Since the revision, 434.zeusmp and other SPEC benchmarks do fail with -march=native -Ofast on AMD znver1 and Intel skylake. I isolated that the affected source file is tranx3.f, where I can see a couple of assembly changes like: Before: vmulsd gridcomr_+44688(,%rax,8), %xmm2, %xmm2 vaddsd %xmm2, %xmm0, %xmm1 vmulsd %xmm2, %xmm0, %xmm0 vxorpd %xmm2, %xmm2, %xmm2 vmaxsd %xmm2, %xmm0, %xmm0 vmovsd %xmm1, %xmm1, %xmm2 vandpd .LC1(%rip), %xmm2, %xmm2 vxorpd %xmm0, %xmm2, %xmm2 vandpd .LC2(%rip), %xmm1, %xmm0 vmovsd .LC3(%rip), %xmm1 vmaxsd %xmm1, %xmm0, %xmm0 vdivsd %xmm0, %xmm2, %xmm0 vmovsd %xmm0, 856(%rsp,%rbx,8) .L102: After: vmulsd gridcomr_+44688(,%rbx,8), %xmm0, %xmm0 vsubsd %xmm2, %xmm1, %xmm2 vmulsd gridcomr_+44688(,%rax,8), %xmm2, %xmm2 vaddsd %xmm2, %xmm0, %xmm1 vandpd .LC1(%rip), %xmm1, %xmm1 vmulsd %xmm2, %xmm0, %xmm0 vxorpd %xmm2, %xmm2, %xmm2 vmaxsd %xmm2, %xmm0, %xmm0 vmovsd .LC3(%rip), %xmm2 vxorpd %xmm0, %xmm1, %xmm0 vandpd .LC2(%rip), %xmm1, %xmm1 vmaxsd %xmm2, %xmm1, %xmm1 vdivsd %xmm1, %xmm0, %xmm0 vmovsd %xmm0, 856(%rsp,%rbx,8) .L102: @H.J. Can you please take a look? It's not easy to reproduce a smaller test-case ..
PR 102224 is most likely related.
Looks like it was always broken and is the same issue as reported in PR 102224 just getting exposed even more. *** This bug has been marked as a duplicate of bug 102224 ***
After r12-3413-ga7b626d98a9a821ffb33466818d6aa86cac1d6fd, I still see the miscompilation in the mentioned file. @Jakub: Can one somehow bisect which XORSIGN pattern causes that?
(In reply to Martin Liška from comment #3) > After r12-3413-ga7b626d98a9a821ffb33466818d6aa86cac1d6fd, I still see the > miscompilation in the mentioned file. > > @Jakub: Can one somehow bisect which XORSIGN pattern causes that? See PR 89984.
(In reply to Andrew Pinski from comment #4) > (In reply to Martin Liška from comment #3) > > After r12-3413-ga7b626d98a9a821ffb33466818d6aa86cac1d6fd, I still see the > > miscompilation in the mentioned file. > > > > @Jakub: Can one somehow bisect which XORSIGN pattern causes that? > > See PR 89984. Thanks!
Fixed after g:7485a52551d71db2e8bbfc4c484196bcc321a1cd.