gcc: fix build on x86_64-darwin

[wegank]

Description of changes

#241951 (comment)

Looks like as from cctools-llvm is not a perfect drop-in replacement? 🤔

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 23.11 Release Notes (or backporting 23.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

[wegank]

@ofborg build gcc gcc.passthru.tests

[mweinelt]

/nix/store/jq3vqh8g07ssnigy7vj7iwv1gfcki5vr-cctools-port-973.0.1/libexec/as/x86_64/as: this system assembler is deprecated. Please migrate to the clang integrated assembler (`as -q').
error: building of '/nix/store/w6y2ncrffs960gmvw1n2cwr6ww2yln3v-gcc-12.3.0.drv!info,lib,man,out' from .drv file timed out after 3600 seconds

https://logs.ofborg.org/?key=nixos/nixpkgs.242108&attempt_id=244a3954-24f5-4421-848d-68f381a111aa

[wegank]

Yeah, gcc and gfortran each took two hours to build on my machine (Rosetta on M1).

[reckenrode]

As part of the Darwin stdenv rework, the default assembler was switched to the clang one on x86_64-darwin. Before switching it back just for GCC, I’d like to look into what’s happening to see if it should be done in cctools-llvm instead (conditionally for older versions of LLVM). I didn’t encounter this issue in my testing, so the failure is a bit surprising.

[reckenrode]

I have a hunch what it might be. I’m testing a build with a clang 13 stdenv (and thus a clang 13 integrated assembler in cctools-llvm) to see if it also fails.

[trofi]

That condition should probably be phrased as targetPlatform.isDarwin && targetPlatform.isx86_64. Why is it x86_64-specific? Shouldn't aarch64 have the same problem?

[reckenrode]

It’s an Intel-specific issue. The Darwin stdenv rework switched the assembler on x86_64-darwin to the clang integrated assembler. The intent was to match what the platform tools does (Apple has been using the clang assembler since Xcode 12, which uses LLVM 10). It appears there is an assembly optimization that is sensitive to whether there is debug info in the binary. In this case, GCC builds stage 2 with debug info and stage 3 without.

When I use a clang 16 stdenv, its stage 3 disassembly matches the stage 2 from the LLVM build, which is expected. I’m running builds with clang 12, 13, 14, and 15 to confirm when the issue is fixed; but I’m pretty sure it will be clang 12. There was some alignment-related optimizations that were disabled (possibly llvm/llvm-project@a048ce1) due to being sensitive to the presence of debug information (resulting in different assembly).

If that’s the case, I would rather push a fix to cctools-llvm them have GCC explicitly use cctools-port. If this issue is affecting GCC, it could also affect other applications or user code with debug information. It doesn’t seem to be a correctness issue, but it affects code generation in an apparently unwanted way.

[trofi]

Ideally gcc should use the same assembler in stage2 and stage3. Do I understand correctly it uses different ones? That would be very scary.

[trofi]

Oh, I did not read your comment carefully. Looks like it's just an assembler bug then. Worth adding an explicit comment into the source code that it's a workaround for a specific bug?

[reckenrode]

I’ve opened #242202 with some cctools-llvm fixes including one for this issue. I targeted staging-next due to the GCC build failure, but I can retarget staging instead if it would be preferred to use this in the interim.

The fix in that PR is intended to be more general since the problem only affects LLVM 11. Once #241692 is merged, Darwin will use LLVM 16 and not have this issue with the integrated assembler.

[vcunat]

I confirm that this does fix the build of gcc and gfortran on my x86_64-darwin (no emulation).

[reckenrode]

I should also add this LGTM as an interim fix. If it gets merged to unstick the GCC build on Hydra, I include a commit to revert this hotfix in favor of the general fix.