Take: typedef unsigned long u64x2 __attribute__ ((vector_size(16))); void g (u64x2 off) { __builtin_prefetch ((void*)off[0], 0, 3); } This ICEs at -O2 and above. during RTL pass: sched1 dump file: t.c.296r.sched1 t.c: In function 'g': t.c:5:1: internal compiler error: in aarch64_classify_address, at config/aarch64/aarch64.c:9966 5 | } | ^ 0x1156ee3 aarch64_classify_address(aarch64_address_info*, rtx_def*, machine_mode, bool, aarch64_addr_query_type) /home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/config/aarch64/aarch64.c:9966 0x1156f03 aarch64_address_valid_for_prefetch_p(rtx_def*, bool) /home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/config/aarch64/aarch64.c:10233 0xb93bbb constraint_satisfied_p ./tm-preds.h:348 0xb93bbb record_reg_classes /home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/ira-costs.c:794 0xb954a7 record_operand_costs /home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/ira-costs.c:1440 0xb95813 scan_one_insn /home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/ira-costs.c:1527 0xb95813 process_bb_for_costs /home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/ira-costs.c:1652 0xb96e1f find_costs_and_classes /home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/ira-costs.c:1759 0xb9771b ira_set_pseudo_classes(bool, _IO_FILE*) /home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/ira-costs.c:2313 0x1964fe7 alloc_global_sched_pressure_data /home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/haifa-sched.c:7201 0x1964fe7 sched_init() /home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/haifa-sched.c:7356 0x19668db haifa_sched_init() /home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/haifa-sched.c:7368 0xd327e7 schedule_insns() /home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/sched-rgn.c:3510 0xd32f9f schedule_insns() /home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/sched-rgn.c:3504 0xd32f9f rest_of_handle_sched /home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/sched-rgn.c:3722 0xd32f9f execute /home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/sched-rgn.c:3830 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions.
ira-costs.c record_operand_costs is stripping off the SUBREG. Is that even valid thing to do? for (i = 0; i < recog_data.n_operands; i++) { rtx op_mem = extract_mem_from_operand (recog_data.operand[i]); memcpy (op_costs[i], init_cost, struct_costs_size); if (GET_CODE (recog_data.operand[i]) == SUBREG) recog_data.operand[i] = SUBREG_REG (recog_data.operand[i]); Here is the instruction which is causing the ICE and is valid with the subreg there: (insn 7 6 0 2 (prefetch (subreg:DI (reg:V2DI 96) 0) (const_int 0 [0]) (const_int 3 [0x3])) "t.c":4:3 26 {prefetch} (expr_list:REG_DEAD (reg:V2DI 96) (nil))) I have to wonder if the stripping off the subreg is valid or not.
This is a regression in that the assert was added in r8-6032-g43cacb12fc85 though it was a latent issue before then.
The latent bug has been there since IRA was added which would have been before AARCH64 backend was added even.
Confirmed on trunk. I can only reproduce the ICE with trunk, not with earlier released versions.
(In reply to Alex Coplan from comment #4) > Confirmed on trunk. I can only reproduce the ICE with trunk, not with > earlier released versions. Are you sure you configured the previous released versions with --enabled-checking=yes ? That is the only way to get the ICE on released versions. I accidentally released a toolchain to our build folks internally inside Marvell with checking enabled and that is how I found this issue. This code is reduced from VPP.
(In reply to Andrew Pinski from comment #5) > (In reply to Alex Coplan from comment #4) > > Confirmed on trunk. I can only reproduce the ICE with trunk, not with > > earlier released versions. > > Are you sure you configured the previous released versions with > --enabled-checking=yes ? That is the only way to get the ICE on released > versions. Well, I just tried a clean build of the GCC 11 branch with --enable-checking=yes, and I don't see the ICE there: $ gcc/xgcc -B gcc -v Reading specs from gcc/specs COLLECT_GCC=gcc/xgcc COLLECT_LTO_WRAPPER=gcc/lto-wrapper Target: aarch64-linux-gnu Configured with: /home/alecop01/toolchain/src/gcc/configure --prefix=/data_sdb/toolchain/cc1s/gcc11-aarch64 --enable-languages=c,c++ --disable-bootstrap --target=aarch64-linux-gnu --enable-checking=yes Thread model: posix Supported LTO compression algorithms: zlib gcc version 11.2.1 20220407 (GCC) $ cat t.c typedef unsigned long u64x2 __attribute__ ((vector_size(16))); void g (u64x2 off) { __builtin_prefetch ((void*)off[0], 0, 3); } $ gcc/xgcc -B gcc -c t.c -O2
A bisect shows this started with r12-2288-g8695bf78dad1a42636775843ca832a2f4dba4da3 : commit 8695bf78dad1a42636775843ca832a2f4dba4da3 Author: Jonathan Wright <jonathan.wright@arm.com> Date: Wed Jun 2 16:55:00 2021 +0100 gcc: Add vec_select -> subreg RTL simplification which makes it a [12/13 Regression], unless I'm missing something? Should it be a P1?
(In reply to Alex Coplan from comment #7) > A bisect shows this started with > r12-2288-g8695bf78dad1a42636775843ca832a2f4dba4da3 : > > commit 8695bf78dad1a42636775843ca832a2f4dba4da3 > Author: Jonathan Wright <jonathan.wright@arm.com> > Date: Wed Jun 2 16:55:00 2021 +0100 > > gcc: Add vec_select -> subreg RTL simplification > > which makes it a [12/13 Regression], unless I'm missing something? Should it > be a P1? It only ices for checking and does not produce wrong code when release checking so it would be a p2 in my mind. Plus it was latent before that patch as I could reproduce on a gcc 10 (maybe I have some other optimizations added which expose it in gcc 10).
GCC 9 branch is being closed
GCC 10.4 is being released, retargeting bugs to GCC 10.5.
GCC 10 branch is being closed.