[Bug target/60088] Segfault when using quad precision and -march=native on gfortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60088 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |DUPLICATE --- Comment #22 from Uroš Bizjak ubizjak at gmail dot com --- *** This bug has been marked as a duplicate of bug 55916 ***
[Bug target/60088] Segfault when using quad precision and -march=native on gfortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60088
--- Comment #23 from Jacob Abel thatcadguy at gmail dot com ---
If it helps at all, the following produces the same problem under gcc:
#include quadmath.h
#include stdlib.h
int main(void)
{
__float128 *ptr = NULL;
int i;
if (ptr = malloc(100 * sizeof(__float128)))
for (i = 0; i 100; i++)
ptr[i] = 0;
return 0;
}
segfault with -march=native, fine without.
[Bug target/60088] Segfault when using quad precision and -march=native on gfortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60088 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-02-06 Ever confirmed|0 |1 --- Comment #9 from Dominique d'Humieres dominiq at lps dot ens.fr --- The test works for me on x86_64-apple-darwin13 on trunk configured with ../work/configure --prefix=/opt/gcc/gcc4.9w --enable-languages=c,c++,fortran,objc,obj-c++,ada,java,lto --with-gmp=/opt/mp --with-system-zlib --with-isl=/opt/mp --enable-lto --enable-plugin --with-arch=corei7 --with-cpu=corei7 for the different tests I have done: separate files/one file, -m64 (default) or -m32, -O3/-Ofast, -static. It works also with gfortran 4.7.4 and 4.8.2/3. Note that I had to user the clang assembler since the as provided by apple is too old, but it should not matter. I have similar results on x86_64-apple-darwin10 (core2) with less accepted options. valgrind reports no error with '-std=f95 -Wall -Wextra -Ofast -march=native -ggdb', but is not happy if I add -m32, though the executable still works outside valgrind. One comment about you configure: you should NEVER use --disable-werror: if your are unable to bootstrap without it, it means you are likely to have problems later. What happens if you configure without graphite, i.e., no cloog stuff?
[Bug target/60088] Segfault when using quad precision and -march=native on gfortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60088 --- Comment #10 from Dominique d'Humieres dominiq at lps dot ens.fr --- This could be a duplicate of pr50201.
[Bug target/60088] Segfault when using quad precision and -march=native on gfortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60088 --- Comment #11 from Jacob Abel thatcadguy at gmail dot com --- The culprit that -march=native activates on my Core i7 laptop is -mavx. Compiling with -mavx causes the segfault, without is fine. Unfortunately, that flag was not set on my other laptop, so might be multiple issues here.
[Bug target/60088] Segfault when using quad precision and -march=native on gfortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60088 --- Comment #12 from Jacob Abel thatcadguy at gmail dot com --- Created attachment 32074 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32074action=edit NEW smaller simpler file to create the segfault
[Bug target/60088] Segfault when using quad precision and -march=native on gfortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60088 --- Comment #13 from Jacob Abel thatcadguy at gmail dot com --- The following file: SUBROUTINE test(N) IMPLICIT NONE INTEGER, INTENT(IN) :: N REAL(KIND=16) :: array(N) array = 0 END SUBROUTINE test PROGRAM main IMPLICIT NONE CALL test(10) END PROGRAM main Creates the same problem. Segfault occurs on 'array = 0'. Will provide more info when I get home.
[Bug target/60088] Segfault when using quad precision and -march=native on gfortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60088 --- Comment #14 from kargl at gcc dot gnu.org --- (In reply to Jacob Abel from comment #8) Seriously? Look, you falsely assumed it was mingw only. Yes, with the information I had at the time, I thought the problem was mingw specific. No wonder clang is going to win in the long run. Fucking twat. If neither gfortran nor the free support offered by the volunteer gfortran developers/maintainers do not meet your expectation, you can remove gfortran from your system and use the llvm-based Fortran compiler.
[Bug target/60088] Segfault when using quad precision and -march=native on gfortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60088 Jouko Orava jouko.orava at iki dot fi changed: What|Removed |Added CC||jouko.orava at iki dot fi --- Comment #15 from Jouko Orava jouko.orava at iki dot fi --- Bug #50201 is fixed by adding -Wl,-uquadmath_snprintf option to gfortran (to cause the linker to consider the quadmath_snprintf to be undefined, and pulls it in). I do not have an AVX-capable CPU at hand, so I don't know if this bug is related or not; perhaps it is worth a test?
[Bug target/60088] Segfault when using quad precision and -march=native on gfortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60088 --- Comment #16 from Jacob Abel thatcadguy at gmail dot com --- Still segfaults, at least on MinGW: C:\Users\Jake\Downloadsgfortran -march=native -Wl,-uquadmath_snprintf newtest.f 90 C:\Users\Jake\Downloadsa Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Backtrace for this error: #0 6f610f4e #1 6f6913eb #2 004010f8 C:\Users\Jake\Downloads
[Bug target/60088] Segfault when using quad precision and -march=native on gfortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60088 --- Comment #18 from Jouko Orava jouko.orava at iki dot fi --- Addendum: the unaligned access causing the segfault seems to occur because __libc_malloc returns an address aligned to 8 bytes, but it is used as if it was aligned to 16 bytes. The disassembly is 80493a0: e8 bb 64 04 00call 808f860 __libc_malloc 80493a5: 89 45 f0 mov%eax,-0x10(%ebp) 80493a8: 8b 5d f4 mov-0xc(%ebp),%ebx 80493ab: b8 01 00 00 00mov$0x1,%eax 80493b0: 39 d8 cmp%ebx,%eax 80493b2: 7f 18 jg 80493cc test_+0x58 80493b4: 8d 48 ff lea-0x1(%eax),%ecx 80493b7: 8b 55 f0 mov-0x10(%ebp),%edx 80493ba: c1 e1 04 shl$0x4,%ecx 80493bd: 01 ca add%ecx,%edx 80493bf: 66 0f ef c0 pxor %xmm0,%xmm0 80493c3: 66 0f 7f 02 movdqa %xmm0,(%edx) 80493c7: 83 c0 01 add$0x1,%eax 80493ca: eb e4 jmp80493b0 test_+0x3c 80493cc: 8b 45 f0 mov-0x10(%ebp),%eax but note that this exact binary was compiled statically, and therefore the addresses differ from the original bug report. Assuming I read the above disassembly correctly, the pointer returned to by __libc_malloc is stored in the stack (at %ebp-16), and retrieved before the access back to %edx. An offset is calculated based on some values into %ecx, multiplied by 16, and added to %edx. %xmm0 is cleared, then copied to address pointed to by %edx. In other words, this is just clearing the array received from malloc() to zeros. Jacob Abel, if you could run the binary you provided me in gdb using (gdb) break *0x80493a5 (gdb) run (gdb) info registers and verify that the %eax register contains an unaligned value (not aligned to 16, last nibble nonzero), then we can confirm that this is the issue -- that GNU Fortran or quadmath library expects malloc() to return 16-byte aligned pointers, whereas it only provides 8-byte aligned pointers. For reference, the malloc man page at the Linux man-pages project, at http://man7.org/linux/man-pages/man3/malloc.3.html explicitly states malloc() returns only 8-byte aligned pointers. (Other references seem to erroneously state that it returns 16-byte aligned pointers on 64-bit architectures.)
[Bug target/60088] Segfault when using quad precision and -march=native on gfortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60088 --- Comment #19 from Jacob Abel thatcadguy at gmail dot com --- jake@Jake-E1505:~/Desktop$ gfortran -static -march=native -Wl,-uquadmath_snprintf newtest.f90 -o newtest jake@Jake-E1505:~/Desktop$ gdb newtest GNU gdb (GDB) 7.5.91.20130417-cvs-ubuntu Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as i686-linux-gnu. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /home/jake/Desktop/newtest...(no debugging symbols found)...done. (gdb) break *0x80493a5 Breakpoint 1 at 0x80493a5 (gdb) run Starting program: /home/jake/Desktop/newtest Breakpoint 1, 0x080493a5 in test_ () (gdb) info registers eax0x81325c8135472584 ecx0x812c780135448448 edx0x81325c8135472584 ebx0x80481d8134513112 esp0xb2e00xb2e0 ebp0xb3080xb308 esi0x00 edi0x812c00c135446540 eip0x80493a50x80493a5 test_+49 eflags 0x286[ PF SF IF ] cs 0x73115 ss 0x7b123 ds 0x7b123 es 0x7b123 fs 0x00 gs 0x3351 (gdb)
[Bug target/60088] Segfault when using quad precision and -march=native on gfortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60088 --- Comment #17 from Jouko Orava jouko.orava at iki dot fi --- I asked and received the details from Jacob Abel off-list, to find out if this bug #60088 is related to bug #50201. They do not seem to be. The instruction causing the segfault in this bug #60088 is 66 0f 7f 02movdqa %xmm0,(%edx) which requires %edx to be aligned to a 16 byte boundary, but %edx is 0x81325c8, unaligned. Thus, segfault. Why this occurs with -mavx but not without, I do not know. In short, the segfault is due to 8-byte aligned access, where 16-byte alignment is required. Perhaps this bug is related to bug #56564 ?
[Bug target/60088] Segfault when using quad precision and -march=native on gfortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60088 --- Comment #20 from Jouko Orava jouko.orava at iki dot fi --- Apologies, Jacob; my advice was faulty. Could you please retest using the following? Compile the binary using gfortran -march=native -ggdb newtest.f90 -o newtest then start gdb, gdb newtest and run until the segfault: (gdb) run At the segfault, list the registers, (gdb) info registers to verify that %edi is still not 16-byte aligned (last hex digit is nonzero). Check the backtrace, (gdb) bt noting the #0 address. Let's say it is 0x6f610f4e. Substract about 0x40 or so from that address, and show the disassembly from that point forwards, using (gdb) disassemble 0x6f610f1e,+100 That should include the segfault address. (In some cases you may need to move the start address by one to five bytes, so that it starts at the correct instruction boundary.) Then, if you could restart the gdb session, and set a breakpoint at the address after the 'call' instruction before the segfault point. Say the line after the 'call' instruction is 0x6f619f2c, then you'd use (gdb) break *0x6f610f2c (gdb) run (gdb) info registers The interesting thing here is the %eax value. If it does end with 8, it means the __libc_malloc call returned a non-aligned memory chunk, and that the generated code did not expect that at all. If not, my theory is incorrect. However, if the above checks out, it means this really is a memory alignment issue, where __libc_malloc() returns a 8-byte-aligned chunk whereas a 16-byte-aligned chunk was expected.
[Bug target/60088] Segfault when using quad precision and -march=native on gfortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60088 --- Comment #21 from Jouko Orava jouko.orava at iki dot fi --- This bug is a duplicate of #55916.
[Bug target/60088] Segfault when using quad precision and -march=native on gfortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60088 Jerry DeLisle jvdelisle at gcc dot gnu.org changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org --- Comment #4 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- I can reproduce this by combining the source into one file and compiling as follows: gfc -static -m32 sip_test.f90 My machine here is x86-64, linux. (Fedora F $ gfc -static -m32 sip_test.f90 $ ./a.out Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Backtrace for this error: #0 0x805D9EF in _gfortrani_backtrace at backtrace.c:258 #1 0x804C4EB in _gfortrani_backtrace_handler at compile_options.c:129 #2 0xF77DA3FF #3 0x80492EE in sip_ #4 0x804C01F in MAIN__ at sip_test.f90:? Segmentation fault (core dumped) Using gdb the fault occurs at the first assignment in subroutine sip b=zero Works fine on -m64
[Bug target/60088] Segfault when using quad precision and -march=native on gfortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60088 --- Comment #5 from Steve Kargl sgk at troutmask dot apl.washington.edu --- On Thu, Feb 06, 2014 at 02:25:27AM +, thatcadguy at gmail dot com wrote: If you bothered to look at the gcc output file, you'd see that I tested it on Linux as well. This is a GCC and MinGW problem. The code segfaults on both platforms with both compilers. What output file? gcc_flags.txt does not show a segfault or a debugger backtrace. I've now tested your code on x86_64-*-freebsd with 4.7, 4.8, and trunk. The code does not segfault. The code runs fine under valgrind. % valgrind ./z ==60969== Memcheck, a memory error detector ==60969== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al. ==60969== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info ==60969== Command: ./z ==60969== 1 1.167898E+02 2 3.604828E+00 3 1.307785E-01 4 8.716767E-03 5 7.426061E-04 6 7.142144E-05 7 7.658771E-06 8 8.214756E-07 9 9.465642E-08 10 1.078958E-08 11 1.283740E-09 12 1.517027E-10 13 1.834825E-11 Max. Error: 4.480767E-13 Avg. Error: 1.225708E-14 Tot. Error: 1.961134E-11 ==60969== ==60969== HEAP SUMMARY: ==60969== in use at exit: 0 bytes in 0 blocks ==60969== total heap usage: 31 allocs, 31 frees, 215,965 bytes allocated ==60969== ==60969== All heap blocks were freed -- no leaks are possible ==60969== ==60969== For counts of detected and suppressed errors, rerun with: -v ==60969== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
[Bug target/60088] Segfault when using quad precision and -march=native on gfortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60088 --- Comment #6 from Jacob Abel thatcadguy at gmail dot com --- (In reply to Steve Kargl from comment #5) What output file? gcc_flags.txt does not show a segfault or a debugger backtrace. It shows that I was not using MinGW, as you assumed. Here's the gdb output: jake@Jake-E1505:~/Downloads$ gdb sip_test GNU gdb (GDB) 7.5.91.20130417-cvs-ubuntu Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as i686-linux-gnu. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /home/jake/Downloads/sip_test...done. (gdb) start Temporary breakpoint 1 at 0x8048ec0: file sip_test.f90, line 1. Starting program: /home/jake/Downloads/sip_test Temporary breakpoint 1, MAIN__ () at sip_test.f90:1 1PROGRAM main (gdb) continue Continuing. Program received signal SIGSEGV, Segmentation fault. 0x0804a9bb in sip (as=..., aw=..., ao=..., ae=..., an=..., s=..., x=..., n=40, k=1600, alp=error reading variable, tol=error reading variable, lim=200, show=.TRUE., fail=.FALSE.) at sip.f90:19 19b = zero; c = zero; d = zero; e = zero; f = zero (gdb) And the normal output: jake@Jake-E1505:~/Downloads$ ./sip_test Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Backtrace for this error: #0 0xB76C3CAB #1 0xB76C42FC #2 0xB77C33FF #3 0x804A9BB in sip_ at sip.f90:19 (discriminator 6) #4 0x804A411 in MAIN__ at sip_test.f90:45 Segmentation fault (core dumped) As I stated, if you take away the -march=native compile flag, it's fine.
[Bug target/60088] Segfault when using quad precision and -march=native on gfortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60088 --- Comment #7 from kargl at gcc dot gnu.org --- (In reply to Jacob Abel from comment #6) (In reply to Steve Kargl from comment #5) What output file? gcc_flags.txt does not show a segfault or a debugger backtrace. It shows that I was not using MinGW, as you assumed. No. It showed that you ran 'gcc -v' on a linux system, and it showed that you ran some other 'gcc -march=native yada' command line. It did not show a segfault or a backtrace. It did not show any problem with linux and it did not show a problem on mingw. Here's the gdb output: Oh, here's the missing information. jake@Jake-E1505:~/Downloads$ gdb sip_test GNU gdb (GDB) 7.5.91.20130417-cvs-ubuntu Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as i686-linux-gnu. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /home/jake/Downloads/sip_test...done. (gdb) start Temporary breakpoint 1 at 0x8048ec0: file sip_test.f90, line 1. Starting program: /home/jake/Downloads/sip_test Temporary breakpoint 1, MAIN__ () at sip_test.f90:1 1 PROGRAM main (gdb) continue Continuing. Program received signal SIGSEGV, Segmentation fault. 0x0804a9bb in sip (as=..., aw=..., ao=..., ae=..., an=..., s=..., x=..., n=40, k=1600, alp=error reading variable, tol=error reading variable, lim=200, show=.TRUE., fail=.FALSE.) at sip.f90:19 19b = zero; c = zero; d = zero; e = zero; f = zero (gdb) Too bad you forgot to at least type bt at the (gdb) prompt. And the normal output: jake@Jake-E1505:~/Downloads$ ./sip_test Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Backtrace for this error: #0 0xB76C3CAB #1 0xB76C42FC #2 0xB77C33FF #3 0x804A9BB in sip_ at sip.f90:19 (discriminator 6) #4 0x804A411 in MAIN__ at sip_test.f90:45 Segmentation fault (core dumped) As I stated, if you take away the -march=native compile flag, it's fine. And, I stated it works fine of 2 different architectures, and yes, I used the options that you provided.
[Bug target/60088] Segfault when using quad precision and -march=native on gfortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60088 --- Comment #8 from Jacob Abel thatcadguy at gmail dot com --- Seriously? Look, you falsely assumed it was mingw only. Jerry reproduced the problem on linux as well. Excuse me for not knowing to post the backtrace. I come here to post a legitimate bug and all you've done is been hasty and unhelpful. No wonder clang is going to win in the long run. Fucking twat.
