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
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.
The same on PPC Darwin: pr33749 with -m64 gives the expected result, but pr33686 gives the same result for 32 and 64 bit modes.
(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
(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.
(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
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
(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?
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
(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.