>
>
> Hi Harald,
> Indeed, the gfc_fatal_error always wins.
:-(
>
> 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 patc
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 sp
Hi Harald,
>
> the patch is OK, but I had to manually fix it. I wonder how you managed
> to produce:
>
Yes, I had to use --whitespace fix when I reapplied it a few minutes ago.
>
> diff --git a/gcc/testsuite/gfortran.dg/pr93484.f90
>
I had followed comment 1 in the PR and wrongly named the fil
Hi Paul,
the patch is OK, but I had to manually fix it. I wonder how you managed
to produce:
diff --git a/gcc/testsuite/gfortran.dg/pr93484.f90
b/gcc/testsuite/gfortran.dg/pr93484.f90
new file mode 100644
index 000..4dcad47e8da
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr103471.f90
Hi All,
This is a more or less obvious patch. The action is in resolve.cc. The
chunk in symbol.cc is a tidy up of a diagnostic marker to distinguish where
the 'no IMPLICIT type' error was coming from and the chunk in trans-decl.cc
follows from discussion with Harald on the PR.
Regtests fine. OK f