|
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? | ||