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

[Jeffrey A Law]

  In message < 19971102224718.19861@dgii.com >you write:
  > [ re: new? failures on i586-pc-sco3.2v5.0.4 ] 
  > >   > I'm seeing different failures on g++ than I have before.  ELF and COF
  > F
  > >   > 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.
Hmmm.  I guess the one thing I can think of which would play into
some of these problems is the bogus flow control graphs we used
to generate.
 
  > 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.
Real strange since I've actually looked in the log files when I've
done H8 testing and everything seems to be in order...  Got to
be something simple/stupid we're missing.

  > Now is when I notice that GDB is not playing nice with EGCS ELF output.
  > When it rains...
Sigh.  More likely it's not playing nice with dwarf2 more so than
ELF.

  > 
  > >   > 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 thos
  > e
  > >   > cases and with -defer-pop.   With -defer-pop, 8 of them pass.   Witho
  > ut
  > >   > -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.
Hmmm, -fdefer-pop is the default; the compiler will arrange for
-fno-defer-pop to be on inside EH regions and such.  Real strange.


jeff