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

[Ian Lance Taylor <iant at google dot com>]

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