[Bug fortran/49103] [4.6/4.7 Regression] local variables exchange values / wrong code with -O3

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49103

--- Comment #8 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2011-05-28 11:08:17 UTC ---
(In reply to comment #7)

> Ugh, the problem is that first cunrolli unrolls the loop, so we get among
> other things parm.9 initialized for printing fgrades_35, then
> _gfortran_transfer_array_write from parm.9, then parm.11 initialized for
> printing fbasegrades_19, then _gfortran_transfer_array_write from
> parm.11, then again parm.9 initialized to the same values again,
> _gfortran_transfer_array_write from it, parm.11 to the same values and
> _gfortran_transfer_array_write from it.  Additionally,
> _gfortran_transfer_array_write uses ".wr" "fn spec" attribute.  Next
> comes fre (2nd), which sees the ".wr" fn spec and removes the second
> identical initialization of parm.9 and parm.11, so parm.9 is no longer
> live in two separate ranges, but also across the parm.11 initialization
> and _gfortran_transfer_array_write call from it.  And during expansion,
> we figure out that parm.9 and parm.11 are in different, non-overlapping
> blocks and thus decide to share the stack slot for both.
> 
> Appart from the ".wr" "fn spec" attribute I think there is nothing
> fortran specific and with
> struct S { largish struct };
> for (int i = 0; i < 2; i++)
>   {
>     {
>       struct S a;
>       initialize a;
>       use a;
>     }
>     {
>       struct S b;
>       initialize b;
>       use b;
>     }
>   }
> we could achieve similar effect (though, if e.g. use is a pure function,
> the second call would be deleted).  So, I'm not convinced reverting my
> patch is the right fix.  Not sure how to allow expansion to notice that
> unrolling made it impossible to share the stack slots though.  Ideas?

I am a little bit confused by the answer:

(1) Is the ".wr" "fn spec" attribute in _gfortran_transfer_array_write a
gfortran mistake?
If yes, what should be the fix?
(2) Will the C example also give a wrog code with revision 169083 reverted?

Note that I have never claimed that reverting revision 169083 is "the right
fix", but only that reverting it fixed the PR!-) Now from my limited
understanding of http://gcc.gnu.org/ml/gcc-patches/2011-01/msg01442.html ,
r169083 looks like an optimization leading to wrong code, which is bad.