On 15/01/2014 19:51, Nico Weber wrote:
On Wed, Jan 15, 2014 at 3:41 AM, Alp Toker <[email protected]
<mailto:[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.
Right. I looked into this because a few different groups requested the
feature last week.
It makes a lot of sense but it's not a need on my end.
I'm skeptical of adding this if there's no standardization movement
for this and no other compilers support this yet :-/
Waiting for standardisation isn't a great idea if the C99-C11 interval
is anything to go by.
Seems reasonable to hold back and see if gcc implements the feature.
Let's revisit then?
Alp.
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]>
<mailto:[email protected] <mailto:[email protected]>>>
wrote:
On Tue, Jan 14, 2014 at 5:47 PM, Richard Smith
<[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>>
wrote:
On Tue, Jan 14, 2014 at 5:23 PM, Alp Toker
<[email protected] <mailto:[email protected]>
<mailto:[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]>
<mailto:[email protected] <mailto:[email protected]>>
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
--
http://www.nuanti.com
the browser experts
--
http://www.nuanti.com
the browser experts
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
