[Bug c++/105293] New: g++-8/i586: internal compiler error trying to compile with g++ (evtl. related to qt5/moc bug)

[Bug c++/105293] New: g++-8/i586: internal compiler error trying to compile with g++ (evtl. related to qt5/moc bug)

[estellnb at elstel dot org]

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&action=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.

[Bug c++/105293] g++-8/i586: internal compiler error trying to compile with g++ (evtl. related to qt5/moc bug)

[estellnb at elstel dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105293

Elmar Stellnberger <estellnb at elstel dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #52821|0                           |1
        is obsolete|                            |

--- Comment #1 from Elmar Stellnberger <estellnb at elstel dot org> ---
Created attachment 52822
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52822&action=edit
command line to evoke the error

[Bug c++/105293] g++-8/i586: internal compiler error trying to compile with g++ (evtl. related to qt5/moc bug)

[estellnb at elstel dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105293

--- Comment #2 from Elmar Stellnberger <estellnb at elstel dot org> ---
  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)

[estellnb at elstel dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105293

--- Comment #3 from Elmar Stellnberger <estellnb at elstel dot org> ---
Created attachment 52823
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52823&action=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
-kestellnb@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)

[estellnb at elstel dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105293

--- Comment #4 from Elmar Stellnberger <estellnb at elstel dot org> ---
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)

[estellnb at elstel dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105293

--- Comment #5 from Elmar Stellnberger <estellnb at elstel dot org> ---
Created attachment 52827
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52827&action=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)

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105293

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2022-04-19
     Ever confirmed|0                           |1

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
Note that GCC 8 is no longer maintained and you should be using the last
release from this branch, GCC 8.5.  Can you check whether GCC 9.4 or later work
correctly?

[Bug c++/105293] g++-8/i586: internal compiler error trying to compile with g++ (evtl. related to qt5/moc bug)

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105293

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |INVALID
             Status|WAITING                     |RESOLVED
   Target Milestone|---                         |9.0

--- Comment #7 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #6)
> Note that GCC 8 is no longer maintained and you should be using the last
> release from this branch, GCC 8.5.  Can you check whether GCC 9.4 or later
> work correctly?

Since r9-1060-g31db0fe044cc9d, the code related to chkp (and
chkp_function_instrumented_p) is removed so I am going to assume this was fixed
for GCC 9.
Plus there is no testcase to prove it so just closing as invalid.