Bug 38161 - [4.4 regression] #elif <non-const expression #defined in this #if> breaks
Summary: [4.4 regression] #elif <non-const expression #defined in this #if> breaks
Status: RESOLVED DUPLICATE of bug 36453
Alias: None
Product: gcc
Classification: Unclassified
Component: preprocessor (show other bugs)
Version: 4.4.0
: P3 normal
Target Milestone: 4.4.0
Assignee: Not yet assigned to anyone
URL:
Keywords:
: 57345 (view as bug list)
Depends on:
Blocks:
 
Reported: 2008-11-16 21:14 UTC by Hallvard B Furuseth
Modified: 2013-05-20 22:52 UTC (History)
11 users (show)

See Also:
Host: x86_64-unknown-linux-gnu
Target: x86_64-unknown-linux-gnu
Build: x86_64-unknown-linux-gnu
Known to work: 4.3.2
Known to fail: 4.4.0
Last reconfirmed: 2008-11-16 21:50:22


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Hallvard B Furuseth 2008-11-16 21:14:51 UTC
#ifndef FOO
#define FOO sizeof(void *)
#elif FOO
#endif
t.c:3:7: error: missing binary operator before token "("

I expect it's caused by the fix to bug #36320.
Comment 1 Tom Tromey 2008-11-17 17:29:18 UTC
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.
Comment 2 Hallvard B Furuseth 2008-11-17 20:15:30 UTC
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.

Comment 3 Neil Booth 2008-11-18 22:18:18 UTC
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.
Comment 4 Richard Biener 2008-12-05 12:20:10 UTC

*** This bug has been marked as a duplicate of 36453 ***
Comment 5 Jakub Jelinek 2013-05-20 22:39:26 UTC
*** Bug 57345 has been marked as a duplicate of this bug. ***
Comment 6 Harald van Dijk 2013-05-20 22:42:50 UTC
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?
Comment 7 Andrew Pinski 2013-05-20 22:52:54 UTC
*** Bug 57345 has been marked as a duplicate of this bug. ***