From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-patches-return-315472-listarch-gcc-patches=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 23971 invoked by alias); 22 Mar 2012 18:55:26 -0000
Received: (qmail 23956 invoked by uid 22791); 22 Mar 2012 18:55:23 -0000
X-SWARE-Spam-Status: No, hits=-1.9 required=5.0	tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,T_RP_MATCHES_RCVD
X-Spam-Check-By: sourceware.org
Received: from qmta10.westchester.pa.mail.comcast.net (HELO qmta10.westchester.pa.mail.comcast.net) (76.96.62.17)    by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 22 Mar 2012 18:55:10 +0000
Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59])	by qmta10.westchester.pa.mail.comcast.net with comcast	id oiq11i00A1GhbT85AivAhd; Thu, 22 Mar 2012 18:55:10 +0000
Received: from up.mrs.kithrup.com ([24.4.193.8])	by omta07.westchester.pa.mail.comcast.net with comcast	id oiv81i00P0BKwT43Tiv9vN; Thu, 22 Mar 2012 18:55:10 +0000
Subject: Re: remove wrong code in immed_double_const
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Mike Stump <mikestump@comcast.net>
In-Reply-To: <Pine.LNX.4.64.1203221444100.25409@wotan.suse.de>
Date: Thu, 22 Mar 2012 18:55:00 -0000
Cc: Richard Sandiford <rdsandiford@googlemail.com>, gcc-patches Patches <gcc-patches@gcc.gnu.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <D5CBD1ED-20C5-429D-A635-C8C7FC315B02@comcast.net>
References: <5FF5A724-3FE1-4E97-8124-542A0B8259FE@comcast.net> <87obrvd6fh.fsf@talisman.home> <C52AA600-299B-4E1F-9855-D1612FF2EC0B@comcast.net> <87haxmgqoo.fsf@talisman.home> <7C6A7462-C1D3-4765-83FF-3B3C726D92E5@comcast.net> <8762e09sgc.fsf@talisman.home> <0A5CBD0C-FC94-4637-B230-1A83372DE91A@comcast.net> <CAFiYyc1Yn8nvfqxwYQKhoBATG=QJg+tvWRK2aa1LTdY3+oHSkw@mail.gmail.com> <g44ntjh7hx.fsf@richards-thinkpad.stglab.manchester.uk.ibm.com> <CAFiYyc0dSZU5ZfSxHRc493rs1jeXY1PTdi=QHCoMtKgZnTdRvA@mail.gmail.com> <g4zkbbfofy.fsf@richards-thinkpad.stglab.manchester.uk.ibm.com> <B5BB677F-55F7-41F3-92A6-60B1D9577426@comcast.net> <g4obrqf5zm.fsf@richards-thinkpad.stglab.manchester.uk.ibm.com> <DF6339D4-BFF6-45FA-A5E0-8141F0BD4199@comcast.net> <Pine.LNX.4.64.1203221444100.25409@wotan.suse.de>
To: Michael Matz <matz@suse.de>
X-IsSubscribed: yes
Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-patches.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-patches/>
List-Post: <mailto:gcc-patches@gcc.gnu.org>
List-Help: <mailto:gcc-patches-help@gcc.gnu.org>
Sender: gcc-patches-owner@gcc.gnu.org
X-SW-Source: 2012-03/txt/msg01531.txt.bz2

On Mar 22, 2012, at 7:12 AM, Michael Matz wrote:
> I see that you didn't remove the assert as part of this patch.

I'll include that in my next patch.

> I'd like  to see what you like to do to this routine once the rest goes i=
n.  In=20
> particular I don't think just removing the assert will be enough, at the=
=20
> very least the block comment should be saying something about what the=20
> routine exactly does (or doesn't do) for modes where the two HWI argument=
s=20
> can't specify all bits.

I think the best approach is to refine the spec:

/* Return a CONST_DOUBLE or CONST_INT for a value specified as a pair=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20
   of ints: I0 is the low-order word and I1 is the high-order word.=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20
   The value is a signed value, with the high bit of i1 being the sign=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20
   bit.  Do not use this routine for non-integer modes; convert to=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20
   REAL_VALUE_TYPE and use CONST_DOUBLE_FROM_REAL_VALUE.  */

I think this then exactly matches CONST_DOUBLE semantics.