00:26
AlexDaniel joined
00:38
MasterDuke joined
01:58
ilbot3 joined
02:00
FROGGS joined
05:51
lizmat joined
06:49
domidumont joined
06:57
domidumont joined
07:01
ingy joined
07:44
AlexDaniel joined
08:27
FROGGS joined
|
|||
FROGGS | o/ | 08:27 | |
08:30
Zoffix joined
10:44
Zoffix left
10:53
domidumont joined
11:33
FROGGS joined
11:44
AlexDani` joined
12:08
lizmat joined
12:15
FROGGS|m joined
12:21
FROGGS|m2 joined
14:23
zakharyas joined
14:44
zakharyas joined
15:10
zakharyas joined
|
|||
FROGGS | something is fishy about my inlined-shaped-carray patch... | 16:00 | |
dogbert17 | uh oh | 16:01 | |
in fact, lots of problems seems to have decided to make an appearance this weekend | |||
.seen timotimo | |||
yoleaux | I saw timotimo 16:00Z in #perl6: <timotimo> this also has alpine linux apks | ||
timotimo | o/ | ||
dogbert17 | o/ | ||
timotimo | o/ | 16:02 | |
dogbert17 | time for a question | ||
did you see nwc10's error report the other day? | |||
paste.scsys.co.uk/576714 | |||
timotimo | i saw nwc10 the other day | 16:03 | |
dogbert17 | cool | ||
there's something fishy going on in his example | 16:04 | ||
timotimo: the valgrind output is a tiny bit more revealing: gist.github.com/dogbert17/8cfbb94b...f0fdd96cbb | 16:05 | ||
FROGGS | is segfaults in nqp::decont... there is an object where its STABLE(obj) is an illegal memory access | ||
timotimo | FROGGS: can you try disabling spesh for a moment? | ||
FROGGS | timotimo: very much the same | 16:06 | |
timotimo | OK | 16:07 | |
do you have a c-level backtrace? | |||
FROGGS | timotimo: gist.github.com/FROGGS/e935f16baec...b5bf83be2a | 16:10 | |
that's all I have | |||
I'm calling a method on a instantiated CPPStruct | 16:11 | ||
dogbert17 | any c experts around ? | 16:23 | |
I get the feeling that there's something wrong in the FSA_SIZE_DEBUG block here compared to the path taken if FSA_SIZE_DEBUG=0 | 16:27 | ||
i.e. here: github.com/MoarVM/MoarVM/blob/mast...loc.c#L232 | |||
if FSA_SIZE_DEBUG=1 the code crashes but if I 'remove' rows 232:238 and 250 then everything works and valgrind is happy | 16:29 | ||
the code I'm running is this gist.github.com/dogbert17/8cfbb94b...f0fdd96cbb | 16:33 | ||
16:47
domidumont joined
16:48
live_the_dream joined
16:54
domidumont joined
16:58
lizmat_ joined
17:05
lizmat joined
17:09
zakharyas joined
|
|||
Geth | MoarVM: a206cd8cd2 | (Timo Paulssen)++ | 2 files jit floor_n not sure if round mode 9 is actually correct. The compiler explorer claims that's what gcc gives for `(double) round(foo)`. I only see values 0 through 3 explained on the 'net. |
17:34 | |
17:36
domidumont joined
17:39
domidumont joined
|
|||
nine | dogbert17: I wonder if the "+ sizeof(MVMuint64)" is actually necessary. I would guess that p actually points at MVMFixedSizeAllocDebug's "memory" attribute already, since that's what the alloc functions return. | 17:42 | |
dogbert17: you could try just removing that and see if anything breaks and if it silences valgrind | |||
dogbert17: talking about github.com/MoarVM/MoarVM/blob/mast...loc.c#L234 | 17:43 | ||
dogbert17 | nine: I'll give it a go, thx for looking | 17:47 | |
nine: now it looks like this: gist.github.com/dogbert17/bf57eded...5f55191bdd | 17:54 | ||
18:00
domidumont1 joined
18:59
zakharyas joined
|
|||
nine | dogbert17: that...looks the same as before | 18:59 | |
dogbert17 | except at the end | 19:01 | |
MoarVM panic: Spesh arg guard: unimplemented sparse guard case | 19:02 | ||
nine: can you see if anything else among those few lines of code looks fishy? | |||
memcpy(dbg->memory, (char *)p + sizeof(MVMuint64), new_bytes > old_bytes ? old_bytes : new_bytes); | 19:11 | ||
does dbg->memory really give us what we want? (my C fu is probably not up to snuff but I'll ask anyway :) | 19:12 | ||
19:25
lizmat_ joined
|
|||
nine | dogbert17: oh, that should probably be &(dbg->memory), since that is not really a pointer at all but just a placeholder | 19:44 | |
yes, that looks much better | 19:52 | ||
Geth | MoarVM: cfa1f2a1e7 | (Stefan Seifert)++ | src/core/fixedsizealloc.c Fix memory corruption when running with FSA_SIZE_DEBUG set dbg->memory is not a real pointer, it's just the placeholder for the actual memory area (that's preceeded by the allocated size). Also we don't have to offset (char *) by the size field as the allocator will already return the pointer to ->memory, so *p is already the start of the actual data. Thanks to dogbert17++ for pointing this out! |
19:57 | |
19:58
Kaiepi joined
|
|||
FROGGS | huh, my code works if I comment out this block: github.com/rakudo/rakudo/blob/mast...#L302-L314 | 20:06 | |
20:27
domidumont joined
|
|||
jnthn | Suspect github.com/MoarVM/MoarVM/issues/838 may be JIT-related | 21:29 | |
lizmat | wonder if www.abubalay.com/blog/2018/04/08/r...ive-ascent could have a comment in Perl 6 | 21:32 | |
jnthn | timotimo: About github.com/MoarVM/MoarVM/commit/a206cd8cd2 I think maybe www.felixcloutier.com/x86/ROUNDSD.html explains the 9 (it seems that it's a bit field) | 21:46 | |
timotimo: I'm wondering if github.com/MoarVM/MoarVM/issues/838 is due to this change | |||
timotimo | search for "roundsd sigill" | 21:47 | |
google finds "Game of Thrones - Round Sigil Herren T-Shirt - Schwarz - GrƶĆe XX ..." | 21:48 | ||
"glibc tries to use roundsd which is SSE4.1," | |||
well, damn | |||
that's definitely not on every machine | |||
jnthn | ah | 21:49 | |
lizmat | ah, no, conditional jitting depending on hardware :- | ||
( | |||
timotimo | yup | ||
dogbert17 is unable to repro github.com/MoarVM/MoarVM/issues/838 | 21:50 | ||
lizmat | probably because you have the right hardware | 21:51 | |
jnthn | Or the wrong hardware :P | ||
dogbert17 | AMD hardware | ||
jnthn | Asked the reporter if they could try with that commit reverted | ||
timotimo | it's very likely the commit is bad | ||
jnthn | Then we'll probably be pretty sure | ||
But it seems to fit | |||
timotimo | if it fits, i sits | 21:52 | |
hah | |||
this compiler implements floor as: | |||
jmp floor # TAILCALL | |||
i can implement it like that, too | 21:54 | ||
jnthn | github.com/MoarVM/MoarVM/issues/83...-379585747 | 21:55 | |
Seems older CPU, so it all fits | |||
No sse4_1 in the flags | 21:56 | ||
(Which I have in mine, and it works for me) | |||
timotimo | now the build system is upset with me | ||
at some point we'll want to cpuid, that's also not trivial from a very cursory google search | 21:57 | ||
ok, called Configure.pl and everything worked | |||
MasterDuke | aren't there some newish libraries for detecting hardware capabilities? | 21:58 | |
i thought i some some blog post about glibc or the clear linux team using one | |||
Geth | MoarVM: 4234ab56bf | (Timo Paulssen)++ | 2 files throw out problematic impl of floor_n in jit turns out the opcode i found requires at least sse 4.1, which we shouldn't require from our users Fixes #838 |
22:00 | |
lizmat | I guess on newer hardware that floor would use the sse4 opcode anyway | 22:01 | |
jnthn | True, though it'd be nice to save the function call overhead in the future :) | ||
timotimo | probably, yeah, but a function call has a little bit of overhead | ||
%) | |||
lizmat | so it's the sse4.1 that needs to be detected | 22:02 | |
timotimo | aye | ||
lizmat | and then c hanged into a compiler flag | ||
timotimo | i mean, at some point we'll want to do stuff like ">>.floor packs bunches of doubles into sse registers and does multiple at a time" with our jit as well | ||
no, i'd prefer a run time check | 22:03 | ||
jnthn | It'd want to be runtime, I think | ||
lizmat | ok | ||
jnthn | Since distros don't package per CPU at *that* granulairty I guess | ||
lizmat | well, it's past my bedtime... good night! | ||
jnthn | o/ | ||
samcv | timotimo: can we just use glibc's implementation? | 22:04 | |
timotimo | so, when i was at the linuxtag 2004 i remember Arch being advertised as "the distro that sets i686 as the baseline" | ||
samcv: we are doing that now | |||
samcv | ah ok | ||
timotimo | well, whatever libc moar is linked to, of course | 22:05 | |
shouldn't be much difference for something simple like floor (famous last words) | |||
dogbert17 | jnthn: [Tux] found a SEGV in his CSV test suite | 22:08 | |
jnthn | dogbert17: Did you manage to repro or get any further info? | 22:10 | |
dogbert17 | yep, github.com/rakudo/rakudo/issues/1689 | ||
22:15
travis-ci joined
|
|||
travis-ci | MoarVM build failed. Timo Paulssen 'throw out problematic impl of floor_n in jit | 22:15 | |
travis-ci.org/MoarVM/MoarVM/builds/363886839 github.com/MoarVM/MoarVM/compare/c...34ab56bf7d | |||
22:15
travis-ci left
|
|||
timotimo | well, that didn't last | 22:16 | |
Unhandled exception: Probable version skew in pre-compiled 'gen/moar/stage2/QASTNode.nqp' (cause: no object at index 140537950791616) | 22:17 | ||
make: *** [NQPP5QRegex.moarvm] Error 1 | |||
i'll just pretend it never happened and restart | 22:18 | ||
dogbert17 | didn't samcv have the same problem? |