[Bug fortran/45019] Aliasing of TARGET dummy argument not detected correctly
--- Comment #13 from burnus at gcc dot gnu dot org 2010-09-04 19:21 --- Subject: Bug 45019 Author: burnus Date: Sat Sep 4 19:20:53 2010 New Revision: 163863 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163863 Log: 2010-09-04 Tobias Burnus bur...@net-b.de PR fortran/45019 * dependency.c (gfc_check_dependency): Add argument alising * check. * symbol.c (gfc_symbols_could_alias): Add argument alising * check. 2010-09-04 Tobias Burnus bur...@net-b.de PR fortran/45019 * gfortran.dg/aliasing_dummy_5.f90: New. Added: branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/aliasing_dummy_5.f90 Modified: branches/gcc-4_5-branch/gcc/fortran/ChangeLog branches/gcc-4_5-branch/gcc/fortran/dependency.c branches/gcc-4_5-branch/gcc/fortran/symbol.c branches/gcc-4_5-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45019
[Bug fortran/45019] Aliasing of TARGET dummy argument not detected correctly
--- Comment #14 from burnus at gcc dot gnu dot org 2010-09-04 19:21 --- FIXED. Thanks for the bugreport. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45019
[Bug fortran/45019] Aliasing of TARGET dummy argument not detected correctly
--- Comment #11 from burnus at gcc dot gnu dot org 2010-07-23 08:40 --- Subject: Bug 45019 Author: burnus Date: Fri Jul 23 08:40:00 2010 New Revision: 162448 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162448 Log: 2010-07-23 Tobias Burnus bur...@net-b.de PR fortran/45019 * dependency.c (gfc_check_dependency): Add argument alising * check. * symbol.c (gfc_symbols_could_alias): Add argument alising * check. 2010-07-23 Tobias Burnus bur...@net-b.de PR fortran/45019 * gfortran.dg/aliasing_dummy_5.f90: New. Added: branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/aliasing_dummy_5.f90 Modified: branches/gcc-4_4-branch/gcc/fortran/ChangeLog branches/gcc-4_4-branch/gcc/fortran/dependency.c branches/gcc-4_4-branch/gcc/fortran/symbol.c branches/gcc-4_4-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45019
[Bug fortran/45019] Aliasing of TARGET dummy argument not detected correctly
--- Comment #12 from burnus at gcc dot gnu dot org 2010-07-23 09:52 --- Fixed on the trunk and the 4.4 branch. Waiting for 4.5.1 release to apply for 4.5.2 (delay requested by RM as there is already a 4.5.1rc1). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45019
[Bug fortran/45019] Aliasing of TARGET dummy argument not detected correctly
--- Comment #7 from burnus at gcc dot gnu dot org 2010-07-22 06:44 ---
(In reply to comment #5)
I have now asked at
Seemingly, I break the dependency chain in comment 3; thus, only with an added
TARGET in the module variable declaration and with an assumed-shaped dummy in
bar the program is valid.
Therefore: Ignore comment 4 and 5 - we are back to the code in comment 2.
I think the patch below looks fine, however, if I set a break point, the
function gfc_check_dependency is never called for test program. Thus, there
must be at least another spot where a change is required. Paul, do you have an
idea where?
--- a/gcc/fortran/dependency.c
+++ b/gcc/fortran/dependency.c
@@ -807,6 +807,19 @@ gfc_check_dependency (gfc_expr *expr1, gfc_expr *expr2,
bool identical)
return 1;
}
+ else
+ {
+ gfc_symbol *sym1 = expr1-symtree-n.sym;
+ gfc_symbol *sym2 = expr2-symtree-n.sym;
+ if (sym1-attr.target sym2-attr.target
+ ((sym1-attr.dummy !sym1-attr.contiguous
+ (!sym1-attr.dimension
+ || sym2-as-type == AS_ASSUMED_SHAPE))
+ ||(sym2-attr.dummy !sym2-attr.contiguous
+ (!sym2-attr.dimension
+|| sym2-as-type == AS_ASSUMED_SHAPE
+ return 1;
+ }
/* Otherwise distinct symbols have no dependencies. */
return 0;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45019
[Bug fortran/45019] Aliasing of TARGET dummy argument not detected correctly
--- Comment #8 from burnus at gcc dot gnu dot org 2010-07-22 08:40 --- Mine. Additional fix is needed for gfc_symbols_could_alias: --- a/gcc/fortran/symbol.c +++ b/gcc/fortran/symbol.c @@ -2811,6 +2811,17 @@ gfc_symbols_could_alias (gfc_symbol *lsym, gfc_symbol *rsym) if (lsym-attr.allocatable rsym-attr.pointer) return 1; + /* Special case: Argument association, cf. F90 12.4.1.6, F2003 12.4.1.7 + and F2008 12.5.2.13 items 3b and 4b. The pointer case (a) is already + checked above. */ + if (lsym-attr.target rsym-attr.target + ((lsym-attr.dummy !lsym-attr.contiguous + (!lsym-attr.dimension || lsym-as-type == AS_ASSUMED_SHAPE)) + || (rsym-attr.dummy !rsym-attr.contiguous + (!rsym-attr.dimension + || rsym-as-type == AS_ASSUMED_SHAPE +return 1; + return 0; } -- burnus at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |burnus at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2010-07-21 15:57:34 |2010-07-22 08:40:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45019
[Bug fortran/45019] Aliasing of TARGET dummy argument not detected correctly
--- Comment #9 from paul dot richard dot thomas at gmail dot com 2010-07-22 10:00 --- Subject: Re: Aliasing of TARGET dummy argument not detected correctly Dear Tobias, I think the patch below looks fine, however, if I set a break point, the function gfc_check_dependency is never called for test program. Thus, there must be at least another spot where a change is required. Paul, do you have an idea where? A yes. Dependencies in assignment go their own sweet way. trans-array.c:gfc_conv_resolve_dependencies calls gfc_could_be_alias, which in its turn calls symbol.c:gfc_symbols_could_alias This latter is where you need to intervene. Cheers Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45019
[Bug fortran/45019] Aliasing of TARGET dummy argument not detected correctly
--- Comment #10 from burnus at gcc dot gnu dot org 2010-07-22 11:35 --- Subject: Bug 45019 Author: burnus Date: Thu Jul 22 11:35:09 2010 New Revision: 162410 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162410 Log: 2010-07-22 Tobias Burnus bur...@net-b.de PR fortran/45019 * dependency.c (gfc_check_dependency): Add argument alising * check. * symbol.c (gfc_symbols_could_alias): Add argument alising * check. 2010-07-22 Tobias Burnus bur...@net-b.de PR fortran/45019 * gfortran.dg/aliasing_dummy_5.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/aliasing_dummy_5.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/dependency.c trunk/gcc/fortran/symbol.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45019
[Bug fortran/45019] Aliasing of TARGET dummy argument not detected correctly
--- Comment #1 from burnus at gcc dot gnu dot org 2010-07-21 15:57 --- Confirm. Fails with ifort, gfortran 4.1 and 4.6, and with pgf90. Works with Crayftn and Pathscale. I think the scalar constraint does not matter (it's not a restricted pointer as both actual and dummy are TARGET), intent(IN) does not matter (user constraint) thus only array alias analysis remains (in dependency.c): LHS and RHS are TARGET and (at least) one of them a dummy w/ assumed-shape w/o CONTIGUOUS. (The reason for the assumed-shape without CONTIGUOUS constraint is that otherwise copy in/copy out might happen, which leads to unpredictable results.) -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||pault at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||wrong-code Last reconfirmed|-00-00 00:00:00 |2010-07-21 15:57:34 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45019
[Bug fortran/45019] Aliasing of TARGET dummy argument not detected correctly
--- Comment #2 from burnus at gcc dot gnu dot org 2010-07-21 16:32 --- For completeness: In F2003, see Section 12.4.1.7 (3)(b) and in F95 see 12.4.1.6 (1)(c). dependency.c's gfc_check_dependency is the place where a check needs to be added. As pointerness is already checked, I think one can simply check for: sym1 = expr1-symtree-n.sym; sym2 = expr2-symtree-n.sym; if (sym1.attr.target sym2-attr.target ((sym1-attr.dummy !sym1-attr.contiguous sym1-attr.dimension sym2-as.type == AS_ASSUMED_SHAPE) ||(sym2-attr.dummy !sym2-attr.contiguous sym2-attr.dimension sym2-as.type == AS_ASSUMED_SHAPE) return 1; Note: This is completely untested - neither compiled not thought about all cases nor compiled. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45019
[Bug fortran/45019] Aliasing of TARGET dummy argument not detected correctly
--- Comment #3 from burnus at gcc dot gnu dot org 2010-07-21 16:44 --- (In reply to comment #2) if (sym1.attr.target sym2-attr.target Actually, I wonder whether this is really testable: the actual argument is a target thus, one probably needs to use: sym1 = expr1-symtree-n.sym; sym2 = expr2-symtree-n.sym; if ((sym1.attr.target sym1-attr.dummy !sym1-attr.contiguous sym1-attr.dimension sym2-as.type == AS_ASSUMED_SHAPE) ||(sym2.attr.target sym2-attr.dummy !sym2-attr.contiguous sym2-attr.dimension sym2-as.type == AS_ASSUMED_SHAPE)) return 1; Test case follows. Works with Crayftn (1 1 2), fails with pgf95, gfortran, pathf95, ifort. MODULE m IMPLICIT NONE INTEGER :: arr(3) ! NO TARGET CONTAINS SUBROUTINE foobar (arg) INTEGER, TARGET :: arg(:) ! Target arr(2:3) = arg(1:2) END SUBROUTINE foobar END MODULE m PROGRAM main USE m IMPLICIT NONE arr = (/ 1, 2, 3 /) CALL bar(arr) PRINT *, arr contains subroutine bar(x) INTEGER, TARGET :: x(3) ! Target CALL foobar (x) PRINT *, x end subroutine bar END PROGRAM main -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45019
[Bug fortran/45019] Aliasing of TARGET dummy argument not detected correctly
--- Comment #4 from burnus at gcc dot gnu dot org 2010-07-21 16:57 --- (In reply to comment #3) Actually, I wonder whether this is really testable: the actual argument is a target thus, one probably needs to use: The other question is how to deal with the restrict middle-end attribute - currently arr is restrict, i.e. the middle end might do certain optimizations. I do not see how one can prevent this. Thus: Is the program in comment 3 indeed valid? If yes, do we need to do something in terms of restrict - and what? For instance: arr(1) = 5 arg(1) = 6 if (arg(1) /= 6) call abort() In this case, the middle end could optimize the condition way as arr is a restricted pointer and thus it cannot alias with arg (which is not restricted). Thus, I would like to declare the program as invalid. Is there anything in the standard which makes this invalid? On place to look for is the CALL bar(arr) as here arr is not yet a target; the question is whether this propagates through to foobar, making the program invalid. Maybe that's indeed a question for either the j3 mailing list or for c.l.f. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45019
[Bug fortran/45019] Aliasing of TARGET dummy argument not detected correctly
--- Comment #5 from burnus at gcc dot gnu dot org 2010-07-21 18:43 --- (In reply to comment #4) For instance: arr(1) = 5 arg(1) = 6 if (arg(1) /= 6) call abort() Make that arr(1) in the last line - otherwise it is pointless. Maybe that's indeed a question for either the j3 mailing list or for c.l.f. I have now asked at http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/9849942aca1d54f4 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45019
[Bug fortran/45019] Aliasing of TARGET dummy argument not detected correctly
--- Comment #6 from burnus at gcc dot gnu dot org 2010-07-21 21:37 --- (In reply to comment #5) Maybe that's indeed a question for either the j3 mailing list or for c.l.f. I have now asked at http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/9849942aca1d54f4 And at J3: http://j3-fortran.org/pipermail/j3/2010-July/003683.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45019
