<Snektron>
How is that implemented? Did you look up those hypothetical bugs or do you build on top of an existing project?
<daurnimator>
andrewrk: I noticed a WINNT version constant in that mingw PR. intentional? an extra place to update when we bump min windows version?
ur5us has quit [Ping timeout: 260 seconds]
ur5us has joined #zig
marijnfs has joined #zig
marijnfs_ has quit [Ping timeout: 265 seconds]
daex has quit [Ping timeout: 240 seconds]
daex has joined #zig
nephele_ has joined #zig
nephele has quit [Ping timeout: 265 seconds]
<wilsonk>
anybody know how to pass a '-W' flag to zig cc via a build.zig file? (ie. turn off a clang warning)
<shakesoda>
wilsonk: in second arg to addCSourceFile
<shakesoda>
i.e. exe.addCSourceFile("thing.c", &[_][]const u8{ "-Wno-return-type-c-linkage"})
<wilsonk>
ah, ok. I tried just adding it after -std=c99 in the first arg and it didn't work
<wilsonk>
thanks
<shakesoda>
it should work as long as you pass the different args as separate strings and not, say, space separated in the same string
<wilsonk>
oh, nvm...what I said didn't make sense...I mean I put my -W arg after -std=c99 in the second arg of addCSourceFIle and it didn't work.
<wilsonk>
ah, ok that makes sense then
<shakesoda>
like so (from my build.zig) : exe.addCSourceFile("extern/tinyfx/tinyfx.c", &[_][]const u8{ "-std=c99", "-D_CRT_SECURE_NO_WARNINGS=1" });
<wilsonk>
sweet, that should work
* shakesoda
thinks the syntax for writing these is pretty nasty...
<wilsonk>
can I force a specific clang that zig will use to link with? (not zig cc but just plain zig)
<wilsonk>
without modifying the source code ;)
a_chou has joined #zig
a_chou has quit [Client Quit]
a_chou has joined #zig
a_chou has quit [Client Quit]
ur5us has quit [Ping timeout: 260 seconds]
<mikdusan>
wilsonk: no
<wilsonk>
alright thanks mikdusan
<mikdusan>
if you're just trying to "hack" something or diagnose some issue, use "--verbose-cc" and "--verbose-link" and you can supply those command-line-args to any version of clang/ld.lld you have lying around
<daurnimator>
Has anyone used zig with GTK/GObject?
<pixelherodev>
Going to have to install GDB (and update LLVM/Clang while I'm at it)
<pixelherodev>
For now I'll just stick to debug mode
<pixelherodev>
Got runtime down to 49 ms in debug mode, of which at least 6% is error checking in a *single function* :P
<pixelherodev>
(an unreachable branch)
waleee-cl has quit [Quit: Connection closed for inactivity]
darithorn has quit [Quit: Leaving]
ur5us has joined #zig
dddddd has quit [Ping timeout: 256 seconds]
nephele_ is now known as nephele
ur5us has quit [Ping timeout: 260 seconds]
wootehfoot has joined #zig
ur5us has joined #zig
_Vi has joined #zig
ur5us has quit [Ping timeout: 260 seconds]
cole-h has quit [Quit: Goodbye]
ur5us has joined #zig
_whitelogger has joined #zig
_Vi has quit [Ping timeout: 260 seconds]
Cogitri has quit [Quit: killed]
Cogitri has joined #zig
ur5us has quit [Ping timeout: 260 seconds]
josch557 has joined #zig
jmiven has quit [Quit: reboot]
ifreund has joined #zig
jmiven has joined #zig
josch557 has quit [Ping timeout: 260 seconds]
Pursche01 has joined #zig
_Vi has joined #zig
<gonz_>
Has there been any progress on getting away from LLVM for development builds?
<ikskuh>
ask pixelherodev :D
josch557 has joined #zig
<gonz_>
mikdusan: Do you know why most/all debuggers on Windows have issues with lots of bindings missing even though presumably these exist in the pdb?
<gonz_>
VS seems to be maybe the most solid for zig atm, but also has issues with lots of identifiers being unwatchable, etc.
<gonz_>
mikdusan: Sorry if you're not the one to ask about this, by the way, I have some memory of you dealing with it at some point is why I ask.
mahmudov has joined #zig
jonathon has quit [Remote host closed the connection]
<ikskuh>
it would require only a shim that fakes the LLVM api used :D
<ikskuh>
then zig would emit PHD-IR :D
<ikskuh>
also: i just noticed a stupid design decision in a project of mine:
FireFox317 has joined #zig
<ikskuh>
decode a packet, allocate space on the heap, put the packet in a queue, … remove the packet from the queue, invoke a callback, delete the packet
<ikskuh>
all in the same call stack
<ikskuh>
looks like i can remove a whole allocation there! :D
<pixelherodev>
Well, if we port over even just the Zig IR then I could probably write a frontend for that
<pixelherodev>
Though I still need to finish the x64 backend
<pixelherodev>
(I'm writing it for the dynarec, but I plan on cross-pollinating the projects :D)
<BaroqueLarouche>
in the end, I think it would far easier to have a 68000 backend accepted in Zig alternative backend than LLVM itself
<kristoff_it>
ah yes that's it, sorry I should have searched more
<kristoff_it>
I was thrown off by another error I found before that
<andrewrk>
no worries
<andrewrk>
idk what's going on upstream
<andrewrk>
llvm devs have this weird way they build their software, and it results in config bugs like this all the time
FireFox317 has quit [Ping timeout: 256 seconds]
<pixelherodev>
I have a different compilation issue with LLVM 10 :(
<kristoff_it>
good luck man, I was able to paste the snippet from josephg from the GH issue and I'm already at the end of the things that I know how to do
<pixelherodev>
Gentoo defaults to building a single library clang-cpp, but Zig doesn't know how to link against it; simple enough that next time I upgrade I'll probably just fix it in Zig's CMakeLists.txt instead of, you know, *modifying the ebuild and adjusting the hash*
<pixelherodev>
Bigger problem though
<pixelherodev>
How would I investigate Zig hanging indefinitely and taking more and more memory?
<pixelherodev>
Current idea to `gdb -p $(pgrep zig)`
<kristoff_it>
btw if anybody's interested I'm currently streaming on twitch, I'm trying to debug a crash that I couldn't find the cause of a few days ago
<mikdusan>
pixelherodev: you can launch a cli with gdb. run it and when you think it's looping, hit ctrl-c
<pixelherodev>
Yes but that has longer start-up time, doesn't it?
<mikdusan>
is that important?
<pixelherodev>
Either way, I need to wait for Clang to finish building
<pixelherodev>
Well, it means it'll be more annoying to deal with
<pixelherodev>
(SSH connection died and so the emerge halted :_(
<torque>
use mosh and tmux at all times
<pixelherodev>
mosh?
<pixelherodev>
should've used tmux though, that's a good call
<andrewrk>
FireFox317, I got x86_64-windows-gnu bootstrapping successfully
<ForLoveOfCats>
I'm probably missing something but it seems that the online std docs have not been updated since late Feburary?
<ForLoveOfCats>
I'm sure this is a known thing, I just want to understand the situation :)
<ForLoveOfCats>
Or perhaps I'm being silly, just want to figure this out
<ikskuh>
andrewrk: \o/
<andrewrk>
ForLoveOfCats, yes the std lib docs are not updated automatically yet
<andrewrk>
ikskuh, now the question is: are we going to have 32-bit windows bootstrapping successfully in time for the release?
marijnfs_ has joined #zig
<ikskuh>
this will be an interesting release cycle for sure
TheLemonMan has quit [Quit: "It's now safe to turn off your computer."]
<pixelherodev>
Aren't they all?
<ikskuh>
yeah, true
KoljaKube has quit [Ping timeout: 246 seconds]
<FireFox317>
andrewrk, nice!! so cool, all this stuff is now possible with `zig cc`, it gets a big part in the release notes i guess? and its even a week old or something xd
bsrd has quit [Quit: WeeChat 2.7.1]
<andrewrk>
I think a bunch of potential users of zig cc are waiting for the release to check it otu
<ikskuh>
they changelog will be huge anyways again :
<ikskuh>
:D
<FireFox317>
kristoff_it, was nice helping you on stream :)
<kristoff_it>
thank you again FireFox317 :D
dddddd has joined #zig
dermetfan has joined #zig
ifreund has joined #zig
<pixelherodev>
I think the way `zig fmt` handles switches is going to force me to use if/else chains :(
<pixelherodev>
Ends up with more than 7 levels of indentation
<ikskuh>
use functions!
<pixelherodev>
This is one single operation though
<pixelherodev>
It's the x64 mov
<pixelherodev>
If going from imm to register, it's one path; depending on the register, it might have to use a different encoding (or might choose to because it's smaller/faster)
<ikskuh>
x64 mov is not "single operation" :D
<ikskuh>
it's turing complete :D
<pixelherodev>
There's also register to memory, memory to register, register-as-pointer to register, register-as-pointer to memory...
<pixelherodev>
I mean
<pixelherodev>
Technically
<pixelherodev>
Yes
<pixelherodev>
but also
<ikskuh>
do you know movfuscator?
<ikskuh>
someone has done it :D
<pixelherodev>
compiles C to mov?
<ikskuh>
yep
<pixelherodev>
yeah
<pixelherodev>
It's a single abstract operation, hypothetically
<pixelherodev>
The fact that there are enough permutations to be turing-complete isn't really the point
<pixelherodev>
Still, I might use internal functions
<pixelherodev>
Not a bad idea
<pixelherodev>
ugh
<pixelherodev>
I'mma switch over to a different project for now
<pixelherodev>
You know what, I'll leave it as a switch for now and mark it as TODO
<pixelherodev>
Better than getting frustrated now, I'll do it later when it won't bother me as much
<pixelherodev>
Ah
<pixelherodev>
Seems to be hanging on the InstructionCombiningPass in LLVM
<pixelherodev>
There a way to disable that in Zig?
<pixelherodev>
Going to leave it for a few minutes just to double check but I'm fairly certain it's that
<pixelherodev>
Yeah, and I'm pretty sure it's on a single function too...
<Snektron>
iksuh: mov is not completely Turing complete
<Snektron>
Unless you count jmp as mov
<Snektron>
movfuscator cheats by installing a signal handler for SIGILL
<Snektron>
The last instruction is an invalid move, then flow is returned back to the start via the signal handler
<ikskuh>
ah lul :D
<pixelherodev>
dangit
<ikskuh>
well, still valid :D
<ikskuh>
another solution
<ikskuh>
we just map enough memory to roll around
<ikskuh>
!
<pixelherodev>
better yet
<pixelherodev>
Map the same memory into the whole address space
<pixelherodev>
just a bunch of nops till it loops around
<pixelherodev>
:P
<pixelherodev>
Going to try overriding optimization level to 1 and seeing what happens
<pixelherodev>
Is it possible to have a specs-compliant incremental compiler for C?
<ikskuh>
what do you mean by incremental? just recompile what has changed?
<pixelherodev>
Yeah
<ikskuh>
you still have to relink though
<ikskuh>
MS is doing this afaik
<pixelherodev>
Weird that there isn't a FOSS one; there's a number of langs doing it already
<pixelherodev>
Still hanging with -O1 :(
<pixelherodev>
If I override to -O0, it produces faster code - technically.
<pixelherodev>
It also produces *invalid* code.
<pixelherodev>
:(
<pixelherodev>
Much much faster before it segfaults though
wilsonk has quit [Ping timeout: 250 seconds]
<pixelherodev>
Actually, I think debug mode is letting me do another thing I shouldn't be able to
<pixelherodev>
I'm `discard`ing on an empty FIFO
<pixelherodev>
Which causes a null pointer to be passed around
<pixelherodev>
Wait no, it should be static :(
<pixelherodev>
No wait I was right
<pixelherodev>
It's taking the address of a zero-length slice
<pixelherodev>
So even though the underlying array is defined, it produces an undefined pointer
<ikskuh>
huh
<ikskuh>
there are a lot of networking syscalls missing :D
<pixelherodev>
Now it segfaults formatting output in std.debug.warn :P
<pixelherodev>
I think this might be a good first thing to investigate in LLVM though
<pixelherodev>
Fixing the instructioncombining pass
<pixelherodev>
Ohhhhh I know why it's crashing in generated code
<pixelherodev>
I'm assuming C calling convention for e.g. available registers, ABI
<pixelherodev>
So when I call to functions that are now optimized to break that ABI, my generated machine code is no longer valid
Pursche01 has joined #zig
<FireFox317>
hey kristoff_it, i was looking into your issue with the docs generation. what was the last time your tried that? because i fixed the docs generation on march 4 (PR: #4616), i think it should work on master
<FireFox317>
work as in, not crash :) there are a lot of issues still with docs generation not having all the info etc, but it should generated some stuff
wilsonk has joined #zig
kristoff_it has quit [Ping timeout: 265 seconds]
<pixelherodev>
Is there a way to check release mode from within code?
dermetfan has quit [Ping timeout: 246 seconds]
<andrewrk>
std.builtin.mode
<pixelherodev>
Ah, thanks!
<pixelherodev>
Need to avoid calls to any functions not explicitly marked callconv(.C) within release mode, clearly
<pixelherodev>
Yep, now it works!
<pixelherodev>
Not really optimized (because of the crash), but still an improvement
<pixelherodev>
From ~170ms to ~20ms, so that's more than enough
<ikskuh>
andrewrk: I noticed the TailQueue(T)-struct from std allows arbitrary nodes to be removed from it (even if not contained)
<ikskuh>
do you think it's reasonable to check "is contained" in debug mode?
_Vi has quit [Ping timeout: 260 seconds]
<ikskuh>
and have an assert that checks this?
<fengb>
Doesn't that require iterating through the chain?
<ikskuh>
yep
<ikskuh>
but can catch some nasty errors like "i removed from this queue and now both queues are kinda linked?"
<andrewrk>
safety checks that change big-O complexity should probably be separately configured
<pixelherodev>
Maybe, but that's a long ways off; this is ~10 lines
<pixelherodev>
Currently I just forced OptimizationLevel to zero regardless of mode
<pixelherodev>
Which, interestingly, still provides massive speedups (~160ms to ~20ms as of my latest changes IIRC)
<pixelherodev>
I do want to look into the upstream bug eventually
<andrewrk>
I think workarounds should stay as workarounds and not get promoted to features
ForLoveOfCats has quit [Quit: Konversation terminated!]
<andrewrk>
which is a euphemistic way to say: sorry, you'll have to maintain that patch until the upstream issue can be sorted out (are you sure it's an upstream issue? it could be UB in your application)
<andrewrk>
valgrind might have some clues, idk if you mentioned you tried this yet
<pixelherodev>
andrewrk, certain.
<pixelherodev>
Because it's not that the code is running wrong
<pixelherodev>
the compiler hangs indefinitely
<pixelherodev>
The *compiler* crashes
<pixelherodev>
Both with Zig tarball and with locally built LLVM+Clang with LLVM_ASSERTIONS ON
<andrewrk>
oh, it's a compiler hang
<pixelherodev>
There is UB in my program, yes
<pixelherodev>
but that's a separate issue
<andrewrk>
yeah if I'm going to put any effort into this issue, it's going to be fixing the upstream bug, not implementing a general purpose workaround flag
<pixelherodev>
Which only got exposed once I overrode optimization level to 0, allowing the compiler to complete without issue
<pixelherodev>
No worries I get it
<pixelherodev>
Pretty sure it'll be hell to investigate though
<andrewrk>
infinite loops are usually pretty straightforward
<pixelherodev>
I don't mean it's like a while(true), but more like a mutually recursive loop or something
<pixelherodev>
Not completely sure
<pixelherodev>
eh, I'll look into it now
<pixelherodev>
What good is all the GB of LLVM source if not for debugging :)
<andrewrk>
oh it's an infinite loop in llvm's guts?
<pixelherodev>
Yeah
<pixelherodev>
Not in Zig
<pixelherodev>
In the InstructionCombiningPass
<andrewrk>
hm. there's a decent chance of getting an llvm dev to fix that if you put together a nice reduction
<pixelherodev>
Is there a usable tool for automatically reducing Zig?
<pixelherodev>
I remember vaguely something about that
<andrewrk>
no, but one person said that they got creduce to work for zig
<pixelherodev>
That's what I was thinking of, creduce
<pixelherodev>
Hoepfully it works
<pixelherodev>
But I want to investigate it myself anyways
<pixelherodev>
I plan on beginning contributing to LLVM a little bit over this year anyways, this seems like a good opportunity for learning more about it
<andrewrk>
you should be able to use --verbose-llvm-ir, copy that output to a .ll file, and submit that. llvm has an IR reducing tool
<pixelherodev>
Except for one problem
<pixelherodev>
*It hangs*
<andrewrk>
LLVMDumpModule is hanging? are you sure? that happens before LLVMEmitModuleToFile
<pixelherodev>
Ah okay then it'll be fine
<andrewrk>
--verbose-llvm-ir dumps to stderr, so you have to manually do a large copy+paste, but it should have your output
<pixelherodev>
Or just 2>a.ll
<andrewrk>
right but then you'll have to possibly delete extra junk
<andrewrk>
you can search for ; ModuleID or something like that
<pixelherodev>
I'm more than passingly familiar with LLVM IR at this point :D
<andrewrk>
:)
<pixelherodev>
No junk either, strangely
<pixelherodev>
It's valid IR
<pixelherodev>
Nothing needed deleting, I mean
<andrewrk>
I think if your compiler-rt is not already cached it would also be in there, and anything that happened to get printed to stderr, etc
<andrewrk>
just need to check, if it's clean, you're good 👍
<pixelherodev>
Ah
<pixelherodev>
Okay, yeah, I've built before so it's already cached
<pixelherodev>
Weirdness:
<pixelherodev>
if I manually run `opt -instcombine` it works fine
<pixelherodev>
... huh
<pixelherodev>
If I do `-O3` it fails though
<andrewrk>
can you repro the hang with clang -O3 ?
<pixelherodev>
I think there's an unrelated optimization that's messing up the code pre-instcombine
<pixelherodev>
You mean `clang IR -O3`?
<andrewrk>
nah, `clang -o foo foo.ll -O3`
<pixelherodev>
That's what I meant
<pixelherodev>
s/IR/file.ll
<pixelherodev>
Yeah
<pixelherodev>
Same thing happens
<andrewrk>
great, now it's proven to be llvm's fault and not zig
<mikdusan>
-very
<mikdusan>
-verify
<pixelherodev>
You mean `opt a.ll -verify [-S -o b.ll]`?
<pixelherodev>
How would I go about reducing the IR?
<pixelherodev>
Ah wait
<pixelherodev>
llvm-reduce is probably the way to go :P
<pixelherodev>
Might not be an upstream bug
<pixelherodev>
Reduced test case seems to think the IR is invalid
<pixelherodev>
Even though it seems fine with `clang -O0` ...
<pixelherodev>
Seems to think the debug info is invalid?
<pixelherodev>
`warning: ignoring debug info with an invalid version (0) in reduced.ll`