This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: C++ constant expressions in __attribute__
On Sat, 7 Mar 2009, Gabriel Dos Reis wrote:
> > (Not that I am impressed with the incompatibilities of C++0x attributes
> > with existing practice or their ignoring all the hard issues with
> > attributes that have actually come up in GCC implementation experience -
> > along with the proposals having long lists of people they were discussed
> > with, none of whom have been involved in any of the discussions of these
> > issues with attributes in GCC.)
>
> I may be wrong but I believe Jason Merrill had had input or participated
> in the attribute discussions in the C++ CWG.
The last paper I can find before attributes support was integrated in the
C++0x document is N2761. It has a long list of people acknowledged, with
Jason Merrill not mentioned by name. It retains the mistake of following
a speculative future direction that used to be in the GCC manual that I
removed in September 2007 as no longer a good idea after I found it had
been picked up in previous draft proposals without talking to GCC people
about whether it really made sense (see my WG14 paper N1259). It does not
seem to address the important question of classifying attributes as
semantic or non-semantic (see
<http://gcc.gnu.org/ml/gcc/2006-10/msg00318.html>), or even reference that
discussion.
By making noreturn apply to functions not to their types, it is both
incompatible with existing practice (whether they apply to functions or
types is certainly visible with GNU typeof, and I suppose may also be
visible through C++0x features without needing GNU extensions), and
ignores rather than thinking about how to address the issues of how those
attributes interact with the type system that I raised in
<http://gcc.gnu.org/ml/gcc-patches/2008-09/msg01056.html>. (It also
chooses in this instance to ignore a long-intended future direction that
noreturn attributes should fully apply to types rather than declarations,
albeit a direction that needs type system issues to be resolved before it
can be brought into effect. So it picks up bad future directions and
ignores good ones.)
--
Joseph S. Myers
joseph@codesourcery.com