This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug bootstrap/83396] [8 Regression] Bootstrap failures with Statement Frontiers
- From: "aoliva at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Fri, 15 Dec 2017 02:35:07 +0000
- Subject: [Bug bootstrap/83396] [8 Regression] Bootstrap failures with Statement Frontiers
- Auto-submitted: auto-generated
- References: <bug-83396-4@http.gcc.gnu.org/bugzilla/>
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.