[Bug c/96550] New: gcc is smart in figuring out a non-returning function.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96550
Bug ID: 96550
Summary: gcc is smart in figuring out a non-returning function.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: R.E.Wolff at BitWizard dot nl
Target Milestone: ---
This is the small probgram that reproduces this:
---
#include
#define FAIL
struct test {
#ifdef FAIL
char *t;
#else
char t[8];
#endif
} ;
extern void somefunc (struct test *t);
void myfunc (void)
{
struct test mt;
memset (&mt, 0, sizeof (mt));
mt.t[0] = 1;
somefunc (&mt);
}
---
Here the struct was defined in another part of the code, and I'd guessed
(wrong) that the declaration was like in the FALSE branch of the IFDEF. As it
turns out the declaration was different.
So what happens is that the compiler decides that I set the pointer to zero,
and that the assignment through that pointer WILL fail.
So the generated assembly starts with:
---
myfunc:
@ Function supports interworking.
@ Volatile: function does not return.
---
So... without saying anything the compiler decided that my function will never
return. It might be right about that (That's not true: This is on an embedded
system and I can map RAM to address zero!) but then IMHO, a warning would be
warranted. A function goes from not being declared volatile by me to being
volatile (not returning).
It's perfectly legal C code in there, but might not be what the user wanted
Just like if (a = 3) ... I think a warning might be issued.
Reproduced on: gcc (Raspbian 6.3.0-18+rpi1+deb9u1) 6.3.0 20170516
not reproduced on: gcc (Ubuntu 5.4.0-6ubuntu1~16.04.12) 5.4.0 20160609
reproduced on (originally ran into): arm-none-eabi-gcc (GNU Arm Embedded
Toolchain 9-2020-q2-update) 9.3.1 20200408 (release)
[Bug c/96550] gcc is smart in figuring out a non-returning function.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96550 --- Comment #5 from Roger Wolff --- Guys, The compiler found a bug in my code, but it didn't tell me. Like the if (a = 3) situation, the compiler is correct when it compiles the code according to the C rules. I like to compile my code with -Wall for this reason: 99% of the cases, the compiler will find and warn about stupid stuff that's not a problem. But in that 1% of the cases, the compiler will warn about something that's a bug that would've taken lots of time to find. SO when you get that one warning, you have the compiler telling you: You have a bug on line X of your program. That's what could've happened here: I had a bug in my code, but didn't expect the binary to suddenly go from 75k to 14k because of a bug. Something like: Line 18: dereferencing NULL pointer is undefined behaviour. Assuming execution stops here. would be a usable error message. This is actually one of those 1% of the cases where the warning COULD have been given and finding the bug would've been seconds whereas without the warning lots of time was wasted looking for the bug in the wrong places. This is not a bug per se, you can suggest workarounds for: "What if you want to store stuff at address zero" all you want, but I had a bug and I've asked gcc to issue warnings where I'm doing fishy stuff that might be a bug. And I didn't get that warning. So this issue is not a bug in that the wrong code is generated, but an enhancement request: Please issue that warning. All this is "not for me": I've now run into this issue, the bug in my project has been fixed and for me it's on to the rest of the code. And I've been subjected to this "way of gcc telling me there is a bug", so in the future, if I make this mistake again, I'll not spend as much time on it as I did this weekend. So I'm trying to make things easier for those others that might run into this in the future.
[Bug c/96550] gcc is smart in figuring out a non-returning function.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96550 --- Comment #6 from Roger Wolff --- So, I've added "-Wall" to my Makefile to get ALL warnings, giving me the biggest chance of finding bugs through the compiler telling me you have a bug on line X of file Y. So IMHO -Wnull-dereference should be part of -Wall. I'm not a compiler guy. I just use the stuff. So now the question becomes: Why is that warning not part of -Wall ?
[Bug c/96550] gcc is smart in figuring out a non-returning function.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96550 --- Comment #8 from Roger Wolff --- Please, start to read what is written. Please.
[Bug c/96554] New: -Wall does not include -Wnull-dereference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96554 Bug ID: 96554 Summary: -Wall does not include -Wnull-dereference Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: R.E.Wolff at BitWizard dot nl Target Milestone: --- As reported in c/96550, the fact that -Wall didn't include -Wnull-dereference cost me a lot of time in trying to figure out what the problem was with my code. I add -Wall to get lots of warnings about potential bugs. if (a = 3) is an example where a simple typo in the code leads to perfectly valid C, but such a "high likelyhood of a bug" that a warning is warranted. Same here: I wrote a bug that caused the compiler to a) not warn me and b) do unexpected things. I think the -Wnull-dreference is a valid warning to enable with -Wall.
[Bug c/96550] gcc is smart in figuring out a non-returning function.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96550 --- Comment #10 from Roger Wolff --- Technically correct.
[Bug c/96550] gcc is smart in figuring out a non-returning function.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96550 --- Comment #11 from Roger Wolff --- Just FYI: I added -Wnull-dereference to my makefile of my real project. It doesn't trigger a warning in my project when I revert to the buggy code. The compiler does detect and act upon the null dereference.
[Bug c/96550] gcc is smart in figuring out a non-returning function.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96550 Roger Wolff changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #12 from Roger Wolff --- better description in: 96554
[Bug c/96554] -Wall does not include -Wnull-dereference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96554 --- Comment #2 from Roger Wolff --- In my case it promotes a function I didn't declare as into one that and thereby it caused 80% of my code to become "dead". It'd be nice to differentiate between the case where a simple optimization removes a few lines of code due to an extra null-check not being reachable due to the trap on the null dereference and the case where big unexpected things start happening. Maybe the promotion of a function from "does return" to "does not return" is something you might warn about. This satisfies the "you can easily modify the code to silence the warning".
[Bug c/96554] -Wall does not include -Wnull-dereference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96554 --- Comment #4 from Roger Wolff --- Update: LTO messes with the warning. When LTO is enabled, the warning from -Wnull-dreference is suppressed.
[Bug c/96550] gcc is smart in figuring out a non-returning function.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96550 --- Comment #15 from Roger Wolff --- I marked it as "resolved', the system then told me to type a message and I did, but then it had added the "FIXED" tag. Not my idea.
[Bug c/96550] gcc is smart in figuring out a non-returning function.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96550 --- Comment #17 from Roger Wolff --- UI suggestion: Then start the selection box on "choose one" instead of a default that probably doesn't get used often (like everybody else).
