This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Patch, fortran] PR31193 - ICE on non-constant character transfer

:ADDPATCH fortran:

This is the only member of the TRANSFER meta-bug that does not involve
gfc_simplify_transfer.  The title is a bit odd because it was
precisely character literals that were the problem.... never mind:)

It should be noted that this arose out of a comp.lang.fortran thread
that got a little heated about the readines of gfortran for "prime
I apologise that it was the errors in my implementation of array
TRANSFER that triggered this thread.

The problem turned out to be twofold:

(i) The ICE came about because gfc_typenode_for_spec was being used to
obtain the TREE_TYPE for the final cast of the function result and the
allocation of memory.  Unfortunately, character constants do not have
a character length field in their typespec and this is the cause of
the ICE.
(ii) On investigation, using a substring for MOLD also cause an ICE
because the result was being cast to the original string length.

Both the fixes are straightforward and are adequately described in the

The testcase is an evolution of the reporter's to make sure that all
sources of a character typespec for MOLD do the right thing.  It is #3
because the original occupant with that number involved derived types
and was just too system dependent to be useful.

Bootstrapped and regtested on Cygwin_NT/amd64 - OK for trunk and,
eventually, 4.2?


Saint Augustine - "O Lord, help me to be pure, but not yet"

Attachment: Change.Logs
Description: Binary data

Attachment: pr31193.diff
Description: Binary data

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]