IRC logs for #openrisc Friday, 2015-01-09

--- Log opened Fri Jan 09 00:00:47 2015
stekernpoke53282: did you have the glibc test results somewhere?06:19
poke53282ysangkok: This is a special feature. I still trying to find a good name for it. "Error" or "Failure". "Mistake" sounds also good.07:56
poke53282I fixed it already yesterday. But probably didn't pushed it to master.07:59
poke53282 But probably didn't push it to master.07:59
poke53282stekern: gcctestsuitelogs.tar.xz08:04
poke53282sorry, jor1k.com/gcctestsuitelogs.tar.xz08:04
poke53282ysangkok: I hope you saw with your last pull request, that we need a plugin system. The current keyboard handling is horrible.08:09
poke53282And the code size enlarges with such libraries.08:13
poke53282I tried already term.js some time ago. And the only thing, which prevented m from implementing it was a missing plugin system.08:16
olofkI'm beginning to think that fusesoc copying files before building wasn't the best idea08:22
olofkhmm... no, it was a great idea08:22
olofkJust need to add a qip parser08:23
stekernpoke53282: thanks08:27
stekernolofk: I think it's great ;)08:28
stekernwhat do you need a qip parser for?08:28
olofkIt would be nice to just specify which qip files you got, and let fusesoc parse the qip file to know which files to copy08:29
stekernah, yes08:36
olofkHas anyone tried any python test framework?08:47
stekernI've used unittest in a project at work09:05
stekernpoke53282: looking at the first failure now, 20030125-110:13
stekerngrepping irc logs I see that you investigated this a bit earlier10:13
stekerndid you gather anything interesting about it (that's not in the logs?)10:14
poke53282which error do you mean? musl or glibc?12:13
poke5328220030125-1 seems to be musl-related problem.12:15
poke53282The problem don't exist for glibc and uclibc.12:15
poke53282musl compiled for x86 also don't show the error.12:16
poke53282I don't know if it has anything to do with soft-float.12:16
poke53282Maybe to try x86-musl with soft-float is an option.12:17
stekernit fails for me when I compiled it with uclibc12:19
stekernquit12:22
stekernoops12:22
poke53282Ok, my uclibc one year ago, before I switched to musl.12:29
poke53282I know that the torture testsuite was Ok during that time.12:29
poke53282This was also another gcc version. So, who knows.12:31
stekernmy uclibc toolchain is some old 4.9.0 based one12:34
stekernbut I haven't ran the tests against that, just statically compiled that particular testcase12:35
poke53282I am talking of 4.8.0.12:42
poke53282except of such tests I couldn't figure out even a starting point.12:43
poke53282binutils, gcc, musl. I don't know where to begin.12:43
poke53282And I am not that familiar with the object file format and all flags.12:44
poke53282I am not sure, where this optimization step of  float and double functions is done. I would guess gcc.12:45
poke53282It might be, that gcc sets some flags, but the linker does the wrong thing.  Who knows.12:48
poke53282But I am curious about the solution :)13:23
stekernpoke53282: me too16:35
stekernor1k-elf doesn't fail that, which is good16:35
stekernshould at least be semi-easy to spot the difference16:35
stekernno, scratch that, it does fail16:37
stekernwhich is weird, because iirc it doesn't fail when you run the testsuite...16:39
poke53282elf does fail too. So it is not related to the libc?16:42
stekernah, my old clang/llvm toolchain doesn't fail16:43
stekernif I understand the problem correctly, floorf should be picked instead of floor, but that doesn't happen for some reason16:45
stekernI have no idea what logic should handle that decision though16:45
poke53282Hmm16:46
poke53282that's not possible.16:46
poke53282yes, exactly. It is writtenin the C standard somehow. I guess, this is supposed to be a speed optimization, because it does not really matter, which floor you use.16:47
poke53282but that would mean, that this is generic problem in gcc and should happen for every CPU.16:48
stekernright16:48
poke53282The only difference is, that we use soft-float.16:48
poke53282But this error happened in gcc 4.9.0 and 4.9.1.16:49
poke53282and glibc does not trigger this error.16:49
poke53282binutils, musl, gcc? I am puzzled like you.16:50
poke53282upgrade to gcc 4.9.2 would be an option.16:51
stekerndid you use the same gcc for glibc as musl?16:51
poke53282yes16:52
poke53282Ok, you can look it up I hope. But I am pretty sure.16:54
poke53282but upgrading is always a good idea. :)16:54
poke53282the version string does not end with ".0". So it is a good upgrade.16:55
stekernmy guess is that the magic happens somewhere in gcc/convert.c16:55
stekernor rather, should happen16:56
stekernbut why it doesn't happen with glibc is a mystery16:56
poke53282why it never happened before? gcc 4.8.x and uclibc16:57
stekernalso good questions16:58
poke53282Can you just compile it and not link? Can you figure out, to which it have to link in the .o file?17:00
poke53282... to which function is has to link ....17:00
stekernthis happens before link17:04
stekerngcc -S file.c -o -17:05
stekern...shows that there's a call to floor instead of floorf17:09
stekerndoing the same with an arm toolchain I have laying around shows a call to floorf17:10
stekernah, found the problem18:02
stekerngit blame came to rescue once again18:03
stekernhttps://github.com/openrisc/or1k-gcc/commit/30f690e026ecdf99c68e777a48562b58afe37f4318:04
stekernthat's the commit that brakes it18:04
stekernhttps://github.com/openrisc/or1k-gcc/commit/30f690e026ecdf99c68e777a48562b58afe37f43#diff-61fc56cb0daf2861012999ef5e06a8c9R3818:05
stekernand that's the line that explains why it works on glibc and not musl18:05
stekernchanging that to: if (OPTION_GLIBC || OPTION_MUSL) fixes it18:10
stekernpoke53282: I wonder why it worked for you in sabotage then?18:10
poke53282Great18:38
poke53282sabotage using x86 I guess.18:39
poke53282but not sure18:51
stekernyes, but that test should fail if the same gcc patches that musl-cross uses is used19:21
stekernbut which gcc version was used there?19:29
* stekern is sidetracking into installing alpine in a virtual machine19:37
poke53282stekern: looks like gcc47419:51
stekernok, that's probably pre that patch19:56
stekernit was committed sometime 201319:56
stekernaugust 19 2013 to be precise19:57
poke53282yes19:58
ysangkokpoke53282: i submitted a new pull request which uses a modularized layout19:58
poke53282yes, I saw it19:59
ysangkokpoke53282: i'll start working on the json stuff now19:59
poke53282Still checking19:59
stekernnot sure that is it though, it was '#define TARGET_C99_FUNCTIONS (OPTION_GLIBC)' before the patch20:00
poke53282might be gcc 474 but maybe with some patches. I don't want to check this.20:02
poke53282If your patch solves the problem I am fine.20:02
poke53282And I will rerun the musl testsuite.20:03
poke53282ysangkok: terminal-macke :)20:04
poke53282Actually it is the linux-terminall. "export TERM=linux"20:04
ysangkokbut that name is confusing... as if the other one doesn't work with linux... oh well, it's just names20:05
poke53282yes, it is confusing. term.js is also confusing. Should be xterm.js.20:07
poke53282But finally I seem to be famous enough, that other people name things after me. :P20:09
ysangkok:P i named your thing though :P20:09
stekernalpine has 4.8.3 and it doesn't fail20:16
stekernit has 4.9.2 in "edge"20:18
stekernyep, that test fails with 4.9.2 in alpine as well20:26
poke53282you should involve dalias from here on20:27
daliashm?20:27
stekerndalias: gcc 4.9.x needs an additional musl specific patch20:29
daliaswhat breaks without it?20:29
stekernsomething in the line of: http://pastie.org/982285620:30
stekernwait, I'll paste the gcc testsuite test that fails20:30
poke53282testsuite 20030125-120:30
daliasthat's probably a bad idea in general in case there are other stupid glibc-specific things this gets used for eventually20:31
daliasimo from gcc's perspective it should assume musl provides any standard functions but nothing else (e.g. not sincos and other stupid things)20:31
stekernhttp://pastie.org/982285920:31
daliasmusl's sincos is not a performance boost; it's a naive wrapper that simply calls both sin and cos to make broken apps happy :-p20:31
stekernmmm, maybe it needs to be more specific20:32
daliasi don't think it's important to pass that test tho20:34
stekernyou're probably right, but I'm combing through the test failures in our gcc port and that was the first in line20:36
poke53282ysangkok: You forgot to include term.js20:45
poke53282browserify does not work.20:45
ysangkokpoke53282: i didn't want to add too much. since it's not used by default, can't we just remove the relevant part in ./compile, and then it should work?20:47
poke53282Well, yes. I can do it20:47
ysangkoki mean remove "-r ./js/plugins/terminal-termjs.js:TermJSTerm"20:48
ysangkoki'll write a small document in the wiki with instructions on how to use term.js20:49
poke53282time to clean up the ui mess.20:49
poke53282Ok20:49
poke53282I have also updated fs2xml20:52
ysangkokpoke53282: ok, here's the wiki page : https://github.com/s-macke/jor1k/wiki/Changing-terminal-emulator20:59
poke53282Well, I hope that will be outdated soon.21:01
poke53282It is too complicated21:01
ysangkokhmmm i don't think it's so bad... most people won't need to change terminal emulator anyway though. the instructions are precise, i think21:05
poke53282the whole ui will get a revision. This part included21:07
ysangkokgood :)21:10
poke53282I hope you saw the mess.21:10
poke53282It got worse with your last commit.21:10
poke53282the mess is now separated to several files ;)21:11
ysangkokan abstraction of messes may allow for easier mess-removal :P21:13
ysangkokpoke53282: would gdb work if i built it?21:32
poke53282nope21:35
poke53282there is something missing in the kernel and in gdb itself.21:36
ysangkokok21:50
--- Log closed Sat Jan 10 00:00:49 2015

Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!