NON_LVALUE_EXPR in GENERIC tree on i686

[Andrew Pinski]

On Wed, Aug 28, 2013 at 5:11 AM, Ilmir Usmanov <i.usmanov@samsung.com> wrote:
> Hello all.
>
> I found strange behavior of 32-bit compiler. The compiler adds
> NON_LVALUE_EXPR to GENERIC tree when accesses to an element of massive.
>
> To reproduce the issue I wrote the test program:
>
> PROGRAM test
>          IMPLICIT NONE
>          INTEGER :: a(64), i
>
>          DO i = 1,10
>                  a(i) = i
>          ENDDO
> END
>
> I compiled this simple FORTRAN program using gfortran from trunk. I built
> gcc twice, for 32-bit and 64-bit architectures. 32-bit gcc is
>
> $ /opt/trunk-gcc-32/bin/gfortran -v
> Using built-in specs.
> COLLECT_GCC=/opt/trunk-gcc-32/bin/gfortran
> COLLECT_LTO_WRAPPER=/opt/trunk-gcc-32/libexec/gcc/i686-pc-linux-gnu/4.9.0/lto-wrapper
> Target: i686-pc-linux-gnu
> Configured with: ../gcc/configure --disable-bootstrap --with-gmp=/opt/gmp-32
> --with-mpfr=/opt/mpfr-32 --with-mpc=/opt/mpc-32
> --enable-languages=fortran,c,c++ --prefix=/opt/trunk-gcc-32/
> --target=i686-pc-linux-gnu --build=i686-pc-linux-gnu
> Thread model: posix
> gcc version 4.9.0 20130827 (experimental) (GCC)
>
> and the other is
>
> $ /opt/trunk-gcc/bin/gfortran -v
> Using built-in specs.
> COLLECT_GCC=/opt/trunk-gcc/bin/gfortran
> COLLECT_LTO_WRAPPER=/opt/trunk-gcc/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
> Target: x86_64-unknown-linux-gnu
> Configured with: ../gcc/configure --disable-bootstrap --with-gmp=/opt/gmp
> --with-mpfr=/opt/mpfr --with-mpc=/opt/mpc --enable-languages=fortran,c,c++
> --prefix=/opt/trunk-gcc/
> Thread model: posix
> gcc version 4.9.0 20130827 (experimental) (GCC)
>
> When I compiled the program using 32-bit compiler or 64-bit compiler with
> -m32 key and dumped GENERIC tree, the dump had line
>
> a[NON_LVALUE_EXPR <i> + -1] = i;
>
> while dump from 64-bit compiler without any key had line
>
> a[(integer(kind=8)) i + -1] = i;
>
> Both of dumps are attached to the letter.
> So, is this a bug? Should I open a PR?

No it is not a bug.  The gimplifier will remove NON_LVALUE_EXPR from
the stream as it is not useful after semantics analysis.  The story
around NON_LVALUE_EXPR is that the C front-end uses the normal trees
for its AST.  So there needs to be a way to say there was a cast
(causing an non lvalue) there but there is no code generated from that
cast.

In 32bits in this case, the cast is to the size of the pointer for the
array access and it is being converted to NON_LVALUE_EXPR by
fold-const.c.

Again this is not a bug and it does not effect code generation in anyway.

Thanks,
Andrew Pinski