<andrewrk>
fengb, yes exactly, just port over the llvm code
<andrewrk>
mikdusan, nice work. if I host this on ziglang.org want to try hooking it up in the CI on a branch and merging TheLemonMan's "moar simd" PR into it? (or feel free to hand off the task, of course)
<Kingsquee>
some condition I can use to typecheck for Qi and generate a @compileError if it's not
<mikdusan>
andrewrk: yes I'll try that but first against my local archlinux VM and then CI
<mikdusan>
LemonBoy comment in #4737 says linux failed due to qemu and the log shows a qemu-x86_64 execution... and I can see the test, but how can I tell on my re-run if it is a qemu test? is the "behavior-x86_64-..." vs. "behavior-native-..." indicate qemu?
<andrewrk>
mikdusan, the -Denable-qemu should do it
<andrewrk>
at least the musl and no-libc ones (the glibc ones require additional setup that takes a long time to obtain)
<mikdusan>
ok I think there is progress; with new qemu, #4737 rebased to master, local VM:
<mikdusan>
behavior.vector.test "behavior-aarch64-linux-none-Debug-bare-multi vector shift operators"...expected 1, found 8388607
<mikdusan>
I'll prep a CI change and PR soon
<andrewrk>
nice!
<andrewrk>
the great thing about that is that we now have a process to upgrade to newer qemus quickly
<mikdusan>
yeah and qemu dropped into my VM just fine too so that helps
<mikdusan>
andrewrk: #4905 is already merged
<mikdusan>
err hell I'm confused. #4905 is based'd off latest master, plus #4737, plus CI change to qemu. what else needs to be merged?
<andrewrk>
mikdusan, oh I was suggesting to do it *without* lemonboy's changes, and we can get that into master
<mikdusan>
ah ok
<andrewrk>
then the ball is back in TheLemonMan's court
<mikdusan>
ok so I'll close #4905 and the PR with ci bump to static-qemu5 is already open #4906
<andrewrk>
great work
<fengb>
Egads, these C macros make everything so hard to read :(
waleee-cl has quit [Quit: Connection closed for inactivity]
<andrewrk>
you might benefit from poking around zig's compiler-rt sources, some of those macros might have already been factored into some common helper functions in zig
<fengb>
I've never seen spaghettified code like this before >_>
<fengb>
I guess I have but it's been buried for awhile
<andrewrk>
mikdusan, looks like it's working great!
<mikdusan>
i can't believe that qemu tar.xz is only 28 MB
<andrewrk>
qemu is incredible
boothby has joined #zig
<mikdusan>
we can slice an array, slice a (pointer to an array), slice a slice, but how about slice a (pointer to a slice) ?
<andrewrk>
all the other ones have 1 indirection. a pointer to a slice has 2
<fengb>
`void __atomic_store_c(int size, void *dest, void *src, int model)` the order comes in as a runtime argument. Should I manually unroll that into comptime args?
<andrewrk>
it looks like __atomic_store_c is actually the __atomic_store symbol. so the ABI is important here
<andrewrk>
the model comes in as a runtime arg
<andrewrk>
I see what you mean about macro spaghetti
<fengb>
Yeah I pasted the easier to unwind piece :P
<fengb>
The Zig side requires a comptime order. I guess for more explicit maintenance, we should manually map the values over huh?
<andrewrk>
not sure if I understand, but generally to get from runtime to comptime you have to switch over the value and then each prong can use the comptime value
<fengb>
Right, I just mean manually switch each number instead of relying on @intToEnum
<andrewrk>
hm if you're asking whether the zig enums are ABI-compatible with the compiler-rt values I think the answer is no
<andrewrk>
so yeah I think the switch will be the best bet
<fengb>
This Zig code looks so much better than macros though :P
<andrewrk>
:)
<andrewrk>
in theory the optimizer would figure out if a switch was just mapping numbers to the same numbers and turn into a no-op
<fengb>
Ah good point
<boothby>
so I patched the //!(eof) and ///(eof) to emit doc tokens which won't be terminated in newlines. if that threw an error instead, it wouldn't be a special case for people building doc tools. thoughts?
<fengb>
Alright, I'm calling it for now. Have a good night!
<andrewrk>
night
ur5us has quit [Ping timeout: 240 seconds]
dddddd has quit [Ping timeout: 265 seconds]
boothby has quit [Ping timeout: 252 seconds]
cole-h has quit [Ping timeout: 256 seconds]
frett27 has joined #zig
_Vi has joined #zig
junon has joined #zig
<junon>
andrewrk: are you around by any chance?
BitPuffin has quit [Quit: killed]
pmwhite has quit [Quit: killed]
dtz has quit [Quit: killed]
pltrz has quit [Quit: killed]
ifreund[m] has quit [Quit: killed]
AlexMax has quit [Quit: killed]
ianc6209 has quit [Quit: killed]
Snektron has quit [Quit: killed]
sammich has quit [Quit: killed]
fengb has quit [Quit: killed]
alva has quit [Quit: killed]
BaroqueLarouche has quit [Quit: killed]
hryx has quit [Quit: killed]
afontain_ has quit [Quit: killed]
D3zmodos has quit [Quit: killed]
pmwhite has joined #zig
return0e has quit [Remote host closed the connection]
return0e has joined #zig
afontain_ has joined #zig
pltrz has joined #zig
BitPuffin has joined #zig
ifreund[m] has joined #zig
alva has joined #zig
dtz has joined #zig
AlexMax has joined #zig
sammich has joined #zig
BaroqueLarouche has joined #zig
Snektron has joined #zig
ianc6209 has joined #zig
hryx has joined #zig
fengb has joined #zig
D3zmodos has joined #zig
marijnfs has joined #zig
dermetfan has joined #zig
ur5us has joined #zig
<pixelherodev>
Using `errdefer` to reset state makes things so much easier
marijnfs1 has joined #zig
marijnfs has quit [Ping timeout: 256 seconds]
return0e has quit []
frett27_ has joined #zig
frett27 has quit [Ping timeout: 256 seconds]
<daurnimator>
junon: he usually goes to sleep ~3 hours before you asked. usually back in ~5 hours from now
<junon>
cool, thanks daurnimator :)
marijnfs has joined #zig
marijnfs1 has quit [Ping timeout: 265 seconds]
ur5us has quit [Ping timeout: 252 seconds]
ifreund has joined #zig
Kingsquee has quit [Read error: Connection reset by peer]
dddddd has joined #zig
<junon>
Trying to make a fix in the standard library but `zig test` is behaving oddly. Built master zig and installed it system-wide, then running `zig test lib/std/unicode.zig` gives me a plethora of errors (that don't normally exist when using the standard library).
<junon>
Am I doing something wrong?
<daurnimator>
junon: you shouldn't need to install to test
<daurnimator>
just run directly from your git clone
<junon>
running `build/zig test lib/std/unicode.zig` causes a permission error since `zig-cache` isn't generated.
<junon>
(where `build/` has the cmake compilation within it)
<daurnimator>
permission error? are you on windows by chance?
<junon>
amcos
<junon>
maocs*
<junon>
my goodness
<junon>
macos*
<daurnimator>
what is the permission error?
<junon>
`Unable to check cache: zig-cache/h: access denied`
<daurnimator>
why doesn't zig-cache exist?
<daurnimator>
it should get created as required.
<junon>
So if I run using the system installed `zig`, it generates it when I run `zig test`
<junon>
If I remove `zig-cache` and then run using `build/zig test` instead, it doesn't generate it at all.
<junon>
There's a bug somewhere, just not sure where or why - I thought that `build/zig` was the same executable that was installed system-wide.
<daurnimator>
that's odd....
<daurnimator>
yeah it is
<daurnimator>
can you try and run under `dtruss` and see for any weirdness?
<junon>
Yeah just confirmed with `shasum`, they're the same.
<junon>
o-o this is weirder
<junon>
running with dtruss gives me the same output as running it with the system installed zig
<junon>
performs the analysis and attempts a build, etc.
<junon>
oh the difference is elevated permissions daurnimator
<junon>
if I run `build/zig test` under sudo it works fine.
<junon>
(not that I want to do this long-term...)
<junon>
does `zig` get the sticky bit or something on macos?
<daurnimator>
nope
<daurnimator>
maybe some new apple mechanism?
<daurnimator>
maybe your home dir mounted noexec?
frett27 has joined #zig
junon has quit [Ping timeout: 252 seconds]
frett27_ has quit [Ping timeout: 256 seconds]
junon has joined #zig
<junon>
daurnimator: the code isn't in my home directory
<junon>
I have a /src/<github_user>/<repo_name> layout - never been an issue before.
waleee-cl has joined #zig
rzezeski has quit [Quit: Connection closed for inactivity]
<pixelherodev>
If I need to call a Zig function from JITed code, I need to `export` the function and use the platform's native C ABI?
<ikskuh>
you don't have to export it
<ikskuh>
just make it callconv(.C)
<pixelherodev>
Ah right
<pixelherodev>
Thanks!
tzekid has joined #zig
mahmudov has quit [Ping timeout: 264 seconds]
marijnfs has quit [Quit: leaving]
marijnfs has joined #zig
frmdstryr has left #zig ["Konversation terminated!"]
mahmudov has joined #zig
<daurnimator>
(or any other calling convention you care to use)
plumm has quit [Quit: Lost terminal]
<ikskuh>
dermetfan: just looked at the source of your directory includer
<ikskuh>
you can make that 100% allocation-free with just a bunch of string compares
frett27_ has joined #zig
frett27 has quit [Ping timeout: 264 seconds]
marijnfs1 has joined #zig
decentpenguin has joined #zig
marijnfs has quit [Ping timeout: 264 seconds]
<pixelherodev>
It works!!!
<pixelherodev>
I implemented a variadic function for generating function calls
<pixelherodev>
And based on argument type, it'll assign it a class and then register / stack space as per the x64 ABI
<pixelherodev>
`block.call(ebus.reset, self.parent.ebus); block.ret(); block.run();` JITs the equivalent of `self.parent.ebus.reset();` :D
tzekid has quit [Remote host closed the connection]
frmdstryr has joined #zig
<mikdusan>
junon: it is likely that because you have run zig as root, it create files/dirs with root permissions; now zig running as user will never be reliable until a cleanup is done. that cleanup involes nuking local and global caches, and anything else created by root
<junon>
mikdusan: that's not the issue; removing zig-cache entirely and running unprivileged results in the same error.
<mikdusan>
clarify: this also includes removing global cache ?
<pixelherodev>
The full thing runs in single-digit milliseconds and I can trace all of what it's doing and honestly say that there's not much room for optimization
cole-h has joined #zig
rzezeski has joined #zig
<fengb>
So ultra-fast debug build time?
lrosa007 has quit [Read error: Connection reset by peer]
<companion_cube>
what's that profiling tool?
<pixelherodev>
KCacheGrind
<companion_cube>
pretty cool!
<pixelherodev>
It's a frontend for CallGrind files
<pixelherodev>
I don't use KDE, but I still love it
<pixelherodev>
The alternative I've used is a small shell script that integrated with a GNU perf tool to generate a PNG
<pixelherodev>
Which was good
<pixelherodev>
But this is *interactive*
<TheLemonMan>
the new gnome sysprof is also nice
marijnfs1 has joined #zig
marijnfs has quit [Ping timeout: 256 seconds]
<andrewrk>
I've never tried gnome sysprof, I'll have to give it a spin
<pixelherodev>
Link?
<pixelherodev>
I found a page from 05
FireFox317 has quit [Ping timeout: 265 seconds]
<TheLemonMan>
I wonder how much time we could shave if the docgen steps were executed in parallel
<andrewrk>
that's all in zig code too
<andrewrk>
might be worth implementing a little something even before async I/O is stable
<andrewrk>
same with compile errors
<pixelherodev>
fengb, super fast, yes; however it still depends on the frontend speed
<pixelherodev>
Currently, waiting for Zig to emit LLVM IR takes most of the time
<pixelherodev>
Well, it would if not for the cache
marijnfs has joined #zig
Akuli has joined #zig
marijnfs1 has quit [Ping timeout: 250 seconds]
<TheLemonMan>
andrewrk, isn't #938 a prerequisite for that?
<andrewrk>
TheLemonMan, that would be a prerequisite for the async I/O route (which is where I want to get to eventually). But it's possible today to implement a simple thread pool and run (blocking) child processes in separate threads
<andrewrk>
it's such a shame too, the drone ci box has an insane number of cores and we only use 1 at a time
<andrewrk>
I've been focusing on climbing the "global maximum" (e.g. work on async I/O) rather than the "local maximum" (implement some thread pool thing for now to speed up test runs). but it is tempting
<pixelherodev>
Isn't it better to have short-term speed to make long-term gains easier?
FireFox317 has joined #zig
<FireFox317>
TheLemonMan, time to debug another bug with me?
<TheLemonMan>
FireFox317, sure thing!
<FireFox317>
behavior tests are passing, std tests not yet. Its hitting an udf in `hash_const_val`, but i can't reproduce it with a test case and also putting a breakpoint on there doesn't work because its called so often. backtrace: https://pastebin.com/PJ6iCHpq
frett27_ has quit [Ping timeout: 240 seconds]
<FireFox317>
did figure out the source_instr -> /home/pi/zig-source/lib/std/fmt.zig:182:35
<TheLemonMan>
hmm, line 5341 is empty for me
frett27_ has joined #zig
<TheLemonMan>
get a disasm so we can see why it's getting to the udf
<andrewrk>
are these udf's coming from building with zig cc in debug mode so that -fsanitize=undefined is enabled?
<FireFox317>
yes i think so andrewrk
<andrewrk>
neat
<FireFox317>
well i'm pretty sure this one also crashed in release mode
<andrewrk>
ah
<FireFox317>
not sure tho XD
<andrewrk>
well what was the -DCMAKE_BUILD_TYPE arg, if any?
<andrewrk>
the bootstrap repo hard codes it to Release
<FireFox317>
Yeah i changed it to Debug now, because i'm debugging and want a proper back trace :)
<andrewrk>
yep so zig is passing -fsanitize=undefined to clang, unless you overrode that flag with -fno-sanitize=undefined
<andrewrk>
it's likely you could reproduce this with zig built natively, passing -target to the std lib tests
<FireFox317>
TheLemonMan, oh probably this binary wasn't compiled with master, but its pointing at the beginning of the function, because that is where the udf is. I can't break on the function to see where exactly it is jumping to there, because `hash_const_val` is called so often
<TheLemonMan>
nice, get a disasm once you hit the udf
<TheLemonMan>
if it's stuck at the beginning the input may be null/non-aligned garbage
<FireFox317>
one moment, will build a zig binary of current bootstrap/master
<FireFox317>
hmm andrewrk, build release now (unintentionally) and still hitting the sigill.
<andrewrk>
hmm that is a mystery that I cannot explain
<FireFox317>
TheLemonMan, i'm not able to see how it ends up at the udf, because i can't break on `hash_const_val` because it is called so often. How would you conditionally break on that one?
<TheLemonMan>
uh, can't you just let it crash on the sigill and then get the backtrace?
<FireFox317>
yes, but it is a backtrace of functions. not a backtrace of what happend in the function itself
<TheLemonMan>
err, I meant disasm
<FireFox317>
i can, but it won't be clear which branch actually jumped to udf, there are a lot of checks which could branch to the udf. disasm: https://pastebin.com/F8Tuy5C2 udf at line 1356
<FireFox317>
that is why i need to break on the function so i follow which check actually jumps to the udf. but i'm not able to break on the function :)
<TheLemonMan>
well you said the backtrace points to the function start, if the debug infos are correct it means you're not going past the zig_assert
<TheLemonMan>
that narrows it down to only 4 possible branches
<TheLemonMan>
you can try with `b hash_const_val if $r0 == 0`
marmotini_ has joined #zig
marmotini_ has quit [Read error: Connection reset by peer]
<FireFox317>
hmm yes it does point to the assert, but i have a feeling that it is just pointing there because it doesnt know. addr2line on the udf also returns the beginning of the function, but it could end up there from anywhere in the function
<TheLemonMan>
right, debug infos are often untrustworthy, especially in release mode
<FireFox317>
but its zig in debug mode, but i found a way to break on the function. will check which branch will jump to the udf
<TheLemonMan>
I said _especially_, not only... the udf is introduced by llvm and so it has no mapping to the source file
<FireFox317>
ah yes indeed, my bad
<FireFox317>
TheLemonMan, okay its line 1252 in the disassembly that jumps to the udf. compiler_rt.__mulodi4 bug?
<TheLemonMan>
you have an overflow there
<TheLemonMan>
r0-r1 are a, r2-r3 are b and the overflow pointer is passed on stack
<TheLemonMan>
the ZigTypeIdEnumLiteral case
<FireFox317>
yes indeed, it should be doing a 32 bit multiplication there?
<FireFox317>
but compiler rt is doing a 64 bit one
<FireFox317>
TheLemonMan, maybe i have to put a (uint32_t) in front of the number?
<FireFox317>
or the number should be smaller such that it is not a long?
<TheLemonMan>
...how can a multiplication between two u32 overflow an u64?
marmotini_ has joined #zig
<pixelherodev>
Can't?
<pixelherodev>
Quick calculation says that the highest 32-bit number squared is 8589934590 less than the highest 64-bit number
<FireFox317>
jup, i'm still wondering why this was also caught in release mode
ur5us has joined #zig
<TheLemonMan>
integer promotion rules are tricky
<FireFox317>
Finally! Passed all the behavior and std tests on the raspberry :) So happy!
<andrewrk>
wow well done FireFox317 and TheLemonMan
<andrewrk>
that really made the difference between having a v7a tarball for 0.6.0 or not having one
<andrewrk>
I believe we can enable 32-bit arm on drone CI now too
<FireFox317>
one last thing i want to know is why it is still emitting all the safety checks in release mode
<FireFox317>
nvm i know why
<TheLemonMan>
andrewrk, #4737 is green, llvm is still fucking up the "nonstandard-sized" vectors on many arches
companion_cube has joined #zig
<andrewrk>
nice
<andrewrk>
idk what llvm expects us to do, this is how they set up debug info to work
<FireFox317>
andrewrk, it was my fault :) i still had a zig compiler on the aarch64 box that did not understand the -O3 flags yet, because i was so early using the bootstrap repo :)
<TheLemonMan>
well they begged us not to generate those weird vector shapes
<andrewrk>
I thought they said only to not store weird vector shapes in memory
<andrewrk>
but that's the only way to do debug info
<FireFox317>
wait, -O3 is a linker arg as well?
<TheLemonMan>
the weirdness doesn't stop there, in #4737 there's something going wrong with the array->vector->array conversion
<TheLemonMan>
and sometimes there are problems with such vectors being fn params
<andrewrk>
TheLemonMan, why does llvm miscompile? it looks like your new test only uses power of 2 bit sizes
<TheLemonMan>
the shifts are u5/u6 vectors
<andrewrk>
oh I see it now
<andrewrk>
wow you implemented a lot of SIMD ops
<andrewrk>
can you add a runtime safety test for the new safety checks you added?
<andrewrk>
(or let me know if you want a hand off)
<TheLemonMan>
if writing some test cases tickles your fancy then go for it! I was wondering how to do that without having to write a new case for each runtime check
<TheLemonMan>
and GH is down! time to log off then!
* TheLemonMan
dies
TheLemonMan has quit [Quit: "It's now safe to turn off your computer."]
<andrewrk>
why not a new test case for each runtime check? that's how it's done now
frett27_ has quit [Ping timeout: 256 seconds]
<andrewrk>
a github page that was already open and had the information I wanted already displayed, just changed itself into a 500 error page
<yrashk>
"undefined behaviour is not allowed in ZZ"
<fengb>
Hmm, it looks like it's trying to embed formal methods into an actual programming language?
<yrashk>
something like that (using an SMT solver)
<pixelherodev>
`a github page that was already open and had the information I wanted already displayed, just changed itself into a 500 error page` Just say NO to yavascript!
_Vi has quit [Ping timeout: 252 seconds]
<via>
can you have a struct with fields that are or are not there based on comptime values?
marijnfs1 has joined #zig
marijnfs has quit [Ping timeout: 256 seconds]
<shakesoda>
pixelherodev: ah, twitter syndrome
<andrewrk>
via, not really but you can have the field have a different type
<andrewrk>
such as void
dermetfan has quit [Ping timeout: 272 seconds]
<andrewrk>
I was able to build an i386-linux tarball with ziglang/bootstrap, check off 1 more tarball for the release
<Yardanico>
maybe I should try Zig again now that https://github.com/ziglang/bootstrap is there :P is it usable yet? (I'm cloning it rn and I'll try building for x86_64-linux-gnu)
<Yardanico>
ah nvm I can use "x86_64-linux-musl" which is OK
<andrewrk>
see the note about musl vs glibc
<Yardanico>
yeah I saw, just forgot that Zig uses musl by default (which is cool) :)
gazler has joined #zig
gazler_ has quit [Ping timeout: 240 seconds]
MrMobius has quit [Read error: Connection reset by peer]