https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539
--- Comment #13 from Thomas Koenig <tkoenig at gcc dot gnu.org> ---
I'm afraid the tree dumps will not help a lot - I know what they
look like before and after, but I don't know what is wrong with it.
I would therefore ask you to reduce the test case, maybe starting
with the wrong-code issue.
I'm describing now what I would do, if I had access to SPEC.
One possibility is using -Os. This restores the behavior of using
the library function for packing / unpacking. You can check which file(s)
you need to compile using that flag to make that problem go away.
(A more fancy way would be to introduce, in my local tree, a new
option to specifically disable that optimization.) The relevant part is
in trans-array.c:
/* When optmizing, we can use gfc_conv_subref_array_arg for
8138 making the packing and unpacking operation visible to
the
8139 optimizers. */
8140
8141 if (g77 && optimize && !optimize_size && expr->expr_type
== EXPR_VARIABLE
8142 && !is_pointer (expr) && (fsym == NULL
8143 || fsym->ts.type !=
BT_ASSUMED))
8144 {
8145 gfc_conv_subref_array_arg (se, expr, g77,
8146 fsym ? fsym->attr.intent
: INTENT_INOUT,
8147 false, fsym, proc_name,
sym);
8148 return;
8149 }
8150
)
Once the file is known, I would set a breakpoint at the call to
gfc_conv_subref_arg and look at expr, fsym and proc_name to pinpoint
which part of the source code is affected.
Once that is known, I would debug the compiled program, seeing
what conditions are when the program is called - what kind of
array is passed, what is its rank, what are the dimension, are they
contiguous, and what does the dummy argument on the callee's side look like,
and work on reducing the test case from there.
Another point - maybe it would be a good idea to see how at least
one of the regular Fortran people could get access to SPEC.
I would be willing to sign an NDA, but I would _not_ be willing
to pay for it. I suppose it would be no good to ask the FSF,
they would probably go bananas :-)
