Re: [Boost-users] Looping through variadic macro arguments

Subject: Re: [Boost-users] Looping through variadic macro arguments
From: Florian Lindner (mailinglists_at_[hidden])
Date: 2016-03-31 04:00:38

On Wed, 30 Mar 2016 14:42:41 -0400
Edward Diener <eldiener_at_[hidden]> wrote:

> On 3/30/2016 4:35 AM, Florian Lindner wrote:
> > Hey,
> >
> > I have integrated the code in our project now and it fails to
> > compile with some older clang version.
> >
> > It compiles fine with clang++ 3.7.1 and g++ 5.3.0 on my arch
> > machine as well as g++ 4.8.4 on our ubuntu server, but fails with
> > clang++ 3.4 on this machine as well as the travis
> >
> > The complete compiler messages are at http://pastebin.com/HgjgCfsH
> > it is mostly something like that:
> >
> > error: unknown type name 'BOOST_PP_IIF_0'
> >    assertion( reinterpret_cast<Vector&>(*this).size()==toAssign.size()
> > );
> >
> > The assertions code is at
> > https://github.com/precice/precice/blob/develop/src/utils/assertion.hpp
> >
> > as well as all other code files.
> >
> > If you want to give it a try, you can clone the project and use
> >
> > clang++ -o
> > build/debug-nopetsc-nompi/tarch/configuration/ConfigurationRegistry.o
> > -c -Wall -std=c++11 -fPIC -Wsign-compare -g3 -O0 -DDebug -DAsserts
> > -DPRECICE_NO_PETSC -DEIGEN_INITIALIZE_MATRICES_BY_NAN
> > -DPRECICE_NO_MPI -DNPY_NO_DEPRECATED_API=NPY_1_7_API_VERSION -Isrc
> > -I/usr/include -I/usr/include/python2.7
> > -I/usr/include/python2.7/numpy
> > src/tarch/configuration/ConfigurationRegistry.cpp
> >
> > (it's also included in the pastebin above)
> >
> > Do you have any idea?  
> 
> Would you please post a complete example along with your command line
> as a Boost bug report for the preprocessor library ? That way I am
> more likely to take a look at it. My guess, without knowing the
> details of your example, is just a clang-3.4 bug which has been fixed
> in a later release but if your problem is easily reproducable I can
> add a test to the preprocessor tests, based on your example, which
> shows the clang-3.4 bug. Currently my preprocessor tests using
> clang-3.4 do not show any problems so incorporating such a test
> showing a problem will be worthwhile for me.

Hey,

I'm very happy to help that way.

I was able to reproduce that bug in a small piece of code and was doing
some tests using different versions.

The bug is triggered using all clang versions (3.4 and 3.7.1 at least)
if using boost 1.55, and obviously was fixed in 1.56.

Do you still want me to open a bug report?

Best,
Florian