[Bug other/91730] [10 regression] r275518 causes 3 verification errors in the cpu 2006 test suite

2019-09-17 Thread tnfchris at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91730

Tamar Christina  changed:

   What|Removed |Added

 CC||tnfchris at gcc dot gnu.org

--- Comment #9 from Tamar Christina  ---
Hmm yes the transformation is too aggressive and incorrect here.

we'll fix that and resubmit a fixed patch.

[Bug other/91730] [10 regression] r275518 causes 3 verification errors in the cpu 2006 test suite

2019-09-11 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91730

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #8 from Richard Biener  ---
Reverted the patch.

[Bug other/91730] [10 regression] r275518 causes 3 verification errors in the cpu 2006 test suite

2019-09-11 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91730

--- Comment #7 from Richard Biener  ---
Note in all cases of the testcases coming with the patch the sources are
eventually casted from float to double.

[Bug other/91730] [10 regression] r275518 causes 3 verification errors in the cpu 2006 test suite

2019-09-11 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91730

--- Comment #6 from Richard Biener  ---
(In reply to Martin Liška from comment #5)
> The transformation is from:
> 
>   _663 = T1$1_55 + _293;
>   _651 = (float) _663;
> 
> where T1$1_55 and _293 are doubles. To:
> 
>   _758 = (float) T1$1_55;
>   _759 = (float) _293;
>   _760 = _758 + _759;
>   _651 = (float) _760;

OK, so thats invalid for example when T1$1_55 and _293 are FP values
that cannot be represented in 'float' but their sum can.  That's outside
of what we generally allow with -ffast-math.

It would be valid if one of T1$1_55 or _293 are already float.

[Bug other/91730] [10 regression] r275518 causes 3 verification errors in the cpu 2006 test suite

2019-09-11 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91730

--- Comment #5 from Martin Liška  ---
The transformation is from:

  _663 = T1$1_55 + _293;
  _651 = (float) _663;

where T1$1_55 and _293 are doubles. To:

  _758 = (float) T1$1_55;
  _759 = (float) _293;
  _760 = _758 + _759;
  _651 = (float) _760;

[Bug other/91730] [10 regression] r275518 causes 3 verification errors in the cpu 2006 test suite

2019-09-11 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91730

--- Comment #4 from Martin Liška  ---
Created attachment 46869
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46869=edit
Dump file without problematic transformation

[Bug other/91730] [10 regression] r275518 causes 3 verification errors in the cpu 2006 test suite

2019-09-11 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91730

--- Comment #3 from Martin Liška  ---
Created attachment 46868
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46868=edit
Dump file with problematic transformation

For the 453.povray (which fails with --size=test), the problematic file is:
g++ -c -o quadrics.o -dspec_cpu -dndebug   -ofast -g -fpermissive  
-dspec_cpu_lp64   quadrics.cpp -fdbg-cnt=match:4030

Where match:4030 is the first bad debug counter value.

[Bug other/91730] [10 regression] r275518 causes 3 verification errors in the cpu 2006 test suite

2019-09-11 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91730

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-09-11
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Martin Liška  ---
I can confirm that and I'm going to bisect the transformation.

[Bug other/91730] [10 regression] r275518 causes 3 verification errors in the cpu 2006 test suite

2019-09-11 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91730

Richard Biener  changed:

   What|Removed |Added

 Target|powerpc64le-unknown-linux-g |powerpc64le-unknown-linux-g
   |nu  |nu, x86_64-*-*
 CC||barnaby.wilks at arm dot com
 Blocks||26163
   Target Milestone|--- |10.0

--- Comment #1 from Richard Biener  ---
Using -Ofast I presume?  Note there's the 'match' debug-counter you can use to
bisect the offending transform (per source file of course).

Confirmed on a Haswell machine with -Ofast -march=native as well.

Not exactly wrong-code confirmed yet but we'd like to have SPEC CPU "-Ofast
clean" and thus need to understand what actual transform is bad here.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
[Bug 26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)