From bugzilla-daemon at llvm.org  Mon Mar  1 07:22:29 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  1 Mar 2010 07:22:29 -0600 (CST)
Subject: [LLVMbugs] [Bug 6447] New: Building C++ app fails with link error
Message-ID: <bug-6447-206@http.llvm.org/bugs/>

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

           Summary: Building C++ app fails with link error
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P5
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: jpakkane at gmail.com
                CC: llvmbugs at cs.uiuc.edu


I try to build Cuneiform OCR system with clang but it fails. Here's how to
duplicate using the latest bzr:

bzr branch lp:cuneiform-linux cf
cd cf
mkdir builddir
cd builddir
CC=/path/to/clang CXX=/path/to/clang++ cmake -DCMAKE_BUILD_TYPE=debug ..
make

Eventually you get this error:

Linking CXX executable ../../cuneiform
../Kern/cpage/libcpage.so.0.9.0: undefined reference to `BLOCK::~BLOCK()'
collect2: ld returned 1 exit status

But BLOCK::~BLOCK is defined in cuneiform_src/Kern/cpage/sources/cpp/block.h:

class BLOCK: public DATA
{
[stuff removed]

public:
    BLOCK();
    virtual ~BLOCK();

and its (empty) implementation is in the corresponding block.cpp:

BLOCK::~BLOCK()
{
}

And this file even gets included in the CMakeLists.txt.

The same code does work with GCC, MinGW, and MSVC.

-- 
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 llvm.org  Mon Mar  1 09:08:21 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  1 Mar 2010 09:08:21 -0600 (CST)
Subject: [LLVMbugs] [Bug 6448] New: clang -fsyntax-only fails on something
	g++ accepts
Message-ID: <bug-6448-206@http.llvm.org/bugs/>

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

           Summary: clang -fsyntax-only fails on something g++ accepts
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: rdivacky at freebsd.org
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com
            Blocks: 6266


when compiling the attached:

pes delta$ g++ -fsyntax-only ext-inst.cc && echo success
success

pes delta$ clang++ -fsyntax-only ext-inst.cc && echo success
ext-inst.cc:20:171: error: '_CharT' does not refer to a value
  ...= (_Rope_RopeLeaf<_CharT, _Alloc>*)this;      __l->_Rope_RopeLeaf<_CharT,
_Alloc>::~_Rope_RopeLeaf(); ...
                                                                       ^
ext-inst.cc:19:31: note: declared at
              template <class _CharT, class _Alloc>     void    
_Rope_RopeRep<_CharT, _Alloc>:: ...
                              ^
ext-inst.cc:20:424: error: '_CharT' does not refer to a value
  ...= (_Rope_RopeConcatenation<_CharT, _Alloc>*)this;     
__c->_Rope_RopeConcatenation<_CharT, _Alloc>:: ...
                                                                               
         ^
ext-inst.cc:19:31: note: declared at
              template <class _CharT, class _Alloc>     void    
_Rope_RopeRep<_CharT, _Alloc>:: ...
                              ^
ext-inst.cc:20:682: error: '_CharT' does not refer to a value
  ..._Alloc>*)this;      __f->_Rope_RopeFunction<_CharT,
_Alloc>::~_Rope_RopeFunction();      _F_deallocate(__f, ...
                                                 ^
ext-inst.cc:19:31: note: declared at
              template <class _CharT, class _Alloc>     void    
_Rope_RopeRep<_CharT, _Alloc>:: ...
                              ^
ext-inst.cc:20:935: error: '_CharT' does not refer to a value
  ...__ss =        (_Rope_RopeSubstring<_CharT, _Alloc>*)this;     
__ss->_Rope_RopeSubstring<_CharT, _Alloc>:: ...
                                                                               
              ^
ext-inst.cc:19:31: note: declared at
              template <class _CharT, class _Alloc>     void    
_Rope_RopeRep<_CharT, _Alloc>:: ...
                              ^
8 diagnostics generated.

-- 
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 llvm.org  Mon Mar  1 09:28:11 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  1 Mar 2010 09:28:11 -0600 (CST)
Subject: [LLVMbugs] [Bug 6449] New: clang -fsyntax-only fails on something
 g++ accepts [2]
Message-ID: <bug-6449-206@http.llvm.org/bugs/>

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

           Summary: clang -fsyntax-only fails on something g++ accepts [2]
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: rdivacky at freebsd.org
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com
            Blocks: 6266


pes delta$ g++ -fsyntax-only locale-inst.cc && echo yes
yes

pes delta$ clang++ -fsyntax-only locale-inst.cc && echo yes
locale-inst.cc:27:95: error: redefinition of 'intl'
       template<typename _CharT, bool _Intl>     const bool
moneypunct_byname<_CharT, _Intl>::intl;
                                                                               
              ^
locale-inst.cc:29:22: note: in instantiation of static data member
'std::moneypunct_byname<char, 0>::intl' requested
      here
      template class moneypunct_byname<char, false>;
                     ^
locale-inst.cc:23:88: note: previous definition is here
       template<typename _CharT, bool _Intl>     const bool moneypunct<_CharT,
_Intl>::intl;
                                                                               
       ^
3 diagnostics generated.

-- 
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 llvm.org  Mon Mar  1 09:46:20 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  1 Mar 2010 09:46:20 -0600 (CST)
Subject: [LLVMbugs] [Bug 6450] New: LiveIntervals code doesn't properly
 identify unspillable registers.
Message-ID: <bug-6450-206@http.llvm.org/bugs/>

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

           Summary: LiveIntervals code doesn't properly identify
                    unspillable registers.
           Product: new-bugs
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: mwb.cde at googlemail.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=4342)
 --> (http://llvm.org/bugs/attachment.cgi?id=4342)
LiveInterval patch - add no_spill field

The spiller code in LiveIntervalAnalysis.cpp and Spiller.cpp asserts
when passed a register with infinite weight even if the register is a
valid choice for spilling.

Registers that can't be spilled, because they are generated by the
spiller for a register placed on the stack, are identified by setting
their interval weight to HUGE_VALF (== inf). This makes them
indistinguishable from normal registers that have infinite weight,
which can occur with deeply nested loops such as generated by the test
case for bug 5846.

The attached LiveIntervals patch adds boolean field no_spill to class
LiveInterval, to indicate whether the interval represents a spillable
register, and updates the spiller code to set and test the field. It
does not change the setting and testing of the interval weight except
to remove the assertions so this patch should not affect any existing
code. The patch has been tested for the CodeGen component.

The RegAllocLinScan patch is a partial, untested change to
RegAllocLinearScan to make use of the no_spill field when trying to
find a register to spill. It gets the test-case for bug 5846 to
compile but is only meant as an example of use and has not been
tested.

-- 
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 llvm.org  Mon Mar  1 09:57:38 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  1 Mar 2010 09:57:38 -0600 (CST)
Subject: [LLVMbugs] [Bug 6376] Assertion failed: ((Result ||
 isa<UsingShadowDecl>(D)) && "Unable to find instantiation of declaration!"),
 function FindInstantiatedDecl, file SemaTemplateInstantiateDecl.cpp,
 line 2306.
In-Reply-To: <bug-6376-206@http.llvm.org/bugs/>
References: <bug-6376-206@http.llvm.org/bugs/>
Message-ID: <20100301155738.97D182A6C12F@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #5 from Douglas Gregor <dgregor at apple.com> 2010-03-01 09:57:37 CST ---
Fixed in r97444.

-- 
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 llvm.org  Mon Mar  1 12:00:16 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  1 Mar 2010 12:00:16 -0600 (CST)
Subject: [LLVMbugs] [Bug 6335] TargetLowering::SimplifyDemandedBits
 incorrectly handles vector types on Truncate
In-Reply-To: <bug-6335-206@http.llvm.org/bugs/>
References: <bug-6335-206@http.llvm.org/bugs/>
Message-ID: <20100301180016.E921D2A6C12C@llvm.org>

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

Dan Gohman <gohman at apple.com> changed:

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

--- Comment #2 from Dan Gohman <gohman at apple.com> 2010-03-01 12:00:16 CST ---
Thanks for the report and patch. I applied a fix to trunk in r97461.

-- 
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 llvm.org  Mon Mar  1 12:21:19 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  1 Mar 2010 12:21:19 -0600 (CST)
Subject: [LLVMbugs] [Bug 5825] c++ parser infinite loop
In-Reply-To: <bug-5825-206@http.llvm.org/bugs/>
References: <bug-5825-206@http.llvm.org/bugs/>
Message-ID: <20100301182119.2A4AB2A6C12D@llvm.org>

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

John McCall <rjmccall at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
                 CC|                            |rjmccall at apple.com
         Resolution|                            |FIXED

--- Comment #4 from John McCall <rjmccall at apple.com> 2010-03-01 12:21:18 CST ---
Fixed in r97462.

-- 
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 llvm.org  Mon Mar  1 13:00:24 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  1 Mar 2010 13:00:24 -0600 (CST)
Subject: [LLVMbugs] [Bug 6375] Assertion failed: (Result && "declaration was
 not instantiated in this scope!")
In-Reply-To: <bug-6375-206@http.llvm.org/bugs/>
References: <bug-6375-206@http.llvm.org/bugs/>
Message-ID: <20100301190024.406072A6C12E@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #4 from Douglas Gregor <dgregor at apple.com> 2010-03-01 13:00:23 CST ---
Fixed in r97471.

-- 
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 llvm.org  Mon Mar  1 13:03:53 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  1 Mar 2010 13:03:53 -0600 (CST)
Subject: [LLVMbugs] [Bug 6448] clang -fsyntax-only fails on something g++
	accepts
In-Reply-To: <bug-6448-206@http.llvm.org/bugs/>
References: <bug-6448-206@http.llvm.org/bugs/>
Message-ID: <20100301190353.B7FDF2A6C12E@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #2 from Douglas Gregor <dgregor at apple.com> 2010-03-01 13:03:53 CST ---
In all of these cases, the code is ill-formed because it is missing a
"template" keyword after the "->". We should produce a better diagnostic, but
that's PR5404.

-- 
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 llvm.org  Mon Mar  1 13:12:25 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  1 Mar 2010 13:12:25 -0600 (CST)
Subject: [LLVMbugs] [Bug 6449] clang -fsyntax-only fails on something g++
	accepts [2]
In-Reply-To: <bug-6449-206@http.llvm.org/bugs/>
References: <bug-6449-206@http.llvm.org/bugs/>
Message-ID: <20100301191225.229C32A6C12E@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #3 from Douglas Gregor <dgregor at apple.com> 2010-03-01 13:12:24 CST ---
Fixed in r97478.

-- 
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 llvm.org  Mon Mar  1 13:24:46 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  1 Mar 2010 13:24:46 -0600 (CST)
Subject: [LLVMbugs] [Bug 2194] Wrong NoAlias from Andersens alias analysis
 in combination with loop-reduce
In-Reply-To: <bug-2194-206@http.llvm.org/bugs/>
References: <bug-2194-206@http.llvm.org/bugs/>
Message-ID: <20100301192446.BAA692A6C12C@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #2 from Chris Lattner <clattner at apple.com> 2010-03-01 13:24:46 CST ---
I just removed anders-aa from 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 llvm.org  Mon Mar  1 13:25:00 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  1 Mar 2010 13:25:00 -0600 (CST)
Subject: [LLVMbugs] [Bug 2451] Anders pass asserts on
	extractelement/insertelement
In-Reply-To: <bug-2451-206@http.llvm.org/bugs/>
References: <bug-2451-206@http.llvm.org/bugs/>
Message-ID: <20100301192500.7DC362A6C12D@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #4 from Chris Lattner <clattner at apple.com> 2010-03-01 13:25:00 CST ---
I just removed anders-aa from 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 llvm.org  Mon Mar  1 13:25:42 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  1 Mar 2010 13:25:42 -0600 (CST)
Subject: [LLVMbugs] [Bug 3323] AliasAnalysis pass removed before function
 pass can use it
In-Reply-To: <bug-3323-206@http.llvm.org/bugs/>
References: <bug-3323-206@http.llvm.org/bugs/>
Message-ID: <20100301192542.19E832A6C124@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #4 from Chris Lattner <clattner at apple.com> 2010-03-01 13:25:41 CST ---
I just removed anders-aa from mainline, so this doesn't repro.  If it remains a
problem we can investigate in the future.

-- 
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 llvm.org  Mon Mar  1 13:34:54 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  1 Mar 2010 13:34:54 -0600 (CST)
Subject: [LLVMbugs] [Bug 6451] New: Missing diagnostics for jump crossing
	initialization
Message-ID: <bug-6451-206@http.llvm.org/bugs/>

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

           Summary: Missing diagnostics for jump crossing initialization
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: dgregor at apple.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


The jump diagnostics need to learn that we can't jump past an initialization in
C++:

terfin:clang dgregor$ cat t.C
struct X {
  X();
};

void f() {
  goto later;
  X x;
 later:
  ;
}
terfin:clang dgregor$ clang -fsyntax-only t.C
terfin:clang dgregor$ g++ -fsyntax-only t.C
t.C: In function ?void f()?:
t.C:8: error: jump to label ?later?
t.C:6: error:   from here
t.C:7: error:   crosses initialization of ?X 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 llvm.org  Mon Mar  1 14:23:26 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  1 Mar 2010 14:23:26 -0600 (CST)
Subject: [LLVMbugs] [Bug 6452] New: Prevent an input structure from being
 copied to the stack
Message-ID: <bug-6452-206@http.llvm.org/bugs/>

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

           Summary: Prevent an input structure from being copied to the
                    stack
           Product: libraries
           Version: 2.6
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: Register Allocator
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: llvm at henning-thielemann.de
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=4347)
 --> (http://llvm.org/bugs/attachment.cgi?id=4347)
an example where values are copied from an input struct to the stack, although
they could remain in the input struct

I have a function definition like
  define i32 @_fun1(%param* noalias, i32, float* noalias)
that reads parameters from a struct type %param and writes results to a float
array of size with type i32. Now LLVM generates code that first copies all
parameters to the stack. This is correct in all circumstances but in my
application I can warrant that the parameter struct and the float array do not
overlap and thus the parameters could always be fetched directly from the
parameter struct. But maybe this isn't even a bug but a feature, because LLVM
expects faster memory access if all temporarily needed values are at one place
(on the stack)?

Maybe this is related to
http://llvm.org/bugs/show_bug.cgi?id=1819
http://llvm.org/bugs/show_bug.cgi?id=1821

-- 
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 llvm.org  Mon Mar  1 14:45:32 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  1 Mar 2010 14:45:32 -0600 (CST)
Subject: [LLVMbugs] [Bug 6453] New: LSR produces invalid IR
Message-ID: <bug-6453-206@http.llvm.org/bugs/>

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

           Summary: LSR produces invalid IR
           Product: libraries
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P5
         Component: Loop Optimizer
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: stoklund at 2pi.dk
                CC: llvmbugs at cs.uiuc.edu


This cropped up during a bugpoint session:

$ Release/bin/opt -loop-reduce -verify LoopReduce.ll -o /dev/null
Instruction does not dominate all uses!
  %lsr.iv.next5 = add i32 %lsr.iv4, %lsr.iv2      ; <i32> [#uses=2]
  %tmp9 = sub i32 %lsr.iv.next5, %tmp8            ; <i32> [#uses=1]
Broken module found, compilation aborted!
0  opt               0x000000010041ca92 PrintStackTrace(void*) + 34
1  opt               0x000000010041d27c SignalHandler(int) + 652
2  libSystem.B.dylib 0x00007fff8160deaa _sigtramp + 26
3  libSystem.B.dylib 0x00007fff5fbfeec0 _sigtramp + 3730772016
4  opt               0x00000001003e33b1 (anonymous
namespace)::Verifier::runOnFunction(llvm::Function&) + 2049
5  opt               0x00000001003b7f10
llvm::FPPassManager::runOnFunction(llvm::Function&) + 512
6  opt               0x00000001003b806b
llvm::FPPassManager::runOnModule(llvm::Module&) + 75
7  opt               0x00000001003b97ce
llvm::MPPassManager::runOnModule(llvm::Module&) + 478
8  opt               0x00000001003b9983
llvm::PassManagerImpl::run(llvm::Module&) + 147
9  opt               0x00000001003b9a0d llvm::PassManager::run(llvm::Module&) +
13
10 opt               0x00000001000465d7 main + 2951
11 opt               0x000000010003caa8 start + 52
Stack dump:
0.    Program arguments: Release/bin/opt -loop-reduce -verify LoopReduce.ll -o
/dev/null 
1.    Running pass 'Function Pass Manager' on module 'LoopReduce.ll'.
2.    Running pass 'Module Verifier' on function
'@_ZNK15PolynomialSpaceILi3EE13compute_indexEjRA3_j'
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 llvm.org  Mon Mar  1 14:53:02 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  1 Mar 2010 14:53:02 -0600 (CST)
Subject: [LLVMbugs] [Bug 6454] New: clang -fsyntax-only fails on something
 g++ accepts [3]
Message-ID: <bug-6454-206@http.llvm.org/bugs/>

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

           Summary: clang -fsyntax-only fails on something g++ accepts [3]
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: FreeBSD
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: rdivacky at freebsd.org
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


pes delta$ g++ -fsyntax-only ext-inst.cc && echo success
success

pes delta$ clang++ -fsyntax-only ext-inst.cc && echo success
ext-inst.cc:9:5: warning: control reaches end of non-void function
[-Wreturn-type]
    }
    ^
ext-inst.cc:37:41: error: use of undeclared identifier '_Data_allocate'
        _CharT* __new_data = (_CharT*) 
_Data_allocate(_S_rounded_up_size(__old_len + __len));
                                        ^
2 diagnostics generated.

-- 
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 llvm.org  Mon Mar  1 14:56:02 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  1 Mar 2010 14:56:02 -0600 (CST)
Subject: [LLVMbugs] [Bug 6455] New: Clear most significant 32 bits in the
 elements <2 x i64> efficiently
Message-ID: <bug-6455-206@http.llvm.org/bugs/>

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

           Summary: Clear most significant 32 bits in the elements <2 x
                    i64> efficiently
           Product: libraries
           Version: 2.6
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: Backend: X86
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: llvm at henning-thielemann.de
                CC: llvmbugs at cs.uiuc.edu


I wanted to write a multiplication of two <2 x i 64> vectors that could be
implemented by pmuludq.
(See http://llvm.org/bugs/show_bug.cgi?id=6399)
I cleared the upper 32 bits of the vector elements of the factors before doing
the multiplication,
in order to show LLVM that pmuludq can be used instead of a full <2 x i 64>
multiplication.
(I was not sure whether LLVM understands this hint.)
However I found that clearing the upper 32 bits is sometimes compiled to quite
inefficient code depending on how I write it.

The first two of the following implementations lead to inefficient code,
and might be replaced automatically by the last one.

define <2 x i64> @_clearupper2xi64a(<2 x i64>) {
  %x0 = extractelement <2 x i64> %0, i32 0
  %x1 = extractelement <2 x i64> %0, i32 1
  %trunc0 = trunc i64 %x0 to i32
  %trunc1 = trunc i64 %x1 to i32
  %ext0 = zext i32 %trunc0 to i64
  %ext1 = zext i32 %trunc1 to i64
  %v0 = insertelement <2 x i64> undef, i64 %ext0, i32 0
  %v1 = insertelement <2 x i64> %v0,   i64 %ext1, i32 1
  ret <2 x i64> %v1
}

define <2 x i64> @_clearupper2xi64b(<2 x i64>) {
  %x32 = bitcast <2 x i64> %0 to <4 x i32>
  %r0 = insertelement <4 x i32> %x32, i32 zeroinitializer, i32 1
  %r1 = insertelement <4 x i32> %r0,  i32 zeroinitializer, i32 3
  %r = bitcast <4 x i32> %r1 to <2 x i64>
  ret <2 x i64> %r
}

define <2 x i64> @_clearupper2xi64c(<2 x i64>) {
  %r = and <2 x i64> <i64 4294967295, i64 4294967295>, %0
  ret <2 x i64> %r
}

They are compiled to:
    .align    16
    .globl    _clearupper2xi64a
    .type    _clearupper2xi64a, at function
_clearupper2xi64a:                                          #
@_clearupper2xi64a
.Leh_func_begin7:
.LBB7_0:
    pushl    %ebp
.Llabel14:
    movl    %esp, %ebp
.Llabel15:
    andl    $-16, %esp
    xorps    %xmm1, %xmm1
    movss    %xmm0, %xmm1
    movhlps    %xmm0, %xmm0
    movd    %xmm0, %eax
    movd    %eax, %xmm2
    movaps    %xmm1, %xmm0
    movlhps    %xmm2, %xmm0
    movl    %ebp, %esp
    popl    %ebp
    ret
    .size    _clearupper2xi64a, .-_clearupper2xi64a
.Leh_func_end7:


    .align    16
    .globl    _clearupper2xi64b
    .type    _clearupper2xi64b, at function
_clearupper2xi64b:                                          #
@_clearupper2xi64b
.Leh_func_begin8:
.LBB8_0:
    pushl    %ebp
.Llabel16:
    movl    %esp, %ebp
.Llabel17:
    andl    $-16, %esp
    movaps    %xmm0, %xmm1
    pslldq    $8, %xmm1
    shufps    $226, %xmm0, %xmm1
    xorl    %eax, %eax
    movd    %eax, %xmm0
    movaps    %xmm1, %xmm2
    movss    %xmm0, %xmm2
    movaps    %xmm1, %xmm0
    shufps    $36, %xmm2, %xmm0
    movl    %ebp, %esp
    popl    %ebp
    ret
    .size    _clearupper2xi64b, .-_clearupper2xi64b
.Leh_func_end8:


    .section    .rodata.cst16,"aM", at progbits,16
    .align    16
.LCPI9_0:                                                   # constant <4 x
i32>
    .long    4294967295                                  # 0xFFFFFFFF
    .zero    4
    .long    4294967295                                  # 0xFFFFFFFF
    .zero    4
    .text
    .align    16
    .globl    _clearupper2xi64c
    .type    _clearupper2xi64c, at function
_clearupper2xi64c:                                          #
@_clearupper2xi64c
.Leh_func_begin9:
.LBB9_0:
    pushl    %ebp
.Llabel18:
    movl    %esp, %ebp
.Llabel19:
    andl    $-16, %esp
    pand    .LCPI9_0, %xmm0
    movl    %ebp, %esp
    popl    %ebp
    ret
    .size    _clearupper2xi64c, .-_clearupper2xi64c
.Leh_func_end9:

-- 
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 llvm.org  Mon Mar  1 14:56:23 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  1 Mar 2010 14:56:23 -0600 (CST)
Subject: [LLVMbugs] [Bug 6454] clang -fsyntax-only fails on something g++
	accepts [3]
In-Reply-To: <bug-6454-206@http.llvm.org/bugs/>
References: <bug-6454-206@http.llvm.org/bugs/>
Message-ID: <20100301205623.0F9B52A6C124@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #2 from Douglas Gregor <dgregor at apple.com> 2010-03-01 14:56:22 CST ---
Clang is correct here. There are no type-dependent arguments in the call to
_Data_allocate, so name lookup fails at template definition time.

-- 
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 llvm.org  Mon Mar  1 15:00:19 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  1 Mar 2010 15:00:19 -0600 (CST)
Subject: [LLVMbugs] [Bug 6451] Missing diagnostics for jump crossing
	initialization
In-Reply-To: <bug-6451-206@http.llvm.org/bugs/>
References: <bug-6451-206@http.llvm.org/bugs/>
Message-ID: <20100301210019.EB1B62A6C12D@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #3 from Chris Lattner <clattner at apple.com> 2010-03-01 15:00:19 CST ---
Implemented here:
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20100301/028039.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 llvm.org  Mon Mar  1 15:01:05 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  1 Mar 2010 15:01:05 -0600 (CST)
Subject: [LLVMbugs] [Bug 6450] LiveIntervals code doesn't properly identify
 unspillable registers.
In-Reply-To: <bug-6450-206@http.llvm.org/bugs/>
References: <bug-6450-206@http.llvm.org/bugs/>
Message-ID: <20100301210105.D273C2A6C12E@llvm.org>

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

Jakob Stoklund Olesen <stoklund at 2pi.dk> changed:

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

--- Comment #5 from Jakob Stoklund Olesen <stoklund at 2pi.dk> 2010-03-01 15:01:05 CST ---
Fixed in r97496

-- 
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 llvm.org  Mon Mar  1 15:01:41 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  1 Mar 2010 15:01:41 -0600 (CST)
Subject: [LLVMbugs] [Bug 5846] Linear Scan Runs Out of Registers
In-Reply-To: <bug-5846-206@http.llvm.org/bugs/>
References: <bug-5846-206@http.llvm.org/bugs/>
Message-ID: <20100301210141.B53D32A6C12E@llvm.org>

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

Jakob Stoklund Olesen <stoklund at 2pi.dk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |stoklund at 2pi.dk
         Resolution|                            |FIXED

--- Comment #2 from Jakob Stoklund Olesen <stoklund at 2pi.dk> 2010-03-01 15:01:41 CST ---
Fixed in r97496

-- 
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 llvm.org  Mon Mar  1 15:06:34 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  1 Mar 2010 15:06:34 -0600 (CST)
Subject: [LLVMbugs] [Bug 5933] bogus unused variable warning after error
In-Reply-To: <bug-5933-206@http.llvm.org/bugs/>
References: <bug-5933-206@http.llvm.org/bugs/>
Message-ID: <20100301210634.5D0252A6C12D@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #9 from Chris Lattner <clattner at apple.com> 2010-03-01 15:06:33 CST ---
Fixed here:
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20100301/028040.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 llvm.org  Mon Mar  1 15:18:01 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  1 Mar 2010 15:18:01 -0600 (CST)
Subject: [LLVMbugs] [Bug 6456] New: clang -fsyntax-only fails on something
 g++ accepts [4]
Message-ID: <bug-6456-206@http.llvm.org/bugs/>

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

           Summary: clang -fsyntax-only fails on something g++ accepts [4]
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: FreeBSD
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: rdivacky at freebsd.org
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


pes delta$ cat locale-inst.cc
        namespace std __attribute__ ((__visibility__ ("default"))) {
         class locale   {
          class facet;
      };
         class locale::facet   {
      };
          struct ctype_base   {
       };
       }
         namespace std __attribute__ ((__visibility__ ("default"))) {
         template<typename _CharT>     class __ctype_abstract_base : public
locale::facet, public ctype_base     {
        };
          inline template class __ctype_abstract_base<char>;
        }

pes delta$ g++ -fsyntax-only locale-inst.cc && echo yes
yes

pes delta$ clang++ -fsyntax-only locale-inst.cc && echo yes
locale-inst.cc:13:18: error: expected unqualified-id
          inline template class __ctype_abstract_base<char>;
                 ^
1 diagnostic generated.

-- 
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 llvm.org  Mon Mar  1 15:18:27 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  1 Mar 2010 15:18:27 -0600 (CST)
Subject: [LLVMbugs] [Bug 6317] Clang gets confused with nested classes and
 friend declarations
In-Reply-To: <bug-6317-206@http.llvm.org/bugs/>
References: <bug-6317-206@http.llvm.org/bugs/>
Message-ID: <20100301211827.4E9132A6C12E@llvm.org>

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

Chandler Carruth <chandlerc at gmail.com> changed:

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

--- Comment #5 from Chandler Carruth <chandlerc at gmail.com> 2010-03-01 15:18:26 CST ---
Fixed in r97499, sorry for delays.

-- 
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 llvm.org  Mon Mar  1 15:20:04 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  1 Mar 2010 15:20:04 -0600 (CST)
Subject: [LLVMbugs] [Bug 6376] Assertion failed: ((Result ||
 isa<UsingShadowDecl>(D)) && "Unable to find instantiation of declaration!"),
 function FindInstantiatedDecl, file SemaTemplateInstantiateDecl.cpp,
 line 2306.
In-Reply-To: <bug-6376-206@http.llvm.org/bugs/>
References: <bug-6376-206@http.llvm.org/bugs/>
Message-ID: <20100301212004.86AC22A6C12E@llvm.org>

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

Andrius Morkunas <hinokind at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #4274|0                           |1
        is obsolete|                            |
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |
         AssignedTo|unassignedclangbugs at nondot. |hinokind at gmail.com
                   |org                         |

--- Comment #6 from Andrius Morkunas <hinokind at gmail.com> 2010-03-01 15:20:03 CST ---
Created an attachment (id=4351)
 --> (http://llvm.org/bugs/attachment.cgi?id=4351)
preprocessed file

This was failing with the same assert before, now fails with updated assert:

$ clang assert8v2.cc
Assertion failed: ((Result || isa<UsingShadowDecl>(D) || D->isInvalidDecl() ||
cast<Decl>(ParentDC)->isInvalidDecl()) && "Unable to find instantiation of
declaration!"), function FindInstantiatedDecl, file
SemaTemplateInstantiateDecl.cpp, line 2337.
Stack dump:
0.    Program arguments: /usr/local/bin/clang -cc1 -triple
x86_64-unknown-freebsd8.0 -S -disable-free -main-file-name assert8v2.cc
-mrelocation-model static -mdisable-fp-elim -mconstructor-aliases
-munwind-tables -target-cpu x86-64 -resource-dir /usr/local/lib/clang/1.1
-fmessage-length 157 -fexceptions -fgnu-runtime -fdiagnostics-show-option
-fcolor-diagnostics -o /tmp/cc-3UXV1F.s -x c++ assert8v2.cc 
1.    systemimagelist.cpp:44:66: current parser token 'Iterator'
clang: error: compiler command failed due to signal 6 (use -v to see
invocation)


$ clang --version
clang version 1.1 (trunk 97498)
Target: x86_64-segfault-freebsd8.0
Thread model: posix

-- 
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 llvm.org  Mon Mar  1 15:22:17 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  1 Mar 2010 15:22:17 -0600 (CST)
Subject: [LLVMbugs] [Bug 4946] tblgen generating insane function in cellspu
	dag isel
In-Reply-To: <bug-4946-206@http.llvm.org/bugs/>
References: <bug-4946-206@http.llvm.org/bugs/>
Message-ID: <20100301212217.D41AA2A6C12C@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #10 from Chris Lattner <clattner at apple.com> 2010-03-01 15:22:17 CST ---
Fixed by the new isel, 2.7 won't have this problem.

-- 
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 llvm.org  Mon Mar  1 15:25:00 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  1 Mar 2010 15:25:00 -0600 (CST)
Subject: [LLVMbugs] [Bug 5424] Sink SelectAddr into Emit_* functions
In-Reply-To: <bug-5424-206@http.llvm.org/bugs/>
References: <bug-5424-206@http.llvm.org/bugs/>
Message-ID: <20100301212500.E72BA2A6C12C@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #4 from Chris Lattner <clattner at apple.com> 2010-03-01 15:25:00 CST ---
The new isel doesn't have this code at all: problem defined away.

-- 
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 llvm.org  Mon Mar  1 15:26:00 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  1 Mar 2010 15:26:00 -0600 (CST)
Subject: [LLVMbugs] [Bug 5708] X86ISelDAGToDAG.ii is very to slow compile
	with llvm-g++
In-Reply-To: <bug-5708-206@http.llvm.org/bugs/>
References: <bug-5708-206@http.llvm.org/bugs/>
Message-ID: <20100301212600.230782A6C130@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #4 from Chris Lattner <clattner at apple.com> 2010-03-01 15:25:59 CST ---
Fixed:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20100301/097068.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 llvm.org  Mon Mar  1 15:38:04 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  1 Mar 2010 15:38:04 -0600 (CST)
Subject: [LLVMbugs] [Bug 1401] Targets should model flags explicitly
In-Reply-To: <bug-1401-206@http.llvm.org/bugs/>
References: <bug-1401-206@http.llvm.org/bugs/>
Message-ID: <20100301213804.4C05E2A6C12E@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #5 from Chris Lattner <clattner at apple.com> 2010-03-01 15:38:03 CST ---
I don't see a point of keeping this bug around anymore.

-- 
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 llvm.org  Mon Mar  1 15:39:26 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  1 Mar 2010 15:39:26 -0600 (CST)
Subject: [LLVMbugs] [Bug 3624] Tablegen incorrectly transoforming a pattern
In-Reply-To: <bug-3624-206@http.llvm.org/bugs/>
References: <bug-3624-206@http.llvm.org/bugs/>
Message-ID: <20100301213926.97C512A6C12D@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #6 from Chris Lattner <clattner at apple.com> 2010-03-01 15:39:26 CST ---
The relevant code is not used in mainline anymore, welcome to the brave new
isel world. :)

-- 
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 llvm.org  Mon Mar  1 15:41:29 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  1 Mar 2010 15:41:29 -0600 (CST)
Subject: [LLVMbugs] [Bug 6456] clang -fsyntax-only fails on something g++
	accepts [4]
In-Reply-To: <bug-6456-206@http.llvm.org/bugs/>
References: <bug-6456-206@http.llvm.org/bugs/>
Message-ID: <20100301214129.8219D2A6C133@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #1 from Douglas Gregor <dgregor at apple.com> 2010-03-01 15:41:29 CST ---
Clang is doing the right thing here; the "inline" is spurious.

-- 
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 llvm.org  Mon Mar  1 15:41:53 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  1 Mar 2010 15:41:53 -0600 (CST)
Subject: [LLVMbugs] [Bug 5993] infinite loop in backend on scheduling
	mem-to-mem
In-Reply-To: <bug-5993-206@http.llvm.org/bugs/>
References: <bug-5993-206@http.llvm.org/bugs/>
Message-ID: <20100301214153.91C932A6C131@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #8 from Chris Lattner <clattner at apple.com> 2010-03-01 15:41:53 CST ---
The new isel shouldn't make cyclic dags for stuff like 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 llvm.org  Mon Mar  1 16:09:46 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  1 Mar 2010 16:09:46 -0600 (CST)
Subject: [LLVMbugs] [Bug 2590] TableGen generates different output on
 different platforms
In-Reply-To: <bug-2590-206@http.llvm.org/bugs/>
References: <bug-2590-206@http.llvm.org/bugs/>
Message-ID: <20100301220946.3FD882A6C135@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #8 from Chris Lattner <clattner at apple.com> 2010-03-01 16:09:45 CST ---
Fixed:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20100301/097095.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 llvm.org  Mon Mar  1 16:07:08 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  1 Mar 2010 16:07:08 -0600 (CST)
Subject: [LLVMbugs] [Bug 1401] Targets should model flags explicitly
In-Reply-To: <bug-1401-206@http.llvm.org/bugs/>
References: <bug-1401-206@http.llvm.org/bugs/>
Message-ID: <20100301220708.F2AD72A6C12E@llvm.org>

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

Dan Gohman <gohman at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
                 CC|                            |gohman at apple.com
         Resolution|FIXED                       |

--- Comment #6 from Dan Gohman <gohman at apple.com> 2010-03-01 16:07:08 CST ---
MVT::Flag is over-conservative.  It's still desirable to replace it with more
precise physreg modeling.

-- 
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 llvm.org  Mon Mar  1 17:15:37 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  1 Mar 2010 17:15:37 -0600 (CST)
Subject: [LLVMbugs] [Bug 6382] use of undeclared label
In-Reply-To: <bug-6382-206@http.llvm.org/bugs/>
References: <bug-6382-206@http.llvm.org/bugs/>
Message-ID: <20100301231537.622C62A6C12E@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #1 from Douglas Gregor <dgregor at apple.com> 2010-03-01 17:15:37 CST ---
Fixed in r97518.

-- 
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 llvm.org  Mon Mar  1 17:32:57 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  1 Mar 2010 17:32:57 -0600 (CST)
Subject: [LLVMbugs] [Bug 4885] Warnings from compiling llvm with icc
In-Reply-To: <bug-4885-206@http.llvm.org/bugs/>
References: <bug-4885-206@http.llvm.org/bugs/>
Message-ID: <20100301233257.896F32A6C12E@llvm.org>

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

Erick Tryzelaar <idadesub at users.sourceforge.net> changed:

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

--- Comment #17 from Erick Tryzelaar <idadesub at users.sourceforge.net> 2010-03-01 17:32:56 CST ---
It's been a while since I tried to compile llvm with icc, and it turns out that
it rebroke. I'll close this and file some new bugs.

-- 
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 llvm.org  Mon Mar  1 17:49:45 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  1 Mar 2010 17:49:45 -0600 (CST)
Subject: [LLVMbugs] [Bug 6376] Assertion failed: ((Result ||
 isa<UsingShadowDecl>(D)) && "Unable to find instantiation of declaration!"),
 function FindInstantiatedDecl, file SemaTemplateInstantiateDecl.cpp,
 line 2306.
In-Reply-To: <bug-6376-206@http.llvm.org/bugs/>
References: <bug-6376-206@http.llvm.org/bugs/>
Message-ID: <20100301234945.E2E9F2A6C131@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #9 from Douglas Gregor <dgregor at apple.com> 2010-03-01 17:49:45 CST ---
Nice bug. Fixed again in r97524.

-- 
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 llvm.org  Mon Mar  1 19:00:44 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  1 Mar 2010 19:00:44 -0600 (CST)
Subject: [LLVMbugs] [Bug 4791] PassMananger can't use alternate
	AliasAnalysis with GVN
In-Reply-To: <bug-4791-206@http.llvm.org/bugs/>
References: <bug-4791-206@http.llvm.org/bugs/>
Message-ID: <20100302010044.A0F6F2A6C12C@llvm.org>

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

Dan Gohman <gohman at apple.com> changed:

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

--- Comment #2 from Dan Gohman <gohman at apple.com> 2010-03-01 19:00:44 CST ---
With 3323 being associated with -anders-aa, this bug is no longer a duplicate.

-- 
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 llvm.org  Mon Mar  1 19:13:15 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  1 Mar 2010 19:13:15 -0600 (CST)
Subject: [LLVMbugs] [Bug 6457] New: Clang fails to model explicitly created
 temporaries correctly
Message-ID: <bug-6457-206@http.llvm.org/bugs/>

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

           Summary: Clang fails to model explicitly created temporaries
                    correctly
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P5
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: chandlerc at gmail.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


The summary is based on the discussion with John and Doug about the cause of a
rather mysterious diagnostic for entirely valid C++ code. Here is the test case

chandlerc at osiris build % cat t.cc
template <typename T> struct X { explicit X(T* p = 0) { }; };
template <typename T> struct Y { Y(int, const T& x); };
struct A { };
template <typename T>
struct B {
  B() : y(0, X<A>()) { }
  Y<X<A> > y;
};
B<int> b;
chandlerc at osiris build % ./bin/clang -fsyntax-only t.cc
t.cc:6:9: error: no matching constructor for initialization of 'Y<X<struct A>
>'
  B() : y(0, X<A>()) { }
        ^
t.cc:9:8: note: in instantiation of member function 'B<int>::B' requested here
B<int> b;
       ^
t.cc:2:34: note: candidate constructor not viable: no known conversion from
'struct A *' to 'struct X<struct A> const' for 2nd argument
template <typename T> struct Y { Y(int, const T& x); };
                                 ^
t.cc:2:30: note: candidate constructor (the implicit copy constructor) not
viable: requires 1 argument, but 2 were provided
template <typename T> struct Y { Y(int, const T& x); };
                             ^
4 diagnostics generated.


After some digging and discussion, the root cause of the problem is that we are
somehow no longer building CXXTemporaryObjectExpr objects to represent explict
calls to constructors, and instead are building a CXXConstructCall, which as
Doug said, should actually be called CXXImplicitConstructCall or some such. In
fact, we never construct CXXTemporaryObjectExprs any more, probably a bad sign.
;]

-- 
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 llvm.org  Mon Mar  1 19:18:55 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  1 Mar 2010 19:18:55 -0600 (CST)
Subject: [LLVMbugs] [Bug 1754] Bunch of small memory leaks in LLVM
In-Reply-To: <bug-1754-206@http.llvm.org/bugs/>
References: <bug-1754-206@http.llvm.org/bugs/>
Message-ID: <20100302011855.9490C2A6C12D@llvm.org>

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

Dan Gohman <gohman at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |gohman at apple.com
         Resolution|                            |FIXED

--- Comment #3 from Dan Gohman <gohman at apple.com> 2010-03-01 19:18:54 CST ---
The problems have been fixed; llc is now valgrind-clean on the testcase.

-- 
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 llvm.org  Mon Mar  1 19:30:19 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  1 Mar 2010 19:30:19 -0600 (CST)
Subject: [LLVMbugs] [Bug 6383] use of undeclared identifier
In-Reply-To: <bug-6383-206@http.llvm.org/bugs/>
References: <bug-6383-206@http.llvm.org/bugs/>
Message-ID: <20100302013019.16D122A6C124@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #1 from Douglas Gregor <dgregor at apple.com> 2010-03-01 19:30:18 CST ---
Fixed in r97534.

-- 
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 llvm.org  Mon Mar  1 19:36:39 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  1 Mar 2010 19:36:39 -0600 (CST)
Subject: [LLVMbugs] [Bug 5812] clang fails to find dependent base class when
 it's referenced via Derived::
In-Reply-To: <bug-5812-206@http.llvm.org/bugs/>
References: <bug-5812-206@http.llvm.org/bugs/>
Message-ID: <20100302013639.B30112A6C12E@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #1 from Douglas Gregor <dgregor at apple.com> 2010-03-01 19:36:39 CST ---
This is working as of r97535.

-- 
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 llvm.org  Mon Mar  1 20:00:02 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  1 Mar 2010 20:00:02 -0600 (CST)
Subject: [LLVMbugs] [Bug 6453] LSR produces invalid IR
In-Reply-To: <bug-6453-206@http.llvm.org/bugs/>
References: <bug-6453-206@http.llvm.org/bugs/>
Message-ID: <20100302020002.8C6882A6C124@llvm.org>

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

Dan Gohman <gohman at apple.com> changed:

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

--- Comment #5 from Dan Gohman <gohman at apple.com> 2010-03-01 20:00:02 CST ---
Fixed in r97537.

-- 
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 llvm.org  Mon Mar  1 20:16:54 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  1 Mar 2010 20:16:54 -0600 (CST)
Subject: [LLVMbugs] [Bug 6438] many functions that call
 SelectionDAG::ComputeMaskedBits are broken with respect to vectors
In-Reply-To: <bug-6438-206@http.llvm.org/bugs/>
References: <bug-6438-206@http.llvm.org/bugs/>
Message-ID: <20100302021654.EA9EB2A6C12C@llvm.org>

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

Dan Gohman <gohman at apple.com> changed:

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

--- Comment #3 from Dan Gohman <gohman at apple.com> 2010-03-01 20:16:54 CST ---
Patch applied to trunk in 97538.

In the future, please send "diff -u" patches, such as those produced by svn
diff or diff -u.  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 llvm.org  Mon Mar  1 20:19:20 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  1 Mar 2010 20:19:20 -0600 (CST)
Subject: [LLVMbugs] [Bug 6334] x86 cannot select sign_extend_inreg on vector
	types
In-Reply-To: <bug-6334-206@http.llvm.org/bugs/>
References: <bug-6334-206@http.llvm.org/bugs/>
Message-ID: <20100302021920.66F2D2A6C12C@llvm.org>

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

Dan Gohman <gohman at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |gohman at apple.com
         Resolution|                            |WORKSFORME

--- Comment #1 from Dan Gohman <gohman at apple.com> 2010-03-01 20:19:20 CST ---
The testcase works for me, x86 and x86-64, with and without -disable-mmx.

-- 
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 llvm.org  Mon Mar  1 21:36:09 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  1 Mar 2010 21:36:09 -0600 (CST)
Subject: [LLVMbugs] [Bug 4380] __builtin_object_size
In-Reply-To: <bug-4380-206@http.llvm.org/bugs/>
References: <bug-4380-206@http.llvm.org/bugs/>
Message-ID: <20100302033609.8E3412A6C12E@llvm.org>

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

Eric Christopher <echristo at gmail.com> changed:

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

--- Comment #10 from Eric Christopher <echristo at gmail.com> 2010-03-01 21:36:09 CST ---
Fixed now.

-- 
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 llvm.org  Mon Mar  1 23:07:27 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  1 Mar 2010 23:07:27 -0600 (CST)
Subject: [LLVMbugs] [Bug 6388] AC_HUGE_VAL_CHECK overwrite CXXFLAGS
In-Reply-To: <bug-6388-206@http.llvm.org/bugs/>
References: <bug-6388-206@http.llvm.org/bugs/>
Message-ID: <20100302050727.A197B2A6C12D@llvm.org>

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

Eric Christopher <echristo at gmail.com> changed:

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

--- Comment #1 from Eric Christopher <echristo at gmail.com> 2010-03-01 23:07:27 CST ---
Applied thusly:

[ghostwheel:~/sources/llvm] echristo% svn ci configure autoconf/m4/huge_val.m4 
Sending        autoconf/m4/huge_val.m4
Sending        configure
Transmitting file data ..
Committed revision 97548.


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 llvm.org  Mon Mar  1 23:17:48 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  1 Mar 2010 23:17:48 -0600 (CST)
Subject: [LLVMbugs] [Bug 6267] Documentation path is weird
In-Reply-To: <bug-6267-206@http.llvm.org/bugs/>
References: <bug-6267-206@http.llvm.org/bugs/>
Message-ID: <20100302051748.69C2D2A6C12C@llvm.org>

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

Eric Christopher <echristo at gmail.com> changed:

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

--- Comment #5 from Eric Christopher <echristo at gmail.com> 2010-03-01 23:17:48 CST ---
Fixed with this commit:

[ghostwheel:~/sources/llvm] echristo% svn ci configure autoconf/configure.ac
Sending        autoconf/configure.ac
Sending        configure
Transmitting file data ..
Committed revision 97549.

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 llvm.org  Tue Mar  2 00:27:07 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  2 Mar 2010 00:27:07 -0600 (CST)
Subject: [LLVMbugs] [Bug 5309] incorrect __SOFTFP__ breaks build on ARM
In-Reply-To: <bug-5309-206@http.llvm.org/bugs/>
References: <bug-5309-206@http.llvm.org/bugs/>
Message-ID: <20100302062707.8971C2A6C12E@llvm.org>

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

Eric Christopher <echristo at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |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 llvm.org  Tue Mar  2 03:47:06 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  2 Mar 2010 03:47:06 -0600 (CST)
Subject: [LLVMbugs] [Bug 6458] New: clang++ emits T while g++ emits U symbol
Message-ID: <bug-6458-206@http.llvm.org/bugs/>

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

           Summary: clang++ emits T while g++ emits U symbol
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: rdivacky at freebsd.org
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


pes delta$ clang++ -c locale-inst.cc && nm locale-inst.o | grep _M_compare

   .... warnings ....

4 diagnostics generated.
0000000000000000 T _ZNKSt7collateIcE10_M_compareEPKcS2_

pes delta$ g++ -c locale-inst.cc && nm locale-inst.o | grep _M_compare
                 U _ZNKSt7collateIcE10_M_compareEPKcS2_

-- 
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 llvm.org  Tue Mar  2 06:25:45 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  2 Mar 2010 06:25:45 -0600 (CST)
Subject: [LLVMbugs] [Bug 5309] incorrect __SOFTFP__ breaks build on ARM
In-Reply-To: <bug-5309-206@http.llvm.org/bugs/>
References: <bug-5309-206@http.llvm.org/bugs/>
Message-ID: <20100302122545.474462A6C12E@llvm.org>

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

Xerxes R?nby <xerxes at zafena.se> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
                 CC|                            |xerxes at zafena.se
         Resolution|FIXED                       |

--- Comment #3 from Xerxes R?nby <xerxes at zafena.se> 2010-03-02 06:25:44 CST ---
this change broke the armv5tejl (softfloat) buildbot 
http://llvm.org/viewvc/llvm-project/?view=rev&revision=97554

can we redesign this to work with SOFTFP machines as well?

llvm[3]: Compiling ARMJITInfo.cpp for Debug build
/tmp/ccA22Bpb.s: Assembler messages:
/tmp/ccA22Bpb.s:26: Error: selected processor does not support `fstmfdd
sp!,{d0,d1,d2,d3,d4,d5,d6,d7}'
/tmp/ccA22Bpb.s:31: Error: selected processor does not support `fldmfdd
sp!,{d0,d1,d2,d3,d4,d5,d6,d7}'
make[3]: ***
[/wd/buildbot/llvm-arm-linux/llvm/lib/Target/ARM/Debug/ARMJITInfo.o] Error 1
make[3]: Leaving directory `/wd/buildbot/llvm-arm-linux/llvm/lib/Target/ARM'
make[2]: *** [ARM/.makeall] 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 llvm.org  Tue Mar  2 07:28:41 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  2 Mar 2010 07:28:41 -0600 (CST)
Subject: [LLVMbugs] [Bug 5309] incorrect __SOFTFP__ breaks build on ARM
In-Reply-To: <bug-5309-206@http.llvm.org/bugs/>
References: <bug-5309-206@http.llvm.org/bugs/>
Message-ID: <20100302132841.D50FA2A6C12E@llvm.org>

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

Xerxes R?nby <xerxes at zafena.se> changed:

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

--- Comment #5 from Xerxes R?nby <xerxes at zafena.se> 2010-03-02 07:28:41 CST ---
Fix pushed hopefully this resolves all VFP and SOFTFP variants.
http://llvm.org/viewvc/llvm-project?view=rev&revision=97564

-- 
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 llvm.org  Tue Mar  2 09:25:25 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  2 Mar 2010 09:25:25 -0600 (CST)
Subject: [LLVMbugs] [Bug 6459] New: Assertion failed:
 (DD->getOperatorDelete() && "operator delete missing - EmitDtorEpilogue"),
 function EmitDtorEpilogue, file CGClass.cpp, line 1116.
Message-ID: <bug-6459-206@http.llvm.org/bugs/>

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

           Summary: Assertion failed: (DD->getOperatorDelete() &&
                    "operator delete missing - EmitDtorEpilogue"),
                    function EmitDtorEpilogue, file CGClass.cpp, line
                    1116.
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: ich at az2000.de
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


[ 28%] Building CXX object CMakeFiles/openlierox.dir/src/common/CWorm.o
Assertion failed: (DD->getOperatorDelete() && "operator delete missing -
EmitDtorEpilogue"), function EmitDtorEpilogue, file CGClass.cpp, line 1116.
0  clang             0x00edd1a0 main + 15560074
1  clang             0x00edd60a main + 15561204
2  libSystem.B.dylib 0x954282bb _sigtramp + 43
3  libSystem.B.dylib 0xffffffff _sigtramp + 1790803311
4  libSystem.B.dylib 0x9549c23a raise + 26
5  libSystem.B.dylib 0x954a8679 abort + 73
6  libSystem.B.dylib 0x9549d3db __assert_rtn + 101
7  clang             0x0013ffa6 main + 1285008
8  clang             0x0014096c main + 1287510
9  clang             0x001f35e4 main + 2019790
10 clang             0x00134bf7 main + 1239009
11 clang             0x001fbc7e main + 2054248
12 clang             0x001fbdd4 main + 2054590
13 clang             0x001fc02c main + 2055190
14 clang             0x002133a6 main + 2150288
15 clang             0x0001f3fc main + 102374
16 clang             0x00220154 main + 2202942
17 clang             0x0003f784 main + 234350
18 clang             0x0003f674 main + 234078
19 clang             0x00020f3b main + 109349
20 clang             0x00002a14 _mh_execute_header + 6676
21 clang             0x000064ff main + 233
22 clang             0x00001936 _mh_execute_header + 2358
23 clang             0x00000033 _mh_execute_header + 18446744073709547571
Stack dump:
0.    Program arguments:
/Users/az/Programmierung/CppIDE/llvm-src/Debug/bin/clang -cc1 -triple
i386-apple-darwin9.0.0 -S -disable-free -main-file-name CWorm.cpp -pic-level 1
-mdisable-fp-elim -target-cpu yonah -g -resource-dir
/Users/az/Programmierung/CppIDE/llvm-src/Debug/lib/clang/1.1 -DDEBUG=1
-D_AI_DEBUG -D SYSTEM_DATA_DIR="/usr/share/games"
-I/Users/az/Programmierung/openlierox/./optional-includes/generated
-I/Users/az/Programmierung/openlierox/./include
-I/Users/az/Programmierung/openlierox/./src
-I/Users/az/Programmierung/openlierox/./libs/pstreams -I/usr/include/libxml2
-I/usr/local/include/libxml2
-I/Users/az/Programmierung/openlierox/./libs/breakpad/src
-I/Users/az/Programmierung/openlierox/./libs/hawknl/include
-I/Users/az/Programmierung/openlierox/./libs/libzip
-I/Users/az/Programmierung/openlierox/./libs/lua
-I/Users/az/Programmierung/openlierox/./build/Xcode/include
-I/Users/az/Programmierung/openlierox/./build/Xcode/freealut/include
-I/Library/Frameworks/SDL.framework/Headers
-I/Library/Frameworks/SDL_image.framework/Headers
-I/Library/Frameworks/SDL_mixer.framework/Headers
-I/Library/Frameworks/UnixImageIO.framework/Headers
-I/Library/Frameworks/GD.framework/Headers -F ./build/Xcode
-F/Library/Frameworks -Wall -fmessage-length 84 -pthread -fexceptions
-fdiagnostics-show-option -fcolor-diagnostics -o
/var/folders/P9/P9wWY+Z8HDeOPixVmDZ0J++++TI/-Tmp-/cc-mmfFCw.s -x c++
/Users/az/Programmierung/openlierox/src/common/CWorm.cpp 
1.    <eof> parser at end of file
2.    Per-file LLVM IR generation
3.    /Users/az/Programmierung/openlierox/src/common/CWorm.cpp:42:15:
Generating code for declaration 'CWorm::SkinDynDrawer::~SkinDynDrawer'
clang: error: compiler command failed due to signal 6 (use -v to see
invocation)
make[2]: *** [CMakeFiles/openlierox.dir/src/common/CWorm.o] Error 250
make[1]: *** [CMakeFiles/openlierox.dir/all] 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 llvm.org  Tue Mar  2 09:49:36 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  2 Mar 2010 09:49:36 -0600 (CST)
Subject: [LLVMbugs] [Bug 6460] New: Codegen aborts
Message-ID: <bug-6460-206@http.llvm.org/bugs/>

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

           Summary: Codegen aborts
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: rafael.espindola at gmail.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


./llvm-build/Debug/bin/clang -cc1 -S test.ii
clang:
/usr/local/google/home/espindola/llvm/llvm/include/llvm/Support/Casting.h:200:
typename llvm::cast_retty<To, From>::ret_type llvm::cast(const Y&) [with X =
clang::VarDecl, Y = const clang::NamedDecl*]: Assertion `isa<X>(Val) &&
"cast<Ty>() argument of incompatible 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 llvm.org  Tue Mar  2 10:47:24 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  2 Mar 2010 10:47:24 -0600 (CST)
Subject: [LLVMbugs] [Bug 6461] New: wrong error: functions that differ only
 in their return type cannot be overloaded
Message-ID: <bug-6461-206@http.llvm.org/bugs/>

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

           Summary: wrong error: functions that differ only in their
                    return type cannot be overloaded
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: ich at az2000.de
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


In file included from
/Users/az/Programmierung/openlierox/src/common/Process.cpp:83:
/Users/az/Programmierung/openlierox/./libs/pstreams/pstream.h:1742:28: error: 
      functions that differ only in their return type cannot be overloaded
    basic_pstreambuf<C,T>::wpipe()
                           ^
/Users/az/Programmierung/openlierox/./libs/pstreams/pstream.h:221:7: note:
previous
      declaration is here
      wpipe();
      ^


The bug is, that the first occurance is only the declaration and the second one
the definition of the declaration.

The code seems correct and valid to me. Also, all versions of GCC I have tried
so far (I think GCC 3.4, several 4.*) accept this code.

-- 
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 llvm.org  Tue Mar  2 10:53:12 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  2 Mar 2010 10:53:12 -0600 (CST)
Subject: [LLVMbugs] [Bug 6462] New: wrong(?) error: member 'rdbuf' found in
 multiple base classes of different types
Message-ID: <bug-6462-206@http.llvm.org/bugs/>

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

           Summary: wrong(?) error: member 'rdbuf' found in multiple base
                    classes of different types
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: ich at az2000.de
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


/Users/az/Programmierung/openlierox/src/common/Process.cpp:96:9: error: member
      'rdbuf' found in multiple base classes of different types
                if(p->rdbuf()) p->rdbuf()->kill();
                      ^
In file included from
/Users/az/Programmierung/openlierox/src/common/Process.cpp:11:
In file included from
/Users/az/Programmierung/openlierox/./include/Process.h:13:
In file included from /usr/include/c++/4.0.0/iostream:43:
In file included from /usr/include/c++/4.0.0/ostream:43:
In file included from /usr/include/c++/4.0.0/ios:49:
/usr/include/c++/4.0.0/bits/basic_ios.h:306:7: note: member found by ambiguous
name
      lookup
      rdbuf() const
      ^
In file included from
/Users/az/Programmierung/openlierox/src/common/Process.cpp:83:
/Users/az/Programmierung/openlierox/./libs/pstreams/pstream.h:315:7: note:
member
      found by ambiguous name lookup
      rdbuf() const;
      ^


I am not exactly sure about this. Maybe the clang error is valid.

The point is that all GCC versions I have tried so far accept it. And I think
ICC too.

-- 
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 llvm.org  Tue Mar  2 10:55:30 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  2 Mar 2010 10:55:30 -0600 (CST)
Subject: [LLVMbugs] [Bug 1675] instcombine neg(zext(bool)) to sext(bool)
In-Reply-To: <bug-1675-206@http.llvm.org/bugs/>
References: <bug-1675-206@http.llvm.org/bugs/>
Message-ID: <20100302165530.93A822A6C12E@llvm.org>

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

Alastair Lynn <arplynn at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |arplynn at gmail.com
         Resolution|                            |FIXED

--- Comment #3 from Alastair Lynn <arplynn at gmail.com> 2010-03-02 10:55:30 CST ---
All of these transformations are now done apart from
select bool X, -1, 0    -> sext from bool
where the reverse is done.

-- 
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 llvm.org  Tue Mar  2 11:03:19 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  2 Mar 2010 11:03:19 -0600 (CST)
Subject: [LLVMbugs] [Bug 6463] New: crash in clang::Type::getTypeClass()
Message-ID: <bug-6463-206@http.llvm.org/bugs/>

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

           Summary: crash in clang::Type::getTypeClass()
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: ich at az2000.de
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


Process:         clang [94528]
Path:            /Users/az/Programmierung/CppIDE/llvm-src/Debug/bin/clang
Identifier:      clang
Version:         ??? (???)
Code Type:       X86 (Native)
Parent Process:  clang++ [94527]

Interval Since Last Report:          5899 sec
Crashes Since Last Report:           2
Per-App Interval Since Last Report:  0 sec
Per-App Crashes Since Last Report:   2

Date/Time:       2010-03-02 18:02:27.652 +0100
OS Version:      Mac OS X 10.5.8 (9L30)
Report Version:  6
Anonymous UUID:  C99325D9-953E-44CB-A0FE-88CB8BF0B517

Exception Type:  EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000008
Crashed Thread:  0

Application Specific Information:
Stack dump:
0.    Program arguments:
/Users/az/Programmierung/CppIDE/llvm-src/Debug/bin/clang -cc1 -triple
i386-apple-darwin9.0.0 -S -disable-free -main-file-name test.cpp -pic-level 1
-mdisable-fp-elim -target-cpu yonah -resource-dir
/Users/az/Programmierung/CppIDE/llvm-src/Debug/lib/clang/1.1 -fmessage-length
84 -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o
/var/folders/P9/P9wWY+Z8HDeOPixVmDZ0J++++TI/-Tmp-/cc-iGRXbn.s -x c++ test.cpp 
1.    test.cpp:8:32: current parser token '{'


Thread 0 Crashed:
0   clang                             0x0005f7ed clang::Type::getTypeClass()
const + 9
1   clang                             0x0009f99d
clang::TypeLoc::getTypeLocClass() const + 77
2   clang                             0x0058183e
clang::TypeLocVisitor<(anonymous namespace)::NextLoc,
clang::TypeLoc>::Visit(clang::TypeLoc) + 24
3   clang                             0x0057d3f5
clang::TypeLoc::getNextTypeLocImpl(clang::TypeLoc) + 31
4   clang                             0x004e610a
clang::TypeLoc::getNextTypeLoc() const + 26
5   clang                             0x0035257e
clang::TypeLocBuilder::pushImpl(clang::QualType, unsigned long) + 50
6   clang                             0x00358409 clang::TypenameTypeLoc
clang::TypeLocBuilder::push<clang::TypenameTypeLoc>(clang::QualType) + 79
7   clang                             0x0035141d (anonymous
namespace)::CurrentInstantiationRebuilder::TransformTypenameType(clang::TypeLocBuilder&,
clang::TypenameTypeLoc, clang::QualType) + 727
8   clang                             0x0035af56
clang::TreeTransform<(anonymous
namespace)::CurrentInstantiationRebuilder>::TransformType(clang::TypeLocBuilder&,
clang::TypeLoc, clang::QualType) + 2248
9   clang                             0x0035b0ad
clang::TreeTransform<(anonymous
namespace)::CurrentInstantiationRebuilder>::TransformType(clang::TypeSourceInfo*,
clang::QualType) + 161
10  clang                             0x0035b1b0
clang::TreeTransform<(anonymous
namespace)::CurrentInstantiationRebuilder>::TransformType(clang::QualType,
clang::QualType) + 178
11  clang                             0x0035113d
clang::Sema::RebuildTypeInCurrentInstantiation(clang::QualType,
clang::SourceLocation, clang::DeclarationName) + 141
12  clang                             0x0026d48a
clang::Sema::HandleDeclarator(clang::Scope*, clang::Declarator&,
clang::ASTMultiPtr<&(clang::ActionBase::DeleteTemplateParams(void*))>, bool) +
696
13  clang                             0x00347455
clang::Sema::ActOnStartOfFunctionTemplateDef(clang::Scope*,
clang::ASTMultiPtr<&(clang::ActionBase::DeleteTemplateParams(void*))>,
clang::Declarator&) + 307
14  clang                             0x005d5f03
clang::Parser::ParseFunctionDefinition(clang::Parser::ParsingDeclarator&,
clang::Parser::ParsedTemplateInfo const&) + 773 (Parser.cpp:674)
15  clang                             0x005ce67f
clang::Parser::ParseSingleDeclarationAfterTemplate(unsigned int,
clang::Parser::ParsedTemplateInfo const&, clang::SourceLocation&,
clang::AccessSpecifier) + 1273 (ParseTemplate.cpp:256)
16  clang                             0x005cf415
clang::Parser::ParseTemplateDeclarationOrSpecialization(unsigned int,
clang::SourceLocation&, clang::AccessSpecifier) + 1009 (ParseTemplate.cpp:155)
17  clang                             0x005cf500
clang::Parser::ParseDeclarationStartingWithTemplate(unsigned int,
clang::SourceLocation&, clang::AccessSpecifier) + 178 (ParseTemplate.cpp:32)
18  clang                             0x005992d8
clang::Parser::ParseDeclaration(unsigned int, clang::SourceLocation&,
clang::CXX0XAttributeList) + 330
19  clang                             0x005d5281
clang::Parser::ParseExternalDeclaration(clang::CXX0XAttributeList) + 2067
(Parser.cpp:478)
20  clang                             0x005d54b6
clang::Parser::ParseTopLevelDecl(clang::OpaquePtr<1>&) + 296 (Parser.cpp:368)
21  clang                             0x00220082
clang::ParseAST(clang::Preprocessor&, clang::ASTConsumer*, clang::ASTContext&,
bool, bool, clang::CodeCompleteConsumer*) + 426
22  clang                             0x0003f784
clang::ASTFrontendAction::ExecuteAction() + 266
23  clang                             0x0003f674
clang::FrontendAction::Execute() + 260
24  clang                             0x00020f3b
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 851
25  clang                             0x00002a14 cc1_main(char const**, char
const**, char const*, void*) + 1292
26  clang                             0x000064ff main + 233 (driver.cpp:179)
27  clang                             0x00001936 start + 54

Thread 0 crashed with X86 Thread State (32-bit):
  eax: 0x00000000  ebx: 0x00581832  ecx: 0xbfffd42f  edx: 0x00000000
  edi: 0x00347322  esi: 0x03839e98  ebp: 0xbfffd398  esp: 0xbfffd390
   ss: 0x0000001f  efl: 0x00010286  eip: 0x0005f7ed   cs: 0x00000017
   ds: 0x0000001f   es: 0x0000001f   fs: 0x00000000   gs: 0x00000037
  cr2: 0x00000008

Binary Images:
    0x1000 -  0x10acfdb +clang ??? (???) <ff262ec1d904824f62f3dced89cb48ea>
/Users/az/Programmierung/CppIDE/llvm-src/Debug/bin/clang
0x8fe00000 - 0x8fe2db43  dyld 97.1 (???) <458eed38a009e5658a79579e7bc26603>
/usr/lib/dyld
0x90dcc000 - 0x90dd0fff  libmathCommon.A.dylib ??? (???)
/usr/lib/system/libmathCommon.A.dylib
0x9250c000 - 0x92569ffb  libstdc++.6.dylib ??? (???)
<04b812dcec670daa8b7d2852ab14be60> /usr/lib/libstdc++.6.dylib
0x953bb000 - 0x95522ff3  libSystem.B.dylib ??? (???)
<ae47ca9b1686b065f8ac4d2de09cc432> /usr/lib/libSystem.B.dylib
0x959c5000 - 0x959ccfe9  libgcc_s.1.dylib ??? (???)
<f53c808e87d1184c0f9df63aef53ce0b> /usr/lib/libgcc_s.1.dylib
0xffff0000 - 0xffff1780  libSystem.B.dylib ??? (???) /usr/lib/libSystem.B.dylib

-- 
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 llvm.org  Tue Mar  2 11:19:51 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  2 Mar 2010 11:19:51 -0600 (CST)
Subject: [LLVMbugs] [Bug 6457] Clang fails to model explicitly created
 temporaries correctly
In-Reply-To: <bug-6457-206@http.llvm.org/bugs/>
References: <bug-6457-206@http.llvm.org/bugs/>
Message-ID: <20100302171951.4C4852A6C12D@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #2 from Douglas Gregor <dgregor at apple.com> 2010-03-02 11:19:50 CST ---
Fixed in r97568.

-- 
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 llvm.org  Tue Mar  2 11:22:31 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  2 Mar 2010 11:22:31 -0600 (CST)
Subject: [LLVMbugs] [Bug 6459] Assertion failed: (DD->getOperatorDelete() &&
 "operator delete missing - EmitDtorEpilogue"), function EmitDtorEpilogue,
 file CGClass.cpp, line 1116.
In-Reply-To: <bug-6459-206@http.llvm.org/bugs/>
References: <bug-6459-206@http.llvm.org/bugs/>
Message-ID: <20100302172231.15E6A2A6C12F@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #4 from Douglas Gregor <dgregor at apple.com> 2010-03-02 11:22:30 CST ---


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

-- 
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 llvm.org  Tue Mar  2 11:32:10 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  2 Mar 2010 11:32:10 -0600 (CST)
Subject: [LLVMbugs] [Bug 4398] passManager should always call releaseMemory
 to avoid use-after-free bugs
In-Reply-To: <bug-4398-206@http.llvm.org/bugs/>
References: <bug-4398-206@http.llvm.org/bugs/>
Message-ID: <20100302173210.5B0042A6C12D@llvm.org>

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

T?r?k Edwin <edwintorok at gmail.com> changed:

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

--- Comment #6 from T?r?k Edwin <edwintorok at gmail.com> 2010-03-02 11:32:09 CST ---
(In reply to comment #5)
> The patch is applied, right? Is this bug fixed?

I should've closed the bug after applying the patch, thanks for reminding.

-- 
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 llvm.org  Tue Mar  2 11:53:43 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  2 Mar 2010 11:53:43 -0600 (CST)
Subject: [LLVMbugs] [Bug 5786] Assertion failed: (!E->isValueDependent() &&
 "Should not see value dependent exprs!")
In-Reply-To: <bug-5786-206@http.llvm.org/bugs/>
References: <bug-5786-206@http.llvm.org/bugs/>
Message-ID: <20100302175343.16F742A6C12D@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #1 from Douglas Gregor <dgregor at apple.com> 2010-03-02 11:53:42 CST ---
Fixed in r97570

-- 
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 llvm.org  Tue Mar  2 12:26:57 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  2 Mar 2010 12:26:57 -0600 (CST)
Subject: [LLVMbugs] [Bug 6311] clang++ -fsyntax-only crash
In-Reply-To: <bug-6311-206@http.llvm.org/bugs/>
References: <bug-6311-206@http.llvm.org/bugs/>
Message-ID: <20100302182657.5CFD12A6C12E@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #2 from Douglas Gregor <dgregor at apple.com> 2010-03-02 12:26:56 CST ---
We fixed problems in this area a week or two ago; this is no longer crashing.

-- 
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 llvm.org  Tue Mar  2 12:30:48 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  2 Mar 2010 12:30:48 -0600 (CST)
Subject: [LLVMbugs] [Bug 6430] Ran out of registers during register
 allocation for vfwprintf
In-Reply-To: <bug-6430-206@http.llvm.org/bugs/>
References: <bug-6430-206@http.llvm.org/bugs/>
Message-ID: <20100302183048.43E9F2A6C12F@llvm.org>

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

Jakob Stoklund Olesen <stoklund at 2pi.dk> changed:

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

--- Comment #1 from Jakob Stoklund Olesen <stoklund at 2pi.dk> 2010-03-02 12:30:47 CST ---
I cannot reproduce with TOT. Please verify, or provide the failing command.

-- 
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 llvm.org  Tue Mar  2 12:33:40 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  2 Mar 2010 12:33:40 -0600 (CST)
Subject: [LLVMbugs] [Bug 6260] -regalloc=linearscan -O0 crash - assertion
 "Ran out of registers during register allocation!"
In-Reply-To: <bug-6260-206@http.llvm.org/bugs/>
References: <bug-6260-206@http.llvm.org/bugs/>
Message-ID: <20100302183340.03CB22A6C12D@llvm.org>

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

Jakob Stoklund Olesen <stoklund at 2pi.dk> changed:

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

--- Comment #4 from Jakob Stoklund Olesen <stoklund at 2pi.dk> 2010-03-02 12:33:39 CST ---
This no longer reproduces on TOT. Please verify.

-- 
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 llvm.org  Tue Mar  2 12:49:45 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  2 Mar 2010 12:49:45 -0600 (CST)
Subject: [LLVMbugs] [Bug 6064] Assertion failure synthesizing an implicitly
 defined copy constructor
In-Reply-To: <bug-6064-206@http.llvm.org/bugs/>
References: <bug-6064-206@http.llvm.org/bugs/>
Message-ID: <20100302184945.055A42A6C12D@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #1 from Douglas Gregor <dgregor at apple.com> 2010-03-02 12:49:44 CST ---
This seems to be fixed now.

-- 
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 llvm.org  Tue Mar  2 12:53:15 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  2 Mar 2010 12:53:15 -0600 (CST)
Subject: [LLVMbugs] [Bug 6350] Compiler assert on valid code
In-Reply-To: <bug-6350-206@http.llvm.org/bugs/>
References: <bug-6350-206@http.llvm.org/bugs/>
Message-ID: <20100302185315.472A42A6C12D@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #1 from Douglas Gregor <dgregor at apple.com> 2010-03-02 12:53:14 CST ---
This is the same assertion as 6100 on very, very similar code.

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

-- 
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 llvm.org  Tue Mar  2 13:07:38 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  2 Mar 2010 13:07:38 -0600 (CST)
Subject: [LLVMbugs] [Bug 6430] Ran out of registers during register
 allocation for vfwprintf
In-Reply-To: <bug-6430-206@http.llvm.org/bugs/>
References: <bug-6430-206@http.llvm.org/bugs/>
Message-ID: <20100302190738.21CE52A6C12F@llvm.org>

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

Sergey Yakoushkin <sergey.yakoushkin at gmail.com> changed:

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

--- Comment #2 from Sergey Yakoushkin <sergey.yakoushkin at gmail.com> 2010-03-02 13:07:37 CST ---
llc ./bugpoint-reduced-simplified.bc -relocation-model=pic

-- 
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 llvm.org  Tue Mar  2 13:12:19 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  2 Mar 2010 13:12:19 -0600 (CST)
Subject: [LLVMbugs] [Bug 6464] New: Assertion failed: (D->isOutOfLine())
Message-ID: <bug-6464-206@http.llvm.org/bugs/>

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

           Summary: Assertion failed: (D->isOutOfLine())
           Product: clang
           Version: trunk
          Platform: Other
        OS/Version: FreeBSD
            Status: NEW
          Severity: normal
          Priority: P5
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: hinokind at gmail.com
                CC: llvmbugs at cs.uiuc.edu


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

$ cat assert12.cc 
template <class Y> class foo {}
bool foo<X>::bar( a )


$ clang assert12.cc 
assert12.cc:1:32: error: expected ';' after class
template <class Y> class foo {}
                               ^
                               ;
assert12.cc:2:10: error: use of undeclared identifier 'X'
bool foo<X>::bar( a )
         ^
assert12.cc:2:14: error: definition or redeclaration of 'bar' cannot name the
global scope
bool foo<X>::bar( a )
           ~~^
assert12.cc:2:14: error: no member named 'bar' in the global namespace
bool foo<X>::bar( a )
           ~~^
Assertion failed: (D->isOutOfLine()), function ActOnCXXEnterDeclInitializer,
file SemaDeclCXX.cpp, line 5743.
Stack dump:
0.    Program arguments: /usr/local/bin/clang -cc1 -triple
x86_64-segfault-freebsd8.0 -S -disable-free -main-file-name assert12.cc
-mrelocation-model static -mdisable-fp-elim -mconstructor-aliases
-munwind-tables -target-cpu x86-64 -resource-dir /usr/local/lib/clang/1.1
-fmessage-length 157 -fexceptions -fgnu-runtime -fdiagnostics-show-option
-fcolor-diagnostics -o /tmp/cc-eEcJ7Z.s -x c++ assert12.cc 
1.    assert12.cc:2:19: current parser token 'a'
clang: error: compiler command failed due to signal 6 (use -v to see
invocation)


$ clang --version
clang version 1.1 (trunk 97574)
Target: x86_64-segfault-freebsd8.0
Thread model: posix

-- 
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 llvm.org  Tue Mar  2 13:15:09 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  2 Mar 2010 13:15:09 -0600 (CST)
Subject: [LLVMbugs] [Bug 6301] template instantiation limit too low?
In-Reply-To: <bug-6301-206@http.llvm.org/bugs/>
References: <bug-6301-206@http.llvm.org/bugs/>
Message-ID: <20100302191509.C92D82A6C130@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #1 from Douglas Gregor <dgregor at apple.com> 2010-03-02 13:15:09 CST ---
GCC uses a default template depth of 500. I've changed Clang to do the same in
r97579.

-- 
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 llvm.org  Tue Mar  2 13:25:12 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  2 Mar 2010 13:25:12 -0600 (CST)
Subject: [LLVMbugs] [Bug 6465] New: DAGCombiner/SelectionDAG are not safe
 when using vectors
Message-ID: <bug-6465-206@http.llvm.org/bugs/>

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

           Summary: DAGCombiner/SelectionDAG are not safe when using
                    vectors
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: Common Code Generator Code
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: micah.villmow at amd.com
                CC: llvmbugs at cs.uiuc.edu


Akin to Bugs 6438/6335 there is a mismatch when passing in arguments to certain
functions that expect the bitsize between the scalar components to be
equivalent. However the calling function passes in the bitsize of the vector
instead of the scalartype.

-- 
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 llvm.org  Tue Mar  2 14:36:46 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  2 Mar 2010 14:36:46 -0600 (CST)
Subject: [LLVMbugs] [Bug 6466] New: Assertion failed:
	(BaseType->isPointerType())
Message-ID: <bug-6466-206@http.llvm.org/bugs/>

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

           Summary: Assertion failed: (BaseType->isPointerType())
           Product: clang
           Version: trunk
          Platform: Other
        OS/Version: FreeBSD
            Status: NEW
          Keywords: crash-on-invalid
          Severity: normal
          Priority: P5
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: hinokind at gmail.com
                CC: llvmbugs at cs.uiuc.edu


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

$ clang assert13.cc
<...>
Assertion failed: (BaseType->isPointerType()), function
BuildMemberReferenceExpr, file SemaExpr.cpp, line 2544.
Stack dump:
0.    Program arguments: /usr/local/bin/clang -cc1 -triple
x86_64-segfault-freebsd8.0 -S -disable-free -main-file-name assert13.cc
-mrelocation-model static -mdisable-fp-elim -mconstructor-aliases
-munwind-tables -target-cpu x86-64 -resource-dir /usr/local/lib/clang/1.1
-fmessage-length 157 -fexceptions -fgnu-runtime -fdiagnostics-show-option
-fcolor-diagnostics -o /tmp/cc-0JIKY1.s -x c++ assert13.cc 
1.    <eof> parser at end of file
2.    assert13.cc:66:18: instantiating function definition
'MinimalModeMultiParadigm::HashAndTreeMaps::ProtoMap<int, class
Variable>::relate'
3.    assert13.cc:55:18: instantiating function definition
'MinimalModeMultiParadigm::HashAndTreeMaps::dynamicset<class
MinimalModeMultiParadigm::HashAndTreeMaps::Pair<int, class Variable>
>::operator[]'
4.    assert13.cc:31:17: instantiating function definition
'MinimalModeMultiParadigm::HashAndTreeMaps::Tree<class
MinimalModeMultiParadigm::HashAndTreeMaps::Pair<int, class Variable>,
Handle>::member'
5.    assert13.cc:35:22: instantiating function definition
'MinimalModeMultiParadigm::HashAndTreeMaps::Tree<class
MinimalModeMultiParadigm::HashAndTreeMaps::Pair<int, class Variable>,
Handle>::splay'
6.    assert13.cc:47:22: instantiating function definition
'MinimalModeMultiParadigm::HashAndTreeMaps::Node<class
MinimalModeMultiParadigm::HashAndTreeMaps::Pair<int, class Variable> >::splay'
clang: error: compiler command failed due to signal 6 (use -v to see
invocation)


$ clang --version
clang version 1.1 (trunk 97574)
Target: x86_64-segfault-freebsd8.0
Thread model: posix

-- 
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 llvm.org  Tue Mar  2 14:40:38 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  2 Mar 2010 14:40:38 -0600 (CST)
Subject: [LLVMbugs] [Bug 6467] New: JIT lazy compilation causes invalid value
Message-ID: <bug-6467-206@http.llvm.org/bugs/>

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

           Summary: JIT lazy compilation causes invalid value
           Product: libraries
           Version: 2.6
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: normal
          Priority: P5
         Component: Backend: X86
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: senorblanco at chromium.org
                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 llvm.org  Tue Mar  2 15:42:32 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  2 Mar 2010 15:42:32 -0600 (CST)
Subject: [LLVMbugs] [Bug 6353] clang emits U symbol while gcc emits W one
In-Reply-To: <bug-6353-206@http.llvm.org/bugs/>
References: <bug-6353-206@http.llvm.org/bugs/>
Message-ID: <20100302214232.556622A6C130@llvm.org>

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

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

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

--- Comment #29 from Rafael ?vila de Esp?ndola <rafael.espindola at gmail.com> 2010-03-02 15:42:32 CST ---
Trying 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 llvm.org  Tue Mar  2 16:00:51 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  2 Mar 2010 16:00:51 -0600 (CST)
Subject: [LLVMbugs] [Bug 6468] New: 97592: -fblocks codegen with template
 reference arg crash
Message-ID: <bug-6468-206@http.llvm.org/bugs/>

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

           Summary: 97592:  -fblocks codegen with  template reference arg
                    crash
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: major
          Priority: P5
         Component: LLVM Codegen
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: raila at illinois.edu
                CC: llvmbugs at cs.uiuc.edu


The following snippet crashes with arg type template reference, but works
without arg type template reference:
#include <stdio.h>
#include <stddef.h>

template<typename T>
class range {
public:
T _i;
        range(T i) {_i = i;};
        T get() {return _i;};
};

int main() {

        // works
        void (^bl)(range<int> ) = ^(range<int> i){printf("Hello Blocks %d\n",
i.get()); };

        //crashes in godegen?
        void (^bl2)(range<int>& ) = ^(range<int>& i){printf("Hello Blocks
%d\n", i.get()); };

        return 0;
}



Here is the backtrace:
clang: ASTContext.cpp:3805: void
clang::ASTContext::getObjCEncodingForTypeImpl(clang::QualType, std::string&,
bool, bool, const clang::FieldDecl*, bool, bool): Assertion `0 && "@encode for
type not implemented!"' failed.

Program received signal SIGABRT, Aborted.
0x00000039410326c5 in raise () from /lib64/libc.so.6
(gdb) bt
#0  0x00000039410326c5 in raise () from /lib64/libc.so.6
#1  0x0000003941033ea5 in abort () from /lib64/libc.so.6
#2  0x000000394102b7b5 in __assert_fail () from /lib64/libc.so.6
#3  0x0000000000931aec in clang::ASTContext::getObjCEncodingForTypeImpl
(this=0x20fc3a0, T=..., S="v16@?0", ExpandPointedToStructures=true, 
    ExpandStructures=true, FD=0x0, OutermostType=true, EncodingProperty=false)
at ASTContext.cpp:3805
#4  0x000000000093059f in clang::ASTContext::getObjCEncodingForType
(this=0x20fc3a0, T=..., S="v16@?0", Field=0x0) at ASTContext.cpp:3510
#5  0x000000000092fb73 in clang::ASTContext::getObjCEncodingForBlock
(this=0x20fc3a0, Expr=0x218ee50, S="v16@?0") at ASTContext.cpp:3314
#6  0x0000000000661939 in
clang::CodeGen::CodeGenFunction::BuildDescriptorBlockDecl (this=0x7fffffffb4f0,
BE=0x218ee50, 
    BlockHasCopyDispose=false, Size=..., Ty=0x0, NoteForHelper=0x0) at
CGBlocks.cpp:57
#7  0x00000000006621b2 in clang::CodeGen::CodeGenFunction::BuildBlockLiteralTmp
(this=0x7fffffffb4f0, BE=0x218ee50) at CGBlocks.cpp:199
#8  0x00000000005edce6 in (anonymous
namespace)::ScalarExprEmitter::VisitBlockExpr (this=0x7fffffffa460,
BE=0x218ee50)
    at CGExprScalar.cpp:1841
#9  0x00000000005ef0f8 in clang::StmtVisitor<<unnamed>::ScalarExprEmitter,
llvm::Value*>::Visit(clang::Stmt *) (this=0x7fffffffa460, 
    S=0x218ee50) at
/home/raila/dpc++/clang/llvm/tools/clang/lib/CodeGen/../../include/clang/AST/StmtNodes.def:152
#10 0x00000000005edd47 in clang::CodeGen::CodeGenFunction::EmitScalarExpr
(this=0x7fffffffb4f0, E=0x218ee50, IgnoreResultAssign=false)
    at CGExprScalar.cpp:1855
#11 0x00000000005b350d in
clang::CodeGen::CodeGenFunction::EmitLocalBlockVarDecl (this=0x7fffffffb4f0,
D=...) at CGDecl.cpp:527
#12 0x00000000005b14c7 in clang::CodeGen::CodeGenFunction::EmitBlockVarDecl
(this=0x7fffffffb4f0, D=...) at CGDecl.cpp:78
#13 0x00000000005b13be in clang::CodeGen::CodeGenFunction::EmitDecl
(this=0x7fffffffb4f0, D=...) at CGDecl.cpp:55
#14 0x000000000062d69b in clang::CodeGen::CodeGenFunction::EmitDeclStmt
(this=0x7fffffffb4f0, S=...) at CGStmt.cpp:632
#15 0x000000000062bd0a in clang::CodeGen::CodeGenFunction::EmitSimpleStmt
(this=0x7fffffffb4f0, S=0x218ee80) at CGStmt.cpp:129
#16 0x000000000062b8b8 in clang::CodeGen::CodeGenFunction::EmitStmt
(this=0x7fffffffb4f0, S=0x218ee80) at CGStmt.cpp:43
#17 0x000000000062bf2d in clang::CodeGen::CodeGenFunction::EmitCompoundStmt
(this=0x7fffffffb4f0, S=..., GetLast=false, AggLoc=0x0, 
    isAggVol=false) at CGStmt.cpp:160
#18 0x000000000062bce7 in clang::CodeGen::CodeGenFunction::EmitSimpleStmt
(this=0x7fffffffb4f0, S=0x218ef00) at CGStmt.cpp:128
#19 0x000000000062b8b8 in clang::CodeGen::CodeGenFunction::EmitStmt
(this=0x7fffffffb4f0, S=0x218ef00) at CGStmt.cpp:43
#20 0x000000000065b9c9 in clang::CodeGen::CodeGenFunction::EmitFunctionBody
(this=0x7fffffffb4f0, Args=...) at CodeGenFunction.cpp:252
#21 0x000000000065c05c in clang::CodeGen::CodeGenFunction::GenerateCode
(this=0x7fffffffb4f0, GD=..., Fn=0x2146fa0)
    at CodeGenFunction.cpp:314
#22 0x000000000055ad86 in
clang::CodeGen::CodeGenModule::EmitGlobalFunctionDefinition (this=0x21194b0,
GD=...) at CodeGenModule.cpp:1259
#23 0x0000000000558fb5 in clang::CodeGen::CodeGenModule::EmitGlobalDefinition
(this=0x21194b0, GD=...) at CodeGenModule.cpp:690
#24 0x0000000000558d30 in clang::CodeGen::CodeGenModule::EmitGlobal
(this=0x21194b0, GD=...) at CodeGenModule.cpp:661
#25 0x000000000055c901 in clang::CodeGen::CodeGenModule::EmitTopLevelDecl
(this=0x21194b0, D=0x218bc30) at CodeGenModule.cpp:1704
#26 0x0000000000555e0d in (anonymous
namespace)::CodeGeneratorImpl::HandleTopLevelDecl (this=0x20fe450, DG=...) at
ModuleBuilder.cpp:65
#27 0x0000000000418a1e in (anonymous
namespace)::BackendConsumer::HandleTopLevelDecl (this=0x21052d0, D=...) at
CodeGenAction.cpp:142
#28 0x0000000000672ee3 in clang::ParseAST (PP=..., Consumer=0x21052d0, Ctx=...,
PrintStats=false, CompleteTranslationUnit=true, 
    CompletionConsumer=0x0) at ParseAST.cpp:72
#29 0x0000000000433d92 in clang::ASTFrontendAction::ExecuteAction
(this=0x20eefa0) at FrontendAction.cpp:219
#30 0x0000000000433a20 in clang::FrontendAction::Execute (this=0x20eefa0) at
FrontendAction.cpp:149
#31 0x000000000041e0bc in clang::CompilerInstance::ExecuteAction
(this=0x7fffffffd7e0, Act=...) at CompilerInstance.cpp:509
#32 0x0000000000408446 in cc1_main (ArgBegin=0x7fffffffe0e8,
ArgEnd=0x7fffffffe1d0, 
    Argv0=0x7fffffffe45c "/home/raila/dpc++/clang/llvm/Debug/bin/clang",
MainAddr=0x40c0dc) at cc1_main.cpp:268
#33 0x000000000040cfbe in main (argc=31, argv=0x7fffffffe0d8) at driver.cpp:179

-- 
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 llvm.org  Tue Mar  2 16:32:59 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  2 Mar 2010 16:32:59 -0600 (CST)
Subject: [LLVMbugs] [Bug 6469] New: llvm-as asserts on invalid IR involving
 trailing comma with a misleading message
Message-ID: <bug-6469-206@http.llvm.org/bugs/>

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

           Summary: llvm-as asserts on invalid IR involving trailing comma
                    with a misleading message
           Product: new-bugs
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: minor
          Priority: P5
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: matti.niemenmaa+llvmbugs at iki.fi
                CC: llvmbugs at cs.uiuc.edu


The invalid IR below causes llvm-as from trunkish (r97475) to assert with the
following message:

While deleting: i32 %x
Use still stuck around after Def is destroyed:  <badref> = add i32 %x, %x      
                ; <i32> [#uses=0]
Use still stuck around after Def is destroyed:  <badref> = add i32 %x, %x      
                ; <i32> [#uses=0]
llvm-as: src/llvm/trunk/lib/VMCore/Value.cpp:75: virtual llvm::Value::~Value():
Assertion `use_empty() && "Uses remain when a value is destroyed!"' failed.
Stack dump:
0.    Program arguments: llvm-as 
0


define void @f() {
    %x = add i32 undef, undef
    %y = add i32 %x, %x,
    ret void
}

The problem is obviously the trailing comma on the %y line.

Appending an extraneous comma to other kinds of instructions will cause the
same assertion to fire. The following causes it to print just "llvm-as:" before
exiting:

define void @f() {
    %x = load i32* undef,
    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 llvm.org  Tue Mar  2 16:42:44 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  2 Mar 2010 16:42:44 -0600 (CST)
Subject: [LLVMbugs] [Bug 6470] New: Assertion failed: (false && "Ran out of
 registers during register allocation!")
Message-ID: <bug-6470-206@http.llvm.org/bugs/>

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

           Summary: Assertion failed: (false && "Ran out of registers
                    during register allocation!")
           Product: libraries
           Version: trunk
          Platform: Other
        OS/Version: FreeBSD
            Status: NEW
          Severity: normal
          Priority: P5
         Component: Common Code Generator Code
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: hinokind at gmail.com
                CC: llvmbugs at cs.uiuc.edu


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

i386-only, -O1 and above

$ cat assert14.c
int main() {
    static char foo[2][8];
    char *x=&foo[0][0];
    char *y=&foo[1][0];
    asm volatile(
    "add %1, %%""esi""   \n\t"
    :
    :  "g" (x),  "g" (y)
    : "%""eax", "%""ecx", "%""edx", "%""esi", "%""edi"
    );
}


$ clang -m32 -O1 assert14.c
Assertion failed: (false && "Ran out of registers during register
allocation!"), function assignRegOrStackSlotAtInterval, file
RegAllocLinearScan.cpp, line 1179.
Stack dump:
0.    Program arguments: /usr/local/bin/clang -cc1 -triple
i386-segfault-freebsd8.0 -S -disable-free -main-file-name assert14.c
-mrelocation-model static -mdisable-fp-elim -mconstructor-aliases -target-cpu
pentium4 -resource-dir /usr/local/lib/clang/1.1 -O1 -fmessage-length 157
-fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-ZQW8dV.s
-x c assert14.c 
1.    <eof> parser at end of file
2.    Code generation
3.    Running pass 'Linear Scan Register Allocator' on function '@main'
clang: error: compiler command failed due to signal 6 (use -v to see
invocation)


$ clang --version
clang version 1.1 (trunk 97589)
Target: x86_64-segfault-freebsd8.0
Thread model: posix

-- 
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 llvm.org  Tue Mar  2 16:46:48 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  2 Mar 2010 16:46:48 -0600 (CST)
Subject: [LLVMbugs] [Bug 6471] New: Missing destructor definition prevents
 bootstrap on ELF systems
Message-ID: <bug-6471-206@http.llvm.org/bugs/>

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

           Summary: Missing destructor definition prevents bootstrap on
                    ELF systems
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: rafael.espindola at gmail.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


When compiling Instructions.ii with clang it is missing a strong definition of
the destructor

_ZN4llvm16UnaryInstructionD2Ev

This prevents bootstrapping clang on ELF systems.

I have delta running and will add a testcase shortly.

-- 
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 llvm.org  Tue Mar  2 16:48:37 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  2 Mar 2010 16:48:37 -0600 (CST)
Subject: [LLVMbugs] [Bug 6472] New: clang segfault
Message-ID: <bug-6472-206@http.llvm.org/bugs/>

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

           Summary: clang segfault
           Product: clang
           Version: trunk
          Platform: Other
        OS/Version: FreeBSD
            Status: NEW
          Keywords: crash-on-invalid
          Severity: normal
          Priority: P5
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: hinokind at gmail.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


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

$ cat segv3.cc 
class { friend class foo::bar;


$ clang segv3.cc 
segv3.cc:1:22: error: use of undeclared identifier 'foo'
class { friend class foo::bar;
                     ^
Stack dump:
0.    Program arguments: /usr/local/bin/clang -cc1 -triple
x86_64-segfault-freebsd8.0 -S -disable-free -main-file-name segv3.cc
-mrelocation-model static -mdisable-fp-elim -mconstructor-aliases
-munwind-tables -target-cpu x86-64 -resource-dir /usr/local/lib/clang/1.1
-fmessage-length 157 -fexceptions -fgnu-runtime -fdiagnostics-show-option
-fcolor-diagnostics -o /tmp/cc-uguqgU.s -x c++ segv3.cc 
1.    segv3.cc:1:30: current parser token ';'
2.    segv3.cc:1:1: parsing struct/union/class body
clang: error: compiler command failed due to signal 11 (use -v to see
invocation)


$ clang --version
clang version 1.1 (trunk 97589)
Target: x86_64-segfault-freebsd8.0
Thread model: posix

-- 
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 llvm.org  Tue Mar  2 17:51:28 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  2 Mar 2010 17:51:28 -0600 (CST)
Subject: [LLVMbugs] [Bug 6473] New: __attribute__ weakref broken
Message-ID: <bug-6473-206@http.llvm.org/bugs/>

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

           Summary: __attribute__ weakref broken
           Product: new-bugs
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: sorokin at rain.ifmo.ru
                CC: llvmbugs at cs.uiuc.edu


ivan at ivan-desktop:~/d/llvm-build/Debug/bin$ g++ 3.cpp
ivan at ivan-desktop:~/d/llvm-build/Debug/bin$ ./clang++ 3.cpp
/tmp/cc-Ex8nJJ.o:(.gnu.linkonce.r._ZZ18__gthread_active_pvE20__gthread_active_ptr+0x0):
undefined reference to `pthread_cancel'
collect2: ld returned 1 exit status
clang: error: linker command failed with exit code 1 (use -v to see invocation)

-- 
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 llvm.org  Tue Mar  2 21:40:46 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  2 Mar 2010 21:40:46 -0600 (CST)
Subject: [LLVMbugs] [Bug 6471] Missing destructor definition prevents
 bootstrap on ELF systems
In-Reply-To: <bug-6471-206@http.llvm.org/bugs/>
References: <bug-6471-206@http.llvm.org/bugs/>
Message-ID: <20100303034046.39D4F2A6C12E@llvm.org>

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

John McCall <rjmccall at apple.com> changed:

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

--- Comment #2 from John McCall <rjmccall at apple.com> 2010-03-02 21:40:45 CST ---
This is a general bug in the derived-to-base destructor alias optimization. 
We're doing the optimization even when we only have a declaration of the target
destructor in this translation unit ? which is to say, we're emitting an alias
to an unresolved symbol, which isn't representable in any object file format I
know of.  Apparently the symptom is that alias just gets dropped at some point.

Fixed in r97637.

-- 
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 llvm.org  Tue Mar  2 22:39:03 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  2 Mar 2010 22:39:03 -0600 (CST)
Subject: [LLVMbugs] [Bug 6462] wrong(?) error: member 'rdbuf' found in
 multiple base classes of different types
In-Reply-To: <bug-6462-206@http.llvm.org/bugs/>
References: <bug-6462-206@http.llvm.org/bugs/>
Message-ID: <20100303043903.A48332A6C12E@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #7 from Douglas Gregor <dgregor at apple.com> 2010-03-02 22:39:03 CST ---
Fixed in r97640.

-- 
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 llvm.org  Tue Mar  2 23:43:11 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  2 Mar 2010 23:43:11 -0600 (CST)
Subject: [LLVMbugs] [Bug 4953] Integrate calling convention into Clang
	function types
In-Reply-To: <bug-4953-206@http.llvm.org/bugs/>
References: <bug-4953-206@http.llvm.org/bugs/>
Message-ID: <20100303054311.032BC2A6C124@llvm.org>

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

Charles Davis <cdavis at mymail.mines.edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
                 CC|                            |cdavis at mymail.mines.edu
         Resolution|                            |FIXED

--- Comment #7 from Charles Davis <cdavis at mymail.mines.edu> 2010-03-02 23:43:10 CST ---
Bug should be fixed now.

-- 
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 llvm.org  Wed Mar  3 02:42:37 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  3 Mar 2010 02:42:37 -0600 (CST)
Subject: [LLVMbugs] [Bug 6426] Structure layout is not correct in big endian.
In-Reply-To: <bug-6426-206@http.llvm.org/bugs/>
References: <bug-6426-206@http.llvm.org/bugs/>
Message-ID: <20100303084237.DC7692A6C12C@llvm.org>

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

hwalin <dodohack at gmail.com> changed:

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

--- Comment #6 from hwalin <dodohack at gmail.com> 2010-03-03 02:42:36 CST ---
This is an invalid bug caused by incorrect LowerCall function.

-- 
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 llvm.org  Wed Mar  3 02:58:45 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  3 Mar 2010 02:58:45 -0600 (CST)
Subject: [LLVMbugs] [Bug 6474] New: clang -fsyntax-only fails on something
 g++ accepts [3]
Message-ID: <bug-6474-206@http.llvm.org/bugs/>

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

           Summary: clang -fsyntax-only fails on something g++ accepts [3]
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: rdivacky at freebsd.org
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


pes delta$ g++ -fsyntax-only globals_io.cc && echo success
success

pes delta$ clang++ -fsyntax-only globals_io.cc && echo success
globals_io.cc:24:8: warning: control reaches end of non-void function
[-Wreturn-type]
       }
       ^
globals_io.cc:25:80: error: explicit specialization of 'xsputn' after
instantiation
        template<>     inline std::streamsize    
stdio_sync_filebuf<wchar_t>::xsputn(const wchar_t* __s, ...
                                                                              
^
globals_io.cc:23:80: note: implicit instantiation first required here
        template<>     inline std::streamsize    
stdio_sync_filebuf<wchar_t>::xsgetn(wchar_t* __s, ...
                                                                              
^
3 diagnostics generated.

-- 
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 llvm.org  Wed Mar  3 04:22:16 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  3 Mar 2010 04:22:16 -0600 (CST)
Subject: [LLVMbugs] [Bug 6475] New: Inline asm bug with
	atomic_exchange_and_add
Message-ID: <bug-6475-206@http.llvm.org/bugs/>

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

           Summary: Inline asm bug with atomic_exchange_and_add
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P5
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: gonsolo at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Clang fails to compile the following reduce testcase:

inline int atomic_exchange_and_add( int * pw, int dv )
{
    int r;

    __asm__ __volatile__
    (
        "lock\n\t"
        "xadd %1, %0":
        "=m"( *pw ), "=r"( r ):
        "m"( *pw ), "1"( dv ):
        "memory", "cc"
    );

    return r;
}

void release() {
    int use_count_;
        if( atomic_exchange_and_add( &use_count_, -1 ) == 1 ) { }
}

with the following error:

Stack dump:
0.    Program arguments: /home/gonzo/bin/clang -cc1 -triple i386-pc-linux-gnu
-S -disable-free -disable-llvm-verifier -main-file-name bla3.cc
-mrelocation-model static -mdisable-fp-elim -mconstructor-aliases -target-cpu
pentium4 -resource-dir /home/gonzo/lib/clang/1.1 -fmessage-length 177
-fexceptions -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o
/tmp/cc-zTnd86.s -x c++ bla3.cc 
1.    <eof> parser at end of file
2.    Code generation
3.    Running pass 'X86 DAG->DAG Instruction Selection' on function
'@_Z23atomic_exchange_and_addPii'
clang: error: compiler command failed due to signal 11 (use -v to see
invocation)

This is clang version 02ebc and llvm version eb6e04 on Ubuntu 9.10.

-- 
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 llvm.org  Wed Mar  3 05:52:42 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  3 Mar 2010 05:52:42 -0600 (CST)
Subject: [LLVMbugs] [Bug 6476] New: ARM JIT hits UNREACHABLE using
 -mattr=+v6t2 and -mattr=+v7a
Message-ID: <bug-6476-206@http.llvm.org/bugs/>

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

           Summary: ARM JIT hits UNREACHABLE using -mattr=+v6t2 and
                    -mattr=+v7a
           Product: libraries
           Version: trunk
          Platform: Other
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P5
         Component: Backend: ARM
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: xerxes at zafena.se
                CC: llvmbugs at cs.uiuc.edu


Expected output when runing lli on hello.ll (here using -mattr=+v6)
xerxes at xerxes:/sd/llvm-configure/test/ExecutionEngine/Output$ lli -mattr=+v6 <
hello.ll.tmp.bc Hello World

Actual output using -mattr=+v6t2
xerxes at xerxes:/sd/llvm-configure/test/ExecutionEngine/Output$ lli -mattr=+v6t2
< hello.ll.tmp.bc  
ARMCodeEmitter::emitPseudoInstruction
UNREACHABLE executed at /media/disk/llvm/lib/Target/ARM/ARMCodeEmitter.cpp:554!
0  libLLVM-2.7svn.so 0x408bf75c
Stack dump:
0.    Program arguments: lli -mattr=+v6t2 
1.    Running pass 'ARM Machine Code Emitter' on function '@main'
Aborted

The same happens using -mattr=+v7a
xerxes at xerxes:/sd/llvm-configure/test/ExecutionEngine/Output$ lli -mcpu=generic
-mattr=+v7a < hello.ll.tmp.bc 
ARMCodeEmitter::emitPseudoInstruction
UNREACHABLE executed at /media/disk/llvm/lib/Target/ARM/ARMCodeEmitter.cpp:554!
0  libLLVM-2.7svn.so 0x408bf75c
Stack dump:
0.    Program arguments: lli -mcpu=generic -mattr=+v7a 
1.    Running pass 'ARM Machine Code Emitter' on function '@main'
Aborted

-- 
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 llvm.org  Wed Mar  3 05:59:33 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  3 Mar 2010 05:59:33 -0600 (CST)
Subject: [LLVMbugs] [Bug 6476] ARM JIT hits UNREACHABLE using -mattr=+v6t2
 and -mattr=+v7a
In-Reply-To: <bug-6476-206@http.llvm.org/bugs/>
References: <bug-6476-206@http.llvm.org/bugs/>
Message-ID: <20100303115933.14BDD2A6C12C@llvm.org>

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

Xerxes R?nby <xerxes at zafena.se> changed:

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

--- Comment #2 from Xerxes R?nby <xerxes at zafena.se> 2010-03-03 05:59:32 CST ---


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

-- 
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 llvm.org  Wed Mar  3 08:46:12 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  3 Mar 2010 08:46:12 -0600 (CST)
Subject: [LLVMbugs] [Bug 6477] New: Goto over object definition causes build
	error
Message-ID: <bug-6477-206@http.llvm.org/bugs/>

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

           Summary: Goto over object definition causes build error
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: jpakkane at gmail.com
                CC: llvmbugs at cs.uiuc.edu


When you compile the attached file with clang++, it gives this error:

gototest.cxx:5:5: error: illegal goto into protected scope
    goto ED_END;
    ^
gototest.cxx:6:18: note: jump bypasses variable initialization
    std::fstream f;

If you comment out line 6, everything works.

This is a regression, as svn checkout from a couple of days ago worked just
fine. The same code compiles on g++ and MSVC without errors.

-- 
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 llvm.org  Wed Mar  3 08:53:04 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  3 Mar 2010 08:53:04 -0600 (CST)
Subject: [LLVMbugs] [Bug 6478] New: ARM CodeGen Running pass 'Prolog/Epilog
 Insertion & Frame Finalization' on function '@"java.lang.String::getChars"'
Message-ID: <bug-6478-206@http.llvm.org/bugs/>

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

           Summary: ARM CodeGen Running pass 'Prolog/Epilog Insertion &
                    Frame Finalization' on function
                    '@"java.lang.String::getChars"'
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: Backend: ARM
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: xerxes at zafena.se
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=4375)
 --> (http://llvm.org/bugs/attachment.cgi?id=4375)
Testcase java.lang.String::getChars.ll

The attached testcase triggers this bug using LLVM IR produced using OpenJDK
Shark JIT when compiling java.lang.String::getChars

xerxes at xerxes-J464X:~$ llvm-as < java.lang.String::getChars.ll | llc -march=arm
    .syntax unified
    .eabi_attribute 20, 1
    .eabi_attribute 21, 1
    .eabi_attribute 23, 3
    .eabi_attribute 24, 1
    .eabi_attribute 25, 1
    .file    "<stdin>"
llc: /home/xerxes/llvm/include/llvm/CodeGen/MachineFrameInfo.h:289: int64_t
llvm::MachineFrameInfo::getObjectOffset(int) const: Assertion
`!isDeadObjectIndex(ObjectIdx) && "Getting frame offset for a dead object?"'
failed.
0  libLLVM-2.7svn.so 0x01cb5e96
1  libLLVM-2.7svn.so 0x01cb5d0b
2  libpthread.so.0   0x004ee2b8
3  libc.so.6         0x0074fa42 abort + 386
4  libc.so.6         0x00745748 __assert_fail + 248
5  libLLVM-2.7svn.so 0x013a70aa llvm::MachineFrameInfo::getStackSize() const +
0
6  libLLVM-2.7svn.so 0x014c8b91
llvm::ARMBaseRegisterInfo::emitPrologue(llvm::MachineFunction&) const + 1415
7  libLLVM-2.7svn.so 0x016f9d78
llvm::PEI::insertPrologEpilogCode(llvm::MachineFunction&) + 70
8  libLLVM-2.7svn.so 0x016f8043
llvm::PEI::runOnMachineFunction(llvm::MachineFunction&) + 427
9  libLLVM-2.7svn.so 0x016b8cdb
llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 87
10 libLLVM-2.7svn.so 0x01864115
llvm::FPPassManager::runOnFunction(llvm::Function&) + 301
11 libLLVM-2.7svn.so 0x01863e54
llvm::FunctionPassManagerImpl::run(llvm::Function&) + 90
12 libLLVM-2.7svn.so 0x01863af6 llvm::FunctionPassManager::run(llvm::Function&)
+ 140
13 llc               0x080590bb main + 3024
14 libc.so.6         0x00738bd6 __libc_start_main + 230
15 llc               0x08057bb1
Stack dump:
0.    Program arguments: llc -march=arm 
1.    Running pass 'Prolog/Epilog Insertion & Frame Finalization' on function
'@"java.lang.String::getChars"'
Avbruten (SIGABRT) (minnesutskrift skapad)

This are a regression since LLVM 2.6

-- 
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 llvm.org  Wed Mar  3 09:25:14 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  3 Mar 2010 09:25:14 -0600 (CST)
Subject: [LLVMbugs] [Bug 6479] New: zero extending i1 to i32 on x86
Message-ID: <bug-6479-206@http.llvm.org/bugs/>

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

           Summary: zero extending i1 to i32 on x86
           Product: new-bugs
           Version: 2.6
          Platform: PC
        OS/Version: Windows NT
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: pete.cooper at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=4377)
 --> (http://llvm.org/bugs/attachment.cgi?id=4377)
intermediate test file

This curently generates a redundant zero extension as 

movzbl    %al, %eax
andl    $1, %eax

which can just be 

andl    $1, %eax

I've written a new pattern for X86InstrInfo.td which removes the unused mov but
i wasn't sure where in that file to put it so i'm not attaching it as a patch

def : Pat<(i32 (and (i32 (anyext GR8 :$src)), (i32 1))),
          (AND32ri (SUBREG_TO_REG (i32 0), GR8:$src, x86_subreg_8bit), 1)>;

Can someone please verify if i've done the right thing here.  I get the right
result which is always a good start.  Also, i've only seen this case (mask with
1) be output, but would it be better to match any constant in the 1-255 range
here, and if it is worth it, could someone please tell me how that would be
written.

-- 
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 llvm.org  Wed Mar  3 09:29:11 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  3 Mar 2010 09:29:11 -0600 (CST)
Subject: [LLVMbugs] [Bug 6480] New: ARM Codegen asserts Running pass
 'Control Flow Optimizer' on function '@"java.lang.String::getChars"'
Message-ID: <bug-6480-206@http.llvm.org/bugs/>

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

           Summary: ARM Codegen asserts Running pass 'Control Flow
                    Optimizer' on function '@"java.lang.String::getChars"'
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: Backend: ARM
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: xerxes at zafena.se
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=4378)
 --> (http://llvm.org/bugs/attachment.cgi?id=4378)
bugpoint-reduced-simplified.bc

the reduced bugpoint-reduced-simplified.bc from PR6478
 hits a new bug so im filing a new bugreport.

Testcase
xerxes at xerxes-J464X:~$ llc < bugpoint-reduced-simplified.bc -march=arm
    .syntax unified
    .eabi_attribute 20, 1
    .eabi_attribute 21, 1
    .eabi_attribute 23, 3
    .eabi_attribute 24, 1
    .eabi_attribute 25, 1
    .file    "<stdin>"
llc: /home/xerxes/llvm/lib/CodeGen/RegisterScavenging.cpp:193: void
llvm::RegScavenger::forward(): Assertion `SubUsed && "Using an undefined
register!"' failed.
0  libLLVM-2.7svn.so 0x01893e96
1  libLLVM-2.7svn.so 0x01893d0b
2  libpthread.so.0   0x003142b8
3  libc.so.6         0x00181a42 abort + 386
4  libc.so.6         0x00177748 __assert_fail + 248
5  libLLVM-2.7svn.so 0x01305741 llvm::RegScavenger::forward() + 1181
6  libLLVM-2.7svn.so 0x010fca19
llvm::RegScavenger::forward(llvm::ilist_iterator<llvm::MachineInstr>) + 105
7  libLLVM-2.7svn.so 0x0121bcf4
llvm::BranchFolder::SplitMBBAt(llvm::MachineBasicBlock&,
llvm::ilist_iterator<llvm::MachineInstr>) + 358
8  libLLVM-2.7svn.so 0x0121cb16
llvm::BranchFolder::CreateCommonTailOnlyBlock(llvm::MachineBasicBlock*&,
unsigned int) + 488
9  libLLVM-2.7svn.so 0x0121d152
llvm::BranchFolder::TryTailMergeBlocks(llvm::MachineBasicBlock*,
llvm::MachineBasicBlock*) + 1468
10 libLLVM-2.7svn.so 0x0121d566
llvm::BranchFolder::TailMergeBlocks(llvm::MachineFunction&) + 428
11 libLLVM-2.7svn.so 0x0121b254
llvm::BranchFolder::OptimizeFunction(llvm::MachineFunction&,
llvm::TargetInstrInfo const*, llvm::TargetRegisterInfo const*,
llvm::MachineModuleInfo*) + 650
12 libLLVM-2.7svn.so 0x0121a982
13 libLLVM-2.7svn.so 0x01296cdb
llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 87
14 libLLVM-2.7svn.so 0x01442115
llvm::FPPassManager::runOnFunction(llvm::Function&) + 301
15 libLLVM-2.7svn.so 0x01441e54
llvm::FunctionPassManagerImpl::run(llvm::Function&) + 90
16 libLLVM-2.7svn.so 0x01441af6 llvm::FunctionPassManager::run(llvm::Function&)
+ 140
17 llc               0x080590bb main + 3024
18 libc.so.6         0x0016abd6 __libc_start_main + 230
19 llc               0x08057bb1
Stack dump:
0.    Program arguments: llc -march=arm 
1.    Running pass 'Control Flow Optimizer' on function
'@"java.lang.String::getChars"'
Avbruten (SIGABRT) (minnesutskrift skapad)

-- 
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 llvm.org  Wed Mar  3 11:02:00 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  3 Mar 2010 11:02:00 -0600 (CST)
Subject: [LLVMbugs] [Bug 6481] New: instcombine incorrectly generates undefs
	with icmp
Message-ID: <bug-6481-206@http.llvm.org/bugs/>

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

           Summary: instcombine incorrectly generates undefs with icmp
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: Scalar Optimizations
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: arplynn at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Take the example of:

define i1 @cond() nounwind readnone {
entry:
        %cmp = icmp slt i8 undef, -128
        ret i1 %cmp
}

instcombine turns this into ret i1 undef. This is not valid: there is no i8
value for which the condition is 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 llvm.org  Wed Mar  3 11:38:03 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  3 Mar 2010 11:38:03 -0600 (CST)
Subject: [LLVMbugs] [Bug 6482] New: llvm-link asserts with "Type mismatch in
 constant table!" depending on linking order
Message-ID: <bug-6482-206@http.llvm.org/bugs/>

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

           Summary: llvm-link asserts with "Type mismatch in constant
                    table!" depending on linking order
           Product: new-bugs
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: major
          Priority: P5
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: matti.niemenmaa+llvmbugs at iki.fi
                CC: llvmbugs at cs.uiuc.edu


The attached two bitcode files are both individually fine, but llvm-link from
trunk (r97652) asserts if one links them in the order 'one.bc' 'two.bc':

$ llvm-link one.bc two.bc >/dev/null
llvm-link: src/llvm/trunk/lib/Bitcode/Reader/BitcodeReader.cpp:203:
llvm::Constant* llvm::BitcodeReaderValueList::getConstantFwdRef(unsigned int,
const llvm::Type*): Assertion `Ty == V->getType() && "Type mismatch in constant
table!"' failed.
Stack dump:
0.    Program arguments: llvm-link one.bc two.bc 

Doing it in the other order is fine though:

$ llvm-link two.bc one.bc | llvm-dis | wc -l
1267

llvm-link from LLVM 2.6 copes fine regardless of the order, but it does produce
different output for the two cases. (Not necessarily unexpected?)

I think that this is the same problem that is preventing me from bugpointing a
misoptimization: bugpoint dies in the same way when it starts splitting the
testcase.

Using the 'delta' tool for several CPU-hours I managed to bring 'two.bc' down
from over a megabyte to the current 43K, but it's still a bit big; I hope it's
not so big as to make finding the problem unduly difficult.

-- 
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 llvm.org  Wed Mar  3 11:51:10 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  3 Mar 2010 11:51:10 -0600 (CST)
Subject: [LLVMbugs] [Bug 6483] New: Assertion failure (Expected a direct
 reference binding!) with boost
Message-ID: <bug-6483-206@http.llvm.org/bugs/>

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

           Summary: Assertion failure (Expected a direct reference
                    binding!) with boost
           Product: clang
           Version: trunk
          Platform: Other
        OS/Version: FreeBSD
            Status: NEW
          Severity: normal
          Priority: P5
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: whitehorn at wisc.edu
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


Created an attachment (id=4381)
 --> (http://llvm.org/bugs/attachment.cgi?id=4381)
Test case

When building headers similar to the attached reduced test case, I get an
assertion failure inside clang:

[nwhitehorn at comporellon /usr/home/nwhitehorn]$ clang++ test.cpp 
Assertion failed: (ICS->UserDefined.After.ReferenceBinding &&
ICS->UserDefined.After.DirectBinding && "Expected a direct reference
binding!"), function CheckReferenceInit, file
/home/nwhitehorn/llvm/llvm-src/tools/clang/lib/Sema/SemaDeclCXX.cpp, line 4550.
Stack dump:
0.      Program arguments: /usr/local/bin/clang -cc1 -triple
x86_64-unknown-freebsd9.0 -S -disable-free -main-file-name test.cpp
-mrelocation-model static -mdisable-fp-elim -mconstructor-aliases
-munwind-tables -target-cpu x86-64 -resource-dir /usr/local/lib/clang/1.1
-fmessage-length 78 -fexceptions -fgnu-runtime -fdiagnostics-show-option
-fcolor-diagnostics -o /tmp/cc-4u7iDn.s -x c++ test.cpp 
1.      <eof> parser at end of file
2.      test.cpp:35:7: instantiating function definition
'boost::archive::portable_binary_oarchive_impl<class
boost::archive::portable_binary_oarchive, char, struct std::char_traits<char>
>::portable_binary_oarchive_impl'
3.      /usr/local/include/boost/archive/basic_binary_oarchive.hpp:124:5:
instantiating function definition 'boost::archive::basic_binary_oarchive<class
boost::archive::portable_binary_oarchive>::basic_binary_oarchive'
4.      /usr/local/include/boost/archive/detail/common_oarchive.hpp:66:5:
instantiating function definition
'boost::archive::detail::common_oarchive<class
boost::archive::portable_binary_oarchive>::common_oarchive'
5.      /usr/local/include/boost/archive/detail/common_oarchive.hpp:34:18:
instantiating function definition
'boost::archive::detail::common_oarchive<class
boost::archive::portable_binary_oarchive>::vsave'
6.      /usr/local/include/boost/archive/detail/interface_oarchive.hpp:63:15:
instantiating function definition
'boost::archive::detail::interface_oarchive<class
boost::archive::portable_binary_oarchive>::operator<<'
clang: error: compiler command failed due to signal 6 (use -v to see
invocation)

-- 
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 llvm.org  Wed Mar  3 13:17:49 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  3 Mar 2010 13:17:49 -0600 (CST)
Subject: [LLVMbugs] [Bug 6477] Goto over object definition causes build error
In-Reply-To: <bug-6477-206@http.llvm.org/bugs/>
References: <bug-6477-206@http.llvm.org/bugs/>
Message-ID: <20100303191749.BFEFE2A6C124@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #2 from Chris Lattner <clattner at apple.com> 2010-03-03 13:17:49 CST ---
I'm not sure what you mean, this is definitely invalid C++ code and gcc 4.2
rejects it:

$ gcc gototest.cxx 
gototest.cxx: In function ?int main(int, char**)?:
gototest.cxx:8: error: jump to label ?ED_END?
gototest.cxx:5: error:   from here
gototest.cxx:6: error:   crosses initialization of ?std::fstream f?

We recently started enforcing this requirement.

-- 
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 llvm.org  Wed Mar  3 13:46:36 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  3 Mar 2010 13:46:36 -0600 (CST)
Subject: [LLVMbugs] [Bug 6481] instcombine incorrectly generates undefs with
	icmp
In-Reply-To: <bug-6481-206@http.llvm.org/bugs/>
References: <bug-6481-206@http.llvm.org/bugs/>
Message-ID: <20100303194636.ECE392A6C12E@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #2 from Chris Lattner <clattner at apple.com> 2010-03-03 13:46:36 CST ---
You're right, fixed in r97659

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 llvm.org  Wed Mar  3 14:16:18 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  3 Mar 2010 14:16:18 -0600 (CST)
Subject: [LLVMbugs] [Bug 6444] Alpha Backend fails to compile _floatdisf
 with internal compiler error.
In-Reply-To: <bug-6444-206@http.llvm.org/bugs/>
References: <bug-6444-206@http.llvm.org/bugs/>
Message-ID: <20100303201618.06FD72A6C12E@llvm.org>

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

Andrew Lenharth <alenhar2 at uiuc.edu> 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 llvm.org  Wed Mar  3 15:53:04 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  3 Mar 2010 15:53:04 -0600 (CST)
Subject: [LLVMbugs] [Bug 6475] Inline asm bug with atomic_exchange_and_add
In-Reply-To: <bug-6475-206@http.llvm.org/bugs/>
References: <bug-6475-206@http.llvm.org/bugs/>
Message-ID: <20100303215304.C5D972A6C12E@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #14 from Chris Lattner <clattner at apple.com> 2010-03-03 15:53:04 CST ---
Fixed here:
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20100301/028107.html

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 llvm.org  Wed Mar  3 15:54:42 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  3 Mar 2010 15:54:42 -0600 (CST)
Subject: [LLVMbugs] [Bug 6484] New: Improve diagnostic when there is an
	extraneous '}'
Message-ID: <bug-6484-206@http.llvm.org/bugs/>

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

           Summary: Improve diagnostic when there is an extraneous '}'
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Keywords: quality-of-implementation
          Severity: enhancement
          Priority: P5
         Component: parser
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: dgregor at apple.com
                CC: llvmbugs at cs.uiuc.edu


terfin:clang dgregor$ cat t2.c
void foo() { }
}

terfin:clang dgregor$ clang t2.c
t2.c:2:1: error: expected external declaration
}
^
1 diagnostic generated.

We can do better, with something like "extraneous closing brace ('}') at the
top level".

-- 
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 llvm.org  Wed Mar  3 16:55:31 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  3 Mar 2010 16:55:31 -0600 (CST)
Subject: [LLVMbugs] [Bug 5820] clang can't disambiguate calls to method in
 base class in diamond-shaped heirarchy, even though the call is qualified
In-Reply-To: <bug-5820-206@http.llvm.org/bugs/>
References: <bug-5820-206@http.llvm.org/bugs/>
Message-ID: <20100303225531.3A5052A6C12E@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #2 from Douglas Gregor <dgregor at apple.com> 2010-03-03 16:55:30 CST ---
Implemented in r97674.

-- 
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 llvm.org  Wed Mar  3 16:57:36 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  3 Mar 2010 16:57:36 -0600 (CST)
Subject: [LLVMbugs] [Bug 6458] clang++ emits T while g++ emits U symbol
In-Reply-To: <bug-6458-206@http.llvm.org/bugs/>
References: <bug-6458-206@http.llvm.org/bugs/>
Message-ID: <20100303225736.5EEED2A6C12D@llvm.org>

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

John McCall <rjmccall at apple.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 llvm.org  Wed Mar  3 17:01:53 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  3 Mar 2010 17:01:53 -0600 (CST)
Subject: [LLVMbugs] [Bug 6485] New: Diagnostic for using non-POD type with
 va_start needs improvement
Message-ID: <bug-6485-206@http.llvm.org/bugs/>

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

           Summary: Diagnostic for using non-POD type with va_start needs
                    improvement
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: trivial
          Priority: P5
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: rideau3 at gmail.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


coppro at overthere:~$ clang -x c++ -
#include <stdarg.h>               

struct foo { virtual void bar(); };

void baz (foo f, ...) {
  va_list v;
  va_start(v, f);
}
// END OF TESTCASE
<stdin>:7:3: error: cannot pass object of non-POD type 'struct foo' through
variadic function; call will abort at runtime [-Wnon-pod-varargs]
  va_start(v, f);
  ^
<stdin>:7:15: note: instantiated from:
  va_start(v, f);
              ^
1 diagnostic generated.
// END OF OUTPUT

GCC does not issue a diagnostic here, however, it is good that clang do so
([support.runtime]/3). The diagnostic could bear improvement, however - prehaps
to something along the lines of "cannot use va_start on a parameter of non-POD
type 'struct foo'".

-- 
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 llvm.org  Wed Mar  3 18:24:29 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  3 Mar 2010 18:24:29 -0600 (CST)
Subject: [LLVMbugs] [Bug 6465] DAGCombiner/SelectionDAG are not safe when
	using vectors
In-Reply-To: <bug-6465-206@http.llvm.org/bugs/>
References: <bug-6465-206@http.llvm.org/bugs/>
Message-ID: <20100304002429.686EA2A6C12C@llvm.org>

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

Dan Gohman <gohman at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |gohman at apple.com
         Resolution|                            |FIXED

--- Comment #2 from Dan Gohman <gohman at apple.com> 2010-03-03 18:24:29 CST ---
The DAGCombiner.cpp part looks fine; I committed that in r97692.  The
SelectionDAG.cpp part does not look right. There had been some confusion about
this in the tree, but now the type operand to vector SIGN_EXTEND_INREG is also
vector.

-- 
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 llvm.org  Wed Mar  3 22:00:04 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  3 Mar 2010 22:00:04 -0600 (CST)
Subject: [LLVMbugs] [Bug 6486] New: likely integer wrong code bug
Message-ID: <bug-6486-206@http.llvm.org/bugs/>

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

           Summary: likely integer wrong code bug
           Product: new-bugs
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: regehr at cs.utah.edu
                CC: llvmbugs at cs.uiuc.edu, chenyang at cs.utah.edu


The -O1 result looks wrong.  Seen using r97717.

regehr at john-home:~/volatile/bugs/tmp272$ clang -O0 small.c -o small -w
regehr at john-home:~/volatile/bugs/tmp272$ ./small
1
regehr at john-home:~/volatile/bugs/tmp272$ clang -O1 small.c -o small -w
regehr at john-home:~/volatile/bugs/tmp272$ ./small
0
regehr at john-home:~/volatile/bugs/tmp272$ cat small.c
#include <stdio.h>

int g_43 = 0;
int *g_92[2];
int **const g_177 = &g_92[1];

static int func_55 (void)
{
  g_43 = 1;
  return 1;
}

int main(void)
{
  (0 <= (0 != g_177)) && func_55();
  printf ("%d\n", g_43);
  return 0;
}
regehr at john-home:~/volatile/bugs/tmp272$ clang -v
clang version 1.1 (trunk)
Target: i386-pc-linux-gnu
Thread model: posix

-- 
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 llvm.org  Wed Mar  3 22:11:29 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  3 Mar 2010 22:11:29 -0600 (CST)
Subject: [LLVMbugs] [Bug 6487] New: ice: Cannot create empty or backwards
	range
Message-ID: <bug-6487-206@http.llvm.org/bugs/>

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

           Summary: ice: Cannot create empty or backwards range
           Product: new-bugs
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: regehr at cs.utah.edu
                CC: llvmbugs at cs.uiuc.edu, chenyang at cs.utah.edu


Seen on Ubuntu 9.10 on x64 using clang r97662.

[regehr at gamow tmp273]$ clang -O2 small.c
clang:
/tmp/z/compiler-build/llvm-r97662/include/llvm/CodeGen/LiveInterval.h:231:
llvm::LiveRange::LiveRange(llvm::SlotIndex, llvm::SlotIndex, llvm::VNInfo*):
Assertion `S < E && "Cannot create empty or backwards range"' failed.
0  clang           0x000000000117320f
1  clang           0x00000000011739fd
2  libpthread.so.0 0x00007f11e745e190
3  libc.so.6       0x00007f11e67644b5 gsignal + 53
4  libc.so.6       0x00007f11e6767f50 abort + 384
5  libc.so.6       0x00007f11e675d481 __assert_fail + 241
6  clang           0x0000000000e5263f
7  clang           0x0000000000e4db7b
8  clang           0x0000000000e4fa69
9  clang           0x0000000000e5036f
10 clang           0x0000000000e50e8e
11 clang           0x0000000000e51d6c
12 clang           0x00000000010fd596
13 clang           0x00000000010fd771
14 clang           0x00000000010fd99e
15 clang           0x0000000000413436
16 clang           0x0000000000413a75
17 clang           0x00000000005f8544
18 clang           0x0000000000416c09
19 clang           0x00000000004095ce
20 clang           0x000000000040c36b main + 1771
21 libc.so.6       0x00007f11e674fabd __libc_start_main + 253
22 clang           0x0000000000407149
Stack dump:
0.    Program arguments:
/tmp/z/compiler-install/llvm-gcc-r97662-install/bin/clang -cc1 -triple
x86_64-unknown-linux-gnu -S -disable-free -main-file-name small.c
-mrelocation-model static -mdisable-fp-elim -mconstructor-aliases
-munwind-tables -target-cpu x86-64 -resource-dir
/tmp/z/compiler-install/llvm-gcc-r97662-install/lib/clang/1.1 -O2
-fmessage-length 85 -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics
-o /tmp/cc-IZAtF0.s -x c small.c 
1.    <eof> parser at end of file
2.    Code generation
3.    Running pass 'Simple Register Coalescing' on function '@int325'
clang: error: compiler command failed due to signal 6 (use -v to see
invocation)
[regehr at gamow tmp273]$ cat small.c
static unsigned char
foo (unsigned char ui1, unsigned char ui2)
{
  return ui2 == 0 ? : (ui1 % ui2);
}

static unsigned bar (unsigned ui1, unsigned ui2)
{
  return ui2 ? ui1 : (ui1 / ui2);
}

int safe (int);

short g_5;
short *g_37 = &g_5;

void int325 (int * p_66)
{
  short l_71 = 7L;
  if (*p_66 & safe (foo (bar (l_71, *g_37), l_71)), 1)
    {
    }
}
[regehr at gamow tmp273]$ clang -v
clang version 1.1 (trunk)
Target: x86_64-unknown-linux-gnu
Thread model: posix

-- 
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 llvm.org  Wed Mar  3 22:24:46 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  3 Mar 2010 22:24:46 -0600 (CST)
Subject: [LLVMbugs] [Bug 6488] New: request for a bit more verbosity from
	"clang -v"
Message-ID: <bug-6488-206@http.llvm.org/bugs/>

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

           Summary: request for a bit more verbosity from "clang -v"
           Product: new-bugs
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: regehr at cs.utah.edu
                CC: llvmbugs at cs.uiuc.edu


As a bug reporter it would make my life easier (and hopefully yours!) if "clang
-v" reported:

- svn rev
- a flag indicating if there are local modifications
- configure options (or at least indicating Debug vs Release)

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 llvm.org  Wed Mar  3 22:35:21 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  3 Mar 2010 22:35:21 -0600 (CST)
Subject: [LLVMbugs] [Bug 6489] New: ice: Cannot find live range
Message-ID: <bug-6489-206@http.llvm.org/bugs/>

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

           Summary: ice: Cannot find live range
           Product: new-bugs
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: regehr at cs.utah.edu
                CC: llvmbugs at cs.uiuc.edu


Seen with clang r97662 on x64 Linux.

[regehr at gamow tmp274]$ clang -O small.c -c 
clang: SimpleRegisterCoalescing.cpp:2315: bool
llvm::SimpleRegisterCoalescing::JoinIntervals(llvm::LiveInterval&,
llvm::LiveInterval&, bool&): Assertion `lr && "Cannot find live range"' failed.
0  clang           0x000000000117320f
1  clang           0x00000000011739fd
2  libpthread.so.0 0x00007f2c03fe0190
3  libc.so.6       0x00007f2c032e64b5 gsignal + 53
4  libc.so.6       0x00007f2c032e9f50 abort + 384
5  libc.so.6       0x00007f2c032df481 __assert_fail + 241
6  clang           0x0000000000e4b97c
7  clang           0x0000000000e4eacd
8  clang           0x0000000000e5036f
9  clang           0x0000000000e50e8e
10 clang           0x0000000000e51d6c
11 clang           0x00000000010fd596
12 clang           0x00000000010fd771
13 clang           0x00000000010fd99e
14 clang           0x0000000000413436
15 clang           0x0000000000413a75
16 clang           0x00000000005f8544
17 clang           0x0000000000416c09
18 clang           0x00000000004095ce
19 clang           0x000000000040c36b main + 1771
20 libc.so.6       0x00007f2c032d1abd __libc_start_main + 253
21 clang           0x0000000000407149
Stack dump:
0.    Program arguments:
/tmp/z/compiler-install/llvm-gcc-r97662-install/bin/clang -cc1 -triple
x86_64-unknown-linux-gnu -S -disable-free -main-file-name small.c
-mrelocation-model static -mdisable-fp-elim -mconstructor-aliases
-munwind-tables -target-cpu x86-64 -resource-dir
/tmp/z/compiler-install/llvm-gcc-r97662-install/lib/clang/1.1 -O2
-fmessage-length 85 -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics
-o /tmp/cc-T2FARQ.s -x c small.c 
1.    <eof> parser at end of file
2.    Code generation
3.    Running pass 'Simple Register Coalescing' on function '@func_56'
clang: error: compiler command failed due to signal 6 (use -v to see
invocation)
[regehr at gamow tmp274]$ cat small.c
int qux (int, int);

static short
foo (short left, unsigned int right)
{
  return 0;
}

static unsigned char
bar (unsigned char ui1, unsigned char ui2)
{
  return (ui2 == 0) ? ((ui1)) : (ui1 / ui2);
}

static unsigned
baz (unsigned ui1, unsigned ui2)
{
  return (ui2 == 0) ? ((ui1)) : (ui1 % ui2);
}

struct S0
{
};
int g_4[4][5];
int g_44 = 0xC733F7CFL;
int *g_87 = 0;
int **g_86 = (&g_87);
int ***g_85[1];
int *volatile g_116 = (&g_4[0][1]);
unsigned g_124 = -9L;
int g_140 = 6L;
struct S0 g_158[8] = {
};

struct S0 *g_160 = (&g_158[2]);
short g_306 = 0xFF2FL;
unsigned char g_312 = 1L;
const int func_35 (int ***p_36, unsigned p_37, int p_38, int p_39,
           unsigned p_40);
void
func_56 (long p_57, int ***p_58)
{
  signed char l_299 = 0xF5L;
  const int *l_303 = (&g_4[0][1]);
  const int **l_302 = (&l_303);
  const int ***l_301[10][3];
  int ***l_304[10];
  int ***l_305[5];
  unsigned l_307 = -3L;
  int l_308[3];
  int l_309 = -2L;
  unsigned short l_310 = 0x04DFL;
  int l_311[6][4];
  short l_313 = 0x1479L;
  unsigned long l_314 = -10L;
  int l_315 = 0L;
  struct S0 **l_316 = (&g_160);
  unsigned long l_317 = 0L;
  unsigned char l_318 = 0L;
  int i;
  for (i = 0; i < 3; i++)
    l_308[i] = 9L;
  (l_318) =
    func_35 (p_58, l_299, (**l_302),
         func_35 (l_304[8], (g_4[2][3]),
              func_35 (l_305[4],
                   (((qux ((*g_116), (***l_301[1][1]))) >
                 0xF8A779C4L) >= func_35 (g_85[0], (g_124),
                              func_35 ((&g_86),
                                   (g_44),
                                   (p_57),
                                   (*l_303),
                                   (p_57)),
                              (g_306), (g_140))),
                   ((bar ((qux ((l_307), l_308[0])), 5L)) >=
                (baz ((qux ((p_57), (l_309))), -1L))),
                   (l_310),
                   ((l_311[4][1] | (~(***l_301[1][2]))) ==
                (foo (((g_312) & (l_313)), (l_314))))), l_315,
              (0 != l_316)), (l_317));
}
[regehr at gamow tmp274]$ clang -v
clang version 1.1 (trunk)
Target: x86_64-unknown-linux-gnu
Thread model: posix

-- 
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 llvm.org  Thu Mar  4 00:55:29 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu,  4 Mar 2010 00:55:29 -0600 (CST)
Subject: [LLVMbugs] [Bug 6486] likely integer wrong code bug
In-Reply-To: <bug-6486-206@http.llvm.org/bugs/>
References: <bug-6486-206@http.llvm.org/bugs/>
Message-ID: <20100304065529.C7A092A6C12D@llvm.org>

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

Nick Lewycky <nicholas at mxc.ca> changed:

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

--- Comment #3 from Nick Lewycky <nicholas at mxc.ca> 2010-03-04 00:55:29 CST ---
Fixed in r97721,
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20100301/097244.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 llvm.org  Thu Mar  4 01:00:58 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu,  4 Mar 2010 01:00:58 -0600 (CST)
Subject: [LLVMbugs] [Bug 6490] New: Negative array dimensions allowed in
 template instantiations
Message-ID: <bug-6490-206@http.llvm.org/bugs/>

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

           Summary: Negative array dimensions allowed in template
                    instantiations
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P5
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: rideau3 at gmail.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


coppro at overthere:~$ clang -x c++ -
#include <stdio.h>

template <typename T>
struct bar {
  int i [sizeof(T)-2];
};

int main () { bar<char> b; printf("%d\n", sizeof(b.i)); };

coppro at overthere:~$ ./a.out
-4
coppro at overthere:~$

-- 
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 llvm.org  Thu Mar  4 01:12:25 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu,  4 Mar 2010 01:12:25 -0600 (CST)
Subject: [LLVMbugs] [Bug 6491] New: asmparser should check types on constant
 forward refs
Message-ID: <bug-6491-206@http.llvm.org/bugs/>

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

           Summary: asmparser should check types on constant forward refs
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: LLVM assembly language parser
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: nicholas at mxc.ca
                CC: llvmbugs at cs.uiuc.edu


The .ll parser does not reject this code:

  %fptr = type { i64(i64*)* }
  @x = constant %fptr { i64(i64*)* @foo }
  define void @foo() { unreachable }

and produces a module where @foo is defined 'i64 @foo(i64*) { unreachable }'.

-- 
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 llvm.org  Thu Mar  4 01:59:17 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu,  4 Mar 2010 01:59:17 -0600 (CST)
Subject: [LLVMbugs] [Bug 5291] JITEmitter holds iterator across set insert()
In-Reply-To: <bug-5291-206@http.llvm.org/bugs/>
References: <bug-5291-206@http.llvm.org/bugs/>
Message-ID: <20100304075917.27D592A6C124@llvm.org>

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

Jeffrey Yasskin <jyasskin at google.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED
         AssignedTo|dalej at apple.com             |jyasskin at google.com

--- Comment #1 from Jeffrey Yasskin <jyasskin at google.com> 2010-03-04 01:59:16 CST ---
Fixed by r97720.

-- 
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 llvm.org  Thu Mar  4 02:26:10 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu,  4 Mar 2010 02:26:10 -0600 (CST)
Subject: [LLVMbugs] [Bug 6492] New: NAN not a constant
Message-ID: <bug-6492-206@http.llvm.org/bugs/>

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

           Summary: NAN not a constant
           Product: clang
           Version: unspecified
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: holm at liacs.nl
                CC: llvmbugs at cs.uiuc.edu


I have tested this on the clang build distributed with Snow Leopard, so if it
has already been fixed sorry in advance.

Using the NAN macro from math.h results in this diagnostics:

nantest.c:2:11: error: initializer element is not a compile-time constant
float x = NAN;
          ^~~
/usr/include/architecture/i386/math.h:66:25: note: instantiated from:
    #define NAN         __builtin_nanf("0x7fc00000") /* Constant ...
                        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
1 diagnostic generated.


where nantest.c contains the following:
---------------
#include <math.h>
float x = NAN;
---------------

This works fine in GCC, but not in Clang and seem to be in violation of C99
7.12:5:

The macro
NAN is defined if and only if the implementation supports quiet NaNs for the
float type. It
expands to a _constant expression_ of type float representing a quiet NaN.

-- 
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 llvm.org  Thu Mar  4 02:27:18 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu,  4 Mar 2010 02:27:18 -0600 (CST)
Subject: [LLVMbugs] [Bug 6493] New: LLVM-GCC fails on simple case
Message-ID: <bug-6493-206@http.llvm.org/bugs/>

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

           Summary: LLVM-GCC fails on simple case
           Product: new-bugs
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: major
          Priority: P5
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: zhousheng00 at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Seems operation on argument of 2d array of templated class will fail llvm-gcc

for example:

template <int N>
class T {
public:
  int V;
};

T<4> test(T<4> a[4][8]) {
  return a[3][3];
}


Tested with ToT LLVM-GCC, got

test.cpp: In function \u2018T<4> test(T<4> (*)[8])\u2019:
test.cpp:7: internal compiler error: Segmentation fault
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 llvm.org  Thu Mar  4 02:37:34 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu,  4 Mar 2010 02:37:34 -0600 (CST)
Subject: [LLVMbugs] [Bug 6492] NAN not a constant
In-Reply-To: <bug-6492-206@http.llvm.org/bugs/>
References: <bug-6492-206@http.llvm.org/bugs/>
Message-ID: <20100304083734.14FD82A6C12E@llvm.org>

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

John McCall <rjmccall at apple.com> changed:

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

--- Comment #1 from John McCall <rjmccall at apple.com> 2010-03-04 02:37:33 CST ---
Yes, this has been fixed since then.  Thanks for filing the 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 llvm.org  Thu Mar  4 04:04:25 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu,  4 Mar 2010 04:04:25 -0600 (CST)
Subject: [LLVMbugs] [Bug 6447] Building C++ app fails with link error
In-Reply-To: <bug-6447-206@http.llvm.org/bugs/>
References: <bug-6447-206@http.llvm.org/bugs/>
Message-ID: <20100304100425.66D202A6C12D@llvm.org>

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

jpakkane at gmail.com changed:

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

--- Comment #3 from jpakkane at gmail.com 2010-03-04 04:04:24 CST ---
That patch fixed this error too.

-- 
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 llvm.org  Thu Mar  4 11:54:47 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu,  4 Mar 2010 11:54:47 -0600 (CST)
Subject: [LLVMbugs] [Bug 6430] Ran out of registers during register
 allocation for vfwprintf
In-Reply-To: <bug-6430-206@http.llvm.org/bugs/>
References: <bug-6430-206@http.llvm.org/bugs/>
Message-ID: <20100304175447.2DD282A6C12F@llvm.org>

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

Jakob Stoklund Olesen <stoklund at 2pi.dk> changed:

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

--- Comment #6 from Jakob Stoklund Olesen <stoklund at 2pi.dk> 2010-03-04 11:54:46 CST ---
This is probably fixed. It doesn't reproduce on trunk.

-- 
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 llvm.org  Thu Mar  4 12:08:57 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu,  4 Mar 2010 12:08:57 -0600 (CST)
Subject: [LLVMbugs] [Bug 6490] Negative array dimensions allowed in template
 instantiations
In-Reply-To: <bug-6490-206@http.llvm.org/bugs/>
References: <bug-6490-206@http.llvm.org/bugs/>
Message-ID: <20100304180857.C6D5A2A6C12C@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #2 from Douglas Gregor <dgregor at apple.com> 2010-03-04 12:08:57 CST ---
(In reply to comment #1)
> I don't think this is a bug.
> 
> sizeof returns size_t, which is an unsigned integral type, so sizeof(char)-2
> gives an unsigned result, meaning the bug summary is wrong.
> 
> The displayed result is perfectly reasonable too. size_t(-1) * 4, thanks to
> twos-complement, gives the same bit pattern as size_t(-1 * 4), and since you
> omitted the unsigned modifier on the format to printf, you're printing
> int(size_t(-4)), giving -4.

Right, the argument is unsigned, not negative. There is a bugg here, which is
that we're not diagnosing array overflow, which is here:

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

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

-- 
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 llvm.org  Thu Mar  4 12:19:01 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu,  4 Mar 2010 12:19:01 -0600 (CST)
Subject: [LLVMbugs] [Bug 6473] __attribute__ weakref is broken
In-Reply-To: <bug-6473-206@http.llvm.org/bugs/>
References: <bug-6473-206@http.llvm.org/bugs/>
Message-ID: <20100304181901.D44582A6C12F@llvm.org>

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

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

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

--- Comment #9 from Rafael ?vila de Esp?ndola <rafael.espindola at gmail.com> 2010-03-04 12:19:01 CST ---
Fixed in r97733.

-- 
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 llvm.org  Thu Mar  4 13:35:12 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu,  4 Mar 2010 13:35:12 -0600 (CST)
Subject: [LLVMbugs] [Bug 6494] New: There are no tests for GVIndirectSymbols
	in the JIT
Message-ID: <bug-6494-206@http.llvm.org/bugs/>

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

           Summary: There are no tests for GVIndirectSymbols in the JIT
           Product: libraries
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: major
          Priority: P5
         Component: Target-Independent JIT
        AssignedTo: evan.cheng at apple.com
        ReportedBy: jyasskin at google.com
                CC: llvmbugs at cs.uiuc.edu


I added an abort() to both the MR.isIndirectSymbol() branch in
JITEmitter::finishFunction and JITResolverState::getGlobalToIndirectSymMap(),
and `make check-lit` passed anyway at r97723. This makes it hard to ensure that
other changes keep it working.

-- 
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 llvm.org  Thu Mar  4 13:51:05 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu,  4 Mar 2010 13:51:05 -0600 (CST)
Subject: [LLVMbugs] [Bug 6473] __attribute__ weakref is broken
In-Reply-To: <bug-6473-206@http.llvm.org/bugs/>
References: <bug-6473-206@http.llvm.org/bugs/>
Message-ID: <20100304195105.2F1B82A6C135@llvm.org>

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

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

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

--- Comment #10 from Rafael ?vila de Esp?ndola <rafael.espindola at gmail.com> 2010-03-04 13:51:04 CST ---
We are still missing static variables that use a weakref :-(

in
----------------------
extern void foo (void);
static void bar (void) __attribute__ ((__weakref__("foo")));

static  void *const zed = (void *) &bar;

int f1(void) {
  return zed != 0;
}

int f2(void) {
  return bar != 0;
}
---------------------

We correctly avoid producing a undef for bar when compiling f2, but zed is
compiled as:

@zed = internal constant i8* bitcast (void ()* @bar to i8*), align 8

-- 
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 llvm.org  Thu Mar  4 13:54:30 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu,  4 Mar 2010 13:54:30 -0600 (CST)
Subject: [LLVMbugs] [Bug 6360] Escaped stub can be destroyed prematurely
In-Reply-To: <bug-6360-206@http.llvm.org/bugs/>
References: <bug-6360-206@http.llvm.org/bugs/>
Message-ID: <20100304195430.5036E2A6C130@llvm.org>

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

Jeffrey Yasskin <jyasskin at google.com> changed:

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

--- Comment #6 from Jeffrey Yasskin <jyasskin at google.com> 2010-03-04 13:54:29 CST ---
(Answered Albert's question offline since it's not related to this bug.)

Should be fixed by r97737. Please reopen if it's not.

-- 
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 llvm.org  Thu Mar  4 14:27:05 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu,  4 Mar 2010 14:27:05 -0600 (CST)
Subject: [LLVMbugs] [Bug 6495] New: extern const file-level variable with
 initializer raises warning
Message-ID: <bug-6495-206@http.llvm.org/bugs/>

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

           Summary: extern const file-level variable with initializer
                    raises warning
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P5
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: dlowe at bitmuse.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


This should be a warning in C, where a const file-level variable is externally
bound.  In C++, however, it is internally bound by default.  You're supposed to
use the extern keyword to bind it externally.  Doing so in clang, however,
generates the warning.

-- 
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 llvm.org  Thu Mar  4 14:36:42 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu,  4 Mar 2010 14:36:42 -0600 (CST)
Subject: [LLVMbugs] [Bug 6496] New: bad Clang diagnostics when
 signed/unsigned is combined with a typedef
Message-ID: <bug-6496-206@http.llvm.org/bugs/>

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

           Summary: bad Clang diagnostics when signed/unsigned is combined
                    with a typedef
           Product: clang
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: minor
          Priority: P5
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: zhanyong.wan at gmail.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


It's easy for a user to make the mistake of qualifying an integer typedef with
signed or unsigned.  Clang's error messages aren't very helpful:

$ cat t.cc
typedef int Integer;
typedef unsigned Integer UnsignedInteger;

void Test() {
  unsigned Integer foo;
  unsigned bar = (unsigned Integer)-1;
}

$ clang t.cc
t.cc:2:18: error: typedef redefinition with different types ('unsigned int' vs
'int')
typedef unsigned Integer UnsignedInteger;
                 ^
t.cc:1:13: note: previous definition is here
typedef int Integer;
            ^
t.cc:2:25: error: invalid token after top level declarator
typedef unsigned Integer UnsignedInteger;
                        ^
                        ;
t.cc:5:19: error: expected ';' at end of declaration
  unsigned Integer foo;
                  ^
                  ;
t.cc:6:28: error: expected ')'
  unsigned bar = (unsigned Integer)-1;
                           ^
t.cc:6:18: note: to match this '('
  unsigned bar = (unsigned Integer)-1;
                 ^
6 diagnostics generated.

I'd expect to see something like "'unsigned' cannot be combined with a typedef
('Integer')."

-- 
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 llvm.org  Thu Mar  4 14:42:46 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu,  4 Mar 2010 14:42:46 -0600 (CST)
Subject: [LLVMbugs] [Bug 6489] ice: Cannot find live range
In-Reply-To: <bug-6489-206@http.llvm.org/bugs/>
References: <bug-6489-206@http.llvm.org/bugs/>
Message-ID: <20100304204246.C35862A6C12D@llvm.org>

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

Jakob Stoklund Olesen <stoklund at 2pi.dk> changed:

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

--- Comment #2 from Jakob Stoklund Olesen <stoklund at 2pi.dk> 2010-03-04 14:42:46 CST ---
Fixed in r97742

-- 
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 llvm.org  Thu Mar  4 15:02:14 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu,  4 Mar 2010 15:02:14 -0600 (CST)
Subject: [LLVMbugs] [Bug 3153] OCaml binding's Makefile.ocaml creates
	incorrect symlinks
In-Reply-To: <bug-3153-206@http.llvm.org/bugs/>
References: <bug-3153-206@http.llvm.org/bugs/>
Message-ID: <20100304210214.F044A2A6C12E@llvm.org>

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

Erick Tryzelaar <idadesub at users.sourceforge.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |idadesub at users.sourceforge.
                   |                            |net
         Resolution|                            |FIXED

--- Comment #7 from Erick Tryzelaar <idadesub at users.sourceforge.net> 2010-03-04 15:02:14 CST ---
Finally fixed in r97743!

-- 
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 llvm.org  Thu Mar  4 15:05:01 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu,  4 Mar 2010 15:05:01 -0600 (CST)
Subject: [LLVMbugs] [Bug 6480] ARM Codegen asserts Running pass 'Control
 Flow Optimizer' on function '@"java.lang.String::getChars"'
In-Reply-To: <bug-6480-206@http.llvm.org/bugs/>
References: <bug-6480-206@http.llvm.org/bugs/>
Message-ID: <20100304210501.B23D72A6C131@llvm.org>

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

Bob Wilson <bob.wilson at apple.com> changed:

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

--- Comment #7 from Bob Wilson <bob.wilson at apple.com> 2010-03-04 15:05:01 CST ---
Fixed in svn r97745.

-- 
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 llvm.org  Thu Mar  4 15:05:35 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu,  4 Mar 2010 15:05:35 -0600 (CST)
Subject: [LLVMbugs] [Bug 6333] SIGSEGV in 'X86 DAG->DAG Instruction
	Selection'
In-Reply-To: <bug-6333-206@http.llvm.org/bugs/>
References: <bug-6333-206@http.llvm.org/bugs/>
Message-ID: <20100304210535.69E152A6C12E@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #1 from Chris Lattner <clattner at apple.com> 2010-03-04 15:05:35 CST ---
Unfortunately this testcase was broken by recent llvm .bc changes. Can you
reduce a new testcase?

-- 
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 llvm.org  Thu Mar  4 15:22:07 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu,  4 Mar 2010 15:22:07 -0600 (CST)
Subject: [LLVMbugs] [Bug 3383] Assertion failed: Only trivial
 vector-to-scalar conversions should get here!
In-Reply-To: <bug-3383-206@http.llvm.org/bugs/>
References: <bug-3383-206@http.llvm.org/bugs/>
Message-ID: <20100304212207.D7A0A2A6C124@llvm.org>

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

Dan Gohman <gohman at apple.com> changed:

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

--- Comment #2 from Dan Gohman <gohman at apple.com> 2010-03-04 15:22:07 CST ---
This now works on TOT.

-- 
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 llvm.org  Thu Mar  4 15:28:06 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu,  4 Mar 2010 15:28:06 -0600 (CST)
Subject: [LLVMbugs] [Bug 6473] __attribute__ weakref is broken
In-Reply-To: <bug-6473-206@http.llvm.org/bugs/>
References: <bug-6473-206@http.llvm.org/bugs/>
Message-ID: <20100304212806.97C052A6C12E@llvm.org>

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

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

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

--- Comment #12 from Rafael ?vila de Esp?ndola <rafael.espindola at gmail.com> 2010-03-04 15:28:06 CST ---
fixed in r97750

-- 
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 llvm.org  Thu Mar  4 15:43:04 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu,  4 Mar 2010 15:43:04 -0600 (CST)
Subject: [LLVMbugs] [Bug 6478] ARM CodeGen Running pass 'Prolog/Epilog
 Insertion & Frame Finalization' on function '@"java.lang.String::getChars"'
In-Reply-To: <bug-6478-206@http.llvm.org/bugs/>
References: <bug-6478-206@http.llvm.org/bugs/>
Message-ID: <20100304214304.B71D52A6C12F@llvm.org>

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

Bob Wilson <bob.wilson at apple.com> changed:

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

--- Comment #7 from Bob Wilson <bob.wilson at apple.com> 2010-03-04 15:43:04 CST ---
Fixed in svn r97755.

-- 
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 llvm.org  Thu Mar  4 15:45:31 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu,  4 Mar 2010 15:45:31 -0600 (CST)
Subject: [LLVMbugs] [Bug 6497] New: Assertion failed:
 (Node2Index[SU->NodeNum] > Node2Index[I->getSUnit()->NodeNum] && "Wrong
 topological sorting"), function InitDAGTopologicalSorting,
 file ScheduleDAG.cpp, line 462.
Message-ID: <bug-6497-206@http.llvm.org/bugs/>

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

           Summary: Assertion failed: (Node2Index[SU->NodeNum] >
                    Node2Index[I->getSUnit()->NodeNum] && "Wrong
                    topological sorting"), function
                    InitDAGTopologicalSorting, file ScheduleDAG.cpp, line
                    462.
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: FreeBSD
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: Common Code Generator Code
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: rdivacky at freebsd.org
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=4392)
 --> (http://llvm.org/bugs/attachment.cgi?id=4392)
testt case

on i386 I am getting this assert when compiling the attached with

clang -O2 r600_cp.c

I believe this is quite recent, it definitely wasnt there on Feb 13th

-- 
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 llvm.org  Thu Mar  4 16:00:38 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu,  4 Mar 2010 16:00:38 -0600 (CST)
Subject: [LLVMbugs] [Bug 6498] New: use .p2align instead of .align
Message-ID: <bug-6498-206@http.llvm.org/bugs/>

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

           Summary: use .p2align instead of .align
           Product: compiler-rt
           Version: unspecified
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P5
         Component: compiler-rt
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: gohman at apple.com
                CC: llvmbugs at cs.uiuc.edu


compiler-rt currently uses .align directives for what appear to be intended as
power-of-2 alignment.  The .p2align directive should be used instead, as .align
means byte alignment on some targets.

-- 
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 llvm.org  Thu Mar  4 16:32:42 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu,  4 Mar 2010 16:32:42 -0600 (CST)
Subject: [LLVMbugs] [Bug 6499] New: clang can't produce jit code with glibc
Message-ID: <bug-6499-206@http.llvm.org/bugs/>

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

           Summary: clang can't produce jit code with glibc
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: minor
          Priority: P5
         Component: Driver
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: castet.matthieu at free.fr
                CC: llvmbugs at cs.uiuc.edu


clang identify as gcc, but in new glibc header if gcc is detected some function
in header are optimized as inline asm.

For example select.h contains [1]. This make llvm bytecode not runnable with
lli jit :

LLVM ERROR: JIT does not support inline asm!



[1]
#if defined __GNUC__ && __GNUC__ >= 2

# if __WORDSIZE == 64
#  define __FD_ZERO_STOS "stosq"
#  define __FD_SET_BTS "btsq"
#  define __FD_CLR_BTR "btrq"
#  define __FD_ISSET_BT "btq"
# else
#  define __FD_ZERO_STOS "stosl"
#  define __FD_SET_BTS "btsl"
#  define __FD_CLR_BTR "btrl"
#  define __FD_ISSET_BT "btl"
# endif
# define __FD_ZERO(fdsp) \
  do {                                                                        \
    int __d0, __d1;                                                           \
    __asm__ __volatile__ ("cld; rep; " __FD_ZERO_STOS                         \
                          : "=c" (__d0), "=D" (__d1)                          \
                          : "a" (0), "0" (sizeof (fd_set)                     \
                                          / sizeof (__fd_mask)),              \
                            "1" (&__FDS_BITS (fdsp)[0])                       \
                          : "memory");                                        \
  } while (0)

#else
# define __FD_ZERO(set)  \
  do {                                                                        \
    unsigned int __i;                                                         \
    fd_set *__arr = (set);                                                    \
    for (__i = 0; __i < sizeof (fd_set) / sizeof (__fd_mask); ++__i)          \
      __FDS_BITS (__arr)[__i] = 0;                                            \
  } while (0)
#endif

-- 
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 llvm.org  Thu Mar  4 16:39:05 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu,  4 Mar 2010 16:39:05 -0600 (CST)
Subject: [LLVMbugs] [Bug 6499] clang can't produce jit code with glibc
In-Reply-To: <bug-6499-206@http.llvm.org/bugs/>
References: <bug-6499-206@http.llvm.org/bugs/>
Message-ID: <20100304223905.5A7822A6C12E@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #1 from Chris Lattner <clattner at apple.com> 2010-03-04 16:39:04 CST ---
The JIT doesn't support inline asm, this is covered by PR1343

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

-- 
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 llvm.org  Thu Mar  4 17:06:02 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu,  4 Mar 2010 17:06:02 -0600 (CST)
Subject: [LLVMbugs] [Bug 6500] New: lli -force-interpreter crash with asm
	inline
Message-ID: <bug-6500-206@http.llvm.org/bugs/>

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

           Summary: lli -force-interpreter crash with asm inline
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: Interpreter
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: castet.matthieu at free.fr
                CC: llvmbugs at cs.uiuc.edu


$ cat test.ll 
; ModuleID = 'test.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-f80:32:32-n8:16:32"
target triple = "i386-unknown-linux-gnu"

define i32 @main() nounwind {
entry:
  tail call void asm sideeffect "ff_mlp_firorder_0:",
"~{dirflag},~{fpsr},~{flags}"() nounwind
  ret i32 0
}

$ lli -force-interpreter test.bc
0  lli 0x086dfa58
Stack dump:
0.      Program arguments: lli -force-interpreter test.bc 
Segmentation fault

-- 
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 llvm.org  Thu Mar  4 17:12:40 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu,  4 Mar 2010 17:12:40 -0600 (CST)
Subject: [LLVMbugs] [Bug 6500] lli -force-interpreter crash with asm inline
In-Reply-To: <bug-6500-206@http.llvm.org/bugs/>
References: <bug-6500-206@http.llvm.org/bugs/>
Message-ID: <20100304231240.AA5062A6C124@llvm.org>

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

Nick Lewycky <nlewycky at google.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |nlewycky at google.com
         Resolution|                            |INVALID

--- Comment #1 from Nick Lewycky <nlewycky at google.com> 2010-03-04 17:12:40 CST ---
What did you expect, exactly?

If you want a clean error + abort() upon trying to interpret inline assembly,
please implement it and send the patch to llvm-commits.

-- 
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 llvm.org  Thu Mar  4 19:11:41 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu,  4 Mar 2010 19:11:41 -0600 (CST)
Subject: [LLVMbugs] [Bug 6501] New: QOI: arguments passed/required mismatch
	diagnostic
Message-ID: <bug-6501-206@http.llvm.org/bugs/>

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

           Summary: QOI: arguments passed/required mismatch diagnostic
           Product: clang
           Version: trunk
          Platform: Macintosh
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: Semantic Analyzer
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: echristo at gmail.com
                CC: llvmbugs at cs.uiuc.edu


It would be useful when emitting a diagnostic for "too many/few arguments to
{thing} x" that it provide some numbers of what the expected and seen number of
arguments were.

-- 
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 llvm.org  Thu Mar  4 19:25:58 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu,  4 Mar 2010 19:25:58 -0600 (CST)
Subject: [LLVMbugs] [Bug 6502] New: Clang complains about indirect goto
 jumping over initializations where GCC doesn't
Message-ID: <bug-6502-206@http.llvm.org/bugs/>

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

           Summary: Clang complains about indirect goto jumping over
                    initializations where GCC doesn't
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P5
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: chandlerc at gmail.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


I know this code is terrifying, but some code generators produce this type of
pattern. The rationale for the combined switch and manually built indirect goto
table is to turn the goto-based solution off on compilers which don't support
it, and on for those that do. I haven't tried to reduce it by de-interleaving
them, not sure if that's relevant or not. It might be possible to reduce this
further, but this makes it an "interesting" test case without being enormous.

% cat t.cc                      
bool f(const unsigned* indices) {
  static void* const dispatch_table[] = {
    &&L1,
    &&LEND,
  };
  for (const unsigned* next = indices; ; ) {
    goto *dispatch_table[*next];
    switch (*(next)) {
L1:
      case 0: {
        const int foo = 1.0;
        (void)foo;
        goto *dispatch_table[*(++next)];
        break;
      }
LEND:
      case 1:
      return true;
    }
  }
}

% ./bin/clang -fsyntax-only t.cc
t.cc:13:9: error: illegal indirect goto in protected scope, unknown effect on
scopes
        goto *dispatch_table[*(++next)];
        ^
t.cc:11:19: note: jump bypasses variable initialization
        const int foo = 1.0;
                  ^
t.cc:6:24: note: jump bypasses variable initialization
  for (const unsigned* next = indices; ; ) {
                       ^
t.cc:7:5: error: illegal indirect goto in protected scope, unknown effect on
scopes
    goto *dispatch_table[*next];
    ^
t.cc:6:24: note: jump bypasses variable initialization
  for (const unsigned* next = indices; ; ) {
                       ^
t.cc:4:5: error: address taken of label in protected scope, jump to it would
have unknown effect on scope
    &&LEND,
    ^
t.cc:6:24: note: jump bypasses variable initialization
  for (const unsigned* next = indices; ; ) {
                       ^
t.cc:3:5: error: address taken of label in protected scope, jump to it would
have unknown effect on scope
    &&L1,
    ^
t.cc:6:24: note: jump bypasses variable initialization
  for (const unsigned* next = indices; ; ) {
                       ^
9 diagnostics generated.

-- 
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 llvm.org  Thu Mar  4 22:29:13 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu,  4 Mar 2010 22:29:13 -0600 (CST)
Subject: [LLVMbugs] [Bug 6503] New: ice: replaceAllUses of value with new
 value of different type!
Message-ID: <bug-6503-206@http.llvm.org/bugs/>

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

           Summary: ice: replaceAllUses of value with new value of
                    different type!
           Product: new-bugs
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: regehr at cs.utah.edu
                CC: llvmbugs at cs.uiuc.edu, chenyang at cs.utah.edu


Created an attachment (id=4394)
 --> (http://llvm.org/bugs/attachment.cgi?id=4394)
failure-inducing input

Seen on x86.

regehr at john-home:~/volatile/bugs/tmp274$ clang -v
clang version 1.1 (trunk)
Target: i386-pc-linux-gnu
Thread model: posix

regehr at john-home:~/volatile/bugs/tmp274$ clang -O2 small.c

clang: Value.cpp:317: void llvm::Value::replaceAllUsesWith(llvm::Value*):
Assertion `New->getType() == getType() && "replaceAllUses of value with new
value of different type!"' failed.
0  clang 0x08edbe18
Stack dump:
0.    Program arguments:
/home/regehr/z/compiler-install/llvm-gcc-r97760-install/bin/clang -cc1 -triple
i386-pc-linux-gnu -S -disable-free -main-file-name small.c -mrelocation-model
static -mdisable-fp-elim -mconstructor-aliases -target-cpu pentium4
-resource-dir
/home/regehr/z/compiler-install/llvm-gcc-r97760-install/lib/clang/1.1 -O2
-fmessage-length 85 -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics
-o /tmp/cc-mau7RF.s -x c small.c 
1.    <eof> parser at end of file
2.    Per-function optimization
3.    Running pass 'Combine redundant instructions' on function '@int327'
clang: error: compiler command failed due to signal 6 (use -v to see
invocation)

regehr at john-home:~/volatile/bugs/tmp274$ clang small.c -emit-llvm -S

regehr at john-home:~/volatile/bugs/tmp274$ opt -O2 small.s -o /dev/null

opt: Value.cpp:317: void llvm::Value::replaceAllUsesWith(llvm::Value*):
Assertion `New->getType() == getType() && "replaceAllUses of value with new
value of different type!"' failed.
0  opt 0x084aaae8
Stack dump:
0.    Program arguments: opt -O2 small.s -o /dev/null 
1.    Running pass 'Combine redundant instructions' on function '@int327'
Aborted

-- 
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 llvm.org  Fri Mar  5 00:20:06 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri,  5 Mar 2010 00:20:06 -0600 (CST)
Subject: [LLVMbugs] [Bug 6497] Assertion failed: (Node2Index[SU->NodeNum] >
 Node2Index[I->getSUnit()->NodeNum] && "Wrong topological sorting"),
 function InitDAGTopologicalSorting, file ScheduleDAG.cpp, line 462.
In-Reply-To: <bug-6497-206@http.llvm.org/bugs/>
References: <bug-6497-206@http.llvm.org/bugs/>
Message-ID: <20100305062006.D6F892A6C12D@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #5 from Chris Lattner <clattner at apple.com> 2010-03-05 00:20:06 CST ---
Fixed here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20100301/097309.html

Scary regression, thanks for reporting it!

-- 
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 llvm.org  Fri Mar  5 01:59:30 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri,  5 Mar 2010 01:59:30 -0600 (CST)
Subject: [LLVMbugs] [Bug 6504] New: BitVector's copy assignment triggers
 debug assert in MSVC2010
Message-ID: <bug-6504-206@http.llvm.org/bugs/>

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

           Summary: BitVector's copy assignment triggers debug assert in
                    MSVC2010
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: critical
          Priority: P5
         Component: Support Libraries
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: ahmedcharles at gmail.com
                CC: llvmbugs at cs.uiuc.edu


MSVC2010 is a bit too aggressive in checking iterators (and pointers) for
validity when performing various algorithms in debug mode. This includes
verifying that output iterators that are pointers are not null. In the case of
std::copy it is conformant to pass a null pointer as an output iterator as long
as there are no elements to copy. However, I'd recommend changing this so that
std::copy is only called when there are elements to copy.

The relevant line is:

include/llvm/ADT/BitVector.h:332

-- 
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 llvm.org  Fri Mar  5 02:26:04 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri,  5 Mar 2010 02:26:04 -0600 (CST)
Subject: [LLVMbugs] [Bug 6387] [2.7] ice: dag combine assertion
In-Reply-To: <bug-6387-206@http.llvm.org/bugs/>
References: <bug-6387-206@http.llvm.org/bugs/>
Message-ID: <20100305082604.5B5422A6C12D@llvm.org>

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

Duncan Sands <baldrick at free.fr> changed:

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

--- Comment #5 from Duncan Sands <baldrick at free.fr> 2010-03-05 02:26:03 CST ---
This seems to have been 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 llvm.org  Fri Mar  5 02:34:26 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri,  5 Mar 2010 02:34:26 -0600 (CST)
Subject: [LLVMbugs] [Bug 6500] lli -force-interpreter crash with asm inline
In-Reply-To: <bug-6500-206@http.llvm.org/bugs/>
References: <bug-6500-206@http.llvm.org/bugs/>
Message-ID: <20100305083426.E10792A6C12C@llvm.org>

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

Matthieu castet <castet.matthieu at free.fr> changed:

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

--- Comment #2 from Matthieu castet <castet.matthieu at free.fr> 2010-03-05 02:34:26 CST ---
This is a little hard.

I don't except random crash from programs. They should catch error and inform
the user what he has done wrong.

I am not interested in implementing a patch ATM, the purpose of this bug was to
be a reminder (from me or other) to implement a proper thing.

-- 
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 llvm.org  Fri Mar  5 02:38:14 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri,  5 Mar 2010 02:38:14 -0600 (CST)
Subject: [LLVMbugs] [Bug 6505] New: EquivalenceClasses::ECValue's private
 constructor is inaccessible when combined with a rvalue reference aware
 STL.
Message-ID: <bug-6505-206@http.llvm.org/bugs/>

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

           Summary: EquivalenceClasses::ECValue's private constructor is
                    inaccessible when combined with a rvalue reference
                    aware STL.
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: Support Libraries
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: ahmedcharles at gmail.com
                CC: llvmbugs at cs.uiuc.edu


EquivalenceClasses::ECValue has an implicit, private constructor which ends up
getting called in the following places:

include/llvm/ADT/EquivalenceClasses.h:193
include/llvm/ADT/EquivalenceClasses.h:206

Rvalue reference versions of set::find and set::insert will be used to forward
the arguments rather than force the construction of the ECValue type within the
EquivalenceClasses members. This is meant to be a performance optimization
because it results in less constructions of ECValue. The fix which results in
the same behavior as today is to explicitly call the ECValue constructor when
passing the value to both methods above.

-- 
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 llvm.org  Fri Mar  5 02:45:29 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri,  5 Mar 2010 02:45:29 -0600 (CST)
Subject: [LLVMbugs] [Bug 6506] New: Ambiguous calls to llvm::next.
Message-ID: <bug-6506-206@http.llvm.org/bugs/>

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

           Summary: Ambiguous calls to llvm::next.
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: critical
          Priority: P5
         Component: Common Code Generator Code
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: ahmedcharles at gmail.com
                CC: llvmbugs at cs.uiuc.edu


C++0x adds std::next (and std::prev). std::next conflicts with llvm::next when
used on a type within the std namespace because of ADL. Explicitly qualifying
these calls will result in the ambiguity being resolved, in favor of the llvm::
version.

lib/CodeGen/Spiller.cpp:442
lib/CodeGen/Spiller.cpp:443
lib/Transforms/Scalar/LoopStrengthReduce.cpp:2820

-- 
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 llvm.org  Fri Mar  5 02:48:19 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri,  5 Mar 2010 02:48:19 -0600 (CST)
Subject: [LLVMbugs] [Bug 6503] ice: replaceAllUses of value with new value
 of different type!
In-Reply-To: <bug-6503-206@http.llvm.org/bugs/>
References: <bug-6503-206@http.llvm.org/bugs/>
Message-ID: <20100305084819.198FA2A6C12E@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #4 from Chris Lattner <clattner at apple.com> 2010-03-05 02:48:18 CST ---
No really,  fixed here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20100301/097318.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 llvm.org  Fri Mar  5 03:02:16 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri,  5 Mar 2010 03:02:16 -0600 (CST)
Subject: [LLVMbugs] [Bug 6507] New: Forwarding 0 as a pointer using rvalue
 references doesn't work
Message-ID: <bug-6507-206@http.llvm.org/bugs/>

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

           Summary: Forwarding 0 as a pointer using rvalue references
                    doesn't work
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: critical
          Priority: P5
         Component: Core LLVM classes
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: ahmedcharles at gmail.com
                CC: llvmbugs at cs.uiuc.edu


std::pair in c++0x has additional constructor overloads which take rvalue
references and forward them to the stored type's constructors. Rvalue
references forward 0 as an int rather than as a pointer. nullptr can be used to
solve this problem, but since that is not universally supported,
static_cast'ing the 0 to the expected pointer type is sufficient.

lib/CodeGen/SelectionDAG/TargetLowering.cpp:2402
lib/CodeGen/SelectionDAG/TargetLowering.cpp:2434
lib/Transforms/Utils/PromoteMemoryToRegister.cpp:864

-- 
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 llvm.org  Fri Mar  5 03:05:38 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri,  5 Mar 2010 03:05:38 -0600 (CST)
Subject: [LLVMbugs] [Bug 6508] New: Forwarding 0 as a pointer using rvalue
 references doesn't work
Message-ID: <bug-6508-206@http.llvm.org/bugs/>

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

           Summary: Forwarding 0 as a pointer using rvalue references
                    doesn't work
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: AST
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: ahmedcharles at gmail.com
                CC: llvmbugs at cs.uiuc.edu


std::pair in c++0x has additional constructor overloads which take rvalue
references and forward them to the stored type's constructors. Rvalue
references forward 0 as an int rather than as a pointer. nullptr can be used to
solve this problem, but since that is not universally supported,
static_cast'ing the 0 to the expected pointer type is sufficient.

include/clang/Analysis/ProgramPoint.h:62
include/clang/AST/DeclContextInternals.h:157
lib/AST/DeclBase.cpp:796
lib/AST/DeclBase.cpp:802
lib/AST/Expr.cpp:2160
lib/AST/Expr.cpp:2162
lib/Checker/GRExprEngine.cpp:1872

-- 
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 llvm.org  Fri Mar  5 03:14:59 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri,  5 Mar 2010 03:14:59 -0600 (CST)
Subject: [LLVMbugs] [Bug 6509] New: Compile error results in MSVC not
	compiling llvm.
Message-ID: <bug-6509-206@http.llvm.org/bugs/>

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

           Summary: Compile error results in MSVC not compiling llvm.
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: critical
          Priority: P5
         Component: Transformation Utilities
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: ahmedcharles at gmail.com
                CC: llvmbugs at cs.uiuc.edu


There is an ifdef section which defines setjmp -> _setjmp. Because this
replacement is applied liberally.

lib/Transforms/Utils/LowerInvoke.cpp:147 and 156

The most trivial change at this point would be to remove the mmvc specific
ifdef's and just not replace the name.

-- 
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 llvm.org  Fri Mar  5 04:13:26 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri,  5 Mar 2010 04:13:26 -0600 (CST)
Subject: [LLVMbugs] [Bug 6510] New: PM doesn't terminate when processing
 passes with circular dependency + patch
Message-ID: <bug-6510-206@http.llvm.org/bugs/>

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

           Summary: PM doesn't terminate when processing passes with
                    circular dependency + patch
           Product: libraries
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P5
         Component: Core LLVM classes
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: philipp.legrum at daimler.com
                CC: llvmbugs at cs.uiuc.edu


The LLVM Pass manager gets caught in an infinite recursion when dealing with
passes that have a circular dependency ultimately resulting in a stack
overflow.

I created a patch that tracks the recursive insertion of passes monitoring if
the manager inserts a pass that it is currently inserting in an outer
invocation of PMTopLevelManager::schedulePass.

The modification now aborts more gracefully printing out the cyclic dependency.

Patch needs review.

-- 
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 llvm.org  Fri Mar  5 05:53:37 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri,  5 Mar 2010 05:53:37 -0600 (CST)
Subject: [LLVMbugs] [Bug 6511] New: clang++ tries to invoke g++
Message-ID: <bug-6511-206@http.llvm.org/bugs/>

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

           Summary: clang++ tries to invoke g++
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: blocker
          Priority: P5
         Component: Driver
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: Axel.Naumann at cern.ch
                CC: llvmbugs at cs.uiuc.edu


I have built the current trunk of clang + llvm with MSVC 2008 in debug with
CMake. I get

c:\ROOT\llvm\AxelTest>clang++ -v t.cxx

Target: i686-pc-win32
Thread model: posix
 "c:/ROOT/llvm/obj/bin/Debug/clang.exe" -cc1 -triple i686-pc-win32 -S
-disable-f
ree -main-file-name t.cxx -mrelocation-model static -mdisable-fp-elim
-mconstruc
tor-aliases -v -resource-dir c:/ROOT/llvm/obj/bin/lib/clang/1.1
-fmessage-length
 80 -fexceptions -fms-extensions -fgnu-runtime -fdiagnostics-show-option
-fcolor
-diagnostics -o C:/Users/axel/AppData/Local/Temp/cc-000000.s -x c++ t.cxx
clang -cc1 version 1.1 based upon llvm 2.7svn hosted on i686-pc-win32
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory "/usr/include"
#include "..." search starts here:
#include <...> search starts here:
 c:/ROOT/llvm/obj/bin/lib/clang/1.1/include
 c:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\include
 C:\Program Files\Microsoft SDKs\Windows\v6.0A
End of search list.
 "g++" -v -c -o C:/Users/axel/AppData/Local/Temp/cc-000001.o -x assembler
C:/Use
rs/axel/AppData/Local/Temp/cc-000000.s
clang++: error: unable to execute command: program not executable
clang++: error: assembler command failed due to signal 1 (use -v to see
invocati
on)

And yes, clang (without "++") tries to invoke gcc. Is there a configuration
step that I have overlooked?

Cheers, Axel.

-- 
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 llvm.org  Fri Mar  5 07:11:59 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri,  5 Mar 2010 07:11:59 -0600 (CST)
Subject: [LLVMbugs] [Bug 6511] clang++ tries to invoke g++
In-Reply-To: <bug-6511-206@http.llvm.org/bugs/>
References: <bug-6511-206@http.llvm.org/bugs/>
Message-ID: <20100305131159.385CB2A6C124@llvm.org>

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

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

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

--- Comment #1 from Anton Korobeynikov <asl at math.spbu.ru> 2010-03-05 07:11:58 CST ---
> And yes, clang (without "++") tries to invoke gcc. Is there a configuration
> step that I have overlooked?
No. gcc is invoked for assembling / linking of the compiler 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 llvm.org  Fri Mar  5 12:03:27 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri,  5 Mar 2010 12:03:27 -0600 (CST)
Subject: [LLVMbugs] [Bug 6512] New: problem with INSTCOMBINE phi node with
 loads from different address spaces
Message-ID: <bug-6512-206@http.llvm.org/bugs/>

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

           Summary: problem with INSTCOMBINE phi node with loads from
                    different address spaces
           Product: new-bugs
           Version: trunk
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: normal
          Priority: P5
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: bixia.zheng at amd.com
                CC: llvmbugs at cs.uiuc.edu


Error message (opt -O3):

INSTCOMBINE ITERATION #0 on foo
....
IC: Visiting:   br label %if.end
IC: Visiting:   %res.0 = phi i32 [ %tmp2, %if.then ], [ %tmp5, %if.else ] ;
<i32> [#uses=1]
Assertion failed: getType() == V->getType() && "All operands to PHI node must
be the same type as the PHI node!", file ....\llvm\include\llvm/Instructions.h,
line 1821




Test case:

define i32 @foo(i32 addrspace(1)* %pointer1, i32 %flag, i32* %pointer2)
nounwind {
entry:
  %retval = alloca i32, align 4                   ; <i32*> [#uses=2]
  %pointer1.addr = alloca i32 addrspace(1)*, align 4 ; <i32 addrspace(1)**>
[#uses=2]
  %flag.addr = alloca i32, align 4                ; <i32*> [#uses=2]
  %pointer2.addr = alloca i32*, align 4           ; <i32**> [#uses=2]
  %res = alloca i32, align 4                      ; <i32*> [#uses=4]
  store i32 addrspace(1)* %pointer1, i32 addrspace(1)** %pointer1.addr
  store i32 %flag, i32* %flag.addr
  store i32* %pointer2, i32** %pointer2.addr
  store i32 10, i32* %res
  %tmp = load i32* %flag.addr                     ; <i32> [#uses=1]
  %tobool = icmp ne i32 %tmp, 0                   ; <i1> [#uses=1]
  br i1 %tobool, label %if.then, label %if.else

return:                                           ; preds = %if.end
  %tmp7 = load i32* %retval                       ; <i32> [#uses=1]
  ret i32 %tmp7

if.end:                                           ; preds = %if.else, %if.then
  %tmp6 = load i32* %res                          ; <i32> [#uses=1]
  store i32 %tmp6, i32* %retval
  br label %return

if.then:                                          ; preds = %entry
  %tmp1 = load i32 addrspace(1)** %pointer1.addr  ; <i32 addrspace(1)*>
[#uses=1]
  %arrayidx = getelementptr i32 addrspace(1)* %tmp1, i32 0 ; <i32
addrspace(1)*> [#uses=1]
  %tmp2 = load i32 addrspace(1)* %arrayidx        ; <i32> [#uses=1]
  store i32 %tmp2, i32* %res
  br label %if.end

if.else:                                          ; preds = %entry
  %tmp3 = load i32** %pointer2.addr               ; <i32*> [#uses=1]
  %arrayidx4 = getelementptr i32* %tmp3, i32 0    ; <i32*> [#uses=1]
  %tmp5 = load i32* %arrayidx4                    ; <i32> [#uses=1]
  store i32 %tmp5, i32* %res
  br label %if.end
}

-- 
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 llvm.org  Fri Mar  5 12:09:45 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri,  5 Mar 2010 12:09:45 -0600 (CST)
Subject: [LLVMbugs] [Bug 6513] New: crash on invalid (enum forward decl in
 template arg list)
Message-ID: <bug-6513-206@http.llvm.org/bugs/>

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

           Summary: crash on invalid (enum forward decl in template arg
                    list)
           Product: clang
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: minor
          Priority: P5
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: ggreif at gmail.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


Compile this with clang++:

$ cat abc.cpp
template <enum PortRole ROLE, typename FACILITY, template <enum PortRole,
typename> class GOVERN>
class Role : public FACILITY, protected GOVERN<ROLE, FACILITY>
{
    friend class GOVERN<ROLE, FACILITY>;
};
$ /phys/mfs/hc_rap/tools/llvm/Release/bin/clang abc.cpp -o /dev/null
abc.cpp:1:16: error: ISO C++ forbids forward references to 'enum' types
template <enum PortRole ROLE, typename FACILITY, template <enum PortRole,
typename> class GOVERN>

               ^

---> CRASH!

-- 
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 llvm.org  Fri Mar  5 12:13:40 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri,  5 Mar 2010 12:13:40 -0600 (CST)
Subject: [LLVMbugs] [Bug 6514] New: valid template code rejected (friend
 decl. misinterpreted)
Message-ID: <bug-6514-206@http.llvm.org/bugs/>

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

           Summary: valid template code rejected (friend decl.
                    misinterpreted)
           Product: clang
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P5
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: ggreif at gmail.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


template <int N, template <int> class GOVERN>
class Role : public GOVERN<N>
{
    friend class GOVERN<N>;
};

/*

abc.cpp:4:18: error: cannot specialize a template template parameter
    friend class GOVERN<N>;
                 ^
1 diagnostic generated.


- G++ digests this.
- comeau too.

*/

-- 
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 llvm.org  Fri Mar  5 12:24:03 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri,  5 Mar 2010 12:24:03 -0600 (CST)
Subject: [LLVMbugs] [Bug 6515] New: gcc compat: __builtin_signbit doesn't
 appear to be supported
Message-ID: <bug-6515-206@http.llvm.org/bugs/>

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

           Summary: gcc compat: __builtin_signbit doesn't appear to be
                    supported
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: minor
          Priority: P5
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: srp at srparish.net
                CC: llvmbugs at cs.uiuc.edu


I'm getting the following when trying to build a code base that is typically
built with gcc -std=gnu99:

  error: implicit declaration of function '__builtin_signbit' is invalid in C99

-- 
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 llvm.org  Fri Mar  5 12:53:50 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri,  5 Mar 2010 12:53:50 -0600 (CST)
Subject: [LLVMbugs] [Bug 6512] problem with INSTCOMBINE phi node with loads
 from different address spaces
In-Reply-To: <bug-6512-206@http.llvm.org/bugs/>
References: <bug-6512-206@http.llvm.org/bugs/>
Message-ID: <20100305185350.D9DD72A6C12C@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #1 from Chris Lattner <clattner at apple.com> 2010-03-05 12:53:50 CST ---
Fixed here, thanks:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20100301/097331.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 llvm.org  Fri Mar  5 13:27:21 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri,  5 Mar 2010 13:27:21 -0600 (CST)
Subject: [LLVMbugs] [Bug 6502] Clang complains about indirect goto jumping
 over initializations where GCC doesn't
In-Reply-To: <bug-6502-206@http.llvm.org/bugs/>
References: <bug-6502-206@http.llvm.org/bugs/>
Message-ID: <20100305192721.CE9CD2A6C124@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #3 from Chris Lattner <clattner at apple.com> 2010-03-05 13:27:21 CST ---
Done here:
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20100301/028173.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 llvm.org  Fri Mar  5 14:22:20 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri,  5 Mar 2010 14:22:20 -0600 (CST)
Subject: [LLVMbugs] [Bug 6516] New: Assertion failed: (I != FieldInfo.end()
 && "Unable to find field info")
Message-ID: <bug-6516-206@http.llvm.org/bugs/>

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

           Summary: Assertion failed: (I != FieldInfo.end() && "Unable to
                    find field info")
           Product: clang
           Version: trunk
          Platform: Other
        OS/Version: FreeBSD
            Status: NEW
          Severity: normal
          Priority: P5
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: hinokind at gmail.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


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

$ clang assert16-min.cc 
Assertion failed: (I != FieldInfo.end() && "Unable to find field info"),
function getLLVMFieldNo, file CodeGenTypes.cpp, line 471.
Stack dump:
0.    Program arguments: /usr/local/bin/clang -cc1 -triple
x86_64-unknown-freebsd8.0 -S -disable-free -main-file-name assert16-min.cc
-mrelocation-model static -mdisable-fp-elim -mconstructor-aliases
-munwind-tables -target-cpu x86-64 -resource-dir /usr/local/lib/clang/1.1
-fmessage-length 157 -fexceptions -fgnu-runtime -fdiagnostics-show-option
-fcolor-diagnostics -o /tmp/cc-t8expo.s -x c++ assert16-min.cc 
1.    assert16-min.cc:20:38: current parser token ';'
2.    assert16-min.cc:6:12: LLVM IR generation of declaration 'kryHash<char *,
class foo *>::kryHash'
3.    assert16-min.cc:6:12: Generating code for declaration 'kryHash<char *,
class foo *>::kryHash'
clang: error: compiler command failed due to signal 6 (use -v to see
invocation)


$ clang --version
clang version 1.1 (trunk 97818)
Target: x86_64-unknown-freebsd8.0
Thread model: posix

-- 
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 llvm.org  Fri Mar  5 14:35:37 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri,  5 Mar 2010 14:35:37 -0600 (CST)
Subject: [LLVMbugs] [Bug 6517] New: Confused scope error on indirect goto
Message-ID: <bug-6517-206@http.llvm.org/bugs/>

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

           Summary: Confused scope error on indirect goto
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: baldrick at free.fr
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


Compiling the following gives:

void jump(void *L) {
  int I = 1;
  goto *L;
}

$ clang -S scope.C
scope.C:3:3: error: illegal indirect goto in protected scope, unknown effect on
scopes
  goto *L;
  ^
scope.C:2:7: note: jump bypasses variable initialization
  int I = 1;
      ^
2 diagnostics generated.

This is surely wrong.

-- 
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 llvm.org  Fri Mar  5 14:38:16 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri,  5 Mar 2010 14:38:16 -0600 (CST)
Subject: [LLVMbugs] [Bug 6517] Confused scope error on indirect goto
In-Reply-To: <bug-6517-206@http.llvm.org/bugs/>
References: <bug-6517-206@http.llvm.org/bugs/>
Message-ID: <20100305203816.35BEB2A6C124@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #1 from Chris Lattner <clattner at apple.com> 2010-03-05 14:38:15 CST ---
Fixed in r97826 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 llvm.org  Fri Mar  5 16:23:32 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri,  5 Mar 2010 16:23:32 -0600 (CST)
Subject: [LLVMbugs] [Bug 6518] New: Assertion failed: (CD->isUsed())
Message-ID: <bug-6518-206@http.llvm.org/bugs/>

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

           Summary: Assertion failed: (CD->isUsed())
           Product: clang
           Version: trunk
          Platform: Other
        OS/Version: FreeBSD
            Status: NEW
          Severity: normal
          Priority: P3
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: hinokind at gmail.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


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

$ clang assert15-min.cc -Wno-return-type
Assertion failed: (CD->isUsed()), function GetOrCreateLLVMFunction, file
CodeGenModule.cpp, line 796.
Stack dump:
0.    Program arguments: /usr/local/bin/clang -cc1 -triple
x86_64-unknown-freebsd8.0 -S -disable-free -main-file-name assert15-min.cc
-mrelocation-model static -mdisable-fp-elim -mconstructor-aliases
-munwind-tables -target-cpu x86-64 -resource-dir /usr/local/lib/clang/1.1
-Wno-return-type -fmessage-length 157 -fexceptions -fgnu-runtime
-fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-8PkM5j.s -x c++
assert15-min.cc 
1.    <eof> parser at end of file
2.    Per-file LLVM IR generation
3.    assert15-min.cc:28:12: Generating code for declaration 'QDebug::~QDebug'
4.    assert15-min.cc:28:22: LLVM IR generation of compound statement ('{}')
5.    assert15-min.cc:29:24: LLVM IR generation of compound statement ('{}')
6.    assert15-min.cc:30:35: LLVM IR generation of compound statement ('{}')
clang: error: compiler command failed due to signal 6 (use -v to see
invocation)


$ clang --version
clang version 1.1 (trunk 97839)
Target: x86_64-unknown-freebsd8.0
Thread model: posix

-- 
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 llvm.org  Fri Mar  5 16:42:22 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri,  5 Mar 2010 16:42:22 -0600 (CST)
Subject: [LLVMbugs] [Bug 6519] New: Support -Xarch_arch option on Darwin
Message-ID: <bug-6519-206@http.llvm.org/bugs/>

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

           Summary: Support -Xarch_arch option on Darwin
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: Driver
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: dgregor at apple.com
                CC: llvmbugs at cs.uiuc.edu
            Blocks: 5881


Darwin's GCC has a funny scheme where we can pass architecture-specific flags
with, e.g.,

  -Xarch_i386 -mmacosx-version-min=10.4

so that -mmacosx-version-min=10.4 will only be passed down the command-line
chain for -arch i386.

Qt uses 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 llvm.org  Fri Mar  5 17:40:16 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri,  5 Mar 2010 17:40:16 -0600 (CST)
Subject: [LLVMbugs] [Bug 6518] catch blocks not trying to copy-initialize,
 destruct variable type
In-Reply-To: <bug-6518-206@http.llvm.org/bugs/>
References: <bug-6518-206@http.llvm.org/bugs/>
Message-ID: <20100305234016.D29E82A6C12F@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #1 from Douglas Gregor <dgregor at apple.com> 2010-03-05 17:40:16 CST ---
Fixed in r97853

-- 
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 llvm.org  Fri Mar  5 20:18:35 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri,  5 Mar 2010 20:18:35 -0600 (CST)
Subject: [LLVMbugs] [Bug 6515] gcc compat: __builtin_signbit doesn't appear
 to be supported
In-Reply-To: <bug-6515-206@http.llvm.org/bugs/>
References: <bug-6515-206@http.llvm.org/bugs/>
Message-ID: <20100306021835.D50CA2A6C12D@llvm.org>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |sharparrow1 at yahoo.com
         Resolution|                            |FIXED

--- Comment #2 from Eli Friedman <sharparrow1 at yahoo.com> 2010-03-05 20:18:35 CST ---
Fixed in r97864.

-- 
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 llvm.org  Fri Mar  5 21:34:23 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri,  5 Mar 2010 21:34:23 -0600 (CST)
Subject: [LLVMbugs] [Bug 6520] New: [inline asm] early clobber + forced
 register + -O0 == wrong register allocation
Message-ID: <bug-6520-206@http.llvm.org/bugs/>

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

           Summary: [inline asm] early clobber + forced register + -O0 ==
                    wrong register allocation
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P5
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: kaffeemonster at googlemail.com
                CC: llvmbugs at cs.uiuc.edu


I build myself a fresh clang today at trunk r97864.
I was trying to hunt down another bug, but was first stopped by this one:

char *func(void)
{
    char *ret, *p;
    unsigned long t;
    asm (
        "mov    $0xdeafbeef, %1\n\t"
        "mov    $0xcafebabe, %0\n\t"
        "mov    %0, %2\n\t"
        : /* %0 */ "=&r" (ret),
          /* %1 */ "=&r" (p),
          /* %2 */ "=&c" (t)
    );
    return ret;
}

compiled with:
clang -c test.c

results in, stripping the prologue/epilogue:
   9:   b9 ef be af de          mov    $0xdeafbeef,%ecx
   e:   b8 be ba fe ca          mov    $0xcafebabe,%eax
  13:   89 c1                   mov    %eax,%ecx

as you can see, %2 and %1 get the same register. This only happens when:
 - there are early clobbers
 - one variable is forced into a specific register with a constrain
 - no optimization is used

The problem is mainly i need -O0 ATM, because i need working debug info (which
is also broken ATM), so i can hunt down another bug (compiled by clang my
programm crashes).

Greetings
    Jan

-- 
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 llvm.org  Fri Mar  5 22:29:25 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri,  5 Mar 2010 22:29:25 -0600 (CST)
Subject: [LLVMbugs] [Bug 6521] New: decl not getting marked used
Message-ID: <bug-6521-206@http.llvm.org/bugs/>

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

           Summary: decl not getting marked used
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: clattner at apple.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


struct Foo {
  static int count() __attribute__((constructor)) {
    static int cnt = 0;
    return ++cnt;
  }
};

int main() {
  return Foo::count();
}


This isn't outputting the body of Foo::count for some reason, and isn't
honoring the attribute ctor either.

-- 
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 llvm.org  Sat Mar  6 05:42:14 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat,  6 Mar 2010 05:42:14 -0600 (CST)
Subject: [LLVMbugs] [Bug 6349] miscompilation of volatile variables in
	msp430 backend
In-Reply-To: <bug-6349-206@http.llvm.org/bugs/>
References: <bug-6349-206@http.llvm.org/bugs/>
Message-ID: <20100306114214.B7AEE2A6C124@llvm.org>

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

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

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

--- Comment #15 from Anton Korobeynikov <asl at math.spbu.ru> 2010-03-06 05:42:13 CST ---
Fixed in
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20100301/097373.html

please verify

-- 
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 llvm.org  Sat Mar  6 06:01:27 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat,  6 Mar 2010 06:01:27 -0600 (CST)
Subject: [LLVMbugs] [Bug 6522] New: clang emits U symbol for
 builtin_copysignl while gcc does not
Message-ID: <bug-6522-206@http.llvm.org/bugs/>

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

           Summary: clang emits U symbol for builtin_copysignl while gcc
                    does not
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: FreeBSD
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: LLVM Codegen
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: rdivacky at freebsd.org
                CC: llvmbugs at cs.uiuc.edu


pes delta$ cat divxc3.c
void foo(float a, float b, float c, float d) {
      float y = __builtin_copysignl (0, c) * b;
}
pes delta$ gcc -std=c99 -c divxc3.c && nm divxc3.o | grep copy
pes delta$ clang -std=c99 -c divxc3.c && nm divxc3.o | grep copy
                 U copysignl

-- 
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 llvm.org  Sat Mar  6 10:21:59 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat,  6 Mar 2010 10:21:59 -0600 (CST)
Subject: [LLVMbugs] [Bug 6523] New: Externally visible global gets wrong name
Message-ID: <bug-6523-206@http.llvm.org/bugs/>

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

           Summary: Externally visible global gets wrong name
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: baldrick at free.fr
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


If I build LLVM with g++ and dragonegg with clang++ then I get a link failure
because g++ and clang++ disagree over some symbol names:

$ clang++ -S -O2 llvm-backend.ii -o - | grep Registry
    movq    $createLinearScanRegisterAllocator, Registry(%rip)
$ g++ -S -O2 llvm-backend.ii -o - | grep Registry
    movq    $_ZN4llvm33createLinearScanRegisterAllocatorEv,
_ZN4llvm16RegisterRegAlloc8RegistryE(%rip)

Reduced testcase follows:

namespace std __attribute__ ((__visibility__ ("default"))) {
# 202 "/usr/local/include/llvm/OperandTraits.h" 3 4
}

namespace llvm {
  class Pass {
  };
  class FunctionPass : public Pass {
  };
  FunctionPass *createLinearScanRegisterAllocator();
  typedef void *(*MachinePassCtor)();
  class MachinePassRegistryNode {
  };
  class MachinePassRegistry {
    MachinePassCtor Default;
public:
    MachinePassRegistryNode *getList() {
    }
    void setDefault(MachinePassCtor C) {
      Default = C;
    }
  };
  class RegisterRegAlloc : public MachinePassRegistryNode {
public:
    typedef FunctionPass *(*FunctionPassCtor)();
    static MachinePassRegistry Registry;
    static void setDefault(FunctionPassCtor C) {
      Registry.setDefault((MachinePassCtor)C);
    }
  };
}

void LazilyInitializeModule(void) {
  llvm::RegisterRegAlloc::setDefault(llvm::createLinearScanRegisterAllocator);
}

-- 
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 llvm.org  Sat Mar  6 10:43:43 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat,  6 Mar 2010 10:43:43 -0600 (CST)
Subject: [LLVMbugs] [Bug 6524] New: opt -internalize breaks C++
 initialization (compiling with clang)
Message-ID: <bug-6524-206@http.llvm.org/bugs/>

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

           Summary: opt -internalize breaks C++ initialization (compiling
                    with clang)
           Product: new-bugs
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P5
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: sveina at gmail.com
                CC: llvmbugs at cs.uiuc.edu


#include <fstream>

int main() {
  ofstream f;
}

===

Compiling this with clang -c -o works.bc -emit-llvm, it works correctly if then
directly llc'd and assembled/linked with gcc.

However, if piped through opt -internalize, it segfaults in code called from
_init; valgrind reported an access to address 0xE, which sounds to me like
something was not dynamically linked which should have been.

Any other opt passes work fine, just not -internalize.

-- 
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 llvm.org  Sat Mar  6 11:29:18 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat,  6 Mar 2010 11:29:18 -0600 (CST)
Subject: [LLVMbugs] [Bug 6525] New: possible wrong code bug
Message-ID: <bug-6525-206@http.llvm.org/bugs/>

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

           Summary: possible wrong code bug
           Product: new-bugs
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: regehr at cs.utah.edu
                CC: llvmbugs at cs.uiuc.edu, chenyang at cs.utah.edu


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

The -O2 result is definitely the right one.  See using r97881 on Ubuntu 9.10 on
x86.

regehr at john-home:~/volatile/bugs/tmp278$ clang -O2 small.c -o small
regehr at john-home:~/volatile/bugs/tmp278$ ./small
0
regehr at john-home:~/volatile/bugs/tmp278$ clang -O3 small.c -o small
regehr at john-home:~/volatile/bugs/tmp278$ ./small
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 llvm.org  Sat Mar  6 12:01:39 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat,  6 Mar 2010 12:01:39 -0600 (CST)
Subject: [LLVMbugs] [Bug 6015] Stack Overflow compiling C++ code
In-Reply-To: <bug-6015-206@http.llvm.org/bugs/>
References: <bug-6015-206@http.llvm.org/bugs/>
Message-ID: <20100306180139.EDE0C2A6C124@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #7 from Douglas Gregor <dgregor at apple.com> 2010-03-06 12:01:39 CST ---
Anton can't reproduce any more; closing.

-- 
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 llvm.org  Sat Mar  6 12:48:43 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat,  6 Mar 2010 12:48:43 -0600 (CST)
Subject: [LLVMbugs] [Bug 6523] Externally visible global gets wrong name
In-Reply-To: <bug-6523-206@http.llvm.org/bugs/>
References: <bug-6523-206@http.llvm.org/bugs/>
Message-ID: <20100306184843.507922A6C12F@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #2 from Chris Lattner <clattner at apple.com> 2010-03-06 12:48:42 CST ---
This looks like it's the same as PR 6217 but a different directory

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

-- 
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 llvm.org  Sat Mar  6 13:30:20 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat,  6 Mar 2010 13:30:20 -0600 (CST)
Subject: [LLVMbugs] [Bug 6526] New: Optimization bug with clang -O2 (not -O1)
Message-ID: <bug-6526-206@http.llvm.org/bugs/>

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

           Summary: Optimization bug with clang -O2 (not -O1)
           Product: new-bugs
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: gonsolo at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=4406)
 --> (http://llvm.org/bugs/attachment.cgi?id=4406)
Bitcode that exposes optimization bug

The attached bitcode fails when compiled with clang -O2. It runs fine
unoptimized and at -O1.
I verified the correctness with valgrind with clang++ unoptimized, clang++ -O1
and g++.

 The error ist:

*** glibc detected *** ./opted: free(): invalid pointer: 0x00e797e0 ***
======= Backtrace: =========
/lib/tls/i686/cmov/libc.so.6[0x910ff1]
/lib/tls/i686/cmov/libc.so.6[0x9126f2]
/lib/tls/i686/cmov/libc.so.6(cfree+0x6d)[0x9157cd]
/usr/lib/libstdc++.so.6(_ZdlPv+0x21)[0xe466f1]
/usr/lib/libstdc++.so.6(_ZdaPv+0x1d)[0xe4674d]
/usr/lib/libstdc++.so.6(_ZNSt6locale5_ImplD1Ev+0x7d)[0xde5a8d]
/usr/lib/libstdc++.so.6(_ZNSt6localeD1Ev+0x4c)[0xde609c]
/usr/lib/libstdc++.so.6(_ZNSt8ios_baseD2Ev+0x61)[0xde3041]
./opted[0x804a7ce]
======= Memory map: ========
003ab000-003c6000 r-xp 00000000 08:07 64         /lib/ld-2.10.1.so
003c6000-003c7000 r--p 0001a000 08:07 64         /lib/ld-2.10.1.so
003c7000-003c8000 rw-p 0001b000 08:07 64         /lib/ld-2.10.1.so
003ec000-00410000 r-xp 00000000 08:07 144631    
/lib/tls/i686/cmov/libm-2.10.1.so
00410000-00411000 r--p 00023000 08:07 144631    
/lib/tls/i686/cmov/libm-2.10.1.so
00411000-00412000 rw-p 00024000 08:07 144631    
/lib/tls/i686/cmov/libm-2.10.1.so
008a6000-009e4000 r-xp 00000000 08:07 144625    
/lib/tls/i686/cmov/libc-2.10.1.so
009e4000-009e5000 ---p 0013e000 08:07 144625    
/lib/tls/i686/cmov/libc-2.10.1.so
009e5000-009e7000 r--p 0013e000 08:07 144625    
/lib/tls/i686/cmov/libc-2.10.1.so
009e7000-009e8000 rw-p 00140000 08:07 144625    
/lib/tls/i686/cmov/libc-2.10.1.so
009e8000-009eb000 rw-p 00000000 00:00 0 
00d8e000-00e74000 r-xp 00000000 08:07 235237     /usr/lib/libstdc++.so.6.0.13
00e74000-00e78000 r--p 000e6000 08:07 235237     /usr/lib/libstdc++.so.6.0.13
00e78000-00e79000 rw-p 000ea000 08:07 235237     /usr/lib/libstdc++.so.6.0.13
00e79000-00e80000 rw-p 00000000 00:00 0 
00ef5000-00ef6000 r-xp 00000000 00:00 0          [vdso]
00fb5000-00fd1000 r-xp 00000000 08:07 18         /lib/libgcc_s.so.1
00fd1000-00fd2000 r--p 0001b000 08:07 18         /lib/libgcc_s.so.1
00fd2000-00fd3000 rw-p 0001c000 08:07 18         /lib/libgcc_s.so.1
08048000-0804d000 r-xp 00000000 08:07 172256     /home/gonsolo/opted
0804d000-0804e000 r--p 00004000 08:07 172256     /home/gonsolo/opted
0804e000-0804f000 rw-p 00005000 08:07 172256     /home/gonsolo/opted
08bd6000-08bf7000 rw-p 00000000 00:00 0          [heap]
b7600000-b7621000 rw-p 00000000 00:00 0 
b7621000-b7700000 ---p 00000000 00:00 0 
b7795000-b7797000 rw-p 00000000 00:00 0 
b77aa000-b77ac000 rw-p 00000000 00:00 0 
bfb12000-bfb27000 rw-p 00000000 00:00 0          [stack]
Aborted

Bugpoint show how to reproduce:

*** You can reproduce the problem with: opt bugpoint-reduced-simplified.bc
-simplifycfg -domtree -domfrontier -scalarrepl -instcombine -globalopt -ipsccp
-deadargelim -instcombine -simplifycfg -basiccg -prune-eh -inline
-functionattrs -domtree -domfrontier -scalarrepl -simplify-libcalls
-instcombine -jump-threading -simplifycfg -instcombine -tailcallelim
-simplifycfg -reassociate -domtree -loops -loopsimplify -domfrontier
-loopsimplify -lcssa -loop-rotate -licm -lcssa -loop-unswitch -instcombine
-scalar-evolution -loopsimplify -lcssa -iv-users -indvars -loop-deletion
-loopsimplify -lcssa -loop-unroll -instcombine -memdep -gvn -memdep -memcpyopt
-sccp -instcombine -jump-threading -domtree -memdep -dse -adce -simplifycfg
-strip-dead-prototypes -print-used-types -deadtypeelim -constmerge -preverify
-domtree -verify

-- 
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 llvm.org  Sat Mar  6 13:33:06 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat,  6 Mar 2010 13:33:06 -0600 (CST)
Subject: [LLVMbugs] [Bug 5292] postRAscheduler vs. MinGW _alloca
In-Reply-To: <bug-5292-206@http.llvm.org/bugs/>
References: <bug-5292-206@http.llvm.org/bugs/>
Message-ID: <20100306193306.B28952A6C12E@llvm.org>

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

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

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

--- Comment #1 from Anton Korobeynikov <asl at math.spbu.ru> 2010-03-06 13:33:06 CST ---
Should be fixed in r97884. Please reopen if it's still the problem.

-- 
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 llvm.org  Sat Mar  6 13:36:46 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat,  6 Mar 2010 13:36:46 -0600 (CST)
Subject: [LLVMbugs] [Bug 6523] Externally visible global gets wrong name
In-Reply-To: <bug-6523-206@http.llvm.org/bugs/>
References: <bug-6523-206@http.llvm.org/bugs/>
Message-ID: <20100306193646.BA2C42A6C131@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #3 from Chris Lattner <clattner at apple.com> 2010-03-06 13:36:46 CST ---
Actually, this isn't a dupe it turns out.

-- 
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 llvm.org  Sat Mar  6 13:38:48 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat,  6 Mar 2010 13:38:48 -0600 (CST)
Subject: [LLVMbugs] [Bug 6523] Externally visible global gets wrong name
In-Reply-To: <bug-6523-206@http.llvm.org/bugs/>
References: <bug-6523-206@http.llvm.org/bugs/>
Message-ID: <20100306193848.0EF8E2A6C133@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #4 from Chris Lattner <clattner at apple.com> 2010-03-06 13:38:47 CST ---
Fixed here, thanks for the help with the analysis Duncan!
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20100301/028201.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 llvm.org  Sat Mar  6 15:37:34 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat,  6 Mar 2010 15:37:34 -0600 (CST)
Subject: [LLVMbugs] [Bug 4138] vmcore recursive type resolution bug
In-Reply-To: <bug-4138-206@http.llvm.org/bugs/>
References: <bug-4138-206@http.llvm.org/bugs/>
Message-ID: <20100306213734.076AB2A6C12D@llvm.org>

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

Nick Lewycky <nicholas at mxc.ca> changed:

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

--- Comment #11 from Nick Lewycky <nicholas at mxc.ca> 2010-03-06 15:37:33 CST ---
I'm quite sure this is the same as pr6482 which now has a much smaller
testcase.

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

-- 
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 llvm.org  Sat Mar  6 17:58:15 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat,  6 Mar 2010 17:58:15 -0600 (CST)
Subject: [LLVMbugs] [Bug 6527] New: catch reference to incomplete type
Message-ID: <bug-6527-206@http.llvm.org/bugs/>

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

           Summary: catch reference to incomplete type
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: sorokin at rain.ifmo.ru
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


clang and comeau can't compile this code, but gcc and msvc can.

struct T;

template <typename U>
void f()
{
   try
   {}
   catch(T const &)
   {}
}

struct T
{};

int main()
{
   f<int>();
   return 0;
}

I don't know is this error of clang or boost. So I report the bug to boost too:
https://svn.boost.org/trac/boost/ticket/3983

In any case compatibility with gcc is useful.

-- 
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 llvm.org  Sat Mar  6 18:30:13 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat,  6 Mar 2010 18:30:13 -0600 (CST)
Subject: [LLVMbugs] [Bug 6528] New: invalid assembly generated with long
	long on i386
Message-ID: <bug-6528-206@http.llvm.org/bugs/>

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

           Summary: invalid assembly generated with long long on i386
           Product: new-bugs
           Version: trunk
          Platform: PC
        OS/Version: OpenBSD
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: jsg at openbsd.org
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=4409)
 --> (http://llvm.org/bugs/attachment.cgi?id=4409)
preprocessed file

When trying to build several OpenBSD kernel files on i386 with llvm and clang
from trunk, assembly is generated that upsets gas, this used to work fine with
at least llvm/clang 2.6.

 "/usr/bin/as" -o ahc_pci.o /tmp/cc-z0wajh.s
/tmp/cc-z0wajh.s: Assembler messages:
/tmp/cc-z0wajh.s:2120: Error: bignum invalid
/tmp/cc-z0wajh.s:2123: Error: bignum invalid
/tmp/cc-z0wajh.s:2126: Error: bignum invalid
/tmp/cc-z0wajh.s:2129: Error: bignum invalid
/tmp/cc-z0wajh.s:2149: Error: bignum invalid
/tmp/cc-z0wajh.s:2150: Error: bignum invalid
/tmp/cc-z0wajh.s:2152: Error: bignum invalid
/tmp/cc-z0wajh.s:2153: Error: bignum invalid
/tmp/cc-z0wajh.s:2155: Error: bignum invalid
/tmp/cc-z0wajh.s:2156: Error: bignum invalid
/tmp/cc-z0wajh.s:2158: Error: bignum invalid
/tmp/cc-z0wajh.s:2159: Error: bignum invalid
/tmp/cc-z0wajh.s:2161: Error: bignum invalid
/tmp/cc-z0wajh.s:2162: Error: bignum invalid
/tmp/cc-z0wajh.s:2164: Error: bignum invalid
/tmp/cc-z0wajh.s:2165: Error: bignum invalid
/tmp/cc-z0wajh.s:2167: Error: bignum invalid
/tmp/cc-z0wajh.s:2168: Error: bignum invalid
/tmp/cc-z0wajh.s:2170: Error: bignum invalid
/tmp/cc-z0wajh.s:2171: Error: bignum invalid
/tmp/cc-z0wajh.s:2174: Error: bignum invalid
/tmp/cc-z0wajh.s:2234: Error: bignum invalid
/tmp/cc-z0wajh.s:2261: Error: bignum invalid
/tmp/cc-z0wajh.s:2264: Error: bignum invalid
/tmp/cc-z0wajh.s:2267: Error: bignum invalid
/tmp/cc-z0wajh.s:2270: Error: bignum invalid
/tmp/cc-z0wajh.s:2273: Error: bignum invalid
/tmp/cc-z0wajh.s:2275: Error: bignum invalid
/tmp/cc-z0wajh.s:2276: Error: bignum invalid
/tmp/cc-z0wajh.s:2279: Error: bignum invalid
/tmp/cc-z0wajh.s:2282: Error: bignum invalid
/tmp/cc-z0wajh.s:2285: Error: bignum invalid
/tmp/cc-z0wajh.s:2288: Error: bignum invalid
/tmp/cc-z0wajh.s:2291: Error: bignum invalid
/tmp/cc-z0wajh.s:2294: Error: bignum invalid
/tmp/cc-z0wajh.s:2297: Error: bignum invalid

This is lines like
        .quad   -4294967296 

GNU assembler version 2.15 (i386-unknown-openbsd4.6) using BFD version 2.15

clang version 1.1 (trunk 97890)
Target: i386-unknown-openbsd4.7

-- 
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 llvm.org  Sat Mar  6 21:59:38 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat,  6 Mar 2010 21:59:38 -0600 (CST)
Subject: [LLVMbugs] [Bug 6529] New: -g0 should disable debug info
Message-ID: <bug-6529-206@http.llvm.org/bugs/>

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

           Summary: -g0 should disable debug info
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Driver
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: rafael.espindola at gmail.com
                CC: llvmbugs at cs.uiuc.edu


In gcc -g0 disables debug information. In clang it passes -g to "clang -cc1".

I found this bug while benchmarking clang. I was surprised it was just a bit
faster than gcc :-)

-- 
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 llvm.org  Sat Mar  6 23:05:48 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat,  6 Mar 2010 23:05:48 -0600 (CST)
Subject: [LLVMbugs] [Bug 6529] -g0 should disable debug info
In-Reply-To: <bug-6529-206@http.llvm.org/bugs/>
References: <bug-6529-206@http.llvm.org/bugs/>
Message-ID: <20100307050548.1C0F72A6C12D@llvm.org>

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

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

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

--- Comment #2 from Rafael ?vila de Esp?ndola <rafael.espindola at gmail.com> 2010-03-06 23:05:47 CST ---
Fixed in r97897.

-- 
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 llvm.org  Sat Mar  6 23:08:00 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat,  6 Mar 2010 23:08:00 -0600 (CST)
Subject: [LLVMbugs] [Bug 6530] New: Extension: Support platforms with
 implicit extern "C" system headers
Message-ID: <bug-6530-206@http.llvm.org/bugs/>

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

           Summary: Extension: Support platforms with implicit extern "C"
                    system headers
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: other
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: dgregor at apple.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


GCC has the notion of system headers that are implicitly wrapped in extern "C"
blocks, since they were written without regard to C++. Clang may need to
support platforms with this requirement in the future, which involves:

  - Tracking which headers require the implicit extern "C" (already handled by
the preprocessor)
  - Implicitly wrapping extern "C" around these headers when the parser sees
them (we aren't doing this)
  - Allowing C-isms in such headers, e.g., prototype-less functions (which look
like zero-parameter functions in C++) can be merged with functions that have
prototypes (we aren't doing 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 llvm.org  Sat Mar  6 23:11:28 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat,  6 Mar 2010 23:11:28 -0600 (CST)
Subject: [LLVMbugs] [Bug 6217] boost::shared_ptr miscompile (mangling in
 implicitly extern c headers)
In-Reply-To: <bug-6217-206@http.llvm.org/bugs/>
References: <bug-6217-206@http.llvm.org/bugs/>
Message-ID: <20100307051128.7A9B32A6C12D@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #25 from Douglas Gregor <dgregor at apple.com> 2010-03-06 23:11:27 CST ---
Fixed in r97899.

-- 
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 llvm.org  Sat Mar  6 23:50:09 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat,  6 Mar 2010 23:50:09 -0600 (CST)
Subject: [LLVMbugs] [Bug 6294] clang c++ assertion "operator delete missing
 - EmitDtorEpilogue"
In-Reply-To: <bug-6294-206@http.llvm.org/bugs/>
References: <bug-6294-206@http.llvm.org/bugs/>
Message-ID: <20100307055009.9CBCF2A6C12E@llvm.org>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

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

--- Comment #3 from Eli Friedman <sharparrow1 at yahoo.com> 2010-03-06 23:50:09 CST ---
Fixed in r97900.

-- 
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 llvm.org  Sun Mar  7 06:06:11 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun,  7 Mar 2010 06:06:11 -0600 (CST)
Subject: [LLVMbugs] [Bug 6531] New: crash with __attribute__ __aligned__ in
 union (libstdc++ tr1/type_traits)
Message-ID: <bug-6531-206@http.llvm.org/bugs/>

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

           Summary: crash with __attribute__ __aligned__ in union
                    (libstdc++ tr1/type_traits)
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: sorokin at rain.ifmo.ru
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


clang crashes on this code:

  template<unsigned long _Len, unsigned long _Align>
    struct aligned_storage
    {
      union type
      {
 unsigned char __data[_Len];
 struct __attribute__((__aligned__((_Align)))) { } __align;
      };
    };

clang: /home/ivan/d/llvm/tools/clang/lib/AST/Expr.cpp:1600: ICEDiag
CheckICE(const clang::Expr*, clang::ASTContext&): Assertion
`!E->isValueDependent() && "Should not see value dependent exprs!"' failed.
0  clang           0x000000000141ceba
1  clang           0x000000000141cd33
2  libpthread.so.0 0x00007f5aef456190
3  libc.so.6       0x00007f5aee75c4b5 gsignal + 53
4  libc.so.6       0x00007f5aee75ff50 abort + 384
5  libc.so.6       0x00007f5aee755481 __assert_fail + 241
6  clang           0x00000000009b8e1d
7  clang           0x00000000009b9d59
8  clang           0x00000000006f0609
9  clang           0x00000000006f29d1
10 clang           0x00000000006f2f88
11 clang           0x00000000006db8e4
12 clang           0x0000000000a47636
13 clang           0x0000000000a3b95b
14 clang           0x0000000000a4889f
15 clang           0x0000000000a498fa
16 clang           0x0000000000a477f7
17 clang           0x0000000000a3b95b
18 clang           0x0000000000a4889f
19 clang           0x0000000000a498fa
20 clang           0x0000000000a477f7
21 clang           0x0000000000a3b95b
22 clang           0x0000000000a60407
23 clang           0x0000000000a60237
24 clang           0x0000000000a5fd63
25 clang           0x0000000000a3828c
26 clang           0x0000000000a32603
27 clang           0x0000000000a31fcd
28 clang           0x00000000006895bb
29 clang           0x00000000004351aa
30 clang           0x0000000000434e38
31 clang           0x000000000041f556
32 clang           0x0000000000408ec7
33 clang           0x000000000040da36 main + 259
34 libc.so.6       0x00007f5aee747abd __libc_start_main + 253
35 clang           0x00000000004079e9
Stack dump:
0.    Program arguments: /home/ivan/d/llvm-build/Debug/bin/clang -cc1 -triple
x86_64-unknown-linux-gnu -S -disable-free -main-file-name 13.cpp
-mrelocation-model static -mdisable-fp-elim -mconstructor-aliases
-munwind-tables -target-cpu x86-64 -resource-dir
/home/ivan/d/llvm-build/Debug/lib/clang/1.1 -fmessage-length 157 -fexceptions
-fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-XT3UNc.s
-x c++ 13.cpp 
1.    13.cpp:7:48: current parser token '{'
2.    13.cpp:2:5: parsing struct/union/class body 'aligned_storage'
3.    13.cpp:4:7: parsing struct/union/class body 'aligned_storage::type'
clang: error: compiler command failed due to signal 6 (use -v to see
invocation)

-- 
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 llvm.org  Sun Mar  7 07:16:43 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun,  7 Mar 2010 07:16:43 -0600 (CST)
Subject: [LLVMbugs] [Bug 6526] Optimization bug with clang -O2 (not -O1)
In-Reply-To: <bug-6526-206@http.llvm.org/bugs/>
References: <bug-6526-206@http.llvm.org/bugs/>
Message-ID: <20100307131643.8FC582A6C12D@llvm.org>

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

gonsolo at gmail.com changed:

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

--- Comment #7 from gonsolo at gmail.com 2010-03-07 07:16:43 CST ---


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

-- 
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 llvm.org  Sun Mar  7 09:19:37 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun,  7 Mar 2010 09:19:37 -0600 (CST)
Subject: [LLVMbugs] [Bug 6532] New: Dependent name not checked for same-type
 constraint in conversion-function-id
Message-ID: <bug-6532-206@http.llvm.org/bugs/>

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

           Summary: Dependent name not checked for same-type constraint in
                    conversion-function-id
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: schaub-johannes at web.de
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


The Standard requires that (unqualified) lookup in the context of the
postfix-expression should find the same type as does a lookup in the scope of
the object expression (see 3.4.5[basic.lookup.classref] paragraph 7). Clang
does not check this:

template<typename>
struct A {
  // if we change the typedef to "short", clang
  // should complain.
  typedef int foo; 
  operator int() {
    return 0;
  }
};

template<typename>
struct B {
  // this is not found, because B<T> is a dependent base.
  typedef short foo;
};

// makes sure applicable name-lookup
// on definition context classifies "foo"
// as a type so it matches the syntax.
struct TypeNameSugar {
  typedef int foo;
};

template<typename T>
struct C : A<T>, B<T>, TypeNameSugar {
  void c() {
    A<T> *p = this;

    // dependent "p" makes "foo" a dependent name.
    p->operator foo();
  }
};

int main() {
  C<void>().c();
}

-- 
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 llvm.org  Sun Mar  7 09:35:53 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun,  7 Mar 2010 09:35:53 -0600 (CST)
Subject: [LLVMbugs] [Bug 6532] Dependent name not checked for same-type
 constraint in conversion-function-id
In-Reply-To: <bug-6532-206@http.llvm.org/bugs/>
References: <bug-6532-206@http.llvm.org/bugs/>
Message-ID: <20100307153553.6DE7E2A6C12D@llvm.org>

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

Johannes Schaub <schaub-johannes at web.de> changed:

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

--- Comment #1 from Johannes Schaub <schaub-johannes at web.de> 2010-03-07 09:35:53 CST ---
Aww, just looked on the C++ Status page and saw it's a known issue. Wasn't sure
i interpreted the stuff right since GCC neither diagnoses. But i guess clang
folks know about it - so closing as "Later"!

-- 
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 llvm.org  Sun Mar  7 10:23:33 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun,  7 Mar 2010 10:23:33 -0600 (CST)
Subject: [LLVMbugs] [Bug 6533] New: SetCC type must be 8-bit integer
Message-ID: <bug-6533-206@http.llvm.org/bugs/>

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

           Summary: SetCC type must be 8-bit integer
           Product: new-bugs
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: regehr at cs.utah.edu
                CC: llvmbugs at cs.uiuc.edu, chenyang at cs.utah.edu


Created an attachment (id=4416)
 --> (http://llvm.org/bugs/attachment.cgi?id=4416)
failure-inducing C code

Seen using r97881 on Ubuntu 9.10 on x86.

regehr at john-home:~/volatile/bugs/tmp279$ clang -O1 -emit-llvm -S small.c
regehr at john-home:~/volatile/bugs/tmp279$ llc small.s
llc: X86ISelLowering.cpp:5945: llvm::SDValue
llvm::X86TargetLowering::LowerSETCC(llvm::SDValue, llvm::SelectionDAG&):
Assertion `Op.getValueType() == MVT::i8 && "SetCC type must be 8-bit integer"'
failed.
0  llc 0x08939c58
Stack dump:
0.    Program arguments: llc small.s 
1.    Running pass 'X86 DAG->DAG Instruction Selection' on function '@baz'
Aborted

-- 
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 llvm.org  Sun Mar  7 10:31:59 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun,  7 Mar 2010 10:31:59 -0600 (CST)
Subject: [LLVMbugs] [Bug 6487] ice: Cannot create empty or backwards range
In-Reply-To: <bug-6487-206@http.llvm.org/bugs/>
References: <bug-6487-206@http.llvm.org/bugs/>
Message-ID: <20100307163159.2DF772A6C12D@llvm.org>

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

John Regehr <regehr at cs.utah.edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |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 llvm.org  Sun Mar  7 12:00:12 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun,  7 Mar 2010 12:00:12 -0600 (CST)
Subject: [LLVMbugs] [Bug 6534] New: clang does not support -Wno-deprecated
Message-ID: <bug-6534-206@http.llvm.org/bugs/>

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

           Summary: clang does not support -Wno-deprecated
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: sorokin at rain.ifmo.ru
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com




-- 
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 llvm.org  Sun Mar  7 12:38:19 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun,  7 Mar 2010 12:38:19 -0600 (CST)
Subject: [LLVMbugs] [Bug 6534] clang does not support -Wno-deprecated
In-Reply-To: <bug-6534-206@http.llvm.org/bugs/>
References: <bug-6534-206@http.llvm.org/bugs/>
Message-ID: <20100307183819.318D02A6C124@llvm.org>

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

Ivan Sorokin <sorokin at rain.ifmo.ru> changed:

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

--- Comment #2 from Ivan Sorokin <sorokin at rain.ifmo.ru> 2010-03-07 12:38:18 CST ---
http://developer.apple.com/mac/library/documentation/DeveloperTools/gcc-4.0.1/gcc/C_002b_002b-Dialect-Options.html
says that it "Do not warn about usage of deprecated features". I've tried
several those features and this switch seems to has no effect.

-- 
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 llvm.org  Sun Mar  7 12:50:47 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun,  7 Mar 2010 12:50:47 -0600 (CST)
Subject: [LLVMbugs] [Bug 6534] clang does not support -Wno-deprecated
In-Reply-To: <bug-6534-206@http.llvm.org/bugs/>
References: <bug-6534-206@http.llvm.org/bugs/>
Message-ID: <20100307185047.75F622A6C12D@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|INVALID                     |FIXED

--- Comment #4 from Chris Lattner <clattner at apple.com> 2010-03-07 12:50:47 CST ---
Implemented in r97919 I hope.  Please verify, I have no way to know if it fixes
the case 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 llvm.org  Sun Mar  7 12:56:07 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun,  7 Mar 2010 12:56:07 -0600 (CST)
Subject: [LLVMbugs] [Bug 6535] New: "relocation R_X86_64_PC32 against
 undefined symbol" building C++ shared libraries
Message-ID: <bug-6535-206@http.llvm.org/bugs/>

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

           Summary: "relocation R_X86_64_PC32 against undefined symbol"
                    building C++ shared libraries
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: sorokin at rain.ifmo.ru
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


Created an attachment (id=4418)
 --> (http://llvm.org/bugs/attachment.cgi?id=4418)
fmt.cpp

clang++ -o fmt.o -c -fvisibility-inlines-hidden -fvisibility=hidden -O3 -fPIC
fmt.cpp
clang++ -o libmrt.so -shared fmt.o -lexpat -lz

/usr/bin/ld: fmt.o: relocation R_X86_64_PC32 against undefined symbol `vtable
for std::exception@@GLIBCXX_3.4' 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
clang: error: linker command failed with exit code 1 (use -v to see invocation)

g++ works without error

-- 
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 llvm.org  Sun Mar  7 12:57:25 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun,  7 Mar 2010 12:57:25 -0600 (CST)
Subject: [LLVMbugs] [Bug 6535] "relocation R_X86_64_PC32 against undefined
 symbol" building C++ shared libraries
In-Reply-To: <bug-6535-206@http.llvm.org/bugs/>
References: <bug-6535-206@http.llvm.org/bugs/>
Message-ID: <20100307185725.50A9C2A6C12D@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #2 from Chris Lattner <clattner at apple.com> 2010-03-07 12:57:25 CST ---


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

-- 
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 llvm.org  Sun Mar  7 15:56:47 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun,  7 Mar 2010 15:56:47 -0600 (CST)
Subject: [LLVMbugs] [Bug 6536] New: C++ scope checking too aggressive with
 struct with trivial constructor
Message-ID: <bug-6536-206@http.llvm.org/bugs/>

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

           Summary: C++ scope checking too aggressive with struct with
                    trivial constructor
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: sharparrow1 at yahoo.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com
            Blocks: 5511


Testcase:
struct A {};
void a() { goto out; A x; out: return; }

gcc accepts this, clang does not; I'm pretty sure it's valid.

-- 
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 llvm.org  Sun Mar  7 16:50:38 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun,  7 Mar 2010 16:50:38 -0600 (CST)
Subject: [LLVMbugs] [Bug 6537] New: Assertion failure in llvm::checkType: Ty
 && "Invalid GetElementPtrInst indices for type!"
Message-ID: <bug-6537-206@http.llvm.org/bugs/>

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

           Summary: Assertion failure in llvm::checkType: Ty && "Invalid
                    GetElementPtrInst indices for type!"
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: josh at joshtriplett.org
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=4420)
 --> (http://llvm.org/bugs/attachment.cgi?id=4420)
Preprocessed source to demonstrate assertion failure

I tried clang on one of my projects, and got an assertion failure.  I
preprocessed the source and reduced to the minimal command line needed:

~/src/psas/event-driven-fc$ /usr/bin/../lib/clang/1.0/clang-cc -S -o /dev/null
sim.i
clang-cc:
/home/arthur/clang/clang-2.6/llvm-2.6/include/llvm/Instructions.h:368: const
llvm::Type* llvm::checkType(const llvm::Type*): Assertion `Ty && "Invalid
GetElementPtrInst indices for type!"' failed.
0   clang-cc        0x000000000124122f
1   clang-cc        0x0000000001241a3d
2   libpthread.so.0 0x00007f7ba477b990
3   libc.so.6       0x00007f7ba3892f45 gsignal + 53
4   libc.so.6       0x00007f7ba3895d80 abort + 384
5   libc.so.6       0x00007f7ba388c08a __assert_fail + 234
6   clang-cc        0x00000000004f111c
7   clang-cc        0x00000000004f4027
8   clang-cc        0x00000000004fc9da
9   clang-cc        0x00000000004fdacd
10  clang-cc        0x00000000004fe402
11  clang-cc        0x00000000004f1666
12  clang-cc        0x00000000004fb525
13  clang-cc        0x00000000004fca6e
14  clang-cc        0x00000000004fdacd
15  clang-cc        0x00000000004fe402
16  clang-cc        0x00000000004f1666
17  clang-cc        0x00000000004fb525
18  clang-cc        0x00000000004fc89f
19  clang-cc        0x00000000004fdacd
20  clang-cc        0x00000000004fe402
21  clang-cc        0x00000000004f1666
22  clang-cc        0x00000000004f6858
23  clang-cc        0x00000000004f8121
24  clang-cc        0x00000000004fbf34
25  clang-cc        0x00000000004fdaed
26  clang-cc        0x00000000004fe402
27  clang-cc        0x0000000000543a20
28  clang-cc        0x0000000000549020
29  clang-cc        0x000000000054935b
30  clang-cc        0x0000000000546e8a
31  clang-cc        0x000000000054e5da
32  clang-cc        0x00000000004c750c
33  clang-cc        0x00000000004c7c35
34  clang-cc        0x00000000004c7d98
35  clang-cc        0x00000000004c8091
36  clang-cc        0x0000000000423bc7
37  clang-cc        0x000000000060ae04
38  clang-cc        0x000000000040dc0a
39  clang-cc        0x000000000041103e main + 6014
40  libc.so.6       0x00007f7ba387fabd __libc_start_main + 253
41  clang-cc        0x000000000040b3f9
Stack dump:
0.    Program arguments: /usr/bin/../lib/clang/1.0/clang-cc -S -o /dev/null
sim.i 
1.    <eof> parser at end of file
2.    Per-file LLVM IR generation
3.    sim.c:181:1: LLVM IR generation of compound statement ('{}')
Aborted


Preprocessed source 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 llvm.org  Sun Mar  7 17:19:04 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun,  7 Mar 2010 17:19:04 -0600 (CST)
Subject: [LLVMbugs] [Bug 6537] Assertion failure in llvm::checkType: Ty &&
 "Invalid GetElementPtrInst indices for type!"
In-Reply-To: <bug-6537-206@http.llvm.org/bugs/>
References: <bug-6537-206@http.llvm.org/bugs/>
Message-ID: <20100307231904.423452A6C12D@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #2 from Chris Lattner <clattner at apple.com> 2010-03-07 17:19:03 CST ---
Hi Josh,

Please try clang mainline, we're about to branch for 2.7, so it's in good shape
and much has been fixed since 2.6.

-- 
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 llvm.org  Sun Mar  7 17:19:25 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun,  7 Mar 2010 17:19:25 -0600 (CST)
Subject: [LLVMbugs] [Bug 6483] Assertion failure (Expected a direct
 reference binding!) with boost
In-Reply-To: <bug-6483-206@http.llvm.org/bugs/>
References: <bug-6483-206@http.llvm.org/bugs/>
Message-ID: <20100307231925.D9CF72A6C12D@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #2 from Douglas Gregor <dgregor at apple.com> 2010-03-07 17:19:25 CST ---
Fixed in r97922.

-- 
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 llvm.org  Sun Mar  7 17:25:11 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun,  7 Mar 2010 17:25:11 -0600 (CST)
Subject: [LLVMbugs] [Bug 6072] Fail to resolve overloaded member function
 name when target type is base class member pointer
In-Reply-To: <bug-6072-206@http.llvm.org/bugs/>
References: <bug-6072-206@http.llvm.org/bugs/>
Message-ID: <20100307232511.67A002A6C124@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #1 from Douglas Gregor <dgregor at apple.com> 2010-03-07 17:25:11 CST ---
Fixed in r97923.

-- 
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 llvm.org  Sun Mar  7 17:27:04 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun,  7 Mar 2010 17:27:04 -0600 (CST)
Subject: [LLVMbugs] [Bug 6463] crash in clang::Type::getTypeClass()
In-Reply-To: <bug-6463-206@http.llvm.org/bugs/>
References: <bug-6463-206@http.llvm.org/bugs/>
Message-ID: <20100307232704.89B012A6C12E@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #3 from Douglas Gregor <dgregor at apple.com> 2010-03-07 17:27:03 CST ---
Fixed in r97924.

-- 
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 llvm.org  Sun Mar  7 17:30:16 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun,  7 Mar 2010 17:30:16 -0600 (CST)
Subject: [LLVMbugs] [Bug 6527] catch reference to incomplete type
	(boost::signals2)
In-Reply-To: <bug-6527-206@http.llvm.org/bugs/>
References: <bug-6527-206@http.llvm.org/bugs/>
Message-ID: <20100307233016.CF7D52A6C12E@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #3 from Douglas Gregor <dgregor at apple.com> 2010-03-07 17:30:16 CST ---
Definitely an error in Boost, but since GCC supports this I've downgraded the
error to a warning. Fixed in r97925.

-- 
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 llvm.org  Sun Mar  7 19:43:13 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun,  7 Mar 2010 19:43:13 -0600 (CST)
Subject: [LLVMbugs] [Bug 6531] [template dependent attr] crash with
 __attribute__ __aligned__ in union (libstdc++ tr1/type_traits)
In-Reply-To: <bug-6531-206@http.llvm.org/bugs/>
References: <bug-6531-206@http.llvm.org/bugs/>
Message-ID: <20100308014313.B24872A6C12D@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #1 from Douglas Gregor <dgregor at apple.com> 2010-03-07 19:43:13 CST ---


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

-- 
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 llvm.org  Sun Mar  7 19:53:29 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun,  7 Mar 2010 19:53:29 -0600 (CST)
Subject: [LLVMbugs] [Bug 6538] New: Undeclared template names in base class
 lists cause parse explosions
Message-ID: <bug-6538-206@http.llvm.org/bugs/>

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

           Summary: Undeclared template names in base class lists cause
                    parse explosions
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: rideau3 at gmail.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


coppro at overthere:~$ cat output.cpp
  struct foo
  { };

template <typename T>
  struct bar
    : public undeclared<undeclared, foo>
  { };

  struct baz : public foo { };

coppro at overthere:~$ clang output.cpp
output.cpp:6:14: error: unknown template name 'undeclared'
    : public undeclared<undeclared, foo>
             ^
output.cpp:6:40: error: expected '{' after base class list
    : public undeclared<undeclared, foo>
                                       ^
output.cpp:6:40: error: expected ';' after struct
    : public undeclared<undeclared, foo>
                                       ^
                                       ;
output.cpp:6:40: error: expected unqualified-id
clang: DeclBase.cpp:444: void clang::Decl::CheckAccessDeclContext() const:
Assertion `Access != AS_none && "Access specifier is AS_none inside a record
decl"' failed.
0  clang     0x0936e5c6
1  clang     0x0936e43b
2            0x00fcd400 __kernel_sigreturn + 0
3  libc.so.6 0x00d81932 abort + 386
4  libc.so.6 0x00d77648 __assert_fail + 248
5  clang     0x085c203c
6  clang     0x080b8070
7  clang     0x08469ebf
8  clang     0x08311bdc
9  clang     0x0866d304
10 clang     0x08661517
11 clang     0x08658429
12 clang     0x0865885b
13 clang     0x0865820e
14 clang     0x08657adb
15 clang     0x082bff26
16 clang     0x0807462e
17 clang     0x080742c1
18 clang     0x080600d9
19 clang     0x0804e724
20 clang     0x08053571 main + 267
21 libc.so.6 0x00d6ab56 __libc_start_main + 230
22 clang     0x0804d2b1
Stack dump:
0.      Program arguments: /usr/local/bin/clang -cc1 -triple i386-pc-linux-gnu
-S -disable-free -main-file-name output.cpp -mrelocation-model static
-mdisable-fp-elim -mconstructor-aliases -target-cpu pentium4 -resource-dir
/usr/local/lib/clang/1.1 -fmessage-length 167 -fexceptions -fgnu-runtime
-fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-pQ2Cgw.s -x c++
output.cpp
1.      output.cpp:9:14: current parser token ':'
clang: error: compiler command failed due to signal 6 (use -v to see
invocation)
coppro at overthere:~$

-- 
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 llvm.org  Sun Mar  7 20:52:28 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun,  7 Mar 2010 20:52:28 -0600 (CST)
Subject: [LLVMbugs] [Bug 6536] C++ scope checking too aggressive with struct
 with trivial constructor
In-Reply-To: <bug-6536-206@http.llvm.org/bugs/>
References: <bug-6536-206@http.llvm.org/bugs/>
Message-ID: <20100308025228.4322C2A6C12D@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #4 from Douglas Gregor <dgregor at apple.com> 2010-03-07 20:52:27 CST ---
(In reply to comment #2)
> It only gets rejected if you compile it as c++.  That said, I think this is a
> AST construction bug, the AST looks like this:
> 
> void a() (CompoundStmt 0x1036181c0 <t.cc:2:10, col:40>
>   (GotoStmt 0x1036180a0 <col:12, col:17> 'out':0x103618070)
>   (DeclStmt 0x103617050 <col:22, col:25>
>     0x1036180f0 "struct A x =
>       (CXXConstructExpr 0x103618160 <col:24> 'struct A''void (void)')"
>   (LabelStmt 0x103618070 <col:27, col:32> 'out'
>     (ReturnStmt 0x1036181a0 <col:32>)))
> 
> 
> I'm pretty sure that x should not be initialized.

Apparently, it should be initialized in C++0x but not in C++98/03! In C++0x, it
appears that we do have an initializer (which calls the trivial default
constructor), but that constructor doesn't actually do anything. 

Fixed for C++98/03 in r97928. Fixing it for '0x isn't a priority now, but I've
left a FIXME there as a reminder.

-- 
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 llvm.org  Sun Mar  7 21:03:08 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun,  7 Mar 2010 21:03:08 -0600 (CST)
Subject: [LLVMbugs] [Bug 6320] Building optimized clang with (gcc built)
 clang results in link error
In-Reply-To: <bug-6320-206@http.llvm.org/bugs/>
References: <bug-6320-206@http.llvm.org/bugs/>
Message-ID: <20100308030308.508CF2A6C124@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #1 from Douglas Gregor <dgregor at apple.com> 2010-03-07 21:03:07 CST ---
We recently fixed the undefined destructors problem when self-hosting Clang on
Linux. Please try again and re-open this bug if it's still broken for you.

-- 
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 llvm.org  Mon Mar  8 01:52:53 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  8 Mar 2010 01:52:53 -0600 (CST)
Subject: [LLVMbugs] [Bug 6539] New: x86 asm earlyclobber not respected
Message-ID: <bug-6539-206@http.llvm.org/bugs/>

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

           Summary: x86 asm earlyclobber not respected
           Product: libraries
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Register Allocator
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: astrange at ithinksw.com
                CC: llvmbugs at cs.uiuc.edu


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

Using checker-236 and

> ~/checker-236/bin/clang -O3 -mdynamic-no-pic -m32 -fomit-frame-pointer -S cabac_residual.i

the first inline asm compiled has its first input and output both assigned to
eax:
_decode_cabac_residual_internal:
...
LBB1_6:
...
    ## InlineAsm Start
    movl 4(%edi), %esi            
    movl 0(%edi), %ebx            
    movzbl (%eax)    , %eax   

This is compiled from:
static inline int get_cabac_inline(CABACContext *c, uint8_t *const state) {
    int bit;

    asm volatile (
    "movl 4(%2), %%esi            \n\t"
    "movl 0(%2), %%ebx            \n\t"
    "movzbl (%1)    , %0                                     \n\t"
...
    : "=&a" (bit) : "r" (state), "r" (c) : "%ecx", "%ebx", "%edx", "%esi",
"memory");

bit is an earlyclobber, so it should be assigned eax and nothing else should.

This only seems to happen when inlined, so I was unable to minimize it very
far.
This causes ffmpeg (and therefore anything else including it) to miscompile and
crash on x86-32 in the H.264 decoder.

-- 
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 llvm.org  Mon Mar  8 03:37:11 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  8 Mar 2010 03:37:11 -0600 (CST)
Subject: [LLVMbugs] [Bug 6540] New: make check fails as ENABLE_SHARED is not
	set at all.
Message-ID: <bug-6540-206@http.llvm.org/bugs/>

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

           Summary: make check fails as ENABLE_SHARED is not set at all.
           Product: Build scripts
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: cmake
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: grosser at fim.uni-passau.de
                CC: llvmbugs at cs.uiuc.edu


Executing "make check" in my build directory fails with this:

-------------------------------------------------------------------------------
Running LLVM regression tests
Traceback (most recent call last):
  File "/home/grosser/Projekte/llvm/git/utils/lit/lit.py", line 5, in <module>
    lit.main()
  File "/home/grosser/Projekte/llvm/git/utils/lit/lit/lit.py", line 446, in
main
    testSuiteCache, localConfigCache)[1])
  File "/home/grosser/Projekte/llvm/git/utils/lit/lit/lit.py", line 281, in
getTestsInSuite
    testSuiteCache, localConfigCache)
  File "/home/grosser/Projekte/llvm/git/utils/lit/lit/lit.py", line 230, in
getTests
    ts,path_in_suite = getTestSuite(path, litConfig, testSuiteCache)
  File "/home/grosser/Projekte/llvm/git/utils/lit/lit/lit.py", line 199, in
getTestSuite
    ts, relative = search(item)
  File "/home/grosser/Projekte/llvm/git/utils/lit/lit/lit.py", line 183, in
search
    cache[path] = res = search1(path)
  File "/home/grosser/Projekte/llvm/git/utils/lit/lit/lit.py", line 174, in
search1
    cfg = TestingConfig.frompath(cfgpath, None, litConfig, mustExist = True)
  File "/home/grosser/Projekte/llvm/git/utils/lit/lit/TestingConfig.py", line
43, in frompath
    exec f in cfg_globals
  File "/home/grosser/Projekte/llvm/build/test/Unit/lit.site.cfg", line 8
    config.enable_shared = @ENABLE_SHARED@
                           ^
SyntaxError: invalid syntax
gmake[3]: *** [test/CMakeFiles/check] Error 1
gmake[2]: *** [test/CMakeFiles/check.dir/all] Error 2
gmake[1]: *** [test/CMakeFiles/check.dir/rule] Error 2
gmake: *** [check] Error 2
-------------------------------------------------------------------------------

When config.enable_shared was introduced CMAKE was probably forgotten.

Here the interesting change:

--------------------
https://llvm.org/svn/llvm-project/llvm/trunk at 97119

Author: Jeffrey Yasskin <jyasskin at google.com>
Date:   Thu Feb 25 06:34:33 2010 +0000

 Try r96559 for the third time.  This time the shared library is only built if
 --enable-shared is passed to configure.
--------------------

-- 
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 llvm.org  Mon Mar  8 04:27:11 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  8 Mar 2010 04:27:11 -0600 (CST)
Subject: [LLVMbugs] [Bug 6541] New: clang doesn't pick up architecture
	dependent headers
Message-ID: <bug-6541-206@http.llvm.org/bugs/>

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

           Summary: clang doesn't pick up architecture dependent headers
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: thebeing+llvm at halbordnung.de
                CC: llvmbugs at cs.uiuc.edu


On my Debian 64bit system, some architecture depenent headers live in
/usr/include/x86_64-linux-gnu/. While gcc picks those up by default (no
"-I"-flag needed), clang doesn't and it would be super nice if it did?

Cheers


Niels

-- 
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 llvm.org  Mon Mar  8 05:20:40 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  8 Mar 2010 05:20:40 -0600 (CST)
Subject: [LLVMbugs] [Bug 6542] New: Add support for __gcc_tdiag__ format
	attribute
Message-ID: <bug-6542-206@http.llvm.org/bugs/>

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

           Summary: Add support for __gcc_tdiag__ format attribute
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: baldrick at free.fr
                CC: llvmbugs at cs.uiuc.edu


GCC makes use of the __gcc_tdiag__ format attribute in its various warning and
error output routines.  When compiling dragonegg with clang++, this results in
lots of warnings like this:

'format' attribute argument not supported: __gcc_tdiag__
extern bool warning (int, const char *, ...) ATTRIBUTE_GCC_DIAG(2,3);

This is annoying, because vast numbers of these warnings are output.
The same thing happens when compiling GCC with clang.  It would be
great if clang could recognize this format attribute.

-- 
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 llvm.org  Mon Mar  8 06:23:32 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  8 Mar 2010 06:23:32 -0600 (CST)
Subject: [LLVMbugs] [Bug 6543] New: ARM JIT CodeGen asserts while jiting
 java.awt.EventDispatchThread::pumpOneEventForFilters
Message-ID: <bug-6543-206@http.llvm.org/bugs/>

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

           Summary: ARM JIT CodeGen asserts while jiting
                    java.awt.EventDispatchThread::pumpOneEventForFilters
           Product: new-bugs
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: xerxes at zafena.se
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=4424)
 --> (http://llvm.org/bugs/attachment.cgi?id=4424)
testcase fdumpmain.bc to be JIT codegen with lli on arm

Testcase running on ARM linux
:
lli < fdumpmain.bc
lli: /media/disk/llvm/lib/Target/ARM/ARMJITInfo.h:142: void
llvm::ARMJITInfo::addJumpTableBaseAddr(unsigned int, intptr_t): Assertion `JTI
< JumpTableId2AddrMap.size()' failed.
0  libLLVM-2.7svn.so 0x408bd7a0
Stack dump:
0.    Program arguments: lli 
1.    Running pass 'ARM Machine Code Emitter' on function
'@"java.awt.EventDispatchThread::pumpOneEventForFilters"'
Aborted

JTI are 23 and JumpTableId2AddrMap.size are 12 when hitting the assert using
the testcase above.

GDB output when jiting the function
java.awt.EventDispatchThread::pumpOneEventForFilters using OpenJDK Icedtea6
Shark JIT on ARM gnu-eabi-linux.

627  !b   java.awt.EventDispatchThread::pumpOneEventForFilters (244 bytes)
XXX JTI 24 JumpTableId2AddrMap.size 12
[Switching to Thread 0x67eaa490 (LWP 30820)]

Breakpoint 2, emitInlineJumpTable (this=0xbf260, JTIndex=36)
    at /media/disk/llvm/lib/Target/ARM/ARMJITInfo.h:146
146          assert(JTI < JumpTableId2AddrMap.size()); 
Current language:  auto; currently c++
(gdb) bt
#0  emitInlineJumpTable (this=0xbf260, JTIndex=36)
    at /media/disk/llvm/lib/Target/ARM/ARMJITInfo.h:146
#1  0x409a12d8 in emitInstruction (this=0xbf260, MI=@0x27c6170)
    at /media/disk/llvm/lib/Target/ARM/ARMCodeEmitter.cpp:347
#2  0x409a1ae0 in runOnMachineFunction (this=0xbf260, MF=@0x2713118)
    at /media/disk/llvm/lib/Target/ARM/ARMCodeEmitter.cpp:196
#3  0x40adac00 in llvm::MachineFunctionPass::runOnFunction (this=0xbf260, 
    F=<value optimized out>)
    at /media/disk/llvm/lib/CodeGen/MachineFunctionPass.cpp:27
#4  0x40c48624 in llvm::FPPassManager::runOnFunction (this=0x9dea8, 
    F=@0x2724208) at /media/disk/llvm/lib/VMCore/PassManager.cpp:1350
#5  0x40c487bc in llvm::FunctionPassManagerImpl::run (this=0x9d698, 
    F=@0x2724208) at /media/disk/llvm/lib/VMCore/PassManager.cpp:1301
#6  0x40c48a20 in llvm::FunctionPassManager::run (this=0x9c750, F=@0x2724208)
    at /media/disk/llvm/lib/VMCore/PassManager.cpp:1231
#7  0x40d22820 in llvm::JIT::runJITOnFunctionUnlocked (this=0x9cfc8, 
    F=0x2910730, locked=@0x29106e8)
    at /media/disk/llvm/lib/ExecutionEngine/JIT/JIT.cpp:631
#8  0x40d233f4 in llvm::JIT::getPointerToFunction (this=0x9cfc8, F=0x2724208)
    at /media/disk/llvm/lib/ExecutionEngine/JIT/JIT.cpp:683
#9  0x40495ea4 in SharkCompiler::generate_native_code (this=0x7cde8, 
    entry=0x415fecc0, function=0x2724208,
    name=0xbfc10 "java.awt.EventDispatchThread::pumpOneEventForFilters")
    at
/media/disk/icedtea6-shark-shared/openjdk/hotspot/src/share/vm/shark/sharkCompiler.cpp:276
#10 0x404964b8 in SharkCompiler::compile_method (this=0x7cde8, env=0x67ea9b48, 
    target=0xd4248, entry_bci=-1)
    at
/media/disk/icedtea6-shark-shared/openjdk/hotspot/src/share/vm/shark/sharkCompiler.cpp:173
#11 0x40295fcc in CompileBroker::invoke_compiler_on_method (task=0xc38f0)
    at
/media/disk/icedtea6-shark-shared/openjdk/hotspot/src/share/vm/compiler/compileBroker.cpp:1545
#12 0x402965a0 in CompileBroker::compiler_thread_loop ()
    at
/media/disk/icedtea6-shark-shared/openjdk/hotspot/src/share/vm/compiler/compileBroker.cpp:1397
#13 0x404d0118 in JavaThread::thread_main_inner (this=0xbf9c0)
    at
/media/disk/icedtea6-shark-shared/openjdk/hotspot/src/share/vm/runtime/thread.cpp:1380
#14 0x40436258 in java_start (thread=0xbf9c0)
    at
/media/disk/icedtea6-shark-shared/openjdk/hotspot/src/os/linux/vm/os_linux.cpp:786
#15 0x4005f30c in start_thread () from /lib/vfp/libpthread.so.0
#16 0x40156d38 in clone () from /lib/vfp/libc.so.6
Backtrace stopped: frame did not save the PC

The attached testcase fdumpmain.bc was generated by running F->dump() on frame
#8. The testcase have an added dummy main stub that allocates some memory and
executes the function inorder to make lli accept the ir. 
the testcase are not expected to run using lli only expected to pass
getPointerToFunction without asserting during JIT codegeneration.

Since bugpoint/lli cant be run with an option to only run the JIT code
generation prevents me from generating a bugpoint-reduced-simplified.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 llvm.org  Mon Mar  8 06:46:20 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  8 Mar 2010 06:46:20 -0600 (CST)
Subject: [LLVMbugs] [Bug 6544] New: LLVMSystem cant use ADT/StringMap due to
 circular dependency with LLVMSupport
Message-ID: <bug-6544-206@http.llvm.org/bugs/>

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

           Summary: LLVMSystem cant use ADT/StringMap due to circular
                    dependency with LLVMSupport
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Archive library
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: xerxes at zafena.se
                CC: llvmbugs at cs.uiuc.edu


LLVMSystem cant use ADT/StringMap since ADT/StingMap are part of LLVMSupport
and that would create a circular dependency.

LLVMSystem needs to use ADT/StringMap in order to add implemenations for
sys::getHostCPUFeatures(StringMap<bool> &Features)
into
llvm/lib/System/Host.cpp

The correct solution would be to extract all ADT parts from LLVMSupport and
make a new library LLVMADT that can be used by both LLVMSystem and LLVMSupport.

-- 
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 llvm.org  Mon Mar  8 07:08:15 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  8 Mar 2010 07:08:15 -0600 (CST)
Subject: [LLVMbugs] [Bug 6545] New: Crashes of clang during
 compilation/static-analyzer of mupen64plus 1.99.3
Message-ID: <bug-6545-206@http.llvm.org/bugs/>

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

           Summary: Crashes of clang during compilation/static-analyzer of
                    mupen64plus 1.99.3
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: preprocessor
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: robert.wohlrab at gmx.de
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=4426)
 --> (http://llvm.org/bugs/attachment.cgi?id=4426)
files which caused crashes

Path: .
URL: http://llvm.org/svn/llvm-project/llvm/trunk
Repository Root: http://llvm.org/svn/llvm-project
Repository UUID: 91177308-0d34-0410-b5e6-96231b3b80d8
Revision: 97939
Node Kind: directory
Schedule: normal
Last Changed Author: johannes
Last Changed Rev: 97939
Last Changed Date: 2010-03-08 06:39:50 +0100 (Mon, 08 Mar 2010)

Path: tools/clang
URL: http://llvm.org/svn/llvm-project/cfe/trunk
Repository Root: http://llvm.org/svn/llvm-project
Repository UUID: 91177308-0d34-0410-b5e6-96231b3b80d8
Revision: 97939
Node Kind: directory
Schedule: normal
Last Changed Author: dgregor
Last Changed Rev: 97930
Last Changed Date: 2010-03-08 03:49:35 +0100 (Mon, 08 Mar 2010)

Compiled on up-to-date Debian sid amd64 on "Mon, 08 Mar 2010 13:38:28 +0100"

-- 
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 llvm.org  Mon Mar  8 10:10:01 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  8 Mar 2010 10:10:01 -0600 (CST)
Subject: [LLVMbugs] [Bug 6546] New: Assertion `L->isLCSSAForm()' failed with
	loop-rotate
Message-ID: <bug-6546-206@http.llvm.org/bugs/>

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

           Summary: Assertion `L->isLCSSAForm()' failed with loop-rotate
           Product: new-bugs
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: baldrick at free.fr
                CC: llvmbugs at cs.uiuc.edu


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

$ opt -loop-rotate lcssa.bc -disable-output
opt: llvm/lib/Transforms/Utils/LCSSA.cpp:167: virtual
bool<unnamed>::LCSSA::runOnLoop(llvm::Loop*, llvm::LPPassManager&): Assertion
`L->isLCSSAForm()' 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 llvm.org  Mon Mar  8 10:36:28 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  8 Mar 2010 10:36:28 -0600 (CST)
Subject: [LLVMbugs] [Bug 6544] LLVMSystem cant use ADT/StringMap due to
 circular dependency with LLVMSupport
In-Reply-To: <bug-6544-206@http.llvm.org/bugs/>
References: <bug-6544-206@http.llvm.org/bugs/>
Message-ID: <20100308163628.BE31E2A6C12D@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #1 from Chris Lattner <clattner at apple.com> 2010-03-08 10:36:28 CST ---
libsystem is supposed to be low level enough to not need this.  If it needs to
return something like this, it can just return either a pointer into a static
array (with keys/values) or can fill in a vector.  It doesn't need to return a
map datastructure, the client can do that.  A more elegant API can be vended in
libsupport if you desire that builds on the simple API in libsystem.

-- 
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 llvm.org  Mon Mar  8 13:18:13 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  8 Mar 2010 13:18:13 -0600 (CST)
Subject: [LLVMbugs] [Bug 6547] New: return of vector makes llc assert
Message-ID: <bug-6547-206@http.llvm.org/bugs/>

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

           Summary: return of vector makes llc assert
           Product: new-bugs
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: kalle.raiskila at nokia.com
                CC: llvmbugs at cs.uiuc.edu


Returning a vector that doesn't fit to the ABI-specified return vectors makes
llc catch an assert:

Compiling this on ARM

%0 = type <5 x float>
define %0 @cAdd_9( ) {
 ret %0 undef
}

gives error:

Return operand #4 has unhandled type i32UNREACHABLE executed at 
.../llvm/lib/CodeGen/SelectionDAG/CallingConvLower.cpp:109!


returning just 4 floats works for ARM.

-- 
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 llvm.org  Mon Mar  8 13:29:01 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  8 Mar 2010 13:29:01 -0600 (CST)
Subject: [LLVMbugs] [Bug 6537] Assertion failure in llvm::checkType: Ty &&
 "Invalid GetElementPtrInst indices for type!"
In-Reply-To: <bug-6537-206@http.llvm.org/bugs/>
References: <bug-6537-206@http.llvm.org/bugs/>
Message-ID: <20100308192901.740152A6C12E@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #4 from Chris Lattner <clattner at apple.com> 2010-03-08 13:29:00 CST ---
Wow, you're right, it isn't fixed.  Here's a reduced testcase:

typedef union vec3 {
  struct {
    double x, y, z;
  };
  double component[3];
} vec3;

vec3 vec_noise(vec3 value)
{
 return (vec3) {{
  .x = value.x, .y = value.y, .z = value.z,
 }};
}

Thanks for filing 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 llvm.org  Mon Mar  8 13:35:39 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  8 Mar 2010 13:35:39 -0600 (CST)
Subject: [LLVMbugs] [Bug 5687] Kaleidoscope tutorial code doesn't build with
 OCaml 3.11.1
In-Reply-To: <bug-5687-206@http.llvm.org/bugs/>
References: <bug-5687-206@http.llvm.org/bugs/>
Message-ID: <20100308193539.824012A6C12E@llvm.org>

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

Erick Tryzelaar <idadesub at users.sourceforge.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |idadesub at users.sourceforge.
                   |                            |net
         Resolution|                            |FIXED

--- Comment #1 from Erick Tryzelaar <idadesub at users.sourceforge.net> 2010-03-08 13:35:39 CST ---
Fixed in r97965!

-- 
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 llvm.org  Mon Mar  8 13:54:15 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  8 Mar 2010 13:54:15 -0600 (CST)
Subject: [LLVMbugs] [Bug 6548] New: DenseSet::iterator doesn't have std
	iterator traits
Message-ID: <bug-6548-206@http.llvm.org/bugs/>

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

           Summary: DenseSet::iterator doesn't have std iterator traits
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Core LLVM classes
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: alenhar2 at uiuc.edu
                CC: llvmbugs at cs.uiuc.edu


DenseMap has difference_type, iterator_category, etc, but DenseSet doesn't. 
This prevents using set iterators with calls, such as insert, on std
containers.

Something like the below fixes this  (any chance this can be fixed for 2.7?):

--- include/llvm/ADT/DenseSet.h (revision 97942)
+++ include/llvm/ADT/DenseSet.h (working copy)
@@ -55,6 +55,13 @@
   class Iterator {
     typename MapTy::iterator I;
   public:
+    typedef typename MapTy::iterator::difference_type difference_type;
+    typedef ValueT value_type;
+    typedef value_type *pointer;
+    typedef value_type &reference;
+    typedef std::forward_iterator_tag iterator_category;
+
+
     Iterator(const typename MapTy::iterator &i) : I(i) {}

     ValueT& operator*() { return I->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 llvm.org  Mon Mar  8 14:24:11 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  8 Mar 2010 14:24:11 -0600 (CST)
Subject: [LLVMbugs] [Bug 6547] return of vector makes llc assert
In-Reply-To: <bug-6547-206@http.llvm.org/bugs/>
References: <bug-6547-206@http.llvm.org/bugs/>
Message-ID: <20100308202411.9A9502A6C12C@llvm.org>

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

Kalle Raiskila <kalle.raiskila at nokia.com> changed:

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

--- Comment #2 from Kalle Raiskila <kalle.raiskila at nokia.com> 2010-03-08 14:24:11 CST ---
So it is...

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

-- 
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 llvm.org  Mon Mar  8 14:33:30 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  8 Mar 2010 14:33:30 -0600 (CST)
Subject: [LLVMbugs] [Bug 6549] New: DenseSet and DenseMap could use a swap
	function
Message-ID: <bug-6549-206@http.llvm.org/bugs/>

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

           Summary: DenseSet and DenseMap could use a swap function
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Core LLVM classes
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: alenhar2 at uiuc.edu
                CC: llvmbugs at cs.uiuc.edu


DenseSet::swap and DenseMap::swap don't exist, which makes it hard to use the
classes in situations which require efficiently moving map or set contents
between objects.

-- 
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 llvm.org  Mon Mar  8 14:46:29 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  8 Mar 2010 14:46:29 -0600 (CST)
Subject: [LLVMbugs] [Bug 6549] DenseSet and DenseMap could use a swap
	function
In-Reply-To: <bug-6549-206@http.llvm.org/bugs/>
References: <bug-6549-206@http.llvm.org/bugs/>
Message-ID: <20100308204629.892D32A6C12D@llvm.org>

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

Andrew Lenharth <alenhar2 at uiuc.edu> changed:

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

--- Comment #2 from Andrew Lenharth <alenhar2 at uiuc.edu> 2010-03-08 14:46:29 CST ---
added in r97974

-- 
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 llvm.org  Mon Mar  8 14:46:36 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  8 Mar 2010 14:46:36 -0600 (CST)
Subject: [LLVMbugs] [Bug 6548] DenseSet::iterator doesn't have std iterator
	traits
In-Reply-To: <bug-6548-206@http.llvm.org/bugs/>
References: <bug-6548-206@http.llvm.org/bugs/>
Message-ID: <20100308204636.177572A6C124@llvm.org>

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

Andrew Lenharth <alenhar2 at uiuc.edu> changed:

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

--- Comment #2 from Andrew Lenharth <alenhar2 at uiuc.edu> 2010-03-08 14:46:35 CST ---
added in r97974

-- 
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 llvm.org  Mon Mar  8 16:42:30 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  8 Mar 2010 16:42:30 -0600 (CST)
Subject: [LLVMbugs] [Bug 6550] New: linker error for std::istream::seekg
Message-ID: <bug-6550-206@http.llvm.org/bugs/>

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

           Summary: linker error for std::istream::seekg
           Product: clang
           Version: trunk
          Platform: All
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: tim.dawborn at gmail.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


Upon trying to use seekg on an istream clang++ produces a linker error.

$ cat test.cc 
#include <fstream>
#include <iostream>

int
main(void) {
  std::ifstream in("/etc/group", std::ios::in);
  in.seekg(0, std::ifstream::beg);
  in.close();

  return 0;
}
$ clang++ -o test test.cc
/tmp/cc-li0XV7.o: In function `main':
test.cc:(.text+0xb7): undefined reference to `std::basic_istream<char,
std::char_traits<char> >::seekg(long, std::_Ios_Seekdir)'
collect2: ld returned 1 exit status
clang: error: linker command failed with exit code 1 (use -v to see invocation)
$

-- 
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 llvm.org  Mon Mar  8 17:53:54 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  8 Mar 2010 17:53:54 -0600 (CST)
Subject: [LLVMbugs] [Bug 6336] SelectionDAG does not handle scalar second
 operand to sign_extend_inreg correctly
In-Reply-To: <bug-6336-206@http.llvm.org/bugs/>
References: <bug-6336-206@http.llvm.org/bugs/>
Message-ID: <20100308235354.99C862A6C12C@llvm.org>

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

Dan Gohman <gohman at apple.com> changed:

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

--- Comment #4 from Dan Gohman <gohman at apple.com> 2010-03-08 17:53:54 CST ---
This patch isn't right.  Vector SIGN_EXTEND_INREG is expected to have a vector
type for the second operand.  A while ago I did try to change it to use a
scalar type here, and this change simplified some of the code, however it was
problematic because Legalize decides what to do by looking at this type, and on
most targets, it needs to do different things for vector and scalar.

-- 
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 llvm.org  Mon Mar  8 18:34:04 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  8 Mar 2010 18:34:04 -0600 (CST)
Subject: [LLVMbugs] [Bug 6551] New: C++ constructors not completely
 eliminated from function-level static constants
Message-ID: <bug-6551-206@http.llvm.org/bugs/>

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

           Summary: C++ constructors not completely eliminated from
                    function-level static constants
           Product: libraries
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Scalar Optimizations
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: stoklund at 2pi.dk
                CC: llvmbugs at cs.uiuc.edu


llvm-g++ compiles this into a nice constant table:

#include <utility>

typedef std::pair<int,int> P;

static const P table[] = {
  P(1,2),
  P(3,4),
  P(5,6)
};

P f(int n) {
  return table[n];
}

Produces the table:

    .section    __TEXT,__const
    .align    4
__ZL5table:
    .long    1
    .long    2
    .long    3
    .long    4
    .long    5
    .long    6

If the static const table is moved into the function

P f(int n) {
  static const P table[] = {
    P(1,2),
    P(3,4),
    P(5,6)
  };
  return table[n];
}

We get horrible dynamic initialization:

Llabel3:
    movl    %edi, %ebx
    cmpb    $0, __ZGVZ1fiE5table(%rip)
    jne    LBB1_3
    leaq    __ZGVZ1fiE5table(%rip), %rdi
    callq    ___cxa_guard_acquire
    testl    %eax, %eax
    je    LBB1_3
    leaq    __ZGVZ1fiE5table(%rip), %rdi
    movl    $1, __ZZ1fiE5table(%rip)
    movl    $2, __ZZ1fiE5table+4(%rip)
    movl    $3, __ZZ1fiE5table+8(%rip)
    movl    $4, __ZZ1fiE5table+12(%rip)
    movl    $5, __ZZ1fiE5table+16(%rip)
    movl    $6, __ZZ1fiE5table+20(%rip)
    callq    ___cxa_guard_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 llvm.org  Mon Mar  8 18:45:37 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  8 Mar 2010 18:45:37 -0600 (CST)
Subject: [LLVMbugs] [Bug 6552] New: Assigning fp to a variable results in
 "Couldn't allocate output reg for constraint '{fp}'!"
Message-ID: <bug-6552-206@http.llvm.org/bugs/>

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

           Summary: Assigning fp to a variable results in "Couldn't
                    allocate output reg for constraint '{fp}'!"
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: ARM
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: john at bass-software.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=4433)
 --> (http://llvm.org/bugs/attachment.cgi?id=4433)
.ll file which results in a "Couldn't allocate output reg for constraint
'{fp}'!" error when compiled to object code.

Following C program compiled with llvm-gcc ("--target=arm-unknown-eabi
--with-arch=armv4"):

--8<--
extern void bar(unsigned int fp);

void foo(void)
{
  register unsigned int fp __asm ("fp");

  bar(fp);
}
--8<--

results in following .ll (in attachement as well):

--8<--
target datalayout =
"e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-n32"
target triple = "armv4-unknown-eabi"

define arm_aapcscc void @foo() nounwind {
entry:
  %fp = alloca i32                                ; <i32*> [#uses=0]
  %"alloca point" = bitcast i32 0 to i32          ; <i32> [#uses=0]
  %0 = call i32 asm "", "={fp}"() nounwind        ; <i32> [#uses=1]
  call arm_aapcscc  void @bar(i32 %0) nounwind
  br label %return

return:                                           ; preds = %entry
  ret void
}
--8<--

which results in a "Couldn't allocate output reg for constraint '{fp}'!" error
when compiled to object code.

-- 
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 llvm.org  Mon Mar  8 19:55:00 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  8 Mar 2010 19:55:00 -0600 (CST)
Subject: [LLVMbugs] [Bug 6546] Assertion `L->isLCSSAForm()' failed with
	loop-rotate
In-Reply-To: <bug-6546-206@http.llvm.org/bugs/>
References: <bug-6546-206@http.llvm.org/bugs/>
Message-ID: <20100309015500.4CD6D2A6C12D@llvm.org>

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

Dan Gohman <gohman at apple.com> changed:

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

--- Comment #2 from Dan Gohman <gohman at apple.com> 2010-03-08 19:54:59 CST ---
Chris convinced me that LCSSA shouldn't try to transform uses in unreachable
blocks. I updated the isLCSSA function to be less strict instead.  Fixed on
trunk in 98033.

-- 
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 llvm.org  Mon Mar  8 21:04:16 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  8 Mar 2010 21:04:16 -0600 (CST)
Subject: [LLVMbugs] [Bug 6429] x86_64 JIT emits PC-relative relocation in
 non-PC-relative instruction
In-Reply-To: <bug-6429-206@http.llvm.org/bugs/>
References: <bug-6429-206@http.llvm.org/bugs/>
Message-ID: <20100309030416.C84342A6C12D@llvm.org>

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

Dan Gohman <gohman at apple.com> changed:

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

--- Comment #13 from Dan Gohman <gohman at apple.com> 2010-03-08 21:04:16 CST ---
I was curious how the JIT copes with code like

    x ? 0.1 : 2.3

because this typically codegens as LCPI(,%rax,8), and it's not possible to
encode addresses using the scaled index with RIP.  The answer is that the JIT
defaults to the large code model, so the symbol gets emitted in a MOV64ri,
which bypasses this issue.

Given that, the bigger problem here is that that X86InstrInfo.cpp code wasn't
aware of the code model.  This is now fixed on trunk in r98042.

It's also the case that the binary code emitter will need more information (a
TargetFlag bit on the MachineOperand?) in order to be able to emit
non-PC-relative encodings, but that's a separate issue.

-- 
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 llvm.org  Mon Mar  8 22:45:54 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  8 Mar 2010 22:45:54 -0600 (CST)
Subject: [LLVMbugs] [Bug 6553] New: Difference between clang and g++ in
 lookup of methods of template base classes
Message-ID: <bug-6553-206@http.llvm.org/bugs/>

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

           Summary: Difference between clang and g++ in lookup of methods
                    of template base classes
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: matthias at gamezock.de
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com
            Blocks: 6023


The folowing code compiles fine with g++, clang++ wants fooNum to be qualified
(Foo<T>::fooNum). I'm not sure which compiler handles this case correctly, but
this affects boost (a similar construct is used in the OpenSSL backend of the
Boost ASIO library).


template <typename T>
struct Foo {
  void fooNum(int newNum) {}
};

template <typename T>
struct Bar : public Foo<T> {
  Bar(int i) { 
    fooNum(getNum());
  }

  int getNum() {return 23;}
};

int main() {
  Bar<void> bar(42);

  return 0;
}


g++ does find the fooNum method, as it considers getNum dependent on T, so it
also looks in Foo. Just calling 'fooNum(23);' fails with both compilers.

-- 
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 llvm.org  Tue Mar  9 00:19:18 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  9 Mar 2010 00:19:18 -0600 (CST)
Subject: [LLVMbugs] [Bug 6554] New: Debug generation broken. Brakes debug
 bootstrap on linux.
Message-ID: <bug-6554-206@http.llvm.org/bugs/>

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

           Summary: Debug generation broken. Brakes debug bootstrap on
                    linux.
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: LLVM Codegen
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: rafael.espindola at gmail.com
                CC: llvmbugs at cs.uiuc.edu


$ valgrind ./clang-debug -cc1 -S -g SelectionDAGISel.ii

==27907== Invalid read of size 1
==27907==    at 0x56AE96: llvm::Value::getValueID() const (Value.h:247)
==27907==    by 0x56AF21: bool llvm::isa_impl<llvm::Instruction,
llvm::Value>(llvm::Value const&) (Value.h:338)
==27907==    by 0x577AFF: llvm::isa_impl_wrap<llvm::Instruction, llvm::Value
const, llvm::Value const>::doit(llvm::Value const&) (Casting.h:71)
==27907==    by 0x57662C: bool
llvm::isa_impl_cl<llvm::Value>::isa<llvm::Instruction>(llvm::Value const&)
(Casting.h:83)
==27907==    by 0xACF97D: bool
llvm::isa_impl_cl<llvm::Value*>::isa<llvm::Instruction>(llvm::Value*)
(Casting.h:101)
==27907==    by 0xACD702: bool llvm::isa<llvm::Instruction,
llvm::Value*>(llvm::Value* const&) (Casting.h:116)
==27907==    by 0x1372464: llvm::MDNode::getMDNode(llvm::LLVMContext&,
llvm::Value* const*, unsigned int, llvm::MDNode::FunctionLocalness, bool)
(Metadata.cpp:211)
==27907==    by 0x137262A: llvm::MDNode::get(llvm::LLVMContext&, llvm::Value*
const*, unsigned int) (Metadata.cpp:237)
==27907==    by 0x1243ED3:
llvm::DIFactory::CreateSubprogram(llvm::DIDescriptor, llvm::StringRef,
llvm::StringRef, llvm::StringRef, llvm::DIFile, unsigned int, llvm::DIType,
bool, bool, unsigned int, unsigned int, llvm::DIType, bool) (DebugInfo.cpp:925)
==27907==    by 0x5B1F40:
clang::CodeGen::CGDebugInfo::CreateCXXMemberFunction(clang::CXXMethodDecl
const*, llvm::DIFile, llvm::DICompositeType&) (CGDebugInfo.cpp:607)
==27907==    by 0x5B210C:
clang::CodeGen::CGDebugInfo::CollectCXXMemberFunctions(clang::CXXRecordDecl
const*, llvm::DIFile, llvm::SmallVectorImpl<llvm::DIDescriptor>&,
llvm::DICompositeType&) (CGDebugInfo.cpp:631)
==27907==    by 0x5B3220:
clang::CodeGen::CGDebugInfo::CreateType(clang::RecordType const*, llvm::DIFile)
(CGDebugInfo.cpp:806)
==27907==  Address 0x7d8bf48 is 8 bytes inside a block of size 576 free'd
==27907==    at 0x4C24D68: free (vg_replace_malloc.c:325)
==27907==    by 0x13722DE: llvm::MDNode::destroy() (Metadata.cpp:185)
==27907==    by 0x124105C:
llvm::DIDerivedType::replaceAllUsesWith(llvm::DIDescriptor&)
(DebugInfo.cpp:279)
==27907==    by 0x5B359B:
clang::CodeGen::CGDebugInfo::CreateType(clang::RecordType const*, llvm::DIFile)
(CGDebugInfo.cpp:835)
==27907==    by 0x5B474F:
clang::CodeGen::CGDebugInfo::CreateType(clang::TagType const*, llvm::DIFile)
(CGDebugInfo.cpp:1008)
==27907==    by 0x5B5B4C:
clang::CodeGen::CGDebugInfo::CreateTypeNode(clang::QualType, llvm::DIFile)
(CGDebugInfo.cpp:1233)
==27907==    by 0x5B56E1:
clang::CodeGen::CGDebugInfo::getOrCreateType(clang::QualType, llvm::DIFile)
(CGDebugInfo.cpp:1190)
==27907==    by 0x5B12B3:
clang::CodeGen::CGDebugInfo::CollectRecordFields(clang::RecordDecl const*,
llvm::DIFile, llvm::SmallVectorImpl<llvm::DIDescriptor>&) (CGDebugInfo.cpp:461)
==27907==    by 0x5B31B1:
clang::CodeGen::CGDebugInfo::CreateType(clang::RecordType const*, llvm::DIFile)
(CGDebugInfo.cpp:803)
==27907==    by 0x5B474F:
clang::CodeGen::CGDebugInfo::CreateType(clang::TagType const*, llvm::DIFile)
(CGDebugInfo.cpp:1008)
==27907==    by 0x5B5B4C:
clang::CodeGen::CGDebugInfo::CreateTypeNode(clang::QualType, llvm::DIFile)
(CGDebugInfo.cpp:1233)
==27907==    by 0x5B56E1:
clang::CodeGen::CGDebugInfo::getOrCreateType(clang::QualType, llvm::DIFile)
(CGDebugInfo.cpp:1190)

-- 
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 llvm.org  Tue Mar  9 00:33:39 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  9 Mar 2010 00:33:39 -0600 (CST)
Subject: [LLVMbugs] [Bug 6552] [ARM inline asm] Assigning fp to a variable
 results in "Couldn't allocate output reg for constraint '{fp}'!"
In-Reply-To: <bug-6552-206@http.llvm.org/bugs/>
References: <bug-6552-206@http.llvm.org/bugs/>
Message-ID: <20100309063339.1DB662A6C124@llvm.org>

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

Bob Wilson <bob.wilson at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |bob.wilson at apple.com
         Resolution|                            |WORKSFORME

--- Comment #1 from Bob Wilson <bob.wilson at apple.com> 2010-03-09 00:33:38 CST ---
Trunk llvm-gcc does not produce that IR.  Instead if correctly diagnoses this
as an error:

test.c: In function 'foo':
test.c:5: error: invalid register name for 'fp'

The error message is pretty good in this case.   You need to specify the name
of a specific register in this context and "fp" is not a register name.

-- 
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 llvm.org  Tue Mar  9 00:43:41 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  9 Mar 2010 00:43:41 -0600 (CST)
Subject: [LLVMbugs] [Bug 6552] [ARM inline asm] Assigning fp to a variable
 results in "Couldn't allocate output reg for constraint '{fp}'!"
In-Reply-To: <bug-6552-206@http.llvm.org/bugs/>
References: <bug-6552-206@http.llvm.org/bugs/>
Message-ID: <20100309064341.AC0B92A6C12D@llvm.org>

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

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

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

--- Comment #2 from Anton Korobeynikov <asl at math.spbu.ru> 2010-03-09 00:43:41 CST ---
(In reply to comment #1)
> Trunk llvm-gcc does not produce that IR.  Instead if correctly diagnoses this
> as an error:
> 
> test.c: In function 'foo':
> test.c:5: error: invalid register name for 'fp'
The error is not shown for me here (arm-eabi cross-compiler) - sound like some
apple-local stuff?

> The error message is pretty good in this case.   You need to specify the name
> of a specific register in this context and "fp" is not a register name.
No, it is a valid register name per ARM's specification. gcc accepts this code
as well.

-- 
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 llvm.org  Tue Mar  9 01:12:50 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  9 Mar 2010 01:12:50 -0600 (CST)
Subject: [LLVMbugs] [Bug 6555] New: 2.7.r97654: Assertion failed: (DataSize
 == TypeLoc::getFullDataSizeForType(T) && "incorrect data size provided to
 CreateTypeSourceInfo!")
Message-ID: <bug-6555-206@http.llvm.org/bugs/>

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

           Summary: 2.7.r97654: Assertion failed: (DataSize ==
                    TypeLoc::getFullDataSizeForType(T) && "incorrect data
                    size provided to CreateTypeSourceInfo!")
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: FreeBSD
            Status: NEW
          Severity: release blocker
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: nms+llvm at otdel-1.org
                CC: llvmbugs at cs.uiuc.edu


Script started on Tue Mar  9 10:06:52 2010

$ sh -x cc.sh
+ cd /usr/home/nms/exiv2/build/src
+ /usr/local/bin/clang++ -v -DEXV_BUILDING_LIB -DEXV_HAVE_DLL
-DEXV_HAVE_STDINT_H -fPIC -I/usr/home/nms/exiv2/build
-I/usr/home/nms/exiv2/xmpsdk/include -I/usr/local/include -Wall -Wcast-align
-Wpointer-arith -Wformat-security -Wmissing-format-attribute
-Woverloaded-virtual -W -o CMakeFiles/exiv2.dir/xmp.cpp.o -c
/usr/home/nms/exiv2/src/xmp.cpp
clang version 1.1 (trunk)
Target: i386-portbld-freebsd9.0
Thread model: posix
 "/usr/local/bin/clang" -cc1 -triple i386-portbld-freebsd9.0 -S -disable-free
-main-file-name xmp.cpp -pic-level 2 -mdisable-fp-elim -mconstructor-aliases
-target-cpu pentium4 -v -resource-dir /usr/local/lib/clang/1.1
-DEXV_BUILDING_LIB -DEXV_HAVE_DLL -DEXV_HAVE_STDINT_H
-I/usr/home/nms/exiv2/build -I/usr/home/nms/exiv2/xmpsdk/include
-I/usr/local/include -Wall -Wcast-align -Wpointer-arith -Wformat-security
-Wmissing-format-attribute -Woverloaded-virtual -W -fmessage-length 210
-fexceptions -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o
/tmp/cc-KcHUk9.s -x c++ /usr/home/nms/exiv2/src/xmp.cpp
clang -cc1 version 1.1 based upon llvm 2.7svn hosted on i386-portbld-freebsd9.0
ignoring duplicate directory "/usr/include/c++/4.2"
ignoring duplicate directory "/usr/local/include"
  as it is a non-system directory that duplicates a system directory
#include "..." search starts here:
#include <...> search starts here:
 /usr/home/nms/exiv2/build
 /usr/home/nms/exiv2/xmpsdk/include
 /usr/local/lib/clang/1.1/include
 /usr/include/c++/4.2
 /usr/include/c++/4.2/backward
 /usr/local/include
 /usr/include
End of search list.
Assertion failed: (DataSize == TypeLoc::getFullDataSizeForType(T) && "incorrect
data size provided to CreateTypeSourceInfo!"), function CreateTypeSourceInfo,
file ASTContext.cpp, line 1144.
Stack dump:
0.    Program arguments: /usr/local/bin/clang -cc1 -triple
i386-portbld-freebsd9.0 -S -disable-free -main-file-name xmp.cpp -pic-level 2
-mdisable-fp-elim -mconstructor-aliases -target-cpu pentium4 -v -resource-dir
/usr/local/lib/clang/1.1 -DEXV_BUILDING_LIB -DEXV_HAVE_DLL -DEXV_HAVE_STDINT_H
-I/usr/home/nms/exiv2/build -I/usr/home/nms/exiv2/xmpsdk/include
-I/usr/local/include -Wall -Wcast-align -Wpointer-arith -Wformat-security
-Wmissing-format-attribute -Woverloaded-virtual -W -fmessage-length 210
-fexceptions -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o
/tmp/cc-KcHUk9.s -x c++ /usr/home/nms/exiv2/src/xmp.cpp 
1.    /usr/home/nms/exiv2/xmpsdk/include/XMP.incl_cpp:55:48: current parser
token ';'
clang: error: compiler command failed due to signal 6 (use -v to see
invocation)

Script done on Tue Mar  9 10:07:01 2010

-- 
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 llvm.org  Tue Mar  9 03:52:59 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  9 Mar 2010 03:52:59 -0600 (CST)
Subject: [LLVMbugs] [Bug 6556] New: header install doesn't honor DESTDIR
Message-ID: <bug-6556-206@http.llvm.org/bugs/>

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

           Summary: header install doesn't honor DESTDIR
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: release blocker
          Priority: P
         Component: Headers
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: doko at ubuntu.com
                CC: llvmbugs at cs.uiuc.edu


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

installation into DESTDIR (used for packaging) doesn't work on the 2.7 branch
(20100308), patch 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 llvm.org  Tue Mar  9 03:56:14 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  9 Mar 2010 03:56:14 -0600 (CST)
Subject: [LLVMbugs] [Bug 6557] New: toolalias install doesn't honor DESTDIR
Message-ID: <bug-6557-206@http.llvm.org/bugs/>

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

           Summary: toolalias install doesn't honor DESTDIR
           Product: Build scripts
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: release blocker
          Priority: P
         Component: Makefiles
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: doko at ubuntu.com
                CC: llvmbugs at cs.uiuc.edu


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

installation into DESTDIR (used for packaging) doesn't work on the 2.7 branch
(20100308), patch 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 llvm.org  Tue Mar  9 04:15:28 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  9 Mar 2010 04:15:28 -0600 (CST)
Subject: [LLVMbugs] [Bug 6558] New: Assertion failed...
Message-ID: <bug-6558-206@http.llvm.org/bugs/>

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

           Summary: Assertion failed...
           Product: clang
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: release blocker
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: Fons.Rademakers at cern.ch
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


Created an attachment (id=4443)
 --> (http://llvm.org/bugs/attachment.cgi?id=4443)
source code exhibiting the bug

In the original source the failure is in <map> related code:

namespace {
static std::map<int /*tagnum*/, std::set<G__ifunc_table> > & G__ifunc_refs()
{
   static std::map<int /*tagnum*/, std::set<G__ifunc_table> > ifunc_refs;
   return ifunc_refs;
}
} // unnamed namespace

To reproduce compile the attached file using:

clang++ -c aap.cxx

-- 
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 llvm.org  Tue Mar  9 04:27:25 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  9 Mar 2010 04:27:25 -0600 (CST)
Subject: [LLVMbugs] [Bug 6559] New: segfault running indvars
Message-ID: <bug-6559-206@http.llvm.org/bugs/>

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

           Summary: segfault running indvars
           Product: new-bugs
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: baldrick at free.fr
                CC: llvmbugs at cs.uiuc.edu


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

$ opt -indvars indvars_segfault.ll -disable-output
Segmentation fault (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 llvm.org  Tue Mar  9 05:22:42 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  9 Mar 2010 05:22:42 -0600 (CST)
Subject: [LLVMbugs] [Bug 6560] New: Assertion failure: An asserting value
 handle still pointed to this value!
Message-ID: <bug-6560-206@http.llvm.org/bugs/>

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

           Summary: Assertion failure: An asserting value handle still
                    pointed to this value!
           Product: new-bugs
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: baldrick at free.fr
                CC: llvmbugs at cs.uiuc.edu


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

$ opt -globalsmodref-aa -loopsimplify -argpromotion -adce value_handle.bc
-disable-output
While deleting: i8 ({ i8*, i32, i32, i32, i8*, i32, i32, i32, i8*, i8* (i8*,
i32, i32)*, void (i8*, i8*)*, i8* }*)* %
An asserting value handle still pointed to this value!

-- 
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 llvm.org  Tue Mar  9 06:46:26 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  9 Mar 2010 06:46:26 -0600 (CST)
Subject: [LLVMbugs] [Bug 6561] New: ARM JIT CodeEmitter VMOVDneon "Unhandled
 instruction encoding format!"
Message-ID: <bug-6561-206@http.llvm.org/bugs/>

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

           Summary: ARM JIT CodeEmitter VMOVDneon "Unhandled instruction
                    encoding format!"
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: ARM
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: xerxes at zafena.se
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=4446)
 --> (http://llvm.org/bugs/attachment.cgi?id=4446)
dacapo.chart.Datasets::createPointerAgeData.ll.tar.gz

Hits unreachable "Unhandled instruction encoding format!" while processing the
MI 
%D10<def> = VMOVDneon %D9, pred:14, pred:%reg0 
jit are running with -mcpu=generic -mattr=+neon,-thumb2,+v6,+vfp2

java -jar dacapio-2006-10-MR2.jar chart
..
Breakpoint 2, emitInstruction (this=0xbefd0, MI=@0x8d2048)
    at /media/disk/llvm/lib/Target/ARM/ARMCodeEmitter.cpp:313
313        llvm_unreachable("Unhandled instruction encoding format!");
Current language:  auto; currently c++
(gdb) call MI.dump()
  %D10<def> = VMOVDneon %D9, pred:14, pred:%reg0
(gdb) bt
#0  emitInstruction (this=0xbefd0, MI=@0x8d2048)
    at /media/disk/llvm/lib/Target/ARM/ARMCodeEmitter.cpp:313
#1  0x409a48c4 in runOnMachineFunction (this=0xbefd0, MF=@0x4c81a8)
    at /media/disk/llvm/lib/Target/ARM/ARMCodeEmitter.cpp:196
#2  0x40af5ee0 in llvm::MachineFunctionPass::runOnFunction (this=0xbefd0, 
    F=<value optimized out>)
    at /media/disk/llvm/lib/CodeGen/MachineFunctionPass.cpp:27
#3  0x40c633e0 in llvm::FPPassManager::runOnFunction (this=0x9dc30, 
    F=@0x432d58) at /media/disk/llvm/lib/VMCore/PassManager.cpp:1350
#4  0x40c63578 in llvm::FunctionPassManagerImpl::run (this=0x9da38, 
    F=@0x432d58) at /media/disk/llvm/lib/VMCore/PassManager.cpp:1301
#5  0x40c637dc in llvm::FunctionPassManager::run (this=0x9e048, F=@0x432d58)
    at /media/disk/llvm/lib/VMCore/PassManager.cpp:1231
#6  0x40d4ea14 in llvm::JIT::runJITOnFunctionUnlocked (this=0x9d9a8, F=0x1de3, 
    locked=@0x4133558c) at /media/disk/llvm/lib/ExecutionEngine/JIT/JIT.cpp:631
#7  0x40d4f5e8 in llvm::JIT::getPointerToFunction (this=0x9d9a8, F=0x432d58)
    at /media/disk/llvm/lib/ExecutionEngine/JIT/JIT.cpp:683
#8  0x40495ea4 in SharkCompiler::generate_native_code (this=0x926a0, 
    entry=0x415d1000, function=0x432d58, 
    name=0xbf978 "dacapo.chart.Datasets::createPointerAgeData")
    at
/media/disk/icedtea6-shark-shared/openjdk/hotspot/src/share/vm/shark/sharkCompiler.cpp:276
---Type <return> to continue, or q <return> to quit---
#9  0x404964b8 in SharkCompiler::compile_method (this=0x926a0, env=0x67ed9c48, 
    target=0x448c90, entry_bci=-1)
    at
/media/disk/icedtea6-shark-shared/openjdk/hotspot/src/share/vm/shark/sharkCompiler.cpp:173
#10 0x40295fcc in CompileBroker::invoke_compiler_on_method (task=0x120350)
    at
/media/disk/icedtea6-shark-shared/openjdk/hotspot/src/share/vm/compiler/compileBroker.cpp:1545
#11 0x402965a0 in CompileBroker::compiler_thread_loop ()
    at
/media/disk/icedtea6-shark-shared/openjdk/hotspot/src/share/vm/compiler/compileBroker.cpp:1397
#12 0x404d0118 in JavaThread::thread_main_inner (this=0xbf730)
    at
/media/disk/icedtea6-shark-shared/openjdk/hotspot/src/share/vm/runtime/thread.cpp:1380
#13 0x40436258 in java_start (thread=0xbf730)
    at
/media/disk/icedtea6-shark-shared/openjdk/hotspot/src/os/linux/vm/os_linux.cpp:786
#14 0x4005f30c in start_thread () from /lib/vfp/libpthread.so.0
#15 0x40156d38 in clone () from /lib/vfp/libc.so.6
Backtrace stopped: frame did not save the PC
(gdb) frame 7
(gdb) call F->dump() 
... output of F->dump() LLVM IR in attachment
dacapo.chart.Datasets::createPointerAgeData.ll.tar.gz 180Kb (1.7Mb unpacked)

-- 
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 llvm.org  Tue Mar  9 14:02:25 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  9 Mar 2010 14:02:25 -0600 (CST)
Subject: [LLVMbugs] [Bug 6562] New: Crash due to missing destructor
Message-ID: <bug-6562-206@http.llvm.org/bugs/>

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

           Summary: Crash due to missing destructor
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: chandlerc at gmail.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


% cat t.cc                      
struct X { ~X() {} };
template <typename T>
struct A {
  struct B { X x; };
  struct C : public B {
    C() : B() { }
  };
};

% ./bin/clang -fsyntax-only t.cc
clang: /home/chandlerc/src/llvm/trunk/tools/clang/lib/AST/DeclCXX.cpp:556:
clang::CXXDestructorDecl*
clang::CXXRecordDecl::getDestructor(clang::ASTContext&) const: Assertion `I !=
E && "Did not find a destructor!"' failed.
Stack dump:
0.      Program arguments: /home/chandlerc/src/llvm/trunk/build/bin/clang -cc1
-triple x86_64-unknown-linux-gnu -fsyntax-only -disable-free -main-file-name
t.cc -mrelocation-model static -mdisable-fp-elim -mconstructor-aliases
-munwind-tables -target-cpu x86-64 -resource-dir
/home/chandlerc/src/llvm/trunk/build/lib/clang/1.1 -fmessage-length 283
-fexceptions -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -x c++
t.cc 
1.      t.cc:6:15: current parser token '{'
2.      t.cc:3:1: parsing struct/union/class body 'A'
clang: error: compiler command failed due to signal 6 (use -v to see
invocation)

-- 
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 llvm.org  Tue Mar  9 15:23:22 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  9 Mar 2010 15:23:22 -0600 (CST)
Subject: [LLVMbugs] [Bug 6553] Difference between clang and g++ in lookup of
 methods of template base classes
In-Reply-To: <bug-6553-206@http.llvm.org/bugs/>
References: <bug-6553-206@http.llvm.org/bugs/>
Message-ID: <20100309212322.E7BB12A6C124@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #4 from Douglas Gregor <dgregor at apple.com> 2010-03-09 15:23:22 CST ---
(In reply to comment #3)
> (In reply to comment #2)
> > (In reply to comment #0)
> > > The folowing code compiles fine with g++, clang++ wants fooNum to be qualified
> > > (Foo<T>::fooNum).
> > > 
> > 
> > In [temp.dep] (14.7.2 in n3000), it says:
> > 
> >     In an expression of the form:
> > 
> >         postfix-expression ( expression-listopt )
> > 
> >     where the postfix-expression is an unqualified-id but not a template-id, 
> >     the unqualified-id denotes a dependent name if and only if any of the 
> >     expressions in the expression-list is a type-dependent expression
> > (14.7.2.2).
> > 
> > 14.6.2 in C++03 has similar wording.
> > 
> > My interpretation of that is that "getNum()" is not dependant, since the empty
> > expression list is not type-dependent, and thus "fooNum(getNum())" is also not
> > dependant, since its expression list isn't type-dependent.
> 
> I don't think the issue is either of these expressions being dependent (and I
> agree getNum() is clearly fine), it's that the base class is dependent. That
> means an unqualified name cannot look into the base class and find a member
> function. I would expect the fix to be calling "this->fooNum(getNum())" to
> clarify that this is a member function call (as opposed to calling a function
> at namespace scope). Perhaps there is something that makes this case special
> that I'm missing though.

Chandler is correct. fooNum() in the base class is not visible, and since
getNum() is not type-dependent , fooNum is not a dependent name. GCC is wrong
to permit this code.

-- 
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 llvm.org  Tue Mar  9 15:32:56 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  9 Mar 2010 15:32:56 -0600 (CST)
Subject: [LLVMbugs] [Bug 6554] Debug generation broken. Brakes debug
	bootstrap on linux.
In-Reply-To: <bug-6554-206@http.llvm.org/bugs/>
References: <bug-6554-206@http.llvm.org/bugs/>
Message-ID: <20100309213256.419612A6C12E@llvm.org>

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

Devang Patel <dpatel at apple.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 llvm.org  Tue Mar  9 17:47:19 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  9 Mar 2010 17:47:19 -0600 (CST)
Subject: [LLVMbugs] [Bug 6559] segfault running indvars
In-Reply-To: <bug-6559-206@http.llvm.org/bugs/>
References: <bug-6559-206@http.llvm.org/bugs/>
Message-ID: <20100309234719.8E4F32A6C12D@llvm.org>

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

Dan Gohman <gohman at apple.com> changed:

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

--- Comment #1 from Dan Gohman <gohman at apple.com> 2010-03-09 17:47:19 CST ---
Fixed on trunk in r98103.

-- 
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 llvm.org  Tue Mar  9 20:23:31 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  9 Mar 2010 20:23:31 -0600 (CST)
Subject: [LLVMbugs] [Bug 6474] Specialization-after-instantiation diagnostic
 due to implicit virtual member function instantiation
In-Reply-To: <bug-6474-206@http.llvm.org/bugs/>
References: <bug-6474-206@http.llvm.org/bugs/>
Message-ID: <20100310022331.496002A6C12D@llvm.org>

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

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

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

--- Comment #21 from Rafael ?vila de Esp?ndola <rafael.espindola at gmail.com> 2010-03-09 20:23:30 CST ---
I am closing this bug as the original testcase has been fixed.

Doug, please open a new bug with the "extern template" issue and assign it to
me if you want.

-- 
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 llvm.org  Tue Mar  9 21:32:49 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  9 Mar 2010 21:32:49 -0600 (CST)
Subject: [LLVMbugs] [Bug 6326] Assert when a class friends itself
In-Reply-To: <bug-6326-206@http.llvm.org/bugs/>
References: <bug-6326-206@http.llvm.org/bugs/>
Message-ID: <20100310033249.906F32A6C12E@llvm.org>

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

John McCall <rjmccall at apple.com> changed:

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

--- Comment #4 from John McCall <rjmccall at apple.com> 2010-03-09 21:32:48 CST ---
I believe the problem was with instantiating any sort of type source info for a
class template's injected class name.  This ended up being remarkably
complicated to fix, but it should be done in r98134.

-- 
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 llvm.org  Tue Mar  9 22:00:03 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  9 Mar 2010 22:00:03 -0600 (CST)
Subject: [LLVMbugs] [Bug 6563] New: accepts invalid template argument
Message-ID: <bug-6563-206@http.llvm.org/bugs/>

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

           Summary: accepts invalid template argument
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: rafael.espindola at gmail.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


clang accepts the following:

---------------------
int *bar;
template <int *>
struct zed {};
void g(zed<bar>*)
{}
-------------------

But that doesn't match the restrictions defined in 14.3.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 llvm.org  Wed Mar 10 04:36:56 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 10 Mar 2010 04:36:56 -0600 (CST)
Subject: [LLVMbugs] [Bug 6564] New: Assertion failed "Key function
	changed"...
Message-ID: <bug-6564-206@http.llvm.org/bugs/>

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

           Summary: Assertion failed "Key function changed"...
           Product: clang
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: Fons.Rademakers at cern.ch
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


Compiling the attached file with clang++ -c aap.cxx gives:

(proof) [137] clang++ -c aap.cxxAssertion failed: (Entry ==
ASTRecordLayoutBuilder::ComputeKeyFunction(RD) && "Key function changed!"),
function getKeyFunction, file
/Users/rdm/llvm/src/tools/clang/lib/AST/ASTContext.cpp, line 1232.
0  clang             0x0000000100d49c5f PrintStackTrace(void*) + 38
1  clang             0x0000000100d4a1ed SignalHandler(int) + 336
2  libSystem.B.dylib 0x00007fff88a66eaa _sigtramp + 26
3  libSystem.B.dylib 000000000000000000 _sigtramp + 2002358640
4  libSystem.B.dylib 0x00007fff88ae2e74 __pthread_markcancel + 0
5  clang             0x00000001004e7a94
clang::ASTContext::getKeyFunction(clang::CXXRecordDecl const*) + 220
6  clang             0x00000001002096ac
clang::CodeGen::CodeGenModule::MayDeferGeneration(clang::ValueDecl const*) +
320
7  clang             0x000000010020bddf
clang::CodeGen::CodeGenModule::EmitGlobal(clang::CodeGen::GlobalDecl) + 249
8  clang             0x000000010014baed
clang::CodeGen::CodeGenModule::EmitCXXConstructors(clang::CXXConstructorDecl
const*) + 47
9  clang             0x000000010020c0d5
clang::CodeGen::CodeGenModule::EmitTopLevelDecl(clang::Decl*) + 643
10 clang             0x0000000100225252 (anonymous
namespace)::CodeGeneratorImpl::HandleTopLevelDecl(clang::DeclGroupRef) + 76
11 clang             0x0000000100038e7e (anonymous
namespace)::BackendConsumer::HandleTopLevelDecl(clang::DeclGroupRef) + 144
12 clang             0x00000001003bee15
clang::Sema::InstantiateFunctionDefinition(clang::SourceLocation,
clang::FunctionDecl*, bool, bool) + 1511
13 clang             0x00000001003be664
clang::Sema::PerformPendingImplicitInstantiations(bool) + 336
14 clang             0x0000000100232c61
clang::Sema::ActOnEndOfTranslationUnit() + 225
15 clang             0x000000010060147b
clang::Parser::ParseTopLevelDecl(clang::OpaquePtr<1>&) + 91
16 clang             0x0000000100231e71 clang::ParseAST(clang::Preprocessor&,
clang::ASTConsumer*, clang::ASTContext&, bool, bool,
clang::CodeCompleteConsumer*) + 523
17 clang             0x000000010005a2d8
clang::ASTFrontendAction::ExecuteAction() + 256
18 clang             0x000000010005a3c8 clang::FrontendAction::Execute() + 226
19 clang             0x000000010003e114
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 726
20 clang             0x000000010001e15c cc1_main(char const**, char const**,
char const*, void*) + 1296
21 clang             0x0000000100022361 main + 252
22 clang             0x000000010001d134 start + 52
Stack dump:
0.      Program arguments: /Users/rdm/llvm/inst/bin/clang -cc1 -triple
x86_64-apple-darwin10.0.0 -S -disable-free -main-file-name aap.cxx -pic-level 1
-mdisable-fp-elim -munwind-tables -target-cpu core2 -resource-dir
/Users/rdm/llvm/inst/lib/clang/1.1 -fmessage-length 80 -stack-protector 1
-fblocks -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o
/var/folders/zK/zKJDfZztH5upJbZEL05q7U+++TI/-Tmp-/cc-LvCuEU.s -x c++ aap.cxx 
1.      <eof> parser at end of file
2.      math/mathcore/src/FunctorCint.cxx:35:4: instantiating function
definition 'ROOT::Math::FunctorCintHandler<class
ROOT::Math::Functor>::FunctorCintHandler'
3.      math/mathcore/src/FunctorCint.cxx:35:4: LLVM IR generation of
declaration 'ROOT::Math::FunctorCintHandler<class
ROOT::Math::Functor>::FunctorCintHandler'
clang: error: compiler command failed due to signal 6 (use -v to see
invocation)

-- 
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 llvm.org  Wed Mar 10 04:40:29 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 10 Mar 2010 04:40:29 -0600 (CST)
Subject: [LLVMbugs] [Bug 6565] New: Assertion failed: incorrect data size
 provided to CreateTypeSourceInfo!
Message-ID: <bug-6565-206@http.llvm.org/bugs/>

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

           Summary: Assertion failed: incorrect data size provided to
                    CreateTypeSourceInfo!
           Product: clang
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: Fons.Rademakers at cern.ch
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


When doing clang++ -c aap.cxx the result will be:

Assertion failed: (DataSize == TypeLoc::getFullDataSizeForType(T) && "incorrect
data size provided to CreateTypeSourceInfo!"), function CreateTypeSourceInfo,
file /Users/rdm/llvm/src/tools/clang/lib/AST/ASTContext.cpp, line 1144.
0  clang             0x0000000100d49c5f PrintStackTrace(void*) + 38
1  clang             0x0000000100d4a1ed SignalHandler(int) + 336
2  libSystem.B.dylib 0x00007fff88a66eaa _sigtramp + 26
3  libSystem.B.dylib 0x00000015002623ec _sigtramp + 2004858204
4  libSystem.B.dylib 0x00007fff88ae2e74 __pthread_markcancel + 0
5  clang             0x00000001004e7d37
clang::ASTContext::CreateTypeSourceInfo(clang::QualType, unsigned int) + 103
6  clang             0x000000010037d6d7
clang::TypeLocBuilder::getTypeSourceInfo(clang::ASTContext&, clang::QualType) +
143
7  clang             0x000000010039ca6c clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformType(clang::TypeSourceInfo*,
clang::QualType) + 286
8  clang             0x000000010039e26c clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformType(clang::QualType,
clang::QualType) + 178
9  clang             0x00000001003a30c2 clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformNestedNameSpecifier(clang::NestedNameSpecifier*,
clang::SourceRange, clang::QualType, clang::NamedDecl*) + 934
10 clang             0x00000001003a8841 clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformDeclRefExpr(clang::DeclRefExpr*) +
171
11 clang             0x00000001003a8d39 (anonymous
namespace)::TemplateInstantiator::TransformDeclRefExpr(clang::DeclRefExpr*) +
173
12 clang             0x0000000100392ab5 clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformExpr(clang::Expr*) + 753
13 clang             0x0000000100397a01 clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformImplicitCastExpr(clang::ImplicitCastExpr*)
+ 63
14 clang             0x00000001003930a0 clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformExpr(clang::Expr*) + 2268
15 clang             0x00000001003983ae clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformCallExpr(clang::CallExpr*) + 98
16 clang             0x0000000100392e9d clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformExpr(clang::Expr*) + 1753
17 clang             0x0000000100399a79 clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformReturnStmt(clang::ReturnStmt*) + 77
18 clang             0x0000000100391b54 clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformStmt(clang::Stmt*) + 2066
19 clang             0x000000010039227a clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformCompoundStmt(clang::CompoundStmt*,
bool) + 178
20 clang             0x00000001003a8ef5 clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformCompoundStmt(clang::CompoundStmt*)
+ 55
21 clang             0x0000000100391631 clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformStmt(clang::Stmt*) + 751
22 clang             0x00000001003ab710 clang::Sema::SubstStmt(clang::Stmt*,
clang::MultiLevelTemplateArgumentList const&) + 200
23 clang             0x00000001003becf6
clang::Sema::InstantiateFunctionDefinition(clang::SourceLocation,
clang::FunctionDecl*, bool, bool) + 1224
24 clang             0x00000001003a50e7
clang::Sema::InstantiateClassMembers(clang::SourceLocation,
clang::CXXRecordDecl*, clang::MultiLevelTemplateArgumentList const&,
clang::TemplateSpecializationKind) + 461
25 clang             0x00000001003ac638
clang::Sema::InstantiateClassTemplateSpecializationMembers(clang::SourceLocation,
clang::ClassTemplateSpecializationDecl*, clang::TemplateSpecializationKind) +
92
26 clang             0x000000010036b2f8
clang::Sema::ActOnExplicitInstantiation(clang::Scope*, clang::SourceLocation,
clang::SourceLocation, unsigned int, clang::SourceLocation, clang::CXXScopeSpec
const&, clang::OpaquePtr<2>, clang::SourceLocation, clang::SourceLocation,
clang::ASTTemplateArgsPtr, clang::SourceLocation, clang::AttributeList*) + 2012
27 clang             0x00000001005cd17c
clang::Parser::ParseClassSpecifier(clang::tok::TokenKind,
clang::SourceLocation, clang::DeclSpec&, clang::Parser::ParsedTemplateInfo
const&, clang::AccessSpecifier, bool) + 2930
28 clang             0x00000001005c0e7d
clang::Parser::ParseDeclarationSpecifiers(clang::DeclSpec&,
clang::Parser::ParsedTemplateInfo const&, clang::AccessSpecifier,
clang::Parser::DeclSpecContext) + 6781
29 clang             0x00000001005fa801
clang::Parser::ParseSingleDeclarationAfterTemplate(unsigned int,
clang::Parser::ParsedTemplateInfo const&, clang::SourceLocation&,
clang::AccessSpecifier) + 365
30 clang             0x00000001005fac9b
clang::Parser::ParseExplicitInstantiation(clang::SourceLocation,
clang::SourceLocation, clang::SourceLocation&) + 65
31 clang             0x00000001005fb17d
clang::Parser::ParseDeclarationStartingWithTemplate(unsigned int,
clang::SourceLocation&, clang::AccessSpecifier) + 133
32 clang             0x00000001005c4f4f
clang::Parser::ParseDeclaration(unsigned int, clang::SourceLocation&,
clang::CXX0XAttributeList) + 331
33 clang             0x00000001006012f5
clang::Parser::ParseExternalDeclaration(clang::CXX0XAttributeList) + 1985
34 clang             0x0000000100601517
clang::Parser::ParseTopLevelDecl(clang::OpaquePtr<1>&) + 247
35 clang             0x0000000100231e71 clang::ParseAST(clang::Preprocessor&,
clang::ASTConsumer*, clang::ASTContext&, bool, bool,
clang::CodeCompleteConsumer*) + 523
36 clang             0x000000010005a2d8
clang::ASTFrontendAction::ExecuteAction() + 256
37 clang             0x000000010005a3c8 clang::FrontendAction::Execute() + 226
38 clang             0x000000010003e114
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 726
39 clang             0x000000010001e15c cc1_main(char const**, char const**,
char const*, void*) + 1296
40 clang             0x0000000100022361 main + 252
41 clang             0x000000010001d134 start + 52
Stack dump:
0.      Program arguments: /Users/rdm/llvm/inst/bin/clang -cc1 -triple
x86_64-apple-darwin10.0.0 -S -disable-free -main-file-name aap.cxx -pic-level 1
-mdisable-fp-elim -munwind-tables -target-cpu core2 -resource-dir
/Users/rdm/llvm/inst/lib/clang/1.1 -fmessage-length 80 -stack-protector 1
-fblocks -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o
/var/folders/zK/zKJDfZztH5upJbZEL05q7U+++TI/-Tmp-/cc-3gn258.s -x c++ aap.cxx 
1.      math/mathcore/src/TKDTree.cxx:1212:39: current parser token ';'
clang: error: compiler command failed due to signal 6 (use -v to see
invocation)

File compiles fine with g++.

Cheers, Fons.

-- 
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 llvm.org  Wed Mar 10 04:48:13 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 10 Mar 2010 04:48:13 -0600 (CST)
Subject: [LLVMbugs] [Bug 6566] New: Assertion failed: should always have a
 canonical type here
Message-ID: <bug-6566-206@http.llvm.org/bugs/>

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

           Summary: Assertion failed: should always have a canonical type
                    here
           Product: clang
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: Fons.Rademakers at cern.ch
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


Doing clang++ -c aap.cxx fails with:

Assertion failed: (Ty.isCanonical() && "should always have a canonical type
here"), function getCoerceResult, file
/Users/rdm/llvm/src/tools/clang/lib/CodeGen/TargetInfo.cpp, line 1052.
0  clang             0x0000000100d49c5f PrintStackTrace(void*) + 38
1  clang             0x0000000100d4a1ed SignalHandler(int) + 336
2  libSystem.B.dylib 0x00007fff88a66eaa _sigtramp + 26
3  libSystem.B.dylib 0x00007fff88a0bbea tiny_malloc_from_free_list + 1196
4  libSystem.B.dylib 0x00007fff88ae2e74 __pthread_markcancel + 0
5  clang             0x00000001002287d6 (anonymous
namespace)::X86_64ABIInfo::getCoerceResult(clang::QualType, llvm::Type const*,
clang::ASTContext&) const + 320
6  clang             0x000000010022a060 (anonymous
namespace)::X86_64ABIInfo::classifyArgumentType(clang::QualType,
clang::ASTContext&, llvm::LLVMContext&, unsigned int&, unsigned int&) const +
860
7  clang             0x000000010022a100 (anonymous
namespace)::X86_64ABIInfo::EmitVAArg(llvm::Value*, clang::QualType,
clang::CodeGen::CodeGenFunction&) const + 154
8  clang             0x000000010014dbc1
clang::CodeGen::CodeGenFunction::EmitVAArg(llvm::Value*, clang::QualType) + 71
9  clang             0x00000001001963d8 (anonymous
namespace)::ScalarExprEmitter::VisitVAArgExpr(clang::VAArgExpr*) + 72
10 clang             0x000000010019bbe5 clang::StmtVisitor<(anonymous
namespace)::ScalarExprEmitter, llvm::Value*>::Visit(clang::Stmt*) + 3339
11 clang             0x000000010019aad7 (anonymous
namespace)::ScalarExprEmitter::EmitCastExpr(clang::CastExpr*) + 3101
12 clang             0x000000010019adb7 (anonymous
namespace)::ScalarExprEmitter::VisitCastExpr(clang::CastExpr*) + 87
13 clang             0x000000010019add7 clang::StmtVisitor<(anonymous
namespace)::ScalarExprEmitter,
llvm::Value*>::VisitImplicitCastExpr(clang::ImplicitCastExpr*) + 29
14 clang             0x000000010019bb1d clang::StmtVisitor<(anonymous
namespace)::ScalarExprEmitter, llvm::Value*>::Visit(clang::Stmt*) + 3139
15 clang             0x000000010019a070 (anonymous
namespace)::ScalarExprEmitter::EmitCastExpr(clang::CastExpr*) + 438
16 clang             0x000000010019adb7 (anonymous
namespace)::ScalarExprEmitter::VisitCastExpr(clang::CastExpr*) + 87
17 clang             0x000000010019adf7 clang::StmtVisitor<(anonymous
namespace)::ScalarExprEmitter,
llvm::Value*>::VisitExplicitCastExpr(clang::ExplicitCastExpr*) + 29
18 clang             0x000000010019ae17 clang::StmtVisitor<(anonymous
namespace)::ScalarExprEmitter,
llvm::Value*>::VisitCStyleCastExpr(clang::CStyleCastExpr*) + 29
19 clang             0x000000010019bb36 clang::StmtVisitor<(anonymous
namespace)::ScalarExprEmitter, llvm::Value*>::Visit(clang::Stmt*) + 3164
20 clang             0x000000010019cf80 (anonymous
namespace)::ScalarExprEmitter::VisitBinAssign(clang::BinaryOperator const*) +
68
21 clang             0x000000010019b1e3 clang::StmtVisitor<(anonymous
namespace)::ScalarExprEmitter, llvm::Value*>::Visit(clang::Stmt*) + 777
22 clang             0x000000010019c0fb
clang::CodeGen::CodeGenFunction::EmitScalarExpr(clang::Expr const*, bool) + 131
23 clang             0x0000000100178823
clang::CodeGen::CodeGenFunction::EmitAnyExpr(clang::Expr const*, llvm::Value*,
bool, bool, bool) + 83
24 clang             0x00000001001da052
clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*) + 450
25 clang             0x00000001001dae1a
clang::CodeGen::CodeGenFunction::EmitForStmt(clang::ForStmt const&) + 748
26 clang             0x00000001001da142
clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*) + 690
27 clang             0x00000001001db710
clang::CodeGen::CodeGenFunction::EmitCompoundStmt(clang::CompoundStmt const&,
bool, llvm::Value*, bool) + 288
28 clang             0x00000001001db92a
clang::CodeGen::CodeGenFunction::EmitSimpleStmt(clang::Stmt const*) + 198
29 clang             0x00000001001d9ede
clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*) + 78
30 clang             0x000000010015a668
clang::CodeGen::CodeGenFunction::EmitConstructorBody(llvm::SmallVector<std::pair<clang::VarDecl
const*, clang::QualType>, 16u>&) + 356
31 clang             0x0000000100202ee9
clang::CodeGen::CodeGenFunction::GenerateCode(clang::CodeGen::GlobalDecl,
llvm::Function*) + 1455
32 clang             0x000000010014c230
clang::CodeGen::CodeGenModule::EmitCXXConstructor(clang::CXXConstructorDecl
const*, clang::CXXCtorType) + 316
33 clang             0x000000010020bc30
clang::CodeGen::CodeGenModule::EmitGlobalDefinition(clang::CodeGen::GlobalDecl)
+ 460
34 clang             0x000000010020be4f
clang::CodeGen::CodeGenModule::EmitGlobal(clang::CodeGen::GlobalDecl) + 361
35 clang             0x000000010014baed
clang::CodeGen::CodeGenModule::EmitCXXConstructors(clang::CXXConstructorDecl
const*) + 47
36 clang             0x000000010020c0d5
clang::CodeGen::CodeGenModule::EmitTopLevelDecl(clang::Decl*) + 643
37 clang             0x0000000100225252 (anonymous
namespace)::CodeGeneratorImpl::HandleTopLevelDecl(clang::DeclGroupRef) + 76
38 clang             0x0000000100038e7e (anonymous
namespace)::BackendConsumer::HandleTopLevelDecl(clang::DeclGroupRef) + 144
39 clang             0x00000001003bee15
clang::Sema::InstantiateFunctionDefinition(clang::SourceLocation,
clang::FunctionDecl*, bool, bool) + 1511
40 clang             0x00000001003a50e7
clang::Sema::InstantiateClassMembers(clang::SourceLocation,
clang::CXXRecordDecl*, clang::MultiLevelTemplateArgumentList const&,
clang::TemplateSpecializationKind) + 461
41 clang             0x00000001003ac638
clang::Sema::InstantiateClassTemplateSpecializationMembers(clang::SourceLocation,
clang::ClassTemplateSpecializationDecl*, clang::TemplateSpecializationKind) +
92
42 clang             0x000000010036b2f8
clang::Sema::ActOnExplicitInstantiation(clang::Scope*, clang::SourceLocation,
clang::SourceLocation, unsigned int, clang::SourceLocation, clang::CXXScopeSpec
const&, clang::OpaquePtr<2>, clang::SourceLocation, clang::SourceLocation,
clang::ASTTemplateArgsPtr, clang::SourceLocation, clang::AttributeList*) + 2012
43 clang             0x00000001005cd17c
clang::Parser::ParseClassSpecifier(clang::tok::TokenKind,
clang::SourceLocation, clang::DeclSpec&, clang::Parser::ParsedTemplateInfo
const&, clang::AccessSpecifier, bool) + 2930
44 clang             0x00000001005c0e7d
clang::Parser::ParseDeclarationSpecifiers(clang::DeclSpec&,
clang::Parser::ParsedTemplateInfo const&, clang::AccessSpecifier,
clang::Parser::DeclSpecContext) + 6781
45 clang             0x00000001005fa801
clang::Parser::ParseSingleDeclarationAfterTemplate(unsigned int,
clang::Parser::ParsedTemplateInfo const&, clang::SourceLocation&,
clang::AccessSpecifier) + 365
46 clang             0x00000001005fac9b
clang::Parser::ParseExplicitInstantiation(clang::SourceLocation,
clang::SourceLocation, clang::SourceLocation&) + 65
47 clang             0x00000001005fb17d
clang::Parser::ParseDeclarationStartingWithTemplate(unsigned int,
clang::SourceLocation&, clang::AccessSpecifier) + 133
48 clang             0x00000001005c4f4f
clang::Parser::ParseDeclaration(unsigned int, clang::SourceLocation&,
clang::CXX0XAttributeList) + 331
49 clang             0x00000001006012f5
clang::Parser::ParseExternalDeclaration(clang::CXX0XAttributeList) + 1985
50 clang             0x0000000100601517
clang::Parser::ParseTopLevelDecl(clang::OpaquePtr<1>&) + 247
51 clang             0x0000000100231e71 clang::ParseAST(clang::Preprocessor&,
clang::ASTConsumer*, clang::ASTContext&, bool, bool,
clang::CodeCompleteConsumer*) + 523
52 clang             0x000000010005a2d8
clang::ASTFrontendAction::ExecuteAction() + 256
53 clang             0x000000010005a3c8 clang::FrontendAction::Execute() + 226
54 clang             0x000000010003e114
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 726
55 clang             0x000000010001e15c cc1_main(char const**, char const**,
char const*, void*) + 1296
56 clang             0x0000000100022361 main + 252
57 clang             0x000000010001d134 start + 52
Stack dump:
0.      Program arguments: /Users/rdm/llvm/inst/bin/clang -cc1 -triple
x86_64-apple-darwin10.0.0 -S -disable-free -main-file-name aap.cxx -pic-level 1
-mdisable-fp-elim -munwind-tables -target-cpu core2 -resource-dir
/Users/rdm/llvm/inst/lib/clang/1.1 -fmessage-length 80 -stack-protector 1
-fblocks -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o
/var/folders/zK/zKJDfZztH5upJbZEL05q7U+++TI/-Tmp-/cc-1e1TRq.s -x c++ aap.cxx 
1.      math/matrix/src/TVectorT.cxx:2371:33: current parser token ';'
2.      include/TVectorT.h:75:4: LLVM IR generation of declaration
'TVectorT<float>::TVectorT'
3.      include/TVectorT.h:75:4: Generating code for declaration
'TVectorT<float>::TVectorT'
4.      math/matrix/src/TVectorT.cxx:259:1: LLVM IR generation of compound
statement ('{}')
clang: error: compiler command failed due to signal 6 (use -v to see
invocation)


Using g++ succeeds.

Cheers, Fons.

-- 
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 llvm.org  Wed Mar 10 04:50:17 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 10 Mar 2010 04:50:17 -0600 (CST)
Subject: [LLVMbugs] [Bug 6567] New: Assertion failed: Cannot get layout of
 forward declarations!
Message-ID: <bug-6567-206@http.llvm.org/bugs/>

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

           Summary: Assertion failed: Cannot get layout of forward
                    declarations!
           Product: clang
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: Fons.Rademakers at cern.ch
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


Doing clang++ -c aap.cxx fails with:

Assertion failed: (D && "Cannot get layout of forward declarations!"), function
getASTRecordLayout, file
/Users/rdm/llvm/src/tools/clang/lib/AST/ASTContext.cpp, line 1208.
0  clang             0x0000000100d49c5f PrintStackTrace(void*) + 38
1  clang             0x0000000100d4a1ed SignalHandler(int) + 336
2  libSystem.B.dylib 0x00007fff88a66eaa _sigtramp + 26
3  libSystem.B.dylib 0x00007fff88a0bbea tiny_malloc_from_free_list + 1196
4  libSystem.B.dylib 0x00007fff88ae2e74 __pthread_markcancel + 0
5  clang             0x00000001004e7af0
clang::ASTContext::getASTRecordLayout(clang::RecordDecl const*) + 78
6  clang             0x00000001004e8983
clang::ASTContext::getTypeInfo(clang::Type const*) + 2469
7  clang             0x00000001004e8daf
clang::ASTContext::getTypeInfo(clang::Type const*) + 3537
8  clang             0x00000001004e8b67
clang::ASTContext::getTypeInfo(clang::Type const*) + 2953
9  clang             0x000000010055db9d
clang::ASTContext::getTypeInfo(clang::QualType) + 37
10 clang             0x00000001002974b5
clang::ASTContext::getTypeAlign(clang::QualType) + 29
11 clang             0x00000001004ec91a
clang::ASTContext::getTypeAlignInChars(clang::QualType) + 30
12 clang             0x0000000100178c4c
clang::CodeGen::CodeGenFunction::CreateMemTemp(clang::QualType, llvm::Twine
const&) + 74
13 clang             0x000000010017f061 (anonymous
namespace)::AggExprEmitter::VisitCXXExprWithTemporaries(clang::CXXExprWithTemporaries*)
+ 79
14 clang             0x000000010018179f clang::StmtVisitor<(anonymous
namespace)::AggExprEmitter, void>::Visit(clang::Stmt*) + 3587
15 clang             0x00000001001819f7
clang::CodeGen::CodeGenFunction::EmitAggExpr(clang::Expr const*, llvm::Value*,
bool, bool, bool, bool) + 261
16 clang             0x00000001001788d5
clang::CodeGen::CodeGenFunction::EmitAnyExpr(clang::Expr const*, llvm::Value*,
bool, bool, bool) + 261
17 clang             0x00000001001da052
clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*) + 450
18 clang             0x00000001001db710
clang::CodeGen::CodeGenFunction::EmitCompoundStmt(clang::CompoundStmt const&,
bool, llvm::Value*, bool) + 288
19 clang             0x00000001001db92a
clang::CodeGen::CodeGenFunction::EmitSimpleStmt(clang::Stmt const*) + 198
20 clang             0x00000001001d9ede
clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*) + 78
21 clang             0x00000001002019b5
clang::CodeGen::CodeGenFunction::EmitFunctionBody(llvm::SmallVector<std::pair<clang::VarDecl
const*, clang::QualType>, 16u>&) + 93
22 clang             0x0000000100202efe
clang::CodeGen::CodeGenFunction::GenerateCode(clang::CodeGen::GlobalDecl,
llvm::Function*) + 1476
23 clang             0x000000010020b118
clang::CodeGen::CodeGenModule::EmitGlobalFunctionDefinition(clang::CodeGen::GlobalDecl)
+ 840
24 clang             0x000000010020bc89
clang::CodeGen::CodeGenModule::EmitGlobalDefinition(clang::CodeGen::GlobalDecl)
+ 549
25 clang             0x000000010020be4f
clang::CodeGen::CodeGenModule::EmitGlobal(clang::CodeGen::GlobalDecl) + 361
26 clang             0x000000010020c040
clang::CodeGen::CodeGenModule::EmitTopLevelDecl(clang::Decl*) + 494
27 clang             0x0000000100225252 (anonymous
namespace)::CodeGeneratorImpl::HandleTopLevelDecl(clang::DeclGroupRef) + 76
28 clang             0x0000000100038e7e (anonymous
namespace)::BackendConsumer::HandleTopLevelDecl(clang::DeclGroupRef) + 144
29 clang             0x0000000100231e5e clang::ParseAST(clang::Preprocessor&,
clang::ASTConsumer*, clang::ASTContext&, bool, bool,
clang::CodeCompleteConsumer*) + 504
30 clang             0x000000010005a2d8
clang::ASTFrontendAction::ExecuteAction() + 256
31 clang             0x000000010005a3c8 clang::FrontendAction::Execute() + 226
32 clang             0x000000010003e114
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 726
33 clang             0x000000010001e15c cc1_main(char const**, char const**,
char const*, void*) + 1296
34 clang             0x0000000100022361 main + 252
35 clang             0x000000010001d134 start + 52
Stack dump:
0.      Program arguments: /Users/rdm/llvm/inst/bin/clang -cc1 -triple
x86_64-apple-darwin10.0.0 -S -disable-free -main-file-name aap.cxx -pic-level 1
-mdisable-fp-elim -munwind-tables -target-cpu core2 -resource-dir
/Users/rdm/llvm/inst/lib/clang/1.1 -fmessage-length 80 -stack-protector 1
-fblocks -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o
/var/folders/zK/zKJDfZztH5upJbZEL05q7U+++TI/-Tmp-/cc-auCAtO.s -x c++ aap.cxx 
1.      graf3d/eve/src/TEveStraightLineSet.cxx:111:1: current parser token
'TClass'
2.      graf3d/eve/src/TEveStraightLineSet.cxx:94:27: LLVM IR generation of
declaration 'TEveStraightLineSet::WriteVizParams'
3.      graf3d/eve/src/TEveStraightLineSet.cxx:94:27: Generating code for
declaration 'TEveStraightLineSet::WriteVizParams'
4.      graf3d/eve/src/TEveStraightLineSet.cxx:95:1: LLVM IR generation of
compound statement ('{}')
clang: error: compiler command failed due to signal 6 (use -v to see
invocation)

Using g++ works.

Cheers, Fons.

-- 
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 llvm.org  Wed Mar 10 05:01:30 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 10 Mar 2010 05:01:30 -0600 (CST)
Subject: [LLVMbugs] [Bug 6568] New: Assertion failed: Default argument is
 not yet parsed!
Message-ID: <bug-6568-206@http.llvm.org/bugs/>

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

           Summary: Assertion failed: Default argument is not yet parsed!
           Product: clang
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: Fons.Rademakers at cern.ch
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


Created an attachment (id=4464)
 --> (http://llvm.org/bugs/attachment.cgi?id=4464)
Source file exhibiting the failed assertion

Doing clang++ -c aap.cxx fails:

Assertion failed: (!hasUnparsedDefaultArg() && "Default argument is not yet
parsed!"), function getDefaultArg, file
/Users/rdm/llvm/src/tools/clang/lib/AST/Decl.cpp, line 761.
0  clang             0x0000000100d49c5f PrintStackTrace(void*) + 38
1  clang             0x0000000100d4a1ed SignalHandler(int) + 336
2  libSystem.B.dylib 0x00007fff88a66eaa _sigtramp + 26
3  libSystem.B.dylib 0x00007fff88a0bbea tiny_malloc_from_free_list + 1196
4  libSystem.B.dylib 0x00007fff88ae2e74 __pthread_markcancel + 0
5  clang             0x00000001005257df clang::ParmVarDecl::getDefaultArg() +
75
6  clang             0x00000001003b942c (anonymous
namespace)::TemplateDeclInstantiator::VisitParmVarDecl(clang::ParmVarDecl*) +
452
7  clang             0x00000001003b9530 (anonymous
namespace)::TemplateDeclInstantiator::SubstFunctionType(clang::FunctionDecl*,
llvm::SmallVectorImpl<clang::ParmVarDecl*>&) + 176
8  clang             0x00000001003b9a4a (anonymous
namespace)::TemplateDeclInstantiator::VisitCXXMethodDecl(clang::CXXMethodDecl*,
clang::TemplateParameterList*) + 488
9  clang             0x00000001003bcf2c clang::DeclVisitor<(anonymous
namespace)::TemplateDeclInstantiator, clang::Decl*>::Visit(clang::Decl*) + 662
10 clang             0x00000001003be0c1 clang::Sema::SubstDecl(clang::Decl*,
clang::DeclContext*, clang::MultiLevelTemplateArgumentList const&) + 81
11 clang             0x00000001003a4c6a
clang::Sema::InstantiateClass(clang::SourceLocation, clang::CXXRecordDecl*,
clang::CXXRecordDecl*, clang::MultiLevelTemplateArgumentList const&,
clang::TemplateSpecializationKind, bool) + 1018
12 clang             0x00000001003acce0
clang::Sema::InstantiateClassTemplateSpecialization(clang::SourceLocation,
clang::ClassTemplateSpecializationDecl*, clang::TemplateSpecializationKind,
bool) + 1672
13 clang             0x00000001003c1ef2
clang::Sema::RequireCompleteType(clang::SourceLocation, clang::QualType,
clang::PartialDiagnostic const&, std::pair<clang::SourceLocation,
clang::PartialDiagnostic>) + 322
14 clang             0x0000000100274352
clang::Sema::CheckFieldDecl(clang::DeclarationName, clang::QualType,
clang::TypeSourceInfo*, clang::RecordDecl*, clang::SourceLocation, bool,
clang::Expr*, clang::SourceLocation, clang::AccessSpecifier, clang::NamedDecl*,
clang::Declarator*) + 356
15 clang             0x000000010027ebb2 clang::Sema::HandleField(clang::Scope*,
clang::RecordDecl*, clang::SourceLocation, clang::Declarator&, clang::Expr*,
clang::AccessSpecifier) + 748
16 clang             0x00000001002aaa53
clang::Sema::ActOnCXXMemberDeclarator(clang::Scope*, clang::AccessSpecifier,
clang::Declarator&,
clang::ASTMultiPtr<&(clang::ActionBase::DeleteTemplateParams(void*))>, void*,
void*, bool, bool) + 1113
17 clang             0x00000001005cbc73
clang::Parser::ParseCXXClassMemberDeclaration(clang::AccessSpecifier,
clang::Parser::ParsedTemplateInfo const&) + 3443
18 clang             0x00000001005cc421
clang::Parser::ParseCXXMemberSpecification(clang::SourceLocation, unsigned int,
clang::OpaquePtr<0>) + 1105
19 clang             0x00000001005cda1f
clang::Parser::ParseClassSpecifier(clang::tok::TokenKind,
clang::SourceLocation, clang::DeclSpec&, clang::Parser::ParsedTemplateInfo
const&, clang::AccessSpecifier, bool) + 5141
20 clang             0x00000001005c0e7d
clang::Parser::ParseDeclarationSpecifiers(clang::DeclSpec&,
clang::Parser::ParsedTemplateInfo const&, clang::AccessSpecifier,
clang::Parser::DeclSpecContext) + 6781
21 clang             0x00000001005ff276
clang::Parser::ParseDeclarationOrFunctionDefinition(clang::Parser::ParsingDeclSpec&,
clang::AttributeList*, clang::AccessSpecifier) + 118
22 clang             0x00000001005ff689
clang::Parser::ParseDeclarationOrFunctionDefinition(clang::AttributeList*,
clang::AccessSpecifier) + 83
23 clang             0x00000001006013d9
clang::Parser::ParseExternalDeclaration(clang::CXX0XAttributeList) + 2213
24 clang             0x0000000100601517
clang::Parser::ParseTopLevelDecl(clang::OpaquePtr<1>&) + 247
25 clang             0x0000000100231e71 clang::ParseAST(clang::Preprocessor&,
clang::ASTConsumer*, clang::ASTContext&, bool, bool,
clang::CodeCompleteConsumer*) + 523
26 clang             0x000000010005a2d8
clang::ASTFrontendAction::ExecuteAction() + 256
27 clang             0x000000010005a3c8 clang::FrontendAction::Execute() + 226
28 clang             0x000000010003e114
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 726
29 clang             0x000000010001e15c cc1_main(char const**, char const**,
char const*, void*) + 1296
30 clang             0x0000000100022361 main + 252
31 clang             0x000000010001d134 start + 52
Stack dump:
0.      Program arguments: /Users/rdm/llvm/inst/bin/clang -cc1 -triple
x86_64-apple-darwin10.0.0 -S -disable-free -main-file-name aap.cxx -pic-level 1
-mdisable-fp-elim -munwind-tables -target-cpu core2 -resource-dir
/Users/rdm/llvm/inst/lib/clang/1.1 -fmessage-length 80 -stack-protector 1
-fblocks -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o
/var/folders/zK/zKJDfZztH5upJbZEL05q7U+++TI/-Tmp-/cc-IGxIQz.s -x c++ aap.cxx 
1.      /Users/rdm/Dropbox/src/pythia8125/include/SusyLesHouches.h:443:20:
current parser token ';'
2.      /Users/rdm/Dropbox/src/pythia8125/include/SusyLesHouches.h:32:1:
parsing struct/union/class body 'SusyLesHouches'
clang: error: compiler command failed due to signal 6 (use -v to see
invocation)

With g++ it compiles fine.

Cheers, Fons.

-- 
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 llvm.org  Wed Mar 10 05:22:08 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 10 Mar 2010 05:22:08 -0600 (CST)
Subject: [LLVMbugs] [Bug 6569] New: clang fails assertion for
 namespace/friend construct.
Message-ID: <bug-6569-206@http.llvm.org/bugs/>

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

           Summary: clang fails assertion for namespace/friend construct.
           Product: clang
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: bjorn at topel.se
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


namespace.cc:

namespace Foo {
    class Bar;
}

class Foo::Bar {
    friend class Friend;
};

---

bjoto at bjorn-topels-macbook-pro:~/Source/scratch/simpleclangtest$
~/pkg/clang+llvm/bin/clang++ -c namespace.cc
Assertion failed: (S && "No enclosing scope matching the enclosing
namespace."), function ActOnTag, file SemaDecl.cpp, line 4800.
0  clang             0x0000000100f46247 PrintStackTrace(void*) + 38
1  clang             0x0000000100f467d5 SignalHandler(int) + 336
2  libSystem.B.dylib 0x00007fff80c3beaa _sigtramp + 26
3  libSystem.B.dylib 0x00007fff80be0bea tiny_malloc_from_free_list + 1196
4  libSystem.B.dylib 0x00007fff80cb7e74 __pthread_markcancel + 0
5  clang             0x0000000100288c48 clang::Sema::ActOnTag(clang::Scope*,
unsigned int, clang::Action::TagUseKind, clang::SourceLocation,
clang::CXXScopeSpec const&, clang::IdentifierInfo*, clang::SourceLocation,
clang::AttributeList*, clang::AccessSpecifier,
clang::ASTMultiPtr<&(clang::ActionBase::DeleteTemplateParams(void*))>, bool&,
bool&) + 3876
6  clang             0x00000001005d6bef
clang::Parser::ParseClassSpecifier(clang::tok::TokenKind,
clang::SourceLocation, clang::DeclSpec&, clang::Parser::ParsedTemplateInfo
const&, clang::AccessSpecifier, bool) + 4705
7  clang             0x00000001005ca1fd
clang::Parser::ParseDeclarationSpecifiers(clang::DeclSpec&,
clang::Parser::ParsedTemplateInfo const&, clang::AccessSpecifier,
clang::Parser::DeclSpecContext) + 6781
8  clang             0x00000001005d4870
clang::Parser::ParseCXXClassMemberDeclaration(clang::AccessSpecifier,
clang::Parser::ParsedTemplateInfo const&) + 1516
9  clang             0x00000001005d57a5
clang::Parser::ParseCXXMemberSpecification(clang::SourceLocation, unsigned int,
clang::OpaquePtr<0>) + 1105
10 clang             0x00000001005d6da3
clang::Parser::ParseClassSpecifier(clang::tok::TokenKind,
clang::SourceLocation, clang::DeclSpec&, clang::Parser::ParsedTemplateInfo
const&, clang::AccessSpecifier, bool) + 5141
11 clang             0x00000001005ca1fd
clang::Parser::ParseDeclarationSpecifiers(clang::DeclSpec&,
clang::Parser::ParsedTemplateInfo const&, clang::AccessSpecifier,
clang::Parser::DeclSpecContext) + 6781
12 clang             0x0000000100608fbe
clang::Parser::ParseDeclarationOrFunctionDefinition(clang::Parser::ParsingDeclSpec&,
clang::AttributeList*, clang::AccessSpecifier) + 118
13 clang             0x00000001006093d1
clang::Parser::ParseDeclarationOrFunctionDefinition(clang::AttributeList*,
clang::AccessSpecifier) + 83
14 clang             0x000000010060b121
clang::Parser::ParseExternalDeclaration(clang::CXX0XAttributeList) + 2213
15 clang             0x000000010060b25f
clang::Parser::ParseTopLevelDecl(clang::OpaquePtr<1>&) + 247
16 clang             0x000000010023b18f clang::ParseAST(clang::Preprocessor&,
clang::ASTConsumer*, clang::ASTContext&, bool, bool,
clang::CodeCompleteConsumer*) + 523
17 clang             0x0000000100060912
clang::ASTFrontendAction::ExecuteAction() + 256
18 clang             0x0000000100060a02 clang::FrontendAction::Execute() + 226
19 clang             0x00000001000454da
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 726
20 clang             0x0000000100025e1c cc1_main(char const**, char const**,
char const*, void*) + 1296
21 clang             0x000000010002a0cd main + 252
22 clang             0x0000000100024df4 start + 52
Stack dump:
0.    Program arguments: /Users/bjoto/pkg/clang+llvm/bin/clang -cc1 -triple
x86_64-apple-darwin10.0.0 -S -disable-free -main-file-name namespace.cc
-pic-level 1 -mdisable-fp-elim -munwind-tables -target-cpu core2 -resource-dir
/Users/bjoto/pkg/clang+llvm/lib/clang/1.1 -fmessage-length 270 -stack-protector
1 -fblocks -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o
/var/folders/Eb/Ebu2gEwcHfeuStO9hJ4SQk+++TI/-Tmp-/cc-oSmG9F.s -x c++
namespace.cc 
1.    namespace.cc:6:24: current parser token ';'
2.    namespace.cc:5:1: parsing struct/union/class body 'Foo::Bar'
clang: error: compiler command failed due to signal 6 (use -v to see
invocation)

-- 
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 llvm.org  Wed Mar 10 06:19:34 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 10 Mar 2010 06:19:34 -0600 (CST)
Subject: [LLVMbugs] [Bug 6570] New: Implicit copy-assignment operator hidden
 by overloaded assignment operator
Message-ID: <bug-6570-206@http.llvm.org/bugs/>

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

           Summary: Implicit copy-assignment operator hidden by overloaded
                    assignment operator
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: ahaczewski at gmail.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


The test case:

class A {
};

class B {
public:
       B() {}

       B(const A& a) {
               operator = (CONST);
               operator = (a);
       }

       B& operator = (const A& a) {
               return *this;
       }

       static const B CONST;
};

And the diagnostics:
t3.cc:13:15: error: no viable conversion from 'class B const' to 'class A
const'
               operator = (CONST);
                           ^~~~~
t3.cc:1:7: note: candidate constructor (the implicit copy constructor)
not viable: no known conversion from 'class B const' to 'class A
const' for 1st argument
class A {
     ^
2 diagnostics generated.

GCC compiles it without problems.

-- 
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 llvm.org  Wed Mar 10 11:30:31 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 10 Mar 2010 11:30:31 -0600 (CST)
Subject: [LLVMbugs] [Bug 6571] New: Crash when turning on RTTI and writing
 your own alias pass using multiple inheritence
Message-ID: <bug-6571-206@http.llvm.org/bugs/>

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

           Summary: Crash when turning on RTTI and writing your own alias
                    pass using multiple inheritence
           Product: new-bugs
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: ddneff at hotmail.com
                CC: llvmbugs at cs.uiuc.edu


I compiled llvm using REQUIRES_RTTI=1 with gcc 4.3.2 on 64 bit linux and
statically linked it into my program.  I have my own alias pass that looks like
this:

class TypeBasedAliasAnalysis 
        : public llvm::ModulePass
        , public llvm::AliasAnalysis
{
    public:
        TypeBasedAliasAnalysis() : ModulePass(&ID) {}
        static char ID;

        virtual void getAnalysisUsage(llvm::AnalysisUsage &AU) const;
        virtual bool runOnModule(llvm::Module& module);

        llvm::AliasAnalysis::AliasResult 
        alias(const llvm::Value *V1, unsigned V1Size,
              const llvm::Value *V2, unsigned V2Size);

        ...
}

It has no other data members and a few other non virtual functions.  When I try
to use this pass, it ends up calling the wrong function when it tries to call
alias in AliasAnalysis::getModRefInfo(StoreInst *s, Value* P, unsigned Size).
It ends up calling the Print function of the raw stream class, and bad things
result.  My other passes that use single inheritence seem to work correctly.

-- 
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 llvm.org  Wed Mar 10 11:50:58 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 10 Mar 2010 11:50:58 -0600 (CST)
Subject: [LLVMbugs] [Bug 6552] [ARM inline asm] Assigning fp to a variable
 results in "Couldn't allocate output reg for constraint '{fp}'!"
In-Reply-To: <bug-6552-206@http.llvm.org/bugs/>
References: <bug-6552-206@http.llvm.org/bugs/>
Message-ID: <20100310175058.8D71A2A6C124@llvm.org>

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

Bob Wilson <bob.wilson at apple.com> changed:

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

--- Comment #4 from Bob Wilson <bob.wilson at apple.com> 2010-03-10 11:50:58 CST ---
This is fixed in llvm-gcc-4.2 svn r98165.

-- 
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 llvm.org  Wed Mar 10 12:21:44 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 10 Mar 2010 12:21:44 -0600 (CST)
Subject: [LLVMbugs] [Bug 6572] New: DAGCombiner.cpp incorrectly calls
 APInt::getLowBitsSet
Message-ID: <bug-6572-206@http.llvm.org/bugs/>

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

           Summary: DAGCombiner.cpp incorrectly calls APInt::getLowBitsSet
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Common Code Generator Code
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: micah.villmow at amd.com
                CC: llvmbugs at cs.uiuc.edu


====
//depot/stg/opencl/drivers/opencl/compiler/llvm/lib/CodeGen/SelectionDAG/DAGCombiner.cpp#19
-
/home/mvillmow/Source/stg/opencl/drivers/opencl/compiler/llvm/lib/CodeGen/SelectionDAG/DAGCombiner.cpp
====
@@ -5344,7 +5344,7 @@
     if (SimplifyDemandedBits(Value,
                              APInt::getLowBitsSet(
                               
Value.getValueType().getScalarType().getSizeInBits(),
-                               ST->getMemoryVT().getSizeInBits())))
+                              
ST->getMemoryVT().getScalarType().getSizeInBits())))
       return SDValue(N, 0);
   }





The problem is that ST->getMemoryVT().getSizeInBits() doesn't match
Value.getValueType().getScalarType().getSizeInBits when ST is a vector.

-- 
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 llvm.org  Wed Mar 10 12:34:00 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 10 Mar 2010 12:34:00 -0600 (CST)
Subject: [LLVMbugs] [Bug 6573] New: msp430 backend: arguments passed in
	wrong registers
Message-ID: <bug-6573-206@http.llvm.org/bugs/>

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

           Summary: msp430 backend: arguments passed in wrong registers
           Product: new-bugs
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Keywords: miscompilation
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: pagariya at cs.utah.edu
                CC: llvmbugs at cs.uiuc.edu, regehr at cs.utah.edu


Test case:

#include <stdint.h>

int8_t g_8[6][10];

int main(void)
{
    int i, j;
    for (i = 0; i < 6; i++)
    {   
        for (j = 0; j < 10; j++)
            g_8[i][j] = 0x44L;
    }
    return 0;
}

Description: 
In the above code g_8 is an array of 6x10 bytes, which is initialized to 0x44.
At -O2 and -O3, this array is initialized using memset().

C interface to memset(): void* memset(void* ptr, int value, size_t num);
Asm interface to memset(): ptr -> reg r15
                           data -> reg r14
                           size -> reg r13

Assembly code at -O2 and -O3 for call to memset():

main:
mov.w #0, r11
.LBB1_1
mov.w r11, r15
add.w #g_8, r15
mov.w #68, r14
mov.w #0, r13   /* size expected here, passed 0 */
mov.w #10, r12  /* Size passed in r12, ignored */
call  #memset
add.w #10, r11
cmp.w #60, r11
jne .LBB1_1
mov.w #0, r15

Bug: size argument to memset() should be passed in register r13. Instead it is
passed in r12.

I am attaching the asm file at -O2. Below are the cmdline options.

pagariya at aleph:~/randprog-testing/main/tmp$ clang -ccc-host-triple msp430-elf
-I/home/pagariya/res-pagariya/llvm-msp430/msp430/include -nostdinc -v -O2 -S
test.c
clang version 1.1 (trunk 184)
Target: msp430-elf-
Thread model: posix
 "/uusoc/facility/res/embed/users/pagariya/llvm-msp430/bin/clang" -cc1 -triple
msp430-elf- -S -disable-free -main-file-name test.c -mrelocation-model static
-mdisable-fp-elim -mconstructor-aliases -v -nostdinc -resource-dir
/uusoc/facility/res/embed/users/pagariya/llvm-msp430/lib/clang/1.1
-I/home/pagariya/res-pagariya/llvm-msp430/msp430/include -O2 -fmessage-length
102 -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o test.s -x c
test.c
clang -cc1 version 1.1 based upon llvm 2.7svn hosted on i386-pc-linux-gnu
#include "..." search starts here:
#include <...> search starts here:
 /home/pagariya/res-pagariya/llvm-msp430/msp430/include
 /uusoc/facility/res/embed/users/pagariya/llvm-msp430/lib/clang/1.1/include
End of search list.

pagariya at aleph:~/randprog-testing/main/tmp$ uname -a
Linux aleph 2.6.24-24-generic #1 SMP Fri Sep 18 16:49:39 UTC 2009 i686
GNU/Linux

-- 
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 llvm.org  Wed Mar 10 12:37:27 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 10 Mar 2010 12:37:27 -0600 (CST)
Subject: [LLVMbugs] [Bug 6574] New: clang silently ignore
	__attribute__((mode(QI)))
Message-ID: <bug-6574-206@http.llvm.org/bugs/>

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

           Summary: clang silently ignore __attribute__((mode(QI)))
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: quickslyver at free.fr
                CC: llvmbugs at cs.uiuc.edu


This attribute say that the integer is 8bits length.

from gcc torture test:

/* { dg-do run } */

extern void abort (void);
extern void exit (int);

#define small   __attribute__((mode(QI))) int
int main()
{
  int x, y = 0x400;

  x = (small) y;                                /* { dg-bogus "ignored" } */
  if (sizeof (small) != sizeof (char))          /* { dg-bogus "ignored" } */
    abort ();
  if (sizeof (x) != sizeof (char) && x == y)
    abort ();
  return 0;
}

generated llvm code without any warning:

$clang tests/run/gcc.dg/20011214-1.c -Wall -c -emit-llvm -o - -O0 | llvm-dis
; ModuleID = '<stdin>'
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-f80:32:32-n8:16:32"
target triple = "i386-pc-linux-gnu"

define i32 @main() nounwind {
entry:
  %retval = alloca i32, align 4                   ; <i32*> [#uses=2]
  %x = alloca i32, align 4                        ; <i32*> [#uses=1]
  %y = alloca i32, align 4                        ; <i32*> [#uses=2]
  store i32 0, i32* %retval
  store i32 1024, i32* %y
  %tmp = load i32* %y                             ; <i32> [#uses=1]
  store i32 %tmp, i32* %x
  call void @abort() noreturn
  unreachable

return:                                           ; No predecessors!
  %0 = load i32* %retval                          ; <i32> [#uses=1]
  ret i32 %0
}

declare void @abort() noreturn

As we can obviously see: the attribute is ignored

-- 
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 llvm.org  Wed Mar 10 14:10:31 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 10 Mar 2010 14:10:31 -0600 (CST)
Subject: [LLVMbugs] [Bug 6575] New: Clang fails to compile member
 initialiser for fields of nested anonymous structs and unions
Message-ID: <bug-6575-206@http.llvm.org/bugs/>

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

           Summary: Clang fails to compile member initialiser for fields
                    of nested anonymous structs and unions
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: oliver at apple.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


Only fails with -Wall strangely, but here is the minimised case:
struct MyClass {
    MyClass() : m_int(0) {}
    union {
        struct {
            int m_int;
        };
    };
};

g++ -Wall ... is fine
clang++ -Wall ... produces:
Assertion failed: (PrevMember && "Member not in member list?!"), function
ActOnMemInitializers, file SemaDeclCXX.cpp, line 1812.
0  clang             0x00000001010413d2 PrintStackTrace(void*) + 34
1  clang             0x0000000101041c5c SignalHandler(int) + 652
2  libSystem.B.dylib 0x00007fff81febeaa _sigtramp + 26
3  libSystem.B.dylib 0xcac9f0b4e90ceeac _sigtramp + 1728983068
4  libSystem.B.dylib 0x00007fff82067e74 __pthread_markcancel + 0
5  clang             0x00000001002fcffe
clang::Sema::ActOnMemInitializers(clang::OpaquePtr<0>, clang::SourceLocation,
void**, unsigned int, bool) + 5022
6  clang             0x000000010062587b
clang::Parser::ParseConstructorInitializer(clang::OpaquePtr<0>) + 491
7  clang             0x000000010060cb1e
clang::Parser::ParseLexedMethodDefs(clang::Parser::ParsingClass&) + 110
8  clang             0x0000000100626da9
clang::Parser::ParseCXXMemberSpecification(clang::SourceLocation, unsigned int,
clang::OpaquePtr<0>) + 1433
9  clang             0x000000010062883c
clang::Parser::ParseClassSpecifier(clang::tok::TokenKind,
clang::SourceLocation, clang::DeclSpec&, clang::Parser::ParsedTemplateInfo
const&, clang::AccessSpecifier, bool) + 5916
10 clang             0x0000000100618e11
clang::Parser::ParseDeclarationSpecifiers(clang::DeclSpec&,
clang::Parser::ParsedTemplateInfo const&, clang::AccessSpecifier,
clang::Parser::DeclSpecContext) + 3937
11 clang             0x0000000100666408
clang::Parser::ParseDeclarationOrFunctionDefinition(clang::Parser::ParsingDeclSpec&,
clang::AttributeList*, clang::AccessSpecifier) + 152
12 clang             0x000000010066684e
clang::Parser::ParseDeclarationOrFunctionDefinition(clang::AttributeList*,
clang::AccessSpecifier) + 350
13 clang             0x000000010066691c
clang::Parser::ParseExternalDeclaration(clang::CXX0XAttributeList) + 76
14 clang             0x0000000100667718
clang::Parser::ParseTopLevelDecl(clang::OpaquePtr<1>&) + 104
15 clang             0x00000001002799cb clang::ParseAST(clang::Preprocessor&,
clang::ASTConsumer*, clang::ASTContext&, bool, bool,
clang::CodeCompleteConsumer*) + 251
16 clang             0x0000000100053bb9
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 393
17 clang             0x0000000100038850 cc1_main(char const**, char const**,
char const*, void*) + 2064
18 clang             0x000000010003b5b7 main + 2247
19 clang             0x0000000100036478 start + 52
20 clang             0x000000000000001e start + 4294745050
Stack dump:
0.    Program arguments: /Users/oliver/llvm/llvm/Release/bin/clang -cc1 -triple
x86_64-apple-darwin10.0.0 -S -disable-free -main-file-name foo.cpp -pic-level 1
-mdisable-fp-elim -munwind-tables -target-cpu core2 -resource-dir
/Users/oliver/llvm/llvm/Release/lib/clang/1.1 -Wall -fmessage-length 132
-stack-protector 1 -fblocks -fexceptions -fdiagnostics-show-option
-fcolor-diagnostics -o
/var/folders/3C/3CRLXCBPEeGMkdDv4V76e++++TI/-Tmp-/cc-kQdJL4.s -x c++ foo.cpp 
1.    foo.cpp:2:26: current parser token '{'
2.    foo.cpp:1:1: parsing struct/union/class body 'MyClass'
clang: error: compiler command failed due to signal 6 (use -v to see
invocation)

-- 
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 llvm.org  Wed Mar 10 14:58:09 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 10 Mar 2010 14:58:09 -0600 (CST)
Subject: [LLVMbugs] [Bug 6571] Crash when turning on RTTI and writing your
 own alias pass using multiple inheritence
In-Reply-To: <bug-6571-206@http.llvm.org/bugs/>
References: <bug-6571-206@http.llvm.org/bugs/>
Message-ID: <20100310205809.28AFA2A6C12C@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #2 from Chris Lattner <clattner at apple.com> 2010-03-10 14:58:08 CST ---
You need to implement the getAdjustedAnalysisPointer method, see
lib/Analysis/BasicAliasAnalysis.cpp

-- 
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 llvm.org  Wed Mar 10 15:06:30 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 10 Mar 2010 15:06:30 -0600 (CST)
Subject: [LLVMbugs] [Bug 6572] DAGCombiner.cpp incorrectly calls
	APInt::getLowBitsSet
In-Reply-To: <bug-6572-206@http.llvm.org/bugs/>
References: <bug-6572-206@http.llvm.org/bugs/>
Message-ID: <20100310210630.460022A6C12C@llvm.org>

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

Dan Gohman <gohman at apple.com> changed:

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

--- Comment #2 from Dan Gohman <gohman at apple.com> 2010-03-10 15:06:30 CST ---
Effective change applied to trunk in 98188.

-- 
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 llvm.org  Wed Mar 10 15:26:11 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 10 Mar 2010 15:26:11 -0600 (CST)
Subject: [LLVMbugs] [Bug 6556] header install doesn't honor DESTDIR
In-Reply-To: <bug-6556-206@http.llvm.org/bugs/>
References: <bug-6556-206@http.llvm.org/bugs/>
Message-ID: <20100310212611.914682A6C12E@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #1 from Chris Lattner <clattner at apple.com> 2010-03-10 15:26:11 CST ---
Applied in r98192, 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 llvm.org  Wed Mar 10 15:28:06 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 10 Mar 2010 15:28:06 -0600 (CST)
Subject: [LLVMbugs] [Bug 6557] toolalias install doesn't honor DESTDIR
In-Reply-To: <bug-6557-206@http.llvm.org/bugs/>
References: <bug-6557-206@http.llvm.org/bugs/>
Message-ID: <20100310212806.343E02A6C12D@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #1 from Chris Lattner <clattner at apple.com> 2010-03-10 15:28:05 CST ---
applied in r98193, 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 llvm.org  Wed Mar 10 15:33:31 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 10 Mar 2010 15:33:31 -0600 (CST)
Subject: [LLVMbugs] [Bug 6576] New: Missed optimisation to remove
 unnecessary branches involving mul
Message-ID: <bug-6576-206@http.llvm.org/bugs/>

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

           Summary: Missed optimisation to remove unnecessary branches
                    involving mul
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Scalar Optimizations
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: arplynn at gmail.com
                CC: llvmbugs at cs.uiuc.edu


The following test case:

define i32 @mul(i32 %a, i32 %b) nounwind readnone {
entry:
  %cond1 = icmp eq i32 %b, 0                      ; <i1> [#uses=1]
  br i1 %cond1, label %exit, label %bb.nph

bb.nph:                                           ; preds = %entry
  %tmp = mul i32 %b, %a                           ; <i32> [#uses=1]
  ret i32 %tmp

exit:                                             ; preds = %entry
  ret i32 0
}

could be reduced to:

define i32 @mul(i32 %a, i32 %b) nounwind readnone {
entry:
  %tmp = mul i32 %b, %a
  ret i32 %tmp
}

-- 
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 llvm.org  Wed Mar 10 15:43:33 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 10 Mar 2010 15:43:33 -0600 (CST)
Subject: [LLVMbugs] [Bug 6576] Missed optimisation to remove unnecessary
 branches involving mul
In-Reply-To: <bug-6576-206@http.llvm.org/bugs/>
References: <bug-6576-206@http.llvm.org/bugs/>
Message-ID: <20100310214333.5AD822A6C12D@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #1 from Chris Lattner <clattner at apple.com> 2010-03-10 15:43:33 CST ---
Moved to the Target independent readme file here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20100308/097618.html

We typically don't track all the microoptimizations in bugzilla.

-- 
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 llvm.org  Wed Mar 10 17:06:24 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 10 Mar 2010 17:06:24 -0600 (CST)
Subject: [LLVMbugs] [Bug 6556] header install doesn't honor DESTDIR
In-Reply-To: <bug-6556-206@http.llvm.org/bugs/>
References: <bug-6556-206@http.llvm.org/bugs/>
Message-ID: <20100310230624.420502A6C12D@llvm.org>

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

Matthias Klose <doko at ubuntu.com> changed:

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

--- Comment #2 from Matthias Klose <doko at ubuntu.com> 2010-03-10 17:06:24 CST ---
reopening, this should be fixed on the 2.7 branch as well (but there's no tag
yet for 2.7). sorry if reopening the report is the wrong procedure to follow.

-- 
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 llvm.org  Wed Mar 10 17:07:09 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 10 Mar 2010 17:07:09 -0600 (CST)
Subject: [LLVMbugs] [Bug 6557] toolalias install doesn't honor DESTDIR
In-Reply-To: <bug-6557-206@http.llvm.org/bugs/>
References: <bug-6557-206@http.llvm.org/bugs/>
Message-ID: <20100310230709.48FD72A6C12C@llvm.org>

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

Matthias Klose <doko at ubuntu.com> changed:

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

--- Comment #2 from Matthias Klose <doko at ubuntu.com> 2010-03-10 17:07:09 CST ---
reopening, this should be fixed on the 2.7 branch as well (but there's no tag
yet for 2.7). sorry if reopening the report is the wrong procedure to follow.

-- 
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 llvm.org  Wed Mar 10 17:20:21 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 10 Mar 2010 17:20:21 -0600 (CST)
Subject: [LLVMbugs] [Bug 6556] header install doesn't honor DESTDIR
In-Reply-To: <bug-6556-206@http.llvm.org/bugs/>
References: <bug-6556-206@http.llvm.org/bugs/>
Message-ID: <20100310232021.289952A6C124@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #3 from Chris Lattner <clattner at apple.com> 2010-03-10 17:20:20 CST ---
I asked for it to get merged into the 2.7 branch, 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 llvm.org  Wed Mar 10 17:20:30 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 10 Mar 2010 17:20:30 -0600 (CST)
Subject: [LLVMbugs] [Bug 6557] toolalias install doesn't honor DESTDIR
In-Reply-To: <bug-6557-206@http.llvm.org/bugs/>
References: <bug-6557-206@http.llvm.org/bugs/>
Message-ID: <20100310232030.8E7612A6C124@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #3 from Chris Lattner <clattner at apple.com> 2010-03-10 17:20:30 CST ---
I asked for it to get merged into the 2.7 branch, 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 llvm.org  Wed Mar 10 17:47:31 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 10 Mar 2010 17:47:31 -0600 (CST)
Subject: [LLVMbugs] [Bug 6533] ice: SetCC type must be 8-bit integer
In-Reply-To: <bug-6533-206@http.llvm.org/bugs/>
References: <bug-6533-206@http.llvm.org/bugs/>
Message-ID: <20100310234731.250512A6C12D@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #3 from Chris Lattner <clattner at apple.com> 2010-03-10 17:47:30 CST ---
Fixed here, thanks!
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20100308/097625.html

I'll ask to get it pulled into 2.7

-- 
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 llvm.org  Wed Mar 10 18:07:28 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 10 Mar 2010 18:07:28 -0600 (CST)
Subject: [LLVMbugs] [Bug 6528] invalid assembly generated with long long on
	i386
In-Reply-To: <bug-6528-206@http.llvm.org/bugs/>
References: <bug-6528-206@http.llvm.org/bugs/>
Message-ID: <20100311000728.393802A6C12C@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |clattner at apple.com
         Resolution|                            |FIXED

--- Comment #7 from Chris Lattner <clattner at apple.com> 2010-03-10 18:07:27 CST ---
This should fix it:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20100308/097628.html

Please verify that it does, and please verify that it doesn't cause any
failures in the regression test suite when run on an openbsd system.  If both
are ok, then we can ask to pull it into 2.7.  Please try to do this in the next
day or so, thanks for reporting it!

-- 
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 llvm.org  Wed Mar 10 21:02:51 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 10 Mar 2010 21:02:51 -0600 (CST)
Subject: [LLVMbugs] [Bug 6577] New: Assertion `Emitted && "Unable to issue a
 copy instruction!\n"'
Message-ID: <bug-6577-206@http.llvm.org/bugs/>

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

           Summary: Assertion `Emitted && "Unable to issue a copy
                    instruction!\n"'
           Product: new-bugs
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: ddneff at hotmail.com
                CC: llvmbugs at cs.uiuc.edu


I am getting an assertion when jitting the code below on x86_64 linux compiled
with gcc 4.3.2.  It looks like one of the registers is GR64 and the other is
FR64.  The instruction looks like a conditional move.  The LLVM assembly passes
through the verifier correctly (at least before I started stripping stuff out
to make it a bit more manageable for the bug).

/lib/CodeGen/SelectionDAG/InstrEmitter.cpp:292: void
llvm::InstrEmitter::AddRegisterOperand(llvm::MachineInstr*, llvm::SDValue,
unsigned int, const llvm::TargetInstrDesc*, llvm::DenseMap<llvm::SDValue,
unsigned int, llvm::DenseMapInfo<llvm::SDValue>, llvm::DenseMapInfo<unsigned
int> >&): Assertion `Emitted && "Unable to issue a copy instruction!\n"'
failed.
Stack dump:
0.      Running pass 'X86 DAG->DAG Instruction Selection' on function '@on4'
Aborted

Here is the llvm assembly, which was stripped down from a significantly larger
program to just the offending function:

; ModuleID = 'Q'

%0 = type { i384, i64, i64, i64, i32, i32, i64, i32, i32, i64, i32, i32, i64,
i32, i32, i64, i32, i32, i64, i32, i32, i64, i32, i32, i64, i32, i32, i64, i32,
i32, i64, i32, i32, i64, i32, i32, i64, i64, i64 }
%1 = type { i64, double }
%2 = type { i64, i64, [2 x double] }
%3 = type { i64, i64, [2 x %1] }
%4 = type { double, double, i1, i1 }
%5 = type { %GEvent, i1, double, %1, i64, i1, i1, i1, i1, i1 }
%6 = type { %GEvent, i1, i1, i64, i1, i1, i1, i1 }
%7 = type opaque
%GEvent = type %0*

@global_subject109_151691824 = internal hidden global %1 zeroinitializer
@global_subMeta_0_153989360 = internal hidden global i1 false
@global_subject159_147021872 = internal hidden global double 0.000000e+00
@global_subMeta_1_153989392 = internal hidden global i1 false
@global_subject167_152731376 = internal hidden global i1 false
@global_subMeta_3_153991696 = internal hidden global i1 false
@global_subject203_153263040 = internal hidden global %2 zeroinitializer
@global_subject207_153163808 = internal hidden global %3 zeroinitializer
@global_subject218_153259872.b = internal global i1 false
@global_subMeta_7_153997040 = internal hidden global i1 false
@global_reflex_ticks = internal hidden global i64 0
@.str = internal constant [6 x i8] c"XXXXX\00"
@.str1 = internal constant [52 x i8]
c"XXXX~XXXXXXXX=XXXX~XXXXXX=XXXX~XXXXXXXX=P~XXXXXX=A\00"
@.str2 = internal constant [52 x i8]
cXXXX~XXXXXXXX=XXXX~XXXXXX=XXXX~XXXXXXXX=P~XXXXXX=A\00"
@.str3 = internal constant [26 x i8] c"XXXXX~XXXXXX=XXX~XXXXXXXX\00"
@.str4 = internal constant [49 x i8]
c"XXXXXX-XXXXX~XXXX=XXXXX~XXX-XXXXX=-X~XXX-XXXXX=X\00"


define void @on4(%GEvent %VALUE_0) {
dependentGraph243.exit:
  %0 = alloca %5, align 8
  %1 = alloca %6, align 8
  %subject34_149825680 = alloca %1, align 8
  store %1 zeroinitializer, %1* %subject34_149825680
  %2 = load i64* @global_reflex_ticks
  %3 = add i64 %2, 1
  store i64 %3, i64* @global_reflex_ticks
  %4 = load i1* @global_subMeta_3_153991696
  %5 = load i1* @global_subject167_152731376
  %6 = call %GEvent @OnMerge(%7* inttoptr (i64 154167792 to %7*), %GEvent
%VALUE_0)
  %MyStatusPtr.i = getelementptr inbounds %GEvent %6, i64 0, i32 2
  %MyStatus.i = load i64* %MyStatusPtr.i
  %NewEvent.i = and i64 %MyStatus.i, 1
  %7 = icmp ne i64 %NewEvent.i, 0
  %subject168_146437360.0 = and i1 %4, %5
  %8 = getelementptr inbounds %6* %1, i64 0, i32 0
  store %GEvent %6, %GEvent* %8
  %9 = getelementptr inbounds %6* %1, i64 0, i32 1
  store i1 %7, i1* %9, align 8
  %10 = getelementptr inbounds %6* %1, i64 0, i32 2
  store i1 true, i1* %10
  %11 = getelementptr inbounds %6* %1, i64 0, i32 3
  store i64 1, i64* %11
  %12 = getelementptr inbounds %6* %1, i64 0, i32 4
  store i1 true, i1* %12, align 8
  %13 = getelementptr inbounds %6* %1, i64 0, i32 5
  store i1 true, i1* %13
  %14 = getelementptr inbounds %6* %1, i64 0, i32 6
  store i1 true, i1* %14, align 2
  %15 = getelementptr inbounds %6* %1, i64 0, i32 7
  store i1 true, i1* %15
  %brmerge.demorgan = and i1 %4, %subject168_146437360.0
  %subject16_153602432.0.i = select i1 %7, %GEvent %6, %GEvent null
  store i1 true, i1* @global_subMeta_7_153997040
  store i1 true, i1* @global_subject218_153259872.b
  br i1 %brmerge.demorgan, label %on170.i, label %on231.i

on170.i:                                          ; preds =
%dependentGraph243.exit
  %16 = call i64 @AbsTimeUSec()
  %17 = sitofp i64 %16 to double
  %18 = fmul double %17, 1.000000e-03
  %19 = fptosi double %18 to i64
  br label %on231.i

on231.i:                                          ; preds = %on170.i,
%dependentGraph243.exit
  %20 = phi i64 [ %19, %on170.i ], [ 0, %dependentGraph243.exit ]
  %subMeta_44_154194224.0.i = phi i1 [ true, %on170.i ], [ false,
%dependentGraph243.exit ]
  br i1 %7, label %on204.i, label %dependentGraph240.exit

on204.i:                                          ; preds = %on231.i
  %MyStatusPtr.i28 = getelementptr inbounds %GEvent %subject16_153602432.0.i,
i64 0, i32 2
  %MyStatus.i29 = load i64* %MyStatusPtr.i28
  %NewEvent.i30 = and i64 %MyStatus.i29, 1
  %21 = icmp ne i64 %NewEvent.i30, 0
  %LastPtr.i = getelementptr inbounds %GEvent %subject16_153602432.0.i, i64 0,
i32 33
  %Last.i = load i64* %LastPtr.i
  %DivisorPtr.i = getelementptr inbounds %GEvent %subject16_153602432.0.i, i64
0, i32 1
  %Divisor.i = load i64* %DivisorPtr.i
  %22 = sitofp i64 %Divisor.i to double
  %23 = sitofp i64 %Last.i to double
  %24 = fdiv double %23, %22
  %25 = call i64 @UptimeUSec()
  %26 = load i64* @global_reflex_ticks
  store i64 %26, i64* getelementptr inbounds (%2* @global_subject203_153263040,
i64 0, i32 1)
  %history_element.i31 = load i64* getelementptr inbounds (%2*
@global_subject203_153263040, i64 0, i32 0)
  %27 = add i64 %history_element.i31, 1
  store i64 %27, i64* getelementptr inbounds (%2* @global_subject203_153263040,
i64 0, i32 0)
  %index.i32 = and i64 %history_element.i31, 1
  %28 = getelementptr %2* @global_subject203_153263040, i64 0, i32 2, i64
%index.i32
  store double %24, double* %28
  %29 = insertvalue %1 undef, i64 %25, 0
  %30 = insertvalue %1 %29, double 0.000000e+00, 1
  br label %dependentGraph240.exit

dependentGraph240.exit:                           ; preds = %on231.i, %on204.i
  %subject25_153661808.0.i = phi i1 [ %21, %on204.i ], [ false, %on231.i ]
  %subMeta_43_154193600.0.i = phi i1 [ true, %on204.i ], [ false, %on231.i ]
  %subject26_153662064.0.i = phi double [ %24, %on204.i ], [ 0.000000e+00,
%on231.i ]
  %subject34_153662224.0.i = phi %1 [ %30, %on204.i ], [ zeroinitializer,
%on231.i ]
  %31 = getelementptr inbounds %5* %0, i64 0, i32 0
  store %GEvent %subject16_153602432.0.i, %GEvent* %31
  %32 = getelementptr inbounds %5* %0, i64 0, i32 1
  store i1 %subject25_153661808.0.i, i1* %32, align 8
  %33 = getelementptr inbounds %5* %0, i64 0, i32 2
  store double %subject26_153662064.0.i, double* %33
  %34 = getelementptr inbounds %5* %0, i64 0, i32 3
  store %1 %subject34_153662224.0.i, %1* %34
  %35 = getelementptr inbounds %5* %0, i64 0, i32 4
  store i64 %20, i64* %35
  %36 = getelementptr inbounds %5* %0, i64 0, i32 5
  store i1 %7, i1* %36, align 8
  %37 = getelementptr inbounds %5* %0, i64 0, i32 6
  store i1 %subMeta_43_154193600.0.i, i1* %37
  %38 = getelementptr inbounds %5* %0, i64 0, i32 7
  store i1 %subMeta_43_154193600.0.i, i1* %38, align 2
  %39 = getelementptr inbounds %5* %0, i64 0, i32 8
  store i1 %subMeta_43_154193600.0.i, i1* %39
  %40 = getelementptr inbounds %5* %0, i64 0, i32 9
  store i1 %subMeta_44_154194224.0.i, i1* %40, align 4
  store %1 %subject34_153662224.0.i, %1* %subject34_149825680
  %41 = load i1* @global_subMeta_1_153989392
  %42 = and i1 %brmerge.demorgan, %41
  %43 = and i1 %subMeta_44_154194224.0.i, %42
  br i1 %43, label %on203, label %on235

on203:                                            ; preds =
%dependentGraph240.exit
  %44 = load double* @global_subject159_147021872
  %45 = fmul double %44, 2.000000e-01
  %reflex_ticks = load i64* @global_reflex_ticks
  call void @output_integer(i8* inttoptr (i64 153975296 to i8*), i64 1, i64
%reflex_ticks, i64 %20)
  %reflex_ticks11 = load i64* @global_reflex_ticks
  call void @output_float(i8* inttoptr (i64 153975056 to i8*), i64 1, i64
%reflex_ticks11, double %45)
  %reflex_ticks12 = load i64* @global_reflex_ticks
  call void @output_flush(i8* inttoptr (i64 153974592 to i8*), i64 1, i64
%reflex_ticks12)
  br label %on235

on235:                                            ; preds =
%dependentGraph240.exit, %on203
  %46 = and i1 %subMeta_43_154193600.0.i, %7
  %47 = and i1 %subMeta_43_154193600.0.i, %46
  %48 = and i1 %subMeta_43_154193600.0.i, %47
  %49 = load i1* @global_subMeta_7_153997040
  %50 = and i1 %49, %48
  br i1 %50, label %hold.i, label %dependentGraph241.exit

hold.i:                                           ; preds = %on235
  %.b = load i1* @global_subject218_153259872.b
  %51 = zext i1 %.b to i64
  %52 = load i64* @global_reflex_ticks
  %history_element = load i64* getelementptr inbounds (%2*
@global_subject203_153263040, i64 0, i32 1)
  %history_element15 = load i64* getelementptr inbounds (%2*
@global_subject203_153263040, i64 0, i32 0)
  %53 = icmp eq i64 %52, %history_element
  %54 = zext i1 %53 to i64
  %55 = sub i64 %history_element15, %51
  %56 = add i64 %55, %54
  %index = and i64 %56, 1
  %57 = getelementptr %2* @global_subject203_153263040, i64 0, i32 2, i64
%index
  %subject = load double* %57
  %history_element16 = load i64* getelementptr inbounds (%3*
@global_subject207_153163808, i64 0, i32 1)
  %history_element17 = load i64* getelementptr inbounds (%3*
@global_subject207_153163808, i64 0, i32 0)
  %58 = icmp eq i64 %52, %history_element16
  %59 = zext i1 %58 to i64
  %60 = sub i64 %history_element17, %51
  %61 = add i64 %60, %59
  %index18 = and i64 %61, 1
  %62 = getelementptr %3* @global_subject207_153163808, i64 0, i32 2, i64
%index18
  %subject19 = load %1* %62
  %q_equal = fcmp oeq double %subject26_153662064.0.i, %subject
  %63 = extractvalue %1 %subject19, 1
  %64 = getelementptr inbounds %1* %subject34_149825680, i64 0, i32 0
  %65 = load i64* %64
  %66 = select i1 %q_equal, i64 0, i64 %65
  %67 = getelementptr inbounds %1* %subject34_149825680, i64 0, i32 1
  %68 = load double* %67
  %69 = select i1 %q_equal, double %63, double %68
  %70 = select i1 %subject25_153661808.0.i, i64 %66, i64 0
  %71 = insertvalue %1 undef, i64 %70, 0
  %72 = select i1 %subject25_153661808.0.i, double %69, double %63
  %73 = insertvalue %1 %71, double %72, 1
  store i1 true, i1* @global_subMeta_0_153989360
  store %1 %73, %1* @global_subject109_151691824
  store i64 %52, i64* getelementptr inbounds (%3* @global_subject207_153163808,
i64 0, i32 1)
  %74 = add i64 %history_element17, 1
  store i64 %74, i64* getelementptr inbounds (%3* @global_subject207_153163808,
i64 0, i32 0)
  %index.i = and i64 %history_element17, 1
  %75 = getelementptr %3* @global_subject207_153163808, i64 0, i32 2, i64
%index.i
  store %1 %73, %1* %75
  ret void

dependentGraph241.exit:                           ; preds = %on235
  ret void
}


declare %GEvent @OnMerge(%7*, %GEvent) nounwind

declare i64 @AbsTimeUSec() nounwind

declare i64 @UptimeUSec() nounwind

declare void @output_integer(i8*, i64, i64, i64) nounwind

declare void @output_float(i8*, i64, i64, double) nounwind

declare void @output_flush(i8*, i64, i64) nounwind

-- 
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 llvm.org  Thu Mar 11 00:18:50 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 11 Mar 2010 00:18:50 -0600 (CST)
Subject: [LLVMbugs] [Bug 6555] 2.7.r97654: Assertion failed: (DataSize ==
 TypeLoc::getFullDataSizeForType(T) && "incorrect data size provided to
 CreateTypeSourceInfo!")
In-Reply-To: <bug-6555-206@http.llvm.org/bugs/>
References: <bug-6555-206@http.llvm.org/bugs/>
Message-ID: <20100311061851.042B62A6C12D@llvm.org>

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

John McCall <rjmccall at apple.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 llvm.org  Thu Mar 11 01:51:20 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 11 Mar 2010 01:51:20 -0600 (CST)
Subject: [LLVMbugs] [Bug 6540] make check fails as ENABLE_SHARED is not set
	at all.
In-Reply-To: <bug-6540-206@http.llvm.org/bugs/>
References: <bug-6540-206@http.llvm.org/bugs/>
Message-ID: <20100311075120.D3D182A6C124@llvm.org>

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

Tobias Grosser <grosser at fim.uni-passau.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |clattner at apple.com,
                   |                            |grosser at fim.uni-passau.de
         Resolution|                            |FIXED

--- Comment #10 from Tobias Grosser <grosser at fim.uni-passau.de> 2010-03-11 01:51:20 CST ---
Committed here. Tanya can you move this to 2.7?

Author: grosser
Date: Wed Mar 10 12:41:59 2010
New Revision: 98171

URL: http://llvm.org/viewvc/llvm-project?rev=98171&view=rev
Log:
Fix make check with cmake/lit

PR6540: Set the newly introduced variables ENABLE_SHARED and
SHLIBPATH_VAR in lit.site.cfg not only in the autoconf build, but also
in a cmake one.

Modified:
    llvm/trunk/test/CMakeLists.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 llvm.org  Thu Mar 11 02:23:10 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 11 Mar 2010 02:23:10 -0600 (CST)
Subject: [LLVMbugs] [Bug 6578] New: clang+ and g++ emits different symbols
Message-ID: <bug-6578-206@http.llvm.org/bugs/>

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

           Summary: clang+ and g++ emits different symbols
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: rdivacky at freebsd.org
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


pes delta$ clang++ -c compatibility.cc > /dev/null && nm compatibility.o | grep
char_traits

.... warnings .....

0000000000000000 W _ZNSt11char_traitsIcE4eqXXERKcS2_
                 U _ZNSt11char_traitsIcE4eqXXERKcS2_3
0000000000000000 T _ZNSt21istreambuf_iteratorXXIcSt11char_traitsIcEEppEv
                 U _ZNSt21istreambuf_iteratorXXIcSt11char_traitsIcEEppEv1
0000000000000012 T _ZNSt21istreambuf_iteratorXXIwSt11char_traitsIwEEppEv
                 U _ZNSt21istreambuf_iteratorXXIwSt11char_traitsIwEEppEv2

pes delta$ g++ -c compatibility.cc > /dev/null && nm compatibility.o | grep
char_traits
0000000000000000 T _X_ZNSt11char_traitsIcE2eqERKcS2_
0000000000000000 T _X_ZNSt19istreambuf_iteratorIcSt11char_traitsIcEEppEv
0000000000000000 T _X_ZNSt19istreambuf_iteratorIwSt11char_traitsIwEEppEv
0000000000000000 W _ZNSt11char_traitsIcE4eqXXERKcS2_
0000000000000000 W _ZNSt21istreambuf_iteratorXXIcSt11char_traitsIcEEppEv
0000000000000000 W _ZNSt21istreambuf_iteratorXXIwSt11char_traitsIwEEppEv

-- 
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 llvm.org  Thu Mar 11 03:18:56 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 11 Mar 2010 03:18:56 -0600 (CST)
Subject: [LLVMbugs] [Bug 5255] clang missing builtins
In-Reply-To: <bug-5255-206@http.llvm.org/bugs/>
References: <bug-5255-206@http.llvm.org/bugs/>
Message-ID: <20100311091856.7A74D2A6C12D@llvm.org>

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

John McCall <rjmccall at apple.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 llvm.org  Thu Mar 11 04:31:04 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 11 Mar 2010 04:31:04 -0600 (CST)
Subject: [LLVMbugs] [Bug 6579] New: Using clang++ as linker does not feed
 symbols to c++filt...
Message-ID: <bug-6579-206@http.llvm.org/bugs/>

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

           Summary: Using clang++ as linker does not feed symbols to
                    c++filt...
           Product: clang
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: Fons.Rademakers at cern.ch
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


Example:

clang++ -v -g -m64 -o cint/cint/main/cint_tmp cint/cint/main/cppmain.o \
cint/cint/src/g__cfunc.o cint/cint/main/G__setup.o cint/cint/src/Api.o
cint/cint/src/BaseCls.o cint/cint/src/CallFunc.o cint/cint/src/Class.o
cint/cint/src/DataMbr.o cint/cint/src/FastAllocString.o cint/cint/src/Method.o
cint/cint/src/MethodAr.o cint/cint/src/Shadow.o cint/cint/src/Token.o
cint/cint/src/Type.o cint/cint/src/Typedf.o cint/cint/src/auxu.o
cint/cint/src/bc_assign.o cint/cint/src/bc_autoobj.o cint/cint/src/bc_cfunc.o
cint/cint/src/bc_debug.o cint/cint/src/bc_eh.o cint/cint/src/bc_exec.o
cint/cint/src/bc_inst.o cint/cint/src/bc_item.o cint/cint/src/bc_parse.o
cint/cint/src/bc_reader.o cint/cint/src/bc_type.o cint/cint/src/bc_vtbl.o
cint/cint/src/cast.o cint/cint/src/debug.o cint/cint/src/decl.o
cint/cint/src/disp.o cint/cint/src/dump.o cint/cint/src/end.o
cint/cint/src/error.o cint/cint/src/expr.o cint/cint/src/fread.o
cint/cint/src/func.o cint/cint/src/gcoll.o cint/cint/src/global1.o
cint/cint/src/global2.o cint/cint/src/ifunc.o cint/cint/src/inherit.o
cint/cint/src/init.o cint/cint/src/input.o cint/cint/src/intrpt.o
cint/cint/src/loadfile_tmp.o cint/cint/src/macro.o cint/cint/src/malloc.o
cint/cint/src/memtest.o cint/cint/src/new.o cint/cint/src/newlink.o
cint/cint/src/oldlink.o cint/cint/src/opr.o cint/cint/src/parse.o
cint/cint/src/pause.o cint/cint/src/pcode.o cint/cint/src/pragma.o
cint/cint/src/quote.o cint/cint/src/random.o cint/cint/src/rflx_gendict.o
cint/cint/src/rflx_gensrc.o cint/cint/src/rflx_tools.o cint/cint/src/scrupto.o
cint/cint/src/shl.o cint/cint/src/sizeof.o cint/cint/src/struct.o
cint/cint/src/stub.o cint/cint/src/tmplt.o cint/cint/src/typedef.o
cint/cint/src/val2a.o cint/cint/src/value.o cint/cint/src/var.o
cint/cint/src/dict/Apiif.o cint/cint/src/dict/stdstrct.o
cint/cint/src/dict/gcc4strm.o cint/cint/src/dict/longif3.o -lm
-Wl,-rpath, at loader_path/../lib   -ldl

gives:

Undefined symbols:
  "__ZTV12G__srcreaderI10G__fstreamE", referenced from:
      __ZN12G__srcreaderI10G__fstreamEC2Ev in bc_cfunc.o
ld: symbol(s) not found
clang: error: linker command failed with exit code 1 (use -v to see invocation)

The same with g++ gives:

Undefined symbols:
  "vtable for G__srcreader<G__fstream>", referenced from:
      G__srcreader<G__fstream>::G__srcreader()in bc_cfunc.o
ld: symbol(s) not found
collect2: ld returned 1 exit status

Notice clang++ uses:

/usr/libexec/gcc/i686-apple-darwin10/4.2.1/ld

while g++ uses:

/usr/libexec/gcc/i686-apple-darwin10/4.2.1/collect2 


Cheers, Fons.

-- 
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 llvm.org  Thu Mar 11 06:57:38 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 11 Mar 2010 06:57:38 -0600 (CST)
Subject: [LLVMbugs] [Bug 6580] New: lli JIT fails to resolve cbe mangled
 method names containing . and :
Message-ID: <bug-6580-206@http.llvm.org/bugs/>

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

           Summary: lli JIT fails to resolve cbe mangled method names
                    containing . and :
           Product: new-bugs
           Version: trunk
          Platform: Other
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: xerxes at zafena.se
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=4477)
 --> (http://llvm.org/bugs/attachment.cgi?id=4477)
bugpoint.safe.ll

testcase:
llvm-as bugpoint.safe.ll
llvm-as bugpoint.test.ll
llc -march=c bugpoint.safe.bc -o temporary.c
gcc -xc temporary.c -O2 -o ./bugpoint.safe.bc.cbe.c.so -fPIC -shared
-fno-strict-aliasing
echo "running lli with jit calling functions in bugpoint.safe.bc.cbe.c.so"
lli -load ./bugpoint.safe.bc.cbe.c.so < bugpoint.test.bc

output:
running lli with jit calling functions in bugpoint.safe.bc.cbe.c.so
LLVM ERROR: Program used external function '.' which could not be resolved!

possitive test to make sure the llvm ir for the testcase are correct:
echo "running using only lli with jit"
cat bugpoint.safe.ll > combined.ll
cat bugpoint.test.ll >> combined.ll
llvm-as combined.ll
lli < combined.bc

expected output:
running using only lli with jit
Hello Works
Hello Works
Hello Works
Hello Works

-- 
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 llvm.org  Thu Mar 11 08:08:52 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 11 Mar 2010 08:08:52 -0600 (CST)
Subject: [LLVMbugs] [Bug 6460] Codegen aborts (mangler)
In-Reply-To: <bug-6460-206@http.llvm.org/bugs/>
References: <bug-6460-206@http.llvm.org/bugs/>
Message-ID: <20100311140852.A2F992A6C12E@llvm.org>

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

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

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

--- Comment #12 from Rafael ?vila de Esp?ndola <rafael.espindola at gmail.com> 2010-03-11 08:08:52 CST ---
Fixed in r98254

-- 
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 llvm.org  Thu Mar 11 09:02:18 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 11 Mar 2010 09:02:18 -0600 (CST)
Subject: [LLVMbugs] [Bug 6581] New: Jump table entries emitted twice
Message-ID: <bug-6581-206@http.llvm.org/bugs/>

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

           Summary: Jump table entries emitted twice
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: ARM
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: richard at xmos.com
                CC: llvmbugs at cs.uiuc.edu


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

Compiling the attached example using llc -march=arm results in the jump table
entries being emitted twice, once inside the function just after the jump and
again after the function. The jump table entries emitted at the end of the jump
are unreferenced.

The ARM backend should be switched over to using the new EK_Inline jump table
encoding type which indicates the jump table entries at emitted by the target
inside the function. This disables emission of the jump table entries after the
function.

Also see http://lists.cs.uiuc.edu/pipermail/llvmdev/2010-March/030111.html

Once this is done I think it should be possible to get rid of the
TargetJITInfo::hasCustomJumpTables() hook

-- 
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 llvm.org  Thu Mar 11 10:59:34 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 11 Mar 2010 10:59:34 -0600 (CST)
Subject: [LLVMbugs] [Bug 6582] New: lit test emits .ll file to working dir
Message-ID: <bug-6582-206@http.llvm.org/bugs/>

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

           Summary: lit test emits .ll file to working dir
           Product: clang
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: mikem.llvm at gmail.com
                CC: llvmbugs at cs.uiuc.edu


lit test/CodeGenCXX/PR6474.cpp emits .ll file to working dir.

-- 
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 llvm.org  Thu Mar 11 11:09:17 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 11 Mar 2010 11:09:17 -0600 (CST)
Subject: [LLVMbugs] [Bug 6583] New: Missing symbol in binary causes
 undefined symbol error during linking...
Message-ID: <bug-6583-206@http.llvm.org/bugs/>

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

           Summary: Missing symbol in binary causes undefined symbol error
                    during linking...
           Product: clang
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: Fons.Rademakers at cern.ch
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


Created an attachment (id=4482)
 --> (http://llvm.org/bugs/attachment.cgi?id=4482)
Source file exhibiting the problem

To see this behaviour do:

$ clang++ -c aap.cxx
$ nm aap.o |c++filt |grep G__srcreader

0000000000008006 S G__srcreader<G__fstream>::G__srcreader()
000000000000fb60 S __ZN12G__srcreaderI10G__fstreamEC1Ev.eh
000000000000ca22 S G__srcreader<G__fstream>::G__srcreader()
0000000000013750 S __ZN12G__srcreaderI10G__fstreamEC2Ev.eh
                 U vtable for G__srcreader<G__fstream>

The result with g++ is:

$ g++ -c aap.cxx
$ nm aap.o |c++filt |grep G__srcreader

0000000000009244 S G__srcreader<G__fstream>::fgetstream(std::basic_string<char,
std::char_traits<char>, std::allocator<char> >&, std::basic_string<char,
std::char_traits<char>, std::allocator<char> > const&, int)
000000000000eef8 S __ZN12G__srcreaderI10G__fstreamE10fgetstreamERSsRKSsi.eh
00000000000090e4 S
G__srcreader<G__fstream>::fgetstream_(std::basic_string<char,
std::char_traits<char>, std::allocator<char> >&, std::basic_string<char,
std::char_traits<char>, std::allocator<char> > const&, int)
000000000000ee18 S __ZN12G__srcreaderI10G__fstreamE11fgetstream_ERSsRKSsi.eh
0000000000008de6 S G__srcreader<G__fstream>::fignoreline()
000000000000ed00 S __ZN12G__srcreaderI10G__fstreamE11fignorelineEv.eh
00000000000094d6 S G__srcreader<G__fstream>::fpp_command(int)
000000000000f010 S __ZN12G__srcreaderI10G__fstreamE11fpp_commandEi.eh
000000000000927e S
G__srcreader<G__fstream>::fappendtoken(std::basic_string<char,
std::char_traits<char>, std::allocator<char> >&, int, std::basic_string<char,
std::char_traits<char>, std::allocator<char> > const&)
000000000000ef30 S __ZN12G__srcreaderI10G__fstreamE12fappendtokenERSsiRKSs.eh
0000000000006a4e S G__srcreader<G__fstream>::fskipcomment(int)
000000000000d4e8 S __ZN12G__srcreaderI10G__fstreamE12fskipcommentEi.eh
0000000000008dd2 S G__srcreader<G__fstream>::skipCcomment()
000000000000ecc8 S __ZN12G__srcreaderI10G__fstreamE12skipCcommentEv.eh
0000000000009332 S
G__srcreader<G__fstream>::fgetquotation(std::basic_string<char,
std::char_traits<char>, std::allocator<char> >&, int, int)
000000000000efa0 S __ZN12G__srcreaderI10G__fstreamE13fgetquotationERSsii.eh
0000000000009194 S
G__srcreader<G__fstream>::fignorestream(std::basic_string<char,
std::char_traits<char>, std::allocator<char> > const&, int)
000000000000ee88 S __ZN12G__srcreaderI10G__fstreamE13fignorestreamERKSsi.eh
0000000000006a10 S G__srcreader<G__fstream>::fgetc_gettoken()
000000000000d4b0 S __ZN12G__srcreaderI10G__fstreamE14fgetc_gettokenEv.eh
0000000000009034 S
G__srcreader<G__fstream>::fignorestream_(std::basic_string<char,
std::char_traits<char>, std::allocator<char> > const&, int)
000000000000eda8 S __ZN12G__srcreaderI10G__fstreamE14fignorestream_ERKSsi.eh
0000000000008dfa S
G__srcreader<G__fstream>::fgetstream_core(std::basic_string<char,
std::char_traits<char>, std::allocator<char> >&, std::basic_string<char,
std::char_traits<char>, std::allocator<char> > const&, int, int, int)
000000000000ed38 S
__ZN12G__srcreaderI10G__fstreamE15fgetstream_coreERSsRKSsiii.eh
000000000000920a S
G__srcreader<G__fstream>::fgetstream_template(std::basic_string<char,
std::char_traits<char>, std::allocator<char> >&, std::basic_string<char,
std::char_traits<char>, std::allocator<char> > const&, int)
000000000000eec0 S
__ZN12G__srcreaderI10G__fstreamE19fgetstream_templateERSsRKSsi.eh
00000000000090aa S
G__srcreader<G__fstream>::fgetstream_template_(std::basic_string<char,
std::char_traits<char>, std::allocator<char> >&, std::basic_string<char,
std::char_traits<char>, std::allocator<char> > const&, int)
000000000000ede0 S
__ZN12G__srcreaderI10G__fstreamE20fgetstream_template_ERSsRKSsi.eh
000000000000911e S
G__srcreader<G__fstream>::fignorestream_template(std::basic_string<char,
std::char_traits<char>, std::allocator<char> > const&, int)
000000000000ee50 S
__ZN12G__srcreaderI10G__fstreamE22fignorestream_templateERKSsi.eh
0000000000008fbe S
G__srcreader<G__fstream>::fignorestream_template_(std::basic_string<char,
std::char_traits<char>, std::allocator<char> > const&, int)
000000000000ed70 S
__ZN12G__srcreaderI10G__fstreamE23fignorestream_template_ERKSsi.eh
00000000000069ec S G__srcreader<G__fstream>::Init(char const*)
000000000000d478 S __ZN12G__srcreaderI10G__fstreamE4InitEPKc.eh
00000000000099b8 S G__srcreader<G__fstream>::Init(G__input_file&)
000000000000f198 S __ZN12G__srcreaderI10G__fstreamE4InitER13G__input_file.eh
000000000000999c S G__srcreader<G__fstream>::fgetc()
000000000000f160 S __ZN12G__srcreaderI10G__fstreamE5fgetcEv.eh
0000000000006b34 S G__srcreader<G__fstream>::getpos()
000000000000d520 S __ZN12G__srcreaderI10G__fstreamE6getposEv.eh
0000000000008d40 S G__srcreader<G__fstream>::setpos(long long)
000000000000eb40 S __ZN12G__srcreaderI10G__fstreamE6setposEx.eh
0000000000008db2 S G__srcreader<G__fstream>::putback()
000000000000ec90 S __ZN12G__srcreaderI10G__fstreamE7putbackEv.eh
0000000000006b50 S G__srcreader<G__fstream>::setspos(unsigned long)
000000000000d558 S __ZN12G__srcreaderI10G__fstreamE7setsposEm.eh
0000000000008d64 S G__srcreader<G__fstream>::storepos(int)
000000000000ebb0 S __ZN12G__srcreaderI10G__fstreamE8storeposEi.eh
000000000000931e S G__srcreader<G__fstream>::fgetspace()
000000000000ef68 S __ZN12G__srcreaderI10G__fstreamE9fgetspaceEv.eh
0000000000009700 S G__srcreader<G__fstream>::fgettoken(std::basic_string<char,
std::char_traits<char>, std::allocator<char> >&, std::basic_string<char,
std::char_traits<char>, std::allocator<char> > const&)
000000000000f0f0 S __ZN12G__srcreaderI10G__fstreamE9fgettokenERSsRKSs.eh
0000000000008cfa S G__srcreader<G__fstream>::rewindpos()
000000000000ead0 S __ZN12G__srcreaderI10G__fstreamE9rewindposEv.eh
0000000000005758 S G__srcreader<G__fstream>::G__srcreader()
000000000000b388 S __ZN12G__srcreaderI10G__fstreamEC1Ev.eh
00000000000075fc S G__srcreader<G__fstream>::~G__srcreader()
000000000000dec8 S __ZN12G__srcreaderI10G__fstreamED0Ev.eh
000000000000762e S G__srcreader<G__fstream>::~G__srcreader()
000000000000df00 S __ZN12G__srcreaderI10G__fstreamED1Ev.eh
000000000000ac50 S typeinfo for G__srcreader<G__fstream>
000000000000ada6 S typeinfo name for G__srcreader<G__fstream>
000000000000ab60 S vtable for G__srcreader<G__fstream>

For clang++ this symbol is undefined:

                 U vtable for G__srcreader<G__fstream>

Cheers, Fons.

-- 
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 llvm.org  Thu Mar 11 12:20:26 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 11 Mar 2010 12:20:26 -0600 (CST)
Subject: [LLVMbugs] [Bug 6433] x86_64 va_arg codegen asserts on typedef'd
 floating point types
In-Reply-To: <bug-6433-206@http.llvm.org/bugs/>
References: <bug-6433-206@http.llvm.org/bugs/>
Message-ID: <20100311182026.49BF22A6C12F@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #3 from Chris Lattner <clattner at apple.com> 2010-03-11 12:20:25 CST ---
Fixed here, I'll ask Tanya to pull it into 2.7:
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20100308/028349.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 llvm.org  Thu Mar 11 13:34:19 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 11 Mar 2010 13:34:19 -0600 (CST)
Subject: [LLVMbugs] [Bug 4808] Missing warning for unspecified fields in
 struct initializations
In-Reply-To: <bug-4808-206@http.llvm.org/bugs/>
References: <bug-4808-206@http.llvm.org/bugs/>
Message-ID: <20100311193419.BD0972A6C12F@llvm.org>

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

John McCall <rjmccall at apple.com> changed:

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

--- Comment #7 from John McCall <rjmccall at apple.com> 2010-03-11 13:34:19 CST ---
Committed in r98275, 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 llvm.org  Thu Mar 11 13:43:38 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 11 Mar 2010 13:43:38 -0600 (CST)
Subject: [LLVMbugs] [Bug 4807] Missing warning for comparing unsigned value
 against < 0 or >= 0
In-Reply-To: <bug-4807-206@http.llvm.org/bugs/>
References: <bug-4807-206@http.llvm.org/bugs/>
Message-ID: <20100311194338.CCF7D2A6C130@llvm.org>

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

John McCall <rjmccall at apple.com> changed:

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

--- Comment #5 from John McCall <rjmccall at apple.com> 2010-03-11 13:43:38 CST ---
Committed in r98279, 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 llvm.org  Thu Mar 11 13:59:01 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 11 Mar 2010 13:59:01 -0600 (CST)
Subject: [LLVMbugs] [Bug 6582] lit test emits .ll file to working dir
In-Reply-To: <bug-6582-206@http.llvm.org/bugs/>
References: <bug-6582-206@http.llvm.org/bugs/>
Message-ID: <20100311195901.4939E2A6C12D@llvm.org>

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

mikem.llvm at gmail.com changed:

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

--- Comment #2 from mikem.llvm at gmail.com 2010-03-11 13:59:01 CST ---
Committed in r98267. Thank you.

-- 
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 llvm.org  Thu Mar 11 18:44:30 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 11 Mar 2010 18:44:30 -0600 (CST)
Subject: [LLVMbugs] [Bug 6584] New: -msse3 does not define __SSE3__
Message-ID: <bug-6584-206@http.llvm.org/bugs/>

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

           Summary: -msse3 does not define __SSE3__
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Driver
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: m at fritschy.de
                CC: llvmbugs at cs.uiuc.edu


When using -msse3 the macro __SSE3__ is not defined which triggers an error in
pmmintrin.h:

---------------------------------
% cat > sse3.c
#include <pmmintrin.h>
int main(){}
% clang -msse3 sse3.c
In file included from sse3.c:1:
/home/m/software/llvm/lib/clang/1.1/include/pmmintrin.h:28:2: error: #error
"SSE3 instruction set not enabled"
#error "SSE3 instruction set not enabled"
 ^
1 diagnostic generated.
---------------------------------

It does however work when using -msse4.

Cheers,
Marcus

-- 
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 llvm.org  Thu Mar 11 21:23:02 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 11 Mar 2010 21:23:02 -0600 (CST)
Subject: [LLVMbugs] [Bug 6585] New: ambiguous expression is parsed as
 functional cast when in BinaryOperator (Comma)
Message-ID: <bug-6585-206@http.llvm.org/bugs/>

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

           Summary: ambiguous expression is parsed as functional cast when
                    in BinaryOperator (Comma)
           Product: clang
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: mikem.llvm at gmail.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


Created an attachment (id=4485)
 --> (http://llvm.org/bugs/attachment.cgi?id=4485)
reduction: foo.cpp

The attached code fails to compile with g++:

foo.cpp: In function ?void foo()?:
foo.cpp:4: error: variable or field ?a? declared void
foo.cpp:4: error: expected unqualified-id before ?++? token

But does compile with clang++:

foo.cpp:4:10: warning: expression result unused [-Wunused-value]
    void(a),++a;
         ^
1 diagnostic generated.

-- 
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 llvm.org  Thu Mar 11 23:03:05 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 11 Mar 2010 23:03:05 -0600 (CST)
Subject: [LLVMbugs] [Bug 6578] Explicit template instantiations should have
	weak linkage
In-Reply-To: <bug-6578-206@http.llvm.org/bugs/>
References: <bug-6578-206@http.llvm.org/bugs/>
Message-ID: <20100312050305.615FE2A6C12F@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #3 from Douglas Gregor <dgregor at apple.com> 2010-03-11 23:03:05 CST ---
Fixed in r98328.

-- 
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 llvm.org  Thu Mar 11 23:15:54 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 11 Mar 2010 23:15:54 -0600 (CST)
Subject: [LLVMbugs] [Bug 6578] Explicit template instantiations should have
	weak linkage
In-Reply-To: <bug-6578-206@http.llvm.org/bugs/>
References: <bug-6578-206@http.llvm.org/bugs/>
Message-ID: <20100312051554.72DDF2A6C12F@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #4 from Douglas Gregor <dgregor at apple.com> 2010-03-11 23:15:54 CST ---
My patch broke bootstrap. 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 llvm.org  Thu Mar 11 23:26:10 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 11 Mar 2010 23:26:10 -0600 (CST)
Subject: [LLVMbugs] [Bug 6586] New: 2.7 Master Bug
Message-ID: <bug-6586-206@http.llvm.org/bugs/>

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

           Summary: 2.7 Master Bug
           Product: new-bugs
           Version: unspecified
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: release blocker
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: tonic at nondot.org
                CC: llvmbugs at cs.uiuc.edu


All bugs blocking the 2.7 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 llvm.org  Fri Mar 12 01:11:43 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 12 Mar 2010 01:11:43 -0600 (CST)
Subject: [LLVMbugs] [Bug 4806] Missing warning for unused expression results
	with commas
In-Reply-To: <bug-4806-206@http.llvm.org/bugs/>
References: <bug-4806-206@http.llvm.org/bugs/>
Message-ID: <20100312071143.2A68D2A6C12F@llvm.org>

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

John McCall <rjmccall at apple.com> changed:

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

--- Comment #4 from John McCall <rjmccall at apple.com> 2010-03-12 01:11:42 CST ---
"void(a), ++a;" is valid and clang is right to accept it.  I think you're
right, we shouldn't warn about it here;  I see no reason not to treat a
functional cast the same as a C-style cast in terms of suppressing unused-value
warnings.

Committed in r98335.

-- 
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 llvm.org  Fri Mar 12 01:16:38 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 12 Mar 2010 01:16:38 -0600 (CST)
Subject: [LLVMbugs] [Bug 6577] Assertion `Emitted && "Unable to issue a copy
 instruction!\n"'
In-Reply-To: <bug-6577-206@http.llvm.org/bugs/>
References: <bug-6577-206@http.llvm.org/bugs/>
Message-ID: <20100312071638.BF2A92A6C12E@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #5 from Chris Lattner <clattner at apple.com> 2010-03-12 01:16:38 CST ---
Fixed here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20100308/097698.html

I will ask for this to be pulled into 2.7, 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 llvm.org  Fri Mar 12 03:27:29 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 12 Mar 2010 03:27:29 -0600 (CST)
Subject: [LLVMbugs] [Bug 6587] New: llvm-gcc fails to compile clang-emitted
 .secrel32 assembly directives
Message-ID: <bug-6587-206@http.llvm.org/bugs/>

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

           Summary: llvm-gcc fails to compile clang-emitted .secrel32
                    assembly directives
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: normal
          Priority: P
         Component: LLVM Codegen
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: A.Mazur at adbglobal.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=4487)
 --> (http://llvm.org/bugs/attachment.cgi?id=4487)
Patch for DwarfPrinter (fixes the issue)

Using LLVM+clang from trunk on a Win32 platform, clang generates assembly file
(with no errors/warnings) which contains .secrel32 directives not in separate
lines, but along with other directives.
This leads to a compilation error with released llvm-gcc-4.2 and MinGW GCC
3.4.5:
> Assembler messages:
> Error: junk at end of line, first unrecognized character is `.'

clang -v output:

"C:/projekty/llvm/llvm/bin/Release/clang.exe" -cc1 -triple i686-pc-win32 -S
-disable-free -disable-llvm-verifier -main-file-name <filename.c>
-mrelocation-model static -mdisable-fp-elim -mconstructor-aliases -v -g
-resource-dir C:/projekty/llvm/llvm/bin/lib/clang/1.1 -dependency-file
<dependency_file_location> -MT <o_file_location> <serveral_-D_definitions>
<several_-I_paths> -O0 -Wall -Wno-unused-value -fmessage-length 0
-fms-extensions -fgnu-runtime -fdiagnostics-show-option -o
C:/DOCUME~1/A8BA4~1.MAZ/LOCALS~1/Temp/cc-000000.s -x c <filename.c>
clang -cc1 version 1.1 based upon llvm 2.7svn hosted on i686-pc-win32

llvm-gcc -v output:

"C:/Program Files/llvm-gcc-4.2/bin/llvm-gcc.exe" -Wall -Wno-unused-value -O0
-fno-strict-aliasing -g -v -fno-strict-aliasing<serveral_-D_definitions>
<several_-I_paths> -MMD -c -o <o_file_location> -x assembler
C:/DOCUME~1/A8BA4~1.MAZ/LOCALS~1/Temp/cc-000000.s
Using built-in specs.
Target: i386-mingw32
Configured with: ../src/configure --build=i386-mingw32 --host=i386-mingw32
--tar
get=i386-mingw32 --disable-shared --disable-bootstrap --disable-nls
--with-arch=
i486 --with-cpu=generic --prefix=c:/proj/llvm/llvm-gcc-4.2/install
--enable-llvm
=c:/proj/llvm/build --disable-win32-registry --enable-languages=c,c++
--program-
prefix=llvm- --disable-sjlj-exceptions
Thread model: win32
gcc version 4.2.1 (Based on Apple Inc. build 5649) (LLVM build)
 as --gstabs -o <o_file_location>
C:/DOCUME~1/A8BA4~1.MAZ/LOCALS~1/Temp/cc-000000.s

as --version output:

GNU assembler (GNU Binutils) 2.20
Copyright 2009 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or later.
This program has absolutely no warranty.
This assembler was configured for a target of `mingw32'.

-- 
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 llvm.org  Fri Mar 12 04:20:29 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 12 Mar 2010 04:20:29 -0600 (CST)
Subject: [LLVMbugs] [Bug 6584] -msse3 does not define __SSE3__
In-Reply-To: <bug-6584-206@http.llvm.org/bugs/>
References: <bug-6584-206@http.llvm.org/bugs/>
Message-ID: <20100312102029.8DFBC2A6C12E@llvm.org>

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

Nuno Lopes <nunoplopes at sapo.pt> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |nunoplopes at sapo.pt
         Resolution|                            |FIXED

--- Comment #1 from Nuno Lopes <nunoplopes at sapo.pt> 2010-03-12 04:20:29 CST ---
fixed in r98342.

-- 
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 llvm.org  Fri Mar 12 05:26:40 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 12 Mar 2010 05:26:40 -0600 (CST)
Subject: [LLVMbugs] [Bug 6588] New: Assertion `RegNo && RegNo < 159 &&
 "Invalid register number!"' failed.
Message-ID: <bug-6588-206@http.llvm.org/bugs/>

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

           Summary: Assertion `RegNo && RegNo < 159 && "Invalid register
                    number!"' failed.
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: X86
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: mail at exoticorn.de
                CC: llvmbugs at cs.uiuc.edu


Compiling the attached linked.bc with llc -O0 from trunk failes with the
following assertion:

dranke at dranke-eee:~/coding/racer/tools/editor$ ~/coding/llvm/Release/bin/llc
-O0 build/debug/linked.bc
llc:
/home/dranke/coding/llvm/lib/Target/X86/AsmPrinter/../X86GenAsmWriter.inc:3262:
static const char* llvm::X86ATTInstPrinter::getRegisterName(unsigned int):
Assertion `RegNo && RegNo < 159 && "Invalid register number!"' failed.
0  llc 0x08915298
Stack dump:
0.    Program arguments: /home/dranke/coding/llvm/Release/bin/llc -O0
build/debug/linked.bc 
1.    Running pass 'X86 AT&T-Style Assembly Printer' on function
'@_ZN8QPainter9drawImageEiiRK6QImageiiii6QFlagsIN2Qt19ImageConversionFlagEE'
Aborted (core dumped)

I build llvm/llc from:
URL: http://llvm.org/svn/llvm-project/llvm/trunk
Repository Root: http://llvm.org/svn/llvm-project
Repository UUID: 91177308-0d34-0410-b5e6-96231b3b80d8
Revision: 98339

-- 
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 llvm.org  Fri Mar 12 05:46:39 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 12 Mar 2010 05:46:39 -0600 (CST)
Subject: [LLVMbugs] [Bug 6522] clang emits U symbol for builtin_copysignl
 while gcc does not
In-Reply-To: <bug-6522-206@http.llvm.org/bugs/>
References: <bug-6522-206@http.llvm.org/bugs/>
Message-ID: <20100312114639.3FB8D2A6C124@llvm.org>

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

Duncan Sands <baldrick at free.fr> changed:

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

--- Comment #26 from Duncan Sands <baldrick at free.fr> 2010-03-12 05:46:38 CST ---
Fixed here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20100308/097700.html
It wasn't clear how to do a testcase, so I'm leaving that to the FreeBSD guys.

-- 
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 llvm.org  Fri Mar 12 06:01:33 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 12 Mar 2010 06:01:33 -0600 (CST)
Subject: [LLVMbugs] [Bug 6589] New: ReturnInst::op_iterator behave bad when
	#operands=0
Message-ID: <bug-6589-206@http.llvm.org/bugs/>

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

           Summary: ReturnInst::op_iterator behave bad when #operands=0
           Product: new-bugs
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: martin at lumai.se
                CC: llvmbugs at cs.uiuc.edu


The ReturnInst at the end of a void function reports 0 from getNumOperands(),
but gives iterators where op_begin() != op_end().

The iterators does behave correctly when getNumOperands() == 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 llvm.org  Fri Mar 12 06:37:42 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 12 Mar 2010 06:37:42 -0600 (CST)
Subject: [LLVMbugs] [Bug 6590] New: test/CodeGen/X86/bswap-inline-asm.ll
 fails on FreeBSD 9.0-CURRENT
Message-ID: <bug-6590-206@http.llvm.org/bugs/>

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

           Summary: test/CodeGen/X86/bswap-inline-asm.ll fails on FreeBSD
                    9.0-CURRENT
           Product: new-bugs
           Version: unspecified
          Platform: PC
               URL: http://https://wwws.clamav.net/bugzilla/show_bug.cgi?i
                    d=1879#c2
        OS/Version: FreeBSD
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: edwintorok at gmail.com
                CC: llvmbugs at cs.uiuc.edu


On FreeBSD 9.0-CURRENT LLVM fails 1 test, see the ClamAV bugreport in the URL.
The failure is reproducible on upstream LLVM:

******************** TEST 'LLVM :: CodeGen/X86/bswap-inline-asm.ll' FAILED
********************
Script:
--
llc < /home/garga/llvm/test/CodeGen/X86/bswap-inline-asm.ll -march=x86-64 >
/home/garga/llvm/test/CodeGen/X86/Output/bswap-inline-asm.ll.tmp
not grep APP /home/garga/llvm/test/CodeGen/X86/Output/bswap-inline-asm.ll.tmp
FileCheck /home/garga/llvm/test/CodeGen/X86/bswap-inline-asm.ll <
/home/garga/llvm/test/CodeGen/X86/Output/bswap-inline-asm.ll.tmp
--
Exit Code: 1
Command Output (stdout):
--
Command 0: "llc" "-march=x86-64"
Command 0 Result: 0
Command 0 Output:
None

Command 0 Stderr:


Command 1: "not" "grep" "APP"
"/home/garga/llvm/test/CodeGen/X86/Output/bswap-inline-asm.ll.tmp"
Command 1 Result: 1
Command 1 Output:
        #APP
        #NO_APP
        #APP
        #NO_APP
        #APP
        #NO_APP
        #APP
        #NO_APP


Command 1 Stderr:


--
Command Output (stderr):
--
--

********************
Testing Time: 272.41s
********************
Failing Tests (1):
    LLVM :: CodeGen/X86/bswap-inline-asm.ll

  Expected Passes    : 3426
  Expected Failures  : 19
  Unsupported Tests  : 1654
  Unexpected Failures: 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 llvm.org  Fri Mar 12 07:11:58 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 12 Mar 2010 07:11:58 -0600 (CST)
Subject: [LLVMbugs] [Bug 6591] New: llc/lli crashes: 1246 tests failed on
 Ubuntu hardy lpia
Message-ID: <bug-6591-206@http.llvm.org/bugs/>

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

           Summary: llc/lli crashes: 1246 tests failed on Ubuntu hardy
                    lpia
           Product: new-bugs
           Version: trunk
          Platform: PC
               URL: http://launchpadlibrarian.net/40834252/buildlog_ubuntu
                    -hardy-lpia.clamav_0.96~rc1%2Bdfsg-0ubuntu1~hardy1~ppa
                    2_FAILEDTOBUILD.txt.gz
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: edwintorok at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Bug originally noticed in ClamAV's buildlogs, reproduced with upstream LLVM:
LLVM SVN r97959
../llvm/configure --enable-optimized --enable-targets=host-only
--disable-bindings

On Ubuntu hardy, architecture lpia (an i686 with "power saving optimizations")
llc/lli crashes a lot with -O2 (works with -O0):
  Expected Passes    : 115
  Expected Failures  : 17
  Unsupported Tests  : 757
  Unexpected Failures: 1246

I got an Ubuntu lpia chroot like this (on Debian):
debootstrap --arch lpia hardy /home/edwin/hardy-lpia/ http://ports.ubuntu.com/

And in /etc/schroot/schroot.conf:
[hardy-lpia]
description=Ubuntu hardy lpia
location=/home/edwin/hardy-lpia
priority=3
users=edwin,root
groups=edwin,root
root-groups=root
personality=linux32
type=directory

$ Release/bin/llc <..//llvm/test/CodeGen/X86/xor.ll
        .file   "<stdin>"                                                       
        .text                                                                   
        .globl  test1                                                           
        .align  16, 0x90                                                        
        .type   test1, at function                                                 
test1:                                  # @test1                                
# BB#0:                                                                         
        xorps   %xmm0, %xmm0                                                    
        ret                                                                     
        .size   test1, .-test1                                                  

0  llc 0x087cb364
Stack dump:      
0.      Program arguments: Release/bin/llc 
1.      Running pass 'X86 DAG->DAG Instruction Selection' on function '@test2'
Segmentation fault                                            

Ubuntu hardy lpia has this compiler:
gcc -v
Using built-in specs.
Target: i686-linux-gnulp
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2
--enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr
--with-arch=i686 --with-tune=i586 --enable-checking=release
--build=i686-linux-gnulp --host=i686-linux-gnulp --target=i686-linux-gnulp
Thread model: posix
gcc version 4.2.3 (Ubuntu 4.2.3-2ubuntu7)

g++ -v
Using built-in specs.
Target: i686-linux-gnulp
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2
--enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr
--with-arch=i686 --with-tune=i586 --enable-checking=release
--build=i686-linux-gnulp --host=i686-linux-gnulp --target=i686-linux-gnulp
Thread model: posix
gcc version 4.2.3 (Ubuntu 4.2.3-2ubuntu7)

ld -v
GNU ld (GNU Binutils for Ubuntu) 2.18.0.20080103

Karmic lpia (and others) built LLVM fine, and all tests passed.

-- 
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 llvm.org  Fri Mar 12 07:24:40 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 12 Mar 2010 07:24:40 -0600 (CST)
Subject: [LLVMbugs] [Bug 6592] New: Fake error concerning: cannot combine
 with previous 'extern' declaration specifier
Message-ID: <bug-6592-206@http.llvm.org/bugs/>

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

           Summary: Fake error concerning: cannot combine with previous
                    'extern' declaration specifier
           Product: clang
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: Fons.Rademakers at cern.ch
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


Created an attachment (id=4489)
 --> (http://llvm.org/bugs/attachment.cgi?id=4489)
Source file exhibiting the problem

The attached aap.cxx compiles fine with g++ (and for that matter any other know
compiler), but not with clang++. Do:

clang++ -c aap.cxx
In file included from core/editline/src/TTermManip.cxx:1:
In file included from core/editline/src/TTermManip.cxx:12:
core/editline/src/TTermManip.h:19:12: error: cannot combine with previous
      'extern' declaration specifier
extern "C" typedef int (*PutcFunc_t)(int);
           ^
core/editline/src/TTermManip.h:99:4: error: unknown type name 'PutcFunc_t'
   PutcFunc_t fPutc;
   ^
In file included from core/editline/src/TTermManip.cxx:1:
core/editline/src/TTermManip.cxx:29:22: error: expected ')'
   fPutc((PutcFunc_t)DefaultPutchar),
                     ^
core/editline/src/TTermManip.cxx:29:9: note: to match this '('
   fPutc((PutcFunc_t)DefaultPutchar),
        ^
4 diagnostics generated.

No errors compiling with g++.

-- 
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 llvm.org  Fri Mar 12 07:33:57 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 12 Mar 2010 07:33:57 -0600 (CST)
Subject: [LLVMbugs] [Bug 6593] New: False error: use of undeclared
	identifier 'address'
Message-ID: <bug-6593-206@http.llvm.org/bugs/>

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

           Summary: False error: use of undeclared identifier 'address'
           Product: clang
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: Fons.Rademakers at cern.ch
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


The attached aap.cxx compiles fine with g++ (and for that matter any other know
compiler), but not with clang++. Do:

clang++ -c aap.cxx
In file included from core/base/src/G__Base2.cxx:1:
In file included from core/base/src/G__Base2.cxx:18:
include/TCollectionProxyInfo.h:217:40: error: use of undeclared identifier
      'address'
         return e->fStart = e->fSize ? address(*c->begin()) : 0;
                                       ^
include/TCollectionProxyInfo.h:356:51: note: in instantiation of member
function
      'ROOT::TCollectionProxyInfo::Pushback<class std::vector<class TString,
      class std::allocator<class TString> > >::resize' requested here
                                               T::resize,
                                                  ^
In file included from core/base/src/G__Base2.cxx:1:
core/base/src/G__Base2.cxx:5914:41: note: in instantiation of function template
      specialization 'ROOT::TCollectionProxyInfo::Generate<struct
      ROOT::TCollectionProxyInfo::Pushback<class std::vector<class TString,
      class std::allocator<class TString> > > >' requested here
      instance.AdoptCollectionProxyInfo(TCollectionProxyInfo:...
                                        ^
In file included from core/base/src/G__Base2.cxx:1:
In file included from core/base/src/G__Base2.cxx:18:
include/TCollectionProxyInfo.h:104:20: note: must qualify identifier to find
      this declaration in dependent base class
      static void* address(T ref) {
                   ^
include/TCollectionProxyInfo.h:154:29: error: use of undeclared identifier
      'address'
         return e->fStart = address(ref);
                            ^
include/TCollectionProxyInfo.h:358:51: note: in instantiation of member
function
      'ROOT::TCollectionProxyInfo::Type<class std::vector<class TString, class
      std::allocator<class TString> > >::first' requested here
                                               T::first,
                                                  ^
In file included from core/base/src/G__Base2.cxx:1:
core/base/src/G__Base2.cxx:5914:41: note: in instantiation of function template
      specialization 'ROOT::TCollectionProxyInfo::Generate<struct
      ROOT::TCollectionProxyInfo::Pushback<class std::vector<class TString,
      class std::allocator<class TString> > > >' requested here
      instance.AdoptCollectionProxyInfo(TCollectionProxyInfo:...
                                        ^
In file included from core/base/src/G__Base2.cxx:1:
In file included from core/base/src/G__Base2.cxx:18:
include/TCollectionProxyInfo.h:104:20: note: must qualify identifier to find
      this declaration in dependent base class
      static void* address(T ref) {
                   ^
include/TCollectionProxyInfo.h:163:17: error: use of undeclared identifier
      'address'
         return address(ref);
                ^
include/TCollectionProxyInfo.h:359:51: note: in instantiation of member
function
      'ROOT::TCollectionProxyInfo::Type<class std::vector<class TString, class
      std::allocator<class TString> > >::next' requested here
                                               T::next,
                                                  ^
In file included from core/base/src/G__Base2.cxx:1:
core/base/src/G__Base2.cxx:5914:41: note: in instantiation of function template
      specialization 'ROOT::TCollectionProxyInfo::Generate<struct
      ROOT::TCollectionProxyInfo::Pushback<class std::vector<class TString,
      class std::allocator<class TString> > > >' requested here
      instance.AdoptCollectionProxyInfo(TCollectionProxyInfo:...
                                        ^
In file included from core/base/src/G__Base2.cxx:1:
In file included from core/base/src/G__Base2.cxx:18:
include/TCollectionProxyInfo.h:104:20: note: must qualify identifier to find
      this declaration in dependent base class
      static void* address(T ref) {
                   ^
include/TCollectionProxyInfo.h:217:40: error: use of undeclared identifier
      'address'
         return e->fStart = e->fSize ? address(*c->begin()) : 0;
                                       ^
include/TCollectionProxyInfo.h:356:51: note: in instantiation of member
function
      'ROOT::TCollectionProxyInfo::Pushback<class std::vector<class
      std::basic_string<char, struct std::char_traits<char>, class
      std::allocator<char> >, class std::allocator<class
std::basic_string<char,
      struct std::char_traits<char>, class std::allocator<char> > > >
>::resize'
      requested here
                                               T::resize,
                                                  ^
In file included from core/base/src/G__Base2.cxx:1:
core/base/src/G__Base2.cxx:5972:41: note: in instantiation of function template
      specialization 'ROOT::TCollectionProxyInfo::Generate<struct
      ROOT::TCollectionProxyInfo::Pushback<class std::vector<class
      std::basic_string<char, struct std::char_traits<char>, class
      std::allocator<char> >, class std::allocator<class
std::basic_string<char,
      struct std::char_traits<char>, class std::allocator<char> > > > > >'
      requested here
      instance.AdoptCollectionProxyInfo(TCollectionProxyInfo:...
                                        ^
In file included from core/base/src/G__Base2.cxx:1:
In file included from core/base/src/G__Base2.cxx:18:
include/TCollectionProxyInfo.h:104:20: note: must qualify identifier to find
      this declaration in dependent base class
      static void* address(T ref) {
                   ^
include/TCollectionProxyInfo.h:154:29: error: use of undeclared identifier
      'address'
         return e->fStart = address(ref);
                            ^
include/TCollectionProxyInfo.h:358:51: note: in instantiation of member
function
      'ROOT::TCollectionProxyInfo::Type<class std::vector<class
      std::basic_string<char, struct std::char_traits<char>, class
      std::allocator<char> >, class std::allocator<class
std::basic_string<char,
      struct std::char_traits<char>, class std::allocator<char> > > > >::first'
      requested here
                                               T::first,
                                                  ^
In file included from core/base/src/G__Base2.cxx:1:
core/base/src/G__Base2.cxx:5972:41: note: in instantiation of function template
      specialization 'ROOT::TCollectionProxyInfo::Generate<struct
      ROOT::TCollectionProxyInfo::Pushback<class std::vector<class
      std::basic_string<char, struct std::char_traits<char>, class
      std::allocator<char> >, class std::allocator<class
std::basic_string<char,
      struct std::char_traits<char>, class std::allocator<char> > > > > >'
      requested here
      instance.AdoptCollectionProxyInfo(TCollectionProxyInfo:...
                                        ^
In file included from core/base/src/G__Base2.cxx:1:
In file included from core/base/src/G__Base2.cxx:18:
include/TCollectionProxyInfo.h:104:20: note: must qualify identifier to find
      this declaration in dependent base class
      static void* address(T ref) {
                   ^
include/TCollectionProxyInfo.h:163:17: error: use of undeclared identifier
      'address'
         return address(ref);
                ^
include/TCollectionProxyInfo.h:359:51: note: in instantiation of member
function
      'ROOT::TCollectionProxyInfo::Type<class std::vector<class
      std::basic_string<char, struct std::char_traits<char>, class
      std::allocator<char> >, class std::allocator<class
std::basic_string<char,
      struct std::char_traits<char>, class std::allocator<char> > > > >::next'
      requested here
                                               T::next,
                                                  ^
In file included from core/base/src/G__Base2.cxx:1:
core/base/src/G__Base2.cxx:5972:41: note: in instantiation of function template
      specialization 'ROOT::TCollectionProxyInfo::Generate<struct
      ROOT::TCollectionProxyInfo::Pushback<class std::vector<class
      std::basic_string<char, struct std::char_traits<char>, class
      std::allocator<char> >, class std::allocator<class
std::basic_string<char,
      struct std::char_traits<char>, class std::allocator<char> > > > > >'
      requested here
      instance.AdoptCollectionProxyInfo(TCollectionProxyInfo:...
                                        ^
In file included from core/base/src/G__Base2.cxx:1:
In file included from core/base/src/G__Base2.cxx:18:
include/TCollectionProxyInfo.h:104:20: note: must qualify identifier to find
      this declaration in dependent base class
      static void* address(T ref) {
                   ^
24 diagnostics generated.


No errors compiling with g++.

Cheers, Fons.

-- 
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 llvm.org  Fri Mar 12 07:40:40 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 12 Mar 2010 07:40:40 -0600 (CST)
Subject: [LLVMbugs] [Bug 6594] New: False error: template argument for
 template type parameter must be a type
Message-ID: <bug-6594-206@http.llvm.org/bugs/>

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

           Summary: False error: template argument for template type
                    parameter must be a type
           Product: clang
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: Fons.Rademakers at cern.ch
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


Created an attachment (id=4491)
 --> (http://llvm.org/bugs/attachment.cgi?id=4491)
Source file exhibiting the problem

The attached aap.cxx compiles fine with g++ (and for that matter any other know
compiler), but not with clang++. Do:

clang++ -c aap.cxx
In file included from cint/reflex/src/ClassBuilder.cxx:16:
include/Reflex/Builder/ClassBuilder.h:465:63: error: template argument for
      template type parameter must be a type
   fClassBuilderImpl.AddFunctionMember(nam, FunctionDistiller<F>...
                                                              ^
In file included from cint/reflex/src/ClassBuilder.cxx:16:
In file included from include/Reflex/Builder/ClassBuilder.h:20:
include/Reflex/Builder/TypeBuilder.h:931:20: note: template parameter is
      declared here
template <typename S> class FunctionDistiller;
                   ^
In file included from cint/reflex/src/ClassBuilder.cxx:16:
include/Reflex/Builder/ClassBuilder.h:461:54: warning: unused parameter
'stubFP'
      [-Wunused-parameter]
                                        StubFunction stubFP,
                                                     ^
include/Reflex/Builder/ClassBuilder.h:462:47: warning: unused parameter
      'stubCtx' [-Wunused-parameter]
                                        void* stubCtx,
                                              ^
include/Reflex/Builder/ClassBuilder.h:463:53: warning: unused parameter
'params'
      [-Wunused-parameter]
                                        const char* params,
                                                    ^
include/Reflex/Builder/ClassBuilder.h:464:54: warning: unused parameter
      'modifiers' [-Wunused-parameter]
                                        unsigned int modifiers) {
                                                     ^
include/Reflex/Builder/ClassBuilder.h:561:63: error: template argument for
      template type parameter must be a type
   fClassBuilderImpl.AddFunctionMember(nam, FunctionDistiller<F>...
                                                              ^
In file included from cint/reflex/src/ClassBuilder.cxx:16:
In file included from include/Reflex/Builder/ClassBuilder.h:20:
include/Reflex/Builder/TypeBuilder.h:931:20: note: template parameter is
      declared here
template <typename S> class FunctionDistiller;
                   ^
In file included from cint/reflex/src/ClassBuilder.cxx:16:
include/Reflex/Builder/ClassBuilder.h:557:35: warning: unused parameter
'stubFP'
      [-Wunused-parameter]
                     StubFunction stubFP,
                                  ^
include/Reflex/Builder/ClassBuilder.h:558:28: warning: unused parameter
      'stubCtx' [-Wunused-parameter]
                     void* stubCtx,
                           ^
include/Reflex/Builder/ClassBuilder.h:559:34: warning: unused parameter
'params'
      [-Wunused-parameter]
                     const char* params,
                                 ^
include/Reflex/Builder/ClassBuilder.h:560:35: warning: unused parameter
      'modifiers' [-Wunused-parameter]
                     unsigned int modifiers) {
                                  ^
12 diagnostics generated.
(proof) [343] g++ -g -m64 -pipe -W -Wall -Woverloaded-virtual -fsigned-char
-fno-common -Iinclude   -D_REENTRANT -pthread -o cint/reflex/src/ClassBuilder.o
-c cint/reflex/src/ClassBuilder.cxx
(proof) [344] clang++ -g -m64 -pipe -W -Wall -Woverloaded-virtual -fsigned-char
-fno-common -Iinclude   -D_REENTRANT -pthread -E -o aap.cxx
cint/reflex/src/ClassBuilder.cxx
(proof) [345] clang++ -c aap
clang: error: no such file or directory: 'aap'
clang: error: no input files
(proof) [346] clang++ -c aap.cxx
In file included from cint/reflex/src/ClassBuilder.cxx:1:
In file included from cint/reflex/src/ClassBuilder.cxx:16:
include/Reflex/Builder/ClassBuilder.h:465:63: error: template argument for
      template type parameter must be a type
   fClassBuilderImpl.AddFunctionMember(nam, FunctionDistiller<F>...
                                                              ^
In file included from cint/reflex/src/ClassBuilder.cxx:1:
In file included from cint/reflex/src/ClassBuilder.cxx:16:
In file included from include/Reflex/Builder/ClassBuilder.h:20:
include/Reflex/Builder/TypeBuilder.h:931:20: note: template parameter is
      declared here
template <typename S> class FunctionDistiller;
                   ^
In file included from cint/reflex/src/ClassBuilder.cxx:1:
In file included from cint/reflex/src/ClassBuilder.cxx:16:
include/Reflex/Builder/ClassBuilder.h:561:63: error: template argument for
      template type parameter must be a type
   fClassBuilderImpl.AddFunctionMember(nam, FunctionDistiller<F>...
                                                              ^
In file included from cint/reflex/src/ClassBuilder.cxx:1:
In file included from cint/reflex/src/ClassBuilder.cxx:16:
In file included from include/Reflex/Builder/ClassBuilder.h:20:
include/Reflex/Builder/TypeBuilder.h:931:20: note: template parameter is
      declared here
template <typename S> class FunctionDistiller;
                   ^
4 diagnostics generated.

No errors compiling with g++.

Cheers, Fons.

-- 
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 llvm.org  Fri Mar 12 07:58:48 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 12 Mar 2010 07:58:48 -0600 (CST)
Subject: [LLVMbugs] [Bug 6590] test/CodeGen/X86/bswap-inline-asm.ll fails on
 FreeBSD 9.0-CURRENT
In-Reply-To: <bug-6590-206@http.llvm.org/bugs/>
References: <bug-6590-206@http.llvm.org/bugs/>
Message-ID: <20100312135848.8717F2A6C12D@llvm.org>

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

Benjamin Kramer <benny.kra at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |benny.kra at gmail.com
         Resolution|                            |FIXED

--- Comment #1 from Benjamin Kramer <benny.kra at gmail.com> 2010-03-12 07:58:48 CST ---
This should be fixed in r98349.
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20100308/097702.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 llvm.org  Fri Mar 12 08:08:25 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 12 Mar 2010 08:08:25 -0600 (CST)
Subject: [LLVMbugs] [Bug 6595] New: Flase error: conditional expression is
	ambiguous
Message-ID: <bug-6595-206@http.llvm.org/bugs/>

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

           Summary: Flase error: conditional expression is ambiguous
           Product: clang
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: Fons.Rademakers at cern.ch
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


Created an attachment (id=4492)
 --> (http://llvm.org/bugs/attachment.cgi?id=4492)
Source file exhibiting the problem

The attached aap.cxx compiles fine with g++ (and for that matter any other know
compiler), but not with clang++. Do:

clang++ -c aap.cxx
In file included from net/net/src/TApplicationRemote.cxx:1:
net/net/src/TApplicationRemote.cxx:102:24: error: conditional expression is
      ambiguous; 'class TString' can be converted to 'char const [1]' and vice
      versa
   TString user = (pw) ? pw->fUser : "";
                       ^ ~~~~~~~~~   ~~
1 diagnostic generated.

Compiles fine with g++.

Cheers, Fons.

-- 
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 llvm.org  Fri Mar 12 08:34:08 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 12 Mar 2010 08:34:08 -0600 (CST)
Subject: [LLVMbugs] [Bug 6596] New: Assertion failed: (Ctx->isFileContext()
 && "We should have been looking only at file context here already."),
 function CppLookupName, file SemaLookup.cpp, line 730.
Message-ID: <bug-6596-206@http.llvm.org/bugs/>

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

           Summary: Assertion failed: (Ctx->isFileContext() && "We should
                    have been looking only at file context here
                    already."), function CppLookupName, file
                    SemaLookup.cpp, line 730.
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: ich at az2000.de
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


[  0%] Building CXX object CMakeFiles/openlierox.dir/src/gusanos/game_actions.o
Assertion failed: (Ctx->isFileContext() && "We should have been looking only at
file context here already."), function CppLookupName, file SemaLookup.cpp, line
730.
0  clang             0x00eec624 main + 15620188
1  clang             0x00eeca8e main + 15621318
2  libSystem.B.dylib 0x9346e2bb _sigtramp + 43
3  libSystem.B.dylib 0xffffffff _sigtramp + 1824071023
4  libSystem.B.dylib 0x934e223a raise + 26
5  libSystem.B.dylib 0x934ee679 abort + 73
6  libSystem.B.dylib 0x934e33db __assert_rtn + 101
7  clang             0x0030feda main + 3182866
8  clang             0x003102f1 main + 3183913
9  clang             0x00233ca0 main + 2281176
10 clang             0x002347ea main + 2284066
11 clang             0x005bbab2 main + 5983466
12 clang             0x005de7c3 main + 6126075
13 clang             0x0059d48d main + 5859013
14 clang             0x005a1113 main + 5874507
15 clang             0x005a14b4 main + 5875436
16 clang             0x005dd0fd main + 6120245
17 clang             0x005a80c5 main + 5903101
18 clang             0x005a13de main + 5875222
19 clang             0x005ce4f4 main + 6059820
20 clang             0x005d2e80 main + 6078648
21 clang             0x005d3553 main + 6080395
22 clang             0x005dde8b main + 6123715
23 clang             0x005a0ce1 main + 5873433
24 clang             0x005dc3c7 main + 6116863
25 clang             0x005dc414 main + 6116940
26 clang             0x005dd1f4 main + 6120492
27 clang             0x005dd332 main + 6120810
28 clang             0x00224288 main + 2217152
29 clang             0x0003fef6 main + 233774
30 clang             0x0003fde6 main + 233502
31 clang             0x0002141b main + 108115
32 clang             0x00003414 _mh_execute_header + 9236
33 clang             0x00006eb1 main + 233
34 clang             0x00002336 _mh_execute_header + 4918
35 clang             0x00000033 _mh_execute_header + 18446744073709547571
Stack dump:
0.    Program arguments:
/Users/az/Programmierung/CppIDE/llvm-src/Debug/bin/clang -cc1 -triple
i386-apple-darwin9.0.0 -S -disable-free -main-file-name game_actions.cpp
-pic-level 1 -mdisable-fp-elim -target-cpu yonah -g -resource-dir
/Users/az/Programmierung/CppIDE/llvm-src/Debug/lib/clang/1.1 -DDEBUG=1
-D_AI_DEBUG -D SYSTEM_DATA_DIR="/usr/share/games"
-I/Users/az/Programmierung/openlierox/./optional-includes/generated
-I/Users/az/Programmierung/openlierox/./include
-I/Users/az/Programmierung/openlierox/./src
-I/Users/az/Programmierung/openlierox/./libs/pstreams -I/usr/include/libxml2
-I/usr/local/include/libxml2
-I/Users/az/Programmierung/openlierox/./libs/breakpad/src
-I/Users/az/Programmierung/openlierox/./libs/hawknl/include
-I/Users/az/Programmierung/openlierox/./libs/libzip
-I/Users/az/Programmierung/openlierox/./libs/lua
-I/Users/az/Programmierung/openlierox/./build/Xcode/include
-I/Users/az/Programmierung/openlierox/./build/Xcode/freealut/include
-I/Library/Frameworks/SDL.framework/Headers
-I/Library/Frameworks/SDL_image.framework/Headers
-I/Library/Frameworks/SDL_mixer.framework/Headers
-I/Library/Frameworks/UnixImageIO.framework/Headers
-I/Library/Frameworks/GD.framework/Headers -F ./build/Xcode
-F/Library/Frameworks -Wall -fmessage-length 99 -pthread -fexceptions
-fdiagnostics-show-option -fcolor-diagnostics -o
/var/folders/P9/P9wWY+Z8HDeOPixVmDZ0J++++TI/-Tmp-/cc-pnjsM0.s -x c++
/Users/az/Programmierung/openlierox/src/gusanos/game_actions.cpp 
1.    /Users/az/Programmierung/openlierox/src/gusanos/game_actions.cpp:50:23:
current parser token 'ActionParamFlags'
2.    /Users/az/Programmierung/openlierox/src/gusanos/game_actions.cpp:48:1:
parsing function body 'registerGameActions'
3.    /Users/az/Programmierung/openlierox/src/gusanos/game_actions.cpp:48:1: in
compound statement ('{}')
4.    /Users/az/Programmierung/openlierox/src/gusanos/game_actions.cpp:49:2:
parsing namespace 'af'

clang: error: compiler command failed due to signal 6 (use -v to see
invocation)
make[2]: *** [CMakeFiles/openlierox.dir/src/gusanos/game_actions.o] Error 250
make[1]: *** [CMakeFiles/openlierox.dir/all] 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 llvm.org  Fri Mar 12 08:52:47 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 12 Mar 2010 08:52:47 -0600 (CST)
Subject: [LLVMbugs] [Bug 6597] New: Assertion failed: (false && "Unhandled
 type!"), function getTypeInfoLinkage, file CGRTTI.cpp, line 333.
Message-ID: <bug-6597-206@http.llvm.org/bugs/>

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

           Summary: Assertion failed: (false && "Unhandled type!"),
                    function getTypeInfoLinkage, file CGRTTI.cpp, line
                    333.
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: ich at az2000.de
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


[  0%] Building CXX object CMakeFiles/openlierox.dir/src/gusanos/gconsole.o
Assertion failed: (false && "Unhandled type!"), function getTypeInfoLinkage,
file CGRTTI.cpp, line 333.
0  clang             0x00eec624 main + 15620188
1  clang             0x00eeca8e main + 15621318
2  libSystem.B.dylib 0x9346e2bb _sigtramp + 43
3  libSystem.B.dylib 0xffffffff _sigtramp + 1824071023
4  libSystem.B.dylib 0x934e223a raise + 26
5  libSystem.B.dylib 0x934ee679 abort + 73
6  libSystem.B.dylib 0x934e33db __assert_rtn + 101
7  clang             0x001c53e2 main + 1828378
8  clang             0x001c558c main + 1828804
9  clang             0x001c5403 main + 1828411
10 clang             0x001c58ef main + 1829671
11 clang             0x001c5cfa main + 1830706
12 clang             0x001725b3 main + 1488875
13 clang             0x001603de main + 1414678
14 clang             0x00166c17 main + 1441359
15 clang             0x0018c531 main + 1595241
16 clang             0x0018d807 main + 1600063
17 clang             0x00190380 main + 1611192
18 clang             0x00188b38 main + 1580400
19 clang             0x0019013c main + 1610612
20 clang             0x00187d4b main + 1576835
21 clang             0x001625fa main + 1423410
22 clang             0x001cb7f7 main + 1853999
23 clang             0x001cc3ff main + 1857079
24 clang             0x001cd49a main + 1861330
25 clang             0x001cb662 main + 1853594
26 clang             0x001cd128 main + 1860448
27 clang             0x001cd3b1 main + 1861097
28 clang             0x001cb662 main + 1853594
29 clang             0x001cbc0f main + 1855047
30 clang             0x001cb95e main + 1854358
31 clang             0x001cd128 main + 1860448
32 clang             0x001cd3b1 main + 1861097
33 clang             0x001cb662 main + 1853594
34 clang             0x001f3729 main + 2017633
35 clang             0x001f6411 main + 2029129
36 clang             0x001fead7 main + 2063631
37 clang             0x001fedaf main + 2064359
38 clang             0x001fef51 main + 2064777
39 clang             0x001ff35c main + 2065812
40 clang             0x002170ee main + 2163494
41 clang             0x0001f8dc main + 101140
42 clang             0x0022435a main + 2217362
43 clang             0x0003fef6 main + 233774
44 clang             0x0003fde6 main + 233502
45 clang             0x0002141b main + 108115
46 clang             0x00003414 _mh_execute_header + 9236
47 clang             0x00006eb1 main + 233
48 clang             0x00002336 _mh_execute_header + 4918
49 clang             0x00000033 _mh_execute_header + 18446744073709547571
Stack dump:
0.    Program arguments:
/Users/az/Programmierung/CppIDE/llvm-src/Debug/bin/clang -cc1 -triple
i386-apple-darwin9.0.0 -S -disable-free -main-file-name gconsole.cpp -pic-level
1 -mdisable-fp-elim -target-cpu yonah -g -resource-dir
/Users/az/Programmierung/CppIDE/llvm-src/Debug/lib/clang/1.1 -DDEBUG=1
-D_AI_DEBUG -D SYSTEM_DATA_DIR="/usr/share/games"
-I/Users/az/Programmierung/openlierox/./optional-includes/generated
-I/Users/az/Programmierung/openlierox/./include
-I/Users/az/Programmierung/openlierox/./src
-I/Users/az/Programmierung/openlierox/./libs/pstreams -I/usr/include/libxml2
-I/usr/local/include/libxml2
-I/Users/az/Programmierung/openlierox/./libs/breakpad/src
-I/Users/az/Programmierung/openlierox/./libs/hawknl/include
-I/Users/az/Programmierung/openlierox/./libs/libzip
-I/Users/az/Programmierung/openlierox/./libs/lua
-I/Users/az/Programmierung/openlierox/./build/Xcode/include
-I/Users/az/Programmierung/openlierox/./build/Xcode/freealut/include
-I/Library/Frameworks/SDL.framework/Headers
-I/Library/Frameworks/SDL_image.framework/Headers
-I/Library/Frameworks/SDL_mixer.framework/Headers
-I/Library/Frameworks/UnixImageIO.framework/Headers
-I/Library/Frameworks/GD.framework/Headers -F ./build/Xcode
-F/Library/Frameworks -Wall -fmessage-length 99 -pthread -fexceptions
-fdiagnostics-show-option -fcolor-diagnostics -o
/var/folders/P9/P9wWY+Z8HDeOPixVmDZ0J++++TI/-Tmp-/cc-mNH5VM.s -x c++
/Users/az/Programmierung/openlierox/src/gusanos/gconsole.cpp 
1.    <eof> parser at end of file
2.    Per-file LLVM IR generation
3.    /usr/local/include/boost/function/function_base.hpp:420:9: Generating
code for declaration
'boost::detail::function::functor_manager<std::basic_string<char>
(*)(std::list<std::basic_string<char>, std::allocator<std::basic_string<char> >
> const &)>::manage'
4.    /usr/local/include/boost/function/function_base.hpp:422:9: LLVM IR
generation of compound statement ('{}')
5.    /usr/local/include/boost/function/function_base.hpp:424:23: LLVM IR
generation of compound statement ('{}')
clang: error: compiler command failed due to signal 6 (use -v to see
invocation)
make[2]: *** [CMakeFiles/openlierox.dir/src/gusanos/gconsole.o] Error 250
make[1]: *** [CMakeFiles/openlierox.dir/all] 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 llvm.org  Fri Mar 12 10:06:19 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 12 Mar 2010 10:06:19 -0600 (CST)
Subject: [LLVMbugs] [Bug 6598] New: duplicate symbol...
Message-ID: <bug-6598-206@http.llvm.org/bugs/>

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

           Summary: duplicate symbol...
           Product: clang
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: Fons.Rademakers at cern.ch
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


Created an attachment (id=4495)
 --> (http://llvm.org/bugs/attachment.cgi?id=4495)
Source file exhibiting the problem

To see this behaviour do:

$ g++ -c aap1.cxx    (file fails with assert using clang++, bug 6565)
$ clang++ -c aap2.cxx
$ clang++ -dynamiclib -single_module -undefined dynamic_lookup -g -m64 -o
aap.so aap1.o aap2.o -ldl
ld: duplicate symbol __ZTS12TMatrixTLazyIfE in aap2.o and aap1.o
clang: error: linker command failed with exit code 1 (use -v to see invocation)

recompile aap2.cxx with g++ and the issue disappears.

Cheers, Fons.

-- 
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 llvm.org  Fri Mar 12 12:11:07 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 12 Mar 2010 12:11:07 -0600 (CST)
Subject: [LLVMbugs] [Bug 6587] llvm-gcc fails to compile clang-emitted
 .secrel32 assembly directives
In-Reply-To: <bug-6587-206@http.llvm.org/bugs/>
References: <bug-6587-206@http.llvm.org/bugs/>
Message-ID: <20100312181107.D77B02A6C12F@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #1 from Chris Lattner <clattner at apple.com> 2010-03-12 12:11:07 CST ---
Great catch, sorry for the breakage, your patch is applied here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20100308/097712.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 llvm.org  Fri Mar 12 13:18:51 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 12 Mar 2010 13:18:51 -0600 (CST)
Subject: [LLVMbugs] [Bug 6588] Assertion `RegNo && RegNo < 159 && "Invalid
 register number!"' failed.
In-Reply-To: <bug-6588-206@http.llvm.org/bugs/>
References: <bug-6588-206@http.llvm.org/bugs/>
Message-ID: <20100312191851.643722A6C12E@llvm.org>

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

Devang Patel <dpatel at apple.com> changed:

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

--- Comment #5 from Devang Patel <dpatel at apple.com> 2010-03-12 13:18:50 CST ---
Fixed. r98369.

-- 
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 llvm.org  Fri Mar 12 14:27:35 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 12 Mar 2010 14:27:35 -0600 (CST)
Subject: [LLVMbugs] [Bug 6601] New: Generic codegen tests that need
 -march=x86, and fail on ppc
Message-ID: <bug-6601-206@http.llvm.org/bugs/>

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

           Summary: Generic codegen tests that need -march=x86, and fail
                    on ppc
           Product: new-bugs
           Version: unspecified
          Platform: Other
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: edwintorok at gmail.com
                CC: llvmbugs at cs.uiuc.edu


See
http://launchpadlibrarian.net/40883485/buildlog_ubuntu-lucid-powerpc.clamav_0.96~rc1%2Bdfsg-0ubuntu1_FAILEDTOBUILD.txt.gz

Some are missing a target, and some have X86, which of course won't work if
only the PPC backend is built.
The tests should have proper -march, and XFAIL on anything else than they
target (or moved to their own target dir).

Testing: 0 .. 10.
FAIL: LLVM :: CodeGen/Generic/2007-02-16-BranchFold.ll (380 of 2135)
******************** TEST 'LLVM :: CodeGen/Generic/2007-02-16-BranchFold.ll'
FAILED ********************
Script:
--
llc <
/build/buildd/clamav-0.96~rc1+dfsg/libclamav/c++/llvm/test/CodeGen/Generic/2007-02-16-BranchFold.ll
-enable-tail-merge=0 | not grep jmp
--
Exit Code: 1
Command Output (stdout):
--
Command has output on stderr!

--
Command Output (stderr):
--
llc: error auto-selecting target for module 'No available targets are
compatible with this triple, see -version for the available targets.'.  Please
use the -march option to explicitly pick a target.
--

********************
Testing: 0 .. 10.
FAIL: LLVM :: CodeGen/Generic/2007-04-13-SwitchLowerBadPhi.ll (381 of 2135)
******************** TEST 'LLVM ::
CodeGen/Generic/2007-04-13-SwitchLowerBadPhi.ll' FAILED ********************
Script:
--
llc <
/build/buildd/clamav-0.96~rc1+dfsg/libclamav/c++/llvm/test/CodeGen/Generic/2007-04-13-SwitchLowerBadPhi.ll
-O0
--
Exit Code: 1
Command Output (stdout):
--
Command has output on stderr!

--
Command Output (stderr):
--
llc: error auto-selecting target for module 'No available targets are
compatible with this triple, see -version for the available targets.'.  Please
use the -march option to explicitly pick a target.
--

********************
Testing: 0 .. 10..
FAIL: LLVM :: CodeGen/Generic/2007-05-05-Personality.ll (388 of 2135)
******************** TEST 'LLVM :: CodeGen/Generic/2007-05-05-Personality.ll'
FAILED ********************
Script:
--
llc <
/build/buildd/clamav-0.96~rc1+dfsg/libclamav/c++/llvm/test/CodeGen/Generic/2007-05-05-Personality.ll
-mtriple=i686-pc-linux-gnu -enable-eh -o - | grep zPL
--
Exit Code: 1
Command Output (stdout):
--
Command has output on stderr!

--
Command Output (stderr):
--
llc: error auto-selecting target for module 'No available targets are
compatible with this triple, see -version for the available targets.'.  Please
use the -march option to explicitly pick a target.
--

********************
Testing: 0 .. 10..
FAIL: LLVM :: CodeGen/Generic/2007-12-17-InvokeAsm.ll (390 of 2135)
******************** TEST 'LLVM :: CodeGen/Generic/2007-12-17-InvokeAsm.ll'
FAILED ********************
Script:
--
llc <
/build/buildd/clamav-0.96~rc1+dfsg/libclamav/c++/llvm/test/CodeGen/Generic/2007-12-17-InvokeAsm.ll
-enable-eh
--
Exit Code: 1
Command Output (stdout):
--
Command has output on stderr!

--
Command Output (stderr):
--
llc: error auto-selecting target for module 'No available targets are
compatible with this triple, see -version for the available targets.'.  Please
use the -march option to explicitly pick a target.
--

********************
Testing: 0 .. 10..
FAIL: LLVM :: CodeGen/Generic/2007-11-21-UndeadIllegalNode.ll (391 of 2135)
******************** TEST 'LLVM ::
CodeGen/Generic/2007-11-21-UndeadIllegalNode.ll' FAILED ********************
Script:
--
llc <
/build/buildd/clamav-0.96~rc1+dfsg/libclamav/c++/llvm/test/CodeGen/Generic/2007-11-21-UndeadIllegalNode.ll
-o -
--
Exit Code: 1
Command Output (stdout):
--
Command has output on stderr!

--
Command Output (stderr):
--
llc: error auto-selecting target for module 'No available targets are
compatible with this triple, see -version for the available targets.'.  Please
use the -march option to explicitly pick a target.
--

********************
Testing: 0 .. 10..
FAIL: LLVM :: CodeGen/Generic/2007-12-31-UnusedSelector.ll (392 of 2135)
******************** TEST 'LLVM ::
CodeGen/Generic/2007-12-31-UnusedSelector.ll' FAILED ********************
Script:
--
llc <
/build/buildd/clamav-0.96~rc1+dfsg/libclamav/c++/llvm/test/CodeGen/Generic/2007-12-31-UnusedSelector.ll
-enable-eh
--
Exit Code: 1
Command Output (stdout):
--
Command has output on stderr!

--
Command Output (stderr):
--
llc: error auto-selecting target for module 'No available targets are
compatible with this triple, see -version for the available targets.'.  Please
use the -march option to explicitly pick a target.
--

********************
Testing: 0 .. 10..
FAIL: LLVM :: CodeGen/Generic/2008-08-07-PtrToInt-SmallerInt.ll (400 of 2135)
******************** TEST 'LLVM ::
CodeGen/Generic/2008-08-07-PtrToInt-SmallerInt.ll' FAILED ********************
Script:
--
llc <
/build/buildd/clamav-0.96~rc1+dfsg/libclamav/c++/llvm/test/CodeGen/Generic/2008-08-07-PtrToInt-SmallerInt.ll
--
Exit Code: 1
Command Output (stdout):
--
Command has output on stderr!

--
Command Output (stderr):
--
llc: error auto-selecting target for module 'No available targets are
compatible with this triple, see -version for the available targets.'.  Please
use the -march option to explicitly pick a target.
--

********************
Testing: 0 .. 10..
FAIL: LLVM :: CodeGen/Generic/2009-11-16-BadKillsCrash.ll (406 of 2135)
******************** TEST 'LLVM :: CodeGen/Generic/2009-11-16-BadKillsCrash.ll'
FAILED ********************
Script:
--
llc <
/build/buildd/clamav-0.96~rc1+dfsg/libclamav/c++/llvm/test/CodeGen/Generic/2009-11-16-BadKillsCrash.ll
--
Exit Code: 1
Command Output (stdout):
--
Command has output on stderr!

--
Command Output (stderr):
--
llc: error auto-selecting target for module 'No available targets are
compatible with this triple, see -version for the available targets.'.  Please
use the -march option to explicitly pick a target.
--

********************
Testing: 0 .. 10..
FAIL: LLVM :: CodeGen/Generic/GC/redundant_init.ll (425 of 2135)
******************** TEST 'LLVM :: CodeGen/Generic/GC/redundant_init.ll' FAILED
********************
Script:
--
llc <
/build/buildd/clamav-0.96~rc1+dfsg/libclamav/c++/llvm/test/CodeGen/Generic/GC/redundant_init.ll
-march=x86 |    ignore grep {movl..0} | count 0
--
Exit Code: 1
Command Output (stdout):
--
Command has output on stderr!

--
Command Output (stderr):
--
llc: error: invalid target 'x86'.
--

********************
Testing: 0 .. 10..
FAIL: LLVM :: CodeGen/Generic/GC/simple_ocaml.ll (426 of 2135)
******************** TEST 'LLVM :: CodeGen/Generic/GC/simple_ocaml.ll' FAILED
********************
Script:
--
llc <
/build/buildd/clamav-0.96~rc1+dfsg/libclamav/c++/llvm/test/CodeGen/Generic/GC/simple_ocaml.ll
| grep caml.*__frametable
llc <
/build/buildd/clamav-0.96~rc1+dfsg/libclamav/c++/llvm/test/CodeGen/Generic/GC/simple_ocaml.ll
-march=x86 | grep {movl    .0}
--
Exit Code: 1
Command Output (stdout):
--
Command has output on stderr!

    .globl    caml<stdin>__frametable
caml<stdin>__frametable:
--
Command Output (stderr):
--
llc: error: invalid target 'x86'.
--

********************
Testing: 0 .. 10.. 20.. 30.. 40.. 50.. 60.. 70.. 80.. 90.. 
Testing Time: 15.89s
********************
Failing Tests (10):
    LLVM :: CodeGen/Generic/2007-02-16-BranchFold.ll
    LLVM :: CodeGen/Generic/2007-04-13-SwitchLowerBadPhi.ll
    LLVM :: CodeGen/Generic/2007-05-05-Personality.ll
    LLVM :: CodeGen/Generic/2007-11-21-UndeadIllegalNode.ll
    LLVM :: CodeGen/Generic/2007-12-17-InvokeAsm.ll
    LLVM :: CodeGen/Generic/2007-12-31-UnusedSelector.ll
    LLVM :: CodeGen/Generic/2008-08-07-PtrToInt-SmallerInt.ll
    LLVM :: CodeGen/Generic/2009-11-16-BadKillsCrash.ll
    LLVM :: CodeGen/Generic/GC/redundant_init.ll
    LLVM :: CodeGen/Generic/GC/simple_ocaml.ll

  Expected Passes    : 486
  Expected Failures  : 15
  Unsupported Tests  : 1624
  Unexpected Failures: 10

-- 
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 llvm.org  Fri Mar 12 17:57:22 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 12 Mar 2010 17:57:22 -0600 (CST)
Subject: [LLVMbugs] [Bug 6603] New: msp430 backend: wrong addressing mode
 for 'br' instruction
Message-ID: <bug-6603-206@http.llvm.org/bugs/>

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

           Summary: msp430 backend: wrong addressing mode for 'br'
                    instruction
           Product: new-bugs
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: pagariya at cs.utah.edu
                CC: llvmbugs at cs.uiuc.edu, regehr at cs.utah.edu


Created an attachment (id=4501)
 --> (http://llvm.org/bugs/attachment.cgi?id=4501)
Test case

Bug:
llvm assembly that contains the branch instruction 'br' uses the indexed
addressing mode, instead of direct mode which is intended.

Description:
Let there be a branch from label A to label B. The code would be:
.L_A
  br #.L_B

...
Some code that doesn't fit in the offset range of absolute jump. Hence branch
instruction is used.
...

.L_B
  mov #0, r15
  ret

The msp430x1xx user guide specifies 7 addressing modes for 'br' instruction.
The relevant ones are:

1. BR #EXEC 
;Branch to label EXEC or direct branch (e.g. #0A4h)
; Core instruction MOV @PC+,PC

2. BR EXEC 
; Branch to the address contained in EXEC
; Core instruction MOV X(PC),PC
; Indirect address

3. BR &EXEC 
; Branch to the address contained in absolute
; address EXEC
; Core instruction MOV X(0),PC
; Indirect address

In the above example, we want to branch to a label (direct addressing mode) and
hence we should use the first addressing mode (br #EXEC). For the same purpose,
llvm generates code that uses second addressing mode (br EXEC).

Branch instructions are emulated as: br dst -> mov.w dst, pc

The llvm generated code gets translated to 
mov.w $off(PC), PC
Here offset is an integer corresponding to the jump offset. 

What actually happens: PC = mem[PC + offset]
Desired instruction: PC = PC + offset

Fix: Labels for branch instruction should be prefixed with '#' to make it
direct addressing mode.

I am attaching all the relevant files. The test case is fairly big (55 lines)
because 'br' instruction is generated only when the offset is huge. It
shouldn't be a problem for this bug though.

Cmd line options:

pagariya at aleph:~/tmp$ clang -ccc-host-triple msp430-elf
-I/home/pagariya/res-pagariya/llvm-msp430/msp430/include -nostdinc -v -O0 -S
foo.c
clang version 1.1 (trunk 184)
Target: msp430-elf-
Thread model: posix
 "/uusoc/facility/res/embed/users/pagariya/llvm-msp430/bin/clang" -cc1 -triple
msp430-elf- -S -disable-free -main-file-name foo.c -mrelocation-model static
-mdisable-fp-elim -mconstructor-aliases -v -nostdinc -resource-dir
/uusoc/facility/res/embed/users/pagariya/llvm-msp430/lib/clang/1.1
-I/home/pagariya/res-pagariya/llvm-msp430/msp430/include -O0 -fmessage-length
102 -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o foo.s -x c
foo.c
clang -cc1 version 1.1 based upon llvm 2.7svn hosted on i386-pc-linux-gnu
#include "..." search starts here:
#include <...> search starts here:
 /home/pagariya/res-pagariya/llvm-msp430/msp430/include
 /uusoc/facility/res/embed/users/pagariya/llvm-msp430/lib/clang/1.1/include
End of search list.

pagariya at aleph:~/tmp$ clang -ccc-host-triple msp430-elf
-L/home/pagariya/res-pagariya/llvm-msp430/lib/msp430
-L/home/pagariya/res-pagariya/llvm-msp430/msp430/lib
-L/home/pagariya/res-pagariya/llvm-msp430/lib/gcc-lib/msp430/3.2.3
-Wl,-m,msp430x1611 -o foo.elf
/home/pagariya/res-pagariya/llvm-msp430/msp430/lib/crt430x1611.o foo-asm.s
-lgcc -v
clang version 1.1 (trunk 184)
Target: msp430-elf-
Thread model: posix
 "/uusoc/facility/res/embed/users/pagariya/llvm-msp430/bin/msp430-as" -o
/tmp/cc-tgCJbV.o foo-asm.s
 "/uusoc/facility/res/embed/users/pagariya/llvm-msp430/bin/msp430-ld" -o
foo.elf -L/home/pagariya/res-pagariya/llvm-msp430/lib/msp430
-L/home/pagariya/res-pagariya/llvm-msp430/msp430/lib
-L/home/pagariya/res-pagariya/llvm-msp430/lib/gcc-lib/msp430/3.2.3 -m
msp430x1611 /home/pagariya/res-pagariya/llvm-msp430/msp430/lib/crt430x1611.o
/tmp/cc-tgCJbV.o -lgcc -L../lib/ -lcompiler_rt.Generic -lc

pagariya at aleph:~/tmp$ uname -a
Linux aleph 2.6.24-24-generic #1 SMP Fri Sep 18 16:49:39 UTC 2009 i686
GNU/Linux

-- 
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 llvm.org  Fri Mar 12 18:00:24 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 12 Mar 2010 18:00:24 -0600 (CST)
Subject: [LLVMbugs] [Bug 6604] New: Combine Instructions phase generates
 bogus offset with some record types
Message-ID: <bug-6604-206@http.llvm.org/bugs/>

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

           Summary: Combine Instructions phase generates bogus offset with
                    some record types
           Product: new-bugs
           Version: 2.6
          Platform: All
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: bugzilla at quickbrownfox.org
                CC: llvmbugs at cs.uiuc.edu


I'm working on a toy compiler for a functional language that uses closures, and
I believe LLVM incorrectly optimizes access to the closure fields when they're
the result of a function. This started happening when I began compiling to
"untyped" LLVM assembly by making liberal use of of the bitcast operator.

Here's a minimal example, where I call a function and interpret the result type
as record containing a function and its argument.

%record = type { i32 (i32)*, i32}
declare i8* @mystery();

define i32 @broken()
{
    %1 = call i8* @mystery();
    %2 = bitcast i8* %1 to %record*;
    %funcRef = getelementptr %record* %2, i32 0, i32 0;
    %func = load i32 (i32)** %funcRef;
    %argRef = getelementptr %record* %2, i32 0, i32 1;
    %arg = load i32* %argRef;

    %res = call i32 %func(i32 %arg);
    ret i32 %res;
}

And here's the function after running opt -instcombine:

define i32 @broken() {
  %1 = call i8* @mystery()                        ; <i8*> [#uses=2]
  %funcRef = bitcast i8* %1 to i32 (i32)**        ; <i32 (i32)**> [#uses=1]
  %func = load i32 (i32)** %funcRef               ; <i32 (i32)*> [#uses=1]
  %argRef = getelementptr i8* %1, i64 8           ; <i8*> [#uses=1]
  %2 = bitcast i8* %argRef to i32*                ; <i32*> [#uses=1]
  %arg = load i32* %2                             ; <i32> [#uses=1]
  %res = call i32 %func(i32 %arg)                 ; <i32> [#uses=1]
  ret i32 %res
}

Note how the second member of the record is being accessed with a byte offset
of 8, instead of 4.
* Changing the order of the fields in the record doesn't help.
* Declaring @mystery to return a record type directly, instead of bitcasting
from i8*, will fix it.
* A similar example that takes a { i32, i32 } and adds the fields works fine.

So the bug seems to be due to casting a value to a record containing a function
pointer, and then accessing the fields of that record.

-- 
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 llvm.org  Sat Mar 13 00:47:30 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 13 Mar 2010 00:47:30 -0600 (CST)
Subject: [LLVMbugs] [Bug 6605] New: ice: Cannot use this version of
	ReplaceAllUsesWith!
Message-ID: <bug-6605-206@http.llvm.org/bugs/>

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

           Summary: ice: Cannot use this version of ReplaceAllUsesWith!
           Product: new-bugs
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: regehr at cs.utah.edu
                CC: llvmbugs at cs.uiuc.edu, chenyang at cs.utah.edu


Created an attachment (id=4506)
 --> (http://llvm.org/bugs/attachment.cgi?id=4506)
failure-inducing input

regehr at john-home:~/volatile/bugs/tmp292$ clang -v

clang version 1.1 (trunk 98425)
Target: i386-pc-linux-gnu
Thread model: posix

regehr at john-home:~/volatile/bugs/tmp292$ clang -O2 -c small.c

clang: SelectionDAG.cpp:4972: void
llvm::SelectionDAG::ReplaceAllUsesWith(llvm::SDNode*, llvm::SDNode*,
llvm::SelectionDAG::DAGUpdateListener*): Assertion `(!From->hasAnyUseOfValue(i)
|| From->getValueType(i) == To->getValueType(i)) && "Cannot use this version of
ReplaceAllUsesWith!"' failed.
0  clang 0x08eec968
Stack dump:
0.    Program arguments:
/home/regehr/z/compiler-install/llvm-gcc-r98425-install/bin/clang -cc1 -triple
i386-pc-linux-gnu -S -disable-free -main-file-name small.c -mrelocation-model
static -mdisable-fp-elim -mconstructor-aliases -target-cpu pentium4
-resource-dir
/home/regehr/z/compiler-install/llvm-gcc-r98425-install/lib/clang/1.1 -O2
-fmessage-length 80 -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics
-o /tmp/cc-mrfDfd.s -x c small.c 
1.    <eof> parser at end of file
2.    Code generation
3.    Running pass 'X86 DAG->DAG Instruction Selection' on function '@func_1'
clang: error: compiler command failed due to signal 6 (use -v to see
invocation)

-- 
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 llvm.org  Sat Mar 13 00:50:20 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 13 Mar 2010 00:50:20 -0600 (CST)
Subject: [LLVMbugs] [Bug 6606] New: ice: replaceAllUses of value with new
 value of different type!
Message-ID: <bug-6606-206@http.llvm.org/bugs/>

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

           Summary: ice: replaceAllUses of value with new value of
                    different type!
           Product: new-bugs
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: regehr at cs.utah.edu
                CC: llvmbugs at cs.uiuc.edu, chenyang at cs.utah.edu


Created an attachment (id=4507)
 --> (http://llvm.org/bugs/attachment.cgi?id=4507)
failure-inducing input

regehr at john-home:~/volatile/bugs/tmp293$ clang -v

clang version 1.1 (trunk 97208)
Target: i386-pc-linux-gnu
Thread model: posix

regehr at john-home:~/volatile/bugs/tmp293$ clang -O1 small.c

small.c:6:9: warning: expression result unused [-Wunused-value]
  *l_22 != (0 >= *p_17 | *p_17 == 0);
  ~~~~~ ^  ~~~~~~~~~~~~~~~~~~~~~~~~~
clang: /home/regehr/llvm/lib/VMCore/Value.cpp:317: void
llvm::Value::replaceAllUsesWith(llvm::Value*): Assertion `New->getType() ==
getType() && "replaceAllUses of value with new value of different type!"'
failed.
0  clang 0x091a05d8
Stack dump:
0.    Program arguments: /home/regehr/llvm/inst/bin/clang -cc1 -triple
i386-pc-linux-gnu -S -disable-free -main-file-name small.c -mrelocation-model
static -mdisable-fp-elim -mconstructor-aliases -target-cpu pentium4
-resource-dir /home/regehr/llvm/inst/lib/clang/1.1 -O1 -fmessage-length 80
-fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-iTGLs3.s
-x c small.c 
1.    <eof> parser at end of file
2.    Per-function optimization
3.    Running pass 'Combine redundant instructions' on function '@func_16'
clang: error: compiler command failed due to signal 6 (use -v to see
invocation)

-- 
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 llvm.org  Sat Mar 13 06:00:53 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 13 Mar 2010 06:00:53 -0600 (CST)
Subject: [LLVMbugs] [Bug 6607] New: "Cannot yet select" error
Message-ID: <bug-6607-206@http.llvm.org/bugs/>

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

           Summary: "Cannot yet select" error
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Common Code Generator Code
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: asl at math.spbu.ru
                CC: llvmbugs at cs.uiuc.edu


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

Consider the bytecode attached. Running llc yields:

$ ./llc bugpoint-reduced-simplified1.bc 
LLVM ERROR: Cannot yet select: 0x171c420: ch = ValueType:i8 [ID=9]

This might be a fallout from isel changes.

-- 
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 llvm.org  Sat Mar 13 11:22:41 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 13 Mar 2010 11:22:41 -0600 (CST)
Subject: [LLVMbugs] [Bug 6608] New: Address of label regression
Message-ID: <bug-6608-206@http.llvm.org/bugs/>

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

           Summary: Address of label regression
           Product: new-bugs
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: release blocker
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: csdavec at swan.ac.uk
                CC: llvmbugs at cs.uiuc.edu


Compiling GSFormat.m from GNUstep, which formerly worked with clang, I now get
assembler errors.  The problem appears to be the use of the address-of-label
extension.  With a reduced test case, I get:

$ cat jmptolabel.c 
int main(int argc, char**argv)
{
    const void *const jump_table[] = { &&lbl1, &&lbl2} ;
    goto *jump_table[0];
lbl1:
    return 1;
lbl2:
    return 0;
}
$ clang -c jmptolabel.c 
/tmp/cc-4ZYGXk.s: Assembler messages:
/tmp/cc-4ZYGXk.s:22: Error: symbol `.LBA4_main_' is already defined
clang: error: assembler command failed with exit code 1 (use -v to see
invocation)

Looking at the generated bitcode, there is one obvious problem:

@main.jump_table = internal constant [2 x i8*] [i8* blockaddress(@main,
<badref>), i8* blockaddress(@main, <badref>)], align 4 ; <[2 x i8*]*> [#uses=1]

Obviously, the <badref> things are wrong.  Looking further down, the error is
more subtle.  The labels for the two jumps look like this:

; <label>:5                                       ; preds = %9
  store i32 1, i32* %1
  br label %7

; <label>:6                                       ; preds = %9
  store i32 0, i32* %1
  br label %7

It seems that LLVM generates the symbol for the jump target by concatenating
the function name and the label name, but in this case the label name is empty
and so all of the symbols are the same.  Adding real names makes it work.  

It would be good if this could be fixed for the release, because it's causing
code that formerly compiled with clang to fail.

-- 
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 llvm.org  Sat Mar 13 12:31:23 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 13 Mar 2010 12:31:23 -0600 (CST)
Subject: [LLVMbugs] [Bug 6562] Crash due to missing destructor
In-Reply-To: <bug-6562-206@http.llvm.org/bugs/>
References: <bug-6562-206@http.llvm.org/bugs/>
Message-ID: <20100313183123.442752A6C12E@llvm.org>

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

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

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

--- Comment #4 from Rafael ?vila de Esp?ndola <rafael.espindola at gmail.com> 2010-03-13 12:31:22 CST ---
Fixed in r98440

-- 
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 llvm.org  Sat Mar 13 16:20:56 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 13 Mar 2010 16:20:56 -0600 (CST)
Subject: [LLVMbugs] [Bug 6610] New: rejects valid friend declaration
Message-ID: <bug-6610-206@http.llvm.org/bugs/>

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

           Summary: rejects valid friend declaration
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: rafael.espindola at gmail.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


I am almost sure this is valid c++:

template<typename T> struct C {
  class X;
  friend class C<T>::X;
};

but clang rejects it:

error: template specialization or definition requires a template parameter list
corresponding to the nested type 'C<T>'
  friend class C<T>::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 llvm.org  Sat Mar 13 22:18:30 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 13 Mar 2010 22:18:30 -0600 (CST)
Subject: [LLVMbugs] [Bug 6578] Explicit template instantiations should have
	weak linkage
In-Reply-To: <bug-6578-206@http.llvm.org/bugs/>
References: <bug-6578-206@http.llvm.org/bugs/>
Message-ID: <20100314041830.3E3072A6C12F@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #5 from Douglas Gregor <dgregor at apple.com> 2010-03-13 22:18:29 CST ---
Fixed in r98441.

-- 
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 llvm.org  Sat Mar 13 22:22:15 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 13 Mar 2010 22:22:15 -0600 (CST)
Subject: [LLVMbugs] [Bug 6593] False error: use of undeclared identifier
	'address'
In-Reply-To: <bug-6593-206@http.llvm.org/bugs/>
References: <bug-6593-206@http.llvm.org/bugs/>
Message-ID: <20100314042215.55FDC2A6C12E@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #2 from Douglas Gregor <dgregor at apple.com> 2010-03-13 22:22:14 CST ---
Clang is correct in rejecting this code. As the note says, you need to qualify
the call to address, because name lookup doesn't look in dependent base
classes. This is two-phase name lookup, which GCC doesn't implement properly
but Clang does.

-- 
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 llvm.org  Sat Mar 13 22:25:17 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 13 Mar 2010 22:25:17 -0600 (CST)
Subject: [LLVMbugs] [Bug 6592] False error: concerning: cannot combine with
 previous 'extern' declaration specifier
In-Reply-To: <bug-6592-206@http.llvm.org/bugs/>
References: <bug-6592-206@http.llvm.org/bugs/>
Message-ID: <20100314042517.4743C2A6C124@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #1 from Douglas Gregor <dgregor at apple.com> 2010-03-13 22:25:16 CST ---
Clang is treating linkage specifications as storage-class-specifiers.

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

-- 
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 llvm.org  Sat Mar 13 22:28:15 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 13 Mar 2010 22:28:15 -0600 (CST)
Subject: [LLVMbugs] [Bug 6565] Assertion failed: incorrect data size
 provided to CreateTypeSourceInfo!
In-Reply-To: <bug-6565-206@http.llvm.org/bugs/>
References: <bug-6565-206@http.llvm.org/bugs/>
Message-ID: <20100314042815.5FF302A6C124@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #3 from Douglas Gregor <dgregor at apple.com> 2010-03-13 22:28:14 CST ---
John fixed this with his re-working of injected-class-name types.

-- 
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 llvm.org  Sat Mar 13 22:36:15 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 13 Mar 2010 22:36:15 -0600 (CST)
Subject: [LLVMbugs] [Bug 6566] Assertion failed: should always have a
 canonical type here
In-Reply-To: <bug-6566-206@http.llvm.org/bugs/>
References: <bug-6566-206@http.llvm.org/bugs/>
Message-ID: <20100314043615.D56012A6C124@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #3 from Douglas Gregor <dgregor at apple.com> 2010-03-13 22:36:15 CST ---
We've had some recent fixes in this area, and I can't reproduce this bug with
either a Darwin or Linux 64-bit target. Please try again with an updated Clang,
and reopen this bug if it still fails for you. Also, if it's still failing,
please show the output of 

  clang++ -c aap.cxx -###

so we can get all of the target configuration information.

-- 
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 llvm.org  Sun Mar 14 00:23:16 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 14 Mar 2010 00:23:16 -0600 (CST)
Subject: [LLVMbugs] [Bug 6611] New: (PR5718 is closed) Assertion failed:
 (ExprType->isFunctionType() && "Unknown scalar value"),
 function EmitLoadOfLValue, file CGExpr.cpp, line 579.
Message-ID: <bug-6611-206@http.llvm.org/bugs/>

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

           Summary: (PR5718 is closed) Assertion failed:
                    (ExprType->isFunctionType() && "Unknown scalar
                    value"), function EmitLoadOfLValue, file CGExpr.cpp,
                    line 579.
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: FreeBSD
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: nms+llvm at otdel-1.org
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


Is it the same as in PR5718? Source line number is different.

Assertion failed: (ExprType->isFunctionType() && "Unknown scalar value"),
function EmitLoadOfLValue, file CGExpr.cpp, line 579.
Stack dump:
0.      Program arguments: /usr/local/bin/clang -cc1 -triple
i386-portbld-freebsd8.0 -S -disable-free -main-file-name tiffimage.cpp
-pic-level 2 -mdisable-fp-elim -mconstructor-aliases -target-cpu pentium4
-resource-dir /usr/local/lib/clang/1.1 -DEXV_BUILDING_LIB -DEXV_HAVE_DLL
-DEXV_HAVE_STDINT_H -I/usr/home/nms/9bsd/exiv2/build
-I/usr/home/nms/9bsd/exiv2/xmpsdk/include -I/usr/local/include -Wall
-Wcast-align -Wpointer-arith -Wformat-security -Wmissing-format-attribute
-Woverloaded-virtual -W -fmessage-length 144 -fexceptions -fgnu-runtime
-fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-WaLqK0.s -x c++
/usr/home/nms/9bsd/exiv2/src/tiffimage.cpp
1.      <eof> parser at end of file
2.      Per-file LLVM IR generation
3.      /usr/home/nms/9bsd/exiv2/src/tiffcomposite_int.hpp:1522:28: Generating
code for declaration 'Exiv2::Internal::newTiffBinaryArray0'
4.      /usr/home/nms/9bsd/exiv2/src/tiffcomposite_int.hpp:1523:5: LLVM IR
generation of compound statement ('{}')
clang: error: compiler command failed due to signal 6 (use -v to see
invocation)
*** Error code 250

-- 
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 llvm.org  Sun Mar 14 03:28:44 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 14 Mar 2010 03:28:44 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6612] New: UNREACHABLE executed! in X86 DAG->DAG
	isel
Message-ID: <bug-6612-206@http.llvm.org/bugs/>

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

           Summary: UNREACHABLE executed! in X86 DAG->DAG isel
           Product: new-bugs
           Version: 2.6
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: eschew at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=4513)
 --> (http://llvm.org/bugs/attachment.cgi?id=4513)
Minimal testcase for X86 DAG->DAG isel crash

This crashes llc:

%Counter = type { %tuple1 (i8*)*, i8* }
%tuple1 = type { i32, %Counter }

define %tuple1 @foo() nounwind readonly {
entry:
  ret %tuple1 undef
}


I tested with version 2.6 installed via macports, and I also confirmed that the
same behavior happens on Ubuntu with the 2.6 Linux x86 binaries from the
Releases page.

Attached is the full minimal testcase.

Here's the full backtrace:

2010-03-14 04:22:08 ~/Code/fxc/ $ llc bad2.bc
UNREACHABLE executed!
0   llc               0x00a2ba78 std::_Rb_tree<llvm::sys::Path,
llvm::sys::Path, std::_Identity<llvm::sys::Path>, std::less<llvm::sys::Path>,
std::allocator<llvm::sys::Path> >::insert_unique(llvm::sys::Path const&) + 8696
1   llc               0x00a2c2b8 std::_Rb_tree<llvm::sys::Path,
llvm::sys::Path, std::_Identity<llvm::sys::Path>, std::less<llvm::sys::Path>,
std::allocator<llvm::sys::Path> >::insert_unique(llvm::sys::Path const&) +
10808
2   libSystem.B.dylib 0x9736f2bb _sigtramp + 43
3   libSystem.B.dylib 0xffffffff _sigtramp + 1758006639
4   libSystem.B.dylib 0x973e323a raise + 26
5   libSystem.B.dylib 0x973ef679 abort + 73
6   llc               0x00a08a13
llvm::ConstantRange::ConstantRange(llvm::ConstantRange const&) + 10931
7   llc               0x00530463
llvm::RegisterTargetMachine<llvm::X86_64TargetMachine>::Allocator(llvm::Target
const&, std::string const&, std::string const&) + 1619
8   llc               0x004fa086 (anonymous
namespace)::X86FastISel::FastEmit_rr(llvm::MVT, llvm::MVT, llvm::ISD::NodeType,
unsigned int, unsigned int) + 1305974
9   llc               0x00685a8e llvm::APInt::getHighBitsSet(unsigned int,
unsigned int) + 273438
10  llc               0x00685ec3 llvm::APInt::getHighBitsSet(unsigned int,
unsigned int) + 274515
11  llc               0x00692b11
llvm::TargetLowering::getNumRegisters(llvm::LLVMContext&, llvm::EVT) const +
17345
12  llc               0x00693e91
llvm::TargetLowering::getNumRegisters(llvm::LLVMContext&, llvm::EVT) const +
22337
13  llc               0x006954b6
llvm::TargetLowering::getNumRegisters(llvm::LLVMContext&, llvm::EVT) const +
28006
14  llc               0x007580df std::vector<llvm::MachineJumpTableEntry,
std::allocator<llvm::MachineJumpTableEntry>
>::_M_insert_aux(__gnu_cxx::__normal_iterator<llvm::MachineJumpTableEntry*,
std::vector<llvm::MachineJumpTableEntry,
std::allocator<llvm::MachineJumpTableEntry> > >, llvm::MachineJumpTableEntry
const&) + 1631
15  llc               0x0099cda5 llvm::FunctionPass::~FunctionPass() + 34821
16  llc               0x0099d080 llvm::FunctionPass::~FunctionPass() + 35552
17  llc               0x0099d298 llvm::FunctionPass::~FunctionPass() + 36088
18  llc               0x00003ef9 _mh_execute_header + 12025
19  llc               0x00001c36 _mh_execute_header + 3126
20  llc               0x00000002 _mh_execute_header + 18446744073709547522
Stack dump:
0.    Program arguments: llc bad2.bc 
1.    Running pass 'X86 DAG->DAG Instruction Selection' on function '@foo'
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 llvm.org  Sun Mar 14 03:36:48 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 14 Mar 2010 03:36:48 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6612] UNREACHABLE executed! in X86 DAG->DAG isel
In-Reply-To: <bug-6612-206@http.llvm.org/bugs/>
References: <bug-6612-206@http.llvm.org/bugs/>
Message-ID: <20100314083649.1FDC42A6C12C@llvm.org>

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

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

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

--- Comment #1 from Anton Korobeynikov <asl at math.spbu.ru> 2010-03-14 03:36:48 CDT ---
This was fixed after 2.6

-- 
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 llvm.org  Sun Mar 14 04:55:42 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 14 Mar 2010 04:55:42 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6613] New: doxygen is broken from objdir build
Message-ID: <bug-6613-206@http.llvm.org/bugs/>

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

           Summary: doxygen is broken from objdir build
           Product: clang
           Version: trunk
          Platform: Macintosh
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Documentation
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: mikem.llvm at gmail.com
                CC: llvmbugs at cs.uiuc.edu


cd obj/tools/clang/docs
make regendoc
-or-
make generated BUILD_FOR_WEBSITE=1

Both fail immediately. If a build is configured from PROJ_SRC_ROOT (no objdir)
the docs are generated. 

Also there are a few problems such as doxygen.cfg is checked into repo and
looking at the dated doxygen.cfg.in file it's pretty clear this stuff is in
need of some TLC.

-- 
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 llvm.org  Sun Mar 14 11:51:47 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 14 Mar 2010 11:51:47 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6609] Namelookup done for unused parameter names
In-Reply-To: <bug-6609-206@http.llvm.org/bugs/>
References: <bug-6609-206@http.llvm.org/bugs/>
Message-ID: <20100314165147.86F6D2A6C124@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dgregor at apple.com,
                   |                            |llvmbugs at cs.uiuc.edu
          Component|Frontend                    |C++

-- 
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 llvm.org  Sun Mar 14 12:54:31 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 14 Mar 2010 12:54:31 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6608] Address of label regression
In-Reply-To: <bug-6608-206@http.llvm.org/bugs/>
References: <bug-6608-206@http.llvm.org/bugs/>
Message-ID: <20100314175431.70B6A2A6C12C@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #5 from Chris Lattner <clattner at apple.com> 2010-03-14 12:54:30 CDT ---
Fixed here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20100308/097830.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 llvm.org  Sun Mar 14 12:55:01 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 14 Mar 2010 12:55:01 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6614] New: SSE intrinsics: _mm_setpd and
	_mm_setr_pd backwards
Message-ID: <bug-6614-206@http.llvm.org/bugs/>

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

           Summary: SSE intrinsics: _mm_setpd and _mm_setr_pd backwards
           Product: clang
           Version: 2.6
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: jed at 59a2.org
                CC: llvmbugs at cs.uiuc.edu


$ cat c.c
#include <stdio.h>
#include <emmintrin.h>
int main(void) {
  double a[2],b[2];
  __m128d x = _mm_set_pd(2,3), y = _mm_setr_pd(5,7);
  _mm_storeu_pd(a,x);
  _mm_storeu_pd(b,y);
  printf("%f %f\n",a[0],a[1]);
  printf("%f %f\n",b[0],b[1]);
  return 0;
}
$ gcc -march=core2 c.c && ./a.out     # correct
3.000000 2.000000
5.000000 7.000000
$ clang -march=core2 c.c && ./a.out   # wrong
2.000000 3.000000
7.000000 5.000000
$ clang --version
clang version 1.0 (https://llvm.org/svn/llvm-project/cfe/branches/release_26 )
Target: x86_64-unknown-linux-gnu
Thread model: posix
$ uname -a
Linux kunyang 2.6.32-ARCH #1 SMP PREEMPT Tue Feb 23 19:43:46 CET 2010 x86_64
Intel(R) Core(TM)2 Duo CPU P8700 @ 2.53GHz GenuineIntel GNU/Linux

-- 
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 llvm.org  Sun Mar 14 12:56:11 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 14 Mar 2010 12:56:11 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6614] SSE intrinsics: _mm_set_pd and _mm_setr_pd
	backwards
In-Reply-To: <bug-6614-206@http.llvm.org/bugs/>
References: <bug-6614-206@http.llvm.org/bugs/>
Message-ID: <20100314175612.0163A2A6C124@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #1 from Chris Lattner <clattner at apple.com> 2010-03-14 12:56:11 CDT ---
This is already fixed on mainline, plz try 2.7

-- 
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 llvm.org  Sun Mar 14 13:32:32 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 14 Mar 2010 13:32:32 -0500 (CDT)
Subject: [LLVMbugs] [Bug 4841] [x86] cmov generated even on -mcpu=pentium
In-Reply-To: <bug-4841-206@http.llvm.org/bugs/>
References: <bug-4841-206@http.llvm.org/bugs/>
Message-ID: <20100314183232.F1E542A6C12D@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #8 from Chris Lattner <clattner at apple.com> 2010-03-14 13:32:32 CDT ---
Sorry for the delay, this got buried in my email.  The patch looks great,
applied here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20100308/097831.html

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 llvm.org  Sun Mar 14 13:35:20 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 14 Mar 2010 13:35:20 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6606] ice: replaceAllUses of value with new value
 of different type!
In-Reply-To: <bug-6606-206@http.llvm.org/bugs/>
References: <bug-6606-206@http.llvm.org/bugs/>
Message-ID: <20100314183520.0C7F02A6C12D@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #2 from Chris Lattner <clattner at apple.com> 2010-03-14 13:35:19 CDT ---
I think this was fixed a couple days ago for one of your other PRs, it doesn't
repro for me.  If it still repros for you, please reopen.

-- 
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 llvm.org  Sun Mar 14 13:42:14 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 14 Mar 2010 13:42:14 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6615] New: legal var decl is reported as error
Message-ID: <bug-6615-206@http.llvm.org/bugs/>

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

           Summary: legal var decl is reported as error
           Product: clang
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: mikem.llvm at gmail.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


Created an attachment (id=4517)
 --> (http://llvm.org/bugs/attachment.cgi?id=4517)
reduction: foo.cpp

namespace xx {
  int m; 
}
namespace yy {
  int m; 
}

using namespace xx;
using namespace yy;

void foo() {
  int m; 
}

//////////////////////////////////////////////////////////////////////

error: reference to 'm' is ambiguous
foo.cpp:2:7: note: candidate found by name lookup is 'xx::m'
  int m;
      ^
foo.cpp:5:7: note: candidate found by name lookup is 'yy::m'
  int m;
      ^
3 diagnostics generated.

-- 
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 llvm.org  Sun Mar 14 13:45:06 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 14 Mar 2010 13:45:06 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6605] ice: Cannot use this version of
	ReplaceAllUsesWith!
In-Reply-To: <bug-6605-206@http.llvm.org/bugs/>
References: <bug-6605-206@http.llvm.org/bugs/>
Message-ID: <20100314184506.1BB9D2A6C12D@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #2 from Chris Lattner <clattner at apple.com> 2010-03-14 13:45:05 CDT ---
Fixed here, thanks!
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20100308/097842.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 llvm.org  Sun Mar 14 13:51:36 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 14 Mar 2010 13:51:36 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6601] Generic codegen tests that need -march=x86,
 and fail on ppc
In-Reply-To: <bug-6601-206@http.llvm.org/bugs/>
References: <bug-6601-206@http.llvm.org/bugs/>
Message-ID: <20100314185136.3A8882A6C12D@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #1 from Chris Lattner <clattner at apple.com> 2010-03-14 13:51:35 CDT ---
This should be fixed in r98508, if not, please reopen with remaining failures.

-- 
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 llvm.org  Sun Mar 14 14:05:22 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 14 Mar 2010 14:05:22 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6615] legal var decl is reported as error
In-Reply-To: <bug-6615-206@http.llvm.org/bugs/>
References: <bug-6615-206@http.llvm.org/bugs/>
Message-ID: <20100314190522.E39E12A6C12D@llvm.org>

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

mikem.llvm at gmail.com changed:

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

--- Comment #1 from mikem.llvm at gmail.com 2010-03-14 14:05:22 CDT ---
invalid.
sorry for the noise. I used polluted working dir. another bugfix in progress
created this issue.

-- 
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 llvm.org  Sun Mar 14 14:46:19 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 14 Mar 2010 14:46:19 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6607] SDISel:ShrinkDemandedOps leaves around dead
	nodes
In-Reply-To: <bug-6607-206@http.llvm.org/bugs/>
References: <bug-6607-206@http.llvm.org/bugs/>
Message-ID: <20100314194619.A3A002A6C12D@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #3 from Chris Lattner <clattner at apple.com> 2010-03-14 14:46:19 CDT ---
Fixed in a series of patches leading up to r98512.

-- 
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 llvm.org  Sun Mar 14 14:59:11 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 14 Mar 2010 14:59:11 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6606] ice: replaceAllUses of value with new value
 of different type!
In-Reply-To: <bug-6606-206@http.llvm.org/bugs/>
References: <bug-6606-206@http.llvm.org/bugs/>
Message-ID: <20100314195912.0EA7E2A6C12C@llvm.org>

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

John Regehr <regehr at cs.utah.edu> changed:

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

--- Comment #4 from John Regehr <regehr at cs.utah.edu> 2010-03-14 14:59:11 CDT ---
Chris I still see the problem with r97208, same crash with both clang and 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 llvm.org  Sun Mar 14 15:02:42 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 14 Mar 2010 15:02:42 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6606] ice: replaceAllUses of value with new value
 of different type!
In-Reply-To: <bug-6606-206@http.llvm.org/bugs/>
References: <bug-6606-206@http.llvm.org/bugs/>
Message-ID: <20100314200243.117932A6C12C@llvm.org>

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

John Regehr <regehr at cs.utah.edu> changed:

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

--- Comment #5 from John Regehr <regehr at cs.utah.edu> 2010-03-14 15:02:42 CDT ---
Nevermind, sorry, wasn't running the version I wanted to 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 llvm.org  Sun Mar 14 15:39:30 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 14 Mar 2010 15:39:30 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6616] New: Warnings building LLVM 2.7
Message-ID: <bug-6616-206@http.llvm.org/bugs/>

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

           Summary: Warnings building LLVM 2.7
           Product: new-bugs
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: baldrick at free.fr
                CC: llvmbugs at cs.uiuc.edu


On x86-32 linux, with gcc-4.2 (release build):

llvm-2.7/lib/Support/regexec.c: In function 'llvm_regexec':
llvm-2.7/llvm-2.7/lib/Support/regexec.c:158: warning: passing argument 2 of
'smatcher' discards qualifiers from pointer target type
llvm-2.7/lib/Support/regexec.c:160: warning: passing argument 2 of 'lmatcher'
discards qualifiers from pointer target type


llvm-2.7/include/llvm/ADT/ilist.h: In member function 'void
llvm::MSILWriter::printLocalVariables(const llvm::Function&)':
llvm-2.7/include/llvm/ADT/ilist.h:173: warning: 'this.851' is used
uninitialized in this function
llvm-2.7/include/llvm/ADT/ilist.h:173: note: 'this.851' was declared here
llvm-2.7/include/llvm/ADT/ilist.h:173: warning: 'this.851' is used
uninitialized in this function
llvm-2.7/include/llvm/ADT/ilist.h:173: note: 'this.851' was declared here

plus a bunch of variations of this when compiling other files.

As usual, there are also lots of warnings while compiling clang.

-- 
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 llvm.org  Sun Mar 14 18:11:55 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 14 Mar 2010 18:11:55 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6617] New: [cppcheck] found a resource leak in
 llvm/lib/System/Unix/Program.inc
Message-ID: <bug-6617-206@http.llvm.org/bugs/>

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

           Summary: [cppcheck] found a resource leak in
                    llvm/lib/System/Unix/Program.inc
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: System Library
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: ettl.martin at gmx.de
                CC: llvmbugs at cs.uiuc.edu


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

during a check with the static code analysis tool cppcheck, the tool discovered
a resource leak in llvm/lib/System/Unix/Program.inc

Please refer the attached patch that fixes the issue

Best regards

Ettl Martin

-- 
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 llvm.org  Sun Mar 14 18:17:17 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 14 Mar 2010 18:17:17 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6617] [cppcheck] found a resource leak in
 llvm/lib/System/Unix/Program.inc
In-Reply-To: <bug-6617-206@http.llvm.org/bugs/>
References: <bug-6617-206@http.llvm.org/bugs/>
Message-ID: <20100314231717.E54042A6C12C@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #1 from Chris Lattner <clattner at apple.com> 2010-03-14 18:17:17 CDT ---
Thanks, applied here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20100308/097864.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 llvm.org  Sun Mar 14 21:01:03 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 14 Mar 2010 21:01:03 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6618] New: ASTRecordLayoutBuilder crash on invalid
Message-ID: <bug-6618-206@http.llvm.org/bugs/>

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

           Summary: ASTRecordLayoutBuilder crash on invalid
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: rafael.espindola at gmail.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


testcase:

------------------
template <class C> class foo {
void f() {
enum {
e = sizeof(C) };
};
};
class bar;
struct zed {
  bar g;
};
class baz {
  zed h;
   void X() {
    s.f();
   }
  foo<baz> s;
};
---------------

clang -cc1 -fsyntax-only test.ii

clang/lib/AST/ASTContext.cpp:1188: const clang::ASTRecordLayout&
clang::ASTContext::getASTRecordLayout(const clang::RecordDecl*): Assertion `D
&& "Cannot get
 layout of forward declarations!"' 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 llvm.org  Mon Mar 15 05:14:50 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 15 Mar 2010 05:14:50 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6619] New: Assert - already instantiated this local
Message-ID: <bug-6619-206@http.llvm.org/bugs/>

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

           Summary: Assert - already instantiated this local
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: chris at bubblescope.net
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


This bug blocks boost::spirit (v1.42). While this reduced test is illegal, to
file it is derived from was valid.

-- 
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 llvm.org  Mon Mar 15 05:53:19 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 15 Mar 2010 05:53:19 -0500 (CDT)
Subject: [LLVMbugs] [Bug 3895] IRGen doesn't set the calling convention
 correctly with incomplete function types
In-Reply-To: <bug-3895-206@http.llvm.org/bugs/>
References: <bug-3895-206@http.llvm.org/bugs/>
Message-ID: <20100315105319.68ED72A6C12C@llvm.org>

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

John McCall <rjmccall at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |rjmccall at apple.com
         Resolution|                            |FIXED

--- Comment #1 from John McCall <rjmccall at apple.com> 2010-03-15 05:53:19 CDT ---
Fixed a month or so ago when I did a lot of other CC work;  or at least, I now
see:

  declare void @x()
  ...
    %call = call x86_stdcallcc i32 bitcast (void ()* @x to i32 (i32)*)(i32
%tmp4)

I'm not really sure why @x gets the odd declaration, but the call has the right
CC.

-- 
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 llvm.org  Mon Mar 15 05:55:08 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 15 Mar 2010 05:55:08 -0500 (CDT)
Subject: [LLVMbugs] [Bug 4804] -Wwrite-strings not implemented
In-Reply-To: <bug-4804-206@http.llvm.org/bugs/>
References: <bug-4804-206@http.llvm.org/bugs/>
Message-ID: <20100315105508.8E58A2A6C124@llvm.org>

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

John McCall <rjmccall at apple.com> changed:

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

--- Comment #3 from John McCall <rjmccall at apple.com> 2010-03-15 05:55:08 CDT ---
That seems like a fine way of doing it.  Committed as r98541, 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 llvm.org  Mon Mar 15 06:54:48 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 15 Mar 2010 06:54:48 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6620] New: Unnamed namespace problem
Message-ID: <bug-6620-206@http.llvm.org/bugs/>

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

           Summary: Unnamed namespace problem
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: chris at bubblescope.net
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


Created an attachment (id=4522)
 --> (http://llvm.org/bugs/attachment.cgi?id=4522)
unnamed namespace example

The attached code compiles in g++, but not in clang++.

Note that the following does compile, where we do not close and reopen the
numeric namespace.

This blocks boost::accumulate.

    namespace numeric {
        namespace op {
            struct greater {};
        }
        namespace {
            extern op::greater const greater;
        }

        namespace {
            op::greater const greater = op::greater();
        }

            template<typename T, typename U>
            int f(T& l, U& r)
            { numeric::greater(l, r); }

    }

-- 
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 llvm.org  Mon Mar 15 09:28:58 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 15 Mar 2010 09:28:58 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6621] New: Assertion in boost code
Message-ID: <bug-6621-206@http.llvm.org/bugs/>

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

           Summary: Assertion in boost code
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: chris at bubblescope.net
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


The following code causes an assert in the compiler. It is extracted from boost
and compiles fine on g++. The problem goes away if the
__attribute__((noreturn)) is removed, or the static member of
failed_rangecheck.

Code:

namespace std {

    template<typename _CharT>     class basic_string     {
        public:       inline       basic_string();
    };
    typedef basic_string<char> string;
}
namespace boost {
    template<class E> __attribute__((noreturn)) inline void throw_exception( E
const & e );
    template<class T, int N>     struct array {
        static T failed_rangecheck () {
            boost::throw_exception(1);
            static T placeholder;
        }
    };
}
int main() {
    boost::array<std::string, 0> x;
    x.failed_rangecheck();
}

Backtrace:

~/temp2$ clang++ t.cc -c
While deleting: label %init.check
Use still stuck around after Def is destroyed:  br i1 %tobool, label
%init.check, label %init.end
Assertion failed: (use_empty() && "Uses remain when a value is destroyed!"),
function ~Value, file Value.cpp, line 75.
0  clang             0x00f16125 PrintStackTrace(void*) + 45
1  clang             0x00f1672d SignalHandler(int) + 410
2  libSystem.B.dylib 0x94ee29bb _sigtramp + 43
3  libSystem.B.dylib 0xffffffff _sigtramp + 1796331119
4  libSystem.B.dylib 0x94f7098d raise + 26
5  libSystem.B.dylib 0x94f86a44 abort + 93
6  libSystem.B.dylib 0x94f735ec __pthread_markcancel + 0
7  clang             0x00eae547 llvm::Value::~Value() + 445
8  clang             0x00df3b85 llvm::BasicBlock::~BasicBlock() + 407
9  clang             0x00e3e27e
llvm::ilist_node_traits<llvm::BasicBlock>::deleteNode(llvm::BasicBlock*) + 30
10 clang             0x00e3e8e4 llvm::iplist<llvm::BasicBlock,
llvm::ilist_traits<llvm::BasicBlock>
>::erase(llvm::ilist_iterator<llvm::BasicBlock>) + 32
11 clang             0x00df39ae llvm::BasicBlock::eraseFromParent() + 60
12 clang             0x00be445a (anonymous
namespace)::UnreachableBlockElim::runOnFunction(llvm::Function&) + 646
13 clang             0x00e8bded
llvm::FPPassManager::runOnFunction(llvm::Function&) + 275
14 clang             0x00e8da38
llvm::FunctionPassManagerImpl::run(llvm::Function&) + 80
15 clang             0x00e8dc09 llvm::FunctionPassManager::run(llvm::Function&)
+ 135
16 clang             0x00044b0a (anonymous
namespace)::BackendConsumer::EmitAssembly() + 728
17 clang             0x00044bef (anonymous
namespace)::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) + 151
18 clang             0x0024c1b8 clang::ParseAST(clang::Preprocessor&,
clang::ASTConsumer*, clang::ASTContext&, bool, bool,
clang::CodeCompleteConsumer*) + 832
19 clang             0x0006306f clang::ASTFrontendAction::ExecuteAction() + 269
20 clang             0x0006317a clang::FrontendAction::Execute() + 260
21 clang             0x00047a83
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 851
22 clang             0x000294c6 cc1_main(char const**, char const**, char
const*, void*) + 1514
23 clang             0x0002cf37 main + 272
24 clang             0x000282cd start + 53
25 clang             0x0000001c start + 4294802820
Stack dump:
0.    Program arguments: /usr/local/bin/clang -cc1 -triple
i386-apple-darwin10.0.0 -S -disable-free -main-file-name t.cc -pic-level 1
-mdisable-fp-elim -target-cpu yonah -resource-dir /usr/local/lib/clang/1.1
-fmessage-length 116 -stack-protector 1 -fblocks -fexceptions
-fdiagnostics-show-option -fcolor-diagnostics -o
/var/folders/M8/M86fCFVgGQ0r-V2oY5lLC++++TI/-Tmp-/cc-mvuXdZ.s -x c++ t.cc 
1.    <eof> parser at end of file
2.    Code generation
3.    Running pass 'Remove unreachable blocks from the CFG' on function
'@_ZN5boost5arrayISbIcELi0EE17failed_rangecheckEv'
clang: error: compiler command failed due to signal 6 (use -v to see
invocation)

-- 
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 llvm.org  Mon Mar 15 09:33:41 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 15 Mar 2010 09:33:41 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6594] Name lookup of template parameters in
 out-of-line definitions of class members
In-Reply-To: <bug-6594-206@http.llvm.org/bugs/>
References: <bug-6594-206@http.llvm.org/bugs/>
Message-ID: <20100315143341.F3FDA2A6C12E@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #3 from Douglas Gregor <dgregor at apple.com> 2010-03-15 09:33:41 CDT ---
Fixed in r98544.

-- 
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 llvm.org  Mon Mar 15 09:34:43 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 15 Mar 2010 09:34:43 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6594] Name lookup of template parameters in
 out-of-line definitions of class members
In-Reply-To: <bug-6594-206@http.llvm.org/bugs/>
References: <bug-6594-206@http.llvm.org/bugs/>
Message-ID: <20100315143443.E60EA2A6C12E@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #4 from Douglas Gregor <dgregor at apple.com> 2010-03-15 09:34:43 CDT ---
Something is amiss; this isn't fixed. 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 llvm.org  Mon Mar 15 10:27:26 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 15 Mar 2010 10:27:26 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6594] Name lookup of template parameters in
 out-of-line definitions of class members
In-Reply-To: <bug-6594-206@http.llvm.org/bugs/>
References: <bug-6594-206@http.llvm.org/bugs/>
Message-ID: <20100315152726.4EDAA2A6C12E@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #5 from Douglas Gregor <dgregor at apple.com> 2010-03-15 10:27:25 CDT ---
Fixed for real in r98546.

-- 
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 llvm.org  Mon Mar 15 11:12:54 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 15 Mar 2010 11:12:54 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6622] New: Assertion failed: Invalid
 GetElementPtrInst indices for type!
Message-ID: <bug-6622-206@http.llvm.org/bugs/>

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

           Summary: Assertion failed: Invalid GetElementPtrInst indices
                    for type!
           Product: clang
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: Fons.Rademakers at cern.ch
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


Created an attachment (id=4523)
 --> (http://llvm.org/bugs/attachment.cgi?id=4523)
Source file exhibiting the problem

Compiling the attached file with clang++ -c aap.cxx gives:

(proof) [137] clang++ -c aap.cxx
Assertion failed: (Ty && "Invalid GetElementPtrInst indices for type!"),
function checkType, file /Users/rdm/llvm/src/include/llvm/Instructions.h, line
276.
0  clang             0x0000000100d5b628 PrintStackTrace(void*) + 38
1  clang             0x0000000100d5bbb6 SignalHandler(int) + 336
2  libSystem.B.dylib 0x00007fff88a66eaa _sigtramp + 26
3  libSystem.B.dylib 0x00007fff5fbf9f30 _sigtramp + 3608752288
4  libSystem.B.dylib 0x00007fff88ae2e74 __pthread_markcancel + 0
5  clang             0x0000000100b1b66c llvm::checkType(llvm::Type const*) + 59
6  clang             0x0000000100b2863d
llvm::GetElementPtrInst::GetElementPtrInst<llvm::Value**>(llvm::Value*,
llvm::Value**, llvm::Value**, unsigned int, llvm::Twine const&,
llvm::Instruction*) + 135
7  clang             0x0000000100b28726 llvm::GetElementPtrInst*
llvm::GetElementPtrInst::Create<llvm::Value**>(llvm::Value*, llvm::Value**,
llvm::Value**, llvm::Twine const&, llvm::Instruction*) + 121
8  clang             0x0000000100b28768 llvm::GetElementPtrInst*
llvm::GetElementPtrInst::CreateInBounds<llvm::Value**>(llvm::Value*,
llvm::Value**, llvm::Value**, llvm::Twine const&, llvm::Instruction*) + 56
9  clang             0x00000001001a6da0 llvm::IRBuilder<true,
llvm::ConstantFolder, llvm::IRBuilderDefaultInserter<true>
>::CreateConstInBoundsGEP2_32(llvm::Value*, unsigned int, unsigned int,
llvm::Twine const&) + 214
10 clang             0x00000001001a6df3 llvm::IRBuilder<true,
llvm::ConstantFolder, llvm::IRBuilderDefaultInserter<true>
>::CreateStructGEP(llvm::Value*, unsigned int, llvm::Twine const&) + 51
11 clang             0x000000010017618a
clang::CodeGen::CodeGenFunction::EmitLValueForField(llvm::Value*,
clang::FieldDecl const*, unsigned int) + 196
12 clang             0x0000000100176358
clang::CodeGen::CodeGenFunction::EmitLValueForFieldInitialization(llvm::Value*,
clang::FieldDecl const*, unsigned int) + 92
13 clang             0x000000010015ba2b
clang::CodeGen::CodeGenFunction::SynthesizeCXXCopyConstructor(llvm::SmallVector<std::pair<clang::VarDecl
const*, clang::QualType>, 16u> const&) + 1333
14 clang             0x000000010015be6b
clang::CodeGen::CodeGenFunction::EmitConstructorBody(llvm::SmallVector<std::pair<clang::VarDecl
const*, clang::QualType>, 16u>&) + 507
15 clang             0x00000001002060dd
clang::CodeGen::CodeGenFunction::GenerateCode(clang::CodeGen::GlobalDecl,
llvm::Function*) + 1455
16 clang             0x000000010014d99c
clang::CodeGen::CodeGenModule::EmitCXXConstructor(clang::CXXConstructorDecl
const*, clang::CXXCtorType) + 316
17 clang             0x000000010020ee26
clang::CodeGen::CodeGenModule::EmitGlobalDefinition(clang::CodeGen::GlobalDecl)
+ 460
18 clang             0x000000010020f83b
clang::CodeGen::CodeGenModule::EmitDeferred() + 289
19 clang             0x000000010020fa41
clang::CodeGen::CodeGenModule::Release() + 21
20 clang             0x0000000100228ce5 (anonymous
namespace)::CodeGeneratorImpl::HandleTranslationUnit(clang::ASTContext&) + 91
21 clang             0x000000010003b325 (anonymous
namespace)::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) + 97
22 clang             0x0000000100235de4 clang::ParseAST(clang::Preprocessor&,
clang::ASTConsumer*, clang::ASTContext&, bool, bool,
clang::CodeCompleteConsumer*) + 776
23 clang             0x000000010005a7f8
clang::ASTFrontendAction::ExecuteAction() + 256
24 clang             0x000000010005a8e8 clang::FrontendAction::Execute() + 226
25 clang             0x000000010003e488
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 726
26 clang             0x000000010001e980 cc1_main(char const**, char const**,
char const*, void*) + 1296
27 clang             0x0000000100022719 main + 252
28 clang             0x000000010001d958 start + 52
29 clang             0x000000000000001d start + 4294846201
Stack dump:
0.      Program arguments: /Users/rdm/llvm/inst/bin/clang -cc1 -triple
x86_64-apple-darwin10.0.0 -S -disable-free -main-file-name aap.cxx -pic-level 1
-mdisable-fp-elim -munwind-tables -target-cpu core2 -resource-dir
/Users/rdm/llvm/inst/lib/clang/1.1 -fmessage-length 80 -stack-protector 1
-fblocks -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o
/var/folders/zK/zKJDfZztH5upJbZEL05q7U+++TI/-Tmp-/cc-a8SXXZ.s -x c++ aap.cxx 
1.      <eof> parser at end of file
2.      Per-file LLVM IR generation
3.      include/Math/FitMethodFunction.h:34:7: Generating code for declaration
'ROOT::Math::BasicFitMethodFunction<ROOT::Math::IGradientFunctionMultiDim>::BasicFitMethodFunction'
clang: error: compiler command failed due to signal 6 (use -v to see
invocation)


With g++ all is fine.

Cheers, Fons.

-- 
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 llvm.org  Mon Mar 15 11:48:18 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 15 Mar 2010 11:48:18 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6566] Assertion failed: should always have a
 canonical type here
In-Reply-To: <bug-6566-206@http.llvm.org/bugs/>
References: <bug-6566-206@http.llvm.org/bugs/>
Message-ID: <20100315164818.497E52A6C124@llvm.org>

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

Fons Rademakers <Fons.Rademakers at cern.ch> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|WORKSFORME                  |FIXED

--- Comment #4 from Fons Rademakers <Fons.Rademakers at cern.ch> 2010-03-15 11:48:17 CDT ---
Issue is indeed fixed. Thanks!

Cheers, Fons.

-- 
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 llvm.org  Mon Mar 15 11:52:02 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 15 Mar 2010 11:52:02 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6565] Assertion failed: incorrect data size
 provided to CreateTypeSourceInfo!
In-Reply-To: <bug-6565-206@http.llvm.org/bugs/>
References: <bug-6565-206@http.llvm.org/bugs/>
Message-ID: <20100315165202.1D9392A6C124@llvm.org>

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

Fons Rademakers <Fons.Rademakers at cern.ch> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|WORKSFORME                  |FIXED

--- Comment #4 from Fons Rademakers <Fons.Rademakers at cern.ch> 2010-03-15 11:52:01 CDT ---
This is indeed fixed. Thanks!

Cheers, Fons.

-- 
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 llvm.org  Mon Mar 15 14:01:17 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 15 Mar 2010 14:01:17 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6623] New: clang/llvm expands memcpy thus making
 the resulting code big
Message-ID: <bug-6623-206@http.llvm.org/bugs/>

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

           Summary: clang/llvm expands memcpy thus making the resulting
                    code big
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: FreeBSD
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: X86
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: rdivacky at freebsd.org
                CC: llvmbugs at cs.uiuc.edu


pes delta$ clang -c -std=c99 -fno-inline -Os boot2.c && nm -S boot2.o | grep "t
fsread"

.... warnings ....

000000000000000e 0000000000000112 t fsread
pes delta$ gcc -c -std=c99 -fno-inline -Os boot2.c && nm -S boot2.o | grep "t
fsread"

.... warnings ....

0000000000000000 00000000000000cd t fsread

clang code is MUCH larger.. this is because gcc uses memcpy

        imulq   $120, %rax, %rsi
        movl    $120, %edx
        movl    $dp2.1791, %edi
        addq    %rcx, %rsi
        call    memcpy

while clang unrolls that memcpy:

        movq    112, %rax
        movq    %rax, fsread.dp2+112(%rip)
        movq    104, %rax
        movq    %rax, fsread.dp2+104(%rip)
        movq    96, %rax
        movq    %rax, fsread.dp2+96(%rip)
        movq    88, %rax
        movq    %rax, fsread.dp2+88(%rip)
        movq    80, %rax
        movq    %rax, fsread.dp2+80(%rip)
        movq    72, %rax
        movq    %rax, fsread.dp2+72(%rip)
        movq    64, %rax
        movq    %rax, fsread.dp2+64(%rip)
        movq    56, %rax
        movq    %rax, fsread.dp2+56(%rip)
        movq    48, %rax
        movq    %rax, fsread.dp2+48(%rip)
        movq    40, %rax
        movq    %rax, fsread.dp2+40(%rip)
        movq    32, %rax
        movq    %rax, fsread.dp2+32(%rip)
        movq    24, %rax
        movq    %rax, fsread.dp2+24(%rip)
        movq    16, %rax
        movq    %rax, fsread.dp2+16(%rip)
        movq    0, %rax
        movq    8, %rcx
        movq    %rcx, fsread.dp2+8(%rip)
        movq    %rax, fsread.dp2(%rip)

I need the generated code to be as small as possible and this effectively
prevents me from that. can I turn this optimization off somehow?

note that this happens at -O0 too

-- 
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 llvm.org  Mon Mar 15 15:28:19 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 15 Mar 2010 15:28:19 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6624] New: Ban creation of PCH files from standard
	input
Message-ID: <bug-6624-206@http.llvm.org/bugs/>

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

           Summary: Ban creation of PCH files from standard input
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Driver
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: dgregor at apple.com
                CC: llvmbugs at cs.uiuc.edu


dgregor$ clang -x c-header -o t.h.pch -
<type some code>
<close stdin>
dgregor$

We should complain about creating such PCH files, because they aren't going to
play well when there's no file we can refer back to.

-- 
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 llvm.org  Mon Mar 15 23:53:48 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 15 Mar 2010 23:53:48 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6625] New: Mangler crash
Message-ID: <bug-6625-206@http.llvm.org/bugs/>

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

           Summary: Mangler crash
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: rafael.espindola at gmail.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


testcase:

--------------------
template<class T>
struct foo {
  typedef T X;
};
class bar {
  typedef foo<int> baz;
};
template <class zed>
void f(const typename zed::baz::X&);
void g() {
  f<bar>( 0);
}
-------------------

gdb --args ~/llvm/llvm-build/Debug/bin/clang -cc1 -S content-ads_unittest.ii

...

#0  0x0000000000472a86 in clang::Type::getTypeClass (this=0x0) at
/usr/local/google/home/espindola/llvm/clang/lib/Frontend/../../include/clang/AST/Type.h:788
#1  0x0000000000472c9d in clang::TemplateSpecializationType::classof (T=0x0) at
/usr/local/google/home/espindola/llvm/clang/lib/Frontend/../../include/clang/AST/Type.h:2438
#2  0x000000000047b52d in llvm::isa_impl<clang::TemplateSpecializationType,
clang::Type> (Val=...) at
/usr/local/google/home/espindola/llvm/llvm/include/llvm/Support/Casting.h:54
#3  0x000000000047b547 in
llvm::isa_impl_wrap<clang::TemplateSpecializationType, clang::Type const,
clang::Type const>::doit (Val=...)
    at
/usr/local/google/home/espindola/llvm/llvm/include/llvm/Support/Casting.h:71
#4  0x000000000047b561 in
llvm::isa_impl_cl<clang::Type>::isa<clang::TemplateSpecializationType>
(Val=...) at
/usr/local/google/home/espindola/llvm/llvm/include/llvm/Support/Casting.h:83
#5  0x0000000000590189 in llvm::isa_impl_cl<clang::Type
const>::isa<clang::TemplateSpecializationType> (Val=...) at
/usr/local/google/home/espindola/llvm/llvm/include/llvm/Support/Casting.h:92
#6  0x00000000005901a3 in llvm::isa_impl_cl<clang::Type
const*>::isa<clang::TemplateSpecializationType> (Val=0x0) at
/usr/local/google/home/espindola/llvm/llvm/include/llvm/Support/Casting.h:101
#7  0x00000000005901c0 in llvm::isa<clang::TemplateSpecializationType,
clang::Type const*> (Val=@0x7fffffff9c28) at
/usr/local/google/home/espindola/llvm/llvm/include/llvm/Support/Casting.h:116
#8  0x00000000005926eb in llvm::dyn_cast<clang::TemplateSpecializationType,
clang::Type const*> (Val=@0x7fffffff9c28) at
/usr/local/google/home/espindola/llvm/llvm/include/llvm/Support/Casting.h:226
#9  0x000000000058e4eb in mangleType (this=0x7fffffff9ea0, T=0x2149390) at
/usr/local/google/home/espindola/llvm/clang/lib/CodeGen/Mangle.cpp:1150

-- 
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 llvm.org  Tue Mar 16 06:00:42 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 16 Mar 2010 06:00:42 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6589] ReturnInst::op_iterator behave bad when
	#operands=0
In-Reply-To: <bug-6589-206@http.llvm.org/bugs/>
References: <bug-6589-206@http.llvm.org/bugs/>
Message-ID: <20100316110043.066372A6C12C@llvm.org>

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

Gabor Greif <ggreif at gmail.com> changed:

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

--- Comment #6 from Gabor Greif <ggreif at gmail.com> 2010-03-16 06:00:42 CDT ---
fixed by r98624.

-- 
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 llvm.org  Tue Mar 16 08:07:30 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 16 Mar 2010 08:07:30 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6627] New: llvm doesn't merge adjacent cmps
Message-ID: <bug-6627-206@http.llvm.org/bugs/>

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

           Summary: llvm doesn't merge adjacent cmps
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Keywords: code-quality
          Severity: enhancement
          Priority: P
         Component: Common Code Generator Code
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: benny.kra at gmail.com
                CC: llvmbugs at cs.uiuc.edu, rdivacky at freebsd.org


Test case (by rdivacky):
===

typedef unsigned int uint32_t;
typedef struct {
    unsigned char e_ident[16];
} Elf32_Ehdr;

struct exec {
     uint32_t a_midmag;
     uint32_t a_text;
     uint32_t a_data;
     uint32_t a_bss;
     uint32_t a_syms;
     uint32_t a_entry;
     uint32_t a_trsize;
     uint32_t a_drsize;
};


foo() {
    union {
 struct exec ex;
 Elf32_Ehdr eh;
    } hdr;


   bar(&hdr);    // pretend to fill something in

   // $CC -std=c99 -Os -S stack-compare.c
   // 
   // clang:
   //
   //     callq   bar
   //     cmpb    $127, -32(%rbp)
   //     jne     .LBB1_5
   //     cmpb    $69, -31(%rbp)
   //     jne     .LBB1_5
   //     cmpb    $76, -30(%rbp)
   //     jne     .LBB1_5
   //     cmpb    $70, -29(%rbp)
   //     jne     .LBB1_5
   //     xorb    %al, %al
   //     callq   doo
   //
   // gcc:
   //        call    bar
   //        cmpl    $1179403647, (%esp)
   //        jne     .L5
   //
   // ie. gcc can combine all these into one compare while llvm cant

   if (((hdr.eh).e_ident[0] == 0x7f && (hdr.eh).e_ident[1] == 'E' &&
(hdr.eh).e_ident[2] == 'L' && (hdr.eh).e_ident[3] == 'F')) {
      doo();
   }

}

===
GCC does this transformation because it sees the uint32_t through the union. I
think it could be safely applied to any cmp with a fixed-size stack allocated
array though (GCC doesn't do 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 llvm.org  Tue Mar 16 10:38:39 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 16 Mar 2010 10:38:39 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6628] New: Assertion failed: Calling a function
 with bad signature!
Message-ID: <bug-6628-206@http.llvm.org/bugs/>

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

           Summary: Assertion failed: Calling a function with bad
                    signature!
           Product: clang
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: Fons.Rademakers at cern.ch
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


Created an attachment (id=4530)
 --> (http://llvm.org/bugs/attachment.cgi?id=4530)
Source file exhibiting the problem

Compiling the attached file with clang++ -c aap.cxx gives:

(proof) [577] clang++ -c aap.cxx
Assertion failed: ((NumParams == FTy->getNumParams() || (FTy->isVarArg() &&
NumParams > FTy->getNumParams())) && "Calling a function with bad signature!"),
function init, file /Users/rdm/llvm/src/lib/VMCore/Instructions.cpp, line 307.
0  clang             0x0000000100d5b628 PrintStackTrace(void*) + 38
1  clang             0x0000000100d5bbb6 SignalHandler(int) + 336
2  libSystem.B.dylib 0x00007fff88a66eaa _sigtramp + 26
3  clang             0x00000001001efcf7 (anonymous
namespace)::OldVtableBuilder::GenerateVtableForBase(clang::CXXRecordDecl
const*, long long, bool, bool, bool, bool, int,
std::vector<std::pair<clang::CXXRecordDecl const*, long long>,
std::allocator<std::pair<clang::CXXRecordDecl const*, long long> > >*) + 569
4  libSystem.B.dylib 0x00007fff88ae2e74 __pthread_markcancel + 0
5  clang             0x0000000100c8a45c llvm::CallInst::init(llvm::Value*,
llvm::Value* const*, unsigned int) + 246
6  clang             0x0000000100679a1e void
llvm::CallInst::init<llvm::Value**>(llvm::Value*, llvm::Value**, llvm::Value**,
llvm::Twine const&, std::random_access_iterator_tag) + 88
7  clang             0x000000010067a0d5
llvm::CallInst::CallInst<llvm::Value**>(llvm::Value*, llvm::Value**,
llvm::Value**, llvm::Twine const&, llvm::Instruction*) + 271
8  clang             0x000000010067a148 llvm::CallInst*
llvm::CallInst::Create<llvm::Value**>(llvm::Value*, llvm::Value**,
llvm::Value**, llvm::Twine const&, llvm::Instruction*) + 106
9  clang             0x0000000100154fa1 llvm::CallInst* llvm::IRBuilder<true,
llvm::ConstantFolder, llvm::IRBuilderDefaultInserter<true>
>::CreateCall<llvm::Value**>(llvm::Value*, llvm::Value**, llvm::Value**,
llvm::Twine const&) + 71
10 clang             0x00000001001511ba
clang::CodeGen::CodeGenFunction::EmitCall(clang::CodeGen::CGFunctionInfo
const&, llvm::Value*, clang::CodeGen::ReturnValueSlot,
llvm::SmallVector<std::pair<clang::CodeGen::RValue, clang::QualType>, 16u>
const&, clang::Decl const*) + 2722
11 clang             0x000000010015b4c8
clang::CodeGen::CodeGenFunction::EmitClassMemberwiseCopy(llvm::Value*,
llvm::Value*, clang::CXXRecordDecl const*, clang::CXXRecordDecl const*,
clang::QualType) + 988
12 clang             0x000000010015b70c
clang::CodeGen::CodeGenFunction::SynthesizeCXXCopyConstructor(llvm::SmallVector<std::pair<clang::VarDecl
const*, clang::QualType>, 16u> const&) + 534
13 clang             0x000000010015be6b
clang::CodeGen::CodeGenFunction::EmitConstructorBody(llvm::SmallVector<std::pair<clang::VarDecl
const*, clang::QualType>, 16u>&) + 507
14 clang             0x00000001002060dd
clang::CodeGen::CodeGenFunction::GenerateCode(clang::CodeGen::GlobalDecl,
llvm::Function*) + 1455
15 clang             0x000000010014d99c
clang::CodeGen::CodeGenModule::EmitCXXConstructor(clang::CXXConstructorDecl
const*, clang::CXXCtorType) + 316
16 clang             0x000000010020ee26
clang::CodeGen::CodeGenModule::EmitGlobalDefinition(clang::CodeGen::GlobalDecl)
+ 460
17 clang             0x000000010020f83b
clang::CodeGen::CodeGenModule::EmitDeferred() + 289
18 clang             0x000000010020fa41
clang::CodeGen::CodeGenModule::Release() + 21
19 clang             0x0000000100228ce5 (anonymous
namespace)::CodeGeneratorImpl::HandleTranslationUnit(clang::ASTContext&) + 91
20 clang             0x000000010003b325 (anonymous
namespace)::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) + 97
21 clang             0x0000000100235de4 clang::ParseAST(clang::Preprocessor&,
clang::ASTConsumer*, clang::ASTContext&, bool, bool,
clang::CodeCompleteConsumer*) + 776
22 clang             0x000000010005a7f8
clang::ASTFrontendAction::ExecuteAction() + 256
23 clang             0x000000010005a8e8 clang::FrontendAction::Execute() + 226
24 clang             0x000000010003e488
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 726
25 clang             0x000000010001e980 cc1_main(char const**, char const**,
char const*, void*) + 1296
26 clang             0x0000000100022719 main + 252
27 clang             0x000000010001d958 start + 52
28 clang             0x000000000000001d start + 4294846201
Stack dump:
0.      Program arguments: /Users/rdm/llvm/inst/bin/clang -cc1 -triple
x86_64-apple-darwin10.0.0 -S -disable-free -main-file-name aap.cxx -pic-level 1
-mdisable-fp-elim -munwind-tables -target-cpu core2 -resource-dir
/Users/rdm/llvm/inst/lib/clang/1.1 -fmessage-length 80 -stack-protector 1
-fblocks -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o
/var/folders/zK/zKJDfZztH5upJbZEL05q7U+++TI/-Tmp-/cc-Ym8obY.s -x c++ aap.cxx 
1.      <eof> parser at end of file
2.      Per-file LLVM IR generation
3.      include/TObjectSet.h:27:7: Generating code for declaration
'TObjectSet::TObjectSet'
clang: error: compiler command failed due to signal 6 (use -v to see
invocation)


With g++ all is fine.

Cheers, Fons.

-- 
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 llvm.org  Tue Mar 16 13:57:47 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 16 Mar 2010 13:57:47 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6524] opt -internalize breaks C++ initialization
 (compiling with clang)
In-Reply-To: <bug-6524-206@http.llvm.org/bugs/>
References: <bug-6524-206@http.llvm.org/bugs/>
Message-ID: <20100316185747.171C82A6C12C@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #1 from Chris Lattner <clattner at apple.com> 2010-03-16 13:57:46 CDT ---
This works fine for me, I'll need more information about your configuration
(host OS, libstdc++ version etc).  Also, please include the exact command lines
that you're using.

-- 
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 llvm.org  Tue Mar 16 14:03:35 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 16 Mar 2010 14:03:35 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6508] Forwarding 0 as a pointer using rvalue
 references doesn't work
In-Reply-To: <bug-6508-206@http.llvm.org/bugs/>
References: <bug-6508-206@http.llvm.org/bugs/>
Message-ID: <20100316190335.135BF2A6C12C@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #3 from Chris Lattner <clattner at apple.com> 2010-03-16 14:03:34 CDT ---


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

-- 
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 llvm.org  Tue Mar 16 14:05:15 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 16 Mar 2010 14:05:15 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6505] EquivalenceClasses::ECValue's private
 constructor is inaccessible when combined with a rvalue reference aware
 STL.
In-Reply-To: <bug-6505-206@http.llvm.org/bugs/>
References: <bug-6505-206@http.llvm.org/bugs/>
Message-ID: <20100316190515.756232A6C12F@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #1 from Chris Lattner <clattner at apple.com> 2010-03-16 14:05:15 CDT ---


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

-- 
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 llvm.org  Tue Mar 16 14:07:18 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 16 Mar 2010 14:07:18 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6504] BitVector's copy assignment triggers debug
 assert in MSVC2010
In-Reply-To: <bug-6504-206@http.llvm.org/bugs/>
References: <bug-6504-206@http.llvm.org/bugs/>
Message-ID: <20100316190718.B7F562A6C12C@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #1 from Chris Lattner <clattner at apple.com> 2010-03-16 14:07:18 CDT ---
Fixed in r98653

-- 
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 llvm.org  Tue Mar 16 14:07:59 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 16 Mar 2010 14:07:59 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6509] Compile error results in MSVC not compiling
	llvm.
In-Reply-To: <bug-6509-206@http.llvm.org/bugs/>
References: <bug-6509-206@http.llvm.org/bugs/>
Message-ID: <20100316190759.07E6F2A6C130@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #1 from Chris Lattner <clattner at apple.com> 2010-03-16 14:07:58 CDT ---


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

-- 
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 llvm.org  Tue Mar 16 14:25:22 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 16 Mar 2010 14:25:22 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6629] New: Access != AS_none && "Access specifier
 is AS_none inside a record decl"
Message-ID: <bug-6629-206@http.llvm.org/bugs/>

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

           Summary: Access != AS_none && "Access specifier is AS_none
                    inside a record decl"
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: josephwinston at mac.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


Created an attachment (id=4531)
 --> (http://llvm.org/bugs/attachment.cgi?id=4531)
sample code

Compiled with:
/scratch/jody/src/Languages/LLVM/llvm-read-only/x86_64-unknown-linux-gnu-INSTALL/bin/clang-cc1
-triple x86_64-unknown-linux-gnu -S -disable-free -main-file-name
DataManager.cpp -pic-level 2 -mdisable-fp-elim -mconstructor-aliases
-munwind-tables -target-cpu x86-64 -g -resource-dir
/scratch/jody/src/Languages/LLVM/llvm-read-only/x86_64-unknown-linux-gnu-INSTALL/lib/clang/1.1
/tmp/example1.cpp

-- 
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 llvm.org  Tue Mar 16 14:29:37 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 16 Mar 2010 14:29:37 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6542] Add support for __gcc_tdiag__ format attribute
In-Reply-To: <bug-6542-206@http.llvm.org/bugs/>
References: <bug-6542-206@http.llvm.org/bugs/>
Message-ID: <20100316192937.600442A6C12E@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #2 from Chris Lattner <clattner at apple.com> 2010-03-16 14:29:37 CDT ---
Implemented in r98661

-- 
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 llvm.org  Tue Mar 16 14:39:55 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 16 Mar 2010 14:39:55 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6178] Unaligned loads are created for packed structs
In-Reply-To: <bug-6178-206@http.llvm.org/bugs/>
References: <bug-6178-206@http.llvm.org/bugs/>
Message-ID: <20100316193955.92C6F2A6C12D@llvm.org>

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

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

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

--- Comment #3 from Anton Korobeynikov <asl at math.spbu.ru> 2010-03-16 14:39:55 CDT ---
Yep!

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

-- 
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 llvm.org  Tue Mar 16 15:50:28 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 16 Mar 2010 15:50:28 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6524] opt -internalize breaks C++ initialization
 (compiling with clang)
In-Reply-To: <bug-6524-206@http.llvm.org/bugs/>
References: <bug-6524-206@http.llvm.org/bugs/>
Message-ID: <20100316205028.6938B2A6C12E@llvm.org>

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

Andrew Lenharth <alenhar2 at uiuc.edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
                 CC|                            |alenhar2 at uiuc.edu
         Resolution|WORKSFORME                  |

--- Comment #4 from Andrew Lenharth <alenhar2 at uiuc.edu> 2010-03-16 15:50:28 CDT ---
gcc works.s -lstdc++
./a.out
opt -internalize works.bc -o broken.bc
llc broken.bc
gcc broken.s -lstdc++
./a.out
Segmentation fault


internalize is internalizing weak_odr constants and available_externally
functions.

-- 
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 llvm.org  Tue Mar 16 16:51:42 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 16 Mar 2010 16:51:42 -0500 (CDT)
Subject: [LLVMbugs] [Bug 4805] -Wshadow not implemented
In-Reply-To: <bug-4805-206@http.llvm.org/bugs/>
References: <bug-4805-206@http.llvm.org/bugs/>
Message-ID: <20100316215142.258132A6C12F@llvm.org>

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

John McCall <rjmccall at apple.com> changed:

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

--- Comment #6 from John McCall <rjmccall at apple.com> 2010-03-16 16:51:41 CDT ---
Committed with modifications as r98684-5.  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 llvm.org  Tue Mar 16 19:38:51 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 16 Mar 2010 19:38:51 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6629] Access != AS_none && "Access specifier is
 AS_none inside a record decl"
In-Reply-To: <bug-6629-206@http.llvm.org/bugs/>
References: <bug-6629-206@http.llvm.org/bugs/>
Message-ID: <20100317003851.B77842A6C12E@llvm.org>

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

John McCall <rjmccall at apple.com> changed:

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

--- Comment #1 from John McCall <rjmccall at apple.com> 2010-03-16 19:38:51 CDT ---
Fixed r98698.

-- 
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 llvm.org  Tue Mar 16 21:34:05 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 16 Mar 2010 21:34:05 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6630] New: clang overwrites assembly inputs with
 -save-temps on Darwin
Message-ID: <bug-6630-206@http.llvm.org/bugs/>

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

           Summary: clang overwrites assembly inputs with -save-temps on
                    Darwin
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Driver
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: daniel at zuster.org
                CC: llvmbugs at cs.uiuc.edu


--
ddunbar at ozzy:tmp$ touch t.s
ddunbar at ozzy:tmp$ clang -c -save-temps t.s -###
clang version 1.1 ($URL$ 98691)
Target: x86_64-apple-darwin10
Thread model: posix
 "/Volumes/Data/ddunbar/llvm.obj.64/Debug/bin/clang" "-cc1" "-triple"
"x86_64-apple-darwin10.0.0" "-E" "-disable-free" "-main-file-name" "t.s"
"-pic-level" "1" "-mdisable-fp-elim" "-munwind-tables" "-target-cpu" "core2"
"-resource-dir" "/Volumes/Data/ddunbar/llvm.obj.64/Debug/lib/clang/1.1"
"-fmessage-length" "100" "-stack-protector" "1" "-fblocks"
"-fdiagnostics-show-option" "-o" "t.s" "-x" "assembler-with-cpp" "t.s"
 "/usr/libexec/gcc/i686-apple-darwin10/4.2.1/as" "-arch" "x86_64"
"-force_cpusubtype_ALL" "-o" "t.o" "t.s"
ddunbar at ozzy:tmp$ 
--

-- 
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 llvm.org  Tue Mar 16 23:28:42 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 16 Mar 2010 23:28:42 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6625] Mangler crash
In-Reply-To: <bug-6625-206@http.llvm.org/bugs/>
References: <bug-6625-206@http.llvm.org/bugs/>
Message-ID: <20100317042842.3FBD12A6C12D@llvm.org>

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

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

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

--- Comment #4 from Rafael ?vila de Esp?ndola <rafael.espindola at gmail.com> 2010-03-16 23:28:41 CDT ---
Fixed in 98707

-- 
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 llvm.org  Wed Mar 17 04:27:05 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 17 Mar 2010 04:27:05 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6631] New: Flase error: allocation of an object of
 abstract type 'Polynomial'
Message-ID: <bug-6631-206@http.llvm.org/bugs/>

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

           Summary: Flase error: allocation of an object of  abstract type
                    'Polynomial'
           Product: clang
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: Fons.Rademakers at cern.ch
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


Created an attachment (id=4539)
 --> (http://llvm.org/bugs/attachment.cgi?id=4539)
Source file exhibiting the problem

The attached aap.cxx compiles fine with g++ (and for that matter any other know
compiler), but not with clang++. Do:

clang++ -c aap.cxx
In file included from math/mathmore/src/Polynomial.cxx:1:
math/mathmore/src/Polynomial.cxx:145:26: error: allocation of an object of
      abstract type 'Polynomial'
    Polynomial * f = new Polynomial(fOrder);
                         ^
In file included from math/mathmore/src/Polynomial.cxx:1:
In file included from math/mathmore/src/Polynomial.cxx:32:
In file included from include/Math/Polynomial.h:36:
In file included from include/Math/ParamFunction.h:38:
In file included from include/Math/IParamFunction.h:17:
include/Math/IFunction.h:172:22: note: pure virtual function 'DoEval'
      virtual double DoEval(double x) const = 0;
                     ^
2 diagnostics generated.

Compiles fine with g++.

Cheers, Fons.

-- 
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 llvm.org  Wed Mar 17 04:38:07 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 17 Mar 2010 04:38:07 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6632] New: llvm-gcc (2.7 branch) fails to compile
	with gcc 4.5
Message-ID: <bug-6632-206@http.llvm.org/bugs/>

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

           Summary: llvm-gcc (2.7 branch) fails to compile with gcc 4.5
           Product: tools
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: llvm-gcc
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: bero at arklinux.org
                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 llvm.org  Wed Mar 17 07:53:56 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 17 Mar 2010 07:53:56 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6634] New: Consumes basically all of the virtual
	memory
Message-ID: <bug-6634-206@http.llvm.org/bugs/>

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

           Summary: Consumes basically all of the virtual memory
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: josephwinston at mac.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


/scratch/jody/src/Languages/LLVM/llvm-read-only/x86_64-unknown-linux-gnu-INSTALL/bin/clang-cc1
-triple x86_64-unknown-linux-gnu -S -disable-free -main-file-name
DataManager.cpp -pic-level 2 -mdisable-fp-elim -mconstructor-aliases
-munwind-tables -target-cpu x86-64 -g -resource-dir
/scratch/jody/src/Languages/LLVM/llvm-read-only/x86_64-unknown-linux-gnu-INSTALL/lib/clang/1.1
/tmp/example1.cpp

-- 
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 llvm.org  Wed Mar 17 10:11:43 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 17 Mar 2010 10:11:43 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6633] Crash with break in statement expression in
	for loop
In-Reply-To: <bug-6633-206@http.llvm.org/bugs/>
References: <bug-6633-206@http.llvm.org/bugs/>
Message-ID: <20100317151143.616672A6C12D@llvm.org>

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

Ted Kremenek <kremenek at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kremenek at apple.com,
                   |                            |llvmbugs at cs.uiuc.edu
          Component|Frontend                    |LLVM Codegen

--- Comment #1 from Ted Kremenek <kremenek at apple.com> 2010-03-17 10:11:43 CDT ---
This reproduces with '-c', not '-fsyntax-only':

$ ~/llvm-cmake/bin/clang -c t.c
Assertion failed: (!BreakContinueStack.empty() && "break stmt not in a loop or
switch!"), function EmitBreakStmt, file
/Users/kremenek/llvm/tools/clang/lib/CodeGen/CGStmt.cpp, line 636.
Stack dump:

-- 
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 llvm.org  Wed Mar 17 10:12:58 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 17 Mar 2010 10:12:58 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6635] New: clang does not emit alias to a C++ struct
Message-ID: <bug-6635-206@http.llvm.org/bugs/>

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

           Summary: clang does not emit alias to a C++ struct
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: rdivacky at freebsd.org
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


pes delta$ cat compatibility.cc
             namespace __gnu_cxx __attribute__ ((__visibility__ ("default"))) {
               template<typename _CharT>     struct char_traits     {
               };
             }
              namespace std __attribute__ ((__visibility__ ("default"))) {
               template<class _CharT>     struct char_traits : public
__gnu_cxx::char_traits<_CharT>     {
                 typedef char char_type;
                  static bool       eqXX(const char_type& __c1, const
char_type& __c2)       {
          }
               };
                bool (* __p1)(const char&, const char&) =
&char_traits<char>::eqXX;
            extern "C" void _X_ZNSt11char_traitsIcE2eqERKcS2_() __attribute__
((alias("_ZNSt11char_traitsIcE4eqXXERKcS2_")));
                }


pes delta$ g++ -c compatibility.cc > /dev/null && nm compatibility.o
0000000000000000 T _X_ZNSt11char_traitsIcE2eqERKcS2_
0000000000000000 W _ZNSt11char_traitsIcE4eqXXERKcS2_
0000000000000000 D _ZSt4__p1
                 U __gxx_personality_v0

pes delta$ clang++ -c compatibility.cc > /dev/null && nm compatibility.o
0000000000000000 W _ZNSt11char_traitsIcE4eqXXERKcS2_
                 U _ZNSt11char_traitsIcE4eqXXERKcS2_1
0000000000000000 D _ZSt4__p1

note the missing T _X_ZNSt11char_traitsIcE2eqERKcS2_

-- 
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 llvm.org  Wed Mar 17 10:17:49 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 17 Mar 2010 10:17:49 -0500 (CDT)
Subject: [LLVMbugs] [Bug 4717] [llvm-g++ upstream] Rejects valid c++
In-Reply-To: <bug-4717-206@http.llvm.org/bugs/>
References: <bug-4717-206@http.llvm.org/bugs/>
Message-ID: <20100317151749.B3F2B2A6C124@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #7 from Douglas Gregor <dgregor at apple.com> 2010-03-17 10:17:49 CDT ---
Clang parses this properly; we're not going to end up fixing this in llvm-gcc.

-- 
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 llvm.org  Wed Mar 17 11:04:02 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 17 Mar 2010 11:04:02 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6636] New: x86_64 vararg garbled with very long
	argument list
Message-ID: <bug-6636-206@http.llvm.org/bugs/>

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

           Summary: x86_64 vararg garbled with very long argument list
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: X86
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: benny.kra at gmail.com
                CC: llvmbugs at cs.uiuc.edu


$ cat bug.c
// test by quest (http://code.google.com/p/quest-tester/)
// carefully reduced.

#include <assert.h>
#include <stdarg.h>

struct three {
  int i[3];
};

static int check = 42;

static void foo(int i1, int i2, int i3, int i4, int i5, int i6, struct three
s1, ...) {
  va_list ap;
  va_start(ap, s1);
  int arg = va_arg(ap, int);
  assert(check == arg);
  va_end(ap);
}

int main() {
  struct three s;
  foo(0, 0, 0, 0, 0, 0, s, check);
}

$ gcc bug.c && ./a.out && echo ok
ok
$ clang bug.c && ./a.out && echo ok
Assertion failed: (check == arg), function foo, file bug.c, line 17.
[1]    23350 abort      ./a.out

$ clang --version
clang version 1.1 (trunk 98723)
Target: x86_64-apple-darwin10
Thread model: posix

llvm-gcc seems to have the same problem.

-- 
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 llvm.org  Wed Mar 17 11:42:14 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 17 Mar 2010 11:42:14 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6632] llvm-gcc (2.7 branch) fails to compile with
	gcc 4.5
In-Reply-To: <bug-6632-206@http.llvm.org/bugs/>
References: <bug-6632-206@http.llvm.org/bugs/>
Message-ID: <20100317164214.653572A6C12D@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #3 from Chris Lattner <clattner at apple.com> 2010-03-17 11:42:14 CDT ---
Thanks, applied here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20100315/098019.html

I will request that this be pulled into 2.7

-- 
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 llvm.org  Wed Mar 17 11:45:32 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 17 Mar 2010 11:45:32 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6637] New: SCEVs are allocated with
 BumpPtrAllocator but have members that need destruction
Message-ID: <bug-6637-206@http.llvm.org/bugs/>

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

           Summary: SCEVs are allocated with BumpPtrAllocator but have
                    members that need destruction
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Global Analyses
        AssignedTo: gohman at apple.com
        ReportedBy: jyasskin at google.com
                CC: llvmbugs at cs.uiuc.edu


For example, SCEV is a FastFoldingSetNode, which includes a
SmallVector<unsigned, 32>. SCEVNAryExpr additionally contains a
SmallVector<const SCEV *, 8>.

Example leak report, by running `valgrind --leak-check=full opt ...`:
******************** TEST 'LLVM ::
Analysis/ScalarEvolution/2008-08-04-LongAddRec.ll' FAILED ********************
Script:
--
opt <
/home/jyasskin/llvm/src/test/Analysis/ScalarEvolution/2008-08-04-LongAddRec.ll
-analyze -scalar-evolution    -scalar-evolution-max-iterations=0 | FileCheck
/home/jyasskin/llvm/src/test/Analysis/ScalarEvolution/2008-08-04-LongAddRec.ll
--
Exit Code: 1
Command Output (stdout):
--
Command has output on stderr!

--
Command Output (stderr):
--
==2116== 1,024 bytes in 4 blocks are definitely lost in loss record 265 of 269
==2116==    at 0x4C229C7: operator new(unsigned long) (vg_replace_malloc.c:220)
==2116==    by 0xBDD610: llvm::SmallVectorBase::grow_pod(unsigned long,
unsigned long) (SmallVector.cpp:24)
==2116==    by 0x846A7B: llvm::SmallVectorTemplateBase<unsigned int,
true>::grow(unsigned long) (SmallVector.h:249)
==2116==    by 0x84694D: llvm::SmallVectorImpl<unsigned
int>::operator=(llvm::SmallVectorImpl<unsigned int> const&) (SmallVector.h:619)
==2116==    by 0x9DFBA0: llvm::SmallVector<unsigned int,
32u>::SmallVector(llvm::SmallVector<unsigned int, 32u> const&)
(SmallVector.h:683)
==2116==    by 0x9DF932:
llvm::FoldingSetNodeID::FoldingSetNodeID(llvm::FoldingSetNodeID const&)
(FoldingSet.h:205)
==2116==    by 0x9DF968:
llvm::FastFoldingSetNode::FastFoldingSetNode(llvm::FoldingSetNodeID const&)
(FoldingSet.h:447)
==2116==    by 0xA3EB99: llvm::SCEV::SCEV(llvm::FoldingSetNodeID const&,
unsigned int) (ScalarEvolution.h:68)
==2116==    by 0xA3EF69:
llvm::SCEVNAryExpr::SCEVNAryExpr(llvm::FoldingSetNodeID const&,
llvm::SCEVTypes, llvm::SmallVectorImpl<llvm::SCEV const*> const&)
(ScalarEvolutionExpressions.h:187)
==2116==    by 0xA3F7F1:
llvm::SCEVAddRecExpr::SCEVAddRecExpr(llvm::FoldingSetNodeID const&,
llvm::SmallVectorImpl<llvm::SCEV const*> const&, llvm::Loop const*)
(ScalarEvolutionExpressions.h:394)
==2116==    by 0xA2B454:
llvm::ScalarEvolution::getAddRecExpr(llvm::SmallVectorImpl<llvm::SCEV const*>&,
llvm::Loop const*, bool, bool) (ScalarEvolution.cpp:2034)
==2116==    by 0xA2AD89: llvm::ScalarEvolution::getAddRecExpr(llvm::SCEV
const*, llvm::SCEV const*, llvm::Loop const*, bool, bool)
(ScalarEvolution.cpp:1942)
==2116== 
==2116== 1,024 bytes in 4 blocks are definitely lost in loss record 266 of 269
==2116==    at 0x4C229C7: operator new(unsigned long) (vg_replace_malloc.c:220)
==2116==    by 0xBDD610: llvm::SmallVectorBase::grow_pod(unsigned long,
unsigned long) (SmallVector.cpp:24)
==2116==    by 0x846A7B: llvm::SmallVectorTemplateBase<unsigned int,
true>::grow(unsigned long) (SmallVector.h:249)
==2116==    by 0x84694D: llvm::SmallVectorImpl<unsigned
int>::operator=(llvm::SmallVectorImpl<unsigned int> const&) (SmallVector.h:619)
==2116==    by 0x9DFBA0: llvm::SmallVector<unsigned int,
32u>::SmallVector(llvm::SmallVector<unsigned int, 32u> const&)
(SmallVector.h:683)
==2116==    by 0x9DF932:
llvm::FoldingSetNodeID::FoldingSetNodeID(llvm::FoldingSetNodeID const&)
(FoldingSet.h:205)
==2116==    by 0x9DF968:
llvm::FastFoldingSetNode::FastFoldingSetNode(llvm::FoldingSetNodeID const&)
(FoldingSet.h:447)
==2116==    by 0xA3EB99: llvm::SCEV::SCEV(llvm::FoldingSetNodeID const&,
unsigned int) (ScalarEvolution.h:68)
==2116==    by 0xA3EF69:
llvm::SCEVNAryExpr::SCEVNAryExpr(llvm::FoldingSetNodeID const&,
llvm::SCEVTypes, llvm::SmallVectorImpl<llvm::SCEV const*> const&)
(ScalarEvolutionExpressions.h:187)
==2116==    by 0xA3F7F1:
llvm::SCEVAddRecExpr::SCEVAddRecExpr(llvm::FoldingSetNodeID const&,
llvm::SmallVectorImpl<llvm::SCEV const*> const&, llvm::Loop const*)
(ScalarEvolutionExpressions.h:394)
==2116==    by 0xA2B454:
llvm::ScalarEvolution::getAddRecExpr(llvm::SmallVectorImpl<llvm::SCEV const*>&,
llvm::Loop const*, bool, bool) (ScalarEvolution.cpp:2034)
==2116==    by 0xA28A2A:
llvm::ScalarEvolution::getAddExpr(llvm::SmallVectorImpl<llvm::SCEV const*>&,
bool, bool) (ScalarEvolution.cpp:1588)
==2116== 
==2116== 1,304 bytes in 10 blocks are definitely lost in loss record 267 of 269
==2116==    at 0x4C229C7: operator new(unsigned long) (vg_replace_malloc.c:220)
==2116==    by 0xBDD610: llvm::SmallVectorBase::grow_pod(unsigned long,
unsigned long) (SmallVector.cpp:24)
==2116==    by 0x84F917: llvm::SmallVectorTemplateBase<llvm::SCEV const*,
true>::grow(unsigned long) (SmallVector.h:249)
==2116==    by 0x8869DA: void llvm::SmallVectorImpl<llvm::SCEV
const*>::append<llvm::SCEV const* const*>(llvm::SCEV const* const*, llvm::SCEV
const* const*) (SmallVector.h:345)
==2116==    by 0x883F03: llvm::SmallVector<llvm::SCEV const*,
8u>::SmallVector<llvm::SCEV const* const*>(llvm::SCEV const* const*, llvm::SCEV
const* const*) (SmallVector.h:678)
==2116==    by 0xA3EFAF:
llvm::SCEVNAryExpr::SCEVNAryExpr(llvm::FoldingSetNodeID const&,
llvm::SCEVTypes, llvm::SmallVectorImpl<llvm::SCEV const*> const&)
(ScalarEvolutionExpressions.h:187)
==2116==    by 0xA3F7F1:
llvm::SCEVAddRecExpr::SCEVAddRecExpr(llvm::FoldingSetNodeID const&,
llvm::SmallVectorImpl<llvm::SCEV const*> const&, llvm::Loop const*)
(ScalarEvolutionExpressions.h:394)
==2116==    by 0xA2B454:
llvm::ScalarEvolution::getAddRecExpr(llvm::SmallVectorImpl<llvm::SCEV const*>&,
llvm::Loop const*, bool, bool) (ScalarEvolution.cpp:2034)
==2116==    by 0xA2AD89: llvm::ScalarEvolution::getAddRecExpr(llvm::SCEV
const*, llvm::SCEV const*, llvm::Loop const*, bool, bool)
(ScalarEvolution.cpp:1942)
==2116==    by 0xA2E329:
llvm::ScalarEvolution::createNodeForPHI(llvm::PHINode*)
(ScalarEvolution.cpp:2656)
==2116==    by 0xA32BB0: llvm::ScalarEvolution::createSCEV(llvm::Value*)
(ScalarEvolution.cpp:3311)
==2116==    by 0xA2CDC4: llvm::ScalarEvolution::getSCEV(llvm::Value*)
(ScalarEvolution.cpp:2360)
==2116== 
==2116== 1,304 bytes in 10 blocks are definitely lost in loss record 268 of 269
==2116==    at 0x4C229C7: operator new(unsigned long) (vg_replace_malloc.c:220)
==2116==    by 0xBDD610: llvm::SmallVectorBase::grow_pod(unsigned long,
unsigned long) (SmallVector.cpp:24)
==2116==    by 0x84F917: llvm::SmallVectorTemplateBase<llvm::SCEV const*,
true>::grow(unsigned long) (SmallVector.h:249)
==2116==    by 0x8869DA: void llvm::SmallVectorImpl<llvm::SCEV
const*>::append<llvm::SCEV const* const*>(llvm::SCEV const* const*, llvm::SCEV
const* const*) (SmallVector.h:345)
==2116==    by 0x883F03: llvm::SmallVector<llvm::SCEV const*,
8u>::SmallVector<llvm::SCEV const* const*>(llvm::SCEV const* const*, llvm::SCEV
const* const*) (SmallVector.h:678)
==2116==    by 0xA3EFAF:
llvm::SCEVNAryExpr::SCEVNAryExpr(llvm::FoldingSetNodeID const&,
llvm::SCEVTypes, llvm::SmallVectorImpl<llvm::SCEV const*> const&)
(ScalarEvolutionExpressions.h:187)
==2116==    by 0xA3F7F1:
llvm::SCEVAddRecExpr::SCEVAddRecExpr(llvm::FoldingSetNodeID const&,
llvm::SmallVectorImpl<llvm::SCEV const*> const&, llvm::Loop const*)
(ScalarEvolutionExpressions.h:394)
==2116==    by 0xA2B454:
llvm::ScalarEvolution::getAddRecExpr(llvm::SmallVectorImpl<llvm::SCEV const*>&,
llvm::Loop const*, bool, bool) (ScalarEvolution.cpp:2034)
==2116==    by 0xA28A2A:
llvm::ScalarEvolution::getAddExpr(llvm::SmallVectorImpl<llvm::SCEV const*>&,
bool, bool) (ScalarEvolution.cpp:1588)
==2116==    by 0x84E636: llvm::ScalarEvolution::getAddExpr(llvm::SCEV const*,
llvm::SCEV const*, bool, bool) (ScalarEvolution.h:416)
==2116==    by 0xA318C3: llvm::ScalarEvolution::createSCEV(llvm::Value*)
(ScalarEvolution.cpp:3134)
==2116==    by 0xA2CDC4: llvm::ScalarEvolution::getSCEV(llvm::Value*)
(ScalarEvolution.cpp:2360)
==2116== 
--

********************

-- 
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 llvm.org  Wed Mar 17 13:46:47 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 17 Mar 2010 13:46:47 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6638] New: IntrinsicEmitter::EmitFnNameRecognizer
 assumes all function names at least 6 characters long
Message-ID: <bug-6638-206@http.llvm.org/bugs/>

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

           Summary: IntrinsicEmitter::EmitFnNameRecognizer assumes all
                    function names at least 6 characters long
           Product: tools
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: TableGen
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: jyasskin at google.com
                CC: llvmbugs at cs.uiuc.edu


None of TargetIntrinsicInfo::getIntrinsicID() or the definitions of lookupName
(Blackfin and MBlaze) enforce this.

******************** TEST 'LLVM :: CodeGen/Blackfin/frameindex.ll' FAILED
********************
Script:
--
llc < /home/jyasskin/llvm/src/test/CodeGen/Blackfin/frameindex.ll -march=bfin
-verify-machineinstrs
--
Exit Code: 1
Command Output (stdout):
--
Command has output on stderr!
...
--
Command Output (stderr):
--
==5337== Invalid read of size 1
==5337==    at 0xA538E3: llvm::BlackfinIntrinsicInfo::lookupName(char const*,
unsigned int) const (BlackfinGenIntrinsics.inc:34)
==5337==    by 0x1104120:
llvm::TargetIntrinsicInfo::getIntrinsicID(llvm::Function*) const
(TargetIntrinsicInfo.cpp:29)
==5337==    by 0xD7B25A: llvm::SelectionDAGBuilder::visitCall(llvm::CallInst&)
(SelectionDAGBuilder.cpp:4653)
==5337==    by 0xD56DE9: llvm::SelectionDAGBuilder::visit(unsigned int,
llvm::User&) (Instruction.def:161)
==5337==    by 0xD568F5: llvm::SelectionDAGBuilder::visit(llvm::Instruction&)
(SelectionDAGBuilder.cpp:617)
==5337==    by 0xD98380:
llvm::SelectionDAGISel::SelectBasicBlock(llvm::BasicBlock*,
llvm::ilist_iterator<llvm::Instruction>,
llvm::ilist_iterator<llvm::Instruction>, bool&) (SelectionDAGISel.cpp:407)
==5337==    by 0xD9B776:
llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function&,
llvm::MachineFunction&, llvm::MachineModuleInfo*, llvm::DwarfWriter*,
llvm::TargetInstrInfo const&) (SelectionDAGISel.cpp:1030)
==5337==    by 0xD9800A:
llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&)
(SelectionDAGISel.cpp:344)
==5337==    by 0xEB2F92:
llvm::MachineFunctionPass::runOnFunction(llvm::Function&)
(MachineFunctionPass.cpp:27)
==5337==    by 0x11CDA2C: llvm::FPPassManager::runOnFunction(llvm::Function&)
(PassManager.cpp:1350)
==5337==    by 0x11CD704: llvm::FunctionPassManagerImpl::run(llvm::Function&)
(PassManager.cpp:1301)
==5337==    by 0x11CD3B4: llvm::FunctionPassManager::run(llvm::Function&)
(PassManager.cpp:1231)
==5337==  Address 0x5d76cc5 is 1 bytes after a block of size 20 alloc'd
==5337==    at 0x4C221A7: malloc (vg_replace_malloc.c:195)
==5337==    by 0xAA40A1: llvm::MallocAllocator::Allocate(unsigned long,
unsigned long) (Allocator.h:31)
==5337==    by 0x11F4D46: llvm::StringMapEntry<llvm::Value*>*
llvm::StringMapEntry<llvm::Value*>::Create<llvm::MallocAllocator,
llvm::Value*>(char const*, char const*, llvm::MallocAllocator&, llvm::Value*)
(StringMap.h:173)
==5337==    by 0x11F49ED: llvm::StringMapEntry<llvm::Value*>*
llvm::StringMapEntry<llvm::Value*>::Create<llvm::Value*>(char const*, char
const*, llvm::Value*) (StringMap.h:200)
==5337==    by 0x11F461A: llvm::StringMapEntry<llvm::Value*>::Create(char
const*, char const*) (StringMap.h:204)
==5337==    by 0x11F3088: llvm::Value::setName(llvm::Twine const&)
(Value.cpp:201)
==5337==    by 0x118DFCC: llvm::GlobalValue::GlobalValue(llvm::Type const*,
llvm::Value::ValueTy, llvm::Use*, unsigned int,
llvm::GlobalValue::LinkageTypes, llvm::Twine const&) (GlobalValue.h:61)
==5337==    by 0x1173EE5: llvm::Function::Function(llvm::FunctionType const*,
llvm::GlobalValue::LinkageTypes, llvm::Twine const&, llvm::Module*)
(Function.cpp:156)
==5337==    by 0x9A4D2E: llvm::Function::Create(llvm::FunctionType const*,
llvm::GlobalValue::LinkageTypes, llvm::Twine const&, llvm::Module*)
(Function.h:126)
==5337==    by 0x99D6BA: llvm::LLParser::ParseFunctionHeader(llvm::Function*&,
bool) (LLParser.cpp:2787)
==5337==    by 0x98F223: llvm::LLParser::ParseDeclare() (LLParser.cpp:381)
==5337==    by 0x98DF9C: llvm::LLParser::ParseTopLevelEntities()
(LLParser.cpp:160)
==5337== 
--

********************

-- 
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 llvm.org  Wed Mar 17 14:25:50 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 17 Mar 2010 14:25:50 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6639] New: Uninitialized read used in
 PIC16TargetObjectFile::allocateIDATA
Message-ID: <bug-6639-206@http.llvm.org/bugs/>

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

           Summary: Uninitialized read used in
                    PIC16TargetObjectFile::allocateIDATA
           Product: new-bugs
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: sanjiv.gupta at microchip.com
        ReportedBy: jyasskin at google.com
                CC: llvmbugs at cs.uiuc.edu


Found by valgrind in
http://google1.osuosl.org:8011/builders/llvm-x86_64-linux-vg/builds/80/steps/test-llvm/logs/stdio.

******************** TEST 'LLVM :: CodeGen/PIC16/2009-07-17-PR4566-pic16.ll'
FAILED ********************
Script:
--
llc <
/build/buildbot-llvm/llvm-x86_64-linux-vg/llvm/test/CodeGen/PIC16/2009-07-17-PR4566-pic16.ll
-march=pic16 | FileCheck
/build/buildbot-llvm/llvm-x86_64-linux-vg/llvm/test/CodeGen/PIC16/2009-07-17-PR4566-pic16.ll
--
Exit Code: 1
Command Output (stdout):
--
Command has output on stderr!

--
Command Output (stderr):
--
==31251== Conditional jump or move depends on uninitialised value(s)
==31251==    at 0xAA2C4D:
llvm::PIC16TargetObjectFile::allocateIDATA(llvm::GlobalVariable const*) const
(PIC16TargetObjectFile.cpp:186)
==31251==    by 0xAA31CD:
llvm::PIC16TargetObjectFile::SelectSectionForGlobal(llvm::GlobalValue const*,
llvm::SectionKind, llvm::Mangler*, llvm::TargetMachine const&) const
(PIC16TargetObjectFile.cpp:256)
==31251==    by 0x1104C9F:
llvm::TargetLoweringObjectFile::SectionForGlobal(llvm::GlobalValue const*,
llvm::SectionKind, llvm::Mangler*, llvm::TargetMachine const&) const
(TargetLoweringObjectFile.cpp:259)
==31251==    by 0xA7FDA9:
llvm::TargetLoweringObjectFile::SectionForGlobal(llvm::GlobalValue const*,
llvm::Mangler*, llvm::TargetMachine const&) const
(TargetLoweringObjectFile.h:181)
==31251==    by 0xA990E5:
llvm::PIC16AsmPrinter::doInitialization(llvm::Module&)
(PIC16AsmPrinter.cpp:283)
==31251==    by 0x11CDD7A: llvm::FPPassManager::doInitialization(llvm::Module&)
(PassManager.cpp:1380)
==31251==    by 0x11CD505:
llvm::FunctionPassManagerImpl::doInitialization(llvm::Module&)
(PassManager.cpp:1257)
==31251==    by 0x11CD472: llvm::FunctionPassManager::doInitialization()
(PassManager.cpp:1238)
==31251==    by 0x97C76A: main (llc.cpp:369)
==31251== 
--

********************

-- 
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 llvm.org  Wed Mar 17 14:44:17 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 17 Mar 2010 14:44:17 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6640] New: release-asserts build of llvm-2.7
 prerelease fails several unit tests
Message-ID: <bug-6640-206@http.llvm.org/bugs/>

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

           Summary: release-asserts build of llvm-2.7 prerelease fails
                    several unit tests
           Product: new-bugs
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: baldrick at free.fr
                CC: llvmbugs at cs.uiuc.edu


[==========] 136 tests from 18 test cases ran.
[  PASSED  ] 128 tests.
[  FAILED  ] 8 tests, listed below:
[  FAILED  ] APIntTest.StringDeath
[  FAILED  ] APFloatTest.SemanticsDeath
[  FAILED  ] APFloatTest.StringDecimalDeath
[  FAILED  ] APFloatTest.StringDecimalSignificandDeath
[  FAILED  ] APFloatTest.StringDecimalExponentDeath
[  FAILED  ] APFloatTest.StringHexadecimalDeath
[  FAILED  ] APFloatTest.StringHexadecimalSignificandDeath
[  FAILED  ] APFloatTest.StringHexadecimalExponentDeath

All tests pass with a debug build or a release build.

-- 
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 llvm.org  Wed Mar 17 15:11:53 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 17 Mar 2010 15:11:53 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6639] Uninitialized read used in
 PIC16TargetObjectFile::allocateIDATA
In-Reply-To: <bug-6639-206@http.llvm.org/bugs/>
References: <bug-6639-206@http.llvm.org/bugs/>
Message-ID: <20100317201153.F21962A6C12D@llvm.org>

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

Benjamin Kramer <benny.kra at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |benny.kra at gmail.com
         Resolution|                            |FIXED

--- Comment #1 from Benjamin Kramer <benny.kra at gmail.com> 2010-03-17 15:11:53 CDT ---
Worked around in r98763.
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20100315/098042.html

Sanjiv, it would be nice if you could take a look if my fix is correct.

-- 
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 llvm.org  Wed Mar 17 16:25:48 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 17 Mar 2010 16:25:48 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6641] New: clang++ crash: "Calling a function with
 a bad signature!"
Message-ID: <bug-6641-206@http.llvm.org/bugs/>

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

           Summary: clang++ crash: "Calling a function with a bad
                    signature!"
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: ori at avtalion.name
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


The following code crashes clang++:

struct Foo {
 Foo() { }
};

void bar() {
 new Foo[1][1];
}


$ clang++ -c file.cpp 
clang: Instructions.cpp:311: void llvm::CallInst::init(llvm::Value*,
llvm::Value* const*, unsigned int): Assertion `(i >= FTy->getNumParams() ||
FTy->getParamType(i) == Params[i]->getType()) && "Calling a function with a bad
signature!"' failed.

Stack dump:
0.    Program arguments: clang -cc1 -triple x86_64-unknown-linux-gnu -S
-disable-free -main-file-name file.cpp -mrelocation-model static
-mdisable-fp-elim -mconstructor-aliases -munwind-tables -target-cpu x86-64
-resource-dir /home/ori/devel/llvm/Debug/lib/clang/1.1 -fmessage-length 143
-fexceptions -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o
/tmp/cc-PjVvBb.s -x c++ file.cpp 
1.    <eof> parser at end of file
2.    file.cpp:5:6: LLVM IR generation of declaration 'bar'
3.    file.cpp:5:6: Generating code for declaration 'bar'
4.    file.cpp:5:12: LLVM IR generation of compound statement ('{}')

-- 
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 llvm.org  Wed Mar 17 17:43:02 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 17 Mar 2010 17:43:02 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6642] New: Loads from arrays initialized with a
 single large store not optimized
Message-ID: <bug-6642-206@http.llvm.org/bugs/>

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

           Summary: Loads from arrays initialized with a single large
                    store not optimized
           Product: new-bugs
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: matti.niemenmaa+llvmbugs at iki.fi
                CC: llvmbugs at cs.uiuc.edu


The following IR is optimized by 'opt -std-compile-opts -std-link-opts' from
r98773 to a main that simply returns zero:


target datalayout =
"e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128"
target triple = "x86_64-unknown-linux-gnu"

%ARRAY = type [128 x i8]

define i32 @main() nounwind readnone {
    %x = alloca %ARRAY, align 16
    store %ARRAY zeroinitializer, %ARRAY* %x, align 16
    %y = getelementptr inbounds %ARRAY* %x, i64 0, i64 0
    %z = load i8* %y, align 16
    %w = zext i8 %z to i32
    ret i32 %w
}


But if we change %ARRAY to be something bigger, like %ARRAY = type [256 x i8],
the code passes through the optimizer unchanged. 128 is the exact bound in this
case: 129 and anything larger inhibits optimization.

Initializing each element of %x individually (lots of separate geps and stores)
apparently works regardless of the size of %ARRAY, but it's a shame that this
seemingly cleaner code optimizes so poorly.

-- 
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 llvm.org  Thu Mar 18 00:36:38 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 18 Mar 2010 00:36:38 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6644] New: [C++ CodeGen] Crash with polymorphic
 class inside extern "C" block
Message-ID: <bug-6644-206@http.llvm.org/bugs/>

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

           Summary: [C++ CodeGen] Crash with polymorphic class inside
                    extern "C" block
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: dgregor at apple.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


blackthorn:clang dgregor$ cat t.C
extern "C" {
  namespace N {
    struct X { 
      virtual void f();
    };
    void X::f() { }
  }
}
blackthorn:clang dgregor$ clang t.C
Assertion failed: (cast<LinkageSpecDecl>(DC)->getLanguage() ==
LinkageSpecDecl::lang_cxx && "Unexpected linkage decl!"), function
IgnoreLinkageSpecDecls, file
/Users/dgregor/Projects/llvm/tools/clang/lib/CodeGen/Mangle.cpp, line 310.
Stack dump:
0.    Program arguments: /Users/dgregor/Projects/llvm-make/bin/clang -cc1
-triple x86_64-apple-darwin10.0.0 -S -disable-free -main-file-name t.C
-pic-level 1 -mdisable-fp-elim -munwind-tables -target-cpu core2 -resource-dir
/Users/dgregor/Projects/llvm-make/lib/clang/1.5 -fmessage-length 80
-stack-protector 1 -fblocks -fexceptions -fdiagnostics-show-option
-fcolor-diagnostics -o
/var/folders/Vf/VfsrpcXeFyKWp16pSa7tMk+++TI/-Tmp-/cc-bwzvzw.s -x c++ t.C 
1.    <eof> parser at end of file
2.    t.C:1:8: LLVM IR generation of declaration
3.    t.C:6:13: Generating code for declaration 'N::X::f'
clang: error: compiler command failed due to signal 6 (use -v to see
invocation)

-- 
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 llvm.org  Thu Mar 18 08:01:40 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 18 Mar 2010 08:01:40 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6645] New: SIGSEG in
 clang::DeclContext::isTransparentContext ()
Message-ID: <bug-6645-206@http.llvm.org/bugs/>

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

           Summary: SIGSEG in clang::DeclContext::isTransparentContext ()
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: josephwinston at mac.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


Created an attachment (id=4543)
 --> (http://llvm.org/bugs/attachment.cgi?id=4543)
sample code

/scratch/jody/src/Languages/LLVM/llvm-read-only/x86_64-unknown-linux-gnu-INSTALL/bin/clang
-cc1 -triple x86_64-unknown-linux-gnu -S -disable-free -main-file-name
DataManager.cpp -pic-level 2 -mdisable-fp-elim -mconstructor-aliases
-munwind-tables -target-cpu x86-64 -g -resource-dir
/scratch/jody/src/Languages/LLVM/llvm-read-only/x86_64-unknown-linux-gnu-INSTALL/lib/clang/1.5
-Wall -Wno-deprecated -fmessage-length 144 -fexceptions -fgnu-runtime -x c++
/tmp/example1.cpp

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x2a95893e00 (LWP 10548)]
0x0000000000d9ddc0 in clang::DeclContext::isTransparentContext ()
(gdb) where
#0  0x0000000000d9ddc0 in clang::DeclContext::isTransparentContext ()
#1  0x0000000000da1ecc in clang::DeclContext::getLookupContext ()
#2  0x0000000000a5373b in clang::IdentifierResolver::isDeclInScope ()
#3  0x0000000000a944ad in clang::Sema::isDeclInScope ()
#4  0x0000000000a96f91 in FilterLookupForScope ()
#5  0x0000000000ab02b2 in clang::Sema::ActOnTypedefDeclarator ()
#6  0x0000000000ab49ae in clang::Sema::HandleDeclarator ()
#7  0x0000000000a59344 in clang::Sema::ActOnDeclarator ()
#8  0x0000000000e37d7d in clang::Parser::ParseDeclarationAfterDeclarator ()
#9  0x0000000000e3b25b in clang::Parser::ParseDeclGroup ()
#10 0x0000000000e46aa2 in clang::Parser::ParseSimpleDeclaration ()
#11 0x0000000000e46c1e in clang::Parser::ParseDeclaration ()
#12 0x0000000000e34f2c in clang::Parser::ParseExternalDeclaration ()
#13 0x0000000000e49fbe in clang::Parser::ParseNamespace ()
#14 0x0000000000e46cd1 in clang::Parser::ParseDeclaration ()
#15 0x0000000000e34f2c in clang::Parser::ParseExternalDeclaration ()
#16 0x0000000000e49fbe in clang::Parser::ParseNamespace ()
#17 0x0000000000e46cd1 in clang::Parser::ParseDeclaration ()
#18 0x0000000000e34f2c in clang::Parser::ParseExternalDeclaration ()
#19 0x0000000000e49fbe in clang::Parser::ParseNamespace ()
#20 0x0000000000e46cd1 in clang::Parser::ParseDeclaration ()
#21 0x0000000000e34f2c in clang::Parser::ParseExternalDeclaration ()
#22 0x0000000000e3524a in clang::Parser::ParseTopLevelDecl ()
#23 0x0000000000a53e0f in clang::ParseAST ()
#24 0x00000000007f1fdf in clang::CompilerInstance::ExecuteAction ()
#25 0x00000000007e6a1e in cc1_main ()
#26 0x00000000007e40a6 in main ()
(gdb)

-- 
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 llvm.org  Thu Mar 18 08:03:26 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 18 Mar 2010 08:03:26 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6646] New: conftest for libm symbols fail under c++
Message-ID: <bug-6646-206@http.llvm.org/bugs/>

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

           Summary: conftest for libm symbols fail under c++
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: jed at 59a2.org
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


This is a reduced conftest.cpp (generated by another projects autoconf) testing
for pow.  The same occurs for other libm symbols.  Clang r98819:

$ cat conftest-reduced.cpp
/* Override any GCC internal prototype to avoid an error.
   Use char because int might match the return type of a GCC
   builtin and then its argument prototype would still apply.  */
extern "C" char pow ();
int main ()
{
  return pow ();
}
$ clang++ -c -v conftest-reduced.cpp >& log.compile

-- 
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 llvm.org  Thu Mar 18 08:04:07 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 18 Mar 2010 08:04:07 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6647] New: SIGSEGV in clang::TokenLexer::Lex ()
Message-ID: <bug-6647-206@http.llvm.org/bugs/>

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

           Summary: SIGSEGV in clang::TokenLexer::Lex ()
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: josephwinston at mac.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


Created an attachment (id=4544)
 --> (http://llvm.org/bugs/attachment.cgi?id=4544)
sample code

/scratch/jody/src/Languages/LLVM/llvm-read-only/x86_64-unknown-linux-gnu-INSTALL/bin/clang
-cc1 -triple x86_64-unknown-linux-gnu -S -disable-free -main-file-name
DataManager.cpp -pic-level 2 -mdisable-fp-elim -mconstructor-aliases
-munwind-tables -target-cpu x86-64 -g -resource-dir
/scratch/jody/src/Languages/LLVM/llvm-read-only/x86_64-unknown-linux-gnu-INSTALL/lib/clang/1.5
-Wall -Wno-deprecated -fmessage-length 144 -fexceptions -fgnu-runtime -x c++
/tmp/example1.cpp

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x2a95893e00 (LWP 10471)]
0x0000000000ea67dc in clang::TokenLexer::Lex ()
(gdb) where
#0  0x0000000000ea67dc in clang::TokenLexer::Lex ()
#1  0x0000000000e84913 in clang::Preprocessor::PeekAhead ()
#2  0x0000000000e62a10 in clang::Parser::ParseOptionalCXXScopeSpecifier ()
#3  0x0000000000e3337e in clang::Parser::TryAnnotateTypeOrScopeToken ()
#4  0x0000000000e55e81 in clang::Parser::ParseCastExpression ()
#5  0x0000000000e596f9 in clang::Parser::ParseCastExpression ()
#6  0x0000000000e599ac in clang::Parser::ParseRHSOfBinaryExpression ()
#7  0x0000000000e5402c in clang::Parser::ParseAssignmentExpression ()
#8  0x0000000000e7277a in clang::Parser::ParseLexedMethodDeclarations ()
#9  0x0000000000e4fc7c in clang::Parser::ParseCXXMemberSpecification ()
#10 0x0000000000e50990 in clang::Parser::ParseClassSpecifier ()
#11 0x0000000000e40572 in clang::Parser::ParseDeclarationSpecifiers ()
#12 0x0000000000e34353 in clang::Parser::ParseDeclarationOrFunctionDefinition
()
#13 0x0000000000e348a1 in clang::Parser::ParseDeclarationOrFunctionDefinition
()
#14 0x0000000000e34a15 in clang::Parser::ParseExternalDeclaration ()
#15 0x0000000000e3524a in clang::Parser::ParseTopLevelDecl ()
#16 0x0000000000a53e0f in clang::ParseAST ()
#17 0x00000000007f1fdf in clang::CompilerInstance::ExecuteAction ()
#18 0x00000000007e6a1e in cc1_main ()
#19 0x00000000007e40a6 in main ()
(gdb)

-- 
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 llvm.org  Thu Mar 18 09:00:18 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 18 Mar 2010 09:00:18 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6648] New: getASTRecordLayout crash on valid
Message-ID: <bug-6648-206@http.llvm.org/bugs/>

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

           Summary: getASTRecordLayout crash on valid
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: rafael.espindola at gmail.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


gcc accepts this code bug clang crashes with

ASTContext.cpp:1196: const clang::ASTRecordLayout&
clang::ASTContext::getASTRecordLayout(const clang::RecordDecl*): Assertion `D
&& "Cannot get layout of forward declarations!"' failed.

--------------------------
struct A {
  ~A();
};
template <typename T>
struct B {
  A x;
};
struct C {
public:
  template <typename T>
  operator B<T>() const;
};
C foo;
template <typename F>
struct D {
};
D<int>& zed(const B<int>&);
void foobar() {
  zed(foo);
}
-------------------------

-- 
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 llvm.org  Thu Mar 18 11:02:49 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 18 Mar 2010 11:02:49 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6649] New: Crash with dependent
	elaborated-type-specifier
Message-ID: <bug-6649-206@http.llvm.org/bugs/>

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

           Summary: Crash with dependent elaborated-type-specifier
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: dgregor at apple.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


template <typename T> struct foo { class T::bar; };

-- 
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 llvm.org  Thu Mar 18 11:41:42 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 18 Mar 2010 11:41:42 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6609] Namelookup done for unused parameter names
In-Reply-To: <bug-6609-206@http.llvm.org/bugs/>
References: <bug-6609-206@http.llvm.org/bugs/>
Message-ID: <20100318164142.7A7502A6C124@llvm.org>

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

John McCall <rjmccall at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |rjmccall at apple.com
         Resolution|                            |FIXED

--- Comment #1 from John McCall <rjmccall at apple.com> 2010-03-18 11:41:42 CDT ---
Fixed in r98806.

-- 
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 llvm.org  Thu Mar 18 11:52:34 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 18 Mar 2010 11:52:34 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6638] IntrinsicEmitter::EmitFnNameRecognizer
 assumes all function names at least 6 characters long
In-Reply-To: <bug-6638-206@http.llvm.org/bugs/>
References: <bug-6638-206@http.llvm.org/bugs/>
Message-ID: <20100318165234.1654C2A6C12D@llvm.org>

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

Bob Wilson <bob.wilson at apple.com> changed:

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

--- Comment #2 from Bob Wilson <bob.wilson at apple.com> 2010-03-18 11:52:33 CDT ---
Fixed in svn r98831.

-- 
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 llvm.org  Thu Mar 18 12:59:16 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 18 Mar 2010 12:59:16 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6637] SCEVs are allocated with BumpPtrAllocator but
 have members that need destruction
In-Reply-To: <bug-6637-206@http.llvm.org/bugs/>
References: <bug-6637-206@http.llvm.org/bugs/>
Message-ID: <20100318175916.C66632A6C124@llvm.org>

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

Jeffrey Yasskin <jyasskin at google.com> changed:

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

--- Comment #2 from Jeffrey Yasskin <jyasskin at google.com> 2010-03-18 12:59:16 CDT ---
Verified in a valgrind --leak-check=full run. 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 llvm.org  Thu Mar 18 13:23:59 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 18 Mar 2010 13:23:59 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6650] New: bugpoint final cleanups fail under
 valgrind --trace-children=yes
Message-ID: <bug-6650-206@http.llvm.org/bugs/>

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

           Summary: bugpoint final cleanups fail under valgrind
                    --trace-children=yes
           Product: tools
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: bugpoint
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: jyasskin at google.com
                CC: llvmbugs at cs.uiuc.edu, nlewycky at google.com


This seems to be causing the failure at
http://google1.osuosl.org:8011/builders/llvm-i686-linux-vg/builds/94/steps/test-llvm/logs/crash-narrowfunctiontest.ll,
but I haven't tracked down the details yet.

$ Debug/bin/bugpoint ../src/test/BugPoint/crash-narrowfunctiontest.ll
-output-prefix test/BugPoint/Output/crash-narrowfunctiontest.ll.tmp
-bugpoint-crashcalls -silence-passes
...
*** Attempting to perform final cleanups: Crashed with signal #6
Dumped core
Emitted bitcode to
'test/BugPoint/Output/crash-narrowfunctiontest.ll.tmp-reduced-simplified.bc'

*** You can reproduce the problem with: opt
test/BugPoint/Output/crash-narrowfunctiontest.ll.tmp-reduced-simplified.bc
-bugpoint-crashcalls
$

but:

$ valgrind --trace-children=yes Debug/bin/bugpoint
../src/test/BugPoint/crash-narrowfunctiontest.ll -output-prefix
test/BugPoint/Output/crash-narrowfunctiontest.ll.tmp -bugpoint-crashcalls
-silence-passes
...
*** Attempting to perform final cleanups: Final cleanups failed.  Sorry. :( 
Please report a bug!
Exited with error code '1'
Emitted bitcode to
'test/BugPoint/Output/crash-narrowfunctiontest.ll.tmp-reduced-simplified.bc'

*** You can reproduce the problem with: opt
test/BugPoint/Output/crash-narrowfunctiontest.ll.tmp-reduced-simplified.bc
-bugpoint-crashcalls


valgrind without --trace-children produces the same output as no-valgrind.


Instead of crashing, valgrind seems to be causing an error exit, which may be
interfering with the path the test is trying to provoke. PR753 makes it harder
to track down the real problem.

-- 
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 llvm.org  Thu Mar 18 13:42:58 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 18 Mar 2010 13:42:58 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6543] ARM JIT Regression CodeEmitter asserts JTI <
 JumpTableId2AddrMap.size while jiting
 java.awt.EventDispatchThread::pumpOneEventForFilters
In-Reply-To: <bug-6543-206@http.llvm.org/bugs/>
References: <bug-6543-206@http.llvm.org/bugs/>
Message-ID: <20100318184258.0E8AE2A6C12D@llvm.org>

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

Bob Wilson <bob.wilson at apple.com> changed:

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

--- Comment #8 from Bob Wilson <bob.wilson at apple.com> 2010-03-18 13:42:57 CDT ---
This is due to svn r88806, which inadvertently disabled jump table merging and
broke things in the process.  Fixed in svn r98845.

-- 
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 llvm.org  Thu Mar 18 17:52:39 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 18 Mar 2010 17:52:39 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6651] New: slow register coalescing
Message-ID: <bug-6651-206@http.llvm.org/bugs/>

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

           Summary: slow register coalescing
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Common Code Generator Code
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: rafael.espindola at gmail.com
                CC: llvmbugs at cs.uiuc.edu


The attached testcase takes 91.2377s in llc. Most of the time is in

 65.8001 ( 72.3%)   0.0440 ( 19.0%)  65.8441 ( 72.2%)  65.9472 ( 72.2%)  Simple
Register Coalescing
  15.9610 ( 17.5%)   0.0080 (  3.4%)  15.9690 ( 17.5%)  15.9948 ( 17.5%) 
Machine Common Subexpression Elimination
   7.0564 (  7.8%)   0.0880 ( 37.9%)   7.1444 (  7.8%)   7.1505 (  7.8%)  X86
DAG->DAG Instruction Selection

-- 
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 llvm.org  Thu Mar 18 17:56:32 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 18 Mar 2010 17:56:32 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6652] New: ARMv4: missed optimization for LDM +
	return
Message-ID: <bug-6652-206@http.llvm.org/bugs/>

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

           Summary: ARMv4: missed optimization for LDM + return
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: ARM
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: john at bass-software.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=4546)
 --> (http://llvm.org/bugs/attachment.cgi?id=4546)
Patch and test case to merge return into ldm for ARMv4 output

Recent ARMv4 support is missing the optimization to merge:

  ldmfd sp!, {..., lr}
  mov pc, lr

into

  ldmfd sp!, {..., pc}

In ARMv5 mode this was already happening.  Attached a small patch and test case
for ARMLoadStoreOpt::MergeReturnIntoLDM() doing this optimization for ARMv4.

-- 
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 llvm.org  Fri Mar 19 01:45:55 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 19 Mar 2010 01:45:55 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6653] New: LiveInterval leaks VNInfos
Message-ID: <bug-6653-206@http.llvm.org/bugs/>

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

           Summary: LiveInterval leaks VNInfos
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Common Code Generator Code
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: jyasskin at google.com
                CC: evan.cheng at apple.com, llvmbugs at cs.uiuc.edu


LiveInterval allocates VNInfo objects with a BumpPtrAllocator. Unfortunately,
VNInfo::kills is a SmallVector<>, which needs to be destroyed.
LiveInterval::clear() helpfully destroys the VNInfos, but the crashes that
result from calling that in ~LiveInterval indicate that the same VNInfo can
wind up in two different LiveIntervals' valnos lists.

Found by valgrinding test/CodeGen/Blackfin/jumptable.ll. The crashes show up in
CodeGen/X86/2009-04-27-CoalescerAssert.ll, CodeGen/X86/i2k.ll,
CodeGen/X86/iv-users-in-other-loops.ll, and CodeGen/X86/pic.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 llvm.org  Fri Mar 19 03:53:40 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 19 Mar 2010 03:53:40 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6654] New: llvm-test regressions with 2.7
Message-ID: <bug-6654-206@http.llvm.org/bugs/>

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

           Summary: llvm-test regressions with 2.7
           Product: new-bugs
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: baldrick at free.fr
                CC: llvmbugs at cs.uiuc.edu


On x86-32 linux, I see the following regressions when running llvm-test using
llvm-gcc:

MultiSource/Benchmarks/Bullet/bullet (llc+jit):

llc:

pre-release1/llvm-2.7/projects/llvm-test/RunSafely.sh 750 0 /dev/null
Output/bullet.out-llc Output/bullet.llc
TEST Output/bullet.llc FAILED: process terminated by signal (exit status 139)!

warning: Can't read pathname for load map: Input/output error.
Core was generated by `Output/bullet.llc'.
Program terminated with signal 11, Segmentation fault.
#0  0x00000000 in ?? ()
#0  0x00000000 in ?? ()
Cannot access memory at address 0x3f800004

jit:

pre-release1/llvm-2.7/projects/llvm-test/RunSafely.sh 750 0 /dev/null
Output/bullet.out-jit pre-release1/release-build/llvm-objects/Release/bin/lli
-info-output-file=pre-release1/release-build/llvm-objects/projects/llvm-test/MultiSource/Benchmarks/Bullet/Output/bullet.out-jit.info
-stats -time-passes -force-interpreter=false --disable-core-files 
Output/bullet.llvm.bc
TEST pre-release1/release-build/llvm-objects/Release/bin/lli FAILED: process
terminated by signal (exit status 139)!


MultiSource/Benchmarks/Fhourstones-3.1/fhourstones3.1 (cbe):

gcc-4.2 Output/fhourstones3.1.cbe.c -o Output/fhourstones3.1.cbe   -O3
-fno-strict-aliasing -fno-inline -m32 -fomit-frame-pointer
Output/fhourstones3.1.cbe.c:1235:37: warning: no newline at end of file
Output/fhourstones3.1.cbe.c: In function 'main':
Output/fhourstones3.1.cbe.c:1235: error: expected '=', ',', ';', 'asm' or
'__attribute__' at end of input
Output/fhourstones3.1.cbe.c:1235: error: expected declaration or statement at
end of input
Output/fhourstones3.1.cbe.c:1160: warning: return type of 'main' is not 'int'


MultiSource/Benchmarks/MallocBench/cfrac/cfrac (cbe):

...
Output/cfrac.cbe.c:12013: warning: function called through a non-compatible
type
Output/cfrac.cbe.c:12013: note: if this code is reached, the program will abort
Output/cfrac.cbe.c:12035: warning: function called through a non-compatible
type
Output/cfrac.cbe.c:12035: note: if this code is reached, the program will abort
pre-release1/llvm-2.7/projects/llvm-test/RunSafely.sh 500 0 /dev/null
Output/cfrac.out-cbe Output/cfrac.cbe 41757646344123832613190542166099121
TEST Output/cfrac.cbe FAILED: process terminated by signal (exit status 132)!

warning: Can't read pathname for load map: Input/output error.
Core was generated by `Output/cfrac.cbe 41757646344123832613190542166099121'.
Program terminated with signal 4, Illegal instruction.
#0  0x0804a55c in padd ()
#0  0x0804a55c in padd ()
#1  0x00000010 in ?? ()


MultiSource/Benchmarks/MiBench/consumer-lame/consumer-lame (cbe):

llc: pre-release1/llvm-2.7/lib/Target/CBackend/CBackend.cpp:501:
llvm::raw_ostream&<unnamed>::CWriter::printSimpleType(llvm::raw_ostream&, const
llvm::Type*, bool, const std::string&): Assertion `NumBits <= 128 && "Bit
widths > 128 not implemented yet"' failed.


SingleSource/Regression/C/2004-03-15-IndirectGoto (jit+cbe):

jit:

pre-release1/llvm-2.7/projects/llvm-test/RunSafely.sh 500 0 /dev/null
Output/2004-03-15-IndirectGoto.out-jit
pre-release1/release-build/llvm-objects/Release/bin/lli
-info-output-file=pre-release1/release-build/llvm-objects/projects/llvm-test/SingleSource/Regression/C/Output/2004-03-15-IndirectGoto.out-jit.info
-stats -time-passes -force-interpreter=false --disable-core-files 
Output/2004-03-15-IndirectGoto.llvm.bc
TEST pre-release1/release-build/llvm-objects/Release/bin/lli FAILED: process
terminated by signal (exit status 134)!

cbe:

pre-release1/llvm-2.7/projects/llvm-test/RunToolSafely.sh 500
pre-release1/release-build/llvm-objects/Release/bin/llc -asm-verbose=false -O3
-march=c Output/2004-03-15-IndirectGoto.llvm.bc -o
Output/2004-03-15-IndirectGoto.cbe.c
-info-output-file=pre-release1/release-build/llvm-objects/projects/llvm-test/SingleSource/Regression/C/Output/2004-03-15-IndirectGoto.cbe.c.info
-stats -time-passes
Unknown constant type: i8* blockaddress(@main, %L1)
UNREACHABLE executed at
pre-release1/llvm-2.7/lib/Target/CBackend/CBackend.cpp:1190!


SingleSource/Regression/C/casts (llc+jit):

llc:

pre-release1/llvm-2.7/projects/llvm-test/RunSafely.sh 500 0 /dev/null
Output/casts.out-llc Output/casts.llc
TEST Output/casts.llc FAILED: process terminated by signal (exit status 139)!

warning: Can't read pathname for load map: Input/output error.
Core was generated by `Output/casts.llc'.
Program terminated with signal 11, Segmentation fault.
#0  0x080488fa in main ()
#0  0x080488fa in main ()

jit:

pre-release1/llvm-2.7/projects/llvm-test/RunSafely.sh 500 0 /dev/null
Output/casts.out-jit pre-release1/release-build/llvm-objects/Release/bin/lli
-info-output-file=pre-release1/release-build/llvm-objects/projects/llvm-test/SingleSource/Regression/C/Output/casts.out-jit.info
-stats -time-passes -force-interpreter=false --disable-core-files 
Output/casts.llvm.bc
TEST pre-release1/release-build/llvm-objects/Release/bin/lli FAILED: process
terminated by signal (exit status 139)!

-- 
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 llvm.org  Fri Mar 19 04:53:16 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 19 Mar 2010 04:53:16 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6655] New: cygwin not support loadable module
Message-ID: <bug-6655-206@http.llvm.org/bugs/>

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

           Summary: cygwin not support loadable module
           Product: Build scripts
           Version: trunk
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: normal
          Priority: P
         Component: cmake
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: etherzhhb at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=4550)
 --> (http://llvm.org/bugs/attachment.cgi?id=4550)
the patch to prevent loadable module build on cygwin

hi,

it seems that cygwin not support the loadable module. But the cmake build
system are going to build loadable module on cygwin, thats because cmake build
system think cygwin is a kind of unix, and the following statment in
/cmake/modules/AddLLVM.cmake lead a loadable module build in cygwin:

 macro(add_llvm_loadable_module name)
  if( NOT LLVM_ON_UNIX )
     message(STATUS "Loadable modules not supported on this platform.
 ${name} ignored.")
   else()

and the follow patch prevent cmake build loadable module on cygwin
diff --git a/cmake/modules/AddLLVM.cmake b/cmake/modules/AddLLVM.cmake
index 0ecd153..0af5e59 100755
--- a/cmake/modules/AddLLVM.cmake
+++ b/cmake/modules/AddLLVM.cmake
@@ -23,7 +23,7 @@ endmacro(add_llvm_library name)


 macro(add_llvm_loadable_module name)
-  if( NOT LLVM_ON_UNIX )
+  if( NOT LLVM_ON_UNIX OR WIN32 )
     message(STATUS "Loadable modules not supported on this platform.
 ${name} ignored.")
   else()



my cygwin version is:
CYGWIN_NT-5.1 sysu-ffc563a254 1.7.1(0.218/5/3) 2009-12-07 11:48 i686 Cygwin

gcc version is:
Using built-in specs.
Target: i686-pc-cygwin
Configured with:
/gnu/gcc/releases/packaging/4.3.4-3/gcc4-4.3.4-3/src/gcc-4.3.4/configure
--srcdir=/gnu/gcc/releases/packaging/4.3.4-3/gcc4-4.3.4-3/src/gcc-4.3.4
--prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin
--libexecdir=/usr/lib --datadir=/usr/share --localstatedir=/var
--sysconfdir=/etc --infodir=/usr/share/info --mandir=/usr/share/man
--datadir=/usr/share --infodir=/usr/share/info --mandir=/usr/share/man -v
--with-gmp=/usr --with-mpfr=/usr --enable-bootstrap
--enable-version-specific-runtime-libs --with-slibdir=/usr/bin
--libexecdir=/usr/lib --enable-static --enable-shared --enable-shared-libgcc
--disable-__cxa_atexit --with-gnu-ld --with-gnu-as --with-dwarf2
--disable-sjlj-exceptions
--enable-languages=ada,c,c++,fortran,java,objc,obj-c++ --disable-symvers
--enable-libjava --program-suffix=-4 --enable-libgomp --enable-libssp
--enable-libada --enable-threads=posix --with-arch=i686 --with-tune=generic
--enable-libgcj-sublibs CC=gcc-4 CXX=g++-4 CC_FOR_TARGET=gcc-4
CXX_FOR_TARGET=g++-4 GNATMAKE_FOR_TARGET=gnatmake GNATBIND_FOR_TARGET=gnatbind
AS=/opt/gcc-tools/bin/as.exe AS_FOR_TARGET=/opt/gcc-tools/bin/as.exe
LD=/opt/gcc-tools/bin/ld.exe LD_FOR_TARGET=/opt/gcc-tools/bin/ld.exe
--with-ecj-jar=/usr/share/java/ecj.jar
Thread model: posix
gcc version 4.3.4 20090804 (release) 1 (GCC)

-- 
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 llvm.org  Fri Mar 19 10:43:43 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 19 Mar 2010 10:43:43 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6650] bugpoint final cleanups fail under valgrind
 --trace-children=yes
In-Reply-To: <bug-6650-206@http.llvm.org/bugs/>
References: <bug-6650-206@http.llvm.org/bugs/>
Message-ID: <20100319154343.CE1962A6C124@llvm.org>

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

Jeffrey Yasskin <jyasskin at google.com> changed:

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

--- Comment #3 from Jeffrey Yasskin <jyasskin at google.com> 2010-03-19 10:43:43 CDT ---
Yep, fixed by r98905.

-- 
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 llvm.org  Fri Mar 19 11:41:54 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 19 Mar 2010 11:41:54 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6656] New: An asserting value handle still pointed
 to this value!
Message-ID: <bug-6656-206@http.llvm.org/bugs/>

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

           Summary: An asserting value handle still pointed to this value!
           Product: new-bugs
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: baldrick at free.fr
                CC: llvmbugs at cs.uiuc.edu


Seems to be a blockaddress problem.

$ llvm-gcc -S -O2 pr27863.c
While deleting: i32 (i32, i8**, i8**)* %main
An asserting value handle still pointed to this value!
UNREACHABLE executed at
/home/duncan/LLVM/llvm.top/llvm/lib/VMCore/Value.cpp:522!
pr27863.c:28: internal compiler error: Aborted

Here's the contents of pr27863.c (from the gcc testsuite):

/* This test used to ICE on IA64.  */
long stack[100];
int main(int argc,char**argv,char **envp)
{
  long *esp=stack;
  static void* jarray[]={ &&KeyCtrlKV };
 *++esp=(long)&&_loc0;
 goto SetTermStruc;
 _loc0:;
 *++esp=(long)&&_loc1;
 _loc1:;
*++esp=(long)&&_loc35;
 _loc35:;
goto *(*esp--);
*++esp=(long)&&_loc36;
 _loc36:;
*++esp=(long)&&_loc37;
 _loc37:;
KeyCtrlKV:
*++esp=(long)&&_loc66;
_loc66:;
*++esp=(long)&&_loc106;
 _loc106:;
*++esp=(long)&&_loc119;
 _loc119:;
SetTermStruc:
 goto *(*esp--);
}

-- 
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 llvm.org  Fri Mar 19 12:25:18 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 19 Mar 2010 12:25:18 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6006] Change ContentCache::getBuffer to support
 failure properly.
In-Reply-To: <bug-6006-206@http.llvm.org/bugs/>
References: <bug-6006-206@http.llvm.org/bugs/>
Message-ID: <20100319172518.8FF432A6C12D@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #1 from Douglas Gregor <dgregor at apple.com> 2010-03-19 12:25:18 CDT ---
I implemented this fix a few days ago, improving our detection of missing or
changed headers inside ContentCache::getBuffer() and introducing diagnostics
when this problem occurs, then updated all of the callers that matter.

-- 
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 llvm.org  Fri Mar 19 16:33:35 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 19 Mar 2010 16:33:35 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6657] New: SemaTemplateInstantiateDecl.cpp:393:
 clang::Decl*<unnamed>::TemplateDeclInstantiator::VisitVarDecl(clang::VarDecl*):
 Assertion `InitArgs.size() == 0' failed.
Message-ID: <bug-6657-206@http.llvm.org/bugs/>

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

           Summary: SemaTemplateInstantiateDecl.cpp:393:
                    clang::Decl*<unnamed>::TemplateDeclInstantiator::Visit
                    VarDecl(clang::VarDecl*): Assertion `InitArgs.size()
                    == 0' failed.
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: evan at chromium.org
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


clang @r98982.  Hit this when (attempting) to compile some v8 template soup.

InitArgs.size() == 2 when this assertion is being hit.  The code in
SemaTemplateInstantiateDecl.cpp only handles sizes of 1 or 0.

I will attempt to reduce this test case.

-- 
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 llvm.org  Fri Mar 19 18:30:27 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 19 Mar 2010 18:30:27 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6635] clang does not emit static c++ functions that
 are only used in an alias
In-Reply-To: <bug-6635-206@http.llvm.org/bugs/>
References: <bug-6635-206@http.llvm.org/bugs/>
Message-ID: <20100319233027.B03362A6C12E@llvm.org>

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

John McCall <rjmccall at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |rjmccall at apple.com
         Resolution|                            |FIXED

--- Comment #2 from John McCall <rjmccall at apple.com> 2010-03-19 18:30:27 CDT ---
Fixed in r99012.

-- 
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 llvm.org  Fri Mar 19 21:02:20 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 19 Mar 2010 21:02:20 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6658] New: clang's mmintrin.h fails in c89 mode
Message-ID: <bug-6658-206@http.llvm.org/bugs/>

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

           Summary: clang's mmintrin.h fails in c89 mode
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Headers
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: daniel at zuster.org
                CC: llvmbugs at cs.uiuc.edu


--
ddunbar at giles:tmp$ echo "#include <mmintrin.h>" | clang -x c -std=c89 -
In file included from <stdin>:1:
/Volumes/Data/Users/ddunbar/llvm.obj.64/Debug/lib/clang/1.5/include/mmintrin.h:37:8:
error: 
      unknown type name 'inline'
static inline void ...
       ^
/Volumes/Data/Users/ddunbar/llvm.obj.64/Debug/lib/clang/1.5/include/mmintrin.h:37:15:
error: 
      expected identifier or '('
static inline void ...
              ^
2 diagnostics generated.
--

-- 
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 llvm.org  Sat Mar 20 02:44:24 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 20 Mar 2010 02:44:24 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6659] New: ConstantUniqueMap::freeConstants may not
 free all constants
Message-ID: <bug-6659-206@http.llvm.org/bugs/>

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

           Summary: ConstantUniqueMap::freeConstants may not free all
                    constants
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Core LLVM classes
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: jyasskin at google.com
                CC: llvmbugs at cs.uiuc.edu


We have:

  void ConstantUniqueMap::freeConstants() {
    for (typename MapTy::iterator I=Map.begin(), E=Map.end();
         I != E; ++I) {
      if (I->second->use_empty())
        delete I->second;
    }
  }

Because this only deletes constants that aren't used anymore, its efficacy
depends on the order of the Map, which is unlikely to be exactly correct except
in tiny test cases where malloc's feeling cooperative. The obvious fix of
changing the "if() delete" to I->second->destroyConstant() doesn't work because
it can (but doesn't always) modify the very map we're iterating over. A
workset-based approach might work, where we insert all the possibly-cyclic
Constants into a single workset, pop one if it's used, or add its uses to the
workset and delete it if it's use-free. O(edges) rather than O(objects), but
that's still O(program-size).


This causes leaks like the one in CodeGen/X86/rodata-relocs.ll, where some
ConstantInts are kept alive because they're still used by some ConstantArrays
that should have been destroyed in freeConstants:

==27522== 248 (72 direct, 176 indirect) bytes in 1 blocks are definitely lost
in loss record 138 of 140
==27522==    at 0x4C229C7: operator new(unsigned long)
(vg_replace_malloc.c:220)
==27522==    by 0x11F0547: llvm::User::operator new(unsigned long, unsigned
int) (Use.cpp:171)
==27522==    by 0x1141F50: llvm::ConstantInt::operator new(unsigned long)
(Constants.h:57)
==27522==    by 0x11392E5: llvm::ConstantInt::get(llvm::LLVMContext&,
llvm::APInt const&) (Constants.cpp:296)
==27522==    by 0x996A20: llvm::LLParser::ConvertValIDToValue(llvm::Type
const*, llvm::ValID&, llvm::Value*&, llvm::LLParser::PerFunctionState*)
(LLParser.cpp:2515)
==27522==    by 0x995F53: llvm::LLParser::ParseGlobalValue(llvm::Type const*,
llvm::Constant*&) (LLParser.cpp:2431)
==27522==    by 0x9960A7:
llvm::LLParser::ParseGlobalTypeAndValue(llvm::Constant*&) (LLParser.cpp:2440)
==27522==    by 0x99615D:
llvm::LLParser::ParseGlobalValueVector(llvm::SmallVectorImpl<llvm::Constant*>&)
(LLParser.cpp:2455)
==27522==    by 0x993590: llvm::LLParser::ParseValID(llvm::ValID&,
llvm::LLParser::PerFunctionState*) (LLParser.cpp:2080)
==27522==    by 0x995F25: llvm::LLParser::ParseGlobalValue(llvm::Type const*,
llvm::Constant*&) (LLParser.cpp:2431)
==27522==    by 0x98BB51: llvm::LLParser::ParseGlobal(std::string const&,
llvm::SMLoc, unsigned int, bool, unsigned int) (LLParser.cpp:684)
==27522==    by 0x98A87C: llvm::LLParser::ParseNamedGlobal() (LLParser.cpp:460)
==27522== 
==27522== 248 (72 direct, 176 indirect) bytes in 1 blocks are definitely lost
in loss record 139 of 140
==27522==    at 0x4C229C7: operator new(unsigned long)
(vg_replace_malloc.c:220)
==27522==    by 0x11F0547: llvm::User::operator new(unsigned long, unsigned
int) (Use.cpp:171)
==27522==    by 0x1141F50: llvm::ConstantInt::operator new(unsigned long)
(Constants.h:57)
==27522==    by 0x11392E5: llvm::ConstantInt::get(llvm::LLVMContext&,
llvm::APInt const&) (Constants.cpp:296)
==27522==    by 0x996A20: llvm::LLParser::ConvertValIDToValue(llvm::Type
const*, llvm::ValID&, llvm::Value*&, llvm::LLParser::PerFunctionState*)
(LLParser.cpp:2515)
==27522==    by 0x995F53: llvm::LLParser::ParseGlobalValue(llvm::Type const*,
llvm::Constant*&) (LLParser.cpp:2431)
==27522==    by 0x9960A7:
llvm::LLParser::ParseGlobalTypeAndValue(llvm::Constant*&) (LLParser.cpp:2440)
==27522==    by 0x99615D:
llvm::LLParser::ParseGlobalValueVector(llvm::SmallVectorImpl<llvm::Constant*>&)
(LLParser.cpp:2455)
==27522==    by 0x993590: llvm::LLParser::ParseValID(llvm::ValID&,
llvm::LLParser::PerFunctionState*) (LLParser.cpp:2080)
==27522==    by 0x995F25: llvm::LLParser::ParseGlobalValue(llvm::Type const*,
llvm::Constant*&) (LLParser.cpp:2431)
==27522==    by 0x9960A7:
llvm::LLParser::ParseGlobalTypeAndValue(llvm::Constant*&) (LLParser.cpp:2440)
==27522==    by 0x996190:
llvm::LLParser::ParseGlobalValueVector(llvm::SmallVectorImpl<llvm::Constant*>&)
(LLParser.cpp:2459)
==27522== 


This may be related to or the same bug as PR2975.

-- 
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 llvm.org  Sat Mar 20 08:59:44 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 20 Mar 2010 08:59:44 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6660] New: clang-2.7 regressions with respect to
	clang-2.6
Message-ID: <bug-6660-206@http.llvm.org/bugs/>

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

           Summary: clang-2.7 regressions with respect to clang-2.6
           Product: new-bugs
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: baldrick at free.fr
                CC: llvmbugs at cs.uiuc.edu


This is on x86-32 linux.  Note that there are many additional clang-2.7
failures, but they also fail with clang-2.6.  This is only the list of
tests that pass with clang-2.6 but fail with clang-2.7.  Also, I did not
include cbe regressions.  I didn't analyze the failures yet.

MultiSource/Applications/JM/lencod/lencod (llc+jit):

llc:

TEST Output/lencod.llc FAILED: process terminated by signal (exit status 139)!

warning: Can't read pathname for load map: Input/output error.
Core was generated by `Output/lencod.llc -d
pre-release1/llvm-2.7/projects/llvm-'.
Program terminated with signal 11, Segmentation fault.
#0  0x0806ba19 in report ()
#0  0x0806ba19 in report ()

jit:

TEST pre-release1/release-build/llvm-objects/Release/bin/lli FAILED: process
terminated by signal (exit status 139)!


MultiSource/Applications/spiff/spiff (jit):

TEST pre-release1/release-build/llvm-objects/Release/bin/lli FAILED: process
terminated by signal (exit status 134)!


MultiSource/Applications/sqlite3/sqlite3 (jit):

TEST pre-release1/release-build/llvm-objects/Release/bin/lli FAILED: process
terminated by signal (exit status 139)!


SingleSource/Regression/C/2004-03-15-IndirectGoto (jit):

TEST pre-release1/release-build/llvm-objects/Release/bin/lli FAILED: process
terminated by signal (exit status 134)!


SingleSource/Regression/C/casts (llc+jit):

llc:

TEST Output/casts.llc FAILED: process terminated by signal (exit status 139)!

warning: Can't read pathname for load map: Input/output error.
Core was generated by `Output/casts.llc'.
Program terminated with signal 11, Segmentation fault.

jit:

TEST pre-release1/release-build/llvm-objects/Release/bin/lli FAILED: process
terminated by signal (exit status 139)!


SingleSource/UnitTests/2005-07-17-INT-To-FP (llc+jit):

llc:

TEST Output/2005-07-17-INT-To-FP.llc FAILED: process terminated by signal (exit
status 139)!

warning: core file may not match specified executable file.

warning: Can't read pathname for load map: Input/output error.
Core was generated by `Output/2005-07-17-INT-To-FP.llc'.
Program terminated with signal 11, Segmentation fault.

jit:

TEST pre-release1/release-build/llvm-objects/Release/bin/lli FAILED: process
terminated by signal (exit status 139)!

-- 
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 llvm.org  Sat Mar 20 15:55:10 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 20 Mar 2010 15:55:10 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6662] New: TableGen leaks lots of memory
Message-ID: <bug-6662-206@http.llvm.org/bugs/>

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

           Summary: TableGen leaks lots of memory
           Product: tools
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: TableGen
        AssignedTo: clattner at apple.com
        ReportedBy: jyasskin at google.com
                CC: llvmbugs at cs.uiuc.edu


For example, we have:

RecordVal::RecordVal(const std::string &N, RecTy *T, unsigned P)
  : Name(N), Ty(T), Prefix(P) {
  Value = Ty->convertValue(new UnsetInit());
...

but

Init *BitsRecTy::convertValue(UnsetInit *UI) {
  BitsInit *Ret = new BitsInit(Size);

  for (unsigned i = 0; i != Size; ++i)
    Ret->setBit(i, new UnsetInit());
  return Ret;
}

which simply drops its argument.


We can either fix tblgen, which could be a lot of work, or we can XFAIL its
tests under valgrind.

Here's a sample valgrind --leak-check=full run:


******************** TEST 'LLVM :: TableGen/eq.td' FAILED ********************
Script:
--
tblgen /Users/jyasskin/src/llvm/trunk/src/test/TableGen/eq.td | FileCheck
/Users/jyasskin/src/llvm/trunk/src/test/TableGen/eq.td
--
Exit Code: 1
Command Output (stdout):
--
Command has output on stderr!

--
Command Output (stderr):
--
==21657== Memcheck, a memory error detector
==21657== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==21657== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info
==21657== Command: tblgen
/Users/jyasskin/src/llvm/trunk/src/test/TableGen/eq.td
==21657== 
==21657== Warning: ignored attempt to set SIGUSR2 handler in sigaction();
==21657==          the SIGUSR2 signal is used internally by Valgrind
==21657== 
==21657== HEAP SUMMARY:
==21657==     in use at exit: 1,291 bytes in 44 blocks
==21657==   total heap usage: 220 allocs, 176 frees, 24,141 bytes allocated
==21657== 
==21657== 4 bytes in 1 blocks are definitely lost in loss record 7 of 31
==21657==    at 0x4CCAD3: operator new(unsigned long) (vg_replace_malloc.c:220)
==21657==    by 0xFF1AA: llvm::TGParser::ParseType() (TGParser.cpp:581)
==21657==    by 0x102BD2: llvm::TGParser::ParseDeclaration(llvm::Record*, bool)
(TGParser.cpp:1446)
==21657==    by 0x1093B2: llvm::TGParser::ParseBodyItem(llvm::Record*)
(TGParser.cpp:1528)
==21657==    by 0x109A33: llvm::TGParser::ParseBody(llvm::Record*)
(TGParser.cpp:1590)
==21657==    by 0x109D15: llvm::TGParser::ParseObjectBody(llvm::Record*)
(TGParser.cpp:1635)
==21657==    by 0x10A047: llvm::TGParser::ParseClass() (TGParser.cpp:1715)
==21657==    by 0x10B752: llvm::TGParser::ParseObject() (TGParser.cpp:2025)
==21657==    by 0x10B79C: llvm::TGParser::ParseObjectList() (TGParser.cpp:2034)
==21657==    by 0x10B7D9: llvm::TGParser::ParseFile() (TGParser.cpp:2042)
==21657==    by 0x11274E: ParseFile(std::string const&,
std::vector<std::string, std::allocator<std::string> > const&,
llvm::SourceMgr&) (TableGen.cpp:174)
==21657==    by 0x112821: main (TableGen.cpp:184)
==21657== 
==21657== 4 bytes in 1 blocks are definitely lost in loss record 8 of 31
==21657==    at 0x4CCAD3: operator new(unsigned long) (vg_replace_malloc.c:220)
==21657==    by 0xD6401: llvm::RecordVal::RecordVal(std::string const&,
llvm::RecTy*, unsigned int) (Record.cpp:1266)
==21657==    by 0x102F26: llvm::TGParser::ParseDeclaration(llvm::Record*, bool)
(TGParser.cpp:1469)
==21657==    by 0x1093B2: llvm::TGParser::ParseBodyItem(llvm::Record*)
(TGParser.cpp:1528)
==21657==    by 0x109A33: llvm::TGParser::ParseBody(llvm::Record*)
(TGParser.cpp:1590)
==21657==    by 0x109D15: llvm::TGParser::ParseObjectBody(llvm::Record*)
(TGParser.cpp:1635)
==21657==    by 0x10A047: llvm::TGParser::ParseClass() (TGParser.cpp:1715)
==21657==    by 0x10B752: llvm::TGParser::ParseObject() (TGParser.cpp:2025)
==21657==    by 0x10B79C: llvm::TGParser::ParseObjectList() (TGParser.cpp:2034)
==21657==    by 0x10B7D9: llvm::TGParser::ParseFile() (TGParser.cpp:2042)
==21657==    by 0x11274E: ParseFile(std::string const&,
std::vector<std::string, std::allocator<std::string> > const&,
llvm::SourceMgr&) (TableGen.cpp:174)
==21657==    by 0x112821: main (TableGen.cpp:184)
==21657== 
==21657== 8 bytes in 2 blocks are definitely lost in loss record 11 of 31
==21657==    at 0x4CCAD3: operator new(unsigned long) (vg_replace_malloc.c:220)
==21657==    by 0xD6401: llvm::RecordVal::RecordVal(std::string const&,
llvm::RecTy*, unsigned int) (Record.cpp:1266)
==21657==    by 0x102F26: llvm::TGParser::ParseDeclaration(llvm::Record*, bool)
(TGParser.cpp:1469)
==21657==    by 0x10325E: llvm::TGParser::ParseTemplateArgList(llvm::Record*)
(TGParser.cpp:1499)
==21657==    by 0x10A028: llvm::TGParser::ParseClass() (TGParser.cpp:1711)
==21657==    by 0x10B752: llvm::TGParser::ParseObject() (TGParser.cpp:2025)
==21657==    by 0x10B79C: llvm::TGParser::ParseObjectList() (TGParser.cpp:2034)
==21657==    by 0x10B7D9: llvm::TGParser::ParseFile() (TGParser.cpp:2042)
==21657==    by 0x11274E: ParseFile(std::string const&,
std::vector<std::string, std::allocator<std::string> > const&,
llvm::SourceMgr&) (TableGen.cpp:174)
==21657==    by 0x112821: main (TableGen.cpp:184)
==21657== 
==21657== 35 (12 direct, 23 indirect) bytes in 1 blocks are definitely lost in
loss record 23 of 31
==21657==    at 0x4CCAD3: operator new(unsigned long) (vg_replace_malloc.c:220)
==21657==    by 0xFE976: llvm::TGParser::ParseIDValue(llvm::Record*,
std::string const&, llvm::SMLoc) (TGParser.cpp:651)
==21657==    by 0x107530: llvm::TGParser::ParseSimpleValue(llvm::Record*,
llvm::RecTy*) (TGParser.cpp:1046)
==21657==    by 0x102335: llvm::TGParser::ParseValue(llvm::Record*,
llvm::RecTy*) (TGParser.cpp:1288)
==21657==    by 0x103034: llvm::TGParser::ParseDeclaration(llvm::Record*, bool)
(TGParser.cpp:1476)
==21657==    by 0x1093B2: llvm::TGParser::ParseBodyItem(llvm::Record*)
(TGParser.cpp:1528)
==21657==    by 0x109A33: llvm::TGParser::ParseBody(llvm::Record*)
(TGParser.cpp:1590)
==21657==    by 0x109D15: llvm::TGParser::ParseObjectBody(llvm::Record*)
(TGParser.cpp:1635)
==21657==    by 0x10A047: llvm::TGParser::ParseClass() (TGParser.cpp:1715)
==21657==    by 0x10B752: llvm::TGParser::ParseObject() (TGParser.cpp:2025)
==21657==    by 0x10B79C: llvm::TGParser::ParseObjectList() (TGParser.cpp:2034)
==21657==    by 0x10B7D9: llvm::TGParser::ParseFile() (TGParser.cpp:2042)
==21657==    by 0x11274E: ParseFile(std::string const&,
std::vector<std::string, std::allocator<std::string> > const&,
llvm::SourceMgr&) (TableGen.cpp:174)
==21657==    by 0x112821: main (TableGen.cpp:184)
==21657== 
==21657== 44 (24 direct, 20 indirect) bytes in 1 blocks are definitely lost in
loss record 25 of 31
==21657==    at 0x4CCAD3: operator new(unsigned long) (vg_replace_malloc.c:220)
==21657==    by 0xD5E9C: llvm::TernOpInit::resolveReferences(llvm::Record&,
llvm::RecordVal const*) (Record.cpp:998)
==21657==    by 0xDB9B6: llvm::Record::resolveReferencesTo(llvm::RecordVal
const*) (Record.cpp:1302)
==21657==    by 0x100A24: llvm::TGParser::AddSubClass(llvm::Record*,
llvm::SubClassReference&) (TGParser.cpp:168)
==21657==    by 0x109AF5: llvm::TGParser::ParseObjectBody(llvm::Record*)
(TGParser.cpp:1619)
==21657==    by 0x10A3ED: llvm::TGParser::ParseDef(llvm::MultiClass*)
(TGParser.cpp:1672)
==21657==    by 0x10B727: llvm::TGParser::ParseObject() (TGParser.cpp:2023)
==21657==    by 0x10B79C: llvm::TGParser::ParseObjectList() (TGParser.cpp:2034)
==21657==    by 0x10B7D9: llvm::TGParser::ParseFile() (TGParser.cpp:2042)
==21657==    by 0x11274E: ParseFile(std::string const&,
std::vector<std::string, std::allocator<std::string> > const&,
llvm::SourceMgr&) (TableGen.cpp:174)
==21657==    by 0x112821: main (TableGen.cpp:184)
==21657== 
==21657== 44 (24 direct, 20 indirect) bytes in 1 blocks are definitely lost in
loss record 26 of 31
==21657==    at 0x4CCAD3: operator new(unsigned long) (vg_replace_malloc.c:220)
==21657==    by 0xD5F3E: llvm::TernOpInit::resolveReferences(llvm::Record&,
llvm::RecordVal const*) (Record.cpp:1002)
==21657==    by 0xDB9B6: llvm::Record::resolveReferencesTo(llvm::RecordVal
const*) (Record.cpp:1302)
==21657==    by 0x100A24: llvm::TGParser::AddSubClass(llvm::Record*,
llvm::SubClassReference&) (TGParser.cpp:168)
==21657==    by 0x109AF5: llvm::TGParser::ParseObjectBody(llvm::Record*)
(TGParser.cpp:1619)
==21657==    by 0x10A3ED: llvm::TGParser::ParseDef(llvm::MultiClass*)
(TGParser.cpp:1672)
==21657==    by 0x10B727: llvm::TGParser::ParseObject() (TGParser.cpp:2023)
==21657==    by 0x10B79C: llvm::TGParser::ParseObjectList() (TGParser.cpp:2034)
==21657==    by 0x10B7D9: llvm::TGParser::ParseFile() (TGParser.cpp:2042)
==21657==    by 0x11274E: ParseFile(std::string const&,
std::vector<std::string, std::allocator<std::string> > const&,
llvm::SourceMgr&) (TableGen.cpp:174)
==21657==    by 0x112821: main (TableGen.cpp:184)
==21657== 
==21657== 116 (40 direct, 76 indirect) bytes in 2 blocks are definitely lost in
loss record 28 of 31
==21657==    at 0x4CCAD3: operator new(unsigned long) (vg_replace_malloc.c:220)
==21657==    by 0xD5D18: llvm::BinOpInit::resolveReferences(llvm::Record&,
llvm::RecordVal const*) (Record.cpp:759)
==21657==    by 0xD5DC0: llvm::TernOpInit::resolveReferences(llvm::Record&,
llvm::RecordVal const*) (Record.cpp:989)
==21657==    by 0xDB9B6: llvm::Record::resolveReferencesTo(llvm::RecordVal
const*) (Record.cpp:1302)
==21657==    by 0x100A24: llvm::TGParser::AddSubClass(llvm::Record*,
llvm::SubClassReference&) (TGParser.cpp:168)
==21657==    by 0x109AF5: llvm::TGParser::ParseObjectBody(llvm::Record*)
(TGParser.cpp:1619)
==21657==    by 0x10A3ED: llvm::TGParser::ParseDef(llvm::MultiClass*)
(TGParser.cpp:1672)
==21657==    by 0x10B727: llvm::TGParser::ParseObject() (TGParser.cpp:2023)
==21657==    by 0x10B79C: llvm::TGParser::ParseObjectList() (TGParser.cpp:2034)
==21657==    by 0x10B7D9: llvm::TGParser::ParseFile() (TGParser.cpp:2042)
==21657==    by 0x11274E: ParseFile(std::string const&,
std::vector<std::string, std::allocator<std::string> > const&,
llvm::SourceMgr&) (TableGen.cpp:174)
==21657==    by 0x112821: main (TableGen.cpp:184)
==21657== 
==21657== 164 (24 direct, 140 indirect) bytes in 1 blocks are definitely lost
in loss record 29 of 31
==21657==    at 0x4CCAD3: operator new(unsigned long) (vg_replace_malloc.c:220)
==21657==    by 0x10705B: llvm::TGParser::ParseOperation(llvm::Record*)
(TGParser.cpp:966)
==21657==    by 0x109130: llvm::TGParser::ParseSimpleValue(llvm::Record*,
llvm::RecTy*) (TGParser.cpp:1272)
==21657==    by 0x102335: llvm::TGParser::ParseValue(llvm::Record*,
llvm::RecTy*) (TGParser.cpp:1288)
==21657==    by 0x10355D: llvm::TGParser::ParseValueList(llvm::Record*,
llvm::Record*, llvm::RecTy*) (TGParser.cpp:1405)
==21657==    by 0x103C14: llvm::TGParser::ParseSubClassReference(llvm::Record*,
bool) (TGParser.cpp:397)
==21657==    by 0x109AAA: llvm::TGParser::ParseObjectBody(llvm::Record*)
(TGParser.cpp:1613)
==21657==    by 0x10A047: llvm::TGParser::ParseClass() (TGParser.cpp:1715)
==21657==    by 0x10B752: llvm::TGParser::ParseObject() (TGParser.cpp:2025)
==21657==    by 0x10B79C: llvm::TGParser::ParseObjectList() (TGParser.cpp:2034)
==21657==    by 0x10B7D9: llvm::TGParser::ParseFile() (TGParser.cpp:2042)
==21657==    by 0x11274E: ParseFile(std::string const&,
std::vector<std::string, std::allocator<std::string> > const&,
llvm::SourceMgr&) (TableGen.cpp:174)
==21657==    by 0x112821: main (TableGen.cpp:184)
==21657== 
==21657== LEAK SUMMARY:
==21657==    definitely lost: 140 bytes in 10 blocks
==21657==    indirectly lost: 279 bytes in 24 blocks
==21657==      possibly lost: 0 bytes in 0 blocks
==21657==    still reachable: 532 bytes in 2 blocks
==21657==         suppressed: 340 bytes in 8 blocks
==21657== Reachable blocks (those to which a pointer was found) are not shown.
==21657== To see them, rerun with: --leak-check=full --show-reachable=yes
==21657== 
==21657== For counts of detected and suppressed errors, rerun with: -v
==21657== ERROR SUMMARY: 8 errors from 8 contexts (suppressed: 0 from 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 llvm.org  Sat Mar 20 15:58:44 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 20 Mar 2010 15:58:44 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6663] New: MultiSource/Benchmarks/Bullet/bullet
 fails on x86-32 linux when using -fPIC
Message-ID: <bug-6663-206@http.llvm.org/bugs/>

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

           Summary: MultiSource/Benchmarks/Bullet/bullet fails on x86-32
                    linux when using -fPIC
           Product: new-bugs
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: baldrick at free.fr
                CC: llvmbugs at cs.uiuc.edu


Split out of PR6654.

Compiling bullet like this works:

$ llvm-g++ -o bullet -O2 -I include -DNO_TIME *.cpp
$ ./bullet 
BenchmarkDemo: 3000 fall, Frame: 0
BenchmarkDemo: 3000 fall, Frame: 25
...

Adding -fPIC causes it to fail (the testsuite uses pic, which is why bullet
fails there):

$ llvm-g++ -o bullet -O2 -I include -DNO_TIME *.cpp -fPIC
$ ./bullet 
Segmentation fault (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 llvm.org  Sat Mar 20 16:42:48 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 20 Mar 2010 16:42:48 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6604] Combine Instructions phase generates bogus
 offset with some record types
In-Reply-To: <bug-6604-206@http.llvm.org/bugs/>
References: <bug-6604-206@http.llvm.org/bugs/>
Message-ID: <20100320214248.3EE9E2A6C12C@llvm.org>

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

Mike Blaguszewski <bugzilla at quickbrownfox.org> changed:

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

--- Comment #2 from Mike Blaguszewski <bugzilla at quickbrownfox.org> 2010-03-20 16:42:47 CDT ---
(In reply to comment #1)
> Is this already fixed with 2.7?

I just got around to trying my example with the svn trunk, and it no longer
attempts to perform the bogus optimization, either with -instcombine or
-std-compile-opts.

-- 
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 llvm.org  Sat Mar 20 17:21:14 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 20 Mar 2010 17:21:14 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6652] ARMv4: missed optimization for LDM + return
In-Reply-To: <bug-6652-206@http.llvm.org/bugs/>
References: <bug-6652-206@http.llvm.org/bugs/>
Message-ID: <20100320222114.62B4F2A6C12D@llvm.org>

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

Bob Wilson <bob.wilson at apple.com> changed:

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

--- Comment #2 from Bob Wilson <bob.wilson at apple.com> 2010-03-20 17:21:14 CDT ---
Patch committed in svn r99096.  Thanks, John!

-- 
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 llvm.org  Sat Mar 20 19:01:09 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 20 Mar 2010 19:01:09 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6664] New: llvm.atomic.load.nand poorly documented
Message-ID: <bug-6664-206@http.llvm.org/bugs/>

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

           Summary: llvm.atomic.load.nand poorly documented
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: Common Code Generator Code
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: eschew at gmail.com
                CC: dalej at apple.com, llvmbugs at cs.uiuc.edu


Most programmers would expect an operation called "nand" to perform ~(A & B),
but llvm.atomic.load.nand performs (A & ~B). According to ddunbar, this was
done for compatibility with gcc, but gcc has changed its behavior in version
4.4 to match the intended semantics:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37908#c6

To further confuse matters, example code given at
http://llvm.org/docs/LangRef.html#int_atomic_load_nand implies that
llvm.atomic.load.nand performs a traditional NAND operation, rather than (A &
~B).

It seems like either:
1) The behavior of llvm.atomic.load.nand should be changed to match GCC 4.4
(and its name), or
2) llvm.atomic.load.nand should be renamed to something like
llvm.atomic.load.andn, and the documentation updated to reflect its true
semantics.

-- 
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 llvm.org  Sat Mar 20 22:43:08 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 20 Mar 2010 22:43:08 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6662] TableGen leaks lots of memory
In-Reply-To: <bug-6662-206@http.llvm.org/bugs/>
References: <bug-6662-206@http.llvm.org/bugs/>
Message-ID: <20100321034308.082162A6C12D@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #1 from Chris Lattner <clattner at apple.com> 2010-03-20 22:43:07 CDT ---
Yep, your right, it was intended to.

-- 
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 llvm.org  Sun Mar 21 01:56:53 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 21 Mar 2010 01:56:53 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6665] New: asm variables
Message-ID: <bug-6665-206@http.llvm.org/bugs/>

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

           Summary: asm variables
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: LLVM Codegen
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: nicholas at mxc.ca
                CC: llvmbugs at cs.uiuc.edu


Some simple register variables should lower from:

  void foo1(void *newfoo) {
    register void *foo __asm__("r8")  = newfoo;
    foo = 5;
  }

to:

  define void @foo1(i8* %newtls) nounwind {
  entry:
    tail call void asm sideeffect "", "{r8}"(i8* %newtls) nounwind
    tail call void asm sideeffect "", "{r8}"(i8* inttoptr (i64 5 to i8*))
nounwind
    ret void
  }

llvm-gcc supports this so it can serve as a reference.

-- 
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 llvm.org  Sun Mar 21 08:18:35 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 21 Mar 2010 08:18:35 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6666] New: llvm-gcc fails to emit volatile for
 volatile array struct argument?
Message-ID: <bug-6666-206@http.llvm.org/bugs/>

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

           Summary: llvm-gcc fails to emit volatile for volatile array
                    struct argument?
           Product: new-bugs
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: zhousheng00 at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Case here:

struct X {
  int a;
  int b;
  int c;
};
int foo(volatile struct X x[100]) {
  int i;
  int r = 0;
  for (i = 0; i < 100; ++i)
    r += x[i].a;
}

With ToT, in the emitted ll code, the volatile for LoadInst of x[100] is lost.

-- 
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 llvm.org  Sun Mar 21 10:37:03 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 21 Mar 2010 10:37:03 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6667] New: Unnecessary duplicate warnings about
 undeclared identifiers
Message-ID: <bug-6667-206@http.llvm.org/bugs/>

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

           Summary: Unnecessary duplicate warnings about undeclared
                    identifiers
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: tss at iki.fi
                CC: llvmbugs at cs.uiuc.edu


Getting multiple warnings about the same problem bloats the error list
unnecessarily and makes it more laborious to go through all the errors in one
compile output. For example:

int main(void) {
    int y;

    y = x;
    y = x;
    return 0;
}

% clang test2.c -o test2
test2.c:4:6: error: use of undeclared identifier 'x'
        y = x;
            ^
test2.c:5:6: error: use of undeclared identifier 'x'
        y = x;
            ^
2 diagnostics generated.

gcc's output is nicer:

% gcc test2.c -o test2
test2.c: In function ?main?:
test2.c:4: error: ?x? undeclared (first use in this function)
test2.c:4: error: (Each undeclared identifier is reported only once
test2.c:4: error: for each function it appears in.)

-- 
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 llvm.org  Sun Mar 21 10:58:19 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 21 Mar 2010 10:58:19 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6668] New: Debug info: Source file paths should be
	absolute
Message-ID: <bug-6668-206@http.llvm.org/bugs/>

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

           Summary: Debug info: Source file paths should be absolute
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: tss at iki.fi
                CC: llvmbugs at cs.uiuc.edu


(If there's a way to configure this, I didn't find it with a few google
searches, and the default should anyway be the same as with gcc.)

clang stores source code path using the same name as they were given to clang.
So typically as "./file.c". This makes debugging pretty difficult for projects
that have multiple source code directories, since gdb always just complains
about missing source code file. Also even for simple programs it won't work if
you try to debug it while working dir isn't the same as the source code dir.

Here's a simple example:

~% clang test2.c -o test -g
~% cd m
~/m% gdb ../test
(gdb) b main
Breakpoint 1 at 0x400509: file ./test2.c, line 4.
(gdb) r
Starting program: /home/tss/test 

Breakpoint 1, main () at ./test2.c:4
4       ./test2.c: No such file or directory.
        in ./test2.c

gcc does what I expected:

(gdb) r
Starting program: /home/tss/test 

Breakpoint 1, main () at test2.c:4
4               printf("foo\n");

-- 
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 llvm.org  Sun Mar 21 12:17:35 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 21 Mar 2010 12:17:35 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6648] getASTRecordLayout crash on valid
In-Reply-To: <bug-6648-206@http.llvm.org/bugs/>
References: <bug-6648-206@http.llvm.org/bugs/>
Message-ID: <20100321171735.EFBCD2A6C12D@llvm.org>

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

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

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

--- Comment #7 from Rafael ?vila de Esp?ndola <rafael.espindola at gmail.com> 2010-03-21 12:17:35 CDT ---
Fixed in r99134

-- 
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 llvm.org  Sun Mar 21 15:34:15 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 21 Mar 2010 15:34:15 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6669] New: clang-2.7: fails 8 tests when building
	self
Message-ID: <bug-6669-206@http.llvm.org/bugs/>

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

           Summary: clang-2.7: fails 8 tests when building self
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: edwintorok at gmail.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


LLVM/Clang-2.7 built with gcc 4.4.3 passes all tests.
If built with self, it fails 8.

The first llvm/clang-2.7 was built like this in /home/edwin/llvm2.7/llvm-2.7
$ ./configure
$ make

The second one in /home/edwin/llvm2.7/clangself/llvm-2.7
./configure CC=/home/edwin/llvm2.7/llvm-2.7/Release/bin/clang
CXX=/home/edwin/llvm2.7/llvm-2.7/Release/bin/clang++

                ===  Summary ===

# of expected passes            4319
# of unexpected failures        8
# of expected failures          23

FAIL:
/home/edwin/llvm2.7/clangself/llvm-2.7/test/CodeGen/PIC16/2009-07-17-PR4566-pic16.ll 
Failed with exit(1) at line 1                                                   
while running:  llc <
/home/edwin/llvm2.7/clangself/llvm-2.7/test/CodeGen/PIC16/2009-07-17-PR4566-pic16.ll
-march=pic16 | FileCheck
/home/edwin/llvm2.7/clangself/llvm-2.7/test/CodeGen/PIC16/2009-07-17-PR4566-pic16.ll 
0  llc             0x0000000000ac6daf                                           
1  llc             0x0000000000ac72b9                                           
2  libpthread.so.0 0x0000003b3b00e990                                           
3  libstdc++.so.6  0x0000003cd5a69d11 std::locale::operator=(std::locale
const&) + 33                                         
4  libstdc++.so.6  0x0000003cd5a6882f std::ios_base::_M_init() + 63             
5  libstdc++.so.6  0x0000003cd5a7d2a9 std::basic_ios<char,
std::char_traits<char> >::init(std::basic_streambuf<char,
std::char_traits<char> >*) + 25                                                 
6  llc             0x000000000050106b                                           
7  llc             0x00000000004ffcd1                                           
8  llc             0x00000000004ff2bf                                           
9  llc             0x00000000004f8349                                           
10 llc             0x0000000000a57390                                           
11 llc             0x0000000000a571cc                                           
12 llc             0x0000000000a5717c                                           
13 llc             0x000000000042585f                                           
14 libc.so.6       0x0000003b3a41eabd __libc_start_main + 253                   
15 llc             0x0000000000424059                                           
Stack dump:                                                                     
0.      Program arguments: llc -march=pic16                                     
/home/edwin/llvm2.7/clangself/llvm-2.7/test/CodeGen/PIC16/2009-07-17-PR4566-pic16.ll:31:10:
error: expected string not found in input                                       
; CHECK: movf @i + 0, W                                                         
         ^                                                                      
<stdin>:1:1: note: scanning from here                                           

^

FAIL:
/home/edwin/llvm2.7/clangself/llvm-2.7/test/CodeGen/PIC16/2009-11-20-NewNode.ll
for PR5558
Failed with signal(SIGSEGV) at line 1                                           
while running:  llc -march=pic16 <
/home/edwin/llvm2.7/clangself/llvm-2.7/test/CodeGen/PIC16/2009-11-20-NewNode.ll
0  llc             0x0000000000ac6daf                                           
1  llc             0x0000000000ac72b9                                           
2  libpthread.so.0 0x0000003b3b00e990                                           
3  libstdc++.so.6  0x0000003cd5a69d11 std::locale::operator=(std::locale
const&) + 33                             
4  libstdc++.so.6  0x0000003cd5a6882f std::ios_base::_M_init() + 63             
5  libstdc++.so.6  0x0000003cd5a7d2a9 std::basic_ios<char,
std::char_traits<char> >::init(std::basic_streambuf<char,
std::char_traits<char> >*) + 25                                                 
6  llc             0x0000000000501432                                           
7  llc             0x000000000050ed00                                           
8  llc             0x0000000000827959                                           
9  llc             0x0000000000a57798                                           
10 llc             0x0000000000a57099                                           
11 llc             0x0000000000a56f9f                                           
12 llc             0x00000000004258e7                                           
13 libc.so.6       0x0000003b3a41eabd __libc_start_main + 253                   
14 llc             0x0000000000424059                                           
Stack dump:                                                                     
0.      Program arguments: llc -march=pic16                                     
1.      Running pass 'PIC16 Memsel Optimizer' on function '@_strtoll_r'         

FAIL: /home/edwin/llvm2.7/clangself/llvm-2.7/test/CodeGen/PIC16/C16-15.ll
Failed with exit(1) at line 1                                            
while running:  llc <
/home/edwin/llvm2.7/clangself/llvm-2.7/test/CodeGen/PIC16/C16-15.ll
-march=pic16 | /bin/grep "extern" | /bin/grep "@.lib.unordered.f32" | count 3   
0  llc             0x0000000000ac6daf                                           
1  llc             0x0000000000ac72b9                                           
2  libpthread.so.0 0x0000003b3b00e990                                           
3  libstdc++.so.6  0x0000003cd5a69d11 std::locale::operator=(std::locale
const&) + 33                                         
4  libstdc++.so.6  0x0000003cd5a6882f std::ios_base::_M_init() + 63             
5  libstdc++.so.6  0x0000003cd5a7d2a9 std::basic_ios<char,
std::char_traits<char> >::init(std::basic_streambuf<char,
std::char_traits<char> >*) + 25                                                 
6  llc             0x000000000050106b                                           
7  llc             0x00000000004ffcd1                                           
8  llc             0x00000000004ff2bf                                           
9  llc             0x00000000004f8349                                           
10 llc             0x0000000000a57390                                           
11 llc             0x0000000000a571cc                                           
12 llc             0x0000000000a5717c                                           
13 llc             0x000000000042585f                                           
14 libc.so.6       0x0000003b3a41eabd __libc_start_main + 253                   
15 llc             0x0000000000424059                                           
Stack dump:                                                                     
0.      Program arguments: llc -march=pic16                                     
Expected 3 lines, got 0.                                                        

FAIL: /home/edwin/llvm2.7/clangself/llvm-2.7/test/CodeGen/PIC16/C16-49.ll
Failed with signal(SIGSEGV) at line 1                                    
while running:  llvm-as <
/home/edwin/llvm2.7/clangself/llvm-2.7/test/CodeGen/PIC16/C16-49.ll |  llc
-march=pic16
0  llc             0x0000000000ac6daf                                           
1  llc             0x0000000000ac72b9                                           
2  libpthread.so.0 0x0000003b3b00e990                                           
3  libstdc++.so.6  0x0000003cd5a69d11 std::locale::operator=(std::locale
const&) + 33                            
4  libstdc++.so.6  0x0000003cd5a6882f std::ios_base::_M_init() + 63             
5  libstdc++.so.6  0x0000003cd5a7d2a9 std::basic_ios<char,
std::char_traits<char> >::init(std::basic_streambuf<char,
std::char_traits<char> >*) + 25                                                 
6  llc             0x000000000050106b                                           
7  llc             0x00000000004ffcd1                                           
8  llc             0x00000000004ff2bf                                           
9  llc             0x00000000004f8349                                           
10 llc             0x0000000000a57390                                           
11 llc             0x0000000000a571cc                                           
12 llc             0x0000000000a5717c                                           
13 llc             0x000000000042585f                                           
14 libc.so.6       0x0000003b3a41eabd __libc_start_main + 253                   
15 llc             0x0000000000424059                                           
Stack dump:                                                                     
0.      Program arguments: llc -march=pic16                                     

FAIL:
/home/edwin/llvm2.7/clangself/llvm-2.7/test/CodeGen/PIC16/result_direction.ll
Failed with exit(1) at line 1                                                   
while running:  llvm-as <
/home/edwin/llvm2.7/clangself/llvm-2.7/test/CodeGen/PIC16/result_direction.ll |
 llc -march=pic16 | FileCheck
/home/edwin/llvm2.7/clangself/llvm-2.7/test/CodeGen/PIC16/result_direction.ll   
0  llc             0x0000000000ac6daf                                           
1  llc             0x0000000000ac72b9                                           
2  libpthread.so.0 0x0000003b3b00e990                                           
3  libstdc++.so.6  0x0000003cd5a69d11 std::locale::operator=(std::locale
const&) + 33                                         
4  libstdc++.so.6  0x0000003cd5a6882f std::ios_base::_M_init() + 63             
5  libstdc++.so.6  0x0000003cd5a7d2a9 std::basic_ios<char,
std::char_traits<char> >::init(std::basic_streambuf<char,
std::char_traits<char> >*) + 25                                                 
6  llc             0x0000000000500ded                                           
7  llc             0x00000000004ff941                                           
8  llc             0x00000000004ff27a                                           
9  llc             0x00000000004f8349                                           
10 llc             0x0000000000a57390                                           
11 llc             0x0000000000a571cc                                           
12 llc             0x0000000000a5717c                                           
13 llc             0x000000000042585f                                           
14 libc.so.6       0x0000003b3a41eabd __libc_start_main + 253                   
15 llc             0x0000000000424059                                           
Stack dump:                                                                     
0.      Program arguments: llc -march=pic16                                     
/home/edwin/llvm2.7/clangself/llvm-2.7/test/CodeGen/PIC16/result_direction.ll:10:9:
error: expected string not found in input 
;CHECK: movlw 1                                                                 
        ^                                                                       
<stdin>:1:1: note: scanning from here                                           

^

FAIL: /home/edwin/llvm2.7/clangself/llvm-2.7/test/CodeGen/PIC16/sext.ll
Failed with signal(SIGSEGV) at line 1                                  
while running:  llc <
/home/edwin/llvm2.7/clangself/llvm-2.7/test/CodeGen/PIC16/sext.ll -march=pic16
0  llc             0x0000000000ac6daf                                           
1  llc             0x0000000000ac72b9                                           
2  libpthread.so.0 0x0000003b3b00e990                                           
3  libstdc++.so.6  0x0000003cd5a69d11 std::locale::operator=(std::locale
const&) + 33               
4  libstdc++.so.6  0x0000003cd5a6882f std::ios_base::_M_init() + 63             
5  libstdc++.so.6  0x0000003cd5a7d2a9 std::basic_ios<char,
std::char_traits<char> >::init(std::basic_streambuf<char,
std::char_traits<char> >*) + 25                                                 
6  llc             0x0000000000501432                                           
7  llc             0x000000000050ed00                                           
8  llc             0x0000000000827959                                           
9  llc             0x0000000000a57798                                           
10 llc             0x0000000000a57099                                           
11 llc             0x0000000000a56f9f                                           
12 llc             0x00000000004258e7                                           
13 libc.so.6       0x0000003b3a41eabd __libc_start_main + 253                   
14 llc             0x0000000000424059                                           
Stack dump:                                                                     
0.      Program arguments: llc -march=pic16                                     
1.      Running pass 'PIC16 Memsel Optimizer' on function '@main'               

FAIL:
/home/edwin/llvm2.7/clangself/llvm-2.7/test/CodeGen/PIC16/test_indf_name.ll
Failed with exit(1) at line 1                                                   
while running:  llvm-as <
/home/edwin/llvm2.7/clangself/llvm-2.7/test/CodeGen/PIC16/test_indf_name.ll | 
llc -march=pic16 | FileCheck
/home/edwin/llvm2.7/clangself/llvm-2.7/test/CodeGen/PIC16/test_indf_name.ll     
0  llc             0x0000000000ac6daf                                           
1  llc             0x0000000000ac72b9                                           
2  libpthread.so.0 0x0000003b3b00e990                                           
3  libstdc++.so.6  0x0000003cd5a69d11 std::locale::operator=(std::locale
const&) + 33                                         
4  libstdc++.so.6  0x0000003cd5a6882f std::ios_base::_M_init() + 63             
5  libstdc++.so.6  0x0000003cd5a7d2a9 std::basic_ios<char,
std::char_traits<char> >::init(std::basic_streambuf<char,
std::char_traits<char> >*) + 25                                                 
6  llc             0x0000000000500ded                                           
7  llc             0x00000000004ff941                                           
8  llc             0x00000000004ff27a                                           
9  llc             0x00000000004f8349                                           
10 llc             0x0000000000a57390                                           
11 llc             0x0000000000a571cc                                           
12 llc             0x0000000000a5717c                                           
13 llc             0x000000000042585f                                           
14 libc.so.6       0x0000003b3a41eabd __libc_start_main + 253                   
15 llc             0x0000000000424059                                           
Stack dump:                                                                     
0.      Program arguments: llc -march=pic16                                     
/home/edwin/llvm2.7/clangself/llvm-2.7/test/CodeGen/PIC16/test_indf_name.ll:9:10:
error: expected string not found in input   
; CHECK: movwi {{[0-1]}}[INDF{{[0-1]}}]                                         
         ^                                                                      
<stdin>:1:1: note: scanning from here                                           

FAIL: /home/edwin/llvm2.7/clangself/llvm-2.7/test/Feature/load_module.ll for
PR1318
Failed with exit(1) at line 1                                                   
while running:  opt <
/home/edwin/llvm2.7/clangself/llvm-2.7/test/Feature/load_module.ll
-load=/home/edwin/llvm2.7/clangself/llvm-2.7/Release/lib/LLVMHello.so -hello 
-disable-output |& /bin/grep Hello                                              
Error opening
'/home/edwin/llvm2.7/clangself/llvm-2.7/Release/lib/LLVMHello.so':
/home/edwin/llvm2.7/clangself/llvm-2.7/Release/lib/LLVMHello.so: undefined
symbol: _ZNK4llvm4Pass11getPassNameEv                                           
child process exited abnormally

-- 
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 llvm.org  Sun Mar 21 17:13:18 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 21 Mar 2010 17:13:18 -0500 (CDT)
Subject: [LLVMbugs] [Bug 803] InlineAsm objects are not uniqued
In-Reply-To: <bug-803-206@http.llvm.org/bugs/>
References: <bug-803-206@http.llvm.org/bugs/>
Message-ID: <20100321221318.3A1852A6C12D@llvm.org>

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

Jeffrey Yasskin <jyasskin at google.com> changed:

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

--- Comment #5 from Jeffrey Yasskin <jyasskin at google.com> 2010-03-21 17:13:17 CDT ---
Fixed by r99143.

-- 
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 llvm.org  Sun Mar 21 18:02:15 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 21 Mar 2010 18:02:15 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6618] ASTRecordLayoutBuilder crash on invalid
In-Reply-To: <bug-6618-206@http.llvm.org/bugs/>
References: <bug-6618-206@http.llvm.org/bugs/>
Message-ID: <20100321230215.309812A6C12D@llvm.org>

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

Rafael ?vila de Esp?ndola <rafael.espindola 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 llvm.org  Sun Mar 21 18:55:15 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 21 Mar 2010 18:55:15 -0500 (CDT)
Subject: [LLVMbugs] [Bug 4841] [x86] cmov generated even on -mcpu=pentium
In-Reply-To: <bug-4841-206@http.llvm.org/bugs/>
References: <bug-4841-206@http.llvm.org/bugs/>
Message-ID: <20100321235515.D5CA22A6C12C@llvm.org>

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

Craig Smith <craig at ni.com> changed:

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

--- Comment #9 from Craig Smith <craig at ni.com> 2010-03-21 18:55:15 CDT ---
I'm reopening this because the current patch, while disabling CMOV and FCMOV
instructions, fails to also
disable the FCOMI/FCOMIP/ FUCOMI/FUCOMIP instructions which were added to the
Pentium Pro at the same time as conditional moves. 

There don't seem to be any models of CPU which support FCOMI and friends but do
not support conditional moves, so it makes sense to tie them to the -cmov
attribute as well.

As it stands, using -cmov is not sufficient to generate code which will run on
pentium and earlier CPUs.

I'm attaching a proposed patch which ties FCOMI, etc. to the -cmov attribute.

-- 
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 llvm.org  Sun Mar 21 23:33:45 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 21 Mar 2010 23:33:45 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6670] New: lli fails to run non-trivial trampoline
	calls
Message-ID: <bug-6670-206@http.llvm.org/bugs/>

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

           Summary: lli fails to run non-trivial trampoline calls
           Product: tools
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: lli
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: eschew at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=4564)
 --> (http://llvm.org/bugs/attachment.cgi?id=4564)
Trampoline call causes LLI segfault.

Attached is a small C testcase. It runs correctly when compiled via:

1) gcc
2) llvm-gcc
3) llvm-gcc -emit-llvm, then llc, then gcc

However, given the bytecode from step 3 above, which llc/gcc compiles
correctly, lli segfaults.

I tried using bugpoint to reduce the .ll but bugpoint had no effect due to CBE
problems.

Tested with LLVM 2.6 and 2.7svn, r98692, both on x86 Linux.

-- 
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 llvm.org  Mon Mar 22 00:29:03 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 22 Mar 2010 00:29:03 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6659] ConstantUniqueMap::freeConstants may not free
 all constants
In-Reply-To: <bug-6659-206@http.llvm.org/bugs/>
References: <bug-6659-206@http.llvm.org/bugs/>
Message-ID: <20100322052903.866052A6C12D@llvm.org>

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

Jeffrey Yasskin <jyasskin at google.com> changed:

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

--- Comment #1 from Jeffrey Yasskin <jyasskin at google.com> 2010-03-22 00:29:03 CDT ---
Fixed by r99160.

-- 
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 llvm.org  Mon Mar 22 01:02:37 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 22 Mar 2010 01:02:37 -0500 (CDT)
Subject: [LLVMbugs] [Bug 2975] memory leak in Type.cpp and Constants.cpp
In-Reply-To: <bug-2975-206@http.llvm.org/bugs/>
References: <bug-2975-206@http.llvm.org/bugs/>
Message-ID: <20100322060237.77D002A6C12E@llvm.org>

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

Jeffrey Yasskin <jyasskin at google.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |jyasskin at google.com
         Resolution|                            |FIXED

--- Comment #19 from Jeffrey Yasskin <jyasskin at google.com> 2010-03-22 01:02:36 CDT ---
`valgrind --leak-check=full Debug/examples/HowToUseJIT` no longer reports any
leaks, so I'm closing this as 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 llvm.org  Mon Mar 22 03:26:03 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 22 Mar 2010 03:26:03 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6671] New: Fail to call destructor for explicitly
 created temporary in function template
Message-ID: <bug-6671-206@http.llvm.org/bugs/>

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

           Summary: Fail to call destructor for explicitly created
                    temporary in function template
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: LLVM Codegen
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: chandlerc at gmail.com
                CC: llvmbugs at cs.uiuc.edu


% cat leak.cc
#include <cstdio>

struct X {
  X()  { std::fprintf(stderr, "Constructing %p\n", this); }
  ~X() { std::fprintf(stderr, "Destructing %p\n", this); }
};

template <int N> void g() {
  (void)X();
}

int main() {
  (void)X();
  (void)g<1>();
  return 0;
}

% clang -o leak leak.cc && ./leak 
Constructing 0x7fff0c09a050
Destructing 0x7fff0c09a050
Constructing 0x7fff0c09a038

-- 
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 llvm.org  Mon Mar 22 04:15:32 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 22 Mar 2010 04:15:32 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6672] New: Assertion failed: (isa<X>(Val) &&
 "cast<Ty>() argument of incompatible type!"), function cast,
 file /data/home/rdivacky/llvm/include/llvm/Support/Casting.h, line 200.
Message-ID: <bug-6672-206@http.llvm.org/bugs/>

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

           Summary: Assertion failed: (isa<X>(Val) && "cast<Ty>() argument
                    of incompatible type!"), function cast, file
                    /data/home/rdivacky/llvm/include/llvm/Support/Casting.
                    h, line 200.
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Interprocedural Optimizations
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: rdivacky at freebsd.org
                CC: llvmbugs at cs.uiuc.edu


pes delta$ cat ios.cc
   typedef int _Atomic_word;
    namespace __gnu_cxx __attribute__ ((__visibility__ ("default"))) {
            static inline _Atomic_word   __exchange_and_add(volatile
_Atomic_word* __mem, int __val)   {
   }
       static inline _Atomic_word   __attribute__ ((__unused__))  
__exchange_and_add_dispatch(_Atomic_word* __mem, int __val)   {
        }
     }
      namespace __gnu_cxx __attribute__ ((__visibility__ ("default"))) {
       class locale   {
     };
     }
     namespace std __attribute__ ((__visibility__ ("default"))) {
           enum _Ios_Fmtflags     {
         _S_boolalpha = 1L << 0,       _S_dec = 1L << 1,       _S_fixed = 1L <<
2,       _S_hex = 1L << 3,       _S_internal = 1L << 4,       _S_left = 1L <<
5,       _S_oct = 1L << 6,       _S_right = 1L << 7,       _S_scientific = 1L
<< 8,       _S_showbase = 1L << 9,       _S_showpoint = 1L << 10,      
_S_showpos = 1L << 11,       _S_skipws = 1L << 12,       _S_unitbuf = 1L << 13,
      _S_uppercase = 1L << 14,       _S_adjustfield = _S_left | _S_right |
_S_internal,       _S_basefield = _S_dec | _S_oct | _S_hex,       _S_floatfield
= _S_scientific | _S_fixed,       _S_ios_fmtflags_end = 1L << 16     };
       class ios_base   {
        static int     xalloc() throw();
     };
        int   ios_base::xalloc() throw()   {
         static _Atomic_word _S_top = 0;
       return __gnu_cxx::__exchange_and_add_dispatch(&_S_top, 1) + 4;
     }
     }


pes delta$ clang++ -O2 ios.cc
ios.cc:4:4: warning: control reaches end of non-void function [-Wreturn-type]
   }
   ^
ios.cc:6:9: warning: control reaches end of non-void function [-Wreturn-type]
        }
        ^
Assertion failed: (isa<X>(Val) && "cast<Ty>() argument of incompatible type!"),
function cast, file /data/home/rdivacky/llvm/include/llvm/Support/Casting.h,
line 200.
Stack dump:
0.      Program arguments: /usr/local/bin/clang -cc1 -triple
x86_64-unknown-freebsd8.0 -S -disable-free -main-file-name ios.cc
-mrelocation-model static -mdisable-fp-elim -mconstructor-aliases
-munwind-tables -target-cpu x86-64 -resource-dir /usr/local/lib/clang/1.5 -O2
-fmessage-length 116 -fexceptions -fgnu-runtime -fdiagnostics-show-option
-fcolor-diagnostics -o /tmp/cc-SAAis0.s -x c++ ios.cc 
1.      <eof> parser at end of file
2.      Per-module optimization passes
3.      Running pass 'Interprocedural Sparse Conditional Constant Propagation'
on module 'ios.cc'.
clang: error: compiler command failed due to signal 6 (use -v to see
invocation)

-- 
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 llvm.org  Mon Mar 22 05:02:43 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 22 Mar 2010 05:02:43 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6672] Assertion failed: (isa<X>(Val) && "cast<Ty>()
 argument of incompatible type!"), function cast,
 file /data/home/rdivacky/llvm/include/llvm/Support/Casting.h, line 200.
In-Reply-To: <bug-6672-206@http.llvm.org/bugs/>
References: <bug-6672-206@http.llvm.org/bugs/>
Message-ID: <20100322100243.895732A6C12C@llvm.org>

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

Roman Divacky <rdivacky at freebsd.org> changed:

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

--- Comment #3 from Roman Divacky <rdivacky at freebsd.org> 2010-03-22 05:02:43 CDT ---
this was caused by r99170

-- 
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 llvm.org  Mon Mar 22 05:35:55 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 22 Mar 2010 05:35:55 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6673] New: Use of blockadress() crashes llc in some
	cases
Message-ID: <bug-6673-206@http.llvm.org/bugs/>

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

           Summary: Use of blockadress() crashes llc in some cases
           Product: new-bugs
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: schlunki at cs.tu-berlin.de
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=4566)
 --> (http://llvm.org/bugs/attachment.cgi?id=4566)
test-cases, that crashes llc

In some cases the use of blockaddress() crashes llc. 

I've attached two test-cases, one that crashes and for reference a slightly
modified one (just 2 lines are commented) that works. 

I compile the files with 
        # llvm-as test_crash.ll -o - | llc -f -o temp.s -

and get

0  llc             0x0000000000c6ab6f
1  llc             0x0000000000c6b38d
2  libpthread.so.0 0x00007feccd2270f0
3  llc             0x00000000009a270f
llvm::DenseMap<llvm::AssertingVH<llvm::BasicBlock>,
llvm::MMIAddrLabelMap::AddrLabelSymEntry,
llvm::DenseMapInfo<llvm::AssertingVH<llvm::BasicBlock> >,
llvm::DenseMapInfo<llvm::MMIAddrLabelMap::AddrLabelSymEntry>
>::operator[](llvm::AssertingVH<llvm::BasicBlock> const&) + 31
4  llc             0x000000000099f5d0
llvm::MMIAddrLabelMap::UpdateForRAUWBlock(llvm::BasicBlock*, llvm::BasicBlock*)
+ 64
5  llc             0x0000000000c10c9a
llvm::ValueHandleBase::ValueIsRAUWd(llvm::Value*, llvm::Value*) + 442
6  llc             0x0000000000c11115
llvm::Value::uncheckedReplaceAllUsesWith(llvm::Value*) + 261
7  llc             0x0000000000ac86da
llvm::MergeBasicBlockIntoOnlyPred(llvm::BasicBlock*, llvm::Pass*) + 186
8  llc             0x0000000000a8780f
9  llc             0x0000000000a8830b
10 llc             0x0000000000a89cd6
11 llc             0x0000000000bfdf16
llvm::FPPassManager::runOnFunction(llvm::Function&) + 534
12 llc             0x0000000000bfe0f1
llvm::FunctionPassManagerImpl::run(llvm::Function&) + 129
13 llc             0x0000000000bfe31e
llvm::FunctionPassManager::run(llvm::Function&) + 110
14 llc             0x000000000052d334 main + 3556
15 libc.so.6       0x00007feccc311a3d __libc_start_main + 253
16 llc             0x000000000052b039
Stack dump:
0.      Program arguments: llc -f -o temp.s - 
1.      Running pass 'Optimize for code generation' on function '@reduce_graph'
Segmentation fault

I'm using the svn-version, revision 98581.

Regards,
Sebastian

-- 
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 llvm.org  Mon Mar 22 07:00:51 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 22 Mar 2010 07:00:51 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6674] New: clang++ emits V and U symbols while g++
 does not emit anything
Message-ID: <bug-6674-206@http.llvm.org/bugs/>

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

           Summary: clang++ emits V and U symbols while g++ does not emit
                    anything
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: rdivacky at freebsd.org
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


pes delta$ cat compatibility.cc
     namespace std  {
       template<class _CharT>     struct char_traits;
           typedef long streamsize;
       template<typename _CharT, typename _Traits = char_traits<_CharT> >    
class basic_istream;
     template<typename _InputIterator1, typename _InputIterator2,     typename
_OutputIterator>     _OutputIterator    
set_symmetric_difference(_InputIterator1 __first1, _InputIterator1 __last1,    
    _InputIterator2 __first2, _InputIterator2 __last2,         _OutputIterator
__result)     {
       }
     class ios_base   {
       };
     template<typename _CharT, typename _Traits>     class basic_ios : public
ios_base     {
       };
       template<typename _CharT, typename _Traits>     class basic_istream :
virtual public basic_ios<_CharT, _Traits>     {
         typedef basic_istream<_CharT, _Traits> __istream_type;
               virtual       ~basic_istream()       {
  }
           class sentry;
          __istream_type&       ignore(streamsize __n);
       };
       template<>     basic_istream<wchar_t>&     basic_istream<wchar_t>::    
ignore(streamsize __n);
       template<typename _CharT, typename _Traits>     class
basic_istream<_CharT, _Traits>::sentry     {
       };
        extern template class basic_istream<wchar_t>;
        template<>     basic_istream<wchar_t>&     basic_istream<wchar_t>::    
ignore(streamsize __n)     {
       }
      }


pes delta$ clang++ -O2 -c compatibility.cc && nm compatibility.o

0000000000000000 T _ZNSt13basic_istreamIwSt11char_traitsIwEE6ignoreEl
                 U _ZNSt13basic_istreamIwSt11char_traitsIwEED0Ev
                 U _ZNSt13basic_istreamIwSt11char_traitsIwEED1Ev
0000000000000000 V _ZTISt13basic_istreamIwSt11char_traitsIwEE
0000000000000000 V _ZTISt8ios_base
0000000000000000 V _ZTISt9basic_iosIwSt11char_traitsIwEE
0000000000000000 V _ZTSSt13basic_istreamIwSt11char_traitsIwEE
0000000000000000 V _ZTSSt8ios_base
0000000000000000 V _ZTSSt9basic_iosIwSt11char_traitsIwEE
0000000000000000 V _ZTTSt13basic_istreamIwSt11char_traitsIwEE
                 U _ZTVN10__cxxabiv117__class_type_infoE
                 U _ZTVN10__cxxabiv120__si_class_type_infoE
                 U _ZTVN10__cxxabiv121__vmi_class_type_infoE
0000000000000000 V _ZTVSt13basic_istreamIwSt11char_traitsIwEE

pes delta$ g++ -O2 -c compatibility.cc && nm compatibility.o

0000000000000000 T _ZNSt13basic_istreamIwSt11char_traitsIwEE6ignoreEl
                 U __gxx_personality_v0

-- 
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 llvm.org  Mon Mar 22 08:19:15 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 22 Mar 2010 08:19:15 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6675] New: clang doesn't warn about accessing
 uninitialized variables
Message-ID: <bug-6675-206@http.llvm.org/bugs/>

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

           Summary: clang doesn't warn about accessing uninitialized
                    variables
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: tss at iki.fi
                CC: llvmbugs at cs.uiuc.edu


This is a major blocker for my attempted switch from gcc to clang. I make this
mistake way too often when coding, so I need to have this warning shown to me
at compile time. Example:

int main(void) {
    int foo;
    return foo;
}

clang gives no warning. gcc -Wall says:

test2.c: In function ?main?:
test2.c:3: warning: ?foo? is used uninitialized in this function

I don't know if this is really static analyzer's job. If it is, I'd still want
it to be shown during normal compiling. For example I would be happy with an
extra clang -Wstatic-analyzer option or something that runs the static analyzer
internally.

-- 
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 llvm.org  Mon Mar 22 08:29:35 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 22 Mar 2010 08:29:35 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6601] Generic codegen tests that need -march=x86,
 and fail on ppc
In-Reply-To: <bug-6601-206@http.llvm.org/bugs/>
References: <bug-6601-206@http.llvm.org/bugs/>
Message-ID: <20100322132935.5ED972A6C12C@llvm.org>

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

T?r?k Edwin <edwintorok at gmail.com> changed:

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

--- Comment #2 from T?r?k Edwin <edwintorok at gmail.com> 2010-03-22 08:29:34 CDT ---
Thanks, 7 failures now:
http://www.0xacab.net:8010/builders/quick-darwin-ppc/builds/770/steps/test/logs/stdio

Failing Tests (7):
    LLVM :: CodeGen/Generic/2007-04-13-SwitchLowerBadPhi.ll
    LLVM :: CodeGen/Generic/2007-11-21-UndeadIllegalNode.ll
    LLVM :: CodeGen/Generic/2007-12-17-InvokeAsm.ll
    LLVM :: CodeGen/Generic/2007-12-31-UnusedSelector.ll
    LLVM :: CodeGen/Generic/2008-08-07-PtrToInt-SmallerInt.ll
    LLVM :: CodeGen/Generic/2009-11-16-BadKillsCrash.ll
    LLVM :: CodeGen/X86/GC/simple_ocaml.ll

This seems to fix them, not sure if moving these is okay, or instead
the triple should be removed:
mv CodeGen/{Generic,X86}/2007-04-13-SwitchLowerBadPhi.ll
mv CodeGen/{Generic,X86}/2007-11-21-UndeadIllegalNode.ll
mv CodeGen/{Generic,X86}/2007-12-17-InvokeAsm.ll
mv CodeGen/{Generic,X86}/2007-12-31-UnusedSelector.ll
mv CodeGen/{Generic,X86}/2008-08-07-PtrToInt-SmallerInt.ll
mv CodeGen/{Generic,X86}/2009-11-16-BadKillsCrash.ll

--- a/libclamav/c++/llvm/test/CodeGen/X86/GC/dg.exp
+++ b/libclamav/c++/llvm/test/CodeGen/X86/GC/dg.exp
@@ -1,3 +1,5 @@
 load_lib llvm.exp

-RunLLVMTests [lsort [glob -nocomplain $srcdir/$subdir/*.{ll,c,cpp}]]
+if { [llvm_supports_target X86] } {
+    RunLLVMTests [lsort [glob -nocomplain $srcdir/$subdir/*.{ll,c,cpp}]]
+}

-- 
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 llvm.org  Mon Mar 22 12:33:30 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 22 Mar 2010 12:33:30 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6676] New: LLVM does not correctly support legalize
 actions for FP <-> INT conversion
Message-ID: <bug-6676-206@http.llvm.org/bugs/>

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

           Summary: LLVM does not correctly support legalize actions for
                    FP <-> INT conversion
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Common Code Generator Code
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: micah.villmow at amd.com
                CC: llvmbugs at cs.uiuc.edu


LLVm currently does not use getConvertAction for any FP <-> INT conversions.
This causes a problem with my backend as I need to custom lower all double <->
[32|64]b integers but not 8 or 16b integers.

-- 
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 llvm.org  Mon Mar 22 12:57:54 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 22 Mar 2010 12:57:54 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6677] New: Assertion failed: (DD->isUsed() && "Sema
 doesn't consider destructor as used."), function GetOrCreateLLVMFunction,
 file CodeGenModule.cpp, line 814.
Message-ID: <bug-6677-206@http.llvm.org/bugs/>

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

           Summary: Assertion failed: (DD->isUsed() && "Sema doesn't
                    consider destructor as used."), function
                    GetOrCreateLLVMFunction, file CodeGenModule.cpp, line
                    814.
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: FreeBSD
            Status: NEW
          Severity: normal
          Priority: P
         Component: LLVM Codegen
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: rdivacky at freebsd.org
                CC: llvmbugs at cs.uiuc.edu


pes delta$ cat globals_io.cc
    typedef long __int64_t;
     typedef __int64_t __ptrdiff_t;
          typedef union {
    }
     __mbstate_t;
     typedef __ptrdiff_t ptrdiff_t;
           extern "C" {
     } 
       namespace std __attribute__ ((__visibility__ ("default"))) {
       template<class _CharT>     struct char_traits;
      }
      namespace std __attribute__ ((__visibility__ ("default"))) {
           typedef ptrdiff_t streamsize;
       template<typename _CharT, typename _Traits>     class basic_streambuf   
 {
      public:        virtual       ~basic_streambuf()       {
  }
       };
        template<typename _CharT>     class __basic_file;
        template<>     class __basic_file<char>     {
       };
        template<typename _CharT, typename _Traits = std::char_traits<_CharT> >
    class stdio_sync_filebuf : public std::basic_streambuf<_CharT, _Traits>    
{
       public:        typedef _CharT char_type;
          virtual std::streamsize       xsgetn(char_type* __s, std::streamsize
__n);
       };
       template<>     inline std::streamsize    
stdio_sync_filebuf<wchar_t>::xsgetn(wchar_t* __s, std::streamsize __n)     {
       }
       extern template class stdio_sync_filebuf<wchar_t>;
       }

pes delta$ clang++ -c -O2 globals_io.cc
globals_io.cc:26:8: warning: control reaches end of non-void function
[-Wreturn-type]
       }
       ^
Assertion failed: (DD->isUsed() && "Sema doesn't consider destructor as
used."), function GetOrCreateLLVMFunction, file CodeGenModule.cpp, line 814.
Stack dump:
0.      Program arguments: /usr/local/bin/clang -cc1 -triple
x86_64-unknown-freebsd8.0 -S -disable-free -main-file-name globals_io.cc
-mrelocation-model static -mdisable-fp-elim -mconstructor-aliases
-munwind-tables -target-cpu x86-64 -resource-dir /usr/local/lib/clang/1.5 -O2
-fmessage-length 152 -fexceptions -fgnu-runtime -fdiagnostics-show-option
-fcolor-diagnostics -o /tmp/cc-zAuNju.s -x c++ globals_io.cc
1.      <eof> parser at end of file
2.      globals_io.cc:12:17: LLVM IR generation of declaration 'std'
3.      globals_io.cc:25:79: Generating code for declaration
'std::stdio_sync_filebuf<wchar_t, std::char_traits<wchar_t> >::xsgetn'
clang: error: compiler command failed due to signal 6 (use -v to see
invocation)

-- 
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 llvm.org  Mon Mar 22 13:14:41 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 22 Mar 2010 13:14:41 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6658] clang's mmintrin.h fails in c89 mode
In-Reply-To: <bug-6658-206@http.llvm.org/bugs/>
References: <bug-6658-206@http.llvm.org/bugs/>
Message-ID: <20100322181441.0A9112A6C12E@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #2 from Chris Lattner <clattner at apple.com> 2010-03-22 13:14:40 CDT ---
Actually, I just did it. Fixed here:
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20100322/028611.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 llvm.org  Mon Mar 22 14:05:17 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 22 Mar 2010 14:05:17 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6678] New: incoherent warning when calling a
 non-const method with a const object
Message-ID: <bug-6678-206@http.llvm.org/bugs/>

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

           Summary: incoherent warning when calling a non-const method
                    with a const object
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: kremenek at apple.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


Consider the following example:

$ cat t.cpp
class Foo {
public:
  void bar();
};

void test(const Foo *x) {
  x->bar();
}

This is what clang says:

$ clang -fsyntax-only t.cpp
t.cpp:7:3: error: cannot initialize object parameter of type 'Foo' with an
expression of type 'Foo const'
  x->bar();
  ^
1 diagnostic generated.

This is what gcc says:

$ gcc -fsytnax-only t.cpp
t.cpp: In function ?void test(const Foo*)?:
t.cpp:7: error: passing ?const Foo? as ?this? argument of ?void Foo::bar()?
discards qualifiers


gcc's warning is much better.  It tells me exactly the nature of the problem. 
Clang's warning is incoherent and not really useful.

-- 
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 llvm.org  Mon Mar 22 15:27:17 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 22 Mar 2010 15:27:17 -0500 (CDT)
Subject: [LLVMbugs] [Bug 4841] [x86] cmov generated even on -mcpu=pentium
In-Reply-To: <bug-4841-206@http.llvm.org/bugs/>
References: <bug-4841-206@http.llvm.org/bugs/>
Message-ID: <20100322202717.79DD42A6C12D@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #11 from Chris Lattner <clattner at apple.com> 2010-03-22 15:27:16 CDT ---
Please open a new bug to track this, this has nothing to do with cmov.  The
proposed patch isn't the right solution.  Instead of handling this at
scheduling time, this should be handled at legalize time.  If this feature
isn't available, the x86 legalize code should not make the 'X86cmp' node for
the fp types.

-- 
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 llvm.org  Mon Mar 22 15:30:28 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 22 Mar 2010 15:30:28 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6542] Add support for __gcc_tdiag__ format attribute
In-Reply-To: <bug-6542-206@http.llvm.org/bugs/>
References: <bug-6542-206@http.llvm.org/bugs/>
Message-ID: <20100322203028.9351E2A6C12E@llvm.org>

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

Duncan Sands <baldrick at free.fr> changed:

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

--- Comment #4 from Duncan Sands <baldrick at free.fr> 2010-03-22 15:30:28 CDT ---
I'm still seeing the same message.  Testcase:

extern void internal_error (const char *, ...) __attribute__ ((__format__
(__gcc_tdiag__, 1, 2)));


$ clang++ -S testcase.ii
testcase.ii:1:64: warning: 'format' attribute argument not supported:
__gcc_tdiag__
extern void internal_error (const char *, ...) __attribute__ ((__format__
(__gcc_tdiag__, 1, 2)));
                                                               ^
1 diagnostic generated.

-- 
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 llvm.org  Mon Mar 22 16:09:05 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 22 Mar 2010 16:09:05 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6542] Add support for __gcc_tdiag__ format attribute
In-Reply-To: <bug-6542-206@http.llvm.org/bugs/>
References: <bug-6542-206@http.llvm.org/bugs/>
Message-ID: <20100322210905.756402A6C12E@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #6 from Chris Lattner <clattner at apple.com> 2010-03-22 16:09:05 CDT ---
(re)implemented in r99213

-- 
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 llvm.org  Mon Mar 22 18:05:54 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 22 Mar 2010 18:05:54 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6601] Generic codegen tests that need -march=x86,
 and fail on ppc
In-Reply-To: <bug-6601-206@http.llvm.org/bugs/>
References: <bug-6601-206@http.llvm.org/bugs/>
Message-ID: <20100322230554.DCEB82A6C124@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #3 from Chris Lattner <clattner at apple.com> 2010-03-22 18:05:54 CDT ---
2007-04-13-SwitchLowerBadPhi.ll is not x86 specific at all.  You're getting
this:

llc <
/Users/acab/bbot/share/slave/quick-darwin/build/libclamav/c++/llvm/test/CodeGen/Generic/2007-04-13-SwitchLowerBadPhi.ll
-O0
--
Exit Code: 1
Command Output (stdout):
--
Command has output on stderr!

--
Command Output (stderr):
--
llc: error auto-selecting target for module 'No available targets are
compatible with this triple, see -version for the available targets.'.  Please
use the -march option to explicitly pick a target.


which indicates that you're not even building the ppc target or something. 
Whatever the issue is, the test is fine, please file a new 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 llvm.org  Mon Mar 22 18:16:24 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 22 Mar 2010 18:16:24 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6673] Use of blockadress() crashes llc in some cases
In-Reply-To: <bug-6673-206@http.llvm.org/bugs/>
References: <bug-6673-206@http.llvm.org/bugs/>
Message-ID: <20100322231624.4562F2A6C12C@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #2 from Chris Lattner <clattner at apple.com> 2010-03-22 18:16:23 CDT ---
Fixed here, thanks for the report and the great testcase!
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20100322/098367.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 llvm.org  Mon Mar 22 19:11:10 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 22 Mar 2010 19:11:10 -0500 (CDT)
Subject: [LLVMbugs] [Bug 2809] Avoid execution domain bypass
In-Reply-To: <bug-2809-206@http.llvm.org/bugs/>
References: <bug-2809-206@http.llvm.org/bugs/>
Message-ID: <20100323001110.242F82A6C124@llvm.org>

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

Jakob Stoklund Olesen <stoklund at 2pi.dk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
                 CC|                            |stoklund at 2pi.dk
         Resolution|INVALID                     |

--- Comment #7 from Jakob Stoklund Olesen <stoklund at 2pi.dk> 2010-03-22 19:11:09 CDT ---
This issue is appearing on Nehalem processors. I have real code that runs 14%
faster on an E5520 when I substitute movaps->movdqa and orps->por. I have
verified that it is not a code size/alignment issue.

I am working on a fix.

-- 
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 llvm.org  Mon Mar 22 20:06:07 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 22 Mar 2010 20:06:07 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6679] New: [x86] FUCOMIP and related instructions
 generated even on -mcpu=pentium
Message-ID: <bug-6679-206@http.llvm.org/bugs/>

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

           Summary: [x86] FUCOMIP and related instructions generated even
                    on -mcpu=pentium
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: X86
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: craig at ni.com
                CC: clattner at apple.com, llvmbugs at cs.uiuc.edu,
                    craig at ni.com, d.g.gorbachev at gmail.com
        Depends on: 4841


+++ This bug was initially created as a clone of Bug #4841 +++

The FCOMI/FCOMIP/ FUCOMI/FUCOMIP instructions were added to the
Pentium Pro at the same time as conditional moves.  
While the -mattr=-cmov flag can disable conditional moves, there is still no
way to disable the floating point comparisons FCOMI, etc. which set EFLAGS

Processors older than Pentium Pro only have floating point comparisons such as
FCOM, FCOMP, etc., which set the x87 floating point status word with the result
rather than EFLAGS.
To set condition codes in order to branch on the result, you need to do
something like

  FUCOMP %st(1)
  FNSTSW   ; store x87 FP status word to AX
  SAHF        ; copy AH to EFLAGS
  JE ...

As it stands, using -cmov is not sufficient to generate code which will run on
pentium and earlier CPUs.

Also note that the definition of the older instructions in X86InstrFPStack.td 
(def UCOM_Fr, UCOM_FPr, and UCOM_FPPr have "let Defs = [EFLAGS]", which is not
correct.
(I'm not sure if it is actually possible to get LLVM to generate these
instructions currently.)

I had attached a proposed fix to this problem to Bug #4841 as part of the -cmov
switch, which used a pseudo-instruction to match X86cmp and generate the
pattern above, 
but Chris suggested I clone the bug and implement a fix during Legalize instead
of scheduling.

Unfortunately I'm a newbie at this, and this seems a bit harder.
Chris, to clarify your intent:

I would need to create X86 DAG Nodes for FUCOM, FNSTSW, and SAHF and generate
them in LowerSelectCC and other places in X86ISelLowering instead of
X86ISD::CMP whenever the feature test fails, and modify X86InstrFPStack to add
pattens to match them with the associated instructions.

Do I have this right?  Also, the FPSW does not seem to be modeled as a
pseudo-register, so will I have to do this in order to be able to model the
dependency between the FUCOM and FNSTSW SDNodes?

-- 
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 llvm.org  Mon Mar 22 20:29:26 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 22 Mar 2010 20:29:26 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6668] Debug info: Source file paths should be
	absolute
In-Reply-To: <bug-6668-206@http.llvm.org/bugs/>
References: <bug-6668-206@http.llvm.org/bugs/>
Message-ID: <20100323012926.9078F2A6C12E@llvm.org>

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

devang.patel <devang.patel at gmail.com> changed:

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

--- Comment #2 from devang.patel <devang.patel at gmail.com> 2010-03-22 20:29:26 CDT ---
Doug fixed this in r 98898.

-- 
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 llvm.org  Mon Mar 22 22:17:25 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 22 Mar 2010 22:17:25 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6680] New: A dynamic link library (DLL)
 initialization routine failed.
Message-ID: <bug-6680-206@http.llvm.org/bugs/>

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

           Summary: A dynamic link library (DLL) initialization routine
                    failed.
           Product: tools
           Version: 2.6
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Keywords: miscompilation
          Severity: release blocker
          Priority: P
         Component: llvm-gcc
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: ga55gees6m at sneakemail.com
                CC: llvmbugs at cs.uiuc.edu


--- tdll.c ---
#define UNICODE

#include <windows.h>

int f(void)
{
    return 0;
}

__stdcall BOOL DllMain(HINSTANCE hInst, DWORD reason, void *reserved)
{
    OutputDebugString(L"dll: 123");
    return TRUE;
}

void g(const WCHAR *msg)
{
    OutputDebugString(msg);
}
---
>llvm-gcc.exe -c tdll.c -o tdll.o -pipe -Wall

>ld --dll --subsystem windows -Bdynamic -nostdlib -
o tdll.dll tdll.o -L\pr\llvm\lib -lkernel32 -luser32 -s --fatal-warnings
--error
-unresolved-symbols

>test
---
test is a simple testing application which loads library and gets error
--- test.c ---
#define UNICODE
#include <windows.h>

void TraceError(void)
{
    WCHAR str[300];
    DWORD err=GetLastError();
    FormatMessage(FORMAT_MESSAGE_FROM_SYSTEM|FORMAT_MESSAGE_IGNORE_INSERTS,
NULL,err,LANG_USER_DEFAULT,str,300,NULL);
    OutputDebugString(str);
}

int main()
{
    HMODULE m=LoadLibrary(L"tdll.dll");
    if(m)OutputDebugStringW(L"test: ok");
    else { OutputDebugStringW(L"test: fail"); TraceError(); }
    return 0;
}
---
Error: A dynamic link library (DLL) initialization routine failed. 
---
Interestingly, reordering functions in tdll.c yields different results - from
failure to success, optimization makes situation even worse. This is a reduced
testcase from miranda plugin project. I wondered, why miranda doesn't display
my plugin. It turned out dll built with llvm-gcc fails to initialize.
Blocker, can't work it around.

-- 
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 llvm.org  Mon Mar 22 22:44:46 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 22 Mar 2010 22:44:46 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6681] New: __VERSION__ is missing clang/LLVM
 version information, __clang__ and __llvm_ have no useful number
Message-ID: <bug-6681-206@http.llvm.org/bugs/>

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

           Summary: __VERSION__ is missing clang/LLVM version information,
                    __clang__ and __llvm_ have no useful number
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Headers
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: c-d.hailfinger.devel.2006 at gmx.net
                CC: llvmbugs at cs.uiuc.edu


__VERSION__ has no information about the clang/LLVM version at all and contains
a fake GCC version string instead.
#define __VERSION__ "4.2.1 Compatible Clang Compiler"

Besides that, there is no useful __CLANG__ or __CLANG_MINOR__ or __LLVM__ or
__LLVM_MINOR__ #define which could be used to test for a recent clang/LLVM.

This makes it impossible to check for a non-broken LLVM/clang version inside C
code.

I can understand faking some numerical values which are used for GCC
compatibility like
#define __GNUC__ 4
#define __GNUC_MINOR__ 2
#define __GNUC_PATCHLEVEL__ 1

Faking GCC version numbers doesn't eliminate the need for such version number
values for LLVM/clang, though.

Besides that, I'm unaware of any software which would be broken by clang/llvm
version numbers in the __VERSION__ string which isn't usable for any
checks/comparisons by the C preprocessor, and I strongly doubt that someone is
actually parsing the __VERSION__ string instead of testing __GNUC__ and
__GNUC_MINOR__. Having a meaningful __VERSION__ string would be appreciated for
easier printing.


Right now clang miscompiles coreboot, and older clang miscompiled flashrom.
With either software a miscompile means that you probably have to use a
soldering iron to recover your mainboard, and I'd really love to replace
#if __clang__
#error Some versions of clang are broken, no way to test for them
#endif
with something a bit more useful.

-- 
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 llvm.org  Tue Mar 23 01:04:01 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 23 Mar 2010 01:04:01 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6680] A dynamic link library (DLL) initialization
 routine failed.
In-Reply-To: <bug-6680-206@http.llvm.org/bugs/>
References: <bug-6680-206@http.llvm.org/bugs/>
Message-ID: <20100323060401.A1AE22A6C12C@llvm.org>

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |asl at math.spbu.ru
         Resolution|                            |INVALID
           Severity|release blocker             |normal

--- Comment #3 from Anton Korobeynikov <asl at math.spbu.ru> 2010-03-23 01:04:01 CDT ---
You failed to link the DLL properly - you need to provide a proper mingw32 CRT
startup object and specify an entry point. So, you should additionally link in
dllcrt{1,2}.o from mingw32 runtime and use _DllMainCRTStartup at 12 as an entry
point (just -e _DllMainCRTStartup at 12).

It's better not to use mingw32-ld directly if you don't know precisely what is
necessary to link in and how. Consider using -shared option of llvm-gcc. The
following cmdline does everything for you and yields a working .dll:
llvm-gcc -shared tdll.c -o tdll.dll

-- 
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 llvm.org  Tue Mar 23 08:26:58 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 23 Mar 2010 08:26:58 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6682] New: -inline ignores noinline attribute
Message-ID: <bug-6682-206@http.llvm.org/bugs/>

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

           Summary: -inline ignores noinline attribute
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Interprocedural Optimizations
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: arplynn at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Consider the following test case:

declare void @foo() nounwind

define void @bar() nounwind {
entry:
    tail call void @foo() nounwind
    ret void
}

define void @bazz() nounwind {
entry:
    tail call void @bar() nounwind noinline
    ret void
}

-inline inlines @bar into @bazz, despite the noinline attribute.

-- 
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 llvm.org  Tue Mar 23 10:27:42 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 23 Mar 2010 10:27:42 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6645] SIGSEG in
	clang::DeclContext::isTransparentContext ()
In-Reply-To: <bug-6645-206@http.llvm.org/bugs/>
References: <bug-6645-206@http.llvm.org/bugs/>
Message-ID: <20100323152742.20A842A6C12E@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #1 from Douglas Gregor <dgregor at apple.com> 2010-03-23 10:27:41 CDT ---
Fixed in r99281.

-- 
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 llvm.org  Tue Mar 23 11:26:46 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 23 Mar 2010 11:26:46 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6683] New: Crash in llvm_shutdown with simple
	bitcode file
Message-ID: <bug-6683-206@http.llvm.org/bugs/>

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

           Summary: Crash in llvm_shutdown with simple bitcode file
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Linker
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: ggreif at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=4574)
 --> (http://llvm.org/bugs/attachment.cgi?id=4574)
clang repro recipe

Compile the attached c++ file so:

Release/bin/clang repro.cpp -c -O0 -emit-llvm -o repro.bc

Then invoke the llvm linker:

Release/bin/llvm-ld -stats repro.bc -lc -disable-inlining -o /dev/null

Observe crash:

llvm-ld: Error opening output file '/dev/null.bc'
===-------------------------------------------------------------------------===
                          ... Statistics Collected ...
===-------------------------------------------------------------------------===

1 deadargelim      - Number of unread args removed
1 functionattrs    - Number of arguments marked nocapture
2 globaldce        - Number of functions removed
1 globalopt        - Number of functions converted to fastcc
1 globalsmodref-aa - Number of functions that only read memory
1 globalsmodref-aa - Number of functions without address taken
3 instcombine      - Number of dead inst eliminated
3 instcombine      - Number of insts combined
1 jump-threading   - Number of jumps threaded
2 jump-threading   - Number of terminators folded
1 mem2reg          - Number of PHI nodes inserted
2 mem2reg          - Number of alloca's promoted with a single store
2 memdep           - Number of uncached non-local responses
4 scalarrepl       - Number of allocas promoted
1 sccp             - Number of arguments constant propagated by IPSCCP
1 sccp             - Number of basic blocks unreachable
4 sccp             - Number of instructions removed

While deleting: i8* %
Use still stuck around after Def is destroyed:  store i8* getelementptr
inbounds (0  llvm-ld         0x0000000000801525
1  llvm-ld         0x0000000000801af9
2  libpthread.so.0 0x00000034abf0c790
3  llvm-ld         0x00000000006d5b41
4  llvm-ld         0x00000000006d4551
5  llvm-ld         0x00000000006d6b90 (anonymous
namespace)::AssemblyWriter::writeOperand(llvm::Value const*, bool) + 128
6  llvm-ld         0x00000000006d87b0 (anonymous
namespace)::AssemblyWriter::printInstruction(llvm::Instruction const&) + 6896
7  llvm-ld         0x00000000006dbfc1 llvm::Value::print(llvm::raw_ostream&,
llvm::AssemblyAnnotationWriter*) const + 369
8  llvm-ld         0x0000000000795cc0 llvm::Value::~Value() + 432
9  llvm-ld         0x000000000075e30a
llvm::GetElementPtrConstantExpr::~GetElementPtrConstantExpr() + 74
10 llvm-ld         0x000000000075f35b llvm::LLVMContextImpl::~LLVMContextImpl()
+ 219
11 llvm-ld         0x000000000075de15 llvm::LLVMContext::~LLVMContext() + 21
12 llvm-ld         0x000000000075e23e
llvm::object_deleter<llvm::LLVMContext>::call(void*) + 14
13 llvm-ld         0x00000000007e404e llvm::ManagedStaticBase::destroy() const
+ 46
14 llvm-ld         0x00000000007e40b5 llvm::llvm_shutdown() + 21
15 llvm-ld         0x00000000004babc4 tan + 16124
16 llvm-ld         0x00000000004bafa4 GenerateBitcode(llvm::Module*,
std::string const&) + 388
17 llvm-ld         0x00000000004bd32b main + 1227
18 libc.so.6       0x00000034ab21c40b __libc_start_main + 219
19 llvm-ld         0x00000000004b73ea fmod + 114
Stack dump:
0.      Program arguments: Release/bin/llvm-ld -stats repro.bc -lc
-disable-inlining -o /dev/null 
Segmentation fault


I'll seek a confirmation on another machine whether this is a reproducible
problem elsewhere.

-- 
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 llvm.org  Tue Mar 23 12:16:19 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 23 Mar 2010 12:16:19 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6684] New: Module::getEndianness() has an infinite
	loop
Message-ID: <bug-6684-206@http.llvm.org/bugs/>

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

           Summary: Module::getEndianness() has an infinite loop
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Core LLVM classes
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: alexmac at adobe.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=4576)
 --> (http://llvm.org/bugs/attachment.cgi?id=4576)
getEndianness patch

A typo in the while loop is causing the same string to be continually
re-tokenised rather than using the temp string.

-- 
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 llvm.org  Tue Mar 23 13:04:47 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 23 Mar 2010 13:04:47 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6685] New: clang emits undefined symbol for type
 info while gcc emits a weak one
Message-ID: <bug-6685-206@http.llvm.org/bugs/>

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

           Summary: clang emits undefined symbol for type info while gcc
                    emits a weak one
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: FreeBSD
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: rdivacky at freebsd.org
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


pes delta$ cat tinfo2.cc
extern          "C++" {
        namespace       std {
                class           type_info {
                        public:virtual ~ type_info();
                        bool            operator == (const type_info &
__arg)const {
                                return __name == __arg.__name;
                        }
                        virtual bool    __is_function_p() const;
                                        protected:const char *__name;
                };
        }
}
namespace       __cxxabiv1 {
        class           __fundamental_type_info:public std::type_info {
                virtual ~ __fundamental_type_info();
        };
        class           __pbase_type_info:public std::type_info {
                public:unsigned int __flags;
                const           std::   type_info * __pointee;
        };
        class           __pointer_type_info:public __pbase_type_info {
                virtual bool    __pointer_catch(const __pbase_type_info *
__thr_type, void **__thr_obj, unsigned __outer)const;
        };
                        __fundamental_type_info::~__fundamental_type_info() {
        }
        bool            __pointer_type_info::__pointer_catch(const
__pbase_type_info * thrown_type, void **thr_obj, unsigned outer)const {
                if (outer < 2 && *__pointee == typeid(void)) {
                        return !thrown_type->__pointee->__is_function_p();
                }
        }
}

pes delta$ g++ -c tinfo2.cc && nm tinfo2.o | grep _ZTIv
0000000000000000 V _ZTIv
pes delta$ clang++ -c tinfo2.cc && nm tinfo2.o | grep _ZTIv
tinfo2.cc:30:2: warning: control may reach end of non-void function
[-Wreturn-type]
        }
        ^
1 diagnostic generated.
                 U _ZTIv

-- 
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 llvm.org  Tue Mar 23 14:38:13 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 23 Mar 2010 14:38:13 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6686] New: llc aborts for simple hello world (blink
 an led) msp430 code
Message-ID: <bug-6686-206@http.llvm.org/bugs/>

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

           Summary: llc aborts for simple hello world (blink an led)
                    msp430 code
           Product: new-bugs
           Version: 2.6
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: dwelch at dwelch.com
                CC: llvmbugs at cs.uiuc.edu


llvm and clang are svnned from release 26 revision 99316

llvm:
URL: http://llvm.org/svn/llvm-project/llvm/branches/release_26
Repository Root: http://llvm.org/svn/llvm-project
Repository UUID: 91177308-0d34-0410-b5e6-96231b3b80d8
Revision: 99316
Node Kind: directory
Schedule: normal
Last Changed Author: tbrethou
Last Changed Rev: 84985
Last Changed Date: 2009-10-23 21:52:47 -0400 (Fri, 23 Oct 2009)

llvm/tools/clang:
URL: http://llvm.org/svn/llvm-project/cfe/branches/release_26
Repository Root: http://llvm.org/svn/llvm-project
Repository UUID: 91177308-0d34-0410-b5e6-96231b3b80d8
Revision: 99316
Node Kind: directory
Schedule: normal
Last Changed Author: tbrethou
Last Changed Rev: 82195
Last Changed Date: 2009-09-18 01:10:35 -0400 (Fri, 18 Sep 2009)


#define DCOCTL       (*(volatile unsigned char *)0x0056)
#define BCSCTL1      (*(volatile unsigned char *)0x0057)
#define WDTCTL       (*(volatile unsigned char *)0x0120)
#define P1OUT        (*(volatile unsigned char *)0x0021)
#define P1DIR        (*(volatile unsigned char *)0x0022)
#define CALDCO_16MHZ (*(volatile unsigned char *)0x10F8)
#define CALDCO_12MHZ (*(volatile unsigned char *)0x10FA)
#define CALDCO_8MHZ  (*(volatile unsigned char *)0x10FC)
#define CALDCO_1MHZ  (*(volatile unsigned char *)0x10FE)
#define CALBC1_16MHZ (*(volatile unsigned char *)0x10F9)
#define CALBC1_12MHZ (*(volatile unsigned char *)0x10FB)
#define CALBC1_8MHZ  (*(volatile unsigned char *)0x10FD)
#define CALBC1_1MHZ  (*(volatile unsigned char *)0x10FF)

extern unsigned char GET8 ( unsigned short );
extern void PUT8 ( unsigned short, unsigned char );
extern void PINGRET ( void );

void notmain ( void )
{
unsigned short ra;


    unsigned char ca,cb;
    //use calibrated clock values
    //PUT8(BCSCTL1,GET8(CALBC1_8MHZ));
    //PUT8(DCOCTL,GET8(CALDCO_8MHZ));
    BCSCTL1=CALBC1_16MHZ;
    DCOCTL=CALDCO_16MHZ;

    P1DIR=P1DIR|1;
    ca=P1OUT;
    cb=ca^1;
    while(1)
    {
        P1OUT=ca;
        ra=0xF000; while(--ra) PINGRET();
        P1OUT=cb;
        ra=0xF000; while(--ra) PINGRET();
    }
}





# clang -Wall -emit-llvm -c lltest.c -o lltestmain.bc 
# opt -std-compile-opts lltestmain.bc -f -o=lltestopt.bc
# llc -march=msp430 lltestopt.bc -f -o=lltest.s
llc: ScheduleDAGSDNodesEmit.cpp:506: void
llvm::ScheduleDAGSDNodes::EmitNode(llvm::SDNode*, bool, bool,
llvm::DenseMap<llvm::SDValue, unsigned int, llvm::DenseMapInfo<llvm::SDValue>,
llvm::DenseMapInfo<unsigned int> >&): Assertion `(II.getNumOperands() ==
NumMIOperands || HasPhysRegOuts || II.isVariadic()) && "#operands for dag node
doesn't match .td file!"' failed.
0   llc             0x0000000000a5d8ef
1   llc             0x0000000000a5f59d
2   libpthread.so.0 0x00007ffdb566c190
3   libc.so.6       0x00007ffdb49724b5 gsignal + 53
4   libc.so.6       0x00007ffdb4975f50 abort + 384
5   libc.so.6       0x00007ffdb496b481 __assert_fail + 241
6   llc             0x000000000067e391
llvm::ScheduleDAGSDNodes::EmitNode(llvm::SDNode*, bool, bool,
llvm::DenseMap<llvm::SDValue, unsigned int, llvm::DenseMapInfo<llvm::SDValue>,
llvm::DenseMapInfo<unsigned int> >&) + 977
7   llc             0x000000000067ed22 llvm::ScheduleDAGSDNodes::EmitSchedule()
+ 338
8   llc             0x00000000006eb9a2
llvm::SelectionDAGISel::CodeGenAndEmitDAG() + 2018
9   llc             0x00000000006ec180
llvm::SelectionDAGISel::SelectBasicBlock(llvm::BasicBlock*,
llvm::ilist_iterator<llvm::Instruction>,
llvm::ilist_iterator<llvm::Instruction>) + 96
10  llc             0x00000000006eda13
llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function&,
llvm::MachineFunction&, llvm::MachineModuleInfo*, llvm::DwarfWriter*,
llvm::TargetInstrInfo const&) + 707
11  llc             0x00000000006eea20
llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) + 1024
12  llc             0x00000000009f2b1e
llvm::FPPassManager::runOnFunction(llvm::Function&) + 574
13  llc             0x00000000009f2d3b
llvm::FunctionPassManagerImpl::run(llvm::Function&) + 171
14  llc             0x00000000009f2fa1
llvm::FunctionPassManager::run(llvm::Function&) + 81
15  llc             0x00000000004f3faf main + 5407
16  libc.so.6       0x00007ffdb495dabd __libc_start_main + 253
17  llc             0x00000000004f1e69
Stack dump:
0.    Program arguments: llc -march=msp430 lltestopt.bc -f -o=lltest.s 
1.    Running pass 'MSP430 DAG->DAG Pattern Instruction Selection' on function
'@notmain'
Aborted

-- 
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 llvm.org  Tue Mar 23 14:43:04 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 23 Mar 2010 14:43:04 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6686] llc aborts for simple hello world (blink an
 led) msp430 code
In-Reply-To: <bug-6686-206@http.llvm.org/bugs/>
References: <bug-6686-206@http.llvm.org/bugs/>
Message-ID: <20100323194304.2E7E32A6C12D@llvm.org>

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

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

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

--- Comment #1 from Anton Korobeynikov <asl at math.spbu.ru> 2010-03-23 14:43:03 CDT ---
msp430 backend in 2.6 was of experimental quality. Consider using ToT - this
bug was fixed long ago there.

-- 
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 llvm.org  Tue Mar 23 16:38:37 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 23 Mar 2010 16:38:37 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6669] clang-2.7: fails 8 tests when building self
In-Reply-To: <bug-6669-206@http.llvm.org/bugs/>
References: <bug-6669-206@http.llvm.org/bugs/>
Message-ID: <20100323213837.8AB8E2A6C124@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #3 from Chris Lattner <clattner at apple.com> 2010-03-23 16:38:36 CDT ---
I agree, until PR 6251 is fixed, we shouldn't bother tracking this here.  Once
it is resolved, we can reverify this and reopen if appropriate.

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

-- 
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 llvm.org  Tue Mar 23 16:54:03 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 23 Mar 2010 16:54:03 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6684] Module::getEndianness() has an infinite loop
In-Reply-To: <bug-6684-206@http.llvm.org/bugs/>
References: <bug-6684-206@http.llvm.org/bugs/>
Message-ID: <20100323215403.229B12A6C12C@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #1 from Chris Lattner <clattner at apple.com> 2010-03-23 16:54:02 CDT ---
Thanks, applied here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20100322/098414.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 llvm.org  Tue Mar 23 16:59:55 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 23 Mar 2010 16:59:55 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6683] Crash in llvm_shutdown with simple bitcode
	file
In-Reply-To: <bug-6683-206@http.llvm.org/bugs/>
References: <bug-6683-206@http.llvm.org/bugs/>
Message-ID: <20100323215955.ADC532A6C12C@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #3 from Chris Lattner <clattner at apple.com> 2010-03-23 16:59:55 CDT ---
Fixed in r99334

-- 
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 llvm.org  Tue Mar 23 17:59:39 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 23 Mar 2010 17:59:39 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6682] -inline ignores noinline attribute
In-Reply-To: <bug-6682-206@http.llvm.org/bugs/>
References: <bug-6682-206@http.llvm.org/bugs/>
Message-ID: <20100323225939.B5C342A6C12D@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #1 from Chris Lattner <clattner at apple.com> 2010-03-23 17:59:39 CDT ---
Fixed, thanks:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20100322/098426.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 llvm.org  Tue Mar 23 18:49:56 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 23 Mar 2010 18:49:56 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6631] Class with virtual inheritance incorrectly
 labeled 'abstract'
In-Reply-To: <bug-6631-206@http.llvm.org/bugs/>
References: <bug-6631-206@http.llvm.org/bugs/>
Message-ID: <20100323234956.A8C982A6C124@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #2 from Douglas Gregor <dgregor at apple.com> 2010-03-23 18:49:56 CDT ---
Fixed in r99351.

-- 
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 llvm.org  Tue Mar 23 18:51:32 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 23 Mar 2010 18:51:32 -0500 (CDT)
Subject: [LLVMbugs] [Bug 5973] missing check for final overrider
In-Reply-To: <bug-5973-206@http.llvm.org/bugs/>
References: <bug-5973-206@http.llvm.org/bugs/>
Message-ID: <20100323235132.A470E2A6C12D@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #1 from Douglas Gregor <dgregor at apple.com> 2010-03-23 18:51:32 CDT ---
Fixed in r99351.

-- 
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 llvm.org  Tue Mar 23 19:38:38 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 23 Mar 2010 19:38:38 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6676] LLVM does not correctly support legalize
 actions for FP <-> INT conversion
In-Reply-To: <bug-6676-206@http.llvm.org/bugs/>
References: <bug-6676-206@http.llvm.org/bugs/>
Message-ID: <20100324003838.D7EB72A6C12C@llvm.org>

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

Micah Villmow <micah.villmow at amd.com> changed:

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

--- Comment #5 from Micah Villmow <micah.villmow at amd.com> 2010-03-23 19:38:38 CDT ---
I figured it out. I'll mark this bug as won't fix as the workaround is working.

-- 
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 llvm.org  Tue Mar 23 19:49:41 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 23 Mar 2010 19:49:41 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6620] Unnamed namespace problem
In-Reply-To: <bug-6620-206@http.llvm.org/bugs/>
References: <bug-6620-206@http.llvm.org/bugs/>
Message-ID: <20100324004941.AE9622A6C12D@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #2 from Douglas Gregor <dgregor at apple.com> 2010-03-23 19:49:41 CDT ---
Fixed in r99368.

-- 
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 llvm.org  Tue Mar 23 20:22:32 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 23 Mar 2010 20:22:32 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6687] New: operator new should check for integer
	overflows
Message-ID: <bug-6687-206@http.llvm.org/bugs/>

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

           Summary: operator new should check for integer overflows
           Product: clang
           Version: trunk
          Platform: All
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: felix-llvm at fefe.de
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


A common security problem in C++ code is operator new for arrays.
For example:

  int* i=new int[some_untrusted_size_t];

operator new takes a single size_t argument, so the compiler generates code at
this point that will multiply some_untrusted_size_t by sizeof(int) and pass the
result to operator new.

Now, if sizeof(int)==4 and some_untrusted_size_t==0x40000000, for example, then
the multiplication results does not fit into a size_t and is truncated.  This
leads not only to bugs, but to security vulnerabilities that allow the whole
process to be taken over.

Therefore I propose that clang generates code that checks for overflows here
and do the right thing (depending on which operator new is used, either throw
and exception or return NULL).

The easiest way to do this is to do what Microsoft Visual C++ does: it
multiplies, and then, if the overflow bit is set (on x86/x86-64), it passes
(size_t)-1 to operator new, which will cause it to fail.  This can still cause
issues when the user wrote their own operator new that rounds up or adds a
margin without checking for integer overflow, but that is then the user's
fault, not the compiler's, and it is done explicitly, so it is easier to spot
and fix.

-- 
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 llvm.org  Tue Mar 23 20:33:28 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 23 Mar 2010 20:33:28 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6619] Assert - already instantiated this local
In-Reply-To: <bug-6619-206@http.llvm.org/bugs/>
References: <bug-6619-206@http.llvm.org/bugs/>
Message-ID: <20100324013328.61A582A6C124@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #2 from Douglas Gregor <dgregor at apple.com> 2010-03-23 20:33:28 CDT ---
Fixed in r99377.

-- 
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 llvm.org  Tue Mar 23 23:43:47 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 23 Mar 2010 23:43:47 -0500 (CDT)
Subject: [LLVMbugs] [Bug 5870] [c++] Copy constructor calls incorrect base
 copy constructor
In-Reply-To: <bug-5870-206@http.llvm.org/bugs/>
References: <bug-5870-206@http.llvm.org/bugs/>
Message-ID: <20100324044347.42D542A6C12D@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #3 from Douglas Gregor <dgregor at apple.com> 2010-03-23 23:43:46 CDT ---
This is working properly now.

-- 
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 llvm.org  Wed Mar 24 00:07:57 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 24 Mar 2010 00:07:57 -0500 (CDT)
Subject: [LLVMbugs] [Bug 5904] `operator delete' does not mean `delete'
In-Reply-To: <bug-5904-206@http.llvm.org/bugs/>
References: <bug-5904-206@http.llvm.org/bugs/>
Message-ID: <20100324050757.6917C2A6C12E@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |dgregor at apple.com
         Resolution|                            |FIXED

--- Comment #1 from Douglas Gregor <dgregor at apple.com> 2010-03-24 00:07:57 CDT ---
Fixed in r99382.

-- 
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 llvm.org  Wed Mar 24 00:32:19 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 24 Mar 2010 00:32:19 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6323] Compiler assert on invalid code
In-Reply-To: <bug-6323-206@http.llvm.org/bugs/>
References: <bug-6323-206@http.llvm.org/bugs/>
Message-ID: <20100324053219.34A292A6C12E@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #2 from Douglas Gregor <dgregor at apple.com> 2010-03-24 00:32:18 CDT ---
These seem to be fixed now.

-- 
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 llvm.org  Wed Mar 24 01:08:56 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 24 Mar 2010 01:08:56 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6124] Error instantiating class with multiple
 virtual inheritance
In-Reply-To: <bug-6124-206@http.llvm.org/bugs/>
References: <bug-6124-206@http.llvm.org/bugs/>
Message-ID: <20100324060856.BF9B82A6C12E@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #1 from Douglas Gregor <dgregor at apple.com> 2010-03-24 01:08:56 CDT ---
Fixed as part of the final-overrider work.

-- 
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 llvm.org  Wed Mar 24 02:15:13 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 24 Mar 2010 02:15:13 -0500 (CDT)
Subject: [LLVMbugs] [Bug 5957] "exception specification does not match..."
 with new operator
In-Reply-To: <bug-5957-206@http.llvm.org/bugs/>
References: <bug-5957-206@http.llvm.org/bugs/>
Message-ID: <20100324071513.BF47A2A6C12D@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #2 from Douglas Gregor <dgregor at apple.com> 2010-03-24 02:15:13 CDT ---
Fixed in r99388.

-- 
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 llvm.org  Wed Mar 24 04:40:38 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 24 Mar 2010 04:40:38 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6688] New: Triple ADT sometimes extracts wrong
	vendor and os
Message-ID: <bug-6688-206@http.llvm.org/bugs/>

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

           Summary: Triple ADT sometimes extracts wrong vendor and os
           Product: new-bugs
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: baldrick at free.fr
                CC: llvmbugs at cs.uiuc.edu


Here are some example triples printed by various gcc versions on my linux
machine:

1) System gcc: x86_64-linux-gnu
2) 32 bit system gcc: i486-linux-gnu
3) ACT supplied gcc: x86_64-pc-linux-gnu
4) 32 bit ACT supplied gcc: i686-pc-linux-gnu
5) self-built gcc-4.5: x86_64-unknown-linux-gnu
6) 32 bit self-built gcc-4.5: i686-pc-linux-gnu

If the Triple class is instantiated with 1) or 2) then
getVendor and getOS return their 'unknown' value.

-- 
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 llvm.org  Wed Mar 24 04:51:34 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 24 Mar 2010 04:51:34 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6689] New: llvm-ld crashes when outputting to stdout
Message-ID: <bug-6689-206@http.llvm.org/bugs/>

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

           Summary: llvm-ld crashes when outputting to stdout
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Linker
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: ggreif at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Reproduce this way:

$ Release/bin/llvm-as < /dev/null -o empty.bc
$ Release/bin/llvm-ld empty.bc -o -
#!/bin/sh
lli=${LLVMINTERP-lli}
exec $lli \
    -.bc ${1+"$@"}
llvm-ld: /home/ggreif/llvm/lib/Support/raw_ostream.cpp:428: void
llvm::raw_fd_ostream::close(): Assertion `ShouldClose' failed.
0  llvm-ld         0x0000000000801ad5
1  llvm-ld         0x00000000008020a9
2  libpthread.so.0 0x00000034abf0c790
3  libc.so.6       0x00000034ab22e26d gsignal + 61
4  libc.so.6       0x00000034ab22fa6e abort + 254
5  libc.so.6       0x00000034ab227af1 __assert_fail + 241
6  llvm-ld         0x00000000007f6a85
7  llvm-ld         0x00000000004bb78a tan + 18834
8  llvm-ld         0x00000000004bdaf3 main + 2883
9  libc.so.6       0x00000034ab21c40b __libc_start_main + 219
10 llvm-ld         0x00000000004b751a fmod + 114
Stack dump:
0.      Program arguments: Release/bin/llvm-ld empty.bc -o - 
Abort

-- 
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 llvm.org  Wed Mar 24 05:58:55 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 24 Mar 2010 05:58:55 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6691] New: glibc and newlib need wint_t defined in
	stddef.h
Message-ID: <bug-6691-206@http.llvm.org/bugs/>

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

           Summary: glibc and newlib need wint_t defined in stddef.h
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Headers
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: quickslyver at free.fr
                CC: llvmbugs at cs.uiuc.edu


glibc version of wchar.h try to get wint_t from stddef.h else it fallback to a
dangerous default "unsigned int"

newlib fails to compile because it doesn't have default version like glibc.

-- 
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 llvm.org  Wed Mar 24 10:18:13 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 24 Mar 2010 10:18:13 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6692] New: JITDebugRegisterer/ELFWriter memory leaks
Message-ID: <bug-6692-206@http.llvm.org/bugs/>

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

           Summary: JITDebugRegisterer/ELFWriter memory leaks
           Product: new-bugs
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: edwintorok 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 llvm.org  Wed Mar 24 12:00:18 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 24 Mar 2010 12:00:18 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6641] clang++ crash: "Calling a function with a bad
	signature!"
In-Reply-To: <bug-6641-206@http.llvm.org/bugs/>
References: <bug-6641-206@http.llvm.org/bugs/>
Message-ID: <20100324170018.95BAA2A6C12E@llvm.org>

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

Fariborz Jahanian <fjahanian at apple.com> changed:

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

--- Comment #1 from Fariborz Jahanian <fjahanian at apple.com> 2010-03-24 12:00:18 CDT ---
Fixed in TOT: http://llvm.org/viewvc/llvm-project?view=rev&revision=99404

-- 
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 llvm.org  Wed Mar 24 12:06:39 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 24 Mar 2010 12:06:39 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6642] Loads from arrays initialized with a single
 large store not optimized
In-Reply-To: <bug-6642-206@http.llvm.org/bugs/>
References: <bug-6642-206@http.llvm.org/bugs/>
Message-ID: <20100324170640.431162A6C12C@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #5 from Chris Lattner <clattner at apple.com> 2010-03-24 12:06:39 CDT ---
Yes, I agree, use of a store like that is not goign to generate good code in
the first place, so the optimizer not handling it doesn't seem worthwhile.

-- 
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 llvm.org  Wed Mar 24 12:24:13 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 24 Mar 2010 12:24:13 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6693] New: clang working as a "cpp"
Message-ID: <bug-6693-206@http.llvm.org/bugs/>

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

           Summary: clang working as a "cpp"
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: FreeBSD
            Status: NEW
          Severity: normal
          Priority: P
         Component: Driver
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: rdivacky at freebsd.org
                CC: llvmbugs at cs.uiuc.edu


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

the attached patch makes it possible to use clang as "cpp" when called from a
binary called cpp... ie. when you link clang as cpp and call cpp it behaves
like such:

pes ~$ ls -l /usr/local/bin/cpp
lrwxr-xr-x  1 root  wheel  20 Mar 24 13:45 /usr/local/bin/cpp@ ->
/usr/local/bin/clang
pes ~$ /usr/local/bin/cpp hello.cc | head
# 1 "hello.cc"
# 1 "hello.cc" 1
# 1 "<built-in>" 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 llvm.org  Wed Mar 24 14:48:24 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 24 Mar 2010 14:48:24 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6694] New: lowerinvoke breaks alloca instructions
 if they do not occur in the entry basic block
Message-ID: <bug-6694-206@http.llvm.org/bugs/>

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

           Summary: lowerinvoke breaks alloca instructions if they do not
                    occur in the entry basic block
           Product: libraries
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Transformation Utilities
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: chrisb at adobe.com
                CC: llvmbugs at cs.uiuc.edu


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

The lowerinvoke pass with -enable-correct-eh-support will transform functions
that have invoke instructions into functions that do not have invoke
instructions.  This is accomplished by adding a setjmp to the end of the entry
basic block.  Any alloca instruction in the function that is not in the entry
basic block will no longer be valid when an unwind is executed because longjmp
will restore the stack state to what it was when setjmp was called.

Attached is a reduced test case that lowerinvoke improperly transforms.

-- 
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 llvm.org  Wed Mar 24 15:14:17 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 24 Mar 2010 15:14:17 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6446] Support -nostdinc++
In-Reply-To: <bug-6446-206@http.llvm.org/bugs/>
References: <bug-6446-206@http.llvm.org/bugs/>
Message-ID: <20100324201417.710852A6C12D@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #1 from Douglas Gregor <dgregor at apple.com> 2010-03-24 15:14:17 CDT ---
Implemented in r99417.

-- 
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 llvm.org  Wed Mar 24 15:17:12 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 24 Mar 2010 15:17:12 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6695] New: clang doesn't turn restrict into noalias
Message-ID: <bug-6695-206@http.llvm.org/bugs/>

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

           Summary: clang doesn't turn restrict into noalias
           Product: clang
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: LLVM Codegen
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: gohman at apple.com
                CC: llvmbugs at cs.uiuc.edu


On this testcase:

void foo(double *restrict A, double *restrict B) {
  *A = 0.0;
  *B = 1.0;
}

clang does not add noalias attributes to the arguments in the LLVM IR 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 llvm.org  Wed Mar 24 16:23:53 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 24 Mar 2010 16:23:53 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6657] SemaTemplateInstantiateDecl.cpp:393:
 clang::Decl*<unnamed>::TemplateDeclInstantiator::VisitVarDecl(clang::VarDecl*):
 Assertion `InitArgs.size() == 0' failed.
In-Reply-To: <bug-6657-206@http.llvm.org/bugs/>
References: <bug-6657-206@http.llvm.org/bugs/>
Message-ID: <20100324212353.55BD72A6C12E@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #6 from Douglas Gregor <dgregor at apple.com> 2010-03-24 16:23:52 CDT ---
Thanks for the reduction and for taking a shot at a patch. The assert was
actually telling us that we really, really shouldn't have multiple arguments
there. Fixed in r99427.

-- 
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 llvm.org  Wed Mar 24 16:42:40 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 24 Mar 2010 16:42:40 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6696] New: ebp wrongly clobbered - causes
 SingleSource/Regression/C/casts.c to crash
Message-ID: <bug-6696-206@http.llvm.org/bugs/>

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

           Summary: ebp wrongly clobbered - causes
                    SingleSource/Regression/C/casts.c to crash
           Product: new-bugs
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: release blocker
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: baldrick at free.fr
                CC: llvmbugs at cs.uiuc.edu


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

On x86-32 linux, SingleSource/Regression/C/casts.c crashes with a segmentation
fault.  This blocks the 2.7 release, since it is a regression from 2.6.
Reduced testcase attached.

The problem seems to be as follows (assembler generated by: llc
mulches_ebp.bc):

At the start of "main" the stack pointer is saved in ebp:

main:                                   # @main
# BB#0:                                 # %entry
        pushl   %ebp
        movl    %esp, %ebp

Somewhere in the middle of the function ebp is used as a scratch register,
clobbering the original value:

        call    printf
        movswl  %bx, %ebp
        movl    %ebp, 8(%esp)

At the end of the function esp is restored from ebp, but gets the wrong
value because ebp was clobbered.

        movl    %ebp, %esp
        popl    %ebp
        ret
        .size   main, .-main

This causes a prompt crash.

-- 
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 llvm.org  Wed Mar 24 17:31:17 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 24 Mar 2010 17:31:17 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6697] New: format attribute not respected in printf
	warning
Message-ID: <bug-6697-206@http.llvm.org/bugs/>

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

           Summary: format attribute not respected in printf warning
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Driver
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: ori at avtalion.name
                CC: llvmbugs at cs.uiuc.edu


Compiling the following code:

#include <stdio.h>
#include <stdarg.h>

void myprintf(const char *format, int x, ...) __attribute__((__format__(printf,
1, 3)));
void myprintf(const char *format, int x, ...) {
    va_list args;
    va_start(args, x);
    vprintf(format, args);
    va_end(args);
}

int main() {
    myprintf("%s\n", 1, "foo");
    return 0;
}


Yields the warning:

format.c:13:13: warning: conversion specifies type 'char *' but the argument
has type 'int' [-Wformat]
        myprintf("%s\n", 1, "foo");
                  ~^     ~

However, the __format__ attribute clearly states that the varargs begin at 3,
not 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 llvm.org  Wed Mar 24 18:31:54 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 24 Mar 2010 18:31:54 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6682] -inline ignores noinline attribute
In-Reply-To: <bug-6682-206@http.llvm.org/bugs/>
References: <bug-6682-206@http.llvm.org/bugs/>
Message-ID: <20100324233154.F19902A6C12D@llvm.org>

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

Eric Christopher <echristo at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
                 CC|                            |echristo at gmail.com
         Resolution|FIXED                       |

--- Comment #2 from Eric Christopher <echristo at gmail.com> 2010-03-24 18:31:54 CDT ---
Seemed to have caused a problem in an apple project. Reopening and looking into
it.

-- 
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 llvm.org  Wed Mar 24 19:35:16 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 24 Mar 2010 19:35:16 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6663] MultiSource/Benchmarks/Bullet/bullet fails on
 x86-32 linux when using -fPIC
In-Reply-To: <bug-6663-206@http.llvm.org/bugs/>
References: <bug-6663-206@http.llvm.org/bugs/>
Message-ID: <20100325003516.904AA2A6C12E@llvm.org>

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

Evan Cheng <evan.cheng at apple.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 llvm.org  Wed Mar 24 21:50:39 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 24 Mar 2010 21:50:39 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6698] New: address-space 256/257 GEP references
 miscompiled at -O0
Message-ID: <bug-6698-206@http.llvm.org/bugs/>

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

           Summary: address-space 256/257 GEP references miscompiled at
                    -O0
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: X86
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: nelhage at mit.edu
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=4585)
 --> (http://llvm.org/bugs/attachment.cgi?id=4585)
Miscompiled example

The attached .ll file, when compiled on x86/x86_84 using 'llc -O0' produces
incorrect assembly, that results in a load without a specified segment, instead
of off the %fs segment as intended.

At -O1 or -O2 the GEP and the load are folded into a single instruction, which 
correctly loads off of %fs.

-- 
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 llvm.org  Wed Mar 24 22:21:06 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 24 Mar 2010 22:21:06 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6699] New: false positive memory leak in C arrays
 with CoreFoundation
Message-ID: <bug-6699-206@http.llvm.org/bugs/>

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

           Summary: false positive memory leak in C arrays with
                    CoreFoundation
           Product: clang
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: Static Analyzer
        AssignedTo: kremenek at apple.com
        ReportedBy: darkshadow at nightproductions.net
                CC: llvmbugs at cs.uiuc.edu


The static analyzer is reporting a false memory leak when assigning a
CoreFoundation object to a C style array inside of an if statement.

#include <CoreFoundation/CoreFoundation.h>

int main( int argc, const char *argv[] )
{
    CFStringRef keys[4];
    CFTypeRef values[4];
    CFDictionaryRef h = NULL;
    double num = 0.7;

    keys[0] = CFSTR("One");
    keys[1] = CFSTR("Two");
    keys[2] = CFSTR("Three");

    values[0] = values[1] = CFNumberCreate( kCFAllocatorDefault,
kCFNumberDoubleType, &num );
    num = 1.25;
    values[2] = CFNumberCreate( kCFAllocatorDefault, kCFNumberDoubleType, &num
);

    if ( argc > 1 ) {
        int numArgs = 4;
        keys[3] = CFSTR("Four");
               /*Following line is flagged as object created */
        values[3] = CFNumberCreate( kCFAllocatorDefault, kCFNumberIntType,
&numArgs );
        h = CFDictionaryCreate( kCFAllocatorDefault, (const void **)keys,
(const void **)values, 4, &kCFCopyStringDictionaryKeyCallBacks,
&kCFTypeDictionaryValueCallBacks );
    } else {
        keys[3] = NULL;
        values[3] = NULL;
        h = CFDictionaryCreate( kCFAllocatorDefault, (const void **)keys,
(const void **)values, 3, &kCFCopyStringDictionaryKeyCallBacks,
&kCFTypeDictionaryValueCallBacks );
    }

    CFShow( h );

    CFRelease( h );
    CFRelease( values[0] );
    CFRelease( values[2] );
    if ( values[3] ) /* Following line is falsely reporting a leak of above
object */
        CFRelease( values[3] );

    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 llvm.org  Wed Mar 24 22:32:38 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 24 Mar 2010 22:32:38 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6700] New: clang: Sema.h:3539: void
 clang::Sema::LocalInstantiationScope::InstantiatedLocal(const clang::Decl*,
 clang::Decl*): Assertion `(!Stored || Stored == Inst) && "Already
 instantiated this local"' failed.
Message-ID: <bug-6700-206@http.llvm.org/bugs/>

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

           Summary: clang: Sema.h:3539: void
                    clang::Sema::LocalInstantiationScope::InstantiatedLoca
                    l(const clang::Decl*, clang::Decl*): Assertion
                    `(!Stored || Stored == Inst) && "Already instantiated
                    this local"' failed.
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: b.jacques at planet.nl
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


The following program causes an assertion when compiled with Clang:
--

#include <boost/algorithm/string/replace.hpp>
#include <string>

int main()
{
    std::string foo = "aaaa";
    boost::algorithm::replace_all(foo, "a", "b");
}

--

Stack dump:
0.    Program arguments: /usr/local/llvm/bin/clang -cc1 -triple
i386-pc-linux-gnu -S -disable-free -main-file-name replace.cc
-mrelocation-model static -mdisable-fp-elim -mconstructor-aliases -target-cpu
pentium4 -resource-dir /home/bastiaan/llvm/lib/clang/1.5 -fmessage-length 133
-fexceptions -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o
/tmp/cc-R8Q4MV.s -x c++ replace.cc 
1.    <eof> parser at end of file
2.    /usr/include/boost/algorithm/string/replace.hpp:649:21: instantiating
function definition 'boost::algorithm::replace_all'
3.    /usr/include/boost/algorithm/string/find_format.hpp:251:21: instantiating
function definition 'boost::algorithm::find_format_all'

-- 
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 llvm.org  Wed Mar 24 23:00:09 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 24 Mar 2010 23:00:09 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6697] Handle format strings where the data argument
 is not adjacent to the format string
In-Reply-To: <bug-6697-206@http.llvm.org/bugs/>
References: <bug-6697-206@http.llvm.org/bugs/>
Message-ID: <20100325040009.9ACFA2A6C12E@llvm.org>

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

Ted Kremenek <kremenek at apple.com> changed:

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

--- Comment #2 from Ted Kremenek <kremenek at apple.com> 2010-03-24 23:00:09 CDT ---
Fixed:

http://llvm.org/viewvc/llvm-project?view=rev&revision=99480

A second bug was that the format string checking assumed the data arguments
immediately followed the format string.

-- 
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 llvm.org  Wed Mar 24 23:43:08 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 24 Mar 2010 23:43:08 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6698] address-space 256/257 GEP references
	miscompiled at -O0
In-Reply-To: <bug-6698-206@http.llvm.org/bugs/>
References: <bug-6698-206@http.llvm.org/bugs/>
Message-ID: <20100325044308.CAD8F2A6C12D@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #1 from Chris Lattner <clattner at apple.com> 2010-03-24 23:43:08 CDT ---


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

-- 
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 llvm.org  Wed Mar 24 23:51:31 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 24 Mar 2010 23:51:31 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6682] -inline ignores noinline attribute
In-Reply-To: <bug-6682-206@http.llvm.org/bugs/>
References: <bug-6682-206@http.llvm.org/bugs/>
Message-ID: <20100325045131.4530B2A6C12D@llvm.org>

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

Eric Christopher <echristo at gmail.com> changed:

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

--- Comment #4 from Eric Christopher <echristo at gmail.com> 2010-03-24 23:51:30 CDT ---
Reapplied here with a small fix:

http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20100322/098544.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 llvm.org  Thu Mar 25 00:58:49 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 25 Mar 2010 00:58:49 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6642] Loads from arrays initialized with a single
 large store not optimized
In-Reply-To: <bug-6642-206@http.llvm.org/bugs/>
References: <bug-6642-206@http.llvm.org/bugs/>
Message-ID: <20100325055849.94FB92A6C12D@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|WONTFIX                     |FIXED

--- Comment #9 from Chris Lattner <clattner at apple.com> 2010-03-25 00:58:48 CDT ---
No need, I fixed the memset case here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20100322/098553.html

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 llvm.org  Thu Mar 25 02:29:27 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 25 Mar 2010 02:29:27 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6613] doxygen is broken from objdir build
In-Reply-To: <bug-6613-206@http.llvm.org/bugs/>
References: <bug-6613-206@http.llvm.org/bugs/>
Message-ID: <20100325072927.E0ACC2A6C12C@llvm.org>

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

mikem.llvm at gmail.com changed:

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

-- 
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 llvm.org  Thu Mar 25 09:39:01 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 25 Mar 2010 09:39:01 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6701] New: Doesn't work with SELinux
Message-ID: <bug-6701-206@http.llvm.org/bugs/>

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

           Summary: Doesn't work with SELinux
           Product: new-bugs
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: edwintorok at gmail.com
                CC: llvmbugs at cs.uiuc.edu


SELinux disallows both writable and executable memory.
In enforcing mode LLVM crashes when trying to write:
#
#0  0x0000003772c7b444 in memset () from /lib64/libc.so.6
#
No symbol table info available.
#
#1  0x00002af2af41e1d2 in allocateNewSlab (this=0xf339000, size=<value
optimized out>) at llvm/lib/ExecutionEngine/JIT/JITMemoryManager.cpp:624
#
        ErrMsg = {static npos = 18446744073709551615,
#
  _M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> =
{<No data fields>}, <No data fields>}, _M_p = 0xf358af8 '?' <repeats 200
times>...}}
#
        LastSlabPtr = <value optimized out>
#
        B = {Address = 0xf3390e0, Size = 255037664}
#

And in non-enforcing mode SELinux logs an audit message:
type=AVC msg=audit(1269527244.925:38384): avc:  denied  { execmem } for 
pid=11936 comm="clamscan" scontext=user_u:system_r:clamscan_t:s0
tcontext=user_u:system_r:clamscan_t:s0 tclass=processss  pid=11936
comm="clamscan" scontext=user_u:sys

Turning execmem off is not an option, but here is some information on how to
write self-modifying code with execmem:
http://people.redhat.com/drepper/selinux-mem.html

Basically you map same file twice, once as writable, once as executable.
You write JITed code to one, and execute the other.

-- 
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 llvm.org  Thu Mar 25 10:30:20 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 25 Mar 2010 10:30:20 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6702] New: Wrong scoping for function parameter
	names?
Message-ID: <bug-6702-206@http.llvm.org/bugs/>

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

           Summary: Wrong scoping for function parameter names?
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: dgregor at apple.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


Clang rejects this code in C++ mode:

  typedef int a;
  void f(int a, a b);

while EDG and GCC accept it (the name 'a' binds to the typedef in global
scope).

Note that this code is ill-formed in C, indicating that the scope of function
parameter names differs between the two languages. I haven't been able to track
down the wording that makes this different.

-- 
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 llvm.org  Thu Mar 25 10:38:52 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 25 Mar 2010 10:38:52 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6703] New: Compiler fails on bool
	MutexImpl::MutexImpl()
Message-ID: <bug-6703-206@http.llvm.org/bugs/>

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

           Summary: Compiler fails on bool MutexImpl::MutexImpl()
           Product: new-bugs
           Version: 2.6
          Platform: PC
        OS/Version: other
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: reeuwijk at few.vu.nl
                CC: llvmbugs at cs.uiuc.edu


While porting llvm to minix 3.0, I came across the function

bool MutexImpl::MutexImpl(){ return true; }

in lib/System/Unix/Mutex.inc

The gcc compiler on Minix fails on this, because the function is not a
constructor. Simply removing the function doesn't seem to have any harmful
effects.

-- 
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 llvm.org  Thu Mar 25 10:45:12 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 25 Mar 2010 10:45:12 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6700] Assertion: Already instantiated this local
In-Reply-To: <bug-6700-206@http.llvm.org/bugs/>
References: <bug-6700-206@http.llvm.org/bugs/>
Message-ID: <20100325154512.55FC52A6C12E@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #2 from Douglas Gregor <dgregor at apple.com> 2010-03-25 10:45:11 CDT ---
I happen to have Boost around and was able to reproduce this bug locally.
However, Nuno is right: please provide a complete test case (reduced,
pre-processed) with bug reports.

Fixed in r99509.

-- 
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 llvm.org  Thu Mar 25 10:50:55 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 25 Mar 2010 10:50:55 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6704] New: Porting llvm to Minix
Message-ID: <bug-6704-206@http.llvm.org/bugs/>

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

           Summary: Porting llvm to Minix
           Product: new-bugs
           Version: 2.6
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: reeuwijk at few.vu.nl
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=4586)
 --> (http://llvm.org/bugs/attachment.cgi?id=4586)
Portability patches for minix

The attached patches help to make llvm compilable on Minix 3.

The porting also exposed a number of issues on Minix that have to be addressed.
With these patched too, llvm now largely passes the testsuite in 'tests'(there
are also some porting issues in the testsuite or dejagnu).

Note that the patch uses HAVE_DLFCN_H to test whether the platform supports
dynamic loading in the first place. It implements LoadLibraryPermanently as a
function that always fails if dynamic loading is not available.

To get llvm compiling on Minix I also had to remove LOADABLE_MODULE = 1 from
lib/Transforms/Hello/Makefile, and similar from runtime/libprofile/Makefile.
I'm not sure this makes sense. Perhaps another way to handle this is
preferable.

-- 
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 llvm.org  Thu Mar 25 11:09:10 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 25 Mar 2010 11:09:10 -0500 (CDT)
Subject: [LLVMbugs] [Bug 5818] CXXRecordDecl::getDestructor: Assertion `I !=
 E && "Did not find a destructor!"' failed.
In-Reply-To: <bug-5818-206@http.llvm.org/bugs/>
References: <bug-5818-206@http.llvm.org/bugs/>
Message-ID: <20100325160910.906432A6C124@llvm.org>

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

Nuno Lopes <nunoplopes at sapo.pt> 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 llvm.org  Thu Mar 25 11:31:43 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 25 Mar 2010 11:31:43 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6705] New: Assertion `I->second ==
 CleanupEntries.size() - 1' failed.
Message-ID: <bug-6705-206@http.llvm.org/bugs/>

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

           Summary: Assertion `I->second == CleanupEntries.size() - 1'
                    failed.
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: b.jacques at planet.nl
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


The following program:

#include <exception>

int main () {
  bool cond = false;

  try { }
  catch (std::exception& e) {
    if (cond) {
      throw e;
    }
    try { } catch (std::exception& e2) { }
  }
}

Causes this assertion failure:

clang: CGStmt.cpp:221: void
clang::CodeGen::CodeGenFunction::EmitBlock(llvm::BasicBlock*, bool): Assertion
`I->second == CleanupEntries.size() - 1' failed.
0  clang 0x08cbe858
Stack dump:
0.    Program arguments: /home/bastiaan/llvm/bin/clang -cc1 -triple
i386-pc-linux-gnu -S -disable-free -main-file-name exception.cc
-mrelocation-model static -mdisable-fp-elim -mconstructor-aliases -target-cpu
pentium4 -resource-dir /home/bastiaan/llvm/lib/clang/1.5 -fmessage-length 133
-fexceptions -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o
/tmp/cc-j5luRc.s -x c++ exception.cc 
1.    <eof> parser at end of file
2.    exception.cc:3:5: LLVM IR generation of declaration 'main'
3.    exception.cc:3:5: Generating code for declaration 'main'
4.    exception.cc:3:13: LLVM IR generation of compound statement ('{}')
5.    exception.cc:7:29: LLVM IR generation of compound statement ('{}')
clang: error: compiler command failed due to signal 6 (use -v to see
invocation)

-- 
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 llvm.org  Thu Mar 25 11:33:05 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 25 Mar 2010 11:33:05 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6702] Wrong scoping for function parameter names?
In-Reply-To: <bug-6702-206@http.llvm.org/bugs/>
References: <bug-6702-206@http.llvm.org/bugs/>
Message-ID: <20100325163305.963E42A6C124@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #2 from Douglas Gregor <dgregor at apple.com> 2010-03-25 11:33:05 CDT ---
Nevermind! It's a GCC bug, which EDG is emulating. Turning on EDG's strict mode
confirms that Clang's behavior is indeed correct. We do not attempt to emulate
GCC's behavior, since it's potentially dangerous:

  typedef double a;
  void f(int a, int b = sizeof(a)) ;

here, GCC will give b a default argument value of sizeof(double). Clang (and
EDG in strict mode) correctly reject it.

-- 
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 llvm.org  Thu Mar 25 11:38:39 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 25 Mar 2010 11:38:39 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6100] Assertion failed: (I->second ==
 CleanupEntries.size() - 1), function EmitBlock, file CGStmt.cpp, line 221.
In-Reply-To: <bug-6100-206@http.llvm.org/bugs/>
References: <bug-6100-206@http.llvm.org/bugs/>
Message-ID: <20100325163839.C2BEB2A6C12E@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #2 from Douglas Gregor <dgregor at apple.com> 2010-03-25 11:38:39 CDT ---


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

-- 
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 llvm.org  Thu Mar 25 11:38:51 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 25 Mar 2010 11:38:51 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6705] Assertion `I->second == CleanupEntries.size()
 - 1' failed.
In-Reply-To: <bug-6705-206@http.llvm.org/bugs/>
References: <bug-6705-206@http.llvm.org/bugs/>
Message-ID: <20100325163851.4C13B2A6C12E@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #2 from Douglas Gregor <dgregor at apple.com> 2010-03-25 11:38:51 CDT ---


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

-- 
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 llvm.org  Thu Mar 25 11:45:17 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 25 Mar 2010 11:45:17 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6706] New: Assertion: Sema doesn't consider
	destructor as used
Message-ID: <bug-6706-206@http.llvm.org/bugs/>

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

           Summary: Assertion: Sema doesn't consider destructor as used
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: dgregor at apple.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


blackthorn:clang dgregor$ cat t.C
struct A { 
  virtual ~A();
};
struct B : virtual A { };
struct C : virtual A { };

struct D : B, C { 
  virtual void f();
  virtual ~D();
};

void D::f() { }

blackthorn:clang dgregor$ clang t.C
Assertion failed: (DD->isUsed() && "Sema doesn't consider destructor as
used."), function GetOrCreateLLVMFunction, file
/Users/dgregor/Projects/llvm/tools/clang/lib/CodeGen/CodeGenModule.cpp, line
803.
Stack dump:
0.    Program arguments: /Users/dgregor/Projects/llvm-make/bin/clang -cc1
-triple x86_64-apple-darwin10.0.0 -S -disable-free -main-file-name t.C
-pic-level 1 -mdisable-fp-elim -munwind-tables -target-cpu core2 -resource-dir
/Users/dgregor/Projects/llvm-make/lib/clang/1.5 -fmessage-length 80
-stack-protector 1 -fblocks -fexceptions -fdiagnostics-show-option
-fcolor-diagnostics -o
/var/folders/Vf/VfsrpcXeFyKWp16pSa7tMk+++TI/-Tmp-/cc-vIddp2.s -x c++ t.C 
1.    <eof> parser at end of file
2.    t.C:12:9: LLVM IR generation of declaration 'D::f'
3.    t.C:12:9: Generating code for declaration 'D::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 llvm.org  Thu Mar 25 13:36:23 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 25 Mar 2010 13:36:23 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6707] New: Template argument deduction fails for
 non-type template parameters with dependent type
Message-ID: <bug-6707-206@http.llvm.org/bugs/>

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

           Summary: Template argument deduction fails for non-type
                    template parameters with dependent type
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: dgregor at apple.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


Example:

terfin:clang dgregor$ cat t.C
template<typename T, T Value>
struct X { };

template<typename T, T Value>
void f(X<T, Value>);

void g(X<int, 10> x) {
  f(x);
}

terfin:clang dgregor$ clang++ t.C
Assertion failed: (false && "Should not see dependent types"), function
getTypeInfo, file
/Volumes/Data/dgregor/Projects/llvm/tools/clang/lib/AST/ASTContext.cpp, line
486.
Stack dump:
0.    Program arguments:
/Volumes/Data/dgregor/Projects/llvm-build-xcode/bin/Debug/clang -cc1 -triple
x86_64-apple-darwin10.0.0 -S -disable-free -main-file-name t.C -pic-level 1
-mdisable-fp-elim -munwind-tables -target-cpu core2 -resource-dir
/Volumes/Data/dgregor/Projects/llvm-build-xcode/bin/lib/clang/1.5
-fmessage-length 80 -stack-protector 1 -fblocks -fexceptions
-fdiagnostics-show-option -fcolor-diagnostics -o
/var/folders/4o/4oX0yyc9FZ0tdikPS5odWE+++TI/-Tmp-/cc-y9VTDU.s -x c++ t.C 
1.    t.C:8:6: current parser token ')'
2.    t.C:7:22: parsing function body 'g'
3.    t.C:7:22: in compound statement ('{}')

-- 
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 llvm.org  Thu Mar 25 18:07:25 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 25 Mar 2010 18:07:25 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6708] New: clang should print inputs to constant
 expressions that cause errors
Message-ID: <bug-6708-206@http.llvm.org/bugs/>

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

           Summary: clang should print inputs to constant expressions that
                    cause errors
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Keywords: quality-of-implementation
          Severity: enhancement
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: jyasskin at google.com
                CC: chandlerc at gmail.com, llvmbugs at cs.uiuc.edu,
                    dgregor at apple.com


In metaprogramming, we often make assertions about constant expressions. It
would be nice if clang could explain why the constant expression had a bad
value. I don't know how to format the message I'm asking for though.

One example of the problem is below. It would be nice to see how 'expr' was
computed in the first note.

$ cat ~/tmp/test.cc
template <bool>
struct CompileAssert {
};
#define COMPILE_ASSERT(expr, msg) \
  typedef ::CompileAssert<(bool(expr))> \
      msg[bool(expr) ? 1 : -1]

template<typename T>
void foo(const T& t) {
    COMPILE_ASSERT(
        sizeof(T) > 4, T_is_too_small);
}

int main() {
    foo(3);
}
$ Debug/bin/clang++ -c ~/tmp/test.cc
/Users/jyasskin/tmp/test.cc:10:5: error: array size is negative
    COMPILE_ASSERT(
    ^~~~~~~~~~~~~~~
/Users/jyasskin/tmp/test.cc:6:11: note: instantiated from:
      msg[bool(expr) ? 1 : -1]
          ^~~~~~~~~~~~~~~~~~~
/Users/jyasskin/tmp/test.cc:15:5: note: in instantiation of function template
specialization 'foo<int>' requested here
    foo(3);
    ^
2 diagnostics generated.

-- 
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 llvm.org  Thu Mar 25 19:38:47 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 25 Mar 2010 19:38:47 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6706] Assertion: Sema doesn't consider destructor
	as used
In-Reply-To: <bug-6706-206@http.llvm.org/bugs/>
References: <bug-6706-206@http.llvm.org/bugs/>
Message-ID: <20100326003847.B7E6B2A6C124@llvm.org>

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

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

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

--- Comment #5 from Rafael ?vila de Esp?ndola <rafael.espindola at gmail.com> 2010-03-25 19:38:47 CDT ---
Fixed in r99582.

-- 
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 llvm.org  Thu Mar 25 19:56:35 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 25 Mar 2010 19:56:35 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6709] New: Clang instantiates unused function
	argument
Message-ID: <bug-6709-206@http.llvm.org/bugs/>

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

           Summary: Clang instantiates unused function argument
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: b.jacques at planet.nl
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


At least, that is the best explanation I can give. The following program:

#include <boost/scoped_ptr.hpp>

class Forward;

class MyClass {
    void foo (boost::scoped_ptr<Forward> ptr) {}
};

int main() { }

Fails to compile with:

In file included from scoped.cpp:1:
In file included from /usr/include/boost/scoped_ptr.hpp:14:
In file included from /usr/include/boost/smart_ptr/scoped_ptr.hpp:15:
/usr/include/boost/checked_delete.hpp:32:41: error: invalid application of
'sizeof' to an incomplete type 'Forward'
    typedef char type_must_be_complete[ sizeof(T)? 1: -1 ];
                                        ^~~~~~~~~
In file included from scoped.cpp:1:
In file included from /usr/include/boost/scoped_ptr.hpp:14:
/usr/include/boost/smart_ptr/scoped_ptr.hpp:80:9: note: in instantiation of
function template specialization
      'boost::checked_delete<Forward>' requested here
        boost::checked_delete( px );
        ^
scoped.cpp:6:42: note: in instantiation of member function
'boost::scoped_ptr<Forward>::~scoped_ptr' requested here
    void foo (boost::scoped_ptr<Forward> ptr) {}
                                         ^
scoped.cpp:3:7: note: forward declaration of 'Forward'
class Forward;
      ^
4 diagnostics generated.


GCC accepts the program.

-- 
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 llvm.org  Fri Mar 26 00:59:44 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 26 Mar 2010 00:59:44 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6707] Template argument deduction fails for
 non-type template parameters with dependent type
In-Reply-To: <bug-6707-206@http.llvm.org/bugs/>
References: <bug-6707-206@http.llvm.org/bugs/>
Message-ID: <20100326055944.767D72A6C12C@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #1 from Douglas Gregor <dgregor at apple.com> 2010-03-26 00:59:44 CDT ---
Fixed in r99611.

-- 
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 llvm.org  Fri Mar 26 01:57:22 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 26 Mar 2010 01:57:22 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6709] Clang instantiates destructor for function
	argument
In-Reply-To: <bug-6709-206@http.llvm.org/bugs/>
References: <bug-6709-206@http.llvm.org/bugs/>
Message-ID: <20100326065722.BEFD22A6C12E@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #3 from Douglas Gregor <dgregor at apple.com> 2010-03-26 01:57:22 CDT ---
Well, it doesn't make sense that we need a destructor (since the caller will
handle the destruction), I don't see any justification for this behavior in the
C++ standard, and none of the other compilers do it, so... fixed in r99615.

-- 
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 llvm.org  Fri Mar 26 02:06:44 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 26 Mar 2010 02:06:44 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6567] Assertion failed: Cannot get layout of
 forward declarations!
In-Reply-To: <bug-6567-206@http.llvm.org/bugs/>
References: <bug-6567-206@http.llvm.org/bugs/>
Message-ID: <20100326070644.7A7D12A6C124@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=6567

Douglas Gregor <dgregor at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |WORKSFORME

--- Comment #3 from Douglas Gregor <dgregor at apple.com> 2010-03-26 02:06:43 CDT ---
This appears to be fixed now.

-- 
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 llvm.org  Fri Mar 26 03:47:15 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 26 Mar 2010 03:47:15 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6711] New: atomic builtin test uses C compiler
 instead of C++ compiler
Message-ID: <bug-6711-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=6711

           Summary: atomic builtin test uses C compiler instead of C++
                    compiler
           Product: new-bugs
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: edwintorok at gmail.com
                CC: llvmbugs at cs.uiuc.edu


It uses the C compiler to do the test, and succeeds (atomic builtins
available).
At build time it fails to link with missing symbols for
__sync_val_compare_and_swap_4, because it uses the C++ compiler for linking
(and that is not what configure tested).

This happens if you build with CFLAGS != CXXFLAGS, and CFLAGS sets the target
architecture to something that supports atomic builtins, while CXXFLAGS stays
at the default (i386?) that doesn't support it.

See here for more details:
http://lurker.clamav.net/message/20100326.084547.051ffb52.en.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 llvm.org  Fri Mar 26 10:16:57 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 26 Mar 2010 10:16:57 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6516] Assertion failed: (I != FieldInfo.end() &&
 "Unable to find field info")
In-Reply-To: <bug-6516-206@http.llvm.org/bugs/>
References: <bug-6516-206@http.llvm.org/bugs/>
Message-ID: <20100326151657.97BC12A6C12E@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=6516

Douglas Gregor <dgregor at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |WORKSFORME

--- Comment #1 from Douglas Gregor <dgregor at apple.com> 2010-03-26 10:16:57 CDT ---
This seems to be working properly now.

-- 
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 llvm.org  Fri Mar 26 10:19:37 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 26 Mar 2010 10:19:37 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6324] Specialisation causes assert
In-Reply-To: <bug-6324-206@http.llvm.org/bugs/>
References: <bug-6324-206@http.llvm.org/bugs/>
Message-ID: <20100326151937.E40662A6C12D@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=6324

Douglas Gregor <dgregor at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #1 from Douglas Gregor <dgregor at apple.com> 2010-03-26 10:19:37 CDT ---
I fixed this recently while improving our handling of non-type template
parameters.

-- 
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 llvm.org  Fri Mar 26 10:28:14 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 26 Mar 2010 10:28:14 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6712] New: mergefunc work looks not as good as
 possible with weak_odr
Message-ID: <bug-6712-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=6712

           Summary: mergefunc work looks not as good as possible with
                    weak_odr
           Product: new-bugs
           Version: 2.6
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Keywords: code-quality
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: bearophile at mailas.com
                CC: llvmbugs at cs.uiuc.edu


I am looking at the -mergefunc pass to remove some template bloat from D
language programs that contain function templates.

This is the D code I have compiled with LDC:


import tango.stdc.stdio: printf;
import tango.stdc.stdlib: atoi;
T factorial(T)(T x) {
  if (x == 0)
    return 1;
  else
    return x * factorial(x - 1);
}
void main(char[][] args) {
  printf("%d\n", factorial(atoi(args[1].ptr)));
  printf("%d\n", factorial(cast(uint)atoi(args[1].ptr)));
}


Compiling it with:
ldc -mergefunc -output-s temp2.d
It produces the (cleaned up) asm:


factorial!int:
    subl    $4, %esp
    call    __unnamed_1
    addl    $4, %esp
    ret

factorial!uint:
    subl    $4, %esp
    call    __unnamed_1
    addl    $4, %esp
    ret

__unnamed_1:
    subl    $4, %esp
    movl    %eax, (%esp)
    testl    %eax, %eax
    jne    .LBB2_2
    movl    $1, %eax
    addl    $4, %esp
    ret
.LBB2_2:
    movl    (%esp), %eax
    decl    %eax
    call    factorial!uint
    imull    (%esp), %eax
    addl    $4, %esp
    ret

_Dmain:
    subl    $28, %esp
    movl    36(%esp), %eax
    movl    %eax, 20(%esp)
    movl    32(%esp), %eax
    movl    %eax, 16(%esp)
    cmpl    $1, 16(%esp)
    jbe    .LBB1_3
    movl    20(%esp), %eax
    movl    12(%eax), %eax
    movl    %eax, (%esp)
    call    atoi
    call    factorial!int
    movl    %eax, 4(%esp)
    movl    $.str, (%esp)
    call    printf
    cmpl    $1, 16(%esp)
    jbe    .LBB1_4
    movl    20(%esp), %eax
    movl    12(%eax), %eax
    movl    %eax, (%esp)
    call    atoi
    call    factorial!uint
    movl    %eax, 4(%esp)
    movl    $.str2, (%esp)
    call    printf
    xorl    %eax, %eax
    addl    $28, %esp
    ret    $8
.LBB1_3:
    movl    .modulefilename+4, %eax
    movl    %eax, 4(%esp)
    movl    .modulefilename, %eax
    movl    %eax, (%esp)
    movl    $12, 8(%esp)
    call    _d_array_bounds
.LBB1_4:
    movl    .modulefilename+4, %eax
    movl    %eax, 4(%esp)
    movl    .modulefilename, %eax
    movl    %eax, (%esp)
    movl    $13, 8(%esp)
    call    _d_array_bounds



The bytecode generated with (some parts of the bytecode removed):
ldc -mergefunc -release -output-ll temp2.d


define x86_stdcallcc i32 @_Dmain(%"char[][]" %args_arg) {
entry:
  %args = alloca %"char[][]"                      ; <%"char[][]"*> [#uses=3]
  store %"char[][]" %args_arg, %"char[][]"* %args
  %tmp = getelementptr %"char[][]"* %args, i32 0, i32 1 ; <%"byte[]"**>
[#uses=1]
  %.ptr = load %"byte[]"** %tmp                   ; <%"byte[]"*> [#uses=1]
  %tmp1 = getelementptr %"byte[]"* %.ptr, i32 1   ; <%"byte[]"*> [#uses=1]
  %tmp2 = getelementptr %"byte[]"* %tmp1, i32 0, i32 1 ; <i8**> [#uses=1]
  %.ptr3 = load i8** %tmp2                        ; <i8*> [#uses=1]
  %tmp4 = call i32 @atoi(i8* %.ptr3)              ; <i32> [#uses=1]
  %tmp5 = call x86_stdcallcc i32 @_D5temp216__T9factorialTiZ9factorialFiZi(i32
inreg %tmp4) ; <i32> [#uses=1]
  %tmp6 = call i32 (i8*, ...)* @printf(i8* getelementptr ([4 x i8]* @.str, i32
0, i32 0), i32 %tmp5) ; <i32> [#uses=0]
  %tmp7 = getelementptr %"char[][]"* %args, i32 0, i32 1 ; <%"byte[]"**>
[#uses=1]
  %.ptr8 = load %"byte[]"** %tmp7                 ; <%"byte[]"*> [#uses=1]
  %tmp9 = getelementptr %"byte[]"* %.ptr8, i32 1  ; <%"byte[]"*> [#uses=1]
  %tmp10 = getelementptr %"byte[]"* %tmp9, i32 0, i32 1 ; <i8**> [#uses=1]
  %.ptr11 = load i8** %tmp10                      ; <i8*> [#uses=1]
  %tmp12 = call i32 @atoi(i8* %.ptr11)            ; <i32> [#uses=1]
  %tmp13 = call x86_stdcallcc i32 @_D5temp216__T9factorialTkZ9factorialFkZk(i32
inreg %tmp12) ; <i32> [#uses=1]
  %tmp14 = call i32 (i8*, ...)* @printf(i8* getelementptr ([4 x i8]* @.str1,
i32 0, i32 0), i32 %tmp13) ; <i32> [#uses=0]
  ret i32 0
}

define internal x86_stdcallcc i32 @0(i32 inreg %x_arg) {
entry:
  %x = alloca i32                                 ; <i32*> [#uses=4]
  store i32 %x_arg, i32* %x
  %tmp = load i32* %x                             ; <i32> [#uses=1]
  %tmp1 = icmp eq i32 %tmp, 0                     ; <i1> [#uses=1]
  br i1 %tmp1, label %if, label %else

if:                                               ; preds = %entry
  ret i32 1

afterreturn:                                      ; No predecessors!
  br label %endif

else:                                             ; preds = %entry
  %tmp2 = load i32* %x                            ; <i32> [#uses=1]
  %tmp3 = sub i32 %tmp2, 1                        ; <i32> [#uses=1]
  %tmp4 = call x86_stdcallcc i32 @_D5temp216__T9factorialTkZ9factorialFkZk(i32
inreg %tmp3) ; <i32> [#uses=1]
  %tmp5 = load i32* %x                            ; <i32> [#uses=1]
  %tmp6 = mul i32 %tmp5, %tmp4                    ; <i32> [#uses=1]
  ret i32 %tmp6

afterreturn7:                                     ; No predecessors!
  br label %endif

endif:                                            ; preds = %afterreturn7,
%afterreturn
  ret i32 undef
}

define weak_odr x86_stdcallcc i32 @_D5temp216__T9factorialTiZ9factorialFiZi(i32
inreg) {
  %2 = tail call x86_stdcallcc i32 @0(i32 %0)     ; <i32> [#uses=1]
  ret i32 %2
}

define weak_odr x86_stdcallcc i32 @_D5temp216__T9factorialTkZ9factorialFkZk(i32
inreg) {
  %2 = tail call x86_stdcallcc i32 @0(i32 %0)     ; <i32> [#uses=1]
  ret i32 %2
}



On IRC in #llvm baldrick has said:

this may well be a bug - it's not clear to me why weak_odr linkage would be a
problem
try asking nlewycky

-- 
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 llvm.org  Fri Mar 26 12:52:33 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 26 Mar 2010 12:52:33 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6713] New: autotools are not honoring LIBDIR
	settings
Message-ID: <bug-6713-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=6713

           Summary: autotools are not honoring LIBDIR settings
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Static Analyzer
        AssignedTo: kremenek at apple.com
        ReportedBy: herrold at owlriver.com
                CC: llvmbugs at cs.uiuc.edu


Red Hat multilib distinguishes /usr/lib/ and /usr/lib64

Putting questions on their design choices to one side (there are arguments for
this which are sensible)  ;)  )  I end up having to add manual entries for
packaging what LIBDIR should posution correctly automatically

...
Processing files: clang-debuginfo-0.0.20100326.cvs-1orc
Provides: libCIndex.so.debug()(64bit) libEnhancedDisassembly.so.debug()(64bit)
libLLVMHello.so.debug()(64bit) libLTO.so.debug()(64bit)
libprofile_rt.so.debug()(64bit)
Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
Checking for unpackaged file(s): /usr/lib/rpm/check-files
/var/tmp/clang-0.0.20100326.cvs.root
error: Installed (but unpackaged) file(s) found:
   /usr/lib/clang/1.5/include/emmintrin.h
   /usr/lib/clang/1.5/include/float.h
   /usr/lib/clang/1.5/include/iso646.h
   /usr/lib/clang/1.5/include/limits.h
   /usr/lib/clang/1.5/include/mm_malloc.h
   /usr/lib/clang/1.5/include/mmintrin.h
   /usr/lib/clang/1.5/include/nmmintrin.h
   /usr/lib/clang/1.5/include/pmmintrin.h
   /usr/lib/clang/1.5/include/smmintrin.h
   /usr/lib/clang/1.5/include/stdarg.h
   /usr/lib/clang/1.5/include/stdbool.h
   /usr/lib/clang/1.5/include/stddef.h
   /usr/lib/clang/1.5/include/stdint.h
   /usr/lib/clang/1.5/include/tgmath.h
   /usr/lib/clang/1.5/include/tmmintrin.h
   /usr/lib/clang/1.5/include/varargs.h
   /usr/lib/clang/1.5/include/xmmintrin.h


RPM build errors:
    File not found:
/var/tmp/clang-0.0.20100326.cvs.root/usr/lib/clang/1.1/include
    Installed (but unpackaged) file(s) found:
   /usr/lib/clang/1.5/include/emmintrin.h
   /usr/lib/clang/1.5/include/float.h
   /usr/lib/clang/1.5/include/iso646.h
   /usr/lib/clang/1.5/include/limits.h
   /usr/lib/clang/1.5/include/mm_malloc.h
   /usr/lib/clang/1.5/include/mmintrin.h
   /usr/lib/clang/1.5/include/nmmintrin.h
   /usr/lib/clang/1.5/include/pmmintrin.h
   /usr/lib/clang/1.5/include/smmintrin.h
   /usr/lib/clang/1.5/include/stdarg.h
   /usr/lib/clang/1.5/include/stdbool.h
   /usr/lib/clang/1.5/include/stddef.h
   /usr/lib/clang/1.5/include/stdint.h
   /usr/lib/clang/1.5/include/tgmath.h
   /usr/lib/clang/1.5/include/tmmintrin.h
   /usr/lib/clang/1.5/include/varargs.h
   /usr/lib/clang/1.5/include/xmmintrin.h

============================

when called thus:
CFLAGS="-g0 -O2 -pipe" ./configure                      \
                --prefix=%{prefix}                      \
                --libexecdir=%{_bindir}                 \
                --libdir=%{_libdir}                     \
...
make DESTDIR=%{buildroot}               \
        prefix=%{_prefix}               \
        libdir=%{_libdir}

...
make DESTDIR=%{buildroot} install       \
        prefix=%{_prefix}               \
        libdir=%{_libdir}


and in my buildsystem, %{_libdir} expands (there is an inheritance chain) to:

[herrold at centos-5 clang]$ rpm --showrc | grep ": _libdir"
-14: _libdir    %{_exec_prefix}/%{_lib}
[herrold at centos-5 clang]$ rpm --showrc | grep ": _exec_prefix"
-14: _exec_prefix       %{_prefix}
[herrold at centos-5 clang]$ rpm --showrc | grep ": _prefix"
-14: _prefix    /usr
[herrold at centos-5 clang]$  

[herrold at centos-5 clang]$ uname -a
Linux centos-5.first.lan 2.6.18-164.11.1.el5xen #1 SMP Wed Jan 20 08:06:04 EST
2010 x86_64 x86_64 x86_64 GNU/Linux
[herrold at centos-5 clang]$

not critical, but the appearance of /1.5/ along side the already crufty /1.1/ 
caused an unnecessary lost 3 hr build cycle for me  ;(

where I had to add the hardcoded (and wrong, to autotool's view of what should
have been a value the system could have figured out if the expansion had been
followed) 

... 
#   /usr/lib/clang/1.1/include/emmintrin.h
# %{_libdir}/clang/1.1/include/
#       here: does not follow RH's opinions on multi-lib
/usr/lib/clang/1.1/include/
/usr/lib/clang/1.5/include/
...

-- Russ herrold

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 llvm.org  Fri Mar 26 16:00:03 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 26 Mar 2010 16:00:03 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6595] Flase error: conditional expression is
	ambiguous
In-Reply-To: <bug-6595-206@http.llvm.org/bugs/>
References: <bug-6595-206@http.llvm.org/bugs/>
Message-ID: <20100326210003.11A032A6C12E@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=6595

Douglas Gregor <dgregor at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #3 from Douglas Gregor <dgregor at apple.com> 2010-03-26 16:00:02 CDT ---
Fixed in r99652.

-- 
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 llvm.org  Fri Mar 26 16:12:26 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 26 Mar 2010 16:12:26 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6716] New: Name lookup not finding friend function
 template definitions inside class template
Message-ID: <bug-6716-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=6716

           Summary: Name lookup not finding friend function template
                    definitions inside class template
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: dgregor at apple.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com,
                    rjmccall at apple.com


template<typename T, typename U = T>
struct X { };

template<typename T>
struct Y {
  template<typename U> friend void operator<<(X<T, U>&, const Y&) { }
};

void f(X<int, float> &x) {
  x << Y<int>();
}
terfin:clang dgregor$ clang++ t.C
t.C:10:5: error: invalid operands to binary expression ('X<int, float>' and
      'Y<int>')
  x << Y<int>();
  ~ ^  ~~~~~~~~
1 diagnostic generated.

-- 
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 llvm.org  Fri Mar 26 17:10:56 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 26 Mar 2010 17:10:56 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6717] New: Cannot handle template name-lookup
	ambiguities
Message-ID: <bug-6717-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=6717

           Summary: Cannot handle template name-lookup ambiguities
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: evan at chromium.org
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


Created an attachment (id=4594)
 --> (http://llvm.org/bugs/attachment.cgi?id=4594)
reduction of problematic file

>From the code it looks like this is already a FIXME.  I ran into this while
trying to compile the Chromium browser.

Reduced test case 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 llvm.org  Fri Mar 26 17:17:37 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 26 Mar 2010 17:17:37 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6703] Compiler fails on bool MutexImpl::MutexImpl()
In-Reply-To: <bug-6703-206@http.llvm.org/bugs/>
References: <bug-6703-206@http.llvm.org/bugs/>
Message-ID: <20100326221737.5066D2A6C12D@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=6703

Chris Lattner <clattner at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #1 from Chris Lattner <clattner at apple.com> 2010-03-26 17:17:37 CDT ---
Thanks, fixed in r99658

-- 
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 llvm.org  Fri Mar 26 17:59:52 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 26 Mar 2010 17:59:52 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6341] Error when using duplicated namespace aliases
In-Reply-To: <bug-6341-206@http.llvm.org/bugs/>
References: <bug-6341-206@http.llvm.org/bugs/>
Message-ID: <20100326225952.C3F092A6C12E@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=6341

Douglas Gregor <dgregor at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #2 from Douglas Gregor <dgregor at apple.com> 2010-03-26 17:59:52 CDT ---
Fixed in r99664.

-- 
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 llvm.org  Fri Mar 26 18:10:39 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 26 Mar 2010 18:10:39 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6716] Name lookup not finding friend function
 template definitions inside class template
In-Reply-To: <bug-6716-206@http.llvm.org/bugs/>
References: <bug-6716-206@http.llvm.org/bugs/>
Message-ID: <20100326231039.BC79A2A6C12D@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=6716

John McCall <rjmccall at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #1 from John McCall <rjmccall at apple.com> 2010-03-26 18:10:39 CDT ---
Fixed in r99665.

-- 
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 llvm.org  Fri Mar 26 18:23:32 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 26 Mar 2010 18:23:32 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6689] llvm-ld crashes when outputting to stdout
In-Reply-To: <bug-6689-206@http.llvm.org/bugs/>
References: <bug-6689-206@http.llvm.org/bugs/>
Message-ID: <20100326232332.B1F8A2A6C12D@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=6689

Chris Lattner <clattner at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #2 from Chris Lattner <clattner at apple.com> 2010-03-26 18:23:32 CDT ---
I think this is fixed enough :)  Thanks Dan,

-- 
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 llvm.org  Fri Mar 26 18:30:51 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 26 Mar 2010 18:30:51 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6719] New: Implement GNU strong using
 directives/C++0x inline namespaces
Message-ID: <bug-6719-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=6719

           Summary: Implement GNU strong using directives/C++0x inline
                    namespaces
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: dgregor at apple.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


Important for libstdc++ debug mode.

-- 
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 llvm.org  Fri Mar 26 19:47:48 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 26 Mar 2010 19:47:48 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6695] clang doesn't turn restrict into noalias
In-Reply-To: <bug-6695-206@http.llvm.org/bugs/>
References: <bug-6695-206@http.llvm.org/bugs/>
Message-ID: <20100327004748.28F642A6C12D@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=6695

John McCall <rjmccall at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #2 from John McCall <rjmccall at apple.com> 2010-03-26 19:47:47 CDT ---
Fixed in r99688.

-- 
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 llvm.org  Fri Mar 26 21:54:00 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 26 Mar 2010 21:54:00 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6685] clang emits undefined symbol for type info
 while gcc emits a weak one
In-Reply-To: <bug-6685-206@http.llvm.org/bugs/>
References: <bug-6685-206@http.llvm.org/bugs/>
Message-ID: <20100327025400.D376E2A6C12E@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=6685

Rafael ?vila de Esp?ndola <rafael.espindola at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED

--- Comment #6 from Rafael ?vila de Esp?ndola <rafael.espindola at gmail.com> 2010-03-26 21:53:54 CDT ---
Fixed in r99701.

-- 
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 llvm.org  Fri Mar 26 21:57:33 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 26 Mar 2010 21:57:33 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6677] Assertion failed: (DD->isUsed() && "Sema
 doesn't consider destructor as used."), function GetOrCreateLLVMFunction,
 file CodeGenModule.cpp, line 814.
In-Reply-To: <bug-6677-206@http.llvm.org/bugs/>
References: <bug-6677-206@http.llvm.org/bugs/>
Message-ID: <20100327025738.E743C2A6C124@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=6677

Rafael ?vila de Esp?ndola <rafael.espindola at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #4 from Rafael ?vila de Esp?ndola <rafael.espindola at gmail.com> 2010-03-26 21:57:29 CDT ---
This 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 llvm.org  Fri Mar 26 22:51:35 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 26 Mar 2010 22:51:35 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6674] clang++ emits sometimes for extern template
In-Reply-To: <bug-6674-206@http.llvm.org/bugs/>
References: <bug-6674-206@http.llvm.org/bugs/>
Message-ID: <20100327035135.0CCFA2A6C12E@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=6674

Rafael ?vila de Esp?ndola <rafael.espindola at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |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 llvm.org  Fri Mar 26 23:53:45 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 26 Mar 2010 23:53:45 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6720] New: invalid jump diagnostic refers to
	deleted Stmt
Message-ID: <bug-6720-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=6720

           Summary: invalid jump diagnostic refers to deleted Stmt
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: nlewycky at google.com
                CC: llvmbugs at cs.uiuc.edu


This is a crash on invalid. Given the code:

  extern int f(char *);

  void test(const UnknownType &RHS) {
    if (int Res = f(RHS.Data))
      ;
  }

clang will crash inside of Sema::DiagnoseInvalidJumps as it tries to access the
Stmt inside the if-statement.

clang:
/home/nlewycky/llvm/tools/clang/lib/Frontend/../../include/clang/AST/Stmt.h:202:
clang::Stmt::StmtClass clang::Stmt::getStmtClass() const: Assertion `RefCount
>= 1 && "Referencing already-destroyed statement!"' failed.

Repro with "clang -fsyntax-only test.cc". The relevant part of the stack trace
is:

#3  0x00000000004568e3 in clang::Stmt::getStmtClass (this=0x28e00f0)
    at
/home/nlewycky/llvm/tools/clang/lib/Frontend/../../include/clang/AST/Stmt.h:202
[...]
#11 0x00000000007d98f5 in BuildScopeInformation (this=0x7fffffffb370, 
    S=0x28e0240, ParentScope=0) at JumpDiagnostics.cpp:128
#12 0x00000000007d9d9f in BuildScopeInformation (this=0x7fffffffb370, 
    S=0x28e0278, ParentScope=0) at JumpDiagnostics.cpp:215
#13 0x00000000007d9e63 in JumpScopeChecker (this=0x7fffffffb370, 
    Body=0x28e0278, s=...) at JumpDiagnostics.cpp:72
#14 0x00000000007d9ea1 in clang::Sema::DiagnoseInvalidJumps (
    this=0x7fffffffc810, Body=0x28e0278) at JumpDiagnostics.cpp:332

-- 
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 llvm.org  Sat Mar 27 02:22:34 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 27 Mar 2010 02:22:34 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6712] mergefunc work looks not as good as possible
 with weak_odr
In-Reply-To: <bug-6712-206@http.llvm.org/bugs/>
References: <bug-6712-206@http.llvm.org/bugs/>
Message-ID: <20100327072235.16F762A6C12C@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=6712

Nick Lewycky <nicholas at mxc.ca> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID

--- Comment #3 from Nick Lewycky <nicholas at mxc.ca> 2010-03-27 02:22:34 CDT ---
The output IR as pasted can't be improved upon. 
@_D5temp216__T9factorialTiZ9factorialFiZi and 
@_D5temp216__T9factorialTkZ9factorialFkZk are weak, so there's nothing more to
do. We can't delete them (since they're externally visible symbols) or merge
them any further since they contain nothing but calls to @0. @0 places calls to
both of the @_D5temp... methods, but since those are weak, we can't turn those
into direct calls of @0 either.

-- 
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 llvm.org  Sat Mar 27 04:39:19 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 27 Mar 2010 04:39:19 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6721] New: llvm-gcc -c -emit-llvm doesn't create
	.bc file
Message-ID: <bug-6721-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=6721

           Summary: llvm-gcc -c -emit-llvm doesn't create .bc file
           Product: tools
           Version: trunk
          Platform: PC
        OS/Version: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: llvm-gcc
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: vlacomp at orange.fr
                CC: llvmbugs at cs.uiuc.edu


Hi,
Thanks for making llvm available.
I compiled/installed successfully llvm and llvm-gcc-4.2 on CYGWIN_NT-6.0.
I am using the svn versions of llvm and llvm-gcc-4.2.
I wanted to try tutorial: An Example Using the LLVM Tool Chain found in
http://llvm.org/docs/GettingStarted.html#environment
Here is what I did:
$ llvm-gcc -O3 hello.c -o hello.exe
This works fine. hello.exe is created and executes OK.
$ llvm-gcc -O3 -emit-llvm hello.c -c -o hello.bc
This command creates file hello.s. File hello.bc is not created.
I thought it is not important if the extension is not .bc
I renamed file hello.s into hello.bc.
Then I tried:
$ lli hello.bc
lli: error loading program 'hello.bc': Bitcode stream should be a multiple of 4
bytes in length
I don't see how to fix this issue?
Please can you help me?
Thanks,
Laurent

-- 
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 llvm.org  Sat Mar 27 06:09:59 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 27 Mar 2010 06:09:59 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6722] New: [ARM] Model VLD/VST latencies properly
Message-ID: <bug-6722-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=6722

           Summary: [ARM] Model VLD/VST latencies properly
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Common Code Generator Code
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: asl at math.spbu.ru
                CC: llvmbugs at cs.uiuc.edu


VLD / VST instructions have different latencies depending on amount of register
they write, how, etc. We need to model these latencies properly.

-- 
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 llvm.org  Sat Mar 27 06:56:23 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 27 Mar 2010 06:56:23 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6721] llvm-gcc -c -emit-llvm doesn't create .bc file
In-Reply-To: <bug-6721-206@http.llvm.org/bugs/>
References: <bug-6721-206@http.llvm.org/bugs/>
Message-ID: <20100327115624.1FE912A6C12C@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=6721

Anton Korobeynikov <asl at math.spbu.ru> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID

--- Comment #3 from Anton Korobeynikov <asl at math.spbu.ru> 2010-03-27 06:56:23 CDT ---
Ok, you haven't configured llvm-gcc properly. Please read README.LLVM file in
the llvm-gcc dir for more instructions (short answer: you forgot about
--enable-llvm argument to llvm-gcc configure)

-- 
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 llvm.org  Sat Mar 27 07:32:20 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 27 Mar 2010 07:32:20 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6723] New: Deduced/Explicit template arguments to
 parameter conversions madness
Message-ID: <bug-6723-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=6723

           Summary: Deduced/Explicit template arguments to parameter
                    conversions madness
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: schaub-johannes at web.de
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


I have done some tests how clang behaves for conversions and deduction failures
regarding explicit and deduced arguments:


struct S { };
void operator<<(S, unsigned char);
// uncomment this, and all works
// void operator<<(S, unsigned int);
void operator<<(S, long);

void g(unsigned char);
void g(long);

template<typename T>
void same_type_e(T, T);

template<unsigned char C>
void f(int(&)[C]) { // C deduced to 512 
  S() << C; // ambiguity
  S() << (unsigned char)0; // works

  g(C); // works

  same_type_e((unsigned char)0, C); // works
  typedef char x[C == 512 ? 1 : -1]; // works
}

template<unsigned char C>
void f1(int(*)[C]) { // C explicitly specified => converted to 0
  S() << C; // works
  S() << (unsigned char)0; // works

  g(C); // works

  same_type_e((unsigned char)0, C); // works
  typedef char x[C == 0 ? 1 : -1]; // works
}

int main() { 
  int x[512]; 
  f(x); 
  f1<512>(0);
}

Clang does not yield a deduction failure for f1<512>(0) - i'm not sure what the
Standard says. It depends on whether 14.9.2[temp.deduct]p2b2 when it says "The
speci?ed template argument values are substituted for the corresponding
template parameters as speci?ed below" whether it refers to the
template-argument expressions as specified, or to the converted arguments after
they gone through 14.4.2[temp.arg.nontype]p5. If it uses the converted
arguments, we will SFINAE fail, but if not, we won't sfinae fail. 

In any case, if we *don't* SFINAE fail, then the parameter type shold be
"int(*)[512]" but clang gives it the "type" int(*)[0] currently, it seems. That
doesn't seem to make sense. 

One other thing that needs correction is the type of "C" in some overload
contexts. While when C is deduced it has type "unsigned char" when in normal
function calls, it seems to have type "unsigned int" when in
overload-resolution-in-expressions contexts. 

The behavior of EDG is that in f, it compiles everything, so it gives "C" the
value 512, but the type unsigned int. For f1, it converts the explicitly
specified argument before substituting it into the function type of the
template and starting argument deduction with it. So it will SFINAE fail for
f1. If i call it with "f1<513>(0)" and change the typedef test to "C == 1",
comeau accepts the whole code. 

I find the Standard is quite mysteriously silent about the handling of these
situations, unfortunately. I haven't found anything that mandates converting
deduced arguments. But in any case, the currently different behavior regarding
overload resolution and the construction of the "int(*)[0]" type in clang needs
a change i suspect.

-- 
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 llvm.org  Sat Mar 27 11:09:48 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 27 Mar 2010 11:09:48 -0500 (CDT)
Subject: [LLVMbugs] [Bug 4911] Tcl detection should look for tcl.h, not tclsh
In-Reply-To: <bug-4911-206@http.llvm.org/bugs/>
References: <bug-4911-206@http.llvm.org/bugs/>
Message-ID: <20100327160948.C2E672A6C12C@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=4911

Michel Salim <salimma at fedoraproject.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #3 from Michel Salim <salimma at fedoraproject.org> 2010-03-27 11:09:48 CDT ---
Looks like 2.7-prerelease-1 finds tclsh in /usr/bin successfully

-- 
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 llvm.org  Sat Mar 27 15:32:39 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 27 Mar 2010 15:32:39 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6724] New: call to devirtualized thunk not being
	inlined
Message-ID: <bug-6724-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=6724

           Summary: call to devirtualized thunk not being inlined
           Product: new-bugs
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: andersca at mac.com
                CC: llvmbugs at cs.uiuc.edu


The original C++ code is:

struct A {
  virtual int f() { return 1; }
};

struct B {
  virtual int f() { return 2; }
};

struct C : A, B {
  virtual int f() { return 3; }
};

struct D : C {
  virtual int f() { return 4; }
};

static int f(D* d) {
  B* b = d;
  return b->f();
};

int g() {
  D d;

  return f(&d);
}

-- 
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 llvm.org  Sat Mar 27 20:20:55 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 27 Mar 2010 20:20:55 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6725] New: [2.7] Analysis/malloc.c fail
Message-ID: <bug-6725-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=6725

           Summary: [2.7] Analysis/malloc.c fail
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: nicholas at mxc.ca
                CC: llvmbugs at cs.uiuc.edu


FAIL: Clang :: Analysis/malloc.c (46 of 2103)
******************** TEST 'Clang :: Analysis/malloc.c' FAILED
********************
Script:
--
/home/nlewycky/llvm-2.7/pre1/release-asserts/llvm-2.7/Release-Asserts/bin/clang
-cc1 -analyze -analyzer-experimental-internal-checks -analyzer-check-objc-mem
-analyzer-experimental-checks -analyzer-store=region -verify
/home/nlewycky/llvm-2.7/pre1/release-asserts/llvm-2.7/tools/clang-2.7/test/Analysis/malloc.c
--
Exit Code: 139
Command Output (stdout):
--
--
Command Output (stderr):
--
[useless stack trace cut]
0.      Program arguments:
/home/nlewycky/llvm-2.7/pre1/release-asserts/llvm-2.7/Release-Asserts/bin/clang
-cc1 -analyze -analyzer-experimental-internal-checks -analyzer-check-objc-mem
-analyzer-experimental-checks -analyzer-store=region -verify
/home/nlewycky/llvm-2.7/pre1/release-asserts/llvm-2.7/tools/clang-2.7/test/Analysis/malloc.c 
1.     
/home/nlewycky/llvm-2.7/pre1/release-asserts/llvm-2.7/tools/clang-2.7/test/Analysis/malloc.c:17:1:
current parser token 'void'
Segmentation fault
--

-- 
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 llvm.org  Sat Mar 27 20:22:15 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 27 Mar 2010 20:22:15 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6726] New: [2.7] Analysis/retain-release.m fail in
 release-asserts
Message-ID: <bug-6726-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=6726

           Summary: [2.7] Analysis/retain-release.m fail in
                    release-asserts
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: nicholas at mxc.ca
                CC: llvmbugs at cs.uiuc.edu


FAIL: Clang :: Analysis/retain-release.m (83 of 2103)
******************** TEST 'Clang :: Analysis/retain-release.m' FAILED
**********
**********
Script:
--
/home/nlewycky/llvm-2.7/pre1/release-asserts/llvm-2.7/Release-Asserts/bin/clang 
-cc1 -triple x86_64-apple-darwin10 -analyze -analyzer-check-objc-mem
-analyzer-s
tore=basic -fblocks -verify
/home/nlewycky/llvm-2.7/pre1/release-asserts/llvm-2.
7/tools/clang-2.7/test/Analysis/retain-release.m
/home/nlewycky/llvm-2.7/pre1/release-asserts/llvm-2.7/Release-Asserts/bin/clang 
-cc1 -triple x86_64-apple-darwin10 -analyze -analyzer-check-objc-mem
-analyzer-s
tore=region -fblocks -verify
/home/nlewycky/llvm-2.7/pre1/release-asserts/llvm-2
.7/tools/clang-2.7/test/Analysis/retain-release.m
--
Exit Code: 139
Command Output (stdout):
--
--
Command Output (stderr):
--
[snip useless stack trace because it's a release-asserts build]
Stack dump:
0.      Program arguments:
/home/nlewycky/llvm-2.7/pre1/release-asserts/llvm-2.7/Release-Asserts/bin/clang
-cc1 -triple x86_64-apple-darwin10 -analyze -analyzer-check-objc-mem
-analyzer-store=basic -fblocks -verify
/home/nlewycky/llvm-2.7/pre1/release-asserts/llvm-2.7/tools/clang-2.7/test/Analysis/retain-release.m 
1.     
/home/nlewycky/llvm-2.7/pre1/release-asserts/llvm-2.7/tools/clang-2.7/test/Analysis/retain-release.m:426:1:
current parser token 'CFMutableArrayRef'
Segmentation fault

-- 
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 llvm.org  Sat Mar 27 21:50:54 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 27 Mar 2010 21:50:54 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6723] Deduced/Explicit template arguments to
 parameter conversions madness
In-Reply-To: <bug-6723-206@http.llvm.org/bugs/>
References: <bug-6723-206@http.llvm.org/bugs/>
Message-ID: <20100328025054.87DD72A6C12D@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=6723

Douglas Gregor <dgregor at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #2 from Douglas Gregor <dgregor at apple.com> 2010-03-27 21:50:54 CDT ---
(In reply to comment #1)
> I've got a typo there:
> 
> > The behavior of EDG is that in f, it compiles everything, so it gives "C" the
> value 512, but the type unsigned int.
> 
> Should say
> 
> > The behavior of EDG is that in f, it compiles everything, so it gives "C" the
> value 512, but the type unsigned char.
> 
> I figured it could cause confusion so i corrected :)

EDG seems to be behaving strangely here, as did Clang. IMO, these should be
deduction failures, since we should convert the deduced template argument to an
unsigned char (value of 0) and then produce a deduction failure when we try to
form the zero-length array.

Clang had two problems, both fixed in r99734: first, we weren't actually
checking the deduced template arguments against the template parameter, so we
weren't converting non-type template arguments appropriately. Second, we only
had a little extension warning (shown only with -pedantic) when forming a
zero-length array, not the hard error it needs to be for SFINAE to work.

-- 
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 llvm.org  Sun Mar 28 00:43:30 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 28 Mar 2010 00:43:30 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6331] Static Analyzer does not recognize that
 function calling exit does not return
In-Reply-To: <bug-6331-206@http.llvm.org/bugs/>
References: <bug-6331-206@http.llvm.org/bugs/>
Message-ID: <20100328054331.2D9D72A6C12D@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=6331

Ted Kremenek <kremenek at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |kremenek at apple.com
         Resolution|                            |DUPLICATE

--- Comment #2 from Ted Kremenek <kremenek at apple.com> 2010-03-28 00:43:30 CDT ---
The analyzer currently doesn't do any inter-procedural analysis.  You can mark
the function 'noreturn' and the analyzer will correctly handle this case. 
Automatically inferring that die() doesn't return is covered by PR 2764.

*** This bug has been marked as a duplicate of bug 2764 ***

-- 
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 llvm.org  Sun Mar 28 02:57:36 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 28 Mar 2010 02:57:36 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6727] New: LSR takes over 12 seconds on 583 line
	testcase
Message-ID: <bug-6727-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=6727

           Summary: LSR takes over 12 seconds on 583 line testcase
           Product: libraries
           Version: 1.0
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Scalar Optimizations
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: clattner at apple.com
                CC: llvmbugs at cs.uiuc.edu


test/CodeGen/PowerPC/tango.net.ftp.FtpClient.ll is taking forever to run, and
is all time in lsr.

This looks like Bug 4534 has either come back or is not fixed.  I'm disabling
the test until the compile time is improved.

-- 
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 llvm.org  Sun Mar 28 07:12:28 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 28 Mar 2010 07:12:28 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6728] New: stage2 of llvm-gcc-4.2 doesn't compile:
 __PTRDIFF_TYPE__ expanded as "int"
Message-ID: <bug-6728-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=6728

           Summary: stage2 of llvm-gcc-4.2 doesn't compile:
                    __PTRDIFF_TYPE__ expanded as "int"
           Product: tools
           Version: trunk
          Platform: PC
        OS/Version: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: llvm-gcc
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: vlacomp at orange.fr
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=4598)
 --> (http://llvm.org/bugs/attachment.cgi?id=4598)
file in <where-gcc-is-build>/gcc/include created in stage2

Hi,
I configured llvm-gcc-4.2 with:
Configured with: ../llvm-gcc-4.2/configure
--prefix=/cygdrive/J/Profiles/r29173/projects/people/llvm/gcc-build/../install
--program-prefix=llvm-
--enable-llvm=/cygdrive/J/Profiles/r29173/projects/people/llvm/build
--enable-languages=c,c++ 
I have an issue during compilation of package 'llvm-gcc-4.2'.
The issue occurs at stage2 in the compilation process.
I looked into the code and found that some builtin macros are not expanded
correctly.
For instance if I run:
./xgcc.exe -B. -I../../llvm-gcc-4.2/gcc/../include -E
../../llvm-gcc-4.2/gcc/tsystem.h > E
In file E I get the following expansions:
  # 152 "./include/stddef.h" 3 4
  typedef "int" ptrdiff_t;
  # 214 "./include/stddef.h" 3 4
  typedef "unsigned int" size_t;
  # 326 "./include/stddef.h" 3 4
  typedef "short unsigned int" wchar_t;
I think (see line 152) "int" should be int, and so on.
Line 152 in file stddef.h is: typedef __PTRDIFF_TYPE__ ptrdiff_t;
Seems that macro __PTRDIFF_TYPE__ is not preprocessed correctly.
I feel that the -B. option is causing the problem.
Any idea?
Thanks,
Laurent

-- 
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 llvm.org  Sun Mar 28 11:29:44 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 28 Mar 2010 11:29:44 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6730] New: clang generates invalid asm
Message-ID: <bug-6730-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=6730

           Summary: clang generates invalid asm
           Product: new-bugs
           Version: unspecified
          Platform: Other
        OS/Version: FreeBSD
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: hinokind at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=4599)
 --> (http://llvm.org/bugs/attachment.cgi?id=4599)
testcase

clang sdl-clang.i 
/tmp/cc-70NrR0.s: Assembler messages:
/tmp/cc-70NrR0.s:1259: Error: suffix or operands invalid for `movq'
/tmp/cc-70NrR0.s:2006: Error: suffix or operands invalid for `movq'
/tmp/cc-70NrR0.s:2965: Error: suffix or operands invalid for `movq'
/tmp/cc-70NrR0.s:3363: Error: suffix or operands invalid for `movq'
/tmp/cc-70NrR0.s:5221: Error: suffix or operands invalid for `movq'
/tmp/cc-70NrR0.s:6163: Error: suffix or operands invalid for `movq'
/tmp/cc-70NrR0.s:7382: Error: suffix or operands invalid for `movq'
/tmp/cc-70NrR0.s:7910: Error: suffix or operands invalid for `movq'
clang: error: assembler command failed with exit code 1 (use -v to see
invocation)

$ clang --version
clang version 1.5 (trunk 99763)
Target: x86_64-unknown-freebsd8.0
Thread model: posix

-- 
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 llvm.org  Sun Mar 28 15:43:49 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 28 Mar 2010 15:43:49 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6731] New: alpha: ICE at
 llvm-gcc4.2-2.6.source/gcc/libgcov.c:848
Message-ID: <bug-6731-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=6731

           Summary: alpha: ICE at llvm-gcc4.2-2.6.source/gcc/libgcov.c:848
           Product: libraries
           Version: 2.6
          Platform: DEC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: Alpha
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: mattst88 at gmail.com
                CC: llvmbugs at cs.uiuc.edu


This is 2.6 with patches r95422, r96300, r97660 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 llvm.org  Sun Mar 28 18:58:05 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 28 Mar 2010 18:58:05 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6732] New: virtual inheritance generates undefined
 symbol in baseclass ctor
Message-ID: <bug-6732-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=6732

           Summary: virtual inheritance generates undefined symbol in
                    baseclass ctor
           Product: clang
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: alexmac at adobe.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


Created an attachment (id=4602)
 --> (http://llvm.org/bugs/attachment.cgi?id=4602)
testcase

The attached testcase generates the following error when compiled with clang
(it works with g++):

Undefined symbols:
  "__ZN9baseclass21somepurevirtualmethodEv", referenced from:
      __ZTC7derived0_9baseclass in cc-72AecD.o

The bug seems to be triggered by the use of virtual inheritance, but I'm not
familiar enough with clang to suggest anything more useful than that. This is a
cutdown testcase from a problem I'm having trying to compile the Tamarin VM
(specifically the DataIO class and its derivatives:
http://hg.mozilla.org/tamarin-redux/file/76c2c53af37e/shell/DataIO.h)

-- 
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 llvm.org  Sun Mar 28 20:15:44 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 28 Mar 2010 20:15:44 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6733] New: template class with default arg assigned
 from enum causes assert
Message-ID: <bug-6733-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=6733

           Summary: template class with default arg assigned from enum
                    causes assert
           Product: clang
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: alexmac at adobe.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


The following code compiles with g++ but causes an assert when compiled with
clang:

#include <iostream>
template <class T>
class bar {
public: enum { kSomeConst = 128 };
    bar(int32_t x = kSomeConst) {}
};
int main() {
    bar<int> tmp;
}

Assertion failed:
(getContext().getCanonicalType(ArgType.getNonReferenceType()). getTypePtr() ==
getContext().getCanonicalType(Arg->getType()).getTypePtr() && "type mismatch in
call argument!"), function EmitCallArgs, file
/p4/llvm-trunk/tools/clang/lib/CodeGen/CodeGenFunction.h, line 1327.
0  clang             0x0000000100ec8372 PrintStackTrace(void*) + 34
1  clang             0x0000000100ec8b5e SignalHandler(int) + 622
2  libSystem.B.dylib 0x00007fff8649feaa _sigtramp + 26
3  libSystem.B.dylib 0x00007fff5fbfa610 _sigtramp + 3648366464
4  libSystem.B.dylib 0x00007fff8651be74 __pthread_markcancel + 0
5  clang             0x00000001001977d0 void
clang::CodeGen::CodeGenFunction::EmitCallArgs<clang::FunctionProtoType>(llvm::SmallVector<std::pair<clang::CodeGen::RValue,
clang::QualType>, 16u>&, clang::FunctionProtoType const*,
clang::ConstExprIterator, clang::ConstExprIterator) + 1008
6  clang             0x000000010019f811
clang::CodeGen::CodeGenFunction::EmitCXXMemberCall(clang::CXXMethodDecl const*,
llvm::Value*, clang::CodeGen::ReturnValueSlot, llvm::Value*, llvm::Value*,
clang::ConstExprIterator, clang::ConstExprIterator) + 369
7  clang             0x0000000100163348
clang::CodeGen::CodeGenFunction::EmitCXXConstructorCall(clang::CXXConstructorDecl
const*, clang::CXXCtorType, llvm::Value*, clang::ConstExprIterator,
clang::ConstExprIterator) + 376
8  clang             0x000000010019d0b7
clang::CodeGen::CodeGenFunction::EmitCXXConstructExpr(llvm::Value*,
clang::CXXConstructExpr const*) + 647
9  clang             0x00000001001983b2 (anonymous
namespace)::AggExprEmitter::VisitCXXConstructExpr(clang::CXXConstructExpr
const*) + 226
10 clang             0x000000010019ae74 clang::StmtVisitor<(anonymous
namespace)::AggExprEmitter, void>::Visit(clang::Stmt*) + 2660
11 clang             0x000000010019b92b
clang::CodeGen::CodeGenFunction::EmitAggExpr(clang::Expr const*, llvm::Value*,
bool, bool, bool, bool) + 139
12 clang             0x000000010017fbcd
clang::CodeGen::CodeGenFunction::EmitLocalBlockVarDecl(clang::VarDecl const&) +
10525
13 clang             0x0000000100180721
clang::CodeGen::CodeGenFunction::EmitDecl(clang::Decl const&) + 497
14 clang             0x0000000100208dfb
clang::CodeGen::CodeGenFunction::EmitDeclStmt(clang::DeclStmt const&) + 171
15 clang             0x000000010020f9eb
clang::CodeGen::CodeGenFunction::EmitSimpleStmt(clang::Stmt const*) + 171
16 clang             0x000000010020cad0
clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*) + 48
17 clang             0x000000010020f6fb
clang::CodeGen::CodeGenFunction::EmitCompoundStmt(clang::CompoundStmt const&,
bool, llvm::Value*, bool) + 267
18 clang             0x000000010020fa27
clang::CodeGen::CodeGenFunction::EmitSimpleStmt(clang::Stmt const*) + 231
19 clang             0x000000010020cad0
clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*) + 48
20 clang             0x000000010023f66d
clang::CodeGen::CodeGenFunction::GenerateCode(clang::CodeGen::GlobalDecl,
llvm::Function*) + 1565
21 clang             0x0000000100247fef
clang::CodeGen::CodeGenModule::EmitGlobalFunctionDefinition(clang::CodeGen::GlobalDecl)
+ 687
22 clang             0x000000010024948b
clang::CodeGen::CodeGenModule::EmitGlobalDefinition(clang::CodeGen::GlobalDecl)
+ 347
23 clang             0x00000001002496d9
clang::CodeGen::CodeGenModule::EmitGlobal(clang::CodeGen::GlobalDecl) + 457
24 clang             0x0000000100249bc2
clang::CodeGen::CodeGenModule::EmitTopLevelDecl(clang::Decl*) + 674
25 clang             0x000000010025b9ac (anonymous
namespace)::CodeGeneratorImpl::HandleTopLevelDecl(clang::DeclGroupRef) + 60
26 clang             0x000000010003a56e (anonymous
namespace)::BackendConsumer::HandleTopLevelDecl(clang::DeclGroupRef) + 158
27 clang             0x000000010026c542 clang::ParseAST(clang::Preprocessor&,
clang::ASTConsumer*, clang::ASTContext&, bool, bool,
clang::CodeCompleteConsumer*) + 274
28 clang             0x000000010003e579
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 377
29 clang             0x0000000100022fb9 cc1_main(char const**, char const**,
char const*, void*) + 2249
30 clang             0x0000000100025cf2 main + 2322
31 clang             0x0000000100020a88 start + 52
32 clang             0x000000000000001d start + 4294833609
Stack dump:
0.    Program arguments: /p4/llvm-trunk-build/Release/bin/clang -cc1 -triple
x86_64-apple-darwin10.0.0 -S -disable-free -main-file-name avmplusList.cpp
-pic-level 1 -mdisable-fp-elim -munwind-tables -target-cpu core2 -resource-dir
/p4/llvm-trunk-build/Release/lib/clang/1.5 -fmessage-length 217
-stack-protector 1 -fblocks -fexceptions -fdiagnostics-show-option
-fcolor-diagnostics -o
/var/folders/ny/nyOMoi2iGUayncIufU3gZU+++TI/-Tmp-/cc-xbhbBV.s -x c++
avmplusList.cpp 
1.    <eof> parser at end of file
2.    avmplusList.cpp:7:5: LLVM IR generation of declaration 'main'
3.    avmplusList.cpp:7:5: Generating code for declaration 'main'
4.    avmplusList.cpp:7:12: LLVM IR generation of compound statement ('{}')
clang: error: compiler command failed due to signal 6 (use -v to see
invocation)

-- 
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 llvm.org  Sun Mar 28 22:31:04 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 28 Mar 2010 22:31:04 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6000] VTT wrong
In-Reply-To: <bug-6000-206@http.llvm.org/bugs/>
References: <bug-6000-206@http.llvm.org/bugs/>
Message-ID: <20100329033104.25D872A6C12D@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=6000

Anders Carlsson <andersca at mac.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |andersca at mac.com
         Resolution|                            |FIXED

--- Comment #2 from Anders Carlsson <andersca at mac.com> 2010-03-28 22:31:03 CDT ---
This bug no longer occurs in ToT.

-- 
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 llvm.org  Mon Mar 29 02:48:57 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 29 Mar 2010 02:48:57 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6734] New: clang 2.7: shows impossible execution
	path
Message-ID: <bug-6734-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=6734

           Summary: clang 2.7: shows impossible execution path
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Static Analyzer
        AssignedTo: kremenek at apple.com
        ReportedBy: edwintorok at gmail.com
                CC: llvmbugs at cs.uiuc.edu


See https://wwws.clamav.net/bugzilla/show_bug.cgi?id=1910

clang looks at this code:
line 175: 
if (!pehdr && dend>0xf8+0x28) {
    cli_dbgmsg("UPX: no luck - scanning for PE\n");
    pehdr = &dst[dend-0xf8-0x28];
    while (pehdr>dst) {
      if ((sections=checkpe(dst, *dsize, pehdr, &valign, &sectcnt)))
    break;
      pehdr--;
    }
line 183:    if (!(realstuffsz = pehdr-dst)) pehdr=NULL;
  }

And it concludes that you can exit the while loop (Loop condition is false
execution continues on line 183), and at line 183 you take the false branch.

But that can't happen.

dend > 0xf8+0x28 => pehdr > dst to begin with.
Then you loop once through the while (pehdr > dst) {... pehdr--;} loop, and
break out because the loop condition is false => pehdr == dst.
Now pehdr - dst = 0 => !(realstuffsz = pehdr-dst) => true => you can only take
the true branch (if you've broken out of the loop because loop condition 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 llvm.org  Mon Mar 29 02:54:58 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 29 Mar 2010 02:54:58 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6735] New: Cannot split an edge from an
 IndirectBrInst failed (llvm with clang compiling gambit-c)
Message-ID: <bug-6735-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=6735

           Summary: Cannot split an edge from an IndirectBrInst failed
                    (llvm with clang compiling gambit-c)
           Product: new-bugs
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Keywords: compile-fail
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: prhlava at gmail.com
                CC: llvmbugs at cs.uiuc.edu


When compiling gambit-c version 4.6.0 (scheme to C compiler),

http://www.iro.umontreal.ca/~gambit/download/gambit/v4.6/source/gambc-v4_6_0-devel.tgz

(the "devel" above means - it is sources, not a development version)

with llvm and clang, it fails with the following:

making all in gsc
make[1]: Entering directory `/data/vladimir/tmp/gambc-v4_6_0-devel/gsc'
/home/vladimir/opt/llvm/svn/bin/clang -Wno-unused -O1 -fno-math-errno
-fschedule-insns2 -fno-trapping-math -fno-strict-aliasing -fwrapv
-fomit-frame-pointer -fPIC -fno-common -mieee -mieee-with-inexact -mieee-fp  
-I"../include" -c -o "_t-c-2.o" -I. -DHAVE_CONFIG_H _t-c-2.c -D___LIBRARY
clang:
/data/vladimir/tmp/llvm.svn/lib/Transforms/Utils/BasicBlockUtils.cpp:400:
llvm::BasicBlock* llvm::SplitBlockPredecessors(llvm::BasicBlock*,
llvm::BasicBlock* const*, unsigned int, const char*, llvm::Pass*): Assertion
`!isa<IndirectBrInst>(Preds[i]->getTerminator()) && "Cannot split an edge from
an IndirectBrInst"' failed.
0  clang           0x00000000014518da
1  clang           0x00000000014517c1
2  libpthread.so.0 0x00002b41b147def0
3  libc.so.6       0x00002b41b206efd5 gsignal + 53
4  libc.so.6       0x00002b41b20703f0 abort + 384
5  libc.so.6       0x00002b41b2068081 __assert_fail + 241
6  clang           0x000000000120425d
7  clang           0x0000000001137dd6
8  clang           0x0000000001137074
9  clang           0x0000000001134eed
10 clang           0x00000000013b8f95
11 clang           0x000000000124d7c1
12 clang           0x000000000124e4f3
13 clang           0x00000000013b94e1
14 clang           0x00000000013b9a33
15 clang           0x00000000013b9d3b
16 clang           0x000000000041b1d1
17 clang           0x000000000041a0ab
18 clang           0x0000000000692a4b
19 clang           0x0000000000435cd6
20 clang           0x0000000000435940
21 clang           0x000000000041fb0d
22 clang           0x0000000000408d23
23 clang           0x000000000040d9b6 main + 244
24 libc.so.6       0x00002b41b205bb6d __libc_start_main + 253
25 clang           0x0000000000407849
Stack dump:
0.      Program arguments: /home/vladimir/opt/llvm/svn/bin/clang -cc1 -triple
x86_64-unknown-linux-gnu -S -disable-free -main-file-name _t-c-2.c -pic-level 2
-mconstructor-aliases -munwind-tables -target-cpu x86-64 -resource-dir
/home/vladimir/opt/llvm/svn/lib/clang/1.5 -DHAVE_CONFIG_H -D___LIBRARY
-I../include -I. -O1 -Wno-unused -fmessage-length 80 -fgnu-runtime -fno-common
-fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-g6p8M6.s -x c _t-c-2.c 
1.      <eof> parser at end of file
2.      Per-module optimization passes
3.      Running pass 'CallGraph Pass Manager' on module '_t-c-2.c'.
4.      Running pass 'Jump Threading' on function
'@___H_c_23_targ_2d_setup_2d_simplifiers'
clang: error: compiler command failed due to signal 6 (use -v to see
invocation)
make[1]: *** [_t-c-2.o] Error 250
make[1]: Leaving directory `/data/vladimir/tmp/gambc-v4_6_0-devel/gsc'
make: *** [all-recursive] Error 1

The gambit-c was configured with: CC=/path/to/llvm ./configure
--prefix=/path/to/result

(no other options were set)

The platform is 64 bit ArchLinux: 

Linux tron 2.6.32-1kHz #1 SMP PREEMPT Thu Mar 18 19:52:28 GMT 2010 x86_64 AMD
Phenom(tm) II X4 810 Processor AuthenticAMD GNU/Linux

The gcc used to compile llvm (and clang):

gcc (GCC) 4.4.3 20100316 (prerelease)
Copyright (C) 2010 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.

-- 
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 llvm.org  Mon Mar 29 09:24:38 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 29 Mar 2010 09:24:38 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6736] New: missing error detection in support for
 variable alias attribute
Message-ID: <bug-6736-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=6736

           Summary: missing error detection in support for variable alias
                    attribute
           Product: clang
           Version: 2.6
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: hkultala at cs.tut.fi
                CC: llvmbugs at cs.uiuc.edu


There is and attribute to specify variable to be alias of another variable

__attribute__ ((alias ("variable2"))); 

This makes this variable alias to location variable2

It seems that the correctness of the symbol where the alias is created is not
checked in clang:

__attribute__ ((alias ("variable2 + 2"))); 

should cause a compiler error, but it passes, and creates a bogus reference to
a variable named "variable2 + 2". 


At least newlib seems to use this broken syntax(because gcc can actually do the
calculation), which then goes thru configure check(because the error is not
detected when compiling) but fails on actual linking, which causes newlib to
not work when compiled with clang.

-- 
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 llvm.org  Mon Mar 29 11:33:12 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 29 Mar 2010 11:33:12 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6737] New: reference to a thunk generated while g++
 generates none
Message-ID: <bug-6737-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=6737

           Summary: reference to a thunk generated while g++ generates
                    none
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: FreeBSD
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: rdivacky at freebsd.org
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


pes delta$ cat compatibility.cc                                                
                                                                           
namespace std __attribute__ ((__visibility__ ("default"))) {
        template<class _CharT>     struct char_traits;
       }
      typedef long __int64_t;
      typedef __int64_t __ptrdiff_t;
     typedef __ptrdiff_t ptrdiff_t;
      namespace std __attribute__ ((__visibility__ ("default"))) {
            typedef ptrdiff_t streamsize;
        template<typename _CharT, typename _Traits = char_traits<_CharT> >    
class basic_ostream;
        template<typename _CharT, typename _Traits = char_traits<_CharT> >    
class basic_fstreamXX;
         template<typename, typename>     struct __are_same     {
        };
      }
        namespace std __attribute__ ((__visibility__ ("default"))) {
            enum _Ios_Fmtflags     {
          _S_beg = 0,       _S_cur = 1,       _S_end = 2,      
_S_ios_seekdir_end = 1L << 16     };
      class ios_base   {
          virtual ~ios_base();
        };
       }
     namespace std __attribute__ ((__visibility__ ("default"))) {
        template<typename _CharT, typename _Traits>     class basic_ios :
public ios_base     {
           protected:       basic_ostream<_CharT, _Traits>* _M_tie;
        };
      template<typename _CharT, typename _Traits>     class basic_istream :
virtual public basic_ios<_CharT, _Traits>     {
         protected:              streamsize _M_gcount;
        };
        template<typename _CharT, typename _Traits>     class basic_iostream   
 : public basic_istream<_CharT, _Traits>,       public basic_ostream<_CharT,
_Traits>     {
        };
        template<typename _CharT, typename _Traits>     class basic_ostream :
virtual public basic_ios<_CharT, _Traits>     {
        };
        template<typename _CharT, typename _Traits>     class basic_fstreamXX :
public basic_iostream<_CharT, _Traits>     {
             bool       is_open() const       {
   }
        };
        template     bool     basic_fstreamXX<char>::is_open() const;
       }
pes delta$ clang++ -c compatibility.cc && nm compatibility.o | grep Thn
0000000000000000 W _ZThn16_NSdD0Ev
0000000000000000 W _ZThn16_NSdD1Ev
0000000000000000 W _ZThn16_NSt15basic_fstreamXXIcSt11char_traitsIcEED0Ev
0000000000000000 W _ZThn16_NSt15basic_fstreamXXIcSt11char_traitsIcEED1Ev
pes delta$ g++ -c compatibility.cc && nm compatibility.o | grep Thn
pes delta$

-- 
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 llvm.org  Mon Mar 29 11:41:59 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 29 Mar 2010 11:41:59 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6176] clang generates wrong code for load from
 bitfield in packed struct
In-Reply-To: <bug-6176-206@http.llvm.org/bugs/>
References: <bug-6176-206@http.llvm.org/bugs/>
Message-ID: <20100329164159.506F22A6C12D@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=6176

Daniel Dunbar <daniel at zuster.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |DUPLICATE

--- Comment #2 from Daniel Dunbar <daniel at zuster.org> 2010-03-29 11:41:59 CDT ---


*** This bug has been marked as a duplicate of bug 5591 ***

-- 
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 llvm.org  Mon Mar 29 12:32:42 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 29 Mar 2010 12:32:42 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6738] New: clang++ emits U symbols while g++ emits
	none
Message-ID: <bug-6738-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=6738

           Summary: clang++ emits U symbols while g++ emits none
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: FreeBSD
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: rdivacky at freebsd.org
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


pes delta$ clang++ -c compatibility.cc && nm compatibility.o | grep U
                 U _ZNSt15basic_fstreamXXIcSt11char_traitsIcEED0Ev
                 U _ZNSt15basic_fstreamXXIcSt11char_traitsIcEED1Ev
                 U _ZTVN10__cxxabiv117__class_type_infoE
                 U _ZTVN10__cxxabiv120__si_class_type_infoE
                 U _ZTVN10__cxxabiv121__vmi_class_type_infoE
                 U _ZdlPv
pes delta$ g++ -c compatibility.cc && nm compatibility.o
0000000000000000 W _ZNKSt15basic_fstreamXXIcSt11char_traitsIcEE7is_openEv
                 U __gxx_personality_v0

-- 
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 llvm.org  Mon Mar 29 13:18:47 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 29 Mar 2010 13:18:47 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6730] clang generates invalid asm
In-Reply-To: <bug-6730-206@http.llvm.org/bugs/>
References: <bug-6730-206@http.llvm.org/bugs/>
Message-ID: <20100329181847.4BEF72A6C12D@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=6730

Chris Lattner <clattner at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID

--- Comment #3 from Chris Lattner <clattner at apple.com> 2010-03-29 13:18:46 CDT ---
Yes, this is invalid constrains on the inline assembly.  In RLEClipBlit, we
have this asm:

...
__asm__         __volatile__("pand" " %" "mm5" ", %" "mm3");
__asm__         __volatile__("por" " %" "mm6" ", %" "mm3");
__asm__         __volatile__("movq" " %%" "mm3" ", %0":"=X"(*dstp):);



This is generating code like this:

    ## InlineAsm Start
    pand %mm5, %mm3
    ## InlineAsm End
    ## InlineAsm Start
    por %mm6, %mm3
    ## InlineAsm End
    movq    -256(%rbp), %rax
    ## InlineAsm Start
    movq %mm3, %cx
    ## InlineAsm End
    movw    %cx, (%rax)

This is perfectly valid code to generate for the X constraint, which says that
anything is allowed.  Change this to =m for this to work.

-- 
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 llvm.org  Mon Mar 29 13:49:32 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 29 Mar 2010 13:49:32 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6691] glibc and newlib need wint_t defined in
	stddef.h
In-Reply-To: <bug-6691-206@http.llvm.org/bugs/>
References: <bug-6691-206@http.llvm.org/bugs/>
Message-ID: <20100329184932.2F0F32A6C124@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=6691

Chris Lattner <clattner at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID

--- Comment #2 from Chris Lattner <clattner at apple.com> 2010-03-29 13:49:31 CDT ---
Is this a clang bug?  IT sounds like a glibc or newlib bug.  wchar.h is
supposed to define win_t, not stddef.h.

-- 
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 llvm.org  Mon Mar 29 14:42:05 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 29 Mar 2010 14:42:05 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6732] virtual inheritance generates undefined
 symbol in baseclass ctor
In-Reply-To: <bug-6732-206@http.llvm.org/bugs/>
References: <bug-6732-206@http.llvm.org/bugs/>
Message-ID: <20100329194205.EED982A6C124@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=6732

Anders Carlsson <andersca at mac.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |andersca at mac.com
         Resolution|                            |FIXED

--- Comment #1 from Anders Carlsson <andersca at mac.com> 2010-03-29 14:42:05 CDT ---
Fixed by r99807.

-- 
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 llvm.org  Mon Mar 29 14:49:34 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 29 Mar 2010 14:49:34 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6251] inline-optimized program crashes inside
	libstdc++
In-Reply-To: <bug-6251-206@http.llvm.org/bugs/>
References: <bug-6251-206@http.llvm.org/bugs/>
Message-ID: <20100329194934.C81E52A6C12F@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=6251

Anders Carlsson <andersca at mac.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #35 from Anders Carlsson <andersca at mac.com> 2010-03-29 14:49:33 CDT ---
Turns out this wasn't a vtable bug at all.

Committed revision 99829.

-- 
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 llvm.org  Mon Mar 29 16:27:45 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 29 Mar 2010 16:27:45 -0500 (CDT)
Subject: [LLVMbugs] [Bug 4975] ARM SDISel:: LowerArguments assert
In-Reply-To: <bug-4975-206@http.llvm.org/bugs/>
References: <bug-4975-206@http.llvm.org/bugs/>
Message-ID: <20100329212745.973872A6C12D@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=4975

Evan Cheng <evan.cheng at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #5 from Evan Cheng <evan.cheng at apple.com> 2010-03-29 16:27:44 CDT ---
Fixed: 99840.

-- 
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 llvm.org  Mon Mar 29 19:05:36 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 29 Mar 2010 19:05:36 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6739] New: If/else scoping problem
Message-ID: <bug-6739-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=6739

           Summary: If/else scoping problem
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: dgregor at apple.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


On this code:

void SSEDomainFixPass::Force(int rx, unsigned domain) {
  hasLiveRegs = true;
  if (DomainValue *dv = LiveRegs[rx]) {
    if (dv->collapsed())
      dv->add(domain);
    else
      Collapse(dv, domain);
  } else {
    // Set up basic collapsed DomainValue
    DomainValue *dv = Pool.Alloc();
    dv->add(domain);
    SetLiveReg(rx, dv);
  }
}

We complain about "dv" being redeclared (which it isn't), then go on to
complain that "dv" is NULL in this context.

-- 
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 llvm.org  Mon Mar 29 21:19:02 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 29 Mar 2010 21:19:02 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6169] vcall offset applied to the wrong pointer
In-Reply-To: <bug-6169-206@http.llvm.org/bugs/>
References: <bug-6169-206@http.llvm.org/bugs/>
Message-ID: <20100330021902.959492A6C124@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=6169

Anders Carlsson <andersca at mac.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |andersca at mac.com
         Resolution|                            |FIXED

--- Comment #1 from Anders Carlsson <andersca at mac.com> 2010-03-29 21:19:02 CDT ---
This bug was fixed when we switched over the thunks code to use the new vtable
layout code.

(In reply to comment #0)
> I have another question. The vtable of B has a part of A: ..., -32, null, -16,
> RTTI, f0, ...
> 
> -32 is the vcall offset of f1. -16 is the offset-to-top of A subobject. What is
> the 'null' standing for?

This is another bug that's been fixed in the new vtable layout code.

-- 
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 llvm.org  Mon Mar 29 21:22:31 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 29 Mar 2010 21:22:31 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6002] vtable wrong
In-Reply-To: <bug-6002-206@http.llvm.org/bugs/>
References: <bug-6002-206@http.llvm.org/bugs/>
Message-ID: <20100330022231.DE47A2A6C124@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=6002

Anders Carlsson <andersca at mac.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |andersca at mac.com
         Resolution|                            |FIXED

--- Comment #2 from Anders Carlsson <andersca at mac.com> 2010-03-29 21:22:31 CDT ---
Fixed in the new vtable layout code.

http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20100329/028860.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 llvm.org  Mon Mar 29 21:22:40 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 29 Mar 2010 21:22:40 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6005] [codegen] wrong covariant returns
In-Reply-To: <bug-6005-206@http.llvm.org/bugs/>
References: <bug-6005-206@http.llvm.org/bugs/>
Message-ID: <20100330022240.059EA2A6C12D@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=6005

Anders Carlsson <andersca at mac.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |andersca at mac.com
         Resolution|                            |FIXED

--- Comment #3 from Anders Carlsson <andersca at mac.com> 2010-03-29 21:22:39 CDT ---
Fixed in the new vtable layout code.

http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20100329/028860.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 llvm.org  Mon Mar 29 21:41:50 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 29 Mar 2010 21:41:50 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6740] New: ast-print-xml: clang:
 DocumentXML.cpp:51: clang::DocumentXML& clang::DocumentXML::toParent():
 Assertion `NodeStack.size() > 1 && "too much backtracking"' failed
Message-ID: <bug-6740-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=6740

           Summary: ast-print-xml: clang: DocumentXML.cpp:51:
                    clang::DocumentXML& clang::DocumentXML::toParent():
                    Assertion `NodeStack.size() > 1 && "too much
                    backtracking"' failed
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: tom.prince at ualberta.net
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


In DocumentXML::finalize, during the loop over BasicTypes, some types (it
appears that these are all duplicates) fail to print, and so the toParent()
prematurely closes the <Types> and potentially the <ReferenceSection> tags, and
so causes an assert in the final toParents.

To reproduce: (with 2.7-pre1)
clang -cc1 -ast-print-xml tools/clang/test/Coverage/ast-printing.cpp

-- 
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 llvm.org  Mon Mar 29 21:57:59 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 29 Mar 2010 21:57:59 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6628] Assertion failed: Calling a function with bad
	signature!
In-Reply-To: <bug-6628-206@http.llvm.org/bugs/>
References: <bug-6628-206@http.llvm.org/bugs/>
Message-ID: <20100330025759.825D02A6C124@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=6628

Anders Carlsson <andersca at mac.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |andersca at mac.com
         Resolution|                            |FIXED

--- Comment #1 from Anders Carlsson <andersca at mac.com> 2010-03-29 21:57:58 CDT ---
Committed revision 99864.

-- 
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 llvm.org  Mon Mar 29 23:32:02 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 29 Mar 2010 23:32:02 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6741] New: Can't have multiple anonymous unions
 which redeclare members
Message-ID: <bug-6741-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=6741

           Summary: Can't have multiple anonymous unions which redeclare
                    members
           Product: clang
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: alexmac at adobe.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


Created an attachment (id=4610)
 --> (http://llvm.org/bugs/attachment.cgi?id=4610)
testcase

Perhaps this is a violation of the spec and clang is right to disallow it,
however it does crop up in "real world" code so it *might* be better for this
to be a warning rather than an error. Here is a small example of what I'm
talking about

p.s. As it happens the one use of this in the AVM code base is entirely
frivolous and can easily be removed, but perhaps it affects other codebases...

void foo() {
    union {
        char *m_a;
        int *m_b;
    };
    // some code

    if(somecondition) {
        union {
            char *m_a;
            int *m_b;
        };
        // some code
    }
}

Currently clang gives you the following error:

union-bug.cpp:11:10: error: member of anonymous union redeclares 'm_a'
                        char *m_a;
                              ^
union-bug.cpp:5:9: note: previous declaration is here
                char *m_a;

-- 
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 llvm.org  Tue Mar 30 00:43:18 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 30 Mar 2010 00:43:18 -0500 (CDT)
Subject: [LLVMbugs] [Bug 3902] clang -ftime-report assertion failure on exit
In-Reply-To: <bug-3902-206@http.llvm.org/bugs/>
References: <bug-3902-206@http.llvm.org/bugs/>
Message-ID: <20100330054318.A83D62A6C12D@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=3902

Chris Lattner <clattner at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #1 from Chris Lattner <clattner at apple.com> 2010-03-30 00:43:17 CDT ---
This is fixed, that assertion no longer exists on 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 llvm.org  Tue Mar 30 01:06:55 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 30 Mar 2010 01:06:55 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6740] [2.7] ast-print-xml: clang:
 DocumentXML.cpp:51: clang::DocumentXML& clang::DocumentXML::toParent():
 Assertion `NodeStack.size() > 1 && "too much backtracking"' failed
In-Reply-To: <bug-6740-206@http.llvm.org/bugs/>
References: <bug-6740-206@http.llvm.org/bugs/>
Message-ID: <20100330060655.5FB042A6C12F@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=6740

Chris Lattner <clattner at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |DUPLICATE

--- Comment #1 from Chris Lattner <clattner at apple.com> 2010-03-30 01:06:55 CDT ---


*** This bug has been marked as a duplicate of bug 5006 ***

-- 
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 llvm.org  Tue Mar 30 08:14:53 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 30 Mar 2010 08:14:53 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6742] New: Clang cannot execute on NetBSD
Message-ID: <bug-6742-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=6742

           Summary: Clang cannot execute on NetBSD
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: NetBSD
            Status: NEW
          Severity: normal
          Priority: P
         Component: Driver
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: neil at daikokuya.co.uk
                CC: llvmbugs at cs.uiuc.edu


$ ./clang
execname not specified in AUX vector: Undefined error: 0

I suspect clang's realpath hackery is still broken; previously it wasn't
executable through a symlink; now it's not executable at all!

On further playing, it seems to only work when executed via shell PATH lookup.

-- 
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 llvm.org  Tue Mar 30 09:31:28 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 30 Mar 2010 09:31:28 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6743] New: jump threading segfault
Message-ID: <bug-6743-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=6743

           Summary: jump threading segfault
           Product: new-bugs
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: regehr at cs.utah.edu
                CC: llvmbugs at cs.uiuc.edu


See below a testcase that crashes clang r99887 on Ubuntu 9.10 on x86.

regehr at john-home:~/volatile/bugs/tmp295$ valgrind -q --trace-children=yes clang
-O1 small.c
==17885== Invalid read of size 1
==17885==    at 0x8D14D09: ??? (in
/home/regehr/z/compiler-install/llvm-gcc-r99887-install/bin/clang)
==17885==  Address 0x43bd0ec is 4 bytes inside a block of size 44 free'd
==17885==    at 0x402454D: operator delete(void*) (vg_replace_malloc.c:346)
==17885==    by 0x8E974CA: ??? (in
/home/regehr/z/compiler-install/llvm-gcc-r99887-install/bin/clang)
==17885== 
==17885== Invalid read of size 4
==17885==    at 0x8D14D19: ??? (in
/home/regehr/z/compiler-install/llvm-gcc-r99887-install/bin/clang)
==17885==  Address 0x43bd0f4 is 12 bytes inside a block of size 44 free'd
==17885==    at 0x402454D: operator delete(void*) (vg_replace_malloc.c:346)
==17885==    by 0x8E974CA: ??? (in
/home/regehr/z/compiler-install/llvm-gcc-r99887-install/bin/clang)
==17885== 
==17885== Invalid read of size 4
==17885==    at 0x8D14B5A: ??? (in
/home/regehr/z/compiler-install/llvm-gcc-r99887-install/bin/clang)
==17885==  Address 0x43bd0f4 is 12 bytes inside a block of size 44 free'd
==17885==    at 0x402454D: operator delete(void*) (vg_replace_malloc.c:346)
==17885==    by 0x8E974CA: ??? (in
/home/regehr/z/compiler-install/llvm-gcc-r99887-install/bin/clang)
==17885== 
==17885== Invalid read of size 1
==17885==    at 0x8D14B70: ??? (in
/home/regehr/z/compiler-install/llvm-gcc-r99887-install/bin/clang)
==17885==  Address 0x43bd0ec is 4 bytes inside a block of size 44 free'd
==17885==    at 0x402454D: operator delete(void*) (vg_replace_malloc.c:346)
==17885==    by 0x8E974CA: ??? (in
/home/regehr/z/compiler-install/llvm-gcc-r99887-install/bin/clang)
==17885== 
==17885== Invalid read of size 1
==17885==    at 0x8D14BE0: ??? (in
/home/regehr/z/compiler-install/llvm-gcc-r99887-install/bin/clang)
==17885==  Address 0x43bd0ec is 4 bytes inside a block of size 44 free'd
==17885==    at 0x402454D: operator delete(void*) (vg_replace_malloc.c:346)
==17885==    by 0x8E974CA: ??? (in
/home/regehr/z/compiler-install/llvm-gcc-r99887-install/bin/clang)
==17885== 
==17885== Invalid read of size 1
==17885==    at 0x8BF51D3: ??? (in
/home/regehr/z/compiler-install/llvm-gcc-r99887-install/bin/clang)
==17885==  Address 0x43bd0ec is 4 bytes inside a block of size 44 free'd
==17885==    at 0x402454D: operator delete(void*) (vg_replace_malloc.c:346)
==17885==    by 0x8E974CA: ??? (in
/home/regehr/z/compiler-install/llvm-gcc-r99887-install/bin/clang)
==17885== 
==17885== Invalid read of size 1
==17885==    at 0x8BF51E0: ??? (in
/home/regehr/z/compiler-install/llvm-gcc-r99887-install/bin/clang)
==17885==  Address 0x43bd0ec is 4 bytes inside a block of size 44 free'd
==17885==    at 0x402454D: operator delete(void*) (vg_replace_malloc.c:346)
==17885==    by 0x8E974CA: ??? (in
/home/regehr/z/compiler-install/llvm-gcc-r99887-install/bin/clang)
==17885== 
==17885== Invalid read of size 1
==17885==    at 0x8E4505A: ??? (in
/home/regehr/z/compiler-install/llvm-gcc-r99887-install/bin/clang)
==17885==  Address 0x43bd0ec is 4 bytes inside a block of size 44 free'd
==17885==    at 0x402454D: operator delete(void*) (vg_replace_malloc.c:346)
==17885==    by 0x8E974CA: ??? (in
/home/regehr/z/compiler-install/llvm-gcc-r99887-install/bin/clang)
==17885== 
==17885== Invalid read of size 1
==17885==    at 0x8E453C5: ??? (in
/home/regehr/z/compiler-install/llvm-gcc-r99887-install/bin/clang)
==17885==  Address 0x43bd0ec is 4 bytes inside a block of size 44 free'd
==17885==    at 0x402454D: operator delete(void*) (vg_replace_malloc.c:346)
==17885==    by 0x8E974CA: ??? (in
/home/regehr/z/compiler-install/llvm-gcc-r99887-install/bin/clang)
==17885== 
==17885== Invalid read of size 4
==17885==    at 0x8D14D92: ??? (in
/home/regehr/z/compiler-install/llvm-gcc-r99887-install/bin/clang)
==17885==  Address 0x43bd100 is 24 bytes inside a block of size 44 free'd
==17885==    at 0x402454D: operator delete(void*) (vg_replace_malloc.c:346)
==17885==    by 0x8E974CA: ??? (in
/home/regehr/z/compiler-install/llvm-gcc-r99887-install/bin/clang)
==17885== 
==17885== Invalid read of size 4
==17885==    at 0x8E4529A: ??? (in
/home/regehr/z/compiler-install/llvm-gcc-r99887-install/bin/clang)
==17885==  Address 0x43bd10c is 36 bytes inside a block of size 44 free'd
==17885==    at 0x402454D: operator delete(void*) (vg_replace_malloc.c:346)
==17885==    by 0x8E974CA: ??? (in
/home/regehr/z/compiler-install/llvm-gcc-r99887-install/bin/clang)
==17885== 
==17885== Invalid read of size 4
==17885==    at 0x8E452A1: ??? (in
/home/regehr/z/compiler-install/llvm-gcc-r99887-install/bin/clang)
==17885==  Address 0x20 is not stack'd, malloc'd or (recently) free'd
==17885== 
0  clang 0x08f089d8
Stack dump:
0.    Program arguments:
/home/regehr/z/compiler-install/llvm-gcc-r99887-install/bin/clang -cc1 -triple
i386-pc-linux-gnu -S -disable-free -main-file-name small.c -mrelocation-model
static -mdisable-fp-elim -mconstructor-aliases -target-cpu pentium4
-resource-dir
/home/regehr/z/compiler-install/llvm-gcc-r99887-install/lib/clang/1.5 -O1
-fmessage-length 80 -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics
-o /tmp/cc-GI1KEJ.s -x c small.c 
1.    <eof> parser at end of file
2.    Per-module optimization passes
3.    Running pass 'CallGraph Pass Manager' on module 'small.c'.
4.    Running pass 'Jump Threading' on function '@func_43'
==17885== 
==17885== Process terminating with default action of signal 11 (SIGSEGV)
==17885==  Access not within mapped region at address 0x20
==17885==    at 0x8E452A1: ??? (in
/home/regehr/z/compiler-install/llvm-gcc-r99887-install/bin/clang)
==17885==  If you believe this happened as a result of a stack
==17885==  overflow in your program's main thread (unlikely but
==17885==  possible), you can try to increase the size of the
==17885==  main thread stack using the --main-stacksize= flag.
==17885==  The main thread stack size used in this run was 8388608.
==17885== Invalid free() / delete / delete[]
==17885==    at 0x4024836: free (vg_replace_malloc.c:325)
==17885==    by 0x42AC7C4: ??? (in /lib/tls/i686/cmov/libc-2.10.1.so)
==17885==    by 0x401F432: _vgnU_freeres (vg_preloaded.c:62)
==17885==    by 0x435204F: ???
==17885==  Address 0xffffffff is not stack'd, malloc'd or (recently) free'd
==17885== 
clang: error: compiler command failed due to signal 11 (use -v to see
invocation)
==17882== Invalid free() / delete / delete[]
==17882==    at 0x4024836: free (vg_replace_malloc.c:325)
==17882==    by 0x42AC7C4: ??? (in /lib/tls/i686/cmov/libc-2.10.1.so)
==17882==    by 0x401F432: _vgnU_freeres (vg_preloaded.c:62)
==17882==    by 0x4237DC3: _Exit (_exit.S:30)
==17882==    by 0x41D00CE: exit (exit.c:100)
==17882==    by 0x41B7B5D: (below main) (libc-start.c:252)
==17882==  Address 0xffffffff is not stack'd, malloc'd or (recently) free'd
==17882== 

regehr at john-home:~/volatile/bugs/tmp295$ cat small.c

int g_28;
int g_31;

void func_43 (void)
{
  int *l_49 = &g_31;
  int *l_50 = &g_28;
 lbl_51:
  *l_50 ^= 0;
  *l_50 = 0 || *l_49;
  if (g_28 ^ 1) {
    for (g_31 = 0; 1; g_31 += 1) {
      if (g_28) goto lbl_51;
      return;
    }
  }
}

regehr at john-home:~/volatile/bugs/tmp295$ clang -v

clang version 1.5 (trunk 99887)
Target: i386-pc-linux-gnu
Thread model: posix

-- 
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 llvm.org  Tue Mar 30 10:16:12 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 30 Mar 2010 10:16:12 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6653] LiveInterval leaks VNInfos
In-Reply-To: <bug-6653-206@http.llvm.org/bugs/>
References: <bug-6653-206@http.llvm.org/bugs/>
Message-ID: <20100330151612.B42562A6C130@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=6653

Jeffrey Yasskin <jyasskin at google.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED
         AssignedTo|stoklund at 2pi.dk             |edwintorok at gmail.com

--- Comment #8 from Jeffrey Yasskin <jyasskin at google.com> 2010-03-30 10:16:12 CDT ---
Yes. Thank you!

-- 
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 llvm.org  Tue Mar 30 12:46:56 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 30 Mar 2010 12:46:56 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6744] New: [2.7]
 SingleSource/Regression/C/2004-03-15-IndirectGoto JIT failure
Message-ID: <bug-6744-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=6744

           Summary: [2.7]
                    SingleSource/Regression/C/2004-03-15-IndirectGoto JIT
                    failure
           Product: new-bugs
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: tonic at nondot.org
                CC: llvmbugs at cs.uiuc.edu


SingleSource/Regression/C/2004-03-15-IndirectGoto - JIT fails on Darwin 10.6.
This is a regression. I will try to bugpoint.

-- 
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 llvm.org  Tue Mar 30 13:19:00 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 30 Mar 2010 13:19:00 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6737] reference to a thunk generated while g++
	generates none
In-Reply-To: <bug-6737-206@http.llvm.org/bugs/>
References: <bug-6737-206@http.llvm.org/bugs/>
Message-ID: <20100330181900.D70C72A6C12F@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=6737

Rafael ?vila de Esp?ndola <rafael.espindola at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #1 from Rafael ?vila de Esp?ndola <rafael.espindola at gmail.com> 2010-03-30 13:19:00 CDT ---
fixed in r99900.

-- 
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 llvm.org  Tue Mar 30 13:19:28 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 30 Mar 2010 13:19:28 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6738] clang++ emits U symbols while g++ emits none
In-Reply-To: <bug-6738-206@http.llvm.org/bugs/>
References: <bug-6738-206@http.llvm.org/bugs/>
Message-ID: <20100330181928.9F0312A6C12E@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=6738

Rafael ?vila de Esp?ndola <rafael.espindola at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED

--- Comment #5 from Rafael ?vila de Esp?ndola <rafael.espindola at gmail.com> 2010-03-30 13:19:28 CDT ---
fixed in r99900.

-- 
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 llvm.org  Tue Mar 30 13:25:34 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 30 Mar 2010 13:25:34 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6302] static analyzer crashes on dereference to
 objc_object struct
In-Reply-To: <bug-6302-206@http.llvm.org/bugs/>
References: <bug-6302-206@http.llvm.org/bugs/>
Message-ID: <20100330182534.22CF92A6C12E@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=6302

Ted Kremenek <kremenek at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #4 from Ted Kremenek <kremenek at apple.com> 2010-03-30 13:25:33 CDT ---
Fixed:

http://llvm.org/viewvc/llvm-project?view=rev&revision=99904

-- 
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 llvm.org  Tue Mar 30 15:32:20 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 30 Mar 2010 15:32:20 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6288] 'const int' not recognized as constant-value
In-Reply-To: <bug-6288-206@http.llvm.org/bugs/>
References: <bug-6288-206@http.llvm.org/bugs/>
Message-ID: <20100330203220.5F0532A6C12D@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=6288

Ted Kremenek <kremenek at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |kremenek at apple.com
         Resolution|                            |FIXED

--- Comment #2 from Ted Kremenek <kremenek at apple.com> 2010-03-30 15:32:20 CDT ---
Fixed:

http://llvm.org/viewvc/llvm-project?view=rev&revision=99922

-- 
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 llvm.org  Tue Mar 30 16:10:07 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 30 Mar 2010 16:10:07 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6613] doxygen is broken from objdir build
In-Reply-To: <bug-6613-206@http.llvm.org/bugs/>
References: <bug-6613-206@http.llvm.org/bugs/>
Message-ID: <20100330211007.860752A6C12C@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=6613

mikem.llvm at gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|WONTFIX                     |

--- Comment #10 from mikem.llvm at gmail.com 2010-03-30 16:10:07 CDT ---
oops inadvertent status change. re-opened.
...just waiting for anyone with doxygen/docs build interest to try the overhaul
out.

-- 
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 llvm.org  Tue Mar 30 16:30:39 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 30 Mar 2010 16:30:39 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6745] New: .ll output is different on windows
Message-ID: <bug-6745-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=6745

           Summary: .ll output is different on windows
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Core LLVM classes
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: rafael.espindola at gmail.com
                CC: llvmbugs at cs.uiuc.edu


I don't have a windows machine to test on, but it looks like we print 0.0 as
"double 0.000000e+00" on linux and as "double 0.000000e+000" on windows.

Possible testcase:

void foo(double a);
void bar(void) {
  foo(0.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 llvm.org  Tue Mar 30 17:11:14 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 30 Mar 2010 17:11:14 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6739] If/else scoping problem
In-Reply-To: <bug-6739-206@http.llvm.org/bugs/>
References: <bug-6739-206@http.llvm.org/bugs/>
Message-ID: <20100330221114.1BA1F2A6C12C@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=6739

Douglas Gregor <dgregor at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID

--- Comment #2 from Douglas Gregor <dgregor at apple.com> 2010-03-30 17:11:13 CDT ---
(In reply to comment #1)
> Sorry, I didn't mean to break all kinds of compilers. MSVC also choked ;-)

It turns out that Clang and MSVC were correct, per C++ [stmt.select]p3.

-- 
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 llvm.org  Tue Mar 30 17:21:13 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 30 Mar 2010 17:21:13 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6647] SIGSEGV in clang::TokenLexer::Lex ()
In-Reply-To: <bug-6647-206@http.llvm.org/bugs/>
References: <bug-6647-206@http.llvm.org/bugs/>
Message-ID: <20100330222113.B44DE2A6C12D@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=6647

Argiris Kirtzidis <akyrtzi at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #3 from Argiris Kirtzidis <akyrtzi at gmail.com> 2010-03-30 17:21:13 CDT ---
Fixed at r99939, thanks for the 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 llvm.org  Tue Mar 30 17:24:38 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 30 Mar 2010 17:24:38 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6550] linker error for std::istream::seekg
In-Reply-To: <bug-6550-206@http.llvm.org/bugs/>
References: <bug-6550-206@http.llvm.org/bugs/>
Message-ID: <20100330222438.3B4D12A6C12F@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=6550

Rafael ?vila de Esp?ndola <rafael.espindola at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #1 from Rafael ?vila de Esp?ndola <rafael.espindola at gmail.com> 2010-03-30 17:24:37 CDT ---
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 llvm.org  Tue Mar 30 17:26:37 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 30 Mar 2010 17:26:37 -0500 (CDT)
Subject: [LLVMbugs] [Bug 3782] 'regparm' attribute is not supported
In-Reply-To: <bug-3782-206@http.llvm.org/bugs/>
References: <bug-3782-206@http.llvm.org/bugs/>
Message-ID: <20100330222637.A4E102A6C124@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=3782

Rafael ?vila de Esp?ndola <rafael.espindola at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED

--- Comment #24 from Rafael ?vila de Esp?ndola <rafael.espindola at gmail.com> 2010-03-30 17:26:36 CDT ---
Fixed in r99940.

-- 
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 llvm.org  Tue Mar 30 17:48:19 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 30 Mar 2010 17:48:19 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6640] release-asserts build of llvm-2.7 prerelease
 fails several unit tests
In-Reply-To: <bug-6640-206@http.llvm.org/bugs/>
References: <bug-6640-206@http.llvm.org/bugs/>
Message-ID: <20100330224819.4188B2A6C12D@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=6640

Tanya Lattner <tonic at nondot.org> 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 llvm.org  Tue Mar 30 17:55:23 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 30 Mar 2010 17:55:23 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6663] MultiSource/Benchmarks/Bullet/bullet fails on
 x86-32 linux when using -fPIC
In-Reply-To: <bug-6663-206@http.llvm.org/bugs/>
References: <bug-6663-206@http.llvm.org/bugs/>
Message-ID: <20100330225523.43A712A6C12D@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=6663

Tanya Lattner <tonic at nondot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
                 CC|                            |tonic at nondot.org
         Resolution|FIXED                       |

--- Comment #8 from Tanya Lattner <tonic at nondot.org> 2010-03-30 17:55:22 CDT ---
Patch does not apply cleanly to the branch, reopening until 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 llvm.org  Tue Mar 30 19:17:53 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 30 Mar 2010 19:17:53 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6597] RTTI codegen crash
In-Reply-To: <bug-6597-206@http.llvm.org/bugs/>
References: <bug-6597-206@http.llvm.org/bugs/>
Message-ID: <20100331001753.663DD2A6C12E@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=6597

Douglas Gregor <dgregor at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #7 from Douglas Gregor <dgregor at apple.com> 2010-03-30 19:17:52 CDT ---
Fixed in r99968.

-- 
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 llvm.org  Tue Mar 30 19:22:52 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 30 Mar 2010 19:22:52 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6598] duplicate symbol...
In-Reply-To: <bug-6598-206@http.llvm.org/bugs/>
References: <bug-6598-206@http.llvm.org/bugs/>
Message-ID: <20100331002252.DE0C22A6C12F@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=6598

Douglas Gregor <dgregor at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #3 from Douglas Gregor <dgregor at apple.com> 2010-03-30 19:22:52 CDT ---
Rafael fixed this recently.

-- 
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 llvm.org  Tue Mar 30 21:20:06 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 30 Mar 2010 21:20:06 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6327] Compiler assert on 'initalizer_list' style
	code:
In-Reply-To: <bug-6327-206@http.llvm.org/bugs/>
References: <bug-6327-206@http.llvm.org/bugs/>
Message-ID: <20100331022006.197D42A6C124@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=6327

John McCall <rjmccall at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |rjmccall at apple.com
         Resolution|                            |FIXED

--- Comment #2 from John McCall <rjmccall at apple.com> 2010-03-30 21:20:05 CDT ---
Fixed (both) in r99980.

-- 
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 llvm.org  Tue Mar 30 22:00:52 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 30 Mar 2010 22:00:52 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6746] New: Crash after missing header
Message-ID: <bug-6746-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=6746

           Summary: Crash after missing header
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Keywords: crash-on-invalid
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: jyasskin at google.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


As of r99978:


(gdb) run
Starting program: /Users/jyasskin/src/llvm/clang/obj/Debug/bin/clang -cc1
-triple i386-apple-darwin9.0.0 -S -disable-free -main-file-name DeclCXX.cpp
-pic-level 1 -mdisable-fp-elim -target-cpu yonah -resource-dir
/Users/jyasskin/src/llvm/clang/obj/Debug/lib/clang/1.5 -I
../src/tools/clang/include/ -fmessage-length 225 -fexceptions
-fdiagnostics-show-option -fcolor-diagnostics -o
/var/folders/zz/zzzivhrRnAmviuee+++ph+++BPE/-Tmp-/cc-x5SK56.s -x c++
../src/tools/clang/lib/AST/DeclCXX.cpp
Reading symbols for shared libraries +++. done
In file included from ../src/tools/clang/lib/AST/DeclCXX.cpp:14:
In file included from ../src/tools/clang/include/clang/AST/DeclCXX.h:18:
In file included from ../src/tools/clang/include/clang/AST/Expr.h:17:
../src/tools/clang/include/clang/AST/APValue.h:17:10: fatal error:
'llvm/ADT/APSInt.h' file not found
#include "llvm/ADT/APSInt.h"
         ^
Assertion failed: (RefCount >= 1 && "Referencing already-destroyed
statement!"), function getStmtClass, file
/Users/jyasskin/src/llvm/clang/src/tools/clang/lib/AST/../../include/clang/AST/Stmt.h,
line 203.

Program received signal SIGABRT, Aborted.
0x92c4ee42 in __kill ()
(gdb) bt
#0  0x92c4ee42 in __kill ()
#1  0x92c4ee34 in kill$UNIX2003 ()
#2  0x92cc123a in raise ()
#3  0x92ccd679 in abort ()
#4  0x92cc23db in __assert_rtn ()
#5  0x004fc41f in clang::Stmt::getStmtClass (this=0x3dff1d0) at Stmt.h:203
#6  0x00496f45 in clang::DeclStmt::classof (T=0x3dff1d0) at Stmt.h:333
#7  0x0049ca45 in llvm::isa_impl<clang::DeclStmt, clang::Stmt>::doit
(Val=@0x3dff1d0) at Casting.h:55
#8  0x004afc75 in llvm::isa_impl_wrap<clang::DeclStmt, clang::Stmt const,
clang::Stmt const>::doit (Val=@0x3dff1d0) at Casting.h:73
#9  0x0049ca5d in llvm::isa_impl_cl<clang::Stmt>::isa<clang::DeclStmt>
(Val=@0x3dff1d0) at Casting.h:85
#10 0x004afc8d in llvm::isa_impl_cl<clang::Stmt*>::isa<clang::DeclStmt>
(Val=0x3dff1d0) at Casting.h:103
#11 0x0049ca77 in llvm::isa<clang::DeclStmt, clang::Stmt*> (Val=@0xbfffcde4) at
Casting.h:118
#12 0x0058781d in llvm::dyn_cast<clang::DeclStmt, clang::Stmt*>
(Val=@0xbfffcde4) at Casting.h:228
#13 0x0022501f in (anonymous
namespace)::JumpScopeChecker::BuildScopeInformation (this=0xbfffd010,
S=0x3dff290, ParentScope=0) at
/Users/jyasskin/src/llvm/clang/src/tools/clang/lib/Sema/JumpDiagnostics.cpp:128
#14 0x0022550c in (anonymous
namespace)::JumpScopeChecker::BuildScopeInformation (this=0xbfffd010,
S=0x3dff2c8, ParentScope=0) at
/Users/jyasskin/src/llvm/clang/src/tools/clang/lib/Sema/JumpDiagnostics.cpp:215
#15 0x002255e0 in (anonymous namespace)::JumpScopeChecker::JumpScopeChecker
(this=0xbfffd010, Body=0x3dff2c8, s=@0xbfffe230) at
/Users/jyasskin/src/llvm/clang/src/tools/clang/lib/Sema/JumpDiagnostics.cpp:72
#16 0x00225613 in clang::Sema::DiagnoseInvalidJumps (this=0xbfffe230,
Body=0x3dff2c8) at
/Users/jyasskin/src/llvm/clang/src/tools/clang/lib/Sema/JumpDiagnostics.cpp:332
#17 0x00270e19 in clang::Sema::ActOnFinishFunctionBody (this=0xbfffe230, D={Ptr
= 0x3dfee40}, BodyArg=@0xbfffd4cc, IsInstantiation=false) at
/Users/jyasskin/src/llvm/clang/src/tools/clang/lib/Sema/SemaDecl.cpp:4405
#18 0x0027103b in clang::Sema::ActOnFinishFunctionBody (this=0xbfffe230, D={Ptr
= 0x3dfee40}, BodyArg=@0xbfffd56c) at
/Users/jyasskin/src/llvm/clang/src/tools/clang/lib/Sema/SemaDecl.cpp:4309
#19 0x005e584a in clang::Parser::ParseFunctionStatementBody (this=0xbfffe900,
Decl={Ptr = 0x3dfee40}) at
/Users/jyasskin/src/llvm/clang/src/tools/clang/lib/Parse/ParseStmt.cpp:1441
#20 0x005a7bf1 in clang::Parser::ParseLexedMethodDefs (this=0xbfffe900,
Class=@0x3378bd0) at
/Users/jyasskin/src/llvm/clang/src/tools/clang/lib/Parse/ParseCXXInlineMethods.cpp:226
#21 0x005bc51d in clang::Parser::ParseCXXMemberSpecification (this=0xbfffe900,
RecordLoc={ID = 1931916}, TagType=16, TagDecl={Ptr = 0x3dfa010}) at
/Users/jyasskin/src/llvm/clang/src/tools/clang/lib/Parse/ParseDeclCXX.cpp:1600
#22 0x005bd8c0 in clang::Parser::ParseClassSpecifier (this=0xbfffe900,
TagTokKind=clang::tok::kw_class, StartLoc={ID = 1931916}, DS=@0xbfffdd5c,
TemplateInfo=@0xbfffdcf8, AS=clang::AS_none, SuppressDeclarations=false) at
/Users/jyasskin/src/llvm/clang/src/tools/clang/lib/Parse/ParseDeclCXX.cpp:910
#23 0x005b0054 in clang::Parser::ParseDeclarationSpecifiers (this=0xbfffe900,
DS=@0xbfffdd5c, TemplateInfo=@0xbfffdcf8, AS=clang::AS_none,
DSContext=clang::Parser::DSC_top_level) at
/Users/jyasskin/src/llvm/clang/src/tools/clang/lib/Parse/ParseDecl.cpp:1302
#24 0x005ee38f in clang::Parser::ParseDeclarationOrFunctionDefinition
(this=0xbfffe900, DS=@0xbfffdd5c, Attr=0x0, AS=clang::AS_none) at
/Users/jyasskin/src/llvm/clang/src/tools/clang/lib/Parse/Parser.cpp:535
#25 0x005ee770 in clang::Parser::ParseDeclarationOrFunctionDefinition
(this=0xbfffe900, Attr=0x0, AS=clang::AS_none) at
/Users/jyasskin/src/llvm/clang/src/tools/clang/lib/Parse/Parser.cpp:590
#26 0x005ef550 in clang::Parser::ParseExternalDeclaration (this=0xbfffe900,
Attr={AttrList = 0x0, Range = {B = {ID = 0}, E = {ID = 0}}, HasAttr = false})
at /Users/jyasskin/src/llvm/clang/src/tools/clang/lib/Parse/Parser.cpp:479
#27 0x005b9861 in clang::Parser::ParseNamespace (this=0xbfffe900, Context=0,
DeclEnd=@0xbfffe0c0) at
/Users/jyasskin/src/llvm/clang/src/tools/clang/lib/Parse/ParseDeclCXX.cpp:105
#28 0x005b3086 in clang::Parser::ParseDeclaration (this=0xbfffe900, Context=0,
DeclEnd=@0xbfffe0c0, Attr={AttrList = 0x0, Range = {B = {ID = 0}, E = {ID =
0}}, HasAttr = false}) at
/Users/jyasskin/src/llvm/clang/src/tools/clang/lib/Parse/ParseDecl.cpp:325
#29 0x005ef459 in clang::Parser::ParseExternalDeclaration (this=0xbfffe900,
Attr={AttrList = 0x0, Range = {B = {ID = 0}, E = {ID = 0}}, HasAttr = false})
at /Users/jyasskin/src/llvm/clang/src/tools/clang/lib/Parse/Parser.cpp:461
#30 0x005ef68e in clang::Parser::ParseTopLevelDecl (this=0xbfffe900,
Result=@0xbfffea2c) at
/Users/jyasskin/src/llvm/clang/src/tools/clang/lib/Parse/Parser.cpp:351
#31 0x002265ab in clang::ParseAST (PP=@0x33026a0, Consumer=0x3304ed0,
Ctx=@0x3824000, PrintStats=false, CompleteTranslationUnit=true,
CompletionConsumer=0x0) at
/Users/jyasskin/src/llvm/clang/src/tools/clang/lib/Sema/ParseAST.cpp:68
#32 0x000406c4 in clang::ASTFrontendAction::ExecuteAction (this=0x3301ed0) at
/Users/jyasskin/src/llvm/clang/src/tools/clang/lib/Frontend/FrontendAction.cpp:223
#33 0x000405b4 in clang::FrontendAction::Execute (this=0x3301ed0) at
/Users/jyasskin/src/llvm/clang/src/tools/clang/lib/Frontend/FrontendAction.cpp:149
#34 0x00021a23 in clang::CompilerInstance::ExecuteAction (this=0x3301980,
Act=@0x3301ed0) at
/Users/jyasskin/src/llvm/clang/src/tools/clang/lib/Frontend/CompilerInstance.cpp:510
#35 0x000035bb in cc1_main (ArgBegin=0xbffff270, ArgEnd=0xbffff2d4,
Argv0=0xbffff384 "/Users/jyasskin/src/llvm/clang/obj/Debug/bin/clang",
MainAddr=0x61ae) at
/Users/jyasskin/src/llvm/clang/src/tools/clang/tools/driver/cc1_main.cpp:271
#36 0x00006f3f in main (argc=27, argv=0xbffff268) at
/Users/jyasskin/src/llvm/clang/src/tools/clang/tools/driver/driver.cpp:181
(gdb)

-- 
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 llvm.org  Tue Mar 30 22:57:02 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 30 Mar 2010 22:57:02 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6747] New: missed optimization for inline virtual
	methods
Message-ID: <bug-6747-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=6747

           Summary: missed optimization for inline virtual methods
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: rafael.espindola at gmail.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


Given the translation unit

struct foo {
  virtual void bar();
  virtual void baz() {}
};
void zed() {
  foo b;
  b.baz();
}

we currently produce

define linkonce_odr void @_ZN3foo3bazEv

it should probably be available_externally. Given that the function is virtual
and we know we will have a vtable in some other translation unit, we can
produce this one as available_externally.

-- 
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 llvm.org  Tue Mar 30 23:05:19 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 30 Mar 2010 23:05:19 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6746] Crash after missing header
In-Reply-To: <bug-6746-206@http.llvm.org/bugs/>
References: <bug-6746-206@http.llvm.org/bugs/>
Message-ID: <20100331040519.4DF832A6C12E@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=6746

Nick Lewycky <nlewycky at google.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |nlewycky at google.com
         Resolution|                            |DUPLICATE

--- Comment #1 from Nick Lewycky <nlewycky at google.com> 2010-03-30 23:05:19 CDT ---


*** This bug has been marked as a duplicate of bug 6720 ***

-- 
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 llvm.org  Tue Mar 30 23:30:27 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 30 Mar 2010 23:30:27 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6748] New: missed optimization for vtables
Message-ID: <bug-6748-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=6748

           Summary: missed optimization for vtables
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: rafael.espindola at gmail.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


We produce a vtable for

template <typename T>
struct foo {
  virtual void bar() {}
};
template struct foo<int>;


so we don't have to produce one for

template <typename T>
struct foo {
  virtual void bar() {}
};
extern template struct foo<int>;
void zed() {
  foo<int> a;
  a.bar();
}

-- 
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 llvm.org  Wed Mar 31 01:56:08 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 31 Mar 2010 01:56:08 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6749] New: clang allows references to fulfill
 reference non-type parameters
Message-ID: <bug-6749-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=6749

           Summary: clang allows references to fulfill reference non-type
                    parameters
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: rideau3 at gmail.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


clang accepts the following code:

template <int& i>
struct foo {};

int x, &y = x;

foo<y> f;

It should not, because a reference satisfies no condition in 14.3.2. It comes
close to satisfying the third condition, but references are not objects.

-- 
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 llvm.org  Wed Mar 31 03:00:06 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 31 Mar 2010 03:00:06 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6750] New: 'SSE execution domain fixup' crash
Message-ID: <bug-6750-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=6750

           Summary: 'SSE execution domain fixup' crash
           Product: new-bugs
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: baldrick at free.fr
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=4617)
 --> (http://llvm.org/bugs/attachment.cgi?id=4617)
testcase .ll

$ llc sse_domain.bc
...
3  llc       0x00000000009ea31e llvm::MachineInstr::getDesc() const + 12
4  llc       0x0000000000c78cff
llvm::X86InstrInfo::SetSSEDomain(llvm::MachineInstr*, unsigned int) const + 75
5  llc       0x0000000000c8b234
6  llc       0x0000000000c8b160
7  llc       0x0000000000c8b892
8  llc       0x0000000000c8c354
9  llc       0x0000000000eb386b
llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 95
10 llc       0x00000000011d1ae9
llvm::FPPassManager::runOnFunction(llvm::Function&) + 405
11 llc       0x00000000011d17b3
llvm::FunctionPassManagerImpl::run(llvm::Function&) + 89
12 llc       0x00000000011d1463 llvm::FunctionPassManager::run(llvm::Function&)
+ 137
13 llc       0x0000000000981902 main + 3119
14 libc.so.6 0x00007fa90e9d1c4d __libc_start_main + 253
15 llc       0x0000000000980449
Stack dump:
0.    Program arguments: llc sse_domain.bc 
1.    Running pass 'SSE execution domain fixup' on function '@main'
Segmentation fault (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 llvm.org  Wed Mar 31 09:10:20 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 31 Mar 2010 09:10:20 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6751] New: bug in release 2.7
Message-ID: <bug-6751-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=6751

           Summary: bug in release 2.7
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: release blocker
          Priority: P
         Component: Backend: X86
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: forumer at smartmobili.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=4619)
 --> (http://llvm.org/bugs/attachment.cgi?id=4619)
Preprocessed file

Hi,

I am testing the upcoming 2.7 release on mingw and I have already reported this
bug on mailing list but with no success, so I am opening a new bug here.
I am trying to compile GNUstep-Gui with clang and I get an assert in 
llvm-2.7\lib\Target\X86\X86ISelLowering.cpp.
I have attached the preprocessed file (gcc -save-temps) to reproduce.
If you need more information, please let me know.
I have also compiled clang with Visual Studio just to be sure and I have the
same error.


clang version 1.1 (branches/release_27 99950)
Target: i686-pc-mingw32
Thread model: posix
 "C:/Developer/Mingw-NG/home/Vincent/llvm-2.7/Release/bin/clang.exe" -cc1
-triple i686-pc-mingw32 -S -disable-free -main-file-name Functions.m
-mrelocation-model static -mdisable-fp-elim -mconstructor-aliases -v -g
-resource-dir
C:/Developer/Mingw-NG/home/Vincent/llvm-2.7/Release/lib/clang/1.1
-dependency-file obj/libgnustep-gui.obj/Functions.m.d -MT
obj/libgnustep-gui.obj/Functions.m.o -MP -DGNUSTEP_TARGET_DIR="."
-DGNUSTEP_TARGET_CPU="ix86" -DGNUSTEP_TARGET_OS="mingw32"
-DLIBRARY_COMBO="gnu-gnu-gnu" -DBACKEND_BUNDLE=1 -DGNUSTEP
-DGNUSTEP_BASE_LIBRARY=1 -DGNU_GUI_LIBRARY=1 -DGNU_RUNTIME=1
-DGNUSTEP_BASE_LIBRARY=1 -DGNUSTEP_WITH_DLL -DBUILD_libgnustep_gui_DLL=1
-DGSWARN -DGSDIAGNOSE -I../Headers/Additions -I../Headers -I./. -I.
-IC:/Developer/Mingw-NG/home/Vincent/GNUstep/Library/Headers
-IC:/Developer/Mingw-NG/GNUstep/Local/Library/Headers
-IC:/Developer/Mingw-NG/GNUstep/System/Library/Headers -O2 -Wall
-Wno-import -Wall -fconstant-string-class NSConstantString -fmessage-length
0 -fgnu-runtime -fdiagnostics-show-option -o
C:/DOCUME~1/Vincent/LOCALS~1/Temp/cc-000000.s -x objective-c Functions.m
clang -cc1 version 1.1 based upon llvm 2.7 hosted on i686-pc-mingw32
ignoring nonexistent directory
"C:/Developer/Mingw-NG/home/Vincent/GNUstep/Library/Headers"
ignoring nonexistent directory
"C:/Developer/Mingw-NG/GNUstep/Local/Library/Headers"
ignoring nonexistent directory "c:/mingw/include"
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory "/usr/include"
ignoring duplicate directory "./."
#include "..." search starts here:
#include <...> search starts here:
 ../Headers/Additions
 ../Headers
 ./.
 C:/Developer/Mingw-NG/GNUstep/System/Library/Headers
 C:/Developer/Mingw-NG/home/Vincent/llvm-2.7/Release/lib/clang/1.1/include
 c:/Developer/Mingw-NG/mingw32/include
 c:/Developer/Mingw-NG/mingw32/lib/gcc/i686-w64-mingw32/4.4.4/include

c:/Developer/Mingw-NG/mingw32/lib/gcc/i686-w64-mingw32/4.4.4/include-fixed
 c:/Developer/Mingw-NG/mingw32/i686-w64-mingw32/include
End of search list.

This application has requested the Runtime to terminate it in an unusual
way.
Please contact the application's support team for more information.
Assertation failed!

Program: C:\Developer\Mingw-NG\home\Vincent\llvm-2.7\Release\bin\clang.exe
File: X86ISelLowering.cpp, Line 2152

Expression: ((Callee.getOpcode() == ISD::Register &&
(cast<RegisterSDNode>(Callee)->getReg() == X86::EAX ||
cast<RegisterSDNode>(Callee)->getReg() == X86::R11)) || Callee.getOpcode()
== ISD::TargetExternalSymbol || Callee.getOpcode() ==
ISD::TargetGlobalAddress) && "Expec
clang: error: compiler command failed with exit code 3 (use -v to see
invocation)

-- 
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 llvm.org  Wed Mar 31 10:09:28 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 31 Mar 2010 10:09:28 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6728] [cygwin] stage2 of llvm-gcc-4.2 doesn't
 compile: __PTRDIFF_TYPE__ expanded as "int"
In-Reply-To: <bug-6728-206@http.llvm.org/bugs/>
References: <bug-6728-206@http.llvm.org/bugs/>
Message-ID: <20100331150928.B14692A6C12C@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=6728

vlacomp at orange.fr changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #3 from vlacomp at orange.fr 2010-03-31 10:09:28 CDT ---
(In reply to comment #2)
> (In reply to comment #1)
> > I have no idea, are you following the instructions in README.LLVM?
> I re-installed llvm-gcc-4.2 today from scratch (svn version).
> I tried to follow all the instructions in README.LLVM.
> stage1 terminates OK. However I get the same issue in stage2.
> I am recompiling llvm in Debug build.
> I will add --enable-checking to the configure flags for llvm-gcc-4.2.
> Hope this config will give better result!

Hi,
I finally succeed in compiling the svn version of llvm-gcc-4.2.
In case this may help somebody-else I put the configure options I used for my
CYGWIN environment.
$ llvm-gcc -v
Using built-in specs.
Target: i686-pc-cygwin
Configured with: ../llvm-gcc-4.2-svn/configure --enable-checking
--disable-shared --disable-bootstrap --disable-nls --with-arch=i486
--with-cpu=generic --prefix=/usr/local
--enable-llvm=/cygdrive/J/Profiles/r29173/projects/people/llvm/llvm-obj
--disable-win32-registry --enable-languages=c,c++ --program-prefix=llvm-
--disable-sjlj-exceptions
Thread model: single
gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build)

-- 
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 llvm.org  Wed Mar 31 10:59:06 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 31 Mar 2010 10:59:06 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6752] New: Assert when compiling - "Access
 specifier is AS_none inside a record decl"
Message-ID: <bug-6752-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=6752

           Summary: Assert when compiling - "Access specifier is AS_none
                    inside a record decl"
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: ori at avtalion.name
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


The following piece of code compiles with g++, but doesn't with clang++

struct Foo {
    template<class A>
    struct IteratorImpl {

        template<class T> friend class IteratorImpl;

        IteratorImpl() {}

        template<class T>
        IteratorImpl(const IteratorImpl<T> &c) {}

    };

    typedef IteratorImpl<int *> iterator;
    typedef IteratorImpl<const int *> const_iterator;

    iterator end() {
        return iterator();
    }
};

Foo foo;
Foo::const_iterator iter = foo.end();

===================================

clang: DeclBase.cpp:463: void clang::Decl::CheckAccessDeclContext() const:
Assertion `Access != AS_none && "Access specifier is AS_none inside a record
decl"' failed.

[...]

Stack dump:
0.    Program arguments: /home/ori/devel/llvm/Debug/bin/clang -cc1 -triple
x86_64-unknown-linux-gnu -S -disable-free -main-file-name clang-crash2.cpp
-mrelocation-model static -mdisable-fp-elim -mconstructor-aliases
-munwind-tables -target-cpu x86-64 -resource-dir
/home/ori/devel/llvm/Debug/lib/clang/1.5 -pedantic -fmessage-length 143
-fexceptions -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o
/tmp/cc-NhBY01.s -x c++ /home/ori/clang-crash2.cpp 
1.    /home/ori/clang-crash2.cpp:23:37: current parser token ';'
clang: error: compiler command failed due to signal 6 (use -v to see
invocation)

-- 
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 llvm.org  Wed Mar 31 12:07:09 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 31 Mar 2010 12:07:09 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6365] Assertion failed: (Access != AS_none &&
 "Access specifier is AS_none inside a record decl")
In-Reply-To: <bug-6365-206@http.llvm.org/bugs/>
References: <bug-6365-206@http.llvm.org/bugs/>
Message-ID: <20100331170709.BC6332A6C12F@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=6365

Chandler Carruth <chandlerc at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED

--- Comment #14 from Chandler Carruth <chandlerc at gmail.com> 2010-03-31 12:07:08 CDT ---
I still have a recovery patch that was inspired by this bug, but no need to
track it here as these test cases are clearly fine now.

-- 
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 llvm.org  Wed Mar 31 12:14:08 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 31 Mar 2010 12:14:08 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6750] 'SSE execution domain fixup' crash
In-Reply-To: <bug-6750-206@http.llvm.org/bugs/>
References: <bug-6750-206@http.llvm.org/bugs/>
Message-ID: <20100331171408.814512A6C12D@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=6750

Jakob Stoklund Olesen <stoklund at 2pi.dk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #6 from Jakob Stoklund Olesen <stoklund at 2pi.dk> 2010-03-31 12:14:07 CDT ---
Fixed in r100016

-- 
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 llvm.org  Wed Mar 31 13:15:28 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 31 Mar 2010 13:15:28 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6753] New: lit may not do a good job of managing
 file descriptors when executing scripts internally
Message-ID: <bug-6753-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=6753

           Summary: lit may not do a good job of managing file descriptors
                    when executing scripts internally
           Product: Test Suite
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: lit
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: daniel at zuster.org
                CC: llvmbugs at cs.uiuc.edu, daniel at zuster.org


I believe that 'lit' has a bug where, when running scripts internally, it does
not close the file descriptors for redirections at the appropriate time.

I believe this is the source of spurious failures we see on the msvc buildbot,
but haven't had time to track it down. Filing for tracking purposes.

-- 
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 llvm.org  Wed Mar 31 13:38:00 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 31 Mar 2010 13:38:00 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6671] Fail to call destructor for explicitly
 created temporary in function template
In-Reply-To: <bug-6671-206@http.llvm.org/bugs/>
References: <bug-6671-206@http.llvm.org/bugs/>
Message-ID: <20100331183800.B33AD2A6C12D@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=6671

Chandler Carruth <chandlerc at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED

--- Comment #2 from Chandler Carruth <chandlerc at gmail.com> 2010-03-31 13:38:00 CDT ---
Fixed in r100029.

-- 
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 llvm.org  Wed Mar 31 13:49:42 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 31 Mar 2010 13:49:42 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6753] lit may not do a good job of managing file
 descriptors when executing scripts internally
In-Reply-To: <bug-6753-206@http.llvm.org/bugs/>
References: <bug-6753-206@http.llvm.org/bugs/>
Message-ID: <20100331184942.8F1BE2A6C12D@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=6753

Daniel Dunbar <daniel at zuster.org> 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 llvm.org  Wed Mar 31 16:06:33 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 31 Mar 2010 16:06:33 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6754] New: incorrect parsing of friend declaration
	with a ::
Message-ID: <bug-6754-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=6754

           Summary: incorrect parsing of friend declaration with a ::
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: rafael.espindola at gmail.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


gcc accepts but clang rejects:

-----------------------------------
struct C {
  enum bar { foo };
};
C::bar zed();
class D {
  friend C::bar ::zed();
};
-----------------------------------

the error message

test.ii:6:13: error: expected a class or namespace
  friend C::bar ::zed();
         ~~~^
test.ii:6:19: error: C++ requires a type specifier for all declarations
  friend C::bar ::zed();
  ~~~~~~          ^

suggest that clang is trying to parse the return type of zed as the class we
are declaring friendship with.

Removing the :: before zed makes clang accept the code.

-- 
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 llvm.org  Wed Mar 31 16:46:25 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 31 Mar 2010 16:46:25 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6754] incorrect parsing of friend declaration with
	a ::
In-Reply-To: <bug-6754-206@http.llvm.org/bugs/>
References: <bug-6754-206@http.llvm.org/bugs/>
Message-ID: <20100331214625.61FB72A6C124@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=6754

Rafael ?vila de Esp?ndola <rafael.espindola at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID

--- Comment #1 from Rafael ?vila de Esp?ndola <rafael.espindola at gmail.com> 2010-03-31 16:46:25 CDT ---
<dgregor> it's invalid
<dgregor> C::bar ::zed
<dgregor> take out the space: C::bar::zed
<dgregor> Clang+EDG correctly try to parse it as a nested-name-specifier. GCC
is using some kind of semantic check to direct parsing here

-- 
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 llvm.org  Wed Mar 31 17:22:15 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 31 Mar 2010 17:22:15 -0500 (CDT)
Subject: [LLVMbugs] [Bug 5681] instantiation of elaborated type specifiers
 does ordinary lookup
In-Reply-To: <bug-5681-206@http.llvm.org/bugs/>
References: <bug-5681-206@http.llvm.org/bugs/>
Message-ID: <20100331222215.690772A6C12D@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=5681

Douglas Gregor <dgregor at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #1 from Douglas Gregor <dgregor at apple.com> 2010-03-31 17:22:15 CDT ---
Fixed in r100054.

-- 
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 llvm.org  Wed Mar 31 19:17:20 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 31 Mar 2010 19:17:20 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6699] false positive memory leak in C arrays with
 CoreFoundation
In-Reply-To: <bug-6699-206@http.llvm.org/bugs/>
References: <bug-6699-206@http.llvm.org/bugs/>
Message-ID: <20100401001720.531D52A6C12D@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=6699

Ted Kremenek <kremenek at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |kremenek at apple.com
         Resolution|                            |FIXED

--- Comment #1 from Ted Kremenek <kremenek at apple.com> 2010-03-31 19:17:19 CDT ---
Fixed:

http://llvm.org/viewvc/llvm-project?view=rev&revision=100067

This turned out to be a regression in the state-cleaning logic concerning
values bound to array elements with a non-zero index.

-- 
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.