public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug fortran/107968] New: array slicing gives wrong result for an array pointer defined in a subroutine
@ 2022-12-05 7:16 dreier at dkrz dot de
2022-12-05 19:12 ` [Bug fortran/107968] " anlauf at gcc dot gnu.org
2022-12-05 21:36 ` anlauf at gcc dot gnu.org
0 siblings, 2 replies; 3+ messages in thread
From: dreier at dkrz dot de @ 2022-12-05 7:16 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107968
Bug ID: 107968
Summary: array slicing gives wrong result for an array pointer
defined in a subroutine
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: dreier at dkrz dot de
Target Milestone: ---
Created attachment 54010
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54010&action=edit
source code
The following code show some weird behavior to me:
```
PROGRAM foo
implicit none
TYPE t_geographical_coordinates
REAL :: lon
REAL :: lat
END TYPE t_geographical_coordinates
TYPE t_vertices
REAL, POINTER :: vlon(:) => null()
REAL, POINTER :: vlat(:) => null()
END TYPE t_vertices
TYPE(t_vertices), POINTER :: vertices_pointer
TYPE(t_vertices), TARGET :: vertices_target
TYPE(t_geographical_coordinates), ALLOCATABLE, TARGET :: vertex(:)
! initialization
ALLOCATE(vertex(2))
vertex%lon = 1
vertex%lat = 2
! obtain pointer to (non-contiguous) field
vertices_target%vlon => vertex%lon
! set pointer in a subroutine
CALL set_vertices_pointer(vertices_target)
WRITE (0,*) vertices_pointer%vlon
WRITE (0,*) vertices_pointer%vlon(1:)
! It seems that setting the pointer in a subroutine does something else
than
! setting it directly. Furthermore uncommenting the following line fixes
the
! issue but changes the output of the lines above ?!
! vertices_pointer => vertices_target
CONTAINS
SUBROUTINE set_vertices_pointer(vertices)
TYPE(t_vertices), POINTER, INTENT(IN) :: vertices
vertices_pointer => vertices
END SUBROUTINE set_vertices_pointer
END PROGRAM foo
```
I expect the output to be:
```
1.00000000 1.00000000
1.00000000 1.00000000
```
Instead, the compiled program gives me
```
1.00000000 1.00000000
1.00000000 2.00000000
```
Compiled with gfortran 12.2 on Ubuntu 22.10.
No warnings with `-Wall -Wextra`. Same behavior with `-fno-strict-aliasing
-fwrapv`.
^ permalink raw reply [flat|nested] 3+ messages in thread
* [Bug fortran/107968] array slicing gives wrong result for an array pointer defined in a subroutine
2022-12-05 7:16 [Bug fortran/107968] New: array slicing gives wrong result for an array pointer defined in a subroutine dreier at dkrz dot de
@ 2022-12-05 19:12 ` anlauf at gcc dot gnu.org
2022-12-05 21:36 ` anlauf at gcc dot gnu.org
1 sibling, 0 replies; 3+ messages in thread
From: anlauf at gcc dot gnu.org @ 2022-12-05 19:12 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107968
anlauf at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Last reconfirmed| |2022-12-05
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
CC| |anlauf at gcc dot gnu.org
--- Comment #1 from anlauf at gcc dot gnu.org ---
Confirmed.
A look at the tree dump shows a funny expansion of the array section in
the data transfer (write statement). It appears that some optimization
of the transfer of arrays is attempted, but the stride looks wrong.
Replacing
WRITE (0,*) vertices_pointer%vlon(1:)
by any of the following produces different - working - output:
WRITE (0,*) [vertices_pointer%vlon(1:)]
WRITE (0,*) (vertices_pointer%vlon(1:))
WRITE (0,*) (vertices_pointer%vlon(i),i=1,size(vertices_pointer%vlon))
And - as reported - why should the addition of a (dead) pointer assignment
after the write change the way the array section is expanded?
Looking at older gfortran version, all tested seem to fail.
And with the dead pointer assignment uncommented, gfortran-7 ICEs.
^ permalink raw reply [flat|nested] 3+ messages in thread
* [Bug fortran/107968] array slicing gives wrong result for an array pointer defined in a subroutine
2022-12-05 7:16 [Bug fortran/107968] New: array slicing gives wrong result for an array pointer defined in a subroutine dreier at dkrz dot de
2022-12-05 19:12 ` [Bug fortran/107968] " anlauf at gcc dot gnu.org
@ 2022-12-05 21:36 ` anlauf at gcc dot gnu.org
1 sibling, 0 replies; 3+ messages in thread
From: anlauf at gcc dot gnu.org @ 2022-12-05 21:36 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107968
--- Comment #2 from anlauf at gcc dot gnu.org ---
The following attempt fixes the erroneous output:
diff --git a/gcc/fortran/trans-io.cc b/gcc/fortran/trans-io.cc
index 9f86815388c..c4525f67ef3 100644
--- a/gcc/fortran/trans-io.cc
+++ b/gcc/fortran/trans-io.cc
@@ -2641,6 +2641,9 @@ gfc_trans_transfer (gfc_code * code)
seen_vector = true;
break;
}
+
+ if (!seen_vector && !gfc_is_not_contiguous (expr))
+ goto scalarize;
}
if (seen_vector && last_dt == READ)
However, this defeats the optimization on array I/O and regresses on
gfortran.dg/implied_do_io_1.f90
gfortran.dg/implied_do_io_4.f90
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2022-12-05 21:36 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-12-05 7:16 [Bug fortran/107968] New: array slicing gives wrong result for an array pointer defined in a subroutine dreier at dkrz dot de
2022-12-05 19:12 ` [Bug fortran/107968] " anlauf at gcc dot gnu.org
2022-12-05 21:36 ` anlauf at gcc dot gnu.org
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).