public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
* Re: init1.C failure under study
       [not found] <19971129112737.14113.cygnus.egcs@dgii.com>
@ 1997-11-30  3:17 ` Jason Merrill
  1997-11-30 20:14   ` Robert Lipe
  1997-11-30 22:31   ` Robert Lipe
  0 siblings, 2 replies; 4+ messages in thread
From: Jason Merrill @ 1997-11-30  3:17 UTC (permalink / raw)
  To: Robert Lipe, egcs

>>>>> Robert Lipe <robertl@dgii.com> writes:

> This test works on OpenServer ELF, but not COFF.   Whether this is
> something in the way sco5.h handles initializers, I can't tell.

> Can anyone offer good hints where to look?

Does defining HAVE_ATEXIT help?

Jason

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: init1.C failure under study
  1997-11-30  3:17 ` init1.C failure under study Jason Merrill
@ 1997-11-30 20:14   ` Robert Lipe
  1997-11-30 22:31   ` Robert Lipe
  1 sibling, 0 replies; 4+ messages in thread
From: Robert Lipe @ 1997-11-30 20:14 UTC (permalink / raw)
  To: Jason Merrill; +Cc: egcs

> > This test works on OpenServer ELF, but not COFF.   Whether this is
> > something in the way sco5.h handles initializers, I can't tell.
> 
> > Can anyone offer good hints where to look?
> 
> Does defining HAVE_ATEXIT help?

The problem isn't in the destructors.   The problem seems to be that
the constructors are never called.

RJL

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: init1.C failure under study
  1997-11-30  3:17 ` init1.C failure under study Jason Merrill
  1997-11-30 20:14   ` Robert Lipe
@ 1997-11-30 22:31   ` Robert Lipe
  1 sibling, 0 replies; 4+ messages in thread
From: Robert Lipe @ 1997-11-30 22:31 UTC (permalink / raw)
  To: Jason Merrill; +Cc: egcs

> > This test works on OpenServer ELF, but not COFF.   Whether this is
> > something in the way sco5.h handles initializers, I can't tell.

OK.  I've reduced the problem down to a one-line assembly source
change that seems to make sense.   I just can't find the place
in sco5.h (if it is even in sco5.h) that's mishandling this.

I've attached the assembly output of the previous example (I may 
have thrown in another printf or something).   The problem seems to 
be that it's pushing the address of a stupid little function that 
contains only prologue and epilogue for the ctor instead of the 
"real" one.

If you look at the end, you'll find that .init contains
	       pushl $_GLOBAL_.I.f__Fv
This does get called and the do_global_ctors handlers do ineed
call this function.  Unfortunately, this function is rather 
nonexciting, though it does point out an optimization opportunity.

_GLOBAL_.I.f__Fv:
        pushl %ebp
        movl %esp,%ebp
        movl %ebp,%esp
        popl %ebp
        ret

If I replace that pushl with a pushl for the address __tcf_0 (the 
function that seems to really contain the ctor) it passes the test.

Interestingly, the only reference to __tcf_0 is in an atexit (?!?!)
function, so that doesn't make any sense either.

My gut tells me that something in the coff/elf handling in sco5.h is
tripping up other things, but I just can't see how anything there
differs in any substantial way from what's in the similar svr[34].h
files...

Any clues?

Oh, Jason.   The presence of HAVE_ATEXIT doesn't seem to change
anything here...

RJL


	.file	"init1.C"
	.version	"01.01"
/ GNU C++ version egcs-2.90.19 971127 (gcc2-970802 experimental) (i586-pc-sco3.2v5.0.4) compiled by GNU C version egcs-2.90.19 971127 (gcc2-970802 experimental).
/ options passed:  -mcoff -O -fno-exceptions
/ options enabled:  -fdefer-pop -fthread-jumps -fpeephole -ffunction-cse
/ -finline -fkeep-static-consts -fpcc-struct-return -fsjlj-exceptions
/ -fcommon -fverbose-asm -fgnu-linker -falias-check -fargument-alias
/ -m80387 -mhard-float -mno-soft-float -mieee-fp -mfp-ret-in-387
/ -mschedule-prologue -mcoff -mcpu=pentium -march=pentium

gcc2_compiled.:
__gnu_compiled_cplusplus:
	.text
.LC0:
	.string	"Dtor\n"
.LC1:
	.string	" Ctor: Bump count to %d\n"
.LC2:
	.string	"Called f\n"
	.data
	.align 4
	.lcomm	a.6,1
	.align 4
	.lcomm	_.tmp_0.7,4
	.text
	.align 4
__tcf_0:
	pushl %ebp
	movl %esp,%ebp
	incl count
	movl count,%eax
	pushl %eax
	pushl $.LC1
	call printf
	movl %ebp,%esp
	popl %ebp
	ret
	.align 4
	.globl f__Fv
f__Fv:
	pushl %ebp
	movl %esp,%ebp
	pushl $.LC2
	call printf
	addl $4,%esp
	cmpl $0,_.tmp_0.7
	jne .L18
	movl $1,_.tmp_0.7
	pushl $__tcf_0
	call atexit
.L18:
	movl %ebp,%esp
	popl %ebp
	ret
.LC3:
	.string	"Construct  a\n"
	.data
	.align 4
	.lcomm	a.12,1
	.align 4
	.lcomm	_.tmp_1.13,4
	.text
	.align 4
__tcf_1:
	pushl %ebp
	movl %esp,%ebp
	incl count
	movl count,%eax
	pushl %eax
	pushl $.LC1
	call printf
	movl %ebp,%esp
	popl %ebp
	ret
	.align 4
	.globl g__Fv
g__Fv:
	pushl %ebp
	movl %esp,%ebp
	pushl $.LC3
	call printf
	addl $4,%esp
	cmpl $0,_.tmp_1.13
	jne .L27
	movl $1,_.tmp_1.13
	pushl $__tcf_1
	call atexit
.L27:
	movl %ebp,%esp
	popl %ebp
	ret
.LC4:
	.string	"main: pref\n"
.LC5:
	.string	"main: postf\n"
	.align 4
	.globl main
main:
	pushl %ebp
	movl %esp,%ebp
	pushl $.LC4
	call printf
	call f__Fv
	pushl $.LC5
	call printf
	xorl %eax,%eax
	movl %ebp,%esp
	popl %ebp
	ret
	.globl c
	.data
c:
	.set	.,.+1
	.text
	.align 4
	.globl _GLOBAL_.D.f__Fv
_GLOBAL_.D.f__Fv:
	pushl %ebp
	movl %esp,%ebp
	pushl $.LC0
	call printf
	addl $4,%esp
	cmpl $1,count
	je .L35
	pushl $1
	call _exit
	.align 4
.L35:
	movl %ebp,%esp
	popl %ebp
	ret
	.section	.fini, "x"
	.long	 _GLOBAL_.D.f__Fv
	.text
	.align 4
	.globl _GLOBAL_.I.f__Fv
_GLOBAL_.I.f__Fv:
	pushl %ebp
	movl %esp,%ebp
	movl %ebp,%esp
	popl %ebp
	ret
	.section	.init ,"x"
/	pushl $_GLOBAL_.I.f__Fv
	pushl $__tcf_0
	.globl count
	.data
	.align 4
count:
	.set	.,.+4
	.ident	"GCC: (GNU) egcs-2.90.19 971127 (gcc2-970802 experimental)"



#include <stdio.h>
extern "C" int      printf(const char *, ...);
int count;

extern "C" void _exit(int);

struct C {
	
  ~C() {printf("Dtor\n"); if (count != 1) _exit(1); }
} c;

class A {
public:
  ~A () { ++count; printf(" Ctor: Bump count to %d\n", count);}
};
void f() {
printf("Called f\n");
//  static A a;
static A a;
}

void g() {
  // Since this isn't constructed, we can't destruct it.
printf("Construct  a\n");
  static A a;
}

int main () {
	printf("main: pref\n");
  f();
	printf("main: postf\n");
}

^ permalink raw reply	[flat|nested] 4+ messages in thread

* init1.C failure under study
@ 1997-11-29  9:29 Robert Lipe
  0 siblings, 0 replies; 4+ messages in thread
From: Robert Lipe @ 1997-11-29  9:29 UTC (permalink / raw)
  To: egcs

This test works on OpenServer ELF, but not COFF.   Whether this is
something in the way sco5.h handles initializers, I can't tell.

If I remove the word 'static' in the function f, this test passes
under COFF.   It also makes more of a difference in the assembly
than I'd have guessed.   This is one of only two g++ tests (p2736.C
is the other)that fails in COFF that doesn't fail in ELF.

Are there any other x86 COFF targets represented on the list?

Can anyone offer good hints where to look?

I stated earlier that this started failing around 1101.    That
is incorrect.   I just fixed the test fixture on 1101 and the
earlier results were the ones that printed "-mcoff" on the headers
but never bothered to pass it down to GCC.  So this problem likely
has tenure. 

Thanx,
RJL


int count;

extern "C" void _exit(int);

struct C {
  ~C() { if (count != 1) _exit(1); }
} c;

class A {
public:
  ~A () { ++count; }
};

void f() {
  static A a;
}

void g() {
  // Since this isn't constructed, we can't destruct it.
  static A a;
}

int main () {
  f();
}


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~1997-11-30 22:31 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <19971129112737.14113.cygnus.egcs@dgii.com>
1997-11-30  3:17 ` init1.C failure under study Jason Merrill
1997-11-30 20:14   ` Robert Lipe
1997-11-30 22:31   ` Robert Lipe
1997-11-29  9:29 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).