C undefined behavior fix

It is even worse (gcc 2.95.4 20011223 (Debian prerelease), i386). Test code:

#include <string.h>
char* dst;
void main(void) {
strcpy(dst, "test"+CONSTANT);
}

# gcc -O2 -S test.c -DCONSTANT=10
test.c: In function `main':
test.c:4: warning: offset outside bounds of constant string
...
and compiler generated correct code (call to strcpy with "test"+10).

But:

# gcc -O2 -S test.c -DCONSTANT=0x80000000
test.c: In function `main':
test.c:4: warning: offset outside bounds of constant string
gcc: Internal compiler error: program cc1 got fatal signal 11

(and for CONSTANT < 5 it of course generated correct code to fill dst with string contents; and yes, I know that code will sigsegv on run because of dst is not initialized - but it should die at runtime, not at compile time).

So we should definitely change RELOC(), or sooner or later gcc will die on such code :-(

Debian's gcc 3.0.3-1 generates:
0 <= CONSTANT <= 4: fills dst directly with constant
5 <= CONSTANT <= 0x7FFFFFFF: emit warnings + use strcpy() 0x80000000U <= CONSTANT <= 0xFFFFFFFFU: use strcpy() silently ... and it does not die.
Best regards,
Petr Vandrovec [email protected]

An ICE, while it's not quite what was expected and it'll probably get fixed, is nonetheless a perfectly valid implementation of 'undefined behaviour'. You should count yourself lucky that the compiler didn't beat you up, sleep with your mother, and/or start WW III.

Contributors to this thread who want to write a kernel in some C-like language other than C probably ought to start by writing their own compiler, rather than complaining about gcc. (I won't suggest starting with a language spec, as the people in question don't really seem to be interested in those.)

That or implement DWIM for gcc, I suppose...

Can we fix the broken code and stop being silly now, please?

--
dwmw2

Not for GCC it isn't. Our standards say that a compiler crash, for any input whatsoever, no matter how invalid (even if you feed in line noise), is a bug. Other than that we shouldn't make promises, though the old gcc1 behavior of trying to launch a game of rogue or hack when encountering a #pragma was cute.

True - sorry, I forgot where this was crossposted. I didn't mean to imply that GCC folks would _accept_ an ICE and not fix it - just that strictly speaking, it is a perfectly valid response, as is the unintended observed behaviour of the output code which actually started this thread.

--
dwmw2

Not really. Think of code whose execution is guarded by a test that guarantees it won't invoke undefined behavior, but whose test is in a separate translation unit. Or even of code that is never executed. The compiler has no business telling whether the code may potentially invoke undefined behavior, or whether it's going to be executed at all, it has to compile it to something that does whatever it wishes *if* it's executed. So, it should indeed die at runtime, not at compile time.

Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me