Patch to add new target macro: TARGET_WARN_RETURN_TYPE

[Nick Clifton]

Hi Guys,

: Nick Clifton <nickc@cygnus.com> said:
: >   I would like to get approval for the following patch.  It adds a new
: >   target macro called 'TARGET_WARN_RETURN_TYPE' which can be used to
: >   disable the check for a non-void function returning without
: >   providing a return value.  This ability would be useful for the ARM
: >   port which supports the notion of a "naked" function whoes prologue
: >   and epilogue is left entirely up to the programmer to code.


: From: Horst von Brand <vonbrand@sleipnir.valparaiso.cl> 
: 
: I'd suggest handling this (quite special) case by some
: "attribute((naked))" or such. Your mechanism will just turn off a
: quite important warnings, unless I misread this.

I should have explained this more clearly.  The ARM port already has
a (target specific) attribute called naked.  The problem is that if
this attribute is used it is still possible to get the warning message
about a non-void funciton returning.  ie:

      int foo (void) __attribute__((naked))
      {
	/* some asm()s which include setting the return value */
      }

will produce a warning with -Wall.  I want to be able to disable this
warning *in this specific case*.  Hence my patch.  The idea is that
the ARM port would then defined TARGET_WARN_RETURN_TYPE to be a check
to see if the function has had the naked attribute applied to it.  If
it has then the warning would be disabled, otherwise it would be
allowed.  ie:

  #define TARGET_WARN_RETURN_TYPE \
   (! arm_naked_function_p (current_function_decl))


: From: craig@jcb-sc.com
: 
: How does the ARM port *do* that?  Is it a property of the CPU, the OS,
: or the library?  If not, I'm not sure I understand how it's a property
: of the *target*.  In other words, what makes the ARM target different,
: in this respect, from any other target?  Are "naked" functions impossible
: things on other processors, for example?  If not, and if all targets
: could possibly support them, suppose we *did* support them everywhere --
: then, what would this macro really do, or mean, for gcc users?

OK - there is no reason in theory why this attribute could not be
supporterd for all targets.  At the moment I only know about it being
supported for the ARM, which is why I am interested in it.  If the
attribute were made generic, then there would be no need for this new
target macro, but I am trying to avoid feeping creaturism... :-)

: Also, if the *programmer* is the one who decides to employ this
: behavior, why not make him specify it in the code (perhaps by
: something akin to an `asm' construct) or, failing that, a
: command-line option?  Disabling useful error constructs for an
: entire port, just to allow a few cases of hand-specification of
: prologue/epilogue code, seems bass-ackwards to me.

Ahh, but the point is that this patch does *not* disable the test.  It
allows targets to control the enabling of the test if they want to.
If they do not define this new target macro, then the test is enabled
just as it always has been.

: Also...
: 
: >+ @findex TARGET_WARN_RETURN_TYPE
: >+ @item TARGET_WARN_RETURN_TYPE
: >+ Define this macro if you need to control the production of warning
: >+ messages about control reaching the end of a non-void function.
: 
: ...control it *how*?  Which value means what?  It's usually a good idea
: to be specific, rather than force people to read the code that uses it.

Fair enough, how about this rewording:

  "If this macro is defined it should return non-zero if it is
   permissable to generate a warning message about a non-void function 
   returning without providing a return value.  This allows targets
   which support programmer specified epilogues to disable this
   warning in cases where it may not be appropriate."


: From: Jeffrey A Law <law@hurl.cygnus.com>
: 
: Why do we care?

I care because I have received a complaint about the current
behaviour.  The programmers involved want to be able to compile their
code with -Wall enabled and still see no warning messages.  They do
not want to just disable this warning as their code contains non-naked
functions which they do want to be tested for non-void returns. 

: I don't see that avoiding warnings for "naked" functions is all that
: important.  Just seems like creeping featurism to me.

It is not all that important at all.  I am just trying to fix this
problem in a "clean" way.  I have another fix for the problem which
involves a horrible hack with the backend overriding the value of the
'warn_return_type' variable on a per-function basis.  This patch is
really rather grungy though, so I would prefer to be able to use a
target macro if I can.

Cheers
	Nick