From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6564 invoked by alias); 7 Mar 2007 10:27:49 -0000 Received: (qmail 6555 invoked by uid 22791); 7 Mar 2007 10:27:48 -0000 X-Spam-Check-By: sourceware.org Received: from Unknown (HELO elsdt-spawn.arc.com) (194.202.198.226) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 07 Mar 2007 10:26:31 +0000 Received: from elsdt-spawn.arc.com (localhost.localdomain [127.0.0.1]) by elsdt-spawn.arc.com (8.12.11.20060308/8.12.11) with ESMTP id l27AQIFi017439 for ; Wed, 7 Mar 2007 10:26:18 GMT Received: (from joernr@localhost) by elsdt-spawn.arc.com (8.12.11.20060308/8.12.11/Submit) id l27AQIgM017437 for cgen@sources.redhat.com; Wed, 7 Mar 2007 10:26:18 GMT Date: Wed, 07 Mar 2007 10:27:00 -0000 From: Joern Rennecke To: cgen@sources.redhat.com Subject: define-hardware, abs, and modes Message-ID: <20070307102618.GA17077@elsdt-spawn.arc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Mailing-List: contact cgen-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cgen-owner@sourceware.org X-SW-Source: 2007-q1/txt/msg00064.txt.bz2 I've found that an 'abs' instruction using the 'abs' rtl code didn't actually compute the absolute value. Looking at the generated C code, I found that the expression inside the ABSSI macro was unsigned, and the ABSSI macro assumes that the expression is signed. The expression was generated from a normal operand, which indexes a register set by an instruction field. The registe rset was defined with define-hardware using the mode SI. However, it had a special get function, which had a (case SI index ... construct. One of the cases uses h-pc. It turns out that h-pc translates into an unsigned variable, and the generated does not actually use the declared modes. Once the problem was known, I could work around it by assigning the operand to a temporary variable with the proper mode first; but I don't think that you should be required to do this. Having abs of an SI value not compute the absolute value is certainly unexpected. Do you thing the GET macro generated for the register is at fault for yielding a value with a type not consistent with the declared mode, the ABSSI macro for not casting its input to be signed first, or both?