From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 706 invoked by alias); 24 Oct 2002 16:09:55 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 696 invoked from network); 24 Oct 2002 16:09:54 -0000 Received: from unknown (HELO monsoon.nj.caldera.com) (68.52.213.60) by sources.redhat.com with SMTP; 24 Oct 2002 16:09:54 -0000 Received: by monsoon.nj.caldera.com (8.9.3/SCO5) id LAA25718; Thu, 24 Oct 2002 11:09:21 -0500 (CDT) Date: Thu, 24 Oct 2002 15:31:00 -0000 From: Robert Lipe To: Mark Mitchell Cc: "gcc@gcc.gnu.org" Subject: Re: 3.2 branch/openserver g++ test results looking bad Message-ID: <20021024160920.GC23898@rjlhome.caldera.com> Mail-Followup-To: Mark Mitchell , "gcc@gcc.gnu.org" References: <20021023175229.GJ5058@rjlhome.caldera.com> <24980000.1035445270@warlock.codesourcery.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <24980000.1035445270@warlock.codesourcery.com> User-Agent: Mutt/1.3.25i X-SW-Source: 2002-10/txt/msg01492.txt.bz2 Mark Mitchell wrote: > >3.0.4 didn't do this. You can argue that the assembler is being lame > >and I won't argue, but it'd be helpful to folks that use AT&T derived > >assemblers if we wouldn't torment them. > > > >Can anyone offer a hand on this? > > First, we need to get a high-priority PR open for this, if you want > me to notice. :-) I filed 8333 last night, based on the original text of this thread. > Perhaps you're getting burned by: > > #undef ASM_OUTPUT_EXTERNAL_LIBCALL > #define ASM_OUTPUT_EXTERNAL_LIBCALL(FILE, FUN) \ > if (TARGET_ELF) (*targetm.asm_out.globalize_label) (FILE, XSTR (FUN, 0)) > > (I'm just grepping around for globalization things that are in sco5.h > but not elsewhere...) Since TARGET_ELF is now a constant "1" and the provided definition is the same as the default, I don't *think* that's it, but it's an important clue. The source input can be reduced to the single line: float blah; This will compile as C and not as C++. I can't get a stack backtrace, but cc1plus calls both asm_output_aligned_bss which globalizes it and globalize_decl which globalizes it again. While I haven't built a Linux GCC, GAS tolerates this syntax, so I think it's just the AT&T assemblers being more grouchy about this sort of thing. > Set a breakpoint on default_globalize_label and see where the two > calls are coming from. Which exposes us to GDB not reading the Dwarf output. :-( Dwarf Error: Cannot handle DW_FORM_strp in DWARF reader. RJL