Closed nyankers closed 2 years ago
This is a variant of the same problem, but now in the context of the JIT compiler. b = 0;
before the loop should solve the problem. Either DGD has to generate an initializer for b
, or the JIT compiler has to.
I didn't have time to test this until today; should be fixed by https://github.com/dworkin/lpc-ext/commit/1bbfa35f3ec299f80382dda3136a64a75cd58416.
Looks like it's fixed now, thanks! ^^
Now I just need to convince clang to stop crashing. I think my server has a super old version for some reason...
Looks like it's fixed now, thanks! ^^ Now I just need to convince clang to stop crashing. I think my server has a super old version for some reason...
@nyankers The JIT compiler should work with clang 3.8 and later. The crashing may be due to a malformatted LLVM source code file. Feel free to open an issue for it, if you can identify the actual .ll
file.
Ah, I'd deleted them when I cleared the cache, but sure thing. I wish there was an easier way to know which program goes with which .ll code, like if it could be commented in or something.
As far as I'm aware, dgd doesn't even send the program path (since JIT wouldn't be able to meaningfully use it anyway), but it's been a little while since I poked around there.
Ah, I spoke too soon. After the above change, cloud-server seems to throw a JIT error on boot-up and login as admin. Checking out before the above change, the error doesn't show up.
cache/22/228431a7bf3200b00fceb59b3bda826a.ll:6800:23: error: use of undefined value '%t140'
%c193 = icmp sge i32 %t140, %t141
^
It looks like the program failing might be /kernel/lib/wiztool.c
. I didn't catch this at first because only admin
uses that lib on my normal server, only saw it while trying to recreate another issue. ^^;
I reproduced it, it is indeed wiztool.c
.
Looks like it is, thanks!
While testing the other issue, I noticed after cleaning the JIT cache, another program was failing. After a whole lot of trial and error, this seems to be the minimum function to cause the problem:
This results in (after compiling twice and calling
f()
on it, for some reason?) an error much like the following: