Investigate why LTO causes test failures on x86_64-darwin (under Rosetta 2) #568

New issue

Closed

opened 2024-11-04 03:58:24 +00:00 by lilyball · 3 comments

lilyball commented

2024-11-04 03:58:24 +00:00

Member

Describe the bug

Nixpkgs enables LTO for its Lix package definition (when not building statically). This causes test failures when building for x86_64-darwin (under Rosetta 2, unsure if that matters). The Lix flake does not enable LTO, which is why we haven't seen the problem ourselves.

For comparison, the Nixpkgs Nix package enables LTO when building with GCC (and not static). No explanation was given, though I found a comment suggesting that it was simply known that LTO didn't work on darwin. @emilazy suggested that what's going on is this is due to UB and GCC is simply exposing less UB than Clang. We don't know for a fact this is UB though.

If this is UB it would be good to fix. If this is not UB it would still be good to understand what's going on because enabling LTO is a potentially useful thing to do.

Steps To Reproduce

I reproduced the problem in Nixpkgs with nix build .#legacyPackages.x86_64-darwin.lix (on an aarch64-darwin machine with Rosetta 2), and confirmed that disabling LTO fixed the test failures. When doing this the failures I got were bizarre and looked like

../tests/unit/libexpr/value/context.cc:16: Failure
Expected: NixStringContextElem::parse("") throws an exception of type BadNixStringContextElem.
  Actual: it throws nix::BadNixStringContextElem with description "error: Bad String Context element: String context element should never be an empty string: ".

[  FAILED  ] NixStringContextElemTest.empty_invalid (0 ms)

(there are other test failures but they're all similar issues, where the expected and actual exceptions have the same names and yet the test considered them to be distinct)

## Describe the bug Nixpkgs enables LTO for its Lix package definition (when not building statically). This causes test failures when building for x86_64-darwin (under Rosetta 2, unsure if that matters). The Lix flake does not enable LTO, which is why we haven't seen the problem ourselves. For comparison, the Nixpkgs Nix package enables LTO when building with GCC (and not static). No explanation was given, though I found a [comment](https://github.com/NixOS/nixpkgs/pull/181180#issuecomment-1184882662) suggesting that it was simply known that LTO didn't work on darwin. @emilazy suggested that what's going on is this is due to UB and GCC is simply exposing less UB than Clang. We don't know for a fact this is UB though. If this is UB it would be good to fix. If this is not UB it would still be good to understand what's going on because enabling LTO is a potentially useful thing to do. ## Steps To Reproduce I reproduced the problem in Nixpkgs with `nix build .#legacyPackages.x86_64-darwin.lix` (on an aarch64-darwin machine with Rosetta 2), and confirmed that disabling LTO fixed the test failures. When doing this the failures I got were bizarre and looked like ``` ../tests/unit/libexpr/value/context.cc:16: Failure Expected: NixStringContextElem::parse("") throws an exception of type BadNixStringContextElem. Actual: it throws nix::BadNixStringContextElem with description "error: Bad String Context element: String context element should never be an empty string: ". [ FAILED ] NixStringContextElemTest.empty_invalid (0 ms) ``` (there are other test failures but they're all similar issues, where the expected and actual exceptions have the same names and yet the test considered them to be distinct)

lilyball added the

bug

label

2024-11-04 03:58:24 +00:00

raito commented

2024-11-06 21:42:54 +00:00

Owner

Can we get our hands on coredumps when such exceptions are thrown so we can identify what are the miscompilations/UB, etc. ?

getchoo referenced this issue

2025-05-15 19:38:48 +00:00

functional-test-libstoreconsumer fails with LTO on aarch64-darwin #832

commentatorforall added the

OS/macOS

awaiting

author

labels

2025-12-23 21:11:59 +00:00

commentatorforall commented

2025-12-23 21:12:53 +00:00

Member

is this still a thing or has this been fixed by-chance (or migration)?

commentatorforall added the

testing/flakey

label

2025-12-23 21:13:02 +00:00

raito commented

2025-12-24 08:53:16 +00:00

Owner

Support for Rosetta 2 is planned to be discontinued in the next years, macOS for Intel is also planned to be discontinued.

With our current resources, it's implausible we can support x86_64-darwin issues caused by compiler problems.

Unless there's a strong rationale for why we should tackle this, I will close this as this problem will disappear by itself.

Support for Rosetta 2 is planned to be discontinued in the next years, macOS for Intel is also planned to be discontinued. With our current resources, it's implausible we can support x86_64-darwin issues caused by compiler problems. Unless there's a strong rationale for why we should tackle this, I will close this as this problem will disappear by itself.