https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86277
--- Comment #20 from anlauf at gcc dot gnu.org ---
(In reply to Mikael Morin from comment #18)
> Created attachment 55300 [details]
> Alternative patch v2
This patch fails for me on several occasions including the testsuite.
I guess the logic was intended as follows:
diff --git a/gcc/fortran/trans-array.cc b/gcc/fortran/trans-array.cc
index e1c75e9fe02..ebadda20004 100644
--- a/gcc/fortran/trans-array.cc
+++ b/gcc/fortran/trans-array.cc
@@ -1117,7 +1117,7 @@ gfc_trans_allocate_array_storage (stmtblock_t * pre,
stmtblock_t * post,
desc = info->descriptor;
info->offset = gfc_index_zero_node;
- if (size == NULL_TREE || integer_zerop (size))
+ if (size == NULL_TREE)
{
/* A callee allocated array. */
gfc_conv_descriptor_data_set (pre, desc, null_pointer_node);
@@ -1129,6 +1129,7 @@ gfc_trans_allocate_array_storage (stmtblock_t * pre,
stmtblock_t * post,
onstack = !dynamic && initial == NULL_TREE
&& (flag_stack_arrays
|| gfc_can_put_var_on_stack (size));
+ onstack = onstack && !integer_zerop (size);
if (onstack)
{
This seems to work on the present cases and regtests almost cleanly, with
the only exception being gfortran.dg/pr69955.f90, which needs an adjustment
of the scan-tree-dump pattern due to an additional __builtin_malloc.
I am beginning to think that there are multiple issues exhibited here: a
wrong-code issue, which is fixed by the above, and a missed-optimization,
which I tried to address with my initial patch.
If the above patch turns out to fix the wrong-code issue safely, I would
like to prepare it for mainline, and if it survives there for some time,
consider a backport to 13-branch in time for 13.2 release.
The missed optimization with superfluous temporaries could then be split
off to a separate PR and addressed only for future (14+) branches.
I'll prepare additional testcases for character and type and see if the above
patch is sufficient.
