http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29776
--- Comment #14 from Marc Glisse <glisse at gcc dot gnu.org> --- (In reply to Jakub Jelinek from comment #12) > Not all CPUs that have defined behavior for 0 define it to the precision > though, and even on i?86 it is undefined even when using lzcnt/tzcnt on > older CPUs. > Even the libgcc routines provide various return values for 0 depending on > target (look for COUNT_LEADING_ZEROS_0). > So it is not an option to redefine the builtins, they are undefined behavior > for 0 and that can't change. I didn't mean to document the value for 0 or have other optimizations create calls to this builtin relying on this property. I just meant that if we already have a call to clz and the argument happens to be 0 (which is undefined), we could optimize based on the assumption that the result is the precision, that may break less code than your current patch. Otherwise we might as well assert (well, tell it to VRP) that the argument is non-zero. But you are probably right that trying to work around the undefined value for 0 is wrong, another builtin should be used instead. > There is __builtin_ffs that provides defined behavior for 0. So, should that be used for the x86 and power intrinsics? Or a new __builtin_clz0?
