[Bug target/86828] [7 Regression] wrong-code bug with "-march=knl -Ofast" (invalid memory reference)

2018-11-25 Thread hjl.tools at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86828

H.J. Lu  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #17 from H.J. Lu  ---
Dup.

*** This bug has been marked as a duplicate of bug 86735 ***

[Bug target/86828] [7 Regression] wrong-code bug with "-march=knl -Ofast" (invalid memory reference)

2018-11-24 Thread hjl.tools at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86828

--- Comment #16 from H.J. Lu  ---
(In reply to janus from comment #15)
> (In reply to H.J. Lu from comment #14)
> > Please try kernel 4.17.xx or above.
> 
> Unfortunately I can not easily test a newer kernel on that hardware right
> now :(

Please try binutils 2.31 branch.  This may be:

https://sourceware.org/bugzilla/show_bug.cgi?id=23465

[Bug target/86828] [7 Regression] wrong-code bug with "-march=knl -Ofast" (invalid memory reference)

2018-11-24 Thread janus at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86828

--- Comment #15 from janus at gcc dot gnu.org ---
(In reply to H.J. Lu from comment #14)
> Please try kernel 4.17.xx or above.

Unfortunately I can not easily test a newer kernel on that hardware right now
:(

[Bug target/86828] [7 Regression] wrong-code bug with "-march=knl -Ofast" (invalid memory reference)

2018-11-23 Thread hjl.tools at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86828

--- Comment #14 from H.J. Lu  ---
(In reply to janus from comment #13)
> (In reply to H.J. Lu from comment #12)
> > Which glibc are you using?
> 
> Same as reported in PR86735:
> * Ubuntu 18.04, kernel 4.15.0
> * Intel(R) Core(TM) i9-7980XE CPU
> * glibc 2.27, binutils 2.30

Please try kernel 4.17.xx or above.

[Bug target/86828] [7 Regression] wrong-code bug with "-march=knl -Ofast" (invalid memory reference)

2018-11-23 Thread janus at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86828

--- Comment #13 from janus at gcc dot gnu.org ---
(In reply to H.J. Lu from comment #12)
> Which glibc are you using?

Same as reported in PR86735:
* Ubuntu 18.04, kernel 4.15.0
* Intel(R) Core(TM) i9-7980XE CPU
* glibc 2.27, binutils 2.30

[Bug target/86828] [7 Regression] wrong-code bug with "-march=knl -Ofast" (invalid memory reference)

2018-11-22 Thread hjl.tools at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86828

--- Comment #12 from H.J. Lu  ---
(In reply to janus from comment #9)
> (In reply to Richard Biener from comment #8)
> > More details are needed here.
> 
> What exactly do you need?
> 
> 
> $ gfortran-7 -march=knl -Ofast -g c0.f90
> $ gdb ./a.out
> [..]
> (gdb) run
> Starting program: /home/janus/fort/gfortran_bugs/86828_knl/a.out 
> 
> Program received signal SIGSEGV, Segmentation fault.
> s (n=..., n=...) at c0.f90:26
> 26  liKOB = Y(n%list)
> (gdb) bt
> #0  s (n=..., n=...) at c0.f90:26
> #1  0x4a9b in knl_bug () at c0.f90:17
> #2  main (argc=argc@entry=1, argv=0x7fffe53a) at c0.f90:17
> #3  0x77626b97 in __libc_start_main (main=0x4800 ,
> argc=1, argv=0x7fffe298, 
> init=, fini=, rtld_fini=,
> stack_end=0x7fffe288)
> at ../csu/libc-start.c:310
> #4  0x4bca in _start ()

Which glibc are you using?

[Bug target/86828] [7 Regression] wrong-code bug with "-march=knl -Ofast" (invalid memory reference)

2018-11-22 Thread janus at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86828

--- Comment #11 from janus at gcc dot gnu.org ---
(In reply to Uroš Bizjak from comment #10)
> (In reply to janus from comment #9)
> > (In reply to Richard Biener from comment #8)
> > > More details are needed here.
> > 
> > What exactly do you need?
> 
> Can you try with valgrind?

I'm afraid that valgrind still does not support knl and skylake instructions,
at least the latest release 3.14 does not seem to do it:

$ valgrind ./a.out 
==5650== Memcheck, a memory error detector
==5650== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==5650== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info
==5650== Command: ./a.out
==5650== 
vex amd64->IR: unhandled instruction bytes: 0x62 0xF1 0xFD 0x48 0x6F 0x5 0x3E
0x6 0x0 0x0
vex amd64->IR:   REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=0
vex amd64->IR:   VEX=0 VEX.L=0 VEX.n=0x0 ESC=NONE
vex amd64->IR:   PFX.66=0 PFX.F2=0 PFX.F3=0
==5650== valgrind: Unrecognised instruction at address 0x108a78.
==5650==at 0x108A78: knl_bug (c0.f90:15)
==5650==by 0x108A78: main (c0.f90:17)
==5650== Your program just tried to execute an instruction that Valgrind
==5650== did not recognise.  There are two possible reasons for this.
==5650== 1. Your program has a bug and erroneously jumped to a non-code
==5650==location.  If you are running Memcheck and you just saw a
==5650==warning about a bad jump, it's probably your program's fault.
==5650== 2. The instruction is legitimate but Valgrind doesn't handle it,
==5650==i.e. it's Valgrind's fault.  If you think this is the case or
==5650==you are not sure, please let us know and we'll try to fix it.
==5650== Either way, Valgrind will now raise a SIGILL signal which will
==5650== probably kill your program.

Program received signal SIGILL: Illegal instruction.

Backtrace for this error:
#0  0x4e582da in ???
#1  0x4e57503 in ???
#2  0x525af1f in ???
#3  0x108a78 in ???
#4  0x523db96 in ???
#5  0x108bc9 in ???
#6  0x in ???
==5650== 
==5650== Process terminating with default action of signal 4 (SIGILL)
==5650==at 0x525AE75: raise (raise.c:46)
==5650==by 0x525AF1F: ??? (in /lib/x86_64-linux-gnu/libc-2.27.so)
==5650==by 0x108A77: knl_bug (c0.f90:15)
==5650==by 0x108A77: main (c0.f90:17)
==5650== 
==5650== HEAP SUMMARY:
==5650== in use at exit: 5,484 bytes in 18 blocks
==5650==   total heap usage: 22 allocs, 4 frees, 13,624 bytes allocated
==5650== 
==5650== LEAK SUMMARY:
==5650==definitely lost: 0 bytes in 0 blocks
==5650==indirectly lost: 0 bytes in 0 blocks
==5650==  possibly lost: 0 bytes in 0 blocks
==5650==still reachable: 5,484 bytes in 18 blocks
==5650== suppressed: 0 bytes in 0 blocks
==5650== Rerun with --leak-check=full to see details of leaked memory
==5650== 
==5650== For counts of detected and suppressed errors, rerun with: -v
==5650== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Illegal instruction (core dumped)

[Bug target/86828] [7 Regression] wrong-code bug with "-march=knl -Ofast" (invalid memory reference)

2018-11-22 Thread ubizjak at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86828

--- Comment #10 from Uroš Bizjak  ---
(In reply to janus from comment #9)
> (In reply to Richard Biener from comment #8)
> > More details are needed here.
> 
> What exactly do you need?

Can you try with valgrind?

[Bug target/86828] [7 Regression] wrong-code bug with "-march=knl -Ofast" (invalid memory reference)

2018-11-22 Thread janus at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86828

--- Comment #9 from janus at gcc dot gnu.org ---
(In reply to Richard Biener from comment #8)
> More details are needed here.

What exactly do you need?


$ gfortran-7 -march=knl -Ofast -g c0.f90
$ gdb ./a.out
[..]
(gdb) run
Starting program: /home/janus/fort/gfortran_bugs/86828_knl/a.out 

Program received signal SIGSEGV, Segmentation fault.
s (n=..., n=...) at c0.f90:26
26liKOB = Y(n%list)
(gdb) bt
#0  s (n=..., n=...) at c0.f90:26
#1  0x4a9b in knl_bug () at c0.f90:17
#2  main (argc=argc@entry=1, argv=0x7fffe53a) at c0.f90:17
#3  0x77626b97 in __libc_start_main (main=0x4800 ,
argc=1, argv=0x7fffe298, 
init=, fini=, rtld_fini=,
stack_end=0x7fffe288)
at ../csu/libc-start.c:310
#4  0x4bca in _start ()

[Bug target/86828] [7 Regression] wrong-code bug with "-march=knl -Ofast" (invalid memory reference)

2018-11-22 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86828

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2018-11-22
 Ever confirmed|0   |1

--- Comment #8 from Richard Biener  ---
(In reply to janus from comment #5)
> (In reply to Richard Biener from comment #1)
> > Would be nice to know what fixed this (or maybe know if it just went 
> > latent).
> 
> Bisection indicates that the segfault disappeared at r254526.

So it somehow went latent...

Note that I cannot reproduce this on a KNL system with GCC 7, binutils 2.26.1,
kernel 4.4 and glibc 2.22.

The backtrace you quote suggests the segfault happens in libgfortran or glibc
during the print stmt.

More details are needed here.