public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c/96550] New: gcc is smart in figuring out a non-returning function.
@ 2020-08-10 11:16 R.E.Wolff at BitWizard dot nl
  2020-08-10 11:32 ` [Bug c/96550] " glisse at gcc dot gnu.org
                   ` (16 more replies)
  0 siblings, 17 replies; 18+ messages in thread
From: R.E.Wolff at BitWizard dot nl @ 2020-08-10 11:16 UTC (permalink / raw)
  To: gcc-bugs

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)

^ permalink raw reply	[flat|nested] 18+ messages in thread
end of thread, other threads:[~2020-08-11  7:19 UTC | newest]

Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-08-10 11:16 [Bug c/96550] New: gcc is smart in figuring out a non-returning function R.E.Wolff at BitWizard dot nl
2020-08-10 11:32 ` [Bug c/96550] " glisse at gcc dot gnu.org
2020-08-10 11:33 ` jakub at gcc dot gnu.org
2020-08-10 11:38 ` redi at gcc dot gnu.org
2020-08-10 11:40 ` redi at gcc dot gnu.org
2020-08-10 11:51 ` R.E.Wolff at BitWizard dot nl
2020-08-10 11:55 ` R.E.Wolff at BitWizard dot nl
2020-08-10 11:59 ` jakub at gcc dot gnu.org
2020-08-10 12:29 ` R.E.Wolff at BitWizard dot nl
2020-08-10 12:30 ` redi at gcc dot gnu.org
2020-08-10 12:42 ` R.E.Wolff at BitWizard dot nl
2020-08-10 12:45 ` R.E.Wolff at BitWizard dot nl
2020-08-10 12:55 ` R.E.Wolff at BitWizard dot nl
2020-08-10 13:03 ` schwab@linux-m68k.org
2020-08-10 13:04 ` redi at gcc dot gnu.org
2020-08-10 13:13 ` R.E.Wolff at BitWizard dot nl
2020-08-10 16:06 ` redi at gcc dot gnu.org
2020-08-11  7:19 ` R.E.Wolff at BitWizard dot nl

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).