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.