public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
* 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).