GCC 10.1 introduced support for the [[]] style spelling of attributes in C mode. Similar to how GCC supports __attribute__((foo)) as [[gnu::foo]] in C++ mode, it now supports the same spelling in C mode as well. This patch makes a change in Clang so that when you use the GCC attribute spelling, the attribute is automatically available in all three spellings by default. However, like Clang, GCC has some attributes it only recognizes in C++ mode (specifically, abi_tag and init_priority), which this patch also honors.
Details
Diff Detail
Event Timeline
1 comment, perhaps outside the scope of this patch.
clang/utils/TableGen/ClangAttrEmitter.cpp | ||
---|---|---|
85 | I guess its a problem for all of these, but why is the last 'true'/'false' (KnownToGCC) not checked from the Spelling? It has: let KnownToGCC = 1;. I would presume that line either is meaningless, or should be used for the true/false bits in here. |
Sounds good to me (welcome to wait for other reviews if you're looking for something more nuanced/exuperienced in this area)
1 more question, how did you arrive at the 'not supported in C' list? Did you find some GCC docs for that (if so, please put in the commit message)? Or did you just try them all?
(sorry @erichkeane didn't mean to usurp your feedback by approving before it was answered - @aaron.ballman do treat my approval as contingent on that feedback being addressed as you/both see fit)
clang/utils/TableGen/ClangAttrEmitter.cpp | ||
---|---|---|
85 | The KnownToGCC flag affects whether we produce certain warnings, not which spellings we register. This does seem fishy: we have the same information represented and examined both by considering whether the attribute has a GNU vs GCC spelling and by considering whether the KnownToGCC flag is set. I imagine we could factor this better. (The two concerns are, I suppose, notionally orthogonal, but I can't imagine we would ever want them to differ.) |
No problem :) The "KnownToGCC" issue is likely a separate issue that should be fixed in a separate patch.
The source-of-the-not-supported-by-C info is simply "if you got this elsewhere, please document the source for future reference", which can be handled without me double checking. If its self experimentation, that makes me sad, but I don't think there is further action that could be taken about that one.
clang/utils/TableGen/ClangAttrEmitter.cpp | ||
---|---|---|
85 | Well, both are used to set the value in "FlattenedSpelling". Here we use true/false, but if you construct one via a record it uses the KnownToGCC flag. It seems to me that these values should be initialized consistently. The "spelling" Variety themselves I can see being different, but for consistency's sake, these trues in the emplace_back should set KnownToGCC with the attribute. That, or we abandon the KnownToGCC 'Value' in the spelling and just always infer it based on the variety. Like I said, its just weird that sometimes we set this via the tablegen file, sometimes we do it automagically. |
clang/utils/TableGen/ClangAttrEmitter.cpp | ||
---|---|---|
85 | Yeah, I agree that this is a bit weird. IIRC, this came from a time when GCC hadn't yet made all attribute spellings available as [[]] spellings and so there was a worry we'd have some attribute spellings that use GNU instead of GCC, despite being supported by GCC. I don't think that situation is plausible any longer. I think a better approach is to keep the known to GCC bit on the ParsedAttr object so we don't have to check attribute vendor name when issuing a diagnostic, but we should infer that bit from the spelling instead of setting it in the Attr.td file. |
clang/utils/TableGen/ClangAttrEmitter.cpp | ||
---|---|---|
65 | Doesn't this result in 'K' being uninitialized now? |
clang/utils/TableGen/ClangAttrEmitter.cpp | ||
---|---|---|
65 | K is still being initialized by the ctor init list above on line 56. |
clang/utils/TableGen/ClangAttrEmitter.cpp | ||
---|---|---|
65 | Isn't that in a different constructor? |
clang/utils/TableGen/ClangAttrEmitter.cpp | ||
---|---|---|
65 | Yes, yes it is. :-D Thank you for helping to point that out. I've fixed in the latest patch. |
There's a documented list, and I'll add it to the commit message (though the format of the link makes me wonder how stable it will be): https://gcc.gnu.org/onlinedocs/gcc-10.1.0/gcc/C_002b_002b-Attributes.html#C_002b_002b-Attributes
Doesn't this result in 'K' being uninitialized now?