https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91518
--- Comment #4 from rguenther at suse dot de <rguenther at suse dot de> --- On Fri, 23 Aug 2019, luoxhu at cn dot ibm.com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91518 > > --- Comment #3 from Xiong Hu XS Luo <luoxhu at cn dot ibm.com> --- > (In reply to Richard Biener from comment #2) > > Not seen on x86_64. Given you bisected to r263875 it should appear with GCC > > 9 as well - are the actual GCC 9 releases also affected? > > > > I assume this is ppc64le. > > > > Unless we know more I assume this is a target issue. Please build with > > debug > > info and see where exactly and why it segfaults. > > Yes. It still fails on both power8 and power9 even on GCC 10 (gcc version > 10.0.0 20190823 (experimental) (GCC)). > Reset to r263875, the register content shown as below, Wrong address filled > for > lwzx instruction ($r8 is expected to be a valid address value): > > 140│ 0x00000000101a5718 <+552>: ld r12,888(r31) > 141│ 0x00000000101a571c <+556>: ld r0,856(r31) > 142│ 0x00000000101a5720 <+560>: ld r17,880(r31) > 143│ 0x00000000101a5724 <+564>: ld r8,848(r31) > 144│ 0x00000000101a5728 <+568>: addi r21,r21,1 > 145│ 0x00000000101a572c <+572>: cmpw cr7,r21,r30 > 146│ 0x00000000101a5730 <+576>: mulld r4,r3,r12 > 147│ 0x00000000101a5734 <+580>: add r18,r4,r0 > 148│ 0x00000000101a5738 <+584>: mulld r11,r18,r17 > 149├> 0x00000000101a573c <+588>: lwzx r3,r8,r11 > > 44: /x $r3 = 0x1 > 45: /x $r8 = 0x77 > 46: /x $r11 = 0x1770 > 47: /x $r18 = 0x7d > 48: /x $r17 = 0x30 > 49: /x $r4 = 0x1 > 50: /x $r0 = 0x7c > 51: /x $r3 = 0x1 > 52: /x $r12 = 0x1 > 53: /x $r21 = 0x2 > 54: /x $r8 = 0x77 > 55: /x $r17 = 0x30 > 56: /x $r0 = 0x7c > 57: /x $r12 = 0x1 > > I am not sure whether this is the debug info you needed? > function callstack is already pasted in #c0, as source code is not allowed to > be pasted, the segment fault place is in line 9375 of file mol.fppized.f90 of > function make_image_of_shell. Thanks. That's call get_shell_(self,sh,b); nb = sh%n_comp; lb = sh%l; call destroy_ptr_part_(sh) for me. Maybe you can edit the source to split this line at stmt boundaries and include assembly up to the previous/next call. I'm not familiar with power too much so you have to say which of r3, r8 or r11 is supposed to be the base address and trace it to where that goes wrong. As said I'm quite confident this is a target issue.
