From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3878 invoked by alias); 31 Oct 2007 15:55:22 -0000 Received: (qmail 3857 invoked by uid 22791); 31 Oct 2007 15:55:20 -0000 X-Spam-Check-By: sourceware.org Received: from mtagate5.de.ibm.com (HELO mtagate5.de.ibm.com) (195.212.29.154) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 31 Oct 2007 15:55:18 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate5.de.ibm.com (8.13.8/8.13.8) with ESMTP id l9VFtF0m305474 for ; Wed, 31 Oct 2007 15:55:15 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v8.5) with ESMTP id l9VFtFBi2257100 for ; Wed, 31 Oct 2007 16:55:15 +0100 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l9VFtEMC032675 for ; Wed, 31 Oct 2007 16:55:14 +0100 Received: from lc4eb0107015440.ibm.com (dyn-9-152-216-52.boeblingen.de.ibm.com [9.152.216.52]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with SMTP id l9VFtDP0032652; Wed, 31 Oct 2007 16:55:13 +0100 Received: by lc4eb0107015440.ibm.com (sSMTP sendmail emulation); Wed, 31 Oct 2007 16:54:00 +0100 From: "Andreas Krebbel" Date: Wed, 31 Oct 2007 17:22:00 -0000 To: Tom Tromey Cc: gcc-patches@gcc.gnu.org Subject: Re: [PING] Target hook for rewriting inline asm constraints Message-ID: <20071031155400.GA13083@homer.boeblingen.de.ibm.com> References: <20071030115424.GA6864@homer.boeblingen.de.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i 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 X-SW-Source: 2007-10/txt/msg01885.txt.bz2 Hi, > I'm not an FE or ME maintainer but I took a look anyway. Thanks! > Wouldn't the C++ FE need a similar patch? And, if so, why do this > work in the front ends rather than somewhere more generic? Yes, the C++ FE also needs to call that hook. I've focused on C with my first patch since this is the most obvious user of inline assemblies, but you are right this has to be extended. I've tried at first to implement this as a more generic hook in the middle end, but dealing with this in recog and reload turned out to be way more complicated. > Or, if the > FE is really the way to go, perhaps a helper function in c-common.c > would be better. Ok that might be a good idea. > I saw a few coding standard violations in the code. > > * Repeated use of strlen in the loop (use an output index) Ok. > * Assignments in conditional expressions (frowned on by GNU standards; > in any case the comma operators seemed gratuitous to me) > * No braces around body of do-while. I've simply copied the loop reload and recog are using. See find_reloads and constrain_operands. I wasn't aware that this isn't considered good style. I can certainly change that. > * Hard-coded lengths without bounds checking (this one is questionable > I suppose) It would be difficult to harden that code against back end hooks returning huge strings. I'm not sure thats worth the effort. But I'll try to address this. Bye, -Andreas-