Re: 3.2 branch/openserver g++ test results looking bad

[Robert Lipe <robertlipe at usa dot net>]

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