[boost] MPL GCC 4.x regressions (Was: Re: Boost regression notification (2006-10-24 [RC_1_34_0]))

From: Aleksey Gurtovoy (agurtovoy_at_[hidden])
Date: 2006-11-10 19:02:15

Phil Richards writes:
> On 2006-10-24, Douglas Gregor <dgregor_at_[hidden]> wrote:
> >  Boost Regression test failures
> >  Report time: 2006-10-24T10:41:49Z
> [...]
> > |mpl|
> >    multiset:  gcc-4.0.3_linux  gcc-4.1.0_linux  gcc-4.1.0_linux_x86_64  gcc-4.1.1_sunos_i86pc  gcc-4_0_3_tru64
> 
> These are not going to go away unless either:
> 1. they are marked as expected
> 2. the test is reworked to avoid the problem
> 3. the macro BOOST_MPL_ASSERT_RELATION is reworked to avoid the problem
> 
> See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29518

Thanks for the lead!

> 
> The macro is:
>     #define BOOST_MPL_ASSERT(pred) \
>     enum { \
> 	BOOST_PP_CAT(mpl_assertion_in_line_,__LINE__) = sizeof( \
> 	      boost::mpl::assertion_failed<false>( \
> 		  boost::mpl::assert_arg( (void (*) pred)0, 1 ) \
> 		) \
> 	    ) \
>     }\
>     /**/
> 
> It is apparently to do with the enum usage... 

Actually, no, enums in the bug's subject and reduced test case are a
red herring. For example, this still fails for me on 4.1.1:

template< int C > int assertion_failed(int);
template< class > struct N
{
  static int const value = 1;
  static int const t = sizeof( assertion_failed<value>(0) );
};

int main()
{
  N<int> n;
  return n.t;
}

As a matter of fact, my current workaround for this issue involves
_introducing_ an auxiliary enum for the values that are used in
function templates' non-type arguments, e.g.:

template< int C > int assertion_failed(int);
template< class > struct N
{
  static int const value = 1;
  enum { gcc_workaround = value };
  static int const t = sizeof( assertion_failed<gcc_workaround>(0) ); // it compiles, yay!
};

> I'm guessing there is a good reason why this code (and others in the
> boost/mpl/assert.hpp) uses enum directly rather than
> BOOST_STATIC_CONSTANT?

I vaguely recalled that there was, but didn't remeber what it was, so
in the end I found it out the hard way :). There are at least two
reasons:

1) Borland can't cope with static constants there
   (http://article.gmane.org/gmane.comp.lib.boost.testing/3514).

2) GCC issues "unused variable" warnings when static constants are
   used at a function scope
   (http://article.gmane.org/gmane.comp.lib.boost.devel/150691).

Thanks for your input,
-- 
Aleksey Gurtovoy
MetaCommunications Engineering