From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27879 invoked by alias); 11 Dec 2018 09:04:59 -0000 Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org Received: (qmail 27866 invoked by uid 89); 11 Dec 2018 09:04:58 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=Ring, harmless, opening X-HELO: mail-lf1-f65.google.com Received: from mail-lf1-f65.google.com (HELO mail-lf1-f65.google.com) (209.85.167.65) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 11 Dec 2018 09:04:57 +0000 Received: by mail-lf1-f65.google.com with SMTP id a16so10194910lfg.3 for ; Tue, 11 Dec 2018 01:04:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=hqbwsAHgG99zqEudE5MatXXaApFpiTUXrM62L5Dey9A=; b=px1oM34lQptI7B074CvVcA4sEnb5GS9JnBEtGQCAoSTVv5P+ZUY0ixV4Y+eX97oAGM /CMec0EqM1V8glt4zkTZSb4wZapxJHEwr8r6PPdu/ZLkblWSYu4ph02ZHF7w7WNU8yrr wLQW74T7XoU92brelSsLA2J2LumIvOQQBD9x5oL7uIi10eZwSNweDtr0ly+KzsyFjGp/ N3MTI9KXwDwOG7/aEcYrIDquf0wjitEdcQLCKcuKbpamW4lvdvmJBGVJm3TcQGLTi+WH UW35SUxN8xIT0NMkS4qFeWUlTWeXxEf1ME8jw3i4Qb3padXwFvmA24t/YyzIHeV48L1u 7gXQ== MIME-Version: 1.0 References: In-Reply-To: From: Stefan Ring Date: Tue, 11 Dec 2018 17:37:00 -0000 Message-ID: Subject: Re: sysroot issue when cross-compiling a native compiler (gcc 7.3.0) To: gcc-help@gcc.gnu.org Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2018-12/txt/msg00027.txt.bz2 On Sat, Dec 8, 2018 at 11:26 AM Stefan Ring wrote: > On Sat, Dec 8, 2018 at 11:10 AM Stefan Ring wrote: > > On Sat, Dec 8, 2018 at 12:09 AM Stefan Ring 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.