Re: __builtin_* expansion to outcalls vs name space issues

["Carlos O'Donell" <carlos at redhat dot com>]

On 02/05/2013 06:46 PM, Roland McGrath wrote:
>> Can it be both our faults?
> 
> Perhaps in a "belt and suspenders" sort of sense.  That is, it's clearly
> our fault we started using __builtin_mempcpy for __mempcpy without
> realizing that it could generate calls to mempcpy.  But if it's GCC's
> fault for generating those calls for a __builtin_* function, then the
> only thing we did wrong was failing to report that GCC bug and ensure it
> was fixed before we started using __builtin_mempcpy.

Agreed. I also didn't know GCC could generate a call to the standard
function if it so chose. I would argue that doing so is a bug unless
you're in strict -std mode and that particular function is available.

> If a program uses __builtin_mempcpy, then what it expects is the exact
> semantics of the canonical mempcpy function.  If it expects anything
> different, it will be broken when the compiler inlines it to plain
> instructions or to a call to memcpy or anything else it might do.  I
> find it an utterly bizarre notion that any program would go out of its
> way to use the GCC extension __builtin_mempcpy and then expect that this
> will produce a call to its own function called "mempcpy".  But this
> seems to be what you have in mind.

That doesn't matter. What matters is that it could happen and your suggest
change breaks the existing behaviour. Which according to Joseph and the
GCC manual is the documented behaviour.

>> Lastly the compiler should not allow __builtin_mempcpy if it wouldn't
>> allow mempcpy or alternatively __builtin_mempcpy should never fall back 
>> to mempcpy if mempcpy is not allowed. This might break building your
>> application, but all you need to do is set the right flags and you're
>> OK to compile again.
> 
> Neither of these seems reasonable to me, if I'm understanding your
> suggestions.
> 
> If "not allow __builtin_mempcpy if it wouldn't allow mempcpy" made
> sense, then there would be no reason whatsoever to have the name
> "__builtin_mempcpy" ever be available.  If you're not in a strict -std=
> mode, then the compiler will inline calls that use the name "mempcpy".
> So why would you ever use "__builtin_mempcpy" instead?

I think your `will inline calls' is too strong a statement. The compiler
`may' inline calls to mempcy. In which case using `__builtin_mempcpy'
should be used to ensure you get the optimal builtin.

You and I disagree about the purpose of the builtins.

You see them as a way to access functions that the runtime doesn't
guarantee, but that the compiler will provide. 

It turns out that this isn't safe because the compiler may elide 
the builtin with a call to the real function. Which could cause a 
build failure if mempcpy didn't exist in the runtime, or worse a
runtime failure.

> I'm not entirely sure what concretely the alternate suggestion is.  It
> sounds like something in which the compiler would offer a feature
> (__builtin_mempcpy in -std=c89 mode) wherein whether it works as
> intended or breaks the build depends on the luck of optimization.  I
> would find anything meeting that description to be completely inane.

Which is why I argue that __builtin_mempcpy shouldn't be allowed
unless in -std=c89 mode to avoid the build breakage that can happen.

> What seems reasonable to me is that the availability of a feature and
> the constraints on its implementation details be orthogonal issues.
> That is, __builtin_mempcpy is available in all modes as are all GCC
> extensions with __* names and that is a completely separate subject from
> what the compiler should or should not be doing in its implementation of
> that feature.

I don't see a recommendation here for this concrete use case.

Cheers,
Carlos.