Re: Patch to add new target macro: TARGET_WARN_RETURN_TYPE

[Nick Clifton <nickc at cygnus dot com>]

Hi Jeff, Hi Craig,

  >   I think I may have to abandon this patch.  I have been trying to
  > think of an alternative way of solving the problem, other than
  > creating the NAKED_FUNCTION_P macro.  The attribute idea:
  > 
  >   asm (<return from function call>) __attribute__((return));
  > 
  > or the type qualifier idea:
  > 
  >   asm return (<return from function call>);
  >

: If an asm sets the return value for a function, then it must be
: using a register class with a size of one register (how else can you
: guarantee what register you get).

Is this necessary ?  I thought you could do it using clobbered
registers, eg:

	   asm ("mov r0, #0" ::: "r0");

(assuming that r0 is the return register).

: Since you know what register it will get, you can determine if that
: register is a function return value via FUNCTION_VALUE_REGNO_P.
: 
: Seems to me we don't need an attribute to do this stuff. 

However you are right in that there really isn't a problem with
computing return values.  If a programmer wants to do this using asms
they can always assign the result of the computation to a variable and
then just append an ordinary return statement using that variable, eg:

   int foo (void)
   {
     int result;

      asm ("mov %0, #0" : "=r" (result));
      return result;
   }

So in fact there is no real need to have an attribute to label an asm
as generating a return value.

The problem I was trying to solve was the case where naked functions
are supported.  In this case using a return statement is invalid,
because the compiler is not allowed to generate the function's
epilogue.  Instead it is up to the programmer to do this.  What I
was thinking of doing was providing a way of marking a particular asm
as being a return asm, so that GCC's jump code would insert a barrier
after the asm, which in turn would stop GCC from thinking that the
code just falls off the end of the function.  (And would also
presumably allow flow anaylsis and other passes to correctly interpret
program flow control).

Doing this however seemed like too much feature add, especially since
naked functions are not a generic feature, so I abandoned the idea.
Of course if there is ever a real demand for this kind of thing in the
future then these ideas can be ressurrected.

Cheers
	Nick