[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnucap-devel] Build failure with version 2007-08-20
From: |
al davis |
Subject: |
Re: [Gnucap-devel] Build failure with version 2007-08-20 |
Date: |
Tue, 25 Sep 2007 02:18:04 -0400 |
User-agent: |
KMail/1.9.7 |
On Friday 21 September 2007, David Fang wrote:
> Hi,
> I'm getting a different (?) issue with
> powerpc-apple-darwin8-gcc-3.3 where a few generated model
> files (d_mos5, d_mos8) crash the compiler with:
I think you mean d_mos7 and d_mos8, but that's ok.
> cc1plus(1685) malloc: *** vm_allocate(size=2210779136) failed
> (error code=3)
> cc1plus(1685) malloc: *** error: can't allocate region
> cc1plus(1685) malloc: *** set a breakpoint in szone_error to
> debug
>
> The culprit seems to be the massive switch-case statements in
> MODEL::set_param_by_index(...) and friends. Does this occur
> on other gcc-3.3's, or is it just Apple's? (I'll hunt around
> for other gcc-3.3s..) Might it be posssible to convert this
> to a function table?
Mine just crashes, giving no clue, after consuming all virtual
memory.
When I compile with "-O0" it works.
(That's minus Oh Zero, which turns optimization off.)
There is a significant run time speed penalty for doing this, so
it is probably best to turn optimization off only for these two
files.
Another possibility is to leave them out of the core, and
compile them as plugins instead (with optimization off)
> > any conclusions on this? Unfortunately most of the
> > computers I use have gcc-3.2 or gcc-3.3.
>
> If I can get it to compile, what needs to be done to
> reproduce the stack-overflow? (Test case +instructions?)
It's a compiler bug.
That section will probably change significantly before the
stable release. I don't like using a switch that way.
It is a hack to make something that isn't an array look like an
array. I will probably change it so it is a real array, or at
least can be indexed like an array.
> IMHO, gcc-3.3 is still a good compiler to support, but I
> personally draw the line at 3.2 because of C++ front-end bugs
> I've encountered.
This snapshot exposed two compiler bugs that resulted in a build
failure. There is also a linker compatibility issue. .. 3.3
(and 3.4) is not compatible with gnu ld 2.17 or 2.18. It fails
to properly resolve template duplicates.
I am not sure where to draw the line. The bug Stuart reported
has an easy work-around that doesn't mess things up. You can
work around the optimizer stack overflow by disabling
optimization. I don't know if this will be a problem in the
future or not.
This version of the optimizer bug just surfaced with the changes
to support language plugins. When 3.3 was current, there was a
different optimizer overflow bug that showed in the BSIM parse
functions. I'm willing to accept compling with optimization
off for this one. These files will be moved to plugins before
the next stable release, so it can be configured so only those
plugins need to have the optimizer off.
Can you compile the optional plugins with 3.3? The "BSIM-4"
group?