Re: [PATCH 0/4] -ffreestanding/-fno-builtin-* patches

["Dávid Bolvanský" <david.bolvansky@gmail.com>]

So -fno-builtin-stpcpy is not ideal solution then.. gcc may implement this opt too and here we go again, red builds.

We should either provide stpcpy implementation or fix few places and do not use sprintf there.

> Dňa 18. 8. 2020 o 23:41 užívateľ Arvind Sankar <nivedita@alum.mit.edu> napísal:
> 
> On Tue, Aug 18, 2020 at 01:58:51PM -0700, Nick Desaulniers wrote:
>>> On Tue, Aug 18, 2020 at 1:27 PM Nick Desaulniers
>>> <ndesaulniers@google.com> wrote:
>>> 
>>> On Tue, Aug 18, 2020 at 1:24 PM Arvind Sankar <nivedita@alum.mit.edu> wrote:
>>>> 
>>>> On Tue, Aug 18, 2020 at 12:13:22PM -0700, Linus Torvalds wrote:
>>>>> On Tue, Aug 18, 2020 at 12:03 PM H. Peter Anvin <hpa@zytor.com> wrote:
>>>>>> 
>>>>>> I'm not saying "change the semantics", nor am I saying that playing
>>>>>> whack-a-mole *for a limited time* is unreasonable. But I would like to go back
>>>>>> to the compiler authors and get them to implement such a #pragma: "this
>>>>>> freestanding implementation *does* support *this specific library function*,
>>>>>> and you are free to call it."
>>>>> 
>>>>> I'd much rather just see the library functions as builtins that always
>>>>> do the right thing (with the fallback being "just call the standard
>>>>> function").
>>>>> 
>>>>> IOW, there's nothing wrong with -ffreestanding if you then also have
>>>>> __builtin_memcpy() etc, and they do the sane compiler optimizations
>>>>> for memcpy().
>>>>> 
>>>>> What we want to avoid is the compiler making *assumptions* based on
>>>>> standard names, because we may implement some of those things
>>>>> differently.
>>>>> 
>>>> 
>>>> -ffreestanding as it stands today does have __builtin_memcpy and
>>>> friends. But you need to then use #define memcpy __builtin_memcpy etc,
>>>> which is messy and also doesn't fully express what you want. #pragma, or
>>>> even just allowing -fbuiltin-foo options would be useful.
>> 
>> I do really like the idea of -fbuiltin-foo.  For example, you'd specify:
>> 
>> -ffreestanding -fbuiltin-bcmp
>> 
>> as an example. `-ffreestanding` would opt you out of ALL libcall
>> optimizations, `-fbuiltin-bcmp` would then opt you back in to
>> transforms that produce bcmp.  That way you're informing the compiler
>> more precisely about the environment you'd be targeting.  It feels
>> symmetric to existing `-fno-` flags (clang makes -f vs -fno- pretty
>> easy when there is such symmetry).  And it's already convention that
>> if you specify multiple conflicting compiler flags, then the latter
>> one specified "wins."  In that sense, turning back on specific
>> libcalls after disabling the rest looks more ergonomic to me.
>> 
>> Maybe Eli or David have thoughts on why that may or may not be as
>> ergonomic or possible to implement as I imagine?
>> 
> 
> Note that -fno-builtin-foo seems to mean slightly different things in
> clang and gcc. From experimentation, clang will neither optimize a call
> to foo, nor perform an optimization that introduces a call to foo. gcc
> will avoid optimizing calls to foo, but it can still generate new calls
> to foo while optimizing something else. Which means that
> -fno-builtin-{bcmp,stpcpy} only solves things for clang, not gcc. It's
> just that gcc doesn't seem to have implemented those optimizations.