Optimiser bug in 12.1.0.233

[Keith_R_]

Version 12.1.0.233 of the compiler miscompiles the attached file (an extract of a much larger program).
This ran find on earlier versions of the compiler, and on other compilers.

When compiled at -O3 with debug symbols and traceback the program crashes at tuntime with a segfault.

[bash]$ ifort     -O3 -g -traceback -fno-inline-functions  force_segv.f90
$ ./a.out
forrtl: severe (174): SIGSEGV, segmentation fault occurred
Image              PC                Routine            Line        Source
a.out              0000000000403035  force_test_mp_fir          32  force_segv.f90
a.out              0000000000402DAE  MAIN__                     60  force_segv.f90
a.out              0000000000402A9C  Unknown               Unknown  Unknown
libc.so.6          00007F77C9C9814D  Unknown               Unknown  Unknown
a.out              00000000004029A9  Unknown               Unknown  Unknown
[/bash]

The program runs to completion when compiled with versions 11.1 or 12.0, or at a lower optimisation level. In fact
removing the "-g -traceback" flags cause it to apparently succeed, but the error is still there according to valgrind - it just fails to cause a segmentation fault.

[bash]==8194== Invalid read of size 8
==8194==    at 0x402FD6: force_test_mp_firstd_calculate_forces_ (in /home/kr/CASTEP/Compiler_Bugs/Ifort12.1_firstd/a.out)
==8194==    by 0x402D7F: MAIN__ (in /home/kr/CASTEP/Compiler_Bugs/Ifort12.1_firstd/a.out)
==8194==    by 0x402A9B: main (in /home/kr/CASTEP/Compiler_Bugs/Ifort12.1_firstd/a.out)
==8194==  Address 0x5a6a128 is not stack'd, malloc'd or (recently) free'd[/bash]

$ ifort -V
Intel Fortran Intel 64 Compiler XE for applications running on Intel 64, Version 12.1.0.233 Build 20110811
Copyright (C) 1985-2011 Intel Corporation. All rights reserved.
$ uname -a
Linux kohn 2.6.38.7-desktop-1mnb2 #1 SMP Sun May 22 19:38:58 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux
$ cat /etc/redhat-release
Red Hat Enterprise Linux AS release 4 (Nahant Update 9)

I eventually gave up after many attempts to log into Premier support, so I hope this can be treated as reporting the bug here!

[TimP]

You failed to mention whether you followed any of the recommendations in the advice posted at the top of this forum about investigating such problems.
If that advice doesn't include considering the implications of running on a no longer supported OS, you might mentally add that to the list, which normally begins with raising stack limit or considering -heap-arrays.

[Keith_R_]

Tim,

You failed to notice that the largest array in my painstakingly cut-down demonstration program contains just 24 elements
and if that causes a stack overflow then you may tie feathers to me and call me a chicken.

Rest assured that I followed all of the recommendations in your beginner's guide to diagnosing segmentation faults,
as well as others arising from my many years experience distinguishing programming and O/S errors from compiler bugs.
I hope that with a small and completely self-contained example with explicit and clear instructions, someone will take the few seconds to check that it is reproducible.

One other thing I failed to mention is that this bug in the Intel compiler (I'm very sure of that) actually showed up and causes a crash in a widely-used electronic structure code. This is a significant issue, as I will need to advise our users to avoid this version of the compiler.

Keith Refson

[mecej4]

I can reproduce the bug on OpenSuse 11.4-X64 and IFort 12.1.0.233 Build 20110811. A workaround, at least for the short example, is to leave out the -fno-inline-functions option. Please see if you can use this workaround.

Alternatively, you could try the more recent updated compiler, released this month.

[TimP]

OK, I thought you were complaining about it not running on the old OS.

The run-time failure shows up even on a recent OS with current ifort, unless
!dir$ optimize:2
is set in the subroutine, or
!dir$ no vector
or
!dir$ nounroll_and_jam
is set on the inner failing do loop.

Strangely, the broken optimization is suppressed by turning on compiler phase diagnostics, or by writing the loop swap into the source code rather than letting the compiler attempt it.
I agree, there have been too many failures lately associated with -O3. The latest release fixed some but not this one.

[Keith_R_]

I did not mean to suggest this was an O/S version issue - in fact it occurs on a variery of systems, both
supported and unsupported. Sorry if I gave that impression.

The failure is, as you say a fragile one and it took me half a day to boil down the real code. -fno-inline-functions
Is a workaround for the demo example bug not for the real-world code. (I might guess because it can optimise everything away once the function is inlined into the main program as the code produces no output).

I have an idea why the behaviour is so fragile or removing -traceback. According to valgrind the cause of the segfault is a READ instruction from an address outside the heap and the stack. Possibly it is picking up a junk address and attempting to read from that. If the value points to real data, in that case there will be no segmentation fault, although the bad code is still doing domething wrong...

The good news is that I have now been able to get back in to my premier support account. Can I report it there even though I am not the licensee and my account is not registered for this version?

Keith Refson

[mecej4]

In your shoes, I would place very little trust in valgrind in combination with IFort compiled code. I have seen valgrind report memory read errors with every IFort compiled program that does I/O, such as this trivial program:

[fortran]      write(*,*)exp(1.0)
      end
[/fortran]

[bash]Use of uninitialised value of size 8
==28708==    at 0x429939: for__add_to_lf_table

[/bash]

[TimP]

A premier support account isn't registered for a specific version. If the license associated with your account hasn't expired, it will be fine. Note that I verified the problem still appears in 12.1.1 Intel64. Include the URL of this thread in your submission.