[Bug fortran/106817] New: clobber ordering problem when an actual intent(in) argument depends on the value of an intent(out) argument

[Bug fortran/106817] New: clobber ordering problem when an actual intent(in) argument depends on the value of an intent(out) argument

[mikael at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106817

            Bug ID: 106817
           Summary: clobber ordering problem when an actual intent(in)
                    argument depends on the value of an intent(out)
                    argument
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: mikael at gcc dot gnu.org
  Target Milestone: ---

module m
  implicit none
contains
  subroutine copy(in, out)
    integer, intent(in) :: in
    integer, intent(out) :: out
    out = in
  end subroutine copy
end module m

program p
  use m
  implicit none
  integer :: a
  a = 3
  call copy(a+1, a)
  if (a /= 4) stop 1
end program p


The in value (a+1) depends on the value of a, but a is clobbered at the
beginning of the call to copy, so we should make sure that we have evaluated
a+1 before generating the clobber.

[Bug fortran/106817] clobber ordering problem when an actual intent(in) argument depends on the value of an intent(out) argument

[mikael at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106817

--- Comment #1 from Mikael Morin <mikael at gcc dot gnu.org> ---
PR92178 is vaguely related.
The tests are very similar, but that other PR is about allocatables whereas
this one isn’t, so I think they are different.

[Bug fortran/106817] clobber ordering problem when an actual intent(in) argument depends on the value of an intent(out) argument

[anlauf at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106817

anlauf at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |anlauf at gcc dot gnu.org

--- Comment #2 from anlauf at gcc dot gnu.org ---
I see:

    D.4225 = a + 1;
    a = {CLOBBER};
    copy (&D.4225, &a);

so I do not see any failure.  What am I missing?

[Bug fortran/106817] clobber ordering problem when an actual intent(in) argument depends on the value of an intent(out) argument

[mikael at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106817

--- Comment #3 from Mikael Morin <mikael at gcc dot gnu.org> ---
(In reply to anlauf from comment #2)
> 
> What am I missing?

The right testcase.
Try this one.

module m
  implicit none
contains
  subroutine copy(out, in)
    integer, intent(in) :: in
    integer, intent(out) :: out
    out = in
  end subroutine copy
end module m

program p
  use m
  implicit none
  integer :: a
  a = 3
  call copy(a, a+1)
  if (a /= 4) stop 1
end program p

[Bug fortran/106817] clobber ordering problem when an actual intent(in) argument depends on the value of an intent(out) argument

[mikael at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106817

--- Comment #4 from Mikael Morin <mikael at gcc dot gnu.org> ---
(In reply to anlauf from comment #2)
> I see:
> 
>     D.4225 = a + 1;
>     a = {CLOBBER};
>     copy (&D.4225, &a);
> 
> so I do not see any failure.

With the testcase from comment #3, it becomes:

    a = {CLOBBER};
    D.4223 = a + 1;
    copy (&a, &D.4223);

[Bug fortran/106817] clobber ordering problem when an actual intent(in) argument depends on the value of an intent(out) argument

[anlauf at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106817

--- Comment #5 from anlauf at gcc dot gnu.org ---
(In reply to Mikael Morin from comment #4)
> With the testcase from comment #3, it becomes:
> 
>     a = {CLOBBER};
>     D.4223 = a + 1;
>     copy (&a, &D.4223);

Right.  And with -Wall one gets a bogus warning that points to the issue:

pr106817.f90:16:20:

   16 |   call copy (a, a+1)
      |                    ^
Warning: 'a' is used uninitialized [-Wuninitialized]
pr106817.f90:14:14:

   14 |   integer :: a
      |              ^
note: 'a' declared here


Which makes this a 9/10/11/12/13 regression ...  :-(

[Bug fortran/106817] clobber ordering problem when an actual intent(in) argument depends on the value of an intent(out) argument

[mikael at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106817

Mikael Morin <mikael at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2022-09-03
     Ever confirmed|0                           |1
           Assignee|unassigned at gcc dot gnu.org      |mikael at gcc dot gnu.org
             Status|UNCONFIRMED                 |ASSIGNED

--- Comment #6 from Mikael Morin <mikael at gcc dot gnu.org> ---
I’m on it.

[Bug fortran/106817] clobber ordering problem when an actual intent(in) argument depends on the value of an intent(out) argument

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106817

--- Comment #7 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Mikael Morin <mikael@gcc.gnu.org>:

https://gcc.gnu.org/g:29919bf3b6449bafd02e795abbb1966e3990c1fc

commit r13-2835-g29919bf3b6449bafd02e795abbb1966e3990c1fc
Author: Mikael Morin <mikael@gcc.gnu.org>
Date:   Sat Sep 3 11:58:47 2022 +0200

    fortran: Move clobbers after evaluation of all arguments [PR106817]

    For actual arguments whose dummy is INTENT(OUT), we used to generate
    clobbers on them at the same time we generated the argument reference
    for the function call.  This was wrong if for an argument coming
    later, the value expression was depending on the value of the just-
    clobbered argument, and we passed an undefined value in that case.

    With this change, clobbers are collected separatedly and appended
    to the procedure call preliminary code after all the arguments have been
    evaluated.

            PR fortran/106817

    gcc/fortran/ChangeLog:

            * trans-expr.cc (gfc_conv_procedure_call): Collect all clobbers
            to their own separate block.  Append the block of clobbers to
            the procedure preliminary block after the argument evaluation
            codes for all the arguments.

    gcc/testsuite/ChangeLog:

            * gfortran.dg/intent_optimize_4.f90: New test.

[Bug fortran/106817] clobber ordering problem when an actual intent(in) argument depends on the value of an intent(out) argument

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106817

--- Comment #8 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-11 branch has been updated by Mikael Morin
<mikael@gcc.gnu.org>:

https://gcc.gnu.org/g:fee1edea459ca655917f14605bdd38fe0e8f344e

commit r11-10300-gfee1edea459ca655917f14605bdd38fe0e8f344e
Author: Mikael Morin <mikael@gcc.gnu.org>
Date:   Sat Sep 3 11:58:47 2022 +0200

    fortran: Move clobbers after evaluation of all arguments [PR106817]

    For actual arguments whose dummy is INTENT(OUT), we used to generate
    clobbers on them at the same time we generated the argument reference
    for the function call.  This was wrong if for an argument coming
    later, the value expression was depending on the value of the just-
    clobbered argument, and we passed an undefined value in that case.

    With this change, clobbers are collected separatedly and appended
    to the procedure call preliminary code after all the arguments have been
    evaluated.

            PR fortran/106817

    gcc/fortran/ChangeLog:

            * trans-expr.c (gfc_conv_procedure_call): Collect all clobbers
            to their own separate block.  Append the block of clobbers to
            the procedure preliminary block after the argument evaluation
            codes for all the arguments.

    gcc/testsuite/ChangeLog:

            * gfortran.dg/intent_optimize_4.f90: New test.

    (cherry picked from commit 29919bf3b6449bafd02e795abbb1966e3990c1fc)

[Bug fortran/106817] clobber ordering problem when an actual intent(in) argument depends on the value of an intent(out) argument

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106817

--- Comment #9 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-10 branch has been updated by Mikael Morin
<mikael@gcc.gnu.org>:

https://gcc.gnu.org/g:b394ebd90e1f9c125216c70beedf97d6d8739773

commit r10-11029-gb394ebd90e1f9c125216c70beedf97d6d8739773
Author: Mikael Morin <mikael@gcc.gnu.org>
Date:   Sat Sep 3 11:58:47 2022 +0200

    fortran: Move clobbers after evaluation of all arguments [PR106817]

    For actual arguments whose dummy is INTENT(OUT), we used to generate
    clobbers on them at the same time we generated the argument reference
    for the function call.  This was wrong if for an argument coming
    later, the value expression was depending on the value of the just-
    clobbered argument, and we passed an undefined value in that case.

    With this change, clobbers are collected separatedly and appended
    to the procedure call preliminary code after all the arguments have been
    evaluated.

            PR fortran/106817

    gcc/fortran/ChangeLog:

            * trans-expr.c (gfc_conv_procedure_call): Collect all clobbers
            to their own separate block.  Append the block of clobbers to
            the procedure preliminary block after the argument evaluation
            codes for all the arguments.

    gcc/testsuite/ChangeLog:

            * gfortran.dg/intent_optimize_4.f90: New test.

    (cherry picked from commit 29919bf3b6449bafd02e795abbb1966e3990c1fc)

[Bug fortran/106817] clobber ordering problem when an actual intent(in) argument depends on the value of an intent(out) argument

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106817

--- Comment #10 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-12 branch has been updated by Mikael Morin
<mikael@gcc.gnu.org>:

https://gcc.gnu.org/g:d633e1cf67ad06c2fef6c33280b548f9c6ea9eba

commit r12-8826-gd633e1cf67ad06c2fef6c33280b548f9c6ea9eba
Author: Mikael Morin <mikael@gcc.gnu.org>
Date:   Sat Sep 3 11:58:47 2022 +0200

    fortran: Move clobbers after evaluation of all arguments [PR106817]

    For actual arguments whose dummy is INTENT(OUT), we used to generate
    clobbers on them at the same time we generated the argument reference
    for the function call.  This was wrong if for an argument coming
    later, the value expression was depending on the value of the just-
    clobbered argument, and we passed an undefined value in that case.

    With this change, clobbers are collected separatedly and appended
    to the procedure call preliminary code after all the arguments have been
    evaluated.

            PR fortran/106817

    gcc/fortran/ChangeLog:

            * trans-expr.cc (gfc_conv_procedure_call): Collect all clobbers
            to their own separate block.  Append the block of clobbers to
            the procedure preliminary block after the argument evaluation
            codes for all the arguments.

    gcc/testsuite/ChangeLog:

            * gfortran.dg/intent_optimize_4.f90: New test.

    (cherry picked from commit 29919bf3b6449bafd02e795abbb1966e3990c1fc)

[Bug fortran/106817] clobber ordering problem when an actual intent(in) argument depends on the value of an intent(out) argument

[mikael at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106817

Mikael Morin <mikael at gcc dot gnu.org> changed:

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

--- Comment #11 from Mikael Morin <mikael at gcc dot gnu.org> ---
Fixed for 13.1, 12.3, 11.4 and 10.5.
Closing.