https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108895
Thomas Schwinge <tschwinge at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Last reconfirmed| |2023-02-23
CC| |burnus at gcc dot gnu.org,
| |tschwinge at gcc dot gnu.org
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
--- Comment #1 from Thomas Schwinge <tschwinge at gcc dot gnu.org> ---
Thanks for the detailed report.
(In reply to Henry Le Berre from comment #0)
> > program p_main
> >
> > real(kind(0d0)), allocatable, dimension(:) :: arrs
> > !$acc declare create(arrs)
> >
> > allocate(arrs(1000))
> > !$acc enter data create(arrs(1000))
> > !$acc update device(arrs(1:1000))
> >
> > end program
>
> Compiled with:
>
> > gfortran -g -fopenacc -foffload-options=-march=gfx90a sample.f90 -o sample
>
> Produces:
>
> > [hberre3@102:instinct]:gcc-acc-test $ ./sample
> >
> > Program received signal SIGSEGV: Segmentation fault - invalid memory
> > reference.
> >
> > Backtrace for this error:
> > [...]
Confirmed for GCN offloading.
For nvptx offloading, we get "similarly":
libgomp: cuMemGetAddressRange_v2 error: named symbol not found
libgomp: Copying of host object [0x10b6090..0x10b7fd0) to dev object
[0x7fb75effe2c8..0x7fb75f000208) failed
For nvfortran 23.1-0, there's no execution failure.
> Observations:
>
> 1) If the length/size of the array were smaller (say 10 or 100) no
> segmentation fault is observed, possibly indicating silent R/W operations to
> memory we don't own.
>
> 2) On ORNL Summit's GCC 8.3.1 (nvptx), this sample does not produce a
> segfault.
Can't really recommend using five years old GCC 8 for code offloading anymore,
but as a cross-check that's been valuable, of course.
I see this execution failure also for GCC 12, 11, 10 -- don't have 9, 8 builds
around anymore. Not sure if it's a regression really, of if this GCC 8 just
didn't run into this for other reasons.
I however do see no execution failure for devel/omp/gcc-12, devel/omp/gcc-11,
devel/omp/gcc-10 branches nvptx offloading builds.
This may be due to different code paths being taken as the latter branches
contain preliminary support for OpenACC "Changes from Version 2.0 to 2.5": "The
'declare create' directive with a Fortran 'allocatable' has new behavior",
which GCC release branches and master branch don't support yet. (As I also
mentioned in your PR106643 "[gfortran + OpenACC] Allocate in module causes
refcount error", for example.) However, that's no excuse for the execution
failure seen here, of course.
Will need to investigate.
> 3) If I translate this sample to C, no matter how large the array is, a
> segfault is not produced.
Very likely it's due to some Fortran-specific code paths.
