Stuart Henderson <stu@spacehopper.org> wrote:
> On 2024/02/18 09:02, Stuart Henderson wrote:
> > On 2024/02/17 22:08, Greg Steuck wrote:
> > > Oh wow, this is becoming eerily similar to the failures aja@ is getting. Do
> > > dig more into this!
> > 
> > Antoine, can you send a dmesg from one of the exopi VMs, please?
> 
> - specifically I am wondering if it could be someething to do with AVX,
> with AVX512 being the most likely to cause problems - Evan's machine
> does have this - my intel 11th gen doesn't because it has a mix of
> P+E cores, E cores don't implement it, so they disable it on the P
> cores too.
> 
> ghc *does* have some code relating to AVX512.

Breakthrough, ignore the previous reproducer and any association with
template haskell. I can get a crash in GHCI very simply:

    ~ $ ghci
    GHCi, version 9.6.4: https://www.haskell.org/ghc/  :? for help
    ghci> import qualified Data.Text as T
    ghci> T.take 1 $ T.pack "aa"
    "Illegal instruction (core dumped)

The issue seems to be related to the employment of AVX512 by the simdutf
project, which is vendored by the ubiquitous text package:

https://github.com/haskell/text/tree/master/simdutf

I had just noticed this dependency when I saw Stuart's message about
"the commit that fixed node" in simdutf upstream:

https://github.com/simdutf/simdutf/commit/55b107f609f5f63880db650a92861ae84cb10abe

GHC 9.6.4 ships with text 2.0.2. GHC 9.2.7 ships with text 1.2.5.0.
simdutf was first vendored in text 2.0 and the vendored copy there was
last updated in 2022. The conclusion is text's old version of simdutf
is using AVX512 instructions regardless of OS support.

I haven't followed this thread all the way to a proposed patch to the
ghc port, let's call it an exercise for the reader.

Evan