Steve Dower added the comment: > I'd be fine to reconsider if a previously-demonstrated bug is now > demonstrated-fixed. However, if the actual bug persists, optimization > should be disabled for all code, not just for the code that allows to > demonstrate the bug.
I'm okay with that. I thought you meant never enable optimizations with that compiler ever again, which is obviously ridiculous and I should have dismissed the idea on that basis rather than posting a snarky response. Sorry. > It seems to me that at the time the wrong branch is taken, f->id > could be in the registers in the wrong order (same as in msg170985), > but when the error message is printed, the value is read from > memory. This is just a guess of course. I checked that and the registers are fine. Here's the snippet of disassembly I posted with the bug I filed: mov edx,dword ptr [edi+4] ; == 0x40000000 mov ecx,dword ptr [edi] ; == 0x00000001 test edx,edx ; should be cmp edx,40000000h or equiv. ja lbl1 ; 'default:' jb lbl2 ; should be je after change above cmp ecx,21h jbe lbl2 ; should probably be lbl3 lbl1: ; default: ... lbl2: cmp ecx,1 jne lbl3 ; case 0x4000000000000001 ... It's clearly an incorrect `test` opcode, and I'd expect switch statements where the first case is a 64-bit integer larger than 2**32 to be rare - I've certainly never encountered one before - which is why such a bug could go undiscovered. When I looked at the disassembly for memoryview it was fine. I actually spent far longer than I should have trying to find the bug that was no longer there... Also bear in mind that I'm working with VC14 and not VC10, so the difference is due to the compiler and not simply time or magic :) ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue15993> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
