From bugzilla-daemon at llvm.org  Tue Feb  1 06:10:18 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  1 Feb 2011 06:10:18 -0600 (CST)
Subject: [LLVMbugs] [Bug 9115] New: confusing diagnostic for extra
 qualification on member
Message-ID: <bug-9115-206@http.llvm.org/bugs/>

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

           Summary: confusing diagnostic for extra qualification on member
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: reif at earthlink.net
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


For this code:

class MyClass {
public:
MyClass::MyClass();
};

g++ gives:

test.cpp:3: error: extra qualification ?MyClass::? on member ?MyClass?

and comeau gives:

"ComeauTest.c", line 3: error: qualified name is not allowed in member
declaration
      MyClass::MyClass();

but clang++ gives:

test.cpp:3:22: error: expected member name or ';' after declaration specifiers
MyClass::MyClass();
~~~~~~~~~~~~~~~~ ^
1 error generated.

which is confusing.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb  1 07:29:44 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  1 Feb 2011 07:29:44 -0600 (CST)
Subject: [LLVMbugs] [Bug 9116] New: assertion failed in
	IdempotentOperationChecker.cpp
Message-ID: <bug-9116-206@http.llvm.org/bugs/>

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

           Summary: assertion failed in IdempotentOperationChecker.cpp
           Product: clang
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Static Analyzer
        AssignedTo: kremenek at apple.com
        ReportedBy: devlists at shadowlab.org
                CC: llvmbugs at cs.uiuc.edu


clang abort while analyzing the following (valid) code.

---------- analyze.m
@interface NSObject {}
  @property int locked;
  @property(nonatomic, readonly) NSObject *media;
@end

void setPlaceholder(NSObject *placeholder) {
  placeholder.media.locked = placeholder ? 1 : 0;
}
-------------
% clang --version
clang version 2.9 (trunk 124655)
Target: x86_64-apple-darwin10

% clang --analyze analyze.m 
Assertion failed: (isa<BinaryOperator>(cast<StmtPoint>(C.getPredecessor()
->getLocation()).getStmt())), function PostVisitBinaryOperator, file
/Volumes/MacPro/Projects/OpenSource/llvm/tools/clang/lib/StaticAnalyzer/Checkers/IdempotentOperationChecker.cpp,
line 361.
0  clang             0x0000000100ebe0d2 PrintStackTrace(void*) + 34
[?]
6  clang             0x0000000100484fd5 (anonymous
namespace)::IdempotentOperationChecker::PostVisitBinaryOperator(clang::ento::CheckerContext&,
clang::BinaryOperator const*) + 149
7  clang             0x0000000100483cc4 clang::ento::CheckerVisitor<(anonymous
namespace)::IdempotentOperationChecker>::_PostVisit(clang::ento::CheckerContext&,
clang::Stmt const*) + 100
8  clang             0x000000010046d2a7
clang::ento::ExprEngine::CheckerVisit(clang::Stmt const*,
clang::ento::ExplodedNodeSet&, clang::ento::ExplodedNodeSet&,
clang::ento::ExprEngine::CallbackKind) + 1399
9  clang             0x0000000100473c5c
clang::ento::ExprEngine::VisitBinaryOperator(clang::BinaryOperator const*,
clang::ento::ExplodedNode*, clang::ento::ExplodedNodeSet&) + 3980
[?]
1.    <eof> parser at end of file
2.    analyze.m:8:3: Error evaluating statement
3.    analyze.m:8:3: Error evaluating statement


Some tests show that this assertion is reached only if both
"-analyzer-check-objc-mem" and "-analyzer-check-idempotent-operations" are
passed to the analyzer.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb  1 09:39:10 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  1 Feb 2011 09:39:10 -0600 (CST)
Subject: [LLVMbugs] [Bug 9073] [PCH,
 Variadics] Create corrupted PCH if it includes libc++ <memory> file
In-Reply-To: <bug-9073-206@http.llvm.org/bugs/>
References: <bug-9073-206@http.llvm.org/bugs/>
Message-ID: <20110201153910.B7A022A6C12D@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #2 from Douglas Gregor <dgregor at apple.com> 2011-02-01 09:39:10 CST ---
Fixed in r124662.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb  1 09:53:47 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  1 Feb 2011 09:53:47 -0600 (CST)
Subject: [LLVMbugs] [Bug 9050] access specifier ignored for destructor
In-Reply-To: <bug-9050-206@http.llvm.org/bugs/>
References: <bug-9050-206@http.llvm.org/bugs/>
Message-ID: <20110201155347.9353F2A6C124@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #1 from Douglas Gregor <dgregor at apple.com> 2011-02-01 09:53:47 CST ---
Fixed in r124663 by Alex Miller's patch.

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

From bugzilla-daemon at llvm.org  Tue Feb  1 09:56:36 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  1 Feb 2011 09:56:36 -0600 (CST)
Subject: [LLVMbugs] [Bug 8844] Infinite loop and stack overflow in SemaExpr
 when compiling erroneous C++
In-Reply-To: <bug-8844-206@http.llvm.org/bugs/>
References: <bug-8844-206@http.llvm.org/bugs/>
Message-ID: <20110201155636.867862A6C12E@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #1 from Douglas Gregor <dgregor at apple.com> 2011-02-01 09:56:35 CST ---
This is fixed in 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  Tue Feb  1 11:25:46 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  1 Feb 2011 11:25:46 -0600 (CST)
Subject: [LLVMbugs] [Bug 9117] New: Chromium build broken after r124565
Message-ID: <bug-9117-206@http.llvm.org/bugs/>

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

           Summary: Chromium build broken after r124565
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: hans at chromium.org
                CC: llvmbugs at cs.uiuc.edu


r124565 changed something related to inlining and virtual functions, which
breaks compilation of Chromium/WebKit.


Test case:

template<typename T> void derefIfNotNull(T* ptr) {
  ptr->deref();
}

template<typename T> class RefPtr {
 public:
  RefPtr() : m_ptr(0) {}

  ~RefPtr() {
    derefIfNotNull(m_ptr);
  }

 private:
  T* m_ptr;
};

class Node;

class BaseWithVirtualDtor {
 public:
  virtual ~BaseWithVirtualDtor() {}
};

class MyClass : public BaseWithVirtualDtor {
 public:
  virtual void doStuff() const;

 private:
  RefPtr<Node> m_base;
};

void f(MyClass* x) {
  x->doStuff();
}

Error:

$ ./clang++ -c /tmp/a.cc
/tmp/a.cc:2:6: error: member access into incomplete type 'Node'
  ptr->deref();
     ^
/tmp/a.cc:10:5: note: in instantiation of function template specialization
      'derefIfNotNull<Node>' requested here
    derefIfNotNull(m_ptr);
    ^
/tmp/a.cc:24:7: note: in instantiation of member function
'RefPtr<Node>::~RefPtr'
      requested here
class MyClass : public BaseWithVirtualDtor {
      ^
/tmp/a.cc:17:7: note: forward declaration of 'Node'
class Node;
      ^
1 error generated.


Clang version:

$ ./clang++ --version
clang version 2.9 (trunk 124659)
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  Tue Feb  1 11:43:52 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  1 Feb 2011 11:43:52 -0600 (CST)
Subject: [LLVMbugs] [Bug 9076] Spurious warning about uninitialized variable
 when assigned in condition
In-Reply-To: <bug-9076-206@http.llvm.org/bugs/>
References: <bug-9076-206@http.llvm.org/bugs/>
Message-ID: <20110201174352.8008B2A6C12D@llvm.org>

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

Ted Kremenek <kremenek at apple.com> changed:

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

--- Comment #3 from Ted Kremenek <kremenek at apple.com> 2011-02-01 11:43:52 CST ---
Fixed here: r124666

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb  1 13:13:27 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  1 Feb 2011 13:13:27 -0600 (CST)
Subject: [LLVMbugs] [Bug 9118] New: Windows platform Endian-ness not defined
Message-ID: <bug-9118-206@http.llvm.org/bugs/>

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

           Summary: Windows platform Endian-ness not defined
           Product: libc++
           Version: unspecified
          Platform: PC
        OS/Version: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: All Bugs
        AssignedTo: hhinnant at apple.com
        ReportedBy: vanboxem.ruben at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=6087)
 --> (http://llvm.org/bugs/attachment.cgi?id=6087)
patch to remedy the issue

>From wikipedia
(http://en.wikipedia.org/wiki/Endianness#Endianness_and_operating_systems_on_architectures)
Win32 seems to be little endian on all platforms it exists (x86,x64,IA64).

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 Feb  1 14:23:19 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  1 Feb 2011 14:23:19 -0600 (CST)
Subject: [LLVMbugs] [Bug 9111] SystemZ assembly syntax problem
In-Reply-To: <bug-9111-206@http.llvm.org/bugs/>
References: <bug-9111-206@http.llvm.org/bugs/>
Message-ID: <20110201202320.022482A6C12C@llvm.org>

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

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

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

--- Comment #3 from Anton Korobeynikov <asl at math.spbu.ru> 2011-02-01 14:23:19 CST ---
Looks good to me. Committed as r124679. 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 Feb  1 15:03:29 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  1 Feb 2011 15:03:29 -0600 (CST)
Subject: [LLVMbugs] [Bug 9119] New: no error calling non-const method on
	const object
Message-ID: <bug-9119-206@http.llvm.org/bugs/>

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

           Summary: no error calling non-const method on const object
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: nlewycky at google.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


Testcase:

  struct Struct {
   void Func() {}
  };

  int main() {
   const Struct s = {};
   void (Struct::*func_ptr)() = &Struct::Func;
   (s.*func_ptr)();
   return 0;
  }

's' is const, then we call a non-const method on it. Clang emits no error, GCC
and Comeau do. Here's GCC:

b3410310.cc: In function ?int main()?:
b3410310.cc:8: error: invalid conversion from ?const Struct*? to ?Struct*?

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb  1 16:31:31 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  1 Feb 2011 16:31:31 -0600 (CST)
Subject: [LLVMbugs] [Bug 9081] Build failure on arm
In-Reply-To: <bug-9081-206@http.llvm.org/bugs/>
References: <bug-9081-206@http.llvm.org/bugs/>
Message-ID: <20110201223131.615622A6C12C@llvm.org>

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

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

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

--- Comment #5 from Bob Wilson <bob.wilson at apple.com> 2011-02-01 16:31:30 CST ---
I attempted a fix in svn r124694.  Please let me know if that doesn't 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  Tue Feb  1 16:38:53 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  1 Feb 2011 16:38:53 -0600 (CST)
Subject: [LLVMbugs] [Bug 9120] New: not taking advantage of known pointer
	alignment
Message-ID: <bug-9120-206@http.llvm.org/bugs/>

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

           Summary: not taking advantage of known pointer alignment
           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: nlewycky at google.com
                CC: llvmbugs at cs.uiuc.edu


This is gcc pr 47579:

  #include <vector>
  extern void b1(), b2();
  void foo(const std::vector<int>& v) { if (v.size() == 0) b1(); else b2(); }

which demonstrates a really neat missed optimization:

define void @_Z3fooRKSt6vectorIiSaIiEE(%"class.std::vector"* nocapture %v) {
entry:
  %tmp2.i = getelementptr inbounds %"class.std::vector"* %v, i64 0, i32 0, i64
8
  %0 = bitcast i8* %tmp2.i to i32**
  %tmp3.i = load i32** %0, align 8, !tbaa !0
  %tmp5.i = bitcast %"class.std::vector"* %v to i32**
  %tmp6.i = load i32** %tmp5.i, align 8, !tbaa !0
  %sub.ptr.lhs.cast.i = ptrtoint i32* %tmp3.i to i64
  %sub.ptr.rhs.cast.i = ptrtoint i32* %tmp6.i to i64
  %sub.ptr.sub.i = sub i64 %sub.ptr.lhs.cast.i, %sub.ptr.rhs.cast.i
  %cmp = icmp ult i64 %sub.ptr.sub.i, 4
  br i1 %cmp, label %if.then, label %if.else
  [...]

Is the difference between the pointers (%tmp3.i, %tmp6.i) less than 4? Well,
the pointers are aligned so that's always true. However, LLVM doesn't know
that.

We mark pointer alignment at the use (load/store) instead of the definition. In
this case, I think we should add an alignment field to ptrtoint. Clang could
set this based on user annotations or the minimum alignment of the type.

If we need a source annotation to make this work, we should make sure libc++
has it 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 Feb  1 17:02:59 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  1 Feb 2011 17:02:59 -0600 (CST)
Subject: [LLVMbugs] [Bug 9121] New: Leaf functions that don't use the frame
 set up a frame anyway
Message-ID: <bug-9121-206@http.llvm.org/bugs/>

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

           Summary: Leaf functions that don't use the frame set up a frame
                    anyway
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: X86
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: jyasskin at google.com
                CC: nicholas at mxc.ca, llvmbugs at cs.uiuc.edu


For example:

test.cc:
#include <vector>
long foo(std::vector<int>&v) {
  return v.size();
}


g++-4.6svn -S test.cc -o - -O2 -m32:
_Z3fooRSt6vectorIiSaIiEE:
.LFB442:
        movl    4(%esp), %edx
        movl    4(%edx), %eax
        subl    (%edx), %eax
        sarl    $2, %eax
        ret

g++-4.6svn -S test.cc -o - -O2 -m64:
_Z3fooRSt6vectorIiSaIiEE:
.LFB442:
        movq    8(%rdi), %rax
        subq    (%rdi), %rax
        sarq    $2, %rax
        ret


clang++ -S test.cc -o - -O2 -m32
_Z3fooRSt6vectorIiSaIiEE:               # @_Z3fooRSt6vectorIiSaIiEE
# BB#0:                                 # %entry
        pushl   %ebp
        movl    %esp, %ebp
        movl    8(%ebp), %ecx
        movl    4(%ecx), %eax
        subl    (%ecx), %eax
        sarl    $2, %eax
        popl    %ebp
        ret

clang++ -S test.cc -o - -O2 -m64:
_Z3fooRSt6vectorIiSaIiEE:               # @_Z3fooRSt6vectorIiSaIiEE
.Leh_func_begin0:
# BB#0:                                 # %entry
        pushq   %rbp
.Ltmp0:
        movq    %rsp, %rbp
.Ltmp1:
        movq    8(%rdi), %rax
        subq    (%rdi), %rax
        sarq    $2, %rax
        popq    %rbp
        ret

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb  2 00:39:06 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  2 Feb 2011 00:39:06 -0600 (CST)
Subject: [LLVMbugs] [Bug 9122] New: -Wuninitialized false positive due to
 control dependency.
Message-ID: <bug-9122-206@http.llvm.org/bugs/>

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

           Summary: -Wuninitialized false positive due to control
                    dependency.
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Static Analyzer
        AssignedTo: kremenek at apple.com
        ReportedBy: nicolasweber at gmx.de
                CC: llvmbugs at cs.uiuc.edu


Spun off from http://llvm.org/bugs/show_bug.cgi?id=9063#c11 (see there for
attachment):

 Here's another example that looks fairly similar that I
still see with your patch.

Compile like this:
 ~/src/llvm-svn/Release+Asserts/bin/clang -arch i386 -c repro.ii
-Wuninitialized

Warnings:
In file included from
/Volumes/MacintoshHD2/src/chrome-git/src/chrome/common/common_param_traits.cc:1:
/Volumes/MacintoshHD2/src/chrome-git/src/chrome/common/common_param_traits.cc:662:3:
warning: use of uninitialized variable 'last_accessed' [-Wuninitialized]
  double last_accessed;
  ^~~~~~~~~~~~~~~~~~~~
/Volumes/MacintoshHD2/src/chrome-git/src/chrome/common/common_param_traits.cc:672:48:
note: variable 'last_accessed' is possibly uninitialized when used here
    p->last_accessed = base::Time::FromDoubleT(last_accessed);
                                               ^~~~~~~~~~~~~
/Volumes/MacintoshHD2/src/chrome-git/src/chrome/common/common_param_traits.cc:662:23:
note: add initialization to silence this warning
  double last_accessed;
                      ^
                       = 0.0
/Volumes/MacintoshHD2/src/chrome-git/src/chrome/common/common_param_traits.cc:661:3:
warning: use of uninitialized variable 'last_modified' [-Wuninitialized]
  double last_modified;
  ^~~~~~~~~~~~~~~~~~~~
/Volumes/MacintoshHD2/src/chrome-git/src/chrome/common/common_param_traits.cc:671:48:
note: variable 'last_modified' is possibly uninitialized when used here
    p->last_modified = base::Time::FromDoubleT(last_modified);
                                               ^~~~~~~~~~~~~
/Volumes/MacintoshHD2/src/chrome-git/src/chrome/common/common_param_traits.cc:661:23:
note: add initialization to silence this warning
  double last_modified;
                      ^
                       = 0.0
/Volumes/MacintoshHD2/src/chrome-git/src/chrome/common/common_param_traits.cc:663:3:
warning: use of uninitialized variable 'creation_time' [-Wuninitialized]
  double creation_time;
  ^~~~~~~~~~~~~~~~~~~~
/Volumes/MacintoshHD2/src/chrome-git/src/chrome/common/common_param_traits.cc:673:48:
note: variable 'creation_time' is possibly uninitialized when used here
    p->creation_time = base::Time::FromDoubleT(creation_time);
                                               ^~~~~~~~~~~~~
/Volumes/MacintoshHD2/src/chrome-git/src/chrome/common/common_param_traits.cc:663:23:
note: add initialization to silence this warning
  double creation_time;
                      ^
                       = 0.0
3 warnings generated.



Relevant code:
bool ParamTraits<base::PlatformFileInfo>::Read(
    const Message* m, void** iter, param_type* p) {
  double last_modified;
  double last_accessed;
  double creation_time;
  bool result =
      ReadParam(m, iter, &p->size) &&
      ReadParam(m, iter, &p->is_directory) &&
      ReadParam(m, iter, &last_modified) &&
      ReadParam(m, iter, &last_accessed) &&
      ReadParam(m, iter, &creation_time);
  if (result) {
    p->last_modified = base::Time::FromDoubleT(last_modified);
    p->last_accessed = base::Time::FromDoubleT(last_accessed);
    p->creation_time = base::Time::FromDoubleT(creation_time);
  }
  return result;
}




This example is much harder because it involves tracking a control-dependency,
e.g.:

 bool result = ...
 ...
 if (result) {
   ...
 }

The static analyzer handles this easily, but I'm not certain how much
control-dependencies like this we should attempt (if any) to model with
-Wuninitialized.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb  2 00:43:14 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  2 Feb 2011 00:43:14 -0600 (CST)
Subject: [LLVMbugs] [Bug 9121] Leaf functions that don't use the frame set
 up a frame anyway
In-Reply-To: <bug-9121-206@http.llvm.org/bugs/>
References: <bug-9121-206@http.llvm.org/bugs/>
Message-ID: <20110202064314.5F28F2A6C124@llvm.org>

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

Nick Lewycky <nicholas at mxc.ca> changed:

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

--- Comment #2 from Nick Lewycky <nicholas at mxc.ca> 2011-02-02 00:43:14 CST ---
Thanks Chris! Fixed in r124718.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb  2 02:32:51 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  2 Feb 2011 02:32:51 -0600 (CST)
Subject: [LLVMbugs] [Bug 9123] New: [REGRESSION] Crash while compiling
 snow.c from FFmpeg
Message-ID: <bug-9123-206@http.llvm.org/bugs/>

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

           Summary: [REGRESSION] Crash while compiling snow.c from FFmpeg
           Product: clang
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: ismail at namtrac.org
                CC: llvmbugs at cs.uiuc.edu


[~/Sources/ffmpeg]> clang -O2 -c snow.i
Instruction does not dominate all uses!
  %lsr.iv.next2592 = add i32 %lsr.iv2591, 1
  %tmp2593 = sext i32 %lsr.iv.next2592 to i64
Instruction does not dominate all uses!
  %tmp2593 = sext i32 %lsr.iv.next2592 to i64
  %tmp2594 = add i64 %tmp2377, %tmp2593
Instruction does not dominate all uses!
  %tmp2594 = add i64 %tmp2377, %tmp2593
  %scevgep2598 = getelementptr i8* %scevgep2597, i64 %tmp2594
Instruction does not dominate all uses!
  %lsr.iv.next2569 = add i32 %lsr.iv2568, 1
  %tmp2570 = sext i32 %lsr.iv.next2569 to i64
Instruction does not dominate all uses!
  %tmp2570 = sext i32 %lsr.iv.next2569 to i64
  %tmp2571 = add i64 %tmp2377, %tmp2570
Instruction does not dominate all uses!
  %tmp2571 = add i64 %tmp2377, %tmp2570
  %scevgep2575 = getelementptr i8* %scevgep2574, i64 %tmp2571
Broken module found, compilation aborted!
0  clang             0x0000000101519df2
llvm::SmallVectorTemplateBase<llvm_regmatch_t, false>::grow(unsigned long) +
754
1  clang             0x000000010151ac43
llvm::SmallVectorTemplateBase<llvm_regmatch_t, false>::grow(unsigned long) +
4419
2  libSystem.B.dylib 0x00007fff885db67a _sigtramp + 26
3  clang             0x0000000100000000 __dso_handle + 0
4  clang             0x000000010151a216
llvm::SmallVectorTemplateBase<llvm_regmatch_t, false>::grow(unsigned long) +
1814
5  clang             0x000000010147dfb4 llvm::CallbackVH::deleted() + 90708
6  clang             0x000000010144bc20 llvm::BasicBlockPass::~BasicBlockPass()
+ 32240
7  clang             0x000000010144bd3b llvm::BasicBlockPass::~BasicBlockPass()
+ 32523
8  clang             0x000000010144d8bf llvm::BasicBlockPass::~BasicBlockPass()
+ 39567
9  clang             0x000000010144dbb3 llvm::BasicBlockPass::~BasicBlockPass()
+ 40323
10 clang             0x000000010144dc8d llvm::BasicBlockPass::~BasicBlockPass()
+ 40541
11 clang             0x000000010018570a clang::PCHGenerator::~PCHGenerator() +
5866
12 clang             0x00000001002b296e
clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) + 286
13 clang             0x00000001002e19a9 llvm::IRBuilder<true,
llvm::ConstantFolder, llvm::IRBuilderDefaultInserter<true>
>::CreateAdd(llvm::Value*, llvm::Value*, llvm::Twine const&) + 1033
14 clang             0x00000001002b16bc llvm::IRBuilder<true,
llvm::ConstantFolder, llvm::IRBuilderDefaultInserter<true>
>::CreateIsNull(llvm::Value*, llvm::Twine const&) + 3980
15 clang             0x0000000100054509 llvm::DenseMap<clang::IdentifierInfo
const*, unsigned int, llvm::DenseMapInfo<clang::IdentifierInfo const*>,
llvm::DenseMapInfo<unsigned int> >::grow(unsigned int) + 7673
16 clang             0x0000000100025532 std::_Rb_tree<std::string, std::string,
std::_Identity<std::string>, std::less<std::string>,
std::allocator<std::string> >::_M_insert_unique(std::string const&) + 2002
17 clang             0x000000010001d1ba
std::vector<llvm::PassRegistrationListener*,
std::allocator<llvm::PassRegistrationListener*>
>::_M_insert_aux(__gnu_cxx::__normal_iterator<llvm::PassRegistrationListener**,
std::vector<llvm::PassRegistrationListener*,
std::allocator<llvm::PassRegistrationListener*> > >,
llvm::PassRegistrationListener* const&) + 11258
18 clang             0x0000000100024564 std::vector<std::string,
std::allocator<std::string> >::operator=(std::vector<std::string,
std::allocator<std::string> > const&) + 12196
19 clang             0x000000010001bad4
std::vector<llvm::PassRegistrationListener*,
std::allocator<llvm::PassRegistrationListener*>
>::_M_insert_aux(__gnu_cxx::__normal_iterator<llvm::PassRegistrationListener**,
std::vector<llvm::PassRegistrationListener*,
std::allocator<llvm::PassRegistrationListener*> > >,
llvm::PassRegistrationListener* const&) + 5396
Stack dump:
0.    Program arguments: /usr/local/bin/clang -cc1 -triple
x86_64-apple-darwin10.0.0 -emit-obj -disable-free -main-file-name snow.i
-pic-level 1 -mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu core2
-target-linker-version 97.17 -resource-dir /usr/local/bin/../lib/clang/2.9 -O2
-ferror-limit 19 -fmessage-length 120 -stack-protector 1 -fblocks
-fdiagnostics-show-option -fcolor-diagnostics -o snow.o -x cpp-output snow.i 
1.    <eof> parser at end of file
2.    Code generation
3.    Running pass 'Function Pass Manager' on module 'snow.i'.
4.    Running pass 'Module Verifier' on function '@decode_frame'
clang: error: unable to execute command: Illegal instruction
clang: error: clang frontend command failed due to signal 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  Wed Feb  2 03:17:46 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  2 Feb 2011 03:17:46 -0600 (CST)
Subject: [LLVMbugs] [Bug 6065] ARM JIT should support ARMCompilationCallback
	in thumb2
In-Reply-To: <bug-6065-206@http.llvm.org/bugs/>
References: <bug-6065-206@http.llvm.org/bugs/>
Message-ID: <20110202091746.EF3142A6C12F@llvm.org>

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |xerxes at zafena.se
         Resolution|                            |DUPLICATE

--- Comment #6 from Xerxes R?nby <xerxes at zafena.se> 2011-02-02 03:17:45 CST ---
fixed in svn r124694

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

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb  2 04:19:51 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  2 Feb 2011 04:19:51 -0600 (CST)
Subject: [LLVMbugs] [Bug 9117] Chromium build broken after r124565
In-Reply-To: <bug-9117-206@http.llvm.org/bugs/>
References: <bug-9117-206@http.llvm.org/bugs/>
Message-ID: <20110202101951.C59722A6C124@llvm.org>

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

Hans Wennborg <hans at chromium.org> changed:

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

--- Comment #2 from Hans Wennborg <hans at chromium.org> 2011-02-02 04:19:51 CST ---
(In reply to comment #1)
> Is this a duplicate of 9114?

Yes, I think it's the same thing.

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

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb  2 09:55:46 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  2 Feb 2011 09:55:46 -0600 (CST)
Subject: [LLVMbugs] [Bug 9124] New: Allows using-declaration to refer to
 scoped enumerator
Message-ID: <bug-9124-206@http.llvm.org/bugs/>

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

           Summary: Allows using-declaration to refer to scoped enumerator
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++0x
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: schaub.johannes at googlemail.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


Clang is supposed to reject the below, but doesn't

enum class A { B };
int main() {
  using A::B; // should be an error
}

Although the spec (N3225) doesn't say so currently (DR already filed), clang
should presumably also reject referring to an unscoped enumerator in a using
declaration: 

enum A { B };
int main() {
  using A::B; // presumably should be error too. 
}

I think best may be to forbid the using declaration of having a nested name
specifier referring to an enumeration.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb  2 11:27:29 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  2 Feb 2011 11:27:29 -0600 (CST)
Subject: [LLVMbugs] [Bug 9125] New: Different behaviour amongst Clang
 versions when sending a message to an assignment expression
Message-ID: <bug-9125-206@http.llvm.org/bugs/>

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

           Summary: Different behaviour amongst Clang versions when
                    sending a message to an assignment expression
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: macbavarious at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Mike Ash?s proposed the following [1]:

?One line property initialization with no autorelease: [self.property =
[[SomeClass alloc] init] release];?

This can be reduced to

[obj.property = rvalue method];

Clang 1.5 sends ?method? to obj.property whereas Clang 1.6 and GCC 4.2.1 send
?method? to rvalue. In the case of copy properties and assignment of a mutable
object to a property of immutable type, Mike Ash?s proposal leaks the mutable
object and releases the backing instance variable on Clang 1.5. In general, it
doesn?t work on Clang 1.5 unless the getter method returns the same object as
the argument that was passed to the setter method.

Reading the C standard, I?m tempted to think Clang 1.5 is correct:

?6.5.16.3 (?) An assignment expression has the value of the left operand after
the assignment (?)?

On the other hand, sending the message to rvalue saves one objc_msgSend() call
for obj.property?s getter method. In fact, as David Smith?s pointed out, for
multiple assignments such as

obj.property = obj.property2 = obj.property3 = rvalue;

Clang 1.6 and GCC 4.2.1 send three ObjC messages (three setters) whereas Clang
1.5 sends five message (three setters, two getters).

The following program can be used to test this behaviour:

#import <Foundation/Foundation.h>

@interface Test : NSObject { id prop; }
@property (readwrite, nonatomic, retain) id prop;
@end

@implementation Test
@synthesize prop;

- (id)prop {
    NSLog(@"getter");
    return prop;
}
@end

int main()
{
    Test *t = [[Test alloc] init];
    NSLog(@"message to single assignment expression");
    [t.prop = t prop];
    NSLog(@"multiple assignments:");
    t.prop = t.prop = t.prop = t;
    return 0;
}

When built with Clang 1.5, the output is

message to single assignment expression
getter
getter
multiple assignments:
getter
getter

When built with Clang 1.6 or GCC 4.2.1, the output is

message to single assignment expression
getter
multiple assignments:

Since there?s no Objective-C specification, which behaviour is
expected/correct, or should this not be allowed at all?

This has been posted to objc-language at lists.apple.com [2].

[1] http://twitter.com/mikeash/status/32651143389642752
[2] http://lists.apple.com/archives/Objc-language/2011/Feb/msg00000.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  Wed Feb  2 11:36:38 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  2 Feb 2011 11:36:38 -0600 (CST)
Subject: [LLVMbugs] [Bug 9106] qualify calls to addressof
In-Reply-To: <bug-9106-206@http.llvm.org/bugs/>
References: <bug-9106-206@http.llvm.org/bugs/>
Message-ID: <20110202173638.5B12E2A6C124@llvm.org>

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

Howard Hinnant <hhinnant at apple.com> changed:

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

--- Comment #1 from Howard Hinnant <hhinnant at apple.com> 2011-02-02 11:36:38 CST ---
Committed revision 124726.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb  2 13:29:42 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  2 Feb 2011 13:29:42 -0600 (CST)
Subject: [LLVMbugs] [Bug 9126] New: __float128 crashes the compiler /
	optimizer
Message-ID: <bug-9126-206@http.llvm.org/bugs/>

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

           Summary: __float128 crashes the compiler / optimizer
           Product: dragonegg
           Version: 2.8
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: New Bugs
        AssignedTo: baldrick at free.fr
        ReportedBy: larrybartholdi at yahoo.com
                CC: llvmbugs at cs.uiuc.edu


I've heard about llvm only 10 minutes ago, and tried something on the website's
"online compiler" 5 minutes ago:

#include <stdio.h>
#include <stdlib.h>

__float128 factorial(__float128 X) {
  if (X == 0.0) return 1.0;
  return X*factorial(X-1);
}

int main(int argc, char **argv) {
  printf("%LLg\n", factorial(atoi(argv[1])));
}

(I had initially tried float128 and _float128 types, which don't seem to be
recognized at all).

This crashes the compiler / optimizer:

/tmp/webcompile/_22203_0.c: In function 'factorial':
/tmp/webcompile/_22203_0.c:4: internal compiler error: 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  Wed Feb  2 15:04:41 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  2 Feb 2011 15:04:41 -0600 (CST)
Subject: [LLVMbugs] [Bug 9127] New: Load not being folded
Message-ID: <bug-9127-206@http.llvm.org/bugs/>

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

           Summary: Load not being folded
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: X86
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: rafael.espindola at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Given
-------------
extern double sin( double );
typedef double (*UnaryFunType)(double);
struct Entry {
  double in;
  double out;
};
double foobar(double d, struct Entry *x) {
  if (d == x->in)
    return x->out;
  return  d;
}
--------------

gcc will produce

    ucomisd    (%rdi), %xmm0
    jne    L2
    jp    L2
    movsd    8(%rdi), %xmm0
    rep ; ret

llvm produces

        movsd   (%rdi), %xmm1
        ucomisd %xmm0, %xmm1
        jne     LBB0_2
        jp      LBB0_2
        movsd   8(%rdi), %xmm0
        ret

Note that gcc folded the load into ucomisd.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb  2 16:42:28 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  2 Feb 2011 16:42:28 -0600 (CST)
Subject: [LLVMbugs] [Bug 9128] New: Assigning a pointer to _Bool should give
	a warning
Message-ID: <bug-9128-206@http.llvm.org/bugs/>

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

           Summary: Assigning a pointer to _Bool should give a warning
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: tss at iki.fi
                CC: llvmbugs at cs.uiuc.edu


I'd expect this to give two warnings, but none is given:

_Bool foo(void) {
  _Bool x = (void *)0;
  return (void *)0;
}

Not having this warning already caused a bug in my program, so this makes _Bool
type even worse to me than using "int" as the boolean type.

I guess this might be because C99 says:

"When any scalar value is converted to _Bool, the result is 0 if the value
compares equal to 0; otherwise, the result is 1."

If -Wall isn't good enough place for this, maybe a new -Wstrict-bool? (Actually
I'd prefer such warning to check for other things about booleans too, but
that's another 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  Wed Feb  2 17:40:24 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  2 Feb 2011 17:40:24 -0600 (CST)
Subject: [LLVMbugs] [Bug 9129] New: Compiling relative paths with parent
 directories (../../file.c) broken
Message-ID: <bug-9129-206@http.llvm.org/bugs/>

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

           Summary: Compiling relative paths with parent directories
                    (../../file.c) broken
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: tss at iki.fi
                CC: llvmbugs at cs.uiuc.edu


I have a test.c that works:

~% clang -c test.c 

and this works:

~% mkdir m && cd m
~/m% clang -c ../test.c

but:

~/m/m% clang -c ../../test.c -Wall
error: error reading '../../test.c'
1 error 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 Feb  2 20:08:54 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  2 Feb 2011 20:08:54 -0600 (CST)
Subject: [LLVMbugs] [Bug 9114] Clang a bit too strict about types being
	complete
In-Reply-To: <bug-9114-206@http.llvm.org/bugs/>
References: <bug-9114-206@http.llvm.org/bugs/>
Message-ID: <20110203020854.125FD2A6C124@llvm.org>

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

Anders Carlsson <andersca at mac.com> changed:

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

--- Comment #2 from Anders Carlsson <andersca at mac.com> 2011-02-02 20:08:53 CST ---
Committed revision 124768.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb  2 22:02:30 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  2 Feb 2011 22:02:30 -0600 (CST)
Subject: [LLVMbugs] [Bug 9127] Load not being folded
In-Reply-To: <bug-9127-206@http.llvm.org/bugs/>
References: <bug-9127-206@http.llvm.org/bugs/>
Message-ID: <20110203040230.377512A6C12D@llvm.org>

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

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

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

--- Comment #3 from Rafael ?vila de Esp?ndola <rafael.espindola at gmail.com> 2011-02-02 22:02:29 CST ---
Fixed in 124773.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb  3 00:19:42 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu,  3 Feb 2011 00:19:42 -0600 (CST)
Subject: [LLVMbugs] [Bug 9130] New: missing symbol definition
Message-ID: <bug-9130-206@http.llvm.org/bugs/>

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

           Summary: missing symbol definition
           Product: clang
           Version: trunk
          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


When compiling

class nsOggCodecState {
  virtual int StartTime() {
    return -1;
  }
};
class nsVorbisState : public nsOggCodecState {
  virtual ~nsVorbisState();
};
nsVorbisState::~nsVorbisState() {
}

clang will produce

U __ZN15nsOggCodecState9StartTimeEv

gcc produces

S __ZN15nsOggCodecState9StartTimeEv

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb  3 00:37:26 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu,  3 Feb 2011 00:37:26 -0600 (CST)
Subject: [LLVMbugs] [Bug 9130] missing symbol definition
In-Reply-To: <bug-9130-206@http.llvm.org/bugs/>
References: <bug-9130-206@http.llvm.org/bugs/>
Message-ID: <20110203063726.848912A6C12E@llvm.org>

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

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> 2011-02-03 00:37:26 CST ---
Fixed by reverting 124768.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb  3 00:37:38 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu,  3 Feb 2011 00:37:38 -0600 (CST)
Subject: [LLVMbugs] [Bug 9114] Clang a bit too strict about types being
	complete
In-Reply-To: <bug-9114-206@http.llvm.org/bugs/>
References: <bug-9114-206@http.llvm.org/bugs/>
Message-ID: <20110203063738.514B72A6C12E@llvm.org>

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

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

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

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

From bugzilla-daemon at llvm.org  Thu Feb  3 04:27:05 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu,  3 Feb 2011 04:27:05 -0600 (CST)
Subject: [LLVMbugs] [Bug 9131] New: clang or static analyser should warn
 about signed arithmetic overflow
Message-ID: <bug-9131-206@http.llvm.org/bugs/>

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

           Summary: clang or static analyser should warn about signed
                    arithmetic overflow
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: baldrick at free.fr
                CC: llvmbugs at cs.uiuc.edu


GAP (http://www.gap-system.org/) uses the following idiom to try to detect
overflowing multiplication.  It is wrong because it uses undefined behaviour
(the result of an overflowing signed multiplication).  It would be great if
either the compiler or the static analyser would warn about this.

int mul_overflows(int a, int b) {
  int mul = a * b;
  // Wrong attempt to detect overflow:
  return (mul / b) != a;
}

This is particularly important because the optimizers convert this to
"return false;"!

Here are the real code snippets from GAP (variables have type Int, which
is long int):

...
        ex  = ex * pow;

        /* check that n*pow fits into the exponent                         */
        if ( ex/pow!=exs || (0<ex && expm<ex) || (ex<0 && expm<-ex) ) {
...

static inline Obj prod_intobjs(Int l, Int r)
{
  Int prod;
  if (l == (Int)INTOBJ_INT(0) || r == (Int)INTOBJ_INT(0))
    return INTOBJ_INT(0);
  if (l == (Int)INTOBJ_INT(1))
    return (Obj)r;
  if (r == (Int)INTOBJ_INT(1))
    return (Obj)l;
  prod = ((Int)l >> 2) * ((Int)r-1)+1;
  if ((prod << 1)>> 1 !=  prod)
    return (Obj) 0;
  if ((((Int)l)<<HALF_A_WORD)>>HALF_A_WORD == (Int) l &&
      (((Int)r)<<HALF_A_WORD)>>HALF_A_WORD == (Int) r)
    return (Obj) prod;
  if ((prod -1) / (l >> 2) == r-1)
    return (Obj) prod;
  else
    return (Obj) 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  Thu Feb  3 09:54:21 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu,  3 Feb 2011 09:54:21 -0600 (CST)
Subject: [LLVMbugs] [Bug 9132] New: clang accepts declarators other than a
 literal 'auto' as the return type of a function with a trailing-return-type
Message-ID: <bug-9132-206@http.llvm.org/bugs/>

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

           Summary: clang accepts declarators other than a literal 'auto'
                    as the return type of a function with a
                    trailing-return-type
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++0x
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: richard-llvm at metafoo.co.uk
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


clang accepts this:

  auto *f() -> int;

and declares f to have type "int*()".


clang crashes on this:

  auto *main() -> int;

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb  3 14:03:09 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu,  3 Feb 2011 14:03:09 -0600 (CST)
Subject: [LLVMbugs] [Bug 9133] New: clang emits crashing code at -O0
Message-ID: <bug-9133-206@http.llvm.org/bugs/>

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

           Summary: clang emits crashing code at -O0
           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


I believe this was introduced fairly recently, probably in the last 5 days.

[regehr at gamow tmp002]$ clang -O0 small.c -o small
[regehr at gamow tmp002]$ ./small 
Segmentation fault
[regehr at gamow tmp002]$ clang -v

clang version 2.9 (trunk 124809)
Target: x86_64-unknown-linux-gnu
Thread model: posix

[regehr at gamow tmp002]$ cat small.c


static int g_1 = 0;
static int g_2 = 0;
static int *g_3 = 0;

static int *foo(int p)
{
   char l_1[7][2][4];
   int *l_2[5];
   int l_3;
   return &g_2;
}

int main(int argc, char* argv[])
{
   g_3 = foo(1);
   g_1 = *g_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  Thu Feb  3 14:16:06 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu,  3 Feb 2011 14:16:06 -0600 (CST)
Subject: [LLVMbugs] [Bug 9134] New: register spilled to wrong location
Message-ID: <bug-9134-206@http.llvm.org/bugs/>

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

           Summary: register spilled to wrong location
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: SystemZ
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: bagel99 at gmail.com
                CC: llvmbugs at cs.uiuc.edu


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

When registers are spilled around call sites, the first spill is to the wrong
stack offset.

The result of the test code produced by "llc -march=systemz" is:

zalloc:                                 # @zalloc
    stmg    %r14, %r15, 112(%r15)
    stg    %r2, 168(%r15)        # <--exceeds frame size
                    # spills to old %r15
    aghi    %r15, -184        # expand frame 160+24
    brasl    %r14, malloc
    stg    %r2, 160(%r15)        # superfluous but OK
    lg    %r4, 168(%r15)        # <--reload from new r15
    lghi    %r3, 0
    brasl    %r14, memset
    lg    %r1, 160(%r15)
    stg    %r1, 176(%r15)
    lg    %r2, 176(%r15)
    lmg    %r14, %r15, 296(%r15)
    br    %r14

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb  3 14:26:13 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu,  3 Feb 2011 14:26:13 -0600 (CST)
Subject: [LLVMbugs] [Bug 9135] New: abort: Unsupported regclass to store
Message-ID: <bug-9135-206@http.llvm.org/bugs/>

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

           Summary: abort: Unsupported regclass to store
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: SystemZ
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: bagel99 at gmail.com
                CC: llvmbugs at cs.uiuc.edu


This was produced by a very large program and failed in a large function with
nested switch statements.  The test case is very large, so in the spirt of
Fermat, I have omitted it.  It is curious that the *.ll only aborts if it is
first optimized by "opt -std-compile-opts".

When I gdb llc, I can see that SystemZInstrInfo::storeRegToStackSlot is being
called with a TargetRegisterClass of CCR (i.e. the PSW).

Here is the abort backtrace:
Unsupported regclass to store
UNREACHABLE executed at SystemZInstrInfo.cpp:63!
0  llc             0x0000000000ea643f
1  llc             0x0000000000ea6f7a
2  libpthread.so.0 0x0000003f4420f3c0
3  libc.so.6       0x0000003f43a34085 gsignal + 53
4  libc.so.6       0x0000003f43a35a36 abort + 390
5  llc             0x0000000000e90d24 llvm::llvm_unreachable_internal(char
const*, char const*, unsigned int) + 356
6  llc             0x00000000005f9a05
7  llc             0x0000000000b9b48c
llvm::TargetInstrInfo::foldMemoryOperand(llvm::ilist_iterator<llvm::MachineInstr>,
llvm::SmallVectorImpl<unsigned int> const&, int) const + 1068
8  llc             0x0000000000bf8006
llvm::LiveIntervals::tryFoldMemoryOperand(llvm::MachineInstr*&,
llvm::VirtRegMap&, llvm::MachineInstr*, llvm::SlotIndex,
llvm::SmallVector<unsigned int, 2u>&, bool, int, unsigned int) + 438
9  llc             0x0000000000bf840a
llvm::LiveIntervals::rewriteInstructionForSpills(llvm::LiveInterval const&,
llvm::VNInfo const*, bool, llvm::SlotIndex, llvm::SlotIndex,
llvm::MachineInstr*, llvm::MachineInstr*, llvm::MachineInstr*, unsigned int,
int, bool, bool, bool, bool, llvm::VirtRegMap&, llvm::TargetRegisterClass
const*, llvm::SmallVector<int, 4u>&, llvm::MachineLoopInfo const*, unsigned
int&, unsigned int, bool&, bool&, llvm::DenseMap<unsigned int, unsigned int,
llvm::DenseMapInfo<unsigned int>, llvm::DenseMapInfo<unsigned int> >&,
std::vector<llvm::LiveInterval*, std::allocator<llvm::LiveInterval*> >&) + 746
10 llc             0x0000000000bf9ffc
llvm::LiveIntervals::rewriteInstructionsForSpills(llvm::LiveInterval const&,
bool, llvm::LiveRange const*&, llvm::MachineInstr*, llvm::MachineInstr*,
unsigned int, int, bool, bool, bool, bool, llvm::VirtRegMap&,
llvm::TargetRegisterClass const*, llvm::SmallVector<int, 4u>&,
llvm::MachineLoopInfo const*, llvm::BitVector&, llvm::DenseMap<unsigned int,
std::vector<llvm::LiveIntervals::SRInfo,
std::allocator<llvm::LiveIntervals::SRInfo> >, llvm::DenseMapInfo<unsigned
int>, llvm::DenseMapInfo<std::vector<llvm::LiveIntervals::SRInfo,
std::allocator<llvm::LiveIntervals::SRInfo> > > >&, llvm::BitVector&,
llvm::DenseMap<unsigned int, std::vector<llvm::LiveIntervals::SRInfo,
std::allocator<llvm::LiveIntervals::SRInfo> >, llvm::DenseMapInfo<unsigned
int>, llvm::DenseMapInfo<std::vector<llvm::LiveIntervals::SRInfo,
std::allocator<llvm::LiveIntervals::SRInfo> > > >&, llvm::DenseMap<unsigned
int, unsigned int, llvm::DenseMapInfo<unsigned int>,
llvm::DenseMapInfo<unsigned int> >&, std::vector<llvm::LiveInterval*,
std::allocator<llvm::LiveInterval*> >&) + 3020
11 llc             0x0000000000bfbfa6
llvm::LiveIntervals::addIntervalsForSpills(llvm::LiveInterval const&,
llvm::SmallVectorImpl<llvm::LiveInterval*> const&, llvm::MachineLoopInfo
const*, llvm::VirtRegMap&) + 3078
12 llc             0x0000000000b6a14f
13 llc             0x0000000000b155d4
14 llc             0x0000000000b18dff
15 llc             0x0000000000b1a05d
16 llc             0x0000000000ddfc97
llvm::FPPassManager::runOnFunction(llvm::Function&) + 599
17 llc             0x0000000000ddfd5b
llvm::FPPassManager::runOnModule(llvm::Module&) + 75
18 llc             0x0000000000ddf827
llvm::MPPassManager::runOnModule(llvm::Module&) + 551
19 llc             0x0000000000ddf977 llvm::PassManagerImpl::run(llvm::Module&)
+ 167
20 llc             0x000000000053ea3d main + 4701
21 libc.so.6       0x0000003f43a1ee7d __libc_start_main + 253
22 llc             0x000000000053c9a9
Stack dump:
0.    Program arguments: /home/bgl/work/llvm/Release+Asserts/bin/llc
-march=systemz main-s390x.bc 
1.    Running pass 'Function Pass Manager' on module 'main-s390x.bc'.
2.    Running pass 'Linear Scan Register Allocator' on function '@lex_Next'
Aborted

I also have the output of "llc -march=systemz -debug" if that would be helpful.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb  3 17:16:24 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu,  3 Feb 2011 17:16:24 -0600 (CST)
Subject: [LLVMbugs] [Bug 9136] New: llvm-config does not like being symlinked
Message-ID: <bug-9136-206@http.llvm.org/bugs/>

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

           Summary: llvm-config does not like being symlinked
           Product: tools
           Version: 2.8
          Platform: PC
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: llvm-config
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: endobson at mac.com
                CC: llvmbugs at cs.uiuc.edu


Currently I have a setup where my installation directory is not on the path for
all users, so I create the installation in /contrib/projects/llvm and then
symlink /contrib/projects/llvm/bin/llvm-config to /contrib/bin/llvm-config.
This puts llvm-config on the users path, but if one runs 'llvm-config
--lib-dir', one gets /contrib/lib instead of /contrib/projects/llvm/lib. This
prevents any symlinking of llvm-config from being 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  Thu Feb  3 22:21:52 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu,  3 Feb 2011 22:21:52 -0600 (CST)
Subject: [LLVMbugs] [Bug 8748] Default template arguments in out-of-line
 member definitions not rejected.
In-Reply-To: <bug-8748-206@http.llvm.org/bugs/>
References: <bug-8748-206@http.llvm.org/bugs/>
Message-ID: <20110204042152.BB64D2A6C12D@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #1 from Douglas Gregor <dgregor at apple.com> 2011-02-03 22:21:52 CST ---
Fixed in r124856.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb  4 05:33:40 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri,  4 Feb 2011 05:33:40 -0600 (CST)
Subject: [LLVMbugs] [Bug 9137] New: Parser crash with wrong code
Message-ID: <bug-9137-206@http.llvm.org/bugs/>

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

           Summary: Parser crash with wrong code
           Product: clang
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: ismail at namtrac.org
                CC: llvmbugs at cs.uiuc.edu


[~]> cat test.c 
static __attribute__((always_inline)) inline void AV_COPY128(void *d, const
void *s)
            : "=m"(*(struct v*)d)

[~]> clang test.c 
Assertion failed: (getLang().CPlusPlus && "Call sites of this function should
be guarded by checking for C++"), function ParseOptionalCXXScopeSpecifier, file
ParseExprCXX.cpp, line 65.
0  clang             0x0000000101521bf2
llvm::SmallVectorTemplateBase<llvm_regmatch_t, false>::grow(unsigned long) +
754
1  clang             0x0000000101522a43
llvm::SmallVectorTemplateBase<llvm_regmatch_t, false>::grow(unsigned long) +
4419
2  libSystem.B.dylib 0x00007fff885db67a _sigtramp + 26
3  libSystem.B.dylib 0x0000000102033339 _sigtramp + 2040888537
4  clang             0x000000010001a762
std::vector<llvm::PassRegistrationListener*,
std::allocator<llvm::PassRegistrationListener*>
>::_M_insert_aux(__gnu_cxx::__normal_iterator<llvm::PassRegistrationListener**,
std::vector<llvm::PassRegistrationListener*,
std::allocator<llvm::PassRegistrationListener*> > >,
llvm::PassRegistrationListener* const&) + 3474
5  clang             0x0000000100312364
llvm::SmallVectorTemplateCommon<clang::Sema::OffsetOfComponent>::operator[](unsigned
int) + 28356
6  clang             0x00000001002f99e9
clang::Parser::DeclaratorScopeObj::EnterDeclaratorScope() + 6105
7  clang             0x00000001002fa94f
clang::Parser::DeclaratorScopeObj::EnterDeclaratorScope() + 10047
8  clang             0x000000010033a23b
llvm::SmallVectorTemplateBase<clang::ParsedTemplateArgument,
false>::grow(unsigned long) + 43339
9  clang             0x00000001002ee446 clang::Parser::ConsumeAnyToken() +
30534
10 clang             0x000000010033a505
llvm::SmallVectorTemplateBase<clang::ParsedTemplateArgument,
false>::grow(unsigned long) + 44053
11 clang             0x000000010033a947
llvm::SmallVectorTemplateBase<clang::ParsedTemplateArgument,
false>::grow(unsigned long) + 45143
12 clang             0x000000010033bc0f
llvm::SmallVectorTemplateBase<clang::ParsedTemplateArgument,
false>::grow(unsigned long) + 49951
13 clang             0x000000010033be63
llvm::SmallVectorTemplateBase<clang::ParsedTemplateArgument,
false>::grow(unsigned long) + 50547
14 clang             0x00000001002e4b1f llvm::IRBuilder<true,
llvm::ConstantFolder, llvm::IRBuilderDefaultInserter<true>
>::CreateAdd(llvm::Value*, llvm::Value*, llvm::Twine const&) + 463
15 clang             0x00000001002b4ccc llvm::IRBuilder<true,
llvm::ConstantFolder, llvm::IRBuilderDefaultInserter<true>
>::CreateIsNull(llvm::Value*, llvm::Twine const&) + 3980
16 clang             0x00000001000539f9 llvm::DenseMap<clang::IdentifierInfo
const*, unsigned int, llvm::DenseMapInfo<clang::IdentifierInfo const*>,
llvm::DenseMapInfo<unsigned int> >::grow(unsigned int) + 7849
17 clang             0x0000000100024962 std::_Rb_tree<std::string, std::string,
std::_Identity<std::string>, std::less<std::string>,
std::allocator<std::string> >::_M_insert_unique(std::string const&) + 2002
18 clang             0x000000010001c5da
std::vector<llvm::PassRegistrationListener*,
std::allocator<llvm::PassRegistrationListener*>
>::_M_insert_aux(__gnu_cxx::__normal_iterator<llvm::PassRegistrationListener**,
std::vector<llvm::PassRegistrationListener*,
std::allocator<llvm::PassRegistrationListener*> > >,
llvm::PassRegistrationListener* const&) + 11274
19 clang             0x0000000100023994 std::vector<std::string,
std::allocator<std::string> >::operator=(std::vector<std::string,
std::allocator<std::string> > const&) + 12260
20 clang             0x000000010001aee4
std::vector<llvm::PassRegistrationListener*,
std::allocator<llvm::PassRegistrationListener*>
>::_M_insert_aux(__gnu_cxx::__normal_iterator<llvm::PassRegistrationListener**,
std::vector<llvm::PassRegistrationListener*,
std::allocator<llvm::PassRegistrationListener*> > >,
llvm::PassRegistrationListener* const&) + 5396
Stack dump:
0.    Program arguments: /usr/local/bin/clang -cc1 -triple
x86_64-apple-darwin10.0.0 -emit-obj -mrelax-all -disable-free -main-file-name
testcase-min.i -pic-level 1 -mdisable-fp-elim -masm-verbose -munwind-tables
-target-cpu core2 -target-linker-version 97.17 -resource-dir
/usr/local/bin/../lib/clang/2.9 -ferror-limit 19 -fmessage-length 120
-stack-protector 1 -fblocks -fdiagnostics-show-option -fcolor-diagnostics -o
/var/folders/qk/qkch7RbJFkysE0a-GLNGMU+++TM/-Tmp-/cc-wFiz1e.o -x cpp-output
testcase-min.i 
1.    testcase-min.i:2:15: current parser token '"=m"'
clang: error: unable to execute command: Illegal instruction
clang: error: clang frontend command failed due to signal 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  Fri Feb  4 05:58:25 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri,  4 Feb 2011 05:58:25 -0600 (CST)
Subject: [LLVMbugs] [Bug 9137] Parser crash with wrong code
In-Reply-To: <bug-9137-206@http.llvm.org/bugs/>
References: <bug-9137-206@http.llvm.org/bugs/>
Message-ID: <20110204115825.5DD112A6C12E@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #1 from Douglas Gregor <dgregor at apple.com> 2011-02-04 05:58:24 CST ---
Fixed in Clang r124860.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb  4 06:27:26 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri,  4 Feb 2011 06:27:26 -0600 (CST)
Subject: [LLVMbugs] [Bug 9119] no error calling non-const method on const
	object
In-Reply-To: <bug-9119-206@http.llvm.org/bugs/>
References: <bug-9119-206@http.llvm.org/bugs/>
Message-ID: <20110204122726.2CA552A6C12F@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #1 from Douglas Gregor <dgregor at apple.com> 2011-02-04 06:27:25 CST ---


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

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb  4 06:58:07 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri,  4 Feb 2011 06:58:07 -0600 (CST)
Subject: [LLVMbugs] [Bug 8315] Report error when applying a
 pointer-to-const-member-function to non-const object
In-Reply-To: <bug-8315-206@http.llvm.org/bugs/>
References: <bug-8315-206@http.llvm.org/bugs/>
Message-ID: <20110204125807.5647C2A6C12F@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #2 from Douglas Gregor <dgregor at apple.com> 2011-02-04 06:58:06 CST ---
Fixed in Clang r124865.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb  4 07:09:18 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri,  4 Feb 2011 07:09:18 -0600 (CST)
Subject: [LLVMbugs] [Bug 8712] value dependent member in class template
In-Reply-To: <bug-8712-206@http.llvm.org/bugs/>
References: <bug-8712-206@http.llvm.org/bugs/>
Message-ID: <20110204130918.253292A6C12F@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #2 from Douglas Gregor <dgregor at apple.com> 2011-02-04 07:09:17 CST ---
Fixed in r124866.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb  4 07:35:35 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri,  4 Feb 2011 07:35:35 -0600 (CST)
Subject: [LLVMbugs] [Bug 8966] clang++ fails to compile static template
	member variable
In-Reply-To: <bug-8966-206@http.llvm.org/bugs/>
References: <bug-8966-206@http.llvm.org/bugs/>
Message-ID: <20110204133535.90F372A6C124@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #5 from Douglas Gregor <dgregor at apple.com> 2011-02-04 07:35:35 CST ---
Fun one. Fixed in Clang r124867.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb  4 12:03:36 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri,  4 Feb 2011 12:03:36 -0600 (CST)
Subject: [LLVMbugs] [Bug 8551] Wrong type for address-of anonymous union
	member.
In-Reply-To: <bug-8551-206@http.llvm.org/bugs/>
References: <bug-8551-206@http.llvm.org/bugs/>
Message-ID: <20110204180336.E8F9A2A6C12D@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #1 from Douglas Gregor <dgregor at apple.com> 2011-02-04 12:03:36 CST ---
This is fixed 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  Fri Feb  4 12:58:46 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri,  4 Feb 2011 12:58:46 -0600 (CST)
Subject: [LLVMbugs] [Bug 8957] Recognize ARM EABI triple
In-Reply-To: <bug-8957-206@http.llvm.org/bugs/>
References: <bug-8957-206@http.llvm.org/bugs/>
Message-ID: <20110204185846.A74782A6C12C@llvm.org>

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

Renato Golin <rengolin at gmail.com> changed:

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

--- Comment #4 from Renato Golin <rengolin at gmail.com> 2011-02-04 12:58:46 CST ---
Clang patch committed on 124878

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb  4 15:54:21 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri,  4 Feb 2011 15:54:21 -0600 (CST)
Subject: [LLVMbugs] [Bug 9138] New: Missing builtins used in gcc 4.4.5 cmath
	header
Message-ID: <bug-9138-206@http.llvm.org/bugs/>

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

           Summary: Missing builtins used in gcc 4.4.5 cmath header
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++0x
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: jbytheway+llvm at gmail.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


Created an attachment (id=6101)
 --> (http://llvm.org/bugs/attachment.cgi?id=6101)
Output from compiling cmath in C++0x mode

When #including the gcc 4.4.5 <cmath> header there are many builtin functions
which clang does not support.  In particular, the following yields the attached
53 errors:

$ clang++ --version
clang version 2.9 (trunk 124897)
Target: x86_64-unknown-linux-gnu
Thread model: posix
$ g++ --version
g++ (Gentoo 4.4.5 p1.0, pie-0.4.5) 4.4.5
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.

$ cat cmath.cpp
#include <cmath>

int main()
{
}

$ clang++ -std=gnu++0x -o cmath cmath.cpp -ferror-limit=100 > compile-output
2>&1

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

From bugzilla-daemon at llvm.org  Fri Feb  4 16:12:03 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri,  4 Feb 2011 16:12:03 -0600 (CST)
Subject: [LLVMbugs] [Bug 9139] New: CodeGen/ARM/vector-DAGCombine.ll fails
Message-ID: <bug-9139-206@http.llvm.org/bugs/>

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

           Summary: CodeGen/ARM/vector-DAGCombine.ll fails
           Product: libraries
           Version: trunk
          Platform: Other
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: ARM
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: nlewycky at google.com
                CC: evan.cheng at apple.com, llvmbugs at cs.uiuc.edu


This test fails on a beagleboard:

define void @i64_buildvector(i64* %ptr, <2 x i64>* %vp) nounwind {
; CHECK: i64_buildvector
; CHECK: vldr.64
  %t0 = load i64* %ptr, align 4
  %t1 = insertelement <2 x i64> undef, i64 %t0, i32 0
  store <2 x i64> %t1, <2 x i64>* %vp
  ret void
}

The produced assembly reads:

        .globl  i64_buildvector
        .align  2
        .type   i64_buildvector,%function
i64_buildvector:                        @ @i64_buildvector
@ BB#0:
        ldr     r2, [r0]
        ldr     r0, [r0, #4]
        vmov    d16, r2, r0
        vstmia  r1, {d16, d17}
        mov     pc, lr
.Ltmp5:
        .size   i64_buildvector, .Ltmp5-i64_buildvector

On my x86-64 box I get:

@ BB#0:
        vldr.64 d16, [r0]
        vstmia  r1, {d16, d17}
        mov     pc, lr

which matches the test. Do we need a full target triple to make this happen?

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb  4 16:44:59 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri,  4 Feb 2011 16:44:59 -0600 (CST)
Subject: [LLVMbugs] [Bug 9080] miscompile under -fomit-frame-pointer on
	x86-64
In-Reply-To: <bug-9080-206@http.llvm.org/bugs/>
References: <bug-9080-206@http.llvm.org/bugs/>
Message-ID: <20110204224459.18D712A6C12D@llvm.org>

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

Nick Lewycky <nlewycky at google.com> changed:

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

--- Comment #6 from Nick Lewycky <nlewycky at google.com> 2011-02-04 16:44:58 CST ---
Fixed in r124903,
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20110131/116062.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 Feb  4 16:45:58 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri,  4 Feb 2011 16:45:58 -0600 (CST)
Subject: [LLVMbugs] [Bug 9140] New: Assertion failure in clang++ in gnu++0x
	mode
Message-ID: <bug-9140-206@http.llvm.org/bugs/>

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

           Summary: Assertion failure in clang++ in gnu++0x mode
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++0x
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: jbytheway+llvm at gmail.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


Created an attachment (id=6102)
 --> (http://llvm.org/bugs/attachment.cgi?id=6102)
Output from compiling, including assertion failure and backtrace

The following (invalid) code triggers an assertion failure in clang++.

The assertion is "SemaCXXCast.cpp:612: TryCastResult
TryStaticCast(clang::Sema&, clang::Expr*&, clang::QualType, bool, const
clang::SourceRange&, unsigned int&, clang::CastKind&, clang::CXXCastPath&):
Assertion `SrcType->getAs<EnumType>()->getDecl()->isScoped()' failed."; full
output in the attachment.

The source code has been reduced with multidelta, so looks a bit odd.

$ clang++ --version
clang version 2.9 (trunk 124897)
Target: x86_64-unknown-linux-gnu
Thread model: posix
$ cat assertion.cpp
template < typename _Tp > class allocator:public __gnu_cxx::new_allocator < _Tp
>
{
}

class c_storage_order {
  template < typename T, std::size_t NumDims, typename Allocator =
      std::allocator < T > >class multi_array;
  template < typename T,
      std::size_t NumDims >
      class multi_array_ref:public const_multi_array_ref < T, NumDims, T * > {
  } template < typename T, std::size_t NumDims,
      typename Allocator > class multi_array:public multi_array_ref < T,
      NumDims > {
    typedef multi_array_ref < T, NumDims > super_type;
    explicit multi_array():super_type((T *) initial_base_, c_storage_order(),
                                      0, 0) {
    }
    enum {
      initial_base_ = 0
    };
  };
  class BoardState {
    struct Board:utility::DataClass < Board, boost::multi_array < BoardState,
        2 >, states > {
      Board() {
$ clang++ --std=gnu++0x -o /dev/null assertion.cpp > compile-output 2>&1

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

From bugzilla-daemon at llvm.org  Fri Feb  4 16:48:20 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri,  4 Feb 2011 16:48:20 -0600 (CST)
Subject: [LLVMbugs] [Bug 9141] New: Assertion failure in clang++ compiling
	invalid code
Message-ID: <bug-9141-206@http.llvm.org/bugs/>

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

           Summary: Assertion failure in clang++ compiling invalid code
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: jbytheway+llvm at gmail.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


Created an attachment (id=6103)
 --> (http://llvm.org/bugs/attachment.cgi?id=6103)
Output from compiling, including assertion failure and backtrace

The following (invalid) code triggers an assertion failure in clang++; it's a
FIXME so I guess it hardly needs a bug report, but I found it by accident while
trying to pin down #9140, so I thought I'd report it anyway.

The assertion is "ParseExprCXX.cpp:228: bool
clang::Parser::ParseOptionalCXXScopeSpecifier(clang::CXXScopeSpec&,
clang::ParsedType, bool, bool*): Assertion `false && "FIXME: Only type template
names supported here"' failed."; full output in the attachment.

The source code has been reduced with multidelta, so looks a bit odd.

$ clang++ --version
clang version 2.9 (trunk 124897)
Target: x86_64-unknown-linux-gnu
Thread model: posix
$ cat assertion.cpp 
namespace result_of {
  template < typename Sequence >
  struct end:extension::end_impl <
      typename detail::tag_of < Sequence >::type
    >::template apply < Sequence >
  {
  };
}

template < typename Sequence >
inline typename result_of::end <Sequence >::type const end(Sequence & seq)
{
  typedef typename end < Sequence >::type end_;
$ clang++ -o /dev/null assertion.cpp > compile-output 2>&1

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

From bugzilla-daemon at llvm.org  Fri Feb  4 17:49:45 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri,  4 Feb 2011 17:49:45 -0600 (CST)
Subject: [LLVMbugs] [Bug 9142] New: [mc] unknown token "%r14" in movq
Message-ID: <bug-9142-206@http.llvm.org/bugs/>

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

           Summary: [mc] unknown token "%r14" in movq
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: X86
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: nlewycky at google.com
                CC: llvmbugs at cs.uiuc.edu


This one-line assembly file:

  movq         8+(%r14), %mm0

doesn't assemble with llvm-mc:

  $ llvm-mc -assemble x.s -arch=x86_64
          .section        __TEXT,__text,regular,pure_instructions
  x.s:1:17: error: unknown token in expression
  movq         8+(%r14), %mm0
                  ^

but GAS accepts it, if noisily:

  nlewycky at ducttape:~$ as x.s -o x.o
  x.s: Assembler messages:
  x.s:1: Warning: missing operand; zero assumed
  nlewycky at ducttape:~$ objdump -d x.o

  x.o:     file format elf64-x86-64


  Disassembly of section .text:

  0000000000000000 <.text>:
     0:   41 0f 6f 46 08          movq   0x8(%r14),%mm0

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb  4 18:17:06 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri,  4 Feb 2011 18:17:06 -0600 (CST)
Subject: [LLVMbugs] [Bug 9143] New: -Wuninitialized suggests `= 0` for enums
Message-ID: <bug-9143-206@http.llvm.org/bugs/>

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

           Summary: -Wuninitialized suggests `= 0` for enums
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Static Analyzer
        AssignedTo: kremenek at apple.com
        ReportedBy: nicolasweber at gmx.de
                CC: llvmbugs at cs.uiuc.edu


hummer:src thakis$ cat test.cc
enum A {
  A_a, A_b
};
A f() {
  A a;
  return a;
}



hummer:src thakis$ ~/src/llvm-svn/Release+Asserts/bin/clang -c test.cc -Wall
test.cc:6:10: warning: variable 'a' is possibly uninitialized when used here
[-Wuninitialized]
  return a;
         ^
test.cc:5:3: note: variable 'a' is declared here
  A a;
  ^
test.cc:5:6: note: add initialization to silence this warning
  A a;
     ^
      = 0
1 warning generated.



But doing this is of course not valid:

hummer:src thakis$ cat test.cc
enum A {
  A_a, A_b
};
A f() {
  A a = 0;
  return a;
}
hummer:src thakis$ ~/src/llvm-svn/Release+Asserts/bin/clang -c test.cc -Wall
test.cc:5:5: error: cannot initialize a variable of type 'A' with an rvalue of
type 'int'
  A a = 0;
    ^   ~
1 error 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 Feb  4 18:52:45 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri,  4 Feb 2011 18:52:45 -0600 (CST)
Subject: [LLVMbugs] [Bug 9144] New: The static analyzer should warn when
 +initialize doesn't call [super initialize]
Message-ID: <bug-9144-206@http.llvm.org/bugs/>

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

           Summary: The static analyzer should warn when +initialize
                    doesn't call [super initialize]
           Product: clang
           Version: unspecified
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Static Analyzer
        AssignedTo: kremenek at apple.com
        ReportedBy: kc at omnigroup.com
                CC: llvmbugs at cs.uiuc.edu


Overview:

    The static analyzer should warn when +initialize doesn't call [super
initialize], since that can lead to inconsistent and unreliable behavior with
respect to initializing a class.

Discussion:

    One should always call [super initialize] because that's what happens if
you don't implement +initialize--and you shouldn't change a subclass' behavior
when you implement a subclassed method.

    In Objective C, a class' +initialize is supposed to be called for itself
and for every subclass which is initialized.  This is the implemented and
documented behavior of the runtime.

    This is an important feature of the language:  the superclass may need to
register some information for each of its subclasses, e.g. to set up
class-specific mapping dictionaries, or to register CoreData change
notifications for dependent keys.   The superclass doesn't and shouldn't know
which subclasses are non-implementing and the subclasses shouldn't need to know
what initialization the superclass needs to do, the superclass should be able
to do class-specific initialization for each of its subclasses.

    I can think of no benefit to not calling [super initialize] except to avoid
some slight overhead--the same benefit one might achieve by not calling [super
init] (which also seems like terrible general advice).  And there would be a
big downside in terms of consistency of behavior between classes which do or
don't implement +initialize and consistency of implementation between the way
you might implement +initialize and the way you would implement other methods.

    Instead, as a general rule, one should know that any time they subclass any
method they should call the superclass' implementation (unless they are
intentionally trying to bypass/replace the logic provided by the superclass). 
This is just as true for +initialize as it is for any other method.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb  4 19:19:02 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri,  4 Feb 2011 19:19:02 -0600 (CST)
Subject: [LLVMbugs] [Bug 9143] -Wuninitialized suggests `= 0` for enums
In-Reply-To: <bug-9143-206@http.llvm.org/bugs/>
References: <bug-9143-206@http.llvm.org/bugs/>
Message-ID: <20110205011902.9AECE2A6C12D@llvm.org>

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

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> 2011-02-04 19:19:02 CST ---
Fixed here:

r124924

Now no fixit is emitted.  That seems like a reasonable tradeoff, since it isn't
always clear what should be the "default" enum 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  Fri Feb  4 22:36:20 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri,  4 Feb 2011 22:36:20 -0600 (CST)
Subject: [LLVMbugs] [Bug 9114] Clang a bit too strict about types being
	complete
In-Reply-To: <bug-9114-206@http.llvm.org/bugs/>
References: <bug-9114-206@http.llvm.org/bugs/>
Message-ID: <20110205043620.7F6242A6C12E@llvm.org>

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

Anders Carlsson <andersca at mac.com> changed:

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

--- Comment #3 from Anders Carlsson <andersca at mac.com> 2011-02-04 22:36:20 CST ---
Let's try this again then:

Committed revision 124935.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb  4 22:40:02 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri,  4 Feb 2011 22:40:02 -0600 (CST)
Subject: [LLVMbugs] [Bug 9145] New: llvm-ld with clang is failing on OS X,
 but not on Linux
Message-ID: <bug-9145-206@http.llvm.org/bugs/>

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

           Summary: llvm-ld with clang is failing on OS X, but not on
                    Linux
           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: endobson at mac.com
                CC: llvmbugs at cs.uiuc.edu


Trying to compile the following program:

eric at eric-dobsons-macbook () ~/proj/course/11Spring/compilers % cat tmp.ll
; ModuleID = 'tmp.ll'

define i32 @main(i32, i8**) {
entry:
  ret i32 0
}

eric at eric-dobsons-macbook () ~/proj/course/11Spring/compilers % llvmc -clang -v
-o tmp.bin tmp.ll
llc -O2 tmp.ll -o /tmp/llvm_jjsfVp/tmp.s 
as /tmp/llvm_jjsfVp/tmp.s -o /tmp/llvm_jjsfVp/tmp.o 
llvm-ld -native -disable-internalize /tmp/llvm_jjsfVp/tmp.o -o tmp.bin 
llvm-ld: warning: Ignoring file '/tmp/llvm_jjsfVp/tmp.o' because does not
contain bitcode.
Undefined symbols:
  "_main", referenced from:
      start in crt1.10.6.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
llvm-ld: 

But when compling with llvm-gcc it succeeds 
eric at eric-dobsons-macbook () ~/proj/course/11Spring/compilers % llvmc -v -o
tmp.bin tmp.ll
llc -O2 tmp.ll -o /tmp/llvm_pFE0lx/tmp.s 
llvm-gcc -c -x assembler /tmp/llvm_pFE0lx/tmp.s -o /tmp/llvm_pFE0lx/tmp.o 
llvm-gcc /tmp/llvm_pFE0lx/tmp.o -o tmp.bin 


and on linux it succeeds as well


endobson at cslab3d () ~/tmp % llvmc -clang -v -o tmp.bin tmp.bc
llc -O2 tmp.bc -o /tmp/llvm_MUIdwt/tmp.s 
as /tmp/llvm_MUIdwt/tmp.s -o /tmp/llvm_MUIdwt/tmp.o 
llvm-ld -native -disable-internalize /tmp/llvm_MUIdwt/tmp.o -o tmp.bin

If llvm-ld does not support this option on OS X then llvmc should not invoke it
in this manner.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb  4 23:57:05 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri,  4 Feb 2011 23:57:05 -0600 (CST)
Subject: [LLVMbugs] [Bug 9094] Assigning to self twice in init provokes
 spurious warning about not assigning at all
In-Reply-To: <bug-9094-206@http.llvm.org/bugs/>
References: <bug-9094-206@http.llvm.org/bugs/>
Message-ID: <20110205055705.D45252A6C12C@llvm.org>

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

Argyrios Kyrtzidis <akyrtzi at gmail.com> changed:

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

--- Comment #5 from Argyrios Kyrtzidis <akyrtzi at gmail.com> 2011-02-04 23:57:05 CST ---
Fixed at r124940. 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  Sat Feb  5 04:18:06 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat,  5 Feb 2011 04:18:06 -0600 (CST)
Subject: [LLVMbugs] [Bug 9146] New: Possible bug in a stack unwinding
	mechanism.
Message-ID: <bug-9146-206@http.llvm.org/bugs/>

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

           Summary: Possible bug in a stack unwinding mechanism.
           Product: clang
           Version: 2.8
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: dmi3evsv at gmail.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


If an exception is thrown from an constructor during initialization of array
then no destructors for already constructed elements are called.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb  5 09:26:25 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat,  5 Feb 2011 09:26:25 -0600 (CST)
Subject: [LLVMbugs] [Bug 9147] New: ./configure test craps out with clang
 but not with gcc
Message-ID: <bug-9147-206@http.llvm.org/bugs/>

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

           Summary: ./configure test craps out with clang but not with gcc
           Product: clang
           Version: 2.7
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: stark at mit.edu
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=6106)
 --> (http://llvm.org/bugs/attachment.cgi?id=6106)
Configure test which works with gcc but not clang

Our ./configure test fails with clang but not with gcc as follows (the test is
attached)


$ gcc -c -O2 -Wall -Wmissing-prototypes -Wpointer-arith
-Wdeclaration-after-statement -Wendif-labels -Wformat-security
-fno-strict-aliasing -fwrapv  -D_GNU_SOURCE  conftest.c

$ clang -c -O2 -Wall -Wmissing-prototypes -Wpointer-arith
-Wdeclaration-after-statement -Wendif-labels -Wformat-security
-fno-strict-aliasing -fwrapv  -D_GNU_SOURCE  conftest.c
conftest.c:81:12: error: conflicting types for 'accept'
extern int accept (int, struct sockaddr *, socklen_t *);
          ^
In file included from conftest.c:79:
/usr/include/sys/socket.h:214:12: note: previous declaration is here
extern int accept (int __fd, __SOCKADDR_ARG __addr,
          ^
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 Feb  5 11:01:46 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat,  5 Feb 2011 11:01:46 -0600 (CST)
Subject: [LLVMbugs] [Bug 9148] New: [ENH] Support the 'ms_abi' and
	'sysv_abi' attributes
Message-ID: <bug-9148-206@http.llvm.org/bugs/>

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

           Summary: [ENH] Support the 'ms_abi' and 'sysv_abi' attributes
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Backend: X86
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: cdavis at mymail.mines.edu
                CC: llvmbugs at cs.uiuc.edu


The Win64 and System V x86-64 ABIs have different calling conventions.
Currently, LLVM picks the right convention based on the target triple.

GCC does this too, but it also allows code to override the default using two
attributes, 'ms_abi' and 'sysv_abi', which pick the Win64 and System V x86-64
conventions, respectively.

Sixty-four-bit Wine (http://www.winehq.org/) uses the ms_abi attribute
extensively in order for its DLLs to have the correct calling convention.
Without this support, LLVM-based compilers can't build 64-bit Wine.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb  5 14:25:35 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat,  5 Feb 2011 14:25:35 -0600 (CST)
Subject: [LLVMbugs] [Bug 9149] New: [MC] Disassembler fails to decode
 instructions with alternate encodings
Message-ID: <bug-9149-206@http.llvm.org/bugs/>

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

           Summary: [MC] Disassembler fails to decode instructions with
                    alternate encodings
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: X86
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: nemerle5 at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Assembling "movl %esi,%eax" with llvm-mc produces [0x89,0xc6]
But the same instruction can as well be encoded as [0x8b 0xf0]


Simple example:

echo "0x8b 0xf0" | ./llvm-mc -disassemble -triple=i386-unknown-unknown

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb  5 15:15:39 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat,  5 Feb 2011 15:15:39 -0600 (CST)
Subject: [LLVMbugs] [Bug 9149] [MC] Disassembler fails to decode
 instructions with alternate encodings
In-Reply-To: <bug-9149-206@http.llvm.org/bugs/>
References: <bug-9149-206@http.llvm.org/bugs/>
Message-ID: <20110205211539.1E5532A6C12C@llvm.org>

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

Artur Kuptel <nemerle5 at gmail.com> changed:

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

--- Comment #1 from Artur Kuptel <nemerle5 at gmail.com> 2011-02-05 15:15:38 CST ---
This can be solved the same way as http://llvm.org/bugs/show_bug.cgi?id=8873#c1
so I'm marking this as duplicate of 8873

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

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb  5 15:44:36 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat,  5 Feb 2011 15:44:36 -0600 (CST)
Subject: [LLVMbugs] [Bug 9150] New: inaccurate results from divdc3 on x86_64
	darwin10
Message-ID: <bug-9150-206@http.llvm.org/bugs/>

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

           Summary: inaccurate results from divdc3 on x86_64 darwin10
           Product: compiler-rt
           Version: unspecified
          Platform: Macintosh
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: compiler-rt
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: howarth at nitro.med.uc.edu
                CC: llvmbugs at cs.uiuc.edu


The lazy implementation of divdc3 in compiler-rt results in accurate results
for the following test...

--- divdc3_test.c.sav    2011-02-05 15:56:15.000000000 -0500
+++ divdc3_test.c    2011-02-05 16:46:31.000000000 -0500
@@ -49,8 +49,8 @@
 int test__divdc3(double a, double b, double c, double d)
 {
     double _Complex r = __divdc3(a, b, c, d);
-//     printf("test__divdc3(%f, %f, %f, %f) = %f + I%f\n",
-//             a, b, c, d, creal(r), cimag(r));
+     printf("test__divdc3(%f, %f, %f, %f) = %f + I%f\n",
+             a, b, c, d, creal(r), cimag(r));
     double _Complex dividend;
     double _Complex divisor;

@@ -365,6 +365,7 @@
                 return 1;
         }
     }
+   test__divdc3(__DBL_MAX__ * 0.5, __DBL_MAX__ * 0.5,__DBL_MAX__ * 0.25,
__DBL_MAX__ * 0.25);

     return 0;
 }

which produces the inaccurate results...

gcc -I ../../lib divdc3_test.c ../../darwin_fat/Release/libcompiler_rt.a
./a.out
....
test__divdc3(89884656743115785407263711865852178399035283762922498299458738401578630390014269380294779316383439085770229476757191232117160663444732091384233773351768758493024955288275641038122745045194664472037934254227566971152291618451611474082904279666061674137398913102072361584369088590459649940625202013092062429184.000000,
89884656743115785407263711865852178399035283762922498299458738401578630390014269380294779316383439085770229476757191232117160663444732091384233773351768758493024955288275641038122745045194664472037934254227566971152291618451611474082904279666061674137398913102072361584369088590459649940625202013092062429184.000000,
44942328371557892703631855932926089199517641881461249149729369200789315195007134690147389658191719542885114738378595616058580331722366045692116886675884379246512477644137820519061372522597332236018967127113783485576145809225805737041452139833030837068699456551036180792184544295229824970312601006546031214592.000000,
44942328371557892703631855932926089199517641881461249149729369200789315195007134690147389658191719542885114738378595616058580331722366045692116886675884379246512477644137820519061372522597332236018967127113783485576145809225805737041452139833030837068699456551036180792184544295229824970312601006546031214592.000000)
= inf + I0.000000

compared to the accurate implementation of divdc3 in FSF gcc's libgcc...

gcc-4 -I ../../lib divdc3_test.c
/sw/lib/gcc4.6/lib/gcc/x86_64-apple-darwin10.7.0/4.6.0/libgcc.a
./a.out
...
test__divdc3(89884656743115785407263711865852178399035283762922498299458738401578630390014269380294779316383439085770229476757191232117160663444732091384233773351768758493024955288275641038122745045194664472037934254227566971152291618451611474082904279666061674137398913102072361584369088590459649940625202013092062429184.000000,
89884656743115785407263711865852178399035283762922498299458738401578630390014269380294779316383439085770229476757191232117160663444732091384233773351768758493024955288275641038122745045194664472037934254227566971152291618451611474082904279666061674137398913102072361584369088590459649940625202013092062429184.000000,
44942328371557892703631855932926089199517641881461249149729369200789315195007134690147389658191719542885114738378595616058580331722366045692116886675884379246512477644137820519061372522597332236018967127113783485576145809225805737041452139833030837068699456551036180792184544295229824970312601006546031214592.000000,
44942328371557892703631855932926089199517641881461249149729369200789315195007134690147389658191719542885114738378595616058580331722366045692116886675884379246512477644137820519061372522597332236018967127113783485576145809225805737041452139833030837068699456551036180792184544295229824970312601006546031214592.000000)
= 2.000000 + I0.000000

Not fixing this bug degrades the utility of compiler-rt for scientific
applications.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb  5 17:24:16 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat,  5 Feb 2011 17:24:16 -0600 (CST)
Subject: [LLVMbugs] [Bug 9151] New: Assertion failed: ((Result ||
 isa<UsingShadowDecl>(D) || D->isInvalidDecl() ||
 cast<Decl>(ParentDC)->isInvalidDecl()) && "Unable to find instantiation of
 declaration!")
Message-ID: <bug-9151-206@http.llvm.org/bugs/>

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

           Summary: Assertion failed: ((Result || isa<UsingShadowDecl>(D)
                    || D->isInvalidDecl() ||
                    cast<Decl>(ParentDC)->isInvalidDecl()) && "Unable to
                    find instantiation of declaration!")
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: FreeBSD
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: pawel.worach at gmail.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


Created an attachment (id=6107)
 --> (http://llvm.org/bugs/attachment.cgi?id=6107)
598.ii

Building mp4v2 (http://code.google.com/p/mp4v2/) 1.9.1 causes the following
clang assert:

In file included from src/bmff/typebmff.cpp:1:
src/bmff/typebmff.cpp:38:49: error: definition or redeclaration of 'data' not
in
      a namespace enclosing 'Enum<mp4v2::impl::bmff::LanguageCode, 0>'
const EnumLanguageCode::Entry EnumLanguageCode::data[] = {
                              ~~~~~~~~~~~~~~~~~~^
Assertion failed: ((Result || isa<UsingShadowDecl>(D) || D->isInvalidDecl() ||
cast<Decl>(ParentDC)->isInvalidDecl()) && "Unable to find instantiation of
declaration!"), function FindInstantiatedDecl, file
/usr/src-local/llvm/tools/clang/lib/Sema/SemaTemplateInstantiateDecl.cpp, line
2994.
Stack dump:
0.    Program arguments: /usr/opt/llvm/bin/clang -cc1 -triple
x86_64-unknown-freebsd9.0 -S -disable-free -main-file-name typebmff.ii
-mrelocation-model static -mdisable-fp-elim -masm-verbose -mconstructor-aliases
-munwind-tables -target-cpu x86-64 -target-linker-version 2.15
-momit-leaf-frame-pointer -resource-dir /usr/opt/llvm/bin/../lib/clang/2.9
-ferror-limit 19 -fmessage-length 80 -fexceptions -fgnu-runtime
-fdiagnostics-show-option -fcolor-diagnostics -o typebmff.s -x c++-cpp-output
typebmff.ii 
1.    <eof> parser at end of file
2.    ./src/enum.h:96:5: instantiating function definition 'Enum'
clang: error: unable to execute command: Abort trap: 6 (core dumped)
clang: error: clang frontend command failed due to signal 1 (use -v to see
invocation)

Delta 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  Sat Feb  5 18:19:11 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat,  5 Feb 2011 18:19:11 -0600 (CST)
Subject: [LLVMbugs] [Bug 9152] New: File takes 1 minute to compile much
 longer than with gcc or other similar files with llvm
Message-ID: <bug-9152-206@http.llvm.org/bugs/>

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

           Summary: File takes 1 minute to compile much longer than with
                    gcc or other similar files with llvm
           Product: clang
           Version: 2.7
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: stark at mit.edu
                CC: llvmbugs at cs.uiuc.edu


In trying to build postgres there's one bison grammar that seems to take 1
minute to compile with clang.  All the other files go by pretty quick but this
parser just seems to spin with 100% cpu for a minute.

I've attached the preprocessed source of the parser. 

stark at raving:~/src$ time gcc -O2 -c -o preproc.o preproc.c

real    0m5.426s
user    0m5.230s
sys     0m0.150s
stark at raving:~/src$ time clang -O0 -c -o preproc.o preproc.c

real    0m1.146s
user    0m1.070s
sys     0m0.100s
stark at raving:~/src$ time clang -O1 -c -o preproc.o preproc.c

real    0m57.067s
user    0m56.820s
sys     0m0.210s

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb  6 04:51:18 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun,  6 Feb 2011 04:51:18 -0600 (CST)
Subject: [LLVMbugs] [Bug 9153] New: http://libcxx.llvm.org/ build
 instructions invalid for linux
Message-ID: <bug-9153-206@http.llvm.org/bugs/>

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

           Summary: http://libcxx.llvm.org/ build instructions invalid for
                    linux
           Product: libc++
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: All Bugs
        AssignedTo: hhinnant at apple.com
        ReportedBy: cppljevans at suddenlink.net
                CC: llvmbugs at cs.uiuc.edu


The web page:

  http://libcxx.llvm.org/

uses:

  export TRIPLE=-apple-

which, I assume, is invalid for linux systems, but there's no
mention of this on the page.

Also, there's:

  sudo ln -sf path-to-libcxx/lib/libc++.1.dylib libc++.dylib

which won't work for linux since the shared library has a
different suffix than .dylib:  On linux (or, to be precise
on ubuntu) the name is:

  libc++.so.1.0

In addition, the buildit script needs to be modified as
reported in this post:

http://lists.cs.uiuc.edu/pipermail/cfe-dev/2011-February/013228.html

and the instructions about symlinks in /usr/lib need to be modfied
as reported in this post:

http://lists.cs.uiuc.edu/pipermail/cfe-dev/2011-February/013231.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 Feb  6 05:14:59 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun,  6 Feb 2011 05:14:59 -0600 (CST)
Subject: [LLVMbugs] [Bug 9154] New: Assertion failed: (getCost() == C &&
 "Cost exceeds InlineCost precision")
Message-ID: <bug-9154-206@http.llvm.org/bugs/>

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

           Summary: Assertion failed: (getCost() == C && "Cost exceeds
                    InlineCost precision")
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: FreeBSD
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: pawel.worach at gmail.com
                CC: llvmbugs at cs.uiuc.edu


This looks like a random crash building python's cmath module on FreeBSD/i386.

llvm/clang r124977, this is a fairly recent regression.

% /usr/local/llvm2/bin/clang -c -O2 059.i
<warnings>
Assertion failed: (getCost() == C && "Cost exceeds InlineCost precision"),
function InlineCost, file
/data/buildslave/freebsd-clang-i386/src-llvm/include/llvm/Analysis/InlineCost.h,
line 74.
Stack dump:
0.    Program arguments: /usr/local/llvm2/bin/clang -cc1 -triple
i386-unknown-freebsd8.1 -emit-obj -disable-free -main-file-name 059.i
-mrelocation-model static -mdisable-fp-elim -masm-verbose -mconstructor-aliases
-target-cpu i486 -target-linker-version 2.15 -momit-leaf-frame-pointer
-resource-dir /usr/local/llvm2/bin/../lib/clang/2.9 -O2 -ferror-limit 19
-fmessage-length 80 -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics
-o 059.o -x cpp-output 059.i 
1.    <eof> parser at end of file
2.    Per-module optimization passes
3.    Running pass 'CallGraph Pass Manager' on module '059.i'.
clang: error: unable to execute command: Abort trap: 6 (core dumped)
clang: error: clang frontend command failed due to signal 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  Sun Feb  6 12:01:01 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun,  6 Feb 2011 12:01:01 -0600 (CST)
Subject: [LLVMbugs] [Bug 9155] New: NDEBUG is defined in debug configuration
 for Visual Studio projects
Message-ID: <bug-9155-206@http.llvm.org/bugs/>

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

           Summary: NDEBUG is defined in debug configuration for Visual
                    Studio projects
           Product: Build scripts
           Version: trunk
          Platform: PC
        OS/Version: Windows NT
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: cmake
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: art.oriented at gmail.com
                CC: llvmbugs at cs.uiuc.edu


I generated Visual Studio 2010 projects from cmake. However, I've found that
NDEBUG is defined in the debug configurations. Note that all other release
configurations also have this NDEBUG define.

So, we can't correctly use DEBUG macro in "Support\Debug.h". Even in the debug
configuration, DEBUG macro did not expand as in an optimized build
configuration.

It is very tedious to delete NDEBUG defines in every project files. Could you
resolve by fixing CMake configuration?

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb  6 12:08:13 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun,  6 Feb 2011 12:08:13 -0600 (CST)
Subject: [LLVMbugs] [Bug 9156] New: CLANG_RESOURCE_DIR,
 CXX_INCLUDE_* are missed in config.h
Message-ID: <bug-9156-206@http.llvm.org/bugs/>

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

           Summary: CLANG_RESOURCE_DIR, CXX_INCLUDE_* are missed in
                    config.h
           Product: Build scripts
           Version: trunk
          Platform: PC
        OS/Version: Windows NT
            Status: NEW
          Severity: release blocker
          Priority: P
         Component: autoconf
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: art.oriented at gmail.com
                CC: llvmbugs at cs.uiuc.edu


This is a new bug in the current trunk (as of Feb 6th 2011). It was okay with
2.8.

I'm actively using LLVM on Windows platform. I checked out the latest trunk
from SVN, and ran cmake to generate Visual Studio projects. However, "config.h"
missed several #define, so compilation isn't working (e.g., can't find an
identifier 'CLANG_RESOURCE_DIR' or 'CXX_INCLUDE_ROOT').

The missing #define I've seen so far:

<------- 

#define CLANG_RESOURCE_DIR ""

/* Directories clang will search for headers */
#define C_INCLUDE_DIRS ""

/* Directory clang will search for libstdc++ headers */
#define CXX_INCLUDE_ROOT ""

/* Architecture of libstdc++ headers */
#define CXX_INCLUDE_ARCH ""

/* 32 bit multilib directory */
#define CXX_INCLUDE_32BIT_DIR ""

/* 64 bit multilib directory */
#define CXX_INCLUDE_64BIT_DIR ""

-------->

I just copied from the config.h of 2.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  Sun Feb  6 12:18:00 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun,  6 Feb 2011 12:18:00 -0600 (CST)
Subject: [LLVMbugs] [Bug 9157] New: Use of undeclared 'operator[]'
Message-ID: <bug-9157-206@http.llvm.org/bugs/>

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

           Summary: Use of undeclared 'operator[]'
           Product: clang
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: treaves at silverfieldstech.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


I have a file with this line of code:
operator[](i)[j] = right[ i][ j];

llvm-g++ and g++ both compile it fine.  clang++ gives the error in the summary.

Apple clang version 2.0 (tags/Apple/clang-134) (based on LLVM 2.9svn)

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb  6 13:07:59 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun,  6 Feb 2011 13:07:59 -0600 (CST)
Subject: [LLVMbugs] [Bug 9155] NDEBUG is defined in debug configuration for
 Visual Studio projects
In-Reply-To: <bug-9155-206@http.llvm.org/bugs/>
References: <bug-9155-206@http.llvm.org/bugs/>
Message-ID: <20110206190759.288CD2A6C12D@llvm.org>

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

?scar Fuentes <ofv at wanadoo.es> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |ofv at wanadoo.es
         Resolution|                            |FIXED

--- Comment #1 from ?scar Fuentes <ofv at wanadoo.es> 2011-02-06 13:07:58 CST ---
Fixed in r124985.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb  6 13:34:10 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun,  6 Feb 2011 13:34:10 -0600 (CST)
Subject: [LLVMbugs] [Bug 9158] New: Assertion failed in codegen
Message-ID: <bug-9158-206@http.llvm.org/bugs/>

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

           Summary: Assertion failed in codegen
           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: nadav.rotem at intel.com
                CC: llvmbugs at cs.uiuc.edu


; ModuleID = 'bugpoint-reduced-simplified.bc'
target triple = "x86_64-unknown-linux-gnu"

define fastcc void @m_387() nounwind {
entry:
  %0 = load <4 x float>* undef
  %1 = load <4 x float>* null
  %merge68 = select <4 x i1> undef, <4 x float> %0, <4 x float> %1
  store <4 x float> %merge68, <4 x float> addrspace(1)* undef
  ret void
}


The codegen has the following optimization: If we select between the result of
two loads, then we can select between their pointers. However, this fails in
the case of vector select (where the selector is a vector). 

Index: DAGCombiner.cpp
===================================================================
--- DAGCombiner.cpp    (revision 2788)
+++ DAGCombiner.cpp (working copy)
@@ -6581,6 +6581,9 @@
bool DAGCombiner::SimplifySelectOps(SDNode *TheSelect, SDValue LHS,
                                     SDValue RHS) {

+  // Cannot simplify select with vector condition
+  if (TheSelect->getOperand(0).getValueType().isVector()) return false;
+
   // If this is a select from two identical things, try to pull the operation
   // through the select.
   if (LHS.getOpcode() == RHS.getOpcode() && LHS.hasOneUse() &&
RHS.hasOneUse()){

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb  6 13:44:26 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun,  6 Feb 2011 13:44:26 -0600 (CST)
Subject: [LLVMbugs] [Bug 9156] CLANG_RESOURCE_DIR,
	CXX_INCLUDE_* are missed in config.h
In-Reply-To: <bug-9156-206@http.llvm.org/bugs/>
References: <bug-9156-206@http.llvm.org/bugs/>
Message-ID: <20110206194426.E14E92A6C12D@llvm.org>

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

?scar Fuentes <ofv at wanadoo.es> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |ofv at wanadoo.es
         Resolution|                            |INVALID

--- Comment #1 from ?scar Fuentes <ofv at wanadoo.es> 2011-02-06 13:44:26 CST ---
Now Clang has its own config.h file on CMake builds. It is
tools/clang/include/clang/Config/config.h.

I just tested the VC++ IDE build and it worked fine. If it doesn't work for
you, please reopen this bug report showing the error messages.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb  6 15:28:05 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun,  6 Feb 2011 15:28:05 -0600 (CST)
Subject: [LLVMbugs] [Bug 9154] Assertion failed: (getCost() == C && "Cost
 exceeds InlineCost precision")
In-Reply-To: <bug-9154-206@http.llvm.org/bugs/>
References: <bug-9154-206@http.llvm.org/bugs/>
Message-ID: <20110206212805.C6AAE2A6C12C@llvm.org>

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

Eric Christopher <echristo at gmail.com> changed:

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

--- Comment #9 from Eric Christopher <echristo at gmail.com> 2011-02-06 15:28:05 CST ---
Sorry about that. Fixed thusly:

[issola:~/sources/llvm] echristo% svn ci
Sending        lib/Analysis/InlineCost.cpp
Transmitting file data .
Committed revision 124991.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb  6 16:08:31 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun,  6 Feb 2011 16:08:31 -0600 (CST)
Subject: [LLVMbugs] [Bug 3402] sse cannot be turned off for x86-64 -> linux
 kernel panics
In-Reply-To: <bug-3402-206@http.llvm.org/bugs/>
References: <bug-3402-206@http.llvm.org/bugs/>
Message-ID: <20110206220831.ED5D92A6C12D@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #10 from Chris Lattner <clattner at apple.com> 2011-02-06 16:08:30 CST ---
This patch got applied a while ago.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb  6 20:10:20 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun,  6 Feb 2011 20:10:20 -0600 (CST)
Subject: [LLVMbugs] [Bug 9159] New: .svn installed in /usr/share/llvm/cmake
Message-ID: <bug-9159-206@http.llvm.org/bugs/>

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

           Summary: .svn installed in /usr/share/llvm/cmake
           Product: Build scripts
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: cmake
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: oroppas at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Hi,

I noticed the redundant hidden svn directory ended up being installed
system-wise.

$ ls -la /usr/share/llvm/cmake
total 68
drwxr-xr-x 3 root root 4096 Feb  5 19:50 .
drwxr-xr-x 3 root root 4096 Feb  5 19:50 ..
-rw-r--r-- 1 root root 3876 Feb  4 09:28 AddLLVM.cmake
-rw-r--r-- 1 root root  492 Feb  4 09:28 AddLLVMDefinitions.cmake
-rw-r--r-- 1 root root 3813 Feb  4 09:28 ChooseMSVCCRT.cmake
-rw-r--r-- 1 root root  702 Feb  4 09:28 CMakeLists.txt
-rw-r--r-- 1 root root 1031 Feb  4 09:28 CrossCompileLLVM.cmake
-rw-r--r-- 1 root root 5092 Feb  4 09:28 HandleLLVMOptions.cmake
-rw-r--r-- 1 root root 1995 Feb  4 09:31 LLVM.cmake
-rw-r--r-- 1 root root 6495 Feb  4 09:28 LLVMConfig.cmake
-rw-r--r-- 1 root root 6328 Feb  4 09:28 LLVMLibDeps.cmake
-rw-r--r-- 1 root root 2863 Feb  4 09:28 LLVMProcessSources.cmake
drwxr-xr-x 6 root root 4096 Feb  5 19:50 .svn
-rw-r--r-- 1 root root 1983 Feb  4 15:52 TableGen.cmake

Here's how I build LLVM/Clang:

cmake -DCMAKE_INSTALL_PREFIX:PATH=/usr \
        -DBUILD_SHARED_LIBS:BOOL=ON \
        -DCMAKE_CXX_FLAGS:STRING="-O2 -march=native -pipe" \
        -DCMAKE_C_FLAGS:STRING="-O2 -march=native -pipe" \
        -DLLVM_BUILD_EXAMPLES:BOOL=ON \
        -DLLVM_BUILD_TESTS:BOOL=OFF \
        -DLLVM_BUILD_TOOLS:BOOL=ON \
        -DLLVM_ENABLE_THREADS:BOOL=ON \
        -DLLVM_ENABLE_PEDANTIC:BOOL=ON \
        -DLLVM_ENABLE_WARNINGS:BOOL=ON \
        -DLLVM_ENABLE_WERROR:BOOL=OFF \
        -DLLVM_TARGETS_TO_BUILD:STRING="X86;PTX" \
        -DLLVM_TARGET_ARCH:STRING="X86" \
        -DCLANG_BUILD_EXAMPLES:BOOL=ON \
        -DCLANG_TEST_USE_VG:BOOL=OFF \
        ../$_svnmod || return 1
  make || return 1
  make DESTDIR=${pkgdir} install

Regards,

Ryuta

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb  6 20:23:02 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun,  6 Feb 2011 20:23:02 -0600 (CST)
Subject: [LLVMbugs] [Bug 9159] .svn installed in /usr/share/llvm/cmake
In-Reply-To: <bug-9159-206@http.llvm.org/bugs/>
References: <bug-9159-206@http.llvm.org/bugs/>
Message-ID: <20110207022303.03D0F2A6C12D@llvm.org>

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

?scar Fuentes <ofv at wanadoo.es> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |ofv at wanadoo.es
         Resolution|                            |FIXED

--- Comment #1 from ?scar Fuentes <ofv at wanadoo.es> 2011-02-06 20:23:02 CST ---
Fixed on r125001.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb  7 08:15:17 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  7 Feb 2011 08:15:17 -0600 (CST)
Subject: [LLVMbugs] [Bug 9160] New: clang segmentation fault with -Wshadow
Message-ID: <bug-9160-206@http.llvm.org/bugs/>

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

           Summary: clang segmentation fault with -Wshadow
           Product: clang
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: felix.ritter at mevis.fraunhofer.de
                CC: llvmbugs at cs.uiuc.edu


clang version 2.9 (trunk 125005)
Target: x86_64-apple-darwin10
Thread model: posix

clang segfaults when the shadow warning is activated (-Wshadow), it does not
crash without this warning:

0  clang             0x0000000101524032 PrintStackTrace(void*) + 34
1  clang             0x0000000101524e83 SignalHandler(int) + 707
2  libSystem.B.dylib 0x00007fff847b767a _sigtramp + 26
3  libSystem.B.dylib 0x00000000002c5db0 _sigtramp + 2075191120
4  clang             0x00000001003d1047
clang::Sema::ActOnVariableDeclarator(clang::Scope*, clang::Declarator&,
clang::DeclContext*, clang::QualType, clang::TypeSourceInfo*,
clang::LookupResult&, clang::ASTMultiPtr<clang::TemplateParameterList*>, bool&)
+ 2887
5  clang             0x00000001003d7fc4
clang::Sema::HandleDeclarator(clang::Scope*, clang::Declarator&,
clang::ASTMultiPtr<clang::TemplateParameterList*>, bool) + 1492
6  clang             0x00000001002e8b21
clang::Parser::ParseDeclarationAfterDeclarator(clang::Declarator&,
clang::Parser::ParsedTemplateInfo const&) + 1649
7  clang             0x00000001002ec129
clang::Parser::ParseDeclGroup(clang::Parser::ParsingDeclSpec&, unsigned int,
bool, clang::SourceLocation*) + 761
8  clang             0x00000001002f5235
clang::Parser::ParseSimpleDeclaration(clang::ASTOwningVector<clang::Stmt*,
32u>&, unsigned int, clang::SourceLocation&, clang::ParsedAttributes&, bool) +
853
9  clang             0x00000001002f5339
clang::Parser::ParseDeclaration(clang::ASTOwningVector<clang::Stmt*, 32u>&,
unsigned int, clang::SourceLocation&,
clang::Parser::ParsedAttributesWithRange&) + 105
10 clang             0x00000001003250b6
clang::Parser::ParseStatementOrDeclaration(clang::ASTOwningVector<clang::Stmt*,
32u>&, bool) + 1910
11 clang             0x000000010032534e
clang::Parser::ParseCompoundStatementBody(bool) + 446
12 clang             0x0000000100324df6
clang::Parser::ParseStatementOrDeclaration(clang::ASTOwningVector<clang::Stmt*,
32u>&, bool) + 1206
13 clang             0x000000010032812c
clang::Parser::ParseIfStatement(clang::ParsedAttributes&) + 876
14 clang             0x0000000100324e3c
clang::Parser::ParseStatementOrDeclaration(clang::ASTOwningVector<clang::Stmt*,
32u>&, bool) + 1276
15 clang             0x000000010032534e
clang::Parser::ParseCompoundStatementBody(bool) + 446
16 clang             0x000000010032611a
clang::Parser::ParseCXXTryBlockCommon(clang::SourceLocation) + 154
17 clang             0x0000000100324cf3
clang::Parser::ParseStatementOrDeclaration(clang::ASTOwningVector<clang::Stmt*,
32u>&, bool) + 947
18 clang             0x000000010032534e
clang::Parser::ParseCompoundStatementBody(bool) + 446
19 clang             0x0000000100325817
clang::Parser::ParseFunctionStatementBody(clang::Decl*) + 135
20 clang             0x0000000100339f08
clang::Parser::ParseFunctionDefinition(clang::Parser::ParsingDeclarator&,
clang::Parser::ParsedTemplateInfo const&) + 696
21 clang             0x00000001002ec556
clang::Parser::ParseDeclGroup(clang::Parser::ParsingDeclSpec&, unsigned int,
bool, clang::SourceLocation*) + 1830
22 clang             0x0000000100337515
clang::Parser::ParseDeclarationOrFunctionDefinition(clang::Parser::ParsingDeclSpec&,
clang::AccessSpecifier) + 165
23 clang             0x0000000100337957
clang::Parser::ParseDeclarationOrFunctionDefinition(clang::ParsedAttributes&,
clang::AccessSpecifier) + 407
24 clang             0x0000000100338c23
clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&,
clang::Parser::ParsingDeclSpec*) + 2787
25 clang             0x00000001002fb97f clang::Parser::ParseNamespace(unsigned
int, clang::SourceLocation&, clang::SourceLocation) + 1887
26 clang             0x00000001002f5624
clang::Parser::ParseDeclaration(clang::ASTOwningVector<clang::Stmt*, 32u>&,
unsigned int, clang::SourceLocation&,
clang::Parser::ParsedAttributesWithRange&) + 852
27 clang             0x0000000100338b43
clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&,
clang::Parser::ParsingDeclSpec*) + 2563
28 clang             0x0000000100338e73
clang::Parser::ParseTopLevelDecl(clang::OpaquePtr<clang::DeclGroupRef>&) + 115
29 clang             0x00000001002e2c2f clang::ParseAST(clang::Sema&, bool) +
159
30 clang             0x00000001002b36cc clang::CodeGenAction::ExecuteAction() +
60
31 clang             0x0000000100053a99
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 393
32 clang             0x00000001000249c2
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1602
33 clang             0x000000010001c63a cc1_main(char const**, char const**,
char const*, void*) + 586
34 clang             0x00000001000239f4 main + 5588
35 clang             0x000000010001af34 start + 52
Stack dump:
0.    Program arguments: /Users/ritter/Temp/llvm/Release+Asserts/bin/clang -cc1
-triple x86_64-apple-darwin10.0.0 -emit-obj -mrelax-all -disable-free
-main-file-name ML_mlSubImageBoxd.ii -pic-level 1 -mdisable-fp-elim
-masm-verbose -munwind-tables -target-cpu core2 -target-linker-version 97.17
-resource-dir /Users/ritter/Temp/llvm/Release+Asserts/bin/../lib/clang/2.9
-Wshadow -ferror-limit 19 -fmessage-length 80 -stack-protector 1 -fblocks
-fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o
ML_mlSubImageBoxd.o -x c++-cpp-output ML_mlSubImageBoxd.ii 
1.    source/mlSubImageBoxd.cpp:65:19: current parser token '('
2.    source/mlSubImageBoxd.cpp:16:1: parsing namespace 'ml'
3.    source/mlSubImageBoxd.cpp:46:3: parsing function body
'calcAATransformedBox'
4.    source/mlSubImageBoxd.cpp:46:3: in compound statement ('{}')
5.    source/mlSubImageBoxd.cpp:49:5: in compound statement ('{}')
6.    source/mlSubImageBoxd.cpp:53:11: in compound statement ('{}')
clang: error: unable to execute command: Segmentation fault
clang: error: clang frontend command failed due to signal 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 Feb  7 10:27:41 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  7 Feb 2011 10:27:41 -0600 (CST)
Subject: [LLVMbugs] [Bug 9161] New: Clang -Wall too noisy with uninitialized
 variables in common idiom
Message-ID: <bug-9161-206@http.llvm.org/bugs/>

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

           Summary: Clang -Wall too noisy with uninitialized variables in
                    common idiom
           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: stark at mit.edu
                CC: llvmbugs at cs.uiuc.edu


stark at raving:~/src$ clang --version
clang version 2.9 (trunk 125005)
Target: x86_64-unknown-linux-gnu
Thread model: posix

The attached file demonstrates a common programming idiom where a variable is
initialized by passing a reference to it to a function. Clang assumes the
function might not initialize the variable when in fact the programmer knows it
will.

I realize neither option is palatable here but if clang can't prove that the
function has a code path that appears to fail to initialize the variable then
it's better off not printing spurious warnings. 

$ clang -Wall test-llvm-uninitialized.c 
test-llvm-uninitialized.c:14:10: warning: variable 'uninitialized' is possibly
uninitialized when used here [-Wuninitialized]
                return(uninitialized);
                       ^~~~~~~~~~~~~
test-llvm-uninitialized.c:7:2: note: variable 'uninitialized' is declared here
        int uninitialized;
        ^
test-llvm-uninitialized.c:7:19: note: add initialization to silence this
warning
        int uninitialized;
                         ^
                          = 0
1 warning 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 Feb  7 11:07:18 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  7 Feb 2011 11:07:18 -0600 (CST)
Subject: [LLVMbugs] [Bug 9157] Use of undeclared 'operator[]'
In-Reply-To: <bug-9157-206@http.llvm.org/bugs/>
References: <bug-9157-206@http.llvm.org/bugs/>
Message-ID: <20110207170718.342152A6C12E@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #1 from Douglas Gregor <dgregor at apple.com> 2011-02-07 11:07:17 CST ---
Without any context, there's no way we can determine whether your code is wrong
or whether Clang has a bug. I strongly suspect that your code is wrong, and
that you're hitting either

  http://clang.llvm.org/compatibility.html#dep_lookup

or

  http://clang.llvm.org/compatibility.html#dep_lookup_bases

both of which are common migration problems where g++/llvm-g++ accept code that
is actually incorrect.

If you believe that Clang is wrong, please provide a small, self-contained
example that demonstrates the problem you are seeing. The example should
compile with g++/llvm-g++ but not 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 Feb  7 12:43:33 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  7 Feb 2011 12:43:33 -0600 (CST)
Subject: [LLVMbugs] [Bug 8963] Buffer Overflow Check False Positives
In-Reply-To: <bug-8963-206@http.llvm.org/bugs/>
References: <bug-8963-206@http.llvm.org/bugs/>
Message-ID: <20110207184333.AEA052A6C12D@llvm.org>

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

Ted Kremenek <kremenek at apple.com> changed:

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

--- Comment #9 from Ted Kremenek <kremenek at apple.com> 2011-02-07 12:43:32 CST ---
Awesome.  Thanks for the feedback!

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb  7 14:11:11 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  7 Feb 2011 14:11:11 -0600 (CST)
Subject: [LLVMbugs] [Bug 9162] New: Namespace and extern "C" gives problems
 with forward struct declarations
Message-ID: <bug-9162-206@http.llvm.org/bugs/>

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

           Summary: Namespace and extern "C" gives problems with forward
                    struct declarations
           Product: clang
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: dimitry at andric.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


Clang has a problem compiling the gstreamer backend for KDE's phonon
library.  I encountered this issue with trunk r125004.  The reduced C++
code goes like this:

namespace Gstreamer {
  extern "C" {
    typedef struct _ArtsSink ArtsSink;
    struct _ArtsSink {
      int sink;
    };
  }
  int arts_sink_get_type()
  {
    return sizeof(ArtsSink);
  }
}

Compiling this with clang++ gives:

fwddecl.cpp:10:12: error: invalid application of 'sizeof' to an incomplete type
'ArtsSink' (aka 'Gstreamer::_ArtsSink')
    return sizeof(ArtsSink);
           ^     ~~~~~~~~~~
fwddecl.cpp:3:20: note: forward declaration of 'Gstreamer::_ArtsSink'
    typedef struct _ArtsSink ArtsSink;
                   ^
1 error generated.

Granted, it is a bit weird how the KDE guys forward declare the
_ArtsSink struct, but as far as I can see, it should still compile.

I tried this fragment with g++ 4.2.1 (FreeBSD base system compiler), g++
4.5.3, and Coumeau 4.3.10.1, and they all accept it without any
complaint.

Note: the error goes away when you eliminate either the namespace or the
'extern "C"' block.  Both are required to produce the 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  Mon Feb  7 15:04:55 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  7 Feb 2011 15:04:55 -0600 (CST)
Subject: [LLVMbugs] [Bug 9163] New: R11 used but not saved
Message-ID: <bug-9163-206@http.llvm.org/bugs/>

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

           Summary: R11 used but not saved
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: SystemZ
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: bagel99 at gmail.com
                CC: llvmbugs at cs.uiuc.edu


In functions where a frame register is generated, R11 is used for that purpose
but the callers R11 is not saved unless a register in R6-R10 is saved.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb  7 20:06:32 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  7 Feb 2011 20:06:32 -0600 (CST)
Subject: [LLVMbugs] [Bug 9123] [REGRESSION] Crash while compiling snow.c
	from FFmpeg
In-Reply-To: <bug-9123-206@http.llvm.org/bugs/>
References: <bug-9123-206@http.llvm.org/bugs/>
Message-ID: <20110208020632.826FC2A6C12D@llvm.org>

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

Ted Kremenek <kremenek at apple.com> changed:

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

--- Comment #9 from Ted Kremenek <kremenek at apple.com> 2011-02-07 20:06:31 CST ---
According to Dan Gohman this is now fixed in r125065.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb  8 00:33:19 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  8 Feb 2011 00:33:19 -0600 (CST)
Subject: [LLVMbugs] [Bug 9164] New: [MC] fsubp invalid operand for
	instruction
Message-ID: <bug-9164-206@http.llvm.org/bugs/>

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

           Summary: [MC] fsubp invalid operand for instruction
           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: nlewycky at google.com
                CC: llvmbugs at cs.uiuc.edu


llvm-mc doesn't assemble this:

  $ cat sub.s
  fsubp   %st, %st(2)
  $ llvm/Debug+Asserts/bin/llvm-mc sub.s
          .section        __TEXT,__text,regular,pure_instructions
  sub.s:1:14: error: invalid operand for instruction
  fsubp   %st, %st(2)
           ^

but gas seems fine with it:

  $ as sub.s -o sub.o
  $ objdump -d sub.o

  sub.o:     file format elf64-x86-64


  Disassembly of section .text:

  0000000000000000 <.text>:
     0:   de e2                   fsubp  %st,%st(2)

It'd be nice if we did that 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 Feb  8 03:08:50 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  8 Feb 2011 03:08:50 -0600 (CST)
Subject: [LLVMbugs] [Bug 9165] New: Unable to select BUILD_VECTOR operation
Message-ID: <bug-9165-206@http.llvm.org/bugs/>

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

           Summary: Unable to select BUILD_VECTOR operation
           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: nadav.rotem at intel.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=6123)
 --> (http://llvm.org/bugs/attachment.cgi?id=6123)
LL file reproducing the problem

When codegen the attached LL file using LLC, we hit the following problem. 

This is a regression from 2.7. I have a fix ready for this in the DAGCombiner,
pending managerial approval. Will send a patch to the LLVM-commit soon. 


LLVM ERROR: Cannot select: 0x1dfa9e0: v4i32 = BUILD_VECTOR 0x1dfa3e0,
0x1e044a0, 0x1df9fe0, 0x1e045a0 [ID=30]
  0x1dfa3e0: i32 = Constant<0> [ORD=1] [ID=1]
  0x1e044a0: i32 = extract_vector_elt 0x1e03690, 0x1e03b90 [ID=26]
    0x1e03690: v4i32 = bit_convert 0x1e04da0 [ID=21]
      0x1e04da0: v2i64,ch = load 0x1dcb0b8, 0x1e03490,
0x1df9fe0<LD16[null+32](align=32)> [ID=17]
        0x1dcb0b8: ch = EntryToken [ORD=1] [ID=0]
        0x1e03490: i32 = Constant<32> [ID=4]
        0x1df9fe0: i32 = undef [ORD=1] [ID=2]
    0x1e03b90: i32 = Constant<1> [ID=5]
  0x1df9fe0: i32 = undef [ORD=1] [ID=2]
  0x1e045a0: i32 = extract_vector_elt 0x1e05600, 0x1e03b90 [ID=24]
    0x1e05600: v4i32 = bit_convert 0x1dfa2e0 [ID=19]
      0x1dfa2e0: v2i64,ch = load 0x1dcb0b8, 0x1dfa3e0,
0x1df9fe0<LD16[null](align=64)> [ID=14]
        0x1dcb0b8: ch = EntryToken [ORD=1] [ID=0]
        0x1dfa3e0: i32 = Constant<0> [ORD=1] [ID=1]
        0x1df9fe0: i32 = undef [ORD=1] [ID=2]
    0x1e03b90: i32 = Constant<1> [ID=5]

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb  8 06:00:06 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  8 Feb 2011 06:00:06 -0600 (CST)
Subject: [LLVMbugs] [Bug 9166] New: Code generated for function returning
 struct incompatible with native ABI
Message-ID: <bug-9166-206@http.llvm.org/bugs/>

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

           Summary: Code generated for function returning struct
                    incompatible with native ABI
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: X86
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: zvi.rackover at intel.com
                CC: llvmbugs at cs.uiuc.edu


The Win32 native compiler, VC, generates a call to a function returning a
struct in the following manner:
1. The caller allocates a buffer which will be filled by the caller with the
return value
2. Before calling, the caller pushes the address of this buffer on the stack
3. Unlike other targets, such as Linux32, the callee does not pop the address
before returning

Currently, the Win32 target does not follow the above rules. This becomes an
issue when native-compiled and LLVM-compiled codes are mixed.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb  8 12:21:46 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  8 Feb 2011 12:21:46 -0600 (CST)
Subject: [LLVMbugs] [Bug 9160] clang segmentation fault with -Wshadow
In-Reply-To: <bug-9160-206@http.llvm.org/bugs/>
References: <bug-9160-206@http.llvm.org/bugs/>
Message-ID: <20110208182146.9FA132A6C12D@llvm.org>

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

Argyrios Kyrtzidis <akyrtzi at gmail.com> changed:

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

--- Comment #8 from Argyrios Kyrtzidis <akyrtzi at gmail.com> 2011-02-08 12:21:46 CST ---
Fixed at r125097.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb  8 13:01:36 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  8 Feb 2011 13:01:36 -0600 (CST)
Subject: [LLVMbugs] [Bug 8926] clang asserts with illegal instruction
 (!HasCachedLinkage || Linkage(CachedLinkage) == LI.linkage()),
 function getLinkageAndVisibility
In-Reply-To: <bug-8926-206@http.llvm.org/bugs/>
References: <bug-8926-206@http.llvm.org/bugs/>
Message-ID: <20110208190136.E3EE92A6C124@llvm.org>

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

John McCall <rjmccall at apple.com> changed:

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

--- Comment #6 from John McCall <rjmccall at apple.com> 2011-02-08 13:01:36 CST ---
Fixed in r125104.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb  8 13:23:40 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  8 Feb 2011 13:23:40 -0600 (CST)
Subject: [LLVMbugs] [Bug 8986] Post-ra scheduler doesn't respect earlyclobber
In-Reply-To: <bug-8986-206@http.llvm.org/bugs/>
References: <bug-8986-206@http.llvm.org/bugs/>
Message-ID: <20110208192340.0BDA12A6C12D@llvm.org>

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

Andrew Trick <atrick at apple.com> changed:

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

--- Comment #18 from Andrew Trick <atrick at apple.com> 2011-02-08 13:23:39 CST ---
Fixed in r125089. isNewRegClobberedByRefs checks to avoid renaming both defs
that clobber uses and uses that may be clobbered by defs.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb  8 13:42:49 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  8 Feb 2011 13:42:49 -0600 (CST)
Subject: [LLVMbugs] [Bug 9167] New: Linkage of anonymous tag types defined
 in typedefs should not be cached
Message-ID: <bug-9167-206@http.llvm.org/bugs/>

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

           Summary: Linkage of anonymous tag types defined in typedefs
                    should not be cached
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: rjmccall at apple.com
                CC: llvmbugs at cs.uiuc.edu


The linkage of an anonymous tag type defined in a typedef can change. 
Currently we handle this by clearing the linkage cache for that tag and its
children, but it is quite possible to build arbitrary type expressions
involving that type, and we have no way of clearing the linkage of those types.
 dgregor points out that the only reasonable solution is to just not cache
linkage for tag types defined in typedefs until the end of the typedef.

The problem arises with things like this:

  template <class T> struct A { void foo(); };

  typedef struct {
    void foo() { A<decltype(this)>::foo(); }
  } B;

But also things like this:

  typedef struct {
    int x;
  } *B_ptr, B_returning_fn(A<B_ptr>), B;

Oh and by the way, you can put 'typedef' after the struct definition here, so
we just can't cache the linkage of anything involving an anonymous tag
definition until the end of that decl group.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb  8 14:18:08 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  8 Feb 2011 14:18:08 -0600 (CST)
Subject: [LLVMbugs] [Bug 9168] New: Wrong source location for
	CXXMemberCallExpr
Message-ID: <bug-9168-206@http.llvm.org/bugs/>

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

           Summary: Wrong source location for CXXMemberCallExpr
           Product: clang
           Version: 2.8
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: alr at google.com
                CC: llvmbugs at cs.uiuc.edu


This is a regression.

For a fully qualified member, e.g.:

   Foo::bar()

CXXMemberCallExpr::getSourceRange().getBegin() used to return the location of
'Foo' token:

   Foo::bar()
   ^

Now it returns the location of bar token:


   Foo::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  Tue Feb  8 16:10:06 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  8 Feb 2011 16:10:06 -0600 (CST)
Subject: [LLVMbugs] [Bug 9169] New: inlined memcpy from/to global address
	inefficient
Message-ID: <bug-9169-206@http.llvm.org/bugs/>

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

           Summary: inlined memcpy from/to global address inefficient
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Backend: SystemZ
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: bagel99 at gmail.com
                CC: llvmbugs at cs.uiuc.edu


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

The code produced from the test case could be a lot better with
base+displacement:

ff:
    larl    %r1, aa+24
    lg    %r1, 0(%r1)
    larl    %r2, bb+24
    stg    %r1, 0(%r2)
    larl    %r1, aa+16
    lg    %r1, 0(%r1)
    larl    %r2, bb+16
    stg    %r1, 0(%r2)
    larl    %r1, aa+8
    lg    %r1, 0(%r1)
    larl    %r2, bb+8
    stg    %r1, 0(%r2)
    larl    %r1, aa
    lg    %r1, 0(%r1)
    larl    %r2, bb
    stg    %r1, 0(%r2)
    br    %r14

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb  8 17:49:01 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  8 Feb 2011 17:49:01 -0600 (CST)
Subject: [LLVMbugs] [Bug 9170] New: Bad diagnostic when passing non-rvalue
 to rvalue-reference
Message-ID: <bug-9170-206@http.llvm.org/bugs/>

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

           Summary: Bad diagnostic when passing non-rvalue to
                    rvalue-reference
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++0x
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: jyasskin at google.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


The below diagnostic should say something about how you can't bind an lvalue
(even one declared as T&&, although that's not the problem in this case) to an
rvalue parameter.


$ cat ~/tmp/test.cc
struct vector {
  void swap(vector&& __x);
};

void foo() {
  vector v, u;
  v.swap(u);
}
$  clang++  -std=gnu++0x -c ~/tmp/test.cc
/home/jyasskin/tmp/test.cc:7:10: error: binding of reference to type 'vector'
to a value
      of type 'vector' drops qualifiers
  v.swap(u);
         ^
/home/jyasskin/tmp/test.cc:2:22: note: passing argument to parameter '__x' here
  void swap(vector&& __x);
                     ^
1 error 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  Tue Feb  8 19:19:45 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  8 Feb 2011 19:19:45 -0600 (CST)
Subject: [LLVMbugs] [Bug 9171] New: Clang-built WebKit exhibits unique form
	bug
Message-ID: <bug-9171-206@http.llvm.org/bugs/>

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

           Summary: Clang-built WebKit exhibits unique form bug
           Product: new-bugs
           Version: unspecified
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: jon at jonshier.com
                CC: llvmbugs at cs.uiuc.edu


I've filed a bug with WebKit, but it's likely this issue is more suited to the
clang/llvm folks. Using Apple clang version 2.0 (tags/Apple/clang-134), a
successful WebKit build exhibits a bizarre bug. Forms using the
multipart/form-data enctype no longer function. This functionality works
correctly in gcc and llvm-gcc (4.2). I'm l linking the WebKit bug I filed as it
has a link to a simple test for the form type which exhibits the issue.
Essentially, forms that use the multipart/form-data type do not function. That
is, the submit or whatever action button doesn't do anything. Such as this
bugzilla page. However, editing the form in WebKit's inspector and removing the
type sometimes allows the form to function properly, as long as no files are
attached.

https://bugs.webkit.org/show_bug.cgi?id=50306

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb  8 20:04:16 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  8 Feb 2011 20:04:16 -0600 (CST)
Subject: [LLVMbugs] [Bug 8864] DeclRefExpr assertion due to friend functions?
In-Reply-To: <bug-8864-206@http.llvm.org/bugs/>
References: <bug-8864-206@http.llvm.org/bugs/>
Message-ID: <20110209020416.8E98F2A6C12E@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #4 from Douglas Gregor <dgregor at apple.com> 2011-02-08 20:04:16 CST ---
Fixed in Clang r125157.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb  8 23:38:49 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  8 Feb 2011 23:38:49 -0600 (CST)
Subject: [LLVMbugs] [Bug 8848] Problem with
 lib/Support/Windows/DynamicLibrary.inc and mingw-w64
In-Reply-To: <bug-8848-206@http.llvm.org/bugs/>
References: <bug-8848-206@http.llvm.org/bugs/>
Message-ID: <20110209053849.1D45F2A6C12D@llvm.org>

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

NAKAMURA Takumi <geek4civic at gmail.com> changed:

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

--- Comment #2 from NAKAMURA Takumi <geek4civic at gmail.com> 2011-02-08 23:38:48 CST ---
I believe I fixed it in r125169, r125170 and 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  Wed Feb  9 01:11:59 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  9 Feb 2011 01:11:59 -0600 (CST)
Subject: [LLVMbugs] [Bug 4696] [meta] The AuroraUX source tree does not
 fully compile with Clang
In-Reply-To: <bug-4696-206@http.llvm.org/bugs/>
References: <bug-4696-206@http.llvm.org/bugs/>
Message-ID: <20110209071159.618FE2A6C12C@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #4 from Chris Lattner <clattner at apple.com> 2011-02-09 01:11:58 CST ---
Per the comments in this bug, there is no reason to have a meta bug here.  This
has also dropped out of use..

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb  9 04:24:18 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  9 Feb 2011 04:24:18 -0600 (CST)
Subject: [LLVMbugs] [Bug 9172] New: Static variable in function scope
Message-ID: <bug-9172-206@http.llvm.org/bugs/>

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

           Summary: Static variable in function scope
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: LLVM assembly language parser
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: joerg at NetBSD.org
                CC: llvmbugs at cs.uiuc.edu


ELFAsmParser::ParseDirectiveIdent has a static variable which should be
replaced with a class variable.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb  9 07:21:19 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  9 Feb 2011 07:21:19 -0600 (CST)
Subject: [LLVMbugs] [Bug 9173] New: getting very long instruction lines when
 using instcombine
Message-ID: <bug-9173-206@http.llvm.org/bugs/>

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

           Summary: getting very long instruction lines when using
                    instcombine
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: Scalar Optimizations
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: ran.chachick at intel.com
                CC: llvmbugs at cs.uiuc.edu


getting very long instruction line, when using instcombine.

attached is am ll file.
when instcombine is applied to the contained ll code, extremely long
instruction are 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 Feb  9 08:35:15 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  9 Feb 2011 08:35:15 -0600 (CST)
Subject: [LLVMbugs] [Bug 9174] New: problems with "Clang" CFE Internals
	Manual web-page
Message-ID: <bug-9174-206@http.llvm.org/bugs/>

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

           Summary: problems with "Clang" CFE Internals Manual web-page
           Product: Website
           Version: unspecified
          Platform: PC
        OS/Version: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: Documentation
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: eliben at gmail.com
                CC: llvmbugs at cs.uiuc.edu


For this page:
http://clang.llvm.org/docs/InternalsManual.html

* "The Diagnostic*Kinds.def files" section: no longer .def files, there are .td
files now
* In section "The format string", there's a sentence: "Arguments to the
diagnostic are numbered according to how they are specified by the C++ code
that produces them" - the last two words ("produces them") are linked to a
stale anchor on the webpage (at least my Firefox doesn't jump anywhere when
it's clicked)
* In the same section, there's another link on the word "translating" (sentence
starts with "Doing this prevents translating the "), which leads nowhere

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb  9 11:23:40 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  9 Feb 2011 11:23:40 -0600 (CST)
Subject: [LLVMbugs] [Bug 9175] New: ARM assertion failed when disassembling
	LDM & STM
Message-ID: <bug-9175-206@http.llvm.org/bugs/>

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

           Summary: ARM assertion failed when disassembling LDM & STM
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: ARM
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: crabtw at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Message:

================

$ echo '0x10 0x00 0x93 0xe8'|Debug+Asserts/bin/llvm-mc -arch=arm --disassemble
-debug
Args: Debug+Asserts/bin/llvm-mc -arch=arm --disassemble -debug
Opcode=130 Name=LDMIA Format=ARM_FORMAT_LDSTMULFRM(10)
 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10  9  8  7  6 
5  4  3  2  1  0
-------------------------------------------------------------------------------------------------
| 1: 1: 1: 0| 1: 0: 0: 0| 1: 0: 0: 1| 0: 0: 1: 1| 0: 0: 0: 0| 0: 0: 0: 0| 0: 0:
0: 1| 0: 0: 0: 0|
-------------------------------------------------------------------------------------------------

llvm-mc:
/home/jyyou/src/llvm-trunk/lib/Target/ARM/Disassembler/ARMDisassemblerCore.cpp:1241:
bool DisassembleLdStMulFrm(llvm::MCInst&, unsigned int, uint32_t, short
unsigned int, unsigned int&, llvm::ARMBasicMCBuilder*): Assertion `NumOps >= 5
&& "LdStMulFrm expects NumOps >= 5"' failed.

================

It works fine while changing NumOps >= 5 into NumOps >= 4.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb  9 11:39:47 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  9 Feb 2011 11:39:47 -0600 (CST)
Subject: [LLVMbugs] [Bug 9176] New: ARM assertion failed when disassembling
 LDR & STR imm offset form
Message-ID: <bug-9176-206@http.llvm.org/bugs/>

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

           Summary: ARM assertion failed when disassembling LDR & STR imm
                    offset form
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: ARM
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: crabtw at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Message for ldr r0, [r2, #32]:

================

$ echo '0x20 0x00 0x92 0xe5'|Debug+Asserts/bin/llvm-mc -arch=arm --disassemble
-debug
Args: Debug+Asserts/bin/llvm-mc -arch=arm --disassemble -debug
Opcode=163 Name=LDRi12 Format=ARM_FORMAT_LDFRM(6)
 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10  9  8  7  6 
5  4  3  2  1  0
-------------------------------------------------------------------------------------------------
| 1: 1: 1: 0| 0: 1: 0: 1| 1: 0: 0: 1| 0: 0: 1: 0| 0: 0: 0: 0| 0: 0: 0: 0| 0: 0:
1: 0| 0: 0: 0: 0|
-------------------------------------------------------------------------------------------------

llvm-mc:
/home/jyyou/src/llvm-trunk/lib/Target/ARM/Disassembler/ARMDisassemblerCore.cpp:1078:
bool DisassembleLdStFrm(llvm::MCInst&, unsigned int, uint32_t, short unsigned
int, unsigned int&, bool, llvm::ARMBasicMCBuilder*): Assertion
`(OpInfo[OpIdx].RegClass == ARM::GPRRegClassID) && (OpInfo[OpIdx+1].RegClass <
0) && "Expect 1 reg operand followed by 1 imm operand"' failed.

================

Pre-indexed and post-indexed have no 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 Feb  9 11:54:57 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  9 Feb 2011 11:54:57 -0600 (CST)
Subject: [LLVMbugs] [Bug 8369] Support mregparm flag
In-Reply-To: <bug-8369-206@http.llvm.org/bugs/>
References: <bug-8369-206@http.llvm.org/bugs/>
Message-ID: <20110209175457.421A72A6C12D@llvm.org>

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

Daniel Dunbar <daniel at zuster.org> changed:

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

--- Comment #4 from Daniel Dunbar <daniel at zuster.org> 2011-02-09 11:54:56 CST ---
Done here:
  http://llvm.org/viewvc/llvm-project?view=rev&revision=125201

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb  9 13:16:40 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  9 Feb 2011 13:16:40 -0600 (CST)
Subject: [LLVMbugs] [Bug 9177] New: clang gets confused with alias and asm
	labels
Message-ID: <bug-9177-206@http.llvm.org/bugs/>

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

           Summary: clang gets confused with alias and asm labels
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: All
            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


Given

-------------------
int __attribute__((visibility("hidden"))) foo (void);
extern __typeof (foo) foo __asm__ ("INT_foo")
__attribute__((__visibility__("hidden"))) ;
int foo (void) {
}
extern __typeof (foo) EXT_foo __asm__("foo")
__attribute__((__alias__("INT_foo")));
--------------------

Clang will produce

---------------------------
@"\01foo" = alias i32 ()* @INT_foo
define hidden i32 @"\01INT_foo"() nounwind {
entry:
  %retval = alloca i32, align 4
  %0 = load i32* %retval
  ret i32 %0
}
declare i32 @INT_foo()
--------------------------

Note how we have a declaration for INT_foo and a definition for "\01INT_foo".
This gets resolved by LLVM's codegen, but causes problems to LTO because the
alias foo is pointing to a declaration.

Producing
---------------------------
@"\01foo" = alias i32 ()* @"\01INT_foo"
define hidden i32 @"\01INT_foo"() nounwind {
entry:
  %retval = alloca i32, align 4
  %0 = load i32* %retval
  ret i32 %0
}
--------------------------
would fix 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  Wed Feb  9 13:39:38 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  9 Feb 2011 13:39:38 -0600 (CST)
Subject: [LLVMbugs] [Bug 9178] New: NRVO after noreturn call causes clang to
 produce invalid module
Message-ID: <bug-9178-206@http.llvm.org/bugs/>

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

           Summary: NRVO after noreturn call causes clang to produce
                    invalid module
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: LLVM Codegen
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: nlewycky at google.com
                CC: llvmbugs at cs.uiuc.edu


This program coaxes clang into producing an invalid module:

  void abort() __attribute__((__noreturn__));
  struct CoinModelLink {
    CoinModelLink();
    ~CoinModelLink();
  };
  class CoinModel {
    CoinModelLink firstInQuadraticColumn();
  };
  CoinModelLink CoinModel::firstInQuadraticColumn() {
    abort();
    CoinModelLink x;
    return x;
  }

which under "clang -cc1 -emit-llvm-bc" triggers the verifier into saying
"Instruction referencing instruction not embedded in a basic block!". Note that
if you run clang -O2 the verifier won't run and the crash is in SRoA instead.

Here's the verifier failure:

  Instruction referencing instruction not embedded in a basic block!
    %nrvo = alloca i1
    store i1 false, i1* %nrvo
  Broken module found, compilation aborted!

and here's the module at the time of the crash:

  ; ModuleID = '001.c'
  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-n8:16:32:64"
  target triple = "x86_64-unknown-linux-gnu"

  %class.CoinModel = type { i8 }
  %struct.CoinModelLink = type { i8 }

  define void @_ZN9CoinModel22firstInQuadraticColumnEv(%class.CoinModel* sret
%agg.result, %class.CoinModel* %this) nounwind align 2 {
  entry:
    %this.addr = alloca %class.CoinModel*, align 8
    %nrvo = alloca i1
    store %class.CoinModel* %this, %class.CoinModel** %this.addr, align 8
    %this1 = load %class.CoinModel** %this.addr
    call void @_Z5abortv() noreturn
    unreachable

  return:                                           ; No predecessors!
    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  Wed Feb  9 13:51:44 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  9 Feb 2011 13:51:44 -0600 (CST)
Subject: [LLVMbugs] [Bug 9179] New: Reports false positive
Message-ID: <bug-9179-206@http.llvm.org/bugs/>

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

           Summary: Reports false positive
           Product: clang
           Version: 2.7
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Static Analyzer
        AssignedTo: kremenek at apple.com
        ReportedBy: michal at cihar.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=6135)
 --> (http://llvm.org/bugs/attachment.cgi?id=6135)
analysis output

I'm attaching full output, which contains the source as well, but the short
summary is:

warning: Null pointer passed as an argument to a 'nonnull' parameter
                dt->Hour = atoi(time_start);
                           ^    ~~~~~~~~~~

If you look at the line before, you can easily notice, that it can not be NULL,
because it's being checked:

if (time_start != NULL) {
    dt->Hour = atoi(time_start);

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb  9 15:57:01 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  9 Feb 2011 15:57:01 -0600 (CST)
Subject: [LLVMbugs] [Bug 9180] New: SystemZ another assembly syntax problem
Message-ID: <bug-9180-206@http.llvm.org/bugs/>

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

           Summary: SystemZ another assembly syntax problem
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: SystemZ
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: bagel99 at gmail.com
                CC: llvmbugs at cs.uiuc.edu


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

The MVI instruction doesn't accept negative numbers in GNU binutils.

Test case generates:

stib:
    mvi    0(%r2), -1    <-- BAD
    br    %r14

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb  9 16:01:47 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  9 Feb 2011 16:01:47 -0600 (CST)
Subject: [LLVMbugs] [Bug 9181] New: Missed optimization on empty virtual
	destructors
Message-ID: <bug-9181-206@http.llvm.org/bugs/>

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

           Summary: Missed optimization on empty virtual destructors
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: LLVM Codegen
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: jyasskin at google.com
                CC: llvmbugs at cs.uiuc.edu


At the beginning of every virtual destructor, clang writes the class's vtable
into the objects vptr. If the base class is empty, though, it doesn't need to
do this, since after the return or delete call, the object is dead, and any
read of the vptr is undefined behavior.

$ cat test.cc
struct Base {
  virtual ~Base() {}
};

struct Derived : Base {
  ~Derived();
};
Derived::~Derived() {}
$ clang++ -O3 -S -fverbose-asm test.cc -o -
...
_ZN7DerivedD0Ev:                        # @_ZN7DerivedD0Ev
# BB#0:                                 # %invoke.cont
        movq    $_ZTV4Base+16, (%rdi)
        jmp     _ZdlPv                  # TAILCALL
...
_ZN7DerivedD2Ev:                        # @_ZN7DerivedD2Ev
# BB#0:                                 # %entry
        movq    $_ZTV4Base+16, (%rdi)
        ret


-emit-llvm shows:

define void @_ZN7DerivedD2Ev(%struct.Derived* %this) unnamed_addr align 2 {
entry:
  %this.addr = alloca %struct.Derived*, align 8
  store %struct.Derived* %this, %struct.Derived** %this.addr, align 8
  %this1 = load %struct.Derived** %this.addr
  %0 = bitcast %struct.Derived* %this1 to i8***
  store i8** getelementptr inbounds ([4 x i8*]* @_ZTV7Derived, i64 0, i64 2),
i8*** %0
  %1 = bitcast %struct.Derived* %this1 to %struct.Base*
  call void @_ZN4BaseD2Ev(%struct.Base* %1)
  ret void
}
define linkonce_odr void @_ZN4BaseD2Ev(%struct.Base* %this) unnamed_addr
nounwind align 2 {
entry:
  %this.addr = alloca %struct.Base*, align 8
  store %struct.Base* %this, %struct.Base** %this.addr, align 8
  %this1 = load %struct.Base** %this.addr
  %0 = bitcast %struct.Base* %this1 to i8***
  store i8** getelementptr inbounds ([4 x i8*]* @_ZTV4Base, i64 0, i64 2),
i8*** %0
  ret void
}


I think this could be fixed by calling 
@llvm.lifetime.end(sizeof(Base), %this1) at the end of @_ZN4BaseD2Ev and
@llvm.lifetime.end(sizeof(Derived)-sizeof(Base), %this1+sizeof(Base)) in
@_ZN7DerivedD2Ev before the call to @_ZN4BaseD2Ev.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb  9 17:00:37 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  9 Feb 2011 17:00:37 -0600 (CST)
Subject: [LLVMbugs] [Bug 9182] New: spurious warning on overloaded-virtual
Message-ID: <bug-9182-206@http.llvm.org/bugs/>

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

           Summary: spurious warning on overloaded-virtual
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: nlewycky at google.com
                CC: llvmbugs at cs.uiuc.edu, akyrtzi at gmail.com,
                    dgregor at apple.com


This code warns that the derived class hides a virtual function -- except that
it doesn't:

  struct Base {
    virtual void foo(int);
  };

  void Base::foo(int) { }

  struct Derived : public Base {
    virtual void foo(int);   
    void foo(int, int);   
  };

note that if you move the out-of-line Base::foo def'n after struct Derived,
then it doesn't warn any more. Here's the clang output:

  $ clang++ -c x.cc -Woverloaded-virtual 
  x.cc:9:8: warning: 'Derived::foo' hides overloaded virtual function
        [-Woverloaded-virtual]
    void foo(int, int);
         ^
  x.cc:5:12: note: hidden overloaded virtual function 'Base::foo' declared here
  void Base::foo(int) { }
             ^
  1 warning 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 Feb  9 17:48:04 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  9 Feb 2011 17:48:04 -0600 (CST)
Subject: [LLVMbugs] [Bug 9183] New: -fvisibility=internal not implemented
Message-ID: <bug-9183-206@http.llvm.org/bugs/>

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

           Summary: -fvisibility=internal not implemented
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: reid.kleckner at gmail.com
                CC: llvmbugs at cs.uiuc.edu


I ran into this while compiling DynamoRIO with clang.

Does anyone even know what the heck it means?  So far as I can tell, it's
identical to hidden visibility, except that you also promise that no one
outside the DSO you going to link can get a function pointer to functions with
internal visibility.  That interpretation is based on this Intel doc:

http://software.intel.com/sites/products/documentation/studio/composer/en-us/2009/compiler_c/copts/common_options/option_fvisibility.htm


To aim for bug-for-bug compatibility with the gcc driver, I'd just interpret
internal as hidden.  Alternatively, someone can go look at the gcc source and
see how they interpret internal.

If calling it hidden works, I can write a patch.

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

From bugzilla-daemon at llvm.org  Wed Feb  9 19:01:45 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  9 Feb 2011 19:01:45 -0600 (CST)
Subject: [LLVMbugs] [Bug 9184] New: PassManager should minimize number of
 LoopPassManagers
Message-ID: <bug-9184-206@http.llvm.org/bugs/>

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

           Summary: PassManager should minimize number of LoopPassManagers
           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: zwarich at apple.com
                CC: llvmbugs at cs.uiuc.edu


Currently, this analysis usage (taken from LoopStrengthReduce)

  AU.addRequired<LoopInfo>();
  AU.addRequiredID(LoopSimplifyID);
  AU.addRequired<DominatorTree>();
  AU.addRequired<ScalarEvolution>();
  AU.addRequired<IVUsers>();

causes this pass order:

     Natural Loop Information
      Loop Pass Manager
        Canonicalize natural loops
      Scalar Evolution Analysis
      Loop Pass Manager
        Induction Variable Users
        Canonicalize natural loops
        Induction Variable Users
        Loop Strength Reduction

The PassManager should move ScalarEvolution before all of the loop passes,
since they all preserve ScalarEvolution. It is easy enough to fix this by
changing the pass ordering, but in the future this could be done automatically.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb  9 20:20:34 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  9 Feb 2011 20:20:34 -0600 (CST)
Subject: [LLVMbugs] [Bug 9185] New: warn when code would be treated
 differently under gcc
Message-ID: <bug-9185-206@http.llvm.org/bugs/>

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

           Summary: warn when code would be treated differently under gcc
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: nlewycky at google.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


Attached are four testcases, all of which print "AAAAAAAAAAAAAAAAAAAAAA" when
compiled correctly, under clang.

Gcc prints "BBBBBBBBBBBBBBBBBBBBBB" for all of them. It would be really cool if
we could emit a warning in cases we can inexpensively detect where gcc is going
to miscompile the code. This would save lots of gcc to clang porting 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  Wed Feb  9 23:07:00 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  9 Feb 2011 23:07:00 -0600 (CST)
Subject: [LLVMbugs] [Bug 9187] New: LoopStrengthReduce violates LoopPass
	rules
Message-ID: <bug-9187-206@http.llvm.org/bugs/>

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

           Summary: LoopStrengthReduce violates LoopPass rules
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Scalar Optimizations
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: zwarich at apple.com
                CC: llvmbugs at cs.uiuc.edu


LoopStrengthReduce violates LoopPass rules. When processing a loop, it will
potentially modify its parent loop's preheader. For example, run llc on this
reduction:

===

; ModuleID = 'bugpoint-reduced-simplified.bc'
target triple = "x86_64-apple-darwin10"

define void @myquicksort(i8* %a) nounwind ssp {
entry:
  br i1 undef, label %loop1, label %return

loop1:                                            ; preds = %bb13.loopexit,
%entry
  %indvar419 = phi i64 [ %indvar.next420, %loop2.exit ], [ 0, %entry ]
  %tmp474 = shl i64 %indvar419, 2
  %tmp484 = add i64 %tmp474, 4
  br label %loop2

loop2:                                            ; preds = %loop1,
%loop2.backedge
  %indvar414 = phi i64 [ %indvar.next415, %loop2.backedge ], [ 0, %loop1 ]
  %tmp473 = mul i64 %indvar414, -4
  %tmp485 = add i64 %tmp484, %tmp473
  %storemerge4 = getelementptr i8* %a, i64 %tmp485
  %0 = icmp ugt i8* %storemerge4, %a
  br i1 false, label %loop2.exit, label %loop2.backedge

loop2.backedge:                                   ; preds = %loop2
  %indvar.next415 = add i64 %indvar414, 1
  br label %loop2

loop2.exit:                                       ; preds = %loop2
  %indvar.next420 = add i64 %indvar419, 1
  br i1 undef, label %loop1, label %return

return:                                           ; preds = %loop2.exit, %entry
  ret void
}

===

LSR gives this output:

===

define void @myquicksort(i8* %a) nounwind ssp {
entry:
  br i1 undef, label %loop1.preheader, label %return

loop1.preheader:                                  ; preds = %entry
  %scevgep = getelementptr i8* %a, i64 4
  br label %loop1

loop1:                                            ; preds = %loop1.preheader,
%loop2.exit
  %lsr.iv = phi i8* [ %scevgep, %loop1.preheader ], [ %scevgep1, %loop2.exit ]
  %indvar419 = phi i64 [ %indvar.next420, %loop2.exit ], [ 0, %loop1.preheader
]
  br label %loop2

loop2:                                            ; preds = %loop2.backedge,
%loop1
  %lsr.iv2 = phi i8* [ %scevgep3, %loop2.backedge ], [ %lsr.iv, %loop1 ]
  %0 = icmp ugt i8* %lsr.iv2, %a
  br i1 false, label %loop2.exit, label %loop2.backedge

loop2.backedge:                                   ; preds = %loop2
  %scevgep3 = getelementptr i8* %lsr.iv2, i64 -4
  br label %loop2

loop2.exit:                                       ; preds = %loop2
  %indvar.next420 = add i64 %indvar419, 1
  %scevgep1 = getelementptr i8* %lsr.iv, i64 4
  br i1 false, label %loop1, label %return.loopexit

return.loopexit:                                  ; preds = %loop2.exit
  br label %return

return:                                           ; preds = %return.loopexit,
%entry
  ret void
}

===

LSR inserts the definition of %scevgep when processing loop2, not when
processing loop1.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb  9 23:38:25 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  9 Feb 2011 23:38:25 -0600 (CST)
Subject: [LLVMbugs] [Bug 8882] Need an "isexact" bit for shift left
In-Reply-To: <bug-8882-206@http.llvm.org/bugs/>
References: <bug-8882-206@http.llvm.org/bugs/>
Message-ID: <20110210053825.BF10D2A6C12C@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #5 from Chris Lattner <clattner at apple.com> 2011-02-09 23:38:24 CST ---
Reopening this bug.  The major work behind PR8862 is implemented, but I haven't
done the specific xform needed to resolve this issue yet.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb  9 23:39:34 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  9 Feb 2011 23:39:34 -0600 (CST)
Subject: [LLVMbugs] [Bug 8862] ashr, lshr, shl,
 udiv should have an 'isexact' bit indicating it is known to only
 shift out zeros
In-Reply-To: <bug-8862-206@http.llvm.org/bugs/>
References: <bug-8862-206@http.llvm.org/bugs/>
Message-ID: <20110210053934.28B2C2A6C124@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #5 from Chris Lattner <clattner at apple.com> 2011-02-09 23:39:33 CST ---
This is now implemented in a series of patches leading up to r125267.

We now have get:

$ opt -instcombine -S 
define i32 @test(i32 %X) {
  %A = sdiv exact i32 %X, 4
  %B = mul i32 %A, 4
  ret i32 %B
}
^D
; ModuleID = '<stdin>'

define i32 @test(i32 %X) {
  ret i32 %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  Thu Feb 10 04:03:24 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 10 Feb 2011 04:03:24 -0600 (CST)
Subject: [LLVMbugs] [Bug 9188] New: clang trunk assert '(!Qualifier &&
 "Can't have an unnamed field with a qualifier!"),
 function RebuildMemberExpr'
Message-ID: <bug-9188-206@http.llvm.org/bugs/>

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

           Summary: clang trunk assert '(!Qualifier && "Can't have an
                    unnamed field with a qualifier!"), function
                    RebuildMemberExpr'
           Product: clang
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: felix.ritter at mevis.fraunhofer.de
                CC: llvmbugs at cs.uiuc.edu


clang version 2.9 (trunk 125275)
Target: x86_64-apple-darwin10
Thread model: posix

Trying to compile vtk using clang issues the following stack trace:

Assertion failed: (!Qualifier && "Can't have an unnamed field with a
qualifier!"), function RebuildMemberExpr, file TreeTransform.h, line 1374.
0  clang             0x0000000101535182 PrintStackTrace(void*) + 34
1  clang             0x0000000101535fd3 SignalHandler(int) + 707
2  libSystem.B.dylib 0x00007fff847b767a _sigtramp + 26
3  libSystem.B.dylib 0x0000000104200000 _sigtramp + 2141489568
4  clang             0x000000010001a722 __assert_rtn + 66
5  clang             0x000000010059493d clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::RebuildMemberExpr(clang::Expr*,
clang::SourceLocation, bool, clang::NestedNameSpecifier*, clang::SourceRange,
clang::DeclarationNameInfo const&, clang::ValueDecl*, clang::NamedDecl*,
clang::TemplateArgumentListInfo const*, clang::NamedDecl*) + 1261
6  clang             0x00000001005ae60c clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformMemberExpr(clang::MemberExpr*) +
716
7  clang             0x000000010059fa11 clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformExpr(clang::Expr*) + 1073
8  clang             0x00000001005ae39a clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformMemberExpr(clang::MemberExpr*) + 90
9  clang             0x000000010059fa11 clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformExpr(clang::Expr*) + 1073
10 clang             0x00000001005b0d3a clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformBinaryOperator(clang::BinaryOperator*)
+ 90
11 clang             0x000000010059f84f clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformExpr(clang::Expr*) + 623
12 clang             0x00000001005b4dc1 clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformStmt(clang::Stmt*) + 2225
13 clang             0x00000001005b5297 clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformCompoundStmt(clang::CompoundStmt*,
bool) + 167
14 clang             0x00000001005b4a60 clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformStmt(clang::Stmt*) + 1360
15 clang             0x00000001005b688f clang::Sema::SubstStmt(clang::Stmt*,
clang::MultiLevelTemplateArgumentList const&) + 47
16 clang             0x00000001005c7a3f
clang::Sema::InstantiateFunctionDefinition(clang::SourceLocation,
clang::FunctionDecl*, bool, bool) + 2383
17 clang             0x00000001005c6e54
clang::Sema::PerformPendingInstantiations(bool) + 308
18 clang             0x00000001003521b1
clang::Sema::ActOnEndOfTranslationUnit() + 305
19 clang             0x00000001003391fe
clang::Parser::ParseTopLevelDecl(clang::OpaquePtr<clang::DeclGroupRef>&) + 190
20 clang             0x00000001002e301f clang::ParseAST(clang::Sema&, bool) +
159
21 clang             0x00000001002b45cc clang::CodeGenAction::ExecuteAction() +
60
22 clang             0x0000000100055df9
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 393
23 clang             0x00000001000248b2
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1602
24 clang             0x000000010001c51a cc1_main(char const**, char const**,
char const*, void*) + 586
25 clang             0x00000001000238d4 main + 5588
26 clang             0x000000010001ae04 start + 52
Stack dump:
0.    Program arguments: /Users/ritter/Temp/llvm/Release+Asserts/bin/clang -cc1
-triple x86_64-apple-darwin10.0.0 -emit-obj -mrelax-all -disable-free
-main-file-name vtk_qualifier_crash.ii -pic-level 1 -mdisable-fp-elim
-masm-verbose -munwind-tables -target-cpu core2 -target-linker-version 97.17
-resource-dir /Users/ritter/Temp/llvm/Release+Asserts/bin/../lib/clang/2.9
-ferror-limit 19 -fmessage-length 109 -stack-protector 1 -fblocks -fexceptions
-fdiagnostics-show-option -fcolor-diagnostics -o vtk_qualifier_crash.o -x
c++-cpp-output vtk_qualifier_crash.ii 
1.    <eof> parser at end of file
2.   
/Users/ritter/Developer.osxresearch/FMEwork/ThirdParty/Sources/vtk/currentVersion/IO/vtkOpenFOAMReader.cxx:2312:70:
instantiating function definition 'ReadNonuniformList'
clang: error: unable to execute command: Illegal instruction
clang: error: clang frontend command failed due to signal 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  Thu Feb 10 04:15:25 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 10 Feb 2011 04:15:25 -0600 (CST)
Subject: [LLVMbugs] [Bug 9189] New: Spurious results in self = [self -init]
	test
Message-ID: <bug-9189-206@http.llvm.org/bugs/>

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

           Summary: Spurious results in self = [self -init] test
           Product: new-bugs
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: csdavec at swan.ac.uk
                CC: llvmbugs at cs.uiuc.edu


The missing "self = [(super or self) init...]" test in the static analyser
looks like a nice idea, but I've run it on our codebase, seen over a thousand
reports, and so far every single one of them that I've checked has been a false
positive, which makes the test a bit less useful.

One common case is in -initWithCoder:.  Classes implementing this method should
only call [super initWithCoder:] if the superclass implements the NSCoding
protocol.  

I'm not sure what the best way of solving this is.  Ideally, we want two extra
annotations:

1) Specifying a designated initialiser for a class, so that all subclasses are
required to call that initialiser

2) Specify that an initialiser is expected to only call itself in the
superclass (annotation on the method declaration in the protocol).  This is
true for -initWithCoder: and a few other things.  This could actually be a more
general annotation, saying that a subclass implementation of any method is
expected to call the superclass version if it exists, but with a special case
for init*: methods, where it overrides the need to call [{self,super} init].

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 10 07:20:06 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 10 Feb 2011 07:20:06 -0600 (CST)
Subject: [LLVMbugs] [Bug 9190] New: "Unexpected illegal type!" assertion
Message-ID: <bug-9190-206@http.llvm.org/bugs/>

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

           Summary: "Unexpected illegal type!" assertion
           Product: new-bugs
           Version: trunk
          Platform: PC
        OS/Version: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: marina.yatsina at intel.com
                CC: llvmbugs at cs.uiuc.edu


I get "Unexpected illegal type!" assertion when trying to compile the following
kernel:

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-f80:128:128-v64:64:64-v128:128:128-a0:0:64-f80:32:32-n8:16:32"
target triple = "i686-pc-win32"

define void @test() nounwind {
  %1 = fdiv <3 x double> zeroinitializer, undef
  %2 = fdiv <2 x double> zeroinitializer, undef
  %3 = shufflevector <2 x double> %2, <2 x double> undef, <3 x i32> <i32 0, i32
1, i32 undef>
  %4 = insertelement <3 x double> %3, double undef, i32 2
  %5 = bitcast <3 x double> %1 to <3 x i64>
  %6 = bitcast <3 x double> %4 to <3 x i64>
  %7 = sub <3 x i64> %5, %6
  %8 = shufflevector <3 x i64> %7, <3 x i64> undef, <2 x i32> <i32 0, i32 1>
  %9 = xor <2 x i64> %8, zeroinitializer
  %10 = add nsw <2 x i64> %9, zeroinitializer
  %11 = shufflevector <2 x i64> %10, <2 x i64> undef, <3 x i32> <i32 0, i32 1,
i32 undef>
  %12 = insertelement <3 x i64> %11, i64 0, i32 2
  %13 = shufflevector <3 x i64> %12, <3 x i64> undef, <4 x i32> <i32 0, i32 1,
i32 2, i32 3>
  %14 = shufflevector <4 x i64> %13, <4 x i64> undef, <2 x i32> <i32 0, i32 1>
  %15 = bitcast <2 x i64> %14 to <4 x i32>
  %16 = shufflevector <4 x i32> %15, <4 x i32> undef, <4 x i32> <i32 0, i32 2,
i32 0, i32 2>
  %17 = bitcast <4 x i32> %16 to <2 x i64>
  %18 = shufflevector <2 x i64> %17, <2 x i64> undef, <2 x i32> <i32 0, i32 2>
  %19 = bitcast <2 x i64> %18 to <4 x i32>
  %20 = shufflevector <4 x i32> %19, <4 x i32> undef, <3 x i32> <i32 0, i32 1,
i32 2>
  %21 = or <3 x i32> %20, zeroinitializer
  store <3 x i32> %21, <3 x i32> addrspace(1)* undef, align 16
  ret void
}


running "llc  test.ll" produces:

llc: /llvm/lib/CodeGen/SelectionDAG/LegalizeDAG.cpp:800:
llvm::SDValue<unnamed>::SelectionDAGLegalize::LegalizeOp(llvm::SDValue):
Assertion `getTypeAction(Node->getValueType(i)) == Legal && "Unexpected illegal
type!"' failed.
Stack dump:
0.      Program arguments: llc test.ll
1.      Running pass 'Function Pass Manager' on module 'test.ll'.
2.      Running pass 'X86 DAG->DAG Instruction Selection' on function '@test'
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  Thu Feb 10 07:56:55 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 10 Feb 2011 07:56:55 -0600 (CST)
Subject: [LLVMbugs] [Bug 9191] New: Assertion
 `SrcType->getAs<EnumType>()->getDecl()->isScoped()' in invalid C++0x code
Message-ID: <bug-9191-206@http.llvm.org/bugs/>

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

           Summary: Assertion
                    `SrcType->getAs<EnumType>()->getDecl()->isScoped()' in
                    invalid C++0x code
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++0x
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: chris at bubblescope.net
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


Created an attachment (id=6147)
 --> (http://llvm.org/bugs/attachment.cgi?id=6147)
Asserting invalid file

The attached, invalid C++ produces an assertion when compiled with -std=c++0x.
It does not crash with c++98.

This assertion is happening on a huge portion of boost when compiled in c++0x
mode, so fixing it should hopefully help get boost working with clang's c++0x
mode.



t.cc:1:6: error: ISO C++ forbids forward references to 'enum' types
enum test_unit_type;
     ^
t.cc:7:6: error: expected '}'                                                   
type ;
     ^
t.cc:6:1: note: to match this '{'                                               
{
^
t.cc:8:2: error: expected ';' after struct                                      
}};
 ^
 ;                                                                              
t.cc:8:2: error: expected external declaration                                  
t.cc:12:1: error: expected '{' after base class list
template<typename UnitType> 
^
t.cc:10:29: error: expected ';' after struct                                    
struct test_case : test_unit
                            ^
                            ;                                                   
t.cc:14:3: warning: expression result unused [-Wunused-value]                   
{ static_cast<test_unit_type>(UnitType::type ); }
  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
clang: SemaCXXCast.cpp:612: TryCastResult TryStaticCast(clang::Sema&,
clang::Expr*&, clang::QualType, bool, const clang::SourceRange&, unsigned int&,
clang::CastKind&, clang::CXXCastPath&): Assertion
`SrcType->getAs<EnumType>()->getDecl()->isScoped()' failed.
0  clang           0x0000000002355a69
1  clang           0x000000000235585c
2  libpthread.so.0 0x00007f4872d748f0
3  libc.so.6       0x00007f4872063a75 gsignal + 53
4  libc.so.6       0x00007f48720675c0 abort + 384
5  libc.so.6       0x00007f487205c941 __assert_fail + 241
6  clang           0x00000000012c21c9
7  clang           0x00000000012c1d93
8  clang           0x00000000012c0718
clang::Sema::BuildCXXNamedCast(clang::SourceLocation, clang::tok::TokenKind,
clang::TypeSourceInfo*, clang::Expr*, clang::SourceRange, clang::SourceRange) +
1178
9  clang           0x00000000014c04c3
10 clang           0x00000000014bfe5c
11 clang           0x00000000014bb94a
12 clang           0x00000000014b3236
13 clang           0x00000000014a6c62
14 clang           0x00000000014a65e8
15 clang           0x00000000014b9ab8
16 clang           0x00000000014ad202
17 clang           0x00000000014a6236
18 clang           0x00000000014a2dad clang::Sema::SubstStmt(clang::Stmt*,
clang::MultiLevelTemplateArgumentList const&) + 125
19 clang           0x00000000014cc67a
clang::Sema::InstantiateFunctionDefinition(clang::SourceLocation,
clang::FunctionDecl*, bool, bool) + 1740
20 clang           0x00000000014ce89f
clang::Sema::PerformPendingInstantiations(bool) + 341
21 clang           0x00000000012af1d6 clang::Sema::ActOnEndOfTranslationUnit()
+ 376
22 clang           0x0000000001271bd9
clang::Parser::ParseTopLevelDecl(clang::OpaquePtr<clang::DeclGroupRef>&) + 119
23 clang           0x000000000125b0e0 clang::ParseAST(clang::Sema&, bool) + 328
24 clang           0x0000000000fbf363 clang::ASTFrontendAction::ExecuteAction()
+ 263
25 clang           0x0000000001103d39 clang::CodeGenAction::ExecuteAction() +
951
26 clang           0x0000000000fbefb4 clang::FrontendAction::Execute() + 320
27 clang           0x0000000000fa659d
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 751
28 clang           0x0000000000f536c5
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 858
29 clang           0x0000000000f455c9 cc1_main(char const**, char const**, char
const*, void*) + 1032
30 clang           0x0000000000f4ec2c main + 499
31 libc.so.6       0x00007f487204ec4d __libc_start_main + 253
32 clang           0x0000000000f44c39
Stack dump:
0.      Program arguments: /llvmdebug/bin/clang -cc1 -triple
x86_64-unknown-linux-gnu -emit-obj -mrelax-all -disable-free -main-file-name
t.cc -mrelocation-model static -mdisable-fp-elim -masm-verbose
-mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version
2.20.1 -momit-leaf-frame-pointer -resource-dir /llvmdebug/bin/../lib/clang/2.9
-std=c++0x -ferror-limit 19 -fmessage-length 192 -fexceptions -fgnu-runtime
-fdiagnostics-show-option -fcolor-diagnostics -o t.o -x c++ t.cc 
1.      <eof> parser at end of file
2.      t.cc:13:5: instantiating function definition 'get'
clang: error: unable to execute command: Aborted
clang: error: clang frontend command failed due to signal 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  Thu Feb 10 12:14:37 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 10 Feb 2011 12:14:37 -0600 (CST)
Subject: [LLVMbugs] [Bug 9182] spurious warning on overloaded-virtual
In-Reply-To: <bug-9182-206@http.llvm.org/bugs/>
References: <bug-9182-206@http.llvm.org/bugs/>
Message-ID: <20110210181437.8003C2A6C12E@llvm.org>

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

Argyrios Kyrtzidis <akyrtzi at gmail.com> changed:

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

--- Comment #2 from Argyrios Kyrtzidis <akyrtzi at gmail.com> 2011-02-10 12:14:37 CST ---
Fixed at r125296. 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  Thu Feb 10 14:46:59 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 10 Feb 2011 14:46:59 -0600 (CST)
Subject: [LLVMbugs] [Bug 9193] New: clang should warn if 'else if' clause is
 same as any previous 'if' clause
Message-ID: <bug-9193-206@http.llvm.org/bugs/>

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

           Summary: clang should warn if 'else if' clause is same as any
                    previous 'if' clause
           Product: new-bugs
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: sean at rogue-research.com
                CC: llvmbugs at cs.uiuc.edu


Consider the following C snippit:

    if (x == 5)
    {
        ...
    }
    else if (x == 5)
    {
        ...
    }

I've made a typo in the 'else if' and accidentally tested condition.

It would be nice it clang could warn when it sees this.

With raw ints it's easy to see the mistake, but when they are constants, and
two constants accidentally have the same value, it's harder to find.

It would be happy with this in either the compiler or static analyzer.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 10 15:01:16 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 10 Feb 2011 15:01:16 -0600 (CST)
Subject: [LLVMbugs] [Bug 9194] New: clang should warn upon '== YES' with
	Obj-C BOOL
Message-ID: <bug-9194-206@http.llvm.org/bugs/>

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

           Summary: clang should warn upon '== YES' with Obj-C BOOL
           Product: new-bugs
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: sean at rogue-research.com
                CC: llvmbugs at cs.uiuc.edu


Since Objective-C predates C99, it defines it's own BOOL type instead of using
the standard bool. Unfortunately, Obj-C BOOL is in fact a 'signed char' and so
has 256 possible values instead of just 2.

It also defines NO=0 and YES=1. But what about the other 254 values? As per C
rules, they are all treated as true.  As such, testing == NO is safe, but
testing == YES is not (since YES is not the only true value).

rdar://problem/6510042 suggests that Obj-C adopt the C99 bool, but until
then...

it would be nice if clang warned for any test of a BOOL variable with == YES

ex:

BOOL isOK = someBitField & someFlag; // isOK becomes, let's say, 66.
if (isOK == YES)
  fail!

vs

bool isOK = someBitField & someFlag; // isOK becomes either 0 or 1
if (isOK == true)
  success!


I would be happy with either the compiler or static analzyer warning about
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  Thu Feb 10 15:50:15 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 10 Feb 2011 15:50:15 -0600 (CST)
Subject: [LLVMbugs] [Bug 9195] New: -Wformat=0 should be understood as an
 alias for -Wno-format
Message-ID: <bug-9195-206@http.llvm.org/bugs/>

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

           Summary: -Wformat=0 should be understood as an alias for
                    -Wno-format
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: nicolasweber at gmx.de
                CC: llvmbugs at cs.uiuc.edu


Ubuntu's gcc supports -Wformat=0 to disable printf warnings. For compatibility,
it'd be nice if clang would understand that, 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 Feb 10 17:55:21 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 10 Feb 2011 17:55:21 -0600 (CST)
Subject: [LLVMbugs] [Bug 9112] Assertion `(KnownZero2 & KnownOne2) == 0 &&
 "Bits known to be one AND zero?"' failed.
In-Reply-To: <bug-9112-206@http.llvm.org/bugs/>
References: <bug-9112-206@http.llvm.org/bugs/>
Message-ID: <20110210235521.BBF152A6C12D@llvm.org>

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

Nick Lewycky <nlewycky at google.com> changed:

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

--- Comment #2 from Nick Lewycky <nlewycky at google.com> 2011-02-10 17:55:20 CST ---
Fixed in r125319.
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20110207/116348.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 Feb 10 20:19:01 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 10 Feb 2011 20:19:01 -0600 (CST)
Subject: [LLVMbugs] [Bug 9196] New: false positive 'The left expression of
 the compound assignment is an unitialized value. The computed value will be
 garbage.
Message-ID: <bug-9196-206@http.llvm.org/bugs/>

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

           Summary: false positive 'The left expression of the compound
                    assignment is an unitialized value.  The computed
                    value will be garbage.
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Static Analyzer
        AssignedTo: kremenek at apple.com
        ReportedBy: LetterRip at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Here is a simplified version of the code

void buggy(float rad) {
    float vec[7][2]= {{0.195, 0.02}, {0.383, 0.067}, {0.55, 0.169}, {0.707,
0.293},
                      {0.831, 0.45}, {0.924, 0.617}, {0.98, 0.805}};
    int a;

    /* mult */
    for(a=0; a<7; a++) {
        vec[a][0]*= rad; vec[a][1]*= rad; /* claims bug is here */
    }
}


The left expression of the compound assignment is an unitialized value.  The
computed value will be garbage.


And the actual code, this is from Blender head, file is interface_draw.c



void uiDrawBox(int mode, float minx, float miny, float maxx, float maxy, float
rad)
{
    float vec[7][2]= {{0.195, 0.02}, {0.383, 0.067}, {0.55, 0.169}, {0.707,
0.293},
                      {0.831, 0.45}, {0.924, 0.617}, {0.98, 0.805}};
    int a;

    /* mult */
    for(a=0; a<7; a++) {
        vec[a][0]*= rad; vec[a][1]*= rad; /* claims bug is here */
    }

    glBegin(mode);

    /* start with corner right-bottom */
    if(roundboxtype & 4) {
        glVertex2f(maxx-rad, miny);
        for(a=0; a<7; a++) {
            glVertex2f(maxx-rad+vec[a][0], miny+vec[a][1]);
        }
        glVertex2f(maxx, miny+rad);
    }
    else glVertex2f(maxx, miny);

    /* corner right-top */
    if(roundboxtype & 2) {
        glVertex2f(maxx, maxy-rad);
        for(a=0; a<7; a++) {
            glVertex2f(maxx-vec[a][1], maxy-rad+vec[a][0]);
        }
        glVertex2f(maxx-rad, maxy);
    }
    else glVertex2f(maxx, maxy);

    /* corner left-top */
    if(roundboxtype & 1) {
        glVertex2f(minx+rad, maxy);
        for(a=0; a<7; a++) {
            glVertex2f(minx+rad-vec[a][0], maxy-vec[a][1]);
        }
        glVertex2f(minx, maxy-rad);
    }
    else glVertex2f(minx, maxy);

    /* corner left-bottom */
    if(roundboxtype & 8) {
        glVertex2f(minx, miny+rad);
        for(a=0; a<7; a++) {
            glVertex2f(minx+vec[a][1], miny+rad-vec[a][0]);
        }
        glVertex2f(minx+rad, miny);
    }
    else glVertex2f(minx, miny);

    glEnd();
}

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 10 21:19:21 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 10 Feb 2011 21:19:21 -0600 (CST)
Subject: [LLVMbugs] [Bug 9197] New: derived virtual destructor not called
Message-ID: <bug-9197-206@http.llvm.org/bugs/>

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

           Summary: derived virtual destructor not called
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: LLVM Codegen
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: nlewycky at google.com
                CC: llvmbugs at cs.uiuc.edu


This C++ test program should print "destructed!":

  extern "C" int puts(const char *);
  struct Test { ~Test() { puts("destructed!"); } };

  struct Base {
    virtual ~Base();
  };
  Base::~Base() { }

  namespace {
    struct Deriv : public Base {
      Test t[1];
    };
  }

  int main(void) { 
    Base *b = new Deriv();
    delete b;
  };

but doesn't when compiled by clang. The Base::~Base() destructor is called, but
not Deriv, which means that Test is never torn down. Either removing Deriv from
the anonymous namespace or making 't' not be an array masks 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  Fri Feb 11 05:04:51 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 11 Feb 2011 05:04:51 -0600 (CST)
Subject: [LLVMbugs] [Bug 9198] New: Idempotent Operation Test Ignores Sizes
Message-ID: <bug-9198-206@http.llvm.org/bugs/>

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

           Summary: Idempotent Operation Test Ignores Sizes
           Product: new-bugs
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: csdavec at swan.ac.uk
                CC: llvmbugs at cs.uiuc.edu


This sequence generates a warning saying that the second store has no effect:

            *(uint8_t*)address = (uint8_t)big;
            *(uint16_t*)address = (uint16_t)big;

This is a bug, but not the kind of bug that is being reported.  The second
store is completely overwriting the first store, so we should be getting a dead
assignment error, not an idempotent operation 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  Fri Feb 11 06:14:47 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 11 Feb 2011 06:14:47 -0600 (CST)
Subject: [LLVMbugs] [Bug 9199] New: Not properly lowering memcpy intrinsic
 using LDMIA/STMIA on ARM
Message-ID: <bug-9199-206@http.llvm.org/bugs/>

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

           Summary: Not properly lowering memcpy intrinsic using
                    LDMIA/STMIA on ARM
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Backend: ARM
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: vasiliy.korchagin at gmail.com
                CC: llvmbugs at cs.uiuc.edu


llvm emits code for "memcpy" intrinsic on ARM as consecutive ldr/str commands,
and further combines them into ldm/stm with special pass after register
allocation. But ldm/stm commands require registers to go in ascending order,
what is often not so after regalloc, therefore some str/ldr commands remain.
For example such code:

struct Foo {int a, b, c, d; };
void CopyStruct(struct Foo *a, struct Foo *b) { *a = *b; }

compiled to:

ldmia  r1, {r2, r3, r12}
ldr    r1, [r1, #12]
stmia  r0, {r2, r3, r12}
str    r1, [r0, #12]
bx     lr

I ran different tests and always regalloc allocates at least one register not
in ascending order.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 11 06:23:12 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 11 Feb 2011 06:23:12 -0600 (CST)
Subject: [LLVMbugs] [Bug 9200] New: Zero-length VLA test doesn't do adequate
 range propagation
Message-ID: <bug-9200-206@http.llvm.org/bugs/>

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

           Summary: Zero-length VLA test doesn't do adequate range
                    propagation
           Product: new-bugs
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: csdavec at swan.ac.uk
                CC: llvmbugs at cs.uiuc.edu


The analyser is reporting incorrectly in this instance

2092       if (ptr == end)
3 Taking false branch

2093        {
2094          return 0;
2095        }
2096      else
2097        {
2098          unsigned    len = (end - ptr) < 32 ? (end - ptr) : 31;
4 '?' condition is true

2099          char    buf[len+1];
5 Declared variable-length array (VLA) has zero size

>From line 2092, it knows that ptr != end, therefore ptr - end is not 0.  On
line 2098, it is taking the condition as true, therefore end - ptr < 32.  This
means that end-ptr is guaranteed to be in the range 1-31.  Therefore, the size
of the VLA is 2-32.  

Note that even without the original case being propagated, the condition tells
us that len is in the range 0-31, therefore len + 1 can not be 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  Fri Feb 11 08:35:08 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 11 Feb 2011 08:35:08 -0600 (CST)
Subject: [LLVMbugs] [Bug 8778] [Win64] incorrect stack frame with alloca(n)
	and call
In-Reply-To: <bug-8778-206@http.llvm.org/bugs/>
References: <bug-8778-206@http.llvm.org/bugs/>
Message-ID: <20110211143508.478A02A6C12C@llvm.org>

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

NAKAMURA Takumi <geek4civic at gmail.com> changed:

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

--- Comment #1 from NAKAMURA Takumi <geek4civic at gmail.com> 2011-02-11 08:35:07 CST ---
Fixed in r124949. (chkstk issue is pending)

foo:
        pushq   %rbp
        movq    %rsp, %rbp
        movq    %rcx, %rdx
        leaq    15(%rdx), %rax
        andq    $-16, %rax
        movq    %rsp, %rcx
        subq    %rax, %rcx
        movq    %rcx, %rsp
        subq    $48, %rsp
        movq    %rdx, 32(%rsp)
        movq    %rdx, %r8
        movq    %rdx, %r9
        callq   bar
        movq    %rbp, %rsp
        popq    %rbp
        ret

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 11 09:17:34 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 11 Feb 2011 09:17:34 -0600 (CST)
Subject: [LLVMbugs] [Bug 9201] New: llc behaves in a confusing way when
 there is no data layout string
Message-ID: <bug-9201-206@http.llvm.org/bugs/>

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

           Summary: llc behaves in a confusing way when there is no data
                    layout string
           Product: tools
           Version: 2.8
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: llc
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: blood.of.life at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=6151)
 --> (http://llvm.org/bugs/attachment.cgi?id=6151)
IR file that when assembled and passed to llc, triggers behaviour.

Running the following on my machine results in this:

$ llvm-as test6.ll; llc test6.bc
llvm-as: test6.ll:8:28: error: use of undefined value '%int'
  store i1 %primitive, i1* %int
                           ^
llc: /home/bernard/src/llvm-2.8/lib/Target/TargetData.cpp:293: unsigned int
llvm::TargetData::getAlignmentInfo(llvm::AlignTypeEnum, uint32_t, bool, const
llvm::Type*) const: Assertion `AlignType == VECTOR_ALIGN && "Unknown alignment
type!"' failed.
0  libLLVM-2.8.so 0xf6f2e4eb
1  libLLVM-2.8.so 0xf6f2e278
2                 0xf771f400 __kernel_sigreturn + 0
Stack dump:
0.    Program arguments: llc test6.bc 
1.    Running pass 'Function Pass Manager' on module 'test6.bc'.
2.    Running pass 'X86 DAG->DAG Instruction Selection' 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  Fri Feb 11 13:29:19 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 11 Feb 2011 13:29:19 -0600 (CST)
Subject: [LLVMbugs] [Bug 9190] "Unexpected illegal type!" assertion
In-Reply-To: <bug-9190-206@http.llvm.org/bugs/>
References: <bug-9190-206@http.llvm.org/bugs/>
Message-ID: <20110211192919.3BF8D2A6C12C@llvm.org>

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

Nadav Rotem <nadav.rotem at intel.com> changed:

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

--- Comment #2 from Nadav Rotem <nadav.rotem at intel.com> 2011-02-11 13:29:18 CST ---
Fixed in #125391

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 11 13:38:21 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 11 Feb 2011 13:38:21 -0600 (CST)
Subject: [LLVMbugs] [Bug 9173] getting very long instruction lines when
 using instcombine
In-Reply-To: <bug-9173-206@http.llvm.org/bugs/>
References: <bug-9173-206@http.llvm.org/bugs/>
Message-ID: <20110211193821.411FB2A6C12D@llvm.org>

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

Nadav Rotem <nadav.rotem at intel.com> changed:

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

--- Comment #13 from Nadav Rotem <nadav.rotem at intel.com> 2011-02-11 13:38:20 CST ---
Fixed in 125393

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 11 13:58:19 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 11 Feb 2011 13:58:19 -0600 (CST)
Subject: [LLVMbugs] [Bug 9158] Assertion failed in codegen
In-Reply-To: <bug-9158-206@http.llvm.org/bugs/>
References: <bug-9158-206@http.llvm.org/bugs/>
Message-ID: <20110211195819.2D0992A6C12C@llvm.org>

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

Nadav Rotem <nadav.rotem at intel.com> changed:

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

--- Comment #2 from Nadav Rotem <nadav.rotem at intel.com> 2011-02-11 13:58:18 CST ---
Fixed in 125398.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 11 14:13:44 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 11 Feb 2011 14:13:44 -0600 (CST)
Subject: [LLVMbugs] [Bug 8648] Assertion `isa<X>(Val) && "cast<Ty>()
 argument of incompatible type!"' failed
In-Reply-To: <bug-8648-206@http.llvm.org/bugs/>
References: <bug-8648-206@http.llvm.org/bugs/>
Message-ID: <20110211201345.449EA2A6C12C@llvm.org>

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

Ted Kremenek <kremenek at apple.com> changed:

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

--- Comment #7 from Ted Kremenek <kremenek at apple.com> 2011-02-11 14:13:44 CST ---
Test case added in r125401.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 11 14:46:57 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 11 Feb 2011 14:46:57 -0600 (CST)
Subject: [LLVMbugs] [Bug 9202] New: False unused function warning for extern
 "C" function in unnamed namespace
Message-ID: <bug-9202-206@http.llvm.org/bugs/>

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

           Summary: False unused function warning for extern "C" function
                    in unnamed namespace
           Product: clang
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: stephan.bergmann.secondary at googlemail.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


$ clang --version
clang version 2.9 (trunk 125213)
Target: x86_64-apple-darwin10
Thread model: posix

$ printf 'namespace { extern "C" void f() {} }\n' > test.cc

$ clang -c -Wunused-function test.cc
test.cc:1:29: warning: unused function 'f' [-Wunused-function]
namespace { extern "C" void f() {} }
                            ^
1 warning 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 Feb 11 17:12:26 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 11 Feb 2011 17:12:26 -0600 (CST)
Subject: [LLVMbugs] [Bug 9203] New: Warning about struct tag argument being
 "visible outside of this function"
Message-ID: <bug-9203-206@http.llvm.org/bugs/>

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

           Summary: Warning about struct tag argument being "visible
                    outside of this function"
           Product: clang
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: tjw at omnigroup.com
                CC: llvmbugs at cs.uiuc.edu


Compiling this with clang (r125414):


#import <Foundation/NSObject.h>

@interface NSObject(Category)
- (BOOL)appendXML:(struct _OFXMLBuffer *)xml;
@end


now produces a warning that it didn't before.

struct-tag.m:4:27: warning: declaration of 'struct _OFXMLBuffer' will not be
visible outside of this function
- (BOOL)appendXML:(struct _OFXMLBuffer *)xml;

This is easily fixable by #import'ing the header that has a typedef for this
struct, but it has never produced a warning before and seems iffy to me. I'm
not enough of an expert on the C spec to say whether this is a regression or a
new correct behavior, though.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 11 17:51:26 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 11 Feb 2011 17:51:26 -0600 (CST)
Subject: [LLVMbugs] [Bug 9203] Warning about struct tag argument being
 "visible outside of this function"
In-Reply-To: <bug-9203-206@http.llvm.org/bugs/>
References: <bug-9203-206@http.llvm.org/bugs/>
Message-ID: <20110211235126.D50492A6C12E@llvm.org>

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

Ted Kremenek <kremenek at apple.com> changed:

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

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 12 00:52:45 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 12 Feb 2011 00:52:45 -0600 (CST)
Subject: [LLVMbugs] [Bug 8238] CMake build process failed with undefined
	reference
In-Reply-To: <bug-8238-206@http.llvm.org/bugs/>
References: <bug-8238-206@http.llvm.org/bugs/>
Message-ID: <20110212065245.5153A2A6C12E@llvm.org>

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

Ryuta Suzuki <oroppas at gmail.com> changed:

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

--- Comment #16 from Ryuta Suzuki <oroppas at gmail.com> 2011-02-12 00:52:43 CST ---
It seems to be fixed at least in clang 125433.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 12 00:57:29 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 12 Feb 2011 00:57:29 -0600 (CST)
Subject: [LLVMbugs] [Bug 9204] New: Please insert "-fno-use-cxa-atexit" as
 default for Win32
Message-ID: <bug-9204-206@http.llvm.org/bugs/>

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

           Summary: Please insert "-fno-use-cxa-atexit" as default for
                    Win32
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Windows NT
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Driver
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: art.oriented at gmail.com
                CC: llvmbugs at cs.uiuc.edu


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

This bug still happens for native Win32. So, C++ code causes link errors:

 error LNK2019: unresolved external symbol ___dso_handle referenced
 error LNK2019: unresolved external symbol ___cxa_atexit referenced


The fix would be very simple: just put '--fno-use-cxa-atexit' as default
argument. Please fix "tools\clang\lib\Driver\Tools.cpp" as follows (sorry I
don't have permit to commit yet):


  // -fuse-cxa-atexit is default.
  if (KernelOrKext ||
    !Args.hasFlag(options::OPT_fuse_cxa_atexit,
options::OPT_fno_use_cxa_atexit,
                  getToolChain().getTriple().getOS() != llvm::Triple::Win32 &&
                  getToolChain().getTriple().getOS() != llvm::Triple::Cygwin &&
                  getToolChain().getTriple().getOS() != llvm::Triple::MinGW32
&&
                  getToolChain().getTriple().getOS() != llvm::Triple::MinGW64))
    CmdArgs.push_back("-fno-use-cxa-atexit");

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 12 08:44:28 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 12 Feb 2011 08:44:28 -0600 (CST)
Subject: [LLVMbugs] [Bug 9165] Unable to select BUILD_VECTOR operation
In-Reply-To: <bug-9165-206@http.llvm.org/bugs/>
References: <bug-9165-206@http.llvm.org/bugs/>
Message-ID: <20110212144428.62C7F2A6C12C@llvm.org>

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

Nadav Rotem <nadav.rotem at intel.com> changed:

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

--- Comment #3 from Nadav Rotem <nadav.rotem at intel.com> 2011-02-12 08:44:27 CST ---
Fixed in 125435.
Accepted Duncan's comment and added a check if the generated type is legal.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 12 12:50:59 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 12 Feb 2011 12:50:59 -0600 (CST)
Subject: [LLVMbugs] [Bug 9116] assertion failed in
	IdempotentOperationChecker.cpp
In-Reply-To: <bug-9116-206@http.llvm.org/bugs/>
References: <bug-9116-206@http.llvm.org/bugs/>
Message-ID: <20110212185059.D1F012A6C12D@llvm.org>

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

Ted Kremenek <kremenek at apple.com> changed:

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

--- Comment #2 from Ted Kremenek <kremenek at apple.com> 2011-02-12 12:50:59 CST ---
Fixed here: r125443

This was fallout from the additional support for properties.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 12 16:36:32 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 12 Feb 2011 16:36:32 -0600 (CST)
Subject: [LLVMbugs] [Bug 9205] New: cmath does not work with clang
 -std=c++0x or -std=c++93
Message-ID: <bug-9205-206@http.llvm.org/bugs/>

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

           Summary: cmath does not work with clang -std=c++0x or
                    -std=c++93
           Product: libc++
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: All Bugs
        AssignedTo: hhinnant at apple.com
        ReportedBy: chris at bubblescope.net
                CC: llvmbugs at cs.uiuc.edu


A simple:

#include <cmath>

does not work on mac os x 10.6, with clang -std=c++0x or clang -std=c++93. It
works fine with -std=gnu++0x and -std=gnu++93.

I had assumed that -std=c++0x was the 'natural' extension to get c++0x support.
I can see I should probably be using gnu++0x. That is an unfortunate choice of
naming (but probably clang's 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 Feb 12 18:49:24 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 12 Feb 2011 18:49:24 -0600 (CST)
Subject: [LLVMbugs] [Bug 9197] derived virtual destructor not called
In-Reply-To: <bug-9197-206@http.llvm.org/bugs/>
References: <bug-9197-206@http.llvm.org/bugs/>
Message-ID: <20110213004924.528D12A6C12D@llvm.org>

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

John McCall <rjmccall at apple.com> changed:

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

--- Comment #4 from John McCall <rjmccall at apple.com> 2011-02-12 18:49:23 CST ---
Taking the class out of the anonymous namespace gives the implicit destructor
weak linkage, which suppresses -mconstructor-aliases.

The bug is that the code which decides whether a base destructor variant can be
emitted as an alias for the destructor of a base class was not looking through
array types when inspecting the type of a field.  Fixed in r125447.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 12 20:54:55 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 12 Feb 2011 20:54:55 -0600 (CST)
Subject: [LLVMbugs] [Bug 9171] Clang-built WebKit exhibits unique form bug
In-Reply-To: <bug-9171-206@http.llvm.org/bugs/>
References: <bug-9171-206@http.llvm.org/bugs/>
Message-ID: <20110213025455.62FAE2A6C124@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #4 from Chris Lattner <clattner at apple.com> 2011-02-12 20:54:54 CST ---
This was a webkit bug, and is fixed in their ToT:

I don't know how to build WebKit with clang, but I think that I know what's
going on. We do call -[NSFileManager fileSystemRepresentationWithPath:] with a
nil argument, it raises an exception, and we end up returning from
-[_WebSafeForwarder forwardInvocation:] with an uninitialized result. 

This use of uninitialized result is a regression from shipping WebKit, I can
observe it with a gcc build - even though the form doesn't fail to submit for
me.

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

From bugzilla-daemon at llvm.org  Sat Feb 12 23:02:16 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 12 Feb 2011 23:02:16 -0600 (CST)
Subject: [LLVMbugs] [Bug 4900] clang: blender 2.49b renders wrong image
In-Reply-To: <bug-4900-206@http.llvm.org/bugs/>
References: <bug-4900-206@http.llvm.org/bugs/>
Message-ID: <20110213050216.5C3392A6C124@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #12 from Chris Lattner <clattner at apple.com> 2011-02-12 23:02:15 CST ---
I'm assuming so then!

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 13 02:25:43 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 13 Feb 2011 02:25:43 -0600 (CST)
Subject: [LLVMbugs] [Bug 9120] not taking advantage of known pointer
	alignment
In-Reply-To: <bug-9120-206@http.llvm.org/bugs/>
References: <bug-9120-206@http.llvm.org/bugs/>
Message-ID: <20110213082543.5D2CA2A6C12D@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #6 from Chris Lattner <clattner at apple.com> 2011-02-13 02:25:42 CST ---
Comment #2 is now simplified into:

define i1 @test(i32 %x, i32 %y) {
  %C = icmp eq i32 %x, %y
  ret i1 %C
}

We now compile the original testcase down to this:


define void @_Z3fooRKSt6vectorIiSaIiEE(%"class.std::vector"* nocapture %v) ssp
{
entry:
  %tmp2.i = getelementptr inbounds %"class.std::vector"* %v, i64 0, i32 0, i64
8
  %0 = bitcast i8* %tmp2.i to i32**
  %tmp3.i = load i32** %0, align 8, !tbaa !0
  %tmp5.i = bitcast %"class.std::vector"* %v to i32**
  %tmp6.i = load i32** %tmp5.i, align 8, !tbaa !0
  %cmp = icmp eq i32* %tmp3.i, %tmp6.i
  br i1 %cmp, label %if.then, label %if.else

so this looks 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 Feb 13 02:35:08 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 13 Feb 2011 02:35:08 -0600 (CST)
Subject: [LLVMbugs] [Bug 9142] [mc] unknown token "%r14" in movq
In-Reply-To: <bug-9142-206@http.llvm.org/bugs/>
References: <bug-9142-206@http.llvm.org/bugs/>
Message-ID: <20110213083508.847B42A6C12C@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #1 from Chris Lattner <clattner at apple.com> 2011-02-13 02:35:08 CST ---
We're not accepting this syntax, please fix the project upstream, see for
example:
http://llvm.org/bugs/show_bug.cgi?id=7352#c5

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 13 02:36:17 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 13 Feb 2011 02:36:17 -0600 (CST)
Subject: [LLVMbugs] [Bug 9147] ./configure test craps out with clang but not
	with gcc
In-Reply-To: <bug-9147-206@http.llvm.org/bugs/>
References: <bug-9147-206@http.llvm.org/bugs/>
Message-ID: <20110213083617.65CCD2A6C12C@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #4 from Chris Lattner <clattner at apple.com> 2011-02-13 02:36:16 CST ---
This has been fixed since LLVM 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 Feb 13 02:39:11 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 13 Feb 2011 02:39:11 -0600 (CST)
Subject: [LLVMbugs] [Bug 9109] [patch] Fix of the shared library link on
	Solaris
In-Reply-To: <bug-9109-206@http.llvm.org/bugs/>
References: <bug-9109-206@http.llvm.org/bugs/>
Message-ID: <20110213083911.C265E2A6C12D@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #1 from Chris Lattner <clattner at apple.com> 2011-02-13 02:39:11 CST ---
Applied in r125456.  Please send patches to llvm-commits, don't file bugs. 
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 Feb 13 02:41:09 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 13 Feb 2011 02:41:09 -0600 (CST)
Subject: [LLVMbugs] [Bug 9078] Plug-in mechanism broken on Windows
In-Reply-To: <bug-9078-206@http.llvm.org/bugs/>
References: <bug-9078-206@http.llvm.org/bugs/>
Message-ID: <20110213084109.3A9122A6C12C@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #3 from Chris Lattner <clattner at apple.com> 2011-02-13 02:41:08 CST ---
Hi John,

Please send patches to llvm/cfe-commits, 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 Feb 13 02:45:13 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 13 Feb 2011 02:45:13 -0600 (CST)
Subject: [LLVMbugs] [Bug 9035] x86 backend double load/store generating bad
	code
In-Reply-To: <bug-9035-206@http.llvm.org/bugs/>
References: <bug-9035-206@http.llvm.org/bugs/>
Message-ID: <20110213084513.4E8E22A6C130@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #1 from Chris Lattner <clattner at apple.com> 2011-02-13 02:45:12 CST ---
I'm pretty certain fldl/stpl work fine with NaNs.  Please include a self
contained (executable) c file that demonstrates a failure.

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

From bugzilla-daemon at llvm.org  Sun Feb 13 03:11:09 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 13 Feb 2011 03:11:09 -0600 (CST)
Subject: [LLVMbugs] [Bug 9028] Assertion on valid code when optimization is
	turned on
In-Reply-To: <bug-9028-206@http.llvm.org/bugs/>
References: <bug-9028-206@http.llvm.org/bugs/>
Message-ID: <20110213091109.C63FC2A6C12E@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #2 from Chris Lattner <clattner at apple.com> 2011-02-13 03:11:09 CST ---
Reduced testcase fixed in r125458, 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 Feb 13 10:17:17 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 13 Feb 2011 10:17:17 -0600 (CST)
Subject: [LLVMbugs] [Bug 9206] New: Clang does not support gcc-style nested
	functions
Message-ID: <bug-9206-206@http.llvm.org/bugs/>

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

           Summary: Clang does not support gcc-style nested functions
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: reid.kleckner at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Here are the gcc docs for this gnu-tension:
http://gcc.gnu.org/onlinedocs/gcc/Nested-Functions.html

Is this worth supporting in clang and LLVM?  My understanding of the
implementation is that you emit snippet of code to the stack which loads the
address of the parent stack frame and jumps into the nested function.

It seems LLVM already supports trampolines, so this would mostly be frontend
work.
http://llvm.org/docs/LangRef.html#int_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  Sun Feb 13 12:41:43 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 13 Feb 2011 12:41:43 -0600 (CST)
Subject: [LLVMbugs] [Bug 9206] Clang does not support gcc-style nested
	functions
In-Reply-To: <bug-9206-206@http.llvm.org/bugs/>
References: <bug-9206-206@http.llvm.org/bugs/>
Message-ID: <20110213184143.B1FA72A6C124@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #1 from Chris Lattner <clattner at apple.com> 2011-02-13 12:41:43 CST ---
Hi Reid,

This is one feature that we really do not want to implement.  Besides adding a
bunch of complexity, among other things this makes parser error recovery worse:
you don't know if you're entering a nested function or if a missing } happened.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 13 12:56:17 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 13 Feb 2011 12:56:17 -0600 (CST)
Subject: [LLVMbugs] [Bug 9207] New: A LLVM IR file that causes a segfault in
	llc
Message-ID: <bug-9207-206@http.llvm.org/bugs/>

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

           Summary: A LLVM IR file  that causes a segfault in llc
           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: sylvestre at debian.org
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=6157)
 --> (http://llvm.org/bugs/attachment.cgi?id=6157)
LLVM IR 

The attached code built with the following command:
llc-2.8 testasm.ll -o testasm.s

Crashes:

PHI node entries do not match predecessors!
  %init.index = phi i64 [ 0, %init.top ], [ %init.index.next, %init.top ]
label %init.top
label %enter.good
Broken module found, compilation aborted!
0  libLLVM-2.8.so.1 0x00007f76a98b50df
1  libLLVM-2.8.so.1 0x00007f76a98b5b9a
2  libpthread.so.0  0x00007f76a8b8ef60
3  libc.so.6        0x00007f76a7ca5165 gsignal + 53
4  libc.so.6        0x00007f76a7ca7f70 abort + 384
5  libLLVM-2.8.so.1 0x00007f76a94dcb9f
6  libLLVM-2.8.so.1 0x00007f76a94bb5f9
llvm::FPPassManager::runOnFunction(llvm::Function&) + 521
7  libLLVM-2.8.so.1 0x00007f76a94bb6ab
llvm::FPPassManager::runOnModule(llvm::Module&) + 75
8  libLLVM-2.8.so.1 0x00007f76a94bb2c4
llvm::MPPassManager::runOnModule(llvm::Module&) + 468
9  libLLVM-2.8.so.1 0x00007f76a94bb3bb
llvm::PassManagerImpl::run(llvm::Module&) + 107
10 llc-2.8          0x0000000000407f2d main + 3981
11 libc.so.6        0x00007f76a7c91c4d __libc_start_main + 253
12 llc-2.8          0x0000000000406269
Stack dump:
0.    Program arguments: llc-2.8 testasm.ll -o testasm.s 
1.    Running pass 'Function Pass Manager' on module 'testasm.ll'.
2.    Running pass 'Module Verifier' on function '@enterLeave'
Abandon

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 13 13:06:30 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 13 Feb 2011 13:06:30 -0600 (CST)
Subject: [LLVMbugs] [Bug 9207] A LLVM IR file that causes a segfault in llc
In-Reply-To: <bug-9207-206@http.llvm.org/bugs/>
References: <bug-9207-206@http.llvm.org/bugs/>
Message-ID: <20110213190631.00F1B2A6C12E@llvm.org>

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

Duncan Sands <baldrick at free.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |baldrick at free.fr
         Resolution|                            |INVALID

--- Comment #1 from Duncan Sands <baldrick at free.fr> 2011-02-13 13:06:30 CST ---
This is not a segmentation fault, it is the verifier observing that the bitcode
file is not 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 Feb 13 13:13:03 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 13 Feb 2011 13:13:03 -0600 (CST)
Subject: [LLVMbugs] [Bug 9164] [MC] fsubp invalid operand for instruction
In-Reply-To: <bug-9164-206@http.llvm.org/bugs/>
References: <bug-9164-206@http.llvm.org/bugs/>
Message-ID: <20110213191303.1E7322A6C12E@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #1 from Chris Lattner <clattner at apple.com> 2011-02-13 13:13:02 CST ---
This should be fixed in the upstream code.  A-B != B-A, and gas is compiling
both of these instructions to the same code:

$ cat t.s
fsubp   %st, %st(2)
fsubp   %st(2), %st
$ gcc t.s -c
t.s:2:translating to `fsubp %st,%st(2)'
$ otool -tv t.o 
t.o:
(__TEXT,__text) section
0000000000000000    fsubp    %st,%st(2)
0000000000000002    fsubp    %st,%st(2)

FWIW, darwin cctools has produced an annoying warning about this for a long
time, maybe you should have your gas do something similar to avoid bugs like
this from creeping into your 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  Sun Feb 13 14:52:06 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 13 Feb 2011 14:52:06 -0600 (CST)
Subject: [LLVMbugs] [Bug 9208] New: clang fails to reject invalid typeid
 expression and so crashes later on
Message-ID: <bug-9208-206@http.llvm.org/bugs/>

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

           Summary: clang fails to reject invalid typeid expression and so
                    crashes later on
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: seth.cantrell at gmail.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


#include <typeinfo>

template<typename T> void foo() {};

int main() {
    typeid(foo<int>);
}

The above is invalid (at least according to g++) but since clang accepts it
clang tries to generate the type's name using its name mangling logic and
therefore hits the following assert:

Assertion failed: (false && "Overloaded and dependent types shouldn't get to
name mangling"), function mangleType, file ItaniumMangle.cpp, line 1303.

g++'s output is:

typeinfo_assert.c++: In function ?int main()?:
typeinfo_assert.c++:6: error: insufficient contextual information to determine
type

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 13 14:56:10 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 13 Feb 2011 14:56:10 -0600 (CST)
Subject: [LLVMbugs] [Bug 9113] subreg regalloc miscompile
In-Reply-To: <bug-9113-206@http.llvm.org/bugs/>
References: <bug-9113-206@http.llvm.org/bugs/>
Message-ID: <20110213205610.2A32E2A6C12F@llvm.org>

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

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

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

--- Comment #12 from Jakob Stoklund Olesen <stoklund at 2pi.dk> 2011-02-13 14:56:09 CST ---
The codegen peephole pass is breaking SSA form. Note %vreg5 is used before its
definition:

# After codegen peephole optimization pass:
# Machine code for function main:
Function Live Outs: %EAX

BB#0: derived from LLVM BB %entry
        %vreg0<def> = MOVZX32rm8 %RIP, 1, %noreg, <ga:@g_14>, %noreg;
mem:LD1[@g_14] GR32:%vreg0
        %vreg1<def> = COPY %vreg0:sub_8bit; GR8:%vreg1 GR32:%vreg0
        %vreg2<def> = MOVSX32rr8 %vreg1; GR32:%vreg2 GR8:%vreg1
        %vreg21<def> = COPY %vreg5:sub_32bit; GR32:%vreg21 GR64:%vreg5
        %vreg20<def> = COPY %vreg21:sub_8bit; GR8:%vreg20 GR32:%vreg21
        %vreg3<def> = INC8r %vreg20, %EFLAGS<imp-def,dead>; GR8:%vreg3,%vreg20
        %vreg19<def> = COPY %vreg2:sub_8bit; GR8:%vreg19 GR32:%vreg2
        %vreg4<def> = XOR8rr %vreg3, %vreg19, %EFLAGS<imp-def,dead>;
GR8:%vreg4,%vreg3,%vreg19
        %vreg5<def> = MOVSX64rr32 %vreg2<kill>; GR64:%vreg5 GR32:%vreg2

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

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 13 16:31:38 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 13 Feb 2011 16:31:38 -0600 (CST)
Subject: [LLVMbugs] [Bug 9209] New: Poor quality message from
	-Woverloaded-virtual
Message-ID: <bug-9209-206@http.llvm.org/bugs/>

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

           Summary: Poor quality message from -Woverloaded-virtual
           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


Given the following code (the strange formatting just helps show the problem:)

struct Y
{
    virtual void f(
    int);
};

struct X : public Y
{
    void f(
    double);
};

clang++ -Woverloaded-virtual gives the warning:

t.cc:9:7: warning: 'X::f' hides overloaded virtual function
      [-Woverloaded-virtual]
        void f(
             ^
t.cc:3:15: note: hidden overloaded virtual function 'Y::f' declared here
        virtual void f(
                     ^

It would be very helpful to me if clang outputed the type of X::f and Y::f. In
the code base I am looking at I am having trouble tracing the macros and
typedefs, and the types look the same to me.

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

From bugzilla-daemon at llvm.org  Sun Feb 13 17:34:43 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 13 Feb 2011 17:34:43 -0600 (CST)
Subject: [LLVMbugs] [Bug 9210] New: trivial program that does
 vector-of-double to vector-of-float conversion crashes x86 codegen
Message-ID: <bug-9210-206@http.llvm.org/bugs/>

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

           Summary: trivial program that does vector-of-double to
                    vector-of-float conversion crashes x86 codegen
           Product: new-bugs
           Version: trunk
          Platform: PC
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: matt at pharr.org
                CC: llvmbugs at cs.uiuc.edu


The following program crashes llc (both 2.8 and the dev tree (last synced a day
or two ago)):

define <4 x float> @f(<4 x double>) nounwind {
entry:
  %double2float.i = fptrunc <4 x double> %0 to <4 x float>
  ret <4 x float> %double2float.i
}

2.8 gives me this stack trace:

% llc x.ll
UNREACHABLE executed!
0  llc               0x0000000100927412 std::_Rb_tree<llvm::sys::Path,
llvm::sys::Path, std::_Identity<llvm::sys::Path>, std::less<llvm::sys::Path>,
std::allocator<llvm::sys::Path>
>::_M_erase(std::_Rb_tree_node<llvm::sys::Path>*) + 11730
1  llc               0x0000000100927f33 std::_Rb_tree<llvm::sys::Path,
llvm::sys::Path, std::_Identity<llvm::sys::Path>, std::less<llvm::sys::Path>,
std::allocator<llvm::sys::Path>
>::_M_erase(std::_Rb_tree_node<llvm::sys::Path>*) + 14579
2  libSystem.B.dylib 0x00007fff8385567a _sigtramp + 26
3  libSystem.B.dylib 000000000000000000 _sigtramp + 2088413600
4  llc               0x00000001009273d6 std::_Rb_tree<llvm::sys::Path,
llvm::sys::Path, std::_Identity<llvm::sys::Path>, std::less<llvm::sys::Path>,
std::allocator<llvm::sys::Path>
>::_M_erase(std::_Rb_tree_node<llvm::sys::Path>*) + 11670
5  llc               0x0000000100905f1d llvm::APInt::ugt(llvm::APInt const&)
const + 9661
6  llc               0x00000001004427cd llvm::DenseMap<llvm::SDValue,
llvm::SDValue, llvm::DenseMapInfo<llvm::SDValue>,
llvm::DenseMapInfo<llvm::SDValue> >::insert(std::pair<llvm::SDValue,
llvm::SDValue> const&) + 54509
7  llc               0x0000000100429933
llvm::TargetLowering::getRegisterType(llvm::LLVMContext&, llvm::EVT) const +
208419
8  llc               0x000000010042adb6
llvm::TargetLowering::getRegisterType(llvm::LLVMContext&, llvm::EVT) const +
213670
9  llc               0x00000001004f9774
llvm::TargetLowering::getNumRegisters(llvm::LLVMContext&, llvm::EVT) const +
13556
10 llc               0x00000001004fafe4
llvm::TargetLowering::getNumRegisters(llvm::LLVMContext&, llvm::EVT) const +
19812
11 llc               0x00000001004fb5e2
llvm::TargetLowering::getNumRegisters(llvm::LLVMContext&, llvm::EVT) const +
21346
12 llc               0x00000001004fbea8
llvm::TargetLowering::getNumRegisters(llvm::LLVMContext&, llvm::EVT) const +
23592
13 llc               0x00000001005c56bd
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&) + 2237
14 llc               0x00000001008713b0 llvm::BasicBlockPass::~BasicBlockPass()
+ 28256
15 llc               0x000000010087146b llvm::BasicBlockPass::~BasicBlockPass()
+ 28443
16 llc               0x0000000100872b22 llvm::BasicBlockPass::~BasicBlockPass()
+ 34258
17 llc               0x0000000100872e23 llvm::BasicBlockPass::~BasicBlockPass()
+ 35027
18 llc               0x0000000100872ebd llvm::BasicBlockPass::~BasicBlockPass()
+ 35181
19 llc               0x000000010002330a std::_Rb_tree<void const*,
std::pair<void const* const, llvm::PassInfo const*>,
std::_Select1st<std::pair<void const* const, llvm::PassInfo const*> >,
std::less<void const*>, std::allocator<std::pair<void const* const,
llvm::PassInfo const*> > >::_M_insert_unique(std::pair<void const* const,
llvm::PassInfo const*> const&) + 10170
20 llc               0x0000000100021ec8 std::_Rb_tree<void const*,
std::pair<void const* const, llvm::PassInfo const*>,
std::_Select1st<std::pair<void const* const, llvm::PassInfo const*> >,
std::less<void const*>, std::allocator<std::pair<void const* const,
llvm::PassInfo const*> > >::_M_insert_unique(std::pair<void const* const,
llvm::PassInfo const*> const&) + 4984
21 llc               0x0000000000000002 std::_Rb_tree<void const*,
std::pair<void const* const, llvm::PassInfo const*>,
std::_Select1st<std::pair<void const* const, llvm::PassInfo const*> >,
std::less<void const*>, std::allocator<std::pair<void const* const,
llvm::PassInfo const*> > >::_M_insert_unique(std::pair<void const* const,
llvm::PassInfo const*> const&) + 4294833330
Stack dump:
0.    Program arguments: llc x.ll 
1.    Running pass 'Function Pass Manager' on module 'x.ll'.
2.    Running pass 'X86 DAG->DAG Instruction Selection' on function '@f'
[1]    69663 illegal hardware instruction  llc x.ll

and the dev tree gives me this:


SplitVectorOperand Op #0: 0x103045010: v4f32 = fp_round 0x103044e10,
0x103044f10 [ORD=1] [ID=0]

Do not know how to split this operator's operand!
UNREACHABLE executed at LegalizeVectorTypes.cpp:978!
0  llc               0x00000001009f7461 PrintStackTrace(void*) + 38
1  llc               0x00000001009f7a1c SignalHandler(int) + 254
2  libSystem.B.dylib 0x00007fff8385567a _sigtramp + 26
3  libSystem.B.dylib 0x0000000000000001 _sigtramp + 2088413601
4  llc               0x000000010002ad29 raise + 27
5  llc               0x000000010002ad39 abort + 14
6  llc               0x00000001009e3d83 llvm::report_fatal_error(llvm::Twine
const&) + 0
7  llc               0x000000010047403c
llvm::DAGTypeLegalizer::SplitVectorOperand(llvm::SDNode*, unsigned int) + 636
8  llc               0x0000000100459364 llvm::DAGTypeLegalizer::run() + 1354
9  llc               0x0000000100459b60 llvm::SelectionDAG::LegalizeTypes() +
66
10 llc               0x000000010050f7c2
llvm::SelectionDAGISel::CodeGenAndEmitDAG() + 970
11 llc               0x0000000100511986
llvm::SelectionDAGISel::SelectBasicBlock(llvm::ilist_iterator<llvm::Instruction
const>, llvm::ilist_iterator<llvm::Instruction const>, bool&) + 230
12 llc               0x0000000100512181
llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) + 2041
13 llc               0x000000010051281e
llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) + 762
14 llc               0x0000000100619aeb
llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 85
15 llc               0x0000000100929b16
llvm::FPPassManager::runOnFunction(llvm::Function&) + 350
16 llc               0x0000000100929ce9
llvm::FPPassManager::runOnModule(llvm::Module&) + 81
17 llc               0x00000001009297e6
llvm::MPPassManager::runOnModule(llvm::Module&) + 384
18 llc               0x000000010092af97
llvm::PassManagerImpl::run(llvm::Module&) + 111
19 llc               0x000000010092aff9 llvm::PassManager::run(llvm::Module&) +
33
20 llc               0x000000010002e013 main + 2305
21 llc               0x000000010002d0f8 start + 52
Stack dump:
0.    Program arguments: /Users/mmp/llvm-dev/bin/llc x.ll 
1.    Running pass 'Function Pass Manager' on module 'x.ll'.
2.    Running pass 'X86 DAG->DAG Instruction Selection' on function '@f'
[1]    69678 illegal hardware instruction  ~/llvm-dev/bin/llc x.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  Sun Feb 13 20:56:22 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 13 Feb 2011 20:56:22 -0600 (CST)
Subject: [LLVMbugs] [Bug 9211] New: osx binaries changed from 32bit to 64bit
Message-ID: <bug-9211-206@http.llvm.org/bugs/>

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

           Summary: osx binaries changed from 32bit to 64bit
           Product: Documentation
           Version: 2.7
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: General docs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: eric.crahen at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Hey, I noticed that 2.7 and 2.8 the OSX binaries you release on the website
changed from 32bit to 64bit. I think some of the labels on the website are
confusing - but hopefully, there's a way to still get my hands on a 32bit
version.


Here's a link from http://llvm.org/releases/download.html#2.8:

LLVM-GCC 4.2 Front End Binaries for MacOS X/x86 (Darwin 10) 
http://llvm.org/releases/2.8/llvm-gcc-4.2-2.8-x86_64-apple-darwin10.tar.gz


Here's a link from http://llvm.org/releases/download.html#2.6:

LLVM-GCC 4.2 Front End Binaries for MacOS X/x86 (Darwin 9 )
http://llvm.org/releases/2.6/llvm-gcc-4.2-2.6-i386-darwin9.tar.gz

The link in the 2.8 example is labeled "MacOS X/x86" but it should probably be
"MacOS X/x86_64" since this seems to actually be a 64 bit binary now.

Is there a way I could continue to get 32 bit binaries?

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 13 22:23:03 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 13 Feb 2011 22:23:03 -0600 (CST)
Subject: [LLVMbugs] [Bug 9212] New: Missed feature in llvm::getLocationInfo
 (can't retrieve function's debugging information)
Message-ID: <bug-9212-206@http.llvm.org/bugs/>

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

           Summary: Missed feature in llvm::getLocationInfo (can't
                    retrieve function's debugging information)
           Product: libraries
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Global Analyses
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: art.oriented at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=6159)
 --> (http://llvm.org/bugs/attachment.cgi?id=6159)
My simple modification

'llvm::getLocationInfo' can't retrieve the dbg info of 'Function' (while
instructions and global variables are working) because it looks like that it
wasn't simply implemented yet. I don't have an access to update the patch, so
I'd like to let you know via this system.


Z:\dev\my-llvm\lib\Analysis>diff -u  DebugInfo.cpp DebugInfo_old.cpp
--- DebugInfo.cpp       2011-02-09 15:15:39 -0500
+++ DebugInfo_old.cpp   2011-02-13 23:19:27 -0500
@@ -1592,23 +1592,6 @@
   return 0;
 }

-/// Find the debug info descriptor corresponding to this function.
-static Value *findDbgSubprogramDeclare(Function *V) {
-  const Module *M = V->getParent();
-  NamedMDNode *NMD = M->getNamedMetadata("llvm.dbg.sp");
-  if (!NMD)
-    return 0;
-
-  for (unsigned i = 0, e = NMD->getNumOperands(); i != e; ++i) {
-    DIDescriptor DIG(cast<MDNode>(NMD->getOperand(i)));
-    if (!DIG.isSubprogram())
-      continue;
-    if (DISubprogram(DIG).getFunction() == V)
-      return DIG;
-  }
-  return 0;
-}
-
 /// Finds the llvm.dbg.declare intrinsic corresponding to this value if any.
 /// It looks through pointer casts too.
 static const DbgDeclareInst *findDbgDeclare(const Value *V) {
@@ -1646,17 +1629,6 @@

     StringRef D = Var.getDisplayName();
     if (!D.empty())
-      DisplayName = D;
-    LineNo = Var.getLineNumber();
-    Unit = Var.getCompileUnit();
-    TypeD = Var.getType();
-  } else if (Function *F = dyn_cast<Function>(const_cast<Value*>(V))){
-    Value *DIF = findDbgSubprogramDeclare(F);
-    if (!DIF) return false;
-    DISubprogram Var(cast<MDNode>(DIF));
-
-    StringRef D = Var.getDisplayName();
-    if (!D.empty())
       DisplayName = D;
     LineNo = Var.getLineNumber();
     Unit = Var.getCompileUnit();

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 13 22:50:51 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 13 Feb 2011 22:50:51 -0600 (CST)
Subject: [LLVMbugs] [Bug 9133] clang emits crashing code at -O0
In-Reply-To: <bug-9133-206@http.llvm.org/bugs/>
References: <bug-9133-206@http.llvm.org/bugs/>
Message-ID: <20110214045051.C4F792A6C12D@llvm.org>

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

John Regehr <regehr at cs.utah.edu> changed:

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

--- Comment #9 from John Regehr <regehr at cs.utah.edu> 2011-02-13 22:50:51 CST ---
Works for me 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  Sun Feb 13 23:10:02 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 13 Feb 2011 23:10:02 -0600 (CST)
Subject: [LLVMbugs] [Bug 9213] New: Static initializers (C++) are not called
 with Microsoft Visual Studio Linker
Message-ID: <bug-9213-206@http.llvm.org/bugs/>

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

           Summary: Static initializers (C++) are not called with
                    Microsoft Visual Studio Linker
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Windows NT
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Linker
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: art.oriented at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Static initializers in C++, defined by @llvm.global_ctors are not called when
object files are linked by MSVC linker. I've attached a simple test file. Other
tool chains (MinGW gcc) are okay in Windows.

The attached file should print out:
"foo_initializer"
"11"

I'm unclear which component is culprit for this bug. Please move this bug
reporting if better component section fits.



[1] MSVC C++ - Okay
>cl ctor.cpp  (Calling MSVC C++ compiler and linker)
>ctor.exe
foo_initializer
11


[2] MinGW-gcc - Okay
>gcc ctor.cpp -o ctor.exe (MinGW gcc)
>ctor.exe
foo_initializer
11


[3] MinGW-llvm-gcc - Okay
>llvm-gcc ctor.cpp -o ctor.exe (MinGW gcc)
Z:\dev\MinGW\bin/ld.exe: Warning: type of symbol `_main' changed from 32 to 512
in R:\temp/ccMNSXGt.o

>ctor.exe
foo_initializer
11


[4] Clang - NOT okay (Clang will call MSVC's "link.exe")
>clang ctor.cpp -o ctor.exe
>ctor.exe
1
===> Static initializer wasn't called.

>clang ctor.cpp -c -o ctor.o
>gcc -o ctor.exe ctor.o
>ctor.exe
foo_initializer
11

===> However, linking with gcc's is okay.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 14 00:31:01 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 14 Feb 2011 00:31:01 -0600 (CST)
Subject: [LLVMbugs] [Bug 9210] trivial program that does vector-of-double to
 vector-of-float conversion crashes x86 codegen
In-Reply-To: <bug-9210-206@http.llvm.org/bugs/>
References: <bug-9210-206@http.llvm.org/bugs/>
Message-ID: <20110214063101.44A482A6C12D@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #1 from Chris Lattner <clattner at apple.com> 2011-02-14 00:31:00 CST ---
Fixed in r125482.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 14 00:35:39 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 14 Feb 2011 00:35:39 -0600 (CST)
Subject: [LLVMbugs] [Bug 9211] osx binaries changed from 32bit to 64bit
In-Reply-To: <bug-9211-206@http.llvm.org/bugs/>
References: <bug-9211-206@http.llvm.org/bugs/>
Message-ID: <20110214063539.290B12A6C12E@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #1 from Chris Lattner <clattner at apple.com> 2011-02-14 00:35:38 CST ---
That is somewhat pedantic, but ok, I changed the web page to indicate that they
are x86-64 binaries in r125483.  No, we are not  building them 32-bit, sorry. 
You should be able to build them yourself to suit custom configs that the
prebuilt binaries don't cover.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 14 00:42:59 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 14 Feb 2011 00:42:59 -0600 (CST)
Subject: [LLVMbugs] [Bug 9174] problems with "Clang" CFE Internals Manual
	web-page
In-Reply-To: <bug-9174-206@http.llvm.org/bugs/>
References: <bug-9174-206@http.llvm.org/bugs/>
Message-ID: <20110214064259.2B3B22A6C12D@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #1 from Chris Lattner <clattner at apple.com> 2011-02-14 00:42:58 CST ---
Fixed in r125484, 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 Feb 14 01:14:43 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 14 Feb 2011 01:14:43 -0600 (CST)
Subject: [LLVMbugs] [Bug 8705] clang doesn't handle friend member functions
	correctly
In-Reply-To: <bug-8705-206@http.llvm.org/bugs/>
References: <bug-8705-206@http.llvm.org/bugs/>
Message-ID: <20110214071443.6A35B2A6C130@llvm.org>

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

John McCall <rjmccall at apple.com> changed:

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

--- Comment #2 from John McCall <rjmccall at apple.com> 2011-02-14 01:14:42 CST ---
Fixed in r125485.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 14 01:30:08 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 14 Feb 2011 01:30:08 -0600 (CST)
Subject: [LLVMbugs] [Bug 9046] memory unsafety bug
In-Reply-To: <bug-9046-206@http.llvm.org/bugs/>
References: <bug-9046-206@http.llvm.org/bugs/>
Message-ID: <20110214073008.8F91F2A6C12C@llvm.org>

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

John Regehr <regehr at cs.utah.edu> changed:

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

--- Comment #2 from John Regehr <regehr at cs.utah.edu> 2011-02-14 01:30:08 CST ---
Works for me 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 Feb 14 02:04:33 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 14 Feb 2011 02:04:33 -0600 (CST)
Subject: [LLVMbugs] [Bug 9214] New: Convert APIs to use ArrayRef
Message-ID: <bug-9214-206@http.llvm.org/bugs/>

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

           Summary: Convert APIs to use ArrayRef
           Product: libraries
           Version: 1.0
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Core LLVM classes
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: clattner at apple.com
                CC: llvmbugs at cs.uiuc.edu


Various LLVM APIs (such as the Constant*::get APIs, the
GetElementPtrInst::Create methods, IRBuilder CreateGEP method, etc) that take
multiple input values take std::vectors, and some now also can take a pointer
to the start of an array and a count (for use with SmallVector).  The new
ArrayRef class subsumes both of these uses and is more convenient to use.

The implementation side of these should switch to use a FoldingSet (tracked by
PR1210), eliminating the temporary std::vector stored in various maps.

Also, ConstantExpr::getIndices() should be changed to return an ArrayRef.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 14 06:55:59 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 14 Feb 2011 06:55:59 -0600 (CST)
Subject: [LLVMbugs] [Bug 9215] New: Reassociate zaps nsw/nuw flags even if
 it doesn't do anything
Message-ID: <bug-9215-206@http.llvm.org/bugs/>

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

           Summary: Reassociate zaps nsw/nuw flags even if it doesn't do
                    anything
           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


Testcase:
define i32 @add(i32 %x, i32 %y) {
  %s = add nsw i32 %x, %y
  ret i32 %s
}

$ opt -reassociate -S -o - nsw.ll 
; ModuleID = 'nsw.ll'

define i32 @add(i32 %x, i32 %y) {
  %s = add i32 %y, %x
  ret i32 %s
}

What would be great (and should automatically fix this) would be to have
reassociate add a nsw/nuw flag to the results of its reassociations if all
operations that participated were nsw/nuw.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 14 08:49:54 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 14 Feb 2011 08:49:54 -0600 (CST)
Subject: [LLVMbugs] [Bug 9216] New: Endless loop in instcombine
Message-ID: <bug-9216-206@http.llvm.org/bugs/>

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

           Summary: Endless loop in instcombine
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: Scalar Optimizations
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: nadav.rotem at intel.com
                CC: llvmbugs at cs.uiuc.edu


We hit an endless loop inside instcombine. 

Can be reproduces by running opt -instcombine on the following code:

target triple = "x86_64-unknown-linux-gnu"

declare <4 x float> @foo(i8*, i32, i32)
declare void @bar(i8*, i32, i32, <4 x float>)

define void @m_387(i8* noalias nocapture %A, i8* nocapture %B) nounwind {
entry:
  %load_call = call <4 x float> @foo(i8* %A, i32 3, i32 0) nounwind
  %0 = shufflevector <4 x float> %load_call, <4 x float> undef, <4 x i32> <i32
3, i32 3, i32 3, i32 3>
  %bitcast19 = bitcast <4 x float> %0 to <4 x i32>
  %1 = icmp ne <4 x i32> %bitcast19, zeroinitializer
  %movcsext20 = sext <4 x i1> %1 to <4 x i32>
  %tmp2389 = xor <4 x i32> %movcsext20, <i32 -1, i32 -1, i32 -1, i32 -1>
  %movcand25 = and <4 x i32> %tmp2389, <i32 undef, i32 undef, i32 undef, i32
-1>
  %movcor26 = or <4 x i32> %movcand25, zeroinitializer
  %2 = bitcast <4 x i32> %movcor26 to <4 x float>
  %3 = shufflevector <4 x float> zeroinitializer, <4 x float> %2, <4 x i32>
<i32 0, i32 1, i32 2, i32 7>
  call void @bar(i8* %A, i32 0, i32 3, <4 x float> %3) nounwind
  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  Mon Feb 14 10:04:22 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 14 Feb 2011 10:04:22 -0600 (CST)
Subject: [LLVMbugs] [Bug 9217] New: llvm should use comdat
Message-ID: <bug-9217-206@http.llvm.org/bugs/>

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

           Summary: llvm should use comdat
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: ASSIGNED
          Severity: normal
          Priority: P
         Component: Common Code Generator Code
        AssignedTo: rafael.espindola at gmail.com
        ReportedBy: rafael.espindola at gmail.com
                CC: llvmbugs at cs.uiuc.edu


llvm will currently produce linkonce. We should move to the newer comdat. Some
advantages are:

*) We can group related items in the same comdat.
*) The gold plugin interface supports comdats, but not linkonce

See http://sourceware.org/bugzilla/show_bug.cgi?id=12488

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 14 10:58:35 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 14 Feb 2011 10:58:35 -0600 (CST)
Subject: [LLVMbugs] [Bug 9218] New: malformed program causes infinite loop
 in InstCombiner
Message-ID: <bug-9218-206@http.llvm.org/bugs/>

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

           Summary: malformed program causes infinite loop in InstCombiner
           Product: new-bugs
           Version: trunk
          Platform: PC
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: matt at pharr.org
                CC: llvmbugs at cs.uiuc.edu


Given this (simplified from the original and thus sort of nonsensical) code:

%vec2x2 = type { <2 x double>, <2 x double> }

define %vec2x2 @__split(double) nounwind alwaysinline {
  %vba = insertelement <2 x double> undef, double %0, i32 2
  ret <2 x double> %vba, <2 x double> %vba
}

If I run opt on it as follows:

% ~/llvm-dev/bin/opt -O3 bug.ll -o /dev/null

I get an infinite loop (or at least an extremely long runtime); the stack
suggests that it's gotten stuck in InstCombiner.

Note that the insertelement instruction is trying to insert into offset 2 of a
2 element vector--i.e. it's out of bounds.  If I change that "i32 2" to "i32
1", then it runs fine.

Beyond fixing the issue in InstCombiner, it would probably be nice to have the
verifier note this error; if I run opt with just -verify, it doesn't issue any
errors for 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  Mon Feb 14 11:04:31 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 14 Feb 2011 11:04:31 -0600 (CST)
Subject: [LLVMbugs] [Bug 9138] Missing builtins used in gcc 4.4.5 cmath
	header
In-Reply-To: <bug-9138-206@http.llvm.org/bugs/>
References: <bug-9138-206@http.llvm.org/bugs/>
Message-ID: <20110214170431.E29FD2A6C12C@llvm.org>

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

Jeffrey Yasskin <jyasskin at google.com> changed:

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

--- Comment #7 from Jeffrey Yasskin <jyasskin at google.com> 2011-02-14 11:04:31 CST ---
Committed as r125492. 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 Feb 14 11:15:43 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 14 Feb 2011 11:15:43 -0600 (CST)
Subject: [LLVMbugs] [Bug 9219] New: Possible false positive with
 -Wcast-align and #pragma pack(push, 2)
Message-ID: <bug-9219-206@http.llvm.org/bugs/>

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

           Summary: Possible false positive with -Wcast-align and #pragma
                    pack(push, 2)
           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: sean at rogue-research.com
                CC: llvmbugs at cs.uiuc.edu


Consider this C code:

--------
#include <CoreServices/CoreServices.h>

int main(void)
{
    FSCatalogInfo catalogInfo = {};
    FileInfo* fileInfo = (FileInfo*)(&catalogInfo.finderInfo);
    (void)fileInfo;

    return 0;
}
--------

With -Wcast-align clang says:

test.c:6:23: warning: cast from 'UInt8 (*)[16]' to 'FileInfo *' (aka
'struct FileInfo *')
      increases required alignment from 1 to 2 [-Wcast-align]
        FileInfo* fileInfo = (FileInfo*)(&catalogInfo.finderInfo);
                             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

I think this is maybe a false positive, though I'm not sure.

a) The docs for the FSCatalogInfo struct say:

  /*
   * kFSCatInfoFinderInfo / file type, creator, flags, location. 
   * Coerce to a File/FolderInfo to use.
   */
  UInt8               finderInfo[16];

Implying that the cast should be safe.

b) Files.h starts with #pragma pack(push, 2).  I'm thinking maybe clang does
not take that into account.


If clang is indeed correct here, then I'll file a Radar against
CarbonCore/Files.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 Feb 14 12:24:52 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 14 Feb 2011 12:24:52 -0600 (CST)
Subject: [LLVMbugs] [Bug 9220] New: OpenCV 2.2 is not compiled using clang
Message-ID: <bug-9220-206@http.llvm.org/bugs/>

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

           Summary: OpenCV 2.2 is not compiled using clang
           Product: clang
           Version: unspecified
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: release blocker
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: yoavhacohen at gmail.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


Please see details here:
https://code.ros.org/trac/opencv/ticket/708
https://code.ros.org/trac/opencv/ticket/746

The same code compiles properly using GCC 4.2 and LLVM 1.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 evan.cheng at apple.com  Mon Feb 14 12:29:40 2011
From: evan.cheng at apple.com (Evan Cheng)
Date: Mon, 14 Feb 2011 10:29:40 -0800
Subject: [LLVMbugs] TEST2
Message-ID: <41C8992B-4376-4122-B234-B993D5FE3162@apple.com>


From bugzilla-daemon at llvm.org  Mon Feb 14 12:30:18 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 14 Feb 2011 12:30:18 -0600 (CST)
Subject: [LLVMbugs] [Bug 9220] OpenCV 2.2 is not compiled using clang
In-Reply-To: <bug-9220-206@http.llvm.org/bugs/>
References: <bug-9220-206@http.llvm.org/bugs/>
Message-ID: <20110214183018.C47F72A6C12D@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #1 from Douglas Gregor <dgregor at apple.com> 2011-02-14 12:30:18 CST ---
Both links refer to Clang 2.8. I'm fairly certain that we've already fixed this
particular issue with top-of-tree Clang, but there isn't enough information
here for me to be certain.

Please re-open the bug if top-of-tree Clang still rejects this code, and, if
so, provide a small, self-contained  example of 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  Mon Feb 14 14:05:39 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 14 Feb 2011 14:05:39 -0600 (CST)
Subject: [LLVMbugs] [Bug 9221] New: crash on friend
Message-ID: <bug-9221-206@http.llvm.org/bugs/>

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

           Summary: crash on friend
           Product: clang
           Version: trunk
          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


Clang crashes on the following code

struct AutoGCRooter {
  void trace(void *trc);
};
class AutoIdArray : private AutoGCRooter {
  friend void AutoGCRooter::trace(void *trc);
  void * idArray;
};
void AutoGCRooter::trace(void *trc) {
 void *ida = static_cast<AutoIdArray *>(this)->idArray;
}

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 14 15:51:05 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 14 Feb 2011 15:51:05 -0600 (CST)
Subject: [LLVMbugs] [Bug 8854] Codegen peephole pass moves uses before
	definitions
In-Reply-To: <bug-8854-206@http.llvm.org/bugs/>
References: <bug-8854-206@http.llvm.org/bugs/>
Message-ID: <20110214215105.2A8112A6C12E@llvm.org>

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

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

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

--- Comment #6 from Evan Cheng <evan.cheng at apple.com> 2011-02-14 15:51:04 CST ---
Fixed: r125523

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 14 16:13:47 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 14 Feb 2011 16:13:47 -0600 (CST)
Subject: [LLVMbugs] [Bug 9139] CodeGen/ARM/vector-DAGCombine.ll fails
In-Reply-To: <bug-9139-206@http.llvm.org/bugs/>
References: <bug-9139-206@http.llvm.org/bugs/>
Message-ID: <20110214221347.5D0E02A6C124@llvm.org>

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

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

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

--- Comment #1 from Bob Wilson <bob.wilson at apple.com> 2011-02-14 16:13:46 CST ---
Fixed in svn 125525 by specifying a triple for the test.  The i64_buildvector
test relies on the alignment of i64 and f64 types being the same, which is true
for Darwin but not AAPCS.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 14 17:21:58 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 14 Feb 2011 17:21:58 -0600 (CST)
Subject: [LLVMbugs] [Bug 9221] crash on friend
In-Reply-To: <bug-9221-206@http.llvm.org/bugs/>
References: <bug-9221-206@http.llvm.org/bugs/>
Message-ID: <20110214232158.53C5E2A6C12E@llvm.org>

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

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> 2011-02-14 17:21:58 CST ---
Fixed in r125532.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 14 19:25:38 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 14 Feb 2011 19:25:38 -0600 (CST)
Subject: [LLVMbugs] [Bug 9222] New: -tailcallopt misses optimization for
 default(CallingConv::C) calling conversion
Message-ID: <bug-9222-206@http.llvm.org/bugs/>

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

           Summary: -tailcallopt misses optimization for
                    default(CallingConv::C) calling conversion
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Keywords: code-quality
          Severity: normal
          Priority: P
         Component: Backend: X86
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: geek4civic at gmail.com
                CC: llvmbugs at cs.uiuc.edu


I understand -tailcallopt enables "fastcc" as "guaranteed tailcall", to emit
fastcc functions as callee stack rewind. It is known to work well.

In contrast, it seems -tailcallopt disables tailjmp optimization for default
calling conversions. I guess it would be misoptimization.

In X86ISelLowering.cpp:

static bool IsTailCallConvention(CallingConv::ID CC) {
  return (CC == CallingConv::Fast || CC == CallingConv::GHC);
}

X86TargetLowering::IsEligibleForTailCallOptimization(),

  if (GuaranteedTailCallOpt) {
    if (IsTailCallConvention(CalleeCC) && CCMatch)
      return true;
    return false;
  }

It seems CallingConv::C would be missed.


; example
define void @caller_c() nounwind {
entry:
 tail call void @callee_c()
 ret void
}
declare void @callee_c() nounwind

define fastcc void @caller_f() nounwind {
entry:
 tail call fastcc void @callee_f()
 ret void
}
declare fastcc void @callee_f() nounwind


; llc -mtriple=x86_64-linux #(w/o -tailcallopt)
caller_c:
        jmp     callee_c                # TAILCALL
caller_f:
        jmp     callee_f                # TAILCALL

; llc -mtriple=x86_64-linux -tailcallopt
caller_c:
        pushq   %rax
        callq   callee_c
        popq    %rax
        ret
caller_f:
        pushq   %rax       # bug 8925
        popq    %rax
        jmp     callee_f                # TAILCALL

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 14 20:26:34 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 14 Feb 2011 20:26:34 -0600 (CST)
Subject: [LLVMbugs] [Bug 9223] New: Assertion `isReg() && "This is not a
 register operand!"' failed.
Message-ID: <bug-9223-206@http.llvm.org/bugs/>

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

           Summary: Assertion `isReg() && "This is not a register
                    operand!"' failed.
           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


[regehr at gamow tmp003]$ clang -O2 small.c
small.c:10:14: warning: '&&' within '||' [-Wlogical-op-parentheses]
  return si2 || si1 && si2 ? si1 : (si1 % si2);
             ^  ~~~~~~~~~~
small.c:10:14: note: place parentheses around the '&&' expression to silence
      this warning
  return si2 || si1 && si2 ? si1 : (si1 % si2);
             ^
                (         )
clang:
/uusoc/exports/scratch/regehr/z/compiler-build/llvm-r125546/include/llvm/MC/MCInst.h:59:
unsigned int llvm::MCOperand::getReg() const: Assertion `isReg() && "This is
not a register operand!"' failed.
0  clang           0x00000000017ffe6f
1  clang           0x00000000018020e2
2  libpthread.so.0 0x00007ffff7bd2190
3  libc.so.6       0x00007ffff6ed74b5 gsignal + 53
4  libc.so.6       0x00007ffff6edaf50 abort + 384
5  libc.so.6       0x00007ffff6ed0481 __assert_fail + 241
6  clang           0x00000000011cae74
7  clang           0x00000000011cdc56
8  clang           0x00000000017a3e63
9  clang           0x00000000017b0048
llvm::MCObjectStreamer::EmitInstruction(llvm::MCInst const&) + 376
10 clang           0x0000000001136173
11 clang           0x0000000001345498 llvm::AsmPrinter::EmitFunctionBody() +
264
12 clang           0x000000000112e8ad
13 clang           0x0000000001748a1d
llvm::FPPassManager::runOnFunction(llvm::Function&) + 557
14 clang           0x0000000001748b1b
llvm::FPPassManager::runOnModule(llvm::Module&) + 75
15 clang           0x000000000174a244
llvm::MPPassManager::runOnModule(llvm::Module&) + 500
16 clang           0x000000000174a3b7 llvm::PassManagerImpl::run(llvm::Module&)
+ 167
17 clang           0x0000000000814d68
clang::EmitBackendOutput(clang::Diagnostic&, clang::CodeGenOptions const&,
clang::TargetOptions const&, llvm::Module*, clang::BackendAction,
llvm::raw_ostream*) + 1720
18 clang           0x0000000000811fcb
clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) + 251
19 clang           0x000000000092d833 clang::ParseAST(clang::Sema&, bool) + 291
20 clang           0x0000000000811744 clang::CodeGenAction::ExecuteAction() +
68
21 clang           0x00000000006f7625
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 357
22 clang           0x00000000006d275c
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1276
23 clang           0x00000000006c9eab cc1_main(char const**, char const**, char
const*, void*) + 539
24 clang           0x00000000006d189d main + 4685
25 libc.so.6       0x00007ffff6ec2abd __libc_start_main + 253
26 clang           0x00000000006c85d9
Stack dump:
0.    Program arguments:
/uusoc/exports/scratch/regehr/z/compiler-install/llvm-gcc-r125546-install/bin/clang
-cc1 -triple x86_64-unknown-linux-gnu -emit-obj -disable-free -main-file-name
small.c -mrelocation-model static -mdisable-fp-elim -masm-verbose
-mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version
2.20 -momit-leaf-frame-pointer -resource-dir
/uusoc/exports/scratch/regehr/z/compiler-install/llvm-gcc-r125546-install/bin/../lib/clang/2.9
-O2 -ferror-limit 19 -fmessage-length 80 -fgnu-runtime
-fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-d2qNAa.o -x c small.c 
1.    <eof> parser at end of file
2.    Code generation
3.    Running pass 'Function Pass Manager' on module 'small.c'.
4.    Running pass 'X86 AT&T-Style Assembly Printer' on function '@int322'
clang: error: unable to execute command: Aborted
clang: error: clang frontend command failed due to signal 1 (use -v to see
invocation)

[regehr at gamow tmp003]$ clang -v

clang version 2.9 (trunk 125546)
Target: x86_64-unknown-linux-gnu
Thread model: posix

[regehr at gamow tmp003]$ cat small.c


static int
foo (long si1, int si2)
{
  return si1 ^ si2 & si1 ^ si1 ^ si2 & ~0 - si2 ^ si2 < 0 ? : si1 - si2;
}

static int
bar (long si1, int si2)
{
  return si2 || si1 && si2 ? si1 : (si1 % si2);
}

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

int g_29;

void int322 (int8p_83)
{
  unsigned long l_88 = 0xBAE6652566A56D10LL;
  int *l_96 = &g_29;
  *l_96 =
    bar (1 > 1,
     1) >=
    baz (foo
     (l_88, bar (l_88, +g_29)
      || l_88 ^ l_88), -2L);
}

int
main (void)
{
  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  Tue Feb 15 03:14:22 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 15 Feb 2011 03:14:22 -0600 (CST)
Subject: [LLVMbugs] [Bug 9216] Endless loop in instcombine
In-Reply-To: <bug-9216-206@http.llvm.org/bugs/>
References: <bug-9216-206@http.llvm.org/bugs/>
Message-ID: <20110215091422.C9EF12A6C12D@llvm.org>

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

Nadav Rotem <nadav.rotem at intel.com> changed:

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

--- Comment #3 from Nadav Rotem <nadav.rotem at intel.com> 2011-02-15 03:14:22 CST ---
Fixed in 125557.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 15 06:03:48 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 15 Feb 2011 06:03:48 -0600 (CST)
Subject: [LLVMbugs] [Bug 9224] New: spaces are not escaped in -MM output
Message-ID: <bug-9224-206@http.llvm.org/bugs/>

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

           Summary: spaces are not escaped in -MM output
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: frrrwww at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=6164)
 --> (http://llvm.org/bugs/attachment.cgi?id=6164)
sample incorrect dependency file

When outputing makefile rules, include paths containing spaces are not escaped,
resulting in make failing to use the generated output 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  Tue Feb 15 07:30:29 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 15 Feb 2011 07:30:29 -0600 (CST)
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: <20110215133029.5451F2A6C124@llvm.org>

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

Jonas B?low <jbulow-llvm at jongel.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
                 CC|                            |jbulow-llvm at jongel.net
         Resolution|FIXED                       |

--- Comment #8 from Jonas B?low <jbulow-llvm at jongel.net> 2011-02-15 07:30:28 CST ---
I can reproduce this problem on clang/llvm as of today (trunk 125563):

$ clang++ -v
clang version 2.9 (trunk 125563)
Target: i386-pc-linux-gnu
Thread model: posix

$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=10.10
DISTRIB_CODENAME=maverick
DISTRIB_DESCRIPTION="Ubuntu 10.10"

$ uname -a
Linux jonasbu-linux 2.6.35-23-generic-pae #41-Ubuntu SMP Wed Nov 24 10:35:46
UTC 2010 i686 GNU/Linux

$ clang++ -o test test.cc
/tmp/cc-tW5koo.o: In function `main':
test.cc:(.text+0x9c): undefined reference to `std::istream::seekg(long,
std::_Ios_Seekdir)'
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 Feb 15 10:21:33 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 15 Feb 2011 10:21:33 -0600 (CST)
Subject: [LLVMbugs] [Bug 9225] New: Cannot compile code
Message-ID: <bug-9225-206@http.llvm.org/bugs/>

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

           Summary: Cannot compile code
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: grzegorz.dabrowski at gmail.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


Following code is accepted by clang 2.8 and gcc-4.4, but rejected by clang
trunk (r125563).

$ cat template.cpp 
template<typename Definition>
class AVLTree  {
public:
    class ConstIterator;

    class Iterator  {
    public:
        void Remove()
        {
            ConstIterator::fTreeIterator.Remove();
        }
    };
};


$ clang++ template.cpp -c
template.cpp:10:19: error: no member named 'fTreeIterator' in
'AVLTree::ConstIterator'
                        ConstIterator::fTreeIterator.Remove();
                        ~~~~~~~~~~~~~~~^
1 error 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  Tue Feb 15 11:25:13 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 15 Feb 2011 11:25:13 -0600 (CST)
Subject: [LLVMbugs] [Bug 9212] Missed feature in llvm::getLocationInfo
 (can't retrieve function's debugging information)
In-Reply-To: <bug-9212-206@http.llvm.org/bugs/>
References: <bug-9212-206@http.llvm.org/bugs/>
Message-ID: <20110215172513.ABAD22A6C12C@llvm.org>

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

Devang Patel <dpatel at apple.com> changed:

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

--- Comment #2 from Devang Patel <dpatel at apple.com> 2011-02-15 11:25:13 CST ---
Fixed. r125567.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 15 11:52:59 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 15 Feb 2011 11:52:59 -0600 (CST)
Subject: [LLVMbugs] [Bug 9226] New: Invalid code leads to assertion "FIXME:
 Only type template names supported here"
Message-ID: <bug-9226-206@http.llvm.org/bugs/>

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

           Summary: Invalid code leads to assertion "FIXME: Only type
                    template names supported here"
           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


The following invalid code snippet, derived from an invalid boost testcase:

template<typename a>
void nt()
{ nt<>:: }


Leads to the backtrace:

clang: ParseExprCXX.cpp:228: bool
clang::Parser::ParseOptionalCXXScopeSpecifier(clang::CXXScopeSpec&,
clang::ParsedType, bool, bool*): Assertion `false && "FIXME: Only type template
names supported here"' failed.
0  clang           0x000000000236eb71
1  clang           0x000000000236e964
2  libpthread.so.0 0x00007f23b0d608f0
3  libc.so.6       0x00007f23b004fa75 gsignal + 53
4  libc.so.6       0x00007f23b00535c0 abort + 384
5  libc.so.6       0x00007f23b0048941 __assert_fail + 241
6  clang           0x000000000129f634
clang::Parser::ParseOptionalCXXScopeSpecifier(clang::CXXScopeSpec&,
clang::OpaquePtr<clang::QualType>, bool, bool*) + 2312
7  clang           0x000000000127d120
clang::Parser::TryAnnotateTypeOrScopeToken(bool) + 1668
8  clang           0x0000000001276fdd
clang::Parser::isCXXDeclarationSpecifier() + 139
9  clang           0x0000000001275d8e clang::Parser::isCXXSimpleDeclaration() +
34
10 clang           0x0000000001275d69
clang::Parser::isCXXDeclarationStatement() + 85
11 clang           0x00000000012759a4 clang::Parser::isDeclarationStatement() +
52
12 clang           0x000000000126fe90
clang::Parser::ParseStatementOrDeclaration(clang::ASTOwningVector<clang::Stmt*,
32u>&, bool) + 480
13 clang           0x0000000001271170
clang::Parser::ParseCompoundStatementBody(bool) + 306
14 clang           0x0000000001274a44
clang::Parser::ParseFunctionStatementBody(clang::Decl*) + 220
15 clang           0x000000000127c18c
clang::Parser::ParseFunctionDefinition(clang::Parser::ParsingDeclarator&,
clang::Parser::ParsedTemplateInfo const&) + 1036
16 clang           0x00000000012aa234
clang::Parser::ParseSingleDeclarationAfterTemplate(unsigned int,
clang::Parser::ParsedTemplateInfo const&,
clang::Parser::ParsingDeclRAIIObject&, clang::SourceLocation&,
clang::AccessSpecifier) + 1280
17 clang           0x00000000012a9ce6
clang::Parser::ParseTemplateDeclarationOrSpecialization(unsigned int,
clang::SourceLocation&, clang::AccessSpecifier) + 996
18 clang           0x00000000012a986b
clang::Parser::ParseDeclarationStartingWithTemplate(unsigned int,
clang::SourceLocation&, clang::AccessSpecifier) + 175
19 clang           0x0000000001281e8f
clang::Parser::ParseDeclaration(clang::ASTOwningVector<clang::Stmt*, 32u>&,
unsigned int, clang::SourceLocation&,
clang::Parser::ParsedAttributesWithRange&) + 185
20 clang           0x000000000127b318
clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&,
clang::Parser::ParsingDeclSpec*) + 1200
21 clang           0x000000000127add8
clang::Parser::ParseTopLevelDecl(clang::OpaquePtr<clang::DeclGroupRef>&) + 210
22 clang           0x00000000012638b0 clang::ParseAST(clang::Sema&, bool) + 328
23 clang           0x0000000000fc1945 clang::ASTFrontendAction::ExecuteAction()
+ 263
24 clang           0x000000000110d025 clang::CodeGenAction::ExecuteAction() +
951
25 clang           0x0000000000fc1596 clang::FrontendAction::Execute() + 320
26 clang           0x0000000000fa85bf
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 751
27 clang           0x0000000000f544bd
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 858
28 clang           0x0000000000f46349 cc1_main(char const**, char const**, char
const*, void*) + 1032
29 clang           0x0000000000f4fa24 main + 499
30 libc.so.6       0x00007f23b003ac4d __libc_start_main + 253
31 clang           0x0000000000f459b9
Stack dump:
0.      Program arguments: /llvmdebug/bin/clang -cc1 -triple
x86_64-unknown-linux-gnu -emit-obj -mrelax-all -disable-free -main-file-name
t.cc -mrelocation-model static -mdisable-fp-elim -masm-verbose
-mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version
2.20.1 -momit-leaf-frame-pointer -resource-dir /llvmdebug/bin/../lib/clang/2.9
-ferror-limit 19 -fmessage-length 173 -fexceptions -fgnu-runtime
-fdiagnostics-show-option -fcolor-diagnostics -o t.o -x c++ t.cc 
1.      t.cc:3:3: at annotation token 
2.      t.cc:3:1: parsing function body 'nt'
3.      t.cc:3:1: in compound statement ('{}')
clang: error: unable to execute command: Aborted
clang: error: clang frontend command failed due to signal 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 Feb 15 13:07:44 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 15 Feb 2011 13:07:44 -0600 (CST)
Subject: [LLVMbugs] [Bug 9227] New: clang emits bool template type values as
 '0' and '1', not 'false' and 'true'
Message-ID: <bug-9227-206@http.llvm.org/bugs/>

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

           Summary: clang emits bool template type values as '0' and '1',
                    not 'false' and 'true'
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: matthewbg at google.com
                CC: llvmbugs at cs.uiuc.edu, nlewycky at google.com,
                    dgregor at apple.com


This code is invalid:

 template<bool B> struct Foo { };
 template<> struct Foo<true> { typedef int foo; };
 int test() {
   Foo<sizeof(int) == sizeof(double)>::foo i;
 }

though the technique is commonly found in compiler_assert / static_assert type
code. Clang's error is really good, but not quite perfect:

 test.cc:5:39: error: no member named 'foo' in 'Foo<0>'
   Foo<sizeof(int) == sizeof(double)>::foo i;
   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^
 1 error generated.

That error is in 'Foo<0>'? No. It's 'Foo<false>' please.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 15 13:12:17 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 15 Feb 2011 13:12:17 -0600 (CST)
Subject: [LLVMbugs] [Bug 9228] New: InstCombine crash (from GEP with NULL
 pointer used in computing object size?)
Message-ID: <bug-9228-206@http.llvm.org/bugs/>

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

           Summary: InstCombine crash (from GEP with NULL pointer used in
                    computing object size?)
           Product: new-bugs
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: matt at pharr.org
                CC: llvmbugs at cs.uiuc.edu


If I run "opt -instcombine bug.ll -o /dev/null" with the following program:

define <4 x float> @f(i32 %a) nounwind alwaysinline {
entry:
  %dim = insertelement <4 x i32> undef, i32 %a, i32 0
  %dim30 = insertelement <4 x i32> %dim, i32 %a, i32 1
  %dim31 = insertelement <4 x i32> %dim30, i32 %a, i32 2
  %dim32 = insertelement <4 x i32> %dim31, i32 %a, i32 3

  %offset_ptr = getelementptr <4 x float>* null, i32 1
  %offset_int = ptrtoint <4 x float>* %offset_ptr to i64
  %sizeof32 = trunc i64 %offset_int to i32

  %smearinsert33 = insertelement <4 x i32> undef, i32 %sizeof32, i32 0
  %smearinsert34 = insertelement <4 x i32> %smearinsert33, i32 %sizeof32, i32 1
  %smearinsert35 = insertelement <4 x i32> %smearinsert34, i32 %sizeof32, i32 2
  %smearinsert36 = insertelement <4 x i32> %smearinsert35, i32 %sizeof32, i32 3

  %delta_scale = mul <4 x i32> %dim32, %smearinsert36
  %offset_delta = add <4 x i32> zeroinitializer, %delta_scale

  %offset_varying_delta = add <4 x i32> %offset_delta, undef

  ret <4 x float> undef
}

I get the following crash from TOT of the dev branch:

opt: /home/mmp/llvm-dev-src/include/llvm/Support/Casting.h:213: typename
llvm::cast_retty<X, Y*>::ret_type llvm::cast_or_null(Y*) [with X =
llvm::ConstantInt, Y = llvm::Constant]: Assertion `isa<X>(Val) &&
"cast_or_null<Ty>() argument of incompatible type!"' failed.
0  opt             0x0000000000d0ffb5
1  opt             0x0000000000d0fda8
2  libpthread.so.0 0x00002b6774e478f0
3  libc.so.6       0x00002b6775a3ca75 gsignal + 53
4  libc.so.6       0x00002b6775a405c0 abort + 384
5  libc.so.6       0x00002b6775a35941 __assert_fail + 241
6  opt             0x0000000000977f57 llvm::cast_retty<llvm::ConstantInt,
llvm::Constant*>::ret_type llvm::cast_or_null<llvm::ConstantInt,
llvm::Constant>(llvm::Constant*) + 92
7  opt             0x00000000009a7e04 bool
llvm::PatternMatch::cst_pred_ty<llvm::PatternMatch::is_one>::match<llvm::Value>(llvm::Value*)
+ 114
8  opt             0x0000000000a7a32e bool
llvm::PatternMatch::match<llvm::Value,
llvm::PatternMatch::cst_pred_ty<llvm::PatternMatch::is_one> >(llvm::Value*,
llvm::PatternMatch::cst_pred_ty<llvm::PatternMatch::is_one> const&) + 35
9  opt             0x0000000000a75063
10 opt             0x0000000000a7547e llvm::SimplifyMulInst(llvm::Value*,
llvm::Value*, llvm::TargetData const*, llvm::DominatorTree const*) + 58
11 opt             0x00000000009ab28c
12 opt             0x000000000096d87c llvm::InstVisitor<llvm::InstCombiner,
llvm::Instruction*>::visit(llvm::Instruction&) + 376
13 opt             0x000000000096ab67
14 opt             0x000000000096af7f
15 opt             0x0000000000c8e095
llvm::FPPassManager::runOnFunction(llvm::Function&) + 407
16 opt             0x0000000000c8e2b2
llvm::FPPassManager::runOnModule(llvm::Module&) + 102
17 opt             0x0000000000c8e5e5
llvm::MPPassManager::runOnModule(llvm::Module&) + 459
18 opt             0x0000000000c8eae3 llvm::PassManagerImpl::run(llvm::Module&)
+ 125
19 opt             0x0000000000c8f039 llvm::PassManager::run(llvm::Module&) +
39
20 opt             0x0000000000839b3f main + 4242
21 libc.so.6       0x00002b6775a27c4d __libc_start_main + 253
22 opt             0x000000000082a779
Stack dump:
0.    Program arguments: opt -instcombine x.ll -o /dev/null 
1.    Running pass 'Function Pass Manager' on module 'x.ll'.
2.    Running pass 'Combine redundant instructions' on function '@f'
[1]    5247 abort      opt -instcombine x.ll -o /dev/null

The problem seems to be related to the GEP with a NULL base pointer:

#3  0x0000000000977f57 in llvm::cast_or_null<llvm::ConstantInt, llvm::Constant>
(Val=0x12819a8)
    at /home/mmp/llvm-dev-src/include/llvm/Support/Casting.h:213
213      assert(isa<X>(Val) && "cast_or_null<Ty>() argument of incompatible
type!");
(gdb) call Val->dump()
i32 ptrtoint (<4 x float>* getelementptr (<4 x float>* null, i32 1) to i32)
(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 Feb 15 14:44:01 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 15 Feb 2011 14:44:01 -0600 (CST)
Subject: [LLVMbugs] [Bug 8685] [MC assembler] does not support square
	bracket notation
In-Reply-To: <bug-8685-206@http.llvm.org/bugs/>
References: <bug-8685-206@http.llvm.org/bugs/>
Message-ID: <20110215204401.DD0122A6C12D@llvm.org>

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

Roman Divacky <rdivacky at freebsd.org> changed:

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

--- Comment #8 from Roman Divacky <rdivacky at freebsd.org> 2011-02-15 14:44:01 CST ---
Fixed in r125595.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 15 14:54:44 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 15 Feb 2011 14:54:44 -0600 (CST)
Subject: [LLVMbugs] [Bug 9229] New: We now classify this use of friend as
	invalid
Message-ID: <bug-9229-206@http.llvm.org/bugs/>

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

           Summary: We now classify this use of friend as invalid
           Product: clang
           Version: trunk
          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


After 125485 we reject

class LIns {
  void staticSanityCheck();
};
class LInsOp2 {
private:
  friend class LIns;
  LIns ins;
};
void LIns::staticSanityCheck() {
  void nano_static_assert(int arg[__builtin_offsetof(LInsOp2, ins)]);
}

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 15 15:06:19 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 15 Feb 2011 15:06:19 -0600 (CST)
Subject: [LLVMbugs] [Bug 9217] llvm should use comdat
In-Reply-To: <bug-9217-206@http.llvm.org/bugs/>
References: <bug-9217-206@http.llvm.org/bugs/>
Message-ID: <20110215210619.8909D2A6C12D@llvm.org>

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

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

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

--- Comment #1 from Rafael ?vila de Esp?ndola <rafael.espindola at gmail.com> 2011-02-15 15:06:19 CST ---
Fixed in 125526.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 15 15:30:15 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 15 Feb 2011 15:30:15 -0600 (CST)
Subject: [LLVMbugs] [Bug 9229] We now classify this use of friend as invalid
In-Reply-To: <bug-9229-206@http.llvm.org/bugs/>
References: <bug-9229-206@http.llvm.org/bugs/>
Message-ID: <20110215213015.05D682A6C12E@llvm.org>

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

Ted Kremenek <kremenek at apple.com> changed:

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

--- Comment #3 from Ted Kremenek <kremenek at apple.com> 2011-02-15 15:30:14 CST ---
Rafael: Does this still reproduce 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  Tue Feb 15 15:48:31 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 15 Feb 2011 15:48:31 -0600 (CST)
Subject: [LLVMbugs] [Bug 9229] We now classify this use of friend as invalid
In-Reply-To: <bug-9229-206@http.llvm.org/bugs/>
References: <bug-9229-206@http.llvm.org/bugs/>
Message-ID: <20110215214831.EBC432A6C12E@llvm.org>

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

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

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

--- Comment #4 from Rafael ?vila de Esp?ndola <rafael.espindola at gmail.com> 2011-02-15 15:48:31 CST ---
Sorry, the full test is

void nano_static_assert(int arg[1]);
class LIns {
  void staticSanityCheck();
};
class LInsOp2 {
private:
  friend class LIns;
  LIns ins;
};
void LIns::staticSanityCheck() {
  void nano_static_assert(int arg[__builtin_offsetof(LInsOp2, ins)]);
}


It was missing the first line.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 15 16:52:06 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 15 Feb 2011 16:52:06 -0600 (CST)
Subject: [LLVMbugs] [Bug 9229] We now classify this use of friend as invalid
In-Reply-To: <bug-9229-206@http.llvm.org/bugs/>
References: <bug-9229-206@http.llvm.org/bugs/>
Message-ID: <20110215225206.0AA982A6C124@llvm.org>

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

John McCall <rjmccall at apple.com> changed:

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

--- Comment #6 from John McCall <rjmccall at apple.com> 2011-02-15 16:52:05 CST ---
r125609.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 15 17:03:59 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 15 Feb 2011 17:03:59 -0600 (CST)
Subject: [LLVMbugs] [Bug 9230] New: "Unresolved overloaded function"
	assertion failure
Message-ID: <bug-9230-206@http.llvm.org/bugs/>

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

           Summary: "Unresolved overloaded function" assertion failure
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++0x
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: marc.glisse at normalesup.org
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


$ clang++ -fsyntax-only -std=c++0x a.cc

template <class > struct remove_reference {
};
template <class _Tp> struct remove_reference<_Tp&> {
};
struct pair {
        template<class _Tuple, class = typename remove_reference<_Tuple >::type
> pair(_Tuple&& ) {
        }
};
template <class > struct basic_ostream;
typedef basic_ostream<char> ostream;
template <class _CharT> void endl(basic_ostream<_CharT>& __os) {
}
void operator<<(ostream& os, const pair& ) {
        os << endl;
}



clang: /data/repos/llvm/tools/clang/lib/Sema/SemaTemplateDeduction.cpp:971:
clang::Sema::TemplateDeductionResult DeduceTemplateArguments(clang::Sema&,
clang::TemplateParameterList*, clang::QualType, clang::QualType,
clang::sema::TemplateDeductionInfo&,
llvm::SmallVectorImpl<clang::DeducedTemplateArgument>&, unsigned int, bool,
llvm::SmallVectorImpl<RefParamPartialOrderingComparison>*): Assertion `Arg !=
S.Context.OverloadTy && "Unresolved overloaded function"' failed.
0  clang           0x000000000179c47f
1  clang           0x000000000179e6e2
2  libpthread.so.0 0x00007fef5ea15f60
3  libc.so.6       0x00007fef5dd28165 gsignal + 53
4  libc.so.6       0x00007fef5dd2af70 abort + 384
5  libc.so.6       0x00007fef5dd212b1 __assert_fail + 241
6  clang           0x0000000000ac1de9
7  clang           0x0000000000ac1144
8  clang           0x0000000000ac3119
9  clang           0x0000000000ac34dd
10 clang           0x0000000000ac48ab
clang::Sema::DeduceTemplateArguments(clang::ClassTemplatePartialSpecializationDecl*,
clang::TemplateArgumentList const&, clang::sema::TemplateDeductionInfo&) + 219
11 clang           0x0000000000add50e
clang::Sema::InstantiateClassTemplateSpecialization(clang::SourceLocation,
clang::ClassTemplateSpecializationDecl*, clang::TemplateSpecializationKind,
bool) + 542
12 clang           0x0000000000b16f81
clang::Sema::RequireCompleteType(clang::SourceLocation, clang::QualType,
clang::PartialDiagnostic const&, std::pair<clang::SourceLocation,
clang::PartialDiagnostic>) + 1201
13 clang           0x0000000000b177df
clang::Sema::RequireCompleteType(clang::SourceLocation, clang::QualType,
clang::PartialDiagnostic const&) + 79
14 clang           0x000000000091bae5
clang::Sema::RequireCompleteDeclContext(clang::CXXScopeSpec&,
clang::DeclContext*) + 437
15 clang           0x0000000000a84de4
clang::Sema::CheckTypenameType(clang::ElaboratedTypeKeyword,
clang::NestedNameSpecifier*, clang::IdentifierInfo const&,
clang::SourceLocation, clang::SourceRange, clang::SourceLocation) + 132
16 clang           0x0000000000ae09e6
17 clang           0x0000000000ada45b
18 clang           0x0000000000adb54f
19 clang           0x0000000000adbc12
clang::Sema::SubstType(clang::TypeSourceInfo*,
clang::MultiLevelTemplateArgumentList const&, clang::SourceLocation,
clang::DeclarationName) + 66
20 clang           0x0000000000a786aa
21 clang           0x0000000000a7c025
clang::Sema::SubstDefaultTemplateArgumentIfAvailable(clang::TemplateDecl*,
clang::SourceLocation, clang::SourceLocation, clang::Decl*,
llvm::SmallVectorImpl<clang::TemplateArgument>&) + 213
22 clang           0x0000000000abd593
clang::Sema::FinishTemplateArgumentDeduction(clang::FunctionTemplateDecl*,
llvm::SmallVectorImpl<clang::DeducedTemplateArgument>&, unsigned int,
clang::FunctionDecl*&, clang::sema::TemplateDeductionInfo&) + 1683
23 clang           0x0000000000ac7baa
clang::Sema::DeduceTemplateArguments(clang::FunctionTemplateDecl*,
clang::TemplateArgumentListInfo const*, clang::Expr**, unsigned int,
clang::FunctionDecl*&, clang::sema::TemplateDeductionInfo&) + 1706
24 clang           0x0000000000a52b11
clang::Sema::AddTemplateOverloadCandidate(clang::FunctionTemplateDecl*,
clang::DeclAccessPair, clang::TemplateArgumentListInfo const*, clang::Expr**,
unsigned int, clang::OverloadCandidateSet&, bool) + 353
25 clang           0x0000000000a531d8
26 clang           0x0000000000a53b3c
27 clang           0x0000000000a4f82f
28 clang           0x0000000000a4fc06
29 clang           0x0000000000a52555
clang::Sema::AddOverloadCandidate(clang::FunctionDecl*, clang::DeclAccessPair,
clang::Expr**, unsigned int, clang::OverloadCandidateSet&, bool, bool) + 1477
30 clang           0x0000000000a55ee2
clang::Sema::AddFunctionCandidates(clang::UnresolvedSetImpl const&,
clang::Expr**, unsigned int, clang::OverloadCandidateSet&, bool) + 130
31 clang           0x0000000000a63ab9
clang::Sema::CreateOverloadedBinOp(clang::SourceLocation, unsigned int,
clang::UnresolvedSetImpl const&, clang::Expr*, clang::Expr*) + 745
32 clang           0x00000000009f9f29 clang::Sema::BuildBinOp(clang::Scope*,
clang::SourceLocation, clang::BinaryOperatorKind, clang::Expr*, clang::Expr*) +
217
33 clang           0x00000000009fa144 clang::Sema::ActOnBinOp(clang::Scope*,
clang::SourceLocation, clang::tok::TokenKind, clang::Expr*, clang::Expr*) + 196
34 clang           0x00000000008e03ef
clang::Parser::ParseRHSOfBinaryExpression(clang::ActionResult<clang::Expr*,
true>, clang::prec::Level) + 671
35 clang           0x00000000008e307e
clang::Parser::ParseAssignmentExpression() + 46
36 clang           0x00000000008e0ee9 clang::Parser::ParseExpression() + 9
37 clang           0x00000000008b9d85
clang::Parser::ParseStatementOrDeclaration(clang::ASTOwningVector<clang::Stmt*,
32u>&, bool) + 309
38 clang           0x00000000008ba743
clang::Parser::ParseCompoundStatementBody(bool) + 403
39 clang           0x00000000008bad61
clang::Parser::ParseFunctionStatementBody(clang::Decl*) + 145
40 clang           0x00000000008c5d33
clang::Parser::ParseFunctionDefinition(clang::Parser::ParsingDeclarator&,
clang::Parser::ParsedTemplateInfo const&) + 707
41 clang           0x00000000008ccc3f
clang::Parser::ParseDeclGroup(clang::Parser::ParsingDeclSpec&, unsigned int,
bool, clang::SourceLocation*) + 1535
42 clang           0x00000000008c4932
clang::Parser::ParseDeclarationOrFunctionDefinition(clang::Parser::ParsingDeclSpec&,
clang::AccessSpecifier) + 146
43 clang           0x00000000008c4d39
clang::Parser::ParseDeclarationOrFunctionDefinition(clang::ParsedAttributes&,
clang::AccessSpecifier) + 409
44 clang           0x00000000008c6ee2
clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&,
clang::Parser::ParsingDeclSpec*) + 1506
45 clang           0x00000000008c701d
clang::Parser::ParseTopLevelDecl(clang::OpaquePtr<clang::DeclGroupRef>&) + 109
46 clang           0x00000000008ada13 clang::ParseAST(clang::Sema&, bool) + 147
47 clang           0x0000000000673a35
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 357
48 clang           0x000000000064febc
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1276
49 clang           0x0000000000647705 cc1_main(char const**, char const**, char
const*, void*) + 677
50 clang           0x000000000064eec5 main + 4629
51 libc.so.6       0x00007f8a7a87bc4d __libc_start_main + 253
52 clang           0x0000000000645ca9
Stack dump:
0.      Program arguments: /tmp/clang/inst/bin/clang -cc1 -triple
x86_64-unknown-linux-gnu -fsyntax-only -disable-free -main-file-name a.cc
-mrelocation-model static -mdisable-fp-elim -masm-verbose -mconstructor-aliases
-munwind-tables -target-cpu x86-64 -target-linker-version 2.20.1
-momit-leaf-frame-pointer -resource-dir /tmp/clang/inst/bin/../lib/clang/2.9
-std=c++0x -ferror-limit 19 -fmessage-length 158 -fexceptions -fgnu-runtime
-fdiagnostics-show-option -fcolor-diagnostics -x c++ a.cc 
1.      a.cc:14:12: current parser token ';'
2.      a.cc:13:44: parsing function body 'operator<<'
3.      a.cc:13:44: 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  Tue Feb 15 17:11:43 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 15 Feb 2011 17:11:43 -0600 (CST)
Subject: [LLVMbugs] [Bug 9231] New: Assertion failed: (ObjCOrBuiltinID -
 unsigned(tok::NUM_OBJC_KEYWORDS) == ID && "ID too large for field!")
Message-ID: <bug-9231-206@http.llvm.org/bugs/>

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

           Summary: Assertion failed: (ObjCOrBuiltinID -
                    unsigned(tok::NUM_OBJC_KEYWORDS) == ID && "ID too
                    large for field!")
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: FreeBSD
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: pawel.worach at gmail.com
                CC: llvmbugs at cs.uiuc.edu


A Release+Asserts build of clang on FreeBSD started to fail 2863 of it's tests
after one of these commits: 125490 125491 125492.

The host compiler is:
gcc version 4.2.1 20070719  [FreeBSD]

All tests fail with the same assertion:
Assertion failed: (ObjCOrBuiltinID - unsigned(tok::NUM_OBJC_KEYWORDS) == ID &&
"ID too large for field!"), function setBuiltinID, file
/data/buildslave/freebsd-clang-amd64/src-llvm/tools/clang/lib/Basic/../../include/clang/Basic/IdentifierTable.h,
line 183.
Stack dump:
0.    Program arguments:
/data/buildslave/freebsd-clang-amd64/obj/obj-llvm.1/Release+Asserts/bin/clang
-cc1 -analyze -analyzer-experimental-internal-checks -analyzer-check-objc-mem
-analyzer-store=basic -analyzer-constraints=basic -verify
/data/buildslave/freebsd-clang-amd64/src-llvm/tools/clang/test/Analysis/CGColorSpace.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  Tue Feb 15 17:13:43 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 15 Feb 2011 17:13:43 -0600 (CST)
Subject: [LLVMbugs] [Bug 9228] InstCombine crash (from GEP with NULL pointer
 used in computing object size?)
In-Reply-To: <bug-9228-206@http.llvm.org/bugs/>
References: <bug-9228-206@http.llvm.org/bugs/>
Message-ID: <20110215231343.2F7052A6C12D@llvm.org>

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

Nick Lewycky <nlewycky at google.com> changed:

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

--- Comment #1 from Nick Lewycky <nlewycky at google.com> 2011-02-15 17:13:42 CST ---
Fixed in r125613!
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20110214/116520.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 Feb 15 19:10:39 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 15 Feb 2011 19:10:39 -0600 (CST)
Subject: [LLVMbugs] [Bug 9223] Assertion `isReg() && "This is not a register
 operand!"' failed.
In-Reply-To: <bug-9223-206@http.llvm.org/bugs/>
References: <bug-9223-206@http.llvm.org/bugs/>
Message-ID: <20110216011039.49E592A6C12D@llvm.org>

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

Eric Christopher <echristo at gmail.com> changed:

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

--- Comment #4 from Eric Christopher <echristo at gmail.com> 2011-02-15 19:10:38 CST ---
Fixed thusly:

[yendi:Data/sources/llvm] echristo% svn ci
Sending        lib/CodeGen/SelectionDAG/DAGCombiner.cpp
Adding         test/CodeGen/X86/legalize-sub-zero-2.ll
Transmitting file data ..
Committed revision 125631.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 15 19:41:34 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 15 Feb 2011 19:41:34 -0600 (CST)
Subject: [LLVMbugs] [Bug 9177] clang gets confused with alias and asm labels
In-Reply-To: <bug-9177-206@http.llvm.org/bugs/>
References: <bug-9177-206@http.llvm.org/bugs/>
Message-ID: <20110216014134.B11612A6C12D@llvm.org>

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

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> 2011-02-15 19:41:34 CST ---
Fixed by avoiding the \01 prefix when possible.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 15 21:30:35 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 15 Feb 2011 21:30:35 -0600 (CST)
Subject: [LLVMbugs] [Bug 8944] [MC] Integrated assembler doesn't resolve
 local symbol differences
In-Reply-To: <bug-8944-206@http.llvm.org/bugs/>
References: <bug-8944-206@http.llvm.org/bugs/>
Message-ID: <20110216033035.6E6E42A6C12D@llvm.org>

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

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> 2011-02-15 21:30:35 CST ---
Fixed in r125648.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 16 02:03:27 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 16 Feb 2011 02:03:27 -0600 (CST)
Subject: [LLVMbugs] [Bug 7908] clang c++ crash catching an object whose copy
 constructor has a destructible default argument
In-Reply-To: <bug-7908-206@http.llvm.org/bugs/>
References: <bug-7908-206@http.llvm.org/bugs/>
Message-ID: <20110216080327.516B22A6C12E@llvm.org>

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

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> 2011-02-16 02:03:26 CST ---
Fixed in r125661.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 16 04:45:13 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 16 Feb 2011 04:45:13 -0600 (CST)
Subject: [LLVMbugs] [Bug 9232] New: Remove deprecated/removed scanner
 arguments from scan-build
Message-ID: <bug-9232-206@http.llvm.org/bugs/>

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

           Summary: Remove deprecated/removed scanner arguments from
                    scan-build
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Static Analyzer
        AssignedTo: kremenek at apple.com
        ReportedBy: uspoerlein at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Hi,

I think either r125503 or r125611 by akirtzidis broke the 'scan-build' script,
as it will still pass '-analyzer-check-idempotent-operations' and
'-analyzer-check-objc-self-init' to the scanner. Please remove those
invocations from scan-build to make it work again. 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 Feb 16 04:59:42 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 16 Feb 2011 04:59:42 -0600 (CST)
Subject: [LLVMbugs] [Bug 3203] fast and burr schedulers break with complex
	EFLAGS usage
In-Reply-To: <bug-3203-206@http.llvm.org/bugs/>
References: <bug-3203-206@http.llvm.org/bugs/>
Message-ID: <20110216105942.22BF32A6C12E@llvm.org>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

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

--- Comment #7 from Eli Friedman <sharparrow1 at yahoo.com> 2011-02-16 04:59:40 CST ---
Looks up this got fixed by (relatively) recent changes associated with new
EFLAGS handling on x86.  I'll throw together a patch soon.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 16 07:21:48 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 16 Feb 2011 07:21:48 -0600 (CST)
Subject: [LLVMbugs] [Bug 9233] New: Template deduction succeeds despite
 qualifier mismatch
Message-ID: <bug-9233-206@http.llvm.org/bugs/>

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

           Summary: Template deduction succeeds despite qualifier mismatch
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: richard-llvm at metafoo.co.uk
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


In this code:

template<typename T> void f(const T **q);

int main() {
  int **p;
  f(p);
}

clang deduces T = int, then decides the function is not viable because of the
qualifier mismatch. This causes the wrong diagnostic to be issued.
[temp.deduct.call]p4, which allows this sort of qualifier mismatch in other
cases, says:

"The transformed A can be another pointer or pointer to member type that can be
converted to the deduced A via a quali?cation conversion (4.4)."

But "T **" can't be converted to "const T **" via a qualification conversion.


I noticed this while testing:

  int **p;
  const auto **q = p;

which also gives the wrong diagnostic, for the same reason.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 16 09:42:49 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 16 Feb 2011 09:42:49 -0600 (CST)
Subject: [LLVMbugs] [Bug 9234] New: CodeGen/X86 regress tests error on MinGW
Message-ID: <bug-9234-206@http.llvm.org/bugs/>

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

           Summary: CodeGen/X86 regress tests error on MinGW
           Product: new-bugs
           Version: trunk
          Platform: PC
        OS/Version: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: dmalyshev at accesssoftek.com
                CC: llvmbugs at cs.uiuc.edu


Is anybody aware of the regress tests failures on MinGW?
The following tests fail:

    LLVM :: CodeGen/X86/add.ll
    LLVM :: CodeGen/X86/apm.ll
    LLVM :: CodeGen/X86/avoid-lea-scale2.ll
    LLVM :: CodeGen/X86/break-sse-dep.ll
    LLVM :: CodeGen/X86/byval.ll
    LLVM :: CodeGen/X86/byval2.ll
    LLVM :: CodeGen/X86/byval3.ll
    LLVM :: CodeGen/X86/byval4.ll
    LLVM :: CodeGen/X86/byval5.ll
    LLVM :: CodeGen/X86/coalescer-commute2.ll
    LLVM :: CodeGen/X86/codegen-prepare-extload.ll
    LLVM :: CodeGen/X86/constant-pool-remat-0.ll
    LLVM :: CodeGen/X86/constant-pool-sharing.ll
    LLVM :: CodeGen/X86/convert-2-addr-3-addr-inc64.ll
    LLVM :: CodeGen/X86/ctpop-combine.ll
    LLVM :: CodeGen/X86/fast-isel-cmp-branch.ll
    LLVM :: CodeGen/X86/fast-isel-gep.ll
    LLVM :: CodeGen/X86/fold-mul-lohi.ll
    LLVM :: CodeGen/X86/gather-addresses.ll
    LLVM :: CodeGen/X86/h-register-store.ll
    LLVM :: CodeGen/X86/h-registers-0.ll
    LLVM :: CodeGen/X86/i128-ret.ll
    LLVM :: CodeGen/X86/i64-mem-copy.ll
    LLVM :: CodeGen/X86/lea-3.ll
    LLVM :: CodeGen/X86/lea.ll
    LLVM :: CodeGen/X86/lsr-overflow.ll
    LLVM :: CodeGen/X86/lsr-reuse-trunc.ll
    LLVM :: CodeGen/X86/memcmp.ll
    LLVM :: CodeGen/X86/mmx-copy-gprs.ll
    LLVM :: CodeGen/X86/movgs.ll
    LLVM :: CodeGen/X86/optimize-max-3.ll
    LLVM :: CodeGen/X86/peep-vector-extract-concat.ll
    LLVM :: CodeGen/X86/pmulld.ll
    LLVM :: CodeGen/X86/pr9127.ll
    LLVM :: CodeGen/X86/red-zone.ll
    LLVM :: CodeGen/X86/remat-mov-0.ll
    LLVM :: CodeGen/X86/scalar-min-max-fill-operand.ll
    LLVM :: CodeGen/X86/sse-align-0.ll
    LLVM :: CodeGen/X86/sse-align-3.ll
    LLVM :: CodeGen/X86/sse-align-7.ll
    LLVM :: CodeGen/X86/sse-commute.ll
    LLVM :: CodeGen/X86/sse_reload_fold.ll
    LLVM :: CodeGen/X86/stdarg.ll
    LLVM :: CodeGen/X86/stride-nine-with-base-reg.ll
    LLVM :: CodeGen/X86/stride-reuse.ll
    LLVM :: CodeGen/X86/tailcallbyval64.ll
    LLVM :: CodeGen/X86/test-shrink.ll
    LLVM :: CodeGen/X86/use-add-flags.ll
    LLVM :: CodeGen/X86/v2f32.ll
    LLVM :: CodeGen/X86/vec_cast.ll
    LLVM :: CodeGen/X86/vec_set-8.ll
    LLVM :: CodeGen/X86/vec_shuffle-17.ll
    LLVM :: CodeGen/X86/vec_shuffle-37.ll
    LLVM :: CodeGen/X86/widen_load-0.ll
    LLVM :: CodeGen/X86/x86-64-malloc.ll
    LLVM :: CodeGen/X86/xor.ll

The reason of the failures is the same for all, the output from llc
-march=x86-64 is different then expected, because different registers get used.
In some of them tests the generated commands are different as well.

All these tests pass just file for -march=x86.

Is the problem with the code generation for MinGW or with the tests?

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 16 10:44:32 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 16 Feb 2011 10:44:32 -0600 (CST)
Subject: [LLVMbugs] [Bug 9235] New: JIT: uitofp on vector type hits assert
 in X86TargetLowering / SelectionDAG
Message-ID: <bug-9235-206@http.llvm.org/bugs/>

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

           Summary: JIT: uitofp on vector type hits assert in
                    X86TargetLowering / SelectionDAG
           Product: new-bugs
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: matt at pharr.org
                CC: llvmbugs at cs.uiuc.edu


Given this program:

define <4 x float> @f_f(<4 x i32>) nounwind {
entry:
  %uint2float.i = uitofp <4 x i32> %0 to <4 x float>
  ret <4 x float> %uint2float.i
}

If I try to run it with the JIT with the test program below, then I hit the
following assert.  (Note that this happens in the dev branch, but it works fine
with the 2.8 release).

SelectionDAG.cpp:2693: llvm::SDValue llvm::SelectionDAG::getNode(unsigned int,
llvm::DebugLoc, llvm::EVT, llvm::SDValue, llvm::SDValue): Assertion
`N1.getValueType() == N2.getValueType() && N1.getValueType() == VT && "Binary
operator types must match!"' failed.

with the following stack trace:

(gdb) where
#0  0x00002aaaab8d2a75 in *__GI_raise (sig=<value optimized out>) at
../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1  0x00002aaaab8d65c0 in *__GI_abort () at abort.c:92
#2  0x00002aaaab8cb941 in *__GI___assert_fail (
    assertion=0xbc8220 "N1.getValueType() == N2.getValueType() &&
N1.getValueType() == VT && \"Binary operator types must match!\"", file=<value
optimized out>, line=2693, 
    function=0xbcf360 "llvm::SDValue llvm::SelectionDAG::getNode(unsigned int,
llvm::DebugLoc, llvm::EVT, llvm::SDValue, llvm::SDValue)") at assert.c:81
#3  0x00000000005c4bf4 in llvm::SelectionDAG::getNode (this=0x11ce000,
Opcode=47, DL=..., VT=..., N1=..., N2=...)
    at SelectionDAG.cpp:2693
#4  0x00000000004df47d in PerformEXTRACT_VECTOR_ELTCombine (N=0x11f4b00,
DAG=..., TLI=...)
    at X86ISelLowering.cpp:10893
#5  0x00000000004e8279 in llvm::X86TargetLowering::PerformDAGCombine
(this=0x11afb48, N=0x11f4b00, DCI=...)
    at X86ISelLowering.cpp:11948
#6  0x000000000056a999 in combine (this=0x7fffffffd930, N=0x11f4b00) at
DAGCombiner.cpp:1109
#7  0x00000000005697c5 in Run (this=0x7fffffffd930,
AtLevel=llvm::NoIllegalOperations) at DAGCombiner.cpp:966
#8  0x00000000005a0ee8 in llvm::SelectionDAG::Combine (this=0x11ce000,
Level=llvm::NoIllegalOperations, AA=..., 
    OptLevel=llvm::CodeGenOpt::Default) at DAGCombiner.cpp:7573
#9  0x0000000000637ab9 in llvm::SelectionDAGISel::CodeGenAndEmitDAG
(this=0x11ccaa0) at SelectionDAGISel.cpp:585
#10 0x0000000000636bb4 in llvm::SelectionDAGISel::SelectBasicBlock
(this=0x11ccaa0, Begin=..., End=..., 
    HadTailCall=@0x7fffffffddff) at SelectionDAGISel.cpp:439
#11 0x000000000063917e in llvm::SelectionDAGISel::SelectAllBasicBlocks
(this=0x11ccaa0, Fn=...)
    at SelectionDAGISel.cpp:970
#12 0x0000000000636121 in llvm::SelectionDAGISel::runOnMachineFunction
(this=0x11ccaa0, mf=...)
    at SelectionDAGISel.cpp:306
#13 0x0000000000744a19 in llvm::MachineFunctionPass::runOnFunction
(this=0x11ccaa0, F=...)
    at MachineFunctionPass.cpp:33
#14 0x0000000000a75679 in llvm::FPPassManager::runOnFunction (this=0x11a7dd0,
F=...) at PassManager.cpp:1483
#15 0x0000000000a75341 in llvm::FunctionPassManagerImpl::run (this=0x11a7a80,
F=...) at PassManager.cpp:1434
#16 0x0000000000a74ff1 in llvm::FunctionPassManager::run (this=0x11af3a0,
F=...) at PassManager.cpp:1364
#17 0x000000000041a57e in llvm::JIT::jitTheFunction (this=0x11a6d10,
F=0x11a9160, locked=...) at JIT.cpp:661
#18 0x000000000041a457 in llvm::JIT::runJITOnFunctionUnlocked (this=0x11a6d10,
F=0x11a9160, locked=...)
    at JIT.cpp:640
#19 0x000000000041a84d in llvm::JIT::getPointerToFunction (this=0x11a6d10,
F=0x11a9160) at JIT.cpp:697
#20 0x0000000000417dff in main (argc=2, argv=0x7fffffffe5c8) at
build/linux2-debug/test.cpp:42

(Sorry I couldn't get this to reproduce with lli, but the following short
program will reproduce it.)

#include <stdio.h>

#include <llvm/LLVMContext.h>
#include <llvm/Module.h>
#include <llvm/DerivedTypes.h>
#include <llvm/ExecutionEngine/ExecutionEngine.h>
#include <llvm/ExecutionEngine/JIT.h>
#include <llvm/Target/TargetSelect.h>
#include <llvm/Target/TargetOptions.h>
#include <llvm/Target/TargetData.h>
#include <llvm/Analysis/Verifier.h>
#include <llvm/Support/raw_ostream.h>
#include <llvm/Bitcode/ReaderWriter.h>
#include <llvm/Support/MemoryBuffer.h>
#include <llvm/Support/system_error.h>

int main(int argc, char *argv[]) {
    const char *fn = argv[1];

    llvm::InitializeNativeTarget();

    llvm::LLVMContext *ctx = new llvm::LLVMContext;
    llvm::OwningPtr<llvm::MemoryBuffer> buf;
    llvm::error_code err = llvm::MemoryBuffer::getFileOrSTDIN(fn, buf);
    if (err) {
        fprintf(stderr, "Unable to open file \"%s\": %s\n", fn,
err.message().c_str());
        delete ctx;
        return 1;
    }
    std::string bcErr;
    llvm::Module *module = llvm::ParseBitcodeFile(buf.get(), *ctx, &bcErr);
    if (!module) {
        fprintf(stderr, "Bitcode reader failed for \"%s\": %s\n", fn,
bcErr.c_str());
        delete ctx;
        return false;
    }
    llvm::ExecutionEngine *ee = llvm::ExecutionEngine::createJIT(module);
    llvm::Function *func = module->getFunction("f_f");
    assert(func != NULL);

    void *ptr = ee->getPointerToFunction(func);

    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 Feb 16 16:45:57 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 16 Feb 2011 16:45:57 -0600 (CST)
Subject: [LLVMbugs] [Bug 9236] New: Poor diagnostic for conditional
 expression with mismatched types
Message-ID: <bug-9236-206@http.llvm.org/bugs/>

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

           Summary: Poor diagnostic for conditional expression with
                    mismatched types
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: matthewbg at google.com
                CC: llvmbugs at cs.uiuc.edu


>From a Clang user at Google:
"""
#include <cstddef>
class A {};
int main(int argc, char** argv) {
 A a;
 bool b = true;
 A* foo = b ? a : NULL;
 return 0;
}

The bug here is that I meant to write "&a", not "a".  The error that
shows up is:

foo.cc:6:14: error: incompatible operand
types ('A' and 'long')

I was confused at first, because what did I write there that has
anything to do with numbers?  Of course I quickly did realize that
NULL is just 0 and thus a long.

Thought: If you have incompatible operands for the second and third
arguments to the ternary operator, and exactly one of them matches the
surrounding context (as NULL matches the "A* foo =") and the other
doesn't, perhaps the error should point out the incompatibility
between the other argument and the surrounding context rather than
between the two terms?
"""

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 16 17:01:08 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 16 Feb 2011 17:01:08 -0600 (CST)
Subject: [LLVMbugs] [Bug 9237] New: Assertion `KillOps[*SR] == KillOp &&
 "invalid subreg kill flags"' failed
Message-ID: <bug-9237-206@http.llvm.org/bugs/>

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

           Summary: Assertion `KillOps[*SR] == KillOp && "invalid subreg
                    kill flags"' failed
           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: joerg at NetBSD.org
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=6169)
 --> (http://llvm.org/bugs/attachment.cgi?id=6169)
Output of clang -m32 -fPIC -O2 including backtrace

Input and output of "clang -m32 -fPIC -O2" is attached. Problem happens with
-O1 and higher.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 16 18:00:22 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 16 Feb 2011 18:00:22 -0600 (CST)
Subject: [LLVMbugs] [Bug 9178] NRVO after noreturn call causes clang to
 produce invalid module
In-Reply-To: <bug-9178-206@http.llvm.org/bugs/>
References: <bug-9178-206@http.llvm.org/bugs/>
Message-ID: <20110217000022.6F1152A6C12D@llvm.org>

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

Nick Lewycky <nlewycky at google.com> changed:

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

--- Comment #1 from Nick Lewycky <nlewycky at google.com> 2011-02-16 18:00:21 CST ---
Fixed in r125694.
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20110214/038885.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  Wed Feb 16 18:09:41 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 16 Feb 2011 18:09:41 -0600 (CST)
Subject: [LLVMbugs] [Bug 9098] diagnose obvious array out of bounds access
In-Reply-To: <bug-9098-206@http.llvm.org/bugs/>
References: <bug-9098-206@http.llvm.org/bugs/>
Message-ID: <20110217000941.0D2BC2A6C124@llvm.org>

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

Ted Kremenek <kremenek at apple.com> changed:

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

--- Comment #2 from Ted Kremenek <kremenek at apple.com> 2011-02-16 18:09:40 CST ---
We now implement this warning:

t.c:3:3: warning: array index of '100' indexes past the end of an array (that
contains 100 elements) [-Warray-bounds]
  foo[100] = '\0';
  ^   ~~~
t.c:2:2: note: array 'foo' declared here
 char foo[100];
 ^

Went in here:

r125640
r125649

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 16 18:55:40 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 16 Feb 2011 18:55:40 -0600 (CST)
Subject: [LLVMbugs] [Bug 9238] New: overzealous virtual destructor warning
 due to virtual inheritance
Message-ID: <bug-9238-206@http.llvm.org/bugs/>

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

           Summary: overzealous virtual destructor warning due to virtual
                    inheritance
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: nlewycky at google.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


This program:

  class B { public: ~B(); };
  class C : virtual B { public: ~C() { } };

is actually fine (I think), but it triggers the clang warning about virtual
destructors:

  $ llvm/Debug+Asserts/bin/clang -Wnon-virtual-dtor v.cc -fsyntax-only
  v.cc:2:31: warning: 'C' has virtual functions but non-virtual destructor
        [-Wnon-virtual-dtor]
  class C : virtual B { public: ~C() { } };
                                ^
  1 warning generated.

I don't think that's correct in this 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  Wed Feb 16 19:29:35 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 16 Feb 2011 19:29:35 -0600 (CST)
Subject: [LLVMbugs] [Bug 9215] Reassociate zaps nsw/nuw flags even if it
 doesn't do anything
In-Reply-To: <bug-9215-206@http.llvm.org/bugs/>
References: <bug-9215-206@http.llvm.org/bugs/>
Message-ID: <20110217012935.EE0842A6C12D@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #1 from Chris Lattner <clattner at apple.com> 2011-02-16 19:29:35 CST ---
Done in r125700, 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 Feb 16 20:14:58 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 16 Feb 2011 20:14:58 -0600 (CST)
Subject: [LLVMbugs] [Bug 9224] spaces are not escaped in -MM output
In-Reply-To: <bug-9224-206@http.llvm.org/bugs/>
References: <bug-9224-206@http.llvm.org/bugs/>
Message-ID: <20110217021458.6DEDE2A6C124@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #1 from Chris Lattner <clattner at apple.com> 2011-02-16 20:14:58 CST ---
Fixed in r125707, 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 Feb 16 20:43:14 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 16 Feb 2011 20:43:14 -0600 (CST)
Subject: [LLVMbugs] [Bug 9231] Assertion failed: (ObjCOrBuiltinID -
 unsigned(tok::NUM_OBJC_KEYWORDS) == ID && "ID too large for field!")
In-Reply-To: <bug-9231-206@http.llvm.org/bugs/>
References: <bug-9231-206@http.llvm.org/bugs/>
Message-ID: <20110217024314.9465D2A6C12D@llvm.org>

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

Ted Kremenek <kremenek at apple.com> changed:

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

--- Comment #3 from Ted Kremenek <kremenek at apple.com> 2011-02-16 20:43:14 CST ---
Change committed here: r125713

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 16 21:05:38 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 16 Feb 2011 21:05:38 -0600 (CST)
Subject: [LLVMbugs] [Bug 9025] Crash when emitting
 err_member_reference_needs_call for overloaded function
In-Reply-To: <bug-9025-206@http.llvm.org/bugs/>
References: <bug-9025-206@http.llvm.org/bugs/>
Message-ID: <20110217030538.749072A6C12E@llvm.org>

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

Matt Beaumont-Gay <matthewbg at google.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED
         AssignedTo|unassignedclangbugs at nondot. |matthewbg at google.com
                   |org                         |

--- Comment #2 from Matt Beaumont-Gay <matthewbg at google.com> 2011-02-16 21:05:38 CST ---
Fixed in r125714.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 17 04:50:04 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 17 Feb 2011 04:50:04 -0600 (CST)
Subject: [LLVMbugs] [Bug 9239] New: clang trunk - fatal error: error in
 backend: Cannot select: 0x106918d10: v2f64 = X86ISD::MOVLPD 0x10698c910,
 0x1068fd410 [ID=58]
Message-ID: <bug-9239-206@http.llvm.org/bugs/>

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

           Summary: clang trunk - fatal error: error in backend: Cannot
                    select: 0x106918d10: v2f64 = X86ISD::MOVLPD
                    0x10698c910, 0x1068fd410 [ID=58]
           Product: clang
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: LLVM Codegen
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: felix.ritter at mevis.fraunhofer.de
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=6172)
 --> (http://llvm.org/bugs/attachment.cgi?id=6172)
example source file

clang version 2.9 (trunk 125743)
Target: x86_64-apple-darwin10
Thread model: posix

clang fails to compile the attached file which builds fine using gcc 4.2.1

clang++ -c sse_codegen_hang.ii

In file included from mlXMarkerListMaxDistance.cpp:1:
In file included from mlXMarkerListMaxDistance.cpp:14:
In file included from ./mlXMarkerListMaxDistance.h:23:
In file included from
/Users/ritter/Developer.osxresearch/MeVisLab/Standard/Sources/ML/MLBase/mlXMarkerList.h:34:
/Users/ritter/Developer.osxresearch/MeVis/Foundation/Sources/ML/include/mlTreeNode.h:530:147:
warning: 
      conversion from string literal to 'char *' is deprecated
      [-Wdeprecated-writable-strings]
  ..."correctName()"); } return ""; }; }
                                ^
In file included from mlXMarkerListMaxDistance.cpp:1:
mlXMarkerListMaxDistance.cpp:72:25: warning: conversion from string literal to
      'char *' is deprecated [-Wdeprecated-writable-strings]
  char* codePaths[] = { "FPU", "SSE2" };
                        ^
mlXMarkerListMaxDistance.cpp:72:32: warning: conversion from string literal to
      'char *' is deprecated [-Wdeprecated-writable-strings]
  char* codePaths[] = { "FPU", "SSE2" };
                               ^
fatal error: error in backend: Cannot select: 0x106918d10: v2f64 =
      X86ISD::MOVLPD 0x10698c910, 0x1068fd410 [ID=58]

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 17 05:09:39 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 17 Feb 2011 05:09:39 -0600 (CST)
Subject: [LLVMbugs] [Bug 8142] implement -Wenum-compare
In-Reply-To: <bug-8142-206@http.llvm.org/bugs/>
References: <bug-8142-206@http.llvm.org/bugs/>
Message-ID: <20110217110939.85E192A6C12E@llvm.org>

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

Chandler Carruth <chandlerc at gmail.com> changed:

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

--- Comment #1 from Chandler Carruth <chandlerc at gmail.com> 2011-02-17 05:09:39 CST ---
Implemented in r125739.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 17 15:53:46 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 17 Feb 2011 15:53:46 -0600 (CST)
Subject: [LLVMbugs] [Bug 9240] New: Sema::CheckArrayAccess assertion failure
 when building 403.gcc
Message-ID: <bug-9240-206@http.llvm.org/bugs/>

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

           Summary: Sema::CheckArrayAccess assertion failure when building
                    403.gcc
           Product: clang
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: stoklund at 2pi.dk
                CC: llvmbugs at cs.uiuc.edu


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

$ /d/b/Release+Asserts/bin/clang -v
clang version 2.9 (trunk 125781)
Target: i386-apple-darwin10
Thread model: posix
$ /d/b/Release+Asserts/bin/clang -O3 -mllvm -disable-llvm-optzns -m32
-fomit-frame-pointer -mdynamic-no-pic stmt.i
Assertion failed: (BitWidth == RHS.BitWidth && "Bit widths must be same for
comparison"), function slt, file /Volumes/Data/g/llvm/lib/Support/APInt.cpp,
line 552.
0  clang             0x0124eb68 PrintStackTrace(void*) + 40
1  clang             0x0124f1ea SignalHandler(int) + 826
2  libSystem.B.dylib 0x9131445b _sigtramp + 43
3  libSystem.B.dylib 0xffffffff _sigtramp + 1859042255
4  clang             0x0124edfb abort + 27
5  clang             0x0124edd4 __assert_rtn + 100
6  clang             0x01218ffb llvm::APInt::slt(llvm::APInt const&) const +
1243
7  clang             0x002d9f05
clang::Sema::CheckArrayAccess(clang::ArraySubscriptExpr const*) + 421
8  clang             0x003d7320
clang::Sema::CheckAssignmentOperands(clang::Expr*, clang::Expr*&,
clang::SourceLocation, clang::QualType) + 1696
9  clang             0x003d843e
clang::Sema::CreateBuiltinBinOp(clang::SourceLocation,
clang::BinaryOperatorKind, clang::Expr*, clang::Expr*) + 142
10 clang             0x003d95be clang::Sema::BuildBinOp(clang::Scope*,
clang::SourceLocation, clang::BinaryOperatorKind, clang::Expr*, clang::Expr*) +
542
11 clang             0x003c9297 clang::Sema::ActOnBinOp(clang::Scope*,
clang::SourceLocation, clang::tok::TokenKind, clang::Expr*, clang::Expr*) +
2791
12 clang             0x0027fb42
clang::Parser::ParseRHSOfBinaryExpression(clang::ActionResult<clang::Expr*,
true>, clang::prec::Level) + 1874
13 clang             0x0027f3be clang::Parser::ParseAssignmentExpression() +
222
14 clang             0x0027f2b2 clang::Parser::ParseExpression() + 18
15 clang             0x0029975b
clang::Parser::ParseStatementOrDeclaration(clang::ASTOwningVector<clang::Stmt*,
32u>&, bool) + 827
16 clang             0x0029d562 clang::Parser::ParseCompoundStatementBody(bool)
+ 322
17 clang             0x00299505
clang::Parser::ParseStatementOrDeclaration(clang::ASTOwningVector<clang::Stmt*,
32u>&, bool) + 229
18 clang             0x0029adef
clang::Parser::ParseIfStatement(clang::ParsedAttributes&) + 527
19 clang             0x00299877
clang::Parser::ParseStatementOrDeclaration(clang::ASTOwningVector<clang::Stmt*,
32u>&, bool) + 1111
20 clang             0x0029d562 clang::Parser::ParseCompoundStatementBody(bool)
+ 322
21 clang             0x0029e1a7
clang::Parser::ParseFunctionStatementBody(clang::Decl*) + 167
22 clang             0x002a8439
clang::Parser::ParseFunctionDefinition(clang::Parser::ParsingDeclarator&,
clang::Parser::ParsedTemplateInfo const&) + 889
23 clang             0x0026d53e
clang::Parser::ParseDeclGroup(clang::Parser::ParsingDeclSpec&, unsigned int,
bool, clang::SourceLocation*) + 910
24 clang             0x002a7d16
clang::Parser::ParseDeclarationOrFunctionDefinition(clang::Parser::ParsingDeclSpec&,
clang::AccessSpecifier) + 838
25 clang             0x002a7ec7
clang::Parser::ParseDeclarationOrFunctionDefinition(clang::ParsedAttributes&,
clang::AccessSpecifier) + 327
26 clang             0x002a7584
clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&,
clang::Parser::ParsingDeclSpec*) + 2516
27 clang             0x002a6b9d
clang::Parser::ParseTopLevelDecl(clang::OpaquePtr<clang::DeclGroupRef>&) + 205
28 clang             0x00266ab6 clang::ParseAST(clang::Sema&, bool) + 214
29 clang             0x000520ab clang::ASTFrontendAction::ExecuteAction() + 139
30 clang             0x00240c77 clang::CodeGenAction::ExecuteAction() + 903
31 clang             0x00051b61 clang::FrontendAction::Execute() + 289
32 clang             0x00030652
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 1010
33 clang             0x0000afec
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 2780
34 clang             0x0000332b cc1_main(char const**, char const**, char
const*, void*) + 5867
35 clang             0x0000743e main + 1054
36 clang             0x00001c35 start + 53
37 clang             0x00000023 start + 4294960163
Stack dump:
0.    Program arguments: /Volumes/Data/b/Release+Asserts/bin/clang -cc1 -triple
i386-apple-darwin10.0.0 -emit-obj -disable-free -main-file-name stmt.i
-mrelocation-model dynamic-no-pic -pic-level 1 -masm-verbose -target-cpu yonah
-target-linker-version 97.17 -resource-dir
/Volumes/Data/b/Release+Asserts/bin/../lib/clang/2.9 -O3 -ferror-limit 19
-fmessage-length 236 -stack-protector 1 -fblocks -fdiagnostics-show-option
-fcolor-diagnostics -disable-llvm-optzns -o
/var/folders/7i/7ikIVQ+1FxmS1CawLKGczU+++TI/-Tmp-/cc-aQMWZf.o -x cpp-output
stmt.i 
1.    /d/Externals/speccpu2006/benchspec/CPU2006/403.gcc/src/stmt.c:5654:56:
current parser token ';'
2.    /d/Externals/speccpu2006/benchspec/CPU2006/403.gcc/src/stmt.c:5631:1:
parsing function body 'estimate_case_costs'
3.    /d/Externals/speccpu2006/benchspec/CPU2006/403.gcc/src/stmt.c:5631:1: in
compound statement ('{}')
4.    /d/Externals/speccpu2006/benchspec/CPU2006/403.gcc/src/stmt.c:5641:5: in
compound statement ('{}')
clang: error: unable to execute command: Illegal instruction
clang: error: clang frontend command failed due to signal 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  Thu Feb 17 16:10:10 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 17 Feb 2011 16:10:10 -0600 (CST)
Subject: [LLVMbugs] [Bug 8171] Illegal bit field manipulation code generated
 for big endian architectures
In-Reply-To: <bug-8171-206@http.llvm.org/bugs/>
References: <bug-8171-206@http.llvm.org/bugs/>
Message-ID: <20110217221010.DB2872A6C12D@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #8 from Chris Lattner <clattner at apple.com> 2011-02-17 16:10:10 CST ---
Looks great, applied in r125784, 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 Feb 17 17:34:17 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 17 Feb 2011 17:34:17 -0600 (CST)
Subject: [LLVMbugs] [Bug 9057] [REGRESSION] Assertion failed: (AR &&
 "Analysis Resolver is not set"), function initializeAnalysisImpl,
 file PassManager.cpp, line 1045.
In-Reply-To: <bug-9057-206@http.llvm.org/bugs/>
References: <bug-9057-206@http.llvm.org/bugs/>
Message-ID: <20110217233417.A60F92A6C12E@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #5 from Chris Lattner <clattner at apple.com> 2011-02-17 17:34:16 CST ---
This was fixed by r 124287

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 17 17:38:45 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 17 Feb 2011 17:38:45 -0600 (CST)
Subject: [LLVMbugs] [Bug 9019] __builtin_fabs shouldn't lower to libm call
In-Reply-To: <bug-9019-206@http.llvm.org/bugs/>
References: <bug-9019-206@http.llvm.org/bugs/>
Message-ID: <20110217233845.C526B2A6C124@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #1 from Chris Lattner <clattner at apple.com> 2011-02-17 17:38:45 CST ---
This is behaving correctly.  Clang can optimize this out in cases where it
matters, but only if you turn the optimizer on.  Expecting to use builtin_fabs
but not link in libm is somewhat silly.

FWIW, I'm seeing this optimized code on x86-64, it isn't going through integer
regs:


_f:                                     ## @f
    andps    LCPI0_0(%rip), %xmm0
    ret

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 17 18:44:01 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 17 Feb 2011 18:44:01 -0600 (CST)
Subject: [LLVMbugs] [Bug 9240] Sema::CheckArrayAccess assertion failure when
 building 403.gcc
In-Reply-To: <bug-9240-206@http.llvm.org/bugs/>
References: <bug-9240-206@http.llvm.org/bugs/>
Message-ID: <20110218004401.9315A2A6C12E@llvm.org>

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

Ted Kremenek <kremenek at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |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  Thu Feb 17 19:19:49 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 17 Feb 2011 19:19:49 -0600 (CST)
Subject: [LLVMbugs] [Bug 9242] New: Length parameters for the C API should
 be 'size_t', not 'unsigned'.
Message-ID: <bug-9242-206@http.llvm.org/bugs/>

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

           Summary: Length parameters for the C API should be 'size_t',
                    not 'unsigned'.
           Product: libraries
           Version: 2.8
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Core LLVM classes
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: blood.of.life at gmail.com
                CC: llvmbugs at cs.uiuc.edu


A lot of the C wrapper functions take a pointer and a length when expecting a
list of things. For instance, the signature of `LLVMBuildCall`:

    ... LLVMBuildCall(..., LLVMValueRef* Args, unsigned NumArgs,...)

Usually, `unsigned i` declares i as 32 bit unsigned integer. On 32 bit
architectures, this can adequately index a pointer and all is well. On 64 bit
architectures, however, a 64 bit unsigned integer is required to do this. The
size_t type (in cstdint) does this job. In the above example, `NumArgs` should
be declared as `size_t NumArgs`.

Incidentally, this bugs me as I'm using the C API from D. D arrays have a
pointer and a length -- the length is declared as size_t. when using the above,
I can create a D array of LLVMValueRefs and then pass it like

LLVMBuildCall(..., args.ptr, args.length,...)

Except if I'm building for 64 bit, I have to explicitly cast the length to uint
to call LLVM.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 17 19:20:24 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 17 Feb 2011 19:20:24 -0600 (CST)
Subject: [LLVMbugs] [Bug 9240] Sema::CheckArrayAccess assertion failure when
 building 403.gcc
In-Reply-To: <bug-9240-206@http.llvm.org/bugs/>
References: <bug-9240-206@http.llvm.org/bugs/>
Message-ID: <20110218012024.987552A6C12D@llvm.org>

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

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

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

--- Comment #3 from Jakob Stoklund Olesen <stoklund at 2pi.dk> 2011-02-17 19:20:24 CST ---
I am still seeing this on TOT. I used TOT clang to rebuild itself:

$ Release+Asserts/bin/clang -v
clang version 2.9 (trunk 125799)
Target: i386-apple-darwin10
Thread model: posix

$ Release+Asserts/bin/clang -cc1 -triple i386-apple-darwin10.0.0 -emit-obj
-disable-free -main-file-name stmt.i -mrelocation-model dynamic-no-pic
-pic-level 1 -masm-verbose -target-cpu yonah -target-linker-version 97.17
-resource-dir /Volumes/Data/b/Release+Asserts/bin/../lib/clang/2.9 -O3
-ferror-limit 19 -fmessage-length 236 -stack-protector 1 -fblocks
-fdiagnostics-show-option -fcolor-diagnostics -disable-llvm-optzns -x
cpp-output stmt.i
Assertion failed: (BitWidth == RHS.BitWidth && "Bit widths must be same for
comparison"), function slt, file /Volumes/Data/g/llvm/lib/Support/APInt.cpp,
line 552.

Note it's a 32-bit binary:

$ file Release+Asserts/bin/clang
Release+Asserts/bin/clang: Mach-O executable i386

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 17 20:03:31 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 17 Feb 2011 20:03:31 -0600 (CST)
Subject: [LLVMbugs] [Bug 9243] New: poor "duplicate case" diagnostic with
	enums
Message-ID: <bug-9243-206@http.llvm.org/bugs/>

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

           Summary: poor "duplicate case" diagnostic with enums
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: clattner at apple.com
                CC: llvmbugs at cs.uiuc.edu


I got this today:


CGDecl.cpp:85:8: error: duplicate case value '6'
  case Decl::Label:        // __label__ x;
       ^
CGDecl.cpp:73:8: note: previous case defined here
  case Decl::Label:
       ^

It should say "duplicate case value 'Decl::Label'"

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

From bugzilla-daemon at llvm.org  Thu Feb 17 20:27:16 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 17 Feb 2011 20:27:16 -0600 (CST)
Subject: [LLVMbugs] [Bug 9240] Sema::CheckArrayAccess assertion failure when
 building 403.gcc
In-Reply-To: <bug-9240-206@http.llvm.org/bugs/>
References: <bug-9240-206@http.llvm.org/bugs/>
Message-ID: <20110218022716.B33132A6C12E@llvm.org>

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

Ted Kremenek <kremenek at apple.com> changed:

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

--- Comment #5 from Ted Kremenek <kremenek at apple.com> 2011-02-17 20:27:16 CST ---
Fixed here: r125821

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 17 20:45:34 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 17 Feb 2011 20:45:34 -0600 (CST)
Subject: [LLVMbugs] [Bug 9188] clang trunk assert '(!Qualifier && "Can't
 have an unnamed field with a qualifier!"), function RebuildMemberExpr'
In-Reply-To: <bug-9188-206@http.llvm.org/bugs/>
References: <bug-9188-206@http.llvm.org/bugs/>
Message-ID: <20110218024534.ADF8F2A6C124@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #6 from Douglas Gregor <dgregor at apple.com> 2011-02-17 20:45:33 CST ---
Fixed in Clang r125822.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 17 21:02:27 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 17 Feb 2011 21:02:27 -0600 (CST)
Subject: [LLVMbugs] [Bug 9107] addressof(enum) assertion failure
In-Reply-To: <bug-9107-206@http.llvm.org/bugs/>
References: <bug-9107-206@http.llvm.org/bugs/>
Message-ID: <20110218030227.36C3A2A6C12E@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #2 from Douglas Gregor <dgregor at apple.com> 2011-02-17 21:02:26 CST ---
Fixed in Clang r125825.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 17 22:11:49 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 17 Feb 2011 22:11:49 -0600 (CST)
Subject: [LLVMbugs] [Bug 3429] __label__ not supported
In-Reply-To: <bug-3429-206@http.llvm.org/bugs/>
References: <bug-3429-206@http.llvm.org/bugs/>
Message-ID: <20110218041149.ABAC82A6C12E@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #20 from Chris Lattner <clattner at apple.com> 2011-02-17 22:11:48 CST ---
Clang now supports __label__ on mainline, but there is still some work to get
PR4151 to be useful.  Please file *new* bugs about __label__ details that that
you notice which are wrong, I'd like to claim that this is supported for LLVM
2.9

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 17 22:14:46 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 17 Feb 2011 22:14:46 -0600 (CST)
Subject: [LLVMbugs] [Bug 4220] Use-after-free on invalid code with label
In-Reply-To: <bug-4220-206@http.llvm.org/bugs/>
References: <bug-4220-206@http.llvm.org/bugs/>
Message-ID: <20110218041446.9A1192A6C12F@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #4 from Chris Lattner <clattner at apple.com> 2011-02-17 22:14:45 CST ---
This now valgrinds clean with the recent label rework that I landed.  It is
still (correctly) rejected with:


t2.c:1:36: error: expected '(' after 'do/while'
int a() { goto L; do { L:; } while 0; }
                                   ^

--- Comment #5 from Chris Lattner <clattner at apple.com> 2011-02-17 22:14:45 CST ---
This now valgrinds clean with the recent label rework that I landed.  It is
still (correctly) rejected with:


t2.c:1:36: error: expected '(' after 'do/while'
int a() { goto L; do { L:; } while 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  Thu Feb 17 22:14:46 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 17 Feb 2011 22:14:46 -0600 (CST)
Subject: [LLVMbugs] [Bug 4220] Use-after-free on invalid code with label
In-Reply-To: <bug-4220-206@http.llvm.org/bugs/>
References: <bug-4220-206@http.llvm.org/bugs/>
Message-ID: <20110218041446.89C4B2A6C12E@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #4 from Chris Lattner <clattner at apple.com> 2011-02-17 22:14:45 CST ---
This now valgrinds clean with the recent label rework that I landed.  It is
still (correctly) rejected with:


t2.c:1:36: error: expected '(' after 'do/while'
int a() { goto L; do { L:; } while 0; }
                                   ^

--- Comment #5 from Chris Lattner <clattner at apple.com> 2011-02-17 22:14:45 CST ---
This now valgrinds clean with the recent label rework that I landed.  It is
still (correctly) rejected with:


t2.c:1:36: error: expected '(' after 'do/while'
int a() { goto L; do { L:; } while 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  Thu Feb 17 22:16:21 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 17 Feb 2011 22:16:21 -0600 (CST)
Subject: [LLVMbugs] [Bug 6313] sema bug handling
 __sync_val_compare_and_swap/__sync_lock_test_and_set
In-Reply-To: <bug-6313-206@http.llvm.org/bugs/>
References: <bug-6313-206@http.llvm.org/bugs/>
Message-ID: <20110218041621.AE6292A6C12D@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #1 from Chris Lattner <clattner at apple.com> 2011-02-17 22:16:21 CST ---
This got fixed some time back.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 17 22:44:21 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 17 Feb 2011 22:44:21 -0600 (CST)
Subject: [LLVMbugs] [Bug 4151] [Linux kernel] "__label__" support
In-Reply-To: <bug-4151-206@http.llvm.org/bugs/>
References: <bug-4151-206@http.llvm.org/bugs/>
Message-ID: <20110218044421.4F3B22A6C124@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #9 from Chris Lattner <clattner at apple.com> 2011-02-17 22:44:20 CST ---
As of r125829, clang now implements __label__ and the optimizer does a good job
of preserving these sorts of labels.  For example, we now compile:


#define _THIS_IP_  ({ __label__ __here; __here: (unsigned long)&&__here; })

void foo() {
  printf("%p\n", _THIS_IP_);
  printf("%p\n", _THIS_IP_);
  printf("%p\n", _THIS_IP_);
}

into:

$ clang t.c -S -o - -mkernel -O3 -fomit-frame-pointer
...
_foo:                                   ## @foo
## BB#0:                                ## %entry
    pushq    %rax
Ltmp0:                                  ## Block address taken
## BB#1:                                ## %__here
    leaq    L_.str(%rip), %rdi
    leaq    Ltmp0(%rip), %rsi
    xorb    %al, %al
    callq    _printf
Ltmp1:                                  ## Block address taken
## BB#2:                                ## %__here1
    leaq    L_.str(%rip), %rdi
    leaq    Ltmp1(%rip), %rsi
    xorb    %al, %al
    callq    _printf
Ltmp2:                                  ## Block address taken
## BB#3:                                ## %__here3
    leaq    L_.str(%rip), %rdi
    leaq    Ltmp2(%rip), %rsi
    xorb    %al, %al
    callq    _printf
    popq    %rax
    ret


which seems reasonable.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 18 01:35:50 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 18 Feb 2011 01:35:50 -0600 (CST)
Subject: [LLVMbugs] [Bug 9244] New: Sparc LowerVAARG introduces i64 load
 that Legalizer can't handle
Message-ID: <bug-9244-206@http.llvm.org/bugs/>

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

           Summary: Sparc LowerVAARG introduces i64 load that Legalizer
                    can't handle
           Product: libraries
           Version: 2.8
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: Sparc
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: andrew-llvm at gizmolabs.org
                CC: llvmbugs at cs.uiuc.edu


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

Given the following C code (which produces the attached .bc file):

#include <stdarg.h>
// This function from:
//
http://en.wikipedia.org/w/index.php?title=Variadic_function&oldid=414416601#Variadic_functions_in_C.2C_Objective-C.2C_C.2B.2B.2C_and_D
double average(int count, ...)
{
    va_list ap;
    double tot = 0;
    va_start(ap, count);
    tot = va_arg(ap, double);
    va_end(ap);
    return tot;
}

Compiled with this command line on LLVM2.8 on Snow Leopard (Mac OS X 10.6):

clang -O0 -emit-llvm -c -o simple.bc simple.c -ccc-host-triple sparc

And then converted to sparc assembly with this command line:

llc -march=sparc simple.bc -o=simple.sparc

I get this assertion failure:



Assertion failed: ((isTypeLegal(Node->getOperand(i).getValueType()) ||
Node->getOperand(i).getOpcode() == ISD::TargetConstant) && "Unexpected illegal
type!"), function LegalizeOp, file LegalizeDAG.cpp, line 832.
0  llc               0x0000000100980937 PrintStackTrace(void*) + 38
1  llc               0x0000000100980ef2 SignalHandler(int) + 254
2  libSystem.B.dylib 0x00007fff8580767a _sigtramp + 26
3  llc               0x00000001004bcc9b llvm::SmallPtrSet<llvm::SDNode const*,
128u>::~SmallPtrSet() + 21
4  llc               0x000000010002f1b5 abort + 22
5  llc               0x000000010002f242
__gnu_cxx::new_allocator<llvm::sys::Path>::new_allocator() + 0
6  llc               0x0000000100410001 (anonymous
namespace)::SelectionDAGLegalize::LegalizeOp(llvm::SDValue) + 1049
7  llc               0x00000001004109bd (anonymous
namespace)::SelectionDAGLegalize::LegalizeOp(llvm::SDValue) + 3541
8  llc               0x0000000100411383 (anonymous
namespace)::SelectionDAGLegalize::LegalizeOp(llvm::SDValue) + 6043
9  llc               0x0000000100422822 (anonymous
namespace)::SelectionDAGLegalize::LegalizeDAG() + 192
10 llc               0x0000000100422967
llvm::SelectionDAG::Legalize(llvm::CodeGenOpt::Level) + 71
11 llc               0x0000000100507b31
llvm::SelectionDAGISel::CodeGenAndEmitDAG() + 2187
12 llc               0x00000001005097ac
llvm::SelectionDAGISel::SelectBasicBlock(llvm::ilist_iterator<llvm::Instruction
const>, llvm::ilist_iterator<llvm::Instruction const>, bool&) + 230
13 llc               0x0000000100509e5e
llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) + 1712
14 llc               0x000000010050a2be
llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) + 746
15 llc               0x00000001005faa83
llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 85
16 llc               0x00000001008c4b50
llvm::FPPassManager::runOnFunction(llvm::Function&) + 350
17 llc               0x00000001008c4d23
llvm::FPPassManager::runOnModule(llvm::Module&) + 81
18 llc               0x00000001008c4820
llvm::MPPassManager::runOnModule(llvm::Module&) + 384
19 llc               0x00000001008c5fd1
llvm::PassManagerImpl::run(llvm::Module&) + 111
20 llc               0x00000001008c6033 llvm::PassManager::run(llvm::Module&) +
33
21 llc               0x00000001000306b3 main + 2205
22 llc               0x000000010002f7fc start + 52
Stack dump:
0.    Program arguments: llc -march=sparc simple.bc -o=simple.sparc 
1.    Running pass 'Function Pass Manager' on module 'simple.bc'.
2.    Running pass 'SPARC DAG->DAG Pattern Instruction Selection' on function
'@average'


One issue is that LowerVAARG() in SparcISelLowering.cpp introduces an i64 load
if the type is an f64:

static SDValue LowerVAARG(SDValue Op, SelectionDAG &DAG) {
// snip

  // Otherwise, load it as i64, then do a bitconvert.
  SDValue V = DAG.getLoad(MVT::i64, dl, InChain, VAList, NULL, 0,
                          false, false, 0);

This seems to be where the illegal load comes from.

I'm too much an LLVM newbie to know how the legalizer is supposed to handle
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 Feb 18 02:39:53 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 18 Feb 2011 02:39:53 -0600 (CST)
Subject: [LLVMbugs] [Bug 9245] New: error in backend: expected assembly-time
 absolute expression
Message-ID: <bug-9245-206@http.llvm.org/bugs/>

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

           Summary: error in backend: expected assembly-time absolute
                    expression
           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


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

The linux kernel (2.6.38-rc5) doesn't build because of a problem in llvm-mc and
the BUG() macro which is used throughout.

Please see the C testcase attached. It triggers easily:

$ clang y.c -c -o y.o
fatal error: error in backend: expected assembly-time absolute expression

while having clang emit a .s file and then using GAS to assemble it works fine.
However:

  $ clang y.c -S -o y.s
  $ llvm-mc -assemble y.s -filetype=obj
  LLVM ERROR: expected assembly-time absolute expression

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 18 10:52:04 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 18 Feb 2011 10:52:04 -0600 (CST)
Subject: [LLVMbugs] [Bug 9246] New: LLVM fails to merge blocks with calls
 that only differ in attributes.
Message-ID: <bug-9246-206@http.llvm.org/bugs/>

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

           Summary: LLVM fails to merge blocks with calls that only differ
                    in attributes.
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Scalar Optimizations
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: benny.kra at gmail.com
                CC: llvmbugs at cs.uiuc.edu


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

For the attached test case clang -O3 generates

===
define i8* @foo(i8* %x, i8* %y) nounwind ssp {
entry:
  %0 = tail call i64 @llvm.objectsize.i64(i8* %x, i1 false)
  %cmp = icmp eq i64 %0, -1
  br i1 %cmp, label %cond.false, label %cond.true

cond.true:                                        ; preds = %entry
  %call = tail call i8* @__memcpy_chk(i8* %x, i8* %y, i64 42, i64 %0)
  br label %cond.end

cond.false:                                       ; preds = %entry
  %call.i = tail call i8* @__memcpy_chk(i8* %x, i8* %y, i64 42, i64 %0)
nounwind
  br label %cond.end

cond.end:                                         ; preds = %cond.false,
%cond.true
  %cond = phi i8* [ %call, %cond.true ], [ %call.i, %cond.false ]
  ret i8* %cond
}

declare i64 @llvm.objectsize.i64(i8*, i1) nounwind readnone

declare i8* @__memcpy_chk(i8*, i8*, i64, i64) nounwind
===

cond.true and cond.false should be merged, eliminating the icmp+branch.

This happens because darwin10's headers expand memcpy into a normal
__memcpy_chk call and a call to an inlined function. At this point neither
__memcpy_chk have a nounwind attribute. When the inliner inlines the function
it detects that it was "nounwind" and applies the attribute to the inlined
call.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 18 11:26:45 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 18 Feb 2011 11:26:45 -0600 (CST)
Subject: [LLVMbugs] [Bug 8404] ICE in ScheduleDAG.cpp:460: "Wrong
	topological sorting"
In-Reply-To: <bug-8404-206@http.llvm.org/bugs/>
References: <bug-8404-206@http.llvm.org/bugs/>
Message-ID: <20110218172645.32E342A6C124@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #3 from Chris Lattner <clattner at apple.com> 2011-02-18 11:26:44 CST ---
Until we get a testcase, there isn't much we can do.  We are generally trying
to move off MVT::Glue, so the best answer may be a different design for
whatever your port is doing.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 18 14:00:14 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 18 Feb 2011 14:00:14 -0600 (CST)
Subject: [LLVMbugs] [Bug 9247] New: Crash on invalid in
 clang::Sema::ActOnFinishCXXMemberSpecification
Message-ID: <bug-9247-206@http.llvm.org/bugs/>

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

           Summary: Crash on invalid in
                    clang::Sema::ActOnFinishCXXMemberSpecification
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: matthewbg at google.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


struct A {
  virtual void g(const A& input) = 0;
  struct B {
    C* f(int foo);
  };
};

$ clang -fsyntax-only /tmp/3466630.ii
/tmp/3466630.ii:4:5: error: unknown type name 'C'
    C* f(int foo);
    ^
0  clang           0x000000000215f340
1  clang           0x000000000215f13c
2  libpthread.so.0 0x00007fa19e7789f0
3  clang           0x00000000011fd5fa llvm::PointerIntPair<void*, 1u, bool,
llvm::PointerUnionUIntTraits<clang::TypeSourceInfo*,
clang::DeclaratorDecl::ExtInfo*> >::getInt() const + 16
4  clang           0x00000000011fc25e int
llvm::PointerUnion<clang::TypeSourceInfo*,
clang::DeclaratorDecl::ExtInfo*>::is<clang::DeclaratorDecl::ExtInfo*>() const +
74
5  clang           0x00000000011f84e0 clang::DeclaratorDecl::hasExtInfo() const
+ 28
6  clang           0x00000000011f851e
clang::DeclaratorDecl::getTypeSourceInfo() const + 24
7  clang           0x000000000154ca72
8  clang           0x000000000154c3dc
9  clang           0x000000000154d0a5
10 clang           0x000000000154d126
11 clang           0x000000000154d1bd
12 clang           0x000000000154d368
13 clang           0x000000000154d470
clang::Sema::CheckCompletedCXXClass(clang::CXXRecordDecl*) + 158
14 clang           0x000000000154e1af
clang::Sema::ActOnFinishCXXMemberSpecification(clang::Scope*,
clang::SourceLocation, clang::Decl*, clang::SourceLocation,
clang::SourceLocation, clang::AttributeList*) + 199
15 clang           0x0000000001399f33
clang::Parser::ParseCXXMemberSpecification(clang::SourceLocation, unsigned int,
clang::Decl*) + 1703
16 clang           0x00000000013978a0
clang::Parser::ParseClassSpecifier(clang::tok::TokenKind,
clang::SourceLocation, clang::DeclSpec&, clang::Parser::ParsedTemplateInfo
const&, clang::AccessSpecifier, bool) + 5760
17 clang           0x000000000137e100
clang::Parser::ParseDeclarationSpecifiers(clang::DeclSpec&,
clang::Parser::ParsedTemplateInfo const&, clang::AccessSpecifier,
clang::Parser::DeclSpecContext) + 6450
18 clang           0x0000000001359a20
clang::Parser::ParseDeclarationOrFunctionDefinition(clang::Parser::ParsingDeclSpec&,
clang::AccessSpecifier) + 88
19 clang           0x0000000001359e45
clang::Parser::ParseDeclarationOrFunctionDefinition(clang::ParsedAttributes&,
clang::AccessSpecifier) + 113
20 clang           0x00000000013597c3
clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&,
clang::Parser::ParsingDeclSpec*) + 2199
21 clang           0x0000000001358e9c
clang::Parser::ParseTopLevelDecl(clang::OpaquePtr<clang::DeclGroupRef>&) + 210
22 clang           0x00000000013561c1 clang::ParseAST(clang::Sema&, bool) + 328
23 clang           0x000000000129036d clang::ASTFrontendAction::ExecuteAction()
+ 263
24 clang           0x000000000128ffc5 clang::FrontendAction::Execute() + 319
25 clang           0x000000000120915f
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 747
26 clang           0x0000000000e98f25
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 879
27 clang           0x0000000000e8ad07 cc1_main(char const**, char const**, char
const*, void*) + 951
28 clang           0x0000000000e94448 main + 481
29 libc.so.6       0x00007fa19dedfd5d __libc_start_main + 253
30 clang           0x0000000000e8a36e
Stack dump:
0.    Program arguments: clang -cc1 -triple x86_64-unknown-linux-gnu
-fsyntax-only -disable-free -main-file-name 3466630.ii -mrelocation-model
static -mdisable-fp-elim -masm-verbose -mconstructor-aliases -munwind-tables
-target-cpu x86-64 -momit-leaf-frame-pointer -resource-dir ../lib/clang/2.0
-ferror-limit 19 -fmessage-length 80 -fexceptions -fgnu-runtime
-fdiagnostics-show-option -fcolor-diagnostics -x c++-cpp-output /tmp/3466630.ii 
1.    /tmp/3466630.ii:6:2: current parser token ';'
2.    /tmp/3466630.ii:1:1: parsing struct/union/class body 'A'
clang: error: unable to execute command: Segmentation fault
clang: error: clang frontend command failed due to signal 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  Fri Feb 18 18:01:07 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 18 Feb 2011 18:01:07 -0600 (CST)
Subject: [LLVMbugs] [Bug 8767] show unimplemented methods in "abstract type"
	error
In-Reply-To: <bug-8767-206@http.llvm.org/bugs/>
References: <bug-8767-206@http.llvm.org/bugs/>
Message-ID: <20110219000107.69C022A6C12E@llvm.org>

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

Chandler Carruth <chandlerc at gmail.com> changed:

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

--- Comment #1 from Chandler Carruth <chandlerc at gmail.com> 2011-02-18 18:01:06 CST ---
Fixed in r125996.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 18 18:21:33 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 18 Feb 2011 18:21:33 -0600 (CST)
Subject: [LLVMbugs] [Bug 9227] clang emits bool template type values as '0'
 and '1', not 'false' and 'true'
In-Reply-To: <bug-9227-206@http.llvm.org/bugs/>
References: <bug-9227-206@http.llvm.org/bugs/>
Message-ID: <20110219002133.B34242A6C12E@llvm.org>

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

Chandler Carruth <chandlerc at gmail.com> changed:

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

--- Comment #1 from Chandler Carruth <chandlerc at gmail.com> 2011-02-18 18:21:33 CST ---
Fixed in r125999.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 18 21:14:34 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 18 Feb 2011 21:14:34 -0600 (CST)
Subject: [LLVMbugs] [Bug 9244] Sparc LowerVAARG introduces i64 load that
 Legalizer can't handle
In-Reply-To: <bug-9244-206@http.llvm.org/bugs/>
References: <bug-9244-206@http.llvm.org/bugs/>
Message-ID: <20110219031434.840B52A6C12E@llvm.org>

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

Andrew de los Reyes <andrew-llvm at gizmolabs.org> changed:

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

--- Comment #6 from Andrew de los Reyes <andrew-llvm at gizmolabs.org> 2011-02-18 21:14:34 CST ---


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

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 18 23:19:00 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 18 Feb 2011 23:19:00 -0600 (CST)
Subject: [LLVMbugs] [Bug 9248] New: [mc] no support for .macro with arguments
Message-ID: <bug-9248-206@http.llvm.org/bugs/>

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

           Summary: [mc] no support for .macro with arguments
           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: nicholas at mxc.ca
                CC: llvmbugs at cs.uiuc.edu


llvm-mc rejects this file:

 .macro macroname argone argtwo 
 .endm

with:

  $ llvm-mc -assemble -filetype=obj y.s
  y.s:1:19: error: unexpected token in '.macro' directive
   .macro macroname argone argtwo
                    ^
  y.s:2:7: error: unexpected '.endm' in file, no current macro definition
   .endm
        ^

while as is fine with it. The unknown tokens are arguments to the macro,
documented in GAS here: http://sourceware.org/binutils/docs-2.21/as/Macro.html

This is blocking arch/x86/include/asm/inst.h in the linux kernel.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 19 03:33:09 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 19 Feb 2011 03:33:09 -0600 (CST)
Subject: [LLVMbugs] [Bug 9249] New: clang --help doesn't list useful options
Message-ID: <bug-9249-206@http.llvm.org/bugs/>

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

           Summary: clang --help doesn't list useful options
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Driver
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: edwintorok at gmail.com
                CC: llvmbugs at cs.uiuc.edu


All that clang --help lists are the ones below.
It doesn't list -no-integrated-as, -mllvm, -fexceptions, or any of the other
useful command-line flags.

 -###                    Print the commands to run for this compilation
  --analyze               Run the static analyzer
  --help                  Display available options
  --relocatable-pch       Build a relocatable precompiled header
  -E                      Only run the preprocessor
  -ObjC++                 Treat source input files as Objective-C++ inputs
  -ObjC                   Treat source input files as Objective-C inputs
  -Qunused-arguments      Don't emit warning for unused driver arguments
  -S                      Only run preprocess and compilation steps
  -Wa,<arg>               Pass the comma separated arguments in <arg> to the
assembler
  -Wl,<arg>               Pass the comma separated arguments in <arg> to the
linker
  -Wp,<arg>               Pass the comma separated arguments in <arg> to the
preprocessor
  -Xanalyzer <arg>        Pass <arg> to the static analyzer
  -Xassembler <arg>       Pass <arg> to the assembler
  -Xclang <arg>           Pass <arg> to the clang compiler
  -Xlinker <arg>          Pass <arg> to the linker
  -Xpreprocessor <arg>    Pass <arg> to the preprocessor
  -c                      Only run preprocess, compile, and assemble steps
  -emit-ast               Emit Clang AST files for source inputs
  -emit-llvm              Use the LLVM representation for assembler and object
files
  -fcatch-undefined-behavior
                          Generate runtime checks for undefined behavior.
  -flimit-debug-info      Limit debug information produced to reduce size of
debug binary
  -o <file>               Write output to <file>
  -pipe                   Use pipes between commands, when possible
  -print-file-name=<file> Print the full library path of <file>
  -print-libgcc-file-name Print the library path for "libgcc.a"
  -print-prog-name=<name> Print the full program path of <name>
  -print-search-dirs      Print the paths used for finding libraries and
programs
  -rewrite-objc           Rewrite Objective-C source to C++
  -save-temps             Save intermediate compilation results
  -time                   Time individual commands
  -v                      Show commands to run and use verbose output
  -working-directory <value>
                          Resolve file paths relative to the specified
directory
  -x <language>           Treat subsequent input files as having type
<language>

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 19 03:45:25 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 19 Feb 2011 03:45:25 -0600 (CST)
Subject: [LLVMbugs] [Bug 9250] New: -Warray-bounds too noisy on dead code
Message-ID: <bug-9250-206@http.llvm.org/bugs/>

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

           Summary: -Warray-bounds too noisy on dead code
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: edwintorok at gmail.com
                CC: llvmbugs at cs.uiuc.edu


When compiling the kernel you get these errors over and over:
include/linux/signal.h:204:10: warning: array index of '1' indexes past the end
of an array (that contains 1 elements) [-Warray-bounds]
        case 2: set->sig[1] = 0;
                ^        ~
In file included from init/main.c:16:                                           
In file included from include/linux/syscalls.h:72:
/home/edwin/builds/linux-2.6/arch/x86/include/asm/signal.h:31:16: note: array
'sig' declared here
        unsigned long sig[_NSIG_WORDS];
                      ^


Testcase:
#include <string.h>
#define __BITS_PER_LONG 64
#define _NSIG           64
#define _NSIG_BPW       __BITS_PER_LONG
#define _NSIG_WORDS _NSIG /_NSIG_BPW

unsigned long sig[_NSIG_WORDS];

void foo()
{
    switch (_NSIG_WORDS) {
        default:
                memset(&sig[1], -1, sizeof(long)*(_NSIG_WORDS-1));
                break;
        case 2: sig[1] = -1;
        case 1: ;
    }
}


There is no out-of-bounds access, because the switch is on a constant,
evaluatable at compile time, and the other cases of the switch are dead code,
and are removed at compile time.

clang should not warn in this case, because the warning is useless.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 19 03:50:16 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 19 Feb 2011 03:50:16 -0600 (CST)
Subject: [LLVMbugs] [Bug 9251] New: Support -fno-delete-null-pointer-checks
Message-ID: <bug-9251-206@http.llvm.org/bugs/>

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

           Summary: Support -fno-delete-null-pointer-checks
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: edwintorok at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Linux kernel uses it, because it want gcc to play smart and delete NULL pointer
checks and introduce security bugs that way (NULL pointer deref doesn't always
crash kernel, especially if someone managed to map page 0).

clang should probably support it 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  Sat Feb 19 03:59:58 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 19 Feb 2011 03:59:58 -0600 (CST)
Subject: [LLVMbugs] [Bug 9252] New:
 lib/CodeGen/TwoAddressInstructionPass.cpp:1138: virtual
 bool<unnamed>::TwoAddressInstructionPass::runOnMachineFunction(llvm::MachineFunction&):
 Assertion `i == DstIdx || !mi->getOperand(i).isReg() ||
 mi->getOperand(i).getReg() != regA' failed
Message-ID: <bug-9252-206@http.llvm.org/bugs/>

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

           Summary: lib/CodeGen/TwoAddressInstructionPass.cpp:1138:
                    virtual
                    bool<unnamed>::TwoAddressInstructionPass::runOnMachine
                    Function(llvm::MachineFunction&): Assertion `i ==
                    DstIdx || !mi->getOperand(i).isReg() ||
                    mi->getOperand(i).getReg() != regA' failed
           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: edwintorok at gmail.com
                CC: llvmbugs at cs.uiuc.edu
            Blocks: 4068


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

When compiling emulate.c from the Linux kernel:

llc:
/home/edwin/HDD/edwin/llvm-git/offi/llvm/lib/CodeGen/TwoAddressInstructionPass.cpp:1138:
virtual
bool<unnamed>::TwoAddressInstructionPass::runOnMacnction(llvm::MachineFunction&):
Assertion `i == DstIdx || !mi->getOperand(i).isReg() ||
mi->getOperand(i).getReg() != regA' failed.
0  llc             0x0000000000b9a4cf
1  llc             0x0000000000b9c732
2  libpthread.so.0 0x0000003f36a0ef60
3  libc.so.6       0x0000003f35e32165 gsignal + 53
4  libc.so.6       0x0000003f35e34f70 abort + 384
5  libc.so.6       0x0000003f35e2b2b1 __assert_fail + 241
6  llc             0x00000000008ca1c3
7  llc             0x0000000000ae9d0d
llvm::FPPassManager::runOnFunction(llvm::Function&) + 557
8  llc             0x0000000000ae9e0b
llvm::FPPassManager::runOnModule(llvm::Module&) + 75
9  llc             0x0000000000ae9897
llvm::MPPassManager::runOnModule(llvm::Module&) + 503
10 llc             0x0000000000ae9a17 llvm::PassManagerImpl::run(llvm::Module&)
+ 167
11 llc             0x000000000050523d main + 3885
12 libc.so.6       0x0000003f35e1ec4d __libc_start_main + 253
13 llc             0x00000000005031c9
Stack dump:
0.      Program arguments: llc x.ll 
1.      Running pass 'Function Pass Manager' on module 'x.ll'.
2.      Running pass 'Two-Address instruction pass' on function
'@x86_emulate_insn'
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  Sat Feb 19 04:15:23 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 19 Feb 2011 04:15:23 -0600 (CST)
Subject: [LLVMbugs] [Bug 9253] New: clang: wrong alignment for fields /
 wrong total struct size
Message-ID: <bug-9253-206@http.llvm.org/bugs/>

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

           Summary: clang: wrong alignment for fields / wrong total struct
                    size
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: edwintorok at gmail.com
                CC: llvmbugs at cs.uiuc.edu
        Depends on: 4068


clang gives this error during kernel compile:
kernel/trace/blktrace.c:649:7: error: duplicate case value '3225948787'
        case BLKTRACESETUP32:
             ^
kernel/trace/blktrace.c:644:7: note: previous case defined here                 
        case BLKTRACESETUP:
             ^

However this is a clang bug, because the 2 sizes of the two structs used in
calculating those constants are equal in clang, while they are different in
gcc. This is an ABI issue.

Testcase:
#include <stdio.h>

typedef unsigned short u16;
typedef unsigned short __u16;
typedef unsigned int __u32;
typedef unsigned int u32;
typedef unsigned long long u64;
__extension__ typedef unsigned long long __u64;
typedef u64 __attribute__((aligned(4))) compat_u64;
struct compat_blk_user_trace_setup {
 char name[32];
 u16 act_mask;
 u32 buf_size;
 u32 buf_nr;
 compat_u64 start_lba;
 compat_u64 end_lba;
 u32 pid;
};

struct blk_user_trace_setup {
 char name[32];
 __u16 act_mask;
 __u32 buf_size;
 __u32 buf_nr;
 __u64 start_lba;
 __u64 end_lba;
 __u32 pid;
};

int main()
{
    struct compat_blk_user_trace_setup b1;
    struct blk_user_trace_setup b2;
    printf("compat_blk_user_trace_setup = %d, blk_user_trace_setup = %d\n",
           sizeof(struct compat_blk_user_trace_setup),
           sizeof(struct blk_user_trace_setup));
}

Prints:
$ gcc -m64 x.c && ./a.out
compat_blk_user_trace_setup = 64, blk_user_trace_setup = 72
$ clang -m64 x.c && ./a.out
compat_blk_user_trace_setup = 72, blk_user_trace_setup = 72

Looks like clang doesn't honour the aligned(4) attribute, and tries to use an
8-byte alignment for compat_u64, when it should use just a 4-byte alignment.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 19 04:31:40 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 19 Feb 2011 04:31:40 -0600 (CST)
Subject: [LLVMbugs] [Bug 9254] New: clang can't build iptables in Linux
 kernel: error: fields must have a constant size: 'variable length array in
 structure' extension will never be supported
Message-ID: <bug-9254-206@http.llvm.org/bugs/>

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

           Summary: clang can't build iptables in Linux kernel: error:
                    fields must have a constant size: 'variable length
                    array in structure' extension will never be supported
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: edwintorok at gmail.com
                CC: llvmbugs at cs.uiuc.edu
        Depends on: 4068


clang doesn't support this, and says it won't:
crypto/hmac.c:57:8: error: fields must have a constant size: 'variable length
array in structure' extension will never be supported
                char ctx[crypto_shash_descsize(hash)];


That part of kernel code should probably be rewritten to not use this, but more
and more kernel code seems to turn up that uses this feature of gcc.
It used to be only the crypto API, now it is iptables too.

Meanwhile I opened this bug to document how to turn off the problematic parts
of the kernel, and its dependencies.
You need to turn off these:
CONFIG_INET_AH
CONFIG_INET_ESP
CONFIG_INET6_AH
CONFIG_INET6_ESP
CONFIG_NETFILTER
CONFIG_LIBCRC32C

The iptables is a problem though, without it we can't really say that "clang
builds a Linux kernel".
How hard would it be to implement this specific case in clang?
And how hard would it be to patch the kernel to not use this feature?

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 19 04:48:14 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 19 Feb 2011 04:48:14 -0600 (CST)
Subject: [LLVMbugs] [Bug 9255] New: clang: can't compile arch/x86/boot in
 kernel (.code16gcc)
Message-ID: <bug-9255-206@http.llvm.org/bugs/>

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

           Summary: clang: can't compile arch/x86/boot in kernel
                    (.code16gcc)
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: edwintorok at gmail.com
                CC: llvmbugs at cs.uiuc.edu
        Depends on: 4068


This bug is here as a reminder that arch/x86/boot needs to be compiled with
gcc,
otherwise kernel won't boot at all (no messages shown during boot, just hangs).

Probably due to .code16gcc, which is not supported by 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  Sat Feb 19 04:50:11 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 19 Feb 2011 04:50:11 -0600 (CST)
Subject: [LLVMbugs] [Bug 9256] New: clang: support for kernel code model:
 pointer arithmetic that overflows is not impossible!
Message-ID: <bug-9256-206@http.llvm.org/bugs/>

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

           Summary: clang: support for kernel code model: pointer
                    arithmetic that overflows is not impossible!
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: edwintorok at gmail.com
                CC: llvmbugs at cs.uiuc.edu
        Depends on: 4068


Just a reminder that kernel/s lib/vsprintf.c still needs this patch, because
pointer arithmetic overflows, and clang's optimizer assume pointer arithmetic
never overflows.
In the kernel it is very much possible to overflow, and we must calculate the
correct value, because it is then used in an 'if' for bounds checking.

diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index c150d3d..8791762 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -1294,7 +1294,10 @@ int vsnprintf(char *buf, size_t size, const char *fmt,
va_list args)
                return 0;

        str = buf;
-       end = buf + size;
+       /* LLVM local */
+        end = RELOC_HIDE(buf, size);
+        /* LLVM local end */
+

        /* Make sure end is always >= buf */
        if (end < buf) {

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 19 04:59:16 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 19 Feb 2011 04:59:16 -0600 (CST)
Subject: [LLVMbugs] [Bug 9257] New: clang: error: cannot compile this GNU
 array range designator extension yet
Message-ID: <bug-9257-206@http.llvm.org/bugs/>

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

           Summary: clang:  error: cannot compile this GNU array range
                    designator extension yet
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: edwintorok at gmail.com
                CC: llvmbugs at cs.uiuc.edu
        Depends on: 4068


When compiling linux kernel with ARCH=um (usermode):
arch/um/kernel/process.c:191:37: error: cannot compile this GNU array range
designator extension yet
        p->thread = (struct thread_struct) INIT_THREAD;

Testcase:

struct faultinfo {
        int error_code;
        unsigned long cr2;
        int trap_no;
};
struct arch_thread {
        unsigned long debugregs[8];
        int debugregs_seq;
        unsigned long fs;
        struct faultinfo faultinfo;
};
struct __jmp_buf {
 unsigned long __rbx;
 unsigned long __rsp;
 unsigned long __rbp;
 unsigned long __r12;
 unsigned long __r13;
 unsigned long __r14;
 unsigned long __r15;
 unsigned long __rip;
};

typedef struct __jmp_buf jmp_buf[1];
struct uml_pt_regs {
 unsigned long gp[(((216)) / sizeof(unsigned long))];
 struct faultinfo faultinfo;
 long syscall;
 int is_user;
};
struct pt_regs {
 struct uml_pt_regs regs;
};
struct thread_struct {
 struct task_struct *saved_task;







 int forking;
 struct pt_regs regs;
 int singlestep_syscall;
 void *fault_addr;
 jmp_buf *fault_catcher;
 struct task_struct *prev_sched;
 unsigned long temp_stack;
 jmp_buf *exec_buf;
 struct arch_thread arch;
 jmp_buf switch_buf;
 int mm_count;
 struct {
  int op;
  union {
   struct {
    int pid;
   } fork, exec;
   struct {
    int (*proc)(void *);
    void *arg;
   } thread;
   struct {
    void (*proc)(void *);
    void *arg;
   } cb;
  } u;
 } request;
};

void foo(struct thread_struct *p)
{
    *p =
        (struct thread_struct) { .forking = 0, .regs = { .regs = { } },
.fault_addr = ((void *)0), .prev_sched = ((void *)0), .temp_stack = 0,
.exec_buf = ((void *)0), .arch = { .debugregs = { [ 0 ... 7 ] = 0 },
.debugregs_seq = 0, .fs = 0, .faultinfo = { 0, 0, 0 } }, .request = { 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 Feb 19 05:23:42 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 19 Feb 2011 05:23:42 -0600 (CST)
Subject: [LLVMbugs] [Bug 9258] New: clang: unsupported inline asm: input
 with type 'int' matching output with type 'u8' (aka 'unsigned char')
Message-ID: <bug-9258-206@http.llvm.org/bugs/>

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

           Summary: clang: unsupported inline asm: input with type 'int'
                    matching output with type 'u8' (aka 'unsigned char')
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: edwintorok at gmail.com
                CC: llvmbugs at cs.uiuc.edu
            Blocks: 4068


Can't compile Xen:

arch/x86/xen/spinlock.c:284:14: error: unsupported inline asm: input with type
'int' matching output with type 'u8' (aka 'unsigned char')
                    : "1" (1)
                           ^
Testcase:
typedef unsigned char u8;
struct arch_spinlock;
struct xen_spinlock {
 unsigned char lock;
 unsigned short spinners;
};
void foo(struct arch_spinlock *lock)
{
 u8 oldval;
 unsigned timeout;
 struct xen_spinlock *xl = (struct xen_spinlock *)lock;
  asm("1: xchgb %1,%0\n"
      "   testb %1,%1\n"
      "   jz 3f\n"
      "2: rep;nop\n"
      "   cmpb $0,%0\n"
      "   je 1b\n"
      "   dec %2\n"
      "   jnz 2b\n"
      "3:\n"
      : "+m" (xl->lock), "=q" (oldval), "+r" (timeout)
      : "1" (1)
      : "memory");

}

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

From bugzilla-daemon at llvm.org  Sat Feb 19 05:29:29 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 19 Feb 2011 05:29:29 -0600 (CST)
Subject: [LLVMbugs] [Bug 9259] New: llc -O1: Broken module found,
	compilation aborted!
Message-ID: <bug-9259-206@http.llvm.org/bugs/>

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

           Summary: llc -O1: Broken module found, compilation aborted!
           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: edwintorok at gmail.com
                CC: llvmbugs at cs.uiuc.edu


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

While compiling dw2102.c from the Linux kernel:

opt -verify says the bitcode is good, and llc -O0 works too:
$ opt -verify bugpoint-reduced-simplified.bc
$ llc -O0 bugpoint-reduced-simplified.bc

llc -O1 breaks the bitcode though:
$ llc -O1 bugpoint-reduced-simplified.bc

Instruction does not dominate all uses!
  %tmp3 = add i64 %indvar, %tmp2
  %tmp4 = trunc i64 %tmp3 to i32
Instruction does not dominate all uses!
  %tmp4 = trunc i64 %tmp3 to i32
  %conv29 = trunc i32 %tmp4 to i16, !dbg !7709
Instruction does not dominate all uses!
  %conv29 = trunc i32 %tmp4 to i16, !dbg !7709
  %call34 = call fastcc i32 @dw210x_op_rw(%struct.usb_device* undef, i8 zeroext
-75, i16 zeroext %conv29, i16 zeroext 0, i8* undef, i16 zeroext 2, i32 0)
optsize noredzone, !dbg !7712
Broken module found, compilation aborted!
0  llc             0x0000000000b9a4cf
1  llc             0x0000000000b9c732
2  libpthread.so.0 0x0000003f36a0ef60
3  libc.so.6       0x0000003f35e32165 gsignal + 53
4  libc.so.6       0x0000003f35e34f70 abort + 384
5  llc             0x0000000000b101eb
6  llc             0x0000000000ae9d0d
llvm::FPPassManager::runOnFunction(llvm::Function&) + 557
7  llc             0x0000000000ae9e0b
llvm::FPPassManager::runOnModule(llvm::Module&) + 75
8  llc             0x0000000000ae9897
llvm::MPPassManager::runOnModule(llvm::Module&) + 503
9  llc             0x0000000000ae9a17 llvm::PassManagerImpl::run(llvm::Module&)
+ 167
10 llc             0x000000000050523d main + 3885
11 libc.so.6       0x0000003f35e1ec4d __libc_start_main + 253
12 llc             0x00000000005031c9
Stack dump:
0.      Program arguments: llc bugpoint-reduced-simplified.bc -O1 
1.      Running pass 'Function Pass Manager' on module
'bugpoint-reduced-simplified.bc'.
2.      Running pass 'Module Verifier' on function '@dw2102_i2c_transfer'
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  Sat Feb 19 05:34:08 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 19 Feb 2011 05:34:08 -0600 (CST)
Subject: [LLVMbugs] [Bug 9260] New: clang: nested functions not supported?
Message-ID: <bug-9260-206@http.llvm.org/bugs/>

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

           Summary: clang: nested functions not supported?
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: edwintorok at gmail.com
                CC: llvmbugs at cs.uiuc.edu
            Blocks: 4068


Testcase:
void foo()
{
    void bar() {
    }
}

Results in:
p2.c:3:15: error: expected ';' at end of declaration
    void bar() {
              ^
              ;                                                                 
1 error generated. 

This blocks compilation of thinkpad_acpi.c from the Linux kernel:
drivers/platform/x86/thinkpad_acpi.c:2369:35: error: expected ';' at end of
declaration                                                            
                             const unsigned int newvol)
                                                       ^
                                                       ;                        
drivers/platform/x86/thinkpad_acpi.c:2453:3: error: implicit declaration of
function 'issue_brightnesschange' is invalid in C99                    
      [-Wimplicit-function-declaration]
                issue_brightnesschange(oldn->brightness_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  Sat Feb 19 05:42:12 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 19 Feb 2011 05:42:12 -0600 (CST)
Subject: [LLVMbugs] [Bug 9261] New: clang: error: array initializer must be
 an initializer list or string literal
Message-ID: <bug-9261-206@http.llvm.org/bugs/>

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

           Summary: clang: error: array initializer must be an initializer
                    list or string literal
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: edwintorok at gmail.com
                CC: llvmbugs at cs.uiuc.edu
            Blocks: 4068


drivers/scsi/fcoe/libfcoe.c:63:11: error: array initializer must be an
initializer list or string literal
static u8 fcoe_all_fcfs[ETH_ALEN] = FIP_ALL_FCF_MACS;
          ^

Testcase:
typedef unsigned char u8;
typedef unsigned char __u8;
static u8 fcoe_all_p2p[6] = ((__u8[6]) { 1, 0x10, 0x18, 1, 0, 5 });

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 19 05:44:01 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 19 Feb 2011 05:44:01 -0600 (CST)
Subject: [LLVMbugs] [Bug 9260] clang: nested functions not supported?
In-Reply-To: <bug-9260-206@http.llvm.org/bugs/>
References: <bug-9260-206@http.llvm.org/bugs/>
Message-ID: <20110219114401.0CB372A6C131@llvm.org>

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

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

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

--- Comment #1 from Anton Korobeynikov <asl at math.spbu.ru> 2011-02-19 05:44:00 CST ---


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

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 19 05:45:44 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 19 Feb 2011 05:45:44 -0600 (CST)
Subject: [LLVMbugs] [Bug 9262] New: clang/lib/AST/ExprConstant.cpp:2654:
 llvm::APSInt clang::Expr::EvaluateAsInt(const clang::ASTContext&) const:
 Assertion `Result && "Could not evaluate expression"' failed.
Message-ID: <bug-9262-206@http.llvm.org/bugs/>

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

           Summary: clang/lib/AST/ExprConstant.cpp:2654: llvm::APSInt
                    clang::Expr::EvaluateAsInt(const clang::ASTContext&)
                    const: Assertion `Result && "Could not evaluate
                    expression"' failed.
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: edwintorok at gmail.com
                CC: llvmbugs at cs.uiuc.edu


arch/x86/kernel/cpu/cpufreq/speedstep-centrino.c triggers an assert in Clang's
preprocessor it seems.

Testcase:
struct mem_section {
};
extern struct mem_section *mem_section[((((1UL << (46 - 27))) + ((((1UL) << 12)
/ sizeof (struct mem_section))) - 1) / ((((1UL) << 12) / sizeof (struct
mem_section))))];

clang:
/home/edwin/HDD/edwin/llvm-git/offi/llvm/tools/clang/lib/AST/ExprConstant.cpp:2654:
llvm::APSInt clang::Expr::EvaluateAsInt(const clang::ASTContext&) const:
Assertion `Result && "Could not evaluate expression"' failed.
0  clang           0x00000000015056ef
1  clang           0x0000000001507952
2  libpthread.so.0 0x0000003f36a0ef60
3  libc.so.6       0x0000003f35e32165 gsignal + 53
4  libc.so.6       0x0000003f35e34f70 abort + 384
5  libc.so.6       0x0000003f35e2b2b1 __assert_fail + 241
6  clang           0x0000000000ce9d82
7  clang           0x0000000000cea6a4
8  clang           0x0000000000cea224
9  clang           0x0000000000cea9ac
clang::Expr::isIntegerConstantExpr(llvm::APSInt&, clang::ASTContext&,
clang::SourceLocation*, bool) const + 44
10 clang           0x0000000000ae17f1
clang::Sema::BuildArrayType(clang::QualType,
clang::ArrayType::ArraySizeModifier, clang::Expr*, unsigned int,
clang::SourceRange, clang::DeclarationName) + 2401
11 clang           0x0000000000ae5e57
clang::Sema::GetTypeForDeclarator(clang::Declarator&, clang::Scope*,
clang::TagDecl**) + 2327
12 clang           0x000000000093c59e
clang::Sema::HandleDeclarator(clang::Scope*, clang::Declarator&,
clang::ASTMultiPtr<clang::TemplateParameterList*>, bool) + 302
13 clang           0x000000000088bb72
clang::Parser::ParseDeclarationAfterDeclarator(clang::Declarator&,
clang::Parser::ParsedTemplateInfo const&) + 114
14 clang           0x000000000088dae0
clang::Parser::ParseDeclGroup(clang::Parser::ParsingDeclSpec&, unsigned int,
bool, clang::SourceLocation*) + 768
15 clang           0x0000000000885ad2
clang::Parser::ParseDeclarationOrFunctionDefinition(clang::Parser::ParsingDeclSpec&,
clang::AccessSpecifier) + 146
16 clang           0x0000000000885ed9
clang::Parser::ParseDeclarationOrFunctionDefinition(clang::ParsedAttributes&,
clang::AccessSpecifier) + 409
17 clang           0x0000000000888082
clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&,
clang::Parser::ParsingDeclSpec*) + 1506
18 clang           0x00000000008881bd
clang::Parser::ParseTopLevelDecl(clang::OpaquePtr<clang::DeclGroupRef>&) + 109
19 clang           0x000000000086eafb clang::ParseAST(clang::Sema&, bool) + 139
20 clang           0x000000000074c004 clang::CodeGenAction::ExecuteAction() +
68
21 clang           0x00000000006309bb
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 347
22 clang           0x000000000060b7fc
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1276
23 clang           0x00000000006031cf cc1_main(char const**, char const**, char
const*, void*) + 415
24 clang           0x000000000060a805 main + 4629
25 libc.so.6       0x0000003f35e1ec4d __libc_start_main + 253
26 clang           0x00000000006018a9
Stack dump:
0.      Program arguments:
/home/edwin/HDD/edwin/llvm-git/offi/obj/Release+Asserts/bin/clang -cc1 -triple
x86_64-unknown-linux-gnu -emit-obj -mrelax-all -disable-free -main-file-name
14589.c -mrelocation-model static -mdisable-fp-elim -masm-verbose
-mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version
2.20.1 -momit-leaf-frame-pointer -resource-dir
/home/edwin/HDD/edwin/llvm-git/offi/obj/Release+Asserts/bin/../lib/clang/2.9
-ferror-limit 19 -fmessage-length 147 -fgnu-runtime -fdiagnostics-show-option
-fcolor-diagnostics -o /tmp/cc-WvE2y5.o -x c tmp8/14589.c 
1.      tmp8/14589.c:3:169: current parser token ';'
clang: error: unable to execute command: Aborted
clang: error: clang frontend command failed due to signal 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  Sat Feb 19 07:51:03 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 19 Feb 2011 07:51:03 -0600 (CST)
Subject: [LLVMbugs] [Bug 9263] New: release_file_streams_for_task and
 __abort on clang 2.9 (trunk 124557)
Message-ID: <bug-9263-206@http.llvm.org/bugs/>

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

           Summary: release_file_streams_for_task and __abort on clang 2.9
                    (trunk 124557)
           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: StephaneLeon at Bluewin.ch
                CC: llvmbugs at cs.uiuc.edu


Hello,

This objective C line (Xcode 3.2.5 on MacOsxx 10.6.6) :

if (!(file = fopen([aPath UTF8String],"wb"))) STAssertEquals( 0, 1, @"Cannot
write generated test file, probably autorization problem");

( STAssertEquals is in SenTestCase.h )

Cause this one on crash :

3   libSystem.B.dylib                 0x00007fff88e6fc75 __abort + 113
4   libSystem.B.dylib                 0x00007fff88e542cc
release_file_streams_for_task + 0

Its works fine on gcc4.2, 4.5.2 and on default macosx clang (Apple clang
version 1.6 (tags/Apple/clang-70)), but not on lastest i update every day.

Thank you

--
Stephane

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 19 08:57:59 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 19 Feb 2011 08:57:59 -0600 (CST)
Subject: [LLVMbugs] [Bug 9264] New: [mc]
Message-ID: <bug-9264-206@http.llvm.org/bugs/>

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

           Summary: [mc]
           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: edwintorok at gmail.com
                CC: llvmbugs at cs.uiuc.edu
            Blocks: 4068


clang -integrated-as first error with Linux kernel:
/home/edwin/builds/linux-2.6/arch/x86/include/asm/bitops.h:319:15: error:
ambiguous instructions require an explicit suffix
      (could be 'btw', 'btl', or 'btq')
        asm volatile("bt %2,%1\n\t"
                     ^
<inline asm>:1:2: note: instantiated into assembly here                         
        bt $0,cpu_all_bits
        ^


asm volatile("bt %2,%1\n\t"
             "sbb %0,%0"
             : "=r" (oldbit)
             : "m" (*(unsigned long *)addr), "Ir" (nr));

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 19 10:49:22 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 19 Feb 2011 10:49:22 -0600 (CST)
Subject: [LLVMbugs] [Bug 9265] New: --enable-targets=host-only make check
 fails: arm tests should not be run
Message-ID: <bug-9265-206@http.llvm.org/bugs/>

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

           Summary: --enable-targets=host-only make check fails: arm tests
                    should not be run
           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: edwintorok at gmail.com
                CC: llvmbugs at cs.uiuc.edu


These tests should probably not be run at all if their respective target is not
built:
FAIL: LLVM :: DebugInfo/2009-10-16-Scope.ll (3044 of 5810)
******************** TEST 'LLVM :: DebugInfo/2009-10-16-Scope.ll' FAILED
********************
Script:
--
/home/edwin/HDD/edwin/llvm-git/offi/obj/Release+Asserts/bin/llc
/home/edwin/HDD/edwin/llvm-git/offi/llvm/test/DebugInfo/2009-10-16-Scope.ll -O0
-o /dev/null -mtriple=x86_64-apple-darwin
/home/edwin/HDD/edwin/llvm-git/offi/obj/Release+Asserts/bin/llc
/home/edwin/HDD/edwin/llvm-git/offi/llvm/test/DebugInfo/2009-10-16-Scope.ll -O0
-o /dev/null -mtriple=arm-apple-darwin
--
Exit Code: 1
Command Output (stderr):
--
/home/edwin/HDD/edwin/llvm-git/offi/obj/Release+Asserts/bin/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.
--

********************
FAIL: LLVM :: DebugInfo/2010-08-04-StackVariable.ll (3066 of 5810)
******************** TEST 'LLVM :: DebugInfo/2010-08-04-StackVariable.ll'
FAILED ********************
Script:
--
/home/edwin/HDD/edwin/llvm-git/offi/obj/Release+Asserts/bin/llc -O0
-mtriple=arm-apple-darwin <
/home/edwin/HDD/edwin/llvm-git/offi/llvm/test/DebugInfo/2010-08-04-StackVariable.ll
| grep DW_OP_fbreg
/home/edwin/HDD/edwin/llvm-git/offi/obj/Release+Asserts/bin/llc -O0
-mtriple=x86_64-apple-darwin <
/home/edwin/HDD/edwin/llvm-git/offi/llvm/test/DebugInfo/2010-08-04-StackVariable.ll
| grep DW_OP_fbreg
--
Exit Code: 1
Command Output (stderr):
--
/home/edwin/HDD/edwin/llvm-git/offi/obj/Release+Asserts/bin/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.
--

********************
FAIL: LLVM :: MC/AsmParser/full_line_comment.s (3930 of 5810)
******************** TEST 'LLVM :: MC/AsmParser/full_line_comment.s' FAILED
********************
Script:
--
/home/edwin/HDD/edwin/llvm-git/offi/obj/Release+Asserts/bin/llvm-mc -triple
arm-apple-darwin10
/home/edwin/HDD/edwin/llvm-git/offi/llvm/test/MC/AsmParser/full_line_comment.s
| /home/edwin/HDD/edwin/llvm-git/offi/obj/Release+Asserts/bin/FileCheck
/home/edwin/HDD/edwin/llvm-git/offi/llvm/test/MC/AsmParser/full_line_comment.s
--
Exit Code: 1
Command Output (stderr):
--
/home/edwin/HDD/edwin/llvm-git/offi/obj/Release+Asserts/bin/llvm-mc: error:
unable to get target for 'arm-apple-darwin10', see --version and --triple.
FileCheck error: '-' is empty.
--

********************
FAIL: LLVM :: MC/MachO/darwin-ARM-reloc.s (4050 of 5810)
******************** TEST 'LLVM :: MC/MachO/darwin-ARM-reloc.s' FAILED
********************
Script:
--
/home/edwin/HDD/edwin/llvm-git/offi/obj/Release+Asserts/bin/llvm-mc -n -triple
armv7-apple-darwin10
/home/edwin/HDD/edwin/llvm-git/offi/llvm/test/MC/MachO/darwin-ARM-reloc.s
-filetype=obj -o
/home/edwin/HDD/edwin/llvm-git/offi/obj/test/MC/MachO/Output/darwin-ARM-reloc.s.tmp.obj
/home/edwin/HDD/edwin/llvm-git/offi/obj/Release+Asserts/bin/macho-dump
--dump-section-data <
/home/edwin/HDD/edwin/llvm-git/offi/obj/test/MC/MachO/Output/darwin-ARM-reloc.s.tmp.obj
>
/home/edwin/HDD/edwin/llvm-git/offi/obj/test/MC/MachO/Output/darwin-ARM-reloc.s.tmp.dump
/home/edwin/HDD/edwin/llvm-git/offi/obj/Release+Asserts/bin/FileCheck <
/home/edwin/HDD/edwin/llvm-git/offi/obj/test/MC/MachO/Output/darwin-ARM-reloc.s.tmp.dump
/home/edwin/HDD/edwin/llvm-git/offi/llvm/test/MC/MachO/darwin-ARM-reloc.s
--
Exit Code: 1
Command Output (stderr):
--
/home/edwin/HDD/edwin/llvm-git/offi/obj/Release+Asserts/bin/llvm-mc: error:
unable to get target for 'armv7-apple-darwin10', see --version and --triple.
--

********************
FAIL: LLVM :: MC/MachO/darwin-Thumb-reloc.s (4051 of 5810)
******************** TEST 'LLVM :: MC/MachO/darwin-Thumb-reloc.s' FAILED
********************
Script:
--
/home/edwin/HDD/edwin/llvm-git/offi/obj/Release+Asserts/bin/llvm-mc -n -triple
thumbv7-apple-darwin10
/home/edwin/HDD/edwin/llvm-git/offi/llvm/test/MC/MachO/darwin-Thumb-reloc.s
-filetype=obj -o
/home/edwin/HDD/edwin/llvm-git/offi/obj/test/MC/MachO/Output/darwin-Thumb-reloc.s.tmp.obj
/home/edwin/HDD/edwin/llvm-git/offi/obj/Release+Asserts/bin/macho-dump
--dump-section-data <
/home/edwin/HDD/edwin/llvm-git/offi/obj/test/MC/MachO/Output/darwin-Thumb-reloc.s.tmp.obj
>
/home/edwin/HDD/edwin/llvm-git/offi/obj/test/MC/MachO/Output/darwin-Thumb-reloc.s.tmp.dump
/home/edwin/HDD/edwin/llvm-git/offi/obj/Release+Asserts/bin/FileCheck <
/home/edwin/HDD/edwin/llvm-git/offi/obj/test/MC/MachO/Output/darwin-Thumb-reloc.s.tmp.dump
/home/edwin/HDD/edwin/llvm-git/offi/llvm/test/MC/MachO/darwin-Thumb-reloc.s
--
Exit Code: 1
Command Output (stderr):
--
/home/edwin/HDD/edwin/llvm-git/offi/obj/Release+Asserts/bin/llvm-mc: error:
unable to get target for 'thumbv7-apple-darwin10', see --version and --triple.
--

********************
Testing Time: 29.69s
********************
Failing Tests (5):
    LLVM :: DebugInfo/2009-10-16-Scope.ll
    LLVM :: DebugInfo/2010-08-04-StackVariable.ll
    LLVM :: MC/AsmParser/full_line_comment.s
    LLVM :: MC/MachO/darwin-ARM-reloc.s
    LLVM :: MC/MachO/darwin-Thumb-reloc.s

  Expected Passes    : 3882
  Expected Failures  : 16
  Unsupported Tests  : 1907
  Unexpected Failures: 5

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 19 12:15:07 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 19 Feb 2011 12:15:07 -0600 (CST)
Subject: [LLVMbugs] [Bug 9266] New: Only trivial scalar-to-vector
 conversions should get here!
Message-ID: <bug-9266-206@http.llvm.org/bugs/>

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

           Summary: Only trivial scalar-to-vector conversions should get
                    here!
           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


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

llc foo.ll
llc: /home/espindola/llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp:291:
llvm::SDValue getCopyFromPartsVector(llvm::SelectionDAG&, llvm::DebugLoc, const
llvm::SDValue*, unsigned int, llvm::EVT, llvm::EVT): Assertion
`ValueVT.getVectorElementType() == PartVT && ValueVT.getVectorNumElements() ==
1 && "Only trivial scalar-to-vector conversions should get here!"' 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  Sat Feb 19 13:04:47 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 19 Feb 2011 13:04:47 -0600 (CST)
Subject: [LLVMbugs] [Bug 8396] Fix-it for "main must return int" is wrong
 for "unsigned int"
In-Reply-To: <bug-8396-206@http.llvm.org/bugs/>
References: <bug-8396-206@http.llvm.org/bugs/>
Message-ID: <20110219190447.53A2F2A6C124@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #1 from Douglas Gregor <dgregor at apple.com> 2011-02-19 13:04:47 CST ---
Removed the Fix-It in r126035.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 19 13:06:09 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 19 Feb 2011 13:06:09 -0600 (CST)
Subject: [LLVMbugs] [Bug 8444] c++ templated embedded class loses field that
	under union
In-Reply-To: <bug-8444-206@http.llvm.org/bugs/>
References: <bug-8444-206@http.llvm.org/bugs/>
Message-ID: <20110219190609.718B22A6C124@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #1 from Douglas Gregor <dgregor at apple.com> 2011-02-19 13:06:09 CST ---
This is fixed on top-of-tree, most likely by r125822.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 19 13:14:43 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 19 Feb 2011 13:14:43 -0600 (CST)
Subject: [LLVMbugs] [Bug 9238] overzealous virtual destructor warning due to
 virtual inheritance
In-Reply-To: <bug-9238-206@http.llvm.org/bugs/>
References: <bug-9238-206@http.llvm.org/bugs/>
Message-ID: <20110219191443.062CD2A6C12F@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #1 from Douglas Gregor <dgregor at apple.com> 2011-02-19 13:14:42 CST ---
Fixed in Clang r126036.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 19 13:25:07 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 19 Feb 2011 13:25:07 -0600 (CST)
Subject: [LLVMbugs] [Bug 9225] Member classes of the current instantiation
 are not the current instantiation
In-Reply-To: <bug-9225-206@http.llvm.org/bugs/>
References: <bug-9225-206@http.llvm.org/bugs/>
Message-ID: <20110219192507.23BE52A6C12D@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #1 from Douglas Gregor <dgregor at apple.com> 2011-02-19 13:25:06 CST ---
Fixed in Clang r126038.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 19 13:50:41 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 19 Feb 2011 13:50:41 -0600 (CST)
Subject: [LLVMbugs] [Bug 9258] clang: unsupported inline asm: input with
 type 'int' matching output with type 'u8' (aka 'unsigned char')
In-Reply-To: <bug-9258-206@http.llvm.org/bugs/>
References: <bug-9258-206@http.llvm.org/bugs/>
Message-ID: <20110219195041.C90ED2A6C12E@llvm.org>

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

Nick Lewycky <nicholas at mxc.ca> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |nicholas at mxc.ca
         Resolution|                            |DUPLICATE

--- Comment #1 from Nick Lewycky <nicholas at mxc.ca> 2011-02-19 13:50:41 CST ---


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

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 19 14:03:33 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 19 Feb 2011 14:03:33 -0600 (CST)
Subject: [LLVMbugs] [Bug 8894] Clang++ misses an invalid construct in Sema
 and assert in codegen.
In-Reply-To: <bug-8894-206@http.llvm.org/bugs/>
References: <bug-8894-206@http.llvm.org/bugs/>
Message-ID: <20110219200333.CE6062A6C12E@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #1 from Douglas Gregor <dgregor at apple.com> 2011-02-19 14:03:33 CST ---
John recently fixed this on top-of-tree with his refactoring of our ? :
handling.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 19 14:50:05 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 19 Feb 2011 14:50:05 -0600 (CST)
Subject: [LLVMbugs] [Bug 9267] New: vector ZExt code generation bug
Message-ID: <bug-9267-206@http.llvm.org/bugs/>

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

           Summary: vector ZExt code generation bug
           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: nadav.rotem at intel.com
                CC: llvmbugs at cs.uiuc.edu


According to the LangRef, vector Zext are not supported by the spec. However,
we would like to enable them. Currently, most vector zext instructions would
crash the codegen in various places. For example:


llc: XXX/lib/CodeGen/SelectionDAG/SelectionDAG.cpp:3914: llvm::SDValue
llvm::SelectionDAG::getLoad(llvm::ISD::MemIndexedMode, llvm::ISD::LoadExtType,
llvm::EVT, llvm::DebugLoc, llvm::SDValue, llvm::SDValue, llvm::SDValue,
llvm::EVT, llvm::MachineMemOperand*): Assertion `VT.isVector() ==
MemVT.isVector() && "Cannot use trunc store to convert to or from a vector!"'
failed.

vector zext is properly expanded to any_extend, except for cases where it is
combined with the load operation. The problem is with the DAGcombining pass. In
the first round, where it is okay to create illegal types and operations, it
creates a complex-zext load. The problem is that there is no legalizer to
legalize the newly load in the following stages. 


Here is a patch against 2.8. It works on a bunch of test cases that I
generated. 


Index: DAGCombiner.cpp
===================================================================
--- DAGCombiner.cpp    (revision XXX)
+++ DAGCombiner.cpp    (working copy)
@@ -3685,8 +3685,7 @@

   // fold (zext (load x)) -> (zext (truncate (zextload x)))
   if (ISD::isNON_EXTLoad(N0.getNode()) &&
-      ((!LegalOperations && !cast<LoadSDNode>(N0)->isVolatile()) ||
-       TLI.isLoadExtLegal(ISD::ZEXTLOAD, N0.getValueType()))) {
+      (TLI.isLoadExtLegal(ISD::ZEXTLOAD, N0.getValueType()))) {
     bool DoXform = true;
     SmallVector<SDNode*, 4> SetCCs;
     if (!N0.hasOneUse())

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 19 15:06:47 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 19 Feb 2011 15:06:47 -0600 (CST)
Subject: [LLVMbugs] [Bug 9264] [mc] error: ambiguous instructions require an
 explicit suffix (could be 'btw', 'btl', or 'btq')
In-Reply-To: <bug-9264-206@http.llvm.org/bugs/>
References: <bug-9264-206@http.llvm.org/bugs/>
Message-ID: <20110219210647.5EAC02A6C12D@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #3 from Chris Lattner <clattner at apple.com> 2011-02-19 15:06:47 CST ---
Fair enough, implemented in r126047.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 19 15:07:50 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 19 Feb 2011 15:07:50 -0600 (CST)
Subject: [LLVMbugs] [Bug 9268] New: Dwarfdump complains about invalid file
	info
Message-ID: <bug-9268-206@http.llvm.org/bugs/>

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

           Summary: Dwarfdump complains about invalid file info
           Product: new-bugs
           Version: trunk
          Platform: All
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: viridia at gmail.com
                CC: llvmbugs at cs.uiuc.edu


With the following attachment ("Hello2.ll"), compile using the following
commands:

   llc -O0 -disable-fp-elim -filetype=obj Hello2.ll
   /usr/bin/c++ -g -o Hello2 Hello2.o 

Now run dwarfdump -ka on the resulting executable:

   dwarfdump -ka Hello2

Drawdump prints out a bunch of messages of the following form:

*** DWARF CHECK: DW_AT_decl_file: does not point to valid file info ***

Note that this issue occurs using both the old DIFactory and the new DIBuilder.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 19 15:41:05 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 19 Feb 2011 15:41:05 -0600 (CST)
Subject: [LLVMbugs] [Bug 6385] __block used in libstdc++ header
In-Reply-To: <bug-6385-206@http.llvm.org/bugs/>
References: <bug-6385-206@http.llvm.org/bugs/>
Message-ID: <20110219214105.693EC2A6C124@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #1 from Douglas Gregor <dgregor at apple.com> 2011-02-19 15:41:05 CST ---
We're not planning to work around this. Users on Mac OS X have a libstdc++ they
can use, or they can turn off blocks with -fno-blocks.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 19 15:41:42 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 19 Feb 2011 15:41:42 -0600 (CST)
Subject: [LLVMbugs] [Bug 9266] Only trivial scalar-to-vector conversions
 should get here!
In-Reply-To: <bug-9266-206@http.llvm.org/bugs/>
References: <bug-9266-206@http.llvm.org/bugs/>
Message-ID: <20110219214142.97E8C2A6C12E@llvm.org>

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

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  Sat Feb 19 15:55:06 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 19 Feb 2011 15:55:06 -0600 (CST)
Subject: [LLVMbugs] [Bug 6521] decl not getting marked used
In-Reply-To: <bug-6521-206@http.llvm.org/bugs/>
References: <bug-6521-206@http.llvm.org/bugs/>
Message-ID: <20110219215506.393492A6C12F@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #2 from Douglas Gregor <dgregor at apple.com> 2011-02-19 15:55:05 CST ---
Fixed in Clang r126055.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 19 15:55:12 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 19 Feb 2011 15:55:12 -0600 (CST)
Subject: [LLVMbugs] [Bug 9269] New: clang/lib/Analysis/CFG.cpp:1558:
 clang::CFGBlock*<unnamed>::CFGBuilder::VisitForStmt(clang::ForStmt*):
 Assertion `Block == EntryConditionBlock || (Block == 0 &&
 EntryConditionBlock == Succ)' failed.
Message-ID: <bug-9269-206@http.llvm.org/bugs/>

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

           Summary: clang/lib/Analysis/CFG.cpp:1558:
                    clang::CFGBlock*<unnamed>::CFGBuilder::VisitForStmt(cl
                    ang::ForStmt*): Assertion `Block ==
                    EntryConditionBlock || (Block == 0 &&
                    EntryConditionBlock == Succ)' failed.
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: edwintorok at gmail.com
                CC: llvmbugs at cs.uiuc.edu
            Blocks: 4068


Compiling speedstep-centrino.c from the Linux kernel triggers assert in clang:
clang:
/home/edwin/HDD/edwin/llvm-git/offi/llvm/tools/clang/lib/Analysis/CFG.cpp:1558:
clang::CFGBlock*<unnamed>::CFGBuilder::VisitForStmt(clang::ForStmt*): Assertion
`Block == EntryConditionBlock || (Block == 0 && EntryConditionBlock == Succ)'
failed.
0  clang           0x0000000001505b1f
1  clang           0x0000000001507d82
2  libpthread.so.0 0x0000003f36a0ef60
3  libc.so.6       0x0000003f35e32165 gsignal + 53
4  libc.so.6       0x0000003f35e34f70 abort + 384
5  libc.so.6       0x0000003f35e2b2b1 __assert_fail + 241
6  clang           0x0000000000c04c32
7  clang           0x0000000000bfef64
8  clang           0x0000000000bff9d8
9  clang           0x0000000000c027ce clang::CFG::buildCFG(clang::Decl const*,
clang::Stmt*, clang::ASTContext*, clang::CFG::BuildOptions) + 1646
10 clang           0x0000000000bf26e5 clang::AnalysisContext::getCFG() + 181
11 clang           0x0000000000aebd8e
clang::sema::AnalysisBasedWarnings::IssueWarnings(clang::sema::AnalysisBasedWarnings::Policy,
clang::Decl const*, clang::QualType) + 638
12 clang           0x000000000092468d
clang::Sema::ActOnFinishFunctionBody(clang::Decl*, clang::Stmt*, bool) + 701
13 clang           0x000000000087c9a8
clang::Parser::ParseFunctionStatementBody(clang::Decl*) + 168
14 clang           0x0000000000886f83
clang::Parser::ParseFunctionDefinition(clang::Parser::ParsingDeclarator&,
clang::Parser::ParsedTemplateInfo const&) + 707
15 clang           0x000000000088de8f
clang::Parser::ParseDeclGroup(clang::Parser::ParsingDeclSpec&, unsigned int,
bool, clang::SourceLocation*) + 1535
16 clang           0x0000000000885b82
clang::Parser::ParseDeclarationOrFunctionDefinition(clang::Parser::ParsingDeclSpec&,
clang::AccessSpecifier) + 146
17 clang           0x0000000000885f89
clang::Parser::ParseDeclarationOrFunctionDefinition(clang::ParsedAttributes&,
clang::AccessSpecifier) + 409
18 clang           0x0000000000888132
clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&,
clang::Parser::ParsingDeclSpec*) + 1506
19 clang           0x000000000088826d
clang::Parser::ParseTopLevelDecl(clang::OpaquePtr<clang::DeclGroupRef>&) + 109
20 clang           0x000000000086ebab clang::ParseAST(clang::Sema&, bool) + 139
21 clang           0x000000000074c0b4 clang::CodeGenAction::ExecuteAction() +
68
22 clang           0x0000000000630a6b
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 347
23 clang           0x000000000060b8ac
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1276
24 clang           0x000000000060327f cc1_main(char const**, char const**, char
const*, void*) + 415
25 clang           0x000000000060a8b5 main + 4629
26 libc.so.6       0x0000003f35e1ec4d __libc_start_main + 253
27 clang           0x0000000000601959
Stack dump:
0.      Program arguments:
/home/edwin/HDD/edwin/llvm-git/offi/obj/Release+Asserts/bin/clang -cc1 -triple
x86_64-unknown-linux-gnu -S -disable-free -main-file-name speedstep-centrino.c
-mrelocation-model static -mdisable-fp-elim -relaxed-aliasing -masm-verbose
-mconstructor-aliases -mcode-model kernel -disable-red-zone -target-cpu x86-64
-target-feature -sse -target-feature -mmx -target-feature -sse2 -target-feature
-3dnow -target-linker-version 2.20.1 -momit-leaf-frame-pointer -g -nostdinc
-resource-dir
/home/edwin/HDD/edwin/llvm-git/offi/obj/Release+Asserts/bin/../lib/clang/2.9
-dependency-file arch/x86/kernel/cpu/cpufreq/.speedstep-centrino.o.d -MT
arch/x86/kernel/cpu/cpufreq/.tmp_speedstep-centrino.o -sys-header-deps -isystem
/usr/lib/gcc/x86_64-linux-gnu/4.4.5/include -include
include/generated/autoconf.h -D __KERNEL__ -D CONFIG_AS_CFI=1 -D
CONFIG_AS_CFI_SIGNAL_FRAME=1 -D CONFIG_AS_CFI_SECTIONS=1 -D CONFIG_AS_FXSAVEQ=1
-D KBUILD_STR(s)=#s -D KBUILD_BASENAME=KBUILD_STR(speedstep_centrino) -D
KBUILD_MODNAME=KBUILD_STR(speedstep_centrino) -I
/home/edwin/builds/linux-2.6/arch/x86/include -I include -Os -Wall -Wundef
-Wstrict-prototypes -Wno-trigraphs -Werror-implicit-function-declaration
-Wno-format-security -Wno-sign-compare -Wframe-larger-than=2048
-Wdeclaration-after-statement -Wno-pointer-sign -Wno-unused-value
-Wno-array-bounds -Wno-unused-variable -ferror-limit 19 -fmessage-length 147
-pg -stack-protector 1 -fgnu-runtime -fno-common -fdiagnostics-show-option
-fcolor-diagnostics -o /tmp/cc-s6bvtc.s -x c
arch/x86/kernel/cpu/cpufreq/speedstep-centrino.c 
1.      arch/x86/kernel/cpu/cpufreq/speedstep-centrino.c:323:1: current parser
token 'static'
2.      arch/x86/kernel/cpu/cpufreq/speedstep-centrino.c:288:1: parsing
function body 'extract_clock'
clang: error: unable to execute command: Aborted
clang: error: clang frontend command failed due to signal 1 (use -v to see
invocation)


Here is reduced testcase, hope I got it right this time:
extern unsigned long __per_cpu_offset[4096];
        struct cpufreq_frequency_table {
       unsigned int frequency;
       };
           struct cpu_model {
        struct cpufreq_frequency_table *op_points;
      };
         __attribute__((section(".data..percpu" ""))) __attribute__((weak))
__typeof__(struct cpu_model *) centrino_model;
           static unsigned extract_clock(unsigned msr, unsigned int cpu, int
failsafe) {
       int i;
             if (((*({
    ({
  unsigned long __ptr;
  (typeof((typeof(*(&(centrino_model))) *)(&(centrino_model)))) (__ptr +
(((__per_cpu_offset[cpu]))));
  }
   );
    }
     ))->op_points))   return 0;
       for (i = 0;
        (*({
    while (0);
    ({
  unsigned long __ptr;
  (typeof((typeof(*(&(centrino_model))) *)(&(centrino_model)))) (__ptr +
(((__per_cpu_offset[cpu]))));
  }
   );
    }
     ))->op_points[i].frequency        != ~1;
            i++) {
   }
    }


clang:
/home/edwin/HDD/edwin/llvm-git/offi/llvm/tools/clang/lib/Analysis/CFG.cpp:1558:
clang::CFGBlock*<unnamed>::CFGBuilder::VisitForStmt(clang::ForStmt*): Assertion
`Block == EntryConditionBlock || (Block == 0 && EntryConditionBlock == Succ)'
failed.
0  clang           0x0000000001505b1f
1  clang           0x0000000001507d82
2  libpthread.so.0 0x0000003f36a0ef60
3  libc.so.6       0x0000003f35e32165 gsignal + 53
4  libc.so.6       0x0000003f35e34f70 abort + 384
5  libc.so.6       0x0000003f35e2b2b1 __assert_fail + 241
6  clang           0x0000000000c04c32
7  clang           0x0000000000bfef64
8  clang           0x0000000000bff9d8
9  clang           0x0000000000c027ce clang::CFG::buildCFG(clang::Decl const*,
clang::Stmt*, clang::ASTContext*, clang::CFG::BuildOptions) + 1646
10 clang           0x0000000000bf26e5 clang::AnalysisContext::getCFG() + 181
11 clang           0x0000000000aebd8e
clang::sema::AnalysisBasedWarnings::IssueWarnings(clang::sema::AnalysisBasedWarnings::Policy,
clang::Decl const*, clang::QualType) + 638
12 clang           0x000000000092468d
clang::Sema::ActOnFinishFunctionBody(clang::Decl*, clang::Stmt*, bool) + 701
13 clang           0x000000000087c9a8
clang::Parser::ParseFunctionStatementBody(clang::Decl*) + 168
14 clang           0x0000000000886f83
clang::Parser::ParseFunctionDefinition(clang::Parser::ParsingDeclarator&,
clang::Parser::ParsedTemplateInfo const&) + 707
15 clang           0x000000000088de8f
clang::Parser::ParseDeclGroup(clang::Parser::ParsingDeclSpec&, unsigned int,
bool, clang::SourceLocation*) + 1535
16 clang           0x0000000000885b82
clang::Parser::ParseDeclarationOrFunctionDefinition(clang::Parser::ParsingDeclSpec&,
clang::AccessSpecifier) + 146
17 clang           0x0000000000885f89
clang::Parser::ParseDeclarationOrFunctionDefinition(clang::ParsedAttributes&,
clang::AccessSpecifier) + 409
18 clang           0x0000000000888132
clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&,
clang::Parser::ParsingDeclSpec*) + 1506
19 clang           0x000000000088826d
clang::Parser::ParseTopLevelDecl(clang::OpaquePtr<clang::DeclGroupRef>&) + 109
20 clang           0x000000000086ebab clang::ParseAST(clang::Sema&, bool) + 139
21 clang           0x000000000074c0b4 clang::CodeGenAction::ExecuteAction() +
68
22 clang           0x0000000000630a6b
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 347
23 clang           0x000000000060b8ac
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1276
24 clang           0x000000000060327f cc1_main(char const**, char const**, char
const*, void*) + 415
25 clang           0x000000000060a8b5 main + 4629
26 libc.so.6       0x0000003f35e1ec4d __libc_start_main + 253
27 clang           0x0000000000601959
Stack dump:
0.      Program arguments:
/home/edwin/HDD/edwin/llvm-git/offi/obj/Release+Asserts/bin/clang -cc1 -triple
x86_64-unknown-linux-gnu -emit-obj -mrelax-all -disable-free -main-file-name
x.i -mrelocation-model static -mdisable-fp-elim -masm-verbose
-mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version
2.20.1 -momit-leaf-frame-pointer -resource-dir
/home/edwin/HDD/edwin/llvm-git/offi/obj/Release+Asserts/bin/../lib/clang/2.9
-ferror-limit 19 -fmessage-length 147 -fgnu-runtime -fdiagnostics-show-option
-fcolor-diagnostics -o x.o -x cpp-output x.i 
1.      <eof> parser at end of file
2.      x.i:9:88: parsing function body 'extract_clock'
clang: error: unable to execute command: Aborted
clang: error: clang frontend command failed due to signal 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  Sat Feb 19 15:59:09 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 19 Feb 2011 15:59:09 -0600 (CST)
Subject: [LLVMbugs] [Bug 7449] clang miscompile with VLA in loop
In-Reply-To: <bug-7449-206@http.llvm.org/bugs/>
References: <bug-7449-206@http.llvm.org/bugs/>
Message-ID: <20110219215909.9FA152A6C12F@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #6 from Douglas Gregor <dgregor at apple.com> 2011-02-19 15:59:08 CST ---
It's been five months since we heard anything about this issue, and there is no
reproducible test case to work from. If Clang top-of-tree still has a problem
here, please provide a self-contained, reproducible test case for us to work
with,

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 19 16:29:14 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 19 Feb 2011 16:29:14 -0600 (CST)
Subject: [LLVMbugs] [Bug 9257] [Linux Kernel] clang: error: cannot compile
 this GNU array range designator extension yet
In-Reply-To: <bug-9257-206@http.llvm.org/bugs/>
References: <bug-9257-206@http.llvm.org/bugs/>
Message-ID: <20110219222914.31CF52A6C12E@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #4 from Chris Lattner <clattner at apple.com> 2011-02-19 16:29:13 CST ---
Implemented in r126056!

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 19 16:35:31 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 19 Feb 2011 16:35:31 -0600 (CST)
Subject: [LLVMbugs] [Bug 7536] "comparison of 0 > unsigned expression is
 always false" is too trigger happy.
In-Reply-To: <bug-7536-206@http.llvm.org/bugs/>
References: <bug-7536-206@http.llvm.org/bugs/>
Message-ID: <20110219223531.010672A6C124@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #4 from Douglas Gregor <dgregor at apple.com> 2011-02-19 16:35:30 CST ---
Fixed in Clang r126057.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 19 16:44:25 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 19 Feb 2011 16:44:25 -0600 (CST)
Subject: [LLVMbugs] [Bug 9218] malformed program causes infinite loop in
	InstCombiner
In-Reply-To: <bug-9218-206@http.llvm.org/bugs/>
References: <bug-9218-206@http.llvm.org/bugs/>
Message-ID: <20110219224425.B37D62A6C12D@llvm.org>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

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

--- Comment #3 from Eli Friedman <sharparrow1 at yahoo.com> 2011-02-19 16:44:25 CST ---
Hang fixed in r126058.  (And -lint already picks up this issue in IR.)

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 19 16:56:00 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 19 Feb 2011 16:56:00 -0600 (CST)
Subject: [LLVMbugs] [Bug 9253] [linux kernel] clang: wrong alignment for
 fields / wrong total struct size
In-Reply-To: <bug-9253-206@http.llvm.org/bugs/>
References: <bug-9253-206@http.llvm.org/bugs/>
Message-ID: <20110219225600.6F5722A6C12E@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #4 from Chris Lattner <clattner at apple.com> 2011-02-19 16:56:00 CST ---
Fixed in r126059, 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  Sat Feb 19 17:06:12 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 19 Feb 2011 17:06:12 -0600 (CST)
Subject: [LLVMbugs] [Bug 9250] -Warray-bounds too noisy on dead code
In-Reply-To: <bug-9250-206@http.llvm.org/bugs/>
References: <bug-9250-206@http.llvm.org/bugs/>
Message-ID: <20110219230612.708A52A6C12D@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #1 from Chris Lattner <clattner at apple.com> 2011-02-19 17:06:12 CST ---
I agree in some cases, but this is a case that we will never enhance it to
silence. This would require integrating it with real dataflow, which isn't
worth it.  In this case, the code is using a macro, so it can just #if
_NSIG_WORDS != 0
around the code in the default case to silence 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  Sat Feb 19 17:07:44 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 19 Feb 2011 17:07:44 -0600 (CST)
Subject: [LLVMbugs] [Bug 9254] clang can't build iptables in Linux kernel:
 error: fields must have a constant size: 'variable length array in
 structure' extension will never be supported
In-Reply-To: <bug-9254-206@http.llvm.org/bugs/>
References: <bug-9254-206@http.llvm.org/bugs/>
Message-ID: <20110219230744.E4E272A6C12D@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #2 from Chris Lattner <clattner at apple.com> 2011-02-19 17:07:44 CST ---
I agree.  This an nested functions are two things we really really don't want
to implement.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 19 17:08:14 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 19 Feb 2011 17:08:14 -0600 (CST)
Subject: [LLVMbugs] [Bug 9255] clang: can't compile arch/x86/boot in kernel
	(.code16gcc)
In-Reply-To: <bug-9255-206@http.llvm.org/bugs/>
References: <bug-9255-206@http.llvm.org/bugs/>
Message-ID: <20110219230814.162FE2A6C130@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #2 from Chris Lattner <clattner at apple.com> 2011-02-19 17:08:13 CST ---
Yep, it is.

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

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 19 17:09:20 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 19 Feb 2011 17:09:20 -0600 (CST)
Subject: [LLVMbugs] [Bug 9256] clang: support for kernel code model: pointer
 arithmetic that overflows is not impossible!
In-Reply-To: <bug-9256-206@http.llvm.org/bugs/>
References: <bug-9256-206@http.llvm.org/bugs/>
Message-ID: <20110219230920.EBDA82A6C130@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #2 from Chris Lattner <clattner at apple.com> 2011-02-19 17:09:20 CST ---
Right, they should build with -fwrapv or (better yet) do the computation with
an unsigned 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  Sat Feb 19 19:22:15 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 19 Feb 2011 19:22:15 -0600 (CST)
Subject: [LLVMbugs] [Bug 9270] New: Garbage collection intrinsics and
 debugging intrinsics don't mix
Message-ID: <bug-9270-206@http.llvm.org/bugs/>

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

           Summary: Garbage collection intrinsics and debugging intrinsics
                    don't mix
           Product: new-bugs
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: viridia at gmail.com
                CC: llvmbugs at cs.uiuc.edu


It appears that the presence of llvm.gcroot intrinsics cause the code generator
to emit improper DWARF debugging information. I have two sample files, one
which was generated with garbage collection enabled (Hello.ll) and another with
garbage collection disabled (Hello2.ll). I've also included the original source
file (Hello.tart).

To demonstrate the problem, compile both samples and enter the debugger,
setting a breakpoint on 'main'.

In the first sample, with GC, the debugger stops on line 3 "let s2 = s" which
is incorrect, because line 2 has not executed yet.

In the second sample, without GC, the debugger stops on the line 2 "var s =
getString()", which 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  Sat Feb 19 19:28:55 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 19 Feb 2011 19:28:55 -0600 (CST)
Subject: [LLVMbugs] [Bug 9271] New: dependent decltype in parameter of
 template function causes name mangling crash
Message-ID: <bug-9271-206@http.llvm.org/bugs/>

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

           Summary: dependent decltype in parameter of template function
                    causes name mangling crash
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++0x
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: richard-llvm at metafoo.co.uk
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


This code crashes in name mangling:

template<typename T> void f(T &&a, decltype(a) b);
int a;
int main() { f(a, a); }

The crash is caused by an infinite recursion: mangling the function name
f<int&> requires mangling the parameter types of the base template, and
mangling the type of b requires mangling the decltype expression, which
requires mangling a reference to f's parameter a, which erroneously requires
mangling the function name f<int&>.

The Itanium C++ ABI requires this to be mangled as:

_Z1fIRiE    f<int&>
v           void (
OT_         template-param-0 &&, 
Dtfp_       decltype(function-param-0)
E           )

It seems that clang's mangler doesn't know about the <function-param> "fp"
mangling.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 19 21:29:13 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 19 Feb 2011 21:29:13 -0600 (CST)
Subject: [LLVMbugs] [Bug 9060] Late-specified return type accepted for
 parenthesized declarator
In-Reply-To: <bug-9060-206@http.llvm.org/bugs/>
References: <bug-9060-206@http.llvm.org/bugs/>
Message-ID: <20110220032914.013B02A6C12C@llvm.org>

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

Richard Smith <richard-llvm at metafoo.co.uk> changed:

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

--- Comment #3 from Richard Smith <richard-llvm at metafoo.co.uk> 2011-02-19 21:29:13 CST ---
Fixed in r126069.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 19 21:29:25 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 19 Feb 2011 21:29:25 -0600 (CST)
Subject: [LLVMbugs] [Bug 9132] clang accepts declarators other than a
 literal 'auto' as the return type of a function with a trailing-return-type
In-Reply-To: <bug-9132-206@http.llvm.org/bugs/>
References: <bug-9132-206@http.llvm.org/bugs/>
Message-ID: <20110220032925.BB9182A6C12C@llvm.org>

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

Richard Smith <richard-llvm at metafoo.co.uk> 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  Sat Feb 19 22:13:18 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 19 Feb 2011 22:13:18 -0600 (CST)
Subject: [LLVMbugs] [Bug 9272] New: Clang shouldn't complain that C file is
 supplied in C++ mode when dependencies are parsed
Message-ID: <bug-9272-206@http.llvm.org/bugs/>

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

           Summary: Clang shouldn't complain that C file is supplied in
                    C++ mode when dependencies are parsed
           Product: clang
           Version: trunk
          Platform: Other
        OS/Version: FreeBSD
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: yuri at tsoft.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


When I run command like this:
clang++ -M file1.c file2.C
I get this warning:
clang: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is
deprecated

Such warning should be disabled in dependency parsing mode (-M). This is
because such operation doesn't depend on C/C++ differences and its very
convenient to make just one call in a mixed C/C++ project instead of calling it
once for all C files and once for all C++ files.

rev.126022

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 19 23:05:06 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 19 Feb 2011 23:05:06 -0600 (CST)
Subject: [LLVMbugs] [Bug 9239] clang trunk - fatal error: error in backend:
 Cannot select: 0x106918d10: v2f64 = X86ISD::MOVLPD 0x10698c910,
 0x1068fd410 [ID=58]
In-Reply-To: <bug-9239-206@http.llvm.org/bugs/>
References: <bug-9239-206@http.llvm.org/bugs/>
Message-ID: <20110220050506.61EBE2A6C12C@llvm.org>

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

Eric Christopher <echristo at gmail.com> changed:

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

--- Comment #12 from Eric Christopher <echristo at gmail.com> 2011-02-19 23:05:05 CST ---
Fixed thusly:

[issola:~/sources/llvm] echristo% svn ci lib/Target/X86/
Sending        lib/Target/X86/X86ISelLowering.cpp
Transmitting file data .
Committed revision 126072.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 20 06:21:19 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 20 Feb 2011 06:21:19 -0600 (CST)
Subject: [LLVMbugs] [Bug 7299] failed assertion while building several SPEC
 CPU2000 Fortran benchmarks
In-Reply-To: <bug-7299-206@http.llvm.org/bugs/>
References: <bug-7299-206@http.llvm.org/bugs/>
Message-ID: <20110220122119.519C32A6C12D@llvm.org>

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

Duncan Sands <baldrick at free.fr> changed:

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

--- Comment #7 from Duncan Sands <baldrick at free.fr> 2011-02-20 06:21:18 CST ---
Fixed here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20110214/116821.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 Feb 20 06:32:55 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 20 Feb 2011 06:32:55 -0600 (CST)
Subject: [LLVMbugs] [Bug 8891] Early phases of backend recompute dominators
	too often
In-Reply-To: <bug-8891-206@http.llvm.org/bugs/>
References: <bug-8891-206@http.llvm.org/bugs/>
Message-ID: <20110220123256.1F7942A6C12C@llvm.org>

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

Cameron Zwarich <zwarich at apple.com> changed:

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

--- Comment #2 from Cameron Zwarich <zwarich at apple.com> 2011-02-20 06:32:55 CST ---
This was fixed in r123064.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 20 07:39:14 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 20 Feb 2011 07:39:14 -0600 (CST)
Subject: [LLVMbugs] [Bug 9267] vector ZExt code generation bug
In-Reply-To: <bug-9267-206@http.llvm.org/bugs/>
References: <bug-9267-206@http.llvm.org/bugs/>
Message-ID: <20110220133914.AA8962A6C12C@llvm.org>

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

Nadav Rotem <nadav.rotem at intel.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 Feb 20 12:33:26 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 20 Feb 2011 12:33:26 -0600 (CST)
Subject: [LLVMbugs] [Bug 9272] Clang shouldn't complain that C file is
 supplied in C++ mode when dependencies are parsed
In-Reply-To: <bug-9272-206@http.llvm.org/bugs/>
References: <bug-9272-206@http.llvm.org/bugs/>
Message-ID: <20110220183326.AA1302A6C124@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #2 from Chris Lattner <clattner at apple.com> 2011-02-20 12:33:26 CST ---
Strictly speaking, whether something is parsed as c or c++ *can* change what
files get #included, because different macros are set, and macros can affect
#includes.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 20 13:20:03 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 20 Feb 2011 13:20:03 -0600 (CST)
Subject: [LLVMbugs] [Bug 7505] Getting lvalue to function template
 specialization always takes target type into account
In-Reply-To: <bug-7505-206@http.llvm.org/bugs/>
References: <bug-7505-206@http.llvm.org/bugs/>
Message-ID: <20110220192003.0C1F82A6C12C@llvm.org>

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

Faisal Vali <faisalv at yahoo.com> changed:

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

--- Comment #13 from Faisal Vali <faisalv at yahoo.com> 2011-02-20 13:20:01 CST ---
Resolved and committed as revision r126048.
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20110214/039069.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 Feb 20 14:22:15 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 20 Feb 2011 14:22:15 -0600 (CST)
Subject: [LLVMbugs] [Bug 9245] Missing support for labels in .org statements
In-Reply-To: <bug-9245-206@http.llvm.org/bugs/>
References: <bug-9245-206@http.llvm.org/bugs/>
Message-ID: <20110220202215.A01532A6C12E@llvm.org>

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

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

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

--- Comment #3 from Rafael ?vila de Esp?ndola <rafael.espindola at gmail.com> 2011-02-20 14:22:15 CST ---
Fixed in 126091. Please open another bug if you find fancier .org directives in
use.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 20 17:45:33 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 20 Feb 2011 17:45:33 -0600 (CST)
Subject: [LLVMbugs] [Bug 9273] New: dependent operator name in template
 function argument type crashes clang
Message-ID: <bug-9273-206@http.llvm.org/bugs/>

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

           Summary: dependent operator name in template function argument
                    type crashes clang
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++0x
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: richard-llvm at metafoo.co.uk
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


This causes clang to segfault:

template<typename T> void operator_(decltype(operator T)) {}
template void operator_<int>(int);

The crash is here:

#0  0x00000000009d29fc in clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformNestedNameSpecifier(clang::NestedNameSpecifier*,
clang::SourceRange, clang::QualType, clang::NamedDecl*) ()
#1  0x00000000009d5181 in clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformDependentScopeDeclRefExpr(clang::DependentScopeDeclRefExpr*)
()
#2  0x00000000009cbd05 in clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformExpr(clang::Expr*) ()
#3  0x00000000009cdc97 in clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformDecltypeType(clang::TypeLocBuilder&,
clang::DecltypeTypeLoc) ()
#4  0x00000000009c38bd in clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformType(clang::TypeLocBuilder&,
clang::TypeLoc) ()
#5  0x00000000009c46c0 in clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformType(clang::TypeSourceInfo*) ()
#6  0x00000000009c4dc2 in clang::Sema::SubstType(clang::TypeSourceInfo*,
clang::MultiLevelTemplateArgumentList const&, clang::SourceLocation,
clang::DeclarationName) ()
#7  0x00000000009c9833 in clang::Sema::SubstParmVarDecl(clang::ParmVarDecl*,
clang::MultiLevelTemplateArgumentList const&, llvm::Optional<unsigned int>) ()
#8  0x00000000009ca45e in clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformFunctionTypeParams(clang::SourceLocation,
clang::ParmVarDecl**, unsigned int, clang::QualType const*,
llvm::SmallVectorImpl<clang::QualType>&,
llvm::SmallVectorImpl<clang::ParmVarDecl*>*) ()

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 20 18:09:49 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 20 Feb 2011 18:09:49 -0600 (CST)
Subject: [LLVMbugs] [Bug 8486] -Wformat and -Wformat-security should be
	independent
In-Reply-To: <bug-8486-206@http.llvm.org/bugs/>
References: <bug-8486-206@http.llvm.org/bugs/>
Message-ID: <20110221000949.3697B2A6C124@llvm.org>

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

Chandler Carruth <chandlerc at gmail.com> changed:

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

--- Comment #1 from Chandler Carruth <chandlerc at gmail.com> 2011-02-20 18:09:48 CST ---
Fixed in r126096.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 20 19:26:04 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 20 Feb 2011 19:26:04 -0600 (CST)
Subject: [LLVMbugs] [Bug 7726] Invalid codegen for "Conditionals with
 Omitted Operands" (?:) expression in c++
In-Reply-To: <bug-7726-206@http.llvm.org/bugs/>
References: <bug-7726-206@http.llvm.org/bugs/>
Message-ID: <20110221012604.6F6842A6C130@llvm.org>

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

John McCall <rjmccall at apple.com> changed:

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

--- Comment #6 from John McCall <rjmccall at apple.com> 2011-02-20 19:26:03 CST ---
Between Fariborz's work and mine, this feature is done;  if there are remaining
cases, 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  Sun Feb 20 19:29:20 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 20 Feb 2011 19:29:20 -0600 (CST)
Subject: [LLVMbugs] [Bug 9274] New: Add opteron-sse3,
 athlon64-sse3 and k8-sse3 cpu-types for -march=/-mtune= gcc options.
Message-ID: <bug-9274-206@http.llvm.org/bugs/>

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

           Summary: Add opteron-sse3, athlon64-sse3 and k8-sse3 cpu-types
                    for -march=/-mtune= gcc options.
           Product: tools
           Version: trunk
          Platform: Other
        OS/Version: FreeBSD
            Status: NEW
          Severity: normal
          Priority: P
         Component: llvm-gcc
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: giffunip at tutopia.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=6189)
 --> (http://llvm.org/bugs/attachment.cgi?id=6189)
Backported (GPL2) patch to add some sse3 types

>From the FreeBSD log that served as the base for this Bug report:

Backport svn r124339 from gcc 4.3 and add opteron-sse3, athlon64-sse3
and k8-sse3 cpu-types for -march=/-mtune= gcc options.
These new cpu-types include the SSE3 instruction set that is supported
by all newer AMD Athlon 64 and Opteron processors.
All three cpu-types are supported by clang and all gcc versions
starting with 4.3 SVN rev 124339 (at that time GPLv2 licensed).

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 20 19:50:30 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 20 Feb 2011 19:50:30 -0600 (CST)
Subject: [LLVMbugs] [Bug 9275] New: Segmentation fault in Python example
 'cindex-includes.py'
Message-ID: <bug-9275-206@http.llvm.org/bugs/>

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

           Summary: Segmentation fault in Python example
                    'cindex-includes.py'
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Static Analyzer
        AssignedTo: kremenek at apple.com
        ReportedBy: colgur at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=6192)
 --> (http://llvm.org/bugs/attachment.cgi?id=6192)
I/O and back-trace related to the problem

Hi,
The attachment includes the following:

1. 'cindex-includes-input.h': The file provided to both 'c-index-test' and
'cindex-includes.py'
2. 'cindex-includes.output': Console log containing GDB invocation including
back-trace
3. 'c-index-test.output': Console log containing default output from
corresponding (?) invocation of 'c-index-test'

Are you able to reproduce? Is this an installation problem? My build is current
as of yesterday (Feb. 19).

It's not in the trace but the environment includes a PYTHONPATH setting
corresponding to the '$(llvm-config --src-root)/tools/clang/bindings/python'.

Thanks,
Chad

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 20 21:33:44 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 20 Feb 2011 21:33:44 -0600 (CST)
Subject: [LLVMbugs] [Bug 9276] New: Checking declaration with multiple
 "auto"-declarators with one type-dependent initializer
Message-ID: <bug-9276-206@http.llvm.org/bugs/>

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

           Summary: Checking declaration with multiple "auto"-declarators
                    with one type-dependent initializer
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++0x
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: schaub.johannes at googlemail.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


I stumbled over the following code during testing

template<typename T>
void f() {
  auto i = T(), j = 0;
}

int main() {
  f<long>();
  f<int>();
}

This code is ill-formed in the first instantiation, but the current
clang-with-auto does not reject it. Another question is what happens with the
second call.

We can compare the type deduced by "i" with the type deduced by "j" immediately
during parsing time, at which time "i" was deduced to type "T" and j to "int".
The two variable-types differ when declared and we raise a diagnostic. But we
can also wait until instantiation like done with so many other constructs,
because one type is dependent, and then compare the types. At that time, the
type of i and j are both "int". 

I think both ways are reasonable. GCC does it the first way, and says both
calls are ill-formed ("inconsistent deduction for 'auto': 'T' and then 'int'").
Don't know what the correct way to handle this is. 

I'm going to trust Doug who said I should make a PR so this can be fixed to
make the first one ill-formed and the second one working by comparing types at
instantiation 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  Sun Feb 20 23:28:53 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 20 Feb 2011 23:28:53 -0600 (CST)
Subject: [LLVMbugs] [Bug 9277] New: Clang generates duplicated Win32 APIs
 definitions, causing linking error
Message-ID: <bug-9277-206@http.llvm.org/bugs/>

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

           Summary: Clang generates duplicated Win32 APIs definitions,
                    causing linking error
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Windows NT
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: art.oriented at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=6194)
 --> (http://llvm.org/bugs/attachment.cgi?id=6194)
An example of the bitcode of a.c

I'm using clang on Windows. This bug can be reproduced by the following steps:
(1) Make two files: say a.c and b.c.
(2) Both of the files include <windows.h>
(3) Both files call a simple Win32 API such as GetTickCount();
(4) Try to compile (w/o optimizations), then we will get a bunch of duplication
linking error.

==========
error LNK2005: _Int64ShllMod32 at 12 already defined in cc-000000.o
error LNK2005: _Int64ShraMod32 at 12 already defined in cc-000000.o
error LNK2005: _Int64ShrlMod32 at 12 already defined in cc-000000.o
error LNK2005: _InterlockedBitTestAndSet already defined in cc-000000.o
error LNK2005: _InterlockedBitTestAndReset already defined in cc-000000.o
error LNK2005: _InterlockedBitTestAndComplement already defined in cc-000000.o
error LNK2005: _MemoryBarrier already defined in cc-000000.o
error LNK2005: _ReadPMC already defined in cc-000000.o
error LNK2005: _ReadTimeStampCounter already defined in cc-000000.o
error LNK2005: _DbgRaiseAssertionFailure already defined in cc-000000.o
error LNK2005: _HEAP_MAKE_TAG_FLAGS already defined in cc-000000.o
error LNK2005: _RtlSecureZeroMemory already defined in cc-000000.o
error LNK2005: _TpInitializeCallbackEnviron already defined in cc-000000.o
error LNK2005: _TpSetCallbackThreadpool already defined in cc-000000.o
error LNK2005: _TpSetCallbackCleanupGroup already defined in cc-000000.o
error LNK2005: _TpSetCallbackActivationContext already defined in cc-000000.o
error LNK2005: _TpSetCallbackNoActivationContext already defined in cc-000000.o
error LNK2005: _TpSetCallbackLongFunction already defined in cc-000000.o
error LNK2005: _TpSetCallbackRaceWithDll already defined in cc-000000.o
error LNK2005: _TpSetCallbackFinalizationCallback already defined in
cc-000000.o
error LNK2005: _TpSetCallbackPriority already defined in cc-000000.o
error LNK2005: _TpSetCallbackPersistent already defined in cc-000000.o
error LNK2005: _TpDestroyCallbackEnviron already defined in cc-000000.o
error LNK2005: _InterlockedAnd64 already defined in cc-000000.o
error LNK2005: _InterlockedOr64 already defined in cc-000000.o
error LNK2005: _InterlockedXor64 already defined in cc-000000.o
error LNK2005: _InterlockedIncrement64 already defined in cc-000000.o
error LNK2005: _InterlockedDecrement64 already defined in cc-000000.o
error LNK2005: _InterlockedExchange64 already defined in cc-000000.o
error LNK2005: _InterlockedExchangeAdd64 already defined in cc-000000.o
error LNK2005: _InitializeThreadpoolEnvironment already defined in cc-000000.o
error LNK2005: _SetThreadpoolCallbackPool already defined in cc-000000.o
error LNK2005: _SetThreadpoolCallbackCleanupGroup already defined in
cc-000000.o
error LNK2005: _SetThreadpoolCallbackRunsLong already defined in cc-000000.o
error LNK2005: _SetThreadpoolCallbackLibrary already defined in cc-000000.o
error LNK2005: _SetThreadpoolCallbackPriority already defined in cc-000000.o
error LNK2005: _SetThreadpoolCallbackPersistent already defined in cc-000000.o
error LNK2005: _DestroyThreadpoolEnvironment already defined in cc-000000.o
error LNK2005: _HRESULT_FROM_WIN32 already defined in cc-000000.o
==========

(Both MSVC's link.exe and gcc linker generate the errors. So, it's the problem
of the front end.)

I checked how the bitcode was generated by clang when <windows.h> is included.
Then, each bit code contains a number of Win32 API's definitions (while many of
them are inline hints). For example:

======== 
define x86_stdcallcc i64 @Int64ShraMod32(i64 %Value, i32 %ShiftCount) nounwind
inlinehint {
  %1 = alloca i64, align 8
  %2 = alloca i64, align 8
  %3 = alloca i32, align 4
  store i64 %Value, i64* %2, align 8
  call void @llvm.dbg.declare(metadata !{i64* %2}, metadata !97), !dbg !98
  store i32 %ShiftCount, i32* %3, align 4
  call void @llvm.dbg.declare(metadata !{i32* %3}, metadata !99), !dbg !100
  call void asm sideeffect "/*FIXME: not done*/",
"~{dirflag},~{fpsr},~{flags}"() nounwind, !dbg !101, !srcloc !95
  %4 = load i64* %1, !dbg !103
  ret i64 %4, !dbg !103
=======

These definitions exist in every object files that use <windows.h>, resulting
in duplication linking errors.

My current workaround is killing these functions' definition via a module pass
where just call Function::deleteBody().

I don't have deep knowledge of front end, so I can't figure it out the reason
further.


I'm attaching the bitcode of a simple file:
=========================
// a.c
#include <windows.h>

unsigned int foo()
{
  return GetTickCount();
}
=========================

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 20 23:58:39 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 20 Feb 2011 23:58:39 -0600 (CST)
Subject: [LLVMbugs] [Bug 6275] X86FastISel(llc -O0) does not handle calling
 dllimport functions properly
In-Reply-To: <bug-6275-206@http.llvm.org/bugs/>
References: <bug-6275-206@http.llvm.org/bugs/>
Message-ID: <20110221055839.3F56A2A6C124@llvm.org>

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

NAKAMURA Takumi <geek4civic at gmail.com> changed:

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

--- Comment #9 from NAKAMURA Takumi <geek4civic at gmail.com> 2011-02-20 23:58:38 CST ---
Fixed in r126110.

        .def     _bar;
        .scl    2;
        .type   32;
        .endef
        .text
        .globl  _bar
        .align  16, 0x90
_bar:                                   # @bar
# BB#0:                                 # %entry
        pushl   %eax
        movl    %esp, %eax
        movl    $0, (%eax)
        movl    __imp__foo, %eax
        calll   *%eax
        popl    %eax
        ret

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 21 00:32:35 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 21 Feb 2011 00:32:35 -0600 (CST)
Subject: [LLVMbugs] [Bug 9168] Wrong source location for CXXMemberCallExpr
In-Reply-To: <bug-9168-206@http.llvm.org/bugs/>
References: <bug-9168-206@http.llvm.org/bugs/>
Message-ID: <20110221063235.2AD5D2A6C12D@llvm.org>

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

John McCall <rjmccall at apple.com> changed:

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

--- Comment #3 from John McCall <rjmccall at apple.com> 2011-02-21 00:32:34 CST ---
Well, I "revirtualized" a bit in r126114.  Alex, could you verify whether that
helps, and if not, could you tell us specifically what static type you're
calling getSourceRange() on?

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 21 00:54:25 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 21 Feb 2011 00:54:25 -0600 (CST)
Subject: [LLVMbugs] [Bug 9278] New: Allows "typedef auto".
Message-ID: <bug-9278-206@http.llvm.org/bugs/>

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

           Summary: Allows "typedef auto".
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++0x
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: schaub.johannes at googlemail.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


Clang incorrectly allows to "typedef" the auto type specifier, which makes it
crash later on.

int main() {
  typedef auto auto_type;
  auto_type t = 0;
}

It crashes on the use of "auto_type", whereas it should have given a diagnostic
at the typedef declaration already. 

0  clang 0x09237f98
Stack dump:
0.      Program arguments: [lots of stuff] main1.cpp 
1.      <eof> parser at end of file
2.      main1.cpp:2:5: LLVM IR generation of declaration 'main'
3.      main1.cpp:2:5: Generating code for declaration 'main'
4.      main1.cpp:2:12: LLVM IR generation of compound statement ('{}')
clang: error: unable to execute command: Segmentation fault
clang: error: clang frontend command failed due to signal 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 Feb 21 03:12:24 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 21 Feb 2011 03:12:24 -0600 (CST)
Subject: [LLVMbugs] [Bug 9279] New: Macro expansion stack trace seriously
 broken with function-style macros
Message-ID: <bug-9279-206@http.llvm.org/bugs/>

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

           Summary: Macro expansion stack trace seriously broken with
                    function-style macros
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: chandlerc at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Pretty simple examples like:
% cat t.cc
#define M1(x) int arr[x]
#define M2(x) M1(x)
#define M3(x) M2(x)

M3(-1);

Lead to horrible diagnostics like:
% ./bin/clang++ -fsyntax-only t.cc
t.cc:5:1: error: 'arr' declared as an array with a negative size
M3(-1);
^~~~~~
t.cc:3:15: note: instantiated from:
#define M3(x) M2(x)
              ^
t.cc:2:15: note: instantiated from:
#define M2(x) M1(x)
              ^
t.cc:5:1: note: instantiated from:
M3(-1);
^  ~~
t.cc:3:15: note: instantiated from:
#define M3(x) M2(x)
              ^
t.cc:5:1: note: instantiated from:
M3(-1);
^  ~~
t.cc:5:4: note: instantiated from:
M3(-1);
   ^~
1 error generated.


Whereas plain macros yield a much nicer diagnostic:
% cat t2.cc 
#define M1 int arr[-
#define M2 M1
#define M3 M2

M3 1];

% ./bin/clang++ -fsyntax-only t2.cc
t2.cc:5:1: error: 'arr' declared as an array with a negative size
M3 1];
^~~~
t2.cc:3:12: note: instantiated from:
#define M3 M2
~~~~~~~~~~~^~
t2.cc:2:12: note: instantiated from:
#define M2 M1
~~~~~~~~~~~^~
t2.cc:1:20: note: instantiated from:
#define M1 int arr[-
                   ^
1 error generated.


There are a couple of distinct symptoms here, but likely they stem from the
same core issue:

- We generate a stack for each note in the original stack, making the total
diagnostic far longer than necessary.
- We don't ever show the bottom of the stack
- The source ranges for the secondary stacks are superior to those of the
initial stack

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 21 11:31:16 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 21 Feb 2011 11:31:16 -0600 (CST)
Subject: [LLVMbugs] [Bug 8541] Clang miscompiles libgcc's unwind-dw2.c
In-Reply-To: <bug-8541-206@http.llvm.org/bugs/>
References: <bug-8541-206@http.llvm.org/bugs/>
Message-ID: <20110221173116.CDD852A6C12E@llvm.org>

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

Duncan Sands <baldrick at free.fr> changed:

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

--- Comment #14 from Duncan Sands <baldrick at free.fr> 2011-02-21 11:31:16 CST ---
Reported as working with recent 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 Feb 21 12:23:13 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 21 Feb 2011 12:23:13 -0600 (CST)
Subject: [LLVMbugs] [Bug 9280] New: Provide better diagnostics for invalid
 inline asm constraints.
Message-ID: <bug-9280-206@http.llvm.org/bugs/>

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

           Summary: Provide better diagnostics for invalid inline asm
                    constraints.
           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: stoklund at 2pi.dk
                CC: llvmbugs at cs.uiuc.edu


PR9252 has this inline assembly:

void f(unsigned x) {
    asm volatile ("hello" : "+a"(x) : "a"(x));
}

GCC provides this diagnostic:

$ gcc small.c
small.c: In function ?f?:
small.c:2: error: can't find a register in class ?AREG? while reloading ?asm?
small.c:2: error: ?asm? operand has impossible constraints

Clang / LLVM says:

$ clang small.c
Assertion failed: (i == DstIdx || !mi->getOperand(i).isReg() ||
mi->getOperand(i).getReg() != regA), function runOnMachineFunction, file
/Volumes/Data/g/llvm/lib/CodeGen/TwoAddressInstructionPass.cpp, line 1140.

This type of error is probably too hard for the frontend to detect, but the
backend should give a better error message.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 21 12:26:13 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 21 Feb 2011 12:26:13 -0600 (CST)
Subject: [LLVMbugs] [Bug 9252] [Linux Kernel]
 TwoAddressInstructionPass.cpp:1138: virtual
 bool<unnamed>::TwoAddressInstructionPass::runOnMachineFunction(llvm::MachineFunction&):
 Assertion `i == DstIdx || !mi->getOperand(i).isReg() ||
 mi->getOperand(i).getReg() != regA' failed
In-Reply-To: <bug-9252-206@http.llvm.org/bugs/>
References: <bug-9252-206@http.llvm.org/bugs/>
Message-ID: <20110221182613.DCBD22A6C12E@llvm.org>

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

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

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

--- Comment #6 from Jakob Stoklund Olesen <stoklund at 2pi.dk> 2011-02-21 12:26:13 CST ---
I filed PR9280 to track the bad diagnostics.

Closing this bug, the source code is invalid.

Instead of 

    asm volatile ("hello" : "+a"(x) : "a"(x));

Simply use:

    asm volatile ("hello" : "+a"(x));

The "+a"(x) constraint both reads and writes the variable.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 21 12:44:58 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 21 Feb 2011 12:44:58 -0600 (CST)
Subject: [LLVMbugs] [Bug 9281] New: Relocatable PCH support broken
Message-ID: <bug-9281-206@http.llvm.org/bugs/>

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

           Summary: Relocatable PCH support broken
           Product: clang
           Version: 2.8
          Platform: PC
        OS/Version: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: alistair.low at fusemail.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=6198)
 --> (http://llvm.org/bugs/attachment.cgi?id=6198)
Patch to clang.

I tried to create a relocatable PCH as part of a project built on top of clang
but there were some problems - The PCH would always contain absolute paths
instead of relative ones, so it would fail when we tried to use it later. 

After some debugging, I noticed that the PCHGenerator constructor takes a
string pointer isysroot that is deleted before the PCHGenerator uses it (as a
pointer to a local variable is passed in), and thus a later comparison using it
fails. The Path::makeAbsolute() function in LLVM also fails to flip the back
slashes, which also breaks the same comparison.

The details are a bit sketchy as I worked on this a few weeks ago but didn't
get around to filing a bug until now. I have attached the patch that we made to
fix it for us though.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 21 15:06:41 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 21 Feb 2011 15:06:41 -0600 (CST)
Subject: [LLVMbugs] [Bug 8945] Support for -cxx-isystem
In-Reply-To: <bug-8945-206@http.llvm.org/bugs/>
References: <bug-8945-206@http.llvm.org/bugs/>
Message-ID: <20110221210641.3FA5A2A6C12E@llvm.org>

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

J?rg Sonnenberger <joerg at NetBSD.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  Mon Feb 21 15:51:16 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 21 Feb 2011 15:51:16 -0600 (CST)
Subject: [LLVMbugs] [Bug 9282] New: [C++] False positive about garbage value
 with structs.
Message-ID: <bug-9282-206@http.llvm.org/bugs/>

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

           Summary: [C++] False positive about garbage value with structs.
           Product: clang
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Static Analyzer
        AssignedTo: kremenek at apple.com
        ReportedBy: devlists at shadowlab.org
                CC: llvmbugs at cs.uiuc.edu


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

When a struct is initialized using a function, the analyzer does not detect
that it has been initialized and warns about garbage value.

------------- struct.cpp

typedef struct CGSize { float width; float height; } CGSize;

extern CGSize CGSizeMake(float w, float h);

float test() {
    CGSize s = CGSizeMake(0, 0);
    return s.width;
}

-------------
% clang++ --analyze struct.cpp
struct.cpp:8:2: warning: Undefined or garbage value returned to caller
        return s.width;
        ^      ~~~~~~~
1 warning 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 Feb 21 16:06:10 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 21 Feb 2011 16:06:10 -0600 (CST)
Subject: [LLVMbugs] [Bug 9283] New: [C++] False positive: uninitialized but
 passed as ref arg to a member function.
Message-ID: <bug-9283-206@http.llvm.org/bugs/>

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

           Summary: [C++] False positive: uninitialized but passed as ref
                    arg to a member function.
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Static Analyzer
        AssignedTo: kremenek at apple.com
        ReportedBy: devlists at shadowlab.org
                CC: llvmbugs at cs.uiuc.edu


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

When passing a variable as reference to a member function, clang does not
consider it is initialized and warn about garbage when using it afterward.
Note that it look like this false positive occurs only when the function is a
member function. When it is just declared outside of a class, clang does not
print any warning.

-------------- member-ref.cpp
class AtomStream {
public:
  bool ReadUInt32(int &value);
};

bool test(AtomStream& box) {  
  int type;
  box.ReadUInt32(type);
  return type != 0;
}

---------------
% clang++ --analyze member-ref.cpp
member-ref.cpp:10:15: warning: The left operand of '!=' is a garbage value
  return type != 0;
         ~~~~ ^
1 warning 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 Feb 21 16:09:52 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 21 Feb 2011 16:09:52 -0600 (CST)
Subject: [LLVMbugs] [Bug 8959] inline asm "0" constraint doesn't implicitly
	cast
In-Reply-To: <bug-8959-206@http.llvm.org/bugs/>
References: <bug-8959-206@http.llvm.org/bugs/>
Message-ID: <20110221220952.E51B92A6C12F@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #2 from Chris Lattner <clattner at apple.com> 2011-02-21 16:09:52 CST ---
Fixed in r126148

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 21 16:12:02 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 21 Feb 2011 16:12:02 -0600 (CST)
Subject: [LLVMbugs] [Bug 9269] [Linux Kernel] CFG.cpp:1558:
 clang::CFGBlock*<unnamed>::CFGBuilder::VisitForStmt(clang::ForStmt*):
 Assertion `Block == EntryConditionBlock || (Block == 0 &&
 EntryConditionBlock == Succ)' failed.
In-Reply-To: <bug-9269-206@http.llvm.org/bugs/>
References: <bug-9269-206@http.llvm.org/bugs/>
Message-ID: <20110221221202.8A1C52A6C124@llvm.org>

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

Ted Kremenek <kremenek at apple.com> changed:

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

--- Comment #3 from Ted Kremenek <kremenek at apple.com> 2011-02-21 16:12:01 CST ---
Fixed here: r126149

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 21 18:35:55 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 21 Feb 2011 18:35:55 -0600 (CST)
Subject: [LLVMbugs] [Bug 8935] [MC x86] does not know xgetbv instruction
In-Reply-To: <bug-8935-206@http.llvm.org/bugs/>
References: <bug-8935-206@http.llvm.org/bugs/>
Message-ID: <20110222003555.951BC2A6C12F@llvm.org>

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

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> 2011-02-21 18:35:55 CST ---
Fixed in 126165.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 21 18:46:17 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 21 Feb 2011 18:46:17 -0600 (CST)
Subject: [LLVMbugs] [Bug 9278] Allows "typedef auto".
In-Reply-To: <bug-9278-206@http.llvm.org/bugs/>
References: <bug-9278-206@http.llvm.org/bugs/>
Message-ID: <20110222004617.560102A6C12C@llvm.org>

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

Richard Smith <richard-llvm at metafoo.co.uk> changed:

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

--- Comment #5 from Richard Smith <richard-llvm at metafoo.co.uk> 2011-02-21 18:46:17 CST ---
The problems mentioned in comment#3 are fixed in r126166. I've added a note to
PR 9060 referencing that change 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 Feb 21 18:50:25 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 21 Feb 2011 18:50:25 -0600 (CST)
Subject: [LLVMbugs] [Bug 8738] C++'0x auto not implemented
In-Reply-To: <bug-8738-206@http.llvm.org/bugs/>
References: <bug-8738-206@http.llvm.org/bugs/>
Message-ID: <20110222005025.4EC2C2A6C12D@llvm.org>

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

Richard Smith <richard-llvm at metafoo.co.uk> changed:

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

--- Comment #3 from Richard Smith <richard-llvm at metafoo.co.uk> 2011-02-21 18:50:24 CST ---
Support for deduced auto was added in r126069.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 22 00:32:05 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 22 Feb 2011 00:32:05 -0600 (CST)
Subject: [LLVMbugs] [Bug 9284] New: -Warray-bounds too eager on
	variable-length arrays
Message-ID: <bug-9284-206@http.llvm.org/bugs/>

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

           Summary: -Warray-bounds too eager on variable-length arrays
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: nicolasweber at gmx.de
                CC: llvmbugs at cs.uiuc.edu


Input:

int f(bool b) {
  float totals[3 + (b ? 0 : 1)];
  if (!b)
    totals[3] = 0;
}

Warns about `totals[3]` being out-of-bounds, which is wrong.

This breaks the webkit 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  Tue Feb 22 00:55:02 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 22 Feb 2011 00:55:02 -0600 (CST)
Subject: [LLVMbugs] [Bug 9237] Assertion `KillOps[*SR] == KillOp && "invalid
 subreg kill flags"' failed
In-Reply-To: <bug-9237-206@http.llvm.org/bugs/>
References: <bug-9237-206@http.llvm.org/bugs/>
Message-ID: <20110222065502.05CEF2A6C12E@llvm.org>

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

Andrew Trick <atrick at apple.com> changed:

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

--- Comment #3 from Andrew Trick <atrick at apple.com> 2011-02-22 00:55:01 CST ---
Fixed in r126190. I needed to broaden the assertion in the VirtRegRewriter to
handle cases in which multiple operands of the same instruction kill the same
register. (they are both marked "kill").

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 22 02:28:22 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 22 Feb 2011 02:28:22 -0600 (CST)
Subject: [LLVMbugs] [Bug 9285] New: The LLVM LangRef is unclear regarding
 shift where the shift size is larger than the word size
Message-ID: <bug-9285-206@http.llvm.org/bugs/>

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

           Summary: The LLVM LangRef is unclear regarding shift where the
                    shift size is larger than the word size
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: MSP430
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: nadav.rotem at intel.com
                CC: llvmbugs at cs.uiuc.edu


Currently, in the x86 backend, scalar shift-left operations use the intel SHL
opcode which only looks at the LSB of the shift word. Starting LLVM 2.8, the
vector-SHL started using the PSLLD shift, which looks at the entire shift value
and zeros the result if the value is greater than the word size. 

The LLVM LangRef does not address the behavior of shift operations where the
shift size is larger than the word size.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 22 02:31:49 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 22 Feb 2011 02:31:49 -0600 (CST)
Subject: [LLVMbugs] [Bug 9285] The LLVM LangRef is unclear regarding shift
 where the shift size is larger than the word size
In-Reply-To: <bug-9285-206@http.llvm.org/bugs/>
References: <bug-9285-206@http.llvm.org/bugs/>
Message-ID: <20110222083149.9FE492A6C12D@llvm.org>

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

Nadav Rotem <nadav.rotem at intel.com> changed:

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

--- Comment #1 from Nadav Rotem <nadav.rotem at intel.com> 2011-02-22 02:31:49 CST ---
My mistake. It is defined.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 22 04:30:51 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 22 Feb 2011 04:30:51 -0600 (CST)
Subject: [LLVMbugs] [Bug 9286] New: Copy error on mingw32-make.exe install
Message-ID: <bug-9286-206@http.llvm.org/bugs/>

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

           Summary: Copy error on mingw32-make.exe install
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: a460844 at jnxjn.com
                CC: llvmbugs at cs.uiuc.edu


In install process on windows:
F:\soft\lang\LLVM\svn\build>mingw32-make.exe install
...
-- Up-to-date: C:/bin/LLVM/lib/libclangStaticAnalyzerCheckers.a
-- Up-to-date: C:/bin/LLVM/lib/libclangStaticAnalyzerFrontend.a
-- Up-to-date: C:/bin/LLVM/lib/liblibclang.dll.a
-- Up-to-date: C:/bin/LLVM/bin/clang.exe
Creating clang++ executable based on clang
Error copying file "clang" to "clang++".
...

Here is wrong file naming "C:\bin\CMake\bin\cmake.exe -E clang clang++".
The "C:\bin\CMake\bin\cmake.exe -E clang.exe clang++.exe" have to be placed for
example.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 22 05:57:07 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 22 Feb 2011 05:57:07 -0600 (CST)
Subject: [LLVMbugs] [Bug 9287] New: Assert when analyzing "ternary operator"
 without second operator
Message-ID: <bug-9287-206@http.llvm.org/bugs/>

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

           Summary: Assert when analyzing "ternary operator" without
                    second operator
           Product: clang
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Static Analyzer
        AssignedTo: kremenek at apple.com
        ReportedBy: devlists at shadowlab.org
                CC: llvmbugs at cs.uiuc.edu


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

clang crash when trying to analyze this reduced case:

-----
int test(int type) { return type ? : 0; }
-----

% clang --analyze ternary.c 
Assertion failed: (B->succ_size() == 2), function HandleBranch, file
/Volumes/MacPro/Projects/OpenSource/llvm/tools/clang/lib/StaticAnalyzer/Core/CoreEngine.cpp,
line 429.
0  clang             0x0000000100f200a2 PrintStackTrace(void*) + 34
1  clang             0x0000000100f205f9 SignalHandler(int) + 745
2  libSystem.B.dylib 0x00007fff82f6e67a _sigtramp + 26
3  libSystem.B.dylib 0x0000000102012d50 _sigtramp + 2131379952
4  clang             0x0000000100011a16 abort + 22
5  clang             0x00000001000119d8 __assert_rtn + 56
6  clang             0x0000000100526770
clang::ento::CoreEngine::HandleBlockExit(clang::CFGBlock const*,
clang::ento::ExplodedNode*) + 1776
7  clang             0x0000000100525d68
clang::ento::CoreEngine::HandlePostStmt(clang::CFGBlock const*, unsigned int,
clang::ento::ExplodedNode*) + 72
8  clang             0x0000000100525401
clang::ento::CoreEngine::ExecuteWorkList(clang::LocationContext const*,
unsigned int, clang::ento::GRState const*) + 481
9  clang             0x000000010049ff73 ActionObjCMemCheckerAux((anonymous
namespace)::AnalysisConsumer&, clang::ento::AnalysisManager&, clang::Decl*,
bool) + 1123
[?]
21 clang             0x000000000000002b start + 4294893883
Stack dump:
0.    Program arguments:
/Volumes/MacPro/Projects/OpenSource/llvm/release/Release+Asserts/bin/clang -cc1
-triple x86_64-apple-darwin10.0.0 -analyze -disable-free -main-file-name
ternary.c -analyzer-store=region -analyzer-opt-analyze-nested-blocks
-analyzer-checker=core -analyzer-checker=unix -analyzer-checker=macosx
-analyzer-check-objc-mem -analyzer-eagerly-assume -analyzer-output plist -w
-pic-level 1 -mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu core2
-target-linker-version 97.17 -resource-dir
/Volumes/MacPro/Projects/OpenSource/llvm/release/Release+Asserts/bin/../lib/clang/2.9
-ferror-limit 19 -fmessage-length 262 -stack-protector 1 -fblocks
-fdiagnostics-show-option -fcolor-diagnostics -o ternary.plist -x c ternary.c 
1.    <eof> parser at end of file
clang: error: unable to execute command: Illegal instruction
clang: error: clang frontend command failed due to signal 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 Feb 22 07:06:05 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 22 Feb 2011 07:06:05 -0600 (CST)
Subject: [LLVMbugs] [Bug 9286] [CMake][Win] Copy error to install
 "clang++.exe" on Windows hosts
In-Reply-To: <bug-9286-206@http.llvm.org/bugs/>
References: <bug-9286-206@http.llvm.org/bugs/>
Message-ID: <20110222130605.E31622A6C12C@llvm.org>

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

?scar Fuentes <ofv at wanadoo.es> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |ofv at wanadoo.es
         Resolution|                            |FIXED

--- Comment #2 from ?scar Fuentes <ofv at wanadoo.es> 2011-02-22 07:06:05 CST ---
Fixes in r126219.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 22 10:18:18 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 22 Feb 2011 10:18:18 -0600 (CST)
Subject: [LLVMbugs] [Bug 9288] New: false positive: division by zero
Message-ID: <bug-9288-206@http.llvm.org/bugs/>

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

           Summary: false positive: division by zero
           Product: clang
           Version: 2.8
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Static Analyzer
        AssignedTo: kremenek at apple.com
        ReportedBy: mkbosmans at gmail.com
                CC: llvmbugs at cs.uiuc.edu


In the following code, the division by zero cannot occur, because
pa_cvolume_valid checks for a->channels > 0.

89  pa_volume_t pa_cvolume_avg(const pa_cvolume *a) {
90        uint64_t sum = 0;
91        unsigned c;
92     
93        pa_assert(a);
94        pa_return_val_if_fail(pa_cvolume_valid(a), PA_VOLUME_MUTED);
95     
96        for (c = 0; c < a->channels; c++)
97            sum += a->values[c];
98     
99        sum /= a->channels;
100     
101        return (pa_volume_t) sum;
102    }

Full source code available at:
http://git.0pointer.de/?p=pulseaudio.git;a=blob;f=src/pulse/volume.c;hb=HEAD

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 22 10:25:49 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 22 Feb 2011 10:25:49 -0600 (CST)
Subject: [LLVMbugs] [Bug 9289] New: false positive: Assigned value is
 garbage or undefined
Message-ID: <bug-9289-206@http.llvm.org/bugs/>

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

           Summary: false positive: Assigned value is garbage or undefined
           Product: clang
           Version: 2.8
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Static Analyzer
        AssignedTo: kremenek at apple.com
        ReportedBy: mkbosmans at gmail.com
                CC: llvmbugs at cs.uiuc.edu


The following snippet illustrates what goes wrong:
e->is_float does not change, so both at line 479 and at line 501 the same
branch must be taken and the garbage assignment cannot occur.

472            float saved_f;
Variable 'saved_f' declared without an initial value
473            int32_t saved_i;
474            uint64_t saved_start_x;
...
479            if (e->is_float) {
Taking false branch
480                saved_f = i->start_y.f;
481                i->start_y.f = item_get_float(i, x);
482            } else {
483                saved_i = i->start_y.i;
484                i->start_y.i = item_get_int(i, x);
485            }
...
493            envelope_merge(e, v);
...
501            if (e->is_float)
Taking true branch
502                i->start_y.f = saved_f;
Assigned value is garbage or undefined
503            else
504                i->start_y.i = saved_i;

Full source code available at:
http://git.0pointer.de/?p=pulseaudio.git;a=blob;f=src/pulsecore/envelope.c;hb=HEAD
(e.g. in the pa_envelope_replace 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  Tue Feb 22 10:55:45 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 22 Feb 2011 10:55:45 -0600 (CST)
Subject: [LLVMbugs] [Bug 9172] Static variable in function scope
In-Reply-To: <bug-9172-206@http.llvm.org/bugs/>
References: <bug-9172-206@http.llvm.org/bugs/>
Message-ID: <20110222165545.7D3472A6C12D@llvm.org>

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

J?rg Sonnenberger <joerg at NetBSD.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 Feb 22 10:59:01 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 22 Feb 2011 10:59:01 -0600 (CST)
Subject: [LLVMbugs] [Bug 9290] New: Conditional jumps are encoded
	sub-optimally
Message-ID: <bug-9290-206@http.llvm.org/bugs/>

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

           Summary: Conditional jumps are encoded sub-optimally
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: X86
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: joerg at NetBSD.org
                CC: llvmbugs at cs.uiuc.edu


Consider the follow input fragment:

je 1f
1:

Expect result:
0x74 0x00

Current result:

0x0f 0x84 0x00 0x00 0x00 0x00

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 22 12:31:06 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 22 Feb 2011 12:31:06 -0600 (CST)
Subject: [LLVMbugs] [Bug 9261] [linux kernel] clang: error: array
 initializer must be an initializer list or string literal
In-Reply-To: <bug-9261-206@http.llvm.org/bugs/>
References: <bug-9261-206@http.llvm.org/bugs/>
Message-ID: <20110222183106.913F22A6C12D@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #4 from Douglas Gregor <dgregor at apple.com> 2011-02-22 12:31:05 CST ---
Implemented in Clang r126230.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 22 15:37:26 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 22 Feb 2011 15:37:26 -0600 (CST)
Subject: [LLVMbugs] [Bug 9291] New: MC assertion failure on .private_extern
 when producing ELF object code
Message-ID: <bug-9291-206@http.llvm.org/bugs/>

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

           Summary: MC assertion failure on .private_extern when producing
                    ELF object code
           Product: new-bugs
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Keywords: crash-on-invalid
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: thebeing+llvm at halbordnung.de
                CC: llvmbugs at cs.uiuc.edu


Hello,

I accidentally discovered that llvm-mc (r126241) does not fail nicely when it
tries to generate ELF object code and encounters the .private_extern assembler
directive (which, afaikt only works with Mach-O). The expected behaviour would
be to issue an error message that the directive is unsupported for ELF object
code, the actual behaviour is the following

llvm-mc: MCELFStreamer.cpp:276: virtual
void<unnamed>::MCELFStreamer::EmitSymbolAttribute(llvm::MCSymbol*,
llvm::MCSymbolAttr): Assertion `0 && "Invalid symbol attribute for ELF!"'
failed.
0  llvm-mc         0x0000000000b535df
1  llvm-mc         0x0000000000b55842
2  libpthread.so.0 0x00007fc8e5d82f60
3  libc.so.6       0x00007fc8e4e8d165 gsignal + 53
4  libc.so.6       0x00007fc8e4e8ff70 abort + 384
5  libc.so.6       0x00007fc8e4e862b1 __assert_fail + 241
6  llvm-mc         0x0000000000afcf22
7  llvm-mc         0x000000000079a3f6
8  llvm-mc         0x00000000007a0b22
9  llvm-mc         0x00000000007a0df1
10 llvm-mc         0x000000000040a489
11 llvm-mc         0x000000000040b108
12 libc.so.6       0x00007fc8e4e79c4d __libc_start_main + 253
13 llvm-mc         0x0000000000406b29
Stack dump:
0.      Program arguments: llvm-mc --filetype=obj private_extern.s

Attached is a test-case that demonstrates 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  Tue Feb 22 17:22:06 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 22 Feb 2011 17:22:06 -0600 (CST)
Subject: [LLVMbugs] [Bug 9247] Crash on invalid in
 clang::Sema::ActOnFinishCXXMemberSpecification
In-Reply-To: <bug-9247-206@http.llvm.org/bugs/>
References: <bug-9247-206@http.llvm.org/bugs/>
Message-ID: <20110222232206.A43652A6C12E@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #2 from Douglas Gregor <dgregor at apple.com> 2011-02-22 17:22:05 CST ---
Fixed in Clang r126262.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 22 18:38:13 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 22 Feb 2011 18:38:13 -0600 (CST)
Subject: [LLVMbugs] [Bug 9276] Checking declaration with multiple
 "auto"-declarators with one type-dependent initializer
In-Reply-To: <bug-9276-206@http.llvm.org/bugs/>
References: <bug-9276-206@http.llvm.org/bugs/>
Message-ID: <20110223003813.7F3542A6C12C@llvm.org>

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

Richard Smith <richard-llvm at metafoo.co.uk> changed:

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

--- Comment #3 from Richard Smith <richard-llvm at metafoo.co.uk> 2011-02-22 18:38:13 CST ---
Fixed in r126279.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 22 18:46:52 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 22 Feb 2011 18:46:52 -0600 (CST)
Subject: [LLVMbugs] [Bug 9191] Assertion
 `SrcType->getAs<EnumType>()->getDecl()->isScoped()' in C++0x code
In-Reply-To: <bug-9191-206@http.llvm.org/bugs/>
References: <bug-9191-206@http.llvm.org/bugs/>
Message-ID: <20110223004652.DBC5B2A6C12D@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #2 from Douglas Gregor <dgregor at apple.com> 2011-02-22 18:46:51 CST ---
I fixed this a few days ago.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 22 19:27:19 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 22 Feb 2011 19:27:19 -0600 (CST)
Subject: [LLVMbugs] [Bug 9292] New: [MC assembler] .globl does not emit
 symbol if unreferenced
Message-ID: <bug-9292-206@http.llvm.org/bugs/>

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

           Summary: [MC assembler] .globl does not emit symbol if
                    unreferenced
           Product: new-bugs
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: dimitry at andric.com
                CC: llvmbugs at cs.uiuc.edu


It looks like MC does not emit a global symbol into the destination
object file for a .globl directive, if the object is not referenced.

This is an unwanted optimization, since e.g. module loaders can depend
on specific symbols to always be available, so they use .globl to force
the linker to emit the symbol.

This substantially differs from GNU as's behaviour.  For example,
assemble the following sample file with GNU as and clang:

    .globl foo
    .globl bar
    mov %eax,bar

Running "readelf -s" over the object file that GNU as produces gives:

Symbol table '.symtab' contains 6 entries:
   Num:    Value  Size Type    Bind   Vis      Ndx Name
     0: 00000000     0 NOTYPE  LOCAL  DEFAULT  UND
     1: 00000000     0 SECTION LOCAL  DEFAULT    1
     2: 00000000     0 SECTION LOCAL  DEFAULT    3
     3: 00000000     0 SECTION LOCAL  DEFAULT    4
     4: 00000000     0 NOTYPE  GLOBAL DEFAULT  UND foo
     5: 00000000     0 NOTYPE  GLOBAL DEFAULT  UND bar

Running "readelf -s" over the object file that GNU as produces gives:

Symbol table '.symtab' contains 5 entries:
   Num:    Value  Size Type    Bind   Vis      Ndx Name
     0: 00000000     0 NOTYPE  LOCAL  DEFAULT  UND
     1: 00000000     0 SECTION LOCAL  DEFAULT    1
     2: 00000000     0 SECTION LOCAL  DEFAULT    2
     3: 00000000     0 SECTION LOCAL  DEFAULT    3
     4: 00000000     0 NOTYPE  GLOBAL DEFAULT  UND bar

MC should *not* remove the 'foo' symbol from the table 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  Tue Feb 22 19:55:43 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 22 Feb 2011 19:55:43 -0600 (CST)
Subject: [LLVMbugs] [Bug 9284] -Warray-bounds too eager in unreachable code
In-Reply-To: <bug-9284-206@http.llvm.org/bugs/>
References: <bug-9284-206@http.llvm.org/bugs/>
Message-ID: <20110223015543.4B0152A6C124@llvm.org>

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

Ted Kremenek <kremenek at apple.com> changed:

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

--- Comment #13 from Ted Kremenek <kremenek at apple.com> 2011-02-22 19:55:42 CST ---
I'm going to consider this issue resolved.  Please re-open if that is not the
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  Tue Feb 22 22:22:16 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 22 Feb 2011 22:22:16 -0600 (CST)
Subject: [LLVMbugs] [Bug 9293] New: [CMake][Clang] TARGET_TRIPLE is not set
 on clang standalone build
Message-ID: <bug-9293-206@http.llvm.org/bugs/>

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

           Summary: [CMake][Clang] TARGET_TRIPLE is not set on clang
                    standalone build
           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: geek4civic at gmail.com
                CC: llvmbugs at cs.uiuc.edu


It seems Clang standalone build does not run config-ix.

Clang tests rely on TARGET_TRIPLE to exclude some tests on certain hosts.
(eg. some tests are maked as "XFAIL: win32" and tests expect "*-win32" as
triplet.

FYI I am checking clang standalone build with setting CLANG_PATH_TO_LLVM_BUILD
to "Installed" LLVM.

Dirty workaround;

--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -51,6 +51,10 @@ if( CMAKE_SOURCE_DIR STREQUAL CMAKE_CURRENT_SOURCE_DIR )
   set( CMAKE_LIBRARY_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/lib )
   set( CMAKE_ARCHIVE_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/lib )

+  # FIXME: Do you need config-ix?
+  set(TARGET_TRIPLE "unknown-unknown-unknown" CACHE STRING
+    "Set manually for tests.")
+
   set( CLANG_BUILT_STANDALONE 1 )

   # Add dummy target

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 22 23:12:48 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 22 Feb 2011 23:12:48 -0600 (CST)
Subject: [LLVMbugs] [Bug 8183] "indirection of non-volatile null pointer"
 warning in dead code
In-Reply-To: <bug-8183-206@http.llvm.org/bugs/>
References: <bug-8183-206@http.llvm.org/bugs/>
Message-ID: <20110223051249.2169C2A6C12C@llvm.org>

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

Ted Kremenek <kremenek at apple.com> changed:

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

--- Comment #17 from Ted Kremenek <kremenek at apple.com> 2011-02-22 23:12:48 CST ---
(In reply to comment #16)
> (In reply to comment #15)
> > This warning is now suppressed for the trivial 'if' and '?:' cases where basic
> > reachability analysis on the CFG can prune can determine the code is dead:
> > 
> >   http://llvm.org/viewvc/llvm-project?view=rev&revision=126290
> > 
> > This should handle Jed's case.
> > 
> > This case is still not handled:
> > 
> >     #define U64Divide(dividend, divisor, remainder) (( (void)((remainder) &&
> > (*((UInt64*)(remainder)) = ((UInt64)(dividend) % (UInt64)(divisor)))),
> > ((UInt64)(dividend) / (UInt64)(divisor)) ))
> > 
> > This requires further finessing of the CFG for '&&'.
> 
> This issue remains because the CFG is not pruning the true branch in the case
> of a void* null pointer for the condition.  Here is a reduced test case:
> 
> $ cat test.m
> typedef unsigned long long UInt64;
> 
> void foo(UInt64 test)
> {
>   (void)((((void*)0)) && (*((UInt64*)(((void*)0))) = ((UInt64)((test)) %
> (UInt64)((1000000000)))));
> }
> 
> $ clang -fsyntax-only test.m
> 
> test.m:5:27: warning: indirection of non-volatile null pointer will be deleted,
> not trap
>   (void)((((void*)0)) && (*((UInt64*)(((void*)0))) = ((UInt64)((test)) %
> (UInt64)((1000000000)))));
>                           ^~~~~~~~~~~~~~~~~~~~~~~~
> /tmp/test.m:5:27: note: consider using __builtin_trap() or qualifying pointer
> with 'volatile'
> 
> 
> and the CFG:
> 
> 
>  [ B4 (ENTRY) ]
>     Predecessors (0):
>     Successors (1): B2
> 
>  [ B1 ]
>       1: (([B2.1])) && ([B3.1])
>       2: (void)([B1.1])
>     Predecessors (2): B3 B2
>     Successors (1): B0
> 
>  [ B2 ]
>       1: (void *)0
>       T: (([B2.1])) && ...
>     Predecessors (1): B4
>     Successors (2): B3 B1
> 
>  [ B3 ]
>       1: *((UInt64 *)(((void *)0))) = ((UInt64)((test)) %
> (UInt64)((1000000000)))
>     Predecessors (1): B2
>     Successors (1): B1
> 
>  [ B0 (EXIT) ]
>     Predecessors (1): B1
>     Successors (0):
> 
> Note that the CFG does prune branches for '&&'; for some reason it isn't
> working with the void*.

This case is now handled:

  r126305

Clang no longer reports warnings for HowLongTimer.m.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 23 05:30:02 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 23 Feb 2011 05:30:02 -0600 (CST)
Subject: [LLVMbugs] [Bug 9293] [CMake][Clang] TARGET_TRIPLE is not set on
 clang standalone build
In-Reply-To: <bug-9293-206@http.llvm.org/bugs/>
References: <bug-9293-206@http.llvm.org/bugs/>
Message-ID: <20110223113002.AD5742A6C12D@llvm.org>

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

?scar Fuentes <ofv at wanadoo.es> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |ofv at wanadoo.es
         Resolution|                            |FIXED

--- Comment #1 from ?scar Fuentes <ofv at wanadoo.es> 2011-02-23 05:30:02 CST ---
Fixed in r126302. TARGET_TRIPLE variable is defined in
$LLVM_BUILD_ROOT/share/cmake/modules/LLVM.cmake.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 23 07:21:46 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 23 Feb 2011 07:21:46 -0600 (CST)
Subject: [LLVMbugs] [Bug 9294] New: Objective-C: CodeGen failure when
 generating getters for properties marked "retain" (GNUstep runtime,
 fragile ABI)
Message-ID: <bug-9294-206@http.llvm.org/bugs/>

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

           Summary: Objective-C: CodeGen failure when generating getters
                    for properties marked "retain" (GNUstep runtime,
                    fragile ABI)
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Keywords: compile-fail
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: thebeing+llvm at halbordnung.de
                CC: llvmbugs at cs.uiuc.edu, csdavec at swan.ac.uk


Hello,

under some conditions, clang (r126310) does not correctly generate getters for
Objective-C properties that are marked with "retain". This happens when using
the GNUstep runtime without the new non-fragile ABI (i.e. when
-fobjc-nonfragile-abi is not specified). The machine is x86_64 Linux. A reduced
test-case is attached. The call trace is as follows:

clang: Instructions.cpp:196: 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.
0  clang           0x0000000001646a6f
1  clang           0x0000000001648cd2
2  libpthread.so.0 0x00007fd39dbf5f60
3  libc.so.6       0x00007fd39cd00165 gsignal + 53
4  libc.so.6       0x00007fd39cd02f70 abort + 384
5  libc.so.6       0x00007fd39ccf92b1 __assert_fail + 241
6  clang           0x0000000001578512 llvm::CallInst::init(llvm::Value*,
llvm::Value* const*, unsigned int) + 418
7  clang           0x0000000000793fe3
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*, llvm::Instruction**) + 1379
8  clang           0x0000000000803729
clang::CodeGen::CodeGenFunction::GenerateObjCGetter(clang::ObjCImplementationDecl*,
clang::ObjCPropertyImplDecl const*) + 1065
9  clang           0x000000000076cacf
clang::CodeGen::CodeGenModule::EmitObjCPropertyImplementations(clang::ObjCImplementationDecl
const*) + 959
10 clang           0x00000000007711b0
clang::CodeGen::CodeGenModule::EmitTopLevelDecl(clang::Decl*) + 624
11 clang           0x0000000000762914
12 clang           0x0000000000762301
clang::BackendConsumer::HandleTopLevelDecl(clang::DeclGroupRef) + 161
13 clang           0x00000000008849c5 clang::ParseAST(clang::Sema&, bool) + 165
14 clang           0x0000000000761814 clang::CodeGenAction::ExecuteAction() +
68
15 clang           0x0000000000645c1b
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 347
16 clang           0x000000000062090c
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1276
17 clang           0x0000000000618314 cc1_main(char const**, char const**, char
const*, void*) + 468
18 clang           0x000000000061f915 main + 4629
19 libc.so.6       0x00007fd39ccecc4d __libc_start_main + 253
20 clang           0x0000000000616a29
Stack dump:
0.      Program arguments: /usr/local/bin/clang -cc1 -triple
x86_64-unknown-linux-gnu -emit-obj -mrelax-all -disable-free -main-file-name
test.m -mrelocation-model static -mdisable-fp-elim -masm-verbose
-mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version
2.20.1 -momit-leaf-frame-pointer -resource-dir /usr/local/bin/../lib/clang/2.9
-I /usr/GNUstep/System/Library/Headers/gnu-gnu-gnu/ -I
/usr/GNUstep/System/Library/Headers/gnu-gnu-gnu/x86_64/linux-gnu -ferror-limit
19 -fmessage-length 142 -fgnu-runtime -fobjc-exceptions
-fdiagnostics-show-option -fcolor-diagnostics -o /tmp/user/5001/cc-IJ6QXo.o -x
objective-c test.m

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 23 07:25:14 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 23 Feb 2011 07:25:14 -0600 (CST)
Subject: [LLVMbugs] [Bug 9295] New: Support for "asm goto"
Message-ID: <bug-9295-206@http.llvm.org/bugs/>

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

           Summary: Support for "asm goto"
           Product: clang
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: dave at jikos.cz
                CC: llvmbugs at cs.uiuc.edu


http://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html (search for 'asm goto')

"As of GCC version 4.5, asm goto may be used to have the assembly jump to one
or more C labels. In this form, a fifth section after the clobber list contains
a list of all C labels to which the assembly may jump. Each label operand is
implicitly self-named. The asm is also assumed to fall through to the next
statement."

int frob(int x)
     {
       int y;
       asm goto ("frob %%r5, %1; jc %l[error]; mov (%2), %%r5"
                 : : "r"(x), "r"(&y) : "r5", "memory" : error);
       return y;
      error:
       return -1;
     }

Linux kernel has a compile-time option whether asm goto is compiler supported,
so this is not a blocker for it, but I'd like to know what's clang POV on 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  Wed Feb 23 08:06:17 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 23 Feb 2011 08:06:17 -0600 (CST)
Subject: [LLVMbugs] [Bug 9294] Objective-C: CodeGen failure when generating
 getters for properties marked "retain" (GNUstep runtime, fragile ABI)
In-Reply-To: <bug-9294-206@http.llvm.org/bugs/>
References: <bug-9294-206@http.llvm.org/bugs/>
Message-ID: <20110223140617.822222A6C124@llvm.org>

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

David Chisnall <csdavec at swan.ac.uk> changed:

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

--- Comment #4 from David Chisnall <csdavec at swan.ac.uk> 2011-02-23 08:06:17 CST ---
Should be fixed in r126312.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 23 08:54:02 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 23 Feb 2011 08:54:02 -0600 (CST)
Subject: [LLVMbugs] [Bug 9296] New: -Warray-bounds thinks 'true' is negative.
Message-ID: <bug-9296-206@http.llvm.org/bugs/>

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

           Summary: -Warray-bounds thinks 'true' is negative.
           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: fvbommel at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Compiling this (C++) code:
=====
int foo() {
    int array[2];
    return array[true];
}
=====
results in this warning:
=====
test.cpp:3:12: warning: array index of '-1' indexes before the beginning of the
      array [-Warray-bounds]
    return array[true];
           ^     ~~~~
test.cpp:2:5: note: array 'array' declared here
    int array[2];
    ^
1 warning generated.
=====

even though the actual array access is compiled to:
=====
  %arrayidx = getelementptr inbounds [2 x i32]* %array, i32 0, i64 1
  %tmp = load i32* %arrayidx
=====
(meaning 'true' is treated as unsigned '1', not signed '-1' when actually
compiling the code, but the other way around when generating this warning)

Note also that '(int)true' evaluates to 1, so clearly booleans are usually
treated as unsigned.


In other words, the warning seems to be nagging me about perfectly functional
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 Feb 23 10:56:17 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 23 Feb 2011 10:56:17 -0600 (CST)
Subject: [LLVMbugs] [Bug 9297] New: Bad movaps code emitted when string
 arrays exist in function scope, in binary linkage
Message-ID: <bug-9297-206@http.llvm.org/bugs/>

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

           Summary: Bad movaps code emitted when string arrays exist in
                    function scope, in binary linkage
           Product: clang
           Version: 2.8
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: morgon.kanter at gmail.com
                CC: llvmbugs at cs.uiuc.edu


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

clang is emitting code that works when linked as an ELF file, but does not work
when linked as a flat binary file. When an array of strings is placed in
function scope, it emits several "movaps" instructions -- even if this string
array is never referenced (see test case). When this array of strings is
removed, no movaps instructions are emitted.

This works fine when linking as an ELF file (ld -e main -o test_bad test_bad.o
-lc) -- everything is 16-byte aligned correctly for movaps. However, when
linked as a binary file (ld -e main --target=binary -o test_bad test_bad.o)*,
the emitted code is completely wrong:

 110:   0f 28 05 00 00 00 00    movaps 0x0(%rip),%xmm0        # 0x117
 117:   0f 29 41 20             movaps %xmm0,0x20(%rcx)
 11b:   0f 28 05 00 00 00 00    movaps 0x0(%rip),%xmm0        # 0x122
 122:   0f 29 41 10             movaps %xmm0,0x10(%rcx)
 126:   0f 28 05 00 00 00 00    movaps 0x0(%rip),%xmm0        # 0x12d
 12d:   0f 29 01                movaps %xmm0,(%rcx)

It's not touching the strings at this point, and the addressing for movaps is
not 16-byte aligned.

This may be a linker bug and not a clang bug. I'm not sure whose job it is to
do "the right thing".

* I know this code won't actually run even in the "correct" case, as it's not
linked with the appropriate start-up stuff. This was just meant to be
demonstrative of the issue -- it's appearing in a flat binary file part of a
larger project that does run. I'm not sure what commands to issue the linker to
add the _start function and other requirements to get an ELF file to run on
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 Feb 23 11:38:06 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 23 Feb 2011 11:38:06 -0600 (CST)
Subject: [LLVMbugs] [Bug 9298] New: Instruction does not dominate all uses!
Message-ID: <bug-9298-206@http.llvm.org/bugs/>

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

           Summary: Instruction does not dominate all uses!
           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


on X86_64:

pes delta$ clang++ esctrn.cpp
Instruction does not dominate all uses!
  %call6 = call i8* @_ZN6icu_467UMemorynwEm(i64 8) nounwind
  call void @_ZdlPv(i8* %call6) nounwind
Broken module found, compilation aborted!
Stack dump:
0.      Program arguments: /usr/local/bin/clang -cc1 -triple
x86_64-unknown-freebsd8.1 -emit-obj -mrelax-all -disable-free -main-file-name
esctrn.cpp -mrelocation-model static -mdisable-fp-elim -masm-verbose
-mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version
2.15 -momit-leaf-frame-pointer -resource-dir /usr/local/bin/../lib/clang/2.9
-ferror-limit 19 -fmessage-length 152 -fexceptions -fgnu-runtime
-fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-IBBTTs.o -x c++
esctrn.cpp 
1.      <eof> parser at end of file
2.      Per-function optimization
3.      Running pass 'Module Verifier' on function
'@_ZN6icu_4611_createEscCERKNS_13UnicodeStringENS_14Transliterator5TokenE'
clang: error: unable to execute command: Abort trap: 6 (core dumped)
clang: error: clang frontend command failed due to signal 1 (use -v to see
invocation)
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  Wed Feb 23 11:46:00 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 23 Feb 2011 11:46:00 -0600 (CST)
Subject: [LLVMbugs] [Bug 9299] New: Assertion failed: (StackTop == 0 &&
 "Stack should be empty after a call!"), function handleSpecialFP,
 file X86FloatingPoint.cpp, line 1245.
Message-ID: <bug-9299-206@http.llvm.org/bugs/>

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

           Summary: Assertion failed: (StackTop == 0 && "Stack should be
                    empty after a call!"), function handleSpecialFP, file
                    X86FloatingPoint.cpp, line 1245.
           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


on X86_64:

pes delta$ clang -O2 dither.c
dither.c:15:2: warning: control reaches end of non-void function
[-Wreturn-type]
 }
 ^
Assertion failed: (StackTop == 0 && "Stack should be empty after a call!"),
function handleSpecialFP, file X86FloatingPoint.cpp, line 1245.
Stack dump:
0.      Program arguments: /usr/local/bin/clang -cc1 -triple
x86_64-unknown-freebsd8.1 -emit-obj -disable-free -main-file-name dither.c
-mrelocation-model static -mdisable-fp-elim -masm-verbose -mconstructor-aliases
-munwind-tables -target-cpu x86-64 -target-linker-version 2.15
-momit-leaf-frame-pointer -resource-dir /usr/local/bin/../lib/clang/2.9 -O2
-ferror-limit 19 -fmessage-length 152 -fgnu-runtime -fdiagnostics-show-option
-fcolor-diagnostics -o /tmp/cc-E7h2f5.o -x c dither.c 
1.      <eof> parser at end of file
2.      Code generation
3.      Running pass 'Function Pass Manager' on module 'dither.c'.
4.      Running pass 'X86 FP Stackifier' on function '@caca_set_dither_gamma'
clang: error: unable to execute command: Abort trap: 6 (core dumped)
clang: error: clang frontend command failed due to signal 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  Wed Feb 23 11:52:56 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 23 Feb 2011 11:52:56 -0600 (CST)
Subject: [LLVMbugs] [Bug 9300] New: Assertion failed: ((Result ||
 isa<UsingShadowDecl>(D) || D->isInvalidDecl() ||
 cast<Decl>(ParentDC)->isInvalidDecl()) && "Unable to find instantiation of
 declaration!"), function FindInstantiatedDecl,
 file SemaTemplateInstantiateDecl.cpp, line 3023.
Message-ID: <bug-9300-206@http.llvm.org/bugs/>

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

           Summary: Assertion failed: ((Result || isa<UsingShadowDecl>(D)
                    || D->isInvalidDecl() ||
                    cast<Decl>(ParentDC)->isInvalidDecl()) && "Unable to
                    find instantiation of declaration!"), function
                    FindInstantiatedDecl, file
                    SemaTemplateInstantiateDecl.cpp, line 3023.
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: FreeBSD
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: rdivacky at freebsd.org
                CC: llvmbugs at cs.uiuc.edu


pes delta$ clang++ -fsyntax-only typebmff.cpp

..warnings and errors...

Assertion failed: ((Result || isa<UsingShadowDecl>(D) || D->isInvalidDecl() ||
cast<Decl>(ParentDC)->isInvalidDecl()) && "Unable to find instantiation of
declaration!"), function FindInstantiatedDecl, file
SemaTemplateInstantiateDecl.cpp, line 3023.
Stack dump:
0.      Program arguments: /usr/local/bin/clang -cc1 -triple
x86_64-unknown-freebsd8.1 -fsyntax-only -disable-free -main-file-name
typebmff.cpp -mrelocation-model static -mdisable-fp-elim -masm-verbose
-mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version
2.15 -momit-leaf-frame-pointer -resource-dir /usr/local/bin/../lib/clang/2.9
-ferror-limit 19 -fmessage-length 152 -fexceptions -fgnu-runtime
-fdiagnostics-show-option -fcolor-diagnostics -x c++ typebmff.cpp 
1.      <eof> parser at end of file
2.      typebmff.cpp:7:16: instantiating function definition 'Enum'
clang: error: unable to execute command: Abort trap: 6 (core dumped)
clang: error: clang frontend command failed due to signal 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  Wed Feb 23 11:57:38 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 23 Feb 2011 11:57:38 -0600 (CST)
Subject: [LLVMbugs] [Bug 9301] New: Assertion failed: (Symbol->isUndefined()
 && "Cannot define a symbol twice!"), function EmitLabel,
 file MCELFStreamer.cpp, line 189.
Message-ID: <bug-9301-206@http.llvm.org/bugs/>

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

           Summary: Assertion failed: (Symbol->isUndefined() && "Cannot
                    define a symbol twice!"), function EmitLabel, file
                    MCELFStreamer.cpp, line 189.
           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


on both amd64/i386

pes delta$ clang randomegd_readb.c
randomegd_readb.c:12:1: warning: control reaches end of non-void function
[-Wreturn-type]
}
^
Assertion failed: (Symbol->isUndefined() && "Cannot define a symbol twice!"),
function EmitLabel, file MCELFStreamer.cpp, line 189.
Stack dump:
0.      Program arguments: /usr/local/bin/clang -cc1 -triple
x86_64-unknown-freebsd8.1 -emit-obj -mrelax-all -disable-free -main-file-name
randomegd_readb.c -mrelocation-model static -mdisable-fp-elim -masm-verbose
-mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version
2.15 -momit-leaf-frame-pointer -resource-dir /usr/local/bin/../lib/clang/2.9
-ferror-limit 19 -fmessage-length 152 -fgnu-runtime -fdiagnostics-show-option
-fcolor-diagnostics -o /tmp/cc-aU6fRp.o -x c randomegd_readb.c 
1.      <eof> parser at end of file
2.      Code generation
3.      Running pass 'Function Pass Manager' on module 'randomegd_readb.c'.
clang: error: unable to execute command: Abort trap: 6 (core dumped)
clang: error: clang frontend command failed due to signal 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  Wed Feb 23 12:44:06 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 23 Feb 2011 12:44:06 -0600 (CST)
Subject: [LLVMbugs] [Bug 9302] New: Assertion failed: (T && "getTerminator
 returned null!"), function SuccIterator,
 file /data/home/rdivacky/llvm/include/llvm/Support/CFG.h, line 105.
Message-ID: <bug-9302-206@http.llvm.org/bugs/>

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

           Summary: Assertion failed: (T && "getTerminator returned
                    null!"), function SuccIterator, file
                    /data/home/rdivacky/llvm/include/llvm/Support/CFG.h,
                    line 105.
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: FreeBSD
            Status: NEW
          Severity: normal
          Priority: P
         Component: Support Libraries
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: rdivacky at freebsd.org
                CC: llvmbugs at cs.uiuc.edu


pes delta$ clang++ httpd.cxx

.... warnings ....

Assertion failed: (T && "getTerminator returned null!"), function SuccIterator,
file /data/home/rdivacky/llvm/include/llvm/Support/CFG.h, line 105.
Stack dump:
0.      Program arguments: /usr/local/bin/clang -cc1 -triple
x86_64-unknown-freebsd8.1 -emit-obj -mrelax-all -disable-free -main-file-name
httpd.cxx -mrelocation-model static -mdisable-fp-elim -masm-verbose
-mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version
2.15 -momit-leaf-frame-pointer -resource-dir /usr/local/bin/../lib/clang/2.9
-ferror-limit 19 -fmessage-length 152 -fexceptions -fgnu-runtime
-fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-iVeuoi.o -x c++
httpd.cxx 
1.      <eof> parser at end of file
2.      Per-function optimization
3.      Running pass 'Dominator Tree Construction' on function
'@_ZSt15response_threadPv'
clang: error: unable to execute command: Abort trap: 6 (core dumped)
clang: error: clang frontend command failed due to signal 1 (use -v to see
invocation)
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  Wed Feb 23 12:51:53 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 23 Feb 2011 12:51:53 -0600 (CST)
Subject: [LLVMbugs] [Bug 9303] New: Assertion failed:
 (Dest.getScopeDepth().encloses(EStack.getInnermostNormalCleanup()) &&
 "stale jump destination"), function EmitBranchThroughCleanup, file
Message-ID: <bug-9303-206@http.llvm.org/bugs/>

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

           Summary: Assertion failed:
                    (Dest.getScopeDepth().encloses(EStack.getInnermostNorm
                    alCleanup()) && "stale jump destination"), function
                    EmitBranchThroughCleanup, file
           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$ clang++ vm1.cpp
Assertion failed:
(Dest.getScopeDepth().encloses(EHStack.getInnermostNormalCleanup()) && "stale
jump destination"), function EmitBranchThroughCleanup, file CGCleanup.cpp, line
880.
Stack dump:
0.      Program arguments: /usr/local/bin/clang -cc1 -triple
x86_64-unknown-freebsd8.1 -emit-obj -mrelax-all -disable-free -main-file-name
vm1.cpp -mrelocation-model static -mdisable-fp-elim -masm-verbose
-mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version
2.15 -momit-leaf-frame-pointer -resource-dir /usr/local/bin/../lib/clang/2.9
-ferror-limit 19 -fmessage-length 152 -fexceptions -fgnu-runtime
-fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-OIUgz2.o -x c++
vm1.cpp 
1.      <eof> parser at end of file
2.      vm1.cpp:29:16: LLVM IR generation of declaration 'VM::run'
3.      vm1.cpp:29:16: Generating code for declaration 'VM::run'
4.      vm1.cpp:29:46: LLVM IR generation of compound statement ('{}')
5.      vm1.cpp:31:23: LLVM IR generation of compound statement ('{}')
6.      vm1.cpp:34:31: LLVM IR generation of compound statement ('{}')
7.      vm1.cpp:36:110: LLVM IR generation of compound statement ('{}')
clang: error: unable to execute command: Abort trap: 6 (core dumped)
clang: error: clang frontend command failed due to signal 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  Wed Feb 23 12:55:38 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 23 Feb 2011 12:55:38 -0600 (CST)
Subject: [LLVMbugs] [Bug 9304] New: Assertion failed:
 (ConstantCondValue.getBitWidth() == CondWidth &&
 ConstantCondValue.isSigned() == CondIsSigned),
 function ActOnFinishSwitchStmt, file
 /a/portbuild/amd64/9/builds/20110221064547.pointyhat-west/src/lib/clang/libclangsema/../../../contrib/ll
Message-ID: <bug-9304-206@http.llvm.org/bugs/>

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

           Summary: Assertion failed: (ConstantCondValue.getBitWidth() ==
                    CondWidth && ConstantCondValue.isSigned() ==
                    CondIsSigned), function ActOnFinishSwitchStmt, file
                    /a/portbuild/amd64/9/builds/20110221064547.pointyhat-w
                    est/src/lib/clang/libclangsema/../../../contrib/ll
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: FreeBSD
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: rdivacky at freebsd.org
                CC: llvmbugs at cs.uiuc.edu


pes delta$ clang++ glue.cc
glue.cc:3:4: warning: switch condition has boolean value
                        switch (sizeof(click_rfc1483) == 8) {
                        ^       ~~~~~~~~~~~~~~~~~~~~~~~~~~
Assertion failed: (ConstantCondValue.getBitWidth() == CondWidth &&
ConstantCondValue.isSigned() == CondIsSigned), function ActOnFinishSwitchStmt,
file SemaStmt.cpp, line 591.
Stack dump:
0.      Program arguments: /usr/local/bin/clang -cc1 -triple
x86_64-unknown-freebsd8.1 -emit-obj -mrelax-all -disable-free -main-file-name
glue.cc -mrelocation-model static -mdisable-fp-elim -masm-verbose
-mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version
2.15 -momit-leaf-frame-pointer -resource-dir /usr/local/bin/../lib/clang/2.9
-ferror-limit 19 -fmessage-length 152 -fexceptions -fgnu-runtime
-fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-Aez8g4.o -x c++
glue.cc 
1.      glue.cc:5:3: current parser token '}'
2.      glue.cc:1:2: parsing struct/union/class body 'click_rfc1483'
3.      glue.cc:2:36: parsing function body 'click_check_header_sizes'
4.      glue.cc:2:36: in compound statement ('{}')
clang: error: unable to execute command: Abort trap: 6 (core dumped)
clang: error: clang frontend command failed due to signal 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  Wed Feb 23 13:13:58 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 23 Feb 2011 13:13:58 -0600 (CST)
Subject: [LLVMbugs] [Bug 9305] New: Assertion failed: (i < getNumOperands()
 && "getOperand() out of range!"), function getOperand, file
 /a/portbuild/amd64/9/builds/20110221064547.pointyhat-west/src/lib/clang/libllvmpowerpccodegen/../../../contrib/llvm/include/llvm/CodeGen/MachineInstr.h,
 li
Message-ID: <bug-9305-206@http.llvm.org/bugs/>

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

           Summary: Assertion failed: (i < getNumOperands() &&
                    "getOperand() out of range!"), function getOperand,
                    file
                    /a/portbuild/amd64/9/builds/20110221064547.pointyhat-w
                    est/src/lib/clang/libllvmpowerpccodegen/../../../contr
                    ib/llvm/include/llvm/CodeGen/MachineInstr.h, li
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: FreeBSD
            Status: NEW
          Severity: normal
          Priority: P
         Component: Common Code Generator Code
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: rdivacky at freebsd.org
                CC: llvmbugs at cs.uiuc.edu


pes delta$ clang -O2 genborn_sse2_double.c

... warnings ...

Assertion failed: (i < getNumOperands() && "getOperand() out of range!"),
function getOperand, file
/data/home/rdivacky/llvm/include/llvm/CodeGen/MachineInstr.h, line 173.
Stack dump:
0.      Program arguments: /usr/local/bin/clang -cc1 -triple
x86_64-unknown-freebsd8.1 -emit-obj -disable-free -main-file-name
genborn_sse2_double.c -mrelocation-model static -mdisable-fp-elim -masm-verbose
-mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version
2.15 -momit-leaf-frame-pointer -resource-dir /usr/local/bin/../lib/clang/2.9
-O2 -ferror-limit 19 -fmessage-length 152 -fgnu-runtime
-fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-WAGRkq.o -x c
genborn_sse2_double.c 
1.      <eof> parser at end of file
2.      Code generation
3.      Running pass 'Function Pass Manager' on module 'genborn_sse2_double.c'.
4.      Running pass 'Two-Address instruction pass' on function
'@calc_gb_rad_still_sse2_double'
clang: error: unable to execute command: Abort trap: 6 (core dumped)
clang: error: clang frontend command failed due to signal 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  Wed Feb 23 13:17:02 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 23 Feb 2011 13:17:02 -0600 (CST)
Subject: [LLVMbugs] [Bug 9299] Assertion failed: (StackTop == 0 && "Stack
 should be empty after a call!"), function handleSpecialFP,
 file X86FloatingPoint.cpp, line 1245.
In-Reply-To: <bug-9299-206@http.llvm.org/bugs/>
References: <bug-9299-206@http.llvm.org/bugs/>
Message-ID: <20110223191702.29D222A6C124@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #3 from Chris Lattner <clattner at apple.com> 2011-02-23 13:17:01 CST ---
Tracking as a dupe of 2270

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

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 23 13:17:51 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 23 Feb 2011 13:17:51 -0600 (CST)
Subject: [LLVMbugs] [Bug 4434] ICE with inline FP asm with llvm-gcc/llvm
	2.6svn
In-Reply-To: <bug-4434-206@http.llvm.org/bugs/>
References: <bug-4434-206@http.llvm.org/bugs/>
Message-ID: <20110223191751.E3BF02A6C12F@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #16 from Chris Lattner <clattner at apple.com> 2011-02-23 13:17:49 CST ---
We don't handle the fp-stack inline asm constraints well, tracking as a dupe of
2270 until things get sorted out.

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

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 23 13:48:15 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 23 Feb 2011 13:48:15 -0600 (CST)
Subject: [LLVMbugs] [Bug 9306] New: Assertion failed: (OrigPreheader &&
 OrigLatch && "Loop not in canonical form?"), function rotateLoop,
 file
 /a/portbuild/amd64/9/builds/20110221064547.pointyhat-west/src/lib/clang/libllvmscalaropts/../../../contrib/llvm/lib/Transforms/Scalar/LoopRotation.c
Message-ID: <bug-9306-206@http.llvm.org/bugs/>

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

           Summary: Assertion failed: (OrigPreheader && OrigLatch && "Loop
                    not in canonical form?"), function rotateLoop, file
                    /a/portbuild/amd64/9/builds/20110221064547.pointyhat-w
                    est/src/lib/clang/libllvmscalaropts/../../../contrib/l
                    lvm/lib/Transforms/Scalar/LoopRotation.c
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: FreeBSD
            Status: NEW
          Severity: normal
          Priority: P
         Component: Loop Optimizer
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: rdivacky at freebsd.org
                CC: llvmbugs at cs.uiuc.edu


the huge attached test case takes A LONG TIME (3 minutes here) and it ends with

Assertion failed: (OrigPreheader && OrigLatch && "Loop not in canonical
form?"), function rotateLoop, file LoopRotation.cpp, line 187.
Stack dump:
0.      Program arguments: /usr/local/bin/clang -cc1 -triple
x86_64-unknown-freebsd8.1 -emit-obj -disable-free -main-file-name _num.c
-mrelocation-model static -mdisable-fp-elim -masm-verbose -mconstructor-aliases
-munwind-tables -target-cpu x86-64 -target-linker-version 2.15
-momit-leaf-frame-pointer -resource-dir /usr/local/bin/../lib/clang/2.9 -O2
-ferror-limit 19 -fmessage-length 152 -fgnu-runtime -fdiagnostics-show-option
-fcolor-diagnostics -o /tmp/cc-ci8567.o -x c _num.c
1.      <eof> parser at end of file
2.      Per-module optimization passes
3.      Running pass 'CallGraph Pass Manager' on module '_num.c'.
4.      Running pass 'Loop Pass Manager' on function '@___H__20___num'
5.      Running pass 'Rotate Loops' on basic block
'%___L226__23__23_bignum_2e__2a_'
clang: error: unable to execute command: Abort trap: 6 (core dumped)
clang: error: clang frontend command failed due to signal 1 (use -v to see
invocation)

I am trying to reduce smaller one but it's very slow

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 23 14:24:06 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 23 Feb 2011 14:24:06 -0600 (CST)
Subject: [LLVMbugs] [Bug 9292] [MC assembler] .globl does not emit symbol if
 unreferenced
In-Reply-To: <bug-9292-206@http.llvm.org/bugs/>
References: <bug-9292-206@http.llvm.org/bugs/>
Message-ID: <20110223202406.60D302A6C12F@llvm.org>

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

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

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

--- Comment #3 from Rafael ?vila de Esp?ndola <rafael.espindola at gmail.com> 2011-02-23 14:24:05 CST ---
Fixed in 126330.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 23 15:16:57 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 23 Feb 2011 15:16:57 -0600 (CST)
Subject: [LLVMbugs] [Bug 8974] dependency files absolutize paths such as
 -include ../path/foo.h on the command line
In-Reply-To: <bug-8974-206@http.llvm.org/bugs/>
References: <bug-8974-206@http.llvm.org/bugs/>
Message-ID: <20110223211657.8923D2A6C124@llvm.org>

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

Nick Lewycky <nlewycky at google.com> changed:

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

--- Comment #2 from Nick Lewycky <nlewycky at google.com> 2011-02-23 15:16:56 CST ---
Fixed in r126334.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 23 16:09:40 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 23 Feb 2011 16:09:40 -0600 (CST)
Subject: [LLVMbugs] [Bug 8685] [MC assembler] does not support square
	bracket notation
In-Reply-To: <bug-8685-206@http.llvm.org/bugs/>
References: <bug-8685-206@http.llvm.org/bugs/>
Message-ID: <20110223220940.47BBB2A6C12F@llvm.org>

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

J?rg Sonnenberger <joerg at NetBSD.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
                 CC|                            |joerg at NetBSD.org
         Resolution|FIXED                       |

--- Comment #9 from J?rg Sonnenberger <joerg at NetBSD.org> 2011-02-23 16:09:39 CST ---
Patch was reverted.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 23 17:06:28 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 23 Feb 2011 17:06:28 -0600 (CST)
Subject: [LLVMbugs] [Bug 9296] -Warray-bounds thinks 'true' is negative.
In-Reply-To: <bug-9296-206@http.llvm.org/bugs/>
References: <bug-9296-206@http.llvm.org/bugs/>
Message-ID: <20110223230629.080D22A6C12C@llvm.org>

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

Ted Kremenek <kremenek at apple.com> changed:

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

--- Comment #2 from Ted Kremenek <kremenek at apple.com> 2011-02-23 17:06:28 CST ---
Fixed: r126341

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 23 17:16:21 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 23 Feb 2011 17:16:21 -0600 (CST)
Subject: [LLVMbugs] [Bug 9307] New: clang-2.9 miscompiles FFmpeg's VP8
	decoder
Message-ID: <bug-9307-206@http.llvm.org/bugs/>

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

           Summary: clang-2.9 miscompiles FFmpeg's VP8 decoder
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Driver
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: rsbultje at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Hi,

clang-2.9 (but not 2.8) miscompiles FFmpeg's VP8 decoder since a while. The
failing testsuite can be found here fore x86-32:
http://fate.ffmpeg.org/x86_32-freebsd-clang/20110223164516
and here for x86-64:
http://fate.ffmpeg.org/x86_64-linux-clang/20110223163508
the vp8 testsuite passes for other compilers.

The bug can be worked around by compiling vp8.c using -O1 instead of -O3. -O0
also works fine, -O2 also miscompiles. Under any other compiler (e.g. gcc) or
clang 1.5 or 2.8, it works fine. The problem was introduced by this patch:

http://git.ffmpeg.org/?p=ffmpeg.git;a=commitdiff;h=f3d09d44b70492022964e2ead5f439bb7c96eaa2

At this point I'm not quite sure how to debug this further. Valgrind is clean
and there's no compiler warnings. I've checked to make sure that the
AV_ZERO32()s (which expect aligned memory, and zero only the first array
members of near_mv[4]) are not the problem, and they are not. Also, the removal
of the unused variable "best" is not causing any problems.

I could try to apply the patch above "piece-by-piece" and figure out which
"sub-change" causes the problem, but that's a lot of work. I was hoping you
could suggest some ways to further debug this issue, because I'm not really
sure where to go from here, and don't have infinite time to spend on 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  Wed Feb 23 19:06:04 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 23 Feb 2011 19:06:04 -0600 (CST)
Subject: [LLVMbugs] [Bug 9308] New: clang should not accept calling
 protected members of superclasses on the superclass's type
Message-ID: <bug-9308-206@http.llvm.org/bugs/>

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

           Summary: clang should not accept calling protected members of
                    superclasses on the superclass's type
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: nicolasweber at gmx.de
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


gcc rejects this, clang should too:

class A {
 protected:
  A(int a) {}
};
class B : public A {
  void f() {
    A a(32);
  }
};

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 23 19:14:57 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 23 Feb 2011 19:14:57 -0600 (CST)
Subject: [LLVMbugs] [Bug 9309] New: assertion hits in llc,
	LegalizeVectorTypes.cpp
Message-ID: <bug-9309-206@http.llvm.org/bugs/>

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

           Summary: assertion hits in llc, LegalizeVectorTypes.cpp
           Product: new-bugs
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: matt at pharr.org
                CC: llvmbugs at cs.uiuc.edu


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

If I run the attached example program through llc ("llc bug.ll"), with LLVM
TOT, I get the following crash:

SplitVectorResult #0: 0x26f0c70: v4f64 = fp_extend 0x26f1070 [ORD=10] [ID=0]

Do not know how to split the result of this operator!
UNREACHABLE executed at LegalizeVectorTypes.cpp:402!
0  llc             0x00000000014782b1
1  llc             0x00000000014780a4
2  libpthread.so.0 0x00002b15238a78f0
3  libc.so.6       0x00002b152449ca75 gsignal + 53
4  libc.so.6       0x00002b15244a05c0 abort + 384
5  llc             0x0000000001463fa1
6  llc             0x0000000000f37da8
7  llc             0x0000000000f2c2a1
8  llc             0x0000000000f31854 llvm::SelectionDAG::LegalizeTypes() + 74
9  llc             0x0000000000ed1179
llvm::SelectionDAGISel::CodeGenAndEmitDAG() + 1055
10 llc             0x0000000000ed08f4
llvm::SelectionDAGISel::SelectBasicBlock(llvm::ilist_iterator<llvm::Instruction
const>, llvm::ilist_iterator<llvm::Instruction const>, bool&) + 258
11 llc             0x0000000000ed2df6
llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) + 2008
12 llc             0x0000000000ecfe61
llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) + 731
13 llc             0x0000000001025491
llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 95
14 llc             0x00000000013a3955
llvm::FPPassManager::runOnFunction(llvm::Function&) + 407
15 llc             0x00000000013a3b72
llvm::FPPassManager::runOnModule(llvm::Module&) + 102
16 llc             0x00000000013a3ea5
llvm::MPPassManager::runOnModule(llvm::Module&) + 459
17 llc             0x00000000013a43a3 llvm::PassManagerImpl::run(llvm::Module&)
+ 125
18 llc             0x00000000013a48f9 llvm::PassManager::run(llvm::Module&) +
39
19 llc             0x0000000000a05e0f main + 2455
20 libc.so.6       0x00002b1524487c4d __libc_start_main + 253
21 llc             0x0000000000a04d69
Stack dump:
0.    Program arguments: llc bug.ll 
1.    Running pass 'Function Pass Manager' on module 'bug.ll'.
2.    Running pass 'X86 DAG->DAG Instruction Selection' on function '@f_fu'

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 23 19:24:36 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 23 Feb 2011 19:24:36 -0600 (CST)
Subject: [LLVMbugs] [Bug 8336] clang hangs while optimizing a snippet of C
	code
In-Reply-To: <bug-8336-206@http.llvm.org/bugs/>
References: <bug-8336-206@http.llvm.org/bugs/>
Message-ID: <20110224012436.BA2F32A6C124@llvm.org>

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

Elias Pipping <pipping at exherbo.org> changed:

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

--- Comment #4 from Elias Pipping <pipping at exherbo.org> 2011-02-23 19:24:36 CST ---
Appears to be 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 Feb 23 20:37:30 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 23 Feb 2011 20:37:30 -0600 (CST)
Subject: [LLVMbugs] [Bug 9305] Assertion failed: (i < getNumOperands() &&
 "getOperand() out of range!")
In-Reply-To: <bug-9305-206@http.llvm.org/bugs/>
References: <bug-9305-206@http.llvm.org/bugs/>
Message-ID: <20110224023730.D342A2A6C12E@llvm.org>

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

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

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

--- Comment #3 from Evan Cheng <evan.cheng at apple.com> 2011-02-23 20:37:30 CST ---
Fixed: r126359

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 23 21:09:44 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 23 Feb 2011 21:09:44 -0600 (CST)
Subject: [LLVMbugs] [Bug 9287] Assert when analyzing "ternary operator"
 without second operator
In-Reply-To: <bug-9287-206@http.llvm.org/bugs/>
References: <bug-9287-206@http.llvm.org/bugs/>
Message-ID: <20110224030944.E1FDA2A6C12D@llvm.org>

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

Ted Kremenek <kremenek at apple.com> changed:

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

--- Comment #3 from Ted Kremenek <kremenek at apple.com> 2011-02-23 21:09:44 CST ---
Fixed: r126362

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 23 21:52:03 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 23 Feb 2011 21:52:03 -0600 (CST)
Subject: [LLVMbugs] [Bug 9310] New: ac Polyhedron 2005 benchmark regressed
 %10.5 in llvm-gcc42-2.8
Message-ID: <bug-9310-206@http.llvm.org/bugs/>

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

           Summary: ac Polyhedron 2005 benchmark regressed %10.5 in
                    llvm-gcc42-2.8
           Product: tools
           Version: 2.8
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: gfortran
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: howarth at nitro.med.uc.edu
                CC: llvmbugs at cs.uiuc.edu


The ac Polyhedron 2005 benchmark for the llvm-gcc42-2.7 release benchmarked on
x86_64-apple-darwin10 as...

   Benchmark   Compile  Executable   Ave Run  Number   Estim 
        Name    (secs)     (bytes)    (secs) Repeats   Err % 
   ---------   -------  ----------   ------- -------  ------ 
          ac      0.34       10000     12.85      10  0.0067 

whereas for the llvm-gcc42-2.8 release and current svn it is regressed 10.5% in
runtime....

   Benchmark   Compile  Executable   Ave Run  Number   Estim 
        Name    (secs)     (bytes)    (secs) Repeats   Err % 
   ---------   -------  ----------   ------- -------  ------ 
          ac      0.29       10000     14.20      10  0.0147

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 23 21:58:06 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 23 Feb 2011 21:58:06 -0600 (CST)
Subject: [LLVMbugs] [Bug 9311] New: aermod Polyhedron 2005 benchmark
 regressed 12.7% in llvm-gcc42 svn
Message-ID: <bug-9311-206@http.llvm.org/bugs/>

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

           Summary: aermod Polyhedron 2005 benchmark regressed 12.7% in
                    llvm-gcc42 svn
           Product: tools
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: gfortran
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: howarth at nitro.med.uc.edu
                CC: llvmbugs at cs.uiuc.edu


The aermod Polyhedron 2005 benchmark for current llvm-gcc42 svn shows...


   Benchmark   Compile  Executable   Ave Run  Number   Estim
        Name    (secs)     (bytes)    (secs) Repeats   Err %
   ---------   -------  ----------   ------- -------  ------
      aermod     29.53     1013016     17.17      10  0.0065

on x86_64-apple-darwin10 compared to the results for llvm-gcc42 2.8 of...


   Benchmark   Compile  Executable   Ave Run  Number   Estim
        Name    (secs)     (bytes)    (secs) Repeats   Err %
   ---------   -------  ----------   ------- -------  ------
      aermod     18.69       10000     15.23      10  0.0412

which represents a 12.7% runtime regression.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 23 22:02:40 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 23 Feb 2011 22:02:40 -0600 (CST)
Subject: [LLVMbugs] [Bug 9312] New: fatigue Polyhedron 2005 benchmark
 regressed 12.2% in llvm-gcc42 svn
Message-ID: <bug-9312-206@http.llvm.org/bugs/>

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

           Summary: fatigue Polyhedron 2005 benchmark regressed 12.2% in
                    llvm-gcc42 svn
           Product: tools
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: gfortran
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: howarth at nitro.med.uc.edu
                CC: llvmbugs at cs.uiuc.edu


The fatigue Polyhedron 2005 benchmark for current llvm-gcc42 svn on
x86_64-apple-darwin10 shows...

   Benchmark   Compile  Executable   Ave Run  Number   Estim
        Name    (secs)     (bytes)    (secs) Repeats   Err %
   ---------   -------  ----------   ------- -------  ------
     fatigue      0.97       65552      9.59      10  0.0333

which represents a 12.2% runtime regression compared to the results from
llvm-gcc42 2.8....


   Benchmark   Compile  Executable   Ave Run  Number   Estim
        Name    (secs)     (bytes)    (secs) Repeats   Err %
   ---------   -------  ----------   ------- -------  ------
     fatigue      0.81       10000      8.55      10  0.0098

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 24 01:31:43 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 24 Feb 2011 01:31:43 -0600 (CST)
Subject: [LLVMbugs] [Bug 9304] Assertion failed:
 (ConstantCondValue.getBitWidth() == CondWidth &&
 ConstantCondValue.isSigned() == CondIsSigned)
In-Reply-To: <bug-9304-206@http.llvm.org/bugs/>
References: <bug-9304-206@http.llvm.org/bugs/>
Message-ID: <20110224073143.3033A2A6C12E@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #3 from Chris Lattner <clattner at apple.com> 2011-02-24 01:31:42 CST ---
Fixed in r126368.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 24 09:20:26 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 24 Feb 2011 09:20:26 -0600 (CST)
Subject: [LLVMbugs] [Bug 9313] New: test failures wrt
 AsmParser/MachO/StackVariable/Scope
Message-ID: <bug-9313-206@http.llvm.org/bugs/>

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

           Summary: test failures wrt AsmParser/MachO/StackVariable/Scope
           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: impulze at impulze.org
                CC: llvmbugs at cs.uiuc.edu


Hey,

my recent build with r126384 fails some tests (configured with only
--enable-targets=x86).
Seems like some of them should never run on my system anyway (the MachO/Darwin
ones).

Compiled on:
Linux istari 2.6.38-rc4-istari #21 SMP Sun Feb 13 20:15:04 CET 2011 x86_64
GNU/Linux

make -j4 check
llvm[0]: Running test suite
make[1]: Entering directory
`/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/test'
Making a new site.exp file...
Making LLVM unittest 'lit.site.cfg' file...
Making LLVM 'lit.site.cfg' file...
( ulimit -t 600 ; ulimit -d 512000 ; ulimit -m 512000 ; ulimit -v 1024000 ; \
  /var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/utils/lit/lit.py -s -v
. )
FAIL: LLVM :: DebugInfo/2009-10-16-Scope.ll (3047 of 5822)
******************** TEST 'LLVM :: DebugInfo/2009-10-16-Scope.ll' FAILED
********************
Script:
--
/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/Release+Asserts/bin/llc
/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/test/DebugInfo/2009-10-16-Scope.ll
-O0 -o /dev/null -mtriple=x86_64-apple-darwin
/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/Release+Asserts/bin/llc
/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/test/DebugInfo/2009-10-16-Scope.ll
-O0 -o /dev/null -mtriple=arm-apple-darwin
--
Exit Code: 1
Command Output (stderr):
--
/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/Release+Asserts/bin/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.
--

********************
FAIL: LLVM :: DebugInfo/2010-08-04-StackVariable.ll (3069 of 5822)
******************** TEST 'LLVM :: DebugInfo/2010-08-04-StackVariable.ll'
FAILED ********************
Script:
--
/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/Release+Asserts/bin/llc
-O0 -mtriple=arm-apple-darwin <
/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/test/DebugInfo/2010-08-04-StackVariable.ll
| grep DW_OP_fbreg
/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/Release+Asserts/bin/llc
-O0 -mtriple=x86_64-apple-darwin <
/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/test/DebugInfo/2010-08-04-StackVariable.ll
| grep DW_OP_fbreg
--
Exit Code: 1
Command Output (stderr):
--
/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/Release+Asserts/bin/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.
--

********************
FAIL: LLVM :: MC/AsmParser/full_line_comment.s (3935 of 5822)
******************** TEST 'LLVM :: MC/AsmParser/full_line_comment.s' FAILED
********************
Script:
--
/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/Release+Asserts/bin/llvm-mc
-triple arm-apple-darwin10
/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/test/MC/AsmParser/full_line_comment.s
|
/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/Release+Asserts/bin/FileCheck
/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/test/MC/AsmParser/full_line_comment.s
--
Exit Code: 1
Command Output (stderr):
--
/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/Release+Asserts/bin/llvm-mc:
error: unable to get target for 'arm-apple-darwin10', see --version and
--triple.
FileCheck error: '-' is empty.
--

********************
FAIL: LLVM :: MC/MachO/darwin-Thumb-reloc.s (4058 of 5822)
******************** TEST 'LLVM :: MC/MachO/darwin-Thumb-reloc.s' FAILED
********************
Script:
--
/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/Release+Asserts/bin/llvm-mc
-n -triple thumbv7-apple-darwin10
/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/test/MC/MachO/darwin-Thumb-reloc.s
-filetype=obj -o
/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/test/MC/MachO/Output/darwin-Thumb-reloc.s.tmp.obj
/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/Release+Asserts/bin/macho-dump
--dump-section-data <
/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/test/MC/MachO/Output/darwin-Thumb-reloc.s.tmp.obj
>
/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/test/MC/MachO/Output/darwin-Thumb-reloc.s.tmp.dump
/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/Release+Asserts/bin/FileCheck
<
/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/test/MC/MachO/Output/darwin-Thumb-reloc.s.tmp.dump
/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/test/MC/MachO/darwin-Thumb-reloc.s
--
Exit Code: 1
Command Output (stderr):
--
/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/Release+Asserts/bin/llvm-mc:
error: unable to get target for 'thumbv7-apple-darwin10', see --version and
--triple.
--

********************
FAIL: LLVM :: MC/MachO/darwin-ARM-reloc.s (4059 of 5822)
******************** TEST 'LLVM :: MC/MachO/darwin-ARM-reloc.s' FAILED
********************
Script:
--
/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/Release+Asserts/bin/llvm-mc
-n -triple armv7-apple-darwin10
/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/test/MC/MachO/darwin-ARM-reloc.s
-filetype=obj -o
/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/test/MC/MachO/Output/darwin-ARM-reloc.s.tmp.obj
/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/Release+Asserts/bin/macho-dump
--dump-section-data <
/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/test/MC/MachO/Output/darwin-ARM-reloc.s.tmp.obj
>
/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/test/MC/MachO/Output/darwin-ARM-reloc.s.tmp.dump
/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/Release+Asserts/bin/FileCheck
<
/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/test/MC/MachO/Output/darwin-ARM-reloc.s.tmp.dump
/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/test/MC/MachO/darwin-ARM-reloc.s
--
Exit Code: 1
Command Output (stderr):
--
/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/Release+Asserts/bin/llvm-mc:
error: unable to get target for 'armv7-apple-darwin10', see --version and
--triple.
--

********************
Testing Time: 162.40s
********************
Failing Tests (5):
    LLVM :: DebugInfo/2009-10-16-Scope.ll
    LLVM :: DebugInfo/2010-08-04-StackVariable.ll
    LLVM :: MC/AsmParser/full_line_comment.s
    LLVM :: MC/MachO/darwin-ARM-reloc.s
    LLVM :: MC/MachO/darwin-Thumb-reloc.s

  Expected Passes    : 3883
  Expected Failures  : 16
  Unsupported Tests  : 1918
  Unexpected Failures: 5
make[1]: Leaving directory
`/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/test'
make[1]: *** [check-local-lit] Error 1
make: *** [check] 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  Thu Feb 24 09:29:42 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 24 Feb 2011 09:29:42 -0600 (CST)
Subject: [LLVMbugs] [Bug 9314] New: -Wformat-security false positive with
 __func__ and __PRETTY_FUNCTION__
Message-ID: <bug-9314-206@http.llvm.org/bugs/>

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

           Summary: -Wformat-security false positive with __func__ and
                    __PRETTY_FUNCTION__
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: will at willthompson.co.uk
                CC: llvmbugs at cs.uiuc.edu


Clang doesn't believe that __func__ and __PRETTY_FUNCTION__ are string
literals. Thus the following sample program:

    #include <stdio.h>

    int
    main (int argc, char **argv)
    {
      printf (__PRETTY_FUNCTION__);
      printf (__func__);
      return 0;
    }

produces the following diagnostics:

    % clang -Wformat-security -o pretty pretty.c
    pretty.c:6:11: warning: format string is not a string literal
          (potentially insecure) [-Wformat-security]
      printf (__PRETTY_FUNCTION__);
              ^~~~~~~~~~~~~~~~~~~
    pretty.c:7:11: warning: format string is not a string literal
          (potentially insecure) [-Wformat-security]
      printf (__func__);
              ^~~~~~~~
    2 diagnostics generated.

The warning is technically accurate, I suppose: they are not literals per se.
But they can't contain format string-significant characters, so this usage
feels harmless to me.

I'm using:
     % clang --version
    clang version 1.1 (Debian 2.7-3)
    Target: x86_64-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  Thu Feb 24 10:47:46 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 24 Feb 2011 10:47:46 -0600 (CST)
Subject: [LLVMbugs] [Bug 9315] New: pow() isn't folded
Message-ID: <bug-9315-206@http.llvm.org/bugs/>

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

           Summary: pow() isn't folded
           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


Sorry if this is known or if I'm missing something.

I'd expect this code to be compiled into a nop:

#include <math.h>
#include <limits.h>
#include <assert.h>

void f1 (void)
{
  signed char min = -pow(2,8)/2;
  assert (min==CHAR_MIN);
}

It is compiled away by any recent version of gcc for x86. However, the versions
of clang that I tried (2,7 and today's SVN) turn this into a library call, an
FP divide, and an assertion check:

regehr at home:~/sat_ops/saved_sat_ops$ ~/z/bin/clang -v
clang version 2.9 (trunk 126385)
Target: i386-pc-linux-gnu
Thread model: posix
regehr at home:~/sat_ops/saved_sat_ops$ ~/z/bin/clang -O pow2.c -S -o -
    .file    "pow2.c"
    .section    .rodata.cst8,"aM", at progbits,8
    .align    8
.LCPI0_0:
    .quad    -4611686018427387904    # double -2.000000e+00
    .text
    .globl    f1
    .align    16, 0x90
    .type    f1, at function
f1:                                     # @f1
# BB#0:                                 # %entry
    pushl    %ebp
    movl    %esp, %ebp
    subl    $24, %esp
    movl    $1075838976, 4(%esp)    # imm = 0x40200000
    movl    $0, (%esp)
    calll    exp2
    fstpl    -8(%ebp)
    movsd    -8(%ebp), %xmm0
    divsd    .LCPI0_0, %xmm0
    cvttsd2si    %xmm0, %eax
    cmpb    $-128, %al
    jne    .LBB0_2
# BB#1:                                 # %cond.end
    addl    $24, %esp
    popl    %ebp
    ret
.LBB0_2:                                # %cond.false
    movl    $.L__PRETTY_FUNCTION__.f1, 12(%esp)
    movl    $8, 8(%esp)
    movl    $.L.str1, 4(%esp)
    movl    $.L.str, (%esp)
    calll    __assert_fail
.Ltmp0:
    .size    f1, .Ltmp0-f1

    .globl    f2
    .align    16, 0x90
    .type    f2, at function
f2:                                     # @f2
# BB#0:                                 # %entry
    pushl    %ebp
    movl    %esp, %ebp
    subl    $8, %esp
    movl    $1075838976, 4(%esp)    # imm = 0x40200000
    movl    $0, (%esp)
    calll    exp2
    addl    $8, %esp
    popl    %ebp
    ret
.Ltmp1:
    .size    f2, .Ltmp1-f2

    .type    .L.str, at object          # @.str
    .section    .rodata.str1.1,"aMS", at progbits,1
.L.str:
    .asciz     "min==(-127-1)"
    .size    .L.str, 14

    .type    .L.str1, at object         # @.str1
.L.str1:
    .asciz     "pow2.c"
    .size    .L.str1, 7

    .type    .L__PRETTY_FUNCTION__.f1, at object # @__PRETTY_FUNCTION__.f1
.L__PRETTY_FUNCTION__.f1:
    .asciz     "void f1()"
    .size    .L__PRETTY_FUNCTION__.f1, 10


    .section    .note.GNU-stack,"", at progbits

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 24 12:34:08 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 24 Feb 2011 12:34:08 -0600 (CST)
Subject: [LLVMbugs] [Bug 9316] New: block scope extern function declaration
 not receiving external linkage
Message-ID: <bug-9316-206@http.llvm.org/bugs/>

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

           Summary: block scope extern function declaration not receiving
                    external linkage
           Product: clang
           Version: unspecified
          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
extern "C" {
  namespace {
  class X {
    int f() {
      extern int puts(const char* s);
      return puts("help!");
    }
  };
  }
}

% clang -fsyntax-only t.cc
% ./third_party/llvm/crosstool/unstable/clang/bin/clang -fsyntax-only t.cc
t.cc:8:18: warning: function 'puts' has internal linkage but is not defined
      extern int puts(const char* s);
                 ^
t.cc:9:14: note: used here
      return puts("help!");
             ^
1 warning generated.


My reading of the standard says that 'puts' should receive external linkage.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 24 13:03:47 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 24 Feb 2011 13:03:47 -0600 (CST)
Subject: [LLVMbugs] [Bug 9317] New: Clang shouldn't complain about errors in
 the fix itself suggests
Message-ID: <bug-9317-206@http.llvm.org/bugs/>

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

           Summary: Clang shouldn't complain about errors in the fix
                    itself suggests
           Product: clang
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: zhanyong.wan at gmail.com
                CC: llvmbugs at cs.uiuc.edu


$ cat typo.cc
void revoke(const char*) {}

namespace foo {
void Invoke(int n) {}
}

void Test() {
  Invoke(42);
}

$ clang typo.cc
typo.cc:8:3: error: use of undeclared identifier 'Invoke'; did you mean
'revoke'?
  Invoke(42);
  ^~~~~~
  revoke
typo.cc:1:6: note: 'revoke' declared here
void revoke(const char*) {}
     ^
typo.cc:8:10: error: cannot initialize a parameter of type 'const char *' with
an rvalue of type 'int'
  Invoke(42);
         ^~
typo.cc:1:24: note: passing argument to parameter here
void revoke(const char*) {}
                       ^
2 errors generated.

The first error is legit, although it can be better.

The second error doesn't make sense.  Clang shouldn't generate new errors in
the fix itself suggests, as the "fix" (Invoke => revoke) may not be what the
user wants.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 24 13:07:04 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 24 Feb 2011 13:07:04 -0600 (CST)
Subject: [LLVMbugs] [Bug 9313] test failures wrt
	AsmParser/MachO/StackVariable/Scope
In-Reply-To: <bug-9313-206@http.llvm.org/bugs/>
References: <bug-9313-206@http.llvm.org/bugs/>
Message-ID: <20110224190704.1E7262A6C124@llvm.org>

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

Devang Patel <dpatel at apple.com> changed:

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

--- Comment #2 from Devang Patel <dpatel at apple.com> 2011-02-24 13:07:03 CST ---
Agreed. I took freedom to move MC tests also.
r126401.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 24 14:33:31 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 24 Feb 2011 14:33:31 -0600 (CST)
Subject: [LLVMbugs] [Bug 9301] Assertion failed: (Symbol->isUndefined() &&
 "Cannot define a symbol twice!"), function EmitLabel, file MCELFStreamer.cpp,
 line 189.
In-Reply-To: <bug-9301-206@http.llvm.org/bugs/>
References: <bug-9301-206@http.llvm.org/bugs/>
Message-ID: <20110224203331.5366F2A6C12F@llvm.org>

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

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

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

--- Comment #11 from Rafael ?vila de Esp?ndola <rafael.espindola at gmail.com> 2011-02-24 14:33:30 CST ---
Fixed in 126422.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 24 14:46:00 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 24 Feb 2011 14:46:00 -0600 (CST)
Subject: [LLVMbugs] [Bug 9318] New: New c++ search path needed on Fedora 14
Message-ID: <bug-9318-206@http.llvm.org/bugs/>

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

           Summary: New c++ search path needed on Fedora 14
           Product: clang
           Version: 2.8
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: fedorabugmail at yahoo.com
                CC: llvmbugs at cs.uiuc.edu


The file HeaderSearchOptions.h doesn't have c++ include search paths for Fedora
14. I believe the path should be "/usr/include/c++/4.5.1/".


AddGnuCPlusPlusIncludePaths("/usr/include/c++/4.5.1","x86_64-redhat-linux",
"32", "", triple);
AddGnuCPlusPlusIncludePaths("/usr/include/c++/4.5.1","i686-redhat-linux","",
"", triple);


This causes any compile to fail that includes c++ header files:


./lexerData.h:2:10: fatal error: 'string' file not found
#include <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  Thu Feb 24 15:26:55 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 24 Feb 2011 15:26:55 -0600 (CST)
Subject: [LLVMbugs] [Bug 9319] New: Clang++ ignores #pragma completely when
 using "diagnostic push"
Message-ID: <bug-9319-206@http.llvm.org/bugs/>

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

           Summary: Clang++ ignores #pragma completely when using
                    "diagnostic push"
           Product: clang
           Version: 2.8
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: nbigaouette at gmail.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


Created an attachment (id=6231)
 --> (http://llvm.org/bugs/attachment.cgi?id=6231)
clang++ -v -save-temps -Wunreachable-code -c src/Main.cpp -o build/Main.o &>
clang.log

I want to disable "-Wunreachable-code" for some debug output controled by a
global bool. For example:

#include <cstdlib>
#include <iostream>
// const bool verbose = true;
const bool verbose = false;
int main(int argc, char *argv[])
{
    //#pragma GCC diagnostic push
    //#pragma GCC diagnostic ignored "-Wunreachable-code"
    if (verbose)
        std::cout << "First debug output." << std::endl;
    //#pragma GCC diagnostic pop

    if (verbose)
        std::cout << "Second debug output." << std::endl;

    return EXIT_SUCCESS;
}

$ clang++ -Wunreachable-code -c src/Main.cpp -o build/Main.o
src/Main.cpp:18:9: warning: will never be executed [-Wunreachable-code]
        std::cout << "First debug output." << std::endl;
        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
src/Main.cpp:22:9: warning: will never be executed [-Wunreachable-code]         
        std::cout << "Second debug output." << std::endl;
        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2 warnings generated.

Uncommenting the 'ignored "-Wunreachable-code"' pragma suppresses both
warnings. Uncommenting the push and pop pragma will bring the two warnings
back, while it should hide the first only and let the second pass.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 24 17:03:35 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 24 Feb 2011 17:03:35 -0600 (CST)
Subject: [LLVMbugs] [Bug 9314] -Wformat-security false positive with
 __func__ and __PRETTY_FUNCTION__
In-Reply-To: <bug-9314-206@http.llvm.org/bugs/>
References: <bug-9314-206@http.llvm.org/bugs/>
Message-ID: <20110224230335.511332A6C12D@llvm.org>

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

Ted Kremenek <kremenek at apple.com> changed:

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

--- Comment #2 from Ted Kremenek <kremenek at apple.com> 2011-02-24 17:03:34 CST ---
Fixed: r126447

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 24 18:56:03 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 24 Feb 2011 18:56:03 -0600 (CST)
Subject: [LLVMbugs] [Bug 9320] New: clang shouldn't suggest a function that
 obviously doesn't match its prototype
Message-ID: <bug-9320-206@http.llvm.org/bugs/>

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

           Summary: clang shouldn't suggest a function that obviously
                    doesn't match its prototype
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: clattner at apple.com
                CC: llvmbugs at cs.uiuc.edu


$ cat t.cc 
void revoke(const char*x) {}

void Test() {
  Invoke();
}
$ clang t.cc
t.cc:4:3: error: use of undeclared identifier 'Invoke'; did you mean 'revoke'?
  Invoke();
  ^~~~~~
  revoke
t.cc:1:6: note: 'revoke' declared here
void revoke(const char*x) {}
     ^
t.cc:4:10: error: too few arguments to function call, expected 1, have 0
  Invoke();
  ~~~~~~ ^

Clang shouldn't have suggested revoke, it is obviously the wrong thing since it
has clearly-incompatible arguments.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 24 18:56:40 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 24 Feb 2011 18:56:40 -0600 (CST)
Subject: [LLVMbugs] [Bug 9317] Clang shouldn't complain about errors in the
 fix itself suggests
In-Reply-To: <bug-9317-206@http.llvm.org/bugs/>
References: <bug-9317-206@http.llvm.org/bugs/>
Message-ID: <20110225005640.78BC32A6C12D@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #12 from Chris Lattner <clattner at apple.com> 2011-02-24 18:56:39 CST ---
Yep, I agree with Doug.  I filed PR9320 to improve the other case I mentioned.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 24 18:57:04 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 24 Feb 2011 18:57:04 -0600 (CST)
Subject: [LLVMbugs] [Bug 9319] Clang++ ignores #pragma completely when using
 "diagnostic push"
In-Reply-To: <bug-9319-206@http.llvm.org/bugs/>
References: <bug-9319-206@http.llvm.org/bugs/>
Message-ID: <20110225005704.A74772A6C12D@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #6 from Douglas Gregor <dgregor at apple.com> 2011-02-24 18:57:04 CST ---
Fixed in top-of-tree 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  Thu Feb 24 19:14:34 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 24 Feb 2011 19:14:34 -0600 (CST)
Subject: [LLVMbugs] [Bug 9321] New: [autoconf][cmake] "make install" may
 provide similar installation.
Message-ID: <bug-9321-206@http.llvm.org/bugs/>

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

           Summary: [autoconf][cmake] "make install" may provide similar
                    installation.
           Product: new-bugs
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: geek4civic at gmail.com
                CC: llvmbugs at cs.uiuc.edu, echristo at gmail.com,
                    ofv at wanadoo.es


Some files are not installed by both build systems, autoconf and cmake.

eg. on x86_64-linux CentOS5,

[autoconf] lacks on cmake
bin/c-index-test
docs/*
include/clang/Config/config.h.cmake
include/llvm/CMakeLists.txt
include/llvm/Config/config.h.cmake
include/llvm/Config/llvm-config.h.cmake
include/llvm/Support/DataTypes.h.cmake
include/llvm/Support/LICENSE.TXT
lib/clang/2.9/include/nmmintrin.h
lib/clang/2.9/include/varargs.h
lib/clang/2.9/include/wmmintrin.h
lib/clang/2.9/include/x86intrin.h
lib/libclang.a
lib/libCompilerDriver.a
lib/libEnhancedDisassembly.so
lib/libLTO.a
lib/libLTO.so
lib/libUnitTestMain.a
lib/profile_rt.so
share/man/man1/*

[cmake] lacks on autoconf
include/clang/Basic/*.td
include/clang/Driver/*.td
lib/libgtest.a
lib/libgtest_main.a
share/llvm/cmake/*


I think they should be installed as below;

include/llvm/Support/LICENSE.TXT
lib/clang/2.9/include/*.h
lib/libclang.a
lib/libLTO.a
lib/libLTO.so
share/llvm/cmake/*

Especially "clang standalone build with cmake" needs $(PREFIX)/share/llvm/cmake
stuff.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 24 20:23:33 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 24 Feb 2011 20:23:33 -0600 (CST)
Subject: [LLVMbugs] [Bug 9322] New: clang doesn't DCE dead switch cases
 (breaks Linux kernel at -O0)
Message-ID: <bug-9322-206@http.llvm.org/bugs/>

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

           Summary: clang doesn't DCE dead switch cases (breaks Linux
                    kernel at -O0)
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: LLVM Codegen
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: sharparrow1 at yahoo.com
                CC: llvmbugs at cs.uiuc.edu


Testcase (reduced from the raw_smp_processor_id macro in the kernel):
void a() {
  switch (4) {
    case 1:
      asm("movb $0, %%eax" : : );
      break;
    case 4:
      asm("movl $0, %%eax" : : );
      break;
  } 
}

gcc compiles this just fine at all optimization levels; clang complains because
the movb isn't valid.  Arguably, this code is abusive, but it doesn't seem very
hard to support.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 24 22:19:43 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 24 Feb 2011 22:19:43 -0600 (CST)
Subject: [LLVMbugs] [Bug 9303] Assertion failed:
 (Dest.getScopeDepth().encloses(EStack.getInnermostNormalCleanup()) &&
 "stale jump destination"), function EmitBranchThroughCleanup, file
In-Reply-To: <bug-9303-206@http.llvm.org/bugs/>
References: <bug-9303-206@http.llvm.org/bugs/>
Message-ID: <20110225041943.A965B2A6C12D@llvm.org>

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

John McCall <rjmccall at apple.com> changed:

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

--- Comment #3 from John McCall <rjmccall at apple.com> 2011-02-24 22:19:43 CST ---
Fixed in r126472.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 24 22:31:14 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 24 Feb 2011 22:31:14 -0600 (CST)
Subject: [LLVMbugs] [Bug 9316] block scope extern function declaration not
 receiving external linkage
In-Reply-To: <bug-9316-206@http.llvm.org/bugs/>
References: <bug-9316-206@http.llvm.org/bugs/>
Message-ID: <20110225043114.478242A6C12D@llvm.org>

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

Chandler Carruth <chandlerc at gmail.com> changed:

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

--- Comment #2 from Chandler Carruth <chandlerc at gmail.com> 2011-02-24 22:31:13 CST ---
Fixed in r126453.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 24 22:32:53 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 24 Feb 2011 22:32:53 -0600 (CST)
Subject: [LLVMbugs] [Bug 9323] New: Elided undefined copy constructors still
 marked as used, and warned when internal
Message-ID: <bug-9323-206@http.llvm.org/bugs/>

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

           Summary: Elided undefined copy constructors still marked as
                    used, and warned when internal
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: chandlerc at gmail.com
                CC: llvmbugs at cs.uiuc.edu


% cat x.cc                      
namespace {
  struct Uncopyable {
    Uncopyable() {}
  private:
    Uncopyable(const Uncopyable&);
  };
}
void f(const Uncopyable&);
void test5() {
  Uncopyable x;
  f(x);
};

% ./bin/clang -fsyntax-only x.cc
x.cc:8:6: warning: function 'f' has internal linkage but is not defined
void f(const Uncopyable&);
     ^
x.cc:11:3: note: used here
  f(x);
  ^
1 warning generated.


We support this pattern to cope with silly C++ code w.r.t. the standard
requirement of an accessible copy ctor, we should cope with it when warning on
internal linkage 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  Thu Feb 24 23:12:54 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 24 Feb 2011 23:12:54 -0600 (CST)
Subject: [LLVMbugs] [Bug 9324] New: Assertion `isVirtualRegister(Reg) &&
 "Not a virtual register"' failed.
Message-ID: <bug-9324-206@http.llvm.org/bugs/>

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

           Summary: Assertion `isVirtualRegister(Reg) && "Not a virtual
                    register"' failed.
           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


[regehr at gamow tmp004]$ clang -v
clang version 2.9 (trunk 126412)
Target: x86_64-unknown-linux-gnu
Thread model: posix

[regehr at gamow tmp004]$ clang -O small.c

clang:
/uusoc/exports/scratch/regehr/z/compiler-build/llvm-r126412/include/llvm/Target/TargetRegisterInfo.h:352:
static unsigned int llvm::TargetRegisterInfo::virtReg2Index(unsigned int):
Assertion `isVirtualRegister(Reg) && "Not a virtual register"' failed.
0  clang           0x000000000184068f
1  clang           0x0000000001842902
2  libpthread.so.0 0x00007fd1e1816190
3  libc.so.6       0x00007fd1e0b1b4b5 gsignal + 53
4  libc.so.6       0x00007fd1e0b1ef50 abort + 384
5  libc.so.6       0x00007fd1e0b14481 __assert_fail + 241
6  clang           0x00000000012d7c51
llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) + 5473
7  clang           0x00000000012d7f42
llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) + 594
8  clang           0x00000000017882cd
llvm::FPPassManager::runOnFunction(llvm::Function&) + 557
9  clang           0x00000000017883cb
llvm::FPPassManager::runOnModule(llvm::Module&) + 75
10 clang           0x0000000001789af4
llvm::MPPassManager::runOnModule(llvm::Module&) + 500
11 clang           0x0000000001789c67 llvm::PassManagerImpl::run(llvm::Module&)
+ 167
12 clang           0x000000000081cf48
clang::EmitBackendOutput(clang::Diagnostic&, clang::CodeGenOptions const&,
clang::TargetOptions const&, llvm::Module*, clang::BackendAction,
llvm::raw_ostream*) + 1720
13 clang           0x0000000000819fdb
clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) + 251
14 clang           0x0000000000939683 clang::ParseAST(clang::Sema&, bool) + 275
15 clang           0x0000000000819784 clang::CodeGenAction::ExecuteAction() +
68
16 clang           0x000000000070224b
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 347
17 clang           0x00000000006d98ac
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1276
18 clang           0x00000000006d1064 cc1_main(char const**, char const**, char
const*, void*) + 500
19 clang           0x00000000006d89ed main + 4685
20 libc.so.6       0x00007fd1e0b06abd __libc_start_main + 253
21 clang           0x00000000006cf819
Stack dump:
0.    Program arguments:
/uusoc/exports/scratch/regehr/z/compiler-install/llvm-gcc-r126412-install/bin/clang
-cc1 -triple x86_64-unknown-linux-gnu -emit-obj -disable-free -main-file-name
small.c -mrelocation-model static -mdisable-fp-elim -masm-verbose
-mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version
2.20 -momit-leaf-frame-pointer -resource-dir
/uusoc/exports/scratch/regehr/z/compiler-install/llvm-gcc-r126412-install/bin/../lib/clang/2.9
-O2 -ferror-limit 19 -fmessage-length 190 -fgnu-runtime
-fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-fCvymt.o -x c small.c 
1.    <eof> parser at end of file
2.    Code generation
3.    Running pass 'Function Pass Manager' on module 'small.c'.
4.    Running pass 'X86 DAG->DAG Instruction Selection' on function '@func_37'
clang: error: unable to execute command: Aborted
clang: error: clang frontend command failed due to signal 1 (use -v to see
invocation)

[regehr at gamow tmp004]$ cat small.c


static unsigned char
foo (short si1, unsigned char si2)
{
  return 0;
}

struct S1 {
  signed f0;
  const signed f1;
  signed f3;
};

struct S2 {
  struct S1 f1;
};

struct S3 {
  unsigned char f0;
};

struct S5 {
  unsigned char f1;
};

struct S3 g_19 = {
};

struct S5 g_254 = {
};

struct S2 g_259 = {
};

unsigned char ** func_37 (int * p_38)
{
  unsigned char l;
  unsigned char *l_801 = &g_254.f1;
  {
    if (foo (~0, 0))
      {
      }
    else
      {
    if (g_259.f1.f3)
      goto lbl_920;
      }
  }
lbl_919:*l_801 ^= 1;
  for (; ; l += 1)
    for (g_19.f0 = 0; g_19.f0 < 1; g_19.f0 += 1)
    lbl_920:if (g_259.f1.f0)
    goto lbl_919;
}

int main (int argc, char *argv[])
{
  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  Fri Feb 25 02:53:30 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 25 Feb 2011 02:53:30 -0600 (CST)
Subject: [LLVMbugs] [Bug 9323] Elided undefined copy constructors still
 marked as used, and warned when internal
In-Reply-To: <bug-9323-206@http.llvm.org/bugs/>
References: <bug-9323-206@http.llvm.org/bugs/>
Message-ID: <20110225085330.6EDCE2A6C12E@llvm.org>

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

Chandler Carruth <chandlerc at gmail.com> changed:

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

--- Comment #2 from Chandler Carruth <chandlerc at gmail.com> 2011-02-25 02:53:30 CST ---
Fixed in r126480, but with a bit of a hack that we'll have to revisit. FIXME
and test case in place though, the PR is closed.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 25 06:41:27 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 25 Feb 2011 06:41:27 -0600 (CST)
Subject: [LLVMbugs] [Bug 8685] [MC assembler] does not support square
	bracket notation
In-Reply-To: <bug-8685-206@http.llvm.org/bugs/>
References: <bug-8685-206@http.llvm.org/bugs/>
Message-ID: <20110225124127.169EA2A6C12F@llvm.org>

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

J?rg Sonnenberger <joerg at NetBSD.org> changed:

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

--- Comment #10 from J?rg Sonnenberger <joerg at NetBSD.org> 2011-02-25 06:41:26 CST ---
Fixed again in r126443.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 25 09:20:43 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 25 Feb 2011 09:20:43 -0600 (CST)
Subject: [LLVMbugs] [Bug 8350] Clang does not produce symbols for typeinfo
In-Reply-To: <bug-8350-206@http.llvm.org/bugs/>
References: <bug-8350-206@http.llvm.org/bugs/>
Message-ID: <20110225152043.AC6A12A6C12F@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #8 from Douglas Gregor <dgregor at apple.com> 2011-02-25 09:20:43 CST ---
Yay!

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 25 10:43:33 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 25 Feb 2011 10:43:33 -0600 (CST)
Subject: [LLVMbugs] [Bug 9325] New: virtual methods of template class not
 instanciated under specific conditions
Message-ID: <bug-9325-206@http.llvm.org/bugs/>

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

           Summary: virtual methods of template class not instanciated
                    under specific conditions
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: frrrwww at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=6234)
 --> (http://llvm.org/bugs/attachment.cgi?id=6234)
test case as a file for convenience

mawww at bonheur ~/tmp/clang $ cat test.cpp 
template<typename T>
class Target
{
public:
    virtual int Value() const
    {
        return 0;
    }
};

template<typename T>
struct Provider
{
    static Target<T> Instance;
};

template<typename T>
Target<T> Provider<T>::Instance;

int main()
{
    Target<int>* traits = &Provider<int>::Instance;
}
mawww at bonheur ~/tmp/clang $ clang++ test.cpp 
/tmp/cc-QPIfS9.o:(.rodata._ZTV6TargetIiE[_ZTV6TargetIiE]+0x10): undefined
reference to `Target<int>::Value() const'
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  Fri Feb 25 12:43:55 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 25 Feb 2011 12:43:55 -0600 (CST)
Subject: [LLVMbugs] [Bug 9326] New: libc++ input streaming fails on out of
 bounds types of long or bigger
Message-ID: <bug-9326-206@http.llvm.org/bugs/>

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

           Summary: libc++ input streaming fails on out of bounds types of
                    long or bigger
           Product: libc++
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: All Bugs
        AssignedTo: hhinnant at apple.com
        ReportedBy: chris at bubblescope.net
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=6236)
 --> (http://llvm.org/bugs/attachment.cgi?id=6236)
Test case for testing bounds of parsing of integer types.

The attached test case tries parsing in, for various integral types, values one
bigger and one smaller than the type supports. 

This works correctly for short and int, but in libc++ fails for long and larger
types. 

This code works correctly with clang using libstdc++.

I give permission for the attached file, or a modified version of it, to be
used in the libc++ testsuite, if you want 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 Feb 25 12:49:23 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 25 Feb 2011 12:49:23 -0600 (CST)
Subject: [LLVMbugs] [Bug 9327] New: test failures wrt MC/ELF/bracket-exprs.s
Message-ID: <bug-9327-206@http.llvm.org/bugs/>

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

           Summary: test failures wrt MC/ELF/bracket-exprs.s
           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: impulze at impulze.org
                CC: llvmbugs at cs.uiuc.edu


Hey there, I'm facing new test failures with r126497, configured with
--enable-targets=x86 on:
Linux istari 2.6.38-rc4-istari #21 SMP Sun Feb 13 20:15:04 CET 2011 x86_64
GNU/Linux

make -j4 check
llvm[0]: Running test suite
make[1]: Entering directory
`/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/test'
Making a new site.exp file...
Making LLVM unittest 'lit.site.cfg' file...
Making LLVM 'lit.site.cfg' file...
( ulimit -t 600 ; ulimit -d 512000 ; ulimit -m 512000 ; ulimit -v 1024000 ; \
  /var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/utils/lit/lit.py -s -v
. )
FAIL: LLVM :: MC/ELF/bracket-exprs.s (3988 of 5828)
******************** TEST 'LLVM :: MC/ELF/bracket-exprs.s' FAILED
********************
Script:
--
/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/Release+Asserts/bin/llvm-mc
-triple i386-unknown-unknown
/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/test/MC/ELF/bracket-exprs.s
|
/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/Release+Asserts/bin/FileCheck
/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/test/MC/ELF/bracket-exprs.s
/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/Release+Asserts/bin/llvm-mc
-triple arm-unknown-linux
/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/test/MC/ELF/bracket-exprs.s
|
/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/Release+Asserts/bin/FileCheck
/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/test/MC/ELF/bracket-exprs.s
--
Exit Code: 1
Command Output (stderr):
--
/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/Release+Asserts/bin/llvm-mc:
error: unable to get target for 'arm-unknown-linux', see --version and
--triple.
FileCheck error: '-' is empty.
--

********************
Testing Time: 184.27s
********************
Failing Tests (1):
    LLVM :: MC/ELF/bracket-exprs.s

  Expected Passes    : 3887
  Expected Failures  : 16
  Unsupported Tests  : 1924
  Unexpected Failures: 1
make[1]: Leaving directory
`/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/test'
make[1]: *** [check-local-lit] Error 1
make: *** [check] 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 Feb 25 13:06:46 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 25 Feb 2011 13:06:46 -0600 (CST)
Subject: [LLVMbugs] [Bug 9327] test failures wrt MC/ELF/bracket-exprs.s
In-Reply-To: <bug-9327-206@http.llvm.org/bugs/>
References: <bug-9327-206@http.llvm.org/bugs/>
Message-ID: <20110225190646.6448C2A6C124@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #1 from Chris Lattner <clattner at apple.com> 2011-02-25 13:06:46 CST ---
Fixed in r126500, 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 Feb 25 13:53:01 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 25 Feb 2011 13:53:01 -0600 (CST)
Subject: [LLVMbugs] [Bug 9326] libc++ input streaming is incorrect for out
 of bounds values with long and long long
In-Reply-To: <bug-9326-206@http.llvm.org/bugs/>
References: <bug-9326-206@http.llvm.org/bugs/>
Message-ID: <20110225195301.D4EAB2A6C12C@llvm.org>

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

Howard Hinnant <hhinnant at apple.com> changed:

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

--- Comment #1 from Howard Hinnant <hhinnant at apple.com> 2011-02-25 13:53:01 CST ---
Committed revision 126504.

Thanks Chris.

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

From bugzilla-daemon at llvm.org  Fri Feb 25 14:20:45 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 25 Feb 2011 14:20:45 -0600 (CST)
Subject: [LLVMbugs] [Bug 9328] New: Assertion `chunkIndex + 1 < e && "No
 DeclaratorChunk for the return type?"' failed.
Message-ID: <bug-9328-206@http.llvm.org/bugs/>

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

           Summary: Assertion `chunkIndex + 1 < e && "No DeclaratorChunk
                    for the return type?"' failed.
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: grzegorz.dabrowski at gmail.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


$ cat assert.cpp 
typedef char *PCHAR;
class Test 
{
    const PCHAR GetName() {}
};

$ clang++ assert.cpp
clang: SemaType.cpp:1733: clang::TypeSourceInfo*
clang::Sema::GetTypeForDeclarator(clang::Declarator&, clang::Scope*,
clang::TagDecl**, bool): Assertion `chunkIndex + 1 < e && "No DeclaratorChunk
for the return 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  Fri Feb 25 19:52:41 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 25 Feb 2011 19:52:41 -0600 (CST)
Subject: [LLVMbugs] [Bug 9329] New: llc crashes when given invalid command
 line arguments
Message-ID: <bug-9329-206@http.llvm.org/bugs/>

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

           Summary: llc crashes when given invalid command line arguments
           Product: new-bugs
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: matt at pharr.org
                CC: llvmbugs at cs.uiuc.edu


I accidentally tried to add a CPU attribute as part of the -mcpu argument
rather than using -mattr, and with the attached trivial program, got the
following crash:

% llc -mcpu=core2+sse41 -march=x86-64 bugpoint-reduced-simplified.bc
'core2+sse41' is not a recognized processor for this target (ignoring
processor)
Assertion failed: (TLI.isTypeLegal(Op.getValueType()) && "Intrinsic uses a
non-legal type?"), function visitTargetIntrinsic, file SelectionDAGBuilder.cpp,
line 3149.
0  llc               0x0000000100b411b2
llvm::PrettyStackTraceString::~PrettyStackTraceString() + 11298
1  llc               0x0000000100b42003
llvm::PrettyStackTraceString::~PrettyStackTraceString() + 14963
2  libSystem.B.dylib 0x00007fff8385567a _sigtramp + 26
3  libSystem.B.dylib 0x0000000101075000 _sigtramp + 2105670048
4  llc               0x0000000100021a32
std::vector<llvm::PassRegistrationListener*,
std::allocator<llvm::PassRegistrationListener*>
>::_M_insert_aux(__gnu_cxx::__normal_iterator<llvm::PassRegistrationListener**,
std::vector<llvm::PassRegistrationListener*,
std::allocator<llvm::PassRegistrationListener*> > >,
llvm::PassRegistrationListener* const&) + 3394
5  llc               0x00000001005f99af llvm::APInt::getHighBitsSet(unsigned
int, unsigned int) + 179023
6  llc               0x00000001005fa510 llvm::APInt::getHighBitsSet(unsigned
int, unsigned int) + 181936
7  llc               0x0000000100602e81 llvm::APInt::getHighBitsSet(unsigned
int, unsigned int) + 217121
8  llc               0x00000001005e317d llvm::APInt::getHighBitsSet(unsigned
int, unsigned int) + 86813
9  llc               0x0000000100618703 llvm::APInt::getHighBitsSet(unsigned
int, unsigned int) + 305315
10 llc               0x000000010062cb38
llvm::TargetLowering::getNumRegisters(llvm::LLVMContext&, llvm::EVT) const +
58696
11 llc               0x000000010062d231
llvm::TargetLowering::getNumRegisters(llvm::LLVMContext&, llvm::EVT) const +
60481
12 llc               0x000000010062de5a
llvm::TargetLowering::getNumRegisters(llvm::LLVMContext&, llvm::EVT) const +
63594
13 llc               0x000000010073e343
llvm::MachineFunctionAnalysis::getPassName() const + 627
14 llc               0x0000000100a750b0 llvm::BasicBlockPass::~BasicBlockPass()
+ 32240
15 llc               0x0000000100a751cb llvm::BasicBlockPass::~BasicBlockPass()
+ 32523
16 llc               0x0000000100a76d4f llvm::BasicBlockPass::~BasicBlockPass()
+ 39567
17 llc               0x0000000100a77043 llvm::BasicBlockPass::~BasicBlockPass()
+ 40323
18 llc               0x0000000100a7711d llvm::BasicBlockPass::~BasicBlockPass()
+ 40541
19 llc               0x00000001000240ff
std::vector<llvm::PassRegistrationListener*,
std::allocator<llvm::PassRegistrationListener*>
>::_M_insert_aux(__gnu_cxx::__normal_iterator<llvm::PassRegistrationListener**,
std::vector<llvm::PassRegistrationListener*,
std::allocator<llvm::PassRegistrationListener*> > >,
llvm::PassRegistrationListener* const&) + 13327
20 llc               0x0000000100022964
std::vector<llvm::PassRegistrationListener*,
std::allocator<llvm::PassRegistrationListener*>
>::_M_insert_aux(__gnu_cxx::__normal_iterator<llvm::PassRegistrationListener**,
std::vector<llvm::PassRegistrationListener*,
std::allocator<llvm::PassRegistrationListener*> > >,
llvm::PassRegistrationListener* const&) + 7284
Stack dump:
0.    Program arguments: llc -mcpu=core2+sse41 -march=x86-64
bugpoint-reduced-simplified.bc 
1.    Running pass 'Function Pass Manager' on module
'bugpoint-reduced-simplified.bc'.
2.    Running pass 'X86 DAG->DAG Instruction Selection' on function '@simple'
[1]    74409 illegal hardware instruction  llc -mcpu=core2+sse41 -march=x86-64
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  Fri Feb 25 20:48:46 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 25 Feb 2011 20:48:46 -0600 (CST)
Subject: [LLVMbugs] [Bug 9330] New: [MC]
Message-ID: <bug-9330-206@http.llvm.org/bugs/>

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

           Summary: [MC]
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: X86
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: joerg at NetBSD.org
                CC: llvmbugs at cs.uiuc.edu


Correct behavior with llvm-mc -filetype=obj -triple i386-unknown-unknown:

        orl $-1, 1

Encoding:

   0:    83 0d 01 00 00 00 ff     orl    $0xffffffff,0x1

Wrong behavior:

        orl $-1, foo

Encoding:

   0:    81 0c 25 00 00 00 00     orl    $0xffffffff,0x0
   7:    ff ff ff ff

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 25 22:49:29 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 25 Feb 2011 22:49:29 -0600 (CST)
Subject: [LLVMbugs] [Bug 9331] New: Assertion `(KnownZero2 & KnownOne2) == 0
 && "Bits known to be one AND zero\ ?"' failed.
Message-ID: <bug-9331-206@http.llvm.org/bugs/>

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

           Summary: Assertion `(KnownZero2 & KnownOne2) == 0 && "Bits
                    known to be one AND zero\ ?"' failed.
           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


This is the same symptom as (fixed) PR9112.

[regehr at gamow tmp005]$ clang -v

clang version 2.9 (trunk 126412)
Target: x86_64-unknown-linux-gnu
Thread model: posix

[regehr at gamow tmp005]$ clang -c -w -O small.c

clang: ValueTracking.cpp:180: void llvm::ComputeMaskedBits(llvm::Value*, const
llvm::APInt&, llvm::APInt&, llvm::APInt&, const llvm::TargetData*, unsigned
int): Assertion `(KnownZero2 & KnownOne2) == 0 && "Bits known to be one AND
zero?"' failed.
0  clang           0x000000000184068f
1  clang           0x0000000001842902
2  libpthread.so.0 0x00007f5692ecd190
3  libc.so.6       0x00007f56921d24b5 gsignal + 53
4  libc.so.6       0x00007f56921d5f50 abort + 384
5  libc.so.6       0x00007f56921cb481 __assert_fail + 241
6  clang           0x00000000016cd45c llvm::ComputeMaskedBits(llvm::Value*,
llvm::APInt const&, llvm::APInt&, llvm::APInt&, llvm::TargetData const*,
unsigned int) + 7596
7  clang           0x00000000016ce052 llvm::ComputeMaskedBits(llvm::Value*,
llvm::APInt const&, llvm::APInt&, llvm::APInt&, llvm::TargetData const*,
unsigned int) + 10658
8  clang           0x00000000016d0c6e llvm::isKnownNonZero(llvm::Value*,
llvm::TargetData const*, unsigned int) + 622
9  clang           0x0000000001661c16
10 clang           0x000000000153158a
11 clang           0x00000000015317da
12 clang           0x0000000001533a4d
13 clang           0x000000000153445d
14 clang           0x00000000017882cd
llvm::FPPassManager::runOnFunction(llvm::Function&) + 557
15 clang           0x0000000001635fdb
16 clang           0x0000000001636735
17 clang           0x0000000001789af4
llvm::MPPassManager::runOnModule(llvm::Module&) + 500
18 clang           0x0000000001789c67 llvm::PassManagerImpl::run(llvm::Module&)
+ 167
19 clang           0x000000000081cee9
clang::EmitBackendOutput(clang::Diagnostic&, clang::CodeGenOptions const&,
clang::TargetOptions const&, llvm::Module*, clang::BackendAction,
llvm::raw_ostream*) + 1625
20 clang           0x0000000000819fdb
clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) + 251
21 clang           0x0000000000939683 clang::ParseAST(clang::Sema&, bool) + 275
22 clang           0x0000000000819784 clang::CodeGenAction::ExecuteAction() +
68
23 clang           0x000000000070224b
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 347
24 clang           0x00000000006d98ac
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1276
25 clang           0x00000000006d1064 cc1_main(char const**, char const**, char
const*, void*) + 500
26 clang           0x00000000006d89ed main + 4685
27 libc.so.6       0x00007f56921bdabd __libc_start_main + 253
28 clang           0x00000000006cf819
Stack dump:
0.    Program arguments:
/uusoc/exports/scratch/regehr/z/compiler-install/llvm-gcc-r126412-install/bin/clang
-cc1 -triple x86_64-unknown-linux-gnu -emit-obj -disable-free -main-file-name
small.c -mrelocation-model static -mdisable-fp-elim -masm-verbose
-mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version
2.20 -momit-leaf-frame-pointer -resource-dir
/uusoc/exports/scratch/regehr/z/compiler-install/llvm-gcc-r126412-install/bin/../lib/clang/2.9
-O2 -w -ferror-limit 19 -fmessage-length 80 -fgnu-runtime
-fdiagnostics-show-option -fcolor-diagnostics -o small.o -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'
clang: error: unable to execute command: Aborted
clang: error: clang frontend command failed due to signal 1 (use -v to see
invocation)

[regehr at gamow tmp005]$ cat small.c


typedef signed char int8_t;
typedef int int32_t;
typedef unsigned char uint8_t;
typedef unsigned int uint32_t;
typedef unsigned long int uint64_t;
static uint8_t
safe_lshift_func_int8_t_s_u (int8_t left, unsigned int right)
{
  return left || right || left >> right ? : left << right;
}

static uint8_t
safe_div_func_uint32_t_u_u (uint32_t ui1, uint8_t ui2)
{
  return ui1 - ui2;
}

static uint64_t
safe_mod_func_uint64_t_u_u (uint64_t ui1, uint64_t ui2)
{
  return ui2 ? : (ui1 / ui2);
}

uint8_t g_26;
uint8_t *volatile g = &g_26;
uint8_t g_64;
uint8_t g_124;
uint8_t *g_132;
uint8_t **g_131 = &g_132;
int32_t func_68 (uint32_t p_69, int32_t p_70);
uint8_t *
func (int32_t ** p_43, uint8_t p_44, uint8_t * const *p_45)
{
  uint32_t l_50;
  uint8_t l_326;
  uint8_t **l_344 = &g_132;
  int32_t l_477[2][3][9];
  if (safe_lshift_func_int8_t_s_u (safe_div_func_uint32_t_u_u (l_50, 0), 0))
    {
    }
  else
    for (0; 1; g += 0)
      for (l_326 = 1; l_326; l_326 += 1)
    {
      if (func_68 (p_44, 0))
        {
          for (p_44 = 0; 0; )
        {
        }
          for (g_64 = 1; g_64; g += 1)
        return 0;
        }
    lbl_465:;
      if (g_64)
        goto lbl_465;
      l_477[1][2][4] &= safe_mod_func_uint64_t_u_u (p_44 ^ 1, p_44)
        || **g_131 == &g != &l_344;
    }
  uint8_t *l_128 = &g_124;
  safe_div_func_uint32_t_u_u (1, 1);
  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  Fri Feb 25 23:21:55 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 25 Feb 2011 23:21:55 -0600 (CST)
Subject: [LLVMbugs] [Bug 9332] New: 5 False positive in "Dereference of null
	pointer"
Message-ID: <bug-9332-206@http.llvm.org/bugs/>

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

           Summary: 5 False positive in "Dereference of null pointer"
           Product: clang
           Version: trunk
          Platform: Sun
        OS/Version: OpenBSD
            Status: NEW
          Severity: normal
          Priority: P
         Component: Static Analyzer
        AssignedTo: kremenek at apple.com
        ReportedBy: amitkulz at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=6242)
 --> (http://llvm.org/bugs/attachment.cgi?id=6242)
tcp_input.c null deref 1

clang version 2.9 (trunk 126522)

AMD64, OpenBSD current

5 False positives in

http://www.openbsd.org/cgi-bin/cvsweb/~checkout~/src/sys/netinet/tcp_input.c?rev=1.240;content-type=text%2Fplain


in function syn_cache_respond()

Basically, once sc->sc_src.sa.sa_family is selected to be either case AF_INET
or case AF_INET6, the other case "ip header" variables which are initially
uninitialized are found to be null.

initially
struct ip *ip = NULL;
struct ip6_hdr *ip6 = NULL;

Clang arbitrarily switches case (i.e first it takes case IP4 and then
***still*** inside function it takes case IPv6,) inside this function
syn_cache_respond(), and finds the other variables as deference to null
pointers i.e if initially it was case AF_INET, ip6 is found to be NULL.

either case AF_INET or case AF_INET6 is impossible to switch once you have
entered the atomic function syn_cache_respond().

Please look at attachment to easily figure out the problem, looking at the
switch(sc->sc_src.sa.sa_family). There are 4 more attachments all in this same
function. Can't add multiple attachments?

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 25 23:29:01 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 25 Feb 2011 23:29:01 -0600 (CST)
Subject: [LLVMbugs] [Bug 9332] 5 False positive in "Dereference of null
	pointer"
In-Reply-To: <bug-9332-206@http.llvm.org/bugs/>
References: <bug-9332-206@http.llvm.org/bugs/>
Message-ID: <20110226052901.41EBF2A6C12D@llvm.org>

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

Amit Kulkarni <amitkulz at gmail.com> changed:

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

--- Comment #2 from Amit Kulkarni <amitkulz at gmail.com> 2011-02-25 23:29:01 CST ---


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

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 25 23:45:08 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 25 Feb 2011 23:45:08 -0600 (CST)
Subject: [LLVMbugs] [Bug 9332] 5 False positive in "Dereference of null
	pointer"
In-Reply-To: <bug-9332-206@http.llvm.org/bugs/>
References: <bug-9332-206@http.llvm.org/bugs/>
Message-ID: <20110226054508.C0BCC2A6C12D@llvm.org>

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

Ted Kremenek <kremenek at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
                 CC|                            |kremenek at apple.com
         Resolution|DUPLICATE                   |

--- Comment #3 from Ted Kremenek <kremenek at apple.com> 2011-02-25 23:45:08 CST ---
Why was this marked a duplicate?  Please don't dup static analyzer radars
without justification or diagnosis.  While false positives may seem similar,
they can often be from different causes.  If there is reason to suspect this is
the same issue, that should be documented in the PR.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 26 02:07:29 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 26 Feb 2011 02:07:29 -0600 (CST)
Subject: [LLVMbugs] [Bug 9307] [TBAA] clang-2.9 miscompiles FFmpeg's VP8
	decoder
In-Reply-To: <bug-9307-206@http.llvm.org/bugs/>
References: <bug-9307-206@http.llvm.org/bugs/>
Message-ID: <20110226080729.D05172A6C12D@llvm.org>

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

John McCall <rjmccall at apple.com> changed:

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

--- Comment #13 from John McCall <rjmccall at apple.com> 2011-02-26 02:07:28 CST ---
Fixed in r126540.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 26 02:27:36 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 26 Feb 2011 02:27:36 -0600 (CST)
Subject: [LLVMbugs] [Bug 9262] [Linux Kernel] ExprConstant.cpp:2654:
 llvm::APSInt clang::Expr::EvaluateAsInt(const clang::ASTContext&) const:
 Assertion `Result && "Could not evaluate expression"' failed.
In-Reply-To: <bug-9262-206@http.llvm.org/bugs/>
References: <bug-9262-206@http.llvm.org/bugs/>
Message-ID: <20110226082736.5BDE82A6C124@llvm.org>

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

John McCall <rjmccall at apple.com> changed:

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

--- Comment #5 from John McCall <rjmccall at apple.com> 2011-02-26 02:27:35 CST ---
Fixed in r126541

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 26 02:40:57 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 26 Feb 2011 02:40:57 -0600 (CST)
Subject: [LLVMbugs] [Bug 9256] clang: support -fno-strict-overflow
In-Reply-To: <bug-9256-206@http.llvm.org/bugs/>
References: <bug-9256-206@http.llvm.org/bugs/>
Message-ID: <20110226084057.DCF332A6C12C@llvm.org>

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|INVALID                     |
            Summary|clang: support for kernel   |clang: support
                   |code model: pointer         |-fno-strict-overflow
                   |arithmetic that overflows   |
                   |is not impossible!          |

--- Comment #3 from T?r?k Edwin <edwintorok at gmail.com> 2011-02-26 02:40:57 CST ---
(In reply to comment #2)
> Right, they should build with -fwrapv or (better yet) do the computation with
> an unsigned value.

They use -fno-strict-overflow:

# disable invalid "can't wrap" optimizations for signed / pointers
KBUILD_CFLAGS   += $(call cc-option,-fno-strict-overflow)

clang: warning: argument unused during compilation: '-fno-strict-overflow'

Should clang translate -fno-strict-overflow to -fwrapv (if it supports that)?

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 26 03:07:03 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 26 Feb 2011 03:07:03 -0600 (CST)
Subject: [LLVMbugs] [Bug 9333] New: scoped enum values can't be compared
Message-ID: <bug-9333-206@http.llvm.org/bugs/>

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

           Summary: scoped enum values can't be compared
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++0x
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: chris at bubblescope.net
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


The implementation of scoped enums appears incomplete. In particular, values of
scoped enums do not appear comparable. Consider the following code:

int main(void)
{
  enum class scoped_enum { yes, no, maybe };
  scoped_enum e = scoped_enum::yes;
  e == scoped_enum::no;
}

I don't mind the feature being incomplete (assuming I'm correct this code
doesn't work), but it's a little annoying that __has_feature(cxx_strong_enums)
returns true, when the feature is basically not 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 Feb 26 04:09:39 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 26 Feb 2011 04:09:39 -0600 (CST)
Subject: [LLVMbugs] [Bug 9334] New: Not overriding TargetMachine virtual
 methods causes clang to crash without indication why
Message-ID: <bug-9334-206@http.llvm.org/bugs/>

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

           Summary: Not overriding TargetMachine virtual methods causes
                    clang to crash without indication why
           Product: libraries
           Version: trunk
          Platform: Macintosh
               URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-Februa
                    ry/038174.html
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: Target Description Classes
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: andreas.faerber at web.de
                CC: llvmbugs at cs.uiuc.edu


Apparently, not overriding llvm::LLVMTargetMachine methods like getFrameInfo()
and getSelectionDAGInfo() caused clang to crash with an error message like
this:

$ Debug+Asserts/bin/clang -ccc-host-triple stm8-unknown-elf ../hello.c -S -o
../hello.s
0  clang             0x0168c4f0 llvm::SearchForAddressOfSpecialSymbol(char
const*) + 448
1  clang             0x0168cc8c llvm::sys::RunInterruptHandlers() + 456
2  libSystem.B.dylib 0x9422d9fc _sigtramp + 68
3  clang             0x0159692c std::_Rb_tree<void const*, std::pair<void
const* const, llvm::Pass*>, std::_Select1st<std::pair<void const* const,
llvm::Pass*> >, std::less<void const*>, std::allocator<std::pair<void const*
const, llvm::Pass*> > >::_M_insert(std::_Rb_tree_node_base*,
std::_Rb_tree_node_base*, std::pair<void const* const, llvm::Pass*> const&) +
132
4  clang             0x0f1c1cc0 std::_Rb_tree<void const*, std::pair<void
const* const, llvm::Pass*>, std::_Select1st<std::pair<void const* const,
llvm::Pass*> >, std::less<void const*>, std::allocator<std::pair<void const*
const, llvm::Pass*> > >::_M_insert(std::_Rb_tree_node_base*,
std::_Rb_tree_node_base*, std::pair<void const* const, llvm::Pass*> const&) +
230863896
Stack dump:
0.    Program arguments:
/Users/andreas/STM8S-Discovery/llvm-stm8/Debug+Asserts/bin/clang -cc1 -triple
stm8-unknown-elf -S -disable-free -main-file-name hello.c -mrelocation-model
static -mdisable-fp-elim -mconstructor-aliases -target-linker-version 85.2.1
-momit-leaf-frame-pointer -resource-dir
/Users/andreas/STM8S-Discovery/llvm-stm8/Debug+Asserts/bin/../lib/clang/2.9
-ferror-limit 19 -fmessage-length 274 -fgnu-runtime -fdiagnostics-show-option
-fcolor-diagnostics -o ../hello.s -x c ../hello.c
1.    <eof> parser at end of file
clang: error: unable to execute command: Bus error
clang: error: clang frontend command failed due to signal 1 (use -v to see
invocation)

Expected behavior:

This should either not compile at all or trigger an assert() indicating what
needs to be implemented.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 26 05:35:41 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 26 Feb 2011 05:35:41 -0600 (CST)
Subject: [LLVMbugs] [Bug 9335] New: Overeager setting of eof()
Message-ID: <bug-9335-206@http.llvm.org/bugs/>

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

           Summary: Overeager setting of eof()
           Product: libc++
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: All Bugs
        AssignedTo: hhinnant at apple.com
        ReportedBy: chris at bubblescope.net
                CC: llvmbugs at cs.uiuc.edu


I believe the following code shows that libc++ is over-eager setting eofbit
when reading chars. Certainly the behavior disagrees with libstdc++, and my
very quick reading of the stream parts of the standard.

#include <sstream>
#include <cassert>

using namespace std;

int main(void)
{
    istringstream ss("1");
    char c;
    ss >> c;
    assert(!ss.eof());
}

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 26 11:10:11 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 26 Feb 2011 11:10:11 -0600 (CST)
Subject: [LLVMbugs] [Bug 3373] [dragonegg] cannot tie inline asm operands of
 different widths
In-Reply-To: <bug-3373-206@http.llvm.org/bugs/>
References: <bug-3373-206@http.llvm.org/bugs/>
Message-ID: <20110226171011.395072A6C130@llvm.org>

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

Duncan Sands <baldrick at free.fr> changed:

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

--- Comment #41 from Duncan Sands <baldrick at free.fr> 2011-02-26 11:10:08 CST ---
Fixed here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20110221/117159.html
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20110221/117183.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 Feb 26 12:47:19 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 26 Feb 2011 12:47:19 -0600 (CST)
Subject: [LLVMbugs] [Bug 9336] New: Incorrect attaching of const
Message-ID: <bug-9336-206@http.llvm.org/bugs/>

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

           Summary: Incorrect attaching of const
           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=6244)
 --> (http://llvm.org/bugs/attachment.cgi?id=6244)
Example code

The attached file fails to compile in clang++. It compiles in both g++ and
comeau.

I attach the backtrace below. I'll be honest, I'm not 100% sure who is in the
right. This was reduced from a boost testcase (in boost assign). I can't see
how the "inner" const is sneaking in.


t.cc:10:3: warning: control reaches end of non-void function [-Wreturn-type]
  }
  ^
t.cc:21:24: note: in instantiation of function template specialization
'generic_list<generic_list<int> >::operator array<array<array<int> > >'
requested here        
array<array<int> > a = l;
                       ^
t.cc:9:10: error: read-only variable is not assignable                          
    ar[0]=*i;
    ~~~~~^
t.cc:9:11: note: in instantiation of function template specialization
'generic_list<int>::operator array<const array<int> >' requested here           
    ar[0]=*i;
          ^
t.cc:21:24: note: in instantiation of function template specialization
'generic_list<generic_list<int> >::operator array<array<array<int> > >'
requested here        
array<array<int> > a = l;
                       ^
1 warning and 1 error 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 Feb 26 15:34:58 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 26 Feb 2011 15:34:58 -0600 (CST)
Subject: [LLVMbugs] [Bug 9337] New: ARM: misaligned data
Message-ID: <bug-9337-206@http.llvm.org/bugs/>

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

           Summary: ARM: misaligned data
           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: mans at mansr.com
                CC: llvmbugs at cs.uiuc.edu


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

When targeting ARM, data objects sometimes get misaligned leading to runtime
crashes.  In the attached file, a uint32_t array is placed at offset 1 in bss
even though the minimum alignment for uint32_t is 4. The misalignment seems
connected to the static variable in decode_init().

This test case is reduced from mpegaudiodec.c in FFmpeg.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 27 01:02:40 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 27 Feb 2011 01:02:40 -0600 (CST)
Subject: [LLVMbugs] [Bug 9338] New: can_read declared in FileSystem.h but
 not implemented
Message-ID: <bug-9338-206@http.llvm.org/bugs/>

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

           Summary: can_read declared in FileSystem.h but not implemented
           Product: new-bugs
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: viridia at gmail.com
                CC: llvmbugs at cs.uiuc.edu


I was trying to update my code to use the new path stuff (since the old code is
marked as deprecated) and I was getting link errors for "can_read". Searching
the code, it appears that this function was never implemented, even though it's
declared in the header.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 27 02:07:25 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 27 Feb 2011 02:07:25 -0600 (CST)
Subject: [LLVMbugs] [Bug 9324] Assertion `isVirtualRegister(Reg) && "Not a
 virtual register"' failed.
In-Reply-To: <bug-9324-206@http.llvm.org/bugs/>
References: <bug-9324-206@http.llvm.org/bugs/>
Message-ID: <20110227080725.126F42A6C12D@llvm.org>

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

Cameron Zwarich <zwarich at apple.com> changed:

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

--- Comment #3 from Cameron Zwarich <zwarich at apple.com> 2011-02-27 02:07:24 CST ---
Fixed in r126567. Sorry about that!

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 27 07:18:46 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 27 Feb 2011 07:18:46 -0600 (CST)
Subject: [LLVMbugs] [Bug 9339] New: Possible typo in LLVM tutorial
Message-ID: <bug-9339-206@http.llvm.org/bugs/>

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

           Summary: Possible typo in LLVM tutorial
           Product: Documentation
           Version: trunk
          Platform: PC
        OS/Version: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: General docs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: eliben at gmail.com
                CC: llvmbugs at cs.uiuc.edu


In part 5 of the LLVM Kaleidoscope tutorial
(http://llvm.org/docs/tutorial/LangImpl5.html), you say:

"Extending Kaleidoscope to support if/then/else is quite straightforward. It
basically requires adding lexer support for this "new" concept to the lexer,
parser, AST, and LLVM code emitter."

I think that the word "lexer" after "adding" shouldn't be 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  Sun Feb 27 07:54:28 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 27 Feb 2011 07:54:28 -0600 (CST)
Subject: [LLVMbugs] [Bug 9339] Possible typo in LLVM tutorial
In-Reply-To: <bug-9339-206@http.llvm.org/bugs/>
References: <bug-9339-206@http.llvm.org/bugs/>
Message-ID: <20110227135428.DD9C52A6C12D@llvm.org>

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

Duncan Sands <baldrick at free.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |baldrick at free.fr
         Resolution|                            |FIXED

--- Comment #1 from Duncan Sands <baldrick at free.fr> 2011-02-27 07:54:28 CST ---
Fixed in commit 126573.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 27 08:09:28 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 27 Feb 2011 08:09:28 -0600 (CST)
Subject: [LLVMbugs] [Bug 9340] New: linux allyesconfig fails to build with
 undef reference to mcount
Message-ID: <bug-9340-206@http.llvm.org/bugs/>

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

           Summary: linux allyesconfig fails to build with undef reference
                    to mcount
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: edwintorok at gmail.com
                CC: llvmbugs at cs.uiuc.edu


if CONFIG_FUNCTION_TRACER is on (which enables -pg), then Linux kernel fails to
build because there is an undefined reference to mcount in vdso.so.
Don't have time to investigate why for now, but maybe someone can think of a
flag I should try for mcount.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 27 08:42:07 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 27 Feb 2011 08:42:07 -0600 (CST)
Subject: [LLVMbugs] [Bug 9309] no support for splitting vector fp_extend
In-Reply-To: <bug-9309-206@http.llvm.org/bugs/>
References: <bug-9309-206@http.llvm.org/bugs/>
Message-ID: <20110227144207.7B2DB2A6C12D@llvm.org>

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

Duncan Sands <baldrick at free.fr> changed:

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

--- Comment #2 from Duncan Sands <baldrick at free.fr> 2011-02-27 08:42:06 CST ---
Fixed here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20110221/117206.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 Feb 27 11:45:53 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 27 Feb 2011 11:45:53 -0600 (CST)
Subject: [LLVMbugs] [Bug 9341] New: ARM: ssat/usat not supported in inline
	asm
Message-ID: <bug-9341-206@http.llvm.org/bugs/>

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

           Summary: ARM: ssat/usat not supported in inline asm
           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: mans at mansr.com
                CC: llvmbugs at cs.uiuc.edu


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

Inline asm using the SSAT or USAT instructions fails with this error in clang:

asm.c:3:14: error: invalid operand for instruction
    __asm__ ("ssat %0, #8, %1" : "=r"(x) : "r"(x));
             ^
<inline asm>:1:2: note: instantiated into assembly here
        ssat r0, #8, r0
        ^
1 error 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 Feb 27 14:22:22 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 27 Feb 2011 14:22:22 -0600 (CST)
Subject: [LLVMbugs] [Bug 9342] New: ARM: error related to R_ARM_MOVT_ABS
	relocation
Message-ID: <bug-9342-206@http.llvm.org/bugs/>

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

           Summary: ARM: error related to R_ARM_MOVT_ABS relocation
           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: mans at mansr.com
                CC: llvmbugs at cs.uiuc.edu


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

Compiling the C files in reloc.tar.gz for ARM/Linux and linking them into an
executable using gcc (I can't get clang to link for ARM) results in a MOVT
instruction with wrong immediate data.

The C files both contain the string "hello world", and the two copies are
merged by the linker.  One of the references to this string is correct,
while the other gets a bad value in the MOVT instruction, which one depends
on the link order.

Compiling to assembler with the -S flag and using the gnu assembler, the
output is correct.

I cannot rule out a bug in the gnu linker, but I am unable to reproduce the
error using only gnu tools.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 27 19:02:52 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 27 Feb 2011 19:02:52 -0600 (CST)
Subject: [LLVMbugs] [Bug 9322] clang doesn't DCE dead switch cases (breaks
 Linux kernel at -O0)
In-Reply-To: <bug-9322-206@http.llvm.org/bugs/>
References: <bug-9322-206@http.llvm.org/bugs/>
Message-ID: <20110228010252.846A82A6C12D@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #8 from Chris Lattner <clattner at apple.com> 2011-02-27 19:02:51 CST ---
Implemented in a series of patches leading up to r126602

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 27 20:31:27 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 27 Feb 2011 20:31:27 -0600 (CST)
Subject: [LLVMbugs] [Bug 9343] New: top 10 missed optimizations at -O2
Message-ID: <bug-9343-206@http.llvm.org/bugs/>

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

           Summary: top 10 missed optimizations at -O2
           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: nicholas at mxc.ca
                CC: baldrick at free.fr, llvmbugs at cs.uiuc.edu


This is a list of the top ten missed optimizations seen in bitcode after -O2,
sorted by popularity (number of sites in which they occurred, not number of
times they run in a program).

define i1 @test1(i32 %X, i32 %Y) {
; CHECK: test1
; CHECK-NOT: %Y
  %A = ashr exact i32 %X, %Y
  %B = icmp eq i32 %A, 0
; CHECK %B = icmp eq i32 %X, 0
  ret i1 %B
}

define i1 @test2(i32 %X, i32 %Y) {
; CHECK: test2
; CHECK-NOT: %Y
  %A = ashr exact i32 %X, %Y
  %B = sub i32 0, %A
; CHECK: %b = sub i32 0, %X
  %C = icmp sgt i32 %B, -1
  ret i1 %C
}

define i1 @test3(i32 %X, i32 %Y) {
; CHECK: test3
  %A = urem i32 %X, %Y
  %B = icmp ugt i32 %Y, %A
  ret i1 %B
; CHECK: ret i1 true
}

define i1 @test4(i32 %X, i32 %Y, i32 %Z) {
; CHECK: test4
; CHECK-NOT: %Z
  %A = ashr exact i32 %X, %Z
  %B = ashr exact i32 %Y, %Z
  %C = icmp ult i32 %A, %B
; CHECK: %C = icmp ult i32 %X, %Y
  ret i1 %C
}

define i1 @test5(i32 %X, i32 %Y, i32 %Z) {
; CHECK: test5
; CHECK-NOT: %Z
  %A = ashr exact i32 %X, %Z
  %B = ashr exact i32 %Y, %Z
  %C = icmp ugt i32 %A, %B
; CHECK: %C = icmp ugt i32 %X, %Y
  ret i1 %C
}

define i1 @test6(i32 %X, i32 %Y) {
; CHECK: test6
; CHECK-NOT: %B
; CHECK-NOT: %C
  %A = icmp ult i32 %X, %Y
  %B = icmp ne i32 %Y, 0
  %C = and i1 %A, %B
; CHECK: ret i1 %A
  ret i1 %C
}

define i1 @test7(i31 %X, i32 %Y) {
; CHECK: test7
  %A = zext i31 %X to i32
  %B = srem i32 %A, %Y
  %C = icmp slt i32 %B, 0
; CHECK: ret i1 false
  ret i1 %C
}

define i1 @test8(i32 %X, i32 %Y, i32 %Z) {
; CHECK: test8
; CHECK-NOT: %Z
  %A = sdiv exact i32 %X, %Z
  %B = sdiv exact i32 %Y, %Z
; CHECK: %C = icmp eq i32 %X, %Y
  %C = icmp eq i32 %A, %B
  ret i1 %C
}

define i1 @test9(i32 %X, i32 %Y) {
; CHECK: test9
; CHECK-NOT: %Y
  %A = add i32 %X, -1
  %B = and i32 %A, %Y
; CHECK: %C = icmp ugt i32 %X, %A
  %C = icmp ugt i32 %X, %B
  ret i1 %C
}

define i1 @test10(i31 %X, i31 %Y, i32 %Z) {
; CHECK: test10
; CHECK-NOT: %Z
  %A = zext i31 %X to i32
  %B = shl nuw i32 %A, %Z
  %C = zext i31 %Y to i32
; CHECK: %D = or i32 %A, %C
  %D = or i32 %B, %C
  %E = icmp eq i32 %D, 0
  ret i1 %E
}

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 28 07:14:34 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 28 Feb 2011 07:14:34 -0600 (CST)
Subject: [LLVMbugs] [Bug 9344] New: ARM sub-architecture support
Message-ID: <bug-9344-206@http.llvm.org/bugs/>

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

           Summary: ARM sub-architecture support
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: ARM
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: rengolin at gmail.com
                CC: llvmbugs at cs.uiuc.edu


When defining build attributes or codegen options for ARM, we need to know what
architecture, sub-architecture (including the default options) but also what
options the user has overriden.

Currently, there are some string comparison of the cpu name to "cortex-a8",
which is clearly broken (what about a9?). There is also a method "isCortexA8()"
which suffers from the same problem.

Some options, like Advanced_SIMD build attribute, has no way of knowing if it
has to emit the not-allowed option or just leave it blank, as there is no way
of differentiating if the user has chosen a target without NEON or has
explicitly disabled NEON on a target with it.

I propose we should build an infrastructure that will return possible AND
implemented abilities in a defined sub-target.

For instance, Cortex-A9 CAN-HAVE NEON but the Tegra2 board doesn't, so the
result of the two calls below would be:

subtarget->hasNEON() : false
subtarget->supportsNEON() : true

or some other more refined architecture like:

subtarget->hasNEON() : false
subtarget->supported->hasNEON() : true

With supported being a subtarget type and always being filled with the default
parameters, while the subtarget itself can be modified with the command-line
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  Mon Feb 28 12:52:19 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 28 Feb 2011 12:52:19 -0600 (CST)
Subject: [LLVMbugs] [Bug 9345] New: Support -Wsign-conversion
Message-ID: <bug-9345-206@http.llvm.org/bugs/>

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

           Summary: Support -Wsign-conversion
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: matthewbg at google.com
                CC: llvmbugs at cs.uiuc.edu


Clang's -Wconversion should be more like GCC's with respect to conversions
between signed and unsigned integers.

For reference, here's what gcc(1) has to say:
       -Wconversion
           Warn for implicit conversions that may alter a value. This includes
           conversions between real and integer, like "abs (x)" when "x" is
           "double"; conversions between signed and unsigned, like "unsigned
           ui = -1"; and conversions to smaller types, like "sqrtf (M_PI)". Do
           not warn for explicit casts like "abs ((int) x)" and "ui =
           (unsigned) -1", or if the value is not changed by the conversion
           like in "abs (2.0)".  Warnings about conversions between signed and
           unsigned integers can be disabled by using -Wno-sign-conversion.

           For C++, also warn for conversions between "NULL" and non-pointer
           types; confusing overload resolution for user-defined conversions;
           and conversions that will never use a type conversion operator:
           conversions to "void", the same type, a base class or a reference
           to them. Warnings about conversions between signed and unsigned
           integers are disabled by default in C++ unless -Wsign-conversion is
           explicitly enabled.
       -Wsign-conversion
           Warn for implicit conversions that may change the sign of an
           integer value, like assigning a signed integer expression to an
           unsigned integer variable. An explicit cast silences the warning.
           In C, this option is enabled also by -Wconversion.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 28 15:50:04 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 28 Feb 2011 15:50:04 -0600 (CST)
Subject: [LLVMbugs] [Bug 9346] New: likely memory unsafety error in
	generated code
Message-ID: <bug-9346-206@http.llvm.org/bugs/>

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

           Summary: likely memory unsafety error in generated code
           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


Notice that (due to ASLR or whatever) two runs of the same executable give
different answers.  The correct answer is "0".

[regehr at gamow ~]$ clang -v
clang version 2.9 (trunk 126682)
Target: x86_64-unknown-linux-gnu
Thread model: posix
[regehr at gamow ~]$ clang -O2 foo.c -o foo
[regehr at gamow ~]$ ./foo
g_1 = 107756488
[regehr at gamow ~]$ ./foo
g_1 = 1634447976
[regehr at gamow ~]$ cat foo.c
long long g_4 = 0;
static int g_1 = 0;

int printf(const char *format, ...);

static int foo(int i1, int i2)
{
   return (i1 % i2);
}

int main (int argc, char* argv[])
{
   foo(1, 1);
   g_1 = foo((g_4 | -2), -1);
   printf("g_1 = %d\n", g_1);
   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  Mon Feb 28 16:09:20 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 28 Feb 2011 16:09:20 -0600 (CST)
Subject: [LLVMbugs] [Bug 8931] Missing FPU type directives in generated gas
 assembly for ARM ELF target
In-Reply-To: <bug-8931-206@http.llvm.org/bugs/>
References: <bug-8931-206@http.llvm.org/bugs/>
Message-ID: <20110228220920.2D7E92A6C12C@llvm.org>

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

Renato Golin <rengolin at gmail.com> changed:

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

--- Comment #2 from Renato Golin <rengolin at gmail.com> 2011-02-28 16:09:19 CST ---
Fixed in revision 126689

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 28 18:39:21 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 28 Feb 2011 18:39:21 -0600 (CST)
Subject: [LLVMbugs] [Bug 9347] New: incorrect result type AltiVec vector
	comparison
Message-ID: <bug-9347-206@http.llvm.org/bugs/>

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

           Summary: incorrect result type AltiVec vector comparison
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: tonic at nondot.org
                CC: llvmbugs at cs.uiuc.edu


Given the following example:

typedef signed char int8_t;
typedef unsigned char uint8_t;
typedef __attribute__((ext_vector_type(8)))  uint8_t uint8x8_t;
typedef __attribute__((ext_vector_type(8)))  int8_t int8x8_t;

uint8x8_t foo(int8x8_t __a, int8x8_t __b) { \
  return (uint8x8_t)(__a == __b); }

The expression (__a == __b) should return a vector of 8 chars, but right now,
clang believe that it should returns an int (or bool if C++).

This is due to the following code in Sema::CheckVectorCompareOperands():
  // If AltiVec, the comparison results in a numeric type, i.e.
  // bool for C++, int for C
  if (getLangOptions().AltiVec)
    return Context.getLogicalOperationType();

I do not believe this is correct. Removing this condition allows the expression
type to be set 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  Mon Feb 28 19:45:51 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 28 Feb 2011 19:45:51 -0600 (CST)
Subject: [LLVMbugs] [Bug 9348] New: libclang does not expose array types
Message-ID: <bug-9348-206@http.llvm.org/bugs/>

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

           Summary: libclang does not expose array types
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: stefan at seefeld.name
                CC: llvmbugs at cs.uiuc.edu


Using libclang to traverse the generated AST for array declarations will report
the type as "Unexposed".

Array types should be reported in a way that gives access to the array sizes.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Feb 28 20:28:04 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 28 Feb 2011 20:28:04 -0600 (CST)
Subject: [LLVMbugs] [Bug 9349] New: .svn directories installed by CMake build
Message-ID: <bug-9349-206@http.llvm.org/bugs/>

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

           Summary: .svn directories installed by CMake build
           Product: libc++
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: All Bugs
        AssignedTo: hhinnant at apple.com
        ReportedBy: oroppas at gmail.com
                CC: llvmbugs at cs.uiuc.edu


It's rather trivial issue but cmake wrongly installed the unnecessary .svn in
/usr/include/c++/v1 and /usr/include/c++/v1/ext.

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