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