I suppose ICE may just (dis)appear on rebuilds more or less randomly, e.g. now I got this one this one.

Current system built and booted with this, FWIW, haven't seen any new failures in deployments (but haven't done the heavier testing that might be warranted).

In an attempt to investigate the ICE w/LLVM previously encountered (reliably, on multiple machines), I rebuilt everything entirely from bootstrap binaries... and have yet to see the error. This is great except this was using the revision that was causing problems before-- so I'm not quite sure what to conclude. "yet" :).

@vcunat the build you linked is green-- presumably it failed previously but succeeded when a rebuild was attempted?

AFAIK our current gcc 7.3 does not randomly ICE, so sorting this out seems like a blocker (certainly without a better reason than "latest greatest" for moving to 7.4 😸 ). Hopefully a minor issue that stems from a common source (wishful thinking perhaps, but here's hoping!). I'll go find the exact error I ran into, do you have the one for go (linked hydra build) or others?

the build you linked is green

Uh, no, I posted a wrong link. (My clipboard workflow is flaky.) This one, also edited above; I did reproduce it reliably.

That appears to be using gcc 7.3, are you seeing it with gcc 7.4 as well?
(or is that evidence that apparently our compiler segfaults "randomly" already, regardless of 7.3 vs 7.4? :P)

I meant the latter (in your parentheses). The same change didn't cause the segfault when picked to 18.09. I haven't tried other experiments around it.

Anyway, by default I'd trust that gcc minor updates fix more issues than they introduce.

Anyway, by default I'd trust that gcc minor updates fix more issues than they introduce.

Agreed! And okay great, that makes sense now re:failures.

Think this is ready for staging, then!

Woohoo, thanks! ❤️

Weird, the hydra machine on hydra.nixos.org got a hash error, twice in a row:

fixed-output derivation produced path '/nix/store/zgx1sjrjlkw182ria8hl19zvc48v7hq9-gcc-7.4.0.tar.xz' with sha256 hash '1v73c16n8k2zig4rsnrh2shnknn7yxfwma5bqrb8lfbs3hiyqjv8' instead of the expected hash '0lgy170b0pp60j9cczqkmaqyjjb584vfamj4c30swd7k0j6y5pgd'

on the third attempt my t4a machine got the job and succeeded (in a rather different physical location). Perhaps some mirror is bad and thus some locations consistently get a bad result.