From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6235 invoked by alias); 16 Oct 2002 16:28:40 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 6227 invoked from network); 16 Oct 2002 16:28:39 -0000 Received: from unknown (HELO mx2.redhat.com) (12.150.115.133) by sources.redhat.com with SMTP; 16 Oct 2002 16:28:39 -0000 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.11.6/8.11.6) with ESMTP id g9GGRts20833; Wed, 16 Oct 2002 12:27:55 -0400 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx2.corp.redhat.com (8.11.6/8.11.6) with ESMTP id g9GGSbl14944; Wed, 16 Oct 2002 12:28:37 -0400 Received: from tonopah.toronto.redhat.com (tonopah.toronto.redhat.com [172.16.14.91]) by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id g9GGSXD05716; Wed, 16 Oct 2002 09:28:33 -0700 Received: (from wilson@localhost) by tonopah.toronto.redhat.com (8.11.6/8.11.6) id g9GGSWY08533; Wed, 16 Oct 2002 12:28:32 -0400 X-Authentication-Warning: tonopah.toronto.redhat.com: wilson set sender to wilson@redhat.com using -f To: "Maciej W. Rozycki" Cc: Daniel Jacobowitz , gcc@gcc.gnu.org, binutils@sources.redhat.com Subject: Re: MIPS gas relaxation still doesn't work References: From: Jim Wilson Date: Wed, 16 Oct 2002 10:37:00 -0000 In-Reply-To: Message-ID: User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-10/txt/msg00965.txt.bz2 > The tough problems I've noticed so far is the small limit >on the number of constraints, which is only ten This should be fixed as of gcc-3.1, since you can have named operands now. Taking an example from the gcc docs: asm ("cmoveq %1,%2,%[result]" : [result] "=r"(result) : "r" (test), "r"(new), "[result]"(old)); > and the unability to pass >a machine address, as the "R" constraint, which is expected to provide the >function, doesn't work here and the "m" and "o" ones may require a macro >expansion. I'm not sure exactly what problem you are trying to report here, but I think it is likely true that we will need new constraint codes. Previously we didn't need special constraint codes for asms because everyone relied on the assembler macros for loads. Now that we want to get people to stop using assembler macros, we may need to add special constraint codes so that people can write the asms that they need. Jim