01:52 <aiwakura> hi!

03:28 <andrewrk> aiwakura, hi

03:38 <GitHub190> [zig] andrewrk pushed 1 new commit to master: https://git.io/vbMJ2

03:38 <GitHub190> zig/master d686113 Andrew Kelley: fix crash when implicitly casting array of len 0 to slice...

04:51 <aiwakura> andrewrk I'm gonna work on #438

04:51 <andrewrk> nice!

04:51 <andrewrk> aiwakura, I'll be online for about 25 more minutes then I'm headed to bed

04:54 <aiwakura> cool

04:54 <aiwakura> any pointer on where to start?

04:58 <andrewrk> you'll probably want to keep the code in zig_llvm.hpp/cpp which exposes the LLVM enums for targets. But we'll want our own enums in target.hpp on top of that with our own string names

04:59 <andrewrk> and some things you should do with our enums: 1. don't include targets that don't work, shown in that issue. 2. omit darwin; we should use macos and ios instead 3. add zen :D

04:59 <aiwakura> seems straightforward

04:59 <aiwakura> :D

04:59 <andrewrk> aiwakura, you'll also need to change the generated builtin.zig file in codegen.cpp:define_builtin_compile_vars

05:00 <andrewrk> then just make sure we're generating the correct LLVM IR when we cross compile

05:00 <andrewrk> and at that point I think compile errors should lead you toward the rest of the patch

05:01 <andrewrk> aiwakura, make sure target.cpp:get_target_triple is correct

05:01 <andrewrk> that will be changed with #438

05:04 <aiwakura> k

11:22 <skyfex_> andrewrk: I'm going to try to compile the nrf-demo for nRF52 as well (Cortex M4). I'm having some issue there though.

11:22 <skyfex_> zig build-obj --target-os freestanding --target-arch thumb --assembly system\gcc_startup_nrf52.S -isystem include --libc-include-dir include test52.zig LLVM ERROR: Unknown Arch: 19

11:22 <skyfex_> LLVM ERROR: Unknown Arch: 19

11:24 <skyfex_> That's ".arch armv7e-m" in gcc_startup_nrf52.S it's complaining about

11:31 <skyfex_> .arch armv7-m works though

12:08 <skyfex_> OK, I got Zig to run on NRF52/Cortex-M4 :) There's only that armv7e-m issue so far

15:27 <andrewrk> skyfex_, thanks for the report

15:27 <andrewrk> I think this is an issue with llvm's assembly parsing

15:28 <andrewrk> we should probably file a bug