[Bug fortran/60088] New: Segfault when using quad precision and -march=native on gfortran

[Bug fortran/60088] New: Segfault when using quad precision and -march=native on gfortran

[thatcadguy at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60088

            Bug ID: 60088
           Summary: Segfault when using quad precision and -march=native
                    on  gfortran
           Product: gcc
           Version: 4.7.3
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: thatcadguy at gmail dot com

Created attachment 32061
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32061&action=edit
zip file of the code, makefile, and gcc output

I went to test the attached code with quad precision by changing
SELECTED_REAL_KIND to 33 digits in precision.f90; I got a segfault when trying
to run the compiled sip_test executable. Everything runs fine with double
precision (SELECTED_REAL_KIND @ 15 digits).

This same behavior also occurs with MinGW gfortran 4.8.1 on Windows 7 64-bit.

I noticed that if I take away '-march=native' that the segfault goes away. My
laptop at work with MinGW is a Core i7, this laptop with linux is a Core Duo.

I've attached the code and the gcc -v output as well as the -march=native
flags.

[Bug fortran/60088] Segfault when using quad precision and -march=native on gfortran

[thatcadguy at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60088

--- Comment #1 from Jacob Abel <thatcadguy at gmail dot com> ---
Created attachment 32062
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32062&action=edit
gcc -v output and march=native flags

[Bug target/60088] [MingW] Segfault when using quad precision and -march=native on gfortran

[kargl at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60088

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kargl at gcc dot gnu.org
          Component|fortran                     |target
            Summary|Segfault when using quad    |[MingW] Segfault when using
                   |precision and -march=native |quad precision and
                   |on  gfortran                |-march=native on  gfortran

--- Comment #2 from kargl at gcc dot gnu.org ---
This is not a fortran specific problem as it works with i386-*-freebsd.
This also looks like it is coming from the c.l.f thread

https://groups.google.com/forum/#!topic/comp.lang.fortran/gcXN-AcjsIw

Looks like mingw is broken.

[Bug target/60088] [MingW] Segfault when using quad precision and -march=native on gfortran

[thatcadguy at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60088

--- Comment #3 from Jacob Abel <thatcadguy at gmail dot com> ---
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.

[Bug target/60088] Segfault when using quad precision and -march=native on gfortran

[jvdelisle at gcc dot gnu.org]

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

[sgk at troutmask dot apl.washington.edu]

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 +0000, 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

[thatcadguy at gmail dot com]

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
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
19    b = 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

[kargl at gcc dot gnu.org]

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
> 19	b = 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.
>From gcc-bugs-return-442776-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Feb 06 06:02:45 2014
Return-Path: <gcc-bugs-return-442776-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 8807 invoked by alias); 6 Feb 2014 06:02:45 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 8778 invoked by uid 48); 6 Feb 2014 06:02:41 -0000
From: "thatcadguy at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/60088] Segfault when using quad precision and -march=native on  gfortran
Date: Thu, 06 Feb 2014 06:02:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 4.7.3
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: thatcadguy at gmail dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-60088-4-W1asoGgIlo@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60088-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60088-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-02/txt/msg00533.txt.bz2
Content-length: 419

http://gcc.gnu.org/bugzilla/show_bug.cgi?id`088

--- 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.

[Bug target/60088] Segfault when using quad precision and -march=native on gfortran

[dominiq at lps dot ens.fr]

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

[dominiq at lps dot ens.fr]

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

[thatcadguy at gmail dot com]

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=32074&action=edit
NEW smaller simpler file to create the segfault

[Bug target/60088] Segfault when using quad precision and -march=native on gfortran

[thatcadguy at gmail dot com]

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

[kargl at gcc dot gnu.org]

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

[jouko.orava at iki dot fi]

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

[thatcadguy at gmail dot com]

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\Downloads>gfortran -march=native -Wl,-uquadmath_snprintf
newtest.f
90

C:\Users\Jake\Downloads>a

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

[jouko.orava at iki dot fi]

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 02        movdqa %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

[jouko.orava at iki dot fi]

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 00        call   808f860 <__libc_malloc>
 80493a5: 89 45 f0              mov    %eax,-0x10(%ebp)
 80493a8: 8b 5d f4              mov    -0xc(%ebp),%ebx
 80493ab: b8 01 00 00 00        mov    $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                 jmp    80493b0 <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

[thatcadguy at gmail dot com]

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
eax            0x81325c8    135472584
ecx            0x812c780    135448448
edx            0x81325c8    135472584
ebx            0x80481d8    134513112
esp            0xbffff2e0    0xbffff2e0
ebp            0xbffff308    0xbffff308
esi            0x0    0
edi            0x812c00c    135446540
eip            0x80493a5    0x80493a5 <test_+49>
eflags         0x286    [ PF SF IF ]
cs             0x73    115
ss             0x7b    123
ds             0x7b    123
es             0x7b    123
fs             0x0    0
gs             0x33    51
(gdb)

[Bug target/60088] Segfault when using quad precision and -march=native on gfortran

[jouko.orava at iki dot fi]

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 0x00006f610f4e.
Substract about 0x40 or so from that address, and show the
disassembly from that point forwards, using
    (gdb) disassemble 0x00006f610f1e,+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 0x00006f619f2c, then you'd use
    (gdb) break *0x00006f610f2c
    (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

[jouko.orava at iki dot fi]

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

[thatcadguy at gmail dot com]

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.