|
04:02
guifa left
08:11
sena_kun joined
09:07
sena_kun left
10:55
guifa joined
11:59
guifa left
|
|||
| timo | I: uname -a | 12:12 | |
| - Linux virt64c 6.1.0-30-arm64 #1 SMP Debian 6.1.124-1 (2025-01-12) aarch64 GNU/Linux | |||
| + Linux i-capture-the-hostname 6.1.0-30-armmp-lpae #1 SMP Debian 6.1.124-1 (2025-01-12) armv7l GNU/Linux | |||
| - your CPU can't read unaligned values for any of int32 int64 num64 | |||
| + your CPU can read unaligned values for only int32 | |||
| ^- this is (maybe just part of) why on armhf on debian our moar builds aren't reproducible. we check for armv[67] but there's no check for aarch64 | 12:14 | ||
| last time i looked i was thinking we had a snippet we compile and run to see if unaligned reads were supported or not somehow | 12:15 | ||
| but we kind of hard-code it at the moment | |||
| github.com/MoarVM/MoarVM/commit/d1...a08ead3255 has a bit of explanation why a snippet won't easily work for that purpose | 12:16 | ||
| if we want to make the reproductive builds happy for moar, we'd have to either give the same results for these two cases, see if i can turn off that particular "mutation", or take it up with the repro-builds team. i can (at least weakly) assume that if they make "aarch64" vs "armv7l" an acceptable mutation in the first place for reproducibility, that it should be fine to give the same result for | 12:28 | ||
| aarch64 and armv7 | 12:29 | ||
|
13:16
JimmyZhuo joined
13:50
JimmyZhuo left
15:01
Nicholas_ is now known as Nicholas
20:57
guifa joined
22:13
sena_kun joined
22:52
sena_kun left
|
|||