[Bug preprocessor/38161] [4.4 regression] #elif <non-const expression #defined in this #if> breaks

[Bug preprocessor/38161] [4.4 regression] #elif <non-const expression #defined in this #if> breaks

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |signupnathan at gmail dot com

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
*** Bug 57345 has been marked as a duplicate of this bug. ***

[Bug preprocessor/38161] [4.4 regression] #elif <non-const expression #defined in this #if> breaks

[harald at gigawatt dot nl]

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

Harald van Dijk <harald at gigawatt dot nl> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |harald at gigawatt dot nl

--- Comment #6 from Harald van Dijk <harald at gigawatt dot nl> ---
Given that the standard apparently unintentionally requires this behaviour, and
the standard will likely be changed to require FOO to not be evaluated (see
<http://www.open-std.org/JTC1/SC22/WG14/www/docs/dr_412.htm>), perhaps the
pre-4.4 behaviour should be restored, or at least the diagnostics downgraded to
a warning?

[Bug preprocessor/38161] [4.4 regression] #elif <non-const expression #defined in this #if> breaks

[pinskia at gcc dot gnu.org]

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

--- Comment #7 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
*** Bug 57345 has been marked as a duplicate of this bug. ***

[Bug preprocessor/38161] [4.4 regression] #elif <non-const expression #defined in this #if> breaks

[rguenth at gcc dot gnu dot org]

------- Comment #4 from rguenth at gcc dot gnu dot org  2008-12-05 12:20 -------


*** This bug has been marked as a duplicate of 36453 ***


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |DUPLICATE


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

[Bug preprocessor/38161] [4.4 regression] #elif <non-const expression #defined in this #if> breaks

[neil at gcc dot gnu dot org]

------- Comment #3 from neil at gcc dot gnu dot org  2008-11-18 22:18 -------
The standard talks about the groups controlled by conditionals being skipped.

There is no conditional controlling the #elif - it is at the top level - so I
see nothing permitting its non-evaluation.


-- 


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

[Bug preprocessor/38161] [4.4 regression] #elif <non-const expression #defined in this #if> breaks

[h dot b dot furuseth at usit dot uio dot no]

------- Comment #2 from h dot b dot furuseth at usit dot uio dot no  2008-11-17 20:15 -------
Subject: Re:  [4.4 regression] #elif <non-const expression #defined in this
#if> breaks

Yes, I should have read the #36320 text more carefully.  I merely
noticed that its empty #elif cannot expand to anything correct, while
my example can (and does in the real-life case which produced it).

I thought C99 6.10p7 was what saved it:
  The preprocessing tokens within a preprocessing directive are
  not subject to macro expansion unless otherwise stated.
but maybe not.  6.10.1p3 doesn't say anything about some #elif branches
not being evaluated:-(  Hopefully that's just overly standard-lawerly
though.  Maybe comp.std.c would have been a better place to ask.


-- 


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

[Bug preprocessor/38161] [4.4 regression] #elif <non-const expression #defined in this #if> breaks

[tromey at gcc dot gnu dot org]

------- Comment #1 from tromey at gcc dot gnu dot org  2008-11-17 17:29 -------
According to my reading of the standard, this code is in fact incorrect.
This is basically the same as #36320.

I'm beginning to wonder, though, whether this change was overly eager on my
part
and should be made -pedantic only, or something like that.


-- 


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