timotimo if i also require facts->type to be non-null, it no longer segfaults, but why would i need to?! 00:15
well, at least with that check i can reach through most of the spec tests, maybe all of them 00:28
seems like my changes made t/spec/integration/advent2012-day24.t infiniloop and gobble up memory or something :( 00:37
and of course i can't get it to do that without the fudger 00:39
well, the fudger doesn't do anything to that file; i meant the test runner 00:44
my brane seems to be suffering from my flu-type-thingie by now, so i'll get some rest
dalek arVM/merge_facts_at_phi: 8b2c7e7 | timotimo++ | src/spesh/optimize.c:
make optimize_smart_coerce more robust to wrong facts
 00:45
arVM/merge_facts_at_phi: 1b174d4 | timotimo++ | src/spesh/optimize.c:
at PHI ops, we may be able to merge common facts
nwc10 jnthn: paste.scsys.co.uk/469517 -- origin/spesh-value-prop setting build ASAN barf 05:36
nwc10 FROGGS: is this the output you wanted? paste.scsys.co.uk/469546 paste.scsys.co.uk/469547 10:37
FROGGS nwc10: aye it is, thank you :o) 15:36
so we seem to read the long portion of the union exactly like C does... that's not too bad 15:37
nwc10 my assumption (not backed up by actual testing) is that on a big endian machine, the union layout will have the short, char (etc) at the *start* of the memory used by the long (just like L.E.) 15:38
FROGGS I already thought that union members that are smaller as ptrsize or intsize have a padding...
nwc10 but of course, as it's B.E
those short, char etc show up as the most-significant bits of the long value, not the least significant.
FROGGS yeah
nwc10 and ("of course") you'll have them in (seemingly) different places on 32 and 64 bit B.E. machins 15:39
because they will appear at <<24 and <<16 or <<48 and <<56
nor <<0 and <<0 :-/
er,
not <<0 and <<0 :-/
(like that fun with the bitintrepr, which has to be different for 32 and 64 bit B.E.) 15:40
anyway, I need to decommute
timotimo damn it 18:22
my branch makes XML not compile any more
oh wow 18:23
massive failures all over
even on the master branch?!
FROGGS O.o 18:26
timotimo hm, false alarm apparently 19:49
not sure what i did wrong
maybe i make'd instead of make installing
timotimo but in my branch i get XML failing to install unless i disable spesh 20:18
timotimo is not amusified 20:49
but i'll just let that branch rest for a bit
brrt \o 20:57
dalek arVM/cpp2: c435813 | FROGGS++ | src/core/nativecall.c:
fix return value of C++ constructore calls
 21:14
arVM/cpp2: fa4019a | FROGGS++ | src/core/nativecall.c:
allow to natviecast from CPPStruct
FROGGS such typo
-.-
nebuchadnezzar nice to see that next moarvm release will permit to drop the debian patch ;-) 21:18
dalek arVM: 75e5909 | FROGGS++ | Configure.pl:
use CPPFLAGS if set, baby-gnu++
 21:22
FROGGS nebuchadnezzar: we should be fine now
nebuchadnezzar thanks a lot 21:23
FROGGS you're welcome 21:25
nebuchadnezzar FROGGS: I have a doubt, shouldn't the CPPFLAGS be pushed in cflags instead of ldflags? 22:15
dalek arVM: 1a551dc | timotimo++ | src/spesh/facts.c:
fix a sort of bad thinko in iter_facts
 23:13
timotimo so it seems like this happened: 23:35
we were looking for $!poisoned, which used to be a getattr_o
then we deconted that and if_o'd it to figure out if it'd be true-ish
spesh - for some reason - thought it knew it was going to be an Int box and turned that decont + if_o into a set, unbox and if_i
that gives rise to the "cannot unbox a type object" error that triggered inside the optimizer 23:36
i don't currently know why it thinks it knows the type; perhaps from logging? but there's no guard for that in the resulting code, so maybe we're not marking a guard properly? 23:37
anyway, for a hotfix i turned that $!poisoned attribute into a native int attribute
hum. optimize_iffy seems to be using the facts properly, so the guard ought to have been kept alive. huh. 23:43
ah, but if facts are merged at a PHI, the guard a fact comes from isn't marked as used when the result is used!
that could be the issue here
yeah, i've got a fix that prevents breakage, but no implementation of "using facts from guards through a PHI node" 23:51
i'll probably leave that for tomorrow and have some rest

Powered by Cro and the Raku® Programming Language.

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

Thank you!