Gfortran 4.4.1 code bug with -O2 but not with (-O + all -O2 flags)

Gfortran 4.4.1 code bug with -O2 but not with (-O + all -O2 flags)

[Julian King]

Hi all,

I have a piece of scientific fortran 77 code that has been developed
over the last 25 years or so. It is compiled with gfortran 4.4.1 on
SuSE 11.1, on an Intel i7 (i.e. quad-core x86_64). No random number
generators are used, so the program should be deterministic. However,
I have discovered several test cases where the program was producing
different output each time it was run. This implies a memory error, of
course. However, I have run the code with -fbounds-check, and have run
through Valgrind, and discover no errors.

Previously, I had been running the code with -O2. Fortuitously, I
discovered that compiling with -O made the bug disappear on my test
cases. I realise that this is much more likely to reveal a memory
error than a compiler bug. I am unable to produce a test case due to
the size and complexity of the program.

I have two questions:
1) Are there any compiler bugs relevant to the -O2 switches that are
known to have been fixed since 4.4.1 which might solve my problem?
2) Bizzarely, if I manually enable all the flags that appear to be
associated with -O2, the bug does not appear, and the program seems to
run slower. Why is it that -O + -O2 flags does not equal -O2? Here are
my compilation flags:
-O  -Wall -g -fgcse -fgcse-lm -fthread-jumps -falign-functions
-falign-jumps -falign-loops -falign-labels -fcaller-saves
-fcrossjumping -fcse-follow-jumps -fcse-skip-blocks -fcse-skip-blocks
-fdelete-null-pointer-checks -finline-small-functions
-findirect-inlining -foptimize-sibling-calls -fstrict-aliasing
-fstrict-overflow -freorder-blocks -freorder-functions
-falign-functions -falign-jumps -falign-loops -falign-labels -fregmove
-ftree-vrp -ftree-pre -fpeephole2 -fschedule-insns2 -fsched-interblock
-fsched-spec -frerun-cse-after-loop -fexpensive-optimizations
-ftree-switch-conversion

The only flag not there from the -O2 list is -fschedule-insns, If I
try to enable that, I get the following error message:
---snip---
vpfit.f: In function ‘vp_settied’:
vpfit.f:911: error: unable to find a register to spill in class ‘DREG’
vpfit.f:911: error: this is the insn:
(insn 129 137 130 16 vpfit.f:897 (parallel [
            (set (reg:SI 0 ax [104])
                (div:SI (reg:SI 2 cx [orig:106 k ] [106])
                    (mem/s/c:SI (symbol_ref:DI ("vpc_noppsys_")
<var_decl 0x2ad30d61d500 vpc_noppsys>) [6 vpc_noppsys.noppsys+0 S4
A128])))
            (set (reg:SI 2 cx [105])
                (mod:SI (reg:SI 2 cx [orig:106 k ] [106])
                    (mem/s/c:SI (symbol_ref:DI ("vpc_noppsys_")
<var_decl 0x2ad30d61d500 vpc_noppsys>) [6 vpc_noppsys.noppsys+0 S4
A128])))
            (clobber (reg:CC 17 flags))
        ]) 354 {*divmodsi4_nocltd} (expr_list:REG_DEAD (reg:SI 2 cx
[orig:106 k ] [106])
        (expr_list:REG_UNUSED (reg:SI 2 cx [105])
            (expr_list:REG_UNUSED (reg:CC 17 flags)
                (nil)))))
vpfit.f:911: confused by earlier errors, bailing out
---snip--

Thanks for your help,
Julian

Re: Gfortran 4.4.1 code bug with -O2 but not with (-O + all -O2 flags)

[Ian Lance Taylor]

Julian King <jking.phys@gmail.com> writes:

> Previously, I had been running the code with -O2. Fortuitously, I
> discovered that compiling with -O made the bug disappear on my test
> cases. I realise that this is much more likely to reveal a memory
> error than a compiler bug. I am unable to produce a test case due to
> the size and complexity of the program.

When a program works at -O1 but fails at -O2, the most common causes
are an aliasing error or a misuse of undefined signed overflow.  To be
honest, I'm not sure how those affect Fortran programs.  A misuse of
undefined signed overflow is unlikely to cause nondeterministic
behaviour.  An aliasing error could.  But as far as I know Fortran
does not permit aliasing to occur anyhow.

That said, there are unfortunately compiler code generation bugs, and
it is not impossible that you have encountered one.


> 1) Are there any compiler bugs relevant to the -O2 switches that are
> known to have been fixed since 4.4.1 which might solve my problem?

Yes, there have been bug fixes.  However, it's impossible to know
whether they might solve your problem.  gcc is a very stable compiler,
which means that when there are bugs in code generation they are
typically obscure cases which are very sensitive to even the smallest
of changes in the code.


> 2) Bizzarely, if I manually enable all the flags that appear to be
> associated with -O2, the bug does not appear, and the program seems to
> run slower. Why is it that -O + -O2 flags does not equal -O2?

In gcc the -O options are not the sum of a set of -f options.  There
are minor optimizations which simply test whether -O2 is in use.


> The only flag not there from the -O2 list is -fschedule-insns, If I
> try to enable that, I get the following error message:
> ---snip---
> vpfit.f: In function ‘vp_settied’:
> vpfit.f:911: error: unable to find a register to spill in class ‘DREG’
> vpfit.f:911: error: this is the insn:
> (insn 129 137 130 16 vpfit.f:897 (parallel [
>             (set (reg:SI 0 ax [104])
>                 (div:SI (reg:SI 2 cx [orig:106 k ] [106])
>                     (mem/s/c:SI (symbol_ref:DI ("vpc_noppsys_")
> <var_decl 0x2ad30d61d500 vpc_noppsys>) [6 vpc_noppsys.noppsys+0 S4
> A128])))
>             (set (reg:SI 2 cx [105])
>                 (mod:SI (reg:SI 2 cx [orig:106 k ] [106])
>                     (mem/s/c:SI (symbol_ref:DI ("vpc_noppsys_")
> <var_decl 0x2ad30d61d500 vpc_noppsys>) [6 vpc_noppsys.noppsys+0 S4
> A128])))
>             (clobber (reg:CC 17 flags))
>         ]) 354 {*divmodsi4_nocltd} (expr_list:REG_DEAD (reg:SI 2 cx
> [orig:106 k ] [106])
>         (expr_list:REG_UNUSED (reg:SI 2 cx [105])
>             (expr_list:REG_UNUSED (reg:CC 17 flags)
>                 (nil)))))
> vpfit.f:911: confused by earlier errors, bailing out

This looks like a compiler bug.  Please consider reporting it if you
can isolate the test case.

Ian

Re: Gfortran 4.4.1 code bug with -O2 but not with (-O + all -O2 flags)

[Toon Moene]

On 05/07/2010 04:47 PM, Ian Lance Taylor wrote:

> Julian King<jking.phys@gmail.com>  writes:
>
>> Previously, I had been running the code with -O2. Fortuitously, I
>> discovered that compiling with -O made the bug disappear on my test
>> cases. I realise that this is much more likely to reveal a memory
>> error than a compiler bug. I am unable to produce a test case due to
>> the size and complexity of the program.
>
> When a program works at -O1 but fails at -O2, the most common causes
> are an aliasing error or a misuse of undefined signed overflow.  To be
> honest, I'm not sure how those affect Fortran programs.  A misuse of
> undefined signed overflow is unlikely to cause nondeterministic
> behaviour.  An aliasing error could.  But as far as I know Fortran
> does not permit aliasing to occur anyhow.

However, the most common reason for the symptoms you see is using 
uninitialiased variables / arrays.

If you go to the "Changes" link below, you'll see that gfortran-4.5.0 
contains new options to help you track down a problem like that.

So if at all possible, try to install gfortran-4.5.0 and use those 
options (from the man page):

        -finit-local-zero
        -finit-integer=n
        -finit-real=<zero|inf|-inf|nan|snan>
        -finit-logical=<true|false>
        -finit-character=n
            The -finit-local-zero option instructs the compiler to 
initialize local "INTEGER", "REAL", and "COMPLEX" variables to zero, 
"LOGICAL" variables to false, and "CHARACTER" variables to a
            string of null bytes.  Finer-grained initialization options 
are provided by the -finit-integer=n, 
-finit-real=<zero|inf|-inf|nan|snan> (which also initializes the real 
and imaginary
            parts of local "COMPLEX" variables), 
-finit-logical=<true|false>, and -finit-character=n (where n is an ASCII 
character value) options.  These options do not initialize components of
            derived type variables, nor do they initialize variables 
that appear in an "EQUIVALENCE" statement.  (This limitation may be 
removed in future releases).

            Note that the -finit-real=nan option initializes "REAL" and 
"COMPLEX" variables with a quiet NaN. For a signalling NaN use 
-finit-real=snan; note, however, that compile-time
            optimizations may convert them into quiet NaN and that 
trapping needs to be enabled (e.g. via -ffpe-trap).

Hope this helps,

-- 
Toon Moene - e-mail: toon@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/
Progress of GNU Fortran: http://gcc.gnu.org/gcc-4.5/changes.html#Fortran