Bug 36453 - [DR 412] PR36320 breaks boost
Summary: [DR 412] PR36320 breaks boost
Status: RESOLVED DUPLICATE of bug 60570
Alias: None
Product: gcc
Classification: Unclassified
Component: preprocessor (show other bugs)
Version: 4.4.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
: 37518 37781 38161 80231 (view as bug list)
Depends on:
Blocks: 36320
  Show dependency tree / graph
 
Reported: 2008-06-06 17:54 UTC by Dirk Mueller
Modified: 2024-04-02 21:40 UTC (History)
7 users (show)

See Also:
Host:
Target:
Build:
Known to work: 5.1.0
Known to fail:
Last reconfirmed: 2008-06-06 20:03:39

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Dirk Mueller 2008-06-06 17:54:03 UTC 
testcase:

=== Cut ===
#if !defined(BOOST_PP_IS_ITERATING)

#elif BOOST_PP_ITERATION_DEPTH() == 1
#endif
=== Cut ===

error: missing binary operator before token "("


from reading the PR36320, this behaviour doesn't seem to be intended. It was
intended to only add a check for non-null argument.
Comment 1 Tom Tromey 2008-06-06 20:23:50 UTC 
By my reading of the standard, issuing an error here is correct.
The restrictions on #elif are only lifted if it is in a skipped group.
But, in this case, it is not.
Comment 2 Dirk Mueller 2008-06-10 22:14:50 UTC 
so the code should be changed to

#elif defined(BOOST_PP_ITERATION_DEPTH) && BOOST_PP_ITERATION_DEPTH() == 1

?

it is confusing that #elif behaves more like "#if" and not like "#else\n#if"
Comment 3 Tom Tromey 2008-07-06 03:25:19 UTC 
Sorry, I somehow missed the followup comment.

>> #elif defined(BOOST_PP_ITERATION_DEPTH) && BOOST_PP_ITERATION_DEPTH() == 1

The expression has to be valid after preprocessing.
So, if BOOST_PP_ITERATION_DEPTH is not defined, this will yield an error.

>> it is confusing that #elif behaves more like "#if" and not like "#else\n#if"

I agree, but by my reading this is what the standard actually says.
I am open to arguments contrariwise, or to rulings from gcc developers more
expert at standardese than I.
Comment 4 Dirk Mueller 2008-07-07 09:25:22 UTC 
well, lets keep it at that for now
Comment 5 Andreas Schwab 2008-09-14 08:08:30 UTC 
*** Bug 37518 has been marked as a duplicate of this bug. ***
Comment 6 Andreas Schwab 2008-10-09 14:46:23 UTC 
*** Bug 37781 has been marked as a duplicate of this bug. ***
Comment 7 Samuel Tardieu 2008-10-09 20:39:00 UTC 
Note that this has been fixed in Boost SVN repository recently (http://svn.boost.org/trac/boost/ticket/2069).
Comment 8 Richard Biener 2008-12-05 12:20:10 UTC 
*** Bug 38161 has been marked as a duplicate of this bug. ***
Comment 9 Andres G. Aragoneses 2010-05-06 18:02:49 UTC 
Hello.

I'm in a position in which I cannot upgrade my Boost libraries right now.

So, is there a way that I can tell gcc to ignore this warning for now?

Thanks in advance.
Comment 10 rguenther@suse.de 2010-05-07 08:39:46 UTC 
Subject: Re:  PR36320 breaks boost

On Thu, 6 May 2010, knocte at gmail dot com wrote:

> ------- Comment #9 from knocte at gmail dot com  2010-05-06 18:02 -------
> Hello.
> 
> I'm in a position in which I cannot upgrade my Boost libraries right now.
> 
> So, is there a way that I can tell gcc to ignore this warning for now?

No.
Comment 11 Andrew Pinski 2013-05-20 22:50:56 UTC 
Reopening to ...
Comment 12 Andrew Pinski 2013-05-20 22:51:18 UTC 
Suspend based on the defect report.
Comment 13 Jackie Rosen 2014-02-16 10:02:53 UTC Comment hidden (spam)
Comment 15 Andrew Pinski 2014-06-06 19:07:24 UTC 
Looks like there is TR about this now as far as I can tell from Feb 2012.
Comment 16 Richard Biener 2017-03-28 07:29:23 UTC 
*** Bug 80231 has been marked as a duplicate of this bug. ***
Comment 17 Andrew Pinski 2024-04-02 21:40:42 UTC 
Dup.

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