Log for on 3rd January 2014:
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
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
03:21:42  *** juzza1 has joined
03:21:42  *** planetmaker has joined
03:21:42  *** fonsinchen has joined
03:21:42  *** Hirundo has joined
03:21:42  *** sets mode: +vv planetmaker fonsinchen
08:29:08  *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r26215 || Logs: || 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: || 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: || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking"
09:01:36  *** adf88 has joined
09:01:36  *** ChanServ sets mode: +v adf88
09:26:31  *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r26218 || Logs: || 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
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
09:43:00  *** ChanServ sets mode: +v Alberth
10:34:08  *** JGR_ has joined
10:35:00  *** JGR has quit IRC
10:40:45  *** adf88 has quit IRC
10:52:15  *** Eagle_Rainbow has joined
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
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>
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>
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
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> <- 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:
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>
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> 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
13:17:28  *** ChanServ sets mode: +v frosch123
13:29:13  *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r26219 || Logs: || 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
13:33:16  *** ChanServ sets mode: +v Alberth
13:41:31  *** adf89 has joined
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>
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> <- 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>
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:
14:51:35  <Eagle_Rainbow> based on : 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: 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> <- 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> <- there's so many versions there... and most of them have been tried by now :(
15:03:58  <Eagle_Rainbow> 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: || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking"
15:11:40  <Eagle_Rainbow> - linux is green
15:59:39  *** Eagle_Rainbow has quit IRC
16:44:43  *** adf88 has joined
16:44:43  *** ChanServ sets mode: +v adf88
16:46:16  *** adf88 has quit IRC
16:50:56  *** Alberth has left
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: || 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: || 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
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: || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking"
18:45:09  *** adf88 has joined
18:45:09  *** ChanServ sets mode: +v adf88
18:45:14  *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r26224 || Logs: || 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:
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
19:18:26  *** JGR_ has quit IRC
20:21:13  *** Eagle_Rainbow has joined
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 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
21:16:48  <Eagle_Rainbow> Rubidium: What do you think about ? 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  ?
21:42:20  <frosch123> <- 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
22:57:05  *** ChanServ sets mode: +v Zuu

Powered by YARRSTE version: svn-trunk