A quick update on FreeBSD support

All,

So far I've tried LLVM on amd64, i386, ia64 and powerpc under FreeBSD
and aside for ia64, things look pretty good for a first try. There
are 2 unexpected failures for PowerPC, which appear to be caused by
uninitialized memory. I'm still working on a fix for that (need to
brush up on my C++ skills).

[sidenote: In FreeBSD -current, the memory allocator initializes
  memory with 0xa5 to expose problems where allocated memory is not
  properly initialized. This is disabled on the release branch. As
  such, a stable version of FreeBSD (i.e. any release) may not have
  the 2 unexpected failures]

Results are:
  amd64 & i386:
  # of expected passes 2463
  # of expected failures 6

  ia64:
  # of expected passes 2440
  # of unexpected failures 21
  # of expected failures 7

  powerpc:
  # of expected passes 2461
  # of unexpected failures 2
  # of expected failures 6

My current plan is as follows:
o Resolve powerpc failures to bring it in line with amd64 & i386.
o Adding support for inline assembly for ia64 (already started) and
    improving ia64 in general. This is longer term work...
o Add ARM and sparc64 to the mix (and MIPS when I have the hardware).
o Extend the testing to include:
    - the testsuite,
    - the complete FreeBSD source tree (kernel + userland)
    - the FreeBSD ports collection (~20000 software projects),
       including biggies like X11, KDE, OpenOffice, Java...

The end-result of this exercise hopefully a compiler that can
replace GCC as the "system" compiler. Your comments and/or
suggestions are always welcome...

FYI,

All,

So far I've tried LLVM on amd64, i386, ia64 and powerpc under FreeBSD
and aside for ia64, things look pretty good for a first try. There
are 2 unexpected failures for PowerPC, which appear to be caused by
uninitialized memory. I'm still working on a fix for that (need to
brush up on my C++ skills).

[sidenote: In FreeBSD -current, the memory allocator initializes
memory with 0xa5 to expose problems where allocated memory is not
properly initialized. This is disabled on the release branch. As
such, a stable version of FreeBSD (i.e. any release) may not have
the 2 unexpected failures]

Hi Marcel,

Let us know if you would like extra eyes on the two PPC failures. Many of us have a lot of experience with C++. :slight_smile: Do you know where these allocations are?

Results are:
  amd64 & i386:
  # of expected passes 2463
  # of expected failures 6

  ia64:
  # of expected passes 2440
  # of unexpected failures 21
  # of expected failures 7

  powerpc:
  # of expected passes 2461
  # of unexpected failures 2
  # of expected failures 6

My current plan is as follows:
o Resolve powerpc failures to bring it in line with amd64 & i386.
o Adding support for inline assembly for ia64 (already started) and
   improving ia64 in general. This is longer term work...

Is the lack of inline assembly the cause of the 21 regressions on ia64? Or is it something more systemic?

o Add ARM and sparc64 to the mix (and MIPS when I have the hardware).
o Extend the testing to include:
   - the testsuite,
   - the complete FreeBSD source tree (kernel + userland)
   - the FreeBSD ports collection (~20000 software projects),
      including biggies like X11, KDE, OpenOffice, Java...

The end-result of this exercise hopefully a compiler that can
replace GCC as the "system" compiler. Your comments and/or
suggestions are always welcome...

This is great work! Thank you!

-bw

Let us know if you would like extra eyes on the two PPC failures. Many
of us have a lot of experience with C++. :slight_smile: Do you know where these
allocations are?

I don't mind if people help out, so here's some information:

FAIL: /nfs/llvm/src/llvm/test/Transforms/PredicateSimplifier/2006-11-04-ReplacingZeros.ll
Failed with signal(SIGABRT) at line 1
while running: llvm-as < /nfs/llvm/src/llvm/test/Transforms/PredicateSimplifier/2006-11-04-ReplacingZeros.ll | opt -predsimplify -disable-output
Assertion failed: (validPredicate(R) && "Invalid predicate."), function update, file /nfs/llvm/src/llvm/lib/Transforms/Scalar/PredicateSimplifier.cpp, line 702.

xserve% Debug/bin/llvm-as < /nfs/llvm/src/llvm/test/Transforms/PredicateSimplifier/2006-11-04-ReplacingZeros.ll > x.bc

xserve% gdb Debug/bin/opt
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "powerpc-marcel-freebsd"...
(gdb) set args -predsimplify -disable-output < x.bc
(gdb) run
Starting program: /nfs/llvm/obj/powerpc/Debug/bin/opt -predsimplify -disable-output < x.bc
[New LWP 100048]
[New Thread 0x2002040 (LWP 100048)]
Assertion failed: (validPredicate(R) && "Invalid predicate."), function update, file /nfs/llvm/src/llvm/lib/Transforms/Scalar/PredicateSimplifier.cpp, line 702.

Program received signal SIGABRT, Aborted.
[Switching to Thread 0x2002040 (LWP 100048)]
0x2229ce08 in kill () from /lib/libc.so.7
(gdb) bt
#0 0x2229ce08 in kill () from /lib/libc.so.7
#1 0x22000848 in raise () from /lib/libthr.so.3
#2 0x2229b6a4 in abort () from /lib/libc.so.7
#3 0x22281d80 in __assert () from /lib/libc.so.7
#4 0x01c34a78 in update (this=0x200c940, n=1515870810, R=1515870810, Subtree=0x20298c0) at /nfs/llvm/src/llvm/lib/Transforms/Scalar/PredicateSimplifier.cpp:702
#5 0x01c3d134 in makeEqual (this=0x7fffd550, V1=0x2009730, V2=0x2006624) at /nfs/llvm/src/llvm/lib/Transforms/Scalar/PredicateSimplifier.cpp:1614
#6 0x01c3db18 in solve (this=0x7fffd550) at /nfs/llvm/src/llvm/lib/Transforms/Scalar/PredicateSimplifier.cpp:2151
#7 0x01c3f95c in visitBranchInst (this=0x7fffd648, BI=@0x2006714) at /nfs/llvm/src/llvm/lib/Transforms/Scalar/PredicateSimplifier.cpp:2447
#8 0x01c3fb90 in visitBr (this=0x7fffd648, I=@0x2006714) at Instruction.def:98
#9 0x01c40038 in visit (this=0x7fffd648, I=@0x2006714) at Instruction.def:98
#10 0x01c40aa8 in visitInstruction (this=0x2006790, I=0x2006714, DT=0x2029800) at /nfs/llvm/src/llvm/lib/Transforms/Scalar/PredicateSimplifier.cpp:2376
#11 0x01c40c48 in visitBasicBlock (this=0x2006790, Node=0x2029800) at /nfs/llvm/src/llvm/lib/Transforms/Scalar/PredicateSimplifier.cpp:2320
#12 0x01c410b8 in runOnFunction (this=0x2006790, F=@0x2006510) at /nfs/llvm/src/llvm/lib/Transforms/Scalar/PredicateSimplifier.cpp:2398
#13 0x01e84760 in llvm::FPPassManager::runOnFunction (this=0x2021080, F=@0x2006510) at /nfs/llvm/src/llvm/lib/VMCore/PassManager.cpp:1178
#14 0x01e84998 in llvm::FPPassManager::runOnModule (this=0x2021080, M=@0x20093a0) at /nfs/llvm/src/llvm/lib/VMCore/PassManager.cpp:1198
#15 0x01e84218 in llvm::MPPassManager::runOnModule (this=0x202c110, M=@0x20093a0) at /nfs/llvm/src/llvm/lib/VMCore/PassManager.cpp:1248
#16 0x01e84474 in llvm::PassManagerImpl::run (this=0x201d100, M=@0x20093a0) at /nfs/llvm/src/llvm/lib/VMCore/PassManager.cpp:1322
#17 0x01e84534 in llvm::PassManager::run (this=0x7fffdb10, M=@0x20093a0) at /nfs/llvm/src/llvm/lib/VMCore/PassManager.cpp:1354
#18 0x01a70774 in main (argc=3, argv=0x7fffdbc4) at /nfs/llvm/src/llvm/tools/opt/opt.cpp:431
(gdb) frame 5
#5 0x01c3d134 in makeEqual (this=0x7fffd550, V1=0x2009730, V2=0x2006624) at /nfs/llvm/src/llvm/lib/Transforms/Scalar/PredicateSimplifier.cpp:1614
1614 IG.node(n1)->update(NI->To, NI->LV, Top);
(gdb) p NI
$1 = ((anonymous namespace)::InequalityGraph::Edge *) 0x2036390
(gdb) p /x *NI
$2 = {To = 0x5a5a5a5a, LV = 0x5a5a5a5a, Subtree = 0x5a5a5a5a}
(gdb) p NE
$3 = ((anonymous namespace)::InequalityGraph::Edge *) 0x203639c
(gdb) p /x *NE
$4 = {To = 0x5a5a5a5a, LV = 0x5a5a5a5a, Subtree = 0x5a5a5a5a}

Both NI and NE are defined by the for loop:

1603 for (Node::iterator NI = IG.node(n)->begin(), NE = IG.node(n)->end();
1604 NI != NE; ++NI) {

In this case:

(gdb) p n
$5 = 4
(gdb) p IG.node(n)->begin()
$12 = ((anonymous namespace)::InequalityGraph::Edge *) 0x1f59378
(gdb) p IG.node(n)->end()
$14 = ((anonymous namespace)::InequalityGraph::Edge *) 0xa5a5a5a5

My current plan is as follows:
o Resolve powerpc failures to bring it in line with amd64 & i386.
o Adding support for inline assembly for ia64 (already started) and
  improving ia64 in general. This is longer term work...

Is the lack of inline assembly the cause of the 21 regressions on
ia64? Or is it something more systemic?

No, not entirely. I added some debug printf's and I see them
pop up in the output, but there are more failures:

FAIL: /dumpster/home/marcel/LLVM/src/llvm/test/CodeGen/Generic/GC/frame_size.ll
Failed with exit(1) at line 1
while running: llvm-as < /dumpster/home/marcel/LLVM/src/llvm/test/CodeGen/Generic/GC/frame_size.ll | llc -asm-verbose | grep {frame size} | grep -v 0x0
Assertion failed: (ResNo < NumValues && "Illegal result number!"), function getValueType, file /dumpster/home/marcel/LLVM/src/llvm/include/llvm/CodeGen/SelectionDAGNodes.h, line 1220.

FAIL: /dumpster/home/marcel/LLVM/src/llvm/test/CodeGen/Generic/2003-05-27-phifcmpd.ll
Failed with signal(SIGABRT) at line 1
while running: llvm-as < /dumpster/home/marcel/LLVM/src/llvm/test/CodeGen/Generic/2003-05-27-phifcmpd.ll | llc

.ident "LLVM-ia64"

  .psr lsb
  .radix C
  .psr abi64
Cannot yet select: 0x2000000001d76120: i1 = setcc 0x2000000001d46520, 0x2000000001d48240, 0x2000000001d08fe0

FAIL: /dumpster/home/marcel/LLVM/src/llvm/test/CodeGen/Generic/2003-05-27-useboolinotherbb.ll
Failed with signal(SIGABRT) at line 1
while running: llvm-as < /dumpster/home/marcel/LLVM/src/llvm/test/CodeGen/Generic/2003-05-27-useboolinotherbb.ll | llc

.ident "LLVM-ia64"

  .psr lsb
  .radix C
  .psr abi64
Cannot yet select: 0x2000000001d76120: i1 = setcc 0x2000000001d463e0, 0x2000000001d341d0, 0x2000000001d08f20

FAIL: /dumpster/home/marcel/LLVM/src/llvm/test/CodeGen/Generic/2003-05-27-usefsubasbool.ll
Failed with signal(SIGABRT) at line 1
while running: llvm-as < /dumpster/home/marcel/LLVM/src/llvm/test/CodeGen/Generic/2003-05-27-usefsubasbool.ll | llc

.ident "LLVM-ia64"

  .psr lsb
  .radix C
  .psr abi64
Cannot yet select: 0x2000000001d76120: i1 = setcc 0x2000000001d463e0, 0x2000000001d341d0, 0x2000000001d08f20

FAIL: /dumpster/home/marcel/LLVM/src/llvm/test/CodeGen/Generic/2005-10-21-longlonggtu.ll
Failed with signal(SIGABRT) at line 1
while running: llvm-as < /dumpster/home/marcel/LLVM/src/llvm/test/CodeGen/Generic/2005-10-21-longlonggtu.ll | llc

.ident "LLVM-ia64"

  .psr lsb
  .radix C
  .psr abi64
Assertion failed: (MVT::isInteger(VT) && MVT::isInteger(Operand.getValueType()) && "Invalid TRUNCATE!"), function getNode, file /dumpster/home/marcel/LLVM/src/llvm/lib/CodeGen/SelectionDAG/SelectionDAG.cpp, line 2011.

FAIL: /dumpster/home/marcel/LLVM/src/llvm/test/CodeGen/Generic/2006-04-28-Sign-extend-bool.ll
Failed with signal(SIGABRT) at line 1
while running: llvm-as < /dumpster/home/marcel/LLVM/src/llvm/test/CodeGen/Generic/2006-04-28-Sign-extend-bool.ll | llc

.ident "LLVM-ia64"

  .psr lsb
  .radix C
  .psr abi64
Cannot yet select: 0x2000000001d523e0: i64 = sign_extend_inreg 0x2000000001d52340, 0x2000000001d08f80

FAIL: /dumpster/home/marcel/LLVM/src/llvm/test/CodeGen/Generic/2007-04-08-MultipleFrameIndices.ll for PR1308,1557
Failed with signal(SIGABRT) at line 1
while running: llvm-as < /dumpster/home/marcel/LLVM/src/llvm/test/CodeGen/Generic/2007-04-08-MultipleFrameIndices.ll | llc

.ident "LLVM-ia64"

  .psr lsb
  .radix C
  .psr abi64
NODE: 0x2000000001d09460: i32 = TargetConstant <1>
Assertion failed: (0 && "Do not know how to promote this operator!"), function PromoteOp, file /dumpster/home/marcel/LLVM/src/llvm/lib/CodeGen/SelectionDAG/LegalizeDAG.cpp, line 4089.

FAIL: /dumpster/home/marcel/LLVM/src/llvm/test/CodeGen/Generic/2007-04-27-LargeMemObject.ll for PR1557
Failed with exit(1) at line 1
while running: llvm-as < /dumpster/home/marcel/LLVM/src/llvm/test/CodeGen/Generic/2007-04-27-LargeMemObject.ll | llc

.ident "LLVM-ia64"

  .psr lsb
  .radix C
  .psr abi64
XXX: getRegForInlineAsmConstraint
XXX: getRegClassForInlineAsmConstraint
XXX: getRegForInlineAsmConstraint
XXX: getRegClassForInlineAsmConstraint
XXX: getRegForInlineAsmConstraint
XXX: getRegClassForInlineAsmConstraint
XXX: getRegForInlineAsmConstraint
XXX: getRegClassForInlineAsmConstraint
XXX: getRegForInlineAsmConstraint
XXX: getRegClassForInlineAsmConstraint
XXX: getRegForInlineAsmConstraint
XXX: getRegClassForInlineAsmConstraint
Could not match memory address. Inline asm failure!

FAIL: /dumpster/home/marcel/LLVM/src/llvm/test/CodeGen/Generic/2008-02-20-MatchingMem.ll for PR1133
Failed with exit(1) at line 1
while running: llvm-as < /dumpster/home/marcel/LLVM/src/llvm/test/CodeGen/Generic/2008-02-20-MatchingMem.ll | llc

.ident "LLVM-ia64"

  .psr lsb
  .radix C
  .psr abi64
XXX: getRegForInlineAsmConstraint
XXX: getRegClassForInlineAsmConstraint
Could not match memory address. Inline asm failure!

FAIL: /dumpster/home/marcel/LLVM/src/llvm/test/CodeGen/Generic/i128-addsub.ll
Failed with signal(SIGABRT) at line 1
while running: llvm-as < /dumpster/home/marcel/LLVM/src/llvm/test/CodeGen/Generic/i128-addsub.ll | llc

.ident "LLVM-ia64"

  .psr lsb
  .radix C
  .psr abi64
Cannot yet select: 0x2000000001d78120: i64,flag = adde 0x2000000001d3c520, 0x2000000001d3c3e0, 0x2000000001d3cc00:1

FAIL: /dumpster/home/marcel/LLVM/src/llvm/test/CodeGen/Generic/multiple-return-values-cross-block-with-invoke.ll
Failed with signal(SIGABRT) at line 1
while running: llvm-as < /dumpster/home/marcel/LLVM/src/llvm/test/CodeGen/Generic/multiple-return-values-cross-block-with-invoke.ll | llc

.ident "LLVM-ia64"

  .psr lsb
  .radix C
  .psr abi64
Assertion failed: (0 && "Unknown type!"), function getValueType, file /dumpster/home/marcel/LLVM/src/llvm/lib/VMCore/ValueTypes.cpp, line 108.

FAIL: /dumpster/home/marcel/LLVM/src/llvm/test/CodeGen/Generic/nested-select.ll
Failed with signal(SIGABRT) at line 1
while running: llvm-as < /dumpster/home/marcel/LLVM/src/llvm/test/CodeGen/Generic/nested-select.ll | llc -o /dev/null -f
Cannot yet select: 0x2000000001d78120: i1 = setcc 0x2000000001d3a5c0, 0x2000000001d4c2b0, 0x2000000001d08e00

FAIL: /dumpster/home/marcel/LLVM/src/llvm/test/CodeGen/Generic/print-arith-fp.ll
Failed with signal(SIGABRT) at line 1
while running: llvm-as < /dumpster/home/marcel/LLVM/src/llvm/test/CodeGen/Generic/print-arith-fp.ll | llc

.ident "LLVM-ia64"

  .psr lsb
  .radix C
  .psr abi64
Cannot yet select: 0x2000000001d7dd90: i1 = setcc 0x2000000001d82100, 0x2000000001d82220, 0x2000000001d09ac0

FAIL: /dumpster/home/marcel/LLVM/src/llvm/test/CodeGen/Generic/select.ll
Failed with signal(SIGABRT) at line 1
while running: llvm-as < /dumpster/home/marcel/LLVM/src/llvm/test/CodeGen/Generic/select.ll | llc

.ident "LLVM-ia64"

  .psr lsb
  .radix C
  .psr abi64

  .section .text, "ax", "progbits"

  .align 32
  .global testConsts
  .type testConsts, @function
testConsts:
  alloc r3 = ar.pfs,0,0,0,0
  // PSEUDO_ALLOC
  ;;
  mov ar.pfs = r3
  br.ret.sptk.many rp

  .align 32
  .global unusedBool
  .type unusedBool, @function
unusedBool:
  alloc r3 = ar.pfs,0,0,0,0
  // PSEUDO_ALLOC
  ;;
  mov ar.pfs = r3
  br.ret.sptk.many rp

  .align 32
  .global mergeConstants
  .type mergeConstants, @function
mergeConstants:
  alloc r3 = ar.pfs,0,0,0,0
  // PSEUDO_ALLOC
.BB3_1: // Top
  (p0) brl.cond.sptk .BB3_1 // Top
.BB3_2: // Next
  (p0) brl.cond.sptk .BB3_1 // Top

  .align 32
  .global castconst
  .type castconst, @function
castconst:
  ;;
  alloc r3 = ar.pfs,0,0,0,0
  // PSEUDO_ALLOC
  adds r8 = 0, r0
  ;;
  mov ar.pfs = r3
  br.ret.sptk.many rp

  .align 32
  .global testbool
  .type testbool, @function
testbool:
  alloc r3 = ar.pfs,0,2,0,0
  // PSEUDO_ALLOC
.BB5_1: // Top
  add r8 = r32, r33
  ;;
  adds r9 = 4, r8
  ;;
  sxt4 r9 = r9
  adds r10 = 1, r0
  ;;
  cmp.lt p6, p0 = r9, r10
  ;;
  (p6) brl.cond.sptk .BB5_3 // retlbl
.BB5_2: // loop
  adds r9 = 4, r8
  ;;
  sxt4 r9 = r9
  adds r10 = 0, r0
  ;;
  cmp.gt p6, p0 = r9, r10
  ;;
  (p6) brl.cond.sptk .BB5_2 // loop
  (p0) brl.cond.sptk .BB5_1 // Top
.BB5_3: // retlbl
  mov ar.pfs = r3
  br.ret.sptk.many rp

  .align 32
  .global castbool
  .type castbool, @function
castbool:
  alloc r3 = ar.pfs,0,2,0,0
  // PSEUDO_ALLOC
  sxt4 r9 = r33
  sxt4 r10 = r32
  adds r8 = 0, r0
  ;;
  cmp.lt p6, p0 = r10, r9
  ;;
  (p6) add r8 = 1, r8
  mov ar.pfs = r3
  ;;
  br.ret.sptk.many rp

  .align 32
  .global boolexpr
  .type boolexpr, @function
boolexpr:
  alloc r3 = ar.pfs,0,2,0,0
  // PSEUDO_ALLOC
  sxt4 r8 = r33
  adds r9 = -1, r0
  cmp.ne p6, p0 = r32, r0
  cmp.eq p7, p0 = r0, r0
  ;;
  cmp.gt p8, p0 = r8, r9
  (p7) cmp.eq.unc p7, p0 = r0, r0
  ;;
  (p8) cmp.ne p7, p0 = r0, r0
  (p6) cmp.eq.unc p6, p0 = r0, r0
  adds r8 = 0, r0
  ;;
  (p6) cmp.eq.unc p6, p0 = r0, r0
  ;;
  (p7) cmp.ne p6, p0 = r0, r0
  ;;
  (p6) add r8 = 1, r8
  mov ar.pfs = r3
  ;;
  br.ret.sptk.many rp
Cannot yet select: 0x2000000001d78120: i1 = setcc 0x2000000001d44ca0, 0x2000000001d44d40, 0x2000000001d095e0

FAIL: /dumpster/home/marcel/LLVM/src/llvm/test/CodeGen/X86/2007-10-04-AvoidEFLAGSCopy.ll
Failed with signal(SIGABRT) at line 1
while running: llvm-as < /dumpster/home/marcel/LLVM/src/llvm/test/CodeGen/X86/2007-10-04-AvoidEFLAGSCopy.ll | llc | not grep pushf
Assertion failed: (MVT::isInteger(VT) && MVT::isInteger(Operand.getValueType()) && "Invalid TRUNCATE!"), function getNode, file /dumpster/home/marcel/LLVM/src/llvm/lib/CodeGen/SelectionDAG/SelectionDAG.cpp, line 2011.

FAIL: /dumpster/home/marcel/LLVM/src/llvm/test/CodeGen/X86/fold-load.ll
Failed with signal(SIGABRT) at line 1
while running: llvm-as < /dumpster/home/marcel/LLVM/src/llvm/test/CodeGen/X86/fold-load.ll | llc

.ident "LLVM-ia64"

  .psr lsb
  .radix C
  .psr abi64
Assertion failed: (ResNo < NumValues && "Illegal result number!"), function getValueType, file /dumpster/home/marcel/LLVM/src/llvm/include/llvm/CodeGen/SelectionDAGNodes.h, line 1220.

FAIL: /dumpster/home/marcel/LLVM/src/llvm/test/CodeGen/X86/memcpy-2.ll
Failed with exit(1) at line 2
while running: llvm-as < /dumpster/home/marcel/LLVM/src/llvm/test/CodeGen/X86/memcpy-2.ll | llc -march=x86 -mattr=+sse | grep mov | count 5
count: expected 5 lines and got 6.
child process exited abnormally
FAIL: /dumpster/home/marcel/LLVM/src/llvm/test/CodeGen/X86/memset.ll
Failed with exit(1) at line 2
while running: llvm-as < /dumpster/home/marcel/LLVM/src/llvm/test/CodeGen/X86/memset.ll | llc -march=x86 -mattr=+sse | grep mov | count 3
count: expected 3 lines and got 5.
child process exited abnormally
FAIL: /dumpster/home/marcel/LLVM/src/llvm/test/CodeGen/X86/pmul.ll
Failed with exit(1) at line 3
while running: grep mov pmul.ll.tmp | count 8
count: expected 8 lines and got 20.
child process exited abnormally
FAIL: /dumpster/home/marcel/LLVM/src/llvm/test/CodeGen/X86/vec_shuffle-18.ll
Failed with exit(1) at line 1
while running: llvm-as < /dumpster/home/marcel/LLVM/src/llvm/test/CodeGen/X86/vec_shuffle-18.ll | llc -march=x86 -mattr=+sse2 | grep mov

count 7

count: expected 7 lines and got 9.
child process exited abnormally

FAIL: /dumpster/home/marcel/LLVM/src/llvm/test/ExecutionEngine/2003-08-21-EnvironmentTest.ll
Failed with signal(SIGABRT) at line 2
while running: lli 2003-08-21-EnvironmentTest.ll.tmp.bc > /dev/null
Assertion failed: (BitWidth == RHS.BitWidth && "Comparison requires equal bit widths"), function operator==, file /dumpster/home/marcel/LLVM/src/llvm/lib/Support/APInt.cpp, line 518.

FAIL: /dumpster/home/marcel/LLVM/src/llvm/test/Transforms/PredicateSimplifier/2006-10-25-AddSetCC.ll
Failed with exit(1) at line 1
while running: llvm-as < /dumpster/home/marcel/LLVM/src/llvm/test/Transforms/PredicateSimplifier/2006-10-25-AddSetCC.ll | opt -predsimplify -instcombine -simplifycfg | llvm-dis | grep -v declare | grep pass | count 2
count: expected 2 lines and got 0.
Assertion failed: (validPredicate(R) && "Invalid predicate."), function update, file /dumpster/home/marcel/LLVM/src/llvm/lib/Transforms/Scalar/PredicateSimplifier.cpp, line 701.
llvm-dis: Invalid bitcode signature

FAIL: /dumpster/home/marcel/LLVM/src/llvm/test/Transforms/PredicateSimplifier/2006-11-04-ReplacingZeros.ll
Failed with signal(SIGABRT) at line 1
while running: llvm-as < /dumpster/home/marcel/LLVM/src/llvm/test/Transforms/PredicateSimplifier/2006-11-04-ReplacingZeros.ll | opt -predsimplify -disable-output
Assertion failed: (validPredicate(R) && "Invalid predicate."), function update, file /dumpster/home/marcel/LLVM/src/llvm/lib/Transforms/Scalar/PredicateSimplifier.cpp, line 701.

FYI,

Let us know if you would like extra eyes on the two PPC failures. Many
of us have a lot of experience with C++. :slight_smile: Do you know where these
allocations are?

I don't mind if people help out, so here's some information:

FAIL: /nfs/llvm/src/llvm/test/Transforms/PredicateSimplifier/
2006-11-04-ReplacingZeros.ll
Failed with signal(SIGABRT) at line 1
while running: llvm-as < /nfs/llvm/src/llvm/test/Transforms/
PredicateSimplifier/2006-11-04-ReplacingZeros.ll | opt -predsimplify -
disable-output
Assertion failed: (validPredicate(R) && "Invalid predicate."),
function update, file /nfs/llvm/src/llvm/lib/Transforms/Scalar/
PredicateSimplifier.cpp, line 702.

xserve% Debug/bin/llvm-as < /nfs/llvm/src/llvm/test/Transforms/
PredicateSimplifier/2006-11-04-ReplacingZeros.ll > x.bc

xserve% gdb Debug/bin/opt
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.

...

#3 0x22281d80 in __assert () from /lib/libc.so.7
#4 0x01c34a78 in update (this=0x200c940, n=1515870810, R=1515870810,
Subtree=0x20298c0) at /nfs/llvm/src/llvm/lib/Transforms/Scalar/
PredicateSimplifier.cpp:702
#5 0x01c3d134 in makeEqual (this=0x7fffd550, V1=0x2009730,
V2=0x2006624) at /nfs/llvm/src/llvm/lib/Transforms/Scalar/
PredicateSimplifier.cpp:1614

...

(gdb) frame 5
#5 0x01c3d134 in makeEqual (this=0x7fffd550, V1=0x2009730,
V2=0x2006624) at /nfs/llvm/src/llvm/lib/Transforms/Scalar/
PredicateSimplifier.cpp:1614
1614 IG.node(n1)->update(NI->To, NI->LV, Top);
(gdb) p NI
$1 = ((anonymous namespace)::InequalityGraph::Edge *) 0x2036390
(gdb) p /x *NI
$2 = {To = 0x5a5a5a5a, LV = 0x5a5a5a5a, Subtree = 0x5a5a5a5a}
(gdb) p NE
$3 = ((anonymous namespace)::InequalityGraph::Edge *) 0x203639c
(gdb) p /x *NE
$4 = {To = 0x5a5a5a5a, LV = 0x5a5a5a5a, Subtree = 0x5a5a5a5a}

Both NI and NE are defined by the for loop:

1603 for (Node::iterator NI = IG.node(n)->begin(), NE =
IG.node(n)->end();
1604 NI != NE; ++NI) {

In this case:

(gdb) p n
$5 = 4
(gdb) p IG.node(n)->begin()
$12 = ((anonymous namespace)::InequalityGraph::Edge *) 0x1f59378
(gdb) p IG.node(n)->end()
$14 = ((anonymous namespace)::InequalityGraph::Edge *) 0xa5a5a5a5

Before it hits these "update" calls, what is the value of *NI and n? My hypothesis is that the first "update" call is invalidating the NI/NE iterators because it's inserting things into the list. Because the SmallVector is only declared to hold 4 things, the 5th iteration (n == 4) would cause it to reallocate the internal storage. If both NI->To and n are the same, then this would cause NI (and NE) to get bad values.

-bw

Could you try this (massively hacky) patch out to see if it fixes your problem?

-bw

Index: lib/Transforms/Scalar/PredicateSimplifier.cpp

Alas, it didn't fix the problem:

  ...
gmake[3]: Entering directory `/nfs/llvm/obj/powerpc/lib/Transforms/Scalar'
llvm[3]: Compiling PredicateSimplifier.cpp for Debug build
/nfs/llvm/src/llvm/lib/Transforms/Scalar/PredicateSimplifier.cpp: In constructor '<unnamed>::InequalityGraph::Edge::Edge()':
/nfs/llvm/src/llvm/lib/Transforms/Scalar/PredicateSimplifier.cpp:607: warning: format '%p' expects type 'void*', but argument 2 has type '<unnamed>::InequalityGraph::Edge*'
llvm[3]: Building Debug Archive Library libLLVMScalarOpts.a
gmake[3]: Leaving directory `/nfs/llvm/obj/powerpc/lib/Transforms/Scalar'
  ...

xserve% Debug/bin/opt -predsimplify -disable-output < x.bc
Assertion failed: (validPredicate(R) && "Invalid predicate."), function update, file /nfs/llvm/src/llvm/lib/Transforms/Scalar/PredicateSimplifier.cpp, line 711.
Abort (core dumped)

(gdb) bt
#0 0x2229ce08 in kill () from /lib/libc.so.7
#1 0x22000848 in raise () from /lib/libthr.so.3
#2 0x2229b6ec in abort () from /lib/libc.so.7
#3 0x22281d80 in __assert () from /lib/libc.so.7
#4 0x01c34b4c in update (this=0x200c940, n=1515870810, R=1515870810, Subtree=0x20298c0) at /nfs/llvm/src/llvm/lib/Transforms/Scalar/PredicateSimplifier.cpp:711
#5 0x01c3d224 in makeEqual (this=0x7fffd580, V1=0x2009730, V2=0x2006624) at /nfs/llvm/src/llvm/lib/Transforms/Scalar/PredicateSimplifier.cpp:1626
#6 0x01c3dc2c in solve (this=0x7fffd580) at /nfs/llvm/src/llvm/lib/Transforms/Scalar/PredicateSimplifier.cpp:2165
#7 0x01c3fa70 in visitBranchInst (this=0x7fffd678, BI=@0x2006714) at /nfs/llvm/src/llvm/lib/Transforms/Scalar/PredicateSimplifier.cpp:2461
#8 0x01c3fca4 in visitBr (this=0x7fffd678, I=@0x2006714) at Instruction.def:98
#9 0x01c4014c in visit (this=0x7fffd678, I=@0x2006714) at Instruction.def:98
#10 0x01c40bbc in visitInstruction (this=0x2006790, I=0x2006714, DT=0x2029800) at /nfs/llvm/src/llvm/lib/Transforms/Scalar/PredicateSimplifier.cpp:2390
#11 0x01c40d5c in visitBasicBlock (this=0x2006790, Node=0x2029800) at /nfs/llvm/src/llvm/lib/Transforms/Scalar/PredicateSimplifier.cpp:2334
#12 0x01c411cc in runOnFunction (this=0x2006790, F=@0x2006510) at /nfs/llvm/src/llvm/lib/Transforms/Scalar/PredicateSimplifier.cpp:2412
#13 0x01e84874 in llvm::FPPassManager::runOnFunction (this=0x2021080, F=@0x2006510) at /nfs/llvm/src/llvm/lib/VMCore/PassManager.cpp:1178
#14 0x01e84aac in llvm::FPPassManager::runOnModule (this=0x2021080, M=@0x20093a0) at /nfs/llvm/src/llvm/lib/VMCore/PassManager.cpp:1198
#15 0x01e8432c in llvm::MPPassManager::runOnModule (this=0x202c110, M=@0x20093a0) at /nfs/llvm/src/llvm/lib/VMCore/PassManager.cpp:1248
#16 0x01e84588 in llvm::PassManagerImpl::run (this=0x201d100, M=@0x20093a0) at /nfs/llvm/src/llvm/lib/VMCore/PassManager.cpp:1322
#17 0x01e84648 in llvm::PassManager::run (this=0x7fffdb40, M=@0x20093a0) at /nfs/llvm/src/llvm/lib/VMCore/PassManager.cpp:1354
#18 0x01a70774 in main (argc=3, argv=0x7fffdbf8) at /nfs/llvm/src/llvm/tools/opt/opt.cpp:431

(gdb) x /x E
0x2036390: 0x5a5a5a5a
(gdb) p n1
$1 = 5
(gdb) p *N
$2 = {_vptr$Node = 0x5a5a5a5a, Relations = {<llvm::SmallVectorImpl<<unnamed>::InequalityGraph::Edge>> = {Begin = 0x5a5a5a5a, End = 0x5a5a5a5a, Capacity = 0x5a5a5a5a, FirstEl = 90 'Z'}, InlineElts = 'Z' <repeats 47 times>}}

FYI,

Could you try this (massively hacky) patch out to see if it fixes your
problem?

Alas, it didn't fix the problem:

Crumbs.

I think that the analysis I told you before wasn't fully correct. I think I mentioned something about "n = 4" and that could cause the SmallVector to reallocate things. But that was in error.

I tried it on my Mac, enabling a mode where malloc initializes memory with 0xAA and deallocated memory with 0x55, but didn't run into the crash that you see here. Perhaps you can track down where the node "4" is being created and see if the values for it aren't being initialized. If they are being initialized, then set a watch on the node to see where they get overwritten.

-bw

Could you try this (massively hacky) patch out to see if it fixes
your
problem?

Alas, it didn't fix the problem:

Crumbs.

I think that the analysis I told you before wasn't fully correct. I
think I mentioned something about "n = 4" and that could cause the
SmallVector to reallocate things. But that was in error.

It sounded very plausible to me :slight_smile: I'll keep it in the back of my
mind...

I tried it on my Mac, enabling a mode where malloc initializes memory
with 0xAA and deallocated memory with 0x55, but didn't run into the
crash that you see here.

Hmmm, odd. I've been trying to figure out on the side why I see
this on powerpc and not i386 or amd64 for example. Endianness was
one thought, but given that it works on your Mac, it cannot be
that simple. I guess it simply means bad code generation is slowly
creeping on the list of suspects...

Perhaps you can track down where the node "4"
is being created and see if the values for it aren't being
initialized. If they are being initialized, then set a watch on the
node to see where they get overwritten.

Will do...

Could you try this (massively hacky) patch out to see if it fixes
your
problem?

Alas, it didn't fix the problem:

Crumbs.

I think that the analysis I told you before wasn't fully correct. I
think I mentioned something about "n = 4" and that could cause the
SmallVector to reallocate things. But that was in error.

The analysis seems to be right after all. The node iterator (NI) is
clobbered when node 5 is added. The reason it sometimes causes a
failure may be related to whether NI is dereferenced after it's
being clobbered. This is highly platform specific, as well as
optimization specific. The problem exists on all platforms that
I've seen so far.

In short:

The call to update() on line 1612 of PredicateSimplifier.cpp can
result in the resizing of the node vector, which breaks dereferencing
NI in the call to update() on line 1613 of PredicateSimplifier.cpp.

(gdb) run
Starting program: /nfs/llvm/obj/amd64/Debug/bin/opt -predsimplify -disable-output < ../powerpc/x.bc
[New LWP 100066]
[New Thread 0xd040b0 (LWP 100066)]
[Switching to Thread 0xd040b0 (LWP 100066)]

Breakpoint 3, makeEqual (this=0x7fffffffe110, V1=0xd1c420, V2=0xd3b168)
     at /nfs/llvm/src/llvm/lib/Transforms/Scalar/PredicateSimplifier.cpp:1612
1612 IG.node(NI->To)->update(n1, reversePredicate(NI- >LV), Top);
(gdb) p NI
$28 = ((anonymous namespace)::InequalityGraph::Edge *) 0xd56340
(gdb) watch *0xd56340
Watchpoint 6: *13984576
(gdb) c
Continuing.
Watchpoint 6: *13984576

Old value = 2
New value = 1515870810
0x00000008013e1e84 in memset () from /lib/libc.so.7
(gdb) bt
#0 0x00000008013e1e84 in memset () from /lib/libc.so.7
#1 0x000000080136ecd1 in malloc_usable_size () from /lib/libc.so.7
#2 0x000000080136eec7 in free () from /lib/libc.so.7
#3 0x00000000007cdf7d in deallocate (this=0xd2e178, __p=0xd561c0)
     at new_allocator.h:97
#4 0x00000000007cdfaf in _M_deallocate (this=0xd2e178, __p=0xd561c0, __n=4)
     at stl_vector.h:134
#5 0x00000000007d66ef in _M_fill_insert (this=0xd2e178, __position=
       {_M_current = 0xd56380}, __n=1, __x=@0x7fffffffdbb0) at vector.tcc:381
#6 0x00000000007d676d in insert (this=0xd2e178, __position=
       {_M_current = 0xd56380}, __n=1, __x=@0x7fffffffdbb0) at stl_vector.h:653
#7 0x00000000007d67f7 in resize (this=0xd2e178, __new_size=5,
     __x=@0x7fffffffdbb0) at stl_vector.h:421
#8 0x00000000007d6877 in node (this=0xd2e160, index=5)
     at /nfs/llvm/src/llvm/lib/Transforms/Scalar/PredicateSimplifier.cpp:749
#9 0x00000000007ddcc3 in makeEqual (this=0x7fffffffe110, V1=0xd1c420,
     V2=0xd3b168)

The following quick-n-dirty fix avoids dereferencing the clobbered NI
and as such fixes the superficial problem (i.e. the assert):

Index: PredicateSimplifier.cpp

Thanks for tracking this down! I can't seem to reproduce it on Linux, even with valgrind.

Can you try out this patch and let me know whether it works?

Nick

Marcel Moolenaar wrote:

patch (582 Bytes)

We have a winner :slight_smile:
FYI,

Let us know if you would like extra eyes on the two PPC failures. Many
of us have a lot of experience with C++. :slight_smile: Do you know where these
allocations are?

I don't mind if people help out, so here's some information:

Nice!

My current plan is as follows:
o Resolve powerpc failures to bring it in line with amd64 & i386.
o Adding support for inline assembly for ia64 (already started) and
improving ia64 in general. This is longer term work...

Is the lack of inline assembly the cause of the 21 regressions on
ia64? Or is it something more systemic?

No, not entirely. I added some debug printf's and I see them
pop up in the output, but there are more failures:

FAIL: /dumpster/home/marcel/LLVM/src/llvm/test/CodeGen/Generic/GC/
frame_size.ll
Failed with exit(1) at line 1
while running: llvm-as < /dumpster/home/marcel/LLVM/src/llvm/test/
CodeGen/Generic/GC/frame_size.ll | llc -asm-verbose | grep {frame
size} | grep -v 0x0
Assertion failed: (ResNo < NumValues && "Illegal result number!"),
function getValueType, file /dumpster/home/marcel/LLVM/src/llvm/
include/llvm/CodeGen/SelectionDAGNodes.h, line 1220.

FAIL: /dumpster/home/marcel/LLVM/src/llvm/test/CodeGen/Generic/
2003-05-27-phifcmpd.ll
Failed with signal(SIGABRT) at line 1
while running: llvm-as < /dumpster/home/marcel/LLVM/src/llvm/test/
CodeGen/Generic/2003-05-27-phifcmpd.ll | llc

This looks like the isel pass is creating an LD8 node with no chain result:

0x1204e00: i64 = LD8 0x1204da0

This patch should help:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20080526/062966.html

This now looks like the fp compare issue below.

.ident "LLVM-ia64"

  .psr lsb
  .radix C
  .psr abi64
Cannot yet select: 0x2000000001d76120: i1 = setcc 0x2000000001d46520,
0x2000000001d48240, 0x2000000001d08fe0

FAIL: /dumpster/home/marcel/LLVM/src/llvm/test/CodeGen/Generic/
2003-05-27-useboolinotherbb.ll

This looks like ia64 backend isn't handling 'setune' (set if unordered or not equal), and looks like an easy place to start. Check out IA64InstrInfo.td, around line 292 for a place to start:

def FCMPEQ : AForm_DAG<0x03, 0x0b, (outs PR:$dst), (ins FP:$src1, FP:$src2),
           "fcmp.eq $dst, p0 = $src1, $src2",
           [(set PR:$dst, (seteq FP:$src1, FP:$src2))]>, isF;
def FCMPGT : AForm_DAG<0x03, 0x0b, (outs PR:$dst), (ins FP:$src1, FP:$src2),
           "fcmp.gt $dst, p0 = $src1, $src2",
           [(set PR:$dst, (setgt FP:$src1, FP:$src2))]>, isF;
...

You probably just need another line for setune. It looks like several other FP compares are missing, you might want to make sure the full list in lib/Target/TargetSelectionDAG.td:843 is supported.

FAIL: /dumpster/home/marcel/LLVM/src/llvm/test/CodeGen/Generic/
2003-05-27-usefsubasbool.ll
Failed with signal(SIGABRT) at line 1
while running: llvm-as < /dumpster/home/marcel/LLVM/src/llvm/test/
CodeGen/Generic/2003-05-27-usefsubasbool.ll | llc

Same thing.

FAIL: /dumpster/home/marcel/LLVM/src/llvm/test/CodeGen/Generic/
2005-10-21-longlonggtu.ll
Failed with signal(SIGABRT) at line 1
while running: llvm-as < /dumpster/home/marcel/LLVM/src/llvm/test/
CodeGen/Generic/2005-10-21-longlonggtu.ll | llc

Fixed:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20080526/062967.html

  .psr lsb
  .radix C
  .psr abi64
Assertion failed: (MVT::isInteger(VT) &&
MVT::isInteger(Operand.getValueType()) && "Invalid TRUNCATE!"),
function getNode, file /dumpster/home/marcel/LLVM/src/llvm/lib/CodeGen/
SelectionDAG/SelectionDAG.cpp, line 2011.

I assume this is the same.

FAIL: /dumpster/home/marcel/LLVM/src/llvm/test/CodeGen/Generic/
2006-04-28-Sign-extend-bool.ll
Failed with signal(SIGABRT) at line 1
while running: llvm-as < /dumpster/home/marcel/LLVM/src/llvm/test/
CodeGen/Generic/2006-04-28-Sign-extend-bool.ll | llc

This should now be fixed:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20080526/062965.html

FAIL: /dumpster/home/marcel/LLVM/src/llvm/test/CodeGen/Generic/
2007-04-08-MultipleFrameIndices.ll for PR1308,1557
Failed with signal(SIGABRT) at line 1
while running: llvm-as < /dumpster/home/marcel/LLVM/src/llvm/test/
CodeGen/Generic/2007-04-08-MultipleFrameIndices.ll | llc

I get:
Couldn't allocate output reg for contraint 'r'!

so it looks like inline asm related.

FAIL: /dumpster/home/marcel/LLVM/src/llvm/test/CodeGen/Generic/
2007-04-27-LargeMemObject.ll for PR1557

Likewise.

FAIL: /dumpster/home/marcel/LLVM/src/llvm/test/CodeGen/Generic/
2008-02-20-MatchingMem.ll for PR1133

Likewise.

FAIL: /dumpster/home/marcel/LLVM/src/llvm/test/CodeGen/Generic/i128-
addsub.ll
Failed with signal(SIGABRT) at line 1
while running: llvm-as < /dumpster/home/marcel/LLVM/src/llvm/test/
CodeGen/Generic/i128-addsub.ll | llc

.ident "LLVM-ia64"

  .psr lsb
  .radix C
  .psr abi64
Cannot yet select: 0x2000000001d78120: i64,flag = adde
0x2000000001d3c520, 0x2000000001d3c3e0, 0x2000000001d3cc00:1

This is ia64 not supporting add/sub with carry on i64 values. This should also be relatively easy to tackle.

FAIL: /dumpster/home/marcel/LLVM/src/llvm/test/CodeGen/Generic/
multiple-return-values-cross-block-with-invoke.ll
Failed with signal(SIGABRT) at line 1
while running: llvm-as < /dumpster/home/marcel/LLVM/src/llvm/test/
CodeGen/Generic/multiple-return-values-cross-block-with-invoke.ll | llc

This is ia64 not handling multiple return values correctly. The calling convention stuff should switch over to using the new "autogenerate from .td files" mechanism the other backends are now using.

FAIL: /dumpster/home/marcel/LLVM/src/llvm/test/CodeGen/Generic/nested-
select.ll
Failed with signal(SIGABRT) at line 1
while running: llvm-as < /dumpster/home/marcel/LLVM/src/llvm/test/
CodeGen/Generic/nested-select.ll | llc -o /dev/null -f
Cannot yet select: 0x2000000001d78120: i1 = setcc 0x2000000001d3a5c0,
0x2000000001d4c2b0, 0x2000000001d08e00

more missing FP comparisons.

FAIL: /dumpster/home/marcel/LLVM/src/llvm/test/CodeGen/Generic/print-
arith-fp.ll
Failed with signal(SIGABRT) at line 1
while running: llvm-as < /dumpster/home/marcel/LLVM/src/llvm/test/
CodeGen/Generic/print-arith-fp.ll | llc

Likewise.

FAIL: /dumpster/home/marcel/LLVM/src/llvm/test/CodeGen/Generic/select.ll
Failed with signal(SIGABRT) at line 1
while running: llvm-as < /dumpster/home/marcel/LLVM/src/llvm/test/
CodeGen/Generic/select.ll | llc
.ret.sptk.many rp
Cannot yet select: 0x2000000001d78120: i1 = setcc 0x2000000001d44ca0,
0x2000000001d44d40, 0x2000000001d095e0

Likewise.

FAIL: /dumpster/home/marcel/LLVM/src/llvm/test/CodeGen/X86/2007-10-04-
AvoidEFLAGSCopy.ll
Failed with signal(SIGABRT) at line 1
while running: llvm-as < /dumpster/home/marcel/LLVM/src/llvm/test/
CodeGen/X86/2007-10-04-AvoidEFLAGSCopy.ll | llc | not grep pushf
Assertion failed: (MVT::isInteger(VT) &&
MVT::isInteger(Operand.getValueType()) && "Invalid TRUNCATE!"),
function getNode, file /dumpster/home/marcel/LLVM/src/llvm/lib/CodeGen/
SelectionDAG/SelectionDAG.cpp, line 2011.

I assume this is fixed.

FAIL: /dumpster/home/marcel/LLVM/src/llvm/test/CodeGen/X86/fold-load.ll
Failed with signal(SIGABRT) at line 1
while running: llvm-as < /dumpster/home/marcel/LLVM/src/llvm/test/
CodeGen/X86/fold-load.ll | llc

This looks like some issue with loads. The IA64 backend is doing some funky stuff with custom isel'ing various loads. It may have been required in the past, but can now probably be all moved to the .td file, cleaning up a lot of gross code in IA64ISelDAGToDAG.cpp.

FAIL: /dumpster/home/marcel/LLVM/src/llvm/test/CodeGen/X86/memcpy-2.ll
Failed with exit(1) at line 2

This should be fixed on mainline.

FAIL: /dumpster/home/marcel/LLVM/src/llvm/test/ExecutionEngine/
2003-08-21-EnvironmentTest.ll
Failed with signal(SIGABRT) at line 2
while running: lli 2003-08-21-EnvironmentTest.ll.tmp.bc > /dev/null
Assertion failed: (BitWidth == RHS.BitWidth && "Comparison requires
equal bit widths"), function operator==, file /dumpster/home/marcel/
LLVM/src/llvm/lib/Support/APInt.cpp, line 518.

I can't repro this one. Is it trying to run the jit or is this an abort in the interpreter?

Hope this helps. It looks like the remaining issues are pretty simple.

-Chris

My current plan is as follows:
o Resolve powerpc failures to bring it in line with amd64 & i386.

BTW: PowerPC is now inline with amd64 and powerpc. See also:
  http://wiki.freebsd.org/LowLevelVirtualMachine

No, not entirely. I added some debug printf's and I see them

pop up in the output, but there are more failures:

[skipping valuable feedback and suggestions...]

I get:
Couldn't allocate output reg for contraint 'r'!

I'm running with local mods. I implemented the 'r' constraint
already. Sorry, I didn't make that clear...

FAIL: /dumpster/home/marcel/LLVM/src/llvm/test/ExecutionEngine/
2003-08-21-EnvironmentTest.ll
Failed with signal(SIGABRT) at line 2
while running: lli 2003-08-21-EnvironmentTest.ll.tmp.bc > /dev/null
Assertion failed: (BitWidth == RHS.BitWidth && "Comparison requires
equal bit widths"), function operator==, file /dumpster/home/marcel/
LLVM/src/llvm/lib/Support/APInt.cpp, line 518.

I can't repro this one. Is it trying to run the jit or is this an
abort in the interpreter?

It's an abort in the interpreter. Consider the input:

\begin{input}
  declare i32 @strlen(i8*)

  define i32 @main(i32 %argc.1, i8** %argv.1, i8** %envp.1) {
          %tmp.2 = load i8** %envp.1 ; <i8*> [#uses=1]
          %tmp.3 = call i32 @strlen( i8* %tmp.2 ) ; <i32> [#uses=1]
          %T = icmp eq i32 %tmp.3, 0 ; <i1> [#uses=1]
          %R = zext i1 %T to i32 ; <i32> [#uses=1]
          ret i32 %R
  }
\end{input}

The compare gets a 64-bit integer (the result of strlen()) and a 32-bit
integer (the constant 0). This may be a problem with the input, because
the call to strlen() is declared as returning an i32, but a size_t on
ia64 is 64-bits. However, this would assume that the interpreter knows
about it, so it may not be that simple :slight_smile:

pluto2% gdb ../../Debug/bin/lli
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "ia64-marcel-freebsd"...
(gdb) set args < EnvironmentTest.bc
(gdb) br __assert
Function "__assert" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (__assert) pending.
(gdb) run
Starting program: /dumpster/home/marcel/LLVM/obj/ia64/Debug/bin/lli < EnvironmentTest.bc
Breakpoint 2 at 0x200000004163c3b0
Pending breakpoint "__assert" resolved

Breakpoint 2, 0x200000004163c3b0 in __assert () from /lib/libc.so.7
Current language: auto; currently c
(gdb) bt
#0 0x200000004163c3b0 in __assert () from /lib/libc.so.7
#1 0x2000000000e3c490 in llvm::APInt::operator== (this=0x9fffffffffffe7a0, RHS=@0x9fffffffffffe788) at /dumpster/home/marcel/LLVM/src/llvm/lib/Support/APInt.cpp:518
#2 0x20000000003cb9f0 in llvm::APInt::eq (this=0x9fffffffffffe7a0, RHS=@0x9fffffffffffe788) at APInt.h:719
#3 0x20000000003931e0 in executeICMP_EQ (Src1=@0x9fffffffffffe798, Src2=@0x9fffffffffffe780, Ty=0x200000000120a300) at /dumpster/home/marcel/LLVM/src/llvm/lib/ExecutionEngine/Interpreter/Execution.cpp:152
#4 0x20000000003a1c60 in llvm::Interpreter::visitICmpInst (this=0x2000000001240200, I=@0x200000000122c130) at /dumpster/home/marcel/LLVM/src/llvm/lib/ExecutionEngine/Interpreter/Execution.cpp:286
#5 0x20000000003cd020 in llvm::InstVisitor<llvm::Interpreter,

::visitICmp (this=0x2000000001240200, I=@0x200000000122c130) at

Instruction.def:156
#6 0x20000000003cdf00 in llvm::InstVisitor<llvm::Interpreter,

::visit (this=0x2000000001240200, I=@0x200000000122c130) at

Instruction.def:156
#7 0x20000000003a35c0 in llvm::Interpreter::run (this=0x2000000001240200) at /dumpster/home/marcel/LLVM/src/llvm/lib/ExecutionEngine/Interpreter/Execution.cpp:1338
#8 0x20000000003b01a0 in llvm::Interpreter::runFunction (this=0x2000000001240200, F=0x2000000001232230, ArgValues=@0x9fffffffffffe978) at /dumpster/home/marcel/LLVM/src/llvm/lib/ExecutionEngine/Interpreter/Interpreter.cpp:99
#9 0x20000000003e4a80 in llvm::ExecutionEngine::runFunctionAsMain (this=0x2000000001240200, Fn=0x2000000001232230, argv=@0x2000000001132f08, envp=0x9fffffffffffeb08) at /dumpster/home/marcel/LLVM/src/llvm/lib/ExecutionEngine/ExecutionEngine.cpp:338
#10 0x2000000000309930 in main (argc=1, argv=0x9fffffffffffeaf8, envp=0x9fffffffffffeb08) at /dumpster/home/marcel/LLVM/src/llvm/tools/lli/lli.cpp:163
(gdb) up
#1 0x2000000000e3c490 in llvm::APInt::operator== (this=0x9fffffffffffe7a0, RHS=@0x9fffffffffffe788) at /dumpster/home/marcel/LLVM/src/llvm/lib/Support/APInt.cpp:518
518 assert(BitWidth == RHS.BitWidth && "Comparison requires equal bit widths");
Current language: auto; currently c++
(gdb) p BitWidth
$1 = 64
(gdb) p RHS.BitWidth
$2 = 32
(gdb) frame 3
#3 0x20000000003931e0 in executeICMP_EQ (Src1=@0x9fffffffffffe798, Src2=@0x9fffffffffffe780, Ty=0x200000000120a300) at /dumpster/home/marcel/LLVM/src/llvm/lib/ExecutionEngine/Interpreter/Execution.cpp:152
152 IMPLEMENT_INTEGER_ICMP(eq,Ty);
(gdb) p Src1
$3 = (class llvm::GenericValue &) @0x9fffffffffffe798: {{DoubleVal = 0, FloatVal = 0, PointerVal = 0x0, UIntPairVal = {first = 0, second = 0}, Untyped = "\000\000\000\000\000\000\000"}, IntVal = {BitWidth = 64, {VAL = 10, pVal = 0xa}}}
(gdb) p Src2
$4 = (class llvm::GenericValue &) @0x9fffffffffffe780: {{DoubleVal = 0, FloatVal = 0, PointerVal = 0x0, UIntPairVal = {first = 0, second = 0}, Untyped = "\000\000\000\000\000\000\000"}, IntVal = {BitWidth = 32, {VAL = 0, pVal = 0x0}}}
(gdb)

I decided not to worry about it. Let me know if you like to know
where the 64-bit value (i.e. Src1) comes from...