[Bug bootstrap/106172] Multiple ICEs building gcc-13 with gcc-12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172 --- Comment #23 from Chris Clayton --- On 18/07/2022 19:13, aldyh at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172 > > Aldy Hernandez changed: > >What|Removed |Added > > CC||aldyh at gcc dot gnu.org > Status|WAITING |NEW > > --- Comment #21 from Aldy Hernandez --- > Confirmed on x86-64 with: ./configure --enable-languages=c,c++ > --enable-checking=no. > > Interestingly, --enable-checking=release works. > Yes, that build succeeds here too. I've had --disable-checking in the picture for at least 5 years, and it's not been a problem. I've built hundreds of gcc- snapshots using gcc- snapshots in that time. Anyway I can drop the checking option altogether because the documentation states that --enable-checking=release is the default. But I guess there is a problem that needs to be fixed albeit maybe not an urgent one. If anyone wants a fix testing, I'm more than happy to help, so just drop me an email. I'll put a comment in my rpm spec file to remind that I need to add the option back in. Thanks.
[Bug bootstrap/106172] Multiple ICEs building gcc-13 with gcc-12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172 --- Comment #20 from Chris Clayton --- On 08/07/2022 15:02, Chris Clayton wrote: > Hi > > On 04/07/2022 00:12, pinskia at gcc dot gnu.org wrote: >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172 >> >> Andrew Pinski changed: >> >>What|Removed |Added >> >> Status|UNCONFIRMED |WAITING >> Ever confirmed|0 |1 >>Last reconfirmed||2022-07-03 >> > > I some additional diagnostics (the result of a bisect) to the bugzilla report > earlier this week. The first bad commit > was 8c99e307b20. > > I've been busy since but have just checked out the first bad commit's parent > commit (54a5f478487) and built with > gcc-12-20220702. That build completed successfully. As an update, I've just tried to build the gcc-13-20220717 snapshot using a compiler built with gcc-12-20220716 snapshot. The outcome is the same set of ICEs. I've also realised this morning that I forgot to add the author of the first bad coomit from the bisect that I reported the results of. So, al...@redhat.com added as recipient of this email. Aldy - the first bad commit from the bisect was 8c99e307b20c502e55c425897fb3884ba8f05882 (Convert DOM to use Ranger rather than EVRP). It seems to be involved in some way in a batch of ICEs I see when trying to build recent gcc-13 snapshots (20220626 and later) with recent gcc-12 snapshots. I aslo get the ICEs trying to build gcc-13 with a gcc-11 or gcc-10 compiler. The diagnostics I've collected are attached to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172 > >
[Bug bootstrap/106172] Multiple ICEs building gcc-13 with gcc-12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172 --- Comment #19 from Chris Clayton --- Hi On 04/07/2022 00:12, pinskia at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172 > > Andrew Pinski changed: > >What|Removed |Added > > Status|UNCONFIRMED |WAITING > Ever confirmed|0 |1 >Last reconfirmed||2022-07-03 > I some additional diagnostics (the result of a bisect) to the bugzilla report earlier this week. The first bad commit was 8c99e307b20. I've been busy since but have just checked out the first bad commit's parent commit (54a5f478487) and built with gcc-12-20220702. That build completed successfully.
[Bug bootstrap/106172] Multiple ICEs building gcc-13 with gcc-12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172 --- Comment #18 from Chris Clayton --- Created attachment 53256 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53256=edit git bisect log
[Bug bootstrap/106172] Multiple ICEs building gcc-13 with gcc-12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172 --- Comment #17 from Chris Clayton --- I've cloned git://gcc.gnu.org/git/gcc.git and bisected between 13-20220626 (ff35dbc02092fbcd3d814fcd9fe8e871c3f741fd) and 13-20220619 (4390e7bfbc641a52c6192b448768dafdf4565527) as bad and good respectively. The result is: 8c99e307b20c502e55c425897fb3884ba8f05882 is the first bad commit commit 8c99e307b20c502e55c425897fb3884ba8f05882 Author: Aldy Hernandez Date: Sat Jun 25 18:58:02 2022 -0400 Convert DOM to use Ranger rather than EVRP [Jeff, this is the same patch I sent you last week with minor tweaks to the commit message.] [Despite the verbosity of the message, this is actually a pretty straightforward patch. It should've gone in last cycle, but there was a nagging regression I couldn't get to until after stage1 had closed.] There are 3 uses of EVRP in DOM that must be converted. Unfortunately, they need to be converted in one go, so further splitting of this patch would be problematic. There's nothing here earth shattering. It's all pretty obvious in retrospect, but I've added a short description of each use to aid in reviewing: * Convert evrp use in cprop to ranger. This is easy, as cprop in DOM was converted to the ranger API last cycle, so this is just a matter of using a ranger instead of an evrp_range_analyzer. * Convert evrp use in threader to ranger. The idea here is to use the hybrid approach we used for the initial VRP threader conversion last cycle. The DOM threader will continue using the forward threader infrastructure while continuing to query DOM data structures, and only if the conditional does not relsolve, using the ranger. This gives us the best of both worlds, and is a proven approach. Furthermore, as frange and prange come live in the next cycle, we can move away from the forward threader altogether, and just add another backward threader. This will not only remove the last use of the forward threader, but will allow us to remove at least 1 or 2 threader instances. * Convert conditional folding to use the method used by the ranger and evrp. Previously DOM was calling into the guts of simplify_using_ranges::vrp_visit_cond_stmt. The blessed way now is using fold_cond() which rewrites the conditional and edges automatically. When legacy is removed, simplify_using_ranges will be further cleaned up, and there will only be one entry point into simplifying a statement. * DOM was setting global ranges determined from unreachable edges as a side-effect of using the evrp engine. We must handle these cases before nuking evrp, and DOM seems like a good fit. I've just moved the snippet to DOM, but it could live anywhere else we do a DOM walk. For the record, this is the case *vrp handled: : ... if (c_5(D) != 5) goto ; else goto ; : __builtin_unreachable (); : If M dominates all uses of c_5, we can set the global range of c_5 to [5,5]. I have tested on x86-64, pcc64le, and aarch64 Linux. I also ran threading benchmarks as well as performance benchmarks. DOM threads 1.56% more paths which ultimately yields a miniscule total increase of 0.03%. The conversion to ranger brings a 7.87% performance drop in DOM, which is a wash in overall compilation. This is in line with other replacements of legacy evrp with ranger. We handle a lot more cases. It's not free . There is a a regression on Wstringop-overflow-4.C which I'm planning on XFAILing. It's another variant of the usual middle-end false positives: having no ranges produces no warnings, but slightly refined ranges, or worse-- isolating specific problematic cases in the threader causes flare-ups. As an aside, as Richi has suggested, I think we should discuss restricting the threader's ability to thread highly unlikely paths. These cause no end of pain for middle-end warnings. However, I don't know if this would conflict with path isolation for things like null dereferencing. ISTR you were interested in this. BTW, I think the Wstringop-overflow-4.C test is problematic and I've attached my analysis. Basically the regression is caused by a bad interaction with the rounding/alignment that placement new has inlined into the IL. This happens for int16_r[] which the test is testing. Ranger can glean some range info, which causes DOM threading to isolate a path which causes a warning. ... I'll attach the bisect log shortly.
[Bug bootstrap/106172] Multiple ICEs building gcc-13 with gcc-12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172 --- Comment #16 from Chris Clayton --- I've tried two further build of gcc-13 using gcc-12-20220702. The gcc-13-20220703 snapshot fails with the same ICEs but the 20220619 snapshot builds successfully. So we have 13-20220626 and 13-20220703 both fail but 13-20220619 succeeds.
[Bug bootstrap/106172] Multiple ICEs building gcc-13 with gcc-12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172 --- Comment #15 from Chris Clayton --- On 04/07/2022 00:12, pinskia at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172 > > Andrew Pinski changed: > >What|Removed |Added > > Status|UNCONFIRMED |WAITING > Ever confirmed|0 |1 >Last reconfirmed||2022-07-03 > > --- Comment #14 from Andrew Pinski --- >> make[2]: *** [Makefile:20255: all-stage2-target-libgcc] Error 2 >> make[2]: Leaving directory >> '/home/chris/rpm/BUILD/gcc-obj-x86_64-pc-linux-gnu' >> make[1]: *** [Makefile:25739: stage2-bubble] Error 2 >> make[1]: Leaving directory >> '/home/chris/rpm/BUILD/gcc-obj-x86_64-pc-linux-gnu' >> make: *** [Makefile:1072: all] Error 2 > > > Did you set any CFLAGS or STAGE1_CFLAGS (or CXXFLAGS) env? > What the above means is stage1 is being miscompiled. I build and manage packages with rpm. Through rpmbuild the default for CFLAGS is "-O2 -g". To that I add "-mindirect-branch=thunk" to build with retpoline enabled. > I Noticed you used --disable-checking, these days the default for releases is > --enable-checking=release rather than --disable-checking (slightly different > though). Is that likely to be the source of the problem? If not, I'll look into it when this problem is solved. > Another data point - I've just tried to build gcc-13-20220626 with gcc-10.4.0 and get the same batch of ICEs.
[Bug c/106172] Multiple ICEs building gcc-13 with gcc-12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172 --- Comment #12 from Chris Clayton --- I've just run the build again with gcc-11-20220701 and get the same set of ICEs. I've kept the files of diagnostics output by gcc and can provide them id they will be helpful.
[Bug c/106172] Multiple ICEs building gcc-13 with gcc-12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172 --- Comment #11 from Chris Clayton --- On 03/07/2022 12:00, sch...@linux-m68k.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172 > > --- Comment #10 from Andreas Schwab --- > How did you build the bootstrap compiler? > I assume that by bootstrap compiler you mean xgcc/xg++. If not, what is it? In any case, I didn't do anything in particular. As I understand it, the bootstrap compiler is built as an early step of the gcc build system so it will have been built with gcc-12-20220702.
[Bug c/106172] Multiple ICEs building gcc-13 with gcc-12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172 --- Comment #9 from Chris Clayton --- Created attachment 53255 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53255=edit Error messages output to terminal
[Bug c/106172] Multiple ICEs building gcc-13 with gcc-12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172 --- Comment #8 from Chris Clayton --- Created attachment 53254 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53254=edit GCC diagnostics file 9
[Bug c/106172] Multiple ICEs building gcc-13 with gcc-12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172 --- Comment #7 from Chris Clayton --- Created attachment 53253 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53253=edit GCC diagnostics file 8
[Bug c/106172] Multiple ICEs building gcc-13 with gcc-12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172 --- Comment #6 from Chris Clayton --- Created attachment 53252 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53252=edit GCC diagnostics file 7
[Bug c/106172] Multiple ICEs building gcc-13 with gcc-12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172 --- Comment #5 from Chris Clayton --- Created attachment 53251 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53251=edit GCC diagnostics file 6
[Bug c/106172] Multiple ICEs building gcc-13 with gcc-12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172 --- Comment #4 from Chris Clayton --- Created attachment 53250 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53250=edit GCC diagnostics file 5
[Bug c/106172] Multiple ICEs building gcc-13 with gcc-12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172 --- Comment #3 from Chris Clayton --- Created attachment 53249 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53249=edit GCC diagnostics file 4
[Bug c/106172] Multiple ICEs building gcc-13 with gcc-12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172 --- Comment #2 from Chris Clayton --- Created attachment 53248 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53248=edit GCC diagnostics file 3
[Bug c/106172] Multiple ICEs building gcc-13 with gcc-12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172 --- Comment #1 from Chris Clayton --- Created attachment 53247 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53247=edit GCC diagnostics file 2
[Bug c/106172] New: Multiple ICEs building gcc-13 with gcc-12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172 Bug ID: 106172 Summary: Multiple ICEs building gcc-13 with gcc-12 Product: gcc Version: 12.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: chris2553 at googlemail dot com Target Milestone: --- Created attachment 53246 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53246=edit GCC diagnostics file 1 I'm trying to build the gcc-13-20220626 snapshot with the gcc-12-20220702 snapshot but get multiple ICEs. I got the same (or similar) bunch of ICE's last week trying to build gcc-13-20220626 with gcc-12-20220625, but didn't have time to get the diagnostics and report it last week) I've run the build again with the recommended -freport-bug added to CFLAGSand the files saved to /tmp/ are attached as is a file containing the text splat on the console when the ICEs happened.
[Bug c++/105256] [9/10 Regression] ICE compiling firefox-99
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105256 --- Comment #33 from Chris Clayton --- On 20/04/2022 07:46, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105256 > > Jakub Jelinek changed: > >What|Removed |Added > > Summary|[9/10/11 Regression] ICE|[9/10 Regression] ICE >|compiling firefox-99|compiling firefox-99 > Status|NEW |ASSIGNED >Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot > gnu.org > > --- Comment #32 from Jakub Jelinek --- > Fixed for 11.3 as well. and I've successfully built firefox-99.0.1 using 11.3-RC with this patch applied. Thanks Jakub. >
[Bug c++/105256] [9/10/11/12 Regression] ICE compiling firefox-99
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105256 --- Comment #25 from Chris Clayton --- I went ahead and patched gcc-11-0220409 and with the resultant compiler have had two successful builds of firefox-99. I then reverted to the unpatched gcc and a build of firefox-99 failed with the same ICE that I reported in comment 1.
[Bug c++/105256] [9/10/11/12 Regression] ICE compiling firefox-99
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105256 --- Comment #24 from Chris Clayton --- I see the patch is for gcc-12. As I said in comment, I don't get the ICE with the latest gcc-12 snapshot, but is it worth me applying the patch to gcc-11 (with which I do get the ICE) and testing a build with that?
[Bug c++/105256] [9/10/11/12 Regression] ICE compiling firefox-99
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105256 --- Comment #17 from Chris Clayton --- Created attachment 52810 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52810=edit Compiler commands Finally got them by running running "ps ax" in a while true loop, grepping the output for the file name and writing any matches to a file. There must be an easier way!
[Bug c++/105256] ICE compiling firefox-99
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105256 --- Comment #6 from Chris Clayton --- I'm struggling to get the compiler command line. The build system is wrapped in a build tool called mach and I'm darned if I can find an argument that will cause it to report the command it is about to launch. The -verbose argument seems to have very little effect on the messages that are output as does the --log-file argument. Hey ho.
[Bug c++/105256] ICE compiling firefox-99
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105256 --- Comment #5 from Chris Clayton --- The .ii file was huge so I've had to split it and then compress the parts
[Bug c++/105256] ICE compiling firefox-99
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105256 --- Comment #4 from Chris Clayton --- Created attachment 52804 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52804=edit Second Requested file - part2
[Bug c++/105256] ICE compiling firefox-99
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105256 --- Comment #3 from Chris Clayton --- Created attachment 52803 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52803=edit Second requested file - part1
[Bug c++/105256] ICE compiling firefox-99
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105256 --- Comment #2 from Chris Clayton --- Created attachment 52802 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52802=edit First requested file
[Bug c++/105256] New: ICE compiling firefox-99
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105256
Bug ID: 105256
Summary: ICE compiling firefox-99
Product: gcc
Version: 11.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: chris2553 at googlemail dot com
Target Milestone: ---
I get the following ICE bump when compiling firefox-99.0 (and 99.0.1) with a
gcc installation built from the gcc-11-20220409 snapshot. The same ICE occurs
with gcc-11-20220402.
30:42.01 In file included from Unified_cpp_layout_style2.cpp:92:
30:42.01 /home/chris/rpm/BUILD/firefox-99.0.1/layout/style/PreferenceSheet.cpp:
In member function 'void mozilla::PreferenceSheet::Prefs::Load(bool)':
30:42.01
/home/chris/rpm/BUILD/firefox-99.0.1/layout/style/PreferenceSheet.cpp:181:12:
internal compiler error: Segmentation fault
30:42.01 181 | *this = {};
30:42.01 |^
30:42.03 0x16b0e03 diagnostic_impl(rich_location*, diagnostic_metadata const*,
int, char const*, __va_list_tag (*) [1], diagnostic_t)
30:42.03???:0
30:42.03 0x16b1247 internal_error(char const*, ...)
30:42.03???:0
30:42.03 0xc8edbf crash_signal(int)
30:42.03???:0
30:42.03 0x8674f3 ggc_free(void*)
30:42.03???:0
30:42.04 0x62a075 gimplify_asm_expr(tree_node**, gimple**, gimple**) [clone
.isra.0] [clone .cold]
30:42.04???:0
30:42.04 Please submit a full bug report,
30:42.04 with preprocessed source if appropriate.
30:42.04 Please include the complete backtrace with any bug report.
30:42.04 See
[Bug tree-optimization/97953] [8/9/10 Regression] ICE (segfault) during GIMPLE pass: loopdone compiling libgcc/config/libbid/bid128_fma.c:190:1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97953 --- Comment #22 from Chris Clayton --- I've applied Richard's patch to the 20201122 snapshot and can happily report that the build now completes successfully. My thanks to Martin and Richard.
[Bug tree-optimization/97953] ICE (segfault) during GIMPLE pass: loopdone compiling libgcc/config/libbid/bid128_fma.c:190:1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97953 --- Comment #13 from Chris Clayton --- (In reply to Martin Liška from comment #9) > Ok, so the question is: does it reproduce with the current master or now? Short answer: Yes, it does. A build done this morning (after pulling the latest changes into the tree I cloned yesterday) fails with the same ICE error messages.
[Bug tree-optimization/97953] ICE (segfault) during GIMPLE pass: loopdone compiling libgcc/config/libbid/bid128_fma.c:190:1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97953 --- Comment #12 from Chris Clayton --- Created attachment 49622 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49622=edit git bisect log
[Bug tree-optimization/97953] ICE (segfault) during GIMPLE pass: loopdone compiling libgcc/config/libbid/bid128_fma.c:190:1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97953 --- Comment #11 from Chris Clayton --- I've finished the bisect and landed at: [chris:~/scratch/gcc-ICE/gcc]$ git bisect good bd87cc14ebdb6789e067fb1828d5808407c308b3 is the first bad commit commit bd87cc14ebdb6789e067fb1828d5808407c308b3 Author: Richard Biener Date: Wed Nov 11 11:51:59 2020 +0100 tree-optimization/97623 - Avoid PRE hoist insertion iteration The recent previous change in this area limited hoist insertion iteration via a param but the following is IMHO better since we are not really interested in PRE opportunities exposed by hoisting but only the other way around. So this moves hoist insertion after PRE iteration finished and removes hoist insertion iteration alltogether. 2020-11-11 Richard Biener PR tree-optimization/97623 * params.opt (-param=max-pre-hoist-insert-iterations): Remove again. * doc/invoke.texi (max-pre-hoist-insert-iterations): Likewise. * tree-ssa-pre.c (insert): Move hoist insertion after PRE insertion iteration and do not iterate it. * gcc.dg/tree-ssa/ssa-hoist-3.c: Adjust. * gcc.dg/tree-ssa/ssa-hoist-7.c: Likewise. * gcc.dg/tree-ssa/ssa-pre-30.c: Likewise. gcc/doc/invoke.texi | 5 - gcc/params.opt | 4 gcc/testsuite/gcc.dg/tree-ssa/ssa-hoist-3.c | 2 +- gcc/testsuite/gcc.dg/tree-ssa/ssa-hoist-7.c | 4 ++-- gcc/testsuite/gcc.dg/tree-ssa/ssa-pre-30.c | 2 +- gcc/tree-ssa-pre.c | 34 +++-- 6 files changed, 26 insertions(+), 25 deletions(-) I've also confirmed the outcome. A build with this commit at HEAD fails with the ICE. A build with the commits parent at HEAD succeeds. I'll attach the bisect log in a few minutes.
[Bug tree-optimization/97953] ICE (segfault) during GIMPLE pass: loopdone compiling libgcc/config/libbid/bid128_fma.c:190:1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97953 --- Comment #8 from Chris Clayton --- Sorry, my last comment contains an error. git bisect start... reported 7 bisections would be needed not that there were only 7 commits.
[Bug tree-optimization/97953] ICE (segfault) during GIMPLE pass: loopdone compiling libgcc/config/libbid/bid128_fma.c:190:1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97953 --- Comment #7 from Chris Clayton --- Yes, Richard's correct. I'm building from snapshot releases. That's why I used the term "snapshot releases" in comment 4. I've cloned git://gcc.gnu.org/git/gcc.git and am bisecting between b642fca1c31b2e2175e0860daf32b4ee0d918085 (11-20201108) and c746fc40f4ec8cfc1092efd49d567751858d2099 (11-20201115). I'm not 100% sure this is correct because I'm anything but a git expert and I've never come across a tree that didn't have branches for different strands of development (e.g gcc-10 gcc-11). git bisect start... reported that there were only 7 commits and that feels right, so I'll blunder on until someone tells me I'm doing this wrong (an, hopefully, how I should be doing it)
[Bug c/97953] ICE (segfault) during GIMPLE pass: loopdone compiling libgcc/config/libbid/bid128_fma.c:190:1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97953 --- Comment #4 from Chris Clayton --- I've done a few more builds of snapshot releases of gcc-11. Using with gcc-10-20201122, I get the ICE building 11-2020115, but 11-20201108 and 20201101 both build successfully.
[Bug c/97953] ICE (segfault) during GIMPLE pass: loopdone compiling libgcc/config/libbid/bid128_fma.c:190:1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97953 --- Comment #2 from Chris Clayton --- Created attachment 49612 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49612=edit Full build log
[Bug c/97953] ICE (segfault) during GIMPLE pass: loopdone compiling libgcc/config/libbid/bid128_fma.c:190:1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97953 --- Comment #1 from Chris Clayton --- Created attachment 49611 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49611=edit Preprocessed source
[Bug c/97953] New: ICE (segfault) during GIMPLE pass: loopdone compiling libgcc/config/libbid/bid128_fma.c:190:1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97953
Bug ID: 97953
Summary: ICE (segfault) during GIMPLE pass: loopdone compiling
libgcc/config/libbid/bid128_fma.c:190:1
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: chris2553 at googlemail dot com
Target Milestone: ---
Building 11-20201122 (with gcc-10-20201121 or gcc-10-20201114) results in an
ICE as follows:
/home/chris/rpm/BUILD/gcc-obj-x86_64-pc-linux-gnu/./gcc/xgcc
-B/home/chris/rpm/BUILD/gcc-obj-x86_64-pc-linux-gnu/./gcc/
-B/usr/x86_64-pc-linux-gnu/bin/ -B/usr/x86_64-pc-linux-gnu/lib/ -isystem
/usr/x86_64-pc-linux-gnu/include -isystem /usr/x86_64-pc-linux-gnu/sys-include
-fno-checking -g -O2 -O2 -g -O2 -DIN_GCC-W -Wall -Wno-narrowing
-Wwrite-strings -Wcast-qual -Wno-error=format-diag -Wstrict-prototypes
-Wmissing-prototypes -Wno-error=format-diag -Wold-style-definition -isystem
./include -fpic -mlong-double-80 -DUSE_ELF_SYMVER -fcf-protection -mshstk -g
-DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -fpic -mlong-double-80
-DUSE_ELF_SYMVER -fcf-protection -mshstk -I. -I. -I../.././gcc
-I../../../gcc-11-20201122/libgcc -I../../../gcc-11-20201122/libgcc/.
-I../../../gcc-11-20201122/libgcc/../gcc
-I../../../gcc-11-20201122/libgcc/../include
-I../../../gcc-11-20201122/libgcc/config/libbid -DENABLE_DECIMAL_BID_FORMAT
-DHAVE_CC_TLS -DUSE_TLS -o bid128_fma.o -MT bid128_fma.o -MD -MP -MF
bid128_fma.dep -c ../../../gcc-11-20201122/libgcc/config/libbid/bid128_fma.c
during GIMPLE pass: loopdone
../../../gcc-11-20201122/libgcc/config/libbid/bid128_fma.c: In function
'nr_digits256':
../../../gcc-11-20201122/libgcc/config/libbid/bid128_fma.c:190:1: internal
compiler error: Segmentation fault
190 | nr_digits256 (UINT256 R256) {
| ^~~~
A log of the full build (using rpmbuild) and the preprocessed source are
attached.
