If I want to disable certain attributes, such as"swiftcall", isthereany way to do it now?

Aaron Ballman via cfe-commits cfe-commits at lists.llvm.org
Mon May 7 05:13:04 PDT 2018


On Mon, May 7, 2018 at 5:48 AM, 朴素 <772847235 at qq.com> wrote:
> hi, Aaron
>
>
>   I may found a useful example. For example, I tested the alias attribute on
> my own Apple laptop (Target: x86_64-apple-darwin17.5.0). First, I use
> __has_attribute to test that the alias is usable or not. The test code is as
> follows:
>
>  #include <stdio.h>
>
> void print() {
>
> #if __has_attribute(alias)
>
>    printf("has attribute");
>
> #else
>
>    printf("has not attribute");
>
> #endif
>
> }
>
> int main() {
>
>     print();
>
>     return 0;
>
> }
>
> Compiled using clang, the output result is has attribute, but when i use the
> following code to verify
>
> #include <stdio.h>
>
> int oldname = 1;
>
> extern int newname __attribute__((alias("oldname"))); // declaration
>
> void foo(void)
>
> {
>
>     printf("newname = %d\n", newname); // prints 1
>
> }
>
> int main() {
>
>     foo();
>
>     return 0;
>
> }
>
> It told me alias.c:3:35: error: aliases are not supported on darwin,but if
> TargetNotSupportedAttr method is used, we can avoid __has_attribute (alias)
> returns true, so we can tell the user more clearly that we do not support
> this attribute on this platform.

That's a bug with the definition of the alias attribute in Attr.td --
it doesn't specify that it's a target-specific attribute, so the
table-generated implementation of __has_attribute does not know to add
in the target-specific check. I think this can be corrected by
properly making the alias attribute inherit from TargetSpecificAttr
and pulling out the custom logic handleAliasAttr() in
SemaDeclAttr.cpp. That said, it could be easier to specify with a
negative version of a TargetSpec like we already do for LangOpt. This
is a difference from what we discussed above in that it doesn't
introduce a new Attr subclass to inherit from but continues to use the
existing TargetSpecificAttr base class.

~Aaron

>
>
>   Thanks.
>
>
>
> ------------------ 原始邮件 ------------------
> 发件人: "Aaron Ballman"<aaron at aaronballman.com>;
> 发送时间: 2018年5月6日(星期天) 晚上10:19
> 收件人: "朴素"<772847235 at qq.com>;
> 抄送: "cfe-commits"<cfe-commits at lists.llvm.org>;
> 主题: Re: If I want to disable certain attributes, such
> as"swiftcall",isthereany way to do it now?
>
> On Sun, May 6, 2018 at 10:01 AM, 朴素 <772847235 at qq.com> wrote:
>> hi, Aaron
>>
>>    Can I ask you some questions?Is there such a demand for me in the
>> community? Does my code need to be submitted to the community?
>>    Thanks.
>
> Generally speaking, the community will accept production-quality
> patches that solve a problem with the product or introduce some new,
> desirable functionality. What you've described so far sounds like it
> solves a specific problem you're having, but it doesn't sound like it
> solves a problem the general public is having. Perhaps if you
> described how you envision your solution being used in the product and
> what immediate problems it solves, that would help me to understand
> the situation a bit better. Basically, if you want to propose adding
> TargetNotSupportedAttr, can you describe what attributes you would
> propose using it on?
>
> Thanks!
>
> ~Aaron
>
>
>> ------------------ 原始邮件 ------------------
>> 发件人: "Aaron Ballman"<aaron at aaronballman.com>;
>> 发送时间: 2018年5月3日(星期四) 晚上7:40
>> 收件人: "朴素"<772847235 at qq.com>;
>> 抄送: "cfe-commits"<cfe-commits at lists.llvm.org>;
>> 主题: Re: If I want to disable certain attributes, such
>> as"swiftcall",isthere
>> any way to do it now?
>>
>> On Thu, May 3, 2018 at 1:25 AM, 朴素 <772847235 at qq.com> wrote:
>>> hi, Aaron
>>>
>>>   The reason why i not use of TargetSpecificAttr is as follows.If I plan
>>> to
>>> support a new platform, I don't want to let users use certain attributes
>>> because of hardware or simply not want to. Yes, we can use
>>> TargetSpecificAttr, but if we use TargetSpecificAttr that we need to
>>> include
>>> platforms other than unsupported platforms, but we just need to exclude
>>> that
>>> platform, using TargetSpecificAttr may not be a good idea.
>>
>> Okay, that makes sense to me. Your design seems like a reasonable one.
>>
>> ~Aaron
>>
>>>
>>>
>>>
>>> ------------------ 原始邮件 ------------------
>>> 发件人: "Aaron Ballman"<aaron at aaronballman.com>;
>>> 发送时间: 2018年5月2日(星期三) 晚上10:05
>>> 收件人: "朴素"<772847235 at qq.com>;
>>> 抄送: "cfe-commits"<cfe-commits at lists.llvm.org>;
>>> 主题: Re: If I want to disable certain attributes, such as
>>> "swiftcall",isthere
>>> any way to do it now?
>>>
>>> On Wed, May 2, 2018 at 4:59 AM, 朴素 <772847235 at qq.com> wrote:
>>>> Thanks.
>>>>
>>>> If I remove some specific attributes, now I can think of the following
>>>> method.First of all, let me talk about my method.
>>>>
>>>> 1.Define target platforms that do not support attributes.such as def
>>>> TargetPower : TargetArch<["ppc", "ppc64", "ppc64le"]>;
>>>>
>>>> 2.Define TargetNotSupportedAttr class.such as class
>>>> TargetNotSupportedAttr<TargetArch target> ;
>>>
>>> Why not make use of TargetSpecificAttr to mark the attributes that are
>>> specific to a target rather than marking the attributes not supported
>>> by a target?
>>>
>>>> 3.Using this approach, we need to modify the
>>>> cfe-4.0.1.src/utils/TableGen/ClangAttrEmitter.cpp file.Modifying the
>>>> code
>>>> in
>>>> the GenerateHasAttrSpellingStringSwitch function looks like this:
>>>>
>>>> if(Attr->isSubClassOf("TargetNotSupportedAttr")) {   // add
>>>>
>>>> #define GenerateTargetNotSupportedAttrChecks
>>>> GenerateTargetSpecificAttrChecks // add
>>>>
>>>>         const Record *R = Attr->getValueAsDef("Target");   // add
>>>>
>>>>         std::vector<std::string> Arches =
>>>> R->getValueAsListOfStrings("Arches"); // add
>>>>
>>>>         GenerateTargetNotSupportedAttrChecks(R, Arches, Test, nullptr);
>>>> // add
>>>>
>>>>         TestStr = !Test.empty() ? Test + " ? "  + " 0 :" +
>>>> llvm::itostr(Version) : "0"; // add
>>>>
>>>>     } else if (Attr->isSubClassOf("TargetSpecificAttr"))
>>>>
>>>> 4.And for classes that inherit from TargetNotSupportedAttr<> class, we
>>>> don’t
>>>> need to generate the attribute class, so add the following code in
>>>> EmitClangAttrClass
>>>>
>>>> if (R->getName() != "TargetSpecificAttr" &&
>>>>
>>>>               R->getName() != "TargetNotSupportedAttr” &&  //add
>>>>
>>>>               SuperName.empty())
>>>>
>>>>         SuperName = R->getName();
>>>>
>>>>
>>>> If I use this method, is it correct?
>>>
>>> It seems like it would work, yes.
>>>
>>> ~Aaron
>>>
>>>>
>>>>
>>>>
>>>>
>>>> ------------------ 原始邮件 ------------------
>>>> 发件人: "Aaron Ballman"<aaron at aaronballman.com>;
>>>> 发送时间: 2018年4月29日(星期天) 凌晨3:07
>>>> 收件人: "朴素"<772847235 at qq.com>;
>>>> 抄送: "cfe-commits"<cfe-commits at lists.llvm.org>;
>>>> 主题: Re: If I want to disable certain attributes, such as "swiftcall",
>>>> isthere any way to do it now?
>>>>
>>>> On Fri, Apr 27, 2018 at 11:23 PM, 朴素 via cfe-commits
>>>> <cfe-commits at lists.llvm.org> wrote:
>>>>>    As the title says,thanks.
>>>>
>>>> You could build a custom clang with specific attributes removed, but
>>>> there are no compiler flags that allow you to disable arbitrary
>>>> attributes like swiftcall.
>>>>
>>>> ~Aaron


More information about the cfe-commits mailing list