[Bug target/110066] [13 Regression] [RISC-V] Segment fault if compiled with -static -pg

[aurelien at aurel32 dot net via Gcc-bugs]

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

--- Comment #25 from Aurelien Jarno  ---
(In reply to Andrew Pinski from comment #23)
> Fixed on the trunk will backport to GCC 13 after 13.2.0 is released (since
> the branch is frozen except for RM approvals).

Now that GCC 13.2.0 has been released, would it be possible to backport the
fix, please?

[Bug tree-optimization/110755] [13/14 Regression] Wrong optimization of fabs on ppc64el at -O1

[aurelien at aurel32 dot net via Gcc-bugs]

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

--- Comment #10 from Aurelien Jarno  ---
(In reply to Jakub Jelinek from comment #9)
> Created attachment 55616 [details]
> gcc14-pr110755.patch
> 
> Updated patch.

Thanks. I have just tested it, and I confirm it fixes the reported issue.

[Bug tree-optimization/110755] [13/14 Regression] Wrong optimization of fabs on ppc64el at -O1

[aurelien at aurel32 dot net via Gcc-bugs]

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

--- Comment #7 from Aurelien Jarno  ---
(In reply to Jakub Jelinek from comment #6)
> Created attachment 55594 [details]
> gcc14-pr110755.patch
> 
> Untested patch.

Thanks for the patch, I confirm it works as expected, now the result is a
positive 0 when using -frounding-math.

[Bug target/110066] [13/14 Regression] [RISC-V] Segment fault if compiled with -static -pg

[aurelien at aurel32 dot net via Gcc-bugs]

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

--- Comment #18 from Aurelien Jarno  ---
(In reply to Andreas Schwab from comment #17)
> I don't think you need -fno-omit-frame-pointer.

I confirm that CRTSTUFF_T_CFLAGS += -fno-asynchronous-unwind-tables
-fno-unwind-tables is enough to fix the issue.

[Bug target/110066] [13/14 Regression] [RISC-V] Segment fault if compiled with -static -pg

[aurelien at aurel32 dot net via Gcc-bugs]

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

--- Comment #15 from Aurelien Jarno  ---
(In reply to Andrew Pinski from comment #14)
> Created attachment 55614 [details]
> patch for someone to test out
> 
> The problem is the similar across many targets so I basically copied what
> was done for another target.

Thanks for the patch, unfortunately it doesn't work as is. However, as commit
3cd08f7168c196d7a481b9ed9f4289fd1f14eea8 enabled both
-fno-asynchronous-unwind-tables and -fno-unwind-tables, I have tried to add
-fno-unwind-tables to riscv/t-crtstuff and that works.

[Bug target/110066] [RISC-V] Segment fault if compiled with -static -pg

[aurelien at aurel32 dot net via Gcc-bugs]

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

--- Comment #12 from Aurelien Jarno  ---
Backtrace with debug symbols in libgcc_eh.a:

Program received signal SIGSEGV, Segmentation fault.
classify_object_over_fdes (ob=0xe2da0 , this_fde=0x1000530e6,
range=0x3ff310) at ../../../gcc/libgcc/unwind-dw2-fde.c:727
727 ../../../gcc/libgcc/unwind-dw2-fde.c: No such file or directory.
(gdb) bt full
#0  classify_object_over_fdes (ob=0xe2da0 , this_fde=0x1000530e6,
range=0x3ff310) at ../../../gcc/libgcc/unwind-dw2-fde.c:727
last_cie = 0x8a43a
count = 1
encoding = 0
base = 0
#1  0x0005277c in __register_frame_info_bases (dbase=0x0, tbase=0x0,
ob=0xe2da0 , begin=) at
../../../gcc/libgcc/unwind-dw2-fde.c:129
range = {4294854026, 4294854042}
range = 
#2  __register_frame_info_bases (dbase=0x0, tbase=0x0, ob=0xe2da0 ,
begin=) at ../../../gcc/libgcc/unwind-dw2-fde.c:109
range = 
range = 
#3  __register_frame_info (begin=, ob=0xe2da0 ) at
../../../gcc/libgcc/unwind-dw2-fde.c:145
No locals.
#4  0x00010728 in frame_dummy ()
No symbol table info available.
#5  0x00010a2a in call_init (envp=0x3ff3d0, argv=0x3ff3b8,
argc=2) at libc-start.c:189
i = 0
size = 
size = 
size = 
i = 
i = 
#6  __libc_start_main_impl (main=0x105f8 , argc=2, argv=0x3ff3b8,
init=, fini=, rtld_fini=,
stack_end=)
at libc-start.c:355
ev = 0x3ff3d0
auxvec = 
stack_chk_guard = 
pointer_chk_guard = 
#7  0x00010638 in _start () at ../sysdeps/riscv/start.S:61

[Bug target/110066] [RISC-V] Segment fault if compiled with -static -pg

[aurelien at aurel32 dot net via Gcc-bugs]

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

--- Comment #11 from Aurelien Jarno  ---
I have bisected the issue, and I found it has been introduced by the following
commit:

commit 3cd08f7168c196d7a481b9ed9f4289fd1f14eea8
Author: Andreas Schwab 
Date:   Wed Jan 25 12:00:09 2023 +0100

riscv: Enable -fasynchronous-unwind-tables by default on Linux

This follows the example of aarch64.

gcc/:
* common/config/riscv/riscv-common.cc
(riscv_option_optimization_table)
[TARGET_DEFAULT_ASYNC_UNWIND_TABLES]: Enable
-fasynchronous-unwind-tables and -funwind-tables.
* config.gcc (riscv*-*-linux*): Define
TARGET_DEFAULT_ASYNC_UNWIND_TABLES.

[Bug target/110066] [RISC-V] Segment fault if compiled with -static -pg

[aurelien at aurel32 dot net via Gcc-bugs]

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

--- Comment #10 from Aurelien Jarno  ---
(In reply to Aurelien Jarno from comment #9)
> (In reply to Andrew Pinski from comment #5)
> > Can you try reverting r13-923-g2d546ff69455f7deadab and try GCC 13 again?
> 
> Yep, I'll do that, but it will probably take some time to get the results.
>

I built a cross-compiler so it went faster than expected. However reverting
that commit doesn't change anything, the generated crtbeginT.o is unchanged, so
the issue is still there.

[Bug target/110066] [RISC-V] Segment fault if compiled with -static -pg

[aurelien at aurel32 dot net via Gcc-bugs]

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

--- Comment #9 from Aurelien Jarno  ---
(In reply to Andrew Pinski from comment #5)
> Can you try reverting r13-923-g2d546ff69455f7deadab and try GCC 13 again?

Yep, I'll do that, but it will probably take some time to get the results.

(In reply to Andrew Pinski from comment #6)
> Also can you attach the two versions of crtbeginT.o (the one from GCC 12 and
> one from GCC 13).
> If anything there has to be some extra null pointer happening ...

I have just done that.

[Bug target/110066] [RISC-V] Segment fault if compiled with -static -pg

[aurelien at aurel32 dot net via Gcc-bugs]

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

--- Comment #8 from Aurelien Jarno  ---
Created attachment 55610
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55610&action=edit
crtbeginT.o GCC 12 version

[Bug target/110066] [RISC-V] Segment fault if compiled with -static -pg

[aurelien at aurel32 dot net via Gcc-bugs]

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

--- Comment #7 from Aurelien Jarno  ---
Created attachment 55609
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55609&action=edit
crtbeginT.o GCC 12 version

[Bug target/110066] [RISC-V] Segment fault if compiled with -static -pg

[aurelien at aurel32 dot net via Gcc-bugs]

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

Aurelien Jarno  changed:

   What|Removed |Added

 CC||aurelien at aurel32 dot net

--- Comment #4 from Aurelien Jarno  ---
This is also reproducible with the tst-gmon-static test from glibc 2.38, when
compiled with GCC 13, while the test passes fine with GCC 12.

A very basic debugging shows that the problem is triggered by using crtbeginT.o
from GCC 13. The test passes when compiling everything with GCC 13, but using
crtbeginT.o from GCC 12.

The backtrace is the following:

Program received signal SIGSEGV, Segmentation fault.
0x000516e2 in classify_object_over_fdes ()
(gdb) bt
#0  0x000516e2 in classify_object_over_fdes ()
#1  0x00052690 in __register_frame_info ()
#2  0x00010570 in frame_dummy ()
#3  0x00010872 in call_init (envp=0x3ff3e0, argv=0x3ff3c8,
argc=2) at libc-start.c:189
#4  __libc_start_main_impl (main=0x10448 , argc=2, argv=0x3ff3c8,
init=, fini=, rtld_fini=,
stack_end=) at libc-start.c:355
#5  0x00010488 in _start () at ../sysdeps/riscv/start.S:61

[Bug target/110755] Wrong optimization of fabs on ppc64el at -O1

[aurelien at aurel32 dot net via Gcc-bugs]

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

--- Comment #2 from Aurelien Jarno  ---
(In reply to Andrew Pinski from comment #1)
> Hmm, this might be the case where you need -frounding-math since we don't
> expectly implement the pragma.

Indeed the original glibc code is compiled with -frounding-math. However adding
it or not doesn't change the resulting code.

[Bug target/110755] New: Wrong optimization of fabs on ppc64el at -O1

[aurelien at aurel32 dot net via Gcc-bugs]

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

Bug ID: 110755
   Summary: Wrong optimization of fabs on ppc64el at -O1
   Product: gcc
   Version: 13.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: aurelien at aurel32 dot net
  Target Milestone: ---

The following code, extracted and simplified from the PowerPC implementation of
nearbyintf() in the GNU libc is wrongly optimized at -O1 and -O2 on ppc64el
with GCC 13. The fabs is removed, while it is not the case with GCC 12

#include 
#include 
#include 

static float my_nearbyintf (float x)
{ 
  float r = x;

  if (x > 0.0)
{ 
  r += 0x1p+23;
  r -= 0x1p+23;
  r = fabs (r);
}

  return r;
}

int main()
{
volatile float in = 0.5f;

fesetround (FE_DOWNWARD);
printf("mynearbyintf(in) = %lf\n", my_nearbyintf(in));
}

This causes the result to have the wrong sign.

[Bug target/104338] RISC-V: Subword atomics result in library calls

[aurelien at aurel32 dot net via Gcc-bugs]

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

--- Comment #18 from Aurelien Jarno  ---
Thanks Patrick for working on that and for the backport to the gcc-13 branch. I
wonder if the following patch should also be backported, as it doesn't make
sense to link with -latomic anymore with inline subword atomic operations:

commit 203f3060dd363361b172f7295f42bb6bf5ac0b3b
Author: Andreas Schwab 
Date:   Sat Apr 23 15:48:42 2022 +0200

riscv/linux: Don't add -latomic with -pthread

Now that we have support for inline subword atomic operations, it is no
longer necessary to link against libatomic.  This also fixes testsuite
failures because the framework does not properly set up the linker flags
for finding libatomic.
The use of atomic operations is also independent of the use of libpthread.

gcc/
* config/riscv/linux.h (LIB_SPEC): Don't redefine.

[Bug target/104338] RISC-V: Subword atomics result in library calls

[aurelien at aurel32 dot net via Gcc-bugs]

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

Aurelien Jarno  changed:

   What|Removed |Added

 CC||aurelien at aurel32 dot net

--- Comment #10 from Aurelien Jarno  ---
I am not subscribed to the mailing list, but I am not able to see any more
mails after the v3. Any update?

[Bug debug/103874] [11 Regression] ICE in internal_error on riscv64 and -gsplit-dwarf

[aurelien at aurel32 dot net via Gcc-bugs]

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

--- Comment #11 from Aurelien Jarno  ---
Thanks for the patch! I confirm the issue is fixed on the trunk. I also tried
to apply it on the GCC 11 branch (which is basically renaming dwarf2out.cc into
dwarf2out.c in the patch) and this also works fine.

[Bug target/103874] [11/12 Regression] ICE in internal_error on riscv64

[aurelien at aurel32 dot net via Gcc-bugs]

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

Aurelien Jarno  changed:

   What|Removed |Added

 CC||jakub at redhat dot com

--- Comment #5 from Aurelien Jarno  ---
A bisect pointed me to that commit:

commit 4b33c5aaab9e863da162942ab8bcd54070b705af
Author: Jakub Jelinek 
Date:   Wed Mar 31 21:25:58 2021 +0200

dwarf2out: Fix up ranges for -gdwarf-5 -gsplit-dwarf [PR99490]

For -gdwarf-4 -gsplit-dwarf we used to emit .debug_ranges section
(so in the binaries/shared libraries) with DW_AT_ranges from skeleton
units as well as .debug_info.dwo pointing to it through DW_FORM_sec_offset
(and DW_AT_GNU_ranges_base pointing into section, not sure for what
reason exactly).
When DWARF5 support was being added, we've started using .debug_rnglists
section, added DW_AT_rnglists_base to the DW_TAG_skeleton_unit, kept
DW_AT_ranges with DW_FORM_sec_offset in the skeleton and switched
over to DW_FORM_rnglistx for DW_AT_ranges in .debug_info.dwo.
But the DWARF5 spec actually means for the ranges section (at least
everything for those DW_AT_ranges in .debug_info.dwo) to sit
in .debug_rnglists.dwo section next to the .debug_info.dwo, rather than
having consumers look it up in the binary/shared library instead.
Based on some discussions in the DWARF discuss mailing list:
   
http://lists.dwarfstd.org/pipermail/dwarf-discuss-dwarfstd.org/2021-March/thread.html#4765
this patch mostly follows what LLVM emits for that right now:
1) small .debug_rnglists section (when needed) just to cover the
   skeleton DW_AT_ranges (if present); the content of the section
   uses the Split DWARFy DW_RLE_* codes with addrx encodings where
   possible
2) DW_AT_ranges in the skeleton uses DW_FORM_sec_offset (difference
   from LLVM which uses DW_FORM_rnglistx, which makes it larger
   and ambiguous)
3) DW_AT_rnglists_base attribute is gone from the skeleton (again,
   unlike LLVM where it is just confusing what exactly it means because
   it is inherited; it would make sense if we emitted DW_FORM_rnglistx
   in non-split DWARF, but unless ranges are shared, I'm afraid we'd
   make DWARF larger with fewer relocations by that)
4) usually big .debug_rnglists.dwo section again with using DW_RLE_*x*
   where possible
5) DW_AT_ranges with DW_FORM_rnglistx from .debug_info.dwo referring to
   that .debug_rnglists.dwo ranges

2021-03-31  Jakub Jelinek  

PR debug/99490
* dwarf2out.c (debug_ranges_dwo_section): New variable.
(DW_RANGES_IDX_SKELETON): Define.
(struct dw_ranges): Add begin_entry and end_entry members.
(DEBUG_DWO_RNGLISTS_SECTION): Define.
(add_ranges_num): Adjust r initializer for addition of *_entry
members.
(add_ranges_by_labels): For -gsplit-dwarf and force_direct,
set idx to DW_RANGES_IDX_SKELETON.
(use_distinct_base_address_for_range): New function.
(index_rnglists): Don't set r->idx if it is equal to
DW_RANGES_IDX_SKELETON.  Initialize r->begin_entry and
r->end_entry for -gsplit-dwarf if those will be needed by
output_rnglists.
(output_rnglists): Add DWO argument.  If true, switch to
debug_ranges_dwo_section rather than debug_ranges_section.
Adjust l1/l2 label indexes.  Only output the offset table when
dwo is true and don't include in there the skeleton range
entry if present.  For -gsplit-dwarf, skip ranges that belong
to the other rnglists section.  Change return type from void
to bool and return true if there are any range entries for
the other section.  For dwarf_split_debug_info use
DW_RLE_startx_endx, DW_RLE_startx_length and DW_RLE_base_addressx
entries instead of DW_RLE_start_end, DW_RLE_start_length and
DW_RLE_base_address.  Use use_distinct_base_address_for_range.
(init_sections_and_labels): Initialize debug_ranges_dwo_section
if -gsplit-dwarf and DWARF >= 5.  Adjust ranges_section_label
and range_base_label indexes.
(dwarf2out_finish): Call index_rnglists earlier before finalizing
.debug_addr.  Never emit DW_AT_rnglists_base attribute.  For
-gsplit-dwarf and DWARF >= 5 call output_rnglists up to twice
with different dwo arguments.
(dwarf2out_c_finalize): Clear debug_ranges_dwo_section.

 gcc/dwarf2out.c | 255 ++--
 1 file changed, 211 insertions(+), 44 deletions(-)

[Bug target/103874] [11/12 Regression] ICE in internal_error on riscv64

[aurelien at aurel32 dot net via Gcc-bugs]

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

--- Comment #4 from Aurelien Jarno  ---
This is a better backtrace after building a riscv64 cross compiler from the
releases/gcc-11 branch:

/tmp/onnxifi_loader.c.i:6:1: internal compiler error: Segmentation fault
6 | }
  | ^
0xadad0f crash_signal
/home/aurel32/git/gcc/gcc/toplev.c:327
0x76ef21 output_rnglists
/home/aurel32/git/gcc/gcc/dwarf2out.c:12174
0x7b7782 dwarf2out_finish
/home/aurel32/git/gcc/gcc/dwarf2out.c:32058
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug target/103874] [11/12 Regression] ICE in internal_error on riscv64

[aurelien at aurel32 dot net via Gcc-bugs]

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

--- Comment #3 from Aurelien Jarno  ---
I have been able to reduce the reproducer code to almost nothing, so I guess
the issue is mostly related to the options and not to the source code.

[Bug target/103874] [11/12 Regression] ICE in internal_error on riscv64

[aurelien at aurel32 dot net via Gcc-bugs]

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

Aurelien Jarno  changed:

   What|Removed |Added

  Attachment #52099|0   |1
is obsolete||

--- Comment #2 from Aurelien Jarno  ---
Created attachment 52100
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52100&action=edit
Minimal reproducer

[Bug c/103874] [11/12 Regression] ICE in internal_error on riscv64

[aurelien at aurel32 dot net via Gcc-bugs]

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

--- Comment #1 from Aurelien Jarno  ---
Sorry I submitted the bug by mistake without filling a comment.

pytorch failed to build in Debian on riscv64 following the switch to GCC 11 by
default:
https://buildd.debian.org/status/fetch.php?pkg=pytorch&arch=riscv64&ver=1.8.1-2%2Bb3&stamp=1640951671&raw=0

I have extracted a reproducer (attached), here are the output with GCC 10, 11
and 12:

aurel32@beaglev:~/pytorch$ gcc-10 -v
Using built-in specs.
COLLECT_GCC=gcc-10
COLLECT_LTO_WRAPPER=/usr/lib/gcc/riscv64-linux-gnu/10/lto-wrapper
Target: riscv64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 10.3.0-13'
--with-bugurl=file:///usr/share/doc/gcc-10/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-10
--program-prefix=riscv64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new
--enable-gnu-unique-object --disable-libitm --disable-libsanitizer
--disable-libquadmath --disable-libquadmath-support --enable-plugin
--enable-default-pie --with-system-zlib --enable-libphobos-checking=release
--with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch
--disable-werror --disable-multilib --with-arch=rv64imafdc --with-abi=lp64d
--enable-checking=release --build=riscv64-linux-gnu --host=riscv64-linux-gnu
--target=riscv64-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.3.1 2027 (Debian 10.3.0-13)
aurel32@beaglev:~/pytorch$ /usr/bin/gcc-10 -gsplit-dwarf -O2 -g -fPIC -std=c90
-c ./onnxifi_loader.c.i
aurel32@beaglev:~/pytorch$


aurel32@beaglev:~/pytorch$ gcc-11 -v
Using built-in specs.
COLLECT_GCC=gcc-11
COLLECT_LTO_WRAPPER=/usr/lib/gcc/riscv64-linux-gnu/11/lto-wrapper
Target: riscv64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 11.2.0-13'
--with-bugurl=file:///usr/share/doc/gcc-11/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-11
--program-prefix=riscv64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new
--enable-gnu-unique-object --disable-libitm --disable-libquadmath
--disable-libquadmath-support --enable-plugin --enable-default-pie
--with-system-zlib --enable-libphobos-checking=release
--with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch
--disable-werror --disable-multilib --with-arch=rv64imafdc --with-abi=lp64d
--enable-checking=release --build=riscv64-linux-gnu --host=riscv64-linux-gnu
--target=riscv64-linux-gnu --with-build-config=bootstrap-lto-lean
--enable-link-serialization=2
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.2.0 (Debian 11.2.0-13)   
(sid-riscv64)aurel32@beaglev:~/pytorch$ /usr/bin/gcc-11 -gsplit-dwarf -O2 -g
-fPIC -std=c90 -c ./onnxifi_loader.c.i
/home/aurel32/pytorch/pytorch-1.8.1/debian/foxi/foxi/onnxifi_loader.c:212:1:
internal compiler error: Segmentation fault
  212 | }
  | ^
0xa26915 internal_error(char const*, ...)
???:0
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
aurel32@beaglev:~/pytorch$


aurel32@beaglev:~/pytorch$ gcc-12 -v
Using built-in specs.
COLLECT_GCC=gcc-12
COLLECT_LTO_WRAPPER=/usr/lib/gcc/riscv64-linux-gnu/12/lto-wrapper
Target: riscv64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 12-20211217-1'
--with-bugurl=file:///usr/share/doc/gcc-12/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-12
--program-prefix=riscv64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new
--enable-gnu-unique-object --disable-libitm --disable-libquadmath
--disable-libquadmath-support --enable-plugin --enable-default-pie
--with-system-zlib --enable-libphobos-checking=release
--with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch
--disable-werror --disable-multilib --with-arch=rv64imafdc --with-abi=lp64d
--enable-checking=release --build=riscv64-linux-gnu --host=riscv64-linux-gnu
--target=riscv64-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.0 20211217 (experimental) [master r12-6027-g774269aa4b9]
(Debian 12-2021121

[Bug c/103874] New: [11/12 Regression] ICE in internal_error on riscv64

[aurelien at aurel32 dot net via Gcc-bugs]

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

Bug ID: 103874
   Summary: [11/12 Regression] ICE in internal_error on riscv64
   Product: gcc
   Version: 11.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: aurelien at aurel32 dot net
  Target Milestone: ---

Created attachment 52099
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52099&action=edit
Reproducer