From bugzilla-daemon at cs.uiuc.edu  Sat Sep  1 13:40:01 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 1 Sep 2007 13:40:01 -0500
Subject: [LLVMbugs] [Bug 1633] New: Verifier doesn't fully verify GC
	intrinsic
Message-ID: <bug-1633-206@http.llvm.org/bugs/>

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

           Summary: Verifier doesn't fully verify GC intrinsic
           Product: libraries
           Version: trunk
          Platform: All
        OS/Version: All
            Status: ASSIGNED
          Severity: minor
          Priority: P2
         Component: Core LLVM classes
        AssignedTo: gordonhenriksen at mac.com
        ReportedBy: gordonhenriksen at mac.com
                CC: llvmbugs at cs.uiuc.edu


The llvm.gc* intrinsics have restrictions beyond what the verifier checks.

llvm.gcroot: 'The first argument specifies the address of a stack object that
contains the root pointer. The second pointer (which must be either a constant
or a global value address) contains the meta-data to be associated with the
root.'

  - Not checked: Type of first argument is a pointer to a pointer.
  - Not checked: First argument is an alloca (or a bitcast of an alloca).
  - Not checked: Second argument is a global or a constant.

llvm.gcread: 'The second argument is the address to read from, which should be
an address allocated from the garbage collector. The first object is a pointer
to the start of the referenced object, if needed by the language runtime
(otherwise null).'

  - Not checked: Type of second argument is a pointer to a pointer.

llvm.gcwrite: 'The first argument is the reference to store, the second is the
start of the object to store it to, and the third is the address of the field
of Obj to store to. If the runtime does not require a pointer to the object,
Obj may be null.'

  - Not checked: Type of third argument is a pointer to a pointer.

It should be easy to fix this by adding a follow-up switch to
Verifier::visitIntrinsicFunctionCall at lib/VMCore/Verifier.cpp:1077.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Sat Sep  1 16:41:27 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 1 Sep 2007 16:41:27 -0500
Subject: [LLVMbugs] [Bug 1634] New: llvm-g++ fails an assertion test
 compiling on x86 (OS X)
Message-ID: <bug-1634-206@http.llvm.org/bugs/>

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

           Summary: llvm-g++ fails an assertion test compiling on x86 (OS X)
           Product: cfe
           Version: unspecified
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Keywords: compile-fail
          Severity: critical
          Priority: P2
         Component: LLVM Codegen
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: arobison at cs.utah.edu
                CC: llvmbugs at cs.uiuc.edu


The following command line:

/Users/arobison/Development/llvm-gcc/bin/llvm-g++   -DManta_Engine_EXPORTS 
-Wall -Wno-strict-aliasing -DSCI_NOPERSISTENT -march=nocona -mtune=nocona  
-msse -msse2 -msse3 -mfpmath=sse  -O3 -DNDEBUG -g3 -fgcse-sm -funroll-loops
-fstrict-aliasing -fsched-interblock -ffast-math -freorder-blocks -fPIC -c
compiler-ice.cc

Produces the following output:

<built-in>:1:1: warning: "__STDC_HOSTED__" redefined<built-in>:1:1: warning:
this is the location of the previous definition
Instructions.cpp:210: failed assertion `(i >= FTy->getNumParams() ||
FTy->getParamType(i) == Params[i]->getType()) && "Calling a function with a bad
signature!"'
/Users/arobison/Development/Manta/Engine/Control/RTRT.cc: In member function
'virtual void Manta::RTRT::unregisterCallback(Manta::CallbackHandle*)':
/Users/arobison/Development/Manta/Engine/Control/RTRT.cc:276: internal compiler
error: Abort trap
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://llvm.org/bugs> for instructions.

g++ does not produce errors compiling this code.
Preprocessed file that produces the error attached.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Sun Sep  2 10:27:38 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 2 Sep 2007 10:27:38 -0500
Subject: [LLVMbugs] [Bug 1635] New: Syntax for 'call' Instruction is wrong
Message-ID: <bug-1635-206@http.llvm.org/bugs/>

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

           Summary: Syntax for 'call' Instruction is wrong
           Product: Documentation
           Version: trunk
          Platform: All
               URL: http://llvm.org/docs/LangRef.html
        OS/Version: All
            Status: ASSIGNED
          Severity: normal
          Priority: P2
         Component: General docs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: nicholas at mxc.ca
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=1099)
 --> (http://llvm.org/bugs/attachment.cgi?id=1099)
Proposed change to LangRef.html

Currently the syntax for the call instruction reads:

  <result> = [tail] call [cconv] <ty>* <fnptrval>(<param list>)

Which is mistaken. A long syntax call instruction has two types, one for the
CallInst itself (aka. the return type) and an optional one for the fnptrval.
The current documentation claims that <ty>* is optional, implying that a call
can be written with no type at all.

Please review the attached patch.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Sun Sep  2 13:27:17 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 2 Sep 2007 13:27:17 -0500
Subject: [LLVMbugs] [Bug 1636] New: crtfastmath.c is miscompiled
Message-ID: <bug-1636-206@http.llvm.org/bugs/>

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

           Summary: crtfastmath.c is miscompiled
           Product: tools
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: llvm-gcc
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: asl at math.spbu.ru
                CC: llvmbugs at cs.uiuc.edu


crtfastmath.c is miscompiled at least on x86/linux. See PR1634 for details.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Tue Sep  4 15:21:23 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 4 Sep 2007 15:21:23 -0500
Subject: [LLVMbugs] [Bug 1613] ScheduleDAG.cpp:464 regclass mismatch
In-Reply-To: <bug-1613-206@http.llvm.org/bugs/>
Message-ID: <200709042021.l84KLN5X012806@zion.cs.uiuc.edu>

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


Evan Cheng <evan.cheng at apple.com> changed:

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




--- Comment #4 from Evan Cheng <evan.cheng at apple.com>  2007-09-04 15:21:23 ---
Fixed.
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070903/053258.html


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Tue Sep  4 15:39:54 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 4 Sep 2007 15:39:54 -0500
Subject: [LLVMbugs] [Bug 1632] codegen of exceptions broken on linux x86-64.
 Brakes gcc bootstrap
In-Reply-To: <bug-1632-206@http.llvm.org/bugs/>
Message-ID: <200709042039.l84Kds9V013636@zion.cs.uiuc.edu>

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


Evan Cheng <evan.cheng at apple.com> changed:

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




--- Comment #4 from Evan Cheng <evan.cheng at apple.com>  2007-09-04 15:39:54 ---
Documentation:
i32 %llvm.eh.selector(i8*, i8*, i8*, ...)

Intrinsics.td:
def int_eh_selector   : Intrinsic<[llvm_i32_ty, llvm_ptr_ty, llvm_ptr_ty,
                                                llvm_vararg_ty]>;

SelectionDAGISel.cpp:
      // Insert the EHSELECTION instruction.                                   
                                                                               
                       SDVTList VTs = DAG.getVTList(TLI.getPointerTy(),
MVT::Other);

This is the mismatch.

I believe the bug is in SelectionDAGISel.cpp, if that's not the case. Please
revert my fix, fix Intrinsics.td and the documentation.

Fix is:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070903/053259.html


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Wed Sep  5 06:45:44 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 5 Sep 2007 06:45:44 -0500
Subject: [LLVMbugs] [Bug 1628] EH shouldn't generate unnecessary labels
In-Reply-To: <bug-1628-206@http.llvm.org/bugs/>
Message-ID: <200709051145.l85BjiMZ002116@zion.cs.uiuc.edu>

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


Duncan Sands <baldrick at free.fr> changed:

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




--- Comment #11 from Duncan Sands <baldrick at free.fr>  2007-09-05 06:45:43 ---
Fixed, patch here:
http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/CodeGen/DwarfWriter.cpp?r1=41717&r2=41718&view=diff&pathrev=41718


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Wed Sep  5 08:54:51 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 5 Sep 2007 08:54:51 -0500
Subject: [LLVMbugs] [Bug 1612] Problems with exception handling when using
	LLVM JIT
In-Reply-To: <bug-1612-206@http.llvm.org/bugs/>
Message-ID: <200709051354.l85DspXJ008598@zion.cs.uiuc.edu>

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


Samit Basu <basu at research.ge.com> changed:

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




--- Comment #13 from Samit Basu <basu at research.ge.com>  2007-09-05 08:54:50 ---
OK - I finally had some time to track this down.  Reid, I don't know related
this is to your problems, but Chris was essentially right - the issues appear
to be entirely on my end - not LLVM related, although LLVM induced.  Here's the
synopsis of what I found:

1.  gcc 3.4.6 - exceptions do _not_ work properly when mixing LLVM code (which
uses -fomit-frame-pointer) with code that does not use this flag.  So even
though my example code worked, my application did not.

2.  gcc 4.1.2 - Fedora Core 6 - this actually works fine.  The problem I had
was that I mistakenly installed the llvm-gcc front end into my home directory. 
This put the llvm-gcc libstdc++.a in my path, which was picked up by the
regular gcc (instead of its own libstdc++.so).  Hence, exception handling was
broken.

3.  gcc 4.1.2 - Fedora Core 7 - worked fine, because I never installed the
llvm-gcc front end.

I'm closing out this bug, although someone may want to mention the issue with
3.4.6 in the broken compiler list (and maybe warn users to be careful about
where they install llvm-gcc...).

Thanks again everyone for such a cool product.

Samit


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Wed Sep  5 12:23:58 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 5 Sep 2007 12:23:58 -0500
Subject: [LLVMbugs] [Bug 1632] codegen of exceptions broken on linux x86-64.
 Brakes gcc bootstrap
In-Reply-To: <bug-1632-206@http.llvm.org/bugs/>
Message-ID: <200709051723.l85HNwVw016438@zion.cs.uiuc.edu>

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


Rafael ??vila de Esp??ndola <rafael.espindola at gmail.com> changed:

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




--- Comment #6 from Rafael ??vila de Esp??ndola <rafael.espindola at gmail.com>  2007-09-05 12:23:58 ---
reopening...


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Wed Sep  5 13:43:53 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 5 Sep 2007 13:43:53 -0500
Subject: [LLVMbugs] [Bug 1637] New: Instcombine turnes true expression into
	false
Message-ID: <bug-1637-206@http.llvm.org/bugs/>

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

           Summary: Instcombine turnes true expression into false
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: Scalar Optimizations
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: asl at math.spbu.ru
                CC: llvmbugs at cs.uiuc.edu


Consider the following code used to check access within array bounds:

define i32 @main(i32 %argc, i8** %argv) {
main.0:
        %arr = malloc i8, i32 65536             ; <i8*> [#uses=3]
        %arrmax = getelementptr i8* %arr, i32 65536             ; <i8*>
[#uses=1]
        %head.0 = getelementptr i8* %arr, i32 65536             ; <i8*>
[#uses=2]
        %test.1 = icmp uge i8* %head.0, %arrmax         ; <i1> [#uses=1]
        %test.2 = icmp ult i8* %head.0, %arr            ; <i1> [#uses=1]
        %test.3 = or i1 %test.1, %test.2                ; <i1> [#uses=1]
        br i1 %test.3, label %main.1, label %main.2

main.1:         ; preds = %main.0
        call i32 @putchar( i32 89 )             ; <i32>:0 [#uses=0]
        br label %main.3

main.2:         ; preds = %main.0
        call i32 @putchar( i32 78 )             ; <i32>:1 [#uses=0]
        br label %main.3

main.3:         ; preds = %main.2, %main.1
        call i32 @putchar( i32 10 )             ; <i32>:2 [#uses=0]
        ret i32 0
}

instcombine deletes all code except "main.2" bb, which is incorrect.

Running opt -instcombine -debug shows pretty interesting things:

INSTCOMBINE ITERATION #0 on main
IC: Mod =       %test.1 = icmp uge i8* %head.0, %arrmax         ; <i1>
[#uses=1]
    New =       %test.1 = icmp uge i8* %head.0, %arrmax         ; <i1>
[#uses=0]
IC: Mod =       %test.3 = or i1 false, %test.2          ; <i1> [#uses=1]
    New =       %test.3 = or i1 %test.2, false          ; <i1> [#uses=0]
IC: Old =       %test.2 = icmp ult i8* %head.0, %arr            ; <i1>
[#uses=1]
    New =       icmp slt i64 65536, 0           ; <i1>:<badref> [#uses=0]
IC: ConstFold to:  i1 false from:       %test.2 = icmp slt i64 65536, 0        
; <i1> [#uses=1]
IC: DCE:        %head.0 = getelementptr i8* %arr, i32 65536             ; <i8*>
[#uses=0]
IC: DCE:        %arrmax = getelementptr i8* %arr, i32 65536             ; <i8*>
[#uses=0]
IC: DCE:        %arr = malloc i8, i32 65536             ; <i8*> [#uses=0]


INSTCOMBINE ITERATION #1 on main
IC: DCE:        call i32 @putchar( i32 89 )             ; <i32>:0 [#uses=0]

Note:
1. It doesn't show the change of first operand of OR to false
2. The change is incorrect, because 65536 uge 65536 = true


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Wed Sep  5 16:55:09 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 5 Sep 2007 16:55:09 -0500
Subject: [LLVMbugs] [Bug 1638] New: povray and lencod are failing on Mac OS
	X / PPC
Message-ID: <bug-1638-206@http.llvm.org/bugs/>

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

           Summary: povray and lencod are failing on Mac OS X / PPC
           Product: libraries
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: major
          Priority: P2
         Component: Backend: PowerPC
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: evan.cheng at apple.com
                CC: llvmbugs at cs.uiuc.edu


Looks like these have been failing for a while.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Wed Sep  5 20:11:15 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 5 Sep 2007 20:11:15 -0500
Subject: [LLVMbugs] [Bug 1637] Instcombine turnes true expression into false
In-Reply-To: <bug-1637-206@http.llvm.org/bugs/>
Message-ID: <200709060111.l861BFQF032308@zion.cs.uiuc.edu>

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


Nick Lewycky <nicholas at mxc.ca> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|enhancement                 |normal
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED
   Target Milestone|---                         |2.1




--- Comment #3 from Nick Lewycky <nicholas at mxc.ca>  2007-09-05 20:11:12 ---
Fixed.

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

Testcase here: test/InstCombine/2007-09-05-EqualGEP.ll


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Wed Sep  5 20:57:08 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 5 Sep 2007 20:57:08 -0500
Subject: [LLVMbugs] [Bug 1639] New: GlobalOpt can' t see through PHI nodes
 when doing SROA on malloc's
Message-ID: <bug-1639-206@http.llvm.org/bugs/>

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

           Summary: GlobalOpt can't see through PHI nodes when doing SROA on
                    malloc's
           Product: new-bugs
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: resistor at mac.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=1102)
 --> (http://llvm.org/bugs/attachment.cgi?id=1102)
gvn-out.bc

GlobalOpt, when it tries to do SROA on malloc's, must ensure that all uses of
the global would trap if the global were null.  This check, however, cannot see
through PHI nodes, which causes a regression on 179.art when using GVN. 
Attached is the example bitcode.  Note that GlobalOpt fails to SROA the global
variable f1_layer because of the instruction %tmp11.rle in init_net().


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Thu Sep  6 00:57:17 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 6 Sep 2007 00:57:17 -0500
Subject: [LLVMbugs] [Bug 1640] New: Compiler crash
Message-ID: <bug-1640-206@http.llvm.org/bugs/>

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

           Summary: Compiler crash
           Product: tools
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P2
         Component: llvm-gcc
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: llvm at rickb.com
                CC: llvmbugs at cs.uiuc.edu


Compiler crashes when trying to compile the attached code. Compiling for Mach-O
ARM. The crash actually occurs when trying to compile the function pointer call
on line 4228.

SelectionDAGISel.cpp:3629: failed assertion `0 && "matching constraints for
memory operands unimp"'
mame/062/src/cpu/z80/z80.c:4583: internal compiler error: Abort trap


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Thu Sep  6 04:52:16 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 6 Sep 2007 04:52:16 -0500
Subject: [LLVMbugs] [Bug 1641] New: ICE: Global initializer should be
	constant!
Message-ID: <bug-1641-206@http.llvm.org/bugs/>

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

           Summary: ICE: Global initializer should be constant!
           Product: tools
           Version: trunk
          Platform: All
        OS/Version: MacOS X
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: llvm-gcc
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: isanbard at gmail.com
                CC: llvmbugs at cs.uiuc.edu


This program:

struct A {
  unsigned long l;
};

static void bork() {
  const unsigned long vcgt = 'vcgt';
  struct A a = { vcgt };
}
void foo() {
  bork();
}

Compiles under GCC but gives this error for LLVM-GCC:

$ llvm-gcc -arch ppc -Os -c testcase.i
Assertion failed: ((TREE_CONSTANT(DECL_INITIAL(decl)) ||
TREE_CODE(DECL_INITIAL(decl)) == STRING_CST) && "Global initializer should be
constant!"), function emit_global_to_llvm, file
../../llvm-gcc-4.0.src/gcc/llvm-backend.cpp, line 777.
testcase.i: In function 'foo':
testcase.i:9: internal compiler error: Abort trap
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://llvm.org/bugs> for instructions.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Thu Sep  6 11:26:28 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 6 Sep 2007 11:26:28 -0500
Subject: [LLVMbugs] [Bug 1642] New: SjLj (setjmp/longjmp) -based exception
 handling in LLVM-GCC seems to be unsupported
Message-ID: <bug-1642-206@http.llvm.org/bugs/>

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

           Summary: SjLj (setjmp/longjmp)-based exception handling in LLVM-
                    GCC seems to be unsupported
           Product: new-bugs
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Keywords: missing-feature, portability
          Severity: enhancement
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: nightwatch41 at gmail.com
                CC: llvmbugs at cs.uiuc.edu


builtin_setjmp() and builtin_longjmp() are unsupported in the latest LLVM-GCC
(per the FIXME at llvm-convert.cpp:4369); however, defining
DONT_USE_BUILTIN_SETJMP as a workaround does not cause the appropriate buffers
to be created at all. cf. except.c, which has several blocks of code to create
the appropriate buffers, bracketed with "if (USING_SJLJ_EXCEPTIONS)".

SjLj-type exceptions would be very helpful for LLVM-GCC, because they're
inherently more portable than the standard target-specific exceptions are.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Thu Sep  6 22:01:01 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 6 Sep 2007 22:01:01 -0500
Subject: [LLVMbugs] [Bug 1643] New: Flags should be different from an expand
 parameter and a divided parameter
Message-ID: <bug-1643-206@http.llvm.org/bugs/>

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

           Summary: Flags should be different from an expand parameter and a
                    divided parameter
           Product: libraries
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: minor
          Priority: P2
         Component: Common Code Generator Code
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: nicolas.geoffray at lip6.fr
                CC: llvmbugs at cs.uiuc.edu


Currently, when doing a call or for formal arguments, SelectionDAG gives a
OrigAlignmentFlag to:
- arguments whose type is expanded (eg i8 -> i32)
- broken up arguments (eg i64 -> i32 + i32)

However the two cases need to have a different flag in the PPC32 ELF ABI. In
this target, arguments are aligned when they are double word, for example:

declare void @foo(i32 %a, i64 %c)

%a goes into register 1
%c goes into registers 3 and 4

The PPC code generator sees three arguments for this function of type i32 and
the last argument has the flag OrigAlignmentFlag. Currently, it can not know if
the last argument is an i64 divided into two i32 or if the last argument is i1,
i8 or i16 which are expanded.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Fri Sep  7 03:19:07 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 7 Sep 2007 03:19:07 -0500
Subject: [LLVMbugs] [Bug 1641] ICE: Global initializer should be constant!
In-Reply-To: <bug-1641-206@http.llvm.org/bugs/>
Message-ID: <200709070819.l878J7eL005327@zion.cs.uiuc.edu>

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


Bill Wendling <isanbard at gmail.com> changed:

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




--- Comment #13 from Bill Wendling <isanbard at gmail.com>  2007-09-07 03:19:07 ---
Fixed:

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

-bw


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Fri Sep  7 06:49:38 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 7 Sep 2007 06:49:38 -0500
Subject: [LLVMbugs] [Bug 1632] codegen of exceptions broken on linux x86-64.
 Brakes gcc bootstrap
In-Reply-To: <bug-1632-206@http.llvm.org/bugs/>
Message-ID: <200709071149.l87BnciM014607@zion.cs.uiuc.edu>

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


Anton Korobeynikov <asl at math.spbu.ru> changed:

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




--- Comment #16 from Anton Korobeynikov <asl at math.spbu.ru>  2007-09-07 06:49:31 ---
Should be fixed in:

http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070903/053314.html
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070903/053315.html
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070903/053316.html

eh.select /eh.typeid.for was splitted into i32/i64 versions.

Please reopen, if stuff is failing again :)


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Fri Sep  7 10:48:08 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 7 Sep 2007 10:48:08 -0500
Subject: [LLVMbugs] [Bug 1632] codegen of exceptions broken on linux x86-64.
 Brakes gcc bootstrap
In-Reply-To: <bug-1632-206@http.llvm.org/bugs/>
Message-ID: <200709071548.l87Fm8R9006360@zion.cs.uiuc.edu>

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


Rafael ??vila de Esp??ndola <rafael.espindola at gmail.com> changed:

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




--- Comment #17 from Rafael ??vila de Esp??ndola <rafael.espindola at gmail.com>  2007-09-07 10:48:07 ---
The program

void g();

void
f() throw()
{
  g();
}

now fails with

/home/espindola/gcc-build/gcc/cc1plus test.cc -emit-llvm
 void f()

Analyzing compilation unit
Performing intraprocedural optimizations
Assembling functions:
 void f()
cc1plus: /home/espindola/llvm/lib/VMCore/Instructions.cpp:2100:
llvm::CmpInst::CmpInst(llvm::Instruction::OtherOps, short unsigned int,
llvm::Value*, llvm::Value*, const std::string&, llvm::Instruction*): Assertion
`Op0Ty == Op1Ty && "Both operands to ICmp instruction are not of the same
type!"' failed.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Fri Sep  7 15:16:54 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 7 Sep 2007 15:16:54 -0500
Subject: [LLVMbugs] [Bug 1644] New: llvm-gcc-4.0 Mac OS X build failure...
 maybe my assember is too old?
Message-ID: <bug-1644-206@http.llvm.org/bugs/>

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

           Summary: llvm-gcc-4.0 Mac OS X build failure... maybe my assember
                    is too old?
           Product: new-bugs
           Version: unspecified
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: tim at tenkan.org
                CC: llvmbugs at cs.uiuc.edu, tim at tenkan.org


Created an attachment (id=1105)
 --> (http://llvm.org/bugs/attachment.cgi?id=1105)
patch to restore buildability on mac os x 10.4.10

When attempting to build llvm-gcc-4.0 from
http://llvm.org/svn/llvm-project/llvm-gcc-4.0/trunk, revision 41769, I saw the
following failure:

/Users/tim/code/c/llvm-gcc/gcc/xgcc -B/Users/tim/code/c/llvm-gcc/gcc/
-B/Users/tim/code/c/llvm-gcc/dst/i686-apple-darwin8/bin/
-B/Users/tim/code/c/llvm-gcc/dst/i686-apple-darwin8/lib/ -isystem
/Users/tim/code/c/llvm-gcc/dst/i686-apple-darwin8/include -isystem
/Users/tim/code/c/llvm-gcc/dst/i686-apple-darwin8/sys-include -O2  -DIN_GCC   
-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition  -isystem ./include  -fPIC -pipe -g -DHAVE_GTHR_DEFAULT
-DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED  -I. -I. -I../../llvm-gcc-4.0/gcc
-I../../llvm-gcc-4.0/gcc/. -I../../llvm-gcc-4.0/gcc/../include -I./../intl
-I../../llvm-gcc-4.0/gcc/../libcpp/include   -DL_gcov -c
../../llvm-gcc-4.0/gcc/libgcov.c -o libgcc/./_gcov.o
In file included from ../../llvm-gcc-4.0/gcc/gcov-io.h:239,
                 from ../../llvm-gcc-4.0/gcc/libgcov.c:51:
./auto-host.h:23:1: warning: "DEFAULT_USE_CXA_ATEXIT" redefined
In file included from ./tm.h:7,
                 from ../../llvm-gcc-4.0/gcc/libgcov.c:39:
../../llvm-gcc-4.0/gcc/defaults.h:712:1: warning: this is the location of the
previous definition
{standard input}:2892:Rest of line ignored. 1st junk character valued 44 (,).
make[2]: *** [libgcc/./_gcov.o] Error 1
make[1]: *** [stmp-multilib] Error 2
make: *** [all-gcc] Error 2

I haven't investigated the warning, but the error on line 2892 turns out to be
an assembler directive that my assembler, (apple's gas version 1.38 that came
with OS/X 10.4.10), doesn't support:

.comm ___gcov_var,4128,5

The .comm directive picks an alignment on its own, and doesn't support passing
one, as described here:
http://developer.apple.com/documentation/DeveloperTools/Reference/Assembler/ASMDirectives/chapter_5_section_4.html#//apple_ref/doc/uid/TP30000823-TPXREF155

Maybe the new assembler in Leopard supports it?  The change to GCC looks like
it happened in late July.

I've attached a patch that works for me.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Fri Sep  7 16:05:04 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 7 Sep 2007 16:05:04 -0500
Subject: [LLVMbugs] [Bug 1645] New: llvm-as refuses to assemble llvm-gcc
 output ( weak references)
Message-ID: <bug-1645-206@http.llvm.org/bugs/>

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

           Summary: llvm-as refuses to assemble llvm-gcc output (weak
                    references)
           Product: new-bugs
           Version: unspecified
          Platform: Other
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: baldrick at free.fr
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=1106)
 --> (http://llvm.org/bugs/attachment.cgi?id=1106)
.ll that doesn't assemble

The attached LLVM assembler was produced by running
llvm-gcc on unwind-dw2.c in the gcc sources with
options -S -emit-llvm, at -O0.  However trying to
assemble it with llvm-as gives

llvm-as unwind-dw2.ll
llvm-as: unwind-dw2.ll:5660,0: Unresolved global references exist:
  i32 (i32) * __gthrw_pthread_cancel

Checking by hand shows that everything is dandy, so
this seems to be an llvm-as bug.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From dalej at apple.com  Fri Sep  7 16:04:00 2007
From: dalej at apple.com (Dale Johannesen)
Date: Fri, 7 Sep 2007 14:04:00 -0700
Subject: [LLVMbugs] [Bug 1644] New: llvm-gcc-4.0 Mac OS X build
	failure... maybe my assember is too old?
In-Reply-To: <bug-1644-206@http.llvm.org/bugs/>
References: <bug-1644-206@http.llvm.org/bugs/>
Message-ID: <6BE71478-A32D-4FC8-B315-3C80F566FCD2@apple.com>


On Sep 7, 2007, at 1:16 PM, bugzilla-daemon at cs.uiuc.edu wrote:
> I haven't investigated the warning, but the error on line 2892  
> turns out to be
> an assembler directive that my assembler, (apple's gas version 1.38  
> that came
> with OS/X 10.4.10), doesn't support:
>
> .comm ___gcov_var,4128,5
>
> The .comm directive picks an alignment on its own, and doesn't  
> support passing
> one, as described here:
> http://developer.apple.com/documentation/DeveloperTools/Reference/ 
> Assembler/ASMDirectives/chapter_5_section_4.html#//apple_ref/doc/ 
> uid/TP30000823-TPXREF155
>
> Maybe the new assembler in Leopard supports it?

I've checked with the assembler expert, and indeed this is a Leopard  
feature that will not be supported in 10.4.

However, the llvm-gcc I built on (x86) 10.4 does the right thing; it  
doesn't get into that code.  This is some sort of configuration  
issue.  I'm asking around to figure it out.  What hardware do you have?



From bugzilla-daemon at cs.uiuc.edu  Sat Sep  8 08:58:51 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 8 Sep 2007 08:58:51 -0500
Subject: [LLVMbugs] [Bug 1635] Syntax for 'call' Instruction is wrong
In-Reply-To: <bug-1635-206@http.llvm.org/bugs/>
Message-ID: <200709081358.l88DwpO3030254@zion.cs.uiuc.edu>

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


Nick Lewycky <nicholas at mxc.ca> changed:

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




--- Comment #2 from Nick Lewycky <nicholas at mxc.ca>  2007-09-08 08:58:50 ---
Applied.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Sat Sep  8 16:07:52 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 8 Sep 2007 16:07:52 -0500
Subject: [LLVMbugs] [Bug 1646] New: Weak alias assumed to be non-null
 results in wrong code for unwind-dw2.c
Message-ID: <bug-1646-206@http.llvm.org/bugs/>

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

           Summary: Weak alias assumed to be non-null results in wrong code
                    for unwind-dw2.c
           Product: new-bugs
           Version: unspecified
          Platform: Other
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: baldrick at free.fr
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=1108)
 --> (http://llvm.org/bugs/attachment.cgi?id=1108)
testcase .ll

The attached testcase is the code used by gcc to test
whether a program was linked with the pthreads library.
LLVM optimizes it to

define i32 @__gthread_active_p() {
entry:
        ret i32 1
}

which is wrong.  Probably it thinks that the weak alias
@__gthrw_pthread_cancel = alias weak i32 (i32)* @pthread_cancel
is necessarily non-null.  The original code was:

static __typeof(pthread_cancel) __gthrw_pthread_cancel __attribute__
((__weakref__("pthread_cancel")));

static __inline__ int
__gthread_active_p (void)
{
  static void *const __gthread_active_ptr
    = __extension__ (void *) &__gthrw_pthread_cancel;
  return __gthread_active_ptr != 0;
}


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Sun Sep  9 09:27:57 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 9 Sep 2007 09:27:57 -0500
Subject: [LLVMbugs] [Bug 1632] codegen of exceptions broken on linux x86-64.
 Brakes gcc bootstrap
In-Reply-To: <bug-1632-206@http.llvm.org/bugs/>
Message-ID: <200709091427.l89ERvrE006871@zion.cs.uiuc.edu>

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


Anton Korobeynikov <asl at math.spbu.ru> changed:

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




--- Comment #21 from Anton Korobeynikov <asl at math.spbu.ru>  2007-09-09 09:27:56 ---
Fixed.

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


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Mon Sep 10 05:27:52 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 10 Sep 2007 05:27:52 -0500
Subject: [LLVMbugs] [Bug 1647] New: volatile attribute lost on pointer array
 dereferences
Message-ID: <bug-1647-206@http.llvm.org/bugs/>

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

           Summary: volatile attribute lost on pointer array dereferences
           Product: tools
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: major
          Priority: P2
         Component: llvm-gcc
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: giuma.cordes at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Looks like the volatile attribute is lost in the llvm-gcc translator when
building an array reference out of a front-end pointer type, for example the
following trivial piece of code:

void foo(volatile int *p)
{
p[0] = 0;
}

produces the following llvm assembly:

; ModuleID = '/tmp/webcompile/_24474_0.bc'
target datalayout =
"e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64"
target triple = "i686-pc-linux-gnu"

define void @foo(i32* %p) {
entry:
        store i32 0, i32* %p
        ret void
}

while expressing the pointer dereference via the pointer dereference op works
ok:

void foo(volatile int *p)
{
*p = 0;
}

define void @foo(i32* %p) {
entry:
        volatile store i32 0, i32* %p
        ret void
}

I believe the problem originates from llv-gcc/gcc/c-typeck.c in function
build_array_ref near conditionally compiled LLVM section line 1893 were the
following piece of code:

      {
        tree ty = TREE_TYPE(TREE_TYPE(ar));
        if (TREE_CODE(ty) != ARRAY_TYPE)
          ty = TYPE_MAIN_VARIANT (ty);
        return build4 (ARRAY_REF, ty, ar, index, NULL_TREE, NULL_TREE);
      }

uses the main variant of the elements pointed to to build an array reference
instead in case of pointer indexed arithmetics.
Look like in doing so the volatile flag attached to the pointer type itself is
lost and not propagated to the array reference (along with possibly some other
attributes I'm not sure about, like side effects etc.)
Replacing the code above with the following one seems to fix the problem:


      {
        tree ty = TREE_TYPE(TREE_TYPE(ar));
        if (TREE_CODE(ty) != ARRAY_TYPE) {
          tree newty = TYPE_MAIN_VARIANT (ty);
          tree ret = build4 (ARRAY_REF, newty, ar, index, NULL_TREE,
NULL_TREE);
          /* we know it's a reference */
          TREE_THIS_VOLATILE(ret) = TREE_THIS_VOLATILE(ty); 
          return ret;
        }
        return build4 (ARRAY_REF, ty, ar, index, NULL_TREE, NULL_TRE


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Mon Sep 10 05:38:23 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 10 Sep 2007 05:38:23 -0500
Subject: [LLVMbugs] [Bug 1647] volatile attribute lost on pointer array
	dereferences
In-Reply-To: <bug-1647-206@http.llvm.org/bugs/>
Message-ID: <200709101038.l8AAcNC1026861@zion.cs.uiuc.edu>

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


Faik Uygur <faik at pardus.org.tr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |faik at pardus.org.tr
             Status|NEW                         |RESOLVED
         Resolution|                            |DUPLICATE




--- Comment #1 from Faik Uygur <faik at pardus.org.tr>  2007-09-10 05:38:20 ---


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


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Mon Sep 10 08:45:56 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 10 Sep 2007 08:45:56 -0500
Subject: [LLVMbugs] [Bug 1647] volatile attribute lost on pointer array
	dereferences
In-Reply-To: <bug-1647-206@http.llvm.org/bugs/>
Message-ID: <200709101345.l8ADjusV001339@zion.cs.uiuc.edu>

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


giuma <giuma.cordes at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|DUPLICATE                   |WONTFIX




--- Comment #2 from giuma <giuma.cordes at gmail.com>  2007-09-10 08:45:55 ---
Hi again,

Sorry to bother again, but the bug is indeed induced by the same code snippet
as of bug 1603 in c-typeck.c, however the patch given for it doesn't fix this
one too.

I'm no gcc front-end expert at all, but it looks to me the volatility flag is
used in a different way that the readonly flag (associated to bug 1603).
Read only is one is applied towards the memory location while the volatility
against the reference itself, in fact the same simple example above still
generates a non volatile store instead of a volatile one even if the patch is
applied.

The problem is that once a build_modify_expr method is invoked in tree.c (e.g.
by the assignment) it finds the volatile_flag of the arg0 (the array reference
built by the previous call to patched build_array_ref code) being false, this
because the flag is instead attached to the type and not the reference itself.
Note that when a pointer dereference is used in place of the array one, the
associated tree contains an indirect_ref with a volatile_flag set.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Mon Sep 10 08:53:20 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 10 Sep 2007 08:53:20 -0500
Subject: [LLVMbugs] [Bug 1647] volatile attribute lost on pointer array
	dereferences
In-Reply-To: <bug-1647-206@http.llvm.org/bugs/>
Message-ID: <200709101353.l8ADrKwh001804@zion.cs.uiuc.edu>

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


Faik Uygur <faik at pardus.org.tr> changed:

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




--- Comment #3 from Faik Uygur <faik at pardus.org.tr>  2007-09-10 08:53:20 ---
(In reply to comment #2)
> I'm no gcc front-end expert at all, but it looks to me the volatility flag is
> used in a different way that the readonly flag (associated to bug 1603).

I'm no expert either. Sorry for the quick and misjudgement. :/ Reopening this
bug.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Mon Sep 10 14:59:59 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 10 Sep 2007 14:59:59 -0500
Subject: [LLVMbugs] [Bug 1648] New: GVN crash - MallocBench/gs
Message-ID: <bug-1648-206@http.llvm.org/bugs/>

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

           Summary: GVN crash - MallocBench/gs
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: Scalar Optimizations
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: dpatel at apple.com
                CC: resistor at mac.com, llvmbugs at cs.uiuc.edu


GVN crashes while optimizing MallocBench/gs benchmark.
$ opt -disable-output -gvn b5.bc


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Mon Sep 10 17:47:25 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 10 Sep 2007 17:47:25 -0500
Subject: [LLVMbugs] [Bug 1644] llvm-gcc-4.0 Mac OS X build failure... maybe
 my assember is too old?
In-Reply-To: <bug-1644-206@http.llvm.org/bugs/>
Message-ID: <200709102247.l8AMlP4J023216@zion.cs.uiuc.edu>

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


Chris Lattner <sabre at nondot.org> changed:

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




--- Comment #2 from Chris Lattner <sabre at nondot.org>  2007-09-10 17:47:25 ---
This works fine for me with "GNU assembler version 1.38".  Please ensure you
configured llvm-gcc with the --emit-llvm option.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Mon Sep 10 18:25:15 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 10 Sep 2007 18:25:15 -0500
Subject: [LLVMbugs] [Bug 1645] llvm-as refuses to assemble llvm-gcc output
 (weak references)
In-Reply-To: <bug-1645-206@http.llvm.org/bugs/>
Message-ID: <200709102325.l8ANPF0a024347@zion.cs.uiuc.edu>

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


Chris Lattner <sabre at nondot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|enhancement                 |normal
             Status|NEW                         |RESOLVED
          Component|new bugs                    |LLVM assembly language
                   |                            |parser
           Keywords|                            |compile-fail
            Product|new-bugs                    |libraries
         Resolution|                            |FIXED
   Target Milestone|---                         |2.1
            Version|unspecified                 |2.0




--- Comment #2 from Chris Lattner <sabre at nondot.org>  2007-09-10 18:25:14 ---
Fixed, patch here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070910/053368.html


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Mon Sep 10 18:29:50 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 10 Sep 2007 18:29:50 -0500
Subject: [LLVMbugs] [Bug 1640] Compiler crash
In-Reply-To: <bug-1640-206@http.llvm.org/bugs/>
Message-ID: <200709102329.l8ANToeM024517@zion.cs.uiuc.edu>

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


Chris Lattner <sabre at nondot.org> changed:

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




--- Comment #3 from Chris Lattner <sabre at nondot.org>  2007-09-10 18:29:47 ---
Matching operands for memory are not implemented yet.  If you paste the
offending inline asm (which is probably coming from a header, not the attached
source), I can suggest a simple change that will make it work.

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


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Mon Sep 10 18:48:18 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 10 Sep 2007 18:48:18 -0500
Subject: [LLVMbugs] [Bug 1646] Weak alias assumed to be non-null results in
 wrong code for unwind-dw2.c
In-Reply-To: <bug-1646-206@http.llvm.org/bugs/>
Message-ID: <200709102348.l8ANmIKX025081@zion.cs.uiuc.edu>

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


Chris Lattner <sabre at nondot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|enhancement                 |normal
             Status|NEW                         |RESOLVED
          Component|new bugs                    |Core LLVM classes
            Product|new-bugs                    |libraries
         Resolution|                            |FIXED
   Target Milestone|---                         |2.1
            Version|unspecified                 |2.0




--- Comment #12 from Chris Lattner <sabre at nondot.org>  2007-09-10 18:48:18 ---
The fix is to tell the constant folding pass to back off from aliases.  We
expect the linker to resolve them as aggressively as possible, so this
shouldn't cause poor codegen.  The code you found in instcombine is actually
dead, as it is only reached if the operands are not both constants.

Both issues are fixed here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070910/053371.html
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070910/053372.html

-Chris


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Mon Sep 10 19:51:40 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 10 Sep 2007 19:51:40 -0500
Subject: [LLVMbugs] [Bug 1634] llvm-g++ 4.0 fails to compile Manta
In-Reply-To: <bug-1634-206@http.llvm.org/bugs/>
Message-ID: <200709110051.l8B0pedQ027207@zion.cs.uiuc.edu>

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


Chris Lattner <sabre at nondot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
          Component|LLVM Codegen                |llvm-gcc
            Product|cfe                         |tools
         Resolution|                            |FIXED
   Target Milestone|---                         |2.1
            Version|unspecified                 |1.0




--- Comment #12 from Chris Lattner <sabre at nondot.org>  2007-09-10 19:51:39 ---
Fixed, patches here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070910/053380.html
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070910/053382.html
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070910/053383.html

Testcase here:
test/C++Frontend/2007-09-10-RecursiveTypeResolution.cpp

-Chris


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Mon Sep 10 23:33:19 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 10 Sep 2007 23:33:19 -0500
Subject: [LLVMbugs] [Bug 1648] GVN crash - MallocBench/gs
In-Reply-To: <bug-1648-206@http.llvm.org/bugs/>
Message-ID: <200709110433.l8B4XJNV002308@zion.cs.uiuc.edu>

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


Owen Anderson <resistor at mac.com> changed:

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




--- Comment #2 from Owen Anderson <resistor at mac.com>  2007-09-10 23:33:19 ---
This is fixed by:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070910/053390.html


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Tue Sep 11 02:09:58 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 11 Sep 2007 02:09:58 -0500
Subject: [LLVMbugs] [Bug 1649] New: Invalid alignment for SSE2 code
Message-ID: <bug-1649-206@http.llvm.org/bugs/>

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

           Summary: Invalid alignment for SSE2 code
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: Backend: X86
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: asl at math.spbu.ru
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=1113)
 --> (http://llvm.org/bugs/attachment.cgi?id=1113)
Function extracted

Consider attached testcase.

In bb79:

bb79:           ; preds = %bb57
        %tmp81 = load double* %tmp68, align 16          ; <double> [#uses=1]
        %tmp82 = sub double -0.000000e+00, %tmp81               ; <double>
[#uses=1]
        store double %tmp82, double* %tmp68, align 16
        %tmp84 = getelementptr [3 x double]* %Raw_Normal, i32 0, i32 1         
; <double*> [#uses=2]
        %tmp85 = load double* %tmp84, align 8           ; <double> [#uses=1]
        %tmp86 = sub double -0.000000e+00, %tmp85               ; <double>
[#uses=1]
        store double %tmp86, double* %tmp84, align 8
        %tmp88 = getelementptr [3 x double]* %Raw_Normal, i32 0, i32 2         
; <double*> [#uses=2]
        %tmp89 = load double* %tmp88, align 8           ; <double> [#uses=1]
        %tmp90 = sub double -0.000000e+00, %tmp89               ; <double>
[#uses=1]
        store double %tmp90, double* %tmp88, align 8
        br label %bb92

This is codegen'ed (-disable-fp-elim) into:

        movsd   .LCPI1_0, %xmm0
        movapd  %xmm0, %xmm1
        xorpd   -104(%ebp), %xmm1
        movsd   %xmm1, -104(%ebp)
        movsd   -96(%ebp), %xmm1
        xorpd   %xmm0, %xmm1
        movsd   %xmm1, -96(%ebp)
        movsd   -88(%ebp), %xmm1
        xorpd   %xmm0, %xmm1
        movsd   %xmm1, -88(%ebp)

We definitely see a problem: even if %ebp is 16-bytes aligned, the access of
temporaries is not aligned at all.

This causes povray miscompilation at -O2.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Tue Sep 11 03:30:37 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 11 Sep 2007 03:30:37 -0500
Subject: [LLVMbugs] [Bug 1650] New: Should provide target-specific hooks for
 selecting preferred EH data emission format
Message-ID: <bug-1650-206@http.llvm.org/bugs/>

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

           Summary: Should provide target-specific hooks for selecting
                    preferred EH data emission format
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: Common Code Generator Code
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: asl at math.spbu.ru
                CC: isanbard at gmail.com, baldrick at free.fr,
                    llvmbugs at cs.uiuc.edu


We really need to have mechanism to allow target:

1. Select data format used for emission of eh/debug data
2. Override data emission procedure.

See, for example, GCC's ASM_PREFERRED_EH_DATA_FORMAT macro and corresponding
handling in dwarf2asm.c

This will be especially needed for carefully handling of EHs on many platforms
without introducing extra code complexity & bunch of knobs.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Tue Sep 11 07:14:15 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 11 Sep 2007 07:14:15 -0500
Subject: [LLVMbugs] [Bug 1651] New: ICE building llvm-gcc-4.2 - invalid free
Message-ID: <bug-1651-206@http.llvm.org/bugs/>

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

           Summary: ICE building llvm-gcc-4.2 - invalid free
           Product: new-bugs
           Version: unspecified
          Platform: Other
        OS/Version: Linux
            Status: NEW
          Keywords: build-problem
          Severity: major
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: kenneth.hoste at elis.ugent.be
                CC: llvmbugs at cs.uiuc.edu


(this is my first bug report here, so please be gentle ;) )

While compiling llvm-gcc-4.2 on Linux/x86 (Fedora Core 4, 32-bit), I ran into
an ICE during stage1. 

More specifically, the following command fails:

/work/LLVM/llvm-gcc-4.2-obj/./gcc/xgcc -B/work/LLVM/llvm-gcc-4.2-obj/./gcc/
-B/work/LLVM/llvm-gcc-4.2-bin/i686-pc-linux-gnu/bin/
-B/work/LLVM/llvm-gcc-4.2-bin/i686-pc-linux-gnu/lib/ -isystem
/work/LLVM/llvm-gcc-4.2-bin/i686-pc-linux-gnu/include -isystem
/work/LLVM/llvm-gcc-4.2-bin/i686-pc-linux-gnu/sys-include -O2 -O2 -g -O2 
-DIN_GCC    -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition  -isystem ./include  -I. -I. -I../../llvm-gcc-4.2/gcc
-I../../llvm-gcc-4.2/gcc/. -I../../llvm-gcc-4.2/gcc/../include
-I../../llvm-gcc-4.2/gcc/../libcpp/include 
-I../../llvm-gcc-4.2/gcc/../libdecnumber -I../libdecnumber
-I/home/kehoste/work/LLVM/llvm/include -I/work/LLVM/llvm-obj/include  -g0
-finhibit-size-directive -fno-inline-functions -fno-exceptions
-fno-zero-initialized-in-bss -fno-toplevel-reorder  -fno-omit-frame-pointer \
  -c ../../llvm-gcc-4.2/gcc/crtstuff.c -DCRT_BEGIN \
  -o crtbegin.o

with

../../llvm-gcc-4.2/gcc/crtstuff.c:1: internal compiler error: Aborted

Running valgrind on it produces the output below. It seems the call to 'erase'
at llvm::PMDataManager::removeNotPreservedAnalysis(llvm::Pass*)
(PassManager.cpp:628) is the cause of this?




==20768== Memcheck, a memory error detector for x86-linux.
==20768== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al.
==20768== Using valgrind-2.4.0, a program supervision framework for x86-linux.
==20768== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al.
==20768== For more details, rerun with: -v
==20768== 
ignoring nonexistent directory
"/work/LLVM/llvm-gcc-4.2-bin/i686-pc-linux-gnu/include"
ignoring nonexistent directory
"/work/LLVM/llvm-gcc-4.2-bin/i686-pc-linux-gnu/sys-include"
ignoring duplicate directory "./include"
ignoring nonexistent directory
"/home/kehoste/work/LLVM/llvm-gcc-4.2-obj/gcc/../lib/gcc/i686-pc-linux-gnu/4.2.1/include"
ignoring nonexistent directory
"/home/kehoste/work/LLVM/llvm-gcc-4.2-obj/gcc/../lib/gcc/i686-pc-linux-gnu/4.2.1/../../../../i686-pc-linux-gnu/include"
ignoring nonexistent directory "/work/LLVM/llvm-gcc-4.2-bin/include"
ignoring nonexistent directory
"/work/LLVM/llvm-gcc-4.2-bin/lib/gcc/i686-pc-linux-gnu/4.2.1/include"
ignoring nonexistent directory
"/work/LLVM/llvm-gcc-4.2-bin/i686-pc-linux-gnu/include"
ignoring duplicate directory "."
ignoring duplicate directory "../../llvm-gcc-4.2/gcc/."
#include "..." search starts here:
#include <...> search starts here:
 .
 ../../llvm-gcc-4.2/gcc
 ../../llvm-gcc-4.2/gcc/../include
 ../../llvm-gcc-4.2/gcc/../libcpp/include
 ../../llvm-gcc-4.2/gcc/../libdecnumber
 ../libdecnumber
 /home/kehoste/work/LLVM/llvm/include
 /work/LLVM/llvm-obj/include
 /work/LLVM/llvm-gcc-4.2-obj/./gcc/include
 /usr/local/include
 /usr/include
End of search list.
GNU C version 4.2.1(llvm) (Based on Apple Inc. build 5530) (i686-pc-linux-gnu)
        compiled by GNU C version 4.2.0.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=8192
Compiler executable checksum: 67319a9093bf38f24f1a85fc8270533a
==20768== Invalid free() / delete / delete[]
==20768==    at 0x1B9098CF: operator delete(void*) (vg_replace_malloc.c:155)
==20768==    by 0x862B67A:
_ZN9__gnu_cxx13new_allocatorISt13_Rb_tree_nodeISt4pairIKPKN4llvm8PassInfoEPNS3_4PassEEEE10deallocateEPSB_j
(new_allocator.h:97)
==20768==    by 0x862B69F: std::_Rb_tree<llvm::PassInfo const*,
std::pair<llvm::PassInfo const* const, llvm::Pass*>,
std::_Select1st<std::pair<llvm::PassInfo const* const, llvm::Pass*> >,
std::less<llvm::PassInfo const*>, std::allocator<std::pair<llvm::PassInfo
const* const, llvm::Pass*> >
>::_M_put_node(std::_Rb_tree_node<std::pair<llvm::PassInfo const* const,
llvm::Pass*> >*) (stl_tree.h:371)
==20768==    by 0x8C64703: std::_Rb_tree<llvm::PassInfo const*,
std::pair<llvm::PassInfo const* const, llvm::Pass*>,
std::_Select1st<std::pair<llvm::PassInfo const* const, llvm::Pass*> >,
std::less<llvm::PassInfo const*>, std::allocator<std::pair<llvm::PassInfo
const* const, llvm::Pass*> >
>::destroy_node(std::_Rb_tree_node<std::pair<llvm::PassInfo const* const,
llvm::Pass*> >*) (stl_tree.h:390)
==20768==    by 0x8D14000: std::_Rb_tree<llvm::PassInfo const*,
std::pair<llvm::PassInfo const* const, llvm::Pass*>,
std::_Select1st<std::pair<llvm::PassInfo const* const, llvm::Pass*> >,
std::less<llvm::PassInfo const*>, std::allocator<std::pair<llvm::PassInfo
const* const, llvm::Pass*> >
>::erase(std::_Rb_tree_iterator<std::pair<llvm::PassInfo const* const,
llvm::Pass*> >) (stl_tree.h:1034)
==20768==    by 0x8D1402B:
_ZNSt3mapIPKN4llvm8PassInfoEPNS0_4PassESt4lessIS3_ESaISt4pairIKS3_S5_EEE5eraseESt17_Rb_tree_iteratorISA_E
(stl_map.h:410)
==20768==    by 0x8D0DB85:
llvm::PMDataManager::removeNotPreservedAnalysis(llvm::Pass*)
(PassManager.cpp:628)
==20768==    by 0x8D1015B: llvm::PMDataManager::add(llvm::Pass*, bool)
(PassManager.cpp:749)
==20768==    by 0x8D10692:
llvm::FunctionPass::assignPassManager(llvm::PMStack&, llvm::PassManagerType)
(PassManager.cpp:1487)
==20768==    by 0x8D190D4:
llvm::FunctionPassManagerImpl::addTopLevelPass(llvm::Pass*)
(PassManager.cpp:164)
==20768==    by 0x8D0E1C6: llvm::PMTopLevelManager::schedulePass(llvm::Pass*)
(PassManager.cpp:445)
==20768==    by 0x8D14ADD: llvm::FunctionPassManagerImpl::add(llvm::Pass*)
(PassManager.cpp:132)
==20768==  Address 0x1BA686A8 is 3896 bytes inside a block of size 4080 alloc'd
==20768==    at 0x1B90939A: operator new(unsigned) (vg_replace_malloc.c:132)
==20768==    by 0x1B96FF56: __gnu_cxx::__pool<true>::_M_reserve_block(unsigned,
unsigned) (mt_allocator.cc:340)
==20768==    by 0x8D0B234:
__gnu_cxx::__mt_alloc<std::_Rb_tree_node<std::pair<int const, llvm::PassInfo*>
>, __gnu_cxx::__common_pool_policy<__gnu_cxx::__pool, true>
>::allocate(unsigned, void const*) (mt_allocator.h:698)
==20768==    by 0x8D0B25B: std::_Rb_tree<int, std::pair<int const,
llvm::PassInfo*>, std::_Select1st<std::pair<int const, llvm::PassInfo*> >,
std::less<int>, std::allocator<std::pair<int const, llvm::PassInfo*> >
>::_M_get_node() (stl_tree.h:356)
==20768==    by 0x8D0B273: std::_Rb_tree<int, std::pair<int const,
llvm::PassInfo*>, std::_Select1st<std::pair<int const, llvm::PassInfo*> >,
std::less<int>, std::allocator<std::pair<int const, llvm::PassInfo*> >
>::_M_create_node(std::pair<int const, llvm::PassInfo*> const&)
(stl_tree.h:365)
==20768==    by 0x8D0B330:
_ZNSt8_Rb_treeIiSt4pairIKiPN4llvm8PassInfoEESt10_Select1stIS5_ESt4lessIiESaIS5_EE9_M_insertEPSt18_Rb_tree_node_baseSD_RKS5_
(stl_tree.h:794)
==20768==    by 0x8D0B487: std::_Rb_tree<int, std::pair<int const,
llvm::PassInfo*>, std::_Select1st<std::pair<int const, llvm::PassInfo*> >,
std::less<int>, std::allocator<std::pair<int const, llvm::PassInfo*> >
>::insert_unique(std::pair<int const, llvm::PassInfo*> const&) (stl_tree.h:883)
==20768==    by 0x8D0B572: std::map<int, llvm::PassInfo*, std::less<int>,
std::allocator<std::pair<int const, llvm::PassInfo*> > >::insert(std::pair<int
const, llvm::PassInfo*> const&) (stl_map.h:360)
==20768==    by 0x8D0B5E3: (anonymous
namespace)::PassRegistrar::RegisterPass(llvm::PassInfo&) (Pass.cpp:157)
==20768==    by 0x8D082C2: llvm::RegisterPassBase::registerPass()
(Pass.cpp:221)
==20768==    by 0x8647CF8: llvm::RegisterPassBase::RegisterPassBase(char
const*, char const*, int, llvm::Pass* (*)(), bool) (PassSupport.h:145)
==20768==    by 0x8D3CBE5: llvm::RegisterPass<(anonymous
namespace)::Verifier>::RegisterPass(char const*, char const*, bool)
(PassSupport.h:169)
==20768== 
==20768== Invalid free() / delete / delete[]
==20768==    at 0x1B9098CF: operator delete(void*) (vg_replace_malloc.c:155)
==20768==    by 0x862B67A:
_ZN9__gnu_cxx13new_allocatorISt13_Rb_tree_nodeISt4pairIKPKN4llvm8PassInfoEPNS3_4PassEEEE10deallocateEPSB_j
(new_allocator.h:97)
==20768==    by 0x862B69F: std::_Rb_tree<llvm::PassInfo const*,
std::pair<llvm::PassInfo const* const, llvm::Pass*>,
std::_Select1st<std::pair<llvm::PassInfo const* const, llvm::Pass*> >,
std::less<llvm::PassInfo const*>, std::allocator<std::pair<llvm::PassInfo
const* const, llvm::Pass*> >
>::_M_put_node(std::_Rb_tree_node<std::pair<llvm::PassInfo const* const,
llvm::Pass*> >*) (stl_tree.h:371)
==20768==    by 0x862B6EF: std::_Rb_tree<llvm::PassInfo const*,
std::pair<llvm::PassInfo const* const, llvm::Pass*>,
std::_Select1st<std::pair<llvm::PassInfo const* const, llvm::Pass*> >,
std::less<llvm::PassInfo const*>, std::allocator<std::pair<llvm::PassInfo
const* const, llvm::Pass*> >
>::_M_destroy_node(std::_Rb_tree_node<std::pair<llvm::PassInfo const* const,
llvm::Pass*> >*) (stl_tree.h:401)
==20768==    by 0x862B737: std::_Rb_tree<llvm::PassInfo const*,
std::pair<llvm::PassInfo const* const, llvm::Pass*>,
std::_Select1st<std::pair<llvm::PassInfo const* const, llvm::Pass*> >,
std::less<llvm::PassInfo const*>, std::allocator<std::pair<llvm::PassInfo
const* const, llvm::Pass*> >
>::_M_erase(std::_Rb_tree_node<std::pair<llvm::PassInfo const* const,
llvm::Pass*> >*) (stl_tree.h:1325)
==20768==    by 0x862B717: std::_Rb_tree<llvm::PassInfo const*,
std::pair<llvm::PassInfo const* const, llvm::Pass*>,
std::_Select1st<std::pair<llvm::PassInfo const* const, llvm::Pass*> >,
std::less<llvm::PassInfo const*>, std::allocator<std::pair<llvm::PassInfo
const* const, llvm::Pass*> >
>::_M_erase(std::_Rb_tree_node<std::pair<llvm::PassInfo const* const,
llvm::Pass*> >*) (stl_tree.h:1323)
==20768==    by 0x862B766: std::_Rb_tree<llvm::PassInfo const*,
std::pair<llvm::PassInfo const* const, llvm::Pass*>,
std::_Select1st<std::pair<llvm::PassInfo const* const, llvm::Pass*> >,
std::less<llvm::PassInfo const*>, std::allocator<std::pair<llvm::PassInfo
const* const, llvm::Pass*> > >::clear() (stl_tree.h:711)
==20768==    by 0x862B7CC: std::map<llvm::PassInfo const*, llvm::Pass*,
std::less<llvm::PassInfo const*>, std::allocator<std::pair<llvm::PassInfo
const* const, llvm::Pass*> > >::clear() (stl_map.h:509)
==20768==    by 0x862B7E3: llvm::PMDataManager::initializeAnalysisInfo()
(PassManagers.h:242)
==20768==    by 0x8D0D975: llvm::PMStack::pop() (PassManager.cpp:1388)
==20768==    by 0x8D10218: llvm::ModulePass::assignPassManager(llvm::PMStack&,
llvm::PassManagerType) (PassManager.cpp:1437)
==20768==    by 0x8D18FEE: llvm::PassManagerImpl::addTopLevelPass(llvm::Pass*)
(PassManager.cpp:294)
==20768==  Address 0x1BAA8A68 is 736 bytes inside a block of size 4080 alloc'd
==20768==    at 0x1B90939A: operator new(unsigned) (vg_replace_malloc.c:132)
==20768==    by 0x1B96FF56: __gnu_cxx::__pool<true>::_M_reserve_block(unsigned,
unsigned) (mt_allocator.cc:340)
==20768==    by 0x8D5F1FC:
__gnu_cxx::__mt_alloc<std::_Rb_tree_node<std::pair<std::string const,
llvm::cl::Option*> >, __gnu_cxx::__common_pool_policy<__gnu_cxx::__pool, true>
>::allocate(unsigned, void const*) (mt_allocator.h:698)
==20768==    by 0x8D5F223: std::_Rb_tree<std::string, std::pair<std::string
const, llvm::cl::Option*>, std::_Select1st<std::pair<std::string const,
llvm::cl::Option*> >, std::less<std::string>,
std::allocator<std::pair<std::string const, llvm::cl::Option*> >
>::_M_get_node() (stl_tree.h:356)
==20768==    by 0x8D5F23B: std::_Rb_tree<std::string, std::pair<std::string
const, llvm::cl::Option*>, std::_Select1st<std::pair<std::string const,
llvm::cl::Option*> >, std::less<std::string>,
std::allocator<std::pair<std::string const, llvm::cl::Option*> >
>::_M_create_node(std::pair<std::string const, llvm::cl::Option*> const&)
(stl_tree.h:365)
==20768==    by 0x8D5F2F8:
_ZNSt8_Rb_treeISsSt4pairIKSsPN4llvm2cl6OptionEESt10_Select1stIS6_ESt4lessISsESaIS6_EE9_M_insertEPSt18_Rb_tree_node_baseSE_RKS6_
(stl_tree.h:794)
==20768==    by 0x8D5F4D8: std::_Rb_tree<std::string, std::pair<std::string
const, llvm::cl::Option*>, std::_Select1st<std::pair<std::string const,
llvm::cl::Option*> >, std::less<std::string>,
std::allocator<std::pair<std::string const, llvm::cl::Option*> >
>::insert_unique(std::pair<std::string const, llvm::cl::Option*> const&)
(stl_tree.h:887)
==20768==    by 0x8D5F53A: std::map<std::string, llvm::cl::Option*,
std::less<std::string>, std::allocator<std::pair<std::string const,
llvm::cl::Option*> > >::insert(std::pair<std::string const, llvm::cl::Option*>
const&) (stl_map.h:360)
==20768==    by 0x8D57A9F: GetOptionInfo(std::vector<llvm::cl::Option*,
std::allocator<llvm::cl::Option*> >&, std::map<std::string, llvm::cl::Option*,
std::less<std::string>, std::allocator<std::pair<std::string const,
llvm::cl::Option*> > >&) (CommandLine.cpp:116)
==20768==    by 0x8D57D0F: llvm::cl::ParseCommandLineOptions(int&, char**, char
const*) (CommandLine.cpp:340)
==20768==    by 0x860C771: llvm_initialize_backend (llvm-backend.cpp:143)
==20768==    by 0x85667B4: backend_init (toplev.c:2089)
==20768== 
==20768== Invalid free() / delete / delete[]
==20768==    at 0x1B9098CF: operator delete(void*) (vg_replace_malloc.c:155)
==20768==    by 0x862B900:
_ZN9__gnu_cxx13new_allocatorISt13_Rb_tree_nodeISt4pairIKPN4llvm10BasicBlockEPNS3_4LoopEEEE10deallocateEPSA_j
(new_allocator.h:97)
==20768==    by 0x862B925: std::_Rb_tree<llvm::BasicBlock*,
std::pair<llvm::BasicBlock* const, llvm::Loop*>,
std::_Select1st<std::pair<llvm::BasicBlock* const, llvm::Loop*> >,
std::less<llvm::BasicBlock*>, std::allocator<std::pair<llvm::BasicBlock* const,
llvm::Loop*> > >::_M_put_node(std::_Rb_tree_node<std::pair<llvm::BasicBlock*
const, llvm::Loop*> >*) (stl_tree.h:371)
==20768==    by 0x862B975: std::_Rb_tree<llvm::BasicBlock*,
std::pair<llvm::BasicBlock* const, llvm::Loop*>,
std::_Select1st<std::pair<llvm::BasicBlock* const, llvm::Loop*> >,
std::less<llvm::BasicBlock*>, std::allocator<std::pair<llvm::BasicBlock* const,
llvm::Loop*> >
>::_M_destroy_node(std::_Rb_tree_node<std::pair<llvm::BasicBlock* const,
llvm::Loop*> >*) (stl_tree.h:401)
==20768==    by 0x862B9BD: std::_Rb_tree<llvm::BasicBlock*,
std::pair<llvm::BasicBlock* const, llvm::Loop*>,
std::_Select1st<std::pair<llvm::BasicBlock* const, llvm::Loop*> >,
std::less<llvm::BasicBlock*>, std::allocator<std::pair<llvm::BasicBlock* const,
llvm::Loop*> > >::_M_erase(std::_Rb_tree_node<std::pair<llvm::BasicBlock*
const, llvm::Loop*> >*) (stl_tree.h:1325)
==20768==    by 0x862B99D: std::_Rb_tree<llvm::BasicBlock*,
std::pair<llvm::BasicBlock* const, llvm::Loop*>,
std::_Select1st<std::pair<llvm::BasicBlock* const, llvm::Loop*> >,
std::less<llvm::BasicBlock*>, std::allocator<std::pair<llvm::BasicBlock* const,
llvm::Loop*> > >::_M_erase(std::_Rb_tree_node<std::pair<llvm::BasicBlock*
const, llvm::Loop*> >*) (stl_tree.h:1323)
==20768==    by 0x8C7A972: std::_Rb_tree<llvm::BasicBlock*,
std::pair<llvm::BasicBlock* const, llvm::Loop*>,
std::_Select1st<std::pair<llvm::BasicBlock* const, llvm::Loop*> >,
std::less<llvm::BasicBlock*>, std::allocator<std::pair<llvm::BasicBlock* const,
llvm::Loop*> > >::clear() (stl_tree.h:667)
==20768==    by 0x8C7A9EB: std::map<llvm::BasicBlock*, llvm::Loop*,
std::less<llvm::BasicBlock*>, std::allocator<std::pair<llvm::BasicBlock* const,
llvm::Loop*> > >::clear() (stl_map.h:465)
==20768==    by 0x8C7792C: llvm::LoopInfo::releaseMemory() (LoopInfo.cpp:115)
==20768==    by 0x8D0E9AF: llvm::PMDataManager::removeDeadPasses(llvm::Pass*,
char const*, llvm::PassDebuggingString) (PassManager.cpp:670)
==20768==    by 0x8D0F671: llvm::FPPassManager::runOnFunction(llvm::Function&)
(PassManager.cpp:1178)
==20768==    by 0x8D0F727: llvm::FPPassManager::runOnModule(llvm::Module&)
(PassManager.cpp:1188)
==20768==  Address 0x1BB135A0 is 3336 bytes inside a block of size 4080 alloc'd
==20768==    at 0x1B90939A: operator new(unsigned) (vg_replace_malloc.c:132)
==20768==    by 0x1B96FF56: __gnu_cxx::__pool<true>::_M_reserve_block(unsigned,
unsigned) (mt_allocator.cc:340)
==20768==    by 0x8CD19E5:
__gnu_cxx::__mt_alloc<std::_Rb_tree_node<std::pair<std::pair<llvm::Type const*,
char> const, llvm::Constant*> >,
__gnu_cxx::__common_pool_policy<__gnu_cxx::__pool, true> >::allocate(unsigned,
void const*) (mt_allocator.h:698)
==20768==    by 0x8CD1A0D: std::_Rb_tree<std::pair<llvm::Type const*, char>,
std::pair<std::pair<llvm::Type const*, char> const, llvm::Constant*>,
std::_Select1st<std::pair<std::pair<llvm::Type const*, char> const,
llvm::Constant*> >, std::less<std::pair<llvm::Type const*, char> >,
std::allocator<std::pair<std::pair<llvm::Type const*, char> const,
llvm::Constant*> > >::_M_get_node() (stl_tree.h:356)
==20768==    by 0x8CD1A25: std::_Rb_tree<std::pair<llvm::Type const*, char>,
std::pair<std::pair<llvm::Type const*, char> const, llvm::Constant*>,
std::_Select1st<std::pair<std::pair<llvm::Type const*, char> const,
llvm::Constant*> >, std::less<std::pair<llvm::Type const*, char> >,
std::allocator<std::pair<std::pair<llvm::Type const*, char> const,
llvm::Constant*> > >::_M_create_node(std::pair<std::pair<llvm::Type const*,
char> const, llvm::Constant*> const&) (stl_tree.h:365)
==20768==    by 0x8CD1AE2:
_ZNSt8_Rb_treeISt4pairIPKN4llvm4TypeEcES0_IKS5_PNS1_8ConstantEESt10_Select1stIS9_ESt4lessIS5_ESaIS9_EE9_M_insertEPSt18_Rb_tree_node_baseSH_RKS9_
(stl_tree.h:794)
==20768==    by 0x8CD1C39: std::_Rb_tree<std::pair<llvm::Type const*, char>,
std::pair<std::pair<llvm::Type const*, char> const, llvm::Constant*>,
std::_Select1st<std::pair<std::pair<llvm::Type const*, char> const,
llvm::Constant*> >, std::less<std::pair<llvm::Type const*, char> >,
std::allocator<std::pair<std::pair<llvm::Type const*, char> const,
llvm::Constant*> > >::insert_unique(std::pair<std::pair<llvm::Type const*,
char> const, llvm::Constant*> const&) (stl_tree.h:883)
==20768==    by 0x8CD1DE1: std::_Rb_tree<std::pair<llvm::Type const*, char>,
std::pair<std::pair<llvm::Type const*, char> const, llvm::Constant*>,
std::_Select1st<std::pair<std::pair<llvm::Type const*, char> const,
llvm::Constant*> >, std::less<std::pair<llvm::Type const*, char> >,
std::allocator<std::pair<std::pair<llvm::Type const*, char> const,
llvm::Constant*> >
>::insert_unique(std::_Rb_tree_iterator<std::pair<std::pair<llvm::Type const*,
char> const, llvm::Constant*> >, std::pair<std::pair<llvm::Type const*, char>
const, llvm::Constant*> const&) (stl_tree.h:905)
==20768==    by 0x8CD2115:
_ZNSt3mapISt4pairIPKN4llvm4TypeEcEPNS1_8ConstantESt4lessIS5_ESaIS0_IKS5_S7_EEE6insertESt17_Rb_tree_iteratorISB_ERKSB_
(stl_map.h:384)
==20768==    by 0x8CD93EA: llvm::ValueMap<char, llvm::Type,
llvm::ConstantAggregateZero, false>::getOrCreate(llvm::Type const*, char
const&) (Constants.cpp:825)
==20768==    by 0x8CC53AD: llvm::ConstantAggregateZero::get(llvm::Type const*)
(Constants.cpp:993)
==20768==    by 0x8CC62F9: llvm::Constant::getNullValue(llvm::Type const*)
(Constants.cpp:122)
==20768== 
==20768== Conditional jump or move depends on uninitialised value(s)
==20768==    at 0x8C826E0: llvm::DenseMap<llvm::BasicBlock*, llvm::Value*,
llvm::DenseMapKeyInfo<llvm::BasicBlock*>
>::CopyFrom(llvm::DenseMap<llvm::BasicBlock*, llvm::Value*,
llvm::DenseMapKeyInfo<llvm::BasicBlock*> > const&) (DenseMap.h:184)
==20768==    by 0x8C827E2: llvm::DenseMap<llvm::BasicBlock*, llvm::Value*,
llvm::DenseMapKeyInfo<llvm::BasicBlock*>
>::DenseMap(llvm::DenseMap<llvm::BasicBlock*, llvm::Value*,
llvm::DenseMapKeyInfo<llvm::BasicBlock*> > const&) (DenseMap.h:63)
==20768==    by 0x8C83191: llvm::DenseMap<llvm::Instruction*,
llvm::DenseMap<llvm::BasicBlock*, llvm::Value*,
llvm::DenseMapKeyInfo<llvm::BasicBlock*> >,
llvm::DenseMapKeyInfo<llvm::Instruction*>
>::InsertIntoBucket(llvm::Instruction* const&,
llvm::DenseMap<llvm::BasicBlock*, llvm::Value*,
llvm::DenseMapKeyInfo<llvm::BasicBlock*> > const&,
std::pair<llvm::Instruction*, llvm::DenseMap<llvm::BasicBlock*, llvm::Value*,
llvm::DenseMapKeyInfo<llvm::BasicBlock*> > >*) (DenseMap.h:228)
==20768==    by 0x8C831EC: llvm::DenseMap<llvm::Instruction*,
llvm::DenseMap<llvm::BasicBlock*, llvm::Value*,
llvm::DenseMapKeyInfo<llvm::BasicBlock*> >,
llvm::DenseMapKeyInfo<llvm::Instruction*> >::operator[](llvm::Instruction*
const&) (DenseMap.h:174)
==20768==    by 0x8C81A0A:
llvm::MemoryDependenceAnalysis::getNonLocalDependency(llvm::Instruction*,
llvm::DenseMap<llvm::BasicBlock*, llvm::Value*,
llvm::DenseMapKeyInfo<llvm::BasicBlock*> >&) (MemoryDependenceAnalysis.cpp:225)
==20768==    by 0x8B8E13B: (anonymous
namespace)::GVN::processNonLocalLoad(llvm::LoadInst*,
llvm::SmallVector<llvm::Instruction*, 4>&) (GVN.cpp:808)
==20768==    by 0x8B8E6D4: (anonymous
namespace)::GVN::processLoad(llvm::LoadInst*, llvm::DenseMap<llvm::Value*,
llvm::LoadInst*, llvm::DenseMapKeyInfo<llvm::Value*> >&,
llvm::SmallVector<llvm::Instruction*, 4>&) (GVN.cpp:880)
==20768==    by 0x8B8E8D0: (anonymous
namespace)::GVN::processInstruction(llvm::Instruction*, (anonymous
namespace)::ValueNumberedSet&, llvm::DenseMap<llvm::Value*, llvm::LoadInst*,
llvm::DenseMapKeyInfo<llvm::Value*> >&, llvm::SmallVector<llvm::Instruction*,
4>&) (GVN.cpp:943)
==20768==    by 0x8B8ECC9: (anonymous
namespace)::GVN::iterateOnFunction(llvm::Function&) (GVN.cpp:1023)
==20768==    by 0x8B8EE1B: (anonymous
namespace)::GVN::runOnFunction(llvm::Function&) (GVN.cpp:985)
==20768==    by 0x8D0F586: llvm::FPPassManager::runOnFunction(llvm::Function&)
(PassManager.cpp:1168)
==20768==    by 0x8D0F727: llvm::FPPassManager::runOnModule(llvm::Module&)
(PassManager.cpp:1188)
==20768== 
==20768== Invalid free() / delete / delete[]
==20768==    at 0x1B9098CF: operator delete(void*) (vg_replace_malloc.c:155)
==20768==    by 0x862D1D6:
__gnu_cxx::new_allocator<llvm::SDNode*>::deallocate(llvm::SDNode**, unsigned)
(new_allocator.h:97)
==20768==    by 0x862D200: std::_Vector_base<llvm::SDNode*,
std::allocator<llvm::SDNode*> >::_M_deallocate(llvm::SDNode**, unsigned)
(stl_vector.h:134)
==20768==    by 0x8983C61: std::vector<llvm::SDNode*,
std::allocator<llvm::SDNode*>
>::_M_insert_aux(__gnu_cxx::__normal_iterator<llvm::SDNode**,
std::vector<llvm::SDNode*, std::allocator<llvm::SDNode*> > >, llvm::SDNode*
const&) (vector.tcc:299)
==20768==    by 0x8983D20: std::vector<llvm::SDNode*,
std::allocator<llvm::SDNode*> >::push_back(llvm::SDNode* const&)
(stl_vector.h:610)
==20768==    by 0x8AAE317: (anonymous namespace)::DAGCombiner::Run(bool)
(DAGCombiner.cpp:546)
==20768==    by 0x8AAE98D: llvm::SelectionDAG::Combine(bool,
llvm::AliasAnalysis&) (DAGCombiner.cpp:4758)
==20768==    by 0x8A5594B:
llvm::SelectionDAGISel::CodeGenAndEmitDAG(llvm::SelectionDAG&)
(SelectionDAGISel.cpp:4614)
==20768==    by 0x8A6B0A3:
llvm::SelectionDAGISel::SelectBasicBlock(llvm::BasicBlock*,
llvm::MachineFunction&, llvm::FunctionLoweringInfo&)
(SelectionDAGISel.cpp:4651)
==20768==    by 0x8A6C6AF:
llvm::SelectionDAGISel::runOnFunction(llvm::Function&)
(SelectionDAGISel.cpp:4352)
==20768==    by 0x897D6A3: (anonymous
namespace)::X86DAGToDAGISel::runOnFunction(llvm::Function&)
(X86ISelDAGToDAG.cpp:122)
==20768==    by 0x8D0F586: llvm::FPPassManager::runOnFunction(llvm::Function&)
(PassManager.cpp:1168)
==20768==  Address 0x1BAAB478 is 80 bytes inside a block of size 4080 alloc'd
==20768==    at 0x1B90939A: operator new(unsigned) (vg_replace_malloc.c:132)
==20768==    by 0x1B96FF56: __gnu_cxx::__pool<true>::_M_reserve_block(unsigned,
unsigned) (mt_allocator.cc:340)
==20768==    by 0x8CB2744: __gnu_cxx::__mt_alloc<std::pair<unsigned,
llvm::TargetMachineRegistry::Entry const*>,
__gnu_cxx::__common_pool_policy<__gnu_cxx::__pool, true> >::allocate(unsigned,
void const*) (mt_allocator.h:698)
==20768==    by 0x8CB276C: std::_Vector_base<std::pair<unsigned,
llvm::TargetMachineRegistry::Entry const*>, std::allocator<std::pair<unsigned,
llvm::TargetMachineRegistry::Entry const*> > >::_M_allocate(unsigned)
(stl_vector.h:117)
==20768==    by 0x8CB2E1A: std::vector<std::pair<unsigned,
llvm::TargetMachineRegistry::Entry const*>, std::allocator<std::pair<unsigned,
llvm::TargetMachineRegistry::Entry const*> >
>::_M_insert_aux(__gnu_cxx::__normal_iterator<std::pair<unsigned,
llvm::TargetMachineRegistry::Entry const*>*, std::vector<std::pair<unsigned,
llvm::TargetMachineRegistry::Entry const*>, std::allocator<std::pair<unsigned,
llvm::TargetMachineRegistry::Entry const*> > > >, std::pair<unsigned,
llvm::TargetMachineRegistry::Entry const*> const&) (vector.tcc:275)
==20768==    by 0x8CB3072: std::vector<std::pair<unsigned,
llvm::TargetMachineRegistry::Entry const*>, std::allocator<std::pair<unsigned,
llvm::TargetMachineRegistry::Entry const*> > >::push_back(std::pair<unsigned,
llvm::TargetMachineRegistry::Entry const*> const&) (stl_vector.h:610)
==20768==    by 0x8CB1A78:
llvm::TargetMachineRegistry::getClosestStaticTargetForModule(llvm::Module
const&, std::string&) (TargetMachineRegistry.cpp:58)
==20768==    by 0x860CA60: llvm_initialize_backend (llvm-backend.cpp:167)
==20768==    by 0x85667B4: backend_init (toplev.c:2089)
==20768==    by 0x85669AE: do_compile (toplev.c:2252)
==20768==    by 0x8566A29: toplev_main (toplev.c:2288)
==20768==    by 0x8112BB3: main (llvm-main.cpp:39)
==20768== 
==20768== Invalid free() / delete / delete[]
==20768==    at 0x1B9098CF: operator delete(void*) (vg_replace_malloc.c:155)
==20768==    by 0x862D1D6:
__gnu_cxx::new_allocator<llvm::SDNode*>::deallocate(llvm::SDNode**, unsigned)
(new_allocator.h:97)
==20768==    by 0x862D200: std::_Vector_base<llvm::SDNode*,
std::allocator<llvm::SDNode*> >::_M_deallocate(llvm::SDNode**, unsigned)
(stl_vector.h:134)
==20768==    by 0x862D27D: std::_Vector_base<llvm::SDNode*,
std::allocator<llvm::SDNode*> >::~_Vector_base() (stl_vector.h:120)
==20768==    by 0x862D2DF: std::vector<llvm::SDNode*,
std::allocator<llvm::SDNode*> >::~vector() (stl_vector.h:268)
==20768==    by 0x8AAF308: (anonymous namespace)::DAGCombiner::~DAGCombiner()
(DAGCombiner.cpp:76)
==20768==    by 0x8AAE99C: llvm::SelectionDAG::Combine(bool,
llvm::AliasAnalysis&) (DAGCombiner.cpp:4758)
==20768==    by 0x8A5594B:
llvm::SelectionDAGISel::CodeGenAndEmitDAG(llvm::SelectionDAG&)
(SelectionDAGISel.cpp:4614)
==20768==    by 0x8A6B0A3:
llvm::SelectionDAGISel::SelectBasicBlock(llvm::BasicBlock*,
llvm::MachineFunction&, llvm::FunctionLoweringInfo&)
(SelectionDAGISel.cpp:4651)
==20768==    by 0x8A6C6AF:
llvm::SelectionDAGISel::runOnFunction(llvm::Function&)
(SelectionDAGISel.cpp:4352)
==20768==    by 0x897D6A3: (anonymous
namespace)::X86DAGToDAGISel::runOnFunction(llvm::Function&)
(X86ISelDAGToDAG.cpp:122)
==20768==    by 0x8D0F586: llvm::FPPassManager::runOnFunction(llvm::Function&)
(PassManager.cpp:1168)
==20768==  Address 0x1BE49B60 is 2936 bytes inside a block of size 4080 alloc'd
==20768==    at 0x1B90939A: operator new(unsigned) (vg_replace_malloc.c:132)
==20768==    by 0x1B96FF56: __gnu_cxx::__pool<true>::_M_reserve_block(unsigned,
unsigned) (mt_allocator.cc:340)
==20768==    by 0x8D17FBC:
__gnu_cxx::__mt_alloc<std::_Rb_tree_node<std::pair<llvm::PassInfo const* const,
llvm::Pass*> >, __gnu_cxx::__common_pool_policy<__gnu_cxx::__pool, true>
>::allocate(unsigned, void const*) (mt_allocator.h:698)
==20768==    by 0x8D17FE3: std::_Rb_tree<llvm::PassInfo const*,
std::pair<llvm::PassInfo const* const, llvm::Pass*>,
std::_Select1st<std::pair<llvm::PassInfo const* const, llvm::Pass*> >,
std::less<llvm::PassInfo const*>, std::allocator<std::pair<llvm::PassInfo
const* const, llvm::Pass*> > >::_M_get_node() (stl_tree.h:356)
==20768==    by 0x8D17FFB: std::_Rb_tree<llvm::PassInfo const*,
std::pair<llvm::PassInfo const* const, llvm::Pass*>,
std::_Select1st<std::pair<llvm::PassInfo const* const, llvm::Pass*> >,
std::less<llvm::PassInfo const*>, std::allocator<std::pair<llvm::PassInfo
const* const, llvm::Pass*> > >::_M_create_node(std::pair<llvm::PassInfo const*
const, llvm::Pass*> const&) (stl_tree.h:365)
==20768==    by 0x8D180B8:
_ZNSt8_Rb_treeIPKN4llvm8PassInfoESt4pairIKS3_PNS0_4PassEESt10_Select1stIS8_ESt4lessIS3_ESaIS8_EE9_M_insertEPSt18_Rb_tree_node_baseSG_RKS8_
(stl_tree.h:794)
==20768==    by 0x8D18515: std::_Rb_tree<llvm::PassInfo const*,
std::pair<llvm::PassInfo const* const, llvm::Pass*>,
std::_Select1st<std::pair<llvm::PassInfo const* const, llvm::Pass*> >,
std::less<llvm::PassInfo const*>, std::allocator<std::pair<llvm::PassInfo
const* const, llvm::Pass*> >
>::insert_unique(std::_Rb_tree_iterator<std::pair<llvm::PassInfo const* const,
llvm::Pass*> >, std::pair<llvm::PassInfo const* const, llvm::Pass*> const&)
(stl_tree.h:921)
==20768==    by 0x8D186EB:
_ZNSt3mapIPKN4llvm8PassInfoEPNS0_4PassESt4lessIS3_ESaISt4pairIKS3_S5_EEE6insertESt17_Rb_tree_iteratorISA_ERKSA_
(stl_map.h:384)
==20768==    by 0x8D187CA: std::map<llvm::PassInfo const*, llvm::Pass*,
std::less<llvm::PassInfo const*>, std::allocator<std::pair<llvm::PassInfo
const* const, llvm::Pass*> > >::operator[](llvm::PassInfo const* const&)
(stl_map.h:339)
==20768==    by 0x8D0F0E0:
llvm::PMDataManager::recordAvailableAnalysis(llvm::Pass*) (PassManager.cpp:564)
==20768==    by 0x8D0F64C: llvm::FPPassManager::runOnFunction(llvm::Function&)
(PassManager.cpp:1177)
==20768==    by 0x8D0F727: llvm::FPPassManager::runOnModule(llvm::Module&)
(PassManager.cpp:1188)
==20768== 
==20768== Invalid free() / delete / delete[]
==20768==    at 0x1B9098CF: operator delete(void*) (vg_replace_malloc.c:155)
==20768==    by 0x862D064:
__gnu_cxx::new_allocator<llvm::SUnit*>::deallocate(llvm::SUnit**, unsigned)
(new_allocator.h:97)
==20768==    by 0x862D08E: std::_Vector_base<llvm::SUnit*,
std::allocator<llvm::SUnit*> >::_M_deallocate(llvm::SUnit**, unsigned)
(stl_vector.h:134)
==20768==    by 0x8AE6ABF: std::vector<llvm::SUnit*,
std::allocator<llvm::SUnit*>
>::_M_insert_aux(__gnu_cxx::__normal_iterator<llvm::SUnit**,
std::vector<llvm::SUnit*, std::allocator<llvm::SUnit*> > >, llvm::SUnit*
const&) (vector.tcc:299)
==20768==    by 0x8AE6B7E: std::vector<llvm::SUnit*,
std::allocator<llvm::SUnit*> >::push_back(llvm::SUnit* const&)
(stl_vector.h:610)
==20768==    by 0x8AEB15A: std::priority_queue<llvm::SUnit*,
std::vector<llvm::SUnit*, std::allocator<llvm::SUnit*> >, (anonymous
namespace)::bu_ls_rr_sort>::push(llvm::SUnit* const&) (stl_queue.h:429)
==20768==    by 0x8AEB22A: (anonymous
namespace)::RegReductionPriorityQueue<(anonymous
namespace)::bu_ls_rr_sort>::push(llvm::SUnit*) (ScheduleDAGRRList.cpp:445)
==20768==    by 0x8AE8CB8: (anonymous
namespace)::ScheduleDAGRRList::ListScheduleBottomUp()
(ScheduleDAGRRList.cpp:232)
==20768==    by 0x8AE90FB: (anonymous namespace)::ScheduleDAGRRList::Schedule()
(ScheduleDAGRRList.cpp:100)
==20768==    by 0x8ADDA43: llvm::ScheduleDAG::Run() (ScheduleDAG.cpp:834)
==20768==    by 0x8A55B9C:
llvm::SelectionDAGISel::ScheduleAndEmitDAG(llvm::SelectionDAG&)
(SelectionDAGISel.cpp:4857)
==20768==    by 0x8949D0A: (anonymous
namespace)::X86DAGToDAGISel::InstructionSelectBasicBlock(llvm::SelectionDAG&)
(X86ISelDAGToDAG.cpp:479)
==20768==  Address 0x1BAAB528 is 256 bytes inside a block of size 4080 alloc'd
==20768==    at 0x1B90939A: operator new(unsigned) (vg_replace_malloc.c:132)
==20768==    by 0x1B96FF56: __gnu_cxx::__pool<true>::_M_reserve_block(unsigned,
unsigned) (mt_allocator.cc:340)
==20768==    by 0x8CB2744: __gnu_cxx::__mt_alloc<std::pair<unsigned,
llvm::TargetMachineRegistry::Entry const*>,
__gnu_cxx::__common_pool_policy<__gnu_cxx::__pool, true> >::allocate(unsigned,
void const*) (mt_allocator.h:698)
==20768==    by 0x8CB276C: std::_Vector_base<std::pair<unsigned,
llvm::TargetMachineRegistry::Entry const*>, std::allocator<std::pair<unsigned,
llvm::TargetMachineRegistry::Entry const*> > >::_M_allocate(unsigned)
(stl_vector.h:117)
==20768==    by 0x8CB2E1A: std::vector<std::pair<unsigned,
llvm::TargetMachineRegistry::Entry const*>, std::allocator<std::pair<unsigned,
llvm::TargetMachineRegistry::Entry const*> >
>::_M_insert_aux(__gnu_cxx::__normal_iterator<std::pair<unsigned,
llvm::TargetMachineRegistry::Entry const*>*, std::vector<std::pair<unsigned,
llvm::TargetMachineRegistry::Entry const*>, std::allocator<std::pair<unsigned,
llvm::TargetMachineRegistry::Entry const*> > > >, std::pair<unsigned,
llvm::TargetMachineRegistry::Entry const*> const&) (vector.tcc:275)
==20768==    by 0x8CB3072: std::vector<std::pair<unsigned,
llvm::TargetMachineRegistry::Entry const*>, std::allocator<std::pair<unsigned,
llvm::TargetMachineRegistry::Entry const*> > >::push_back(std::pair<unsigned,
llvm::TargetMachineRegistry::Entry const*> const&) (stl_vector.h:610)
==20768==    by 0x8CB1A78:
llvm::TargetMachineRegistry::getClosestStaticTargetForModule(llvm::Module
const&, std::string&) (TargetMachineRegistry.cpp:58)
==20768==    by 0x860CA60: llvm_initialize_backend (llvm-backend.cpp:167)
==20768==    by 0x85667B4: backend_init (toplev.c:2089)
==20768==    by 0x85669AE: do_compile (toplev.c:2252)
==20768==    by 0x8566A29: toplev_main (toplev.c:2288)
==20768==    by 0x8112BB3: main (llvm-main.cpp:39)
==20768== 
==20768== Invalid free() / delete / delete[]
==20768==    at 0x1B9098CF: operator delete(void*) (vg_replace_malloc.c:155)
==20768==    by 0x862D064:
__gnu_cxx::new_allocator<llvm::SUnit*>::deallocate(llvm::SUnit**, unsigned)
(new_allocator.h:97)
==20768==    by 0x862D08E: std::_Vector_base<llvm::SUnit*,
std::allocator<llvm::SUnit*> >::_M_deallocate(llvm::SUnit**, unsigned)
(stl_vector.h:134)
==20768==    by 0x862D10B: std::_Vector_base<llvm::SUnit*,
std::allocator<llvm::SUnit*> >::~_Vector_base() (stl_vector.h:120)
==20768==    by 0x862D16D: std::vector<llvm::SUnit*,
std::allocator<llvm::SUnit*> >::~vector() (stl_vector.h:268)
==20768==    by 0x8AE982F: std::priority_queue<llvm::SUnit*,
std::vector<llvm::SUnit*, std::allocator<llvm::SUnit*> >, (anonymous
namespace)::bu_ls_rr_sort>::~priority_queue() (stl_queue.h:338)
==20768==    by 0x8AE98E8: (anonymous
namespace)::RegReductionPriorityQueue<(anonymous
namespace)::bu_ls_rr_sort>::~RegReductionPriorityQueue()
(ScheduleDAGRRList.cpp:398)
==20768==    by 0x8AEA4A5: (anonymous
namespace)::BURegReductionPriorityQueue<(anonymous
namespace)::bu_ls_rr_sort>::~BURegReductionPriorityQueue()
(ScheduleDAGRRList.cpp:466)
==20768==    by 0x8AE9693: (anonymous
namespace)::ScheduleDAGRRList::~ScheduleDAGRRList() (ScheduleDAGRRList.cpp:67)
==20768==    by 0x8A55BE1:
llvm::SelectionDAGISel::ScheduleAndEmitDAG(llvm::SelectionDAG&)
(SelectionDAGISel.cpp:4861)
==20768==    by 0x8949D0A: (anonymous
namespace)::X86DAGToDAGISel::InstructionSelectBasicBlock(llvm::SelectionDAG&)
(X86ISelDAGToDAG.cpp:479)
==20768==    by 0x8A55A70:
llvm::SelectionDAGISel::CodeGenAndEmitDAG(llvm::SelectionDAG&)
(SelectionDAGISel.cpp:4633)
==20768==  Address 0x1BAAB538 is 272 bytes inside a block of size 4080 alloc'd
==20768==    at 0x1B90939A: operator new(unsigned) (vg_replace_malloc.c:132)
==20768==    by 0x1B96FF56: __gnu_cxx::__pool<true>::_M_reserve_block(unsigned,
unsigned) (mt_allocator.cc:340)
==20768==    by 0x8CB2744: __gnu_cxx::__mt_alloc<std::pair<unsigned,
llvm::TargetMachineRegistry::Entry const*>,
__gnu_cxx::__common_pool_policy<__gnu_cxx::__pool, true> >::allocate(unsigned,
void const*) (mt_allocator.h:698)
==20768==    by 0x8CB276C: std::_Vector_base<std::pair<unsigned,
llvm::TargetMachineRegistry::Entry const*>, std::allocator<std::pair<unsigned,
llvm::TargetMachineRegistry::Entry const*> > >::_M_allocate(unsigned)
(stl_vector.h:117)
==20768==    by 0x8CB2E1A: std::vector<std::pair<unsigned,
llvm::TargetMachineRegistry::Entry const*>, std::allocator<std::pair<unsigned,
llvm::TargetMachineRegistry::Entry const*> >
>::_M_insert_aux(__gnu_cxx::__normal_iterator<std::pair<unsigned,
llvm::TargetMachineRegistry::Entry const*>*, std::vector<std::pair<unsigned,
llvm::TargetMachineRegistry::Entry const*>, std::allocator<std::pair<unsigned,
llvm::TargetMachineRegistry::Entry const*> > > >, std::pair<unsigned,
llvm::TargetMachineRegistry::Entry const*> const&) (vector.tcc:275)
==20768==    by 0x8CB3072: std::vector<std::pair<unsigned,
llvm::TargetMachineRegistry::Entry const*>, std::allocator<std::pair<unsigned,
llvm::TargetMachineRegistry::Entry const*> > >::push_back(std::pair<unsigned,
llvm::TargetMachineRegistry::Entry const*> const&) (stl_vector.h:610)
==20768==    by 0x8CB1A78:
llvm::TargetMachineRegistry::getClosestStaticTargetForModule(llvm::Module
const&, std::string&) (TargetMachineRegistry.cpp:58)
==20768==    by 0x860CA60: llvm_initialize_backend (llvm-backend.cpp:167)
==20768==    by 0x85667B4: backend_init (toplev.c:2089)
==20768==    by 0x85669AE: do_compile (toplev.c:2252)
==20768==    by 0x8566A29: toplev_main (toplev.c:2288)
==20768==    by 0x8112BB3: main (llvm-main.cpp:39)
==20768== 
==20768== Invalid free() / delete / delete[]
==20768==    at 0x1B9098CF: operator delete(void*) (vg_replace_malloc.c:155)
==20768==    by 0x862D4BA:
__gnu_cxx::new_allocator<std::_List_node<std::vector<unsigned,
std::allocator<unsigned> > >
>::deallocate(std::_List_node<std::vector<unsigned, std::allocator<unsigned> >
>*, unsigned) (new_allocator.h:97)
==20768==    by 0x862D4DF: std::_List_base<std::vector<unsigned,
std::allocator<unsigned> >, std::allocator<std::vector<unsigned,
std::allocator<unsigned> > >
>::_M_put_node(std::_List_node<std::vector<unsigned, std::allocator<unsigned> >
>*) (stl_list.h:321)
==20768==    by 0x862E0C9: std::_List_base<std::vector<unsigned,
std::allocator<unsigned> >, std::allocator<std::vector<unsigned,
std::allocator<unsigned> > > >::_M_clear() (list.tcc:79)
==20768==    by 0x862E108: std::_List_base<std::vector<unsigned,
std::allocator<unsigned> >, std::allocator<std::vector<unsigned,
std::allocator<unsigned> > > >::~_List_base() (stl_list.h:348)
==20768==    by 0x862E126: std::list<std::vector<unsigned,
std::allocator<unsigned> >, std::allocator<std::vector<unsigned,
std::allocator<unsigned> > > >::~list() (stl_list.h:408)
==20768==    by 0x8A39E50: llvm::SelectionDAG::~SelectionDAG()
(SelectionDAG.cpp:669)
==20768==    by 0x8A6B0B5:
llvm::SelectionDAGISel::SelectBasicBlock(llvm::BasicBlock*,
llvm::MachineFunction&, llvm::FunctionLoweringInfo&)
(SelectionDAGISel.cpp:4651)
==20768==    by 0x8A6C6AF:
llvm::SelectionDAGISel::runOnFunction(llvm::Function&)
(SelectionDAGISel.cpp:4352)
==20768==    by 0x897D6A3: (anonymous
namespace)::X86DAGToDAGISel::runOnFunction(llvm::Function&)
(X86ISelDAGToDAG.cpp:122)
==20768==    by 0x8D0F586: llvm::FPPassManager::runOnFunction(llvm::Function&)
(PassManager.cpp:1168)
==20768==    by 0x8D0F7F0: llvm::FunctionPassManagerImpl::run(llvm::Function&)
(PassManager.cpp:1126)
==20768==  Address 0x1BE49BB0 is 3016 bytes inside a block of size 4080 alloc'd
==20768==    at 0x1B90939A: operator new(unsigned) (vg_replace_malloc.c:132)
==20768==    by 0x1B96FF56: __gnu_cxx::__pool<true>::_M_reserve_block(unsigned,
unsigned) (mt_allocator.cc:340)
==20768==    by 0x8D17FBC:
__gnu_cxx::__mt_alloc<std::_Rb_tree_node<std::pair<llvm::PassInfo const* const,
llvm::Pass*> >, __gnu_cxx::__common_pool_policy<__gnu_cxx::__pool, true>
>::allocate(unsigned, void const*) (mt_allocator.h:698)
==20768==    by 0x8D17FE3: std::_Rb_tree<llvm::PassInfo const*,
std::pair<llvm::PassInfo const* const, llvm::Pass*>,
std::_Select1st<std::pair<llvm::PassInfo const* const, llvm::Pass*> >,
std::less<llvm::PassInfo const*>, std::allocator<std::pair<llvm::PassInfo
const* const, llvm::Pass*> > >::_M_get_node() (stl_tree.h:356)
==20768==    by 0x8D17FFB: std::_Rb_tree<llvm::PassInfo const*,
std::pair<llvm::PassInfo const* const, llvm::Pass*>,
std::_Select1st<std::pair<llvm::PassInfo const* const, llvm::Pass*> >,
std::less<llvm::PassInfo const*>, std::allocator<std::pair<llvm::PassInfo
const* const, llvm::Pass*> > >::_M_create_node(std::pair<llvm::PassInfo const*
const, llvm::Pass*> const&) (stl_tree.h:365)
==20768==    by 0x8D180B8:
_ZNSt8_Rb_treeIPKN4llvm8PassInfoESt4pairIKS3_PNS0_4PassEESt10_Select1stIS8_ESt4lessIS3_ESaIS8_EE9_M_insertEPSt18_Rb_tree_node_baseSG_RKS8_
(stl_tree.h:794)
==20768==    by 0x8D18515: std::_Rb_tree<llvm::PassInfo const*,
std::pair<llvm::PassInfo const* const, llvm::Pass*>,
std::_Select1st<std::pair<llvm::PassInfo const* const, llvm::Pass*> >,
std::less<llvm::PassInfo const*>, std::allocator<std::pair<llvm::PassInfo
const* const, llvm::Pass*> >
>::insert_unique(std::_Rb_tree_iterator<std::pair<llvm::PassInfo const* const,
llvm::Pass*> >, std::pair<llvm::PassInfo const* const, llvm::Pass*> const&)
(stl_tree.h:921)
==20768==    by 0x8D186EB:
_ZNSt3mapIPKN4llvm8PassInfoEPNS0_4PassESt4lessIS3_ESaISt4pairIKS3_S5_EEE6insertESt17_Rb_tree_iteratorISA_ERKSA_
(stl_map.h:384)
==20768==    by 0x8D187CA: std::map<llvm::PassInfo const*, llvm::Pass*,
std::less<llvm::PassInfo const*>, std::allocator<std::pair<llvm::PassInfo
const* const, llvm::Pass*> > >::operator[](llvm::PassInfo const* const&)
(stl_map.h:339)
==20768==    by 0x8D0F0E0:
llvm::PMDataManager::recordAvailableAnalysis(llvm::Pass*) (PassManager.cpp:564)
==20768==    by 0x8D0F64C: llvm::FPPassManager::runOnFunction(llvm::Function&)
(PassManager.cpp:1177)
==20768==    by 0x8D0F727: llvm::FPPassManager::runOnModule(llvm::Module&)
(PassManager.cpp:1188)
==20768== 
==20768== Invalid free() / delete / delete[]
==20768==    at 0x1B9098CF: operator delete(void*) (vg_replace_malloc.c:155)
==20768==    by 0x862D348:
__gnu_cxx::new_allocator<llvm::CondCodeSDNode*>::deallocate(llvm::CondCodeSDNode**,
unsigned) (new_allocator.h:97)
==20768==    by 0x862D372: std::_Vector_base<llvm::CondCodeSDNode*,
std::allocator<llvm::CondCodeSDNode*> >::_M_deallocate(llvm::CondCodeSDNode**,
unsigned) (stl_vector.h:134)
==20768==    by 0x862D3EF: std::_Vector_base<llvm::CondCodeSDNode*,
std::allocator<llvm::CondCodeSDNode*> >::~_Vector_base() (stl_vector.h:120)
==20768==    by 0x862D451: std::vector<llvm::CondCodeSDNode*,
std::allocator<llvm::CondCodeSDNode*> >::~vector() (stl_vector.h:268)
==20768==    by 0x8A39E3E: llvm::SelectionDAG::~SelectionDAG()
(SelectionDAG.cpp:669)
==20768==    by 0x8A6B0B5:
llvm::SelectionDAGISel::SelectBasicBlock(llvm::BasicBlock*,
llvm::MachineFunction&, llvm::FunctionLoweringInfo&)
(SelectionDAGISel.cpp:4651)
==20768==    by 0x8A6C6AF:
llvm::SelectionDAGISel::runOnFunction(llvm::Function&)
(SelectionDAGISel.cpp:4352)
==20768==    by 0x897D6A3: (anonymous
namespace)::X86DAGToDAGISel::runOnFunction(llvm::Function&)
(X86ISelDAGToDAG.cpp:122)
==20768==    by 0x8D0F586: llvm::FPPassManager::runOnFunction(llvm::Function&)
(PassManager.cpp:1168)
==20768==    by 0x8D0F7F0: llvm::FunctionPassManagerImpl::run(llvm::Function&)
(PassManager.cpp:1126)
==20768==    by 0x8D0F93A: llvm::FunctionPassManager::run(llvm::Function&)
(PassManager.cpp:1071)
==20768==  Address 0x1BB15B58 is 560 bytes inside a block of size 4080 alloc'd
==20768==    at 0x1B90939A: operator new(unsigned) (vg_replace_malloc.c:132)
==20768==    by 0x1B96FF56: __gnu_cxx::__pool<true>::_M_reserve_block(unsigned,
unsigned) (mt_allocator.cc:340)
==20768==    by 0x88F6186: __gnu_cxx::__mt_alloc<llvm::Instruction*,
__gnu_cxx::__common_pool_policy<__gnu_cxx::__pool, true> >::allocate(unsigned,
void const*) (mt_allocator.h:698)
==20768==    by 0x88F61AE: std::_Vector_base<llvm::Instruction*,
std::allocator<llvm::Instruction*> >::_M_allocate(unsigned) (stl_vector.h:117)
==20768==    by 0x88F7C82: std::vector<llvm::Instruction*,
std::allocator<llvm::Instruction*>
>::_M_insert_aux(__gnu_cxx::__normal_iterator<llvm::Instruction**,
std::vector<llvm::Instruction*, std::allocator<llvm::Instruction*> > >,
llvm::Instruction* const&) (vector.tcc:275)
==20768==    by 0x88F7EDA: std::vector<llvm::Instruction*,
std::allocator<llvm::Instruction*> >::push_back(llvm::Instruction* const&)
(stl_vector.h:610)
==20768==    by 0x8BD72E4: (anonymous
namespace)::InstCombiner::AddToWorkList(llvm::Instruction*)
(InstructionCombining.cpp:86)
==20768==    by 0x8BCF6AD: AddReachableCodeToWorklist(llvm::BasicBlock*,
llvm::SmallPtrSet<llvm::BasicBlock*, 64>&, (anonymous
namespace)::InstCombiner&, llvm::TargetData const*)
(InstructionCombining.cpp:9940)
==20768==    by 0x8BCFA46: (anonymous
namespace)::InstCombiner::DoOneIteration(llvm::Function&, unsigned)
(InstructionCombining.cpp:9984)
==20768==    by 0x8BD03BA: (anonymous
namespace)::InstCombiner::runOnFunction(llvm::Function&)
(InstructionCombining.cpp:10143)
==20768==    by 0x8D0F586: llvm::FPPassManager::runOnFunction(llvm::Function&)
(PassManager.cpp:1168)
==20768==    by 0x8D0F7F0: llvm::FunctionPassManagerImpl::run(llvm::Function&)
(PassManager.cpp:1126)
==20768== 
==20768== Invalid free() / delete / delete[]
==20768==    at 0x1B9098CF: operator delete(void*) (vg_replace_malloc.c:155)
==20768==    by 0x862E1A4: __gnu_cxx::new_allocator<int>::deallocate(int*,
unsigned) (new_allocator.h:97)
==20768==    by 0x862E1CE: std::_Vector_base<int, std::allocator<int>
>::_M_deallocate(int*, unsigned) (stl_vector.h:134)
==20768==    by 0x862E24B: std::_Vector_base<int, std::allocator<int>
>::~_Vector_base() (stl_vector.h:120)
==20768==    by 0x862E2AD: std::vector<int, std::allocator<int> >::~vector()
(stl_vector.h:268)
==20768==    by 0x8B4A247: llvm::IndexedMap<int,
llvm::VirtReg2IndexFunctor>::~IndexedMap() (IndexedMap.h:36)
==20768==    by 0x8B4DC38: llvm::VirtRegMap::~VirtRegMap() (VirtRegMap.h:31)
==20768==    by 0x8B4DE76:
std::auto_ptr<llvm::VirtRegMap>::reset(llvm::VirtRegMap*) (memory:333)
==20768==    by 0x8B4717C: (anonymous
namespace)::RALinScan::runOnMachineFunction(llvm::MachineFunction&)
(RegAllocLinearScan.cpp:220)
==20768==    by 0x869B117:
llvm::MachineFunctionPass::runOnFunction(llvm::Function&)
(MachineFunctionPass.h:41)
==20768==    by 0x8D0F586: llvm::FPPassManager::runOnFunction(llvm::Function&)
(PassManager.cpp:1168)
==20768==    by 0x8D0F7F0: llvm::FunctionPassManagerImpl::run(llvm::Function&)
(PassManager.cpp:1126)
==20768==  Address 0x1BA69BF8 is 2248 bytes inside a block of size 4080 alloc'd
==20768==    at 0x1B90939A: operator new(unsigned) (vg_replace_malloc.c:132)
==20768==    by 0x1B96FF56: __gnu_cxx::__pool<true>::_M_reserve_block(unsigned,
unsigned) (mt_allocator.cc:340)
==20768==    by 0x8D0BF3E:
__gnu_cxx::__mt_alloc<std::_Rb_tree_node<std::pair<llvm::PassInfo const* const,
(anonymous namespace)::PassRegistrar::AnalysisGroupInfo> >,
__gnu_cxx::__common_pool_policy<__gnu_cxx::__pool, true> >::allocate(unsigned,
void const*) (mt_allocator.h:698)
==20768==    by 0x8D0BF65: std::_Rb_tree<llvm::PassInfo const*,
std::pair<llvm::PassInfo const* const, (anonymous
namespace)::PassRegistrar::AnalysisGroupInfo>,
std::_Select1st<std::pair<llvm::PassInfo const* const, (anonymous
namespace)::PassRegistrar::AnalysisGroupInfo> >, std::less<llvm::PassInfo
const*>, std::allocator<std::pair<llvm::PassInfo const* const, (anonymous
namespace)::PassRegistrar::AnalysisGroupInfo> > >::_M_get_node()
(stl_tree.h:356)
==20768==    by 0x8D0BF7D: std::_Rb_tree<llvm::PassInfo const*,
std::pair<llvm::PassInfo const* const, (anonymous
namespace)::PassRegistrar::AnalysisGroupInfo>,
std::_Select1st<std::pair<llvm::PassInfo const* const, (anonymous
namespace)::PassRegistrar::AnalysisGroupInfo> >, std::less<llvm::PassInfo
const*>, std::allocator<std::pair<llvm::PassInfo const* const, (anonymous
namespace)::PassRegistrar::AnalysisGroupInfo> >
>::_M_create_node(std::pair<llvm::PassInfo const* const, (anonymous
namespace)::PassRegistrar::AnalysisGroupInfo> const&) (stl_tree.h:365)
==20768==    by 0x8D0C03A:
_ZNSt8_Rb_treeIPKN4llvm8PassInfoESt4pairIKS3_N77_GLOBAL__N__home_kehoste_work_LLVM_llvm_lib_VMCore_Pass.cpp_00000000_F5B4444913PassRegistrar17AnalysisGroupInfoEESt10_Select1stIS9_ESt4lessIS3_ESaIS9_EE9_M_insertEPSt18_Rb_tree_node_baseSH_RKS9_
(stl_tree.h:794)
==20768==    by 0x8D0C191: std::_Rb_tree<llvm::PassInfo const*,
std::pair<llvm::PassInfo const* const, (anonymous
namespace)::PassRegistrar::AnalysisGroupInfo>,
std::_Select1st<std::pair<llvm::PassInfo const* const, (anonymous
namespace)::PassRegistrar::AnalysisGroupInfo> >, std::less<llvm::PassInfo
const*>, std::allocator<std::pair<llvm::PassInfo const* const, (anonymous
namespace)::PassRegistrar::AnalysisGroupInfo> >
>::insert_unique(std::pair<llvm::PassInfo const* const, (anonymous
namespace)::PassRegistrar::AnalysisGroupInfo> const&) (stl_tree.h:883)
==20768==    by 0x8D0C339: std::_Rb_tree<llvm::PassInfo const*,
std::pair<llvm::PassInfo const* const, (anonymous
namespace)::PassRegistrar::AnalysisGroupInfo>,
std::_Select1st<std::pair<llvm::PassInfo const* const, (anonymous
namespace)::PassRegistrar::AnalysisGroupInfo> >, std::less<llvm::PassInfo
const*>, std::allocator<std::pair<llvm::PassInfo const* const, (anonymous
namespace)::PassRegistrar::AnalysisGroupInfo> >
>::insert_unique(std::_Rb_tree_iterator<std::pair<llvm::PassInfo const* const,
(anonymous namespace)::PassRegistrar::AnalysisGroupInfo> >,
std::pair<llvm::PassInfo const* const, (anonymous
namespace)::PassRegistrar::AnalysisGroupInfo> const&) (stl_tree.h:905)
==20768==    by 0x8D0C66D:
_ZNSt3mapIPKN4llvm8PassInfoEN77_GLOBAL__N__home_kehoste_work_LLVM_llvm_lib_VMCore_Pass.cpp_00000000_F5B4444913PassRegistrar17AnalysisGroupInfoESt4lessIS3_ESaISt4pairIKS3_S6_EEE6insertESt17_Rb_tree_iteratorISB_ERKSB_
(stl_map.h:384)
==20768==    by 0x8D0C754:
_ZNSt3mapIPKN4llvm8PassInfoEN77_GLOBAL__N__home_kehoste_work_LLVM_llvm_lib_VMCore_Pass.cpp_00000000_F5B4444913PassRegistrar17AnalysisGroupInfoESt4lessIS3_ESaISt4pairIKS3_S6_EEEixERSA_
(stl_map.h:339)
==20768==    by 0x8D0C7B8: (anonymous
namespace)::PassRegistrar::RegisterAnalysisGroup(llvm::PassInfo*,
llvm::PassInfo const*, bool) (Pass.cpp:181)
==20768==    by 0x8D08591: llvm::RegisterAGBase::RegisterAGBase(int, int, bool)
(Pass.cpp:264)
==20768== 
==20768== Invalid free() / delete / delete[]
==20768==    at 0x1B9098CF: operator delete(void*) (vg_replace_malloc.c:155)
==20768==    by 0x862B2B2:
__gnu_cxx::new_allocator<std::_Rb_tree_node<std::pair<std::string const,
llvm::SDNode*> > >::deallocate(std::_Rb_tree_node<std::pair<std::string const,
llvm::SDNode*> >*, unsigned) (new_allocator.h:97)
==20768==    by 0x862B2D7: std::_Rb_tree<std::string, std::pair<std::string
const, llvm::SDNode*>, std::_Select1st<std::pair<std::string const,
llvm::SDNode*> >, std::less<std::string>, std::allocator<std::pair<std::string
const, llvm::SDNode*> > >::_M_put_node(std::_Rb_tree_node<std::pair<std::string
const, llvm::SDNode*> >*) (stl_tree.h:371)
==20768==    by 0x862B327: std::_Rb_tree<std::string, std::pair<std::string
const, llvm::SDNode*>, std::_Select1st<std::pair<std::string const,
llvm::SDNode*> >, std::less<std::string>, std::allocator<std::pair<std::string
const, llvm::SDNode*> >
>::_M_destroy_node(std::_Rb_tree_node<std::pair<std::string const,
llvm::SDNode*> >*) (stl_tree.h:401)
==20768==    by 0x862B38F: std::_Rb_tree<std::string, std::pair<std::string
const, llvm::SDNode*>, std::_Select1st<std::pair<std::string const,
llvm::SDNode*> >, std::less<std::string>, std::allocator<std::pair<std::string
const, llvm::SDNode*> > >::_M_erase(std::_Rb_tree_node<std::pair<std::string
const, llvm::SDNode*> >*) (stl_tree.h:1325)
==20768==    by 0x862B3BE: std::_Rb_tree<std::string, std::pair<std::string
const, llvm::SDNode*>, std::_Select1st<std::pair<std::string const,
llvm::SDNode*> >, std::less<std::string>, std::allocator<std::pair<std::string
const, llvm::SDNode*> > >::~_Rb_tree() (stl_tree.h:592)
==20768==    by 0x862B40E: std::map<std::string, llvm::SDNode*,
std::less<std::string>, std::allocator<std::pair<std::string const,
llvm::SDNode*> > >::~map() (stl_map.h:94)
==20768==    by 0x8A39E08: llvm::SelectionDAG::~SelectionDAG()
(SelectionDAG.cpp:669)
==20768==    by 0x8A6B0B5:
llvm::SelectionDAGISel::SelectBasicBlock(llvm::BasicBlock*,
llvm::MachineFunction&, llvm::FunctionLoweringInfo&)
(SelectionDAGISel.cpp:4651)
==20768==    by 0x8A6C6AF:
llvm::SelectionDAGISel::runOnFunction(llvm::Function&)
(SelectionDAGISel.cpp:4352)
==20768==    by 0x897D6A3: (anonymous
namespace)::X86DAGToDAGISel::runOnFunction(llvm::Function&)
(X86ISelDAGToDAG.cpp:122)
==20768==    by 0x8D0F586: llvm::FPPassManager::runOnFunction(llvm::Function&)
(PassManager.cpp:1168)
==20768==  Address 0x1BE94078 is 1856 bytes inside a block of size 4080 alloc'd
==20768==    at 0x1B90939A: operator new(unsigned) (vg_replace_malloc.c:132)
==20768==    by 0x1B96FF56: __gnu_cxx::__pool<true>::_M_reserve_block(unsigned,
unsigned) (mt_allocator.cc:340)
==20768==    by 0x8B4E570:
__gnu_cxx::__mt_alloc<std::_Rb_tree_node<std::pair<unsigned const,
llvm::TargetRegisterClass const*> >,
__gnu_cxx::__common_pool_policy<__gnu_cxx::__pool, true> >::allocate(unsigned,
void const*) (mt_allocator.h:698)
==20768==    by 0x8B4E597: std::_Rb_tree<unsigned, std::pair<unsigned const,
llvm::TargetRegisterClass const*>, std::_Select1st<std::pair<unsigned const,
llvm::TargetRegisterClass const*> >, std::less<unsigned>,
std::allocator<std::pair<unsigned const, llvm::TargetRegisterClass const*> >
>::_M_get_node() (stl_tree.h:356)
==20768==    by 0x8B4E5AF: std::_Rb_tree<unsigned, std::pair<unsigned const,
llvm::TargetRegisterClass const*>, std::_Select1st<std::pair<unsigned const,
llvm::TargetRegisterClass const*> >, std::less<unsigned>,
std::allocator<std::pair<unsigned const, llvm::TargetRegisterClass const*> >
>::_M_create_node(std::pair<unsigned const, llvm::TargetRegisterClass const*>
const&) (stl_tree.h:365)
==20768==    by 0x8B4E66C:
_ZNSt8_Rb_treeIjSt4pairIKjPKN4llvm19TargetRegisterClassEESt10_Select1stIS6_ESt4lessIjESaIS6_EE9_M_insertEPSt18_Rb_tree_node_baseSE_RKS6_
(stl_tree.h:794)
==20768==    by 0x8B4EAC9: std::_Rb_tree<unsigned, std::pair<unsigned const,
llvm::TargetRegisterClass const*>, std::_Select1st<std::pair<unsigned const,
llvm::TargetRegisterClass const*> >, std::less<unsigned>,
std::allocator<std::pair<unsigned const, llvm::TargetRegisterClass const*> >
>::insert_unique(std::_Rb_tree_iterator<std::pair<unsigned const,
llvm::TargetRegisterClass const*> >, std::pair<unsigned const,
llvm::TargetRegisterClass const*> const&) (stl_tree.h:921)
==20768==    by 0x8B4EC9F: std::map<unsigned, llvm::TargetRegisterClass const*,
std::less<unsigned>, std::allocator<std::pair<unsigned const,
llvm::TargetRegisterClass const*> >
>::insert(std::_Rb_tree_iterator<std::pair<unsigned const,
llvm::TargetRegisterClass const*> >, std::pair<unsigned const,
llvm::TargetRegisterClass const*> const&) (stl_map.h:384)
==20768==    by 0x8B4ED7E: std::map<unsigned, llvm::TargetRegisterClass const*,
std::less<unsigned>, std::allocator<std::pair<unsigned const,
llvm::TargetRegisterClass const*> > >::operator[](unsigned const&)
(stl_map.h:339)
==20768==    by 0x8B46E83: (anonymous
namespace)::RALinScan::ComputeRelatedRegClasses() (RegAllocLinearScan.cpp:172)
==20768==    by 0x8B47043: (anonymous
namespace)::RALinScan::runOnMachineFunction(llvm::MachineFunction&)
(RegAllocLinearScan.cpp:207)
==20768==    by 0x869B117:
llvm::MachineFunctionPass::runOnFunction(llvm::Function&)
(MachineFunctionPass.h:41)
==20768== 
==20768== ERROR SUMMARY: 478 errors from 12 contexts (suppressed: 21 from 1)
==20768== malloc/free: in use at exit: 1118021 bytes in 2525 blocks.
==20768== malloc/free: 11439 allocs, 9387 frees, 5218694 bytes allocated.
==20768== For counts of detected errors, rerun with: -v
==20768== searching for pointers to 2525 not-freed blocks.
==20768== checked 5192716 bytes.
==20768== 
==20768== LEAK SUMMARY:
==20768==    definitely lost: 3895 bytes in 14 blocks.
==20768==      possibly lost: 1548 bytes in 22 blocks.
==20768==    still reachable: 1112578 bytes in 2489 blocks.
==20768==         suppressed: 0 bytes in 0 blocks.
==20768== Use --leak-check=full to see details of leaked memory.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Tue Sep 11 16:50:41 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 11 Sep 2007 16:50:41 -0500
Subject: [LLVMbugs] [Bug 1652] New: Cygwin 32-bit GCC 3.4.4 fails to compile
 latest LLVM SVN
Message-ID: <bug-1652-206@http.llvm.org/bugs/>

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

           Summary: Cygwin 32-bit GCC 3.4.4 fails to compile latest LLVM SVN
           Product: new-bugs
           Version: unspecified
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: nightwatch41 at gmail.com
                CC: llvmbugs at cs.uiuc.edu


The Cygwin GCC fails to compile the latest LLVM SVN. The full compiler error is
shown here:

http://pastebin.ca/692648

I did some searching and found that others have run into this bug, but no
solution was provided to the mailing list, as shown by the URL below:

http://lists.cs.uiuc.edu/pipermail/llvmdev/2007-August/010172.html

-Patrick


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Tue Sep 11 20:04:06 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 11 Sep 2007 20:04:06 -0500
Subject: [LLVMbugs] [Bug 1653] New: Obj-C NSString crash in front end of
 LLVM-GCC 4.2/ arm-apple-darwin
Message-ID: <bug-1653-206@http.llvm.org/bugs/>

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

           Summary: Obj-C NSString crash in front end of LLVM-GCC 4.2/arm-
                    apple-darwin
           Product: new-bugs
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: nightwatch41 at gmail.com
                CC: llvmbugs at cs.uiuc.edu


The following code causes a segfault in the front-end of LLVM-GCC 4.2, target
arm-apple-darwin.

-----

#import <Foundation/Foundation.h>

@interface FooApp : NSObject

@end

@implementation FooApp

- (void)foo
{
    NSLog(@"foo");
    NSLog(@"bar"); 
}

@end

-----

The call frame traceback is as follows:

#0  emit_global_to_llvm (decl=0x1925720) at
../../llvm-gcc-iphone/gcc/llvm-backend.cpp:860
#1  0x002c5e45 in DefaultABI<(anonymous
namespace)::FunctionPrologArgumentConversion>::HandleArgument () at
../../llvm-gcc-iphone/gcc/llvm-convert.cpp:4725
#2  0x002cbbd9 in TreeToLLVM::EmitLV (this=0xbffff0c4, exp=0x1925720) at
../../llvm-gcc-iphone/gcc/llvm-convert.cpp:1001
#3  0x002cc2e8 in TreeToLLVM::EmitADDR_EXPR (this=0xbffff0c4, exp=0x14efd80) at
../../llvm-gcc-iphone/gcc/llvm-convert.cpp:2086
#4  0x002cd045 in TreeToLLVM::Emit (this=0xbffff0c4, exp=0x14efd80,
DestLoc=0x0) at ../../llvm-gcc-iphone/gcc/llvm-convert.cpp:858
#5  0x002d7e89 in TreeToLLVM::EmitNOP_EXPR (this=0xbffff0c4, exp=0x14efe10,
DestLoc=0x0) at ../../llvm-gcc-iphone/gcc/llvm-convert.cpp:2568
#6  0x002ccffb in TreeToLLVM::Emit (this=0xbffff0c4, exp=0x14efe10,
DestLoc=0x0) at ../../llvm-gcc-iphone/gcc/llvm-convert.cpp:865
#7  0x002de909 in TreeToLLVM::EmitMODIFY_EXPR (this=0xbffff0c4, exp=0x14efed0,
DestLoc=0x0) at ../../llvm-gcc-iphone/gcc/llvm-convert.cpp:2456
#8  0x002ccbb8 in TreeToLLVM::Emit (this=0xbffff0c4, exp=0x14efed0,
DestLoc=0x0) at ../../llvm-gcc-iphone/gcc/llvm-convert.cpp:860
#9  0x002df4e5 in TreeToLLVM::EmitFunction (this=0xbffff0c4) at
../../llvm-gcc-iphone/gcc/llvm-convert.cpp:791
#10 0x002bb70b in llvm_emit_code_for_current_function (fndecl=0x18c7c00) at
../../llvm-gcc-iphone/gcc/llvm-backend.cpp:574
#11 0x0008af1d in tree_rest_of_compilation (fndecl=0x18c7c00) at
../../llvm-gcc-iphone/gcc/tree-optimize.c:476
#12 0x0002a1e2 in c_expand_body (fndecl=0x18c7c00) at
../../llvm-gcc-iphone/gcc/c-decl.c:7133
#13 0x0030a732 in cgraph_expand_function (node=0x191d3f0) at
../../llvm-gcc-iphone/gcc/cgraphunit.c:1305
#14 0x0030c3b2 in cgraph_assemble_pending_functions () at
../../llvm-gcc-iphone/gcc/cgraphunit.c:376
#15 0x0030c0a3 in cgraph_finalize_function (decl=0x18c7c00, nested=0) at
../../llvm-gcc-iphone/gcc/cgraphunit.c:511
#16 0x0002a571 in finish_function () at ../../llvm-gcc-iphone/gcc/c-decl.c:7102
#17 0x00010bd0 in objc_finish_method_definition (fndecl=0x18c7c00) at
../../llvm-gcc-iphone/gcc/objc/objc-act.c:17246
#18 0x0007180a in c_parser_external_declaration (parser=0x4260d0c0) at
../../llvm-gcc-iphone/gcc/c-parser.c:6728
#19 0x0007219b in c_parse_file () at ../../llvm-gcc-iphone/gcc/c-parser.c:1217
#20 0x0005c10b in c_common_parse_file (set_yydebug=0) at
../../llvm-gcc-iphone/gcc/c-opts.c:1290
#21 0x00279e3b in do_compile () at ../../llvm-gcc-iphone/gcc/toplev.c:1134
#22 0x0027a8ec in toplev_main (argc=15, argv=0xbffff464) at
../../llvm-gcc-iphone/gcc/toplev.c:2288
#23 0x00001e72 in _start ()
#24 0x00001d99 in start ()

-Patrick


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Wed Sep 12 13:37:21 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 12 Sep 2007 13:37:21 -0500
Subject: [LLVMbugs] [Bug 1654] New: Broken arm_struct_value_rtx confuses
 objc_act. c in LLVM-GCC 4.0
Message-ID: <bug-1654-206@http.llvm.org/bugs/>

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

           Summary: Broken arm_struct_value_rtx confuses objc_act.c in LLVM-
                    GCC 4.0
           Product: new-bugs
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: minor
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: nightwatch41 at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=1115)
 --> (http://llvm.org/bugs/attachment.cgi?id=1115)
Proposed patch to address this issue.

Per the FIXME comment in gcc/config/arm/arm.c of LLVM-GCC 4.0, the
arm_struct_value_rtx function lies about whether structs are passed in a hidden
first parameter. This confuses gcc/objc/objc_act.c, which takes this result to
mean that Objective-C method calls do not need to be specially wrapped up in
objc_msgSend_stret. This causes crashes whenever struct-returning Objective-C
methods are called on arm-apple-darwin. The attached patch corrects this by
adding a new subtarget-specific define, BROKEN_STRUCT_VALUE_RTX, which simply
causes the Objective-C component of LLVM-GCC to assume that structures are
returned in a hidden first parameter, regardless of what the target backend's
struct_value_rtx() function tells it.

Thanks,
Patrick Walton


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Thu Sep 13 01:10:54 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 13 Sep 2007 01:10:54 -0500
Subject: [LLVMbugs] [Bug 1652] Cygwin 32-bit GCC 3.4.4 fails to compile
	latest LLVM SVN
In-Reply-To: <bug-1652-206@http.llvm.org/bugs/>
Message-ID: <200709130610.l8D6Asnc028801@zion.cs.uiuc.edu>

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


Chris Lattner <sabre at nondot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|enhancement                 |normal
             Status|NEW                         |RESOLVED
          Component|new bugs                    |Common Code Generator Code
           Keywords|                            |build-problem
            Product|new-bugs                    |libraries
         Resolution|                            |FIXED
   Target Milestone|---                         |2.1
            Version|unspecified                 |trunk




--- Comment #2 from Chris Lattner <sabre at nondot.org>  2007-09-13 01:10:52 ---
Your patch looks great to me, thanks!  Applied:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070910/053487.html

-Chris


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Thu Sep 13 16:34:42 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 13 Sep 2007 16:34:42 -0500
Subject: [LLVMbugs] [Bug 1639] GlobalOpt can't see through PHI nodes when
 doing SROA on malloc' s
In-Reply-To: <bug-1639-206@http.llvm.org/bugs/>
Message-ID: <200709132134.l8DLYgKL002307@zion.cs.uiuc.edu>

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


Chris Lattner <sabre at nondot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|enhancement                 |normal
             Status|NEW                         |RESOLVED
          Component|new bugs                    |Interprocedural
                   |                            |Optimizations
           Keywords|                            |code-quality
            Product|new-bugs                    |libraries
         Resolution|                            |FIXED
   Target Milestone|---                         |2.1
            Version|unspecified                 |trunk




--- Comment #1 from Chris Lattner <sabre at nondot.org>  2007-09-13 16:34:42 ---
Fixed, patches here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070910/053491.html
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070910/053492.html
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070910/053493.html
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070910/053494.html
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070910/053495.html

This speeds 179.art up from 7.84s to 3.13s on PPC.
-Chris


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Thu Sep 13 16:39:39 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 13 Sep 2007 16:39:39 -0500
Subject: [LLVMbugs] [Bug 473] [load-vn/gcse] Slow compiles in some cases
 (e.g. 145.fpppp)
In-Reply-To: <bug-473-206@http.llvm.org/bugs/>
Message-ID: <200709132139.l8DLddmI002503@zion.cs.uiuc.edu>

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


Owen Anderson <resistor at mac.com> changed:

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




--- Comment #12 from Owen Anderson <resistor at mac.com>  2007-09-13 16:39:39 ---
GCSE+LoadVN takes 4.78s on X86.  GVN takes 1.26s.  Just used GVN instead of
GCSE+LoadVN. ;-)


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Thu Sep 13 17:58:29 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 13 Sep 2007 17:58:29 -0500
Subject: [LLVMbugs] [Bug 1655] New: uclibc build problem
Message-ID: <bug-1655-206@http.llvm.org/bugs/>

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

           Summary: uclibc build problem
           Product: new-bugs
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Keywords: miscompilation
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: dgu at stanford.edu
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=1117)
 --> (http://llvm.org/bugs/attachment.cgi?id=1117)
Contains files referenced in my message (object and preprocessor output for
LLVM and GCC)

I recently exchanged some emails regarding this on the LLVM devlist and Chris
suggested that I post my problems here after some discussion.  The emails from
the mailing list (from 12-Sep-2007) are included below.

Note: I have referenced a number of files below.  These are all included in the
attached tarball.

I have reduced the scope of my problem to compiling a single file in uclibc:
/libc/string/generic/strcpy.c (though the same problem occurs across most
functions defined in libc).

The output object (strcpy.os) has the following symbols (as per llvm-nm, nm):
When compiling with LLVM (source object attached as strcpy.llvm.os):
         T 
__GI_strcpy
When compiling with GCC (source object attached as strcpy.gcc.os):
00000000 T __GI_strcpy
00000000 T strcpy

This is a problem because I would expect both to contain the same symbols (and
in particular because I want to link with this object file and be able to call
strcpy :]).

As requested by Chris, I compiled with -E to get the preprocessor output and
have attached those files as well (strcpy.gcc.e, strcpy.llvm.e).  A diff shows
that they are essentially identical except that each compiler references its
own stddef.h header.

With a small modification (described in the readme which I describe below), I
can get the object files generated by GCC and LLVM to have the following
symbol:
GCC:00000000 T strcpy
LLVM:         T strcpy

The only difference in the output from -E is (the change is made to the uclibc
file include/libc-symbols.h ... the resulting output from -E for LLVM is
attached as strcpy.remdefs.llvm.e):
292c292
< extern __typeof (strcpy) strcpy __asm__ ("" "__GI_strcpy") __attribute__
((visibility ("hidden")));
---
>
314c314
< extern __typeof (strcpy) __EI_strcpy __asm__("" "strcpy"); extern __typeof
(strcpy) __EI_strcpy __attribute__((alias ("" "__GI_strcpy")));
---
>

Any ideas on what the problem is?  My compiler options are -O2 -Wall (plus
--emit-llvm for llvm-gcc).  I am using gcc 4.2.1 and llvm-gcc 4.2.0.

I also included a readme (BUILD_W_LLVM_README) on the simple changes (to the
configuration and makefile) which need to be made to build uclibc-0.9.29 with
LLVM in case you would like to try building it on your system and see if you
have similar results.  If anyone is interested, I can upload the modified
uclibc config and make files if you prefer just to use those instead of making
the changes per the readme.


Thanks in advance for any light you can shed on these issues!


************************************
*** EMAILS FROM THE MAILING LIST ***
************************************
On 9/12/07, Chris Lattner <sabre at nondot.org > wrote:

    On Wed, 12 Sep 2007, David Underhill wrote:
    > I am trying compile a libc with llvm (currently uclibc).  I am able to
    > compile uclibc by changing the Rules.mak to use llvm-gcc, llvm-ar,
llvm-ad,
    > and not using strip.  (I also use the --emit-llvm flag for llvm-gcc). 
When
    > I run llvm-nm on libc.a (or try to use libc.a) I run into problems.  For
    > example, strlen is not defined -- llvm-nm shows that strlen.os has
    > __GI_strlen while if I compile with the "normal" tools (gcc, ar, ...)
    > strlen.os has __GI_strlen as well as strlen listed (both have the symbol
    > value 00000000).
    >
    > Any ideas why the archive I create with llvm doesn't define the strlen
(and
    > most other) symbols but does define the __GI_strlen?

    Can you paste the output of nm for the native GCC version?  It's possible
    that uclibc is using aliases for these, and it seems very likely that
    llvm-nm just isn't printing aliases at all.  Anton, do you want to see if
    llvm-nm should be extended by this?

-------
Anton Korobeynikov:
    afaik, llvm-nm should already handle aliases. :) However, it will be
    good to see, how uclibc handle mentioned symbols.
-------

Sure, thanks for your thoughts ... it is a little long so I'll just include
links to the nm output:

nm on the gcc generated native archive: http://www.dound.com/tmp/nm-native.txt
llvm-nm on the llvm generated archive: http://www.dound.com/tmp/nm-llvm.txt


-------------------------------
FOLLOW-UP EMAIL ...
-------------------------------
On 9/12/07, Chris Lattner <sabre at nondot.org > wrote:
Okay, this doesn't look like an alias issue :).  Without more information, I
can't tell what is going on.  Please build the file that produces strlen.os
with the -E option to get preprocessed output, and attach it to a bugzilla
entry.  With that we can figure out what is happening.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Thu Sep 13 23:14:04 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 13 Sep 2007 23:14:04 -0500
Subject: [LLVMbugs] [Bug 1656] New: Failed to run Datastructure
 analysis(dsa-local) on Linux kernel file
Message-ID: <bug-1656-206@http.llvm.org/bugs/>

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

           Summary: Failed to run Datastructure analysis(dsa-local) on Linux
                    kernel file
           Product: new-bugs
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: hehaifeng2nd at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=1119)
 --> (http://llvm.org/bugs/attachment.cgi?id=1119)
the source file of the bytecode is linux-2.4.31/fs/open.c

I tried to run Datastructure analysis on Linux kernel(version 2.4.31) but
failed. Here is the error I was able to track down:

LLVM used version: 2.0

Library used: poolalloc  Revision 41951

Command: opt -load PATH/LLVMDataStructure -dsa-local open.o

Error Message:
opt: TargetData.cpp:86: unsigned int
llvm::StructLayout::getElementContainingOffset(uint64_t) const: Assertion `(SI
== &MemberOffsets[0] || *(SI-1) < Offset) && (SI+1 ==
&MemberOffsets[NumElements] || *(SI+1) > Offset) && "Upper bound didn't work!"'
failed

/home/hehf/solar/Tools/llvm/Debug/bin/opt[0x85a67b8]
/home/hehf/solar/Tools/llvm/Debug/bin/opt[0x85a6a7e]
[0xffffe500]
[0x6]
/lib/libc.so.6(abort+0x101)[0x3744b1]
/lib/libc.so.6(__assert_fail+0xfb)[0x36c1db]
/home/hehf/solar/Tools/llvm/Debug/bin/opt(llvm::StructLayout::getElementContainingOffset(unsigned
long long) const+0x17a)[0x84ac84c]
/cs/solar/hehf/Tools/llvm/projects/poolalloc/Debug/lib/LLVMDataStructure.so.0(llvm::DSNode::mergeTypeInfo(llvm::Type
const*, unsigned int, bool)+0xc3a)[0xf7f42de2]

Description:

The assertion in StructLayout::getElementContainingOffset failed when
DSNode::mergeTypeInfo tried to merge DSNode types.

This happened when visitLoadInst:Local.cpp method was processing
instruction %tmp130 = load i32* %tmp129             ; <i32> [#uses=1]
in function get_unused_fd.

It seems some C structure in the code violated the assumption made in llvm but
I am not sure exactly what was happening.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Fri Sep 14 09:41:50 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 14 Sep 2007 09:41:50 -0500
Subject: [LLVMbugs] [Bug 1657] New: licm promotes store to null pointer
Message-ID: <bug-1657-206@http.llvm.org/bugs/>

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

           Summary: licm promotes store to null pointer
           Product: libraries
           Version: 2.0
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Scalar Optimizations
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: jay.foad at antixlabs.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=1120)
 --> (http://llvm.org/bugs/attachment.cgi?id=1120)
bitcode for test case

I'm using LLVM 2.0 on cygwin.

The attached bitcode file pre.o contains a store to a null pointer:

        %tmp1.i = getelementptr %struct.decision* null, i32 0, i32 0    ; <i8*>
[#uses=1]
        store i8 0, i8* %tmp1.i

but in practice this is never executed, because it's preceded by a conditional
branch (where the condition is always true) which branches over it.

If I run this through "opt -f -o post.o pre.o -licm -debug", the resulting
bitcode file contains a load from a null pointer and a store to a null pointer,
both of which are unconditionally executed:

entry:
        ...
        %tmp1.i = getelementptr %struct.decision* null, i32 0, i32 0    ; <i8*>
[#uses=2]
        %tmp1.i.promoted = load i8* %tmp1.i             ; <i8> [#uses=1]

...

clear_modes.exit:               ; preds = %blah.i
        store i8 %tmp1.i.tmp.0, i8* %tmp1.i
        call void @exit( i32 0 )
        unreachable

This has broken my program: it's now going to trap, when it wouldn't have
before I ran the LICM pass on it.

Here's the debug output from LICM:

LICM hoisting to entry:         %tmp3.i = icmp eq %struct.decision* null, null;
<i1> [#uses=1]
LICM hoisting to entry:         %tmp1.i = getelementptr %struct.decision* null,
i32 0, i32 0            ; <i8*> [#uses=1]
LICM: Promoting value:  %tmp1.i = getelementptr %struct.decision* null, i32 0,
i32 0            ; <i8*> [#uses=1]


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Fri Sep 14 12:30:22 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 14 Sep 2007 12:30:22 -0500
Subject: [LLVMbugs] [Bug 1658] New: CBE miscompiles common C++ Code
Message-ID: <bug-1658-206@http.llvm.org/bugs/>

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

           Summary: CBE miscompiles common C++ Code
           Product: libraries
           Version: 1.0
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Backend: C
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: sabre at nondot.org
                CC: llvmbugs at cs.uiuc.edu


Consider this code:

struct ctor {
  void *foo;
  ctor(const ctor &X);
  ctor() {}
};

struct test {
  unsigned char *field0;
};

test foo();
ctor bar();  

void testfunc() {
  test xx;
  ctor yy;  

  xx = foo();
  yy = bar();
}

In the GCC abi, single element structs are returned as registers, larger
structs and any struct with a copy ctor are returned by passing a hidden "sret"
pointer to the struct.  llvm-gcc compiles this to:

        %tmp2 = call i8* @_Z3foov( )            ; <i8*> [#uses=0]
        call void @_Z3barv( %struct.ctor* %tmp1 sret  )

which is correct.  The problem is that the CBE doesn't know about this.  When
run through the CBE, we get:

struct l_struct_2E_ctor {
  unsigned char *field0;
};
...
  struct l_struct_2E_ctor llvm_cbe_tmp1;    /* Address-exposed local */
  *((&llvm_cbe_tmp1)) = _Z3barv();
 ...

Suddenly the the C compiler compiling the CBE output will return the struct in
a register, instead of passing it by dummy argument.  This causes
miscompilation of Misc-C++/bigfib and probably a lot of other stuff because
this affects std::string.

-Chris


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Fri Sep 14 14:23:36 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 14 Sep 2007 14:23:36 -0500
Subject: [LLVMbugs] [Bug 1655] uclibc build problem
In-Reply-To: <bug-1655-206@http.llvm.org/bugs/>
Message-ID: <200709141923.l8EJNaRp023935@zion.cs.uiuc.edu>

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


Anton Korobeynikov <asl at math.spbu.ru> changed:

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




--- Comment #4 from Anton Korobeynikov <asl at math.spbu.ru>  2007-09-14 14:23:36 ---
Ok, this seems to be non-referenced alias problem which I recently fixed :)

>llvm-gcc4-2.0.source
Means llvm-gcc4 from LLVM 2.0. llvm-gcc itself is based on 4.0.1 branch.

I'm closing this PR. Please update to mainline (or next 2.1 release).


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Fri Sep 14 17:38:21 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 14 Sep 2007 17:38:21 -0500
Subject: [LLVMbugs] [Bug 1659] New: libstdc++ fails to build on darwin/x86-64
Message-ID: <bug-1659-206@http.llvm.org/bugs/>

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

           Summary: libstdc++ fails to build on darwin/x86-64
           Product: libraries
           Version: 1.0
          Platform: PC
        OS/Version: All
            Status: NEW
          Keywords: compile-fail
          Severity: normal
          Priority: P2
         Component: Backend: X86
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: sabre at nondot.org
                CC: llvmbugs at cs.uiuc.edu


libstdc++ fails to build on darwin/x86-64.  This isn't suggested, but it should
still at least build :).  The failure is:

eh_alloc.s:183:unknown section type:
non_lazy_symbol_pointerseh_alloc.s:183:Rest of line ignored. 1st junk character
valued 76 (L).
eh_alloc.s:184:Unknown pseudo-op: .indirect_symboleh_alloc.s:184:Rest of line
ignored. 1st junk character valued 95 (_).

The generated code in question is:

.section __IMPORT,__pointers,non_lazy_symbol_pointers
L___gxx_personality_v0$non_lazy_ptr:
        .indirect_symbol ___gxx_personality_v0
        .long   0
        .subsections_via_symbols

Bill, can you take a look at this?

-Chris


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Fri Sep 14 20:08:00 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 14 Sep 2007 20:08:00 -0500
Subject: [LLVMbugs] [Bug 1660] New: compilation of llvm-gcc-4-2 dies
Message-ID: <bug-1660-206@http.llvm.org/bugs/>

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

           Summary: compilation of llvm-gcc-4-2 dies
           Product: new-bugs
           Version: unspecified
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: ggreif at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Xcode 2.4.1, configuring thus:

../llvm-gcc/configure --enable-llvm=$LLVMOBJDIR
--enable-languages=c,c++$EXTRALANGS
--with-gxx-include-dir=/usr/include/c++/4.0.0 --build=$TRIPLE --host=$TRIPLE
--target=$TRIPLE

EXTRALANGS=,objc,obj-c++
TRIPLE=powerpc-apple-darwin8

llvm-gcc is is freshly checked out llvm-gcc-4-2, libstdc++ shwiched to the
"missing" dir

This is a PPC mac mini (poor guy!)


I get:



/gdm/obj/./gcc/xgcc -B/gdm/obj/./gcc/ -B/usr/local/powerpc-apple-darwin8/bin/
-B/usr/local/powerpc-apple-darwin8/lib/ -isystem
/usr/local/powerpc-apple-darwin8/include -isystem
/usr/local/powerpc-apple-darwin8/sys-include -O2  -O2 -g -O2  -DIN_GCC    -W
-Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition  -isystem ./include  -Wa,-force_cpusubtype_ALL -pipe
-mmacosx-version-min=10.4 -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2
-D__GCC_FLOAT_NOT_NEEDED  -I. -I. -I../../llvm-gcc/gcc -I../../llvm-gcc/gcc/.
-I../../llvm-gcc/gcc/../include -I./../intl
-I../../llvm-gcc/gcc/../libcpp/include  -I../../llvm-gcc/gcc/../libdecnumber
-I../libdecnumber -I/gdm/llvm/include -I/gdm/llvm-build/include -m64
-xassembler-with-cpp -include libgcc/ppc64/darwin-fpsave.vis -c
../../llvm-gcc/gcc/config/rs6000/darwin-fpsave.asm -o
libgcc/ppc64/darwin-fpsave.o
/gdm/obj/./gcc/xgcc -B/gdm/obj/./gcc/ -B/usr/local/powerpc-apple-darwin8/bin/
-B/usr/local/powerpc-apple-darwin8/lib/ -isystem
/usr/local/powerpc-apple-darwin8/include -isystem
/usr/local/powerpc-apple-darwin8/sys-include -O2  -O2 -g -O2  -DIN_GCC    -W
-Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition  -isystem ./include  -Wa,-force_cpusubtype_ALL -pipe
-mmacosx-version-min=10.4 -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2
-D__GCC_FLOAT_NOT_NEEDED  -I. -I. -I../../llvm-gcc/gcc -I../../llvm-gcc/gcc/.
-I../../llvm-gcc/gcc/../include -I./../intl
-I../../llvm-gcc/gcc/../libcpp/include  -I../../llvm-gcc/gcc/../libdecnumber
-I../libdecnumber -I/gdm/llvm/include -I/gdm/llvm-build/include -m64
-fvisibility=hidden -DHIDE_EXPORTS -c
../../llvm-gcc/gcc/config/rs6000/ppc64-fp.c -o libgcc/ppc64/ppc64-fp.o
In file included from ../../llvm-gcc/gcc/config/rs6000/ppc64-fp.c:35:
../../llvm-gcc/gcc/config/fp-bit.h:100: error: unable to emulate 'TF'
make[4]: *** [libgcc/ppc64/ppc64-fp.o] Error 1
make[3]: *** [stmp-multilib] Error 2
make[2]: *** [all-stage1-gcc] Error 2
make[1]: *** [stage1-bubble] Error 2
make: *** [all] Error 2


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Fri Sep 14 23:05:06 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 14 Sep 2007 23:05:06 -0500
Subject: [LLVMbugs] [Bug 1661] New: ji fails on SPASS
Message-ID: <bug-1661-206@http.llvm.org/bugs/>

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

           Summary: ji fails on SPASS
           Product: tools
           Version: trunk
          Platform: Macintosh
        OS/Version: Mac System 9.x
            Status: NEW
          Severity: normal
          Priority: P2
         Component: lli
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: tonic at nondot.org
                CC: llvmbugs at cs.uiuc.edu


The jit is failing on SPASS. This is a regression from 2.0.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Fri Sep 14 23:07:11 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 14 Sep 2007 23:07:11 -0500
Subject: [LLVMbugs] [Bug 1662] New: cbe fails on MiBench/office-ispell
Message-ID: <bug-1662-206@http.llvm.org/bugs/>

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

           Summary: cbe fails on MiBench/office-ispell
           Product: libraries
           Version: 2.0
          Platform: Macintosh
        OS/Version: Mac System 9.x
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Backend: C
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: tonic at nondot.org
                CC: llvmbugs at cs.uiuc.edu


cbe fails on MiBench/office-ispell. This is a regression from 2.0.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Fri Sep 14 23:09:29 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 14 Sep 2007 23:09:29 -0500
Subject: [LLVMbugs] [Bug 1663] New: cbe fails on Prolangs-C/cdecl
Message-ID: <bug-1663-206@http.llvm.org/bugs/>

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

           Summary: cbe fails on Prolangs-C/cdecl
           Product: libraries
           Version: trunk
          Platform: Macintosh
        OS/Version: Mac System 9.x
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Backend: C
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: tonic at nondot.org
                CC: llvmbugs at cs.uiuc.edu


The cbe on ppc fails on Prolangs-C/cdecl. This is a regression from 2.0.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Fri Sep 14 23:13:51 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 14 Sep 2007 23:13:51 -0500
Subject: [LLVMbugs] [Bug 1664] New: llc fails on UnitTests/Vector/build2
Message-ID: <bug-1664-206@http.llvm.org/bugs/>

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

           Summary: llc fails on UnitTests/Vector/build2
           Product: libraries
           Version: trunk
          Platform: Macintosh
        OS/Version: Mac System 9.x
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Backend: PowerPC
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: tonic at nondot.org
                CC: llvmbugs at cs.uiuc.edu


llc fails on UnitTests/Vector/build2. This is a regression from 2.0.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Fri Sep 14 23:26:00 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 14 Sep 2007 23:26:00 -0500
Subject: [LLVMbugs] [Bug 1665] New: jit fails on UnitTests/Vector/build2
Message-ID: <bug-1665-206@http.llvm.org/bugs/>

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

           Summary: jit fails on UnitTests/Vector/build2
           Product: libraries
           Version: trunk
          Platform: Macintosh
        OS/Version: Mac System 9.x
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: Target-Independent JIT
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: tonic at nondot.org
                CC: llvmbugs at cs.uiuc.edu


ppc jit fails on UnitTests/Vector/build2. This is a regression from 2.0.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Fri Sep 14 23:28:58 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 14 Sep 2007 23:28:58 -0500
Subject: [LLVMbugs] [Bug 1666] New: cbe fails on
	SPEC/CINT2000/254.gap/254.gap
Message-ID: <bug-1666-206@http.llvm.org/bugs/>

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

           Summary: cbe fails on SPEC/CINT2000/254.gap/254.gap
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Backend: C
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: tonic at nondot.org
                CC: llvmbugs at cs.uiuc.edu


cbe fails on SPEC/CINT2000/254.gap/254.gap. This is a regression from 2.0.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Fri Sep 14 23:30:12 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 14 Sep 2007 23:30:12 -0500
Subject: [LLVMbugs] [Bug 1667] New: llc fails on SPEC/CINT95/099.go/099.go
Message-ID: <bug-1667-206@http.llvm.org/bugs/>

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

           Summary: llc fails on SPEC/CINT95/099.go/099.go
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Backend: X86
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: tonic at nondot.org
                CC: llvmbugs at cs.uiuc.edu


This is a regression from 2.0.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Fri Sep 14 23:31:05 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 14 Sep 2007 23:31:05 -0500
Subject: [LLVMbugs] [Bug 1668] New: x86 jit fails on
	SPEC/CINT95/099.go/099.go
Message-ID: <bug-1668-206@http.llvm.org/bugs/>

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

           Summary: x86 jit fails on SPEC/CINT95/099.go/099.go
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Target-Independent JIT
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: tonic at nondot.org
                CC: llvmbugs at cs.uiuc.edu


This is a regression from 2.0.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Fri Sep 14 23:32:07 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 14 Sep 2007 23:32:07 -0500
Subject: [LLVMbugs] [Bug 1669] New: cbe fails on SPEC/CINT95/099.go/099.go
Message-ID: <bug-1669-206@http.llvm.org/bugs/>

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

           Summary: cbe fails on SPEC/CINT95/099.go/099.go
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Backend: C
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: tonic at nondot.org
                CC: llvmbugs at cs.uiuc.edu


This is a regression from 2.0.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Fri Sep 14 23:35:30 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 14 Sep 2007 23:35:30 -0500
Subject: [LLVMbugs] [Bug 1670] New: llc fails on
	UnitTests/Vector/SSE/sse.expandfft
Message-ID: <bug-1670-206@http.llvm.org/bugs/>

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

           Summary: llc fails on UnitTests/Vector/SSE/sse.expandfft
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Backend: X86
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: tonic at nondot.org
                CC: llvmbugs at cs.uiuc.edu


This is a regression from 2.0.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Fri Sep 14 23:36:19 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 14 Sep 2007 23:36:19 -0500
Subject: [LLVMbugs] [Bug 1671] New: x86 jit fails on
	UnitTests/Vector/SSE/sse.expandfft
Message-ID: <bug-1671-206@http.llvm.org/bugs/>

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

           Summary: x86 jit fails on UnitTests/Vector/SSE/sse.expandfft
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Target-Independent JIT
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: tonic at nondot.org
                CC: llvmbugs at cs.uiuc.edu


This is a regression from 2.0.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Sat Sep 15 00:15:34 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 15 Sep 2007 00:15:34 -0500
Subject: [LLVMbugs] [Bug 1672] New: legalizer doesn' t scalarize illegal
 vector return correctly in some cases
Message-ID: <bug-1672-206@http.llvm.org/bugs/>

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

           Summary: legalizer doesn't scalarize illegal vector return
                    correctly in some cases
           Product: libraries
           Version: 1.0
          Platform: PC
        OS/Version: All
            Status: NEW
          Keywords: compile-fail
          Severity: normal
          Priority: P2
         Component: Common Code Generator Code
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: sabre at nondot.org
                CC: llvmbugs at cs.uiuc.edu


The PPC backend dies on this input:

define <4 x float> @test1110(float %a, float %b, float %c) {
entry:
        ret <4 x float> zeroinitializer
}

This gets turned into a return of 4 floats.  The PPC backend dies because it
only knows how to return one float value (PPCCallingConv.td):

  CCIfType<[f32, f64], CCAssignToReg<[F1]>>,

It would be very easy to change this to:

  CCIfType<[f32, f64], CCAssignToReg<[F1,F2,F3,F4]>>,

However, this would fix this case, but not the arbitrary case, and this is
almost certainly not abi compatible with GCC.

-Chris


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Sat Sep 15 00:15:58 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 15 Sep 2007 00:15:58 -0500
Subject: [LLVMbugs] [Bug 1665] llvm-gcc crashes compiling build2 directly on
	ppc
In-Reply-To: <bug-1665-206@http.llvm.org/bugs/>
Message-ID: <200709150515.l8F5FwLE010924@zion.cs.uiuc.edu>

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


Chris Lattner <sabre at nondot.org> changed:

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




--- Comment #4 from Chris Lattner <sabre at nondot.org>  2007-09-15 00:15:58 ---
This is a codegen bug/missing-feature, but is not a regression.

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


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Sat Sep 15 00:18:39 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 15 Sep 2007 00:18:39 -0500
Subject: [LLVMbugs] [Bug 1670] llc fails on
	UnitTests/Vector/SSE/sse.expandfft
In-Reply-To: <bug-1670-206@http.llvm.org/bugs/>
Message-ID: <200709150518.l8F5IdEm011054@zion.cs.uiuc.edu>

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


Chris Lattner <sabre at nondot.org> changed:

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




--- Comment #2 from Chris Lattner <sabre at nondot.org>  2007-09-15 00:18:39 ---
This is almost certainly a duplicate of 1672, which is target independent. 
Please let me know if your gcc is not llvm-gcc.

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


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Sat Sep 15 00:19:35 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 15 Sep 2007 00:19:35 -0500
Subject: [LLVMbugs] [Bug 1664] llc fails on UnitTests/Vector/build2
In-Reply-To: <bug-1664-206@http.llvm.org/bugs/>
Message-ID: <200709150519.l8F5JZTC011138@zion.cs.uiuc.edu>

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


Chris Lattner <sabre at nondot.org> changed:

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




--- Comment #1 from Chris Lattner <sabre at nondot.org>  2007-09-15 00:19:34 ---
This is a duplicate of 1672, and is not a regression.

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


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Sat Sep 15 00:48:45 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 15 Sep 2007 00:48:45 -0500
Subject: [LLVMbugs] [Bug 1662] llvm-gcc crashes on NEGATE_EXPR with pointer
	type
In-Reply-To: <bug-1662-206@http.llvm.org/bugs/>
Message-ID: <200709150548.l8F5mjuf028872@zion.cs.uiuc.edu>

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


Chris Lattner <sabre at nondot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
           Keywords|                            |compile-fail
         Resolution|                            |FIXED
            Summary|llvm-gcc crashes on this .i |llvm-gcc crashes on
                   |file                        |NEGATE_EXPR with pointer
                   |                            |type
            Version|trunk                       |1.0




--- Comment #4 from Chris Lattner <sabre at nondot.org>  2007-09-15 00:48:45 ---
Fixed, testcase here: test/CFrontend/2007-09-14-NegatePointer.c

Patches here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070910/053542.html
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070910/053543.html

-Chris


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Sat Sep 15 00:54:12 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 15 Sep 2007 00:54:12 -0500
Subject: [LLVMbugs] [Bug 1663] cbe fails on Prolangs-C/cdecl
In-Reply-To: <bug-1663-206@http.llvm.org/bugs/>
Message-ID: <200709150554.l8F5sCPN029143@zion.cs.uiuc.edu>

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


Chris Lattner <sabre at nondot.org> changed:

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




--- Comment #1 from Chris Lattner <sabre at nondot.org>  2007-09-15 00:54:12 ---
This is a dup of 1662.

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


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Sat Sep 15 01:52:41 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 15 Sep 2007 01:52:41 -0500
Subject: [LLVMbugs] [Bug 1666] CBE miscompiles relation pointer comparisons
	to null
In-Reply-To: <bug-1666-206@http.llvm.org/bugs/>
Message-ID: <200709150652.l8F6qfPP018114@zion.cs.uiuc.edu>

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


Chris Lattner <sabre at nondot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
           Keywords|                            |miscompilation
         OS/Version|Linux                       |All
           Platform|PC                          |All
         Resolution|                            |FIXED
            Summary|cbe fails on                |CBE miscompiles relation
                   |SPEC/CINT2000/254.gap/254.ga|pointer comparisons to null
                   |p                           |
   Target Milestone|---                         |2.1
            Version|trunk                       |2.0




--- Comment #3 from Chris Lattner <sabre at nondot.org>  2007-09-15 01:52:40 ---
Fixed, patch here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070910/053546.html

This fixes 254.gap and SPASS with the CBE.

-Chris


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Sat Sep 15 15:27:13 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 15 Sep 2007 15:27:13 -0500
Subject: [LLVMbugs] [Bug 1669] cbe fails on SPEC/CINT95/099.go/099.go
In-Reply-To: <bug-1669-206@http.llvm.org/bugs/>
Message-ID: <200709152027.l8FKRD6q019236@zion.cs.uiuc.edu>

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


Chris Lattner <sabre at nondot.org> changed:

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




--- Comment #1 from Chris Lattner <sabre at nondot.org>  2007-09-15 15:27:12 ---
merging these 3 bugs

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


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Sat Sep 15 15:27:52 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 15 Sep 2007 15:27:52 -0500
Subject: [LLVMbugs] [Bug 1667] llc fails on SPEC/CINT95/099.go/099.go
In-Reply-To: <bug-1667-206@http.llvm.org/bugs/>
Message-ID: <200709152027.l8FKRq4n019279@zion.cs.uiuc.edu>

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


Chris Lattner <sabre at nondot.org> changed:

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




--- Comment #1 from Chris Lattner <sabre at nondot.org>  2007-09-15 15:27:52 ---
merging these 3 bugs

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


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Sat Sep 15 16:17:45 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 15 Sep 2007 16:17:45 -0500
Subject: [LLVMbugs] [Bug 1671] x86 jit fails on
	UnitTests/Vector/SSE/sse.expandfft
In-Reply-To: <bug-1671-206@http.llvm.org/bugs/>
Message-ID: <200709152117.l8FLHj6I020543@zion.cs.uiuc.edu>

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


Anton Korobeynikov <asl at math.spbu.ru> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |asl at math.spbu.ru
             Status|NEW                         |RESOLVED
         Resolution|                            |DUPLICATE




--- Comment #1 from Anton Korobeynikov <asl at math.spbu.ru>  2007-09-15 16:17:44 ---


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


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Sat Sep 15 18:12:34 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 15 Sep 2007 18:12:34 -0500
Subject: [LLVMbugs] [Bug 1673] New: Assertion failed in vector code
Message-ID: <bug-1673-206@http.llvm.org/bugs/>

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

           Summary: Assertion failed in vector code
           Product: tools
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: llvm-gcc
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: asl at math.spbu.ru
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=1123)
 --> (http://llvm.org/bugs/attachment.cgi?id=1123)
Preprocessed source

Consider attached testcase. It fails with:

cc1plus: /home/asl/proj/llvm/src/lib/VMCore/Instructions.cpp:1854: static
llvm::Instruction::CastOps llvm::CastInst::getCastOpcode(const llvm::Value*,
bool, const llvm::Type*, bool): Assertion `DestPTy->getBitWidth() ==
SrcPTy->getBitWidth() && "Casting vector to vector of different widths"'
failed.

It seems, that it tries to emit a cast from 4xi32 to i64.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Sun Sep 16 13:19:15 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 16 Sep 2007 13:19:15 -0500
Subject: [LLVMbugs] [Bug 1673] regression building MMX code in Qt
In-Reply-To: <bug-1673-206@http.llvm.org/bugs/>
Message-ID: <200709161819.l8GIJFDx025973@zion.cs.uiuc.edu>

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


Chris Lattner <sabre at nondot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
           Keywords|                            |compile-fail, regression
         Resolution|                            |FIXED
            Summary|Assertion failed in vector  |regression building MMX code
                   |code                        |in Qt




--- Comment #3 from Chris Lattner <sabre at nondot.org>  2007-09-16 13:19:15 ---
Fixed, patch here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070910/053559.html
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070910/053560.html


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Sun Sep 16 14:37:15 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 16 Sep 2007 14:37:15 -0500
Subject: [LLVMbugs] [Bug 1659] libstdc++ fails to build on darwin/x86-64
In-Reply-To: <bug-1659-206@http.llvm.org/bugs/>
Message-ID: <200709161937.l8GJbFE8028792@zion.cs.uiuc.edu>

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


Bill Wendling <isanbard at gmail.com> changed:

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




--- Comment #1 from Bill Wendling <isanbard at gmail.com>  2007-09-16 14:37:14 ---
The code that emits the personality stub was doing so even if the target didn't
support exceptions. This was a massive think-o in my exception handling patches
for Darwin. Fixed:

http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070910/053555.html
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070910/053564.html

-bw


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Mon Sep 17 12:36:29 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 17 Sep 2007 12:36:29 -0500
Subject: [LLVMbugs] [Bug 1674] New: configure --help not showing correct
	defaults
Message-ID: <bug-1674-206@http.llvm.org/bugs/>

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

           Summary: configure --help not showing correct defaults
           Product: Build scripts
           Version: cvs
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: minor
          Priority: P2
         Component: autoconf
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: tonic at nondot.org
                CC: llvmbugs at cs.uiuc.edu


> $ cd objdir
> $ ../llvm-2.1/configure --help
> [...]
>  --enable-shared[=PKGS]  build shared libraries
>                          [default=enable_shared_default]
>  --enable-static[=PKGS]  build static libraries
>                          [default=enable_static_default]
>  --enable-fast-install[=PKGS]
>                          optimize for fast installation
>                          [default=enable_Fast_install_default]


These should show yes or no.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Mon Sep 17 15:32:51 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 17 Sep 2007 15:32:51 -0500
Subject: [LLVMbugs] [Bug 1633] Verifier doesn't fully verify GC intrinsics
In-Reply-To: <bug-1633-206@http.llvm.org/bugs/>
Message-ID: <200709172032.l8HKWpmX008689@zion.cs.uiuc.edu>

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


Gordon Henriksen <gordonhenriksen at mac.com> changed:

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




--- Comment #5 from Gordon Henriksen <gordonhenriksen at mac.com>  2007-09-17 15:32:50 ---
Fixed here (r42051):
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070917/053600.html


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Mon Sep 17 16:02:14 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 17 Sep 2007 16:02:14 -0500
Subject: [LLVMbugs] [Bug 1668] LoopIndexSplit miscompiles
	SPEC/CINT95/099.go/099.go
In-Reply-To: <bug-1668-206@http.llvm.org/bugs/>
Message-ID: <200709172102.l8HL2Esu021667@zion.cs.uiuc.edu>

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


Devang Patel <dpatel at apple.com> changed:

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




--- Comment #7 from Devang Patel <dpatel at apple.com>  2007-09-17 16:02:14 ---
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070917/053605.html

This patch fixes test case extracted by Owen.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Mon Sep 17 16:42:50 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 17 Sep 2007 16:42:50 -0500
Subject: [LLVMbugs] [Bug 1674] configure --help not showing correct defaults
In-Reply-To: <bug-1674-206@http.llvm.org/bugs/>
Message-ID: <200709172142.l8HLgoxW027698@zion.cs.uiuc.edu>

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


Tanya Lattner <tonic at nondot.org> changed:

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




--- Comment #1 from Tanya Lattner <tonic at nondot.org>  2007-09-17 16:42:50 ---
Fixed:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070917/053608.html


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Mon Sep 17 20:55:16 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 17 Sep 2007 20:55:16 -0500
Subject: [LLVMbugs] [Bug 1657] licm promotes store to null pointer
In-Reply-To: <bug-1657-206@http.llvm.org/bugs/>
Message-ID: <200709180155.l8I1tGRg010645@zion.cs.uiuc.edu>

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


Devang Patel <dpatel at apple.com> changed:

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




--- Comment #4 from Devang Patel <dpatel at apple.com>  2007-09-17 20:55:15 ---
Fixed.
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070917/053616.html


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Mon Sep 17 21:04:18 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 17 Sep 2007 21:04:18 -0500
Subject: [LLVMbugs] [Bug 1675] New: instcombine neg(zext(bool)) to sext(bool)
Message-ID: <bug-1675-206@http.llvm.org/bugs/>

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

           Summary: instcombine neg(zext(bool)) to sext(bool)
           Product: libraries
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: Scalar Optimizations
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: nicholas at mxc.ca
                CC: llvmbugs at cs.uiuc.edu


Instruction combiner isn't simplifying this:

  define i32 @f(i32 %x, i32 %y) {
    %A = icmp ne i32 %x, %y
    %B = zext i1 %A to i32
    %C = sub i32 0, %B
    ret i32 %C
  }

which could become:

  define i32 @f(i32 %x, i32 %y) {
    %A = icmp ne i32 %x, %y
    %B = sext i1 %A to i32
    ret i32 %B
  }

This example is reduced from mediabench/gsm/toast.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Mon Sep 17 22:25:22 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 17 Sep 2007 22:25:22 -0500
Subject: [LLVMbugs] [Bug 1657] licm promotes store to null pointer
In-Reply-To: <bug-1657-206@http.llvm.org/bugs/>
Message-ID: <200709180325.l8I3PMGw015985@zion.cs.uiuc.edu>

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


Nick Lewycky <nicholas at mxc.ca> changed:

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




-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Mon Sep 17 23:52:18 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 17 Sep 2007 23:52:18 -0500
Subject: [LLVMbugs] [Bug 1676] New: 140x slower compilation time vs gcc
Message-ID: <bug-1676-206@http.llvm.org/bugs/>

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

           Summary: 140x slower compilation time vs gcc
           Product: new-bugs
           Version: unspecified
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: astrange at ithinksw.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=1127)
 --> (http://llvm.org/bugs/attachment.cgi?id=1127)
testcase source

> time /usr/local/llvmgcc/bin/llvm-gcc -O3 -g -mdynamic-no-pic -march=nocona -mtune=nocona -c llvm-snow.i
683.139u 4.366s 11:46.76 97.2%  0+0k 0+19io 0pf+0w
> time gcc -O3 -g -mdynamic-no-pic -march=nocona -mtune=nocona -c llvm-snow.i
5.331u 0.257s 0:05.62 99.2%     0+0k 0+7io 0pf+0w

gcc version 4.0.1 LLVM (Apple Computer, Inc. build 2.0)
vs
gcc version 4.0.1 (Apple Computer, Inc. build 5367)


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Tue Sep 18 00:08:05 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 18 Sep 2007 00:08:05 -0500
Subject: [LLVMbugs] [Bug 1677] New: Failed assertion `isa<X>(Val) &&
 "cast<Ty>() argument of incompatible type!"'
Message-ID: <bug-1677-206@http.llvm.org/bugs/>

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

           Summary: Failed assertion `isa<X>(Val) && "cast<Ty>() argument of
                    incompatible type!"'
           Product: new-bugs
           Version: unspecified
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: astrange at ithinksw.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=1128)
 --> (http://llvm.org/bugs/attachment.cgi?id=1128)
testcase (QT SMC decoder from ffmpeg)

> /usr/local/llvmgcc/bin/llvm-gcc -v
Using built-in specs.
Target: i686-apple-darwin8
Configured with: ../llvm-gcc4-2.0.source/configure
--prefix=/Users/tonic/release/llvm-gcc/obj/../install --program-prefix=llvm-
--enable-llvm=/Users/tonic/release/llvm-2.0
--enable-languages=c,c++,objc,obj-c++ --with-arch=nocona --with-tune=generic
--with-gxx-include-dir=/usr/include/c++/4.0.0 --build=i686-apple-darwin8
--host=i686-apple-darwin8 --target=i686-apple-darwin8
Thread model: posix
gcc version 4.0.1 LLVM (Apple Computer, Inc. build 2.0)

> /usr/local/llvmgcc/bin/llvm-gcc -O3 -emit-llvm -g -mdynamic-no-pic -march=nocona -mtune=nocona -c llvm-smc.i
/Users/tonic/release/llvm-2.0/include/llvm/Support/Casting.h:199: failed
assertion `isa<X>(Val) && "cast<Ty>() argument of incompatible type!"'
smc.c:490: internal compiler error: Abort trap

Changing optimization flags leads to one other error and a segfault:

> /usr/local/llvmgcc/bin/llvm-gcc -O1 -emit-llvm -g -mdynamic-no-pic -c llvm-smc.i
/Users/tonic/release/llvm-2.0/include/llvm/Type.h:295: failed assertion
`isAbstract() && "Cannot drop a reference to a non-abstract type!"'

> /usr/local/llvmgcc/bin/llvm-gcc -O2 -emit-llvm -g -mdynamic-no-pic -march=nocona -mtune=nocona -c llvm-smc.i
smc.c:490: internal compiler error: Segmentation fault

gcc compiles it with no warnings.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Tue Sep 18 00:12:25 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 18 Sep 2007 00:12:25 -0500
Subject: [LLVMbugs] [Bug 1677] Failed assertion `isa<X>(Val) && "cast<Ty>()
 argument of incompatible type!"'
In-Reply-To: <bug-1677-206@http.llvm.org/bugs/>
Message-ID: <200709180512.l8I5CP4J022070@zion.cs.uiuc.edu>

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


Chris Lattner <sabre at nondot.org> changed:

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




--- Comment #1 from Chris Lattner <sabre at nondot.org>  2007-09-18 00:12:22 ---
This is already fixed in SVN head, and presumably in LLVM 2.1.  LLVM 2.1 should
be out "real soon now", if you'd like to test a release tarball, please take a
look here:
http://lists.cs.uiuc.edu/pipermail/llvmdev/2007-September/010710.html

-Chris


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Tue Sep 18 00:15:37 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 18 Sep 2007 00:15:37 -0500
Subject: [LLVMbugs] [Bug 1676] 140x slower compilation time vs gcc
In-Reply-To: <bug-1676-206@http.llvm.org/bugs/>
Message-ID: <200709180515.l8I5FbcO022235@zion.cs.uiuc.edu>

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


Owen Anderson <resistor at mac.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |resistor at mac.com
             Status|NEW                         |RESOLVED
         Resolution|                            |WORKSFORME




--- Comment #2 from Owen Anderson <resistor at mac.com>  2007-09-18 00:15:36 ---
I am unable to reproduce this on mainline with a release build.  My timings are
as follows:

gcc version 4.0.1 (Apple Computer, Inc. build 5367):
real    0m4.181s
user    0m3.967s
sys     0m0.205s

gcc version 4.0.1 (Apple Computer, Inc. build 5449)(LLVM build )
real    0m2.509s
user    0m2.430s
sys     0m0.076s

I'm guessing this is a bad case for LoadVN/GCSE.  But whatever caused it, it's
gone now!  Closing as WORKSFORME.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Tue Sep 18 04:04:21 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 18 Sep 2007 04:04:21 -0500
Subject: [LLVMbugs] [Bug 1678] New: wrong weak alias optimization with
	llvm-gcc-4.2
Message-ID: <bug-1678-206@http.llvm.org/bugs/>

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

           Summary: wrong weak alias optimization with llvm-gcc-4.2
           Product: new-bugs
           Version: unspecified
          Platform: Other
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: baldrick at free.fr
                CC: llvmbugs at cs.uiuc.edu


This bug only effects llvm-gcc-4.2.  Here is the testcase:

extern void B (void);
static __typeof(B) A __attribute__ ((__weakref__("B")));
int active (void)
{
  static void *const p = __extension__ (void *) &A;
  return p != 0;
}

This is optimized to:

@A = alias weak void ()* @B
define i32 @active() {
entry:
        ret i32 1
}

which is wrong (see PR1646).  The cause is quite interesting though:
llvm-gcc emits the function @active and runs per function passes on
it.  At that point A has not yet been declared an alias for B!  It
is simply an ordinary global.  Thus the optimizers correctly decide
that &A is not null.  The alias is only output later.

This shows a danger with per-function passes: if a function refers
to globals then those globals had better be in their final state
before any passes are run.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Tue Sep 18 14:07:42 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 18 Sep 2007 14:07:42 -0500
Subject: [LLVMbugs] [Bug 1679] New: GEP is unsigned
Message-ID: <bug-1679-206@http.llvm.org/bugs/>

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

           Summary: GEP is unsigned
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Backend: C
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: stein at ir.iit.edu
                CC: llvmbugs at cs.uiuc.edu


The C generated for:
%head.3 = getelementptr i8* %head.2, i32 -1
is:
llvm_cbe_head_3 = &llvm_cbe_head_2[((unsigned int )-1)];
Which is incorrect, due to signedness.
It should be:
llvm_cbe_head_3 = &llvm_cbe_head_2[((int )-1)];

This way instead of having:
$1 = (unsigned char *) 0x10060d016 <Address 0x10060d016 out of bounds>
I could have
$1 = (unsigned char *) 0x60d016 ""

This problem was noticed on AMD64,
so the pointer is 64-bit instead of 32-bit,
thus there was an extra 1 to be added from an unsigned addition.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Tue Sep 18 15:08:32 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 18 Sep 2007 15:08:32 -0500
Subject: [LLVMbugs] [Bug 1680] New: x86 inline asm generates wrong code
Message-ID: <bug-1680-206@http.llvm.org/bugs/>

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

           Summary: x86 inline asm generates wrong code
           Product: new-bugs
           Version: unspecified
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: astrange at ithinksw.com
                CC: llvmbugs at cs.uiuc.edu


This is the llvm 2.1 prerelease for darwin/x86.

> /usr/local/llvmgcc/bin/llvm-gcc -v
Using built-in specs.
Target: i686-apple-darwin8
Configured with: ../src/configure
--prefix=/Users/lattner/2.1/llvm-gcc4.0-2.1.source/obj/../install
--enable-llvm=/Users/lattner/2.1/llvm-2.1 --enable-languages=c,c++,objc,obj-c++
--with-arch=nocona --with-tune=generic
--with-gxx-include-dir=/usr/include/c++/4.0.0 --build=i686-apple-darwin8
--host=i686-apple-darwin8 --target=i686-apple-darwin8 : (reconfigured)
../src/configure
--prefix=/Users/lattner/2.1/llvm-gcc4.0-2.1.source/obj/../install
--enable-llvm=/Users/lattner/2.1/llvm-2.1 --enable-languages=c,c++,objc,obj-c++
--with-arch=nocona --with-tune=generic
--with-gxx-include-dir=/usr/include/c++/4.0.0 --build=i686-apple-darwin8
--host=i686-apple-darwin8 --target=i686-apple-darwin8 --program-prefix=llvm-
Thread model: posix
gcc version 4.0.1 (Apple Computer, Inc. build 5449)(LLVM build 2.1)

compared to:
> /usr/local/gcc43/bin/gcc -v
Using built-in specs.
Target: i386-apple-darwin8.10.1
Configured with: ../gcc/configure --prefix=/usr/local/gcc43 --with-arch=nocona
--with-tune=nocona --with-gmp=/sw --with-system-zlib
--enable-languages=c,c++,objc,obj-c++
Thread model: posix
gcc version 4.3.0 20070915 (experimental) (GCC) 

> /usr/local/llvmgcc/bin/llvm-gcc -fstrict-aliasing -O3 -fomit-frame-pointer -mdynamic-no-pic -march=nocona -mtune=nocona -S h264-cabac.i -o llvm-gcc21.s

This asm has these constraints:
        :"=&a"(bit)
        :"r"(state), "r"(c)
        : "%""ecx", "%ebx", "%edx", "%esi", "memory"

GCC 4.3 allocates the first three to eax, edi, and ebp.
LLVM uses eax, ecx, and edx.
This generates wrong code since ecx and edx are already in the clobber list.

BTW, I think gcc 4.3 generates better code for the C version; llvm uses (%esp)
instead of a register in one important part.

FSF gcc doesn't have -mdynamic-no-pic, so I had to compile with -fno-pic, which
lets it generate "_ff_h264_lps_range(%edi,%eax,2)" directly instead of using
$non_lazy_ptr. Since that seems to work and the asm does it anyway, I'm not
really sure what the difference is.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Tue Sep 18 16:07:33 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 18 Sep 2007 16:07:33 -0500
Subject: [LLVMbugs] [Bug 1681] New: llc aborts with " Register class of
 operand and regclass of use don't agree!"
Message-ID: <bug-1681-206@http.llvm.org/bugs/>

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

           Summary: llc aborts with "Register class of operand and regclass
                    of use don't agree!"
           Product: new-bugs
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Keywords: compile-fail
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: jlh at gmx.ch
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=1132)
 --> (http://llvm.org/bugs/attachment.cgi?id=1132)
Bitcode triggering the error

Software: linux-2.6/gentoo, LLVM 2.1 prerelease 1

When running "llc file.bc" (file is attached), I get the following output:

Register class of operand and regclass of use don't agree!
Operand = 0
Op->Val = 0x85f6918: f32,ch = LD_Fp32m 0x85f8230, 0x85f6670, 0x85f7118,
0x85f66d8, 0x85f6ae0
MI = UCOMISSrm  %reg1025
VReg = 1025
VReg RegClass     size = 4, align = 4
Expected RegClass size = 4, align = 4
Fatal error, aborting.
llc((anonymous namespace)::PrintStackTrace()+0x19)[0x8501759]
Aborted

I originally got this error on the final linking step in the process of
building POV-Ray 3.6.1 with LLVM (with link-time optimization enabled).  I then
reduced that case to this small test case.  For your convenience, here's the
human readable form:

define void @myfunc() {
        %zerodouble = add double 0.0, 0.0
        br label %label
label:
        %zerofloat = fptrunc double %zerodouble to float
        %cond = fcmp ogt float %zerofloat, 2.0
        br i1 %cond, label %label, label %label
}


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Wed Sep 19 05:38:56 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 19 Sep 2007 05:38:56 -0500
Subject: [LLVMbugs] [Bug 1682] New: make test failures on Solaris (SPARC)
Message-ID: <bug-1682-206@http.llvm.org/bugs/>

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

           Summary: make test failures on Solaris (SPARC)
           Product: cfe
           Version: unspecified
          Platform: Sun
        OS/Version: Solaris
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Semantic Analyzer
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: ggreif at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Here is the list I got today:

Sema/cocoa.m
******************** TEST 'Sema/cocoa.m' FAILED! ********************
Command: 
 clang Sema/cocoa.m -arch ppc
Output:
Sema/cocoa.m:3:10: error: 'Cocoa/Cocoa.h' file not found
#include <Cocoa/Cocoa.h>
         ^
1 diagnostic generated.
******************** TEST 'Sema/cocoa.m' FAILED! ********************




Sema/switch.c
******************** TEST 'Sema/switch.c' FAILED! ********************
Command: 
 clang -parse-ast-check Sema/switch.c
Output:
Errors expected but not seen:
  Line 11: previous case value
  Line 13: duplicate case value
Errors seen but not expected:
  Line 11: duplicate case value '42'
  Line 13: previous case value occurrence defined here
******************** TEST 'Sema/switch.c' FAILED! ********************




Sema/carbon.c
******************** TEST 'Sema/carbon.c' FAILED! ********************
Command: 
 clang Sema/carbon.c -fsyntax-only -arch ppc
Output:
Sema/carbon.c:3:10: error: 'Carbon/Carbon.h' file not found
#include <Carbon/Carbon.h>
         ^
1 diagnostic generated.
******************** TEST 'Sema/carbon.c' FAILED! ********************





Sema/format-strings.c
******************** TEST 'Sema/format-strings.c' FAILED! ********************
Command: 
 clang -parse-ast-check Sema/format-strings.c
Output:
Errors seen but not expected:
  Line 10: use of undeclared identifier '__builtin_va_alist'
  Line 51: use of undeclared identifier '__builtin_va_alist'
  Line 60: use of undeclared identifier '__builtin_va_alist'
******************** TEST 'Sema/format-strings.c' FAILED! ********************






The switch.c test seems to give the same diagnostics, but attributes them to
the exchanged lines. Very strange. Maybe it is some indeterministic ordering
issue.


My system compiler is

ggreif at dengsvr18 [!273] g++ --version
g++ (GCC) 3.4.6
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


Cheers,

   Gabor


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Wed Sep 19 08:22:49 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 19 Sep 2007 08:22:49 -0500
Subject: [LLVMbugs] [Bug 1683] New: wrong predsimplify simplification
Message-ID: <bug-1683-206@http.llvm.org/bugs/>

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

           Summary: wrong predsimplify simplification
           Product: new-bugs
           Version: unspecified
          Platform: Other
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: baldrick at free.fr
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=1133)
 --> (http://llvm.org/bugs/attachment.cgi?id=1133)
testcase .ll

Running
  opt -predsimplify t.bc
on the following testcase shows the following wrong change:

<       br label %bb99
---
>       unreachable

To see that it is wrong, note that @report__ident_int
returns its argument (it is the identity function).  Thus
  %tmp4 = 6
So %tmp6 = 0 and invcont branches to bb9.
Then %tmp51 = 12, %tmp56 = 0 and bb9 branches to bb9.bb61_crit_edge,
which branches to bb61.  Thus %J4b.0 = 6 and %tmp70 = 0, causing
a branch to bb73, so %tmp75 = 7.  Going around the loop, finally
%J4b.0 = 12 and %tmp70 = 1, causing a branch to bb61.bb76_crit_edge,
so to bb76.

In bb76 we get
  %tmp78 = 0
  %tmp81 = 12
  %tmp8182 = 12
  %tmp8384 = 6
  %tmp85 = 6
  %tmp86 = 0
  %tmp90 = 0
and thus branch to bb76.bb99_crit_edge.

Now bb76.bb99_crit_edge branches to bb99, but predsimplify
replaces this with unreachable, which is wrong since as you
just saw it is perfectly reachable.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Wed Sep 19 10:30:18 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 19 Sep 2007 10:30:18 -0500
Subject: [LLVMbugs] [Bug 1684] New: llc reads freed memory when run on
 2006-11-30-NoCompileUnit .cpp
Message-ID: <bug-1684-206@http.llvm.org/bugs/>

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

           Summary: llc reads freed memory when run on 2006-11-30-
                    NoCompileUnit.cpp
           Product: new-bugs
           Version: unspecified
          Platform: Other
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: baldrick at free.fr
                CC: llvmbugs at cs.uiuc.edu


Running test/C++Frontend/2006-11-30-NoCompileUnit.cpp under valgrind
shows it reading freed memory in llvm::DIEBlock::BestForm.

To reproduce, run
  llvm-gcc -S -O0 -emit-llvm -g 2006-11-30-NoCompileUnit.cpp -o - | llvm-as |
valgrind --tool=memcheck llc --disable-fp-elim -f -o NoCompileUnit.s


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Wed Sep 19 10:34:56 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 19 Sep 2007 10:34:56 -0500
Subject: [LLVMbugs] [Bug 1685] New: eraseLocalLLVMValues accesses memory
 freed in emit_global_to_llvm
Message-ID: <bug-1685-206@http.llvm.org/bugs/>

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

           Summary: eraseLocalLLVMValues accesses memory freed in
                    emit_global_to_llvm
           Product: new-bugs
           Version: unspecified
          Platform: Other
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: baldrick at free.fr
                CC: llvmbugs at cs.uiuc.edu


Compiling test/C++Frontend/2007-01-06-PtrMethodInit.cpp with
llvm-gcc-4.2 running under valgrind shows the following:

==12998== Invalid read of size 2
==12998==    at 0x84FD3FC: eraseLocalLLVMValues() (Value.h:207)
==12998==    by 0x851E9D0: TreeToLLVM::FinishFunctionBody()
(llvm-convert.cpp:766)
...
==12998==  Address 0x438a9c4 is 4 bytes inside a block of size 68 free'd
==12998==    at 0x4022166: operator delete(void*) (vg_replace_malloc.c:336)
==12998==    by 0x8AE1C3E: llvm::GlobalVariable::~GlobalVariable()
(GlobalVariable.h:33)
==12998==    by 0x84F585F: emit_global_to_llvm (llvm-backend.cpp:821)


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Wed Sep 19 11:17:47 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 19 Sep 2007 11:17:47 -0500
Subject: [LLVMbugs] [Bug 1685] eraseLocalLLVMValues accesses memory freed in
 emit_global_to_llvm
In-Reply-To: <bug-1685-206@http.llvm.org/bugs/>
Message-ID: <200709191617.l8JGHl4D017544@zion.cs.uiuc.edu>

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


Anton Korobeynikov <asl at math.spbu.ru> changed:

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




--- Comment #2 from Anton Korobeynikov <asl at math.spbu.ru>  2007-09-19 11:17:47 ---
Fixed in:

http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070917/053682.html
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070917/053684.html


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Wed Sep 19 11:28:44 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 19 Sep 2007 11:28:44 -0500
Subject: [LLVMbugs] [Bug 1359] Finish Danny Berlin's Re-implementation of
	Andersen's AA
In-Reply-To: <bug-1359-206@http.llvm.org/bugs/>
Message-ID: <200709191628.l8JGSirS018150@zion.cs.uiuc.edu>

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


Daniel Berlin <dberlin at dberlin.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dberlin at dberlin.org
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED




--- Comment #6 from Daniel Berlin <dberlin at dberlin.org>  2007-09-19 11:28:44 ---
Fixed


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Wed Sep 19 12:30:17 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 19 Sep 2007 12:30:17 -0500
Subject: [LLVMbugs] [Bug 1686] New: llc -march= arm reads from freed memory
 on 2007-01-19-InfiniteLoop.ll
Message-ID: <bug-1686-206@http.llvm.org/bugs/>

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

           Summary: llc -march=arm reads from freed memory on 2007-01-19-
                    InfiniteLoop.ll
           Product: new-bugs
           Version: unspecified
          Platform: Other
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: baldrick at free.fr
                CC: llvmbugs at cs.uiuc.edu


Running test/CodeGen/ARM/2007-01-19-InfiniteLoop.ll shows llc reading
from freed memory:

==19601==    at 0x8369D9A:
llvm::ilist_traits<llvm::MachineInstr>::getPrev(llvm::MachineInstr*)
...
==19601==  Address 0x437850c is 20 bytes inside a block of size 32 free'd
==19601==    at 0x4022166: operator delete(void*) (vg_replace_malloc.c:336)
==19601==    by 0x837598A: llvm::iplist<llvm::MachineInstr,
llvm::ilist_traits<llvm::MachineInstr>
>::erase(llvm::ilist_iterator<llvm::MachineInstr>) (ilist:368)
==19601==    by 0x83759B9:
llvm::MachineBasicBlock::erase(llvm::ilist_iterator<llvm::MachineInstr>)

To reproduce:

llvm-as 2007-01-19-InfiniteLoop.ll -o - | valgrind --tool=memcheck llc
-march=arm -mattr=+v6,+vfp2 -o 2007-01-19-InfiniteLoop.s -f


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Wed Sep 19 15:22:24 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 19 Sep 2007 15:22:24 -0500
Subject: [LLVMbugs] [Bug 1657] licm promotes store to null pointer
In-Reply-To: <bug-1657-206@http.llvm.org/bugs/>
Message-ID: <200709192022.l8JKMOEk029787@zion.cs.uiuc.edu>

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


Devang Patel <dpatel at apple.com> changed:

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




--- Comment #9 from Devang Patel <dpatel at apple.com>  2007-09-19 15:22:23 ---
Fixed.
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070917/053653.html


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Wed Sep 19 17:06:13 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 19 Sep 2007 17:06:13 -0500
Subject: [LLVMbugs] [Bug 1686] llc -march= arm reads from freed memory on
 2007-01-19-InfiniteLoop.ll
In-Reply-To: <bug-1686-206@http.llvm.org/bugs/>
Message-ID: <200709192206.l8JM6DIT001924@zion.cs.uiuc.edu>

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


Evan Cheng <evan.cheng at apple.com> changed:

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




--- Comment #3 from Evan Cheng <evan.cheng at apple.com>  2007-09-19 17:06:12 ---
Fixed.
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070917/053696.html

Duncan, please verify. Thanks!


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Wed Sep 19 19:49:31 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 19 Sep 2007 19:49:31 -0500
Subject: [LLVMbugs] [Bug 1683] wrong predsimplify simplification
In-Reply-To: <bug-1683-206@http.llvm.org/bugs/>
Message-ID: <200709200049.l8K0nVhv007453@zion.cs.uiuc.edu>

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


Nick Lewycky <nicholas at mxc.ca> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|enhancement                 |minor
             Status|ASSIGNED                    |RESOLVED
           Keywords|                            |miscompilation
         Resolution|                            |FIXED




--- Comment #2 from Nick Lewycky <nicholas at mxc.ca>  2007-09-19 19:49:30 ---
Fixed in r42157.

Thanks for the bug report!


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Wed Sep 19 21:45:41 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 19 Sep 2007 21:45:41 -0500
Subject: [LLVMbugs] [Bug 1687] New: opt -loop-index-split segfaults on
 SaveLastValue-2007-08-17 .ll
Message-ID: <bug-1687-206@http.llvm.org/bugs/>

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

           Summary: opt -loop-index-split segfaults on SaveLastValue-2007-
                    08-17.ll
           Product: new-bugs
           Version: unspecified
          Platform: PC
        OS/Version: FreeBSD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: emil at cs.rmit.edu.au
                CC: llvmbugs at cs.uiuc.edu


With a Debug+Checking build of LLVM 2.1 prerelease,
"make check" uncovers [among other things]:

FAIL:
/home/emil/ll/llvm-2.1/test/Transforms/LoopIndexSplit/SaveLastValue-2007-08-17.ll
Failed with exit(1) at line 1
while running: llvm-as <
/home/emil/ll/llvm-2.1/test/Transforms/LoopIndexSplit/SaveLastValue-2007-08-17.ll
| opt -loop-index-split -disable-output -stats |&  grep "loop-index-split" |
count 1
count: expected 1 lines and got        0.
child killed: segmentation violation
child process exited abnormally

#0  0x08495206 in llvm::Instruction::getNext (this=0x5a5a5a5a)
    at Instruction.h:231
231       Instruction *getNext()             { return Next; }
(gdb) where
#0  0x08495206 in llvm::Instruction::getNext (this=0x5a5a5a5a)
    at Instruction.h:231
#1  0x08496a51 in llvm::SymbolTableListTraits<llvm::Instruction,
llvm::BasicBlock>::getNext (V=0x5a5a5a5a) at SymbolTableListTraits.h:52
#2  0x084d6db3 in llvm::ilist_iterator<llvm::Instruction>::operator
llvm::Instruction* (this=0xbfbfe400) at ilist:115
#3  0x085c94ad in removeBlocks (this=0x28c31180, DeadBB=0x28c18190, 
    LP=0x28c04880, LiveBB=0x28c181c0)
    at /home/emil/ll/llvm-2.1/lib/Transforms/Scalar/LoopIndexSplit.cpp:721
#4  0x085c9ef0 in splitLoop (this=0x28c31180, SD=@0x28c311d0)
    at /home/emil/ll/llvm-2.1/lib/Transforms/Scalar/LoopIndexSplit.cpp:1127
#5  0x085cb40c in runOnLoop (this=0x28c31180, IncomingLoop=0x28c04880, 
    LPM_Ref=@0x28c39040)
    at /home/emil/ll/llvm-2.1/lib/Transforms/Scalar/LoopIndexSplit.cpp:253
#6  0x08716044 in llvm::LPPassManager::runOnFunction (this=0x28c39040, 
    F=@0x28c02240) at /home/emil/ll/llvm-2.1/lib/Analysis/LoopPass.cpp:225
#7  0x0881f31d in llvm::FPPassManager::runOnFunction (this=0x28c37060, 
    F=@0x28c02240) at /home/emil/ll/llvm-2.1/lib/VMCore/PassManager.cpp:1168
#8  0x0881f4b4 in llvm::FPPassManager::runOnModule (this=0x28c37060, 
    M=@0x28c04480) at /home/emil/ll/llvm-2.1/lib/VMCore/PassManager.cpp:1188
#9  0x0881efd3 in llvm::MPPassManager::runOnModule (this=0x28c211b0, 
    M=@0x28c04480) at /home/emil/ll/llvm-2.1/lib/VMCore/PassManager.cpp:1237
#10 0x0881f194 in llvm::PassManagerImpl::run (this=0x28c24040, M=@0x28c04480)
    at /home/emil/ll/llvm-2.1/lib/VMCore/PassManager.cpp:1310
#11 0x0881f1fa in llvm::PassManager::run (this=0xbfbfe984, M=@0x28c04480)
    at /home/emil/ll/llvm-2.1/lib/VMCore/PassManager.cpp:1342
#12 0x0848421b in main (argc=4, argv=0xbfbfec70)
    at /home/emil/ll/llvm-2.1/tools/opt/opt.cpp:426

(gdb) print this
$2 = (llvm::Instruction * const) 0x5a5a5a5a
(gdb) print *this
Cannot access memory at address 0x5a5a5a5a


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Thu Sep 20 00:26:44 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 20 Sep 2007 00:26:44 -0500
Subject: [LLVMbugs] [Bug 1688] New: Assertion failed:
 (APInt::tcCompare(dividend, divisor, partsCount) >= 0)
Message-ID: <bug-1688-206@http.llvm.org/bugs/>

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

           Summary: Assertion failed: (APInt::tcCompare(dividend, divisor,
                    partsCount) >= 0)
           Product: new-bugs
           Version: unspecified
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: major
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: mark+llvm.org at bdash.net.nz
                CC: llvmbugs at cs.uiuc.edu


Compiling the following code in a file named test.cpp:

double intPow10() {
     long double result = 10.0;
     return static_cast<double>(1.0 / result);
 }


with the command:
llvm-g++ -Os -c test.cpp

Results in:
Assertion failed: (APInt::tcCompare(dividend, divisor, partsCount) >= 0),
function divideSignificand, file
/Volumes/Data/Home/Documents/Source/SVN/llvm-project/llvm/lib/Support/APFloat.cpp,
line 578.
test.cpp: In function ???double intPow10()???:
test.cpp:1: internal compiler error: Abort trap
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://llvm.org/bugs> for instructions.

This is using LLVM and llvm-gcc from r42159 of trunk on Mac OS X.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Thu Sep 20 01:25:41 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 20 Sep 2007 01:25:41 -0500
Subject: [LLVMbugs] [Bug 1689] New: lli reads freed memory on
	bit-intrinsics.ll
Message-ID: <bug-1689-206@http.llvm.org/bugs/>

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

           Summary: lli reads freed memory on bit-intrinsics.ll
           Product: new-bugs
           Version: unspecified
          Platform: Other
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: baldrick at free.fr
                CC: llvmbugs at cs.uiuc.edu


Running test/Codegen/Generic/bit-intrinsics.ll under valgrind gives
the following:

Invalid read of size 2
   at 0x8329D52: llvm::Value::getValueID() const (Value.h:207)
   by 0x841B920: llvm::Instruction::getOpcode() const (Instruction.h:104)
   by 0x843E706: llvm::CallInst::classof(llvm::Instruction const*)
(Instructions.h:931)
   by 0x843F9B8: bool llvm::isa_impl<llvm::CallInst,
llvm::Instruction>(llvm::Instruction const&) (Casting.h:54)
   by 0x843F9CE: llvm::isa_impl_wrap<llvm::CallInst, llvm::Instruction const,
llvm::Instruction const>::doit(llvm::Instruction const&) (Casting.h:71)
   by 0x843F9E4: bool
llvm::isa_impl_cl<llvm::Instruction>::isa<llvm::CallInst>(llvm::Instruction
const&) (Casting.h:83)
   by 0x843F9FA: bool llvm::isa<llvm::CallInst,
llvm::Instruction>(llvm::Instruction const&) (Casting.h:116)
   by 0x84392B4: llvm::Interpreter::run() (Execution.cpp:1368)
   by 0x843DDF1: llvm::Interpreter::runFunction(llvm::Function*,
std::vector<llvm::GenericValue, std::allocator<llvm::GenericValue> > const&)
(Interpreter.cpp:102)
   by 0x845B9BA: llvm::ExecutionEngine::runFunctionAsMain(llvm::Function*,
std::vector<std::string, std::allocator<std::string> > const&, char const*
const*) (ExecutionEngine.cpp:284)
   by 0x8329B94: main (lli.cpp:141)
 Address 0x42d305c is 4 bytes inside a block of size 44 free'd
   at 0x4022166: operator delete(void*) (vg_replace_malloc.c:336)
   by 0x86A6268: llvm::CallInst::~CallInst() (Instructions.cpp:192)
   by 0x85B5F92: llvm::iplist<llvm::Instruction,
llvm::ilist_traits<llvm::Instruction>
>::erase(llvm::ilist_iterator<llvm::Instruction>) (ilist:368)
   by 0x869739C: llvm::Instruction::eraseFromParent() (Instruction.cpp:68)
   by 0x8562A41: llvm::IntrinsicLowering::LowerIntrinsicCall(llvm::CallInst*)
(IntrinsicLowering.cpp:801)
   by 0x843701C: llvm::Interpreter::visitCallSite(llvm::CallSite)
(Execution.cpp:874)
   by 0x8444903: llvm::Interpreter::visitCallInst(llvm::CallInst&)
(Interpreter.h:164)
   by 0x844491D: llvm::InstVisitor<llvm::Interpreter,
void>::visitCall(llvm::CallInst&) (Instruction.def:159)
   by 0x8444F15: llvm::InstVisitor<llvm::Interpreter,
void>::visit(llvm::Instruction&) (Instruction.def:159)
   by 0x84392A9: llvm::Interpreter::run() (Execution.cpp:1366)
   by 0x843DDF1: llvm::Interpreter::runFunction(llvm::Function*,
std::vector<llvm::GenericValue, std::allocator<llvm::GenericValue> > const&)
(Interpreter.cpp:102)
   by 0x845B9BA: llvm::ExecutionEngine::runFunctionAsMain(llvm::Function*,
std::vector<std::string, std::allocator<std::string> > const&, char const*
const*) (ExecutionEngine.cpp:284)

Reproduce as follows:
  llvm-as -f bit-intrinsics.ll
  valgrind --tool=memcheck lli --force-interpreter=true bit-intrinsics.bc


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Thu Sep 20 01:33:37 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 20 Sep 2007 01:33:37 -0500
Subject: [LLVMbugs] [Bug 1690] New: LoopUnswitch reads freed memory
Message-ID: <bug-1690-206@http.llvm.org/bugs/>

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

           Summary: LoopUnswitch reads freed memory
           Product: new-bugs
           Version: unspecified
          Platform: Other
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: baldrick at free.fr
                CC: llvmbugs at cs.uiuc.edu


Running test/Transforms/LoopUnswitch/2007-08-01-Dom.ll under valgrind
shows
Invalid read of size 2
   at 0x82C8548: llvm::Value::getValueID() const (Value.h:207)
   by 0x82C85BC: bool llvm::isa_impl<llvm::Instruction,
llvm::Value>(llvm::Value const&) (Value.h:256)
   by 0x82C8D20: llvm::isa_impl_wrap<llvm::Instruction, llvm::Value const,
llvm::Value const>::doit(llvm::Value const&) (Casting.h:71)
   by 0x82C8D36: bool
llvm::isa_impl_cl<llvm::Value>::isa<llvm::Instruction>(llvm::Value const&)
(Casting.h:83)
   by 0x82C8D4C: bool
llvm::isa_impl_cl<llvm::Value*>::isa<llvm::Instruction>(llvm::Value*)
(Casting.h:101)
   by 0x82C8D64: bool llvm::isa<llvm::Instruction, llvm::Value*>(llvm::Value*
const&) (Casting.h:116)
   by 0x82C9132: llvm::cast_retty<llvm::Instruction, llvm::Value*>::ret_type
llvm::dyn_cast<llvm::Instruction, llvm::Value*>(llvm::Value*) (Casting.h:225)
   by 0x82C9164: llvm::CallSite::get(llvm::Value*) (CallSite.h:46)
   by 0x8474D02: llvm::AliasSetTracker::deleteValue(llvm::Value*)
(AliasSetTracker.cpp:456)
   by 0x83B3953: (anonymous namespace)::LICM::deleteAnalysisValue(llvm::Value*,
llvm::Loop*) (LICM.cpp:835)
   by 0x849276C: llvm::LPPassManager::deleteSimpleAnalysisValue(llvm::Value*,
llvm::Loop*) (LoopPass.cpp:159)
   by 0x83D6896: (anonymous
namespace)::LoopUnswitch::UnswitchNontrivialCondition(llvm::Value*,
llvm::Constant*, llvm::Loop*) (LoopUnswitch.cpp:763)
 Address 0x42ec734 is 4 bytes inside a block of size 88 free'd
   at 0x4022166: operator delete(void*) (vg_replace_malloc.c:336)
   by 0x853BCF0: llvm::BranchInst::~BranchInst() (Instructions.h:1389)
   by 0x82EBB8C: llvm::iplist<llvm::Instruction,
llvm::ilist_traits<llvm::Instruction>
>::erase(llvm::ilist_iterator<llvm::Instruction>) (ilist:368)
   by 0x852B9A8: llvm::Instruction::eraseFromParent() (Instruction.cpp:68)
   by 0x83D6871: (anonymous
namespace)::LoopUnswitch::UnswitchNontrivialCondition(llvm::Value*,
llvm::Constant*, llvm::Loop*) (LoopUnswitch.cpp:762)
   by 0x83D7578: (anonymous
namespace)::LoopUnswitch::UnswitchIfProfitable(llvm::Value*, llvm::Constant*,
llvm::Loop*) (LoopUnswitch.cpp:409)
   by 0x83D7797: (anonymous namespace)::LoopUnswitch::processLoop(llvm::Loop*)
(LoopUnswitch.cpp:191)
   by 0x83D7A53: (anonymous namespace)::LoopUnswitch::runOnLoop(llvm::Loop*,
llvm::LPPassManager&) (LoopUnswitch.cpp:167)
   by 0x8493062: llvm::LPPassManager::runOnFunction(llvm::Function&)
(LoopPass.cpp:225)
   by 0x854EADB: llvm::FPPassManager::runOnFunction(llvm::Function&)
(PassManager.cpp:1168)
   by 0x854EC7D: llvm::FPPassManager::runOnModule(llvm::Module&)
(PassManager.cpp:1188)
   by 0x854E7B1: llvm::MPPassManager::runOnModule(llvm::Module&)
(PassManager.cpp:1237)

Reproduce using
  llvm-as < 2007-08-01-Dom.ll | valgrind --tool=memcheck opt -licm
-loop-unswitch -disable-output


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Thu Sep 20 01:38:43 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 20 Sep 2007 01:38:43 -0500
Subject: [LLVMbugs] [Bug 1691] New: LoopIndexSplit reads from freed memory
Message-ID: <bug-1691-206@http.llvm.org/bugs/>

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

           Summary: LoopIndexSplit reads from freed memory
           Product: new-bugs
           Version: unspecified
          Platform: Other
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: baldrick at free.fr
                CC: llvmbugs at cs.uiuc.edu


Running test/Transforms/LoopIndexSplit/SaveLastValue-2007-08-17.ll
under valgrind shows:
Invalid read of size 4
   at 0x82E067E: llvm::Instruction::getNext() (Instruction.h:231)
   by 0x82E1A6C: llvm::SymbolTableListTraits<llvm::Instruction,
llvm::BasicBlock>::getNext(llvm::Instruction*) (SymbolTableListTraits.h:52)
   by 0x82F3EA8: llvm::ilist_iterator<llvm::Instruction>::operator++()
(ilist:141)
   by 0x83BB36A: (anonymous
namespace)::LoopIndexSplit::removeBlocks(llvm::BasicBlock*, llvm::Loop*,
llvm::BasicBlock*) (LoopIndexSplit.cpp:930)
   by 0x83BBF14: (anonymous namespace)::LoopIndexSplit::splitLoop((anonymous
namespace)::LoopIndexSplit::SplitInfo&) (LoopIndexSplit.cpp:1351)
   by 0x83BD79A: (anonymous namespace)::LoopIndexSplit::runOnLoop(llvm::Loop*,
llvm::LPPassManager&) (LoopIndexSplit.cpp:272)
   by 0x8493062: llvm::LPPassManager::runOnFunction(llvm::Function&)
(LoopPass.cpp:225)
   by 0x854EADB: llvm::FPPassManager::runOnFunction(llvm::Function&)
(PassManager.cpp:1168)
   by 0x854EC7D: llvm::FPPassManager::runOnModule(llvm::Module&)
(PassManager.cpp:1188)
   by 0x854E7B1: llvm::MPPassManager::runOnModule(llvm::Module&)
(PassManager.cpp:1237)
   by 0x854E969: llvm::PassManagerImpl::run(llvm::Module&)
(PassManager.cpp:1310)
   by 0x854E9BB: llvm::PassManager::run(llvm::Module&) (PassManager.cpp:1342)
 Address 0x42df24c is 36 bytes inside a block of size 44 free'd
   at 0x4022166: operator delete(void*) (vg_replace_malloc.c:336)
   by 0x853A7F8: llvm::CallInst::~CallInst() (Instructions.cpp:192)
   by 0x82EBB8C: llvm::iplist<llvm::Instruction,
llvm::ilist_traits<llvm::Instruction>
>::erase(llvm::ilist_iterator<llvm::Instruction>) (ilist:368)
   by 0x852B9A8: llvm::Instruction::eraseFromParent() (Instruction.cpp:68)
   by 0x83BB35C: (anonymous
namespace)::LoopIndexSplit::removeBlocks(llvm::BasicBlock*, llvm::Loop*,
llvm::BasicBlock*) (LoopIndexSplit.cpp:934)
   by 0x83BBF14: (anonymous namespace)::LoopIndexSplit::splitLoop((anonymous
namespace)::LoopIndexSplit::SplitInfo&) (LoopIndexSplit.cpp:1351)
   by 0x83BD79A: (anonymous namespace)::LoopIndexSplit::runOnLoop(llvm::Loop*,
llvm::LPPassManager&) (LoopIndexSplit.cpp:272)
   by 0x8493062: llvm::LPPassManager::runOnFunction(llvm::Function&)
(LoopPass.cpp:225)
   by 0x854EADB: llvm::FPPassManager::runOnFunction(llvm::Function&)
(PassManager.cpp:1168)
   by 0x854EC7D: llvm::FPPassManager::runOnModule(llvm::Module&)
(PassManager.cpp:1188)
   by 0x854E7B1: llvm::MPPassManager::runOnModule(llvm::Module&)
(PassManager.cpp:1237)
   by 0x854E969: llvm::PassManagerImpl::run(llvm::Module&)
(PassManager.cpp:1310)

Reproduce using

  llvm-as < SaveLastValue-2007-08-17.ll | valgrind --tool=memcheck opt
-loop-index-split -disable-output -stats


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Thu Sep 20 13:10:12 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 20 Sep 2007 13:10:12 -0500
Subject: [LLVMbugs] [Bug 1661] ppc jit fails on SPASS
In-Reply-To: <bug-1661-206@http.llvm.org/bugs/>
Message-ID: <200709201810.l8KIACoS025712@zion.cs.uiuc.edu>

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


Chris Lattner <sabre at nondot.org> changed:

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




--- Comment #2 from Chris Lattner <sabre at nondot.org>  2007-09-20 13:10:11 ---

SPASS passed in the ppc jit last night:
http://llvm.org/nightlytest/test.php?machine=153&night=3679


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Thu Sep 20 17:16:46 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 20 Sep 2007 17:16:46 -0500
Subject: [LLVMbugs] [Bug 1691] LoopIndexSplit reads from freed memory
In-Reply-To: <bug-1691-206@http.llvm.org/bugs/>
Message-ID: <200709202216.l8KMGk33006363@zion.cs.uiuc.edu>

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


Devang Patel <dpatel at apple.com> changed:

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




--- Comment #1 from Devang Patel <dpatel at apple.com>  2007-09-20 17:16:45 ---


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


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Thu Sep 20 18:02:29 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 20 Sep 2007 18:02:29 -0500
Subject: [LLVMbugs] [Bug 1687] opt -loop-index-split segfaults on
 SaveLastValue-2007-08-17.ll
In-Reply-To: <bug-1687-206@http.llvm.org/bugs/>
Message-ID: <200709202302.l8KN2T32018413@zion.cs.uiuc.edu>

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


Devang Patel <dpatel at apple.com> changed:

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




--- Comment #2 from Devang Patel <dpatel at apple.com>  2007-09-20 18:02:27 ---
Fixed.

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


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Thu Sep 20 19:08:58 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 20 Sep 2007 19:08:58 -0500
Subject: [LLVMbugs] [Bug 1688] Assertion failed: (APInt::tcCompare(dividend,
 divisor, partsCount) >= 0)
In-Reply-To: <bug-1688-206@http.llvm.org/bugs/>
Message-ID: <200709210008.l8L08wCY021841@zion.cs.uiuc.edu>

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


Dale Johannesen <dalej at apple.com> changed:

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




--- Comment #3 from Dale Johannesen <dalej at apple.com>  2007-09-20 19:08:56 ---
This is fixed.  It turns out to be interesting, at least for those interested
in APFloat (both of us).

First, Neil's code originally added 1 to the precision when computing the
number of words for the mantissa; I mistakenly thought this had something to do
with the integer bit, and turned it off for x87 long double.  In fact that
extra bit is needed for (at least) the divide algorithm to work right.  That
was the immediate cause of the crash; I put it back the way it was.

However, fixing that requires 2 words rather than 1 to store x87 mantissas,
which exposed a problem in APFloat::convert.  Converting to a type with more
words than the incoming type is handled correctly, but when the incoming type
is 2 words and the outgoing type is only 1 (where the mantissa is stored
directly rather than by following a pointer), the corresponding conversion
wasn't done.  I have fixed this for the x87->float/double case, where the
obvious truncation preserves all 64 bits with information in them; I think this
case is correct.   However I think there would be issues with rounding if you
are losing information, as in shortening IEEEquad.  Neil, this isn't urgent,
but could you look at it sometime?  Thanks.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Thu Sep 20 23:12:44 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 20 Sep 2007 23:12:44 -0500
Subject: [LLVMbugs] [Bug 1692] New: -loop-index-split performs illegal
	transform
Message-ID: <bug-1692-206@http.llvm.org/bugs/>

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

           Summary: -loop-index-split performs illegal transform
           Product: libraries
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Loop Optimizer
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: nicholas at mxc.ca
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=1135)
 --> (http://llvm.org/bugs/attachment.cgi?id=1135)
testcase

The attached bytecode crashes when run under loop index splitting:

$ opt -loop-index-split b.bc -disable-output
Instruction does not dominate all uses!
        %j.0.i.i = phi i32 [ %tmp39.i.i, %cond_next37.i.i ], [ 0,
%bb40.i.i.loopexit ]          ; <i32> [#uses=4]
        %lsplit.ev = icmp slt i32 %lsplit.add, %j.0.i.i         ; <i1>
[#uses=1]
Instruction does not dominate all uses!
        %lsplit.ev = icmp slt i32 %lsplit.add, %j.0.i.i         ; <i1>
[#uses=1]
        %lsplit.ev1 = select i1 %lsplit.ev, i32 %lsplit.add, i32 %j.0.i.i     
; <i32> [#uses=1]
Broken module found, compilation aborted!
llvm-commit/Debug/bin/opt[0x85b9506]
llvm-commit/Debug/bin/opt[0x85b97cc]
[0xffffe500]
Aborted

To see what opt would have output, pass -disable-verify to opt.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Fri Sep 21 03:54:42 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 21 Sep 2007 03:54:42 -0500
Subject: [LLVMbugs] [Bug 1690] LoopUnswitch reads freed memory
In-Reply-To: <bug-1690-206@http.llvm.org/bugs/>
Message-ID: <200709210854.l8L8sgeC012109@zion.cs.uiuc.edu>

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


Duncan Sands <baldrick at free.fr> changed:

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




--- Comment #2 from Duncan Sands <baldrick at free.fr>  2007-09-21 03:54:42 ---
I can confirm that it is fixed.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Fri Sep 21 09:56:06 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 21 Sep 2007 09:56:06 -0500
Subject: [LLVMbugs] [Bug 1693] New: SimplifySelectCC from visitZERO_EXTEND
 uses an uninitialized value
Message-ID: <bug-1693-206@http.llvm.org/bugs/>

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

           Summary: SimplifySelectCC from visitZERO_EXTEND uses an
                    uninitialized value
           Product: new-bugs
           Version: unspecified
          Platform: Other
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: baldrick at free.fr
                CC: llvmbugs at cs.uiuc.edu


Running valgrind on test/CodeGen/ARM/2007-05-22-tailmerge-3.ll gives:

Conditional jump or move depends on uninitialised value(s)
   at 0x85C674E: (anonymous
namespace)::DAGCombiner::SimplifySelectCC(llvm::SDOperand, llvm::SDOperand,
llvm::SDOperand, llvm::SDOperand, llvm::ISD::CondCode, bool)
(DAGCombiner.cpp:4433)
   by 0x85D0A64: (anonymous
namespace)::DAGCombiner::visitZERO_EXTEND(llvm::SDNode*) (DAGCombiner.cpp:2568)
   by 0x85DB1E9: (anonymous namespace)::DAGCombiner::visit(llvm::SDNode*)
(DAGCombiner.cpp:660)
   by 0x85DB7C5: (anonymous namespace)::DAGCombiner::Run(bool)
(DAGCombiner.cpp:578)
   by 0x85DBD2A: llvm::SelectionDAG::Combine(bool, llvm::AliasAnalysis&)
(DAGCombiner.cpp:4773)
   by 0x860B2BE: llvm::SelectionDAGISel::CodeGenAndEmitDAG(llvm::SelectionDAG&)
(SelectionDAGISel.cpp:4627)
   by 0x861F5D2: llvm::SelectionDAGISel::SelectBasicBlock(llvm::BasicBlock*,
llvm::MachineFunction&, llvm::FunctionLoweringInfo&)
(SelectionDAGISel.cpp:4664)
   by 0x8621211: llvm::SelectionDAGISel::runOnFunction(llvm::Function&)
(SelectionDAGISel.cpp:4365)
   by 0x8822027: llvm::FPPassManager::runOnFunction(llvm::Function&)
(PassManager.cpp:1168)
   by 0x8822285: llvm::FunctionPassManagerImpl::run(llvm::Function&)
(PassManager.cpp:1126)
   by 0x88223DB: llvm::FunctionPassManager::run(llvm::Function&)
(PassManager.cpp:1071)
   by 0x8352F6A: main (llc.cpp:295)

Reproduce using
llvm-as < 2007-05-22-tailmerge-3.ll | valgrind --tool=memcheck llc -march=arm
-enable-eh > /dev/null


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Fri Sep 21 10:02:23 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 21 Sep 2007 10:02:23 -0500
Subject: [LLVMbugs] [Bug 1694] New: SimplifyDemandedBits uses an
	uninitialized value
Message-ID: <bug-1694-206@http.llvm.org/bugs/>

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

           Summary: SimplifyDemandedBits uses an uninitialized value
           Product: new-bugs
           Version: unspecified
          Platform: Other
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: baldrick at free.fr
                CC: llvmbugs at cs.uiuc.edu


Running test/CodeGen/ARM/2007-08-14-SpillDeadDef.ll under valgrind gives

Conditional jump or move depends on uninitialised value(s)
   at 0x86420A3: llvm::TargetLowering::SimplifyDemandedBits(llvm::SDOperand,
unsigned long long, unsigned long long&, unsigned long long&,
llvm::TargetLowering::TargetLoweringOpt&, unsigned) const
(TargetLowering.cpp:516)
   by 0x86411DB: llvm::TargetLowering::SimplifyDemandedBits(llvm::SDOperand,
unsigned long long, unsigned long long&, unsigned long long&,
llvm::TargetLowering::TargetLoweringOpt&, unsigned) const
(TargetLowering.cpp:403)
   by 0x85D1829: (anonymous
namespace)::DAGCombiner::SimplifyDemandedBits(llvm::SDOperand)
(DAGCombiner.cpp:159)
   by 0x85D838B: (anonymous namespace)::DAGCombiner::visitAND(llvm::SDNode*)
(DAGCombiner.cpp:1525)
   by 0x85DB03C: (anonymous namespace)::DAGCombiner::visit(llvm::SDNode*)
(DAGCombiner.cpp:647)
   by 0x85DB7C5: (anonymous namespace)::DAGCombiner::Run(bool)
(DAGCombiner.cpp:578)
   by 0x85DBD2A: llvm::SelectionDAG::Combine(bool, llvm::AliasAnalysis&)
(DAGCombiner.cpp:4773)
   by 0x860B2BE: llvm::SelectionDAGISel::CodeGenAndEmitDAG(llvm::SelectionDAG&)
(SelectionDAGISel.cpp:4627)
   by 0x861F5D2: llvm::SelectionDAGISel::SelectBasicBlock(llvm::BasicBlock*,
llvm::MachineFunction&, llvm::FunctionLoweringInfo&)
(SelectionDAGISel.cpp:4664)
   by 0x8621211: llvm::SelectionDAGISel::runOnFunction(llvm::Function&)
(SelectionDAGISel.cpp:4365)
   by 0x8822027: llvm::FPPassManager::runOnFunction(llvm::Function&)
(PassManager.cpp:1168)
   by 0x8822285: llvm::FunctionPassManagerImpl::run(llvm::Function&)
(PassManager.cpp:1126)

Conditional jump or move depends on uninitialised value(s)
   at 0x86420A3: llvm::TargetLowering::SimplifyDemandedBits(llvm::SDOperand,
unsigned long long, unsigned long lo
ng&, unsigned long long&, llvm::TargetLowering::TargetLoweringOpt&, unsigned)
const (TargetLowering.cpp:516)        by 0x86412AA:
llvm::TargetLowering::SimplifyDemandedBits(llvm::SDOperand, unsigned long long,
unsigned long lo
ng&, unsigned long long&, llvm::TargetLowering::TargetLoweringOpt&, unsigned)
const (TargetLowering.cpp:407)
   by 0x85D1829: (anonymous
namespace)::DAGCombiner::SimplifyDemandedBits(llvm::SDOperand)
(DAGCombiner.cpp:159)
   by 0x85D838B: (anonymous namespace)::DAGCombiner::visitAND(llvm::SDNode*)
(DAGCombiner.cpp:1525)
   by 0x85DB03C: (anonymous namespace)::DAGCombiner::visit(llvm::SDNode*)
(DAGCombiner.cpp:647)
   by 0x85DB7C5: (anonymous namespace)::DAGCombiner::Run(bool)
(DAGCombiner.cpp:578)
   by 0x85DBD2A: llvm::SelectionDAG::Combine(bool, llvm::AliasAnalysis&)
(DAGCombiner.cpp:4773)
   by 0x860B2BE: llvm::SelectionDAGISel::CodeGenAndEmitDAG(llvm::SelectionDAG&)
(SelectionDAGISel.cpp:4627)
   by 0x861F5D2: llvm::SelectionDAGISel::SelectBasicBlock(llvm::BasicBlock*,
llvm::MachineFunction&, llvm::FunctionLoweringInfo&)
(SelectionDAGISel.cpp:4664)
   by 0x8621211: llvm::SelectionDAGISel::runOnFunction(llvm::Function&)
(SelectionDAGISel.cpp:4365)
   by 0x8822027: llvm::FPPassManager::runOnFunction(llvm::Function&)
(PassManager.cpp:1168)
   by 0x8822285: llvm::FunctionPassManagerImpl::run(llvm::Function&)
(PassManager.cpp:1126)

Reproduce using
llvm-as < 2007-08-14-SpillDeadDef.ll | valgrind --tool=memcheck llc
-mtriple=arm-apple-darwin > /dev/null


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Fri Sep 21 12:07:39 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 21 Sep 2007 12:07:39 -0500
Subject: [LLVMbugs] [Bug 1693] SimplifySelectCC from visitZERO_EXTEND uses
 an uninitialized value
In-Reply-To: <bug-1693-206@http.llvm.org/bugs/>
Message-ID: <200709211707.l8LH7dfv032014@zion.cs.uiuc.edu>

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


Chris Lattner <sabre at nondot.org> changed:

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




--- Comment #1 from Chris Lattner <sabre at nondot.org>  2007-09-21 12:07:39 ---
Fixed, patch here, please verify.
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070917/053737.html

Thanks Duncan!

-Chris


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Fri Sep 21 12:08:33 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 21 Sep 2007 12:08:33 -0500
Subject: [LLVMbugs] [Bug 1694] SimplifyDemandedBits uses an uninitialized
	value
In-Reply-To: <bug-1694-206@http.llvm.org/bugs/>
Message-ID: <200709211708.l8LH8XuF032069@zion.cs.uiuc.edu>

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


Chris Lattner <sabre at nondot.org> changed:

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




--- Comment #1 from Chris Lattner <sabre at nondot.org>  2007-09-21 12:08:33 ---
I'm pretty certain this is a dup of 1693, plz verify

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


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Fri Sep 21 13:30:57 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 21 Sep 2007 13:30:57 -0500
Subject: [LLVMbugs] [Bug 1689] lli reads freed memory on bit-intrinsics.ll
In-Reply-To: <bug-1689-206@http.llvm.org/bugs/>
Message-ID: <200709211830.l8LIUvnH004417@zion.cs.uiuc.edu>

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


Chris Lattner <sabre at nondot.org> changed:

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




--- Comment #3 from Chris Lattner <sabre at nondot.org>  2007-09-21 13:30:56 ---
fixed:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070917/053752.html


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Fri Sep 21 16:18:45 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 21 Sep 2007 16:18:45 -0500
Subject: [LLVMbugs] [Bug 1692] -loop-index-split performs illegal transform
In-Reply-To: <bug-1692-206@http.llvm.org/bugs/>
Message-ID: <200709212118.l8LLIj0x032579@zion.cs.uiuc.edu>

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


Devang Patel <dpatel at apple.com> changed:

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




--- Comment #1 from Devang Patel <dpatel at apple.com>  2007-09-21 16:18:44 ---
Fixed.

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


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Fri Sep 21 18:16:03 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 21 Sep 2007 18:16:03 -0500
Subject: [LLVMbugs] [Bug 1653] Obj-C NSString crash in front end of LLVM-GCC
 4.2/ arm-apple-darwin
In-Reply-To: <bug-1653-206@http.llvm.org/bugs/>
Message-ID: <200709212316.l8LNG3YU020645@zion.cs.uiuc.edu>

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


Devang Patel <dpatel at apple.com> changed:

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




--- Comment #7 from Devang Patel <dpatel at apple.com>  2007-09-21 18:16:03 ---
Fixed.
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070917/053760.html


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Sat Sep 22 01:56:48 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 22 Sep 2007 01:56:48 -0500
Subject: [LLVMbugs] [Bug 1695] New: ScheduleDAGSimple:: isStrongDependency
 uses an uninitialized value
Message-ID: <bug-1695-206@http.llvm.org/bugs/>

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

           Summary: ScheduleDAGSimple::isStrongDependency uses an
                    uninitialized value
           Product: new-bugs
           Version: unspecified
          Platform: Other
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: baldrick at free.fr
                CC: llvmbugs at cs.uiuc.edu


Running test/CodeGen/Generic/2006-07-03-schedulers.ll under valgrind gives:

Conditional jump or move depends on uninitialised value(s)
   at 0x85E9018: (anonymous
namespace)::ScheduleDAGSimple::isStrongDependency((anonymous
namespace)::NodeInfo*, (anonymous namespace)::NodeInfo*)
(ScheduleDAGSimple.cpp:960)
   by 0x85E929D: (anonymous namespace)::ScheduleDAGSimple::ScheduleBackward()
(ScheduleDAGSimple.cpp:998)
   by 0x85EA80B: (anonymous namespace)::ScheduleDAGSimple::Schedule()
(ScheduleDAGSimple.cpp:1126)
   by 0x8675363: llvm::ScheduleDAG::Run() (ScheduleDAG.cpp:834)
   by 0x860B240:
llvm::SelectionDAGISel::ScheduleAndEmitDAG(llvm::SelectionDAG&)
(SelectionDAGISel.cpp:4870)
   by 0x8546DE5: (anonymous
namespace)::X86DAGToDAGISel::InstructionSelectBasicBlock(llvm::SelectionDAG&)
(X86ISelDAGToDAG.cpp:479)
   by 0x860B3CE: llvm::SelectionDAGISel::CodeGenAndEmitDAG(llvm::SelectionDAG&)
(SelectionDAGISel.cpp:4646)
   by 0x861F5D2: llvm::SelectionDAGISel::SelectBasicBlock(llvm::BasicBlock*,
llvm::MachineFunction&, llvm::FunctionLoweringInfo&)
(SelectionDAGISel.cpp:4664)
   by 0x8621211: llvm::SelectionDAGISel::runOnFunction(llvm::Function&)
(SelectionDAGISel.cpp:4365)
   by 0x84A02E0: (anonymous
namespace)::X86DAGToDAGISel::runOnFunction(llvm::Function&)
(X86ISelDAGToDAG.cpp:122)
   by 0x8822027: llvm::FPPassManager::runOnFunction(llvm::Function&)
(PassManager.cpp:1168)
   by 0x8822285: llvm::FunctionPassManagerImpl::run(llvm::Function&)
(PassManager.cpp:1126)

Conditional jump or move depends on uninitialised value(s)
   at 0x85E9018: (anonymous
namespace)::ScheduleDAGSimple::isStrongDependency((anonymous
namespace)::NodeInfo*, (anonymous namespace)::NodeInfo*)
(ScheduleDAGSimple.cpp:960)
   by 0x85E90C7: (anonymous namespace)::ScheduleDAGSimple::ScheduleForward()
(ScheduleDAGSimple.cpp:1055)
   by 0x85EA816: (anonymous namespace)::ScheduleDAGSimple::Schedule()
(ScheduleDAGSimple.cpp:1129)
   by 0x8675363: llvm::ScheduleDAG::Run() (ScheduleDAG.cpp:834)
   by 0x860B240:
llvm::SelectionDAGISel::ScheduleAndEmitDAG(llvm::SelectionDAG&)
(SelectionDAGISel.cpp:4870)
   by 0x8546DE5: (anonymous
namespace)::X86DAGToDAGISel::InstructionSelectBasicBlock(llvm::SelectionDAG&)
(X86ISelDAGToDAG.cpp:479)
   by 0x860B3CE: llvm::SelectionDAGISel::CodeGenAndEmitDAG(llvm::SelectionDAG&)
(SelectionDAGISel.cpp:4646)
   by 0x861F5D2: llvm::SelectionDAGISel::SelectBasicBlock(llvm::BasicBlock*,
llvm::MachineFunction&, llvm::FunctionLoweringInfo&)
(SelectionDAGISel.cpp:4664)
   by 0x8621211: llvm::SelectionDAGISel::runOnFunction(llvm::Function&)
(SelectionDAGISel.cpp:4365)
   by 0x84A02E0: (anonymous
namespace)::X86DAGToDAGISel::runOnFunction(llvm::Function&)
(X86ISelDAGToDAG.cpp:122)
   by 0x8822027: llvm::FPPassManager::runOnFunction(llvm::Function&)
(PassManager.cpp:1168)
   by 0x8822285: llvm::FunctionPassManagerImpl::run(llvm::Function&)
(PassManager.cpp:1126)

Reproduce using:
  llvm-upgrade 2006-07-03-schedulers.ll | llvm-as | valgrind --tool=memcheck
llc -pre-RA-sched=simple > /dev/null


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Sat Sep 22 02:02:42 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 22 Sep 2007 02:02:42 -0500
Subject: [LLVMbugs] [Bug 1695] ScheduleDAGSimple:: isStrongDependency uses
 an uninitialized value
In-Reply-To: <bug-1695-206@http.llvm.org/bugs/>
Message-ID: <200709220702.l8M72gYs010749@zion.cs.uiuc.edu>

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


Chris Lattner <sabre at nondot.org> changed:

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




--- Comment #1 from Chris Lattner <sabre at nondot.org>  2007-09-22 02:02:41 ---
I believe this should fix it, plz verify:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070917/053772.html

Thanks for filing these!


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Sat Sep 22 08:56:43 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 22 Sep 2007 08:56:43 -0500
Subject: [LLVMbugs] [Bug 1696] New: llvm's configure ignores
	--program-transform-name=
Message-ID: <bug-1696-206@http.llvm.org/bugs/>

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

           Summary: llvm's configure ignores --program-transform-name=
           Product: Build scripts
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: autoconf
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: rep.dot.nop at gmail.com
                CC: llvmbugs at cs.uiuc.edu


../../llvm-2.1/configure \
                --prefix=/usr \
                --build=i386-pc-linux-gnu \
                --host=i386-pc-linux-gnu \
                --target=i386-linux-uclibc \
                --program-transform-name=i386-linux-uclibc- \

make DESTDIR="$(MYOFFSET)" install

creates
$ ls ll*
llc       llvm-ar          llvmc        llvm-dis      llvm-link  llvm-ranlib
lli       llvm-as          llvm-config  llvm-extract  llvm-nm    llvm-stub
llvm2cpp  llvm-bcanalyzer  llvm-db      llvm-ld       llvm-prof  llvm-upgrade

instead of the expected i386-linux-uclibc-* files:
$ ls *uclibc*ll*
ls: *uclibc*ll*: No such file or directory


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Sat Sep 22 15:17:42 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 22 Sep 2007 15:17:42 -0500
Subject: [LLVMbugs] [Bug 1679] GEP is unsigned
In-Reply-To: <bug-1679-206@http.llvm.org/bugs/>
Message-ID: <200709222017.l8MKHgE4017609@zion.cs.uiuc.edu>

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


Chris Lattner <sabre at nondot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
           Keywords|                            |miscompilation
         Resolution|                            |FIXED
   Target Milestone|---                         |2.2




--- Comment #2 from Chris Lattner <sabre at nondot.org>  2007-09-22 15:17:41 ---
Fixed, patch here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070917/053786.html

Thanks!

-Chris


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Sun Sep 23 02:35:43 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 23 Sep 2007 02:35:43 -0500
Subject: [LLVMbugs] [Bug 1684] llc reads freed memory when run on
 2006-11-30-NoCompileUnit.cpp
In-Reply-To: <bug-1684-206@http.llvm.org/bugs/>
Message-ID: <200709230735.l8N7ZhvW003316@zion.cs.uiuc.edu>

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


Duncan Sands <baldrick at free.fr> changed:

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




--- Comment #9 from Duncan Sands <baldrick at free.fr>  2007-09-23 02:35:42 ---
I can confirm that this bug is now fixed.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Sun Sep 23 10:17:09 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 23 Sep 2007 10:17:09 -0500
Subject: [LLVMbugs] [Bug 1681] llc aborts with " Register class of operand
 and regclass of use don't agree!"
In-Reply-To: <bug-1681-206@http.llvm.org/bugs/>
Message-ID: <200709231517.l8NFH92e008274@zion.cs.uiuc.edu>

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


Dale Johannesen <dalej at apple.com> changed:

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




--- Comment #7 from Dale Johannesen <dalej at apple.com>  2007-09-23 10:17:08 ---
Fixed here as described above:
http://llvm.org/viewvc/llvm-project?view=rev&revision=42246
This mode probably isn't used much (it was broken on 7/2 and nobody reported it
until 9/18).  There are no testsuite problems, but it's a big patch, as you
see.  jlh, could you exercise it on whatever code you care about?


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Sun Sep 23 19:55:51 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 23 Sep 2007 19:55:51 -0500
Subject: [LLVMbugs] [Bug 1697] New: llc aborts with: Assertion `StackTop > 0
 && " Stack cannot be empty!"'
Message-ID: <bug-1697-206@http.llvm.org/bugs/>

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

           Summary: llc aborts with: Assertion `StackTop > 0 && "Stack
                    cannot be empty!"'
           Product: new-bugs
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Keywords: compile-fail
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: jlh at gmx.ch
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=1137)
 --> (http://llvm.org/bugs/attachment.cgi?id=1137)
.bc file triggering the error

CPU: AMD Athlon Thoroughbred
Software: linux-2.6/gentoo, LLVM SVN-r42247

When running "llc file.bc" (file is attached), I get the following output:

llc: X86FloatingPoint.cpp:670:
void<unnamed>::FPS::handleOneArgFPRW(llvm::ilist_iterator<llvm::MachineInstr>&):
Assertion `StackTop > 0 && "Stack cannot be empty!"' failed.
llc((anonymous namespace)::PrintStackTrace()+0x19)[0x84ffbf9]
Aborted

Attached is a reduced test case, which originally was the linking step of
building POV-Ray 3.6.1 with LLVM (with link-time optimization enabled).  For
your convenience, here's the human readable form:

target datalayout =
"e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64-s0:0:64-f80:32:32"
target triple = "i686-pc-linux-gnu"

define void @myfunc1(double %double) {
        ret void
}

define void @myfunc2(double* %ptr1, float* %ptr2, float* %ptr3) {
        %double_1 = load double* %ptr1
        %float_2 = load float* %ptr2
        %float_3 = load float* %ptr3
        %cond = fcmp olt float %float_2, 0.0 
        %float_4 = select i1 %cond, float 0.0, float %float_2
        %double_5 = fpext float %float_4 to double
        %double = mul double %double_1, %double_5
        call void @myfunc1(double %double)
        ret void
}


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Mon Sep 24 06:31:41 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 24 Sep 2007 06:31:41 -0500
Subject: [LLVMbugs] [Bug 1657] licm promotes store to null pointer
In-Reply-To: <bug-1657-206@http.llvm.org/bugs/>
Message-ID: <200709241131.l8OBVfg2017557@zion.cs.uiuc.edu>

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


Jay Foad <jay.foad at antixlabs.com> changed:

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




--- Comment #11 from Jay Foad <jay.foad at antixlabs.com>  2007-09-24 06:31:39 ---
Reopened on the assumption that this new test case is another example of the
same bug.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Mon Sep 24 14:08:51 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 24 Sep 2007 14:08:51 -0500
Subject: [LLVMbugs] [Bug 1698] New: Constant cast of double to short gives
	wrong result
Message-ID: <bug-1698-206@http.llvm.org/bugs/>

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

           Summary: Constant cast of double to short gives wrong result
           Product: new-bugs
           Version: unspecified
          Platform: Other
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: baldrick at free.fr
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=1139)
 --> (http://llvm.org/bugs/attachment.cgi?id=1139)
C testcase

Casting 0x405FBFFFFFFFE483 to i16 results in 127 rather than 126, as
shown by doing the following with the attached testcase tc.c:

llvm-gcc -S -emit-llvm tc.c -o - | llvm-as | opt -std-compile-opts | llvm-dis

define i32 @main() {
entry:
        tail call void @abort( )
        unreachable
}

This should return 0, which is what happens if you compile with
mainline gcc.  It is also what happens with llvm-gcc if you
compile without optimization.

Reduced from a recently introduced Ada testsuite failure.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Mon Sep 24 14:41:18 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 24 Sep 2007 14:41:18 -0500
Subject: [LLVMbugs] [Bug 1699] New: multiple definition of `testandset' with
 llvm-gcc-4.2
Message-ID: <bug-1699-206@http.llvm.org/bugs/>

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

           Summary: multiple definition of `testandset' with llvm-gcc-4.2
           Product: tools
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: llvm-gcc
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: rep.dot.nop at gmail.com
                CC: llvmbugs at cs.uiuc.edu


I'm using llvm-gcc-4.2/trunk to (attempt to) build a cross-compiler for i386.

For the initial compiler, i configure llvm-gcc-4.2 *without* specifying
--enable-llvm. binutils-2.18 (and also HJL's .50.) is used.

Building a library (uClibc in this case) results in:

/home/me/obj.ia32/buildroot.mine/build_i386/staging_dir/usr/bin/i386-linux-ucli
bc-ld  -shared --warn-common --warn-once -z combreloc -z relro -z now -z defs
-s
  -init __uClibc_init -soname=libc.so.0 -o lib/libuClibc-0.9.29.so 
--whole-arch
ive libc/libc_so.a --no-whole-archive ./lib/interp.os ./lib/ld-uClibc.so.0
./lib
/uclibc_nonshared.a /home/me/obj.ia32/buildroot.mine/build_i386/staging_dir/usr
/lib/gcc/i386-linux-uclibc/4.2.1/libgcc.a 
libc/libc_so.a(sigaction.os): In function `testandset':
sigaction.c:(.text+0xf): multiple definition of `testandset'
libc/libc_so.a(brk.os):brk.c:(.text+0x0): first defined here
libc/libc_so.a(sigaction.os): In function `__compare_and_swap':
sigaction.c:(.text+0x1e): multiple definition of `__compare_and_swap'
libc/libc_so.a(brk.os):brk.c:(.text+0xf): first defined here
libc/libc_so.a(sigaction.os): In function `get_eflags':
sigaction.c:(.text+0x39): multiple definition of `get_eflags'
libc/libc_so.a(brk.os):brk.c:(.text+0x2a): first defined here
libc/libc_so.a(sigaction.os): In function `set_eflags':
sigaction.c:(.text+0x40): multiple definition of `set_eflags'
libc/libc_so.a(brk.os):brk.c:(.text+0x31): first defined here
libc/libc_so.a(sigaction.os): In function `compare_and_swap_is_available':
sigaction.c:(.text+0x137): multiple definition of
`compare_and_swap_is_available
'

Using gcc-4.2.1 (i.e. not the llvm-gcc) works flawlessly.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Mon Sep 24 15:05:21 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 24 Sep 2007 15:05:21 -0500
Subject: [LLVMbugs] [Bug 1657] licm promotes store to null pointer
In-Reply-To: <bug-1657-206@http.llvm.org/bugs/>
Message-ID: <200709242005.l8OK5Ld2030358@zion.cs.uiuc.edu>

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


Devang Patel <dpatel at apple.com> changed:

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




--- Comment #12 from Devang Patel <dpatel at apple.com>  2007-09-24 15:05:20 ---
Test case is invalid because
  store i8 undef, i8* null


Anyway, fixed.
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070924/053828.html

Please file new bugzilla if you run into another regression with same symptoms 
- "promoting store to null pointer". Thanks.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Mon Sep 24 16:07:06 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 24 Sep 2007 16:07:06 -0500
Subject: [LLVMbugs] [Bug 1698] Constant cast of double to short gives wrong
	result
In-Reply-To: <bug-1698-206@http.llvm.org/bugs/>
Message-ID: <200709242107.l8OL76Qf032256@zion.cs.uiuc.edu>

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


Dale Johannesen <dalej at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dalej at apple.com
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED




--- Comment #1 from Dale Johannesen <dalej at apple.com>  2007-09-24 16:07:06 ---
Fixed.  Sorry about that.
http://llvm.org/viewvc/llvm-project?view=rev&revision=42273


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Mon Sep 24 17:53:21 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 24 Sep 2007 17:53:21 -0500
Subject: [LLVMbugs] [Bug 1697] llc aborts with: Assertion `StackTop > 0 && "
 Stack cannot be empty!"'
In-Reply-To: <bug-1697-206@http.llvm.org/bugs/>
Message-ID: <200709242253.l8OMrLhQ002494@zion.cs.uiuc.edu>

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


Dale Johannesen <dalej at apple.com> changed:

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




--- Comment #2 from Dale Johannesen <dalej at apple.com>  2007-09-24 17:53:21 ---
Fixed here.
http://llvm.org/viewvc/llvm-project?view=rev&revision=42281


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Tue Sep 25 10:53:11 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 25 Sep 2007 10:53:11 -0500
Subject: [LLVMbugs] [Bug 1700] New: Assertion `category == fcNormal ||
 category == fcNaN' failed
Message-ID: <bug-1700-206@http.llvm.org/bugs/>

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

           Summary: Assertion `category == fcNormal || category == fcNaN'
                    failed
           Product: new-bugs
           Version: unspecified
          Platform: Other
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: baldrick at free.fr
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=1140)
 --> (http://llvm.org/bugs/attachment.cgi?id=1140)
testcase .ll

Running opt on the attached testcase causes this assertion failure:

$ opt -std-compile-opts c460008.bc --disable-output
opt: lib/Support/APFloat.cpp:360: llvm::integerPart*
llvm::APFloat::significandParts(): Assertion `category == fcNormal || category
== fcNaN' failed.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Tue Sep 25 11:12:32 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 25 Sep 2007 11:12:32 -0500
Subject: [LLVMbugs] [Bug 1701] New: lli vs JIT diffs on FCmp::ne with NaN
	operands
Message-ID: <bug-1701-206@http.llvm.org/bugs/>

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

           Summary: lli vs JIT diffs on FCmp::ne with NaN operands
           Product: new-bugs
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: dgu at stanford.edu
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=1141)
 --> (http://llvm.org/bugs/attachment.cgi?id=1141)
LL asm demonstrating the bug on ordered fcmp with doubles != operator

I am using the LLVM 2.0 release.

I am having a little trouble with the fcmp one instruction on doubles only.

For ordered comparisons, the LLVM manual states that true should be returned
iff neither operands is QNAN.  ( http://llvm.org/docs/LangRef.html#i_fcmp)

If I do fcmp one which includes one or both operands as a NaN, the result is
expected to be 0 then.

If I run the bitcode with lli (JIT off), no problem.  If I use the JIT (lli
--force-interpreted=true), then it returns 1.

(Converely, fcmp une with the JIT returns 0 instead of the expected 1 ...
without JIT it returns the expected 0).

The other operators (oeq, oge, ..., ueq, uge, ...) seem to work fine.


Is this a bug with the JIT or have I done to muck this up?  I've included
source below which illustrates the problem (with doubles on fcmp one only ...
).

Thanks for your help.

~ David


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Tue Sep 25 11:34:52 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 25 Sep 2007 11:34:52 -0500
Subject: [LLVMbugs] [Bug 1701] lli vs JIT diffs on FCmp::ne with NaN operands
In-Reply-To: <bug-1701-206@http.llvm.org/bugs/>
Message-ID: <200709251634.l8PGYqru016935@zion.cs.uiuc.edu>

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


Chris Lattner <sabre at nondot.org> changed:

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




--- Comment #1 from Chris Lattner <sabre at nondot.org>  2007-09-25 11:34:21 ---
This appears to work on both x86 and ppc with SVN head.  Please try out the 2.1
prerelease tarballs, it should be fixed there.

Thanks for reporting the bug!

-Chris


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Tue Sep 25 12:27:25 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 25 Sep 2007 12:27:25 -0500
Subject: [LLVMbugs] [Bug 1700] Assertion `category == fcNormal || category
 == fcNaN' failed
In-Reply-To: <bug-1700-206@http.llvm.org/bugs/>
Message-ID: <200709251727.l8PHRP7b019294@zion.cs.uiuc.edu>

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


Dale Johannesen <dalej at apple.com> changed:

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




--- Comment #1 from Dale Johannesen <dalej at apple.com>  2007-09-25 12:27:19 ---
Yeah, Chris spotted this a couple days back and it was next in my queue.  Fixed
now.
http://llvm.org/viewvc/llvm-project?view=rev&revision=42298


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Tue Sep 25 13:25:37 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 25 Sep 2007 13:25:37 -0500
Subject: [LLVMbugs] [Bug 714] [loopopt] Need index set analysis/splitting
In-Reply-To: <bug-714-206@http.llvm.org/bugs/>
Message-ID: <200709251825.l8PIPbrK021904@zion.cs.uiuc.edu>

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


Devang Patel <dpatel at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dpatel at apple.com
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED




--- Comment #1 from Devang Patel <dpatel at apple.com>  2007-09-25 13:25:35 ---
Fixed.
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070924/053864.html


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Tue Sep 25 22:33:41 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 25 Sep 2007 22:33:41 -0500
Subject: [LLVMbugs] [Bug 1702] New: HANDLE_PRAGMA_PACK_PUSH_POP in
	gcc/config/freebsd.h
Message-ID: <bug-1702-206@http.llvm.org/bugs/>

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

           Summary: HANDLE_PRAGMA_PACK_PUSH_POP in gcc/config/freebsd.h
           Product: new-bugs
           Version: unspecified
          Platform: PC
        OS/Version: FreeBSD
            Status: NEW
          Severity: minor
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: emil at cs.rmit.edu.au
                CC: llvmbugs at cs.uiuc.edu


This error in llvm 2.1 "make check":

FAIL: /home/emil/ll/llvm-2.1/test/CFrontend/2007-09-12-PragmaPack.c
Failed with exit(1) at line 1
while running: /home/emil/ll/prefix/bin/llvm-gcc -emit-llvm -O3 -S -o -
/home/emil/ll/llvm-2.1/test/CFrontend/2007-09-12-PragmaPack.c | grep {26}
/home/emil/ll/llvm-2.1/test/CFrontend/2007-09-12-PragmaPack.c:5: warning:
#pragma pack(push[, id], <n>) is not supported on this target
/home/emil/ll/llvm-2.1/test/CFrontend/2007-09-12-PragmaPack.c:26: warning:
#pragma pack(pop[, id], <n>) is not supported on this target

Is fixed by the following patch to llvm-gcc4:
--- llvm-gcc4.0-2.1.source/gcc/config/freebsd.h.orig    2007-09-26
12:38:58.804518521 +1000
+++ llvm-gcc4.0-2.1.source/gcc/config/freebsd.h 2007-09-26 12:39:39.290051224
+1000
@@ -85,3 +85,5 @@
    This enables the test coverage code to use file locking when exiting a
    program, which avoids race conditions if the program has forked.  */
 #define TARGET_HAS_F_SETLKW
+
+#define HANDLE_PRAGMA_PACK_PUSH_POP                                            

The added line is apparently not present in gcc mainline, but is a local change
in the GCC sources in the FreeBSD base system:
http://www.freebsd.org/cgi/cvsweb.cgi/src/contrib/gcc/config/freebsd.h#rev1.40

Big thanks to Anton Korobeynikov for chasing this down!


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Wed Sep 26 00:49:58 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 26 Sep 2007 00:49:58 -0500
Subject: [LLVMbugs] [Bug 1180] Linker is slower than it needs to be when
	linking 1 file
In-Reply-To: <bug-1180-206@http.llvm.org/bugs/>
Message-ID: <200709260549.l8Q5nw5i015356@zion.cs.uiuc.edu>

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


Chris Lattner <sabre at nondot.org> changed:

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




--- Comment #1 from Chris Lattner <sabre at nondot.org>  2007-09-26 00:49:58 ---
I'm not sure what the problem is here, but it doesn't seem very important.  If
you disagree, please reopen and give an example, thanks!


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Wed Sep 26 00:52:15 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 26 Sep 2007 00:52:15 -0500
Subject: [LLVMbugs] [Bug 1416] cbe miscompiles SPASS
In-Reply-To: <bug-1416-206@http.llvm.org/bugs/>
Message-ID: <200709260552.l8Q5qFZX015590@zion.cs.uiuc.edu>

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


Chris Lattner <sabre at nondot.org> changed:

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




--- Comment #11 from Chris Lattner <sabre at nondot.org>  2007-09-26 00:52:15 ---
This was fixed, even for 2.1 :)


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Wed Sep 26 00:56:37 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 26 Sep 2007 00:56:37 -0500
Subject: [LLVMbugs] [Bug 1619] llvm-gcc 4.0 compilation failure on Fedora
	Core 4
In-Reply-To: <bug-1619-206@http.llvm.org/bugs/>
Message-ID: <200709260556.l8Q5ubwQ016103@zion.cs.uiuc.edu>

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


Chris Lattner <sabre at nondot.org> changed:

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




--- Comment #15 from Chris Lattner <sabre at nondot.org>  2007-09-26 00:56:36 ---
This seems to work.  Ryan if you are still having problems, please reopen with
requested details.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Wed Sep 26 01:14:03 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 26 Sep 2007 01:14:03 -0500
Subject: [LLVMbugs] [Bug 769] Subregister support
In-Reply-To: <bug-769-206@http.llvm.org/bugs/>
Message-ID: <200709260614.l8Q6E35s018036@zion.cs.uiuc.edu>

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


Chris Lattner <sabre at nondot.org> changed:

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




--- Comment #2 from Chris Lattner <sabre at nondot.org>  2007-09-26 01:14:02 ---


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


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Wed Sep 26 01:16:00 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 26 Sep 2007 01:16:00 -0500
Subject: [LLVMbugs] [Bug 1264] converting 64-bit constant pool entry to
 32-bit not necessarily beneficial
In-Reply-To: <bug-1264-206@http.llvm.org/bugs/>
Message-ID: <200709260616.l8Q6G0Zw018262@zion.cs.uiuc.edu>

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


Chris Lattner <sabre at nondot.org> changed:

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




--- Comment #4 from Chris Lattner <sabre at nondot.org>  2007-09-26 01:16:00 ---
I moved this to X86/README-SSE.txt


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Wed Sep 26 01:16:52 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 26 Sep 2007 01:16:52 -0500
Subject: [LLVMbugs] [Bug 1290] linklint reports many problems with llvm.org
In-Reply-To: <bug-1290-206@http.llvm.org/bugs/>
Message-ID: <200709260616.l8Q6GqHG018375@zion.cs.uiuc.edu>

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


Chris Lattner <sabre at nondot.org> changed:

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




--- Comment #5 from Chris Lattner <sabre at nondot.org>  2007-09-26 01:16:51 ---
This has insufficient info (no patches) :)


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Wed Sep 26 01:19:35 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 26 Sep 2007 01:19:35 -0500
Subject: [LLVMbugs] [Bug 1123] Convert DejaGNU Tests To Use Tcl Fully
In-Reply-To: <bug-1123-206@http.llvm.org/bugs/>
Message-ID: <200709260619.l8Q6JZIe018682@zion.cs.uiuc.edu>

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


Chris Lattner <sabre at nondot.org> changed:

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




--- Comment #4 from Chris Lattner <sabre at nondot.org>  2007-09-26 01:19:34 ---
We can reevaluate this later, but it doesn't seem like a good tradeoff at this
point.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Wed Sep 26 01:21:49 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 26 Sep 2007 01:21:49 -0500
Subject: [LLVMbugs] [Bug 1034] SCCP and vector types
In-Reply-To: <bug-1034-206@http.llvm.org/bugs/>
Message-ID: <200709260621.l8Q6Lnl3018980@zion.cs.uiuc.edu>

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


Chris Lattner <sabre at nondot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED
            Summary|SCCP and Packed Types       |SCCP and vector types




--- Comment #3 from Chris Lattner <sabre at nondot.org>  2007-09-26 01:21:49 ---
SCCP no longer miscompiles vector stuff, though it could still be improved of
course.  Closing this.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Wed Sep 26 01:23:01 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 26 Sep 2007 01:23:01 -0500
Subject: [LLVMbugs] [Bug 1104] Bad struct argument "packing/conversion" in
	llvm-gcc4
In-Reply-To: <bug-1104-206@http.llvm.org/bugs/>
Message-ID: <200709260623.l8Q6N1KI019104@zion.cs.uiuc.edu>

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


Chris Lattner <sabre at nondot.org> changed:

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




--- Comment #8 from Chris Lattner <sabre at nondot.org>  2007-09-26 01:23:00 ---


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


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Wed Sep 26 01:24:17 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 26 Sep 2007 01:24:17 -0500
Subject: [LLVMbugs] [Bug 986] Suboptimal code is generated for integer
 division in some cases.
In-Reply-To: <bug-986-206@http.llvm.org/bugs/>
Message-ID: <200709260624.l8Q6OHAb019250@zion.cs.uiuc.edu>

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


Chris Lattner <sabre at nondot.org> changed:

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




--- Comment #5 from Chris Lattner <sabre at nondot.org>  2007-09-26 01:24:16 ---
Anton, can you please verify whether this bug still makes sense?  If so, please
move it to the X86 readme.txt file.  Thanks!


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Wed Sep 26 01:31:46 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 26 Sep 2007 01:31:46 -0500
Subject: [LLVMbugs] [Bug 1160] x86 backend misses read-modify-write
	opportunity
In-Reply-To: <bug-1160-206@http.llvm.org/bugs/>
Message-ID: <200709260631.l8Q6Vk7S019931@zion.cs.uiuc.edu>

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


Chris Lattner <sabre at nondot.org> changed:

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




--- Comment #9 from Chris Lattner <sabre at nondot.org>  2007-09-26 01:31:45 ---
Some progress on this bug.  With -static, we now produce pretty nice code for
the first loop, but we still don't get the RMW thing correct:

LBB1_1: # bb
        movl    _huge(,%eax,4), %ecx
        orl     _target(,%eax,4), %ecx
        movl    %ecx, _target(,%eax,4)
        incl    %eax
        cmpl    $2048, %eax
        jne     LBB1_1  # bb

I entered the reduced testcase into the README.txt file here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070924/053908.html

In the second loop, we are now producing nice simple code with no branches in
it:

 LBB1_3: # bb18
        addl    _target(,%ecx,4), %eax
        incl    %ecx
        cmpl    $2048, %ecx
        jne     LBB1_3  # bb18

Thus this bug is subsumed by the readme entry.  Closing.

-Chris


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Wed Sep 26 01:33:44 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 26 Sep 2007 01:33:44 -0500
Subject: [LLVMbugs] [Bug 1230] llvm-gcc should not lower calling convs in
	front-end
In-Reply-To: <bug-1230-206@http.llvm.org/bugs/>
Message-ID: <200709260633.l8Q6XiwB020127@zion.cs.uiuc.edu>

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


Chris Lattner <sabre at nondot.org> changed:

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




--- Comment #2 from Chris Lattner <sabre at nondot.org>  2007-09-26 01:33:43 ---


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


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Wed Sep 26 01:34:32 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 26 Sep 2007 01:34:32 -0500
Subject: [LLVMbugs] [Bug 731] Enhanced Makefile System To Use SCONS
In-Reply-To: <bug-731-206@http.llvm.org/bugs/>
Message-ID: <200709260634.l8Q6YWma020246@zion.cs.uiuc.edu>

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


Chris Lattner <sabre at nondot.org> changed:

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




--- Comment #9 from Chris Lattner <sabre at nondot.org>  2007-09-26 01:34:32 ---
This is certainly still interesting, but needs to be reevaluated in the context
of llvm-top.  When we get back to this we should also see if there are other
options interesting.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Wed Sep 26 01:35:32 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 26 Sep 2007 01:35:32 -0500
Subject: [LLVMbugs] [Bug 688] bugpoint should fork processes with sane limits
In-Reply-To: <bug-688-206@http.llvm.org/bugs/>
Message-ID: <200709260635.l8Q6ZWGj020361@zion.cs.uiuc.edu>

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


Chris Lattner <sabre at nondot.org> changed:

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




--- Comment #10 from Chris Lattner <sabre at nondot.org>  2007-09-26 01:35:32 ---
anton implemented this.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Wed Sep 26 01:36:25 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 26 Sep 2007 01:36:25 -0500
Subject: [LLVMbugs] [Bug 498] [llvm-gcc] [meta] Make llvm-gcc4 completely
 replace llvm-gcc3
In-Reply-To: <bug-498-206@http.llvm.org/bugs/>
Message-ID: <200709260636.l8Q6aPXL020437@zion.cs.uiuc.edu>

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


Chris Lattner <sabre at nondot.org> changed:

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




--- Comment #3 from Chris Lattner <sabre at nondot.org>  2007-09-26 01:36:25 ---
llvm-gcc3 is dead


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Wed Sep 26 01:51:15 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 26 Sep 2007 01:51:15 -0500
Subject: [LLVMbugs] [Bug 1703] New: Teach the coalescing how to remove
 subreg instructions
Message-ID: <bug-1703-206@http.llvm.org/bugs/>

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

           Summary: Teach the coalescing how to remove subreg instructions
           Product: new-bugs
           Version: unspecified
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: christopher.lamb at gmail.com
                CC: llvmbugs at cs.uiuc.edu





-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Wed Sep 26 01:52:00 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 26 Sep 2007 01:52:00 -0500
Subject: [LLVMbugs] [Bug 1704] New: Add tablegen syntax support for
 selecting to subreg nodes in .td files
Message-ID: <bug-1704-206@http.llvm.org/bugs/>

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

           Summary: Add tablegen syntax support for selecting to subreg
                    nodes in .td files
           Product: new-bugs
           Version: unspecified
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: christopher.lamb at gmail.com
                CC: llvmbugs at cs.uiuc.edu





-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Wed Sep 26 01:52:51 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 26 Sep 2007 01:52:51 -0500
Subject: [LLVMbugs] [Bug 1350] Vreg subregs support
In-Reply-To: <bug-1350-206@http.llvm.org/bugs/>
Message-ID: <200709260652.l8Q6qp9Y021826@zion.cs.uiuc.edu>

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


Christopher Lamb <christopher.lamb at gmail.com> changed:

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




-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Wed Sep 26 02:40:44 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 26 Sep 2007 02:40:44 -0500
Subject: [LLVMbugs] [Bug 1702] HANDLE_PRAGMA_PACK_PUSH_POP in
	gcc/config/freebsd.h
In-Reply-To: <bug-1702-206@http.llvm.org/bugs/>
Message-ID: <200709260740.l8Q7ei7q030161@zion.cs.uiuc.edu>

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


Anton Korobeynikov <asl at math.spbu.ru> changed:

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




--- Comment #3 from Anton Korobeynikov <asl at math.spbu.ru>  2007-09-26 02:40:44 ---
Applied:

http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070924/053912.html
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070924/053913.html


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Wed Sep 26 02:49:22 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 26 Sep 2007 02:49:22 -0500
Subject: [LLVMbugs] [Bug 1705] New: lower-packed pass fails assertion on
	bitcast
Message-ID: <bug-1705-206@http.llvm.org/bugs/>

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

           Summary: lower-packed pass fails assertion on bitcast
           Product: libraries
           Version: 2.0
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: Scalar Optimizations
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: jay.foad at antixlabs.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=1142)
 --> (http://llvm.org/bugs/attachment.cgi?id=1142)
bitcode for test case

I'm using LLVM 2.0 on Linux/x86. With the attached bitcode file, I get:

foad at debian:~$ ~/svn/antix/agp/trunk/toolchain/install/bin/opt -f -o opt.o
20050316-1.bc -lower-packed
Unhandled Instruction with Packed ReturnType:   %tmp3 = bitcast i64 %tmp12 to
<2 x i32>         ; <<2 x i32>> [#uses=1]

opt:
/home/foad/svn/antix/agp/trunk/toolchain/llvm/llvm/lib/Transforms/Scalar/LowerPacked.cpp:207:
std::vector<llvm::Value*, std::allocator<llvm::Value*>
>&<unnamed>::LowerPacked::getValues(llvm::Value*): Assertion `false &&
"Unhandled VectorType value"' failed.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Wed Sep 26 05:00:32 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 26 Sep 2007 05:00:32 -0500
Subject: [LLVMbugs] [Bug 1706] New: Assertion failure: Linear scev
 computation is off in a bad way!
Message-ID: <bug-1706-206@http.llvm.org/bugs/>

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

           Summary: Assertion failure: Linear scev computation is off in a
                    bad way!
           Product: libraries
           Version: 2.0
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Interprocedural Analyses
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: richard.smith at antixlabs.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=1143)
 --> (http://llvm.org/bugs/attachment.cgi?id=1143)
Testcase

Using the attached,

llvm-gcc bug.c -o bug -O3

gives

cc1:
/home/ros/svn/agp/trunk/toolchain/llvm/llvm/lib/Analysis/ScalarEvolution.cpp:2401:
llvm::SCEVHandle
llvm::SCEVAddRecExpr::getNumIterationsInRange(llvm::ConstantRange, bool) const:
Assertion `Range.contains( EvaluateConstantChrecAtConstant(this,
ConstantInt::get(ExitVal - One))->getValue()) && "Linear scev computation is
off in a bad way!"' failed.
74.c: At top level:
74.c:16: internal compiler error: Aborted
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://llvm.org/bugs> for instructions.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Wed Sep 26 07:16:40 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 26 Sep 2007 07:16:40 -0500
Subject: [LLVMbugs] [Bug 1707] New: 80 bit floats + eh -> Cannot yet select:
 0x8a0ddd8: f80 = TargetConstantFP <0>
Message-ID: <bug-1707-206@http.llvm.org/bugs/>

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

           Summary: 80 bit floats + eh -> Cannot yet select: 0x8a0ddd8: f80
                    = TargetConstantFP <0>
           Product: new-bugs
           Version: unspecified
          Platform: Other
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: baldrick at free.fr
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=1144)
 --> (http://llvm.org/bugs/attachment.cgi?id=1144)
testcase .ll

$ llc -f tc.bc -enable-correct-eh-support
Cannot yet select: 0x8a0ddd8: f80 = TargetConstantFP <0>
llc[0x889ff2e]
llc[0x88a01f4]
[0xffffe420]
/lib/tls/i686/cmov/libc.so.6(abort+0x101)[0xb7d10201]
llc[0x84cd0bc]
llc[0x854f45d]
llc[0x8552ff0]
llc[0x855356d]
llc[0x8553e12]
llc(llvm::SelectionDAGISel::CodeGenAndEmitDAG(llvm::SelectionDAG&)+0x133)[0x861de07]
llc(llvm::SelectionDAGISel::SelectBasicBlock(llvm::BasicBlock*,
llvm::MachineFunction&, llvm::FunctionLoweringInfo&)+0xb5)[0x863200b]
llc(llvm::SelectionDAGISel::runOnFunction(llvm::Function&)+0x1e4)[0x8633c4a]
llc[0x84a1ec1]
llc(llvm::FPPassManager::runOnFunction(llvm::Function&)+0x11a)[0x8834c44]
llc(llvm::FunctionPassManagerImpl::run(llvm::Function&)+0x6e)[0x8834ea2]
llc(llvm::FunctionPassManager::run(llvm::Function&)+0x88)[0x8834ff8]
llc(main+0x959)[0x835474b]
/lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe0)[0xb7cfa050]
llc(realloc+0x8d)[0x8352c71]
Aborted (core dumped)


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Wed Sep 26 10:01:59 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 26 Sep 2007 10:01:59 -0500
Subject: [LLVMbugs] [Bug 1708] New: assertion failure with complex short
	data type
Message-ID: <bug-1708-206@http.llvm.org/bugs/>

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

           Summary: assertion failure with complex short data type
           Product: new-bugs
           Version: unspecified
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: richard.smith at antixlabs.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=1145)
 --> (http://llvm.org/bugs/attachment.cgi?id=1145)
test canse

The attached code shows an assertion failure with complex short data types:

$ llvm-gcc bug.c --emit-llvm
...
cc1:
/home/ros/svn/agp/trunk/toolchain/llvm/llvm/lib/VMCore/Instructions.cpp:2218:
llvm::CmpInst::CmpInst(llvm::Instruction::OtherOps, short unsigned int,
llvm::Value*, llvm::Value*, const std::string&, llvm::BasicBlock*): Assertion
`Op0Ty->isFloatingPoint() && "Invalid operand types for FCmp instruction"'
failed.
bug.c:6: internal compiler error: Aborted
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://llvm.org/bugs> for instructions.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Wed Sep 26 12:28:21 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 26 Sep 2007 12:28:21 -0500
Subject: [LLVMbugs] [Bug 1707] 80 bit floats + eh -> Cannot yet select:
 0x8a0ddd8: f80 = TargetConstantFP <0>
In-Reply-To: <bug-1707-206@http.llvm.org/bugs/>
Message-ID: <200709261728.l8QHSLpv017378@zion.cs.uiuc.edu>

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


Dale Johannesen <dalej at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dalej at apple.com
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED




--- Comment #1 from Dale Johannesen <dalej at apple.com>  2007-09-26 12:28:21 ---
Fixed.
http://llvm.org/viewvc/llvm-project?view=rev&revision=42359


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Wed Sep 26 14:20:51 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 26 Sep 2007 14:20:51 -0500
Subject: [LLVMbugs] [Bug 1709] New: long double 0.5 prints as 0.500001
Message-ID: <bug-1709-206@http.llvm.org/bugs/>

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

           Summary: long double 0.5 prints as 0.500001
           Product: new-bugs
           Version: unspecified
          Platform: Other
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: baldrick at free.fr
                CC: llvmbugs at cs.uiuc.edu


This program compiled with llvm-gcc-4.2 outputs 0.500001, while with
gcc it outputs 0.5.

#include <stdio.h>
int main(void) {
  long double x = 0.5L;
  printf("%Lg\n", x);
  return 0;
}


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Thu Sep 27 09:13:43 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 27 Sep 2007 09:13:43 -0500
Subject: [LLVMbugs] [Bug 1706] Assertion failure: Linear scev computation is
 off in a bad way!
In-Reply-To: <bug-1706-206@http.llvm.org/bugs/>
Message-ID: <200709271413.l8REDhHg006254@zion.cs.uiuc.edu>

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


Nick Lewycky <nicholas at mxc.ca> changed:

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




--- Comment #2 from Nick Lewycky <nicholas at mxc.ca>  2007-09-27 09:13:42 ---
Fixed. Thanks Jay!

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


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Thu Sep 27 09:37:38 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 27 Sep 2007 09:37:38 -0500
Subject: [LLVMbugs] [Bug 1709] long double 0.5 prints as 0.500001
In-Reply-To: <bug-1709-206@http.llvm.org/bugs/>
Message-ID: <200709271437.l8REbcEx006986@zion.cs.uiuc.edu>

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


Duncan Sands <baldrick at free.fr> changed:

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




--- Comment #3 from Duncan Sands <baldrick at free.fr>  2007-09-27 09:37:38 ---
Yes, that fixed it - thanks a lot!


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Thu Sep 27 10:37:20 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 27 Sep 2007 10:37:20 -0500
Subject: [LLVMbugs] [Bug 1710] New: No debug info for optimised code
Message-ID: <bug-1710-206@http.llvm.org/bugs/>

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

           Summary: No debug info for optimised code
           Product: new-bugs
           Version: unspecified
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: richard.smith at antixlabs.com
                CC: llvmbugs at cs.uiuc.edu


>From http://www.llvm.org/docs/SourceLevelDebugging.html:

"An extremely high priority of LLVM debugging information is to make it
interact
well with optimizations and analysis. ... Compiling a program with "-O3 -g"
gives you full debug information."

However, compiling with optimisation seems to disable debugging.

llvm_initialize_backend() (in llvm-gcc-4.0/gcc/llvm-backend.cpp) has this:

  if (!optimize && debug_info_level > DINFO_LEVEL_NONE)
    TheDebugInfo = new DebugInfo(TheModule);

which suggests that this is intentional.

(This is with 2.0)


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Thu Sep 27 10:49:25 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 27 Sep 2007 10:49:25 -0500
Subject: [LLVMbugs] [Bug 1708] assertion failure with complex short data type
In-Reply-To: <bug-1708-206@http.llvm.org/bugs/>
Message-ID: <200709271549.l8RFnPTZ003068@zion.cs.uiuc.edu>

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


Chris Lattner <sabre at nondot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|enhancement                 |normal
             Status|NEW                         |RESOLVED
          Component|new bugs                    |llvm-gcc
           Keywords|                            |compile-fail
            Product|new-bugs                    |tools
         Resolution|                            |FIXED
   Target Milestone|---                         |2.2
            Version|unspecified                 |1.0




--- Comment #1 from Chris Lattner <sabre at nondot.org>  2007-09-27 10:49:24 ---
Fixed, patch here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070924/054001.html
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070924/054002.html

Testcase here: test/CFrontend/2007-09-27-ComplexIntCompare.c

Thanks!

-Chris


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Fri Sep 28 12:44:38 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 28 Sep 2007 12:44:38 -0500
Subject: [LLVMbugs] [Bug 1711] New: failing build of llvm-gcc-4.2 on x84-64
 ( relocation R_X86_64_PC32 against `__cxa_finalize@@GLIBC_2.2.5')
Message-ID: <bug-1711-206@http.llvm.org/bugs/>

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

           Summary: failing build of llvm-gcc-4.2 on x84-64 (relocation
                    R_X86_64_PC32 against `__cxa_finalize@@GLIBC_2.2.5')
           Product: new-bugs
           Version: unspecified
          Platform: Other
        OS/Version: Linux
            Status: NEW
          Severity: major
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: kenneth.hoste at elis.ugent.be
                CC: asl at math.spbu.ru, llvmbugs at cs.uiuc.edu


While trying to build llvm-gcc-4.2 on Gentoo Linux x84-64, I'm running into the
problem below. 
I was told (@ IRC) this is a known problem, and efforts have been made to solve
it, but it not well-known enough yet to solve it globally.

I'm using SVN head for both LLVM and llvm-gcc-4.2, and am doing a debug build. 

LLVM is configured with ./configure --prefix=<path>, and made using just
'make', while llvm-gcc-4.2 is configured with

./llvm-gcc-4.2/configure --prefix=/tmp/kehoste/LLVM/llvm-gcc-4.2-bin
--enable-llvm=/tmp/kehoste/LLVM/llvm-obj --enable-languages=c,c++,fortran
--enable-checking

and built with 'make'.

Any further tests I can do, or information I can provide?

/tmp/kehoste/LLVM/llvm-gcc-4.2-obj/./gcc/xgcc
-B/tmp/kehoste/LLVM/llvm-gcc-4.2-obj/./gcc/
-B/tmp/kehoste/LLVM/llvm-gcc-4.2-bin/x86_64-unknown-linux-gnu/bin/
-B/tmp/kehoste/LLVM/llvm-gcc-4.2-bin/x86_64-unknown-linux-gnu/lib/ -isystem
/tmp/kehoste/LLVM/llvm-gcc-4.2-bin/x86_64-unknown-linux-gnu/include -isystem
/tmp/kehoste/LLVM/llvm-gcc-4.2-bin/x86_64-unknown-linux-gnu/sys-include -O2 
-O2 -fPIC  -DIN_GCC    -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition  -isystem ./include  -fPIC -g
-DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED  -shared
-nodefaultlibs -Wl,--soname=libgcc_s.so.1
-Wl,--version-script=libgcc/./libgcc.map -o ./libgcc_s.so.1.tmp 
libgcc/./_muldi3_s.o libgcc/./_negdi2_s.o libgcc/./_lshrdi3_s.o
libgcc/./_ashldi3_s.o libgcc/./_ashrdi3_s.o libgcc/./_cmpdi2_s.o
libgcc/./_ucmpdi2_s.o libgcc/./_clear_cache_s.o
libgcc/./_enable_execute_stack_s.o libgcc/./_trampoline_s.o libgcc/./__main_s.o
libgcc/./_absvsi2_s.o libgcc/./_absvdi2_s.o libgcc/./_addvsi3_s.o
libgcc/./_addvdi3_s.o libgcc/./_subvsi3_s.o libgcc/./_subvdi3_s.o
libgcc/./_mulvsi3_s.o libgcc/./_mulvdi3_s.o libgcc/./_negvsi2_s.o
libgcc/./_negvdi2_s.o libgcc/./_ctors_s.o libgcc/./_ffssi2_s.o
libgcc/./_ffsdi2_s.o libgcc/./_clz_s.o libgcc/./_clzsi2_s.o
libgcc/./_clzdi2_s.o libgcc/./_ctzsi2_s.o libgcc/./_ctzdi2_s.o
libgcc/./_popcount_tab_s.o libgcc/./_popcountsi2_s.o libgcc/./_popcountdi2_s.o
libgcc/./_paritysi2_s.o libgcc/./_paritydi2_s.o libgcc/./_powisf2_s.o
libgcc/./_powidf2_s.o libgcc/./_powixf2_s.o libgcc/./_powitf2_s.o
libgcc/./_mulsc3_s.o libgcc/./_muldc3_s.o libgcc/./_mulxc3_s.o
libgcc/./_multc3_s.o libgcc/./_divsc3_s.o libgcc/./_divdc3_s.o
libgcc/./_divxc3_s.o libgcc/./_divtc3_s.o libgcc/./_bswapsi2_s.o
libgcc/./_bswapdi2_s.o libgcc/./_fixunssfsi_s.o libgcc/./_fixunsdfsi_s.o
libgcc/./_fixunsxfsi_s.o libgcc/./_fixsfdi_s.o libgcc/./_fixunssfdi_s.o
libgcc/./_floatdisf_s.o libgcc/./_floatundisf_s.o libgcc/./_fixdfdi_s.o
libgcc/./_fixunsdfdi_s.o libgcc/./_floatdidf_s.o libgcc/./_floatundidf_s.o
libgcc/./_fixxfdi_s.o libgcc/./_fixunsxfdi_s.o libgcc/./_floatdixf_s.o
libgcc/./_floatundixf_s.o libgcc/./_fixtfdi_s.o libgcc/./_fixunstfdi_s.o
libgcc/./_floatditf_s.o libgcc/./_floatunditf_s.o libgcc/./_divdi3_s.o
libgcc/./_moddi3_s.o libgcc/./_udivdi3_s.o libgcc/./_umoddi3_s.o
libgcc/./_udiv_w_sdiv_s.o libgcc/./_udivmoddi4_s.o libgcc/./unwind-dw2_s.o
libgcc/./unwind-dw2-fde-glibc_s.o libgcc/./unwind-sjlj_s.o
libgcc/./gthr-gnat_s.o libgcc/./unwind-c_s.o -lc && rm -f ./libgcc_s.so && if [
-f ./libgcc_s.so.1 ]; then mv -f ./libgcc_s.so.1 ./libgcc_s.so.1.backup; else
true; fi && mv ./libgcc_s.so.1.tmp ./libgcc_s.so.1 && ln -s libgcc_s.so.1
./libgcc_s.so
/usr/bin/ld: /tmp/kehoste/LLVM/llvm-gcc-4.2-obj/./gcc/crtbeginS.o: relocation
R_X86_64_PC32 against `__cxa_finalize@@GLIBC_2.2.5' can not be used when making
a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Bad value
collect2: ld returned 1 exit status
make[4]: *** [libgcc_s.so] Error 1
make[4]: Leaving directory `/tmp/kehoste/LLVM/llvm-gcc-4.2-obj/gcc'
make[3]: *** [stmp-multilib] Error 2
make[3]: Leaving directory `/tmp/kehoste/LLVM/llvm-gcc-4.2-obj/gcc'
make[2]: *** [all-stage1-gcc] Error 2
make[2]: Leaving directory `/tmp/kehoste/LLVM/llvm-gcc-4.2-obj'
make[1]: *** [stage1-bubble] Error 2
make[1]: Leaving directory `/tmp/kehoste/LLVM/llvm-gcc-4.2-obj'
make: *** [all] Error 2


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Fri Sep 28 14:50:52 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 28 Sep 2007 14:50:52 -0500
Subject: [LLVMbugs] [Bug 1712] New: Null pointer dereference in
	SelectionDAGLowering
Message-ID: <bug-1712-206@http.llvm.org/bugs/>

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

           Summary: Null pointer dereference in SelectionDAGLowering
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Archive library
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: ddunbar at stanford.edu
                CC: llvmbugs at cs.uiuc.edu


Around lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp : 2987
--
SelectionDAGLowering::visitCall calls Function::getNameLen without first
checking if the function name is non-null. It seems reasonable to just have
getNameLen return 0 if the name is null but if this is not the appropriate fix
then visitCall should check name for null first.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Fri Sep 28 15:10:12 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 28 Sep 2007 15:10:12 -0500
Subject: [LLVMbugs] [Bug 1712] Null pointer dereference in
	SelectionDAGLowering
In-Reply-To: <bug-1712-206@http.llvm.org/bugs/>
Message-ID: <200709282010.l8SKACV2016086@zion.cs.uiuc.edu>

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


Chris Lattner <sabre at nondot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
          Component|Archive library             |Core LLVM classes
         Resolution|                            |FIXED
   Target Milestone|---                         |2.2




--- Comment #1 from Chris Lattner <sabre at nondot.org>  2007-09-28 15:10:12 ---
Fixed, plz verify:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070924/054065.html

-Chris


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Fri Sep 28 18:30:00 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 28 Sep 2007 18:30:00 -0500
Subject: [LLVMbugs] [Bug 1713] New: Command guide docs broken for offline
 viewing and releases.
Message-ID: <bug-1713-206@http.llvm.org/bugs/>

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

           Summary: Command guide docs broken for offline viewing and
                    releases.
           Product: Documentation
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: General docs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: tonic at nondot.org
                CC: llvmbugs at cs.uiuc.edu


The index.html links to the command guide docs (ie. llc, lli) is hardcoded to
use the /cmds/ path which only works on our website. It is broken for offline
viewing. It also breaks the links for the online version of the release docs
since we want those docs to be specific to the release and not whats in
mainline.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Fri Sep 28 19:45:09 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 28 Sep 2007 19:45:09 -0500
Subject: [LLVMbugs] [Bug 1601] etags not configured correctly
In-Reply-To: <bug-1601-206@http.llvm.org/bugs/>
Message-ID: <200709290045.l8T0j9pc029803@zion.cs.uiuc.edu>

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


Gordon Henriksen <gordonhenriksen at mac.com> changed:

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




--- Comment #5 from Gordon Henriksen <gordonhenriksen at mac.com>  2007-09-28 19:45:09 ---
Deleted vestigal etags support here:

http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070924/054086.html
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070924/054087.html


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Sat Sep 29 10:14:06 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 29 Sep 2007 10:14:06 -0500
Subject: [LLVMbugs] [Bug 1714] New: constant assertion fails while building
	libgfortran
Message-ID: <bug-1714-206@http.llvm.org/bugs/>

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

           Summary: constant assertion fails while building libgfortran
           Product: new-bugs
           Version: unspecified
          Platform: Macintosh
        OS/Version: Mac System 9.x
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: kenneth.hoste at elis.ugent.be
                CC: asl at math.spbu.ru, llvmbugs at cs.uiuc.edu


While building llvm-gcc-4.2 with fortran support on Linux/x86 (32 bit), I'm
running into a failing assertion when libgfortran is being built (see below).

I'm using SVN head for both llvm-gcc-4.2 and LLVM. I have adjusted llvm-gcc-4.2
slighty using the patch at
http://www.nabble.com/fixincludes-for-glibc-'inline'-non-C99-conformance-t2564711.html,
 but I don't think that is related to this, because the patch fixes a
C++-related problem.

LLVM is built using './configure' and 'make', llvm-gcc-4.2 is configured with
'../llvm-gcc-4.2-patched/configure
--prefix=/work/LLVM/LLVM/llvm-gcc-4.2-bin-patched
--enable-llvm=/work/LLVM/llvm-obj --enable-languages=c,c++,fortran
--enable-checking' and built using 'make'.

Is there something missing in LLVM regarding AST-support? (just guessing here,
I saw llvm-convert is converting from AST to LLVM code).

/bin/sh ./libtool --mode=compile
/work/LLVM/llvm-gcc-4.2-obj-patched/./gcc/gfortran
-B/work/LLVM/llvm-gcc-4.2-obj-patched/./gcc/
-B/work/LLVM/LLVM/llvm-gcc-4.2-bin-patched/i686-pc-linux-gnu/bin/
-B/work/LLVM/LLVM/llvm-gcc-4.2-bin-patched/i686-pc-linux-gnu/lib/ -isystem
/work/LLVM/LLVM/llvm-gcc-4.2-bin-patched/i686-pc-linux-gnu/include -isystem
/work/LLVM/LLVM/llvm-gcc-4.2-bin-patched/i686-pc-linux-gnu/sys-include -I .
-Wall -fno-repack-arrays -fno-underscoring -g -O2 -c -o selected_int_kind.lo
`test -f 'intrinsics/selected_int_kind.f90' || echo
'../../../llvm-gcc-4.2-patched/libgfortran/'`intrinsics/selected_int_kind.f90
/work/LLVM/llvm-gcc-4.2-obj-patched/./gcc/gfortran
-B/work/LLVM/llvm-gcc-4.2-obj-patched/./gcc/
-B/work/LLVM/LLVM/llvm-gcc-4.2-bin-patched/i686-pc-linux-gnu/bin/
-B/work/LLVM/LLVM/llvm-gcc-4.2-bin-patched/i686-pc-linux-gnu/lib/ -isystem
/work/LLVM/LLVM/llvm-gcc-4.2-bin-patched/i686-pc-linux-gnu/include -isystem
/work/LLVM/LLVM/llvm-gcc-4.2-bin-patched/i686-pc-linux-gnu/sys-include -I .
-Wall -fno-repack-arrays -fno-underscoring -g -O2 -c
../../../llvm-gcc-4.2-patched/libgfortran/intrinsics/selected_int_kind.f90 -o
selected_int_kind.o
WARNING: 128-bit integers not supported!
f951: ../../llvm-gcc-4.2-patched/gcc/llvm-convert.cpp:5184: static
llvm::Constant* TreeConstantToLLVM::Convert(tree_node*): Assertion
`((__extension__ ({ const tree __t = (exp); if ((tree_code_type[(int) (((enum
tree_code) (__t)->common.code))] == tcc_type)) tree_not_class_check_failed
(__t, tcc_type, "../../llvm-gcc-4.2-patched/gcc/llvm-convert.cpp", 5184,
__FUNCTION__); __t; })->common.constant_flag) || ((enum tree_code)
(exp)->common.code) == STRING_CST) && "Isn't a constant!"' failed.
../../../llvm-gcc-4.2-patched/libgfortran/intrinsics/selected_int_kind.f90: In
function 'selected_int_kind':
../../../llvm-gcc-4.2-patched/libgfortran/intrinsics/selected_int_kind.f90:22:
internal compiler error: Aborted
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://developer.apple.com/bugreporter> for instructions.
make[3]: *** [selected_int_kind.lo] Error 1
make[3]: Leaving directory
`/home/kehoste/work/LLVM/llvm-gcc-4.2-obj-patched/i686-pc-linux-gnu/libgfortran'
make[2]: *** [all] Error 2
make[2]: Leaving directory
`/home/kehoste/work/LLVM/llvm-gcc-4.2-obj-patched/i686-pc-linux-gnu/libgfortran'
make[1]: *** [all-target-libgfortran] Error 2
make[1]: Leaving directory `/home/kehoste/work/LLVM/llvm-gcc-4.2-obj-patched'
make: *** [all] Error 2


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Sat Sep 29 21:41:29 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 29 Sep 2007 21:41:29 -0500
Subject: [LLVMbugs] [Bug 1715] New: getAnalysis<someimmutablepass> doesn' t
 work from doInitialization(Module&)
Message-ID: <bug-1715-206@http.llvm.org/bugs/>

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

           Summary: getAnalysis<someimmutablepass> doesn't work from
                    doInitialization(Module&)
           Product: libraries
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: minor
          Priority: P2
         Component: Core LLVM classes
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: gordonhenriksen at mac.com
                CC: llvmbugs at cs.uiuc.edu


Quirkily, using getAnalysisToUpdate<someimmutablepass> instead does work.

AsmPrinter::doInitialization uses this behavior to get ahold of
MachineModuleInfo, which may not be present at all, so getAnalysisToUpdate is
appropriate.

However, I needed to unconditionally get a handle onto an ImmutablePass, and so
used getAnalysis instead. It failed an assertion that the pass was not required
(which was false).


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Sun Sep 30 17:20:36 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 30 Sep 2007 17:20:36 -0500
Subject: [LLVMbugs] [Bug 1716] New: noalias attribute pessimization
Message-ID: <bug-1716-206@http.llvm.org/bugs/>

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

           Summary: noalias attribute pessimization
           Product: libraries
           Version: trunk
          Platform: Macintosh
        OS/Version: Mac System 9.x
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Core LLVM classes
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: sabre at nondot.org
                CC: llvmbugs at cs.uiuc.edu


The following simple code:

#include <stdio.h>
#include <stdlib.h>

int power(int X) {
  if (X == 0) return 1;
  return X*power(X-1);
}

int main(int argc, char **argv) {
  printf("%d\n", power(atoi(argv[0])));
}

Produces this LLVM code on linux:

...
        %tmp20 = tail call i32 (i8* noalias , ...)* bitcast (i32 (i8*, ...)*
@printf to i32 (i8* noalias , ...)*)( i8* getelementptr ([4 x i8]* @.str, i32
0, i32 0) noalias , i32 %accumulator.tr.lcssa.i )            ; <i32> [#uses=0]

The bitcasting needs to be resolved, which is there only because of the noalias
attribute.

-Chris


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.