From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29943 invoked by alias); 5 Feb 2002 17:24:51 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 29853 invoked from network); 5 Feb 2002 17:24:48 -0000 Received: from unknown (HELO potter.sfbay.redhat.com) (209.249.29.60) by sources.redhat.com with SMTP; 5 Feb 2002 17:24:48 -0000 Received: from dot.sfbay.redhat.com (dot.sfbay.redhat.com [205.180.230.224]) by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id g15HKTP17715; Tue, 5 Feb 2002 09:20:30 -0800 Received: (from rth@localhost) by dot.sfbay.redhat.com (8.11.6/8.11.6) id g15HOc419921; Tue, 5 Feb 2002 09:24:38 -0800 X-Authentication-Warning: dot.sfbay.redhat.com: rth set sender to rth@redhat.com using -f Date: Tue, 05 Feb 2002 09:32:00 -0000 From: Richard Henderson To: Jan Hubicka Cc: law@redhat.com, John David Anglin , gcc-bugs@gcc.gnu.org, gcc-patches@gcc.gnu.org Subject: Re: PATCH: Re: ICE in 920624-1.c with -O3 -funroll-loops on vax-dec-ultrix4.3 Message-ID: <20020205092437.A19915@redhat.com> Mail-Followup-To: Richard Henderson , Jan Hubicka , law@redhat.com, John David Anglin , gcc-bugs@gcc.gnu.org, gcc-patches@gcc.gnu.org References: <20020204164731.A19099@redhat.com> <13368.1012879798@porcupine.cygnus.com> <20020204215518.A19374@redhat.com> <20020205124050.GR17128@atrey.karlin.mff.cuni.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020205124050.GR17128@atrey.karlin.mff.cuni.cz>; from jh@suse.cz on Tue, Feb 05, 2002 at 01:40:50PM +0100 X-SW-Source: 2002-02/txt/msg00395.txt.bz2 On Tue, Feb 05, 2002 at 01:40:50PM +0100, Jan Hubicka wrote: > Perhaps using symbol_ref is just fine. For calls we also do use > symbol refs to addresses inside code segment. And on thouse troublesome ports we have ENCODE_SECTION_INFO to set e.g. SYMBOL_REF_FLAG to indicate a code segment address. >From whence would you call ENCODE_SECTION_INFO from this? Of course, don't get me started on how SYMBOL_REF should be cleaned up as well. r~