IRC logs for #openrisc Wednesday, 2014-12-31

--- Log opened Wed Dec 31 00:00:17 2014
--- Log closed Wed Dec 31 00:24:02 2014
--- Log opened Wed Dec 31 00:24:15 2014
-!- Irssi: #openrisc: Total of 38 nicks [0 ops, 0 halfops, 0 voices, 38 normal]00:24
-!- Irssi: Join to #openrisc was synced in 14 secs00:24
olofk_blueCmd: Great mail07:49
olofk_Any feedback?07:49
-!- olofk_ is now known as olofk07:58
poke53282I wish the testsuite failures would be easy to fix.09:44
poke53282Unfortunately most of them are completely non-obvious.09:47
poke53282Also the failures of of musl and glibc don't have that much overlap.09:47
poke53282And it is true, that some of the testcases should be disabled. For example the function to get the stack usage of functions. We don't support it, but the testcases fail.09:49
poke53282From the practical side, every important software compiles so far.09:56
poke53282The errors I encountered were never related to gcc.09:56
poke53282At the moment I guess, that there are only 2 or 3 important errors left, most of them related to C++.09:57
poke53282A 100% pass seems illusionary.10:01
poke53282this is still the summary, which I posted some time ago.10:31
poke53282the first one is somehow musl -related.10:31
poke53282the second failure is something for stekern. stdatomic-compare-exchange-1.c10:32
maxpalnhi - been offline for a few days. I'm revisiting this process of making the BFM exercise Classic (and constant address) cycles -11:28
maxpalnolofk: you said you had made some updates too - I think the changes for the above should be minimal11:28
maxpalnI'll make them and that should be the end of my changes (I think)11:28
maxpalnthat would be a good point for a merge I guess.11:29
stekernpoke53282: I will take a look at that11:30
stekernre musl related fails, I bet there are tests that assume glibc11:31
maxpalnhmmm, ok - this is interesting. The definitions of the cycle types haven't followed the WB Spec - might have to change a few additional things to make this work. Hopefully I don't break too much in the process.11:36
blueCmdolofk: nope!11:49
blueCmdpoke53282: I don't think 100% test pass is illusionary. Either the test is 1) showing something that is broken, 2) irrelevant and should be disabled, 3) using a missing feature and should be disabled and documented11:51
blueCmdit's basically a matter of fixing or documenting them, at least from where I'm standing11:52
blueCmdI don't have any problem making musl the "libc of choice" for running the GCC testsuite, so if we need to disable tests because they assume glibc, so be it (unless GCC folks scream at us for doing that)11:53
blueCmdhaving a gcc upstream that is known to fail tests is kind of bad in the sense where we lose a good tool to track regressions11:54
stekernI agree11:57
stekernI will have a lot of "free time" in January, wife and kids are in Thailand, so I'm home alone. I'll set aside some time running the tests and digging through the failure during that time.11:58
blueCmdstekern: that'd be really cool. I won't have much time to commit, but ping me if you want a rubber duck to talk to12:02
stekerndon't be surprised if I take you up on that offer ;)12:04
blueCmdI won't, especially the stdatomic ones12:09
blueCmdthey can be.. weird12:09
ysangkokpoke53282: i can't find the dtb/dts, is it in vmlinux.bin.bz2?13:51
-!- Netsplit *.net <-> *.split quits: mboehnert, jeremybennett, fotis2, mithro22:34
olofkHappy new year!23:07
--- Log closed Thu Jan 01 00:00:18 2015

Generated by 2.15.2 by Marius Gedminas - find it at!