Boost C++ Libraries: Ticket #2069: #elif behaviour in gcc 4.4

attachment set

Fri, 04 Jul 2008 11:58:59 GMT

attachment → boost_mpl_gcc-4_4.patch

attachment set

Daniel James — Sat, 12 Jul 2008 12:54:03 GMT

attachment → mpl.patch

A better patch for this problem.

milestone changed; cc set

Daniel James — Sat, 12 Jul 2008 13:24:36 GMT

cc daniel@… added
milestone Boost 1.36.0 → Boost 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).

attachment set

Wed, 20 Aug 2008 08:47:11 GMT

attachment → 0001-boost.mpl-gcc-4.4-fixes.patch

patch against boost-1.36.0

owner, component, summary changed

Daniel James — Wed, 20 Aug 2008 19:53:32 GMT

owner changed from Aleksey Gurtovoy to No-Maintainer
component mpl → preprocessor
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.

cc changed

Ralf W. Grosse-Kunstleve — Mon, 15 Sep 2008 16:26:47 GMT

cc rwgk@… added

Ralf W. Grosse-Kunstleve — Mon, 15 Sep 2008 16:31:01 GMT

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.

owner, status changed

Daniel James — Mon, 15 Sep 2008 18:46:27 GMT

owner changed from No-Maintainer to Daniel James
status new → assigned

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 — Mon, 15 Sep 2008 19:04:51 GMT

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 — Mon, 15 Sep 2008 20:05:02 GMT

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 — Mon, 15 Sep 2008 21:55:25 GMT

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 — Mon, 15 Sep 2008 22:08:36 GMT

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

Ralf W. Grosse-Kunstleve — Tue, 16 Sep 2008 02:11:42 GMT

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 — Thu, 25 Sep 2008 04:53:55 GMT

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 — Wed, 01 Oct 2008 12:07:26 GMT

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 — Wed, 01 Oct 2008 15:27:33 GMT

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?

status, component changed; resolution set

Daniel James — Tue, 07 Oct 2008 00:15:11 GMT

status assigned → closed
resolution → fixed
component preprocessor → mpl

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 — Fri, 10 Oct 2008 19:58:48 GMT

(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 — Fri, 15 Nov 2013 12:05:31 GMT

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