error: instruction requires: sha3

[bmillwood]

I've started seeing this error recently on my M1 Macbook on GHC 8.10.7:

...
[135 of 136] Compiling Crypto.System.CPU ( Crypto/System/CPU.hs, /Users/ben/Tech/upstreams/cryptonite/dist-newstyle/build/aarch64-osx/ghc-8.10.7/cryptonite-0.30/build/Crypto/System/CPU.o, /Users/ben/Tech/upstreams/cryptonite/dist-newstyle/build/aarch64-osx/ghc-8.10.7/cryptonite-0.30/build/Crypto/System/CPU.dyn_o )
[136 of 136] Compiling Crypto.Tutorial  ( Crypto/Tutorial.hs, /Users/ben/Tech/upstreams/cryptonite/dist-newstyle/build/aarch64-osx/ghc-8.10.7/cryptonite-0.30/build/Crypto/Tutorial.o, /Users/ben/Tech/upstreams/cryptonite/dist-newstyle/build/aarch64-osx/ghc-8.10.7/cryptonite-0.30/build/Crypto/Tutorial.dyn_o )

/var/folders/64/dnh592q95bs78x18w4psyrpm0000gn/T/ghc73460_0/ghc_1.s:3394:2: error:
     error: instruction requires: sha3
            eor3.16b        v0, v1, v0, v2
            ^
     |
3394 |         eor3.16b        v0, v1, v0, v2
     |  ^

<no location info>: error:
    Error running clang! you need clang installed to use the LLVM backend
    (or GHC tried to execute clang incorrectly)
`clang' failed in phase `Clang (Assembler)'. (Exit code: 1)

This only started happening recently. I don't know why, but my guess is it's related to either an OS upgrade or an upgrade of some other library. I'm on macOS Ventura 13.0.1.

Switching to GHC 9.2.5 seems to fix it, although that's not an ideal solution for me for other reasons. 9.0.2 seems to reproduce the instruction requires: sha3 issue once I've worked around this unrelated GHC-on-M1 issue.

Using cabal build -v, it seems like this is the command that fails:

/Users/ben/.ghcup/bin/ghc -c -fPIC -odir /Users/ben/Tech/upstreams/cryptonite/dist-newstyle/build/aarch64-osx/ghc-8.10.7/cryptonite-0.30/build -I/Users/ben/Tech/upstreams/cryptonite/dist-newstyle/build/aarch64-osx/ghc-8.10.7/cryptonite-0.30/build/autogen -I/Users/ben/Tech/upstreams/cryptonite/dist-newstyle/build/aarch64-osx/ghc-8.10.7/cryptonite-0.30/build/global-autogen -I/Users/ben/Tech/upstreams/cryptonite/dist-newstyle/build/aarch64-osx/ghc-8.10.7/cryptonite-0.30/build -Icbits -Icbits/ed25519 -Icbits/decaf/include -Icbits/decaf/p448 -Icbits/argon2 -Icbits/include64 -Icbits/decaf/include/arch_ref64 -Icbits/decaf/p448/arch_ref64 -Icbits/blake2/ref -I/Users/ben/Tech/upstreams/cryptonite/dist-newstyle/build/aarch64-osx/ghc-8.10.7/cryptonite-0.30/build/cbits -I/Users/ben/Tech/upstreams/cryptonite/dist-newstyle/build/aarch64-osx/ghc-8.10.7/cryptonite-0.30/build/cbits/ed25519 -I/Users/ben/Tech/upstreams/cryptonite/dist-newstyle/build/aarch64-osx/ghc-8.10.7/cryptonite-0.30/build/cbits/decaf/include -I/Users/ben/Tech/upstreams/cryptonite/dist-newstyle/build/aarch64-osx/ghc-8.10.7/cryptonite-0.30/build/cbits/decaf/p448 -I/Users/ben/Tech/upstreams/cryptonite/dist-newstyle/build/aarch64-osx/ghc-8.10.7/cryptonite-0.30/build/cbits/argon2 -I/Users/ben/Tech/upstreams/cryptonite/dist-newstyle/build/aarch64-osx/ghc-8.10.7/cryptonite-0.30/build/cbits/include64 -I/Users/ben/Tech/upstreams/cryptonite/dist-newstyle/build/aarch64-osx/ghc-8.10.7/cryptonite-0.30/build/cbits/decaf/include/arch_ref64 -I/Users/ben/Tech/upstreams/cryptonite/dist-newstyle/build/aarch64-osx/ghc-8.10.7/cryptonite-0.30/build/cbits/decaf/p448/arch_ref64 -I/Users/ben/Tech/upstreams/cryptonite/dist-newstyle/build/aarch64-osx/ghc-8.10.7/cryptonite-0.30/build/cbits/blake2/ref -I/opt/homebrew/include -optc-O2 '-optc-std=gnu99' -optc-DWITH_TARGET_ATTRIBUTES -hide-all-packages -no-user-package-db -package-db /Users/ben/.cabal/store/ghc-8.10.7/package.db -package-db /Users/ben/Tech/upstreams/cryptonite/dist-newstyle/packagedb/ghc-8.10.7 -package-db /Users/ben/Tech/upstreams/cryptonite/dist-newstyle/build/aarch64-osx/ghc-8.10.7/cryptonite-0.30/package.conf.inplace -package-id base-4.14.3.0 -package-id bsmnt-0.0.15-7485cda7 -package-id bytestring-0.10.12.0 -package-id deepseq-1.4.4.0 -package-id ghc-prim-0.6.1 -package-id integer-gmp-1.0.3.0 -package-id mmry-0.18.0-baff4fa2 cbits/cryptonite_aes.c -hide-all-packages

This happens both with the released cryptonite-0.30 and with the git master branch (at time of writing, d163f69512a3d162baa69a95927f3d6369833f7d).

[vincenthz]

I don't think it has anything to do with cryptonite, since there's no arm lowlevel instructions whatsoever.

so my best guess (from the error message and a 1min google) is that ghc is producing the eor3 instructions indiscriminately whether sha3 instructions are enabled or not, and maybe some more lowlevel assembler/linker is now being more pedantic on whether it accept eor3.

Maybe you need to specify some extra options to linkers that is currently being assumed.

Also as far as I heard, the ghc arm backend is not quite production ready ~now, and older versions are extremely bad in arm generation.

I suggest you see with ghc upstream

[jepino]

I'm experiencing the exact same issue. @bmillwood were you able to solve this?

EDIT: Not exactly the same issue, I was using stack instead of cabal.

[bmillwood]

No, sorry, I just took the upgrading GHC route.

[jepino]

To anyone wondering how to fix this, upgrading to llvm@13 worked for me. This is odd because stack specifically instructed to use versions [9, 13).