[Bug target/29776] result of ffs/clz/ctz/popcount/parity are already sign-extended

["jakub at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29776

--- Comment #16 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Defining the value at this point would mean that we'd need to generate
slower/larger code on various targets (including i386/x86_64 when not
targetting the really most recent CPUs only) and possibly create new libgcc
entrypoints, at least for targets where the current library routine doesn't
return the value that would be newly defined.  That would slow down users that
know they aren't passing 0 to the builtins (all correct ones).
If you want builtins with defined behavior for 0, the only way is to add new
ones, but the question is what the return value should be for 0.
Or __builtin_ffs can be used, but that is 0 for 0 and otherwise 1 +
__builtin_ctz, so if you wanted ctz from that, you'd subtract one, which would
imply that for 0 this ctz variant would return -1.

BTW, the patch broke regtest on x86_64, because libgcc contained code like:
void foo (__int128_t u)
{
  if ((long long) u == u)
    return something;
  long long hi = u >> 64;
  if (hi < 0)
    hi = -hi;
  int count = __builtin_clzll (hi);
  if (count == 0)
    return somethingelse;
  ...
}

VRP figured out that count can't be 0 in a valid program (which is true), so I
had to fix it up to do hi = -(unsigned long long) hi; so that it doesn't
trigger undefined behavior for the minimum value of u.