https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71078
--- Comment #7 from prathamesh3492 at gcc dot gnu.org --- (In reply to prathamesh3492 from comment #6) > (In reply to rguent...@suse.de from comment #5) > > On Thu, 4 Aug 2016, mwahab at gcc dot gnu.org wrote: > > > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71078 > > > > > > mwahab at gcc dot gnu.org changed: > > > > > > What |Removed |Added > > > ---------------------------------------------------------------------------- > > > CC| |mwahab at gcc dot gnu.org > > > > > > --- Comment #4 from mwahab at gcc dot gnu.org --- > > > (In reply to prathamesh3492 from comment #3) > > > > Fixed. > > > > > > The new test pr71078-1.c fails for arm and aarch64 because copysignl > > > isn't > > > generated for fabsl making the expected output fail to match. > > > > Is that a non-C99 target? If so add require-effective-target c99_runtime > dg-require-effective-target c99_runtime didn't work. > Apparently for long double, it is simplified to __builtin_copysign > instead of __builtin_copysignl > > Applying pattern match.pd:208, gimple-match.c:1347 > gimple_simplified to t2_3 = __builtin_copysign (1.0e+0, x_1(D)); > f3 (long double x) > { > long double t2; > long double t1; > > <bb 2>: > t1_2 = ABS_EXPR <x_1(D)>; > t2_3 = __builtin_copysign (1.0e+0, x_1(D)); > return t2_3; > > } > > Looks like for arm, long double and double are same > (sizeof (double) == sizeof (long double)). > Since we first match for the double case, > we end up simplifying to __builtin_copysign. I wonder if this is a bug in the pattern or in test-case ? If double and long double are same, then I suppose it shouldn't matter if copysign would get called for long double ? In that case, should I add following target-effective-checks to the test-case ? dg-require-effective-target large_long_double dg-require-effective-target large_double Adding /* { dg-require-effective-target large_long_double } */ to the test-case makes it unsupported on arm-linux-gnueabihf. Thanks, Prathamesh > > Thanks, > Prathamesh > > > > Richard.
