[Bug fortran/45019] New: Aliasing of TARGET dummy argument not detected correctly

[Bug fortran/45019] New: Aliasing of TARGET dummy argument not detected correctly

[domob at gcc dot gnu dot org]

The following program:

MODULE m
  IMPLICIT NONE
  INTEGER, TARGET :: arr(3)

CONTAINS

  SUBROUTINE foobar (arg)
    INTEGER, TARGET :: arg(:)

    arr(2:3) = arg(1:2)
  END SUBROUTINE foobar

END MODULE m

PROGRAM main
  USE :: m
  IMPLICIT NONE

  arr = (/ 1, 2, 3 /)
  CALL foobar (arr)
  PRINT *, arr
END PROGRAM main

does not create a temporary array inside foobar and prints "1 1 1", while I
think it should print "1 1 2".

In the Fortran 2008 standard, 12.5.2.13, 3b):

(3) Action that affects the value of the entity or any subobject of it shall be
taken only through the dummy argument unless
a) ... or
b) the dummy argument has the TARGET attribute, the dummy argument does not
have INTENT(IN), the dummy argument is a scalar object or an assumed-shape
array without the CONTIGUOUS attribute, and the actual argument is a target
other than an array section with a vector subscript.

It seems to me that this allows the code above.


-- 
           Summary: Aliasing of TARGET dummy argument not detected correctly
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: domob at gcc dot gnu dot org


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

[Bug fortran/45019] Aliasing of TARGET dummy argument not detected correctly

[burnus at gcc dot gnu dot org]

------- 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|0000-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

[burnus at gcc dot gnu dot org]

------- 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

[burnus at gcc dot gnu dot org]

------- 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

[burnus at gcc dot gnu dot org]

------- 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

[burnus at gcc dot gnu dot org]

------- 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

[burnus at gcc dot gnu dot org]

------- 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

[Bug fortran/45019] Aliasing of TARGET dummy argument not detected correctly

[burnus at gcc dot gnu dot org]

------- 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

[burnus at gcc dot gnu dot org]

------- 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

[paul dot richard dot thomas at gmail dot com]

------- 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?

Ahhhh.... 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

[burnus at gcc dot gnu dot org]

------- 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=gcc&view=rev&rev=162410
Log:
2010-07-22  Tobias Burnus  <burnus@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  <burnus@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

[burnus at gcc dot gnu dot org]

------- 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=gcc&view=rev&rev=162448
Log:
2010-07-23  Tobias Burnus  <burnus@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  <burnus@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

[burnus at gcc dot gnu dot org]

------- 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

[burnus at gcc dot gnu dot org]

------- 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

[burnus at gcc dot gnu dot org]

------- 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=gcc&view=rev&rev=163863
Log:
2010-09-04  Tobias Burnus  <burnus@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  <burnus@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