------- Comment #4 from brooks at gcc dot gnu dot org 2007-05-29 05:59 -------
I misunderstood something slightly in that last comment; MERGE is elemental, so
the conforming I mentioned doesn't matter. Also, my guess that fixing the
transfer("A", "x", 20) problem would fix the whole thing proved to be
incorrect.
So, even once the first bit is fixed, if we change the code to be legitimate,
as follows, then it still has an error:
character(len=20) :: string
logical :: a(20)
write(*,*) transfer (merge (transfer("A", "x", 20), "b", a), string )
end
Specifically, we ICE by failing the "gcc_assert (integer_zerop (loop ->
from[n]))" at line 593 of trans-array.c, when doing gfc_conv... stuff to the
arguments of the outer transfer function.
I'm having a bear of a time tracking down why this is happening. The problem
is that we're generating a temporary, so loop->temp_dim is 1 (as set in
gfc_trans_constant_array_constructor, line 1576). However, the loop seems to
be picking up dimensions from the result of the inner transfer function
somehow. Walking through the ss list for the loop gives a GFC_SS_CONSTRUCTOR,
a GFC_SS_SCALAR, and a GFC_SS_SECTION, and the GFC_SS_SECTION causes the
info->start[0] and info->end[0] values to be set (to 1 and 20, respectively) in
gfc_conv_ss_startstride, which then propagate to the from[0] and to[0] values
for the loop.
I can't seem to duplicate this with any other set of functions. It's only
happening with characters, not integers, and if I break up the expression or
substitute other things for transfer and merge, it doesn't replicate this
behavior.
Help?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31610
