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

2024-02-18 Thread aarnold.gcc at antonarnold dot de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108640

--- Comment #10 from Anton Arnold  ---
I applied the patch to a gcc 13.2 buildroot toolchain for a coldfire cpu with
ISA-A+ instruction set. Everything compiled fine and a linux 4.19 uclinux nommu
build with buildroot and several custom packages runs fine with no
abnormabilities. Great work, thank you for still contributing to this
architecture!

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

2024-01-20 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108640

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |14.0

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

2024-01-19 Thread law at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108640

Jeffrey A. Law  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 CC||law at gcc dot gnu.org
 Status|NEW |RESOLVED

--- Comment #9 from Jeffrey A. Law  ---
Fixed on the trunk.  No plans to backport.

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

2024-01-19 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108640

--- Comment #8 from GCC Commits  ---
The master branch has been updated by Jeff Law :

https://gcc.gnu.org/g:a834414794d80f21550dd0591e260fc833f49eb9

commit r14-8298-ga834414794d80f21550dd0591e260fc833f49eb9
Author: Mikael Pettersson 
Date:   Fri Jan 19 16:05:34 2024 -0700

[PATCH] Avoid ICE in single-bit logical RMWs on m68k-uclinux [PR108640]

When generating RMW logical operations on m68k, the backend
recognizes single-bit operations and rewrites them as bit
instructions on operands adjusted to address the intended byte.
When offsetting the addresses the backend keeps the modes as
SImode, even though the actual access will be in QImode.

The uclinux target defines M68K_OFFSETS_MUST_BE_WITHIN_SECTIONS_P
which adds a check that the adjusted operand is within the bounds
of the original object.  Since the address has been offset it is
not, and the compiler ICEs.

The bug is that the modes of the adjusted operands should have been
narrowed to QImode, which is that this patch does.  Nearby code
which narrows to HImode gets that right.

Bootstrapped and regression tested on m68k-linux-gnu.

Ok for master? (Note: I don't have commit rights.)

gcc/

PR target/108640
* config/m68k/m68k.cc (output_andsi3): Use QImode for
address adjusted for 1-byte RMW access.
(output_iorsi3): Likewise.
(output_xorsi3): Likewise.

gcc/testsuite/

PR target/108640
* gcc.target/m68k/pr108640.c: New test.

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

2024-01-18 Thread 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/108640] ICE compiling busybox for m68k in change_address_1, at emit-rtl.cc:2283

2023-12-30 Thread 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

2023-12-30 Thread 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/108640] ICE compiling busybox for m68k in change_address_1, at emit-rtl.cc:2283

2023-10-15 Thread matthias.reis at posteo dot de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108640

--- Comment #4 from Matthias Reis  ---
I have the same problem unfortunately. Changing '-Os' into '-O2' fixes the
problem for me.

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

2023-03-30 Thread marxin at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108640

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
 CC||marxin at gcc dot gnu.org
   Keywords|needs-reduction |
   Last reconfirmed||2023-03-30

--- Comment #3 from Martin Liška  ---
Reduced test-case:

$ cat pr108640.i
int option_mask32;

enum {
  OPTBIT_F = 12,
  OPTBIT_R,
  OPTBIT_Z,
  OPTBIT_c,
  OPTBIT_t,
  OPT_t = 1 << OPTBIT_t
} ls_main() {
  option_mask32 |= OPT_t;
}

$ ./xgcc -B. ~/Programming/testcases/pr108640.i -c -Os
during RTL pass: final
/home/marxin/Programming/testcases/pr108640.i: In function ‘ls_main’:
/home/marxin/Programming/testcases/pr108640.i:12:1: internal compiler error: in
change_address_1, at emit-rtl.cc:2287
   12 | }
  | ^
0xee4b72 change_address_1
/home/marxin/Programming/gcc/gcc/emit-rtl.cc:2287
0xee5684 adjust_address_1(rtx_def*, machine_mode, poly_int<1u, long>, int, int,
int, poly_int<1u, long>)
/home/marxin/Programming/gcc/gcc/emit-rtl.cc:2421
0x190e4e3 output_iorsi3(rtx_def**)
/home/marxin/Programming/gcc/gcc/config/m68k/m68k.cc:5513
0x1fd17bd output_255
/home/marxin/Programming/gcc/gcc/config/m68k/m68k.md:3779
0xf64f4f get_insn_template(int, rtx_insn*)
/home/marxin/Programming/gcc/gcc/final.cc:2029
0xf66b5e final_scan_insn_1
/home/marxin/Programming/gcc/gcc/final.cc:2774
0xf66fd2 final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
/home/marxin/Programming/gcc/gcc/final.cc:2887
0xf64d79 final_1
/home/marxin/Programming/gcc/gcc/final.cc:1979
0xf69bbc rest_of_handle_final
/home/marxin/Programming/gcc/gcc/final.cc:4240
0xf69f1a execute
/home/marxin/Programming/gcc/gcc/final.cc:4318
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/108640] ICE compiling busybox for m68k in change_address_1, at emit-rtl.cc:2283

2023-02-02 Thread 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

2023-02-02 Thread 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.