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
