[Bug fortran/33749] New: Wrong evaluation of expressions in lhs of assignment statements

[Bug fortran/33749] New: Wrong evaluation of expressions in lhs of assignment statements

[pault at gcc dot gnu dot org]

This is a similar problem to PR33686.

$ cat test.f90
  integer :: p(4) = (/2,4,1,3/)
  p(p) = (/(i, i = 1, 4)/)
  print *, p
end

$ ./a
           3           1           4           3

7.5.1.5 Interpretation of intrinsic assignments
Execution of an intrinsic assignment causes, in effect, the evaluation of the
expression expressions within variable (7.1.7), the possible conversion of expr
to the type and type of variable (Table 7.10), and the definition of variable
with the resulting value. The execution assignment shall have the same effect
as if the evaluation of all operations in expr occurred before any portion of
variable is defined by the assignment. The evaluation within variable shall
neither affect nor be affected by the evaluation of expr. No value variable if
variable is of type character and zero length, or is an array of size zero.

....snip....

The processor may perform the element-by-element assignment in any order.

I take all this to mean that expressions within variable must be evaluated
before the assignment, so that the correct result should be

$ ./a
           3           1           4           2

Paul


-- 
           Summary: Wrong evaluation of expressions in lhs of assignment
                    statements
           Product: gcc
           Version: 4.3.0
            Status: UNCONFIRMED
          Keywords: wrong-code
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: pault at gcc dot gnu dot org


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

[Bug fortran/33749] Wrong evaluation of expressions in lhs of assignment statements

[burnus at gcc dot gnu dot org]

------- Comment #1 from burnus at gcc dot gnu dot org  2007-10-12 15:18 -------
I want to add that I cannot reproduce it on x86-64/Linux with -m64 -- only with
-m32. Other than that, I agree that this is a bug.


-- 

burnus at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |burnus at gcc dot gnu dot
                   |                            |org
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2007-10-12 15:18:17
               date|                            |


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

[Bug fortran/33749] Wrong evaluation of expressions in lhs of assignment statements

[dominiq at lps dot ens dot fr]

------- Comment #2 from dominiq at lps dot ens dot fr  2007-10-12 15:23 -------
The same on PPC Darwin: pr33749 with -m64 gives the expected result, but
pr33686 gives the same result for 32 and 64 bit modes.


-- 


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

[Bug fortran/33749] Wrong evaluation of expressions in lhs of assignment statements

[pault at gcc dot gnu dot org]

------- Comment #3 from pault at gcc dot gnu dot org  2007-10-12 19:09 -------
(In reply to comment #2)
> The same on PPC Darwin: pr33749 with -m64 gives the expected result, but
> pr33686 gives the same result for 32 and 64 bit modes.
> 
Tobias and Dominique,

You're right.  The assignment even produces the temporary for the lhs index
that it should.  Now why on earth does this happen in 64bit mode an not in
32bit??

Try it; first you see it and then you don't....

Still worse, I failed to find any code that would make this possible!! OK I've
got airport lounges and hotel rooms next week; I'll investigate then.

Cheers

Paul


-- 


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

[Bug fortran/33749] Wrong evaluation of expressions in lhs of assignment statements

[fxcoudert at gcc dot gnu dot org]

------- Comment #4 from fxcoudert at gcc dot gnu dot org  2007-10-17 12:36 -------
(In reply to comment #3)
> You're right.  The assignment even produces the temporary for the lhs index
> that it should.  Now why on earth does this happen in 64bit mode an not in
> 32bit??

Sometimes, the difference between 32 and 64 bit is that gfortran generates
conversions for subscripts from int4 to int8 in the 64-bit case, while it uses
the int4 directly in the 32 bit case; an expression can then be an
EXPR_FUNCTION in one case (__convert_i4_i8, or something like that) and an
EXPR_CONST or EXPR_ARRAY in the other case; this difference then makes us take
different code paths. I've seen it happen for a recent PR, though I can't
remember which.


-- 

fxcoudert at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fxcoudert at gcc dot gnu dot
                   |                            |org


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

[Bug fortran/33749] Wrong evaluation of expressions in lhs of assignment statements

[pault at gcc dot gnu dot org]

------- Comment #5 from pault at gcc dot gnu dot org  2007-10-18 04:26 -------
(In reply to comment #4)
> (In reply to comment #3)
> > You're right.  The assignment even produces the temporary for the lhs index
> > that it should.  Now why on earth does this happen in 64bit mode an not in
> > 32bit??
> 
> Sometimes, the difference between 32 and 64 bit is that gfortran generates
> conversions for subscripts from int4 to int8 in the 64-bit case, while it uses
> the int4 directly in the 32 bit case; an expression can then be an
> EXPR_FUNCTION in one case (__convert_i4_i8, or something like that) and an
> EXPR_CONST or EXPR_ARRAY in the other case; this difference then makes us take
> different code paths. I've seen it happen for a recent PR, though I can't
> remember which.
> 

FX,

Yes, I just beat you to it http://gcc.gnu.org/ml/fortran/2007-10/msg00207.html
:)

I'll try to post the patch tomorrow.

Cheers

Paul


-- 

pault at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |pault at gcc dot gnu dot org
                   |dot org                     |
             Status|NEW                         |ASSIGNED
   Last reconfirmed|2007-10-12 15:18:17         |2007-10-18 04:26:21
               date|                            |


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

[Bug fortran/33749] Wrong evaluation of expressions in lhs of assignment statements

[pault at gcc dot gnu dot org]

------- Comment #6 from pault at gcc dot gnu dot org  2007-10-21 18:10 -------
Subject: Bug 33749

Author: pault
Date: Sun Oct 21 18:10:00 2007
New Revision: 129539

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129539
Log:
2007-10-21  Paul Thomas  <pault@gcc.gnu.org>

        PR fortran/33749
        * resolve.c (resolve_ordinary_assign): New function that takes
        the code to resolve an assignment from resolve_code. In
        addition, it makes a temporary of any vector index, on the
        lhs, using gfc_get_parentheses.
        (resolve_code): On EXEC_ASSIGN call the new function.

2007-10-21  Paul Thomas  <pault@gcc.gnu.org>

        PR fortran/33749
        * gfortran.dg/assign_9.f90: New test.


Added:
    trunk/gcc/testsuite/gfortran.dg/assign_9.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/resolve.c
    trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/33749] Wrong evaluation of expressions in lhs of assignment statements

[burnus at gcc dot gnu dot org]

------- Comment #7 from burnus at gcc dot gnu dot org  2007-10-23 08:20 -------
(In reply to comment #6)
> URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129539
> Log:
> 2007-10-21  Paul Thomas  <pault@gcc.gnu.org>
> 
>         PR fortran/33749

Paul, can this bug be closed as FIXED or is something left to be fixed?
Or should be backported to 4.2?


-- 


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

[Bug fortran/33749] Wrong evaluation of expressions in lhs of assignment statements

[patchapp at dberlin dot org]

------- Comment #8 from patchapp at dberlin dot org  2007-10-30 22:15 -------
Subject: Bug number PR33749

A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-10/msg01237.html


-- 


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

[Bug fortran/33749] Wrong evaluation of expressions in lhs of assignment statements

[fxcoudert at gcc dot gnu dot org]

------- Comment #9 from fxcoudert at gcc dot gnu dot org  2007-10-30 22:20 -------
(In reply to comment #8)
> Subject: Bug number PR33749
> 
> A patch for this bug has been added to the patch tracker.
> The mailing list url for the patch is
> http://gcc.gnu.org/ml/gcc-patches/2007-10/msg01237.html

Hum, patchapp sure isn't very up-to-date with his work :)
The patch was approved, and I think the PR can be closed as FIXED.


-- 

fxcoudert at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED


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