For the heck of it I tried upgrading to gcc 3.4.2 (from 3.3.3). It
didn't make a difference. So here are the failures for llvm-test. All
diffs are against the "native" output.
cbe failed differently from jit/llc. First cbe:
< One-Norm(A) ---------- 8.879153e+02.
> One-Norm(A) ---------- 8.879156e+02.
< One-Norm(A) ---------- 5.000000e+35.
> One-Norm(A) ---------- 5.000005e+35.
> Zero Column 200 found
sgefa is a known XFAIL. See the nightly test results over the last
several months. Actually, you should compare your test results with the
1.3 release test results (on or about August 13th, 2004). Please only
report deltas from there.
Only llc failed. Instead of producing 13,000+ lines of parsing actions,
it produces the following two lines:
Reading input files ...kc++: segmentation violation
kc.llc: received signal 11, cleaning up
Not sure what's up with this. This test doesn't appear on the nightly
tester although it *should*.
Only cbe failed:
< TR=0.81, TI=0.16, P0=6397.86, Q0=1288.50
> TR=0.81, TI=0.16, P0=6397.87, Q0=1288.50
< TR=0.80, TI=0.16, P0=7565.44, Q0=1525.86
> TR=0.80, TI=0.16, P0=7565.44, Q0=1525.85
< TR=0.79, TI=0.16, P0=7725.99, Q0=1558.54
> TR=0.79, TI=0.16, P0=7725.99, Q0=1558.53
< TR=0.79, TI=0.16, P0=8052.56, Q0=1625.04
> TR=0.79, TI=0.16, P0=8052.56, Q0=1625.05
< TR=0.79, TI=0.16, P0=7894.33, Q0=1592.81
> TR=0.79, TI=0.16, P0=7894.32, Q0=1592.81
This works on Linux (it did last night) so not sure why FreeBSD gives
these rounding errors. Can you investigate? Does the test use fpcmp?
This test continues to be non-deterministic. Sample of partial diff:
Not sure what's up with this one.
All fail (including native) with error "Could not open datafile test.in"
When's the last time you cvs updated llvm-test, wiped out your build
directory, reconfigured, and rebuilt? There have been numerous
structural changes to llvm-test in the last week. It seems to have
settled down now and the above error is indicative of at least one of
the changes that fixed problems.
None of cbe/jit/llc passed. gccld core dumped:
This is a known XFAIL.
All of cbe/jit/llc failed with:
> Destroying C object in foo
Again, a known XFAIL.
Only cbe failed with:
gcc Output/ConditionalExpr.cbe.c -std=c99 -fno-strict-aliasing -O2 -o Output/ConditionalExpr.cbe
Output/ConditionalExpr.cbe.c:1629: warning: conflicting types for built-in function 'memset'
Output/ConditionalExpr.cbe.c: In function `l141__ZNKSt7collateIwE12do_transformEPKwS2_':
Output/ConditionalExpr.cbe.c:29424: warning: implicit declaration of function `alloca'
/var/tmp//cc7mQbke.o: In function `l292__ZNKSt8time_getIwSt19istreambuf_iteratorIwSt11char_traitsIwEEE15_M_extract_nameERS3_S5_RiPPKwjRSt12_Ios_Iostate':
/var/tmp//cc7mQbke.o(.text+0x122e3): undefined reference to `alloca'
/var/tmp//cc7mQbke.o: In function `l164__ZNKSt8time_putIwSt19ostreambuf_iteratorIwSt11char_traitsIwEEE6do_putES3_RSt8ios_basewPK2tmcc':
/var/tmp//cc7mQbke.o(.text+0x139aa): undefined reference to `alloca'
/var/tmp//cc7mQbke.o: In function `l311__ZNSt5__padIwSt11char_traitsIwEE6_S_padERSt8ios_basewPwPKwiib':
/var/tmp//cc7mQbke.o(.text+0x14db8): undefined reference to `alloca'
/var/tmp//cc7mQbke.o: In function `l195__ZNKSt9money_putIwSt19ostreambuf_iteratorIwSt11char_traitsIwEEE6do_putES3_bRSt8ios_basewe':
/var/tmp//cc7mQbke.o(.text+0x15180): undefined reference to `alloca'
/var/tmp//cc7mQbke.o(.text+0x153a5): undefined reference to `alloca'
/var/tmp//cc7mQbke.o(.text+0x15580): more undefined references to `alloca' follow
collect2: ld returned 1 exit status
gmake: [Output/ConditionalExpr.cbe] Error 1 (ignored)
You need to look into this. Why isn't alloca being linked in? Where is
it on FreeBSD? This comment goes for all the other C++/EH tests that
failed for "No alloca".
/usr/include/machine/endian.h: In function `__uint32_t __bswap32(__uint32_t)':
/usr/include/machine/endian.h:156: error: LLVM does not yet support inline assembly! Code: 'xchgb %h0, %b0
rorl $16, %0
xchgb %h0, %b0'
gmake: [Output/echo.ll] Error 1 (ignored)
I guess I have to place a modified version of this header file in sys-include.
All of cbe/jit/llc fail with:
< x = 0.150572 y = 0.49 low = 31314973 j = 40000001
> x = 0.150572 y = 0.49 low = 31314970 j = 40000001
Hmm. Not sure what's up with that but Linux passes this one.