Dear all,

this patch extends the previous version by adding further code testing
the presence of an optional deferred-length character argument also
in the function initialization code.  This allows to re-enable a
commented-out test in v2.

Regtested on x86_64-pc-linux-gnu.  OK for mainline?

Thanks,
Harald


On 11/28/23 20:56, Harald Anlauf wrote:
> Hi FX,
> 
> On 11/28/23 18:07, FX Coudert wrote:
>> Hi Harald,
>>
>> The patch looks OK to me. Probably wait a bit for another opinion, 
>> since I’m not that active and I may have missed something.
>>
>> Thanks,
>> FX
> 
> thanks for having a look.
> 
> In the meantime I got an automated mail from the Linaro testers.
> According to it there is a runtime failure of the testcase on
> aarch64.  I couldn't see any useful traceback or else.
> 
> I tried the testcase on x86 with different options and found
> an unexpected result only with -fsanitize=undefined and only
> for the case of a rank-1 dummy when there is no actual argument
> and the passed to another subroutine.  (valgrind is happy.)
> 
> Reduced reproducer:
> 
> ! this fails with -fsanitize=undefined
> program main
>    call test_rank1 ()
> contains
>    subroutine test_rank1 (msg1)
>      character(:), optional, allocatable :: msg1(:)
>      if (present (msg1)) stop 77
>      call assert_rank1 ()        ! <- no problem here
>      call assert_rank1 (msg1)    ! <- problematic code path
>    end
> 
>    subroutine assert_rank1 (msg2)
>      character(:), optional, allocatable :: msg2(:)
>      if (present (msg2)) stop 99 ! <- no problem if commented
>    end
> end
> 
> 
> As far as I can tell, this could be a pre-existing (latent)
> issue.  By looking at the tree-dump, the only thing that
> appears fishy has been there before.  But then I am only
> guessing that this is the problem observed on aarch64.
> 
> I have disabled the related call in the testcase of the
> attached revised version.  As I do not see anything else,
> I wonder if one could proceed with the current version
> but open a PR for the reduced case above, unless someone
> can pinpoint the place that is responsible for the above
> failure.  (Is it the caller, or rather the function entry
> code in the callee?)
> 
> Cheers,
> Harald
>