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? _______________________________________________ Gnucap-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnucap-devel
