00:45
<
GitHub144 >
[artiq] whitequark commented on issue #655: Per correspondence with LLVM developers, the patch is broken by design and cannot be fixed (and likely can lead to miscompilations already). We'll have to find some other way of improving the performance of the loops it was used to speed up.
https://github.com/m-labs/artiq/issues/655#issuecomment-353810249
01:01
<
whitequark >
sb0: who are the right OR1K people to talk about if I need to extend the ABI?
01:02
<
whitequark >
two 32-bit return registers are not enough
01:09
<
GitHub141 >
llvm-or1k/artiq-5.0 1c49b6f whitequark: [OR1K] Add two more return registers, R13 and R15....
02:00
<
sb0 >
whitequark, maybe stekern ?
02:03
<
whitequark >
stekern: ^ I've used R13 and R15 for this. it shouldn't affect anything other than LLVM intrinsics, I think, JFYI
02:08
<
cr1901_modern >
How can you fast forward thousands of commits without the directory structure or something in the build system itself breaking?
02:08
<
whitequark >
it's LLVM
02:08
<
whitequark >
they don't change the build system all that much, and they do a lot of very small incremental commits
02:09
<
whitequark >
github doesn't properly show commit #'s by the way, that was somewhere around 5000 commits I think?
02:09
<
cr1901_modern >
Well, directory structure was changed between 3.minor-version-cpu0-version uses and 3.9 (which is the version I'm slowly hacking on)
02:09
<
cr1901_modern >
(that second "version" should be tutorial)
02:09
<
whitequark >
3.0 to 3.9 spans like a decade
02:10
<
whitequark >
and a migration from autocrap to cmake
02:10
<
cr1901_modern >
Okay I'll take your word for it. I'm prob filled with FUD when I inevitably try to rebase on top of 4.x
02:11
<
cr1901_modern >
or 5.x- whatever the new version scheme is
02:11
<
whitequark >
4.x converted a few pointers to references and added an argument here and there
02:11
<
whitequark >
5.x converted a few more pointers to references
02:11
<
whitequark >
that's it
02:11
<
whitequark >
oh and if cpu0 has relocations then relocation def files moved too
02:12
<
cr1901_modern >
yes those were the files I was thinking of in particular
02:12
<
whitequark >
it's exactly one file
02:13
<
whitequark >
it's really not hard to fix, this took me less than ten minutes per version
02:13
<
whitequark >
plus a hour of compiling all the crap
02:13
<
whitequark >
also, don't rebase, merge
02:14
<
cr1901_modern >
i.e. checkout 4.x/5.x branch and just merge from the tip of my altered 3.9 branch?
02:15
<
whitequark >
fetch upstream/release_{40,50}
02:15
<
whitequark >
`git fetch upstream && git merge upstream/release_40`
02:15
<
whitequark >
then for 50
02:16
<
cr1901_modern >
Oh duh (I'm totally not on release_39 anyway. My branch's ancestor is release_39 of course)
04:01
<
stekern >
whitequark: you should speak to Stafford Horne (shorne on irc), he's the one that's been most active touching the arch definitions lately
04:44
_rht has joined #m-labs
05:42
_whitelogger has joined #m-labs
07:43
_rht has quit [Quit: Connection closed for inactivity]
09:14
<
whitequark >
stekern: which IRC?
09:15
<
whitequark >
IRC channel*
10:34
<
GitHub97 >
rust/artiq-1.22.1 39b8aaf Felix S. Klock II: Slew of feature gating tests for issue #43106.
10:34
<
GitHub97 >
rust/artiq-1.22.1 ba53f95 Ralf Jung: E0122: clarify wording
10:34
<
GitHub97 >
rust/artiq-1.22.1 2306687 Johannes Löthberg: Add support for full RELRO...
12:04
<
whitequark >
of
*course* the upgrade to LLVM 5.0 broke something in rust's liballoc...
12:05
<
whitequark >
this is why we should upgrade every time a new version comes out and not in these massive chunks once a year
13:49
<
sb0 >
why are we upgrading right now?
14:02
<
whitequark >
because smoltcp tickled some rustc bug
14:03
<
whitequark >
in 1.20.0
14:03
<
whitequark >
well, I'm working on backtraces now, so it's all good
14:09
<
whitequark >
sb0: $(compile) -D_LIBUNWIND_BARE_METAL
14:09
<
whitequark >
this doesn't work
14:09
<
whitequark >
what should I use instead?
14:09
<
whitequark >
(in misoc)
14:09
<
sb0 >
whitequark, what are you trying to do, pass an additional flag to the compiler?
14:10
<
whitequark >
but only in some rules
14:11
<
sb0 >
maybe copy what compile expands to?
14:11
<
sb0 >
$(CC) -c $(CFLAGS) -D_LIBUNWIND_BARE_METAL $(1) $< -o $@
14:11
<
whitequark >
that's ugly...
14:11
<
whitequark >
why even bother with the short form in the first place
14:11
<
sb0 >
makefiles are ugly
14:12
<
sb0 >
why does $(compile) -D_LIBUNWIND_BARE_METAL break anyway?
14:12
<
whitequark >
not a clue
14:12
<
whitequark >
oh hm, it does pass the argument
14:12
<
whitequark >
nevermind
14:22
X-Scale has joined #m-labs
15:27
<
GitHub35 >
misoc/master 06fb383 whitequark: software: extract libprintf from libbase....
15:27
<
GitHub35 >
misoc/master 876eeb1 whitequark: software: clean up Makefiles.
15:28
<
GitHub81 >
misoc/master e09d84d whitequark: software: fix typo.
15:33
<
GitHub139 >
misoc/master 727187d whitequark: libprintf: inline strnlen to avoid a libbase dependency....
15:36
<
whitequark >
"rotting FPGA designs"
15:43
<
whitequark >
sb0: your printf implementation only worked because it invoked unsigned underflow in strnlen.
15:43
<
whitequark >
C was a mistake.
15:44
<
sb0 >
whitequark, where did that printf come from again? it was either newlib or linux kernel
15:45
<
whitequark >
but I don't recall linux's printf being
*this* shitty
15:45
<
whitequark >
maybe if you took some very old version of it...
15:59
<
GitHub189 >
misoc/master 88ffbb6 whitequark: libprintf: unbreak %s....
17:03
<
whitequark >
sb0: backtraces work.
17:03
<
whitequark >
and I'll even upstream them in libunwind...
17:13
<
GitHub44 >
misoc/master a3bc1b8 whitequark: libunwind: update, split into libunwind-elf.a and libunwind-bare.a.
18:03
<
rqou >
this one is ripped from musl
18:14
<
whitequark >
eh, I already fixed it
18:20
<
GitHub39 >
misoc/master d95f4ed whitequark: libunwind: build GCC extension APIs.
18:32
<
GitHub120 >
artiq/master fa4dc1b whitequark: doc: developing: show how to make clang source builds faster.
18:32
<
GitHub120 >
artiq/master 1570a48 whitequark: artiq_devtool: don't require lock for reset....
18:32
<
GitHub120 >
artiq/master 3eec15c whitequark: firmware: fix compatibility with newer rustc. NFC.
18:33
f4bug has quit [Quit: Leaving.]
19:22
<
GitHub59 >
artiq/master 230f2e5 whitequark: runtime: print (address-only) backtraces on core device panics.
20:30
<
GitHub140 >
artiq/master 061fb3d whitequark: runtime: remove accidentally committed parts of a Makefile.
21:31
<
whitequark >
*stare*
21:31
<
whitequark >
panic at src/libcore/slice/mod.rs:735: index 1869492536 out of range for slice of length 65536
21:31
<
whitequark >
this makes no sense
21:33
<
whitequark >
of course, the backtraces aren't symbolized yet, so I don't know where this actually happens...
23:11
X-Scale has joined #m-labs