How to fix the miscompilations on Darwin?

How to fix the miscompilations on Darwin?

Afaik this only happens on aarch64-darwin?
I think we should disable native compilation for aarch64-darwin for the time being.

This should "only" result in a performance regression for users, not a functional regression.

If it doesn't work on aarch64-darwin, we should probably hold off on upgrading emacs = emacs29 (at least on aarch64-darwin).

How to fix the miscompilations on Darwin?

Afaik this only happens on aarch64-darwin? I think we should disable native compilation for aarch64-darwin for the time being.

This should "only" result in a performance regression for users, not a functional regression.

Do we know if this was failing on Darwin for 29.1-rc1?

FWIW, nix build 'github:adisbladis/nixpkgs/emacs29#emacs' succeeds for me on aarch64-darwin, including normal startup afterwards. So not sure where the reference above about failures on this arch came from.

FWIW, nix build 'github:adisbladis/nixpkgs/emacs29#emacs' succeeds for me on aarch64-darwin, including normal startup afterwards. So not sure where the reference above about failures on this arch came from.

Built first time for me on aarch64-darwin too:

% uname -a
Darwin mba 22.6.0 Darwin Kernel Version 22.6.0: Wed Jul  5 22:22:52 PDT 2023; root:xnu-8796.141.3~6/RELEASE_ARM64_T8103 arm64 arm Darwin

% nix build 'github:adisbladis/nixpkgs/emacs29#emacs' |& nom

% ./result/bin/emacs-29.1 --batch --eval '(progn (princ system-configuration-options) (kill-emacs))'

--prefix=/nix/store/vasvsppn4zsziwr4hfmpnsajjck8sgms-emacs-29.1 --disable-build-details --with-modules --disable-ns-self-contained --with-ns --with-native-compilation --with-tree-sitter

I also rebuilt all my packages via:

(defun aim/elpaca-native-comp-rebuild ()
  "native-compile ~/.emacs/elpaca/builds"
  (interactive)
  (setq native-comp-async-jobs-number 8)
  (native-compile-async (expand-file-name "elpaca/builds" user-emacs-directory) 'recursively))

% ls -trl ~/.emacs.d/eln-cache
total 0
drwxr-xr-x 292 aim staff  9344 May  7 23:55 28.2-3de7ef76
drwxr-xr-x 292 aim staff  9344 May 15 11:08 28.2-40f6d145
drwxr-xr-x   5 aim staff   160 Jun  3 22:25 28.2-7ae05b16
drwxr-xr-x 298 aim staff  9536 Jun  3 23:03 28_3-881844cb
drwxr-xr-x  14 aim staff   448 Jun 19 18:16 28.2-6b9b9b29
drwxr-xr-x 305 aim staff  9760 Jul 25 20:34 29_0_91-4e517c6d
drwxr-xr-x 389 aim staff 12448 Jul 29 10:52 29_1-419c4759
drwxr-xr-x 456 aim staff 14592 Jul 30 18:50 29.0.92-9315583a
drwxr-xr-x 265 aim staff  8480 Jul 31 21:24 29.1-736645da

and running the newly built emacs-29.1 for 10 minutes or so seems fine.

Result of nixpkgs-review pr 246203 run on aarch64-darwin 1

Ran with --skip-package-regex '.*agda.*' to avoid proving the entirety of mathematics in tests.

I'm not sure how the level of build breakage compares to other architectures or previously known issues.

emacs -Q looks fine.

Shout back if there are any specific recipes I should run to check for other possible failures.

FWIW, nix build 'github:adisbladis/nixpkgs/emacs29#emacs' succeeds for me on aarch64-darwin, including normal startup afterwards. So not sure where the reference above about failures on this arch came from.

My memory was tricking me a bit and I was thinking about #127902 which, afaict, pertains only to emacs-macport.
I suspect that's what @AndersonTorres was also talking about?

I was talking about the error ofborg catched in x64 apple.

It makes me wonder because timeouts are more typical than compilation errors.

About the news, --with-native-compilation now accepts the option =aot.

About the news, --with-native-compilation now accepts the option =aot.

I looked into that but we don't need to change anything as we use the env var NATIVE_FULL_AOT that achieves the same thing and I didn't want to break up the grouping of:

  env = {
    NATIVE_FULL_AOT = "1";
    LIBRARY_PATH = lib.concatStringsSep ":" libGccJitLibraryPaths;
  };

as I think it makes it more clear why we're setting the library path.

@adisbladis, see your own suggestion: #246169 (comment)
I think it would be better to separate this PR into two:

• The version bump to 29.1, which can then be immediately backported to nixos-23.05
• The promotion of emacs 29.1 flavors as the default one (and possibly the doc changes), which only applies to unstable

(I'm concerned that otherwise, the users of nixos-23.05 will be stuck with emacs 29.1-rc1, lest another PR is especifically created for that bump, which seems like a double effort to me).

While the bot is handy for backporting entire PRs, we can always cherry-pick backports manually.

While the bot is handy for backporting entire PRs, we can always cherry-pick backports manually.

I would recommend new contributors to use the bot for backports but if you are a seasoned nixpkgs contributor a manual backport is not hard.