http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59350 --- Comment #32 from David Binderman --- Same error with gcc trunk, dated 20131215, for attached source code. Flags -O3 -g -fPIC -fstack-protector-strong required. [dcb@zippy4 foundBugs]$ ../results/bin/gcc -c -O3 -g -fPIC -fstack-protector-strong bug126.c zprime.c: In function ‘zfactor’: zprime.c:577:1: internal compiler error: in vt_expand_var_loc_chain, at var-tracking.c:8213 0xd1b1d0 vt_expand_var_loc_chain ../../src/trunk/gcc/var-tracking.c:8213 0xd1b5c7 vt_expand_loc_callback ../../src/trunk/gcc/var-tracking.c:8409 0x6d44de cselib_expand_value_rtx_1 ../../src/trunk/gcc/cselib.c:1684 0x6d44de cselib_expand_value_rtx_cb(rtx_def*, bitmap_head*, int, rtx_def* (*)(rtx_def*, bitmap_head*, int, void*), void*) ../../src/trunk/gcc/cselib.c:1531 ... >From gcc-bugs-return-437839-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Dec 17 13:08:15 2013 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 10468 invoked by alias); 17 Dec 2013 13:08:15 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Delivered-To: mailing list gcc-bugs@gcc.gnu.org Received: (qmail 10421 invoked by uid 48); 17 Dec 2013 13:08:11 -0000 From: "rearnsha at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug rtl-optimization/59535] [4.9 regression] -Os code size regressions for Thumb1/Thumb2 with LRA Date: Tue, 17 Dec 2013 13:08:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: rtl-optimization X-Bugzilla-Version: 4.9.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: rearnsha at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: attachments.created Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2013-12/txt/msg01494.txt.bz2 Content-length: 1705 http://gcc.gnu.org/bugzilla/show_bug.cgi?idY535 --- Comment #6 from Richard Earnshaw --- Created attachment 31457 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id1457&actioníit Another testcase Another testcase, but this one has some obvious examples of poor behaviour for -Os. In addtion to the options used on the previous case, this might need -fno-strict-aliasing -fno-common -fomit-frame-pointer -fno-strength-reduce Example one, spilling a value and then keeping a copy in a hard reg over a call. mov r5, r1 <= R1 copied to R5 sub sp, sp, #28 str r1, [sp, #8] <= And spilled to the stack mov r2, #12 mov r1, #0 mov r4, r0 bl memset mov r3, #2 mov r2, r5 <= Could reload from the stack instead Example two, use of multiple reloads to use high register: ldr r3, [sp, #4] mov ip, r3 <= Copying value into high register add ip, ip, r5 <= Arithmetic mov r3, ip <= Copying result back to original register str r3, [sp, #4] ldr r3, [sp, #12] mov ip, r3 <= And IP is dead anyway... In this case, mov ip, r3 add ip, ip, r5 mov r3, ip can be replaced entirely with add r3, r5 saving two completely unnecessary MOV instructions. Third, related case, mov r1, #12 mov ip, r1 add ip, ip, r4 mov r1, ip Could be done either as mov r1, #12 add r1, r4 mov ip, r1 or mov r1, r4 add r1, #12 mov ip, r1 both saving one instruction, or even two if the value doesn't really need copying to a high reg.