[Bug libstdc++/81706] std::sin vectorization bug

[rguenther at suse dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81706

--- Comment #7 from rguenther at suse dot de <rguenther at suse dot de> ---
On Fri, 4 Aug 2017, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81706
> 
> --- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> (In reply to rguenther@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?

No idea ;)  The simd clone attribute looks like a library implementation
thing and using __builtin_sin doesn't end up using a libraries inline
wrapper called sin () either.

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

I see, that's definitely interesting.  But it won't end up as the
extern inline cos if the library provides one.

Also should __builtin_sin () behavior depend on whether you include
math.h or not?  I think not.

That said, I have no very strong opinion here so you can propose this
to the ml if you like.

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

Sure, but we have to keep matching glibc or other libcs providing 
vectorized variants then and adjust libstdc++ (of past releases?)?