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?