Hi Mike,
On Wed, Jul 12, 2017 at 11:38:11AM -0400, Michael Meissner wrote:
> I also changed the current warning in target_clones handling to be an error
> instead of a warning, since it really makes no sense to use target_clones if
> we
> can't generate a resolver function.
Okay. Another option is to then always use the default, but this
certainly is easier; let's hope we can get away with it.
> (rs6000_get_function_versions_dispatcher): Change the warnging
Typo.
> --- gcc/config/rs6000/rs6000-c.c
> (.../svn+ssh://meiss...@gcc.gnu.org/svn/gcc/trunk/gcc/config/rs6000)
> (revision 250063)
> +++ gcc/config/rs6000/rs6000-c.c (.../gcc/config/rs6000) (working copy)
> @@ -644,6 +644,10 @@ rs6000_cpu_cpp_builtins (cpp_reader *pfi
> builtin_define ("__FLOAT128_HARDWARE__");
> if (TARGET_LONG_DOUBLE_128 && FLOAT128_IBM_P (TFmode))
> builtin_define ("__ibm128=long double");
> +#ifdef TARGET_LIBC_PROVIDES_HWCAP_IN_TCB
> + builtin_define ("__BUILTIN_CPU_SUPPORTS__");
> + builtin_define ("__BUILTIN_CPU_IS__");
> +#endif
Is it useful to have two defines? They always are enabled at the same
time afaics? Thinking of a good name isn't so easy of course, but maybe
just __BUILTIN_CPU_SUPPORTS__ is fine always.
Or do other architectures already have both?
> +The @code{__builtin_cpu_is} function requires GLIBC 2.23 or newer in
> +order to export the hardware capability bits. The
> +@code{__builtin_cpu_is} function will return 0 if the compiler was
> +configured for an earlier GCC. GCC defines the macro
> +@code{__BUILTIN_CPU_IS__} if you can use the @code{__builtin_cpu_is}
> +built-in function.
"if you can use it" is not very clear (the line before you said you
always can use it, it just returns 0).
Okay for trunk and 7 with those things taken care of. Thanks!
Segher
