Re: [Boost-testing] pathscale 3.1 reporting problems?

Subject: Re: [Boost-testing] pathscale 3.1 reporting problems?
From: Christopher Cambly (ccambly_at_[hidden])
Date: 2009-06-17 12:04:51

> > >
> > > This test is expected to fail (it tests how Boost.Test handles
> > > division by zero)
> > > and if it's not this is an error. That's all.FWIW I'm not a fan of
this
> test. >  xlC/PPC hardware does not trap on div.  We can fix it easy
> by adding an
> option > to generate a trap and did so in Boost 1.34.1 but never bothered
for
> the Boost > development line.
>
> Not sure I follow this comment. You changed compiler only for boost
1.34.1? Or
> you changed toolset? Why not generate this trap always?
>
> That said, division by zero is just another error condition
> Boost.Test is trying
> to catch and properly report. If you opt not to generate it, you can
> always mark
> this test as intentionally failing.
>
This testcase appears to assume that all hardware will generate an
exception on a divide by zero.  I believe that the PPC hardware itself does
not raise an exception on a divide by zero.  The compiler can insert
special code around the divide by zero to cause an exception similar to
what is expected by this testcase but that is not the default of the
hardware or the compiler.

In a patch that we provided for Boost 1.34.1 we added an option
(-qflttrap=zerodivide) to the Jamfile that would generate the behaviour
expected by this testcase.  However, the change was never propagated to the
Boost development line which is why the test still fails for us.
Certainly, the test could be marked as a known failure but the underlying
assumption of the test that all hardware/software will fail on a divide by
zero is false.

The comment was nothing more than a comment about the test itself which has
underlying assumptions that are invalid on certain platforms.

Chris Cambly
XL C++ Compiler Development