https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78037
--- Comment #13 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #11)
> Back to target because:
>
> @defmac CLZ_DEFINED_VALUE_AT_ZERO (@var{mode}, @var{value})
> @defmacx CTZ_DEFINED_VALUE_AT_ZERO (@var{mode}, @var{value})
> A C expression that indicates whether the architecture defines a value
> for @code{clz} or @code{ctz} with a zero operand.
> ...
> Note that regardless of this macro the ``definedness'' of @code{clz}
> and @code{ctz} at zero do @emph{not} extend to the builtin functions
> visible to the user. Thus one may be free to adjust the value at will
> to match the target expansion of these operations without fear of
> breaking the API@.
The problem is that on x86 clz/ctz is sometimes undefined and sometimes defined
at zero, it depends on which instruction is used and which CPU too.
If we emit bsf/bsr etc., it is undefined, if we emit tzcnt/lzcnt aka
rep;bsf/rep;bsr, it is undefined if it is run on CPUs without BMI and defined
on CPUs with BMI.
Even if we declare that code compiled with -mbmi must be only invoked on BMI
capable CPUs, the *_DEFINED_VALUE_AT_ZERO macros would need to depend on
current_function_decl attributes. Is that possible?
