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.
Thanks.
------------------ ???????? ------------------
??????: "Aaron Ballman"<aa...@aaronballman.com>;
????????: 2018??5??6??(??????) ????10:19
??????: "????"<772847...@qq.com>;
????: "cfe-commits"<cfe-commits@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, ???? <772847...@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"<aa...@aaronballman.com>;
> ????????: 2018??5??3??(??????) ????7:40
> ??????: "????"<772847...@qq.com>;
> ????: "cfe-commits"<cfe-commits@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, ???? <772847...@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"<aa...@aaronballman.com>;
>> ????????: 2018??5??2??(??????) ????10:05
>> ??????: "????"<772847...@qq.com>;
>> ????: "cfe-commits"<cfe-commits@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, ???? <772847...@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"<aa...@aaronballman.com>;
>>> ????????: 2018??4??29??(??????) ????3:07
>>> ??????: "????"<772847...@qq.com>;
>>> ????: "cfe-commits"<cfe-commits@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@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_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
