#elif behaviour in gcc 4.4

[tim blechmann <tim@…>]

hi all,

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

a small patch is attached

[Daniel James]

A better patch for this problem.

[Daniel James]

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).

[tim blechmann <tim@…>]

patch against boost-1.36.0

[Daniel James]

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.

[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.

[Daniel James]

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.

[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

[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.

[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

[Daniel James]

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

[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.

[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)

---

[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.

[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?

[Daniel James]

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.

[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)

........

[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