[utility] operators_test/gcc-3.4.5/64 bit
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? Thanks, Volodya
Vladimir Prus wrote:
Hi, the above test fails with ICE:
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? Regards, Daniel
Daniel Frey <d.frey@gmx.de> writes:
Vladimir Prus wrote:
Hi, the above test fails with ICE:
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?
I do. It'll be a few days before I can make it useful for testing, though. -- Dave Abrahams Boost Consulting www.boost-consulting.com
Daniel Frey wrote:
Vladimir Prus wrote:
Hi, the above test fails with ICE:
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. Regards, m Send instant messages to your online friends http://au.messenger.yahoo.com
Martin Wille wrote:
Daniel Frey wrote:
Vladimir Prus wrote:
Hi, the above test fails with ICE:
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? Regards, m Send instant messages to your online friends http://au.messenger.yahoo.com
On 8/23/06, Martin Wille <mw8329@yahoo.com.au> wrote:
Martin Wille wrote:
Daniel Frey wrote:
Vladimir Prus wrote:
Hi, the above test fails with ICE:
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 -- Julio M. Merino Vidal <jmmv84@gmail.com> The Julipedia - http://julipedia.blogspot.com/
"Julio M. Merino Vidal" <jmmv84@gmail.com> writes:
On 8/23/06, Martin Wille <mw8329@yahoo.com.au> wrote:
Martin Wille wrote:
Daniel Frey wrote:
Vladimir Prus wrote:
Hi, the above test fails with ICE:
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
participants (5)
-
Daniel Frey -
David Abrahams -
Julio M. Merino Vidal -
Martin Wille -
Vladimir Prus