[Bug debug/109161] Bad CTF generated for stub in function scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109161 Nix changed: What|Removed |Added CC||nix at esperi dot org.uk --- Comment #2 from Nix --- It definitely shouldn't hang for invalid input, but that sort of proof against invalid input isn't even implemented for the deduplicator yet, let alone every other thing that recurses over the type graph. It's on the todo list... and it's not specific to objdump at all: ctf_dump (objdump/readelf), ctf_type_rvisit, ctf_type_compat, even foundational libctf stuff like ctf_type_resolve would hang if, say, we had a CTF_K_CONST node pointing to itself, even indirectly. This does mean that anything we use to detect cycles must be *cheap*. Now I was assuming I could only implement cycle-detection efficiently for the deduplicator (which would usually suffice, since linking is the first thing that is usually done to compiler-generated CTF) -- but it occurs to me now that I could use a similar technique in ctf_type_rvisit, which will handle ctf_dump: I can probably do the same for the other recursive type-traversing functions, and handle all of them with the same cycle-detection code, and then CTF manipulation on raw object files would be safe against cycles too. The algorithm in question (one of Hellman's more obscure) cannot guarantee immediate detection of cycles, but it will always detect them eventually, which is good enough for this application. That's the price we pay for spotting cycles in constant space with almost no time overhead for the common, acyclic case.
[Bug bootstrap/98860] [11 Regression] boostrap failure on MinGW-w64 windows 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860 --- Comment #24 from Nix --- ... and ten seconds after I posted that it failed again. Looks like binutils isn't quite ready for DWARF 5 on Windows yet :(
[Bug bootstrap/98860] [11 Regression] boostrap failure on MinGW-w64 windows 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860 --- Comment #23 from Nix --- OK, that works: ignore me, in my case it was just using a too old binutils. (The error message emitted is... unhelpful: exec format error, really?)
[Bug bootstrap/98860] [11 Regression] boostrap failure on MinGW-w64 windows 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860 Nix changed: What|Removed |Added CC||nix at esperi dot org.uk --- Comment #22 from Nix --- I can confirm the same failure with an x86_64-pc-cygwin native build using a GCC trunk current as of Jan 12 (a bit old, sorry) and, oh dear this might explain it, binutils 2.35.1. Trying again with trunk binutils now.
[Bug target/65248] Copy relocation against protected symbol doesn't work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65248 --- Comment #11 from Nix --- The symptoms are failures to link with "relocation against protected symbol is invalid" errors which go away when you use gold. (You can see it if you try to build firefox, for instance.)
[Bug target/65248] Copy relocation against protected symbol doesn't work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65248 Nix changed: What|Removed |Added CC||nix at esperi dot org.uk --- Comment #9 from Nix --- Thirded. At the very least there should be a huge note in binutils NEWS about this. A subtle, unadvertised incompatibility of a new binutils with a not-very-old GCC is the sort of horror show that gives free software a bad name. At the very least make more noise about it.
[Bug pch/68176] [4.9/5/6 Regression] all pch tests fail on eglibc systems (with bits/predefs.h)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68176 --- Comment #11 from Nix --- Confirmed fixed (properly this time).
[Bug pch/68176] [4.9/5/6 Regression] all pch tests fail on eglibc systems (with bits/predefs.h)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68176 --- Comment #10 from Nix --- 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.
[Bug pch/68176] [4.9/5/6 Regression] all pch tests fail on eglibc systems (with bits/predefs.h)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68176 --- Comment #9 from Nix --- 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.
[Bug pch/68176] [4.9/5/6 Regression] all pch tests fail on eglibc systems (with bits/predefs.h)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68176 --- Comment #5 from Nix --- 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 ... I'll do some experimentation.
[Bug pch/68176] [4.9/5/6 Regression] all pch tests fail on eglibc systems (with bits/predefs.h)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68176 --- Comment #3 from Nix --- 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.)
[Bug pch/68176] [4.8/4.9 Regression] all pch tests fail on eglibc systems (with bits/predefs.h)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68176 --- Comment #1 from Nix --- 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.
[Bug pch/68176] New: [4.8/4.9 Regression] all pch tests fail on eglibc systems (with bits/predefs.h)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68176 Bug ID: 68176 Summary: [4.8/4.9 Regression] all pch tests fail on eglibc systems (with bits/predefs.h) Product: gcc Version: 4.9.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: pch Assignee: unassigned at gcc dot gnu.org Reporter: nix at esperi dot org.uk Target Milestone: --- 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 , 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.
[Bug other/50639] -flto=jobserver broken on large LTO build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50639 Nix changed: What|Removed |Added CC||nix at esperi dot org.uk --- Comment #1 from Nix 2012-01-23 01:18:58 UTC --- I can confirm the same symptoms while bootstrapping GCC on the head of the GCC 4.6 branch, with a bootstrap-lto profiledbootstrap, and GNU make 3.82. During the stage3 (profilegenerate) libgcc build, the build suddenly stops with: make[6]: *** read jobs pipe: No such file or directory. Stop. make[6]: *** Waiting for unfinished jobs lto-wrapper: make returned 2 exit status /usr/bin/ld: lto-wrapper failed collect2: ld returned 1 exit status make[5]: *** [libgcc_s.so] Error 1 This failure appears consistent, so whatever it is it's not a race (or, if it is, it's fearfully easy to hit).
