This is the mail archive of the gcc-patches@gcc.gnu.org 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] |
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 time". http://groups.google.co.uk/group/comp.lang.fortran/browse_thread/thread/100b8994f011019b/529d9c3ae011171f?hl=en#529d9c3ae011171f I apologise that it was the errors in my implementation of array TRANSFER that triggered this thread.
(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 ChangeLog.
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] |