[Bug target/114466] mips: ICE during RTL pass: zero_call_used_regs

[rene at exactcode dot de via Gcc-bugs]

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

--- Comment #6 from René Rebe  ---
ok - good to know. I guess someone should tell the openssh developers and maybe
gcc should error out with a warning. Actually if gcc would error out it would
signal openssl's configure not to automatically try to use it, ...

[Bug target/114466] mips: ICE during RTL pass: zero_call_used_regs

[rene at exactcode dot de via Gcc-bugs]

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

--- Comment #4 from René Rebe  ---
Created attachment 57809
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57809&action=edit
preprocessed source from -freport-bug

preprocessed source from -freport-bug

[Bug target/114466] New: mips: ICE during RTL pass: zero_call_used_regs

[rene at exactcode dot de via Gcc-bugs]

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

Bug ID: 114466
   Summary: mips: ICE during RTL pass: zero_call_used_regs
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rene at exactcode dot de
  Target Milestone: ---

Compiling the latest openssh-9.7p1 (and openssh-9.6p1) for mips-linux or
mips64n32 linux causes and internal compiler error: Segmentation fault:

uring RTL pass: zero_call_used_regs
misc.c: In function 'bandwidth_limit':
misc.c:1807:1: internal compiler error: Segmentation fault
 1807 | }
  | ^
0x128fff5 internal_error(char const*, ...)
???:0
0x863ad0 emit_move_insn(rtx_def*, rtx_def*)
???:0
0xac9967 default_zero_call_used_regs(HARD_REG_SET)
???:0
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.

at least 14-20240324 and 13-20240224 are affected. I would expect at leaste
13.2 as well.

[Bug target/97367] powerpc64 g5 and cell optimizations result in .machine power7

[rene at exactcode dot de via Gcc-bugs]

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

--- Comment #5 from René Rebe  ---
latest version:
https://svn.exactcode.de/t2/trunk/package/develop/gcc/hotfix-g5-power4.patch

[Bug target/97367] New: powerpc64 g5 and cell optimizations result in .machine power7

[rene at exactcode dot de via Gcc-bugs]

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

Bug ID: 97367
   Summary: powerpc64 g5 and cell optimizations result in .machine
power7
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rene at exactcode dot de
  Target Milestone: ---

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

Since reworking the rs6000 .machine output selection in commit
e154242724b084380e3221df7c08fcdbd8460674 22 May 2019, compiling glibc with
either G5 or cell results in power7 assembly optimizations to be chosen, which
obviously crash with illegal instructions. This is because gcc's .machine
output was accidentally changed due to OPTION_MASK_ALTIVEC only otherwise
present in IBM CPUs since power7.

powerpc64-t2-linux-gnu-gcc  test.c -S -o - -mcpu=G5
.file   "test.c"
.machine power7
.abiversion 2
.section".text"
.ident  "GCC: (GNU) 10.2.0"
.section.note.GNU-stack,"",@progbits

Attached patch fixes this to filter out ALTIVEC just like GFXOPT and GPOPT.