This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug bootstrap/83396] [8 Regression] Bootstrap failures with Statement Frontiers


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83396

--- Comment #77 from Alexandre Oliva <aoliva at gcc dot gnu.org> ---
Created attachment 42891
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42891&action=edit
fix libiberty/unix-pex bootstrap compare (stage3 configure)

... and if you find that bootstrap-debug compare fails in libiberty/unix-pex,
that's because the configure test for vfork fails: we start a new block for the
vfork call, even if all we had in the initial block was a debug marker.  Worse:
in this case, nothing connects the two blocks, so the vfork call and everything
else in the configure test gets optimized out.  If you are lucky,
-fcompare-debug will make that a compile failure, so the configure test result
will be different, and you'll get different code between the different stages. 
Otherwise, you might get a silent pass, and bootstrap will succeed.
Isn't that reason enough to bootstrap gcc with BUILD_CONFIG='bootstrap-debug
bootstrap-debug-lean bootstrap-debug-lib' at least once in a while? :-)

This patch reinstates the changes I'd made to fix this error some 13 months
ago, i.e., it re-reverts some of the changes that the previous patch reverted. 
They were not *just* to accept markers before labels.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]