On Sat, Dec 8, 2018 at 11:26 AM Stefan Ring <stefanrin@xxxxxxxxx> wrote:
> On Sat, Dec 8, 2018 at 11:10 AM Stefan Ring <stefanrin@xxxxxxxxx> wrote:
> > On Sat, Dec 8, 2018 at 12:09 AM Stefan Ring <stefanrin@xxxxxxxxx> wrote:
> > $ ~/gcc8/bin/g++ -x c++ x.c
> > during IPA pass: inline
> > x.c:13:1: internal compiler error: in inline_small_functions, at
> > ipa-inline.c:1865
> > }
>
> This is only partially the compiler's fault. I noticed that it worked
> fine on an arm64 machine chrooted into the armv5 environment and
> remembered that /proc/cpu/alignment (used to?) default to 0 on Fedora
> ARM, causing misaligned accesses to produce garbage. It works after
> activating mis-alignment fixup (setting the value to 2). But this
> means that gcc version 8 has introduced some unaligned accesses
> lurking somewhere in its code.
This seems to be a stack alignment issue. The last ldrd instruction traps.
Dump of assembler code for function
cgraph_node::create_edge(cgraph_node*, gcall*, profile_count):
0x00398e64 <+0>: sub sp, sp, #8
0x00398e68 <+4>: push {r4, r5, r6, r7, r8, lr}
0x00398e6c <+8>: sub sp, sp, #24
0x00398e70 <+12>: str r3, [sp, #3280068] ; 0x34
0x00398e74 <+16>: ldrd r6, [sp, #52] ; 0x34
All of the sp manipulations leading up to the ldrd instruction work on
multiples of 8, which 52 is not. So the function will only work if the
stack is _not_ aligned to 8 bytes at function entry, which is rather
strange. This is not just a consequence of my exotic cross build
setup, but happens in the exact same way with a native build in the
Fedora armv5 chroot with only harmless configure arguments:
--build=armv5tel-unknown-linux-gnueabi --prefix=$HOME/gcc8
--enable-languages=c,c++ --with-arch=armv5te --with-mode=arm
--disable-nls. I think it's almost time for opening a bug report. I
will check how armv7 hardfp behaves before doing that.
