[Bug c++/10479] __alignof__(double) not compile time constant inside template class

gdr at integrable-solutions dot net gcc-bugzilla@gcc.gnu.org
Tue Sep 14 14:46:00 GMT 2004


------- Additional Comments From gdr at integrable-solutions dot net  2004-09-14 14:46 -------
Subject: Re:  __alignof__(double) not compile time constant inside template class

"rguenth at tat dot physik dot uni-tuebingen dot de" <gcc-bugzilla@gcc.gnu.org> writes:

| Same with using sizeof() instead of __alignof__.  Can we please clarify if we

You'e right.  The issue has nothing to do with __alignof__ extension.
Using sizeof is probably better.

| are supporting this syntax?  It seems at least that sizeof() is a constant
| expression
| in the sense of the C++ standard.  So - are we supposed to support any
| conforming constant expression as argument to attribute(aligned)?
| 
| I'd like to CC a C++ maintainer here, but it seems just for one comment I cannot
| do this, so, Mark added to PR CC list.


I know (or at least I knew) what is going on here.  
I was meaning to send a detailed explanation of this to the general
list a long time ago.  We have another instance of this bug somewhere,
I tink.

The executive summary is that __attribute__ was designed to ignore
language lookup rules -- yep, lookup!

When parsing attributes, the parser interprets any identifier (or
anything that looks so) as an attribute name/value or keyword.  In
particular, it does not understand symbolic constants.  It it is
expecting to see a constant expression, then it really means a
literal or combination of such; but not computed constant expressions
or symbolic constant expressions.  That is just plain stupid but it
works for C, and that is what they were designed for.
Given the above situation, tsubst() does not even try to look into
attributes -- because there is no much it would do there since
attributes disobey language scope rules.

To solve, this problem, one would have to redesign the name lookup
rules for attributes.  Or/and provide an "escaping" mechanism for the
compiler to follow usual language rules.

-- Gaby


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10479



More information about the Gcc-bugs mailing list