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