00:27 leont joined 01:23 colomon joined 01:34 geekosaur joined 01:44 geekosaur joined 01:46 geekosaur joined 02:56 vendethiel joined 04:18 geekosaur joined 06:26 japhb joined
nwc10 good *, #moarvm 07:34
07:48 zakharyas joined 07:56 patrickz joined 08:05 FROGGS joined 08:23 zakharyas joined 08:49 ShimmerFairy joined 09:54 zakharyas joined 10:04 brrt joined 10:06 leont joined
brrt ohhai #moarvm 10:06
i just had a mildly evil idea that i just can't find the flaw on yet
you might know that i've added a facility to extract the values used into a single tile out of the tree into a linear array; that is very useful for ensuring that values which should be in a register are actually there 10:07
as well as ensuring that values which are never further used are 'killed' 10:08
anyway, a very simple and practical difficulty in tiler linearisation is that i want to interleave the tiles with nodes representing the 'inter-tile-work' that is done by the compiler 10:11
that is to say, i want to insert loads, stores, labels, and conditional jumps, because that is all there is
bear with me; i'll get to the point :-)
these things all take integer values as arguments 10:12
i can store any number of integers in the expression tree as arguments
i can extract a number of intergers out of the expression tree, by the above-mentioned mechanism
hence, i can insert the arguments for these functions into the tree, and deal with them as i would with regular tiles 10:13
i can create fake pseudotiles, and all will be well....
but it's conflating of the tree and its' storage mechanism, for one thing, and reusing that storage mechanism for nefarious purposes, too 10:14
hence, big software engineering red flag 10:15
but, it will work
you may understand my dillema :-)
stmuk do I open MoarVM bugs on RT or GH? 10:28
brrt both are fine i think 10:29
RT is used a little more? but I use github personally
stmuk: what's the bug?
stmuk the build has recently broken on FreeBSD
I have a crude fix 10:30
but not sure putting an #ifndef __FreeBSD__ in is that good nice
ah its reported with a similar fix anyway 10:32
github.com/MoarVM/MoarVM/issues/311
brrt oh, yes, i can recall that 10:36
i don't like the suggested fix; it'll end up with a long list of platforms that have fileno defined as a macro 10:39
iirc, jnthn recently added the native-fileno method on file handles
i'd prefer renaming the function fileno to native_fileno or something like that 10:40
10:46 virtualsue joined, Peter_R joined
jnthn It ended up as native-descriptor 10:57
I think we'll go with something like that as the name in Moar too 10:58
brrt descriptor, that's the right term 11:04
timotimo yeah 11:12
brrt: if you have design decisions like that, why not "plan to throw one away"? ;P
see where it leads you?
brrt hmmm
good enough point.... 11:13
timotimo i don't really see the big trouble with using a pseudotile for the inter-tile compiler work
it reminds me a tiny bit of how PHI nodes are handled in spesh 11:14
those are fake, too, in that they have an opcode of MVM_SSA_PHI, but there's actually multiple info structs allocated for them, because every PHI node can have a different number of arguments
brrt well, there's another option, and i would like it best if it didn't involve a whole bunch of allocation work
which is, copy the arguments into an array..... 11:15
oh
that is not even a really bad idea
now that i think of it
i can just use a fixed-size array internal to the 'linear tile node' and pass it to the tile when it is time to emit it 11:16
that... fixes all my objections, which were (among other things) 'gee, isn't it a pain to manage a billion pointers for such a simple thing'
timotimo++ # you've just made my day :-D 11:17
timotimo <3
brrt (urgh, i'm entering the relative-overcaffeniation/under-caloric state, which means it is time for lunch) 11:18
timotimo i just had a tiny noms break my own self 11:25
i'm amazed i could pump out such good advice while nomming on some toast
jnthn is still on breakfast... :) 11:29
timotimo i've only had a miniature breakfast so far :) 11:30
dalek arVM: 1a896ff | jnthn++ | src/io/io. (2 files):
Fix build bustage where fileno is a macro.

Turns out that C macros don't C so well.		 11:43
nwc10 jnthn: "still"? surely any meal is correct when one is in UGT? 11:44
jnthn True :) 11:45
stmuk with regard to github.com/MoarVM/MoarVM/issues/311 the parans fix of cygx might be a good temporary solution allowing *BSD until fileno is renaming (which appears to be in multiple places?) 11:48
s/ing/ed
jnthn stmuk: I already did it above 11:50
stmuk d'uh
jnthn :)
stmuk :)
jnthn Don't have a BSD to test it on though, so that'd be appreciated by anyone who does
stmuk oh I thought it was renaming the opcode as well 11:51
I can test
jnthn opcode should be harmless
brrt has a bsd vm stashed somewhere 12:06
nwc10 1cc1: error: unrecognized command line option "-Wno-logical-op-parentheses" 12:10
ops
cc1: error: unrecognized command line option "-Wno-logical-op-parentheses"
OK, how do I get round that one... 12:11
--compiler=gcc 12:12
jnthn Upgrade to a newer clang? :P
nwc10 OK, bigger F-up
no, really, what we need is someone who understands Win32 and *nix to produce (or "buy in") a better configuration system that doesn't pre-code a bunch of assumptions
but, failing that
I get to fix the gnu-make assumptions
oh wait
gmake is installed
stmuk it works on NetBSD I'm just waiting for the old clunky clang to finish
nwc10 I'll ignore that bug for now too 12:13
stmuk clang36+ on FreeBSD is much faster than the default one
nwc10 I'm not root
stmuk nwc10: which platform is this? 12:14
nwc10 7.2-RELEASE FreeBSD 12:15
and I'm not going to say *where*, as IIRC that's out of security
stmuk hahaha 12:16
nwc10 OK
sorry,
build FAIL
there are gmake assumptions in the top level Makefile
stmuk it works (or worked) on FreeBSD 8.x
nwc10 and some sort of "doesn't like gmake" assumptions somewhere lower
oh, odd 12:17
`gmake -` *works* 12:18
MoarVM builds
stmuk nwc10: if you wanted a modern toolchain you could probably use pkgsrc with a prefix of $HOME/pkg or whatever 12:21
nwc10 I didn't know one could do that 12:22
stmuk its useful for people stranded on obsolete systems in industry :/ 12:23
nwc10 for now, I seem to be getting a viable build with the default ancient(ish) toolchain 12:24
stmuk an old gcc is probably faster than an old clang anyway :) 12:32
brrt nwc10, current version is 10.2 ? :-o 12:40
and yes, there are gmake assumptions
nwc10 something like that
brrt there is also special nmake magic i think
i wonder if the state-of-the-art in perl5 Configure.pl scripts has improved 12:41
i would *hate* to lose make, fwiw
also, i would equally hate to lose perl5-as-a-guaranteed-property-of-the-build process
nwc10 I'd love to see the assumption of perl *5* gone from the build process. 12:42
brrt but but but
nwc10 I'm biased.
brrt i use perl5 for my preprocessors
i'd have to rewrite everything in minilua :-P
nwc10 "rebuild" is different from bootstrap
brrt hmmm
stmuk I think removing perl 5 dependency from panda type installs should be first 12:43
brrt lets just say i wouldn't like to checkin the generated headers from preprocessing templates / tile descriptions
stmuk I don't think needing perl 5 to build is unreasonable
brrt thing is, something like luajit gets by *just fine* with a single makefile, no preconfiguring necessary 12:44
nwc10 I *do*
brrt configuring is imho an autotools legacy, and if we *can* get away without it, that would be better
nwc10 but that's because I don't want to mandate that someone keeps having to maintain Perl 5, just so that Perl 6 can build 12:45
but this is at the 10 year timescale.
but you're right that Panda is the thing to start with
work from that end backwards, and see where things go
stmuk anyway moarvm builds on all 3 major BSDs (I deleted my DragonFlyBSD sadly) 12:48
nwc10 stmuk++ 12:50
doing better than me
stmuk virtualbox++ 12:51
brrt i think people will be maintaining perl5 for such timescales whether we want them to or not 13:02
nwc10 oh yes, I don't disagree with *that*
but it shouldn't be forever 13:03
but start with Panda and work back
it should be viable for everything from NQP onwards to build without Perl 5, given that NQP already self-bootstraps with code written in NQP 13:04
and we're a long way from getting to that
which is "easy" (for a dubious value of easy)
"we" also need to address the toolchain code duplication between NQP and Rakudo
and all of that is probably more important and easier than any (semi) ideological purge of Perl 5 13:05
stmuk I rather liked the current perl configure scripts since they were very clear and better than most perl 5 I've seen
nwc10 they are pretty clear, but there are too many copies of the same code in 2 or 3 repositories
and there's too much assupmtion/not enough probing
(I'm biased) 13:06
but, as you said, start with Panda
stmuk certainly nicer than the usual auto* and the increasingly popular cmake
I think leont has a prove6 type thing already 13:08
brrt nods 13:17
yeah, the whole thing can be made much more robust
but there is so much encoded knowledge there....
pretty much nobody knows all that about all platforms 13:18
jnthn back 13:39
13:40 geekosaur joined 13:41 geekosaur joined
brrt ohai jnthn 13:54
jnthn o/ brrt
dalek arVM: 8aa4cd4 | jnthn++ | / (3 files):
Configure bits for \n -> \r\n on output.
 13:57
arVM: e7ebeb9 | jnthn++ | src/ (12 files):
Implement input newline translation.

Applies to all I/O handles except sockets.		 14:23
14:36 travis-ci joined
travis-ci MoarVM build failed. jnthn 'Implement input newline translation. 14:36
travis-ci.org/MoarVM/MoarVM/builds/97224178 github.com/MoarVM/MoarVM/compare/8...ebeb957a29
14:36 travis-ci left
jnthn I bet that'll be heisenbuild... :P 14:36
dalek arVM: 6935e94 | jnthn++ | / (30 files):
Translate newline \n -> \r\n on output.

When doing I/O for anything except sockets, and only when configured to do so (meaning "on Windows builds").		 15:01
jnthn heh, not heisenbuild :) 15:05
dalek arVM: 49f10b9 | jnthn++ | src/strings/normalize.c:
Fix missing intialization.
 15:07
15:16 travis-ci joined
travis-ci MoarVM build failed. jnthn 'Translate newline \n -> \r\n on output. 15:16
travis-ci.org/MoarVM/MoarVM/builds/97232730 github.com/MoarVM/MoarVM/compare/e...35e941dfc1
15:16 travis-ci left
nwc10 jnthn: t/moar/03-line-seps.t fails 15:16
not ok 14 - \r\n separator used
jnthn Yeah, that test is now wrong 15:17
Fixed locally
15:27 travis-ci joined
travis-ci MoarVM build failed. jnthn 'Fix missing intialization.' 15:27
travis-ci.org/MoarVM/MoarVM/builds/97233863 github.com/MoarVM/MoarVM/compare/6...f10b9b8651
15:27 travis-ci left 16:20 domidumont joined 16:21 zakharyas joined
brrt commute & 16:22
16:25 zakharyas joined 16:53 zakharyas joined
jnthn Seems we we aren't especially validating typevars properly 16:59
In the bytecode validator
Meaning we get away with spitting out bytecode for various things with very dubious behaviors
Like num32 lex being read into a num64 register, and vice versa 17:00
Without the appropriate coercion
timotimo that could be kinda bad 17:01
jnthn Yes, it's why num32 mis-behaves in rt.perl.org/Ticket/Display.html?id=124084 17:02
oh, it seems it does happen for reg reg, but not for lex reg or reg lex 17:03
I wonder how much chaos fixing this will cause 17:10
Well, nqp's make test still passes 17:19
And it catches the issue
C:\consulting\rakudo>perl6-m -e "my num32 $n; say $n;"
Bytecode validation error at offset 18, instruction 4:
operand type 40 does not match register type 48
timotimo ideally we'd complain at the compiler stage rather than at the bytecode validation stage 17:21
jnthn That's a nice to have :)
Running bytecode that's full of it is just really wrong :) 17:22
timotimo right!
jnthn Feel free to patch mast/compiler.c or so
(I'll probably only do that now if it makes debugging easier)
Well, NQP builds and passes tests with the patch. Now to see if Rakudo builds. 17:24
Phew, yes, it does :) 17:25
Blows up make test in a couple of places 17:26
17:33 zakharyas joined
jnthn And a couple of spectests, it seems 17:34
But seems everything it catches is genuine bad code-gen
timotimo very good 17:35
jnthn I'd guess the nativecall fails that it results in match up with native call fails on BE
17:40 virtualsue joined
dalek arVM/sized-native-fixes: 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.		 17:44
arVM/sized-native-fixes: d23cbe2 | jnthn++ | src/core/interp.c:
Implement truncate/extend ops for num32.
nwc10 *aha*, them
jnthn
.oO( The sun never sets on Big Endian )
Enough for now...will look at the code-gen fixes we need later 17:46
JimmyZ (MVMnum64)GET_REG(cur_op, 2).n64; # do you mean MVMnum32 here? 17:48
jnthn yes
dalek arVM/sized-native-fixes: d6544f5 | jnthn++ | src/core/interp.c:
Fix cast; JimmyZ++.
 17:49
jnthn That's exactly why I'll worry about the rest later :P
JimmyZ ;) 17:50
jnthn dinner &
diakopter jnthn: dare I suggest the nativecall fails are also related to what you saw on windows with the deserialization cache thing XD XD XD XD *Christmas Cheer*** 18:35
(yes I'm still gonna try to repro on windows)
18:52 leont joined 18:55 zakharyas joined 19:04 zakharyas joined 19:05 vendethiel joined 19:19 zakharyas1 joined 19:35 virtualsue joined
jnthn diakopter: Sadly, I highly doubt it...the bustage I've uncovered will be cross-platform. 19:37
19:49 FROGGS joined
diakopter oh 19:52
20:00 virtualsue joined
nwc10 jnthn: ASAN likes (OK, tolerates with the usual disdain) your branch so far 20:01
jnthn :) 20:02
20:25 virtualsue joined 20:54 virtualsue joined 20:58 zakharyas joined
ilmari wow, just running nqp's Configure on an ubsan-enabled moar spews tons of errors 21:25
it didn't do that a few weeks ago, iirc
laods of misaligned loads 21:26
src/core/validation.c:156:12: runtime error: load of misaligned address 0x7fcb21c463d9 for type 'MVMuint16', which requires 2 byte alignment
that's opcode = *(MVMuint16 *)val->cur_op; 21:27
and callsites_equal() passing null pointers to memcmp 21:28
hoelzro github.com/joyent/libuv/issues/414 21:29
that explains the UDP issues
FROGGS jnthn: could that explain the blowup? gist.github.com/FROGGS/bc20e5799a3...xt-L16-L23 21:30
TimToady went to bed
FROGGS ahh :o) 21:33
21:37 colomon joined
ilmari ubsan output from nqp Configure.pl run: paste.scsys.co.uk/502894 21:38
hoelzro wow 21:39
ilmari gcc 5.2.1-23 on debian testing
hoelzro these sanitizers are so cool
dalek arVM: 016bb5e | FROGGS++ | src/core/bytecode.c:
init cd->arg_flags so callsites_equal wont complain
 21:40
FROGGS sadly, this does not help
ilmari well, no, it's still passing null pointers to memcmp 21:41
if arg_flags == NULL is a valid state, callsite_equals needs to guard against that
diakopter ilmari: nopaste the error list? 21:46
ilmari diakopter: 21:38 < ilmari> ubsan output from nqp Configure.pl run: paste.scsys.co.uk/502894
diakopter ahah 21:47
gah 21:48
ilmari FROGGS: there are other places where arrays that would be zero-sized are not allocated, then add_foo functions blindly memcpy them 21:52
21:55 travis-ci joined
travis-ci MoarVM build passed. Tobias Leich 'init cd->arg_flags so callsites_equal wont complain' 21:55
travis-ci.org/MoarVM/MoarVM/builds/97320646 github.com/MoarVM/MoarVM/compare/4...6bb5ec9cae
21:55 travis-ci left
ilmari although in other places it does malloc(0) 21:56
but malloc(0) is allowed to return NULL anyway, so we can't rely on that 22:27
22:28 colomon joined
ilmari FROGGS: github.com/MoarVM/MoarVM/pull/312 22:54
FROGGS: fixes all null pointer memc(py|mp) in callsite.c and spesh/ 22:55
dalek arVM: 31bdb0f | (Dagfinn Ilmari Mannsåker)++ | src/spesh/ (3 files):
Avoid memcpy(x, NULL, 0) in spesh

Although most compilers sensibly do nothing in this case, it is undefined behaviour according to the standard, and UBSAN complains.		 23:13
arVM: c571752 | (Dagfinn Ilmari Mannsåker)++ | src/core/callsite.c:
Don't try to compare empty flag sets

This avoids calling memcmp() with NULL pointers, which is undefined behaviour, even is the count is zero.
diakopter ilmari: I merged it
show me a couple of the 6model ones you're not sure about 23:14
ilmari: which 6model things 23:26
ilmari diakopter: the ones in src/6model/serialization.c:concatenate_outputs 23:32
diakopter: ubsan only flagged the one for repos_table 23:33
this was just during 'make' of nqp
diakopter maybe ubscan divined that it couldn't definitively determine that the size sent to memcpy would always be zero when the pointer was invalid 23:34
ilmari I don't think ubsan does that kind of analysis 23:35
diakopter oh
ilmari null pointers to memc(py|mp) are undefined even when size == 0
diakopter well, is it a problem to send invalid pointers to memcpy when the size is 0? oh
I see
ilmari yes, it's explicitly undefined, presumably for speed/ease of implementation
diakopter yeah, the check for zero would need to be *somewhere*; might as well make the caller do it 23:38
ilmari and often you know that it can't be zero, so don't need to check 23:39
diakopter but yes, should add those checks to the 6model serialization too 23:40
most of those memcpy usages could theoretically be zero 23:41
ilmari 'nqp make' is up over 200k lines of ubsan output 23:51
mostly misaligned access
diakopter well hopefully it decreases non-linearly XD
ilmari I'll upload the full output pluss deduplicated by source code line 23:52

Powered by Cro and the Raku® Programming Language.

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

Thank you!