public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug target/111815] New: VAX: ICE in 'print_operand_address' while building 'elf_zstd_decompress' from libbacktrace/elf.c
@ 2023-10-14 23:47 macro at orcam dot me.uk
2023-10-15 1:31 ` [Bug target/111815] " macro at orcam dot me.uk
` (6 more replies)
0 siblings, 7 replies; 8+ messages in thread
From: macro at orcam dot me.uk @ 2023-10-14 23:47 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111815
Bug ID: 111815
Summary: VAX: ICE in 'print_operand_address' while building
'elf_zstd_decompress' from libbacktrace/elf.c
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: blocker
Priority: P3
Component: target
Assignee: macro at orcam dot me.uk
Reporter: macro at orcam dot me.uk
Target Milestone: ---
Target: vax-*-*
Created attachment 56113
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56113&action=edit
VAX: Only accept the index scaler as the RHS operand to ASHIFT
As from commit 9df1ba9a35b8 ("libbacktrace: support zstd decompression")
GCC for the `vax-netbsdelf' target fails to complete building, with an
ICE:
during RTL pass: final
.../libbacktrace/elf.c: In function 'elf_zstd_decompress':
.../libbacktrace/elf.c:5006:1: internal compiler error: in
print_operand_address, at config/vax/vax.cc:514
5006 | }
| ^
0x1113df97 print_operand_address(_IO_FILE*, rtx_def*)
.../gcc/config/vax/vax.cc:514
0x10c2489b default_print_operand_address(_IO_FILE*, machine_mode, rtx_def*)
.../gcc/targhooks.cc:373
0x106ddd0b output_address(machine_mode, rtx_def*)
.../gcc/final.cc:3648
0x106ddd0b output_asm_insn(char const*, rtx_def**)
.../gcc/final.cc:3505
0x106e2143 output_asm_insn(char const*, rtx_def**)
.../gcc/final.cc:3421
0x106e2143 final_scan_insn_1
.../gcc/final.cc:2841
0x106e28e3 final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
.../gcc/final.cc:2887
0x106e2bf7 final_1
.../gcc/final.cc:1979
0x106e3c67 rest_of_handle_final
.../gcc/final.cc:4240
0x106e3c67 execute
.../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 <https://gcc.gnu.org/bugs/> for instructions.
This is due to combine producing an invalid address RTX:
(plus:SI (ashift:SI (const_int 1 [0x1])
(reg:QI 3 %r3 [1232]))
(reg/v:SI 10 %r10 [orig:736 weight_mask ] [736]))
where the expression is ((1 << R3) + R10), which does not match a valid
machine address mode. Consequently `print_operand_address' chokes.
The ultimate cause has been commit c605a8bf9270 ("VAX: Accept ASHIFT in
address expressions"), where a shift of an immediate value by a register
has been mistakenly allowed as an index expression as if the shift
operation was commutative such as multiplication is. So with ASHIFT
the scaler in an index expression has to be the right-hand operand, and
the backend has to enforce that, whereas with MULT the scaler can be
either operand.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug target/111815] VAX: ICE in 'print_operand_address' while building 'elf_zstd_decompress' from libbacktrace/elf.c
2023-10-14 23:47 [Bug target/111815] New: VAX: ICE in 'print_operand_address' while building 'elf_zstd_decompress' from libbacktrace/elf.c macro at orcam dot me.uk
@ 2023-10-15 1:31 ` macro at orcam dot me.uk
2023-10-15 23:48 ` macro at orcam dot me.uk
` (5 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: macro at orcam dot me.uk @ 2023-10-15 1:31 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111815
Maciej W. Rozycki <macro at orcam dot me.uk> changed:
What |Removed |Added
----------------------------------------------------------------------------
Ever confirmed|0 |1
Target Milestone|--- |14.0
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed| |2023-10-15
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug target/111815] VAX: ICE in 'print_operand_address' while building 'elf_zstd_decompress' from libbacktrace/elf.c
2023-10-14 23:47 [Bug target/111815] New: VAX: ICE in 'print_operand_address' while building 'elf_zstd_decompress' from libbacktrace/elf.c macro at orcam dot me.uk
2023-10-15 1:31 ` [Bug target/111815] " macro at orcam dot me.uk
@ 2023-10-15 23:48 ` macro at orcam dot me.uk
2023-11-22 1:28 ` cvs-commit at gcc dot gnu.org
` (4 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: macro at orcam dot me.uk @ 2023-10-15 23:48 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111815
--- Comment #1 from Maciej W. Rozycki <macro at orcam dot me.uk> ---
Created attachment 56120
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56120&action=edit
Reduced testcase
This triggers the same ICE in `p'. Preincrements are required so that
their results land in registers and consequently an indexed addressing
mode is tried or otherwise doing operations piecemeal on stack-based
function arguments as direct input operands turns out more profitable
in terms of RTX costs and the ICE is avoided.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug target/111815] VAX: ICE in 'print_operand_address' while building 'elf_zstd_decompress' from libbacktrace/elf.c
2023-10-14 23:47 [Bug target/111815] New: VAX: ICE in 'print_operand_address' while building 'elf_zstd_decompress' from libbacktrace/elf.c macro at orcam dot me.uk
2023-10-15 1:31 ` [Bug target/111815] " macro at orcam dot me.uk
2023-10-15 23:48 ` macro at orcam dot me.uk
@ 2023-11-22 1:28 ` cvs-commit at gcc dot gnu.org
2023-11-22 1:34 ` cvs-commit at gcc dot gnu.org
` (3 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2023-11-22 1:28 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111815
--- Comment #2 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Maciej W. Rozycki <macro@gcc.gnu.org>:
https://gcc.gnu.org/g:56ff988e6be3fdba70cad86d73ec0038bc3b6b5a
commit r14-5745-g56ff988e6be3fdba70cad86d73ec0038bc3b6b5a
Author: Maciej W. Rozycki <macro@embecosm.com>
Date: Wed Nov 22 01:27:02 2023 +0000
PR target/111815: VAX: Only accept the index scaler as the RHS operand to
ASHIFT
As from commit 9df1ba9a35b8 ("libbacktrace: support zstd decompression")
GCC for the `vax-netbsdelf' target fails to complete building, with an
ICE:
during RTL pass: final
.../libbacktrace/elf.c: In function 'elf_zstd_decompress':
.../libbacktrace/elf.c:5006:1: internal compiler error: in
print_operand_address, at config/vax/vax.cc:514
5006 | }
| ^
0x1113df97 print_operand_address(_IO_FILE*, rtx_def*)
.../gcc/config/vax/vax.cc:514
0x10c2489b default_print_operand_address(_IO_FILE*, machine_mode, rtx_def*)
.../gcc/targhooks.cc:373
0x106ddd0b output_address(machine_mode, rtx_def*)
.../gcc/final.cc:3648
0x106ddd0b output_asm_insn(char const*, rtx_def**)
.../gcc/final.cc:3505
0x106e2143 output_asm_insn(char const*, rtx_def**)
.../gcc/final.cc:3421
0x106e2143 final_scan_insn_1
.../gcc/final.cc:2841
0x106e28e3 final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
.../gcc/final.cc:2887
0x106e2bf7 final_1
.../gcc/final.cc:1979
0x106e3c67 rest_of_handle_final
.../gcc/final.cc:4240
0x106e3c67 execute
.../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 <https://gcc.gnu.org/bugs/> for instructions.
This is due to combine producing an invalid address RTX:
(plus:SI (ashift:SI (const_int 1 [0x1])
(reg:QI 3 %r3 [1232]))
(reg/v:SI 10 %r10 [orig:736 weight_mask ] [736]))
where the expression is ((1 << R3) + R10), which does not match a valid
machine addressing mode. Consequently `print_operand_address' chokes.
This can be reduced to the testcase included, where it triggers the same
ICE in `p'. Preincrements are required so that their results land in
registers and consequently an indexed addressing mode is tried or
otherwise doing operations piecemeal on stack-based function arguments
as direct input operands turns out more profitable in terms of RTX costs
and the ICE is avoided.
The ultimate cause has been commit c605a8bf9270 ("VAX: Accept ASHIFT in
address expressions"), where a shift of an immediate value by a register
has been mistakenly allowed as an index expression as if the shift
operation was commutative such as multiplication is. So with ASHIFT the
scaler in an index expression has to be the right-hand operand, and the
backend has to enforce that, whereas with MULT the scaler can be either
operand.
Fix this by only accepting the index scaler as the RHS operand to
ASHIFT.
gcc/
PR target/111815
* config/vax/vax.cc (index_term_p): Only accept the index scaler
as the RHS operand to ASHIFT.
gcc/testsuite/
PR target/111815
* gcc.dg/torture/pr111815.c: New test.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug target/111815] VAX: ICE in 'print_operand_address' while building 'elf_zstd_decompress' from libbacktrace/elf.c
2023-10-14 23:47 [Bug target/111815] New: VAX: ICE in 'print_operand_address' while building 'elf_zstd_decompress' from libbacktrace/elf.c macro at orcam dot me.uk
` (2 preceding siblings ...)
2023-11-22 1:28 ` cvs-commit at gcc dot gnu.org
@ 2023-11-22 1:34 ` cvs-commit at gcc dot gnu.org
2023-11-22 2:16 ` cvs-commit at gcc dot gnu.org
` (2 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2023-11-22 1:34 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111815
--- Comment #3 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-13 branch has been updated by Maciej W. Rozycki
<macro@gcc.gnu.org>:
https://gcc.gnu.org/g:2c23fa691d23d9f3d57ac7feece6fbbb7236c563
commit r13-8089-g2c23fa691d23d9f3d57ac7feece6fbbb7236c563
Author: Maciej W. Rozycki <macro@embecosm.com>
Date: Wed Nov 22 01:27:02 2023 +0000
PR target/111815: VAX: Only accept the index scaler as the RHS operand to
ASHIFT
As from commit 9df1ba9a35b8 ("libbacktrace: support zstd decompression")
GCC for the `vax-netbsdelf' target fails to complete building, with an
ICE:
during RTL pass: final
.../libbacktrace/elf.c: In function 'elf_zstd_decompress':
.../libbacktrace/elf.c:5006:1: internal compiler error: in
print_operand_address, at config/vax/vax.cc:514
5006 | }
| ^
0x1113df97 print_operand_address(_IO_FILE*, rtx_def*)
.../gcc/config/vax/vax.cc:514
0x10c2489b default_print_operand_address(_IO_FILE*, machine_mode, rtx_def*)
.../gcc/targhooks.cc:373
0x106ddd0b output_address(machine_mode, rtx_def*)
.../gcc/final.cc:3648
0x106ddd0b output_asm_insn(char const*, rtx_def**)
.../gcc/final.cc:3505
0x106e2143 output_asm_insn(char const*, rtx_def**)
.../gcc/final.cc:3421
0x106e2143 final_scan_insn_1
.../gcc/final.cc:2841
0x106e28e3 final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
.../gcc/final.cc:2887
0x106e2bf7 final_1
.../gcc/final.cc:1979
0x106e3c67 rest_of_handle_final
.../gcc/final.cc:4240
0x106e3c67 execute
.../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 <https://gcc.gnu.org/bugs/> for instructions.
This is due to combine producing an invalid address RTX:
(plus:SI (ashift:SI (const_int 1 [0x1])
(reg:QI 3 %r3 [1232]))
(reg/v:SI 10 %r10 [orig:736 weight_mask ] [736]))
where the expression is ((1 << R3) + R10), which does not match a valid
machine addressing mode. Consequently `print_operand_address' chokes.
This can be reduced to the testcase included, where it triggers the same
ICE in `p'. Preincrements are required so that their results land in
registers and consequently an indexed addressing mode is tried or
otherwise doing operations piecemeal on stack-based function arguments
as direct input operands turns out more profitable in terms of RTX costs
and the ICE is avoided.
The ultimate cause has been commit c605a8bf9270 ("VAX: Accept ASHIFT in
address expressions"), where a shift of an immediate value by a register
has been mistakenly allowed as an index expression as if the shift
operation was commutative such as multiplication is. So with ASHIFT the
scaler in an index expression has to be the right-hand operand, and the
backend has to enforce that, whereas with MULT the scaler can be either
operand.
Fix this by only accepting the index scaler as the RHS operand to
ASHIFT.
gcc/
PR target/111815
* config/vax/vax.cc (index_term_p): Only accept the index scaler
as the RHS operand to ASHIFT.
gcc/testsuite/
PR target/111815
* gcc.dg/torture/pr111815.c: New test.
(cherry picked from commit 56ff988e6be3fdba70cad86d73ec0038bc3b6b5a)
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug target/111815] VAX: ICE in 'print_operand_address' while building 'elf_zstd_decompress' from libbacktrace/elf.c
2023-10-14 23:47 [Bug target/111815] New: VAX: ICE in 'print_operand_address' while building 'elf_zstd_decompress' from libbacktrace/elf.c macro at orcam dot me.uk
` (3 preceding siblings ...)
2023-11-22 1:34 ` cvs-commit at gcc dot gnu.org
@ 2023-11-22 2:16 ` cvs-commit at gcc dot gnu.org
2023-11-22 2:25 ` cvs-commit at gcc dot gnu.org
2023-11-22 2:31 ` macro at orcam dot me.uk
6 siblings, 0 replies; 8+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2023-11-22 2:16 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111815
--- Comment #4 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-12 branch has been updated by Maciej W. Rozycki
<macro@gcc.gnu.org>:
https://gcc.gnu.org/g:31bc12b6bb3fd56a65d1f73dcc4fcfad6486361c
commit r12-9998-g31bc12b6bb3fd56a65d1f73dcc4fcfad6486361c
Author: Maciej W. Rozycki <macro@embecosm.com>
Date: Wed Nov 22 01:27:02 2023 +0000
PR target/111815: VAX: Only accept the index scaler as the RHS operand to
ASHIFT
As from commit 9df1ba9a35b8 ("libbacktrace: support zstd decompression")
GCC for the `vax-netbsdelf' target fails to complete building, with an
ICE:
during RTL pass: final
.../libbacktrace/elf.c: In function 'elf_zstd_decompress':
.../libbacktrace/elf.c:5006:1: internal compiler error: in
print_operand_address, at config/vax/vax.cc:514
5006 | }
| ^
0x1113df97 print_operand_address(_IO_FILE*, rtx_def*)
.../gcc/config/vax/vax.cc:514
0x10c2489b default_print_operand_address(_IO_FILE*, machine_mode, rtx_def*)
.../gcc/targhooks.cc:373
0x106ddd0b output_address(machine_mode, rtx_def*)
.../gcc/final.cc:3648
0x106ddd0b output_asm_insn(char const*, rtx_def**)
.../gcc/final.cc:3505
0x106e2143 output_asm_insn(char const*, rtx_def**)
.../gcc/final.cc:3421
0x106e2143 final_scan_insn_1
.../gcc/final.cc:2841
0x106e28e3 final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
.../gcc/final.cc:2887
0x106e2bf7 final_1
.../gcc/final.cc:1979
0x106e3c67 rest_of_handle_final
.../gcc/final.cc:4240
0x106e3c67 execute
.../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 <https://gcc.gnu.org/bugs/> for instructions.
This is due to combine producing an invalid address RTX:
(plus:SI (ashift:SI (const_int 1 [0x1])
(reg:QI 3 %r3 [1232]))
(reg/v:SI 10 %r10 [orig:736 weight_mask ] [736]))
where the expression is ((1 << R3) + R10), which does not match a valid
machine addressing mode. Consequently `print_operand_address' chokes.
This can be reduced to the testcase included, where it triggers the same
ICE in `p'. Preincrements are required so that their results land in
registers and consequently an indexed addressing mode is tried or
otherwise doing operations piecemeal on stack-based function arguments
as direct input operands turns out more profitable in terms of RTX costs
and the ICE is avoided.
The ultimate cause has been commit c605a8bf9270 ("VAX: Accept ASHIFT in
address expressions"), where a shift of an immediate value by a register
has been mistakenly allowed as an index expression as if the shift
operation was commutative such as multiplication is. So with ASHIFT the
scaler in an index expression has to be the right-hand operand, and the
backend has to enforce that, whereas with MULT the scaler can be either
operand.
Fix this by only accepting the index scaler as the RHS operand to
ASHIFT.
gcc/
PR target/111815
* config/vax/vax.cc (index_term_p): Only accept the index scaler
as the RHS operand to ASHIFT.
gcc/testsuite/
PR target/111815
* gcc.dg/torture/pr111815.c: New test.
(cherry picked from commit 56ff988e6be3fdba70cad86d73ec0038bc3b6b5a)
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug target/111815] VAX: ICE in 'print_operand_address' while building 'elf_zstd_decompress' from libbacktrace/elf.c
2023-10-14 23:47 [Bug target/111815] New: VAX: ICE in 'print_operand_address' while building 'elf_zstd_decompress' from libbacktrace/elf.c macro at orcam dot me.uk
` (4 preceding siblings ...)
2023-11-22 2:16 ` cvs-commit at gcc dot gnu.org
@ 2023-11-22 2:25 ` cvs-commit at gcc dot gnu.org
2023-11-22 2:31 ` macro at orcam dot me.uk
6 siblings, 0 replies; 8+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2023-11-22 2:25 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111815
--- Comment #5 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-11 branch has been updated by Maciej W. Rozycki
<macro@gcc.gnu.org>:
https://gcc.gnu.org/g:66a4094112c446ec16733c687e4b3813519da66b
commit r11-11108-g66a4094112c446ec16733c687e4b3813519da66b
Author: Maciej W. Rozycki <macro@embecosm.com>
Date: Wed Nov 22 01:27:02 2023 +0000
PR target/111815: VAX: Only accept the index scaler as the RHS operand to
ASHIFT
As from commit 9df1ba9a35b8 ("libbacktrace: support zstd decompression")
GCC for the `vax-netbsdelf' target fails to complete building, with an
ICE:
during RTL pass: final
.../libbacktrace/elf.c: In function 'elf_zstd_decompress':
.../libbacktrace/elf.c:5006:1: internal compiler error: in
print_operand_address, at config/vax/vax.cc:514
5006 | }
| ^
0x1113df97 print_operand_address(_IO_FILE*, rtx_def*)
.../gcc/config/vax/vax.cc:514
0x10c2489b default_print_operand_address(_IO_FILE*, machine_mode, rtx_def*)
.../gcc/targhooks.cc:373
0x106ddd0b output_address(machine_mode, rtx_def*)
.../gcc/final.cc:3648
0x106ddd0b output_asm_insn(char const*, rtx_def**)
.../gcc/final.cc:3505
0x106e2143 output_asm_insn(char const*, rtx_def**)
.../gcc/final.cc:3421
0x106e2143 final_scan_insn_1
.../gcc/final.cc:2841
0x106e28e3 final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
.../gcc/final.cc:2887
0x106e2bf7 final_1
.../gcc/final.cc:1979
0x106e3c67 rest_of_handle_final
.../gcc/final.cc:4240
0x106e3c67 execute
.../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 <https://gcc.gnu.org/bugs/> for instructions.
This is due to combine producing an invalid address RTX:
(plus:SI (ashift:SI (const_int 1 [0x1])
(reg:QI 3 %r3 [1232]))
(reg/v:SI 10 %r10 [orig:736 weight_mask ] [736]))
where the expression is ((1 << R3) + R10), which does not match a valid
machine addressing mode. Consequently `print_operand_address' chokes.
This can be reduced to the testcase included, where it triggers the same
ICE in `p'. Preincrements are required so that their results land in
registers and consequently an indexed addressing mode is tried or
otherwise doing operations piecemeal on stack-based function arguments
as direct input operands turns out more profitable in terms of RTX costs
and the ICE is avoided.
The ultimate cause has been commit c605a8bf9270 ("VAX: Accept ASHIFT in
address expressions"), where a shift of an immediate value by a register
has been mistakenly allowed as an index expression as if the shift
operation was commutative such as multiplication is. So with ASHIFT the
scaler in an index expression has to be the right-hand operand, and the
backend has to enforce that, whereas with MULT the scaler can be either
operand.
Fix this by only accepting the index scaler as the RHS operand to
ASHIFT.
gcc/
PR target/111815
* config/vax/vax.c (index_term_p): Only accept the index scaler
as the RHS operand to ASHIFT.
gcc/testsuite/
PR target/111815
* gcc.dg/torture/pr111815.c: New test.
(cherry picked from commit 56ff988e6be3fdba70cad86d73ec0038bc3b6b5a)
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug target/111815] VAX: ICE in 'print_operand_address' while building 'elf_zstd_decompress' from libbacktrace/elf.c
2023-10-14 23:47 [Bug target/111815] New: VAX: ICE in 'print_operand_address' while building 'elf_zstd_decompress' from libbacktrace/elf.c macro at orcam dot me.uk
` (5 preceding siblings ...)
2023-11-22 2:25 ` cvs-commit at gcc dot gnu.org
@ 2023-11-22 2:31 ` macro at orcam dot me.uk
6 siblings, 0 replies; 8+ messages in thread
From: macro at orcam dot me.uk @ 2023-11-22 2:31 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111815
Maciej W. Rozycki <macro at orcam dot me.uk> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution|--- |FIXED
--- Comment #6 from Maciej W. Rozycki <macro at orcam dot me.uk> ---
Fix now committed and backported to GCC 13/12/11. Closing bug.
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2023-11-22 2:31 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-10-14 23:47 [Bug target/111815] New: VAX: ICE in 'print_operand_address' while building 'elf_zstd_decompress' from libbacktrace/elf.c macro at orcam dot me.uk
2023-10-15 1:31 ` [Bug target/111815] " macro at orcam dot me.uk
2023-10-15 23:48 ` macro at orcam dot me.uk
2023-11-22 1:28 ` cvs-commit at gcc dot gnu.org
2023-11-22 1:34 ` cvs-commit at gcc dot gnu.org
2023-11-22 2:16 ` cvs-commit at gcc dot gnu.org
2023-11-22 2:25 ` cvs-commit at gcc dot gnu.org
2023-11-22 2:31 ` macro at orcam dot me.uk
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).