[Bug fortran/35681] wrong result for vector subscripted array expression in MVBITS
-- hjl dot tools at gmail dot com changed: What|Removed |Added Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35681
[Bug fortran/35681] wrong result for vector subscripted array expression in MVBITS
--- Comment #28 from mikael at gcc dot gnu dot org 2009-01-14 20:53 --- Subject: Bug 35681 Author: mikael Date: Wed Jan 14 20:53:18 2009 New Revision: 143383 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143383 Log: 2009-01-14 Mikael Morin mikael.mo...@tele2.fr PR fortran/35681 * ChangeLog: Fix function name. PR fortran/38487 * dependency.c (gfc_check_argument_var_dependency): Move the check for pointerness inside the if block so that it doesn't affect the return value. PR fortran/38669 * trans-stmt.c (gfc_trans_call): Add the dependency code after the loop bounds calculation one. 2009-01-14 Mikael Morin mikael.mo...@tele2.fr PR fortran/38669 * gfortran.dg/elemental_dependency_3.f90: New test. * gfortran.dg/elemental_subroutine_7.f90: New test. Added: branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/elemental_dependency_3.f90 branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/elemental_subroutine_7.f90 Modified: branches/gcc-4_3-branch/gcc/fortran/ChangeLog branches/gcc-4_3-branch/gcc/fortran/dependency.c branches/gcc-4_3-branch/gcc/fortran/trans-stmt.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35681
[Bug fortran/35681] wrong result for vector subscripted array expression in MVBITS
--- Comment #27 from mikael at gcc dot gnu dot org 2009-01-04 19:12 --- Subject: Bug 35681 Author: mikael Date: Sun Jan 4 19:12:16 2009 New Revision: 143057 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143057 Log: 2009-01-04 Mikael Morin mikael.mo...@tele2.fr PR fortran/35681 * ChangeLog-2008: Fix function name. PR fortran/38487 * dependency.c (gfc_check_argument_var_dependency): Move the check for pointerness inside the if block so that it doesn't affect the return value. PR fortran/38669 * trans-stmt.c (gfc_trans_call): Add the dependency code after the loop bounds calculation one. 2009-01-04 Mikael Morin mikael.mo...@tele2.fr PR fortran/38669 * gfortran.dg/elemental_dependency_3.f90: New test. * gfortran.dg/elemental_subroutine_7.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/elemental_dependency_3.f90 trunk/gcc/testsuite/gfortran.dg/elemental_subroutine_7.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/ChangeLog-2008 trunk/gcc/fortran/dependency.c trunk/gcc/fortran/trans-stmt.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35681
[Bug fortran/35681] wrong result for vector subscripted array expression in MVBITS
--- Comment #21 from mikael at gcc dot gnu dot org 2008-11-24 12:15 --- Subject: Bug 35681 Author: mikael Date: Mon Nov 24 12:13:59 2008 New Revision: 142154 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142154 Log: 2008-11-24 Mikael Morin [EMAIL PROTECTED] PR fortran/35681 * dependency.c (gfc_check_argument_var_dependency): Add elemental check flag. Issue a warning if we find a dependency but don't generate a temporary. Add the case of an elemental function call as actual argument to an elemental procedure. Add the case of an operator expression as actual argument to an elemental procedure. (gfc_check_argument_dependency): Add elemental check flag. Update calls to gfc_check_argument_var_dependency. (gfc_check_fncall_dependency): Add elemental check flag. Update call to gfc_check_argument_dependency. * trans-stmt.c (gfc_trans_call): Make call to gfc_conv_elemental_dependency unconditional, but with a flag whether we should check dependencies between variables. (gfc_conv_elemental_dependency): Add elemental check flag. Update call to gfc_check_fncall_dependency. * trans-expr.c (gfc_trans_arrayfunc_assign): Update call to gfc_check_fncall_dependency. * resolve.c (find_noncopying_intrinsics): Update call to gfc_check_fncall_dependency. * dependency.h (enum gfc_dep_check): New enum. (gfc_check_fncall_dependency): Update prototype. 2008-11-24 Mikael Morin [EMAIL PROTECTED] PR fortran/35681 * gfortran.dg/elemental_dependency_1.f90: New test. Modified: branches/gcc-4_3-branch/gcc/fortran/ChangeLog branches/gcc-4_3-branch/gcc/fortran/dependency.c branches/gcc-4_3-branch/gcc/fortran/dependency.h branches/gcc-4_3-branch/gcc/fortran/resolve.c branches/gcc-4_3-branch/gcc/fortran/trans-expr.c branches/gcc-4_3-branch/gcc/fortran/trans-stmt.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35681
[Bug fortran/35681] wrong result for vector subscripted array expression in MVBITS
--- Comment #22 from mikael at gcc dot gnu dot org 2008-11-24 12:25 --- Argh!! elemental_dependency_1.f90 was not committed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35681
[Bug fortran/35681] wrong result for vector subscripted array expression in MVBITS
--- Comment #23 from mikael at gcc dot gnu dot org 2008-11-24 12:38 --- Subject: Bug 35681 Author: mikael Date: Mon Nov 24 12:37:25 2008 New Revision: 142155 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142155 Log: 2008-11-24 Mikael Morin [EMAIL PROTECTED] PR fortran/35681 * gfortran.dg/elemental_dependency_1.f90: Really commit it. Added: trunk/gcc/testsuite/gfortran.dg/elemental_dependency_1.f90 Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35681
[Bug fortran/35681] wrong result for vector subscripted array expression in MVBITS
--- Comment #24 from mikael at gcc dot gnu dot org 2008-11-24 12:48 --- Subject: Bug 35681 Author: mikael Date: Mon Nov 24 12:46:57 2008 New Revision: 142156 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142156 Log: 2008-11-24 Mikael Morin [EMAIL PROTECTED] PR fortran/35681 * gfortran.dg/elemental_dependency_1.f90: Really commit it. Added: branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/elemental_dependency_1.f90 Modified: branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35681
[Bug fortran/35681] wrong result for vector subscripted array expression in MVBITS
--- Comment #25 from mikael at gcc dot gnu dot org 2008-11-24 13:10 --- (In reply to comment #22) Argh!! elemental_dependency_1.f90 was not committed. Fixed now, sorry for the noise. (In reply to comment #20) Mikael, Daniel: Have I missed something or is everything in this PR fixed in 4.4 (trunk) and only some 4.3 back porting is needed? Sorry for forgetting about it. Yes, I think it is fixed, and I've just back-ported. closing now. -- mikael at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35681
[Bug fortran/35681] wrong result for vector subscripted array expression in MVBITS
--- Comment #26 from pault at gcc dot gnu dot org 2008-11-24 19:14 --- Subject: Bug 35681 Author: pault Date: Mon Nov 24 19:13:12 2008 New Revision: 142169 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142169 Log: 2008-11-24 Steven G. Kargl [EMAIL PROTECTED] PR fortran/37792 * fortran/resolve.c (resolve_fl_variable): Simplify the initializer if there is one. 2008-11-24 Steven G. Kargl [EMAIL PROTECTED] PR fortran/37792 * gfortran.dg/arithmetic_overflow_1.f90: New test. 2008-11-24 Mikael Morin [EMAIL PROTECTED] PR fortran/35681 * gfortran.dg/elemental_dependency_1.f90: Correct strings in test. Added: branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/arithmetic_overflow_1.f90 Modified: branches/gcc-4_3-branch/gcc/fortran/ChangeLog branches/gcc-4_3-branch/gcc/fortran/resolve.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/elemental_dependency_1.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35681
[Bug fortran/35681] wrong result for vector subscripted array expression in MVBITS
--- Comment #20 from burnus at gcc dot gnu dot org 2008-11-23 19:07 --- Mikael, Daniel: Have I missed something or is everything in this PR fixed in 4.4 (trunk) and only some 4.3 back porting is needed? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35681
[Bug fortran/35681] wrong result for vector subscripted array expression in MVBITS
--- Comment #19 from mikael at gcc dot gnu dot org 2008-11-16 22:46 --- Subject: Bug 35681 Author: mikael Date: Sun Nov 16 22:45:10 2008 New Revision: 141931 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141931 Log: 2008-11-16 Mikael Morin [EMAIL PROTECTED] PR fortran/35681 * dependency.c (gfc_check_argument_var_dependency): Add elemental check flag. Issue a warning if we find a dependency but don't generate a temporary. Add the case of an elemental function call as actual argument to an elemental procedure. Add the case of an operator expression as actual argument to an elemental procedure. (gfc_check_argument_dependency): Add elemental check flag. Update calls to gfc_check_argument_var_dependency. (gfc_check_fncall_dependency): Add elemental check flag. Update call to gfc_check_argument_dependency. * trans-stmt.c (gfc_trans_call): Make call to gfc_conv_elemental_dependency unconditional, but with a flag whether we should check dependencies between variables. (gfc_conv_elemental_dependency): Add elemental check flag. Update call to gfc_check_fncall_dependency. * trans-expr.c (gfc_trans_arrayfunc_assign): Update call to gfc_check_fncall_dependency. * resolve.c (find_noncopying_intrinsics): Update call to gfc_check_fncall_dependency. * dependency.h (enum gfc_dep_check): New enum. (gfc_check_fncall_dependency): Update prototype. 2008-11-16 Mikael Morin [EMAIL PROTECTED] PR fortran/35681 * gfortran.dg/elemental_dependency_1.f90: New test. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/dependency.c trunk/gcc/fortran/dependency.h trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-expr.c trunk/gcc/fortran/trans-stmt.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35681
[Bug fortran/35681] wrong result for vector subscripted array expression in MVBITS
--- Comment #18 from mikael at gcc dot gnu dot org 2008-11-14 13:01 --- (In reply to comment #17) Unassigning myself. Mikael will probably want to take the missing part on with his pending patch :) Regressions are making my life tough right now, but I will succeed in the end. :) Taking it. -- mikael at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mikael at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2008-10-14 16:20:44 |2008-11-14 13:01:53 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35681
[Bug fortran/35681] wrong result for vector subscripted array expression in MVBITS
--- Comment #17 from domob at gcc dot gnu dot org 2008-11-13 17:16 --- Unassigning myself. Mikael will probably want to take the missing part on with his pending patch :) -- domob at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|domob at gcc dot gnu dot org|unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35681
[Bug fortran/35681] wrong result for vector subscripted array expression in MVBITS
--- Comment #15 from domob at gcc dot gnu dot org 2008-11-01 13:27 --- Subject: Bug 35681 Author: domob Date: Sat Nov 1 13:26:19 2008 New Revision: 141516 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141516 Log: 2008-11-01 Daniel Kraft [EMAIL PROTECTED] PR fortran/35681 * gfortran.h (struct gfc_code): New field `resolved_isym'. * trans.h (gfc_build_memcpy_call): Made public. * trans-array.h (gfc_trans_create_temp_array): New argument `initial'. * intrinsic.c (gfc_intrinsic_sub_interface): Set resolved_isym. * iresolve.c (create_formal_for_intents): New helper method. (gfc_resolve_mvbits): Put dummy formal arglist on resolved_sym. * resolve.c (resolve_call): Initialize resolved_isym to NULL. * trans-array.c (gfc_trans_allocate_array_storage): New argument `initial' to allow initializing the allocated storage to some initial value copied from another array. (gfc_trans_create_temp_array): Allow initialization of the temporary with a copy of some other array by using the new extension. (gfc_trans_array_constructor): Pass NULL_TREE for initial argument. (gfc_conv_loop_setup): Ditto. * trans-intrinsic.c (gfc_conv_intrinsic_array_transfer): Ditto. * trans-expr.c (gfc_conv_function_call): Ditto. (gfc_build_memcpy_call): Made public. * trans-stmt.c (gfc_conv_elemental_dependencies): Initialize created temporary for INTENT(INOUT) arguments to the value of the mirrored array and clean up the temporary as very last intructions in the created block. * trans.c (gfc_trans_code): For EXEC_CALL, see if we have a MVBITS call and enable elemental dependency checking if we have. 2008-11-01 Daniel Kraft [EMAIL PROTECTED] PR fortran/35681 * gfortran.dg/mvbits_4.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/mvbits_4.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/intrinsic.c trunk/gcc/fortran/iresolve.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-array.h trunk/gcc/fortran/trans-expr.c trunk/gcc/fortran/trans-intrinsic.c trunk/gcc/fortran/trans-stmt.c trunk/gcc/fortran/trans.c trunk/gcc/fortran/trans.h trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35681
[Bug fortran/35681] wrong result for vector subscripted array expression in MVBITS
--- Comment #16 from domob at gcc dot gnu dot org 2008-11-01 13:37 --- This commit implements correct dependency and temporary handling if the arguments to MVBITS are *not* expressions; thus it does not yet fix the original test, although it fixes it if the parentheses are taken off the first argument. This other problem with ELEMENTAL scalarization will be part 2... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35681
[Bug fortran/35681] wrong result for vector subscripted array expression in MVBITS
--- Comment #12 from pault at gcc dot gnu dot org 2008-10-19 14:34 --- To put the arguments succinctly, this is a double problem (apart from the conformity issue): (i) The original test case is losing the EXPR_PARENTHESES for some reason. ie. there is no question that in this case a temporary should be made for the 'FROM' actual argument. (ii) 12.7.3Elemental subroutine actual arguments An elemental subroutine is one that has only scalar dummy arguments, but may have array actual arguments. In a reference to an elemental subroutine, either all actual arguments shall be scalar, or all actual arguments associated with INTENT (OUT) and INTENT (INOUT) dummy arguments shall be arrays of the same shape and the remaining actual arguments shall be conformable with them. In the case that the actual arguments associated with INTENT (OUT) and INTENT (INOUT) dummy arguments are arrays, the values of the elements, if any, of the results are the same as would be obtained if the subroutine had been applied separately, in any order, to corresponding elements of each array actual argument. In a reference to the intrinsic subroutine MVBITS, the actual arguments corresponding to the TO and FROM dummy arguments may be the same variable. Apart from this, the actual arguments in a reference to an elemental subroutine must satisfy the restrictions of 12.4.1.6. Since the 'TO' and 'FROM' arguments can alias in MVBITS and the results must be order independent, the test case should also create a temporary, even without enclosing parentheses. For the reason described before trans-stmt.c(gfc_conv_elemental_dependencies) this should be the 'TO' variable and should be done on the basis of a dependency between 'TO' and 'FROM' to be safe. The implementation is complicated by the resolved_sym for MVBITS not carrying formal arguments so that gfc_conv_elemental_dependencies does nothing, even if it is spoon-fed the call. Paul puts thinking hat on! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35681
[Bug fortran/35681] wrong result for vector subscripted array expression in MVBITS
--- Comment #13 from domob at gcc dot gnu dot org 2008-10-19 14:46 --- Paul, thanks for stepping into the party :) My plan for working on this is to look at the first part of the problem for now (the lost parentheses, this is a general ELEMENTAL problem, as my (invalid) test from comment #7 also fails for adding parentheses around the first argument). I hope this can be fixed quite straight forward if I find the problem. After this, we can look at the MVBITS specific part. I think this is a reasonable way to work on this problem; what do you think? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35681
[Bug fortran/35681] wrong result for vector subscripted array expression in MVBITS
--- Comment #14 from domob at gcc dot gnu dot org 2008-10-19 16:16 --- Actually, the parentheses aren't lost and *do* get honoured, but the temporary is only inside the scalarization loop and thus not the full array temporary we want; the problem is that the actual argument expressions (and thus the EXPR_OP) gets translated inside gfc_conv_function_call which is only inside the scalarization loop for ELEMENTAL calls and thus only a scalar temporary. A possible approach for solving this problem in a way that looks more or less clean to me would be to translate call expression arguments in gfc_trans_call before gfc_conv_function_call, i.e. before even generating the ELEMENTAL scalarization loop. This would however of course be a somewhat intrusive patch and I want to make sure you agree with this plan. Or is there some other way I'm not aware of? I'm just thinking that moving this expression translation that would take care of parentheses and friends would not involve any new code but rather reorganize the existing one and thus utilize what's already there to its best. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35681
[Bug fortran/35681] wrong result for vector subscripted array expression in MVBITS
--- Comment #7 from domob at gcc dot gnu dot org 2008-10-18 08:27 --- I'm having some difficulties seeing what the problem really is... My understanding of elemental procedures so far is that they should be more or less equivalent to looping over the arguments and then performing them as the standard seems to enforce the order and such is not important... What do I miss? Is the following program supposed to swap the elements in a and b? PROGRAM main IMPLICIT NONE INTEGER :: a(2) a = (/ 1, 2 /) CALL copy (a((/ 2, 1 /)), a) PRINT *, a STOP CONTAINS ELEMENTAL SUBROUTINE copy (a, b) IMPLICIT NONE INTEGER, INTENT(IN) :: a INTEGER, INTENT(OUT) :: b b = a END SUBROUTINE copy END PROGRAM main This prints 2 2 at the moment, which seems quite reasonable to me; or does the standard enforce it should print 2 1? If so, where can I find the details about this (i.e. need temporaries only for INTENT(IN) arguments that are TARGETS or also passed to INTENT(*OUT) parameters, or also for INTENT(INOUT) ones...)? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35681
[Bug fortran/35681] wrong result for vector subscripted array expression in MVBITS
--- Comment #9 from burnus at gcc dot gnu dot org 2008-10-18 10:20 --- (In reply to comment #8) ifort returns 2 2 and g95 2 1. As far as I understand the scalarization of elemental procedures, I think g95 is right. sunf95, openf95, NAG f95 and pathscale's pathf95 also return 2 1; Portland group's pgf95 has 2 2. I think we need an array temporary if an a variable appears twice in an argument list, if one of these arguments has an array section (except for whole-array sections (:)). Special care might be necessary: Pointers as actual argument and elemental functions of the type array = func(array(section)), I'm not sure and need to re-read the standard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35681
[Bug fortran/35681] wrong result for vector subscripted array expression in MVBITS
--- Comment #10 from burnus at gcc dot gnu dot org 2008-10-18 11:36 --- Somehow reading the bug report first before replying helps ... Ignore the crap I just wrote. Dick's (comment 0) CALL MVBITS ((ILA1(NFV3)), 2, 4, ILA1, 3) !fails is valid as the first and the fourth argument don't refer to the same variable - the first argument is an expression for which a temporary needs to be created. Ditto for FX's (comment 1) call mvbits ((ILA1((/9/))), 2, 4, ILA1, 3) However, comment 7's CALL copy (a((/ 2, 1 /)), a) is wrong as one passes twice the same variable - once as array section and once as whole array. There an outer ( ... ) is missing which is needed to makes this an expression. For a lengthy answer including where to find it in the standard, see: http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/160867d13fd90927/ Seemingly somewhere (x) is simplified to x (= EXPR_VARIABLE) and thus no temporary is created - or something like that. For non-elemental procedures this was fixed in gfortran 4.3; before foo((x),x) was optimized to foo((x),x). One can probably ignore all examples after comment 1 and start with looking why no temporary is created for comment 1 - afterwards one needs to check comment 0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35681
[Bug fortran/35681] wrong result for vector subscripted array expression in MVBITS
--- Comment #8 from dominiq at lps dot ens dot fr 2008-10-18 09:31 --- (In reply to comment #7) This prints 2 2 at the moment, which seems quite reasonable to me; or does the standard enforce it should print 2 1? ifort returns 2 2 and g95 2 1. As far as I understand the scalarization of elemental procedures, I think g95 is right. Considering the following modification of the code: PROGRAM main IMPLICIT NONE INTEGER :: i, a(2), b(2) a = (/ 1, 2 /) b = (/ 2, 1 /) CALL copy (a((/ 2, 1 /)), a) PRINT *, a a = (/ 1, 2 /) do i = 1, 2 CALL copy (a(b(i)), a(i)) end do PRINT *, a a = (/ 1, 2 /) do i = 2, 1, -1 CALL copy (a(b(i)), a(i)) end do PRINT *, a STOP CONTAINS ELEMENTAL SUBROUTINE copy (a, b) IMPLICIT NONE INTEGER, INTENT(IN) :: a INTEGER, INTENT(OUT) :: b b = a END SUBROUTINE copy END PROGRAM main which gives: 2 1 2 2 2 2 1 1 i.e., a result depending on the order of the scalar do loop, my understanding is that a temporary is required. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35681
[Bug fortran/35681] wrong result for vector subscripted array expression in MVBITS
--- Comment #11 from dick dot hendrickson at gmail dot com 2008-10-18 17:02 --- Subject: Re: wrong result for vector subscripted array expression in MVBITS Also, MVBITS is a special case. See the top of page 215 in the F95 standard. The FROM and TO arguments are allowed to be the same variable. The other thing about overlapping variables is (2) on page 205, which is a long way from the section header and is often overlooked (at least I missed it once). I'm off to help paint my granddaughter's bedroom, so I can't think much about this. Somewhere, along time ago, there was a smallish test program of the form subroutine xxx(a,b) b = b+1 print *, a,b end and then a ton of call statements of the forms a = 99 call xxx ((a),a) or call xxx( 1*a,a) or call xxx(a+0, a) ... which might be a good thing to invent as a way to check that you aren't oversimplifing actual expressions. Dick Hendrickson On Sat, Oct 18, 2008 at 6:36 AM, burnus at gcc dot gnu dot org [EMAIL PROTECTED] wrote: --- Comment #10 from burnus at gcc dot gnu dot org 2008-10-18 11:36 --- Somehow reading the bug report first before replying helps ... Ignore the crap I just wrote. Dick's (comment 0) CALL MVBITS ((ILA1(NFV3)), 2, 4, ILA1, 3) !fails is valid as the first and the fourth argument don't refer to the same variable - the first argument is an expression for which a temporary needs to be created. Ditto for FX's (comment 1) call mvbits ((ILA1((/9/))), 2, 4, ILA1, 3) However, comment 7's CALL copy (a((/ 2, 1 /)), a) is wrong as one passes twice the same variable - once as array section and once as whole array. There an outer ( ... ) is missing which is needed to makes this an expression. For a lengthy answer including where to find it in the standard, see: http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/160867d13fd90927/ Seemingly somewhere (x) is simplified to x (= EXPR_VARIABLE) and thus no temporary is created - or something like that. For non-elemental procedures this was fixed in gfortran 4.3; before foo((x),x) was optimized to foo((x),x). One can probably ignore all examples after comment 1 and start with looking why no temporary is created for comment 1 - afterwards one needs to check comment 0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35681 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35681
[Bug fortran/35681] wrong result for vector subscripted array expression in MVBITS
--- Comment #6 from domob at gcc dot gnu dot org 2008-10-16 16:32 --- Fixed the accepts-invalid mentioned in comment #1 (patch posted at http://gcc.gnu.org/ml/fortran/2008-10/msg00145.html) on trunk, but the main problem here is still there, I'll start to work on it directly now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35681
[Bug fortran/35681] wrong result for vector subscripted array expression in MVBITS
--- Comment #5 from domob at gcc dot gnu dot org 2008-10-14 16:20 --- I will look at this and try to work it out, taking it for now. -- domob at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |domob at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2008-03-24 22:13:04 |2008-10-14 16:20:44 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35681
[Bug fortran/35681] wrong result for vector subscripted array expression in MVBITS
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2008-03-28 15:18 --- Reduced testcase: integer, dimension(10) :: ILA1 = (/1,2,3,4,5,6,7,8,9,10/) call mvbits ((ILA1((/9,9,6,2,4,9,2,9,6,10/))), 2, 4, ILA1, 3) write (*,'(10(I3))') ila1 end output is: 17 18 11 36 77 22 39 16 41 18 while it should be: 17 18 11 4 13 22 7 16 9 18 I don't know if it related, but the following compiles and segfault at runtime: integer, dimension(10) :: ILA1 = (/1,2,3,4,5,6,7,8,9,10/) call mvbits ((ILA1((/9/))), 2, 4, ILA1, 3) write (*,'(10(I3))') ila1 end while it gives a strange error message with -fbounds-check: At line 2 of file a.f90 Fortran runtime error: Array reference out of bounds for array 'ila1', upper bound of dimension 1 exceeded (68 10) -- 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=35681
[Bug fortran/35681] wrong result for vector subscripted array expression in MVBITS
--- Comment #2 from dominiq at lps dot ens dot fr 2008-03-28 15:29 --- For the second test in comment #1, ifort gives: fortcom: Error: pr35681_2.f90, line 2: The shapes of the arguments do not conform. [MVBITS] call mvbits ((ILA1((/9/))), 2, 4, ILA1, 3) ^ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35681
[Bug fortran/35681] wrong result for vector subscripted array expression in MVBITS
--- Comment #3 from dick dot hendrickson at gmail dot com 2008-03-28 15:48 --- Subject: Re: wrong result for vector subscripted array expression in MVBITS Right, in case you haven't found it yet, the first paragraph of 12.7.3, page 214, says effectively that all of the arguments must be conformable with the TO argument. I was mildly amused that a significant restriction on MVBITS came in the paragraph before the one that explicitly discusses MVBITS. Dick Hendrickson On 28 Mar 2008 15:29:05 -, dominiq at lps dot ens dot fr [EMAIL PROTECTED] wrote: --- Comment #2 from dominiq at lps dot ens dot fr 2008-03-28 15:29 --- For the second test in comment #1, ifort gives: fortcom: Error: pr35681_2.f90, line 2: The shapes of the arguments do not conform. [MVBITS] call mvbits ((ILA1((/9/))), 2, 4, ILA1, 3) ^ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35681 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35681
[Bug fortran/35681] wrong result for vector subscripted array expression in MVBITS
--- Comment #4 from dominiq at lps dot ens dot fr 2008-03-28 16:22 --- It looks like a missing temporary: integer, dimension(10) :: ILA1 = (/1,2,3,4,5,6,7,8,9,10/), ILA2, ILA3 ILA3 = (/9,9,6,2,4,9,2,9,6,10/) print '(10(I3))', ILA1((/9,9,6,2,4,9,2,9,6,10/)) ILA2 = ILA1 do i = 1, 10 call mvbits (ila2(ila3(i)), 2, 4, ila2(i), 3) end do write (*,'(10(I3))') ila2 ILA2 = ILA1 call mvbits ((ILA1((/9,9,6,2,4,9,2,9,6,10/))), 2, 4, ILA2, 3) write (*,'(10(I3))') ila2 call mvbits ((ILA1((/9,9,6,2,4,9,2,9,6,10/))), 2, 4, ILA1, 3) write (*,'(10(I3))') ila1 if (any(ila1 /= ila2)) call abort() end yields 9 9 6 2 4 9 2 9 6 10 17 18 11 36 77 22 39 16 41 18 17 18 11 4 13 22 7 16 9 18 17 18 11 36 77 22 39 16 41 18 Abort -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35681
[Bug fortran/35681] wrong result for vector subscripted array expression in MVBITS
-- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||wrong-code Last reconfirmed|-00-00 00:00:00 |2008-03-24 22:13:04 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35681
