This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: disturbing g++ 971031 results. defer-pop to blame?
[ 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