On Friday 18 July 2003 11:49, Matthias Urlichs wrote: > I have looked at this Debian bug (http://bugs.debian.org/195364). The > problem seems to be at line 599 of gforth's engine/main.c, which states > > pi->length = symbols1[i+1]-symbols1[i]; > > symbols[] is an array of consecutive(?) label addresses, and GCC 3.3 > happily inverts their order when compiling engine/engine.c(prim.i). Thus > the length ends up being negative, and the next memcpy() which uses it > (in append_prim()) causes a segfault. > > The proper solution seems to be not to copy the built-in functions in the > first place. I wonder why that is done -- I consider that to be rather > dangerous if the compiler happens to do CSE or similar optimizations.
Start gforth with the option --no-dynamic. Actually, there was a configure option to change the dynamic superinstruction generation default setting, but since it worked well with GCC 3.2, *and* we force GCSE off with -fno-gcse, we didn't worry about that. The more "elaborate" optimizations in GCC they added lately causes us quite some grief. Most of them are pessimizations for Gforth, and the GCC maintainer don't seem to bother adding a "turn it off" switch. *Especially* more elaborated options have to be turned off here or there, and usually I'd expect it to be off at -O2, anyway. A lot of really useful stuff (e.g. -fomit-frame-pointer) is off by default. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://www.jwdt.com/~paysan/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
