[Bug fortran/119800] Use of Fortran TRANSFER intrinsic with argument of derived type containing allocatable causes storage aliasing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119800 --- Comment #7 from Keith Refson --- Yes, definitely. Any scalar with an ultimate allocatable component should be warned about.
[Bug fortran/119800] Use of Fortran TRANSFER intrinsic with argument of derived type containing allocatable causes storage aliasing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119800 --- Comment #6 from kargls at comcast dot net --- (In reply to kargls from comment #5) > (In reply to anlauf from comment #4) > > (In reply to Keith Refson from comment #3) > > > I think it probably also needs to flag up if MOLD contains an allocatable > > > or > > > pointer component too. Modifying the example to TRANSFER to an integer, > > > followed by a second TRANSFER with SOURCE= as an integer array and MOLD as > > > the type, should warn on both instances. > > > > Indeed, the problem is MOLD, not SOURCE. > > Yeah, Keith is correct in that the patch should also check MOLD. > In looking at the nascent patch, we likely need to walk the components as well. Is something like the following an issue? type c integer, allocatable :: z(:) end type c type a integer i type(c) b ! <-- allocatable component needs checking. end type a Hmmm, attr contain an alloc_comp and pointer_comp field.
[Bug fortran/119800] Use of Fortran TRANSFER intrinsic with argument of derived type containing allocatable causes storage aliasing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119800 --- Comment #5 from kargls at comcast dot net --- (In reply to anlauf from comment #4) > (In reply to Keith Refson from comment #3) > > I think it probably also needs to flag up if MOLD contains an allocatable or > > pointer component too. Modifying the example to TRANSFER to an integer, > > followed by a second TRANSFER with SOURCE= as an integer array and MOLD as > > the type, should warn on both instances. > > Indeed, the problem is MOLD, not SOURCE. Yeah, Keith is correct in that the patch should also check MOLD. gfortran's behavior with TRANSFER, I believe, matches the requirements of the Fortran standard. F2023, 16.9.212 talks about physical representation of SOURCE and MOLD. We're copying the physical address of the allocated memory and perhaps a dope vector instead of doing a deep copy. We probably want to key the warning off of -Wall instead of -Wsurprising. I suspect more people use the former, and thus, will see the warning.
[Bug fortran/119800] Use of Fortran TRANSFER intrinsic with argument of derived type containing allocatable causes storage aliasing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119800 --- Comment #4 from anlauf at gcc dot gnu.org --- (In reply to Keith Refson from comment #3) > I think it probably also needs to flag up if MOLD contains an allocatable or > pointer component too. Modifying the example to TRANSFER to an integer, > followed by a second TRANSFER with SOURCE= as an integer array and MOLD as > the type, should warn on both instances. Indeed, the problem is MOLD, not SOURCE.
[Bug fortran/119800] Use of Fortran TRANSFER intrinsic with argument of derived type containing allocatable causes storage aliasing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119800 --- Comment #3 from Keith Refson --- I think it probably also needs to flag up if MOLD contains an allocatable or pointer component too. Modifying the example to TRANSFER to an integer, followed by a second TRANSFER with SOURCE= as an integer array and MOLD as the type, should warn on both instances.
[Bug fortran/119800] Use of Fortran TRANSFER intrinsic with argument of derived type containing allocatable causes storage aliasing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119800
--- Comment #2 from kargls at comcast dot net ---
(In reply to kargls from comment #1)
> (In reply to Keith Refson from comment #0)
>
> >
> > I suggest at least issuing a warning to expect undefined run-time behaviour!
> >
>
> Here's a patch hidden behind -Wsurprising.
>
And now the patch. :-)
diff --git a/gcc/fortran/check.cc b/gcc/fortran/check.cc
index 9c66c25e059..9aef66b4616 100644
--- a/gcc/fortran/check.cc
+++ b/gcc/fortran/check.cc
@@ -6856,6 +6856,32 @@ gfc_check_transfer (gfc_expr *source, gfc_expr *mold,
gfc_expr *size)
if (!warn_surprising)
return true;
+ /* TRANSFER does not do a deep copy. So, if SOURCE contains an allocatable
+ or pointer component, then this can lead to undefined behavior. */
+
+ if (source->expr_type == EXPR_VARIABLE && source->ts.type == BT_DERIVED)
+{
+ bool saw = false;
+ gfc_component *c;
+
+ for (c = source->ts.u.derived->components; c; c = c->next)
+ {
+ if (c->attr.allocatable || c->attr.pointer)
+ {
+ saw = true;
+ break;
+ }
+ }
+
+ if (saw)
+ gfc_warning (OPT_Wsurprising,
+"SOURCE at %L contains an ALLOCATABLE or POINTER "
+"component, which may lead to undefined behavior because "
+"TRANSFER does not do a deep copy",
+&source->where);
+}
+
+
/* If we can't calculate the sizes, we cannot check any more.
Return true for that case. */
[Bug fortran/119800] Use of Fortran TRANSFER intrinsic with argument of derived type containing allocatable causes storage aliasing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119800 kargls at comcast dot net changed: What|Removed |Added CC||kargls at comcast dot net --- Comment #1 from kargls at comcast dot net --- (In reply to Keith Refson from comment #0) > > I suggest at least issuing a warning to expect undefined run-time behaviour! > Here's a patch hidden behind -Wsurprising. % gfcx -o z -Wsurprising a.f90 a.f90:10:19: 10 | b = transfer(a, b) | 1 Warning: SOURCE at (1) contains an ALLOCATABLE or POINTER component, which may lead to undefined behavior because TRANSFER does not do a deep copy [-Wsurprising] It's a partial patch in that it only handles SOURCE with a derived type. The patch likely needs to be expanded to handle a polymorphic entity. I know very little about CLASS.
