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)
