disturbing g++ 971031 results. defer-pop to blame?

[Robert Lipe]

[ re: new? failures on i586-pc-sco3.2v5.0.4 ] 
>   > I'm seeing different failures on g++ than I have before.  ELF and COFF
>   > used to fail identically.  Since it's sort of wierd, I should confess
>   > that ELF on this target uses dwarf2eh and COFF uses sjlj.
> Yup.  But, aside from the tests that actually test EH, I would expect
> the run for ELF & COFF to be identical.

And a few short weeks ago, they did.

> Did we ever come to a resolution of the multilib testing problem?

Not really.   I was so elated when I saw that runlib was running the 
tests twice that I completely failed to notice until some weeks later
that it was running the elf compiler twice - once with the elf banner
and once with the coff banner.   I wasn't amused.

I'm now just running runtest twice, each with different --tool_opts flags. 

> Makes me wonder if something is goof-ing in the finalization code.
> Can you debug it?

Now is when I notice that GDB is not playing nice with EGCS ELF output.
When it rains...

>   > If I add '-defer-pop' to most of the cases I've tried by hand, it
>   > seems to work.   In  fact, I just wrote a script to loop through those
>   > cases and with -defer-pop.   With -defer-pop, 8 of them pass.   Without
>   > -defer-pop, none of them pass.
> Don't you mean -fno-defer-pop?

Boy, I was on a roll there, wasn't I?

I meant "-fdefer-pop".   -fno-defer-pop (the default) still shows the 
problem.


$ ./negcs /tmp/net34.C -lstdc++
$ ./a.out
bar_1::k -> 1
bar_2::k -> 2
bar_1::get_k() -> 1
bar_2::get_k() -> 2
Memory fault(coredump)
$ ./negcs -fdefer-pop /tmp/net34.C -lstdc++
$ ./a.out
bar_1::k -> 1
bar_2::k -> 2
bar_1::get_k() -> 1
bar_2::get_k() -> 2
$ 

This is actually ironic becuase when H.J. was having the problems that
could only be cured by -fdefer-pop, I tried them on OpenServer and
couldn't duplicate them at all.     Apparently, our stacks are just
different enough to be sensitive to whatever is going on here...

RJL