http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59219
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|WAITING |NEW
--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Martin Sebor from comment #4)
> I understand. The current semantics of __builtin__xxx_chk are to:
>
> a) check the constraints of the xxx function at compile time, and
> b) diagnose constraint violations detected in (a) and call __xxx_chk, or
> c) expand xxx inline if constraints are satisfied
c) isn't correct - the rule is that __xxx_chk is either expanded to
a call to __builtin_xxx or to a call to __xxx_chk.
__builtin_xxx is then either expanded inline or as a call to xxx
dependent on cost and flags.
> I'm suggesting that it would be useful to change the semantics in (c):
>
> c) if constraints are satisfied, then if -fbuiltin is used, expand xxx
> inline, or
> d) if -fno-builtin is used, call xxx
I think you are asking that __builtin_xxx_chk should expand to
__xxx_chk or xxx (instead of __builtin_xxx).
> I.e., reduce the effects of the __builtin__xxx_chk intrinsics to just
> checking the constraints, and (when -fno-builtin is used) make it possible
> to customize the implementation within those constraints.
>
> This would let freestanding implementations use the __builtin__xxx_chk
> intrinsics and also provide their own semantics for the xxx functions within
> the constraints specified by the language.
A target independent flag that controls inline expansion of xxx would be
more useful I think. You can use -mstringop-strategy=libcall on x86.
> (PS I belatedly realized that my mention of a freestanding sprintf using '$'
> to introduce a freestanding format directive didn't make sense as it would
> violate the function's constraint. Please diregard that part.)
