This is the mail archive of the
mailing list for the GCC project.
Re: Patch to add new target macro: TARGET_WARN_RETURN_TYPE
- To: nickc at cygnus dot com
- Subject: Re: Patch to add new target macro: TARGET_WARN_RETURN_TYPE
- From: craig at jcb-sc dot com
- Date: 19 Mar 1999 21:51:39 -0000
- Cc: egcs-patches at cygnus dot com
- Cc: craig at jcb-sc dot com
- References: <199903191750.JAA21167@elmo.cygnus.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
> #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
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
&& ! NAKED_ATTRIBUTE_P (fn)
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)