From bugzilla-daemon at cs.uiuc.edu  Mon Oct  2 13:27:40 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 2 Oct 2006 13:27:40 -0500
Subject: [Bug 930] NEW: DSE pass takes very long to optimize llvmAsmParser.cpp
Message-ID: <200610021827.k92IReEM002028@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=930

           Summary: DSE pass takes very long to optimize??llvmAsmParser.cpp
           Product: libraries
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Scalar Optimizations
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: dpatel at apple.com


I am attaching shark profile.



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Mon Oct  2 15:50:51 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 2 Oct 2006 15:50:51 -0500
Subject: [LLVMbugs] [Bug 896] llvm-gcc's xgcc links with system libstdc++
Message-ID: <200610022050.k92KopQ8004318@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=896

nicholas at mxc.ca changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|INVALID                     |
            Summary|libgcc_s.so not compatible  |llvm-gcc's xgcc links with
                   |with libstdc++.so.6.0.8?    |system libstdc++



------- Additional Comments From nicholas at mxc.ca  2006-10-02 15:50 -------
This bug is being caused by the fact that the bootstrap-built compiler xgcc is
linked against build/gcc/libgcc_s.so.1, but /usr/lib/libstdc++.so.6.



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Mon Oct  2 16:27:32 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 2 Oct 2006 16:27:32 -0500
Subject: [LLVMbugs] [Bug 931] NEW: ConvertStructFieldInitializerToType
	problems
Message-ID: <200610022127.k92LRW3C004899@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=931

           Summary: ConvertStructFieldInitializerToType problems
           Product: tools
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: llvm-gcc
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: alenhar2 at uiuc.edu


When compiling the linux kernel (x86), I've hit the assertion in
ConvertStructFieldInitializerToType.
I am seeing several unhandled cases:
a) ConstantExpr initializing UByte arrays.  These happen to be constant GEP
expressions. ([ulong*] -> [4 x ubyte])
b) ConstantPointerNull initializing UByte arrays. ([null] -> [4 x ubyte])
c) arrays of ints intializing arrays of UBytes. ([2049 x uint] -> [8196 x ubyte])
([initializer type] -> [field type])

The following patch was made to solve a and b before c was discovered.  Probably
in light of c, some generalization and simplification should happen.

--- gcc/llvm-convert.cpp        (revision 178)
+++ gcc/llvm-convert.cpp        (working copy)
@@ -4488,9 +4488,9 @@
  // If this is an integer initializer for an array of ubytes, we are
  // initializing an unaligned integer field.  Break the integer initializer up
  // into pieces.
-  if (ConstantInt *CI = dyn_cast<ConstantInt>(Val)) {
-    if (const ArrayType *ATy = dyn_cast<ArrayType>(FieldTy))
-      if (ATy->getElementType() == Type::UByteTy) {
+  if (const ArrayType *ATy = dyn_cast<ArrayType>(FieldTy))
+    if (ATy->getElementType() == Type::UByteTy) {
+      if (ConstantInt *CI = dyn_cast<ConstantInt>(Val)) {
        std::vector<Constant*> ArrayElts;
        uint64_t Val = CI->getRawValue();
        for (unsigned i = 0, e = ATy->getNumElements(); i != e; ++i) {
@@ -4504,14 +4504,54 @@

          ArrayElts.push_back(ConstantUInt::get(Type::UByteTy, EltVal));
        }
-
        return ConstantArray::get(ATy, ArrayElts);
+      } else if (isa<ConstantPointerNull>(Val)) {
+        std::vector<Constant*> ArrayElts;
+        for (unsigned i = 0, e = ATy->getNumElements(); i != e; ++i)
+          ArrayElts.push_back(ConstantUInt::get(Type::UByteTy, 0));
+        return ConstantArray::get(ATy, ArrayElts);
+      } else if (ConstantExpr* CE = dyn_cast<ConstantExpr>(Val)) {
+        Type* tcasted = 0;
+        switch (TD.getTypeSize(CE->getType())) {
+        case 1: tcasted = Type::UByteTy;  break;
+        case 2: tcasted = Type::UShortTy; break;
+        case 4: tcasted = Type::UIntTy;   break;
+        case 8: tcasted = Type::ULongTy;  break;
+        default: break;
+        }
+        if (tcasted) {
+          std::vector<Constant*> ArrayElts;
+          Constant* CEC = ConstantExpr::getCast(CE, tcasted);
+          for (unsigned i = 0, e = ATy->getNumElements(); i != e; ++i) {
+            Constant* EltVal;
+            if (TD.isLittleEndian())
+              EltVal = ConstantInt::get(Type::UByteTy,i);
+            else
+              EltVal = ConstantInt::get(Type::UByteTy,e-i-1);
+            EltVal = ConstantExpr::getCast(
+                       ConstantExpr::getShr(CEC,
+
ConstantExpr::getMul(ConstantInt::get(Type::UByteTy,8),
+                                              EltVal)),
+                       Type::UByteTy);
+            ArrayElts.push_back(EltVal);
+          }
+          return ConstantArray::get(ATy, ArrayElts);
+        }
      }
-  }
+    }



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Mon Oct  2 23:38:23 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 2 Oct 2006 23:38:23 -0500
Subject: [LLVMbugs] [Bug 932] NEW: Break Critical Edges pass doesn't update
	dominators right in some cases
Message-ID: <200610030438.k934cNMt011770@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=932

           Summary: Break Critical Edges pass doesn't update dominators
                    right in some cases
           Product: libraries
           Version: 1.8
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Transformation Utilities
        AssignedTo: sabre at nondot.org
        ReportedBy: sabre at nondot.org


Nick Lewycky reported that dominators we're getting updated for this .ll file correctly:

declare void %use1(int)

void %f(int %i, bool %c) {
entry:
  %A = seteq int %i, 0
  br bool %A, label %brtrue, label %brfalse

brtrue:
  %B = phi bool [ true, %brtrue ], [ false, %entry ]
  call void %use1(int %i)
  br bool %B, label %brtrue, label %brfalse

brfalse:
  call void %use1(int %i)
  ret void
}


Correct is:

Inorder Dominator Tree:
  [1]  %entry
    [2]  %entry.brfalse_crit_edge
    [2]  %entry.brtrue_crit_edge
      [3]  %brtrue
        [4]  %brtrue.brfalse_crit_edge
        [4]  %brtrue.brtrue_crit_edge
    [2]  %brfalse

Computed is:

Inorder Dominator Tree:
  [1]  %entry
    [2]  %brtrue
      [3]  %brtrue.brtrue_crit_edge
      [3]  %brtrue.brfalse_crit_edge
    [2]  %brfalse
    [2]  %entry.brtrue_crit_edge
    [2]  %entry.brfalse_crit_edge

BCE assumes that the broken edge block can never dominate anything, which is incorrect in this case.

-Chris



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Tue Oct  3 02:03:13 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 3 Oct 2006 02:03:13 -0500
Subject: [LLVMbugs] [Bug 932] Break Critical Edges pass doesn't update
	dominators right in some cases
Message-ID: <200610030703.k9373DsO014266@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=932

sabre at nondot.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
           Keywords|                            |code-quality
         Resolution|                            |FIXED



------- Additional Comments From sabre at nondot.org  2006-10-03 02:03 -------
Fixed. Testcase here: Analysis/Dominators/2006-10-02-BreakCritEdges.ll

Patch/analysis here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20061002/038237.html

-Chris



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Tue Oct  3 02:21:29 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 3 Oct 2006 02:21:29 -0500
Subject: [LLVMbugs] [Bug 929] livevars takes 50% of codegen time (N^2
	algorithm?)
Message-ID: <200610030721.k937LTKp023153@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=929

isanbard at gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED



------- Additional Comments From isanbard at gmail.com  2006-10-03 02:21 -------
Fixed:

http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20061002/038239.html
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20061002/038238.html

Before:

$ llvm.obj/Debug/bin/llc interpret.bc -time-passes -f -fast
===-------------------------------------------------------------------------===
                      ... Pass execution timing report ...
===-------------------------------------------------------------------------===
  Total Execution Time: 81.9564 seconds (150.8072 wall clock)

   ---User Time---   --System Time--   --User+System--   ---Wall Time---  --- Name ---
  37.2380 ( 46.0%)   0.4395 ( 40.1%)  37.6775 ( 45.9%)  78.9992 ( 52.3%)  Live Variable Analysis
   7.1519 (  8.8%)   0.2003 ( 18.3%)   7.3523 (  8.9%)  20.3752 ( 13.5%)  X86 DAG->DAG Instruction 
Selection
   9.9280 ( 12.2%)   0.2185 ( 19.9%)  10.1466 ( 12.3%)  18.4788 ( 12.2%)  Eliminate PHI nodes for 
register allocation

After:

llvm.obj/Debug/bin/llc interpret.bc -time-passes -f -fast
===-------------------------------------------------------------------------===
                      ... Pass execution timing report ...
===-------------------------------------------------------------------------===
  Total Execution Time: 46.5941 seconds (78.4110 wall clock)

   ---User Time---   --System Time--   --User+System--   ---Wall Time---  --- Name ---
  14.2680 ( 31.1%)   0.1674 ( 19.7%)  14.4354 ( 30.9%)  23.9314 ( 30.5%)  Linear Scan Register Allocator
  10.0606 ( 21.9%)   0.2507 ( 29.5%)  10.3114 ( 22.1%)  17.3218 ( 22.0%)  Eliminate PHI nodes for 
register allocation
   9.8416 ( 21.5%)   0.1711 ( 20.1%)  10.0128 ( 21.4%)  16.7627 ( 21.3%)  Live Interval Analysis




------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Tue Oct  3 06:49:35 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 3 Oct 2006 06:49:35 -0500
Subject: [LLVMbugs] [Bug 933] NEW: llc -enable-x86-fastcc bugpoint gives
	"Unknown type!" assertion
Message-ID: <200610031149.k93BnZk0029258@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=933

           Summary: llc -enable-x86-fastcc bugpoint gives "Unknown type!"
                    assertion
           Product: tools
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: blocker
          Priority: P2
         Component: llc
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: eric at vanrietpaap.nl


llc -enable-x86-fastcc bugpoint-reduced-simplified.bc -f -o bugpoint-reduced-simplified.s

llc: X86ISelLowering.cpp:1495: llvm::SDOperand llvm::X86TargetLowering::LowerFastCCArguments
(llvm::SDOperand, llvm::SelectionDAG&): Assertion `0 && "Unknown type!"' failed.
llc((anonymous namespace)::PrintStackTrace()+0x1f)[0x852c01f]
/lib/libc.so.6(abort+0xeb)[0xb7dc10f3]
/lib/libc.so.6(__assert_fail+0xeb)[0xb7db94af]
llc(llvm::X86TargetLowering::LowerFastCCArguments(llvm::SDOperand, llvm::SelectionDAG&)+0x98b)
[0x821d72b]
./REDUCED_CRASH: line 1: 27102 Aborted                 llc -enable-x86-fastcc bugpoint-reduced-
simplified.bc -f -o bugpoint-reduced-simplified.s



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Tue Oct  3 09:48:53 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 3 Oct 2006 09:48:53 -0500
Subject: [LLVMbugs] [Bug 934] NEW: 'explicit' keyword @ ctor fixes in
	Instructions.h
Message-ID: <200610031448.k93EmrKR032352@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=934

           Summary: 'explicit' keyword @ ctor fixes in Instructions.h
           Product: libraries
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: trivial
          Priority: P2
         Component: Core LLVM classes
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: baraclese at googlemail.com


Just some 'explicit' ctor fixes.



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Tue Oct  3 12:12:14 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 3 Oct 2006 12:12:14 -0500
Subject: [LLVMbugs] [Bug 934] 'explicit' keyword @ ctor fixes in
	Instructions.h
Message-ID: <200610031712.k93HCEGe002308@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=934

sabre at nondot.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED



------- Additional Comments From sabre at nondot.org  2006-10-03 12:12 -------
Patch applied:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20061002/038244.html

Thanks!

-Chris




------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Tue Oct  3 12:20:24 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 3 Oct 2006 12:20:24 -0500
Subject: [LLVMbugs] [Bug 933] X86 -enable-x86-fastcc crash on functions
	returning bool
Message-ID: <200610031720.k93HKOP4002610@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=933

sabre at nondot.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
          Component|llc                         |Backend: X86
           Keywords|                            |compile-fail
         OS/Version|Linux                       |All
            Product|tools                       |libraries
           Platform|PC                          |All
         Resolution|                            |FIXED
            Summary|llc -enable-x86-fastcc      |X86 -enable-x86-fastcc crash
                   |bugpoint gives "Unknown     |on functions returning bool
                   |type!" assertion            |
   Target Milestone|---                         |1.9



------- Additional Comments From sabre at nondot.org  2006-10-03 12:20 -------
Fixed.?? Testcase here:??CodeGen/X86/2006-10-02-BoolRetCrash.ll

Patch here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20061002/038246.html

Thanks!

One note though: -enable-x86-fastcc has a couple of problems, and doesn't always necessarily speed up 
the code.?? Use it with care. :)

-Chris



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Tue Oct  3 13:47:01 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 3 Oct 2006 13:47:01 -0500
Subject: [LLVMbugs] [Bug 935] NEW: Loop optimization deficiencies
Message-ID: <200610031847.k93Il1rm004138@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=935

           Summary: Loop optimization deficiencies
           Product: libraries
           Version: 1.5
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Scalar Optimizations
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: sabre at nondot.org


Consider these nested loops:

void foo(unsigned char *ptr, unsigned r, unsigned g, unsigned b, unsigned h, unsigned w) {
unsigned row, col;

for (row = 0; row < h; row++) {
for (col = 0; col < w; col += 3) { 
ptr[col] = r;
ptr[col+1] = g;
ptr[col+2] = b;
}
}
}

We currently don't rotate the inner loop (bad), though this produces decent X86 code for the inner loop:

        xorl %ebx, %ebx
        jmp LBB1_4      #bb16
LBB1_3: #bb1
        movb %cl, (%edi,%ebx)
        movb %ah, 1(%edi,%ebx)
        movb %al, 2(%edi,%ebx)
        addl $3, %ebx
LBB1_4: #bb16
        cmpl %edx, %ebx
        jb LBB1_3       #bb1

For PowerPC though, we're getting an extra IV:

        li r9, 0
        b LBB1_4        ;bb16
LBB1_3: ;bb1
        stbx r4, r3, r9
        add r10, r3, r9
        addi r9, r9, 3
        stb r5, 1(r10)
        stb r6, 2(r10)
LBB1_4: ;bb16
        cmplw cr0, r9, r8
        blt cr0, LBB1_3 ;bb1

Further, the use of postinc addressing modes would eliminate the need for *any* adds in the loop.

-Chris



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Wed Oct  4 11:33:52 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 4 Oct 2006 11:33:52 -0500
Subject: [LLVMbugs] [Bug 936] NEW: MultiSource/Applications/viterbi slow on
	X86/PPC with LLC
Message-ID: <200610041633.k94GXqLQ003235@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=936

           Summary: MultiSource/Applications/viterbi slow on X86/PPC with
                    LLC
           Product: libraries
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Common Code Generator Code
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: sabre at nondot.org


The X86 LLC ratio for viterbi is .75, the CBE ratio is 1.0.
The PPC LLC ratio for viterbi is .74, the CBE ratio is 0.96

We need to find out why native X86/PPC is 25% slower than the CBE or GCC.

-Chris



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Thu Oct  5 17:52:17 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 5 Oct 2006 17:52:17 -0500
Subject: [LLVMbugs] [Bug 937] NEW: SelectionDAGLowering does not support
	frndint instruction (in inline asm)
Message-ID: <200610052252.k95MqHEA032752@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=937

           Summary: SelectionDAGLowering does not support frndint
                    instruction (in inline asm)
           Product: libraries
           Version: trunk
          Platform: All
        OS/Version: Linux
            Status: NEW
          Severity: major
          Priority: P2
         Component: Backend: X86
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: pmeredit at uiuc.edu


The problem is that frndint casts the top of the 8087 floating point stack to 
an integer.  I have been told the SelectionDAGLowering does not support the 
8087 stack.  This is fairly serious because frndint is included in math.h's 
floor function, via inclusion through the system specific mathinlines.h.  Thus, 
any program that uses floor (from math.h) on an x86 platform will crash during 
native codegen or JIT'ing.



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Thu Oct  5 17:53:49 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 5 Oct 2006 17:53:49 -0500
Subject: [LLVMbugs] [Bug 937] SelectionDAGLowering does not support frndint
	instruction (in inline asm)
Message-ID: <200610052253.k95Mrnp8000334@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=937

sabre at nondot.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |DUPLICATE



------- Additional Comments From sabre at nondot.org  2006-10-05 17:53 -------
This is a straight duplicate of PR879.?? Patches welcome.

-Chris


*** This bug has been marked as a duplicate of 879 ***



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Sat Oct  7 16:12:00 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 7 Oct 2006 16:12:00 -0500
Subject: [LLVMbugs] [Bug 938] NEW: Lack of inline asm support
Message-ID: <200610072112.k97LC0r0006832@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=938

           Summary: Lack of inline asm support
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Common Code Generator Code
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: asl at math.spbu.ru


Just try to run the attached .bc with llc.



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Sat Oct  7 17:04:36 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 7 Oct 2006 17:04:36 -0500
Subject: [LLVMbugs] [Bug 939] NEW: LLC segfaults
Message-ID: <200610072204.k97M4abl007741@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=939

           Summary: LLC segfaults
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Backend: X86
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: asl at math.spbu.ru


llc segfaults on the attached bytecode. Running llc -debug showed, that it
segfaulted in the list sheduler code.



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Sun Oct  8 14:16:06 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 8 Oct 2006 14:16:06 -0500
Subject: [LLVMbugs] [Bug 940] NEW: X86 load folding bug
Message-ID: <200610081916.k98JG6wk031540@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=940

           Summary: X86 load folding bug
           Product: libraries
           Version: 1.8
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Backend: X86
        AssignedTo: evan.cheng at apple.com
        ReportedBy: sabre at nondot.org


This testcase causes the X86 backend to select a legal dag into an illegal input to the scheduler.  It's a 
"load folding + flag" issue.

This breaks QT.

-Chris

void %_ZN13QFSFileEngine4readEPcx() {
        %tmp201 = load int* null                ; <int> [#uses=1]
        %tmp201 = cast int %tmp201 to long              ; <long> [#uses=1]
        %tmp202 = load long* null               ; <long> [#uses=1]
        %tmp203 = add long %tmp201, %tmp202             ; <long> [#uses=1]
        store long %tmp203, long* null
        ret void
}



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Sun Oct  8 15:27:35 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 8 Oct 2006 15:27:35 -0500
Subject: [LLVMbugs] [Bug 737] [llvmg++4] Code quality issue with gimplified
	array ctor
Message-ID: <200610082027.k98KRZ5o000396@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=737

sabre at nondot.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED



------- Additional Comments From sabre at nondot.org  2006-10-08 15:27 -------
This got fixed somewhere along the way.




------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Sun Oct  8 17:29:29 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 8 Oct 2006 17:29:29 -0500
Subject: [LLVMbugs] [Bug 897] ADT/SmallVector.h violates aliasing rules
Message-ID: <200610082229.k98MTTGt002452@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=897

sabre at nondot.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED



------- Additional Comments From sabre at nondot.org  2006-10-08 17:29 -------
Nicholas, thanks for verifying.

Fixed, patch here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20061002/038404.html

-Chris



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Sun Oct  8 18:32:19 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 8 Oct 2006 18:32:19 -0500
Subject: [LLVMbugs] [Bug 941] NEW: please support TLS
Message-ID: <200610082332.k98NWJSd003736@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=941

           Summary: please support TLS
           Product: tools
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: llvm-gcc
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: nicholas at mxc.ca


LLVM-GCC doesn't yet support thread-local storage. Given the one-line program
"__thread int x;", llvm-gcc emits this error:
  tls.c:1: sorry, unimplemented: thread-local data not supported by LLVM yet!

The extension is described in the GCC manual here:
http://gcc.gnu.org/onlinedocs/gcc/Thread_002dLocal.html



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Sun Oct  8 18:54:20 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 8 Oct 2006 18:54:20 -0500
Subject: [LLVMbugs] [Bug 892] [scalarrepl] Should be able to scalarrepl
	'union's with pointers in them
Message-ID: <200610082354.k98NsKCH004211@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=892

sabre at nondot.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED



------- Additional Comments From sabre at nondot.org  2006-10-08 18:54 -------
Fixed, patches here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20061002/038407.html
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20061002/038409.html

Testcase here:
Transforms/ScalarRepl/union-pointer.ll

-Chris



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Mon Oct  9 12:40:19 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 9 Oct 2006 12:40:19 -0500
Subject: [LLVMbugs] [Bug 886] asmparser doesn't catch invalid code
Message-ID: <200610091740.k99HeJs3018137@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=886

rspencer at x10sys.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED



------- Additional Comments From rspencer at x10sys.com  2006-10-09 12:40 -------
Resolved, patch here:

http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20061009/038418.html




------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Mon Oct  9 12:41:45 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 9 Oct 2006 12:41:45 -0500
Subject: [LLVMbugs] [Bug 895] asmparser doesn't handle undeclared function
	very well
Message-ID: <200610091741.k99HfjG0018187@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=895

rspencer at x10sys.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED



------- Additional Comments From rspencer at x10sys.com  2006-10-09 12:41 -------
The fix for PR886 fixed this one as well.



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Mon Oct  9 15:15:25 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 9 Oct 2006 15:15:25 -0500
Subject: [LLVMbugs] [Bug 894] LTO : avoid using system specific path for tmp
	file
Message-ID: <200610092015.k99KFPYQ021043@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=894

dpatel at apple.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED



------- Additional Comments From dpatel at apple.com  2006-10-09 15:15 -------
Fixed.

http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20061009/038423.html



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Mon Oct  9 20:47:35 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 9 Oct 2006 20:47:35 -0500
Subject: [LLVMbugs] [Bug 940] X86 load folding bug
Message-ID: <200610100147.k9A1lZPi026577@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=940

evan.cheng at apple.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED



------- Additional Comments From evan.cheng at apple.com  2006-10-09 20:47 -------
Fixed in top of tree.



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Tue Oct 10 11:38:17 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 10 Oct 2006 11:38:17 -0500
Subject: [LLVMbugs] [Bug 939] LLC segfaults
Message-ID: <200610101638.k9AGcH5h020767@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=939

evan.cheng at apple.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |DUPLICATE



------- Additional Comments From evan.cheng at apple.com  2006-10-10 11:38 -------
Yep, same as PR940.

*** This bug has been marked as a duplicate of 940 ***



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From babic.domagoj at gmail.com  Tue Oct 10 12:34:45 2006
From: babic.domagoj at gmail.com (Domagoj Babic)
Date: Tue, 10 Oct 2006 10:34:45 -0700
Subject: [LLVMbugs] Smarter bugpoint reduction heuristic
Message-ID: <e3684ba30610101034i19d28790m936ccfc2aae9b2bc@mail.gmail.com>

Modifications:

1) random_shuffle of TheList - decreases the probability of having
two bug causing functions at the opposite ends of a large list, speeds
up the convergence.

2) backtrack with 10% probability from the trimming loop
to the binary search loop - once it finds the problematic
cluster, the remaining functions are eliminated one by one,
which is painfully slow. This probabalistic backtracking enables
the bugpoint to leave the particularly hard search subspace
and attempt more agressive pruning again.

A bug that the previous heuristic couldn't reduce in a week
(after a week it was left with cca 6500 functions, reducing them
one by one...), the new one reduces in 1.5 hours to 4 functions,
and then takes another 2 hours for basic blocks and instructions.

This patch reduces the probability of heavy tails of the distribution,
speeding up the convergence.

Domagoj Babic
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ListReducerPatch.bz2
Type: application/x-bzip2
Size: 1881 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvmbugs/attachments/20061010/a063f3df/attachment.bz2 

From sabre at nondot.org  Tue Oct 10 17:12:49 2006
From: sabre at nondot.org (Chris Lattner)
Date: Tue, 10 Oct 2006 15:12:49 -0700 (PDT)
Subject: [LLVMbugs] Smarter bugpoint reduction heuristic
In-Reply-To: <e3684ba30610101034i19d28790m936ccfc2aae9b2bc@mail.gmail.com>
References: <e3684ba30610101034i19d28790m936ccfc2aae9b2bc@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0610101512260.14542@nondot.org>

On Tue, 10 Oct 2006, Domagoj Babic wrote:
> This patch reduces the probability of heavy tails of the distribution,
> speeding up the convergence.

Applied, thanks! Note that some tabs snuck into the file, please avoid 
these in the future.  I've taken care of the patch, thanks again.

-Chris

-- 
http://nondot.org/sabre/
http://llvm.org/

From babic.domagoj at gmail.com  Wed Oct 11 15:49:49 2006
From: babic.domagoj at gmail.com (Domagoj Babic)
Date: Wed, 11 Oct 2006 13:49:49 -0700
Subject: [LLVMbugs] Bugpoint patch for pruning global initializers
Message-ID: <e3684ba30610111349r3fdcfd82ke22b8ed531e45dfb@mail.gmail.com>

Currently, bugpoint prunes either all global initializers or none.
That's a serious problem if the bug is related to global initializers
and you have almost 50000 initializers (like in my case).

The patch does binary splitting on the set of initializers, and reduces
those 50000 initializers to 1 in a couple of minutes.

Unfortunately, I haven't been able to figure out how to reuse
ListReducer for globals, but the idea is pretty much the same.

Note that the probability of "restarts" (BackjumpProbability) has
to decrease, otherwise there's an exceptionally small probability
of infinite looping.

Domagoj Babic
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CrashDebuggerPatch.bz2
Type: application/x-bzip2
Size: 2084 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvmbugs/attachments/20061011/69a86c2d/attachment.bz2 

From bugzilla-daemon at cs.uiuc.edu  Wed Oct 11 17:47:04 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 11 Oct 2006 17:47:04 -0500
Subject: [LLVMbugs] [Bug 942] NEW: analyze missing-optimization-opportunity
Message-ID: <200610112247.k9BMl4Tl011327@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=942

           Summary: analyze missing-optimization-opportunity
           Product: tools
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: bugpoint
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: nicholas at mxc.ca


I'd like to use bugpoint to isolate the parts of code where we aren't optimizing
as well as gcc (or other reference compiler). The technique is similar to the
miscompilation analysis.

Set a threshold for bugpoint, say, a 5% performance difference. Bugpoint
compiles the program with both LLVM and GCC and times the runs. It then cuts the
program in two, and compiles one half with LLVM, the other with GCC and links
them. If the program runs faster than (5% slower than GCC) then the
missing-optimization-opportunity must be in the GCC compiled half of the code,
else it's in the LLVM compiled half. Continue and isolate.

All the same tricks (loop extraction) can be applied to this too.



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Wed Oct 11 18:48:44 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 11 Oct 2006 18:48:44 -0500
Subject: [LLVMbugs] [Bug 943] NEW: Too much spill code generated after loop
	unrolling
Message-ID: <200610112348.k9BNmiie012495@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=943

           Summary: Too much spill code generated after loop unrolling
           Product: libraries
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Backend: X86
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: isanbard at gmail.com


This code:

int value(uint64 b1, uint64 b2)                                                                                   
{                                                                                                                 
  int i, j, k;                                                                                                    
  int value = 0;                                                                                                  
                                                                                                                  
  for (k = 0; k < 2; k++)                                                                                         
    for (i = 0; i < 6; i++)                                                                                       
      for (j = 0; j < 2; j++)                                                                                     
        if ((b2 & 0xf << (j + i * 6)) == 0xf << (j + i * 6))                                                      
          value += 1000;                                                                                          
                                                                                                                  
  return value;                                                                                                   
}                                                                                                                 

generates too many unnecessary spills/reloads when rerun through the optimizer (at -O2). See "***" 
below:

LBB1_1: #bb17.preheader                                                                                           
        movl $15, %eax                                                                                            
***     movb 39(%esp), %cl                                                                                        
        movl %eax, %edx                                                                                           
        shll %cl, %edx                                                                                            
***     movb 39(%esp), %cl                                                                                        
        incb %cl                                                                                                  
        shll %cl, %eax                                                                                            
        movl %edx, %ecx                                                                                           

The result is that the loop will run slower than if optimizations were turned on only once.



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Wed Oct 11 19:06:38 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 11 Oct 2006 19:06:38 -0500
Subject: [LLVMbugs] [Bug 944] NEW: Unrolling loop creates register pressure
Message-ID: <200610120006.k9C06cQv012796@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=944

           Summary: Unrolling loop creates register pressure
           Product: libraries
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Loop Optimizer
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: isanbard at gmail.com


When run through the optimizer twice, the following code:

int value(uint64 b1, uint64 b2)                                                                                   
{                                                                                                                 
  int i, j, k;                                                                                                    
  int value = 0;                                                                                                  
                                                                                                                  
  for (k = 0; k < 2; k++)                                                                                         
    for (i = 0; i < 6; i++)                                                                                       
      for (j = 0; j < 2; j++)                                                                                     
        if ((b2 & 0xf << (j + i * 6)) == 0xf << (j + i * 6))                                                      
          value += 1000;                                                                                          
                                                                                                                  
  return value;                                                                                                   
}                                                                                                                 

gets unrolled into two loops. However, this creates a ton of register pressure, and, as a result, many 
more spills/loads are added which the code running only through the optimizer once doesn't have.



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Wed Oct 11 21:36:19 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 11 Oct 2006 21:36:19 -0500
Subject: [LLVMbugs] [Bug 943] Too much spill code generated after loop
	unrolling
Message-ID: <200610120236.k9C2aJWV015337@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=943

sabre at nondot.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |minor
             Status|NEW                         |RESOLVED
          Component|Backend: X86                |Common Code Generator Code
           Keywords|                            |code-quality
         OS/Version|MacOS X                     |All
           Platform|Macintosh                   |All
         Resolution|                            |FIXED
   Target Milestone|---                         |1.9



------- Additional Comments From sabre at nondot.org  2006-10-11 21:36 -------
Fixed.  Patch here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20061009/038511.html

The diff of produced code:

--- t.s 2006-10-11 18:57:23.000000000 -0700
+++ t2.s        2006-10-11 19:29:35.000000000 -0700
@@ -22,7 +22,6 @@
        movb 39(%esp), %cl
        movl %eax, %edx
        shll %cl, %edx
-       movb 39(%esp), %cl
        incb %cl
        shll %cl, %eax
        movl %edx, %ecx
@@ -73,7 +72,6 @@
        movb 15(%esp), %cl
        movl %esi, %eax
        shll %cl, %eax
-       movb 15(%esp), %cl
        incb %cl
        shll %cl, %esi
        movl %eax, %ecx


-Chris



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Thu Oct 12 01:42:42 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 12 Oct 2006 01:42:42 -0500
Subject: [LLVMbugs] [Bug 945] NEW: x86 backend doesn't lower x%255 to
	multiply
Message-ID: <200610120642.k9C6ggat019158@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=945

           Summary: x86 backend doesn't lower x%255 to multiply
           Product: libraries
           Version: 1.8
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Backend: X86
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: sabre at nondot.org


Consider:

int test(int X) {
  return X%255;
}

The PPC backend lowers this to mulhw+stuff, the X86 backend should too.  It is the major reason we are 
slower at Benchmarks/Misc/ReedSolomon.c than GCC.

-Chris



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Thu Oct 12 11:03:51 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 12 Oct 2006 11:03:51 -0500
Subject: [LLVMbugs] [Bug 946] NEW: New boot strap failure for llvm-gcc4
Message-ID: <200610121603.k9CG3pkZ007061@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=946

           Summary: New boot strap failure for llvm-gcc4
           Product: tools
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: llvm-gcc
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: alenhar2 at uiuc.edu


This is the reduction on alpha.  Is this that llvm-gcc started expecting va_list
to be a simple type (not a structure)?

 typedef __builtin_va_list __gnuc_va_list;
  typedef __gnuc_va_list va_list;
  __gcov_execl (const char *path, const char *arg, ...) {
   va_list ap, aq;
   __builtin_va_copy(aq,ap);
 }



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Thu Oct 12 16:00:23 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 12 Oct 2006 16:00:23 -0500
Subject: [LLVMbugs] [Bug 945] x86 backend doesn't lower x%255 to multiply
Message-ID: <200610122100.k9CL0NPF029816@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=945

sabre at nondot.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
          Component|Backend: X86                |Common Code Generator Code
           Keywords|                            |code-quality
         Resolution|                            |FIXED
   Target Milestone|---                         |1.9
            Version|1.8                         |1.0



------- Additional Comments From sabre at nondot.org  2006-10-12 16:00 -------
Fixed.?? Patch here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20061009/038537.html

Testcase here: Regression/CodeGen/X86/rem.ll

llc is now faster than GCC on reedsolomon.c.

-Chris




------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Sun Oct 15 18:34:00 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 15 Oct 2006 18:34:00 -0500
Subject: [LLVMbugs] [Bug 947] NEW: llvm-gcc missing address of label
Message-ID: <200610152334.k9FNY0lM030694@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=947

           Summary: llvm-gcc missing address of label
           Product: tools
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: llvm-gcc
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: nicholas at mxc.ca


Taking the address of a label doesn't seem to be supported in llvm-gcc4. This
GCC extension is described in
http://gcc.gnu.org/onlinedocs/gcc-4.0.2/gcc/Labels-as-Values.html . This is the
program:

  void foo() {
    void *ptr;
  label:
    ptr = &&label;
  }

$ llvm-gcc gotolabel.c
Unhandled lvalue expression!
 <label_decl 0x55a6fd98 label
    type <void_type 0x55a26708 void sizes-gimplified VOID
        align 8 symtab 145740416 alias set -1
        pointer_to_this <pointer_type 0x55a26780>>
    side-effects used asm-frame-size 0 VOID file gotolabel.c line 4
    align 1 context <function_decl 0x55a6fb40 foo> initial <error_mark 0x55a172d8>
    LLVM: label %label>
gotolabel.c: In function ???foo???:
gotolabel.c:1: internal compiler error: in EmitLV, at llvm-convert.cpp:604
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://llvm.org/bugs> for instructions.

Here's a backtrace:

#0  internal_error (gmsgid=0x890e091 "in %s, at %s:%d")
    at ../../src/gcc/diagnostic.c:532
#1  0x08166d7f in fancy_abort (
    file=0x8953e40 "../../src/gcc/llvm-convert.cpp", line=604, 
    function=0x895eec9 "EmitLV") at ../../src/gcc/diagnostic.c:588
#2  0x0832269b in TreeToLLVM::EmitLV (this=0xffffaee4, exp=0x55a6fd98)
    at ../../src/gcc/llvm-convert.cpp:604
#3  0x083242aa in TreeToLLVM::EmitADDR_EXPR (this=0xffffaee4, exp=0x55a1c230)
    at ../../src/gcc/llvm-convert.cpp:1718
#4  0x0832223d in TreeToLLVM::Emit (this=0xffffaee4, exp=0x55a1c230, 
    DestLoc=0x0) at ../../src/gcc/llvm-convert.cpp:513
#5  0x0833c94b in TreeToLLVM::EmitMODIFY_EXPR (this=0xffffaee4, 
    exp=0x55a1c258, DestLoc=0x0) at ../../src/gcc/llvm-convert.cpp:2055
#6  0x0832210d in TreeToLLVM::Emit (this=0xffffaee4, exp=0x55a1c258, 
    DestLoc=0x0) at ../../src/gcc/llvm-convert.cpp:515
#7  0x0833add3 in TreeToLLVM::EmitSTATEMENT_LIST (this=0xffffaee4, 
    exp=0x55a77690, DestLoc=0x0) at ../../src/gcc/llvm-convert.cpp:1168
#8  0x08322163 in TreeToLLVM::Emit (this=0xffffaee4, exp=0x55a77690, 
    DestLoc=0x0) at ../../src/gcc/llvm-convert.cpp:488
#9  0x0833b948 in TreeToLLVM::EmitBIND_EXPR (this=0xffffaee4, exp=0x55a71068, 
    DestLoc=0x0) at ../../src/gcc/llvm-convert.cpp:1143
#10 0x083220e0 in TreeToLLVM::Emit (this=0xffffaee4, exp=0x55a71068, 
    DestLoc=0x0) at ../../src/gcc/llvm-convert.cpp:487
#11 0x0830e0d3 in llvm_emit_code_for_current_function (fndecl=0x55a6fb40)
    at ../../src/gcc/llvm-backend.cpp:412
#12 0x080dc8bf in tree_rest_of_compilation (fndecl=0x55a6fb40)
    at ../../src/gcc/tree-optimize.c:704
#13 0x0805e3a3 in c_expand_body (fndecl=0x55a6fb40)
    at ../../src/gcc/c-decl.c:6954
#14 0x083819ad in cgraph_expand_function (node=0x55a6fe10)
    at ../../src/gcc/cgraphunit.c:896
#15 0x08381b65 in cgraph_assemble_pending_functions ()
    at ../../src/gcc/cgraphunit.c:313
#16 0x08384165 in cgraph_finalize_function (decl=0x55a6fb40, nested=false)
    at ../../src/gcc/cgraphunit.c:411
#17 0x0805e965 in finish_function () at ../../src/gcc/c-decl.c:6923
#18 0x08054808 in yyparse () at c-parse.y:440
#19 0x080557eb in c_parse_file () at c-parse.y:3483
#20 0x080a5c7a in c_common_parse_file (set_yydebug=0)
    at ../../src/gcc/c-opts.c:1238
#21 0x082e145a in toplev_main (argc=2, argv=0xffffbb34)
    at ../../src/gcc/toplev.c:1100
#22 0x080bb632 in main (argc=1634296879, argv=0x736f6e67)
    at ../../src/gcc/llvm-main.cpp:37



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Sun Oct 15 18:52:57 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 15 Oct 2006 18:52:57 -0500
Subject: [LLVMbugs] [Bug 948] NEW: support transparent LTO on linux
Message-ID: <200610152352.k9FNqv9H030969@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=948

           Summary: support transparent LTO on linux
           Product: tools
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: llvm-gcc
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: nicholas at mxc.ca


llvm-gcc should know to run llvm-ld when linking bytecode files. Specifically,
running "llvm-gcc main.bc aux.bc -o myprog" should produce a native "myprog". It
should also parse and interpret the command-line parameters -O0 to turn on/off
optimization.

This is necessary to use llvm-gcc with LTO with an autoconf based package.



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Tue Oct 17 10:43:03 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 17 Oct 2006 10:43:03 -0500
Subject: [LLVMbugs] [Bug 949] NEW: -enable-llcbeta does nothing
Message-ID: <200610171543.k9HFh3QZ022936@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=949

           Summary: -enable-llcbeta does nothing
           Product: Test Suite
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Nightly Tester
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: rspencer at x10sys.com


Currently the nightly tester's option -enable-llcbeta doesn't do anything. You
get the llcbeta test whether you use this option or not.  While it is probably a
reasonable default to have llcbeta turned on by default, there should be a way
to turn it off. 

I would prefer that the llcbeta was on by default and a -disable-llcbeta option
was provided, similar to -disable-jit, -disable-cbe, etc.



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Tue Oct 17 10:52:05 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 17 Oct 2006 10:52:05 -0500
Subject: [LLVMbugs] [Bug 950] NEW: Signless Types For LLVM
Message-ID: <200610171552.k9HFq5Xn025314@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=950

           Summary: Signless Types For LLVM
           Product: libraries
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: Core LLVM classes
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: rspencer at x10sys.com


Despite our best attempts, the LLVM type system somehow ended up too
high-level.  No! How can it be so?  Let me tell you.

The LLVM primitive integer types maintain a distinction between signed
and unsigned, when all we really want to know is the size of the data.  This
extra information bloats the .bc files and in-memory IR with "noop" casts 
(like int -> uint) and causes there to be redundancy in the LLVM language.
This redundancy in the language currently leads to horrible missed optimization
opportunities (particular in the indvars pass), but can even miss trivial
cases (i.e. not CSE'ing  (X+4) with ((unsigned)X + 4), which produce the same
value).  Another annoying thing is that 'int 1' and 'uint 1' both need to be
written out to the .bc file, which is more duplication and takes space.

As a side note, we also have three trivial bits of ugliness:
  1. we have an "SByte" type, but none of the other signed types are prefixed
     with S.
  2. Using C names like "int" and "long" make people think that LLVM types
     vary in size like C types do, depending on the target.
  3. Using all C names leads people think our type system is the same as C's,
     which is obviously untrue, but still people think that.

You can read more about this feature in Chris Lattner's LLVM Notes, at
http://nondot.org/~sabre/LLVMNotes/TypeSystemChanges.txt.

Since this is a fairly extensive change to LLVM, this bug will be used to track
the progress of the work as it proceeds.



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Tue Oct 17 13:52:07 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 17 Oct 2006 13:52:07 -0500
Subject: [LLVMbugs] [Bug 951] NEW: Corrupt Stack in SSE Test Failures ?
Message-ID: <200610171852.k9HIq7Ru030270@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=951

           Summary: Corrupt Stack in SSE Test Failures ?
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Backend: X86
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: rspencer at x10sys.com


Two of the SSE tests fail on Linux with a SEGV. The output is this:

/proj/llvm/llvm/projects/llvm-test/RunSafely.sh 500 /dev/null
Output/sse.stepfft.out-llc Output/sse.stepfft.llc
(no debugging symbols found)
Using host libthread_db library "/lib/libthread_db.so.1".
(no debugging symbols found)
Core was generated by `Output/sse.stepfft.llc'.
Program terminated with signal 11, Segmentation fault.

warning: svr4_current_sos: Can't read pathname for load map: Input/output error

(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
#0  0x0804871e in .BB1_13 ()
#0  0x0804871e in .BB1_13 ()
#1  0x00000000 in ?? ()

Nearly identical results (the stack dump is different) occur for JIT. The JIT
test also produces this:
Previous frame inner to this frame (corrupt stack?)

Possibly the stack is getting corrupted?



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Tue Oct 17 14:02:14 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 17 Oct 2006 14:02:14 -0500
Subject: [LLVMbugs] [Bug 946] New boot strap failure for llvm-gcc4
Message-ID: <200610171902.k9HJ2Ecc005659@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=946

sabre at nondot.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
           Keywords|                            |compile-fail
           Platform|PC                          |DEC
         Resolution|                            |FIXED
   Target Milestone|---                         |1.9



------- Additional Comments From sabre at nondot.org  2006-10-17 14:02 -------
Fixed, patch here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20061016/038653.html

Andrew, if you have a testcase, please add it to Regression/CFrontend.

Thanks,

-Chris




------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Tue Oct 17 15:30:10 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 17 Oct 2006 15:30:10 -0500
Subject: [LLVMbugs] [Bug 952] NEW: Incorrect linkage set
Message-ID: <200610172030.k9HKUAcD028052@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=952

           Summary: Incorrect linkage set
           Product: tools
           Version: trunk
          Platform: PC
        OS/Version: Windows 2000
            Status: NEW
          Severity: normal
          Priority: P2
         Component: llvm-g++
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: asl at math.spbu.ru


The attached cpp code caused incorrect linkage set for mingw32 target. Also this
issues breaks libstdc++ on mingw32.

In general: there is (generally speaking) no weak linkage on mingw32, just only
linkonce. llvm-gcc currently marks symbols as "weak", not "linkonce".

Linkonce linkage support for mingw32 target has been recently added to LLVM x86
Backend.

2 generated assembler outputs are also attached: native g++ (good), llvm-g++ (bad).



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Wed Oct 18 00:29:28 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 18 Oct 2006 00:29:28 -0500
Subject: [LLVMbugs] [Bug 952] Incorrect linkage set
Message-ID: <200610180529.k9I5TSK7002554@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=952

asl at math.spbu.ru changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID



------- Additional Comments From asl at math.spbu.ru  2006-10-18 00:29 -------
I was wrong mixind linkage at LLVM side and gcc\binutils side in my mind.
Symbols should be "weak" LLVM linkage, but AsmPrint'ed in ".linkonce" section.



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Wed Oct 18 03:02:35 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 18 Oct 2006 03:02:35 -0500
Subject: [LLVMbugs] [Bug 953] NEW: A bug + a fix in InstructionCombining
Message-ID: <200610180802.k9I82Z5I013805@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=953

           Summary: A bug + a fix in InstructionCombining
           Product: libraries
           Version: 1.8
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: minor
          Priority: P2
         Component: Scalar Optimizations
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: gil.dogon at mobileye.com


First I'd like to introduce myself.

I am an employee of MobileEye company, and we are using LLVM in order to compile
'C' code for a proprietary chip architceture. Generaly we are very happy with
LLVM  and we managed to have a little nice environment, including a debugger up
and running. During the developement ww stumbled upon the following bug:

we are using gccas explicitly and a short program to demonstarte the bug as
follows :

int t(int a,int b)
{
    return ((a&1) != 0)  != (b != 0);
}

runing gcc4.0 front end with no optimizations :

1360 tirana ~/VMPCompiler/VMP-gcc4> llvm-gcc --emit-llvm -S a.c -o a.s
1361 tirana ~/VMPCompiler/VMP-gcc4> cat a.s

; ModuleID = 'a.c'
target endian = little
target pointersize = 32
target triple = "i686-pc-linux-gnu"

implementation   ; Functions:

int %t(int %a, int %b) {
entry:
        %a_addr = alloca int            ; <int*> [#uses=2]
        %b_addr = alloca int            ; <int*> [#uses=2]
        %retval = alloca int, align 4           ; <int*> [#uses=2]
        %tmp = alloca int, align 4              ; <int*> [#uses=2]
        "alloca point" = cast int 0 to int              ; <int> [#uses=0]
        store int %a, int* %a_addr
        store int %b, int* %b_addr
        %tmp = load int* %a_addr                ; <int> [#uses=1]
        %tmp1 = and int %tmp, 1         ; <int> [#uses=1]
        %tmp1 = cast int %tmp1 to bool          ; <bool> [#uses=1]
        %tmp2 = load int* %b_addr               ; <int> [#uses=1]
        %tmp = setne int %tmp2, 0               ; <bool> [#uses=1]
        %tmp3 = xor bool %tmp1, %tmp            ; <bool> [#uses=1]
        %tmp3 = cast bool %tmp3 to int          ; <int> [#uses=1]
        store int %tmp3, int* %tmp
        %tmp4 = load int* %tmp          ; <int> [#uses=1]
        store int %tmp4, int* %retval
        br label %return

return:         ; preds = %entry
        %retval = load int* %retval             ; <int> [#uses=1]
        ret int %retval
}

<

declare int %printf(sbyte*, ...)

Gets us a correct program . However after optimizing it with gccas
the bug appears :

< 1386 tirana ~/VMPCompiler/VMP-gcc4> gccas a.s -o a.o
< 1389 tirana ~/VMPCompiler/VMP-gcc4> llvm-dis a.o -f -o a.ll
< 1390 tirana ~/VMPCompiler/VMP-gcc4> cat a.ll
; ModuleID = 'a.o'
target endian = little
target pointersize = 32
target triple = "i686-pc-linux-gnu"

implementation   ; Functions:

int %t(int %a, int %b) {
entry:
        %tmp1 = setne int %a, 0         ; <bool> [#uses=1]
        %tmp = setne int %b, 0          ; <bool> [#uses=1]
        %tmp3 = xor bool %tmp, %tmp1            ; <bool> [#uses=1]
        %tmp3 = cast bool %tmp3 to int          ; <int> [#uses=1]
        ret int %tmp3
}

As you can see this code is a bit too optimized and the and operation (a&1)
has been discarded.

I have chased down the bug and found the culprit is at the function 
SimplifyDemandedBits in InstructionCombining.cpp . In there the case of
cast from int to boolean is treated incorrectly as plain truncation.
where in fact a zero comparison is needed.

The following code snippet includes the bugfix:

 case Instruction::Cast: {
    const Type *SrcTy = I->getOperand(0)->getType();
    if (!SrcTy->isIntegral()) return false;

    //
    //  GD : Bugfix: Cast from non-bool to bool require all the sources bits as
    //               it is not just a truncation ...
    //
    //if (I->getType() == Type::BoolTy && SrcTy != Type::BoolTy) return false;

    // If this is an integer truncate or noop, just look in the input.

    if (SrcTy->getPrimitiveSizeInBits() >=
        I->getType()->getPrimitiveSizeInBits()) {
      if (SimplifyDemandedBits(I->getOperand(0), DemandedMask,
                               KnownZero, KnownOne, Depth+1))
        return true;
      assert((KnownZero & KnownOne) == 0 && "Bits known to be one AND zero?");
      break;
    }

I think this bug is rather rare because most of the time llvm does not generate
casts from int to boolean at the first place but have an expilit comparison.



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Wed Oct 18 10:42:26 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 18 Oct 2006 10:42:26 -0500
Subject: [LLVMbugs] [Bug 954] NEW: Another llvm-gcc boot strap failure
Message-ID: <200610181542.k9IFgQrL021634@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=954

           Summary: Another llvm-gcc boot strap failure
           Product: tools
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: llvm-gcc
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: alenhar2 at uiuc.edu


The following reduction:
struct _Refcount_Base   {
  long unsigned int _M_ref_count;
  int _M_ref_count_lock;
  _Refcount_Base(long unsigned int __n) : _M_ref_count(__n) {}
  _Refcount_Base() : _M_ref_count(0) {}
};

struct _Rope_RopeRep : public _Refcount_Base 
{
public:
  int _M_tag:8; 
};

int foo(_Rope_RopeRep* r) { return r->_M_tag; }


causes llvm-gcc to die with:
cc1plus: ../../source/gcc/llvm-convert.cpp:3863: LValue
TreeToLLVM::EmitLV_COMPONENT_REF(tree_node*): Assertion `ByteAlignment*8 <
LLVMValueBitSize && "Unknown overlap case!"' failed.

stack trace:
#6  0x0000000120827d94 in TreeToLLVM::EmitLV_COMPONENT_REF (this=0x11ffff6c0,
exp=0x200005c44b0)
    at ../../source/gcc/llvm-convert.cpp:3863
#7  0x00000001207f8840 in TreeToLLVM::EmitLV (this=0x11ffff6c0,
exp=0x200005c44b0) at ../../source/gcc/llvm-convert.cpp:614
#8  0x0000000120804f38 in TreeToLLVM::EmitLoadOfLValue (this=0x11ffff6c0,
exp=0x200005c44b0, DestLoc=0x0)
    at ../../source/gcc/llvm-convert.cpp:1659
#9  0x00000001207f7cd8 in TreeToLLVM::Emit (this=0x11ffff6c0, exp=0x200005c44b0,
DestLoc=0x0)
    at ../../source/gcc/llvm-convert.cpp:510
#10 0x00000001208080a4 in TreeToLLVM::EmitMODIFY_EXPR (this=0x11ffff6c0,
exp=0x200004e0438, DestLoc=0x0)
    at ../../source/gcc/llvm-convert.cpp:2032
#11 0x00000001207f7d60 in TreeToLLVM::Emit (this=0x11ffff6c0, exp=0x200004e0438,
DestLoc=0x0)
    at ../../source/gcc/llvm-convert.cpp:515
#12 0x00000001207fe690 in TreeToLLVM::EmitSTATEMENT_LIST (this=0x11ffff6c0,
exp=0x200005b3f80, DestLoc=0x0)
    at ../../source/gcc/llvm-convert.cpp:1168
#13 0x00000001207f7bf0 in TreeToLLVM::Emit (this=0x11ffff6c0, exp=0x200005b3f80,
DestLoc=0x0)
    at ../../source/gcc/llvm-convert.cpp:488
#14 0x00000001207fe490 in TreeToLLVM::EmitBIND_EXPR (this=0x11ffff6c0,
exp=0x200005c4500, DestLoc=0x0)
    at ../../source/gcc/llvm-convert.cpp:1143
#15 0x00000001207f7bcc in TreeToLLVM::Emit (this=0x11ffff6c0, exp=0x200005c4500,
DestLoc=0x0)
    at ../../source/gcc/llvm-convert.cpp:487
#16 0x00000001207d408c in llvm_emit_code_for_current_function
(fndecl=0x200005cae00) at ../../source/gcc/llvm-backend.cpp:411
#17 0x000000012035ec70 in tree_rest_of_compilation (fndecl=0x200005cae00) at
../../source/gcc/tree-optimize.c:704
#18 0x000000012021c3c0 in expand_body (fn=0x200005cae00) at
../../source/gcc/cp/semantics.c:3006
#19 0x00000001208aa7d4 in cgraph_expand_function (node=0x200005cb0a0) at
../../source/gcc/cgraphunit.c:896
#20 0x00000001208ada5c in cgraph_expand_all_functions () at
../../source/gcc/cgraphunit.c:1812
#21 0x00000001208adfac in cgraph_optimize () at ../../source/gcc/cgraphunit.c:1909
#22 0x000000012014cc90 in cp_finish_file () at ../../source/gcc/cp/decl2.c:3126
#23 0x000000012000e9e4 in finish_file () at ../../source/gcc/cp/cp-lang.c:113
#24 0x00000001202f4868 in c_common_parse_file (set_yydebug=0) at
../../source/gcc/c-opts.c:1239
#25 0x000000012075b868 in compile_file () at ../../source/gcc/toplev.c:1100
#26 0x000000012075ecc8 in do_compile () at ../../source/gcc/toplev.c:2327
#27 0x000000012075ed80 in toplev_main (argc=24, argv=0x11ffffa88) at
../../source/gcc/toplev.c:2359
#28 0x0000000120311624 in main (argc=24, argv=0x11ffffa88) at
../../source/gcc/llvm-main.cpp:37


Random bits from gdb:
call debug_tree(FieldDecl)
 <field_decl 0x200005ca700 _M_tag
    type <integer_type 0x200004ea620 int public SI
        size <integer_cst 0x200004d27e0 constant invariant 32>
        unit size <integer_cst 0x200004d2300 constant invariant 4>
        align 32 symtab 561522016 alias set -1 precision 32 min <integer_cst
0x200004d2750 -2147483648> max <integer_cst 0x200004d2780 2147483647>
        pointer_to_this <pointer_type 0x200004ff880>>
    used nonlocal asm-frame-size 0 nonaddressable decl_3 decl_4 QI file min.ii
line 11
    size <integer_cst 0x200004d23f0 type <integer_type 0x200004ea0e0
bit_size_type> constant invariant 8>
    unit size <integer_cst 0x200004d2420 type <integer_type 0x200004ea000 long
unsigned int> constant invariant 1>
    align 8 offset_align 128
    offset <integer_cst 0x200004d2330 type <integer_type 0x200004ea000 long
unsigned int> constant invariant 0>
    bit offset <integer_cst 0x200004d3620 type <integer_type 0x200004ea0e0
bit_size_type> constant invariant 96> context <record_type 0x200005ca2a0
_Rope_RopeRep> arguments <integer_cst 0x200004d2330 0> result <integer_type
0x200004ea620 int>
    LLVM: uint 0 chain <type_decl 0x200005ca540 _Rope_RopeRep>>


(gdb) print ByteAlignment
$1 = 4
(gdb) print LLVMValueBitSize
$2 = 32
(gdb) print BitStart
$3 = 96
(gdb) print BitfieldSize
$4 = 8
LLVMFieldTy: { ulong, int }
FieldTy: uint



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Wed Oct 18 12:40:28 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 18 Oct 2006 12:40:28 -0500
Subject: [LLVMbugs] [Bug 953] A bug + a fix in InstructionCombining
Message-ID: <200610181740.k9IHeSX1023802@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=953

sabre at nondot.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |DUPLICATE



------- Additional Comments From sabre at nondot.org  2006-10-18 12:40 -------
Thank you for the bug report!  This bug has already been fixed in mainline CVS.  The code currently 
looks like:

    const Type *SrcTy = I->getOperand(0)->getType();
    if (!SrcTy->isIntegral()) return false;
    
    // If this is an integer truncate or noop, just look in the input.
    if (SrcTy->getPrimitiveSizeInBits() >= 
        I->getType()->getPrimitiveSizeInBits()) {
      // Cast to bool is a comparison against 0, which demands all bits.  We
      // can't propagate anything useful up.
      if (I->getType() == Type::BoolTy)
        break;
      
      if (SimplifyDemandedBits(I->getOperand(0), DemandedMask,
                               KnownZero, KnownOne, Depth+1))
        return true;
      assert((KnownZero & KnownOne) == 0 && "Bits known to be one AND zero?"); 
      break;
    }

Your example now compiles into:

int %t(int %a, int %b) {
entry:
        %tmp1 = and int %a, 1           ; <int> [#uses=1]
        %tmp1 = setne int %tmp1, 0              ; <bool> [#uses=1]
        %tmp = setne int %b, 0          ; <bool> [#uses=1]
        %tmp3 = xor bool %tmp1, %tmp            ; <bool> [#uses=1]
        %tmp3 = cast bool %tmp3 to int          ; <int> [#uses=1]
        ret int %tmp3
}

While this happened to already be fixed, we welcome any bug reports for things you run into in the 
future.

-Chris

-Chris


*** This bug has been marked as a duplicate of 913 ***



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Wed Oct 18 12:59:50 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 18 Oct 2006 12:59:50 -0500
Subject: [LLVMbugs] [Bug 955] NEW: setjmp issue causes siod test to fail
Message-ID: <200610181759.k9IHxoEY024138@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=955

           Summary: setjmp issue causes siod test to fail
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Backend: C
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: rspencer at x10sys.com


The CBE isn't handling _setjmp correctly. The CBE output is #including
<setjmp.h> and declaring its own prototype for _setjmp. The prototype
declarations differ because the structures passed differ in shape. This
apparently only affects Linux as siod CBE compiles correctly on Darwin.



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Wed Oct 18 17:48:13 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 18 Oct 2006 17:48:13 -0500
Subject: [LLVMbugs] [Bug 956] NEW: Vectors don't display correctly when in a
	struct.
Message-ID: <200610182248.k9IMmDvO031350@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=956

           Summary: Vectors don't display correctly when in a struct.
           Product: Runtime Libraries
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P2
         Component: other
        AssignedTo: jlaskey at apple.com
        ReportedBy: jlaskey at apple.com


In the enclosed example, run gdb, break on VectorBug.c:18, run and the print buffer.  Will get a 
"Unexpected type (2) encountered for integer constant." error message.



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Thu Oct 19 13:33:02 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 19 Oct 2006 13:33:02 -0500
Subject: [LLVMbugs] [Bug 957] NEW: Predicate simplifier causes
	libgcc/_udivdi3_s miscompilation
Message-ID: <200610191833.k9JIX2Zv026997@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=957

           Summary: Predicate simplifier causes libgcc/_udivdi3_s
                    miscompilation
           Product: libraries
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: critical
          Priority: P2
         Component: Scalar Optimizations
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: evan.cheng at apple.com


Without predsimplify pass:

LBB1_18:        #cond_false179
        testl %ebp, %ebp
        jne LBB1_20     #cond_next185
LBB1_19:        #cond_true182
        movl $1, %eax
        xorl %edx, %edx
        divl %ebp
        movl %eax, %ebp
LBB1_20:        #cond_next185
        cmpl $65535, %ebp
        ja LBB1_24      #cond_false199

The divl is properly guarded to prevent divide by zero.

With -predsimplify:

LBB1_25:        #cond_true182
        xorl %edx, %edx
        movl $1, %eax
        divl %edx
        movl %eax, %ebp
LBB1_26:        #cond_next185
        cmpl $65535, %ebp
        ja LBB1_30      #cond_false199

That's guaranteed to cause an divide by zero exception!



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Thu Oct 19 17:20:29 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 19 Oct 2006 17:20:29 -0500
Subject: [LLVMbugs] [Bug 958] NEW: case branch tables: as complains "complex
	expression, absolute segment assumed"
Message-ID: <200610192220.k9JMKTIw031422@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=958

           Summary: case branch tables: as complains "complex expression,
                    absolute segment assumed"
           Product: tools
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: blocker
          Priority: P2
         Component: llvm-gcc
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: scottm at aero.org


Not sure if the problem is with the assembler or if it is a gcc frontend issue.
However, for gcc/config/darwin-crt3.c:run_routines as well as numerous messages
from compiling gcc/unwind-dw2-fde.c, it's clear that case statements are a
problem. I've attached a patch to work around this issue for the time being to
get a working front end, but clearly this will be an issue.

The version of as installed on my Mac OS 10.4.8 system reports itself as "Apple
Computer, Inc. version cctools-590.18.obj~10, GNU assembler version 1.38" (which
may be the problem, but it's also an issue on 10.3.9 systems too.)

The as statements look like:

LBB8_8:	;bb17

; ...

LBB8_11:	;bb22

; ...

	blr
	.align	2
	.set L8_0_set_8,LBB8_8-LJTI8_0      ; "complex expression, absolute segment
assumed"
	.set L8_0_set_11,LBB8_11-LJTI8_0    ; "complex expression, absolute segment
assumed"
LJTI8_0:
	.long	 L8_0_set_8
	.long	 L8_0_set_11
	.long	 L8_0_set_8
	.long	 L8_0_set_11
	.long	 L8_0_set_8
	.long	 L8_0_set_11



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Thu Oct 19 19:25:05 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 19 Oct 2006 19:25:05 -0500
Subject: [LLVMbugs] [Bug 958] case branch tables: as complains "complex
	expression, absolute segment assumed"
Message-ID: <200610200025.k9K0P52q001216@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=958

scottm at aero.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED



------- Additional Comments From scottm at aero.org  2006-10-19 19:25 -------
Yup, it's the assembler. Recommended workaround is to install odcctools from
DarwinPorts (or equivalent upgraded binutils) and run configure for the C
frontend as follows:

env AS=/opt/local/bin/odas LD=/opt/local/bin/odld ../configure
--prefix=/Users/scottm/play/llvm-cfrontend/obj/../powerpc-apple-darwin8.0
--program-prefix=llvm- --enable-llvm=`pwd`/../../llvm/obj/
--enable-languages=c,c++ --with-as=/opt/local/bin/odas --with-ld=/opt/local/bin/odld



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Thu Oct 19 19:44:32 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 19 Oct 2006 19:44:32 -0500
Subject: [LLVMbugs] [Bug 957] [simplifycfg] constantexpr divide evaluation
	made unconditional
Message-ID: <200610200044.k9K0iWn2001922@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=957

sabre at nondot.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED
            Summary|[simplifycfg] miscompilation|[simplifycfg] constantexpr
                   |                            |divide evaluation made
                   |                            |unconditional
   Target Milestone|---                         |1.9



------- Additional Comments From sabre at nondot.org  2006-10-19 19:44 -------
select is closest to a conditional move.  Given two values (which are precomputed) it picks one.  Select 
itself doesn't have a notion of control flow, a constant expr is a value like any other, which needs to be 
evaluated.

Fixed.  Patch here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20061016/038778.html

testcase here: SimplifyCFG/2006-10-19-UncondDiv.ll

-Chris




------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Fri Oct 20 11:39:07 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 20 Oct 2006 11:39:07 -0500
Subject: [LLVMbugs] [Bug 959] NEW: update to cfrontend README.LLVM due to
	assembler breakage
Message-ID: <200610201639.k9KGd7oZ030816@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=959

           Summary: update to cfrontend README.LLVM due to assembler
                    breakage
           Product: tools
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: llvm-gcc
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: scottm at aero.org


Added configure comment for Darwin/PPC for those who might run into the "complex
expression, absolute segment assumed" issue. The fix is to install an updated
assembler, force the frontend to use the updated assembler.



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Fri Oct 20 17:46:51 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 20 Oct 2006 17:46:51 -0500
Subject: [LLVMbugs] [Bug 844] Internal compiler error with Objective-C++ and
	-fobjc-gc
Message-ID: <200610202246.k9KMkpep013791@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=844

dpatel at apple.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED



------- Additional Comments From dpatel at apple.com  2006-10-20 17:46 -------
This is now fixed.



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Fri Oct 20 22:41:38 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 20 Oct 2006 22:41:38 -0500
Subject: [LLVMbugs] [Bug 960] NEW: enhance bugpoint to reduce global
	initializers
Message-ID: <200610210341.k9L3fcuB018675@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=960

           Summary: enhance bugpoint to reduce global initializers
           Product: tools
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: bugpoint
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: sabre at nondot.org


It would be wonderful if someone would enhance bugpoint to prune down the list of global var initializers 
when some are required to provoke a compiler crash.  Domagoj Babic produced a patch that does exactly 
this:
http://lists.cs.uiuc.edu/pipermail/llvmbugs/2006-October/002004.html

... but his patch does not use the list reducer.  It would be great if someone could pick this up and finish 
it.

-Chris



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Sat Oct 21 09:56:33 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 21 Oct 2006 09:56:33 -0500
Subject: [LLVMbugs] [Bug 961] NEW: bootstrap failure in amd64
Message-ID: <200610211456.k9LEuXta006446@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=961

           Summary: bootstrap failure in amd64
           Product: tools
           Version: trunk
          Platform: Other
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: llvm-g++
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: rafael.espindola at gmail.com


llvm-g++ fail to compile libstdc++. The error message is
----------------------------------------------------------
cc1plus: ../../trunk/gcc/llvm-convert.cpp:3865: LValue 
TreeToLLVM::EmitLV_COMPONENT_REF(tree_node*): Assertion `ByteAlignment*8 < 
LLVMValueBitSize && "Unknown overlap case!"' failed.
test.cpp: In static member function ???static char 
rope<_CharT>::_S_fetch(_Rope_RopeRep*) [with _CharT = char]???:
test.cpp:29: internal compiler error: Aborted
----------------------------------------------------------
test.cpp is a reduced test case that is attached



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Sat Oct 21 15:56:42 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 21 Oct 2006 15:56:42 -0500
Subject: [LLVMbugs] [Bug 961] bootstrap failure in amd64
Message-ID: <200610212056.k9LKugjv012074@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=961

alenhar2 at uiuc.edu changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |DUPLICATE



------- Additional Comments From alenhar2 at uiuc.edu  2006-10-21 15:56 -------
This is a duplicate of http://llvm.org/bugs/show_bug.cgi?id=954
which has a slightly simpler reduced testcase.

*** This bug has been marked as a duplicate of 954 ***



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Sun Oct 22 13:20:59 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 22 Oct 2006 13:20:59 -0500
Subject: [LLVMbugs] [Bug 962] NEW: Code generator compiles back-to-back
	fixed-size dynamic allocas into really bad code
Message-ID: <200610221820.k9MIKxqT002804@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=962

           Summary: Code generator compiles back-to-back fixed-size dynamic
                    allocas into really bad code
           Product: libraries
           Version: 1.8
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: Common Code Generator Code
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: sabre at nondot.org


The tail recursion elimination pass can produce functions with allocas not in the entry block, if it wants 
them to live across iterations of the tail-recursion-eliminated code.  A simple example of the produced 
code is:

void %foo(bool %c) {
        br label %Next
Next:
        %A = alloca int
        %B = alloca int
        %C = alloca int
        %D = alloca int
        store int 1, int* %A
        store int 1, int* %B
        store int 1, int* %C
        store int 1, int* %D
        call void %test(int* %A, int* %B, int* %C, int* %D)
        br bool %c, label %Next, label %Out
Out:
        ret void
}
declare void %test(int*,int*,int*,int*)


It does this on the assumption that a block of allocas will be compiled into marginally efficient code, on 
the order of performance as a normal prolog.  However, this isn't the case.  The code above compiles 
into:

LBB1_1: ;Next
        mr r2, r1
        addi r3, r2, -16
        mr r1, r3
        mr r7, r1
        addi r4, r7, -16
        mr r1, r4
        mr r8, r1
        addi r5, r8, -16
        mr r1, r5
        mr r9, r1
        addi r6, r9, -16
        mr r1, r6
        li r10, 1
        stw r10, -16(r2)
        stw r10, -16(r7)
        stw r10, -16(r8)
        stw r10, -16(r9)
        rlwinm r29, r30, 0, 31, 31
        addi r1, r1, -64
        bl L_test$stub
        cmplwi cr0, r29, 0
        addi r1, r1, 64
        bne cr0, LBB1_1 ;Next

At the top, that is a ton of back-to-back copies into the stack pointer and out.  On X86, doing this sort 
of thing quickly causes spill code to be generated.

It would be far better to see these fixed size dynamic allocas and merge them together in the code 
generator, doing a single stack adjustment and then treating the suballocas as offsets from the base 
pointer.

-Chris



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Sun Oct 22 13:50:40 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 22 Oct 2006 13:50:40 -0500
Subject: [LLVMbugs] [Bug 963] NEW: MultiSource/Applications/JM/ldecod
	miscompilation
Message-ID: <200610221850.k9MIoe7m003355@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=963

           Summary: MultiSource/Applications/JM/ldecod miscompilation
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Backend: X86
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: rspencer at x10sys.com


The ldecod test shows a significant difference in the output of its floating
point numbers (~0.2 to ~1.3) compared to GCC. This is most notable on the JIT.
Furthermore the JIT output does not agree with the CBE, and LLC output.

Running "make bugpoint-jit" produces:

*** The following function is being miscompiled:  dpb_split_field_cond_true967
<cbe><gcc>You can reproduce the problem with the command line:
  lli -load ./bugpoint.safe.bc.cbe.c.so bugpoint.test.bc -i
/proj/llvm/llvm-test-nc/MultiSource/Applications/JM/ldecod/data/test.264 -o
/proj/llvm/llvm-test-nc/MultiSource/Applications/JM/ldecod/data/test_dec.yuv -r
/proj/llvm/llvm-test-nc/MultiSource/Applications/JM/ldecod/data/test_rec.yuv
The shared object was created with:
  llc -march=c bugpoint.safe.bc -o temporary.c
  gcc -xc temporary.c -O2 -o ./bugpoint.safe.bc.cbe.c.so -shared \ 
    -fno-strict-aliasing

Looking at the bugpoint.safe.bc file, the interesting bit is this block:
cond_true967:           ; preds = %newFuncRoot
        %tmp974 = getelementptr %struct.StorablePicture* %tmp957.reload, int 0,
uint 30         ; <short***> [#uses=1]
        %tmp975 = load short*** %tmp974         ; <short**> [#uses=1]
        %tmp977 = getelementptr short** %tmp975, int %tmp675.reload            
; <short**> [#uses=1]
        %tmp978 = load short** %tmp977          ; <short*> [#uses=1]
        %tmp980 = getelementptr short* %tmp978, int %tmp678.reload             
; <short*> [#uses=1]
        %tmp981 = load short* %tmp980           ; <short> [#uses=1]
        %tmp981 = cast short %tmp981 to int             ; <int> [#uses=1]
        %tmp986 = getelementptr %struct.StorablePicture* %tmp957.reload, int 0,
uint 5, int %tmp981, int 1, int %tmp916.reload          ; <long*> [#uses=1]
        %tmp987 = load long* %tmp986            ; <long> [#uses=1]
        br label %cond_next989.exitStub

which apparently has nothing to do with floating point calcuations.



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Sun Oct 22 14:07:07 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 22 Oct 2006 14:07:07 -0500
Subject: [LLVMbugs] [Bug 964] NEW: switch lowering makes ugly code for a
	simple scanning loop
Message-ID: <200610221907.k9MJ77dZ003677@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=964

           Summary: switch lowering makes ugly code for a simple scanning
                    loop
           Product: libraries
           Version: 1.8
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Common Code Generator Code
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: sabre at nondot.org


Consider this function (very similar to strhr):

void foo(unsigned char C);
const char *FindChar(const char *CurPtr) {
  unsigned char C;
  do
    C = *CurPtr++;
  while (C != 'x' && C != '\0');

  foo(C);
  return CurPtr;
}

We currently compile the loop to:

LBB1_1: #bb
        movb (%esi), %al
        incl %esi
        cmpb $119, %al
        jg LBB1_4       #bb
LBB1_3: #bb
        testb %al, %al
        je LBB1_2       #bb7
        jmp LBB1_1      #bb
LBB1_4: #bb
        cmpb $120, %al
        jne LBB1_1      #bb

It seems that switch lowering could produce something like:

        cmpb $120, %al
        je out
        testb %al, %al
        jnz LBB1_1       #bb7

which would be much faster.

-Chris



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Sun Oct 22 16:38:24 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 22 Oct 2006 16:38:24 -0500
Subject: [LLVMbugs] [Bug 964] switch lowering makes ugly code for a simple
	scanning loop
Message-ID: <200610222138.k9MLcO4L006691@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=964

sabre at nondot.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED



------- Additional Comments From sabre at nondot.org  2006-10-22 16:38 -------
Implemented.  Testcase here: Regression/CodeGen/Generic/SwitchLowering.ll

Patch here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20061016/038932.html

We now compile the inner loop to:

LBB1_1: #bb
        movb (%esi), %al
        incl %esi
        testb %al, %al
        je LBB1_2       #bb7
LBB1_3: #bb
        cmpb $120, %al
        jne LBB1_1      #bb

-Chris



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Sun Oct 22 19:33:43 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 22 Oct 2006 19:33:43 -0500
Subject: [LLVMbugs] [Bug 965] NEW: -globalmodref-aa & unreachable don't go
	along very well.
Message-ID: <200610230033.k9N0Xhtw009750@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=965

           Summary: -globalmodref-aa & unreachable don't go along very well.
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Global Analyses
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: patil.nikhil at gmail.com


Hi,

I have been playing with functions marked __attribute__((noreturn));
Specifically consider a following code:

void f(void) __attribute__((noreturn));

int call_f()
{
    f();
}

void f()
{
    while(1)
        ;
}

With "opt -globalsmodref-aa -adce" this gets compiled to:

int %call_f() {
entry:
    %retval = alloca int, align 4           ; <int*> [#uses=1]
    unreachable ; **** WRONG!!
    
return:         ; No predecessors!
    %retval = load int* %retval             ; <int> [#uses=1]
    ret int %retval
    
void %f() {
entry:
    br label %bb
    
bb:             ; preds = %bb, %entry
    br label %bb
    
return:         ; No predecessors!
    ret void    
}



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Mon Oct 23 15:27:39 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 23 Oct 2006 15:27:39 -0500
Subject: [LLVMbugs] [Bug 966] NEW: Turning on predicate simplifier pass
	breaks llvm-gcc bootstrapping
Message-ID: <200610232027.k9NKRdE6012565@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=966

           Summary: Turning on predicate simplifier pass breaks llvm-gcc
                    bootstrapping
           Product: libraries
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: critical
          Priority: P2
         Component: Scalar Optimizations
        AssignedTo: nicholas at mxc.ca
        ReportedBy: evan.cheng at apple.com


We recently added the predicate simplifier pass to llvm-gcc. See
gcc/llvm-backend.cpp

Sometime after 10/21, llvm-gcc bootstrapping broke. There were only a handful of
changes. After eliminating the possibility of Chris' changes may have broke it,
I tried disabling the predsimplfier pass. That did the trick.

Nick, please do a llvm-gcc build:

svn co ... llvm-gcc
cd llvm-gcc
cvs co llvm
mkdir -p build/obj build/dst build/sym
gnumake install RC_OS=macos RC_ARCHS='i386 ppc' TARGETS='i386 ppc' SRCROOT=`pwd`
OBJROOT=`pwd`/build/obj DSTROOT=`pwd`/build/dst SYMROOT=`pwd`/build/sym

The failure looks like this:

./xgcc -B./ -B/usr/local/llvm-gcc-install/i686-apple-darwin8/bin/ -isystem
/usr/local/llvm-gcc-install/i686-apple-darwin8/include -isystem
/usr/local/llvm-gcc-install/i686-apple-darwin8/sys-include -L/Volumes/\
Wildlings/echeng/SUBMISSIONS/llvm-submission/build/obj/obj-i686-i686/gcc/../ld
-O2  -DIN_GCC    -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition  -isystem ./include  -fP\
IC -pipe -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED  -I. -I.
-I/Volumes/Wildlings/echeng/SUBMISSIONS/llvm-submission/build/obj/src/gcc
-I/Volumes/Wildlings/echeng/SUBMISSIONS/llvm-submission/\
build/obj/src/gcc/.
-I/Volumes/Wildlings/echeng/SUBMISSIONS/llvm-submission/build/obj/src/gcc/../include
-I./../intl
-I/Volumes/Wildlings/echeng/SUBMISSIONS/llvm-submission/build/obj/src/gcc/../libcpp/include
\
 -I/Volumes/Wildlings/echeng/SUBMISSIONS/llvm-submission/build/obj/src/llvm/include
-I/Volumes/Wildlings/echeng/SUBMISSIONS/llvm-submission/build/obj/obj-llvm/include
-DL_muldi3  -c /Volumes/Wildlings/echeng/S\
UBMISSIONS/llvm-submission/build/obj/src/gcc/libgcc2.c -o libgcc/./_muldi3.o
In file included from
/Volumes/Wildlings/echeng/SUBMISSIONS/llvm-submission/build/obj/src/gcc/tsystem.h:47,
                 from
/Volumes/Wildlings/echeng/SUBMISSIONS/llvm-submission/build/obj/src/gcc/libgcc2.c:41:
./include/stddef.h:152: error: storage class specified for parameter 'ptrdiff_t'
./include/stddef.h:214: error: storage class specified for parameter 'size_t'
./include/stddef.h:326: error: storage class specified for parameter 'wchar_t'
In file included from
/Volumes/Wildlings/echeng/SUBMISSIONS/llvm-submission/build/obj/src/gcc/tsystem.h:87,
                 from
/Volumes/Wildlings/echeng/SUBMISSIONS/llvm-submission/build/obj/src/gcc/libgcc2.c:41:
./include/stdarg.h:43: error: storage class specified for parameter '__gnuc_va_list'
./include/stdarg.h:105: error: syntax error before 'va_list'
...



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Tue Oct 24 07:44:06 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 24 Oct 2006 07:44:06 -0500
Subject: [LLVMbugs] [Bug 956] Vectors don't display correctly when in a
	struct.
Message-ID: <200610241244.k9OCi67D000940@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=956

jlaskey at apple.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED



------- Additional Comments From jlaskey at apple.com  2006-10-24 07:44 -------
Apparently a change to gcc tree addressed problem.



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Wed Oct 25 16:36:01 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 25 Oct 2006 16:36:01 -0500
Subject: [LLVMbugs] [Bug 967] NEW: [predsimplify] release run works fine,
	debug run goes crazy
Message-ID: <200610252136.k9PLa1Cu018836@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=967

           Summary: [predsimplify] release run works fine, debug run goes
                    crazy
           Product: libraries
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Scalar Optimizations
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: sabre at nondot.org


This is a nasty bug that points to some memory corruption issue or something.

time ~/llvm/Release/bin/opt -predsimplify -disable-output bugpoint-reduced-simplified.bc 
0.055u 0.009s 0:00.06 83.3%     0+0k 0+1io 0pf+0w

time ~/llvm/Debug/bin/opt -predsimplify -disable-output bugpoint-reduced-simplified.bc 
<forever>

Note that the .bc *does* have a large nasty cfg, but it is strange that this issue should only affect a 
debug opt and not a release opt.  This points to some memory clobbering, or deleting something, but 
not removing it from a map or something (i.e. it's address is still the key or value of some map).

I'm disabling predsimplify in llvm-gcc until this is resolved, this breaks debug bootstraps on both ppc 
and x86.

-Chris



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Thu Oct 26 00:59:52 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 26 Oct 2006 00:59:52 -0500
Subject: [LLVMbugs] [Bug 968] NEW: X86 doesn't support vector <4 x int> or <
	4 x uint >
Message-ID: <200610260559.k9Q5xqAB028687@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=968

           Summary: X86 doesn't support vector <4 x int> or < 4 x uint >
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Backend: X86
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: rspencer at x10sys.com


This test case:
SingleSource/UnitTests/Vector/divides.c
produces:
llc: /proj/llvm/llvm/lib/Target/X86/X86ISelDAGToDAG.cpp:1138: llvm::SDNode*
<unnamed>::X86DAGToDAGISel::Select(llvm::SDOperand): Assertion `0 &&
"Unsupported VT!"' failed.



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Thu Oct 26 11:01:30 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 26 Oct 2006 11:01:30 -0500
Subject: [LLVMbugs] [Bug 969] NEW: llc-beta results count as fail if they
	didn't run
Message-ID: <200610261601.k9QG1UK0024453@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=969

           Summary: llc-beta results count as fail if they didn't run
           Product: Test Suite
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Nightly Tester
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: rspencer at x10sys.com


I don't run the llc-beta tests as part of my nightly tester. That is I don't
specify the -enable-llcbeta option to NewNightlyTester.pl. The test results web
site reports every single test as having llc-beta failed. That creates a
can't-see-the-tree-for-the-forest situation when reviewing results. It gets very
easy to miss a failed test because every test has at least one failure: llc-beta. 

I don't think this situation is useful or correct. If --enable-llcbeta was not
specified on the command line, the nightly tester should inform the server of
that situation and:

1. Not report llc-beta tests as failed
2. Not include an llc-beta summary ("Tests Significantly Changed for LLC-BETA")
3. Not include any llc-beta related columns in the detailed reports.



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Thu Oct 26 13:30:47 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 26 Oct 2006 13:30:47 -0500
Subject: [LLVMbugs] [Bug 970] NEW: Should audit LLVM for incorrect uses of
	isFloatingPoint()
Message-ID: <200610261830.k9QIUlP3002402@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=970

           Summary: Should audit LLVM for incorrect uses of
                    isFloatingPoint()
           Product: libraries
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Core LLVM classes
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: sabre at nondot.org


A lot of code uses X->getType()->isFloatingPoint() to disable transformations that are unsafe on FP math.  
We should audit these and change them to call Ty->isFPOrFPVector() if they are also unsafe for vectors of 
floats (which is probably most of them).

Of course, it would be far better to just have FADD/FMUL/etc instructions separate from ADD/MUL, etc, 
but that will take time.

-Chris



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Fri Oct 27 13:49:34 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 27 Oct 2006 13:49:34 -0500
Subject: [LLVMbugs] [Bug 968] X86 doesn't support vector <4 x int> or < 4 x
	uint >
Message-ID: <200610271849.k9RInYMn020220@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=968

evan.cheng at apple.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED



------- Additional Comments From evan.cheng at apple.com  2006-10-27 13:49 -------
We were not expaning vector sdiv and udiv. Fixed.



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Sat Oct 28 10:51:25 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 28 Oct 2006 10:51:25 -0500
Subject: [LLVMbugs] [Bug 971] NEW: boostrap build fails with all optzns
	removed
Message-ID: <200610281551.k9SFpPqU006784@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=971

           Summary: boostrap build fails with all optzns removed
           Product: tools
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: llvm-gcc
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: nicholas at mxc.ca


I changed llvm-backend.cpp to exclude the PerModulePasses no matter what the
optimization level was. Specifically, I added #if 0 right after "if (optimize >
0) {" and the matching #endif right before the matching "}".

"make bootstrap" fails with the following error:

./xgcc -B./ -B/home/nicholas/llvm-gcc/install/i686-pc-linux-gnu/bin/ -isystem
/home/nicholas/llvm-gcc/install/i686-pc-linux-gnu/include -isystem
/home/nicholas/llvm-gcc/install/i686-pc-linux-gnu/sys-include
-L/home/nicholas/llvm-gcc/build/gcc/../ld -O2  -DIN_GCC    -W -Wall
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition
 -isystem ./include  -fPIC -g  -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED  -I. -I.
-I../../src/gcc -I../../src/gcc/. -I../../src/gcc/../include
-I../../src/gcc/../libcpp/include  -I/home/nicholas/llvm/include
-I/home/nicholas/llvm/include -DL_muldi3 -c ../../src/gcc/libgcc2.c -o
libgcc/./_muldi3.o
In file included from /usr/include/stdio.h:36,
                 from ../../src/gcc/tsystem.h:90,
                 from ../../src/gcc/libgcc2.c:41:
/usr/include/bits/types.h:146: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://llvm.org/bugs> for instructions.

At the moment, gdb isn't playing along, but valgrind does show something
interesting:

$ valgrind --db-attach=yes ./cc1 -quiet -I. -I. -I../../src/gcc
-I../../src/gcc/. -I../../src/gcc/../include -I../../src/gcc/../libcpp/include
-I/home/nicholas/llvm/include -I/home/nicholas/llvm/include -iprefix
/home/nicholas/llvm-gcc/build/gcc/../lib/gcc/i686-pc-linux-gnu/4.0.1/ -isystem
./include -DIN_GCC -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -DL_muldi3 -isystem
/home/nicholas/llvm-gcc/install/i686-pc-linux-gnu/include -isystem
/home/nicholas/llvm-gcc/install/i686-pc-linux-gnu/sys-include -isystem ./include
../../src/gcc/libgcc2.c -quiet -dumpbase libgcc2.c -mtune=generic -auxbase-strip
libgcc/./_muldi3.o -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition -fPIC -o /tmp/ccJ3kfje.s
==17508== Memcheck, a memory error detector.
==17508== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al.
==17508== Using LibVEX rev 1658, a library for dynamic binary translation.
==17508== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP.
==17508== Using valgrind-3.2.1-Debian, a dynamic binary instrumentation framework.
==17508== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al.
==17508== For more details, rerun with: -v
==17508== 
==17508== Invalid read of size 4
==17508==    at 0x8059AD5: (within /home/nicholas/llvm-gcc/build/gcc/cc1)
==17508==  Address 0x171 is not stack'd, malloc'd or (recently) free'd
==17508== 
==17508== ---- Attach to debugger ? --- [Return/N/n/Y/y/C/c] ---- y
starting debugger
==17508== starting debugger with cmd: /usr/bin/gdb -nw /proc/17509/fd/1014 17509
GNU gdb 6.4.90-debian
Copyright (C) 2006 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 "i486-linux-gnu"...Using host libthread_db library
"/usr/lib/debug/libthread_db.so.1".

Attaching to program: /proc/17509/fd/1014, process 17509
Reading symbols from /usr/lib/valgrind/x86-linux/vgpreload_core.so...done.
[...]
Loaded symbols for /usr/lib/debug/libdl.so.2

warning: Lowest section in system-supplied DSO at 0xffffe000 is .hash at ffffe0b4
0x08059ad5 in .BB16_56 ()
Breakpoint 1 at 0x81d1220
Breakpoint 2 at 0x81d1440
Breakpoint 3 at 0x5e3ff96: file exit.c, line 35.
Breakpoint 4 at 0x5e3ec15: file ../sysdeps/generic/abort.c, line 50.
(gdb) bt
#0  0x08059ad5 in .BB16_56 ()
#1  0x05f635c0 in ?? ()
#2  0x0623ad50 in ?? ()
#3  0x00000111 in ?? ()
Previous frame inner to this frame (corrupt stack?)
(gdb) 

No useful backtrace, no line numbers. "cc1" doesn't have any debugging
information. I've tried, but I can't seem to compile llvm-gcc with debugging.



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Sat Oct 28 12:05:21 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 28 Oct 2006 12:05:21 -0500
Subject: [LLVMbugs] [Bug 925] sdisel lowers this to really bad code
Message-ID: <200610281705.k9SH5LbZ008694@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=925

sabre at nondot.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED



------- Additional Comments From sabre at nondot.org  2006-10-28 12:05 -------
Fixed.  Testcase here: CodeGen/Generic/switch-crit-edge-constant.ll

Patch here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20061023/039183.html

-Chris



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Sat Oct 28 16:33:30 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 28 Oct 2006 16:33:30 -0500
Subject: [LLVMbugs] [Bug 972] NEW: llvm-gcc Makefiles use obolete syntax for
	"tail" call
Message-ID: <200610282133.k9SLXUqI015550@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=972

           Summary: llvm-gcc Makefiles use obolete syntax for "tail" call
           Product: Build scripts
           Version: cvs
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Makefiles
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: asl at math.spbu.ru


It seems, that llvm-gcc Makefiles use obsolete syntax of "tail" (during, e.g.
bootstrapping). The syntax of form "+16c" is by default definitely unsupported
with GNU coreutils 6.4. 

Solution: replace "+16c" with "-c 16"



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Sun Oct 29 06:15:21 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 29 Oct 2006 06:15:21 -0600
Subject: [LLVMbugs] [Bug 973] NEW: llvm-gcc4 compiled code lacks static
	ctors & dtors
Message-ID: <200610291215.k9TCFLOI030636@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=973

           Summary: llvm-gcc4 compiled code lacks static ctors & dtors
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Support Libraries
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: asl at math.spbu.ru


llvm-gcc4 code lacks static ctors & dtors at least on Linux (mingw has its own
technique to handle this and everything is ok there). This breaks many apps,
e.q. Qt.

The problem will solved (I hope), when crtstuff.c will be properly compiled with
llvm-gcc4.



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Sun Oct 29 15:23:27 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 29 Oct 2006 15:23:27 -0600
Subject: [LLVMbugs] [Bug 974] NEW: -fno-unit-at-a-time should disable all ipo
Message-ID: <200610292123.k9TLNR60006754@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=974

           Summary: -fno-unit-at-a-time should disable all ipo
           Product: tools
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: minor
          Priority: P2
         Component: llvm-gcc
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: sabre at nondot.org


GCC's -fno-unit-at-a-time, basically now means 'disable all ipo except inlining'.  This understanding is 
expected by crtstuff.c in the GCC build.  We could remove some llvm-local hacks from crtstuff if we made 
-fno-unit-at-a-time disable IPO (specific dead global var deletion).

-Chris



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Mon Oct 30 16:40:48 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 30 Oct 2006 16:40:48 -0600
Subject: [LLVMbugs] [Bug 972] llvm-gcc Makefiles use obolete syntax for
	"tail" call
Message-ID: <200610302240.k9UMems3001418@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=972

sabre at nondot.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
           Keywords|                            |portability
         Resolution|                            |FIXED
   Target Milestone|---                         |1.9



------- Additional Comments From sabre at nondot.org  2006-10-30 16:40 -------
Patch applied, thanks Anton!

-Chris




------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Mon Oct 30 17:08:57 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 30 Oct 2006 17:08:57 -0600
Subject: [LLVMbugs] [Bug 975] NEW: crtstuff.c breaks llvm-gcc build
Message-ID: <200610302308.k9UN8vBm002075@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=975

           Summary: crtstuff.c breaks llvm-gcc build
           Product: tools
           Version: 1.0
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: llvm-gcc
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: rspencer at x10sys.com


/proj/llvm/cfe/build-2/gcc/xgcc -B/proj/llvm/cfe/build-2/gcc/
-B/proj/llvm/cfe/install-2/i686-pc-linux-gnu/bin/
-B/proj/llvm/cfe/install-2/i686-pc-linux-gnu/lib/ -isystem
/proj/llvm/cfe/install-2/i686-pc-linux-gnu/include -isystem
/proj/llvm/cfe/install-2/i686-pc-linux-gnu/sys-include -O2 -DIN_GCC    -W -Wall
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition
 -isystem ./include  -I. -I. -I../../src-2/gcc -I../../src-2/gcc/.
-I../../src-2/gcc/../include -I../../src-2/gcc/../libcpp/include 
-I/proj/llvm/llvm-2/include -I/proj/llvm/llvm-2/include  -g0
-finhibit-size-directive -fno-inline-functions -fno-exceptions
-fno-zero-initialized-in-bss -fno-unit-at-a-time -fno-omit-frame-pointer \
   -c ../../src-2/gcc/crtstuff.c -DCRT_BEGIN \
  -o crtbegin.o
In file included from ../../src-2/gcc/crtstuff.c:67:
../../src-2/gcc/unwind-dw2-fde.h: In function ???get_cie???:
../../src-2/gcc/unwind-dw2-fde.h:163: warning: return from incompatible pointer type
cc1: /proj/llvm/llvm-2/include/llvm/Support/Casting.h:199: typename
llvm::cast_retty<To, From>::ret_type llvm::cast(const Y&) [with X =
llvm::CondCodeSDNode, Y = llvm::SDOperand]: Assertion `isa<X>(Val) &&
"cast<Ty>() argument of incompatible type!"' failed.
../../src-2/gcc/crtstuff.c: At top level:
../../src-2/gcc/crtstuff.c:314: internal compiler error: Aborted
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://llvm.org/bugs> for instructions.



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Mon Oct 30 19:27:30 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 30 Oct 2006 19:27:30 -0600
Subject: [LLVMbugs] [Bug 973] llvm-gcc4 compiled code lacks static ctors &
	dtors
Message-ID: <200610310127.k9V1RUdl004339@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=973

evan.cheng at apple.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED



------- Additional Comments From evan.cheng at apple.com  2006-10-30 19:27 -------
"Patch for LLVM" applied. Thanks!



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Tue Oct 31 00:18:52 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 31 Oct 2006 00:18:52 -0600
Subject: [LLVMbugs] [Bug 954] Crash handling COMPONENT_REF at -m64
Message-ID: <200610310618.k9V6IqBs009234@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=954

sabre at nondot.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED



------- Additional Comments From sabre at nondot.org  2006-10-31 00:18 -------
After trying to get my head rewrapped around this code, I've come to the conclusion that the suggested 
patch is safe and it certainly is minimal.  The code basically needs (another) rewrite. 


Testcase here: Regression/C++Frontend/2006-10-30-ClassBitfield.cpp

Patch here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20061030/039265.html

-Chris



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Tue Oct 31 00:25:43 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 31 Oct 2006 00:25:43 -0600
Subject: [LLVMbugs] [Bug 911] ICE during compilation of program
Message-ID: <200610310625.k9V6PhJS009530@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=911

sabre at nondot.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |DUPLICATE



------- Additional Comments From sabre at nondot.org  2006-10-31 00:25 -------
The patch in pr954 fixes this.

I checked this testcase in as Regression/CFrontend/2006-10-30-ArrayCrash.c

-Chris

*** This bug has been marked as a duplicate of 954 ***



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Tue Oct 31 00:31:40 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 31 Oct 2006 00:31:40 -0600
Subject: [LLVMbugs] [Bug 959] update to cfrontend README.LLVM due to
	assembler breakage
Message-ID: <200610310631.k9V6VeKD009706@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=959

sabre at nondot.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
           Keywords|                            |doc-obsolete
         Resolution|                            |FIXED



------- Additional Comments From sabre at nondot.org  2006-10-31 00:31 -------
Thanks!

It looks like Jim applied this but never closed the bug.

-Chris



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Tue Oct 31 00:35:42 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 31 Oct 2006 00:35:42 -0600
Subject: [LLVMbugs] [Bug 938] Lack of inline asm support
Message-ID: <200610310635.k9V6ZgXe009842@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=938

sabre at nondot.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |DUPLICATE



------- Additional Comments From sabre at nondot.org  2006-10-31 00:35 -------
If you change the inline asm to "=m" instead of "=qm", it should build.

-Chris

*** This bug has been marked as a duplicate of 839 ***



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Tue Oct 31 00:36:56 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 31 Oct 2006 00:36:56 -0600
Subject: [LLVMbugs] [Bug 782] [x86] inline asm failure
Message-ID: <200610310636.k9V6auCq009927@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=782

sabre at nondot.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED
   Target Milestone|---                         |1.9



------- Additional Comments From sabre at nondot.org  2006-10-31 00:36 -------
Fixed.



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Tue Oct 31 00:39:28 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 31 Oct 2006 00:39:28 -0600
Subject: [LLVMbugs] [Bug 960] enhance bugpoint to reduce global initializers
Message-ID: <200610310639.k9V6dSek010016@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=960

isanbard at gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED



------- Additional Comments From isanbard at gmail.com  2006-10-31 00:39 -------
Good point. Fixed here:

http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20061023/039047.html



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Tue Oct 31 11:33:17 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 31 Oct 2006 11:33:17 -0600
Subject: [LLVMbugs] [Bug 976] NEW: Simple asm breaks build of llvm-gcc
Message-ID: <200610311733.k9VHXHP8023674@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=976

           Summary: Simple asm breaks build of llvm-gcc
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Common Code Generator Code
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: rspencer at x10sys.com


Test Case:
; ModuleID = 'bugpoint-reduced-simplified.bc'
target datalayout = "e-p:32:32"
target endian = little
target pointersize = 32
target triple = "i686-pc-linux-gnu"
module asm "\09.section\09.fini"
module asm "\09call __do_global_dtors_aux"
module asm "\09.text"

implementation   ; Functions:

void %__do_global_dtors_aux() {
entry:
        ret void
}



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Tue Oct 31 11:34:09 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 31 Oct 2006 11:34:09 -0600
Subject: [LLVMbugs] [Bug 977] NEW: LCSSA code dereferences NULL pointer
Message-ID: <200610311734.k9VHY9KV023709@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=977

           Summary: LCSSA code dereferences NULL pointer
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Transformation Utilities
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: criswell at uiuc.edu


When run on the attached test case, the opt tool crases from a SEGFAULT. 
Initial investigation shows that LCSSA::GetValueForBlock is being passed a NULL
pointer for the BB operand and attempts to dereference it.



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Tue Oct 31 11:53:24 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 31 Oct 2006 11:53:24 -0600
Subject: [LLVMbugs] [Bug 977] LCSSA code crash on unreachable block.
Message-ID: <200610311753.k9VHrOmb025405@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=977

sabre at nondot.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
           Keywords|                            |compile-fail
         OS/Version|Linux                       |All
           Platform|PC                          |All
         Resolution|                            |FIXED
            Summary|LCSSA code dereferences NULL|LCSSA code crash on
                   |pointer                     |unreachable block.
   Target Milestone|---                         |1.9



------- Additional Comments From sabre at nondot.org  2006-10-31 11:53 -------
Fixed, patch here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20061030/039276.html

Testcase here:
Transforms/LCSSA/2006-10-31-UnreachableBlock.ll

Thanks,

-Chris




------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Tue Oct 31 12:43:05 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 31 Oct 2006 12:43:05 -0600
Subject: [LLVMbugs] [Bug 977] LCSSA code crash on unreachable block.
Message-ID: <200610311843.k9VIh5nm032014@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=977

criswell at uiuc.edu changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |



------- Additional Comments From criswell at uiuc.edu  2006-10-31 12:43 -------
Chris,

I believe the new testcase is another form of the same bug.




------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Tue Oct 31 12:57:25 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 31 Oct 2006 12:57:25 -0600
Subject: [LLVMbugs] [Bug 977] LCSSA code crash on unreachable block.
Message-ID: <200610311857.k9VIvPZT026483@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=977

sabre at nondot.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |FIXED



------- Additional Comments From sabre at nondot.org  2006-10-31 12:57 -------
Fixed.  Patch here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20061030/039278.html

Testcase here:
Transforms/LCSSA/2006-10-31-UnreachableBlock-2.ll

-Chris




------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Tue Oct 31 14:12:06 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 31 Oct 2006 14:12:06 -0600
Subject: [LLVMbugs] [Bug 882] Inline asm crash in linux kernel
Message-ID: <200610312012.k9VKC604017132@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=882

sabre at nondot.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
           Keywords|regression                  |
         Resolution|                            |FIXED
   Target Milestone|---                         |1.9



------- Additional Comments From sabre at nondot.org  2006-10-31 14:12 -------
Implemented.  Testcase here:  CodeGen/X86/asm-global-imm.ll

There are several patches, so not listing here.

-Chris




------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Tue Oct 31 15:11:15 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 31 Oct 2006 15:11:15 -0600
Subject: [LLVMbugs] [Bug 976] Linking Cruft Doesn't Help
Message-ID: <200610312111.k9VLBFuD018146@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=976

rspencer at x10sys.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID
            Summary|Simple asm breaks build of  |Linking Cruft Doesn't Help
                   |llvm-gcc                    |
   Target Milestone|---                         |1.9



------- Additional Comments From rspencer at x10sys.com  2006-10-31 15:11 -------
Turns out a 100% clean rebuild fixed this. *sigh*



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Tue Oct 31 17:44:04 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 31 Oct 2006 17:44:04 -0600
Subject: [LLVMbugs] [Bug 978] NEW: X86/ELF Dwarf Support Is Lacking
Message-ID: <200610312344.k9VNi4f9021002@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=978

           Summary: X86/ELF Dwarf Support Is Lacking
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Common Code Generator Code
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: rspencer at x10sys.com


The X86/ELF Dwarf support appears to be lacking some information that the
debugger needs. Although it is possible to set breakpoints, trace through the
program, and otherwise debug things, GDB will quite frequently print messages of
the form: 
During symbol reading, Incomplete CFI data; unspecified register eax at 0x08867e2d.
During symbol reading, Incomplete CFI data; unspecified register ecx at 0x08867e2d.
During symbol reading, Incomplete CFI data; unspecified register edx at 0x08867e2d.
During symbol reading, Incomplete CFI data; unspecified register ebx at 0x08867e2d.
During symbol reading, Incomplete CFI data; unspecified register esi at 0x08867e2d.
During symbol reading, Incomplete CFI data; unspecified register edi at 0x08867e2d.

These always occur with the "where" command and often occur when inspecting
variables or using the "next" command.

Possibly there is some frame information that is missing for X86/ELF.



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.