Since the fix to bug 65550, more or less all pch tests fail, with symptoms identical to those reported in bug 55399: FAIL: gcc.dg/pch/common-1.c -O0 -g -I. -Dwith_PCH (test for excess errors) FAIL: gcc.dg/pch/common-1.c -O0 -g assembly comparison FAIL: gcc.dg/pch/common-1.c -O0 -I. -Dwith_PCH (test for excess errors) FAIL: gcc.dg/pch/common-1.c -O0 assembly comparison FAIL: gcc.dg/pch/common-1.c -O1 -I. -Dwith_PCH (test for excess errors) FAIL: gcc.dg/pch/common-1.c -O1 assembly comparison FAIL: gcc.dg/pch/common-1.c -O2 -I. -Dwith_PCH (test for excess errors) FAIL: gcc.dg/pch/common-1.c -O2 assembly comparison FAIL: gcc.dg/pch/common-1.c -O3 -fomit-frame-pointer -I. -Dwith_PCH (test for excess errors) FAIL: gcc.dg/pch/common-1.c -O3 -fomit-frame-pointer assembly comparison FAIL: gcc.dg/pch/common-1.c -O3 -g -I. -Dwith_PCH (test for excess errors) FAIL: gcc.dg/pch/common-1.c -O3 -g assembly comparison FAIL: gcc.dg/pch/common-1.c -Os -I. -Dwith_PCH (test for excess errors) FAIL: gcc.dg/pch/common-1.c -Os assembly comparison FAIL: gcc.dg/pch/counter-1.c -O0 -g -I. -Dwith_PCH (test for excess errors) FAIL: gcc.dg/pch/counter-1.c -O0 -g assembly comparison FAIL: gcc.dg/pch/counter-1.c -O0 -I. -Dwith_PCH (test for excess errors) FAIL: gcc.dg/pch/counter-1.c -O0 assembly comparison FAIL: gcc.dg/pch/counter-1.c -O1 -I. -Dwith_PCH (test for excess errors) FAIL: gcc.dg/pch/counter-1.c -O1 assembly comparison FAIL: gcc.dg/pch/counter-1.c -O2 -I. -Dwith_PCH (test for excess errors) FAIL: gcc.dg/pch/counter-1.c -O2 assembly comparison FAIL: gcc.dg/pch/counter-1.c -O3 -fomit-frame-pointer -I. -Dwith_PCH (test for excess errors) FAIL: gcc.dg/pch/counter-1.c -O3 -fomit-frame-pointer assembly comparison FAIL: gcc.dg/pch/counter-1.c -O3 -g -I. -Dwith_PCH (test for excess errors) FAIL: gcc.dg/pch/counter-1.c -O3 -g assembly comparison FAIL: gcc.dg/pch/counter-1.c -Os -I. -Dwith_PCH (test for excess errors) FAIL: gcc.dg/pch/counter-1.c -Os assembly comparison [etc etc ad nauseam] The failures are all identical in the logs: a refusal to use common-1.h.gch, thus an attempt to find common-1.h, which has specifically been removed to ensure that PCH is used. The underlying cause of this is that on eglibc -- but not glibc -- systems, /usr/include/stdc-predef.h itself includes <bits/predefs.h>, and that inclusion, being done by a normal #include, does not get implicit_preinclude set. So all PCH inclusion fails, spuriously. eglibc is pretty dead by now: it may be that we don't care about this. But there are still systems using it, and they were broken by this change.
I can confirm that reverting the fix for bug 65550 makes the pch failures go away on my increasingly creaky eglibc 2.18 systems. So that's the smoking gun.
I suppose it doesn't work with GCC 5 or trunk either.
I haven't tested that yet, so I wasn't willing to commit to it. It seems very likely though. (I wasn't sure of protocol, or I'd have put you in the Cc list as the author of the fix for bug 65550, but I was afraid that might seem spammy... glad to see you spotted the bug going by anyway.)
So shouldn't we just fixinclude the bad stdc-predef.h headers and resolve this that way? IMNSHO stdc-predef.h really shouldn't include anything.
I didn't think of that (I try to forget that fixincludes exists because it gives me nightmares). But much though I hate fixincludes, this sort of fix (to headers for an obsolete program which will by definition never be fixed) is more or less exactly what it was designed for, and seems a perfect fit for this case. The question is whether further adjustments are needed to compensate for the removal of <bits/predefs.h>... I'll do some experimentation.
The original concept for stdc-predef.h includes that it might include other headers - in particular, that it might #include_next <stdc-predef.h>, so that e.g. libdfp could provide its own stdc-predef.h that defines relevant __STDC_* macros to say that DFP library functionality is available before including the glibc version, when you use -isystem /usr/include/dfp. Now, libdfp currently doesn't do that, and such use of libdfp might not be expected to work with PCH, so fixincluding may well be sufficient for this bug at present.
Created attachment 37503 [details] gcc6-pr68176.patch Can you please try this?
Note, while I don't have eglibc, I've hacked my /usr/include/stdc-predef.h to #include <bits/predef.h> and added that header, without the patch I see many FAILs with make check-gcc RUNTESTFLAGS=pch.exp, with the patch none. Will bootstrap/regtest it now.
Tested on the same old GCC 4.9 build tree and eglibc system that failed in the original report (for maximum reproducibility): it works, the regression is cured.
Argh, scratch that -- I need to test a tree that *doesn't* have the original patch reverted! Doing that now, will report back once that's done.
Confirmed fixed (properly this time).
Author: jakub Date: Thu Jan 28 22:35:20 2016 New Revision: 232956 URL: https://gcc.gnu.org/viewcvs?rev=232956&root=gcc&view=rev Log: PR pch/68176 * files.c (_cpp_find_file): Set file->implicit_preinclude even if included from file->implicit_preinclude header. Modified: trunk/libcpp/ChangeLog trunk/libcpp/files.c
Fixed on the trunk so far.
Author: jakub Date: Wed Feb 10 18:43:01 2016 New Revision: 233299 URL: https://gcc.gnu.org/viewcvs?rev=233299&root=gcc&view=rev Log: Backported from mainline 2016-01-28 Jakub Jelinek <jakub@redhat.com> PR pch/68176 * files.c (_cpp_find_file): Set file->implicit_preinclude even if included from file->implicit_preinclude header. Modified: branches/gcc-5-branch/libcpp/ChangeLog branches/gcc-5-branch/libcpp/files.c
Fixed also for 5.4+.
Author: jakub Date: Thu Feb 11 09:27:07 2016 New Revision: 233335 URL: https://gcc.gnu.org/viewcvs?rev=233335&root=gcc&view=rev Log: Backported from mainline 2016-01-28 Jakub Jelinek <jakub@redhat.com> PR pch/68176 * files.c (_cpp_find_file): Set file->implicit_preinclude even if included from file->implicit_preinclude header. Modified: branches/gcc-4_9-branch/libcpp/ChangeLog branches/gcc-4_9-branch/libcpp/files.c
Fixed.