LemonBoy
LemonBoy
> I need to figure out a better way to debug.. Try running the program under gdb: `gdb ./sio_sine` and get a backtrace with `bt`, that should shed some light...
Ok, I've managed to reproduce the problem in a alpine chroot. The process crashes because the TLS DTV is empty, I believe it has to do with ZIg's obsession to...
More details please, do the tests modified in the linked PR pass? Can you print the values received by `__extendhftf2` and friends to check if the parameter passing is (somehow)...
Once you add the `-lsqlite3` your `#include` is not picking up the header file from `/usr/include` but the Zig-provided one in `lib/libc/include/any-linux-any/linux/fanotify.h`. Zig is adding a `-isystem /usr/include` right after...
I ran out of time to debug this but I've got a pretty good idea of what's wrong. The SROA pass kicks in and becomes confused by the `is_weak: bool`...
> 0.9.0 milestone, haha, ouch. > > LemonBoy are you saying that this is an LLVM bug, not a Zig compiler bug? It really sounds like one, you can (hopefully)...
> Do you think the problem is specific to boolean struct fields getting returned through (possibly multiple layers of) result locations? Hard to tell, the problem disappears if you touch...
Good news (?), I've managed to pin-point the bad code generation to an unfortunate interaction between the inliner pass and the SROA one. The bad news is that I don't...
I managed to shrink the test case down to ~200LoC (from ~7k), this is now ready to be reported upstream (@andrewrk can you open a ticket for this?). LLVM IR...
> This is either over-reduced, or the original IR is already broken, because alive2 says that the transformation is valid: That's weird, running it with `lli` prints two different strings...