For what it is worth.
On 2/10/22 11:49 AM, Harald Anlauf via Fortran wrote:
Hi Paul,
Am 10.02.22 um 13:25 schrieb Paul Richard Thomas via Fortran:
Conclusions on ifort:
(i) The agreement between gfortran, with the patch applied, and ifort is
strongest of all the other brands;
(ii) The disagree
Dear Fortranners,
when referencing a bad array section after an erroneous previous
declaration we might hit an assert. The assert can be replaced
by a more gracious error recovery. Reported by Gerhard.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
From d0250b563eb51f5f5fb
Hi Paul,
Am 10.02.22 um 13:25 schrieb Paul Richard Thomas via Fortran:
Conclusions on ifort:
(i) The agreement between gfortran, with the patch applied, and ifort is
strongest of all the other brands;
(ii) The disagreements are all down to the treatment of the parent
component of arrays of exten
Hi Harald,
I have run your modified version of finalize_38.f90, and now I see
> that you can get a bloody head just from scratching too much...
>
> crayftn 12.0.2:
>
> 1, 3, 1
>
It appears that Cray interpret a derived type constructor as being a
function call and so "6 If a specification ex
On 10.02.22 11:07, Roger Sayle wrote:
The fix is to tweak trans-common.cc to respect the target's NO_DOT_IN_LABEL
(and NO_DOLLAR_IN_LABEL) when generating internal equiv.%d symbols.
In general, I think the patch is okay – but as '_' is a valid identifier
and with -fdollar-ok '$' is valid as we
This patch fixes 9 unexpected failures in the gfortran testsuite on
nvptx-none. The issue is that gfortran's EQUIVALENCE internally uses
symbols such as "equiv.0" even on platforms that define NO_DOT_IN_LABEL.
On nvptx-none, this then results in the following error message(s):
ptxas application p
