public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug libfortran/95293] New: Fortran not passing array by reference
@ 2020-05-23 20:36 david.sagan at gmail dot com
2020-05-23 22:26 ` [Bug libfortran/95293] " kargl at gcc dot gnu.org
` (11 more replies)
0 siblings, 12 replies; 13+ messages in thread
From: david.sagan at gmail dot com @ 2020-05-23 20:36 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95293
Bug ID: 95293
Summary: Fortran not passing array by reference
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libfortran
Assignee: unassigned at gcc dot gnu.org
Reporter: david.sagan at gmail dot com
Target Milestone: ---
The test program is:
program test
implicit none
type cb_struct
real :: cbar = 0
end type
type scratch_struct
type (cb_struct) :: cc(10)
real :: zz(10) = 0
end type
type (scratch_struct), target :: s1
!
s1%cc(2)%cbar = 7
call sub2(s1%cc%cbar)
print *, 'Sub2 result:', s1%cc(2)%cbar, ' ! Wrong. Should be 10'
s1%zz(2) = 7
call sub3(s1%zz)
print *, 'Sub3 result:', s1%zz(2)
!--------------------------------------
contains
subroutine sub2(vec)
real, target, intent(inout) :: vec(:)
real, pointer :: ptr
ptr => vec(1)
print *, 'In sub2:', associated(ptr, s1%cc(1)%cbar), vec(2)
vec(2) = 23
s1%cc(2)%cbar = 10
end subroutine sub2
subroutine sub3(vec)
real, target, intent(inout) :: vec(:)
real, pointer :: ptr
ptr => vec(1)
print *, 'In sub3:', associated(ptr, s1%zz(1)), vec(2)
vec(2) = 23
s1%zz(2) = 10
end subroutine sub3
end program
Running gives:
> gfortran test.f90
> ./a.out
In sub2: F 7.00000000
Sub2 result: 23.0000000 ! Wrong. Should be 10
In sub3: T 7.00000000
Sub3 result: 10.0000000
I get the same result on Linux and Mac with gcc 8.3.1 and gcc 9.3.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug libfortran/95293] Fortran not passing array by reference
2020-05-23 20:36 [Bug libfortran/95293] New: Fortran not passing array by reference david.sagan at gmail dot com
@ 2020-05-23 22:26 ` kargl at gcc dot gnu.org
2020-05-23 22:43 ` david.sagan at gmail dot com
` (10 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: kargl at gcc dot gnu.org @ 2020-05-23 22:26 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95293
kargl at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |kargl at gcc dot gnu.org
--- Comment #1 from kargl at gcc dot gnu.org ---
(In reply to David Sagan from comment #0)
> The test program is:
>
> program test
> implicit none
>
> type cb_struct
> real :: cbar = 0
> end type
>
> type scratch_struct
> type (cb_struct) :: cc(10)
> real :: zz(10) = 0
> end type
>
> type (scratch_struct), target :: s1
>
> !
>
> s1%cc(2)%cbar = 7
> call sub2(s1%cc%cbar)
> print *, 'Sub2 result:', s1%cc(2)%cbar, ' ! Wrong. Should be 10'
>
> s1%zz(2) = 7
> call sub3(s1%zz)
> print *, 'Sub3 result:', s1%zz(2)
>
> !--------------------------------------
> contains
>
> subroutine sub2(vec)
> real, target, intent(inout) :: vec(:)
> real, pointer :: ptr
> ptr => vec(1)
> print *, 'In sub2:', associated(ptr, s1%cc(1)%cbar), vec(2)
> vec(2) = 23
> s1%cc(2)%cbar = 10
> end subroutine sub2
>
> subroutine sub3(vec)
> real, target, intent(inout) :: vec(:)
> real, pointer :: ptr
> ptr => vec(1)
> print *, 'In sub3:', associated(ptr, s1%zz(1)), vec(2)
> vec(2) = 23
> s1%zz(2) = 10
> end subroutine sub3
>
> end program
>
>
> Running gives:
>
> > gfortran test.f90
> > ./a.out
> In sub2: F 7.00000000
> Sub2 result: 23.0000000 ! Wrong. Should be 10
> In sub3: T 7.00000000
> Sub3 result: 10.0000000
>
> I get the same result on Linux and Mac with gcc 8.3.1 and gcc 9.3.
% gfcx -Warray-temporaries -o z b.f90
b.f90:18:10:
18 | call sub2(s1%cc%cbar)
| 1
Warning: Creating array temporary at (1) [-Warray-temporaries]
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug libfortran/95293] Fortran not passing array by reference
2020-05-23 20:36 [Bug libfortran/95293] New: Fortran not passing array by reference david.sagan at gmail dot com
2020-05-23 22:26 ` [Bug libfortran/95293] " kargl at gcc dot gnu.org
@ 2020-05-23 22:43 ` david.sagan at gmail dot com
2020-05-24 1:53 ` sgk at troutmask dot apl.washington.edu
` (9 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: david.sagan at gmail dot com @ 2020-05-23 22:43 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95293
--- Comment #2 from David Sagan <david.sagan at gmail dot com> ---
The gcc documentation says:
‘array-temps’
Warns at run time when for passing an actual argument a temporary array had to
be generated. The information generated by this warning is sometimes useful in
optimization, in order to avoid such temporaries.
But a temporary array does not have to be created in this example. The ifort
compiler does not do this.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug libfortran/95293] Fortran not passing array by reference
2020-05-23 20:36 [Bug libfortran/95293] New: Fortran not passing array by reference david.sagan at gmail dot com
2020-05-23 22:26 ` [Bug libfortran/95293] " kargl at gcc dot gnu.org
2020-05-23 22:43 ` david.sagan at gmail dot com
@ 2020-05-24 1:53 ` sgk at troutmask dot apl.washington.edu
2020-05-24 6:47 ` tkoenig at gcc dot gnu.org
` (8 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: sgk at troutmask dot apl.washington.edu @ 2020-05-24 1:53 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95293
--- Comment #3 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Sat, May 23, 2020 at 10:43:23PM +0000, david.sagan at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95293
>
> --- Comment #2 from David Sagan <david.sagan at gmail dot com> ---
> The gcc documentation says:
>
> ‘array-temps’
> Warns at run time when for passing an actual argument a temporary array had to
> be generated. The information generated by this warning is sometimes useful in
> optimization, in order to avoid such temporaries.
>
> But a temporary array does not have to be created in this example. The ifort
> compiler does not do this.
>
I suspect your code is invalid, and so gfortran results are
correct. Namely, you have
call sub2(s1%cc%cbar)
...
subroutine sub2(vec)
real, target, intent(inout) :: vec(:)
...
vec(2) = 23
s1%cc(2)%cbar = 10
...
end subroutine sub2
>From F2028
2 The name of the dummy argument may be different from the name,
if any, of its effective argument. The dummy argument name is
the name by which the effective argument is known, and by which
it may be accessed, in the referenced procedure.
The effective argument is s1%cc%cbar and the dummy argument is
vec. Within sub2, you can access vec, which vec(2) = 23 does.
The 's1%cc(2)%cbar' cannot be accessed via host association.
Fortran also does not specify calling semantics, so this
call sub2(s1%cc%cbar)
becomes
tmp = s1%cc%cbar
call sub2(tmp)
s1%cc%bar= tmp
which is essentially
create temporary for s1%cc%cbar
temporary becomes vec(:)
set vec(2) = 23
set s1%cc(2)%cbar = 10 (which is a no-no as it is an effective argument)
return to main and copy vec into s1%cc%cbar (which overwrites the no-no)
Of course, I could be wrong. Of course, changing an entity
via both an effective argument and host association is also
questionable.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug libfortran/95293] Fortran not passing array by reference
2020-05-23 20:36 [Bug libfortran/95293] New: Fortran not passing array by reference david.sagan at gmail dot com
` (2 preceding siblings ...)
2020-05-24 1:53 ` sgk at troutmask dot apl.washington.edu
@ 2020-05-24 6:47 ` tkoenig at gcc dot gnu.org
2020-05-24 7:55 ` sgk at troutmask dot apl.washington.edu
` (7 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: tkoenig at gcc dot gnu.org @ 2020-05-24 6:47 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95293
--- Comment #4 from Thomas Koenig <tkoenig at gcc dot gnu.org> ---
Time to dig out the F2018 standard...
15.5.2.4 Ordinary dummy variables
9 If the dummy argument has the TARGET attribute
That's fulfilled
does not have the VALUE attribute,
That's fulfilled.
and either the effective argument is simply contiguous
That's fulfilled.
or the dummy argument is scalar, assumed-rank, or assumed-shape, and does not
have the CONTIGUOUS attribute,
That is not relevant here.
and the effective argument has the TARGET attribute
That I will have to look up; if a has the TARGET attribute,
does a%b have it as well?
but is not a coindexed
object or an array section with a vector subscript
That's fullfilled.
then
any pointers associated with the effective argument become associated with the
orresponding dummy argument on invocation of the procedure, and
Not relevant to your test case.
when execution of the procedure completes, any pointers that do not become
undefined (19.5.2.5) and are associated with the dummy argument remain
associated with the effective argument.
Hm, this indicates that your test case may be valid if the condition
abouve is met. Have to look at the definition of the TARGET attribute next...
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug libfortran/95293] Fortran not passing array by reference
2020-05-23 20:36 [Bug libfortran/95293] New: Fortran not passing array by reference david.sagan at gmail dot com
` (3 preceding siblings ...)
2020-05-24 6:47 ` tkoenig at gcc dot gnu.org
@ 2020-05-24 7:55 ` sgk at troutmask dot apl.washington.edu
2020-05-24 14:45 ` david.sagan at gmail dot com
` (6 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: sgk at troutmask dot apl.washington.edu @ 2020-05-24 7:55 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95293
--- Comment #5 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Sun, May 24, 2020 at 06:47:18AM +0000, tkoenig at gcc dot gnu.org wrote:
>
> and the effective argument has the TARGET attribute
>
> That I will have to look up; if a has the TARGET attribute,
> does a%b have it as well?
>
You're looking for
If an object has the TARGET attribute, then all of its nonpointer
subobjects also have the TARGET attribute.
I believe it does not matter. The effective argument is s1%cc%cbar.
The subroutine sub2() accesses s1%cc(2)%cbar via host association.
I've quoted the relevant part of the standard that says an effective
should be accessed via the dummy argument. You basically have an
aliasing problem where something is known by a dummy argument
and by host association. It's a rather questionable programming
idiom.
Consider,
program foo
real x
x = 42
call bar(x)
print *, x
contains
subroutine bar(a)
real, intent(inout) :: a
a = 12
x = 0
end subroutine bar
end program foo
Should this print 12 or 0? When bar returns 'a' has a value of
12, should this value be transferred to 'x' before the print
statement is executed?
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug libfortran/95293] Fortran not passing array by reference
2020-05-23 20:36 [Bug libfortran/95293] New: Fortran not passing array by reference david.sagan at gmail dot com
` (4 preceding siblings ...)
2020-05-24 7:55 ` sgk at troutmask dot apl.washington.edu
@ 2020-05-24 14:45 ` david.sagan at gmail dot com
2020-05-24 16:27 ` sgk at troutmask dot apl.washington.edu
` (5 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: david.sagan at gmail dot com @ 2020-05-24 14:45 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95293
--- Comment #6 from David Sagan <david.sagan at gmail dot com> ---
> program foo
> real x
> x = 42
> call bar(x)
> print *, x
> contains
> subroutine bar(a)
> real, intent(inout) :: a
> a = 12
> x = 0
> end subroutine bar
> end program foo
>
> Should this print 12 or 0? When bar returns 'a' has a value of
> 12, should this value be transferred to 'x' before the print
> statement is executed?
'a' is passed by reference. Therefore, when the statement 'x = 0' is executed,
the value of 'a' immediately changes to 0. So '0' will be printed.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug libfortran/95293] Fortran not passing array by reference
2020-05-23 20:36 [Bug libfortran/95293] New: Fortran not passing array by reference david.sagan at gmail dot com
` (5 preceding siblings ...)
2020-05-24 14:45 ` david.sagan at gmail dot com
@ 2020-05-24 16:27 ` sgk at troutmask dot apl.washington.edu
2020-07-08 12:24 ` dominiq at lps dot ens.fr
` (4 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: sgk at troutmask dot apl.washington.edu @ 2020-05-24 16:27 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95293
--- Comment #7 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Sun, May 24, 2020 at 02:45:32PM +0000, david.sagan at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95293
>
> --- Comment #6 from David Sagan <david.sagan at gmail dot com> ---
> > program foo
> > real x
> > x = 42
> > call bar(x)
> > print *, x
> > contains
> > subroutine bar(a)
> > real, intent(inout) :: a
> > a = 12
> > x = 0
> > end subroutine bar
> > end program foo
> >
> > Should this print 12 or 0? When bar returns 'a' has a value of
> > 12, should this value be transferred to 'x' before the print
> > statement is executed?
>
> 'a' is passed by reference. Therefore, when the statement 'x = 0' is executed,
> the value of 'a' immediately changes to 0. So '0' will be printed.
>
The code, like your original example, is invalid. As this is
not a numbered constraint, a Fortran processor is not required
to tell a programmer that the program violated the standard.
15.5.2.13 Restrictions on entities associated with dummy arguments
While an entity is associated with a dummy argument, the following
restrictions hold.
(1) Does not apply
(2) Does not apply
(3) Action that affects the value of the entity or any subobject
of it shall be taken only through the dummy argument unless
(a) Does not apply
(b) Does not apply
(c) Does not apply
(d) Does not apply
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug libfortran/95293] Fortran not passing array by reference
2020-05-23 20:36 [Bug libfortran/95293] New: Fortran not passing array by reference david.sagan at gmail dot com
` (6 preceding siblings ...)
2020-05-24 16:27 ` sgk at troutmask dot apl.washington.edu
@ 2020-07-08 12:24 ` dominiq at lps dot ens.fr
2020-07-08 18:42 ` kargl at gcc dot gnu.org
` (3 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: dominiq at lps dot ens.fr @ 2020-07-08 12:24 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95293
Dominique d'Humieres <dominiq at lps dot ens.fr> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |WAITING
Ever confirmed|0 |1
Last reconfirmed| |2020-07-08
--- Comment #8 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
Isn't it an aliasing problem?
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug libfortran/95293] Fortran not passing array by reference
2020-05-23 20:36 [Bug libfortran/95293] New: Fortran not passing array by reference david.sagan at gmail dot com
` (7 preceding siblings ...)
2020-07-08 12:24 ` dominiq at lps dot ens.fr
@ 2020-07-08 18:42 ` kargl at gcc dot gnu.org
2020-12-02 21:47 ` dominiq at lps dot ens.fr
` (2 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: kargl at gcc dot gnu.org @ 2020-07-08 18:42 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95293
--- Comment #9 from kargl at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #8)
> Isn't it an aliasing problem?
No. It is not an aliasing problem. It is an invalid
program giving a result that the programmer does not
expect. This is not a numbered constraint, and may be
difficult to reliably detect, so the Fortran standard
does not require a Fortran processor to catch the
error.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug libfortran/95293] Fortran not passing array by reference
2020-05-23 20:36 [Bug libfortran/95293] New: Fortran not passing array by reference david.sagan at gmail dot com
` (8 preceding siblings ...)
2020-07-08 18:42 ` kargl at gcc dot gnu.org
@ 2020-12-02 21:47 ` dominiq at lps dot ens.fr
2020-12-03 7:28 ` tkoenig at gcc dot gnu.org
2020-12-07 14:34 ` dominiq at lps dot ens.fr
11 siblings, 0 replies; 13+ messages in thread
From: dominiq at lps dot ens.fr @ 2020-12-02 21:47 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95293
--- Comment #10 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
Could this PR be closed as INVALID?
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug libfortran/95293] Fortran not passing array by reference
2020-05-23 20:36 [Bug libfortran/95293] New: Fortran not passing array by reference david.sagan at gmail dot com
` (9 preceding siblings ...)
2020-12-02 21:47 ` dominiq at lps dot ens.fr
@ 2020-12-03 7:28 ` tkoenig at gcc dot gnu.org
2020-12-07 14:34 ` dominiq at lps dot ens.fr
11 siblings, 0 replies; 13+ messages in thread
From: tkoenig at gcc dot gnu.org @ 2020-12-03 7:28 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95293
--- Comment #11 from Thomas Koenig <tkoenig at gcc dot gnu.org> ---
(In reply to Dominique d'Humieres from comment #10)
> Could this PR be closed as INVALID?
Yes, I think so.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug libfortran/95293] Fortran not passing array by reference
2020-05-23 20:36 [Bug libfortran/95293] New: Fortran not passing array by reference david.sagan at gmail dot com
` (10 preceding siblings ...)
2020-12-03 7:28 ` tkoenig at gcc dot gnu.org
@ 2020-12-07 14:34 ` dominiq at lps dot ens.fr
11 siblings, 0 replies; 13+ messages in thread
From: dominiq at lps dot ens.fr @ 2020-12-07 14:34 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95293
Dominique d'Humieres <dominiq at lps dot ens.fr> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|WAITING |RESOLVED
Resolution|--- |INVALID
--- Comment #12 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> > Could this PR be closed as INVALID?
>
> Yes, I think so.
So closing.
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2020-12-07 14:34 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-05-23 20:36 [Bug libfortran/95293] New: Fortran not passing array by reference david.sagan at gmail dot com
2020-05-23 22:26 ` [Bug libfortran/95293] " kargl at gcc dot gnu.org
2020-05-23 22:43 ` david.sagan at gmail dot com
2020-05-24 1:53 ` sgk at troutmask dot apl.washington.edu
2020-05-24 6:47 ` tkoenig at gcc dot gnu.org
2020-05-24 7:55 ` sgk at troutmask dot apl.washington.edu
2020-05-24 14:45 ` david.sagan at gmail dot com
2020-05-24 16:27 ` sgk at troutmask dot apl.washington.edu
2020-07-08 12:24 ` dominiq at lps dot ens.fr
2020-07-08 18:42 ` kargl at gcc dot gnu.org
2020-12-02 21:47 ` dominiq at lps dot ens.fr
2020-12-03 7:28 ` tkoenig at gcc dot gnu.org
2020-12-07 14:34 ` dominiq at lps dot ens.fr
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).