Bug 5364 – optimizer kills high dword of -1

Status
RESOLVED
Resolution
FIXED
Severity
critical
Priority
P2
Component
dmd
Product
D
Version
D2
Platform
x86
OS
Linux
Creation time
2010-12-22T21:53:00Z
Last change time
2011-11-18T08:32:03Z
Keywords
wrong-code
Assigned to
nobody
Creator
ellery-newcomer

Comments

Comment #0 by ellery-newcomer — 2010-12-22T21:53:58Z
dmd 2.050. the code: import std.stdio; long b(long bmax){ if(true){ } if(bmax >= 0) bmax = -1; return bmax; } void main(){ writeln(b(0)); } the compilation: dmd -O -inline test.d the result: 4294967295
Comment #1 by clugdbug — 2010-12-22T23:46:32Z
Works on Windows. (Tried 2.020, 2.030, 2.040, 2.049, 2.050, 2.051, also tried -release).
Comment #2 by clugdbug — 2011-08-01T03:59:14Z
I can't reproduce this on Linux64 either, with the DMD from git master. Unless somebody can reproduce this, it should be closed as WORKSFORME.
Comment #3 by ellery-newcomer — 2011-08-03T05:52:39Z
I am still seeing this behavior on DMD32 2.054, Fedora 14 64 bit. I don't have internet access at home, so I can't test against DMD from git master.
Comment #4 by ellery-newcomer — 2011-08-11T19:19:25Z
just built dmd from github, and I am seeing this behavior there, too.
Comment #5 by ellery-newcomer — 2011-09-24T16:52:49Z
FWIW, just tested dmd 2.055 against this issue - 32 bit version has it, 64 bit version doesn't.
Comment #6 by clugdbug — 2011-09-26T07:32:12Z
Could you please post the disassembly of main() and b() when compiled with -O -inline?
Comment #7 by ellery-newcomer — 2011-09-26T08:59:08Z
the compile: ~/Downloads/dmd2/linux/bin32/dmd pest -inline -O the assembly dump: 08085344 <_D4pest1bFlZl>: 8085344: 55 push ebp 8085345: 8b ec mov ebp,esp 8085347: 8b 4d 0c mov ecx,DWORD PTR [ebp+0xc] 808534a: 8b 44 24 08 mov eax,DWORD PTR [esp+0x8] 808534e: 85 c9 test ecx,ecx 8085350: 7c 0d jl 808535f <_D4pest1bFlZl+0x1b> 8085352: 7f 04 jg 8085358 <_D4pest1bFlZl+0x14> 8085354: 85 c0 test eax,eax 8085356: 72 07 jb 808535f <_D4pest1bFlZl+0x1b> 8085358: b8 ff ff ff ff mov eax,0xffffffff 808535d: 31 c9 xor ecx,ecx 808535f: 5d pop ebp 8085360: 8b d1 mov edx,ecx 8085362: c2 08 00 ret 0x8 8085365: 90 nop 8085366: 90 nop 8085367: 90 nop 08085368 <_Dmain>: 8085368: 55 push ebp 8085369: 8b ec mov ebp,esp 808536b: 6a 00 push 0x0 808536d: 6a 00 push 0x0 808536f: e8 d0 ff ff ff call 8085344 <_D4pest1bFlZl> 8085374: 52 push edx 8085375: 50 push eax 8085376: b8 84 67 0c 08 mov eax,0x80c6784 808537b: 6a 0a push 0xa 808537d: e8 22 00 00 00 call 80853a4 <_D3std5stdio4File14__T5writeTlTaZ5writeMFlaZv> 8085382: 31 c0 xor eax,eax 8085384: 5d pop ebp 8085385: c3 ret 8085386: 90 nop 8085387: 90 nop
Comment #8 by clugdbug — 2011-10-15T16:03:33Z
Here's what it does on 32-bit Windows. The commented line is where the difference is. mov ECX,8[ESP] mov EAX,4[ESP] test ECX,ECX jl Lsecond jg Lfirst test EAX,EAX jb Lsecond Lfirst: mov EAX,0xFFFFFFFF mov ECX,EAX // xor ECX, ECX on failing case Lsecond: mov EDX,ECX ret 8
Comment #9 by bugzilla — 2011-11-17T21:12:36Z
I can reproduce the problem on Linux.
Comment #10 by bugzilla — 2011-11-18T00:57:46Z
Comment #11 by code — 2011-11-18T08:32:03Z
*** Issue 6537 has been marked as a duplicate of this issue. ***