[Bug c++/105293] g++-8/i586: internal compiler error trying to compile with g++ (evtl. related to qt5/moc bug)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105293 --- Comment #5 from Elmar Stellnberger --- Created attachment 52827 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52827=edit 2nd version of patch that should be useable under gcc-8-8.3.0/debian/patches/ Last time I reported that I could not test the patch posted here because the result of package creation with dpkg-buildpackage had vanished. Luckily I found gcc/xg++ and gcc/xgcc which were the required executables that could be installed into /bin/ and tested whether they compiled the new Firefox. g++ with the last patch did not do this. Consequently I have checked out 10.2.2, newer than the last known working good one (10.1.1) from Debian 11 and analysed all changes along the backtrace again. What I found is condensed in the patch above: discover_nonconstant_array_refs (); - was moved up in addition to the other change tested already before If the error is evoked by what is called along the backtrace this needs to resolve it. (I assume now that the Qt5/moc bug is independent and do not use it as reference for the gcc version to compare against any more). Otherwise, the error may stem from something done in a previous pass: during RTL pass: expand Unfortunately this time I was not even able to compile gcc/xg++. Makefiles were garbled, xgcc did not produce a.out (test in Makefile), texinfo files were invalid and I had to copy them from a fresh root and ultimately xg++ stayed the same after all. I had rescued the original g++ as /bin/g++ and that one turned into a link (I know it was a regular file before) although all debian/rules Makefiles only ship into debian/tmp/usr/... and not /. Absolutely no chance to test this second patch! Perhaps someone else can do.
[Bug c++/105293] g++-8/i586: internal compiler error trying to compile with g++ (evtl. related to qt5/moc bug)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105293 --- Comment #4 from Elmar Stellnberger --- The related debian-security discussion can be found here: https://lists.debian.org/debian-security/2022/04/msg00042.html (strangely I can not find my last posts when sorting by Thread, simple to see with sorting by Date)
[Bug c++/105293] g++-8/i586: internal compiler error trying to compile with g++ (evtl. related to qt5/moc bug)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105293 --- Comment #3 from Elmar Stellnberger --- Created attachment 52823 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52823=edit patch that should be useable under gcc-8-8.3.0/debian/patches/ I have recompiled g++ and the output of dpkg-buildpackage -b -kestel...@elstel.org -nc tells me that it should have successfully created the respective .deb package files as before. I have looked into the same directory as before but unfortunately I found not a single .deb there and nowhere else under /usr/src. The files can only have been deleted like the ssh user from /etc/passwd at my nslu2 machine. Another time I found out about a chmod -x /etc/init.d/sshd as I suddenly could not connect to my nslu2 via ssh any more. This looks very similar as what I have experienced with arm-linux-gnueabihf-ld when the program did neither produce an error message, an !=0 return value and no output file as given with -o txtfmt. This was when I had all options right to what I can assess, i.e. just before it must have worked. As for now I can not find out whether the patch really resolves the bug. Someone else will have to be as nice to recompile for me. The patch makes a forward change to a known good g++ (version as suggested by use of moc/Qt5 rather than by building Firefox however). It patches the only piece of code that was different along the backtrace of Firefox-esr-91.8.0esr.
[Bug c++/105293] g++-8/i586: internal compiler error trying to compile with g++ (evtl. related to qt5/moc bug)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105293 --- Comment #2 from Elmar Stellnberger --- One of the differences I see around the backtrace is that the type source_location has been changed into location_t. I could change this in tree-outof-ssa.c, but in reality the change has been made in many files between gcc 8.3.0 and gcc 9.2.0 (did not find 9.2.1). Another change around the backtrace is that the following code block has been stripped from pass_expand::execute: if (chkp_function_instrumented_p (current_function_decl)) chkp_reset_rtl_bounds (); However the following in input.h would say it were without effect to change location_t: typedef source_location location_t; pass_expand is at the very bottom of the stack trace and if it is really these two lines then great, but it could also be the data passed into this process. The assert that fails is: expr.c:220: gcc_assert (from_mode != BLKmode); // convert_move from_mode originates from 389 copy_rtx(SA.partition_to_pseudo[src]) // insert_part_to_rtx_on_edge 733 g->stack_pop() -> src // procedure eliminate_phi 909 elim_graph g(sa->map) // procedure expand_phi_nodes On the other hand perhaps the issue could not even be resolved with 9.2.0. This was just my first guess.
[Bug c++/105293] g++-8/i586: internal compiler error trying to compile with g++ (evtl. related to qt5/moc bug)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105293 Elmar Stellnberger changed: What|Removed |Added Attachment #52821|0 |1 is obsolete|| --- Comment #1 from Elmar Stellnberger --- Created attachment 52822 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52822=edit command line to evoke the error
[Bug c++/105293] New: g++-8/i586: internal compiler error trying to compile with g++ (evtl. related to qt5/moc bug)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105293 Bug ID: 105293 Summary: g++-8/i586: internal compiler error trying to compile with g++ (evtl. related to qt5/moc bug) Product: gcc Version: 8.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: estellnb at elstel dot org Target Milestone: --- Created attachment 52821 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52821=edit command line to evoke the error If I try to compile firefox-esr-91.8.0esr I get the following error in (command line in evoke-compilererr): In file included from src/gl.cc:2643: src/rasterize.h: In function ‘void draw_quad_spans(int, Point2D*, uint32_t, glsl::Interpolants*, Texture&, Texture&, const ClipRect&) [with P = unsigned char]’: src/rasterize.h:782:20: internal compiler error: in convert_move, at expr.c:218 static inline void draw_quad_spans(int nump, Point2D p[4], uint32_t z, ^~~ 0xf78b7b40 __libc_start_main ../csu/libc-start.c:308 Please submit a full bug report, If I run /bin/g++ (g++ 4:8.3.0-1 i386 Debian10/Buster) in gdb: (gdb) l 1 ../sysdeps/unix/sysv/linux/i386/init-first.c: file not found (gdb) bt No stack. The error is known and does not appear in the same version of amd64 Debian. It does not appear with newer versions like Debian11/Bullseye/g++ 4:10.2.1-1 I get another type of error with Qt5/moc (meta object compiler for generating signal handler procedure signatures): usr/include/c++/8/bits/stl_relops.:67: Parse error at "std" /usr/include/c++/8/bits/stl_relops.h start like any .h in bits/ and should be correct. Like the internal compiler error from above this one appears only in i586, but with a wide variety of distributions: i586 Debian10 gcc 8.3.0-1: bad (likewise bad Ubuntu19.04) i586 Ubuntu19.10 gcc 9.2.1: good I will appreciate any hint to what the bug could have been related to. I would like to develop a patch to fix things for Debian10/i386 but do not really know on where to start looking for. I could neither find init-first.c nor libc-start.c looking for such files in the source directory gcc-8-8.3.0.
