stdenv/linux: apply default compiler errors from GCC 14#356545
stdenv/linux: apply default compiler errors from GCC 14#356545emilazy wants to merge 2 commits intoNixOS:stagingfrom
Conversation
I omitted the manual changes for now as they would require adapting to the changed defaults of the parameters and ran into merge conflicts. I also skipped the test suite changes from one of the commits, as it depended on another commit.
Let’s make sure both OSes get an adequate amount of compiler fun this cycle! This is a version of alyssais’s <NixOS#344239> that applies to the Linux standard environment’s compiler wrapping rather than the versioned GCC packages themselves. This is purely a transition mechanism to help us prepare for the GCC 14 update while GCC 14 itself is not yet ready for wide deployment; it will be reverted before 25.05, whether because it becomes obsolete thanks to an upgrade to GCC 14 or because we give up on GCC 14 and deicde to stick with GCC 13 with the vanilla flags. This approach means that the standard `gcc` will be wrapped correctly, unlike with the previous PR, achieving the primary goal of the change, but `gcc13` will remain as it was before. Currently, I believe the difference between the two is just bootstrapping stage stuff; it’s a bit weird to me to diverge, especially since there is a definition of `gcc` in `all-packages.nix` that looks like it ought to make them equivalent, but it may have the nice property that we can pin especially stubborn packages to GCC 13 without them getting the errors (though I am not sure if this is actually true or not, since I’m not sure how `gcc13Stdenv` actually works). One downside is that this only applies to Linux, but since this is essentially meant to be a forcing function to get us to deal with the errors early, that seems fine. Source: https://gcc.gnu.org/gcc-14/porting_to.html Co-authored-by: Alyssa Ross <[email protected]>
|
Two problems: Firstly, It seems like this breaks the Secondly, since I’m not sure if we have a flags file specifically for C, all C++ compilation gives these warnings: This seems tricky to fix if we don’t want to suppress such warnings in any case where vanilla GCC 13 would be producing them. @alyssais I’m starting to lean towards just updating to the GCC 14 release branch HEAD instead. It seems like all the known AArch64 issues we ran into were already fixed there weeks ago when we ran into them, and Arch (and IIRC another distro?) are shipping it so it seems like it shouldn’t be too bad to do on unstable. What do you think? |
|
SGTM. We can always roll back. |
|
Closing in favour of #356812. |
2 participants
Let’s make sure both OSes get an adequate amount of compiler fun this cycle! This is a version of alyssais’s #344239 that applies to the Linux standard environment’s compiler wrapping rather than the versioned GCC packages themselves.
This is purely a transition mechanism to help us prepare for the GCC 14 update while GCC 14 itself is not yet ready for wide deployment; it will be reverted before 25.05, whether because it becomes obsolete thanks to an upgrade to GCC 14 or because we give up on GCC 14 and deicde to stick with GCC 13 with the vanilla flags.
This approach means that the standard
gccwill be wrapped correctly, unlike with the previous PR, achieving the primary goal of the change, butgcc13will remain as it was before. Currently, I believe the difference between the two is just bootstrapping stage stuff; it’s a bit weird to me to diverge, especially since there is a definition ofgccinall-packages.nixthat looks like it ought to make them equivalent, but it may have the nice property that we can pin especially stubborn packages to GCC 13 without them getting the errors (though I am not sure if this is actually true or not, since I’m not sure howgcc13Stdenvactually works).One downside is that this only applies to Linux, but since this is essentially meant to be a forcing function to get us to deal with the errors early, that seems fine.
Source: https://gcc.gnu.org/gcc-14/porting_to.html
I’ve bootstrapped an earlier version of this but will compile again with the current commits tomorrow.
cc @trofi for review of my sloppily‐modified GCC patches :) I hope
Init(-1)rather thanInit(0)is correct!Things done
nix.conf? (See Nix manual)sandbox = relaxedsandbox = truenix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/)Add a 👍 reaction to pull requests you find important.