[Bug fortran/67779] Strange ordering with strings in extended object

[pault at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67779

Paul Thomas <pault at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |pault at gcc dot gnu.org

--- Comment #15 from Paul Thomas <pault at gcc dot gnu.org> ---
Created attachment 37185
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37185&action=edit
A provisional patch for the PR

This patch has two objectives:

(i) To fix the ICE in trans.c. This is fixed by the change to trans-stmt.c.
Note that I have not checked to see if this has been cured - my tree is
somewhat out of date. In anycase, expr3 should never be coming back as a
NOP_EXPR; and

(ii) Fix the original problem in sorting. As noted previously, this is
associated with the array offset being zero, rather than -1. Setting
parmse.use_offset = 0; rather than one does the job.

Rather alarmingly, in my opinion, the patch regtests OK. This begs the question
as to why parmse.use_offset was set in the first place. In the absence of any
explanation, it might be judicious to only set it for full arrays; ie. not to
set it for array sections, as is the case here.

s/        write( string_array(i)%value, '(a,i0)' ) "String = ", 11 - i
 /        write( string_array(i)%value, '(a,i2)' ) "String = ", 11 - i /

Allows the original testcase not only to run but to sort string_array
correctly. Is this indicative of a bug in LLT?

I'll take the PR.

Paul