00:02.19 | freemangordon | dammit, seems like a bug in gcc :( |
00:26.04 | DocScrutinizer05 | wut? you found a bug in gcc? incredible! |
00:26.09 | DocScrutinizer05 | ;-) |
01:38.47 | *** join/#maemo-ssu aap (~drew@cpe-71-64-199-26.cinci.res.rr.com) |
03:42.58 | *** join/#maemo-ssu amiconn_ (amiconn@rockbox/developer/amiconn) |
07:29.09 | *** join/#maemo-ssu cappu (~cappu@peelo.net) |
07:55.42 | *** join/#maemo-ssu sixwheeledbeast (~paul@cl-1547.lon-02.gb.sixxs.net) |
08:14.28 | *** join/#maemo-ssu NIN101 (~core@n900.quitesimple.org) |
08:17.06 | *** join/#maemo-ssu LauRoman (~LauRoman@5-14-92-51.residential.rdsnet.ro) |
08:40.34 | *** join/#maemo-ssu trx (ns-team@212.200.199.87) |
08:40.34 | *** join/#maemo-ssu trx (ns-team@devbin/founder/trx) |
09:01.21 | *** join/#maemo-ssu luf (~luf@ip-89-103-184-55.net.upcbroadband.cz) |
09:43.24 | *** join/#maemo-ssu kolp (~quassel@212.255.122.47) |
09:53.51 | *** join/#maemo-ssu dafox (~dafox@ip51cc571d.speed.planet.nl) |
09:57.33 | *** join/#maemo-ssu NIN102 (~core@n900.quitesimple.org) |
10:48.41 | freemangordon | <PROTECTED> |
10:49.03 | kerio | mh |
10:49.09 | kerio | it could be a problem |
10:49.14 | freemangordon | hmm? |
10:49.18 | kerio | i still have no decent internets on my n900 |
10:49.34 | kerio | actually ima backup |
10:49.36 | freemangordon | so? |
10:49.46 | kerio | idk its a bit annoying |
10:49.51 | kerio | i'll do it tho, need to backup first |
10:49.52 | freemangordon | anyway you should download the .deb by hand |
10:49.59 | freemangordon | ok |
10:50.08 | kerio | fuck moving files around |
10:50.09 | kerio | i wget |
10:50.12 | kerio | or bust |
10:50.33 | freemangordon | kerio: BTW I have the impression that everything is 2 times faster. could be a placebo effect though |
10:50.53 | kerio | :3 |
10:51.22 | kerio | also how's it possible that a 2600eur laptop only has 2 usb ports i dont get it |
10:51.45 | freemangordon | kerio: wait, what?!? you paid 2600 euros for a laptop? |
10:51.54 | kerio | well i paid 2400 for it |
10:51.56 | freemangordon | are you crazy man? |
10:52.03 | kerio | but it's so fucking cool |
10:52.24 | freemangordon | does it do blowjobs? I guess for that price :P |
10:53.22 | kerio | ...why the hell does rescueos need a login via telnet |
10:53.25 | kerio | instead of giving you a shell |
10:54.14 | ShadowJK | 's obnoxiously expensive laptop came with 5 usb ports |
10:54.24 | kerio | fwiw they can't really fit i guess |
10:54.36 | kerio | meh |
10:54.46 | kerio | this shits like crazy small |
10:55.05 | freemangordon | ShadowJK: are you on -thumb? |
10:55.09 | ShadowJK | yes |
10:55.26 | freemangordon | wanna help me test thumb-compiled glibc6? |
10:55.49 | ShadowJK | uh, okay |
10:55.53 | ShadowJK | sounds scary :) |
10:56.00 | kerio | i'm backupping dis |
10:56.29 | freemangordon | is afk for a while |
10:58.05 | kerio | stupid question: does it work on *your* device? |
10:58.26 | freemangordon | kerio: see the link I posted ;) |
10:58.32 | freemangordon | kerio: ofc it does |
10:58.40 | kerio | alright i trust you |
10:58.56 | freemangordon | how do you think I decided that: |
10:59.14 | freemangordon | it is 2 times fatser |
10:59.14 | kerio | idk it's something i'd do :3 |
10:59.33 | kerio | "can you please test this it might wreck your n900, i don't wanna test it on mine" |
11:09.57 | freemangordon | kerio: you're not me :) |
11:11.03 | freemangordon | I never, ever, ask lusers to install thumb-related stuff on their devices without first installing it on my daily and had a reboot |
11:12.26 | kerio | mh, why isn't internet sharing working as intended here |
11:12.34 | kerio | meh |
11:15.56 | freemangordon | ShadowJK: hmm, why scary, it is just another library :) |
11:21.02 | kerio | gaaah why isn't this working |
11:21.04 | kerio | fucking osx |
11:22.33 | kerio | meh |
11:22.36 | kerio | "just works" my ass |
11:23.29 | *** join/#maemo-ssu BCMM (~BCMM@unaffiliated/bcmm) |
11:26.39 | kerio | freemangordon: wait, why are you using an external file storage thing |
11:26.48 | kerio | instead of your space on merlin's server |
11:27.01 | freemangordon | hmm, good question :D |
11:27.17 | kerio | i can't wget that :s |
11:27.55 | freemangordon | however, now my desktop is finally on linux, I'll set up web server and debian repo soon |
11:28.02 | freemangordon | kerio: download it with microb |
11:28.10 | kerio | also i *really* need to find a way to use my home connection |
11:28.15 | kerio | i need to update 22MB of things |
11:28.17 | kerio | 22 is a lot |
11:28.24 | kerio | ...meh fuck it |
11:28.44 | freemangordon | kerio: what is the problem with your home connection? |
11:28.49 | kerio | i can't use it |
11:28.53 | freemangordon | why? |
11:28.54 | kerio | because my n900's wifi doesn't work |
11:28.57 | freemangordon | ooh |
11:29.14 | freemangordon | broken? |
11:29.18 | kerio | i think so, yeah |
11:29.29 | freemangordon | hmm |
11:29.32 | kerio | now, with snow leopard, internet sharing over usbnet used to work |
11:29.47 | kerio | but now, nope |
11:30.12 | kerio | i wonder if i can use bluetooth pan |
11:32.03 | kerio | i'll tell you, it's really pretty fucking annoying |
11:32.19 | kerio | i should probably set up some "stable" usb networking on my home server actually |
11:32.58 | kerio | i really need a powered usb hub for that, tho |
11:33.05 | kerio | the sheevaplug has no protection circuits on the usb port |
11:33.09 | kerio | so it's easy to overdraw |
11:33.14 | kerio | and wreck the power supply |
11:33.31 | freemangordon | why don;t you by another device with everything working? |
11:33.47 | kerio | i'm not gonna buy another n900 |
11:33.48 | kerio | seriously |
11:34.05 | *** join/#maemo-ssu dos1 (~dos@unaffiliated/dos1) |
11:34.35 | freemangordon | hmm, why? |
11:34.43 | kerio | the one i have works! |
11:35.02 | freemangordon | but, but,... you said wifi dowsn't wokr |
11:35.15 | freemangordon | omg, what a typing skills |
11:35.36 | kerio | freemangordon: yeah but it makes phone calls |
11:35.57 | freemangordon | you lost me on that one |
11:37.13 | kerio | it does serve its main purpose |
11:37.54 | *** join/#maemo-ssu _rd (~rd@p57B4BEAC.dip0.t-ipconnect.de) |
11:39.31 | kerio | freemangordon: ok here goes nothin' |
11:39.48 | trx | freemangordon installed, rebooted |
11:39.51 | trx | so far so good |
11:39.56 | kerio | rebooting |
11:40.29 | kerio | h-d isn't crashing |
11:40.32 | kerio | so far so good |
11:40.54 | freemangordon | good |
11:40.55 | trx | it actually is faster |
11:41.05 | freemangordon | trx: ain't? |
11:41.05 | trx | or placebo :) |
11:41.10 | freemangordon | yeah :D |
11:41.18 | trx | but it is |
11:41.19 | kerio | the point of placebo isn't that it does nothing |
11:41.22 | kerio | the point of placebo is that it works |
11:41.24 | kerio | :3 |
11:41.27 | kerio | anyway, it works |
11:41.30 | trx | it started up faster, and opens shit faster |
11:41.36 | freemangordon | :nod: |
11:41.44 | freemangordon | same feeling here |
11:41.47 | trx | good job :) |
11:41.48 | kerio | feel faster but it could be suggestion |
11:42.07 | freemangordon | will compare with my GF's device when she is here |
11:43.00 | kerio | let's get DocScrutinizer into this |
11:43.45 | ShadowJK | main purpose is wifi+3g for irc, surely |
11:44.12 | kerio | ShadowJK: to be honest, yeah |
11:44.18 | kerio | but meh, i have a laptop |
11:44.24 | kerio | so wifi+irc isn't *that* useful |
11:44.30 | kerio | and irc uses so little traffic anyway |
11:46.16 | freemangordon | hmm, ok, will test it for a week and will issue a new update |
12:13.35 | *** join/#maemo-ssu M4rtinK (~M4rtinK@mail.melf.eu) |
12:16.50 | *** join/#maemo-ssu okias (~okias@berger.cust.centro-net.cz) |
12:35.59 | *** join/#maemo-ssu hbib (~wurmel@pD9E0D645.dip0.t-ipconnect.de) |
12:42.29 | Ashley` | freemangordon, I am not sure, but I think my N900 with your libc started up faster :P |
12:50.40 | *** join/#maemo-ssu dafox (~dafox@ip51cc571d.speed.planet.nl) |
12:55.36 | *** join/#maemo-ssu _rd (~rd@p57B4BEAC.dip0.t-ipconnect.de) |
13:29.04 | kerio | it probably did |
13:29.11 | kerio | i mean, libc is kind of used everywhere |
13:29.17 | kerio | and this is a better version |
13:34.39 | *** join/#maemo-ssu NIN102 (~core@n900.quitesimple.org) |
13:41.33 | *** join/#maemo-ssu scoobertron (~tom@66.172.11.27) |
14:01.14 | *** join/#maemo-ssu scoobertron (~tom@66.172.11.27) |
14:05.13 | *** join/#maemo-ssu _rd (~rd@p57B4BEAC.dip0.t-ipconnect.de) |
14:24.58 | *** join/#maemo-ssu javispedro (~javier@69.Red-80-32-146.staticIP.rima-tde.net) |
14:24.58 | *** join/#maemo-ssu javispedro (~javier@Maemo/community/contributor/javispedro) |
14:39.45 | *** join/#maemo-ssu _rd (~rd@p57B4BEAC.dip0.t-ipconnect.de) |
14:54.03 | *** join/#maemo-ssu trx (ns-team@212.200.199.87) |
14:54.03 | *** join/#maemo-ssu trx (ns-team@devbin/founder/trx) |
15:06.22 | *** join/#maemo-ssu _rd (~rd@p57B4BEAC.dip0.t-ipconnect.de) |
15:16.57 | freemangordon | hmm, I tried to compare application startup times between my device with -thumb glibc and my GF's device, with cssu's one. Also compared the devices startup times. My device is OC to 805, her is @ 600. Surprise, surprise: |
15:17.13 | freemangordon | There is no difference :D |
15:17.43 | freemangordon | so, that means that my test cases are flawed and we're still flash/swap speed bound |
15:18.14 | freemangordon | I am open to suggestions on how to test thumb/non-thumb glibc speed |
15:18.22 | freemangordon | DocScrutinizer05: ^^^ |
15:19.17 | freemangordon | all others too ofc: ^^^ |
15:31.54 | *** join/#maemo-ssu hbib1 (~wurmel@pD9E0D780.dip0.t-ipconnect.de) |
15:33.32 | *** join/#maemo-ssu _rd (~rd@p57B4BEAC.dip0.t-ipconnect.de) |
15:41.09 | DocScrutinizer05 | I think there is no better test than real usecase like boot time and app startup. It's probably hard to create and run real standardized application performance tests |
15:48.57 | *** join/#maemo-ssu trx (ns-team@devbin/founder/trx) |
15:51.36 | kerio | DocScrutinizer05: install the glibc! |
15:53.23 | *** join/#maemo-ssu dhbiker (~dhbiker@95.87.145.172) |
15:54.00 | *** join/#maemo-ssu arcean (~arcean@aadd220.neoplus.adsl.tpnet.pl) |
16:19.38 | freemangordon | DocScrutinizer05: yes, but if the speed is IO bound, such test tells nothing about glibc speed |
16:20.35 | DocScrutinizer05 | well, then glibc speed is irrelevant? |
16:28.08 | DocScrutinizer05 | when you find your PC has a bottleneck on IO/HDD, will you throw massive amounts of money at a octocore instead of the dualcore it may have right now, when you consider improving it? |
16:34.25 | *** join/#maemo-ssu _rd (~rd@p57B4BEAC.dip0.t-ipconnect.de) |
16:39.09 | freemangordon | DocScrutinizer05: come on, I am not 13 years old :P. If glibc is faster that means slightly better battry life, ain't? |
16:40.11 | freemangordon | DocScrutinizer05: I want to measure glibc performance, not the system performance. But have no idea how |
16:40.16 | DocScrutinizer05 | umm, right. then that's the way to go for glibc evaluation, no? simply check system load average last 5 min, while doing exactly same tasks on two systems |
16:40.58 | dos1 | aren't thumb binaries actually slower? |
16:41.15 | DocScrutinizer05 | supposed to be slower, yes |
16:41.18 | dos1 | I thought that speed up on cssu-thumb came from decreased memory usage |
16:41.27 | DocScrutinizer05 | :nod: |
16:41.44 | DocScrutinizer05 | I'm unclear if this whole thing is about thumb though |
16:42.08 | freemangordon | dos1: but the catch is that gcc used to build them is waaay better than stock |
16:42.10 | DocScrutinizer05 | might be related to a newer improved glibc version, unrelated to thumb |
16:42.32 | dos1 | freemangordon: ah, ok |
16:42.37 | DocScrutinizer05 | :-) |
16:42.40 | DocScrutinizer05 | makes sense |
16:43.05 | freemangordon | dos1: for example - some openssl benchmarks are 2 times faster with thumb and gcc 4.7.2 |
16:43.08 | DocScrutinizer05 | freemangordon: check system load |
16:43.29 | DocScrutinizer05 | make sure you're not suffering from IO lagging |
16:43.33 | freemangordon | DocScrutinizer05: hmm, ok. will ask google too |
16:43.54 | freemangordon | it is not a lag, might be related to rootfs compression |
16:43.58 | DocScrutinizer05 | e.g game playing might be a good way to check for CPU load |
16:44.11 | freemangordon | don;t think so |
16:44.26 | DocScrutinizer05 | nah, IO spoils load figures while CPU actually might be idle |
16:44.35 | freemangordon | yep |
16:44.52 | DocScrutinizer05 | thus do something that's CPU heavy and IO light |
16:45.01 | DocScrutinizer05 | and then check system load |
16:45.19 | DocScrutinizer05 | A vs B |
16:46.00 | freemangordon | hmm, what about that one? http://www.etalabs.net/libc-bench.html |
16:46.39 | DocScrutinizer05 | time for ((x=0; x<10000000; x++ )) do :; done |
16:48.41 | DocScrutinizer05 | well, maybe 2 "0" less |
16:49.46 | freemangordon | lets see |
16:51.01 | DocScrutinizer05 | IroN900:~# time for ((x=0; x<100000; x++ )) do :; done; cat /proc/loadavg |
16:51.02 | DocScrutinizer05 | real 0m15.943s |
16:51.03 | DocScrutinizer05 | user 0m15.344s |
16:51.04 | freemangordon | hmm, actually it takes about a second for every test, lets not OK |
16:51.05 | DocScrutinizer05 | sys 0m0.289s |
16:51.06 | DocScrutinizer05 | 0.23 0.07 0.02 1/202 22962 |
16:51.13 | freemangordon | OC even |
16:51.28 | DocScrutinizer05 | maybe I need to add one 0 |
16:51.52 | freemangordon | use how it is, the whole bench takes about 40 seconds |
16:51.54 | freemangordon | here :) |
16:52.48 | freemangordon | real0m 35.85s |
16:52.51 | freemangordon | user0m 17.40s |
16:52.53 | freemangordon | sys0m 14.48s |
16:53.07 | freemangordon | device @ 600 MHz, glibc-thumb |
16:53.57 | freemangordon | this is for libc-bench, lets see how it will perform on cssu glibc |
16:56.34 | DocScrutinizer05 | IroN900:~# time for ((x=0; x<1000000; x++ )) do :; done; cat /proc/loadavg |
16:56.36 | DocScrutinizer05 | real 2m41.718s |
16:56.37 | DocScrutinizer05 | user 2m36.547s |
16:56.39 | DocScrutinizer05 | sys 0m2.336s |
16:56.40 | DocScrutinizer05 | 0.94 0.46 0.17 1/202 22963 |
16:57.00 | freemangordon | real0m 35.85s |
16:57.03 | freemangordon | user0m 17.40s |
16:57.05 | freemangordon | sys0m 14.48s |
16:57.14 | freemangordon | device with cssu libc @ 600 MHz |
16:57.24 | freemangordon | oops |
16:57.28 | freemangordon | real0m 35.60s |
16:57.30 | freemangordon | user0m 17.16s |
16:57.32 | freemangordon | sys0m 14.38s |
16:57.34 | freemangordon | that one ^^^ |
16:58.19 | freemangordon | DocScrutinizer05: -sh: syntax error: "(" unexpected |
16:58.28 | freemangordon | do you have bash by chance? |
16:58.33 | DocScrutinizer05 | use a proper shell |
16:58.49 | freemangordon | oh, come on |
16:59.24 | freemangordon | I won't install bash on my GF's device just to please you :) |
17:00.17 | DocScrutinizer05 | then rewrite the above oneliner to basicbourne |
17:00.28 | freemangordon | is C/++ developer :P |
17:00.37 | DocScrutinizer05 | and i'll happily c&p and echo the results |
17:00.41 | freemangordon | not a linux admin |
17:00.58 | freemangordon | seriously, it'll take me 15 minutes to figure it out |
17:01.20 | DocScrutinizer05 | the obvious use of "for i in `seq 1 1000000`" might fail epically |
17:02.37 | DocScrutinizer05 | you'll have to unroll the for-statement into a proper conditional sequence wrapped into a while loop |
17:03.24 | DocScrutinizer05 | sth like i=0; while [ i -lt 100000 ]; do :; done |
17:03.31 | DocScrutinizer05 | err |
17:03.54 | DocScrutinizer05 | sth like i=0; while [ i -lt 100000 ]; do $(( i++ )) :; done |
17:04.00 | freemangordon | DocScrutinizer05: scratch that , this libc-bench tests various stuff, like ptherds etc |
17:04.32 | freemangordon | seems glibc-thumb is neither faster nor slower than cssu glibc |
17:04.44 | DocScrutinizer05 | that's for sure nice but far from my every day reality |
17:05.07 | DocScrutinizer05 | well, THAT result however is pretty close to my reality ;-P |
17:05.12 | freemangordon | ok, maybe 2-5% faster, but i guess that is not relevant |
17:05.42 | DocScrutinizer05 | yeah, <5% is probing error |
17:05.49 | freemangordon | what counts is that gliibc alone is 1.2 MB in cssu and ~800k thumbified |
17:06.15 | DocScrutinizer05 | hmm, so we saved 400kB |
17:06.43 | DocScrutinizer05 | which is nice though not groundbreaking |
17:09.04 | freemangordon | more than that, there are more libs and bins in glibc |
17:09.18 | freemangordon | maybe aboiut 600-700KiB |
17:33.35 | DocScrutinizer05 | really nice, but still... It's a shared lib |
17:34.56 | DocScrutinizer05 | I guess the best thing to say about new glibc would be that it's basically not distinguishable from old one |
17:36.12 | DocScrutinizer05 | 100% compatibility is of paramount importance. everything else is just a bonus on top |
17:37.08 | DocScrutinizer05 | I've seen gcc or linker fsckup symbol names so stuff broke with no apparent reason |
17:37.35 | DocScrutinizer05 | and of course it did that for one variable type only, in one particular situation |
17:40.44 | DocScrutinizer05 | sure apps liked against new lib used new symbol name, but "old" apps suddenly stopped working with "symbol not found" despite the particular function didn't change at all in new lib version |
17:41.00 | DocScrutinizer05 | linked* |
17:41.09 | *** join/#maemo-ssu _rd (~rd@p57B4BEAC.dip0.t-ipconnect.de) |
17:42.41 | DocScrutinizer05 | and since no proper testframe came with the whole thing, the problem only showed up much later, when first app not only referred to but actually used that particular function (iirc) |
17:43.48 | DocScrutinizer05 | must have been like 6 years or more ago, so sorry when my memory is sparse |
17:44.38 | DocScrutinizer05 | iirc it been in context of twinkle and probably libboost or the rtp-libs |
17:44.57 | DocScrutinizer05 | or maybe even qt |
17:55.40 | freemangordon | DocScrutinizer05: just look at lines 39-40 here https://gitorious.org/community-ssu/glibc/commit/c3afe0ae3f658b947126e27950ad0cf41410ae23 |
17:55.55 | freemangordon | that is what fixes the non-working locales :D |
17:56.11 | freemangordon | re: "I've seen gcc or linker fsckup symbol names so stuff broke with no apparent reason" |
17:57.23 | freemangordon | without that patch _nl_category_name_idxs[category] always evaluates to 0, no matter the index |
17:57.35 | freemangordon | gcc screwed it badly this time |
17:58.03 | freemangordon | or /me knows nothing about C |
18:28.14 | *** join/#maemo-ssu ravelo (~ravelo@178.115.0.112.wireless.dyn.drei.com) |
18:39.39 | DocScrutinizer05 | err, looks pretty much gibbersih to me. |
18:40.30 | DocScrutinizer05 | anyway that one actual c line that's in there looks semantically changed to me |
18:42.04 | DocScrutinizer05 | <PROTECTED> |
18:42.49 | DocScrutinizer05 | no idea what happens when adding those |
18:45.23 | DocScrutinizer05 | to make matter worse, the whole thing is a multiline #def aiui |
18:47.14 | DocScrutinizer05 | which renders the whole thinh subject to macroprocessor parsing. No idea what the macroprozessor creates out of it |
18:47.26 | DocScrutinizer05 | thing* |
18:47.52 | DocScrutinizer05 | a trailing space can already mess up stuff I guess |
18:49.23 | DocScrutinizer05 | I seem to recall it's not first time I seen "( )" used in macros, for obscure reasons |
18:49.50 | DocScrutinizer05 | though the major diff is the deref* |
18:50.35 | DocScrutinizer05 | and all this needs checking if it might mean something special to the macroprocessor |
18:51.14 | DocScrutinizer05 | don't ask me about the makefile sed commands, completely obscure |
18:52.18 | DocScrutinizer05 | +nscd-cflags += -fstack-protector $(common-objpfx)$(binfmt-subdir)/ld-linux.so.3 errwutevr |
18:57.08 | *** join/#maemo-ssu _rd (~rd@p57B4BEAC.dip0.t-ipconnect.de) |
19:21.54 | freemangordon | DocScrutinizer05: scratch the makefiles change, I pointed you to lines 39-40 |
19:21.59 | freemangordon | - _nl_category_names.str + _nl_category_name_idxs[category] |
19:22.02 | freemangordon | 40 + (_nl_category_names.str + *(_nl_category_name_idxs + category)) |
19:22.12 | freemangordon | this is one and the same thing |
19:22.31 | freemangordon | but gcc fails to properly compile the old one |
19:22.45 | freemangordon | that "_nl_category_names.str + _nl_category_name_idxs[category]" one |
19:23.23 | freemangordon | this always results in like "category" is 0 |
19:24.31 | freemangordon | I put the brackets as I am used to always surrond macro expressions in brackets |
19:24.36 | freemangordon | *surround |
19:28.47 | ShadowJK | I forget if it depends on how the type whether foo[bar] is same as * (foo + bar) or not |
19:30.07 | *** join/#maemo-ssu M4rtinK (~M4rtinK@ip-37-188-226-193.eurotel.cz) |
19:32.44 | freemangordon | ShadowJK: index is always converted to in and whether it is *(p+i) or p[i] makes (well, should not make) any difference |
19:32.53 | freemangordon | s/in/int/ |
19:33.05 | freemangordon | hmm? |
19:33.26 | freemangordon | anyway, read "converted to int" |
19:34.08 | freemangordon | ShadowJK: both dereference the same pointer type |
19:34.47 | freemangordon | well, it is not the first time in the history when the compiler oversmarts itself |
19:35.48 | freemangordon | ShadowJK: think of *p and p[0] |
19:42.07 | DocScrutinizer05 | freemangordon: is this c or c++? |
19:42.13 | *** join/#maemo-ssu NIN101 (~core@n900.quitesimple.org) |
19:42.33 | DocScrutinizer05 | aiui _nl_category_names.str is an object |
19:42.45 | freemangordon | DocScrutinizer05: this is C |
19:42.52 | freemangordon | glibc, remember :P |
19:42.56 | DocScrutinizer05 | ooh |
19:42.59 | DocScrutinizer05 | :-P |
19:43.41 | DocScrutinizer05 | well, then it's actually just a question if it maybe is a macropreprocessor hiccup |
19:44.09 | DocScrutinizer05 | you qould try kick out optimization, just for test |
19:44.15 | DocScrutinizer05 | could* |
19:44.26 | DocScrutinizer05 | -O0 ? |
19:44.49 | *** join/#maemo-ssu FlameReaper (~assassin@203.106.65.208) |
19:45.08 | DocScrutinizer05 | check preproc output of both versions |
19:45.15 | DocScrutinizer05 | check assembly of both versions |
19:45.25 | DocScrutinizer05 | will tell a story, I'm sure |
19:46.45 | DocScrutinizer05 | no doubt it's a bug or highly undesirable "feature" of gcc |
19:46.59 | ShadowJK | lol, I logged in to my server and did "nano test.c" and discovered previous test was also pointer arithmetic |
19:47.00 | DocScrutinizer05 | nevertheless I'd want to check what exactly happening there |
19:48.33 | DocScrutinizer05 | maybe compiler thinks _nl_category_name_idxs is an array of vars of size 0 |
19:49.14 | DocScrutinizer05 | (yeah I know that doesn't make any sense) |
19:50.23 | DocScrutinizer05 | nayway sizeof(_nl_category_name_idxs) would be first thing I'd check |
19:51.10 | DocScrutinizer05 | as well as sizeof(_nl_category_name_idxs[0]) |
20:04.50 | *** join/#maemo-ssu M4rtinK2 (~M4rtinK@ip-37-188-229-109.eurotel.cz) |
20:05.51 | DocScrutinizer05 | I'd almost *bet* compiler "thinks" the elements of _nl_category_name_idxs are size 0 |
20:06.22 | DocScrutinizer05 | does it comsist of structs? |
20:07.04 | DocScrutinizer05 | which are still "empty" at that time/phase of compiler run? |
20:08.03 | freemangordon | DocScrutinizer05: glibc can't be compiled without optimization |
20:08.13 | freemangordon | there is a compile-time check |
20:08.45 | DocScrutinizer05 | and I bet it optimizes by compile-time solving of constant arithmetic expressions |
20:09.21 | DocScrutinizer05 | and for some reason thinks sizeof(_nl_category_name_idxs) == 0 |
20:10.08 | DocScrutinizer05 | thus the whole "+ _nl_category_name_idxs[category]" term is const 0 |
20:10.16 | DocScrutinizer05 | --> optimize it out |
20:16.34 | *** join/#maemo-ssu _rd (~rd@p57B4BEAC.dip0.t-ipconnect.de) |
20:33.07 | *** join/#maemo-ssu _rd (~rd@p57B4BEAC.dip0.t-ipconnect.de) |
21:20.47 | *** join/#maemo-ssu M4rtinK2 (~M4rtinK@ip-89-177-125-59.net.upcbroadband.cz) |
21:20.58 | kerio | freemangordon: have you seen luf lately? |
21:22.06 | *** join/#maemo-ssu nox- (noident@freebsd/developer/nox) |
21:29.12 | *** join/#maemo-ssu xes (~xes@unaffiliated/xes) |
22:06.18 | freemangordon | kerio: mo :( |
22:57.05 | *** join/#maemo-ssu mikestav (~mikestav@193.104.110.146) |
23:12.33 | *** join/#maemo-ssu M4rtinK (~M4rtinK@ip-89-177-125-59.net.upcbroadband.cz) |
23:43.34 | *** join/#maemo-ssu psycho_oreos (~no@unaffiliated/tuxsavvy) |