Modify

Opened 9 years ago

Closed 9 years ago

Last modified 4 years ago

#2069 closed Bugs (fixed)

#elif behaviour in gcc 4.4

Reported by: tim blechmann <tim@…> Owned by: Daniel James
Milestone: Boost 1.37.0 Component: mpl
Version: Boost 1.35.0 Severity: Problem
Keywords: Cc: daniel@…, rwgk@…

Description

hi all,

currently, the mpl header do not compile with gcc-4.4

a small patch is attached

Attachments (3)

boost_mpl_gcc-4_4.patch (2.5 KB) - added by tim blechmann <tim@…> 9 years ago.
mpl.patch (3.9 KB) - added by Daniel James 9 years ago.
A better patch for this problem.
0001-boost.mpl-gcc-4.4-fixes.patch (15.6 KB) - added by tim blechmann <tim@…> 9 years ago.
patch against boost-1.36.0

Download all attachments as: .zip

Change History (19)

Changed 9 years ago by tim blechmann <tim@…>

Attachment: boost_mpl_gcc-4_4.patch added

Changed 9 years ago by Daniel James

Attachment: mpl.patch added

A better patch for this problem.

comment:1 Changed 9 years ago by Daniel James

Cc: daniel@… added
Milestone: Boost 1.36.0Boost 1.37.0

The patch I just attached is more complete and calls BOOST_PP_ITERATION_DEPTH correctly. But this is a larger problem, so I've also written to the mailing list.

(I also changed the milestone to 1.37 because we shouldn't accept patches for unreleased compilers at this late stage).

Changed 9 years ago by tim blechmann <tim@…>

patch against boost-1.36.0

comment:2 Changed 9 years ago by Daniel James

Component: mplpreprocessor
Owner: changed from Aleksey Gurtovoy to No-Maintainer
Summary: compile mpl with gcc-4.4#elif behaviour in gcc 4.4

The following is copied from: http://lists.boost.org/Archives/boost/2008/07/139765.php

A recent change to the development version of the gcc preprocessor changes the way it processes '#elif' directives and breaks a common use of the preprocessor library. We've already had reports of this causing problems in MPL, and it might also affect: variant, function_types, python, fusion, xpressive and phoenix. Details of the change are at:

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

With this change, the argument to an '#elif' directive is processed even if a previous '#if'/'#elif' directive was true. This causes the example use of BOOST_PP_ITERATION_DEPTH to break:

http://www.boost.org/doc/libs/1_35_0/libs/preprocessor/doc/ref/iteration_depth.html

In this example, the first time the header is included, BOOST_PP_ITERATION_DEPTH is not yet defined, so it causes the develoment gcc to fail when the #elif directives are evaluated (which are skipped with existing versions, because the first #if directive evaluates to true).

Looking at the standard, I think their interpretation is correct (although I'm not familiar with it and could be missing something) but it isn't clear that this was the intent of the authors. Any opinions on this?

I think it's quite easy to work around, we can replace:

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

with:

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

So that the calls to BOOST_PP_ITERATION_DEPTH are skipped - or we could just include the necessary header before including the file. But it does seem a pity that any code which uses this technique might need to be changed for gcc 4.4. We should probably write to them about this (it doesn't look like they realised this would be a problem), but I'm writing here first in case anyone has any ideas.

comment:3 Changed 9 years ago by Ralf W. Grosse-Kunstleve

Cc: rwgk@… added

comment:4 Changed 9 years ago by Ralf W. Grosse-Kunstleve

Is anyone working on this issue?

gcc 4.4 is in stage 3 now, and it looks like the new behavior will make it into the release.

comment:5 Changed 9 years ago by Daniel James

Owner: changed from No-Maintainer to Daniel James
Status: newassigned

No, no one's working on it. Someone said they were going to write to Paul Mensonides but I guess that didn't work out, so it looks like it's up to me.

comment:6 Changed 9 years ago by Ralf W. Grosse-Kunstleve

I just wrote a small Python script to do most of the work automatically. With this I got Boost.Python to compile with gcc 4.4. The script and the diffs against the current trunk are here:

http://cci.lbl.gov/~rwgk/tmp/gcc44_boost/

Files fixit.py and diffs_r48789_2008_09_15_1159.

I'll run these changes through our in-house multi-platform build+testing procedure.

I'm not setup for running the standard boost unit tests, to exercise the changes not used by Boost.Python. Help with this would be great.

Ralf

comment:7 Changed 9 years ago by Daniel James

Oh very clever. I wish I'd seen that you'd done that before doing some of them manually. I'm feeling stupid now.

Your patch looks good. To be picky, the comments are a bit mismatched - you've put 'gcc 4.4 compatability' on the #else from the outer if statement and the #endif from the inner statement. That could be confusing and it should be easy to fix. I'd suggest something like:

// For gcc 4.4 compatability, we must include the
// BOOST_PP_ITERATION_DEPTH test inside an #else clause.
#else // BOOST_PP_IS_ITERATING
#if BOOST_PP_ITERATION_DEPTH() == 1

and at the end:

#endif // BOOST_PP_ITERATION_DEPTH()

But feel free to do it however you want.

I'm not set up for testing Boost.Python, but I can test the other libraries - so it's very convenient can you can test it. Can you create a ticket for just the python changes (include a link to this ticket, ie. #2069), and I'll deal with the other libraries. function_types is a bit of a problem as I'm getting failures on gcc 4.3 and the code to be changed looks a little odd already.

Thanks for your help.

comment:8 Changed 9 years ago by Ralf W. Grosse-Kunstleve

OK, I changed the Python script according to your suggestions, and I'm only applying the script to the mpl and python subdirectories. (I need the mpl patches for Boost.Python). I won't do anything with the other files since I'm not setup for the tests, but there aren't very many. Suggestion:

  • I try out the mpl and python fixes in our multi-platform build.
  • I pass them by David Abrahams for review.
  • Then I check them in.
  • Once that is settled (in a day or two) you work on the rest.

How does that sound? (You can easily run the script yourself to do most of the legwork for the rest. Let me know if you need more information.) Ralf

comment:9 Changed 9 years ago by Daniel James

That's great, although I might not wait to deal with the other libraries. Thanks again.

comment:10 Changed 9 years ago by Ralf W. Grosse-Kunstleve

In the meantime, I ran our multi-platform build+test with the modified boost sources, and there are no errors. I wrote David and Aleksey, pointing them to the diffs:

http://cci.lbl.gov/~rwgk/tmp/gcc44_boost/diffs_r48790_mpl_python_2008_09_15_1456

I'll wait until tomorrow afternoon for feedback, although it seems highly unlikely that there's something wrong with the diffs.

comment:11 Changed 9 years ago by Ralf W. Grosse-Kunstleve

No feedback from David or Aleksey...

I went ahead and checked in my patches:


r48960 | rwgk | 2008-09-24 21:49:24 -0700 (Wed, 24 Sep 2008) | 1 line

boost/python, boost/mpl: gcc 4.4 compatibility (see http://svn.boost.org/trac/bo ost/ticket/2069)


comment:12 Changed 9 years ago by Daniel James

Sorry, I've been very slack. Here are the patches I've submitted: #2375, #2376, #2377, #2378, #2379.

I'll change the preprocessor library myself.

comment:13 in reply to:  12 Changed 9 years ago by Ralf W. Grosse-Kunstleve

Replying to danieljames:

Sorry, I've been very slack. Here are the patches I've submitted: #2375, #2376, #2377, #2378, #2379.

Are you planning to check these patches in yourself?

comment:14 Changed 9 years ago by Daniel James

Component: preprocessormpl
Resolution: fixed
Status: assignedclosed

I've finally got round to fully testing the patches and I discovered that the problem only effects the mpl library. It uses a complicated system to preprocess the header files in advance for compilers which have slow preprocessors, and this was preventing it from including the preprocessor library. In all the other libraries <boost/preprocessor/iteration/iterator.hpp> is included by the time the #elif is reached so the problem doesn't occur.

So, this really was an mpl bug and not a preprocessor bug. If you want to, you can problably revert the changes to python. I'm going to try to get python testing working so I can see if it works without the patch but that might take me a little while. Sorry for the hassle. I'm closing the ticket as your patch fixed the problem in mpl.

comment:15 Changed 9 years ago by Daniel James

(In [49257]) Merge the mpl fixes for gcc 4.4. (But not the python ones). Refs #2069.

Merged revisions 48960 via svnmerge from https://svn.boost.org/svn/boost/trunk

........

r48960 | rwgk | 2008-09-25 05:49:24 +0100 (Thu, 25 Sep 2008) | 1 line

boost/python, boost/mpl: gcc 4.4 compatibility (see http://svn.boost.org/trac/boost/ticket/2069)

........

comment:16 Changed 4 years ago by albermg7

Thanks a lot for your changes DanielJames?. 5 years ago and I am gonna use your files to fix my boost version required to build Flexsus :D

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain Daniel James.
The resolution will be deleted.

Add Comment


E-mail address and name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.