knebulae has quit [Read error: Connection reset by peer]
knebulae has joined #zig
alfa07 has joined #zig
<alfa07>
hi all! I wonder how memory is managed for comptime objects, why this works?: fn f() []type { comptime tx: [32]type = undefined; tx[0] = u32; return tx[0..1]; }
nvmd has quit [Quit: Later nerds.]
supercoven has quit [Ping timeout: 245 seconds]
kbd has joined #zig
<g-w1>
its supporesd to be garbage collected! (its not, it just leaks rn :()
<alfa07>
g-w1: so it is safe to assume that comptime objects (like arrays) are alife for the duration of compilation?
<g-w1>
i believe so
brzg has joined #zig
<daurnimator>
tiehuis: you disowned zig-git?
leroycep has joined #zig
Snetry has quit [Ping timeout: 265 seconds]
Snetry has joined #zig
brzg has quit [Quit: leaving]
layneson has joined #zig
kbd has quit [Quit: My Mac Mini has gone to sleep. ZZZzzz…]
<TheLemonMan>
it's possibly a difference in how the pipelines are setup
riba has quit [Ping timeout: 260 seconds]
<mikdusan>
re #6408, I'm not certain, have we determined if this has to do with the way zig generates debug metadata, or it's upstream ?
<TheLemonMan>
that's on zig's side, the variables declared in a inline for confuse the dwarf emitter
<mikdusan>
ok thanks
<TheLemonMan>
damn it, I see a miscompilation in the early i386 code
xackus__ has joined #zig
nycex has quit [Remote host closed the connection]
nycex has joined #zig
craigo has quit [Ping timeout: 240 seconds]
bitmapper has quit [Quit: Connection closed for inactivity]
kenran has joined #zig
remby has quit [Quit: Konversation terminated!]
earnestly has joined #zig
<TheLemonMan>
oh it was just a blunder in the updated LLVM flag set
cole-h has quit [Quit: Goodbye]
<ikskuh>
llvm12 seems to have broken half of zig
<TheLemonMan>
nah
cole-h has joined #zig
<ikskuh>
TheLemonMan: your last comment on github: does it mean we can actually emit proper 16 bit code?
<ikskuh>
if we set the CPU right?
<mikdusan>
hey so is #8124 possibly related to #8123 ?
<TheLemonMan>
ikskuh, yeah, LLVM's triple looks like i386-unknown-unknown-code16
<TheLemonMan>
it _should_ work
mokafolio has quit [Quit: Bye Bye!]
mokafolio has joined #zig
<TheLemonMan>
mikdusan, give it a try, remove all the mentions of {16,32}bit-mode from x86.zig and re-compile zig
<TheLemonMan>
anyway, please push the s/push/pushl/ change whenever you have a minute, that's a nice improvement nonetheless
tnorth has joined #zig
<ikskuh>
TheLemonMan: Sweet! Zig BIOS when?! :D
hnOsmium0001 has quit [Quit: Connection closed for inactivity]
<TheLemonMan>
we already have Zig EFI heh
<mikdusan>
(I'd like andrew to chime in before pushing a pr). but noob question: there's 2 asm push and only one was needed to quiet LLVM error. so make lines [85..86] s/push/pushl/ ?
<TheLemonMan>
push <reg> -> the assembler knows the register width
<TheLemonMan>
push <mem> -> the assembler has no idea how many bytes you want to push
<mikdusan>
k. only memory form then.
<TheLemonMan>
yeah
<TheLemonMan>
sometimes the assembler aliases a "naked" push as a native-sized push
cole-h has quit [Ping timeout: 245 seconds]
kenran has quit [Quit: leaving]
<mikdusan>
ohyeah as per #8124... this can't be good: zig build-obj hello.zig --verbose-llvm-cpu-features -target i386-linux-none
<mikdusan>
and look at the first features:
<mikdusan>
-16bit-mode,-32bit-mode,
<mikdusan>
ouch
<mikdusan>
oh never mind. those just mean modes. duh.
<mikdusan>
well maybe not never mind. the reproduction for "push" ambiguity:
<LewisGaul>
Hey, I'm trying to fix a zig fmt regression and just wondering if there's a faster way to iterate that running 'make install' every time I change lib/std/zig/render.zig?
<TheLemonMan>
you can run the test cases using `zig test`
<LewisGaul>
as opposed to `./zig test ../lib/std/zig/parser_test.zig`, as in no need to rerun `make install` and use the newly compiled `zig` for running the test?
<TheLemonMan>
yeah, you're working on the stdlib after all
<LewisGaul>
I guess what I'm asking, to clarify, is: does `zig test ../lib/std/zig/parser_test.zig` cause `../lib/std/zig/render.zig` to be recompiled?
<TheLemonMan>
yeah
<LewisGaul>
cool, thanks :)
<TheLemonMan>
np
hidayat has joined #zig
<tnorth>
Ping! I'm trying to create a structure which as member has a pointer to itself or to an u64, depending on a comptime parameter. The compiler complains that it is " error: unable to evaluate constant expression" a minimal example here: any pointers? https://pastebin.com/tYBAmUnt
<ikskuh>
heya
<ikskuh>
you need to store types in a "comptime var" or a const
<ikskuh>
right now, you'Re storing the type "type" in ptr_type (a runtime var)
<tnorth>
ikskuh: ah yep, I tried that as well, doesn't fix it
<tnorth>
(comptime var ptr_type)
<ikskuh>
gimme a sec
<tnorth>
ikskuh: yep, thanks already for looking into it :)
LewisGaul has quit [Quit: Connection closed]
<ikskuh>
basic problem is:
<ikskuh>
you're trying to store a set of []type into your struct
<ikskuh>
not a ptr to self
<tnorth>
`type` should be the type of the return, ie the struct, is that right?
<tnorth>
[]ptr_type should then become a pointer to a runtime known number of this struct ?
<ikskuh>
no, "type" is just a type (so something like u64, f32, []const u8 or type)
<ikskuh>
[]ptr_type would then become "[]type"
<ikskuh>
which is a slice of types
<ikskuh>
you cannot manipulate "type" at runtime, that's why you get that error
<ikskuh>
what you want is: you want to store @This()
<tnorth>
ah... I thought that type was inferred at compile time
<ikskuh>
which is the type of the surrounding context
<ikskuh>
no, that would be "anytype" for parameters, but it's not valid in other places
<tnorth>
used to be active in the Fedora community, otherwise not
<tnorth>
but I kind of enjoy the little I know from Zig and would like to be able to use it more regularly
<ikskuh>
that's good. spread the word!
<tnorth>
I do, and already annoy my friends :P
<ikskuh>
very good *grin*
LewisGaul has joined #zig
<ikskuh>
okay, one hard question of one crazy programmer *grin*
<ikskuh>
do we have a way to link a function against a different location that it will be stored in the later executable?
<ikskuh>
or do i have to do some super-hacky linker magic for this?
<TheLemonMan>
a function pointer?
<ikskuh>
nah
<ikskuh>
use case:
<ikskuh>
i have a embedded device with a lot of flash and a little bit of RAM
<ikskuh>
but executing code from flash is super-slow
<ikskuh>
so what i want to do is:c
<ikskuh>
copy a function from flash to RAM to a (known) position
<ikskuh>
and run it
<ikskuh>
but i have to know the location where the function is stored in the output section as well
<ikskuh>
so the offsets used in the function for linking are different than the ones "on disk" or in the final executable
<tnorth>
ikskuh: sorry, why can't I access my_cell.children ? I thought I can use it as a normal array now. "error: type '@typeInfo(@typeInfo(@TypeOf(Foo(false).init)).Fn.return_type.?).ErrorUnion.error_set!Foo(false)' does not support field access"
<ikskuh>
that means that you're missing error handling
<ikskuh>
the function you're calling might fail (which is what this cryptic error message tells you)
<ikskuh>
but you're not handling the error
<ikskuh>
try inserting a "try" between your "=" and the value :)
<tnorth>
ikskuh: still get the same msg :/
<tnorth>
I suspected that but somehow it is not enough
<tnorth>
I get that child0 may not be reachable, that line can't work. But for child, shouldn't it?
<TheLemonMan>
ikskuh, if you known the location you can just memcpy the code and call it like @intToPtr(fn () void, <addr>)()
<LewisGaul>
Is there a way to break on a `test` block in gdb?
<ikskuh>
yeah, i know
<ikskuh>
but: you need to link functions properly
<ikskuh>
afaik both arm and x86_64 use relative adressing nowadays by default
<ikskuh>
so relative addresses are broken
<g-w1>
LewisGaul: you can probably just use the line number
<dutchie>
tnorth: my advice for stuff like this is to add explicit type annotations to your variables so you can see exactly where your intuition and the compiler disagree
<LewisGaul>
g-w1 oh duh should've thought of that :p
<TheLemonMan>
ikskuh, you have to save&apply the relocations by hand (if any)
<tnorth>
dutchie: type annotation? do you mean print them out with @typeName etc. or is there any feature I ignore to do it?
<TheLemonMan>
I did something similar to what you want in https://github.com/LemonBoy/elf2aab , except it's targeting a proprietary file format I've reverse-engineered
<ikskuh>
TheLemonMan: okay, so i'll make a proposal to allow such features
<ikskuh>
it's not uncommon to create code like this (kernel devs also need this)
<ikskuh>
the relocations aren't necessary because the link address is fixed anyways
<dutchie>
tnorth: i mean write `var my_cell: Foo(false) = ...`, `const child: ?[]u64 = ...` and so on
<dutchie>
also, you'll have to change your main function's return type to !void if you want to use try
<TheLemonMan>
well if the address is known before link-time you can simply compile each function as its own binary, using a linker script to fix its address
LewisGaul24 has joined #zig
LewisGaul24 has left #zig [#zig]
LewisGaul71 has joined #zig
LewisGaul71 has left #zig [#zig]
LewisGaul has quit [Ping timeout: 240 seconds]
<tnorth>
dutchie: https://zig.godbolt.org/z/oz9dG7 . I think what I don't get is how to go from the optional to the u64 type only. I tried try ... catch unreachable but is doesn't make it.
<dutchie>
catch is for errors, you want orelse for optionals
<dutchie>
similarly try doesn't work with optionals
<dutchie>
the equivalent of `catch unreachable` is .?
<ikskuh>
TheLemonMan: yeah, i have to conduct some experiments
<ikskuh>
i want to create a new demo for an embedded platform and i need that sadly
<dutchie>
so if you change the last line to `const child_r0: u64 = child_r.?[0]` it should work
<tnorth>
dutchie: thanks for the explaination.
<tnorth>
dutchie: that make a lot of sense now :)
<dutchie>
no problem, glad to help :)
leon-p has quit [Read error: Connection reset by peer]
leon-p has joined #zig
nvmd has joined #zig
<ed_t>
Assertion failed at /tmp/makepkg/zig-git/src/zig/src/stage1/analyze.cpp:527 in get_pointer_to_type_extra2. This is a bug in the Zig compiler.thread 181282 panic:
<ed_t>
Unable to dump stack trace: debug info stripped
<ed_t>
Aborted (core dumped)
bitmapper has joined #zig
<ed_t>
this ring any bells
LewisGaul71 has joined #zig
LewisGaul71 has quit [Quit: Connection closed]
LewisGaul has joined #zig
<TheLemonMan>
not without some code
<ed_t>
Had this happen twice today. Have not figured out a pattern (yet).
<TheLemonMan>
get a compiler with debug symbols and run it under gdb
kchambers has joined #zig
<ed_t>
would you know how to change the pkgbuild in arch for zig-git to keep the symbols?
<ed_t>
rebuilding now. If I get it again I will be back. Thanks
<ed_t>
when do makepkg with the option add to the cmake the build fails with:
<ed_t>
tmp/makepkg/zig-git/src/zig/src/zig_clang_cc1as_main.cpp:521:23: error: ‘Value’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
<ed_t>
c and cpp and make are, as you probably gathered, not my strong points
TheLemonMan has quit [Quit: "It's now safe to turn off your computer."]
kbd has joined #zig
kenran has quit [Quit: leaving]
kbd has quit [Quit: My Mac Mini has gone to sleep. ZZZzzz…]
Swahili has joined #zig
sawzall has quit [Read error: Connection reset by peer]
sawzall has joined #zig
amk has quit [Remote host closed the connection]
amk has joined #zig
LewisGaul has quit [Ping timeout: 240 seconds]
cole-h has joined #zig
TheLemonMan has joined #zig
hnOsmium0001 has joined #zig
tnorth has quit [Ping timeout: 240 seconds]
kbd has joined #zig
craigo has joined #zig
LewisGaul has joined #zig
vegai has quit [Remote host closed the connection]
Akuli has joined #zig
fireglow has joined #zig
<TheLemonMan>
ifreund, the new `zig fmt: {on,off}` thing works very well, I think it should trim the leading space after the two slashes
kchambers has quit [Quit: WeeChat 3.0.1]
<LewisGaul>
Are you saying it should be `\\zig fmt: off` rather than `\\ zig fmt: off`? I'd disagree with that personally
<LewisGaul>
excuse the formatting, should've been `\\ zig fmt: off`
<TheLemonMan>
no?
<LewisGaul>
ok ignore me then :)
<ifreund>
TheLemonMan: glad you like it, the previous limitations were bugging me for quite while :D
<ifreund>
I think allowing the `zig fmt: off` to appear anywhere in the comment would be a good change yeah, though we shouldn't allow anything else aside frome whitespace
<TheLemonMan>
yeah, today I spent quite some time trying to figure out why it was not working ... and I had an extra whitespace before the `zig fmt` part
WilhelmVonWeiner has joined #zig
Swahili has quit [Remote host closed the connection]
emptee has joined #zig
tughi has joined #zig
<andrewrk>
nice find mikdusan
<andrewrk>
ah I see what happened here
<TheLemonMan>
not LLVM's fault this time :^)
<andrewrk>
we gained the 16bit_mode and 32bit_mode cpu feature flags, which I think was the right decision, but the way it works when we pass to LLVM is explicitly set everything we are aware of. so being aware of these modes made us start passing -32bit_mode to llvm
<andrewrk>
previously we were leaving those flags on whatever was default for llvm, which was assuming 32bit_mode based on the arch
<andrewrk>
ahh I did not realize there was an abi way to affect this
<andrewrk>
TheLemonMan, did you see the new cpu features upgrade script? I think it will be much less painful for llvm 13 at least
hidayat has quit [Quit: Connection closed]
<andrewrk>
you might also have some opinions about my overrides in there
<TheLemonMan>
the only question I had was about i386 generic being a 64bit target now
<andrewrk>
uhh that sounds like an accident. let me take a look
<LewisGaul>
Hey andrewrk I've been working on a fix for https://github.com/ziglang/zig/issues/8088 and have just managed to get it working, although I'm not sure about the approach - it seems a little messy overloading `renderWhile()` to also handle 'if' for this case. Anyway shall I just raise a PR and add some comments pointing out the bits I'm unsure of?
<andrewrk>
TheLemonMan, you're talking about line 1813? I think perhaps we should omit that entirely. The generic i386 cpu is _i386 and the generic x86_64 cpu is x86_64
<andrewrk>
I mean we should perhaps omit that generic cpu entirely
<andrewrk>
nice work LewisGaul - give me a few minutes to solve this other issue and then I'll send a code review your way :)
<LewisGaul>
no problem, no rush at all!
<TheLemonMan>
yeah, it doesn't really make sense to have a generic for x86 since it doubles as x64 too
<TheLemonMan>
I wonder what's the default for clang
<ifreund>
LewisGaul: why special case if statements when you could make it consitent across if/for/while?
leroycep has joined #zig
emptee has quit [Remote host closed the connection]
<ifreund>
LewisGaul: IMO whatever line breaks are in the source should be respected
<LewisGaul>
I'm mainly going off zig 0.7.1 behaviour, which does break the above into 3 lines. I kind of prefer that too tbh
<TheLemonMan>
oh, that explains everything
<LewisGaul>
eh maybe I take that back, makes sense to give flexibility to the user
<LewisGaul>
I'm definitely open to removing the `base_node_is_if` stuff
<ifreund>
I think respecting the line breaks in the source or lack thereof is the right thing to do with single-statement if/while/for. Having inconsistent behavior between them as is the status quo or always forcing line breaks/no line breaks is objectively worse IMO
<LewisGaul>
FWIW single-*line* statements are respected, e.g. `if (a) |x| if (x) f(x);`. But yes I'm inclined to agree, partly on the basis of homogenising and justifying using `renderWhile()` for 'if' :p
<ifreund>
It's often argued that consistency is the most important part of coding style
<andrewrk>
I'm tempted to make the triple for i386/x86_64 only be "x86" and have the baseline be a modern x86_64, and if you want 32 bit, you'd have to use -mcpu=i386+foo+bar or -mcpu=i486+baz+quux etc
<ifreund>
I mean look at GNU's way of writing C. It's totally foreign to most people but once you spend a few days reading it it's fine because they are consistent with it
<LewisGaul>
ifreund I've added a comment to the PR summarising our discussion and will see what Andrew says at review - thanks for taking a look
<andrewrk>
LewisGaul, if ifreund has the energy for it, he's quite capable of reviewing and merging zig fmt PRs :)
<ifreund>
(talking just about how they format code, not the actual code itself to be clear. Not a fan of glib)
<TheLemonMan>
andrewrk, do we punt the mcpu parameter to clang? because departing from LLVM's conventions may be a problem for zig cc
<LewisGaul>
oh sure well I can just make that change in that case aha, sorry, new here
<andrewrk>
I think we already have a layer of indirection there, constructing an llvm triple out of zig's target information
<TheLemonMan>
as long as people don't expect it to be a 1:1 drop-in replacement it's fine then
<TheLemonMan>
but I'd avoid turning x86 into x64
<andrewrk>
oh? you think it should be 32 bits by default without an -mcpu parameter?
<andrewrk>
I think that would be Footgun City
<andrewrk>
we could host the World Footgun Olympics there
<TheLemonMan>
I was suggesting to keep x86_64 and the various iNNN variants
<andrewrk>
I see, so status quo, but actually support *more* architecture names as part of the triple?
<TheLemonMan>
yeah, extend it to {x86_64,i386,i586,i686}
<andrewrk>
interesting
<TheLemonMan>
I think this is also the naming scheme Rust uses
<andrewrk>
we also have these new x86_64_v2, x86_64_v3 and x86_64_v4 cpus that llvm introduced
<TheLemonMan>
that's a task for mcpu, those would be specified as -triple x86_64-whatever -mcpu=x86_64_vN
<andrewrk>
couldn't the same argument be made for i386, i586, i686?
<TheLemonMan>
but afair we wanted to clarify the split between the 32bit targets
<TheLemonMan>
because right now the default for i386 is ... a i686 target
<andrewrk>
the solution in the linked issue is to rename it to x86 and leave the baseline as status quo
kbd has quit [Quit: My Mac Mini has gone to sleep. ZZZzzz…]
<andrewrk>
we already have i386, i486, etc cpus that can be selected with -mcpu
<earnestly>
TheLemonMan: (Is -mcpu like -march? Because those _vN's are -vN)
<earnestly>
(And well, x86-64, so idk)
emptee has quit [Quit: Konversation terminated!]
<tnorth_>
oh copy/paste error sorry
tnorth_ has quit [Quit: Konversation terminated!]
<andrewrk>
for better or worse zig has a different naming convention of cpu models and conventions
<andrewrk>
so that the same names can be used in identifiers and the CLI
<andrewrk>
s/models and conventions/models and features/
<earnestly>
If zig can refine that, make it more consistent, as a side-effect; that'd be nice
<LewisGaul>
what's the deal with including a mascot image from ziglang.org in a personal blog post, is that allowed or is there some licensing to worry about?
<ifreund>
I think I saw talk about changing them to be just CC-by though
<andrewrk>
they are intended for this purpose
<LewisGaul>
thanks
<ifreund>
we should really make them just CC-BY if that's the intent
<ifreund>
I can open a PR if you like
<andrewrk>
let me just double check with Loris and I'll do it
<ifreund>
cool :)
sord937 has quit [Quit: sord937]
<g-w1>
marler8997: https://clbin.com/p4Dd1 <- here is the error for the openssl with https://google.com but its not openssl static; the same thing triggers with regular openssl so I assume its a different bug; so I say ship it!
<g-w1>
i mean the bug is in the openssl code and not part of it being static
<marler8997>
good test
losinggeneration has quit [Read error: Connection reset by peer]
andrewrk has quit [Ping timeout: 256 seconds]
<marler8997>
this reminds me of the iguana error, like there are extra characters around the data
<g-w1>
yeah, does it trigger for you? or is my machine weird?
andrewrk has joined #zig
<marler8997>
not for me no, it did with iguana
<g-w1>
hmm, ill try it with iguana :)
<g-w1>
now I get an out of memory in the build.zig :)
<andrewrk>
yeah I inspected this and it looks good
<TheLemonMan>
have you tried passing the same set of flags?
<g-w1>
if 12.0.0 will release soon, does that == 0.8.0?
<andrewrk>
I have not
<mikdusan>
this guy... and his solid bug skills. wth :)
<andrewrk>
llvm12 has added and removed cpu feature flags however, so it's a bit squishy what that tells us
<daurnimator>
andrewrk: they also added x86_64-v2 and v3
<andrewrk>
it's an identical set of + flags. the only changes are - flags which look like they are off regardless
<TheLemonMan>
ok, the error is caused by the horizontal min/max on f16 vectors
<andrewrk>
oh I thought we already had f16 test cases disabled due to this bug
<TheLemonMan>
fuck f16 and f128
<andrewrk>
why?
<TheLemonMan>
because they are a constant source of bugs
<TheLemonMan>
and nobody needs 128 bits of precision
<TheLemonMan>
and nearly no general-purpose hw implements f16 in silicon, everything is implemented in full precision and then scaled down
<fengb>
Even f32 has "weird" bugs because people aren't used to single precision
<mikdusan>
the LLVM error is about fmi, and to point out the obvious, for llvm11 we do -fmi and not sure for llvm12
sawzall has joined #zig
<TheLemonMan>
people aren't used to floating point in general
<andrewrk>
mikdusan, fmi is no longer a cpu feature of llvm12
<andrewrk>
or rather it has been renamed to flagm
sawzall has quit [Read error: Connection reset by peer]
<mikdusan>
ah that's what i was trying to verify. thanks
sawzall has joined #zig
<TheLemonMan>
add +fullfp16 and the error goes away
<andrewrk>
do we perhaps want to choose a different cpu for our aarch64 tests?
<andrewrk>
hmm right now we use baseline
<andrewrk>
that seems right
<andrewrk>
baseline for aarch64 is currently the same as generic
<TheLemonMan>
the fp16 should be gated by checking fullfp16 being active
LewisGaul has quit [Ping timeout: 240 seconds]
<mikdusan>
+fp16fml also fixes error
<mikdusan>
ah of course it includes it
<mikdusan>
strange thing is on master/llvm11 we do -fullfp16 and no error
<andrewrk>
hmmmm did I just put an override on master for this?
<andrewrk>
oh nvm I misread what you said
<andrewrk>
TheLemonMan, that's not the zig way- we have compiler-rt for filling in the gaps of what hardware is capable of, and core stuff like f16 is supposed to work on all targets
filpAM has joined #zig
<andrewrk>
however, I could see zig lowering this to LLVM without f16
<TheLemonMan>
I wouldn't call f16 "core"
<ifreund>
it's part of the language currently, and I assume will make it into the spec
<andrewrk>
I'm fine with labeling f16 as experimental for now and not trying to support it until stage2 is further along, and we have a mechanism for lowering it without machine code backend support
<andrewrk>
then as far as LLVM is concerned it would only see f16 when +fullfp16 is available
<ifreund>
that sounds very reasonable :)
<TheLemonMan>
how many times have you used f16?
<g-w1>
will stage2 use softfloat? or will it be in zig?
<TheLemonMan>
in COBOL obviously
<g-w1>
ofc
<mipri>
there's some APL code that I was annoyed I couldn't duplicate in a language without support for f128, but it's also amusing that there's no f80. D really made a bad bet on using that.
<andrewrk>
TheLemonMan, not once, in an any code other than zig compiler code
<andrewrk>
g-w1, end-game is that stage2 will use f16, backed by compiler-rt where necessary
<andrewrk>
TheLemonMan, I see your point, I really do, but I don't think it's a decision to be made on a whim
<rom1504>
f16 is really important for some use cases (ML is one)
<TheLemonMan>
I understand, just keep that in mind when writing the specification
<TheLemonMan>
you can easily add more types if needed, removing them is a bit harder
<rom1504>
(that said I don't know if these use cases intersect with zig planned use cases)
<andrewrk>
fair points
<TheLemonMan>
rom1504, that's why I said _almost_ no hardware implements them in HW
<TheLemonMan>
some GPUs do, iirc there's even yet another 16bit floating point format
<TheLemonMan>
ah, bfloat16
cren has quit [Quit: nyaa~]
TheLemonMan has quit [Quit: "It's now safe to turn off your computer."]
<mipri>
https://godbolt.org/z/TK1YzW doesn't produce the right answer, so maybe f128 isn't even what APL's using there. *shrug*
xackus__ has quit [Ping timeout: 245 seconds]
blackbeard420 has quit [Excess Flood]
kbd has quit [Quit: My Mac Mini has gone to sleep. ZZZzzz…]