tech-toolchain archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: State of AVX512 support in NetBSD?



On Tue, Jul 30, 2024 at 07:02:15AM +0000, RVP wrote:
> On Mon, 29 Jul 2024, Thomas Klausner wrote:
> 
> > For my recent build trouble of lang/ghc98 that only I can see but pho@
> > can't[1], upstream has suggested it might be a problem with AVX512
> > support[2] in NetBSD. (My CPU supports AVX512, pho's doesn't.)
> > 
> > I'll give their suggestion (using -D__STDC_NO_ATOMICS__) a try, but
> > does anyone know the actual state of AVX512 support on NetBSD?
> > 
> 
> I don't think this is AVX-512-related. The programs would've crashed with
> an `Illegal instruction' like my test progs (attached) did on OpenBSD.
> 
> I think it may due to how the *BSDs handle conversions of multi-byte
> chars. in non-UTF-8 locales:
> 
> In my test program, glibc's mbstowcs(3) returns -1 when fed UTF-8 chars
> and the locale is C/POSIX.
> 
> *BSDs treat the same string as a byte sequence--ie. mbstowcs() == strlen()
> if LC_ALL=C/POSIX.
> 
> If, however, the locale is some UTF-8 one (say, C.UTF-8), then both Linux
> and the BSDs behave the same.
> 
> Try the attached like so on NetBSD and Linux:
> 
> ```
> $ make clean; LC_ALL=C.UTF-8 make
> $ make clean; LC_ALL=C make
> ```
> 
> compare the hs*.txt files on Linux and NetBSD and notice that when LC_ALL=C
> _hs_text_measure_off() returns a negative number (as it says it will in the
> code when the buffer is short) for LC_ALL=C.

I have a couple arguments against your point here:

1. adding -D__STDC_NO_ATOMICS__ to CFLAGS fixes it

2. ghc98 built in the exact same environment before, the only change
   was an update of the operating system by about 10 days, which
   coincided with the switch from gcc10 to gcc12 (which plausibly
   might have changed AVX-512 support).

 Thomas


Home | Main Index | Thread Index | Old Index