search for: miscompare

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 Time, on Monday 31aug) ... 80589 bootstrap miscompare (about one hour after 80586) ... 80610 abort()s while compiling libgcc (about two hours after 80589) ... 80717...

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) (ll...

...uart at apple.com> wrote: > 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 Time, on Monday 31aug) > ... > 80589   bootstrap miscompare (about one hour after 80586) > ... > 80610   abort()s while compiling libgcc...

...lease file a bug for the other one if you havent already. > > I haven't, will do tomorrow. Sorry for taking so long, I opened a PR for spiff, but its not a regression, see PR6785. To sum up: all tests (including native) run out of memory, llvm 2.6 had this problem too, but it didn't miscompare (it was all Out of memory). Now in 2.7 the JIT crashes when running out of memory. While that is a bug, I'm not sure if its part of the release criteria. I tried to make some changes in MallocSlabAllocator to not crash, but then FoldingSet crashed on OOM. P.S.: looking at the current 2.7 rele...

...d=15040#c4) With the updated trunk, clang still gives an error when FMA4 is enabled but does fine when -no-integrated-as is used. So that's a bug with LLVM's integrated assembler. On a related note, r173176 mentioned in http://llvm.org/bugs/show_bug.cgi?id=15282 does not fix the gromacs miscompare error either. However -no-integrated-as helps in all cases. I am not sure if r173176 is incomplete or the issue is something else. -Anitha > > On Mon, Mar 11, 2013 at 4:49 AM, Anitha B Gollamudi > <anitha.boyapati at gmail.com> wrote: >> >> On 11 March 2013 17:00,...

...trunk, clang still gives an error when FMA4 is > enabled but does fine when -no-integrated-as is used. So that's a bug > with LLVM's integrated assembler. > > On a related note, r173176 mentioned in > http://llvm.org/bugs/show_bug.cgi?id=15282 does not fix the gromacs > miscompare error either. However -no-integrated-as helps in all cases. > > I am not sure if r173176 is incomplete or the issue is something else. > > > > -Anitha > > > > > > On Mon, Mar 11, 2013 at 4:49 AM, Anitha B Gollamudi > > <anitha.boyapati at gmail.com>...

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.

...om> 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. Going by http://llvm.org/bugs/show_bug.cgi?id=14185#c12 , I am inclined to think that it is an optimization. (If it is an encoding issue, dragonegg would have failed as well...). or maybe I am missing something here. -Anitha > > It seems to be so! I will look into...

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/...

...anuary 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. > > Going by http://llvm.org/bugs/show_bug.cgi?id=14185#c12 , I am > inclined to think that it is an optimization. (If it is an encoding > issue, dragonegg would have failed as well...). or maybe I am missing > something here. > Ah, I am taking back my above words...

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