From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 36FB83858C55; Tue, 2 Apr 2024 14:40:18 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 36FB83858C55 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1712068818; bh=yATt+Gvf7CCof9UzSmb/69pOYMwZ7u//rAZoJczIky4=; h=From:To:Subject:Date:In-Reply-To:References:From; b=flE8m/D2IYwvQRDkIsN6TqQSRs3Q3raeaz8QY4wXyQOWCHmZ20U6Yfn8LRzLizbW1 sl1bt3znHw7HYlVGGpqBLWVX7v+zC2IvGFDgvkfHewNGB8p3reRWsDP64x3RyGDmT0 8Eu1UlUAxPiBrktXoumTS9VvmXJWTd9kVj63UHj4= From: "paul.richard.thomas at gmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/106987] [11/12/13/14 Regression] ICE in simplify_intrinsic_op, at fortran/expr.cc:1305 Date: Tue, 02 Apr 2024 14:40:17 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: fortran X-Bugzilla-Version: 13.0 X-Bugzilla-Keywords: ice-on-invalid-code X-Bugzilla-Severity: normal X-Bugzilla-Who: paul.richard.thomas at gmail dot com X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P4 X-Bugzilla-Assigned-To: anlauf at gcc dot gnu.org X-Bugzilla-Target-Milestone: 11.5 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D106987 --- Comment #8 from paul.richard.thomas at gmail dot com --- Hi Harald, After a lot of messing around, I managed to backport the patch; essentially by hand. However, two of the testcases ICEd in trans-array.cc and so there were obviously dependences that I had missed. I will not be backporting r14-1629, if for no other reason than it is not a regression but also because the amount of work that would be involved doesn't warrant it. It's a pity that I didn't keep 13-branch up to speed with mainline on the associate fixes but we will just have to live with it now. Regards Paul On Tue, 2 Apr 2024 at 14:32, Paul Richard Thomas < paul.richard.thomas@gmail.com> wrote: > Hi Harald, > > I will have a stab at backporting r14-1629 later this afternoon and will > let you know what happens. I am just rebuilding after applying the fix for > pr112407 (yes, I did add -std=3Df2008 :-) ). > > I don't think that there is any point in going back to 12-branch at this > point in the release cycle. > > Cheers > > Paul > > > > > On Mon, 1 Apr 2024 at 21:42, anlauf at gcc dot gnu.org < > gcc-bugzilla@gcc.gnu.org> wrote: > >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D106987 >> >> anlauf at gcc dot gnu.org changed: >> >> What |Removed |Added >> >> ------------------------------------------------------------------------= ---- >> Status|NEW |ASSIGNED >> >> --- Comment #6 from anlauf at gcc dot gnu.org --- >> (In reply to Paul Thomas from comment #5) >> > Hi Harald, >> > >> > I am pinning this one on you since it needs backporting to 13-branch, = at >> > least. It also keeps the audit trail clean. >> >> Hi Paul, >> >> this one is at the top of my backport list. >> >> It depends on backporting r14-8902 (mine), and has weak conflict if >> r14-1629 (yours) is not backported, as testcase gfortran.dg/pr99350.f90 >> was introduced in that commit. >> >> I could amend backporting the fix for the current PR as well as r14-8902 >> to 13-branch by removing the changes to pr99350.f90 from the backport. >> That is likely the most simple solution, as backporting r14-1629 might >> introduce regressions. >> >> Nevertheless, the current fixes can only be backported to 13-branch, >> as some of the infrastructure changes for better error recovery after >> arithmetic errors and when array ctors are involved are to risky to >> backport to 12-branch. >> >> What do you think? >> >> -- >> You are receiving this mail because: >> You are on the CC list for the bug. > >=