[Bug target/63805] ICE: in extract_insn, at recog.c:2327 with -mcpu=power8

[asolokha at gmx dot com]

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

Arseny Solokha  changed:

   What|Removed |Added

 CC||asolokha at gmx dot com

--- Comment #16 from Arseny Solokha  ---
I cannot reproduce the ICE w/ any of the testcases posted here, using gcc 8.2
and the current trunk (10.0).

[Bug target/63805] ICE: in extract_insn, at recog.c:2327 with -mcpu=power8

[kelvin at gcc dot gnu.org]

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

--- Comment #15 from kelvin at gcc dot gnu.org ---
On my macbook, g++ (Apple LLVM version 7.0.2 (clang-700.1.81), Target:
x86_64-apple-darwin15.3.0), the test program does compile successfully.

For Martin's simplified example, it produces the following code:

__Z3barv:   ## @_Z3barv
.cfi_startproc
## BB#0:
pushq   %rbp
Ltmp0:
.cfi_def_cfa_offset 16
Ltmp1:
.cfi_offset %rbp, -16
movq%rsp, %rbp
Ltmp2:
.cfi_def_cfa_register %rbp
subq$80, %rsp
movl$16, %eax
movl%eax, %edi
xorl%ecx, %ecx
leaq-16(%rbp), %rdx
movq%rdx, %rsi
callq   ___atomic_load
leaq-40(%rbp), %rdx
xorl%esi, %esi
movl$24, %eax
movl%eax, %edi
movq%rdx, %r8
movq%rdi, -48(%rbp) ## 8-byte Spill
movq%r8, %rdi
movq-48(%rbp), %r8  ## 8-byte Reload
movq%rdx, -56(%rbp) ## 8-byte Spill
movq%r8, %rdx
callq   _memset
movq-56(%rbp), %rdx ## 8-byte Reload
movq(%rdx), %rdi
movq%rdi, (%rsp)
movq8(%rdx), %rdi
movq%rdi, 8(%rsp)
movq16(%rdx), %rdi
movq%rdi, 16(%rsp)
callq   __Z3foo1B
addq$80, %rsp
popq%rbp
retq
.cfi_endproc

I tried Alan's small-value test case on the Apple Mac compiler as well.  I made
minor changes to the source code to make the "stricter" type checking of that
environment happy.  The program compiles and runs ok on Apple Macintosh:

#include 

/* intel compiler claims to ignore packed __attribute__ */
struct foo { 
char pad;
char x[4];
} __attribute__((packed)) a;

int
bar (int val)
{
int ret;
char array1[4];
char array2[4];

*((int *) array1) = val;
/* copies a.x to array2 and copies array1 to a.x, atomically. */
__atomic_exchange (&a.x, &array1, &array2, 5);

ret = *((int *) array2);
return  ret;
}

int main ()
{
std::cout << "Result from first __atomic_exchange is " << bar (42) << "\n";
std::cout << "Result from second __atomic_exchange is " << bar (13) <<
"\n";
std::cout << "Result from third __atomic_exchange is " << bar (25) << "\n";
}

Though I'm no longer fluent in reading Intel assembler, I'm pretty confident
that the struct is packed and the atomic exchange deals with an unaligned
address to a 4-byte quantity:

.globl  __Z3bari
.align  4, 0x90
__Z3bari:   ## @_Z3bari
.cfi_startproc
## BB#0:
pushq   %rbp
Ltmp0:
.cfi_def_cfa_offset 16
Ltmp1:
.cfi_offset %rbp, -16
movq%rsp, %rbp
Ltmp2:
.cfi_def_cfa_register %rbp
subq$16, %rsp
leaq_a(%rip), %rax
addq$1, %rax
movl$5, %edx
movl%edi, -4(%rbp)
movl-4(%rbp), %edi
movl%edi, -12(%rbp)
movl-12(%rbp), %esi
movq%rax, %rdi
callq   ___atomic_exchange_4
movl%eax, -16(%rbp)
movl-16(%rbp), %eax
movl%eax, -8(%rbp)
movl-8(%rbp), %eax
addq$16, %rsp
popq%rbp
retq
.cfi_endproc

with _a declared as follows:

.globl  _a  ## @a
.zerofill __DATA,__common,_a,5,0

[Bug target/63805] ICE: in extract_insn, at recog.c:2327 with -mcpu=power8

[wschmidt at gcc dot gnu.org]

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

--- Comment #14 from Bill Schmidt  ---
>From correspondence with Uli Weigand, it appears that the code is valid even
with misaligned data, but a locking implementation is needed.  I haven't
checked whether other targets succeed here; that would be interesting to know.

[Bug target/63805] ICE: in extract_insn, at recog.c:2327 with -mcpu=power8

[amodra at gmail dot com]

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

--- Comment #13 from Alan Modra  ---
Note that testcases with smaller atomic ops fail too, but at runtime.  For
example:

struct foo { char pad; char x[4]; } a;

int
bar (int val)
{
  int ret;
  __atomic_exchange (&a.x, &val, &ret, 5);
  return  ret;
}

int main ()
{
  return bar (42);
}

Fails with a bus error.

[Bug target/63805] ICE: in extract_insn, at recog.c:2327 with -mcpu=power8

[amodra at gmail dot com]

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

Alan Modra  changed:

   What|Removed |Added

 CC||amodra at gmail dot com

--- Comment #12 from Alan Modra  ---
The problem with the both the original testcase and the one in comment #4 is
that a 16-byte atomic access is being attempted on an object that is not
16-byte aligned.  I'm not sure if that makes the code invalid, or whether it
means that powerpc64 should use a locking implementation, but mis-aligned
16-byte atomic loads are not supported by the hardware.

[Bug target/63805] ICE: in extract_insn, at recog.c:2327 with -mcpu=power8

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #11 from Bill Schmidt  ---
OK, yes, that looks correct.  Thanks for the clarification!  I had missed that
statement.

[Bug target/63805] ICE: in extract_insn, at recog.c:2327 with -mcpu=power8

[msebor at gcc dot gnu.org]

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

--- Comment #10 from Martin Sebor  ---
Since the manual says that "... The four non-arithmetic functions (load, store,
exchange, and compare_exchange) all have a generic version as well. This
generic version works on any data type." I believe the code in the small test
case in comment #4 (and probably also the bigger test case in the description
that I reduced the small one from) is valid.

[Bug target/63805] ICE: in extract_insn, at recog.c:2327 with -mcpu=power8

[wschmidt at gcc dot gnu.org]

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

--- Comment #9 from Bill Schmidt  ---
Same question for Markus.  Sorry for conflating the two of you. :)

[Bug target/63805] ICE: in extract_insn, at recog.c:2327 with -mcpu=power8

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #8 from Bill Schmidt  ---
Martin, per the description of _atomic_load in the GCC manual, this appears to
be invalid code.  Do you disagree?  Of course we should probably die more
gracefully, but in both cases _atomic_load appears to be called in an invalid
manner.

[Bug target/63805] ICE: in extract_insn, at recog.c:2327 with -mcpu=power8

[kelvin at gcc dot gnu.org]

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

kelvin at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kelvin at gcc dot gnu.org

--- Comment #7 from kelvin at gcc dot gnu.org ---
The "official" description of the built-in atomic operations
(https://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html) states "GCC
allows any integral scalar or pointer type that is 1, 2, 4, or 8 bytes in
length. 16-byte integral types are also allowed if ‘__int128’ (see __int128) is
supported by the architecture."

It appears that this test case represents illegal source code.  (Rather than
aborting with an internal compiler error, the compiler should report an error
message due to the illegal use of this built-in API.)

[Bug target/63805] ICE: in extract_insn, at recog.c:2327 with -mcpu=power8

[kelvin at gcc dot gnu.org]

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

--- Comment #6 from kelvin at gcc dot gnu.org ---
Author: kelvin
Date: Fri Jan 22 22:13:43 2016
New Revision: 232752

URL: https://gcc.gnu.org/viewcvs?rev=232752&root=gcc&view=rev
Log:

This "branch" is to support kelvin's work on bugzilla PR 63805.


Added:
branches/ibm/kelvin-pr63805/
  - copied from r232751, trunk/

[Bug target/63805] ICE: in extract_insn, at recog.c:2327 with -mcpu=power8

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
   Last reconfirmed|2014-11-10 00:00:00 |2016-1-19
  Known to work||4.8.5
  Known to fail||5.3.0, 6.0

--- Comment #5 from Martin Sebor  ---
6.0 still fails with the same ICE.  The native 4.8.5 on RHEL 7.2 works though
it's not the same as the vanilla 4.8.5.

[Bug target/63805] ICE: in extract_insn, at recog.c:2327 with -mcpu=power8

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #4 from Martin Sebor  ---
A smaller test case still fails with GCC 5.0.0 20150221, on both ppc64 and
ppc64le.  4.9.4 and 4.8.3 fail similarly.

$ cat u.cpp && /build/gcc-trunk/gcc/xgcc -B /build/gcc-trunk/gcc -O2 -S
-mcpu=power8 -xc++ u.cpp
struct A { long a; int b; };

struct B
{
struct { } c;
long a;
int b;
};

void foo (B);

void bar ()
{
A a;
__atomic_load (&a, &a, 0);
foo (B ());
}
u.cpp: In function ‘void bar()’:
u.cpp:17:1: error: unrecognizable insn:
 }
 ^
(insn 5 2 6 2 (set (reg:PTI 156)
(unspec:PTI [
(mem/v:TI (plus:DI (reg/f:DI 150 virtual-stack-vars)
(const_int 24 [0x18])) [-1  S16 A128])
] UNSPEC_LSQ)) u.cpp:15 -1
 (nil))
u.cpp:17:1: internal compiler error: in extract_insn, at recog.c:2343
0x109b11db _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/home/remote/msebor/fsf/gcc/trunk/gcc/rtl-error.c:110
0x109b1247 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/home/remote/msebor/fsf/gcc/trunk/gcc/rtl-error.c:118
0x10977b87 extract_insn(rtx_insn*)
/home/remote/msebor/fsf/gcc/trunk/gcc/recog.c:2343
0x106e0ddf instantiate_virtual_regs_in_insn
/home/remote/msebor/fsf/gcc/trunk/gcc/function.c:1598
0x106e0ddf instantiate_virtual_regs
/home/remote/msebor/fsf/gcc/trunk/gcc/function.c:1966
0x106e0ddf execute
/home/remote/msebor/fsf/gcc/trunk/gcc/function.c:2015
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug target/63805] ICE: in extract_insn, at recog.c:2327 with -mcpu=power8

[dimhen at gmail dot com]

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

--- Comment #3 from Dmitry G. Dyachenko  ---
(In reply to Dmitry G. Dyachenko from comment #2)
> I have similar error in LTO/x86_64, but stack is slightly different.

Its different issue (now PR64374)

Sorry for noise.

[Bug target/63805] ICE: in extract_insn, at recog.c:2327 with -mcpu=power8

[dimhen at gmail dot com]

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

--- Comment #2 from Dmitry G. Dyachenko  ---
I have similar error in LTO/x86_64, but stack is slightly different.

gcc-trunk r218991, binutils-trunk current

g++ -flto -o xx [6 files]. I'll try to reduce testcase.

TesterTest.cpp:422:1: internal compiler error: in extract_insn, at recog.c:2327
0xb230b8 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/home/dimhen/src/gcc_current/gcc/rtl-error.c:110
0xb23148 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/home/dimhen/src/gcc_current/gcc/rtl-error.c:118
0xad96f8 extract_insn(rtx_insn*)
/home/dimhen/src/gcc_current/gcc/recog.c:2327
0xad97a7 extract_insn_cached(rtx_insn*)
/home/dimhen/src/gcc_current/gcc/recog.c:2218
0x86f8c9 cleanup_subreg_operands(rtx_insn*)
/home/dimhen/src/gcc_current/gcc/final.c:3124
0xad51b9 split_insn
/home/dimhen/src/gcc_current/gcc/recog.c:2937
0xadd3ad split_all_insns()
/home/dimhen/src/gcc_current/gcc/recog.c:2991
0xadd4c8 rest_of_handle_split_after_reload
/home/dimhen/src/gcc_current/gcc/recog.c:3938
0xadd4c8 execute
/home/dimhen/src/gcc_current/gcc/recog.c:3967
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
lto-wrapper: fatal error: g++ returned 1 exit status
compilation terminated.
/usr/local/binutils_current/bin/ld: fatal error: lto-wrapper failed
collect2: error: ld returned 1 exit status

[Bug target/63805] ICE: in extract_insn, at recog.c:2327 with -mcpu=power8

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|4.8.5   |---

[Bug target/63805] ICE: in extract_insn, at recog.c:2327 with -mcpu=power8

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-11-10
   Target Milestone|--- |4.8.5
Summary|[4.9/4.8/5 Regression] ICE: |ICE: in extract_insn, at
   |in extract_insn, at |recog.c:2327 with
   |recog.c:2154 with   |-mcpu=power8
   |-mcpu=power8|
 Ever confirmed|0   |1

--- Comment #1 from Markus Trippelsdorf  ---
Not a regression, because it apparently never worked.