[Bug c/14062] New: noreturn attribute generates warning "function does return", still creates epilogue code

["csirac2 at yahoo dot com dot au" <gcc-bugzilla@gcc.gnu.org>]

This report is in relation to bug "c/3764: Gcc incorrectly complains that a
noreturn function returns".

The author of that bug report was met with "fix: don't use noreturn" or "make an
infinite loop to trick the compiler".

Whilst these two suggestions are perhaps workable with the majority of
developers, they ignore one important thing: redundant code is still generated
that wastes space.

This is frustrating for those working with cross-compilers trying to save every
byte possible on an MCU target with limited ROM space.

Consider the following code:

--- FILE: test.c ---
	#include <stdio.h>
	
	void init() __attribute__ ((noreturn));
	
	void run(void)
	{	/* .. the run loop runs forever .. */
		for (;;) puts(".");
	}
	
	void init(void)
	{	/*.. init stuff .. */
		run();	/* ... actually I use ASM to JMP to run() in my RTOS code  */
	}	/* <- test.c:13: warning: `noreturn' function does return */
	
	int main(void)	/* ... actually, there is no main() in my RTOS code */
	{
		init();
	}
--- FILE: test.c ---

Then consider the following bash session:

	csirac@singularity-0:~/Projects/test$ gcc -Wall -save-temps -g test.c
	test.c: In function `init':
	test.c:13: warning: `noreturn' function does return
	csirac@singularity-0:~/Projects/test$ objdump -SCrd a.out > a.asm
	csirac@singularity-0:~/Projects/test$ l
	total 96
	-rw-r--r--    1 csirac   csirac      11802 Feb  7 20:23 a.asm
	-rwxr-xr-x    1 csirac   csirac      15804 Feb  7 20:23 a.out*
	-rw-r--r--    1 csirac   csirac        280 Feb  7 20:15 test.c
	-rw-r--r--    1 csirac   csirac      17262 Feb  7 20:23 test.i
	-rw-r--r--    1 csirac   csirac       9396 Feb  7 20:23 test.o
	-rw-r--r--    1 csirac   csirac      32416 Feb  7 20:23 test.s
	csirac@singularity-0:~/Projects/test$ 

I can ignore warnings, but the noreturn function is still generating epilogue
ASM despite the noreturn attribute.

A quick look at a.asm created in the above bash session demonstrates this.
Here's an excerpt:

--- SNIP from FILE: a.asm ---
	void init(void)
	{       /*.. init stuff .. */
	 8048379:       55                      push   %ebp
	 804837a:       89 e5                   mov    %esp,%ebp
	 804837c:       83 ec 08                sub    $0x8,%esp
			run();
	 804837f:       e8 e0 ff ff ff          call   8048364 <run>
	}       /* <- test.c:13: warning: `noreturn' function does return */
	 8048384:       c9                      leave
	 8048385:       c3                      ret
--- SNIP from FILE: a.asm ---

Although the return ASM in the above example is just 2 bytes, the code generated
for the m68hc12 target consumes 8 bytes.
	
I can see why the G/CC developers would be against having the compiler behave in
the way that I would prefer. Admittedly, the areas where I need noreturn to work
"as advertised" are quite ugly and spaghetti-ish in nature but then again so is
a lot of microcontroller code.

If it is not possible to have noreturn actually inhibit the generation of
epilogue code by default, then can we add a compiler option or perhaps a whole
new attribute.
	
Actually, at
http://www.avr1.org/pipermail/avr-gcc-list/2002-February/001449.html one can
find a post by Kang Tin LAI who has created a patch (working with the AVR  MCU
target) that does just this (adds a new attribute).

I know I know... you guys will probably tell me to "fix it yourself", but until
I do, I just thought I'd make some noise and point out a legitimate concern with
the current behaviour of noreturn.
	
And no, JMPing around the place like an old C64 basic program is not pretty, but
it is sometimes necessary. Currently my only work-around is to merge my "init()"
and "run()" loops (it isn't really what I have but this example demonstrates the
point).

- Paul

-- 
           Summary: noreturn attribute generates warning "function does
                    return", still creates epilogue code
           Product: gcc
           Version: 3.2.3
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: c
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: csirac2 at yahoo dot com dot au
                CC: gcc-bugs at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14062