Re: Patch to add new target macro: TARGET_WARN_RETURN_TYPE

[craig at jcb-sc dot com]

>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))

Ah, that makes more sense.

>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... :-)

Is there already something you can test, in an target-neutral way,
to determine whether the "naked" attribute is implemented?

If so, perhaps that'd be a better test than to make up another new
macro name.

E.g. somewhere, somebody has to define `arm_naked_function_p'.  If
that "someone" also defined a macro like "NAKED_ATTRIBUTE_P(fn)" to
"arm_naked_function_p(fn)", then you could just write

...
#ifdef NAKED_ATTRIBUTE_P
    && ! NAKED_ATTRIBUTE_P (fn)
#endif

or something like that.  That'd put it less in the realm of target-
specific attributes, for good reason, IMO.  But it would still have
to be documented somewhere....

>: 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.

If never warning about naked functions is truly a property of
naked functions, I think my above suggestion is probably the best
approach for now, though in the long run naked functions should
probably be supported by all targets (or, perhaps, tossed altogether).

I do wonder, though, whether an `asm' construct or similar that
explicitly says "return whatever is already prepared" would be
a better approach, e.g. `return __asm__();' or some such thing.
I don't know enough about gcc's asm facility to be sure, but,
in general, I can see the need for such a construct.

        tq vm, (burley)