Dejagnu Tests

Hi,

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.

I will mail the summary once my current build is done.

Hi,

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.

I will mail the summary once my current build is done.

on most platforms all tests should pass (except for those marked XFAIL,
but these won't be reported as failures so no problem!). If you are
building using source from svn then you may see failures from time
to time, which is normal for code in development; these problems are
usually fixed swiftly.

Ciao,

Duncan.

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.

Thanks,
Tanya

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 :slight_smile:

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.

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

Ok, 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 :slight_smile:

Great!

-Chris

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.

If the output of llvm-dis is "0.0" instead of "-0.0", then that is a serious problem, and we need to fix the asmprinter to work around the different in system libraries.

The printing is happening in lib/VMCore/AsmWriter.cpp around line 483.

-Chris

Chris Lattner wrote:

If the output of llvm-dis is "0.0" instead of "-0.0", then that is a serious problem, and we need to fix the asmprinter to work around the different in system libraries.

Correct. This is the behavior we see.

For now wait to see what the OpenBSD dev's say.

Thread here: 'sprintf() and negative zero' - MARC

And yes, my test in the first message is b0rk3d :slight_smile: See the rest of the thread.

Edd Barrett wrote:

For now wait to see what the OpenBSD dev's say.

It looks like the OpenBSD team are planning to change their number handling in OpenBSD.

We have found that our build fails more tests if the optimiser is off. Whacky!

Details soon.

Hi,

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.

I will mail the summary once my current build is done.

As a part of my project I had to run the Dejagnu tests several time. FYI, my Dejagnu log says:

of expected passes 2568

of expected failures 7

-Rajika