Times are UTC Toggle Colours
00:00:03 <planetmaker> bridges. but that's road, too 00:00:25 <frosch123> yeah, ScriptSign::GetOwner should also distinguish worldgen/gs signs from bankrupt signs 00:01:08 <frosch123> canals? 00:01:36 <frosch123> hmm, no, i think there are no special scenedit canals 00:01:43 <frosch123> rivers might be different though 00:02:26 <planetmaker> rivers are not owned by anyone 00:02:32 <planetmaker> or should not 00:03:33 <frosch123> yeah, it's a different issue. we can add ScriptTile::IsRiver and ScriptTile::IsCanal as well or so 00:04:01 <frosch123> though there is ScriptMarine::IsCanalTile 00:23:07 *** frosch123 has quit IRC 00:57:44 *** adf88 has quit IRC 01:57:51 *** JGR_ has quit IRC 02:00:35 *** JGR has joined #openttd.dev 03:20:29 *** TheIJ has quit IRC 03:20:29 *** Hirundo has quit IRC 03:20:29 *** fonsinchen has quit IRC 03:20:29 *** juzza1 has quit IRC 03:20:29 *** planetmaker has quit IRC 03:21:42 *** TheIJ has joined #openttd.dev 03:21:42 *** juzza1 has joined #openttd.dev 03:21:42 *** planetmaker has joined #openttd.dev 03:21:42 *** fonsinchen has joined #openttd.dev 03:21:42 *** Hirundo has joined #openttd.dev 03:21:42 *** kinetic.oftc.net sets mode: +vv planetmaker fonsinchen 08:29:08 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r26215 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking" 08:31:33 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r26216 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking" 08:51:49 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r26217 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking" 09:01:36 *** adf88 has joined #openttd.dev 09:01:36 *** ChanServ sets mode: +v adf88 09:26:31 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r26218 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking" 09:35:41 <planetmaker> hm, in the sse code I get warnings about uninitialized variables http://paste.openttdcoop.org/show/2956/ 09:38:51 *** ChanServ sets mode: +v Rubidium 09:38:54 <Rubidium> please post them, together with the compiler version in the thread in the development section 09:39:34 <Rubidium> I don't have those warnings with gcc 4.8 09:40:12 <planetmaker> gcc 4.7.2 09:40:58 <planetmaker> from what I gather reading the code the warnings are pointless. They are used ininitialized - but only be be assigned a value inside the function. 09:43:00 *** Alberth has joined #openttd.dev 09:43:00 *** ChanServ sets mode: +v Alberth 10:34:08 *** JGR_ has joined #openttd.dev 10:35:00 *** JGR has quit IRC 10:40:45 *** adf88 has quit IRC 10:52:15 *** Eagle_Rainbow has joined #openttd.dev 10:52:15 *** ChanServ sets mode: +v Eagle_Rainbow 10:52:40 <Eagle_Rainbow> happy new year to everyone 10:56:00 <Eagle_Rainbow> for me the new SSE2 blitter causes a segmentation fault on startup - already known here? 10:57:13 <Rubidium> not to me 10:59:08 <Eagle_Rainbow> env: gcc 4.4.5 (yes, I know: old), /proc/cpuinfo states SSE and SSE2 only; backtrace is very vague: 10:59:15 <Eagle_Rainbow> 0x6f6 10:59:18 <Eagle_Rainbow> __do_global_ctors_aux() at 0xaaa116 10:59:21 <Eagle_Rainbow> _init() at 0x619f1b 11:02:02 <Eagle_Rainbow> I was able to bisect the issue to be introduced with r26211 (which is no surprise, though) 11:06:55 <Rubidium> Eagle_Rainbow: you forced the sse2 blitter? 11:07:50 <Eagle_Rainbow> nope - appears to be on by default (at least this part) 11:08:57 <Eagle_Rainbow> My gutfeeling tells me: Has something to do with HasCPUIDFlag, as even new Blitter_32bppSSE2() isn't called yet... 11:09:09 * Eagle_Rainbow is trying to debug to give some more hints 11:11:22 <Rubidium> my gcc 4.4.5 binary works just fine 11:11:36 <Rubidium> oh... sorry, 4.4.7 11:16:18 <Eagle_Rainbow> apparently void ottd_cpuid(int info[4], int type) is somehow broken 11:16:34 *** adf88 has joined #openttd.dev 11:16:34 *** ChanServ sets mode: +v adf88 11:16:43 <Eagle_Rainbow> I replaced the asm function with constants valid for my machine and it worked again... 11:17:18 <Rubidium> argh... 11:18:32 <Eagle_Rainbow> could it be that the stack frame gets broken somehow? 11:19:24 <Rubidium> might be; my asm fu comes basically from copy-pasting it from somewhere 11:20:23 <Eagle_Rainbow> :) 12:11:13 <Eagle_Rainbow> @Rubidium: How did you get to the point that the BX register is being clobbered? 12:12:00 <Rubidium> http://farm.openttd.org/browse/OTTD-NIGHTLY-OSX-787/log 12:20:57 <Eagle_Rainbow> mmh.. I think you misunderstood this statement there... 12:21:44 <Eagle_Rainbow> I have reimplemented the CPUID function how I would do it and got totally different results - but those values I would expect to see on my box... 12:23:31 <Eagle_Rainbow> http://pastebin.com/Ey63pY4k 12:25:24 <Rubidium> with your code: /tmp/1.3/src/cpu.cpp:105: error: can't find a register in class 'BREG' while reloading 'asm' 12:26:00 <Rubidium> the 1.3 is a misnomer; it's actually trunk 12:26:25 *** adf88 has quit IRC 12:27:11 <Rubidium> anyhow, your code is roughly the same as the code I used to have 12:27:32 *** adf88 has joined #openttd.dev 12:27:32 *** ChanServ sets mode: +v adf88 12:28:17 <Eagle_Rainbow> ok, lemme better understand that BREG error there.. 12:28:55 <Eagle_Rainbow> ah! now, I understand: PIC != PIC 12:30:33 <Rubidium> http://vcs.openttd.org/svn/changeset/26208 <- that's what I did copy to get that error gone 12:33:17 <Eagle_Rainbow> yea, thanks... Now I understood what the compiler has the problem with: http://sam.zoy.org/blog/2007-04-13-shlib-with-non-pic-code-have-inlin 12:33:52 <Eagle_Rainbow> BTW: pushl %%ebx seems to be enough; you don't need %%rbx 12:34:59 <Rubidium> rbx is needed for 64 bits 12:35:06 <Rubidium> instead of ebx 12:37:10 <Rubidium> do you create 32 bits or 64 bits binaries? 12:39:45 <Eagle_Rainbow> ELF 64-bit LSB executable, x86-64 12:40:04 <Eagle_Rainbow> concerning ebx: yep... got the point 12:40:11 <Eagle_Rainbow> and most likely also found your "template" :) 12:41:40 <Rubidium> http://rbijker.net/openttd/try_this.diff 12:42:20 <Eagle_Rainbow> will do, gimme a second; I want to see something else first 12:44:24 <Eagle_Rainbow> That's hot: at the end of ottd_cpuid() I added a "printf ("test");" just for the sake of having a proper breakpoint - now it works. Without it (just commented it out): back to the old problem 12:44:33 <Eagle_Rainbow> perhaps an inlining issue? 12:44:52 <Rubidium> it shouldn't be inlined, unless you're using LTO or something similar 12:44:53 * Eagle_Rainbow used the old code as of r26211 12:46:00 <Rubidium> r26211 has the anti 'clobbering' code already 12:46:50 <Eagle_Rainbow> yep - and based on a git bisect it was the location where my problem has been introduced 12:46:59 <Eagle_Rainbow> (first commit with the error) 12:47:14 <Rubidium> odd 12:47:25 <Eagle_Rainbow> very odd 12:47:38 <Rubidium> since the code is already used before that 12:48:07 <Rubidium> r26205 to be precise, but not that early in the execution of the game 12:53:25 <Eagle_Rainbow> Had a look at the generated assembler code of both versions: besides some necessary differences of stack frame handling, I don't see a change... 12:55:16 <Eagle_Rainbow> http://rbijker.net/openttd/try_this.diff fixes it for me 12:55:23 <Eagle_Rainbow> But I don't understand why 12:57:19 <Eagle_Rainbow> Especially as "xchgl %%ebx, %1 \n\t" is being translated into "xchg %ebx,%ebx" which is trivial 13:00:12 <Rubidium> maybe it becomes that when PIC isn't used? 13:01:33 <Rubidium> i.e. it becomes another e?x when PIC isn't in use? 13:01:34 <Eagle_Rainbow> perhaps - that the coding of r26211 is thought to be PIC-enabled, but the xchgl version is understood that it won't do it... 13:01:46 <Eagle_Rainbow> don't think so: 13:01:55 <Eagle_Rainbow> I am doing objdump -sD cpu.o 13:02:10 <Eagle_Rainbow> on what the Makefile has created... 13:03:37 <Eagle_Rainbow> If I may have a call: I would prefer the xchgl version in trunk, though I don't get it entirely, yet :) 13:04:31 <Rubidium> it's xchg %ebx,%esi for me 13:04:48 <Rubidium> or xchg %ebx,%r9d 13:05:10 <Rubidium> or xchg %ebx,%edi 13:05:30 <Rubidium> hmm... so it copied the code three times 13:09:18 <Eagle_Rainbow> strange things happen here as well: in the original version (push-variant) produces a "mov %eax,%esi" right after the "pop %rbx" 13:09:34 <Eagle_Rainbow> wouldn't this kill the stack indicator? 13:10:04 <Rubidium> it's xchgl %ebx, %esi on the platform where the BREG error happens on 13:11:14 <Rubidium> I reckon that xchgl %ebx,%ebx is just effectively a no-op, so it can behave like only a cpuid in some cases 13:12:03 <Rubidium> but in other cases it can be used to temporary store the ebx value into some other register, and then once cpuid has run swap ebx and the other register so the original ebx is returned 13:13:12 <Eagle_Rainbow> right 13:16:24 *** Alberth has quit IRC 13:17:28 *** frosch123 has joined #openttd.dev 13:17:28 *** ChanServ sets mode: +v frosch123 13:29:13 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r26219 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking" 13:32:40 <Eagle_Rainbow> thx for r26219 13:33:16 *** Alberth has joined #openttd.dev 13:33:16 *** ChanServ sets mode: +v Alberth 13:41:31 *** adf89 has joined #openttd.dev 13:42:57 *** adf88 has quit IRC 14:11:32 <frosch123> silly cpuid, fails on random machines? 14:17:20 <Eagle_Rainbow> no, it's not cpuid itself... 14:17:35 <Eagle_Rainbow> it more looks that this asm stuff is quite shaky 14:18:16 <frosch123> yeah, now it works on your machine, on mine, on rb's... but fails on the farm again :p 14:18:29 <Eagle_Rainbow> eeeehhh! 14:18:41 <Eagle_Rainbow> could you send me the log again? 14:18:52 <frosch123> http://farm.openttd.org/download/OTTD-TEST-LG64BIT/build_logs/OTTD-TEST-LG64BIT-3016.log 14:19:58 <frosch123> does not look particular useful though 14:20:16 <frosch123> maybe some important registered is destroyed, which makes it crash later 14:20:17 <Rubidium> a crash in the file scanner? 14:20:28 <frosch123> yeah :p 14:21:51 <Rubidium> gcc 4.4 crashes, 4.6-4.8 don't 14:23:09 <Rubidium> gcc 4.4 debug=3 runs 14:23:33 <Eagle_Rainbow> do we have a log from that same box but on r26218? 14:24:01 <frosch123> http://farm.openttd.org/browse/OTTD-TEST <- well, yes, but it succeeded 14:25:34 <Eagle_Rainbow> ok, that means that this compiler version is not able to digest our xchg variant properly... 14:25:47 <Eagle_Rainbow> seems like we fixed the symptom, but not the root cause :( 14:27:09 <Eagle_Rainbow> are we able to somehow get the file objs/debug/cpu.o from #3016? 14:35:08 <Rubidium> http://rbijker.net/openttd/bla.txt 14:37:53 <frosch123> : "0" (type) <- what does the "0" mean, i only know "a" 14:38:56 <Rubidium> copy-pasted from... somewhere 14:39:17 <Rubidium> lets see if changing 0 to a does anything 14:39:21 <Eagle_Rainbow> means: 14:39:43 <Eagle_Rainbow> "take the same register as the zero-ist constraint" 14:40:06 <Eagle_Rainbow> frosch123: would be the same in your case 14:41:29 <Rubidium> 0 or a, crashes in both cases 14:42:03 <Eagle_Rainbow> if someone is interested - see for example: http://www.ibiblio.org/gferg/ldp/GCC-Inline-Assembly-HOWTO.html#ss5.2 14:51:35 <Eagle_Rainbow> based on http://rbijker.net/openttd/bla.txt : it's obvious that the compiler has optimized away the stack frame stuff 14:51:49 <Eagle_Rainbow> However, how, EBX is being clobbered, but we did not explain it 14:52:54 <Eagle_Rainbow> even worse: it can't guess that it's clobbered, so the contents may be voided and cause any arbitrary inconsistency 14:53:57 <Rubidium> hmm, I also see bits of cpuid code that use a different bit of code for x86 PIC than non-PIC x86 or x86_64 14:54:35 <Rubidium> might that be the right way? 14:55:05 <Eagle_Rainbow> What's the difference you see? 14:55:45 <Eagle_Rainbow> BTW: http://rbijker.net/openttd/bla.txt is elf64-x86-64 - mine here as well 14:56:34 <Eagle_Rainbow> the major difference between the farm-box and mine is, that I am using gcc 4.4.5, the farm-box 4.4.7 14:58:32 <Rubidium> http://rbijker.net/openttd/try_this.diff <- might that do the trick (seems to work for my 4.4.7 gcc) 14:59:41 <Rubidium> (seems to build on i386 OSX) 15:00:37 * Eagle_Rainbow will try if it breaks my setup here 15:00:46 <Rubidium> what does the whole volatile asm do? 15:01:01 <Eagle_Rainbow> you mean "volatile" as statement? 15:01:15 <Eagle_Rainbow> s/statement/modifier/ 15:01:32 <Rubidium> __asm__("cpuid;" vs __asm__ __volatile__(... 15:01:50 *** adf89 has quit IRC 15:01:57 <Eagle_Rainbow> "volatile" instructs the gcc compiler that it may not change the sequence of this block 15:02:08 <Eagle_Rainbow> for reasons of optimizations 15:03:16 <Rubidium> http://en.wikipedia.org/wiki/CPUID#Accessing_the_id_from_other_languages <- there's so many versions there... and most of them have been tried by now :( 15:03:58 <Eagle_Rainbow> http://rbijker.net/openttd/try_this.diff doesn't break here as well - regression test on local box: ok 15:09:56 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r26220 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking" 15:11:40 <Eagle_Rainbow> http://farm.openttd.org/browse/OTTD-TEST-3017 - linux is green 15:59:39 *** Eagle_Rainbow has quit IRC 16:44:43 *** adf88 has joined #openttd.dev 16:44:43 *** ChanServ sets mode: +v adf88 16:46:16 *** adf88 has quit IRC 16:50:56 *** Alberth has left #openttd.dev 17:53:17 <Rubidium> planetmaker: can you check whether that patch from the blitter thread helps? 17:55:41 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r26221 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking" 18:03:15 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r26222 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking" 18:29:33 <planetmaker> Rubidium, which patch? 18:30:05 <planetmaker> ah, wrong thread :) 18:34:19 <planetmaker> Rubidium, yes, it actually does help 18:34:44 *** Alberth has joined #openttd.dev 18:34:44 *** ChanServ sets mode: +v Alberth 18:39:24 <Rubidium> planetmaker: could you commit it then? 18:40:51 <planetmaker> sure 18:43:11 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r26223 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking" 18:45:09 *** adf88 has joined #openttd.dev 18:45:09 *** ChanServ sets mode: +v adf88 18:45:14 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r26224 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking" 18:45:50 <planetmaker> I'm unsure about patch1: http://www.tt-forums.net/download/file.php?id=176273 18:45:57 <planetmaker> It smells very much like code duplication 18:46:24 <Rubidium> sadly enough... that's basically the point 18:46:50 <Rubidium> for the different SSE ones you have N variants where each variant is the previous plus an improvement 18:47:09 <Rubidium> and the improvement is usually a slightly more performant SSE instruction 19:13:45 *** JGR has joined #openttd.dev 19:18:26 *** JGR_ has quit IRC 20:21:13 *** Eagle_Rainbow has joined #openttd.dev 20:21:13 *** ChanServ sets mode: +v Eagle_Rainbow 20:21:21 <Eagle_Rainbow> good evening 20:21:42 <Eagle_Rainbow> I slowing begin to understand what the CPUID problem really is about... 20:22:46 <Eagle_Rainbow> If you really look carefully at http://en.wikipedia.org/wiki/CPUID you'll notice that all their coding is not handing over the results to a parameter, but first to local variables. 20:23:21 <Eagle_Rainbow> But if they do (in the case of "Another version of that:"), they explicitly specify which registers shall be used 20:23:50 <Eagle_Rainbow> They don't use "=r" but only "=D" which takes away one degree of freedom to the compiler. 20:24:40 <Eagle_Rainbow> Here on my local box, it caused big trouble, as my compiler - by chance - took EBX (as I did not enable PIC) for this "=r" 20:25:24 <Eagle_Rainbow> This resulted in the following nonsense code: push %rbx; cpuid; mov %ebx, %ebx; pop %rbx 20:26:22 <Eagle_Rainbow> => the value of ebx is gone with the wind, and later on the registers are wrong which leads to writing to *(NULL) 20:27:07 <Eagle_Rainbow> I fear that with the current r26224 it can still be the case. 21:16:19 *** Alberth has left #openttd.dev 21:16:48 <Eagle_Rainbow> Rubidium: What do you think about http://paste.openttdcoop.org/show/2963/ ? It would solve my doubts from above. 21:24:04 <Rubidium> what is, commonly, for PIC in ebx in i386, is in a new register rip in x86_64 21:26:01 <Rubidium> so the whole mess isn't necessary for x86_64 21:28:25 <Eagle_Rainbow> ok, that I did not know 21:28:35 <Eagle_Rainbow> then we get rid of it... 21:31:26 <Eagle_Rainbow> ... and then we can revert back to xchg... mmmh 21:35:12 <Eagle_Rainbow> In case of PIC i386,however, it would be very unlikely that the compiler chooses EBX for the yet-to-define register... the coding is not very self-explaining here 21:41:39 <Eagle_Rainbow> ok, you convinced me that the coding is safe. But still it is too implicit to me. What do you think about some comments in that area like in http://paste.openttdcoop.org/show/2966/ ? 21:42:20 <frosch123> http://git.etherboot.org/gcc/gcc.git/blob/10100befc28f8b993070a154f8a73e2bb716c8af:/gcc/config/i386/cpuid.h <- that one also uses "=r" 21:42:40 <frosch123> there are some myths that gcc would have a "cpuid.h", but i do not have it either 21:43:04 <Eagle_Rainbow> yep, thanks... 21:43:15 <Eagle_Rainbow> I am convinced in the meantime :) 21:43:36 <Eagle_Rainbow> You also see there very well, that they "#if defined(__i386__) && defined(__PIC__)" it 21:44:25 <Eagle_Rainbow> but putting it in a macro, doesn't make it easier to understand either ;) 21:44:28 <frosch123> i have also seen versions which force it to use edi, i.e. "=D" 21:44:40 <frosch123> they use "mov" instead of "xchg" then 21:45:05 <Eagle_Rainbow> yes, has the same effect 21:45:07 <frosch123> hmm, do they? maybe i misremember 21:45:32 <Eagle_Rainbow> There are multiple ways how to get around the issue 21:45:55 <Eagle_Rainbow> The big point is that you have to do the "mov" or "xchg" trick, if it's i386 and PIC-enabled. 21:46:03 <Eagle_Rainbow> In all other cases, you should not do it. 21:46:49 <Eagle_Rainbow> If you do it, you may also hit the wall, if you are using "=r" 21:47:33 <Eagle_Rainbow> which is what happened this morning to me. 21:48:56 * Eagle_Rainbow is asking himself if he shall played the lottery this week - chances might be good :D 21:59:46 <frosch123> night 21:59:49 *** frosch123 has quit IRC 22:42:56 *** Eagle_Rainbow has quit IRC 22:57:05 *** Zuu has joined #openttd.dev 22:57:05 *** ChanServ sets mode: +v Zuu