ilmari diakopter: I noticed some places it uses fields named _offset as the size for memcpy 00:02
I hope that's just unfortunate naming
oops, the gist web ui is possibly not best suited for multimegabyte files 00:11
anyway: gist.github.com/ilmari/3a97aa414eafc95d4553
.raw are the raw ones, .uniq are deduplicated by source location
I've pushed a new ubsan branch with the serializer fixes 00:14
src/6model/reprs/MVMStaticFrame.c has one actually detected and a few more potential ones too 00:15
but now I have to go to bed
night, *
dalek arVM: 9fd64bd | hoelzro++ | src/io/asyncsocketudp.c:
Handle UDP recv with size=0

nread=0 is a valid result from recv; libuv uses it to signal empty datagrams or if a buffer is no longer in use		 02:05
02:25 FROGGS_ joined 06:14 TimToady joined, ShimmerFairy joined 07:46 cognominal joined 07:54 FROGGS joined 09:01 FROGGS joined 09:12 zakharyas joined 09:16 brrt joined
brrt good * #moarvm 09:16
nwc10 good *, brrt 09:19
brrt ohhai nwc10 09:58
jnthn morning o/ 10:20
brrt morning jnthn 10:21
nwc10 correct \o
jnthn Wow, backlog here today as well as #perl6...
timotimo good * 10:27
10:40 Peter_R joined 10:44 rurban_ joined
ilmari jnthn: gcc 5.2's -fsanitize=undefined (ubsan) is complaining a lot about misaligned accesses in moarvm 10:46
jnthn ilmari: We do platform probes on that stuff 10:48
nwc10 ilmari: I think that there's a bunch of #ifdef's or similar set up via the code called by Configure.pl based on the CPU type for "what does the CPU get away with"
jnthn Look for MVM_CAN_UNALIGNED_
nwc10 so, I assume, that if one undefines all of those, it's possible to get a build which doesn't assume anything naughty
jnthn Should be, yeah
nwc10 and everything that remains is (hopefully) real, and not noise
jnthn Maybe if configuring a build for use with ubsan, we should set those flags. 10:49
Well, set that we *can't* do unaligned
And then we will indeed catch the useful things
ilmari those defines don't cover 16bit accesses, which ubsan also complains about 10:50
nwc10 do we have a lot of locations with 16 bit accesses? 10:51
ilmari src/core/interp.c:1015:37: runtime error: load of misaligned address 0xdeadbeef for type 'MVMuint16', which requires 2 byte alignment
nwc10 is it viable to replace all the locations with a clean inline function, which hides the #ifdef mess for the "direct access" vs "memcpy" ? 10:52
ilmari #define GET_REG(pc, idx) reg_base[*((MVMuint16 *)(pc + idx))]
jnthn is a bit surprised we would be doing any unaligned reads in the *bytecode* 10:53
That's meant to be 2-byte aligned everywhere
nwc10 oh, interesting.
I'm slow here.
jnthn So something feels off about 2-byte issues in bytecode/validation
ilmari the validator is allocated on the stack as Validator val[1] in MVM_validate_static_frame 11:02
dalek arVM/sized-native-fixes: 7227678 | jnthn++ | / (6 files):
Ops to introspect type bits/unsignedness.
 11:04
ilmari why is that an array instead of just a scalar?
jnthn has no idea 11:05
ilmari not that changing it changed anything about the errors 11:07
it was added by Gerhard R in 933b8105daf132e1c3256c3cb98556fc731e6133 11:13
timotimo it's been a long time since i last saw gerd here :( 11:14
i mean ... not_gerd
if he could see us now, would he be proud?
ilmari hang on. Validator.cur_op is an MVMuint8*, but is being dereferenced as an MVMuint16* 11:20
brrt aye, that makes sense 11:26
a MVM op is 16 bits wide 11:27
timotimo perhaps it's just the offset is in bytes for some reason?
brrt but the minimum size of any argument is 2 bytes, iirc, so i'd be surprised if there was some way in which we'd get an uneven offset from the start 11:28
so either the start is not 16-bit aligned
or i'm wrong in my assumption
timotimo it kind of sounds like we have a fix on our hands 11:29
jnthn At a guess, the start is not aligned 11:30
brrt lunch & 11:31
ilmari adds some validation of that 11:35
*boom* 11:36
how can I get a stacktrace from the validation failure?
nwc10 run under gdb and breakpoint on the error reporter? 11:37
I forget how - google usually knows
ilmari or just gdb and run with --crash
timotimo then you can "print MVM_dump_backtrace(tc)"
ilmari which aborts on exceptions
timotimo um ... huh? Too many positionals passed; expected 3 arguments but got 4 11:50
at gen/moar/stage1/QAST.nqp:1852 (gen/moar/stage1/QAST.moarvm::0)
oh! 11:51
local changes
11:53 virtualsue joined 11:59 virtualsue joined
ilmari argh, pahole doesn't show unnamed structs, e.g. typedef struct {} Foo; 12:01
nwc10 ilmari: give up and have lunch? :-)
but, yes, argh 12:02
and also
ilmari++ # using pahole
jnthn 00002 nan loc_0_num 12:05
00003 trunc_n32 loc_1_num32, loc_0_num
00004 bindlex lex_Frame_1_$n_num32, loc_1_num32
Progress...
stmuk nan always makes me think of balti :/
jnthn mmmm
jnthn already finished eating all the jalfrezi he made... 12:07
Guess it will be something simpler for lunch today
Darn, now the code-gen is telling me off for various places I cheated in the past... 12:09
timotimo hah, the past always catches up to you, doesn't it? 12:12
dalek arVM/sized-native-fixes: 4ee8436 | jnthn++ | / (6 files):
Sized local/lexical reference taking ops.
 12:17
jnthn perl6-m -e "my num32 $n; say $n;" 12:35
NaN
phew :) 12:36
ilmari it looks like the bytecode segment in the _file_ is misaligned 12:40
jnthn Ouch
ilmari in ../nqp/src/vm/moar/stage0/nqp.moarvmq 12:41
bytecode_seg = 0x7ffff7f3b099
jnthn lunch, bbiab 12:44
ilmari: If you want to look into fixing that, then src/mast/compiler.c is the place, btw
ilmari jnthn: yeah, just found it
jnthn \o/
ilmari aha! vm->serialized_size = 301 13:04
nwc10 have you earned lunch yet? 13:08
diakopter I'll say 13:12
13:14 virtualsue joined
ilmari is confused by several places that increment foo_size by bar->baz_offset 13:20
specifically: output_size += writer->stables_data_offset, which is 119, thus misaligning everything after that 13:24
nwc10 git blame might reveal the culprit, and if it's a PEBKAC level bug 13:25
ilmari that bit has been unchanged since 2013 13:27
github.com/moarvm/moarvm/commit/a4...e9efd2R663 13:28
ilmari can't see it being initialised on the writer _anywhere_ 13:33
jnthn ilmari: It starts off zeroed because MVMSerializationWriter is MVM_calloc'd 13:43
And is incremented through a level of indirection
writer->cur_write_offset = &(writer->stables_data_offset);
ilmari yeah, I _just_ found that 13:44
jnthn Through things like that.
ilmari gives up single-stepping and sets a watchpoint
diakopter simple answer is to ensure alignment of those offsets whenever they're finalized 13:45
(doesn't address whether they shouldn't've become misaligned in the first palace though) 13:46
ilmari ++*(writer->cur_write_offset); 13:47
in MVM_serialization_write_ref
so if there's an odd number of refs, it goes wrong 13:49
diakopter but what's the unit of the pointer? 13:50
ilmari MVMuint32 *cur_write_offset; 13:52
diakopter k
(but wouldn't that still keep it aligned on 4 bytes?) 13:54
ilmari no, the offset is in bytes
stored in an MVMuint32
diakopter gotcha
ilmari the easiest fix for the odd alignment is to make the discriminator an MVMuint16 13:55
diakopter so then ++*(writer->cur_write_offset); isn't incrementing enough?
oh, it's only one byte
is this the only place it uses bytes? 13:56
jnthn ilmari: It was deliberately made smaller by nwc10 a while back to have a smaller serialization blob 13:57
If we're talking about the same discriminator, anyway
ilmari there are three places that increment cur_write_offset by one 13:58
jnthn var_int can increment it by and odd number also, I'd expect
ilmari instead of fixing it here, we could make sure to align the sections that are going to be directly mmapped 13:59
diakopter I'd say just bump the offset if it's odd before each time it's used in a calculation
since it's used in such few places 14:00
jnthn ilmari: Yeah, padding the sections is probably the way to go
diakopter (is that the same as what I said?) 14:01
surely it will still warn for things it reads that aren't directly mmapped 14:08
ilmari I think serialization.c:concatenate_outputs just needs to align each table appropriately 14:14
because the header has the offset and size of each section
diakopter I thought there were some internal relative references, but maybe not 14:15
for pointer fixups 14:16
or maybe that was in some imaginary branch I was working on <evil grin>
ilmari as far as I can tell (from a skim), each section is serialized independently 14:18
ilmari TIAS
worst case, it'll segfault horribly
do we have an align macro? 14:19
diakopter worst case, it will format your disk and infect your bios
ilmari that rounds a value up to the nearest multiple of some value
nwc10 there was already some "round up for alignment" code for some sections 14:20
ilmari no mention of round or align in serialization.c 14:21
diakopter jnthn: that last nqp commit might just speed some things up :) 14:22
jnthn: (at least I recall thinking, "I know this will be terrifically slow" when writing that line)
jnthn: (the line that your commit replaced)
ilmari nwc10: there's some stuff in compiler.c, but not in in serialization.c
nwc10 ilmari: the ones I I'm thinkng of were commented "Add alignment" in src/core/bytecode.c
ilmari nwc10: the bytcode is fine, it's the VM's other serialization stuff 14:23
if the result of concatenate_outputs ends up with an odd length, everything after that in the bytecode file ends up misaligned 14:24
so arguably compiler.c sholud safeguard against that too 14:25
nwc10 ah OK
diakopter gist.github.com/ilmari/3a97aa414eafc95d4553 # I'm curious to see how much this gets shortened after this fix
dalek arVM/sized-native-fixes: 6864de7 | jnthn++ | src/core/interp.c:
Fill out int extend/truncate ops.
 14:31
timotimo diakopter: what nqp commit were you refering to? i don't see anything appropriate in the commit log that could speed anything up :| 14:43
diakopter the commit immediately before my comment? in his branch? 14:44
jnthn Any speedups are welcome, but this is mostly about correctness. :) 14:45
Our code-gen for sized types has been utterly bogus
diakopter I was thinking of github.com/perl6/nqp/commit/2884c8a651 # but now that I think about it again, mebbe not
timotimo it doesn't remove the unbox or box, it even adds more code to that 14:46
diakopter well, the calls to coerce (which creates a runtime coercion) could be reduced 14:47
timotimo because of the removal of $got := $MVM_reg_void; ? 14:51
ilmari eek
[75516.418439] Killed process 18537 (moar) total-vm:8560752kB, anon-rss:7249592kB, file-rss:0kB
diakopter \o/ 14:52
ilmari guess how much memory my laptop has
diakopter (at least it killed it)
41 PB 14:53
ilmari after a several-minute swap storm
8GB
timotimo huh, what made it balloon up like that?
ilmari and 2GB swap
my attempt at aligning the sections in serialization.c:concatenate_outputs 14:54
timotimo oops
diakopter heh maybe you made it align to 32MB instead
timotimo maybe something's incrementing and hoping to hit a limit exactly, but goes beyond it?
ilmari oh, that might be the fault of --debug 15:02
timotimo huh? i always build with --debug=3 --optimize=3 15:03
ilmari is it normal for moar to grow to 2GB when building stage1? 15:04
diakopter last I saw it, resident set was max 1 GB, even building rakudo 15:05
ilmari tries with a completely unmodified master moarvm and nqp 15:16
--ubsan --debug=3 --optimize=3
it hit a 4GB ulimit compiling gen/moar/stage1/NQPHLL.moarvm 15:17
diakopter well I suppose it could be 100,000 UBsan guards? 15:18
ilmari but it was working earlier, damnit 15:19
ilmari bumps the ulimit to 6G
diakopter gist your diff? :) 15:20
15:21 pyrimidine joined
ilmari compiling gen/moar/stage1/nqpmo.nqp took 2G 15:21
jnthn o.O 15:22
ilmari that's with clean master
diakopter how sure are you it's clean
ilmari I just did git stash; git clean -xfd
and installed into a fresh prefix 15:23
diakopter but for which repo
ilmari both moar and nqp
QRegex took about 2.731g
let's see if 6 is enough for NQPHLL
diakopter but if nqp doesn't think it needs to reconfigure moar, it won't 15:24
ilmari I did git clean in nqp too
[Coke] "fresh prefix" should handle that.
since there is then no moar for it to find.
ilmari juust about managed to sneak in under 6G for NQPHLL
diakopter [Coke]: I've seen it use a moar from outside the install 15:26
outside the install requestedsuch as, a previous install or path
ilmari bah, failed at QAST.nqp 15:27
ilmari tries without ubsan
and now I haven't seen it go over 100m, with a 1s update interval in top 15:32
ubsan-- # memory hog
timotimo :(
diakopter ilmari: I bet if you do --no-jit it'll be a lot less 15:33
(I think it instruments all executable memory?)
er, lol maybe not. 15:34
timotimo wouldn't that be a bit hard to make work?
diakopter gets more coffee 15:35
[Coke] diakopter: have you seen that recently? 15:46
diakopter not sure
not that I remember clearly, no
we definitely sacrifice some dependency clarity and simplicity with the convenience of the recursively configuring thingie. 15:47
[Coke] ok. hopefully no longer an issue, but I dunno.
diakopter I suppose theoretically there's a way to rewrite history to merge two git repos XD (moar into nqp) 15:53
hoelzro you could probably do it with git-filter-branch 15:55
diakopter though I guess if anything would be more logically tied from a user perspective, it's rakudo & nqp
jnthn But we won't be.
hoelzro not saying it's a good idea, but...
;)
diakopter jnthn: what about making a version of configure that can make a combined Makefile 15:57
jnthn Um...it'd be possible, not sure why we would? 15:58
diakopter well it could at least rule out mysterious dependency issues if they keep cropping up 15:59
dalek arVM: ee0afc2 | jnthn++ | src/core/validation.c:
Validate lexical types properly.

This means that we catch invalid code-gen for storing wrongly sized values into lexicals, and vice versa.		 16:01
arVM: d23cbe2 | jnthn++ | src/core/interp.c:
Implement truncate/extend ops for num32.
arVM: d6544f5 | jnthn++ | src/core/interp.c:
Fix cast; JimmyZ++.
diakopter I'm guessing that's a merge 16:02
dalek--
jnthn yes 16:03
ilmari is it normal for moarvm file sizes to randomly vary? 16:05
diakopter giggle, :p 16:06
ilmari I was trying to measure alignment overhead, and found that aligning to 4 bytes made the stage0 files 564 bytes smaller overall
diakopter *boggle*
ilmari and now I rebuilt it twice with 8 byte alignment, and it varied by 16 bytes betwen those runs
lizmat ilmari: some hash bucket size / linked list issue ? 16:07
ilmari might be
anyway, the overhead of even 8-byte alignment is negligible
lizmat I mean, on Perl 5 2 successive runs don't generate the same hashes either, do they ?
ilmari no
diakopter but hashes aren't serialized that way
maybe GC needs to flush the nurseries before serialization 16:09
dunno
jnthn serialization is over a live object graph, not just a memory dump
So shouldn't be an issue.
ilmari so, now, with hopefully properly-aligned bytecode files, let's see if ubsan still complains 16:10
16:10 dalek joined
ilmari being home sick makes me miss my work workstation 16:13
my laptop is only a dual 2GHz Core i7, at work I have a quad 3.2GHz Xeon 16:14
3rdparty/sha1/libsha1.a takes ages to link with ubsan
no, it must be something else, that was just the last thing that _started_ linking 16:15
ubsan.configure.uniq: 4 insertions(+), 658 deletions(-) 16:21
ubsan.make.uniq: 5 insertions(+), 817 deletions(-) 16:26
ubsan.test.uniq: insertions(+), 832 deletions(-) 16:30
16:32 domidumont joined
timotimo is that 0 insertions? 16:33
ilmari now, that was 6 16:34
now building without MVM_CAN_UNALIGNED_*
ubsan.configure.uniq: 447 deletions(-) 16:39
40 left
timotimo wow, that's nothing!
almost
ilmari gist.githubusercontent.com/ilmari/...igure.uniq 16:41
16:42 virtualsue joined
ilmari the remaining ones are mostly doing GET_I32() on an op argument 16:42
which may or may not be alined, since ops are variable number of 16bit long 16:43
s/number/multiple/
ubsan.make.uniq down to 52 16:44
gist.githubusercontent.com/ilmari/....make.uniq 16:45
timotimo do we need a bytecode munging phase that blows it up so that everything we may want to read in isolation is aligned to 32bit?
16:56 domidumont joined
ilmari any 32bit literal operand needs to be aligned 17:00
jnthn Not really 17:01
Or at least, not if you have something that can safely read it anyway
Which afaik we do, and that's what the alignment probe is seeing if we need
ilmari jnthn: even with the alignment probe neutered, there's lots of unaligne reads 17:02
jnthn So, we should probably fix where they're happening 17:03
Not bloat the bytecode
ilmari you can move the complexity into the GET_*32 macros instead
jnthn Yeah, I thought they were paying attention to the alignment probe's results 17:04
ilmari but then you need to copy the value
the code only actually respects MVM_CAN_UNALIGNED_(INT|NUM)64 17:06
jnthn Copying the value is OK; on platforms where we really want to invest in performance we'll build JIT support, and then the hot paths won't hit such copies. 17:09
ilmari to support archs that can't do unaligned 32bit reads we'd need eqivalents of MVM_BC_get_[IN]64 17:10
maybe ubsan should imply no MVM_CAN_UNALIGNED_*, to reduce the noise 17:11
jnthn +1 to both of those
ilmari jnthn: you forgot to rebase sized-native-fixes before merging 17:15
so it overlaps my memc(mp|py) branch
that might be why dalek got conffused
jnthn I didn't forget to rebase, I just tend to use the merge workflow when I do things that knowingly have broken points along the way. 17:16
dalek doesn't really look at the topology at all, though
So it's very easily confused. 17:17
ilmari prefers rebase + merge --no-ff
so you get linear history, but commits grouped by topic
jnthn That's a nice way to do it. 17:18
jnthn will keep that in mind
ilmari gist.githubusercontent.com/ilmari/...n.all.uniq 17:27
that's all the distinct error locations when running nqp configure+make+make test
on github.com/ilmari/MoarVM/commit/24...686e94d14a with MVM_CAN_UNALIGNED_* undefined 17:29
the ALIGN macro should probably be centralised
timotimo everything includes every header anyway, so it can go into some headery place 17:30
it may want a more mvm-specific name, though
ilmari ALIGNOF is defined in moar.h, so sticking it next to that
MVM_ALIGN_SECTION?
jnthn Seems reasonable 17:31
timotimo yeah, sounds a bit better
jnthn Think it's dinner time :) 17:32
ilmari gets ready to order pizza 17:55
timotimo mhhh pizza
diakopter ilmari: that's.... dramatically smaller 18:35
(list of errors)
ilmari diakopter: yeah
diakopter ilmari++
diakopter guesses a speed improvement from alignment too
I'm high on the wishful thinking today, apparently 18:36
ilmari depends on the CPU
timotimo that's *very* wishful thinking
ilmari I don't think there's any difference on x86
timotimo especially in deserialization which is mostly sequentially read
BBIAB
diakopter this one's interesting 18:41
src/core/interp.c:323:65: runtime error: signed integer overflow: 4611686018427387904 + 4611686018427387904 cannot be represented in type 'long int'
seems like it couldn't be a pointer value...
ilmari bah, I've rebased since then, so the line numbers are all out of sync 18:46
timotimo oh
18:53 vendethiel- joined
dalek arVM: 2c0b70f | timotimo++ | src/spesh/dump.c:
dump "known to be RW container" flag to speshlog, too.
 18:58
arVM: 15de300 | (Dagfinn Ilmari Mannsåker)++ | build/probe.pm:
Disable unaligned reads under UBSAN

We only enable unaligned reads on CPUs we know can handle them, but UBSAN flags them up regardless. This reduces false positive noise (and memory consumption) when looking for actually-harmful undefined behaviour.		 19:02
arVM: 98d6c9c | (Matthew Wilson)++ | build/probe.pm:
Merge pull request #313 from ilmari/ubsan-no-unalign

Disable unaligned reads under UBSAN
arVM: 758c3fe | (Dagfinn Ilmari Mannsåker)++ | src/ (3 files):
Align bytecode sections to 8 bytes

The bytecode file gets mmapped, and pointers to larger types inside these sections dereferenced directly, so make sure each section starts on a maximum alignment boundary. The internal aligment in each section is the responsibility of that section's (de)serializers.
This only increases the size of the NQP stage0 bytecode files by about 1735e2a | jnthn++ | src/core/interp.h: Add missing unsigned operand types.
diakopter oh dalek
19:19 FROGGS joined
ilmari it's the add_i 19:19
op
timotimo i kind of feel like we'd really want to have constants in nqp, so that we don't have to emit getlex for $MVM_reg_* numbers everywhere 19:32
but our compiler is already somewhat fast ... at least compared to parsing stuff 19:33
19:34 vendethiel joined
jnthn timotimo: Yeah, adding constants in NQP is one of my todos for after xmas :) 20:12
[Coke] jnthn++ btw 20:16
lizmat TimToady: on the issue of security and visibility, maybe "use nqp" should be something like "use NOT-QUITE-PERL;' ? 20:17
jnthn oh no, not more renaming 20:18
jnthn vetos just because he can :P
timotimo nqp gives you the most dangerous ops 20:25
but so does nativecall
jnthn Except...we use all those ops to implement Perl 6 features anyway :P 20:26
So you can get at 'em already.
timotimo hehe 20:27
20:36 brrt joined
lizmat well, we implemented 'use nqp' as a deprecation 20:38
perhaps we should remove the deprecation before Christmas
and simply just disallow unless we have a 'use nqp' in scope 20:39
jnthn yes, should remove the deprecation 20:43
timotimo aye 20:44
[Coke] there should, IMO be no deprecations shipped this month
lizmat okidoki, will take care 20:46
[Coke] lizmat: you feeling better? 20:50
lizmat sorta, not really 100% yet... 20:56
jnthn A proper flu :( 20:57
lizmat started on the way back from LPW, so probably some fresh virus from people with young kids :-) 20:58
arVM: 6be6fe8 | jnthn++ | tools/update_ops.p6:
Teach op build tool about uint*.
ilmari should I send a pull request for rebootstrapping nqp with the alignment fixes in moar, or does someone fancy just doing it? 21:29
jnthn I'd leave it a bit just in case we have another reason to, given every time we do it the git repo grows a bit 21:30
ilmari okay 21:31
timotimo a noticable bit, yeah 21:33
ilmari is there a disassembler/pretty-printer for moarvm bytecode files? 21:35
timotimo we have moar --dump foobar.moar 21:36
jnthn moar --dump foo.moarvm
timotimo jnthn: you know how malloc has a function that spits out some information about its "health"? stats and such? 21:41
dalek arVM: 71bea81 | jnthn++ | / (5 files):
Clean up uint ops; implement uint trunc/extend.

None of these are being used yet.		 21:42
arVM: ecedaec | jnthn++ | src/ (15 files):
Add box unsigned to REPR boxing API.
arVM: 989506b | jnthn++ | / (6 files):
A handful of extra unsigned int related ops.
timotimo i wonder if we'd want to have that output in the profiler, too. like, at every GC run we just put the info into the output and into the html
ilmari writes a moardump script and sets it as textconv for *.moarvm files
jnthn timotimo: hmm 21:45
timotimo: Guess we'd have to probe for it
timotimo probably
i even forgot what it's called, but i think hoelzro played around with that before
dalek arVM: 1ac6420 | jnthn++ | src/mast/compiler.c:
Teach assembler about unsigneds.
 21:48
ilmari jnthn: did you mean to change the last parameter of MVM_repr_set_int to MVMuint64? 21:49
jnthn No, and the compiler didn't whine at me about the inconsistent signatures either :/ 21:50
dalek arVM: 9da6022 | jnthn++ | src/6model/reprconv.c:
Undo accidental change; ilmari++.
 21:51
ilmari mine did 21:52
but I spotted it while browsing the recent diffs while it was building 21:53
jnthn :)
ilmari which compiler are you using? 21:54
jnthn MSVC
ilmari gcc 5.2.1 on linux here
src/6model/reprconv.c:553:6: error: conflicting types for ‘MVM_repr_set_int’
jnthn Nice 21:55
Fixed now, anyways
ilmari yeah, I noticed
jnthn Think that'll be enough for me today. Got some code-gen changes underway also to take advantage of this stuff.
ilmari cool
good night :) 21:56
jnthn 'night
lizmat good night, jnthn !
ilmari I converted the ubsan output gist to a proper repo: github.com/ilmari/ubsan-moar 21:57
21:59 travis-ci joined
travis-ci MoarVM build failed. jnthn 'A handful of extra unsigned int related ops.' 21:59
travis-ci.org/MoarVM/MoarVM/builds/97549391 github.com/MoarVM/MoarVM/compare/6...9506be4674
21:59 travis-ci left
ilmari the time- and pid-based compilation unit IDs are not going to make the reproducible build lot (e.g. debian) happy 22:14
dalek arVM: 875d761 | timotimo++ | src/moar.c:
allow %d to mean pid in MVM_SPESH/JIT/DYNVAR_LOG
 22:15
timotimo yeah :<
ilmari the instruction streams aren't stable either 22:17
00002 getcode [-loc_9_obj, Frame_37-]{+loc_20_obj, Frame_39+}
--word-diff, i.e. [- -] is removal, {+ +} is addition
timotimo ho-hum. something is being put into a hash? 22:19
flussence argh, I had a perfectly working moarvm .ebuild and today it's complaining about wrong -std= mode in for() syntax... 22:35
...which is weird because my bash script to build perl6 works fine...
flussence wonders if portage is being really dumb and using the gcc5.3 it just installed, even though I didn't set that as the default system gcc 22:36
er, anyway, the error there suggests either the makefile or code does need a fix: 22:42
«src/moar.c:28:9: error: ‘for’ loop initial declarations are only allowed in C99 or C11 mode»
timotimo damn, maybe i broke it. 22:47
it's probably me
give me a second, flussence
dalek arVM: 1ea71d4 | timotimo++ | src/moar.c:
pull declaraiton up front, use bigger vars
 22:48
timotimo flussence: try now -^
flussence oh! the stuff I built by hand just uses --gen-moar and not master, of course I wouldn't have seen failures there... trying now 22:50
yep, all good now 22:52
23:17 stmuk_ joined 23:45 rurban_ joined, virtualsue joined 23:58 stmuk joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!