Bug 2239498 - Internal compiler error
Summary: Internal compiler error
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: gcc
Version: 40
Hardware: i686
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Fedora Extras Quality Assurance
URL: https://koji.fedoraproject.org/koji/g...
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2023-09-18 17:14 UTC by Michal Schorm
Modified: 2025-04-08 16:12 UTC (History)
10 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2025-04-08 16:12:00 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
GNU Compiler Collection 111497 0 P2 NEW [11/12/13/14 Regression] ICE building mariadb on i686 since r8-470 2023-09-20 14:43:11 UTC

Description Michal Schorm 2023-09-18 17:14:35 UTC
I'm preparing a rebase of package 'mariadb' from version 10.5.21 to version 10.5.22.

Exclusively on architecture i686, it gives me 'Internal compiler error(s)'.
This is reproducible on all non-EOL Fedora versions.

---

Sample:

CMakeFiles/sql.dir/sql_get_diagnostics.cc.o -c /builddir/build/BUILD/mariadb-10.5.22-downstream_modified/sql/sql_get_diagnostics.cc
/builddir/build/BUILD/mariadb-10.5.22-downstream_modified/storage/perfschema/ha_perfschema.cc: In member function 'delete_table':
/builddir/build/BUILD/mariadb-10.5.22-downstream_modified/storage/perfschema/ha_perfschema.cc:473:8: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]
  473 |   *ptr = '\0';
      |        ^
/builddir/build/BUILD/mariadb-10.5.22-downstream_modified/storage/perfschema/ha_perfschema.cc:455:8: note: at offset -1 into destination object 'table_path' of size 513
  455 |   char table_path[FN_REFLEN+1];
      |        ^
*** WARNING *** there are active plugins, do not report this as a bug unless you can reproduce it without enabling any plugins.
Event                            | Plugins
PLUGIN_FINISH_UNIT               | annobin: Generate final annotations
PLUGIN_START_UNIT                | annobin: Generate global annotations
PLUGIN_ALL_PASSES_START          | annobin: Generate per-function annotations
PLUGIN_ALL_PASSES_END            | annobin: Register per-function end symbols
during RTL pass: pro_and_epilogue
/builddir/build/BUILD/mariadb-10.5.22-downstream_modified/sql/item.cc: In member function '__ct_base ':
/builddir/build/BUILD/mariadb-10.5.22-downstream_modified/sql/item.cc:7826:1: internal compiler error: in find_oldest_value_reg, at regcprop.cc:460
 7826 | }
      | ^
Please submit a full bug report, with preprocessed source.

---

https://koji.fedoraproject.org/koji/getfile?taskID=106290589&volume=DEFAULT&name=build.log&offset=-40000



Reproducible: Always

Steps to Reproduce:
Pick rebase, build in KOJI.
Actual Results:  
Internal compiler error

Expected Results:  
Compiles

If it would be on me, I'd rather stop building i686 variants of package 'mariadb', as I see no value in that. See
https://discussion.fedoraproject.org/t/is-it-safe-to-stop-building-i686-builds-of-mariadb/90198
where I described it.

Comment 1 Michal Schorm 2023-09-18 18:47:27 UTC
In a private fork in this branch:
  https://src.fedoraproject.org/fork/mschorm/rpms/mariadb/commits/internal-compiler-error
I've put the prepared rebase to mariadb 10.5.22 and on top of it several debug commits aims mostly minimize the reproducer.

The last debug commit enables the debug build, and it is the only mode, in which the compilation succeeded. (build failed in %install phase , which if file)

You can do a test builds from that branch with:
  fedpkg --release=rawhide build --scratch --srpm --arches=i686
That is how I produced the scratch builds

https://koji.fedoraproject.org/koji/taskinfo?taskID=106357029
https://koji.fedoraproject.org/koji/taskinfo?taskID=106357363
https://koji.fedoraproject.org/koji/taskinfo?taskID=106358180 (this one is the debug build)

Comment 2 Jakub Jelinek 2023-09-20 07:29:57 UTC
If you want quick workaround, I think
%ifarch i686
%global _lto_cflags %{nil}
%endif
early in the spec file should do the trick, as it (unfortunately for me) isn't reproducible without LTO.
Will try to reduce it now.

Comment 3 Michal Schorm 2023-09-20 11:40:35 UTC
Thank you for the workaround! It seems to be working well so far.

%ifarch i686
%global _lto_cflags %{nil}
%endif

I'll use it for the production builds, and potentially revert it later, once the issue is resolved, either on my, your or the upstream side.

Comment 4 Jakub Jelinek 2023-09-20 11:48:15 UTC
From initial investigation, it looks like some LRA bug on debug instructions where it leaves a pseudo-register in one of them for some reason.
So, another workaround might be to build i686 sql/item.cc with -g0 rather than -g, or perhaps just -fno-var-tracking-assignments.

Comment 5 Jakub Jelinek 2023-09-20 14:43:11 UTC
Now reduced and filed upstream as https://gcc.gnu.org/PR111497

Comment 6 Michal Schorm 2023-09-25 06:53:51 UTC
Thank you Jakub.
I haven't expected such a quick help and fast resolution.

Well done, much appreciated 👍

Comment 7 Aoife Moloney 2024-02-15 22:58:04 UTC
This bug appears to have been reported against 'rawhide' during the Fedora Linux 40 development cycle.
Changing version to 40.

Comment 8 Michal Schorm 2025-04-08 16:12:00 UTC
Upstream ticket closed as RESOLVED.

I haven't encountered this issue recently.
Closing

Thank you for the fix !


Note You need to log in before you can comment on or make changes to this bug.