[Bug tree-optimization/113551] [13 Regression] Miscompilation with -O1 -funswitch-loops -fno-strict-overflow

[mikpelinux at gmail dot com via Gcc-bugs]

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

Mikael Pettersson  changed:

   What|Removed |Added

 CC||mikpelinux at gmail dot com

--- Comment #20 from Mikael Pettersson  ---
For gcc-14 this test case was fixed by 

dc48d1d1d4458773f89f21b2f019f66ddf88f2e5 is the first new commit
commit dc48d1d1d4458773f89f21b2f019f66ddf88f2e5
Author: Andrew MacLeod 
Date:   Thu Aug 17 11:13:14 2023 -0400

Fix range-ops operator_addr.

Lack of symbolic information prevents op1_range from beig able to draw
the same conclusions as fold_range can.

PR tree-optimization/111009
gcc/
* range-op.cc (operator_addr_expr::op1_range): Be more restrictive.

That commit was backported to gcc-13 in
421311a31a12b96143eb901fde0e020771fe71d4, and that fixed this test case there
too.

Not sure if this is the proper fix or just makes the issue latent.

[Bug target/115010] m68k: invalid subl instruction generated

[mikpelinux at gmail dot com via Gcc-bugs]

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

Mikael Pettersson  changed:

   What|Removed |Added

 CC||mikpelinux at gmail dot com

--- Comment #10 from Mikael Pettersson  ---
Reproduces with a cross to m68k-linux-gnu compiling the shortened test case
with -O2 -m68060. A git bisect between 13.2.0 and 14.1.0 identified the
following commit as introducing the misbehaviour:

d8a6945c6ea22efa4d5e42fe1922d2b27953c8cd is the first new commit
commit d8a6945c6ea22efa4d5e42fe1922d2b27953c8cd
Author: Roger Sayle 
Date:   Sun May 7 07:52:15 2023 +0100

Don't call emit_clobber in lower-subreg.cc's resolve_simple_move.

Possibly it just exposes a latent issue in the target code.

[Bug tree-optimization/114937] [11 regression] -ftree-vrp optimizes out range check before conditional increment

[mikpelinux at gmail dot com via Gcc-bugs]

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

--- Comment #5 from Mikael Pettersson  ---
I ran a git bisect between 11.4.0 and 12.3.0, which identified the following as
fixing this test case:

2e96b5f14e4025691b57d2301d71aa6092ed44bc is the first new commit
commit 2e96b5f14e4025691b57d2301d71aa6092ed44bc
Author: Aldy Hernandez 
Date:   Tue Jun 15 12:32:51 2021 +0200

Backwards jump threader rewrite with ranger.

[Bug target/114910] can't build a c6x cross compiler

[mikpelinux at gmail dot com via Gcc-bugs]

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

--- Comment #8 from Mikael Pettersson  ---
According to my git bisect, the assembler error started with

551935d11817dd5b139d66c36f62c0f0eba0db06 is the first new commit
commit 551935d11817dd5b139d66c36f62c0f0eba0db06
Author: Alexandre Oliva 
Date:   Fri Oct 20 07:50:33 2023 -0300

Control flow redundancy hardening

[Bug target/114910] can't build a c6x cross compiler

[mikpelinux at gmail dot com via Gcc-bugs]

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

Mikael Pettersson  changed:

   What|Removed |Added

 CC||mikpelinux at gmail dot com

--- Comment #7 from Mikael Pettersson  ---
(In reply to Marc Poulhiès from comment #6)
> It fails with -Os.
> It works with -O0, -O1, -O2, -O3 and -Os -fno-var-tracking.
> 
> Mikael, is it possible that you're not using -Os for target libs?

I'm not adding -Os anywhere, just taking defaults.
Confirmed that adding --enable-target-optspace triggers the assembler error.

[Bug target/114910] can't build a c6x cross compiler

[mikpelinux at gmail dot com via Gcc-bugs]

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

--- Comment #5 from Mikael Pettersson  ---
I don't use crosstool-ng, but I have no problems building a cross to
c6x-unknown-elf with binutils-2.42, gcc-14.1.0-RC-20240430, and
newlib-4.4.0.20231231. (A cross to c6x-unknown-uclibc with uclibc-ng-1.0.47
experiences some problems not seen with gcc-13.2.0, but those are
compiler-warnings-that-now-are-errors rather than the assembler errors you
cited.)

[Bug target/113779] Very inefficient m68k code generated for simple copy loop

[mikpelinux at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Mikael Pettersson  ---
I'm not sure this is an m68k bug. I tried several targets that have
auto-increment addressing modes (m68k, pdp11, msp430, vax, aarch64) and none of
them would use auto-increment for this test case.

[Bug target/113357] [14 regression] m68k-linux bootstrap failure in stage2 due to segfault compiling unwind-dw2.c

[mikpelinux at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Mikael Pettersson  ---
Confirmed:

04c9cf5c786b94fbe3f6f21f06cae73a7575ff7a is the first new commit
commit 04c9cf5c786b94fbe3f6f21f06cae73a7575ff7a
Author: Manolis Tsamis 
Date:   Mon Oct 16 13:08:12 2023 -0600

Implement new RTL optimizations pass: fold-mem-offsets

[Bug target/113357] [14 regression] m68k-linux bootstrap failure in stage2 due to segfault compiling unwind-dw2.c

[mikpelinux at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Mikael Pettersson  ---
git bisect identified the following as the start of this error:

# new: [04c9cf5c786b94fbe3f6f21f06cae73a7575ff7a] Implement new RTL
optimizations pass: fold-mem-offsets

Note the error still reproduced as of 2024-01-07 so wasn't fixed by PR111601.

(Technically my bisect has one more commit to test, the one immediately before
the above, but that one only updates gcc/d/ so cannot have any impact to my
bootstraps.)

[Bug target/82420] ICE with -malign-int and -m68000

[mikpelinux at gmail dot com via Gcc-bugs]

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

--- Comment #6 from Mikael Pettersson  ---
Updated patch posted:
https://gcc.gnu.org/pipermail/gcc-patches/2024-January/643139.html

[Bug target/110934] m68k: ICE with -fzero-call-used-regs=all compiling openssh 9.3p2

[mikpelinux at gmail dot com via Gcc-bugs]

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

--- Comment #12 from Mikael Pettersson  ---
Patch posted:
https://gcc.gnu.org/pipermail/gcc-patches/2024-January/643276.html

[Bug target/108640] ICE compiling busybox for m68k in change_address_1, at emit-rtl.cc:2283

[mikpelinux at gmail dot com via Gcc-bugs]

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

--- Comment #7 from Mikael Pettersson  ---
Patch posted:
https://gcc.gnu.org/pipermail/gcc-patches/2024-January/643383.html

[Bug target/113324] internal compiler error: in reload_combine_note_use, at postreload.c:1534

[mikpelinux at gmail dot com via Gcc-bugs]

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

Mikael Pettersson  changed:

   What|Removed |Added

 CC||mikpelinux at gmail dot com

--- Comment #4 from Mikael Pettersson  ---
The ICE was fixed for 11.0 and up by 85f5a7d6ac9380fb9a07a8c900aa2e21d83d6805
 which is
part of a series of major updates to the vax backend.

Your best bet is to upgrade to gcc-11 or newer.

[Bug target/113357] [14 regression] m68k-linux bootstrap failure in stage2 due to segfault compiling unwind-dw2.c

[mikpelinux at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Mikael Pettersson  ---
/mnt/scratch/gcc-14-20240107/configure --prefix=/mnt/scratch/install14
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id --with-linker-hash-style=gnu --disable-sjlj-exceptions
--disable-plugin --disable-lto --disable-multilib --disable-libgomp
--enable-initfini-array --enable-languages=c,c++

[Bug bootstrap/113357] New: [14 regression] m68k-linux bootstrap failure in stage2 due to segfault compiling unwind-dw2.c

[mikpelinux at gmail dot com via Gcc-bugs]

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

Bug ID: 113357
   Summary: [14 regression] m68k-linux bootstrap failure in stage2
due to segfault compiling unwind-dw2.c
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mikpelinux at gmail dot com
  Target Milestone: ---

gcc-14 native(*) bootstrap on m68k-linux-gnu fails during stage2 as follows:

ranlib  libgcov.a
/mnt/scratch/objdir14/./gcc/xgcc -B/mnt/scratch/objdir14/./gcc/
-B/mnt/scratch/install14/m68k-unknown-linux-gnu/bin/
-B/mnt/scratch/install14/m68k-unknown-linux-gnu/lib/ -isystem
/mnt/scratch/install14/m68k-unknown-linux-gnu/include -isystem
/mnt/scratch/install14/m68k-unknown-linux-gnu/sys-include   -fno-checking -g
-O2 -O2  -g -O2 -DIN_GCC   -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition  -isystem
./include   -fPIC -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector  
-fPIC -I. -I. -I../.././gcc -I/mnt/scratch/gcc-14-20240107/libgcc
-I/mnt/scratch/gcc-14-20240107/libgcc/.
-I/mnt/scratch/gcc-14-20240107/libgcc/../gcc
-I/mnt/scratch/gcc-14-20240107/libgcc/../include  -DHAVE_CC_TLS   -o
unwind-dw2.o -MT unwind-dw2.o -MD -MP -MF unwind-dw2.dep -fexceptions -c
/mnt/scratch/gcc-14-20240107/libgcc/unwind-dw2.c -fvisibility=hidden
-DHIDE_EXPORTS
during GIMPLE pass: switchlower
/mnt/scratch/gcc-14-20240107/libgcc/unwind-dw2.c: In function
'execute_stack_op':
/mnt/scratch/gcc-14-20240107/libgcc/unwind-dw2.c:524:1: internal compiler
error: Segmentation fault
  524 | execute_stack_op (const unsigned char *op_ptr, const unsigned char
*op_end,
  | ^~~~
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
See  for instructions.
make[3]: *** [/mnt/scratch/gcc-14-20240107/libgcc/shared-object.mk:14:
unwind-dw2.o] Error 1
make[3]: Leaving directory
'/mnt/scratch/objdir14/m68k-unknown-linux-gnu/libgcc'
make[2]: *** [Makefile:17845: all-stage2-target-libgcc] Error 2
make[2]: Leaving directory '/mnt/scratch/objdir14'
make[1]: *** [Makefile:21317: stage2-bubble] Error 2
make[1]: Leaving directory '/mnt/scratch/objdir14'
make: *** [Makefile:21513: bootstrap] Error 2

This has been going on since 20231022, 20231015 was good. gcc-13 is also good.

Starting a git bisect now, but it'll take at least several weeks to get a
result.

(*) M1 mini running Aranym running m68k-linux-gnu full-system emulation.

[Bug target/113324] internal compiler error: in reload_combine_note_use, at postreload.c:1534

[mikpelinux at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Mikael Pettersson  ---
I can reproduce with gcc-10.5.0 hosted on x86_64-pc-linux-gnu targeting
vax-netbsdelf, but not with gcc-11.4.0. 12.3.0, or 13.2.0.

[Bug target/105525] some targets don't define __INTPTR_TYPE__ breaking libgcov-driver.c

[mikpelinux at gmail dot com via Gcc-bugs]

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

Mikael Pettersson  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED
  Known to work||14.0

--- Comment #5 from Mikael Pettersson  ---
Fixed for gcc-14, no plans to backport.

[Bug target/110934] m68k: ICE with -fzero-call-used-regs=all compiling openssh 9.3p2

[mikpelinux at gmail dot com via Gcc-bugs]

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

--- Comment #11 from Mikael Pettersson  ---
Reduced test case:

> cat ../pr110934.c 
extern double clobber_fp0(void);
void f(void) { clobber_fp0(); }
> gcc/xgcc -Bgcc -fzero-call-used-regs=used -fPIC -O -S ../pr110934.c
during RTL pass: zero_call_used_regs
../pr110934.c: In function 'f':
../pr110934.c:2:31: internal compiler error: in change_address_1, at
emit-rtl.cc:2299
2 | void f(void) { clobber_fp0(); }
  |  ^
0x40dc15 change_address_1
/mnt/scratch/other/mikpe-gcc.git/gcc/emit-rtl.cc:2299
0x69dc1e emit_move_insn(rtx_def*, rtx_def*)
/mnt/scratch/other/mikpe-gcc.git/gcc/expr.cc:4717
0xa0cf63 default_zero_call_used_regs(unsigned long)
/mnt/scratch/other/mikpe-gcc.git/gcc/targhooks.cc:1112
0x6ed8fa gen_call_used_regs_seq
/mnt/scratch/other/mikpe-gcc.git/gcc/function.cc:5928
0x6ed8fa execute
/mnt/scratch/other/mikpe-gcc.git/gcc/function.cc:6785
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

The issue is that to zero %fp0 the generic code synthesizes a move from
(const_double:XF 0.0 [0x0.0p+0]) which is replaced by a label referencing a
literal in .rodata, but that label is rejected by
m68k_legitimate_constant_address_p due to -fPIC, which triggers the assertion
failure in change_address_1.

[Bug target/82420] ICE with -malign-int and -m68000

[mikpelinux at gmail dot com via Gcc-bugs]

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

--- Comment #5 from Mikael Pettersson  ---
Patch submitted:
https://gcc.gnu.org/pipermail/gcc-patches/2024-January/641800.html

[Bug target/111279] ICE: Segmentation fault with m68k,SJLJ and -malign-int

[mikpelinux at gmail dot com via Gcc-bugs]

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

Mikael Pettersson  changed:

   What|Removed |Added

 CC||mikpelinux at gmail dot com

--- Comment #4 from Mikael Pettersson  ---
(In reply to Thorsten Otto from comment #3)
> Created attachment 55837 [details]
> Avoid segmentation fault when calling assign_temp with a NULL type pointer
> 
> Attached is a potential patch to fix that.
> 
> The above mentioned commit was made for gcc 4.3, and all compiler versions
> after that are affected by it.

This patch also fixes PR82420. That PR contains a tidied up patch with a test
case and proper attribution to your original. Will you submit your patch or
should I submit mine?

[Bug target/82420] ICE with -malign-int and -m68000

[mikpelinux at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Mikael Pettersson  ---
Created attachment 56985
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56985=edit
proposed fix

[Bug target/110627] m68k: “Tried to convert PC relative branch to absolute jump” while building iconvdata/iso-2022-jp.c from glibc

[mikpelinux at gmail dot com via Gcc-bugs]

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

Mikael Pettersson  changed:

   What|Removed |Added

 CC||mikpelinux at gmail dot com

--- Comment #1 from Mikael Pettersson  ---
I believe this is a duplicate of PR103370.

[Bug target/104028] M68k: Error: value -16034 out of range for switch tables in some cases with optimization

[mikpelinux at gmail dot com via Gcc-bugs]

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

Mikael Pettersson  changed:

   What|Removed |Added

 CC||mikpelinux at gmail dot com

--- Comment #12 from Mikael Pettersson  ---
The reduced test case stopped failing in gcc >= 12 with

# first new commit: [2e96b5f14e4025691b57d2301d71aa6092ed44bc] Backwards jump
threader rewrite with ranger.

but the original test case (sg_vpd.i) still fails with current master.

[Bug target/109133] Error: operands mismatch -- statement `movec %d0,%cacr' ignored

[mikpelinux at gmail dot com via Gcc-bugs]

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

Mikael Pettersson  changed:

   What|Removed |Added

 CC||mikpelinux at gmail dot com

--- Comment #1 from Mikael Pettersson  ---
Looks like either a problem in gas, or the gcc driver not passing appropriate
options to gas. We need a standalone test case, and please indicate exactly
what versions of gcc and binutils you're using and how they were configured and
built.

[Bug target/80786] m68k: internal compiler error: in change_address_1

[mikpelinux at gmail dot com via Gcc-bugs]

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

Mikael Pettersson  changed:

   What|Removed |Added

 CC||mikpelinux at gmail dot com

--- Comment #4 from Mikael Pettersson  ---
Reduced test case:

> cat /tmp/pr80786.c
extern long G[];

void dir_op(short op, short *dirs)
{
if (!op)
*dirs = G[1];
}
> gcc/xgcc -Bgcc -O2 -mpcrel -S /tmp/pr80786.c
during RTL pass: final
/tmp/pr80786.c: In function 'dir_op':
/tmp/pr80786.c:7:1: internal compiler error: in change_address_1, at
emit-rtl.cc:2299
7 | }
  | ^
0x40dc15 change_address_1
/mnt/scratch/other/mikpe-gcc.git/gcc/emit-rtl.cc:2299
0x668fc9 adjust_address_1(rtx_def*, machine_mode, poly_int<1u, long>, int, int,
int, poly_int<1u, long>)
/mnt/scratch/other/mikpe-gcc.git/gcc/emit-rtl.cc:2433
0x10c2ea2 output_80
/mnt/scratch/other/mikpe-gcc.git/gcc/config/m68k/m68k.md:1678
...

This is gcc-14 from 2023-12-30, and output_80 is m68k.md's truncsihi2 insn.

The source operand is

(mem:SI (const:SI (plus:SI (symbol_ref:SI ("G") [flags 0x40] )
(const_int 4 [0x4]))) [1 G[1]+0 S4 A16])

which truncsihi2 wants to adjust by adding 2 to the offset, but

(const:SI (plus:SI (symbol_ref:SI ("G") [flags 0x40] )
(const_int 6 [0x6])))

is rejected by m68k_legitimate_constant_address_p, causing
m68k_decompose_address to fail, and the assert in change_address_1 to fire.

Disabling this insn for TARGET_PCREL seems to work, but I don't know what
negative side-effects that might have.

gcc-4.9 and older were ok, gcc-5 and above ICE, starting with

aea3d681ec784b1a44ee3b37b0df2b71bdfadfc3 is the first new commit
commit aea3d681ec784b1a44ee3b37b0df2b71bdfadfc3
Author: DJ Delorie 
Date:   Fri Aug 29 19:19:42 2014 -0400

expr.c (convert_move): If the target has an explicit converter, use it.

[Bug target/108640] ICE compiling busybox for m68k in change_address_1, at emit-rtl.cc:2283

[mikpelinux at gmail dot com via Gcc-bugs]

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

--- Comment #6 from Mikael Pettersson  ---
Created attachment 56965
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56965=edit
Preliminary patch, only tested on the test case so far.

[Bug target/108640] ICE compiling busybox for m68k in change_address_1, at emit-rtl.cc:2283

[mikpelinux at gmail dot com via Gcc-bugs]

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

Mikael Pettersson  changed:

   What|Removed |Added

 CC||mikpelinux at gmail dot com

--- Comment #5 from Mikael Pettersson  ---
Further reduced test case:

> cat pr108640v2.i 
int x;
void iorsi3(void) { x |= (1 << 16); }
> gcc/xgcc -Bgcc -O1 -S pr108640v2.i
during RTL pass: final
../pr108640v2.i: In function 'iorsi3':
../pr108640v2.i:2:38: internal compiler error: in change_address_1, at
emit-rtl.cc:2299
2 | void iorsi3(void) { x |=  (1 << 16); }
  |  ^
0x40dc15 change_address_1
/mnt/scratch/other/mikpe-gcc.git/gcc/emit-rtl.cc:2299
0x668f79 adjust_address_1(rtx_def*, machine_mode, poly_int<1u, long>, int, int,
int, poly_int<1u, long>)
/mnt/scratch/other/mikpe-gcc.git/gcc/emit-rtl.cc:2433
0xd3ae93 output_iorsi3(rtx_def**)
/mnt/scratch/other/mikpe-gcc.git/gcc/config/m68k/m68k.cc:5513
...

In output_iorsi3() the m68k backend wants to change "x |= (1 << 16)" to
"*(((char *) ) + 1) |= 1". It calls adjust_address() to offset x by 1, but it
keeps the mode as SImode (4-byte). This address expr reaches
m68k_legitimate_constant_address_p(). On the uclinux target
M68K_OFFSETS_MUST_BE_WITHIN_SECTIONS_P is 1 so it calls
offset_within_block_p(x, 4) which fails because that is out of bounds, causing
the assert in change_address_1() to fail.

The other m68k targets don't define M68K_OFFSETS_MUST_BE_WITHIN_SECTIONS_P so
this works there.

The bug is that the adjust_address() call should have specified QImode as mode
since the resulting address is to be used in a 1-byte RMW operation. It gets it
right in the nearby code which rewrites to a HImode (2-byte) RMW.

output_andsi3() and output_xorsi3() have the exact same bug.

I have a patch.

[Bug target/113086] m68k: ICE at emit-rtl.cc:2287 with -fzero-call-used-regs=all -fPIE compiling openssh 9.6p1

[mikpelinux at gmail dot com via Gcc-bugs]

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

Mikael Pettersson  changed:

   What|Removed |Added

 CC||mikpelinux at gmail dot com

--- Comment #1 from Mikael Pettersson  ---
Bisected to the same rev. as PR110934, and fixed by the same proposed patch.
Please mark it as a duplicate of PR110934.

[Bug target/110934] m68k: ICE with -fzero-call-used-regs=all compiling openssh 9.3p2

[mikpelinux at gmail dot com via Gcc-bugs]

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

--- Comment #9 from Mikael Pettersson  ---
Created attachment 56961
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56961=edit
proposed fix, only tested on the given test case so far

[Bug target/110934] m68k: ICE with -fzero-call-used-regs=all compiling openssh 9.3p2

[mikpelinux at gmail dot com via Gcc-bugs]

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

--- Comment #8 from Mikael Pettersson  ---
The generic code synthesizes a move from CONST0_RTX (XFmode) to an XFmode FP
reg, and that causes the ice. Forcing the mode of both to SFmode or DFmode
avoids the ice and generates sane-looking code. The XFmode comes from the
generic code's use of regno_reg_rtx[regno] (in zcur_select_mode_rtx).

I'm not sure if overriding TARGET_ZERO_CALL_USED_REGS on m68k is the right
thing to do, or if it only masks a deeper problem within the backend.

[Bug target/110934] m68k: ICE with -fzero-call-used-regs=all compiling openssh 9.3p2

[mikpelinux at gmail dot com via Gcc-bugs]

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

--- Comment #7 from Mikael Pettersson  ---
The issue appears to be the clearing of FP regs. If I add an m68k-specific
version of TARGET_ZERO_CALL_USED_REGS which handles integer (address and data)
regs but skips FP regs, then the test case compiles fine.

[Bug target/110934] m68k: ICE with -fzero-call-used-regs=all compiling openssh 9.3p2

[mikpelinux at gmail dot com via Gcc-bugs]

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

--- Comment #6 from Mikael Pettersson  ---
Affects gcc-11 and newer, gcc-10 and older are ok. Started with:

d10f3e900b0377b4760a090b0f90371bcef01686 is the first new commit
commit d10f3e900b0377b4760a090b0f90371bcef01686
Author: qing zhao 
Date:   Fri Oct 30 20:41:38 2020 +0100

Add -fzero-call-used-regs option and zero_call_used_regs function
attributes.

[Bug tree-optimization/113049] Compiles to strlen even with -fno-builtin-strlen -fno-optimize-strlen

[mikpelinux at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Mikael Pettersson  ---
Does -fno-tree-loop-distribute-patterns work? That's been the go-to for
disabling similar loop-to-call transformations people have been objecting to.

[Bug target/112413] Wrong switch jump table offset

[mikpelinux at gmail dot com via Gcc-bugs]

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

--- Comment #7 from Mikael Pettersson  ---
Patch posted after bootstrap and regression testing on m68k-linux-gnu:
https://gcc.gnu.org/pipermail/gcc-patches/2023-December/640177.html

[Bug target/112712] Crash when compiling g++ -m68020-60 -O2

[mikpelinux at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Mikael Pettersson  ---
It appears the test case comes from https://github.com/dxx-rebirth/dxx-rebirth/
(a port of the old Descent game engine).

[Bug target/112712] Crash when compiling g++ -m68020-60 -O2

[mikpelinux at gmail dot com via Gcc-bugs]

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

Mikael Pettersson  changed:

   What|Removed |Added

 CC||mikpelinux at gmail dot com

--- Comment #1 from Mikael Pettersson  ---
I can reproduce with a gcc-13.2 cross to m68k-elf w/ c++:

during RTL pass: reload
similar/main/multi.cpp: In function 'void d1x::multi_object_to_object_rw(const
object&, object_rw*)':
similar/main/multi.cpp:6167:1: internal compiler error: in push_reload, at
reload.cc:1124
0x422a9d push_reload(rtx_def*, rtx_def*, rtx_def**, rtx_def**, reg_class,
machine_mode, machine_mode, int, int, int, reload_type)
/mnt/scratch/cross/downloads/gcc-mirror-gcc.git/gcc/reload.cc:1124
0xabcda1 find_reloads(rtx_insn*, int, int, int, short*)
/mnt/scratch/cross/downloads/gcc-mirror-gcc.git/gcc/reload.cc:4049
0xaca6ea calculate_needs_all_insns
/mnt/scratch/cross/downloads/gcc-mirror-gcc.git/gcc/reload1.cc:1469
0xaca6ea reload(rtx_insn*, int)
/mnt/scratch/cross/downloads/gcc-mirror-gcc.git/gcc/reload1.cc:983
0x96f784 do_reload
/mnt/scratch/cross/downloads/gcc-mirror-gcc.git/gcc/ira.cc:5975
0x96f784 execute
/mnt/scratch/cross/downloads/gcc-mirror-gcc.git/gcc/ira.cc:6149

The given test case doesn't compile with older g++ versions so I can't bisect.

[Bug target/112443] [12/13/14 Regression] Misoptimization of _mm256_blendv_epi8 intrinsic on avx512bw+avx512vl

[mikpelinux at gmail dot com via Gcc-bugs]

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

--- Comment #8 from Mikael Pettersson  ---
Can this be closed now?

[Bug preprocessor/112701] wrong type inference for ternary operator with `0/0u` in preprocessing context

[mikpelinux at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Mikael Pettersson  ---
gcc-2.95.3 generates neither, gcc-3.0.4 and up generate the bar: .long 0 (or
.zero 4) one.

[Bug c/83324] [feature request] Pragma or special syntax for guaranteed tail calls

[mikpelinux at gmail dot com via Gcc-bugs]

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

--- Comment #5 from Mikael Pettersson  ---
To get guaranteed tail-calls to work you need to adjust the calling convention
for the caller as well as the callee. Things are trivial as long as parameters
always fit in registers. With parameters on the stack you need, in general, to
shift the responsibility for their deallocation from caller to callee, and this
results in a non-standard calling convention.

[Bug target/112413] Wrong switch jump table offset

[mikpelinux at gmail dot com via Gcc-bugs]

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

--- Comment #5 from Mikael Pettersson  ---
Created attachment 56561
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56561=edit
proposed fix, only compile-tested for now

[Bug target/112413] Wrong switch jump table offset

[mikpelinux at gmail dot com via Gcc-bugs]

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

Mikael Pettersson  changed:

   What|Removed |Added

 CC||mikpelinux at gmail dot com

--- Comment #4 from Mikael Pettersson  ---
Does the `.balignw` filler disappear if you drop `-malign-int`?

[Bug middle-end/111151] [12/13/14 Regression] Wrong code at -O0 on x86_64-pc-linux-gnu

[mikpelinux at gmail dot com via Gcc-bugs]

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

Mikael Pettersson  changed:

   What|Removed |Added

 CC||mikpelinux at gmail dot com

--- Comment #2 from Mikael Pettersson  ---
On x86_64-linux-gnu I can reproduce this all the way back to gcc-3.2.3 with
both -m64 and -m32. gcc-2.95.3 compiling for i686-linux-gnu gets it right.

[Bug tree-optimization/111015] [11/12/13/14 Regression] __int128 bitfields optimized incorrectly to the 64 bit operations

[mikpelinux at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Mikael Pettersson  ---
Reverting the pass_store_merging::process_store hunk makes this test case work
again:

diff --git a/gcc/gimple-ssa-store-merging.cc b/gcc/gimple-ssa-store-merging.cc
index 0d19b98ed73..c4bf8eec64e 100644
--- a/gcc/gimple-ssa-store-merging.cc
+++ b/gcc/gimple-ssa-store-merging.cc
@@ -5299,7 +5299,7 @@ pass_store_merging::process_store (gimple *stmt)
  && bitsize.is_constant (_bitsize)
  && ((const_bitsize % BITS_PER_UNIT) != 0
  || !multiple_p (bitpos, BITS_PER_UNIT))
- && const_bitsize <= MAX_FIXED_MODE_SIZE)
+ && const_bitsize <= 64)
{
  /* Bypass a conversion to the bit-field type.  */
  if (!bit_not_p

[Bug tree-optimization/111015] [11/12/13/14 Regression] __int128 bitfields optimized incorrectly to the 64 bit operations

[mikpelinux at gmail dot com via Gcc-bugs]

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

Mikael Pettersson  changed:

   What|Removed |Added

 CC||mikpelinux at gmail dot com

--- Comment #3 from Mikael Pettersson  ---
10.5.0 is good, 11.4.0 and above are affected, started with (or was exposed
by):

commit ed01d707f8594827de95304371d5b62752410842
Author: Eric Botcazou 
Date:   Mon May 25 22:13:11 2020 +0200

Fix internal error on store to FP component at -O2

This is about a GIMPLE verification failure at -O2 or above because
the GIMPLE store merging pass generates a NOP_EXPR between a FP type
and an integral type.  This happens when the bit-field insertion path
is taken for a FP field, which can happen in Ada for bit-packed record
types.

It is fixed by generating an intermediate VIEW_CONVERT_EXPR.  The patch
also tames a little the bit-field insertion path because, for bit-packed
record  types in Ada, you can end up with large bit-field regions, which
results in a lot of mask-and-shifts instructions.

gcc/ChangeLog
* gimple-ssa-store-merging.c
(merged_store_group::can_be_merged_into):
Only turn MEM_REFs into bit-field stores for small bit-field
regions
(imm_store_chain_info::output_merged_store): Be prepared for
sources
with non-integral type in the bit-field insertion case.
(pass_store_merging::process_store): Use MAX_BITSIZE_MODE_ANY_INT
as
the largest size for the bit-field case.

gcc/testsuite/ChangeLog
* gnat.dg/opt84.adb: New test.

 gcc/ChangeLog   |  9 +
 gcc/gimple-ssa-store-merging.c  | 20 ---
 gcc/testsuite/ChangeLog |  4 +++
 gcc/testsuite/gnat.dg/opt84.adb | 74 +
 4 files changed, 103 insertions(+), 4 deletions(-)
 create mode 100644 gcc/testsuite/gnat.dg/opt84.adb

[Bug target/110934] m68k: ICE with -fzero-call-used-regs=all compiling openssh 9.3p2

[mikpelinux at gmail dot com via Gcc-bugs]

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

Mikael Pettersson  changed:

   What|Removed |Added

 CC||mikpelinux at gmail dot com

--- Comment #4 from Mikael Pettersson  ---
I can reproduce with m68k-unknown-linux-gnu-gcc -Os -fzero-call-used-regs=all
-fPIC.

[Bug middle-end/110702] [12/13/14 Regression] Wrong code at -O1 on x86_64-linux-gnu (regression since GCC-12.2)

[mikpelinux at gmail dot com via Gcc-bugs]

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

Mikael Pettersson  changed:

   What|Removed |Added

 CC||mikpelinux at gmail dot com

--- Comment #2 from Mikael Pettersson  ---
Masked at -Os/O2/O3. The regression at -O1 started with

374cee99d01fceb89d0929da8b38051e6c9768f0 is the first new commit
commit 374cee99d01fceb89d0929da8b38051e6c9768f0
Author: Richard Biener 
Date:   Tue May 17 09:45:02 2022 +0200

tree-optimization/105618 - restore load sinking

[Bug target/59178] Stack corruption on register save/restore when using frame pointer on pdp-11

[mikpelinux at gmail dot com via Gcc-bugs]

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

Mikael Pettersson  changed:

   What|Removed |Added

 CC||mikpelinux at gmail dot com

--- Comment #2 from Mikael Pettersson  ---
This was fixed for gcc-9.1.0, see PR59172.

[Bug target/59172] pdp11-aout makes a wrong code at the epilogue

[mikpelinux at gmail dot com via Gcc-bugs]

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

Mikael Pettersson  changed:

   What|Removed |Added

 CC||mikpelinux at gmail dot com

--- Comment #3 from Mikael Pettersson  ---
For completeness, this was fixed for gcc-9.1.0 by

commit 442fcea74d0c7797fc083fa7e5543268c0ff54a6
Author: Paul Koning 
Date:   Thu Nov 8 13:56:58 2018 -0500

The commit message mentions PR c/87795 but that seems like an error; the
mailing-list message just mentions it being a collection of fixes.

[Bug ada/110668] gcc/ada/gcc-interface/Make-lang.in:1012: ada/b_gnat1.adb] Error 5

[mikpelinux at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Mikael Pettersson  ---
https://gcc.gnu.org/install/prerequisites.html, GNAT section, 4th paragraph.

[Bug ada/110668] gcc/ada/gcc-interface/Make-lang.in:1012: ada/b_gnat1.adb] Error 5

[mikpelinux at gmail dot com via Gcc-bugs]

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

Mikael Pettersson  changed:

   What|Removed |Added

 CC||mikpelinux at gmail dot com

--- Comment #1 from Mikael Pettersson  ---
Ada only supports being built by the same or older releases, while you're
trying to bootstrap gcc-10.5 using gcc-13.1. That won't work in general. (For
Canadian crosses it must be the exact same version.)

[Bug middle-end/87944] Wrong code with LRA pushing stack local variable

[mikpelinux at gmail dot com via Gcc-bugs]

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

Mikael Pettersson  changed:

   What|Removed |Added

 CC||mikpelinux at gmail dot com

--- Comment #5 from Mikael Pettersson  ---
Appears to have been fixed for gcc-14.0 by

30038a207c10a2783fa2695b62c7c8458ef05e73 is the first new commit
commit 30038a207c10a2783fa2695b62c7c8458ef05e73
Author: Vladimir N. Makarov 
Date:   Tue May 30 15:54:28 2023 -0400

LRA: Update insn sp offset if its input reload changes SP

which mentions a problem switching the h8300 to lra, but there's no PR
reference in either the commit message or the mailing-list post.

[Bug libgcc/109670] [13/14 regression] Exception handling broken for 32-bit Windows

[mikpelinux at gmail dot com via Gcc-bugs]

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

Mikael Pettersson  changed:

   What|Removed |Added

 CC||mikpelinux at gmail dot com

--- Comment #18 from Mikael Pettersson  ---
Since the fix has been backported to gcc-13 branch, can this be closed now?

[Bug target/105525] some targets don't define __INTPTR_TYPE__ breaking libgcov-driver.c

[mikpelinux at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Mikael Pettersson  ---
Patch submitted:
https://gcc.gnu.org/pipermail/gcc-patches/2023-April/617071.html

[Bug target/105525] some targets don't define __INTPTR_TYPE__ breaking libgcov-driver.c

[mikpelinux at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Mikael Pettersson  ---
The issue issue remains in gcc-13.1.0 but is no longer limited to gcov, i.e. a
vax build with --disable-gcov using gcc-13.1.0 now fails with

In file included from
/mnt/scratch/cross/sources/gcc-13.1.0/libgcc/unwind-dw2-fde-dip.c:579:
/mnt/scratch/cross/sources/gcc-13.1.0/libgcc/unwind-dw2-fde.c:45:9: error:
unknown type name '__UINTPTR_TYPE__'
   45 | typedef __UINTPTR_TYPE__ uintptr_type;
  | ^~~~
/mnt/scratch/cross/sources/gcc-13.1.0/libgcc/unwind-dw2-fde.c: In function
'classify_object_over_fdes':
/mnt/scratch/cross/sources/gcc-13.1.0/libgcc/unwind-dw2-fde.c:777:28: warning:
comparison of integer expressions of different signedness: '_Unwind_Ptr' {aka
'unsigned int'} and 'uintptr_type' {aka 'int'} [-Wsign-compare]
  777 |   if (pc_begin < range[0])
  |^
/mnt/scratch/cross/sources/gcc-13.1.0/libgcc/unwind-dw2-fde.c:779:26: warning:
comparison of integer expressions of different signedness: '_Unwind_Ptr' {aka
'unsigned int'} and 'uintptr_type' {aka 'int'} [-Wsign-compare]
  779 |   if (pc_end > range[1])
  |  ^
make[2]: *** [/mnt/scratch/cross/sources/gcc-13.1.0/libgcc/static-object.mk:17:
unwind-dw2-fde-dip.o] Error 1
make[2]: Leaving directory '/tmp/objdir-gcc-vax/vax-unknown-linux/libgcc'
make[1]: *** [Makefile:12865: all-target-libgcc] Error 2
make[1]: Leaving directory '/tmp/objdir-gcc-vax'
make: *** [Makefile:1020: all] Error 2

lm32 is similar.

I will submit a patch shortly.

[Bug target/109402] v850: non-v850e version of __muldi3() in /libgcc/config/v850/lib1funcs.S operates sp in reversed direction

[mikpelinux at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Mikael Pettersson  ---
Please send patches to gcc-patches for review.

[Bug target/109140] ICE (during RTL pass: internal compiler error: in extract_insn, at recog.cc:2791) when building qemu on sparc64-unknown-linux-gnu with -march=niagara4

[mikpelinux at gmail dot com via Gcc-bugs]

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

--- Comment #10 from Mikael Pettersson  ---
A bisect between 4.6.4 (good) and 4.7.4 (bad) found:

1f9ed162eb30f1b40b65d164b3a40ac78e1f006e is the first bad commit
commit 1f9ed162eb30f1b40b65d164b3a40ac78e1f006e
Author: David S. Miller 
Date:   Tue Nov 1 08:42:57 2011 +

Add vcond/vcondu patterns to sparc backend.

If I disable the "vconduv8qiv8qi" expander this test case doesn't cause an ICE.

[Bug target/109140] ICE (during RTL pass: internal compiler error: in extract_insn, at recog.cc:2791) when building qemu on sparc64-unknown-linux-gnu with -march=niagara4

[mikpelinux at gmail dot com via Gcc-bugs]

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

--- Comment #9 from Mikael Pettersson  ---
I can reproduce all the way down to gcc-4.7.4, gcc-4.6.4 doesn't support
-mcpu=niagara4.

[Bug target/109140] ICE (during RTL pass: internal compiler error: in extract_insn, at recog.cc:2791) when building qemu on sparc64-unknown-linux-gnu with -march=niagara4

[mikpelinux at gmail dot com via Gcc-bugs]

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

--- Comment #7 from Mikael Pettersson  ---
With -O2 -ftree-vectorize -mcpu=niagara4 a bisect between 9.5.0 (good) and
10.4.0 (bad) found

6271dd984d7f920d4fb17ad37af6a1f8e6b796dc is the first bad commit
commit 6271dd984d7f920d4fb17ad37af6a1f8e6b796dc
Author: Wilco Dijkstra 
Date:   Wed Nov 20 16:29:23 2019 +

PR85678: Change default to -fno-common

And sure enough, with -O2 -ftree-vectorize -fno-common -mcpu=niagara4 gcc-9.5.0
also ICEs.

[Bug target/109140] ICE (during RTL pass: internal compiler error: in extract_insn, at recog.cc:2791) when building qemu on sparc64-unknown-linux-gnu with -march=niagara4

[mikpelinux at gmail dot com via Gcc-bugs]

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

--- Comment #6 from Mikael Pettersson  ---
With -O2 -ftree-vectorize -mcpu=niagara4 the ICE reproduces with gcc-10.4.0 but
not with gcc-9.5.0.

[Bug target/109140] ICE (during RTL pass: internal compiler error: in extract_insn, at recog.cc:2791) when building qemu on sparc64-unknown-linux-gnu with -march=niagara4

[mikpelinux at gmail dot com via Gcc-bugs]

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

Mikael Pettersson  changed:

   What|Removed |Added

 CC||mikpelinux at gmail dot com

--- Comment #5 from Mikael Pettersson  ---
I can reproduce with a cross to sparc64-linux-gnu hosted on x86_64-linux-gnu.

git bisect between 11.3.0 (good) and 12.2.0 (bad) identified:

2b8453c401b699ed93c085d0413ab4b5030bcdb8 is the first bad commit
commit 2b8453c401b699ed93c085d0413ab4b5030bcdb8
Author: liuhongt 
Date:   Mon Sep 6 13:48:49 2021 +0800

Enable auto-vectorization at O2 with very-cheap cost model.

which tells me the issue is pre-existing.

[Bug middle-end/108657] [13 Regression] csmith: possible wrong checksum with -O3 and -ftrivial-auto-var-init=zero

[mikpelinux at gmail dot com via Gcc-bugs]

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

--- Comment #11 from Mikael Pettersson  ---
Bisected on x86_64-linux-gnu:

dc477ffb4aba21e9cf47de22a4df6f2b23849505 is the first bad commit
commit dc477ffb4aba21e9cf47de22a4df6f2b23849505
Author: Richard Biener 
Date:   Thu Jul 21 10:13:46 2022 +0200

tree-optimization/106378 - DSE of LEN_STORE and MASK_STORE

The following enhances DSE to handle LEN_STORE (optimally) and
MASK_STORE (conservatively).

PR tree-optimization/106378
* tree-ssa-dse.cc (initialize_ao_ref_for_dse): Handle
LEN_STORE, add mode to initialize a may-def and handle
MASK_STORE that way.
(dse_optimize_stmt): Query may-defs.  Handle internal
functions LEN_STORE and MASK_STORE similar to how
we handle memory builtins but without byte tracking.

[Bug target/108640] ICE compiling busybox for m68k in change_address_1, at emit-rtl.cc:2283

[mikpelinux at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Mikael Pettersson  ---
Happens with 11.3.0, 10.4.0, and 9.5.0 too, so shouldn't be related to the CC0
conversion.

[Bug target/108640] ICE compiling busybox for m68k in change_address_1, at emit-rtl.cc:2283

[mikpelinux at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Mikael Pettersson  ---
I can reproduce. Doesn't happen with the m68k-linux-gnu target though.

> cross-m68k-uclinux/bin/m68k-unknown-uclinux-uclibc-gcc -Os -c /tmp/ls.i 
during RTL pass: final
coreutils/ls.c: In function 'ls_main':
coreutils/ls.c:1265:1: internal compiler error: in change_address_1, at
emit-rtl.cc:2283
0x40c57b change_address_1
/mnt/scratch/cross/sources/gcc-12.2.0/gcc/emit-rtl.cc:2283
0x64e80d adjust_address_1(rtx_def*, machine_mode, poly_int<1u, long>, int, int,
int, poly_int<1u, long>)
/mnt/scratch/cross/sources/gcc-12.2.0/gcc/emit-rtl.cc:2417
0xc6da2f output_iorsi3(rtx_def**)
/mnt/scratch/cross/sources/gcc-12.2.0/gcc/config/m68k/m68k.cc:5498
0x691b05 final_scan_insn_1
/mnt/scratch/cross/sources/gcc-12.2.0/gcc/final.cc:2827
0x692108 final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
/mnt/scratch/cross/sources/gcc-12.2.0/gcc/final.cc:2940
0x692395 final_1
/mnt/scratch/cross/sources/gcc-12.2.0/gcc/final.cc:1997
0x692b92 rest_of_handle_final
/mnt/scratch/cross/sources/gcc-12.2.0/gcc/final.cc:4285
0x692b92 execute
/mnt/scratch/cross/sources/gcc-12.2.0/gcc/final.cc:4363
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug target/101697] [11/12 regression] ICE compiling uClibc-ng for h8300-linux

[mikpelinux at gmail dot com via Gcc-bugs]

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

--- Comment #9 from Mikael Pettersson  ---
I can confirm that building the latest uClibc-ng for h8300 now succeeds with
gcc master @ 4374c424a60777a7658050f0aeb1dcc9af915647.

[Bug middle-end/106892] [11/12 Regression] Wrong code at -O3 on x86_64-linux-gnu since r11-963-g80d6f89e78fc3b77

[mikpelinux at gmail dot com via Gcc-bugs]

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

Mikael Pettersson  changed:

   What|Removed |Added

 CC||mikpelinux at gmail dot com

--- Comment #12 from Mikael Pettersson  ---
(In reply to Richard Biener from comment #11)
> PR tree-optimization/106722

Shouldn't that be 106892?

> * tree-predcom.cc (ref_at_iteration): Do not associate the
> constant part of the offset into the MEM_REF offset
> operand, across a non-zero offset.
> 
> * gcc.dg/torture/pr106892.c: New testcase.

[Bug target/93242] [MIPS] patchable-function-entry broken

[mikpelinux at gmail dot com via Gcc-bugs]

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

--- Comment #10 from Mikael Pettersson  ---
(In reply to Ilya Leoshkevich from comment #9)
> Would it be possible to backport this to gcc-9?
...
> There is a workaround for now, but it would be good to have this fixed in
> all the maintained gccs (gcc-8 is no longer maintained as far as I can see,
> so this leaves only gcc-9).

GCC-9 went EOL with the gcc-9.5.0 release on May 27 this year.

[Bug target/106609] [12/13 Regression] sh3eb-elf cross compiler is being miscompiled since r12-1525-g3155d51bfd1de8b6c4645

[mikpelinux at gmail dot com via Gcc-bugs]

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

--- Comment #12 from Mikael Pettersson  ---
I tried compiling the gcc-13 cross compiler using the broken gcc-12 host
compiler and -mtune-ctrl=^use_bt but that didn't help.

I then tried rebuilding the broken gcc-12 host compiler with the new splitters
disabled, one by one. Disabling the "*bt_setcqi" one did unbreak the
gcc-13 cross-compiler:

diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
index 48532eb7ddf..0780ba992f3 100644
--- a/gcc/config/i386/i386.md
+++ b/gcc/config/i386/i386.md
@@ -12830,7 +12830,7 @@
  (const_int 1)
  (zero_extend:SI (match_operand:QI 2 "register_operand"
(clobber (reg:CC FLAGS_REG))]
-  "TARGET_USE_BT && ix86_pre_reload_split ()"
+  "0 && TARGET_USE_BT && ix86_pre_reload_split ()"
   "#"
   "&& 1"
   [(set (reg:CCC FLAGS_REG)

[Bug middle-end/106609] sh3eb-elf cross compiler is being miscompiled

[mikpelinux at gmail dot com via Gcc-bugs]

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

--- Comment #9 from Mikael Pettersson  ---
# first bad commit: [3155d51bfd1de8b6c4645dcb2292248a8d7cc3c9] [PATCH] PR
rtl-optimization/46235: Improved use of bt for bit tests on x86_64.

Starting with this commit, the host compiler (on x86_64-linux) miscompiles the
gcc-13 based cross-compiler to sh3eb-elf.

[Bug target/106609] [SH] miscompilation due to incorrect elimination of comparisons to 0

[mikpelinux at gmail dot com via Gcc-bugs]

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

Mikael Pettersson  changed:

   What|Removed |Added

 CC||mikpelinux at gmail dot com

--- Comment #7 from Mikael Pettersson  ---
I can reproduce with gcc-12 as host compiler, but not with gcc-11 as host
compiler.

I'm using the example in comment #4, and a recent HEAD of master (bac07a1da24)
configured with --target=sh3eb-elf.

With "GCC: (GNU) 11.3.1 20220812" as host compiler, the cross-compiler compiles
(-O1) the example to:

_f:
cmp/pz  r4
bf.s.L3
add r4,r5
tst r5,r5
bf  .L4
rts
mov r4,r0
.align 1
.L3:
rts
mov #1,r0
.align 1
.L4:
rts
mov #3,r0

which looks ok to me (not knowing SH asm...).

With "GCC: (GNU) 12.1.1 20220812" (the 12.2.0 RC) as host compiler, the
cross-compiler instead compiles the example to:

_f:
cmp/pz  r4
bf  .L3
bf  .L4
rts
mov r4,r0
.align 1
.L3:
rts
mov #1,r0
.align 1
.L4:
rts
mov #3,r0

which looks broken.

[Bug tree-optimization/106064] Wrong code comparing two global zero-sized arrays

[mikpelinux at gmail dot com via Gcc-bugs]

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

Mikael Pettersson  changed:

   What|Removed |Added

 CC||mikpelinux at gmail dot com

--- Comment #2 from Mikael Pettersson  ---
Seems target-dependent. I can't reproduce on x86_64-linux-gnu or
sparc64-linux-gnu: both compile f() to return 1 and g() to perform a runtime
computation. But ppc64-linux-gnu and armv7l-linux-gnueabi behave as your
aarch64 example: f() returns 1 and g() returns 0 (unconditionally, no runtime
computations).

[Bug tree-optimization/106025] Incorrect optimization at -O2 leads to infinite test execution time

[mikpelinux at gmail dot com via Gcc-bugs]

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

Mikael Pettersson  changed:

   What|Removed |Added

 CC||mikpelinux at gmail dot com

--- Comment #1 from Mikael Pettersson  ---
I can reproduce with gcc version 13.0.0 20220619 at -O2 on x86_64-pc-linux-gnu,
but not with gcc version 12.1.1 20220618 or gcc-11. I tried
-fsanitize=undefined to see if the code had any UB, but that was silent _and_
masked the problem.

[Bug ada/105872] GNAT Bug Box compiling gcc/ada/spark_xrefs.adb

[mikpelinux at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Mikael Pettersson  ---
Also see PR105874.

[Bug ada/105872] GNAT Bug Box compiling gcc/ada/spark_xrefs.adb

[mikpelinux at gmail dot com via Gcc-bugs]

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

Mikael Pettersson  changed:

   What|Removed |Added

 CC||mikpelinux at gmail dot com

--- Comment #2 from Mikael Pettersson  ---
I think this might be what's discussed in
https://gcc.gnu.org/pipermail/gcc-patches/2022-June/596202.html. Try reverting
ed6fd2aed58f2cca99f15331bf68999c0e6df370 for now.

[Bug libstdc++/105681] libstdc++-v3 fails to build on msp430

[mikpelinux at gmail dot com via Gcc-bugs]

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

Mikael Pettersson  changed:

   What|Removed |Added

 CC||mikpelinux at gmail dot com

--- Comment #3 from Mikael Pettersson  ---
I can reproduce in a cross to --target=msp430-unknown-elf
--enable-languages=c,c++ with binutils-2.38 and newlib-4.2.0.20211231.
gcc-11.3.0 builds fine, but gcc-12.1.0 build fails with

In file included from
/mnt/scratch/cross/sources/gcc-12.1.0/libstdc++-v3/include/precompiled/extc++.h:61:
/mnt/scratch/cross/objdir-gcc/msp430-unknown-elf/libstdc++-v3/include/ext/random:355:69:
error: narrowing conversion of '86243' from 'long int' to 'unsigned int'
[-Wnarrowing]
  355 | 0xU, 0xe9528d85U>
  | ^
(several more)

and

In file included from
/mnt/scratch/cross/objdir-gcc/msp430-unknown-elf/libstdc++-v3/include/ext/pb_ds/hash_policy.hpp:475,
 from
/mnt/scratch/cross/objdir-gcc/msp430-unknown-elf/libstdc++-v3/include/ext/pb_ds/detail/standard_policies.hpp:45,
 from
/mnt/scratch/cross/objdir-gcc/msp430-unknown-elf/libstdc++-v3/include/ext/pb_ds/assoc_container.hpp:47,
 from
/mnt/scratch/cross/sources/gcc-12.1.0/libstdc++-v3/include/precompiled/extc++.h:72:
/mnt/scratch/cross/objdir-gcc/msp430-unknown-elf/libstdc++-v3/include/ext/pb_ds/detail/resize_policy/hash_prime_size_policy_imp.hpp:73:32:
error: narrowing conversion of '116731' from 'long unsigned int' to
'std::size_t' {aka 'unsigned int'} [-Wnarrowing]
   73 |   /* 14*/  116731ul,
  |^~~~
(many more)

[Bug target/105525] New: some targets don't define __INTPTR_TYPE__ breaking libgcov-driver.c

[mikpelinux at gmail dot com via Gcc-bugs]

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

Bug ID: 105525
   Summary: some targets don't define __INTPTR_TYPE__ breaking
libgcov-driver.c
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mikpelinux at gmail dot com
  Target Milestone: ---

Attempting to build a gcc-12.1.0 based cross-compiler to lm32-uclinux-uclibc or
vax-unknown-linux fails with

/mnt/scratch/cross/sources/gcc-12.1.0/libgcc/libgcov-driver.c: In function
'write_topn_counters':
/mnt/scratch/cross/sources/gcc-12.1.0/libgcc/libgcov-driver.c:457:56: error:
'__INTPTR_TYPE__' undeclared (first use in this function); did you mean
'INTPTR_TYPE'?
  457 |   for (struct gcov_kvp *node = (struct gcov_kvp
*)(__INTPTR_TYPE__)start;
  |^~~
  |INTPTR_TYPE
/mnt/scratch/cross/sources/gcc-12.1.0/libgcc/libgcov-driver.c:457:56: note:
each undeclared identifier is reported only once for each function it appears
in
/mnt/scratch/cross/sources/gcc-12.1.0/libgcc/libgcov-driver.c:457:72: error:
expected ',' or ';' before 'start'
  457 |   for (struct gcov_kvp *node = (struct gcov_kvp
*)(__INTPTR_TYPE__)start;
  |   
^
/mnt/scratch/cross/sources/gcc-12.1.0/libgcc/libgcov-driver.c:454:17: warning:
unused variable 'start' [-Wunused-variable]
  454 |   gcov_type start = ci_ptr->values[GCOV_TOPN_MEM_COUNTERS * i + 2];
  | ^
/mnt/scratch/cross/sources/gcc-12.1.0/libgcc/libgcov-driver.c:476:72: error:
expected ',' or ';' before 'start'
  476 |   for (struct gcov_kvp *node = (struct gcov_kvp
*)(__INTPTR_TYPE__)start;
  |   
^
/mnt/scratch/cross/sources/gcc-12.1.0/libgcc/libgcov-driver.c:473:17: warning:
unused variable 'start' [-Wunused-variable]
  473 |   gcov_type start = ci_ptr->values[GCOV_TOPN_MEM_COUNTERS * i + 2];
  | ^
make[2]: *** [Makefile:928: _gcov_info_to_gcda.o] Error 1
make[2]: Leaving directory
'/mnt/scratch/cross/objdir-vax-gcc/vax-unknown-linux/libgcc'
make[1]: *** [Makefile:12928: all-target-libgcc] Error 2
make[1]: Leaving directory '/mnt/scratch/cross/objdir-vax-gcc'
make: *** [Makefile:1012: all] Error 2

These builds work with gcc-11.3.0, so it's a regression. I haven't bisected but
I believe this started with:

2021-08-06  Sebastian Huber  

* libgcov-driver.c (#include ): Remove.
(write_topn_counters): Use __INTPTR_TYPE__ instead of intptr_t.

However, a deeper question is _why_ don't these two targets define
__INTPTR_TYPE__ when so many others do? I suspect that's the real bug here.

Workarounds: revert to gcc-11.3.0, or build gcc-12.1.0 with --disable-gcov.

[Bug target/103722] [12/13 Regression] ICE in extract_constrain_insn building glibc for SH4

[mikpelinux at gmail dot com via Gcc-bugs]

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

Mikael Pettersson  changed:

   What|Removed |Added

 CC||mikpelinux at gmail dot com

--- Comment #4 from Mikael Pettersson  ---
This is still happening, and prevents using gcc-12.1.0 to build glibc-2.35.

[Bug target/105292] [sparc64] ICE in expand_expr_real_2 on sparc64 when compiling with -mcpu=niagara4

[mikpelinux at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Mikael Pettersson  ---
Works with gcc-9.4, ICEs with gcc-10.3 and above. Git bisect identified

# first bad commit: [9b75f56d4b7951c60a6563964a65787b95bc] Apply maximum
nunits for BB SLP

as the cause of the ICEs, though it possibly only exposed a latent target
issue.

[Bug target/105292] [sparc64] ICE in expand_expr_real_2 on sparc64 when compiling with -mcpu=niagara4

[mikpelinux at gmail dot com via Gcc-bugs]

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

Mikael Pettersson  changed:

   What|Removed |Added

 CC||mikpelinux at gmail dot com

--- Comment #1 from Mikael Pettersson  ---
I can reproduce with a gcc-11.2.0 cross to sparc64-linux-gnu. ICEs with -mcpu
selecting ultrasparc3 or niagara[2347]. Doesn't ice if -mcpu select plain
ultrasparc or niagara. Also doesn't ICE if -O3 is reduced to -O2.

Still ICEs with gcc-12-20220417.

[Bug ipa/103083] [10/11/12 Regression] Wrong code due to ipa-cp's bits value propagation since r10-5538-gc7ac9a0c7e3916f1

[mikpelinux at gmail dot com via Gcc-bugs]

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

Mikael Pettersson  changed:

   What|Removed |Added

 CC||mikpelinux at gmail dot com

--- Comment #9 from Mikael Pettersson  ---
Can this be closed now? I cannot reproduce the abort at -O2 for the original
test case with current gcc-10/11 branch snapshots (but I can with snapshots
from March).

[Bug target/89040] [9 Regressiom] Wrong code with -mno-mmx

[mikpelinux at gmail dot com via Gcc-bugs]

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

Mikael Pettersson  changed:

   What|Removed |Added

 CC||mikpelinux at gmail dot com

--- Comment #5 from Mikael Pettersson  ---
According to my git bisect, this was fixed for gcc-10.1.0 by

d4410ec0ab4e3d2c834a811acf9e39af32e1d1d8 is the first new commit
commit d4410ec0ab4e3d2c834a811acf9e39af32e1d1d8
Author: H.J. Lu 
Date:   Wed May 15 15:31:18 2019 +

i386: Allow MMX vector expanders with TARGET_MMX_WITH_SSE

PR target/89021
...
From-SVN: r271251

but it's part of a long series of patches (see PR89021) and I doubt it's
backportable as-is.

[Bug middle-end/102133] [12 Regression] ICE in set_rtl building libgcc __muldc3 for 32-bit SPARC

[mikpelinux at gmail dot com via Gcc-bugs]

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

--- Comment #10 from Mikael Pettersson  ---
(In reply to Hongtao.liu from comment #2)
> But failed to configure for target mcore, i didn't find any reference in
> https://gcc.gnu.org/install/specific.html
> 
> --target=mcore results in
> *** Configuration mcore-unknown-none not supported

It's mcore-elf or mcore-unknown-elf .

[Bug target/101697] [11/12 regression] ICE compiling uClibc-ng for h8300-linux

[mikpelinux at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Mikael Pettersson  ---
As far as I can tell the problem is introduced by reload.

With a gcc-11.2.0 cross, getaddrinfo.i.290r.ira has

(insn 161 159 163 31 (set (reg/f:SI 185)
(reg/f:SI 7 sp)) "libc/inet/getaddrinfo.c":465:13 13 {*movsi}
 (nil))
(insn 163 161 164 31 (set (mem/f:SI (pre_dec:SI (reg/f:SI 7 sp)) [3  S4 A32])
(reg/f:SI 185)) "libc/inet/getaddrinfo.c":466:11 13 {*movsi}
 (expr_list:REG_ARGS_SIZE (const_int 4 [0x4])
(nil)))

these are adjacent.

Then getaddrinfo.i.291r.reload has

Reloads for insn # 161
Reload 0: reload_out (SI) = (reg/f:SI 185)
NO_REGS, RELOAD_FOR_OUTPUT (opnum = 0), optional
reload_out_reg: (reg/f:SI 185)

Reloads for insn # 163
Reload 0: reload_out (SI) = (mem/f:SI (pre_dec:SI (reg/f:SI 7 sp)) [3  S4 A32])
NO_REGS, RELOAD_FOR_OUTPUT (opnum = 0), optional
reload_out_reg: (mem/f:SI (pre_dec:SI (reg/f:SI 7 sp)) [3  S4 A32])
Reload 1: reload_in (SI) = (reg/f:SI 185)
GENERAL_REGS, RELOAD_FOR_INPUT (opnum = 1)
reload_in_reg: (reg/f:SI 185)
reload_reg_rtx: (reg/f:SI 7 sp)

and later

(insn 161 159 995 31 (set (mem/c:SI (plus:SI (reg/f:SI 6 r6)
(const_int -140 [0xff74])) [30 %sfp+-132 S4 A32])
(reg/f:SI 7 sp)) "libc/inet/getaddrinfo.c":465:13 13 {*movsi}
 (nil))
(insn 995 161 163 31 (set (reg/f:SI 7 sp)
(mem/c:SI (plus:SI (reg/f:SI 6 r6)
(const_int -140 [0xff74])) [30 %sfp+-132 S4 A32]))
"libc/inet/getaddrinfo.c":466:11 13 {*movsi}
 (expr_list:REG_ARGS_SIZE (const_int 0 [0])
(nil)))
(insn 163 995 164 31 (set (mem/f:SI (pre_dec:SI (reg/f:SI 7 sp)) [3  S4 A32])
(reg/f:SI 7 sp)) "libc/inet/getaddrinfo.c":466:11 13 {*movsi}
 (expr_list:REG_ARGS_SIZE (const_int 4 [0x4])
(nil)))

It's strange you can't reproduce. My current build is literally:

> mkdir objdir-binutils; cd objdir-binutils
> /tmp/binutils-2.37/configure --target=h8300-unknown-linux-uclibc 
> --prefix=/tmp/cross-h8300 --with-sysroot=/tmp/cross-h8300
> make -jN
> make install
> cd ..
> mkdir objdir-gcc; cd objdir-gcc
> PATH=/tmp/cross-h8300/bin:/usr/bin /tmp/gcc-11.2.0/configure 
> --target=h8300-unknown-linux-uclibc --prefix=/tmp/cross-h8300 
> --with-sysroot=/tmp/cross-h8300 --with-newlib --disable-libquadmath 
> --disable-libssp --disable-threads --disable-libatomic --disable-libgomp 
> --enable-languages=c --enable-checking=release
> PATH=/tmp/cross-h8300/bin:/usr/bin make -jN
> gcc/xgcc -Bgcc -fno-builtin -Os -S /tmp/getaddrinfo.i

[Bug target/101697] [11/12 regression] ICE compiling uClibc-ng for h8300-linux

[mikpelinux at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Mikael Pettersson  ---
The ICE in gcc-11 started with:
[f16897cb4b1468374d63b1a6b12d8b7be845874a] H8 cc0 conversion

It changed from "unrecognizable insn" to "could not split insn" in gcc-12 with:
[549d7f4310f6f8c2c64efcb6f3efcee99c9d9f4f] Fix split conditions in H8/300 port

[Bug target/101697] New: [11/12 regression] ICE compiling uClibc-ng for h8300-linux

[mikpelinux at gmail dot com via Gcc-bugs]

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

Bug ID: 101697
   Summary: [11/12 regression] ICE compiling uClibc-ng for
h8300-linux
   Product: gcc
   Version: 11.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mikpelinux at gmail dot com
  Target Milestone: ---

Created attachment 51226
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51226=edit
pre-processed source of uClibc's getaddrinfo.c

Attempting to build uClibc-ng-1.0.38 with a gcc-11.2.0 cross to
h8300-unknown-linux-uclibc fails with an ICE:

libc/inet/getaddrinfo.c: In function 'gaih_inet':
libc/inet/getaddrinfo.c:801:1: error: unrecognizable insn:
  801 | }
  | ^
(insn 1444 1443 164 31 (parallel [
(set (mem/f:SI (pre_dec:SI (reg/f:SI 7 sp)) [3  S4 A32])
(reg/f:SI 7 sp))
(clobber (reg:CC 12 cc))
]) "libc/inet/getaddrinfo.c":466:11 -1
 (expr_list:REG_ARGS_SIZE (const_int 4 [0x4])
(nil)))
during RTL pass: split2
libc/inet/getaddrinfo.c:801:1: internal compiler error: in extract_insn, at
recog.c:2770
0x41a6f0 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/mnt/scratch/cross/sources/gcc-11.2.0/gcc/rtl-error.c:108
0x41a70c _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/mnt/scratch/cross/sources/gcc-11.2.0/gcc/rtl-error.c:116
0x4199e8 extract_insn(rtx_insn*)
/mnt/scratch/cross/sources/gcc-11.2.0/gcc/recog.c:2770
0x8cf1c4 extract_insn_cached(rtx_insn*)
/mnt/scratch/cross/sources/gcc-11.2.0/gcc/recog.c:2659
0x67c782 cleanup_subreg_operands(rtx_insn*)
/mnt/scratch/cross/sources/gcc-11.2.0/gcc/final.c:3330
0x8cd42f split_insn
/mnt/scratch/cross/sources/gcc-11.2.0/gcc/recog.c:3399
0x8d2407 split_all_insns()
/mnt/scratch/cross/sources/gcc-11.2.0/gcc/recog.c:3467
0x8d2498 execute
/mnt/scratch/cross/sources/gcc-11.2.0/gcc/recog.c:4385

A gcc-12 cross also ICEs on the same location, but with a different message:

libc/inet/getaddrinfo.c: In function 'gaih_inet':
libc/inet/getaddrinfo.c:801:1: error: could not split insn
  801 | }
  | ^
(insn 163 1443 1444 (set (mem/f:SI (pre_dec:SI (reg/f:SI 7 sp)) [3  S4 A32])
(reg/f:SI 7 sp)) "libc/inet/getaddrinfo.c":466:11 19 {*movsi}
 (expr_list:REG_ARGS_SIZE (const_int 4 [0x4])
(nil)))
during RTL pass: final
libc/inet/getaddrinfo.c:801:1: internal compiler error: in final_scan_insn_1,
at final.c:2861
0x41abf2 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/mnt/scratch/cross/sources/gcc-12-20210725/gcc/rtl-error.c:108
0x40ded8 final_scan_insn_1
/mnt/scratch/cross/sources/gcc-12-20210725/gcc/final.c:2861
0x687d9b final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
/mnt/scratch/cross/sources/gcc-12-20210725/gcc/final.c:2940
0x688064 final_1
/mnt/scratch/cross/sources/gcc-12-20210725/gcc/final.c:1997
0x688842 rest_of_handle_final
/mnt/scratch/cross/sources/gcc-12-20210725/gcc/final.c:4285
0x688842 execute,
/mnt/scratch/cross/sources/gcc-12-20210725/gcc/final.c:4363

gcc-10.3.0 has no problems building uClibc-1.0.38 for the h8300.

Attaching the preprocessed getaddrinfo.i. Compile with -fno-builtin and -Os,
-O2, or -O3 to trigger the ICE. Removing -fno-builtin or reducing optimization
to -Og, -O1, or -O0 stops the ICE.

The cross-compilers were configured (yes there's some redundancies there):
--target=h8300-unknown-linux-uclibc --build=x86_64-pc-linux-gnu
--prefix=/mnt/scratch/cross/cross-h8300
--with-sysroot=/mnt/scratch/cross/cross-h8300
--with-gmp=/mnt/scratch/cross/host-tools/gmp-6.2.1
--with-mpfr=/mnt/scratch/cross/host-tools/mpfr-4.1.0
--with-mpc=/mnt/scratch/cross/host-tools/mpc-1.2.1 --without-cloog
--without-isl --disable-libatomic --disable-libgomp --disable-libitm
--disable-libmpx --disable-libmudflap --disable-libquadmath
--disable-libsanitizer --disable-lto --disable-nls --disable-plugin
--disable-shared --enable-checking=release --enable-languages=c
--enable-multilib --disable-threads --disable-libssp

[Bug tree-optimization/93734] [9 Regression] Invalid code generated with -O2 -march=haswell -ftree-vectorize

[mikpelinux at gmail dot com via Gcc-bugs]

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

--- Comment #8 from Mikael Pettersson  ---
I can't reproduce the wrong code using either the fortran test case in #c2 or
the C one in #c3 with gcc-9.4.0 on Kaby Lake R. If I revert the PR92420 fix
both test cases do reproduce the wrong code. Thus I think this was fixed by
PR92420 in gcc-8.4.0 and gcc-9.3.0.

[Bug target/80786] m68k: internal compiler error: in change_address_1

[mikpelinux at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Mikael Pettersson  ---
Still ICEs gcc-12. m68k_legitimate_address_p () returns false for

(const:SI (plus:SI (symbol_ref:SI ("G") [flags 0x40] )
(const_int 6 [0x6])))
mode 4 (QI is 4)

which triggers the assert failure in change_address_1 ().

[Bug target/82420] ICE with -malign-int and -m68000

[mikpelinux at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Mikael Pettersson  ---
Still ICEs in gcc-12:

> gcc/xgcc -Bgcc -march=68000 -malign-int -S /tmp/pr82420.c
during RTL pass: expand
/tmp/pr82420.c: In function 'f':
/tmp/pr82420.c:3:4: internal compiler error: Segmentation fault
3 |  a /= 3;
  |^~
0x95fe3f crash_signal
/tmp/gcc-12-20210711/gcc/toplev.c:328
0x6c30a2 assign_temp(tree_node*, int, int)
/tmp/gcc-12-20210711/gcc/function.c:976
0x67e321 emit_push_insn(rtx_def*, machine_mode, tree_node*, rtx_def*, unsigned
int, int, rtx_def*, poly_int<1u, long>, rtx_def*, rtx_def*, int, rtx_def*,
bool)
/tmp/gcc-12-20210711/gcc/expr.c:4621
0x559c98 emit_library_call_value_1(int, rtx_def*, rtx_def*, libcall_type,
machine_mode, int, std::pair*)
/tmp/gcc-12-20210711/gcc/calls.c:5595
0x86de22 emit_library_call_value(rtx_def*, rtx_def*, libcall_type,
machine_mode, rtx_def*, machine_mode, rtx_def*, machine_mode)
/tmp/gcc-12-20210711/gcc/rtl.h:4390
0x86de22 expand_binop(machine_mode, optab_tag, rtx_def*, rtx_def*, rtx_def*,
int, optab_methods)
/tmp/gcc-12-20210711/gcc/optabs.c:2172
0x86f9e6 sign_expand_binop(machine_mode, optab_tag, optab_tag, rtx_def*,
rtx_def*, rtx_def*, int, optab_methods)
/tmp/gcc-12-20210711/gcc/optabs.c:2304
0x665e44 expand_divmod(int, tree_code, machine_mode, rtx_def*, rtx_def*,
rtx_def*, int, optab_methods)
/tmp/gcc-12-20210711/gcc/expmed.c:5271
0x66fdad expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
/tmp/gcc-12-20210711/gcc/expr.c:9473
0x57296a expand_gimple_stmt_1
/tmp/gcc-12-20210711/gcc/cfgexpand.c:3980
0x57296a expand_gimple_stmt
/tmp/gcc-12-20210711/gcc/cfgexpand.c:4041
0x577392 expand_gimple_basic_block
/tmp/gcc-12-20210711/gcc/cfgexpand.c:6083
0x579196 execute
/tmp/gcc-12-20210711/gcc/cfgexpand.c:6809
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

The SEGV occurs because emit_library_call_value_1 () [calls.c line 5595] calls
emit_push_insn () with NULL_TREE for TYPE, emit_push_insn () in this test case
needs to call assign_temp () [expr.c line 4621] with the given TYPE, but
assign_temp () fundamentally requires a non-NULL_TREE TYPE.

[Bug target/101175] builtin_clz generates wrong bsr instruction

[mikpelinux at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Mikael Pettersson  ---
(In reply to Uroš Bizjak from comment #3)
> (In reply to Mikael Pettersson from comment #2)
> > (In reply to Iru Cai from comment #0)
> > > Built with '-march=x86-64-v3 -O1', the following code generates a bsr
> > > instruction, which has undefined behavior when the source operand is zero,
> > > thus gives wrong result
> > 
> > The documentation for __builtin_clz(x) states "If x is 0, the result is
> > undefined".
> 
> The testcase from Comment #0 does:
> 
>   if (value != 0) {
>   return __builtin_clz(value);

Yes I just noticed. My mistake.

[Bug target/101175] builtin_clz generates wrong bsr instruction

[mikpelinux at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Mikael Pettersson  ---
(In reply to Iru Cai from comment #0)
> Built with '-march=x86-64-v3 -O1', the following code generates a bsr
> instruction, which has undefined behavior when the source operand is zero,
> thus gives wrong result

The documentation for __builtin_clz(x) states "If x is 0, the result is
undefined".

[Bug target/99847] Optimization breaks alignment on CPU32

[mikpelinux at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Mikael Pettersson  ---
I am almost certain that you need to use an m68k-elf toolchain rather than an
m68k-linux-gnu one for the CPU32. The linux toolchain targets the classic '020
CPU or above (030, 040, or 060) and mandates the Linux ABI, which affects
alignment among other things.

[Bug bootstrap/98590] [11 regression] Bootstrap failure with Ada on Cygwin since switch to C++11

[mikpelinux at gmail dot com via Gcc-bugs]

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

Mikael Pettersson  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #14 from Mikael Pettersson  ---
This issue is now fixed.
Bootstrap still needs the PR94918 fix though.

[Bug bootstrap/98860] [11 Regression] bootstrap failure on MinGW-w64 windows 10

[mikpelinux at gmail dot com via Gcc-bugs]

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

--- Comment #38 from Mikael Pettersson  ---
After updating binutils to ba6eb62ff0ea9843a018cfd7cd06777bd66ae0a0, including
the fix for BZ 27268, I was able to do a full bootstrap of current gcc head on
Cygwin64. https://sourceware.org/bugzilla/show_bug.cgi?id=27268 has more
detail.

[Bug bootstrap/98860] [11 Regression] boostrap failure on MinGW-w64 windows 10

[mikpelinux at gmail dot com via Gcc-bugs]

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

--- Comment #31 from Mikael Pettersson  ---
Created attachment 50158
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50158=edit
conftest.c (based configure's cross compilation test)

This runs Ok when compiled with "-O2 -g -gdwarf-4", but fails with Windows
error code 193 aka "Exec format error" when compiled with "-O2 -g -gdwarf-5".
The error is reproducible with a x86_64-w64-mingw32 cross (just transfer the
EXEs to Windows for execution).

Compiling with -S shows differences in several .debug sections.

[Bug bootstrap/98860] [11 Regression] boostrap failure on MinGW-w64 windows 10

[mikpelinux at gmail dot com via Gcc-bugs]

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

--- Comment #30 from Mikael Pettersson  ---
Patch has been posted:
https://gcc.gnu.org/pipermail/gcc-patches/2021-February/564990.html

[Bug bootstrap/98860] [11 Regression] boostrap failure on MinGW-w64 windows 10

[mikpelinux at gmail dot com via Gcc-bugs]

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

--- Comment #28 from Mikael Pettersson  ---
(In reply to Brecht Sanders from comment #27)
> @Mikael Pettersson, should a similar patch be applied to
> gcc/config/i386/mingw-w64.h to fix this same issue in MinGW-w64?

cygming.h is used for both mingw and cygwin, so no additional patch should be
needed.

[Bug bootstrap/98860] [11 Regression] boostrap failure on MinGW-w64 windows 10

[mikpelinux at gmail dot com via Gcc-bugs]

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

Mikael Pettersson  changed:

   What|Removed |Added

 CC||mikpelinux at gmail dot com

--- Comment #25 from Mikael Pettersson  ---
Created attachment 50138
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50138=edit
do not default to dwarf5 on Windows

I have the same problem with gcc-11 bootstrap failures due to Exec format
errors post stage 1 on Cygwin64, even with current binutils master. I don't
know if it's a bug in binutils or a limitation in Windows, but DWARF5 clearly
does not work there, so this patch disables it. Works for me on Cygwin64. Can
someone please test it on mingw-w64?

[Bug target/98341] [11 Regression] Ada bootstrap fails with Storage_Error stack overflow or erroneous memory access on m68k

[mikpelinux at gmail dot com via Gcc-bugs]

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

--- Comment #5 from Mikael Pettersson  ---
(In reply to John Paul Adrian Glaubitz from comment #4)
> This regression was introduced by:
> 
> commit d7e20130650fb46d71e0403652e4e07bc14f9775 (refs/bisect/bad)
> Author: Justin Squirek 
> Date:   Mon Aug 10 12:05:07 2020 -0400
> 
> [Ada] Reimplementation of accessibility checking

My git bisect landed on this commit too.

[Bug bootstrap/98590] [11 regression] Bootstrap failure with Ada on Cygwin since switch to C++11

[mikpelinux at gmail dot com via Gcc-bugs]

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

--- Comment #11 from Mikael Pettersson  ---
(In reply to Eric Botcazou from comment #10)
> > Kludge to work around configure breakage. Not pretty, but at least it lets
> > bootstrap w/ Ada succeed on Cygwin.
> 
> OK, let's go for this.  Can you post it on the gcc-patches@ mailing list?

Done: https://gcc.gnu.org/pipermail/gcc-patches/2021-February/564804.html

Sorry about the delay, I had issues building current trunk on Cygwin, with
symptoms similar to those shown in the DWARF5 regression PRs.

[Bug bootstrap/98616] Compile gcc 10.2.0 error for loongson 2f CPU use MIPS n32 ABI on Gentoo OS

[mikpelinux at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Mikael Pettersson  ---
> cat mips64el-unknown-linux-gnu/libgcc/config.log
...
configure:3778: checking for suffix of object files
configure:3800: /var/tmp/portage/sys-devel/gcc-10.2.0-r5/work/build/./gcc/xgcc
-B/var/tmp/portage/sys-devel/gcc-10.2.0-r5/work/build/./gcc/
-B/usr/mips64el-unknown-linux-gnu/bin/ -B/usr/mips64el-unknown-linux-gnu/lib/
-isystem /usr/mips64el-unknown-linux-gnu/include -isystem
/usr/mips64el-unknown-linux-gnu/sys-include   -fno-checking -c -g
-march=loongson2f -Wa,-mfix-loongson2f-nop -pipe -fPIC -O2 -minterlink-mips16 
conftest.c >&5
/usr/mips64el-unknown-linux-gnu/bin/as: unrecognized option '-mloongson-mmi'
configure:3804: $? = 2
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "GNU C Runtime Library"
| #define PACKAGE_TARNAME "libgcc"
| #define PACKAGE_VERSION "1.0"
| #define PACKAGE_STRING "GNU C Runtime Library 1.0"
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE_URL "http://www.gnu.org/software/libgcc/;
| /* end confdefs.h.  */
| 
| int
| main ()
| {
| 
|   ;
|   return 0;
| }
configure:3818: error: in
`/var/tmp/portage/sys-devel/gcc-10.2.0-r5/work/build/mips64el-unknown-linux-gnu/libgcc':
configure:3820: error: cannot compute suffix of object files: cannot compile

You have a clear discrepancy between gcc and binutils. As you're using Gentoo
sources and build procedure I suggest you report the bug to them.

[Bug rtl-optimization/96015] [10/11 Regression] gcc-10.1.0 miscompiles Python on hppa

[mikpelinux at gmail dot com via Gcc-bugs]

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

--- Comment #39 from Mikael Pettersson  ---
I tried the few test cases listed in this PR with gcc-11 on sparcv9-linux-gnu,
but wasn't able to observe any miscompilation.