From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-155275-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 10792 invoked by alias); 13 Jul 2009 08:23:51 -0000
Received: (qmail 10780 invoked by uid 22791); 13 Jul 2009 08:23:50 -0000
X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 	tests=AWL,BAYES_00,SARE_MSGID_LONG40,SPF_PASS
X-Spam-Check-By: sourceware.org
Received: from mail-vw0-f198.google.com (HELO mail-vw0-f198.google.com) (209.85.212.198)     by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 13 Jul 2009 08:23:43 +0000
Received: by vwj36 with SMTP id 36so1700615vwj.0         for <gcc@gcc.gnu.org>; Mon, 13 Jul 2009 01:23:41 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.220.98.17 with SMTP id o17mr6693313vcn.86.1247473421868; Mon,  	13 Jul 2009 01:23:41 -0700 (PDT)
In-Reply-To: <4A5AF0C4.4050300@gmail.com>
References: <20090712194138.GA9466@bromo.med.uc.edu> 	 <84fc9c000907121255ye67ec82ld8d23aff790157f@mail.gmail.com> 	 <4A5A8563.2070100@gmail.com> <20090713033940.GA16166@bromo.med.uc.edu> 	 <84fc9c000907130032k93fd677o21f6e0ffa5ea62fc@mail.gmail.com> 	 <4A5AF0C4.4050300@gmail.com>
Date: Mon, 13 Jul 2009 08:23:00 -0000
Message-ID: <84fc9c000907130123qaf2ef17he08b6bc5caacef15@mail.gmail.com>
Subject: Re: FAIL: gcc.c-torture/compile/20000804-1.c -O0 with PIC on  	gcc-4_4-branch
From: Richard Guenther <richard.guenther@gmail.com>
To: Dave Korn <dave.korn.cygwin@googlemail.com>
Cc: Jack Howarth <howarth@bromo.med.uc.edu>, gcc@gcc.gnu.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-IsSubscribed: yes
Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc/>
List-Post: <mailto:gcc@gcc.gnu.org>
List-Help: <http://gcc.gnu.org/ml/>
Sender: gcc-owner@gcc.gnu.org
X-SW-Source: 2009-07/txt/msg00215.txt.bz2

On Mon, Jul 13, 2009 at 10:31 AM, Dave
Korn<dave.korn.cygwin@googlemail.com> wrote:
> Richard Guenther wrote:
>> On Mon, Jul 13, 2009 at 5:39 AM, Jack Howarth<howarth@bromo.med.uc.edu> =
wrote:
>>> On Mon, Jul 13, 2009 at 01:52:51AM +0100, Dave Korn wrote:
>
>>>>> __complex__ long long f ()
>>>>> {
>>>>> =A0 int i[99];
>>>>> =A0 __complex__ long long v;
>>>>>
>>>>> =A0 v +=3D f ();
>>>> =A0 Undefined behaviour, no?
>>>>
>>>> =A0 =A0 cheers,
>>>> =A0 =A0 =A0 DaveK
>>> So then the testcase is flawed and should have the darwin line correcte=
d to...
>>>
>>> /* { dg-skip-if "PIC default" { { i?86-*-darwin* x86_64-*-darwin* } && =
ilp32 } =A0{ "*" } { "" } } */
>>
>> Probably yes. =A0The testcase invokes undefined behavior because
>> v is used uninitialized - but that may be the trigger for the original
>> ICE, so better preserve that.
>
> =A0It would be useful as an experiment to try initialising it and see if =
that's
> also what's triggering the reload failure in this particular case, becaus=
e if
> not then there's still a real bug to find on darwin.

I don't think so.  On 32bit

  asm("": "+r" (v) : "r" (0), "r" (1));

needs too many registers (4 for the v, 1 for constant 0 and 1 for
constant 1).  That's not possible with a frame-pointer and a PIC
register.

Richard.