[Bug soft-fp/7006] Bad left shift in _FP_FRAC_SRS_2 macro in soft-fp/op-2.h on SH-4

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

http://sourceware.org/bugzilla/show_bug.cgi?id=7006

--- Comment #3 from Joseph Myers <jsm28 at gcc dot gnu.org> ---
Indeed, I don't actually see how the _SRS macros can be called with a shift
count of 0.  In the interest of efficiency, I'm inclined to say we should
define the interfaces to all the shift macros to require a shift count that is
strictly positive and strictly less than the total number of bits in the given
number of words, then review all shift counts for cases that might violate
this; I expect checking for 0 at any rare call sites where it might occur will
be more efficient than making these macros handle the case of 0.

In one such review attempt, I can see the use of *left* shift for converting
integers to floating point may shift by 0.  The following testcase illustrates
that on x86_64 for conversion from unsigned __int128 to __float128 (soft-fp as
used in libgcc):

#include <stdlib.h>

#ifdef COMPILE_TIME
# define VOL /* Empty.  */
#else
# define VOL volatile
#endif

int
main (void)
{
  VOL unsigned long long a = 0x1000000000000ULL;
  VOL unsigned long long b = 0xffffffffffffffffULL;
  unsigned __int128 c = (((unsigned __int128) a) << 64) | b;
  __float128 d = c;
  if (d != 0x1.000000000000ffffffffffffffffp112q)
    abort ();
  exit (0);
}

If you define COMPILE_TIME and build with optimization, the test passes as the
conversion is done at compile time; otherwise, it is done at runtime and a
right-shift by 64 in _FP_FRAC_SLL_2 called to shift left by 0 results in an
incorrect result.

-- 
You are receiving this mail because:
You are on the CC list for the bug.