Hi Tobias,
the patch looks reasonable to me. I wouldn't know where to get the "correct"
charlen either. In fact I have the same problem at the moment with an array
spec. Anyway, one small question: Your testcase does not have a dg-do line. Is
this intentional?
Thanks for the patch,
Andre
On Wed, 15 Jan 2025 23:49:01 +0100
Tobias Burnus <tbur...@baylibre.com> wrote:
> As shown in the PR, updating the function declaration
> for _gfortran_pack_char could leak into the character
> typespec back-end declaration to the the caller by
> setting the backend declaration of the caller.
>
> The problem is that that function returns a character string
> and in trans-intrinsic.cc, we obtain the function declaration
> from the call (which may not always work, hmm).
>
> In any case, the routine already takes care to of copying
> the ts->u.cl character length data,
> i.e. sym->formal[->next etc.]->ts.u.cl
> but it didn't do so for the result variable, itself,
> i.e. sym->ts.u.cl.
>
> Well, this patch does so – I am just not completely sure
> what it should do for the character length. In Fortran,
> the result can either be deferred - or has an explicit
> length expression (such as 'len(n)'). I now went for
> 'NULL' instead of copying the length from the caller.
>
> For this case, it does not matter as '_s' also has
> ts->u.cl->length == NULL;
>
> Build & regtested on x86-64-gnu-linux.
> OK? Other thoughts?
>
> Tobias
>
> PS: The issue is long standing but since a recent GCC 15
> commit (cf. PR), the issue is now triggered and causes an ICE
> for the testcase from the PR.
--
Andre Vehreschild * Email: vehre ad gmx dot de
