japhb | jnthn: Good luck on the vote! | 00:12 | |
01:20
AlexDaniel joined
02:57
ilbot3 joined
03:35
Util joined
06:51
brrt joined
|
|||
brrt | good * | 07:08 | |
samcv: re names, why not suffix the ops with _strict | |||
so nqp::encode_strict() | |||
samcv | i could do that | ||
brrt | although | 07:09 | |
from a JIT compilers' perspective | |||
i'd rather have a nqp::encode_strict that would -fail- and then have the caller throw, than to have the op throw | |||
i'm not sure how practical that is | |||
because you'd need to return a boolean while taking a buffer-out argument | 07:10 | ||
07:52
domidumont joined
07:57
domidumont joined
08:04
brrt joined
08:42
brrt left,
brrt joined
09:41
AlexDaniel joined
11:43
AlexDaniel joined
12:03
SmokeMachine joined
12:27
Zoffix joined
|
|||
Zoffix | Reminder that there is a release blocker JIT bug R#1483 | 12:28 | |
synopsebot | R#1483 [open]: github.com/rakudo/rakudo/issues/1483 [SEGV][regression][⚠ blocker ⚠] Cross-HLL inlining segfault | ||
brrt | i know i know | 12:29 | |
Zoffix | I don't know anything about JIT but I could try to do the legwork for the fix if someone points to where to start. Ticket comments say "jit-bisect pinpoints it to a miscompile - in all probability in a template of sp_p6ogetvt_o." | ||
brrt | so | ||
i have a patch for part of the miscompile, | |||
but i have no patch for the other part of the miscompile, because i can't figure out what it is | |||
Zoffix | oh | ||
brrt | figuring that out takes time because it means stepping trhough the assembly and seeing what's changing | ||
which i can do | 12:30 | ||
but it's hard | |||
and takes time | |||
Zoffix | (that's probably a few levels up from my current skill level :)) | ||
brrt | i'd rather think a few levels lateral from your current skill level :-) | 12:31 | |
thing is, that template has been with us for a while | |||
Geth | MoarVM: 296620e862 | (Bart Wiegmans)++ | src/jit/linear_scan.c Register allocator should process all live ranges on worklist In order to ensure that we have set up function call arguments properly, we need to iterate over every tile during linear scan allocation, even after the last live range in the worklist has been processed. However, during tile processing we might still create new live ranges (e.g. when we spill a value). This fixes a miscompile in sp_p6ogetvt_o which affects rakudo issue 4283, but that issue is not fixed with this commit. |
12:44 | |
12:51
Zoffix left
12:57
notable6 joined,
coverable6 joined,
greppable6 joined
13:00
travis-ci joined
|
|||
travis-ci | MoarVM build passed. Bart Wiegmans 'Register allocator should process all live ranges on worklist | 13:00 | |
travis-ci.org/MoarVM/MoarVM/builds/339437956 github.com/MoarVM/MoarVM/compare/4...6620e86288 | |||
13:00
travis-ci left
15:27
lizmat joined
15:42
statisfiable6 joined
|
|||
dogbert17 | one of the examples given in RT #125978 tends to crash at the same place, i.e github.com/MoarVM/MoarVM/blob/mast...ue.c#L1214 | 16:24 | |
synopsebot | RT#125978 [open]: rt.perl.org/Ticket/Display.html?id=125978 [CONC] [SEGV] (and other crashes) when using .hyper | ||
dogbert17 | there's a slightly worrying comment a few lines above: /* Copy existing to new. | ||
* XXX Need more care here, as may have to re-barrier pointers. */ | |||
more specifically ASAN writes: ==21770== ERROR: AddressSanitizer: attempting free on address which was not malloc()-ed: 0x9f904c30 | 16:26 | ||
17:02
brrt joined
17:32
AlexDaniel joined
17:39
domidumont joined
17:51
Ven`` joined
18:43
Ven` joined
20:31
brrt joined
22:01
brrt joined
|