* 3.2 branch/openserver g++ test results looking bad
@ 2002-10-23 15:58 Robert Lipe
2002-10-24 9:21 ` Mark Mitchell
0 siblings, 1 reply; 5+ messages in thread
From: Robert Lipe @ 2002-10-23 15:58 UTC (permalink / raw)
To: gcc
[-- Attachment #1: Type: text/plain, Size: 1443 bytes --]
Once upon a time in the not terribly distant pass, GCC's testuite
results on OpenServer (i686-*-sco3.2v5*) were at approximate parity with
Linux on IA32. I've been a big slacker and haven't had my eye on it in
many months. I just cranked off a bootstrap and a testsuite run and
it's not looking good for G++.
The C language tests are basically in the game with 234 unexpected
failures. The G++ tests are still running, but by inspection of the
still-growing g++.log, it looks like the majority of the failures have
the same root:
/usr/tmp/blah.s:name already bound as global: blah
If I take the attached registers1.ii (derived from a random failing
testsuite entry) I'll see:
$ ./xgcc -c ./registers1.ii
/usr/tmp//ccG6WKmc.s:4:name already bound as global: float_src
/usr/tmp//ccG6WKmc.s:12:name already bound as global: float_dest
/usr/tmp//ccG6WKmc.s:19:name already bound as global: int_src
/usr/tmp//ccG6WKmc.s:26:name already bound as global: int_dest
Sure enough, it's emitting double .globl for C++ things.
(robertl) rjlhome:/play/negcs-3.2/gcc
$ head -5 registers1.s
.file "registers1.C"
.version "01.01"
.globl float_src
.globl float_src
.data
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?
Thanx,
RJL
[-- Attachment #2: registers1.ii --]
[-- Type: text/plain, Size: 3181 bytes --]
# 1 "/play/gcc-3.2/gcc/testsuite/g++.dg/eh/registers1.C"
# 1 "<built-in>"
# 1 "<command line>"
# 1 "/play/gcc-3.2/gcc/testsuite/g++.dg/eh/registers1.C"
extern "C" void exit(int);
extern "C" void abort();
# 15 "/play/gcc-3.2/gcc/testsuite/g++.dg/eh/registers1.C"
const int num_vars = 16;
const int depth = 3;
float float_src[num_vars * depth];
float float_dest[num_vars];
int int_src[num_vars * depth];
int int_dest[num_vars];
void foo (int level, int throw_to)
{
float *fsrc = &float_src[level * num_vars];
float f00 = *fsrc++ + 1.0f;
float f01 = *fsrc++ + 1.0f;
float f02 = *fsrc++ + 1.0f;
float f03 = *fsrc++ + 1.0f;
float f04 = *fsrc++ + 1.0f;
float f05 = *fsrc++ + 1.0f;
float f06 = *fsrc++ + 1.0f;
float f07 = *fsrc++ + 1.0f;
float f08 = *fsrc++ + 1.0f;
float f09 = *fsrc++ + 1.0f;
float f10 = *fsrc++ + 1.0f;
float f11 = *fsrc++ + 1.0f;
float f12 = *fsrc++ + 1.0f;
float f13 = *fsrc++ + 1.0f;
float f14 = *fsrc++ + 1.0f;
float f15 = *fsrc++ + 1.0f;
int *isrc = &int_src[level * num_vars];
int i00 = *isrc++ + 1;
int i01 = *isrc++ + 1;
int i02 = *isrc++ + 1;
int i03 = *isrc++ + 1;
int i04 = *isrc++ + 1;
int i05 = *isrc++ + 1;
int i06 = *isrc++ + 1;
int i07 = *isrc++ + 1;
int i08 = *isrc++ + 1;
int i09 = *isrc++ + 1;
int i10 = *isrc++ + 1;
int i11 = *isrc++ + 1;
int i12 = *isrc++ + 1;
int i13 = *isrc++ + 1;
int i14 = *isrc++ + 1;
int i15 = *isrc++ + 1;
try
{
if (level == 0)
throw throw_to;
else
foo (level - 1, throw_to);
}
catch (int i)
{
if (i == level)
{
float *fdest = float_dest;
*fdest++ = f00;
*fdest++ = f01;
*fdest++ = f02;
*fdest++ = f03;
*fdest++ = f04;
*fdest++ = f05;
*fdest++ = f06;
*fdest++ = f07;
*fdest++ = f08;
*fdest++ = f09;
*fdest++ = f10;
*fdest++ = f11;
*fdest++ = f12;
*fdest++ = f13;
*fdest++ = f14;
*fdest++ = f15;
int *idest = int_dest;
*idest++ = i00;
*idest++ = i01;
*idest++ = i02;
*idest++ = i03;
*idest++ = i04;
*idest++ = i05;
*idest++ = i06;
*idest++ = i07;
*idest++ = i08;
*idest++ = i09;
*idest++ = i10;
*idest++ = i11;
*idest++ = i12;
*idest++ = i13;
*idest++ = i14;
*idest++ = i15;
}
else
{
throw;
}
}
}
int main ()
{
for (int i = 0; i < depth * num_vars; i++)
{
int_src[i] = i * i;
float_src[i] = i * 2.0f;
}
for (int level = 0; level < depth; level++)
for (int throw_to = 0; throw_to <= level; throw_to++)
{
foo (level, throw_to);
float *fsrc = &float_src[throw_to * num_vars];
int *isrc = &int_src[throw_to * num_vars];
for (int i = 0; i < num_vars; i++)
{
if (int_dest[i] != isrc[i] + 1)
abort ();
if (float_dest[i] != fsrc[i] + 1.0f)
abort ();
}
}
exit (0);
}
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: 3.2 branch/openserver g++ test results looking bad
2002-10-23 15:58 3.2 branch/openserver g++ test results looking bad Robert Lipe
@ 2002-10-24 9:21 ` Mark Mitchell
2002-10-24 15:31 ` Robert Lipe
0 siblings, 1 reply; 5+ messages in thread
From: Mark Mitchell @ 2002-10-24 9:21 UTC (permalink / raw)
To: Robert Lipe, gcc
> 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. :-)
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...)
Set a breakpoint on default_globalize_label and see where the two
calls are coming from.
--
Mark Mitchell mark@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: 3.2 branch/openserver g++ test results looking bad
2002-10-24 9:21 ` Mark Mitchell
@ 2002-10-24 15:31 ` Robert Lipe
2002-10-24 15:52 ` Daniel Jacobowitz
2002-10-24 21:15 ` Robert Lipe
0 siblings, 2 replies; 5+ messages in thread
From: Robert Lipe @ 2002-10-24 15:31 UTC (permalink / raw)
To: Mark Mitchell; +Cc: gcc
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: 3.2 branch/openserver g++ test results looking bad
2002-10-24 15:31 ` Robert Lipe
@ 2002-10-24 15:52 ` Daniel Jacobowitz
2002-10-24 21:15 ` Robert Lipe
1 sibling, 0 replies; 5+ messages in thread
From: Daniel Jacobowitz @ 2002-10-24 15:52 UTC (permalink / raw)
To: Mark Mitchell, gcc
On Thu, Oct 24, 2002 at 11:09:20AM -0500, Robert Lipe wrote:
> > 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.
This is fixed in GDB 5.2.1, if I remember rightly...
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: 3.2 branch/openserver g++ test results looking bad
2002-10-24 15:31 ` Robert Lipe
2002-10-24 15:52 ` Daniel Jacobowitz
@ 2002-10-24 21:15 ` Robert Lipe
1 sibling, 0 replies; 5+ messages in thread
From: Robert Lipe @ 2002-10-24 21:15 UTC (permalink / raw)
To: gcc
Armed with Mark's hint, GDB will play nice again.
> > Set a breakpoint on default_globalize_label and see where the two
> > calls are coming from.
The two globalizations for the same symbol are happening here:
(gdb) where
#0 globalize_decl (decl=0x856e2a0) at /play/gcc-3.2/gcc/varasm.c:5128
#1 0x08311b2e in asm_emit_uninitialised (decl=0x856e2a0,
name=0x8554ce9 "blah", size=4, rounded=16)
at /play/gcc-3.2/gcc/varasm.c:1402
#2 0x083120cb in assemble_variable (decl=0x856e2a0, top_level=1, at_end=0,
dont_output_data=0) at /play/gcc-3.2/gcc/varasm.c:1628
#3 0x082feb34 in rest_of_decl_compilation (decl=0x856e2a0, asmspec=0x0,
top_level=1, at_end=0) at /play/gcc-3.2/gcc/toplev.c:2280
#4 0x08064094 in make_rtl_for_nonlocal_decl (decl=0x856e2a0, init=0x0,
asmspec=0x0) at /play/gcc-3.2/gcc/cp/decl.c:8014
#5 0x08064928 in cp_finish_decl (decl=0x856e2a0, init=0x0, asmspec_tree=0x0,
flags=0) at /play/gcc-3.2/gcc/cp/decl.c:8312
#6 0x080a7350 in parse_end_decl (decl=0x856e2a0, init=0x0, asmspec=0x0)
at parse.y:162
#7 0x080ad1c1 in yyparse_1 () at parse.y:2128
#8 0x080f968f in yyparse () at /play/gcc-3.2/gcc/c-lex.c:164
#9 0x082fe83f in compile_file () at /play/gcc-3.2/gcc/toplev.c:2124
#10 0x08303c19 in do_compile () at /play/gcc-3.2/gcc/toplev.c:5215
#11 0x08303c7b in toplev_main (argc=2, argv=0x8047a34)
at /play/gcc-3.2/gcc/toplev.c:5247
#12 0x080fb465 in main (argc=2, argv=0x8047a34) at /play/gcc-3.2/gcc/main.c:35
#13 0x0804971b in _start ()
and here:
Breakpoint 5, asm_output_aligned_bss (file=0x84df2a8, decl=0x856e2a0,
name=0x8554ce9 "blah", size=4, align=32) at /play/gcc-3.2/gcc/varasm.c:538
538 ASM_GLOBALIZE_LABEL (file, name);
(gdb) where
#0 asm_output_aligned_bss (file=0x84df2a8, decl=0x856e2a0,
name=0x8554ce9 "blah", size=4, align=32) at /play/gcc-3.2/gcc/varasm.c:538
#1 0x08311b9c in asm_emit_uninitialised (decl=0x856e2a0,
name=0x8554ce9 "blah", size=4, rounded=16)
at /play/gcc-3.2/gcc/varasm.c:1433
#2 0x083120cb in assemble_variable (decl=0x856e2a0, top_level=1, at_end=0,
dont_output_data=0) at /play/gcc-3.2/gcc/varasm.c:1628
#3 0x082feb34 in rest_of_decl_compilation (decl=0x856e2a0, asmspec=0x0,
top_level=1, at_end=0) at /play/gcc-3.2/gcc/toplev.c:2280
#4 0x08064094 in make_rtl_for_nonlocal_decl (decl=0x856e2a0, init=0x0,
asmspec=0x0) at /play/gcc-3.2/gcc/cp/decl.c:8014
#5 0x08064928 in cp_finish_decl (decl=0x856e2a0, init=0x0, asmspec_tree=0x0,
flags=0) at /play/gcc-3.2/gcc/cp/decl.c:8312
#6 0x080a7350 in parse_end_decl (decl=0x856e2a0, init=0x0, asmspec=0x0)
at parse.y:162
#7 0x080ad1c1 in yyparse_1 () at parse.y:2128
#8 0x080f968f in yyparse () at /play/gcc-3.2/gcc/c-lex.c:164
#9 0x082fe83f in compile_file () at /play/gcc-3.2/gcc/toplev.c:2124
#10 0x08303c19 in do_compile () at /play/gcc-3.2/gcc/toplev.c:5215
#11 0x08303c7b in toplev_main (argc=2, argv=0x8047a34)
at /play/gcc-3.2/gcc/toplev.c:5247
#12 0x080fb465 in main (argc=2, argv=0x8047a34) at /play/gcc-3.2/gcc/main.c:35
#13 0x0804971b in _start ()
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2002-10-24 18:39 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-10-23 15:58 3.2 branch/openserver g++ test results looking bad Robert Lipe
2002-10-24 9:21 ` Mark Mitchell
2002-10-24 15:31 ` Robert Lipe
2002-10-24 15:52 ` Daniel Jacobowitz
2002-10-24 21:15 ` Robert Lipe
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).