Bug 103938 - [11/12/13/14 Regression] ICE with __builtin_prefetch and vectors
Summary: [11/12/13/14 Regression] ICE with __builtin_prefetch and vectors
Status: NEW
Alias: None
Product: gcc
Classification: Unclassified
Component: target (show other bugs)
Version: 12.0
: P2 normal
Target Milestone: 11.5
Assignee: Not yet assigned to anyone
URL:
Keywords: ice-checking, ice-on-valid-code
Depends on:
Blocks:
 
Reported: 2022-01-07 10:12 UTC by Andrew Pinski
Modified: 2023-07-07 10:41 UTC (History)
5 users (show)

See Also:
Host:
Target: aarch64-linux-gnu
Build:
Known to work: 7.1.0
Known to fail: 8.1.0
Last reconfirmed: 2022-04-06 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andrew Pinski 2022-01-07 10:12:44 UTC
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.
Comment 1 Andrew Pinski 2022-01-07 10:51:37 UTC
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.
Comment 2 Andrew Pinski 2022-01-28 00:33:59 UTC
This is a regression in that the assert was added in r8-6032-g43cacb12fc85 though it was a latent issue before then.
Comment 3 Andrew Pinski 2022-01-28 00:35:57 UTC
The latent bug has been there since IRA was added which would have been before AARCH64 backend was added even.
Comment 4 Alex Coplan 2022-04-06 16:28:12 UTC
Confirmed on trunk. I can only reproduce the ICE with trunk, not with earlier released versions.
Comment 5 Andrew Pinski 2022-04-06 16:36:25 UTC
(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.
Comment 6 Alex Coplan 2022-04-07 09:17:48 UTC
(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
Comment 7 Alex Coplan 2022-04-28 17:29:28 UTC
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?
Comment 8 Andrew Pinski 2022-04-28 19:14:39 UTC
(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).
Comment 9 Richard Biener 2022-05-27 09:47:02 UTC
GCC 9 branch is being closed
Comment 10 Jakub Jelinek 2022-06-28 10:47:36 UTC
GCC 10.4 is being released, retargeting bugs to GCC 10.5.
Comment 11 Richard Biener 2023-07-07 10:41:57 UTC
GCC 10 branch is being closed.