From bugzilla-daemon at llvm.org  Thu Dec  1 02:18:38 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 01 Dec 2011 08:18:38 +0000
Subject: [LLVMbugs] [Bug 11459] New: is_empty<> chokes on final
Message-ID: <bug-11459-206@http.llvm.org/bugs/>

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

             Bug #: 11459
           Summary: is_empty<> chokes on final
           Product: libc++
           Version: unspecified
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: All Bugs
        AssignedTo: hhinnant at apple.com
        ReportedBy: ganesh at barbati.net
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 7660
  --> http://llvm.org/bugs/attachment.cgi?id=7660
Patch to make is_empty use the __is_empty intrinsic, if available

The following code will not compile:

  #include <type_traits>

  struct A final {};
  struct B { virtual ~B() final; };

  int main()
  {
    std::is_empty<A>::value;
    std::is_empty<B>::value;
  }

The error messages being:

  type_traits:787:14: error: base 'A' is marked 'final' [3]
  type_traits:786:8: error: declaration of '~__is_empty1' overrides a 'final'
function [3]

The current implementation if is_empty<> uses a technique that assumes every
class type can be derived from, but in presence of final that is no longer
true. I am attaching a patch that makes is_empty<> use the __is_empty intrinsic
function if it is available, as the intrinsic doesn't have this problem.

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

From bugzilla-daemon at llvm.org  Thu Dec  1 05:33:15 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 01 Dec 2011 11:33:15 +0000
Subject: [LLVMbugs] [Bug 11461] New: std::tuple chokes on final
Message-ID: <bug-11461-206@http.llvm.org/bugs/>

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

             Bug #: 11461
           Summary: std::tuple chokes on final
           Product: libc++
           Version: unspecified
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: All Bugs
        AssignedTo: hhinnant at apple.com
        ReportedBy: ganesh at barbati.net
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


The following code does not compile:

  #include <utility>

  struct A final {};
  struct B { virtual ~B() final; };

  int main()
  {
    std::tuple<A> x; // #1
    std::tuple<B> y; // #2
  }

This currently happens because of a problem in std::is_empty<> that has been
reported as bug #11459. However even if we fix std::is_empty<>, only line #2
will compile. Line #1 will still trigger an error, because std::tuple will
attempt to derive from the empty class type A, which is forbidden.

In order to fix the problem we should disable the empty base optimization for
final classes. To achieve that, we need either an __is_final intrinsic or a
(possibly library-only) trait to check if derivation from a type T is actually
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  Thu Dec  1 05:41:51 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 01 Dec 2011 11:41:51 +0000
Subject: [LLVMbugs] [Bug 11462] New: __is_final intrinsic
Message-ID: <bug-11462-206@http.llvm.org/bugs/>

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

             Bug #: 11462
           Summary: __is_final intrinsic
           Product: clang
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: C++0x
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: ganesh at barbati.net
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 7662
  --> http://llvm.org/bugs/attachment.cgi?id=7662
Patch that implements the __is_final intrinsic

I am attaching a patch that implements the __is_final() intrinsic function that
checks whether a class is declared final. In other words, the code:

struct A {};
struct B final {};

int main()
{
  std::cout << __is_final(A) << " " << __is_final(B) << "\n";
}

should output "0 1".

This intrinsic is motivated by the library bug #11461.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec  1 04:20:11 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 01 Dec 2011 10:20:11 +0000
Subject: [LLVMbugs] [Bug 11460] New: [LLVM,
	SelectionDAG] store <N x i1> crash.
Message-ID: <bug-11460-206@http.llvm.org/bugs/>

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

             Bug #: 11460
           Summary: [LLVM, SelectionDAG] store <N x i1> crash.
           Product: tools
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: llc
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: stpworld at narod.ru
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 7661
  --> http://llvm.org/bugs/attachment.cgi?id=7661
Testcase

Attempt to store i1 vectors crashes llc with assertion. Testcase is attached.
Assertion:
./llc < store-v4i1.ll
    .file    "<stdin>"
llc:
/home/stepan/projects/llvm.project/llvm/include/llvm/CodeGen/ValueTypes.h:563:
llvm::MVT llvm::EVT::getSimpleVT() const: Assertion `isSimple() && "Expected a
SimpleValueType!"' failed.
0  llc             0x090b62ca
1  llc             0x090b6057
2  libpthread.so.0 0x007ae9e8
3  libc.so.6       0x001e734e abort + 382
4  libc.so.6       0x001dc888 __assert_fail + 248
5  llc             0x086bc560 llvm::EVT::getSimpleVT() const + 82
6  llc             0x08aa8109
llvm::TargetLowering::getTruncStoreAction(llvm::EVT, llvm::EVT) const + 121
7  llc             0x08ba5c9d
8  llc             0x08ba572a
9  llc             0x08ba8066 llvm::SelectionDAG::LegalizeVectors() + 36
10 llc             0x08b4ba25 llvm::SelectionDAGISel::CodeGenAndEmitDAG() +
1767
11 llc             0x08b4afeb
llvm::SelectionDAGISel::SelectBasicBlock(llvm::ilist_iterator<llvm::Instruction
const>, llvm::ilist_iterator<llvm::Instruction const>, bool&) + 219
12 llc             0x08b4d570
llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) + 2368
13 llc             0x08b4a52d
llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) + 689
14 llc             0x08cae8e1
llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 87
15 llc             0x09048322
llvm::FPPassManager::runOnFunction(llvm::Function&) + 344
16 llc             0x09048508 llvm::FPPassManager::runOnModule(llvm::Module&) +
114
17 llc             0x09048804 llvm::MPPassManager::runOnModule(llvm::Module&) +
400
18 llc             0x09048cbf llvm::PassManagerImpl::run(llvm::Module&) + 127
19 llc             0x09049075 llvm::PassManager::run(llvm::Module&) + 39
20 llc             0x086484c2 main + 2692
21 libc.so.6       0x001cfe37 __libc_start_main + 231
22 llc             0x08647331
Stack dump:
0.    Program arguments: ./llc 
1.    Running pass 'Function Pass Manager' on module '<stdin>'.
2.    Running pass 'X86 DAG->DAG Instruction Selection' on function '@test'

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec  1 08:42:14 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 01 Dec 2011 14:42:14 +0000
Subject: [LLVMbugs] [Bug 11460] [LLVM, SelectionDAG] store <N x i1> crash.
In-Reply-To: <bug-11460-206@http.llvm.org/bugs/>
References: <bug-11460-206@http.llvm.org/bugs/>
Message-ID: <bug-11460-206-qXjUh0fhT8@http.llvm.org/bugs/>

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

Duncan Sands <baldrick at free.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |baldrick at free.fr
         Resolution|                            |DUPLICATE

--- Comment #1 from Duncan Sands <baldrick at free.fr> 2011-12-01 08:42:14 CST ---


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

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec  1 16:30:48 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 01 Dec 2011 22:30:48 +0000
Subject: [LLVMbugs] [Bug 11463] New: test-suite requires yacc to run
	correctly
Message-ID: <bug-11463-206@http.llvm.org/bugs/>

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

             Bug #: 11463
           Summary: test-suite requires yacc to run correctly
           Product: Documentation
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: General docs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: Kevin.Harris at unisys.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


I discovered, by installing LLVM 3.0rc4, Clang, and test-suite on a system that
didn't have "yacc" installed, that test-suite gmake will fail catastrophically.
 Installing the gnu "bison" kit corrected the problem.  This additional
software requirement should be documented on the "Requirements" section of the
Testing Infrastructure Guide. 

http://llvm.org/docs/TestingGuide.html#requirements

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec  1 16:34:47 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 01 Dec 2011 22:34:47 +0000
Subject: [LLVMbugs] [Bug 11464] New: LinkModules fails to remap types
Message-ID: <bug-11464-206@http.llvm.org/bugs/>

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

             Bug #: 11464
           Summary: LinkModules fails to remap types
           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: boulos at cs.stanford.edu
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


I've got two simple c files with va_lists:

a.c:

#include <stdarg.h>
void fn1(va_list args) {}

b.c:

#include <stdarg.h>
void fn2(va_list args) {}

If I compile these to bitcode with clang and then link with llvm-link, I get an
output module that has two different va_list types:

%struct.__va_list_tag = type { i32, i32, i8*, i8* }
%struct.__va_list_tag.0 = type { i32, i32, i8*, i8* }

define void @fn1(%struct.__va_list_tag* %args) nounwind uwtable ssp {
  %1 = alloca %struct.__va_list_tag*, align 8
  store %struct.__va_list_tag* %args, %struct.__va_list_tag** %1, align 8
  ret void
}

define void @fn2(%struct.__va_list_tag.0* %args) nounwind uwtable ssp {
  %1 = alloca %struct.__va_list_tag.0*, align 8
  store %struct.__va_list_tag.0* %args, %struct.__va_list_tag.0** %1, align 8
  ret void
}

Having read the type system rewrite blog post, it seems like LinkModules should
be merging these types. After tracking this down in lib/Linker/LinkModules.cpp,
it seems that the TypeMap only learns types that it sees in "stuff" that will
overlap between the Dst and Src modules. Since fn2 doesn't overlap with fn1,
the TypeMap never tries to merge the two different va_list names, producing a
duplicate.

I'm not sure if this falls under the category of expecting to be able to find a
"magic IR type" or not.

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

From bugzilla-daemon at llvm.org  Thu Dec  1 19:58:00 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 02 Dec 2011 01:58:00 +0000
Subject: [LLVMbugs] [Bug 11466] New: Build failed for LLVM 3.0
Message-ID: <bug-11466-206@http.llvm.org/bugs/>

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

             Bug #: 11466
           Summary: Build failed for LLVM 3.0
           Product: new-bugs
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: spamdaemon at comcast.net
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


I just downloaded llvm-3.0. After unzipping it (with and without clang), I
typed "configure --prefix=/local/llvm-3.0" and then "make -j8"

Build fails here:

In file included from
/pub/llvm-3.0.src/utils/unittest/googletest/include/gtest/gtest.h:57:0,
                 from InstructionsTest.cpp:16:
/pub/llvm-3.0.src/utils/unittest/googletest/include/gtest/internal/gtest-internal.h:
In instantiation of ?const bool testing::internal::ImplicitlyConvertible<const
llvm::Use&, long long int>::value?:
/pub/llvm-3.0.src/utils/unittest/googletest/include/gtest/gtest-printers.h:201:3:
  instantiated from ?std::basic_ostream<_CharT, _Traits>&
testing::internal2::operator<<(std::basic_ostream<_CharT, _Traits>&, const T&)
[with Char = char, CharTraits = std::char_traits<char>, T = llvm::Use]?
/pub/llvm-3.0.src/utils/unittest/googletest/include/gtest/gtest-printers.h:245:3:
  instantiated from ?void testing_internal::DefaultPrintNonContainerTo(const
T&, std::ostream*) [with T = llvm::Use, std::ostream =
std::basic_ostream<char>]?
/pub/llvm-3.0.src/utils/unittest/googletest/include/gtest/gtest-printers.h:338:3:
  instantiated from ?void
testing::internal::DefaultPrintTo(testing::internal::IsNotContainer,
testing::internal::false_type, const T&, std::ostream*) [with T = llvm::Use,
testing::internal::IsNotContainer = char, testing::internal::false_type =
testing::internal::bool_constant<false>, std::ostream =
std::basic_ostream<char>]?
/pub/llvm-3.0.src/utils/unittest/googletest/include/gtest/gtest-printers.h:376:3:
  instantiated from ?void testing::internal::PrintTo(const T&, std::ostream*)
[with T = llvm::Use, std::ostream = std::basic_ostream<char>]?
/pub/llvm-3.0.src/utils/unittest/googletest/include/gtest/gtest-printers.h:600:5:
  instantiated from ?static void
testing::internal::UniversalPrinter<T>::Print(const T&, std::ostream*) [with T
= llvm::Use, std::ostream = std::basic_ostream<char>]?
/pub/llvm-3.0.src/utils/unittest/googletest/include/gtest/gtest-printers.h:697:3:
  instantiated from ?void testing::internal::UniversalPrint(const T&,
std::ostream*) [with T = llvm::Use, std::ostream = std::basic_ostream<char>]?
/pub/llvm-3.0.src/utils/unittest/googletest/include/gtest/gtest-printers.h:678:3:
  instantiated from ?void testing::internal::UniversalTersePrint(const T&,
std::ostream*) [with T = llvm::Use, std::ostream = std::basic_ostream<char>]?
/pub/llvm-3.0.src/utils/unittest/googletest/include/gtest/gtest-printers.h:790:3:
  instantiated from ?std::string testing::PrintToString(const T&) [with T =
llvm::Use, std::string = std::basic_string<char>]?
/pub/llvm-3.0.src/utils/unittest/googletest/include/gtest/gtest.h:1301:40:  
instantiated from ?testing::internal::String
testing::internal::FormatForComparisonFailureMessage(const T1&, const T2&)
[with T1 = llvm::Use, T2 = llvm::Constant*]?
/pub/llvm-3.0.src/utils/unittest/googletest/include/gtest/gtest.h:1330:25:  
instantiated from ?testing::AssertionResult
testing::internal::CmpHelperEQ(const char*, const char*, const T1&, const T2&)
[with T1 = llvm::Constant*, T2 = llvm::Use]?
/pub/llvm-3.0.src/utils/unittest/googletest/include/gtest/gtest.h:1355:30:  
instantiated from ?static testing::AssertionResult
testing::internal::EqHelper<lhs_is_null_literal>::Compare(const char*, const
char*, const T1&, const T2&) [with T1 = llvm::Constant*, T2 = llvm::Use, bool
lhs_is_null_literal = false]?
InstructionsTest.cpp:35:3:   instantiated from here
/pub/llvm-3.0.src/include/llvm/Use.h:69:3: error: ?llvm::Use::Use(const
llvm::Use&)? is private
/pub/llvm-3.0.src/utils/unittest/googletest/include/gtest/internal/gtest-internal.h:910:60:
error: within this context
/pub/llvm-3.0.src/include/llvm/Use.h:72:3: error: ?llvm::Use::~Use()? is
private
/pub/llvm-3.0.src/utils/unittest/googletest/include/gtest/internal/gtest-internal.h:910:60:
error: within this context
/bin/rm: cannot remove
`/pub/llvm-3.0.src/unittests/VMCore/Release/InstructionsTest.d.tmp': No such
file or directory
make[2]: *** [/pub/llvm-3.0.src/unittests/VMCore/Release/InstructionsTest.o]
Error 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  Thu Dec  1 20:39:22 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 02 Dec 2011 02:39:22 +0000
Subject: [LLVMbugs] [Bug 9560] bit fields not packed
In-Reply-To: <bug-9560-206@http.llvm.org/bugs/>
References: <bug-9560-206@http.llvm.org/bugs/>
Message-ID: <bug-9560-206-CVqg3bToop@http.llvm.org/bugs/>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

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

--- Comment #7 from Eli Friedman <sharparrow1 at yahoo.com> 2011-12-01 20:39:22 CST ---
r145673.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec  1 21:25:49 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 02 Dec 2011 03:25:49 +0000
Subject: [LLVMbugs] [Bug 11466] Build/unit test failed for LLVM 3.0
In-Reply-To: <bug-11466-206@http.llvm.org/bugs/>
References: <bug-11466-206@http.llvm.org/bugs/>
Message-ID: <bug-11466-206-OZYRdaiP5i@http.llvm.org/bugs/>

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

spamdaemon at comcast.net changed:

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

--- Comment #3 from spamdaemon at comcast.net 2011-12-01 21:25:49 CST ---
Tried with gcc (GCC) 4.7.0 20111126 (experimental)

and that seems to work.

I'll set the status to resolved, 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  Fri Dec  2 00:29:54 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 02 Dec 2011 06:29:54 +0000
Subject: [LLVMbugs] [Bug 11467] New: The definition of the "LLVM" acronyn
 should be spelled out on the llvm.org front page or FAQ.
Message-ID: <bug-11467-206@http.llvm.org/bugs/>

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

             Bug #: 11467
           Summary: The definition of the "LLVM" acronyn should be spelled
                    out on the llvm.org front page or FAQ.
           Product: Documentation
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: General docs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: aaron at justaaron.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


An acronym like LLVM is expected to have a definition behind it. If LLVM stands
for anything, it should be spelled out early, like at the top of llvm.org, or
in the FAQ. If it no longer stands for anything, then that should be stated.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec  2 10:54:08 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 02 Dec 2011 16:54:08 +0000
Subject: [LLVMbugs] [Bug 11467] The definition of the "LLVM" acronyn should
 be spelled out on the llvm.org front page or FAQ.
In-Reply-To: <bug-11467-206@http.llvm.org/bugs/>
References: <bug-11467-206@http.llvm.org/bugs/>
Message-ID: <bug-11467-206-TmFvQc1Dx6@http.llvm.org/bugs/>

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

aaron at justaaron.com changed:

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

--- Comment #1 from aaron at justaaron.com 2011-12-02 10:54:08 CST ---
It was suggested to me that this is a waste of team's time, and since I would
have to waste one or more team member's time to verify what the definition is,
I am (attempting to) close 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 Dec  2 13:27:46 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 02 Dec 2011 19:27:46 +0000
Subject: [LLVMbugs] [Bug 11468] New: Clang incorrectly handles exceptions in
 presence of stack aligned variables
Message-ID: <bug-11468-206@http.llvm.org/bugs/>

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

             Bug #: 11468
           Summary: Clang incorrectly handles exceptions in presence of
                    stack aligned variables
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: samsonov at google.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


On fresh clang from trunk.
Reproducible both on Mac OS and Linux.

Clang seem to incorrectly restore value of callee-safe registers
during stack unwinding (when exception is thrown). This happens in
presence of aligned stack variables. Clang inserts asm instruction that
aligns %rsp but this isn't reported to unwinder. See this reproducer:

$ cat exception_test.cc
#include <stdio.h>

void TouchR15AndThrow(const char& arg) {
  volatile int n __attribute__((aligned(32))) = 0;
  asm volatile ("nop" : : : "r15"); // force to save r15 on stack
  throw arg;
}

int main() {
  register int *a asm ("r15");
  fprintf(stderr, "before throw: %p\n", a);
  try {
    TouchR15AndThrow('c');
  } catch (const char&) { }
  fprintf(stderr, "after catch: %p\n", a);
  return 0;
}
$ ../build/Release+Asserts/bin/clang++ -O2 exception_test.cc
$ ./a.out 
before throw: 0x7fff5fbff968
after catch: 0x7fff702de650

More data, including parts of objdump and DWARF can be found here:
: http://code.google.com/p/address-sanitizer/issues/detail?id=13#c1

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec  2 13:37:07 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 02 Dec 2011 19:37:07 +0000
Subject: [LLVMbugs] [Bug 11428] errc,
 io_errc and future_errc constants should really be scoped enums
In-Reply-To: <bug-11428-206@http.llvm.org/bugs/>
References: <bug-11428-206@http.llvm.org/bugs/>
Message-ID: <bug-11428-206-U4bTUistCR@http.llvm.org/bugs/>

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

Howard Hinnant <hhinnant at apple.com> changed:

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

--- Comment #3 from Howard Hinnant <hhinnant at apple.com> 2011-12-02 13:37:07 CST ---
Committed revision 145698.

Nicely done Ganesh!

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec  2 13:41:30 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 02 Dec 2011 19:41:30 +0000
Subject: [LLVMbugs] [Bug 11468] Clang incorrectly handles exceptions in
 presence of stack aligned variables
In-Reply-To: <bug-11468-206@http.llvm.org/bugs/>
References: <bug-11468-206@http.llvm.org/bugs/>
Message-ID: <bug-11468-206-97EnfW52KZ@http.llvm.org/bugs/>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |sharparrow1 at yahoo.com
         Resolution|                            |INVALID

--- Comment #2 from Eli Friedman <sharparrow1 at yahoo.com> 2011-12-02 13:41:30 CST ---
Applying a register name to a variable that isn't used in an inline asm doesn't
actually do anything.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec  2 14:42:02 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 02 Dec 2011 20:42:02 +0000
Subject: [LLVMbugs] [Bug 11459] is_empty<> chokes on final
In-Reply-To: <bug-11459-206@http.llvm.org/bugs/>
References: <bug-11459-206@http.llvm.org/bugs/>
Message-ID: <bug-11459-206-SNNCNm5SZd@http.llvm.org/bugs/>

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

Howard Hinnant <hhinnant at apple.com> changed:

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

--- Comment #2 from Howard Hinnant <hhinnant at apple.com> 2011-12-02 14:42:02 CST ---
Committed revision 145703.

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 Dec  2 15:14:08 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 02 Dec 2011 21:14:08 +0000
Subject: [LLVMbugs] [Bug 11468] Clang incorrectly handles exceptions in
 presence of stack aligned variables
In-Reply-To: <bug-11468-206@http.llvm.org/bugs/>
References: <bug-11468-206@http.llvm.org/bugs/>
Message-ID: <bug-11468-206-k8nvji92Az@http.llvm.org/bugs/>

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

Alexey Samsonov <samsonov at google.com> changed:

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

--- Comment #4 from Alexey Samsonov <samsonov at google.com> 2011-12-02 15:14:08 CST ---
Ouch, sorry for that. I tried to make another reproducer, please take a look:
$ cat exception_test.cc
#include <stdio.h>

__attribute__((noinline))
void TouchR15AndThrow(const char& arg) {
  volatile int n __attribute__((aligned(32))) = 0;
  asm volatile ("nop" : : : "%r15"); // force to save r15 on stack
  throw arg;
}

int main() {
  // Set r15 value
  int a = 42;
  asm ("movq %0, %%r15;\n\t" : : "g"(a) : "%r15");
  // Output value of r15
  int b;
  asm ("movq %%r15, %0;\n\t" : "=g" (b) : : "%r15");
  fprintf(stderr, "before = %d\n", b);
  try {
    TouchR15AndThrow('c');
  } catch (const char&) { }
  // Output value of r15 again
  asm ("movq %%r15, %0;\n\t" : "=g" (b) : : "%r15");
  fprintf(stderr, "after = %d\n", b);
  return 0;
}

$ ../build/Release+Asserts/bin/clang++ -O2 exception_test.cc
$ ./a.out
before = 42
after = 0

there is no instruction that changes value in %r15, but it is incorrectly
restored after exception is caught.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec  2 15:23:25 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 02 Dec 2011 21:23:25 +0000
Subject: [LLVMbugs] [Bug 11469] New: Wrong CFG generated for cast to VM type
Message-ID: <bug-11469-206@http.llvm.org/bugs/>

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

             Bug #: 11469
           Summary: Wrong CFG generated for cast to VM type
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Static Analyzer
        AssignedTo: kremenek at apple.com
        ReportedBy: abramobagnara at tin.it
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec  2 18:04:46 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 03 Dec 2011 00:04:46 +0000
Subject: [LLVMbugs] [Bug 11455] Dead store elimination kills non-dead store
 as part of memcpy
In-Reply-To: <bug-11455-206@http.llvm.org/bugs/>
References: <bug-11455-206@http.llvm.org/bugs/>
Message-ID: <bug-11455-206-09cBrTHu3l@http.llvm.org/bugs/>

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

Peter Cooper <pete.cooper at gmail.com> changed:

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

--- Comment #7 from Peter Cooper <pete.cooper at gmail.com> 2011-12-02 18:04:46 CST ---
Fixed in r145731

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec  2 21:46:13 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 03 Dec 2011 03:46:13 +0000
Subject: [LLVMbugs] [Bug 11470] New: clang incorrectly marks all return slot
 parameters as noalias
Message-ID: <bug-11470-206@http.llvm.org/bugs/>

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

             Bug #: 11470
           Summary: clang incorrectly marks all return slot parameters as
                    noalias
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Keywords: miscompilation
          Severity: enhancement
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: richard-llvm at metafoo.co.uk
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu,
                    nicholas at mxc.ca
    Classification: Unclassified


Consider the following:


struct foo { int a, b; double c, d, e; };
extern foo x;
foo f() { return { 1, x.a }; }
foo x = f();


Depending on what copy elision happens, x is initialized as either {1,0} or
{1,1}. With the double members in struct foo, we elide all the copies and an
-O0 build initializes x as {1,1}. (Without the double members, we return as i64
and get the resulting value {1,0}). However, we define f as:

define void @_Z1fv(%struct.foo* noalias sret %agg.result) nounwind uwtable {   

This is wrong! %agg.result is not noalias. This results in us incorrectly
assuming the write to %agg.result.a and the read of @x.a do not alias, and
producing the result {1,0}. This coincidentally happens to be a legal outcome
in this case, but not in general.

Another example:


struct bar {
  bar(bar *o) : ok(true) {
    o->ok = false;
    if (!ok)
      ok = true;
  }

  bool ok;
  double make, it, bigger;
};

bar f(bar *p) {
  return p;
}

int main() {
  bar self_reference = f(&self_reference);
  return !self_reference.ok;
}


In a compliant compiler, main must always return 0, whether we elide the copies
or not. But in clang at -O3, it returns 1! This is again because we've
incorrectly marked the return slot in bar as noalias.

Note that, while the above initializations have undefined behaviour for const
objects, by C++11[class.ctor]p14, I believe they have well-defined behaviour in
these cases, since the objects are not const.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec  2 21:59:42 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 03 Dec 2011 03:59:42 +0000
Subject: [LLVMbugs] [Bug 11471] New: alias analysis misled by pointer
	comparison
Message-ID: <bug-11471-206@http.llvm.org/bugs/>

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

             Bug #: 11471
           Summary: alias analysis misled by pointer comparison
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Scalar Optimizations
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: richard-llvm at metafoo.co.uk
                CC: llvmbugs at cs.uiuc.edu, nicholas at mxc.ca
    Classification: Unclassified


Consider the following:

; ModuleID = '<stdin>'
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-S128"
target triple = "x86_64-unknown-linux-gnu"

%struct.bar = type { i8, double, double, double }

define void @_Z1fP3bar(%struct.bar* noalias sret %agg.result, %struct.bar* %p)
nounwind uwtable {
entry:
  %ok.i = getelementptr inbounds %struct.bar* %agg.result, i64 0, i32 0
  store i8 1, i8* %ok.i, align 1, !tbaa !0
  %cmp.i = icmp eq %struct.bar* %agg.result, %p
  br i1 %cmp.i, label %if.then.i, label %_ZN3barC2EPS_.exit

if.then.i:                                        ; preds = %entry
  %ok2.i = getelementptr inbounds %struct.bar* %p, i64 0, i32 0
  store i8 0, i8* %ok2.i, align 1, !tbaa !0
  %0 = load i8* %ok.i, align 1, !tbaa !0
  %1 = and i8 %0, 1
  %tobool.i = icmp eq i8 %1, 0
  br i1 %tobool.i, label %if.then4.i, label %_ZN3barC2EPS_.exit

if.then4.i:                                       ; preds = %if.then.i
  store i8 1, i8* %ok.i, align 1, !tbaa !0
  br label %_ZN3barC2EPS_.exit

_ZN3barC2EPS_.exit:                               ; preds = %if.then4.i,
%if.then.i, %entry
  ret void
}

!0 = metadata !{metadata !"bool", metadata !1}
!1 = metadata !{metadata !"omnipotent char", metadata !2}
!2 = metadata !{metadata !"Simple C/C++ TBAA", null}

We do not optimize this any further, apparently because the icmp of %agg.result
and %p is causing us to lose the knowledge that those two pointers don't alias.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec  3 00:57:32 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 03 Dec 2011 06:57:32 +0000
Subject: [LLVMbugs] [Bug 11468] Clang incorrectly handles exceptions in
 presence of stack aligned variables
In-Reply-To: <bug-11468-206@http.llvm.org/bugs/>
References: <bug-11468-206@http.llvm.org/bugs/>
Message-ID: <bug-11468-206-PDXgUdsKRN@http.llvm.org/bugs/>

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

Bill Wendling <wendling at apple.com> changed:

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

--- Comment #5 from Bill Wendling <wendling at apple.com> 2011-12-03 00:57:32 CST ---
>From the EH ABI:

"The unwind runtime will likely have modified the stack (e.g. popped frames
from it) or register context, or landing pad code may have corrupted them. As a
result, the the caller of _Unwind_RaiseException can make no assumptions about
the state of its stack or registers."

So basically we cannot rely upon any register values being valid except for
those we know are restored via the unwinder. 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  Sat Dec  3 03:37:23 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 03 Dec 2011 09:37:23 +0000
Subject: [LLVMbugs] [Bug 11472] New: no path to 32-bit startup files on ppc64
Message-ID: <bug-11472-206@http.llvm.org/bugs/>

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

             Bug #: 11472
           Summary: no path to 32-bit startup files on ppc64
           Product: clang
           Version: trunk
          Platform: Other
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: michael.kostylev at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 7665
  --> http://llvm.org/bugs/attachment.cgi?id=7665
proposed patch

To be more precise, there are at least ppc64, mips64{,el} and sparcv9 platforms
where 32-bit multilibs could be supported. Clang is able to find 32-bit system
libraries but fails to find 32-bit crt*.o files, libgcc* etc.
Mips64/sparcv9 require more driver patching per se, so I did a patch only for
ppc64.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec  3 07:23:54 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 03 Dec 2011 13:23:54 +0000
Subject: [LLVMbugs] [Bug 11468] Clang incorrectly handles exceptions in
 presence of stack aligned variables
In-Reply-To: <bug-11468-206@http.llvm.org/bugs/>
References: <bug-11468-206@http.llvm.org/bugs/>
Message-ID: <bug-11468-206-tMtg082otX@http.llvm.org/bugs/>

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

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

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

--- Comment #7 from Anton Korobeynikov <asl at math.spbu.ru> 2011-12-03 07:23:54 CST ---
Yes, we should definitely check this. When stack is realigned then all the
variables should be saved / restored relative to frame pointer.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec  3 12:14:58 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 03 Dec 2011 18:14:58 +0000
Subject: [LLVMbugs] [Bug 11462] __is_final intrinsic
In-Reply-To: <bug-11462-206@http.llvm.org/bugs/>
References: <bug-11462-206@http.llvm.org/bugs/>
Message-ID: <bug-11462-206-0bSEFSz44U@http.llvm.org/bugs/>

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

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-12-03 12:14:58 CST ---
Committed as r145775, 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 Dec  3 15:33:20 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 03 Dec 2011 21:33:20 +0000
Subject: [LLVMbugs] [Bug 10282] [SPARC] Assertion in Tail Duplication
In-Reply-To: <bug-10282-206@http.llvm.org/bugs/>
References: <bug-10282-206@http.llvm.org/bugs/>
Message-ID: <bug-10282-206-MUAMymfxtB@http.llvm.org/bugs/>

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

Venkatraman Govindaraju <venkatra at cs.wisc.edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |venkatra at cs.wisc.edu
         Resolution|                            |FIXED

--- Comment #1 from Venkatraman Govindaraju <venkatra at cs.wisc.edu> 2011-12-03 15:33:20 CST ---
Fixed in r145779.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec  3 17:49:54 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 03 Dec 2011 23:49:54 +0000
Subject: [LLVMbugs] [Bug 11322] Wrong constructor order for ARM/ELF
In-Reply-To: <bug-11322-206@http.llvm.org/bugs/>
References: <bug-11322-206@http.llvm.org/bugs/>
Message-ID: <bug-11322-206-xRQOVKp6wZ@http.llvm.org/bugs/>

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

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

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

--- Comment #11 from Anton Korobeynikov <asl at math.spbu.ru> 2011-12-03 17:49:54 CST ---
Commited in r145781. 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 Dec  3 23:51:16 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 04 Dec 2011 05:51:16 +0000
Subject: [LLVMbugs] [Bug 11474] New: colorized printing is not atomic
Message-ID: <bug-11474-206@http.llvm.org/bugs/>

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

             Bug #: 11474
           Summary: colorized printing is not atomic
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: balicki.aleksander at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 7666
  --> http://llvm.org/bugs/attachment.cgi?id=7666
screenshot of colorizing bug

The output colorizing of 'warning' sometimes contaminates other text, when
doing a multithreaded build with make (i.e. make -j4)

There should be some kind of locking, to print the whole message out, so there
will be no problems whem multiple processes are writing to stdout.

Attached screenshot with 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  Sun Dec  4 00:13:12 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 04 Dec 2011 06:13:12 +0000
Subject: [LLVMbugs] [Bug 11401]
 lib/CodeGen/SelectionDAG/ScheduleDAGRRList.cpp:825: void
 {anonymous}::ScheduleDAGRRList::UnscheduleNodeBottomUp(llvm::SUnit*):
 Assertion `NumLiveRegs > 0 && "NumLiveRegs is already zero!"' failed.
In-Reply-To: <bug-11401-206@http.llvm.org/bugs/>
References: <bug-11401-206@http.llvm.org/bugs/>
Message-ID: <bug-11401-206-uyF8YCOfd6@http.llvm.org/bugs/>

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

Nico Weber <nicolasweber at gmx.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |nicolasweber at gmx.de
         Resolution|                            |DUPLICATE

--- Comment #2 from Nico Weber <nicolasweber at gmx.de> 2011-12-04 00:13:12 CST ---


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

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec  4 01:41:10 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 04 Dec 2011 07:41:10 +0000
Subject: [LLVMbugs] [Bug 11475] New: LLVMgold.so link segfault
Message-ID: <bug-11475-206@http.llvm.org/bugs/>

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

             Bug #: 11475
           Summary: LLVMgold.so link segfault
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Support Libraries
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: mario.fetka at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


ld is crashing when the -plugin is specified more then once.

here the output of a compile:

x86_64-pc-linux-gnu-gcc -c  -I/usr/include -D_REENTRANT -D_GNU_SOURCE
-fno-strict-aliasing -pipe -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -march=k8
-msse3 -O2 -pipe --plugin=/usr/lib64/llvm/dragonegg.so    -DVERSION=\"2.043\"
-DXS_VERSION=\"2.043\" -fPIC
"-I/usr/lib64/perl5/5.12.4/x86_64-linux-thread-multi/CORE"  -DNO_VIZ  
-DGZIP_OS_CODE=3 -DUSE_PPPORT_H Zlib.c
rm -f blib/arch/auto/Compress/Raw/Zlib/Zlib.so
LD_RUN_PATH="/usr/lib64" x86_64-pc-linux-gnu-gcc  -shared -march=k8 -msse3 -O2
-pipe --plugin=/usr/lib64/llvm/dragonegg.so -Wl,--hash-style=gnu,-O1
-Wl,--as-needed -Wl,-plugin=/usr/lib64/llvm/LLVMgold.so  Zlib.o
-Wl,--hash-style=gnu,-O1 -Wl,--as-needed
-Wl,-plugin=/usr/lib64/llvm/LLVMgold.so  -o
blib/arch/auto/Compress/Raw/Zlib/Zlib.so  \
   -L/usr/lib64 -lz     \

collect2: ld mit Signal 11 [Speicherzugriffsfehler] beendet
make: *** [blib/arch/auto/Compress/Raw/Zlib/Zlib.so] Fehler 1

as you can see the LLVMgold.so is added twize 
it schould not crash with 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  Sun Dec  4 04:09:37 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 04 Dec 2011 10:09:37 +0000
Subject: [LLVMbugs] [Bug 8474] #pragma weak recursion crashes clang
In-Reply-To: <bug-8474-206@http.llvm.org/bugs/>
References: <bug-8474-206@http.llvm.org/bugs/>
Message-ID: <bug-8474-206-Q5VkURgvsd@http.llvm.org/bugs/>

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

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-12-04 04:09:37 CST ---
Closing as per the above comments.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec  4 09:33:14 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 04 Dec 2011 15:33:14 +0000
Subject: [LLVMbugs] [Bug 11476] New: InlineSpiller generates invalid
	register values
Message-ID: <bug-11476-206@http.llvm.org/bugs/>

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

             Bug #: 11476
           Summary: InlineSpiller generates invalid register values
           Product: libraries
           Version: trunk
          Platform: All
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Register Allocator
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: hfinkel at anl.gov
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Running llc (trunk 145766) on the attached input generates a crash because
foldMemoryOperand is calling TargetInstrInfo::foldMemoryOperand which is
calling PPCInstrInfo::storeRegToStackSlot with an invalid register number.

The actual backtrace is (abbreviated):
Unhandled reg in PPCRegisterInfo::getRegisterNumbering!
UNREACHABLE executed at
/src/llvm-trunk-writable/lib/Target/PowerPC/MCTargetDesc/PPCBaseInfo.h:64!
...
#2  0x0000000001533aa1 in llvm::llvm_unreachable_internal (msg=0x16cd920
"Unhandled reg in PPCRegisterInfo::getRegisterNumbering!",
    file=0x16cd8c0
"/src/llvm-trunk-writable/lib/Target/PowerPC/MCTargetDesc/PPCBaseInfo.h",
line=64)
    at /src/llvm-trunk-writable/lib/Support/ErrorHandling.cpp:98
#3  0x0000000000d38dda in getPPCRegisterNumbering (RegEnum=2147483882)
    at
/src/llvm-trunk-writable/lib/Target/PowerPC/MCTargetDesc/PPCBaseInfo.h:64
#4  0x0000000000d3aad3 in llvm::PPCInstrInfo::StoreRegToStackSlot
(this=0x2438730, MF=..., SrcReg=2147483882, isKill=false, FrameIdx=3,
RC=0x1ef3e00, NewMIs=...)
    at /src/llvm-trunk-writable/lib/Target/PowerPC/PPCInstrInfo.cpp:423
#5  0x0000000000d3b01a in llvm::PPCInstrInfo::storeRegToStackSlot
(this=0x2438730, MBB=..., MI=..., SrcReg=2147483882, isKill=false, FrameIdx=3,
RC=0x1ef3e00,
    TRI=0x2438758) at
/src/llvm-trunk-writable/lib/Target/PowerPC/PPCInstrInfo.cpp:497
#6  0x00000000011fb0dc in llvm::TargetInstrInfo::foldMemoryOperand
(this=0x2438730, MI=..., Ops=..., FI=3)
    at /src/llvm-trunk-writable/lib/CodeGen/TargetInstrInfoImpl.cpp:321
#7  0x00000000012224aa in foldMemoryOperand (this=0x223c300, MI=..., Ops=...,
LoadMI=0x0)
    at /src/llvm-trunk-writable/lib/CodeGen/InlineSpiller.cpp:1044
#8  0x00000000012230f1 in spillAroundUses (this=0x223c300, Reg=2147483881) at
/src/llvm-trunk-writable/lib/CodeGen/InlineSpiller.cpp:1175
#9  0x000000000122370b in spillAll (this=0x223c300) at
/src/llvm-trunk-writable/lib/CodeGen/InlineSpiller.cpp:1238
#10 0x0000000001223b8f in spill (this=0x223c300, edit=...) at
/src/llvm-trunk-writable/lib/CodeGen/InlineSpiller.cpp:1286
#11 0x00000000011625f5 in selectOrSplit (this=0x2450ad0, VirtReg=...,
NewVRegs=...)
    at /src/llvm-trunk-writable/lib/CodeGen/RegAllocGreedy.cpp:1593
#12 0x000000000114e020 in llvm::RegAllocBase::allocatePhysRegs (this=0x2450af0)
at /src/llvm-trunk-writable/lib/CodeGen/RegAllocBasic.cpp:322
#13 0x0000000001162a21 in runOnMachineFunction (this=0x2450ad0, mf=...) at
/src/llvm-trunk-writable/lib/CodeGen/RegAllocGreedy.cpp:1630
...
(gdb) up
#3  0x0000000000d38dda in getPPCRegisterNumbering (RegEnum=2147483882)
    at
/src/llvm-trunk-writable/lib/Target/PowerPC/MCTargetDesc/PPCBaseInfo.h:64
64          llvm_unreachable("Unhandled reg in
PPCRegisterInfo::getRegisterNumbering!");
(gdb) up
#4  0x0000000000d3aad3 in llvm::PPCInstrInfo::StoreRegToStackSlot
(this=0x2438730, MF=..., SrcReg=2147483882, isKill=false, FrameIdx=3,
RC=0x1ef3e00, NewMIs=...)
    at /src/llvm-trunk-writable/lib/Target/PowerPC/PPCInstrInfo.cpp:423
423             unsigned ShiftBits = getPPCRegisterNumbering(SrcReg)*4;
(gdb) up
#5  0x0000000000d3b01a in llvm::PPCInstrInfo::storeRegToStackSlot
(this=0x2438730, MBB=..., MI=..., SrcReg=2147483882, isKill=false, FrameIdx=3,
RC=0x1ef3e00, 
    TRI=0x2438758) at
/src/llvm-trunk-writable/lib/Target/PowerPC/PPCInstrInfo.cpp:497
497       if (StoreRegToStackSlot(MF, SrcReg, isKill, FrameIdx, RC, NewMIs)) {
(gdb) up
#6  0x00000000011fb0dc in llvm::TargetInstrInfo::foldMemoryOperand
(this=0x2438730, MI=..., Ops=..., FI=3)
    at /src/llvm-trunk-writable/lib/CodeGen/TargetInstrInfoImpl.cpp:321
321         storeRegToStackSlot(*MBB, Pos, MO.getReg(), MO.isKill(), FI, RC,
TRI);
...
(gdb) p *MI
$3 = (llvm::MachineInstr &) @0x2695a68: {<llvm::ilist_node<llvm::MachineInstr>>
= {<llvm::ilist_half_node<llvm::MachineInstr>> = {Prev = 0x284e660},
    Next = 0x284e5b0}, MCID = 0x1e5c3a0, Flags = 0 '\000', AsmPrinterFlags = 0
'\000', Operands = std::vector of length 2, capacity 2 = {{OpKind = 0 '\000',
      SubReg = 0 '\000', TargetFlags = 0 '\000', IsDef = true, IsImp = false,
IsKill = false, IsDead = false, IsUndef = false, IsEarlyClobber = false,
      IsDebug = false, SmallContents = {RegNo = 2147483881, OffsetLo =
2147483881}, ParentMI = 0x2695a68, Contents = {MBB = 0x2282008, CFP =
0x2282008,
        CI = 0x2282008, ImmVal = 36184072, MD = 0x2282008, Sym = 0x2282008, Reg
= {Prev = 0x2282008, Next = 0x24fe240}, OffsetedInfo = {Val = {Index =
36184072,
            SymbolName = 0x2282008 "?&\002", GV = 0x2282008, BA = 0x2282008},
OffsetHi = 38789696}}}, {OpKind = 0 '\000', SubReg = 0 '\000', TargetFlags = 0
'\000',
      IsDef = false, IsImp = false, IsKill = false, IsDead = false, IsUndef =
false, IsEarlyClobber = false, IsDebug = false, SmallContents = {RegNo =
2147483882,
        OffsetLo = 2147483882}, ParentMI = 0x2695a68, Contents = {MBB =
0x249a308, CFP = 0x249a308, CI = 0x249a308, ImmVal = 38380296, MD = 0x249a308,
        Sym = 0x249a308, Reg = {Prev = 0x249a308, Next = 0x0}, OffsetedInfo =
{Val = {Index = 38380296, SymbolName = 0x249a308 "\360\221&\002", GV =
0x249a308,
            BA = 0x249a308}, OffsetHi = 0}}}}, MemRefs = 0x0, MemRefsEnd = 0x0,
Parent = 0x2618cb8, debugLoc = {LineCol = 0, ScopeIdx = 0}}

(so the MI being provided to TargetInstrInfo::foldMemoryOperand by
foldMemoryOperand in InlineSpiller has a register with an invalid number (does
that large number indicate a virtual register?))

0.    Program arguments: llc -o /tmp/tscvec.s /tmp/tscvec.ll 
1.    Running pass 'Function Pass Manager' on module '/tmp/tscvec.ll'.
2.    Running pass 'Greedy Register Allocator' on function '@s3110'


I've tried running this under valgrind on both linux/ppc64 and linux/x86_64,
and the crash is the same on both systems, and on both systems, valgrind gives
the process of clean bill of health.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec  4 14:26:07 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 04 Dec 2011 20:26:07 +0000
Subject: [LLVMbugs] [Bug 5329] Global ctor/dtor priorities not codegened
	correctly
In-Reply-To: <bug-5329-206@http.llvm.org/bugs/>
References: <bug-5329-206@http.llvm.org/bugs/>
Message-ID: <bug-5329-206-Pzxkzmr35Q@http.llvm.org/bugs/>

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

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

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

--- Comment #5 from Anton Korobeynikov <asl at math.spbu.ru> 2011-12-04 14:26:07 CST ---
Ok, in fact the patch is incomplete. While it will solve the stuff in the
single .o file, it won't solve the problem when several functions are emitted
into the different .o files - the linker will just merge the init_array
sections alltogether thus making the construction priorities bogus.

The solution I can think of is to emit the functions with constructor priority
N into the section, say, init_array.N and dtor - init_array.(65535-N). This way
everything will be ok.

Also, we should not worry about Darwin - according to Nick Kledzik, Darwin does
not support ctor / dtor priorities at all.

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

From bugzilla-daemon at llvm.org  Sun Dec  4 18:08:52 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 05 Dec 2011 00:08:52 +0000
Subject: [LLVMbugs] [Bug 10971] Due to bad hash functions,
 unordered_set can easily give horrible performance
In-Reply-To: <bug-10971-206@http.llvm.org/bugs/>
References: <bug-10971-206@http.llvm.org/bugs/>
Message-ID: <bug-10971-206-yBIeBvjqVZ@http.llvm.org/bugs/>

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

Howard Hinnant <hhinnant at apple.com> changed:

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

--- Comment #2 from Howard Hinnant <hhinnant at apple.com> 2011-12-04 18:08:52 CST ---
I've decided to close this as "behaves correctly".  It wasn't without a lot of
thought and testing though.

A colleague I highly respect (Dave Zarzycki) summed it up this way:

As for std::hash<int>, the problem that pr10971 is asking
you to try and solve is essentially this: "magically figure
out what the high entropy bits are in a random int and
somehow magically redistribute that entropy to the low
entropy bits in the int"

Note that this decision only impacts the hash<scalar> where sizeof(scalar) <=
sizeof(size_t).

I ran lots of tests measuring collisions with many different distributions of
size_t.  The only one I came across that had bad performance was if the key was
a linear with a slope of a prime number:  And not just any prime, but the prime
corresponding to the number of buckets.  And even then, the prime had to be
fairly large for there to be a noticeable impact.  And as soon as the table
automatically rehashes, the problem not only disappears, the identity function
reverts to a perfect hash.

The other hash functions I tested, did not suffer the "multiple of a prime"
problem.  But they were consistently slower and resulted in more collisions
much more often.  I'm not saying that identity is the perfect hashing function.
 But I am saying that it is a good default for containers which restrict the
number of buckets to a prime.  Had I been dealing with containers where the
number of buckets is a power of 2, I'm sure I would've come to a different
conclusion.  Indeed, this was a big influence in pushing me away from such hash
container implementations years 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  Mon Dec  5 00:42:22 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 05 Dec 2011 06:42:22 +0000
Subject: [LLVMbugs] [Bug 11477] New: The version list for clang does not
	include 3.0
Message-ID: <bug-11477-206@http.llvm.org/bugs/>

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

             Bug #: 11477
           Summary: The version list for clang does not include 3.0
           Product: Bugzilla Admin
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: UI
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: Dave at Yost.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec  5 00:46:29 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 05 Dec 2011 06:46:29 +0000
Subject: [LLVMbugs] [Bug 11478] New: clang -std=c++0x should report use of
 (obsolete) typeof keyword
Message-ID: <bug-11478-206@http.llvm.org/bugs/>

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

             Bug #: 11478
           Summary: clang -std=c++0x should report use of (obsolete)
                    typeof keyword
           Product: clang
           Version: 2.9
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: C++0x
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: Dave at Yost.com
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified


clang -std=c++0x should report use of (obsolete) typeof keyword and suggest use
of decltype instead.

Instead clang gives inscrutable error messages.

0 280 Z% cat typeofbug.cpp
template<typename T>
class foo {
  typedef typeof(T() - T()) differenceType;
};
0 281 Z% clang -std=c++0x -c typeofbug.cpp
typeofbug.cpp:3:22: error: expected ')'
  typedef typeof(T() - T()) differenceType;
                     ^
typeofbug.cpp:3:17: note: to match this '('
  typedef typeof(T() - T()) differenceType;
                ^
typeofbug.cpp:3:11: error: C++ requires a type specifier for all declarations
  typedef typeof(T() - T()) differenceType;
  ~~~~~~~ ^
typeofbug.cpp:3:28: error: expected ';' at end of declaration list
  typedef typeof(T() - T()) differenceType;
                           ^
                           ;
3 errors generated.
1 282 Z%

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec  5 00:51:54 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 05 Dec 2011 06:51:54 +0000
Subject: [LLVMbugs] [Bug 11479] New: [MC] llvm-mc crashes with symbol of
 .file directive same as a function name
Message-ID: <bug-11479-206@http.llvm.org/bugs/>

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

             Bug #: 11479
           Summary: [MC] llvm-mc crashes with symbol of .file directive
                    same as a function name
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Core LLVM classes
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: lihaitao+llvmbugs at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 7669
  --> http://llvm.org/bugs/attachment.cgi?id=7669
test case

llvm-mc crashes when compiling the attached t.s file.

The .s file is generated by a frontend which encodes .file directive value
without a suffix.

If the first line is '.file "t.bc" instead of '.file "t"', llvm-mc works as
expected.

$ llvm-mc -filetype=obj -o t.o t.s
llvm-mc: /home/***/src/llvm/include/llvm/MC/MCSymbol.h:111: const
llvm::MCSection &llvm::MCSymbol::getSection() const: Assertion `isInSection()
&& "Invalid accessor!"' failed.
$ llvm-mc -version
Low Level Virtual Machine (http://llvm.org/):
  llvm version 3.1svn
  DEBUG build with assertions.
  Built Dec  5 2011 (10:03:25).
  Default target: i386-pc-linux-gnu
  Host CPU: corei7


(gdb) bt
#0  0xb7fe1424 in __kernel_vsyscall ()
#1  0xb7d46e71 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#2  0xb7d4a34e in abort () at abort.c:92
#3  0xb7d3f888 in __assert_fail (assertion=0x8434fd3 "isInSection() &&
\"Invalid accessor!\"", 
    file=0x8434ff8 "/home/***/src/llvm/include/llvm/MC/MCSymbol.h", line=111,
function=0x843502a "const llvm::MCSection &llvm::MCSymbol::getSection() const")
    at assert.c:81
#4  0x08232a17 in llvm::MCSymbol::getSection (this=0x86a8f90) at
/home/***/src/llvm/include/llvm/MC/MCSymbol.h:111
#5  0x0835a5e6 in llvm::MCObjectWriter::IsSymbolRefDifferenceFullyResolvedImpl
(this=0x86aac18, Asm=..., DataA=..., FB=..., InSet=false, IsPCRel=true)
    at /home/***/src/llvm/lib/MC/MCObjectWriter.cpp:84
#6  0x083064ac in llvm::ELFObjectWriter::IsSymbolRefDifferenceFullyResolvedImpl
(this=0x86aac18, Asm=..., DataA=..., FB=..., InSet=false, IsPCRel=true)
    at /home/***/src/llvm/lib/MC/ELFObjectWriter.cpp:1254
#7  0x083241a0 in llvm::MCAssembler::EvaluateFixup (this=0x86aaaa0, Layout=...,
Fixup=..., DF=0x86ac120, Target=..., Value=@0xbfffedc0)
    at /home/***/src/llvm/lib/MC/MCAssembler.cpp:266
#8  0x08325a14 in llvm::MCAssembler::HandleFixup (this=0x86aaaa0, Layout=...,
F=..., Fixup=...) at /home/***/src/llvm/lib/MC/MCAssembler.cpp:555
#9  0x08326230 in llvm::MCAssembler::Finish (this=0x86aaaa0) at
/home/***/src/llvm/lib/MC/MCAssembler.cpp:624
#10 0x0835940d in llvm::MCObjectStreamer::Finish (this=0x86a71a0) at
/home/***/src/llvm/lib/MC/MCObjectStreamer.cpp:263
#11 0x083444be in llvm::MCELFStreamer::Finish (this=0x86a71a0) at
/home/***/src/llvm/lib/MC/MCELFStreamer.cpp:379
#12 0x08296803 in (anonymous namespace)::AsmParser::Run (this=0x86aae58,
NoInitialTextSection=false, NoFinalize=false)
    at /home/elihait/src/llvm/lib/MC/MCParser/AsmParser.cpp:524
#13 0x08056fc9 in AssembleInput (ProgName=0xbffff9f6
"/home/***/local/rust/bin/llvm-mc") at
/home/elihait/src/llvm/tools/llvm-mc/llvm-mc.cpp:449
#14 0x08054288 in main (argc=5, argv=0xbffff854) at
/home/***/src/llvm/tools/llvm-mc/llvm-mc.cpp:517

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec  5 01:45:16 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 05 Dec 2011 07:45:16 +0000
Subject: [LLVMbugs] [Bug 11480] New: attribute((init_array(N))) is not
 codegen'ed properly
Message-ID: <bug-11480-206@http.llvm.org/bugs/>

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

             Bug #: 11480
           Summary: attribute((init_array(N))) is not codegen'ed properly
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: LLVM Codegen
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: asl at math.spbu.ru
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Right now attribute((init_array(N))) in clang defines the "local" order of
initialization of statics in the same TU. However, gcc's behavior for
init_array(N) is same as for constructor(N) - global priority wrt all TUs.

The solution seems to be easy - instead of emission of the single global
initialization function, emit one for each priority and rely on the priorities
in the LLVM's global_ctor / global_dtor section. There, if the target supports
the ctor / dtor priorities, then everything will be emitted in the appropriate
order. Otherwise (e.g. on Darwin, which does not support the priorities), we'll
emit everything into the single section with the proper priority order.

Does this sound 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  Mon Dec  5 05:21:55 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 05 Dec 2011 11:21:55 +0000
Subject: [LLVMbugs] [Bug 11481] New: Clang binaries for Ubuntu 11.10/x86
 contain 64-bit executables (not 32-bit ones)
Message-ID: <bug-11481-206@http.llvm.org/bugs/>

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

             Bug #: 11481
           Summary: Clang binaries for Ubuntu 11.10/x86 contain 64-bit
                    executables (not 32-bit ones)
           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: garen.p at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Simple repro from CLI session:

$ wget
http://llvm.org/releases/3.0/clang+llvm-3.0-i386-linux-Ubuntu-11_10.tar.gz
$ tar xzvfp clang+llvm-3.0-i386-linux-debian.tar.gz
$ ./clang+llvm-3.0-x86_64-linux-Ubuntu-11_10/bin/clang -v
-bash: ./clang+llvm-3.0-x86_64-linux-Ubuntu-11_10/bin/clang: cannot execute
binary file
$ file clang+llvm-3.0-x86_64-linux-Ubuntu-11_10/bin/clang
clang+llvm-3.0-x86_64-linux-Ubuntu-11_10/bin/clang: ELF 64-bit LSB executable,
x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux
2.6.15, stripped

Note the "ELF 64-bit" part in the last command.

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

From bugzilla-daemon at llvm.org  Mon Dec  5 11:54:59 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 05 Dec 2011 17:54:59 +0000
Subject: [LLVMbugs] [Bug 11482] New: UppercaseString was not declared in
	this scope
Message-ID: <bug-11482-206@http.llvm.org/bugs/>

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

             Bug #: 11482
           Summary: UppercaseString was not declared in this scope
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: release blocker
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: apacherulzz at yahoo.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Clean build of trunk...

llvm[3]: Compiling ClangDiagnosticsEmitter.cpp for Release+Asserts build
/opt/llvm/llvm/tools/clang/utils/TableGen/ClangDiagnosticsEmitter.cpp: In
member function ?virtual void
llvm::ClangDiagsDefsEmitter::run(llvm::raw_ostream&)?:
/opt/llvm/llvm/tools/clang/utils/TableGen/ClangDiagnosticsEmitter.cpp:133:
error: ?UppercaseString? was not declared in this scope

This is the only place UppercaseString appears in the entire llvm checkout, not
sure what was intended here but perhaps an include is missing?

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec  5 11:55:07 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 05 Dec 2011 17:55:07 +0000
Subject: [LLVMbugs] [Bug 11483] New: Crash in libclang when reparsing
Message-ID: <bug-11483-206@http.llvm.org/bugs/>

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

             Bug #: 11483
           Summary: Crash in libclang when reparsing
           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
    Classification: Unclassified


Created attachment 7671
  --> http://llvm.org/bugs/attachment.cgi?id=7671
Test program

The attached program demonstrates a crash in libclang.  The before.m and
after.m files are two versions of the same (preprocessed) source file.  after.m
has had the word 'static' added on a new line after some existing top-level
declarations.  When reparsing with after.m passed as an unsaved buffer,
libclang crashes.

The clangTest.c file contains a simple program that demonstrates the crash.

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

From bugzilla-daemon at llvm.org  Mon Dec  5 12:23:51 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 05 Dec 2011 18:23:51 +0000
Subject: [LLVMbugs] [Bug 11482] UppercaseString was not declared in this
	scope
In-Reply-To: <bug-11482-206@http.llvm.org/bugs/>
References: <bug-11482-206@http.llvm.org/bugs/>
Message-ID: <bug-11482-206-dutNqnbl7C@http.llvm.org/bugs/>

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

Benjamin Kramer <benny.kra at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |benny.kra at gmail.com
         Resolution|                            |INVALID

--- Comment #1 from Benjamin Kramer <benny.kra at gmail.com> 2011-12-05 12:23:51 CST ---
Your LLVM and clang checkouts are out of sync. "make update" will fix that for
you.

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

From bugzilla-daemon at llvm.org  Mon Dec  5 15:48:18 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 05 Dec 2011 21:48:18 +0000
Subject: [LLVMbugs] [Bug 9395] open source project ITK, when built with clang,
 has many failing unit tests
In-Reply-To: <bug-9395-206@http.llvm.org/bugs/>
References: <bug-9395-206@http.llvm.org/bugs/>
Message-ID: <bug-9395-206-gZPsa3CmAa@http.llvm.org/bugs/>

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

John McCall <rjmccall at apple.com> changed:

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

--- Comment #16 from John McCall <rjmccall at apple.com> 2011-12-05 15:48:18 CST ---
The specified behavior of 'noreturn' is that the function is not allowed to
return.  The GCC manual is quite explicit about this, saying that the compiler
and optimizer can freely assume that the function does not return, etc.  This
is exactly what Clang is doing.  That you've found an example where GCC happens
to not produce code that crashes when you violate the rules does not mean that
your code is sound;  it's more akin to writing past the end of a local
variable, which is a bug that may or may not be exposed depending on a lot of
contextual and internal details that vary from compiler to compiler (and
version to version).  And much like that example, the right thing to do here is
to fix your code, in this case by removing 'noreturn' from the overridden
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  Mon Dec  5 16:52:14 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 05 Dec 2011 22:52:14 +0000
Subject: [LLVMbugs] [Bug 11477] The version list for clang does not include
	3.0
In-Reply-To: <bug-11477-206@http.llvm.org/bugs/>
References: <bug-11477-206@http.llvm.org/bugs/>
Message-ID: <bug-11477-206-856i3vloLt@http.llvm.org/bugs/>

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

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-12-05 16:52:14 CST ---
fixed, 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 Dec  5 17:24:26 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 05 Dec 2011 23:24:26 +0000
Subject: [LLVMbugs] [Bug 11484] New: "can't implicitly cast lvalue to rvalue
 with this cast kind" assertion reached while compiling libc++
Message-ID: <bug-11484-206@http.llvm.org/bugs/>

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

             Bug #: 11484
           Summary: "can't implicitly cast lvalue to rvalue with this cast
                    kind" assertion reached while compiling libc++
           Product: clang
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: devlists at shadowlab.org
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 7674
  --> http://llvm.org/bugs/attachment.cgi?id=7674
Test case

While trying to compile libc++ (after revision r145698 of libcxx), clang
trigger an assertion when using Mac OS 10.6 SDK.

I managed to reduce the issue to the 2 lines attached test case.

$ clang++ -std=c++11 crash.ii
Assertion failed: (0 && "can't implicitly cast lvalue to rvalue with this cast
kind"), function ImpCastExprToType, file
/Users/jddupas/Projects/OpenSource/llvm/tools/clang/lib/Sema/Sema.cpp, line
248.
?


You can also reproduce the original problem by compiling a file that include
<system_error> using 10.6 SDK (you need to have a trunk clang with trunk libcxx
headers)

$ echo "#include <system_error>" > crash.cpp
$ clang++ -std=c++11 -U__STRICT_ANSI__ -stdlib=libc++ -isysroot
/Developer/SDKs/MacOSX10.6.sdk/ -c crash.cpp
Assertion failed: (0 && "can't implicitly cast lvalue to rvalue with this cast
kind"), function ImpCastExprToType, file
/Users/jddupas/Projects/OpenSource/llvm/tools/clang/lib/Sema/Sema.cpp, line
248.
?
3  clang             0x00000001030b5bf6
clang::DeclContext::lookup(clang::DeclarationName) + 630
4  clang             0x0000000103aca566 abort + 22
5  clang             0x0000000103aca525 __assert_rtn + 53
6  clang             0x0000000102b6a5ff
clang::Sema::ImpCastExprToType(clang::Expr*, clang::QualType, clang::CastKind,
clang::ExprValueKind, llvm::SmallVector<clang::CXXBaseSpecifier*, 4u> const*,
clang::Sema::CheckedConversionKind) + 95
7  clang             0x0000000102c04bbd
clang::Sema::CheckEnumConstant(clang::EnumDecl*, clang::EnumConstantDecl*,
clang::SourceLocation, clang::IdentifierInfo*, clang::Expr*) + 1037
8  clang             0x0000000102c05b76
clang::Sema::ActOnEnumConstant(clang::Scope*, clang::Decl*, clang::Decl*,
clang::SourceLocation, clang::IdentifierInfo*, clang::AttributeList*,
clang::SourceLocation, clang::Expr*) + 726
9  clang             0x0000000102b097d9
clang::Parser::ParseEnumBody(clang::SourceLocation, clang::Decl*) + 729
10 clang             0x0000000102b06d03
clang::Parser::ParseEnumSpecifier(clang::SourceLocation, clang::DeclSpec&,
clang::Parser::ParsedTemplateInfo const&, clang::AccessSpecifier) + 2675
11 clang             0x0000000102b035ac
clang::Parser::ParseDeclarationSpecifiers(clang::DeclSpec&,
clang::Parser::ParsedTemplateInfo const&, clang::AccessSpecifier,
clang::Parser::DeclSpecContext) + 5788
?

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec  5 18:11:08 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 06 Dec 2011 00:11:08 +0000
Subject: [LLVMbugs] [Bug 11484] "can't implicitly cast lvalue to rvalue with
 this cast kind" assertion reached while compiling libc++
In-Reply-To: <bug-11484-206@http.llvm.org/bugs/>
References: <bug-11484-206@http.llvm.org/bugs/>
Message-ID: <bug-11484-206-66JBTulI6K@http.llvm.org/bugs/>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |sharparrow1 at yahoo.com
         Resolution|                            |FIXED

--- Comment #1 from Eli Friedman <sharparrow1 at yahoo.com> 2011-12-05 18:11:08 CST ---
r145874.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec  5 19:46:27 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 06 Dec 2011 01:46:27 +0000
Subject: [LLVMbugs] [Bug 11485] New: Division by power of two expansion
 blocked by other flag
Message-ID: <bug-11485-206@http.llvm.org/bugs/>

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

             Bug #: 11485
           Summary: Division by power of two expansion blocked by other
                    flag
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Common Code Generator Code
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: javier.e.martinez at intel.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 7675
  --> http://llvm.org/bugs/attachment.cgi?id=7675
Fix for expanding integer division by 2

Assume that a target can do integer division cheaply but not as cheap as
shifts. This target would call setIntDivIsCheap(true) and
setPow2DivIsCheap(false). The issue is that the DAGCombiner visitSDIV punts if
isIntDivCheap is true. The fix is to check for isPow2DivCheap instead. Below is
the current code and the fix. A patch is also attached.

[CURRENT]
  // fold (sdiv X, pow2) -> simple ops after legalize
  if (N1C && !N1C->isNullValue() && !TLI.isIntDivCheap() &&
      (N1C->getAPIntValue().isPowerOf2() ||
       (-N1C->getAPIntValue()).isPowerOf2())) {
    // If dividing by powers of two is cheap, then don't perform the following
    // fold.
    if (TLI.isPow2DivCheap())
      return SDValue();

    unsigned lg2 = N1C->getAPIntValue().countTrailingZeros();

[FIX]
  // fold (sdiv X, pow2) -> simple ops after legalize
  if (N1C && !N1C->isNullValue() && !TLI.isPow2DivCheap() &&
      (N1C->getAPIntValue().isPowerOf2() ||
       (-N1C->getAPIntValue()).isPowerOf2())) {

    unsigned lg2 = N1C->getAPIntValue().countTrailingZeros();

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec  5 23:20:01 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 06 Dec 2011 05:20:01 +0000
Subject: [LLVMbugs] [Bug 11486] New: union { struct { }; } foo = { .bar = 0 };
Message-ID: <bug-11486-206@http.llvm.org/bugs/>

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

             Bug #: 11486
           Summary: union { struct { }; } foo = { .bar = 0 };
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: chisophugis at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 7676
  --> http://llvm.org/bugs/attachment.cgi?id=7676
Clang's error dump

That's about it.

$ cat >kill-clang.c
union { struct { }; } foo = { .bar = 0 };
$ clang -c kill-clang.c
<<long error dump (attached)>>

Another variation that seems to cause the same crash:
int x = (union { struct { }; }) { .bar = 0 };




$ clang --version                 
clang version 2.9 (tags/RELEASE_29/final)
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  Tue Dec  6 01:25:11 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 06 Dec 2011 07:25:11 +0000
Subject: [LLVMbugs] [Bug 11486] union { struct { }; } foo = { .bar = 0 };
In-Reply-To: <bug-11486-206@http.llvm.org/bugs/>
References: <bug-11486-206@http.llvm.org/bugs/>
Message-ID: <bug-11486-206-4QsqTzJPI7@http.llvm.org/bugs/>

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

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

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

--- Comment #1 from Anton Korobeynikov <asl at math.spbu.ru> 2011-12-06 01:25:11 CST ---
Works for me on ToT / 3.0:


$ clang -c 2.c 
2.c:1:32: error: field designator 'bar' does not refer to any field in type
'union <anonymous at 2.c:1:1>'
union { struct { }; } foo = { .bar = 0 };
                               ^
2.c:2:36: error: field designator 'bar' does not refer to any field in type
'union <anonymous at 2.c:2:10>'
int x = (union { struct { }; }) { .bar = 0 };
                                   ^
2 errors 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 Dec  6 03:49:14 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 06 Dec 2011 09:49:14 +0000
Subject: [LLVMbugs] [Bug 2709] incorrect parser handling of Obj-C @interface
 ... @end scope
In-Reply-To: <bug-2709-206@http.llvm.org/bugs/>
References: <bug-2709-206@http.llvm.org/bugs/>
Message-ID: <bug-2709-206-mG6iiFjdHA@http.llvm.org/bugs/>

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

Erik Verbruggen <Erik.Verbruggen at Me.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |Erik.Verbruggen at Me.com
         Resolution|                            |FIXED

--- Comment #15 from Erik Verbruggen <Erik.Verbruggen at Me.com> 2011-12-06 03:49:14 CST ---
Fixed in rev. 145928.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec  6 04:45:00 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 06 Dec 2011 10:45:00 +0000
Subject: [LLVMbugs] [Bug 11487] New: pointers to data members in unions are
 not initialized to -1
Message-ID: <bug-11487-206@http.llvm.org/bugs/>

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

             Bug #: 11487
           Summary: pointers to data members in unions are not initialized
                    to -1
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: LLVM Codegen
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: shatrov at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 7677
  --> http://llvm.org/bugs/attachment.cgi?id=7677
test case

According to C++ ABI, null pointers to data members are represented as "-1".
Clang does not obey this rule for members of a union (see the attached test
case).

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

From bugzilla-daemon at llvm.org  Tue Dec  6 05:11:12 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 06 Dec 2011 11:11:12 +0000
Subject: [LLVMbugs] [Bug 11488] New: Clang should warn on the use of
 reserved identifier/macro names
Message-ID: <bug-11488-206@http.llvm.org/bugs/>

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

             Bug #: 11488
           Summary: Clang should warn on the use of reserved
                    identifier/macro names
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Windows NT
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: vanboxem.ruben at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


For C, Clang should warn when user code uses identifiers or macros that are
implementation-reserved.

For C(99), this would mean names starting with an underscore followed by
another unerscore or capitalized letter.

For C++ a single underscore is also reserved for the global namespace.

I could have messed the above rules up, but these are the cause of a lot of
unexpected bugs, and a warning would be super-easy 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  Tue Dec  6 05:29:32 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 06 Dec 2011 11:29:32 +0000
Subject: [LLVMbugs] [Bug 11489] New: opt -gvn: Assertion `isa<X>(Val) &&
 "cast<Ty>() argument of incompatible type!
Message-ID: <bug-11489-206@http.llvm.org/bugs/>

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

             Bug #: 11489
           Summary: opt -gvn: Assertion `isa<X>(Val) && "cast<Ty>()
                    argument of incompatible type!
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Global Analyses
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: eugeni.stepanov at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


# opt -gvn 1.ll -o 1.bc

opt: clang_src/include/llvm/Support/Casting.h:194: typename
llvm::cast_retty<To, From>::ret_type llvm::cast(const Y&) [with X =
llvm::Instruction, Y = llvm::User*]: Assertion `isa<X>(Val) && "cast<Ty>()
argument of incompatible type!"' failed.
0  opt             0x0000000000900e0f
1  opt             0x0000000000903082
2  libpthread.so.0 0x00007f4143b068f0
3  libc.so.6       0x00007f4142df5a75 gsignal + 53
4  libc.so.6       0x00007f4142df95c0 abort + 384
5  libc.so.6       0x00007f4142dee941 __assert_fail + 241
6  opt             0x00000000007044dd
llvm::MemoryDependenceAnalysis::getModRefInfo(llvm::Instruction const*,
llvm::AliasAnalysis::Location const&) + 2605
7  opt             0x0000000000704686
llvm::MemoryDependenceAnalysis::getPointerDependencyFrom(llvm::AliasAnalysis::Location
const&, bool, llvm::ilist_iterator<llvm::Instruction>, llvm::BasicBlock*) + 230
8  opt             0x0000000000704c17
llvm::MemoryDependenceAnalysis::GetNonLocalInfoForBlock(llvm::AliasAnalysis::Location
const&, bool, llvm::BasicBlock*, std::vector<llvm::NonLocalDepEntry,
std::allocator<llvm::NonLocalDepEntry> >*, unsigned int) + 231
9  opt             0x00000000007063c0
llvm::MemoryDependenceAnalysis::getNonLocalPointerDepFromBB(llvm::PHITransAddr
const&, llvm::AliasAnalysis::Location const&, bool, llvm::BasicBlock*,
llvm::SmallVectorImpl<llvm::NonLocalDepResult>&,
llvm::DenseMap<llvm::BasicBlock*, llvm::Value*,
llvm::DenseMapInfo<llvm::BasicBlock*>, llvm::DenseMapInfo<llvm::Value*> >&,
bool) + 3520
10 opt             0x0000000000707996
llvm::MemoryDependenceAnalysis::getNonLocalPointerDependency(llvm::AliasAnalysis::Location
const&, bool, llvm::BasicBlock*,
llvm::SmallVectorImpl<llvm::NonLocalDepResult>&) + 246
11 opt             0x00000000005215d0
12 opt             0x0000000000523639
13 opt             0x00000000005243d8
14 opt             0x0000000000524d8b
15 opt             0x00000000008a471b
llvm::FPPassManager::runOnFunction(llvm::Function&) + 587
16 opt             0x00000000008a4803
llvm::FPPassManager::runOnModule(llvm::Module&) + 51
17 opt             0x00000000008a41e7
llvm::MPPassManager::runOnModule(llvm::Module&) + 503
18 opt             0x00000000008a437b llvm::PassManagerImpl::run(llvm::Module&)
+ 187
19 opt             0x00000000004c5d8d main + 4797
20 libc.so.6       0x00007f4142de0c4d __libc_start_main + 253
21 opt             0x00000000004b9c59
Stack dump:
0.    Program arguments: ./opt -gvn 1.ll -o 1.bc 
1.    Running pass 'Function Pass Manager' on module '1.ll'.
2.    Running pass 'Global Value Numbering' on function '@g'
Aborted


# cat 1.ll

; ModuleID = '1.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-S128"
target triple = "x86_64-unknown-linux-gnu"

define void @g() nounwind uwtable {
entry:
  %code = alloca i8*, align 8
  store i8* bitcast (void (...)* @f to i8*), i8** %code, align 8
  %0 = load i8** %code, align 8
  %arrayidx = getelementptr inbounds i8* %0, i64 0
  %1 = load i8* %arrayidx
  %tobool = icmp ne i8 %1, 0
  br i1 %tobool, label %if.then, label %if.end

if.then:                                          ; preds = %entry
  call void (...)* @gg()
  br label %if.end

if.end:                                           ; preds = %if.then, %entry
  %2 = load i8** %code, align 8
  %3 = load i8* %2
  call void @hh(i8 zeroext %3)
  ret void
}

declare void @f(...)

declare void @gg(...)

declare void @hh(i8 zeroext)


# This can also be reproduced with clang -c -O2 1.c
# cat 1.c

void gg();
void hh(unsigned char);
void f();

void g() {
  unsigned char *code    = (unsigned char*)f;
  if (code[0]) {
    gg();
  }
  hh(*code);
}

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

From bugzilla-daemon at llvm.org  Tue Dec  6 05:36:10 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 06 Dec 2011 11:36:10 +0000
Subject: [LLVMbugs] [Bug 11490] New: projects/sample/Makefile.llvm.config
 incorrectly configures x86_64 target as 'x86'
Message-ID: <bug-11490-206@http.llvm.org/bugs/>

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

             Bug #: 11490
           Summary: projects/sample/Makefile.llvm.config incorrectly
                    configures x86_64 target as 'x86'
           Product: Build scripts
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: Makefiles
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: vince at macports.org
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


When compiling from trunk on a x86_64 hardware, the
projects/sample/Release+Asserts/lib/libsample.a build fails because it gets
compiled for i386 rather than x86_64. This misbehavior is caused by a wrong
parameter in projects/sample/Makefile.llvm.config line 85:

# Target hardware architecture
ARCH=x86

instead of:

# Target hardware architecture
ARCH=x86_64

And so the build fails without a correcting patch. I think it is very easy to
fix.

V.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec  6 06:41:40 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 06 Dec 2011 12:41:40 +0000
Subject: [LLVMbugs] [Bug 11491] New: Stricter option for
	GCC_WARN_MISSING_PARENTHESES
Message-ID: <bug-11491-206@http.llvm.org/bugs/>

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

             Bug #: 11491
           Summary: Stricter option for GCC_WARN_MISSING_PARENTHESES
           Product: clang
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: peylow at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


GCC_WARN_MISSING_PARENTHESES gives a warning for this ambitious code;
  { if (a) if (b) foo (); else bar (); }
requiring a change to this;
  { if (a) { if (b) foo (); else bar (); } }
It would be useful to have an even stricter option requiring this;
  { if (a) { if (b) { foo (); } else { 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 Dec  6 08:50:36 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 06 Dec 2011 14:50:36 +0000
Subject: [LLVMbugs] [Bug 11492] New: llvm-config includes gtest even though
 it's not built by default
Message-ID: <bug-11492-206@http.llvm.org/bugs/>

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

             Bug #: 11492
           Summary: llvm-config includes gtest even though it's not built
                    by default
           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
    Classification: Unclassified


With a fresh checkout of 3.1 TOT, if I build using "./configure" and then "make
ENABLE_OPTIMIZED=1 DISABLE_ASSERTIONS=0 install", then if I run "llvm-config
--libs all", the output includes "-lLLVMgtest_main -lLLVMgtest" even though
those haven't been built.

(Speaking of llvm-config, the help message indicates that "backend" is allowed,
though that seems to have been removed by 144202.)

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec  6 09:45:06 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 06 Dec 2011 15:45:06 +0000
Subject: [LLVMbugs] [Bug 11493] New: missing unwind.h
Message-ID: <bug-11493-206@http.llvm.org/bugs/>

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

             Bug #: 11493
           Summary: missing unwind.h
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: ASSIGNED
          Severity: enhancement
          Priority: P
         Component: Headers
        AssignedTo: rafael.espindola at gmail.com
        ReportedBy: rafael.espindola at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


This is an interesting one. GCC includes it in most systems, but on OS X Lion
it is considered part of the SDK:

/Developer/SDKs//MacOSX10.7.sdk/usr/include/unwind.h

We need this header for systems where gcc provides it, but on Lion we probably
want to use the system one.

I can see two ways of doing this. One is to install it to
lib/clang/<ver>/include/cpuid/cpuid.h and only add that directory to the search
path on systems where cpuid.h is provided by gcc. The other one is to install
it in the regular directory (lib/clang/<ver>/include) and use an #ifdef and a
#include_next to use the system one on Lion.

I will give the #ifdef option a try.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec  6 11:00:14 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 06 Dec 2011 17:00:14 +0000
Subject: [LLVMbugs] [Bug 9665] __builtin_shufflevector requires a constant
	integer
In-Reply-To: <bug-9665-206@http.llvm.org/bugs/>
References: <bug-9665-206@http.llvm.org/bugs/>
Message-ID: <bug-9665-206-9u7QI3GZNi@http.llvm.org/bugs/>

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

Luke Dalessandro <luked at cs.rochester.edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
            Version|2.9                         |3.0
         Resolution|INVALID                     |
           Severity|normal                      |enhancement

--- Comment #2 from Luke Dalessandro <luked at cs.rochester.edu> 2011-12-06 11:00:14 CST ---
This bites me as well because Intel seems to use the (apparent) "unportable
extension" in their avx intrinsic emulation header, downloadable as
"avxintrin_emu.h" from
"http://software.intel.com/en-us/articles/avx-emulation-header-file/". The
header compiles without complaint on gcc on my Linux system up through 4.6.2.

Reproduce by downloading the header and including it in some temp.c file, and
compiling with gcc -msse2 -c temp.c -o /dev/null. 

It's an inconvenient deviation from gcc's behavior (in the sense that there
isn't any way that I can fix this header given my knowledge of SSE), so I
updated to clang 3.0 and marked as an enhancement request.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec  6 12:59:07 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 06 Dec 2011 18:59:07 +0000
Subject: [LLVMbugs] [Bug 11494] New: [AVX] incorrect code generated from
 short program with shuffles/int min/max
Message-ID: <bug-11494-206@http.llvm.org/bugs/>

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

             Bug #: 11494
           Summary: [AVX] incorrect code generated from short program with
                    shuffles/int min/max
           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: matt at pharr.org
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 7680
  --> http://llvm.org/bugs/attachment.cgi?id=7680
test case

The attached short test case does a series of 4-wide SSE4.1 pminsd/pmaxsd calls
to compute a 16-wide vector.  It should generate a vector where the first four
values are respectively <4,3,2,1> and where the rest of the values are 0s.

With the SSE target, the correct result is computed.  With AVX, the last four
values incorrectly have a value of four.

% llc -mattr=+avx bug.ll -o t.o --filetype=obj && clang t.cpp t.o && ./a.out
0    4.000000
1    3.000000
2    2.000000
3    1.000000
4    0.000000
5    0.000000
6    0.000000
7    0.000000
8    0.000000
9    0.000000
10    0.000000
11    0.000000
12    4.000000
13    4.000000
14    4.000000
15    4.000000
% llc bug.ll -o t.o --filetype=obj && clang t.cpp t.o && ./a.out
0    4.000000
1    3.000000
2    2.000000
3    1.000000
4    0.000000
5    0.000000
6    0.000000
7    0.000000
8    0.000000
9    0.000000
10    0.000000
11    0.000000
12    0.000000
13    0.000000
14    0.000000
15    0.000000
%

This bug is present in both 3.1svn and the 3.0 release.

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

From bugzilla-daemon at llvm.org  Tue Dec  6 13:05:01 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 06 Dec 2011 19:05:01 +0000
Subject: [LLVMbugs] [Bug 9665] __builtin_shufflevector requires a constant
	integer
In-Reply-To: <bug-9665-206@http.llvm.org/bugs/>
References: <bug-9665-206@http.llvm.org/bugs/>
Message-ID: <bug-9665-206-6Qc24J00j4@http.llvm.org/bugs/>

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

Chris Lattner <clattner at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
                 CC|                            |clattner at apple.com
         Resolution|                            |WONTFIX

--- Comment #3 from Chris Lattner <clattner at apple.com> 2011-12-06 13:05:01 CST ---
We're not doing this.  Please ask Intel to fix their headers, or just use the
Clang AVX headers.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec  6 16:03:22 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 06 Dec 2011 22:03:22 +0000
Subject: [LLVMbugs] [Bug 10164] Issue with objc_method_family(init) in class
	extension.
In-Reply-To: <bug-10164-206@http.llvm.org/bugs/>
References: <bug-10164-206@http.llvm.org/bugs/>
Message-ID: <bug-10164-206-Mr8aawVgfQ@http.llvm.org/bugs/>

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

Ted Kremenek <kremenek at apple.com> changed:

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

--- Comment #3 from Ted Kremenek <kremenek at apple.com> 2011-12-06 16:03:22 CST ---
I dont' see the issue here.

'self' has type 'Foo*'.  With the instancetype feature, the method should
return 'Foo*', and thus no warning should be issued.  Without the instancetype
feature (without the 'init' attribute), this is still correct behavior, because
'Foo*' can be matched to 'id'.  'id' trumps the type checking.  That's how
Objective-C has worked for a long 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  Tue Dec  6 16:06:08 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 06 Dec 2011 22:06:08 +0000
Subject: [LLVMbugs] [Bug 10164] Issue with objc_method_family(init) in class
	extension.
In-Reply-To: <bug-10164-206@http.llvm.org/bugs/>
References: <bug-10164-206@http.llvm.org/bugs/>
Message-ID: <bug-10164-206-2se0Jyq5Lu@http.llvm.org/bugs/>

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

Ted Kremenek <kremenek at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|INVALID                     |FIXED

--- Comment #5 from Ted Kremenek <kremenek at apple.com> 2011-12-06 16:06:08 CST ---
I can reproduce this issue with an earlier version of Clang (e.g., the one in
Xcode 4.2).  This is already fixed in mainline.

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

From bugzilla-daemon at llvm.org  Tue Dec  6 17:33:47 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 06 Dec 2011 23:33:47 +0000
Subject: [LLVMbugs] [Bug 11495] New: int-to-vector bitcast can't be lowered
Message-ID: <bug-11495-206@http.llvm.org/bugs/>

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

             Bug #: 11495
           Summary: int-to-vector bitcast can't be lowered
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Common Code Generator Code
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: richard-llvm at metafoo.co.uk
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


The following code, when fed to clang...

typedef float __attribute__((__vector_size__(8))) vf;
vf v = (vf)0x123456789abcdef0ull;

... produces this IR (as of r145981, when I fixed a wrong-code bug for
big-endian systems on this code)...

; ModuleID = '-'
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-S128"
target triple = "x86_64-unknown-linux-gnu"

@v = global <2 x float> bitcast (<1 x i64> <i64 1311768467463790320> to <2 x
float>), align 8

The backend fails when fed this code (at -O0):

Unknown constant value to lower!
UNREACHABLE executed at lib/CodeGen/AsmPrinter/AsmPrinter.cpp:1441!
[...]

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec  6 15:59:29 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 06 Dec 2011 21:59:29 +0000
Subject: [LLVMbugs] [Bug 11476] PPC can't spill CRC virtual registers
In-Reply-To: <bug-11476-206@http.llvm.org/bugs/>
References: <bug-11476-206@http.llvm.org/bugs/>
Message-ID: <bug-11476-206-3FBJq4umgQ@http.llvm.org/bugs/>

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

Hal Finkel <hfinkel at anl.gov> changed:

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

--- Comment #10 from Hal Finkel <hfinkel at anl.gov> 2011-12-06 15:59:29 CST ---
r145961 fixes this issue.

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

From bugzilla-daemon at llvm.org  Tue Dec  6 18:12:04 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 07 Dec 2011 00:12:04 +0000
Subject: [LLVMbugs] [Bug 11494] [AVX] incorrect code generated from short
 program with shuffles/int min/max
In-Reply-To: <bug-11494-206@http.llvm.org/bugs/>
References: <bug-11494-206@http.llvm.org/bugs/>
Message-ID: <bug-11494-206-BDB1GySSCL@http.llvm.org/bugs/>

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

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-12-06 18:12:04 CST ---
r145996.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec  6 18:51:01 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 07 Dec 2011 00:51:01 +0000
Subject: [LLVMbugs] [Bug 11495] int-to-vector bitcast can't be lowered
In-Reply-To: <bug-11495-206@http.llvm.org/bugs/>
References: <bug-11495-206@http.llvm.org/bugs/>
Message-ID: <bug-11495-206-bovu67ApMr@http.llvm.org/bugs/>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |sharparrow1 at yahoo.com
         Resolution|                            |FIXED

--- Comment #1 from Eli Friedman <sharparrow1 at yahoo.com> 2011-12-06 18:51:01 CST ---
r146001.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec  6 19:31:16 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 07 Dec 2011 01:31:16 +0000
Subject: [LLVMbugs] [Bug 11487] pointers to data members in unions are not
 initialized to -1
In-Reply-To: <bug-11487-206@http.llvm.org/bugs/>
References: <bug-11487-206@http.llvm.org/bugs/>
Message-ID: <bug-11487-206-XMk4ewaBpN@http.llvm.org/bugs/>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |sharparrow1 at yahoo.com
         Resolution|                            |FIXED

--- Comment #3 from Eli Friedman <sharparrow1 at yahoo.com> 2011-12-06 19:31:16 CST ---
Fix for unions in r146009.  It appears the other testcase already works
correctly 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  Tue Dec  6 21:56:00 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 07 Dec 2011 03:56:00 +0000
Subject: [LLVMbugs] [Bug 11485] Division by power of two expansion blocked
 by division flag
In-Reply-To: <bug-11485-206@http.llvm.org/bugs/>
References: <bug-11485-206@http.llvm.org/bugs/>
Message-ID: <bug-11485-206-tzjtnQKrk8@http.llvm.org/bugs/>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

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

--- Comment #5 from Eli Friedman <sharparrow1 at yahoo.com> 2011-12-06 21:56:00 CST ---
r146015.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec  6 22:01:01 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 07 Dec 2011 04:01:01 +0000
Subject: [LLVMbugs] [Bug 11472] no path to 32-bit startup files on ppc64
In-Reply-To: <bug-11472-206@http.llvm.org/bugs/>
References: <bug-11472-206@http.llvm.org/bugs/>
Message-ID: <bug-11472-206-QXPynfMW44@http.llvm.org/bugs/>

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

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-12-06 22:01:01 CST ---
r146016.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec  6 22:13:36 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 07 Dec 2011 04:13:36 +0000
Subject: [LLVMbugs] [Bug 11496] New: Crash zero-initializing union with
 pointer to data member and long double
Message-ID: <bug-11496-206@http.llvm.org/bugs/>

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

             Bug #: 11496
           Summary: Crash zero-initializing union with pointer to data
                    member and long double
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: sharparrow1 at yahoo.com
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Testcase:

namespace PR11487 {
  union U
  {
    int U::* mptr;
    struct S { char a; long double b; } x;
  } x;
}

EmitNullConstant needs to be rewritten from scratch to handle this 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  Tue Dec  6 22:22:06 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 07 Dec 2011 04:22:06 +0000
Subject: [LLVMbugs] [Bug 11497] New: llvm-config no longer returns targets
	built
Message-ID: <bug-11497-206@http.llvm.org/bugs/>

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

             Bug #: 11497
           Summary: llvm-config no longer returns targets built
           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: viridia at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Running 'llvm-config --targets-built' now returns an empty string. This has
broken my build scripts. I just did a fresh checkout of LLVM from head to
verify 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 Dec  7 01:46:19 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 07 Dec 2011 07:46:19 +0000
Subject: [LLVMbugs] [Bug 11498] New: llvm::InitializeNativeTargetAsmParser()
	is broken
Message-ID: <bug-11498-206@http.llvm.org/bugs/>

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

             Bug #: 11498
           Summary: llvm::InitializeNativeTargetAsmParser() is broken
           Product: Build scripts
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: cmake
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: alexey.prokhin at yandex.ru
                CC: llvmbugs at cs.uiuc.edu, ofv at wanadoo.es
    Classification: Unclassified


Created attachment 7682
  --> http://llvm.org/bugs/attachment.cgi?id=7682
cmake-ix.cmake patch

llvm::InitializeNativeTargetAsmParser function does nothing if LLVM was
configured using cmake. That happens because LLVM_NATIVE_ASMPARSER is not set
in config-ix.cmake. I made a patch that resolves the issue.

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

From bugzilla-daemon at llvm.org  Wed Dec  7 02:24:59 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 07 Dec 2011 08:24:59 +0000
Subject: [LLVMbugs] [Bug 11489] opt -gvn: Assertion `isa<X>(Val) &&
 "cast<Ty>() argument of incompatible type!
In-Reply-To: <bug-11489-206@http.llvm.org/bugs/>
References: <bug-11489-206@http.llvm.org/bugs/>
Message-ID: <bug-11489-206-pjIJHZRyza@http.llvm.org/bugs/>

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

Evgeniy Stepanov <eugeni.stepanov at gmail.com> changed:

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

--- Comment #2 from Evgeniy Stepanov <eugeni.stepanov at gmail.com> 2011-12-07 02:24:59 CST ---
Hm, I can not reproduce it, too, after an update. Sorry, false alarm.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec  7 04:13:06 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 07 Dec 2011 10:13:06 +0000
Subject: [LLVMbugs] [Bug 11499] New: LLVM 3.0 opt SEGFAULT on following
	example
Message-ID: <bug-11499-206@http.llvm.org/bugs/>

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

             Bug #: 11499
           Summary: LLVM 3.0 opt SEGFAULT on following example
           Product: new-bugs
           Version: 3.0
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: babslachem at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 7683
  --> http://llvm.org/bugs/attachment.cgi?id=7683
CL file to reproduce problem

Using LLVM 3.0 on attached example, it SEGFAULTs with following exec trace on
my Ubuntu 10.04LTS 64-bit system:

opt -O2 cl00.ll -S -o cl00.opt.ll

0  opt             0x00000000008a1d0f
1  opt             0x00000000008a3a5a
2  libpthread.so.0 0x00007f5c57a158f0
3  opt             0x0000000000875686 llvm::APInt::countLeadingZerosSlowCase()
const + 38
4  opt             0x0000000000875962 llvm::APInt::EqualSlowCase(unsigned long)
const + 98
5  opt             0x00000000004d4bdb llvm::MemIntrinsic::isVolatile() const +
59
6  opt             0x00000000005b1138
7  opt             0x0000000000594e49
8  opt             0x00000000005959f6
9  opt             0x00000000008500d8
llvm::FPPassManager::runOnFunction(llvm::Function&) + 552
10 opt             0x0000000000850183
llvm::FPPassManager::runOnModule(llvm::Module&) + 51
11 opt             0x000000000084fcb4
llvm::MPPassManager::runOnModule(llvm::Module&) + 468
12 opt             0x000000000084fdcd llvm::PassManagerImpl::run(llvm::Module&)
+ 141
13 opt             0x00000000004b4ff9 main + 4489
14 libc.so.6       0x00007f5c56cefc4d __libc_start_main + 253
15 opt             0x00000000004a6eb9
Stack dump:
0.    Program arguments:
/home/deldon/Work/dev/pgi/linux86/share/llvm/3.0/bin/opt -O2 cl00.ll -S -o
cl00.opt.ll 
1.    Running pass 'Function Pass Manager' on module 'cl00.ll'.
2.    Running pass 'Combine redundant instructions' on function '@f'
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 Dec  7 04:54:26 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 07 Dec 2011 10:54:26 +0000
Subject: [LLVMbugs] [Bug 11499] LLVM 3.0 opt SEGFAULT on following example
In-Reply-To: <bug-11499-206@http.llvm.org/bugs/>
References: <bug-11499-206@http.llvm.org/bugs/>
Message-ID: <bug-11499-206-gOHlHoy5oe@http.llvm.org/bugs/>

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

Duncan Sands <baldrick at free.fr> changed:

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

--- Comment #1 from Duncan Sands <baldrick at free.fr> 2011-12-07 04:54:26 CST ---
The module doesn't pass the verifier:

$ opt -verify cl00.ll -disable-output
Intrinsic prototype has incorrect number of arguments!
void (i8*, i8, i32, i32)* @llvm.memset.i32

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec  7 07:32:14 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 07 Dec 2011 13:32:14 +0000
Subject: [LLVMbugs] [Bug 11500] New: clang_saveTranslationUnit() crashes,
 when saving TU with precompiledPreamble.
Message-ID: <bug-11500-206@http.llvm.org/bugs/>

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

             Bug #: 11500
           Summary: clang_saveTranslationUnit() crashes, when saving TU
                    with precompiledPreamble.
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: michal.fizek at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


There is a problem, when i try to save TU, that was parsed and then
reparsed(!!) with following flags 0x14(CX_TranslationUnit_precompiledPreamble |
CX_TranslationUnit_CXXprecompiledPreamble) (it works the same also when only
first flag is set, however reparse is mandatory(im suspecting, that first parse
doesnt take into account the above mentioned flag)).

After calling clang_saveTranslationUnit() and assertion condition is met, at
the program that called this function crashes completely with SIGABRT.

Following message is written to output:
ASTWriter.cpp:3422: clang::serialization::DeclID
clang::ASTWriter::getDeclID(const clang::Decl*): Assertion `DeclIDs.find(D) !=
DeclIDs.end() && "Declaration not emitted!"' 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  Wed Dec  7 08:12:45 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 07 Dec 2011 14:12:45 +0000
Subject: [LLVMbugs] [Bug 2712] Hello,
	World in `Writing an LLVM Pass' does not work
In-Reply-To: <bug-2712-206@http.llvm.org/bugs/>
References: <bug-2712-206@http.llvm.org/bugs/>
Message-ID: <bug-2712-206-Z1E2AEXR95@http.llvm.org/bugs/>

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

Roel Jordans <r.jordans at tue.nl> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
                 CC|                            |r.jordans at tue.nl
         Resolution|WORKSFORME                  |

--- Comment #4 from Roel Jordans <r.jordans at tue.nl> 2011-12-07 08:12:45 CST ---
The current version on the website still has the problem of crashing when
executed.

http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-January/037761.html

Describes how to fix this. Apparently the line

   Hello() : FunctionPass(ID) {}

Should be rewritten as

   Hello() : FunctionPass(&ID) {}

This is already corrected in the example included in the source code but not in
the documentation

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec  7 11:18:20 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 07 Dec 2011 17:18:20 +0000
Subject: [LLVMbugs] [Bug 11501] New: "opt -verify-each" is no longer useful
Message-ID: <bug-11501-206@http.llvm.org/bugs/>

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

             Bug #: 11501
           Summary: "opt -verify-each" is no longer useful
           Product: new-bugs
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: baldrick at free.fr
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Now that opt (like everywhere else) is using PassManagerBuilder, the
-verify-each
option no longer results in the bitcode being verified after every 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  Wed Dec  7 11:26:15 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 07 Dec 2011 17:26:15 +0000
Subject: [LLVMbugs] [Bug 11502] New: llvm-3.0 creates massive .ll asm file
 where llvm-2.9 did not
Message-ID: <bug-11502-206@http.llvm.org/bugs/>

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

             Bug #: 11502
           Summary: llvm-3.0 creates massive .ll asm file where llvm-2.9
                    did not
           Product: new-bugs
           Version: 3.0
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: luked at cs.rochester.edu
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 7684
  --> http://llvm.org/bugs/attachment.cgi?id=7684
Preprocessed source that triggers bug.

We have a number of large tables of structs (lock structures) that are
statically allocated and zero initialized, as displayed in the included
preprocessed source. In llvm-2.9, using llvm-gcc, a .ll output is approximately
30k. In llvm-3.0, using clang-3.0, the .ll output is 25MB, and using
gcc-4.6.2/dragonegg-3.0 the .ll output is 75MB.

A discussion with Duncan on irc shows that this seems to be due to how llvm
choses to represent the tables a struct with lots of fields rather than a
struct with one array field. I don't know why this happens (maybe it has
something to do with how we specify the zero initialization?). A trace of the
three compilations for the preprocessed source is below.

luked at node2x6x2a ~/temp $ time
/u/luked/local/llvm-gcc4.2-2.9-x86_64-linux/bin/llvm-g++ -O0 -m64 -emit-llvm -o
preprocessed.ll -S preprocessed.cpp

real    0m0.126s
user    0m0.102s
sys     0m0.022s

luked at node2x6x2a ~/temp $ ls -l preprocessed.ll 
-rw-r--r-- 1 luked people 33762 Dec  7 12:17 preprocessed.ll

luked at node2x6x2a ~/temp $ clang -v
clang version 3.0 (tags/RELEASE_30/final)
Target: x86_64-redhat-linux-gnu
Thread model: posix

luked at node2x6x2a ~/temp $ time clang -O0 -m64 -emit-llvm -o preprocessed.ll -S
preprocessed.cpp

real    0m0.695s
user    0m0.579s
sys     0m0.115s

luked at node2x6x2a ~/temp $ ls -l preprocessed.ll 
-rw-r--r-- 1 luked people 24166071 Dec  7 12:17 preprocessed.ll

luked at node2x6x2a ~/temp $ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/localdisk/luked/local/gcc-4.6.2/bin/../libexec/gcc/x86_64-redhat-linux-gnu/4.6.2/lto-wrapper
Target: x86_64-redhat-linux-gnu
Configured with: ../configure --prefix=/u/luked/local/gcc-4.6.2
--enable-languages=c,c++ --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id --enable-plugin --with-arch_32=i686
--host=x86_64-redhat-linux-gnu --target=x86_64-redhat-linux-gnu
--build=x86_64-redhat-linux-gnu --disable-nls --enable-checking=release
--without-ppl --without-cloog
Thread model: posix
gcc version 4.6.2 (GCC) 

luked at node2x6x2a ~/temp $ time gcc -fplugin=dragonegg -O0 -m64 -flto -o
preprocessed.ll -S preprocessed.cpp

real    0m18.737s
user    0m2.698s
sys     0m16.025s

luked at node2x6x2a ~/temp $ ls -l preprocessed.ll 
-rw-r--r-- 1 luked people 74496790 Dec  7 12:18 preprocessed.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  Wed Dec  7 12:03:00 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 07 Dec 2011 18:03:00 +0000
Subject: [LLVMbugs] [Bug 2712] Hello,
	World in `Writing an LLVM Pass' does not work
In-Reply-To: <bug-2712-206@http.llvm.org/bugs/>
References: <bug-2712-206@http.llvm.org/bugs/>
Message-ID: <bug-2712-206-tcU8FAU1Xf@http.llvm.org/bugs/>

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

Bill Wendling <wendling at apple.com> changed:

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

--- Comment #5 from Bill Wendling <wendling at apple.com> 2011-12-07 12:03:00 CST ---
Updated r146041. 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 Dec  7 16:06:12 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 07 Dec 2011 22:06:12 +0000
Subject: [LLVMbugs] [Bug 11386] Regression(r143660): Assertion failed:
 (NumLiveRegs > 0 && "NumLiveRegs is already zero!"),
 function UnscheduleNodeBottomUp, file ScheduleDAGRRList.cpp,
 line 825. Breaks ffmpeg build.
In-Reply-To: <bug-11386-206@http.llvm.org/bugs/>
References: <bug-11386-206@http.llvm.org/bugs/>
Message-ID: <bug-11386-206-Ef6gEJj9sB@http.llvm.org/bugs/>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

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

--- Comment #7 from Eli Friedman <sharparrow1 at yahoo.com> 2011-12-07 16:06:12 CST ---
r146083

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec  7 18:41:50 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 08 Dec 2011 00:41:50 +0000
Subject: [LLVMbugs] [Bug 11503] New: clang -isysroot doesn't work properly
	on linux
Message-ID: <bug-11503-206@http.llvm.org/bugs/>

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

             Bug #: 11503
           Summary: clang -isysroot doesn't work properly on linux
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Driver
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: daniel at zuster.org
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Related to bug 9372, perhaps.

Clang doesn't handle -isysroot like GCC on Linux. Note how it is still allowing
/usr/include in the search list which is really bad.
--
ddunbar at ubuntu:~$ cd /tmp
ddunbar at ubuntu:/tmp$ touch x.c
ddunbar at ubuntu:/tmp$ clang -isysroot /tmp -c x.c -v
clang version 3.1 (trunk 146082)
Target: x86_64-unknown-linux-gnu
Thread model: posix
...
ignoring nonexistent directory "/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/include
 /home/ddunbar/llvm.obj/Debug+Asserts/bin/../lib/clang/3.1/include
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
ddunbar at ubuntu:/tmp$ gcc -isysroot /tmp -c x.c -v
...
GNU C (Ubuntu/Linaro 4.6.1-9ubuntu3) version 4.6.1 (x86_64-linux-gnu)
    compiled by GNU C version 4.6.1, GMP version 5.0.1, MPFR version 3.0.1-p3,
MPC version 0.9
...
ignoring nonexistent directory "/tmp/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory "/tmp/usr/local/include"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-linux-gnu/4.6.1/../../../../x86_64-linux-gnu/include"
ignoring nonexistent directory "/tmp/usr/include/x86_64-linux-gnu"
ignoring nonexistent directory "/tmp/usr/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/x86_64-linux-gnu/4.6.1/include
 /usr/lib/gcc/x86_64-linux-gnu/4.6.1/include-fixed
End of search list.
...
--

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec  7 23:04:21 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 08 Dec 2011 05:04:21 +0000
Subject: [LLVMbugs] [Bug 11493] missing unwind.h
In-Reply-To: <bug-11493-206@http.llvm.org/bugs/>
References: <bug-11493-206@http.llvm.org/bugs/>
Message-ID: <bug-11493-206-OzLTEDjTqH@http.llvm.org/bugs/>

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

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-12-07 23:04:21 CST ---
fixed in 146140.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec  7 23:47:22 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 08 Dec 2011 05:47:22 +0000
Subject: [LLVMbugs] [Bug 11504] New: Parsing of -idirafter flag is stricter
 than clang/gcc
Message-ID: <bug-11504-206@http.llvm.org/bugs/>

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

             Bug #: 11504
           Summary: Parsing of -idirafter flag is stricter than clang/gcc
           Product: clang
           Version: 3.0
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Static Analyzer
        AssignedTo: kremenek at apple.com
        ReportedBy: mail at justinbogner.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Specifying -idirafer/some/path (without a space) is accepted by both gcc and
clang, but scan-build (or possibly ccc-analyzer) doesn't understand this and
misses the include path. Using "-idirafter /some/path" (with a space) works
without problems.

This probably isn't a huge deal (it took me about 30 seconds to add a space in
the Makefile), but it is a bit inconsistent.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec  8 03:11:30 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 08 Dec 2011 09:11:30 +0000
Subject: [LLVMbugs] [Bug 11505] New: Clang++ aborts when there are two
 fields with the same name, one in anonymous union, in specific
Message-ID: <bug-11505-206@http.llvm.org/bugs/>

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

             Bug #: 11505
           Summary: Clang++ aborts when there are two fields with the same
                    name, one in anonymous union, in specific
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: arkadiusz.danilecki at put.poznan.pl
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 7685
  --> http://llvm.org/bugs/attachment.cgi?id=7685
preprocessed source which caused crash

The code attached causes clang++ to crash. To replicate crash, exact this
structure must be made; e.g. if there is not char str[] in anonymous union,
there is no crash.

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

From bugzilla-daemon at llvm.org  Thu Dec  8 03:18:31 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 08 Dec 2011 09:18:31 +0000
Subject: [LLVMbugs] [Bug 11506] New: GEPSplitterPass reference
Message-ID: <bug-11506-206@http.llvm.org/bugs/>

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

             Bug #: 11506
           Summary: GEPSplitterPass reference
           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: arkangath at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 7688
  --> http://llvm.org/bugs/attachment.cgi?id=7688
Patch to remove reference to GEPSplitterPass

There is a reference to the removed GEPSplitterPass in the include headers for
llvm. It has lead me to believe that it was still in the llvm passes collection
and had me chase my tails for an undefined reference when linking.

Patch to remove reference attached (basically, delete 3 lines)

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec  8 11:51:16 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 08 Dec 2011 17:51:16 +0000
Subject: [LLVMbugs] [Bug 11507] New: missing optimization opportunity:
 recursive inlining
Message-ID: <bug-11507-206@http.llvm.org/bugs/>

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

             Bug #: 11507
           Summary: missing optimization opportunity: recursive inlining
           Product: new-bugs
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: s3734770 at mail.zih.tu-dresden.de
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 7689
  --> http://llvm.org/bugs/attachment.cgi?id=7689
Test case in C++

I saw a lot of std::map usage in the llvm compiler which uses lots of
operators, especially to check if the map is empty. But thinking this check is
cheap is too naive as you will see in the test case:

_ZNSt8_Rb_treeIiSt4pairIKiiESt10_Select1stIS2_ESt4lessIiESaIS2_EE8_M_eraseEPSt13_Rb_tree_nodeIS2_E
is called with null as the second parameter.
_ZNSt8_Rb_treeIiSt4pairIKiiESt10_Select1stIS2_ESt4lessIiESaIS2_EE8_M_eraseEPSt13_Rb_tree_nodeIS2_E
itself starts with a comparison of the second parameter against null. So
inlining this function can fold a lot (the test case is designed to be a
completely empty program).

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

From bugzilla-daemon at llvm.org  Thu Dec  8 12:00:47 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 08 Dec 2011 18:00:47 +0000
Subject: [LLVMbugs] [Bug 11508] New: __is_empty() returns 0 for empty union
Message-ID: <bug-11508-206@http.llvm.org/bugs/>

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

             Bug #: 11508
           Summary: __is_empty() returns 0 for empty union
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: ipapadop at cse.tamu.edu
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 7691
  --> http://llvm.org/bugs/attachment.cgi?id=7691
Test of __is_empty with empty union.

Calling __is_empty() with an empty union incorrectly returns false.

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

From bugzilla-daemon at llvm.org  Thu Dec  8 15:28:41 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 08 Dec 2011 21:28:41 +0000
Subject: [LLVMbugs] [Bug 11509] New: ?: with cast to void breaks build of
	SelectInst
Message-ID: <bug-11509-206@http.llvm.org/bugs/>

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

             Bug #: 11509
           Summary: ?: with cast to void breaks build of SelectInst
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: LLVM Codegen
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: nlewycky at google.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


This testcase:

int f(void);
void test() {
  f() ? (void)0 : (void)0;
}

crashes in IRGen:

nlewycky at ducttape:~$ llvm/Debug+Asserts/bin/clang -cc1 -emit-llvm-only z.i
0  clang           0x0000000002c28ff5
1  clang           0x0000000002c28de8
2  libpthread.so.0 0x00007f46a916f8f0
3  clang           0x0000000001353dc6 llvm::Value::getType() const + 12
4  clang           0x0000000001379824
llvm::SelectInst::SelectInst(llvm::Value*, llvm::Value*, llvm::Value*,
llvm::Twine const&, llvm::Instruction*) + 62
5  clang           0x00000000013798e8 llvm::SelectInst::Create(llvm::Value*,
llvm::Value*, llvm::Value*, llvm::Twine const&, llvm::Instruction*) + 84
6  clang           0x000000000137b75b llvm::IRBuilder<true,
llvm::ConstantFolder, llvm::IRBuilderDefaultInserter<true>
>::CreateSelect(llvm::Value*, llvm::Value*, llvm::Value*, llvm::Twine const&) +
205
7  clang           0x0000000001425a47
8  clang           0x0000000001427feb
9  clang           0x00000000014272fe
10 clang           0x0000000001419781
11 clang           0x00000000014263b2
clang::CodeGen::CodeGenFunction::EmitScalarExpr(clang::Expr const*, bool) + 158
12 clang           0x00000000013df5be
clang::CodeGen::CodeGenFunction::EmitAnyExpr(clang::Expr const*,
clang::CodeGen::AggValueSlot, bool) + 84
13 clang           0x00000000013df51d
clang::CodeGen::CodeGenFunction::EmitIgnoredExpr(clang::Expr const*) + 139
14 clang           0x000000000147e4ff
clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*) + 401
15 clang           0x000000000147eaf1
clang::CodeGen::CodeGenFunction::EmitCompoundStmt(clang::CompoundStmt const&,
bool, clang::CodeGen::AggValueSlot) + 299
16 clang           0x000000000147e8ac
clang::CodeGen::CodeGenFunction::EmitSimpleStmt(clang::Stmt const*) + 234
17 clang           0x000000000147e3b9
clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*) + 75
18 clang           0x0000000001495c84
clang::CodeGen::CodeGenFunction::EmitFunctionBody(clang::CodeGen::FunctionArgList&)
+ 154
19 clang           0x0000000001496105
clang::CodeGen::CodeGenFunction::GenerateCode(clang::GlobalDecl,
llvm::Function*, clang::CodeGen::CGFunctionInfo const&) + 831
20 clang           0x000000000132f9a2
clang::CodeGen::CodeGenModule::EmitGlobalFunctionDefinition(clang::GlobalDecl)
+ 908
21 clang           0x000000000132d5be
clang::CodeGen::CodeGenModule::EmitGlobalDefinition(clang::GlobalDecl) + 450
22 clang           0x000000000132d04e
clang::CodeGen::CodeGenModule::EmitGlobal(clang::GlobalDecl) + 852
23 clang           0x00000000013329c2
clang::CodeGen::CodeGenModule::EmitTopLevelDecl(clang::Decl*) + 310
24 clang           0x00000000013263e9
25 clang           0x0000000001324d1f
clang::BackendConsumer::HandleTopLevelDecl(clang::DeclGroupRef) + 163
26 clang           0x00000000014b99d8 clang::ParseAST(clang::Sema&, bool) + 440
27 clang           0x00000000011a21df clang::ASTFrontendAction::ExecuteAction()
+ 265
28 clang           0x000000000132419e clang::CodeGenAction::ExecuteAction() +
968
29 clang           0x00000000011a1e2e clang::FrontendAction::Execute() + 326
30 clang           0x000000000117c328
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 750
31 clang           0x000000000114d33c
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 972
32 clang           0x000000000113ca09 cc1_main(char const**, char const**, char
const*, void*) + 999
33 clang           0x000000000114893e main + 499
34 libc.so.6       0x00007f46a8449c4d __libc_start_main + 253
35 clang           0x000000000113bca9
Stack dump:
0.      Program arguments: llvm/Debug+Asserts/bin/clang -cc1 -emit-llvm-only
z.i 
1.      <eof> parser at end of file
2.      z.i:2:6: LLVM IR generation of declaration 'test'
3.      z.i:2:6: Generating code for declaration 'test'
4.      z.i:2:13: LLVM IR generation of compound statement ('{}')
Segmentation fault

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

From bugzilla-daemon at llvm.org  Thu Dec  8 15:56:07 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 08 Dec 2011 21:56:07 +0000
Subject: [LLVMbugs] [Bug 11510] New: [qoi] warn about dead boolean op
Message-ID: <bug-11510-206@http.llvm.org/bugs/>

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

             Bug #: 11510
           Summary: [qoi] warn about dead boolean op
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: daniel at zuster.org
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


It would be nice for us to warn on this:
--
ddunbar at lordcrumb:tmp$ cat t.c
int f0(void);
int f0(void) {
  return 1 | 1;
}
ddunbar at lordcrumb:tmp$ clang -Weverything -c t.c
ddunbar at lordcrumb:tmp$ 
--

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

From bugzilla-daemon at llvm.org  Thu Dec  8 16:02:56 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 08 Dec 2011 22:02:56 +0000
Subject: [LLVMbugs] [Bug 11509] ?: with cast to void breaks build of
	SelectInst
In-Reply-To: <bug-11509-206@http.llvm.org/bugs/>
References: <bug-11509-206@http.llvm.org/bugs/>
Message-ID: <bug-11509-206-2lVZlzUYsy@http.llvm.org/bugs/>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
                 CC|                            |sharparrow1 at yahoo.com
         Resolution|                            |FIXED

--- Comment #2 from Eli Friedman <sharparrow1 at yahoo.com> 2011-12-08 16:02:56 CST ---
r146189, which is nearly identical to your fix. :)

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

From bugzilla-daemon at llvm.org  Thu Dec  8 16:08:31 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 08 Dec 2011 22:08:31 +0000
Subject: [LLVMbugs] [Bug 11508] __is_empty() returns false for empty union
In-Reply-To: <bug-11508-206@http.llvm.org/bugs/>
References: <bug-11508-206@http.llvm.org/bugs/>
Message-ID: <bug-11508-206-1ZNa2nV8QL@http.llvm.org/bugs/>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |sharparrow1 at yahoo.com
         Resolution|                            |INVALID

--- Comment #1 from Eli Friedman <sharparrow1 at yahoo.com> 2011-12-08 16:08:31 CST ---
__is_empty is supposed to be equivalent to std::is_empty.  std::is_empty always
returns false for unions.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec  8 16:28:23 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 08 Dec 2011 22:28:23 +0000
Subject: [LLVMbugs] [Bug 11506] GEPSplitterPass reference
In-Reply-To: <bug-11506-206@http.llvm.org/bugs/>
References: <bug-11506-206@http.llvm.org/bugs/>
Message-ID: <bug-11506-206-aIKOKOCGt6@http.llvm.org/bugs/>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |sharparrow1 at yahoo.com
         Resolution|                            |FIXED

--- Comment #1 from Eli Friedman <sharparrow1 at yahoo.com> 2011-12-08 16:28:23 CST ---
r146195.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec  8 16:33:11 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 08 Dec 2011 22:33:11 +0000
Subject: [LLVMbugs] [Bug 11512] New: circular dependency between
 clangSerialization and clangFrontend
Message-ID: <bug-11512-206@http.llvm.org/bugs/>

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

             Bug #: 11512
           Summary: circular dependency between clangSerialization and
                    clangFrontend
           Product: Build scripts
           Version: 3.0
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: cmake
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: fang at csl.cornell.edu
                CC: llvmbugs at cs.uiuc.edu, ofv at wanadoo.es
    Classification: Unclassified


Hi, I'm bootstrapping LLVM/clang on powerpc-darwin8 using gcc-4.6.2, (since
g++-4.0.1 is unsupported) and have run into a circular dependency.

tools/clang/lib/Frontend/CMakeLists.txt

lists depending on clangSerialization, however during the build of
clangSerialization.dylib
[tools/clang/lib/Serialization/CMakeLists.txt]
I get:

Linking CXX shared library ../../../../lib/libclangSerialization.dylib
cd
/Volumes/Mercedes2/sw/src/fink.build/llvm30-3.0-1/llvm-3.0.src/build/tools/clang/lib/Serialization
&& /Volumes/Mercedes2/sw/bin/cmake -E cmake_link_script
CMakeFiles/clangSerialization.dir/link.txt --verbose=1
/Volumes/Mercedes2/sw/src/fink.build/llvm30-3.0-1/llvm-3.0.src/opt-bin/ccg++-4.6
 -fno-common -fPIC -fno-common -Woverloaded-virtual -Wcast-qual
-fno-strict-aliasing -pedantic -Wno-long-long -Wall -W -Wno-unused-parameter
-Wwrite-strings -fno-rtti -O3 -DNDEBUG -mmacosx-version-min=10.4 -dynamiclib
-Wl,-headerpad_max_install_names  -L/sw/lib -o
../../../../lib/libclangParse.dylib -install_name
/Volumes/Mercedes2/sw/src/fink.build/llvm30-3.0-1/llvm-3.0.src/build/lib/libclangParse.dylib
CMakeFiles/clangParse.dir/ParseAST.cpp.o
CMakeFiles/clangParse.dir/ParseCXXInlineMethods.cpp.o
CMakeFiles/clangParse.dir/ParseDecl.cpp.o
CMakeFiles/clangParse.dir/ParseDeclCXX.cpp.o
CMakeFiles/clangParse.dir/ParseExpr.cpp.o
CMakeFiles/clangParse.dir/ParseExprCXX.cpp.o
CMakeFiles/clangParse.dir/ParseInit.cpp.o
CMakeFiles/clangParse.dir/ParseObjc.cpp.o
CMakeFiles/clangParse.dir/ParsePragma.cpp.o
CMakeFiles/clangParse.dir/ParseStmt.cpp.o
CMakeFiles/clangParse.dir/ParseTemplate.cpp.o
CMakeFiles/clangParse.dir/ParseTentative.cpp.o
CMakeFiles/clangParse.dir/Parser.cpp.o ../../../../lib/libclangBasic.dylib
../../../../lib/libclangAST.dylib ../../../../lib/libclangLex.dylib
../../../../lib/libclangSema.dylib -lpthread
../../../../lib/libclangAnalysis.dylib ../../../../lib/libclangIndex.dylib
../../../../lib/libclangAST.dylib ../../../../lib/libclangLex.dylib
../../../../lib/libclangBasic.dylib ../../../../lib/libLLVMMC.dylib
../../../../lib/libLLVMObject.dylib ../../../../lib/libLLVMCore.dylib
../../../../lib/libLLVMSupport.dylib -lpthread 
/usr/bin/ld: Undefined symbols:
clang::NormalizeDashIncludePath(llvm::StringRef, clang::FileManager&)
clang::CompilerInstance::createSema(clang::TranslationUnitKind,
clang::CodeCompleteConsumer*)
clang::CompilerInstance::setInvocation(clang::CompilerInvocation*)
clang::CompilerInstance::setASTConsumer(clang::ASTConsumer*)
clang::CompilerInstance::setDiagnostics(clang::DiagnosticsEngine*)
clang::CompilerInstance::createASTContext()
clang::CompilerInstance::createFileManager()
clang::CompilerInstance::createPreprocessor()
clang::CompilerInstance::createSourceManager(clang::FileManager&)
clang::CompilerInstance::InitializeSourceManager(llvm::StringRef)
clang::CompilerInstance::setTarget(clang::TargetInfo*)
clang::CompilerInstance::CompilerInstance()
clang::TextDiagnosticPrinter::TextDiagnosticPrinter(llvm::raw_ostream&,
clang::DiagnosticOptions const&, bool)
clang::ParseAST(clang::Sema&, bool)
collect2: ld returned 1 exit status
make[2]: *** [lib/libclangSerialization.dylib] Error 1

whose undefined symbols are defined in clangFrontend.

This work is going towards a fink package for llvm on OS X 10.4:
http://fink.cvs.sf.net/viewvc/fink/experimental/fangism/finkinfo/llvm30.info?view=log

I've already made a few cmake file modifications to get this far, seen in the
PatchScript entry of llvm30.info.

cmake options:
-DLLVM_BUILD_32_BITS:BOOL=ON
-DLLVM_TARGETS_TO_BUILD=PowerPC
-DBUILD_SHARED_LIBS:BOOL=ON
-DCMAKE_C_FLAGS=-fno-common
-DCMAKE_CXX_FLAGS=-fno-common

-fno-common was needed for building of dylibs.  (Might be orthogonal issue.)

This issue was also raised on the cfe-dev mailing list:
http://lists.cs.uiuc.edu/pipermail/cfe-dev/2011-November/018755.html

Any suggestions for unraveling the circular dependency?

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec  8 17:02:12 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 08 Dec 2011 23:02:12 +0000
Subject: [LLVMbugs] [Bug 11513] New: MC select different relocation from gas
Message-ID: <bug-11513-206@http.llvm.org/bugs/>

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

             Bug #: 11513
           Summary: MC select different relocation from gas
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Common Code Generator Code
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: rafael.espindola at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


For

1:      subl _GLOBAL_OFFSET_TABLE_-1b(%edx),%ebx

in 32 bits, MC produces a R_386_PC32 and gas produces R_386_GOTPC.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec  8 17:50:49 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 08 Dec 2011 23:50:49 +0000
Subject: [LLVMbugs] [Bug 11514] New: Illegal DAG optimization for SHL of any
 extended value
Message-ID: <bug-11514-206@http.llvm.org/bugs/>

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

             Bug #: 11514
           Summary: Illegal DAG optimization for SHL of any extended value
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Common Code Generator Code
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: hfinkel at anl.gov
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 7693
  --> http://llvm.org/bugs/attachment.cgi?id=7693
Failing input

%call = tail call i32 bitcast (i32 (...)* @__bswap32_var to i32 (i32)*)(i32 0)
nounwind
  %0 = zext i32 %call to i64
  %1 = shl nuw i64 %0, 32

is transformed to:

0x2485770: ch,glue = callseq_end 0x2485470, 0x2483350, 0x2485670, 0x2485570
[ORD=2]
0x2485970: i32,ch,glue = CopyFromReg 0x2485770, 0x2485870, 0x2485770:1 [ORD=2]
0x2485a70: i64 = zero_extend 0x2485970 [ORD=4]
0x2485c70: i32 = Constant<32> [ORD=5]
0x2485d70: i64 = shl 0x2485a70, 0x2485c70 [ORD=5]

which becomes:

0x3c278d0: i32,ch,glue = CopyFromReg 0x3c276d0, 0x3c277d0, 0x3c276d0:1 [ORD=2]
0x3c24fb0: i64 = any_extend 0x3c278d0
0x3c27bd0: i32 = Constant<32> [ORD=5]
0x3c27cd0: i64 = shl 0x3c24fb0, 0x3c27bd0 [ORD=5]

which becomes:

0x2485770: ch,glue = callseq_end 0x2485470, 0x2483350, 0x2485670, 0x2485570
[ORD=2] [ID=21]
0x2485970: i32,ch,glue = CopyFromReg 0x2485770, 0x2485870, 0x2485770:1 [ORD=2]
[ID=22]
0x2485c70: i32 = Constant<32> [ORD=5] [ID=9]
0x2486170: i32 = shl 0x2485970, 0x2485c70
0x2485a70: i64 = any_extend 0x2486170

but this transformation is not legal because the 32-bit shift cannot shift by
32 bits (31 is the maximum). The original 64-bit shift would have been fine,
but for some reason the shift was demoted from a 64-bit shift to a 32-bit
shift.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec  8 19:16:44 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 09 Dec 2011 01:16:44 +0000
Subject: [LLVMbugs] [Bug 11514] Illegal DAG optimization for SHL of any
	extended value
In-Reply-To: <bug-11514-206@http.llvm.org/bugs/>
References: <bug-11514-206@http.llvm.org/bugs/>
Message-ID: <bug-11514-206-Cjao59l1Uj@http.llvm.org/bugs/>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |sharparrow1 at yahoo.com
         Resolution|                            |FIXED

--- Comment #1 from Eli Friedman <sharparrow1 at yahoo.com> 2011-12-08 19:16:44 CST ---
r146219; please double-check that the codegen 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  Thu Dec  8 19:56:28 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 09 Dec 2011 01:56:28 +0000
Subject: [LLVMbugs] [Bug 11512] circular dependency between
 clangSerialization and clangFrontend
In-Reply-To: <bug-11512-206@http.llvm.org/bugs/>
References: <bug-11512-206@http.llvm.org/bugs/>
Message-ID: <bug-11512-206-NvRqBYLu9t@http.llvm.org/bugs/>

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

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-12-08 19:56:28 CST ---
I was mis-remembering, this is a *long* standing layering violation in Clang.
I've fixed it in a series of commits leading up to r146233.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec  8 20:45:46 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 09 Dec 2011 02:45:46 +0000
Subject: [LLVMbugs] [Bug 11515] New: incorrect access checking for friends
	of friends
Message-ID: <bug-11515-206@http.llvm.org/bugs/>

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

             Bug #: 11515
           Summary: incorrect access checking for friends of friends
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: richard-llvm at metafoo.co.uk
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Clang allows this:

class A {
  int n;
  friend struct B;
};

struct B {
  friend int get(A &a) {
    return a.n;
  }
};

It should not!

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

From bugzilla-daemon at llvm.org  Thu Dec  8 21:06:16 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 09 Dec 2011 03:06:16 +0000
Subject: [LLVMbugs] [Bug 11513] MC select different relocation from gas
In-Reply-To: <bug-11513-206@http.llvm.org/bugs/>
References: <bug-11513-206@http.llvm.org/bugs/>
Message-ID: <bug-11513-206-yIk9tF6Yvk@http.llvm.org/bugs/>

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

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

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

--- Comment #1 from Rafael ?vila de Esp?ndola <rafael.espindola at gmail.com> 2011-12-08 21:06:16 CST ---
Fixed in 146238.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec  8 21:21:22 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 09 Dec 2011 03:21:22 +0000
Subject: [LLVMbugs] [Bug 11516] New: Wrong alignment for variable of a
 reference type (e.g. char &foo)
Message-ID: <bug-11516-206@http.llvm.org/bugs/>

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

             Bug #: 11516
           Summary: Wrong alignment for variable of a reference type (e.g.
                    char &foo)
           Product: clang
           Version: 3.0
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: pickensd at synopsys.com
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Look at the bitcode generated from the following function:

int eq(const char &c1, const char &c2) {
    return c1 < c2;
}

You'll see that the dereference of c1 and c2 are incorrectly aligned to 4
instead of 1. This causes misaligned loads  to be generated for some loop
transformations involving char pointers.

define i32 @_Z2eqRKcS0_(i8* %c1, i8* %c2) nounwind {
entry:
  %c1.addr = alloca i8*, align 4
  %c2.addr = alloca i8*, align 4
  store i8* %c1, i8** %c1.addr, align 4
  store i8* %c2, i8** %c2.addr, align 4
  %0 = load i8** %c1.addr
  %1 = load i8* %0, align 4   <-------------------WRONG!
  %conv = zext i8 %1 to i32
  %2 = load i8** %c2.addr
  %3 = load i8* %2, align 4   <-------------------WRONG!
  %conv1 = zext i8 %3 to i32
  %cmp = icmp slt i32 %conv, %conv1
  %conv2 = zext i1 %cmp to i32
  ret i32 %conv2
}

Here is a proposed fix in module clang/lib/CodeGen/CGExpr.cpp, function
CodeGenFunction::EmitDeclRefLValue(const DeclRefExpr *E) :


Change this:

    if (VD->getType()->isReferenceType())
      V = Builder.CreateLoad(V);


To this:

    if (VD->getType()->isReferenceType()) {
      V = Builder.CreateLoad(V);
      // Alignment is now that of referenced type!
      QualType refee = VD->getType()->getPointeeType();
      Alignment = getContext().getTypeAlignInChars(refee).getQuantity();
    }

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec  8 21:32:12 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 09 Dec 2011 03:32:12 +0000
Subject: [LLVMbugs] [Bug 11498] llvm::InitializeNativeTargetAsmParser() is
	broken
In-Reply-To: <bug-11498-206@http.llvm.org/bugs/>
References: <bug-11498-206@http.llvm.org/bugs/>
Message-ID: <bug-11498-206-tUScZMhOWQ@http.llvm.org/bugs/>

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

Chandler Carruth <chandlerc at gmail.com> changed:

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

--- Comment #1 from Chandler Carruth <chandlerc at gmail.com> 2011-12-08 21:32:12 CST ---
Thanks for the report and the patch! Applied in r146239.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec  8 21:38:47 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 09 Dec 2011 03:38:47 +0000
Subject: [LLVMbugs] [Bug 11516] Wrong alignment for variable of a reference
 type (e.g. char &foo)
In-Reply-To: <bug-11516-206@http.llvm.org/bugs/>
References: <bug-11516-206@http.llvm.org/bugs/>
Message-ID: <bug-11516-206-zefW5PvbWy@http.llvm.org/bugs/>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |sharparrow1 at yahoo.com
         Resolution|                            |DUPLICATE

--- Comment #1 from Eli Friedman <sharparrow1 at yahoo.com> 2011-12-08 21:38:47 CST ---


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

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec  8 21:39:51 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 09 Dec 2011 03:39:51 +0000
Subject: [LLVMbugs] [Bug 11517] New: Missing aggregate va_arg for SPARC
Message-ID: <bug-11517-206@http.llvm.org/bugs/>

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

             Bug #: 11517
           Summary: Missing aggregate va_arg for SPARC
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: LLVM Codegen
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: joerg at NetBSD.org
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 7694
  --> http://llvm.org/bugs/attachment.cgi?id=7694
Test case for aggregate va_arg usage.

Aggregate types are not supported for SPARC. Example is attached.

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

From bugzilla-daemon at llvm.org  Fri Dec  9 02:12:30 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 09 Dec 2011 08:12:30 +0000
Subject: [LLVMbugs] [Bug 11518] New: clang frontend cmd SEGV after "cannot
 compile this conditional operator yet"
Message-ID: <bug-11518-206@http.llvm.org/bugs/>

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

             Bug #: 11518
           Summary: clang frontend cmd SEGV after "cannot compile this
                    conditional operator yet"
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: mnemo at minimum.se
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 7695
  --> http://llvm.org/bugs/attachment.cgi?id=7695
TC for the uncompilable conditional (doesn't hit SEGV though)

Unfortunately, I'm not allowed to paste the exact error, but it looks similar
to this:

blaH.h:1974:50: error: cannot compile this conditional operator yet
        void                    SomeFunc(BOOL value) { value ? thing.field = 1
: thing.field = 0; }
                                                                        
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
clang: note: diagnostic msg: Preprocessed source(s) are located at:
clang: note: diagnostic msg: /tmp/SOME-FILENAME-lCCbJS.ii
make[2]: *** [../../blah/blah/file.o] Error 254
0  clang           0x000000000182c0cf
1  clang           0x000000000182c559
2  libpthread.so.0 0x00002b42ea8c3c60
3  clang           0x00000000015ddd3b
4  clang           0x00000000015dd6ca
5  clang           0x000000000179ceef
llvm::FPPassManager::runOnFunction(llvm::Function&) + 335
6  clang           0x000000000179c90c
llvm::FunctionPassManagerImpl::run(llvm::Function&) + 428
7  clang           0x000000000179c72b
llvm::FunctionPassManager::run(llvm::Function&) + 139
8  clang           0x00000000007a18dc
clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::CodeGenOptions
const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::Module*,
clang::BackendAction, llvm::raw_ostream*) + 4636
9  clang           0x000000000079fee2
clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) + 274
10 clang           0x000000000089b153 clang::ParseAST(clang::Sema&, bool) + 403
11 clang           0x000000000079f3e2 clang::CodeGenAction::ExecuteAction() +
738
12 clang           0x0000000000689259
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 873
13 clang           0x0000000000674c5a
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 2714
14 clang           0x000000000066d176 cc1_main(char const**, char const**, char
const*, void*) + 6182
15 clang           0x00000000006710dc main + 748
16 libc.so.6       0x00002b42eb497eff __libc_start_main + 255
17 clang           0x000000000066b889
Stack dump:
0.      Program arguments: /home/autobuilder/src/llvm/llvm/Release/bin/clang
-cc1 -triple x86_64-unknown-linux-gnu -emit-obj -disable-free
-disable-llvm-verifier ... lots of source filenames and switches etc here ...
1.      <eof> parser at end of file
2.      Per-function optimization
3.      Running pass 'Simplify the CFG' on function
'@_ZN12HTML_Element26SetHasRealSizeDependentCssEi'
clang: error: unable to execute command: Segmentation fault
clang: error: clang frontend command failed due to signal 2 (use -v to see
invocation)
clang: note: diagnostic msg: Please submit a bug report to
http://llvm.org/bugs/ and include command line arguments and all diagnostic
information.
clang: note: diagnostic msg: Preprocessed source(s) are located at:
clang: note: diagnostic msg: /tmp/SOMETHING-qIPDL4.ii



I also make a small TC that can repro the "cannot compile this conditional
operator yet" part, but my small TC doesn't hit the SEGV it seems.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec  9 05:08:03 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 09 Dec 2011 11:08:03 +0000
Subject: [LLVMbugs] [Bug 11519] New: "GEP is not of right type for indices!"
Message-ID: <bug-11519-206@http.llvm.org/bugs/>

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

             Bug #: 11519
           Summary: "GEP is not of right type for indices!"
           Product: tools
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: llvm-link
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: max at duempel.org
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Got the "GEP is not of right type for indices!" while trying to link all .bc
files of a large project (C and C++ compiled with clang).

GEP is not of right type for indices!
  %d_stream = getelementptr inbounds %bar* %fp, i64 0, i32 0
 i32Broken module found, compilation aborted!
[...]
Stack dump:
0.      Program arguments: llvm-link -o /tmp/foo.bc /tmp/bz.ll /tmp/bar.ll 
1.      Running pass 'Function Pass Manager' on module '/tmp/bz.ll'.
2.      Running pass 'Module Verifier' on function '@bug_a'
Aborted


I don't understand the error message, but I've experimented with reducing the
test case to a few lines of LLVM assembly:

first file:
%struct.bug_type = type opaque
declare i32 @bug_a(%struct.bug_type*)
declare i32 @bug_b(%struct.bug_type*)

second file:
%struct.bug_type = type { %struct.bug_type* }
%bar = type { i32 }
define i32 @bug_a(%struct.bug_type* %fp) nounwind uwtable {
entry:
  %d_stream = getelementptr inbounds %struct.bug_type* %fp, i64 0, i32 0
  ret i32 0
}
define i32 @bug_b(%bar* %a) nounwind uwtable {
entry:
  ret i32 0
}

Command to reproduce: llvm-link -o foo.bc first.ll second.ll

The type mismatch is intentional, it may or may not have been in my original
clang-generated bitcode files, I didn't check; the point is that this error is
not noticed, instead it complains about the function bug_a that is (or seems)
correct!

The problem disappears when any detail is changed in the file, and it
disappears when the reverse argument order in the llvm-link command is used.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec  9 06:48:31 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 09 Dec 2011 12:48:31 +0000
Subject: [LLVMbugs] [Bug 11520] New: clang crash while building mimosa
Message-ID: <bug-11520-206@http.llvm.org/bugs/>

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

             Bug #: 11520
           Summary: clang crash while building mimosa
           Product: clang
           Version: 3.0
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: C++0x
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: bique.alexandre at gmail.com
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Hi,

I tried clang 3.0 to compile mimosa (https://github.com/abique/mimosa) at
revision ac298032a910fc94f5f8b39495cd4dd1f7554205.

I got the following error:

make
[  1%] Built target mimosa-options
[  4%] Built target mimosa-runtime
[  6%] Built target mimosa
[ 10%] Built target mimosa-log
[ 15%] Built target mimosa-uri
[ 31%] Built target mimosa-stream
[ 33%] Building CXX object mimosa/net/CMakeFiles/mimosa-net.dir/server.cc.o
0  libLLVM-3.0.so  0x00007f9836c7383f
1  libLLVM-3.0.so  0x00007f9836c73e01
2  libpthread.so.0 0x00007f9835dee850
3  clang           0x0000000000d3dcce
clang::Expr::hasAnyTypeDependentArguments(clang::Expr**, unsigned int) + 14
4  clang           0x000000000096e7ef
clang::Sema::BuildCXXTypeConstructExpr(clang::TypeSourceInfo*,
clang::SourceLocation, clang::ASTMultiPtr<clang::Expr*>, clang::SourceLocation)
+ 239
5  clang           0x000000000096ed24
clang::Sema::ActOnCXXTypeConstructExpr(clang::OpaquePtr<clang::QualType>,
clang::SourceLocation, clang::ASTMultiPtr<clang::Expr*>, clang::SourceLocation)
+ 84
6  clang           0x0000000000834a3a
clang::Parser::ParseCXXTypeConstructExpression(clang::DeclSpec const&) + 666
7  clang           0x000000000082d381 clang::Parser::ParseCastExpression(bool,
bool, bool&, bool) + 7361
8  clang           0x000000000082dfde clang::Parser::ParseCastExpression(bool,
bool, bool) + 30
9  clang           0x000000000082e8cf
clang::Parser::ParseAssignmentExpression() + 31
10 clang           0x000000000082f699 clang::Parser::ParseExpression() + 9
11 clang           0x00000000007f1ca2
clang::Parser::ParseExprStatement(clang::ParsedAttributes&) + 50
12 clang           0x00000000007ee4c8
clang::Parser::ParseStatementOrDeclaration(clang::ASTOwningVector<clang::Stmt*,
32u>&, bool) + 2616
13 clang           0x00000000007f22e6
clang::Parser::ParseIfStatement(clang::ParsedAttributes&) + 758
14 clang           0x00000000007ee4dd
clang::Parser::ParseStatementOrDeclaration(clang::ASTOwningVector<clang::Stmt*,
32u>&, bool) + 2637
15 clang           0x00000000007eb0c1
clang::Parser::ParseCompoundStatementBody(bool) + 417
16 clang           0x00000000007ebea6
clang::Parser::ParseCompoundStatement(clang::ParsedAttributes&, bool, unsigned
int) + 38
17 clang           0x00000000007ebee1
clang::Parser::ParseCompoundStatement(clang::ParsedAttributes&, bool) + 17
18 clang           0x00000000007ee4f7
clang::Parser::ParseStatementOrDeclaration(clang::ASTOwningVector<clang::Stmt*,
32u>&, bool) + 2663
19 clang           0x00000000007f22e6
clang::Parser::ParseIfStatement(clang::ParsedAttributes&) + 758
20 clang           0x00000000007ee4dd
clang::Parser::ParseStatementOrDeclaration(clang::ASTOwningVector<clang::Stmt*,
32u>&, bool) + 2637
21 clang           0x00000000007eb0c1
clang::Parser::ParseCompoundStatementBody(bool) + 417
22 clang           0x00000000007ebdaa
clang::Parser::ParseFunctionStatementBody(clang::Decl*,
clang::Parser::ParseScope&) + 138
23 clang           0x000000000080589c
clang::Parser::ParseFunctionDefinition(clang::Parser::ParsingDeclarator&,
clang::Parser::ParsedTemplateInfo const&) + 1116
24 clang           0x0000000000813212
clang::Parser::ParseDeclGroup(clang::Parser::ParsingDeclSpec&, unsigned int,
bool, clang::SourceLocation*, clang::Parser::ForRangeInit*) + 610
25 clang           0x0000000000801485
clang::Parser::ParseDeclarationOrFunctionDefinition(clang::Parser::ParsingDeclSpec&,
clang::AccessSpecifier) + 149
26 clang           0x0000000000801af6
clang::Parser::ParseDeclarationOrFunctionDefinition(clang::ParsedAttributes&,
clang::AccessSpecifier) + 678
27 clang           0x00000000008036bd
clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&,
clang::Parser::ParsingDeclSpec*) + 2685
28 clang           0x0000000000821c8f
clang::Parser::ParseInnerNamespace(std::vector<clang::SourceLocation,
std::allocator<clang::SourceLocation> >&, std::vector<clang::IdentifierInfo*,
std::allocator<clang::IdentifierInfo*> >&, std::vector<clang::SourceLocation,
std::allocator<clang::SourceLocation> >&, unsigned int, clang::SourceLocation&,
clang::ParsedAttributes&, clang::Parser::BalancedDelimiterTracker&) + 367
29 clang           0x00000000008229de clang::Parser::ParseNamespace(unsigned
int, clang::SourceLocation&, clang::SourceLocation) + 1854
30 clang           0x0000000000818311
clang::Parser::ParseDeclaration(clang::ASTOwningVector<clang::Stmt*, 32u>&,
unsigned int, clang::SourceLocation&,
clang::Parser::ParsedAttributesWithRange&) + 641
31 clang           0x000000000080304d
clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&,
clang::Parser::ParsingDeclSpec*) + 1037
32 clang           0x0000000000821c8f
clang::Parser::ParseInnerNamespace(std::vector<clang::SourceLocation,
std::allocator<clang::SourceLocation> >&, std::vector<clang::IdentifierInfo*,
std::allocator<clang::IdentifierInfo*> >&, std::vector<clang::SourceLocation,
std::allocator<clang::SourceLocation> >&, unsigned int, clang::SourceLocation&,
clang::ParsedAttributes&, clang::Parser::BalancedDelimiterTracker&) + 367
33 clang           0x00000000008229de clang::Parser::ParseNamespace(unsigned
int, clang::SourceLocation&, clang::SourceLocation) + 1854
34 clang           0x0000000000818311
clang::Parser::ParseDeclaration(clang::ASTOwningVector<clang::Stmt*, 32u>&,
unsigned int, clang::SourceLocation&,
clang::Parser::ParsedAttributesWithRange&) + 641
35 clang           0x000000000080304d
clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&,
clang::Parser::ParsingDeclSpec*) + 1037
36 clang           0x0000000000803c27
clang::Parser::ParseTopLevelDecl(clang::OpaquePtr<clang::DeclGroupRef>&) + 167
37 clang           0x00000000007db1fd clang::ParseAST(clang::Sema&, bool) + 269
38 clang           0x00000000006c3e13 clang::CodeGenAction::ExecuteAction() +
51
39 clang           0x00000000005c9c3f
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 319
40 clang           0x00000000005b251a
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1114
41 clang           0x00000000005aa1a4 cc1_main(char const**, char const**, char
const*, void*) + 820
42 clang           0x00000000005a8b1c main + 620
43 libc.so.6       0x00007f983555e14d __libc_start_main + 237
44 clang           0x00000000005a9d19
Stack dump:
0.    Program arguments: /usr/bin/clang -cc1 -triple x86_64-unknown-linux-gnu
-emit-obj -mrelax-all -disable-free -disable-llvm-verifier -main-file-name
server.cc -mrelocation-model static -mdisable-fp-elim -masm-verbose
-mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version
2.22.0.20111201 -momit-leaf-frame-pointer -coverage-file
CMakeFiles/mimosa-net.dir/server.cc.o -resource-dir /usr/bin/../lib/clang/3.0
-D _GNU_SOURCE -D _LARGEFILE64_SOURCE -I /home/abique/develop/mimosa/.
-fmodule-cache-path /var/tmp/clang-module-cache -internal-isystem
/usr/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.6.2/../../../../include/c++/4.6.2
-internal-isystem
/usr/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.6.2/../../../../include/c++/4.6.2/x86_64-unknown-linux-gnu
-internal-isystem
/usr/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.6.2/../../../../include/c++/4.6.2/backward
-internal-isystem /usr/local/include -internal-isystem
/usr/bin/../lib/clang/3.0/include -internal-externc-isystem /usr/include -Wall
-Wextra -std=c++0x -fdeprecated-macro -ferror-limit 19 -fmessage-length 239
-fgnu-runtime -fobjc-runtime-has-arc -fobjc-runtime-has-weak -fobjc-fragile-abi
-fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o
CMakeFiles/mimosa-net.dir/server.cc.o -x c++
/home/abique/develop/mimosa/mimosa/net/server.cc 
1.    /home/abique/develop/mimosa/mimosa/net/server.cc:115:15: current parser
token '.'
2.    /home/abique/develop/mimosa/mimosa/net/server.cc:12:1: parsing namespace
'mimosa'
3.    /home/abique/develop/mimosa/mimosa/net/server.cc:14:3: parsing namespace
'net'
4.    /home/abique/develop/mimosa/mimosa/net/server.cc:107:5: parsing function
body 'serveOne'
5.    /home/abique/develop/mimosa/mimosa/net/server.cc:107:5: in compound
statement ('{}')
6.    /home/abique/develop/mimosa/mimosa/net/server.cc:110:7: in compound
statement ('{}')
clang: error: unable to execute command: Segmentation fault
clang: error: clang frontend command failed due to signal 2 (use -v to see
invocation)
clang: note: diagnostic msg: Please submit a bug report to
http://llvm.org/bugs/ and include command line arguments and all diagnostic
information.
clang: note: diagnostic msg: Preprocessed source(s) are located at:
clang: note: diagnostic msg: /tmp/server-R9faDr.ii
make[2]: *** [mimosa/net/CMakeFiles/mimosa-net.dir/server.cc.o] Error 254
make[1]: *** [mimosa/net/CMakeFiles/mimosa-net.dir/all] Error 2
make: *** [all] Error 2


Thanks for you attention.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec  9 09:08:10 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 09 Dec 2011 15:08:10 +0000
Subject: [LLVMbugs] [Bug 11521] New: order of static constructors wrong
Message-ID: <bug-11521-206@http.llvm.org/bugs/>

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

             Bug #: 11521
           Summary: order of static constructors wrong
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: ich at az2000.de
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified


In the example [here](https://gist.github.com/1451848), I would expect that the
constructor of `rnd` is called first and then the function `_rand_engine__init`
(via `__attribute__((constructor))`).

However, from the output, I can see that this is not the case.

I'm not exactly sure wether this is really a bug or if the doc leaves this
undefined. However, from the GCC docs (summarized
[here](http://stackoverflow.com/a/8433525/133374)), it seems that my expected
behavior should have been the one.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec  9 09:29:38 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 09 Dec 2011 15:29:38 +0000
Subject: [LLVMbugs] [Bug 11521] order of static constructors wrong
In-Reply-To: <bug-11521-206@http.llvm.org/bugs/>
References: <bug-11521-206@http.llvm.org/bugs/>
Message-ID: <bug-11521-206-XzFBAy7wbM@http.llvm.org/bugs/>

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

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

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

--- Comment #2 from Anton Korobeynikov <asl at math.spbu.ru> 2011-12-09 09:29:38 CST ---


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

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec  9 09:30:33 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 09 Dec 2011 15:30:33 +0000
Subject: [LLVMbugs] [Bug 11522] New: Clang hangs in infinite loop
Message-ID: <bug-11522-206@http.llvm.org/bugs/>

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

             Bug #: 11522
           Summary: Clang hangs in infinite loop
           Product: clang
           Version: 3.0
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: arne-llvm at rfc2549.org
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 7698
  --> http://llvm.org/bugs/attachment.cgi?id=7698
test case which triggers the bug

clang -v
Apple clang version 3.0 (tags/Apple/clang-211.12) (based on LLVM 3.0svn)
Target: x86_64-apple-darwin11.2.0
Thread model: posix


When compiling the attached test.cpp with:

clang++  -I/opt/local/include test.cpp 

clang++ consumes multiple gigabytes of memory. Note that um_nodes(g) is a
mispelled variant of num_nodes(g) of boost. The opt/local/include directory
contains a boost 1.48 installation (macports)

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec  9 09:36:08 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 09 Dec 2011 15:36:08 +0000
Subject: [LLVMbugs] [Bug 11523] New: Arrays of pointers to data members are
 not zero-initialized correctly
Message-ID: <bug-11523-206@http.llvm.org/bugs/>

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

             Bug #: 11523
           Summary: Arrays of pointers to data members are not
                    zero-initialized correctly
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: LLVM Codegen
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: shatrov at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 7699
  --> http://llvm.org/bugs/attachment.cgi?id=7699
test case

Elements of arrays of pointers to data members should be set to "-1" when such
arrays are zero-initialized, as Itanium C++ ABI requires. But they are
initialized to 0 by clang. See the attached test case.

A possible fix is also attached. I didn't compile and test it, but it
highlights the relevant place in the source 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  Fri Dec  9 10:20:11 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 09 Dec 2011 16:20:11 +0000
Subject: [LLVMbugs] [Bug 2712] Hello,
	World in `Writing an LLVM Pass' does not work
In-Reply-To: <bug-2712-206@http.llvm.org/bugs/>
References: <bug-2712-206@http.llvm.org/bugs/>
Message-ID: <bug-2712-206-uZqQq9fjsI@http.llvm.org/bugs/>

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

Roel Jordans <r.jordans at tue.nl> changed:

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

--- Comment #6 from Roel Jordans <r.jordans at tue.nl> 2011-12-09 10:20:11 CST ---
I am sorry to bother you again but I was testing the example code on an older
version of LLVM.

The current trunk version apparently requires the example code without the
added &

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec  9 11:34:00 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 09 Dec 2011 17:34:00 +0000
Subject: [LLVMbugs] [Bug 11525] New: Segmentation fault on simple C99 source
Message-ID: <bug-11525-206@http.llvm.org/bugs/>

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

             Bug #: 11525
           Summary: Segmentation fault on simple C99 source
           Product: clang
           Version: 2.9
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: LLVM Codegen
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: mike.bakhterev at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


When compiling simple source:

$ cat test.c 
typedef double eltype;

eltype matat(
        const eltype araw[],
        const unsigned m,
        const unsigned i,
        const unsigned j,
        const unsigned tc)
{
        return ((const eltype (*const)[m])araw)[i][j];
}

I get:
$ clang -v -flto -O4 test.c

clang version 2.9 (tags/RELEASE_29/final)
Target: x86_64-unknown-linux-gnu
Thread model: posix
 "/usr/bin/clang" -cc1 -triple x86_64-unknown-linux-gnu -emit-llvm-bc
-disable-free -disable-llvm-verifier -main-file-name test.c -mrelocation-model
static -mdisable-fp-elim -masm-verbose -mconstructor-aliases -munwind-tables
-target-cpu x86-64 -target-linker-version 2.21.1.20110627
-momit-leaf-frame-pointer -v -resource-dir /usr/bin/../lib/clang/2.9 -O3
-ferror-limit 19 -fmessage-length 0 -fgnu-runtime -fdiagnostics-show-option -o
/tmp/cc-I7y2Ut.o -x c test.c
clang -cc1 version 2.9 based upon llvm 2.9 hosted on x86_64-unknown-linux-gnu
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/include
 /usr/bin/../lib/clang/2.9/include
 /usr/include
End of search list.
0  libLLVM-2.9.so  0x00007f002f004a0f
1  libLLVM-2.9.so  0x00007f002f004fd1
2  libpthread.so.0 0x00007f002e959850
3  libLLVM-2.9.so  0x00007f002f1bddd0
4  libLLVM-2.9.so  0x00007f002f1c47b6
llvm::SimplifyInstruction(llvm::Instruction*, llvm::TargetData const*,
llvm::DominatorTree const*) + 342
5  libLLVM-2.9.so  0x00007f002ef26fed
6  libLLVM-2.9.so  0x00007f002ef2967d
7  libLLVM-2.9.so  0x00007f002f4f0e55
llvm::FPPassManager::runOnFunction(llvm::Function&) + 501
8  libLLVM-2.9.so  0x00007f002f4f0fb1
llvm::FunctionPassManagerImpl::run(llvm::Function&) + 97
9  libLLVM-2.9.so  0x00007f002f4f1091
llvm::FunctionPassManager::run(llvm::Function&) + 97
10 clang           0x0000000000613cce
clang::EmitBackendOutput(clang::Diagnostic&, clang::CodeGenOptions const&,
clang::TargetOptions const&, llvm::Module*, clang::BackendAction,
llvm::raw_ostream*) + 3918
11 clang           0x0000000000611d0e
clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) + 238
12 clang           0x000000000071ae2b clang::ParseAST(clang::Sema&, bool) + 251
13 clang           0x0000000000610c03 clang::CodeGenAction::ExecuteAction() +
51
14 clang           0x000000000054393b
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 283
15 clang           0x000000000052987b
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 971
16 clang           0x0000000000521d37 cc1_main(char const**, char const**, char
const*, void*) + 727
17 clang           0x00000000005208ba main + 634
18 libc.so.6       0x00007f002e0c317d __libc_start_main + 237
19 clang           0x0000000000521905
Stack dump:
0.    Program arguments: /usr/bin/clang -cc1 -triple x86_64-unknown-linux-gnu
-emit-llvm-bc -disable-free -disable-llvm-verifier -main-file-name test.c
-mrelocation-model static -mdisable-fp-elim -masm-verbose -mconstructor-aliases
-munwind-tables -target-cpu x86-64 -target-linker-version 2.21.1.20110627
-momit-leaf-frame-pointer -v -resource-dir /usr/bin/../lib/clang/2.9 -O3
-ferror-limit 19 -fmessage-length 0 -fgnu-runtime -fdiagnostics-show-option -o
/tmp/cc-I7y2Ut.o -x c test.c 
1.    <eof> parser at end of file
2.    Per-function optimization
3.    Running pass 'Early CSE' on function '@matat'
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 Dec  9 12:49:47 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 09 Dec 2011 18:49:47 +0000
Subject: [LLVMbugs] [Bug 10071] Assertion in clang codegen
In-Reply-To: <bug-10071-206@http.llvm.org/bugs/>
References: <bug-10071-206@http.llvm.org/bugs/>
Message-ID: <bug-10071-206-MD2cHw7JWe@http.llvm.org/bugs/>

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

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-12-09 12:49:47 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  Fri Dec  9 13:11:21 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 09 Dec 2011 19:11:21 +0000
Subject: [LLVMbugs] [Bug 2712] Hello,
	World in `Writing an LLVM Pass' does not work
In-Reply-To: <bug-2712-206@http.llvm.org/bugs/>
References: <bug-2712-206@http.llvm.org/bugs/>
Message-ID: <bug-2712-206-KPMU5Prnrh@http.llvm.org/bugs/>

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

Bill Wendling <wendling at apple.com> changed:

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

--- Comment #7 from Bill Wendling <wendling at apple.com> 2011-12-09 13:11:21 CST ---
Ah! Okay. Thanks for noticing. I reverted the 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  Fri Dec  9 13:11:42 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 09 Dec 2011 19:11:42 +0000
Subject: [LLVMbugs] [Bug 2712] Hello,
	World in `Writing an LLVM Pass' does not work
In-Reply-To: <bug-2712-206@http.llvm.org/bugs/>
References: <bug-2712-206@http.llvm.org/bugs/>
Message-ID: <bug-2712-206-m0ORJHVWJi@http.llvm.org/bugs/>

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

Bill Wendling <wendling at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|INVALID                     |FIXED

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

From bugzilla-daemon at llvm.org  Fri Dec  9 13:34:23 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 09 Dec 2011 19:34:23 +0000
Subject: [LLVMbugs] [Bug 11526] New: Assertion in
	ARMTargetLowering::LowerBUILD_VECTOR()
Message-ID: <bug-11526-206@http.llvm.org/bugs/>

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

             Bug #: 11526
           Summary: Assertion in ARMTargetLowering::LowerBUILD_VECTOR()
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Backend: ARM
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: asl at math.spbu.ru
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 7702
  --> http://llvm.org/bugs/attachment.cgi?id=7702
Testcase

Consider the attached .ll file.

I'm having:
$ ./llc 2.ll 
Assertion failed: (isa<X>(Val) && "cast<Ty>() argument of incompatible type!"),
function cast, file
/Users/asl/Projects/llvm/src/include/llvm/Support/Casting.h, line 194.
0  llc               0x000000010ab74442 _ZL15PrintStackTracePv + 34
1  llc               0x000000010ab74a29 _ZL13SignalHandleri + 745
2  libsystem_c.dylib 0x00007fff8cc54cfa _sigtramp + 26
3  libsystem_c.dylib 000000000000000000 _sigtramp + 18446603338154423072
4  llc               0x000000010ab74696 abort + 22
5  llc               0x000000010ab74658 __assert_rtn + 56
6  llc               0x000000010a569050
llvm::ARMTargetLowering::LowerBUILD_VECTOR(llvm::SDValue, llvm::SelectionDAG&,
llvm::ARMSubtarget const*) const + 4112
7  llc               0x000000010a56e9b3
llvm::ARMTargetLowering::LowerOperation(llvm::SDValue, llvm::SelectionDAG&)
const + 7971
8  llc               0x000000010a60c34e (anonymous
namespace)::SelectionDAGLegalize::LegalizeOp(llvm::SDNode*) + 3710
9  llc               0x000000010a60b3aa llvm::SelectionDAG::Legalize() + 378
10 llc               0x000000010a71760d
llvm::SelectionDAGISel::CodeGenAndEmitDAG() + 3229
11 llc               0x000000010a7148c3
llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) + 291
12 llc               0x000000010a713c4e
llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) + 1006
13 llc               0x000000010a81564c
llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 60
14 llc               0x000000010ab1323d
llvm::FPPassManager::runOnFunction(llvm::Function&) + 349
15 llc               0x000000010ab134cb
llvm::FPPassManager::runOnModule(llvm::Module&) + 75
16 llc               0x000000010ab13606
llvm::MPPassManager::runOnModule(llvm::Module&) + 262
17 llc               0x000000010ab13c32
llvm::PassManagerImpl::run(llvm::Module&) + 338
18 llc               0x000000010ab1418d llvm::PassManager::run(llvm::Module&) +
13
19 llc               0x000000010a349cc3 main + 5251
20 llc               0x000000010a348834 start + 52
21 llc               0x0000000000000002 start + 18446744069243369474

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec  9 15:56:04 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 09 Dec 2011 21:56:04 +0000
Subject: [LLVMbugs] [Bug 11512] circular dependency between
 clangSerialization and clangFrontend
In-Reply-To: <bug-11512-206@http.llvm.org/bugs/>
References: <bug-11512-206@http.llvm.org/bugs/>
Message-ID: <bug-11512-206-jUYkSrVldK@http.llvm.org/bugs/>

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

David Fang <fang at csl.cornell.edu> changed:

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

--- Comment #3 from David Fang <fang at csl.cornell.edu> 2011-12-09 15:56:04 CST ---
Thanks for the upstream fix, will check it out from svn some time in the
future.
FWIW, the suggested workaround of lumping all of clangSerialization's objects
into clangFrontend (not the other way around) and propagating up the dependency
chain seems to have worked and gotten me pretty far.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec  9 16:09:33 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 09 Dec 2011 22:09:33 +0000
Subject: [LLVMbugs] [Bug 11512] circular dependency between
 clangSerialization and clangFrontend
In-Reply-To: <bug-11512-206@http.llvm.org/bugs/>
References: <bug-11512-206@http.llvm.org/bugs/>
Message-ID: <bug-11512-206-2q8xysFtgP@http.llvm.org/bugs/>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
                 CC|                            |sharparrow1 at yahoo.com
         Resolution|                            |FIXED

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

From bugzilla-daemon at llvm.org  Fri Dec  9 16:56:35 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 09 Dec 2011 22:56:35 +0000
Subject: [LLVMbugs] [Bug 11527] New: find-cycles.pl finds cyclic
 dependencies among LLVM libs
Message-ID: <bug-11527-206@http.llvm.org/bugs/>

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

             Bug #: 11527
           Summary: find-cycles.pl finds cyclic dependencies among LLVM
                    libs
           Product: new-bugs
           Version: 3.0
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: fang at csl.cornell.edu
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


In the process of bootstrapping llvm/clang-3.0 [release] with gcc-4.6.2 (after
having worked around bug 11512), build fails in llvm-config on find-cycles.pl.
Can anyone spot what's wrong?  Where should there NOT be a dependency edge?


% cat LibDeps.txt | awk '{print $0; print "";}'
libLLVMAnalysis.dylib: libLLVMAsmPrinter.dylib libLLVMCodeGen.dylib
libLLVMCore.dylib libLLVMInstCombine.dylib libLLVMInstrumentation.dylib
libLLVMScalarOpts.dylib libLLVMSelectionDAG.dylib libLLVMSupport.dylib
libLLVMTableGen.dylib libLLVMTarget.dylib libLLVMTransformUtils.dylib
libLLVMipa.dylib libLLVMipo.dylib

libLLVMArchive.dylib: libLLVMBitReader.dylib libLLVMCore.dylib
libLLVMMCDisassembler.dylib libLLVMSupport.dylib libLLVMTableGen.dylib

libLLVMAsmParser.dylib: libLLVMCore.dylib libLLVMSupport.dylib

libLLVMAsmPrinter.dylib: libLLVMAnalysis.dylib libLLVMCodeGen.dylib
libLLVMCore.dylib libLLVMInstrumentation.dylib libLLVMMC.dylib
libLLVMMCParser.dylib libLLVMSupport.dylib libLLVMTableGen.dylib
libLLVMTarget.dylib libLLVMTransformUtils.dylib libLLVMipo.dylib

libLLVMBitReader.dylib: libLLVMCore.dylib libLLVMSupport.dylib

libLLVMBitWriter.dylib: libLLVMCore.dylib libLLVMSupport.dylib

libLLVMCodeGen.dylib: libLLVMAnalysis.dylib libLLVMCore.dylib libLLVMJIT.dylib
libLLVMMC.dylib libLLVMObject.dylib libLLVMPowerPCCodeGen.dylib
libLLVMScalarOpts.dylib libLLVMSelectionDAG.dylib libLLVMSupport.dylib
libLLVMTableGen.dylib libLLVMTarget.dylib libLLVMTransformUtils.dylib
libLLVMipa.dylib libLLVMipo.dylib

libLLVMCore.dylib: libLLVMSelectionDAG.dylib libLLVMSupport.dylib
libLLVMTableGen.dylib libLLVMTarget.dylib libLLVMTransformUtils.dylib
libLLVMipo.dylib

libLLVMDebugInfo.dylib: libLLVMMC.dylib libLLVMSupport.dylib

libLLVMExecutionEngine.dylib: libLLVMCore.dylib libLLVMMC.dylib
libLLVMSupport.dylib libLLVMTarget.dylib

libLLVMInstCombine.dylib: libLLVMAnalysis.dylib libLLVMCore.dylib
libLLVMScalarOpts.dylib libLLVMSelectionDAG.dylib libLLVMSupport.dylib
libLLVMTarget.dylib libLLVMTransformUtils.dylib libLLVMipo.dylib

libLLVMInstrumentation.dylib: libLLVMAnalysis.dylib libLLVMCore.dylib
libLLVMSupport.dylib libLLVMTransformUtils.dylib libLLVMipo.dylib

libLLVMInterpreter.dylib: libLLVMCodeGen.dylib libLLVMCore.dylib
libLLVMExecutionEngine.dylib libLLVMSupport.dylib libLLVMTarget.dylib

libLLVMJIT.dylib: libLLVMCodeGen.dylib libLLVMCore.dylib
libLLVMExecutionEngine.dylib libLLVMMC.dylib libLLVMSupport.dylib
libLLVMTarget.dylib

libLLVMLinker.dylib: libLLVMArchive.dylib libLLVMBitReader.dylib
libLLVMCore.dylib libLLVMSupport.dylib libLLVMTableGen.dylib
libLLVMTransformUtils.dylib

libLLVMMC.dylib: libLLVMPowerPCDesc.dylib libLLVMSupport.dylib
libLLVMTableGen.dylib libLLVMTransformUtils.dylib

libLLVMMCDisassembler.dylib: libLLVMMC.dylib libLLVMMCParser.dylib
libLLVMPowerPCDesc.dylib libLLVMPowerPCInfo.dylib libLLVMSupport.dylib

libLLVMMCJIT.dylib: libLLVMCore.dylib libLLVMExecutionEngine.dylib
libLLVMRuntimeDyld.dylib libLLVMSupport.dylib libLLVMTarget.dylib

libLLVMMCParser.dylib: libLLVMMC.dylib libLLVMSupport.dylib

libLLVMObject.dylib: libLLVMSupport.dylib libLLVMTableGen.dylib

libLLVMPowerPCAsmPrinter.dylib: libLLVMMC.dylib libLLVMSupport.dylib

libLLVMPowerPCCodeGen.dylib: libLLVMAnalysis.dylib libLLVMAsmPrinter.dylib
libLLVMCodeGen.dylib libLLVMCore.dylib libLLVMMC.dylib
libLLVMPowerPCAsmPrinter.dylib libLLVMPowerPCDesc.dylib
libLLVMPowerPCInfo.dylib libLLVMSelectionDAG.dylib libLLVMSupport.dylib
libLLVMTarget.dylib libLLVMTransformUtils.dylib libLLVMipo.dylib

libLLVMPowerPCDesc.dylib: libLLVMMC.dylib libLLVMPowerPCAsmPrinter.dylib
libLLVMPowerPCInfo.dylib libLLVMSupport.dylib

libLLVMPowerPCInfo.dylib: libLLVMMC.dylib libLLVMSupport.dylib

libLLVMRuntimeDyld.dylib: libLLVMObject.dylib libLLVMSupport.dylib

libLLVMScalarOpts.dylib: libLLVMAnalysis.dylib libLLVMCore.dylib
libLLVMInstCombine.dylib libLLVMSelectionDAG.dylib libLLVMSupport.dylib
libLLVMTarget.dylib libLLVMTransformUtils.dylib libLLVMipa.dylib
libLLVMipo.dylib

libLLVMSelectionDAG.dylib: libLLVMAnalysis.dylib libLLVMCodeGen.dylib
libLLVMCore.dylib libLLVMMC.dylib libLLVMSupport.dylib libLLVMTableGen.dylib
libLLVMTarget.dylib libLLVMTransformUtils.dylib libLLVMipa.dylib
libLLVMipo.dylib

libLLVMSupport.dylib: libLLVMTableGen.dylib libLLVMTransformUtils.dylib
libLLVMipo.dylib

libLLVMTableGen.dylib: libLLVMSupport.dylib libLLVMipo.dylib

libLLVMTarget.dylib: libLLVMCore.dylib libLLVMMC.dylib libLLVMSupport.dylib
libLLVMipo.dylib

libLLVMTransformUtils.dylib: libLLVMAnalysis.dylib libLLVMCore.dylib
libLLVMSupport.dylib libLLVMTarget.dylib libLLVMipa.dylib libLLVMipo.dylib

libLLVMipa.dylib: libLLVMAnalysis.dylib libLLVMCore.dylib libLLVMSupport.dylib
libLLVMipo.dylib

libLLVMipo.dylib: libLLVMAnalysis.dylib libLLVMCore.dylib
libLLVMInstCombine.dylib libLLVMScalarOpts.dylib libLLVMSupport.dylib
libLLVMTarget.dylib libLLVMTransformUtils.dylib libLLVMipa.dylib



% cat FinalLibDeps.txt.tmp | awk '{print $0; print "";}'
libLLVMAnalysis.dylib libLLVMAsmPrinter.dylib libLLVMCodeGen.dylib
libLLVMCore.dylib libLLVMInstCombine.dylib libLLVMInstrumentation.dylib
libLLVMJIT.dylib libLLVMMC.dylib libLLVMPowerPCAsmPrinter.dylib
libLLVMPowerPCCodeGen.dylib libLLVMPowerPCDesc.dylib libLLVMPowerPCInfo.dylib
libLLVMScalarOpts.dylib libLLVMSelectionDAG.dylib libLLVMSupport.dylib
libLLVMTableGen.dylib libLLVMTarget.dylib libLLVMTransformUtils.dylib
libLLVMipa.dylib libLLVMipo.dylib libLLVMAnalysis.dylib libLLVMAsmPrinter.dylib
libLLVMCodeGen.dylib libLLVMCore.dylib libLLVMInstCombine.dylib
libLLVMInstrumentation.dylib libLLVMJIT.dylib libLLVMMC.dylib
libLLVMPowerPCAsmPrinter.dylib libLLVMPowerPCCodeGen.dylib
libLLVMPowerPCDesc.dylib libLLVMPowerPCInfo.dylib libLLVMScalarOpts.dylib
libLLVMSelectionDAG.dylib libLLVMSupport.dylib libLLVMTableGen.dylib
libLLVMTarget.dylib libLLVMTransformUtils.dylib libLLVMipa.dylib
libLLVMipo.dylib: libLLVMExecutionEngine.dylib libLLVMMCParser.dylib
libLLVMObject.dylib

libLLVMArchive.dylib: libLLVMBitReader.dylib libLLVMCore.dylib
libLLVMMCDisassembler.dylib libLLVMSupport.dylib libLLVMTableGen.dylib

libLLVMAsmParser.dylib: libLLVMCore.dylib libLLVMSupport.dylib

libLLVMBitReader.dylib: libLLVMCore.dylib libLLVMSupport.dylib

libLLVMBitWriter.dylib: libLLVMCore.dylib libLLVMSupport.dylib

libLLVMDebugInfo.dylib: libLLVMMC.dylib libLLVMSupport.dylib

libLLVMExecutionEngine.dylib: libLLVMCore.dylib libLLVMMC.dylib
libLLVMSupport.dylib libLLVMTarget.dylib

libLLVMInterpreter.dylib: libLLVMCodeGen.dylib libLLVMCore.dylib
libLLVMExecutionEngine.dylib libLLVMSupport.dylib libLLVMTarget.dylib

libLLVMLinker.dylib: libLLVMArchive.dylib libLLVMBitReader.dylib
libLLVMCore.dylib libLLVMSupport.dylib libLLVMTableGen.dylib
libLLVMTransformUtils.dylib

libLLVMMCDisassembler.dylib: libLLVMMC.dylib libLLVMMCParser.dylib
libLLVMPowerPCDesc.dylib libLLVMPowerPCInfo.dylib libLLVMSupport.dylib

libLLVMMCJIT.dylib: libLLVMCore.dylib libLLVMExecutionEngine.dylib
libLLVMRuntimeDyld.dylib libLLVMSupport.dylib libLLVMTarget.dylib

libLLVMMCParser.dylib: libLLVMMC.dylib libLLVMSupport.dylib

libLLVMObject.dylib: libLLVMSupport.dylib libLLVMTableGen.dylib

libLLVMRuntimeDyld.dylib: libLLVMObject.dylib libLLVMSupport.dylib

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

From bugzilla-daemon at llvm.org  Fri Dec  9 17:09:05 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 09 Dec 2011 23:09:05 +0000
Subject: [LLVMbugs] [Bug 11523] Arrays of pointers to data members are not
 zero-initialized correctly
In-Reply-To: <bug-11523-206@http.llvm.org/bugs/>
References: <bug-11523-206@http.llvm.org/bugs/>
Message-ID: <bug-11523-206-q34R84YKbT@http.llvm.org/bugs/>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |sharparrow1 at yahoo.com
         Resolution|                            |FIXED

--- Comment #2 from Eli Friedman <sharparrow1 at yahoo.com> 2011-12-09 17:09:05 CST ---
r146291.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec  9 17:16:19 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 09 Dec 2011 23:16:19 +0000
Subject: [LLVMbugs] [Bug 11199] Umbrella bug for 3.0 release
In-Reply-To: <bug-11199-206@http.llvm.org/bugs/>
References: <bug-11199-206@http.llvm.org/bugs/>
Message-ID: <bug-11199-206-Ypy1asfmKD@http.llvm.org/bugs/>

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

Bill Wendling <wendling at apple.com> changed:

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

--- Comment #4 from Bill Wendling <wendling at apple.com> 2011-12-09 17:16:19 CST ---
The release is finished.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec  9 17:17:03 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 09 Dec 2011 23:17:03 +0000
Subject: [LLVMbugs] [Bug 11520] clang crash while building mimosa
In-Reply-To: <bug-11520-206@http.llvm.org/bugs/>
References: <bug-11520-206@http.llvm.org/bugs/>
Message-ID: <bug-11520-206-HtGd7AxvpB@http.llvm.org/bugs/>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |sharparrow1 at yahoo.com
         Resolution|                            |LATER

--- Comment #5 from Eli Friedman <sharparrow1 at yahoo.com> 2011-12-09 17:17:03 CST ---
clang doesn't support lambdas yet.  (I'm planning to look into giving a proper
error instead of crashing.)

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

From bugzilla-daemon at llvm.org  Fri Dec  9 17:21:03 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 09 Dec 2011 23:21:03 +0000
Subject: [LLVMbugs] [Bug 11528] New: -Wbind-to-temporary warns if field in
 class has a type with a non-const copy constructor.
Message-ID: <bug-11528-206@http.llvm.org/bugs/>

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

             Bug #: 11528
           Summary: -Wbind-to-temporary warns if field in class has a type
                    with a non-const copy constructor.
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: ajwong at chromium.org
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified


struct A {
  A();

private:
 A(A& other) {}
};

class B {
  A field_;
};

void Func(const B& t) {}

int main(void) {
  Func(B());
  return 0;
}

This triggers -Wbind-to-temporary-copy:

$ ./third_party/llvm-build/Release+Asserts/bin/clang++ -c /tmp/bad3.cc
/tmp/bad3.cc:15:8: warning: no viable constructor copying parameter of type
'B'; C++98 requires a copy constructor when binding a reference to a temporary
[-Wbind-to-temporary-copy]
  Func(B());
       ^~~
/tmp/bad3.cc:8:7: note: candidate constructor (the implicit copy constructor)
not viable: no known conversion from 'B' to 'B &' for 1st argument;
class B {
      ^

If A's copy constructor is defined using a const-reference as in A(const A&
other) {}, the warning does not fire.

I *think* the warning should still not fire even if A's copy constructor is
non-const because B's implicit copy constructor should still be public.  If the
warning is actually accurate, then we have a separate problem where the
diagnostic is very confusing since it talks about B converting to B&.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec  9 17:54:54 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 09 Dec 2011 23:54:54 +0000
Subject: [LLVMbugs] [Bug 11526] Assertion in
	ARMTargetLowering::LowerBUILD_VECTOR()
In-Reply-To: <bug-11526-206@http.llvm.org/bugs/>
References: <bug-11526-206@http.llvm.org/bugs/>
Message-ID: <bug-11526-206-7vOoNsm31k@http.llvm.org/bugs/>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |sharparrow1 at yahoo.com
         Resolution|                            |FIXED

--- Comment #1 from Eli Friedman <sharparrow1 at yahoo.com> 2011-12-09 17:54:54 CST ---
r146299.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec  9 18:40:21 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 10 Dec 2011 00:40:21 +0000
Subject: [LLVMbugs] [Bug 11529] New: Tblgen type inference: Assertion failure
Message-ID: <bug-11529-206@http.llvm.org/bugs/>

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

             Bug #: 11529
           Summary: Tblgen type inference: Assertion failure
           Product: new-bugs
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: ivanllopard at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Hi,

I have got an assertion failure when tblgen tried to build the instruction
information description by analizyng the following patern:

def mul_add      : MephInstr<(outs RARegs:$dst), (ins RARegs:$src, RARegs:$a,
RARegs:$b), "mulaa", 
    [(set RARegs:$dst, (insertelt RARegs:$src, 
          (i16 (trunc (add 
           (ncmul 
            (sext (extractelt RARegs:$a, imm)), 
            (sext (extractelt RARegs:$b, imm))
            ), 
           (ncmul 
            (sext (extractelt RARegs:$a, imm)), 
            (sext (extractelt RARegs:$b, imm))
           )
           ))),
          imm) )] >;

Where RARegs is the only register class I have defined with types [i32, v2i16].
Hereafter, the execution back-trace of tblgen:

llvm-tblgen: /llvm/include/llvm/ADT/SmallVector.h:150: T&
llvm::SmallVectorTemplateCommon<T>::operator[](unsigned int) [with T =
llvm::MVT::SimpleValueType, T& = llvm::MVT::SimpleValueType&]: Assertion
`begin() + idx < end()' failed.
0  llvm-tblgen 0x081c0e8a
1  llvm-tblgen 0x081c0c17
2              0x4001e400 __kernel_sigreturn + 0
3  libc.so.6   0x401af34e abort + 382
4  libc.so.6   0x401a4888 __assert_fail + 248
5  llvm-tblgen 0x080a7692
6  llvm-tblgen 0x0809319d
7  llvm-tblgen 0x080955b7
8  llvm-tblgen 0x080a430b
9  llvm-tblgen 0x08098c3e
10 llvm-tblgen 0x08098c8b
11 llvm-tblgen 0x08098c8b
12 llvm-tblgen 0x08098c8b
13 llvm-tblgen 0x08098c8b
14 llvm-tblgen 0x080982a1
15 llvm-tblgen 0x0809b9ad
16 llvm-tblgen 0x0809f770
17 llvm-tblgen 0x0809c2c2
18 llvm-tblgen 0x08164b8c
19 llvm-tblgen 0x08165197
20 llvm-tblgen 0x08171aac
21 llvm-tblgen 0x0816458c
22 libc.so.6   0x40197e37 __libc_start_main + 231
23 llvm-tblgen 0x0804c411
Stack dump:
0.    Program arguments: /llvm/_build/Debug+Asserts/bin/llvm-tblgen -I
/llvm/lib/Target/Meph -I /llvm/include -I /llvm/include -I /llvm/lib/Target
-gen-instr-info -o
/llvm/_build/lib/Target/Meph/Debug+Asserts/MephGenInstrInfo.inc.tmp
/llvm/lib/Target/Meph/Meph.td

Let me know if more information is needed.

Regards,
Ivan

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec  9 19:30:02 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 10 Dec 2011 01:30:02 +0000
Subject: [LLVMbugs] [Bug 11530] New: llvm-config --libs returns empty string
Message-ID: <bug-11530-206@http.llvm.org/bugs/>

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

             Bug #: 11530
           Summary: llvm-config --libs returns empty string
           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: vlee at vmware.com
                CC: jfonseca at vmware.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Starting with llvm-3.1svn r145623, 'llvm-config --libs' returns an empty
string.

With llvm-3.1svn r145622, 'llvm-config --libs' returns the list of libraries.


------------------------------------------------------------------------
r145623 | ddunbar | 2011-12-01 12:18:09 -0800 (Thu, 01 Dec 2011) | 2 lines

llvm-config: Replace with C++ version (was llvm-config-2).
   - Another reapply of r144300, with hopefully one last fix.
------------------------------------------------------------------------
r145622 | ddunbar | 2011-12-01 12:00:19 -0800 (Thu, 01 Dec 2011) | 2 lines

llvm-config-2: Fix --cflags and --includedir which pointed at the wrong
directory when running from a build directory.

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

From bugzilla-daemon at llvm.org  Fri Dec  9 21:02:17 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 10 Dec 2011 03:02:17 +0000
Subject: [LLVMbugs] [Bug 11531] New: "make dist" fails on gzip
Message-ID: <bug-11531-206@http.llvm.org/bugs/>

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

             Bug #: 11531
           Summary: "make dist" fails on gzip
           Product: Build scripts
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Makefiles
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: scott+llvm+bugzilla at pakin.org
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Makefile.rules (and, where I actually first noticed the problem,
projects/sample/Makefile.llvm.rules) uses $(ZIP), $(BZIP2) and $(GZIP) to
produce various tarballs when "make dist" is invoked.  However,
autoconf/configure.ac (respectively, projects/sample/autoconf/configure.ac)
does an AC_PATH_PROG of ZIP, BZIP2, and *GZIPBIN*.  Apparently, this
inconsistency is due to the fix for Bug 8758.  However, as a result, running
"make dist" for my project, derived from sample, fails with a "/bin/sh: -c: not
found" error.

I believe the solution is simply to rename GZIP to GZIPBIN in Makefile.rules
and projects/sample/Makefile.llvm.rules.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 10 10:13:21 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 10 Dec 2011 16:13:21 +0000
Subject: [LLVMbugs] [Bug 11532] New: Assertion `Symbol->isUndefined() &&
 "Cannot define a symbol twice!"' failed
Message-ID: <bug-11532-206@http.llvm.org/bugs/>

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

             Bug #: 11532
           Summary: Assertion `Symbol->isUndefined() && "Cannot define a
                    symbol twice!"' failed
           Product: clang
           Version: 3.0
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: sedat.dilek at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 7705
  --> http://llvm.org/bugs/attachment.cgi?id=7705
bugreport llvm-clang from dileks

Hi,

I have compiled llvm/clang v3.0 (final) on my i386 Debian/sid system by myself
(Just FYI: I am using multiarch [1]).

The issue I am reporting was seen when compiling mesa from master GIT branch:

commit b1a8b7b0196c73bcfe488cbfc9e9fcd1d7ce7d9b
"Revert "st/mesa: only resolve is number of samples is > 1""

I have attached the build-logs, my build-scripts, the preprocessed-sources,
etc. (as desired by baldrick on IRC).

BTW, I was pointed on IRC to llvm-bug #9301 and tried with a refreshed version
of pr9301.patch which did not help here.

Regards,
- Sedat (dileks on IRC) -

[1] http://wiki.debian.org/Multiarch/
[2] http://llvm.org/bugs/show_bug.cgi?id=9301

P.S.: From my initial build.log:

...
make[2]: Entering directory `/home/sd/src/mesa/mesa/src/mapi/shared-glapi'
clang -c -I../../../include -I../../../src/mapi -DMAPI_MODE_GLAPI
-DMAPI_ABI_HEADER=\"shared-glapi/glapi_mapi_tmp.h\" -g -O2 -Wall
-Wmissing-prototypes -std=c99 -fno-strict-aliasing -fno-builtin-memcmp -g 
-fPIC  -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -D_GNU_SOURCE
-DPTHREADS -DDEBUG -DHAVE_POSIX_MEMALIGN -DGLX_INDIRECT_RENDERING
-DGLX_DIRECT_RENDERING -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DHAVE_ALIAS
-fvisibility=hidden ../../../src/mapi/mapi/entry.c -o entry.o
clang: warning: argument unused during compilation: '-fno-builtin-memcmp'
In file included from ../../../src/mapi/mapi/entry.c:47:
../../../src/mapi/mapi/entry_x86_tsd.h:63:19: warning: tentative array
definition assumed to have one element
static const char x86_entry_start[];
                  ^
../../../src/mapi/mapi/entry_x86_tsd.h:64:19: warning: tentative array
definition assumed to have one element
static const char x86_entry_end[];
                  ^
clang: /home/sd/src/llvm/llvm/lib/MC/MCELFStreamer.cpp:42: virtual void
llvm::MCELFStreamer::EmitLabel(llvm::MCSymbol*): Assertion
`Symbol->isUndefined() && "Cannot define a symbol twice!"' failed.
0  clang     0x09641708
1  clang     0x09641c54
2            0x4001d400 __kernel_sigreturn + 0
3            0x4001d424 __kernel_vsyscall + 16
4  libc.so.6 0x401b4911 gsignal + 81
5  libc.so.6 0x401b7d42 abort + 386
6  libc.so.6 0x401adb28 __assert_fail + 248
7  clang     0x095bd00e
Stack dump:
0.      Program arguments: /opt/llvm/bin/clang -cc1 -triple i386-pc-linux-gnu
-emit-obj -disable-free -main-file-name entry.c -pic-level 2 -mdisable-fp-elim
-relaxed-aliasing -masm-verbose -mconstructor-aliases -target-cpu pentium4
-target-linker-version 2.22 -momit-leaf-frame-pointer -g -coverage-file entry.o
-resource-dir /opt/llvm/bin/../lib/clang/3.0 -D MAPI_MODE_GLAPI -D
MAPI_ABI_HEADER="shared-glapi/glapi_mapi_tmp.h" -D USE_X86_ASM -D USE_MMX_ASM
-D USE_3DNOW_ASM -D USE_SSE_ASM -D _GNU_SOURCE -D PTHREADS -D DEBUG -D
HAVE_POSIX_MEMALIGN -D GLX_INDIRECT_RENDERING -D GLX_DIRECT_RENDERING -D
USE_EXTERNAL_DXTN_LIB=1 -D IN_DRI_DRIVER -D HAVE_ALIAS -I ../../../include -I
../../../src/mapi -fmodule-cache-path /var/tmp/clang-module-cache
-internal-isystem /usr/local/include -internal-isystem
/opt/llvm/bin/../lib/clang/3.0/include -internal-externc-isystem
/usr/include/i386-linux-gnu -internal-externc-isystem /usr/include -O2 -Wall
-Wmissing-prototypes -std=c99 -ferror-limit 19 -fmessage-length 0 -fvisibility
hidden -fgnu-runtime -fobjc-runtime-has-arc -fobjc-runtime-has-weak
-fobjc-fragile-abi -fdiagnostics-show-option -o entry.o -x c
../../../src/mapi/mapi/entry.c 
1.      <eof> parser at end of file
2.      Code generation
3.      Running pass 'Function Pass Manager' on module
'../../../src/mapi/mapi/entry.c'.
clang: error: unable to execute command: Aborted
clang: error: clang frontend command failed due to signal 2 (use -v to see
invocation)
clang: note: diagnostic msg: Please submit a bug report to
http://llvm.org/bugs/ and include command line arguments and all diagnostic
information.
clang: note: diagnostic msg: Preprocessed source(s) are located at:
clang: note: diagnostic msg: /tmp/entry-Y0sBsk.i
make[2]: *** [entry.o] Error 254
make[2]: Leaving directory `/home/sd/src/mesa/mesa/src/mapi/shared-glapi'
make[1]: *** [subdirs] Error 1
make[1]: Leaving directory `/home/sd/src/mesa/mesa/src'
make: *** [default] Error 1

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

From bugzilla-daemon at llvm.org  Sat Dec 10 12:12:47 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 10 Dec 2011 18:12:47 +0000
Subject: [LLVMbugs] [Bug 11533] New: clang is wrongly proposing assuming
 that strlcpy or strlcat are part of the lib c
Message-ID: <bug-11533-206@http.llvm.org/bugs/>

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

             Bug #: 11533
           Summary: clang is wrongly proposing assuming that strlcpy or
                    strlcat are part of the lib c
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Headers
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: sylvestre at debian.org
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Under Debian, the following code:
int
main ()
{
    (void) strlcat;
    return 0;
}
will trigger the warning:
test.c:4:12: warning: implicitly declaring C library function 'strlcat' with
      type 'unsigned long (char *, const char *, unsigned long)'
    (void) strlcat;
           ^
test.c:4:12: note: please include the header <string.h> or explicitly provide a
      declaration for 'strlcat'
1 warning generated.

while strlcat (or strlcpy) does not exist under Debian libc (version 2.13-21 on
my system).

This has been reported initially here:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=651454

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 10 17:07:09 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 10 Dec 2011 23:07:09 +0000
Subject: [LLVMbugs] [Bug 11534] New: Properly lookup .lib files on command
 line on MS/Windows.
Message-ID: <bug-11534-206@http.llvm.org/bugs/>

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

             Bug #: 11534
           Summary: Properly lookup .lib files on command line on
                    MS/Windows.
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Windows NT
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Driver
        AssignedTo: bigcheesegs at gmail.com
        ReportedBy: bigcheesegs at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Given:
$clang++ file.cpp kernel32.lib
Clang currently prints:
clang++: error: no such file or directory: 'kernel32.lib'

It should look up the library in the same manner as cl.exe.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 10 19:15:32 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 11 Dec 2011 01:15:32 +0000
Subject: [LLVMbugs] [Bug 11535] New: Clang miscompiles simple C code
Message-ID: <bug-11535-206@http.llvm.org/bugs/>

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

             Bug #: 11535
           Summary: Clang miscompiles simple C code
           Product: clang
           Version: 3.0
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: ambrop7 at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 7709
  --> http://llvm.org/bugs/attachment.cgi?id=7709
Test case C program

Clang 3.0 with -O2 miscompiles the attached C code on Linux x86_64.
Correct result is "x=1"; with clang instead it prints "x=2".
Clang 2.9 is not affected.

It appears that the value of 'x' printed is as if it was incremented a second
time (which it must not be). Some evidence of this is that if you change
"pos++" to "pos += 4" for instance, it prints out "x=8" (instead of "x=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  Sat Dec 10 19:33:41 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 11 Dec 2011 01:33:41 +0000
Subject: [LLVMbugs] [Bug 11536] New: Clang incorrect array-bounds warning on
 strpbrk in GlibC 2.9 header
Message-ID: <bug-11536-206@http.llvm.org/bugs/>

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

             Bug #: 11536
           Summary: Clang incorrect array-bounds warning on strpbrk in
                    GlibC 2.9 header
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Static Analyzer
        AssignedTo: kremenek at apple.com
        ReportedBy: pdox at google.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 7710
  --> http://llvm.org/bugs/attachment.cgi?id=7710
example code

Compile the attached example.c with Clang. The code was taken from
bits/string2.h in GlibC 2.9. It appears to be correct.

$ clang example.c -Werror

example.c:26:26: error: array index 2 is past the end of the array
      (which contains 2 elements) [-Werror,-Warray-bounds]
  foo = strpbrk("hello", "l");
        ~~~~~~~~~~~~~~~~~^~~~
example.c:16:46: note: expanded from macro 'strpbrk'
               : ((__a2 = ((__const char *) (accept))[2], __a2 == '\0')       \
                                             ^        ~
example.c:26:26: error: array index 3 is past the end of the array
      (which contains 2 elements) [-Werror,-Warray-bounds]
  foo = strpbrk("hello", "l");
        ~~~~~~~~~~~~~~~~~^~~~
example.c:18:41: note: expanded from macro 'strpbrk'
                  : (((__const char *) (accept))[3] == '\0'                   \
                                        ^        ~
2 errors 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 Dec 11 09:05:00 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 11 Dec 2011 15:05:00 +0000
Subject: [LLVMbugs] [Bug 11537] New: llvm-config --ld-flags does not give
 the correct library path
Message-ID: <bug-11537-206@http.llvm.org/bugs/>

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

             Bug #: 11537
           Summary: llvm-config --ld-flags does not give the correct
                    library path
           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: lucas at treffenstaedt.de
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 7712
  --> http://llvm.org/bugs/attachment.cgi?id=7712
llvm configure log

When using llvm-config --ldflags, the program returns -L/usr/lib instead of the
correct location of the llvm libraries (/usr/lib/llvm in my case).
According to baldrick, this may be due to llvm-config assuming the libs would
be install under --prefix, rather than --libdir.

Attached is the config.log from my llvm build.

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

From bugzilla-daemon at llvm.org  Sun Dec 11 09:50:31 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 11 Dec 2011 15:50:31 +0000
Subject: [LLVMbugs] [Bug 11439] Operations on double3 mis-optimised to
	double2
In-Reply-To: <bug-11439-206@http.llvm.org/bugs/>
References: <bug-11439-206@http.llvm.org/bugs/>
Message-ID: <bug-11439-206-mCIk7BoQ84@http.llvm.org/bugs/>

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

Erik Schnetter <schnetter at gmail.com> changed:

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

--- Comment #3 from Erik Schnetter <schnetter at gmail.com> 2011-12-11 09:50:31 CST ---
Can this solution be back-ported to the 3.0 release branch?

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 11 10:00:05 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 11 Dec 2011 16:00:05 +0000
Subject: [LLVMbugs] [Bug 11439] Operations on double3 mis-optimised to
	double2
In-Reply-To: <bug-11439-206@http.llvm.org/bugs/>
References: <bug-11439-206@http.llvm.org/bugs/>
Message-ID: <bug-11439-206-wkcSl4uN33@http.llvm.org/bugs/>

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

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

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

--- Comment #4 from Anton Korobeynikov <asl at math.spbu.ru> 2011-12-11 10:00:05 CST ---
The releases are time-based, not feature based. So, given that we normally we
do not do "point releases", the fix will be included in 3.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  Sun Dec 11 10:40:46 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 11 Dec 2011 16:40:46 +0000
Subject: [LLVMbugs] [Bug 11538] New: Support the option
	-fextended-identifiers
Message-ID: <bug-11538-206@http.llvm.org/bugs/>

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

             Bug #: 11538
           Summary: Support the option -fextended-identifiers
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: sylvestre at debian.org
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


It would be nice if you could support the option -fextended-identifiers like in
gcc/g++:

       -fextended-identifiers
           Accept universal character names in identifiers.  This option is
           experimental; in a future version of GCC, it will be enabled by
           default for C99 and C++.

This wish has been reported on:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=647636

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 11 14:19:32 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 11 Dec 2011 20:19:32 +0000
Subject: [LLVMbugs] [Bug 10719] attempting to inline spill CRBITRC:%vreg
In-Reply-To: <bug-10719-206@http.llvm.org/bugs/>
References: <bug-10719-206@http.llvm.org/bugs/>
Message-ID: <bug-10719-206-58QtZmUcmF@http.llvm.org/bugs/>

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

Roman Divacky <rdivacky at freebsd.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  Sun Dec 11 14:25:34 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 11 Dec 2011 20:25:34 +0000
Subject: [LLVMbugs] [Bug 5781] [SEMA]: incredibly big warning output
In-Reply-To: <bug-5781-206@http.llvm.org/bugs/>
References: <bug-5781-206@http.llvm.org/bugs/>
Message-ID: <bug-5781-206-SaQ3cDM5n7@http.llvm.org/bugs/>

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

Roman Divacky <rdivacky at freebsd.org> changed:

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

--- Comment #6 from Roman Divacky <rdivacky at freebsd.org> 2011-12-11 14:25:34 CST ---
does not reproduce anymore

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

From bugzilla-daemon at llvm.org  Sun Dec 11 14:31:47 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 11 Dec 2011 20:31:47 +0000
Subject: [LLVMbugs] [Bug 11461] std::tuple chokes on final
In-Reply-To: <bug-11461-206@http.llvm.org/bugs/>
References: <bug-11461-206@http.llvm.org/bugs/>
Message-ID: <bug-11461-206-sSa1jLXTu3@http.llvm.org/bugs/>

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

Howard Hinnant <hhinnant at apple.com> changed:

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

--- Comment #3 from Howard Hinnant <hhinnant at apple.com> 2011-12-11 14:31:47 CST ---
Fix Committed revision 146345.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 11 18:07:27 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 12 Dec 2011 00:07:27 +0000
Subject: [LLVMbugs] [Bug 11539] New: libc++ fails to build with gcc 4.5
Message-ID: <bug-11539-206@http.llvm.org/bugs/>

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

             Bug #: 11539
           Summary: libc++ fails to build with gcc 4.5
           Product: libc++
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: All Bugs
        AssignedTo: hhinnant at apple.com
        ReportedBy: expipiplus1 at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 7713
  --> http://llvm.org/bugs/attachment.cgi?id=7713
The output from gcc 4.6.1

gcc doesn't seem to be able to compile any file including any of the libc++
headers.
I've attached the output of trying to compile a simple testcase with:

g++ test.cpp -nostdinc++ -lc++ -I/usr/include/c++/v1

The file is as follows:

#include <iostream>
int main()
{}

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 11 21:53:02 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 12 Dec 2011 03:53:02 +0000
Subject: [LLVMbugs] [Bug 11540] New: Crash with -std=c++11,
 compiling cast-to-void* of cast-to-integer function
Message-ID: <bug-11540-206@http.llvm.org/bugs/>

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

             Bug #: 11540
           Summary: Crash with -std=c++11, compiling cast-to-void* of
                    cast-to-integer function
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++0x
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: jwalden+llvm at mit.edu
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 7714
  --> http://llvm.org/bugs/attachment.cgi?id=7714
Compiler output when attempting to compile testcase

Compiling this with -std=c++11 (on an x86-64 system, I de-aliased uintptr_t
while minimizing) crashes Clang from earlier today:

  void fun() { }

  void cast()
  {
    (void*)(unsigned long int)fun;
  }

This is a regression from sometime in the last couple weeks or so.  Commandline
spew and such are 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  Mon Dec 12 03:14:51 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 12 Dec 2011 09:14:51 +0000
Subject: [LLVMbugs] [Bug 11541] New: some i386/x86 Object tests fail when
 target is PowerPC
Message-ID: <bug-11541-206@http.llvm.org/bugs/>

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

             Bug #: 11541
           Summary: some i386/x86 Object tests fail when target is PowerPC
           Product: new-bugs
           Version: 3.0
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: fang at csl.cornell.edu
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


I've successfully built llvm/clang for powerpc-darwin8, and when I run the
regression tests, I see two failures, which look like tests for the wrong
target architecture.  Should these be somehow conditioned out when target is
PowerPC?

Transcript:

[100%] Running LLVM regression tests
FAIL: LLVM :: Object/objdump-disassembly-inline-relocations.test (3845 of 5636)
******************** TEST 'LLVM ::
Object/objdump-disassembly-inline-relocations.test' FAILED ********************
Script:
--
llvm-objdump -d -r
/Volumes/Mercedes2/sw/src/fink.build/llvm30-3.0-0/llvm-3.0.src/test/Object/TestObjectFiles/trivial-object-test.coff-i386
              |
/Volumes/Mercedes2/sw/src/fink.build/llvm30-3.0-0/build/bin/./FileCheck
/Volumes/Mercedes2/sw/src/fink.build/llvm30-3.0-0/llvm-3.0.src/test/Object/objdump-disassembly-inline-relocations.test
-check-prefix COFF-i386
llvm-objdump -d -r
/Volumes/Mercedes2/sw/src/fink.build/llvm30-3.0-0/llvm-3.0.src/test/Object/TestObjectFiles/trivial-object-test.coff-x86-64
              |
/Volumes/Mercedes2/sw/src/fink.build/llvm30-3.0-0/build/bin/./FileCheck
/Volumes/Mercedes2/sw/src/fink.build/llvm30-3.0-0/llvm-3.0.src/test/Object/objdump-disassembly-inline-relocations.test
-check-prefix COFF-x86-64
--
Exit Code: 1
Command Output (stderr):
--
llvm-objdump: error: unable to get target for 'i386-unknown-unknown', see
--version and --triple.
FileCheck error: '-' is empty.
--

********************
FAIL: LLVM :: Object/objdump-trivial-object.test (3849 of 5636)
******************** TEST 'LLVM :: Object/objdump-trivial-object.test' FAILED
********************
Script:
--
llvm-objdump -d
/Volumes/Mercedes2/sw/src/fink.build/llvm30-3.0-0/llvm-3.0.src/test/Object/TestObjectFiles/trivial-object-test.coff-i386
              |
/Volumes/Mercedes2/sw/src/fink.build/llvm30-3.0-0/build/bin/./FileCheck
/Volumes/Mercedes2/sw/src/fink.build/llvm30-3.0-0/llvm-3.0.src/test/Object/objdump-trivial-object.test
-check-prefix COFF-i386
llvm-objdump -d
/Volumes/Mercedes2/sw/src/fink.build/llvm30-3.0-0/llvm-3.0.src/test/Object/TestObjectFiles/trivial-object-test.coff-x86-64
              |
/Volumes/Mercedes2/sw/src/fink.build/llvm30-3.0-0/build/bin/./FileCheck
/Volumes/Mercedes2/sw/src/fink.build/llvm30-3.0-0/llvm-3.0.src/test/Object/objdump-trivial-object.test
-check-prefix COFF-x86-64
llvm-objdump -d
/Volumes/Mercedes2/sw/src/fink.build/llvm30-3.0-0/llvm-3.0.src/test/Object/TestObjectFiles/trivial-object-test.elf-i386
              |
/Volumes/Mercedes2/sw/src/fink.build/llvm30-3.0-0/build/bin/./FileCheck
/Volumes/Mercedes2/sw/src/fink.build/llvm30-3.0-0/llvm-3.0.src/test/Object/objdump-trivial-object.test
-check-prefix ELF-i386
llvm-objdump -d
/Volumes/Mercedes2/sw/src/fink.build/llvm30-3.0-0/llvm-3.0.src/test/Object/TestObjectFiles/trivial-object-test.elf-x86-64
              |
/Volumes/Mercedes2/sw/src/fink.build/llvm30-3.0-0/build/bin/./FileCheck
/Volumes/Mercedes2/sw/src/fink.build/llvm30-3.0-0/llvm-3.0.src/test/Object/objdump-trivial-object.test
-check-prefix ELF-x86-64
--
Exit Code: 1
Command Output (stderr):
--
llvm-objdump: error: unable to get target for 'i386-unknown-unknown', see
--version and --triple.
FileCheck error: '-' is empty.
--

********************
Testing Time: 1211.33s
********************
Failing Tests (2):
    LLVM :: Object/objdump-disassembly-inline-relocations.test
    LLVM :: Object/objdump-trivial-object.test

  Expected Passes    : 2707
  Expected Failures  : 10
  Unsupported Tests  : 2917
  Unexpected Failures: 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  Mon Dec 12 03:35:31 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 12 Dec 2011 09:35:31 +0000
Subject: [LLVMbugs] [Bug 11542] New: -Wreturn-type should be able to derive
 _Noreturn indirectly
Message-ID: <bug-11542-206@http.llvm.org/bugs/>

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

             Bug #: 11542
           Summary: -Wreturn-type should be able to derive _Noreturn
                    indirectly
           Product: clang
           Version: 3.0
          Platform: PC
        OS/Version: FreeBSD
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: ed at 80386.nl
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


I suspect this bug is similar to bug 9599, but not identical, so I'm filing
this anyway.

The following code generates a -Wreturn-type warning:

__attribute__((__noreturn__)) void bar(void);

static void
foo(void)
{

        bar();
}

int
f(void)
{

        foo();
}


foo.c:15:1: warning: control reaches end of non-void function [-Wreturn-type]

If I change the call to foo() to bar(), it obviously work, but in this case the
compiler should be to derive to a certain extent that foo() isn't going to
return anyway. This information should be available anyway, as for this
specific C file, foo() is even inlined into bar() completely.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 12 04:19:13 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 12 Dec 2011 10:19:13 +0000
Subject: [LLVMbugs] [Bug 11543] New: ambiguous qualified class member access
 lookup diagnostic unclear
Message-ID: <bug-11543-206@http.llvm.org/bugs/>

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

             Bug #: 11543
           Summary: ambiguous qualified class member access lookup
                    diagnostic unclear
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: richard-llvm at metafoo.co.uk
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified


This question came up on stackoverflow:

http://stackoverflow.com/questions/8100492/ambiguous-member-access-expression-is-clang-rejecting-valid-code

Testcase, for posterity:

template<typename T>
class TemplateClass : public T {
 public:
  void method() {}
  template<typename U>
  static void static_method(U u) { u.TemplateClass::method(); }
};

class EmptyClass {};

int main() {
  TemplateClass<TemplateClass<EmptyClass> > c;
  TemplateClass<EmptyClass>::static_method(c);
}

Clearly our diagnostic for this code is insufficient, since it's taken a month
and a +500 rep bounty for someone to figure out why the code is ill-formed. We
say:

example.cc:6:38: error: lookup of 'TemplateClass' in member access expression
is
      ambiguous
  static void static_method(U u) { u.TemplateClass::method(); }
                                     ^
example.cc:13:3: note: in instantiation of function template specialization
     
'TemplateClass<EmptyClass>::static_method<TemplateClass<TemplateClass<EmptyClass>
      > >' requested here
  TemplateClass<EmptyClass>::static_method(c);
  ^
example.cc:2:7: note: lookup in the object type
      'TemplateClass<TemplateClass<EmptyClass> >' refers here
class TemplateClass : public T {
      ^
example.cc:2:7: note: lookup from the current scope refers here

These last two notes are clearly trying to indicate the problem, but since they
don't list the template arguments they fail to point out the problem. The
problem would be more obvious if we said:

example.cc:2:7: note: lookup in the object type
      'TemplateClass<TemplateClass<EmptyClass> >' refers here [with T =
TemplateClass<EmptyClass>]
class TemplateClass : public T {
      ^
example.cc:2:7: note: lookup from the current scope refers here [with T =
EmptyClass]

It could also be useful to mention that the lookup found an injected-class-name
(but that wouldn't help in this particular 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  Mon Dec 12 08:49:34 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 12 Dec 2011 14:49:34 +0000
Subject: [LLVMbugs] [Bug 11544] New: Trivial math builtins not inlined
Message-ID: <bug-11544-206@http.llvm.org/bugs/>

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

             Bug #: 11544
           Summary: Trivial math builtins not inlined
           Product: clang
           Version: 3.0
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: LLVM Codegen
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: dsaritz at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


When compiling for -march=armv7-a, Apple Clang 3.0 from Xcode 4.2 fails to
inline math builtins, both relatively complex ones like __builtin_fmodf as well
as trivial (single instruction) ones like __builtin_lrintf.
-ffast-math -D__NO_MATH_INLINES do not help...

__builtin_lrintf is most important to me as I need fast scalar float to int 
rounding and there is no intrisic for that AFAIK (and the inline ARM assembler
is broken in Apple's Clang 3.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 Dec 12 10:36:47 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 12 Dec 2011 16:36:47 +0000
Subject: [LLVMbugs] [Bug 11545] New: Analysis for this terminator not
 implemented (CoreEngine.cpp:325)
Message-ID: <bug-11545-206@http.llvm.org/bugs/>

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

             Bug #: 11545
           Summary: Analysis for this terminator not implemented
                    (CoreEngine.cpp:325)
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Static Analyzer
        AssignedTo: kremenek at apple.com
        ReportedBy: ch.ehrlicher at gmx.de
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


I get the following error when I try scan-build on my code:

Analysis for this terminator not implemented.                                   
UNREACHABLE executed at
/home/chehrlic/llvm/llvm/tools/clang/lib/StaticAnalyzer/Core/CoreEngine.cpp:325!
0  clang++         0x0000000001a6565f
1  clang++         0x0000000001a65b79
2  libpthread.so.0 0x00007f1df4d3dd00
3  libc.so.6       0x00007f1df4058d95 gsignal + 53
4  libc.so.6       0x00007f1df405a2ab abort + 379
5  clang++         0x0000000001a55aef llvm::llvm_unreachable_internal(char
const*, char const*, unsigned int) + 463
6  clang++         0x0000000000cb65a1
clang::ento::CoreEngine::HandleBlockExit(clang::CFGBlock const*,
clang::ento::ExplodedNode*) + 145
7  clang++         0x0000000000cb61e5
clang::ento::CoreEngine::HandleBlockEntrance(clang::BlockEntrance const&,
clang::ento::ExplodedNode*) + 213
8  clang++         0x0000000000cb58d5
clang::ento::CoreEngine::ExecuteWorkList(clang::LocationContext const*,
unsigned int, clang::ento::ProgramState const*) + 549
9  clang++         0x0000000000c2d2e2
10 clang++         0x0000000000c2ccd7
11 clang++         0x0000000000c2c199
12 clang++         0x0000000000c2c0a7
13 clang++         0x000000000092cad5 clang::ParseAST(clang::Sema&, bool) + 421
14 clang++         0x00000000006e5fdb
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 987
15 clang++         0x00000000006cee90
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 2816
16 clang++         0x00000000006c63b9 cc1_main(char const**, char const**, char
const*, void*) + 5561
17 clang++         0x00000000006cb165 main + 757
18 libc.so.6       0x00007f1df404523d __libc_start_main + 237
19 clang++         0x00000000006c4d45


And here the testcase:

#include <stdexcept>

void Error_terminate()
{
  try
  {
      throw;
  }
  catch (...)
  {
  }
}

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 12 12:12:33 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 12 Dec 2011 18:12:33 +0000
Subject: [LLVMbugs] [Bug 11527] find-cycles.pl finds cyclic dependencies
	among LLVM libs
In-Reply-To: <bug-11527-206@http.llvm.org/bugs/>
References: <bug-11527-206@http.llvm.org/bugs/>
Message-ID: <bug-11527-206-mv3zapyrwn@http.llvm.org/bugs/>

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

Daniel Dunbar <daniel at zuster.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |daniel at zuster.org
         Resolution|                            |WONTFIX

--- Comment #3 from Daniel Dunbar <daniel at zuster.org> 2011-12-12 12:12:33 CST ---
find-cycles.pl has some options to explain the cycle, check the source (or
maybe try --help) for more information.

We have already resolved this on TOT, because we no longer use find-cycles.pl.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 12 12:23:23 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 12 Dec 2011 18:23:23 +0000
Subject: [LLVMbugs] [Bug 11530] llvm-config --libs returns empty string
In-Reply-To: <bug-11530-206@http.llvm.org/bugs/>
References: <bug-11530-206@http.llvm.org/bugs/>
Message-ID: <bug-11530-206-Ihpw7PPmeI@http.llvm.org/bugs/>

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

Daniel Dunbar <daniel at zuster.org> changed:

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

--- Comment #1 from Daniel Dunbar <daniel at zuster.org> 2011-12-12 12:23:23 CST ---
Fixed here:
  http://llvm.org/viewvc/llvm-project?view=rev&revision=146388
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 Dec 12 12:33:38 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 12 Dec 2011 18:33:38 +0000
Subject: [LLVMbugs] [Bug 11540] Crash with -std=c++11,
 compiling cast-to-void* of cast-to-integer function
In-Reply-To: <bug-11540-206@http.llvm.org/bugs/>
References: <bug-11540-206@http.llvm.org/bugs/>
Message-ID: <bug-11540-206-3QcCK3IVoD@http.llvm.org/bugs/>

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

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-12-12 12:33:38 CST ---
I was able to reproduce this with llvm 146344 and clang 146343, so this is
already 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  Mon Dec 12 15:22:29 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 12 Dec 2011 21:22:29 +0000
Subject: [LLVMbugs] [Bug 11522] Clang hangs in infinite loop
In-Reply-To: <bug-11522-206@http.llvm.org/bugs/>
References: <bug-11522-206@http.llvm.org/bugs/>
Message-ID: <bug-11522-206-ZHFs2owWLh@http.llvm.org/bugs/>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

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

--- Comment #3 from Eli Friedman <sharparrow1 at yahoo.com> 2011-12-12 15:22:29 CST ---
I can reproduce with Apple clang-211, but this appears to be already 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  Mon Dec 12 16:01:30 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 12 Dec 2011 22:01:30 +0000
Subject: [LLVMbugs] [Bug 11527] find-cycles.pl finds cyclic dependencies
	among LLVM libs
In-Reply-To: <bug-11527-206@http.llvm.org/bugs/>
References: <bug-11527-206@http.llvm.org/bugs/>
Message-ID: <bug-11527-206-sR9oZOysHS@http.llvm.org/bugs/>

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

David Fang <fang at csl.cornell.edu> changed:

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

--- Comment #4 from David Fang <fang at csl.cornell.edu> 2011-12-12 16:01:30 CST ---
I just ignored the result of find-cycles.pl for now and forced the build to
continue... and eventually succeeded in finishing all libs and the clang
executables.  Will eventually post more detailed results with tests results for
powerpc-darwin8.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 12 16:02:04 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 12 Dec 2011 22:02:04 +0000
Subject: [LLVMbugs] [Bug 11527] find-cycles.pl finds cyclic dependencies
	among LLVM libs
In-Reply-To: <bug-11527-206@http.llvm.org/bugs/>
References: <bug-11527-206@http.llvm.org/bugs/>
Message-ID: <bug-11527-206-3WKtHjkF3X@http.llvm.org/bugs/>

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

David Fang <fang at csl.cornell.edu> changed:

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

--- Comment #5 from David Fang <fang at csl.cornell.edu> 2011-12-12 16:02:04 CST ---
Oops, didn't mean to change status (defaulted to reopen).

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

From bugzilla-daemon at llvm.org  Mon Dec 12 16:02:53 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 12 Dec 2011 22:02:53 +0000
Subject: [LLVMbugs] [Bug 11527] find-cycles.pl finds cyclic dependencies
	among LLVM libs
In-Reply-To: <bug-11527-206@http.llvm.org/bugs/>
References: <bug-11527-206@http.llvm.org/bugs/>
Message-ID: <bug-11527-206-hdHepXIfy0@http.llvm.org/bugs/>

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

David Fang <fang at csl.cornell.edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|FIXED                       |WONTFIX

--- Comment #6 from David Fang <fang at csl.cornell.edu> 2011-12-12 16:02:53 CST ---
Arg, I meant WONTFIX.

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

From bugzilla-daemon at llvm.org  Mon Dec 12 16:04:33 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 12 Dec 2011 22:04:33 +0000
Subject: [LLVMbugs] [Bug 11546] New: Recursive template flagged when defined
	out of line
Message-ID: <bug-11546-206@http.llvm.org/bugs/>

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

             Bug #: 11546
           Summary: Recursive template flagged when defined out of line
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: ivan at ootbcomp.com
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Found in clang 3.1, w & wo c++11 enabled:
s3:~/ootbc/common$ clang -v
clang version 3.1 (trunk 145795)
Target: x86_64-unknown-linux-gnu
Thread model: posix


This code:

template<int v>
class       bitWidthHolding {
public:
    /** width is the number of bits occupied by the template parameter v
            */
    static const
    int    w1;
    static const
    int    w2 = (v == 0 ? 0 : bitWidthHolding<(v >> 1)>::w2 + 1);
    };

template<int v>
const
int    bitWidthHolding<v>::w1 =
            (v == 0 ? 0 : bitWidthHolding<(v >> 1)>::w1 + 1);

int main() {
    int v1 = bitWidthHolding<3>::w1;
    int v2 = bitWidthHolding<3>::w2;
    return 0;
    }


gets you this:

s3:~/ootbc1/common$ clang++ -std=c++11 foo.cc
foo.cc:15:18: warning: variable 'w1' is uninitialized when used within its own
      initialization [-Wuninitialized]
                        (v == 0 ? 0 : bitWidthHolding<(v >> 1)>::w1 + 1);
                                      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
foo.cc:15:45: note: in instantiation of static data member
      'bitWidthHolding<0>::w1' requested here
                        (v == 0 ? 0 : bitWidthHolding<(v >> 1)>::w1 + 1);
                                                                 ^
foo.cc:15:45: note: in instantiation of static data member
      'bitWidthHolding<1>::w1' requested here
                        (v == 0 ? 0 : bitWidthHolding<(v >> 1)>::w1 + 1);
                                                                 ^
foo.cc:18:31: note: in instantiation of static data member
      'bitWidthHolding<3>::w1' requested here
        int v1 = bitWidthHolding<3>::w1;
                                     ^
1 warning generated.

Note that no warning is issued when w2 is defined inside the class, but is
issued when w1 is defined outside; w1 and w2 are otherwise identical. No
warning is justified in either case, because the nested invocation has a
different template argument except for the zero argument case, for which the
recursive invocation should not be evaluated by ?:. However, right or wrong it
should not matter where the definition is.

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

From bugzilla-daemon at llvm.org  Mon Dec 12 17:42:38 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 12 Dec 2011 23:42:38 +0000
Subject: [LLVMbugs] [Bug 11547] New: Clang crash compiling newlib
Message-ID: <bug-11547-206@http.llvm.org/bugs/>

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

             Bug #: 11547
           Summary: Clang crash compiling newlib
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: jpbonn-keyword-llvmbug.a51747 at corniceresearch.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 7716
  --> http://llvm.org/bugs/attachment.cgi?id=7716
File causing crash

clang version 3.1 (git at github.com:milkymist/clang-lm32.git
http://llvm.org/git/clang.git 84db6ffdf895b7b31fae6d6ba0fd37b2f9a387ed)
Target: x86_64-unknown-linux-gnu
Thread model: posix

$ clang -S -emit-llvm -o /tmp/ce.ll /tmp/ce.c
0  clang           0x0000000002cd5a85
1  clang           0x0000000002cd5881
2  libpthread.so.0 0x00007fbbbf248c60
3  clang           0x00000000014a577c llvm::Value::getType() const + 12
4  clang           0x00000000014cab62
llvm::SelectInst::SelectInst(llvm::Value*, llvm::Value*, llvm::Value*,
llvm::Twine const&, llvm::Instruction*) + 60
5  clang           0x00000000014cac1e llvm::SelectInst::Create(llvm::Value*,
llvm::Value*, llvm::Value*, llvm::Twine const&, llvm::Instruction*) + 84
6  clang           0x00000000014cc9bc llvm::IRBuilder<true,
llvm::ConstantFolder, llvm::IRBuilderDefaultInserter<true>
>::CreateSelect(llvm::Value*, llvm::Value*, llvm::Value*, llvm::Twine const&) +
198
7  clang           0x0000000001573b66
8  clang           0x00000000015760c5
9  clang           0x00000000015753d8
10 clang           0x0000000001567d19
11 clang           0x0000000001567d9c
12 clang           0x0000000001575b81
13 clang           0x0000000001567d19
14 clang           0x00000000015744b0
clang::CodeGen::CodeGenFunction::EmitScalarExpr(clang::Expr const*, bool) + 156
15 clang           0x000000000152eb07
clang::CodeGen::CodeGenFunction::EmitAnyExpr(clang::Expr const*,
clang::CodeGen::AggValueSlot, bool) + 83
16 clang           0x000000000152ea7b
clang::CodeGen::CodeGenFunction::EmitIgnoredExpr(clang::Expr const*) + 97
17 clang           0x00000000015c6f9b
clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*) + 401
18 clang           0x00000000015c7574
clang::CodeGen::CodeGenFunction::EmitCompoundStmt(clang::CompoundStmt const&,
bool, clang::CodeGen::AggValueSlot) + 292
19 clang           0x00000000015c733b
clang::CodeGen::CodeGenFunction::EmitSimpleStmt(clang::Stmt const*) + 217
20 clang           0x00000000015c6e55
clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*) + 75
21 clang           0x00000000015ddf20
clang::CodeGen::CodeGenFunction::EmitFunctionBody(clang::CodeGen::FunctionArgList&)
+ 154
22 clang           0x00000000015de393
clang::CodeGen::CodeGenFunction::GenerateCode(clang::GlobalDecl,
llvm::Function*, clang::CodeGen::CGFunctionInfo const&) + 819
23 clang           0x00000000014813ef
clang::CodeGen::CodeGenModule::EmitGlobalFunctionDefinition(clang::GlobalDecl)
+ 917
24 clang           0x000000000147f054
clang::CodeGen::CodeGenModule::EmitGlobalDefinition(clang::GlobalDecl) + 448
25 clang           0x000000000147eaec
clang::CodeGen::CodeGenModule::EmitGlobal(clang::GlobalDecl) + 834
26 clang           0x0000000001484330
clang::CodeGen::CodeGenModule::EmitTopLevelDecl(clang::Decl*) + 310
27 clang           0x00000000014789bf
28 clang           0x000000000147743a
clang::BackendConsumer::HandleTopLevelDecl(clang::DeclGroupRef) + 158
29 clang           0x0000000001601004 clang::ParseAST(clang::Sema&, bool) + 440
30 clang           0x000000000130170f clang::ASTFrontendAction::ExecuteAction()
+ 265
31 clang           0x00000000014769f5 clang::CodeGenAction::ExecuteAction() +
957
32 clang           0x0000000001301369 clang::FrontendAction::Execute() + 325
33 clang           0x00000000012dc67a
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 740
34 clang           0x00000000012aeab5
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 969
35 clang           0x000000000129e0e7 cc1_main(char const**, char const**, char
const*, void*) + 990
36 clang           0x00000000012aa078 main + 496
37 libc.so.6       0x00007fbbbe51eeff __libc_start_main + 255
38 clang           0x000000000129d399
Stack dump:
0.    Program arguments: /var/build/Debug+Asserts/bin/clang -cc1 -triple
x86_64-unknown-linux-gnu -emit-llvm -disable-free -main-file-name ce.c
-mrelocation-model static -mdisable-fp-elim -masm-verbose -mconstructor-aliases
-munwind-tables -target-cpu x86-64 -target-linker-version 2.21.0.20110327
-momit-leaf-frame-pointer -coverage-file /tmp/ce.ll -resource-dir
/var/build/Debug+Asserts/bin/../lib/clang/3.1 -fmodule-cache-path
/var/tmp/clang-module-cache -internal-isystem /usr/local/include
-internal-isystem /var/build/Debug+Asserts/bin/../lib/clang/3.1/include
-internal-externc-isystem /usr/include/x86_64-linux-gnu
-internal-externc-isystem /include -internal-externc-isystem /usr/include
-fdebug-compilation-dir
/home/jpbonn/Documents/mico32/newlib/build/lm32-rtems4.11/newlib/libc/stdio
-ferror-limit 19 -fmessage-length 82 -mstackrealign -fgnu-runtime
-fobjc-runtime-has-arc -fobjc-runtime-has-weak -fobjc-fragile-abi
-fdiagnostics-show-option -fcolor-diagnostics -o /tmp/ce.ll -x c /tmp/ce.c 
1.    <eof> parser at end of file
2.    ../../../../../newlib-1.19.0/newlib/libc/stdio/clearerr.c:64:1: LLVM IR
generation of declaration 'clearerr'
3.    ../../../../../newlib-1.19.0/newlib/libc/stdio/clearerr.c:64:1:
Generating code for declaration 'clearerr'
4.    ../../../../../newlib-1.19.0/newlib/libc/stdio/clearerr.c:66:1: LLVM IR
generation of compound statement ('{}')
clang: error: unable to execute command: Segmentation fault
clang: error: clang frontend command failed due to signal (use -v to see
invocation)
clang: note: diagnostic msg: Please submit a bug report to
http://llvm.org/bugs/ and include command line arguments and all diagnostic
information.
clang: note: diagnostic msg: Preprocessed source(s) and associated run
script(s) are located at:
clang: note: diagnostic msg: /tmp/ce-wihH4b.i
clang: note: diagnostic msg: /tmp/ce-wihH4b.sh


"/var/build/Debug+Asserts/bin/clang" -cc1 -triple x86_64-unknown-linux-gnu
-emit-llvm -disable-free -main-file-name ce.c -mrelocation-model static
-mdisable-fp-elim -masm-verbose -mconstructor-aliases -munwind-tables
-target-cpu x86-64 -target-linker-version 2.21.0.20110327
-momit-leaf-frame-pointer -coverage-file /tmp/ce.ll -resource-dir
/var/build/Debug+Asserts/bin/../lib/clang/3.1 -fmodule-cache-path
/var/tmp/clang-module-cache -internal-isystem /usr/local/include
-internal-isystem /var/build/Debug+Asserts/bin/../lib/clang/3.1/include
-internal-externc-isystem /usr/include/x86_64-linux-gnu
-internal-externc-isystem /include -internal-externc-isystem /usr/include
-fdebug-compilation-dir
/home/jpbonn/Documents/mico32/newlib/build/lm32-rtems4.11/newlib/libc/stdio
-ferror-limit 19 -fmessage-length 82 -mstackrealign -fgnu-runtime
-fobjc-runtime-has-arc -fobjc-runtime-has-weak -fobjc-fragile-abi
-fdiagnostics-show-option -fcolor-diagnostics -o /tmp/ce.ll -x c /tmp/ce.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  Mon Dec 12 17:58:11 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 12 Dec 2011 23:58:11 +0000
Subject: [LLVMbugs] [Bug 11548] New: no diagnostic for ill-formed call to
 function on a member of the current instantiation
Message-ID: <bug-11548-206@http.llvm.org/bugs/>

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

             Bug #: 11548
           Summary: no diagnostic for ill-formed call to function on a
                    member of the current instantiation
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: richard-llvm at metafoo.co.uk
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified


This bit me recently: see r146366. g++ diagnoses the following, but clang
doesn't notice anything wrong with it:

struct A {
  void f(int);
};

template<typename T> struct S {
  A a;
  void g() {
    a.f();
  }
};

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

From bugzilla-daemon at llvm.org  Mon Dec 12 19:05:52 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 13 Dec 2011 01:05:52 +0000
Subject: [LLVMbugs] [Bug 11549] New: clang frontend command failed due to
	signal
Message-ID: <bug-11549-206@http.llvm.org/bugs/>

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

             Bug #: 11549
           Summary: clang frontend command failed due to signal
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Windows NT
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: 876762257 at qq.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


I tried to execute make, but get some error that i can't resolve

1) environment: 
cygwin at win7

2) clang version:
$ clang -v
clang version 3.1 (trunk 146369)
Target: i386-pc-cygwin
Thread model: posix

3) command:
clang -ccc-host-triple arm-apple-darwin9  -include LocalPush-Prefix.pch -c
-ObjC -fblocks -std=c99  -isysroot /toolchain4/sys
-D__IPHONE_OS_VERSION_MIN_REQUIRED=40000 -g0 -O2 -Wno-attributes -Wno-trigraphs
-Wreturn-type -Wunused-variable -I"." main.m -o main.o

4) source file:

only a main function

int main(int argc, char *argv[])
{
    //NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
    //int retVal = UIApplicationMain(argc, argv, nil, @"AppDelegate");
    //[pool release];
    return 1;
}

5) error info
clang -ccc-host-triple arm-apple-darwin9  -include LocalPush-Prefix.pch -c
-ObjC -fblocks -std=c99  -isysroot /toolchain4/sys
-D__IPHONE_OS_VERSION_MIN_REQUIRED=40000 -g0 -O2 -Wno-attributes -Wno-trigraphs
-Wreturn-type -Wunused-variable -I"." main.m -o main.o
clang: error: unable to execute command: Program could not be executed
clang: error: clang frontend command failed due to signal (use -v to see
invocation)
clang: note: diagnostic msg: Please submit a bug report to
http://llvm.org/bugs/ and include command line arguments and all diagnostic
information.
clang: error: unable to execute command: Program could not be executed
clang: note: diagnostic msg: Error generating preprocessed source(s).
Makefile:116: recipe for target `main.o' failed
make: *** [main.o] Error 255

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 12 19:56:08 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 13 Dec 2011 01:56:08 +0000
Subject: [LLVMbugs] [Bug 11550] New: Missing warning for unused variables of
 a class type with user declare constructor
Message-ID: <bug-11550-206@http.llvm.org/bugs/>

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

             Bug #: 11550
           Summary: Missing warning for unused variables of a class type
                    with user declare constructor
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: rafael.espindola at gmail.com
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified


We don't warn about
-------------------
struct S {
  S();
};
S foo();
void bar() {
  S x = foo();
}
-----------------

gcc 4.6 warns about x being "set but not used", which I don't think is
technically correct, but it is better than nothing.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 12 21:35:45 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 13 Dec 2011 03:35:45 +0000
Subject: [LLVMbugs] [Bug 11547] Clang crash compiling newlib
In-Reply-To: <bug-11547-206@http.llvm.org/bugs/>
References: <bug-11547-206@http.llvm.org/bugs/>
Message-ID: <bug-11547-206-NrqaVQiH0V@http.llvm.org/bugs/>

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

JP <jpbonn-keyword-llvmbug.a51747 at corniceresearch.com> changed:

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

--- Comment #2 from JP <jpbonn-keyword-llvmbug.a51747 at corniceresearch.com> 2011-12-12 21:35:45 CST ---
I'm closing this - I just built ToT on another machine and it's working.  I'm
assuming the tree where it occurs has something wrong.  I'll reopen if
necessary.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 13 02:20:09 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 13 Dec 2011 08:20:09 +0000
Subject: [LLVMbugs] [Bug 11551] New: Header search problem with clang trunk
	(3.1)
Message-ID: <bug-11551-206@http.llvm.org/bugs/>

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

             Bug #: 11551
           Summary: Header search  problem with clang trunk (3.1)
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Headers
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: ismail at namtrac.org
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 7717
  --> http://llvm.org/bugs/attachment.cgi?id=7717
clang 3.0 strace

Simple testcase:


#include <stddef.h>

int main()
{
}

[/kutu/t]> clang -v
clang version 3.1 (trunk 146366)
Target: x86_64-unknown-linux-gnu
Thread model: posix

[/kutu/t]> clang -c test.c
test.c:1:10: fatal error: 'stddef.h' file not found
#include <stddef.h>
         ^
1 error generated.  

Rolling back to clang 3.0


[/kutu/t]> clang -v
SUSE Linux clang version 3.0 (branches/release_30 145598) (based on LLVM 3.0)
Target: x86_64-unknown-linux-gnu
Thread model: posix


[/kutu/t]> clang test.c
[/kutu/t]> 

I will attached strace -efile clang -c test.c output for clang 3.0 and 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 Dec 13 02:24:21 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 13 Dec 2011 08:24:21 +0000
Subject: [LLVMbugs] [Bug 11552] New: make check-all not path independent,
 e.g. Preprocessor/macro_paste_c_block_comment.c fails on
 /scratch/...
Message-ID: <bug-11552-206@http.llvm.org/bugs/>

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

             Bug #: 11552
           Summary: make check-all not path independent, e.g.
                    Preprocessor/macro_paste_c_block_comment.c fails on
                    /scratch/...
           Product: Test Suite
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: lit
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: patrik.h.hagglund at ericsson.com
                CC: daniel at zuster.org, llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Preprocessor/macro_paste_c_block_comment.c contains 'not grep scratch', which
means that it fails if executed under for example /scratch/...

******************** TEST 'Clang :: Preprocessor/macro_paste_c_block_comment.c'
FAILED ********************
Script:
--
/scratch/bb-slaves/mipssw001/LLVM_optimize_install/build/Release+Asserts/bin/clang
-cc1 -internal-isystem
/scratch/bb-slaves/mipssw001/LLVM_optimize_install/build/Release+Asserts/bin/../lib/clang/3.1/include
/scratch/bb-slaves/mipssw001/LLVM_optimize_install/source/tools/clang/test/Preprocessor/macro_paste_c_block_comment.c
-Eonly 2>&1 | grep error
/scratch/bb-slaves/mipssw001/LLVM_optimize_install/build/Release+Asserts/bin/clang
-cc1 -internal-isystem
/scratch/bb-slaves/mipssw001/LLVM_optimize_install/build/Release+Asserts/bin/../lib/clang/3.1/include
/scratch/bb-slaves/mipssw001/LLVM_optimize_install/source/tools/clang/test/Preprocessor/macro_paste_c_block_comment.c
-Eonly 2>&1 | not grep unterminated
/scratch/bb-slaves/mipssw001/LLVM_optimize_install/build/Release+Asserts/bin/clang
-cc1 -internal-isystem
/scratch/bb-slaves/mipssw001/LLVM_optimize_install/build/Release+Asserts/bin/../lib/clang/3.1/include
/scratch/bb-slaves/mipssw001/LLVM_optimize_install/source/tools/clang/test/Preprocessor/macro_paste_c_block_comment.c
-Eonly 2>&1 | not grep scratch
--
Exit Code: 1
Command Output (stdout):
--
/scratch/bb-slaves/mipssw001/LLVM_optimize_install/source/tools/clang/test/Preprocessor/macro_paste_c_block_comment.c:6:1:
error: pasting formed '/*', an invalid preprocessing token
1 error generated.
/scratch/bb-slaves/mipssw001/LLVM_optimize_install/source/tools/clang/test/Preprocessor/macro_paste_c_block_comment.c:6:1:
error: pasting formed '/*', an invalid preprocessing token
/scratch/bb-slaves/mipssw001/LLVM_optimize_install/source/tools/clang/test/Preprocessor/macro_paste_c_block_comment.c:5:16:
note: expanded from macro 'COMM'
--

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 13 08:22:45 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 13 Dec 2011 14:22:45 +0000
Subject: [LLVMbugs] [Bug 11551] Header search problem with clang trunk (3.1)
In-Reply-To: <bug-11551-206@http.llvm.org/bugs/>
References: <bug-11551-206@http.llvm.org/bugs/>
Message-ID: <bug-11551-206-MJtPDsiLfk@http.llvm.org/bugs/>

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

?smail "cartman" D?nmez <ismail at namtrac.org> changed:

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

--- Comment #5 from ?smail "cartman" D?nmez <ismail at namtrac.org> 2011-12-13 08:22:45 CST ---
Fixed by correctly setting clang resource directory.

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

From bugzilla-daemon at llvm.org  Tue Dec 13 09:09:28 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 13 Dec 2011 15:09:28 +0000
Subject: [LLVMbugs] [Bug 11553] New: clang segfaults when compiling
 mesa-7.11.2 with debug symbols
Message-ID: <bug-11553-206@http.llvm.org/bugs/>

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

             Bug #: 11553
           Summary: clang segfaults when compiling mesa-7.11.2 with debug
                    symbols
           Product: clang
           Version: 3.0
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: balicki.aleksander at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 7721
  --> http://llvm.org/bugs/attachment.cgi?id=7721
preprocessed source file

tried installing mesa by:

FEATURES=splitdebug CC=clang CXX=clang++ emerge =mesa-7.11.2

the installation crashes with clang segfaulting

attaching 2 preprocessed files that diagnostic messages suggested and the build
log

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 13 09:31:52 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 13 Dec 2011 15:31:52 +0000
Subject: [LLVMbugs] [Bug 11554] New: basictypes.h: Conflict between int64
 and hardcoded long long on GCC 4.6.2 64 bit host build.
Message-ID: <bug-11554-206@http.llvm.org/bugs/>

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

             Bug #: 11554
           Summary: basictypes.h: Conflict between int64 and hardcoded
                    long long on GCC 4.6.2 64 bit host build.
           Product: compiler-rt
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: compiler-rt
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: rickfoosusa at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 7724
  --> http://llvm.org/bugs/attachment.cgi?id=7724
Patch to fix int64t / long long conflict in sscanf.

Build on Fedora 16 64 bit host fails. Conflict in sscanf between SCNx64 (llx)
and SCNd64 (int64_t). Compiler defines int64_t as long.

Patch for basictypes.h below resolves build problem. Passes unittests. Since
'long long' was hardcoded in int_types.h, I also hardcoded it in basictypes.h.
Since long long should always translate to int64t (when available), seems to
make sense.

-Rick

make[5]: Entering directory `/home/rick/llvm/projects/compiler-rt'
  COMPILE:   clang_linux/asan-x86_64/x86_64:
/home/rick/llvm/projects/compiler-rt/lib/asan/sysinfo/sysinfo.cc
/home/rick/llvm/projects/compiler-rt/lib/asan/sysinfo/sysinfo.cc:324:27: error: 
      conversion specifies type 'unsigned long long *' but the argument has
type
      'uint64 *' (aka 'unsigned long *') [-Werror,-Wformat]
    if (sscanf(stext_, "%"SCNx64"-%"SCNx64" %4s %"SCNx64" %x:%x %"SCNd64" %n",
                        ~~^
/home/rick/llvm/projects/compiler-rt/lib/asan/sysinfo/basictypes.h:82:19: note: 
      expanded from macro 'SCNx64'
#define SCNx64 "llx"
                  ^
/home/rick/llvm/projects/compiler-rt/lib/asan/sysinfo/sysinfo.cc:324:37: error: 
      conversion specifies type 'unsigned long long *' but the argument has
type
      'uint64 *' (aka 'unsigned long *') [-Werror,-Wformat]
    if (sscanf(stext_, "%"SCNx64"-%"SCNx64" %4s %"SCNx64" %x:%x %"SCNd64" %n",
                                  ~~^

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

From bugzilla-daemon at llvm.org  Tue Dec 13 11:47:09 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 13 Dec 2011 17:47:09 +0000
Subject: [LLVMbugs] [Bug 11555] New: OpenCL counts can overflow
Message-ID: <bug-11555-206@http.llvm.org/bugs/>

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

             Bug #: 11555
           Summary: OpenCL counts can overflow
           Product: clang
           Version: 3.0
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: schnetter at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


In OpenCL, shift counts should be taken modulo the size of the datatype. This
piece of code shows that this is not the case:

  if (((char)1 << (char)8) != (char)1) {
    printf("char FAIL\n");
  }

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

From bugzilla-daemon at llvm.org  Tue Dec 13 12:41:05 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 13 Dec 2011 18:41:05 +0000
Subject: [LLVMbugs] [Bug 11556] New: VLA folded pedantic error in -std=gnu99
Message-ID: <bug-11556-206@http.llvm.org/bugs/>

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

             Bug #: 11556
           Summary: VLA folded pedantic error in -std=gnu99
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: max at duempel.org
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


The following code generates a warning with -pedantic:

static const int size = 100;
void foo(void) { int data[size]; }

vla.c:2:27: warning: variable length array folded to constant array as an
extension [-pedantic]

The warning occurs only with "-std=gnu99" (or no "std" option, which defaults
to gnu99). It disappears with "-std=c99". Both C99 modes should behave the same
way here, and this warning makes sense only in "gnu89" mode.

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

From bugzilla-daemon at llvm.org  Tue Dec 13 12:56:12 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 13 Dec 2011 18:56:12 +0000
Subject: [LLVMbugs] [Bug 11557] New: Clang trunk build broken on Ubuntu
	11.04 x64
Message-ID: <bug-11557-206@http.llvm.org/bugs/>

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

             Bug #: 11557
           Summary: Clang trunk build broken on Ubuntu 11.04 x64
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: release blocker
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: abiryan at ryand.net
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


I have a nightly build of clang trunk (inside llvm trunk) running on an Ubuntu
11.04 x64 machine, and using the CMake build.  The build was broken between
r146143 and r146243 (the commits added the day it broke).  I get the following
message:

[ 59%] Building CXX object
tools/clang/lib/Basic/CMakeFiles/clangBasic.dir/DiagnosticIDs.cpp.o
In file included from
/var/lib/jenkins/jobs/Clang-Trunk/workspace/llvm/tools/clang/lib/Basic/DiagnosticIDs.cpp:24:0:
/var/lib/jenkins/jobs/Clang-Trunk/workspace/llvm/tools/clang/include/clang/Serialization/SerializationDiagnostic.h:21:56:
fatal error: clang/Basic/DiagnosticSerializationKinds.inc: No such file or
directory
compilation terminated.
make[2]: ***
[tools/clang/lib/Basic/CMakeFiles/clangBasic.dir/DiagnosticIDs.cpp.o] Error 1
make[1]: *** [tools/clang/lib/Basic/CMakeFiles/clangBasic.dir/all] Error 2
make: *** [all] Error 2

It continues to be broken since then, even on a completely clean checkout and
build, through at least my most recent build (r146476)

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 13 14:58:21 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 13 Dec 2011 20:58:21 +0000
Subject: [LLVMbugs] [Bug 11558] New: Crash in ActOnExplicitInstantiation():
 "point of instantiation must be valid!"
Message-ID: <bug-11558-206@http.llvm.org/bugs/>

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

             Bug #: 11558
           Summary: Crash in ActOnExplicitInstantiation(): "point of
                    instantiation must be valid!"
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: nicolasweber at gmx.de
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified


tests-MacBook-Pro-2:delta test$ cat repro.ii
namespace std {

template<typename _CharT>
class basic_string;

typedef basic_string<char> string;

template <typename STRING_TYPE> class BasicStringPiece;

template <> class BasicStringPiece<std::string> {
};

extern template class BasicStringPiece<std::string>;
template class BasicStringPiece<std::string>;

}  // namespace std
tests-MacBook-Pro-2:delta test$ gcc -x c++ -c repro.ii
tests-MacBook-Pro-2:delta test$
~/src/chrome-git/src/third_party/llvm-build/Release+Asserts/bin/clang -x c++ -c
repro.ii
Assertion failed: (Loc.isValid() && "point of instantiation must be valid!"),
function setPointOfInstantiation, file
/Volumes/MacintoshHD2/src/chrome-git/src/third_party/llvm/tools/clang/lib/Sema/../../include/clang/AST/DeclTemplate.h,
line 1416.
0  clang             0x00000001014c9ac2 _ZL15PrintStackTracePv + 34
1  clang             0x00000001014c9ff9 _ZL13SignalHandleri + 713
2  libsystem_c.dylib 0x00007fff8b0ffcfa _sigtramp + 26
3  clang             0x00000001002eb2ea clang::Parser::ParseTemplateArgument()
+ 138
4  clang             0x00000001000441e6 abort + 22
5  clang             0x0000000100044238 __assert_rtn + 56
6  clang             0x0000000100503cf5
clang::Sema::ActOnExplicitInstantiation(clang::Scope*, clang::SourceLocation,
clang::SourceLocation, unsigned int, clang::SourceLocation, clang::CXXScopeSpec
const&, clang::OpaquePtr<clang::TemplateName>, clang::SourceLocation,
clang::SourceLocation, clang::ASTTemplateArgsPtr, clang::SourceLocation,
clang::AttributeList*) + 2119
7  clang             0x00000001002c0ee8
clang::Parser::ParseClassSpecifier(clang::tok::TokenKind,
clang::SourceLocation, clang::DeclSpec&, clang::Parser::ParsedTemplateInfo
const&, clang::AccessSpecifier, bool, bool) + 2710
8  clang             0x00000001002b3e5e
clang::Parser::ParseDeclarationSpecifiers(clang::DeclSpec&,
clang::Parser::ParsedTemplateInfo const&, clang::AccessSpecifier,
clang::Parser::DeclSpecContext) + 6218
9  clang             0x00000001002ed4b5
clang::Parser::ParseSingleDeclarationAfterTemplate(unsigned int,
clang::Parser::ParsedTemplateInfo const&,
clang::Parser::ParsingDeclRAIIObject&, clang::SourceLocation&,
clang::AccessSpecifier, clang::AttributeList*) + 717
10 clang             0x00000001002ea15d
clang::Parser::ParseDeclarationStartingWithTemplate(unsigned int,
clang::SourceLocation&, clang::AccessSpecifier, clang::AttributeList*) + 429
11 clang             0x00000001002b6fc3
clang::Parser::ParseDeclaration(clang::ASTOwningVector<clang::Stmt*, 32u>&,
unsigned int, clang::SourceLocation&,
clang::Parser::ParsedAttributesWithRange&) + 381
12 clang             0x00000001002f723e
clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&,
clang::Parser::ParsingDeclSpec*) + 1776
13 clang             0x00000001002c287a
clang::Parser::ParseInnerNamespace(std::vector<clang::SourceLocation,
std::allocator<clang::SourceLocation> >&, std::vector<clang::IdentifierInfo*,
std::allocator<clang::IdentifierInfo*> >&, std::vector<clang::SourceLocation,
std::allocator<clang::SourceLocation> >&, unsigned int, clang::SourceLocation&,
clang::ParsedAttributes&, clang::Parser::BalancedDelimiterTracker&) + 256
14 clang             0x00000001002b861b clang::Parser::ParseNamespace(unsigned
int, clang::SourceLocation&, clang::SourceLocation) + 3323
15 clang             0x00000001002b706b
clang::Parser::ParseDeclaration(clang::ASTOwningVector<clang::Stmt*, 32u>&,
unsigned int, clang::SourceLocation&,
clang::Parser::ParsedAttributesWithRange&) + 549
16 clang             0x00000001002f723e
clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&,
clang::Parser::ParsingDeclSpec*) + 1776
17 clang             0x00000001002f7d6e
clang::Parser::ParseTopLevelDecl(clang::OpaquePtr<clang::DeclGroupRef>&) + 262
18 clang             0x00000001002a3175 clang::ParseAST(clang::Sema&, bool) +
325
19 clang             0x000000010026f2cc clang::CodeGenAction::ExecuteAction() +
924
20 clang             0x0000000100065a96
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 962
21 clang             0x000000010004da31
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 2161
22 clang             0x0000000100047acb cc1_main(char const**, char const**,
char const*, void*) + 2923
23 clang             0x000000010004aab0 main + 640
24 clang             0x0000000100046f4c start + 52
25 clang             0x000000000000002f start + 18446744069414293783
Stack dump:
0.    Program arguments:
/Users/test/src/chrome-git/src/third_party/llvm-build/Release+Asserts/bin/clang
-cc1 -triple x86_64-apple-macosx10.7.2 -emit-obj -mrelax-all -disable-free
-main-file-name repro.ii -pic-level 1 -mdisable-fp-elim -masm-verbose
-munwind-tables -target-cpu core2 -target-linker-version 97.17 -coverage-file
repro.o -resource-dir
/Users/test/src/chrome-git/src/third_party/llvm-build/Release+Asserts/bin/../lib/clang/3.1
-fmodule-cache-path
/var/folders/5j/6xp_dl050mv_b_0_56s5mjx80000gn/T/clang-module-cache
-fdeprecated-macro -fdebug-compilation-dir /Users/test/src/delta -ferror-limit
19 -fmessage-length 267 -stack-protector 1 -mstackrealign -fblocks
-fobjc-runtime-has-arc -fobjc-runtime-has-weak -fobjc-dispatch-method=mixed
-fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o
repro.o -x c++ repro.ii 
1.    repro.ii:14:45: current parser token ';'
2.    repro.ii:1:1: parsing namespace 'std'
clang: error: unable to execute command: Illegal instruction: 4
clang: error: clang frontend command failed due to signal (use -v to see
invocation)
clang: note: diagnostic msg: Please submit a bug report to
http://llvm.org/bugs/ and include command line arguments and all diagnostic
information.
clang: note: diagnostic msg: Preprocessed source(s) and associated run
script(s) are located at:
clang: note: diagnostic msg:
/var/folders/5j/6xp_dl050mv_b_0_56s5mjx80000gn/T/repro-VirH75.ii
clang: note: diagnostic msg:
/var/folders/5j/6xp_dl050mv_b_0_56s5mjx80000gn/T/repro-VirH75.sh

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 13 15:46:43 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 13 Dec 2011 21:46:43 +0000
Subject: [LLVMbugs] =?utf-8?q?=5BBug_11559=5D_New=3A_Regression=3A_clang_c?=
 =?utf-8?q?laims_that_-=5BNSApp_stop=3A=5D__is_deprecated_=E2=80=93_but_on?=
 =?utf-8?q?ly_on_i386?=
Message-ID: <bug-11559-206@http.llvm.org/bugs/>

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

             Bug #: 11559
           Summary: Regression: clang claims that -[NSApp stop:] is
                    deprecated ? but only on i386
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: nicolasweber at gmx.de
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


$ cat test.mm
#import <AppKit/AppKit.h>

int main() {
  [NSApp stop:nil];
}
tests-MacBook-Pro-2:src test$ third_party/llvm-build/Release+Asserts/bin/clang
-c  test.mm   
tests-MacBook-Pro-2:src test$ third_party/llvm-build/Release+Asserts/bin/clang
-c  test.mm   -arch i386
test.mm:4:4: warning: 'stop:' is deprecated [-Wdeprecated-declarations]
  [NSApp stop:nil];
   ^
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  Tue Dec 13 18:52:19 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 14 Dec 2011 00:52:19 +0000
Subject: [LLVMbugs] =?utf-8?q?=5BBug_11559=5D_Regression=3A_clang_claims_t?=
 =?utf-8?q?hat_-=5BNSApp_stop=3A=5D__is_deprecated_=E2=80=93_but_only_on_i?=
 =?utf-8?q?386?=
In-Reply-To: <bug-11559-206@http.llvm.org/bugs/>
References: <bug-11559-206@http.llvm.org/bugs/>
Message-ID: <bug-11559-206-YhZmmmmRtV@http.llvm.org/bugs/>

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

Fariborz Jahanian <fjahanian at apple.com> changed:

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

--- Comment #1 from Fariborz Jahanian <fjahanian at apple.com> 2011-12-13 18:52:19 CST ---
When compiled for i386, I see that 
- (void)stop:(id)sender __attribute__((deprecated));
is deprecated in @interface NSMovieView

I also see that NSMovieView class has been ifdef'ed out under x86_64 compile.
This is not a clang 
issue and behaves as expected.

> $ cat test.mm
> #import <AppKit/AppKit.h>
> 
> int main() {
>   [NSApp stop:nil];
> }
> tests-MacBook-Pro-2:src test$ third_party/llvm-build/Release+Asserts/bin/clang
> -c  test.mm   
> tests-MacBook-Pro-2:src test$ third_party/llvm-build/Release+Asserts/bin/clang
> -c  test.mm   -arch i386
> test.mm:4:4: warning: 'stop:' is deprecated [-Wdeprecated-declarations]
>   [NSApp stop:nil];
>    ^
> 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  Tue Dec 13 20:16:25 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 14 Dec 2011 02:16:25 +0000
Subject: [LLVMbugs] [Bug 11552] make check-all not path independent,
 e.g. Preprocessor/macro_paste_c_block_comment.c fails on
 /scratch/...
In-Reply-To: <bug-11552-206@http.llvm.org/bugs/>
References: <bug-11552-206@http.llvm.org/bugs/>
Message-ID: <bug-11552-206-I9yNk12rbr@http.llvm.org/bugs/>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |sharparrow1 at yahoo.com
         Resolution|                            |FIXED

--- Comment #1 from Eli Friedman <sharparrow1 at yahoo.com> 2011-12-13 20:16:25 CST ---
r146544.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 13 20:43:40 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 14 Dec 2011 02:43:40 +0000
Subject: [LLVMbugs] [Bug 11561] New: Segfault on a C++ example
Message-ID: <bug-11561-206@http.llvm.org/bugs/>

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

             Bug #: 11561
           Summary: Segfault on a C++ example
           Product: clang
           Version: 3.0
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: llvm at foxcub.org
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 7725
  --> http://llvm.org/bugs/attachment.cgi?id=7725
segfault example

clang++ segfaults on the attached example. g++ compiles it fine.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 13 20:50:30 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 14 Dec 2011 02:50:30 +0000
Subject: [LLVMbugs] [Bug 11561] Segfault on a C++ example
In-Reply-To: <bug-11561-206@http.llvm.org/bugs/>
References: <bug-11561-206@http.llvm.org/bugs/>
Message-ID: <bug-11561-206-07KRhLjf8k@http.llvm.org/bugs/>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |sharparrow1 at yahoo.com
         Resolution|                            |WORKSFORME

--- Comment #1 from Eli Friedman <sharparrow1 at yahoo.com> 2011-12-13 20:50:30 CST ---
I can reproduce this issue with Apple clang-211, but not with trunk 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  Wed Dec 14 00:21:40 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 14 Dec 2011 06:21:40 +0000
Subject: [LLVMbugs] [Bug 11562] New: Dead link on LLVMBuild documentation
	page
Message-ID: <bug-11562-206@http.llvm.org/bugs/>

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

             Bug #: 11562
           Summary: Dead link on LLVMBuild documentation page
           Product: Documentation
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: General docs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: eliben at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


http://llvm.org/docs/LLVMBuild.html has a link to
http://llvm.org/docs/CommandGuide/html/llvm-build.html, which is 404

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 14 00:34:20 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 14 Dec 2011 06:34:20 +0000
Subject: [LLVMbugs] [Bug 11563] New: Patch with some typo fixes for
 LLVMBuild documentation
Message-ID: <bug-11563-206@http.llvm.org/bugs/>

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

             Bug #: 11563
           Summary: Patch with some typo fixes for LLVMBuild documentation
           Product: Documentation
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: General docs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: eliben at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 7726
  --> http://llvm.org/bugs/attachment.cgi?id=7726
A patch file made by svn diff

Attaching a patch with some typo fixes for docs/LLVMBuild.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 Dec 14 04:13:45 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 14 Dec 2011 10:13:45 +0000
Subject: [LLVMbugs] [Bug 11564] New: Incorrect warning about hidden
 overloaded virtual function with virtual inheritance
Message-ID: <bug-11564-206@http.llvm.org/bugs/>

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

             Bug #: 11564
           Summary: Incorrect warning about hidden overloaded virtual
                    function with virtual inheritance
           Product: clang
           Version: 3.0
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: zhezherun at yandex.ru
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


The following code generates a warning in clang 3.0:


struct A {
    virtual ~A() {}
    virtual void func(int) = 0;
};

struct B {
    virtual ~B() {}
    virtual void func(double) = 0;
};

struct Base: public virtual A {
    virtual void func(int) {}
};

struct Derived: public Base, virtual public A, virtual public B {
    virtual void func(int) {}
    virtual void func(double) {}
};

int main() {
    Derived d;
    d.func(1);
    d.func(1.0);
}


./clang++ -Wall -o test test.cpp
test.cpp:17:18: warning: 'Derived::func' hides overloaded virtual function
[-Woverloaded-virtual]
    virtual void func(double) {}
                 ^
test.cpp:3:18: note: hidden overloaded virtual function 'A::func' declared here
    virtual void func(int) = 0;
                 ^
1 warning generated.


Note that func(int) is implemented in Derived, so it is not hidden and the
warning is incorrect. gcc 4.6.2 processes this example correctly and does not
generate any warnings.

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

From bugzilla-daemon at llvm.org  Wed Dec 14 05:51:15 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 14 Dec 2011 11:51:15 +0000
Subject: [LLVMbugs] [Bug 11565] New: _mm_test_all_zeros macro is incorrect
Message-ID: <bug-11565-206@http.llvm.org/bugs/>

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

             Bug #: 11565
           Summary: _mm_test_all_zeros macro is incorrect
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: loufoque at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


smmintrin.h defines _mm_test_all_zeros as
#define _mm_test_all_zeros(M, V) _mm_testz_si128 ((V), (V))

this is clearly incorrect, it should be
#define _mm_test_all_zeros(M, V) _mm_testz_si128 ((M), (V))

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 14 09:05:00 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 14 Dec 2011 15:05:00 +0000
Subject: [LLVMbugs] [Bug 11566] New: clang keeps frame pointers by default
 on linux x86_64
Message-ID: <bug-11566-206@http.llvm.org/bugs/>

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

             Bug #: 11566
           Summary: clang keeps frame pointers by default on linux x86_64
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Driver
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: rafael.espindola at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


given

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

"gcc -c foo.c -Os -o foo.o" will produce

push   %rax
callq  6 <f+0x6>
pop    %rdx
jmpq   c <f+0xc>

(no idea what gcc is doing with rax/rdx).

"clang -c foo.c -Os -o foo.o" produces

push   %rbp
mov    %rsp,%rbp
callq  9 <f+0x9>
pop    %rbp
jmpq   f <f+0xf>

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 14 09:09:31 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 14 Dec 2011 15:09:31 +0000
Subject: [LLVMbugs] [Bug 11567] New: unnecessary sign extension
Message-ID: <bug-11567-206@http.llvm.org/bugs/>

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

             Bug #: 11567
           Summary: unnecessary sign extension
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Scalar Optimizations
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: rafael.espindola at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


in
-------------------------------------------
extern void do_something_with(char *arr);

void foo(char **arr, int n) {
   for (T i = 0; i < n; i++) {
     do_something_with(arr[2*i]);
   }
}
------------------------------------------

the loop produced by clang is

movslq %r15d,%r15
mov    (%r14,%r15,8),%rdi
callq  1d <foo+0x1d>
add    $0x2,%r15d
dec    %ebx
jne    11 <foo+0x11>

the loop produced by gcc is

mov    0x0(%rbp),%rdi
inc    %ebx
add    $0x10,%rbp
callq  1d <foo+0x1d>
cmp    %r12d,%ebx
jl     e <foo+0xe>

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 14 10:12:31 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 14 Dec 2011 16:12:31 +0000
Subject: [LLVMbugs] [Bug 11568] New:
 clang/Basic/DiagnosticSerializationKinds.inc does not get generated by
 CMake
Message-ID: <bug-11568-206@http.llvm.org/bugs/>

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

             Bug #: 11568
           Summary: clang/Basic/DiagnosticSerializationKinds.inc does not
                    get generated by CMake
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: oroppas at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


It seems that CMake ignores clang_diag_gen(Serialization) in
clang/include/clang/Basic/CMakeLists.txt:

Scanning dependencies of target ClangDiagnosticAnalysis
[ 60%] Building DiagnosticAnalysisKinds.inc...
[ 60%] Built target ClangDiagnosticAnalysis
Scanning dependencies of target ClangDiagnosticAST
[ 60%] Building DiagnosticASTKinds.inc...
[ 60%] Built target ClangDiagnosticAST
Scanning dependencies of target ClangDiagnosticCommon
[ 60%] Building DiagnosticCommonKinds.inc...
[ 60%] Built target ClangDiagnosticCommon
Scanning dependencies of target ClangDiagnosticDriver
[ 60%] Building DiagnosticDriverKinds.inc...
[ 60%] Built target ClangDiagnosticDriver
Scanning dependencies of target ClangDiagnosticFrontend
[ 60%] Building DiagnosticFrontendKinds.inc...
[ 60%] Built target ClangDiagnosticFrontend
Scanning dependencies of target ClangDiagnosticLex
[ 60%] Building DiagnosticLexKinds.inc...
[ 60%] Built target ClangDiagnosticLex
Scanning dependencies of target ClangDiagnosticParse
[ 60%] Building DiagnosticParseKinds.inc...
[ 60%] Built target ClangDiagnosticParse
Scanning dependencies of target ClangDiagnosticSema
[ 60%] Building DiagnosticSemaKinds.inc...
[ 60%] Built target ClangDiagnosticSema
Scanning dependencies of target ClangDiagnosticGroups
[ 60%] Building DiagnosticGroups.inc...
[ 60%] Built target ClangDiagnosticGroups
Scanning dependencies of target ClangAttrList
[ 60%] Building AttrList.inc...
[ 60%] Built target ClangAttrList
Scanning dependencies of target ClangDiagnosticIndexName
[ 60%] Building DiagnosticIndexName.inc...
[ 60%] Built target ClangDiagnosticIndexName
Scanning dependencies of target clangBasic
[ 60%] Building CXX object
tools/clang/lib/Basic/CMakeFiles/clangBasic.dir/Builtins.cpp.o
[ 60%] Building C object
tools/clang/lib/Basic/CMakeFiles/clangBasic.dir/ConvertUTF.c.o
[ 60%] Building CXX object
tools/clang/lib/Basic/CMakeFiles/clangBasic.dir/Diagnostic.cpp.o
[ 60%] Building CXX object
tools/clang/lib/Basic/CMakeFiles/clangBasic.dir/DiagnosticIDs.cpp.o
In file included from
/home/ryuta/devel/llvm/src/llvm/tools/clang/lib/Basic/DiagnosticIDs.cpp:24:0:
/home/ryuta/devel/llvm/src/llvm/tools/clang/include/clang/Serialization/SerializationDiagnostic.h:21:56:
fatal error: clang/Basic/DiagnosticSerializationKinds.inc: No such file or
directory
compilation terminated.
make[2]: ***
[tools/clang/lib/Basic/CMakeFiles/clangBasic.dir/DiagnosticIDs.cpp.o] Error 1
make[1]: *** [tools/clang/lib/Basic/CMakeFiles/clangBasic.dir/all] Error 2
make: *** [all] Error 2
==> ERROR: A failure occurred in build().
    Aborting...


Any ideas?

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 14 11:17:32 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 14 Dec 2011 17:17:32 +0000
Subject: [LLVMbugs] [Bug 11565] _mm_test_all_zeros macro is incorrect
In-Reply-To: <bug-11565-206@http.llvm.org/bugs/>
References: <bug-11565-206@http.llvm.org/bugs/>
Message-ID: <bug-11565-206-wf9Ivz6oOQ@http.llvm.org/bugs/>

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

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

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

--- Comment #1 from Bob Wilson <bob.wilson at apple.com> 2011-12-14 11:17:32 CST ---
svn r146565.  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 Dec 14 12:35:56 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 14 Dec 2011 18:35:56 +0000
Subject: [LLVMbugs] [Bug 11570] New: boost karma causes clang optimizer crash
Message-ID: <bug-11570-206@http.llvm.org/bugs/>

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

             Bug #: 11570
           Summary: boost karma causes clang optimizer crash
           Product: clang
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: release blocker
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: kyle.tarplee at numerica.us
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 7727
  --> http://llvm.org/bugs/attachment.cgi?id=7727
the code that causes the crash

I have distilled the crash down to a simple one liner that causes the compiler
to fresh with the error


fatal error: error in backend: Cannot select: 0x7fa5b6abb210: i64 = shl
0x7fa5b6ae0c10, 0x7fa5b6ab7c10 [ID=23]
  0x7fa5b6ae0c10: i64 = fgetsign 0x7fa5b6ae0a10 [ID=21]
    0x7fa5b6ae0a10: f64,ch = CopyFromReg 0x7fa5b5b6c528, 0x7fa5b6ae0b10
[ORD=324] [ID=17]
      0x7fa5b6ae0b10: f64 = Register %vreg1 [ORD=324] [ID=1]
  0x7fa5b6ab7c10: i64 = Constant<63> [ID=16]

When the optimization (-0) is turned on.  Without optimization it compiles
fine.

To reproduce it:

CC=clang++
#Any boost seems to do it
BOOST_HDRS=/opt/local/include
#BOOST_HDRS=~/projs/boost/boost_1_45_0


echo "No optimization"
$CC -c -I$BOOST_HDRS test_karma.cpp

echo "With -O optimization (expected failure)"
$CC -c -O -I$BOOST_HDRS test_karma.cpp



The error happens on clang++ version 3.0 from apple and on llvm trunk (r146173)
and clang trunk (r146174).

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 14 13:15:57 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 14 Dec 2011 19:15:57 +0000
Subject: [LLVMbugs] [Bug 11571] New: Instruction does not dominate all uses!
 PHI nodes not grouped at top of basic block!
Message-ID: <bug-11571-206@http.llvm.org/bugs/>

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

             Bug #: 11571
           Summary: Instruction does not dominate all uses! PHI nodes not
                    grouped at top of basic block!
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: FreeBSD
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Backend: X86
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: rdivacky at freebsd.org
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


witten delta# llc vb.ll
Instruction does not dominate all uses!
  %lsr.iv30 = phi i32 [ 0, %for.body7.lr.ph.preheader ], [ %lsr.iv.next31,
%for.inc32 ]
  %lsr.iv.next46 = add i32 %lsr.iv30, 2
PHI nodes not grouped at top of basic block!
  %lsr.iv33 = phi i32 [ 0, %for.body7.lr.ph.preheader ], [ %lsr.iv.next34,
%for.inc32 ]
label %for.body7.lr.ph
PHI nodes not grouped at top of basic block!
  %lsr.iv17 = phi i32 [ 0, %for.body7.lr.ph.preheader ], [ %lsr.iv.next18,
%for.inc32 ]
label %for.body7.lr.ph
Instruction does not dominate all uses!
  %lsr.iv2 = phi i32 [ 0, %for.body7.lr.ph.preheader ], [ %lsr.iv.next3,
%for.inc32 ]
  %lsr.iv.next16 = add i32 %lsr.iv2, 2
PHI nodes not grouped at top of basic block!
  %lsr.iv5 = phi i32 [ 0, %for.body7.lr.ph.preheader ], [ %lsr.iv.next6,
%for.inc32 ]
label %for.body7.lr.ph
PHI nodes not grouped at top of basic block!
  %indvars.iv77 = phi i32 [ %indvars.iv.next78, %for.inc32 ], [ 1,
%for.body7.lr.ph.preheader ]
label %for.body7.lr.ph
Instruction does not dominate all uses!
  %indvars.iv77 = phi i32 [ %indvars.iv.next78, %for.inc32 ], [ 1,
%for.body7.lr.ph.preheader ]
  %1 = add i32 %bf.072, %indvars.iv77
Broken module found, compilation aborted!
Stack dump:
0.    Program arguments: llc vb.ll 
1.    Running pass 'Function Pass Manager' on module 'vb.ll'.
2.    Running pass 'Module Verifier' on function '@vb'
Abort (core dumped)

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

From bugzilla-daemon at llvm.org  Wed Dec 14 13:25:59 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 14 Dec 2011 19:25:59 +0000
Subject: [LLVMbugs] [Bug 11572] New: Right shift of a bit field strips the
 "unsigned" type property from a bitfield
Message-ID: <bug-11572-206@http.llvm.org/bugs/>

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

             Bug #: 11572
           Summary: Right shift of a bit field strips the "unsigned" type
                    property from a bitfield
           Product: clang
           Version: 3.0
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: Kevin.Harris at unisys.com
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 7730
  --> http://llvm.org/bugs/attachment.cgi?id=7730
source file for the bug

With the following test source:

class Example {
public:
    unsigned int lock : 26;
    unsigned int v1    :  3;
    unsigned int v2    :  3;

inline    unsigned int getPermission(unsigned int key)
    {
        if( key != 0 ){
            if( ( key >> 24 ) < ( lock >> 24 ) )
                return (unsigned int)( v1 );
            else
                return (unsigned int)( v2 );
        }
        return 7;
    };
};

I get a warning on the compare when -Wsign-compare is in effect.

va-sa.cpp:10:31: warning: comparison of integers of different signs:
      'unsigned int' and 'int' [-Wsign-compare]
            if( ( key >> 24 ) < ( lock >> 24 ) )
                  ~~~~~~~~~   ^   ~~~~~~~~~~

What seems to have happened is that the >> operator strips the "unsigned"
property when the left operand is a bit field.  Both the use of a bit field
and the use of the >> operator are needed to trigger the warning.  

g++ 4.5.3 doesn't give a warning for 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 Dec 14 13:26:49 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 14 Dec 2011 19:26:49 +0000
Subject: [LLVMbugs] [Bug 9905] Failure in code selection for llvm intrinsics
	sqrt/exp
In-Reply-To: <bug-9905-206@http.llvm.org/bugs/>
References: <bug-9905-206@http.llvm.org/bugs/>
Message-ID: <bug-9905-206-h9mWKasssN@http.llvm.org/bugs/>

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

Stepan Dyatkovskiy <stpworld at narod.ru> changed:

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

--- Comment #3 from Stepan Dyatkovskiy <stpworld at narod.ru> 2011-12-14 13:26:49 CST ---
Resolved in 146341. There are some FIXMEs 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  Wed Dec 14 13:34:04 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 14 Dec 2011 19:34:04 +0000
Subject: [LLVMbugs] [Bug 11566] clang keeps frame pointers by default on
	linux x86_64
In-Reply-To: <bug-11566-206@http.llvm.org/bugs/>
References: <bug-11566-206@http.llvm.org/bugs/>
Message-ID: <bug-11566-206-jjLx0WdtiC@http.llvm.org/bugs/>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |sharparrow1 at yahoo.com
         Resolution|                            |DUPLICATE

--- Comment #1 from Eli Friedman <sharparrow1 at yahoo.com> 2011-12-14 13:34:04 CST ---


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

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 14 15:03:28 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 14 Dec 2011 21:03:28 +0000
Subject: [LLVMbugs] [Bug 8186] -fomit-frame-pointer should be on by default
 at -O1+ on linux/x86-64
In-Reply-To: <bug-8186-206@http.llvm.org/bugs/>
References: <bug-8186-206@http.llvm.org/bugs/>
Message-ID: <bug-8186-206-GKfwW6mVdT@http.llvm.org/bugs/>

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

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-12-14 15:03:28 CST ---
Fixed in r146586.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 14 15:13:59 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 14 Dec 2011 21:13:59 +0000
Subject: [LLVMbugs] [Bug 11572] Right shift of a bit field strips the
 "unsigned" type property from a bitfield
In-Reply-To: <bug-11572-206@http.llvm.org/bugs/>
References: <bug-11572-206@http.llvm.org/bugs/>
Message-ID: <bug-11572-206-AxvwsiCt3n@http.llvm.org/bugs/>

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

Kevin W. Harris <Kevin.Harris at unisys.com> changed:

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

--- Comment #5 from Kevin W. Harris <Kevin.Harris at unisys.com> 2011-12-14 15:13:59 CST ---
Eli,
     Thanks for the explanation.  I see it now.  Even more to the point,
6.3.1.8 says, in describing integer promotions (2nd to last clause):
"Otherwise, if the type of the operand with signed integer type can represent
all the values of the type of the operand with unsigned integer type, then the
operand with unsigned integer type is converted to the type of the operand with
signed integer type."

I'll withdraw the report.
     -Kevin

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 14 15:19:34 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 14 Dec 2011 21:19:34 +0000
Subject: [LLVMbugs] [Bug 11573] New: segfault on expr/expr.const/p2-0x.cpp
Message-ID: <bug-11573-206@http.llvm.org/bugs/>

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

             Bug #: 11573
           Summary: segfault on expr/expr.const/p2-0x.cpp
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: FreeBSD
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: pawel.worach at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


After r146479 clang crashes on the test below, this seems to happen on both
FreeBSD amd64 and i386, valgrind gives no errors.

If a run with debug symbols would help I can arrange that.

1>buildbot at llvm-amd64 /tmp> gdb
/data/buildslave/clang-amd64-freebsd/obj/llvm.1/Release+Asserts/bin/clang
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd"...(no debugging symbols
found)...
(gdb) run -cc1 -internal-isystem
/data/buildslave/clang-amd64-freebsd/obj/llvm.1/Release+Asserts/bin/../lib/clang/3.1/include
-fsyntax-only -std=c++11 -pedantic -verify -fcxx-exceptions
/data/buildslave/clang-amd64-freebsd/src-llvm/tools/clang/test/CXX/expr/expr.const/p2-0x.cpp
Starting program:
/data/buildslave/freebsd-clang-amd64/obj/llvm.1/Release+Asserts/bin/clang -cc1
-internal-isystem
/data/buildslave/clang-amd64-freebsd/obj/llvm.1/Release+Asserts/bin/../lib/clang/3.1/include
-fsyntax-only -std=c++11 -pedantic -verify -fcxx-exceptions
/data/buildslave/clang-amd64-freebsd/src-llvm/tools/clang/test/CXX/expr/expr.const/p2-0x.cpp
(no debugging symbols found)...[New LWP 102929]
(no debugging symbols found)...(no debugging symbols found)...(no debugging
symbols found)...(no debugging symbols found)...(no debugging symbols
found)...[New Thread 803807400 (LWP 102929/clang)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 803807400 (LWP 102929/clang)]
0x000000000134c553 in clang::StmtVisitorBase<clang::make_const_ptr, (anonymous
namespace)::LValueExprEvaluator, bool>::Visit ()
(gdb) bt
#0  0x000000000134c553 in clang::StmtVisitorBase<clang::make_const_ptr,
(anonymous namespace)::LValueExprEvaluator, bool>::Visit ()
#1  0x000000000134cd8b in EvaluateLValue ()
#2  0x000000000133afbf in (anonymous
namespace)::PointerExprEvaluator::VisitCastExpr ()
#3  0x000000000133c9c9 in clang::StmtVisitorBase<clang::make_const_ptr,
(anonymous namespace)::PointerExprEvaluator, bool>::Visit ()
#4  0x000000000133d7da in EvaluatePointer ()
#5  0x0000000001343866 in Evaluate ()
#6  0x000000000136807d in (anonymous namespace)::ExprEvaluatorBase<(anonymous
namespace)::IntExprEvaluator, bool>::VisitCallExpr ()
#7  0x0000000001368781 in (anonymous
namespace)::IntExprEvaluator::VisitCallExpr ()
#8  0x00000000013385f4 in clang::StmtVisitorBase<clang::make_const_ptr,
(anonymous namespace)::IntExprEvaluator, bool>::Visit ()
#9  0x0000000001365f98 in (anonymous
namespace)::IntExprEvaluator::VisitBinaryOperator ()
#10 0x0000000001337e05 in clang::StmtVisitorBase<clang::make_const_ptr,
(anonymous namespace)::IntExprEvaluator, bool>::Visit ()
#11 0x0000000001343a6c in Evaluate ()
#12 0x00000000013477f9 in EvaluateStmt ()
#13 0x00000000013477a7 in EvaluateStmt ()
#14 0x0000000001347ac2 in HandleFunctionCall ()
---Type <return> to continue, or q <return> to quit---
#15 0x000000000136811a in (anonymous namespace)::ExprEvaluatorBase<(anonymous
namespace)::IntExprEvaluator, bool>::VisitCallExpr ()
#16 0x0000000001368781 in (anonymous
namespace)::IntExprEvaluator::VisitCallExpr ()
#17 0x00000000013385f4 in clang::StmtVisitorBase<clang::make_const_ptr,
(anonymous namespace)::IntExprEvaluator, bool>::Visit ()
#18 0x0000000001365f98 in (anonymous
namespace)::IntExprEvaluator::VisitBinaryOperator ()
#19 0x0000000001337e05 in clang::StmtVisitorBase<clang::make_const_ptr,
(anonymous namespace)::IntExprEvaluator, bool>::Visit ()
#20 0x0000000001343a6c in Evaluate ()
#21 0x00000000013477f9 in EvaluateStmt ()
#22 0x00000000013477a7 in EvaluateStmt ()
#23 0x0000000001347ac2 in HandleFunctionCall ()
#24 0x000000000136811a in (anonymous namespace)::ExprEvaluatorBase<(anonymous
namespace)::IntExprEvaluator, bool>::VisitCallExpr ()
#25 0x0000000001368781 in (anonymous
namespace)::IntExprEvaluator::VisitCallExpr ()
#26 0x00000000013385f4 in clang::StmtVisitorBase<clang::make_const_ptr,
(anonymous namespace)::IntExprEvaluator, bool>::Visit ()
#27 0x0000000001365f98 in (anonymous
namespace)::IntExprEvaluator::VisitBinaryOperator ()
#28 0x0000000001337e05 in clang::StmtVisitorBase<clang::make_const_ptr,
(anonymo---Type <return> to continue, or q <return> to quit---
us namespace)::IntExprEvaluator, bool>::Visit ()
#29 0x0000000001343a6c in Evaluate ()
#30 0x00000000013477f9 in EvaluateStmt ()
#31 0x00000000013477a7 in EvaluateStmt ()
#32 0x0000000001347ac2 in HandleFunctionCall ()
#33 0x000000000136811a in (anonymous namespace)::ExprEvaluatorBase<(anonymous
namespace)::IntExprEvaluator, bool>::VisitCallExpr ()
#34 0x0000000001368781 in (anonymous
namespace)::IntExprEvaluator::VisitCallExpr ()
#35 0x00000000013385f4 in clang::StmtVisitorBase<clang::make_const_ptr,
(anonymous namespace)::IntExprEvaluator, bool>::Visit ()
#36 0x0000000001365f98 in (anonymous
namespace)::IntExprEvaluator::VisitBinaryOperator ()
#37 0x0000000001337e05 in clang::StmtVisitorBase<clang::make_const_ptr,
(anonymous namespace)::IntExprEvaluator, bool>::Visit ()
#38 0x0000000001343a6c in Evaluate ()
#39 0x00000000013477f9 in EvaluateStmt ()
#40 0x00000000013477a7 in EvaluateStmt ()
#41 0x0000000001347ac2 in HandleFunctionCall ()
#42 0x000000000136811a in (anonymous namespace)::ExprEvaluatorBase<(anonymous
namespace)::IntExprEvaluator, bool>::VisitCallExpr ()
#43 0x0000000001368781 in (anonymous
namespace)::IntExprEvaluator::VisitCallExpr ()
---Type <return> to continue, or q <return> to quit---
#44 0x00000000013385f4 in clang::StmtVisitorBase<clang::make_const_ptr,
(anonymous namespace)::IntExprEvaluator, bool>::Visit ()
#45 0x0000000001365f98 in (anonymous
namespace)::IntExprEvaluator::VisitBinaryOperator ()
#46 0x0000000001337e05 in clang::StmtVisitorBase<clang::make_const_ptr,
(anonymous namespace)::IntExprEvaluator, bool>::Visit ()
#47 0x0000000001343a6c in Evaluate ()
#48 0x00000000013477f9 in EvaluateStmt ()
#49 0x00000000013477a7 in EvaluateStmt ()
#50 0x0000000001347ac2 in HandleFunctionCall ()
#51 0x000000000136811a in (anonymous namespace)::ExprEvaluatorBase<(anonymous
namespace)::IntExprEvaluator, bool>::VisitCallExpr ()
#52 0x0000000001368781 in (anonymous
namespace)::IntExprEvaluator::VisitCallExpr ()
#53 0x00000000013385f4 in clang::StmtVisitorBase<clang::make_const_ptr,
(anonymous namespace)::IntExprEvaluator, bool>::Visit ()
#54 0x0000000001365f98 in (anonymous
namespace)::IntExprEvaluator::VisitBinaryOperator ()
#55 0x0000000001337e05 in clang::StmtVisitorBase<clang::make_const_ptr,
(anonymous namespace)::IntExprEvaluator, bool>::Visit ()
#56 0x0000000001343a6c in Evaluate ()
#57 0x00000000013477f9 in EvaluateStmt ()
#58 0x00000000013477a7 in EvaluateStmt ()
---Type <return> to continue, or q <return> to quit---
... this goes on and 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  Wed Dec 14 15:37:57 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 14 Dec 2011 21:37:57 +0000
Subject: [LLVMbugs] [Bug 11575] New: The unwind destination does not have a
 landingpad instruction! Block containing LandingPadInst must be jumped to
 only by the unwind edge of an invoke.
Message-ID: <bug-11575-206@http.llvm.org/bugs/>

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

             Bug #: 11575
           Summary: The unwind destination does not have a landingpad
                    instruction! Block containing LandingPadInst must be
                    jumped to only by the unwind edge of an invoke.
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: FreeBSD
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: LLVM Codegen
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: rdivacky at freebsd.org
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


witten delta# clang -O2 ParserTest.cpp
The unwind destination does not have a landingpad instruction!
  invoke void @_ZN6PoDoFo9PdfParser9ParseFileEPKclb(%"class.PoDoFo::PdfParser"*
%parser, i8* null, i32 0, i1 zeroext true)
          to label %try.cont19 unwind label %lpad.preheader
Block containing LandingPadInst must be jumped to only by the unwind edge of an
invoke.
  %1 = landingpad { i8*, i32 } personality i8* bitcast (i32 (...)*
@__gxx_personality_v0 to i8*)
          catch i8* bitcast ({ i8*, i8*, i8* }* @_ZTIN6PoDoFo8PdfErrorE to i8*)
Instruction does not dominate all uses!
  %1 = landingpad { i8*, i32 } personality i8* bitcast (i32 (...)*
@__gxx_personality_v0 to i8*)
          catch i8* bitcast ({ i8*, i8*, i8* }* @_ZTIN6PoDoFo8PdfErrorE to i8*)
  %2 = extractvalue { i8*, i32 } %1, 0
Instruction does not dominate all uses!
  %1 = landingpad { i8*, i32 } personality i8* bitcast (i32 (...)*
@__gxx_personality_v0 to i8*)
          catch i8* bitcast ({ i8*, i8*, i8* }* @_ZTIN6PoDoFo8PdfErrorE to i8*)
  %3 = extractvalue { i8*, i32 } %1, 1
Instruction does not dominate all uses!
  %3 = extractvalue { i8*, i32 } %1, 1
  %matches = icmp eq i32 %3, %0
Instruction does not dominate all uses!
  %matches = icmp eq i32 %3, %0
  br i1 %matches, label %catch, label %catch.dispatch12
Broken module found, compilation aborted!
Stack dump:
0.    Program arguments: /usr/local/bin/clang -cc1 -triple
i386-unknown-freebsd10.0 -emit-obj -disable-free -main-file-name ParserTest.cpp
-mrelocation-model static -mdisable-fp-elim -masm-verbose -mconstructor-aliases
-target-cpu pentium4 -target-linker-version 2.17.50 -momit-leaf-frame-pointer
-resource-dir /usr/local/bin/../lib/clang/3.1 -fmodule-cache-path
/var/tmp/clang-module-cache -O2 -fdeprecated-macro -fdebug-compilation-dir
/tmp/delta -ferror-limit 19 -fmessage-length 152 -mstackrealign -fgnu-runtime
-fobjc-runtime-has-arc -fobjc-runtime-has-weak -fobjc-fragile-abi
-fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o
/tmp/ParserTest-07dJO6.o -x c++ ParserTest.cpp 
1.    <eof> parser at end of file
2.    Code generation
3.    Running pass 'Function Pass Manager' on module 'ParserTest.cpp'.
4.    Running pass 'Module Verifier' on function '@main'
clang: error: unable to execute command: Abort trap: 6 (core dumped)
clang: error: clang frontend command failed due to signal (use -v to see
invocation)
clang: note: diagnostic msg: Please submit a bug report to
http://llvm.org/bugs/ and include command line arguments and all diagnostic
information.
clang: note: diagnostic msg: Preprocessed source(s) and associated run
script(s) are located at:
clang: note: diagnostic msg: /tmp/ParserTest-zM3GQM.ii
clang: note: diagnostic msg: /tmp/ParserTest-zM3GQM.sh

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 14 15:49:29 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 14 Dec 2011 21:49:29 +0000
Subject: [LLVMbugs] [Bug 11576] New: Use in block doesn't count as use to
 prevent dead store warning
Message-ID: <bug-11576-206@http.llvm.org/bugs/>

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

             Bug #: 11576
           Summary: Use in block doesn't count as use to prevent dead
                    store warning
           Product: clang
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: Static Analyzer
        AssignedTo: kremenek at apple.com
        ReportedBy: tjw at me.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 7734
  --> http://llvm.org/bugs/attachment.cgi?id=7734
test case

Allocating an object and then letting it be captured and used by a block
doesn't count as a use for dead store calculations, resulting in a spurious
warning.


clang version 3.1 (trunk 146587)


/Users/bungi/Source/LLVM/llvm/Release+Asserts/bin/clang --analyze
block-capture-vs-dead-store.m

block-capture-vs-dead-store.m:10:12: warning: Value stored to 'object' during
its initialization is never read
        NSObject *object = [[[NSObject alloc] init] autorelease];
                  ^        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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 Dec 14 16:15:01 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 14 Dec 2011 22:15:01 +0000
Subject: [LLVMbugs] [Bug 11577] New: "[self alloc]" in a class method not
 inferred to return an instance of that class
Message-ID: <bug-11577-206@http.llvm.org/bugs/>

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

             Bug #: 11577
           Summary: "[self alloc]" in a class method not inferred to
                    return an instance of that class
           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 me.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 7735
  --> http://llvm.org/bugs/attachment.cgi?id=7735
test case

The result of +alloc should be inferred to be an instance of the receiving
"self" class here, but is apparently just being typed as "id". This cause clang
to think the -initWithContentsOfFile: and -initWithContentsOfURL: are possibly
the deprecated methods in Foundation.


/Users/bungi/Source/LLVM/llvm/Release+Asserts/bin/clang -c
incorrect-type-inferrence-vs-deprecation.m

incorrect-type-inferrence-vs-deprecation.m:32:14: warning:
'initWithContentsOfFile:' is deprecated [-Wdeprecated-declarations]
    return [[[self alloc] initWithContentsOfFile:path] autorelease];
             ^
incorrect-type-inferrence-vs-deprecation.m:37:14: warning:
'initWithContentsOfURL:' is deprecated [-Wdeprecated-declarations]
    return [[[self alloc] initWithContentsOfURL:url] autorelease];
             ^
2 warnings 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 Dec 14 17:05:28 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 14 Dec 2011 23:05:28 +0000
Subject: [LLVMbugs] [Bug 11573] segfault on expr/expr.const/p2-0x.cpp
In-Reply-To: <bug-11573-206@http.llvm.org/bugs/>
References: <bug-11573-206@http.llvm.org/bugs/>
Message-ID: <bug-11573-206-aJri07zSqM@http.llvm.org/bugs/>

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

Pawel Worach <pawel.worach at gmail.com> changed:

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

--- Comment #4 from Pawel Worach <pawel.worach at gmail.com> 2011-12-14 17:05:28 CST ---
Yep, confirmed fixed by r146479.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 14 18:36:30 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 15 Dec 2011 00:36:30 +0000
Subject: [LLVMbugs] [Bug 11578] New: clang-sa doesn't track retains across
 block boundaries
Message-ID: <bug-11578-206@http.llvm.org/bugs/>

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

             Bug #: 11578
           Summary: clang-sa doesn't track retains across block boundaries
           Product: clang
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Static Analyzer
        AssignedTo: kremenek at apple.com
        ReportedBy: tjw at me.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 7738
  --> http://llvm.org/bugs/attachment.cgi?id=7738
test case

The attached sample is narrowed down from a real method we have. We have a
__block variable (which is non-retaining when captured by blocks, so we have to
retain when assigning into it under MRR). This variable gets filled out in one
synchronously executing block (NSFileCoordinator), double-checked on the
mainline code, and then used and autoreleased in a delayed block.

I'm not sure if it is possible for clang-sa to properly track this w/o knowing
that NSOperationQueue takes blocks that will get executed exactly once
(assuming no deadlock, cancellation, etc).

This code used to not warn in previously versions, but does now in "clang
version 3.1 (trunk 146587)". This may actually be a fix and the correct
behavior, but it is a bit annoying since it seems like it should be possible.

One alternate approach would be to declare another local:

  NSDate *date = [modificationDate autorelease];

that the second block could capture (and *would* retain and release as needed
by the lifetime of the second block). This extra variable is kind of strange
(and hard to name) but maybe this is the right way to color w/in the lines
here.

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

From bugzilla-daemon at llvm.org  Wed Dec 14 18:51:20 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 15 Dec 2011 00:51:20 +0000
Subject: [LLVMbugs] [Bug 11575] The unwind destination does not have a
 landingpad instruction! Block containing LandingPadInst must be jumped to
 only by the unwind edge of an invoke.
In-Reply-To: <bug-11575-206@http.llvm.org/bugs/>
References: <bug-11575-206@http.llvm.org/bugs/>
Message-ID: <bug-11575-206-tGPWWsdbQr@http.llvm.org/bugs/>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

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

--- Comment #5 from Eli Friedman <sharparrow1 at yahoo.com> 2011-12-14 18:51:20 CST ---
After working with the patch a bit more, I'm more confident that it is correct.
 r146621.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 14 19:05:51 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 15 Dec 2011 01:05:51 +0000
Subject: [LLVMbugs] [Bug 11580] New: float4->float3 conversion uses
	inefficient code
Message-ID: <bug-11580-206@http.llvm.org/bugs/>

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

             Bug #: 11580
           Summary: float4->float3 conversion uses inefficient code
           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: schnetter at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 14 20:07:29 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 15 Dec 2011 02:07:29 +0000
Subject: [LLVMbugs] [Bug 11570] boost karma causes clang optimizer crash
In-Reply-To: <bug-11570-206@http.llvm.org/bugs/>
References: <bug-11570-206@http.llvm.org/bugs/>
Message-ID: <bug-11570-206-8ShBg8kzUY@http.llvm.org/bugs/>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |sharparrow1 at yahoo.com
         Resolution|                            |FIXED

--- Comment #4 from Eli Friedman <sharparrow1 at yahoo.com> 2011-12-14 20:07:29 CST ---
r146630.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 14 20:43:04 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 15 Dec 2011 02:43:04 +0000
Subject: [LLVMbugs] [Bug 11572] Right shift of a bit field strips the
 "unsigned" type property from a bitfield
In-Reply-To: <bug-11572-206@http.llvm.org/bugs/>
References: <bug-11572-206@http.llvm.org/bugs/>
Message-ID: <bug-11572-206-boyLKi2H3u@http.llvm.org/bugs/>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|INVALID                     |FIXED

--- Comment #6 from Eli Friedman <sharparrow1 at yahoo.com> 2011-12-14 20:43:04 CST ---
Looking a bit more, I realized that we have existing handling that was supposed
to be suppressing the warning in this case, but wasn't working correctly. 
Fixed in r146634.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 15 02:49:58 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 15 Dec 2011 08:49:58 +0000
Subject: [LLVMbugs] [Bug 11581] New: Segmentation fault in clang-cpp when
 arguments are ignored
Message-ID: <bug-11581-206@http.llvm.org/bugs/>

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

             Bug #: 11581
           Summary: Segmentation fault in clang-cpp when arguments are
                    ignored
           Product: clang
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Driver
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: fjoe at samodelkin.net
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 7739
  --> http://llvm.org/bugs/attachment.cgi?id=7739
Proposed fix

clang-cpp fails to preprocess empty source file when it ignores command line
arguments:

<pre>
[Dec 15 14:24:13] fjoe at husky:~/fbsd/clang$clang-cpp foo.c -lpthread
Stack dump:
0.    Program arguments: clang-cpp foo.c -lpthread 
1.    Compilation construction
2.    Building compilation actions
Segmentation fault (core dumped)
</pre>

Stack trace is:
<pre>
[Dec 15 14:24:26] fjoe at husky:~/fbsd/clang$gdb -c clang-cpp.core clang
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd"...

warning: core file may not match specified executable file.
Core was generated by `clang-cpp'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/lib/libstdc++.so.6...done.
Loaded symbols for /usr/lib/libstdc++.so.6
Reading symbols from /lib/libm.so.5...done.
Loaded symbols for /lib/libm.so.5
Reading symbols from /lib/libgcc_s.so.1...done.
Loaded symbols for /lib/libgcc_s.so.1
Reading symbols from /lib/libc.so.7...done.
Loaded symbols for /lib/libc.so.7
Reading symbols from /libexec/ld-elf.so.1...done.
Loaded symbols for /libexec/ld-elf.so.1
#0  0x000000000048679c in clang::driver::Arg::getOption (this=0x0) at Arg.h:64
64        const Option &getOption() const { return *Opt; }
(gdb) bt
#0  0x000000000048679c in clang::driver::Arg::getOption (this=0x0) at Arg.h:64
#1  0x000000000048ee0f in clang::driver::Driver::BuildActions
(this=0x7fffffffd120, TC=@0x80386e100, 
    Args=@0x803862300, Inputs=@0x7fffffffc480, Actions=@0x803872320)
    at
/usr/fbsd/head/lib/clang/libclangdriver/../../../contrib/llvm/tools/clang/lib/Driver/Driver.cpp:1025
#2  0x0000000000492d09 in clang::driver::Driver::BuildCompilation
(this=0x7fffffffd120, ArgList=
      {Data = 0x7fffffffc920, Length = 3})
    at
/usr/fbsd/head/lib/clang/libclangdriver/../../../contrib/llvm/tools/clang/lib/Driver/Driver.cpp:351
#3  0x0000000000412718 in main (argc_=3, argv_=0x7fffffffd950)
    at
/usr/fbsd/head/usr.bin/clang/clang/../../../contrib/llvm/tools/clang/tools/driver/driver.cpp:452
(gdb) frame 1
#1  0x000000000048ee0f in clang::driver::Driver::BuildActions
(this=0x7fffffffd120, TC=@0x80386e100, 
    Args=@0x803862300, Inputs=@0x7fffffffc480, Actions=@0x803872320)
    at
/usr/fbsd/head/lib/clang/libclangdriver/../../../contrib/llvm/tools/clang/lib/Driver/Driver.cpp:1025
warning: Source file is more recent than executable.

1025              << FinalPhaseArg->getOption().getName();
(gdb) print FinalPhaseArg
$1 = (class clang::driver::Arg *) 0x0
(gdb)
</pre>

Patch is attached.

With the patch the output is:
<pre>
[Dec 15 15:51:43] fjoe at husky:~/fbsd/clang$clang-cpp foo.c -lpthread
clang-cpp: warning: -lpthread: 'linker' input unused
# 1 "foo.c"
# 1 "foo.c" 1
# 1 "<built-in>" 1
# 1 "<built-in>" 3
# 130 "<built-in>" 3
# 1 "<command line>" 1
# 1 "<built-in>" 2
# 1 "foo.c" 2

[Dec 15 15:51:51] fjoe at husky:~/fbsd/clang$
</pre>

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 15 04:29:28 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 15 Dec 2011 10:29:28 +0000
Subject: [LLVMbugs] [Bug 11582] New: Random segfaults when using clang (both
	C and C++)
Message-ID: <bug-11582-206@http.llvm.org/bugs/>

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

             Bug #: 11582
           Summary: Random segfaults when using clang (both C and C++)
           Product: clang
           Version: 3.0
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: witold.krecicki at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 7740
  --> http://llvm.org/bugs/attachment.cgi?id=7740
Stack trace

I'm trying to build trunk llvm using llvm/clang 3.0 relase (bootstraped
manually using clang). On random occasions a segmentation fault occurs (really
random, on 10 runs around 5 will succeed). Command line, stack trace and .i
file 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  Thu Dec 15 06:10:11 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 15 Dec 2011 12:10:11 +0000
Subject: [LLVMbugs] [Bug 11583] New: Macro Redefinition in MSVC
	compatibility mode
Message-ID: <bug-11583-206@http.llvm.org/bugs/>

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

             Bug #: 11583
           Summary: Macro Redefinition in MSVC compatibility mode
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: eremeev at viva64.com
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified


In code containing function-like macro overloading, for example:

#define RETERROR(x) return x
#define RETERROR(x,y) return x + 1    

int test()
{
    RETERROR(2);
}

Visual C++ compiler is able to processes this code, generating the C4003
warning (the missing argument being replaced by an empty string), while clang
exits with an error "too few arguments provided to function-like macro
invocation", being unable to process it and potentially making some Visual C++
projects uncompilable.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 15 07:53:12 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 15 Dec 2011 13:53:12 +0000
Subject: [LLVMbugs] [Bug 11584] New: Segmentation fault in
 clang::Sema::ActOnFields() on ObjC code
Message-ID: <bug-11584-206@http.llvm.org/bugs/>

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

             Bug #: 11584
           Summary: Segmentation fault in clang::Sema::ActOnFields() on
                    ObjC code
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: MacOS X
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: glider at google.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


=====================================
$ cat test.mm
       @class NSString;
  typedef struct _NSZone NSZone;
   extern NSZone *NSDefaultMallocZone(void);
 extern NSZone *NSCreateZone(NSUInteger startSize, NSUInteger granularity, BOOL
canFree);
 extern void NSRecycleZone(NSZone *zone);
  @end  @protocol NSCoding  - (void)encodeWithCoder:(NSCoder *)aCoder;
 - (id)initWithCoder:(NSCoder *)aDecoder;
  @end    @interface NSObject <NSObject> {
=====================================
(note this is a malformed code)

$ clang++ -c test.mm -o test64.o -ObjC

test.mm:4:30: error: unknown type name 'NSUInteger'
 extern NSZone *NSCreateZone(NSUInteger startSize, NSUInteger granularity, BOOL
canFree);
                             ^
test.mm:4:52: error: unknown type name 'NSUInteger'
 extern NSZone *NSCreateZone(NSUInteger startSize, NSUInteger granularity, BOOL
canFree);
                                                   ^
test.mm:4:76: error: unknown type name 'BOOL'
 extern NSZone *NSCreateZone(NSUInteger startSize, NSUInteger granularity, BOOL
canFree);
                                                                           ^
test.mm:6:3: error: '@end' must appear in an Objective-C context
  @end  @protocol NSCoding  - (void)encodeWithCoder:(NSCoder *)aCoder;
  ^
test.mm:6:54: error: expected a type
  @end  @protocol NSCoding  - (void)encodeWithCoder:(NSCoder *)aCoder;
                                                     ^
test.mm:7:23: error: expected a type
 - (id)initWithCoder:(NSCoder *)aDecoder;
                      ^
test.mm:8:32: error: cannot find protocol declaration for 'NSObject'
  @end    @interface NSObject <NSObject> {
                               ^
test.mm:8:43: error: expected '}'
  @end    @interface NSObject <NSObject> {
                                          ^
test.mm:8:42: note: to match this '{'
  @end    @interface NSObject <NSObject> {
                                         ^
0  clang             0x0000000101531282 PrintStackTrace(void*) + 34
1  clang             0x00000001015317d9 SignalHandler(int) + 745
2  libSystem.B.dylib 0x00007fff83fa31ba _sigtramp + 26
3  libSystem.B.dylib 0x00007fff5fbfba00 _sigtramp + 3687155808
4  clang             0x00000001003979b8 clang::Sema::ActOnFields(clang::Scope*,
clang::SourceLocation, clang::Decl*, llvm::ArrayRef<clang::Decl*>,
clang::SourceLocation, clang::SourceLocation, clang::AttributeList*) + 6388
5  clang             0x00000001002e2804
clang::Parser::ParseObjCClassInstanceVariables(clang::Decl*,
clang::tok::ObjCKeywordKind, clang::SourceLocation) + 1546
6  clang             0x00000001002e8e9d
clang::Parser::ParseObjCAtInterfaceDeclaration(clang::SourceLocation,
clang::ParsedAttributes&) + 1793
7  clang             0x00000001002df340 clang::Parser::ParseObjCAtDirectives()
+ 288
8  clang             0x0000000100300273
clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&,
clang::Parser::ParsingDeclSpec*) + 773
9  clang             0x000000010030113e
clang::Parser::ParseTopLevelDecl(clang::OpaquePtr<clang::DeclGroupRef>&) + 262
10 clang             0x00000001002ac035 clang::ParseAST(clang::Sema&, bool) +
325
11 clang             0x000000010027909c clang::CodeGenAction::ExecuteAction() +
924
12 clang             0x0000000100068716
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 962
13 clang             0x0000000100050982
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 2162
14 clang             0x000000010004aa7b cc1_main(char const**, char const**,
char const*, void*) + 2907
15 clang             0x000000010004d920 main + 640
16 clang             0x0000000100049f0c start + 52
Stack dump:
0.    Program arguments:
/Users/glider/src/asan/asan-llvm-trunk/llvm/build/Release+Asserts/bin/clang
-cc1 -triple x86_64-apple-macosx10.6.8 -emit-obj -mrelax-all -disable-free
-main-file-name test.mm -pic-level 1 -mdisable-fp-elim -masm-verbose
-munwind-tables -target-cpu core2 -target-linker-version 97.17 -coverage-file
test64.o -resource-dir
/Users/glider/src/asan/asan-llvm-trunk/llvm/build/Release+Asserts/bin/../lib/clang/3.1
-fmodule-cache-path /var/tmp/clang-module-cache -fdebug-compilation-dir
/Users/glider/src/asan/asan-llvm-trunk/llvm/projects/compiler-rt/lib/asan
-ferror-limit 19 -fmessage-length 222 -stack-protector 1 -mstackrealign
-fblocks -fobjc-dispatch-method=mixed -fobjc-exceptions -fexceptions
-fdiagnostics-show-option -fcolor-diagnostics -o test64.o -x objective-c
test.mm 
1.    <eof> parser at end of file
clang: error: unable to execute command: Segmentation fault
clang: error: clang frontend command failed due to signal (use -v to see
invocation)
clang: note: diagnostic msg: Please submit a bug report to
http://llvm.org/bugs/ and include command line arguments and all diagnostic
information.
clang: note: diagnostic msg: Preprocessed source(s) and associated run
script(s) are located at:
clang: note: diagnostic msg: /tmp/test-c7qt2o.mi
clang: note: diagnostic msg: /tmp/test-c7qt2o.sh

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 15 08:13:24 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 15 Dec 2011 14:13:24 +0000
Subject: [LLVMbugs] [Bug 11585] New: trunk doesn't build on linux
Message-ID: <bug-11585-206@http.llvm.org/bugs/>

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

             Bug #: 11585
           Summary: trunk doesn't build on linux
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: gryzman at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


In file included from /home/gj/llvm/llvm/lib/Target/X86/X86FastISel.cpp:76:
/home/gj/llvm/llvm/lib/Target/X86/X86GenFastISel.inc: In member function
?virtual unsigned int<unnamed>::X86FastISel::FastEmit_rr(llvm::MVT, llvm::MVT,
unsigned int, unsigned int, bool, unsigned int, bool)?:
/home/gj/llvm/llvm/lib/Target/X86/X86GenFastISel.inc:3469: error: ?PSIGNB? is
not a member of ?llvm::X86ISD?
/home/gj/llvm/llvm/lib/Target/X86/X86GenFastISel.inc:3470: error: ?PSIGND? is
not a member of ?llvm::X86ISD?
/home/gj/llvm/llvm/lib/Target/X86/X86GenFastISel.inc:3471: error: ?PSIGNW? is
not a member of ?llvm::X86ISD?
/home/gj/llvm/llvm/lib/Target/X86/X86GenFastISel.inc:3473: error: ?PUNPCKHBW?
is not a member of ?llvm::X86ISD?
/home/gj/llvm/llvm/lib/Target/X86/X86GenFastISel.inc:3474: error: ?PUNPCKHDQ?
is not a member of ?llvm::X86ISD?
/home/gj/llvm/llvm/lib/Target/X86/X86GenFastISel.inc:3475: error: ?PUNPCKHQDQ?
is not a member of ?llvm::X86ISD?
/home/gj/llvm/llvm/lib/Target/X86/X86GenFastISel.inc:3476: error: ?PUNPCKHWD?
is not a member of ?llvm::X86ISD?
/home/gj/llvm/llvm/lib/Target/X86/X86GenFastISel.inc:3477: error: ?PUNPCKLBW?
is not a member of ?llvm::X86ISD?
/home/gj/llvm/llvm/lib/Target/X86/X86GenFastISel.inc:3478: error: ?PUNPCKLDQ?
is not a member of ?llvm::X86ISD?
/home/gj/llvm/llvm/lib/Target/X86/X86GenFastISel.inc:3479: error: ?PUNPCKLQDQ?
is not a member of ?llvm::X86ISD?
/home/gj/llvm/llvm/lib/Target/X86/X86GenFastISel.inc:3480: error: ?PUNPCKLWD?
is not a member of ?llvm::X86ISD?
/home/gj/llvm/llvm/lib/Target/X86/X86GenFastISel.inc:3483: error: ?UNPCKHPD? is
not a member of ?llvm::X86ISD?
/home/gj/llvm/llvm/lib/Target/X86/X86GenFastISel.inc:3484: error: ?UNPCKHPS? is
not a member of ?llvm::X86ISD?
/home/gj/llvm/llvm/lib/Target/X86/X86GenFastISel.inc:3485: error: ?UNPCKLPD? is
not a member of ?llvm::X86ISD?
/home/gj/llvm/llvm/lib/Target/X86/X86GenFastISel.inc:3486: error: ?UNPCKLPS? is
not a member of ?llvm::X86ISD?
/home/gj/llvm/llvm/lib/Target/X86/X86GenFastISel.inc:3487: error: ?VUNPCKHPDY?
is not a member of ?llvm::X86ISD?
/home/gj/llvm/llvm/lib/Target/X86/X86GenFastISel.inc:3488: error: ?VUNPCKHPSY?
is not a member of ?llvm::X86ISD?
/home/gj/llvm/llvm/lib/Target/X86/X86GenFastISel.inc:3489: error: ?VUNPCKLPDY?
is not a member of ?llvm::X86ISD?
/home/gj/llvm/llvm/lib/Target/X86/X86GenFastISel.inc:3490: error: ?VUNPCKLPSY?
is not a member of ?llvm::X86ISD?
In file included from /home/gj/llvm/llvm/lib/Target/X86/X86FastISel.cpp:76:
/home/gj/llvm/llvm/lib/Target/X86/X86GenFastISel.inc: In member function
?virtual unsigned int<unnamed>::X86FastISel::FastEmit_rri(llvm::MVT, llvm::MVT,
unsigned int, unsigned int, bool, unsigned int, bool, uint64_t)?:
/home/gj/llvm/llvm/lib/Target/X86/X86GenFastISel.inc:3843: error: ?VPERM2F128?
is not a member of ?llvm::X86ISD?
/home/gj/llvm/llvm/lib/Target/X86/X86GenFastISel.inc: In member function
?virtual unsigned int<unnamed>::X86FastISel::FastEmit_ri(llvm::MVT, llvm::MVT,
unsigned int, unsigned int, bool, uint64_t)?:
/home/gj/llvm/llvm/lib/Target/X86/X86GenFastISel.inc:4465: error: ?VPERMILPDY?
is not a member of ?llvm::X86ISD?
/home/gj/llvm/llvm/lib/Target/X86/X86GenFastISel.inc:4466: error: ?VPERMILPSY?
is not a member of ?llvm::X86ISD?
make[3]: ***
[/home/gj/llvm/llvm/build/lib/Target/X86/Release+Asserts/X86FastISel.o] Error 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  Thu Dec 15 09:37:17 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 15 Dec 2011 15:37:17 +0000
Subject: [LLVMbugs] [Bug 10294] Release tarballs are signed with a key that
 is nowhere to be found
In-Reply-To: <bug-10294-206@http.llvm.org/bugs/>
References: <bug-10294-206@http.llvm.org/bugs/>
Message-ID: <bug-10294-206-1iTKokfaP0@http.llvm.org/bugs/>

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

Adam Sampson <ats-llvmbugs at offog.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
                 CC|                            |ats-llvmbugs at offog.org
         Resolution|FIXED                       |

--- Comment #2 from Adam Sampson <ats-llvmbugs at offog.org> 2011-12-15 09:37:17 CST ---
Reopening because this has been broken with the 3.0 release -- the 3.0 tarballs
are again signed with key E95C63DC, which isn't on the keyservers.

It would be a good idea to check that the signatures can be verified starting
from an empty keyring as part of the release process...

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 15 12:42:23 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 15 Dec 2011 18:42:23 +0000
Subject: [LLVMbugs] [Bug 11586] New: [AVX] incorrect code generated with
 blending (regression)
Message-ID: <bug-11586-206@http.llvm.org/bugs/>

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

             Bug #: 11586
           Summary: [AVX] incorrect code generated with blending
                    (regression)
           Product: new-bugs
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: matt at pharr.org
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 7743
  --> http://llvm.org/bugs/attachment.cgi?id=7743
test case

The attached short program loads a value from memory, does two calls to the AVX
blendv.ps intrinsic to compute what turns out to be the vector value
<0,2,0,4,0,6,0,8>, and stores the result back to the original location.  With
top of tree, if generates a vector of 7 0s and then a garbage value:

% llc -mattr=+avx bug.ll -o bug.s && clang bug.cpp bug.s && ./a.out
0.000000
0.000000
0.000000
0.000000
0.000000
0.000000
0.000000
-256541003186488763470434762634106503168.000000
%

git bisect reports that this is the commit that introduced this bug:

Author: Craig Topper <craig.topper at gmail.com>
Date:   Wed Dec 7 08:30:53 2011 +0000

    Fix a bunch of SSE/AVX patterns to use proper memop types. In particular,
not using integer loads other than v2i64/v4i64 since the others are all
promoted.

    git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk at 146031
91177308-0d34-0410-b5e6-96231b3b80d8

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 15 13:33:52 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 15 Dec 2011 19:33:52 +0000
Subject: [LLVMbugs] [Bug 11587] New: clang-trunk segfaults when building
 make_aisleriot_freecell_board.c
Message-ID: <bug-11587-206@http.llvm.org/bugs/>

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

             Bug #: 11587
           Summary: clang-trunk segfaults when building
                    make_aisleriot_freecell_board.c
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: shlomif at shlomifish.org
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Hi all. Thanks for your work on LLVM and clang. 

When I try to build Freecell Solver ( http://fc-solve.shlomifish.org/ ) using
it, I'm getting a segfault on one of its board generation programs:

shlomif[fcs]:$trunk/fc-solve/source/board_gen$
/home/shlomif/apps/llvm/bin/clang-3.1 -cc1 -triple x86_64-unknown-linux-gnu
-emit-obj -disable-free -disable-llvm-verifier -main-file-name
make_aisleriot_freecell_board.c -mrelocation-model static -masm-verbose
-mconstructor-aliases -munwind-tables -target-cpu x86-64
-momit-leaf-frame-pointer -coverage-file
CMakeFiles/make-aisleriot-freecell-board.dir/make_aisleriot_freecell_board.c.o
-resource-dir /home/shlomif/apps/llvm/bin/../lib/clang/3.1 -D NDEBUG
-fmodule-cache-path /home/shlomif/tmp/clang-module-cache -internal-isystem
/usr/local/include -internal-isystem
/home/shlomif/apps/llvm/bin/../lib/clang/3.1/include -internal-externc-isystem
/include -internal-externc-isystem /usr/include -O3 -fdebug-compilation-dir
/home/shlomif/progs/freecell/trunk/fc-solve/source/board_gen -ferror-limit 19
-fmessage-length 80 -mstackrealign -fgnu-runtime -fobjc-runtime-has-arc
-fobjc-runtime-has-weak -fobjc-fragile-abi -fdiagnostics-show-option
-fcolor-diagnostics  -x c make_aisleriot_freecell_board.c
Stack dump:
0.      Program arguments: /home/shlomif/apps/llvm/bin/clang-3.1 -cc1 -triple
x86_64-unknown-linux-gnu -emit-obj -disable-free -disable-llvm-verifier
-main-file-name make_aisleriot_freecell_board.c -mrelocation-model static
-masm-verbose -mconstructor-aliases -munwind-tables -target-cpu x86-64
-momit-leaf-frame-pointer -coverage-file
CMakeFiles/make-aisleriot-freecell-board.dir/make_aisleriot_freecell_board.c.o
-resource-dir /home/shlomif/apps/llvm/bin/../lib/clang/3.1 -D NDEBUG
-fmodule-cache-path /home/shlomif/tmp/clang-module-cache -internal-isystem
/usr/local/include -internal-isystem
/home/shlomif/apps/llvm/bin/../lib/clang/3.1/include -internal-externc-isystem
/include -internal-externc-isystem /usr/include -O3 -fdebug-compilation-dir
/home/shlomif/progs/freecell/trunk/fc-solve/source/board_gen -ferror-limit 19
-fmessage-length 80 -mstackrealign -fgnu-runtime -fobjc-runtime-has-arc
-fobjc-runtime-has-weak -fobjc-fragile-abi -fdiagnostics-show-option
-fcolor-diagnostics -x c make_aisleriot_freecell_board.c 
1.      <eof> parser at end of file
2.      Code generation
3.      Running pass 'Function Pass Manager' on module
'make_aisleriot_freecell_board.c'.
4.      Running pass 'Machine Instruction LICM' on function '@main'
Segmentation fault
shlomif[fcs]:$trunk/fc-solve/source/board_gen$ 

I'll attach the offending file soon, and a reproducing script, and a patch I
applied to the clang svn trunk to get it to run properly on Mageia Linux.

Regards,

-- Shlomi Fish

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 15 13:58:28 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 15 Dec 2011 19:58:28 +0000
Subject: [LLVMbugs] [Bug 11589] New: Scoreboard not reporting
	dependency-induced hazards
Message-ID: <bug-11589-206@http.llvm.org/bugs/>

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

             Bug #: 11589
           Summary: Scoreboard not reporting dependency-induced hazards
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Common Code Generator Code
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: hfinkel at anl.gov
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 7748
  --> http://llvm.org/bugs/attachment.cgi?id=7748
Test case

The scoreboard hazard detector that I've added for the PPC 440 is not
detecting hazards as it should (which certainly could be my fault
somehow, but...). For example, it will produce a schedule that looks
like...

SU(28): 0x127969b0: f64,ch = LFD 0x12793aa0, 0x1277b4f0,
0x127965b0<Mem:LD8[%scevgep100](tbaa=!"double")> [ORD=41] [ID=28]
SU(46): 0x12796ab0: f64 = FADD 0x127969b0, 0x127968b0 [ORD=42] [ID=46]
SU(27): 0x12796cb0: ch = STFD 0x12796ab0, 0x12793aa0, 0x1277b3f0,
0x127969b0:1<Mem:ST8[%scevgep103](tbaa=!"double")> [ORD=46] [ID=27]
SU(26): 0x127970b0: f64,ch = LFD 0x127941a0, 0x1277b4f0,
0x12796cb0<Mem:LD8[%scevgep94](align=16)(tbaa=!"double")> [ORD=50]
[ID=26]
SU(47): 0x127972c0: f64 = FADD 0x127970b0, 0x127968b0 [ORD=51] [ID=47]
SU(25): 0x127974c0: ch = STFD 0x127972c0, 0x127941a0, 0x1277b3f0,
0x127970b0:1<Mem:ST8[%scevgep97](align=16)(tbaa=!"double")> [ORD=55]
[ID=25]

in other words, it produces a set of load, add, store triples,
non-interleaved, in order. The problem is that the result of the load is
not immediately available, and either is the result of the add. The
loads are covered by the itinerary:

  InstrItinData<LdStLFD     , [InstrStage<1, [IFTH1, IFTH2]>,
                               InstrStage<1, [PDCD1, PDCD2]>,
                               InstrStage<1, [DISS1, DISS2]>,
                               InstrStage<1, [LRACC]>,
                               InstrStage<1, [AGEN]>,
                               InstrStage<1, [CRD]>,
                               InstrStage<2, [LWB]>],
                              [9, 5, 5],
                              [NoBypass, GPR_Bypass, GPR_Bypass]>,

the add is covered by the itinerary:

  InstrItinData<FPGeneral   , [InstrStage<1, [IFTH1, IFTH2]>,
                               InstrStage<1, [PDCD1, PDCD2]>,
                               InstrStage<1, [DISS1, DISS2]>,
                               InstrStage<1, [FRACC]>,
                               InstrStage<1, [FEXE1]>,
                               InstrStage<1, [FEXE2]>,
                               InstrStage<1, [FEXE3]>,
                               InstrStage<1, [FEXE4]>,
                               InstrStage<1, [FEXE5]>,
                               InstrStage<1, [FEXE6]>,
                               InstrStage<1, [FWB]>],
                              [10, 4, 4],
                              [FPR_Bypass, FPR_Bypass, FPR_Bypass]>,

the store is covered by:

  InstrItinData<LdStUX      , [InstrStage<1, [IFTH1, IFTH2]>,
                               InstrStage<1, [PDCD1, PDCD2]>,
                               InstrStage<1, [DISS1, DISS2]>,
                               InstrStage<1, [LRACC]>,
                               InstrStage<1, [AGEN]>,
                               InstrStage<1, [CRD]>,
                               InstrStage<1, [LWB]>],
                              [8, 5, 5],
                              [NoBypass, GPR_Bypass, GPR_Bypass]>,


So, say that the load dispatches in cycle 1. According to the itinerary,
the result of the load is not available until cycle 9. The add
dispatches in the same cycle, or one cycle later. In the best case, it
dispatches one cycle later (in cycle 2). It expects to read its inputs 4
cycles later in cycle number 6. The input, however, will not be
available until cycle 9 yielding a 3 cycle stall. As far as I can tell
by looking at the debug output, no hazard was reported by the scoreboard
detector. Is this a bug or am I doing something wrong?

I've attached a small test case, run with llc -mcpu=440

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 15 14:34:19 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 15 Dec 2011 20:34:19 +0000
Subject: [LLVMbugs] [Bug 11590] New: template class destructor not called
Message-ID: <bug-11590-206@http.llvm.org/bugs/>

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

             Bug #: 11590
           Summary: template class destructor not called
           Product: clang
           Version: 3.0
          Platform: Macintosh
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: benoit at bittrap.com
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified


A destructor isn't called in the test case below (works with gcc 4.2.1 and
MSVC2010).

-----
#include <iostream>

using namespace std;

template<typename T> class Handle {
public:

    Handle() { cout << "Handle::Handle()" << endl; }

    Handle(const Handle& r) { cout << "Handle::Handle(Handle&)" << endl; }

    ~Handle() { cout << "Handle::~Handle()" << endl; }
};

class P {
public:
    Handle<int> h;

    Handle<int> getHandle() {
        return h;
    }

    template<class T> void 
    f(Handle<T>& h) {
        h = getHandle();
    }
};

int
main(int, char**) {
    P p;
    Handle<int> h;
    p.f(h);
}
----

MacBookPro:~/Devel/git/game$ clang++ -v
Apple clang version 3.0 (tags/Apple/clang-211.10.1) (based on LLVM 3.0svn)
Target: x86_64-apple-darwin11.2.0
Thread model: posix
MacBookPro:~/Devel/git/game$ ./a.out 
Handle::Handle()
Handle::Handle()
Handle::Handle(Handle&)
Handle::~Handle()
Handle::~Handle()

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 15 14:39:35 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 15 Dec 2011 20:39:35 +0000
Subject: [LLVMbugs] [Bug 11590] template class destructor not called
In-Reply-To: <bug-11590-206@http.llvm.org/bugs/>
References: <bug-11590-206@http.llvm.org/bugs/>
Message-ID: <bug-11590-206-WLz2vtTqtM@http.llvm.org/bugs/>

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

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-12-15 14:39:35 CST ---
Good find. This was fixed in Clang r146301.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 15 16:08:31 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 15 Dec 2011 22:08:31 +0000
Subject: [LLVMbugs] [Bug 11591] New: inline (and instcombine) changing debug
	info
Message-ID: <bug-11591-206@http.llvm.org/bugs/>

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

             Bug #: 11591
           Summary: inline (and instcombine) changing debug info
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Scalar Optimizations
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: nlewycky at google.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


This code:

extern "C" void helper(void*, const int);

  struct Base {
    void ReturnMemory(void* memory, const int size) {
      helper(memory, size);
    }
  };

  struct Derived : public Base {
    void Free(void* memory, int size) {
      ReturnMemory(memory, size);
    }
    virtual void SlowFree(void *memory, int size) {
      Free(memory, size);
    }
  };

  void f() {
    new Derived;
  }

has correct debug info when built at -O0. Now, the debug info I'm interested in
is *not* the CIE for the function -- that stays correct after -O2 (the
DW_AT_decl_line after the DW_TAG_subprogram as dumped by dwarfdump). What's
changing is the line number for the first instruction of the function.

$ opt x.bc -o y.bc && llc -filetype=obj y.bc -o y.o
$ echo 0 | addr2line -j .text._ZN7Derived8SlowFreeEPvi -f -e y.o
_ZN7Derived8SlowFreeEPvi
/home/nlewycky/x.cc:13
$ opt -instcombine x.bc -o y.bc && llc -filetype=obj y.bc -o y.o
$ echo 0 | addr2line -j .text._ZN7Derived8SlowFreeEPvi -f -e y.o
_ZN7Derived8SlowFreeEPvi
/home/nlewycky/x.cc:14
$ opt -inline -instcombine x.bc -o y.bc && llc -filetype=obj y.bc -o y.o
$ echo 0 | addr2line -j .text._ZN7Derived8SlowFreeEPvi -f -e y.o
_ZN4Base12ReturnMemoryEPvi
/home/nlewycky/x.cc:5

That's the line number it shows (line 5) when built with clang -O2. That should
stay at 13.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 15 17:00:12 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 15 Dec 2011 23:00:12 +0000
Subject: [LLVMbugs] [Bug 11592] New: llvm Codegen crashes when debugging and
 optimization enabled
Message-ID: <bug-11592-206@http.llvm.org/bugs/>

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

             Bug #: 11592
           Summary: llvm Codegen crashes when debugging and optimization
                    enabled
           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: jpbonn-keyword-llvmbug.a51747 at corniceresearch.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 7750
  --> http://llvm.org/bugs/attachment.cgi?id=7750
reduced test case for sparc

The attached files cause the following problem when compiling for Sparc: 

llc:
/home/jpbonn/Documents/clang/llvm/include/llvm/CodeGen/MachineFrameInfo.h:378:
int64_t llvm::MachineFrameInfo::getObjectOffset(int) const: Assertion
`unsigned(ObjectIdx+NumFixedObjects) < Objects.size() && "Invalid Object Idx!"'
failed.

The reduced test case is attached.

The attached .i file also seem to causes  problems for sparcv9, xcore, hexagon
and mblaze when compiled with clang. I'm not sure if they are all related.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 15 17:46:34 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 15 Dec 2011 23:46:34 +0000
Subject: [LLVMbugs] [Bug 11586] [AVX] incorrect code generated with blending
 (regression)
In-Reply-To: <bug-11586-206@http.llvm.org/bugs/>
References: <bug-11586-206@http.llvm.org/bugs/>
Message-ID: <bug-11586-206-CdidKHuEij@http.llvm.org/bugs/>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

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

--- Comment #5 from Eli Friedman <sharparrow1 at yahoo.com> 2011-12-15 17:46:34 CST ---
r146709.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 15 18:05:22 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 16 Dec 2011 00:05:22 +0000
Subject: [LLVMbugs] [Bug 11497] llvm-config no longer returns targets built
In-Reply-To: <bug-11497-206@http.llvm.org/bugs/>
References: <bug-11497-206@http.llvm.org/bugs/>
Message-ID: <bug-11497-206-yQwJe7R4aN@http.llvm.org/bugs/>

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

Daniel Dunbar <daniel at zuster.org> changed:

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

--- Comment #2 from Daniel Dunbar <daniel at zuster.org> 2011-12-15 18:05:22 CST ---
I swear I tested this, sorry!

Fixed here:
  http://llvm.org/viewvc/llvm-project?view=rev&revision=146711

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 15 18:54:15 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 16 Dec 2011 00:54:15 +0000
Subject: [LLVMbugs] [Bug 11593] New: DragonEgg makefile uses svnversion to
 set REVISION, causing build failure with release tarball
Message-ID: <bug-11593-206@http.llvm.org/bugs/>

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

             Bug #: 11593
           Summary: DragonEgg makefile uses svnversion to set REVISION,
                    causing build failure with release tarball
           Product: dragonegg
           Version: 2.7
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: New Bugs
        AssignedTo: baldrick at free.fr
        ReportedBy: eric at brouhaha.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


In the process of packaging DragonEgg for the Fedora Linux distribution, the
package reviewer encountered a build failure due to the Makefile's use of
svnversion to set the REVISION variable.  If svnversion is present, it outputs
the string "unversioned directory", which breaks things due to the space
character.

For now we've patched the makefile to change the way REVISION is set.  I'm not
sure what the correct solution in general is, but the Makefile in a release
tarball shouldn't be using svnversion on what obviously isn't a Subversion
working directory, or it should detect that condition and take an appropriate
action.

The problem description in the Fedora package review is at:
    https://bugzilla.redhat.com/show_bug.cgi?id=759712#c2

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 16 01:49:51 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 16 Dec 2011 07:49:51 +0000
Subject: [LLVMbugs] [Bug 11593] DragonEgg makefile uses svnversion to set
 REVISION, causing build failure with release tarball
In-Reply-To: <bug-11593-206@http.llvm.org/bugs/>
References: <bug-11593-206@http.llvm.org/bugs/>
Message-ID: <bug-11593-206-tknPsY7Zxz@http.llvm.org/bugs/>

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

Duncan Sands <baldrick at free.fr> changed:

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

--- Comment #2 from Duncan Sands <baldrick at free.fr> 2011-12-16 01:49:51 CST ---
I forgot to hard-code the revision as "3.0" (I've added it to my list of things
to do for a release, so hopefully it won't happen again).  Closing this bug
report since it is too late to do anything about 3.0 now.

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

From bugzilla-daemon at llvm.org  Fri Dec 16 02:15:49 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 16 Dec 2011 08:15:49 +0000
Subject: [LLVMbugs] [Bug 11584] Segmentation fault in
 clang::Sema::ActOnFields() on ObjC code
In-Reply-To: <bug-11584-206@http.llvm.org/bugs/>
References: <bug-11584-206@http.llvm.org/bugs/>
Message-ID: <bug-11584-206-kbFGXEqibu@http.llvm.org/bugs/>

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

Alexander Potapenko <glider at google.com> changed:

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

--- Comment #1 from Alexander Potapenko <glider at google.com> 2011-12-16 02:15:49 CST ---
This works for me as of r146725

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 16 03:06:04 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 16 Dec 2011 09:06:04 +0000
Subject: [LLVMbugs] [Bug 11047] test-suite execution broken
In-Reply-To: <bug-11047-206@http.llvm.org/bugs/>
References: <bug-11047-206@http.llvm.org/bugs/>
Message-ID: <bug-11047-206-biPQNRqExD@http.llvm.org/bugs/>

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

Eric Christopher <echristo at gmail.com> changed:

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

--- Comment #5 from Eric Christopher <echristo at gmail.com> 2011-12-16 03:06:04 CST ---
Think I fixed this in r146730. I tested using a soft-link for the test-suite
directory which had previously failed and it's now using the value of LLVM_SRC.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 16 03:08:47 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 16 Dec 2011 09:08:47 +0000
Subject: [LLVMbugs] [Bug 11594] New: Assertion `!E->isArrow() && "missing
 call to bound member function?"' failed
Message-ID: <bug-11594-206@http.llvm.org/bugs/>

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

             Bug #: 11594
           Summary: Assertion `!E->isArrow() && "missing call to bound
                    member function?"' failed
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: glider at google.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


I'm using Clang r146725
==============================
$ cat test.c
typedef char uint8_t;
      struct UConverter {
      int8_t preFromULength;
  };
  void _fromUnicodeWithCallback() {
      UConverter *cnv;
      uint16_t replay[19];
      p=replay-cnv->preFromULength;
==============================

$ clang -c test.c

test.c:3:7: error: unknown type name 'int8_t'; did you mean 'uint8_t'?
      int8_t preFromULength;
      ^~~~~~
      uint8_t
test.c:1:14: note: 'uint8_t' declared here
typedef char uint8_t;
             ^
test.c:6:7: error: must use 'struct' tag to refer to type 'UConverter'
      UConverter *cnv;
      ^
      struct 
test.c:7:7: error: unknown type name 'uint16_t'; did you mean 'uint8_t'?
      uint16_t replay[19];
      ^~~~~~~~
      uint8_t
test.c:1:14: note: 'uint8_t' declared here
typedef char uint8_t;
             ^
test.c:8:7: error: use of undeclared identifier 'p'
      p=replay-cnv->preFromULength;
      ^
clang:
/usr/local/google/asan/asan-llvm-trunk/llvm/tools/clang/lib/AST/ExprConstant.cpp:1888:
RetTy<unnamed>::ExprEvaluatorBase<Derived, RetTy>::VisitMemberExpr(const
clang::MemberExpr*) [with Derived = <unnamed>::IntExprEvaluator, RetTy = bool]:
Assertion `!E->isArrow() && "missing call to bound member function?"' failed.
0  clang           0x0000000001dc0f4f
1  clang           0x0000000001dc31c2
2  libpthread.so.0 0x00007fb4cb82a8f0
3  libc.so.6       0x00007fb4cab19a75 gsignal + 53
4  libc.so.6       0x00007fb4cab1d5c0 abort + 384
5  libc.so.6       0x00007fb4cab12941 __assert_fail + 241
6  clang           0x00000000010c34ae
7  clang           0x00000000010cbe24
8  clang           0x00000000010c2384
9  clang           0x00000000010cac39
10 clang           0x00000000010d1d68
11 clang           0x00000000010d2d49
clang::Expr::EvaluateAsRValue(clang::Expr::EvalResult&, clang::ASTContext
const&) const + 233
12 clang           0x00000000010d32b6 clang::Expr::EvaluateAsInt(llvm::APSInt&,
clang::ASTContext const&) const + 70
13 clang           0x0000000000a454e0 clang::Sema::CheckArrayAccess(clang::Expr
const*, clang::Expr const*, clang::ArraySubscriptExpr const*, bool) + 224
14 clang           0x0000000000b3933a
clang::Sema::CheckSubtractionOperands(clang::ActionResult<clang::Expr*, true>&,
clang::ActionResult<clang::Expr*, true>&, clang::SourceLocation,
clang::QualType*) + 762
15 clang           0x0000000000b58a13
clang::Sema::CreateBuiltinBinOp(clang::SourceLocation,
clang::BinaryOperatorKind, clang::Expr*, clang::Expr*) + 1827
16 clang           0x0000000000b59153 clang::Sema::BuildBinOp(clang::Scope*,
clang::SourceLocation, clang::BinaryOperatorKind, clang::Expr*, clang::Expr*) +
355
17 clang           0x0000000000b593b6 clang::Sema::ActOnBinOp(clang::Scope*,
clang::SourceLocation, clang::tok::TokenKind, clang::Expr*, clang::Expr*) + 278
18 clang           0x00000000009f28c4
clang::Parser::ParseRHSOfBinaryExpression(clang::ActionResult<clang::Expr*,
true>, clang::prec::Level) + 708
19 clang           0x00000000009f2a9c
clang::Parser::ParseRHSOfBinaryExpression(clang::ActionResult<clang::Expr*,
true>, clang::prec::Level) + 1180
20 clang           0x00000000009f33af
clang::Parser::ParseAssignmentExpression() + 47
21 clang           0x00000000009f4179 clang::Parser::ParseExpression() + 9
22 clang           0x00000000009b3cc3
clang::Parser::ParseExprStatement(clang::ParsedAttributes&) + 83
23 clang           0x00000000009b20bb
clang::Parser::ParseStatementOrDeclaration(clang::ASTOwningVector<clang::Stmt*,
32u>&, bool) + 2219
24 clang           0x00000000009af6df
clang::Parser::ParseCompoundStatementBody(bool) + 1791
25 clang           0x00000000009afce8
clang::Parser::ParseFunctionStatementBody(clang::Decl*,
clang::Parser::ParseScope&) + 168
26 clang           0x00000000009c514a
clang::Parser::ParseFunctionDefinition(clang::Parser::ParsingDeclarator&,
clang::Parser::ParsedTemplateInfo const&) + 2154
27 clang           0x00000000009d6578
clang::Parser::ParseDeclGroup(clang::Parser::ParsingDeclSpec&, unsigned int,
bool, clang::SourceLocation*, clang::Parser::ForRangeInit*) + 2504
28 clang           0x00000000009c253d
clang::Parser::ParseDeclarationOrFunctionDefinition(clang::Parser::ParsingDeclSpec&,
clang::AccessSpecifier) + 157
29 clang           0x00000000009c2a96
clang::Parser::ParseDeclarationOrFunctionDefinition(clang::ParsedAttributes&,
clang::AccessSpecifier) + 742
30 clang           0x00000000009c8510
clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&,
clang::Parser::ParsingDeclSpec*) + 2304
31 clang           0x00000000009c89b0
clang::Parser::ParseTopLevelDecl(clang::OpaquePtr<clang::DeclGroupRef>&) + 160
32 clang           0x000000000099faa5 clang::ParseAST(clang::Sema&, bool) + 293
33 clang           0x000000000084d644 clang::CodeGenAction::ExecuteAction() +
68
34 clang           0x00000000006f8115
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 373
35 clang           0x00000000006e0709
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1401
36 clang           0x00000000006d694c cc1_main(char const**, char const**, char
const*, void*) + 812
37 clang           0x00000000006df4d7 main + 7191
38 libc.so.6       0x00007fb4cab04c4d __libc_start_main + 253
39 clang           0x00000000006d4529
Stack dump:
0.    Program arguments:
/usr/local/google/chrome-asan/src/third_party/asan/asan_clang_Linux/bin/clang
-cc1 -triple x86_64-unknown-linux-gnu -emit-obj -mrelax-all -disable-free
-main-file-name test.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 -coverage-file test.o
-resource-dir
/usr/local/google/chrome-asan/src/third_party/asan/asan_clang_Linux/bin/../lib/clang/3.1
-fmodule-cache-path /var/tmp/clang-module-cache -internal-isystem
/usr/local/include -internal-isystem
/usr/local/google/chrome-asan/src/third_party/asan/asan_clang_Linux/bin/../lib/clang/3.1/include
-internal-externc-isystem /usr/include/x86_64-linux-gnu
-internal-externc-isystem /include -internal-externc-isystem /usr/include
-fdebug-compilation-dir /usr/local/google/chrome-asan/src -ferror-limit 19
-fmessage-length 249 -mstackrealign -fgnu-runtime -fobjc-runtime-has-arc
-fobjc-runtime-has-weak -fobjc-fragile-abi -fdiagnostics-show-option
-fcolor-diagnostics -o test.o -x c test.c 
1.    test.c:8:35: current parser token ';'
2.    test.c:5:35: parsing function body '_fromUnicodeWithCallback'
3.    test.c:5:35: in compound statement ('{}')
clang: error: unable to execute command: Aborted
clang: error: clang frontend command failed due to signal (use -v to see
invocation)
clang: note: diagnostic msg: Please submit a bug report to
http://llvm.org/bugs/ and include command line arguments and all diagnostic
information.
clang: note: diagnostic msg: Preprocessed source(s) and associated run
script(s) are located at:
clang: note: diagnostic msg: /tmp/test-PCTQJb.i
clang: note: diagnostic msg: /tmp/test-PCTQJb.sh

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 16 06:30:54 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 16 Dec 2011 12:30:54 +0000
Subject: [LLVMbugs] [Bug 11595] New: Assertion failed: (E->isRValue() &&
 E->getType()->isRecordType() && E->getType()->isLiteralType()),
 function EvaluateTemporary, file ExprConstant.cpp, line 2692.
Message-ID: <bug-11595-206@http.llvm.org/bugs/>

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

             Bug #: 11595
           Summary: Assertion failed: (E->isRValue() &&
                    E->getType()->isRecordType() &&
                    E->getType()->isLiteralType()), function
                    EvaluateTemporary, file ExprConstant.cpp, line 2692.
           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: tm at ayena.de
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 7752
  --> http://llvm.org/bugs/attachment.cgi?id=7752
Reduced testcase.

In recent (r146734) LLVM/Clang clang crashes when building a project I'm
working on. It builds without issue with G++. I've reduced the relevant code
with delta. The reduced testcode is attached.

This is the trace clang outputs:


Assertion failed: (E->isRValue() && E->getType()->isRecordType() &&
E->getType()->isLiteralType()), function EvaluateTemporary, file
ExprConstant.cpp, line 2692.
0  clang             0x00000001015e90d2
llvm::SmallVectorImpl<llvm_regmatch_t>::resize(unsigned int) + 2050
1  clang             0x00000001015e9709
llvm::SmallVectorImpl<llvm_regmatch_t>::resize(unsigned int) + 3641
2  libSystem.B.dylib 0x00007fff874901ba _sigtramp + 26
3  libSystem.B.dylib 0x0000000102811600 _sigtramp + 2067272800
4  clang             0x00000001015e9306
llvm::SmallVectorImpl<llvm_regmatch_t>::resize(unsigned int) + 2614
5  clang             0x00000001015e92c8
llvm::SmallVectorImpl<llvm_regmatch_t>::resize(unsigned int) + 2552
6  clang             0x0000000100923d96
clang::CastExpr::CastExpr(clang::Stmt::StmtClass, clang::QualType,
clang::ExprValueKind, clang::CastKind, clang::Expr*, unsigned int) + 41574
7  clang             0x000000010092138a
clang::CastExpr::CastExpr(clang::Stmt::StmtClass, clang::QualType,
clang::ExprValueKind, clang::CastKind, clang::Expr*, unsigned int) + 30810
8  clang             0x000000010091c450
clang::CastExpr::CastExpr(clang::Stmt::StmtClass, clang::QualType,
clang::ExprValueKind, clang::CastKind, clang::Expr*, unsigned int) + 10528
9  clang             0x00000001009316c7
clang::CastExpr::CastExpr(clang::Stmt::StmtClass, clang::QualType,
clang::ExprValueKind, clang::CastKind, clang::Expr*, unsigned int) + 97175
10 clang             0x0000000100954b36
clang::CastExpr::CastExpr(clang::Stmt::StmtClass, clang::QualType,
clang::ExprValueKind, clang::CastKind, clang::Expr*, unsigned int) + 241670
11 clang             0x0000000100928914
clang::CastExpr::CastExpr(clang::Stmt::StmtClass, clang::QualType,
clang::ExprValueKind, clang::CastKind, clang::Expr*, unsigned int) + 60900
12 clang             0x000000010092a8ba
clang::CastExpr::CastExpr(clang::Stmt::StmtClass, clang::QualType,
clang::ExprValueKind, clang::CastKind, clang::Expr*, unsigned int) + 69002
13 clang             0x000000010092592c
clang::CastExpr::CastExpr(clang::Stmt::StmtClass, clang::QualType,
clang::ExprValueKind, clang::CastKind, clang::Expr*, unsigned int) + 48636
14 clang             0x0000000100955eec
clang::CastExpr::CastExpr(clang::Stmt::StmtClass, clang::QualType,
clang::ExprValueKind, clang::CastKind, clang::Expr*, unsigned int) + 246716
15 clang             0x0000000100927197
clang::CastExpr::CastExpr(clang::Stmt::StmtClass, clang::QualType,
clang::ExprValueKind, clang::CastKind, clang::Expr*, unsigned int) + 54887
16 clang             0x000000010092592c
clang::CastExpr::CastExpr(clang::Stmt::StmtClass, clang::QualType,
clang::ExprValueKind, clang::CastKind, clang::Expr*, unsigned int) + 48636
17 clang             0x000000010091b56e
clang::CastExpr::CastExpr(clang::Stmt::StmtClass, clang::QualType,
clang::ExprValueKind, clang::CastKind, clang::Expr*, unsigned int) + 6718
18 clang             0x000000010091b422
clang::CastExpr::CastExpr(clang::Stmt::StmtClass, clang::QualType,
clang::ExprValueKind, clang::CastKind, clang::Expr*, unsigned int) + 6386
19 clang             0x00000001003277b6 clang::UnresolvedUsingTypeLoc
clang::TypeLocBuilder::push<clang::UnresolvedUsingTypeLoc>(clang::QualType) +
118646
20 clang             0x0000000100325f20 clang::UnresolvedUsingTypeLoc
clang::TypeLocBuilder::push<clang::UnresolvedUsingTypeLoc>(clang::QualType) +
112352
21 clang             0x0000000100320899 clang::UnresolvedUsingTypeLoc
clang::TypeLocBuilder::push<clang::UnresolvedUsingTypeLoc>(clang::QualType) +
90201
22 clang             0x0000000100320f24 clang::UnresolvedUsingTypeLoc
clang::TypeLocBuilder::push<clang::UnresolvedUsingTypeLoc>(clang::QualType) +
91876
23 clang             0x000000010032498d clang::UnresolvedUsingTypeLoc
clang::TypeLocBuilder::push<clang::UnresolvedUsingTypeLoc>(clang::QualType) +
106829
24 clang             0x000000010032087a clang::UnresolvedUsingTypeLoc
clang::TypeLocBuilder::push<clang::UnresolvedUsingTypeLoc>(clang::QualType) +
90170
25 clang             0x000000010045dbcc
clang::CXXDefaultArgExpr::CXXDefaultArgExpr(clang::Stmt::StmtClass,
clang::SourceLocation, clang::ParmVarDecl*) + 83356
26 clang             0x00000001002cac48
clang::PragmaFPContractHandler::~PragmaFPContractHandler() + 3752
27 clang             0x00000001002ca542
clang::PragmaFPContractHandler::~PragmaFPContractHandler() + 1954
28 clang             0x00000001002cf489
clang::PragmaFPContractHandler::~PragmaFPContractHandler() + 22249
29 clang             0x00000001002ca58d
clang::PragmaFPContractHandler::~PragmaFPContractHandler() + 2029
30 clang             0x00000001002cbd8b
clang::PragmaFPContractHandler::~PragmaFPContractHandler() + 8171
31 clang             0x00000001002ca612
clang::PragmaFPContractHandler::~PragmaFPContractHandler() + 2162
32 clang             0x00000001002cf489
clang::PragmaFPContractHandler::~PragmaFPContractHandler() + 22249
33 clang             0x00000001002d0811
clang::PragmaFPContractHandler::~PragmaFPContractHandler() + 27249
34 clang             0x000000010028b495
llvm::CrashRecoveryContextCleanupBase<llvm::CrashRecoveryContextDeleteCleanup<clang::Sema>,
clang::Sema>::~CrashRecoveryContextCleanupBase() + 7541
35 clang             0x000000010028ae25
llvm::CrashRecoveryContextCleanupBase<llvm::CrashRecoveryContextDeleteCleanup<clang::Sema>,
clang::Sema>::~CrashRecoveryContextCleanupBase() + 5893
36 clang             0x00000001002a4375
clang::Parser::LateParsedAttribute::~LateParsedAttribute() + 26165
37 clang             0x00000001002a312a
clang::Parser::LateParsedAttribute::~LateParsedAttribute() + 21482
38 clang             0x0000000100292158
clang::Parser::LateParsedMemberInitializer::~LateParsedMemberInitializer() +
24744
39 clang             0x00000001002dc1db
llvm::SmallVectorTemplateBase<clang::ParsedTemplateArgument,
false>::grow(unsigned long) + 27707
40 clang             0x00000001002dc6b9
llvm::SmallVectorTemplateBase<clang::ParsedTemplateArgument,
false>::grow(unsigned long) + 28953
41 clang             0x00000001002db77c
llvm::SmallVectorTemplateBase<clang::ParsedTemplateArgument,
false>::grow(unsigned long) + 25052
42 clang             0x000000010029f0dc
clang::Parser::LateParsedAttribute::~LateParsedAttribute() + 5020
43 clang             0x000000010029ebd7
clang::Parser::LateParsedAttribute::~LateParsedAttribute() + 3735
44 clang             0x0000000100290844
clang::Parser::LateParsedMemberInitializer::~LateParsedMemberInitializer() +
18324
45 clang             0x00000001002db1cf
llvm::SmallVectorTemplateBase<clang::ParsedTemplateArgument,
false>::grow(unsigned long) + 23599
46 clang             0x000000010029f0dc
clang::Parser::LateParsedAttribute::~LateParsedAttribute() + 5020
47 clang             0x000000010029ebd7
clang::Parser::LateParsedAttribute::~LateParsedAttribute() + 3735
48 clang             0x0000000100290844
clang::Parser::LateParsedMemberInitializer::~LateParsedMemberInitializer() +
18324
49 clang             0x00000001002db1cf
llvm::SmallVectorTemplateBase<clang::ParsedTemplateArgument,
false>::grow(unsigned long) + 23599
50 clang             0x00000001002daaf5
llvm::SmallVectorTemplateBase<clang::ParsedTemplateArgument,
false>::grow(unsigned long) + 21845
51 clang             0x0000000100289485 clang::CUDAGlobalAttr*
clang::Decl::getAttr<clang::CUDAGlobalAttr>() const + 773
52 clang             0x000000010025257e llvm::DenseMap<clang::CXXMethodDecl
const*, llvm::SmallVector<clang::ThunkInfo, 1u>,
llvm::DenseMapInfo<clang::CXXMethodDecl const*>,
llvm::DenseMapInfo<llvm::SmallVector<clang::ThunkInfo, 1u> >
>::find(clang::CXXMethodDecl const* const&) + 4430
53 clang             0x0000000100024c77 std::vector<clang::CompilerInstance*,
std::allocator<clang::CompilerInstance*>
>::_M_insert_aux(__gnu_cxx::__normal_iterator<clang::CompilerInstance**,
std::vector<clang::CompilerInstance*, std::allocator<clang::CompilerInstance*>
> >, clang::CompilerInstance* const&) + 14999
54 clang             0x000000010000a836 llvm::SmallVectorImpl<char
const*>::insert(char const**, char const* const&) + 3062
55 clang             0x0000000100002917
56 clang             0x0000000100006abd std::vector<std::string,
std::allocator<std::string>
>::_M_insert_aux(__gnu_cxx::__normal_iterator<std::string*,
std::vector<std::string, std::allocator<std::string> > >, std::string const&) +
1453
57 clang             0x0000000100001234
Stack dump:
0.    Program arguments: /Users/tobias/llvm/bin/clang -cc1 -triple
x86_64-apple-macosx10.6.8 -emit-obj -mrelax-all -disable-free -main-file-name
clang_bug.ii.cpp -pic-level 1 -mdisable-fp-elim -masm-verbose -munwind-tables
-target-cpu core2 -target-linker-version 123.2 -coverage-file
clang_bug.ii.cpp.o -resource-dir /Users/tobias/llvm/bin/../lib/clang/3.1
-fmodule-cache-path
/var/folders/5m/5mk-kBbrGguxaR0NKdsAyE+++TI/-Tmp-/clang-module-cache
-fdeprecated-macro -fdebug-compilation-dir /Users/tobias/dev/clang_boost_bug
-ferror-limit 19 -fmessage-length 202 -stack-protector 1 -mstackrealign
-fblocks -fobjc-dispatch-method=mixed -fcxx-exceptions -fexceptions
-fdiagnostics-show-option -fcolor-diagnostics -o clang_bug.ii.cpp.o -x c++
clang_bug.ii.cpp 
1.    clang_bug.ii.cpp:103:21: current parser token '}'
2.    clang_bug.ii.cpp:76:1: parsing namespace 'boost'
3.    clang_bug.ii.cpp:91:5: parsing namespace 'exception_detail'
4.    clang_bug.ii.cpp:97:9: parsing struct/union/class body 'error_info_base'
5.    clang_bug.ii.cpp:98:108: parsing function body 'get'
6.    clang_bug.ii.cpp:98:108: in compound statement ('{}')
7.    clang_bug.ii.cpp:100:62: 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  Fri Dec 16 07:57:04 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 16 Dec 2011 13:57:04 +0000
Subject: [LLVMbugs] [Bug 11596] New: Assertion failed: (!E->isArrow() &&
 "missing call to bound member function?"), function VisitMemberExpr,
 file ExprConstant.cpp, line 1888.
Message-ID: <bug-11596-206@http.llvm.org/bugs/>

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

             Bug #: 11596
           Summary: Assertion failed: (!E->isArrow() && "missing call to
                    bound member function?"), function VisitMemberExpr,
                    file ExprConstant.cpp, line 1888.
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: rdivacky at freebsd.org
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 7753
  --> http://llvm.org/bugs/attachment.cgi?id=7753
test case

When compiling the attached:


Assertion failed: (!E->isArrow() && "missing call to bound member function?"),
function VisitMemberExpr, file ExprConstant.cpp, line 1888.
Stack dump:
0.      Program arguments: /usr/local/bin/clang -cc1 -triple
x86_64-unknown-freebsd8.2 -fsyntax-only -disable-free -main-file-name ucnv.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/3.1
-fmodule-cache-path /var/tmp/clang-module-cache -fdebug-compilation-dir
/tmp/delta-2006.08.03 -ferror-limit 19 -fmessage-length 116 -mstackrealign
-fgnu-runtime -fobjc-runtime-has-arc -fobjc-runtime-has-weak -fobjc-fragile-abi
-fdiagnostics-show-option -fcolor-diagnostics -x c ucnv.c 
1.      ucnv.c:9:56: current parser token ';'
2.      ucnv.c:6:91: parsing function body '_fromUnicodeWithCallback'
3.      ucnv.c:6:91: in compound statement ('{}')
clang: error: unable to execute command: Abort trap: 6 (core dumped)
clang: error: clang frontend command failed due to signal (use -v to see
invocation)
clang: note: diagnostic msg: Please submit a bug report to
http://llvm.org/bugs/ and include command line arguments and all diagnostic
information.
clang: note: diagnostic msg: Preprocessed source(s) and associated run
script(s) are located at:
clang: note: diagnostic msg: /tmp/ucnv-gKqRAk.i
clang: note: diagnostic msg: /tmp/ucnv-gKqRAk.sh

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 16 08:36:56 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 16 Dec 2011 14:36:56 +0000
Subject: [LLVMbugs] [Bug 11597] New: Incorrect alignment warning about
 aligned struct members
Message-ID: <bug-11597-206@http.llvm.org/bugs/>

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

             Bug #: 11597
           Summary: Incorrect alignment warning about aligned struct
                    members
           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
    Classification: Unclassified


Using clang trunk r146734 (and also 3.0 release), I get unexpected
warnings when checking for alignment problems using -Wcast-align.  I
reduced the problem case to the following:

struct foo {
} __attribute__((__aligned__(16)));

struct bar {
  int m[128] __attribute__((__aligned__(16)));
};

void baz(struct bar *b)
{
  struct foo *f = (struct foo *)&b->m;
}

Here, the bar::m member is declared to be 16-byte aligned, but clang
still warns about it, as shown:

$ clang -Wcast-align -c align2.c
align2.c:10:19: warning: cast from 'int (*)[128]' to 'struct foo *' increases
required alignment from 4 to 16 [-Wcast-align]
  struct foo *f = (struct foo *)&b->m;
                  ^~~~~~~~~~~~~~~~~~~
1 warning generated.

If I interpret gcc's documentation on aligned attributes correctly, the
alignment is supposed to apply to the array base m here, not to each
individual member of the array.  So in that case, the warning is
incorrect.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 16 10:00:42 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 16 Dec 2011 16:00:42 +0000
Subject: [LLVMbugs] [Bug 11598] New: Analysis for this terminator not
	implemented.
Message-ID: <bug-11598-206@http.llvm.org/bugs/>

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

             Bug #: 11598
           Summary: Analysis for this terminator not implemented.
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Static Analyzer
        AssignedTo: kremenek at apple.com
        ReportedBy: gryzman at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Analysis for this terminator not implemented.
UNREACHABLE executed at
/mnt/oldhd/home/gjaskie/Projects/llvm/llvm/tools/clang/lib/StaticAnalyzer/Core/CoreEngine.cpp:325!
0  clang++   0x097c65c8
1  clang++   0x097c6b14
2            0x00606400 __kernel_sigreturn + 0
3            0x00606424 __kernel_vsyscall + 16
4  libc.so.6 0x0032db91 gsignal + 81
5  libc.so.6 0x0032f46a abort + 378
6  clang++   0x097aeafc
7  clang++   0x089b9bc3
clang::ento::CoreEngine::HandleBlockExit(clang::CFGBlock const*,
clang::ento::ExplodedNode*) + 99
8  clang++   0x089ba1d2
clang::ento::CoreEngine::HandleBlockEntrance(clang::BlockEntrance const&,
clang::ento::ExplodedNode*) + 178
9  clang++   0x089bb34a
clang::ento::CoreEngine::ExecuteWorkList(clang::LocationContext const*,
unsigned int, clang::ento::ProgramState const*) + 634
10 clang++   0x088badec
11 clang++   0x088bb7b2
12 clang++   0x088bbb63
13 clang++   0x088bbe1c
14 clang++   0x088bc7a1
15 clang++   0x08541d1f clang::ParseAST(clang::Sema&, bool) + 527
16 clang++   0x0829855f clang::ASTFrontendAction::ExecuteAction() + 95
17 clang++   0x08299033 clang::FrontendAction::Execute() + 323
18 clang++   0x0827c53b
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 379
19 clang++   0x08261edc
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1196
20 clang++   0x08255a43 cc1_main(char const**, char const**, char const*,
void*) + 611
21 clang++   0x0825ef62 main + 754
22 libc.so.6 0x00319bb6 __libc_start_main + 230
23 clang++   0x08255651
Stack dump:

no idea what sort of 'terminator' causes it to do this, as the file I'm
compiling is quite long.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 16 12:23:16 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 16 Dec 2011 18:23:16 +0000
Subject: [LLVMbugs] [Bug 11599] New: Crash on invalid with
 TSK_ExplicitInstantiationDefinition after an invalid
 TSK_ExplicitInstantiationDeclaration
Message-ID: <bug-11599-206@http.llvm.org/bugs/>

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

             Bug #: 11599
           Summary: Crash on invalid with
                    TSK_ExplicitInstantiationDefinition after an invalid
                    TSK_ExplicitInstantiationDeclaration
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: nicolasweber at gmx.de
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified


hummer:clang thakis$ cat bug2.cc
namespace std {

template<typename _CharT>
class basic_string;

typedef basic_string<char> string;

template <typename STRING_TYPE> class BasicStringPiece;

extern template class BasicStringPiece<std::string>;
template class BasicStringPiece<std::string>;

}  // namespace std
hummer:clang thakis$ ../../Release+Asserts/bin/clang -c bug2.cc
bug2.cc:10:23: error: explicit instantiation of undefined template
'std::BasicStringPiece<std::string>'
extern template class BasicStringPiece<std::string>;
                      ^
bug2.cc:8:39: note: template is declared here
template <typename STRING_TYPE> class BasicStringPiece;
                                      ^
Assertion failed: (DefinitionData && "queried property of class with no
definition"), function data, file
/Volumes/MacintoshHD2/src/llvm-svn/tools/clang/lib/Sema/../../include/clang/AST/DeclCXX.h,
line 531.
0  clang             0x00000001015588a2 PrintStackTrace(void*) + 34
1  clang             0x0000000101558dd9 SignalHandler(int) + 713
2  libSystem.B.dylib 0x00007fff84b4e1ba _sigtramp + 26
3  libSystem.B.dylib 0x0000000000000090 _sigtramp + 2068520688
4  clang             0x0000000100047a46 abort + 22
5  clang             0x0000000100047a98 __assert_rtn + 56
6  clang             0x00000001003e2a28
clang::Sema::ActOnCXXConditionDeclaration(clang::Scope*, clang::Declarator&) +
0
7  clang             0x000000010058d496
clang::Sema::InstantiateClassTemplateSpecialization(clang::SourceLocation,
clang::ClassTemplateSpecializationDecl*, clang::TemplateSpecializationKind,
bool) + 196
8  clang             0x000000010050ee00
clang::Sema::ActOnExplicitInstantiation(clang::Scope*, clang::SourceLocation,
clang::SourceLocation, unsigned int, clang::SourceLocation, clang::CXXScopeSpec
const&, clang::OpaquePtr<clang::TemplateName>, clang::SourceLocation,
clang::SourceLocation, clang::ASTTemplateArgsPtr, clang::SourceLocation,
clang::AttributeList*) + 1522
9  clang             0x00000001002caf28
clang::Parser::ParseClassSpecifier(clang::tok::TokenKind,
clang::SourceLocation, clang::DeclSpec&, clang::Parser::ParsedTemplateInfo
const&, clang::AccessSpecifier, bool, bool) + 2710
10 clang             0x00000001002bde9e
clang::Parser::ParseDeclarationSpecifiers(clang::DeclSpec&,
clang::Parser::ParsedTemplateInfo const&, clang::AccessSpecifier,
clang::Parser::DeclSpecContext) + 6218
11 clang             0x00000001002f7bc5
clang::Parser::ParseSingleDeclarationAfterTemplate(unsigned int,
clang::Parser::ParsedTemplateInfo const&,
clang::Parser::ParsingDeclRAIIObject&, clang::SourceLocation&,
clang::AccessSpecifier, clang::AttributeList*) + 717
12 clang             0x00000001002f486d
clang::Parser::ParseDeclarationStartingWithTemplate(unsigned int,
clang::SourceLocation&, clang::AccessSpecifier, clang::AttributeList*) + 429
13 clang             0x00000001002c1003
clang::Parser::ParseDeclaration(clang::ASTOwningVector<clang::Stmt*, 32u>&,
unsigned int, clang::SourceLocation&,
clang::Parser::ParsedAttributesWithRange&) + 381
14 clang             0x000000010030194e
clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&,
clang::Parser::ParsingDeclSpec*) + 1776
15 clang             0x00000001002cc8ba
clang::Parser::ParseInnerNamespace(std::vector<clang::SourceLocation,
std::allocator<clang::SourceLocation> >&, std::vector<clang::IdentifierInfo*,
std::allocator<clang::IdentifierInfo*> >&, std::vector<clang::SourceLocation,
std::allocator<clang::SourceLocation> >&, unsigned int, clang::SourceLocation&,
clang::ParsedAttributes&, clang::Parser::BalancedDelimiterTracker&) + 256
16 clang             0x00000001002c265b clang::Parser::ParseNamespace(unsigned
int, clang::SourceLocation&, clang::SourceLocation) + 3323
17 clang             0x00000001002c10ab
clang::Parser::ParseDeclaration(clang::ASTOwningVector<clang::Stmt*, 32u>&,
unsigned int, clang::SourceLocation&,
clang::Parser::ParsedAttributesWithRange&) + 549
18 clang             0x000000010030194e
clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&,
clang::Parser::ParsingDeclSpec*) + 1776
19 clang             0x000000010030247e
clang::Parser::ParseTopLevelDecl(clang::OpaquePtr<clang::DeclGroupRef>&) + 262
20 clang             0x00000001002ad1a5 clang::ParseAST(clang::Sema&, bool) +
325
21 clang             0x0000000100278bfc clang::CodeGenAction::ExecuteAction() +
924
22 clang             0x00000001000693f6
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 962
23 clang             0x0000000100051391
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 2161
24 clang             0x000000010004b40b cc1_main(char const**, char const**,
char const*, void*) + 2939
25 clang             0x000000010004e410 main + 640
26 clang             0x000000010004a87c start + 52
Stack dump:
0.    Program arguments:
/Volumes/MacintoshHD2/src/llvm-svn/Release+Asserts/bin/clang -cc1 -triple
x86_64-apple-macosx10.6.8 -emit-obj -mrelax-all -disable-free -main-file-name
bug2.cc -pic-level 1 -mdisable-fp-elim -masm-verbose -munwind-tables
-target-cpu core2 -target-linker-version 97.17 -coverage-file bug2.o
-resource-dir
/Volumes/MacintoshHD2/src/llvm-svn/Release+Asserts/bin/../lib/clang/3.1
-fmodule-cache-path
/var/folders/++/++1Gyk++6+0++4RjPqRgNE++ojg/-Tmp-/clang-module-cache
-fdeprecated-macro -fdebug-compilation-dir
/Users/thakis/src/llvm-svn/tools/clang -ferror-limit 19 -fmessage-length 354
-stack-protector 1 -mstackrealign -fblocks -fobjc-dispatch-method=mixed
-fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o
bug2.o -x c++ bug2.cc 
1.    bug2.cc:11:45: current parser token ';'
2.    bug2.cc:1:1: parsing namespace 'std'
clang: error: unable to execute command: Illegal instruction
clang: error: clang frontend command failed due to signal (use -v to see
invocation)
clang: note: diagnostic msg: Please submit a bug report to
http://llvm.org/bugs/ and include command line arguments and all diagnostic
information.
clang: note: diagnostic msg: Preprocessed source(s) and associated run
script(s) are located at:
clang: note: diagnostic msg:
/var/folders/++/++1Gyk++6+0++4RjPqRgNE++ojg/-Tmp-/bug2-VDGar1.ii
clang: note: diagnostic msg:
/var/folders/++/++1Gyk++6+0++4RjPqRgNE++ojg/-Tmp-/bug2-VDGar1.sh
hummer:clang thakis$ ../../Release+Asserts/bin/clang --version
clang version 3.1 (trunk 146741)
Target: x86_64-apple-darwin10.8.0
Thread model: posix

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

From bugzilla-daemon at llvm.org  Fri Dec 16 13:31:36 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 16 Dec 2011 19:31:36 +0000
Subject: [LLVMbugs] [Bug 11594] Regression(r146562): Assertion
 `!E->isArrow() && "missing call to bound member function?"' when building
 ICU
In-Reply-To: <bug-11594-206@http.llvm.org/bugs/>
References: <bug-11594-206@http.llvm.org/bugs/>
Message-ID: <bug-11594-206-bVmRC0Xf2h@http.llvm.org/bugs/>

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

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-12-16 13:31:36 CST ---
r146753.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 16 15:50:07 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 16 Dec 2011 21:50:07 +0000
Subject: [LLVMbugs] [Bug 11600] New: LLVM cross-compilation fail when
	build=mingw
Message-ID: <bug-11600-206@http.llvm.org/bugs/>

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

             Bug #: 11600
           Summary: LLVM cross-compilation fail when build=mingw
           Product: tools
           Version: trunk
          Platform: PC
        OS/Version: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: llvm-config
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: dmalyshev at accesssoftek.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


I use mingw32 and cross tools based on gcc-4.5.1

LLVM configured with following parameters:

../llvm/configure
 --prefix=/g/llvm-armv7 \
 --build=i686-pc-mingw32 \
 --host=armv7-none-linux-gnueabi \
 --target=armv7-none-linux-gnueabi \
 --disable-shared --disable-multilib --disable-nls --disable-bootstrap \
 --with-cpu=cortex-a8 --with-fpu=neon --with-abi=aapcs --with-float=hard

and make stopped with following messages:

make[2]: *** No rule to make target
`g:/mytries/build/obj-cross-llvm/BuildTools/Debug+Asserts/lib/libLLVMipo.a',
needed by `/g/mytries/build/obj-cross-llvm/Debug+Asserts/bin/opt'.  Stop.
make[2]: Leaving directory `/g/mytries/build/obj-cross-llvm/tools/opt'
make[1]: *** [opt/.makeall] Error 2

And the same result if I try make any other tool.
I found that the command:

/g/mytries/build/obj-cross-llvm/BuildTools/Debug+Asserts/bin/llvm-config
--libfiles ipo

returns:

g:/mytries/build/obj-cross-llvm/BuildTools/Debug+Asserts/lib/libLLVMipo.a
g:/mytries/build/obj-cross-llvm/BuildTools/Debug+Asserts/lib/libLLVMScalarOpts.a
g:/mytries/build/obj-cross-llvm/BuildTools/Debug+Asserts/lib/libLLVMInstCombine.a
g:/mytries/build/obj-cross-llvm/BuildTools/Debug+Asserts/lib/libLLVMTransformUtils.a
g:/mytries/build/obj-cross-llvm/BuildTools/Debug+Asserts/lib/libLLVMipa.a
g:/mytries/build/obj-cross-llvm/BuildTools/Debug+Asserts/lib/libLLVMAnalysis.a
g:/mytries/build/obj-cross-llvm/BuildTools/Debug+Asserts/lib/libLLVMTarget.a
g:/mytries/build/obj-cross-llvm/BuildTools/Debug+Asserts/lib/libLLVMMC.a
g:/mytries/build/obj-cross-llvm/BuildTools/Debug+Asserts/lib/libLLVMObject.a
g:/mytries/build/obj-cross-llvm/BuildTools/Debug+Asserts/lib/libLLVMCore.a
g:/mytries/build/obj-cross-llvm/BuildTools/Debug+Asserts/lib/libLLVMSupport.a

but this libraries stored in
g:/mytries/build/obj-cross-llvm/Debug+Asserts/lib
instread of
g:/mytries/build/obj-cross-llvm/BuildTools/Debug+Asserts/lib



From: Daniel Dunbar
> My guess at the moment is that the comparison at llvm-config.cpp:186 
> (if (CurrentExecPrefix) ...) is failing perhaps due to non-normalized 
> paths on Win32.
>
> In your case, that branch definitely is supposed to be entered. If you 
> have a chance, could you run in a debugger and tell me what the values 
> of CurrentExecPrefix are in that case (as well as LLVM_OBJ_ROOT and 
> LLVM_BUILDMODE)?

Yes, you are right, CurrentExecPrefix:
g:/mytries/build/obj-cross-llvm/BuildTools/Release+Asserts

std::string(LLVM_OBJ_ROOT) + "/" + LLVM_BUILDMODE:
/g/mytries/build/obj-cross-llvm/BuildTools/Release+Asserts 

So, the comparison at llvm-config.cpp:186 is failing.

The fast solving is adds something like:

#ifdef LLVM_ON_WIN32
  CurrentExecPrefix.erase(1,1);
  CurrentExecPrefix = "/" + CurrentExecPrefix;
#endif

But maybe the best way is adds compare() function to llvm/Support/PathV2.h and
use 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 Dec 16 18:10:17 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 17 Dec 2011 00:10:17 +0000
Subject: [LLVMbugs] [Bug 11573] segfault on expr/expr.const/p2-0x.cpp
In-Reply-To: <bug-11573-206@http.llvm.org/bugs/>
References: <bug-11573-206@http.llvm.org/bugs/>
Message-ID: <bug-11573-206-Z7Mcbmvv5V@http.llvm.org/bugs/>

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

Pawel Worach <pawel.worach at gmail.com> changed:

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

--- Comment #6 from Pawel Worach <pawel.worach at gmail.com> 2011-12-16 18:10:17 CST ---
Apparently this test still triggers a segfault on a self-hosted i386 build.

clang version 3.1 (trunk 146754)

This time valgrind shows:

==42285== Conditional jump or move depends on uninitialised value(s)
==42285==    at 0x8B49C8C: clang::Expr::refersToVectorElement() const (in
/data/buildslave/freebsd-clang-i386/obj/llvm.2/Release+Asserts/bin/clang)
==42285==    by 0x8748D92: TryReferenceInitializationCore(clang::Sema&,
clang::InitializedEntity const&, clang::InitializationKind const&,
clang::Expr*, clang::QualType, clang::QualType, clang::Qualifiers,
clang::QualType, clang::QualType, clang::Qualifiers,
clang::InitializationSequence&) (in
/data/buildslave/freebsd-clang-i386/obj/llvm.2/Release+Asserts/bin/clang)
==42285==    by 0x8733141:
clang::InitializationSequence::InitializationSequence(clang::Sema&,
clang::InitializedEntity const&, clang::InitializationKind const&,
clang::Expr**, unsigned int) (in
/data/buildslave/freebsd-clang-i386/obj/llvm.2/Release+Asserts/bin/clang)
==42285==    by 0x873DFBD:
clang::Sema::PerformCopyInitialization(clang::InitializedEntity const&,
clang::SourceLocation, clang::ActionResult<clang::Expr*, true>, bool) (in
/data/buildslave/freebsd-clang-i386/obj/llvm.2/Release+Asserts/bin/clang)
==42285==    by 0x87A1E8B:
clang::Sema::PerformMoveOrCopyInitialization(clang::InitializedEntity const&,
clang::VarDecl const*, clang::QualType, clang::Expr*, bool) (in
/data/buildslave/freebsd-clang-i386/obj/llvm.2/Release+Asserts/bin/clang)
==42285==    by 0x87A2E87: clang::Sema::ActOnReturnStmt(clang::SourceLocation,
clang::Expr*) (in
/data/buildslave/freebsd-clang-i386/obj/llvm.2/Release+Asserts/bin/clang)
==42285==    by 0x85547AD:
clang::Parser::ParseReturnStatement(clang::ParsedAttributes&) (in
/data/buildslave/freebsd-clang-i386/obj/llvm.2/Release+Asserts/bin/clang)
==42285==    by 0x8550B53:
clang::Parser::ParseStatementOrDeclaration(clang::ASTOwningVector<clang::Stmt*,
32u>&, bool) (in
/data/buildslave/freebsd-clang-i386/obj/llvm.2/Release+Asserts/bin/clang)
==42285==    by 0x8556407: clang::Parser::ParseCompoundStatementBody(bool) (in
/data/buildslave/freebsd-clang-i386/obj/llvm.2/Release+Asserts/bin/clang)
==42285==    by 0x8557C8A:
clang::Parser::ParseFunctionStatementBody(clang::Decl*,
clang::Parser::ParseScope&) (in
/data/buildslave/freebsd-clang-i386/obj/llvm.2/Release+Asserts/bin/clang)
==42285==    by 0x8564C63:
clang::Parser::ParseFunctionDefinition(clang::Parser::ParsingDeclarator&,
clang::Parser::ParsedTemplateInfo const&) (in
/data/buildslave/freebsd-clang-i386/obj/llvm.2/Release+Asserts/bin/clang)
==42285==    by 0x8572B5F:
clang::Parser::ParseDeclGroup(clang::Parser::ParsingDeclSpec&, unsigned int,
bool, clang::SourceLocation*, clang::Parser::ForRangeInit*) (in
/data/buildslave/freebsd-clang-i386/obj/llvm.2/Release+Asserts/bin/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  Fri Dec 16 19:36:26 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 17 Dec 2011 01:36:26 +0000
Subject: [LLVMbugs] [Bug 11596] Assertion failed: (!E->isArrow() && "missing
 call to bound member function?"), function VisitMemberExpr,
 file ExprConstant.cpp, line 1888.
In-Reply-To: <bug-11596-206@http.llvm.org/bugs/>
References: <bug-11596-206@http.llvm.org/bugs/>
Message-ID: <bug-11596-206-bgpUkvEd7J@http.llvm.org/bugs/>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |sharparrow1 at yahoo.com
         Resolution|                            |DUPLICATE

--- Comment #1 from Eli Friedman <sharparrow1 at yahoo.com> 2011-12-16 19:36:26 CST ---


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

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 16 20:24:31 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 17 Dec 2011 02:24:31 +0000
Subject: [LLVMbugs] [Bug 11595] Assertion failed: (E->isRValue() &&
 E->getType()->isRecordType() && E->getType()->isLiteralType()),
 function EvaluateTemporary, file ExprConstant.cpp, line 2692.
In-Reply-To: <bug-11595-206@http.llvm.org/bugs/>
References: <bug-11595-206@http.llvm.org/bugs/>
Message-ID: <bug-11595-206-BMEweQzZ1B@http.llvm.org/bugs/>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |sharparrow1 at yahoo.com
         Resolution|                            |FIXED

--- Comment #1 from Eli Friedman <sharparrow1 at yahoo.com> 2011-12-16 20:24:31 CST ---
r146813.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 16 20:49:16 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 17 Dec 2011 02:49:16 +0000
Subject: [LLVMbugs] [Bug 11556] VLA folded pedantic error in -std=gnu99
In-Reply-To: <bug-11556-206@http.llvm.org/bugs/>
References: <bug-11556-206@http.llvm.org/bugs/>
Message-ID: <bug-11556-206-1IGuYAD9qS@http.llvm.org/bugs/>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

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

--- Comment #1 from Eli Friedman <sharparrow1 at yahoo.com> 2011-12-16 20:49:16 CST ---
This is an unfortunate side-effect of r132983; the issue is that people use
something like the given construct, then depend on the it to get folded to a
constant, so that initialization, illegal gotos, etc. work correctly.  We
initially made some effort to do the right thing in both std=gnu99 and std=c99,
but it got to be too much effort to handle wacky edge cases, so gnu99 does the
non-compliant folding (and tells you that it did it in -pedantic mode).

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

From bugzilla-daemon at llvm.org  Fri Dec 16 20:51:43 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 17 Dec 2011 02:51:43 +0000
Subject: [LLVMbugs] [Bug 11601] New: Range-based for cannot iterate over
 explicitly typed function pointers
Message-ID: <bug-11601-206@http.llvm.org/bugs/>

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

             Bug #: 11601
           Summary: Range-based for cannot iterate over explicitly typed
                    function pointers
           Product: clang
           Version: 3.0
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++0x
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: ainsaar at gmail.com
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Consider the following code (test.cpp) trying different ways of iterating over
an array of function pointers.

/////////////////////////////////////////
void v() {}

int main() {
    void (*vv[])() = {v, v, v};
    typedef void (*type)();
    for (type i : vv) i();
    for (decltype(*vv) i : vv) i();
    for (auto i : vv) i();
    for (void (*i)() : vv) i(); // Does not compile
    return 0;
}
/////////////////////////////////////////

Clang++ 3.0  gives the following errors:

$ clang++ test.cpp -std=c++11 -Wall -pedantic

test.cpp:10:17: error: use of undeclared identifier 'i'
    for (void (*i)() : vv) i(); // Does not compile
                ^
test.cpp:10:26: error: expected ';' in 'for' statement specifier
    for (void (*i)() : vv) i(); // Does not compile
                         ^
test.cpp:10:28: error: use of undeclared identifier 'i'
    for (void (*i)() : vv) i(); // Does not compile
                           ^
3 errors generated.


I think it should be possible to iterate over an array of function pointers
using a range-based for loop with an iterator whose type has been spelled out.

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

From bugzilla-daemon at llvm.org  Fri Dec 16 23:23:05 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 17 Dec 2011 05:23:05 +0000
Subject: [LLVMbugs] [Bug 11602] New: i386 bootstrap failure on OpenBSD
Message-ID: <bug-11602-206@http.llvm.org/bugs/>

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

             Bug #: 11602
           Summary: i386 bootstrap failure on OpenBSD
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: OpenBSD
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: X86
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: jsg at openbsd.org
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 7755
  --> http://llvm.org/bugs/attachment.cgi?id=7755
bitcode

There appears to be a problem compiling llvm/clang with clang++ on
OpenBSD/i386.
It does not appear when compiling with GCC 4.2.1 and clang++ compiles
llvm/clang
fine on OpenBSD/amd64.

clang++ -I/home/jsg/src/llvm/include -I/home/jsg/src/llvm/lib/Target/X86 
-D_DEBUG -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS
-D__STDC_LIMIT_MACROS -O3 -fomit-frame-pointer -fno-exceptions -fno-rtti -fPIC
-Woverloaded-virtual -Wcast-qual    -pedantic -Wno-long-long -Wall -W
-Wno-unused-parameter -Wwrite-strings  -c -MMD -MP -MF
"/home/jsg/src/llvm/lib/Target/X86/Release+Asserts/X86JITInfo.d.tmp" -MT
"/home/jsg/src/llvm/lib/Target/X86/Release+Asserts/X86JITInfo.o" -MT
"/home/jsg/src/llvm/lib/Target/X86/Release+Asserts/X86JITInfo.d" X86JITInfo.cpp
-o /home/jsg/src/llvm/lib/Target/X86/Release+Asserts/X86JITInfo.o
fatal error: error in backend: Size expression must be absolute.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 16 23:25:55 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 17 Dec 2011 05:25:55 +0000
Subject: [LLVMbugs] [Bug 7665] disassembler map file problems on OpenBSD
In-Reply-To: <bug-7665-206@http.llvm.org/bugs/>
References: <bug-7665-206@http.llvm.org/bugs/>
Message-ID: <bug-7665-206-R1KsBEuwJO@http.llvm.org/bugs/>

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

Jonathan Gray <jsg at openbsd.org> changed:

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

--- Comment #4 from Jonathan Gray <jsg at openbsd.org> 2011-12-16 23:25:55 CST ---
I no longer see this problem, closing.

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

From bugzilla-daemon at llvm.org  Sat Dec 17 04:13:49 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 17 Dec 2011 10:13:49 +0000
Subject: [LLVMbugs] [Bug 11603] New: Missing word in llvm.org main page
Message-ID: <bug-11603-206@http.llvm.org/bugs/>

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

             Bug #: 11603
           Summary: Missing word in llvm.org main page
           Product: Website
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: General Website
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: ori at avtalion.name
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


In the main llvm.org page, there seems to be a missing word in one of the
sub-project descriptions:

"The Clang Static Analyzer is a tool automatically finds bugs".
                                    ^
                                    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 Dec 17 09:28:31 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 17 Dec 2011 15:28:31 +0000
Subject: [LLVMbugs] [Bug 11604] New: Crash on evaluation of ICE with overflow
Message-ID: <bug-11604-206@http.llvm.org/bugs/>

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

             Bug #: 11604
           Summary: Crash on evaluation of ICE with overflow
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: release blocker
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: abramobagnara at tin.it
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


$ cat bug.c
typedef int v[(int) 2147483648.0f];
$ llvm_new/Debug+Asserts/bin/clang -c bug.c
ICE cannot be evaluated!
UNREACHABLE executed at ExprConstant.cpp:5380!
0  clang           0x00000000028f1365
1  clang           0x00000000028f1158
2  libpthread.so.0 0x00007fdf0f5ab8f0
3  libc.so.6       0x00007fdf0e89aa75 gsignal + 53
4  libc.so.6       0x00007fdf0e89e5c0 abort + 384
5  clang           0x00000000028db84d
6  clang           0x0000000001d415d5
clang::Expr::isIntegerConstantExpr(llvm::APSInt&, clang::ASTContext&,
clang::SourceLocation*, bool) const + 179
7  clang           0x00000000017a14c5
8  clang           0x00000000017a1ed1
clang::Sema::BuildArrayType(clang::QualType,
clang::ArrayType::ArraySizeModifier, clang::Expr*, unsigned int,
clang::SourceRange, clang::DeclarationName) + 2257
9  clang           0x00000000017a4861
10 clang           0x00000000017a7248
clang::Sema::GetTypeForDeclarator(clang::Declarator&, clang::Scope*) + 248
11 clang           0x00000000015201c7
clang::Sema::HandleDeclarator(clang::Scope*, clang::Declarator&,
clang::ASTMultiPtr<clang::TemplateParameterList*>) + 1989
12 clang           0x000000000151f8c2
clang::Sema::ActOnDeclarator(clang::Scope*, clang::Declarator&) + 90
13 clang           0x0000000001463060
clang::Parser::ParseDeclarationAfterDeclaratorAndAttributes(clang::Declarator&,
clang::Parser::ParsedTemplateInfo const&) + 120
14 clang           0x0000000001462b2b
clang::Parser::ParseDeclGroup(clang::Parser::ParsingDeclSpec&, unsigned int,
bool, clang::SourceLocation*, clang::Parser::ForRangeInit*) + 1159
15 clang           0x0000000001462526
clang::Parser::ParseSimpleDeclaration(clang::ASTOwningVector<clang::Stmt*,
32u>&, unsigned int, clang::SourceLocation&, clang::ParsedAttributes&, bool,
clang::Parser::ForRangeInit*) + 492
16 clang           0x00000000014622ef
clang::Parser::ParseDeclaration(clang::ASTOwningVector<clang::Stmt*, 32u>&,
unsigned int, clang::SourceLocation&,
clang::Parser::ParsedAttributesWithRange&) + 743
17 clang           0x0000000001453c29
clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&,
clang::Parser::ParsingDeclSpec*) + 1557
18 clang           0x0000000001453565
clang::Parser::ParseTopLevelDecl(clang::OpaquePtr<clang::DeclGroupRef>&) + 309
19 clang           0x000000000142f434 clang::ParseAST(clang::Sema&, bool) + 472
20 clang           0x000000000110f5f3 clang::ASTFrontendAction::ExecuteAction()
+ 265
21 clang           0x00000000012973aa clang::CodeGenAction::ExecuteAction() +
968
22 clang           0x000000000110f242 clang::FrontendAction::Execute() + 326
23 clang           0x00000000010e92b4
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 750
24 clang           0x00000000010ba298
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 972
25 clang           0x00000000010a9a39 cc1_main(char const**, char const**, char
const*, void*) + 999
26 clang           0x00000000010b589a main + 499
27 libc.so.6       0x00007fdf0e885c4d __libc_start_main + 253
28 clang           0x00000000010a8cd9

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 17 15:59:22 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 17 Dec 2011 21:59:22 +0000
Subject: [LLVMbugs] [Bug 11568] clang/Basic/DiagnosticSerializationKinds.inc
 does not get generated by CMake
In-Reply-To: <bug-11568-206@http.llvm.org/bugs/>
References: <bug-11568-206@http.llvm.org/bugs/>
Message-ID: <bug-11568-206-19bioFuStq@http.llvm.org/bugs/>

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

Chandler Carruth <chandlerc at gmail.com> changed:

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

--- Comment #4 from Chandler Carruth <chandlerc at gmail.com> 2011-12-17 15:59:22 CST ---
Still not sure why no build bot and most developers didn't hit this, but Ted
just committed a patch identical to this one that fixes the issue in r146836.
Sorry for the trouble.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 17 17:01:36 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 17 Dec 2011 23:01:36 +0000
Subject: [LLVMbugs] [Bug 11557] Clang trunk build broken on Ubuntu 11.04 x64
In-Reply-To: <bug-11557-206@http.llvm.org/bugs/>
References: <bug-11557-206@http.llvm.org/bugs/>
Message-ID: <bug-11557-206-apmtDpFioM@http.llvm.org/bugs/>

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

Chandler Carruth <chandlerc at gmail.com> changed:

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

--- Comment #3 from Chandler Carruth <chandlerc at gmail.com> 2011-12-17 17:01:36 CST ---
This is a dup of 11568 which was fixed by Ted in r146836 with an essentially
identical patch.

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

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 17 17:05:12 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 17 Dec 2011 23:05:12 +0000
Subject: [LLVMbugs] [Bug 11605] New: OpenCL operator && does not accept
	vector arguments
Message-ID: <bug-11605-206@http.llvm.org/bugs/>

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

             Bug #: 11605
           Summary: OpenCL operator && does not accept vector arguments
           Product: clang
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: schnetter at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


According to the OpenCL standard, this code is supposed to work:

typedef int int2 __attribute__((__ext_vector_type__(2)));
int2 and2(int2 a, int2 b) { return a && b; }

However, clang reports an error:

$ clang --version
clang version 3.1 (trunk 146839)
Target: x86_64-apple-darwin11.2.0
Thread model: posix

$ clang -S and.cl
and.cl:3:38: error: invalid operands to binary expression ('int2' and 'int2')
int2 and2(int2 a, int2 b) { return a && b; }
                                   ~ ^  ~
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 Dec 17 20:38:42 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 18 Dec 2011 02:38:42 +0000
Subject: [LLVMbugs] [Bug 11604] Crash on evaluation of ICE with overflow
In-Reply-To: <bug-11604-206@http.llvm.org/bugs/>
References: <bug-11604-206@http.llvm.org/bugs/>
Message-ID: <bug-11604-206-DcUGHNa5k2@http.llvm.org/bugs/>

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

Richard Smith <richard-llvm at metafoo.co.uk> changed:

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

--- Comment #1 from Richard Smith <richard-llvm at metafoo.co.uk> 2011-12-17 20:38:42 CST ---
Fixed in r146842. We now treat such overflowing casts as non-ICE, matching
modern gcc behavior; the original code sample is now rejected with a
diagnostic.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 18 05:10:30 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 18 Dec 2011 11:10:30 +0000
Subject: [LLVMbugs] [Bug 11606] New: ocaml bindings tests produce binaries
	in source dir
Message-ID: <bug-11606-206@http.llvm.org/bugs/>

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

             Bug #: 11606
           Summary: ocaml bindings tests produce binaries in source dir
           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: nobled at dreamwidth.org
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Each test in test/Bindings/Ocaml/ creates a .cmi, .cmx, and a .o file in the
same directory. If they're being produced at all, they should be in the build
directory, at least...

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 18 07:13:00 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 18 Dec 2011 13:13:00 +0000
Subject: [LLVMbugs] [Bug 11607] New: undefined references in libLLVMTarget.so
Message-ID: <bug-11607-206@http.llvm.org/bugs/>

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

             Bug #: 11607
           Summary: undefined references in libLLVMTarget.so
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Target Description Classes
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: oroppas at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Linking CXX executable ../../bin/opt
../../lib/libLLVMTarget.so: undefined reference to
`llvm::TargetInstrInfo::getOperandLatency(llvm::InstrItineraryData const*,
llvm::SDNode*, unsigned int, llvm::SDNode*, unsigned int) const'
../../lib/libLLVMTarget.so: undefined reference to
`llvm::TargetInstrInfo::getInstrLatency(llvm::InstrItineraryData const*,
llvm::SDNode*) const'
collect2: ld returned 1 exit status
make[2]: *** [bin/opt] Error 1
make[1]: *** [tools/opt/CMakeFiles/opt.dir/all] Error 2
make: *** [all] Error 2

In include/llvm/Target/TargetInstrInfo.h, I see

  virtual int getOperandLatency(const InstrItineraryData *ItinData,
                              const MachineInstr *DefMI, unsigned DefIdx,
                              const MachineInstr *UseMI, unsigned UseIdx)
const;

  virtual int getOperandLatency(const InstrItineraryData *ItinData,
                                SDNode *DefNode, unsigned DefIdx,
                                SDNode *UseNode, unsigned UseIdx) const;
and

  virtual int getInstrLatency(const InstrItineraryData *ItinData,
                              const MachineInstr *MI,
                              unsigned *PredCost = 0) const;

  virtual int getInstrLatency(const InstrItineraryData *ItinData,
                              SDNode *Node) const;

but only MachineInstr-versions are implemented in
lib/Target/TargetInstrInfo.cpp

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

From bugzilla-daemon at llvm.org  Sun Dec 18 11:20:50 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 18 Dec 2011 17:20:50 +0000
Subject: [LLVMbugs] [Bug 11608] New: -Wformat-security false positive with
 literal string + offset
Message-ID: <bug-11608-206@http.llvm.org/bugs/>

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

             Bug #: 11608
           Summary: -Wformat-security false positive with literal string +
                    offset
           Product: clang
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: dimitry at andric.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


In a bit of older code that I am running through clang, to clean out
warnings, I encountered the following rather tricky construction (but is
still valid C):

#include <stdio.h>

void foo(void)
{
  int noquotes = 2
  printf("\" hello world" + noquotes);
}

Of course in the original program, noquotes could be either 0 or 2, so
quotes before the string would either be printed or not.

However, clang always warns about it, as follows:

literal.c:6:10: warning: format string is not a string literal (potentially
insecure) [-Wformat-security]
  printf("\" hello world" + noquotes);
         ^~~~~~~~~~~~~~~~~~~~~~~~~~~

Somebody pointed out to me that a string literal plus an offset is still
a string literal, so this is a false positive.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 18 11:32:15 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 18 Dec 2011 17:32:15 +0000
Subject: [LLVMbugs] [Bug 11609] New: missing warning for ambiguous else
Message-ID: <bug-11609-206@http.llvm.org/bugs/>

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

             Bug #: 11609
           Summary: missing warning for ambiguous else
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: rafael.espindola at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


gcc will warn on

void g(int);
void f(int a, int b) {
        if (a)
                if (b)
                        g(1);
                else
                        g(2);
        g(3);
}

but clang doesn't.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 18 12:47:03 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 18 Dec 2011 18:47:03 +0000
Subject: [LLVMbugs] [Bug 11610] New: MIPS backend missing from component list
Message-ID: <bug-11610-206@http.llvm.org/bugs/>

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

             Bug #: 11610
           Summary: MIPS backend missing from component list
           Product: Bugzilla Admin
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Products
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: mans at mansr.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


The component list for the 'libraries' product is missing an entry for the MIPS
backend (other backends are in this list). This makes it impossible to report
bugs related to the MIPS backend.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 18 13:39:06 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 18 Dec 2011 19:39:06 +0000
Subject: [LLVMbugs] [Bug 11611] New: crash evaluating statement on function
	prototype
Message-ID: <bug-11611-206@http.llvm.org/bugs/>

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

             Bug #: 11611
           Summary: crash evaluating statement on function prototype
           Product: clang
           Version: 2.9
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Static Analyzer
        AssignedTo: kremenek at apple.com
        ReportedBy: davidv1992 at msn.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 7757
  --> http://llvm.org/bugs/attachment.cgi?id=7757
preprocessed file produced by scan-build crash overview

crash during analyzing of home-made kernel, whilst analyzing interrupt
handling. Crash is whilst evaluating long list of function prototypes.

Crash remains unaffected when rerunning scan-build

Stderr output:
ANALYZE: scaffold/test/interrupts/core.c test1_handler
ANALYZE: scaffold/test/interrupts/core.c test_interrupts_core_1
0  libLLVM-2.9.so.1 0x00002b34fabcecaf
1  libLLVM-2.9.so.1 0x00002b34fabcf271
2  libpthread.so.0  0x00002b34fb42c060
3  clang            0x0000000000a6e170
clang::ento::SimpleConstraintManager::assumeAux(clang::ento::GRState const*,
clang::ento::Loc, bool) + 192
4  clang            0x0000000000a6e25a
clang::ento::SimpleConstraintManager::assume(clang::ento::GRState const*,
clang::ento::Loc, bool) + 58
5  clang            0x0000000000a6ee60
clang::ento::SimpleConstraintManager::assume(clang::ento::GRState const*,
clang::ento::DefinedSVal, bool) + 48
6  clang            0x0000000000962591
7  clang            0x000000000096346f
8  clang            0x0000000000a09f13
clang::ento::CheckerManager::runCheckersForLocation(clang::ento::ExplodedNodeSet&,
clang::ento::ExplodedNodeSet const&, clang::ento::SVal, bool, clang::Stmt
const*, clang::ento::ExprEngine&) + 819
9  clang            0x0000000000a2359c
clang::ento::ExprEngine::evalLocation(clang::ento::ExplodedNodeSet&,
clang::Stmt const*, clang::ento::ExplodedNode*, clang::ento::GRState const*,
clang::ento::SVal, void const*, bool) + 332
10 clang            0x0000000000a25a22
clang::ento::ExprEngine::evalStore(clang::ento::ExplodedNodeSet&, clang::Expr
const*, clang::Expr const*, clang::ento::ExplodedNode*, clang::ento::GRState
const*, clang::ento::SVal, clang::ento::SVal, void const*) + 290
11 clang            0x0000000000a286d4
clang::ento::ExprEngine::VisitBinaryOperator(clang::BinaryOperator const*,
clang::ento::ExplodedNode*, clang::ento::ExplodedNodeSet&) + 3332
12 clang            0x0000000000a26ab1
clang::ento::ExprEngine::Visit(clang::Stmt const*, clang::ento::ExplodedNode*,
clang::ento::ExplodedNodeSet&) + 513
13 clang            0x0000000000a2e4b6
clang::ento::ExprEngine::ProcessStmt(clang::CFGStmt,
clang::ento::StmtNodeBuilder&) + 982
14 clang            0x0000000000a2e8ca
clang::ento::ExprEngine::processCFGElement(clang::CFGElement,
clang::ento::StmtNodeBuilder&) + 186
15 clang            0x0000000000a0fe85
clang::ento::CoreEngine::HandleBlockEntrance(clang::BlockEntrance const&,
clang::ento::ExplodedNode*) + 261
16 clang            0x0000000000a10b53
clang::ento::CoreEngine::ExecuteWorkList(clang::LocationContext const*,
unsigned int, clang::ento::GRState const*) + 515
17 clang            0x0000000000959176
18 clang            0x0000000000959974
19 clang            0x0000000000959db2
20 clang            0x000000000095a676
21 clang            0x000000000070b7cb clang::ParseAST(clang::Sema&, bool) +
251
22 clang            0x0000000000534aeb
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 283
23 clang            0x000000000051aa3b
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 971
24 clang            0x0000000000512ef7 cc1_main(char const**, char const**,
char const*, void*) + 727
25 clang            0x0000000000511a7a main + 634
26 libc.so.6        0x00002b34fbb7830d __libc_start_main + 237
27 clang            0x0000000000512ac5
Stack dump:
0.    Program arguments: /usr/bin/clang -cc1 -triple i386-pc-linux-gnu -analyze
-disable-free -disable-llvm-verifier -main-file-name core.c
-analyzer-store=region -analyzer-opt-analyze-nested-blocks
-analyzer-checker=core -analyzer-checker=unix -analyzer-checker=DeadStores
-analyzer-eagerly-assume -analyzer-output plist -w -mrelocation-model static
-mdisable-fp-elim -masm-verbose -mconstructor-aliases -target-cpu pentium4
-target-linker-version 2.21.53.20110810 -momit-leaf-frame-pointer -resource-dir
/usr/bin/../lib/clang/2.9 -I ./include/ -std=c99 -ferror-limit 19
-fmessage-length 0 -fgnu-runtime -fdiagnostics-show-option
-analyzer-display-progress -analyzer-output=html -o
/tmp/scan-build-2011-12-18-2 -x c scaffold/test/interrupts/core.c 
1.    <eof> parser at end of file
2.    scaffold/test/interrupts/core.c:25:3: Error evaluating statement
3.    scaffold/test/interrupts/core.c:25:3: Error evaluating 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  Sun Dec 18 15:42:36 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 18 Dec 2011 21:42:36 +0000
Subject: [LLVMbugs] [Bug 11612] New: _Atomic does not allow initialisation
 -- needed for ATOMIC_VAR_INIT()
Message-ID: <bug-11612-206@http.llvm.org/bugs/>

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

             Bug #: 11612
           Summary: _Atomic does not allow initialisation -- needed for
                    ATOMIC_VAR_INIT()
           Product: clang
           Version: 3.0
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: ed at 80386.nl
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


The latest C1X draft mentions a macro called ATOMIC_VAR_INIT() that can be used
to initialize an atomic variable.

_Atomic(int) i = ATOMIC_VAR_INIT(3);

As an experiment, I implemented a C-centric version of <stdatomic.h> for
FreeBSD:

http://80386.nl/pub/stdatomic.txt

Now the question is: how should I implement ATOMIC_VAR_INIT()? It seems like
assigning values to these variables directly doesn't work:

error: initializing '_Atomic(int)' with an expression of incompatible type
'int';
_Atomic(int) x = 3;
             ^   ~

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 18 17:29:44 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 18 Dec 2011 23:29:44 +0000
Subject: [LLVMbugs] [Bug 11608] -Wformat-security false positive with
 literal string + offset
In-Reply-To: <bug-11608-206@http.llvm.org/bugs/>
References: <bug-11608-206@http.llvm.org/bugs/>
Message-ID: <bug-11608-206-zwJ0lkPqPI@http.llvm.org/bugs/>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |sharparrow1 at yahoo.com
         Resolution|                            |INVALID

--- Comment #1 from Eli Friedman <sharparrow1 at yahoo.com> 2011-12-18 17:29:44 CST ---
There are many ways to hide a constant string from -Wformat-security.  This is
one.  If you want to use -Wformat-security, don't do 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 Dec 18 18:36:01 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 19 Dec 2011 00:36:01 +0000
Subject: [LLVMbugs] [Bug 11613] New: Assertion Failed:
 (D->isThisDeclarationADefinition() && "Invalid interface decl!"),
 function getObjCLayout, file
 /Users/kmowery/src/builds/llvm-svn/llvm/tools/clang/lib/AST/RecordLayoutBuilder.cpp,
 line 2164.
Message-ID: <bug-11613-206@http.llvm.org/bugs/>

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

             Bug #: 11613
           Summary: Assertion Failed: (D->isThisDeclarationADefinition()
                    && "Invalid interface decl!"), function getObjCLayout,
                    file
                    /Users/kmowery/src/builds/llvm-svn/llvm/tools/clang/li
                    b/AST/RecordLayoutBuilder.cpp, line 2164.
           Product: clang
           Version: trunk
          Platform: Macintosh
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: kmowery at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


I'm trying to compile WebKit trunk (currently r103192) with LLVM/Clang trunk
(Debug+Asserts, r146854). It fails rather spectacularly, with an LLVM assertion
failure. 

Associated debug information is attached and console output is pasted below.

--------------

CompileC
/Users/kmowery/src/builds/webkit/WebKit/WebKitBuild/WebCore.build/Release/WebCore.build/Objects-normal/x86_64/WebAccessibilityObjectWrapper.o
accessibility/mac/WebAccessibilityObjectWrapper.mm normal x86_64 objective-c++
com.apple.compilers.llvm.clang.1_0.compiler
    cd /Users/kmowery/src/builds/webkit/WebKit/Source/WebCore
    setenv LANG en_US.US-ASCII
    /Users/kmowery/src/builds/llvm-svn/build/Debug+Asserts/bin/clang -x
objective-c++ -arch x86_64 -fmessage-length=0
-fdiagnostics-print-source-range-info -fdiagnostics-show-category=id
-fdiagnostics-parseable-fixits -fobjc-gc -Wno-trigraphs -fno-exceptions
-fno-rtti -fpascal-strings -O2 -Werror -Wmissing-prototypes -Wno-return-type
-Wnon-virtual-dtor -Wparentheses -Wswitch -Wno-unused-parameter
-Wno-unused-variable -Wunused-value -Wno-shorten-64-to-32 -Wnewline-eof
-Wno-arc-abi -Wno-c++0x-extensions -DNDEBUG -DENABLE_3D_RENDERING -DENABLE_BLOB
-DENABLE_CHANNEL_MESSAGING -DENABLE_CLIENT_BASED_GEOLOCATION
-DENABLE_CSS_FILTERS -DENABLE_CSS_GRID_LAYOUT -DENABLE_CSS_SHADERS
-DENABLE_DATALIST -DENABLE_DETAILS -DENABLE_FILTERS -DENABLE_FULLSCREEN_API
-DENABLE_GEOLOCATION -DENABLE_ICONDATABASE -DENABLE_JAVASCRIPT_DEBUGGER
-DENABLE_MATHML -DENABLE_METER_TAG -DENABLE_NOTIFICATIONS -DENABLE_PROGRESS_TAG
-DENABLE_REQUEST_ANIMATION_FRAME -DENABLE_SHARED_WORKERS -DENABLE_SQL_DATABASE
-DENABLE_SVG -DENABLE_SVG_DOM_OBJC_BINDINGS -DENABLE_SVG_FONTS -DENABLE_VIDEO
-DENABLE_WEBGL -DENABLE_WEB_AUDIO -DENABLE_WEB_SOCKETS -DENABLE_WORKERS
-DENABLE_XSLT -DWEBKIT_VERSION_MIN_REQUIRED=WEBKIT_VERSION_LATEST -fasm-blocks
-mmacosx-version-min=10.7 -gdwarf-2 -fvisibility-inlines-hidden
-fno-threadsafe-statics -Wno-sign-conversion
"-DIBOutlet=__attribute__((iboutlet))"
"-DIBOutletCollection(ClassName)=__attribute__((iboutletcollection(ClassName)))"
"-DIBAction=void)__attribute__((ibaction)"
-I/Users/kmowery/src/builds/webkit/WebKit/WebKitBuild/WebCore.build/Release/WebCore.build/WebCore.hmap
-I/Users/kmowery/src/builds/webkit/WebKit/WebKitBuild/Release/include
-IForwardingHeaders -Iicu -I/usr/include/libxslt -I/usr/include/libxml2
-I/Users/kmowery/src/builds/webkit/WebKit/WebKitBuild/Release/DerivedSources/WebCore
-I/Users/kmowery/src/builds/webkit/WebKit/WebKitBuild/Release/usr/local/include
-I/Users/kmowery/src/builds/webkit/WebKit/WebKitBuild/WebCore.build/Release/WebCore.build/DerivedSources/x86_64
-I/Users/kmowery/src/builds/webkit/WebKit/WebKitBuild/WebCore.build/Release/WebCore.build/DerivedSources
-Wall -Wextra -Wcast-qual -Wchar-subscripts -Wextra-tokens -Wformat=2
-Winit-self -Wmissing-format-attribute -Wmissing-noreturn -Wpacked
-Wpointer-arith -Wredundant-decls -Wundef -Wwrite-strings -Wglobal-constructors
-Wexit-time-destructors
-F/Users/kmowery/src/builds/webkit/WebKit/WebKitBuild/Release
-F/System/Library/Frameworks/Carbon.framework/Frameworks
-F/System/Library/Frameworks/ApplicationServices.framework/Frameworks
-F/System/Library/Frameworks/CoreServices.framework/Frameworks
-F/System/Library/PrivateFrameworks -include
/var/folders/2j/4dcc9sy915z774w9789765p00000gn/C/com.apple.Xcode.501/SharedPrecompiledHeaders/WebCorePrefix-esrzswlfpuwqcvgzjllqcpmqkuxp/WebCorePrefix.h
-MMD -MT dependencies -MF
/Users/kmowery/src/builds/webkit/WebKit/WebKitBuild/WebCore.build/Release/WebCore.build/Objects-normal/x86_64/WebAccessibilityObjectWrapper.d
-c
/Users/kmowery/src/builds/webkit/WebKit/Source/WebCore/accessibility/mac/WebAccessibilityObjectWrapper.mm
-o
/Users/kmowery/src/builds/webkit/WebKit/WebKitBuild/WebCore.build/Release/WebCore.build/Objects-normal/x86_64/WebAccessibilityObjectWrapper.o
Assertion failed: (D->isThisDeclarationADefinition() && "Invalid interface
decl!"), function getObjCLayout, file
/Users/kmowery/src/builds/llvm-svn/llvm/tools/clang/lib/AST/RecordLayoutBuilder.cpp,
line 2164.
0  clang             0x00000001106ef2f5 _ZL15PrintStackTracePv + 53
1  clang             0x00000001106ef969 _ZL13SignalHandleri + 361
2  libsystem_c.dylib 0x00007fff8dea6cfa _sigtramp + 26
3  libsystem_c.dylib 0x0000040015526980 _sigtramp + 18446607736539446432
4  clang             0x00000001106ef63b raise + 27
5  clang             0x00000001106ef6fc abort + 28
6  clang             0x00000001106ef6d1 __assert_rtn + 129
7  clang             0x000000010f464d68
clang::ASTContext::getObjCLayout(clang::ObjCInterfaceDecl const*,
clang::ObjCImplementationDecl const*) const + 136
8  clang             0x000000010f2c25f7
clang::ASTContext::getASTObjCInterfaceLayout(clang::ObjCInterfaceDecl const*)
const + 39
9  clang             0x000000010f465073 (anonymous
namespace)::RecordLayoutBuilder::Layout(clang::ObjCInterfaceDecl const*) + 67
10 clang             0x000000010f464e93
clang::ASTContext::getObjCLayout(clang::ObjCInterfaceDecl const*,
clang::ObjCImplementationDecl const*) const + 435
11 clang             0x000000010f2c25f7
clang::ASTContext::getASTObjCInterfaceLayout(clang::ObjCInterfaceDecl const*)
const + 39
12 clang             0x000000010e6d92b2
clang::CodeGen::CGDebugInfo::CreateType(clang::ObjCInterfaceType const*,
llvm::DIFile) + 1778
13 clang             0x000000010e6db8aa
clang::CodeGen::CGDebugInfo::CreateTypeNode(clang::QualType, llvm::DIFile) +
618
14 clang             0x000000010e6cfe21
clang::CodeGen::CGDebugInfo::getOrCreateType(clang::QualType, llvm::DIFile) +
305
15 clang             0x000000010e6d8bb1
clang::CodeGen::CGDebugInfo::CreateType(clang::ObjCObjectType const*,
llvm::DIFile) + 97
16 clang             0x000000010e6db84a
clang::CodeGen::CGDebugInfo::CreateTypeNode(clang::QualType, llvm::DIFile) +
522
17 clang             0x000000010e6cfe21
clang::CodeGen::CGDebugInfo::getOrCreateType(clang::QualType, llvm::DIFile) +
305
18 clang             0x000000010e6d27e0
clang::CodeGen::CGDebugInfo::CreatePointeeType(clang::QualType, llvm::DIFile) +
1824
19 clang             0x000000010e6d1fa3
clang::CodeGen::CGDebugInfo::CreatePointerLikeType(unsigned int, clang::Type
const*, clang::QualType, llvm::DIFile) + 451
20 clang             0x000000010e6d1dae
clang::CodeGen::CGDebugInfo::CreateType(clang::ObjCObjectPointerType const*,
llvm::DIFile) + 126
21 clang             0x000000010e6db7ea
clang::CodeGen::CGDebugInfo::CreateTypeNode(clang::QualType, llvm::DIFile) +
426
22 clang             0x000000010e6cfe21
clang::CodeGen::CGDebugInfo::getOrCreateType(clang::QualType, llvm::DIFile) +
305
23 clang             0x000000010e6d4114
clang::CodeGen::CGDebugInfo::CreateType(clang::FunctionType const*,
llvm::DIFile) + 212
24 clang             0x000000010e6dbacb
clang::CodeGen::CGDebugInfo::CreateTypeNode(clang::QualType, llvm::DIFile) +
1163
25 clang             0x000000010e6cfe21
clang::CodeGen::CGDebugInfo::getOrCreateType(clang::QualType, llvm::DIFile) +
305
26 clang             0x000000010e6d4d10
clang::CodeGen::CGDebugInfo::getOrCreateMethodType(clang::CXXMethodDecl const*,
llvm::DIFile) + 256
27 clang             0x000000010e6d5655
clang::CodeGen::CGDebugInfo::CreateCXXMemberFunction(clang::CXXMethodDecl
const*, llvm::DIFile, llvm::DIType) + 261
28 clang             0x000000010e6d5e95
clang::CodeGen::CGDebugInfo::CollectCXXMemberFunctions(clang::CXXRecordDecl
const*, llvm::DIFile, llvm::SmallVectorImpl<llvm::Value*>&, llvm::DIType) + 293
29 clang             0x000000010e6d7f52
clang::CodeGen::CGDebugInfo::CreateType(clang::RecordType const*) + 3122
30 clang             0x000000010e6dba48
clang::CodeGen::CGDebugInfo::CreateTypeNode(clang::QualType, llvm::DIFile) +
1032
31 clang             0x000000010e6cfe21
clang::CodeGen::CGDebugInfo::getOrCreateType(clang::QualType, llvm::DIFile) +
305
32 clang             0x000000010e6d6340
clang::CodeGen::CGDebugInfo::CollectCXXBases(clang::CXXRecordDecl const*,
llvm::DIFile, llvm::SmallVectorImpl<llvm::Value*>&, llvm::DIType) + 576
33 clang             0x000000010e6d78b2
clang::CodeGen::CGDebugInfo::CreateType(clang::RecordType const*) + 1426
34 clang             0x000000010e6dba48
clang::CodeGen::CGDebugInfo::CreateTypeNode(clang::QualType, llvm::DIFile) +
1032
35 clang             0x000000010e6cfe21
clang::CodeGen::CGDebugInfo::getOrCreateType(clang::QualType, llvm::DIFile) +
305
36 clang             0x000000010e6d27e0
clang::CodeGen::CGDebugInfo::CreatePointeeType(clang::QualType, llvm::DIFile) +
1824
37 clang             0x000000010e6d1fa3
clang::CodeGen::CGDebugInfo::CreatePointerLikeType(unsigned int, clang::Type
const*, clang::QualType, llvm::DIFile) + 451
38 clang             0x000000010e6d20aa
clang::CodeGen::CGDebugInfo::CreateType(clang::PointerType const*,
llvm::DIFile) + 122
39 clang             0x000000010e6db952
clang::CodeGen::CGDebugInfo::CreateTypeNode(clang::QualType, llvm::DIFile) +
786
40 clang             0x000000010e6cfe21
clang::CodeGen::CGDebugInfo::getOrCreateType(clang::QualType, llvm::DIFile) +
305
41 clang             0x000000010e6d44f8
clang::CodeGen::CGDebugInfo::createFieldType(llvm::StringRef, clang::QualType,
unsigned long long, clang::SourceLocation, clang::AccessSpecifier, unsigned
long long, llvm::DIFile, llvm::DIDescriptor) + 216
42 clang             0x000000010e6d4b86
clang::CodeGen::CGDebugInfo::CollectRecordFields(clang::RecordDecl const*,
llvm::DIFile, llvm::SmallVectorImpl<llvm::Value*>&, llvm::DIType) + 886
43 clang             0x000000010e6d7e4a
clang::CodeGen::CGDebugInfo::CreateType(clang::RecordType const*) + 2858
44 clang             0x000000010e6dba48
clang::CodeGen::CGDebugInfo::CreateTypeNode(clang::QualType, llvm::DIFile) +
1032
45 clang             0x000000010e6cfe21
clang::CodeGen::CGDebugInfo::getOrCreateType(clang::QualType, llvm::DIFile) +
305
46 clang             0x000000010e6d44f8
clang::CodeGen::CGDebugInfo::createFieldType(llvm::StringRef, clang::QualType,
unsigned long long, clang::SourceLocation, clang::AccessSpecifier, unsigned
long long, llvm::DIFile, llvm::DIDescriptor) + 216
47 clang             0x000000010e6d4b86
clang::CodeGen::CGDebugInfo::CollectRecordFields(clang::RecordDecl const*,
llvm::DIFile, llvm::SmallVectorImpl<llvm::Value*>&, llvm::DIType) + 886
48 clang             0x000000010e6d7e4a
clang::CodeGen::CGDebugInfo::CreateType(clang::RecordType const*) + 2858
49 clang             0x000000010e6dba48
clang::CodeGen::CGDebugInfo::CreateTypeNode(clang::QualType, llvm::DIFile) +
1032
50 clang             0x000000010e6cfe21
clang::CodeGen::CGDebugInfo::getOrCreateType(clang::QualType, llvm::DIFile) +
305
51 clang             0x000000010e6d27e0
clang::CodeGen::CGDebugInfo::CreatePointeeType(clang::QualType, llvm::DIFile) +
1824
52 clang             0x000000010e6d1fa3
clang::CodeGen::CGDebugInfo::CreatePointerLikeType(unsigned int, clang::Type
const*, clang::QualType, llvm::DIFile) + 451
53 clang             0x000000010e6d20aa
clang::CodeGen::CGDebugInfo::CreateType(clang::PointerType const*,
llvm::DIFile) + 122
54 clang             0x000000010e6db952
clang::CodeGen::CGDebugInfo::CreateTypeNode(clang::QualType, llvm::DIFile) +
786
55 clang             0x000000010e6cfe21
clang::CodeGen::CGDebugInfo::getOrCreateType(clang::QualType, llvm::DIFile) +
305
56 clang             0x000000010e6d44f8
clang::CodeGen::CGDebugInfo::createFieldType(llvm::StringRef, clang::QualType,
unsigned long long, clang::SourceLocation, clang::AccessSpecifier, unsigned
long long, llvm::DIFile, llvm::DIDescriptor) + 216
57 clang             0x000000010e6d4b86
clang::CodeGen::CGDebugInfo::CollectRecordFields(clang::RecordDecl const*,
llvm::DIFile, llvm::SmallVectorImpl<llvm::Value*>&, llvm::DIType) + 886
58 clang             0x000000010e6d7e4a
clang::CodeGen::CGDebugInfo::CreateType(clang::RecordType const*) + 2858
59 clang             0x000000010e6dba48
clang::CodeGen::CGDebugInfo::CreateTypeNode(clang::QualType, llvm::DIFile) +
1032
60 clang             0x000000010e6cfe21
clang::CodeGen::CGDebugInfo::getOrCreateType(clang::QualType, llvm::DIFile) +
305
61 clang             0x000000010e6d44f8
clang::CodeGen::CGDebugInfo::createFieldType(llvm::StringRef, clang::QualType,
unsigned long long, clang::SourceLocation, clang::AccessSpecifier, unsigned
long long, llvm::DIFile, llvm::DIDescriptor) + 216
62 clang             0x000000010e6d4b86
clang::CodeGen::CGDebugInfo::CollectRecordFields(clang::RecordDecl const*,
llvm::DIFile, llvm::SmallVectorImpl<llvm::Value*>&, llvm::DIType) + 886
63 clang             0x000000010e6d7e4a
clang::CodeGen::CGDebugInfo::CreateType(clang::RecordType const*) + 2858
64 clang             0x000000010e6dba48
clang::CodeGen::CGDebugInfo::CreateTypeNode(clang::QualType, llvm::DIFile) +
1032
65 clang             0x000000010e6cfe21
clang::CodeGen::CGDebugInfo::getOrCreateType(clang::QualType, llvm::DIFile) +
305
66 clang             0x000000010e6d6061
clang::CodeGen::CGDebugInfo::CollectCXXFriends(clang::CXXRecordDecl const*,
llvm::DIFile, llvm::SmallVectorImpl<llvm::Value*>&, llvm::DIType) + 337
67 clang             0x000000010e6d7fd7
clang::CodeGen::CGDebugInfo::CreateType(clang::RecordType const*) + 3255
68 clang             0x000000010e6dba48
clang::CodeGen::CGDebugInfo::CreateTypeNode(clang::QualType, llvm::DIFile) +
1032
69 clang             0x000000010e6cfe21
clang::CodeGen::CGDebugInfo::getOrCreateType(clang::QualType, llvm::DIFile) +
305
70 clang             0x000000010e6d44f8
clang::CodeGen::CGDebugInfo::createFieldType(llvm::StringRef, clang::QualType,
unsigned long long, clang::SourceLocation, clang::AccessSpecifier, unsigned
long long, llvm::DIFile, llvm::DIDescriptor) + 216
71 clang             0x000000010e6d4b86
clang::CodeGen::CGDebugInfo::CollectRecordFields(clang::RecordDecl const*,
llvm::DIFile, llvm::SmallVectorImpl<llvm::Value*>&, llvm::DIType) + 886
72 clang             0x000000010e6d7e4a
clang::CodeGen::CGDebugInfo::CreateType(clang::RecordType const*) + 2858
73 clang             0x000000010e6dba48
clang::CodeGen::CGDebugInfo::CreateTypeNode(clang::QualType, llvm::DIFile) +
1032
74 clang             0x000000010e6cfe21
clang::CodeGen::CGDebugInfo::getOrCreateType(clang::QualType, llvm::DIFile) +
305
75 clang             0x000000010e6d72b0
clang::CodeGen::CGDebugInfo::getOrCreateRecordType(clang::QualType,
clang::SourceLocation) + 112
76 clang             0x000000010e720b09
clang::CodeGen::CodeGenFunction::EmitCXXMemberCallExpr(clang::CXXMemberCallExpr
const*, clang::CodeGen::ReturnValueSlot) + 473
77 clang             0x000000010e70ff94
clang::CodeGen::CodeGenFunction::EmitCallExpr(clang::CallExpr const*,
clang::CodeGen::ReturnValueSlot) + 292
78 clang             0x000000010e74ae7c (anonymous
namespace)::ScalarExprEmitter::VisitCallExpr(clang::CallExpr const*) + 156
79 clang             0x000000010e74aef8 clang::StmtVisitorBase<clang::make_ptr,
(anonymous namespace)::ScalarExprEmitter,
llvm::Value*>::VisitCXXMemberCallExpr(clang::CXXMemberCallExpr*) + 40
80 clang             0x000000010e746e7d clang::StmtVisitorBase<clang::make_ptr,
(anonymous namespace)::ScalarExprEmitter, llvm::Value*>::Visit(clang::Stmt*) +
2749
81 clang             0x000000010e73ea68 (anonymous
namespace)::ScalarExprEmitter::Visit(clang::Expr*) + 40
82 clang             0x000000010e73e9d2
clang::CodeGen::CodeGenFunction::EmitScalarExpr(clang::Expr const*, bool) + 226
83 clang             0x000000010e720c95
clang::CodeGen::CodeGenFunction::EmitCXXMemberCallExpr(clang::CXXMemberCallExpr
const*, clang::CodeGen::ReturnValueSlot) + 869
84 clang             0x000000010e70ff94
clang::CodeGen::CodeGenFunction::EmitCallExpr(clang::CallExpr const*,
clang::CodeGen::ReturnValueSlot) + 292
85 clang             0x000000010e74ae7c (anonymous
namespace)::ScalarExprEmitter::VisitCallExpr(clang::CallExpr const*) + 156
86 clang             0x000000010e74aef8 clang::StmtVisitorBase<clang::make_ptr,
(anonymous namespace)::ScalarExprEmitter,
llvm::Value*>::VisitCXXMemberCallExpr(clang::CXXMemberCallExpr*) + 40
87 clang             0x000000010e746e7d clang::StmtVisitorBase<clang::make_ptr,
(anonymous namespace)::ScalarExprEmitter, llvm::Value*>::Visit(clang::Stmt*) +
2749
88 clang             0x000000010e73ea68 (anonymous
namespace)::ScalarExprEmitter::Visit(clang::Expr*) + 40
89 clang             0x000000010e73e9d2
clang::CodeGen::CodeGenFunction::EmitScalarExpr(clang::Expr const*, bool) + 226
90 clang             0x000000010e7b59e9
clang::CodeGen::CodeGenFunction::EmitReturnStmt(clang::ReturnStmt const&) + 697
91 clang             0x000000010e7b3bbd
clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*) + 813
92 clang             0x000000010e7b9725
clang::CodeGen::CodeGenFunction::EmitCompoundStmt(clang::CompoundStmt const&,
bool, clang::CodeGen::AggValueSlot) + 357
93 clang             0x000000010e7b3fc6
clang::CodeGen::CodeGenFunction::EmitSimpleStmt(clang::Stmt const*) + 262
94 clang             0x000000010e7b38fe
clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*) + 110
95 clang             0x000000010e755d69
clang::CodeGen::CodeGenFunction::GenerateObjCMethod(clang::ObjCMethodDecl
const*) + 105
96 clang             0x000000010e7e3248
clang::CodeGen::CodeGenModule::EmitTopLevelDecl(clang::Decl*) + 1064
97 clang             0x000000010e821518 (anonymous
namespace)::CodeGeneratorImpl::HandleTopLevelDecl(clang::DeclGroupRef) + 104
98 clang             0x000000010e7ce768
clang::BackendConsumer::HandleTopLevelDecl(clang::DeclGroupRef) + 232
99 clang             0x000000010e833b2f clang::ParseAST(clang::Sema&, bool) +
511
100 clang             0x000000010e4c4cb8
clang::ASTFrontendAction::ExecuteAction() + 264
101 clang             0x000000010e7cc670 clang::CodeGenAction::ExecuteAction()
+ 1200
102 clang             0x000000010e4c489e clang::FrontendAction::Execute() + 366
103 clang             0x000000010e4893f9
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 969
104 clang             0x000000010e4575b7
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1159
105 clang             0x000000010e43fd13 cc1_main(char const**, char const**,
char const*, void*) + 1203
106 clang             0x000000010e450ade main + 670
107 clang             0x000000010e43f834 start + 52
108 clang             0x00000000000000bd start + 18446744069175249085
Stack dump:
0.    Program arguments:
/Users/kmowery/src/builds/llvm-svn/build/Debug+Asserts/bin/clang -cc1 -triple
x86_64-apple-macosx10.7.0 -emit-obj -disable-free -main-file-name
WebAccessibilityObjectWrapper.mm -pic-level 1 -mdisable-fp-elim -masm-verbose
-munwind-tables -target-cpu core2 -target-linker-version 127.2 -g
-coverage-file
/Users/kmowery/src/builds/webkit/WebKit/WebKitBuild/WebCore.build/Release/WebCore.build/Objects-normal/x86_64/WebAccessibilityObjectWrapper.o
-resource-dir
/Users/kmowery/src/builds/llvm-svn/build/Debug+Asserts/bin/../lib/clang/3.1
-dependency-file
/Users/kmowery/src/builds/webkit/WebKit/WebKitBuild/WebCore.build/Release/WebCore.build/Objects-normal/x86_64/WebAccessibilityObjectWrapper.d
-MT dependencies -include-pch
/var/folders/2j/4dcc9sy915z774w9789765p00000gn/C/com.apple.Xcode.501/SharedPrecompiledHeaders/WebCorePrefix-esrzswlfpuwqcvgzjllqcpmqkuxp/WebCorePrefix.h.pth
-D NDEBUG -D ENABLE_3D_RENDERING -D ENABLE_BLOB -D ENABLE_CHANNEL_MESSAGING -D
ENABLE_CLIENT_BASED_GEOLOCATION -D ENABLE_CSS_FILTERS -D ENABLE_CSS_GRID_LAYOUT
-D ENABLE_CSS_SHADERS -D ENABLE_DATALIST -D ENABLE_DETAILS -D ENABLE_FILTERS -D
ENABLE_FULLSCREEN_API -D ENABLE_GEOLOCATION -D ENABLE_ICONDATABASE -D
ENABLE_JAVASCRIPT_DEBUGGER -D ENABLE_MATHML -D ENABLE_METER_TAG -D
ENABLE_NOTIFICATIONS -D ENABLE_PROGRESS_TAG -D ENABLE_REQUEST_ANIMATION_FRAME
-D ENABLE_SHARED_WORKERS -D ENABLE_SQL_DATABASE -D ENABLE_SVG -D
ENABLE_SVG_DOM_OBJC_BINDINGS -D ENABLE_SVG_FONTS -D ENABLE_VIDEO -D
ENABLE_WEBGL -D ENABLE_WEB_AUDIO -D ENABLE_WEB_SOCKETS -D ENABLE_WORKERS -D
ENABLE_XSLT -D WEBKIT_VERSION_MIN_REQUIRED=WEBKIT_VERSION_LATEST -D
IBOutlet=__attribute__((iboutlet)) -D
IBOutletCollection(ClassName)=__attribute__((iboutletcollection(ClassName))) -D
IBAction=void)__attribute__((ibaction) -I
/Users/kmowery/src/builds/webkit/WebKit/WebKitBuild/WebCore.build/Release/WebCore.build/WebCore.hmap
-I /Users/kmowery/src/builds/webkit/WebKit/WebKitBuild/Release/include -I
ForwardingHeaders -I icu -I /usr/include/libxslt -I /usr/include/libxml2 -I
/Users/kmowery/src/builds/webkit/WebKit/WebKitBuild/Release/DerivedSources/WebCore
-I
/Users/kmowery/src/builds/webkit/WebKit/WebKitBuild/Release/usr/local/include
-I
/Users/kmowery/src/builds/webkit/WebKit/WebKitBuild/WebCore.build/Release/WebCore.build/DerivedSources/x86_64
-I
/Users/kmowery/src/builds/webkit/WebKit/WebKitBuild/WebCore.build/Release/WebCore.build/DerivedSources
-F/Users/kmowery/src/builds/webkit/WebKit/WebKitBuild/Release
-F/System/Library/Frameworks/Carbon.framework/Frameworks
-F/System/Library/Frameworks/ApplicationServices.framework/Frameworks
-F/System/Library/Frameworks/CoreServices.framework/Frameworks
-F/System/Library/PrivateFrameworks -fmodule-cache-path
/var/folders/2j/4dcc9sy915z774w9789765p00000gn/T/clang-module-cache -O2
-Wno-trigraphs -Werror -Wmissing-prototypes -Wno-return-type -Wnon-virtual-dtor
-Wparentheses -Wswitch -Wno-unused-parameter -Wno-unused-variable
-Wunused-value -Wno-shorten-64-to-32 -Wnewline-eof -Wno-arc-abi
-Wno-c++0x-extensions -Wno-sign-conversion -Wall -Wextra -Wcast-qual
-Wchar-subscripts -Wextra-tokens -Wformat=2 -Winit-self
-Wmissing-format-attribute -Wmissing-noreturn -Wpacked -Wpointer-arith
-Wredundant-decls -Wundef -Wwrite-strings -Wglobal-constructors
-Wexit-time-destructors -fconst-strings -fdeprecated-macro
-fdebug-compilation-dir /Users/kmowery/src/builds/webkit/WebKit -ferror-limit
19 -fmessage-length 0 -fvisibility-inlines-hidden
-fdiagnostics-print-source-range-info -fdiagnostics-parseable-fixits
-stack-protector 1 -mstackrealign -fblocks -fno-rtti -fno-threadsafe-statics
-fobjc-runtime-has-arc -fobjc-runtime-has-weak -fobjc-dispatch-method=mixed
-fobjc-gc -fobjc-exceptions -fexceptions -fpascal-strings
-fdiagnostics-show-option -fdiagnostics-show-category id -o
/Users/kmowery/src/builds/webkit/WebKit/WebKitBuild/WebCore.build/Release/WebCore.build/Objects-normal/x86_64/WebAccessibilityObjectWrapper.o
-x objective-c++
/Users/kmowery/src/builds/webkit/WebKit/Source/WebCore/accessibility/mac/WebAccessibilityObjectWrapper.mm 
1.    <eof> parser at end of file
2.   
/Users/kmowery/src/builds/webkit/WebKit/Source/WebCore/accessibility/mac/WebAccessibilityObjectWrapper.mm:341:1:
LLVM IR generation of declaration
'WebAccessibilityObjectWrapper::initWithAccessibilityObject:'
3.   
/Users/kmowery/src/builds/webkit/WebKit/Source/WebCore/accessibility/mac/WebAccessibilityObjectWrapper.mm:1343:1:
LLVM IR generation of compound statement ('{}')
clang: error: unable to execute command: Illegal instruction: 4
clang: error: clang frontend command failed due to signal (use -v to see
invocation)
clang: note: diagnostic msg: Please submit a bug report to
http://llvm.org/bugs/ and include command line arguments and all diagnostic
information.
clang: note: diagnostic msg: Preprocessed source(s) and associated run
script(s) are located at:
clang: note: diagnostic msg:
/var/folders/2j/4dcc9sy915z774w9789765p00000gn/T/WebAccessibilityObjectWrapper-WfS9Al.mii
clang: note: diagnostic msg:
/var/folders/2j/4dcc9sy915z774w9789765p00000gn/T/WebAccessibilityObjectWrapper-WfS9Al.sh

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 18 20:30:52 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 19 Dec 2011 02:30:52 +0000
Subject: [LLVMbugs] [Bug 8443] named metadata not quotable
In-Reply-To: <bug-8443-206@http.llvm.org/bugs/>
References: <bug-8443-206@http.llvm.org/bugs/>
Message-ID: <bug-8443-206-qGab0Uwx2V@http.llvm.org/bugs/>

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

Nick Lewycky <nicholas at mxc.ca> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |nicholas at mxc.ca
         Resolution|                            |FIXED

--- Comment #2 from Nick Lewycky <nicholas at mxc.ca> 2011-12-18 20:30:52 CST ---
Metadata names still aren't quotable, but they have escaping support for
whitespace characters and whatnot. This is as fixed as it's going to get.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 18 20:33:24 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 19 Dec 2011 02:33:24 +0000
Subject: [LLVMbugs] [Bug 4037] independently control IR optimization and
	fast codegen
In-Reply-To: <bug-4037-206@http.llvm.org/bugs/>
References: <bug-4037-206@http.llvm.org/bugs/>
Message-ID: <bug-4037-206-ySW3JudjSc@http.llvm.org/bugs/>

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

Nick Lewycky <nicholas at mxc.ca> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |nicholas at mxc.ca
         Resolution|                            |FIXED

--- Comment #3 from Nick Lewycky <nicholas at mxc.ca> 2011-12-18 20:33:24 CST ---
-mllvm -disable-llvm-optzns has existed for a while.

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

From bugzilla-daemon at llvm.org  Sun Dec 18 21:00:58 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 19 Dec 2011 03:00:58 +0000
Subject: [LLVMbugs] [Bug 10375] warning on delete object of incomplete type
 missing -W flag
In-Reply-To: <bug-10375-206@http.llvm.org/bugs/>
References: <bug-10375-206@http.llvm.org/bugs/>
Message-ID: <bug-10375-206-OhU2fL5Xt0@http.llvm.org/bugs/>

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

Nick Lewycky <nicholas at mxc.ca> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |nicholas at mxc.ca
         Resolution|                            |FIXED

--- Comment #2 from Nick Lewycky <nicholas at mxc.ca> 2011-12-18 21:00:58 CST ---
The flag is -Wdelete-incomplete.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 18 21:29:35 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 19 Dec 2011 03:29:35 +0000
Subject: [LLVMbugs] [Bug 6720] invalid jump diagnostic refers to deleted Stmt
In-Reply-To: <bug-6720-206@http.llvm.org/bugs/>
References: <bug-6720-206@http.llvm.org/bugs/>
Message-ID: <bug-6720-206-XDxBoygUA3@http.llvm.org/bugs/>

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

Nick Lewycky <nicholas at mxc.ca> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |nicholas at mxc.ca
         Resolution|                            |FIXED

--- Comment #3 from Nick Lewycky <nicholas at mxc.ca> 2011-12-18 21:29:35 CST ---
This no longer crashes.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 19 01:08:35 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 19 Dec 2011 07:08:35 +0000
Subject: [LLVMbugs] [Bug 11603] Missing word in llvm.org main page
In-Reply-To: <bug-11603-206@http.llvm.org/bugs/>
References: <bug-11603-206@http.llvm.org/bugs/>
Message-ID: <bug-11603-206-cbBVKt0dMI@http.llvm.org/bugs/>

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

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-12-19 01:08:35 CST ---
Fixed in r146858, 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 Dec 19 01:10:52 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 19 Dec 2011 07:10:52 +0000
Subject: [LLVMbugs] [Bug 11610] MIPS backend missing from component list
In-Reply-To: <bug-11610-206@http.llvm.org/bugs/>
References: <bug-11610-206@http.llvm.org/bugs/>
Message-ID: <bug-11610-206-qvmHXzdDhI@http.llvm.org/bugs/>

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

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-12-19 01:10:52 CST ---
Added!

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 19 04:04:08 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 19 Dec 2011 10:04:08 +0000
Subject: [LLVMbugs] [Bug 11614] New: Cannot assign in constexpr
	initialization
Message-ID: <bug-11614-206@http.llvm.org/bugs/>

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

             Bug #: 11614
           Summary: Cannot assign in constexpr initialization
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++0x
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: max at duempel.org
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified


struct Foo {};constexpr Foo foo = Foo();

constexpr.cc:1:29: error: constexpr variable 'foo' must be initialized by a
constant expression

The assignment should be allowed, because the value of Foo() is known at
compile time (it doesn't make a difference if I make the struct non-empty and
add an explicit constexpr constructor, by the way).

The following works:

struct Foo {};constexpr Foo foo();

This problem occurs with libstdc++ 4.6 in allocator.h:

  struct allocator_arg_t { };
  constexpr allocator_arg_t allocator_arg = allocator_arg_t();

svn trunk 146862

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 19 05:13:11 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 19 Dec 2011 11:13:11 +0000
Subject: [LLVMbugs] [Bug 11615] New: MIPS backend generates unaligned zero
	stores
Message-ID: <bug-11615-206@http.llvm.org/bugs/>

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

             Bug #: 11615
           Summary: MIPS backend generates unaligned zero stores
           Product: libraries
           Version: trunk
          Platform: All
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: MIPS
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: mans at mansr.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 7761
  --> http://llvm.org/bugs/attachment.cgi?id=7761
Handle unaligned addresses in zero-store pattern

The MIPS backend has a special pattern for storing zeros using the zero
register. This fails to properly handle unaligned addresses.  The attached
patch fixes this.

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

From bugzilla-daemon at llvm.org  Mon Dec 19 06:05:52 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 19 Dec 2011 12:05:52 +0000
Subject: [LLVMbugs] [Bug 11616] New: std::make_shared call will fail to
 compile for a class with a non-copyable member and a non-default
 constructor
Message-ID: <bug-11616-206@http.llvm.org/bugs/>

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

             Bug #: 11616
           Summary: std::make_shared call will fail to compile for a class
                    with a non-copyable member and a non-default
                    constructor
           Product: libc++
           Version: unspecified
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: All Bugs
        AssignedTo: hhinnant at apple.com
        ReportedBy: alexander.bolodurin at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


I've tested with Clang 3.0, but it's probably in the latest too, given that the
release wasn't that far off.

This compiles:
-------------------8<-------------------
#include <memory>

class Foo
{
public:
    Foo()
        : mem_(new int(10))
    {
    }
    std::unique_ptr<int> mem_;
};

int main()
{
    auto foo = std::make_shared<Foo>();
    return 0;
}
-------------------8<-------------------

This doesn't:

-------------------8<-------------------
#include <memory>
#include <string>

class Foo
{
public:
    Foo(const std::string& s)
        : mem_(new int(10))
    {
    }
    std::unique_ptr<int> mem_;
};

int main()
{
    auto foo = std::make_shared<Foo>("aaa");
    return 0;
}
-------------------8<-------------------

The fix to the above is to introduce an explicit move constructor (so it
compiles again):

-------------------8<-------------------
#include <memory>
#include <string>

class Foo
{
public:
    Foo(const std::string& s)
        : mem_(new int(10))
    {
    }
    Foo(Foo&& other)
        : mem_(std::move(other.mem_))
    {
    }
    std::unique_ptr<int> mem_;
};

int main()
{
    auto foo = std::make_shared<Foo>("aaa");
    return 0;
}
-------------------8<-------------------

But the second example should be working fine as far as I can see (gcc happily
accepts 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  Mon Dec 19 11:59:01 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 19 Dec 2011 17:59:01 +0000
Subject: [LLVMbugs] [Bug 11616] std::make_shared call will fail to compile
 for a class with a non-copyable member and a non-default constructor
In-Reply-To: <bug-11616-206@http.llvm.org/bugs/>
References: <bug-11616-206@http.llvm.org/bugs/>
Message-ID: <bug-11616-206-isL6IQNZCc@http.llvm.org/bugs/>

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

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-12-19 11:59:01 CST ---
Fix Committed revision 146881.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 19 13:26:31 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 19 Dec 2011 19:26:31 +0000
Subject: [LLVMbugs] [Bug 11617] New: undefined reference getInstrLatency,
 getOperandLatency (trunk)
Message-ID: <bug-11617-206@http.llvm.org/bugs/>

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

             Bug #: 11617
           Summary: undefined reference getInstrLatency, getOperandLatency
                    (trunk)
           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: fang at csl.cornell.edu
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Since the week of 12/15, I've been getting the following link failure (i'm
building on powerpc-darwin8):

ld: Undefined symbols:
llvm::TargetInstrInfo::getInstrLatency(llvm::InstrItineraryData const*,
llvm::SDNode*) const
llvm::TargetInstrInfo::getOperandLatency(llvm::InstrItineraryData const*,
llvm::SDNode*, unsigned int, llvm::SDNode*, unsigned int) const
/usr/libexec/gcc/powerpc-apple-darwin8/4.0.1/libtool: internal link edit
command failed
make[2]: *** [lib/libLLVMTarget.dylib] Error 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  Mon Dec 19 13:37:58 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 19 Dec 2011 19:37:58 +0000
Subject: [LLVMbugs] [Bug 11617] undefined reference getInstrLatency,
 getOperandLatency (trunk)
In-Reply-To: <bug-11617-206@http.llvm.org/bugs/>
References: <bug-11617-206@http.llvm.org/bugs/>
Message-ID: <bug-11617-206-UDGI7CN1vA@http.llvm.org/bugs/>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |sharparrow1 at yahoo.com
         Resolution|                            |DUPLICATE

--- Comment #2 from Eli Friedman <sharparrow1 at yahoo.com> 2011-12-19 13:37:58 CST ---


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

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 19 15:19:40 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 19 Dec 2011 21:19:40 +0000
Subject: [LLVMbugs] [Bug 5279] attribute 'aligned' silently ignored on
	typedefs
In-Reply-To: <bug-5279-206@http.llvm.org/bugs/>
References: <bug-5279-206@http.llvm.org/bugs/>
Message-ID: <bug-5279-206-fLaFIivgTG@http.llvm.org/bugs/>

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

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-12-19 15:19:40 CST ---
Fixed in r146908, all three tests added to the clang test suite.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 19 15:24:08 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 19 Dec 2011 21:24:08 +0000
Subject: [LLVMbugs] [Bug 11044] clang ignores 'aligned' attribute with
 'vector_size' attribute
In-Reply-To: <bug-11044-206@http.llvm.org/bugs/>
References: <bug-11044-206@http.llvm.org/bugs/>
Message-ID: <bug-11044-206-8biFcQDZtR@http.llvm.org/bugs/>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #7 from Chris Lattner <clattner at apple.com> 2011-12-19 15:24:08 CST ---
This specific test case is corrected in r146908.  If there are other cases, we
should handle them in their own bugs.

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

From bugzilla-daemon at llvm.org  Mon Dec 19 16:03:27 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 19 Dec 2011 22:03:27 +0000
Subject: [LLVMbugs] [Bug 11620] New: Please support HURD & kfreebsd in the
	autotools
Message-ID: <bug-11620-206@http.llvm.org/bugs/>

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

             Bug #: 11620
           Summary: Please support HURD & kfreebsd in the autotools
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: System Library
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: sylvestre at debian.org
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 7764
  --> http://llvm.org/bugs/attachment.cgi?id=7764
KfreeBSD & HURD support

I would be nice if you could apply the small patch attached. It allows the
configure to succeeded under Debian KfreeBSD and GNU/Hurd.

PS: There is no component in the bug tracker for such kind of bug.

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

From bugzilla-daemon at llvm.org  Mon Dec 19 16:27:57 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 19 Dec 2011 22:27:57 +0000
Subject: [LLVMbugs] [Bug 11607] undefined references in libLLVMTarget.so
In-Reply-To: <bug-11607-206@http.llvm.org/bugs/>
References: <bug-11607-206@http.llvm.org/bugs/>
Message-ID: <bug-11607-206-A7nkmJOiby@http.llvm.org/bugs/>

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

Ryuta Suzuki <oroppas at gmail.com> changed:

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

--- Comment #7 from Ryuta Suzuki <oroppas at gmail.com> 2011-12-19 16:27:57 CST ---
Yep. It does fix the issue. Thanks all.

(In reply to comment #6)
> I took a shot with r146897; does that fix the issue?

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

From bugzilla-daemon at llvm.org  Mon Dec 19 16:32:36 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 19 Dec 2011 22:32:36 +0000
Subject: [LLVMbugs] [Bug 11621] New: Clang does not properly implement
 -Woverloaded-virtual
Message-ID: <bug-11621-206@http.llvm.org/bugs/>

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

             Bug #: 11621
           Summary: Clang does not properly implement -Woverloaded-virtual
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: chandlerc at gmail.com
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified


% cat x.cc
struct Base {
  virtual void f(int);
  virtual void f(float);
};

struct Dervied : Base {
  virtual void f(int);
};

% ./bin/clang -fsyntax-only -Woverloaded-virtual x.cc

% gcc -fsyntax-only -Woverloaded-virtual x.cc
x.cc:3:16: warning: 'virtual void Base::f(float)' was hidden
[-Woverloaded-virtual]
x.cc:7:16: warning:   by 'virtual void Dervied::f(int)' [-Woverloaded-virtual]


This warning has a very high value. I don't even know why it isn't in -Wall. =[

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 19 18:04:36 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 20 Dec 2011 00:04:36 +0000
Subject: [LLVMbugs] [Bug 11519] "GEP is not of right type for indices!"
In-Reply-To: <bug-11519-206@http.llvm.org/bugs/>
References: <bug-11519-206@http.llvm.org/bugs/>
Message-ID: <bug-11519-206-phr1zodWob@http.llvm.org/bugs/>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #7 from Chris Lattner <clattner at apple.com> 2011-12-19 18:04:36 CST ---
Fixed in r146929.  I really *really really* appreciate the reduced test case,
thank you!

-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  Mon Dec 19 18:12:49 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 20 Dec 2011 00:12:49 +0000
Subject: [LLVMbugs] [Bug 11464] LinkModules fails to remap types
In-Reply-To: <bug-11464-206@http.llvm.org/bugs/>
References: <bug-11464-206@http.llvm.org/bugs/>
Message-ID: <bug-11464-206-GQ7bsaPvA8@http.llvm.org/bugs/>

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

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-12-19 18:12:49 CST ---
Fixed in r146932.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 19 18:21:50 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 20 Dec 2011 00:21:50 +0000
Subject: [LLVMbugs] [Bug 11622] New: A bunch of checks are missing for
 defaulted functions
Message-ID: <bug-11622-206@http.llvm.org/bugs/>

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

             Bug #: 11622
           Summary: A bunch of checks are missing for defaulted functions
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: C++0x
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: sharparrow1 at yahoo.com
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Per [dcl.fct.def.default]p2, a defaulted function must be public, non-explicit,
non-virtual, and must use constexpr appropriately.  We perform none of these
checks.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 19 19:45:57 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 20 Dec 2011 01:45:57 +0000
Subject: [LLVMbugs] [Bug 11571] Instruction does not dominate all uses! PHI
 nodes not grouped at top of basic block!
In-Reply-To: <bug-11571-206@http.llvm.org/bugs/>
References: <bug-11571-206@http.llvm.org/bugs/>
Message-ID: <bug-11571-206-inpJwPk9Cq@http.llvm.org/bugs/>

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

Andrew Trick <atrick at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
          Component|Backend: X86                |Backend: SystemZ
         Resolution|                            |FIXED

--- Comment #6 from Andrew Trick <atrick at apple.com> 2011-12-19 19:45:57 CST ---
Another corner case in LSR's expansion of postinc users.
Fixed in r146950.
Test in r146951.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 19 19:49:32 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 20 Dec 2011 01:49:32 +0000
Subject: [LLVMbugs] [Bug 10515] LoopPasses incorrectly update LoopInfo after
 removing a backedge.
In-Reply-To: <bug-10515-206@http.llvm.org/bugs/>
References: <bug-10515-206@http.llvm.org/bugs/>
Message-ID: <bug-10515-206-o6fYTfWYHD@http.llvm.org/bugs/>

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

Andrew Trick <atrick at apple.com> changed:

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

--- Comment #1 from Andrew Trick <atrick at apple.com> 2011-12-19 19:49:32 CST ---
Initial fix: r137341
Tests: r137385
Bug Fix: r138622
Bug Fix: r144970

It seems pretty stable now :)

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

From bugzilla-daemon at llvm.org  Mon Dec 19 19:50:47 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 20 Dec 2011 01:50:47 +0000
Subject: [LLVMbugs] [Bug 11601] Range-based for cannot iterate over
 explicitly typed function pointers
In-Reply-To: <bug-11601-206@http.llvm.org/bugs/>
References: <bug-11601-206@http.llvm.org/bugs/>
Message-ID: <bug-11601-206-LTnglnCDOQ@http.llvm.org/bugs/>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

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

--- Comment #2 from Eli Friedman <sharparrow1 at yahoo.com> 2011-12-19 19:50:47 CST ---
r146953.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 20 03:11:46 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 20 Dec 2011 09:11:46 +0000
Subject: [LLVMbugs] [Bug 10294] Release tarballs are signed with a key that
 is nowhere to be found
In-Reply-To: <bug-10294-206@http.llvm.org/bugs/>
References: <bug-10294-206@http.llvm.org/bugs/>
Message-ID: <bug-10294-206-j2RAzUZnk4@http.llvm.org/bugs/>

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

Bill Wendling <wendling at apple.com> changed:

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

--- Comment #3 from Bill Wendling <wendling at apple.com> 2011-12-20 03:11:46 CST ---
I uploaded the public key to the php.mit.edu key server. Please give it another
go.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 20 03:45:15 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 20 Dec 2011 09:45:15 +0000
Subject: [LLVMbugs] [Bug 11623] New: "GEP is not of right type for indices!"
	(again)
Message-ID: <bug-11623-206@http.llvm.org/bugs/>

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

             Bug #: 11623
           Summary: "GEP is not of right type for indices!" (again)
           Product: tools
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: llvm-link
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: max at duempel.org
                CC: llvmbugs at cs.uiuc.edu
        Depends on: 11519
    Classification: Unclassified


I found another way to trigger bug 11519 with svn trunk 146960:

touch bar.ll && clang++ -std=c++0x -emit-llvm -c -o foo.bc foo.cxx && llvm-link
-o output.bc bar.ll  foo.bc

Error message:GEP is not of right type for indices!
  %coerce.dive = getelementptr %struct.Foo* %agg.tmp, i32 0, i32 0
 %"type 0x2493a60"*Instruction does not dominate all uses!
  %coerce.dive = getelementptr %struct.Foo* %agg.tmp, i32 0, i32 0
  %3 = load %"struct.Foo::Dummy1"** %coerce.dive
Instruction does not dominate all uses!
  %3 = load %"struct.Foo::Dummy1"** %coerce.dive
  %call2 = call i64 @_ZNKSt4hashI3FooEclES0_(%"struct.std::hash"* %_M_h1,
%"struct.Foo::Dummy1"* %3)
Instruction does not dominate all uses!
  %call2 = call i64 @_ZNKSt4hashI3FooEclES0_(%"struct.std::hash"* %_M_h1,
%"struct.Foo::Dummy1"* %3)
  %call3 = call i64
@_ZNKSt8__detail18_Mod_range_hashingclEmm(%"struct.std::__detail::_Mod_range_hashing"*
%_M_h2, i64 %call2, i64 %4)
Instruction does not dominate all uses!
  %call3 = call i64
@_ZNKSt8__detail18_Mod_range_hashingclEmm(%"struct.std::__detail::_Mod_range_hashing"*
%_M_h2, i64 %call2, i64 %4)
  ret i64 %call3
Broken module found, compilation aborted!
0  llvm-link       0x000000000057591f
1  llvm-link       0x0000000000575e39
2  libpthread.so.0 0x00007f7c94431030
3  libc.so.6       0x00007f7c9372e405 gsignal + 53
4  libc.so.6       0x00007f7c93731680 abort + 384
5  llvm-link       0x000000000052ec89
6  llvm-link       0x000000000052dcc6
7  llvm-link       0x000000000051a67f
8  llvm-link       0x000000000051a90b
9  llvm-link       0x000000000051aa5a
10 llvm-link       0x000000000051b041
11 llvm-link       0x000000000051b54a
12 llvm-link       0x000000000052d48f
13 llvm-link       0x00000000004066eb
14 libc.so.6       0x00007f7c9371aead __libc_start_main + 253
15 llvm-link       0x0000000000405ff9
Stack dump:
0.      Program arguments: llvm-link -o output.bc bar.ll foo.bc 
1.      Running pass 'Function Pass Manager' on module 'bar.ll'.
2.      Running pass 'Module Verifier' on function
'@_ZNKSt8__detail15_Hash_code_baseI3FooSt4pairIKS1_PN3BarILi2EE6Dummy2EESt10_Select1stIS8_ESt8equal_toIS1_ESt4hashIS1_ENS_18_Mod_range_hashingENS_20_Default_ranged_hashELb0EE15_M_bucket_indexEPKNS_10_Hash_nodeIS8_Lb0EEEm'
Aborted

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

From bugzilla-daemon at llvm.org  Tue Dec 20 06:22:28 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 20 Dec 2011 12:22:28 +0000
Subject: [LLVMbugs] [Bug 11519] "GEP is not of right type for indices!"
In-Reply-To: <bug-11519-206@http.llvm.org/bugs/>
References: <bug-11519-206@http.llvm.org/bugs/>
Message-ID: <bug-11519-206-emuydkMjSi@http.llvm.org/bugs/>

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

Stepan Dyatkovskiy <stpworld at narod.ru> 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  Tue Dec 20 06:50:51 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 20 Dec 2011 12:50:51 +0000
Subject: [LLVMbugs] [Bug 11624] New: LTO fails to remove strlen calls on
 static const strings from a separate TU
Message-ID: <bug-11624-206@http.llvm.org/bugs/>

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

             Bug #: 11624
           Summary: LTO fails to remove strlen calls on static const
                    strings from a separate TU
           Product: clang
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: LLVM Codegen
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: dsaritz at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 7772
  --> http://llvm.org/bugs/attachment.cgi?id=7772
testcase

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

From bugzilla-daemon at llvm.org  Tue Dec 20 08:11:53 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 20 Dec 2011 14:11:53 +0000
Subject: [LLVMbugs] [Bug 11625] New: Excessive inlinine with Os
Message-ID: <bug-11625-206@http.llvm.org/bugs/>

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

             Bug #: 11625
           Summary: Excessive inlinine with Os
           Product: clang
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: LLVM Codegen
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: dsaritz at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 7775
  --> http://llvm.org/bugs/attachment.cgi?id=7775
codegen

As the codegen shows, clang -Os -flto -m32 -lstdc++ inlines test_function()
even though it is clearly larger than the cost of the call and it is called
more than once.
Even adding -fno-inline -fno-inline-functions options makes no difference.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 20 09:50:37 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 20 Dec 2011 15:50:37 +0000
Subject: [LLVMbugs] [Bug 11613] Assertion Failed:
 (D->isThisDeclarationADefinition() && "Invalid interface decl!"),
 function getObjCLayout, file
 /Users/kmowery/src/builds/llvm-svn/llvm/tools/clang/lib/AST/RecordLayoutBuilder.cpp,
 line 2164.
In-Reply-To: <bug-11613-206@http.llvm.org/bugs/>
References: <bug-11613-206@http.llvm.org/bugs/>
Message-ID: <bug-11613-206-2zuyxdRUC3@http.llvm.org/bugs/>

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

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-12-20 09:50:37 CST ---
Fixed in Clang r146976.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 20 13:28:44 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 20 Dec 2011 19:28:44 +0000
Subject: [LLVMbugs] [Bug 11626] New: linker munges types,
	produces invalid IR from valid
Message-ID: <bug-11626-206@http.llvm.org/bugs/>

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

             Bug #: 11626
           Summary: linker munges types, produces invalid IR from valid
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Core LLVM classes
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: nicholas at mxc.ca
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 7778
  --> http://llvm.org/bugs/attachment.cgi?id=7778
testcase (7.bc)

The attached .bc file is valid:

  $ opt -disable-output -verify 7.bc
  $

but linking it against nothing causes it to break:

  $ touch empty.ll
  $ llvm-link empty.ll 7.bc -o x.bc
  Load result type does not match pointer operand type!
    %t294 = load %0** undef, align 8
   %"type 0x86c4b0"*Broken module found, compilation aborted!
  0  llvm-link       0x0000000000649fba
  1  llvm-link       0x0000000000649db6
  2  libpthread.so.0 0x00007fc244b1b020
  3  libc.so.6       0x00007fc243e1a405 gsignal + 53
  4  libc.so.6       0x00007fc243e1d680 abort + 384
  5  llvm-link       0x00000000005f28c9
  6  llvm-link       0x00000000005f25b3
  7  llvm-link       0x00000000005d111f
  8  llvm-link       0x00000000005d1363
  9  llvm-link       0x00000000005d16a3
  10 llvm-link       0x00000000005d1ba8
  11 llvm-link       0x00000000005d1f9b
  12 llvm-link       0x0000000000603a0c
  13 llvm-link       0x0000000000407848
  14 libc.so.6       0x00007fc243e06ead __libc_start_main + 253
  15 llvm-link       0x0000000000406fe9
  Stack dump:
  0.    Program arguments: llvm-commit/Debug+Asserts/bin/llvm-link empty.ll
7.bc 
  1.    Running pass 'Function Pass Manager' on module 'empty.ll'.
  2.    Running pass 'Module Verifier' on function '@_Z7yyparsev_zzz'

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 20 13:33:45 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 20 Dec 2011 19:33:45 +0000
Subject: [LLVMbugs] [Bug 11519] "GEP is not of right type for indices!"
In-Reply-To: <bug-11519-206@http.llvm.org/bugs/>
References: <bug-11519-206@http.llvm.org/bugs/>
Message-ID: <bug-11519-206-5T8sVPHxXL@http.llvm.org/bugs/>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

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

--- Comment #9 from Eli Friedman <sharparrow1 at yahoo.com> 2011-12-20 13:33:45 CST ---
New issue, new bug 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 Dec 20 13:40:26 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 20 Dec 2011 19:40:26 +0000
Subject: [LLVMbugs] [Bug 11627] New: llvm-link links functions with same
 name but with different parameters set
Message-ID: <bug-11627-206@http.llvm.org/bugs/>

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

             Bug #: 11627
           Summary: llvm-link links functions with same name but with
                    different parameters set
           Product: tools
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: llvm-link
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: stpworld at narod.ru
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 7779
  --> http://llvm.org/bugs/attachment.cgi?id=7779
Draft patch

llvm-link links functions with same name but with different parameters set.

consider two files:

; 1.ll:
declare i32 @bug_a(%struct.bug_type*)
declare i32 @bug_b(%struct.bug_type*)
define i32 @bug_c(%struct.bug_type* %var) nounwind uwtable {
entry:
  %res = call i32 @bug_b(%struct.bug_type* %var)
  ret i32 0
}

; 2.ll:
%bar1 = type { i16 }

%bar2 = type { i32 }

define i32 @bug_a(%bar1* %fp) nounwind uwtable {
entry:
  %d_stream = getelementptr inbounds %bar1* %fp, i64 0, i32 0
  ret i32 0
}
define i32 @bug_b(%bar2* %a) nounwind uwtable {
entry:
  ret i32 0
}

"llvm-link -S 1.ll 2.ll" will produces the next:

%bar1 = type { i16 }
%bar2 = type { i32 }

define i32 @bug_c(%bar1* %var) nounwind uwtable {
entry:
  %res = call i32 bitcast (i32 (%bar2*)* @bug_b to i32 (%bar1*)*)(%bar1* %var)
  ret i32 0
}

define i32 @bug_a(%bar1* %fp) nounwind uwtable {
entry:
  %d_stream = getelementptr inbounds %bar1* %fp, i64 0, i32 0
  ret i32 0
}

define i32 @bug_b(%bar2* %a) nounwind uwtable {
entry:
  ret i32 0
}

bar_c is wrong here.

I attached the patch that fixes this problem, but I still have two failed
tests. By now I'm thinking how to fix all of them...

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 20 13:46:10 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 20 Dec 2011 19:46:10 +0000
Subject: [LLVMbugs] [Bug 11602] i386 bootstrap failure on OpenBSD
In-Reply-To: <bug-11602-206@http.llvm.org/bugs/>
References: <bug-11602-206@http.llvm.org/bugs/>
Message-ID: <bug-11602-206-JQNyosHxcZ@http.llvm.org/bugs/>

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

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-12-20 13:46:10 CST ---
Essentially, X86JITInfo.cpp is buggy, and we give a low-quality 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  Tue Dec 20 14:34:49 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 20 Dec 2011 20:34:49 +0000
Subject: [LLVMbugs] [Bug 11599] Crash on invalid with
 TSK_ExplicitInstantiationDefinition after an invalid
 TSK_ExplicitInstantiationDeclaration
In-Reply-To: <bug-11599-206@http.llvm.org/bugs/>
References: <bug-11599-206@http.llvm.org/bugs/>
Message-ID: <bug-11599-206-esEgkjOAAa@http.llvm.org/bugs/>

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

Nico Weber <nicolasweber at gmx.de> changed:

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

--- Comment #4 from Nico Weber <nicolasweber at gmx.de> 2011-12-20 14:34:49 CST ---
r146988

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 20 16:56:45 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 20 Dec 2011 22:56:45 +0000
Subject: [LLVMbugs] [Bug 11297] Bad diagnostic for range for loop with
	non-declaration
In-Reply-To: <bug-11297-206@http.llvm.org/bugs/>
References: <bug-11297-206@http.llvm.org/bugs/>
Message-ID: <bug-11297-206-vvGy6RgfVA@http.llvm.org/bugs/>

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

Richard Smith <richard-llvm at metafoo.co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |richard-llvm at metafoo.co.uk
         Resolution|                            |FIXED

--- Comment #1 from Richard Smith <richard-llvm at metafoo.co.uk> 2011-12-20 16:56:45 CST ---
As of r147006, we now produce:

test/Parser/cxx0x-for-range.cpp:24:18: error: for range declaration must
declare
      a variable
  for (tie(p, n) : m) {
       ~~~~~~~~~ ^

I do wonder whether we should propose an extension to allow a "for (expression
: expression)" form of the for-range-statement. Cases like this give me pause:

template<typename In, typename Out>
Out copy(In I, In IEnd, Out O) {
  for (*O++ : range(I, IEnd));
  return O;
}

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 20 17:09:58 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 20 Dec 2011 23:09:58 +0000
Subject: [LLVMbugs] [Bug 11629] New:
 SingleSource/Benchmarks/BenchmarkGame/puzzle use of rand() + golden file is
 not libc agnostic
Message-ID: <bug-11629-206@http.llvm.org/bugs/>

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

             Bug #: 11629
           Summary: SingleSource/Benchmarks/BenchmarkGame/puzzle use of
                    rand() + golden file is not libc agnostic
           Product: Test Suite
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Programs Tests
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: jvoung at google.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


The "puzzle" test uses rand() and rand() is not standardized (only an "example
of an implementation" is given in the manpage). Thus, if a system uses a
different libc (e.g., newlib), then the output will not match the golden file.

If the benchmark is changed to use a fixed "myrand()" and "mysrand()", then the
benchmark will be consistent on different systems. If myrand() is the exact
example given in the manpage, then the golden file would not need to be
changed. Hopefully the performance numbers don't change much either.

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

From bugzilla-daemon at llvm.org  Tue Dec 20 18:35:12 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 21 Dec 2011 00:35:12 +0000
Subject: [LLVMbugs] [Bug 11615] MIPS backend generates unaligned zero stores
In-Reply-To: <bug-11615-206@http.llvm.org/bugs/>
References: <bug-11615-206@http.llvm.org/bugs/>
Message-ID: <bug-11615-206-NtuiJXkGP8@http.llvm.org/bugs/>

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

Akira Hatanaka <ahatanak at gmail.com> changed:

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

--- Comment #3 from Akira Hatanaka <ahatanak at gmail.com> 2011-12-20 18:35:12 CST ---
The patch and test case (with modification) were committed in r147024.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 20 18:36:02 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 21 Dec 2011 00:36:02 +0000
Subject: [LLVMbugs] [Bug 11623] "GEP is not of right type for indices!"
	(again)
In-Reply-To: <bug-11623-206@http.llvm.org/bugs/>
References: <bug-11623-206@http.llvm.org/bugs/>
Message-ID: <bug-11623-206-VpncjYXKqg@http.llvm.org/bugs/>

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

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-12-20 18:36:02 CST ---
Woot, thanks.  Sorry for the breakage.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 20 18:51:54 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 21 Dec 2011 00:51:54 +0000
Subject: [LLVMbugs] [Bug 11630] New: Clang fails to detect that two types
 are the same in a template
Message-ID: <bug-11630-206@http.llvm.org/bugs/>

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

             Bug #: 11630
           Summary: Clang fails to detect that two types are the same in a
                    template
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: rafael.espindola at gmail.com
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified


clang fails to accept this:

template <class T>
struct S
{
  static const unsigned C = 1;
  static void f()
  {
    typedef int q[C == 1 ? 1 : -1];
    typedef int q[C >= 1 ? 1 : -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  Tue Dec 20 18:55:53 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 21 Dec 2011 00:55:53 +0000
Subject: [LLVMbugs] [Bug 11631] New: Static analyzer ignores goto statement
Message-ID: <bug-11631-206@http.llvm.org/bugs/>

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

             Bug #: 11631
           Summary: Static analyzer ignores goto statement
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Static Analyzer
        AssignedTo: kremenek at apple.com
        ReportedBy: gregory.szorc at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 7781
  --> http://llvm.org/bugs/attachment.cgi?id=7781
Report showing ignored goto statement

The attached report shows an apparent bug in the static analyzer where a goto
statement in an if statement is supposed to be taken but seems to be ignored by
the static analyzer.

The trouble starts at:

  343 if(codes==NULL)goto err_out;

    5 Assuming 'codes' is equal to null
    6 Taking false branch

Statements 5 and 6 made by the analyzer appear to be contradictory. The
analyzer continues past the goto to report an error that should not occur.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 20 18:59:17 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 21 Dec 2011 00:59:17 +0000
Subject: [LLVMbugs] [Bug 11587] clang-trunk segfaults when building
 make_aisleriot_freecell_board.c
In-Reply-To: <bug-11587-206@http.llvm.org/bugs/>
References: <bug-11587-206@http.llvm.org/bugs/>
Message-ID: <bug-11587-206-3SLyZChjoV@http.llvm.org/bugs/>

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

Andrew Trick <atrick at apple.com> changed:

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

--- Comment #6 from Andrew Trick <atrick at apple.com> 2011-12-20 18:59:17 CST ---
Indeed fixed by r146950.

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

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 20 19:00:47 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 21 Dec 2011 01:00:47 +0000
Subject: [LLVMbugs] [Bug 11525] Segmentation fault on simple C99 source
In-Reply-To: <bug-11525-206@http.llvm.org/bugs/>
References: <bug-11525-206@http.llvm.org/bugs/>
Message-ID: <bug-11525-206-dObdYrzBXr@http.llvm.org/bugs/>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |sharparrow1 at yahoo.com
         Resolution|                            |WORKSFORME

--- Comment #3 from Eli Friedman <sharparrow1 at yahoo.com> 2011-12-20 19:00:47 CST ---
There were many fixes between LLVM 2.9 and 3.0; you can probably bisect it if
you really need to know for some 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  Tue Dec 20 19:22:13 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 21 Dec 2011 01:22:13 +0000
Subject: [LLVMbugs] [Bug 11626] linker munges types,
	produces invalid IR from valid
In-Reply-To: <bug-11626-206@http.llvm.org/bugs/>
References: <bug-11626-206@http.llvm.org/bugs/>
Message-ID: <bug-11626-206-5d7IPqUHM8@http.llvm.org/bugs/>

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

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-12-20 19:22:13 CST ---
This should be fixed by r 147010

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 20 19:24:43 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 21 Dec 2011 01:24:43 +0000
Subject: [LLVMbugs] [Bug 11627] llvm-link links functions with same name but
 with different parameters set
In-Reply-To: <bug-11627-206@http.llvm.org/bugs/>
References: <bug-11627-206@http.llvm.org/bugs/>
Message-ID: <bug-11627-206-GwXuUI3LrH@http.llvm.org/bugs/>

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

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-12-20 19:24:43 CST ---
Specifically, the IR linker emulates the behavior you'd get if you used a
native linker.  It must insert bit casts to make the IR correctly formed when a
non-type-safe link like this happens.  It is not acceptable for the linker to
fail, or not link two functions, because of their IR types.

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

From bugzilla-daemon at llvm.org  Tue Dec 20 20:48:51 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 21 Dec 2011 02:48:51 +0000
Subject: [LLVMbugs] [Bug 11632] New: -Wmismatched-tags bogus warning that
 class != struct
Message-ID: <bug-11632-206@http.llvm.org/bugs/>

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

             Bug #: 11632
           Summary: -Wmismatched-tags bogus warning that class != struct
           Product: clang
           Version: unspecified
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: kilobyte at angband.pl
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified


class foo;
struct foo {int a;};

warning: class 'foo' was previously declared as a struct [-Wmismatched-tags]

Interchangeably referring to classes and structs by either name is explicitly
allowed by C++98 7.1.5.3/3 = C++11 7.1.6.3/3.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 20 20:55:35 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 21 Dec 2011 02:55:35 +0000
Subject: [LLVMbugs] [Bug 11632] -Wmismatched-tags bogus warning that class
	!= struct
In-Reply-To: <bug-11632-206@http.llvm.org/bugs/>
References: <bug-11632-206@http.llvm.org/bugs/>
Message-ID: <bug-11632-206-2KvAkRSmZb@http.llvm.org/bugs/>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |sharparrow1 at yahoo.com
         Resolution|                            |INVALID

--- Comment #1 from Eli Friedman <sharparrow1 at yahoo.com> 2011-12-20 20:55:35 CST ---
It's a warning in the sense of "you might not want to do this", not that it's
invalid C++.  Also, it isn't turned on by default.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 21 02:35:38 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 21 Dec 2011 08:35:38 +0000
Subject: [LLVMbugs] [Bug 11633] New: Binary identical template
 instantiations are not merged
Message-ID: <bug-11633-206@http.llvm.org/bugs/>

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

             Bug #: 11633
           Summary: Binary identical template instantiations are not
                    merged
           Product: clang
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: LLVM Codegen
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: dsaritz at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 7782
  --> http://llvm.org/bugs/attachment.cgi?id=7782
testcase

Function templates instantiated for different integral types that produce
identical code are not merged into a single function.
In the attached example this is demonstrated for int and an enum type.
Codegen produced with clang -Os -std=gnu++0x -flto -m32 -lstdc++ -ffast-math.

Sometimes clang even produces very slightly different code for example for
unsigned int and enum instantiations of certain functions for which MSVC
generates identical code and merges the functions.

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

From bugzilla-daemon at llvm.org  Wed Dec 21 03:12:51 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 21 Dec 2011 09:12:51 +0000
Subject: [LLVMbugs] [Bug 11634] New: -faltivec ignored by the driver
Message-ID: <bug-11634-206@http.llvm.org/bugs/>

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

             Bug #: 11634
           Summary: -faltivec ignored by the driver
           Product: clang
           Version: trunk
          Platform: Other
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: michael.kostylev at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


The driver does not forward the -faltivec option to clang -cc1:

% clang -m32 -faltivec test.c
clang: warning: argument unused during compilation: '-faltivec'
test.c:1:20: error: use of undeclared identifier 'vector'
int main (void) { (vector int) {1}; return 0; }
                   ^
1 error generated.

At a first look, clang/include/clang/Driver/Options.td and
clang/lib/Driver/Tools.cpp simply lack required entries.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 21 08:38:12 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 21 Dec 2011 14:38:12 +0000
Subject: [LLVMbugs] [Bug 11635] New: Compiling llvm in VC++11 fails.
Message-ID: <bug-11635-206@http.llvm.org/bugs/>

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

             Bug #: 11635
           Summary: Compiling llvm in VC++11 fails.
           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: niobium93 at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Visual Studio 2011 Developer Preview reports an error in file
lib/CodeGen/AsmPrinter
This is the error:
E:\Documents\Projects\llvm\lib\CodeGen\AsmPrinter\DwarfDebug.cpp(534): error
C2668: 'llvm::tie' : ambiguous call to overloaded function
          E:\Documents\Projects\llvm\include\llvm/ADT/STLExtras.h(206): could
be 'llvm::tier<T1,T2> llvm::tie<std::_Tree_iterator<_Mytree>,bool>(T1 &,T2 &)'
          with
          [
             
T1=std::_Tree_iterator<std::_Tree_val<std::_Tree_simple_types<std::pair<const
std::pair<std::string,std::string>,unsigned int>>>>,
              T2=bool,
              _Mytree=std::_Tree_val<std::_Tree_simple_types<std::pair<const
std::pair<std::string,std::string>,unsigned int>>>
          ]
          C:\Program Files (x86)\Microsoft Visual Studio
11.0\VC\include\tuple(690): or      
'std::tuple<<unnamed-symbol>,_V0_t,_V1_t,_V2_t,_V3_t,_V4_t,_V5_t,std::_Nil>
std::tie<std::_Tree_iterator<_Mytree>,bool>(std::_Tree_iterator<_Mytree> &,bool
&)' [found using argument-dependent lookup]
          with
          [
             
<unnamed-symbol>=std::_Tree_iterator<std::_Tree_val<std::_Tree_simple_types<std::pair<const
std::pair<std::string,std::string>,unsigned int>>>> &,
              _V0_t=bool &,
              _V1_t=std::_Nil,
              _V2_t=std::_Nil,
              _V3_t=std::_Nil,
              _V4_t=std::_Nil,
              _V5_t=std::_Nil,
              _Mytree=std::_Tree_val<std::_Tree_simple_types<std::pair<const
std::pair<std::string,std::string>,unsigned int>>>
          ]
          while trying to match the argument list
'(std::_Tree_iterator<_Mytree>, bool)'
          with
          [
              _Mytree=std::_Tree_val<std::_Tree_simple_types<std::pair<const
std::pair<std::string,std::string>,unsigned 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  Wed Dec 21 12:10:01 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 21 Dec 2011 18:10:01 +0000
Subject: [LLVMbugs] [Bug 11631] Static analyzer ignores goto statement
In-Reply-To: <bug-11631-206@http.llvm.org/bugs/>
References: <bug-11631-206@http.llvm.org/bugs/>
Message-ID: <bug-11631-206-5oqJPJs2Au@http.llvm.org/bugs/>

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

Ted Kremenek <kremenek at apple.com> changed:

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

--- Comment #2 from Ted Kremenek <kremenek at apple.com> 2011-12-21 12:10:01 CST ---
I think this was an issue with the output of the diagnostics, not the actual
reasoning.  I believe this is fixed with:

http://llvm.org/viewvc/llvm-project?view=rev&revision=146993

Please reopen if this is still an issue.

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

From bugzilla-daemon at llvm.org  Wed Dec 21 14:18:44 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 21 Dec 2011 20:18:44 +0000
Subject: [LLVMbugs] [Bug 11636] New: Double-release from ARC when inlining C
	functions
Message-ID: <bug-11636-206@http.llvm.org/bugs/>

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

             Bug #: 11636
           Summary: Double-release from ARC when inlining C functions
           Product: clang
           Version: 3.0
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: paul.q.stevenson at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 7785
  --> http://llvm.org/bugs/attachment.cgi?id=7785
Source file that generates a double release

The attached file generates a double release when compiled with -O2 and
inlining InlineCFunc inside CFunc. The problem can't be reproduced with pure
objc code due to the lack of inlining.

In the example code, when InlineCFunc() returns false, label 20 is taken which
releases the object and then calls the .critedge cleanup code, which also
releases the object. When InlineCFunc() returns true, .critedge is jumped to
directly, resulting in just a single release.

This is about as minimal a reproduction of the original problem as I can manage
- simplifying this example in any way seems to stop the double-release from
being 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 Dec 21 14:20:18 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 21 Dec 2011 20:20:18 +0000
Subject: [LLVMbugs] [Bug 10153] clang preprocessor crashes when using -E -CC
 option on MFC code.
In-Reply-To: <bug-10153-206@http.llvm.org/bugs/>
References: <bug-10153-206@http.llvm.org/bugs/>
Message-ID: <bug-10153-206-Jf3vOvmi1m@http.llvm.org/bugs/>

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

Argyrios Kyrtzidis <akyrtzi at gmail.com> changed:

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

--- Comment #4 from Argyrios Kyrtzidis <akyrtzi at gmail.com> 2011-12-21 14:20:18 CST ---
Fixed in r147091.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 21 16:34:48 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 21 Dec 2011 22:34:48 +0000
Subject: [LLVMbugs] [Bug 11637] New: C++11 crash with constexpr constructor
 and string literal
Message-ID: <bug-11637-206@http.llvm.org/bugs/>

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

             Bug #: 11637
           Summary: C++11 crash with constexpr constructor and string
                    literal
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: C++0x
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: sharparrow1 at yahoo.com
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu,
                    richard-llvm at metafoo.co.uk
    Classification: Unclassified


Testcase:

struct A { char a[4]; constexpr A() : a{"foo"} {} };
constexpr int x = A().a[0];

Result:

Assertion failed: (Result.Val.isInt() && "pointer cast to int is not an ICE"),
function EvaluateCPlusPlus11IntegralConstantExpr, file
/Volumes/storage/llvm/tools/clang/lib/AST/ExprConstant.cpp, line 5367.

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

From bugzilla-daemon at llvm.org  Wed Dec 21 16:58:41 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 21 Dec 2011 22:58:41 +0000
Subject: [LLVMbugs] [Bug 11636] Double-release from ARC when inlining C
	functions
In-Reply-To: <bug-11636-206@http.llvm.org/bugs/>
References: <bug-11636-206@http.llvm.org/bugs/>
Message-ID: <bug-11636-206-08EFLyyZAq@http.llvm.org/bugs/>

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

Dan Gohman <gohman at apple.com> changed:

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

--- Comment #5 from Dan Gohman <gohman at apple.com> 2011-12-21 16:58:41 CST ---
Confirmed.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 21 19:01:14 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 22 Dec 2011 01:01:14 +0000
Subject: [LLVMbugs] [Bug 11631] Static analyzer ignores goto statement
In-Reply-To: <bug-11631-206@http.llvm.org/bugs/>
References: <bug-11631-206@http.llvm.org/bugs/>
Message-ID: <bug-11631-206-kcj0oLteET@http.llvm.org/bugs/>

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

Gregory Szorc <gregory.szorc at gmail.com> changed:

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

--- Comment #3 from Gregory Szorc <gregory.szorc at gmail.com> 2011-12-21 19:01:14 CST ---
The issue persists with r147091.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 21 20:09:37 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 22 Dec 2011 02:09:37 +0000
Subject: [LLVMbugs] [Bug 11638] New: False positive "called function pointer
 is null" after assuming variable not null
Message-ID: <bug-11638-206@http.llvm.org/bugs/>

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

             Bug #: 11638
           Summary: False positive "called function pointer is null" after
                    assuming variable not null
           Product: clang
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Static Analyzer
        AssignedTo: kremenek at apple.com
        ReportedBy: gregory.szorc at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 7787
  --> http://llvm.org/bugs/attachment.cgi?id=7787
Report showing ignored non-null assumption

On r147091, I'm seeing a false positive for a null dereference on a function
pointer that has already been assumed to be non-null. Incorrect report is
attached.

This seems like bug 4558, but scan-build says '-store region' (the recommended
resolution to that bug) is the default. I also don't think it is bug 9828
because the static analyzer explicitly states the value is non-null then
complains about a null dereference. (Although in this case the assert macro in
this source does not abort program execution. However, this particular report
assumes the value is non-null, which contradicts the null dereference.)

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 21 20:24:09 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 22 Dec 2011 02:24:09 +0000
Subject: [LLVMbugs] [Bug 11637] C++11 crash with constexpr constructor and
 string literal
In-Reply-To: <bug-11637-206@http.llvm.org/bugs/>
References: <bug-11637-206@http.llvm.org/bugs/>
Message-ID: <bug-11637-206-YHND4t7hVZ@http.llvm.org/bugs/>

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

Richard Smith <richard-llvm at metafoo.co.uk> changed:

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

--- Comment #1 from Richard Smith <richard-llvm at metafoo.co.uk> 2011-12-21 20:24:09 CST ---
Fixed in r147120.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 21 20:24:55 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 22 Dec 2011 02:24:55 +0000
Subject: [LLVMbugs] [Bug 11614] implement marking of defaulted special
 members as constexpr
In-Reply-To: <bug-11614-206@http.llvm.org/bugs/>
References: <bug-11614-206@http.llvm.org/bugs/>
Message-ID: <bug-11614-206-6cUVFP7TTp@http.llvm.org/bugs/>

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

Richard Smith <richard-llvm at metafoo.co.uk> changed:

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

--- Comment #6 from Richard Smith <richard-llvm at metafoo.co.uk> 2011-12-21 20:24:55 CST ---
This was next on my constexpr agenda anyway. r147128.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 21 22:47:06 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 22 Dec 2011 04:47:06 +0000
Subject: [LLVMbugs] [Bug 11639] New: Trunk clang on Redhat Linux configured
 with --enable-optimized
 --with-c-include-dirs=/usr/include:/usr/include/c++/4.1.1
Message-ID: <bug-11639-206@http.llvm.org/bugs/>

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

             Bug #: 11639
           Summary: Trunk clang on Redhat Linux configured with
                    --enable-optimized
                    --with-c-include-dirs=/usr/include:/usr/include/c++/4.
                    1.1
           Product: compiler-rt
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: release blocker
          Priority: P
         Component: compiler-rt
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: kbelco at sandia.gov
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 7788
  --> http://llvm.org/bugs/attachment.cgi?id=7788
build generated script of command that failed.

make[4]: Nothing to be done for `all'.
make[4]: Leaving directory
`/home/kbelco/llvm_linux/build/tools/clang/tools/diagtool'
make[3]: Leaving directory `/home/kbelco/llvm_linux/build/tools/clang/tools'
make[3]: Entering directory `/home/kbelco/llvm_linux/build/tools/clang/runtime'
make[4]: Entering directory
`/home/kbelco/llvm_linux/build/tools/clang/runtime/compiler-rt'
make[5]: Entering directory `/home/kbelco/llvm_linux/llvm/projects/compiler-rt'
  COMPILE:   clang_linux/full-i386/i386:
/home/kbelco/llvm_linux/llvm/projects/compiler-rt/lib/adddf3.c
clang: /home/kbelco/llvm_linux/llvm/include/llvm/ADT/IntervalMap.h:606:
unsigned int llvm::IntervalMapImpl::LeafNode< <template-parameter-1-1>,
<template-parameter-1-2>, <anonymous>, <template-parameter-1-4>
>::insertFrom(unsigned int&, unsigned int, KeyT, KeyT, ValT) [with KeyT =
llvm::SlotIndex, ValT = unsigned int, unsigned int N = 9u, Traits =
llvm::IntervalMapInfo<llvm::SlotIndex>]: Assertion `!Traits::stopLess(b, a) &&
"Invalid interval"' failed.
0  clang           0x0000000002246a1f
1  clang           0x0000000002247737
2  libpthread.so.0 0x000000332380eb10
3  libc.so.6       0x0000003322c30265 gsignal + 53
4  libc.so.6       0x0000003322c31d10 abort + 272
5  libc.so.6       0x0000003322c296e6 __assert_fail + 246
6  clang           0x0000000001d0987c
llvm::IntervalMapImpl::LeafNode<llvm::SlotIndex, unsigned int, 9u,
llvm::IntervalMapInfo<llvm::SlotIndex> >::insertFrom(unsigned int&, unsigned
int, llvm::SlotIndex, llvm::SlotIndex, unsigned int) + 716
7  clang           0x0000000001d0a032 llvm::IntervalMap<llvm::SlotIndex,
unsigned int, 9u, llvm::IntervalMapInfo<llvm::SlotIndex>
>::insert(llvm::SlotIndex, llvm::SlotIndex, unsigned int) + 178
8  clang           0x0000000001cfdb4a
llvm::SplitEditor::useIntv(llvm::SlotIndex, llvm::SlotIndex) + 90
9  clang           0x0000000001d01c14
llvm::SplitEditor::splitRegInBlock(llvm::SplitAnalysis::BlockInfo const&,
unsigned int, llvm::SlotIndex) + 1524
10 clang           0x0000000001cb5b8a
11 clang           0x0000000001cb89dd
12 clang           0x0000000001cbc347
13 clang           0x0000000001cbc7f6
14 clang           0x0000000001d8f5d0 llvm::RegAllocBase::allocatePhysRegs() +
320
15 clang           0x0000000001cb790f
16 clang           0x0000000001c5cd85
llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 53
17 clang           0x00000000021db676
llvm::FPPassManager::runOnFunction(llvm::Function&) + 646
18 clang           0x00000000021db70d
llvm::FPPassManager::runOnModule(llvm::Module&) + 45
19 clang           0x00000000021db11c
llvm::MPPassManager::runOnModule(llvm::Module&) + 556
20 clang           0x00000000021db27e llvm::PassManagerImpl::run(llvm::Module&)
+ 174
21 clang           0x00000000021db3dd llvm::PassManager::run(llvm::Module&) +
13
22 clang           0x00000000008dbdab
clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::CodeGenOptions
const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::Module*,
clang::BackendAction, llvm::raw_ostream*) + 1419
23 clang           0x00000000008d9463
clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) + 787
24 clang           0x0000000000a7891b clang::ParseAST(clang::Sema&, bool) + 443
25 clang           0x00000000008d7602 clang::CodeGenAction::ExecuteAction() +
66
26 clang           0x0000000000738344
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 756
27 clang           0x00000000007133f2
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1218
28 clang           0x000000000070a1a2 cc1_main(char const**, char const**, char
const*, void*) + 754
29 clang           0x00000000007121d0 main + 3984
30 libc.so.6       0x0000003322c1d994 __libc_start_main + 244
31 clang           0x0000000000707cc9
Stack dump:
0.    Program arguments:
/home/kbelco/llvm_linux/build/Release+Asserts/bin/clang -cc1 -triple
i386-unknown-linux-gnu -S -disable-free -main-file-name adddf3.c -pic-level 2
-masm-verbose -mconstructor-aliases -target-cpu pentium4 -target-linker-version
2.17.50.0.6 -momit-leaf-frame-pointer -coverage-file /tmp/adddf3-f4md0C.s
-resource-dir
/home/kbelco/llvm_linux/build/Release+Asserts/bin/../lib/clang/3.1 -isysroot
/home/kbelco/llvm_linux/llvm/projects/compiler-rt/SDKs/linux
-fmodule-cache-path /var/tmp/clang-module-cache -internal-isystem
/home/kbelco/llvm_linux/llvm/projects/compiler-rt/SDKs/linux/usr/local/include
-internal-isystem
/home/kbelco/llvm_linux/build/Release+Asserts/bin/../lib/clang/3.1/include
-internal-externc-isystem
/home/kbelco/llvm_linux/llvm/projects/compiler-rt/SDKs/linux/usr/include
-internal-externc-isystem
/home/kbelco/llvm_linux/llvm/projects/compiler-rt/SDKs/linux/usr/include/c++/4.1.1
-O3 -Wall -Werror -fno-dwarf-directory-asm -fdebug-compilation-dir
/home/kbelco/llvm_linux/build/tools/clang/runtime/compiler-rt -ferror-limit 19
-fmessage-length 152 -mstackrealign -fgnu-runtime -fobjc-runtime-has-arc
-fobjc-runtime-has-weak -fobjc-fragile-abi -fdiagnostics-show-option
-fcolor-diagnostics -o /tmp/adddf3-f4md0C.s -x c
/home/kbelco/llvm_linux/llvm/projects/compiler-rt/lib/adddf3.c 
1.    <eof> parser at end of file
2.    Code generation
3.    Running pass 'Function Pass Manager' on module
'/home/kbelco/llvm_linux/llvm/projects/compiler-rt/lib/adddf3.c'.
4.    Running pass 'Greedy Register Allocator' on function '@__adddf3'
clang: error: unable to execute command: Aborted (core dumped)
clang: error: clang frontend command failed due to signal (use -v to see
invocation)
clang: note: diagnostic msg: Please submit a bug report to
http://llvm.org/bugs/ and include command line arguments and all diagnostic
information.
clang: note: diagnostic msg: Preprocessed source(s) and associated run
script(s) are located at:
clang: note: diagnostic msg: /tmp/adddf3-6sfvBj.i
clang: note: diagnostic msg: /tmp/adddf3-6sfvBj.sh
make[5]: ***
[/home/kbelco/llvm_linux/build/tools/clang/runtime/compiler-rt/clang_linux/full-i386/i386/SubDir.lib/adddf3.o]
Error 254
make[5]: Leaving directory `/home/kbelco/llvm_linux/llvm/projects/compiler-rt'
make[4]: *** [BuildRuntimeLibraries] Error 2
make[4]: Leaving directory
`/home/kbelco/llvm_linux/build/tools/clang/runtime/compiler-rt'
make[3]: *** [compiler-rt/.makeall] Error 2
make[3]: Leaving directory `/home/kbelco/llvm_linux/build/tools/clang/runtime'
make[2]: *** [all] Error 1
make[2]: Leaving directory `/home/kbelco/llvm_linux/build/tools/clang'
make[1]: *** [clang/.makeall] Error 2
make[1]: Leaving directory `/home/kbelco/llvm_linux/build/tools'
make: *** [all] Error 1

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

From bugzilla-daemon at llvm.org  Wed Dec 21 23:00:12 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 22 Dec 2011 05:00:12 +0000
Subject: [LLVMbugs] [Bug 11639] Trunk clang on Redhat Linux configured with
 --enable-optimized
 --with-c-include-dirs=/usr/include:/usr/include/c++/4.1.1
In-Reply-To: <bug-11639-206@http.llvm.org/bugs/>
References: <bug-11639-206@http.llvm.org/bugs/>
Message-ID: <bug-11639-206-AxOakEMTgA@http.llvm.org/bugs/>

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

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

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

--- Comment #3 from Anton Korobeynikov <asl at math.spbu.ru> 2011-12-21 23:00:12 CST ---
Please try with other gcc version and reopen if this still reproduces.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 22 00:04:12 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 22 Dec 2011 06:04:12 +0000
Subject: [LLVMbugs] [Bug 11639] Trunk clang on Redhat Linux configured with
 --enable-optimized
 --with-c-include-dirs=/usr/include:/usr/include/c++/4.1.1
In-Reply-To: <bug-11639-206@http.llvm.org/bugs/>
References: <bug-11639-206@http.llvm.org/bugs/>
Message-ID: <bug-11639-206-9cNoqcG9xr@http.llvm.org/bugs/>

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

K. Noel Belcourt <kbelco at sandia.gov> changed:

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

--- Comment #4 from K. Noel Belcourt <kbelco at sandia.gov> 2011-12-22 00:04:12 CST ---
Hi Anton,

I just retried a clean build, same error, so compiler-rt trunk is broken. 
Might want to see who's recently pushed to trunk.

This gcc (4.1.2) works fine (was working all day today).  I was trying to
fixing the broken include path support in clang by configuring and passing the
include paths explicitly.  It didn't work but I thought I'd give it a try.  The
crash below is still occurring with a clean checkout of llvm, clang, and
compiler-rt.

-- Noel

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 22 00:11:38 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 22 Dec 2011 06:11:38 +0000
Subject: [LLVMbugs] [Bug 11639] Trunk clang on Redhat Linux configured with
 --enable-optimized
 --with-c-include-dirs=/usr/include:/usr/include/c++/4.1.1
In-Reply-To: <bug-11639-206@http.llvm.org/bugs/>
References: <bug-11639-206@http.llvm.org/bugs/>
Message-ID: <bug-11639-206-hgvROnuyHC@http.llvm.org/bugs/>

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

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

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

--- Comment #5 from Anton Korobeynikov <asl at math.spbu.ru> 2011-12-22 00:11:38 CST ---
(In reply to comment #4)
> I just retried a clean build, same error, so compiler-rt trunk is broken. 
> Might want to see who's recently pushed to trunk.
Once again: you're seeing that compiler-rt build is broken. This seems to be
due to assertion in clang. Which is triggerred (most probably) due to
miscompilation of *clang* by your system gcc. So it does not help whether
you're using "clean checkout" or something else.

> This gcc (4.1.2) works fine (was working all day today).
Note the following line from the link I posted:
"GCC 4.1.2 20071124 (Red Hat 4.1.2-42): Suffers from the same symptoms as the
previous one. It appears to work with ENABLE_OPTIMIZED=0 (the default)."

So, some RedHat-provided version of gcc (which appears to be the same version
of yours) is already known to be broken.

Before reopen please try two things:

1. Check the debug build (make ENABLE_OPTIMIZED=0) of llvm/clang
2. Check with other version of gcc (not 4.1.x at least)

If this is still reproduces with 2. - then please reopen. Otherwise, please
upgrade your gcc.

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

From bugzilla-daemon at llvm.org  Thu Dec 22 06:24:33 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 22 Dec 2011 12:24:33 +0000
Subject: [LLVMbugs] [Bug 11640] New: clang optimization changes the linkage
 type of string constant
Message-ID: <bug-11640-206@http.llvm.org/bugs/>

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

             Bug #: 11640
           Summary: clang optimization changes the linkage type of string
                    constant
           Product: clang
           Version: 3.0
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: writalnaie at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


For compiling with -O2 option:

$ cat gig.c

#include <stdio.h>

void go() {
        printf("gig!\n");
}

int main() {
        go();
        return 0;
}

$ ../clang gig.c -o gig.o -c -O2
$ nm gig.o
00000000 T go
00000020 T main
         U puts
00000000 r str

The extra "str" is exported which does not occur in orignal source file

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 22 08:03:28 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 22 Dec 2011 14:03:28 +0000
Subject: [LLVMbugs] [Bug 11620] Please support HURD & kfreebsd in the
	autotools
In-Reply-To: <bug-11620-206@http.llvm.org/bugs/>
References: <bug-11620-206@http.llvm.org/bugs/>
Message-ID: <bug-11620-206-cS2KsRuRbb@http.llvm.org/bugs/>

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

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

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

--- Comment #1 from Rafael ?vila de Esp?ndola <rafael.espindola at gmail.com> 2011-12-22 08:03:28 CST ---
Fixed in r147143.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 22 08:22:48 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 22 Dec 2011 14:22:48 +0000
Subject: [LLVMbugs] [Bug 11640] clang optimization changes the linkage type
 of string constant
In-Reply-To: <bug-11640-206@http.llvm.org/bugs/>
References: <bug-11640-206@http.llvm.org/bugs/>
Message-ID: <bug-11640-206-5M0oYx8rW3@http.llvm.org/bugs/>

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

Benjamin Kramer <benny.kra at gmail.com> changed:

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

--- Comment #1 from Benjamin Kramer <benny.kra at gmail.com> 2011-12-22 08:22:48 CST ---
Fixed in r147144.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 22 15:17:00 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 22 Dec 2011 21:17:00 +0000
Subject: [LLVMbugs] [Bug 11641] New: preprocessor with -O2 generates
	incorrect warnings
Message-ID: <bug-11641-206@http.llvm.org/bugs/>

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

             Bug #: 11641
           Summary: preprocessor with -O2 generates incorrect warnings
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: steven at ngls.net
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 7795
  --> http://llvm.org/bugs/attachment.cgi?id=7795
unoptimized preprocessor output

Running just the prepocessor with and without -O2 generates different
output files.  The -O2 file then generates incorrect warnings.

shell log follows:

bluishred:~/work 754 ? clang -O2 -fpic -Wno-format-security -E minigzip.c >
preprocessed_O2.c 
bluishred:~/work 755 ? clang     -fpic -Wno-format-security -E minigzip.c >
preprocessed.c 
bluishred:~/work 756 ? clang     -fpic -Wno-format-security -c preprocessed.c 
bluishred:~/work 757 ? clang -O2 -fpic -Wno-format-security -c
preprocessed_O2.c 
In file included from minigzip.c:1:
minigzip.c:283:2075: warning: array index 3 is past the end of the array (which
contains 3 elements) [-Warray-bounds]
  ...- ((__const unsigned char *) (__const char *) ("-d"))[2]); if (__s2_len >
2 && __result == 0) __result = (__s1[3] - ((__const unsigned char *) (__const
char *) ("-d"))[3]); } } __result; }))) : __builtin_strcmp (*argv, "-d")))); })
== 0)
                                                                               
                                                                               
      ^      ~
minigzip.c:285:2080: warning: array index 3 is past the end of the array (which
contains 3 elements) [-Warray-bounds]
  ...- ((__const unsigned char *) (__const char *) ("-f"))[2]); if (__s2_len >
2 && __result == 0) __result = (__s1[3] - ((__const unsigned char *) (__const
char *) ("-f"))[3]); } } __result; }))) : __builtin_strcmp (*argv, "-f")))); })
== 0)
                                                                               
                                                                               
      ^      ~
minigzip.c:287:2080: warning: array index 3 is past the end of the array (which
contains 3 elements) [-Warray-bounds]
  ...- ((__const unsigned char *) (__const char *) ("-h"))[2]); if (__s2_len >
2 && __result == 0) __result = (__s1[3] - ((__const unsigned char *) (__const
char *) ("-h"))[3]); } } __result; }))) : __builtin_strcmp (*argv, "-h")))); })
== 0)
                                                                               
                                                                               
      ^      ~
minigzip.c:289:2080: warning: array index 3 is past the end of the array (which
contains 3 elements) [-Warray-bounds]
  ...- ((__const unsigned char *) (__const char *) ("-r"))[2]); if (__s2_len >
2 && __result == 0) __result = (__s1[3] - ((__const unsigned char *) (__const
char *) ("-r"))[3]); } } __result; }))) : __builtin_strcmp (*argv, "-r")))); })
== 0)
                                                                               
                                                                               
      ^      ~
4 warnings generated.
bluishred:~/work 758 ? clang -v
clang version 3.1 (trunk 147153)
Target: x86_64-unknown-linux-gnu
Thread model: posix

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

From bugzilla-daemon at llvm.org  Thu Dec 22 15:21:06 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 22 Dec 2011 21:21:06 +0000
Subject: [LLVMbugs] [Bug 11642] New: -fvisibility-inlines-hidden should not
 hide explicit instantiations
Message-ID: <bug-11642-206@http.llvm.org/bugs/>

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

             Bug #: 11642
           Summary: -fvisibility-inlines-hidden should not hide explicit
                    instantiations
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: LLVM Codegen
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: benny.kra at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 7798
  --> http://llvm.org/bugs/attachment.cgi?id=7798
preprocessed testcase for a.cc

Clang with -fvisibility-inlines-hidden generates a hidden definition for
explicitly instantiated inlines.

Now think of the following scenario:
a.h defines class Foo.
a.cc has the instantiation for Foo<int>
b.cc uses Foo<int>

Now we build a shared library from a.cc, Foo::foo is not exported. When b.cc is
compiled it won't include a definition for Foo::foo and linking against the
shared library will cause a linker 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  Thu Dec 22 15:38:01 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 22 Dec 2011 21:38:01 +0000
Subject: [LLVMbugs] [Bug 11214] ELF: R_ARM_THM_CALL relocation is written
	R_ARM_NONE
In-Reply-To: <bug-11214-206@http.llvm.org/bugs/>
References: <bug-11214-206@http.llvm.org/bugs/>
Message-ID: <bug-11214-206-a9ncWK8Wx8@http.llvm.org/bugs/>

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

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

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

--- Comment #3 from Rafael ?vila de Esp?ndola <rafael.espindola at gmail.com> 2011-12-22 15:38:01 CST ---
Fixed in r147180.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 22 16:04:46 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 22 Dec 2011 22:04:46 +0000
Subject: [LLVMbugs] [Bug 11641] preprocessor with -O2 generates incorrect
	warnings
In-Reply-To: <bug-11641-206@http.llvm.org/bugs/>
References: <bug-11641-206@http.llvm.org/bugs/>
Message-ID: <bug-11641-206-HHNKgrXjDH@http.llvm.org/bugs/>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |sharparrow1 at yahoo.com
         Resolution|                            |DUPLICATE

--- Comment #4 from Eli Friedman <sharparrow1 at yahoo.com> 2011-12-22 16:04:46 CST ---


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

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 22 16:19:38 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 22 Dec 2011 22:19:38 +0000
Subject: [LLVMbugs] [Bug 11643] New: [x86 disassembler] jecxz not
	disassembled
Message-ID: <bug-11643-206@http.llvm.org/bugs/>

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

             Bug #: 11643
           Summary: [x86 disassembler] jecxz not disassembled
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Backend: X86
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: kkhoo at perfwizard.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


>From the "Intel? 64 and IA-32 Architectures Software Developer?s Manual
Volume 2 (2A & 2B): Instruction Set Reference, A-Z", p. 3-544:
Jcc?Jump if Condition Is Met
E3 cb JCXZ rel8 A N.E. Valid Jump short if CX register is
0.
E3 cb JECXZ rel8 A Valid Valid Jump short if ECX register is
0.
E3 cb JRCXZ rel8 A Valid N.E. Jump short if RCX register is
0.

Using llvm-mc from the 3.0 pre-built binaries for MacOS X:

$ echo '0xe3 0x0a' |./llvm-mc -disassemble -triple="x86_64"
<stdin>:1:1: warning: invalid instruction encoding
0xe3 0x0a
^
<stdin>:1:6: warning: invalid instruction encoding
0xe3 0x0a
     ^

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 22 17:26:37 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 22 Dec 2011 23:26:37 +0000
Subject: [LLVMbugs] [Bug 11609] missing warning for ambiguous else
In-Reply-To: <bug-11609-206@http.llvm.org/bugs/>
References: <bug-11609-206@http.llvm.org/bugs/>
Message-ID: <bug-11609-206-2nkwSmXbTS@http.llvm.org/bugs/>

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

Nico Weber <nicolasweber at gmx.de> changed:

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

--- Comment #4 from Nico Weber <nicolasweber at gmx.de> 2011-12-22 17:26:37 CST ---
r147202

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 22 18:01:02 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 23 Dec 2011 00:01:02 +0000
Subject: [LLVMbugs] [Bug 11644] New: clang should throw
 std::bad_array_new_length when the allocation size for new overflows
Message-ID: <bug-11644-206@http.llvm.org/bugs/>

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

             Bug #: 11644
           Summary: clang should throw std::bad_array_new_length when the
                    allocation size for new overflows
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: C++0x
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: sharparrow1 at yahoo.com
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified


C++11 has a new exception type: std::bad_array_new_length.  And per the
standard, "If the value of that expression is less than zero or such that the
size of the allocated object would exceed the implementation-defined limit, no
storage is obtained and the new-expression terminates by throwing an exception
of a type that would match a handler (15.3) of type std::bad_array_new_length".
 Our current behavior is likely good enough in most cases, but it isn't
strictly compliant.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 22 19:47:15 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 23 Dec 2011 01:47:15 +0000
Subject: [LLVMbugs] [Bug 11645] New: CFG for destructors in '||'/'&&' lacks
	precision
Message-ID: <bug-11645-206@http.llvm.org/bugs/>

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

             Bug #: 11645
           Summary: CFG for destructors in '||'/'&&' lacks precision
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Static Analyzer
        AssignedTo: kremenek at apple.com
        ReportedBy: kremenek at apple.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


The source-level CFG currently is very imprecise for modeling C++ destructors
and '||'/'&&' short-circuit operations.

Consider:

$ cat /tmp/test.cpp
int foo();
int bar();

class A {
public:
  A(int x);
  ~A();
  operator bool();
};

class B {
public:
  B(int x);
  ~B();
  operator bool();
};

class C {
public:
  C(int x);
  ~C();
  operator bool();
};

int test(int x, int y) {
  if (C b = A(x) || B(y))
   return foo();
  return bar();
}


Let's look at the CFG without destructors:

$ clang -cc1 -analyze -analyzer-checker=debug.DumpCFG /tmp/test.cpp
 [B6 (ENTRY)]
   Succs (1): B4

 [B1]
   1: bar
   2: [B1.1] (ImplicitCastExpr, FunctionToPointerDecay, int (*)(void))
   3: [B1.2]()
   4: return [B1.3];
   Preds (1): B3
   Succs (1): B0

 [B2]
   1: foo
   2: [B2.1] (ImplicitCastExpr, FunctionToPointerDecay, int (*)(void))
   3: [B2.2]()
   4: return [B2.3];
   Preds (1): B3
   Succs (1): B0

 [B3]
   1: [B4.8] || [B5.8]
   2: [B3.1] (ImplicitCastExpr, IntegralCast, int)
   3: [B3.2] (CXXConstructExpr, class C)
   4: [B3.3] (ImplicitCastExpr, ConstructorConversion, class C)
   5: [B3.4] (BindTemporary)
   6: [B3.5] (ImplicitCastExpr, NoOp, const class C)
   7: [B3.6]
   8: C b = A(x).operator _Bool() || B(y).operator _Bool();
   9: b
  10: [B3.9].operator _Bool
  11: [B3.10]()
  12: [B3.11] (ImplicitCastExpr, UserDefinedConversion, _Bool)
   T: if [B3.12]
   Preds (2): B5 B4
   Succs (2): B2 B1

 [B4]
   1: x
   2: [B4.1] (ImplicitCastExpr, LValueToRValue, int)
   3: [B4.2] (CXXConstructExpr, class A)
   4: [B4.3] (BindTemporary)
   5: A([B4.4]) (CXXFunctionalCastExpr, ConstructorConversion, class A)
   6: [B4.5].operator _Bool
   7: [B4.6]()
   8: [B4.7] (ImplicitCastExpr, UserDefinedConversion, _Bool)
   T: [B4.8] || ...
   Preds (1): B6
   Succs (2): B3 B5

 [B5]
   1: y
   2: [B5.1] (ImplicitCastExpr, LValueToRValue, int)
   3: [B5.2] (CXXConstructExpr, class B)
   4: [B5.3] (BindTemporary)
   5: B([B5.4]) (CXXFunctionalCastExpr, ConstructorConversion, class B)
   6: [B5.5].operator _Bool
   7: [B5.6]()
   8: [B5.7] (ImplicitCastExpr, UserDefinedConversion, _Bool)
   Preds (1): B4
   Succs (1): B3

 [B0 (EXIT)]
   Preds (2): B1 B2


This CFG behaves as expected.  We have a single block with the '||' operation
as a terminator (block 4), and a single block that merges the values from the
LHS and RHS expressions (block B3) which is then terminated with the 'if'
branch terminator.  My motivation for looking at this CFG was to further
optimize this so that block B5 was seen as dominating block B2.   This would
improve the quality of some flow-sensitive (but path-insensitive) analyses in
the frontend and also simplify the CFG.

The CFG gets significantly more complicated (and wrong) when we add implicit
destructors:

$ clang -cc1 -analyze -cfg-add-implicit-dtors -analyzer-checker=debug.DumpCFG
/tmp/test.cpp

 [B8 (ENTRY)]
   Succs (1): B6

 [B1]
   1: [B3.2].~C() (Implicit destructor)
   2: bar
   3: [B1.2] (ImplicitCastExpr, FunctionToPointerDecay, int (*)(void))
   4: [B1.3]()
   5: return [B1.4];
   Preds (1): B3
   Succs (1): B0

 [B2]
   1: foo
   2: [B2.1] (ImplicitCastExpr, FunctionToPointerDecay, int (*)(void))
   3: [B2.2]()
   4: return [B2.3];
   5: [B3.2].~C() (Implicit destructor)
   Preds (1): B3
   Succs (1): B0

 [B3]
   1: ~A() (Temporary object destructor)
   2: C b = A(x).operator _Bool() || B(y).operator _Bool();
   3: b
   4: [B3.3].operator _Bool
   5: [B3.4]()
   6: [B3.5] (ImplicitCastExpr, UserDefinedConversion, _Bool)
   T: if [B3.6]
   Preds (2): B4 B5
   Succs (2): B2 B1

 [B4]
   1: ~B() (Temporary object destructor)
   Preds (1): B5
   Succs (1): B3

 [B5]
   1: [B6.8] || [B7.8]
   2: [B5.1] (ImplicitCastExpr, IntegralCast, int)
   3: [B5.2] (CXXConstructExpr, class C)
   4: [B5.3] (ImplicitCastExpr, ConstructorConversion, class C)
   5: [B5.4] (BindTemporary)
   6: [B5.5] (ImplicitCastExpr, NoOp, const class C)
   7: [B5.6]
   8: ~C() (Temporary object destructor)
   T: [B6.8] || ...
   Preds (2): B7 B6
   Succs (2): B3 B4

 [B6]
   1: x
   2: [B6.1] (ImplicitCastExpr, LValueToRValue, int)
   3: [B6.2] (CXXConstructExpr, class A)
   4: [B6.3] (BindTemporary)
   5: A([B6.4]) (CXXFunctionalCastExpr, ConstructorConversion, class A)
   6: [B6.5].operator _Bool
   7: [B6.6]()
   8: [B6.7] (ImplicitCastExpr, UserDefinedConversion, _Bool)
   T: [B6.8] || ...
   Preds (1): B8
   Succs (2): B5 B7

 [B7]
   1: y
   2: [B7.1] (ImplicitCastExpr, LValueToRValue, int)
   3: [B7.2] (CXXConstructExpr, class B)
   4: [B7.3] (BindTemporary)
   5: B([B7.4]) (CXXFunctionalCastExpr, ConstructorConversion, class B)
   6: [B7.5].operator _Bool
   7: [B7.6]()
   8: [B7.7] (ImplicitCastExpr, UserDefinedConversion, _Bool)
   Preds (1): B6
   Succs (1): B5

 [B0 (EXIT)]
   Preds (2): B1 B2


Notice that blocks B6 and B5 have the same terminator, which itself is suspect.
 The rationale is that the temporary for 'B(y)' should only be destructed when
we evaluated the RHS of the logical operation.  This is good enough for the
static analyzer, but the CFG itself doesn't explicitly capture this dependency.
 This can be seen by observing that there is a path in the CFG from the entry
block to the exit block where destructor ~B is called but the constructor B()
is NOT called.  While the static analyzer will likely get this right and
recover that information (since it does enough value flow analysis to
understand control-dependent branches), this unnecessarily drops a bunch of
control-dependencies from the CFG which will degrade the quality of CFG-based
analyses in the frontend.

The second, and more glaring problem, is that ~C is called twice along a path,
both as an implicit destructor (in B1 and B2 respectively) and a destructor for
a temporary (in B5).  I may be missing something here, but this doesn't show up
in the LLVM IR (which clearly shows a single destructor call to ~C).

Also, look at where the destructors are called.  In block B1, ~C is correctly
called before the call to bar(), but in block B2, the destructor appears after
the return statement.  Instead, it should appear immediately after the call to
foo().

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

From bugzilla-daemon at llvm.org  Fri Dec 23 00:56:30 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 23 Dec 2011 06:56:30 +0000
Subject: [LLVMbugs] [Bug 11646] New: Unable to build shared libraries of
 llvm/clang-3.0 on MinGW32 (MSYS)
Message-ID: <bug-11646-206@http.llvm.org/bugs/>

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

             Bug #: 11646
           Summary: Unable to build shared libraries of llvm/clang-3.0 on
                    MinGW32 (MSYS)
           Product: Build scripts
           Version: 3.0
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: cmake
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: oroppas at gmail.com
                CC: llvmbugs at cs.uiuc.edu, ofv at wanadoo.es
    Classification: Unclassified


Created attachment 7799
  --> http://llvm.org/bugs/attachment.cgi?id=7799
The patch for clang/lib/Serialization/CMakeLists.txt

Hi,

I've got the following link error (lots of lots of error messages) of the
shared library (libclangSerialization.dll):

<snip>

CMakeFiles/clangSerialization.dir/objects.a(ModuleManager.cpp.obj):ModuleManager
.cpp:(.text+0x13c7): undefined reference to
`llvm::SmallPtrSetImpl::FindBucketFo
r(void const*) const'
CMakeFiles/clangSerialization.dir/objects.a(ModuleManager.cpp.obj):ModuleManager
.cpp:(.text+0x1a94): undefined reference to
`llvm::SmallVectorBase::grow_pod(uns
igned int, unsigned int)'
CMakeFiles/clangSerialization.dir/objects.a(ModuleManager.cpp.obj):ModuleManager
.cpp:(.text+0x1abc): undefined reference to
`llvm::SmallVectorBase::grow_pod(uns
igned int, unsigned int)'
CMakeFiles/clangSerialization.dir/objects.a(ModuleManager.cpp.obj):ModuleManager
.cpp:(.text+0x1b7a): undefined reference to
`llvm::SmallPtrSetImpl::~SmallPtrSet
Impl()'
CMakeFiles/clangSerialization.dir/objects.a(ModuleManager.cpp.obj):ModuleManager
.cpp:(.text+0x1cc2): undefined reference to
`llvm::SmallPtrSetImpl::insert_imp(v
oid const*)'
CMakeFiles/clangSerialization.dir/objects.a(ModuleManager.cpp.obj):ModuleManager
.cpp:(.text+0x1cff): undefined reference to
`llvm::SmallPtrSetImpl::insert_imp(v
oid const*)'
CMakeFiles/clangSerialization.dir/objects.a(ModuleManager.cpp.obj):ModuleManager
.cpp:(.text+0x1e5c): undefined reference to
`llvm::SmallVectorBase::grow_pod(uns
igned int, unsigned int)'
CMakeFiles/clangSerialization.dir/objects.a(ModuleManager.cpp.obj):ModuleManager
.cpp:(.text+0x1ede): undefined reference to
`llvm::SmallVectorBase::grow_pod(uns
igned int, unsigned int)'
CMakeFiles/clangSerialization.dir/objects.a(ModuleManager.cpp.obj):ModuleManager
.cpp:(.text+0x1fd6): undefined reference to
`llvm::SmallPtrSetImpl::insert_imp(v
oid const*)'
CMakeFiles/clangSerialization.dir/objects.a(ModuleManager.cpp.obj):ModuleManager
.cpp:(.text+0x2000): undefined reference to
`llvm::SmallPtrSetImpl::~SmallPtrSet
Impl()'
CMakeFiles/clangSerialization.dir/objects.a(ModuleManager.cpp.obj):ModuleManager
.cpp:(.text+0x2067): undefined reference to
`clang::FileManager::getFile(llvm::S
tringRef, bool, bool)'
CMakeFiles/clangSerialization.dir/objects.a(ModuleManager.cpp.obj):ModuleManager
.cpp:(.text+0x223e): undefined reference to
`llvm::SmallPtrSetImpl::insert_imp(v
oid const*)'
CMakeFiles/clangSerialization.dir/objects.a(ModuleManager.cpp.obj):ModuleManager
.cpp:(.text+0x2290): undefined reference to
`llvm::SmallPtrSetImpl::insert_imp(v
oid const*)'
CMakeFiles/clangSerialization.dir/objects.a(ModuleManager.cpp.obj):ModuleManager
.cpp:(.text+0x27ad): undefined reference to
`llvm::SmallVectorBase::grow_pod(uns
igned int, unsigned int)'
CMakeFiles/clangSerialization.dir/objects.a(ModuleManager.cpp.obj):ModuleManager
.cpp:(.text+0x27cb): undefined reference to `llvm::system_category()'
CMakeFiles/clangSerialization.dir/objects.a(ModuleManager.cpp.obj):ModuleManager
.cpp:(.text+0x27fd): undefined reference to
`clang::FileManager::getBufferForFil
e(llvm::StringRef, std::string*)'
CMakeFiles/clangSerialization.dir/objects.a(ModuleManager.cpp.obj):ModuleManager
.cpp:(.text+0x2839): undefined reference to
`llvm::MemoryBuffer::getSTDIN(llvm::
OwningPtr<llvm::MemoryBuffer>&)'
CMakeFiles/clangSerialization.dir/objects.a(ModuleManager.cpp.obj):ModuleManager
.cpp:(.text+0x285b): undefined reference to `llvm::error_code::message() const'
collect2: ld returned 1 exit status
make[2]: *** [bin/libclangSerialization.dll] Error 1
make[1]: ***
[tools/clang/lib/Serialization/CMakeFiles/clangSerialization.dir/al
l] Error 2
make: *** [all] Error 2

Here's my CMake script:

cmake -DCMAKE_INSTALL_PREFIX:PATH=/mingw \
      -DCMAKE_BUILD_TYPE=Release \
      -DBUILD_SHARED_LIBS:BOOL=ON \
      -DLLVM_TARGETS_TO_BUILD:STRING=X86 \
      -G "MSYS Makefiles" \
      ../llvm-3.0.src

To fix the undefined reference to LLVM libraries all we need is to set
LLVM_LINK_COMPONENTS with the "support" component (i.e. libLLVMSupport).

But then, we still get huge number of undefined reference errors where
the linker is unable to link to, say libclangAST, etc.

With the attached patch, I finally managed to bring down the number of
undefined reference errors to the reasonable level:

cd /D/packages/llvm-build/tools/clang/lib/Serialization && /C/MinGW/bin/g++.exe
    -shared -o ../../../../bin/libclangSerialization.dll
-Wl,--out-implib,../../
../../lib/libclangSerialization.dll.a
-Wl,--major-image-version,0,--minor-image-
version,0 -Wl,--whole-archive CMakeFiles/clangSerialization.dir/objects.a
-Wl,--
no-whole-archive ../../../../lib/libclangAST.dll.a
../../../../lib/libclangSema.
dll.a ../../../../lib/libLLVMSupport.dll.a -limagehlp -lpsapi
../../../../lib/li
bclangAnalysis.dll.a ../../../../lib/libclangIndex.dll.a
../../../../lib/libclan
gAST.dll.a ../../../../lib/libclangLex.dll.a
../../../../lib/libclangBasic.dll.a
 ../../../../lib/libLLVMMC.dll.a ../../../../lib/libLLVMObject.dll.a
../../../..
/lib/libLLVMCore.dll.a ../../../../lib/libLLVMSupport.dll.a -limagehlp -lpsapi
-
lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid
-lcomd
lg32 -ladvapi32
Creating library file: ../../../../lib/libclangSerialization.dll.a
CMakeFiles/clangSerialization.dir/objects.a(ASTReader.cpp.obj):ASTReader.cpp:(.t
ext+0x16d6c): undefined reference to
`clang::NormalizeDashIncludePath(llvm::Stri
ngRef, clang::FileManager&)'
CMakeFiles/clangSerialization.dir/objects.a(ChainedIncludesSource.cpp.obj):Chain
edIncludesSource.cpp:(.text+0x874): undefined reference to
`clang::TextDiagnosti
cPrinter::TextDiagnosticPrinter(llvm::raw_ostream&, clang::DiagnosticOptions
con
st&, bool)'
CMakeFiles/clangSerialization.dir/objects.a(ChainedIncludesSource.cpp.obj):Chain
edIncludesSource.cpp:(.text+0x94f): undefined reference to
`clang::CompilerInsta
nce::CompilerInstance()'
CMakeFiles/clangSerialization.dir/objects.a(ChainedIncludesSource.cpp.obj):Chain
edIncludesSource.cpp:(.text+0x95b): undefined reference to
`clang::CompilerInsta
nce::setInvocation(clang::CompilerInvocation*)'
CMakeFiles/clangSerialization.dir/objects.a(ChainedIncludesSource.cpp.obj):Chain
edIncludesSource.cpp:(.text+0x967): undefined reference to
`clang::CompilerInsta
nce::setDiagnostics(clang::DiagnosticsEngine*)'
CMakeFiles/clangSerialization.dir/objects.a(ChainedIncludesSource.cpp.obj):Chain
edIncludesSource.cpp:(.text+0x98a): undefined reference to
`clang::CompilerInsta
nce::setTarget(clang::TargetInfo*)'
CMakeFiles/clangSerialization.dir/objects.a(ChainedIncludesSource.cpp.obj):Chain
edIncludesSource.cpp:(.text+0x992): undefined reference to
`clang::CompilerInsta
nce::createFileManager()'
CMakeFiles/clangSerialization.dir/objects.a(ChainedIncludesSource.cpp.obj):Chain
edIncludesSource.cpp:(.text+0x9a1): undefined reference to
`clang::CompilerInsta
nce::createSourceManager(clang::FileManager&)'
CMakeFiles/clangSerialization.dir/objects.a(ChainedIncludesSource.cpp.obj):Chain
edIncludesSource.cpp:(.text+0x9a9): undefined reference to
`clang::CompilerInsta
nce::createPreprocessor()'
CMakeFiles/clangSerialization.dir/objects.a(ChainedIncludesSource.cpp.obj):Chain
edIncludesSource.cpp:(.text+0x9d3): undefined reference to
`clang::CompilerInsta
nce::createASTContext()'
CMakeFiles/clangSerialization.dir/objects.a(ChainedIncludesSource.cpp.obj):Chain
edIncludesSource.cpp:(.text+0xa70): undefined reference to
`clang::CompilerInsta
nce::setASTConsumer(clang::ASTConsumer*)'
CMakeFiles/clangSerialization.dir/objects.a(ChainedIncludesSource.cpp.obj):Chain
edIncludesSource.cpp:(.text+0xa88): undefined reference to
`clang::CompilerInsta
nce::createSema(clang::TranslationUnitKind, clang::CodeCompleteConsumer*)'
CMakeFiles/clangSerialization.dir/objects.a(ChainedIncludesSource.cpp.obj):Chain
edIncludesSource.cpp:(.text+0xd40): undefined reference to
`clang::CompilerInsta
nce::InitializeSourceManager(llvm::StringRef)'
CMakeFiles/clangSerialization.dir/objects.a(ChainedIncludesSource.cpp.obj):Chain
edIncludesSource.cpp:(.text+0xd5b): undefined reference to
`clang::ParseAST(clan
g::Sema&, bool)'
collect2: ld returned 1 exit status
make[2]: *** [bin/libclangSerialization.dll] Error 1
make[2]: Leaving directory `/d/packages/llvm-build'
make[1]: ***
[tools/clang/lib/Serialization/CMakeFiles/clangSerialization.dir/al
l] Error 2
make[1]: Leaving directory `/d/packages/llvm-build'
make: *** [all] Error 2

At this point the missing library to be linked is libclangFrontend.
However, libclangFrontend depends on libclangSerialization as well,
resulting in the circular dependency.

How can we break this circular dependency between libclangFrontend and
libclangSerialization?

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 23 03:41:24 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 23 Dec 2011 09:41:24 +0000
Subject: [LLVMbugs] [Bug 11647] New: tramp3d-v4 -O4 failure
Message-ID: <bug-11647-206@http.llvm.org/bugs/>

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

             Bug #: 11647
           Summary: tramp3d-v4 -O4 failure
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: markus at trippelsdorf.de
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


% clang++ -w -O4 tramp3d-v4-xhcsyW.ii
Call parameter type does not match function signature!
%1* getelementptr inbounds (%class.Interval.101* @vertexDomain, i64 0, i32 0,
i32 0)
 %class.DomainBase.103*  invoke void
@_ZNK10DomainBaseI12DomainTraitsI8IntervalILi3EEEE5printISoEEvRT_(%1*
getelementptr inbounds (%class.Interval.101* @vertexDomain, i64 0, i32 0, i32
0), %"class.std::basic_ostream"* %2595)
          to label %_ZlsI8IntervalILi3EEER6InformS3_RKT_.exit unwind label
%.nonloopexit
GEP is not of right type for indices!
  %2798 = getelementptr inbounds %class.Interval.101* %87, i64 0, i32 0, i32 0
 %"type 0x27f3ea0" = type { [3 x %"type 0x27f3e40"] }Instruction does not
dominate all uses!
  %2798 = getelementptr inbounds %class.Interval.101* %87, i64 0, i32 0, i32 0
  invoke void
@_ZNK10DomainBaseI12DomainTraitsI8IntervalILi3EEEE5printISoEEvRT_(%class.DomainBase.103*
%2798, %"class.std::basic_ostream"* %2797)
          to label %_ZlsI8IntervalILi3EEER6InformS3_RKT_.exit472 unwind label
%3101
Instruction does not dominate all uses!
  %2798 = getelementptr inbounds %class.Interval.101* %87, i64 0, i32 0, i32 0
  invoke void
@_ZNK10DomainBaseI12DomainTraitsI8IntervalILi3EEEE5printISoEEvRT_(%class.DomainBase.103*
%2798, %"class.std::basic_ostream"* %2797)
          to label %_ZlsI8IntervalILi3EEER6InformS3_RKT_.exit472 unwind label
%3101
GEP is not of right type for indices!
  %2895 = getelementptr inbounds %class.Interval.101* %88, i64 0, i32 0, i32 0
 %"type 0x27f3ea0" = type { [3 x %"type 0x27f3e40"] }Instruction does not
dominate all uses!
  %2895 = getelementptr inbounds %class.Interval.101* %88, i64 0, i32 0, i32 0
  invoke void
@_ZNK10DomainBaseI12DomainTraitsI8IntervalILi3EEEE5printISoEEvRT_(%class.DomainBase.103*
%2895, %"class.std::basic_ostream"* %2894)
          to label %_ZlsI8IntervalILi3EEER6InformS3_RKT_.exit477 unwind label
%3105
Instruction does not dominate all uses!
  %2895 = getelementptr inbounds %class.Interval.101* %88, i64 0, i32 0, i32 0
  invoke void
@_ZNK10DomainBaseI12DomainTraitsI8IntervalILi3EEEE5printISoEEvRT_(%class.DomainBase.103*
%2895, %"class.std::basic_ostream"* %2894)
          to label %_ZlsI8IntervalILi3EEER6InformS3_RKT_.exit477 unwind label
%3105
GEP is not of right type for indices!
  %2984 = getelementptr inbounds %class.Interval.101* %89, i64 0, i32 0, i32 0
 %"type 0x27f3ea0" = type { [3 x %"type 0x27f3e40"] }Instruction does not
dominate all uses!
  %2984 = getelementptr inbounds %class.Interval.101* %89, i64 0, i32 0, i32 0
  invoke void
@_ZNK10DomainBaseI12DomainTraitsI8IntervalILi3EEEE5printISoEEvRT_(%class.DomainBase.103*
%2984, %"class.std::basic_ostream"* %2983)
          to label %_ZlsI8IntervalILi3EEER6InformS3_RKT_.exit484 unwind label
%3109
Instruction does not dominate all uses!
  %2984 = getelementptr inbounds %class.Interval.101* %89, i64 0, i32 0, i32 0
  invoke void
@_ZNK10DomainBaseI12DomainTraitsI8IntervalILi3EEEE5printISoEEvRT_(%class.DomainBase.103*
%2984, %"class.std::basic_ostream"* %2983)
          to label %_ZlsI8IntervalILi3EEER6InformS3_RKT_.exit484 unwind label
%3109
GEP is not of right type for indices!
  %3081 = getelementptr inbounds %class.Interval.101* %90, i64 0, i32 0, i32 0
 %"type 0x27f3ea0" = type { [3 x %"type 0x27f3e40"] }Instruction does not
dominate all uses!
  %3081 = getelementptr inbounds %class.Interval.101* %90, i64 0, i32 0, i32 0
  invoke void
@_ZNK10DomainBaseI12DomainTraitsI8IntervalILi3EEEE5printISoEEvRT_(%class.DomainBase.103*
%3081, %"class.std::basic_ostream"* %3080)
          to label %_ZlsI8IntervalILi3EEER6InformS3_RKT_.exit491 unwind label
%3113
Instruction does not dominate all uses!
  %3081 = getelementptr inbounds %class.Interval.101* %90, i64 0, i32 0, i32 0
  invoke void
@_ZNK10DomainBaseI12DomainTraitsI8IntervalILi3EEEE5printISoEEvRT_(%class.DomainBase.103*
%3081, %"class.std::basic_ostream"* %3080)
          to label %_ZlsI8IntervalILi3EEER6InformS3_RKT_.exit491 unwind label
%3113
Broken module found, compilation aborted!
Stack dump:
0.      Running pass 'Function Pass Manager' on module 'ld-temp.o'.
1.      Running pass 'Module Verifier' on function '@main'
clang: error: unable to execute command: Aborted
clang: error: linker command failed due to signal (use -v to see invocation)
clang: note: diagnostic msg: Please submit a bug report to
http://llvm.org/bugs/ and include command line arguments and all diagnostic
information.
clang: note: diagnostic msg: Error generating preprocessed source(s) - no
preprocessable inputs.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 23 04:29:53 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 23 Dec 2011 10:29:53 +0000
Subject: [LLVMbugs] [Bug 11648] New: C++ lambda segfault [with minimal
	testcase and bt]
Message-ID: <bug-11648-206@http.llvm.org/bugs/>

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

             Bug #: 11648
           Summary: C++ lambda segfault [with minimal testcase and bt]
           Product: clang
           Version: 3.0
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: C++0x
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: gasper.azman at gmail.com
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 7801
  --> http://llvm.org/bugs/attachment.cgi?id=7801
the preprocessed sources, for completenes.

Hi,
Clang just crashed on me. As this isn't implemented, it should probably warn
about that instead of crashing:) 

This is the code:

#include <iostream>
int main( int argc, char *argv[] )
{
    std::cout << ([](){return 10;})();
}

I compiled with -std=c++0x and no other flags.

atom at kamichan ~ $ clang --version
clang version 3.0 (tags/RELEASE_30/final)
Target: x86_64-unknown-linux-gnu
Thread model: posix

I'm attaching clang's output .ii file (preprocessed sources) and everything it
dumped to the console (bt.txt)

By the way, the 3.0 clang is AWESOME. I love it. 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 Dec 23 16:11:02 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 23 Dec 2011 22:11:02 +0000
Subject: [LLVMbugs] [Bug 11649] New: Crash in 'ObjC ARC optimization' pass
Message-ID: <bug-11649-206@http.llvm.org/bugs/>

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

             Bug #: 11649
           Summary: Crash in 'ObjC ARC optimization' pass
           Product: clang
           Version: 3.0
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: LLVM Codegen
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: paul.q.stevenson at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


The latest development tree results in a crash when trying to compile the
function below with -O2. The same crash can be observed when cherry-picking 
commit 59a1c93e955c366084742ceca65e7b1afd8772ac to the 3.0 tree (to fix an ARC
double-release)


@interface TestObj
+ (TestObj *)obj;
- (BOOL)predicate:(int)val;
@end

void Func()
{
    TestObj *obj = [TestObj obj];
    BOOL flag1 = NO;
    BOOL flag2 = [obj predicate:0];
    int val = 0;

    if (![obj predicate:0])
        return;
    for (;; val++) {
        if ([obj predicate:0]) { 
            flag2 = NO;
            if ([obj predicate:0]) {
                flag1 = YES;
                continue;
            }
        }
        if ([obj predicate:val])
            break;

        val++;
    }
}

Crash output:


0  clang             0x00000001085bebf2
llvm::SmallVectorImpl<llvm_regmatch_t>::resize(unsigned int) + 2082
1  clang             0x00000001085bf1d9
llvm::SmallVectorImpl<llvm_regmatch_t>::resize(unsigned int) + 3593
2  libsystem_c.dylib 0x00007fff97281cfa _sigtramp + 26
3  libsystem_c.dylib 0x00007fff9724a00e szone_malloc_should_clear + 1115
4  clang             0x00000001082d4d49 void
llvm::SmallVectorImpl<llvm::User*>::append<llvm::value_use_iterator<llvm::User>
>(llvm::value_use_iterator<llvm::User>, llvm::value_use_iterator<llvm::User>) +
28073
5  clang             0x000000010851e9ed llvm::cl::parser<llvm::PassInfo
const*>::~parser() + 22237
6  clang             0x00000001083af32e std::vector<std::pair<llvm::WeakVH,
llvm::CallGraphNode*>, std::allocator<std::pair<llvm::WeakVH,
llvm::CallGraphNode*> >
>::_M_insert_aux(__gnu_cxx::__normal_iterator<std::pair<llvm::WeakVH,
llvm::CallGraphNode*>*, std::vector<std::pair<llvm::WeakVH,
llvm::CallGraphNode*>, std::allocator<std::pair<llvm::WeakVH,
llvm::CallGraphNode*> > > >, std::pair<llvm::WeakVH, llvm::CallGraphNode*>
const&) + 5310
7  clang             0x000000010851edb9 llvm::cl::parser<llvm::PassInfo
const*>::~parser() + 23209
8  clang             0x000000010851f3c2 llvm::cl::parser<llvm::PassInfo
const*>::~parser() + 24754
9  clang             0x000000010851f91d llvm::cl::parser<llvm::PassInfo
const*>::~parser() + 26125
10 clang             0x00000001072ee90a llvm::DenseMap<clang::FileEntry const*,
clang::serialization::Module*, llvm::DenseMapInfo<clang::FileEntry const*>,
llvm::DenseMapInfo<clang::serialization::Module*> >::grow(unsigned int) + 5082
11 clang             0x00000001073d4e96
clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) + 278
12 clang             0x00000001073f7c1b clang::CUDAGlobalAttr*
clang::Decl::getAttr<clang::CUDAGlobalAttr>() const + 891
13 clang             0x00000001073d3d8c
llvm::DenseMap<llvm::ValueMapCallbackVH<llvm::Value const*,
llvm::TrackingVH<llvm::Value>, llvm::ValueMapConfig<llvm::Value const*>,
llvm::DenseMapInfo<llvm::TrackingVH<llvm::Value> > >,
llvm::TrackingVH<llvm::Value>,
llvm::DenseMapInfo<llvm::ValueMapCallbackVH<llvm::Value const*,
llvm::TrackingVH<llvm::Value>, llvm::ValueMapConfig<llvm::Value const*>,
llvm::DenseMapInfo<llvm::TrackingVH<llvm::Value> > > >,
llvm::DenseMapInfo<llvm::TrackingVH<llvm::Value> > >::init(unsigned int) + 3660
14 clang             0x00000001071c759b llvm::DenseMap<clang::IdentifierInfo
const*, unsigned int, llvm::DenseMapInfo<clang::IdentifierInfo const*>,
llvm::DenseMapInfo<unsigned int> >::grow(unsigned int) + 14299
15 clang             0x00000001071b14e5 llvm::SmallVectorImpl<char
const*>::insert(char const**, char const* const&) + 3013
16 clang             0x00000001071a98fb
17 clang             0x00000001071ad7a1 std::vector<std::string,
std::allocator<std::string>
>::_M_insert_aux(__gnu_cxx::__normal_iterator<std::string*,
std::vector<std::string, std::allocator<std::string> > >, std::string const&) +
1553
18 clang             0x00000001071a8434
Stack dump:
0.
1.    <eof> parser at end of file
2.    Per-module optimization passes
3.    Running pass 'CallGraph Pass Manager' on module '...'.
4.    Running pass 'ObjC ARC optimization' on function '@Func'

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 23 17:56:09 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 23 Dec 2011 23:56:09 +0000
Subject: [LLVMbugs] [Bug 11558] Crash in ActOnExplicitInstantiation():
 "point of instantiation must be valid!"
In-Reply-To: <bug-11558-206@http.llvm.org/bugs/>
References: <bug-11558-206@http.llvm.org/bugs/>
Message-ID: <bug-11558-206-mQvGReW2qi@http.llvm.org/bugs/>

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

Nico Weber <nicolasweber at gmx.de> changed:

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

--- Comment #3 from Nico Weber <nicolasweber at gmx.de> 2011-12-23 17:56:09 CST ---
r147225

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 24 17:45:22 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 24 Dec 2011 23:45:22 +0000
Subject: [LLVMbugs] [Bug 11650] New: Implement DR1301: reject
 value-initialization of unions with deleted constructors
Message-ID: <bug-11650-206@http.llvm.org/bugs/>

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

             Bug #: 11650
           Summary: Implement DR1301: reject value-initialization of
                    unions with deleted constructors
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: C++0x
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: richard-llvm at metafoo.co.uk
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified


clang currently accepts cases like this:

struct S {
  S();
  virtual int f();
  int n;
};
union U {
  S s;
  int m;
};
int u = U().s.n;
int v = U().s.f();

Under the resolution of DR1301, these cases are ill-formed: the default
constructor of U is deleted, so value-initialization of U is ill-formed.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 24 18:01:28 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 25 Dec 2011 00:01:28 +0000
Subject: [LLVMbugs] [Bug 11651] New: Warn about "restrict" violations
Message-ID: <bug-11651-206@http.llvm.org/bugs/>

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

             Bug #: 11651
           Summary: Warn about "restrict" violations
           Product: clang
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: joerg at NetBSD.org
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Consider:

#include <stdio.h>

char buf[1024];

void foo(int c)
{
    snprintf(buf, sizeof(buf), "%s %d", buf, c);
}

This is derived from code found e.g. in NetBSD. It should give a warning, since
the first argument of snprintf is marked as restrict, but another reference is
provided.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 25 02:16:06 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 25 Dec 2011 08:16:06 +0000
Subject: [LLVMbugs] [Bug 10718] ExecutionEngine construction not thread-safe
In-Reply-To: <bug-10718-206@http.llvm.org/bugs/>
References: <bug-10718-206@http.llvm.org/bugs/>
Message-ID: <bug-10718-206-5bWOCH8gb0@http.llvm.org/bugs/>

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

Jordy Rose <jediknil at belkadan.com> changed:

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

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

From bugzilla-daemon at llvm.org  Mon Dec 26 04:45:39 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 26 Dec 2011 10:45:39 +0000
Subject: [LLVMbugs] [Bug 11634] -faltivec ignored by the driver
In-Reply-To: <bug-11634-206@http.llvm.org/bugs/>
References: <bug-11634-206@http.llvm.org/bugs/>
Message-ID: <bug-11634-206-4EEFvOFhKm@http.llvm.org/bugs/>

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

Michael Kostylev <michael.kostylev at gmail.com> changed:

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

--- Comment #1 from Michael Kostylev <michael.kostylev at gmail.com> 2011-12-26 04:45:39 CST ---
r147224

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 26 12:18:19 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 26 Dec 2011 18:18:19 +0000
Subject: [LLVMbugs] [Bug 10747] miscompiled extractelement instruction
In-Reply-To: <bug-10747-206@http.llvm.org/bugs/>
References: <bug-10747-206@http.llvm.org/bugs/>
Message-ID: <bug-10747-206-E6X4jeOJQP@http.llvm.org/bugs/>

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

Zoltan Varga <vargaz at gmail.com> changed:

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

--- Comment #5 from Zoltan Varga <vargaz at gmail.com> 2011-12-26 12:18:19 CST ---
This is not entirely fixed, here is another testcase, which also fails since
r131183:
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
; ModuleID = 'temp.opt.bc'

define i32 @main() {
BB0:
  %r0 = alloca <4 x i32>, align 16
  %r1 = getelementptr <4 x i32>* %r0, i32 0, i32 3
  store i32 4, i32* %r1
  %r2 = getelementptr <4 x i32>* %r0, i32 0, i32 2
  store i32 3, i32* %r2
  %r3 = getelementptr <4 x i32>* %r0, i32 0, i32 1
  store i32 2, i32* %r3
  %r4 = getelementptr inbounds <4 x i32>* %r0, i32 0, i32 0
  store i32 1, i32* %r4
  %r7 = load <4 x i32>* %r0, align 1
  store i32 8, i32* %r1
  store i32 7, i32* %r2
  store i32 6, i32* %r3
  store i32 5, i32* %r4
  %r8 = load <4 x i32>* %r0, align 1
  %r9 = extractelement <4 x i32> %r7, i32 2
  %r10 = icmp eq i32 %r9, 3
  br i1 %r10, label %BB4, label %BB1

BB4:                                              ; preds = %BB0
  %r11 = extractelement <4 x i32> %r8, i32 2
  %r12 = icmp eq i32 %r11, 7
  br i1 %r12, label %BB6, label %BB1

BB6:                                              ; preds = %BB4
  %r13 = extractelement <4 x i32> %r7, i32 3
  %r14 = icmp eq i32 %r13, 4
  br i1 %r14, label %BB8, label %BB1

BB8:                                              ; preds = %BB6
  br label %BB1

BB1:                                              ; preds = %BB8, %BB6, %BB4,
%BB0
  %r17 = phi i32 [ 1, %BB0 ], [ 2, %BB4 ], [ 3, %BB6 ], [ 0, %BB8 ]
  ret i32 %r17
}
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

Compile using:
llvm-as -o temp.bc bug.ll && llc -march=x86-64 -o temp.s temp.bc && gcc temp.s

This should exit with exit code 0, but it exits with code 3.

It looks like this load:
  %r7 = load <4 x i32>* %r0, align 1
gets moved pasts the stores which alias 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  Mon Dec 26 16:43:50 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 26 Dec 2011 22:43:50 +0000
Subject: [LLVMbugs] [Bug 11630] Clang fails to detect that two types are the
 same in a template
In-Reply-To: <bug-11630-206@http.llvm.org/bugs/>
References: <bug-11630-206@http.llvm.org/bugs/>
Message-ID: <bug-11630-206-33w2yR67h5@http.llvm.org/bugs/>

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

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-12-26 16:43:50 CST ---
Fixed in r147281.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 26 16:49:52 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 26 Dec 2011 22:49:52 +0000
Subject: [LLVMbugs] [Bug 10747] miscompiled extractelement instruction
In-Reply-To: <bug-10747-206@http.llvm.org/bugs/>
References: <bug-10747-206@http.llvm.org/bugs/>
Message-ID: <bug-10747-206-p78mC05PWG@http.llvm.org/bugs/>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

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

--- Comment #6 from Eli Friedman <sharparrow1 at yahoo.com> 2011-12-26 16:49:52 CST ---
r147283.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 26 17:30:47 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 26 Dec 2011 23:30:47 +0000
Subject: [LLVMbugs] [Bug 11652] New: assertion failures when Type.cpp is
 compiled with -Os
Message-ID: <bug-11652-206@http.llvm.org/bugs/>

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

             Bug #: 11652
           Summary: assertion failures when Type.cpp is compiled with -Os
           Product: new-bugs
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: nobled at dreamwidth.org
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


This is probably a GCC bug, but does anyone have advice on how to reduce it
further?

GCC version:
g++ (Ubuntu/Linaro 4.5.2-8ubuntu4) 4.5.2

With r147274 and configuring with these options:

cmake ../llvm -DCMAKE_BUILD_TYPE=Debug -DLLVM_BUILD_CLANG=OFF
-DBUILD_SHARED_LIBS=ON -DCMAKE_CXX_FLAGS=-Os

It causes assertion failures in a ton of unit tests:

.../include/llvm/Type.h:296: llvm::Type* llvm::Type::getContainedType(unsigned
int) const: Assertion `i < NumContainedTys && "Index out of range!"' failed.
Stack dump:
0.    Running pass 'X86 DAG->DAG Instruction Selection' on function '@foo1'

.../lib/Bitcode/Writer/ValueEnumerator.h:94: unsigned int
llvm::ValueEnumerator::getTypeID(llvm::Type*) const: Assertion `I !=
TypeMap.end() && "Type not in ValueEnumerator!"' failed.
Stack dump:
0.    Program arguments: bin/./opt -strip-debug 
1.    Running pass 'Bitcode Writer' on module '<stdin>'.

.../lib/Bitcode/Reader/BitcodeReader.cpp:740: bool
llvm::BitcodeReader::ParseTypeTableBody(): Assertion `TypeList[NumRecords] == 0
&& "Already read type?"' failed.

  Expected Passes    : 4167
  Expected Failures  : 50
  Unsupported Tests  : 13
  Unexpected Failures: 1437


Taking off that -DCMAKE_CXX_FLAGS=-Os makes the assertions go away. And copying
Type.cpp.o from a build *without* -Os into a build that was configured *with*
it also fixes them (where -b2 was a good build, and the current directory is a
bad one):
cp -ai ../llvm-b2/lib/VMCore/CMakeFiles/LLVMCore.dir/Type.cpp.o
lib/VMCore/CMakeFiles/LLVMCore.dir/

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

From bugzilla-daemon at llvm.org  Mon Dec 26 20:30:48 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 27 Dec 2011 02:30:48 +0000
Subject: [LLVMbugs] [Bug 11653] New: Trouble indexing (*array)[][]'s
Message-ID: <bug-11653-206@http.llvm.org/bugs/>

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

             Bug #: 11653
           Summary: Trouble indexing (*array)[][]'s
           Product: clang
           Version: 2.9
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: release blocker
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: radford at blackbean.org
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


The following should exit with a zero status and will if you comment out the
indicated line.

int main(int c, char **v)
{
    int p[20], a = 10, (*P)[2][a] = (int(*)[2][a]) p;

    if (0) (*P)[0][0] = 0; // comment me out to work around the bug             
    return &p[1*a+0] - &(*P)[1][0];
}

It fails with g++ from llvm-gcc-4.2-2.9-x86_64-apple-darwin10, and doesn't
compile with clang++ from clang+llvm-3.0-x86_64-apple-darwin11.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 26 21:02:15 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 27 Dec 2011 03:02:15 +0000
Subject: [LLVMbugs] [Bug 11654] New: Refusal to compile (*array)[][]
	assignments
Message-ID: <bug-11654-206@http.llvm.org/bugs/>

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

             Bug #: 11654
           Summary: Refusal to compile (*array)[][] assignments
           Product: clang
           Version: 2.9
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: radford at blackbean.org
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


int main(int c, char **v)
{
    const bool p = 0;
    bool q = 0;
    int a=0, (*b)[q | p ? 2 : 1]
      = (int (* )[q | p ? 2 : 1])&a;
    return (*b)[0];
}

This will not compile with g++ from llvm-gcc-4.2-2.9-x86_64-apple-darwin10
unless I s/bool/int/g, s/const//g or s/^bool/const bool/g.  Only s/^bool/const
bool/g compiles with clang++ from clang+llvm-3.0-x86_64-apple-darwin11.

The former's error message is following.  Note the identical types.

  error: cannot convert ?int (*)[(((long unsigned int)(q ? 1 : 0)) + 1u)]? to
?int (*)[(((long unsigned int)(q ? 1 : 0)) + 1u)]? in initialization

The later's is the following.  Note again the identical types.

  error: cannot initialize a variable of type 'int (*)[q | p ? 2 : 1]' with an
rvalue of type 'int (*)[q | p ? 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  Mon Dec 26 21:03:52 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 27 Dec 2011 03:03:52 +0000
Subject: [LLVMbugs] [Bug 10761] dejagnu test fails to compiler with clang
 g++.old-deja/g++.pt/ttp42.C
In-Reply-To: <bug-10761-206@http.llvm.org/bugs/>
References: <bug-10761-206@http.llvm.org/bugs/>
Message-ID: <bug-10761-206-MaEbLSS8PV@http.llvm.org/bugs/>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |sharparrow1 at yahoo.com
         Resolution|                            |DUPLICATE

--- Comment #1 from Eli Friedman <sharparrow1 at yahoo.com> 2011-12-26 21:03:52 CST ---


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

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 26 21:04:39 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 27 Dec 2011 03:04:39 +0000
Subject: [LLVMbugs] [Bug 11653] Trouble indexing (*array)[][]'s
In-Reply-To: <bug-11653-206@http.llvm.org/bugs/>
References: <bug-11653-206@http.llvm.org/bugs/>
Message-ID: <bug-11653-206-cYzLatYle1@http.llvm.org/bugs/>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |sharparrow1 at yahoo.com
         Resolution|                            |DUPLICATE

--- Comment #1 from Eli Friedman <sharparrow1 at yahoo.com> 2011-12-26 21:04:39 CST ---


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

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 26 21:05:52 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 27 Dec 2011 03:05:52 +0000
Subject: [LLVMbugs] [Bug 11654] Refusal to compile (*array)[][] assignments
In-Reply-To: <bug-11654-206@http.llvm.org/bugs/>
References: <bug-11654-206@http.llvm.org/bugs/>
Message-ID: <bug-11654-206-UqZrjqzAv7@http.llvm.org/bugs/>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |sharparrow1 at yahoo.com
         Resolution|                            |DUPLICATE

--- Comment #1 from Eli Friedman <sharparrow1 at yahoo.com> 2011-12-26 21:05:52 CST ---


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

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 27 02:44:10 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 27 Dec 2011 08:44:10 +0000
Subject: [LLVMbugs] [Bug 11655] New: clang alignment mismatch with gcc for
 ppc architecture
Message-ID: <bug-11655-206@http.llvm.org/bugs/>

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

             Bug #: 11655
           Summary: clang alignment mismatch with gcc for ppc architecture
           Product: clang
           Version: 2.9
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: LLVM Codegen
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: mackyle at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 7805
  --> http://llvm.org/bugs/attachment.cgi?id=7805
example.c file that demonstrates the issue

Items designated with "*" indicate a result from clang that differs from gcc.

#include <stddef.h>
#include <sys/sysctl.h>

CC='gcc-4.0'
  i386: offsetof(struct kinfo_proc,kp_eproc) = 196
   ppc: offsetof(struct kinfo_proc,kp_eproc) = 196
x86_64: offsetof(struct kinfo_proc,kp_eproc) = 296
 ppc64: offsetof(struct kinfo_proc,kp_eproc) = 296

CC='gcc-4.2'
  i386: offsetof(struct kinfo_proc,kp_eproc) = 196
   ppc: offsetof(struct kinfo_proc,kp_eproc) = 196
x86_64: offsetof(struct kinfo_proc,kp_eproc) = 296
 ppc64: offsetof(struct kinfo_proc,kp_eproc) = 296

clang version 2.9 (tags/RELEASE_29/final)
Target: i386-apple-darwin9
Thread model: posix
CC='clang'
  i386: offsetof(struct kinfo_proc,kp_eproc) = 196
   ppc: offsetof(struct kinfo_proc,kp_eproc) = 200 *
x86_64: offsetof(struct kinfo_proc,kp_eproc) = 296
 ppc64: offsetof(struct kinfo_proc,kp_eproc) = 296

Minimized example:

----- BEGIN example.c -----
/*
$CC -arch ppc -o example example.c
*/
#include <stddef.h>
#include <stdio.h>

struct badsize {
  long f0;
  long f1;
  long long f2;
  int f3;
  long long f4;
};

int main() {
  printf("offsetof(struct badsize,f4) = %d\n",
    (int)offsetof(struct badsize,f4));
  printf("  sizeof(struct badsize)    = %d\n",
    (int)sizeof(struct badsize));
  return 0;
}
----- END example.c -----

CC='gcc'
  i386: offsetof(struct badsize,f4) = 20
   ppc: offsetof(struct badsize,f4) = 20
x86_64: offsetof(struct badsize,f4) = 32
 ppc64: offsetof(struct badsize,f4) = 32

CC='clang'
  i386: offsetof(struct badsize,f4) = 20
   ppc: offsetof(struct badsize,f4) = 24 *
x86_64: offsetof(struct badsize,f4) = 32
 ppc64: offsetof(struct badsize,f4) = 32

CC='gcc'
  i386: sizeof(struct badsize) = 28
   ppc: sizeof(struct badsize) = 28
x86_64: sizeof(struct badsize) = 40
 ppc64: sizeof(struct badsize) = 40

CC='clang'
  i386: sizeof(struct badsize) = 28
   ppc: sizeof(struct badsize) = 32 *
x86_64: sizeof(struct badsize) = 40
 ppc64: sizeof(struct badsize) = 40


CC='gcc' sample.c output for -arch ppc:
offsetof(struct badsize,f4) = 20
  sizeof(struct badsize)    = 28

CC='clang' sample.c output for -arch ppc:
offsetof(struct badsize,f4) = 24 *
  sizeof(struct badsize)    = 32 *

The above issue makes it difficult to use clang as a gcc replacement for ppc
code.

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

From bugzilla-daemon at llvm.org  Tue Dec 27 06:26:54 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 27 Dec 2011 12:26:54 +0000
Subject: [LLVMbugs] [Bug 11656] New: switch block causes frontend to segfault
Message-ID: <bug-11656-206@http.llvm.org/bugs/>

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

             Bug #: 11656
           Summary: switch block causes frontend to segfault
           Product: clang
           Version: 3.0
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: lazar6 at illinois.edu
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 7806
  --> http://llvm.org/bugs/attachment.cgi?id=7806
switchBlock.c

switchBlock.c attached.

$ clang --version
clang version 3.0 (tags/RELEASE_30/final)
Target: x86_64-unknown-linux-gnu
Thread model: posix

$ clang switchBlock.c 
0  libLLVM-3.0.so  0x00007fd3d4f1883f
1  libLLVM-3.0.so  0x00007fd3d4f18e01
2  libpthread.so.0 0x00007fd3d4093850
3  libLLVM-3.0.so  0x00007fd3d48b7d13
llvm::SwitchInst::addCase(llvm::ConstantInt*, llvm::BasicBlock*) + 35
4  clang           0x00000000007b10ca
clang::CodeGen::CodeGenFunction::EmitCaseStmt(clang::CaseStmt const&) + 282
5  clang           0x00000000007b2c29
clang::CodeGen::CodeGenFunction::EmitSimpleStmt(clang::Stmt const*) + 201
6  clang           0x00000000007aff13
clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*) + 35
7  clang           0x00000000007b29ef
clang::CodeGen::CodeGenFunction::EmitCompoundStmt(clang::CompoundStmt const&,
bool, clang::CodeGen::AggValueSlot) + 239
8  clang           0x00000000007b2c5c
clang::CodeGen::CodeGenFunction::EmitSimpleStmt(clang::Stmt const*) + 252
9  clang           0x00000000007aff13
clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*) + 35
10 clang           0x00000000007b1f3f
clang::CodeGen::CodeGenFunction::EmitDoStmt(clang::DoStmt const&) + 479
11 clang           0x00000000007b000b
clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*) + 283
12 clang           0x00000000007b0316
clang::CodeGen::CodeGenFunction::EmitSwitchStmt(clang::SwitchStmt const&) + 550
13 clang           0x00000000007affcb
clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*) + 219
14 clang           0x00000000007b29ef
clang::CodeGen::CodeGenFunction::EmitCompoundStmt(clang::CompoundStmt const&,
bool, clang::CodeGen::AggValueSlot) + 239
15 clang           0x00000000007b2c5c
clang::CodeGen::CodeGenFunction::EmitSimpleStmt(clang::Stmt const*) + 252
16 clang           0x00000000007aff13
clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*) + 35
17 clang           0x00000000007c065c
clang::CodeGen::CodeGenFunction::GenerateCode(clang::GlobalDecl,
llvm::Function*, clang::CodeGen::CGFunctionInfo const&) + 380
18 clang           0x00000000006d629b
clang::CodeGen::CodeGenModule::EmitGlobalFunctionDefinition(clang::GlobalDecl)
+ 427
19 clang           0x00000000006d6d93
clang::CodeGen::CodeGenModule::EmitGlobalDefinition(clang::GlobalDecl) + 371
20 clang           0x00000000006d72cd
clang::CodeGen::CodeGenModule::EmitGlobal(clang::GlobalDecl) + 1293
21 clang           0x00000000006d7cab
22 clang           0x00000000006c536c
23 clang           0x00000000006c4e07
clang::BackendConsumer::HandleTopLevelDecl(clang::DeclGroupRef) + 151
24 clang           0x00000000007db214 clang::ParseAST(clang::Sema&, bool) + 292
25 clang           0x00000000006c3e13 clang::CodeGenAction::ExecuteAction() +
51
26 clang           0x00000000005c9c3f
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 319
27 clang           0x00000000005b251a
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1114
28 clang           0x00000000005aa1a4 cc1_main(char const**, char const**, char
const*, void*) + 820
29 clang           0x00000000005a8b1c main + 620
30 libc.so.6       0x00007fd3d380314d __libc_start_main + 237
31 clang           0x00000000005a9d19
Stack dump:
0.    Program arguments: /usr/bin/clang -cc1 -triple x86_64-unknown-linux-gnu
-emit-obj -mrelax-all -disable-free -disable-llvm-verifier -main-file-name
switchBlock.c -mrelocation-model static -mdisable-fp-elim -masm-verbose
-mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version
2.22.0.20111201 -momit-leaf-frame-pointer -resource-dir
/usr/bin/../lib/clang/3.0 -fmodule-cache-path /var/tmp/clang-module-cache
-internal-isystem /usr/local/include -internal-isystem
/usr/bin/../lib/clang/3.0/include -internal-externc-isystem /usr/include
-ferror-limit 19 -fmessage-length 128 -fgnu-runtime -fobjc-runtime-has-arc
-fobjc-runtime-has-weak -fobjc-fragile-abi -fdiagnostics-show-option
-fcolor-diagnostics -o /tmp/switchBlock-Cks1Vp.o -x c switchBlock.c 
1.    <eof> parser at end of file
2.    switchBlock.c:1:5: LLVM IR generation of declaration 'main'
3.    switchBlock.c:1:5: Generating code for declaration 'main'
4.    switchBlock.c:1:15: LLVM IR generation of compound statement ('{}')
5.    switchBlock.c:5:14: LLVM IR generation of compound statement ('{}')
clang: error: unable to execute command: Segmentation fault
clang: error: clang frontend command failed due to signal 2 (use -v to see
invocation)
clang: note: diagnostic msg: Please submit a bug report to
http://llvm.org/bugs/ and include command line arguments and all diagnostic
information.
clang: note: diagnostic msg: Preprocessed source(s) are located at:
clang: note: diagnostic msg: /tmp/switchBlock-fxFsAO.i

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 27 07:41:44 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 27 Dec 2011 13:41:44 +0000
Subject: [LLVMbugs] [Bug 11657] New: error in backend: Invalid operand for
 inline asm constraint 'i'! error in backend: Invalid operand for inline asm
 constraint 'i'!
Message-ID: <bug-11657-206@http.llvm.org/bugs/>

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

             Bug #: 11657
           Summary: error in backend: Invalid operand for inline asm
                    constraint 'i'! error in backend: Invalid operand for
                    inline asm constraint 'i'!
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: ismail at namtrac.org
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 7807
  --> http://llvm.org/bugs/attachment.cgi?id=7807
Reduced testcase

Sample testcase;

> cat testcase.i 
typedef int int32_t;
typedef long int intptr_t;
struct sbc_encoder_state {
 void (*sbc_calc_scalefactors)(int32_t sb_sample_f[16][2][8],
   int blocks, int channels, int subbands);
};
static void sbc_calc_scalefactors_mmx(
 int32_t sb_sample_f[16][2][8],
 int blocks, int channels, int subbands)
{
 int ch, sb;
 intptr_t blk;
 for (ch = 0; ch < channels; ch++) {
  for (sb = 0; sb < subbands; sb += 2) {
   __asm__ volatile (
    "movq         (%4), %%mm0\n"
   : "+r" (blk)
   : "r" (&sb_sample_f[0][ch][sb]),
    "i" ((char *) &sb_sample_f[1][0][0] -
     (char *) &sb_sample_f[0][0][0]),
    "i" (15)
   : "cc", "memory");
  }
 }
}
void sbc_init_primitives_mmx(struct sbc_encoder_state *state)
{
  state->sbc_calc_scalefactors = sbc_calc_scalefactors_mmx;
}


> clang -c testcase.i
fatal error: error in backend: Invalid operand for inline asm constraint 'i'!

> clang -v
clang version 3.1 (trunk 147142)
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 Dec 27 09:41:31 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 27 Dec 2011 15:41:31 +0000
Subject: [LLVMbugs] [Bug 11658] New: false positive with method that returns
 the same value in two calls
Message-ID: <bug-11658-206@http.llvm.org/bugs/>

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

             Bug #: 11658
           Summary: false positive with method that returns the same value
                    in two calls
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Static Analyzer
        AssignedTo: kremenek at apple.com
        ReportedBy: rafael.espindola at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 27 14:19:18 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 27 Dec 2011 20:19:18 +0000
Subject: [LLVMbugs] [Bug 11659] New: [CBE] bugs in
 CWriter::visitShuffleVectorInst (with patch)
Message-ID: <bug-11659-206@http.llvm.org/bugs/>

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

             Bug #: 11659
           Summary: [CBE] bugs in CWriter::visitShuffleVectorInst (with
                    patch)
           Product: new-bugs
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: matt at pharr.org
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 7808
  --> http://llvm.org/bugs/attachment.cgi?id=7808
path to fix bug

The implementation of that method implicitly assumes that the vector widths of
the shufflevector operands are half the result vector width, though this isn't
necessarily the case.

For example, if one runs "llc -march=c" on this code:

define void @foo(<4 x float> * %a, <4 x float> * %b, <2 x float> * %r) {
  %va = load <4 x float> * %a
  %vb = load <4 x float> * %b
  %s = shufflevector <4 x float> %va, <4 x float> %vb,
         <2 x i32> <i32 0, i32 4>
  store <2 x float> %s, <2 x float> * %r
  ret void
}

Then the current c backend generates the following for the shuffle (it
incorrectly thinks that the 4 index is out of bounds):

  *llvm_cbe_r = ((float  __attribute__((vector_size(8 ))) ){ ((float
*)(&llvm_cbe_va))[0],  0/*undef*/ });

With the attached patch, it generates the following, which is correct:

  *llvm_cbe_r = ((float  __attribute__((vector_size(8 ))) ){ ((float
*)(&llvm_cbe_va))[0], ((float *)(&llvm_cbe_vb))[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 Dec 27 14:50:26 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 27 Dec 2011 20:50:26 +0000
Subject: [LLVMbugs] [Bug 11660] New: set-xcode-analyzer doesn't work with
 custom Xcode install locations
Message-ID: <bug-11660-206@http.llvm.org/bugs/>

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

             Bug #: 11660
           Summary: set-xcode-analyzer doesn't work with custom Xcode
                    install locations
           Product: clang
           Version: 3.0
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: Static Analyzer
        AssignedTo: kremenek at apple.com
        ReportedBy: e28eta at yahoo.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


This is with checker-258.

The set-xcode-analyzer script has a hard-coded assumption that Xcode is located
at /Developer

This is not true on my system, and when I run it I see:
    $ ./set-xcode-analyzer --use-checker-build=/checker-258
    (+) Using Clang bundled with checker build: /checker-258
    $

It looks like it succeeded, but it never found the Clang LLVM xcspec, and so
never made a change. When I run analyze, it still uses the clang binary bundled
with Xcode.

I think it should be using `xcode-select -print-path` to find the path to the
current Developer directory. According to the man page for xcode-select, "This
is a recommended way for scripts and other tools to locate the current Xcode
folder."

I think it should also print some sort of confirmation/error based on whether
it actually changes Xcode to use the new/changed checker.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 27 15:02:21 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 27 Dec 2011 21:02:21 +0000
Subject: [LLVMbugs] [Bug 11661] New: set-xcode-analyzer fails if Python 2.7
	is installed
Message-ID: <bug-11661-206@http.llvm.org/bugs/>

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

             Bug #: 11661
           Summary: set-xcode-analyzer fails if Python 2.7 is installed
           Product: clang
           Version: 3.0
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Static Analyzer
        AssignedTo: kremenek at apple.com
        ReportedBy: e28eta at yahoo.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


This is with checker-258, on OS X 10.6.8.

I have python 2.7 installed as a dependency of something else through MacPorts.
When I run set-xcode-analyzer, it fails with an import error:

$ ./set-xcode-analyzer 
Traceback (most recent call last):
  File "./set-xcode-analyzer", line 9, in <module>
    from AppKit import *
ImportError: No module named AppKit


Searching the web for this particular error or to find the download for AppKit
fails, because it apparently comes bundled with the OS. I finally found it with
a `locate`

I don't know the best way to solve this. I changed the first line of the script
to run python2.6 instead of python, and that worked for my machine. I don't
think the same fix would work for everyone.

Maybe just some documentation that users need to use a python that came bundled
with their OS? Or a way to detect and print a helpful tip to the user when the
script fails?

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 27 15:16:39 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 27 Dec 2011 21:16:39 +0000
Subject: [LLVMbugs] [Bug 11642] -fvisibility-inlines-hidden should not hide
 explicit instantiations
In-Reply-To: <bug-11642-206@http.llvm.org/bugs/>
References: <bug-11642-206@http.llvm.org/bugs/>
Message-ID: <bug-11642-206-qnUSpccavs@http.llvm.org/bugs/>

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

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

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

--- Comment #2 from Rafael ?vila de Esp?ndola <rafael.espindola at gmail.com> 2011-12-27 15:16:39 CST ---
Fixed in r147295.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 27 15:48:02 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 27 Dec 2011 21:48:02 +0000
Subject: [LLVMbugs] [Bug 11662] New: vector select with i8s seems to be
	broken
Message-ID: <bug-11662-206@http.llvm.org/bugs/>

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

             Bug #: 11662
           Summary: vector select with i8s seems to be broken
           Product: new-bugs
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: matt at pharr.org
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 7809
  --> http://llvm.org/bugs/attachment.cgi?id=7809
bitcode

See the attached test case, which does a vector select with compile-time
constant values for all operands.  It should produce the result <100, 2, 100,
4, 100, 6, 100 8>, and does so if the select operands are i16, i32, or i64
types.  However, if it is a vector of i8s, then the result returned is <100,
100, 100, 100, 100, 100, 100, 100>


% llc bug.ll -o bug.s && clang bug.s bug.cpp && ./a.out
0: x8 = 100.0    x16 = 100.0    x32 = 100.0    x64 = 100.0
1: x8 = 100.0    x16 = 2.0    x32 = 2.0    x64 = 2.0
2: x8 = 100.0    x16 = 100.0    x32 = 100.0    x64 = 100.0
3: x8 = 100.0    x16 = 4.0    x32 = 4.0    x64 = 4.0
4: x8 = 100.0    x16 = 100.0    x32 = 100.0    x64 = 100.0
5: x8 = 100.0    x16 = 6.0    x32 = 6.0    x64 = 6.0
6: x8 = 100.0    x16 = 100.0    x32 = 100.0    x64 = 100.0
7: x8 = 100.0    x16 = 8.0    x32 = 8.0    x64 = 8.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 Dec 27 16:31:27 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 27 Dec 2011 22:31:27 +0000
Subject: [LLVMbugs] [Bug 11663] New: ctzdi2: endless recursion
Message-ID: <bug-11663-206@http.llvm.org/bugs/>

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

             Bug #: 11663
           Summary: ctzdi2: endless recursion
           Product: compiler-rt
           Version: unspecified
          Platform: Other
        OS/Version: FreeBSD
            Status: NEW
          Severity: normal
          Priority: P
         Component: compiler-rt
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: ed at 80386.nl
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


On FreeBSD/sparc64, using GCC 4.2.1, ctzdi2.c compilers to the following code:

0000000000000000 <__ctzdi2>:
   0:   9d e3 bf 40     save  %sp, -192, %sp
   4:   82 10 00 18     mov  %i0, %g1
   8:   80 a0 00 18     cmp  %g0, %i0
   c:   85 3e 30 20     srax  %i0, 0x20, %g2
  10:   b0 40 3f ff     addc  %g0, -1, %i0
  14:   90 38 00 18     xnor  %g0, %i0, %o0
  18:   84 0e 00 02     and  %i0, %g2, %g2
  1c:   90 0a 00 01     and  %o0, %g1, %o0
  20:   b0 0e 20 20     and  %i0, 0x20, %i0
  24:   90 12 00 02     or  %o0, %g2, %o0
  28:   40 00 00 00     call  28 <__ctzdi2+0x28>
  2c:   91 32 20 00     srl  %o0, 0, %o0
  30:   b0 06 00 08     add  %i0, %o0, %i0
  34:   81 cf e0 08     rett  %i7 + 8
  38:   91 3a 20 00     sra  %o0, 0, %o0
  3c:   01 00 00 00     nop 

This is due to the fact that __builtin_ctz() emits a call to __ctzdi2(). This
prevents FreeBSD from switching from libgcc to libcompiler_rt on SPARC64.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 27 19:29:45 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 28 Dec 2011 01:29:45 +0000
Subject: [LLVMbugs] [Bug 11664] New: std::getline requires 2 enters to
	unblock
Message-ID: <bug-11664-206@http.llvm.org/bugs/>

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

             Bug #: 11664
           Summary: std::getline requires 2 enters to unblock
           Product: libc++
           Version: unspecified
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: All Bugs
        AssignedTo: hhinnant at apple.com
        ReportedBy: felixcca at yahoo.ca
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 7811
  --> http://llvm.org/bugs/attachment.cgi?id=7811
A very simple test case that demonstrates the problem.

When using std::getline(std::istream&, std::string&) with std::cin, and when
the standard input is connected to the terminal, the function will not return
when the user presses 'enter' (as it does when using libcpp's getline).
Instead, the user has to press the 'enter' key twice.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 27 20:02:08 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 28 Dec 2011 02:02:08 +0000
Subject: [LLVMbugs] [Bug 11665] New: Crash accessing field of union
 explicitly initialized by calling the default constructor
Message-ID: <bug-11665-206@http.llvm.org/bugs/>

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

             Bug #: 11665
           Summary: Crash accessing field of union explicitly initialized
                    by calling the default constructor
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++0x
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: jwalden+llvm at mit.edu
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified


[jwalden at wheres-wally plugin-ice]$ cat minimal.ii 
void f()
{
  union U { int field; } u = U();
  (void)U().field;
}
[jwalden at wheres-wally plugin-ice]$
~/Programs/clang-build/build/Release/bin/clang++ -std=c++11 minimal.ii 
0  clang           0x0000000001b5a42f
1  clang           0x0000000001b5a899
2  libpthread.so.0 0x000000358f00eef0
3  clang           0x00000000008035fd
clang::CodeGen::CodeGenFunction::EmitAutoVarInit(clang::CodeGen::CodeGenFunction::AutoVarEmission
const&) + 381
4  clang           0x00000000008086c1
clang::CodeGen::CodeGenFunction::EmitAutoVarDecl(clang::VarDecl const&) + 33
5  clang           0x000000000089261f
clang::CodeGen::CodeGenFunction::EmitDeclStmt(clang::DeclStmt const&) + 95
6  clang           0x00000000008988b7
clang::CodeGen::CodeGenFunction::EmitSimpleStmt(clang::Stmt const*) + 87
7  clang           0x0000000000895c13
clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*) + 35
8  clang           0x00000000008986ef
clang::CodeGen::CodeGenFunction::EmitCompoundStmt(clang::CompoundStmt const&,
bool, clang::CodeGen::AggValueSlot) + 239
9  clang           0x0000000000898963
clang::CodeGen::CodeGenFunction::EmitSimpleStmt(clang::Stmt const*) + 259
10 clang           0x0000000000895c13
clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*) + 35
11 clang           0x00000000008a5f6c
clang::CodeGen::CodeGenFunction::GenerateCode(clang::GlobalDecl,
llvm::Function*, clang::CodeGen::CGFunctionInfo const&) + 380
12 clang           0x00000000007b23bb
clang::CodeGen::CodeGenModule::EmitGlobalFunctionDefinition(clang::GlobalDecl)
+ 427
13 clang           0x00000000007b2df3
clang::CodeGen::CodeGenModule::EmitGlobalDefinition(clang::GlobalDecl) + 371
14 clang           0x00000000007b331d
clang::CodeGen::CodeGenModule::EmitGlobal(clang::GlobalDecl) + 1277
15 clang           0x00000000007b3ceb
16 clang           0x000000000079eeec
17 clang           0x000000000079e6b7
18 clang           0x00000000008c54a4 clang::ParseAST(clang::Sema&, bool) + 292
19 clang           0x000000000067acfd
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 317
20 clang           0x0000000000661a2a
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1114
21 clang           0x00000000006580ba cc1_main(char const**, char const**, char
const*, void*) + 826
22 clang           0x0000000000643176 main + 678
23 libc.so.6       0x000000358ec2139d __libc_start_main + 237
24 clang           0x0000000000657c2d
Stack dump:
0.    Program arguments:
/home/jwalden/Programs/clang-build/build/Release/bin/clang -cc1 -triple
x86_64-unknown-linux-gnu -emit-obj -mrelax-all -disable-free
-disable-llvm-verifier -main-file-name minimal.ii -mrelocation-model static
-mdisable-fp-elim -masm-verbose -mconstructor-aliases -munwind-tables
-target-cpu x86-64 -target-linker-version 2.21.51.0.6 -momit-leaf-frame-pointer
-resource-dir
/home/jwalden/Programs/clang-build/build/Release/bin/../lib/clang/3.1
-std=c++11 -fdeprecated-macro -fdebug-compilation-dir /tmp/plugin-ice
-ferror-limit 19 -fmessage-length 143 -mstackrealign -fgnu-runtime
-fobjc-runtime-has-arc -fobjc-runtime-has-weak -fobjc-fragile-abi
-fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o
/tmp/minimal-TRoJXc.o -x c++-cpp-output minimal.ii 
1.    <eof> parser at end of file
2.    minimal.ii:1:6: LLVM IR generation of declaration 'f'
3.    minimal.ii:1:6: Generating code for declaration 'f'
4.    minimal.ii:2:1: LLVM IR generation of compound statement ('{}')
clang: error: unable to execute command: Segmentation fault (core dumped)
clang: error: clang frontend command failed due to signal (use -v to see
invocation)
clang: note: diagnostic msg: Please submit a bug report to
http://llvm.org/bugs/ and include command line arguments and all diagnostic
information.
clang: note: diagnostic msg: Error generating preprocessed source(s) - no
preprocessable inputs.
[jwalden at wheres-wally plugin-ice]$ (cd ~/Programs/clang-build/llvm/ && svn info
&& cd ~/Programs/clang-build/llvm/tools/clang/ && svn info; )
Path: .
URL: http://llvm.org/svn/llvm-project/llvm/trunk
Repository Root: http://llvm.org/svn/llvm-project
Repository UUID: 91177308-0d34-0410-b5e6-96231b3b80d8
Revision: 147303
Node Kind: directory
Schedule: normal
Last Changed Author: rafael
Last Changed Rev: 147296
Last Changed Date: 2011-12-27 15:37:11 -0600 (Tue, 27 Dec 2011)

Path: .
URL: http://llvm.org/svn/llvm-project/cfe/trunk
Repository Root: http://llvm.org/svn/llvm-project
Repository UUID: 91177308-0d34-0410-b5e6-96231b3b80d8
Revision: 147303
Node Kind: directory
Schedule: normal
Last Changed Author: dgregor
Last Changed Rev: 147299
Last Changed Date: 2011-12-27 16:43:10 -0600 (Tue, 27 Dec 2011)

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 27 20:52:55 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 28 Dec 2011 02:52:55 +0000
Subject: [LLVMbugs] [Bug 11666] New: local/unnamed types as template
 arguments extension in c++98 is non-conforming
Message-ID: <bug-11666-206@http.llvm.org/bugs/>

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

             Bug #: 11666
           Summary: local/unnamed types as template arguments extension in
                    c++98 is non-conforming
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: richard-llvm at metafoo.co.uk
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified


template<typename T> int f(T t) { return 1; } // #1
int f(int n) { return 2; } // #2
int g() {
  enum { E };
  return f(E);
}

In C++11 mode, g() will return 1.

In C++98 mode, it looks like g() must return 2, because #1 has (what looks
like) a substitution failure (since it attempts to use an unnamed local type as
a template argument). However, when built with clang in C++98 mode, it returns
1, and produces an ExtWarn diagnostic. This both generates wrong code (and
potentially rejects valid if instantiating f fails), and causes -Werror builds
to fail.

It's not entirely clear that clang is at fault here: while clang calls #1 and
g++ calls #2, EDG produces a hard error (using local type as template
argument). However, if clang's ExtWarn is upgraded to an Error (as it was prior
to this extension being added), we accept this code and call #2.

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

From bugzilla-daemon at llvm.org  Wed Dec 28 02:17:34 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 28 Dec 2011 08:17:34 +0000
Subject: [LLVMbugs] [Bug 11659] [CBE] bugs in
 CWriter::visitShuffleVectorInst (with patch)
In-Reply-To: <bug-11659-206@http.llvm.org/bugs/>
References: <bug-11659-206@http.llvm.org/bugs/>
Message-ID: <bug-11659-206-ZUyiSwFL0K@http.llvm.org/bugs/>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #1 from Chris Lattner <clattner at apple.com> 2011-12-28 02:17:34 CST ---
Hi Matt,  please send patches to llvm-commits, thanks!

FYI, the CBE is quite broken in many ways.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 28 06:33:20 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 28 Dec 2011 12:33:20 +0000
Subject: [LLVMbugs] [Bug 11667] New: [Patch] assembly-written implementation
 of {u, }{div, mod}si3 for SPARC64
Message-ID: <bug-11667-206@http.llvm.org/bugs/>

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

             Bug #: 11667
           Summary: [Patch] assembly-written implementation of
                    {u,}{div,mod}si3 for SPARC64
           Product: compiler-rt
           Version: unspecified
          Platform: Sun
        OS/Version: FreeBSD
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: compiler-rt
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: ed at 80386.nl
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 7812
  --> http://llvm.org/bugs/attachment.cgi?id=7812
{u,}{div,mod}si3 for SPARC64

According to a developer at the FreeBSD project, FreeBSD's total compilation
time increases by 2.6% when the host system is built against compiler-rt
instead of libgcc. This is likely due to the fact that GCC has assembly-written
versions of the division and modulo routines, while compiler-rt does not.

The division and modulo routines used by GCC can easily be re-used by
compiler-rt. They are provided for free in The SPARC Architecture Manual
Version 8. Attached to this bug report is a patch that I have written for
compiler-rt. It contains the M4 file that is listed in the manual, with some
small modifications:

- The M4 file uses exponentiation (2^N). This seems to be a Sun-specific
extension to M4, as I cannot reproduce it with GNU and BSD m4. Fix this similar
to OpenBSD's version by replacing 2^N with TWOSUPN.

- Use the same register layout as GCC's version.

- Integrate into compiler-rt's codebase by using DEFINE_COMPILERRT_FUNCTION().

The patch lacks modifications to CMake files, but this is due to the fact that
we use a custom BSD makefile.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 28 07:09:44 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 28 Dec 2011 13:09:44 +0000
Subject: [LLVMbugs] [Bug 11662] vector select with i8s seems to be broken
In-Reply-To: <bug-11662-206@http.llvm.org/bugs/>
References: <bug-11662-206@http.llvm.org/bugs/>
Message-ID: <bug-11662-206-HkK8a8agQx@http.llvm.org/bugs/>

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

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-12-28 07:09:44 CST ---
Fixed in 147309.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 28 09:49:39 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 28 Dec 2011 15:49:39 +0000
Subject: [LLVMbugs] [Bug 10471] FLT_EVAL_METHOD sometimes wrong for Intel
	FPUs
In-Reply-To: <bug-10471-206@http.llvm.org/bugs/>
References: <bug-10471-206@http.llvm.org/bugs/>
Message-ID: <bug-10471-206-KXLH4QZmos@http.llvm.org/bugs/>

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

Benjamin Kramer <benny.kra at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
                 CC|                            |benny.kra at gmail.com
         Resolution|                            |FIXED

--- Comment #3 from Benjamin Kramer <benny.kra at gmail.com> 2011-12-28 09:49:39 CST ---
With clang r147311 the value now depends on the availability of SSE.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 28 10:05:53 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 28 Dec 2011 16:05:53 +0000
Subject: [LLVMbugs] [Bug 11668] New: Support of HURD
Message-ID: <bug-11668-206@http.llvm.org/bugs/>

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

             Bug #: 11668
           Summary: Support of HURD
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: System Library
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: sylvestre at debian.org
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 7813
  --> http://llvm.org/bugs/attachment.cgi?id=7813
HURD bug fixes

Could you apply the attached patch (just generated against the SVN) ?
It allows llvm to build and run under GNU/HURD.

For the record, the build log of LLVM 3.0 with this patch is available here:

https://buildd.debian.org/status/fetch.php?pkg=llvm-3.0&arch=hurd-i386&ver=3.0-5&stamp=1324414499 

The patch has been written by Pino Toscano, me and a few others
The last bug report concerning this is here:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=652283

A first step has been applied from the bug #11620

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 28 10:15:34 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 28 Dec 2011 16:15:34 +0000
Subject: [LLVMbugs] [Bug 11669] New: Support of mipsel
Message-ID: <bug-11669-206@http.llvm.org/bugs/>

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

             Bug #: 11669
           Summary: Support of mipsel
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: System Library
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: sylvestre at debian.org
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 7814
  --> http://llvm.org/bugs/attachment.cgi?id=7814
mipsel support

Recent mips CPU (called mipsel) shows themself as "mipsel" in target. 
This causes the current detection (mips-*) to fail.

The attached patch fixes it. It has been generated against the current svn.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 28 10:36:53 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 28 Dec 2011 16:36:53 +0000
Subject: [LLVMbugs] [Bug 11670] New: Please allow llvm to support armhf
	hardware
Message-ID: <bug-11670-206@http.llvm.org/bugs/>

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

             Bug #: 11670
           Summary: Please allow llvm to support armhf hardware
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: System Library
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: sylvestre at debian.org
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 7815
  --> http://llvm.org/bugs/attachment.cgi?id=7815
Support of armhf

It would be nice if you could apply the attached patch. It has been generated
against the last llvm svn
It allows LLVM to run on Arm Hard Float CPU (armhf or called also armv7).

A new gcc triple has been introduced which requires LLVM to be updated.

It builds without any problem:
https://buildd.debian.org/status/fetch.php?pkg=llvm-3.0&arch=armhf&ver=3.0-5&stamp=1324362164

More information on the debian port:
http://wiki.debian.org/ArmHardFloatPort

and the impact of this triple on llvm:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=642127

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 28 10:58:39 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 28 Dec 2011 16:58:39 +0000
Subject: [LLVMbugs] [Bug 11671] New: Missing categories
Message-ID: <bug-11671-206@http.llvm.org/bugs/>

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

             Bug #: 11671
           Summary: Missing categories
           Product: Bugzilla Admin
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Products
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: sylvestre at debian.org
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Could you create the following categories in the bug tracker ?

* clang 
=> libclang

* LLVM 
=> Build system

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 Dec 28 11:05:05 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 28 Dec 2011 17:05:05 +0000
Subject: [LLVMbugs] [Bug 11672] New: Please provide an soname for libclang
Message-ID: <bug-11672-206@http.llvm.org/bugs/>

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

             Bug #: 11672
           Summary: Please provide an soname for libclang
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Driver
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: sylvestre at debian.org
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 7816
  --> http://llvm.org/bugs/attachment.cgi?id=7816
libclang soname

The attached patch adds an SONAME to the libclang library.
It would be nice and helpful for distro tools to have a soname.

I am available to improve this patch if needed.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 28 11:08:48 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 28 Dec 2011 17:08:48 +0000
Subject: [LLVMbugs] [Bug 11669] Support of mipsel
In-Reply-To: <bug-11669-206@http.llvm.org/bugs/>
References: <bug-11669-206@http.llvm.org/bugs/>
Message-ID: <bug-11669-206-b06GQlRn63@http.llvm.org/bugs/>

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

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

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

--- Comment #1 from Rafael ?vila de Esp?ndola <rafael.espindola at gmail.com> 2011-12-28 11:08:48 CST ---
Fixed in r147312.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 28 11:19:46 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 28 Dec 2011 17:19:46 +0000
Subject: [LLVMbugs] [Bug 11673] New: Please support the other naming scheme
	of Debian
Message-ID: <bug-11673-206@http.llvm.org/bugs/>

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

             Bug #: 11673
           Summary: Please support the other naming scheme of Debian
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Headers
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: sylvestre at debian.org
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 7817
  --> http://llvm.org/bugs/attachment.cgi?id=7817
Detection of version Debian name with numbers

In some releases of Debian, the content of /etc/debian_version is not the
codename of the release (ie squeeze/sid or wheezy/sid) but the version number
(example 6.0.3)

This causes the clang detection to fails.
The attached patch fixes it.

It has been originaly reported here:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=651301

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 28 12:17:48 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 28 Dec 2011 18:17:48 +0000
Subject: [LLVMbugs] [Bug 11673] Please support the other naming scheme of
	Debian
In-Reply-To: <bug-11673-206@http.llvm.org/bugs/>
References: <bug-11673-206@http.llvm.org/bugs/>
Message-ID: <bug-11673-206-IxvfezGYI4@http.llvm.org/bugs/>

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

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

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

--- Comment #1 from Rafael ?vila de Esp?ndola <rafael.espindola at gmail.com> 2011-12-28 12:17:48 CST ---
Fixed in r147313.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 28 12:46:56 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 28 Dec 2011 18:46:56 +0000
Subject: [LLVMbugs] [Bug 11649] Crash in 'ObjC ARC optimization' pass
In-Reply-To: <bug-11649-206@http.llvm.org/bugs/>
References: <bug-11649-206@http.llvm.org/bugs/>
Message-ID: <bug-11649-206-Df294tEOvQ@http.llvm.org/bugs/>

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

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

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

--- Comment #2 from Bob Wilson <bob.wilson at apple.com> 2011-12-28 12:46:56 CST ---
Dan already fixed this in svn r147098

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 28 14:23:09 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 28 Dec 2011 20:23:09 +0000
Subject: [LLVMbugs] [Bug 11674] New: Codegen for vector float->double cast
 fails on x86 above SSE3
Message-ID: <bug-11674-206@http.llvm.org/bugs/>

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

             Bug #: 11674
           Summary: Codegen for vector float->double cast fails on x86
                    above SSE3
           Product: libraries
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: X86
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: jrk at csail.mit.edu
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 7818
  --> http://llvm.org/bugs/attachment.cgi?id=7818
ll code which tickles error

I've isolated a bug in SSE codegen to the attached example.

    define void @f(<2 x float>* %in, <2 x double>* %out) {
    entry:
      %0 = load <2 x float>* %in, align 8
      %1 = fpext <2 x float> %0 to <2 x double>
      store <2 x double> %1, <2 x double>* %out, align 1
      ret void
    }

The code should load a <2 x float> vector from %in, fpext cast it to a
<2 x double>, and do an unaligned store (movupd) of the result to %out. This
works as expected on earlier SSE targets, generating this with llc -mcpu=core2:


    movss    (%rdi), %xmm1
    movss    4(%rdi), %xmm0
    cvtss2sd    %xmm0, %xmm0
    cvtss2sd    %xmm1, %xmm1
    unpcklpd    %xmm0, %xmm1    ## xmm1 = xmm1[0],xmm0[0]
    movupd    %xmm1, (%rsi)
    ret

Load both, cast float to double (cvtss2sd), pack vectors, and store.

But with llc -mcpu=penryn or greater, it yields nonsense:

    movq    (%rdi), %xmm0
    pshufd    $16, %xmm0, %xmm0       ## xmm0 = xmm0[0,0,1,0]
    movdqu    %xmm0, (%rsi)
    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 Dec 28 15:25:26 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 28 Dec 2011 21:25:26 +0000
Subject: [LLVMbugs] [Bug 11674] Codegen for vector float->double cast fails
 on x86 above SSE3
In-Reply-To: <bug-11674-206@http.llvm.org/bugs/>
References: <bug-11674-206@http.llvm.org/bugs/>
Message-ID: <bug-11674-206-6Pcbqm5k4b@http.llvm.org/bugs/>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |sharparrow1 at yahoo.com
         Resolution|                            |FIXED

--- Comment #1 from Eli Friedman <sharparrow1 at yahoo.com> 2011-12-28 15:25:26 CST ---
r147323.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 28 16:43:58 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 28 Dec 2011 22:43:58 +0000
Subject: [LLVMbugs] [Bug 11664] std::getline requires 2 enters to unblock
In-Reply-To: <bug-11664-206@http.llvm.org/bugs/>
References: <bug-11664-206@http.llvm.org/bugs/>
Message-ID: <bug-11664-206-PBOCoKT8jE@http.llvm.org/bugs/>

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

Howard Hinnant <hhinnant at apple.com> changed:

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

--- Comment #1 from Howard Hinnant <hhinnant at apple.com> 2011-12-28 16:43:58 CST ---


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

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 28 21:19:59 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 29 Dec 2011 03:19:59 +0000
Subject: [LLVMbugs] [Bug 11653] Trouble indexing (*array)[][]'s
In-Reply-To: <bug-11653-206@http.llvm.org/bugs/>
References: <bug-11653-206@http.llvm.org/bugs/>
Message-ID: <bug-11653-206-2p42yEB215@http.llvm.org/bugs/>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|-New Bugs                   |new bugs
         Resolution|DUPLICATE                   |WONTFIX
         AssignedTo|unassignedclangbugs at nondot. |unassignedbugs at nondot.org
                   |org                         |
            Product|clang                       |new-bugs

--- Comment #3 from Eli Friedman <sharparrow1 at yahoo.com> 2011-12-28 21:19:59 CST ---
Oh, sorry, I didn't read the report carefully enough to spot that this wasn't
against clang.  As stated in the LLVM 3.0 release notes, llvm-gcc is no longer
supported.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 29 01:26:28 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 29 Dec 2011 07:26:28 +0000
Subject: [LLVMbugs] [Bug 11671] Missing categories in the bug tracker
In-Reply-To: <bug-11671-206@http.llvm.org/bugs/>
References: <bug-11671-206@http.llvm.org/bugs/>
Message-ID: <bug-11671-206-JKVMhgCqRi@http.llvm.org/bugs/>

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

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-12-29 01:26:28 CST ---
I added Clang/libclang.  For build system work please use the "Build scripts"
product.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 29 02:25:52 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 29 Dec 2011 08:25:52 +0000
Subject: [LLVMbugs] [Bug 11675] New: Improvement for Objective-C code
	analyzing
Message-ID: <bug-11675-206@http.llvm.org/bugs/>

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

             Bug #: 11675
           Summary: Improvement for Objective-C code analyzing
           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: eugene.v.smirnov at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


I believe that this check will be good
1) Check when objects has custom implementation for -[NSObject isEqual] but
-[NSObject hash] is not implemented
2) Warning when comparing two NSObjects using == operator;

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 29 20:08:50 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 30 Dec 2011 02:08:50 +0000
Subject: [LLVMbugs] [Bug 11436] missing cpuid.h
In-Reply-To: <bug-11436-206@http.llvm.org/bugs/>
References: <bug-11436-206@http.llvm.org/bugs/>
Message-ID: <bug-11436-206-FDfdnaebUh@http.llvm.org/bugs/>

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

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  Thu Dec 29 20:28:10 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 30 Dec 2011 02:28:10 +0000
Subject: [LLVMbugs] [Bug 11676] New: crash with empty union with -std=c++0x
Message-ID: <bug-11676-206@http.llvm.org/bugs/>

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

             Bug #: 11676
           Summary: crash with empty union with -std=c++0x
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: LLVM Codegen
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: rafael.espindola at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


clang -cc1 -S -std=c++0x crashes on

union _XEvent {
};
void ProcessEvent() {
  _XEvent pluginEvent = _XEvent();
}

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 29 21:15:03 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 30 Dec 2011 03:15:03 +0000
Subject: [LLVMbugs] [Bug 11676] crash with empty union with -std=c++0x
In-Reply-To: <bug-11676-206@http.llvm.org/bugs/>
References: <bug-11676-206@http.llvm.org/bugs/>
Message-ID: <bug-11676-206-yNs1fUcHfg@http.llvm.org/bugs/>

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

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

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

--- Comment #1 from Rafael ?vila de Esp?ndola <rafael.espindola at gmail.com> 2011-12-29 21:15:03 CST ---
Fixed in r147362 by reverting r147271.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 29 22:19:17 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 30 Dec 2011 04:19:17 +0000
Subject: [LLVMbugs] [Bug 11665] Crash accessing field of union explicitly
 initialized by calling the default constructor
In-Reply-To: <bug-11665-206@http.llvm.org/bugs/>
References: <bug-11665-206@http.llvm.org/bugs/>
Message-ID: <bug-11665-206-mliKJ08oOR@http.llvm.org/bugs/>

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

Jeff Walden (remove +llvm to email) <jwalden+llvm at mit.edu> changed:

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

--- Comment #1 from Jeff Walden (remove +llvm to email) <jwalden+llvm at mit.edu> 2011-12-29 22:19:17 CST ---


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

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 29 22:20:20 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 30 Dec 2011 04:20:20 +0000
Subject: [LLVMbugs] [Bug 11677] New: lto lazy-loading produces invalid ir
Message-ID: <bug-11677-206@http.llvm.org/bugs/>

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

             Bug #: 11677
           Summary: lto lazy-loading produces invalid ir
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Linker
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: nicholas at mxc.ca
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


This .ll file:

@table = constant i8* blockaddress(@func, %bb)
define void @func() {
  unreachable
bb:
  unreachable
}

breaks in LTO:

$ ld --plugin LLVMgold.so x.bc -shared -o x.so
invalid linkage type for global declaration
i8* @0
Broken module found, compilation aborted!
Stack dump:
0.    Running pass 'Function Pass Manager' on module 'ld-temp.o'.

What's @0? Taking a look with gdb, it's the not-materialized blockaddress
constant:

Breakpoint 2, LTOCodeGenerator::addModule (this=0x6b6ff0, mod=0x702d80,
    errMsg=...) at LTOCodeGenerator.cpp:93
93        bool ret = _linker.LinkInModule(mod->getLLVVMModule(), &errMsg);
(gdb) call mod->getLLVVMModule()->dump()

@table = constant i8* @0
@0 = internal global i8

; Materializable
declare void @func()
(gdb)

Whoops!

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 30 02:11:57 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 30 Dec 2011 08:11:57 +0000
Subject: [LLVMbugs] [Bug 6404] Provide llvm-config.cmake file for
 find_package(llvm ...) support
In-Reply-To: <bug-6404-206@http.llvm.org/bugs/>
References: <bug-6404-206@http.llvm.org/bugs/>
Message-ID: <bug-6404-206-6QuSFvtIDe@http.llvm.org/bugs/>

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

arrowdodger <6yearold at gmail.com> changed:

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

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

From bugzilla-daemon at llvm.org  Fri Dec 30 02:30:13 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 30 Dec 2011 08:30:13 +0000
Subject: [LLVMbugs] [Bug 6148] Some LLVM tests fail, when build with cmake,
 if clang isn't built
In-Reply-To: <bug-6148-206@http.llvm.org/bugs/>
References: <bug-6148-206@http.llvm.org/bugs/>
Message-ID: <bug-6148-206-a66tjhGN9a@http.llvm.org/bugs/>

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

arrowdodger <6yearold at gmail.com> changed:

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

--- Comment #1 from arrowdodger <6yearold at gmail.com> 2011-12-30 02:30:13 CST ---
LLVMC is no more, so there are no tests for 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  Fri Dec 30 05:57:19 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 30 Dec 2011 11:57:19 +0000
Subject: [LLVMbugs] [Bug 11678] New: "Getting Started" docs out of date
Message-ID: <bug-11678-206@http.llvm.org/bugs/>

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

             Bug #: 11678
           Summary: "Getting Started" docs out of date
           Product: clang
           Version: 2.9
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Documentation
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: zilla at kayari.org
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


http://clang.llvm.org/get_started.html

step 4 should be 'cd ../projects' not 'cd llvm/projects' because after step 3
you're already in llvm/tools

I think step 6 is out of date, instead of hacking the sources I think it's now
possible to simply configure with --with-cxx-include-root and
--with-cxx-include-arch

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Dec 30 14:34:56 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 30 Dec 2011 20:34:56 +0000
Subject: [LLVMbugs] [Bug 11680] New: scan-build errors on c++ includes in .c
 files, while clang++ does not
Message-ID: <bug-11680-206@http.llvm.org/bugs/>

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

             Bug #: 11680
           Summary: scan-build errors on c++ includes in .c files, while
                    clang++ does not
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Static Analyzer
        AssignedTo: kremenek at apple.com
        ReportedBy: fedorabugmail at yahoo.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


clang++ and g++ both successfully build my code which has source files with
extensions cpp and c . However scan-build complains about the presence of C++
includes in any file with a .c extension and does not analyze those files.
Using the --use-c++ switch causes the entire analysis to fail.

The command line used for compilation is:
g++ -O3 -Wall \
<list_of_files>

Adding the option --use-c++ causes the below error:
~/llvm/llvm/tools/clang/tools/scan-build/scan-build --use-c++ g++ \
<list_of_files>

Can't exec "<first_file_in_list.cpp>": Permission denied at
~/llvm/llvm/tools/clang/tools/scan-build/scan-build line 923.


scan-build will fail on this code, but clang++ will succeed.

#include <string>

int main(int argc, char * argv[])
{
  std::string temp;
  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 Dec 30 15:34:52 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 30 Dec 2011 21:34:52 +0000
Subject: [LLVMbugs] [Bug 11681] New: Problem with glibc headers and
	-D_FORTIFY_SOURCE=2
Message-ID: <bug-11681-206@http.llvm.org/bugs/>

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

             Bug #: 11681
           Summary: Problem with glibc headers and -D_FORTIFY_SOURCE=2
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: ismail at namtrac.org
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 7821
  --> http://llvm.org/bugs/attachment.cgi?id=7821
Preprocessed source code

idoenmez at havana:~> cat t.c
#include <stdio.h>

extern int asprintf (char **, const char *, ...) 
__attribute__((__format__(__printf__,2,3)));

idoenmez at havana:~> clang -O2 -D_FORTIFY_SOURCE=2 -fstack-protector
-D_GNU_SOURCE -c -save-temps t.c
In file included from t.c:1:
t.c:3:37: error: expected parameter declarator
extern int __asprintf_chk (char **, 2 - 1, const char *, ...)
__attribute__((__format__(__printf__,2,3)));
                                    ^
t.c:3:37: error: expected ')'
t.c:3:27: note: to match this '('
extern int __asprintf_chk (char **, 2 - 1, const char *, ...)
__attribute__((__format__(__printf__,2,3)));
                          ^
t.c:3:12: error: conflicting types for '__asprintf_chk'
extern int __asprintf_chk (char **, 2 - 1, const char *, ...)
__attribute__((__format__(__printf__,2,3)));
           ^
/usr/include/bits/stdio2.h:133:12: note: previous declaration is here
extern int __asprintf_chk (char **__restrict __ptr, int __flag,
           ^
In file included from t.c:1:
t.c:3:78: error: 'format' attribute parameter 2 is out of bounds
extern int __asprintf_chk (char **, 2 - 1, const char *, ...)
__attribute__((__format__(__printf__,2,3)));
                                                                             ^ 
                   ~
4 errors generated.

Preprocessed source code is 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.