[Bug ipa/88900] [9 Regression] 502.gcc_r SPEC benchmark miscompiles with LTO and PGO

2019-01-23 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88900

--- Comment #11 from Martin Liška  ---
(In reply to rguent...@suse.de from comment #10)
> On Wed, 23 Jan 2019, marxin at gcc dot gnu.org wrote:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88900
> > 
> > Martin Liška  changed:
> > 
> >What|Removed |Added
> > 
> >  Status|ASSIGNED|RESOLVED
> >  Resolution|--- |INVALID
> > 
> > --- Comment #9 from Martin Liška  ---
> > Yes, -fno-strict-aliasing works!
> 
> You can also try the specifc source fix to spec_qsort which IIRC
> I attached somewhere...

Yep, it's this patch:
https://github.com/freebsd/freebsd/commit/26c8a03901f609258e58c4e3bfdc981962a638f0#diff-a8e4a78e4bb28c6e0fe9561688f51573

[Bug ipa/88900] [9 Regression] 502.gcc_r SPEC benchmark miscompiles with LTO and PGO

2019-01-23 Thread rguenther at suse dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88900

--- Comment #10 from rguenther at suse dot de  ---
On Wed, 23 Jan 2019, marxin at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88900
> 
> Martin Liška  changed:
> 
>What|Removed |Added
> 
>  Status|ASSIGNED|RESOLVED
>  Resolution|--- |INVALID
> 
> --- Comment #9 from Martin Liška  ---
> Yes, -fno-strict-aliasing works!

You can also try the specifc source fix to spec_qsort which IIRC
I attached somewhere...

[Bug ipa/88900] [9 Regression] 502.gcc_r SPEC benchmark miscompiles with LTO and PGO

2019-01-23 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88900

Martin Liška  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |INVALID

--- Comment #9 from Martin Liška  ---
Yes, -fno-strict-aliasing works!

[Bug ipa/88900] [9 Regression] 502.gcc_r SPEC benchmark miscompiles with LTO and PGO

2019-01-23 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88900

Martin Liška  changed:

   What|Removed |Added

   Keywords|needs-reduction |

--- Comment #8 from Martin Liška  ---
Ok, compiled binary differs in spec_qsort. That's a known problem and we should
use -fno-strict-aliasing. As mentioned here:
https://www.spec.org/cpu2017/Docs/benchmarks/502.gcc_r.html

I'm testing that..

[Bug ipa/88900] [9 Regression] 502.gcc_r SPEC benchmark miscompiles with LTO and PGO

2019-01-23 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88900

--- Comment #7 from Martin Liška  ---
Using -flto only for tree-ssa-reassoc.o produces the miscompiled GCC (other
files are takes from -O2 -fno-lto build).

[Bug ipa/88900] [9 Regression] 502.gcc_r SPEC benchmark miscompiles with LTO and PGO

2019-01-23 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88900

--- Comment #6 from Martin Liška  ---
I first isolated minimal test-case for which I can see the miscompilation of
the benchmark compiler:

$ cat scilab.c
int a, b, c, d;
void e() { a = (d >= c ? d : c) - 1 + b; }

$ bash -x ./reduce-ice.sh scilab.c 
+ TC1=scilab.c
+
/home/marxin/Programming/cpu2017/benchspec/CPU/502.gcc_r/build/build_peak_gcc7-m64./cpugcc_r
scilab.c -fpic -o 1.s
+ test 0 = 0
+ /tmp/502gcc/build/build_peak_gcc7-m64./cpugcc_r scilab.c -fpic -o 2.s
+ test 0 = 0
+ diff -u 1.s 2.s
--- 1.s 2019-01-23 12:36:20.815829891 +0100
+++ 2.s 2019-01-23 12:36:20.831830396 +0100
@@ -4,26 +4,23 @@
 .globl e
.type   e, @function
 e:
+   call__i686.get_pc_thunk.cx
+   addl$_GLOBAL_OFFSET_TABLE_, %ecx
pushl   %ebp
movl%esp, %ebp
-   pushl   %ebx
-   call__i686.get_pc_thunk.bx
-   addl$_GLOBAL_OFFSET_TABLE_, %ebx
-   movlb@GOT(%ebx), %eax
-   movl(%eax), %ecx
-   movld@GOT(%ebx), %eax
-   subl$1, %ecx
+   movld@GOT(%ecx), %eax
movl(%eax), %edx
-   movlc@GOT(%ebx), %eax
+   movlc@GOT(%ecx), %eax
...

Not I'm going to find a minimal set of LTO object files needed.

[Bug ipa/88900] [9 Regression] 502.gcc_r SPEC benchmark miscompiles with LTO and PGO

2019-01-18 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88900

Martin Liška  changed:

   What|Removed |Added

   Keywords|needs-bisection |
 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org

--- Comment #5 from Martin Liška  ---
Started with r263875:

Setting Up Run Directories
  Setting up 502.gcc_r refrate (ref) peak gcc7-m64 (1 copy):
run_peak_refrate_gcc7-m64.0002
Running Benchmarks
  Running 502.gcc_r refrate (ref) peak gcc7-m64 (1 copy) [2019-01-18 15:34:36]
Error with '/home/marxin/Programming/cpu2017/bin/specinvoke -d
/home/marxin/Programming/cpu2017/benchspec/CPU/502.gcc_r/run/run_peak_refrate_gcc7-m64.0002
-f compare.cmd -E -e compare.err -o compare.stdout'; no non-empty output files
exist
  Command returned exit code 1

Contents of gcc-pp.opts-O2_-finline-limit_36000_-fpic.err

gcc-pp.c: In function 'fibheap_delete_node':
gcc-pp.c:19958:49: warning: overflow in implicit constant conversion
gcc-pp.c: In function 'htab_mod_1':
gcc-pp.c:25469:7: warning: right shift count >= width of type
gcc-pp.c: At top level:
gcc-pp.c:463503:13: warning: 'compute_transp' used but never defined
gcc-pp.c:463518:12: warning: 'one_cprop_pass' used but never defined
gcc-pp.c:463534:12: warning: 'one_pre_gcse_pass' used but never defined
gcc-pp.c:463542:12: warning: 'one_code_hoisting_pass' used but never defined
gcc-pp.c:463551:25: warning: 'find_rtx_in_ldst' used but never defined
gcc-pp.c:463579:13: warning: 'store_motion' used but never defined
gcc-pp.c:463582:13: warning: 'free_modify_mem_tables' used but never defined
gcc-pp.c:463588:22: warning: 'is_too_expensive' used but never defined



Contents of
gcc-pp.opts-O3_-finline-limit_0_-fif-conversion_-fif-conversion2.err

gcc-pp.c: In function 'fibheap_delete_node':
gcc-pp.c:19958:49: warning: overflow in implicit constant conversion
gcc-pp.c: In function 'htab_mod_1':
gcc-pp.c:25469:7: warning: right shift count >= width of type
gcc-pp.c: At top level:
gcc-pp.c:463503:13: warning: 'compute_transp' used but never defined
gcc-pp.c:463518:12: warning: 'one_cprop_pass' used but never defined
gcc-pp.c:463534:12: warning: 'one_pre_gcse_pass' used but never defined
gcc-pp.c:463542:12: warning: 'one_code_hoisting_pass' used but never defined
gcc-pp.c:463551:25: warning: 'find_rtx_in_ldst' used but never defined
gcc-pp.c:463579:13: warning: 'store_motion' used but never defined
gcc-pp.c:463582:13: warning: 'free_modify_mem_tables' used but never defined
gcc-pp.c:463588:22: warning: 'is_too_expensive' used but never defined



Contents of gcc-smaller.opts-O3_-fipa-pta.err

gcc-smaller.c: In function 'fibheap_delete_node':
gcc-smaller.c:19958:49: warning: overflow in implicit constant conversion
gcc-smaller.c: In function 'htab_mod_1':
gcc-smaller.c:25469:7: warning: right shift count >= width of type



Contents of ref32.opts-O3_-fselective-scheduling_-fselective-scheduling2.err

ref32.c:6213:17: warning: conflicting types for built-in function 'imaxabs'



Contents of ref32.opts-O5.err

ref32.c:6213:17: warning: conflicting types for built-in function 'imaxabs'


*** Miscompare of gcc-smaller.opts-O3_-fipa-pta.s; for details see
   
/home/marxin/Programming/cpu2017/benchspec/CPU/502.gcc_r/run/run_peak_refrate_gcc7-m64.0002/gcc-smaller.opts-O3_-fipa-pta.s.mis
*** Miscompare of gcc-pp.opts-O2_-finline-limit_36000_-fpic.s; for details see
   
/home/marxin/Programming/cpu2017/benchspec/CPU/502.gcc_r/run/run_peak_refrate_gcc7-m64.0002/gcc-pp.opts-O2_-finline-limit_36000_-fpic.s.mis
*** Miscompare of
gcc-pp.opts-O3_-finline-limit_0_-fif-conversion_-fif-conversion2.s; for details
see
   
/home/marxin/Programming/cpu2017/benchspec/CPU/502.gcc_r/run/run_peak_refrate_gcc7-m64.0002/gcc-pp.opts-O3_-finline-limit_0_-fif-conversion_-fif-conversion2.s.mis

I'll work on that next week and I'll try find the problem.

[Bug ipa/88900] [9 Regression] 502.gcc_r SPEC benchmark miscompiles with LTO and PGO

2019-01-18 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88900

--- Comment #4 from Martin Liška  ---
(In reply to H.J. Lu from comment #3)
> Is this the same as PR 87214?

No, this one is probably related to RPO VN, I'm not finished with bisection.
And it also happens on non-avx512 targets.

[Bug ipa/88900] [9 Regression] 502.gcc_r SPEC benchmark miscompiles with LTO and PGO

2019-01-18 Thread hjl.tools at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88900

H.J. Lu  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com

--- Comment #3 from H.J. Lu  ---
Is this the same as PR 87214?

[Bug ipa/88900] [9 Regression] 502.gcc_r SPEC benchmark miscompiles with LTO and PGO

2019-01-18 Thread hubicka at ucw dot cz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88900

--- Comment #2 from Jan Hubicka  ---
> What a surprise, started with r267883. I'll carry on bisection with --param
> inline-unit-growth=40.

Well, I guess I can't claim that this is not gcc bug but it is the
benchmark that is broken :)

Honza

[Bug ipa/88900] [9 Regression] 502.gcc_r SPEC benchmark miscompiles with LTO and PGO

2019-01-18 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88900

Martin Liška  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #1 from Martin Liška  ---
What a surprise, started with r267883. I'll carry on bisection with --param
inline-unit-growth=40.

[Bug ipa/88900] [9 Regression] 502.gcc_r SPEC benchmark miscompiles with LTO and PGO

2019-01-18 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88900

Martin Liška  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-01-18
  Known to work||8.2.0
 Blocks||26163
   Target Milestone|--- |9.0
 Ever confirmed|0   |1
  Known to fail||9.0


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)