Compilation of the patch just finished here.
I now get an ICE (regression) on the following code:
program minimal_bug
implicit none
type :: nested_t
type(nested_t), allocatable :: children(:)
type(nested_t), allocatable :: relatives(:)
end type nested_t
type(nested_t) :: a
end
1 | program minimal_bug
| 1
internal compiler error: Segmentation fault
0x364259b internal_error(char const*, ...)
../../gcc-trunk/gcc/diagnostic-global-context.cc:787
0x1a68a0e crash_signal
../../gcc-trunk/gcc/toplev.cc:323
0x11092d4 contains_struct_check(tree_node*, tree_node_structure_enum,
char const*, int, char const*)
../../gcc-trunk/gcc/tree.h:3891
0x11092d4 gfc_build_addr_expr(tree_node*, tree_node*)
../../gcc-trunk/gcc/fortran/trans.cc:348
0x112a58a structure_alloc_comps
../../gcc-trunk/gcc/fortran/trans-array.cc:11038
0x11276d2 structure_alloc_comps
../../gcc-trunk/gcc/fortran/trans-array.cc:10251
0x112a0c6 structure_alloc_comps
../../gcc-trunk/gcc/fortran/trans-array.cc:10960
0x11276d2 structure_alloc_comps
../../gcc-trunk/gcc/fortran/trans-array.cc:10251
0x112a0c6 structure_alloc_comps
../../gcc-trunk/gcc/fortran/trans-array.cc:10960
0x11276d2 structure_alloc_comps
../../gcc-trunk/gcc/fortran/trans-array.cc:10251
0x112a0c6 structure_alloc_comps
Looks like an infinite recursion.
Can you please check?
Thanks,
Harald
Am 06.11.25 um 21:15 schrieb Harald Anlauf:
Hi Christopher!
Am 05.11.25 um 22:30 schrieb Christopher Albert:
On Wed, 5 Nov 2025 13:12:04 -0800
Steve Kargl <[email protected]> wrote:
On Sun, Nov 02, 2025 at 02:20:59PM +0100, Christopher Albert wrote:
Rebased again on trunk with small corrections, correct text format
directly pasted in the e-mail and without attachments (sorry for
the mess before, I'm new to to the GCC patch workflow). Tested on
x86_64 by Stefan Kargl on FreeBSD and by myself on Linux. See
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121628 for details.
Can you attach the diff file? When I save your email
to a text and open it in nedit, there as numerous non-ASCII
characters embedded in the diff. Specifically, I see
Unicode character (U+00C2), and in hexdump the hex digits
are c2a0 where I expect one or more spaces.
Sorry, some trouble with email client. I try claws-mail now and attach
the diff file.
I could not find out if you have a copyright assignment on file.
Since you are not listed in MAINTAINERS, I assume this is not the case.
In this situation I believe you need to sign-off your contribution, see:
https://gcc.gnu.org/dco.html
***
I just applied your patch here, and get a couple of complaints about
white-space issues. Jerry might be able to remedy them.
Regarding coding style: I would prefer if you stick to the GNU style
and tried to keep lines below the 80 characters mark. But this is
not a showstopper.
I wonder if the change you applied to conv_intrinsic_atomic_op is of
the same origin as what Andre mentioned in
https://gcc.gnu.org/pipermail/fortran/2025-October/062998.html
I didn't have time to check, but your comment lead me to that
assumption. Still we can keep your version.
diff --git a/libgfortran/libgfortran.h b/libgfortran/libgfortran.h
index 25c3cb6641c..71ec640b335 100644
--- a/libgfortran/libgfortran.h
+++ b/libgfortran/libgfortran.h
@@ -914,6 +914,14 @@ internal_proto(xcalloc);
extern void *xrealloc (void *, size_t);
internal_proto(xrealloc);
+/* deep_copy.c - Runtime helper for recursive allocatable array
components */
+
+struct CFI_cdesc_t;
^^^^^^^^^^^^^^^^^^^
Is that a left-over from previous work? It is not needed and
should be removed.
Otherwise I am fine so far with it, and it appears that Steve
and Jerry have tested it already.
Thanks for the patch!
Harald
