diakopter jnthn: whoa 04:39
ohh, just introduced 3 days ago 04:40
FROGGS o/ 10:18
lizmat FROGGS o/ 10:31
synopsebot6's lifetime is 20 minutes ? 10:32
nwc10 orbus: (gdb) #0 validate_literal_operand (val=val@entry=0xffbff650, flags=56) at src/core/validation.c:248 14:09
would seem to be the GET_UI32() macro here: 14:10
case MVM_operand_str: {
MVMuint32 index = GET_UI32(val->cur_op, 0);
MVMuint32 count = val->cu->body.orig_strings;
nwc10 wonders - is the value of the pointer val->cur_op only 2-byte aligned?
GET_UI32 is defined like this: 14:11
#define GET_UI32(pc, idx) *((MVMuint32 *)(pc + idx))
my hunch is that (pc + idx) is 2 byte aligned, and all the platforms we've built on so far can load 4 byte values from 2 byte alignment without complaining
jnthn Yes, 4-byte things in the bytecode stream can only safely be considered 2-byte alignee 15:14
*aligned
nwc10 ah OK, rightho 15:15
so seems like some more compile-time alignment checks, and runtime memcpy-or-not stuff is needed 15:16
jnthn Seems so 15:18
dalek arVM: a0869ee | jnthn++ | docs/ChangeLog:
ChangeLog for 2016.02.
 15:38
arVM: e4a316a | jnthn++ | VERSION:
Bump VERSION.
nwc10 although it looks like all our memcpy-or-not stuff is spelled "memcpy" and we assume that the compiler optmisers is smart 15:39
jnthn grumbles about waking up full of cold 15:45
jnthn www.moarvm.org/releases/MoarVM-2016.02.tar.gz 15:47
Tagged too 15:48
dalek href="https://moarvm.org:">moarvm.org: 1bbc6df | jnthn++ | / (3 files):
Update the website for latest releases.
 16:06
orbus nwc10: makes sense - no idea how to fix it though 18:25
even on x86, I know unaligned access is a performance hit, so it seems like a solution would of benefit even on platforms that aren't as picky as sparc 18:26

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!