Re: [PATCH] libgfortran: Fix libgfortran.so versioning on Solaris with subdirs
Hi FX, >> This patch fixes this by allowing for the new structure. >> Tested on i386-pc-solaris2.11 and sparc-sun-solaris2.11. >> >> Ok for trunk? > > OK to push, given it’s localised inside LIBGFOR_USE_SYMVER_SUN. > > I find it weird though that .libs is harcoded there. If we look at all the > lib*/Makefile.am in gcc, the only thing that ever needs to specify .libs is > for Solaris versioning. It feels like it should be more generic, as you say > (but that’s for longer term). look again ;-) libgo/Makefile.am has other unrelated instances for both setting LD_LIBRARY_PATH and related to AIX. It seems that libtool has no provision for operations other than compile (create .lo from sources) and link (create executable from libtool objects/archives). It you need something else, there's no way but to reach below the abstraction. I believe libtool could provide something like this, but apparently it doesn't. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
[PATCH, libgfortran] aix: Fix building fat library for AIX
aix: Fix building fat library for AIX With the change in subdirectories, the code for libgfortran fat libraries needs to be adjusted to explicitly reference the subdirectory. AIX creates fat library archives and the compiler itself can be built as either 32 bit or 64 bit application and default code generation. For the two, alternate versions of the compiler to interoperate, GCC needs to construct the fat libraries manually. The Makefile fragment had been trying to leverage as much of the existing targets and macros as possible. With the subdirectory change, the location of single.o is more obscured and cannot be determined without libtool. This patch references the location of the real object file more explicitly. Utilizing subst seems like overkill and unnecessary obscuration for a single object file. Either way, it's digging below the libtool abstraction layer. This also fixes Fortran bootstrap on AIX. Bootstrapped on powerpc-ibm-aix7.3.0.0 libgfortran/ChangeLog: * config/t-aix (all-local, libcaf_single): Explicitly reference caf/.libs/single.o diff --git a/libgfortran/config/t-aix b/libgfortran/config/t-aix index 0e50501d10e..099fc5d8b3a 100644 --- a/libgfortran/config/t-aix +++ b/libgfortran/config/t-aix @@ -7,6 +7,6 @@ ARX=$(shell echo $(AR) | sed -e 's/-X[^ ]*//g') all-local: $(ARX) -X$(BITS) rc .libs/$(PACKAGE).a ../ppc$(BITS)/$(PACKAGE)/.libs/$(PACKAGE).so.$(MAJOR) $(ARX) -X$(BITS) rc ../pthread/$(PACKAGE)/.libs/$(PACKAGE).a ../pthread/ppc$(BITS)/$(PACKAGE)/.libs/$(PACKAGE).so.$(MAJOR) - $(ARX) -X$(BITS) rc .libs/libcaf_single.a ../ppc$(BITS)/$(PACKAGE)/.libs/$(libcaf_single_la_OBJECTS:.lo=.o) - $(ARX) -X$(BITS) rc ../pthread/$(PACKAGE)/.libs/libcaf_single.a ../pthread/ppc$(BITS)/$(PACKAGE)/.libs/$(libcaf_single_la_OBJECTS:.lo=.o) + $(ARX) -X$(BITS) rc .libs/libcaf_single.a ../ppc$(BITS)/$(PACKAGE)/caf/.libs/single.o + $(ARX) -X$(BITS) rc ../pthread/$(PACKAGE)/.libs/libcaf_single.a ../pthread/ppc$(BITS)/$(PACKAGE)/caf/.libs/single.o endif
Re: [PATCH, libgfortran] aix: Fix building fat library for AIX
> libgfortran/ChangeLog: > * config/t-aix (all-local, libcaf_single): Explicitly reference > caf/.libs/single.o OK, and sorry for the breakage. FX
[PATCH] Fortran: improve attribute conflict checking [PR93635]
Dear all,
I've been contemplating whether to submit the attached patch.
It addresses an ICE-on-invalid as reported in the PR, and also
fixes an accepts-invalid (see testcase), plus maybe some more,
related due to incomplete checking of symbol attribute conflicts.
The fix does not fully address the general issue, which is
analyzed by Steve: some of the checks do depend on the selected
Fortran standard, and under circumstances such as in the testcase
the checking of other, standard-version-independent conflicts
simply does not occur.
Steve's solution would fix that, but unfortunately leads to issues
with error recovery in notoriously fragile parts of the FE: e.g.
testcase pr87907.f90 needs adjusting, and minor variations
of it will lead to various other horrendous ICEs that remind
of existing PRs where parsing or resolution goes sideways.
I therefore propose a much simpler approach: move - if possible -
selected of the standard-version-dependent checks after the
version-independent ones. I think this could help in getting more
consistent error reporting and recovery. However, I did *not*
move those checks that are critical when processing interfaces.
(-> pr87907.f90 / (sub)modules)
The patch therefore does not require any testsuite update and
should not give any other surprises, so it should be very safe.
The plan is also to leave the PR open for the time being.
Regtesting on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
From c55cb36a6ad00996b5efb33c0c5357fc5fa9919c Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Mon, 6 May 2024 20:57:29 +0200
Subject: [PATCH] Fortran: improve attribute conflict checking [PR93635]
gcc/fortran/ChangeLog:
PR fortran/93635
* symbol.cc (gfc_check_conflict): Move some attribute conflict
checks that depend on the selected version of the Fortran standard
so that error reporting gets more consistent.
gcc/testsuite/ChangeLog:
PR fortran/93635
* gfortran.dg/pr93635.f90: New test.
---
gcc/fortran/symbol.cc | 30 ---
gcc/testsuite/gfortran.dg/pr93635.f90 | 19 +
2 files changed, 32 insertions(+), 17 deletions(-)
create mode 100644 gcc/testsuite/gfortran.dg/pr93635.f90
diff --git a/gcc/fortran/symbol.cc b/gcc/fortran/symbol.cc
index 8f7deac1d1e..ed17291c53e 100644
--- a/gcc/fortran/symbol.cc
+++ b/gcc/fortran/symbol.cc
@@ -459,22 +459,6 @@ gfc_check_conflict (symbol_attribute *attr, const char *name, locus *where)
if (where == NULL)
where = &gfc_current_locus;
- if (attr->pointer && attr->intent != INTENT_UNKNOWN)
-{
- a1 = pointer;
- a2 = intent;
- standard = GFC_STD_F2003;
- goto conflict_std;
-}
-
- if (attr->in_namelist && (attr->allocatable || attr->pointer))
-{
- a1 = in_namelist;
- a2 = attr->allocatable ? allocatable : pointer;
- standard = GFC_STD_F2003;
- goto conflict_std;
-}
-
/* Check for attributes not allowed in a BLOCK DATA. */
if (gfc_current_state () == COMP_BLOCK_DATA)
{
@@ -579,10 +563,12 @@ gfc_check_conflict (symbol_attribute *attr, const char *name, locus *where)
return false;
conf (allocatable, pointer);
+
+ /* Moving these checks past the function/subroutine conflict check may
+ cause trouble with minor variations of testcase pr87907.f90. */
conf_std (allocatable, dummy, GFC_STD_F2003);
conf_std (allocatable, function, GFC_STD_F2003);
conf_std (allocatable, result, GFC_STD_F2003);
- conf_std (elemental, recursive, GFC_STD_F2018);
conf (in_common, dummy);
conf (in_common, allocatable);
@@ -911,6 +897,16 @@ gfc_check_conflict (symbol_attribute *attr, const char *name, locus *where)
break;
}
+ /* Conflict checks depending on the selected version of the Fortran
+ standard are preferably applied after standard-independent ones, so
+ that one gets more consistent error reporting and recovery. */
+ if (attr->pointer && attr->intent != INTENT_UNKNOWN)
+conf_std (pointer, intent, GFC_STD_F2003);
+
+ conf_std (in_namelist, allocatable, GFC_STD_F2003);
+ conf_std (in_namelist, pointer, GFC_STD_F2003);
+ conf_std (elemental, recursive, GFC_STD_F2018);
+
return true;
conflict:
diff --git a/gcc/testsuite/gfortran.dg/pr93635.f90 b/gcc/testsuite/gfortran.dg/pr93635.f90
new file mode 100644
index 000..4ef33fecf2b
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr93635.f90
@@ -0,0 +1,19 @@
+! { dg-do compile }
+! PR fortran/93635
+!
+! Test that some attribute conflicts are properly diagnosed
+
+program p
+ implicit none
+ character(len=:),allocatable :: r,s
+ namelist /args/ r,s
+ equivalence(r,s) ! { dg-error "EQUIVALENCE attribute conflicts with ALLOCATABLE" }
+ allocate(character(len=1024) :: r)
+end
+
+subroutine sub (p, q)
+ implicit none
+ real, pointer, intent(inout) :: p(:), q(:)
+ namelist /nml/ p,q
+ equivalence(p,q) ! { dg-error "EQUIVALENCE attribute conflicts with DUMMY" }
+end
--
2.35.3
Tests of gcc development beyond its testsuite (in this case, for gfortran)
I have now, for some time, ran LAPACK's test programs on my gcc/gfortran builds on both on the x86_64-linux-gnu architecture, as well as the aarch64-linux-gnu one (see, e.g., http://moene.org/~toon/lapack-amd64-gfortran13-O3). The results are rather alarming - this is r15-202 for aarch64 vs r15-204 for x86_64 (compiled with -O3): diff lapack-amd64-gfortran15-O3 lapack-aarch64-gfortran15-O3 3892,3895c3928,3931 < REAL 1327023 0 (0.000%)0 (0.000%) < DOUBLE PRECISION 1300917 6 (0.000%)0 (0.000%) < COMPLEX786775 0 (0.000%)0 (0.000%) < COMPLEX16 787842 0 (0.000%)0 (0.000%) --- > REAL 1317063 71 (0.005%)0 (0.000%) > DOUBLE PRECISION 1318331 54 (0.004%)4 (0.000%) > COMPLEX767023 390 (0.051%)0 (0.000%) > COMPLEX16 772338 305 (0.039%)0 (0.000%) 3897c3933 < --> ALL PRECISIONS 4202557 6 (0.000%)0 (0.000%) --- > --> ALL PRECISIONS 4174755 820 (0.020%)4 (0.000%) Note the excessive exceeding the threshold for errors on the aarch64 side (>). Of course, this is only an excerpt of the full log file - there is more information in it to zoom in on the errors on the aarch64 side (note that the x86_64 side is not faultless). Is there a way to pass this information to our websites, so that we do not "forget" this - or in the alternative, follow the progress in solving this ? Kind regards, -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
Re: Tests of gcc development beyond its testsuite (in this case, for gfortran)
On Mon, May 6, 2024 at 2:27 PM Toon Moene wrote: > > I have now, for some time, ran LAPACK's test programs on my gcc/gfortran > builds on both on the x86_64-linux-gnu architecture, as well as the > aarch64-linux-gnu one (see, e.g., > http://moene.org/~toon/lapack-amd64-gfortran13-O3). > > The results are rather alarming - this is r15-202 for aarch64 vs r15-204 > for x86_64 (compiled with -O3): Did you test x86_64 with -march=native (or with -mfma) or just -O3? The reason why I am asking is aarch64 includes FMA by default while x86_64 does not. Most recent x86_64 includes an FMA instruction but since the base ISA does not include it, it is not enabled by default. I am suspect the aarch64 "excessive exceeding the threshold for errors" are all caused by the more use of FMA rather than anything else. Thanks, Andrew Pinski > > diff lapack-amd64-gfortran15-O3 lapack-aarch64-gfortran15-O3 > > 3892,3895c3928,3931 > < REAL 1327023 0 (0.000%)0 > (0.000%) > < DOUBLE PRECISION 1300917 6 (0.000%)0 > (0.000%) > < COMPLEX 786775 0 (0.000%)0 > (0.000%) > < COMPLEX16 787842 0 (0.000%)0 > (0.000%) > --- > > REAL 1317063 71 (0.005%)0 > (0.000%) > > DOUBLE PRECISION 1318331 54 (0.004%)4 > (0.000%) > > COMPLEX 767023 390 (0.051%)0 > (0.000%) > > COMPLEX16772338 305 (0.039%)0 > (0.000%) > 3897c3933 > < --> ALL PRECISIONS4202557 6 (0.000%)0 > (0.000%) > --- > > --> ALL PRECISIONS 4174755 820 (0.020%)4 > (0.000%) > > Note the excessive exceeding the threshold for errors on the aarch64 > side (>). > > Of course, this is only an excerpt of the full log file - there is more > information in it to zoom in on the errors on the aarch64 side (note > that the x86_64 side is not faultless). > > Is there a way to pass this information to our websites, so that we do > not "forget" this - or in the alternative, follow the progress in > solving this ? > > Kind regards, > > -- > Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 > Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
Re: Tests of gcc development beyond its testsuite (in this case, for gfortran)
On 5/6/24 23:32, Andrew Pinski wrote: Did you test x86_64 with -march=native (or with -mfma) or just -O3? The reason why I am asking is aarch64 includes FMA by default while x86_64 does not. Most recent x86_64 includes an FMA instruction but since the base ISA does not include it, it is not enabled by default. I am suspect the aarch64 "excessive exceeding the threshold for errors" are all caused by the more use of FMA rather than anything else. Aah, I forgot to include that tidbit, because its readily apparent from the full logs - I compiled with *just* -O3. Thanks, -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
Re: Tests of gcc development beyond its testsuite (in this case, for gfortran)
On 5/6/24 23:35, Toon Moene wrote: On 5/6/24 23:32, Andrew Pinski wrote: Did you test x86_64 with -march=native (or with -mfma) or just -O3? The reason why I am asking is aarch64 includes FMA by default while x86_64 does not. Most recent x86_64 includes an FMA instruction but since the base ISA does not include it, it is not enabled by default. I am suspect the aarch64 "excessive exceeding the threshold for errors" are all caused by the more use of FMA rather than anything else. Aah, I forgot to include that tidbit, because its readily apparent from the full logs - I compiled with *just* -O3. Thanks, OK, perhaps on the aarch64 I need the following option to make the comparison fair: ‘rdma’ Enable Round Double Multiply Accumulate instructions. This is on by default for -march=armv8.1-a. I.e., -mno-rdma (I hope that's correct - I'll will try that when the Sun rises again and I have some power to run the AArch64 machine ...). I must say I didn't expected this - the discussion on the "Intel" side was always that the fact that fused multiply-add instruction didn't express the "real computations" expressed by the program meant that they were evil and therefore had to be hidden behind some special compiler option that made it very clear that those instruction were evil. Again, thanks to point me to the difference (in philosophy, if not math) between to the two continents (i.e., the Americas and Europe's - before Brexit - England :-) Kind regards, -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
