Re: [Gnucap-devel] Build failure with version 2007-08-20

[al davis]

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?