Re: [boost] [utility] operators_test/gcc-3.4.5/64 bit

From: David Abrahams (dave_at_[hidden])
Date: 2006-08-23 16:25:16

"Julio M. Merino Vidal" <jmmv84_at_[hidden]> writes:

> On 8/23/06, Martin Wille <mw8329_at_[hidden]> wrote:
>> Martin Wille wrote:
>> > Daniel Frey wrote:
>> >> Vladimir Prus wrote:
>> >>> Hi,
>> >>> the above test fails with ICE:
>> >>>
>> >>>    http://tinyurl.com/pw2qu
>> >>>
>> >>> Is any maintainer willing to sumbit a bug report? In any case, can this
>> >>> failure be marked as expected?
>> >> Before marking it as expected, let's at least try to find a solution.
>> >> I'd like to understand what exactly the problem is, whether there is a
>> >> fix I could apply and what bug to file against the GCC. I just don't
>> >> have a x86_64 system to test. Anyone?
>> >
>> > The problem could be that gcc runs out of memory here.
>> >
>> > I'll try with a higher limit.
>>
>>
>> That didn't work, apparently. The problem isn't memory; apparently, the
>> compiler runs into an infinite loop. The test got killed due to
>> exceeding the limit on CPU time.
>>
>>
>> Note that http://tinyurl.com/gqnd5 shows the same symptoms. Could this
>> be caused by the same compiler bug?
>
> And a similar problem appears while building Boost Wave under
> NetBSD/amd64 with gcc 3.x.  We use the following hack during the build
> to avoid the problem:
>
> # GCC 3.3.3 enters an infinite loop under NetBSD/amd64 in Boost.Wave's
> # insantiate_cpp_literalgrs.cpp source file.  Avoid compiling it.
> # To make things simple, apply the hack to all the platforms so that the
> # builds are consistent.
> BJAM_BUILD+=    <define>BOOST_WAVE_SEPARATE_GRAMMAR_INSTANTIATION=0

This really ought to be built into the library's usage-requirements,
shouldn't it?

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com