Re: [Patch, fortran] PR91717 - ICE on concatenating deferred-length character and character literal

[Paul Richard Thomas <paul dot richard dot thomas at gmail dot com>]

Hi Steve,

I have inserted a my_core%msg = '"" so that it is initialised. The
reallocation on assignment explicitly deals with an unallocated entity
or one of its allocatable components by allocation, rather than
reallocation.

I realise that my explanation of the patch might be a bit sparse. The
ultimate caller is frontend_passes.c(realloc_string_callback), which
looks for overlap even for scalar cases. The ICE came about because
there are no array references in the expressions being compared.
Flagging that there are identical component chains in this case and
returning 1 from gfc_dep_resolver covers this case.

OK to commit?

Cheers

Paul





realloc_string_callback)

On Thu, 12 Sep 2019 at 00:05, Steve Kargl
<sgk@troutmask.apl.washington.edu> wrote:
>
> On Wed, Sep 11, 2019 at 11:27:56PM +0100, Paul Richard Thomas wrote:
> > Hi Steve,
> >
> > Being an allocatable component, this code appears on entry into scope:
> >
> >   my_core.msg = 0B;
> >   my_core._msg_length = 0;
> >   {
> >
> > Thus, according to the standard, my_core%msg is defined.
> >
>
> I'll politely defer to the Fortran standard.
>
>   5.4.10 Allocatable variables
>
>   The allocation status of an allocatable variable is either allocated
>   or unallocated.  An allocatable variable becomes allocated as described
>   in 9.7.1.3. It becomes unallocated as described in 9.7.3.2.
>
>   An unallocated allocatable variable shall not be referenced or defined.
>
>   7.5.4.6 Default initialization for components
>
>   Allocatable components are always initialized to unallocated.
>
> In your testcase, you have an unallocatable allocatable entity
> referenced on the RHS in the first line that involves my_core%msg.
> From the Fortran standard's point of view, I believe the code is
> nonconforming.
>
>   type core
>     character (len=:), allocatable :: msg
>   end type
>
>   type(core) :: my_core
>
>   print *, allocated(my_core%msg)
>
> ! Comment out to avoid ICE.
> !  my_core%msg on RHS is unallocated in next line.
> !  my_core%msg = my_core%msg//"my message is:
> !  my_core%msg = my_core%msg//"Hello!"
> !
> !  if (my_core%msg .ne. "my message is: Hello!") stop 1
> end
>
> % gfcx -o z a.f90 && ./z
>  F
>
> > detected for this assignment even though no array references are
> > involved. There is certainly the need for a temporary, which the patch
> > generates.
> >
>
> Your patch may fix the ICE, but if the code compiles and
> execute.  You are getting the "right" answer fortuitiouly.
>
> Of course, I could be wrong.
>
> --
> Steve



-- 
"If you can't explain it simply, you don't understand it well enough"
- Albert Einstein