[Bug c/96550] New: gcc is smart in figuring out a non-returning function.

[Bug c/96550] New: gcc is smart in figuring out a non-returning function.

[R.E.Wolff at BitWizard dot nl]

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 <string.h>

#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.

[glisse at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96550

--- Comment #1 from Marc Glisse <glisse at gcc dot gnu.org> ---
Does -fno-delete-null-pointer-checks help?

[Bug c/96550] gcc is smart in figuring out a non-returning function.

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96550

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
If FAIL is defined, your myfunc will always trigger undefined behavior if
called, and as such anything can happen.
Derefencing NULL is UB.
If you are on an embedded system where there is memory mapped, you can use
-fno-delete-null-pointer-checks (for some embedded targets it is even the
default).

[Bug c/96550] gcc is smart in figuring out a non-returning function.

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96550

--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Roger Wolff from comment #0)
> 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. 

GCC *does* warn:

null.c: In function ‘myfunc’:
null.c:19:11: warning: null pointer dereference [-Wnull-dereference]
   19 |   mt.t[0] = 1;
      |   ~~~~~~~~^~~

[Bug c/96550] gcc is smart in figuring out a non-returning function.

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96550

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Version|unknown                     |9.3.1

--- Comment #4 from Jonathan Wakely <redi at gcc dot gnu.org> ---
And if you read the manual for the -Wnull-dereference warning you'll see it
also mentions -fdelete-null-pointer-checks, and if you read about that you
should find the solution you need.

[Bug c/96550] gcc is smart in figuring out a non-returning function.

[R.E.Wolff at BitWizard dot nl]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96550

--- Comment #5 from Roger Wolff <R.E.Wolff at BitWizard dot nl> ---
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.

[R.E.Wolff at BitWizard dot nl]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96550

--- Comment #6 from Roger Wolff <R.E.Wolff at BitWizard dot nl> ---
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.

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96550

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
The compiler can't diagnose this as an error (unless -Werror* is used), because
it is only an error if such code is ever called at runtime, which the compiler
can't determine at compile time.
That is why it is just a warning.
And, as an optimizing compiler, the compiler can and does optimize anything
that would be only reachable through that statement with UB.
This isn't an attempt to punish those who write broken code, but it actually
helps a lot in real-world code, something like that can happen frequently, but
usually in code that will not be actually encountered at runtime, just the
compiler can't prove that.

[Bug c/96550] gcc is smart in figuring out a non-returning function.

[R.E.Wolff at BitWizard dot nl]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96550

--- Comment #8 from Roger Wolff <R.E.Wolff at BitWizard dot nl> ---
Please, start to read what is written. Please.

[Bug c/96550] gcc is smart in figuring out a non-returning function.

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96550

--- Comment #9 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Roger Wolff from comment #6)
> So, I've added "-Wall" to my Makefile to get ALL warnings,

It doesn't enable ALL warnings, as documented in the manual.

[Bug c/96550] gcc is smart in figuring out a non-returning function.

[R.E.Wolff at BitWizard dot nl]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96550

--- Comment #10 from Roger Wolff <R.E.Wolff at BitWizard dot nl> ---
Technically correct.

[Bug c/96550] gcc is smart in figuring out a non-returning function.

[R.E.Wolff at BitWizard dot nl]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96550

--- Comment #11 from Roger Wolff <R.E.Wolff at BitWizard dot nl> ---
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.

[R.E.Wolff at BitWizard dot nl]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96550

Roger Wolff <R.E.Wolff at BitWizard dot nl> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |FIXED

--- Comment #12 from Roger Wolff <R.E.Wolff at BitWizard dot nl> ---
better description in: 96554

[Bug c/96550] gcc is smart in figuring out a non-returning function.

[schwab@linux-m68k.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96550

Andreas Schwab <schwab@linux-m68k.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|FIXED                       |DUPLICATE

--- Comment #13 from Andreas Schwab <schwab@linux-m68k.org> ---


*** This bug has been marked as a duplicate of bug 96554 ***

[Bug c/96550] gcc is smart in figuring out a non-returning function.

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96550

--- Comment #14 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Roger Wolff from comment #11)
> 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.

It will only warn when optimisations are performed, including the
-fdelete-null-pointer-checks optimisation. I would expect it to either not act
on the null dereference, or act and warn.

Please don't change status to FIXED when nothing was changed in GCC, let alone
fixed.

[Bug c/96550] gcc is smart in figuring out a non-returning function.

[R.E.Wolff at BitWizard dot nl]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96550

--- Comment #15 from Roger Wolff <R.E.Wolff at BitWizard dot nl> ---
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.

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96550

--- Comment #16 from Jonathan Wakely <redi at gcc dot gnu.org> ---
When you choose RESOLVED you can pick various types of resolution, FIXED,
INVALID, DUPLICATE, MOVED, WORKSFORME etc.

[Bug c/96550] gcc is smart in figuring out a non-returning function.

[R.E.Wolff at BitWizard dot nl]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96550

--- Comment #17 from Roger Wolff <R.E.Wolff at BitWizard dot nl> ---
UI suggestion: Then start the selection box on "choose one" instead of a
default that probably doesn't get used often (like everybody else).