This is an archive of the discontinued LLVM Phabricator instance.

Support GCC [[gnu::attributes]] in C2x mode
ClosedPublic

Authored by aaron.ballman on May 29 2020, 1:33 PM.

Details

Summary

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.

Diff Detail

Event Timeline

aaron.ballman created this revision.May 29 2020, 1:33 PM

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.

dblaikie accepted this revision.May 29 2020, 2:06 PM

Sounds good to me (welcome to wait for other reviews if you're looking for something more nuanced/exuperienced in this area)

This revision is now accepted and ready to land.May 29 2020, 2:06 PM

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)

rsmith added inline comments.May 29 2020, 2:28 PM
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.)

erichkeane accepted this revision.May 29 2020, 6:42 PM

(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)

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.

aaron.ballman marked an inline comment as done.

Updated to remove the KnownToGCC tablegen bit.

aaron.ballman added inline comments.May 30 2020, 11:45 AM
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.

erichkeane added inline comments.Jun 1 2020, 6:05 AM
clang/utils/TableGen/ClangAttrEmitter.cpp
65

Doesn't this result in 'K' being uninitialized now?

aaron.ballman marked an inline comment as done.Jun 1 2020, 6:29 AM
aaron.ballman added inline comments.
clang/utils/TableGen/ClangAttrEmitter.cpp
65

K is still being initialized by the ctor init list above on line 56.

erichkeane added inline comments.Jun 1 2020, 6:33 AM
clang/utils/TableGen/ClangAttrEmitter.cpp
65

Isn't that in a different constructor?

New and improved with proper member initialization in all constructors.

aaron.ballman marked 3 inline comments as done.Jun 1 2020, 6:37 AM
aaron.ballman added inline comments.
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.

erichkeane accepted this revision.Jun 1 2020, 6:39 AM
aaron.ballman marked an inline comment as done.

Whoops, *now* I'm properly setting the bit from the record.

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?

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

Sorry for the back and forth, this Monday morning is not easy it seems.

erichkeane accepted this revision.Jun 1 2020, 6:56 AM
aaron.ballman closed this revision.Jun 1 2020, 7:43 AM

Thank you for the review, I've commit in 522934da1f0c78c1de1a80d4ba14204a11f5afa8