From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-95106-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 31263 invoked by alias); 29 Apr 2004 16:19:57 -0000
Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
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
Received: (qmail 31234 invoked from network); 29 Apr 2004 16:19:56 -0000
Received: from unknown (HELO NUTMEG.CAM.ARTIMI.COM) (217.40.111.177)
  by sources.redhat.com with SMTP; 29 Apr 2004 16:19:56 -0000
Received: from mace ([192.168.1.25]) by NUTMEG.CAM.ARTIMI.COM with Microsoft SMTPSVC(6.0.3790.0);
	 Thu, 29 Apr 2004 17:18:25 +0100
From: "Dave Korn" <dk@artimi.com>
To: <gcc@gcc.gnu.org>
Subject: RE: ACATS
Date: Thu, 29 Apr 2004 18:32:00 -0000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
In-Reply-To: <200404290958.47622.john@johnrshannon.com>
Message-ID: <NUTMEGPuYnYJbXmZoGA000000ca@NUTMEG.CAM.ARTIMI.COM>
X-OriginalArrivalTime: 29 Apr 2004 16:18:25.0703 (UTC) FILETIME=[996DA370:01C42E05]
X-SW-Source: 2004-04/txt/msg01396.txt.bz2

> -----Original Message-----
> From: gcc-owner On Behalf Of John R. Shannon
> Sent: 29 April 2004 16:59

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Thank you. I have a case of '.L124' being reference where it 
> should be '.L123'.


  Ouch.  Grep the source for ASM_OUTPUT_INTERNAL_LABEL where the second
parameter is "L", and you'll see that these are generated in final_scan_insn
in final.c, using CODE_LABEL_NUMBER (insn).  However defaults.h also
implements default definitions of ASM_OUTPUT_ADDR_VEC_ELT and
ASM_OUTPUT_DEBUG_LABEL from ASM_OUTPUT_INTERNAL_LABEL.  So your problem may
be specifically related either to switch....case constructs, or to debug
info, or your problem may be more generic.  What's actually at .L123 ?

  The problem seems likely to be that either the CODE_LABEL_NUMBER field of
the insn is getting stomped on, or something is damaging the operand of the
reference in the label_ref.  It might become clear which by following the
rtl dumps through the various stages; or it might be something you can
locate easily by setting a watchpoint or two with gdb.  I'd suspect
something going wrong when insns get deleted, myself.



    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....