Re: ☠ Buildbot (Sourceware): gcc - failed configure (failure) (master)
On Sun, Jan 29, 2023 at 07:49:35PM +, Sam James via Fortran wrote: > > > > On 29 Jan 2023, at 19:36, Jerry D via Gcc wrote: > > > > I had this show up today. I have no idea what this is about. > > > > Please advise. > > > > Sorry Jerry, false positive -- something went wrong with > the builder. Disregard. > > We're still setting things up there. > Please remove the skull and cross bones in the subject line. -- Steve
Re: ☠ Buildbot (Sourceware): gcc - failed configure (failure) (master)
> On 29 Jan 2023, at 19:36, Jerry D via Gcc wrote: > > I had this show up today. I have no idea what this is about. > > Please advise. > Sorry Jerry, false positive -- something went wrong with the builder. Disregard. We're still setting things up there. > Jerry Best, sam signature.asc Description: Message signed with OpenPGP
Re: ☠ Buildbot (Sourceware): gcc - failed configure (failure) (master)
On Sun, Jan 29, 2023 at 2:37 PM Jerry D via Fortran wrote: > > I had this show up today. I have no idea what this is about. > > Please advise. I assume the buildbot thinks that https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=8011fbba7baa46947341ca8069b5a327163a68d5 broke the build, but I fail to see how that commit results in the error reported in the log.
Fwd: ☠ Buildbot (Sourceware): gcc - failed configure (failure) (master)
I had this show up today. I have no idea what this is about. Please advise. Jerry Forwarded Message Subject: ☠ Buildbot (Sourceware): gcc - failed configure (failure) (master) Date: Sun, 29 Jan 2023 19:31:23 + From: buil...@sourceware.org To: Jerry DeLisle A new failure has been detected on builder gcc-gentoo-sparc while building gcc. Full details are available at: https://builder.sourceware.org/buildbot/#builders/231/builds/210 Build state: failed configure (failure) Revision: 8011fbba7baa46947341ca8069b5a327163a68d5 Worker: gentoo-sparc-big Build Reason: (unknown) Blamelist: Jerry DeLisle Steps: - 0: worker_preparation ( success ) - 1: git checkout ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/231/builds/210/steps/1/logs/stdio - 2: rm -rf gcc-build ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/231/builds/210/steps/2/logs/stdio - 3: configure ( failure ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/231/builds/210/steps/3/logs/stdio
Re: [PATCH] fortran: Explicitly set name for *LOC default BACK argument [PR108450]
Hi Mikael, Am 29.01.23 um 17:21 schrieb Mikael Morin: Hello, this is a fix for a gcc-12 ICE regression. This ICE rings a bell to me, and I think the change by Tobias which triggers it only uncovers a bug that can also happen independently in other cases. The problem is resolution of maxloc expressions is not idempotent, that is resolution changes the expression in such a way that it can't be successfully resolved again. I have not tried to prevent multiple resolutions, and fixed instead the way the expression is changed. The patch explains the details. No regression on x86_64-pc-linux-gnu. OK for master and 12? yes, ok for both. Thanks for the patch! Harald
Re: [patch, fortran] PR103506 [10/11/12/13 Regression] ICE in gfc_free_namespace, at fortran/symbol.c
Le 29/01/2023 à 05:17, Jerry DeLisle via Fortran a écrit : Attached patch fixes this problem by allowing the namespace pointer to be set correctly regardless of error condition. Regression tested on x86_64_linux_gnu. OK for trunk and backports? Yes, thanks.
[PATCH] fortran: Explicitly set name for *LOC default BACK argument [PR108450]
Hello,
this is a fix for a gcc-12 ICE regression.
This ICE rings a bell to me, and I think the change by Tobias which
triggers it only uncovers a bug that can also happen independently in
other cases.
The problem is resolution of maxloc expressions is not idempotent, that
is resolution changes the expression in such a way that it can't be
successfully resolved again.
I have not tried to prevent multiple resolutions, and fixed instead the
way the expression is changed. The patch explains the details.
No regression on x86_64-pc-linux-gnu.
OK for master and 12?From e61e2a51e1859f884125670010337f34265997b8 Mon Sep 17 00:00:00 2001
From: Mikael Morin
Date: Sun, 29 Jan 2023 14:38:08 +0100
Subject: [PATCH] fortran: Set name for *LOC default BACK argument [PR108450]
This change fixes an ICE caused by the double resolution of MINLOC,
MAXLOC and FINDLOC expressions which get a default value for the BACK
argument at resolution time. That argument is added without name,
and argument reordering code is not prepared to handle unnamed arguments
coming after named ones, so the second resolution causes a NULL pointer
dereference.
The problem is fixed by explicitly setting the argument name.
PR fortran/108450
gcc/fortran/ChangeLog:
* check.cc (gfc_check_minloc_maxloc): Explicitly set argument name.
(gfc_check_findloc): Ditto.
gcc/testsuite/ChangeLog:
* gfortran.dg/gomp/minmaxloc_1.f90: New test.
---
gcc/fortran/check.cc | 2 ++
.../gfortran.dg/gomp/minmaxloc_1.f90 | 32 +++
2 files changed, 34 insertions(+)
create mode 100644 gcc/testsuite/gfortran.dg/gomp/minmaxloc_1.f90
diff --git a/gcc/fortran/check.cc b/gcc/fortran/check.cc
index ebcb8f39852..8c1ae8c2f00 100644
--- a/gcc/fortran/check.cc
+++ b/gcc/fortran/check.cc
@@ -3888,6 +3888,7 @@ gfc_check_minloc_maxloc (gfc_actual_arglist *ap)
{
b = gfc_get_logical_expr (gfc_logical_4_kind, NULL, 0);
ap->next->next->next->next->expr = b;
+ ap->next->next->next->next->name = gfc_get_string ("back");
}
if (m == NULL && d != NULL && d->ts.type == BT_LOGICAL
@@ -3969,6 +3970,7 @@ gfc_check_findloc (gfc_actual_arglist *ap)
{
b = gfc_get_logical_expr (gfc_logical_4_kind, NULL, 0);
ap->next->next->next->next->next->expr = b;
+ ap->next->next->next->next->next->name = gfc_get_string ("back");
}
if (m == NULL && d != NULL && d->ts.type == BT_LOGICAL
diff --git a/gcc/testsuite/gfortran.dg/gomp/minmaxloc_1.f90 b/gcc/testsuite/gfortran.dg/gomp/minmaxloc_1.f90
new file mode 100644
index 000..b3691f774de
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/gomp/minmaxloc_1.f90
@@ -0,0 +1,32 @@
+! { dg-do compile }
+!
+! PR fortran/108450
+! This program used to cause an ICE because of the double resolution
+! of the maxloc expression and the addition of a hidden unnamed argument
+! during the first resolution.
+!
+! Original testcase from G. Steinmetz
+
+subroutine s1
+ integer :: a(8) = 0
+ integer :: l
+ integer :: n
+ !$omp atomic
+ n = maxloc(a, mask=l) ! { dg-error ".mask. argument of .maxloc. intrinsic at .1. must be LOGICAL" }
+end
+
+subroutine s2
+ integer :: a(8) = 0
+ integer :: l
+ integer :: n
+ !$omp atomic
+ n = minloc(a, mask=l) ! { dg-error ".mask. argument of .minloc. intrinsic at .1. must be LOGICAL" }
+end
+
+subroutine s3
+ integer :: a(8) = 0
+ integer :: l
+ integer :: n
+ !$omp atomic
+ n = findloc(a, 3, mask=l) ! { dg-error ".mask. argument of .findloc. intrinsic at .1. must be LOGICAL" }
+end
--
2.39.0
