From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16729 invoked by alias); 1 Feb 2005 08:07:33 -0000 Mailing-List: contact binutils-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sources.redhat.com Received: (qmail 15565 invoked from network); 1 Feb 2005 08:06:21 -0000 Received: from unknown (HELO emea1-mh.id2.novell.com) (195.33.99.129) by sourceware.org with SMTP; 1 Feb 2005 08:06:21 -0000 Received: from EMEA1-MTA by emea1-mh.id2.novell.com with Novell_GroupWise; Tue, 01 Feb 2005 08:06:21 +0100 Message-Id: Date: Tue, 01 Feb 2005 08:07:00 -0000 From: "Jan Beulich" To: Cc: Subject: Re: [PATCH] ia64: accept alternative forms of .pred.rel Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SW-Source: 2005-02/txt/msg00021.txt.bz2 >>> James E Wilson 31.01.05 21:48:41 >>> >On Mon, 2005-01-31 at 08:32, Jan Beulich wrote: >> Change to allow ias forms of .pred.rel (with @-prefixed designators). > >Neither the Intel Assembly Language Reference Guide nor the Intel >Assembler User's Guide mentions this syntax. Where did it come from? >We already have two supported syntaxes. Do we really need a third one? >I do agree that using @ operators here makes sense though, as it makes >it more similar to how other directives work, but I'd like to know more >about why we need it. I assume this is because these are rather aged; at least I haven't been able to find recent copies anywhere. These alternative syntaxes where added fairly late in the Itanium1 time frame I believe (and obviously for exactly the sake of consistency), and but I don't recall how I learned about them (perhaps release notes). In any case I would think one could check with their assembler sources, but the simple observation that ias accepts these speaks for itself, I guess. >Otherwise, this looks OK. I'll wait for your final agreement to commit based on the above. >> Also >> eliminate a memory leak in the original code dealing with the quoted >> form. > >There are 3 places that call demand_copy_C_string, and only one calls >obstack_free afterwards. The other one is much harder to fix though. >Curiously, I see that tc-ia64.c is not the only config file that calls >demand_copy_C_string, but it is the only one calling obstack_free >afterwards. It does look like the right thing to do though. Yes, I saw one other, more difficult to fix place immediately, too. And I thought of grepping for similar instances, but at this point I didn't do so. I may at some point, and then also check for (less likely) demand_copy_string uses. Jan