search for: miscompares

The buildbots are unhappy again. :-( Specifically, the "llvm-gcc-i386-darwin9" buildbot here at Apple last compiled TOT successfully yesterday morning (31aug); that was revision 80586. By revision 80589, the bootstrap failed due to a miscompare, and by revision 80610, it's aborting while compiling little pieces of libgcc. 80586 built O.K. (about 8AM, Pacific Standard

Hi All, I am facing miscompare error when running povray (and few other C/C++ benchmarks) from spec cpu2006 suite enabling FMA4 (and disabling FMA3). I have used -ffp-contract=fast to turn on this option. (Compilation options and targets pasted below). >>>>>>>> clang version 3.2 (trunk 163295:163308) (llvm/trunk 163295) Target: x86_64-unknown-linux-gnu Thread model: posix

Yes, this is pretty unacceptable IMHO. I would go revert crazy if I knew what to hit, unfortunately I don't. Currently I believe there are two problems, a CallGraphSCC assert which is firing everywhere (including the clang test suite, *cough*). This started with 80698. Chris is working on this (if it isn't already fixed). The bootstrap comparison failures are being looked at by Devang.

On 03/30/2010 09:21 PM, Török Edwin wrote: > On 03/30/2010 09:15 PM, Tanya Lattner wrote: >> Thanks for testing the release! >> >>> Tests were run on x86-64, Debian unstable, Linux 2.6.33, gcc 4.4.3, >>> 64-bit. I built srcdir == objdir, I have built llvm and clang myself, >>> and used the binaries for llvm-gcc. >>> >>> 1. llvm-gcc 2.7 vs

On 12 March 2013 09:51, Craig Topper <craig.topper at gmail.com> wrote: > I'm still slightly confused. Is the error now fixed or is there still a bug > in LLVM's integrated assembler? > The error is not fixed yet (even with fix mentioned in PR15040 http://llvm.org/bugs/show_bug.cgi?id=15040#c4) With the updated trunk, clang still gives an error when FMA4 is enabled but

Can you send the binaries compiled with and without the integrated assembler. Maybe I can figure out the encoding problem. I've been unsuccessful figuring it out myself so far. On Tue, Mar 12, 2013 at 12:34 AM, Anitha B Gollamudi < anitha.boyapati at gmail.com> wrote: > On 12 March 2013 09:51, Craig Topper <craig.topper at gmail.com> wrote: > > I'm still slightly

I'm still slightly confused. Is the error now fixed or is there still a bug in LLVM's integrated assembler? On Mon, Mar 11, 2013 at 4:49 AM, Anitha B Gollamudi < anitha.boyapati at gmail.com> wrote: > On 11 March 2013 17:00, Duncan Sands <baldrick at free.fr> wrote: > > Hi Anitha, > > > > > >> Ah, I am taking back my above words w.r.t encoding.

On 11 March 2013 10:06, Anitha B Gollamudi <anitha.boyapati at gmail.com> wrote: > On 23 January 2013 00:20, Craig Topper <craig.topper at gmail.com> wrote: >> >> Are you still having issues with FMA4? I wonder if PR15040 is related. A >> fix was just committed. Unfortunately r173176 does not fix this. I have updated the trunk and ran...Miscompare still persists.

On 03/30/2010 09:15 PM, Tanya Lattner wrote: > > Thanks for testing the release! > >> Tests were run on x86-64, Debian unstable, Linux 2.6.33, gcc 4.4.3, >> 64-bit. I built srcdir == objdir, I have built llvm and clang myself, >> and used the binaries for llvm-gcc. >> >> 1. llvm-gcc 2.7 vs 2.6 >> compared to my results from Aug 31 2009, ignoring CBE

...:~/slave/recurse3be/build$ find . -name "*.o" -exec cmp '{}' ../../recurse2be/build/'{}' \; |& tee foo.txt Is anyone else doing this? There 2 compilers, recurse 2 and recurse3 that in principle should be identical. Obviously if there is date and time information, miscompares can occur. -------------- next part -------------- ./tools/clang/lib/AST/Release+Asserts/ASTDumper.o ../../recurse2be/build/./tools/clang/lib/AST/Release+Asserts/ASTDumper.o differ: byte 181746, line 385 ./tools/clang/lib/AST/Release+Asserts/AttrImpl.o ../../recurse2be/build/./tools/clang/lib/AST/R...

On 11 March 2013 16:13, Anitha B Gollamudi <anitha.boyapati at gmail.com> wrote: > On 11 March 2013 10:06, Anitha B Gollamudi <anitha.boyapati at gmail.com> wrote: >> On 23 January 2013 00:20, Craig Topper <craig.topper at gmail.com> wrote: >>> >>> Are you still having issues with FMA4? I wonder if PR15040 is related. A >>> fix was just

Hi, The 7.0.1-rc2 release has been tagged and is ready for testing. I forgot to bump the version number to 7.0.1 before I tagged -rc1, which is why we are now on -rc2. Remember, you can continue to submit merge requests up until Nov, 21, so keep testing and submitting fixes. Thanks, Tom

Are you still having issues with FMA4? I wonder if PR15040 is related. A fix was just committed. On Wed, Nov 7, 2012 at 3:22 AM, Anitha Boyapati <anitha.boyapati at gmail.com>wrote: > > > On 7 November 2012 15:29, Duncan Sands <baldrick at free.fr> wrote: > >> >> That way the output should be exactly the same as the output dragonegg >> would >>

On 23 January 2013 00:20, Craig Topper <craig.topper at gmail.com> wrote: > > Are you still having issues with FMA4? I wonder if PR15040 is related. A > fix was just committed. It seems to be so! I will look into it immediately. Apologies for the late e-mail. I ran out of time devoted for this PR and moved on. Coincidentally, only today I came back to this PR for further

Hello, I am trying to bootstrap on ARM linux EABI using a qemu chroot to better test my changes on at least one more architecture. I am using the following configure line: ../gcc/configure --prefix=/home/espindola/install/ --program-prefix=llvm- --enable-languages=c --disable-shared --disable-multilib --enable-llvm=/home/espindola/build --enable-checking arm-linux-gnueabi The bootstrap fails

On Apr 27, 2007, at 3:50 PM, David Greene wrote: > The saga continues. > > I've been tracking the interface changes and merging them with > the refactoring work I'm doing. I got as far as building stage3 > of llvm-gcc but the object files from stage2 and stage3 differ: > > > warning: ./cc1-checksum.o differs > warning: ./cc1plus-checksum.o differs > >

Folks, I've been asking around people about the state of FP contract, which seems to be "on" but it's not really behaving like it, at least not as I would expect: int foo(float a, float b, float c) { return a*b+c; } $ clang -target aarch64-linux-gnu -O2 -S fma.c -ffp-contract=on -o - (...) fmul s0, s0, s1 fadd s0, s0, s2 (...) $ clang -target aarch64-linux-gnu -O2 -S fma.c

The saga continues. I've been tracking the interface changes and merging them with the refactoring work I'm doing. I got as far as building stage3 of llvm-gcc but the object files from stage2 and stage3 differ: warning: ./cc1-checksum.o differs warning: ./cc1plus-checksum.o differs (Are the above two ok?) The list below is clearly bad. I think it's every object file in the