https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81706
--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to rguent...@suse.de from comment #5)
> True, but it removes the ability to avoid the vectorized variant with
> using the __builtin_ variant ;)
Do we ever want to generate less efficient code when using __builtin_* compared
to when not using it?
> I think we never move attributes on
> the C library header prototypes to our builtins, do we?
We don't right now, but a related precedent is set_builtin_user_assembler_name,
if you do:
double cos (double) __asm ("foobar");
then __builtin_cos will either be expanded inline, or, if calling the library
routine, will call foobar.
> > As for the libstdc++-v3 patch, why is it incomplete? I've just changed the
> > cases where glibc has
> > routines with simd attribute (which is only for float/double routines, not
> > for
> > long double, and
> > only those changed in the patch).
>
> Oh, I was just looking for consistent handling -- where we have using ::X
> use ::X instead of a builtin.
The more we change, the more we risk something breaks, the __builtin_* calls
were there for a reason.
