Hi, I am currently making the transition from gcc 4.2 to clang for the projects (mostly C++) I am working on. I think I discovered a major optimization bug in Clang++. I managed to create a simple (60 lines of code) test case which exhibits the issue. When you compile this file for i386 with optimizations turned on (O2, O3 or Os), you get an unexpected result. When you compile it for x86_64, or for i386 with optimizations turned off (O0 or O1), you get the expected behavior. I can reproduce this issue with Clang shipping in Xcode 4.2 GM as well as the Clang binaries from LLVM 2.9 (http://llvm.org/releases/download.html#svn). The tests were made on a Mac running 10.7.1. Here is what you see if you compile the example with O2: $ /Developer/usr/bin/clang++ -arch i386 -o testLLVM testLLVM.cp -O2 $ ./testLLVM Unexpected Value: 3222105416 (at index: 2) Expected Value: 3 (at index: 2) I haven't found any bugs similar in the LLVM bug database. It is a known issue? This looks like a major optimization issue which causes us to not be able to use Clang for our products. Thanks, Alexandre -------------- next part -------------- A non-text attachment was scrubbed... Name: testLLVM.cp Type: application/octet-stream Size: 2067 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20111010/dbe4ed9a/attachment.obj>
Hi Alexandre,> I am currently making the transition from gcc 4.2 to clang for the projects (mostly C++) I am working on. > I think I discovered a major optimization bug in Clang++. I managed to create a simple (60 lines of code) test case which exhibits the issue. > > When you compile this file for i386 with optimizations turned on (O2, O3 or Os), you get an unexpected result. When you compile it for x86_64, or for i386 with optimizations turned off (O0 or O1), you get the expected behavior. I can reproduce this issue with Clang shipping in Xcode 4.2 GM as well as the Clang binaries from LLVM 2.9 (http://llvm.org/releases/download.html#svn). The tests were made on a Mac running 10.7.1.try compiling with -m32. I suspect -arch doesn't mean what you think it means. Ciao, Duncan. PS: I can't reproduce on a real 32 bit machine.> > Here is what you see if you compile the example with O2: > > $ /Developer/usr/bin/clang++ -arch i386 -o testLLVM testLLVM.cp -O2 > $ ./testLLVM > Unexpected Value: 3222105416 (at index: 2) > Expected Value: 3 (at index: 2) > > > I haven't found any bugs similar in the LLVM bug database. It is a known issue? This looks like a major optimization issue which causes us to not be able to use Clang for our products. > > Thanks, > Alexandre > > > > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
On 10.10.2011, at 16:10, Alexandre Colucci wrote:> Hi, > > I am currently making the transition from gcc 4.2 to clang for the projects (mostly C++) I am working on. > I think I discovered a major optimization bug in Clang++. I managed to create a simple (60 lines of code) test case which exhibits the issue. > > When you compile this file for i386 with optimizations turned on (O2, O3 or Os), you get an unexpected result. When you compile it for x86_64, or for i386 with optimizations turned off (O0 or O1), you get the expected behavior. I can reproduce this issue with Clang shipping in Xcode 4.2 GM as well as the Clang binaries from LLVM 2.9 (http://llvm.org/releases/download.html#svn). The tests were made on a Mac running 10.7.1. > > Here is what you see if you compile the example with O2: > > $ /Developer/usr/bin/clang++ -arch i386 -o testLLVM testLLVM.cp -O2 > $ ./testLLVM > Unexpected Value: 3222105416 (at index: 2) > Expected Value: 3 (at index: 2) > > > I haven't found any bugs similar in the LLVM bug database. It is a known issue? This looks like a major optimization issue which causes us to not be able to use Clang for our products.I can reproduce your problem with the version of clang that ships with xcode 4.2gm but I can't reproduce it with clang trunk. The bug was probably fixed in the meantime. - Ben
The issue appears indeed to be fixed in clang trunk. Hopefully Apple will include the fix in Xcode 4.2 final or will provide soon a Xcode 4.2.1 beta. Right now Xcode 4.2 GM (October 4, 2011) is simply unusable for compiling C++ for i386. Thanks, Alexandre> > On 10.10.2011, at 16:10, Alexandre Colucci wrote: > >> Hi, >> >> I am currently making the transition from gcc 4.2 to clang for the projects (mostly C++) I am working on. >> I think I discovered a major optimization bug in Clang++. I managed to create a simple (60 lines of code) test case which exhibits the issue. >> >> When you compile this file for i386 with optimizations turned on (O2, O3 or Os), you get an unexpected result. When you compile it for x86_64, or for i386 with optimizations turned off (O0 or O1), you get the expected behavior. I can reproduce this issue with Clang shipping in Xcode 4.2 GM as well as the Clang binaries from LLVM 2.9 (http://llvm.org/releases/download.html#svn). The tests were made on a Mac running 10.7.1. >> >> Here is what you see if you compile the example with O2: >> >> $ /Developer/usr/bin/clang++ -arch i386 -o testLLVM testLLVM.cp -O2 >> $ ./testLLVM >> Unexpected Value: 3222105416 (at index: 2) >> Expected Value: 3 (at index: 2) >> >> >> I haven't found any bugs similar in the LLVM bug database. It is a known issue? This looks like a major optimization issue which causes us to not be able to use Clang for our products. > > I can reproduce your problem with the version of clang that ships with xcode 4.2gm but I can't reproduce it with clang trunk. The bug was probably fixed in the meantime. > > - Ben > >
Maybe Matching Threads
- [LLVMdev] Major i386 optimization bug in Clang++?
- [LLVMdev] Use of 'ldrd' instructions with unaligned addresses on armv7 (Major bug in LLVM optimizer?)
- [LLVMdev] Use of 'ldrd' instructions with unaligned addresses on armv7 (Major bug in LLVM optimizer?)
- [LLVMdev] Use of 'ldrd' instructions with unaligned addresses on armv7 (Major bug in LLVM optimizer?)
- [LLVMdev] gcc 4.2 to llvm-gcc 4.2 transition