* 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).