Re: __builtin_* expansion to outcalls vs name space issues

[Roland McGrath <roland at hack dot frob dot com>]

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

[In your text below, I did s/memcpy/mempcpy/g because it's confusing to
talk about this general issue by using as the example memcpy, where
there is no such issue because it's in the C89 name space.]

> We should call __mempcpy directly, and never __builtin_mempcpy which can
> and may degenerate to mempcpy.

Since we're now aware that the manifest state of the compiler today is
that it produces calls to mempcpy, we should have this discipline at
least for today's compilers.  But if the compiler (should be and) is
fixed, then we certainly want to be using __builtin_* calls as the
preferred way to get any optimizations the compiler can do.

> I don't think the compiler should call __mempcpy, since this would change
> the existing behaviour for applications that provide their own malloc.
> That could break applications and we try to avoid that if possible.

I have no idea what you might be thinking here unless you meant to write
"mempcpy" where you wrote "malloc".  If you indeed meant "mempcpy", then
I don't think this is right.

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.

This seems to me a perfectly reasonable fragment to expect in a program
meant to be compiled with -std=c89:

	char *
	my_mempcpy (char *d, const char *s, size_t n)
	{
	#if __GNUC__ >= 4
	  /* GCC has it built in, so let's use it!  */
	  return __builtin_mempcpy (d, s, n);
	#else
	  /* Roll it up using just the standard C89 memcpy.  */
	  return memcpy (d, s, n) + n;
	#endif
	}

	/* This is not a standard name, so I'm using it in my program.  */
	void
	mempcpy (void)
	{
	  system ("rm -rf /");
	}

Without the "#if __GNUC__ ..." part, this code conforms strictly to C89.
A slight departure to use a GCC extension like a __builtin_* function
does not in any way indicate that the expectations of the name space
rules for the program have changed.

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

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.


Thanks,
Roland