This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug c/47533] [m68k] stack corruption with -Os (probably due to tail call optimisation)
- From: "tg at mirbsd dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Sat, 29 Jan 2011 17:39:56 +0000
- Subject: [Bug c/47533] [m68k] stack corruption with -Os (probably due to tail call optimisation)
- Auto-submitted: auto-generated
- References: <bug-47533-4@http.gcc.gnu.org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47533
--- Comment #3 from Thorsten Glaser <tg at mirbsd dot org> 2011-01-29 17:39:42 UTC ---
> You don't really say what the error is. Is it that the number after got2
> differs from the one after got1?
Yes, itâs a local variable of foo() and bar() and thus not supposed to be
overwritten by baz()
> Can you rewrite the test case so that it does
> a runtime check and an exit(1) or similar if the error is detected?
Sure. Butâ
> Looking in klibc-1.5.21 I see that the published prototype for open() is:
>
> __extern int open(const char *, int, ...);
>
> This looks fine, but the actual definition (which deliberately doesn't see the
> above prototype) is:
>
> int open(const char *pathname, int flags, mode_t mode)
> { ... }
>
> This is invalid C, and very sloppy programming.
â if this is the case (is it? I seem to think *everyone* handles open()
this way), then itâs not a bug in gcc (I think) but in klibc.