From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26183 invoked by alias); 13 May 2014 21:41:54 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 26166 invoked by uid 89); 13 May 2014 21:41:54 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-we0-f178.google.com Received: from mail-we0-f178.google.com (HELO mail-we0-f178.google.com) (74.125.82.178) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Tue, 13 May 2014 21:41:53 +0000 Received: by mail-we0-f178.google.com with SMTP id u56so1009779wes.37 for ; Tue, 13 May 2014 14:41:50 -0700 (PDT) X-Received: by 10.180.7.198 with SMTP id l6mr22979451wia.52.1400017309982; Tue, 13 May 2014 14:41:49 -0700 (PDT) Received: from localhost ([2.26.169.52]) by mx.google.com with ESMTPSA id q9sm23775987wjo.3.2014.05.13.14.41.49 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 May 2014 14:41:49 -0700 (PDT) From: Richard Sandiford To: Sandra Loosemore Mail-Followup-To: Sandra Loosemore ,GCC Patches , rdsandiford@googlemail.com Cc: GCC Patches Subject: Re: [patch,mips] avoid invalid register for JALR References: <53727BC3.3060600@codesourcery.com> Date: Tue, 13 May 2014 21:41:00 -0000 In-Reply-To: <53727BC3.3060600@codesourcery.com> (Sandra Loosemore's message of "Tue, 13 May 2014 14:08:35 -0600") Message-ID: <87mwelcq5f.fsf@talisman.default> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2014-05/txt/msg01019.txt.bz2 Sandra Loosemore writes: > When I was trying to benchmark another patch (which I'll be sending > along shortly) with CSiBE for -mabi=64, I ran into an assembler error > like this: > > /tmp/ccJv2faG.s: Assembler messages: > /tmp/ccJv2faG.s:1605: Error: a destination register must be supplied > `jalr $31' JALR patterns should have an explicit clobber of $31, which I thought was also supposed to stop $31 from being used as the call address. E.g.: int foo (void) { typedef void (*type) (void); register type fn asm ("$31"); asm ("foo %0" : "=r" (fn)); fn (); return 1; } gives the expected shuffle: #APP # 5 "/tmp/foo.c" 1 foo $31 # 0 "" 2 #NO_APP move $2,$31 jalr $2 If you change the asm to some other random register then the JALR uses it directly. Do you have a testcase? > Indeed, GCC is generating invalid code here; the single-operand JALR > instruction doesn't permit the use of $31 because it is already the > implicit destination register. The attached patch introduces a new > register class JALR_REGS to represent the valid set of registers for > this instruction, and modifies the "c" register constraint to use it. > > I had some difficulty in regression-testing this patch because of > unrelated problems on trunk in the past week -- at first I was getting > ICEs due to a null pointer dereference in tree code, then when I tried > again a couple days later trunk was not even building. Could you give more details? Thanks, Richard