RE: [boost] [preprocessor] Sun Studio 9 Early Access regressions

From: Paul Mensonides (pmenso57_at_[hidden])
Date: 2004-07-14 16:47:56

> -----Original Message-----
> [mailto:boost-bounces_at_[hidden]] On Behalf Of Christopher Currie

> Can anyone lend assistance in debugging the Sun regressions 
> for Boost Preprocessor? The early access edition of the 
> Studio 9 compiler is failing on BOOST_PP code that compiles 
> just fine under earlier versions.
> 
> The code that's failing appears to relate to the expansion (or lack
> thereof) of the macros that implement BOOST_PP_WHILE. I'm 
> continuing to investigate, but since I'm unfamiliar with what 
> the macros are
> *supposed* to do, I'm hoping someone can spot the trouble 
> more quickly than I can.
> 
> I've attached the preprocessed code from 
> libs/preprocessor/test/control.cpp.

It looks more like a failure in the automatic recursion mechanism (all that NODE
stuff that you see in the output is from the internals of the binary search on
available WHILE iterations).  First, what happens when you avoid automatic
recursion in the test case:

#include <boost/preprocessor/arithmetic/add.hpp>
#include <boost/preprocessor/arithmetic/dec.hpp>
#include <boost/preprocessor/control/while.hpp>

#define PRED(d, state) state
#define OP_1(d, state) BOOST_PP_DEC(state)
#define OP_2(d, state) BOOST_PP_DEC(BOOST_PP_ADD_D(d, BOOST_PP_WHILE_ ## d(PRED,
OP_1, state), state))

BOOST_PP_WHILE_1(PRED, OP_2, 10) // 0

Second, what is the result of this:

#include <boost/preprocessor/control/while.hpp>

BOOST_PP_WHILE // should be: BOOST_PP_WHILE_1

> From: boost-bounces_at_[hidden] 
> [mailto:boost-bounces_at_[hidden]] On Behalf Of Christopher Currie

> > Not knowing much, the first thing I'd do is play with the flags 
> > settings in boost/preprocessor/config/config.hpp to see if any of 
> > those can work around the problem.
> > 
> 
> That, combined with some futher investigation, yielded a partial
> solution: the newest version of the Sun needs to enable 
> BOOST_PP_CONFIG_MSVC, in order for BOOST_PP_BITAND to work properly.

What?  Does this work?

#include <boost/preprocessor/logical/bitand.hpp>

BOOST_PP_BITAND(0, 0) // 0
BOOST_PP_BITAND(0, 1) // 0
BOOST_PP_BITAND(1, 0) // 0
BOOST_PP_BITAND(1, 1) // 1

If it doesn't, then the Sun preprocessor is more seriously broken than I
thought.  The MSVC configuration is a bad configuration to have to step down
too.  What it fundamentally does is attempt to force things to expand that
should have expanded already.

> Enabling this does not cause regressions in the earlier 
> version, at least w.r.t. Boost PP.

The test files for the pp-lib do not comprehensively test the pp-lib.  If it
did, there would be many more failures.

> This leaves one test still failing, list.cpp. I've been 
> unable to come up with a config combination that will clear 
> this one up. 
> BOOST_PP_LIST_FOLD_LEFT seems to not remove enough 
> whitespace. I'm sure it's just a bug in Sun's token pasting 
> (which was the cause of the other problems). I'll continue to 
> look for a workaround.

BTW, whitespace between the ## operator and its operands is
non-significant--even if there a hundred space characters in between it should
still work.

> I've attached preprocessor output from list.hpp, the first 
> comes from just adding the MSVC flag, the second from adding 
> the MSVC, EDG, and STRICT flags.

What is the output of list.cpp without any of these flags set (some of these are
contradictory)?

> From: boost-bounces_at_[hidden] 
> [mailto:boost-bounces_at_[hidden]] On Behalf Of Christopher Currie

> I've attached a patch for 
> boost/preprocessor/config/config.hpp, in order to at least 
> fix the most common problems the Sun Studio 9 compiler is 
> having with BOOST_PP_WHILE, as a number of libraries are 
> choking on this at the moment.

Before we get to this, lets try to isolate the problem a little better, but I
don't have access to that preprocessor directly.  Setting the MSVC and
EDG/STRICT flags is contradictory and is almost guaranteed to cause a failure
some time in the future--i.e. STRICT particularly implies *not* MSVC.  In any
case, setting the MSVC flag alone is an option (though an unfortunate one).

Regards,
Paul Mensonides