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 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? 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?)?
