Hi, Tanya M. Lattner wrote:>> We were wondering if *all* of the dejagnu tests should pass (in the >> sense that no result should be unexpected), because we have a few failed >> tests on our build. > > make check should always be clean. However, sometimes people do commit > changes that impact platforms they are not able to test on and we do have > the occasional failure. > > If you have failures, please file a bug with the test case that is > failing, the command that fails, and the bc file if applicable. Basically, > as much information as you can provide since it may not be a target that > the majority of the developers have access to.The target is OpenBSD/i386 for now and later sparc64 and amd64. Most of the errors are to do with GNU grep syntax not being compatible with BSD grep. I would not be suprised if solaris and FreeBSD were impacted by this too. The solution is to use egrep we *think*. There are a couple we are scratching our head on. One being the negative zero test. It seems the display function in llvm-dis (probably printf) is truncating the minus sign from the output deeming it pointless in the case of zero, whereas on a linux box it does not. Not sure quite what to do there yet, as -0 == 0 mathematically, but not in floating point representation. There were some others too, but off of the top of my head I cant remember. We should be able to send you guys a bunch of patches for testing soon. I think we are down to 6 failed tests now. The build itself is now reliable on OpenBSD/i386 after patching tablegen :)
On Jul 1, 2008, at 10:11 AMPDT, Edd Barrett wrote:> Hi, > > Tanya M. Lattner wrote: >>> We were wondering if *all* of the dejagnu tests should pass (in the >>> sense that no result should be unexpected), because we have a few >>> failed >>> tests on our build. >> >> make check should always be clean. However, sometimes people do >> commit >> changes that impact platforms they are not able to test on and we >> do have >> the occasional failure. >> >> If you have failures, please file a bug with the test case that is >> failing, the command that fails, and the bc file if applicable. >> Basically, >> as much information as you can provide since it may not be a target >> that >> the majority of the developers have access to. > > The target is OpenBSD/i386 for now and later sparc64 and amd64. Most > of > the errors are to do with GNU grep syntax not being compatible with > BSD > grep. I would not be suprised if solaris and FreeBSD were impacted by > this too. The solution is to use egrep we *think*. > > There are a couple we are scratching our head on. One being the > negative > zero test. It seems the display function in llvm-dis (probably printf) > is truncating the minus sign from the output deeming it pointless in > the > case of zero, whereas on a linux box it does not. Not sure quite > what to > do there yet, as -0 == 0 mathematically, but not in floating point > representation.The conversion is done by ftostr which uses sprintf("%20.6e"). We may need to special-case negative zero there.> There were some others too, but off of the top of my head I cant > remember. > > We should be able to send you guys a bunch of patches for testing > soon. > I think we are down to 6 failed tests now. > > The build itself is now reliable on OpenBSD/i386 after patching > tablegen :) > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
On Jul 1, 2008, at 10:34 AMPDT, Dale Johannesen wrote:> > On Jul 1, 2008, at 10:11 AMPDT, Edd Barrett wrote: > >> Hi, >> >> Tanya M. Lattner wrote: >>>> We were wondering if *all* of the dejagnu tests should pass (in the >>>> sense that no result should be unexpected), because we have a few >>>> failed >>>> tests on our build. >>> >>> make check should always be clean. However, sometimes people do >>> commit >>> changes that impact platforms they are not able to test on and we >>> do have >>> the occasional failure. >>> >>> If you have failures, please file a bug with the test case that is >>> failing, the command that fails, and the bc file if applicable. >>> Basically, >>> as much information as you can provide since it may not be a >>> target that >>> the majority of the developers have access to. >> >> The target is OpenBSD/i386 for now and later sparc64 and amd64. >> Most of >> the errors are to do with GNU grep syntax not being compatible with >> BSD >> grep. I would not be suprised if solaris and FreeBSD were impacted by >> this too. The solution is to use egrep we *think*. >> >> There are a couple we are scratching our head on. One being the >> negative >> zero test. It seems the display function in llvm-dis (probably >> printf) >> is truncating the minus sign from the output deeming it pointless >> in the >> case of zero, whereas on a linux box it does not. Not sure quite >> what to >> do there yet, as -0 == 0 mathematically, but not in floating point >> representation. > > The conversion is done by ftostr which uses sprintf("%20.6e"). > We may need to special-case negative zero there.Incidentally, C99 requires the leading - to be emitted for negative zero (7.19.6.1, footnote 233 is explicit). If it's feasible to fix this in sprintf that would be better IMO.
On Tue, 1 Jul 2008, Edd Barrett wrote:>> as much information as you can provide since it may not be a target that >> the majority of the developers have access to. > > The target is OpenBSD/i386 for now and later sparc64 and amd64. Most ofOk, that sounds like we need to increase testsuite portability.> the errors are to do with GNU grep syntax not being compatible with BSD > grep. I would not be suprised if solaris and FreeBSD were impacted by > this too. The solution is to use egrep we *think*.Interesting, ok!> There are a couple we are scratching our head on. One being the negative > zero test. It seems the display function in llvm-dis (probably printf) > is truncating the minus sign from the output deeming it pointless in the > case of zero, whereas on a linux box it does not. Not sure quite what to > do there yet, as -0 == 0 mathematically, but not in floating point > representation.Specifically which test is this? It is possible we can just change the test to not depend on this.> We should be able to send you guys a bunch of patches for testing soon. > I think we are down to 6 failed tests now. > The build itself is now reliable on OpenBSD/i386 after patching tablegen :)Great! -Chris -- http://nondot.org/sabre/ http://llvm.org/
Chris Lattner wrote:> Specifically which test is this? It is possible we can just change the > test to not depend on this.Assembler/2004-02-01-NegativeZero.ll ; RUN: llvm-as < %s | llvm-dis | grep -- -0.0 global double 0x8000000000000000 global float -0.0 The .bc made by both Linux and OpenBSD is identical according to an md5 hash.