On Wed Jan 15 2014 at 11:51:24 AM, Nico Weber <[email protected]> wrote:
> On Wed, Jan 15, 2014 at 3:41 AM, Alp Toker <[email protected]> wrote: > > > On 15/01/2014 06:04, Nico Weber wrote: > > Does gcc allow this for C? Is C planning on standardizing this? > > > The impression I get is that everybody's doing it but nobody's talking > about it. Yet. > > > Clarified on irc. gcc doesn't implement this, Alp meant that some people > carry local patches to add this support. > > I'm skeptical of adding this if there's no standardization movement for > this and no other compilers support this yet :-/ > I agree. As far as I'm aware, we would be the *only* production C compiler to support C++ attribute syntax. The good news is that we already have a policy on allowing such extension: http://clang.llvm.org/get_involved.html The only point where this extension falls down is point 4. Here's what the C committee said about N1403 (see minutes in N1475): Do you support double square brackets? [[ ]] Yes – 4 No – 15 Abs – 3 Do we want a syntax for non-Standard extensions? Yes – 4 No – 12 Abs – 6 I think it's fair to say we would *not* have the support of the C committee here. ISO C is reactionary so if we set a sensible standard there's a reasonable > shot at getting it adopted. Likewise OpenMP and other dialects -- they'll > go with the mainstream. > > This is also why we should use a name that's already recognised like > "generalized attributes." Language bodies simply won't accept a foreign > name like "C++ attributes" -- it has never happened before, given how > fiercely independent these committees are -- so they'll end up each going > their own route, choosing their own names. It's a better plan to > consolidate proactively here. > > My view is that it matters because we're working with the people designing > these standards and they respect our decisions when we put time into > getting them right. > > Of there'll always be those with Richard Smith's point of view that "we > really don't need to worry about theoretical future C17 or OpenMP > constructs now" -- but assuming we do care (and I do), these are issues > that matter. > > Alp. > > > > > > > On Tue, Jan 14, 2014 at 5:50 PM, Richard Smith <[email protected]<mailto: > [email protected]>> wrote: > > On Tue, Jan 14, 2014 at 5:47 PM, Richard Smith > <[email protected] <mailto:[email protected]>> wrote: > > On Tue, Jan 14, 2014 at 5:23 PM, Alp Toker <[email protected] > <mailto:[email protected]>> wrote: > > This patch generalizes C++11 attributes for use in C and > C-like dialects, and additionally enables the new syntax > as an extension to C11. > > > Why do you allow this by default in C11? And conversely, why > not in C90 / C99? > > > I think maybe this was unclear. I'd prefer one of these two options: > > 1) A -fcxx-attributes argument (or similar) to enable C++ > attribute syntax outside C++ (and either do or don't allow them by > default in C++98), or > 2) C++ attributes available by default in all language modes. > > I'd prefer the first option (defaulting to following the language > standard more strictly) -- I think this would be the first time we > enabled a C++ language feature in C modes, if we went with the > second option. > > If we're going to allow these anywhere by default, C++98 would > seem like a good place to start. I don't believe they > introduce any ambiguities outside of Objective-C(++), and we > already disambiguate those cases. (There's an ambiguity with > lambdas, but we don't need to address that until/unless we > allow lambdas in C++98.) > > All features are carried forward from C++11, including > usage on declarations, attributed statements, scoped > attribute names, GNU attribute aliases and the > clang-specific attribute namespace. > > A new feature detection macro is provided, breaking from > the usual c/cxx prefix convention in order to facilitate > portable detection in C++ and C modes: > > __has_feature(attributes) - 1 in C++11, otherwise 0. > __has_extension(attributes) - 1 in C++11 and C11, otherwise 0. > > > This is already available as __has_feature(cxx_attributes); > using __has_extension(cxx_attributes) in C would seem to be > the right approach here (we're allowing C++ attributes as an > extension in C). This is what we already do for C99 and C11 > features which we accept in C++. > > The new warning flag -W(no-)generalized-attributes > suppresses the new extension warning in C. The same flag > can also be used to selectively disable attribute > compatibility warnings produced by the pre-existing > -Wc++98-compat option. > > > OK, so this is why you wanted us to pick a name for this > feature; you're going to use it as a diagnostic name. I think > this should be called -Wc++-attributes, to match our existing > compatible-for-all-time feature name cxx_attributes. We can > add an alias to a better name if we ever need one, but for > now, we're pretty clearly allowing a C++ feature in C, so > calling it "c++-something" makes sense to me. > > Newly added tests have been shared with C++11 where > possible to ensure consistency between language modes. > > > Does this do the right thing for (for instance) > > struct S { > [[ gnu::aligned(8) ]] int n; > }; > > ? (Structs use different parsing code in C and C++. ) > > > > _______________________________________________ > cfe-commits mailing list > [email protected] <mailto:[email protected]> > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits > > > > -- > http://www.nuanti.com > the browser experts > >
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
