Patch for building Boost with GCC 4.4.0 - Boost-users - lists.preview.boost.org

newer
[serialization] class names in xml...

Patch for building Boost with GCC 4.4.0

older
VS 2008 and boost::thread...

Chris Fairles

18 Jun 2008 18 Jun '08

12:51 p.m.

GCC changed the way #elif's are handled (is now more std-compliant apparently) but this broke all the #elif BOOST_PP_ITERATION_DEPTH() == N lines. They need to be replaced with #elif defined(BOOST_PP_ITERATION_DEPTH) #if BOOST_PP_ITERATION_DEPTH == N ... #endif Attached is a patch that does so (against trunk). Cheers, Chris

Reply

Sign in to reply online Use email software

Show replies by date

Chris Fairles

18 Jun 18 Jun

12:52 p.m.

On Wed, Jun 18, 2008 at 8:51 AM, Chris Fairles wrote:

GCC changed the way #elif's are handled (is now more std-compliant apparently) but this broke all the #elif BOOST_PP_ITERATION_DEPTH() == N lines. They need to be replaced with

#elif defined(BOOST_PP_ITERATION_DEPTH) #if BOOST_PP_ITERATION_DEPTH == N ... #endif

Attached is a patch that does so (against trunk).

Cheers, Chris

Guess I should actually attach the patch... Chris

Reply

Sign in to reply online Use email software

Frank Mori Hess

3:18 p.m.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 18 June 2008 08:52 am, Chris Fairles wrote:

On Wed, Jun 18, 2008 at 8:51 AM, Chris Fairles wrote:

...
GCC changed the way #elif's are handled (is now more std-compliant apparently) but this broke all the #elif BOOST_PP_ITERATION_DEPTH() == N lines. They need to be replaced with

#elif defined(BOOST_PP_ITERATION_DEPTH) #if BOOST_PP_ITERATION_DEPTH == N ... #endif

Does it work if you do #elif defined(BOOST_PP_ITERATION_DEPTH) && BOOST_PP_ITERATION_DEPTH() == N then you could avoid adding the extra #endif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIWSdD5vihyNWuA4URAjY+AKCS3jeAhQkkbMb03vWLe4+ntvW1oACgw0Gi Y0HYLTLQLAieVN+0zz8CJYQ= =jIsQ -----END PGP SIGNATURE-----

Reply

Sign in to reply online Use email software

Chris Fairles

10:03 p.m.

On Wed, Jun 18, 2008 at 11:18 AM, Frank Mori Hess wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On Wednesday 18 June 2008 08:52 am, Chris Fairles wrote:

...
On Wed, Jun 18, 2008 at 8:51 AM, Chris Fairles wrote:

...
GCC changed the way #elif's are handled (is now more std-compliant apparently) but this broke all the #elif BOOST_PP_ITERATION_DEPTH() == N lines. They need to be replaced with

#elif defined(BOOST_PP_ITERATION_DEPTH) #if BOOST_PP_ITERATION_DEPTH == N ... #endif

Does it work if you do

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

then you could avoid adding the extra #endif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFIWSdD5vihyNWuA4URAjY+AKCS3jeAhQkkbMb03vWLe4+ntvW1oACgw0Gi Y0HYLTLQLAieVN+0zz8CJYQ= =jIsQ -----END PGP SIGNATURE----- _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

Unfortunately no. I thought at first it would, but gcc 4.4 still complains. Reading the std (albeit, n2606, the c++0x draft) it seems this is incorrect since the tokens after the pp directive combine to form a constant-expression and constant-expressions can be short circuited. There may be some special rule for the logical && in pp const-exprs saying that sub-expressions can be evaluated out of order, but I couldn't find anything.

Reply

Sign in to reply online Use email software

Chris Fairles

10:34 p.m.

On Wed, Jun 18, 2008 at 6:03 PM, Chris Fairles wrote:

On Wed, Jun 18, 2008 at 11:18 AM, Frank Mori Hess wrote:

...
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On Wednesday 18 June 2008 08:52 am, Chris Fairles wrote:

...
On Wed, Jun 18, 2008 at 8:51 AM, Chris Fairles wrote:

...
GCC changed the way #elif's are handled (is now more std-compliant apparently) but this broke all the #elif BOOST_PP_ITERATION_DEPTH() == N lines. They need to be replaced with

#elif defined(BOOST_PP_ITERATION_DEPTH) #if BOOST_PP_ITERATION_DEPTH == N ... #endif

Does it work if you do

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

then you could avoid adding the extra #endif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFIWSdD5vihyNWuA4URAjY+AKCS3jeAhQkkbMb03vWLe4+ntvW1oACgw0Gi Y0HYLTLQLAieVN+0zz8CJYQ= =jIsQ -----END PGP SIGNATURE----- _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

Unfortunately no. I thought at first it would, but gcc 4.4 still complains. Reading the std (albeit, n2606, the c++0x draft) it seems this is incorrect since the tokens after the pp directive combine to form a constant-expression and constant-expressions can be short circuited. There may be some special rule for the logical && in pp const-exprs saying that sub-expressions can be evaluated out of order, but I couldn't find anything.

I'm wrong. It's correctly erroring because: #elif 0 && () == 1 isn't a valid constant expression. Chris

Reply

Sign in to reply online Use email software

Daniel James

19 Jun 19 Jun

10:35 a.m.

2008/6/18 Chris Fairles :

I'm wrong. It's correctly erroring because: #elif 0 && () == 1 isn't a valid constant expression.

If BOOST_PP_ITERATION_DEPTH was not defined that would probably be: #elif 0 && BOOST_PP_ITERATION_DEPTH() == N Which I think still isn't valid. The basic structure of boost/mpl/aux_/advance_backward.hpp is something like: #if !defined(BOOST_PP_IS_ITERATING) // ... #elif BOOST_PP_ITERATION_DEPTH() == 1 // ... #elif BOOST_PP_ITERATION_DEPTH() == 2 // ... #endif If I understand you correctly, gcc 4.4 has started evaluating the '#elif' arguments even when a previous '#if' or '#elif' argument was true. I have no idea if gcc 4.4 is correct.... Your patch changes this to: #if !defined(BOOST_PP_IS_ITERATING) // ... #elif defined(BOOST_PP_ITERATION_DEPTH) # if BOOST_PP_ITERATION_DEPTH() == 1 // ... # endif #elif defined(BOOST_PP_ITERATION_DEPTH) # if BOOST_PP_ITERATION_DEPTH() == 2 // ... # endif #endif Which is wrong because the check 'BOOST_PP_ITERATION_DEPTH() == 2' can never be reached. A solution might be something like: #if !defined(BOOST_PP_IS_ITERATING) // ... #else # if BOOST_PP_ITERATION_DEPTH() == 1 // ... # elif BOOST_PP_ITERATION_DEPTH() == 2 // ... # endif #endif Anyway, I doubt the relevant developers will see this. The best way to get their attention would probably be to create a ticket: http://svn.boost.org/trac/boost/newticket?component=mpl Daniel

Reply

Sign in to reply online Use email software

Chris Fairles

20 Jun 20 Jun

1:38 p.m.

On Thu, Jun 19, 2008 at 6:35 AM, Daniel James wrote:

2008/6/18 Chris Fairles :

...
I'm wrong. It's correctly erroring because: #elif 0 && () == 1 isn't a valid constant expression.

If BOOST_PP_ITERATION_DEPTH was not defined that would probably be:

#elif 0 && BOOST_PP_ITERATION_DEPTH() == N

Which I think still isn't valid.

The basic structure of boost/mpl/aux_/advance_backward.hpp is something like:

#if !defined(BOOST_PP_IS_ITERATING) // ... #elif BOOST_PP_ITERATION_DEPTH() == 1 // ... #elif BOOST_PP_ITERATION_DEPTH() == 2 // ... #endif

If I understand you correctly, gcc 4.4 has started evaluating the '#elif' arguments even when a previous '#if' or '#elif' argument was true. I have no idea if gcc 4.4 is correct....

Your patch changes this to:

#if !defined(BOOST_PP_IS_ITERATING) // ... #elif defined(BOOST_PP_ITERATION_DEPTH) # if BOOST_PP_ITERATION_DEPTH() == 1 // ... # endif #elif defined(BOOST_PP_ITERATION_DEPTH) # if BOOST_PP_ITERATION_DEPTH() == 2 // ... # endif #endif

Which is wrong because the check 'BOOST_PP_ITERATION_DEPTH() == 2' can never be reached. A solution might be something like:

#if !defined(BOOST_PP_IS_ITERATING) // ... #else # if BOOST_PP_ITERATION_DEPTH() == 1 // ... # elif BOOST_PP_ITERATION_DEPTH() == 2 // ... # endif #endif

Anyway, I doubt the relevant developers will see this. The best way to get their attention would probably be to create a ticket:

http://svn.boost.org/trac/boost/newticket?component=mpl

Daniel _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

Ha. Classic case of "It compiles? Ship it!" Good catch, your solution is indeed what I intended. Will fix and submit ticket. Cheers, Chris

Reply

Sign in to reply online Use email software

6092

Age (days ago)

6094

Last active (days ago)

Download

6 comments

3 participants

tags

participants (3)

Chris Fairles
Daniel James
Frank Mori Hess