[Bug fortran/60370] New: TRANSPOSE on rhs of allocatable array assignment gives bounds error

[Bug fortran/60370] New: TRANSPOSE on rhs of allocatable array assignment gives bounds error

[townsend at astro dot wisc.edu]

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

            Bug ID: 60370
           Summary: TRANSPOSE on rhs of allocatable array assignment gives
                    bounds error
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: townsend at astro dot wisc.edu

The following code:

program foo

  real, allocatable :: a(:,:)
  real, allocatable :: b(:,:)

  allocate(a(10,5))

  a = 0.

  b = TRANSPOSE(a)

end program foo

...produces this error message at runtime, when compiled with -fcheck=all:

At line 10 of file foo.f90
Fortran runtime error: Array bound mismatch for dimension 1 of array 'b' (1/5)

This is on OS X:

Using built-in specs.
COLLECT_GCC=/Applications/madsdk/bin/gfortran.exec
COLLECT_LTO_WRAPPER=/Applications/madsdk/libexec/gcc/x86_64-apple-darwin11.4.2/4.9.0/lto-wrapper
Target: x86_64-apple-darwin11.4.2
Configured with: ./configure CC='gcc -D_FORTIFY_SOURCE=0'
--build=x86_64-apple-darwin11.4.2 --prefix=/Applications/madsdk
--with-gmp=/Applications/madsdk --with-mpfr=/Applications/madsdk
--with-mpc=/Applications/madsdk --enable-languages=c,c++,fortran
--disable-multilib --disable-nls --disable-libsanitizer
Thread model: posix
gcc version 4.9.0 20140201 (experimental) (GCC)

[Bug fortran/60370] TRANSPOSE on rhs of allocatable array assignment gives error with -fcheck=bounds

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |diagnostic, wrong-code
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-03-01
                 CC|                            |janus at gcc dot gnu.org
            Summary|TRANSPOSE on rhs of         |TRANSPOSE on rhs of
                   |allocatable array           |allocatable array
                   |assignment gives bounds     |assignment gives error with
                   |error                       |-fcheck=bounds
     Ever confirmed|0                           |1

--- Comment #1 from janus at gcc dot gnu.org ---
With 4.7/4.8/trunk I get on x86_64-unknown-linux-gnu:

At line 10 of file c0.f90
Fortran runtime error: Array bound mismatch for dimension 1 of array 'b' (0/5)


With 4.6 I get:

At line 10 of file c0.f90
Fortran runtime error: Array bound mismatch for dimension 1 of array 'b'
(140735200374865/5)

(with large random numbers)

[Bug fortran/60370] TRANSPOSE on rhs of allocatable array assignment gives error with -fcheck=bounds

[anlauf at gmx dot de]

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

Harald Anlauf <anlauf at gmx dot de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |anlauf at gmx dot de

--- Comment #2 from Harald Anlauf <anlauf at gmx dot de> ---
PR52162 might be related.  Running the code under comment #0 under
valgrind, I get:

==31023== Memcheck, a memory error detector
==31023== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==31023== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info
==31023== Command: ./a.out
==31023== 
==31023== Conditional jump or move depends on uninitialised value(s)
==31023==    at 0x8049D22: MAIN__ (pr60370.f90:10)
==31023==    by 0x804A16E: main (pr60370.f90:12)
==31023== 
==31023== Conditional jump or move depends on uninitialised value(s)
==31023==    at 0x8049D59: MAIN__ (pr60370.f90:10)
==31023==    by 0x804A16E: main (pr60370.f90:12)
==31023== 
==31023== Conditional jump or move depends on uninitialised value(s)
==31023==    at 0x8049D90: MAIN__ (pr60370.f90:10)
==31023==    by 0x804A16E: main (pr60370.f90:12)
==31023== 
==31023== Conditional jump or move depends on uninitialised value(s)
==31023==    at 0x8049DC7: MAIN__ (pr60370.f90:10)
==31023==    by 0x804A16E: main (pr60370.f90:12)
==31023== 
==31023== Conditional jump or move depends on uninitialised value(s)
==31023==    at 0x8049E02: MAIN__ (pr60370.f90:10)
==31023==    by 0x804A16E: main (pr60370.f90:12)
==31023== 
At line 10 of file pr60370.f90
Fortran runtime error: ==31023== Conditional jump or move depends on
uninitialised value(s)

etc.

[Bug fortran/60370] TRANSPOSE on rhs of allocatable array assignment gives error with -fcheck=bounds

[mikael at gcc dot gnu.org]

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

Mikael Morin <mikael at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mikael at gcc dot gnu.org

--- Comment #3 from Mikael Morin <mikael at gcc dot gnu.org> ---
The array reallocation code must come before the bound checking code, but after
the loop bounds evaluation code.  However, at the time of reallocation
generation the two last codes have already been put in one single block.

The following doesn't work because the array reallocation code uses the loop
bounds so reallocation can't come before loop bounds evaluation.


diff --git a/gcc/fortran/trans-expr.c b/gcc/fortran/trans-expr.c
index 1e156ff..00b1459 100644
--- a/gcc/fortran/trans-expr.c
+++ b/gcc/fortran/trans-expr.c
@@ -8044,7 +8044,7 @@ gfc_trans_assignment_1 (gfc_expr * expr1, gfc_expr *
expr2, bool init_flag,
          ompws_flags &= ~OMPWS_SCALARIZER_WS;
          tmp = gfc_alloc_allocatable_for_assignment (&loop, expr1, expr2);
          if (tmp != NULL_TREE)
-           gfc_add_expr_to_block (&loop.code[expr1->rank - 1], tmp);
+           gfc_prepend_expr_to_block (&loop.pre, tmp);
        }

       /* Generate the copying loops.  */

[Bug fortran/60370] TRANSPOSE on rhs of allocatable array assignment gives error with -fcheck=bounds

[mikael at gcc dot gnu.org]

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

--- Comment #4 from Mikael Morin <mikael at gcc dot gnu.org> ---
Created attachment 32239
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32239&action=edit
Tentative patch moving realloc code before bound checking

This patch doesn't work, so it may not be a code ordering issue after all.

[Bug fortran/60370] TRANSPOSE on rhs of allocatable array assignment gives error with -fcheck=bounds

[janus at gcc dot gnu.org]

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

--- Comment #5 from janus at gcc dot gnu.org ---
(In reply to Mikael Morin from comment #4)
> This patch doesn't work, so it may not be a code ordering issue after all.

I think it *is* an ordering issue after all, and indeed your patch seems to fix
that in the sense that it makes sure that the bounds of 'b' are set before the
bounds-checking code is run.

However, it also seems to introduce another ordering issue: In particular the
bounds of 'b' are now set as

        b.dim[1].lbound = 1;
        b.dim[1].ubound = (D.2352 - D.2351) + 1;

before those temps are actually set via

      D.2351 = a.dim[0].lbound;
      D.2352 = a.dim[0].ubound;

[Bug fortran/60370] TRANSPOSE on rhs of allocatable array assignment gives error with -fcheck=bounds

[mikael at gcc dot gnu.org]

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

--- Comment #6 from Mikael Morin <mikael at gcc dot gnu.org> ---
(In reply to janus from comment #5)
> However, it also seems to introduce another ordering issue: In particular
> the bounds of 'b' are now set as
> 
>         b.dim[1].lbound = 1;
>         b.dim[1].ubound = (D.2352 - D.2351) + 1;
> 
> before those temps are actually set via
> 
>       D.2351 = a.dim[0].lbound;
>       D.2352 = a.dim[0].ubound;

Hmm, no those are correctly ordered, but I see what you mean; and it's actually
diagnosed by the compiler when warnings and optimizations are enabled:
Namely this happens:

      D.2339 = b.dim[1].lbound;
      D.2340 = b.dim[1].ubound;

before b has been initialized.

So the reallocation code has to also happen before b's bounds are evaluated.
Even more tricky... :-(