Compiling the Wine Gecko project on Fedora for a Windows target produces an internal compiler error. GCC 10.1 and 10.2 are affected. Last known working with GCC 9.2.1. When I compile it with the default arguments I get the error. When I compile it with '-save-temps' to get the preprocessed file no error occurs. No error occurs if I compile the preprocessed file either. I'm not sure what to provide to reproduce this besides the SRPM file to compile it. https://kojipkgs.fedoraproject.org//packages/mingw-wine-gecko/2.47.1/2.fc32/src/mingw-wine-gecko-2.47.1-2.fc32.src.rpm
Created attachment 48963 [details] g++ command and output of error
A backtrace would be helpful, I suspect a stale location somewhere.
All right, so please provide pre-processed source file (-E option). I can then try to reproduce it..
The preprocessed file, even XZ compressed, is too large for attaching here. https://github.com/mooninite/gcc-bug/blob/master/Unified_cpp_widget_windows0.ii.xz
Similar issue @ https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96935 (with bisect to the 'last known good' version)
when using gcc10.2 to compile our application, we have the same compilation error.
as we noticed, when using gcc10.2.1 compile our application, 528 C++ modules failed with this bug. looks like a high priority bug to me.
(In reply to Jan Smets from comment #5) > Similar issue @ https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96935 I applied the patch from that bug but it did not fix this issue. Anything I can do to help push this bug along?
I tried reproducing this using the .ii file (albeit with trunk), but it's not triggering for me. (In reply to Michael Cronenworth from comment #0) [...] > When I compile it with '-save-temps' to get the preprocessed file no error > occurs. No error occurs if I compile the preprocessed file either. ...which suggests to me that maybe this is in a diagnostic that relies on re-reading the sources, such as -Wmisleading-indentation. Alternatively, the crash is in linemap_compare_locations. This is used by linemap_location_before_p, which is used by -Wuninitialized and -Wmaybe-uninitialized. So those could be a few warnings to try disabling to see if we can narrow this down; try adding: -Wno-misleading-indentation -Wno-uninitialized -Wno-maybe-uninitialized and see if one of those fixes it. Michael: are you able to invoke the crashing command under gdb? Adding -wrapper gdb,--args to the g++ invocation will make it invoke cc1plus under the debugger, from which you can get a backtrace. (gdb) run [...hopefully the process crashes...] (gdb) bt and hopefully will shed light on where it's crashing. Hope this is helpful
I have a couple of changes in my own tree. I had a couple of different issues and I don't recall exactly what change was for what specifically. I locally have a revert of 0d48e8779c6a9ac88f5efd1b4a2d40f43ef75faf "Support string locations for C++ in -Wformat (PR c++/56856)" , plus the ugly hack patch from https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96940
FWIW I had another go at reproduing this, but after various failures due to running out of disk space, I was able to rebuild the SRPM from comment #0 without seeing the crash, via: mock --rebuild mingw-wine-gecko-2.47.1-2.fc32.src.rpm -N -r fedora-32-i386 (which the root.log tells me used gcc-c++-10.2.1-9.fc32.i686.rpm). Michael: is that the mock configuration that's failing for you, or are you using a different one?
(In reply to David Malcolm from comment #11) > FWIW I had another go at reproduing this, but after various failures due to > running out of disk space, I was able to rebuild the SRPM from comment #0 > without seeing the crash, via: Yes, and with -save-temps you double the disk space required. :( > mock --rebuild mingw-wine-gecko-2.47.1-2.fc32.src.rpm -N -r fedora-32-i386 That's a reasonable mock command for a Fedora 32 build. > (which the root.log tells me used gcc-c++-10.2.1-9.fc32.i686.rpm). That's the Linux GCC. You will want to see the version for MinGW: mingw-gcc-9.2.1-6.fc32 - which does not crash so I'm not surprised you didn't crash. > Michael: is that the mock configuration that's failing for you, or are you > using a different one? Try: mock --rebuild mingw-wine-gecko-2.47.1-2.fc32.src.rpm -N -r fedora-33-i386 It's still failing for me today. I'm working around it by passing -save-temps to CFLAGS as packages that fail to compile in Fedora for too long are dropped from the distribution.
(In reply to Michael Cronenworth from comment #12) > That's the Linux GCC. You will want to see the version for MinGW: > mingw-gcc-9.2.1-6.fc32 - which does not crash so I'm not surprised you > didn't crash. Thanks. > > Michael: is that the mock configuration that's failing for you, or are you > > using a different one? > > Try: mock --rebuild mingw-wine-gecko-2.47.1-2.fc32.src.rpm -N -r > fedora-33-i386 Thanks; however with that command line it fails for me very early in the build with: 0:03.33 Generating /builddir/build/BUILD/wine-gecko-2.47.1/wine-gecko-2.47.1/configure using autoconf 0:03.34 autoconf: configure.in: No such file or directory 0:03.34 gmake: *** [client.mk:323: /builddir/build/BUILD/wine-gecko-2.47.1/wine-gecko-2.47.1/configure] Error 1 Am I doing something wrong, or does that src.rpm need reworking? (sorry, my packaging skills are rather rusty) This is with the src.rpm downloaded from the link in comment #0: $ md5sum mingw-wine-gecko-2.47.1-2.fc32.src.rpm 82684032aabc8bd3b19923aa9452eb5e mingw-wine-gecko-2.47.1-2.fc32.src.rpm $ rpm -q mock mock-2.3-1.fc32.noarch If you supply me with a .src.rpm that manifests the compiler crash, I can try to debug it and find a simpler reproducer.
(In reply to David Malcolm from comment #13) > $ rpm -q mock > mock-2.3-1.fc32.noarch Sorry, my bad; I had quite an old mock. I've upgraded, and the build is now progressing beyond that point.
#0 fancy_abort (file=0x95b0ab6 "../../libcpp/line-map.c", line=1359, function=0x95b0ace "linemap_compare_locations") at ../../gcc/diagnostic.c:1778 #1 0x08fcbecf in linemap_compare_locations (set=0xf7ffb000, pre=2146782942, post=<optimized out>) at ../../libcpp/line-map.c:1359 #2 0x080f4378 in linemap_location_before_p (loc_b=2146782943, loc_a=2146782942, set=<optimized out>) at ../../gcc/../libcpp/include/line-map.h:1247 #3 min_location (locb=2146782942, loca=2146782943) at ../../gcc/cp/decl.c:10641 #4 smallest_type_location (type_quals=type_quals@entry=1, locations=locations@entry=0xffffc778) at ../../gcc/cp/decl.c:10673 #5 0x081024bb in grokdeclarator (declarator=0xa03c950, declspecs=0xffffc778, decl_context=NORMAL, initialized=0, attrlist=0xffffc62c) at ../../gcc/cp/decl.c:11008 #6 0x0810a109 in start_decl (declarator=0xa03c950, declspecs=0xffffc778, initialized=0, attributes=<optimized out>, prefix_attributes=0x0, pushed_scope_p=0xffffc68c) at ../../gcc/cp/decl.c:5226 #7 0x0818face in cp_parser_init_declarator (parser=0xec83dae0, flags=<optimized out>, decl_specifiers=0xffffc778, checks=0x0, function_definition_allowed_p=true, member_p=false, declares_class_or_enum=0, function_definition_p=0xffffc71c, maybe_range_for_decl=0x0, init_loc=0xffffc710, auto_result=0xffffc7fc) at ../../gcc/cp/parser.c:20776 #8 0x08172e04 in cp_parser_simple_declaration (parser=0xec83dae0, function_definition_allowed_p=<optimized out>, maybe_range_for_decl=0x0) at ../../gcc/cp/parser.c:13739 #9 0x08198e6a in cp_parser_declaration (parser=0xec83dae0) at ../../gcc/cp/parser.c:13438 #10 0x081998cb in cp_parser_declaration_seq_opt (parser=<optimized out>) at ../../gcc/cp/parser.c:13314 #11 cp_parser_linkage_specification (parser=0xec83dae0) at ../../gcc/cp/parser.c:14632 #12 0x08198ed2 in cp_parser_declaration (parser=0xec83dae0) at ../../gcc/cp/parser.c:13375 #13 0x081995b6 in cp_parser_translation_unit (parser=0xec83dae0) at ../../gcc/cp/parser.c:4734 #14 c_parse_file () at ../../gcc/cp/parser.c:44001 #15 0x0825a13c in c_common_parse_file () at ../../gcc/c-family/c-opts.c:1190 #16 0x086be8ce in compile_file () at ../../gcc/toplev.c:458 #17 0x0809227d in do_compile () at ../../gcc/toplev.c:2298 #18 toplev::main (this=0xffffca4e, argc=120, argv=0xffffcb24) at ../../gcc/toplev.c:2437 #19 0x08096231 in main (argc=120, argv=0xffffcb24) at ../../gcc/main.c:39 It's hitting the abort at line 1359 within linemap_compare_locations: 1350 /* So pre and post represent two tokens that are present in a 1351 same macro expansion. Let's see if the token for pre was 1352 before the token for post in that expansion. */ 1353 unsigned i0, i1; 1354 const struct line_map *map = 1355 first_map_in_common (set, pre, post, &l0, &l1); 1356 1357 if (map == NULL) 1358 /* This should not be possible. */ 1359 abort (); where: (gdb) p /x loc_a $1 = 0x7ff54ede (gdb) p /x loc_b $2 = 0x7ff54edf (gdb) call inform (loc_a, "loc_a") In file included from /usr/i686-w64-mingw32/sys-root/mingw/include/minwindef.h:163, from /usr/i686-w64-mingw32/sys-root/mingw/include/windef.h:8, from /usr/i686-w64-mingw32/sys-root/mingw/include/windows.h:69, from /builddir/build/BUILD/wine-gecko-2.47.1/wine-gecko-2.47.1/widget/windows/AudioSession.cpp:7, from /builddir/build/BUILD/wine-gecko-2.47.1/wine-gecko-2.47.1-x86/widget/windows/Unified_cpp_widget_windows0.cpp:2: /usr/i686-w64-mingw32/sys-root/mingw/include/cfgmgr32.h: At global scope: /usr/i686-w64-mingw32/sys-root/mingw/include/cfgmgr32.h:19: note: loc_a 19 | typedef CONST VOID *PCVOID; | (gdb) call inform (loc_b, "loc_b") In file included from /usr/i686-w64-mingw32/sys-root/mingw/include/windef.h:8, from /usr/i686-w64-mingw32/sys-root/mingw/include/windows.h:69, from /builddir/build/BUILD/wine-gecko-2.47.1/wine-gecko-2.47.1/widget/windows/AudioSession.cpp:7, from /builddir/build/BUILD/wine-gecko-2.47.1/wine-gecko-2.47.1-x86/widget/windows/Unified_cpp_widget_windows0.cpp:2: /usr/i686-w64-mingw32/sys-root/mingw/include/cfgmgr32.h:19: note: loc_b 19 | typedef CONST VOID *PCVOID; |
On Wed, 10 Feb 2021, dmalcolm at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96391 > > --- Comment #15 from David Malcolm <dmalcolm at gcc dot gnu.org> --- > #0 fancy_abort (file=0x95b0ab6 "../../libcpp/line-map.c", line=1359, > function=0x95b0ace "linemap_compare_locations") > at ../../gcc/diagnostic.c:1778 > #1 0x08fcbecf in linemap_compare_locations (set=0xf7ffb000, pre=2146782942, > post=<optimized out>) at ../../libcpp/line-map.c:1359 > #2 0x080f4378 in linemap_location_before_p (loc_b=2146782943, > loc_a=2146782942, set=<optimized out>) > at ../../gcc/../libcpp/include/line-map.h:1247 > #3 min_location (locb=2146782942, loca=2146782943) at > ../../gcc/cp/decl.c:10641 > #4 smallest_type_location (type_quals=type_quals@entry=1, > locations=locations@entry=0xffffc778) at ../../gcc/cp/decl.c:10673 > #5 0x081024bb in grokdeclarator (declarator=0xa03c950, declspecs=0xffffc778, > decl_context=NORMAL, initialized=0, attrlist=0xffffc62c) > at ../../gcc/cp/decl.c:11008 > #6 0x0810a109 in start_decl (declarator=0xa03c950, declspecs=0xffffc778, > initialized=0, attributes=<optimized out>, prefix_attributes=0x0, > pushed_scope_p=0xffffc68c) at ../../gcc/cp/decl.c:5226 > #7 0x0818face in cp_parser_init_declarator (parser=0xec83dae0, > flags=<optimized out>, decl_specifiers=0xffffc778, checks=0x0, > function_definition_allowed_p=true, member_p=false, > declares_class_or_enum=0, function_definition_p=0xffffc71c, > maybe_range_for_decl=0x0, > init_loc=0xffffc710, auto_result=0xffffc7fc) at ../../gcc/cp/parser.c:20776 > #8 0x08172e04 in cp_parser_simple_declaration (parser=0xec83dae0, > function_definition_allowed_p=<optimized out>, maybe_range_for_decl=0x0) > at ../../gcc/cp/parser.c:13739 > #9 0x08198e6a in cp_parser_declaration (parser=0xec83dae0) at > ../../gcc/cp/parser.c:13438 > #10 0x081998cb in cp_parser_declaration_seq_opt (parser=<optimized out>) at > ../../gcc/cp/parser.c:13314 > #11 cp_parser_linkage_specification (parser=0xec83dae0) at > ../../gcc/cp/parser.c:14632 > #12 0x08198ed2 in cp_parser_declaration (parser=0xec83dae0) at > ../../gcc/cp/parser.c:13375 > #13 0x081995b6 in cp_parser_translation_unit (parser=0xec83dae0) at > ../../gcc/cp/parser.c:4734 > #14 c_parse_file () at ../../gcc/cp/parser.c:44001 > #15 0x0825a13c in c_common_parse_file () at ../../gcc/c-family/c-opts.c:1190 > #16 0x086be8ce in compile_file () at ../../gcc/toplev.c:458 > #17 0x0809227d in do_compile () at ../../gcc/toplev.c:2298 > #18 toplev::main (this=0xffffca4e, argc=120, argv=0xffffcb24) at > ../../gcc/toplev.c:2437 > #19 0x08096231 in main (argc=120, argv=0xffffcb24) at ../../gcc/main.c:39 > > > It's hitting the abort at line 1359 within linemap_compare_locations: > > 1350 /* So pre and post represent two tokens that are present in a > 1351 same macro expansion. Let's see if the token for pre was > 1352 before the token for post in that expansion. */ > 1353 unsigned i0, i1; > 1354 const struct line_map *map = > 1355 first_map_in_common (set, pre, post, &l0, &l1); > 1356 > 1357 if (map == NULL) > 1358 /* This should not be possible. */ > 1359 abort (); > > where: > > (gdb) p /x loc_a > $1 = 0x7ff54ede > (gdb) p /x loc_b > $2 = 0x7ff54edf > (gdb) call inform (loc_a, "loc_a") > In file included from > /usr/i686-w64-mingw32/sys-root/mingw/include/minwindef.h:163, > from /usr/i686-w64-mingw32/sys-root/mingw/include/windef.h:8, > from > /usr/i686-w64-mingw32/sys-root/mingw/include/windows.h:69, > from > /builddir/build/BUILD/wine-gecko-2.47.1/wine-gecko-2.47.1/widget/windows/AudioSession.cpp:7, > from > /builddir/build/BUILD/wine-gecko-2.47.1/wine-gecko-2.47.1-x86/widget/windows/Unified_cpp_widget_windows0.cpp:2: > /usr/i686-w64-mingw32/sys-root/mingw/include/cfgmgr32.h: At global scope: > /usr/i686-w64-mingw32/sys-root/mingw/include/cfgmgr32.h:19: note: loc_a > 19 | typedef CONST VOID *PCVOID; > | > (gdb) call inform (loc_b, "loc_b") > In file included from /usr/i686-w64-mingw32/sys-root/mingw/include/windef.h:8, > from > /usr/i686-w64-mingw32/sys-root/mingw/include/windows.h:69, > from > /builddir/build/BUILD/wine-gecko-2.47.1/wine-gecko-2.47.1/widget/windows/AudioSession.cpp:7, > from > /builddir/build/BUILD/wine-gecko-2.47.1/wine-gecko-2.47.1-x86/widget/windows/Unified_cpp_widget_windows0.cpp:2: > /usr/i686-w64-mingw32/sys-root/mingw/include/cfgmgr32.h:19: note: loc_b > 19 | typedef CONST VOID *PCVOID; > | > Guess you now have to trace first_map_in_common_1 where it "breaks" since visually there should be a common map.
(In reply to David Malcolm from comment #15) > where: > > (gdb) call inform (loc_a, "loc_a") > In file included from > /usr/i686-w64-mingw32/sys-root/mingw/include/minwindef.h:163, > from > /usr/i686-w64-mingw32/sys-root/mingw/include/windef.h:8, > from > /usr/i686-w64-mingw32/sys-root/mingw/include/windows.h:69, > from > /builddir/build/BUILD/wine-gecko-2.47.1/wine-gecko-2.47.1/widget/windows/ > AudioSession.cpp:7, > from > /builddir/build/BUILD/wine-gecko-2.47.1/wine-gecko-2.47.1-x86/widget/windows/ > Unified_cpp_widget_windows0.cpp:2: > /usr/i686-w64-mingw32/sys-root/mingw/include/cfgmgr32.h: At global scope: > /usr/i686-w64-mingw32/sys-root/mingw/include/cfgmgr32.h:19: note: loc_a > 19 | typedef CONST VOID *PCVOID; Is the above line the failing point for the testing file? there is a "CONST" qualifier. I am not sure whether it's helpful or not: we found that deleting "CONST" from the source code helped the compilation to succeed.
(In reply to qinzhao from comment #17) > (In reply to David Malcolm from comment #15) > > /builddir/build/BUILD/wine-gecko-2.47.1/wine-gecko-2.47.1-x86/widget/windows/ > > Unified_cpp_widget_windows0.cpp:2: > > /usr/i686-w64-mingw32/sys-root/mingw/include/cfgmgr32.h: At global scope: > > /usr/i686-w64-mingw32/sys-root/mingw/include/cfgmgr32.h:19: note: loc_a > > 19 | typedef CONST VOID *PCVOID; > > Is the above line the failing point for the testing file? > > there is a "CONST" qualifier. I am not sure whether it's helpful or not: we > found that deleting "CONST" from the source code helped the compilation to > succeed. Yes. Note how there are no column numbers for the macro invocation locations. The issue occurs when location_t > LINE_MAP_MAX_LOCATION_WITH_COLS (enough source has been compiled that we've stopped tracking column numbers). We have two locations that are both from macro expansions, and return the same output from: linemap_resolve_location (set, [...], LRK_MACRO_EXPANSION_POINT, NULL); i.e. line 19 of cfgmgr32.h cc1plus attempts to compare the locations of the two declarators ("const" and "void"), decides that they are the same location, and assumes they must be from the same macro expansion - but they're only at the same location because we're no longer attempting to track column numbers. Converting one of both of those "const" and "void" to non-macros ought to work around it. I've created a minimal reproducer and will attempt a fix.
(In reply to David Malcolm from comment #18) > Converting one of both of those "const" and "void" to non-macros ought to "one or both", I meant to say
The master branch has been updated by David Malcolm <dmalcolm@gcc.gnu.org>: https://gcc.gnu.org/g:1f5c80883efce5242d892eb771ebb60830d20e0f commit r11-7179-g1f5c80883efce5242d892eb771ebb60830d20e0f Author: David Malcolm <dmalcolm@redhat.com> Date: Wed Feb 10 14:33:10 2021 -0500 libcpp: fix ICE comparing macro locations without column info [PR96391] PR preprocessor/96391 describes an ICE in the C++ frontend on: #define CONST const #define VOID void typedef CONST VOID *PCVOID; where the typedef line occurs after enough code has been compiled that location_t values are beyond LINE_MAP_MAX_LOCATION_WITH_COLS, and hence no column numbers are available. The issue occurs in linemap_compare_locations when comparing the locations of the "const" and "void" tokens. Upon resolving the LRK_MACRO_EXPANSION_POINT, both have the same location_t, the line of the "typedef" (with no column), and so the l0 == l1 clause is triggered, but they are not from the same macro expansion, leading first_map_in_common to return NULL and triggering the "abort" condition. This patch fixes the issue by checking when the two macro expansion point location_t values are equal that the value <= LINE_MAP_MAX_LOCATION_WITH_COLS and thus has column information, fixing the issue. gcc/testsuite/ChangeLog: PR preprocessor/96391 * g++.dg/plugin/location-overflow-test-pr96391.c: New test. * g++.dg/plugin/plugin.exp (plugin_test_list): Add it, using the location_overflow_plugin.c from gcc.dg/plugin. libcpp/ChangeLog: PR preprocessor/96391 * line-map.c (linemap_compare_locations): Require that the location be <= LINE_MAP_MAX_LOCATION_WITH_COLS when treating locations as coming from the same macro expansion.
Should be fixed on trunk by the above commit. Presumably still affects gcc 10 branch. Updating "Summary" accordingly.
*** Bug 96940 has been marked as a duplicate of this bug. ***
with the latest gcc11, our application can be compiled without any issue now. thanks a lot for fixing this bug. will this patch be added to gcc10?
GCC 10.3 is being released, retargeting bugs to GCC 10.4.
The master branch has been updated by Jason Merrill <jason@gcc.gnu.org>: https://gcc.gnu.org/g:9e64426dae129cca5b62355ef6c5a3bd6137e830 commit r12-1538-g9e64426dae129cca5b62355ef6c5a3bd6137e830 Author: Jason Merrill <jason@redhat.com> Date: Mon Jun 14 17:37:43 2021 -0400 libcpp: location comparison within macro [PR100796] The patch for 96391 changed linemap_compare_locations to give up on comparing locations from macro expansions if we don't have column information. But in this testcase, the BOILERPLATE macro is multiple lines long, so we do want to compare locations within the macro. So this patch moves the LINE_MAP_MAX_LOCATION_WITH_COLS check inside the block, to use it for failing gracefully. PR c++/100796 PR preprocessor/96391 libcpp/ChangeLog: * line-map.c (linemap_compare_locations): Only use comparison with LINE_MAP_MAX_LOCATION_WITH_COLS to avoid abort. gcc/testsuite/ChangeLog: * g++.dg/plugin/location-overflow-test-pr100796.c: New test. * g++.dg/plugin/plugin.exp: Run it.
The releases/gcc-11 branch has been updated by Jason Merrill <jason@gcc.gnu.org>: https://gcc.gnu.org/g:bb2e908638758097e261bca1a4825d171a18af9c commit r11-8583-gbb2e908638758097e261bca1a4825d171a18af9c Author: Jason Merrill <jason@redhat.com> Date: Mon Jun 14 17:37:43 2021 -0400 libcpp: location comparison within macro [PR100796] The patch for 96391 changed linemap_compare_locations to give up on comparing locations from macro expansions if we don't have column information. But in this testcase, the BOILERPLATE macro is multiple lines long, so we do want to compare locations within the macro. So this patch moves the LINE_MAP_MAX_LOCATION_WITH_COLS check inside the block, to use it for failing gracefully. PR c++/100796 PR preprocessor/96391 libcpp/ChangeLog: * line-map.c (linemap_compare_locations): Only use comparison with LINE_MAP_MAX_LOCATION_WITH_COLS to avoid abort. gcc/testsuite/ChangeLog: * g++.dg/plugin/location-overflow-test-pr100796.c: New test. * g++.dg/plugin/plugin.exp: Run it.
I can also say that gcc 11 has fixed this. Thanks. I'm happy to close as I will not be using 10.x anymore.
The patch should be further backported if it doesn't cause any issues.
GCC 10.4 is being released, retargeting bugs to GCC 10.5.
Fixed in GCC 11.