Re: libgfortran bootstrap failure
On Tue, Jan 11, 2022 at 10:30:26PM -0500, David Edelsohn wrote:
> The recent patch to support Power IEEE128 causes a bootstrap failure
> on AIX and possibly all non-GLIBC systems.
>
> +#if defined(__powerpc64__) && __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__ \
> +&& defined __GLIBC_PREREQ && __GLIBC_PREREQ (2, 32)
> +#define POWER_IEEE128 1
> +#endif
>
> __GLIBC_PREREQ is tested on all systems.
>
> /nasfarm/edelsohn/src/src/libgfortran/libgfortran.h:107:49: error:
> missing binary operator before token "("
> 107 | && defined __GLIBC_PREREQ && __GLIBC_PREREQ (2, 32)
> | ^
This is what I've committed as obvious:
2022-01-12 Jakub Jelinek
* libgfortran.h (POWER_IEEE128): Use __GLIBC_PREREQ in a separate
#if directive inside of #if ... && defined __GLIBC_PREREQ.
--- libgfortran/libgfortran.h.jj2022-01-11 23:49:51.759830402 +0100
+++ libgfortran/libgfortran.h 2022-01-12 09:41:48.779107854 +0100
@@ -104,9 +104,11 @@ typedef off_t gfc_offset;
#endif
#if defined(__powerpc64__) && __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__ \
-&& defined __GLIBC_PREREQ && __GLIBC_PREREQ (2, 32)
+&& defined __GLIBC_PREREQ
+#if __GLIBC_PREREQ (2, 32)
#define POWER_IEEE128 1
#endif
+#endif
/* These functions from should only be used on values that can be
represented as unsigned char, otherwise the behavior is undefined.
Jakub
Re: [PATCH] Mass rename of C++ .c files to .cc suffix
On 1/11/22 17:16, Jakub Jelinek wrote: On Tue, Jan 11, 2022 at 05:03:34PM +0100, Martin Liška wrote: On 1/11/22 16:56, Jakub Jelinek wrote: While e.g. libcpp or gcc are in C++. Which means I should rename .c files under libcpp, right? Is there any other folder from gcc/ and libcpp/ that would need that as well? From the directories that use .c files for C++, I think that is all. c++tools/, libcody/, libitm/, libsanitizer/, libstdc++-v3/ already use .cc or .cpp. All right, I've included libcpp folder in the renaming effort. Please take a look at V2 of the series here: https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;a=log;h=refs/users/marxin/heads/cc-renaming Now I filled up complete ChangeLog entries and I'm asking for a patchset approval. Cheers, Martin Jakub
Re: GCC GSoC 2022: Call for project ideas and mentors
On Thu, Jan 06 2022, Martin Jambor wrote: > [...] > > I will update you as more details about GSoC 2022 become available. > The official timeline has been published at https://developers.google.com/open-source/gsoc/timeline I do not know how the "standard coding period" and "extended deadlines" will exactly work, I suppose mentors and contributors will together simply pick which one of the two to follow. I intend to file our application around February 8th, so it would be great to have our "selected ideas list" ready with all the details by then. Thanks, Martin
Re: GCC GSoC 2022: Call for project ideas and mentors
On Wed, Jan 12 2022, Martin Jambor wrote: > On Thu, Jan 06 2022, Martin Jambor wrote: >> > [...] >> >> I will update you as more details about GSoC 2022 become available. >> > > The official timeline has been published at > https://developers.google.com/open-source/gsoc/timeline > > I do not know how the "standard coding period" and "extended deadlines" > will exactly work, I suppose mentors and contributors will together > simply pick which one of the two to follow. > > I intend to file our application around February 8th, apparently I have not had enough coffee today yet... I wanted to write February 15 (one week before the deadline). It would be great to finish our ideas list with all the details by February 15. Sorry for the slight confusion, Martin
Re: [PATCH] Fortran: make IEEE_CLASS recognize signaling NaNs
Hi, I can confirm that I don’t see this failure on a Debian bullseye/sid (Linux 5.11.0-46, glibc 2.31-0ubuntu9.2) with a fresh bootstrap of master: $ grep signaling testsuite/gfortran/gfortran.sum PASS: gfortran.dg/ieee/signaling_1.f90 -O0 (test for excess errors) PASS: gfortran.dg/ieee/signaling_1.f90 -O0 execution test PASS: gfortran.dg/ieee/signaling_1.f90 -O1 (test for excess errors) PASS: gfortran.dg/ieee/signaling_1.f90 -O1 execution test PASS: gfortran.dg/ieee/signaling_1.f90 -O2 (test for excess errors) PASS: gfortran.dg/ieee/signaling_1.f90 -O2 execution test PASS: gfortran.dg/ieee/signaling_1.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (test for excess errors) PASS: gfortran.dg/ieee/signaling_1.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test PASS: gfortran.dg/ieee/signaling_1.f90 -O3 -g (test for excess errors) PASS: gfortran.dg/ieee/signaling_1.f90 -O3 -g execution test PASS: gfortran.dg/ieee/signaling_1.f90 -Os (test for excess errors) PASS: gfortran.dg/ieee/signaling_1.f90 -Os execution test It’s showing on some gcc-testresults for x86_64 and aarch64 linux, so I’ll need someone (HJ, Andreas are in CC) to show me what the error is. It may be related to the use of dg-options instead of dg-additional-options in that testcase, so I pushed the attached fix. I’ll check the test results mailing-list to see if it improved things (or confirm when the error message is posted). FX test.patch Description: Binary data
Re: [PATCH] Fortran: make IEEE_CLASS recognize signaling NaNs
On Wed, Jan 12, 2022 at 11:23:43AM +0100, FX via Gcc-patches wrote:
> I can confirm that I don’t see this failure on a Debian bullseye/sid (Linux
> 5.11.0-46, glibc 2.31-0ubuntu9.2) with a fresh bootstrap of master:
>
> $ grep signaling testsuite/gfortran/gfortran.sum
> PASS: gfortran.dg/ieee/signaling_1.f90 -O0 (test for excess errors)
> PASS: gfortran.dg/ieee/signaling_1.f90 -O0 execution test
> PASS: gfortran.dg/ieee/signaling_1.f90 -O1 (test for excess errors)
> PASS: gfortran.dg/ieee/signaling_1.f90 -O1 execution test
> PASS: gfortran.dg/ieee/signaling_1.f90 -O2 (test for excess errors)
> PASS: gfortran.dg/ieee/signaling_1.f90 -O2 execution test
> PASS: gfortran.dg/ieee/signaling_1.f90 -O3 -fomit-frame-pointer
> -funroll-loops -fpeel-loops -ftracer -finline-functions (test for excess
> errors)
> PASS: gfortran.dg/ieee/signaling_1.f90 -O3 -fomit-frame-pointer
> -funroll-loops -fpeel-loops -ftracer -finline-functions execution test
> PASS: gfortran.dg/ieee/signaling_1.f90 -O3 -g (test for excess errors)
> PASS: gfortran.dg/ieee/signaling_1.f90 -O3 -g execution test
> PASS: gfortran.dg/ieee/signaling_1.f90 -Os (test for excess errors)
> PASS: gfortran.dg/ieee/signaling_1.f90 -Os execution test
The error I was getting was:
/home/jakub/src/gcc/obj46/gcc/testsuite/gfortran2/../../gfortran
-B/home/jakub/src/gcc/obj46/gcc/testsuite/gfortran2/../../
-B/home/jakub/src/gcc/obj46/x86_64-pc
-linux-gnu/./libgfortran/
/home/jakub/src/gcc/gcc/testsuite/gfortran.dg/ieee/signaling_1.f90
-fdiagnostics-plain-output -fdiagnostics-plain-output -O1 -fsignaling-nans
/home/jakub/sr
c/gcc/gcc/testsuite/gfortran.dg/ieee/signaling_1_c.c -dumpbase
-B/home/jakub/src/gcc/obj46/x86_64-pc-linux-gnu/./libgfortran/.libs
-L/home/jakub/src/gcc/obj46/x86_64-pc-linux-gnu/./
libgfortran/.libs
-L/home/jakub/src/gcc/obj46/x86_64-pc-linux-gnu/./libgfortran/.libs
-L/home/jakub/src/gcc/obj46/x86_64-pc-linux-gnu/./libatomic/.libs
-B/home/jakub/src/gcc/obj46/x8
6_64-pc-linux-gnu/./libquadmath/.libs
-L/home/jakub/src/gcc/obj46/x86_64-pc-linux-gnu/./libquadmath/.libs
-L/home/jakub/src/gcc/obj46/x86_64-pc-linux-gnu/./libquadmath/.libs -lm -o .
/signaling_1.exe
/home/jakub/src/gcc/gcc/testsuite/gfortran.dg/ieee/signaling_1.f90:8:20: Fatal
Error: Cannot find an intrinsic module named 'ieee_arithmetic' at (1)
compilation terminated.
compiler exited with status 1
FAIL: gfortran.dg/ieee/signaling_1.f90 -O1 (test for excess errors)
Excess errors:
/home/jakub/src/gcc/gcc/testsuite/gfortran.dg/ieee/signaling_1.f90:8:20: Fatal
Error: Cannot find an intrinsic module named 'ieee_arithmetic' at (1)
compilation terminated.
UNRESOLVED: gfortran.dg/ieee/signaling_1.f90 -O1 compilation failed to
produce executable
And
-! { dg-options "-fsignaling-nans" }
+! { dg-additional-options "-fsignaling-nans" }
doesn't fix it, it changes the FAIL into:
cc1: warning: command-line option '-fintrinsic-modules-path
/home/jakub/src/gcc/obj46/x86_64-pc-linux-gnu/./libgfortran/' is valid for
Fortran but not for C
FAIL: gfortran.dg/ieee/signaling_1.f90 -O1 (test for excess errors)
Excess errors:
cc1: warning: command-line option '-fintrinsic-modules-path
/home/jakub/src/gcc/obj46/x86_64-pc-linux-gnu/./libgfortran/' is valid for
Fortran but not for C
We need -fintrinsic-modules-path option for the signalling_1.f90 compilation
but need to make sure it isn't used when the *.c file is compiled, so they
need to be compiled by separate compiler invocations probably.
Jakub
Re: [PATCH] Fortran: make IEEE_CLASS recognize signaling NaNs
Hi Jakub, > We need -fintrinsic-modules-path option for the signalling_1.f90 compilation > but need to make sure it isn't used when the *.c file is compiled, so they > need to be compiled by separate compiler invocations probably. Thanks for posting the errors! So I wasn’t seeing it because I had run “make install” before the testsuite. The patch I pushed at https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=6b14100b9504800768da726dcb81f1857db3b493 should fix the failure, then. FX
Re: [PATCH] Fortran: make IEEE_CLASS recognize signaling NaNs
On Wed, Jan 12, 2022 at 12:03:40PM +0100, FX wrote: > > We need -fintrinsic-modules-path option for the signalling_1.f90 compilation > > but need to make sure it isn't used when the *.c file is compiled, so they > > need to be compiled by separate compiler invocations probably. > > Thanks for posting the errors! So I wasn’t seeing it because I had run > “make install” before the testsuite. The patch I pushed at > https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=6b14100b9504800768da726dcb81f1857db3b493 > should fix the failure, then. Thanks. Just a nit, it is cc1 that reports the warning, not f951. Jakub
Re: [PATCH] Fortran: make IEEE_CLASS recognize signaling NaNs
> Thanks. Just a nit, it is cc1 that reports the warning, not f951. I confirm the patch fixes the testcase failure. And I fixed the comment in a follow-up commit. Thanks! FX
[PATCH] git-backport: support renamed .cc files in commit message.
Hi.
There's a patch that enhances git-backport so that it updates commit
messages for files which name ends now with .cc and is still .c on a branch.
Example usage:
$ git show test
commit 8ed4b2cb9aa158c0ef418fd1ac66271664904604 (test)
Author: Martin Liska
Date: Wed Jan 12 16:08:13 2022 +0100
Fix file.
gcc/ChangeLog:
* ipa-icf.cc: Test me.
gcc/ada/ChangeLog:
* cal.c: aaa.
libcpp/ChangeLog:
* expr.cc: aaa.
$ git gcc-backport test
Auto-merging gcc/ada/cal.c
Auto-merging gcc/ipa-icf.c
Auto-merging libcpp/expr.c
[test2 ee40feb077e] Fix file.
Date: Wed Jan 12 16:08:13 2022 +0100
3 files changed, 3 insertions(+)
Commit message updated: 2 .cc file(s) changed.
$ git show test2
commit f59a1e736c1b68f07d83388a994df8d043e8aa6e (test2)
Author: Martin Liska
Date: Wed Jan 12 16:08:13 2022 +0100
Fix file.
gcc/ChangeLog:
* ipa-icf.c: Test me.
gcc/ada/ChangeLog:
* cal.c: aaa.
libcpp/ChangeLog:
* expr.c: aaa.
(cherry picked from commit 8ed4b2cb9aa158c0ef418fd1ac66271664904604)
MartinFrom 647a6dbaf8cde4ee07b95c4530a03f7774500914 Mon Sep 17 00:00:00 2001
From: Martin Liska
Date: Wed, 12 Jan 2022 16:35:41 +0100
Subject: [PATCH] git-backport: support renamed .cc files in commit message.
The change can automatically update names for *.cc files that
are part of a backport.
contrib/ChangeLog:
* git-backport.py: Support renaming of .cc files.
---
contrib/git-backport.py | 50 +
1 file changed, 50 insertions(+)
diff --git a/contrib/git-backport.py b/contrib/git-backport.py
index 2b8e4686719..627bbd9ee66 100755
--- a/contrib/git-backport.py
+++ b/contrib/git-backport.py
@@ -20,7 +20,32 @@
# Boston, MA 02110-1301, USA.
import argparse
+import os
import subprocess
+import sys
+import tempfile
+
+script_folder = os.path.dirname(os.path.abspath(__file__))
+verify_script = os.path.join(script_folder,
+ 'gcc-changelog/git_check_commit.py')
+
+
+def replace_file_in_changelog(lines, filename):
+if not filename.endswith('.cc'):
+return
+
+# consider all componenets of a path: gcc/ipa-icf.cc
+while filename:
+for i, line in enumerate(lines):
+if filename in line:
+line = line.replace(filename, filename[:-1])
+lines[i] = line
+return
+parts = filename.split('/')
+if len(parts) == 1:
+return
+filename = '/'.join(parts[1:])
+
if __name__ == '__main__':
parser = argparse.ArgumentParser(description='Backport a git revision and '
@@ -63,3 +88,28 @@ if __name__ == '__main__':
subprocess.check_output(cmd, shell=True)
else:
print('Please resolve all remaining file conflicts.')
+sys.exit(1)
+
+# Update commit message if change for a .cc file was taken
+r = subprocess.run(f'{verify_script} HEAD', shell=True, encoding='utf8',
+ stdout=subprocess.PIPE, stderr=subprocess.PIPE)
+if r.returncode != 0:
+lines = r.stdout.splitlines()
+cmd = 'git show -s --format=%B'
+commit_message = subprocess.check_output(cmd, shell=True,
+ encoding='utf8').strip()
+commit_message = commit_message.splitlines()
+
+todo = [line for line in lines if 'unchanged file mentioned' in line]
+for item in todo:
+filename = item.split()[-1].strip('"')
+replace_file_in_changelog(commit_message, filename)
+
+with tempfile.NamedTemporaryFile('w', encoding='utf8',
+ delete=False) as w:
+w.write('\n'.join(commit_message))
+w.close()
+subprocess.check_output(f'git commit --amend -F {w.name}',
+shell=True, encoding='utf8')
+os.unlink(w.name)
+print(f'Commit message updated: {len(todo)} .cc file(s) changed.')
--
2.34.1
[PATCH] PR fortran/67804 - ICE on data initialization of type(character) with wrong data
Dear Fortranners,
the attached patch improves error recovery after an invalid
structure constructor has been detected in a DATA statement.
Testcase by Gerhard.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
This should be a rather safe patch which I would like to
backport to 11-branch after a suitable waiting period.
Thanks,
Harald
From 31436189cb2859040703ec6baff816cd63ef Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Wed, 12 Jan 2022 21:24:49 +0100
Subject: [PATCH] Fortran: fix error recovery on bad structure constructor in
DATA statement
gcc/fortran/ChangeLog:
PR fortran/67804
* primary.c (gfc_match_structure_constructor): Recover from errors
that occurred while checking for a valid structure constructor in
a DATA statement.
gcc/testsuite/ChangeLog:
PR fortran/67804
* gfortran.dg/pr93604.f90: Adjust to changed diagnostics.
* gfortran.dg/pr67804.f90: New test.
---
gcc/fortran/primary.c | 15 ---
gcc/testsuite/gfortran.dg/pr67804.f90 | 25 +
gcc/testsuite/gfortran.dg/pr93604.f90 | 2 +-
3 files changed, 38 insertions(+), 4 deletions(-)
create mode 100644 gcc/testsuite/gfortran.dg/pr67804.f90
diff --git a/gcc/fortran/primary.c b/gcc/fortran/primary.c
index fd4d6af50c0..3f01f67cd49 100644
--- a/gcc/fortran/primary.c
+++ b/gcc/fortran/primary.c
@@ -3364,6 +3364,7 @@ gfc_match_structure_constructor (gfc_symbol *sym, gfc_expr **result)
match m;
gfc_expr *e;
gfc_symtree *symtree;
+ bool t = true;
gfc_get_ha_sym_tree (sym->name, &symtree);
@@ -3394,10 +3395,18 @@ gfc_match_structure_constructor (gfc_symbol *sym, gfc_expr **result)
in the structure constructor must be a constant. Try to reduce the
expression here. */
if (gfc_in_match_data ())
-gfc_reduce_init_expr (e);
+t = gfc_reduce_init_expr (e);
- *result = e;
- return MATCH_YES;
+ if (t)
+{
+ *result = e;
+ return MATCH_YES;
+}
+ else
+{
+ gfc_free_expr (e);
+ return MATCH_ERROR;
+}
}
diff --git a/gcc/testsuite/gfortran.dg/pr67804.f90 b/gcc/testsuite/gfortran.dg/pr67804.f90
new file mode 100644
index 000..e2009a5bfdb
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr67804.f90
@@ -0,0 +1,25 @@
+! { dg-do compile }
+! PR fortran/67804 - ICE on bad type in structure constructor in DATA statement
+! Contributed by G.Steinmetz
+
+program p
+ type t
+ character :: c
+ end type
+ type u
+ character, pointer :: c
+ end type
+ type(t) :: x0, x1, x2, x3, x4, x5, x6, x7, x8, x9
+ type(u) :: y6
+ data x0 /t('a')/ ! OK
+ data x1 /t(1)/ ! { dg-error "Cannot convert" }
+ data x2 /t(1.)/ ! { dg-error "Cannot convert" }
+ data x3 /t(1d1)/ ! { dg-error "Cannot convert" }
+ data x4 /t((0.,1.))/ ! { dg-error "Cannot convert" }
+ data x5 /t(.true.)/ ! { dg-error "Cannot convert" }
+ data x6 /t(null())/ ! { dg-error "neither a POINTER nor ALLOCATABLE" }
+ data x7 /t(['1'])/ ! { dg-error "The rank of the element" }
+ data x8 /t([1])/ ! { dg-error "Cannot convert" }
+ data x9 /t(z'0')/! { dg-error "Cannot convert" }
+ data y6 /u(null())/ ! OK
+end
diff --git a/gcc/testsuite/gfortran.dg/pr93604.f90 b/gcc/testsuite/gfortran.dg/pr93604.f90
index 2c695d37829..4040155120c 100644
--- a/gcc/testsuite/gfortran.dg/pr93604.f90
+++ b/gcc/testsuite/gfortran.dg/pr93604.f90
@@ -5,6 +5,6 @@ program p
integer :: a
end type
type(t) :: x
- data x /t(z'1')/ ! { dg-error "cannot appear in a structure constructor" }
+ data x /t(z'1')/ ! { dg-error "BOZ" }
end
--
2.31.1
