Re: [Patch, fortran] PR103471 - [11/12/13/14 Regression] ICE in gfc_typenode_for_spec, at fortran/trans-types.c:1114

[Harald Anlauf <anlauf@gmx.de>]

Hi Paul!

On 4/20/24 09:54, Paul Richard Thomas wrote:
>> subroutine sub
>>     implicit none
>>     real, external :: x
>>     real           :: y(10)
>>     integer :: kk
>>     print *, [real(x(k))]
>> !  print *, [real(y(k))]
>> end
>>
>
> This is another problem, somewhere upstream from resolve.cc, which I have
> just spent an hour failing to find. In the presence of both print
> statements, in no matter which order, it is the error in trans-decl.cc that
> applies.

Indeed, the gfc_fatal_error always wins.

(I had tried to replace it with gfc_error()/return NULL_TREE, but then
I hit an ICE later on.  When trying to find out who added the said
code, guess whom I found :)

>
>> Thus I have the impression that the testcase tests something different
>> on the one hand, and on the other I wonder if we would want to change
>> the error message and replace "no default type" to "no IMPLICIT type".
>> It still would not hit the fuzzy check, but that is something that
>> might not be important now.
>>
>
> The fuzzy check was intended to ensure that the error was being detected in
> the "right" place. I want to keep the "no default type" message for the
> time being at least so as to identify exactly where it comes from. Getting
> to trans-decl.cc with an unknown type is just wrong.

True.

> I'll come back to you on this.

This PR is marked as a regression.  Depending on your progress,
it might be worth to consider fixing what you think is needed
to get rid of the regression marker and defer the improvement
of the diagnostics to a second patch.

Harald

> Thanks for the report.
>
> Paul
>