<andrewrk>
invalid IR still shouldn't hang the verifier
<pixelherodev>
It's not the verifier that's hanging though
<pixelherodev>
It's instcombine, and only if other optimizations run first
<andrewrk>
if the verifier says it's invalid, then instcombine is allowed to UB
<pixelherodev>
Verifier doesn't say that pre-reduction though...
<andrewrk>
I think you should submit the pre-reduced code then
<pixelherodev>
Yeah, double-checked...
<pixelherodev>
Think the reduction might be wrong
<pixelherodev>
Attempting a reduction with test=opt and test-arg=-O3 doesn't have a timeout
<pixelherodev>
So it never actually does anything
<andrewrk>
I think your reduce script is not detecting the correct thing
<andrewrk>
your reduce script should look for the crash instead of a verifier error
<pixelherodev>
I know
<pixelherodev>
That's what I said
<pixelherodev>
:P
<andrewrk>
ah apologies I missed that
<pixelherodev>
no worries
<pixelherodev>
Thanks for pointing out i should be using a script
layneson has quit [Quit: WeeChat 2.4]
FireFox317 has quit [Ping timeout: 256 seconds]
joey152 has quit [Quit: Leaving]
<pixelherodev>
No wonder the test was producing invalid IR
<pixelherodev>
I was accidentally using "can it compile" as the test
<pixelherodev>
so it broke it down further and further until it couldn't :P
<pixelherodev>
Seems to be working now, but it's taking a while (because it's ~5s per failed attempt and the goal is to keep going until it stops failing)
<pixelherodev>
Gah, test is still wrong :(
Pursche01 has quit [Quit: Connection closed for inactivity]
<andrewrk>
I have a 32-bit windows bootstrap tarball now too
<pixelherodev>
Awesome!
<andrewrk>
dare I try aarch64-windows-gnu??
<andrewrk>
I've never even heard of an arm machine running windows
<daurnimator>
andrewrk: windows RT laptops/tablets
<daurnimator>
oh that was arm32
<andrewrk>
mingw-w64 supports both 64 and 32 bit arm
<daurnimator>
seems like the Lenovo Miix 630 is one such device
<daurnimator>
I remember seeing them in stores
<daurnimator>
andrewrk: did you see my note yesterday about using a git subtree in the bootstrap repository?
<daurnimator>
(I agree with you about submodules being bad!)
<andrewrk>
anyway compared to 0.5.0 we're going to have +7 new binary tarballs as part of the release, and +1 new source tarball
<andrewrk>
oh, are "git subtrees" different than submodules?
<daurnimator>
yes
<daurnimator>
submodules are a reference to an external repository
<daurnimator>
subtrees are a way to keep a copy of another repository as a subdirectory
<andrewrk>
that does sound relevant. but why would I want it when not having it is working perfectly?
<daurnimator>
means you can track references easier; and there's a built in way to update it :)
<daurnimator>
essentially its the git blessed way of doing what you're already doing
<daurnimator>
in bootstrap it would look something like: `git rm zig/ && git commit -m "Delete zig in preparation for subtree" && git subtree add --prefix=zig https://github.com/ziglang/zig --squash`
<shakesoda>
andrewrk: there are a few modern arm windows machines
<pixelherodev>
There are modern Windows machines? Blasphemy
<shakesoda>
you can also run windows on pi 3's etc if you like
<shakesoda>
not that you, like, should
<shakesoda>
you just can
<andrewrk>
cool. well, I'll leave it to an enthusiast to work on the ability to get zig bootstrapping for arm-windows-gnu and aarch64-windows-gnu
<andrewrk>
daurnimator, let me look into that after the release is tagged
<andrewrk>
right now I'm throwing patches around left and right and happy with the workflow
<andrewrk>
btw, can somebody please appreciate that despite this bootstrap repo supporting all these targets, the clang, lld, and llvm sources have no patches against them, and the build script has no branching logic
<daurnimator>
andrewrk: I noticed you deleted the `test` directories out of them :)
<andrewrk>
yes, however I think it's fair to not call that a patch
<andrewrk>
really, it's shaving off cruft so that the source tarball can be smaller
<daurnimator>
also some vscode config file is missing (not that it matters)
<andrewrk>
no affect on logic; with those files restored the behavior is the same
<daurnimator>
andrewrk: but yes; aside from removal of inconsequtial files, its nice that there's nothing changed from upstream llvm release
<daurnimator>
I'm also impressed you managed to write a POSIX shell script.
<daurnimator>
I had to check a couple of things but it seemed all clear :)
<pixelherodev>
...?
<pixelherodev>
What's so impressive about a POSIX shell script?
<daurnimator>
pixelherodev: its far too easy to accidentally use a bashism
<pixelherodev>
True
<andrewrk>
posix shell is more portable. usually it's pretty pedantic to care, but the explicit goal of this project is "minimal system dependencies"
marijnfs_ has joined #zig
<andrewrk>
it also should have an equivalent `build.bat` script, which Sahnvour has a WIP version of
marijnfs has quit [Ping timeout: 258 seconds]
ur5us has quit [Ping timeout: 260 seconds]
nephele_ has joined #zig
nephele has quit [Ping timeout: 260 seconds]
ur5us has joined #zig
<mikdusan>
`${TARGET_OS_LOWER^}` is that posix?
<pixelherodev>
Easy way to check: run it with /bin/sh
<pixelherodev>
Yep
<fengb>
That’s linked to bash under many systems
<pixelherodev>
Not mine
<pixelherodev>
Or.
<pixelherodev>
drat
<pixelherodev>
Stupid lying PoS
<fengb>
I only remember Alpine and Ubuntu as the last holdouts
<pixelherodev>
That's one reason I love Alpine
<waleee-cl>
voidlinux uses dash as /bin/sh
<pixelherodev>
That's scarcely better innit?
<pixelherodev>
Can't believe I had to *patch* llvm-reduce to do this :(
<pixelherodev>
I don't even want to know how much power it's wasted on this
<waleee-cl>
mostly in comment to Alpine and Ubuntu as the last holdouts of /bin/sh != bash
<pixelherodev>
I know, I'm saying that dash isn't exactly much of an improvement
<pixelherodev>
Alpine and Ubuntu are the last holdouts of /bin/sh == POSIX
darithorn has joined #zig
<fengb>
Ubuntu uses dash... I just meant they aren't bash
<fengb>
What's wrong with dash?
<pixelherodev>
Isn't it also not POSIX?
<fengb>
I don't think any shell is strictly only POSIX, but it's the one people talk about supporting when getting rid of bashisms
<pixelherodev>
Yes! It worked!
<pixelherodev>
Reduced from 8.7MB to 11KB
<pixelherodev>
:D
<fengb>
That's a slight improvement 🙃
<pixelherodev>
Yep!
<pixelherodev>
Going to attempt to run it again and see what happens
<pixelherodev>
Shouldn't take all that long this time, and might be able to reduce it a tad more
<pixelherodev>
Yeah, a couple more nodes it can seem to ignore
<pixelherodev>
Yep!
<pixelherodev>
1.4KB smaller now; under 10KB!
<fengb>
You didn't drop another 99.9%. Fail!
<pmwhite>
In reference to posix shells, there's https://mrsh.sh/ that aims to be posix and only posix.
<pixelherodev>
Heh, yeah I know of that one :)
<pixelherodev>
fengb, sure, but counter point
<pixelherodev>
Did it *again*
<pixelherodev>
7671 bytes now
<pixelherodev>
The goal isn't minimal size though
<pixelherodev>
I'm doing this because it's stripping out functions that I might have thought were related to the crash
<fengb>
Oh neat
<fengb>
We should write a new shell, in zig. Call it zsh
<pmwhite>
Has anybody made a shell called rush?
<pixelherodev>
hah
<pixelherodev>
Also, it wasn't 99.9%
<pixelherodev>
It was 99.9156%
<pixelherodev>
SO hah
<pixelherodev>
Well, 99.88 initially
<pixelherodev>
99.9156 now
swills has left #zig [#zig]
<waleee-cl>
pmwhite: if you're thinking of ru(st)sh(ell) there's ion
<ikskuh>
fengb: i think pi zero isn't an interesting target to comile on :D
<fengb>
Pi Zero arch is identical to <Pi 3
<pixelherodev>
I think Andrew was saying it's *not* actually the target of raspi zero
<pixelherodev>
it's in strikethrough
<fengb>
Oh hrmm
<pixelherodev>
that's probably part of why it's uninteresting
<TheLemonMan>
the whole armv6+linux combo is not that interesting
<TheLemonMan>
most of the v6 users I've seen target bare-metal
<fengb>
I mean, I'm complaining but I don't think I'd run the compiler on my Pi :P
<fengb>
Easier to cross compile and copy over >_>
<pixelherodev>
... Zig can't target bare metal... can it?
<pixelherodev>
(to run the compiler on I mean)
<TheLemonMan>
that's not what target means, but no, you need an OS
<fengb>
Bleh, this ABI thing is very confusing. I'll be glad once it gets split as well
<pixelherodev>
TheLemonMan, I know
<pixelherodev>
hence the correction
layneson has joined #zig
josch557 has joined #zig
marijnfs has joined #zig
marijnfs1 has quit [Ping timeout: 258 seconds]
ianc6209 has left #zig ["Kicked by @appservice-irc:matrix.org : Idle for 30+ days"]
<shakesoda>
fengb: not quite
<shakesoda>
pi zero arch matches the pi 1
<shakesoda>
not 2
Akuli has joined #zig
<shakesoda>
the 2's were first v7a, later models the same v8 that the pi 3 uses (but running slower)
<fengb>
Oh
<fengb>
They need to upgrade the zero :(
<shakesoda>
yeah, they do, but i'm not complaining too much given what it is!
<TheLemonMan>
what should they upgrade it to? afaik the zero is meant to be a low-power model
layneson has quit [Quit: Leaving]
<fengb>
New architecture / fab downclocked to provide the same performance
<shakesoda>
ideally a downclocked version of the pi 4 soc
<fengb>
I'm assuming the newer stuff is more power efficient
<shakesoda>
since it's exactly that
<fengb>
Call it, Pi Naught? 🙃
<fengb>
Pi Zero two
<shakesoda>
+1 for pi zero two
<fengb>
Pi Zero S
<fengb>
Having an IPS backlight on doesn't harm the screen right?
mahmudov has joined #zig
frett27 has joined #zig
<shakesoda>
it wears the backlight out over time
<shakesoda>
but no, not the screen
<shakesoda>
how much this matters depends on the backlight, the older ccfl ones didn't age as gracefully as leds
frett27_ has joined #zig
<TheLemonMan>
oh, don't know why but I always assumed the rpi zero had some kind of cortex in it
<TheLemonMan>
it has a beefy(-ish) soc instead
<shakesoda>
like, an M?
<shakesoda>
it's a shrunken regular rpi
frett27 has quit [Ping timeout: 265 seconds]
frett27_ has quit [Ping timeout: 240 seconds]
<TheLemonMan>
gotcha, the only rpi I've ever played with is a rpi1
<FireFox317>
fengb, you send the wrong link. The on you were sending has musleabihf as an ABI. Notice the hf, hard float. And since hard float is not available on armv6kz the target triple doesn't make a lot of sense. The correct one is armv6kz-linux-musleabi and its already working 4 days ago: https://github.com/ziglang/bootstrap/issues/14
<fengb>
But the Pi (Zero) has hard float
<shakesoda>
yeah it absolutely has hard float
<shakesoda>
check for yourself with the possibly easier to find via google "arm1176jzf-s"
<fengb>
Might be a stupid question... but ARM 11 = armv6?
<FireFox317>
oh yeah i see actually, then its the abi that can't pass floats in hardware registers, but hardware float is still enabled inside the binary
<shakesoda>
fengb: yes
<FireFox317>
well that depends on the cpu-features that zig enables
<shakesoda>
they changed their naming scheme after that
<shakesoda>
the relevant floating point support for the pi zero would be vfp2
<FireFox317>
but it should defitely work on a rpi 1/rpi zero, maybe someone who has such a rpi laying around can test it
<shakesoda>
i've got a whole pile of them, just need to make some time
<FireFox317>
i tested zig on a rpi3
<fengb>
So does `eabihf` not exist for armv6?
<fengb>
Is there a nice prebuilt binary I can just download to test with? :P
<FireFox317>
for which rpi? :)
<FireFox317>
i can upload a binary if you want
<fengb>
Pi0 / armv6
<Snektron>
i have an old rpi
<fengb>
I still don't understand the whole ABI thing but that's always confused me anyway 🤷
<FireFox317>
fengb, i'm not sure about the eabihf for armv6. but it is only relevant for linking objects against the zig binary, because then the abi matters.
<Snektron>
Is there a specific reason bootstrap-zig has a copy of zig master instead of a git submodule?
<BaroqueLarouche>
it's a hack and require extra git commands to be usable
<fengb>
We should go back to SVN monorepos 🙃
<companion_cube>
I'm trying `git subtree` currently
<companion_cube>
it's supposed to avoid such problems
<fengb>
Actually maybe I'm not sarcastic. Being able to checkout sub trees directly is pretty useful
<Snektron>
I thought SVN didn't have branches
<Snektron>
Outside of copy pasting
<fengb>
It has branches. It doesn't have proper merging so people often don't use branches
<fengb>
Oh wait, maybe you're right. I remember using a directory structure for "branches"
cole-h has joined #zig
ifreund has quit [Quit: WeeChat 2.8]
ifreund has joined #zig
<FireFox317>
fengb, building the binary now, uno momento
<mikdusan>
git subtree looks like it's moving in the right direction. first hint that submodules is mis-designed is that it tweaked .git/config ; I don't see anything added it .git/config for subtree, so it must be using git objects for meta
<mikdusan>
but sadly `git log --stat` file paths do not prefix with subtree's prefix.
<ifreund>
it seems kindof odd to me that the first of these is a compile error while the second works https://paste.rs/SzZ
<ifreund>
would that be considered a bug? or is that issue worth
<TheLemonMan>
Thalheim, it'd be cool if you could try using lld with that patch as drop-in replacement of binutils ld, I've only tested it with some binaries built by the Zig compiler but nothing too big
<TheLemonMan>
and I've only implemented the relocations used by the TLS model we use
<andrewrk>
sweet!
<andrewrk>
TheLemonMan, do you think we should rename the arch from sparcv9 to sparc64?
<andrewrk>
ikskuh, we're not even reaping the benefits yet of the declarative nature of the build system. for example it will be possible to merge 2 build scripts together, print a graphical display of the dependency tree, parallelization of jobs
<ikskuh>
yeah i know
<andrewrk>
also possibly build script sandboxing
<ikskuh>
but i think the current way of use is quite nice
<andrewrk>
since you end up with a serializable declarative set of things to do
<ikskuh>
neat
KoljaKube has quit [Ping timeout: 265 seconds]
ur5us has joined #zig
<Thalheim>
TheLemonMan: will do. would you like me to do so or do you want to?
dddddd has quit [Ping timeout: 260 seconds]
kristoff_it has joined #zig
<kristoff_it>
FireFox317: saw your message from yesterday, I'm going to update to the latest changes in the stdlib and let you know what's the current state of things
<kristoff_it>
what's the new equivalent of SliceOutStream?
<andrewrk>
`const s = std.io.fixedBufferStream(slice); s.print("{}\n", "hi");
<kristoff_it>
thanks!
<andrewrk>
uh you might need outStream() on there.
<andrewrk>
var fbs = std.io.fixedBufferStream(slice); // you can now do inStream(), outStream(), or seekableStream()
<andrewrk>
one piece of good news is llvm is much better at optimizing this new stream API
<andrewrk>
so you might try running some benchmarks or something if you have any and maybe the numbers will improve
<TheLemonMan>
Thalheim, I'll leave the testing work to you if you don't mind :P
<TheLemonMan>
andrewrk, no idea, iiuc sparcv9 with mcpu=v8 lets you target the 32bit variants while v9 is 64bit only
<andrewrk>
interesting
<TheLemonMan>
so it works as a catch-all of some sort
layneson has joined #zig
<andrewrk>
v9 is a cpu feature but "v8" is a cpu model that has an empty set of cpu features
<andrewrk>
none of the cpu features are "64" or "32" bit related
<andrewrk>
maybe the "v9" cpu feature implies 64 bit
<TheLemonMan>
yep
decentpenguin has quit [Quit: decentpenguin]
<andrewrk>
if a v10 came out (I understand this is unlikely) it would probably still be 64 bit, and so sparc64 for the arch would make more sense than sparcv9
<TheLemonMan>
yeah, I'm still sitting on the Zig PR because of the lld problem & the fact the sparc backend doesn't like fp16/fp128
<andrewrk>
I'm confused why llvm didn't solve fp16/fp128 in a generic way and then allow target-specific overrides
<mikdusan>
v9 apparently supports 32/64/128 float. and 32/64/ integer. oh maybe this complicates things: The 32- and 64- bit floating point types conforms to IEEE Std 754-1985. The 128-bit floating-point type conforms to IEEE Std 1596.5-1992
<TheLemonMan>
well they appeared later, fp32/fp64 was/is the norm
<TheLemonMan>
fp16 is often legalized by promoting them to bigger types so you basically use a fp16 during the load/store instructions
<TheLemonMan>
and fp128 was PPC only, afair x86_64 uses SSE* instructions when possible and every other arch falls back to compiler-rt builtins
<TheLemonMan>
mikdusan, I did a bit of research and it seems that no CPU was produced with support for fp128
<mikdusan>
oh the "optional" thing. gotcha
<TheLemonMan>
I really hate fp16/fp128
<andrewrk>
in what sense? you think the language should not have these types?
<TheLemonMan>
well they're the main source of problems in porting Zig to new architectures
<andrewrk>
I think it's more revealing a limitation of llvm as a dependency
<andrewrk>
I'm imagining in the non-llvm backend, a general solution for f16 and f128 across all architectures, with some overrides for x86_64 and PPC. the overrides don't even have to happen immediately, it's an optimization really
<andrewrk>
TheLemonMan, maybe we can do a better organization of the f16 and f128 tests, so that there are fewer places that tests have to be disabled when it's not working on a particular architecture yet
<Thalheim>
TheLemonMan: it's a little more subtle. "-m64 -mcpu=v9" is 64-bit v9, "-m32 -mcpu=v9" is 32-bit v9 a.k.a. v8plus, and "-m32 -mcpu=v8" is binary-compatible with v7 which is also 32-bit -- v7/v8 are "sparc" and v9 is "sparc64", while v8plus is technically its own thing
<Thalheim>
(a 32-bit subset of v9, but not binary compatible)
<TheLemonMan>
andrewrk, that's a nice idea
<TheLemonMan>
Thalheim, oh I didn't take into account the v8plus variant
<andrewrk>
hmm, does -m64 translate to a cpu feature? so far this is the first architecture where that's not the case
<andrewrk>
e.g. on x86_64 vs i386, -m32 vs -m64 affects the "64bit" cpu feature flag
<andrewrk>
if v9 supports both 32 and 64 bit, then I think "sparcv9" (status quo in zig) is more appropriate for the architecture than "sparc64"
<andrewrk>
if this is accurate regarding -m32 and -m64 then I would propose for us to add a "64bit" cpu feature flag
<andrewrk>
zig doesn't have -m32 -m64 flags
<Thalheim>
how to reconcile the fact that 32-bit v9 (v8plus) is not binary compatible with 64-bit v9? one is 32-bit ELF MSB the other is 64-bit ELF MSB
<andrewrk>
that sounds the same as i386 vs x86_64 and arm vs aarch64, no?
<Thalheim>
I mean in terms of naming
<andrewrk>
you can run i386 32-bit ELF binaries on x86_64 systems, and you can run arm 32-bit ELF binaries on aarch64 systems. is this not the case for 32-bit v9 running on a 64-bit v9 system?
<andrewrk>
ah I see re: naming
<andrewrk>
as far as zig is concerned, it could be both "sparcv9" as the architecture, and "64bit" cpu feature (default on) that decides between 32 or 64
<andrewrk>
another option would be: only have `sparc` (get rid of both `sparcel` and `sparcv9`) and rely on CPU features: `64bit`, `v9`, and `le` to distinguish
<andrewrk>
this second option would have implications for potentially also doing this with x86, arm, and others
<ikskuh>
andrewrk: thanks for making "zig cc" possible in the way it is now!
<TheLemonMan>
hmm, the LLVM backend has no '64bit' nor 'le' cpu feature
<ikskuh>
received a link to some c file for windows, just crosscompiled it from linux for i386-windows and it just worked ♥
<andrewrk>
TheLemonMan, right, zig would diverging here in an attempt to clean up. we've already done this a little bit: consider that we don't have "vendor" as part of the triple, and no longer have "sub-arch" as part of the triple
<andrewrk>
when specifying target details to llvm, zig would determine the sub-arch to pass or -m flags or whatever based on cpu features. we still have access to all the same information, and pass it to llvm however it wants. the question is how to organize the info for the user
<kristoff_it>
andrewrk: thanks for the help, I've successfully updated to the latest changes, all tests pass :)
<andrewrk>
glad to hear
<andrewrk>
sounds like you're ready for 0.6.0
<kristoff_it>
looking forward to it :D
<andrewrk>
btw kristoff_it I'm speaking at the virtual redis conf right? somebody on discord mentioned my name is not on the speakers list
josch557 has quit [Quit: ERC (IRC client for Emacs 26.3)]
<kristoff_it>
uhhhh I'd have to ask, strange as it might sound I'm not actively part of that process
<kristoff_it>
and everything is messy now for the same global reason
<andrewrk>
makes sense. no worries just thought I'd check in
<kristoff_it>
I apologize I should have followed it more closely, I'll get back to you tomorrow
Akuli has quit [Quit: Leaving]
TheLemonMan has quit [Quit: "It's now safe to turn off your computer."]
kristoff_it has quit [Ping timeout: 256 seconds]
recombinant has quit [Read error: Connection reset by peer]
marijnfs has quit [Quit: leaving]
dermetfan has quit [Ping timeout: 246 seconds]
<FireFox317>
TheLemonMan, the issue i was pointing out earlier was my own fault, my bad :)
<andrewrk>
I'm guessing: updated std lib files but not rebuilt compiler
<andrewrk>
oh nice, you made one for exactly that cpu model
<fengb>
I just screwed up my pi D:
<andrewrk>
hmm I wonder if there is a way to do a `git log` but only show commits against master branch. e.g. yes merge commits, but not commits of that branch
<andrewrk>
(and also show commits made against master directly)
<shakesoda>
fengb: how so
<andrewrk>
this would help my release notes task in the future
<fengb>
Doesn’t shut down properly and I’m not sure why. I need to reflash the sdcard
<andrewrk>
maybe --first-parent
<andrewrk>
oh wow this is so much easier
<andrewrk>
Mon Nov 18 2019, Benjamin Feng: Optimize binary search algorithm
<andrewrk>
Fri Jan 31 2020, LemonBoy: stdlib: Add binary search function
<fengb>
Did I break things?
<andrewrk>
🤔
<shakesoda>
andrewrk: the timeline has been altered, pray git does not alter it further
<andrewrk>
there's an even simpler explanation
<andrewrk>
there are multiple implementations in std
FireFox317 has quit [Ping timeout: 265 seconds]
<fengb>
Ah yeah the one I touched was internal to sorts
<Sphax>
Hi. I'm confused about this compile error https://gcc.godbolt.org/z/a2N5xs if I make data a var it works, I don't understand why it needs to be a var though
<andrewrk>
Sphax, you could also resolve the problem by changing []u8 to []const u8