LLVM miscompiles dlls/user32/dialog.c from wine

[llvmbot]

Bugzilla Link	9704
Resolution	FIXED
Resolved on	Dec 17, 2012 17:08
Version	trunk
OS	Linux
Blocks	llvm/llvm-bugzilla-archive#10638
Reporter	LLVM Bugzilla Contributor

Extended Description

Part 2 of a long series filed on behalf of Austin English.

This miscompilation happens inside comdlg32, specifically in the Find/Replace dialog. The test (see http://bugs.winehq.org/show_bug.cgi?id=25824) hangs indefinitely. It only happens at -O2; -O0 is unaffected. -O1 has other problems. This should be unrelated to the integrated assembler.

[llvmbot]

For me in trunk, occurs at -O0 as well as -O2. If I recompile all of comdlg32 and comdlg32/tests with gcc, bug still occurs, so not sure what would be useful to debug this.

[llvmbot]

Found it, it's dlls/user32/dialog.c.

Fails with:
austin@aw21 ~/src/wine-clang/dlls/user32 $ clang --version
clang version 3.0 (trunk 131941)
Target: i386-pc-linux-gnu
Thread model: posix

works with:
austin@aw21 ~/src/wine-clang/dlls/user32 $ gcc --version
gcc (Gentoo 4.4.5 p1.2, pie-0.4.5) 4.4.5
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

I'll attach preprocessed files.

[llvmbot]

preprocessed C file
clang -E -I. -I. -I../../include -I../../include -D__WINESRC__ -D_USER32_ -D_WINABLE_ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body -Wstrict-prototypes -Wtype-limits -Wwrite-strings -Wpointer-arith -g -O0 dialog.c &> ~/clang_user32_dialog.i

[llvmbot]

preprocessed C file, using gcc
gcc -E -I. -I. -I../../include -I../../include -D__WINESRC__ -D_USER32_ -D_WINABLE_ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body -Wstrict-prototypes -Wtype-limits -Wwrite-strings -Wpointer-arith -g -O0 dialog.c &> ~/gcc_user32_dialog.i

[llvmbot]

FWIW, this doesn't occur when compiling Wine with dragonegg, so it's likely in clang specific code rather than in llvm.

[llvmbot]

Still present, as of
git-svn-id: http://llvm.org/svn/llvm-project/llvm/trunk@150433 91177308-0d34-0410-b5e6-96231b3b80d8

and wine-1.4-rc3-23-gd548af4

[llvmbot]

Works fine in wine-1.4 and current wine from git (wine-1.5.19-186-g1cd0c4a).

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@170295 91177308-0d3
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@170294 91177308-0d34