From bugzilla-daemon at llvm.org  Mon Apr  1 06:19:51 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 01 Apr 2013 13:19:51 +0000
Subject: [LLVMbugs] [Bug 15633] New: a bug involving defining enumeration
 outside of template class body
Message-ID: <bug-15633-206@http.llvm.org/bugs/>

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

            Bug ID: 15633
           Summary: a bug involving defining enumeration outside of
                    template class body
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++11
          Assignee: unassignedclangbugs at nondot.org
          Reporter: zhangxiongpang at gmail.com
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Platform: linux, x86_84, clang++3.3 (trunk 177699), g++4.7.2

Today I wrote some code testing c++11 "Forwarding declaration of enumerations".
And a strange thing occurred. The following code makes clang++ core dump and
makes g++ got into a dead loop.
----------------------------------
template <class T>
struct X {
    struct Y {
        enum class E : T;
    };
};

template <class T>
enum class X<T>::Y::E : T { e1, e2 };

template class X<int>;
----------------------------------

The core dump information is as follows:
----------------------------------
clang:
/root/work/newdisk/zhang/llvm/llvm/tools/clang/lib/Sema/SemaTemplate.cpp:863:
clang::DeclResult clang::Sema::CheckClassTemplate(clang::Scope*, unsigned int,
clang::Sema::TagUseKind, clang::SourceLocation, clang::CXXScopeSpec&,
clang::IdentifierInfo*, clang::SourceLocation, clang::AttributeList*,
clang::TemplateParameterList*, clang::AccessSpecifier, clang::SourceLocation,
unsigned int, clang::TemplateParameterList**): Assertion `Kind != TTK_Enum &&
"can't build template of enumerated type"' failed.
0  clang           0x0000000002f4e50d llvm::sys::PrintStackTrace(_IO_FILE*) +
38
1  clang           0x0000000002f4e78a
2  clang           0x0000000002f4e1e2
3  libpthread.so.0 0x0000003ffd40f4c0
4  libc.so.6       0x0000003ffcc329a5 gsignal + 53
5  libc.so.6       0x0000003ffcc34185 abort + 373
6  libc.so.6       0x0000003ffcc2b935 __assert_fail + 245
7  clang           0x00000000014514e6
clang::Sema::CheckClassTemplate(clang::Scope*, unsigned int,
clang::Sema::TagUseKind, clang::SourceLocation, clang::CXXScopeSpec&,
clang::IdentifierInfo*, clang::SourceLocation, clang::AttributeList*,
clang::TemplateParameterList*, clang::AccessSpecifier, clang::SourceLocation,
unsigned int, clang::TemplateParameterList**) + 290
8  clang           0x0000000001222119 clang::Sema::ActOnTag(clang::Scope*,
unsigned int, clang::Sema::TagUseKind, clang::SourceLocation,
clang::CXXScopeSpec&, clang::IdentifierInfo*, clang::SourceLocation,
clang::AttributeList*, clang::AccessSpecifier, clang::SourceLocation,
llvm::MutableArrayRef<clang::TemplateParameterList*>, bool&, bool&,
clang::SourceLocation, bool,
clang::ActionResult<clang::OpaquePtr<clang::QualType>, false>) + 637
9  clang           0x00000000010fe46c
clang::Parser::ParseEnumSpecifier(clang::SourceLocation, clang::DeclSpec&,
clang::Parser::ParsedTemplateInfo const&, clang::AccessSpecifier,
clang::Parser::DeclSpecContext) + 4258
10 clang           0x00000000010fc207
clang::Parser::ParseDeclarationSpecifiers(clang::DeclSpec&,
clang::Parser::ParsedTemplateInfo const&, clang::AccessSpecifier,
clang::Parser::DeclSpecContext, clang::Parser::LateParsedAttrList*) + 9139
11 clang           0x000000000114b09b
clang::Parser::ParseSingleDeclarationAfterTemplate(unsigned int,
clang::Parser::ParsedTemplateInfo const&, clang::ParsingDeclRAIIObject&,
clang::SourceLocation&, clang::AccessSpecifier, clang::AttributeList*) + 425
12 clang           0x000000000114aea4
clang::Parser::ParseTemplateDeclarationOrSpecialization(unsigned int,
clang::SourceLocation&, clang::AccessSpecifier, clang::AttributeList*) + 1046
13 clang           0x000000000114a9e5
clang::Parser::ParseDeclarationStartingWithTemplate(unsigned int,
clang::SourceLocation&, clang::AccessSpecifier, clang::AttributeList*) + 217
14 clang           0x00000000010f6d0e
clang::Parser::ParseDeclaration(llvm::SmallVector<clang::Stmt*, 32u>&, unsigned
int, clang::SourceLocation&, clang::Parser::ParsedAttributesWithRange&) + 242
15 clang           0x00000000010e5a32
clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&,
clang::ParsingDeclSpec*) + 1622
16 clang           0x00000000010e53ab
clang::Parser::ParseTopLevelDecl(clang::OpaquePtr<clang::DeclGroupRef>&) + 413
17 clang           0x00000000010e1db2 clang::ParseAST(clang::Sema&, bool, bool)
+ 610
18 clang           0x0000000000cd5ef4 clang::ASTFrontendAction::ExecuteAction()
+ 298
19 clang           0x0000000000f056e6 clang::CodeGenAction::ExecuteAction() +
1296
20 clang           0x0000000000cd5a76 clang::FrontendAction::Execute() + 200
21 clang           0x0000000000caabc4
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 722
22 clang           0x0000000000c7acee
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1048
23 clang           0x0000000000c6ab87 cc1_main(char const**, char const**, char
const*, void*) + 673
24 clang           0x0000000000c7528d main + 484
25 libc.so.6       0x0000003ffcc1ec5d __libc_start_main + 253
26 clang           0x0000000000c6a309
Stack dump:
0.      Program arguments:
/root/work/newdisk/zhang/llvm/build/Debug+Asserts/bin/clang -cc1 -triple
x86_64-unknown-linux-gnu -emit-obj -mrelax-all -disable-free -main-file-name
test.cpp -mrelocation-model static -mdisable-fp-elim -fmath-errno -masm-verbose
-mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version
2.20.51.0.2 -momit-leaf-frame-pointer -coverage-file
/root/work/newdisk/zhang/c++11/20130401/forward_declarations_for_enums/test.o
-resource-dir
/root/work/newdisk/zhang/llvm/build/Debug+Asserts/bin/../lib/clang/3.3
-I/opt/intel/composer_xe_2013.1.117/mkl/include
-I/opt/intel/composer_xe_2013.1.117/tbb/include -internal-isystem
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/../../../../include/c++/4.4.4
-internal-isystem
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/../../../../include/c++/4.4.4/x86_64-redhat-linux
-internal-isystem
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/../../../../include/c++/4.4.4/backward
-internal-isystem
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/../../../../include/x86_64-redhat-linux/c++/4.4.4
-internal-isystem /usr/local/include -internal-isystem
/root/work/newdisk/zhang/llvm/build/Debug+Asserts/bin/../lib/clang/3.3/include
-internal-externc-isystem /include -internal-externc-isystem /usr/include
-std=c++11 -fdeprecated-macro -fdebug-compilation-dir
/root/work/newdisk/zhang/c++11/20130401/forward_declarations_for_enums
-ferror-limit 19 -fmessage-length 114 -mstackrealign -fobjc-runtime=gcc
-fobjc-default-synthesize-properties -fcxx-exceptions -fexceptions
-fdiagnostics-show-option -fcolor-diagnostics -backend-option -vectorize-loops
-o test.o -x c++ test.cpp
1.      test.cpp:11:27: current parser token '{'
clang: error: unable to execute command: Aborted (core dumped)
clang: error: clang frontend command failed due to signal (use -v to see
invocation)
clang version 3.3 (trunk 177699) (llvm/trunk 177691)
Target: x86_64-unknown-linux-gnu
Thread model: posix
clang: note: diagnostic msg: PLEASE submit a bug report to
http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and
associated run script.
clang: note: diagnostic msg:
********************

PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang: note: diagnostic msg: /tmp/test-9ucxjN.cpp
clang: note: diagnostic msg: /tmp/test-9ucxjN.sh
clang: note: diagnostic msg:

********************
----------------------------------

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130401/526282fa/attachment.html>

From bugzilla-daemon at llvm.org  Mon Apr  1 10:41:51 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 01 Apr 2013 17:41:51 +0000
Subject: [LLVMbugs] [Bug 12527] initialization from an _Atomic variable
	causes assert
In-Reply-To: <bug-12527-206@http.llvm.org/bugs/>
References: <bug-12527-206@http.llvm.org/bugs/>
Message-ID: <bug-12527-206-zjmF8gwzGR@http.llvm.org/bugs/>

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

Richard Smith <richard-llvm at metafoo.co.uk> changed:

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

--- Comment #2 from Richard Smith <richard-llvm at metafoo.co.uk> ---
Confirmed. Regression test added in r178476.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130401/b393362a/attachment.html>

From bugzilla-daemon at llvm.org  Mon Apr  1 10:51:18 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 01 Apr 2013 17:51:18 +0000
Subject: [LLVMbugs] [Bug 5952] pragmas not copied to the preprocessed output
In-Reply-To: <bug-5952-206@http.llvm.org/bugs/>
References: <bug-5952-206@http.llvm.org/bugs/>
Message-ID: <bug-5952-206-ChiNgaYXHa@http.llvm.org/bugs/>

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

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

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

--- Comment #2 from Rafael Ávila de Espíndola <rafael.espindola at gmail.com> ---
Thanks for testing it again!

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130401/57745ba6/attachment.html>

From bugzilla-daemon at llvm.org  Mon Apr  1 11:01:18 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 01 Apr 2013 18:01:18 +0000
Subject: [LLVMbugs] [Bug 15634] New: Diagnostic for failed template
 deduction is insufficient
Message-ID: <bug-15634-206@http.llvm.org/bugs/>

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

            Bug ID: 15634
           Summary: Diagnostic for failed template deduction is
                    insufficient
           Product: clang
           Version: 3.2
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
          Assignee: unassignedclangbugs at nondot.org
          Reporter: berkus at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Using this sample code
[code]
#include <vector>
#include <boost/array.hpp>

class byte_array
{
    std::vector<char> value;
public:
    template <typename T, size_t N>
    byte_array(const std::array<T, N>& in) : value(in.begin(), in.begin() + N)
{}
};

int main()
{
   boost::array<unsigned char, 32> arr;
   byte_array data(arr);
}
[/code]
(see http://liveworkspace.org/code/2uLY7q$4)

Clang's error diagnostic is quite not sufficient to spot and fix the error:

[irrelevant text skipped]
source.cpp:9:5: note: candidate template ignored: failed template argument
deduction
    byte_array(const std::array<T, N>& in) : value(in.begin(), in.begin() + N)
{}
    ^
1 error generated.

Gcc 4.8.0 on the other hand provides much more helpful text, which lets fix the
error on the spot (even gcc 4.7.2 nails it):

source.cpp:9:5: note:   template argument deduction/substitution failed:
source.cpp:15:23: note:   'boost::array<unsigned char, 32ul>' is not derived
from 'const std::array<_Tp, _Nm>'
    byte_array data(arr);
                       ^

It is possible to test the output of both the compilers with provided test code
on the liveworkspace website directly.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130401/3ecb351f/attachment.html>

From bugzilla-daemon at llvm.org  Mon Apr  1 11:20:13 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 01 Apr 2013 18:20:13 +0000
Subject: [LLVMbugs] [Bug 15635] New: Crash shell script writer doesn't
 escape quotes correctly
Message-ID: <bug-15635-206@http.llvm.org/bugs/>

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

            Bug ID: 15635
           Summary: Crash shell script writer doesn't escape quotes
                    correctly
           Product: clang
           Version: unspecified
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Driver
          Assignee: unassignedclangbugs at nondot.org
          Reporter: nicolasweber at gmx.de
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

If you pass a command-lien flag that contains escaped quotes, the .sh script
written on crash time won't execute correctly:

thakis$ cat test.cc
#pragma clang __debug parser_crash
thakis$ ~/src/llvm-svn/Release+Asserts/bin/clang -c test.cc -D
'WEBCORE_NAVIGATOR_VENDOR="Google Inc.\"'
0  clang             0x00000001106bfbf8 llvm::sys::PrintStackTrace(__sFILE*) +
40
1  clang             0x00000001106c0154 SignalHandler(int) + 548
2  libsystem_c.dylib 0x00007fff87fa194a _sigtramp + 26
3  clang             0x000000011087c41f NaNL + 6320
4  clang             0x000000010f1a9e20
clang::Parser::ParseDeclaratorInternal(clang::Declarator&, void
(clang::Parser::*)(clang::Declarator&)) + 576
5  clang             0x000000010f1a16e4
clang::Parser::ParseDeclGroup(clang::ParsingDeclSpec&, unsigned int, bool,
clang::SourceLocation*, clang::Parser::ForRangeInit*) + 612
6  clang             0x000000010f207be6
clang::Parser::ParseDeclOrFunctionDefInternal(clang::Parser::ParsedAttributesWithRange&,
clang::ParsingDeclSpec&, clang::AccessSpecifier) + 694
7  clang             0x000000010f207639
clang::Parser::ParseDeclarationOrFunctionDefinition(clang::Parser::ParsedAttributesWithRange&,
clang::ParsingDeclSpec*, clang::AccessSpecifier) + 361
8  clang             0x000000010f206b4c
clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&,
clang::ParsingDeclSpec*) + 3020
9  clang             0x000000010f205f04
clang::Parser::ParseTopLevelDecl(clang::OpaquePtr<clang::DeclGroupRef>&) + 308
10 clang             0x000000010f1932b1 clang::ParseAST(clang::Sema&, bool,
bool) + 257
11 clang             0x000000010f151bd7 clang::CodeGenAction::ExecuteAction() +
215
12 clang             0x000000010ef22457 clang::FrontendAction::Execute() + 119
13 clang             0x000000010eefe70d
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 957
14 clang             0x000000010eec718a
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 3690
15 clang             0x000000010eebe330 cc1_main(char const**, char const**,
char const*, void*) + 816
16 clang             0x000000010eec44a9 main + 7049
17 libdyld.dylib     0x00007fff81ba07e1 start + 0
Stack dump:
0.    Program arguments:
/Volumes/MacintoshHD2/src/llvm-svn/Release+Asserts/bin/clang -cc1 -triple
x86_64-apple-macosx10.8.0 -emit-obj -mrelax-all -disable-free -main-file-name
test.cc -mrelocation-model pic -pic-level 2 -mdisable-fp-elim -masm-verbose
-munwind-tables -target-cpu core2 -target-linker-version 136 -coverage-file
/Users/thakis/src/chrome-git/src/test.o -resource-dir
/Volumes/MacintoshHD2/src/llvm-svn/Release+Asserts/bin/../lib/clang/3.3 -D
WEBCORE_NAVIGATOR_VENDOR="Google Inc.\"" -fdeprecated-macro
-fdebug-compilation-dir /Users/thakis/src/chrome-git/src -ferror-limit 19
-fmessage-length 302 -stack-protector 1 -mstackrealign -fblocks
-fobjc-runtime=macosx-10.8.0 -fobjc-dispatch-method=mixed
-fobjc-default-synthesize-properties -fencode-extended-block-signature
-fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics
-backend-option -vectorize-loops -o test.o -x c++ test.cc 
1.    <unknown> parser at unknown location
clang: error: unable to execute command: Illegal instruction: 4
clang: error: clang frontend command failed due to signal (use -v to see
invocation)
clang version 3.3 (trunk 178474)
Target: x86_64-apple-darwin12.3.0
Thread model: posix
clang: note: diagnostic msg: PLEASE submit a bug report to
http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and
associated run script.
clang: note: diagnostic msg: 
********************

PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang: note: diagnostic msg:
/var/folders/00/0d5yr000h01000cxqpysvccm001mqv/T/test-HimD0k.cpp
clang: note: diagnostic msg:
/var/folders/00/0d5yr000h01000cxqpysvccm001mqv/T/test-HimD0k.sh
clang: note: diagnostic msg: 

********************

thakis$ chmod +x 
/var/folders/00/0d5yr000h01000cxqpysvccm001mqv/T/test-HimD0k.sh
thakis$  /var/folders/00/0d5yr000h01000cxqpysvccm001mqv/T/test-HimD0k.sh
error: error reading 'Inc.\"'
error: error reading 'test-HimD0k.cpp'
2 errors generated.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130401/02b74824/attachment.html>

From bugzilla-daemon at llvm.org  Mon Apr  1 11:24:04 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 01 Apr 2013 18:24:04 +0000
Subject: [LLVMbugs] [Bug 15636] New: clang should warn on suspicious
 increments of loop variables
Message-ID: <bug-15636-206@http.llvm.org/bugs/>

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

            Bug ID: 15636
           Summary: clang should warn on suspicious increments of loop
                    variables
           Product: clang
           Version: unspecified
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
          Assignee: unassignedclangbugs at nondot.org
          Reporter: resistor at mac.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Consider the following code snippet:

void foo(char *a, char *b, unsigned c) {
    for (unsigned i = 0; i < c; ++i) {
        a[i] = b[i];
        ++i;
    }
}

clang does not currently warn on this, even though the code is likely incorrect
(incrementing i both in the loop latch and in the body of the loop).  clang
should produce a warning when it detects a variable that is incremented in the
latch of the for header, and *unconditionally* incremented in the body of the
loop.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130401/93629e14/attachment.html>

From bugzilla-daemon at llvm.org  Mon Apr  1 12:36:41 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 01 Apr 2013 19:36:41 +0000
Subject: [LLVMbugs] [Bug 15637] New: Regression: Assertion failed:
 ((!TParams || DbgNode->getNumOperands() == 14) && "If you're setting the
 template parameters this should include a slot " "for that!"),
 function setTypeArray, file DebugInfo.cpp, line 623.
Message-ID: <bug-15637-206@http.llvm.org/bugs/>

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

            Bug ID: 15637
           Summary: Regression: Assertion failed: ((!TParams ||
                    DbgNode->getNumOperands() == 14) && "If you're setting
                    the template parameters this should include a slot "
                    "for that!"), function setTypeArray, file
                    DebugInfo.cpp, line 623.
           Product: clang
           Version: unspecified
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: LLVM Codegen
          Assignee: unassignedclangbugs at nondot.org
          Reporter: nicolasweber at gmx.de
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

This is reduced from code in WebKit:

thakis$ cat repro.ii
template <typename T> union Value { int a; };
void g(float value) {
  Value<float> tempValue;
}

thakis$ ~/src/llvm-svn/Release+Asserts/bin/clang -cc1 -triple
i386-apple-macosx10.6.0 -emit-obj -g   -x c++ repro.ii 
Assertion failed: ((!TParams || DbgNode->getNumOperands() == 14) && "If you're
setting the template parameters this should include a slot " "for that!"),
function setTypeArray, file DebugInfo.cpp, line 623.
0  clang             0x000000010b58cbf8 llvm::sys::PrintStackTrace(__sFILE*) +
40
1  clang             0x000000010b58d154 SignalHandler(int) + 548
2  libsystem_c.dylib 0x00007fff87fa194a _sigtramp + 26
3  clang             0x000000010b4b844c llvm::DIDescriptor::isCompositeType()
const + 28
4  clang             0x000000010b58cf16 abort + 22
5  clang             0x000000010b58cef1 __assert_rtn + 81
6  clang             0x000000010b4b9846
llvm::DICompositeType::setTypeArray(llvm::DIArray, llvm::DIArray) + 278
7  clang             0x0000000109f746e4
clang::CodeGen::CGDebugInfo::CreateType(clang::RecordType const*) + 1268


This is at r178474 (which was current trunk when I started delta an hour or so
ago). Doesn't happen at r178178.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130401/b1b1e4af/attachment.html>

From bugzilla-daemon at llvm.org  Mon Apr  1 12:52:51 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 01 Apr 2013 19:52:51 +0000
Subject: [LLVMbugs] [Bug 15638] New: Possible memory leak when starting a
	new thread
Message-ID: <bug-15638-206@http.llvm.org/bugs/>

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

            Bug ID: 15638
           Summary: Possible memory leak when starting a new thread
           Product: libc++
           Version: unspecified
          Hardware: Macintosh
                OS: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: All Bugs
          Assignee: hhinnant at apple.com
          Reporter: louis.dionne92 at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

While looking at the code in <thread>, I ran into the following:

template <class _Fp>
void* __thread_proxy(void* __vp) {
    __thread_local_data().reset(new __thread_struct);
    std::unique_ptr<_Fp> __p(static_cast<_Fp*>(__vp));
    .....
}

template <class _Fp, class ..._Args, class>
thread::thread(_Fp&& __f, _Args&&... __args) {
    typedef tuple<typename decay<_Fp>::type, typename decay<_Args>::type...>
_Gp;
    _VSTD::unique_ptr<_Gp> __p(new _Gp(__decay_copy(_VSTD::forward<_Fp>(__f)),
                               
__decay_copy(_VSTD::forward<_Args>(__args))...));
    int __ec = pthread_create(&__t_, 0, &__thread_proxy<_Gp>, __p.get());
    if (__ec == 0)
        __p.release();
    else
        __throw_system_error(__ec, "thread constructor failed");
}

Unless I am mistaken, if the allocation fails on the first line of
__thread_proxy, __vp will never be freed because it is not yet owned by
the unique_ptr. Simply changing the order of the first two lines in
__thread_proxy would fix the issue.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130401/39061472/attachment.html>

From bugzilla-daemon at llvm.org  Mon Apr  1 13:33:39 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 01 Apr 2013 20:33:39 +0000
Subject: [LLVMbugs] [Bug 15637] Regression: Assertion failed: ((!TParams ||
 DbgNode->getNumOperands() == 14) && "If you're setting the template
 parameters this should include a slot " "for that!"), function setTypeArray,
 file DebugInfo.cpp, line 623.
In-Reply-To: <bug-15637-206@http.llvm.org/bugs/>
References: <bug-15637-206@http.llvm.org/bugs/>
Message-ID: <bug-15637-206-M7vQOw5gWR@http.llvm.org/bugs/>

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

Nico Weber <nicolasweber at gmx.de> changed:

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

--- Comment #4 from Nico Weber <nicolasweber at gmx.de> ---
Reverted r178079 in r178497 for now.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130401/1599bf26/attachment.html>

From bugzilla-daemon at llvm.org  Mon Apr  1 13:47:23 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 01 Apr 2013 20:47:23 +0000
Subject: [LLVMbugs] [Bug 15639] New: regression: clang trunk r178466 crashes
 building ITK ('itk::Math::FloatAlmostEqual')
Message-ID: <bug-15639-206@http.llvm.org/bugs/>

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

            Bug ID: 15639
           Summary: regression: clang trunk r178466 crashes building ITK
                    ('itk::Math::FloatAlmostEqual')
           Product: new-bugs
           Version: trunk
          Hardware: Macintosh
                OS: MacOS X
            Status: NEW
          Severity: release blocker
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: sean at rogue-research.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 10263
  --> http://llvm.org/bugs/attachment.cgi?id=10263&action=edit
requested files

I have a buildbot that builds nightly ITK with a recent build of clang (that I
rebuild every few weeks).

I updated clang from r177175 to r178252 and then it started crashing.  Updated
to r178466 and it's still crashing.

My ITK nightly build log:
<http://open.cdash.org/viewBuildError.php?buildid=2862761>

Basically:

0  clang-3.3         0x0000000106b0c258 llvm::sys::PrintStackTrace(__sFILE*) +
40
1  clang-3.3         0x0000000106b0c744 SignalHandler(int) + 436
2  libsystem_c.dylib 0x00007fff8327894a _sigtramp + 26
3  libsystem_c.dylib 0x00007fff59af7350 _sigtramp + 3599231520
4  clang-3.3         0x0000000106a52572
llvm::MDNode::replaceOperand(llvm::MDNodeOperand*, llvm::Value*) + 274
5  clang-3.3         0x00000001069f442a
llvm::DICompositeType::setTypeArray(llvm::DIArray, llvm::DIArray) + 122
6  clang-3.3         0x0000000106d03626
clang::CodeGen::CGDebugInfo::CreateType(clang::RecordType const*) + 1302
7  clang-3.3         0x0000000106d05994
clang::CodeGen::CGDebugInfo::CreateTypeNode(clang::QualType, llvm::DIFile) +
740
8  clang-3.3         0x0000000106cfdd96
clang::CodeGen::CGDebugInfo::getOrCreateType(clang::QualType, llvm::DIFile) +
118
9  clang-3.3         0x0000000106cfda72
clang::CodeGen::CGDebugInfo::getContextDescriptor(clang::Decl const*) + 338
10 clang-3.3         0x0000000106d00e75
clang::CodeGen::CGDebugInfo::CreateType(clang::TypedefType const*,
llvm::DIFile) + 197
11 clang-3.3         0x0000000106d05984
clang::CodeGen::CGDebugInfo::CreateTypeNode(clang::QualType, llvm::DIFile) +
724
12 clang-3.3         0x0000000106cfdd96
clang::CodeGen::CGDebugInfo::getOrCreateType(clang::QualType, llvm::DIFile) +
118
13 clang-3.3         0x0000000106d00fd2
clang::CodeGen::CGDebugInfo::CreateType(clang::FunctionType const*,
llvm::DIFile) + 242
14 clang-3.3         0x0000000106d05817
clang::CodeGen::CGDebugInfo::CreateTypeNode(clang::QualType, llvm::DIFile) +
359
15 clang-3.3         0x0000000106cfdd96
clang::CodeGen::CGDebugInfo::getOrCreateType(clang::QualType, llvm::DIFile) +
118
16 clang-3.3         0x0000000106d0622d
clang::CodeGen::CGDebugInfo::getOrCreateFunctionType(clang::Decl const*,
clang::QualType, llvm::DIFile) + 93
17 clang-3.3         0x0000000106d067c9
clang::CodeGen::CGDebugInfo::EmitFunctionStart(clang::GlobalDecl,
clang::QualType, llvm::Function*, llvm::IRBuilder<false, llvm::ConstantFolder,
llvm::IRBuilderDefaultInserter<false> >&) + 713
18 clang-3.3         0x0000000106d9d8a4
clang::CodeGen::CodeGenFunction::StartFunction(clang::GlobalDecl,
clang::QualType, llvm::Function*, clang::CodeGen::CGFunctionInfo const&,
clang::CodeGen::FunctionArgList const&, clang::SourceLocation) + 1060
19 clang-3.3         0x0000000106d9e423
clang::CodeGen::CodeGenFunction::GenerateCode(clang::GlobalDecl,
llvm::Function*, clang::CodeGen::CGFunctionInfo const&) + 563
20 clang-3.3         0x0000000106da7379
clang::CodeGen::CodeGenModule::EmitGlobalFunctionDefinition(clang::GlobalDecl)
+ 585
21 clang-3.3         0x0000000106da499c
clang::CodeGen::CodeGenModule::EmitGlobalDefinition(clang::GlobalDecl) + 220
22 clang-3.3         0x0000000106da19db
clang::CodeGen::CodeGenModule::EmitDeferred() + 27
23 clang-3.3         0x0000000106da18a1
clang::CodeGen::CodeGenModule::Release() + 17
24 clang-3.3         0x0000000106d9af2d
clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) + 93
25 clang-3.3         0x0000000106ef6a54 clang::ParseAST(clang::Sema&, bool,
bool) + 516
26 clang-3.3         0x0000000106d9a21b clang::CodeGenAction::ExecuteAction() +
91
27 clang-3.3         0x0000000106e7d518 clang::FrontendAction::Execute() + 88
28 clang-3.3         0x0000000106e5b8cd
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 861
29 clang-3.3         0x0000000106b0f127
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 3623
30 clang-3.3         0x0000000106107815 cc1_main(char const**, char const**,
char const*, void*) + 773
31 clang-3.3         0x00000001061059c6 main + 6518
32 libdyld.dylib     0x00007fff8adf77e1 start + 0
Stack dump:
0.    Program arguments: /Users/builder/llvm/llvm-rel-install/bin/clang-3.3
-cc1 -triple x86_64-apple-macosx10.8.0 -emit-obj -mrelax-all -disable-free
-disable-llvm-verifier -main-file-name itkMathTest.cxx -mrelocation-model pic
-pic-level 2 -mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu core2
-g -coverage-file
/Users/builder/external/ITK-clang-dbg-x86_64-static/Modules/Core/Common/test/CMakeFiles/itkMathTest.dir/itkMathTest.cxx.o
-resource-dir /Users/builder/llvm/llvm-rel-install/bin/../lib/clang/3.3
-isysroot
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk
-D _FORTIFY_SOURCE=2 -I
/Users/builder/external/ITK/Modules/ThirdParty/DoubleConversion/src/double-conversion
-I
/Users/builder/external/ITK-clang-dbg-x86_64-static/Modules/ThirdParty/KWSys/src
-I /Users/builder/external/ITK/Modules/ThirdParty/VNL/src/vxl/v3p/netlib -I
/Users/builder/external/ITK/Modules/ThirdParty/VNL/src/vxl/vcl -I
/Users/builder/external/ITK/Modules/ThirdParty/VNL/src/vxl/core -I
/Users/builder/external/ITK-clang-dbg-x86_64-static/Modules/ThirdParty/VNL/src/vxl/v3p/netlib
-I
/Users/builder/external/ITK-clang-dbg-x86_64-static/Modules/ThirdParty/VNL/src/vxl/vcl
-I
/Users/builder/external/ITK-clang-dbg-x86_64-static/Modules/ThirdParty/VNL/src/vxl/core
-I /Users/builder/external/ITK/Modules/ThirdParty/VNLInstantiation/include -I
/Users/builder/external/ITK-clang-dbg-x86_64-static/Modules/Core/Common -I
/Users/builder/external/ITK/Modules/Core/Common/include -I
/Users/builder/external/ITK-clang-dbg-x86_64-static/Modules/IO/ImageBase -I
/Users/builder/external/ITK/Modules/IO/ImageBase/include -I
/Users/builder/external/ITK/Modules/Core/ImageAdaptors/include -I
/Users/builder/external/ITK/Modules/Filtering/ImageFilterBase/include -I
/Users/builder/external/ITK-clang-dbg-x86_64-static/Modules/ThirdParty/Netlib
-I /Users/builder/external/ITK/Modules/Numerics/Statistics/include -I
/Users/builder/external/ITK/Modules/Core/Transform/include -I
/Users/builder/external/ITK/Modules/Core/ImageFunction/include -I
/Users/builder/external/ITK/Modules/Filtering/ImageGrid/include -I
/Users/builder/external/ITK/Modules/Filtering/ImageCompose/include -I
/Users/builder/external/ITK/Modules/Core/Mesh/include -I
/Users/builder/external/ITK-clang-dbg-x86_64-static/Modules/ThirdParty/ZLIB/src
-I
/Users/builder/external/ITK-clang-dbg-x86_64-static/Modules/ThirdParty/MetaIO/src/MetaIO
-I /Users/builder/external/ITK/Modules/ThirdParty/MetaIO/src/MetaIO -I
/Users/builder/external/ITK/Modules/Core/SpatialObjects/include -I
/Users/builder/external/ITK/Modules/Filtering/ImageStatistics/include -I
/Users/builder/external/ITK/Modules/Filtering/Path/include -I
/Users/builder/external/ITK/Modules/Filtering/ImageIntensity/include -I
/Users/builder/external/ITK/Modules/IO/BMP/include -I
/Users/builder/external/ITK/Modules/IO/BioRad/include -I
/Users/builder/external/ITK-clang-dbg-x86_64-static/Modules/ThirdParty/Expat/src/expat
-I /Users/builder/external/ITK/Modules/ThirdParty/Expat/src/expat -I
/Users/builder/external/ITK-clang-dbg-x86_64-static/Modules/ThirdParty/OpenJPEG/src/openjpeg
-I /Users/builder/external/ITK/Modules/ThirdParty/OpenJPEG/src/openjpeg -I
/Users/builder/external/ITK-clang-dbg-x86_64-static/Modules/ThirdParty/GDCM -I
/Users/builder/external/ITK-clang-dbg-x86_64-static/Modules/ThirdParty/GDCM/src/gdcm/Source/Common
-I
/Users/builder/external/ITK/Modules/ThirdParty/GDCM/src/gdcm/Source/MediaStorageAndFileFormat
-I
/Users/builder/external/ITK/Modules/ThirdParty/GDCM/src/gdcm/Source/DataDictionary
-I /Users/builder/external/ITK/Modules/ThirdParty/GDCM/src/gdcm/Source/Common
-I
/Users/builder/external/ITK/Modules/ThirdParty/GDCM/src/gdcm/Source/InformationObjectDefinition
-I
/Users/builder/external/ITK/Modules/ThirdParty/GDCM/src/gdcm/Source/MessageExchangeDefinition
-I
/Users/builder/external/ITK/Modules/ThirdParty/GDCM/src/gdcm/Source/DataStructureAndEncodingDefinition
-I /Users/builder/external/ITK/Modules/IO/GDCM/include -I
/Users/builder/external/ITK/Modules/IO/GIPL/include -I
/Users/builder/external/ITK-clang-dbg-x86_64-static/Modules/ThirdParty/JPEG/src
-I /Users/builder/external/ITK/Modules/ThirdParty/JPEG/src -I
/Users/builder/external/ITK/Modules/IO/JPEG/include -I
/Users/builder/external/ITK-clang-dbg-x86_64-static/Modules/ThirdParty/TIFF/src
-I
/Users/builder/external/ITK-clang-dbg-x86_64-static/Modules/ThirdParty/TIFF/src/itktiff
-I /Users/builder/external/ITK/Modules/ThirdParty/TIFF/src -I
/Users/builder/external/ITK/Modules/IO/TIFF/include -I
/Users/builder/external/ITK/Modules/IO/LSM/include -I
/Users/builder/external/ITK/Modules/IO/Meta/include -I
/Users/builder/external/ITK/Modules/ThirdParty/NIFTI/src/nifti/niftilib -I
/Users/builder/external/ITK/Modules/ThirdParty/NIFTI/src/nifti/znzlib -I
/Users/builder/external/ITK/Modules/IO/NIFTI/include -I
/Users/builder/external/ITK-clang-dbg-x86_64-static/Modules/ThirdParty/NrrdIO/src/NrrdIO
-I /Users/builder/external/ITK/Modules/ThirdParty/NrrdIO/src/NrrdIO -I
/Users/builder/external/ITK/Modules/IO/NRRD/include -I
/Users/builder/external/ITK-clang-dbg-x86_64-static/Modules/ThirdParty/PNG/src
-I /Users/builder/external/ITK/Modules/ThirdParty/PNG/src -I
/Users/builder/external/ITK/Modules/IO/PNG/include -I
/Users/builder/external/ITK/Modules/IO/Stimulate/include -I
/Users/builder/external/ITK/Modules/IO/VTK/include -I
/Users/builder/external/ITK/Modules/Core/TestKernel/include -Wall -Wextra
-Wno-unused-parameter -Wc++11-compat -Wall -Wcast-align -Wdisabled-optimization
-Wextra -Wformat=2 -Winvalid-pch -Wno-format-nonliteral -Wpointer-arith
-Wshadow -Wunused -Wwrite-strings -Wno-strict-overflow -Wno-deprecated
-Wno-invalid-offsetof -Woverloaded-virtual -fconst-strings
-fdebug-compilation-dir
/Users/builder/external/ITK-clang-dbg-x86_64-static/Modules/Core/Common/test
-ferror-limit 19 -fmessage-length 0
-fsanitize=integer-divide-by-zero,null,object-size,return,unreachable,vla-bound
-stack-protector 2 -mstackrealign -fblocks -fobjc-runtime=macosx-10.8.0
-fobjc-dispatch-method=mixed -fobjc-default-synthesize-properties
-fencode-extended-block-signature -fcxx-exceptions -fexceptions
-fdiagnostics-show-option -backend-option -vectorize-loops -o
CMakeFiles/itkMathTest.dir/itkMathTest.cxx.o -x c++
/Users/builder/external/ITK/Modules/Core/Common/test/itkMathTest.cxx 
1.    <eof> parser at end of file
2.    Per-file LLVM IR generation
3.    /Users/builder/external/ITK/Modules/Core/Common/include/itkMath.h:258:1:
Generating code for declaration 'itk::Math::FloatAlmostEqual'
clang-3.3: error: unable to execute command: Segmentation fault: 11
clang-3.3: error: clang frontend command failed due to signal (use -v to see
invocation)
clang version 3.3 (178466)
Target: x86_64-apple-darwin12.3.0
Thread model: posix
clang-3.3: note: diagnostic msg: PLEASE submit a bug report to  and include the
crash backtrace, preprocessed source, and associated run script.
clang-3.3: note: diagnostic msg: 
********************

PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang-3.3: note: diagnostic msg:
/var/folders/fk/hnnmm2h91xl6zvz8dl4y6b8r0000gn/T/itkMathTest-9Ljx8h.cpp
clang-3.3: note: diagnostic msg:
/var/folders/fk/hnnmm2h91xl6zvz8dl4y6b8r0000gn/T/itkMathTest-9Ljx8h.sh
clang-3.3: note: diagnostic msg: 

********************

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130401/f9af2d40/attachment.html>

From bugzilla-daemon at llvm.org  Mon Apr  1 14:09:28 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 01 Apr 2013 21:09:28 +0000
Subject: [LLVMbugs] [Bug 15639] regression: clang trunk r178466 crashes
 building ITK ('itk::Math::FloatAlmostEqual')
In-Reply-To: <bug-15639-206@http.llvm.org/bugs/>
References: <bug-15639-206@http.llvm.org/bugs/>
Message-ID: <bug-15639-206-AG5vZyY5Nf@http.llvm.org/bugs/>

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

Eric Christopher <echristo at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |echristo at gmail.com
         Resolution|---                         |DUPLICATE

--- Comment #1 from Eric Christopher <echristo at gmail.com> ---
Should be dup.

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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130401/4b424fb7/attachment.html>

From bugzilla-daemon at llvm.org  Mon Apr  1 14:13:03 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 01 Apr 2013 21:13:03 +0000
Subject: [LLVMbugs] [Bug 15500] ARCMT uses an iterator after invalidation
In-Reply-To: <bug-15500-206@http.llvm.org/bugs/>
References: <bug-15500-206@http.llvm.org/bugs/>
Message-ID: <bug-15500-206-PDX6peJPha@http.llvm.org/bugs/>

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

Argyrios Kyrtzidis <akyrtzi at gmail.com> changed:

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

--- Comment #3 from Argyrios Kyrtzidis <akyrtzi at gmail.com> ---
Should be fixed in r178500

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130401/e3649abd/attachment.html>

From bugzilla-daemon at llvm.org  Mon Apr  1 14:26:26 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 01 Apr 2013 21:26:26 +0000
Subject: [LLVMbugs] [Bug 15640] New: llvm crashes with Linux kernel code on
	ARM target
Message-ID: <bug-15640-206@http.llvm.org/bugs/>

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

            Bug ID: 15640
           Summary: llvm crashes with Linux kernel code on ARM target
           Product: new-bugs
           Version: trunk
          Hardware: Other
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: weimingz at codeaurora.org
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 10264
  --> http://llvm.org/bugs/attachment.cgi?id=10264&action=edit
clang -O3 q

clang: /home/weimingz/llvm/include/llvm/CodeGen/MachineOperand.h:260: unsigned
int llvm::MachineOperand::getReg() const: Assertion `isReg() && "This is not a
register operand!"' failed.
0  clang           0x0000000002c7e165 llvm::sys::PrintStackTrace(_IO_FILE*) +
38
1  clang           0x0000000002c7e3e2
2  clang           0x0000000002c7de3a
3  libpthread.so.0 0x00007fa103acc8f0
4  libc.so.6       0x00007fa102bb3a75 gsignal + 53
5  libc.so.6       0x00007fa102bb75c0 abort + 384
6  libc.so.6       0x00007fa102bac941 __assert_fail + 241
7  clang           0x00000000020a6a79
8  clang           0x00000000020c68d9
llvm::ARMBaseRegisterInfo::eliminateFrameIndex(llvm::MachineBasicBlock::bundle_iterator<llvm::MachineInstr,
llvm::ilist_iterator<llvm::MachineInstr> >, int, unsigned int,
llvm::RegScavenger*) const + 935
9  clang           0x00000000024bce82
llvm::PEI::replaceFrameIndices(llvm::MachineFunction&) + 1476
10 clang           0x00000000024b9b33
llvm::PEI::runOnMachineFunction(llvm::MachineFunction&) + 571
11 clang           0x0000000002476ca5
llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 95
12 clang           0x0000000002b54c77
llvm::FPPassManager::runOnFunction(llvm::Function&) + 393
13 clang           0x0000000002b54e77
llvm::FPPassManager::runOnModule(llvm::Module&) + 89
14 clang           0x0000000002b551f2
llvm::MPPassManager::runOnModule(llvm::Module&) + 576
15 clang           0x0000000002b55818 llvm::PassManagerImpl::run(llvm::Module&)
+ 254
16 clang           0x0000000002b55b73 llvm::PassManager::run(llvm::Module&) +
39
17 clang           0x0000000000e83ada
18 clang           0x0000000000e83bb2
clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::CodeGenOptions
const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::Module*,
clang::BackendAction, llvm::raw_ostream*) + 140
19 clang           0x0000000000e7e2d4
20 clang           0x0000000001062e7f clang::ParseAST(clang::Sema&, bool, bool)
+ 780
21 clang           0x0000000000c371da clang::ASTFrontendAction::ExecuteAction()
+ 298
22 clang           0x0000000000e7d139 clang::CodeGenAction::ExecuteAction() +
1425
23 clang           0x0000000000c36d5a clang::FrontendAction::Execute() + 200
24 clang           0x0000000000c0bfaa
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 728
25 clang           0x0000000000bdaa28
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1018
26 clang           0x0000000000bca930 cc1_main(char const**, char const**, char
const*, void*) + 754
27 clang           0x0000000000bd4f56 main + 499
28 libc.so.6       0x00007fa102b9ec4d __libc_start_main + 253
29 clang           0x0000000000bc9fa9
Stack dump:
0.    Program arguments: /scratch/llvm-build/Debug+Asserts/bin/clang -cc1
-triple armv4t-none-linux-gnueabi -emit-obj -disable-free -main-file-name
context-parsed.i -mrelocation-model static -fmath-errno -ffp-contract=fast
-masm-verbose -mconstructor-aliases -target-abi aapcs-linux -target-cpu
arm7tdmi -mfloat-abi soft -target-feature +soft-float-abi
-target-linker-version 2.20.1 -momit-leaf-frame-pointer -resource-dir
/local/scratch/llvm-build/mainline-state-transtion/Debug+Asserts/bin/../lib/clang/3.3
-O3 -fdebug-compilation-dir
/prj/llvm-arm/home/weimingz/llvm_tests/bug_asm_inline/unittest -ferror-limit 19
-fmessage-length 174 -mstackrealign -fno-signed-char -fobjc-runtime=gcc
-fobjc-default-synthesize-properties -fdiagnostics-show-option
-fcolor-diagnostics -o /tmp/context-parsed-VKo8Pc.o -x cpp-output
context-parsed.i

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130401/f0cce5e4/attachment.html>

From bugzilla-daemon at llvm.org  Mon Apr  1 14:43:26 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 01 Apr 2013 21:43:26 +0000
Subject: [LLVMbugs] [Bug 15642] New: clang -MMD doesn't escape dollar signs
	in output
Message-ID: <bug-15642-206@http.llvm.org/bugs/>

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

            Bug ID: 15642
           Summary: clang -MMD doesn't escape dollar signs in output
           Product: clang
           Version: 3.2
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: abbeyj at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

When using "clang -MMD" with filenames that contain dollar signs, the dollar
signs are not escaped.  If this output is used with make it won't be able to
find the prerequisites.  For example:

$ /bin/ls -l
-rw-r--r-- 1 abbeyj users 75 Apr  1 17:36 Makefile
-rw-r--r-- 1 abbeyj users  0 Apr  1 17:35 dollar$sign.h
-rw-r--r-- 1 abbeyj users 25 Apr  1 17:32 main.c

$ cat Makefile
main.o: main.c
        $(CC) -MMD -c main.c
-include main.d
clean:
        $(RM) *.o *.d

$ cat main.c
#include "dollar$sign.h"

# works fine with gcc
$ make CC=gcc
gcc -MMD -c main.c
$ cat main.d
main.o: main.c dollar$$sign.h
$ make CC=gcc
make: `main.o' is up to date.

$ make clean

# fails with clang (once .d file has been created)
$ make CC=clang
clang -MMD -c main.c
$ cat main.d
main.o: main.c dollar$sign.h
$ make CC=clang
make: *** No rule to make target `dollarign.h', needed by `main.o'.  Stop.



Since the dollar sign is not doubled, make tries to expand "$s" and gets an
empty string making it think the desired filename is "dollarign.h".  Since that
file doesn't exist, the make then fails.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130401/c92e766f/attachment.html>

From bugzilla-daemon at llvm.org  Mon Apr  1 14:43:54 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 01 Apr 2013 21:43:54 +0000
Subject: [LLVMbugs] [Bug 15633] a bug involving defining enumeration outside
 of template class body
In-Reply-To: <bug-15633-206@http.llvm.org/bugs/>
References: <bug-15633-206@http.llvm.org/bugs/>
Message-ID: <bug-15633-206-i9yKt3Y6Vx@http.llvm.org/bugs/>

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

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> ---
Fixed in r178502.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130401/b6d67699/attachment.html>

From bugzilla-daemon at llvm.org  Mon Apr  1 14:55:43 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 01 Apr 2013 21:55:43 +0000
Subject: [LLVMbugs] [Bug 15644] New: Scalar replacement of aggregates slower
 in LLVM 3.0+ relative to 2.8
Message-ID: <bug-15644-206@http.llvm.org/bugs/>

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

            Bug ID: 15644
           Summary: Scalar replacement of aggregates slower in LLVM 3.0+
                    relative to 2.8
           Product: libraries
           Version: 3.2
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Scalar Optimizations
          Assignee: unassignedbugs at nondot.org
          Reporter: ajclinto at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

This was originally sent to the LLVM mailing list after the LLVM 3.0 release,
but it still seems to be an issue in 3.2.  The attached file optimizes much
faster (about 3x better) in LLVM 2.8 compared to 3.2.  Performance didn't
change on this test case between 3.0 and 3.2.

time opt -scalarrepl slow_sroa.ll

On my system:
2.8: 0.16s
3.2: 0.5s

This is from email correspondence on llvm-dev:

------------------------------------------------------

Actually, -scalarrepl-ssa is the slower one.

On 04/05/2012 06:56 PM, Andrew Clinton wrote:
> Attached is the test case.
>
> Run:
>
> opt -scalarrepl slow_sroa.ll
>
> Andrew
>
> On 04/05/2012 05:11 PM, Nick Lewycky wrote:
>> I've patched SROA in a way that may have made it slower. Do you have a testcase we can look at?
>>
>> Nick
>>
>> On 4 April 2012 16:19, Andrew Clinton <andrew at sidefx.com> wrote:
>>
>>     I just upgraded our optimizer to LLVM 3.0 from 2.8 and noticed that the
>>     scalar replacement of aggregates pass takes a lot longer for some code.
>>     Has there been a performance regression in this pass, or does it do more
>>     work?
>>
>>     LLVM 3.0:
>>
>>       Total Execution Time: 1.0600 seconds (1.0526 wall clock)
>>
>>        ---User Time---   --System Time--   --User+System--   ---Wall
>>     Time---  --- Name ---
>>        0.5100 ( 49.5%)   0.0000 (  0.0%)   0.5100 ( 48.1%)   0.5099 (
>>     48.4%)  Scalar Replacement of Aggregates (SSAUp)
>>        0.1900 ( 18.4%)   0.0300 (100.0%)   0.2200 ( 20.8%)   0.2156 (
>>     20.5%)  Scalar Replacement of Aggregates (DT)
>>        0.1200 ( 11.7%)   0.0000 (  0.0%)   0.1200 ( 11.3%)   0.1158 (
>>     11.0%)  VEX Constant Propagation
>>        0.0200 (  1.9%)   0.0000 (  0.0%)   0.0200 (  1.9%)   0.0196 (
>>     1.9%)  Simplify the CFG
>>        0.0200 (  1.9%)   0.0000 (  0.0%)   0.0200 (  1.9%)   0.0181 (
>>     1.7%)  Module Verifier
>>     ...
>>
>>     LLVM 2.8:
>>
>>       Total Execution Time: 0.6500 seconds (0.6489 wall clock)
>>
>>        ---User Time---   --System Time--   --User+System--   ---Wall
>>     Time---  --- Name ---
>>        0.1400 ( 21.9%)   0.0000 (  0.0%)   0.1400 ( 21.5%)   0.1379 (
>>     21.3%)  Scalar Replacement of Aggregates
>>        0.1200 ( 18.7%)   0.0000 (  0.0%)   0.1200 ( 18.5%)   0.1208 (
>>     18.6%)  VEX Constant Propagation
>>        0.1000 ( 15.6%)   0.0000 (  0.0%)   0.1000 ( 15.4%)   0.1050 (
>>     16.2%)  Scalar Replacement of Aggregates
>>        0.0400 (  6.3%)   0.0000 (  0.0%)   0.0400 (  6.2%)   0.0481 (
>>     7.4%)  Combine redundant instructions
>>        0.0200 (  3.1%)   0.0000 (  0.0%)   0.0200 (  3.1%)   0.0235 (
>>     3.6%)  Preliminary module verification
>>     ...
>>     _______________________________________________
>>     LLVM Developers mailing list
>>     LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>     http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>>

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130401/0f61131c/attachment.html>

From bugzilla-daemon at llvm.org  Mon Apr  1 15:46:46 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 01 Apr 2013 22:46:46 +0000
Subject: [LLVMbugs] [Bug 15647] New: Add .eh_frame support
Message-ID: <bug-15647-206@http.llvm.org/bugs/>

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

            Bug ID: 15647
           Summary: Add .eh_frame support
           Product: tools
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: llvm-dwarfdump
          Assignee: unassignedbugs at nondot.org
          Reporter: jcarter at mips.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 10269
  --> http://llvm.org/bugs/attachment.cgi?id=10269&action=edit
ELF object for dump

The .eh_frame section is very similar to the .debug_frame section.

This section describes exception handling. If this bug belongs in llvm-objdump,
please move it there. I could not find a bugzilla spot for it.

Basically we need a pretty printer output for exception handling info if for no
other reason, to create "make check" tests.

This is what gnu's readelf -wf dumps for my small test case:

svn: readelf -wf ../../j.o
Contents of the .eh_frame section:

00000000 0000001c 00000000 CIE
  Version:               1
  Augmentation:          "zPLR"
  Code alignment factor: 1
  Data alignment factor: -8
  Return address column: 31
  Augmentation data:     00 00 00 00 00 00 00 00 00 00 00

  DW_CFA_def_cfa: r29 ofs 0

00000020 0000002c 00000024 FDE cie=00000000 pc=00000000..0000007c
  Augmentation data:     00 00 00 00 00 00 00 00

  DW_CFA_advance_loc: 4 to 00000004
  DW_CFA_def_cfa_offset: 16
  DW_CFA_advance_loc: 8 to 0000000c
  DW_CFA_offset: r31 at cfa-8
  DW_CFA_offset: r28 at cfa-16
  DW_CFA_nop
  DW_CFA_nop
  DW_CFA_nop
  DW_CFA_nop
  DW_CFA_nop
  DW_CFA_nop
  DW_CFA_nop

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130401/125aca0f/attachment.html>

From bugzilla-daemon at llvm.org  Mon Apr  1 15:54:44 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 01 Apr 2013 22:54:44 +0000
Subject: [LLVMbugs] [Bug 15649] New: clang-sa should warn when taking the
 address of __block storage?
Message-ID: <bug-15649-206@http.llvm.org/bugs/>

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

            Bug ID: 15649
           Summary: clang-sa should warn when taking the address of
                    __block storage?
           Product: clang
           Version: 3.2
          Hardware: Macintosh
                OS: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: Static Analyzer
          Assignee: kremenek at apple.com
          Reporter: jim.correia at pobox.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 10270
  --> http://llvm.org/bugs/attachment.cgi?id=10270&action=edit
sample code

Build and run the attached sample code.

-performTest1 works correctly when built with MRR. (Ignoring the possibility
that it won't if the autorelease pool implementation details of
NSFileCoordinator change.)

It doesn't work correctly when built for ARC. The reason is that the code
that the compiler generates (-performTest2 is written similarly to the what
the method looks like with the compiler generated code) overwrites the value
of error set in the block.

-performTest3 doesn't work correctly (either for MRR or ARC) because we take
the address of __block storage, then copy the block, moving that value to the
heap. We writing to the stale value on the stack.

These are really two separate issues, but both avoidable if clang-sa issued a
warning that taking the address of __block storage is likely going to lead to
heartache.

xcrun clang NSFileCoordinatorErrorPattern.m -fobjc-arc -framework Foundation 

xcrun clang --version

    Apple LLVM version 4.2 (clang-425.0.27) (based on LLVM 3.2svn)
    Target: x86_64-apple-darwin12.3.0
    Thread model: posix

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130401/c429852d/attachment.html>

From bugzilla-daemon at llvm.org  Mon Apr  1 15:56:04 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 01 Apr 2013 22:56:04 +0000
Subject: [LLVMbugs] [Bug 15650] New: Segfault when assigning value to a
	reference
Message-ID: <bug-15650-206@http.llvm.org/bugs/>

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

            Bug ID: 15650
           Summary: Segfault when assigning value to a reference
           Product: clang
           Version: 3.2
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
          Assignee: unassignedclangbugs at nondot.org
          Reporter: vk at vedantk.com
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 10271
  --> http://llvm.org/bugs/attachment.cgi?id=10271&action=edit
clang++ backtrace

clang++ attempted to generate a diagnostic for me on the line;

    /* Right hand side is of type Vector3f. */
    Vector3f& normal = loc.second.normalized();

It segfaulted while doing that. The full trace is attached in the file
"trace.txt". Here are the last few frames;

0  libLLVM-3.2.so  0x00007f34d25f40bf
1  libLLVM-3.2.so  0x00007f34d25f4529
2  libpthread.so.0 0x00007f34d189c1e0
3  libLLVM-3.2.so  0x00007f34d25bbb75 llvm::APInt::countLeadingZerosSlowCase()
const + 37
4  libLLVM-3.2.so  0x00007f34d25bbd5d llvm::APInt::EqualSlowCase(llvm::APInt
const&) const + 253 
5  clang           0x0000000000ec22b9
6  clang           0x0000000000ec3113
7  clang           0x0000000000ec4380
clang::FormatASTNodeDiagnosticArgument(clang::DiagnosticsEngine::ArgumentKind,
long, char const*, unsigned int, char const*, unsigned int,
std::pair<clang::DiagnosticsEngine::ArgumentKind, long> const*, unsigned int,
llvm::SmallVectorImpl<char>&, void*, llvm::ArrayRef<long>) + 240
8  clang           0x00000000010235fa clang::Diagnostic::FormatDiagnostic(char
const*, char const*, llvm::SmallVectorImpl<char>&) const + 2570
9  clang           0x0000000000638787
clang::TextDiagnosticPrinter::HandleDiagnostic(clang::DiagnosticsEngine::Level,
clang::Diagnostic const&) + 87
10 clang           0x0000000001027f20
clang::DiagnosticIDs::EmitDiag(clang::DiagnosticsEngine&,
clang::DiagnosticIDs::Level) const + 48
11 clang           0x0000000001028175
clang::DiagnosticIDs::ProcessDiag(clang::DiagnosticsEngine&) const + 389 
12 clang           0x0000000001021d5c
clang::DiagnosticsEngine::EmitCurrentDiagnostic(bool) + 76
13 clang           0x000000000090133b
clang::Sema::EmitCurrentDiagnostic(unsigned int) + 683 

clang++ was able to successfully compile the program when I removed the
reference from the left hand side;

    Vector3f normal = loc.second.normalized();

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130401/f8900d9f/attachment.html>

From bugzilla-daemon at llvm.org  Mon Apr  1 18:46:56 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 02 Apr 2013 01:46:56 +0000
Subject: [LLVMbugs] [Bug 15201] clang crashes when building tor
	0.2.4.9-alpha universal
In-Reply-To: <bug-15201-206@http.llvm.org/bugs/>
References: <bug-15201-206@http.llvm.org/bugs/>
Message-ID: <bug-15201-206-czArbFJbqz@http.llvm.org/bugs/>

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |rafael.espindola at gmail.com
         Resolution|---                         |WORKSFORME

--- Comment #6 from Rafael Ávila de Espíndola <rafael.espindola at gmail.com> ---
No reply since 2013-02-07. Please reopen with a .i if appropriate.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130402/da628cf0/attachment.html>

From bugzilla-daemon at llvm.org  Mon Apr  1 20:57:21 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 02 Apr 2013 03:57:21 +0000
Subject: [LLVMbugs] [Bug 15206] clang and gold plugin of 3.2 cannot generate
 bc file for MySQL
In-Reply-To: <bug-15206-206@http.llvm.org/bugs/>
References: <bug-15206-206@http.llvm.org/bugs/>
Message-ID: <bug-15206-206-8i9WHEQ9Zp@http.llvm.org/bugs/>

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |rafael.espindola at gmail.com
         Resolution|---                         |INVALID

--- Comment #6 from Rafael Ávila de Espíndola <rafael.espindola at gmail.com> ---
Closing per comment 5.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130402/0f2583ea/attachment.html>

From bugzilla-daemon at llvm.org  Mon Apr  1 22:40:47 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 02 Apr 2013 05:40:47 +0000
Subject: [LLVMbugs] [Bug 15352] x86 crash: cannot select v4i32 = vselect
In-Reply-To: <bug-15352-206@http.llvm.org/bugs/>
References: <bug-15352-206@http.llvm.org/bugs/>
Message-ID: <bug-15352-206-DKQYsKGtFL@http.llvm.org/bugs/>

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

Bill Wendling <isanbard at gmail.com> changed:

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

--- Comment #2 from Bill Wendling <isanbard at gmail.com> ---
ispc's bug is closed. Closing this now.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130402/019c0a37/attachment.html>

From bugzilla-daemon at llvm.org  Mon Apr  1 22:43:12 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 02 Apr 2013 05:43:12 +0000
Subject: [LLVMbugs] [Bug 15651] New: Clang fails to build a template that
 uses constexpr.
Message-ID: <bug-15651-206@http.llvm.org/bugs/>

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

            Bug ID: 15651
           Summary: Clang fails to build a template that uses constexpr.
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++11
          Assignee: unassignedclangbugs at nondot.org
          Reporter: jujjyl at gmail.com
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 10275
  --> http://llvm.org/bugs/attachment.cgi?id=10275&action=edit
-E -generated test case.

I have built Clang 3.2 on Windows following these instructions:
https://github.com/kripken/emscripten/wiki/Using-Emscripten-from-Visual-Studio-2010
(step 4 on that page)

Using that to build libcxx on Windows for emscripten, I am bit by an issue
where a constexpr inside a template class is not working.

The same code builds ok on Clang 3.2 built on Linux or OSX (following
instructions at
https://github.com/kripken/emscripten/wiki/Getting-started-on-Mac-OS-X and
https://github.com/kripken/emscripten/wiki/Getting-Started-on-Ubuntu-12.10 )

A large test case is available at
https://dl.dropbox.com/u/40949268/emcc/bugs/preprocessed.cpp 

Compiling on Windows with "clang++ -std=c++11 -m32 -U__i386__ -U__x86_64__
-U__i386 -U__x86_64 -Ui386 -Ux86_64 -U__SSE__ -U__SSE2__ -U__MMX__
-UX87_DOUBLE_ROUNDING -UHAVE_GCC_ASM_FOR_X87 -DEMSCRIPTEN -U__STRICT_ANSI__
-U__CYGWIN__ -D__STDC__ -Xclang -triple=i386-pc-linux-gnu
-D__IEEE_LITTLE_ENDIAN -fno-math-errno -fno-ms-compatibility -nostdinc
-nostdinc++ -Xclang -nobuiltininc -Xclang -nostdsysteminc -U__APPLE__
-U__linux__ -emit-llvm -c preprocessed.cpp"

gives the error

clang++: warning: argument unused during compilation: '-nostdinc++'

G:\Inttel-slave\win-emcc-incoming-tests\build\system\lib\libcxx\condition_variable.cpp:59:30:
error: constexpr variable 'ts_sec_max' must be initialized by a constant
expression
 _LIBCPP_CONSTEXPR ts_sec ts_sec_max = numeric_limits::max();
 ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

G:\Inttel-slave\win-emcc-incoming-tests\build\system\lib\libcxx\condition_variable.cpp:59:43:
note: undefined function 'max' cannot be used in a constant expression
 _LIBCPP_CONSTEXPR ts_sec ts_sec_max = numeric_limits::max();
 ^

G:\Inttel-slave\win-emcc-incoming-tests\build\system\include\libcxx\limits:443:61:
note: declared here
 _LIBCPP_INLINE_VISIBILITY static _LIBCPP_CONSTEXPR type max() _NOEXCEPT
{return __base::max();}
 ^
 1 error generated.

A minimal failing example that exhibits the same problem is available at
https://dl.dropbox.com/u/40949268/emcc/bugs/constexpr_fail.cpp which fails as
follows: https://dl.dropbox.com/u/40949268/emcc/bugs/constexpr_fail.txt

The same problem is tracked in the emscripten issue tracker here:
https://github.com/kripken/emscripten/issues/1019

I also tried with the Clang trunk on Windows, which also fails in the same way:
https://dl.dropbox.com/u/40949268/emcc/bugs/constexpr_fail_clang33trunk.txt

Any ideas what could cause this kind of thing to work on linux and OSX builds
of Clang, but not on Windows builds of Clang?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130402/e59557c0/attachment.html>

From bugzilla-daemon at llvm.org  Tue Apr  2 01:17:03 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 02 Apr 2013 08:17:03 +0000
Subject: [LLVMbugs] [Bug 15440] llvm opt crash on csmith fuzz testcase
In-Reply-To: <bug-15440-206@http.llvm.org/bugs/>
References: <bug-15440-206@http.llvm.org/bugs/>
Message-ID: <bug-15440-206-kEETrqKtJU@http.llvm.org/bugs/>

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

Bill Wendling <isanbard at gmail.com> changed:

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

--- Comment #1 from Bill Wendling <isanbard at gmail.com> ---
This should be fixed here:

Sending        lib/Transforms/IPO/GlobalOpt.cpp
Adding         test/Transforms/GlobalOpt/crash-2.ll
Transmitting file data ..
Committed revision 178531.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130402/ba353945/attachment.html>

From bugzilla-daemon at llvm.org  Tue Apr  2 01:17:03 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 02 Apr 2013 08:17:03 +0000
Subject: [LLVMbugs] [Bug 15465] Emscripten tracking bug
In-Reply-To: <bug-15465-206@http.llvm.org/bugs/>
References: <bug-15465-206@http.llvm.org/bugs/>
Message-ID: <bug-15465-206-CnJkp9t2vE@http.llvm.org/bugs/>

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

Bug 15465 depends on bug 15440, which changed state.

Bug 15440 Summary: llvm opt crash on csmith fuzz testcase
http://llvm.org/bugs/show_bug.cgi?id=15440

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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130402/2ee91d86/attachment.html>

From bugzilla-daemon at llvm.org  Tue Apr  2 02:22:16 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 02 Apr 2013 09:22:16 +0000
Subject: [LLVMbugs] [Bug 15653] New: HTTPS access to llvm.org gives 404 error
Message-ID: <bug-15653-206@http.llvm.org/bugs/>

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

            Bug ID: 15653
           Summary: HTTPS access to llvm.org gives 404 error
           Product: Website
           Version: unspecified
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: General Website
          Assignee: unassignedbugs at nondot.org
          Reporter: Matthieu.Moy at imag.fr
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

I mistakenly accessed https://llvm.org/ (httpS instead of plain HTTP). I'd
expect either

* HTTPS working
* Redirection to the plain HTTP site
* at worse, no reply from server.

Instead, I got a 404 error:

Not Found
The requested URL / was not found on this server.

I guess there's a misconfigured virtual host in the apache config.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130402/c048a02d/attachment.html>

From bugzilla-daemon at llvm.org  Tue Apr  2 04:14:11 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 02 Apr 2013 11:14:11 +0000
Subject: [LLVMbugs] [Bug 15654] New: False positive: free() on a "constant"
 malloc()-ed address
Message-ID: <bug-15654-206@http.llvm.org/bugs/>

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

            Bug ID: 15654
           Summary: False positive: free() on a "constant" malloc()-ed
                    address
           Product: clang
           Version: unspecified
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Static Analyzer
          Assignee: kremenek at apple.com
          Reporter: ranma42 at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 10276
  --> http://llvm.org/bugs/attachment.cgi?id=10276&action=edit
Reduced testcase

Running the latest checker (checker-272 (2013-03-01 14:12:07) ) on the attached
code, it incorrectly reports:

test-free.c:16:2: warning: Argument to free() is a constant address (42), which
is not memory allocated by malloc()

Although the address can be proved to be equal to a compile-time known constant
in one of the branches, it has actually been allocated by malloc(), so it
should not be reported as a problem in this case.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130402/a72508bd/attachment.html>

From bugzilla-daemon at llvm.org  Tue Apr  2 06:44:17 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 02 Apr 2013 13:44:17 +0000
Subject: [LLVMbugs] [Bug 15642] clang -MMD doesn't escape dollar signs in
	output
In-Reply-To: <bug-15642-206@http.llvm.org/bugs/>
References: <bug-15642-206@http.llvm.org/bugs/>
Message-ID: <bug-15642-206-jjpt8UKfYU@http.llvm.org/bugs/>

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

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> ---
Fixed in r178540.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130402/5ce44a15/attachment.html>

From bugzilla-daemon at llvm.org  Tue Apr  2 11:23:49 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 02 Apr 2013 18:23:49 +0000
Subject: [LLVMbugs] [Bug 15655] New: libLLVMTarget.so is not linked with
 -lLLVMCodeGet,
 unresolved llvm::MachineInstr::hasPropertyInBundle when linking llvm-dis
Message-ID: <bug-15655-206@http.llvm.org/bugs/>

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

            Bug ID: 15655
           Summary: libLLVMTarget.so is not linked with -lLLVMCodeGet,
                    unresolved llvm::MachineInstr::hasPropertyInBundle
                    when linking llvm-dis
           Product: Build scripts
           Version: 3.2
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: cmake
          Assignee: unassignedbugs at nondot.org
          Reporter: dilyan.palauzov at aegee.org
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

I compile llvm-3.2 with cmake.  On 'make' I get the message

[ 61%] Built target opt
[ 61%] Built target llvm-as
Linking CXX executable ../../bin/llvm-dis
../../lib/libLLVMTarget.so: undefined reference to
`llvm::MachineInstr::hasPropertyInBundle(unsigned int,
llvm::MachineInstr::QueryType) const'
collect2: error: ld returned 1 exit status
make[2]: *** [bin/llvm-dis] Error 1
make[1]: *** [tools/llvm-dis/CMakeFiles/llvm-dis.dir/all] Error 2
make: *** [all] Error 2

Indeed, libLLVMCodeGen.so defines llvm::MachineInstr::hasPropertyInBundle:

nm -C lib/libLLVMCodeGen.so |grep hasPropertyInBundle
000000000027136c T llvm::MachineInstr::hasPropertyInBundle(unsigned int,
llvm::MachineInstr::QueryType) const


and libLLVMTarget.so has hasPropertyInBundle as undefined symbol:

nm -C lib/libLLVMTarget.so |grep hasPropertyInBundle
                 U llvm::MachineInstr::hasPropertyInBundle(unsigned int,
llvm::MachineInstr::QueryType) const


and libLLVMTarget.so does not depend on libLLVMCodeGen.so:

readelf -d lib/libLLVMTarget.so |grep NEEDED
 0x0000000000000001 (NEEDED)             Shared library: [libdl.so.2]
 0x0000000000000001 (NEEDED)             Shared library: [libpthread.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libLLVMCore.so]
 0x0000000000000001 (NEEDED)             Shared library: [libLLVMMC.so]
 0x0000000000000001 (NEEDED)             Shared library: [libLLVMSupport.so]
 0x0000000000000001 (NEEDED)             Shared library: [libLLVMObject.so]
 0x0000000000000001 (NEEDED)             Shared library: [libstdc++.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libm.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libgcc_s.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]

I noticed, that both libLLVMTarget.so and libLLVMCodeGen.so have a private
llvm::MachineInstr::hasProperty , but only libLLVMCodeGen has and exports
hasPropertyInBundle() .

So the error is one of:

-- libLLVMTarget.so is not linked with -lLLVMCodeGet, or
-- llvm-dis is not linked with -lLLVMCodeGet, in case llvm-dis does not use on
its own hasPropertyInBundle, but depends on libLLVMTarget

I can compile llvm-dis using Autoconf, but not with cmake.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130402/94b08122/attachment.html>

From bugzilla-daemon at llvm.org  Tue Apr  2 11:37:41 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 02 Apr 2013 18:37:41 +0000
Subject: [LLVMbugs] [Bug 15630] PPC64: atomic store results in bus error if
 type i8 is used
In-Reply-To: <bug-15630-206@http.llvm.org/bugs/>
References: <bug-15630-206@http.llvm.org/bugs/>
Message-ID: <bug-15630-206-8TbxxApk9K@http.llvm.org/bugs/>

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

Bill Schmidt <wschmidt at linux.vnet.ibm.com> changed:

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

--- Comment #4 from Bill Schmidt <wschmidt at linux.vnet.ibm.com> ---
Fixed in r178559.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130402/f7a0e9f6/attachment.html>

From bugzilla-daemon at llvm.org  Tue Apr  2 13:15:29 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 02 Apr 2013 20:15:29 +0000
Subject: [LLVMbugs] [Bug 15656] New: not substituting into some
 instantiation-dependent (but not type-dependent) expressions inside sizeof
Message-ID: <bug-15656-206@http.llvm.org/bugs/>

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

            Bug ID: 15656
           Summary: not substituting into some instantiation-dependent
                    (but not type-dependent) expressions inside sizeof
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++11
          Assignee: unassignedclangbugs at nondot.org
          Reporter: richard-llvm at metafoo.co.uk
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified

For instance:

template<typename T> void f(int a[sizeof(static_cast<int &>( T() ))]);
void g() { f<double[42]>(0); }

We should reject this (both the value-initialization and the cast are
ill-formed), but we apparently don't even instantiate inside the sizeof's
operand (perhaps because it's not type-dependent?).

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130402/8a45b884/attachment.html>

From bugzilla-daemon at llvm.org  Tue Apr  2 17:34:16 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 03 Apr 2013 00:34:16 +0000
Subject: [LLVMbugs] [Bug 15351] Illegal instruction with -march=native
In-Reply-To: <bug-15351-206@http.llvm.org/bugs/>
References: <bug-15351-206@http.llvm.org/bugs/>
Message-ID: <bug-15351-206-ynhdnL87YQ@http.llvm.org/bugs/>

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

Aaron Ballman <aaron at aaronballman.com> changed:

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

--- Comment #5 from Aaron Ballman <aaron at aaronballman.com> ---
Fixed in r178598

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130403/2d858811/attachment.html>

From bugzilla-daemon at llvm.org  Tue Apr  2 17:42:52 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 03 Apr 2013 00:42:52 +0000
Subject: [LLVMbugs] [Bug 15657] New: s/__threaad_execute/__thread_execute/
Message-ID: <bug-15657-206@http.llvm.org/bugs/>

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

            Bug ID: 15657
           Summary: s/__threaad_execute/__thread_execute/
           Product: libc++
           Version: 3.2
          Hardware: All
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: All Bugs
          Assignee: hhinnant at apple.com
          Reporter: arthur.j.odwyer at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Lines 331 and 343 in "include/thread" contain the identifier
"__threaad_execute", which was probably intended to be "__thread_execute".
Right now it's misspelled consistently everywhere, so there's no bug in the
code's behavior; it just looks dumb if you happen to be scanning headers and/or
reading stack traces.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130403/5e13e301/attachment.html>

From bugzilla-daemon at llvm.org  Tue Apr  2 20:13:01 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 03 Apr 2013 03:13:01 +0000
Subject: [LLVMbugs] [Bug 15351] Illegal instruction with -march=native
In-Reply-To: <bug-15351-206@http.llvm.org/bugs/>
References: <bug-15351-206@http.llvm.org/bugs/>
Message-ID: <bug-15351-206-VR1XEbabQG@http.llvm.org/bugs/>

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

Aaron Ballman <aaron at aaronballman.com> changed:

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

--- Comment #6 from Aaron Ballman <aaron at aaronballman.com> ---
Reopening the bug -- my patch broke a gcc 4.6 builder that doesn't understand
xgetbv.  I will reapply the patch once I've solved that issue.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130403/6d2417e9/attachment.html>

From bugzilla-daemon at llvm.org  Tue Apr  2 20:42:38 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 03 Apr 2013 03:42:38 +0000
Subject: [LLVMbugs] [Bug 15491] Assertion `Result && "Could not evaluate
 expression"' failed
In-Reply-To: <bug-15491-206@http.llvm.org/bugs/>
References: <bug-15491-206@http.llvm.org/bugs/>
Message-ID: <bug-15491-206-AQ7ZQrHzsQ@http.llvm.org/bugs/>

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

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 #4 from Rafael Ávila de Espíndola <rafael.espindola at gmail.com> ---
Fixed in r178609.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130403/01637684/attachment.html>

From bugzilla-daemon at llvm.org  Wed Apr  3 06:06:07 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 03 Apr 2013 13:06:07 +0000
Subject: [LLVMbugs] [Bug 15632] PPC64: UNREACHABLE executed in
 LegalizeFloatTypes.cpp because of PPC128 float
In-Reply-To: <bug-15632-206@http.llvm.org/bugs/>
References: <bug-15632-206@http.llvm.org/bugs/>
Message-ID: <bug-15632-206-2OvF19bj1a@http.llvm.org/bugs/>

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

Bill Schmidt <wschmidt at linux.vnet.ibm.com> changed:

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

--- Comment #4 from Bill Schmidt <wschmidt at linux.vnet.ibm.com> ---
Fixed in r178639.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130403/19a487c4/attachment.html>

From bugzilla-daemon at llvm.org  Wed Apr  3 06:08:03 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 03 Apr 2013 13:08:03 +0000
Subject: [LLVMbugs] [Bug 15351] Illegal instruction with -march=native
In-Reply-To: <bug-15351-206@http.llvm.org/bugs/>
References: <bug-15351-206@http.llvm.org/bugs/>
Message-ID: <bug-15351-206-mFYnu7aYHW@http.llvm.org/bugs/>

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

Aaron Ballman <aaron at aaronballman.com> changed:

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

--- Comment #7 from Aaron Ballman <aaron at aaronballman.com> ---
Fixed in r178636; this time for sure!

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130403/9e649329/attachment.html>

From bugzilla-daemon at llvm.org  Wed Apr  3 09:07:05 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 03 Apr 2013 16:07:05 +0000
Subject: [LLVMbugs] [Bug 15659] New: std::vector + emplaced
 std::istringstream .seekg(0,
 std::ios_base::beg) leads to missize and trash at end of the stream .str()
Message-ID: <bug-15659-206@http.llvm.org/bugs/>

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

            Bug ID: 15659
           Summary: std::vector + emplaced std::istringstream .seekg(0,
                    std::ios_base::beg) leads to missize and trash at end
                    of the stream .str()
           Product: libc++
           Version: unspecified
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: release blocker
          Priority: P
         Component: All Bugs
          Assignee: hhinnant at apple.com
          Reporter: iamtakingiteasy at eientei.org
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 10279
  --> http://llvm.org/bugs/attachment.cgi?id=10279&action=edit
Example testcase

When std::istringstream emplaced into std::vector alongside with other
std::istringstream and then seeked to begening with .seekg(0,
std::ios_base::beg), it size becames largally bigger than original and end of
the stream filled with trash (probably, uninitalized or miss-accessed) data.

It is also known to work as expected on VC++ 2012.

The problem was reproduced with exact observed output by other person with
libc++.

Attaching a simple test-case; compiled with line

$ clang++ -std=c++11 -stdlib=libc++ tmp.cpp && ./a.out

Expected output:

3
MSG
3
31
hub started at [00 6b 8b 45 69]
31


Observed output:

3
MSG
3
31
hub started at [00 6b 8b 45 69]
593

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130403/d60f87c6/attachment.html>

From bugzilla-daemon at llvm.org  Wed Apr  3 11:19:37 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 03 Apr 2013 18:19:37 +0000
Subject: [LLVMbugs] [Bug 15661] New: Concatenation with empty macro argument
 does not prevent recursive expansion of macro
Message-ID: <bug-15661-206@http.llvm.org/bugs/>

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

            Bug ID: 15661
           Summary: Concatenation with empty macro argument does not
                    prevent recursive expansion of macro
           Product: clang
           Version: 3.2
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
          Assignee: unassignedclangbugs at nondot.org
          Reporter: harald at gigawatt.nl
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Prompted by a bug report to GCC:

#define foo(x, y) x ## y
1
foo(f,oo(,))
2
foo(,foo(,))
3
foo(a,foo(,))
4

is preprocessed to

$ clang -std=c99 -E bug.c
# 1 "bug.c"
# 1 "bug.c" 1
# 1 "<built-in>" 1
# 1 "<built-in>" 3
# 152 "<built-in>" 3
# 1 "<command line>" 1
# 1 "<built-in>" 2
# 1 "bug.c" 2

1
foo(,)
2

3
afoo(,)
4

The expansion between 1 and 2 is correct, and shows that as the inner foo only
appears after concatenation, it is not expanded because it is seen in the
context of another foo macro expansion.

The expansion between 3 and 4 is correct, and shows that as the macro argument
is used as an operand to ##, it is not expanded.

The expansion between 2 and 3 is wrong, I believe: the inner foo should not be
expanded during argument substitution because it is used as an operand of ##,
and it should not be expanded after argument substitution because that happens
in the context of the outer foo macro expansion. There are no other moments
when it could be expanded.

This happens with Fedora 18's clang 3.2:
$ clang -v
clang version 3.2 (tags/RELEASE_32/final)
Target: x86_64-redhat-linux-gnu
Thread model: posix

Apologies if this is fixed already, but I cannot find a bugreport about this,
closed or open.

gcc and mcpp both give the expected output:

$ gcc -std=c99 -E bug.c
# 1 "bug.c"
# 1 "<command-line>"
# 1 "bug.c"

1
foo(,)
2
foo(,)
3
afoo(,)
4

$ mcpp bug.c
#line 1 "/home/harald/bug.c"

1
foo (,)
2
foo (,)
3
afoo (,)
4

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130403/31172db2/attachment.html>

From bugzilla-daemon at llvm.org  Wed Apr  3 11:33:15 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 03 Apr 2013 18:33:15 +0000
Subject: [LLVMbugs] [Bug 15661] Concatenation with empty macro argument does
 not prevent recursive expansion of macro
In-Reply-To: <bug-15661-206@http.llvm.org/bugs/>
References: <bug-15661-206@http.llvm.org/bugs/>
Message-ID: <bug-15661-206-8tTs3UW5jS@http.llvm.org/bugs/>

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

Harald van Dijk <harald at gigawatt.nl> changed:

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

--- Comment #1 from Harald van Dijk <harald at gigawatt.nl> ---
...and of course an older report does show up after an additional attempt at
searching. That bug does not have a nested expansion of the same macro, but
this bug does seem like a special case of that one.

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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130403/e3b214ff/attachment.html>

From bugzilla-daemon at llvm.org  Wed Apr  3 13:16:53 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 03 Apr 2013 20:16:53 +0000
Subject: [LLVMbugs] [Bug 15662] New: incorrect dwarf information about
 function arguments is produced in one case
Message-ID: <bug-15662-206@http.llvm.org/bugs/>

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

            Bug ID: 15662
           Summary: incorrect dwarf information about function arguments
                    is produced in one case
           Product: clang
           Version: 3.2
          Hardware: PC
                OS: FreeBSD
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: avg at FreeBSD.org
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 10282
  --> http://llvm.org/bugs/attachment.cgi?id=10282&action=edit
pre-processed source code

Function signature in FreeBSD source code is:

void _sx_xunlock(struct sx *sx, const char *file, int line);

clang generated dwarf information (as reported by objdump -W) is:
 <1><2c70>: Abbrev Number: 55 (DW_TAG_subprogram)
  <2c71>     DW_AT_name        : (indirect string, offset: 0x1817): _sx_xunlock
  <2c75>     DW_AT_decl_file   : 1
  <2c76>     DW_AT_decl_line   : 373
  <2c78>     DW_AT_prototyped  : 1
  <2c78>     DW_AT_external    : 1
  <2c78>     DW_AT_inline      : 1      (inlined)
 <2><2c79>: Abbrev Number: 51 (DW_TAG_formal_parameter)
  <2c7a>     DW_AT_name        : (indirect string, offset: 0xd061): line
  <2c7e>     DW_AT_decl_file   : 1
  <2c7f>     DW_AT_decl_line   : 373
  <2c81>     DW_AT_type        : <a2>
 <2><2c85>: Abbrev Number: 51 (DW_TAG_formal_parameter)
  <2c86>     DW_AT_name        : (indirect string, offset: 0xd056): sx
  <2c8a>     DW_AT_decl_file   : 1
  <2c8b>     DW_AT_decl_line   : 373
  <2c8d>     DW_AT_type        : <782c>
 <2><2c91>: Abbrev Number: 51 (DW_TAG_formal_parameter)
  <2c92>     DW_AT_name        : (indirect string, offset: 0xc67): file
  <2c96>     DW_AT_decl_file   : 1
  <2c97>     DW_AT_decl_line   : 373
  <2c99>     DW_AT_type        : <32>

That is, order of arguments is recorded as 'line', 'sx', 'file'.

Please see the attached preprocessed file.
My compilation options were:
-pipe -fno-strict-aliasing -march=amdfam10 -std=c99 -g -O -Wall
-Wredundant-decls
-Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith
-Winline
-Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions
-Wmissing-include-dirs
-fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body
-Wno-error-parentheses-equality -nostdinc -fno-omit-frame-pointer
-mno-omit-leaf-frame-pointer -mno-aes -mno-avx -mcmodel=kernel -mno-red-zone
-mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding
-fstack-protector -Werror

clang is:
FreeBSD clang version 3.2 (tags/RELEASE_32/final 170710) 20121221

The problem doesn't seem to be a common one.
Thus far, I have seen it only with this function (out of many inspected).

Please also see this thread for a preliminary discussion of this issue:
http://lists.cs.uiuc.edu/pipermail/cfe-dev/2013-April/028829.html

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130403/0724e7cc/attachment.html>

From bugzilla-daemon at llvm.org  Wed Apr  3 13:21:47 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 03 Apr 2013 20:21:47 +0000
Subject: [LLVMbugs] [Bug 15659] std::vector + emplaced std::istringstream
 .seekg(0,
 std::ios_base::beg) leads to missize and trash at end of the stream .str()
In-Reply-To: <bug-15659-206@http.llvm.org/bugs/>
References: <bug-15659-206@http.llvm.org/bugs/>
Message-ID: <bug-15659-206-B7dHdnxZfo@http.llvm.org/bugs/>

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

Howard Hinnant <hhinnant at apple.com> changed:

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

--- Comment #2 from Howard Hinnant <hhinnant at apple.com> ---
Fix Committed revision 178690.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130403/08031111/attachment.html>

From bugzilla-daemon at llvm.org  Wed Apr  3 13:29:59 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 03 Apr 2013 20:29:59 +0000
Subject: [LLVMbugs] [Bug 15657] s/__threaad_execute/__thread_execute/
In-Reply-To: <bug-15657-206@http.llvm.org/bugs/>
References: <bug-15657-206@http.llvm.org/bugs/>
Message-ID: <bug-15657-206-FoKJJIUuEh@http.llvm.org/bugs/>

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

Howard Hinnant <hhinnant at apple.com> changed:

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

--- Comment #1 from Howard Hinnant <hhinnant at apple.com> ---
Committed revision 178691.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130403/fcde7869/attachment.html>

From bugzilla-daemon at llvm.org  Wed Apr  3 14:27:06 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 03 Apr 2013 21:27:06 +0000
Subject: [LLVMbugs] [Bug 15485] UNREACHABLE at IdentifierResolver.cpp:78
 when friend-ing a using declaration
In-Reply-To: <bug-15485-206@http.llvm.org/bugs/>
References: <bug-15485-206@http.llvm.org/bugs/>
Message-ID: <bug-15485-206-jPqZPR02Yz@http.llvm.org/bugs/>

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

Stephen Lin <stephenwlin at gmail.com> changed:

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

--- Comment #5 from Stephen Lin <stephenwlin at gmail.com> ---
this is patched by r178698

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130403/9393b6df/attachment.html>

From bugzilla-daemon at llvm.org  Wed Apr  3 14:40:20 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 03 Apr 2013 21:40:20 +0000
Subject: [LLVMbugs] [Bug 15663] New: GNU "a?:b" ternary operator with blocks
 causes bus error
Message-ID: <bug-15663-206@http.llvm.org/bugs/>

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

            Bug ID: 15663
           Summary: GNU "a?:b" ternary operator with blocks causes bus
                    error
           Product: clang
           Version: trunk
          Hardware: All
                OS: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: arthur.j.odwyer at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 10283
  --> http://llvm.org/bugs/attachment.cgi?id=10283&action=edit
Output of "clang test.c -v"

cat >test.c <<EOF
void (^b)() = ^{};
int main() {
    (b ?: ^{})();
}
EOF
clang test.c
./a.out

Bus error: 10

Notice that "void (^b)()" is the Apple Blocks extension, and "?:" is the GNU
ternary operator — "a ?: b" is equivalent to "a ? a : b" except that "a" is
evaluated only once.

This reproduces in Objective-C (test.m) as well as in C (test.c).

Replacing the offending expression with (^{} ?: ^{}) avoids the bus error.
Replacing it with (b ?: b) also avoids the bus error.

In my unreduced code, "b" was a complicated expression with side effects that
could in fact be NULL (hence my use of the GNU ternary operator), but it turns
out that this is not relevant to reproducing the bug.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130403/ed27757d/attachment.html>

From bugzilla-daemon at llvm.org  Wed Apr  3 17:05:18 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 04 Apr 2013 00:05:18 +0000
Subject: [LLVMbugs] [Bug 15664] New: -frewrite-includes doesn't handle
	Windows UTF-8 BOM
Message-ID: <bug-15664-206@http.llvm.org/bugs/>

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

            Bug ID: 15664
           Summary: -frewrite-includes doesn't handle Windows UTF-8 BOM
           Product: clang
           Version: unspecified
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
          Assignee: unassignedclangbugs at nondot.org
          Reporter: paul_robinson at playstation.sony.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

when Clang crashes, it will create a preprocessed file using
-frewrite-includes.
Unfortunately this does not strip byte-order marks from included headers.
(http://en.wikipedia.org/wiki/Byte_order_mark)

Attached bom.c is a regular text file, bom.h is encoded as UTF-8 with BOM.

C:\Data\scratch>clang -c bom.c 
C:\Data\scratch>clang -E bom.c > bom-E.c
C:\Data\scratch>clang -c bom-E.c
C:\Data\scratch>clang -E -frewrite-includes bom.c > bom-E2.c
C:\Data\scratch>clang -c bom-E2.c
./bom.h:1:1: error: non-ASCII characters are not allowed outside of literals
and

      identifiers
<U+FEFF>void foo();
^~~~~~~~
1 error generated.

C:\Data\scratch>clang --version
clang version 3.3 (178499)
Target: i686-pc-win32
Thread model: posix

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130404/5239d735/attachment.html>

From bugzilla-daemon at llvm.org  Wed Apr  3 18:03:57 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 04 Apr 2013 01:03:57 +0000
Subject: [LLVMbugs] [Bug 15543] All binaries are linked with -rdynamic
In-Reply-To: <bug-15543-206@http.llvm.org/bugs/>
References: <bug-15543-206@http.llvm.org/bugs/>
Message-ID: <bug-15543-206-9qqXfnUIQa@http.llvm.org/bugs/>

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

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

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

--- Comment #2 from Rafael Ávila de Espíndola <rafael.espindola at gmail.com> ---
Fixed in 178725.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130404/f1bb77ed/attachment.html>

From bugzilla-daemon at llvm.org  Wed Apr  3 18:35:20 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 04 Apr 2013 01:35:20 +0000
Subject: [LLVMbugs] [Bug 15665] New: /Support/raw_ostream.cpp:326: void
 llvm::raw_ostream::copy_to_buffer(const char *,
 size_t): Assertion `Size <= size_t(OutBufEnd - OutBufCur) && "Buffer
 overrun!"' failed/
Message-ID: <bug-15665-206@http.llvm.org/bugs/>

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

            Bug ID: 15665
           Summary: /Support/raw_ostream.cpp:326: void
                    llvm::raw_ostream::copy_to_buffer(const char *,
                    size_t): Assertion `Size <= size_t(OutBufEnd -
                    OutBufCur) && "Buffer overrun!"' failed/
           Product: new-bugs
           Version: unspecified
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: scherkus at chromium.org
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Hit this while compiling Chromium code.

I rebased my git patch to trunk and I know there are syntax errors / it
shouldn't compile as-is, however it also shouldn't crash clang :)


../../media/filters/video_frame_stream.cc:59:7: error: no viable conversion
from 'Callback<typename internal::BindState<typename
internal::FunctorTraits<void (class VideoFrameStream::*)(class scoped_
ptr<class VideoDecoderSelector, struct DefaultDeleter<class
VideoDecoderSelector> >, const class scoped_refptr<class VideoDecoder> &, const
class scoped_refptr<class DecryptingDemuxerStream> &)>::Run
nableType, typename internal::FunctorTraits<void (class
VideoFrameStream::*)(class scoped_ptr<class VideoDecoderSelector, struct
DefaultDeleter<class VideoDecoderSelector> >, const class scoped_refpt
r<class VideoDecoder> &, const class scoped_refptr<class
DecryptingDemuxerStream> &)>::RunType, void (typename
internal::CallbackParamTraits<class WeakPtr<class VideoFrameStream>
>::StorageType, type
name internal::CallbackParamTraits<class PassedWrapper<class scoped_ptr<class
VideoDecoderSelector, struct DefaultDeleter<class VideoDecoderSelector> > >
>::StorageType)>::UnboundRunType>' to 'const 
Callback<void (scoped_ptr<class media::VideoDecoder>, const scoped_refptr<class
media::DecryptingDemuxerStream> &)>'
      base::Bind(&VideoFrameStream::OnDecoderSelected, weak_this_,
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../base/callback.h:447:7: note: candidate constructor (the implicit copy
constructor) not viable: no known conversion from 'base::Callback<typename
internal::BindState<typename internal::FunctorTr
aits<void (VideoFrameStream::*)(scoped_ptr<VideoDecoderSelector,
DefaultDeleter<VideoDecoderSelector> >, const scoped_refptr<VideoDecoder> &,
const scoped_refptr<DecryptingDemuxerStream> &)>::Runnabl
eType, typename internal::FunctorTraits<void
(VideoFrameStream::*)(scoped_ptr<VideoDecoderSelector,
DefaultDeleter<VideoDecoderSelector> >, const scoped_refptr<VideoDecoder> &,
const scoped_refptr<De
cryptingDemuxerStream> &)>::RunType, void (typename
internal::CallbackParamTraits<WeakPtr<VideoFrameStream> >::StorageType,
typename internal::CallbackParamTraits<PassedWrapper<scoped_ptr<VideoDecode
rSelector, DefaultDeleter<VideoDecoderSelector> > >
>::StorageType)>::UnboundRunType>' to 'const base::Callback<void
(scoped_ptr<media::VideoDecoder, base::DefaultDeleter<media::VideoDecoder> >,
cons
t scoped_refptr<media::DecryptingDemuxerStream> &)> &' for 1st argument
class Callback<R(A1, A2)> : public internal::CallbackBase {
      ^
clang:
/usr/local/google/chrome/src/third_party/llvm/lib/Support/raw_ostream.cpp:326:
void llvm::raw_ostream::copy_to_buffer(const char *, size_t): Assertion `Size
<= size_t(OutBufEnd - OutBufCur) &&
 "Buffer overrun!"' failed.
0  clang     0x0000000001e3f545 llvm::sys::PrintStackTrace(_IO_FILE*) + 37
1  clang     0x0000000001e3fa33
2  libc.so.6 0x00007fa560e944a0
3  libc.so.6 0x00007fa560e94425 gsignal + 53
4  libc.so.6 0x00007fa560e97b8b abort + 379
5  libc.so.6 0x00007fa560e8d0ee
6  libc.so.6 0x00007fa560e8d192
7  clang     0x0000000001e54a99 llvm::raw_ostream::write(char const*, unsigned
long) + 505
8  clang     0x00000000010ad3c3
clang::FormatASTNodeDiagnosticArgument(clang::DiagnosticsEngine::ArgumentKind,
long, char const*, unsigned int, char const*, unsigned int,
std::pair<clang::Diagnostics
Engine::ArgumentKind, long> const*, unsigned int, llvm::SmallVectorImpl<char>&,
void*, llvm::ArrayRef<long>) + 3299
9  clang     0x00000000011fff86 clang::Diagnostic::FormatDiagnostic(char
const*, char const*, llvm::SmallVectorImpl<char>&) const + 5366
10 clang     0x00000000006a4a30
clang::TextDiagnosticPrinter::HandleDiagnostic(clang::DiagnosticsEngine::Level,
clang::Diagnostic const&) + 96
11 clang     0x0000000001202c22
clang::DiagnosticIDs::ProcessDiag(clang::DiagnosticsEngine&) const + 546
12 clang     0x00000000011fe944
clang::DiagnosticsEngine::EmitCurrentDiagnostic(bool) + 84
13 clang     0x00000000009c10cd clang::Sema::EmitCurrentDiagnostic(unsigned
int) + 1005
14 clang     0x0000000000bb0796
clang::OverloadCandidateSet::NoteCandidates(clang::Sema&,
clang::OverloadCandidateDisplayKind, llvm::ArrayRef<clang::Expr*>,
llvm::StringRef, clang::SourceLocation) + 
8342
15 clang     0x0000000000b750dd
clang::InitializationSequence::Diagnose(clang::Sema&, clang::InitializedEntity
const&, clang::InitializationKind const&, clang::Expr**, unsigned int) + 7661
16 clang     0x0000000000b702a3
clang::InitializationSequence::Perform(clang::Sema&, clang::InitializedEntity
const&, clang::InitializationKind const&, llvm::MutableArrayRef<clang::Expr*>,
clang::Qua
lType*) + 339
17 clang     0x0000000000b76e39
clang::Sema::PerformCopyInitialization(clang::InitializedEntity const&,
clang::SourceLocation, clang::ActionResult<clang::Expr*, true>, bool, bool) +
249
18 clang     0x0000000000aef086
clang::Sema::GatherArgumentsForCall(clang::SourceLocation,
clang::FunctionDecl*, clang::FunctionProtoType const*, unsigned int,
clang::Expr**, unsigned int, llvm::Smal
lVector<clang::Expr*, 8u>&, clang::Sema::VariadicCallType, bool, bool) + 998
19 clang     0x0000000000aee763
clang::Sema::ConvertArgumentsForCall(clang::CallExpr*, clang::Expr*,
clang::FunctionDecl*, clang::FunctionProtoType const*, clang::Expr**, unsigned
int, clang::SourceL
ocation, bool) + 659
20 clang     0x0000000000bc46cd
clang::Sema::BuildCallToMemberFunction(clang::Scope*, clang::Expr*,
clang::SourceLocation, clang::Expr**, unsigned int, clang::SourceLocation) +
4301
21 clang     0x0000000000ae20d6 clang::Sema::ActOnCallExpr(clang::Scope*,
clang::Expr*, clang::SourceLocation, llvm::MutableArrayRef<clang::Expr*>,
clang::SourceLocation, clang::Expr*, bool) + 1302
22 clang     0x000000000096f266
clang::Parser::ParsePostfixExpressionSuffix(clang::ActionResult<clang::Expr*,
true>) + 3174
23 clang     0x00000000009726d3 clang::Parser::ParseCastExpression(bool, bool,
bool&, clang::Parser::TypeCastState) + 11987
24 clang     0x000000000096d2d4
clang::Parser::ParseAssignmentExpression(clang::Parser::TypeCastState) + 132
25 clang     0x000000000096d239
clang::Parser::ParseExpression(clang::Parser::TypeCastState) + 9
26 clang     0x000000000099a2bc clang::Parser::ParseExprStatement() + 44
27 clang     0x0000000000999e44
clang::Parser::ParseStatementOrDeclarationAfterAttributes(llvm::SmallVector<clang::Stmt*,
32u>&, bool, clang::SourceLocation*, clang::Parser::ParsedAttributesWithRange
&) + 2404
28 clang     0x0000000000999441
clang::Parser::ParseStatementOrDeclaration(llvm::SmallVector<clang::Stmt*,
32u>&, bool, clang::SourceLocation*) + 145
29 clang     0x00000000009a0431 clang::Parser::ParseCompoundStatementBody(bool)
+ 1729
30 clang     0x00000000009a1c4b
clang::Parser::ParseFunctionStatementBody(clang::Decl*,
clang::Parser::ParseScope&) + 187
31 clang     0x000000000093db41
clang::Parser::ParseFunctionDefinition(clang::ParsingDeclarator&,
clang::Parser::ParsedTemplateInfo const&, clang::Parser::LateParsedAttrList*) +
2065
32 clang     0x000000000094c99d
clang::Parser::ParseDeclGroup(clang::ParsingDeclSpec&, unsigned int, bool,
clang::SourceLocation*, clang::Parser::ForRangeInit*) + 1373
33 clang     0x000000000093d1d8
clang::Parser::ParseDeclOrFunctionDefInternal(clang::Parser::ParsedAttributesWithRange&,
clang::ParsingDeclSpec&, clang::AccessSpecifier) + 664
34 clang     0x000000000093cc50
clang::Parser::ParseDeclarationOrFunctionDefinition(clang::Parser::ParsedAttributesWithRange&,
clang::ParsingDeclSpec*, clang::AccessSpecifier) + 416
35 clang     0x000000000093c1e0
clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&,
clang::ParsingDeclSpec*) + 2864
36 clang     0x000000000095d02a
clang::Parser::ParseInnerNamespace(std::vector<clang::SourceLocation,
std::allocator<clang::SourceLocation> >&, std::vector<clang::IdentifierInfo*,
std::allocator<clan
g::IdentifierInfo*> >&, std::vector<clang::SourceLocation,
std::allocator<clang::SourceLocation> >&, unsigned int, clang::SourceLocation&,
clang::ParsedAttributes&, clang::BalancedDelimiterTracker&) 
+ 474
37 clang     0x000000000095cbca clang::Parser::ParseNamespace(unsigned int,
clang::SourceLocation&, clang::SourceLocation) + 6026
38 clang     0x0000000000948d1f
clang::Parser::ParseDeclaration(llvm::SmallVector<clang::Stmt*, 32u>&, unsigned
int, clang::SourceLocation&, clang::Parser::ParsedAttributesWithRange&) + 415
39 clang     0x000000000093bd33
clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&,
clang::ParsingDeclSpec*) + 1667
40 clang     0x000000000093b630
clang::Parser::ParseTopLevelDecl(clang::OpaquePtr<clang::DeclGroupRef>&) + 304
41 clang     0x0000000000937d66 clang::ParseAST(clang::Sema&, bool, bool) + 454
42 clang     0x00000000007f4a12 clang::CodeGenAction::ExecuteAction() + 194
43 clang     0x0000000000688c61 clang::FrontendAction::Execute() + 113
44 clang     0x0000000000669cfd
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 909
45 clang     0x0000000000651ab7
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 2983
46 clang     0x00000000006487a5 cc1_main(char const**, char const**, char
const*, void*) + 693
47 clang     0x000000000064edeb main + 7035
48 libc.so.6 0x00007fa560e7f76d __libc_start_main + 237
49 clang     0x0000000000648429
Stack dump:
0.      Program arguments:
/src/chrome/src/third_party/llvm-build/Release+Asserts/bin/clang -cc1 -triple
x86_64-unknown-linux-gnu -emit-obj -mrelax-all -disable-free -main-file-name
video_frame_strea
m.cc -mrelocation-model pic -pic-level 2 -mdisable-fp-elim -relaxed-aliasing
-fmath-errno -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu
x86-64 -target-linker-version 2.20.1 -momit-l
eaf-frame-pointer -g -coverage-file
/src/chrome/src/out/Debug/obj/media/filters/media.video_frame_stream.o
-resource-dir
/src/chrome/src/third_party/llvm-build/Release+Asserts/bin/../lib/clang/3.3 -d
ependency-file obj/media/filters/media.video_frame_stream.o.d -MT
obj/media/filters/media.video_frame_stream.o -D _FILE_OFFSET_BITS=64 -D
USE_LINUX_BREAKPAD -D DISABLE_NACL -D CHROMIUM_BUILD -D COMPO
NENT_BUILD -D USE_DEFAULT_RENDER_THEME=1 -D USE_LIBJPEG_TURBO=1 -D USE_NSS=1 -D
ENABLE_ONE_CLICK_SIGNIN -D GTK_DISABLE_SINGLE_INCLUDES=1 -D ENABLE_REMOTING=1
-D ENABLE_WEBRTC=1 -D USE_PROPRIETARY_COD
ECS -D ENABLE_CONFIGURATION_POLICY -D ENABLE_INPUT_SPEECH -D
ENABLE_NOTIFICATIONS -D ENABLE_GPU=1 -D ENABLE_EGLIMAGE=1 -D
ENABLE_TASK_MANAGER=1 -D ENABLE_EXTENSIONS=1 -D ENABLE_PLUGIN_INSTALLATION=1 
-D ENABLE_PLUGINS=1 -D ENABLE_SESSION_SERVICE=1 -D ENABLE_THEMES=1 -D
ENABLE_BACKGROUND=1 -D ENABLE_AUTOMATION=1 -D ENABLE_GOOGLE_NOW=1 -D
ENABLE_LANGUAGE_DETECTION=1 -D ENABLE_PRINTING=1 -D ENABLE_C
APTIVE_PORTAL_DETECTION=1 -D ENABLE_MANAGED_USERS=1 -D MEDIA_IMPLEMENTATION -D
USE_NEON -D USE_PULSEAUDIO -D DLOPEN_PULSEAUDIO -D GURL_DLL -D
SK_BUILD_NO_IMAGE_ENCODE -D SK_DEFERRED_CANVAS_USES_GPIPE=1 -D
GR_GL_CUSTOM_SETUP_HEADER="GrGLConfig_chrome.h" -D GR_AGGRESSIVE_SHADER_OPTS=1
-D SK_ENABLE_INST_COUNT=0 -D SK_USE_POSIX_THREADS -D GR_DLL -D SKIA_DLL -D
U_USING_ICU_NAMESPACE=0 -D __STDC_CONST
ANT_MACROS -D __STDC_FORMAT_MACROS -D DYNAMIC_ANNOTATIONS_ENABLED=1 -D
WTF_USE_DYNAMIC_ANNOTATIONS=1 -D _DEBUG -D _REENTRANT -I
../../third_party/icu/public/common -I ../../third_party/icu/public/i18
n -I ../.. -I gen/pulse -I ../../net/third_party/nss/ssl -I ../../skia/config
-I ../../third_party/skia/src/core -I ../../third_party/skia/include/config -I
../../third_party/skia/include/core -I ../
../third_party/skia/include/effects -I ../../third_party/skia/include/pdf -I
../../third_party/skia/include/gpu -I ../../third_party/skia/include/gpu/gl -I
../../third_party/skia/include/pipe -I ../.
./third_party/skia/include/ports -I ../../third_party/skia/include/utils -I
../../skia/ext -I ../../third_party/opus/src/include -I gen/ffmpeg -I
../../third_party/ffmpeg/chromium/config/ChromeOS/lin
ux/x64 -I ../../third_party/ffmpeg -I ../../third_party/libvpx/source/libvpx -I
/usr/include/glib-2.0 -I /usr/lib/x86_64-linux-gnu/glib-2.0/include -I
/usr/include/nss -I /usr/include/nspr -I /usr/in
clude/glib-2.0 -I /usr/lib/x86_64-linux-gnu/glib-2.0/include -I
/usr/include/gtk-2.0 -I /usr/lib/x86_64-linux-gnu/gtk-2.0/include -I
/usr/include/atk-1.0 -I /usr/include/cairo -I /usr/include/gdk-pix
buf-2.0 -I /usr/include/pango-1.0 -I /usr/include/gio-unix-2.0/ -I
/usr/include/pixman-1 -I /usr/include/freetype2 -I /usr/include/libpng12
-internal-isystem /usr/lib/gcc/x86_64-linux-gnu/4.6/../../.
./../include/c++/4.6 -internal-isystem
/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../include/c++/4.6/x86_64-linux-gnu
-internal-isystem
/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../include/c++/4.6/b
ackward -internal-isystem /usr/local/include -internal-isystem
/src/chrome/src/third_party/llvm-build/Release+Asserts/bin/../lib/clang/3.3/include
-internal-externc-isystem /usr/include/x86_64-linux-
gnu -internal-externc-isystem /include -internal-externc-isystem /usr/include
-O0 -Werror -Wall -Wno-unused-parameter -Wno-missing-field-initializers
-Wheader-hygiene -Wno-unused-function -Wno-char-s
ubscripts -Wno-unnamed-type-template-args -Wno-c++11-extensions
-Wno-covered-switch-default -Wstring-conversion -Wsign-compare
-fdeprecated-macro -fdebug-compilation-dir /src/chrome/src/out/Debug -fe
rror-limit 19 -fmessage-length 0 -fvisibility hidden
-fvisibility-inlines-hidden -pthread -stack-protector 1
-stack-protector-buffer-size 4 -mstackrealign -fno-rtti -fno-threadsafe-statics
-fobjc-run
time=gcc -fdiagnostics-show-option -fcolor-diagnostics -backend-option
-vectorize-loops -load
/src/chrome/src/tools/clang/scripts/../../../third_party/llvm-build/Release+Asserts/lib/libFindBadConstru
cts.so -add-plugin find-bad-constructs -plugin-arg-find-bad-constructs
skip-virtuals-in-implementations -o
obj/media/filters/media.video_frame_stream.o -x c++
../../media/filters/video_frame_stream.c
c 
1.      ../../media/filters/video_frame_stream.cc:60:50: current parser token
')'
2.      ../../media/filters/video_frame_stream.cc:18:1: parsing namespace
'media'
3.      ../../media/filters/video_frame_stream.cc:36:58: parsing function body
'Initialize'
4.      ../../media/filters/video_frame_stream.cc:36:58: in compound statement
('{}')
clang: error: unable to execute command: Aborted (core dumped)
clang: error: clang frontend command failed due to signal (use -v to see
invocation)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130404/c151a5ae/attachment.html>

From bugzilla-daemon at llvm.org  Wed Apr  3 23:08:41 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 04 Apr 2013 06:08:41 +0000
Subject: [LLVMbugs] [Bug 15666] New: clang does not know Red Hat Linux ARM
 triplets armv7hl-redhat-linux and armv5tel-redhat-linux
Message-ID: <bug-15666-206@http.llvm.org/bugs/>

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

            Bug ID: 15666
           Summary: clang does not know Red Hat Linux ARM triplets
                    armv7hl-redhat-linux and armv5tel-redhat-linux
           Product: clang
           Version: 3.2
          Hardware: Other
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Driver
          Assignee: unassignedclangbugs at nondot.org
          Reporter: petersen at redhat.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Clang on Fedora ARM does not work well because clang does not
recognize the Fedora ARM triplets and fallback to software floating point,
causing build failures like this:

clang: warning: unknown platform, assuming -mfloat-abi=soft
In file included from In file included from fsck_messages.c:25:
In file included from /usr/include/assert.hIn file included from :36cache.c:
:In file included from /usr/include/features.h24::
399In file included from :
/usr/include/errno.h:28/usr/include/gnu/stubs.h:
In file included from :/usr/include/features.h7::39911:
: fatal error: /usr/include/gnu/stubs.h'gnu/stubs-soft.h' file not found:
7:11: fatal error: 'gnu/stubs-soft.h' file not found
# include <gnu/stubs-soft.h># include <gnu/stubs-soft.h>
:

See this Fedora ARM bug:
https://bugzilla.redhat.com/show_bug.cgi?id=803433

Earlier I tried a simple naive patch like:

--- llvm-3.2.src/tools/clang/lib/Driver/ToolChains.cpp~    2012-12-17
00:59:27.000000000 +0900
+++ llvm-3.2.src/tools/clang/lib/Driver/ToolChains.cpp    2013-02-12
19:18:00.755164292 +0900
@@ -1054,10 +1054,12 @@
   static const char *const ARMLibDirs[] = { "/lib" };
   static const char *const ARMTriples[] = {
     "arm-linux-gnueabi",
-    "arm-linux-androideabi"
+    "arm-linux-androideabi",
+    "armv5tel-redhat-linux",
   };
   static const char *const ARMHFTriples[] = {
     "arm-linux-gnueabihf",
+    "armv7hl-redhat-linux",
   };

but it was not sufficient - maybe fixes are also needed to on the llvm side,
perhaps?

(Similarly ppc64-redhat-linux is also not supported.)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130404/ec75c32e/attachment.html>

From bugzilla-daemon at llvm.org  Thu Apr  4 07:17:59 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 04 Apr 2013 14:17:59 +0000
Subject: [LLVMbugs] [Bug 15667] New: crash in search_n
Message-ID: <bug-15667-206@http.llvm.org/bugs/>

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

            Bug ID: 15667
           Summary: crash in search_n
           Product: libc++
           Version: unspecified
          Hardware: Macintosh
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: All Bugs
          Assignee: hhinnant at apple.com
          Reporter: dlorenz at mac.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

See
http://stackoverflow.com/questions/15809929/is-this-crash-in-libc-stdsearch-n-a-bug

This code crashes in Xcode 4.6.1:
int main(int argc, char *argv[])
{
  // Crashes
  std::vector<uint8_t> bs{1, 0, 0};
  std::search_n(bs.begin(), bs.end(), 3, 1);

  // Does not crash
  std::vector<uint8_t> bs{1, 0};
  std::search_n(bs.begin(), bs.end(), 2, 1);

  return 0;
}

The problem lies in __search_n, when a partial match is made, __first will be
beyond __s and the check for equality will fail, so there is no early exit;
eventually it will crash.

if (__first == __s)  // return __last if no element matches __value_

needs to be replaced by

if (__first >= __s)  // return __last if no element matches __value_

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130404/867279b3/attachment.html>

From bugzilla-daemon at llvm.org  Thu Apr  4 08:42:40 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 04 Apr 2013 15:42:40 +0000
Subject: [LLVMbugs] [Bug 15667] crash in search_n
In-Reply-To: <bug-15667-206@http.llvm.org/bugs/>
References: <bug-15667-206@http.llvm.org/bugs/>
Message-ID: <bug-15667-206-te3mLssdc2@http.llvm.org/bugs/>

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

Howard Hinnant <hhinnant at apple.com> changed:

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

--- Comment #1 from Howard Hinnant <hhinnant at apple.com> ---
Agreed, thanks for the fix.  Committed revision 178764.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130404/137eb53d/attachment.html>

From bugzilla-daemon at llvm.org  Thu Apr  4 09:38:49 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 04 Apr 2013 16:38:49 +0000
Subject: [LLVMbugs] [Bug 15668] New: static, extern,
 static function is rejected incorrectly
Message-ID: <bug-15668-206@http.llvm.org/bugs/>

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

            Bug ID: 15668
           Summary: static, extern, static function is rejected
                    incorrectly
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: bruce.r.stephens at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

This is presumably 3645, again (though with a function).

static void a(void);
extern void a();
static void a(void) {}

is rejected by clang, but not by gcc (and other compilers). The code appears to
be valid (the function is static).

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130404/fc3b7f18/attachment.html>

From bugzilla-daemon at llvm.org  Thu Apr  4 10:00:01 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 04 Apr 2013 17:00:01 +0000
Subject: [LLVMbugs] [Bug 15669] New: Enable JIT/MCJIT unit tests for targets
 with JIT support.
Message-ID: <bug-15669-206@http.llvm.org/bugs/>

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

            Bug ID: 15669
           Summary: Enable JIT/MCJIT unit tests for targets with JIT
                    support.
           Product: Test Suite
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: lit
          Assignee: unassignedbugs at nondot.org
          Reporter: jverma at codeaurora.org
                CC: daniel at zuster.org, llvmbugs at cs.uiuc.edu
    Classification: Unclassified

This patch http://llvm.org/viewvc/llvm-project?view=revision&revision=178221
intended to disable MCJIT/JIT unittests only for the targets without JIT
support. However, it accidentally disabled them for all the targets when using
make.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130404/a90fefd7/attachment.html>

From bugzilla-daemon at llvm.org  Thu Apr  4 10:41:50 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 04 Apr 2013 17:41:50 +0000
Subject: [LLVMbugs] [Bug 15668] static, extern,
	static function is rejected incorrectly
In-Reply-To: <bug-15668-206@http.llvm.org/bugs/>
References: <bug-15668-206@http.llvm.org/bugs/>
Message-ID: <bug-15668-206-B6pVA67Bw0@http.llvm.org/bugs/>

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

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

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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130404/4c548ebe/attachment.html>

From bugzilla-daemon at llvm.org  Thu Apr  4 10:49:09 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 04 Apr 2013 17:49:09 +0000
Subject: [LLVMbugs] [Bug 15672] New: Since r177724: AddressSanitizer CHECK
 failed: llvm/projects/compiler-rt/lib/asan/asan_fake_stack.cc:46
 "((alloc_size > (1UL << (log-1)))) != (0)" (0x0, 0x0)
Message-ID: <bug-15672-206@http.llvm.org/bugs/>

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

            Bug ID: 15672
           Summary: Since r177724: AddressSanitizer CHECK failed:
                    llvm/projects/compiler-rt/lib/asan/asan_fake_stack.cc:
                    46 "((alloc_size > (1UL << (log-1)))) != (0)" (0x0,
                    0x0)
           Product: compiler-rt
           Version: unspecified
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: compiler-rt
          Assignee: unassignedbugs at nondot.org
          Reporter: emikulic at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 10287
  --> http://llvm.org/bugs/attachment.cgi?id=10287&action=edit
Test case that triggers AddressSanitizer CHECK-fail

Working:

$ clang++ -v
clang version 3.3 (trunk 177722)
Target: x86_64-unknown-linux-gnu
Thread model: posix
$ clang++ -g -fsanitize=address-full test2.cpp && ./a.out; echo $?
0

Not working:

$ clang++ -v
clang version 3.3 (trunk 177724)
Target: x86_64-unknown-linux-gnu
Thread model: posix
$ clang++ -g -fsanitize=address-full test2.cpp
$ ASAN_OPTIONS=abort_on_error=1 gdb a.out 
GNU gdb (GDB) 7.4.1-debian
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /tmp/a.out...done.
(gdb) run
Starting program: /tmp/a.out 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
alloc_size 1 log 0
==20275==AddressSanitizer CHECK failed:
/home/emil/llvm/llvm/projects/compiler-rt/lib/asan/asan_fake_stack.cc:46
"((alloc_size > (1UL << (log-1)))) != (0)" (0x0, 0x0)
    #0 0x41ffcf (/tmp/a.out+0x41ffcf)
    #1 0x4217d1 (/tmp/a.out+0x4217d1)
    #2 0x41377b (/tmp/a.out+0x41377b)
    #3 0x41339a (/tmp/a.out+0x41339a)
    #4 0x4132f2 (/tmp/a.out+0x4132f2)
    #5 0x429395 (/tmp/a.out+0x429395)
    #6 0x428f09 (/tmp/a.out+0x428f09)
    #7 0x428b4d (/tmp/a.out+0x428b4d)
    #8 0x7ffff6eb2eac (/lib/x86_64-linux-gnu/libc-2.13.so+0x1eeac)
    #9 0x4289dc (/tmp/a.out+0x4289dc)

Program received signal SIGABRT, Aborted.
0x00007ffff6ec6475 in *__GI_raise (sig=<optimized out>) at
../nptl/sysdeps/unix/sysv/linux/raise.c:64
64    ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  0x00007ffff6ec6475 in *__GI_raise (sig=<optimized out>)
    at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1  0x00007ffff6ec96f0 in *__GI_abort () at abort.c:92
#2  0x00000000004249f6 in __sanitizer::Abort() ()
#3  0x000000000041ff98 in __asan::AsanDie() ()
#4  0x000000000042177f in __sanitizer::Die() ()
#5  0x000000000041ffff in __asan::AsanCheckFailed(char const*, int, char
const*, unsigned long long, unsigned long long) ()
#6  0x00000000004217d2 in __sanitizer::CheckFailed(char const*, int, char
const*, unsigned long long, unsigned long long) ()
#7  0x000000000041377c in __asan::FakeStack::ComputeSizeClass(unsigned long) ()
#8  0x000000000041339b in
__asan::FakeStack::DeallocateFrame(__asan::FakeFrame*) ()
#9  0x00000000004132f3 in __asan::FakeStack::AllocateStack(unsigned long,
unsigned long) ()
#10 0x0000000000429396 in c::c (
    this=<error reading variable: DWARF-2 expression error: DW_OP_reg
operations must be used either alone or in conjunction with DW_OP_piece or
DW_OP_bit_piece.>) at test2.cpp:27
#11 0x0000000000428f0a in a::b (this=0x7ffff438e020) at test2.cpp:33
#12 0x0000000000428b4e in main () at test2.cpp:38
(gdb)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130404/fcd0869b/attachment.html>

From bugzilla-daemon at llvm.org  Thu Apr  4 10:51:15 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 04 Apr 2013 17:51:15 +0000
Subject: [LLVMbugs] [Bug 15673] New: poor diagnostic for deduction failure
 in default template argument
Message-ID: <bug-15673-206@http.llvm.org/bugs/>

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

            Bug ID: 15673
           Summary: poor diagnostic for deduction failure in default
                    template argument
           Product: clang
           Version: trunk
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++11
          Assignee: unassignedclangbugs at nondot.org
          Reporter: zilla at kayari.org
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified

The change made by
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20120507/057436.html
is excellent, but only seems to work for old fashioned uses of enable_if, in
return types or function parameters.

My preferred style is to de-clutter the function declaration by using enable_if
in a template parameter with a default template argument e.g.

#include <type_traits>

template<typename T>
struct a_trait : std::false_type { };

template<typename T,
         typename Requires = typename std::enable_if<a_trait<T>::value>::type>
void foo() { }

int main()
{
    foo<int>();
}

Clang is not very helpful here:

b.cc:12:5: error: no matching function for call to 'foo'
    foo<int>();
    ^~~~~~~~
b.cc:8:6: note: candidate template ignored: couldn't infer template argument
'Requires'
void foo() { }
     ^


In an ideal world it would even recognise this is an equivalent use of 
enable_if

#include <type_traits>

template<typename T>
struct some_trait : std::false_type { };

template<typename T>
struct a_pony
: std::enable_if<some_trait<T>::value>
{ };

template<typename T,
         typename Requires = typename a_pony<T>::type>
void foo() { }

int main()
{
    foo<int>();
}

And also recognise my preferred form of using enable_if constraints via alias
templates:

#include <type_traits>

template<typename T>
struct some_trait : std::false_type { };

template<typename T>
    using unicorns
        = typename std::enable_if<some_trait<T>::value>::type;

template<typename T,
         typename Requires = unicorns<T>>
void foo() { }

int main()
{
    foo<int>();
}

(unicorns might be simpler than a_pony since there's no other type involved,
just an alias for enable_if)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130404/68e2f766/attachment.html>

From bugzilla-daemon at llvm.org  Thu Apr  4 11:59:09 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 04 Apr 2013 18:59:09 +0000
Subject: [LLVMbugs] [Bug 14330] Clang does not pass the GDB 7.5 test suite
In-Reply-To: <bug-14330-206@http.llvm.org/bugs/>
References: <bug-14330-206@http.llvm.org/bugs/>
Message-ID: <bug-14330-206-7hq6dX5hbg@http.llvm.org/bugs/>

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

Bug 14330 depends on bug 14332, which changed state.

Bug 14332 Summary: Implement -fsplit-stack
http://llvm.org/bugs/show_bug.cgi?id=14332

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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130404/42b9373d/attachment.html>

From bugzilla-daemon at llvm.org  Thu Apr  4 11:59:08 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 04 Apr 2013 18:59:08 +0000
Subject: [LLVMbugs] [Bug 14332] Implement -fsplit-stack
In-Reply-To: <bug-14332-206@http.llvm.org/bugs/>
References: <bug-14332-206@http.llvm.org/bugs/>
Message-ID: <bug-14332-206-LbLw62Asja@http.llvm.org/bugs/>

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

Eric Christopher <echristo at gmail.com> changed:

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

--- Comment #3 from Eric Christopher <echristo at gmail.com> ---
It's wired up now and seems to work based on:

(gdb) b main
Breakpoint 1 at 0x400c20: file morestack.c, line 89.
(gdb) run
Starting program: /usr/local/google/home/echristo/tmp/a.out 

Breakpoint 1, main () at morestack.c:89
89    {
(gdb) b marker_hit
Breakpoint 2 at 0x400e10: file morestack.c, line 47.
(gdb) break marker_miss
Breakpoint 3 at 0x400e90: file morestack.c, line 41.
(gdb) c
Continuing.
499: 0x7ffff64218d0 < 0x7ffff78028d0

Breakpoint 2, marker_hit () at morestack.c:47
47    {
(gdb) up 3000
#1004 0x0000000000400ce4 in main () at morestack.c:103
103      down (1000);

the bot appears to be skipping the test so I can't verify it via the testsuite,
but it seems to work for me. Going to mark it as resolved for now.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130404/0ff8014c/attachment.html>

From bugzilla-daemon at llvm.org  Thu Apr  4 13:48:16 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 04 Apr 2013 20:48:16 +0000
Subject: [LLVMbugs] [Bug 8869] False positive with static analyzer and
 struct initialization through a temporary.
In-Reply-To: <bug-8869-206@http.llvm.org/bugs/>
References: <bug-8869-206@http.llvm.org/bugs/>
Message-ID: <bug-8869-206-9kOOrPyUVg@http.llvm.org/bugs/>

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

Juli Mallett <juli at clockworksquid.com> changed:

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

--- Comment #2 from Juli Mallett <juli at clockworksquid.com> ---
This no longer seems to be broken with trunk; verified with r171214.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130404/d6c335c4/attachment.html>

From bugzilla-daemon at llvm.org  Thu Apr  4 14:08:04 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 04 Apr 2013 21:08:04 +0000
Subject: [LLVMbugs] [Bug 15674] New: Broken switch when compiling with
	optimizations
Message-ID: <bug-15674-206@http.llvm.org/bugs/>

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

            Bug ID: 15674
           Summary: Broken switch when compiling with optimizations
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: release blocker
          Priority: P
         Component: LLVM Codegen
          Assignee: unassignedclangbugs at nondot.org
          Reporter: llvm.org at halfy.net
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 10288
  --> http://llvm.org/bugs/attachment.cgi?id=10288&action=edit
Bug with switch statements.

The attached test case is extracted from a much larger production code. When
compiled and run, the expected output is:

> ./t
> 1 1 1 1

However, if built with any -O level above zero, it outputs:

> ./t
> 1 0 0 0

It seems that the ::memcpy() is confusing the optimizer. I'm not sure at what
stage this happens, so logging against clang.

I can work around this by rewriting the code like below, but this seems like a
rather critical bug.

---- 8< ----
void quantize(char *data, float *src, int nb_src, int vsize)
{
    unsigned char     *i8 = (unsigned char *)data;

    switch(vsize)
    {
    case 4: i8[3] = (unsigned char)src[3];
    case 3: i8[2] = (unsigned char)src[2];
        i8[1] = (unsigned char)src[1];
    case 1: i8[0] = (unsigned char)src[0];
    }
}
---- 8< ----

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130404/294809d7/attachment.html>

From bugzilla-daemon at llvm.org  Thu Apr  4 14:16:50 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 04 Apr 2013 21:16:50 +0000
Subject: [LLVMbugs] [Bug 15675] New: Empty macro arguments cause whitespace
 to go missing
Message-ID: <bug-15675-206@http.llvm.org/bugs/>

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

            Bug ID: 15675
           Summary: Empty macro arguments cause whitespace to go missing
           Product: clang
           Version: 3.2
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: harald at gigawatt.nl
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

#define A()
#define B(x)x
#define C(x) x
#define STR(x) STR_(x)
#define STR_(x) #x
STR([ A()])
STR([ B()])
STR([ C()])

is preprocessed to

"[ ]"
"[]"
"[]"

It should be "[ ]" for all three lines, which is what gcc and mcpp do.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130404/3e065f46/attachment.html>

From bugzilla-daemon at llvm.org  Thu Apr  4 14:26:39 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 04 Apr 2013 21:26:39 +0000
Subject: [LLVMbugs] [Bug 15676] New: clang segfaults when cross compiling
 arch/arm/mm/context.c for ARM
Message-ID: <bug-15676-206@http.llvm.org/bugs/>

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

            Bug ID: 15676
           Summary: clang segfaults when cross compiling
                    arch/arm/mm/context.c for ARM
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: LLVM Codegen
          Assignee: unassignedclangbugs at nondot.org
          Reporter: behanw at converseincode.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 10289
  --> http://llvm.org/bugs/attachment.cgi?id=10289&action=edit
Code, backtrace, etc

When cross compiling the Linux kernel for ARM, clang segfaults when compiling
arch/arm/mm/context.c

Code to reproduce in attachment.

/home/behanw/src/kernel/llvmlinux/toolchain/clang/install/bin/clang
-gcc-toolchain
/home/behanw/src/kernel/llvmlinux/arch/arm/toolchain/codesourcery/arm-2011.03/bin
-target arm-linux-gnueabi -include ./include/kconfig.h -D __KERNEL__ -D
__LINUX_ARM_ARCH__=7 -I ./include -O2 -Wall -Wundef -Wstrict-prototypes
-Wno-trigraphs -Werror-implicit-function-declaration -Wno-format-security
-Wno-asm-operand-widths -Wno-unused-variable -Wno-tautological-compare
-Wdeclaration-after-statement -Wno-pointer-sign -fno-dwarf2-cfi-asm
-fno-dwarf-directory-asm -fdebug-compilation-dir -fwrapv -mstackrealign
-fno-builtin -fobjc-runtime=gcc -fno-common -fdiagnostics-show-option
-fcolor-diagnostics -c -o context.o context-parsed.c -static
clang-3.3: warning: argument unused during compilation:
'-fdebug-compilation-dir -fwrapv' [-Wunused-command-line-argument]
0  clang-3.3       0x0000000001150712 llvm::sys::PrintStackTrace(_IO_FILE*) +
34
1  clang-3.3       0x0000000001150399
2  libpthread.so.0 0x00002aaaaaee3cb0
3  clang-3.3       0x0000000000b2bcea
llvm::ARMInstPrinter::getRegisterName(unsigned int) + 10
4  clang-3.3       0x0000000000b2bd50
llvm::ARMInstPrinter::printRegName(llvm::raw_ostream&, unsigned int) const + 80
5  clang-3.3       0x0000000000b2f58c
llvm::ARMInstPrinter::printRegisterList(llvm::MCInst const*, unsigned int,
llvm::raw_ostream&) + 124
6  clang-3.3       0x0000000000b35e76
llvm::ARMInstPrinter::printInstruction(llvm::MCInst const*, llvm::raw_ostream&)
+ 7670
7  clang-3.3       0x0000000000b37501
llvm::ARMInstPrinter::printInst(llvm::MCInst const*, llvm::raw_ostream&,
llvm::StringRef) + 369
8  clang-3.3       0x00000000010aa89f
9  clang-3.3       0x00000000006ed187
10 clang-3.3       0x0000000000998a15 llvm::AsmPrinter::EmitFunctionBody() +
293
11 clang-3.3       0x00000000006e6f2f
12 clang-3.3       0x0000000001073bdf
llvm::FPPassManager::runOnFunction(llvm::Function&) + 607
13 clang-3.3       0x0000000001073c1b
llvm::FPPassManager::runOnModule(llvm::Module&) + 43
14 clang-3.3       0x00000000010737af
llvm::MPPassManager::runOnModule(llvm::Module&) + 575
15 clang-3.3       0x00000000010738fc llvm::PassManagerImpl::run(llvm::Module&)
+ 188
16 clang-3.3       0x00000000011729d4
clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::CodeGenOptions
const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::Module*,
clang::BackendAction, llvm::raw_ostream*) + 3604
17 clang-3.3       0x00000000011700e2
18 clang-3.3       0x00000000013f9d2a clang::ParseAST(clang::Sema&, bool, bool)
+ 538
19 clang-3.3       0x0000000001349969 clang::FrontendAction::Execute() + 185
20 clang-3.3       0x000000000132bdf5
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 293
21 clang-3.3       0x000000000115309a
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1514
22 clang-3.3       0x00000000006d4e78 cc1_main(char const**, char const**, char
const*, void*) + 920
23 clang-3.3       0x00000000006c42c5 main + 8133
24 libc.so.6       0x00002aaaab92776d __libc_start_main + 237
25 clang-3.3       0x00000000006d2be5
Stack dump:
0.    Program arguments:
/home/behanw/src/kernel/llvmlinux/toolchain/clang/install/bin/clang-3.3 -cc1
-triple armv4t--linux-gnueabi -S -disable-free -disable-llvm-verifier
-main-file-name context-parsed.c -static-define -mrelocation-model static
-mdisable-fp-elim -fmath-errno -mconstructor-aliases -target-abi aapcs-linux
-target-cpu arm7tdmi -mfloat-abi soft -target-feature +soft-float-abi
-coverage-file
/home/behanw/src/kernel/llvmlinux/targets/vexpress/tmp/context-parsed-60H0nV.s
-resource-dir
/home/behanw/src/kernel/llvmlinux/toolchain/clang/install/bin/../lib/clang/3.3
-include ./include/kconfig.h -D __KERNEL__ -D __LINUX_ARM_ARCH__=7 -I ./include
-internal-isystem /usr/local/include -internal-isystem
/home/behanw/src/kernel/llvmlinux/toolchain/clang/install/bin/../lib/clang/3.3/include
-internal-externc-isystem /include -internal-externc-isystem /usr/include -O2
-Wall -Wundef -Wstrict-prototypes -Wno-trigraphs
-Werror-implicit-function-declaration -Wno-format-security
-Wno-asm-operand-widths -Wno-unused-variable -Wno-tautological-compare
-Wdeclaration-after-statement -Wno-pointer-sign -fno-dwarf2-cfi-asm
-fno-dwarf-directory-asm -fdebug-compilation-dir
/home/behanw/src/kernel/llvmlinux/test/unit/ARM64bit -ferror-limit 19
-fmessage-length 0 -backend-option -force-align-stack -mstackrealign
-fno-builtin -fno-signed-char -fobjc-runtime=gcc
-fobjc-default-synthesize-properties -fno-common -fdiagnostics-show-option
-fcolor-diagnostics -backend-option -vectorize-loops -o
/home/behanw/src/kernel/llvmlinux/targets/vexpress/tmp/context-parsed-60H0nV.s
-x c context-parsed.c 
1.    <eof> parser at end of file
2.    Code generation
3.    Running pass 'Function Pass Manager' on module 'context-parsed.c'.
4.    Running pass 'ARM Assembly / Object Emitter' on function
'@check_and_switch_context'
clang-3.3: error: unable to execute command: Segmentation
fault (core dumped)
clang-3.3: error: clang frontend command failed due to signal
(use -v to see invocation)
clang version 3.3 
Target: arm--linux-gnueabi
Thread model: posix
clang-3.3: note: diagnostic msg: PLEASE submit a bug report to 
and include the crash backtrace, preprocessed source, and associated run
script.
clang-3.3: note: diagnostic msg: 
********************

PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang-3.3: note: diagnostic msg:
/home/behanw/src/kernel/llvmlinux/targets/vexpress/tmp/context-parsed-GdtCr3.c
clang-3.3: note: diagnostic msg:
/home/behanw/src/kernel/llvmlinux/targets/vexpress/tmp/context-parsed-GdtCr3.sh
clang-3.3: note: diagnostic msg: 

********************
make: *** [testcase] Error 254

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130404/2da7913d/attachment.html>

From bugzilla-daemon at llvm.org  Thu Apr  4 14:31:23 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 04 Apr 2013 21:31:23 +0000
Subject: [LLVMbugs] [Bug 15677] New: Some invalid code causes a crash
Message-ID: <bug-15677-206@http.llvm.org/bugs/>

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

            Bug ID: 15677
           Summary: Some invalid code causes a crash
           Product: clang
           Version: 3.2
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++11
          Assignee: unassignedclangbugs at nondot.org
          Reporter: nacitar at ubercpp.com
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 10290
  --> http://llvm.org/bugs/attachment.cgi?id=10290&action=edit
Core file, preprocessed cpp and run script.

The error here is I redeclared RetEnableIf (meant to name the second one
RetDisableIf)... just playing around with some template stuff.  Anyway, here's
the crash information.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130404/b2f7c5df/attachment.html>

From bugzilla-daemon at llvm.org  Thu Apr  4 14:46:57 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 04 Apr 2013 21:46:57 +0000
Subject: [LLVMbugs] [Bug 15678] New: -Wformat-nonliteral is inconsistent
Message-ID: <bug-15678-206@http.llvm.org/bugs/>

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

            Bug ID: 15678
           Summary: -Wformat-nonliteral is inconsistent
           Product: clang
           Version: unspecified
          Hardware: Macintosh
                OS: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
          Assignee: unassignedclangbugs at nondot.org
          Reporter: bjhomer+llvm at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

The following code generates a warning under -Wformat-nonliteral:

  NSString *template = NSLocalizedString(@"My name is %@", nil);
  NSString *str = [NSString stringWithFormat:template, @"John"];

However, the following code does not:

  NSString *str = [NSString stringWithFormat:NSLocalizedString(@"My name is
%@", nil), @"John"];

Note that in neither case is the parameter actually a string literal; the
return value of NSLocalizedString() is determined at runtime in either case.

I suspect that it should really warn in both cases, though that means I'll
probably have to turn off this warning for my project.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130404/a5cdc444/attachment.html>

From bugzilla-daemon at llvm.org  Thu Apr  4 16:05:15 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 04 Apr 2013 23:05:15 +0000
Subject: [LLVMbugs] [Bug 15679] New: static analyser reports null
 dereference when it clearly cannot happen
Message-ID: <bug-15679-206@http.llvm.org/bugs/>

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

            Bug ID: 15679
           Summary: static analyser reports null dereference when it
                    clearly cannot happen
           Product: clang
           Version: unspecified
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Static Analyzer
          Assignee: kremenek at apple.com
          Reporter: gryzman at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 10291
  --> http://llvm.org/bugs/attachment.cgi?id=10291&action=edit
formatting.c from postgresql project

checker-272 on mac

fe-lobj.c from postgresql got flagged (attaching the result file and source
file). 
But it clearly is visible in the same source file, that the condition could
never work out ! Clearly clang is unable to figure it out, and throws in loads
of false positives. 

In short this looks like so:


void some_funct(struct f *foo)
{
  if (foo==null || foo->bar==0)
  {

    if (initialise_f(foo) < 0)
      return;
  }

  // this gets flagged as dereference of null pointer if foo is null
  do_something(foo->bar);
}


int initialise_f(struct f* foo)
{
  if (!foo)
  {
    return -1'
  }

// ....
}




so in the example above (and attached code, look at function lo_tell64 and
lo_initialise) - this condition (dereference of null pointer) cannot happen.
Yet clang insists it does. After dozens of reports like that - and wasted time
on my pard - I decided to bug it here.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130404/eb2eaed6/attachment.html>

From bugzilla-daemon at llvm.org  Thu Apr  4 16:55:31 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 04 Apr 2013 23:55:31 +0000
Subject: [LLVMbugs] [Bug 11174] #define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_
In-Reply-To: <bug-11174-206@http.llvm.org/bugs/>
References: <bug-11174-206@http.llvm.org/bugs/>
Message-ID: <bug-11174-206-oGXAAgta3B@http.llvm.org/bugs/>

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

Michael Spencer <bigcheesegs at gmail.com> changed:

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

--- Comment #6 from Michael Spencer <bigcheesegs at gmail.com> ---
Fixed in r178816 for x86.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130404/10d4f180/attachment.html>

From bugzilla-daemon at llvm.org  Thu Apr  4 16:56:03 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 04 Apr 2013 23:56:03 +0000
Subject: [LLVMbugs] [Bug 12730] libstdc++ std::thread,
 when compiled with clang, "pure virtual method called"
In-Reply-To: <bug-12730-206@http.llvm.org/bugs/>
References: <bug-12730-206@http.llvm.org/bugs/>
Message-ID: <bug-12730-206-agDfNbvTgx@http.llvm.org/bugs/>

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

Michael Spencer <bigcheesegs at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
                 CC|                            |bigcheesegs at gmail.com
         Resolution|---                         |FIXED

--- Comment #12 from Michael Spencer <bigcheesegs at gmail.com> ---
Fixed in r178816.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130404/2f8e6520/attachment.html>

From bugzilla-daemon at llvm.org  Thu Apr  4 18:05:36 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 05 Apr 2013 01:05:36 +0000
Subject: [LLVMbugs] [Bug 15680] New: Clang does not find identifiers
 imported into namespaces by "using namespace"
Message-ID: <bug-15680-206@http.llvm.org/bugs/>

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

            Bug ID: 15680
           Summary: Clang does not find identifiers imported into
                    namespaces by "using namespace"
           Product: clang
           Version: trunk
          Hardware: PC
                OS: FreeBSD
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: M8R-9yw8a5 at mailinator.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

1. Source code (x.cpp):

namespace A { void f() { } }
namespace B { using namespace A; void g(); }
void B::g() { f(); }

2. Command line:

clang++ -c x.cpp

3. Output:

error: use of undeclared identifier 'f'; did you mean 'f'?

4. Notes:

This FEATURE(TM) was introduced somewhere in the revision range
(177716..178453] (at r177716, Clang compiles the code).

This is either a bug or a standard-conformant behavior change, but in the
latter case, diagnostics messages should be more explanatory: the compiler
should direct the user to 'A::f()'.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130405/f25903c9/attachment.html>

From bugzilla-daemon at llvm.org  Thu Apr  4 18:53:33 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 05 Apr 2013 01:53:33 +0000
Subject: [LLVMbugs] [Bug 15681] New: clangg++ error building Chromium on
	Linux
Message-ID: <bug-15681-206@http.llvm.org/bugs/>

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

            Bug ID: 15681
           Summary: clangg++ error building Chromium on Linux
           Product: clang
           Version: 3.2
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: johnb316 at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 10292
  --> http://llvm.org/bugs/attachment.cgi?id=10292&action=edit
Preprocessed source code to build abort.o

I tried to build Chromium 26.0.1410.43 from source on 64-bit Slackware Linux
using clang as the C++ compiler. After the Chromium build script downloaded a
prebuilt clang, the following errors were thrown as the build started:

http://llvm.org/bugs/  CXX(target)
out/Release/obj.target/allocator/third_party/tcmalloc/chromium/src/base/abort.o
  CXX(target)
out/Release/obj.target/allocator/third_party/tcmalloc/chromium/src/base/elf_mem_image.o
clang: warning: argument unused during compilation: '-fno-ipa-cp'
clang: warning: argument unused during compilation: '-fno-ipa-cp'
/usr/bin/clang: symbol lookup error:
/tmp/buildpkgs/chromium/chromium-26.0.1410.43/tools/clang/scripts/../../../third_party/llvm-build/Release+Asserts/lib/libFindBadConstructs.so:
undefined symbol:
_ZNK5clang13SourceManager14getPresumedLocENS_14SourceLocationEb
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 version 3.2 (tags/RELEASE_32/final)
Target: x86_64-slackware-linux-gnu
Thread model: posix
clang: note: diagnostic msg: PLEASE submit a bug report to
http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and
associated run script.
/usr/bin/clang: symbol lookup error:
/tmp/buildpkgs/chromium/chromium-26.0.1410.43/tools/clang/scripts/../../../third_party/llvm-build/Release+Asserts/lib/libFindBadConstructs.so:
undefined symbol:
_ZNK5clang13SourceManager14getPresumedLocENS_14SourceLocationEb
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 version 3.2 (tags/RELEASE_32/final)
Target: x86_64-slackware-linux-gnu
Thread model: posix
clang: note: diagnostic msg: PLEASE submit a bug report to
http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and
associated run script.
clang: note: diagnostic msg: 
********************

PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang: note: diagnostic msg: /tmp/abort-t94ibA.cpp
clang: note: diagnostic msg: /tmp/abort-t94ibA.sh
clang: note: diagnostic msg: 

********************
make: ***
[out/Release/obj.target/allocator/third_party/tcmalloc/chromium/src/base/abort.o]
Error 255
make: *** Waiting for unfinished jobs....
clang: note: diagnostic msg: 
********************

PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang: note: diagnostic msg: /tmp/elf_mem_image-SILiKz.cpp
clang: note: diagnostic msg: /tmp/elf_mem_image-SILiKz.sh
clang: note: diagnostic msg: 

********************
make: ***
[out/Release/obj.target/allocator/third_party/tcmalloc/chromium/src/base/elf_mem_image.o]
Error 255

As requested, the files listed in the error message are attached.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130405/f59f3330/attachment.html>

From bugzilla-daemon at llvm.org  Thu Apr  4 19:32:20 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 05 Apr 2013 02:32:20 +0000
Subject: [LLVMbugs] [Bug 15681] clangg++ error building Chromium on Linux
In-Reply-To: <bug-15681-206@http.llvm.org/bugs/>
References: <bug-15681-206@http.llvm.org/bugs/>
Message-ID: <bug-15681-206-rt6LXYdMlW@http.llvm.org/bugs/>

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

johnb316 at gmail.com changed:

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

--- Comment #6 from johnb316 at gmail.com ---
If that's the case, then the issue is probably with the prebuilt clang that the
tools/clang/scripts/update.sh script in Chromium pulls from llvm.org. That
clang was most likely built against Ubuntu, which I don't use (I use
Slackware64-current, FWIMBW). I suppose I'll have to tinker with the Chromium
gypi files so that the build uses the clang that Slackware supplies.

Given these circumstances, I'm going to mark this bug as RESOLVED and INVALID.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130405/532510f0/attachment.html>

From bugzilla-daemon at llvm.org  Fri Apr  5 00:21:58 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 05 Apr 2013 07:21:58 +0000
Subject: [LLVMbugs] [Bug 15682] New: Clang crash when compiling a simple C++
	program
Message-ID: <bug-15682-206@http.llvm.org/bugs/>

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

            Bug ID: 15682
           Summary: Clang crash when compiling a simple C++ program
           Product: libraries
           Version: 3.2
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Common Code Generator Code
          Assignee: unassignedbugs at nondot.org
          Reporter: kan.liu.229 at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 10296
  --> http://llvm.org/bugs/attachment.cgi?id=10296&action=edit
diagnostic msg

****************************The source code*******************************

#include <cstdio>

void merge(int* array, int* tmparray, int left, int center, int right) {
  int pos, lpos = left, rpos=center + 1;
  for (pos = left; pos < right; pos++) {
    if (lpos <= center && (rpos > right || array[lpos] < array[rpos])) {
      tmparray[pos] = array[lpos++];
    } else {
      tmparray[pos] = array[rpos++];
    }
  }
  for (int i = left; i <= right; i++) {
    array[i] = tmparray[i];
  }
}

void m_sort(int* array, int* tmparray, int left, int right) {
  if (left < right) {
    int center = (right - left) / 2 + left;
    m_sort(array, tmparray, left, center);
    m_sort(array, tmparray, center + 1, right);
    merge(array, tmparray, left, center, right);
  }
}


void merge_sort(int* array, size_t size) {
  if (size <= 1)
    return ;

  int *tmparray = new int[size];
  m_sort(array, tmparray, 0, size - 1);
  delete[] tmparray;
}

int main() {
  int tt[] = {1, 10, 4, 2, 6, 6, 10, 0};
  merge_sort(tt, sizeof(tt));
  for (int i = 0; i < sizeof(tt); i++)
    printf("%d ", tt[i]);
  return 0;
}

****************************   Result   *******************************

lk at lk-laptop:~$ clang++ test.cpp 
0  libLLVM-3.2.so.1 0x00007f08d59ae00f
1  libLLVM-3.2.so.1 0x00007f08d59ae5d1
2  libpthread.so.0  0x00007f08d49ffcb0
3  libLLVM-3.2.so.1 0x00007f08d58182f9
llvm::FastISel::getRegForValue(llvm::Value const*) + 41
4  libLLVM-3.2.so.1 0x00007f08d5a9a976
5  libLLVM-3.2.so.1 0x00007f08d581c1a8
llvm::FastISel::SelectInstruction(llvm::Instruction const*) + 216
6  libLLVM-3.2.so.1 0x00007f08d5938cac
llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) + 1196
7  libLLVM-3.2.so.1 0x00007f08d5939ee8
llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) + 680
8  libLLVM-3.2.so.1 0x00007f08d53d72f5
llvm::FPPassManager::runOnFunction(llvm::Function&) + 501
9  libLLVM-3.2.so.1 0x00007f08d53d7393
llvm::FPPassManager::runOnModule(llvm::Module&) + 51
10 libLLVM-3.2.so.1 0x00007f08d53d6fa9
llvm::MPPassManager::runOnModule(llvm::Module&) + 457
11 libLLVM-3.2.so.1 0x00007f08d53d70bf
llvm::PassManagerImpl::run(llvm::Module&) + 111
12 clang            0x000000000071312a
clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::CodeGenOptions
const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::Module*,
clang::BackendAction, llvm::raw_ostream*) + 4618
13 clang            0x0000000000710ab0
14 clang            0x000000000085221e clang::ParseAST(clang::Sema&, bool,
bool) + 382
15 clang            0x00000000005e3501 clang::FrontendAction::Execute() + 97
16 clang            0x00000000005c593d
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 285
17 clang            0x00000000005ae49a
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1338
18 clang            0x00000000005a7fb0 cc1_main(char const**, char const**,
char const*, void*) + 1168
19 clang            0x00000000005a69c0 main + 672
20 libc.so.6        0x00007f08d413c76d __libc_start_main + 237
21 clang            0x00000000005a79d9
Stack dump:
0.      Program arguments: /usr/bin/clang -cc1 -triple x86_64-pc-linux-gnu
-emit-obj -mrelax-all -disable-free -disable-llvm-verifier -main-file-name
test.cpp -mrelocation-model static -mdisable-fp-elim -fmath-errno -masm-verbose
-mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version
2.22 -momit-leaf-frame-pointer -resource-dir /usr/bin/../lib/clang/3.2
-fmodule-cache-path /var/tmp/clang-module-cache -internal-isystem
/usr/bin/../lib/gcc/x86_64-linux-gnu/4.6/../../../../include/c++/4.6
-internal-isystem
/usr/bin/../lib/gcc/x86_64-linux-gnu/4.6/../../../../include/c++/4.6/x86_64-linux-gnu
-internal-isystem
/usr/bin/../lib/gcc/x86_64-linux-gnu/4.6/../../../../include/c++/4.6/backward
-internal-isystem
/usr/bin/../lib/gcc/x86_64-linux-gnu/4.6/../../../../include/c++
-internal-isystem
/usr/bin/../lib/gcc/x86_64-linux-gnu/4.6/../../../../include/c++/x86_64-linux-gnu
-internal-isystem
/usr/bin/../lib/gcc/x86_64-linux-gnu/4.6/../../../../include/c++/backward
-internal-isystem /usr/local/include -internal-isystem
/usr/bin/../lib/clang/3.2/include -internal-isystem
/usr/include/clang/3.2/include/ -internal-externc-isystem
/usr/include/x86_64-linux-gnu -internal-externc-isystem
/usr/include/x86_64-linux-gnu -internal-externc-isystem /usr/include
-fdeprecated-macro -fdebug-compilation-dir /home/lk -ferror-limit 19
-fmessage-length 80 -mstackrealign -fobjc-runtime=gcc -fcxx-exceptions
-fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o
/tmp/test-BtMMsu.o -x c++ test.cpp 
1.      <eof> parser at end of file
2.      Code generation
3.      Running pass 'Function Pass Manager' on module 'test.cpp'.
4.      Running pass 'X86 DAG->DAG Instruction Selection' on function
'@_Z10merge_sortPim'
clang: error: unable to execute command: Segmentation fault (core dumped)
clang: error: clang frontend command failed due to signal (use -v to see
invocation)
Ubuntu clang version 3.2-1~exp5ubuntu1~precise1 (tags/RELEASE_32/final) (based
on LLVM 3.2)
Target: x86_64-pc-linux-gnu
Thread model: posix
clang: note: diagnostic msg: PLEASE submit a bug report to
http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and
associated run script.
clang: note: diagnostic msg: 
********************

PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang: note: diagnostic msg: /tmp/test-L9gloJ.cpp
clang: note: diagnostic msg: /tmp/test-L9gloJ.sh
clang: note: diagnostic msg: 

********************
lk at lk-laptop:~$ clang tes
tesseract-android-tools/ test.cpp                 
lk at lk-laptop:~$ clang test.cpp 
0  libLLVM-3.2.so.1 0x00007f483550b00f
1  libLLVM-3.2.so.1 0x00007f483550b5d1
2  libpthread.so.0  0x00007f483455ccb0
3  libLLVM-3.2.so.1 0x00007f48353752f9
llvm::FastISel::getRegForValue(llvm::Value const*) + 41
4  libLLVM-3.2.so.1 0x00007f48355f7976
5  libLLVM-3.2.so.1 0x00007f48353791a8
llvm::FastISel::SelectInstruction(llvm::Instruction const*) + 216
6  libLLVM-3.2.so.1 0x00007f4835495cac
llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) + 1196
7  libLLVM-3.2.so.1 0x00007f4835496ee8
llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) + 680
8  libLLVM-3.2.so.1 0x00007f4834f342f5
llvm::FPPassManager::runOnFunction(llvm::Function&) + 501
9  libLLVM-3.2.so.1 0x00007f4834f34393
llvm::FPPassManager::runOnModule(llvm::Module&) + 51
10 libLLVM-3.2.so.1 0x00007f4834f33fa9
llvm::MPPassManager::runOnModule(llvm::Module&) + 457
11 libLLVM-3.2.so.1 0x00007f4834f340bf
llvm::PassManagerImpl::run(llvm::Module&) + 111
12 clang            0x000000000071312a
clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::CodeGenOptions
const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::Module*,
clang::BackendAction, llvm::raw_ostream*) + 4618
13 clang            0x0000000000710ab0
14 clang            0x000000000085221e clang::ParseAST(clang::Sema&, bool,
bool) + 382
15 clang            0x00000000005e3501 clang::FrontendAction::Execute() + 97
16 clang            0x00000000005c593d
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 285
17 clang            0x00000000005ae49a
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1338
18 clang            0x00000000005a7fb0 cc1_main(char const**, char const**,
char const*, void*) + 1168
19 clang            0x00000000005a69c0 main + 672
20 libc.so.6        0x00007f4833c9976d __libc_start_main + 237
21 clang            0x00000000005a79d9
Stack dump:
0.      Program arguments: /usr/bin/clang -cc1 -triple x86_64-pc-linux-gnu
-emit-obj -mrelax-all -disable-free -disable-llvm-verifier -main-file-name
test.cpp -mrelocation-model static -mdisable-fp-elim -fmath-errno -masm-verbose
-mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version
2.22 -momit-leaf-frame-pointer -resource-dir /usr/bin/../lib/clang/3.2
-fmodule-cache-path /var/tmp/clang-module-cache -internal-isystem
/usr/bin/../lib/gcc/x86_64-linux-gnu/4.6/../../../../include/c++/4.6
-internal-isystem
/usr/bin/../lib/gcc/x86_64-linux-gnu/4.6/../../../../include/c++/4.6/x86_64-linux-gnu
-internal-isystem
/usr/bin/../lib/gcc/x86_64-linux-gnu/4.6/../../../../include/c++/4.6/backward
-internal-isystem
/usr/bin/../lib/gcc/x86_64-linux-gnu/4.6/../../../../include/c++
-internal-isystem
/usr/bin/../lib/gcc/x86_64-linux-gnu/4.6/../../../../include/c++/x86_64-linux-gnu
-internal-isystem
/usr/bin/../lib/gcc/x86_64-linux-gnu/4.6/../../../../include/c++/backward
-internal-isystem /usr/local/include -internal-isystem
/usr/bin/../lib/clang/3.2/include -internal-isystem
/usr/include/clang/3.2/include/ -internal-externc-isystem
/usr/include/x86_64-linux-gnu -internal-externc-isystem
/usr/include/x86_64-linux-gnu -internal-externc-isystem /usr/include
-fdeprecated-macro -fdebug-compilation-dir /home/lk -ferror-limit 19
-fmessage-length 80 -mstackrealign -fobjc-runtime=gcc -fcxx-exceptions
-fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o
/tmp/test-2X7dZs.o -x c++ test.cpp 
1.      <eof> parser at end of file
2.      Code generation
3.      Running pass 'Function Pass Manager' on module 'test.cpp'.
4.      Running pass 'X86 DAG->DAG Instruction Selection' on function
'@_Z10merge_sortPim'
clang: error: unable to execute command: Segmentation fault (core dumped)
clang: error: clang frontend command failed due to signal (use -v to see
invocation)
Ubuntu clang version 3.2-1~exp5ubuntu1~precise1 (tags/RELEASE_32/final) (based
on LLVM 3.2)
Target: x86_64-pc-linux-gnu
Thread model: posix
clang: note: diagnostic msg: PLEASE submit a bug report to
http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and
associated run script.
clang: note: diagnostic msg: 
********************

PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang: note: diagnostic msg: /tmp/test-IlGsSE.cpp
clang: note: diagnostic msg: /tmp/test-IlGsSE.sh
clang: note: diagnostic msg: 

********************
lk at lk-laptop:~$ ls
20080408145541789.jpg                   miniSQL
98ATautocomplete                        node
addyosmani-backbonejs-gallery-a3f51f7   node_modules
android                                 nodepad
android-ndk-r8b                         NVIDIA_CUDA-5.0_Samples
android-sdk-linux                       output4.jpeg
ants                                    output5.jpeg
AntsGame                                output6.jpeg
%APPDATA%                               patpat
Bespin Transparent Blur.bespin          python
builddir                                Qt5.0.1
cc                                      racket
cloudcity                               setup
cmpt379                                 square.cu
cmpt470                                 Sublime Text 2
cpp                                     tesseract-android-tools
cs344                                   test.cpp
cuda-5.0                                thawte.pem
cuda_5.0.35_linux_64_ubuntu11.10-1.run  tmp
eclipse                                 vim_works
fixit reader                            vuforia-sdk-android-2-0-31
glass.despin                            wps-office_8.1.0.3718~b1_x86
hs_err_pid7048.log                      下载
images.jpg                              公共的
jpeg-encoder                            图片
Jpeg_essential                          文档
Jpeg_essential_build                    桌面
Jpeg_essential_release                  模板
js                                      视频
koala-contactlist                       音乐
mezzofanti_java
lk at lk-laptop:~$ cd miniSQL/
lk at lk-laptop:~/miniSQL$ ls
bplustree.cpp  logger.cpp  nfa.cpp  README.md    scanner.hpp  test
bplustree.hpp  logger.hpp  nfa.hpp  scanner.cpp  tags         token.hpp
lk at lk-laptop:~/miniSQL$ clang++ logger.
clang: error: no such file or directory: 'logger.'
clang: error: no input files
lk at lk-laptop:~/miniSQL$ clang++ logger.cpp 
logger.cpp:9:3: warning: 'auto' type specifier is a C++11 extension
      [-Wc++11-extensions]
  auto it = loggers.find(name);
  ^
logger.cpp:33:8: warning: 'auto' type specifier is a C++11 extension
      [-Wc++11-extensions]
  for (auto i = loggers.begin(); i != loggers.end(); i++)
       ^
2 warnings generated.
/usr/bin/ld: /usr/lib/debug/usr/lib/x86_64-linux-gnu/crt1.o(.debug_info):
relocation 0 has invalid symbol index 10
/usr/bin/ld: /usr/lib/debug/usr/lib/x86_64-linux-gnu/crt1.o(.debug_info):
relocation 1 has invalid symbol index 11
/usr/bin/ld: /usr/lib/debug/usr/lib/x86_64-linux-gnu/crt1.o(.debug_info):
relocation 2 has invalid symbol index 2
/usr/bin/ld: /usr/lib/debug/usr/lib/x86_64-linux-gnu/crt1.o(.debug_info):
relocation 3 has invalid symbol index 2
/usr/bin/ld: /usr/lib/debug/usr/lib/x86_64-linux-gnu/crt1.o(.debug_info):
relocation 4 has invalid symbol index 10
/usr/bin/ld: /usr/lib/debug/usr/lib/x86_64-linux-gnu/crt1.o(.debug_info):
relocation 5 has invalid symbol index 12
/usr/bin/ld: /usr/lib/debug/usr/lib/x86_64-linux-gnu/crt1.o(.debug_info):
relocation 6 has invalid symbol index 12
/usr/bin/ld: /usr/lib/debug/usr/lib/x86_64-linux-gnu/crt1.o(.debug_info):
relocation 7 has invalid symbol index 12
/usr/bin/ld: /usr/lib/debug/usr/lib/x86_64-linux-gnu/crt1.o(.debug_info):
relocation 8 has invalid symbol index 2
/usr/bin/ld: /usr/lib/debug/usr/lib/x86_64-linux-gnu/crt1.o(.debug_info):
relocation 9 has invalid symbol index 2
/usr/bin/ld: /usr/lib/debug/usr/lib/x86_64-linux-gnu/crt1.o(.debug_info):
relocation 10 has invalid symbol index 11
/usr/bin/ld: /usr/lib/debug/usr/lib/x86_64-linux-gnu/crt1.o(.debug_info):
relocation 11 has invalid symbol index 12
/usr/bin/ld: /usr/lib/debug/usr/lib/x86_64-linux-gnu/crt1.o(.debug_info):
relocation 12 has invalid symbol index 12
/usr/bin/ld: /usr/lib/debug/usr/lib/x86_64-linux-gnu/crt1.o(.debug_info):
relocation 13 has invalid symbol index 12
/usr/bin/ld: /usr/lib/debug/usr/lib/x86_64-linux-gnu/crt1.o(.debug_info):
relocation 14 has invalid symbol index 12
/usr/bin/ld: /usr/lib/debug/usr/lib/x86_64-linux-gnu/crt1.o(.debug_info):
relocation 15 has invalid symbol index 12
/usr/bin/ld: /usr/lib/debug/usr/lib/x86_64-linux-gnu/crt1.o(.debug_info):
relocation 16 has invalid symbol index 12
/usr/bin/ld: /usr/lib/debug/usr/lib/x86_64-linux-gnu/crt1.o(.debug_info):
relocation 17 has invalid symbol index 12
/usr/bin/ld: /usr/lib/debug/usr/lib/x86_64-linux-gnu/crt1.o(.debug_info):
relocation 18 has invalid symbol index 12
/usr/bin/ld: /usr/lib/debug/usr/lib/x86_64-linux-gnu/crt1.o(.debug_info):
relocation 19 has invalid symbol index 12
/usr/bin/ld: /usr/lib/debug/usr/lib/x86_64-linux-gnu/crt1.o(.debug_info):
relocation 20 has invalid symbol index 19
/usr/bin/../lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/crt1.o: In
function `_start':
(.text+0x20): undefined reference to `main'
clang: error: linker command failed with exit code 1 (use -v to see invocation)
lk at lk-laptop:~/miniSQL$ cd ..
lk at lk-laptop:~$ clang++ test.cpp 
0  libLLVM-3.2.so.1 0x00007fe971ca500f
1  libLLVM-3.2.so.1 0x00007fe971ca55d1
2  libpthread.so.0  0x00007fe970cf6cb0
3  libLLVM-3.2.so.1 0x00007fe971b0f2f9
llvm::FastISel::getRegForValue(llvm::Value const*) + 41
4  libLLVM-3.2.so.1 0x00007fe971d91976
5  libLLVM-3.2.so.1 0x00007fe971b131a8
llvm::FastISel::SelectInstruction(llvm::Instruction const*) + 216
6  libLLVM-3.2.so.1 0x00007fe971c2fcac
llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) + 1196
7  libLLVM-3.2.so.1 0x00007fe971c30ee8
llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) + 680
8  libLLVM-3.2.so.1 0x00007fe9716ce2f5
llvm::FPPassManager::runOnFunction(llvm::Function&) + 501
9  libLLVM-3.2.so.1 0x00007fe9716ce393
llvm::FPPassManager::runOnModule(llvm::Module&) + 51
10 libLLVM-3.2.so.1 0x00007fe9716cdfa9
llvm::MPPassManager::runOnModule(llvm::Module&) + 457
11 libLLVM-3.2.so.1 0x00007fe9716ce0bf
llvm::PassManagerImpl::run(llvm::Module&) + 111
12 clang            0x000000000071312a
clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::CodeGenOptions
const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::Module*,
clang::BackendAction, llvm::raw_ostream*) + 4618
13 clang            0x0000000000710ab0
14 clang            0x000000000085221e clang::ParseAST(clang::Sema&, bool,
bool) + 382
15 clang            0x00000000005e3501 clang::FrontendAction::Execute() + 97
16 clang            0x00000000005c593d
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 285
17 clang            0x00000000005ae49a
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1338
18 clang            0x00000000005a7fb0 cc1_main(char const**, char const**,
char const*, void*) + 1168
19 clang            0x00000000005a69c0 main + 672
20 libc.so.6        0x00007fe97043376d __libc_start_main + 237
21 clang            0x00000000005a79d9
Stack dump:
0.      Program arguments: /usr/bin/clang -cc1 -triple x86_64-pc-linux-gnu
-emit-obj -mrelax-all -disable-free -disable-llvm-verifier -main-file-name
test.cpp -mrelocation-model static -mdisable-fp-elim -fmath-errno -masm-verbose
-mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version
2.22 -momit-leaf-frame-pointer -resource-dir /usr/bin/../lib/clang/3.2
-fmodule-cache-path /var/tmp/clang-module-cache -internal-isystem
/usr/bin/../lib/gcc/x86_64-linux-gnu/4.6/../../../../include/c++/4.6
-internal-isystem
/usr/bin/../lib/gcc/x86_64-linux-gnu/4.6/../../../../include/c++/4.6/x86_64-linux-gnu
-internal-isystem
/usr/bin/../lib/gcc/x86_64-linux-gnu/4.6/../../../../include/c++/4.6/backward
-internal-isystem
/usr/bin/../lib/gcc/x86_64-linux-gnu/4.6/../../../../include/c++
-internal-isystem
/usr/bin/../lib/gcc/x86_64-linux-gnu/4.6/../../../../include/c++/x86_64-linux-gnu
-internal-isystem
/usr/bin/../lib/gcc/x86_64-linux-gnu/4.6/../../../../include/c++/backward
-internal-isystem /usr/local/include -internal-isystem
/usr/bin/../lib/clang/3.2/include -internal-isystem
/usr/include/clang/3.2/include/ -internal-externc-isystem
/usr/include/x86_64-linux-gnu -internal-externc-isystem
/usr/include/x86_64-linux-gnu -internal-externc-isystem /usr/include
-fdeprecated-macro -fdebug-compilation-dir /home/lk -ferror-limit 19
-fmessage-length 80 -mstackrealign -fobjc-runtime=gcc -fcxx-exceptions
-fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o
/tmp/test-jGN2uR.o -x c++ test.cpp 
1.      <eof> parser at end of file
2.      Code generation
3.      Running pass 'Function Pass Manager' on module 'test.cpp'.
4.      Running pass 'X86 DAG->DAG Instruction Selection' on function
'@_Z10merge_sortPim'
clang: error: unable to execute command: Segmentation fault (core dumped)
clang: error: clang frontend command failed due to signal (use -v to see
invocation)
Ubuntu clang version 3.2-1~exp5ubuntu1~precise1 (tags/RELEASE_32/final) (based
on LLVM 3.2)
Target: x86_64-pc-linux-gnu
Thread model: posix
clang: note: diagnostic msg: PLEASE submit a bug report to
http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and
associated run script.
clang: note: diagnostic msg: 
********************

PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang: note: diagnostic msg: /tmp/test-UD9iFl.cpp
clang: note: diagnostic msg: /tmp/test-UD9iFl.sh
clang: note: diagnostic msg: 

********************

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130405/3911f1d3/attachment.html>

From bugzilla-daemon at llvm.org  Fri Apr  5 00:31:00 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 05 Apr 2013 07:31:00 +0000
Subject: [LLVMbugs] [Bug 15516] simultaneous diagnostics from sanitizers get
	intermixed
In-Reply-To: <bug-15516-206@http.llvm.org/bugs/>
References: <bug-15516-206@http.llvm.org/bugs/>
Message-ID: <bug-15516-206-tEOnRilI7j@http.llvm.org/bugs/>

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

Alexey Samsonov <samsonov at google.com> changed:

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

--- Comment #3 from Alexey Samsonov <samsonov at google.com> ---
Should be fixed by r178853.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130405/8a20095f/attachment.html>

From bugzilla-daemon at llvm.org  Fri Apr  5 01:14:49 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 05 Apr 2013 08:14:49 +0000
Subject: [LLVMbugs] [Bug 15683] New: pointer arithmetic with empty struct
 compiles into division by zero
Message-ID: <bug-15683-206@http.llvm.org/bugs/>

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

            Bug ID: 15683
           Summary: pointer arithmetic with empty struct compiles into
                    division by zero
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: jari at kirma.fi
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Unoptimized compilation of following program emits code that includes division
by zero (apparently clang considers struct to be zero-sized, and doesn't handle
the special case?):

#include <stddef.h>

int main(int argc, char **argv)
{
  struct {} x[2];
  volatile ptrdiff_t y = 1+x-x;
  return 0;
}

This issue occurs with -O0, but not with -O1.

Generated assembler below.

        .file   "struct_test.c"
        .text
        .globl  main
        .align  16, 0x90
        .type   main, at function
main:                                   # @main
        .cfi_startproc
# BB#0:
        pushq   %rbp
.Ltmp2:
        .cfi_def_cfa_offset 16
.Ltmp3:
        .cfi_offset %rbp, -16
        movq    %rsp, %rbp
.Ltmp4:
        .cfi_def_cfa_register %rbp
        movl    $0, %eax
        movl    $0, -4(%rbp)
        movl    %edi, -8(%rbp)
        movq    %rsi, -16(%rbp)
        xorl    %esi, %esi
        xorl    %edx, %edx
        movl    %eax, -36(%rbp)         # 4-byte Spill
        movq    %rsi, %rax
        divq    %rsi
        movq    %rax, -32(%rbp)
        movl    -36(%rbp), %eax         # 4-byte Reload
        popq    %rbp
        ret
.Ltmp5:
        .size   main, .Ltmp5-main
        .cfi_endproc


        .section        ".note.GNU-stack","", at progbits

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130405/549ce794/attachment.html>

From bugzilla-daemon at llvm.org  Fri Apr  5 02:44:02 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 05 Apr 2013 09:44:02 +0000
Subject: [LLVMbugs] [Bug 15684] New: recent clang "hangs" when scanning
 FreeBSD source code
Message-ID: <bug-15684-206@http.llvm.org/bugs/>

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

            Bug ID: 15684
           Summary: recent clang "hangs" when scanning FreeBSD source code
           Product: clang
           Version: trunk
          Hardware: PC
                OS: FreeBSD
            Status: NEW
          Severity: normal
          Priority: P
         Component: Static Analyzer
          Assignee: kremenek at apple.com
          Reporter: uspoerlein at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Hey, I'm running scans using ToT clang against FreeBSD's head 3 times a week,
results can be seen here: http://scan.freebsd.your.org/freebsd-head/

These run in a VM with 4 cores or so and usually take around 14-18h, as you can
see from the logfile timestamps (the runs start at midnight). The last run that
was ok used r177463 from March 20th, the next run using r177833 from March 24th
did not finish, I had to kill a couple of clang processes that we using up over
100h of hours of CPU.

The current run has 3 hanging clang instances and doesn't progress at all, top
snapshot:

% top -b 5
last pid: 24911;  load averages:  3.06,  3.02,  3.00  up 587+16:11:43   
09:46:16
84 processes:  5 running, 78 sleeping, 1 stopped

Mem: 213M Active, 7978M Inact, 1152M Wired, 233M Cache, 1237M Buf, 2306M Free
Swap: 4093M Total, 7848K Used, 4086M Free


  PID USERNAME  THR PRI NICE   SIZE    RES STATE   C   TIME   WCPU COMMAND
90516 uqs         1 129   10 64740K 55444K CPU3    3 127.4H 100.00% clang
 1496 uqs         1 129   10 64740K 55508K CPU2    2 126.4H 100.00% clang
83115 uqs         1 128   10 48252K 39256K CPU1    0 127.7H 96.97% clang
  853 root        1  44    0 23236K  1284K select  1 683:00  0.00%
vmtoolsd-real
 1114 root        1  44    0 29312K  9492K select  1 386:26  0.00% bsnmpd


two of these are hung on scanning the nvi sources (these haven't changed in
quite some time)

% lsof|grep "clang.*freebsd-head"
clang      1496   uqs  cwd     VDIR               0,82               2560 
2756720 /usr/obj/data/src/freebsd-head/usr.bin/vi
clang      1496   uqs  txt     VREG               0,82              24421   
72763 /data/src/freebsd-head/contrib/nvi/vi/vs_refresh.c
clang      1496   uqs  txt     VREG               0,82              23106 
3358307 /data/src/freebsd-head/sys/sys/cdefs.h
clang      1496   uqs  txt     VREG               0,82              16774 
2735768 /usr/obj/data/src/freebsd-head/tmp/usr/include/stdio.h
clang     83115   uqs  cwd     VDIR               0,82                512 
2734730 /usr/obj/data/src/freebsd-head/sys/boot/userboot/ficl
clang     83115   uqs  txt     VREG               0,82              23106 
3358307 /data/src/freebsd-head/sys/sys/cdefs.h
clang     83115   uqs  txt     VREG               0,82              21844 
3452753 /data/src/freebsd-head/sys/sys/queue.h
clang     83115   uqs  txt     VREG               0,82              42931  
358839 /data/src/freebsd-head/sys/boot/ficl/ficl.h
clang     83115   uqs    3r    VREG               0,82               4717 
2735729 /usr/obj/data/src/freebsd-head/tmp/usr/include/limits.h
clang     90516   uqs  cwd     VDIR               0,82               2560 
3226716
/usr/obj/data/src/freebsd-head/rescue/rescue/data/src/freebsd-head/usr.bin/vi
clang     90516   uqs  txt     VREG               0,82              24421   
72763 /data/src/freebsd-head/contrib/nvi/vi/vs_refresh.c
clang     90516   uqs  txt     VREG               0,82              23106 
3358307 /data/src/freebsd-head/sys/sys/cdefs.h
clang     90516   uqs  txt     VREG               0,82              16774 
2735768 /usr/obj/data/src/freebsd-head/tmp/usr/include/stdio.h

What's a quick way to get a preprocessed file out of that?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130405/85b5bd8f/attachment.html>

From bugzilla-daemon at llvm.org  Fri Apr  5 02:44:08 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 05 Apr 2013 09:44:08 +0000
Subject: [LLVMbugs] [Bug 15683] pointer arithmetic with empty struct
 compiles into division by zero
In-Reply-To: <bug-15683-206@http.llvm.org/bugs/>
References: <bug-15683-206@http.llvm.org/bugs/>
Message-ID: <bug-15683-206-BUk1TLXUCj@http.llvm.org/bugs/>

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

Jari Kirma <jari at kirma.fi> changed:

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

--- Comment #1 from Jari Kirma <jari at kirma.fi> ---
After a second of thought and comment from a colleague, closing as invalid:
structure with no named members is undefined behavior.

Maybe this undefined behavior could emit a warning. Or is there such a warning
already?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130405/2f2da147/attachment.html>

From bugzilla-daemon at llvm.org  Fri Apr  5 04:20:39 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 05 Apr 2013 11:20:39 +0000
Subject: [LLVMbugs] [Bug 15685] New: OpenCL 'char' is not signed
Message-ID: <bug-15685-206@http.llvm.org/bugs/>

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

            Bug ID: 15685
           Summary: OpenCL 'char' is not signed
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: kalle.raiskila at nokia.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

When compiling OpenCL, the signedness of 'char' is platform dependant (as in
C), whereas the OpenCL spec (§6.1.1) defines 'char' to be signed.

check with e.g.: 
echo "int foo=(char)0xff;" | clang -x cl - -o - -emit-llvm -S

which compiles on PowerPC to:
@foo = global i32 255, align 4

but, on Intel:
@foo = global i32 -1, align 4

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130405/541f5046/attachment.html>

From bugzilla-daemon at llvm.org  Fri Apr  5 05:46:51 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 05 Apr 2013 12:46:51 +0000
Subject: [LLVMbugs] [Bug 15686] New: Class constructor default argument
	fails to compile
Message-ID: <bug-15686-206@http.llvm.org/bugs/>

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

            Bug ID: 15686
           Summary: Class constructor default argument fails to compile
           Product: new-bugs
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: MyAdEss at seznam.cz
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

If a class constructor has an argument that takes a default value that itself
is a template of more than one parameter, it fails to compile.

Example of a full program:
http://ideone.com/mv9Qco
/***************************************************/
#include <functional>
using namespace std;

/* a function template */
template <typename A, typename B>
A f(B) { return A(); }

/* a class template */
template <typename A, typename B>
class X {};

template <typename A, typename B>
class Y
{
  /** All these constructors fail to compile **/

  Y(X<A,B> = X<A,B>())
  //Y(A (*arg)(B) = f<A, B>)
  //Y(std::function<A(B)> arg = f<A, B>)
  { }
};

int main()
{ return 0; }
/***************************************************/

It compiles successfully on GCC and MSVC.

Compiler error:
clangtest.cpp:17:19: error: expected ')'
  Y(X<A,B> = X<A,B>())
                  ^
clangtest.cpp:17:4: note: to match this '('
  Y(X<A,B> = X<A,B>())
   ^
clangtest.cpp:17:17: error: expected '>'
  Y(X<A,B> = X<A,B>())
                ^
2 errors generated.


--Floop

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130405/4a8a4d17/attachment.html>

From bugzilla-daemon at llvm.org  Fri Apr  5 08:44:02 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 05 Apr 2013 15:44:02 +0000
Subject: [LLVMbugs] [Bug 15687] New: clang fails to build kernel/bound.c
 (Linux Kernel build)
Message-ID: <bug-15687-206@http.llvm.org/bugs/>

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

            Bug ID: 15687
           Summary: clang fails to build kernel/bound.c (Linux Kernel
                    build)
           Product: clang
           Version: unspecified
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: LLVM Codegen
          Assignee: unassignedclangbugs at nondot.org
          Reporter: dl9pf at gmx.de
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Aborted with clang error.

Clang version: trunk at 178860
LLVM version: trunk at 178859
Linux Kernel:  d08d528dc1848fb369a0b27cdb0749d8f6f38063  (3.9-rc6+)

make CONFIG_DEBUG_SECTION_MISMATCH=y CONFIG_DEBUG_INFO=1 -j1 CC=clang
make[1]: Entering directory `/local/dl9pf/llvmlinux/targets/x86_64/src/linux'
make[2]: Nothing to be done for `all'.
make[2]: Nothing to be done for `relocs'.
  CHK     include/generated/uapi/linux/version.h
  CHK     include/generated/utsrelease.h
  UPD     include/generated/utsrelease.h
  CC      kernel/bounds.s
clang-3.3:
/local/dl9pf/llvmlinux/toolchain/clang/src/llvm/lib/IR/Value.cpp:553: void
llvm::ValueHandleBase::RemoveFromUseList(): Assertion `VP.getPointer() &&
VP.getPointer()->HasValueHandle && "Pointer doesn't have a use list!"' failed.
0  clang-3.3       0x0000000001995f4a llvm::sys::PrintStackTrace(_IO_FILE*) +
38
1  clang-3.3       0x00000000019961d1
2  clang-3.3       0x0000000001995c20
3  libpthread.so.0 0x00007fc8af8fc1f0
4  libc.so.6       0x00007fc8aed5b3d5 gsignal + 53
5  libc.so.6       0x00007fc8aed5c858 abort + 328
6  libc.so.6       0x00007fc8aed542e2
7  libc.so.6       0x00007fc8aed54392
8  clang-3.3       0x00000000018b73d9
llvm::ValueHandleBase::RemoveFromUseList() + 91
9  clang-3.3       0x0000000000f4e97d
10 clang-3.3       0x000000000152dc34
11 clang-3.3       0x00000000019e02b7
12 clang-3.3       0x00000000019d9dea
clang::CodeGen::CodeGenFunction::StartFunction(clang::GlobalDecl,
clang::QualType, llvm::Function*, clang::CodeGen::CGFunctionInfo const&,
clang::CodeGen::FunctionArgList const&, clang::SourceLocation) + 832
13 clang-3.3       0x00000000019daae7
clang::CodeGen::CodeGenFunction::GenerateCode(clang::GlobalDecl,
llvm::Function*, clang::CodeGen::CGFunctionInfo const&) + 539
14 clang-3.3       0x00000000019edef7
clang::CodeGen::CodeGenModule::EmitGlobalFunctionDefinition(clang::GlobalDecl)
+ 669
15 clang-3.3       0x00000000019eb041
clang::CodeGen::CodeGenModule::EmitGlobalDefinition(clang::GlobalDecl) + 383
16 clang-3.3       0x00000000019ea97e
clang::CodeGen::CodeGenModule::EmitGlobal(clang::GlobalDecl) + 696
17 clang-3.3       0x00000000019f0efa
clang::CodeGen::CodeGenModule::EmitTopLevelDecl(clang::Decl*) + 320
18 clang-3.3       0x00000000019c94ad
19 clang-3.3       0x00000000019c853a
20 clang-3.3       0x0000000001d2ab27 clang::ParseAST(clang::Sema&, bool, bool)
+ 554
21 clang-3.3       0x0000000001c376a4 clang::ASTFrontendAction::ExecuteAction()
+ 298
22 clang-3.3       0x00000000019c7851 clang::CodeGenAction::ExecuteAction() +
1273
23 clang-3.3       0x0000000001c37226 clang::FrontendAction::Execute() + 200
24 clang-3.3       0x0000000001c11416
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 564
25 clang-3.3       0x000000000199ae26
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1060
26 clang-3.3       0x0000000000c0782d cc1_main(char const**, char const**, char
const*, void*) + 641
27 clang-3.3       0x0000000000c019b3 main + 508
28 libc.so.6       0x00007fc8aed47a15 __libc_start_main + 245
29 clang-3.3       0x0000000000c00089
Stack dump:
0.      Program arguments:
/local/dl9pf/llvmlinux/toolchain/clang/install/bin/clang-3.3 -cc1 -triple
x86_64-unknown-linux-gnu -S -disable-free -disable-llvm-verifier
-main-file-name bounds.c -mrelocation-model static -mdisable-fp-elim
-relaxed-aliasing -mdisable-tail-calls -fmath-errno -masm-verbose
-mconstructor-aliases -fuse-init-array -mcode-model kernel -disable-red-zone
-target-cpu x86-64 -target-feature -sse -target-feature -mmx -target-feature
-sse2 -target-feature -3dnow -target-feature -avx -momit-leaf-frame-pointer -g
-coverage-file /local/dl9pf/llvmlinux/targets/x86_64/src/linux/kernel/bounds.s
-nostdsysteminc -nobuiltininc -resource-dir
/local/dl9pf/llvmlinux/toolchain/clang/install/bin/../lib/clang/3.3
-dependency-file kernel/.bounds.s.d -MT kernel/bounds.s -sys-header-deps
-isystem
/local/dl9pf/llvmlinux/toolchain/clang/install/bin/../lib/clang/3.3/include
-include
/local/dl9pf/llvmlinux/targets/x86_64/src/linux/include/linux/kconfig.h -D
__KERNEL__ -D CONFIG_AS_CFI=1 -D CONFIG_AS_CFI_SIGNAL_FRAME=1 -D
CONFIG_AS_CFI_SECTIONS=1 -D CONFIG_AS_FXSAVEQ=1 -D CONFIG_AS_AVX=1 -D
CONFIG_AS_AVX2=1 -D KBUILD_STR(s)=#s -D KBUILD_BASENAME=KBUILD_STR(bounds) -D
KBUILD_MODNAME=KBUILD_STR(bounds) -I
/local/dl9pf/llvmlinux/targets/x86_64/src/linux/arch/x86/include -I
arch/x86/include/generated -I include -I
/local/dl9pf/llvmlinux/targets/x86_64/src/linux/arch/x86/include/uapi -I
arch/x86/include/generated/uapi -I
/local/dl9pf/llvmlinux/targets/x86_64/src/linux/include/uapi -I
include/generated/uapi -O2 -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs
-Werror-implicit-function-declaration -Wno-format-security -Wno-sign-compare
-Wno-unused-variable -Wno-tautological-compare -Wdeclaration-after-statement
-Wno-pointer-sign -fdebug-compilation-dir
/local/dl9pf/llvmlinux/targets/x86_64/src/linux -ferror-limit 19
-fmessage-length 117 -fwrapv -mstackrealign -fobjc-runtime=gcc
-fobjc-default-synthesize-properties -fno-common -fdiagnostics-show-option
-fcolor-diagnostics -backend-option -vectorize-loops -o kernel/bounds.s -x c
kernel/bounds.c 
1.      <eof> parser at end of file
2.      kernel/bounds.c:14:6: LLVM IR generation of declaration 'foo'
3.      kernel/bounds.c:14:6: Generating code for declaration 'foo'
clang-3.3: error: unable to execute command: Aborted
clang-3.3: error: clang frontend command failed due to signal (use -v to see
invocation)
clang version 3.3 
Target: x86_64-unknown-linux-gnu
Thread model: posix
clang-3.3: note: diagnostic msg: PLEASE submit a bug report to  and include the
crash backtrace, preprocessed source, and associated run script.
clang-3.3: note: diagnostic msg: 
********************

PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang-3.3: note: diagnostic msg:
/local/dl9pf/llvmlinux/targets/x86_64/tmp/bounds-gN5RQ7.c
clang-3.3: note: diagnostic msg:
/local/dl9pf/llvmlinux/targets/x86_64/tmp/bounds-gN5RQ7.sh
clang-3.3: note: diagnostic msg: 

********************
make[2]: *** [kernel/bounds.s] Error 254

kernel/bounds.c :
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/kernel/bounds.c

Files attached.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130405/b87ec9df/attachment.html>

From bugzilla-daemon at llvm.org  Fri Apr  5 09:04:19 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 05 Apr 2013 16:04:19 +0000
Subject: [LLVMbugs] [Bug 15686] Class constructor default argument fails to
	compile
In-Reply-To: <bug-15686-206@http.llvm.org/bugs/>
References: <bug-15686-206@http.llvm.org/bugs/>
Message-ID: <bug-15686-206-LqnRR2bn2t@http.llvm.org/bugs/>

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

Richard Smith <richard-llvm at metafoo.co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |richard-llvm at metafoo.co.uk
         Resolution|---                         |DUPLICATE

--- Comment #2 from Richard Smith <richard-llvm at metafoo.co.uk> ---


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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130405/1fe560a6/attachment.html>

From bugzilla-daemon at llvm.org  Fri Apr  5 09:51:17 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 05 Apr 2013 16:51:17 +0000
Subject: [LLVMbugs] [Bug 15683] pointer arithmetic with empty struct
 compiles into division by zero
In-Reply-To: <bug-15683-206@http.llvm.org/bugs/>
References: <bug-15683-206@http.llvm.org/bugs/>
Message-ID: <bug-15683-206-zIGo2jLcbH@http.llvm.org/bugs/>

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

Serge Pavlov <sepavloff at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
                 CC|                            |sepavloff at gmail.com
          Component|-New Bugs                   |Frontend
         Resolution|INVALID                     |---

--- Comment #2 from Serge Pavlov <sepavloff at gmail.com> ---
Empty structures are supported as GCC extension, corresponding message is
emitted if flag '-pedantic' is specified. So reopening this bug.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130405/85328b93/attachment.html>

From bugzilla-daemon at llvm.org  Fri Apr  5 09:59:58 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 05 Apr 2013 16:59:58 +0000
Subject: [LLVMbugs] [Bug 15655] libLLVMTarget.so is not linked with
 -lLLVMCodeGet,
 unresolved llvm::MachineInstr::hasPropertyInBundle when linking llvm-dis
In-Reply-To: <bug-15655-206@http.llvm.org/bugs/>
References: <bug-15655-206@http.llvm.org/bugs/>
Message-ID: <bug-15655-206-GxX4nZ2XKL@http.llvm.org/bugs/>

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

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> ---
CMake shared library build was broken in 3.2. It works with LLVM trunk.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130405/2a8feae3/attachment.html>

From bugzilla-daemon at llvm.org  Fri Apr  5 14:39:08 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 05 Apr 2013 21:39:08 +0000
Subject: [LLVMbugs] [Bug 11818] Debug info broken,
 gdb can't find value of variables (value optimized out)
In-Reply-To: <bug-11818-206@http.llvm.org/bugs/>
References: <bug-11818-206@http.llvm.org/bugs/>
Message-ID: <bug-11818-206-RRsFLyGEkD@http.llvm.org/bugs/>

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

Eric Christopher <echristo at gmail.com> changed:

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

--- Comment #25 from Eric Christopher <echristo at gmail.com> ---
Since we've not gotten a new testcase and it seems to generally work I'm going
to close it. Feel free to reopen if you can get a testcase (or just open a new
bug).

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130405/ac4a7b4a/attachment.html>

From bugzilla-daemon at llvm.org  Fri Apr  5 15:44:54 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 05 Apr 2013 22:44:54 +0000
Subject: [LLVMbugs] [Bug 15688] New: missing return value
Message-ID: <bug-15688-206@http.llvm.org/bugs/>

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

            Bug ID: 15688
           Summary: missing return value
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
          Assignee: unassignedclangbugs at nondot.org
          Reporter: drivehappy at gmail.com
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 10303
  --> http://llvm.org/bugs/attachment.cgi?id=10303&action=edit
Reproduce source code

When a function contains a missing return value when a return type is specified
the program will contain undefined results. For the attached code I receive an
"Illegal instruction" when running the executable.

The ISO C++ standard 6.6.3 does state that, "Flowing off the end of a function
is equivalent to a return with no value; this results in undefined behavior in
a value-returning function." If this is the reason clang is generating code
then I would consider it resolved. However some more diagnostics might be more
helpful, instead of the seemingly benign warning of: "missing_return.cpp:2:1:
warning: control reaches end of non-void function"

Appears in Clang 3.2 and trunk, under Debug and Release for both 32 and 64-bit
generated code.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130405/4870541b/attachment.html>

From bugzilla-daemon at llvm.org  Fri Apr  5 17:03:57 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 06 Apr 2013 00:03:57 +0000
Subject: [LLVMbugs] [Bug 13015] missing destructor call for temporary
 created by C++11 braced initializer list syntax as function argument
In-Reply-To: <bug-13015-206@http.llvm.org/bugs/>
References: <bug-13015-206@http.llvm.org/bugs/>
Message-ID: <bug-13015-206-MmeCyhSRA5@http.llvm.org/bugs/>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #5 from Douglas Gregor <dgregor at apple.com> ---
These simple cases are working on trunk

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130406/64126c9b/attachment.html>

From bugzilla-daemon at llvm.org  Fri Apr  5 18:47:35 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 06 Apr 2013 01:47:35 +0000
Subject: [LLVMbugs] [Bug 15684] recent clang "hangs" when scanning FreeBSD
	source code
In-Reply-To: <bug-15684-206@http.llvm.org/bugs/>
References: <bug-15684-206@http.llvm.org/bugs/>
Message-ID: <bug-15684-206-eKHRFuSWJB@http.llvm.org/bugs/>

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

Jordan Rose <jordan_rose at apple.com> changed:

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

--- Comment #5 from Jordan Rose <jordan_rose at apple.com> ---
Silly mistake of mine. Should be fixed in r178944. Thanks for the report!

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130406/a8577f1c/attachment.html>

From bugzilla-daemon at llvm.org  Sat Apr  6 02:21:25 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 06 Apr 2013 09:21:25 +0000
Subject: [LLVMbugs] [Bug 15690] New: Two clang crashes occur running
 scan-build ryzom/rzyomcore
Message-ID: <bug-15690-206@http.llvm.org/bugs/>

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

            Bug ID: 15690
           Summary: Two clang crashes occur running scan-build
                    ryzom/rzyomcore
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Static Analyzer
          Assignee: kremenek at apple.com
          Reporter: lbalbalba at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

When running scan-build on ryzom/ryzomcore, the attached two crashes occur.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130406/669daa2b/attachment.html>

From bugzilla-daemon at llvm.org  Sat Apr  6 04:57:44 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 06 Apr 2013 11:57:44 +0000
Subject: [LLVMbugs] [Bug 15690] Two clang crashes occur running scan-build
 ryzom/rzyomcore
In-Reply-To: <bug-15690-206@http.llvm.org/bugs/>
References: <bug-15690-206@http.llvm.org/bugs/>
Message-ID: <bug-15690-206-GEExJQJVMm@http.llvm.org/bugs/>

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

John Smith <lbalbalba at gmail.com> changed:

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

--- Comment #2 from John Smith <lbalbalba at gmail.com> ---
Im unable to reproduce this with clang version 3.3 (trunk 178955).

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130406/cb797370/attachment.html>

From bugzilla-daemon at llvm.org  Sat Apr  6 05:12:18 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 06 Apr 2013 12:12:18 +0000
Subject: [LLVMbugs] [Bug 13995] Crash running scan-build (clang r164463) on
 blender (svn r50962)
In-Reply-To: <bug-13995-206@http.llvm.org/bugs/>
References: <bug-13995-206@http.llvm.org/bugs/>
Message-ID: <bug-13995-206-9LV4ZKqlRo@http.llvm.org/bugs/>

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

John Smith <lbalbalba at gmail.com> changed:

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

--- Comment #3 from John Smith <lbalbalba at gmail.com> ---
Unable to reproduce this with clang version 3.3 (trunk 178955).

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130406/0d3360a2/attachment.html>

From bugzilla-daemon at llvm.org  Sat Apr  6 05:17:45 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 06 Apr 2013 12:17:45 +0000
Subject: [LLVMbugs] [Bug 13614] clang crashes during scan-build of
	LibreOffice ~master
In-Reply-To: <bug-13614-206@http.llvm.org/bugs/>
References: <bug-13614-206@http.llvm.org/bugs/>
Message-ID: <bug-13614-206-6t8dKe6kZW@http.llvm.org/bugs/>

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

John Smith <lbalbalba at gmail.com> changed:

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

--- Comment #1 from John Smith <lbalbalba at gmail.com> ---
Unable to reproduce this with clang version 3.3 (trunk 178955).

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130406/144f1242/attachment.html>

From bugzilla-daemon at llvm.org  Sat Apr  6 12:33:46 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 06 Apr 2013 19:33:46 +0000
Subject: [LLVMbugs] [Bug 15687] clang fails to build kernel/bound.c (Linux
	Kernel build)
In-Reply-To: <bug-15687-206@http.llvm.org/bugs/>
References: <bug-15687-206@http.llvm.org/bugs/>
Message-ID: <bug-15687-206-M9XSnJPO5o@http.llvm.org/bugs/>

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

Jan-Simon Möller <dl9pf at gmx.de> changed:

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

--- Comment #8 from Jan-Simon Möller <dl9pf at gmx.de> ---
Fresh checkout seems to work. 
Still, what could cause this behaviour  ?

Check also #15676 .

Closing.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130406/1ee228c9/attachment.html>

From bugzilla-daemon at llvm.org  Sat Apr  6 12:33:48 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 06 Apr 2013 19:33:48 +0000
Subject: [LLVMbugs] [Bug 4068] [META] Compiling the Linux kernel with clang
In-Reply-To: <bug-4068-206@http.llvm.org/bugs/>
References: <bug-4068-206@http.llvm.org/bugs/>
Message-ID: <bug-4068-206-ok16r34Ed0@http.llvm.org/bugs/>

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

Bug 4068 depends on bug 15687, which changed state.

Bug 15687 Summary: clang fails to build kernel/bound.c (Linux Kernel build)
http://llvm.org/bugs/show_bug.cgi?id=15687

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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130406/e56595df/attachment.html>

From bugzilla-daemon at llvm.org  Sat Apr  6 14:25:17 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 06 Apr 2013 21:25:17 +0000
Subject: [LLVMbugs] [Bug 15691] New: MakeCInformation.cmake:37
 (get_filename_component) cmake "Visual Studio 10" "Visual Studio 2008"
Message-ID: <bug-15691-206@http.llvm.org/bugs/>

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

            Bug ID: 15691
           Summary: MakeCInformation.cmake:37 (get_filename_component)
                    cmake "Visual Studio 10" "Visual Studio 2008"
           Product: Build scripts
           Version: 3.2
          Hardware: PC
                OS: Windows XP
            Status: NEW
          Keywords: build-problem
          Severity: normal
          Priority: P
         Component: cmake
          Assignee: unassignedbugs at nondot.org
          Reporter: Andre_Mikulec at Hotmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 10306
  --> http://llvm.org/bugs/attachment.cgi?id=10306&action=edit
2010 cmake error log

My system

llvm and clang
Checked out revisions 178956
on windows XP ( 5.1 ) using 

When I run ...

cmake -G "Visual Studio 10" ..
OR
cmake -G "Visual Studio 2008" ..

I am getting the following "exact same error"

-- The C compiler identification is unknown
-- The CXX compiler identification is unknown
-- Looking for argz.h
CMake Error at F:/Program Files/CMake
2.8/share/cmake-2.8/Modules/CMakeCInformation.cmake:37
(get_filename_component):
  get_filename_component called with incorrect number of arguments
Call Stack (most recent call first):
  CMakeLists.txt:3 (PROJECT)
...

CMake Error: Internal CMake error, TryCompile configure of cmake failed
-- Performing Test SUPPORTS_NO_VARIADIC_MACROS_FLAG - Failed
mkdir: cannot create directory `/tmp/cg-7684': No such file or directory
config.guess: cannot create a temporary directory in /tmp
CMake Error at cmake/modules/GetHostTriple.cmake:24 (message):
  Failed to execute
 
M:/YDrive/All_Economics/eclipse_workspace/CheckoutLLVM/llvm/autoconf/config.guess
Call Stack (most recent call first):
  cmake/config-ix.cmake:336 (get_host_triple)
  CMakeLists.txt:243 (include)

Maybe the instructions 

If you are using Visual Studio 2008: cmake -G "Visual Studio 9 2008" ..\llvm

Or if you are using Visual Studio 2010: cmake -G "Visual Studio 10" ..\llvm

on page 
http://clang.llvm.org/get_started.html

should be updated?

Thank you,
Andre Mikulec
Andre_Mikulec at Hotmail.com

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130406/c6086764/attachment.html>

From bugzilla-daemon at llvm.org  Sat Apr  6 14:31:42 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 06 Apr 2013 21:31:42 +0000
Subject: [LLVMbugs] [Bug 15692] New: cmake MinGW Makefiles
 DummyConfigureOutput.tmp and SVNVersion.inc missing
Message-ID: <bug-15692-206@http.llvm.org/bugs/>

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

            Bug ID: 15692
           Summary: cmake MinGW Makefiles DummyConfigureOutput.tmp and
                    SVNVersion.inc missing
           Product: Build scripts
           Version: 3.2
          Hardware: PC
                OS: Windows XP
            Status: NEW
          Keywords: build-problem
          Severity: normal
          Priority: P
         Component: cmake
          Assignee: unassignedbugs at nondot.org
          Reporter: Andre_Mikulec at Hotmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 10307
  --> http://llvm.org/bugs/attachment.cgi?id=10307&action=edit
MinGW Makefiles CMakeOutput.log

llvm and clang
Checked out revisions 178956
on windows XP ( 5.1 ) using 
GNU Make 3.82
 Built for i386-pc-mingw3
Thread model: win32
gcc version 4.6.2 (GCC)

FIRST
When I try a cmake configure with my SVN executable in the path
cmake -G "MinGW Makefiles" ..\llvm

I get the following errors

-- Constructing LLVMBuild project information
CMake Error: Could not open file for write in copy operation
M:/YDrive/All_Economics/eclipse_workspace/build/DummyConfigureOutput.tmp
CMake Error: : System Error: Permission denied
CMake Error at
M:/YDrive/All_Economics/eclipse_workspace/build/LLVMBuild.cmake:290
(configure_file):
  configure_file Problem configuring file
Call Stack (most recent call first):
  CMakeLists.txt:318 (include)

-- Found Subversion: F:/Program Files/Subversion/bin/svn.exe (found version
"1.7.8")
-- Expecting header to go in
M:/YDrive/All_Economics/eclipse_workspace/build/tools/clang/lib/Basic/SVNVersion.inc
-- Configuring incomplete, errors occurred!

SECOND
When I try a cmake configure with my SVN executable in the path
cmake -G "MinGW Makefiles" ..\llvm

I get the following errors.

CMake Error: Could not open file for write in copy operation
M:/YDrive/All_Economics/eclipse_workspace/build/DummyConfigureOutput.tmp
CMake Error: : System Error: Permission denied
CMake Error at
M:/YDrive/All_Economics/eclipse_workspace/build/LLVMBuild.cmake:204
(configure_file):
  configure_file Problem configuring file
Call Stack (most recent call first):
  CMakeLists.txt:318 (include)

Expecting header to go in
M:/YDrive/All_Economics/eclipse_workspace/build/tools/clang/lib/Basic/SVNVersion.inc
Configuring incomplete, errors occurred!

But, I am logged in as "Administrator." 
I should not get "System Error: Permission denied"

I did not find "DummyConfigureOutput.tmp"

I did find "DummyConfigureOutput" with one line

    "from main import main"


If I "generate" using cmake and "MinGW Makefiles" 

I am still getting the following error

CMake Error: Could not open file for write in copy operation
M:/YDrive/All_Economics/eclipse_workspace/build/DummyConfigureOutput.tmp
CMake Error: : System Error: Permission denied
CMake Error at
M:/YDrive/All_Economics/eclipse_workspace/build/LLVMBuild.cmake:160
(configure_file):
  configure_file Problem configuring file
Call Stack (most recent call first):
  CMakeLists.txt:318 (include)

Expecting header to go in
M:/YDrive/All_Economics/eclipse_workspace/build/tools/clang/lib/Basic/SVNVersion.inc
Configuring incomplete, errors occurred!



THIRD
When I try a cmake configure without my SVN executable in the path
cmake -G "MinGW Makefiles" ..\llvm

I am still getting this error message.

Found Subversion: F:/Program Files/Subversion/bin/svn.exe (found version
"1.7.8") 
Expecting header to go in
M:/YDrive/All_Economics/eclipse_workspace/build/tools/clang/lib/Basic/SVNVersion.inc
Configuring done

When I try to "make" with "mingw32-make.exe" and  without my SVN executable in
my path

After about two hours of compiling, I get the following message

[ 73%] Building CXX object
tools/clang/lib/Basic/CMakeFiles/clangBasic.dir/TokenKinds.cpp.obj
[ 73%] Building CXX object
tools/clang/lib/Basic/CMakeFiles/clangBasic.dir/Version.cpp.obj
M:\YDrive\All_Economics\eclipse_workspace\llvm\tools\clang\lib\Basic\Version.cpp:22:28:
fatal error: SVNVersion.inc: No such file or directory
compilation terminated.
mingw32-make.exe[2]: ***
[tools/clang/lib/Basic/CMakeFiles/clangBasic.dir/Version.cpp.obj] Error 1
mingw32-make.exe[1]: *** [tools/clang/lib/Basic/CMakeFiles/clangBasic.dir/all]
Error 2
mingw32-make.exe: *** [all] Error 2

My lines 21 through 30 look like ...
M:\YDrive\All_Economics\eclipse_workspace\llvm\tools\clang\lib\Basic\Version.cpp

21 #ifdef HAVE_SVN_VERSION_INC
22 #  include "SVNVersion.inc"  ( HERE )
23 #endif
24 
25 namespace clang {
26 
27 std::string getClangRepositoryPath() {
28 #if defined(CLANG_REPOSITORY_STRING)
29  return CLANG_REPOSITORY_STRING;
30 #else

No file called "SVNVersion.inc" exists that directory
M:\YDrive\All_Economics\eclipse_workspace\llvm\tools\clang\lib\Basic

Do I need an SVN executable in my path?
Where is this SVNVersion.inc file?

Thank you,
Andre Mikulec
Andre_Mikulec at Hotmail.com

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130406/dc651f74/attachment.html>

From bugzilla-daemon at llvm.org  Sat Apr  6 19:30:29 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 07 Apr 2013 02:30:29 +0000
Subject: [LLVMbugs] [Bug 15693] New: crash-on-invalid: Assertion `Val &&
 "isa<> used on a null pointer"'
Message-ID: <bug-15693-206@http.llvm.org/bugs/>

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

            Bug ID: 15693
           Summary: crash-on-invalid: Assertion `Val && "isa<> used on a
                    null pointer"'
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: adamschn at umich.edu
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 10308
  --> http://llvm.org/bugs/attachment.cgi?id=10308&action=edit
crashing test case

I am getting an assert failure when compiling a sample with duplicated enum
values, but only on -Weverything.

I have attached a test case, run script and stack trace.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130407/5b29c407/attachment.html>

From bugzilla-daemon at llvm.org  Sun Apr  7 04:00:03 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 07 Apr 2013 11:00:03 +0000
Subject: [LLVMbugs] [Bug 15694] New: clang trunk r178955 crashes running
 scan-build on 'ryzomcore'
Message-ID: <bug-15694-206@http.llvm.org/bugs/>

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

            Bug ID: 15694
           Summary: clang trunk r178955 crashes running scan-build on
                    'ryzomcore'
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Static Analyzer
          Assignee: kremenek at apple.com
          Reporter: lbalbalba at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Running clang version 3.3 (trunk 178955) scan-build on 'ryzomcore' generates a
few crashes. You can reproduce by running 'clang --analyze ./foo.ii' on the
preprocessed files in the attachment.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130407/b855397a/attachment.html>

From bugzilla-daemon at llvm.org  Sun Apr  7 04:24:24 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 07 Apr 2013 11:24:24 +0000
Subject: [LLVMbugs] [Bug 15603] SROA fix for PR14972 introduced a new
	regression
In-Reply-To: <bug-15603-206@http.llvm.org/bugs/>
References: <bug-15603-206@http.llvm.org/bugs/>
Message-ID: <bug-15603-206-PVi2jRFwuD@http.llvm.org/bugs/>

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

Chandler Carruth <chandlerc at gmail.com> changed:

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

--- Comment #1 from Chandler Carruth <chandlerc at gmail.com> ---
Duping this to a newer bug as that bug had a slightly easier (for me) to track
down test case due to it being a generic mis-execution test that worked even on
x86.

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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130407/b440012b/attachment.html>

From bugzilla-daemon at llvm.org  Sun Apr  7 07:07:13 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 07 Apr 2013 14:07:13 +0000
Subject: [LLVMbugs] [Bug 15695] New: #pragma weak foo = bar and 'extern foo'
 are ambiguous
Message-ID: <bug-15695-206@http.llvm.org/bugs/>

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

            Bug ID: 15695
           Summary: #pragma weak foo = bar and 'extern foo' are ambiguous
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
          Assignee: unassignedclangbugs at nondot.org
          Reporter: gribozavr at gmail.com
                CC: llvmbugs at cs.uiuc.edu, rafael.espindola at gmail.com
    Classification: Unclassified

GCC 4.7.2 compiles the following program:

extern int PFoo(int);
#pragma weak PFoo = Foo
int Foo(int a) { return a; }
int main() {
  return PFoo(1);
}

while Clang emits an error:

$ clang weak.c
weak.c:5:8: error: call to 'PFoo' is ambiguous
return PFoo(1);
       ^~~~
weak.c:1:12: note: candidate function
extern int PFoo(int);
           ^
weak.c:2:14: note: candidate function
#pragma weak PFoo = Foo
             ^
1 error generated.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130407/28046e51/attachment.html>

From bugzilla-daemon at llvm.org  Sun Apr  7 07:11:53 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 07 Apr 2013 14:11:53 +0000
Subject: [LLVMbugs] [Bug 15693] crash-on-invalid: Assertion `Val && "isa<>
 used on a null pointer"'
In-Reply-To: <bug-15693-206@http.llvm.org/bugs/>
References: <bug-15693-206@http.llvm.org/bugs/>
Message-ID: <bug-15693-206-aQ4D068BV3@http.llvm.org/bugs/>

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

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

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

--- Comment #3 from Benjamin Kramer <benny.kra at gmail.com> ---
Fixed in r178975, thanks for the test case.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130407/7a1164f5/attachment.html>

From bugzilla-daemon at llvm.org  Sun Apr  7 12:27:08 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 07 Apr 2013 19:27:08 +0000
Subject: [LLVMbugs] [Bug 15696] New: Assertion failed: ((PtrVal & ((1 <<
 PtrTraits::NumLowBitsAvailable)-1)) == 0 && "Pointer is not sufficiently
 aligned"), function setPointer
Message-ID: <bug-15696-206@http.llvm.org/bugs/>

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

            Bug ID: 15696
           Summary: Assertion failed: ((PtrVal & ((1 <<
                    PtrTraits::NumLowBitsAvailable)-1)) == 0 && "Pointer
                    is not sufficiently aligned"), function setPointer
           Product: clang
           Version: 3.2
          Hardware: All
                OS: FreeBSD
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: rene at freebsd.org
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 10315
  --> http://llvm.org/bugs/attachment.cgi?id=10315&action=edit
test case

Hardware: Raspberry Pi B, 426MB memory allocated to FreeBSD

FreeBSD raspberrypi 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r249163M: Fri Apr  5
21:57:35 CEST 2013    
rene at clang:/usr/home/rene/rpi/obj/arm.armv6/usr/home/rene/rpi/src/sys/RPI-B-RENE
 arm

FreeBSD clang version 3.2 (tags/RELEASE_32/final 170710) 20121221
Target: armv6-unknown-freebsd10.0
Thread model: posix

% c++ -c test.cc -o /dev/null
test.cc:1:56: error: use of undeclared identifier 'locale'
  template<typename _CharT>     class collate : public locale::facet     {
                                                       ^
test.cc:1:64: error: expected class name
  template<typename _CharT>     class collate : public locale::facet     {
                                                               ^
Assertion failed: ((PtrVal & ((1 << PtrTraits::NumLowBitsAvailable)-1)) == 0 &&
"Pointer is not sufficiently aligned"), function setPointer, file
/usr/home/rene/rpi/src/lib/clang/libclangsema/../../../contrib/llvm/include/llvm/ADT/PointerIntPair.h,
line 80.
Stack dump:
0.    Program arguments: /usr/bin/c++ -cc1 -triple armv6-unknown-freebsd10.0 -S
-disable-free -main-file-name test.cc -mrelocation-model static
-mdisable-fp-elim -mconstructor-aliases -target-abi apcs-gnu -target-cpu
arm1136jf-s -msoft-float -mfloat-abi soft -target-feature +soft-float
-target-feature +soft-float-abi -target-feature -neon -momit-leaf-frame-pointer
-coverage-file /tmp/test-NQWono.s -resource-dir /usr/bin/../lib/clang/3.2
-fmodule-cache-path /var/tmp/clang-module-cache -fdeprecated-macro
-fno-dwarf-directory-asm -fdebug-compilation-dir /var/tmp -ferror-limit 19
-fmessage-length 80 -mstackrealign -fno-signed-char -fobjc-runtime=gnustep
-fcxx-exceptions -fexceptions -fsjlj-exceptions -fdiagnostics-show-option
-fcolor-diagnostics -o /tmp/test-NQWono.s -x c++ test.cc 
1.    test.cc:4:47: current parser token '_M_compare'
c++: error: unable to execute command: Abort trap (core dumped)
c++: error: clang frontend command failed due to signal (use -v to see
invocation)
FreeBSD clang version 3.2 (tags/RELEASE_32/final 170710) 20121221
Target: armv6-unknown-freebsd10.0
Thread model: posix
c++: note: diagnostic msg: PLEASE submit a bug report to http://llvm.org/bugs/
and include the crash backtrace, preprocessed source, and associated run
script.
c++: note: diagnostic msg: Error generating preprocessed source(s).
%

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130407/c3505e2b/attachment.html>

From bugzilla-daemon at llvm.org  Sun Apr  7 13:28:10 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 07 Apr 2013 20:28:10 +0000
Subject: [LLVMbugs] [Bug 15697] New: clang trunk 178973 freezes analyzing
	attached file
Message-ID: <bug-15697-206@http.llvm.org/bugs/>

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

            Bug ID: 15697
           Summary: clang trunk 178973 freezes analyzing attached file
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Static Analyzer
          Assignee: kremenek at apple.com
          Reporter: lbalbalba at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 10316
  --> http://llvm.org/bugs/attachment.cgi?id=10316&action=edit
pre-processed files that causes the hang

clang trunk 178973 freezes when analyzing attached file. reproduce with 

clang --analyze ./clang_hang.ii

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130407/a3d8ce4d/attachment.html>

From bugzilla-daemon at llvm.org  Sun Apr  7 14:38:17 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 07 Apr 2013 21:38:17 +0000
Subject: [LLVMbugs] [Bug 15698] New: Memory corruption bug in clang 3.2
Message-ID: <bug-15698-206@http.llvm.org/bugs/>

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

            Bug ID: 15698
           Summary: Memory corruption bug in clang 3.2
           Product: clang
           Version: 3.2
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: tiffany at stormbit.net
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 10317
  --> http://llvm.org/bugs/attachment.cgi?id=10317&action=edit
File from crash report

Steps to reproduce:

1: Download https://raw.github.com/troydhanson/uthash/master/src/uthash.h
2: Try to compile the following:

#include "uthash.h"

struct module {
    UT_hash_handle hh;
} *modules = NULL;

int main()
{
    struct module *mod1, *mod2;
    HASH_REPLACE_STR(modules, hh, mod1, mod2);
}

Output: 
$ clang test.c
test.c:10:35: error: passing 'UT_hash_handle' (aka 'struct UT_hash_handle') to
parameter of incompatible type 'const char *'
*** Error in `/usr/bin/clang': malloc(): memory corruption (fast):
0x0000000002831f40 ***

It produces no crash report in this shorter version. Here is the crash report
from when I discovered it: http://paste.strictfp.com/37342
log-aUMbnp.c is attached
log-aUMbnp.sh: /usr/bin/clang -cc1 -triple x86_64-unknown-linux-gnu -emit-obj
-mrelax-all -disable-free -disable-llvm-verifier -main-file-name log.c
-mrelocation-model pic -pic-level 2 -mdisable-fp-elim -fmath-errno
-masm-verbose -mconstructor-aliases -munwind-tables -fuse-init-array
-target-cpu x86-64 -target-linker-version 2.23.1 -momit-leaf-frame-pointer -g
-D "DEBUG" -D "_POSIX_C_SOURCE=200809" -Wall -pedantic -std=c99 -ferror-limit
19 -fmessage-length 134 -pthread -mstackrealign -fobjc-runtime=gcc
-fdiagnostics-show-option -x c log-aUMbnp.c

$ clang -v
clang version 3.2 (tags/RELEASE_32/final)
Target: x86_64-unknown-linux-gnu
Thread model: posix
$ uname -a
Linux arch 3.8.4-1-ARCH #1 SMP PREEMPT Wed Mar 20 22:10:25 CET 2013 x86_64
GNU/Linux

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130407/1ff6d991/attachment.html>

From bugzilla-daemon at llvm.org  Sun Apr  7 16:26:45 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 07 Apr 2013 23:26:45 +0000
Subject: [LLVMbugs] [Bug 15699] New: crash in or around call to
 std::chrono::steady_clock::now() when using precompiled header
Message-ID: <bug-15699-206@http.llvm.org/bugs/>

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

            Bug ID: 15699
           Summary: crash in or around call to
                    std::chrono::steady_clock::now() when using
                    precompiled header
           Product: clang
           Version: 3.2
          Hardware: HP
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++11
          Assignee: unassignedclangbugs at nondot.org
          Reporter: john at mcfarlane.name
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 10318
  --> http://llvm.org/bugs/attachment.cgi?id=10318&action=edit
as directed by diagnostic message

This crash occurs in a single source file out of a project of about 100 files.
I happens when I employ a CMake script
[https://code.google.com/p/crag/source/browse/PrecompiledHeader.cmake] intended
to get precompiled headers to work with GCC, and adapted with minimal expertise
to work with Clang 3.2. The system is a daily of Ubuntu 13.04 with clang 3.2
installed using apt-get.

The line referenced in the console output (below), app.cpp:243 is as follows:
    auto now = std::chrono::steady_clock::now();

And this code compiles fine when not using a PCH.
================================================================================
[  1%] Built target crag_gch
[  2%] Building CXX object CMakeFiles/crag.dir/src/core/app.cpp.o
0  libLLVM-3.2.so.1 0x00002aaaaba0ec0f
1  libLLVM-3.2.so.1 0x00002aaaaba0f079
2  libpthread.so.0  0x00002aaaac407bd0
3  clang            0x0000000000a651d0
clang::Sema::LookupSpecialMember(clang::CXXRecordDecl*,
clang::Sema::CXXSpecialMember, bool, bool, bool, bool, bool) + 1440
4  clang            0x0000000000a656e0
clang::Sema::LookupCopyingConstructor(clang::CXXRecordDecl*, unsigned int) + 48
5  clang            0x000000000098f133
6  clang            0x00000000009a5a63
clang::Sema::DeclareImplicitCopyConstructor(clang::CXXRecordDecl*) + 643
7  clang            0x0000000000a63d0b
clang::Sema::LookupConstructors(clang::CXXRecordDecl*) + 251
8  clang            0x0000000000a4cd9b
9  clang            0x0000000000a56773
clang::InitializationSequence::InitializationSequence(clang::Sema&,
clang::InitializedEntity const&, clang::InitializationKind const&,
clang::Expr**, unsigned int) + 2371
10 clang            0x000000000095ff54
clang::Sema::AddInitializerToDecl(clang::Decl*, clang::Expr*, bool, bool) +
1876
11 clang            0x000000000086777e
clang::Parser::ParseDeclarationAfterDeclaratorAndAttributes(clang::Declarator&,
clang::Parser::ParsedTemplateInfo const&) + 750
12 clang            0x000000000086ff4a
clang::Parser::ParseDeclGroup(clang::ParsingDeclSpec&, unsigned int, bool,
clang::SourceLocation*, clang::Parser::ForRangeInit*) + 442
13 clang            0x00000000008767cc
clang::Parser::ParseSimpleDeclaration(llvm::SmallVector<clang::Stmt*, 32u>&,
unsigned int, clang::SourceLocation&,
clang::Parser::ParsedAttributesWithRange&, bool, clang::Parser::ForRangeInit*)
+ 780
14 clang            0x00000000008769bf
clang::Parser::ParseDeclaration(llvm::SmallVector<clang::Stmt*, 32u>&, unsigned
int, clang::SourceLocation&, clang::Parser::ParsedAttributesWithRange&) + 207
15 clang            0x00000000008badb8
clang::Parser::ParseStatementOrDeclarationAfterAttributes(llvm::SmallVector<clang::Stmt*,
32u>&, bool, clang::SourceLocation*, clang::Parser::ParsedAttributesWithRange&)
+ 376
16 clang            0x00000000008bba5d
clang::Parser::ParseStatementOrDeclaration(llvm::SmallVector<clang::Stmt*,
32u>&, bool, clang::SourceLocation*) + 141
17 clang            0x00000000008b85b7
clang::Parser::ParseCompoundStatementBody(bool) + 1879
18 clang            0x00000000008c0652
clang::Parser::ParseFunctionStatementBody(clang::Decl*,
clang::Parser::ParseScope&) + 130
19 clang            0x0000000000862b45
clang::Parser::ParseFunctionDefinition(clang::ParsingDeclarator&,
clang::Parser::ParsedTemplateInfo const&, clang::Parser::LateParsedAttrList*) +
997
20 clang            0x0000000000870150
clang::Parser::ParseDeclGroup(clang::ParsingDeclSpec&, unsigned int, bool,
clang::SourceLocation*, clang::Parser::ForRangeInit*) + 960
21 clang            0x000000000085ebc4
clang::Parser::ParseDeclOrFunctionDefInternal(clang::Parser::ParsedAttributesWithRange&,
clang::ParsingDeclSpec&, clang::AccessSpecifier) + 228
22 clang            0x000000000085f381
23 clang            0x000000000085f3af
clang::Parser::ParseDeclarationOrFunctionDefinition(clang::Parser::ParsedAttributesWithRange&,
clang::ParsingDeclSpec*, clang::AccessSpecifier) + 31
24 clang            0x00000000008608a6
clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&,
clang::ParsingDeclSpec*) + 102
25 clang            0x000000000086152f
clang::Parser::ParseTopLevelDecl(clang::OpaquePtr<clang::DeclGroupRef>&) + 191
26 clang            0x0000000000859aeb clang::ParseAST(clang::Sema&, bool,
bool) + 267
27 clang            0x00000000005f50b1 clang::FrontendAction::Execute() + 97
28 clang            0x00000000005dc57a
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 282
29 clang            0x00000000005c5e92
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1378
30 clang            0x00000000005c0e88 cc1_main(char const**, char const**,
char const*, void*) + 1160
31 clang            0x00000000005bfd84 main + 7316
32 libc.so.6        0x00002aaaacb4fea5 __libc_start_main + 245
33 clang            0x00000000005c0889
Stack dump:
0.    Program arguments: /usr/bin/clang -cc1 -triple x86_64-pc-linux-gnu
-emit-obj -mrelax-all -disable-free -disable-llvm-verifier -main-file-name
app.cpp -mrelocation-model static -mdisable-fp-elim -fmath-errno -masm-verbose
-mconstructor-aliases -munwind-tables -fuse-init-array -target-cpu x86-64
-target-linker-version 2.23.1 -momit-leaf-frame-pointer -g -coverage-file
/home/john/Documents/crag/CMakeFiles/crag.dir/src/core/app.cpp.o -resource-dir
/usr/bin/../lib/clang/3.2 -include-pch pch.h.gch -D PROFILE -D __STRICT_ANSI__
-I /home/john/Documents/crag/src -I
/home/john/Documents/crag/dependencies/include -fmodule-cache-path
/var/tmp/clang-module-cache -internal-isystem
/usr/bin/../lib/gcc/x86_64-linux-gnu/4.7/../../../../include/c++/4.7
-internal-isystem
/usr/bin/../lib/gcc/x86_64-linux-gnu/4.7/../../../../include/c++/4.7/x86_64-linux-gnu
-internal-isystem
/usr/bin/../lib/gcc/x86_64-linux-gnu/4.7/../../../../include/c++/4.7/backward
-internal-isystem
/usr/bin/../lib/gcc/x86_64-linux-gnu/4.7/../../../../include/x86_64-linux-gnu/c++/4.7
-internal-isystem
/usr/bin/../lib/gcc/x86_64-linux-gnu/4.7/../../../../include/x86_64-linux-gnu/c++/4.7/x86_64-linux-gnu
-internal-isystem
/usr/bin/../lib/gcc/x86_64-linux-gnu/4.7/../../../../include/x86_64-linux-gnu/c++/4.7/backward
-internal-isystem
/usr/bin/../lib/gcc/x86_64-linux-gnu/4.7/../../../../include/x86_64-linux-gnu/c++/4.7
-internal-isystem
/usr/bin/../lib/gcc/x86_64-linux-gnu/4.7/../../../../include/x86_64-linux-gnu/c++/4.7/x86_64-linux-gnu
-internal-isystem
/usr/bin/../lib/gcc/x86_64-linux-gnu/4.7/../../../../include/x86_64-linux-gnu/c++/4.7/backward
-internal-isystem
/usr/bin/../lib/gcc/x86_64-linux-gnu/4.7/../../../../include/c++
-internal-isystem
/usr/bin/../lib/gcc/x86_64-linux-gnu/4.7/../../../../include/c++/x86_64-linux-gnu
-internal-isystem
/usr/bin/../lib/gcc/x86_64-linux-gnu/4.7/../../../../include/c++/backward
-internal-isystem /usr/local/include -internal-isystem
/usr/bin/../lib/clang/3.2/include -internal-isystem
/usr/include/clang/3.2/include/ -internal-externc-isystem
/usr/include/x86_64-linux-gnu -internal-externc-isystem
/usr/include/x86_64-linux-gnu -internal-externc-isystem /usr/include -Wall
-Wfatal-errors -Winvalid-pch -std=gnu++11 -fdeprecated-macro
-fdebug-compilation-dir /home/john/Documents/crag -ferror-limit 19
-fmessage-length 213 -pthread -mstackrealign -fno-rtti -fobjc-runtime=gcc
-fdiagnostics-show-option -fcolor-diagnostics -o
CMakeFiles/crag.dir/src/core/app.cpp.o -x c++
/home/john/Documents/crag/src/core/app.cpp 
1.    /home/john/Documents/crag/src/core/app.cpp:243:45: current parser token
';'
2.    /home/john/Documents/crag/src/core/app.cpp:242:1: parsing function body
'GetTime'
3.    /home/john/Documents/crag/src/core/app.cpp:242:1: in compound statement
('{}')
clang: fatal error: unable to execute command: Segmentation fault (core dumped)
Ubuntu clang version 3.2-1~exp5ubuntu2 (tags/RELEASE_32/final) (based on LLVM
3.2)
Target: x86_64-pc-linux-gnu
Thread model: posix
clang: note: diagnostic msg: 
********************

PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang: note: diagnostic msg: /tmp/app-zWOsZa.cpp
clang: note: diagnostic msg: /tmp/app-zWOsZa.sh
clang: note: diagnostic msg: 

********************
make[2]: *** [CMakeFiles/crag.dir/src/core/app.cpp.o] Error 254
make[1]: *** [CMakeFiles/crag.dir/all] Error 2
make: *** [all] Error 2
================================================================================
Contents of /tmp/app-zWOsZa.sh as requested by diagnostic message:
/usr/bin/clang -cc1 -triple x86_64-pc-linux-gnu -emit-obj -mrelax-all
-disable-free -disable-llvm-verifier -main-file-name app.cpp -mrelocation-model
static -mdisable-fp-elim -fmath-errno -masm-verbose -mconstructor-aliases
-munwind-tables -fuse-init-array -target-cpu x86-64 -target-linker-version
2.23.1 -momit-leaf-frame-pointer -g -D "PROFILE" -D "__STRICT_ANSI__" -Wall
-Wfatal-errors -Winvalid-pch -std=gnu++11 -fdeprecated-macro -ferror-limit 19
-fmessage-length 213 -pthread -mstackrealign -fno-rtti -fobjc-runtime=gcc
-fdiagnostics-show-option -fcolor-diagnostics -x c++ app-zWOsZa.cpp

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130407/05659a80/attachment.html>

From bugzilla-daemon at llvm.org  Mon Apr  8 01:54:58 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 08 Apr 2013 08:54:58 +0000
Subject: [LLVMbugs] [Bug 15700] New: Assertion failure '!isImplicitAccess()'
 involving decltype and default function template arguments
Message-ID: <bug-15700-206@http.llvm.org/bugs/>

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

            Bug ID: 15700
           Summary: Assertion failure '!isImplicitAccess()' involving
                    decltype and default function template arguments
           Product: clang
           Version: trunk
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++11
          Assignee: unassignedclangbugs at nondot.org
          Reporter: zeratul976 at hotmail.com
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified

For the following code:


struct S
{
    template <typename T, typename U = int>
    U foo_impl(T);

    template <typename T>
    auto foo(T t) -> decltype(foo_impl(t));
};

int main()
{
    S s;
    s.foo(0);
}


with clang r178972 I get the following assertion failure:


clang: llvm/tools/clang/lib/AST/../../include/clang/AST/ExprCXX.h:3227: const
clang::Expr *clang::UnresolvedMemberExpr::getBase() const: Assertion
`!isImplicitAccess()' failed.
0  clang           0x0000000001e903d5 llvm::sys::PrintStackTrace(_IO_FILE*) +
37
1  clang           0x0000000001e908c3
2  libpthread.so.0 0x00007f398af678f0
3  libc.so.6       0x00007f398a05ab25 gsignal + 53
4  libc.so.6       0x00007f398a05e670 abort + 384
5  libc.so.6       0x00007f398a0539f1 __assert_fail + 241
6  clang           0x00000000011b77ed
7  clang           0x00000000011b7dc5
8  clang           0x00000000011b3211
9  clang           0x00000000011bb55d
10 clang           0x00000000011ae0bd
11 clang           0x000000000081ec8f
clang::CodeGen::CodeGenModule::getMangledName(clang::GlobalDecl) + 751
12 clang           0x0000000000823a3b
clang::CodeGen::CodeGenModule::GetAddrOfFunction(clang::GlobalDecl,
llvm::Type*, bool) + 75
13 clang           0x00000000008c7105
clang::CodeGen::CodeGenFunction::EmitCXXMemberCallExpr(clang::CXXMemberCallExpr
const*, clang::CodeGen::ReturnValueSlot) + 1413
14 clang           0x00000000008bb6e6
clang::CodeGen::CodeGenFunction::EmitCallExpr(clang::CallExpr const*,
clang::CodeGen::ReturnValueSlot) + 262
15 clang           0x00000000008ea148
16 clang           0x00000000008e3d1d
17 clang           0x00000000008dcbfd
clang::CodeGen::CodeGenFunction::EmitScalarExpr(clang::Expr const*, bool) + 93
18 clang           0x00000000008aad29
clang::CodeGen::CodeGenFunction::EmitAnyExpr(clang::Expr const*,
clang::CodeGen::AggValueSlot, bool) + 249
19 clang           0x00000000008aac29
clang::CodeGen::CodeGenFunction::EmitIgnoredExpr(clang::Expr const*) + 57
20 clang           0x000000000093a177
clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*) + 343
21 clang           0x000000000093fd8b
clang::CodeGen::CodeGenFunction::EmitCompoundStmtWithoutScope(clang::CompoundStmt
const&, bool, clang::CodeGen::AggValueSlot) + 91
22 clang           0x0000000000817eb9
clang::CodeGen::CodeGenFunction::GenerateCode(clang::GlobalDecl,
llvm::Function*, clang::CodeGen::CGFunctionInfo const&) + 713
23 clang           0x0000000000822f27
clang::CodeGen::CodeGenModule::EmitGlobalFunctionDefinition(clang::GlobalDecl)
+ 663
24 clang           0x0000000000820284
clang::CodeGen::CodeGenModule::EmitGlobalDefinition(clang::GlobalDecl) + 228
25 clang           0x000000000082235d
clang::CodeGen::CodeGenModule::EmitGlobal(clang::GlobalDecl) + 781
26 clang           0x00000000008255b5
clang::CodeGen::CodeGenModule::EmitTopLevelDecl(clang::Decl*) + 1173
27 clang           0x000000000080cb3f
28 clang           0x000000000080bfd7
29 clang           0x0000000000959253 clang::ParseAST(clang::Sema&, bool, bool)
+ 435
30 clang           0x000000000080b5a2 clang::CodeGenAction::ExecuteAction() +
194
31 clang           0x0000000000692c81 clang::FrontendAction::Execute() + 113
32 clang           0x000000000067293d
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 909
33 clang           0x00000000006594f7
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 3031
34 clang           0x000000000064f615 cc1_main(char const**, char const**, char
const*, void*) + 693
35 clang           0x00000000006564f1 main + 8609
36 libc.so.6       0x00007f398a045c4d __libc_start_main + 253
37 clang           0x000000000064f229
Stack dump:
0.      Program arguments: /home/nr/Programs/clang/clang-3.3-20130406/bin/clang
-cc1 -triple x86_64-unknown-linux-gnu -emit-obj -mrelax-all -disable-free
-main-file-name test2.cpp -mrelocation-model static -mdisable-fp-elim
-fmath-errno -masm-verbose -mconstructor-aliases -munwind-tables
-fuse-init-array -target-cpu x86-64 -target-linker-version 2.20.1
-coverage-file /home/nr/Dev/Projects/C++/test/test.o -resource-dir
/home/nr/Programs/clang/clang-3.3-20130406/bin/../lib/clang/3.3
-internal-isystem
/home/nr/Programs/gcc/gcc-4.8.0/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../include/c++/4.8.0
-internal-isystem
/home/nr/Programs/gcc/gcc-4.8.0/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../include/c++/4.8.0/x86_64-unknown-linux-gnu
-internal-isystem
/home/nr/Programs/gcc/gcc-4.8.0/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../include/c++/4.8.0/backward
-internal-isystem
/home/nr/Programs/gcc/gcc-4.8.0/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../include/x86_64-unknown-linux-gnu/c++/4.8.0
-internal-isystem /usr/local/include -internal-isystem
/home/nr/Programs/clang/clang-3.3-20130406/bin/../lib/clang/3.3/include
-internal-externc-isystem /include -internal-externc-isystem /usr/include
-std=c++11 -fdeprecated-macro -fdebug-compilation-dir
/home/nr/Dev/Projects/C++/test -ferror-limit 19 -fmessage-length 0
-mstackrealign -fobjc-runtime=gcc -fobjc-default-synthesize-properties
-fcxx-exceptions -fexceptions -fdiagnostics-show-option -backend-option
-vectorize-loops -o test.o -x c++ src/test.cpp
1.      <eof> parser at end of file
2.      src/test2.cpp:10:5: LLVM IR generation of declaration 'main'
3.      src/test2.cpp:10:5: Generating code for declaration 'main'
4.      src/test2.cpp:7:10: Mangling declaration 'S::foo'
clang: error: unable to execute command: Aborted
clang: error: clang frontend command failed due to signal (use -v to see
invocation)
clang version 3.3 (trunk 178972)
Target: x86_64-unknown-linux-gnu
Thread model: posix

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130408/2fe3f79f/attachment.html>

From bugzilla-daemon at llvm.org  Mon Apr  8 05:46:02 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 08 Apr 2013 12:46:02 +0000
Subject: [LLVMbugs] [Bug 15701] New: Clang fails to compile a program which
 calls inline function present in a header file
Message-ID: <bug-15701-206@http.llvm.org/bugs/>

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

            Bug ID: 15701
           Summary: Clang fails to compile a program which calls inline
                    function present in a header file
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: assie181 at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

✗ cat check.h
inline void fun(int x) {
}

✗ cat check.c
#include "check.h"

int main(int argc, char **argv)
{
    fun(10);
    return 0;
}

✗ /usr/local/bin/clang check.c 
/tmp/check-UthCL9.o: In function `main':
check.c:(.text+0x1e): undefined reference to `fun'
clang: error: linker command failed with exit code 1 (use -v to see invocation)

 ✗ /usr/local/bin/clang -v
clang version 3.3 (http://llvm.org/git/clang.git
efac8da4cfa49799d5fdbc9d10b0e9f9a53ff6c8) (http://llvm.org/git/llvm.git
59889f7f496f549965764820a0150c4068c02f5b)
Target: x86_64-unknown-linux-gnu
Thread model: posix

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130408/eae91d22/attachment.html>

From bugzilla-daemon at llvm.org  Mon Apr  8 06:15:58 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 08 Apr 2013 13:15:58 +0000
Subject: [LLVMbugs] [Bug 15701] Clang fails to compile a program which calls
 inline function present in a header file
In-Reply-To: <bug-15701-206@http.llvm.org/bugs/>
References: <bug-15701-206@http.llvm.org/bugs/>
Message-ID: <bug-15701-206-YyAHTq3nj9@http.llvm.org/bugs/>

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

Hans Wennborg <hans at chromium.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |hans at chromium.org
         Resolution|---                         |INVALID

--- Comment #3 from Hans Wennborg <hans at chromium.org> ---
Right, this is http://clang.llvm.org/compatibility.html#inline

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130408/7097645e/attachment.html>

From bugzilla-daemon at llvm.org  Mon Apr  8 10:30:58 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 08 Apr 2013 17:30:58 +0000
Subject: [LLVMbugs] [Bug 10942] clang/analyzer hangs when compiling php 5.3.8
In-Reply-To: <bug-10942-206@http.llvm.org/bugs/>
References: <bug-10942-206@http.llvm.org/bugs/>
Message-ID: <bug-10942-206-NWRukHm0kc@http.llvm.org/bugs/>

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

John Smith <lbalbalba at gmail.com> changed:

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

--- Comment #3 from John Smith <lbalbalba at gmail.com> ---
Tested again with clang version 3.3 (trunk 178973). It still takes a while, but
there is no longer a 'freeze' or hang (if there ever was one to begin with).

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130408/2d4c66e1/attachment.html>

From bugzilla-daemon at llvm.org  Mon Apr  8 10:53:59 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 08 Apr 2013 17:53:59 +0000
Subject: [LLVMbugs] [Bug 15702] New: Address sanitizer: setrlimit() fails
Message-ID: <bug-15702-206@http.llvm.org/bugs/>

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

            Bug ID: 15702
           Summary: Address sanitizer: setrlimit() fails
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: martin at infinio.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

The following code:

#include <sys/resource.h>
#include <stdio.h>
#include <errno.h>
#include <string.h>

int main()
{
    struct rlimit r;
    r.rlim_cur = RLIM_INFINITY;
    r.rlim_max = RLIM_INFINITY;
    int ret = setrlimit(RLIMIT_CORE, &r);
    fprintf(stderr, "ret: %d, errno: %d, message: %s\n", ret, errno,
strerror(errno));
    return 0;
}

Fails with EPERM when run with the address sanitizer:

$ clang -fsanitize=address ./setrlimit.c && ./a.out
ret: -1, errno: 1, message: Operation not permitted

But fine when run without:

$ clang ./setrlimit.c && ./a.out
ret: 0, errno: 0, message: Success

Trunk from today:

clang version 3.3 (179025)
Target: x86_64-unknown-linux-gnu
Thread model: posix

On Ubuntu 12.10.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130408/4683fd70/attachment.html>

From bugzilla-daemon at llvm.org  Mon Apr  8 11:52:57 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 08 Apr 2013 18:52:57 +0000
Subject: [LLVMbugs] [Bug 13865] Interprocedural analysis false positive
In-Reply-To: <bug-13865-206@http.llvm.org/bugs/>
References: <bug-13865-206@http.llvm.org/bugs/>
Message-ID: <bug-13865-206-gYt1oaqbKR@http.llvm.org/bugs/>

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

Jordan Rose <jordan_rose at apple.com> changed:

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

--- Comment #7 from Jordan Rose <jordan_rose at apple.com> ---
Destructor inlining has been turned on in r178805, which allows us to inline
the constructor with confidence, which makes the warning go away.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130408/7bdffee6/attachment.html>

From bugzilla-daemon at llvm.org  Mon Apr  8 13:23:38 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 08 Apr 2013 20:23:38 +0000
Subject: [LLVMbugs] [Bug 14877] Changing unrelated code changes emitted
 garbage value warning
In-Reply-To: <bug-14877-206@http.llvm.org/bugs/>
References: <bug-14877-206@http.llvm.org/bugs/>
Message-ID: <bug-14877-206-lGnKAIqoUT@http.llvm.org/bugs/>

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

Jordan Rose <jordan_rose at apple.com> changed:

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

--- Comment #5 from Jordan Rose <jordan_rose at apple.com> ---
Oops, Anna fixed this in r177905.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130408/91061dae/attachment.html>

From bugzilla-daemon at llvm.org  Mon Apr  8 13:31:21 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 08 Apr 2013 20:31:21 +0000
Subject: [LLVMbugs] [Bug 14330] Clang does not pass the GDB 7.5 test suite
In-Reply-To: <bug-14330-206@http.llvm.org/bugs/>
References: <bug-14330-206@http.llvm.org/bugs/>
Message-ID: <bug-14330-206-sza0IJdZC0@http.llvm.org/bugs/>

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

Bug 14330 depends on bug 14511, which changed state.

Bug 14511 Summary: -O0 default of omitting frame pointers degrades debuggability of code
http://llvm.org/bugs/show_bug.cgi?id=14511

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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130408/0665c18f/attachment.html>

From bugzilla-daemon at llvm.org  Mon Apr  8 13:31:19 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 08 Apr 2013 20:31:19 +0000
Subject: [LLVMbugs] [Bug 14511] -O0 default of omitting frame pointers
 degrades debuggability of code
In-Reply-To: <bug-14511-206@http.llvm.org/bugs/>
References: <bug-14511-206@http.llvm.org/bugs/>
Message-ID: <bug-14511-206-OFhyqDXBog@http.llvm.org/bugs/>

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

Eric Christopher <echristo at gmail.com> changed:

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

--- Comment #2 from Eric Christopher <echristo at gmail.com> ---
I've fixed this.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130408/b32e1d81/attachment.html>

From bugzilla-daemon at llvm.org  Mon Apr  8 14:15:08 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 08 Apr 2013 21:15:08 +0000
Subject: [LLVMbugs] [Bug 15634] Diagnostic for failed template deduction is
	insufficient
In-Reply-To: <bug-15634-206@http.llvm.org/bugs/>
References: <bug-15634-206@http.llvm.org/bugs/>
Message-ID: <bug-15634-206-TBMlt0x0oh@http.llvm.org/bugs/>

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

rtrieu at google.com changed:

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

--- Comment #3 from rtrieu at google.com ---
r179056 fixes this.  From my given example, the improved error message is

note: candidate template ignored: could not match 'NS2::array' against
'NS1::array'

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130408/aa434319/attachment.html>

From bugzilla-daemon at llvm.org  Mon Apr  8 14:53:00 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 08 Apr 2013 21:53:00 +0000
Subject: [LLVMbugs] [Bug 15703] New: clang-analyzer 273 crash with CPP file
Message-ID: <bug-15703-206@http.llvm.org/bugs/>

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

            Bug ID: 15703
           Summary: clang-analyzer 273 crash with CPP file
           Product: clang
           Version: trunk
          Hardware: Macintosh
                OS: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: Static Analyzer
          Assignee: kremenek at apple.com
          Reporter: puurtuur at me.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 10323
  --> http://llvm.org/bugs/attachment.cgi?id=10323&action=edit
Xcode Transcript (invocation and stacktrace)

I'm running the new v273 analyser in Xcode and got 2 distinct problems, this is
the first. A failed assert. See 3 attached files.

Snip from first file for context:

Assertion failed: (T->isIntegerType() || Loc::isLocType(T)), function
getAPSIntType, file
/Volumes/Data/Users/kremenek/checker-build/checker-273-src/tools/clang/include/clang/StaticAnalyzer/Core/PathSensitive/BasicValueFactory.h,
line 96.0
clang             0x000000010092fe48 llvm::sys::PrintStackTrace(__sFILE*) + 401
clang             0x00000001009303b4 SignalHandler(int) + 5642
libsystem_c.dylib 0x00007fff8f5cf94a _sigtramp + 263
libsystem_c.dylib 000000000000000000 _sigtramp + 18897323044
clang             0x0000000100930166 abort + 225
clang             0x0000000100930141 __assert_rtn + 816
clang             0x0000000101529e92
clang::ento::BasicValueFactory::getAPSIntType(clang::QualType) const + 3387
clang             0x00000001015425e2
clang::ento::SimpleConstraintManager::assumeSymRel(llvm::IntrusiveRefCntPtr<clang::ento::ProgramState
const>, clang::ento::SymExpr const*, clang::BinaryOperatorKind, llvm::APSInt
const&) + 988
clang             0x000000010154235a
clang::ento::SimpleConstraintManager::assumeAux(llvm::IntrusiveRefCntPtr<clang::ento::ProgramState
const>, clang::ento::NonLoc, bool) + 14669
clang             0x00000001015419a5
clang::ento::SimpleConstraintManager::assume(llvm::IntrusiveRefCntPtr<clang::ento::ProgramState
const>, clang::ento::NonLoc, bool) + 8510
clang             0x00000001015418ca
clang::ento::SimpleConstraintManager::assume(llvm::IntrusiveRefCntPtr<clang::ento::ProgramState
const>, clang::ento::DefinedSVal, bool) + 9011
clang             0x00000001014f7d24
clang::ento::ConstraintManager::assumeDual(llvm::IntrusiveRefCntPtr<clang::ento::ProgramState
const>, clang::ento::DefinedSVal) + 8412
clang             0x00000001014f3592
clang::ento::ProgramState::assume(clang::ento::DefinedOrUnknownSVal) const +
11413
clang             0x00000001014ee5f1
clang::ento::ExprEngine::evalEagerlyAssumeBinOpBifurcation(clang::ento::ExplodedNodeSet&,
clang::ento::ExplodedNodeSet&, clang::Expr const*) + 40114
clang             0x00000001014ecb22 clang::ento::ExprEngine::Visit(clang::Stmt
const*, clang::ento::ExplodedNode*, clang::ento::ExplodedNodeSet&) + 822615
clang             0x00000001014e94b9
clang::ento::ExprEngine::ProcessStmt(clang::CFGStmt,
clang::ento::ExplodedNode*) + 80916
clang             0x00000001014e0209
clang::ento::CoreEngine::HandlePostStmt(clang::CFGBlock const*, unsigned int,
clang::ento::ExplodedNode*) + 13717
clang             0x00000001014dfc75
clang::ento::CoreEngine::dispatchWorkItem(clang::ento::ExplodedNode*,
clang::ProgramPoint, clang::ento::WorkListUnit const&) + 38918
...etc

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130408/86566e93/attachment.html>

From bugzilla-daemon at llvm.org  Mon Apr  8 15:07:39 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 08 Apr 2013 22:07:39 +0000
Subject: [LLVMbugs] =?utf-8?q?=5BExecutable_Attachment_Removed=5D_=5BBug_1?=
 =?utf-8?q?5704=5D_New=3A_clang-analyzer_273_in_xcode_error_diagnostic_cau?=
 =?utf-8?q?ses_failure?=
Message-ID: <bug-15704-206@http.llvm.org/bugs/>

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

            Bug ID: 15704
           Summary: clang-analyzer 273 in xcode error diagnostic causes
                    failure
           Product: clang
           Version: trunk
          Hardware: Macintosh
                OS: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: Static Analyzer
          Assignee: kremenek at apple.com
          Reporter: puurtuur at me.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

I'm testing the new clang-analyzer v273 under Xcode and got 2 problems. This is
the second.

Xcode just reports the standard "Analyzer skipped this file due to parse
errors" with sub-error:

type 'float' cannot be narrowed to 'Uint8' (aka 'unsigned char') in initializer
list
This file compiles normally under Xcode 4.6.1's clang. It seems to generate an
actual error diagnostic, likely a compiler change, but the error causes the
analysis to fail and it does not generate a diagnostic in Xcode. It does not
crash however.

So I'm not sure if this is a clang problem or an Xcode integration issue, but
it doesn't work either way.

Full Xcode transcript follows:

Analyze Quadrae/GameView.cpp
    cd /Users/arthur/Documents/Creations/Quadrae
    setenv LANG en_US.US-ASCII
    /Users/arthur/Documents/Common/checker-273/bin/clang -x c++ -arch x86_64
-fmessage-length=0 -std=gnu++11 -stdlib=libc++ -Wno-trigraphs -fpascal-strings
-O0 -Wno-missing-field-initializers -Wno-missing-prototypes -Wreturn-type
-Wnon-virtual-dtor -Woverloaded-virtual -Wno-exit-time-destructors -Wformat
-Wno-missing-braces -Wparentheses -Wswitch -Wno-unused-function
-Wno-unused-label -Wno-unused-parameter -Wunused-variable -Wunused-value
-Wempty-body -Wuninitialized -Wno-unknown-pragmas -Wshadow
-Wno-four-char-constants -Wno-conversion -Wconstant-conversion -Wint-conversion
-Wenum-conversion -Wshorten-64-to-32 -Wno-newline-eof -Wno-c++11-extensions
-DDEBUG=1 -isysroot
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk
-fasm-blocks -fstrict-aliasing -Wdeprecated-declarations -Winvalid-offsetof
-mmacosx-version-min=10.8 -g -fvisibility-inlines-hidden -Wno-sign-conversion
-Xclang -analyzer-output=plist-multi-file -Xclang -analyzer-checker -Xclang
security.FloatLoopCounter -Xclang -analyzer-checker -Xclang
security.insecureAPI.UncheckedReturn -Xclang -analyzer-checker -Xclang
security.insecureAPI.getpw -Xclang -analyzer-checker -Xclang
security.insecureAPI.gets -Xclang -analyzer-checker -Xclang
security.insecureAPI.mkstemp -Xclang -analyzer-checker -Xclang
security.insecureAPI.mktemp -Xclang -analyzer-checker -Xclang
security.insecureAPI.rand -Xclang -analyzer-checker -Xclang
security.insecureAPI.strcpy -Xclang -analyzer-checker -Xclang
security.insecureAPI.vfork -iquote
/Users/arthur/Library/Developer/Xcode/DerivedData/Quadrae-abgauznybbsogscxhysxkrhbnxdw/Build/Intermediates/Quadrae.build/Debug/QuadraeBundle.build/QuadraeBundle-generated-files.hmap
-I/Users/arthur/Library/Developer/Xcode/DerivedData/Quadrae-abgauznybbsogscxhysxkrhbnxdw/Build/Intermediates/Quadrae.build/Debug/QuadraeBundle.build/QuadraeBundle-own-target-headers.hmap
-I/Users/arthur/Library/Developer/Xcode/DerivedData/Quadrae-abgauznybbsogscxhysxkrhbnxdw/Build/Intermediates/Quadrae.build/Debug/QuadraeBundle.build/QuadraeBundle-all-target-headers.hmap
-iquote
/Users/arthur/Library/Developer/Xcode/DerivedData/Quadrae-abgauznybbsogscxhysxkrhbnxdw/Build/Intermediates/Quadrae.build/Debug/QuadraeBundle.build/QuadraeBundle-project-headers.hmap
-I/Users/arthur/Library/Developer/Xcode/DerivedData/Quadrae-abgauznybbsogscxhysxkrhbnxdw/Build/Products/Debug/include
-I/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include
-I/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include
-I/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include
-I/Users/arthur/Library/Developer/Xcode/DerivedData/Quadrae-abgauznybbsogscxhysxkrhbnxdw/Build/Intermediates/Quadrae.build/Debug/QuadraeBundle.build/DerivedSources/x86_64
-I/Users/arthur/Library/Developer/Xcode/DerivedData/Quadrae-abgauznybbsogscxhysxkrhbnxdw/Build/Intermediates/Quadrae.build/Debug/QuadraeBundle.build/DerivedSources
-Weverything -Wno-c++98-compat -Wno-c++98-compat-pedantic -Wno-padded
-Wno-documentation -Wno-global-constructors
-F/Users/arthur/Library/Developer/Xcode/DerivedData/Quadrae-abgauznybbsogscxhysxkrhbnxdw/Build/Products/Debug
-F/Users/arthur/Documents/Creations/Quadrae/../../../Library/Frameworks -MMD
-MT dependencies -MF
/Users/arthur/Library/Developer/Xcode/DerivedData/Quadrae-abgauznybbsogscxhysxkrhbnxdw/Build/Intermediates/Quadrae.build/Debug/QuadraeBundle.build/StaticAnalyzer/Quadrae/QuadraeBundle/normal/x86_64/GameView.d
--analyze /Users/arthur/Documents/Creations/Quadrae/Quadrae/GameView.cpp -o
/Users/arthur/Library/Developer/Xcode/DerivedData/Quadrae-abgauznybbsogscxhysxkrhbnxdw/Build/Intermediates/Quadrae.build/Debug/QuadraeBundle.build/StaticAnalyzer/Quadrae/QuadraeBundle/normal/x86_64/GameView.plist
/Users/arthur/Documents/Creations/Quadrae/Quadrae/GameView.cpp:90:78: error:
type 'float' cannot be narrowed to 'Uint8' (aka 'unsigned char') in initializer
list [-Wc++11-narrowing]
        auto border = sf::Shape::Rectangle(24, 24, 24 + 240, 24 + 480, {
142,131,0, 255 * (1.0f - progress) });
                                                                               
    ^~~~~~~~~~~~~~~~~~~~~~~
/Users/arthur/Documents/Creations/Quadrae/Quadrae/GameView.cpp:90:78: note:
override this message by inserting an explicit cast
        auto border = sf::Shape::Rectangle(24, 24, 24 + 240, 24 + 480, {
142,131,0, 255 * (1.0f - progress) });
                                                                               
    ^~~~~~~~~~~~~~~~~~~~~~~
                                                                               
    static_cast<Uint8>(    )

-- 
You are receiving this mail because:
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Mon Apr  8 15:10:19 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 08 Apr 2013 22:10:19 +0000
Subject: [LLVMbugs] [Executable Attachment Removed] [Bug 15705] New:
 Unneeded register-register move emitted for x86_64
Message-ID: <bug-15705-206@http.llvm.org/bugs/>

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

            Bug ID: 15705
           Summary: Unneeded register-register move emitted for x86_64
           Product: new-bugs
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: david.majnemer at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Using r179060, the following ll code generates an extra mov instruction:

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-apple-macosx10.8.0"

define i32 @fun(i32 %x, i32 %a, i32 %b, i32 %c) #0 {
entry:
  %cmp = icmp eq i32 %x, %a
  br i1 %cmp, label %return, label %if.end

if.end:                                           ; preds = %entry
  %cmp1 = icmp eq i32 %x, %b
  %c.a = select i1 %cmp1, i32 %c, i32 %a
  br label %return

return:                                           ; preds = %if.end, %entry
  %retval.0 = phi i32 [ %b, %entry ], [ %c.a, %if.end ]
  ret i32 %retval.0
}

attributes #0 = { nounwind readnone ssp "less-precise-fpmad"="false"
"no-frame-pointer-elim"="false" "no-frame-pointer-elim-non-leaf"="false"
"no-infs-fp-math"="false" "no-nans-fp-math"="false" "unsafe-fp-math"="false"
"use-soft-float"="false" }

generates:
## BB#0:                                ## %entry
    cmpl    %esi, %edi
    jne    LBB0_2
## BB#1:
    movl    %edx, %esi
    movl    %esi, %eax
    ret
LBB0_2:                                 ## %if.end
    cmpl    %edx, %edi
    cmovel    %ecx, %esi
    movl    %esi, %eax
    ret


Note the sequence in BB#1
edx -> esi, esi-> eax could just be edx -> eax

-- 
You are receiving this mail because:
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Mon Apr  8 18:11:07 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 09 Apr 2013 01:11:07 +0000
Subject: [LLVMbugs] [Bug 15706] New: Multiple escaped newline between the */
 characters are not handled correctly
Message-ID: <bug-15706-206@http.llvm.org/bugs/>

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

            Bug ID: 15706
           Summary: Multiple escaped newline between the */ characters are
                    not handled correctly
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
          Assignee: unassignedclangbugs at nondot.org
          Reporter: ruiu at google.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Clang recognize only one escaped newline between the */ characters of a block
comment. So it handles (A) correctly, but can't parse (B).

(A)

/**\
/

(b)

/**\
\
/

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130409/235c2756/attachment.html>

From bugzilla-daemon at llvm.org  Mon Apr  8 21:27:17 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 09 Apr 2013 04:27:17 +0000
Subject: [LLVMbugs] [Bug 15707] New: StackColoring can wrongly merge stack
 slots due to incorrect liveness calculation
Message-ID: <bug-15707-206@http.llvm.org/bugs/>

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

            Bug ID: 15707
           Summary: StackColoring can wrongly merge stack slots due to
                    incorrect liveness calculation
           Product: tools
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: llc
          Assignee: unassignedbugs at nondot.org
          Reporter: mseaborn at chromium.org
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

StackColoring::calculateLiveIntervals() does not correctly handle the case
where the following sequence occurs in a basic block:

  llvm.lifetime.start(%buf)
  ...
  llvm.lifetime.end(%buf)
  ...
  llvm.lifetime.start(%buf)

calculateLiveIntervals() ignores the second lifetime.start() and regards %buf
as not being live after the lifetime.end().  This will cause StackColoring to
merge stack slots that shouldn't be merged.


Example:

declare void @llvm.lifetime.start(i64, i8*)
declare void @llvm.lifetime.end(i64, i8*)

declare void @ext(i8*)

define void @foo() {
  %buf1 = alloca i8, i32 10000, align 16
  %buf2 = alloca i8, i32 10000, align 16

  call void @llvm.lifetime.start(i64 -1, i8* %buf1)
  call void @llvm.lifetime.end(i64 -1, i8* %buf1)

  call void @llvm.lifetime.start(i64 -1, i8* %buf1)
  call void @llvm.lifetime.start(i64 -1, i8* %buf2)
  call void @ext(i8* %buf1)
  call void @ext(i8* %buf2)
  ret void
}


Expected output:

$ llc -mtriple=x86_64-none-gnu llvm_lifetime_bug.ll -O1 -o -
...
    subq    $20008, %rsp            # imm = 0x4E28
.Ltmp1:
    .cfi_def_cfa_offset 20016
    leaq    10000(%rsp), %rdi
    callq    ext
    leaq    (%rsp), %rdi
    callq    ext
    addq    $20008, %rsp            # imm = 0x4E28
    ret

Actual output:

$ llc -mtriple=x86_64-none-gnu llvm_lifetime_bug.ll -O1 -o -
...
    subq    $10008, %rsp            # imm = 0x2718
.Ltmp1:
    .cfi_def_cfa_offset 10016
    leaq    (%rsp), %rdi
    callq    ext
    leaq    (%rsp), %rdi
    callq    ext
    addq    $10008, %rsp            # imm = 0x2718
    ret


The following change fixes the bug:

@@ -434,10 +446,8 @@ void StackColoring::calculateLiveIntervals(unsigned
NumSlots) {
     if (Alive.any()) {
       for (int pos = Alive.find_first(); pos != -1;
            pos = Alive.find_next(pos)) {
-        if (!Starts[pos].isValid())
-          Starts[pos] = Indexes->getMBBStartIdx(MBB);
-        if (!Finishes[pos].isValid())
-          Finishes[pos] = Indexes->getMBBEndIdx(MBB);
+        Starts[pos] = Indexes->getMBBStartIdx(MBB);
+        Finishes[pos] = Indexes->getMBBEndIdx(MBB);
       }
     }

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130409/2cf30dd4/attachment.html>

From bugzilla-daemon at llvm.org  Mon Apr  8 21:28:58 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 09 Apr 2013 04:28:58 +0000
Subject: [LLVMbugs] [Bug 15708] New: malloc(0) is not undefined behaviour
Message-ID: <bug-15708-206@http.llvm.org/bugs/>

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

            Bug ID: 15708
           Summary: malloc(0) is not undefined behaviour
           Product: clang
           Version: unspecified
          Hardware: PC
                OS: FreeBSD
            Status: NEW
          Severity: normal
          Priority: P
         Component: Static Analyzer
          Assignee: kremenek at apple.com
          Reporter: cperciva at freebsd.org
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

When encountering a possible malloc(0), the clang analyzer reports a "Undefined
allocation of 0 bytes (CERT MEM04-C; CWE-131)" bug.  This text is wrong, since
malloc(0) is not *undefined*; rather, it is *implementation-defined*.

A global s/Undefined allocation/Implementation-defined allocation/ in the
clang-analyzer source code should fix this.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130409/1ca8c722/attachment.html>

From bugzilla-daemon at llvm.org  Mon Apr  8 21:38:13 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 09 Apr 2013 04:38:13 +0000
Subject: [LLVMbugs] [Bug 15709] New: incorrect recovery after -> versus .
 correction for template name
Message-ID: <bug-15709-206@http.llvm.org/bugs/>

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

            Bug ID: 15709
           Summary: incorrect recovery after -> versus . correction for
                    template name
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
          Assignee: unassignedclangbugs at nondot.org
          Reporter: richard-llvm at metafoo.co.uk
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified

lib/Sema/SemaDeclCXX.cpp:7712:24: error: no member named 'castAs' in
'clang::QualType'; did
 you mean to use '->' instead of '.'?
    return Map[CtorType.castAs<FunctionProtoType>()].getEntry(SemaRef, Ctor);
                       ^
                       ->
lib/Sema/SemaDeclCXX.cpp:7712:32: error: 'FunctionProtoType' does not refer to
a value
    return Map[CtorType.castAs<FunctionProtoType>()].getEntry(SemaRef, Ctor);
                               ^
include/clang/Sema/Sema.h:105:9: note: declared here
  class FunctionProtoType;
        ^
lib/Sema/SemaDeclCXX.cpp:7712:51: error: expected expression
    return Map[CtorType.castAs<FunctionProtoType>()].getEntry(SemaRef, Ctor);
                                                  ^

The first diagnostic is great. The second and third are terrible, and indicate
that we have not recovered as the fixit on the first diagnostic indicates.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130409/13ba6f0f/attachment.html>

From bugzilla-daemon at llvm.org  Mon Apr  8 22:33:25 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 09 Apr 2013 05:33:25 +0000
Subject: [LLVMbugs] [Bug 15702] Address sanitizer: setrlimit() fails
In-Reply-To: <bug-15702-206@http.llvm.org/bugs/>
References: <bug-15702-206@http.llvm.org/bugs/>
Message-ID: <bug-15702-206-076nN3piDJ@http.llvm.org/bugs/>

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

Kostya Serebryany <kcc at google.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |kcc at google.com
         Resolution|---                         |WONTFIX

--- Comment #1 from Kostya Serebryany <kcc at google.com> ---
This is expected. 
>From https://code.google.com/p/address-sanitizer/wiki/Flags (just added that):

disable_core     0/1     Disable the core dumper. Since asan consumes many
terabytes of virtual memory on 64-bit, dumping core is unwise. Default: 0 on
32-bit and 1 on 64-bit.

% clang -fsanitize=address setrlimit.c ; ./a.out 
ret: -1, errno: 1, message: Operation not permitted
% clang -fsanitize=address setrlimit.c ; ASAN_OPTIONS=disable_core=0 ./a.out 
ret: 0, errno: 0, message: Success
% clang -m32 -fsanitize=address setrlimit.c ; ./a.out 
ret: 0, errno: 0, message: Success
% 


Why would you want to have a 20Tb core file on your disk?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130409/0add3808/attachment.html>

From bugzilla-daemon at llvm.org  Tue Apr  9 10:59:15 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 09 Apr 2013 17:59:15 +0000
Subject: [LLVMbugs] [Bug 15525] SROA pessimizes ARM int8x16x2_t function
 argument handling
In-Reply-To: <bug-15525-206@http.llvm.org/bugs/>
References: <bug-15525-206@http.llvm.org/bugs/>
Message-ID: <bug-15525-206-BrT4VUtQve@http.llvm.org/bugs/>

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

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

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

--- Comment #5 from Benjamin Kramer <benny.kra at gmail.com> ---
Committed in r179106.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130409/aab92233/attachment.html>

From bugzilla-daemon at llvm.org  Tue Apr  9 11:16:47 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 09 Apr 2013 18:16:47 +0000
Subject: [LLVMbugs] [Bug 15540] GVN Pass time 10% regression caused by
	revision 176408
In-Reply-To: <bug-15540-206@http.llvm.org/bugs/>
References: <bug-15540-206@http.llvm.org/bugs/>
Message-ID: <bug-15540-206-JDiXSHfWpk@http.llvm.org/bugs/>

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

Nadav Rotem <nrotem at apple.com> changed:

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

--- Comment #10 from Nadav Rotem <nrotem at apple.com> ---
Hi Nuno, as you suggested I reverted r176408 and r176407 in revision r179111.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130409/bb9995c8/attachment.html>

From bugzilla-daemon at llvm.org  Tue Apr  9 11:46:23 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 09 Apr 2013 18:46:23 +0000
Subject: [LLVMbugs] [Bug 15710] New: ability to cross check all source files
Message-ID: <bug-15710-206@http.llvm.org/bugs/>

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

            Bug ID: 15710
           Summary: ability to cross check all source files
           Product: clang
           Version: trunk
          Hardware: Macintosh
                OS: MacOS X
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Static Analyzer
          Assignee: kremenek at apple.com
          Reporter: gryzman at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

So I'm doing a lot of security audits of code (hey apple!), it annoys me that I
cannot just dump all files into scan-build and let it do cross file checking. I
end up hacking code so it fits in one big file, and then analyse that. 

But with a standard ./configure/make way, or any other build process for that
matter - it should be possible for scan-build to do the hard lifting for me.
Each clang c.cc -o foo.o could also dump some pre-parsed form, and then when
linker is called - grab them - by using the .o files as reference to where to
find those, and do the long painful analysis that we all want. 

I'm guessing you guys are working on something like that, as it feels like a
natural step forward after cross function checking.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130409/b29d12ef/attachment.html>

From bugzilla-daemon at llvm.org  Tue Apr  9 12:13:41 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 09 Apr 2013 19:13:41 +0000
Subject: [LLVMbugs] [Bug 15711] New: clang allows access to private
 overloaded member function
Message-ID: <bug-15711-206@http.llvm.org/bugs/>

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

            Bug ID: 15711
           Summary: clang allows access to private overloaded member
                    function
           Product: clang
           Version: unspecified
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
          Assignee: unassignedclangbugs at nondot.org
          Reporter: rafael.espindola at gmail.com
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified

gcc rejects but clang accepts this:

class foo  {
  void f();
  void f(int);
};
template<typename T>
class bar : public foo {
  void g() {
    f();
  }
};
template class bar<int>;

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130409/71421d39/attachment.html>

From bugzilla-daemon at llvm.org  Tue Apr  9 12:26:21 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 09 Apr 2013 19:26:21 +0000
Subject: [LLVMbugs] [Bug 15712] New: inefficient code generation for
 128-bit->256-bit typecast intrinsics
Message-ID: <bug-15712-206@http.llvm.org/bugs/>

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

            Bug ID: 15712
           Summary: inefficient code generation for 128-bit->256-bit
                    typecast intrinsics
           Product: new-bugs
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: katya_romanova at playstation.sony.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

LLVM generates two additional instructions for 128->256 bit typecasts 
(e.g. _mm256_castsi128_si256, _mm256_castps128_ps256, _mm256_castpd128_pd256)
to clear out the upper 128 bits of YMM register corresponding to source XMM
register.

    vxorps xmm2,xmm2,xmm2
    vinsertf128 ymm0,ymm2,xmm0,0x0

Most of the industry-standard C/C++ compilers (GCC, Intel’s compiler, Visual
Studio compiler) don’t generate any extra moves for 128-bit->256-bit typecast
intrinsics. None of these compilers zero-extend the upper 128 bits of the
256-bit YMM register. Intel’s documentation for the _mm256_castsi128_si256
intrinsic explicitly states that “the upper bits of the resulting vector are
undefined” and that “this intrinsic does not introduce extra moves to the
generated code”. 

http://software.intel.com/sites/products/documentation/studio/composer/en-us/2011Update/compiler_c/intref_cls/common/intref_avx_castsi128_si256.htm

Clang implements these typecast intrinsics differently. I suspect that this was
done on purpose to avoid a hardware penalty caused by partial register writes. 

I think that the overall cost of 2 additional instructions (vxor + vinsertf128)
for *every* 128-bit->256-bit typecast intrinsic much higher than the hardware
penalty caused by partial register writes for *rare* cases when the upper part
of YMM register corresponding to a source XMM register is not cleared already.

Katya.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130409/0ac20fd0/attachment.html>

From bugzilla-daemon at llvm.org  Tue Apr  9 13:01:02 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 09 Apr 2013 20:01:02 +0000
Subject: [LLVMbugs] [Bug 15713] New: Implement MSVC's language extension to
 form pointers to members of virtual bases
Message-ID: <bug-15713-206@http.llvm.org/bugs/>

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

            Bug ID: 15713
           Summary: Implement MSVC's language extension to form pointers
                    to members of virtual bases
           Product: clang
           Version: unspecified
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: C++
          Assignee: unassignedclangbugs at nondot.org
          Reporter: reid.kleckner at gmail.com
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Clang currently rejects this program, as the standard says it is ill-formed in
[conv.mem], I think:

struct A { int a; };
struct B : virtual A { int b; };
int B::*memptr_b = &B::a;  // error
----
memptr_data_virtual.cpp:8:20: error: conversion from pointer to member of class
'A' to pointer to member of class 'B' via virtual base 'A' is not allowed
int B::*memptr_b = &B::a;  // error

MSVC accepts this program, and has a whole bunch of machinery baked into the
ABI to support it.  Data member pointers can be formed with up to 3 (!) i32s.

There's basically no way to implement this within the Itanium ABI since data
memptrs there are always just one offset, so this would only be in
-fms-compatibility (or -fms-extensions, I forget which is which).

Mostly I'm just filing this to have a discussion of record with a decision to
implement or not.  We should document this as part of
http://clang.llvm.org/compatibility.html, probably.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130409/dc5ca6c5/attachment.html>

From bugzilla-daemon at llvm.org  Tue Apr  9 16:48:16 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 09 Apr 2013 23:48:16 +0000
Subject: [LLVMbugs] [Bug 9170] Bad diagnostic when passing non-rvalue to
 rvalue-reference
In-Reply-To: <bug-9170-206@http.llvm.org/bugs/>
References: <bug-9170-206@http.llvm.org/bugs/>
Message-ID: <bug-9170-206-rlpZaRYTRx@http.llvm.org/bugs/>

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

Jordan Rose <jordan_rose at apple.com> changed:

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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130409/39eaeaf3/attachment.html>

From bugzilla-daemon at llvm.org  Tue Apr  9 17:52:14 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 10 Apr 2013 00:52:14 +0000
Subject: [LLVMbugs] [Bug 15558] False positive for -Wunused-variable with
 static member of internal-linkage type
In-Reply-To: <bug-15558-206@http.llvm.org/bugs/>
References: <bug-15558-206@http.llvm.org/bugs/>
Message-ID: <bug-15558-206-BYEVFtz6m6@http.llvm.org/bugs/>

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

Matt Beaumont-Gay <matthewbg at google.com> changed:

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

--- Comment #4 from Matt Beaumont-Gay <matthewbg at google.com> ---
Fixed in r179138.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130410/b13a8561/attachment.html>

From bugzilla-daemon at llvm.org  Tue Apr  9 19:42:40 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 10 Apr 2013 02:42:40 +0000
Subject: [LLVMbugs] [Bug 15714] New: clang hangs at -O3 on expression
Message-ID: <bug-15714-206@http.llvm.org/bugs/>

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

            Bug ID: 15714
           Summary: clang hangs at -O3 on expression
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: LLVM Codegen
          Assignee: unassignedclangbugs at nondot.org
          Reporter: dhazeghi at yahoo.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

The following snippet (generated by csmith) causes top-of-trunk clang to get
stuck in an infinite loop at -O3 (-O2 and below are fine, as is clang 3.2). 
While it appears to invoke undefined behavior ((*d ^= 1 != (long)d)), hanging
is probably not the right thing to do.

$ clang-trunk -v
clang version 3.3 (trunk 179090)
Target: x86_64-pc-linux-gnu
Thread model: posix
$ clang-trunk -O2 -c test.c
$ clang-trunk -O3 -c test.c
<hangs>


int a, b, c;
int fn2();
void fn1 ()
{
    int *d, *e = &b;
    d = &b;
    *e = 0;
    c = 0;
    for (; c < 42; ++c)
    {
        (*d ^= 1 != (long)d) && fn2 ();
        if (a)
            break;
    }
}

int fn2 ()
{
    int *f = &b;
    *f = 1;
    return b;
}

void fn3 ()
{
    fn1 ();
}

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130410/d9f87eae/attachment.html>

From bugzilla-daemon at llvm.org  Wed Apr 10 00:04:18 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 10 Apr 2013 07:04:18 +0000
Subject: [LLVMbugs] [Bug 15680] Clang does not find identifiers imported
 into namespaces by "using namespace"
In-Reply-To: <bug-15680-206@http.llvm.org/bugs/>
References: <bug-15680-206@http.llvm.org/bugs/>
Message-ID: <bug-15680-206-mJaOj8utPO@http.llvm.org/bugs/>

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

/dev/humancontroller <M8R-9yw8a5 at mailinator.com> changed:

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

--- Comment #1 from /dev/humancontroller <M8R-9yw8a5 at mailinator.com> ---
This bug has apparently been fixed without respect to this bug report.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130410/c61bb6c8/attachment.html>

From bugzilla-daemon at llvm.org  Wed Apr 10 02:26:40 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 10 Apr 2013 09:26:40 +0000
Subject: [LLVMbugs] [Bug 15715] New: False positive in interprocedural
 analysis of C++ destructors
Message-ID: <bug-15715-206@http.llvm.org/bugs/>

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

            Bug ID: 15715
           Summary: False positive in interprocedural analysis of C++
                    destructors
           Product: clang
           Version: unspecified
          Hardware: Macintosh
                OS: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: Static Analyzer
          Assignee: kremenek at apple.com
          Reporter: timac at timac.org
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 10331
  --> http://llvm.org/bugs/attachment.cgi?id=10331&action=edit
Xcode project

The Clang Static Analyzer (checker-273 and Xcode 4.6.1) reports a memory leak
for the following source code.

Steps to reproduce:
1- On 10.8.3 with Xcode 4.6.1, create a new CoreFoundation project with ARC
disabled.
2- Download the attached Xcode project or replace the main.c with a main.cpp
containing the following:


#include <CoreFoundation/CoreFoundation.h>

//
// MyCFString is a wrapper around CFStringRef.
//
class MyCFString
{
public:
    static CFStringRef EmptyCFString()
    {
        static CFStringRef kEmptyCFString = CFSTR("Empty");
        return kEmptyCFString;
    }

    MyCFString()
    {
        mRef = CFStringRef(CFRetain(EmptyCFString()));
    }

    ~MyCFString()
    {
        if(mRef != NULL)
            CFRelease(mRef);
    }

    // Adopt doesn't retain the passed CFStringRef
    void Adopt(CFStringRef s)
    {
        if (s != mRef)
        {
            if(mRef != NULL)
                CFRelease(mRef);
            mRef = s;
        }
    }

private:
    CFStringRef mRef;
};


int main(int argc, const char * argv[])
{
    MyCFString theString;

    // Create a CFStringRef
    CFStringRef adoptedString = CFStringCreateCopy(kCFAllocatorDefault,
CFSTR("This is not a leak"));

    // adoptedString is not retained by Adopt() but the MyCFString destructor
will release adoptedString
    theString.Adopt(adoptedString);

    return 0;
}


3- Run scan-build /usr/bin/xcodebuild -project InterproceduralBug.xcodeproj
-target "InterproceduralBug" build

Result:
The Clang static analyzer reports a memory leak.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130410/057c5814/attachment.html>

From bugzilla-daemon at llvm.org  Wed Apr 10 03:08:55 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 10 Apr 2013 10:08:55 +0000
Subject: [LLVMbugs] [Bug 15716] New: Clang doen't init map with
	initializer_list
Message-ID: <bug-15716-206@http.llvm.org/bugs/>

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

            Bug ID: 15716
           Summary: Clang doen't init map with initializer_list
           Product: libc++
           Version: unspecified
          Hardware: PC
                OS: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: All Bugs
          Assignee: hhinnant at apple.com
          Reporter: vladimir91.bondar at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

I had a bad code 
map<string, vector<string>[2]> m = { { "key", {{ "foo" }, { "meow" }} } };
and clang doesn't compile it, but with gcc everything ok.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130410/f6a246da/attachment.html>

From bugzilla-daemon at llvm.org  Wed Apr 10 05:25:32 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 10 Apr 2013 12:25:32 +0000
Subject: [LLVMbugs] [Bug 15717] New: FixIt: Wrong (suggested) location of
 the dereference operator in block enumerations
Message-ID: <bug-15717-206@http.llvm.org/bugs/>

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

            Bug ID: 15717
           Summary: FixIt: Wrong (suggested) location of the dereference
                    operator in block enumerations
           Product: clang
           Version: trunk
          Hardware: Macintosh
                OS: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: hagi.dd at web.de
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 10333
  --> http://llvm.org/bugs/attachment.cgi?id=10333&action=edit
FixIt inserts the operator at the wrong location

When using Cocoa's array block enumeration (enumerateObjectsUsingBlock:
selector), the default/autocompleted code block looks like this:

[array enumerateObjectsUsingBlock:^(id obj, NSUInteger idx, BOOL *stop) {
        // code
    }];

However, you can change the type of the input parameters to avoid casting
within the block, e.g., if you iterate over NSString objects:

[array enumerateObjectsUsingBlock:^(NSString *obj, NSUInteger idx, BOOL *stop)
{
        // code
    }];

If you forget to add the dereference operator between 'NSString' and 'obj',
Clang detects the issue, but suggests the wrong FixIt solution – the FixIt
inserts the dereference operator in front of the type name. I've attached a
screenshot of the situation in Xcode.

Expected Result: Put the dereference operator in front of the parameter name.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130410/f95b721a/attachment.html>

From bugzilla-daemon at llvm.org  Wed Apr 10 15:07:03 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 10 Apr 2013 22:07:03 +0000
Subject: [LLVMbugs] [Bug 13476] Crash of clang version 3.3 (trunk 178973)
 during analysis of attached file
In-Reply-To: <bug-13476-206@http.llvm.org/bugs/>
References: <bug-13476-206@http.llvm.org/bugs/>
Message-ID: <bug-13476-206-DS2rraxLOq@http.llvm.org/bugs/>

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

Anna Zaks <ganna at apple.com> changed:

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

--- Comment #4 from Anna Zaks <ganna at apple.com> ---
Fixed in r179228.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130410/2beb85a8/attachment.html>

From bugzilla-daemon at llvm.org  Wed Apr 10 21:54:52 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 11 Apr 2013 04:54:52 +0000
Subject: [LLVMbugs] [Bug 5443] missed x86 optimization for flags
In-Reply-To: <bug-5443-206@http.llvm.org/bugs/>
References: <bug-5443-206@http.llvm.org/bugs/>
Message-ID: <bug-5443-206-yvxPbosT3G@http.llvm.org/bugs/>

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

Michael Liao <michael.liao at intel.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |michael.liao at intel.com
         Resolution|---                         |FIXED

--- Comment #3 from Michael Liao <michael.liao at intel.com> ---
It's fixed in r179265. Now both functions are compiled into the same neat code.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130411/460f0892/attachment.html>

From bugzilla-daemon at llvm.org  Wed Apr 10 23:19:22 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 11 Apr 2013 06:19:22 +0000
Subject: [LLVMbugs] [Bug 15720] New: LoopVectorizer fails to vectorize loops
 with increasing integer induction variable
Message-ID: <bug-15720-206@http.llvm.org/bugs/>

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

            Bug ID: 15720
           Summary: LoopVectorizer fails to vectorize loops with
                    increasing integer induction variable
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Loop Optimizer
          Assignee: unassignedbugs at nondot.org
          Reporter: reachanadi at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Loops having integer induction variable running from lower value to higher
value as shown in example below(0 to SIZE) are not vectorized.

int foo(int *aa, int *bb, int SIZE) {
  int count = 190;
  for(int i=0;i<SIZE;i++) {
    aa[i] = bb[i] + count;
    count++;
  }
}

However, loops with integer induction variable running from higher value to
lower value(SIZE to 0) are successfully vectorized as in the example below.

int foo(int *aa, int *bb, int SIZE) {
  int count = 190;
  for(int i=SIZE;i > 0;i--) {
    aa[i] = bb[i] + count;
    count++;
  }
}

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130411/cab9e018/attachment.html>

From bugzilla-daemon at llvm.org  Thu Apr 11 03:18:41 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 11 Apr 2013 10:18:41 +0000
Subject: [LLVMbugs] [Bug 15721] New: Three crashes on gcc cpp0x testsuite
Message-ID: <bug-15721-206@http.llvm.org/bugs/>

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

            Bug ID: 15721
           Summary: Three crashes on gcc cpp0x testsuite
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++11
          Assignee: unassignedclangbugs at nondot.org
          Reporter: markus at trippelsdorf.de
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified

markus at x4 gcc % cat gcc/testsuite/g++.dg/cpp0x/alias-decl-2.C
// { dg-options "-std=c++0x" }

template<class T> struct S0 {};
template<class T> using AS0 = S0<T>;

template<template<class> class TT>
void f(TT<int>);

template class AS0<char>; // { dg-error "alias
templ\[^\n\r\]*specialization\[^\n\r\]*after\[^\n\r\]*class" }

void
foo()
{
  AS0<int> a;
  f(a);
}

template<class T, class U> struct Vector{};
template<class T> struct Alloc {};

template<class T> using Vec = Vector<T, Alloc<T> >;

template<class T> void g(Vector<T, Alloc<T> >);

template<template<class T> class TT> void h(TT<int>); // { dg-error "provided
for" }

void
bar()
{
  Vec<int> a;
  g(a);
  h(a); // { dg-error "no matching function|wrong number of template arguments"
}
}

markus at x4 gcc % clang++ -c gcc/testsuite/g++.dg/cpp0x/alias-decl-2.C
gcc/testsuite/g++.dg/cpp0x/alias-decl-2.C:4:31: warning: alias declarations are
a C++11 extension [-Wc++11-extensions]
template<class T> using AS0 = S0<T>;
                              ^
0  clang-3.3       0x0000000000f06602 llvm::sys::PrintStackTrace(_IO_FILE*) +
34
1  clang-3.3       0x0000000000f06261
2  libpthread.so.0 0x00007f39cfb750c0
3  clang-3.3       0x00000000019be8fb clang::TagDecl::getDefinition() const +
91
4  clang-3.3       0x00000000013c6c85
clang::Sema::isAcceptableTagRedeclaration(clang::TagDecl const*,
clang::TagTypeKind, bool, clang::SourceLocation, clang::IdentifierInfo 
const&) + 1061
5  clang-3.3       0x000000000157acde
clang::Sema::ActOnExplicitInstantiation(clang::Scope*, clang::SourceLocation,
clang::SourceLocation, unsigned int, clang::SourceLocation
, clang::CXXScopeSpec const&, clang::OpaquePtr<clang::TemplateName>,
clang::SourceLocation, clang::SourceLocation,
llvm::MutableArrayRef<clang::ParsedTemplateArgument>, clang
::SourceLocation, clang::AttributeList*) + 110
6  clang-3.3       0x00000000011b98dd
clang::Parser::ParseClassSpecifier(clang::tok::TokenKind,
clang::SourceLocation, clang::DeclSpec&, clang::Parser::ParsedTemplateInfo con
st&, clang::AccessSpecifier, bool, clang::Parser::DeclSpecContext,
clang::Parser::ParsedAttributesWithRange&) + 4813
7  clang-3.3       0x00000000011a54f5
clang::Parser::ParseDeclarationSpecifiers(clang::DeclSpec&,
clang::Parser::ParsedTemplateInfo const&, clang::AccessSpecifier, clang::Par
ser::DeclSpecContext, clang::Parser::LateParsedAttrList*) + 4325
8  clang-3.3       0x00000000011ffc8a
clang::Parser::ParseSingleDeclarationAfterTemplate(unsigned int,
clang::Parser::ParsedTemplateInfo const&, clang::ParsingDeclRAIIObject&
, clang::SourceLocation&, clang::AccessSpecifier, clang::AttributeList*) + 874
9  clang-3.3       0x0000000001201396
clang::Parser::ParseExplicitInstantiation(unsigned int, clang::SourceLocation,
clang::SourceLocation, clang::SourceLocation&, clang::Acc
essSpecifier) + 150
10 clang-3.3       0x0000000001201566
clang::Parser::ParseDeclarationStartingWithTemplate(unsigned int,
clang::SourceLocation&, clang::AccessSpecifier, clang::AttributeList*)
 + 342
11 clang-3.3       0x00000000011a8c86
clang::Parser::ParseDeclaration(llvm::SmallVector<clang::Stmt*, 32u>&, unsigned
int, clang::SourceLocation&, clang::Parser::ParsedAttrib
utesWithRange&) + 582
12 clang-3.3       0x00000000011958ea
clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&,
clang::ParsingDeclSpec*) + 314
13 clang-3.3       0x0000000001195fa2
clang::Parser::ParseTopLevelDecl(clang::OpaquePtr<clang::DeclGroupRef>&) + 194
14 clang-3.3       0x000000000118d44b clang::ParseAST(clang::Sema&, bool, bool)
+ 283
15 clang-3.3       0x00000000010de929 clang::FrontendAction::Execute() + 169
16 clang-3.3       0x00000000010c1ad5
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 293
17 clang-3.3       0x0000000000f08d07
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1607
18 clang-3.3       0x00000000006a31e8 cc1_main(char const**, char const**, char
const*, void*) + 872
19 clang-3.3       0x000000000068ed40 main + 8032
20 libc.so.6       0x00007f39cf592875 __libc_start_main + 245
21 clang-3.3       0x00000000006a1135
Stack dump:
0.      Program arguments: /usr/local/bin/clang-3.3 -cc1 -triple
x86_64-unknown-linux-gnu -emit-obj -mrelax-all -disable-free
-disable-llvm-verifier -main-file-name alias-dec
l-2.C -mrelocation-model static -mdisable-fp-elim -fmath-errno -masm-verbose
-mconstructor-aliases -munwind-tables -fuse-init-array -target-cpu x86-64
-momit-leaf-frame-point
er -coverage-file /home/markus/gcc/alias-decl-2.o -resource-dir
/usr/local/bin/../lib/clang/3.3 -internal-isystem
/usr/lib64/gcc/x86_64-pc-linux-gnu/4.9.0/include/g++-v4 -int
ernal-isystem
/usr/lib64/gcc/x86_64-pc-linux-gnu/4.9.0/include/g++-v4/x86_64-pc-linux-gnu
-internal-isystem
/usr/lib64/gcc/x86_64-pc-linux-gnu/4.9.0/include/g++-v4/backward -
internal-isystem /usr/local/include -internal-isystem
/usr/local/bin/../lib/clang/3.3/include -internal-externc-isystem /include
-internal-externc-isystem /usr/include -fdepr
ecated-macro -fdebug-compilation-dir /home/markus/gcc -ferror-limit 19
-fmessage-length 174 -mstackrealign -fobjc-runtime=gcc
-fobjc-default-synthesize-properties -fcxx-excep
tions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics
-backend-option -vectorize-loops -o alias-decl-2.o -x c++
gcc/testsuite/g++.dg/cpp0x/alias-decl-2.C 
1.      gcc/testsuite/g++.dg/cpp0x/alias-decl-2.C:9:25: current parser token
';'
clang-3.3: error: unable to execute command: Segmentation fault
clang-3.3: error: clang frontend command failed due to signal (use -v to see
invocation)


markus at x4 gcc % cat gcc/testsuite/g++.dg/cpp0x/alias-decl-10.C
// { dg-options "-std=c++0x" }

template <class T> using Ptr = T*;
Ptr<unsigned>; // { dg-error "does not declare anything" }
Ptr<char><int>; // { dg-error "not a template|does not declare anything" }
template class Ptr<int>;//{ dg-error "alias template
specialization\[^\n\r\]*after\[^\n\r\]*class" }

template <class T> using Arg = T;
struct A {};
template class Arg<A>;// { dg-error "alias
templ\[^\n\r\]*specialization\[^\n\r\]*Arg<A>\[^\n\r\]*after\[^\n\r\]*class" }

template <template <class> class TT, class T> using Instantiate = TT<T>;
template <class> struct Vector {};

// The below is not OK, because of [dcl.type.elab]:
// 
//     If the identifier resolves to a typedef-name or the
//     simple-template-id resolves to an alias template
//     specialization, the elaborated-type-specifier is ill-formed.
//
template class Instantiate<Vector, int>;//{ dg-error "alias template
specialization\[^\n\r\]*after\[^\n\r\]*class" }

template <class T> struct S {};
template<class T> using SFor = S<T>;
// Likewise, this is not OK.
template class SFor<int>; //{ dg-error "alias template
specialization\[^\n\r\]*after\[^\n\r\]*class" }


markus at x4 gcc % clang++ -c gcc/testsuite/g++.dg/cpp0x/alias-decl-10.C
gcc/testsuite/g++.dg/cpp0x/alias-decl-10.C:3:32: warning: alias declarations
are a C++11 extension [-Wc++11-extensions]
template <class T> using Ptr = T*;
                               ^
gcc/testsuite/g++.dg/cpp0x/alias-decl-10.C:4:1: warning: declaration does not
declare anything [-Wmissing-declarations]
Ptr<unsigned>; // { dg-error "does not declare anything" }
^~~~~~~~~~~~~
gcc/testsuite/g++.dg/cpp0x/alias-decl-10.C:5:10: error: expected unqualified-id
Ptr<char><int>; // { dg-error "not a template|does not declare anything" }
         ^
0  clang-3.3       0x0000000000f06602 llvm::sys::PrintStackTrace(_IO_FILE*) +
34
1  clang-3.3       0x0000000000f06261
2  libpthread.so.0 0x00007f5b2ae9d0c0
3  clang-3.3       0x0000000000ed6fba
llvm::FoldingSetImpl::FindNodeOrInsertPos(llvm::FoldingSetNodeID const&,
void*&) + 58
4  clang-3.3       0x00000000019eb8b6
clang::ClassTemplateDecl::findSpecialization(clang::TemplateArgument const*,
unsigned int, void*&) + 150
5  clang-3.3       0x000000000157b01d
clang::Sema::ActOnExplicitInstantiation(clang::Scope*, clang::SourceLocation,
clang::SourceLocation, unsigned int, clang::SourceLocation
, clang::CXXScopeSpec const&, clang::OpaquePtr<clang::TemplateName>,
clang::SourceLocation, clang::SourceLocation,
llvm::MutableArrayRef<clang::ParsedTemplateArgument>, clang
::SourceLocation, clang::AttributeList*) + 941
6  clang-3.3       0x00000000011b98dd
clang::Parser::ParseClassSpecifier(clang::tok::TokenKind,
clang::SourceLocation, clang::DeclSpec&, clang::Parser::ParsedTemplateInfo con
st&, clang::AccessSpecifier, bool, clang::Parser::DeclSpecContext,
clang::Parser::ParsedAttributesWithRange&) + 4813
7  clang-3.3       0x00000000011a54f5
clang::Parser::ParseDeclarationSpecifiers(clang::DeclSpec&,
clang::Parser::ParsedTemplateInfo const&, clang::AccessSpecifier, clang::Par
ser::DeclSpecContext, clang::Parser::LateParsedAttrList*) + 4325
8  clang-3.3       0x00000000011ffc8a
clang::Parser::ParseSingleDeclarationAfterTemplate(unsigned int,
clang::Parser::ParsedTemplateInfo const&, clang::ParsingDeclRAIIObject&
, clang::SourceLocation&, clang::AccessSpecifier, clang::AttributeList*) + 874
9  clang-3.3       0x0000000001201396
clang::Parser::ParseExplicitInstantiation(unsigned int, clang::SourceLocation,
clang::SourceLocation, clang::SourceLocation&, clang::Acc
essSpecifier) + 150
10 clang-3.3       0x0000000001201566
clang::Parser::ParseDeclarationStartingWithTemplate(unsigned int,
clang::SourceLocation&, clang::AccessSpecifier, clang::AttributeList*)
 + 342
11 clang-3.3       0x00000000011a8c86
clang::Parser::ParseDeclaration(llvm::SmallVector<clang::Stmt*, 32u>&, unsigned
int, clang::SourceLocation&, clang::Parser::ParsedAttrib
utesWithRange&) + 582
12 clang-3.3       0x00000000011958ea
clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&,
clang::ParsingDeclSpec*) + 314
13 clang-3.3       0x0000000001195fa2
clang::Parser::ParseTopLevelDecl(clang::OpaquePtr<clang::DeclGroupRef>&) + 194
14 clang-3.3       0x000000000118d44b clang::ParseAST(clang::Sema&, bool, bool)
+ 283
15 clang-3.3       0x00000000010de929 clang::FrontendAction::Execute() + 169
16 clang-3.3       0x00000000010c1ad5
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 293
17 clang-3.3       0x0000000000f08d07
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1607
18 clang-3.3       0x00000000006a31e8 cc1_main(char const**, char const**, char
const*, void*) + 872
19 clang-3.3       0x000000000068ed40 main + 8032
20 libc.so.6       0x00007f5b2a8ba875 __libc_start_main + 245
21 clang-3.3       0x00000000006a1135
Stack dump:
0.      Program arguments: /usr/local/bin/clang-3.3 -cc1 -triple
x86_64-unknown-linux-gnu -emit-obj -mrelax-all -disable-free
-disable-llvm-verifier -main-file-name alias-dec
l-10.C -mrelocation-model static -mdisable-fp-elim -fmath-errno -masm-verbose
-mconstructor-aliases -munwind-tables -fuse-init-array -target-cpu x86-64
-momit-leaf-frame-poin
ter -coverage-file /home/markus/gcc/alias-decl-10.o -resource-dir
/usr/local/bin/../lib/clang/3.3 -internal-isystem
/usr/lib64/gcc/x86_64-pc-linux-gnu/4.9.0/include/g++-v4 -i
nternal-isystem
/usr/lib64/gcc/x86_64-pc-linux-gnu/4.9.0/include/g++-v4/x86_64-pc-linux-gnu
-internal-isystem
/usr/lib64/gcc/x86_64-pc-linux-gnu/4.9.0/include/g++-v4/backward
 -internal-isystem /usr/local/include -internal-isystem
/usr/local/bin/../lib/clang/3.3/include -internal-externc-isystem /include
-internal-externc-isystem /usr/include -fde
precated-macro -fdebug-compilation-dir /home/markus/gcc -ferror-limit 19
-fmessage-length 174 -mstackrealign -fobjc-runtime=gcc
-fobjc-default-synthesize-properties -fcxx-exc
eptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics
-backend-option -vectorize-loops -o alias-decl-10.o -x c++
gcc/testsuite/g++.dg/cpp0x/alias-decl-10.C 
1.      gcc/testsuite/g++.dg/cpp0x/alias-decl-10.C:6:24: current parser token
';'
clang-3.3: error: unable to execute command: Segmentation fault
clang-3.3: error: clang frontend command failed due to signal (use -v to see
invocation)


markus at x4 gcc % cat gcc/testsuite/g++.dg/cpp0x/nsdmi-defer6.C
// { dg-do compile { target c++11 } }

struct A                        // { dg-error "non-static data member" }
{
  int i = (A(), 42);            // { dg-message "required here" }
};

A a;

markus at x4 gcc % clang++ -c -std=c++11 gcc/testsuite/g++.dg/cpp0x/nsdmi-defer6.C
gcc/testsuite/g++.dg/cpp0x/nsdmi-defer6.C:5:12: error: defaulted default
constructor of 'A' cannot be used by non-static data member initializer which
appears before end of
      class definition
  int i = (A(), 42);            // { dg-message "required here" }
           ^
0  clang-3.3       0x0000000000f06602 llvm::sys::PrintStackTrace(_IO_FILE*) +
34
1  clang-3.3       0x0000000000f06261
2  libpthread.so.0 0x00007f959dc1f0c0
3  clang-3.3       0x0000000001a09f1e
4  clang-3.3       0x0000000001a130da
5  clang-3.3       0x000000000067eb57
6  clang-3.3       0x0000000001a0948f
7  clang-3.3       0x0000000001a0e9b2
8  clang-3.3       0x0000000001a162b0
9  clang-3.3       0x0000000001a17f6a
10 clang-3.3       0x0000000001a185b2
11 clang-3.3       0x0000000001a0e3e0
12 clang-3.3       0x0000000001a10022
13 clang-3.3       0x0000000001a11c54
clang::Expr::EvaluateForOverflow(clang::ASTContext const&,
llvm::SmallVectorImpl<std::pair<clang::SourceLocation,
clang::PartialDiagnostic> >*) const + 324
14 clang-3.3       0x0000000001370b34
clang::Sema::CheckForIntOverflow(clang::Expr*) + 84
15 clang-3.3       0x00000000014c1762
clang::Sema::ActOnFinishFullExpr(clang::Expr*, clang::SourceLocation, bool,
bool) + 178
16 clang-3.3       0x0000000001418add
clang::Sema::ActOnCXXInClassMemberInitializer(clang::Decl*,
clang::SourceLocation, clang::Expr*) + 141
17 clang-3.3       0x0000000001208f59
clang::Parser::ParseLexedMemberInitializer(clang::Parser::LateParsedMemberInitializer&)
+ 521
18 clang-3.3       0x0000000001208c79
clang::Parser::ParseLexedMemberInitializers(clang::Parser::ParsingClass&) + 233
19 clang-3.3       0x00000000011b7933
clang::Parser::ParseCXXMemberSpecification(clang::SourceLocation,
clang::SourceLocation, clang::Parser::ParsedAttributesWithRange&, unsigned int,
clang::Decl*) + 1443
20 clang-3.3       0x00000000011b945b
clang::Parser::ParseClassSpecifier(clang::tok::TokenKind,
clang::SourceLocation, clang::DeclSpec&, clang::Parser::ParsedTemplateInfo
const&, clang::AccessSpecifier, bool, clang::Parser::DeclSpecContext,
clang::Parser::ParsedAttributesWithRange&) + 3659
21 clang-3.3       0x00000000011a54f5
clang::Parser::ParseDeclarationSpecifiers(clang::DeclSpec&,
clang::Parser::ParsedTemplateInfo const&, clang::AccessSpecifier,
clang::Parser::DeclSpecContext, clang::Parser::LateParsedAttrList*) + 4325
22 clang-3.3       0x0000000001191bb4
clang::Parser::ParseDeclOrFunctionDefInternal(clang::Parser::ParsedAttributesWithRange&,
clang::ParsingDeclSpec&, clang::AccessSpecifier) + 84
23 clang-3.3       0x000000000119245e
clang::Parser::ParseDeclarationOrFunctionDefinition(clang::Parser::ParsedAttributesWithRange&,
clang::ParsingDeclSpec*, clang::AccessSpecifier) + 958
24 clang-3.3       0x00000000011958a9
clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&,
clang::ParsingDeclSpec*) + 249
25 clang-3.3       0x0000000001195fa2
clang::Parser::ParseTopLevelDecl(clang::OpaquePtr<clang::DeclGroupRef>&) + 194
26 clang-3.3       0x000000000118d490 clang::ParseAST(clang::Sema&, bool, bool)
+ 352
27 clang-3.3       0x00000000010de929 clang::FrontendAction::Execute() + 169
28 clang-3.3       0x00000000010c1ad5
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 293
29 clang-3.3       0x0000000000f08d07
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1607
30 clang-3.3       0x00000000006a31e8 cc1_main(char const**, char const**, char
const*, void*) + 872
31 clang-3.3       0x000000000068ed40 main + 8032
32 libc.so.6       0x00007f959d63c875 __libc_start_main + 245
33 clang-3.3       0x00000000006a1135
Stack dump:
0.      Program arguments: /usr/local/bin/clang-3.3 -cc1 -triple
x86_64-unknown-linux-gnu -emit-obj -mrelax-all -disable-free
-disable-llvm-verifier -main-file-name nsdmi-defer6.C -mrelocation-model static
-mdisable-fp-elim -fmath-errno -masm-verbose -mconstructor-aliases
-munwind-tables -fuse-init-array -target-cpu x86-64 -momit-leaf-frame-pointer
-coverage-file /home/markus/gcc/nsdmi-defer6.o -resource-dir
/usr/local/bin/../lib/clang/3.3 -internal-isystem
/usr/lib64/gcc/x86_64-pc-linux-gnu/4.9.0/include/g++-v4 -internal-isystem
/usr/lib64/gcc/x86_64-pc-linux-gnu/4.9.0/include/g++-v4/x86_64-pc-linux-gnu
-internal-isystem
/usr/lib64/gcc/x86_64-pc-linux-gnu/4.9.0/include/g++-v4/backward
-internal-isystem /usr/local/include -internal-isystem
/usr/local/bin/../lib/clang/3.3/include -internal-externc-isystem /include
-internal-externc-isystem /usr/include -std=c++11 -fdeprecated-macro
-fdebug-compilation-dir /home/markus/gcc -ferror-limit 19 -fmessage-length 174
-mstackrealign -fobjc-runtime=gcc -fobjc-default-synthesize-properties
-fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics
-backend-option -vectorize-loops -o nsdmi-defer6.o -x c++
gcc/testsuite/g++.dg/cpp0x/nsdmi-defer6.C 
1.      <eof> parser at end of file
2.      gcc/testsuite/g++.dg/cpp0x/nsdmi-defer6.C:3:1: parsing
struct/union/class body 'A'
clang-3.3: error: unable to execute command: Segmentation fault
clang-3.3: error: clang frontend command failed due to signal (use -v to see
invocation)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130411/d6c2a006/attachment.html>

From bugzilla-daemon at llvm.org  Thu Apr 11 05:56:51 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 11 Apr 2013 12:56:51 +0000
Subject: [LLVMbugs] [Bug 15672] use-after-return is broken since r177724
In-Reply-To: <bug-15672-206@http.llvm.org/bugs/>
References: <bug-15672-206@http.llvm.org/bugs/>
Message-ID: <bug-15672-206-uXZUUqlTPA@http.llvm.org/bugs/>

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

Kostya Serebryany <kcc at google.com> changed:

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

--- Comment #3 from Kostya Serebryany <kcc at google.com> ---
Should be fixed by 179278.
We still don't provide any guarantee that use-after-return detection works. 
But this simple test (and a few others) pass again now

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130411/2db80c71/attachment.html>

From bugzilla-daemon at llvm.org  Thu Apr 11 06:48:03 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 11 Apr 2013 13:48:03 +0000
Subject: [LLVMbugs] [Bug 15722] New: VIM syntax highlight improvement
Message-ID: <bug-15722-206@http.llvm.org/bugs/>

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

            Bug ID: 15722
           Summary: VIM syntax highlight improvement
           Product: new-bugs
           Version: trunk
          Hardware: PC
                OS: Windows XP
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: Christian at savioursofsoul.de
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

I'm by no means an expert of VIM syntax highlighting, but I was using this file
as a reference for my own syntax highlighting code. So excuse me if I'm wrong
here.

in line 67 of the llvm.vim script it is written:

syn match   llvmFloat  /\<0x\x\+\>/

but it should probably be like this:

syn match   llvmHex  /\<0x\x\+\>/

with an additional

  HiLink llvmHex Number

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130411/8da578a8/attachment.html>

From bugzilla-daemon at llvm.org  Thu Apr 11 07:27:09 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 11 Apr 2013 14:27:09 +0000
Subject: [LLVMbugs] [Bug 15723] New: Incorrect handling of out of bounds and
 strings starting from 0x
Message-ID: <bug-15723-206@http.llvm.org/bugs/>

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

            Bug ID: 15723
           Summary: Incorrect handling of out of bounds and strings
                    starting from 0x
           Product: libc++
           Version: 3.2
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: All Bugs
          Assignee: hhinnant at apple.com
          Reporter: antoshkka at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 10336
  --> http://llvm.org/bugs/attachment.cgi?id=10336&action=edit
Tests

Test cases in attachment are taken from Boost.LexicalCast conversion tests that
currently fail on libc++ and pass well on other STL implementations.

This bugreport may be a partial duplicate for #9326 and #15579.

I give permission for the attached file, or a modified version of it, to be
used in the libc++ testsuite, if you want it.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130411/46018bba/attachment.html>

From bugzilla-daemon at llvm.org  Thu Apr 11 08:08:19 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 11 Apr 2013 15:08:19 +0000
Subject: [LLVMbugs] [Bug 15724] New: set: default construction does not work
	properly
Message-ID: <bug-15724-206@http.llvm.org/bugs/>

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

            Bug ID: 15724
           Summary: set: default construction does not work properly
           Product: libc++
           Version: unspecified
          Hardware: Macintosh
                OS: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: All Bugs
          Assignee: hhinnant at apple.com
          Reporter: akim.demaille at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

In the following piece of code, if I understand correctly libc++'s own header
(the initial "Synopsis" section), there is:

    set()
        noexcept(
            is_nothrow_default_constructible<allocator_type>::value &&
            is_nothrow_default_constructible<key_compare>::value &&
            is_nothrow_copy_constructible<key_compare>::value);
    explicit set(const value_compare& comp);

i.e., the default constructor is not flagged with explicit.

Yet, the following piece of code does not work, because there is no default
constructor: its functionality is provided by the following (explicit)
unary-constructor whose argument is optional.  So clang rejects the following
piece of code.

$ cat /tmp/set.cc
#include <set>
int
main()
{
  std::set<int> s = {};
}
$ clang++-mp-3.3 -std=c++11 -Wall /tmp/set.cc -stdlib=libc++
/tmp/set.cc:5:17: error: chosen constructor is explicit in copy-initialization
  std::set<int> s = {};
                ^   ~~
/opt/local/libexec/llvm-3.3/bin/../lib/c++/v1/set:378:14: note: constructor
declared here
    explicit set(const value_compare& __comp = value_compare())
             ^
1 error generated.
$ g++-mp-4.8 -std=c++11 -Wall /tmp/set.cc

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130411/39d1578a/attachment.html>

From bugzilla-daemon at llvm.org  Thu Apr 11 10:30:51 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 11 Apr 2013 17:30:51 +0000
Subject: [LLVMbugs] [Bug 15725] New: uninitialized __block storage variables
 used in blocks don't provoke warning
Message-ID: <bug-15725-206@http.llvm.org/bugs/>

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

            Bug ID: 15725
           Summary: uninitialized __block storage variables used in blocks
                    don't provoke warning
           Product: clang
           Version: trunk
          Hardware: Macintosh
                OS: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
          Assignee: unassignedclangbugs at nondot.org
          Reporter: tjw at me.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 10337
  --> http://llvm.org/bugs/attachment.cgi?id=10337&action=edit
test case

See the attached test case, in which a __block variable is left uninitialized
and then used w/in a block:


void test0(void)
{
    __block int x; // BAD: No warning that this is the uninitialized variable

    void (^block)(void) = ^{ // BAD: No warning that an uninitialized variable
is captured
        printf("x = %d\n", x);
    };
    block();
}

This is conceivably good in the case that the block variable is out-only (the
block initializes it), but a very common pattern with Foundation is now:

__block BOOL success = NO;
__block NSError *error;
[coordinator coordinate... ^(NSURL *newURL){
   ... do a bunch of stuff that might fail ...
   success = YES;
}];
if (!success) {
  ... handle the error ...
}

In the case that you forget the 'NO' initializer above, you'll miss your error
handling case with disastrous results.

This is especially insidious in ARC mode where you get trained to not
initialize locals (since ARC initializes object pointer locals to nil for you).

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130411/f9ba2545/attachment.html>

From bugzilla-daemon at llvm.org  Thu Apr 11 10:54:35 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 11 Apr 2013 17:54:35 +0000
Subject: [LLVMbugs] [Bug 14856] IPA notices leak that isn't noticed in
	normal method
In-Reply-To: <bug-14856-206@http.llvm.org/bugs/>
References: <bug-14856-206@http.llvm.org/bugs/>
Message-ID: <bug-14856-206-uHyxitORx6@http.llvm.org/bugs/>

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

Anna Zaks <ganna at apple.com> changed:

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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130411/b4724c56/attachment.html>

From bugzilla-daemon at llvm.org  Thu Apr 11 13:55:40 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 11 Apr 2013 20:55:40 +0000
Subject: [LLVMbugs] [Bug 15726] New: clang emits wrong symbol on PPC32 for
 std::ostream::write
Message-ID: <bug-15726-206@http.llvm.org/bugs/>

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

            Bug ID: 15726
           Summary: clang emits wrong symbol on PPC32 for
                    std::ostream::write
           Product: clang
           Version: trunk
          Hardware: Macintosh
                OS: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
          Assignee: unassignedclangbugs at nondot.org
          Reporter: fang at csl.cornell.edu
                CC: dgregor at apple.com, hfinkel at anl.gov,
                    llvmbugs at cs.uiuc.edu
    Classification: Unclassified

I have a stage1 clang built from gcc-4.0+cmake+shared on powerpc-darwin8 that
I'm using to build stage 2.
The flags I use for stage 2 are: -fno-common -no-integrated-as
(no optimization/debug)

I'm able to compile all translation units for libLLVMSupport, but at link time,
I get:
ld: Undefined symbols:
__ZNSo5writeEPKcl
/usr/libexec/gcc/powerpc-apple-darwin8/4.0.1/libtool: internal link edit
command failed

This symbol is:
% echo __ZNSo5writeEPKcl | c++filt
std::basic_ostream<char, std::char_traits<char> >::write(char const*, long)

However, libstdc++ on my system (PPC, 32b) provides only
std::basic_ostream<char, std::char_traits<char> >::write(char const*, int)

This undefined symbol (stage-2) is being referenced from:
% nm lib/Support/CMakeFiles/LLVMSupport.dir/raw_os_ostream.cpp.o
...
         U __ZNSo5writeEPKcl
...

% file lib/Support/CMakeFiles/LLVMSupport.dir/raw_os_ostream.cpp.o
lib/Support/CMakeFiles/LLVMSupport.dir/raw_os_ostream.cpp.o: Mach-O object ppc
(That's 32b.)

Support/raw_os_ostream.cpp has:
void raw_os_ostream::write_impl(const char *Ptr, size_t Size) {
  OS.write(Ptr, Size);
}


For comparison, during stage 1 (built by system compiler gcc-4.0.1):
% nm lib/Support/CMakeFiles/LLVMSupport.dir/raw_os_ostream.cpp.o 
...
         U __ZNSo5writeEPKci
...

>From libstdc++ (gcc-4.0.1) <ostream>:
      __ostream_type&
      write(const char_type* __s, streamsize __n);

So clang is mistakenly treating the streamsize/size_t argument of
std::ostream::write as long instead of int on a 32b powerpc triple.
size_t should map to int on powerpc 32b, right?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130411/055be927/attachment.html>

From bugzilla-daemon at llvm.org  Thu Apr 11 13:56:04 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 11 Apr 2013 20:56:04 +0000
Subject: [LLVMbugs] [Bug 15727] New: Value::isUsedInBasicBlock is buggy.
Message-ID: <bug-15727-206@http.llvm.org/bugs/>

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

            Bug ID: 15727
           Summary: Value::isUsedInBasicBlock is buggy.
           Product: libraries
           Version: 3.2
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: release blocker
          Priority: P
         Component: Core LLVM classes
          Assignee: unassignedbugs at nondot.org
          Reporter: fjia at cs.ucsd.edu
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

I happened to use Value::isUsedInBasicBlock(const BasicBlock *BB) const.

I noticed that the function always returns false when the basic block size is
larger than 3. So I checked the source of Value.c and found there is a bug
there.

113   unsigned MaxBlockSize = 3;                                                
114   for (BasicBlock::const_iterator I = BB->begin(), E = BB->end(); I != E;
++I) {    
115     if (std::find(I->op_begin(), I->op_end(), this) != I->op_end())         
116       return true;                                                          
117     if (MaxBlockSize-- == 0) // If the block is larger fall back to
use_iterator    
118       break;                                                                
119   }                                                                         
120                                                                             
121   if (MaxBlockSize != 0) // We scanned the entire block and found no use.   
122     return false;  

If block size is larger than 3, in line 117, the loop is breaked out, and
MaxBlockSize = -1. In line 121, MaxBlockSize != 0 is true, and false is
returned. This explains why the function always returns false when the block
size is larger than 3.

The potential bug fix is

117   if (--MaxBlockSize == 0) // If ...

Thanks!

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130411/b96f41ce/attachment.html>

From bugzilla-daemon at llvm.org  Thu Apr 11 15:31:32 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 11 Apr 2013 22:31:32 +0000
Subject: [LLVMbugs] [Bug 15728] New: clang crashes with SIGSEV in
 clang::CodeGen::CodeGenFunction::EmitScalarExpr
Message-ID: <bug-15728-206@http.llvm.org/bugs/>

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

            Bug ID: 15728
           Summary: clang crashes with SIGSEV in
                    clang::CodeGen::CodeGenFunction::EmitScalarExpr
           Product: clang
           Version: 3.2
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
          Assignee: unassignedclangbugs at nondot.org
          Reporter: spam at abma.de
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 10341
  --> http://llvm.org/bugs/attachment.cgi?id=10341&action=edit
source code which lets clang crash

0  libLLVM-3.2.so.1 0x00007f23a3af4c0f
1  libLLVM-3.2.so.1 0x00007f23a3af5079
2  libpthread.so.0  0x00007f23a2ba8bd0
3  clang            0x0000000000540c38
4  clang            0x00000000007d610f
5  clang            0x00000000007d85fd
clang::CodeGen::CodeGenFunction::EmitScalarExpr(clang::Expr const*, bool) + 61
6  clang            0x000000000079bebf
clang::CodeGen::CodeGenFunction::EmitAnyExpr(clang::Expr const*,
clang::CodeGen::AggValueSlot, bool) + 303
7  clang            0x00000000007ac826
clang::CodeGen::CodeGenFunction::EmitIgnoredExpr(clang::Expr const*) + 70
8  clang            0x000000000082c24f
clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*) + 303
9  clang            0x000000000082c41f
clang::CodeGen::CodeGenFunction::EmitCompoundStmt(clang::CompoundStmt const&,
bool, clang::CodeGen::AggValueSlot) + 239
10 clang            0x000000000082ea42
clang::CodeGen::CodeGenFunction::EmitSimpleStmt(clang::Stmt const*) + 210
11 clang            0x000000000082c143
clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*) + 35
12 clang            0x000000000082e7f3
clang::CodeGen::CodeGenFunction::EmitIfStmt(clang::IfStmt const&) + 483
13 clang            0x000000000082c29b
clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*) + 379
14 clang            0x000000000082c41f
clang::CodeGen::CodeGenFunction::EmitCompoundStmt(clang::CompoundStmt const&,
bool, clang::CodeGen::AggValueSlot) + 239
15 clang            0x000000000082ea42
clang::CodeGen::CodeGenFunction::EmitSimpleStmt(clang::Stmt const*) + 210
16 clang            0x000000000082c143
clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*) + 35
17 clang            0x0000000000771231
clang::CodeGen::CodeGenFunction::EmitDestructorBody(clang::CodeGen::FunctionArgList&)
+ 385
18 clang            0x000000000083eb20
clang::CodeGen::CodeGenFunction::GenerateCode(clang::GlobalDecl,
llvm::Function*, clang::CodeGen::CGFunctionInfo const&) + 1600
19 clang            0x000000000075b942
clang::CodeGen::CodeGenModule::EmitCXXDestructor(clang::CXXDestructorDecl
const*, clang::CXXDtorType) + 194
20 clang            0x0000000000736221
clang::CodeGen::CodeGenModule::EmitGlobalDefinition(clang::GlobalDecl) + 465
21 clang            0x0000000000737968
clang::CodeGen::CodeGenModule::EmitDeferred() + 216
22 clang            0x0000000000737979 clang::CodeGen::CodeGenModule::Release()
+ 9
23 clang            0x000000000072332b
24 clang            0x0000000000859bd2 clang::ParseAST(clang::Sema&, bool,
bool) + 498
25 clang            0x00000000005f50b1 clang::FrontendAction::Execute() + 97
26 clang            0x00000000005dc57a
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 282
27 clang            0x00000000005c5e92
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1378
28 clang            0x00000000005c0e88 cc1_main(char const**, char const**,
char const*, void*) + 1160
29 clang            0x00000000005bfd84 main + 7316
30 libc.so.6        0x00007f23a22d9ea5 __libc_start_main + 245
31 clang            0x00000000005c0889
Stack dump:
0.    Program arguments: /usr/bin/clang -cc1 -triple x86_64-pc-linux-gnu
-emit-obj -mrelax-all -disable-free -disable-llvm-verifier -main-file-name
MiniMap.cpp -mrelocation-model static -mdisable-fp-elim -relaxed-aliasing
-fmath-errno -masm-verbose -mconstructor-aliases -munwind-tables
-fuse-init-array -target-cpu x86-64 -target-linker-version 2.23.1
-momit-leaf-frame-pointer -g -D BOOST_NO_FENV_H -D
SPRING_DATADIR="/home/abma/local/spring/develop/share/games/spring" -D
STREFLOP_SSE -D SYNCCHECK -D USE_GML -D USE_GML_SIM -D USE_VALGRIND -D DEBUG -D
_DEBUG -D NO_CATCH_EXCEPTIONS -O0 -Wall -Wno-sign-compare -fdeprecated-macro
-ferror-limit 19 -fmessage-length 0 -fvisibility hidden
-fvisibility-inlines-hidden -pthread -mstackrealign -fobjc-runtime=gcc
-fcxx-exceptions -fexceptions -fdiagnostics-show-option -x c++
MiniMap-UMYYr8.cpp 
1.    <eof> parser at end of file
2.    Per-file LLVM IR generation
3.    rts/lib/gml/gmlcls.h:235:10: Generating code for declaration
'gmlBaseMutexLock<boost::unique_lock<boost::recursive_mutex>,
boost::recursive_mutex>::~gmlBaseMutexLock'
4.    rts/lib/gml/gmlcls.h:235:30: LLVM IR generation of compound statement
('{}')
5.    rts/lib/gml/gmlcls.h:236:23: LLVM IR generation of compound statement
('{}')
Segmentation fault (core dumped)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130411/83393259/attachment.html>

From bugzilla-daemon at llvm.org  Thu Apr 11 16:03:18 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 11 Apr 2013 23:03:18 +0000
Subject: [LLVMbugs] [Bug 14417] Due to base compiler upgrade,
 clang fails to generate binaries on DragonFly 3.2+
In-Reply-To: <bug-14417-206@http.llvm.org/bugs/>
References: <bug-14417-206@http.llvm.org/bugs/>
Message-ID: <bug-14417-206-tpaIYFcw0Y@http.llvm.org/bugs/>

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

John McCall <rjmccall at apple.com> changed:

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

--- Comment #7 from John McCall <rjmccall at apple.com> ---
Committed with some privately-discussed tweaks and a small change to the test
case as r179334.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130411/0a2e5175/attachment.html>

From bugzilla-daemon at llvm.org  Thu Apr 11 16:36:00 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 11 Apr 2013 23:36:00 +0000
Subject: [LLVMbugs] [Bug 15729] New: RuntimeDyld doesn't handle calls to
 external functions from MachO objects
Message-ID: <bug-15729-206@http.llvm.org/bugs/>

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

            Bug ID: 15729
           Summary: RuntimeDyld doesn't handle calls to external functions
                    from MachO objects
           Product: libraries
           Version: trunk
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Generic Execution Engine Support
          Assignee: unassignedbugs at nondot.org
          Reporter: andrew.kaylor at intel.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 10343
  --> http://llvm.org/bugs/attachment.cgi?id=10343&action=edit
sample code to reproduce the problem

RuntimeDyld fails with an assertion when trying to perform relocations on
generated code that contains a call to an external function.  The generated
code contains a relocation (which varies by architecture) that is not handled
by the RuntimeDyldMachO class.

Eran Weiss provided the attached sample code to reproduce the problem.

To reproduce:

$ /usr/bin/g++ `llvm-config --cxxflags` -g -m32 -c mcjit_external_symbol.cpp
$ /usr/bin/g++ `llvm-config --ldflags` -g -m32 -o mcjit_external_symbol
mcjit_external_symbol.o `llvm-config --libs all`
$ ./mcjit_external_symbol 
verifying... 
LLVM ERROR: Program used external function '_external' which could not be
resolved!


This same test case passes if the older JIT implementation is used.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130411/9d062a1a/attachment.html>

From bugzilla-daemon at llvm.org  Fri Apr 12 00:45:47 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 12 Apr 2013 07:45:47 +0000
Subject: [LLVMbugs] [Bug 15730] New: __attribute__((vector)) and templates
Message-ID: <bug-15730-206@http.llvm.org/bugs/>

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

            Bug ID: 15730
           Summary: __attribute__((vector)) and templates
           Product: clang
           Version: 3.2
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
          Assignee: unassignedclangbugs at nondot.org
          Reporter: giulio.eulisse at cern.ch
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Hi,

the following bit of code:

template <int N, typename T> struct Foo
{
  typedef T __attribute__((vector_size(N*sizeof(T)))) type;
};

compiles fine with gcc 4.7.2, however when compiled with clang 3.2 I get:

foo.cc:4:41: error: expected ')'
  typedef T __attribute__((vector_size(N*sizeof(T)))) type;
                                        ^
                                        )
foo.cc:4:41: error: expected ')'
  typedef T __attribute__((vector_size(N*sizeof(T)))) type;
                                        ^
                                        )
foo.cc:4:53: error: expected member name or ';' after declaration specifiers
  typedef T __attribute__((vector_size(N*sizeof(T)))) type;
  ~~~~~~~~~                                         ^

Moreover even doing:

template <int N, typename T> struct Foo
{
  typedef T __attribute__((vector_size(16))) type;
};

does not work and gives:

foo.cc:4:28: error: invalid vector element type 'T'
  typedef T __attribute__((vector_size(16))) type;
                           ^

The only way to get it to work is to eliminate the dependency on the T template
argument:

template <int N, typename T> struct Foo
{
  typedef int __attribute__((vector_size(16))) type;
};

compiles fine on both clang 3.2 and gcc 4.7.2

Any idea?

Ciao,
Giulio

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130412/f4d75694/attachment.html>

From bugzilla-daemon at llvm.org  Fri Apr 12 01:06:10 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 12 Apr 2013 08:06:10 +0000
Subject: [LLVMbugs] [Bug 15731] New: Bugzilla: Please update the category
	description
Message-ID: <bug-15731-206@http.llvm.org/bugs/>

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

            Bug ID: 15731
           Summary: Bugzilla: Please update the category description
           Product: Website
           Version: unspecified
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: General Website
          Assignee: unassignedbugs at nondot.org
          Reporter: sylvestre at debian.org
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

In the product list, we can see:
Build scripts:      Makefiles and autoconf

It should be updated to
Build system:      CMake, Makefiles and autoconf

Thanks

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130412/15eeeb7e/attachment.html>

From bugzilla-daemon at llvm.org  Fri Apr 12 01:08:18 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 12 Apr 2013 08:08:18 +0000
Subject: [LLVMbugs] [Bug 15732] New: [META] CMake build equivalent to the
 autotools build
Message-ID: <bug-15732-206@http.llvm.org/bugs/>

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

            Bug ID: 15732
           Summary: [META] CMake build equivalent to the autotools build
           Product: Build scripts
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: cmake
          Assignee: unassignedbugs at nondot.org
          Reporter: sylvestre at debian.org
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

This is a meta-bug for issues compiling the LLVM toolchain using CMake instead
of using the autotools.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130412/1dbee911/attachment.html>

From bugzilla-daemon at llvm.org  Fri Apr 12 01:14:30 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 12 Apr 2013 08:14:30 +0000
Subject: [LLVMbugs] [Bug 15733] New: -Wunsequenced false positive for code
 involving lambdas
Message-ID: <bug-15733-206@http.llvm.org/bugs/>

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

            Bug ID: 15733
           Summary: -Wunsequenced false positive for code involving
                    lambdas
           Product: clang
           Version: trunk
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Static Analyzer
          Assignee: kremenek at apple.com
          Reporter: zeratul976 at hotmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

When compiling the following code with -Wall:


struct A
{
    A() {};

    template <typename T>
    int operator=(T) const;
};


struct B           
{
    B foo(int);
};

template <typename T>
void waldo()
{
    A a;
    B b;
    b.foo(a = []{}).foo(a = []{});
}


clang produces the following warning: 


test.cpp:20:13: warning: multiple unsequenced modifications to 'a'
[-Wunsequenced]
    b.foo(a = []{}).foo(a = []{});
            ^             ~


This is a false positive because the assignment operator that's supposedly
modifying 'a' is const, and thus does no such thing.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130412/2b5c2582/attachment.html>

From bugzilla-daemon at llvm.org  Fri Apr 12 01:33:24 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 12 Apr 2013 08:33:24 +0000
Subject: [LLVMbugs] [Bug 15727] Value::isUsedInBasicBlock is buggy.
In-Reply-To: <bug-15727-206@http.llvm.org/bugs/>
References: <bug-15727-206@http.llvm.org/bugs/>
Message-ID: <bug-15727-206-nBqSSpDAOn@http.llvm.org/bugs/>

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

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> ---
Fixed in r179370, thanks!

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130412/078ecddf/attachment.html>

From bugzilla-daemon at llvm.org  Fri Apr 12 02:31:51 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 12 Apr 2013 09:31:51 +0000
Subject: [LLVMbugs] [Bug 15734] New: seg fault in clang frontend triggered
 by std::is_trivially_default_destructible<std::vector<int>>
Message-ID: <bug-15734-206@http.llvm.org/bugs/>

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

            Bug ID: 15734
           Summary: seg fault in clang frontend triggered by
                    std::is_trivially_default_destructible<std::vector<int
                    >>
           Product: clang
           Version: 3.2
          Hardware: Macintosh
                OS: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
          Assignee: unassignedclangbugs at nondot.org
          Reporter: wd11 at leicester.ac.uk
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

clang++ -std=c++11 -stdlib=libc++ crashes upon processing
std::is_trivially_default_constructible<std::vector<int>>.

source is trivial, preprocessed source attached (sorry, cannot attach run
script as I can only attach one file here).
crash backtrace:


clang version 3.2 (tags/RELEASE_32/final)
Target: x86_64-apple-darwin12.3.0
Thread model: posix
 "/opt/local/share/clang-32/bin/clang" -cc1 -triple x86_64-apple-macosx10.8.0
-emit-obj -mrelax-all -disable-free -disable-llvm-verifier -main-file-name
test1.cc -mrelocation-model pic -pic-level 2 -mdisable-fp-elim -masm-verbose
-munwind-tables -target-cpu core2 -target-linker-version 134.9 -v -resource-dir
/opt/local/share/clang-32/bin/../lib/clang/3.2 -fmodule-cache-path
/var/folders/n5/bcfvl8s53ds0g8slrlcwnk9m0000gq/T/clang-module-cache
-I/Users/walter/code/tbb41_20121003oss//include
-I/Users/walter/code/tbb41_20121003oss//include -stdlib=libc++ -std=c++11
-fdeprecated-macro -fdebug-compilation-dir /Users/walter1/nemo/usr/dehnen/utils
-ferror-limit 19 -fmessage-length 167 -stack-protector 1 -mstackrealign
-fblocks -fobjc-runtime=macosx-10.8.0 -fobjc-dispatch-method=mixed
-fobjc-default-synthesize-properties -fencode-extended-block-signature
-fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o
/var/folders/n5/bcfvl8s53ds0g8slrlcwnk9m0000gq/T/test1-mmEPFD.o -x c++ test1.cc
clang -cc1 version 3.2 based upon LLVM 3.2svn default target
x86_64-apple-darwin12.3.0
ignoring nonexistent directory "/opt/local/share/clang-32/bin/../lib/c++/v1"
ignoring nonexistent directory "/usr/local/include"
ignoring duplicate directory "/Users/walter/code/tbb41_20121003oss//include"
#include "..." search starts here:
#include <...> search starts here:
 /Users/walter/code/tbb41_20121003oss//include
 /usr/include/c++/v1
 /opt/local/share/clang-32/bin/../lib/clang/3.2/include
 /usr/include
 /System/Library/Frameworks (framework directory)
 /Library/Frameworks (framework directory)
End of search list.
0  clang             0x0000000103e69005
llvm::SmallVectorImpl<char>::swap(llvm::SmallVectorImpl<char>&) + 13189
1  clang             0x0000000103e69424
llvm::SmallVectorImpl<char>::swap(llvm::SmallVectorImpl<char>&) + 14244
2  libsystem_c.dylib 0x00007fff8871c94a _sigtramp + 26
3  clang             0x0000000102d7056c std::vector<std::pair<llvm::Constant*,
int>, std::allocator<std::pair<llvm::Constant*, int> >
>::_M_insert_aux(__gnu_cxx::__normal_iterator<std::pair<llvm::Constant*, int>*,
std::vector<std::pair<llvm::Constant*, int>,
std::allocator<std::pair<llvm::Constant*, int> > > >,
std::pair<llvm::Constant*, int> const&) + 14908
4  clang             0x0000000102f8bd31 llvm::SmallVectorImpl<unsigned
int>::swap(llvm::SmallVectorImpl<unsigned int>&) + 22705
5  clang             0x0000000102f8c4d6 llvm::SmallVectorImpl<unsigned
int>::swap(llvm::SmallVectorImpl<unsigned int>&) + 24662
6  clang             0x0000000102f6f52e
llvm::SmallVectorImpl<clang::sema::FunctionScopeInfo::WeakUseTy>::operator=(llvm::SmallVectorImpl<clang::sema::FunctionScopeInfo::WeakUseTy>
const&) + 171294
7  clang             0x0000000102f6e0e8
llvm::SmallVectorImpl<clang::sema::FunctionScopeInfo::WeakUseTy>::operator=(llvm::SmallVectorImpl<clang::sema::FunctionScopeInfo::WeakUseTy>
const&) + 166104
8  clang             0x0000000102f5217e
llvm::SmallVectorImpl<clang::sema::FunctionScopeInfo::WeakUseTy>::operator=(llvm::SmallVectorImpl<clang::sema::FunctionScopeInfo::WeakUseTy>
const&) + 51566
9  clang             0x0000000103042883
llvm::SmallVectorImpl<clang::DeducedTemplateArgument>::operator=(llvm::SmallVectorImpl<clang::DeducedTemplateArgument>
const&) + 65187
10 clang             0x00000001030498bc
llvm::SmallVectorImpl<clang::DeducedTemplateArgument>::operator=(llvm::SmallVectorImpl<clang::DeducedTemplateArgument>
const&) + 93916
11 clang             0x000000010304a2bf
llvm::SmallVectorImpl<clang::DeducedTemplateArgument>::operator=(llvm::SmallVectorImpl<clang::DeducedTemplateArgument>
const&) + 96479
12 clang             0x00000001030370b1
llvm::SmallVectorImpl<clang::DeducedTemplateArgument>::operator=(llvm::SmallVectorImpl<clang::DeducedTemplateArgument>
const&) + 18129
13 clang             0x0000000103035884
llvm::SmallVectorImpl<clang::DeducedTemplateArgument>::operator=(llvm::SmallVectorImpl<clang::DeducedTemplateArgument>
const&) + 11940
14 clang             0x000000010303ad9f
llvm::SmallVectorImpl<clang::DeducedTemplateArgument>::operator=(llvm::SmallVectorImpl<clang::DeducedTemplateArgument>
const&) + 33727
15 clang             0x000000010303b481
llvm::SmallVectorImpl<clang::DeducedTemplateArgument>::operator=(llvm::SmallVectorImpl<clang::DeducedTemplateArgument>
const&) + 35489
16 clang             0x000000010303c816
llvm::SmallVectorImpl<clang::DeducedTemplateArgument>::operator=(llvm::SmallVectorImpl<clang::DeducedTemplateArgument>
const&) + 40502
17 clang             0x0000000103075e8f
llvm::SmallVectorImpl<clang::Decl*>::operator=(llvm::SmallVectorImpl<clang::Decl*>
const&) + 108383
18 clang             0x0000000102eb8c79
llvm::SmallVectorImpl<clang::sema::DelayedDiagnostic>::operator=(llvm::SmallVectorImpl<clang::sema::DelayedDiagnostic>
const&) + 13497
19 clang             0x000000010303b020
llvm::SmallVectorImpl<clang::DeducedTemplateArgument>::operator=(llvm::SmallVectorImpl<clang::DeducedTemplateArgument>
const&) + 34368
20 clang             0x000000010303b481
llvm::SmallVectorImpl<clang::DeducedTemplateArgument>::operator=(llvm::SmallVectorImpl<clang::DeducedTemplateArgument>
const&) + 35489
21 clang             0x000000010303c816
llvm::SmallVectorImpl<clang::DeducedTemplateArgument>::operator=(llvm::SmallVectorImpl<clang::DeducedTemplateArgument>
const&) + 40502
22 clang             0x0000000103075e8f
llvm::SmallVectorImpl<clang::Decl*>::operator=(llvm::SmallVectorImpl<clang::Decl*>
const&) + 108383
23 clang             0x0000000102e1cc84 std::vector<std::pair<unsigned int,
clang::SourceLocation>, std::allocator<std::pair<unsigned int,
clang::SourceLocation> >
>::_M_insert_aux(__gnu_cxx::__normal_iterator<std::pair<unsigned int,
clang::SourceLocation>*, std::vector<std::pair<unsigned int,
clang::SourceLocation>, std::allocator<std::pair<unsigned int,
clang::SourceLocation> > > >, std::pair<unsigned int, clang::SourceLocation>
const&) + 2052
24 clang             0x0000000102e7915c std::_Rb_tree<clang::NamespaceDecl*,
std::pair<clang::NamespaceDecl* const, clang::NamespaceDecl*>,
std::_Select1st<std::pair<clang::NamespaceDecl* const, clang::NamespaceDecl*>
>, std::less<clang::NamespaceDecl*>,
std::allocator<std::pair<clang::NamespaceDecl* const, clang::NamespaceDecl*> >
>::_M_erase(std::_Rb_tree_node<std::pair<clang::NamespaceDecl* const,
clang::NamespaceDecl*> >*) + 860
25 clang             0x0000000102de5141
llvm::SmallVectorTemplateBase<clang::ParsedTemplateArgument,
false>::grow(unsigned long) + 33441
26 clang             0x0000000102de5440
llvm::SmallVectorTemplateBase<clang::ParsedTemplateArgument,
false>::grow(unsigned long) + 34208
27 clang             0x0000000102dae854 std::vector<clang::IdentifierInfo*,
std::allocator<clang::IdentifierInfo*>
>::_M_insert_aux(__gnu_cxx::__normal_iterator<clang::IdentifierInfo**,
std::vector<clang::IdentifierInfo*, std::allocator<clang::IdentifierInfo*> > >,
clang::IdentifierInfo* const&) + 20820
28 clang             0x0000000102daa1da std::vector<clang::IdentifierInfo*,
std::allocator<clang::IdentifierInfo*>
>::_M_insert_aux(__gnu_cxx::__normal_iterator<clang::IdentifierInfo**,
std::vector<clang::IdentifierInfo*, std::allocator<clang::IdentifierInfo*> > >,
clang::IdentifierInfo* const&) + 2778
29 clang             0x0000000102da9a81 std::vector<clang::IdentifierInfo*,
std::allocator<clang::IdentifierInfo*>
>::_M_insert_aux(__gnu_cxx::__normal_iterator<clang::IdentifierInfo**,
std::vector<clang::IdentifierInfo*, std::allocator<clang::IdentifierInfo*> > >,
clang::IdentifierInfo* const&) + 897
30 clang             0x0000000102da996e std::vector<clang::IdentifierInfo*,
std::allocator<clang::IdentifierInfo*>
>::_M_insert_aux(__gnu_cxx::__normal_iterator<clang::IdentifierInfo**,
std::vector<clang::IdentifierInfo*, std::allocator<clang::IdentifierInfo*> > >,
clang::IdentifierInfo* const&) + 622
31 clang             0x0000000102dd00f3 std::vector<clang::IdentifierInfo*,
std::allocator<clang::IdentifierInfo*>
>::_M_insert_aux(__gnu_cxx::__normal_iterator<clang::IdentifierInfo**,
std::vector<clang::IdentifierInfo*, std::allocator<clang::IdentifierInfo*> > >,
clang::IdentifierInfo* const&) + 158195
32 clang             0x0000000102dcfc61 std::vector<clang::IdentifierInfo*,
std::allocator<clang::IdentifierInfo*>
>::_M_insert_aux(__gnu_cxx::__normal_iterator<clang::IdentifierInfo**,
std::vector<clang::IdentifierInfo*, std::allocator<clang::IdentifierInfo*> > >,
clang::IdentifierInfo* const&) + 157025
33 clang             0x0000000102dcf30a std::vector<clang::IdentifierInfo*,
std::allocator<clang::IdentifierInfo*>
>::_M_insert_aux(__gnu_cxx::__normal_iterator<clang::IdentifierInfo**,
std::vector<clang::IdentifierInfo*, std::allocator<clang::IdentifierInfo*> > >,
clang::IdentifierInfo* const&) + 154634
34 clang             0x0000000102dd59cf std::vector<clang::IdentifierInfo*,
std::allocator<clang::IdentifierInfo*>
>::_M_insert_aux(__gnu_cxx::__normal_iterator<clang::IdentifierInfo**,
std::vector<clang::IdentifierInfo*, std::allocator<clang::IdentifierInfo*> > >,
clang::IdentifierInfo* const&) + 180943
35 clang             0x0000000102dd75bf std::vector<clang::IdentifierInfo*,
std::allocator<clang::IdentifierInfo*>
>::_M_insert_aux(__gnu_cxx::__normal_iterator<clang::IdentifierInfo**,
std::vector<clang::IdentifierInfo*, std::allocator<clang::IdentifierInfo*> > >,
clang::IdentifierInfo* const&) + 188095
36 clang             0x0000000102de4006
llvm::SmallVectorTemplateBase<clang::ParsedTemplateArgument,
false>::grow(unsigned long) + 29030
37 clang             0x0000000102d904cf std::vector<std::pair<llvm::WeakVH,
llvm::Constant*>, std::allocator<std::pair<llvm::WeakVH, llvm::Constant*> >
>::_M_insert_aux(__gnu_cxx::__normal_iterator<std::pair<llvm::WeakVH,
llvm::Constant*>*, std::vector<std::pair<llvm::WeakVH, llvm::Constant*>,
std::allocator<std::pair<llvm::WeakVH, llvm::Constant*> > > >,
std::pair<llvm::WeakVH, llvm::Constant*> const&) + 109567
38 clang             0x0000000102de3798
llvm::SmallVectorTemplateBase<clang::ParsedTemplateArgument,
false>::grow(unsigned long) + 26872
39 clang             0x0000000102de3303
llvm::SmallVectorTemplateBase<clang::ParsedTemplateArgument,
false>::grow(unsigned long) + 25699
40 clang             0x0000000102de2920
llvm::SmallVectorTemplateBase<clang::ParsedTemplateArgument,
false>::grow(unsigned long) + 23168
41 clang             0x0000000102de2014
llvm::SmallVectorTemplateBase<clang::ParsedTemplateArgument,
false>::grow(unsigned long) + 20852
42 clang             0x0000000102d85256 std::vector<std::pair<llvm::WeakVH,
llvm::Constant*>, std::allocator<std::pair<llvm::WeakVH, llvm::Constant*> >
>::_M_insert_aux(__gnu_cxx::__normal_iterator<std::pair<llvm::WeakVH,
llvm::Constant*>*, std::vector<std::pair<llvm::WeakVH, llvm::Constant*>,
std::allocator<std::pair<llvm::WeakVH, llvm::Constant*> > > >,
std::pair<llvm::WeakVH, llvm::Constant*> const&) + 63878
43 clang             0x0000000102d4ed9a std::vector<clang::CXXRecordDecl
const*, std::allocator<clang::CXXRecordDecl const*>
>::_M_insert_aux(__gnu_cxx::__normal_iterator<clang::CXXRecordDecl const**,
std::vector<clang::CXXRecordDecl const*, std::allocator<clang::CXXRecordDecl
const*> > >, clang::CXXRecordDecl const* const&) + 4282
44 clang             0x0000000102b71036 std::_Rb_tree<clang::edit::FileOffset,
std::pair<clang::edit::FileOffset const, clang::edit::EditedSource::FileEdit>,
std::_Select1st<std::pair<clang::edit::FileOffset const,
clang::edit::EditedSource::FileEdit> >, std::less<clang::edit::FileOffset>,
std::allocator<std::pair<clang::edit::FileOffset const,
clang::edit::EditedSource::FileEdit> >
>::_M_erase(std::_Rb_tree_node<std::pair<clang::edit::FileOffset const,
clang::edit::EditedSource::FileEdit> >*) + 4422
45 clang             0x0000000102b5435d 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&) + 14477
46 clang             0x0000000102b23c96 std::_Rb_tree<std::string, std::string,
std::_Identity<std::string>, std::less<std::string>,
std::allocator<std::string> >::_M_insert_unique(std::string const&) + 4278
47 clang             0x0000000102b1bf59
48 clang             0x0000000102b20663 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&) +
3507
49 clang             0x0000000102b1bc34
Stack dump:
0.    Program arguments: /opt/local/share/clang-32/bin/clang -cc1 -triple
x86_64-apple-macosx10.8.0 -emit-obj -mrelax-all -disable-free
-disable-llvm-verifier -main-file-name test1.cc -mrelocation-model pic
-pic-level 2 -mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu core2
-target-linker-version 134.9 -v -resource-dir
/opt/local/share/clang-32/bin/../lib/clang/3.2 -fmodule-cache-path
/var/folders/n5/bcfvl8s53ds0g8slrlcwnk9m0000gq/T/clang-module-cache
-I/Users/walter/code/tbb41_20121003oss//include
-I/Users/walter/code/tbb41_20121003oss//include -stdlib=libc++ -std=c++11
-fdeprecated-macro -fdebug-compilation-dir /Users/walter1/nemo/usr/dehnen/utils
-ferror-limit 19 -fmessage-length 167 -stack-protector 1 -mstackrealign
-fblocks -fobjc-runtime=macosx-10.8.0 -fobjc-dispatch-method=mixed
-fobjc-default-synthesize-properties -fencode-extended-block-signature
-fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o
/var/folders/n5/bcfvl8s53ds0g8slrlcwnk9m0000gq/T/test1-mmEPFD.o -x c++ test1.cc 
1.    test1.cc:9:70: current parser token 'value'
2.    test1.cc:6:1: parsing function body 'main'
3.    test1.cc:6:1: in compound statement ('{}')
clang: error: unable to execute command: Segmentation fault: 11
clang: error: clang frontend command failed due to signal (use -v to see
invocation)
clang version 3.2 (tags/RELEASE_32/final)
Target: x86_64-apple-darwin12.3.0
Thread model: posix

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130412/dd388480/attachment.html>

From bugzilla-daemon at llvm.org  Fri Apr 12 04:11:41 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 12 Apr 2013 11:11:41 +0000
Subject: [LLVMbugs] [Bug 15735] New: list-initialization of array
 new-expression requires declared default constructor
Message-ID: <bug-15735-206@http.llvm.org/bugs/>

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

            Bug ID: 15735
           Summary: list-initialization of array new-expression requires
                    declared default constructor
           Product: clang
           Version: 3.2
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++11
          Assignee: unassignedclangbugs at nondot.org
          Reporter: ed at catmur.co.uk
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified

struct S { S(int) {} S() = delete; };
int main() { new S[5] { 0, 1, 2, 3, 4 }; }

source.cpp:2:23: error: call to deleted constructor of 'S'
int main() { new S[5] { 0, 1, 2, 3, 4 }; }
                      ^
source.cpp:1:20: note: function has been explicitly marked deleted here
struct S { S(int) {} S() = delete; };
                     ^

If a default constructor is declared non-deleted and accessible the code
compiles, even though it is not called (it does not need to be defined).

g++ compiles this fine.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130412/a524e703/attachment.html>

From bugzilla-daemon at llvm.org  Fri Apr 12 07:59:03 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 12 Apr 2013 14:59:03 +0000
Subject: [LLVMbugs] [Bug 15736] New: variable with constant initializer is
	dependent
Message-ID: <bug-15736-206@http.llvm.org/bugs/>

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

            Bug ID: 15736
           Summary: variable with constant initializer is dependent
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
          Assignee: unassignedclangbugs at nondot.org
          Reporter: vanyacpp at gmail.com
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Variable with constant initializer is considered dependent currently. That is
why clang do not print error on the following code:

template <int N>
struct x
{
    static const int M = 10;

    typedef typename x<M>::asdf mytype2;
};

GCC understand that M is not dependent and print error message:

12.cpp:6:28: error: 'asdf' in 'struct x<10>' does not name a type

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130412/4545d642/attachment.html>

From bugzilla-daemon at llvm.org  Fri Apr 12 08:21:50 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 12 Apr 2013 15:21:50 +0000
Subject: [LLVMbugs] [Bug 15723] Incorrect handling of out of bounds and
 strings starting from 0x
In-Reply-To: <bug-15723-206@http.llvm.org/bugs/>
References: <bug-15723-206@http.llvm.org/bugs/>
Message-ID: <bug-15723-206-H7qwosbVHF@http.llvm.org/bugs/>

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

Howard Hinnant <hhinnant at apple.com> changed:

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

--- Comment #3 from Howard Hinnant <hhinnant at apple.com> ---
2.  "0x0" fails for the same reasons.

3.  This is the exact same test as 2.

4.  Fails because ss.fail() is false.  Value of ld is 1.79769e+3081

5.  Fails because ss.fail() is false.  Value of ld is 1.79769e+3089

6.  Fails because ss.fail() is false.  Value of ld is 1.17977e+309

7.  Fails because ss.fail() is false.  Value of ld is 9.17977e+309

For me: std::numeric_limits<long double>::max() ==
1.189731495357231765021264e+4932

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130412/48f96fb7/attachment.html>

From bugzilla-daemon at llvm.org  Fri Apr 12 09:54:21 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 12 Apr 2013 16:54:21 +0000
Subject: [LLVMbugs] [Bug 9703] MC/COFF and MC/ELF tests fail because Windows
 MKS runs elf-dump instead of elf-dump.bat (etc.)
In-Reply-To: <bug-9703-206@http.llvm.org/bugs/>
References: <bug-9703-206@http.llvm.org/bugs/>
Message-ID: <bug-9703-206-FVo5GYo6gS@http.llvm.org/bugs/>

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

Nico Rieck <nico.rieck at gmail.com> changed:

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

--- Comment #2 from Nico Rieck <nico.rieck at gmail.com> ---
Since elf-dump has been removed, this shouldn't be a problem anymore.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130412/5c9ea1c8/attachment.html>

From bugzilla-daemon at llvm.org  Fri Apr 12 13:45:28 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 12 Apr 2013 20:45:28 +0000
Subject: [LLVMbugs] [Bug 15737] New: Assert when combining an AND of two
	FCMPs.
Message-ID: <bug-15737-206@http.llvm.org/bugs/>

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

            Bug ID: 15737
           Summary: Assert when combining an AND of two FCMPs.
           Product: clang
           Version: trunk
          Hardware: Macintosh
                OS: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: cameron.mcinally at nyu.edu
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 10346
  --> http://llvm.org/bugs/attachment.cgi?id=10346&action=edit
Tarball of preprocessed source, run script, and backtrace.

When compiling this function at -O2, Clang issues an assert:

int kung( float a, double b ) {
  return (a == a) & (b == b);
}

The assert is:

Assertion failed: (getOperand(0)->getType() == getOperand(1)->getType() &&
"Both operands to FCmp instruction are not of the same type!"), function
FCmpInst, file /Users/xkrebstarx/clang/llvm/include/llvm/IR/Instructions.h,
line 1117.


We begin with a float "a" and double "b":

> (fcmp oeq a, a) & (fcmp oeq b, b) 

After canonicalization in InstCombine, we end up with the expression:

> (fcmp ord a, 0.0) & (fcmp ord b, 0.0)

The bug manifest is in InstCombiner::FoldAndOfFCmps(FCmpInst *LHS, FCmpInst
*RHS), when trying to perform this transformation:

> (fcmp ord x, c) & (fcmp ord y, c)  -> (fcmp ord x, y)

This is all fine, except that the FCmpInst constructor in the IRBuilder
requires that both operands to the new fcmp are the same type, which they are
not.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130412/597dd16a/attachment.html>

From bugzilla-daemon at llvm.org  Fri Apr 12 14:56:54 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 12 Apr 2013 21:56:54 +0000
Subject: [LLVMbugs] [Bug 15737] Assert when combining an AND of two FCMPs.
In-Reply-To: <bug-15737-206@http.llvm.org/bugs/>
References: <bug-15737-206@http.llvm.org/bugs/>
Message-ID: <bug-15737-206-XjjVopF60j@http.llvm.org/bugs/>

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

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> ---
Fixed in r179417.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130412/e59d65f6/attachment.html>

From bugzilla-daemon at llvm.org  Fri Apr 12 18:49:26 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 13 Apr 2013 01:49:26 +0000
Subject: [LLVMbugs] [Bug 14115] clang assertion failure on incompatible
 std::vector comparison.
In-Reply-To: <bug-14115-206@http.llvm.org/bugs/>
References: <bug-14115-206@http.llvm.org/bugs/>
Message-ID: <bug-14115-206-46997qAIQ5@http.llvm.org/bugs/>

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

rtrieu at google.com changed:

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

--- Comment #4 from rtrieu at google.com ---
Given:

template<class> class base {};
template<class> class vector : base<int> {};
template<class T> void f(const vector<T>& x, const vector<T>& y) {}

int main() {
  vector<int> a;
  vector<float> b;
  f(a, b);
}

Clang now produces this message instead of crashing:

pr14115.cc:9:3: error: no matching function for call to 'f'
  f(a, b);
  ^
pr14115.cc:4:24: note: candidate template ignored: deduced conflicting types
for parameter 'T' ('int' vs. 'float')
template<class T> void f(const vector<T>& x, const vector<T>& y) {}

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130413/2805e421/attachment.html>

From bugzilla-daemon at llvm.org  Fri Apr 12 23:35:26 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 13 Apr 2013 06:35:26 +0000
Subject: [LLVMbugs] [Bug 15738] New: loop and casting causes clang to hang
	at -O2
Message-ID: <bug-15738-206@http.llvm.org/bugs/>

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

            Bug ID: 15738
           Summary: loop and casting causes clang to hang at -O2
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: LLVM Codegen
          Assignee: unassignedclangbugs at nondot.org
          Reporter: dhazeghi at yahoo.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

The following testcase causes current clang trunk to go into and infinite loop
(hang) when compiled at -O2 and above.

$ clang -v
clang version 3.3 (trunk 179371)
Target: x86_64-pc-linux-gnu
Thread model: posix
$ clang -O1 -c small.c
$ clang -O2 -c small.c
^C
$ cat small.c
struct
{
    int f0;
}
a;
int b, c, d, e;
void fn1 ();
void fn2 ()
{
    fn1 ();
}

void
fn1 ()
{
    int *f = &c, *g = &a.f0;
    *g = (int)f;
    b = 0;
    for (; b != 60; ++b)
    {
        e = (*g > (d = 0)) % 5;
        *g = 0 == e - *g * 80;
    }
}

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130413/bb4d4957/attachment.html>

From bugzilla-daemon at llvm.org  Sat Apr 13 02:53:11 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 13 Apr 2013 09:53:11 +0000
Subject: [LLVMbugs] [Bug 15739] New: explicit specialization of 'instance'
 after instantiation
Message-ID: <bug-15739-206@http.llvm.org/bugs/>

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

            Bug ID: 15739
           Summary: explicit specialization of 'instance' after
                    instantiation
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
          Assignee: unassignedclangbugs at nondot.org
          Reporter: dimhen at gmail.com
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified

clang version 3.3 (trunk 179456)
$ /home/dimhen/build/csa/Release+Asserts/bin/clang++ -fsyntax-only
specialization.ii
specialization.ii:26:57: error: explicit specialization of 'instance' after
instantiation
         0 > ChoiceValueTraitsT < DVCS_DigestInfo, 0 >::instance =
                                                        ^
specialization.ii:22:39: note: implicit instantiation first required here
               A::t_messageImprint >::instance;
                                      ^
specialization.ii:27:14: error: cannot refer to class template
'ChoiceValueTraitsT' without a template argument list
             ChoiceValueTraitsT ();
             ^
specialization.ii:12:30: note: template is declared here
template < class, int >class ChoiceValueTraitsT:public B
                             ^
2 errors generated.
$ cat specialization.ii
struct DVCS_DigestInfo;
class A
{
public:
    enum Type
    { t_messageImprint };
}
;
class B
{
};
template < class, int >class ChoiceValueTraitsT:public B
{
public:
    static const ChoiceValueTraitsT instance;
};
class C
{
    const B *findTraits ()
    {
        return &ChoiceValueTraitsT < DVCS_DigestInfo,
               A::t_messageImprint >::instance;
    }
};
template <> const ChoiceValueTraitsT < DVCS_DigestInfo,
         0 > ChoiceValueTraitsT < DVCS_DigestInfo, 0 >::instance =
             ChoiceValueTraitsT ();

g++ (3.4.6, 4.7.2 and 4.9) compiles this code

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130413/8914c801/attachment.html>

From bugzilla-daemon at llvm.org  Sat Apr 13 04:06:49 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 13 Apr 2013 11:06:49 +0000
Subject: [LLVMbugs] [Bug 15740] New: Long octals from strings using
	stringstreams
Message-ID: <bug-15740-206@http.llvm.org/bugs/>

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

            Bug ID: 15740
           Summary: Long octals from strings using stringstreams
           Product: libc++
           Version: unspecified
          Hardware: Macintosh
                OS: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: All Bugs
          Assignee: hhinnant at apple.com
          Reporter: luke.clemente at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

The following works with libstdc++. Tested using current svn.

#include <sstream>
#include <cassert>

int main() {
  std::stringstream ss;
  long l;
  // This works
  ss.str("01777777777777777777777");
  ss >> std::oct >> l;
  assert(ss.fail());
  // This doesn't work
  ss.clear();
  ss.str("0000000000000000001777777777777777777777");
  ss >> std::oct >> l;
  assert(ss.fail());
}

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130413/b0da6185/attachment.html>

From bugzilla-daemon at llvm.org  Sat Apr 13 05:34:45 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 13 Apr 2013 12:34:45 +0000
Subject: [LLVMbugs] [Bug 15738] loop and casting causes clang to hang at -O2
In-Reply-To: <bug-15738-206@http.llvm.org/bugs/>
References: <bug-15738-206@http.llvm.org/bugs/>
Message-ID: <bug-15738-206-4aO4HoDJpx@http.llvm.org/bugs/>

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

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

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

--- Comment #1 from Benjamin Kramer <benny.kra at gmail.com> ---


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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130413/66990432/attachment.html>

From bugzilla-daemon at llvm.org  Sat Apr 13 06:19:44 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 13 Apr 2013 13:19:44 +0000
Subject: [LLVMbugs] [Bug 15741] New: ICE on invalid 'class { template {
	typename {'
Message-ID: <bug-15741-206@http.llvm.org/bugs/>

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

            Bug ID: 15741
           Summary: ICE on invalid 'class { template { typename {'
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
          Assignee: unassignedclangbugs at nondot.org
          Reporter: dimhen at gmail.com
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified

$ cat x.ii
              class    {                     template<typename          {   $

No EOL at EOF

$ clang++ -fsyntax-only x.ii
x.ii:1:76: error: expected a qualified name after 'typename'
              class    {                     template<typename             {    
                                                                           ^
x.ii:1:76: error: expected ',' or '>' in template-parameter-list
x.ii:1:83: error: expected member name or ';' after declaration specifiers
clang: /home/dimhen/src/llvm/tools/clang/lib/Frontend/TextDiagnostic.cpp:969:
void highlightRange(const clang::CharSourceRange&, unsigned int, clang::FileID,
const {anonymous}::SourceColumnMap&, std::string&, const clang::SourceManager&,
const clang::LangOptions&): Assertion `StartColNo <= EndColNo && "Trying to
highlight whitespace??"' failed.
0  clang           0x0000000001dba142 llvm::sys::PrintStackTrace(_IO_FILE*) +
34
1  clang           0x0000000001db9d99
2  libpthread.so.0 0x0000003eb020f000
3  libc.so.6       0x0000003eafa35ba5 gsignal + 53
4  libc.so.6       0x0000003eafa37358 abort + 328
5  libc.so.6       0x0000003eafa2e972
6  libc.so.6       0x0000003eafa2ea22
7  clang           0x00000000006bcd41
clang::TextDiagnostic::emitSnippetAndCaret(clang::SourceLocation,
clang::DiagnosticsEngine::Level,
llvm::SmallVectorImpl<clang::CharSourceRange>&,
llvm::ArrayRef<clang::FixItHint>, clang::SourceManager const&) + 9137
8  clang           0x00000000006aeea1
clang::DiagnosticRenderer::emitCaret(clang::SourceLocation,
clang::DiagnosticsEngine::Level, llvm::ArrayRef<clang::CharSourceRange>,
llvm::ArrayRef<clang::FixItHint>, clang::SourceManager const&) + 145
9  clang           0x00000000006b008d
clang::DiagnosticRenderer::emitDiagnostic(clang::SourceLocation,
clang::DiagnosticsEngine::Level, llvm::StringRef,
llvm::ArrayRef<clang::CharSourceRange>, llvm::ArrayRef<clang::FixItHint>,
clang::SourceManager const*, llvm::PointerUnion<clang::Diagnostic const*,
clang::StoredDiagnostic const*>) + 765
10 clang           0x000000000067d2a2
clang::TextDiagnosticPrinter::HandleDiagnostic(clang::DiagnosticsEngine::Level,
clang::Diagnostic const&) + 898
11 clang           0x00000000012c2534
clang::DiagnosticIDs::EmitDiag(clang::DiagnosticsEngine&,
clang::DiagnosticIDs::Level) const + 52
12 clang           0x00000000012c27b5
clang::DiagnosticIDs::ProcessDiag(clang::DiagnosticsEngine&) const + 341
13 clang           0x00000000012bb524
clang::DiagnosticsEngine::EmitCurrentDiagnostic(bool) + 36
14 clang           0x0000000000629700
15 clang           0x00000000009738b8
clang::Parser::ParseDirectDeclarator(clang::Declarator&) + 2344
16 clang           0x000000000096ddc7
clang::Parser::ParseDeclaratorInternal(clang::Declarator&, void
(clang::Parser::*)(clang::Declarator&)) + 199
17 clang           0x000000000096e462
clang::Parser::ParseDeclarator(clang::Declarator&) + 18
18 clang           0x000000000097d68f
clang::Parser::ParseCXXClassMemberDeclaration(clang::AccessSpecifier,
clang::AttributeList*, clang::Parser::ParsedTemplateInfo const&,
clang::ParsingDeclRAIIObject*) + 687
19 clang           0x00000000009c2796
clang::Parser::ParseSingleDeclarationAfterTemplate(unsigned int,
clang::Parser::ParsedTemplateInfo const&, clang::ParsingDeclRAIIObject&,
clang::SourceLocation&, clang::AccessSpecifier, clang::AttributeList*) + 4150
20 clang           0x00000000009c2f8a
clang::Parser::ParseTemplateDeclarationOrSpecialization(unsigned int,
clang::SourceLocation&, clang::AccessSpecifier, clang::AttributeList*) + 698
21 clang           0x00000000009c345e
clang::Parser::ParseDeclarationStartingWithTemplate(unsigned int,
clang::SourceLocation&, clang::AccessSpecifier, clang::AttributeList*) + 158
22 clang           0x000000000097dc30
clang::Parser::ParseCXXClassMemberDeclaration(clang::AccessSpecifier,
clang::AttributeList*, clang::Parser::ParsedTemplateInfo const&,
clang::ParsingDeclRAIIObject*) + 2128
23 clang           0x000000000097fa84
clang::Parser::ParseCXXMemberSpecification(clang::SourceLocation,
clang::SourceLocation, clang::Parser::ParsedAttributesWithRange&, unsigned int,
clang::Decl*) + 1476
24 clang           0x0000000000981c7b
clang::Parser::ParseClassSpecifier(clang::tok::TokenKind,
clang::SourceLocation, clang::DeclSpec&, clang::Parser::ParsedTemplateInfo
const&, clang::AccessSpecifier, bool, clang::Parser::DeclSpecContext,
clang::Parser::ParsedAttributesWithRange&) + 3883
25 clang           0x0000000000969085
clang::Parser::ParseDeclarationSpecifiers(clang::DeclSpec&,
clang::Parser::ParsedTemplateInfo const&, clang::AccessSpecifier,
clang::Parser::DeclSpecContext, clang::Parser::LateParsedAttrList*) + 3285
26 clang           0x0000000000958250
clang::Parser::ParseDeclOrFunctionDefInternal(clang::Parser::ParsedAttributesWithRange&,
clang::ParsingDeclSpec&, clang::AccessSpecifier) + 96
27 clang           0x00000000009585d2
clang::Parser::ParseDeclarationOrFunctionDefinition(clang::Parser::ParsedAttributesWithRange&,
clang::ParsingDeclSpec*, clang::AccessSpecifier) + 114
28 clang           0x000000000095a8db
clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&,
clang::ParsingDeclSpec*) + 107
29 clang           0x000000000095af33
clang::Parser::ParseTopLevelDecl(clang::OpaquePtr<clang::DeclGroupRef>&) + 195
30 clang           0x00000000009564f5 clang::ParseAST(clang::Sema&, bool, bool)
+ 389
31 clang           0x0000000000653909 clang::FrontendAction::Execute() + 265
32 clang           0x0000000000633d05
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 341
33 clang           0x000000000061b012
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1794
34 clang           0x00000000006129d8 cc1_main(char const**, char const**, char
const*, void*) + 888
35 clang           0x000000000061a290 main + 4992
36 libc.so.6       0x0000003eafa21a05 __libc_start_main + 245
37 clang           0x0000000000611999
Stack dump:
0.    Program arguments: /home/dimhen/build/csa/Release+Asserts/bin/clang -cc1
-triple x86_64-unknown-linux-gnu -fsyntax-only -disable-free -main-file-name
x.ii -mrelocation-model static -mdisable-fp-elim -fmath-errno -masm-verbose
-mconstructor-aliases -munwind-tables -fuse-init-array -target-cpu x86-64
-target-linker-version 2.23.51.0.1 -resource-dir
/home/dimhen/build/csa/Release+Asserts/bin/../lib/clang/3.3 -fdeprecated-macro
-fdebug-compilation-dir /home/dimhen/errs/clang -ferror-limit 19
-fmessage-length 90 -mstackrealign -fobjc-runtime=gcc
-fobjc-default-synthesize-properties -fcxx-exceptions -fexceptions
-fdiagnostics-show-option -fcolor-diagnostics -backend-option -vectorize-loops
-x c++-cpp-output x.ii 
1.    <eof> parser at end of file
2.    x.ii:1:15: parsing struct/union/class body
clang: error: unable to execute command: Aborted (core dumped)
clang: error: clang frontend command failed due to signal (use -v to see
invocation)
clang version 3.3 (trunk 179458)
Target: x86_64-unknown-linux-gnu
Thread model: posix
clang: note: diagnostic msg: PLEASE submit a bug report to
http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and
associated run script.
clang: note: diagnostic msg: Error generating preprocessed source(s) - no
preprocessable inputs.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130413/a2b60b5c/attachment.html>

From bugzilla-daemon at llvm.org  Sat Apr 13 06:43:43 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 13 Apr 2013 13:43:43 +0000
Subject: [LLVMbugs] [Bug 15714] clang hangs at -O3 on expression
In-Reply-To: <bug-15714-206@http.llvm.org/bugs/>
References: <bug-15714-206@http.llvm.org/bugs/>
Message-ID: <bug-15714-206-GcjPqWoSjj@http.llvm.org/bugs/>

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

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

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

--- Comment #3 from Benjamin Kramer <benny.kra at gmail.com> ---
Fixed in r179458.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130413/13d977bf/attachment.html>

From bugzilla-daemon at llvm.org  Sat Apr 13 07:32:21 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 13 Apr 2013 14:32:21 +0000
Subject: [LLVMbugs] [Bug 15742] New: ICE in createTemporaryRegionIfNeeded()
Message-ID: <bug-15742-206@http.llvm.org/bugs/>

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

            Bug ID: 15742
           Summary: ICE in createTemporaryRegionIfNeeded()
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Static Analyzer
          Assignee: kremenek at apple.com
          Reporter: dimhen at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

$ cat x.ii
template < class _T1, class _T2 > struct A
{
    A (const _T1 &, const _T2 &);
};
extern "C" typedef enum
{ }
NPVariant;
typedef void *NPIdentifier;
template < class T > class B
{
protected:
    typedef A < NPIdentifier, bool (T::*) (const NPVariant *, unsigned,
                                           NPVariant *)
    >MethodMapMember;
};

class C:B < C >
{
    bool Find (const NPVariant *, unsigned, NPVariant *);
    void InitStaticData ();
};
void
C::InitStaticData ()
{
    MethodMapMember (0, &C::Find);
}


$ /home/dimhen/build/csa/Release+Asserts/bin/clang++ -cc1 -triple
x86_64-unknown-linux-gnu -analyze -disable-free -main-file-name x.ii
-analyzer-store=region -analyzer-opt-analyze-nested-blocks
-analyzer-eagerly-assume -analyzer-checker=core -analyzer-checker=cplusplus
-fcxx-exceptions -x c++ x.ii
clang++:
/home/dimhen/src/llvm/tools/clang/lib/StaticAnalyzer/Core/ExprEngine.cpp:184:
clang::ento::ProgramStateRef
clang::ento::ExprEngine::createTemporaryRegionIfNeeded(clang::ento::ProgramStateRef,
const clang::LocationContext*, const clang::Expr*, const clang::Expr*):
Assertion `!V.getAs<Loc>() || Loc::isLocType(Result->getType())' failed.
0  clang++         0x0000000001dba142 llvm::sys::PrintStackTrace(_IO_FILE*) +
34
1  clang++         0x0000000001db9d99
2  libpthread.so.0 0x0000003eb020f000
3  libc.so.6       0x0000003eafa35ba5 gsignal + 53
4  libc.so.6       0x0000003eafa37358 abort + 328
5  libc.so.6       0x0000003eafa2e972
6  libc.so.6       0x0000003eafa2ea22
7  clang++         0x0000000000e98b61
clang::ento::ExprEngine::createTemporaryRegionIfNeeded(llvm::IntrusiveRefCntPtr<clang::ento::ProgramState
const>, clang::LocationContext const*, clang::Expr const*, clang::Expr const*)
+ 961
8  clang++         0x0000000000eb07c5
clang::ento::ExprEngine::CreateCXXTemporaryObject(clang::MaterializeTemporaryExpr
const*, clang::ento::ExplodedNode*, clang::ento::ExplodedNodeSet&) + 805
9  clang++         0x0000000000e9c9f4
clang::ento::ExprEngine::Visit(clang::Stmt const*, clang::ento::ExplodedNode*,
clang::ento::ExplodedNodeSet&) + 3604
10 clang++         0x0000000000e9db78
clang::ento::ExprEngine::ProcessStmt(clang::CFGStmt,
clang::ento::ExplodedNode*) + 712
11 clang++         0x0000000000e9de53
clang::ento::ExprEngine::processCFGElement(clang::CFGElement,
clang::ento::ExplodedNode*, unsigned int, clang::ento::NodeBuilderContext*) +
227
12 clang++         0x0000000000e84b90
clang::ento::CoreEngine::HandlePostStmt(clang::CFGBlock const*, unsigned int,
clang::ento::ExplodedNode*) + 128
13 clang++         0x0000000000e85a5c
clang::ento::CoreEngine::dispatchWorkItem(clang::ento::ExplodedNode*,
clang::ProgramPoint, clang::ento::WorkListUnit const&) + 92
14 clang++         0x0000000000e85e1d
clang::ento::CoreEngine::ExecuteWorkList(clang::LocationContext const*,
unsigned int, llvm::IntrusiveRefCntPtr<clang::ento::ProgramState const>) + 253
15 clang++         0x0000000000d0ec70
16 clang++         0x0000000000d0f76f
17 clang++         0x0000000000d1a0c0
18 clang++         0x000000000095658a clang::ParseAST(clang::Sema&, bool, bool)
+ 538
19 clang++         0x0000000000653909 clang::FrontendAction::Execute() + 265
20 clang++         0x0000000000633d05
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 341
21 clang++         0x000000000061b012
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1794
22 clang++         0x00000000006129d8 cc1_main(char const**, char const**, char
const*, void*) + 888
23 clang++         0x000000000061a290 main + 4992
24 libc.so.6       0x0000003eafa21a05 __libc_start_main + 245
25 clang++         0x0000000000611999
Stack dump:
0.    Program arguments: /home/dimhen/build/csa/Release+Asserts/bin/clang++
-cc1 -triple x86_64-unknown-linux-gnu -analyze -disable-free -main-file-name
x.ii -analyzer-store=region -analyzer-opt-analyze-nested-blocks
-analyzer-eagerly-assume -analyzer-checker=core -analyzer-checker=cplusplus
-fcxx-exceptions -x c++ x.ii 
1.    <eof> parser at end of file
2.    x.ii:25:25: Error evaluating statement
3.    x.ii:25:25: Error evaluating statement
Aborted (core dumped)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130413/3e5d08ff/attachment.html>

From bugzilla-daemon at llvm.org  Sat Apr 13 10:09:10 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 13 Apr 2013 17:09:10 +0000
Subject: [LLVMbugs] [Bug 15723] Incorrect handling of out of bounds and
 strings starting from 0x
In-Reply-To: <bug-15723-206@http.llvm.org/bugs/>
References: <bug-15723-206@http.llvm.org/bugs/>
Message-ID: <bug-15723-206-amN5rYUGrq@http.llvm.org/bugs/>

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

Antony Polukhin <antoshkka at gmail.com> changed:

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

--- Comment #6 from Antony Polukhin <antoshkka at gmail.com> ---
(In reply to comment #5)
> Yes, tests 4-7 fail.  In each case a value of inf is successfully read into
> ld.

Other STL implementations in that case report failure via returning true in
ss.fail().

And it is required by C++11 (22.4.2.1.2, step 3):
The numeric value to be stored can be one of:
...
— the most positive representable value, if the field represents a value too
large positive to be
represented in val. ios_base::failbit is assigned to err.
...

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130413/f72b5913/attachment.html>

From bugzilla-daemon at llvm.org  Sat Apr 13 11:20:14 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 13 Apr 2013 18:20:14 +0000
Subject: [LLVMbugs] [Bug 15723] Incorrect handling of out of bounds and
 strings starting from 0x
In-Reply-To: <bug-15723-206@http.llvm.org/bugs/>
References: <bug-15723-206@http.llvm.org/bugs/>
Message-ID: <bug-15723-206-OaPRGiN52S@http.llvm.org/bugs/>

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

Howard Hinnant <hhinnant at apple.com> changed:

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

--- Comment #7 from Howard Hinnant <hhinnant at apple.com> ---
Good point, agreed.

Fix committed revision 179461.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130413/ee81aa80/attachment.html>

From bugzilla-daemon at llvm.org  Sat Apr 13 14:52:01 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 13 Apr 2013 21:52:01 +0000
Subject: [LLVMbugs] [Bug 15743] New: gep problem when optimizer changes
	struct padding
Message-ID: <bug-15743-206@http.llvm.org/bugs/>

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

            Bug ID: 15743
           Summary: gep problem when optimizer changes struct padding
           Product: libraries
           Version: 3.2
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Common Code Generator Code
          Assignee: unassignedbugs at nondot.org
          Reporter: robin at icir.org
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

I'm seeing a problem with the optimizer changing padding inside a
struct, but seemingly not propagating that change to a gep inside an
array.

Here's code to reproduce it. I'm using LLVM/clang 3.2.

----- r.ll

target triple = "x86_64-unknown-linux-gnu"

%A = type { i64, i32, i64 }

@B = constant i16 ptrtoint (i64* getelementptr (%A* null, i32 0, i32 2) to i16)
@C = constant [1 x { i16 }] [{ i16 } { i16 ptrtoint (i64* getelementptr (%A*
null, i32 0, i32 2) to i16) }]

----- r.c

#include <stdint.h>
#include <stdio.h>

extern const int16_t B;
extern const int16_t C[];

int main()
{
    printf("%d\n", B);
    printf("%d\n", C[0]);
}

-----

Without optimization, the offset of %A's 3rd element is 16:

# clang r.ll r.c -o a.out && ./a.out
16
16

With optimization enabled the offset changes to 12, however only B reflects
that:

# clang r.ll r.c -o a.out -O && ./a.out
12
16

Am I missing something, or is this bug?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130413/67bd927c/attachment.html>

From bugzilla-daemon at llvm.org  Sat Apr 13 18:47:51 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 14 Apr 2013 01:47:51 +0000
Subject: [LLVMbugs] [Bug 15744] New: extern "C" linkage ignored for a static
	function
Message-ID: <bug-15744-206@http.llvm.org/bugs/>

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

            Bug ID: 15744
           Summary: extern "C" linkage ignored for a static function
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
          Assignee: unassignedclangbugs at nondot.org
          Reporter: jbeich at tormail.org
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified

A static function may be called unmangled by asm() within another function
or from a function defined entirely within asm(). The latter is what
firefox does on i386 linux and bsd e.g.,
https://mxr.mozilla.org/mozilla-central/source/xpcom/reflect/xptcall/src/md/unix/xptcinvoke_gcc_x86_unix.cpp#85
https://mxr.mozilla.org/mozilla-central/source/xpcom/reflect/xptcall/src/md/unix/xptcstubs_gcc_x86_unix.cpp#121

  // a simple testcase
  extern "C"
  {
    __attribute__((__used__))
    static void
    foo(void)
    {
    }
  }

  asm("call foo");

$ clang++33 -c test.cc
$ objdump -t test.o | fgrep foo
0000000000000010 l     F .text  0000000000000006 _Z3foov
0000000000000000         *UND*  0000000000000000 foo

$ clang++32 -c test.cc
$ objdump -t test.o | fgrep foo
0000000000000010 l     F .text  0000000000000001 foo

$ g++48 -c test.cc
$ objdump -t test.o | fgrep foo
0000000000000000 l     F .text  0000000000000006 foo

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130414/0bf36813/attachment.html>

From bugzilla-daemon at llvm.org  Sat Apr 13 20:40:18 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 14 Apr 2013 03:40:18 +0000
Subject: [LLVMbugs] [Bug 15744] extern "C" linkage ignored for a static
	function
In-Reply-To: <bug-15744-206@http.llvm.org/bugs/>
References: <bug-15744-206@http.llvm.org/bugs/>
Message-ID: <bug-15744-206-59fjrTpz8w@http.llvm.org/bugs/>

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

Meador Inge <meadori at codesourcery.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |meadori at codesourcery.com
         Resolution|---                         |FIXED

--- Comment #1 from Meador Inge <meadori at codesourcery.com> ---
This bug was fixed here:
http://llvm.org/viewvc/llvm-project?view=revision&revision=178950.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130414/10020342/attachment.html>

From bugzilla-daemon at llvm.org  Sun Apr 14 01:53:11 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 14 Apr 2013 08:53:11 +0000
Subject: [LLVMbugs] [Bug 15746] New: R600: Build failure on openSUSE
Message-ID: <bug-15746-206@http.llvm.org/bugs/>

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

            Bug ID: 15746
           Summary: R600: Build failure on openSUSE
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: release blocker
          Priority: P
         Component: Target Description Classes
          Assignee: unassignedbugs at nondot.org
          Reporter: johannesobermayr at gmx.de
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

/home/abuild/rpmbuild/BUILD/llvm/lib/Target/R600/R600ControlFlowFinalizer.cpp:
In member function 'const llvm::MCInstrDesc&
llvm::R600ControlFlowFinalizer::getHWInstrDesc(llvm::R600ControlFlowFinalizer::ControlFlowInstruction)
const':
/home/abuild/rpmbuild/BUILD/llvm/lib/Target/R600/R600ControlFlowFinalizer.cpp:137:3:
warning: control reaches end of non-void function [-Wreturn-type]


Becomes a build failure on openSUSE post-build-checks:

... running 02-check-gcc-output
... testing for serious compiler warnings
    (using /usr/lib/build/checks-data/check_gcc_output)
    (using /var/cache/obs/worker/root_1/.build.log)

I: Program returns random data in a function
E: llvm no-return-in-nonvoid-function
/home/abuild/rpmbuild/BUILD/llvm/lib/Target/R600/R600ControlFlowFinalizer.cpp:137

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130414/f8b43f11/attachment.html>

From bugzilla-daemon at llvm.org  Sun Apr 14 04:50:01 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 14 Apr 2013 11:50:01 +0000
Subject: [LLVMbugs] [Bug 15747] New: clang trunk r179460 crashes running
 scan-build on llvm/clang
Message-ID: <bug-15747-206@http.llvm.org/bugs/>

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

            Bug ID: 15747
           Summary: clang trunk r179460 crashes running scan-build on
                    llvm/clang
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Static Analyzer
          Assignee: kremenek at apple.com
          Reporter: lbalbalba at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 10348
  --> http://llvm.org/bugs/attachment.cgi?id=10348&action=edit
preprocessed file causing a crash

Running clang version 3.3 (trunk 179460) scan-build on llvm/clang generates a
few crashes. You can reproduce by running 'clang --analyze ./foo.ii' on the
preprocessed files in the attachments.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130414/c9c3e76b/attachment.html>

From bugzilla-daemon at llvm.org  Sun Apr 14 17:38:47 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 15 Apr 2013 00:38:47 +0000
Subject: [LLVMbugs] [Bug 15748] New: clang hangs at -O3 on loop
Message-ID: <bug-15748-206@http.llvm.org/bugs/>

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

            Bug ID: 15748
           Summary: clang hangs at -O3 on loop
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: LLVM Codegen
          Assignee: unassignedclangbugs at nondot.org
          Reporter: dhazeghi at yahoo.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

The following testcase (generated by csmith) causes current clang trunk to hang
when compiling at -O3.

This does not appear to be the same as 15714, which was recently fixed.

$ clang -v
clang version 3.3 (trunk 179483)
Target: x86_64-pc-linux-gnu
Thread model: posix
$ clang -O2 -c try.c
$ clang -O3 -c try.c
^C

--------------

int a, b, c, d;
void fn1 ()
{
    int e = 0;
    for (; a; a++)
    {
        int *f = &c;
        d || (e |= *f);
        b ^= *f = 1;
    }
}

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130415/490faa2a/attachment.html>

From bugzilla-daemon at llvm.org  Mon Apr 15 08:49:36 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 15 Apr 2013 15:49:36 +0000
Subject: [LLVMbugs] [Bug 15749] New: llvm::sys::Memory not thread-safe
Message-ID: <bug-15749-206@http.llvm.org/bugs/>

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

            Bug ID: 15749
           Summary: llvm::sys::Memory not thread-safe
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Support Libraries
          Assignee: unassignedbugs at nondot.org
          Reporter: jim.kearney at oracle.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Memory::allocateMappedMemory() has a block-scope static that caches the size of
a page (in both Posix and Windows versions).  When LLVM is built by a pre-C++11
compiler (note 1), multiple threads may race on examining and setting the
hidden boolean.  In the case of MS Visual Studio this is disastrous because it
sets the flag before setting the value, which results in other threads using
the not-yet-set value.

  static const size_t PageSize = Process::GetPageSize();
  const size_t NumPages = (NumBytes+PageSize-1)/PageSize;

(1) C++11 says concurrent access must be serialized, previous Standards did
not.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130415/a2e554c0/attachment.html>

From bugzilla-daemon at llvm.org  Mon Apr 15 09:13:44 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 15 Apr 2013 16:13:44 +0000
Subject: [LLVMbugs] [Bug 15750] New: GDBJITRegistrar not thread-safe (makes
 MCJIT not thread-safe)
Message-ID: <bug-15750-206@http.llvm.org/bugs/>

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

            Bug ID: 15750
           Summary: GDBJITRegistrar not thread-safe (makes MCJIT not
                    thread-safe)
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Generic Execution Engine Support
          Assignee: unassignedbugs at nondot.org
          Reporter: jim.kearney at oracle.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

GDBJITRegistrar::(de)registerObject() accesses a member variable
ObjectBufferMap without any synchronization.  The class is used as a singleton
and so multiple instances of MCJIT try to modify that map simultaneously.

The code is written to be thread-safe with its access to gdb variables but not
with its own state, which is strange given its singleton nature.

Also, JITRegistrar::getGDBRegistrar should use ManagedStatic.  The
initialization pattern it uses is not guaranteed thread-safe.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130415/0d1d8759/attachment.html>

From bugzilla-daemon at llvm.org  Mon Apr 15 09:39:02 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 15 Apr 2013 16:39:02 +0000
Subject: [LLVMbugs] [Bug 15751] New: reading a long double from a stream is
 out by a factor of 10
Message-ID: <bug-15751-206@http.llvm.org/bugs/>

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

            Bug ID: 15751
           Summary: reading a long double from a stream is out by a factor
                    of 10
           Product: libc++
           Version: unspecified
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: All Bugs
          Assignee: hhinnant at apple.com
          Reporter: john at johnmaddock.co.uk
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

This issue is causing most of the Boost.Math lib tests to fail, sample code is:

int main(int argc, char** argv)
{
   std::stringstream ss;
   long double r3;
   ss << "304888344611713860501504000000";
   ss >> r3;

   std::cout << std::setprecision(std::numeric_limits<long
double>::max_digits10) << r3 << std::endl;

   r3 = 304888344611713860501504000000.0L;
   std::cout << std::setprecision(std::numeric_limits<long
double>::max_digits10) << r3 << std::endl;

   return 0;
}

Which outputs:

3.04888344611713860494e+28
3.04888344611713860494e+29

Note how the value read from the stream is 10 times too small :-(

The issue still occurs if I append a ".0" to the input string.

Platform is Ubuntu Linux, latest clang and libc++ SVN Trunk.  Same issue with
last release as well.   GCC/libstdc++ and MSVC both handle this fine.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130415/0a57eb9e/attachment.html>

From bugzilla-daemon at llvm.org  Mon Apr 15 09:45:06 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 15 Apr 2013 16:45:06 +0000
Subject: [LLVMbugs] [Bug 15752] New: Current trunk miscompiles Firefox
Message-ID: <bug-15752-206@http.llvm.org/bugs/>

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

            Bug ID: 15752
           Summary: Current trunk miscompiles Firefox
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: markus at trippelsdorf.de
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Firefox (trunk) build with clang trunk crashes during startup.
clang-3.2 and gcc are fine.
(Linux x86-64)

A Firefox debug build doesn't crash during startup, but soon afterwards:

Program received signal SIGSEGV, Segmentation fault.
mozalloc_abort (msg=<optimized out>) at
/home/markus/mozilla-central/memory/mozalloc/mozalloc_abort.cpp:30
30          MOZ_CRASH();
(gdb) bt
#0  mozalloc_abort (msg=<optimized out>) at
/home/markus/mozilla-central/memory/mozalloc/mozalloc_abort.cpp:30
#1  0x00007ffff5463004 in Abort (aMsg=0x0) at
/home/markus/mozilla-central/xpcom/base/nsDebugImpl.cpp:430
#2  0x00007ffff5462ee1 in NS_DebugBreak (aSeverity=<error reading variable:
Cannot access memory at address 0x0>, aStr=<optimized out>, aExpr=<optimized
out>, 
    aFile=<optimized out>, aLine=<optimized out>) at
/home/markus/mozilla-central/xpcom/base/nsDebugImpl.cpp:417
#3  0x00007ffff4146a21 in mozilla::image::Decoder::PostDecodeDone
(this=0x7fffcca04540, aLoopCount=0) at
/home/markus/mozilla-central/image/src/Decoder.cpp:365
#4  0x00007ffff414681c in mozilla::image::Decoder::Finish (this=0x7fffcca04540,
aShutdownIntent=mozilla::image::RasterImage::eShutdownIntent_Done)
    at /home/markus/mozilla-central/image/src/Decoder.cpp:166
#5  0x00007ffff414dd88 in mozilla::image::RasterImage::ShutdownDecoder
(this=0x7fffcaa7b7d0,
aIntent=mozilla::image::RasterImage::eShutdownIntent_Done)
    at /home/markus/mozilla-central/image/src/RasterImage.cpp:2625
#6  0x00007ffff414c1cb in mozilla::image::RasterImage::FinishedSomeDecoding
(this=0x7fffcaa7b7d0,
aIntent=mozilla::image::RasterImage::eShutdownIntent_Done, 
    aRequest=<optimized out>) at
/home/markus/mozilla-central/image/src/RasterImage.cpp:3436
#7  0x00007ffff414a1ce in mozilla::image::RasterImage::SyncDecode
(this=0x7fffcaa7b7d0) at
/home/markus/mozilla-central/image/src/RasterImage.cpp:2913
#8  0x00007ffff414c4dc in mozilla::image::RasterImage::FinishedSomeDecoding
(this=0x7fffcaa7b7d0,
aIntent=mozilla::image::RasterImage::eShutdownIntent_Done, 
    aRequest=<optimized out>) at
/home/markus/mozilla-central/image/src/RasterImage.cpp:3485
#9  0x00007ffff414cabb in
mozilla::image::RasterImage::DecodePool::DecodeUntilSizeAvailable
(this=<optimized out>, aImg=0x7fffcaa7b7d0)
    at /home/markus/mozilla-central/image/src/RasterImage.cpp:3711
#10 0x00007ffff414c80f in mozilla::image::RasterImage::DoImageDataComplete
(this=0x7fffcaa7b7d0) at
/home/markus/mozilla-central/image/src/RasterImage.cpp:1755
#11 0x00007ffff414cb9e in mozilla::image::RasterImage::OnImageDataComplete
(this=0x7fffcaa7b7d0, aStatus=NS_OK, aLastPart=true)
    at /home/markus/mozilla-central/image/src/RasterImage.cpp:1797
#12 0x00007ffff4165e15 in imgRequest::OnStopRequest (this=0x7fffc98a97c0,
aRequest=0x7fffcaa7b6d0, ctxt=0x0, status=NS_OK)
    at /home/markus/mozilla-central/image/src/imgRequest.cpp:616
#13 0x00007ffff3faaced in nsBaseChannel::OnStopRequest (this=0x7fffcaa7b680,
request=<optimized out>, ctxt=<optimized out>, status=<optimized out>)
    at /home/markus/mozilla-central/netwerk/base/src/nsBaseChannel.cpp:737
...

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130415/7cbf5c17/attachment.html>

From bugzilla-daemon at llvm.org  Mon Apr 15 13:17:53 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 15 Apr 2013 20:17:53 +0000
Subject: [LLVMbugs] [Bug 15753] New: wrong handling of linkage for explicit
 specializations of static function templates
Message-ID: <bug-15753-206@http.llvm.org/bugs/>

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

            Bug ID: 15753
           Summary: wrong handling of linkage for explicit specializations
                    of static function templates
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: matthewbg at google.com
                CC: llvmbugs at cs.uiuc.edu, rafael.espindola at gmail.com
    Classification: Unclassified

$ cat ~/test.cc
template <typename T> static int Foo(T t);
template <typename T> int Foo(T t) {
  return t;
}
template<> int Foo<int>(int i) {
  return i;
}
$ clang -o /tmp/test.o -c ~/test.cc && nm /tmp/test.o
0000000000000000 T _ZL3FooIiEiT_

At r178511, we didn't emit anything for that input; at r179138, we produce the
above output.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130415/47e23446/attachment.html>

From bugzilla-daemon at llvm.org  Mon Apr 15 13:55:55 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 15 Apr 2013 20:55:55 +0000
Subject: [LLVMbugs] [Bug 15740] Long octals from strings using stringstreams
In-Reply-To: <bug-15740-206@http.llvm.org/bugs/>
References: <bug-15740-206@http.llvm.org/bugs/>
Message-ID: <bug-15740-206-HrT6tqUvjP@http.llvm.org/bugs/>

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

Howard Hinnant <hhinnant at apple.com> changed:

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

--- Comment #1 from Howard Hinnant <hhinnant at apple.com> ---
Fix Committed revision 179556.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130415/59cd1e23/attachment.html>

From bugzilla-daemon at llvm.org  Mon Apr 15 13:56:26 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 15 Apr 2013 20:56:26 +0000
Subject: [LLVMbugs] [Bug 15751] reading a long double from a stream is out
 by a factor of 10
In-Reply-To: <bug-15751-206@http.llvm.org/bugs/>
References: <bug-15751-206@http.llvm.org/bugs/>
Message-ID: <bug-15751-206-OINDRi4Suu@http.llvm.org/bugs/>

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

Howard Hinnant <hhinnant at apple.com> changed:

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

--- Comment #1 from Howard Hinnant <hhinnant at apple.com> ---
Fix Committed revision 179556.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130415/051c89b3/attachment.html>

From bugzilla-daemon at llvm.org  Mon Apr 15 15:04:23 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 15 Apr 2013 22:04:23 +0000
Subject: [LLVMbugs] [Bug 15742] ICE in createTemporaryRegionIfNeeded()
In-Reply-To: <bug-15742-206@http.llvm.org/bugs/>
References: <bug-15742-206@http.llvm.org/bugs/>
Message-ID: <bug-15742-206-6a2sASQcl1@http.llvm.org/bugs/>

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

Jordan Rose <jordan_rose at apple.com> changed:

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

--- Comment #4 from Jordan Rose <jordan_rose at apple.com> ---
Looks like this was the same as bug 15747. Thanks for the reduced test case; it
made things a lot easier!

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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130415/089ab049/attachment.html>

From bugzilla-daemon at llvm.org  Mon Apr 15 15:04:36 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 15 Apr 2013 22:04:36 +0000
Subject: [LLVMbugs] [Bug 15747] clang trunk r179460 crashes running
 scan-build on llvm/clang
In-Reply-To: <bug-15747-206@http.llvm.org/bugs/>
References: <bug-15747-206@http.llvm.org/bugs/>
Message-ID: <bug-15747-206-kCuUuSZJWN@http.llvm.org/bugs/>

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

Jordan Rose <jordan_rose at apple.com> changed:

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

--- Comment #8 from Jordan Rose <jordan_rose at apple.com> ---
Should be fixed in r179563.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130415/c208bd1b/attachment.html>

From bugzilla-daemon at llvm.org  Mon Apr 15 15:34:07 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 15 Apr 2013 22:34:07 +0000
Subject: [LLVMbugs] [Bug 15185] opt -mergefunc trips assertion error
In-Reply-To: <bug-15185-206@http.llvm.org/bugs/>
References: <bug-15185-206@http.llvm.org/bugs/>
Message-ID: <bug-15185-206-2VEWo1Dd7U@http.llvm.org/bugs/>

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

Bill Wendling <wendling at apple.com> changed:

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

--- Comment #19 from Bill Wendling <wendling at apple.com> ---
Hoping that this is the correct fix:

Sending        lib/Transforms/IPO/MergeFunctions.cpp
Adding         test/Transforms/MergeFunc/crash.ll
Transmitting file data ..
Committed revision 179569.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130415/078f185b/attachment.html>

From bugzilla-daemon at llvm.org  Mon Apr 15 15:34:09 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 15 Apr 2013 22:34:09 +0000
Subject: [LLVMbugs] [Bug 15465] Emscripten tracking bug
In-Reply-To: <bug-15465-206@http.llvm.org/bugs/>
References: <bug-15465-206@http.llvm.org/bugs/>
Message-ID: <bug-15465-206-8dV83VVMcK@http.llvm.org/bugs/>

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

Bug 15465 depends on bug 15185, which changed state.

Bug 15185 Summary: opt -mergefunc trips assertion error
http://llvm.org/bugs/show_bug.cgi?id=15185

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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130415/a15faa1b/attachment.html>

From bugzilla-daemon at llvm.org  Mon Apr 15 17:14:48 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 16 Apr 2013 00:14:48 +0000
Subject: [LLVMbugs] [Bug 15735] list-initialization of array new-expression
 requires declared default constructor
In-Reply-To: <bug-15735-206@http.llvm.org/bugs/>
References: <bug-15735-206@http.llvm.org/bugs/>
Message-ID: <bug-15735-206-ByLt0lb3oh@http.llvm.org/bugs/>

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

David Blaikie <dblaikie at gmail.com> changed:

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

--- Comment #1 from David Blaikie <dblaikie at gmail.com> ---
I believe this is well defined/required. If during construction of any of those
array elements, an exception is thrown (the fact that the body of the ctor is
visible & not throwing isn't considered) then the previous fully constructed
elements need to be destroyed. So the destructor must be available for any such
expression.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130416/69f1fc33/attachment.html>

From bugzilla-daemon at llvm.org  Mon Apr 15 17:45:27 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 16 Apr 2013 00:45:27 +0000
Subject: [LLVMbugs] [Bug 15731] Bugzilla: Please update the category
	description
In-Reply-To: <bug-15731-206@http.llvm.org/bugs/>
References: <bug-15731-206@http.llvm.org/bugs/>
Message-ID: <bug-15731-206-SzA9e50QV5@http.llvm.org/bugs/>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #1 from Chris Lattner <clattner at apple.com> ---
Ok, done.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130416/515d542d/attachment.html>

From bugzilla-daemon at llvm.org  Mon Apr 15 17:52:14 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 16 Apr 2013 00:52:14 +0000
Subject: [LLVMbugs] [Bug 15754] New: addressof returns wrong address when
 there is user provided conversion operator to char&
Message-ID: <bug-15754-206@http.llvm.org/bugs/>

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

            Bug ID: 15754
           Summary: addressof returns wrong address when there is user
                    provided conversion operator to char&
           Product: libc++
           Version: unspecified
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: All Bugs
          Assignee: hhinnant at apple.com
          Reporter: tuhertz at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

addressof uses plain c style cast, so type conversion operator is invoked when
argument type T has user-defined conversion operator to char& like this:

struct nothing {
    operator char&()
    {
        static char c;
        return c;
    }
};

one way to fix this is using reinterpret_cast:
http://www.boost.org/doc/libs/release/boost/utility/addressof.hpp

template <class _Tp>
inline _LIBCPP_INLINE_VISIBILITY
_Tp*
addressof(_Tp& __x) _NOEXCEPT
{
    return reinterpret_cast<_Tp*>(&const_cast<char&>(reinterpret_cast<const
volatile char&>(__x)));
}

this code adding const volatile to char& and remove it for allowing addressof
to be called with const or volatile type _Tp.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130416/6a636e54/attachment.html>

From bugzilla-daemon at llvm.org  Mon Apr 15 19:26:24 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 16 Apr 2013 02:26:24 +0000
Subject: [LLVMbugs] [Bug 15755] New: Failed to inherit variadic template
 constructor from base's base.
Message-ID: <bug-15755-206@http.llvm.org/bugs/>

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

            Bug ID: 15755
           Summary: Failed to inherit variadic template constructor from
                    base's base.
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++11
          Assignee: unassignedclangbugs at nondot.org
          Reporter: eric at boostpro.com
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified

The following code fails to compile:

{{{
    struct S
    {
        template<class A, class...B>
        S(A, B...) {}
    };

    struct T : S
    {
        using S::S;
    };

    struct U : T
    {
        using T::T;
    };

    int main()
    {
        U u{"hello"};
    }
}}}

Clang trunk gives:

1>  "C:/cygwin/usr/local/bin/clang++.exe" -c -O0 -std=gnu++11 -I../../../..
-I/home/Eric/boost/org/trunk main.cpp -o main.o
1>  main.cpp:19:7: error: call to deleted constructor of 'U'
1>      U u{"hello"};
1>        ^~~~~~~~~~
1>  main.cpp:14:14: note: function has been explicitly marked deleted here
1>      using T::T;
1>               ^
1>  1 error generated.
1>  make: *** [main.o] Error 1

The code should compile.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130416/27b247cb/attachment.html>

From bugzilla-daemon at llvm.org  Mon Apr 15 19:30:34 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 16 Apr 2013 02:30:34 +0000
Subject: [LLVMbugs] [Bug 15753] wrong handling of linkage for explicit
 specializations of static function templates
In-Reply-To: <bug-15753-206@http.llvm.org/bugs/>
References: <bug-15753-206@http.llvm.org/bugs/>
Message-ID: <bug-15753-206-vTGiarPM00@http.llvm.org/bugs/>

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

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

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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130416/68773e6e/attachment.html>

From bugzilla-daemon at llvm.org  Mon Apr 15 21:28:52 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 16 Apr 2013 04:28:52 +0000
Subject: [LLVMbugs] [Bug 15756] New: scan-build confused by pointer
 arithmetic on 2nd argument to read
Message-ID: <bug-15756-206@http.llvm.org/bugs/>

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

            Bug ID: 15756
           Summary: scan-build confused by pointer arithmetic on 2nd
                    argument to read
           Product: clang
           Version: unspecified
          Hardware: Macintosh
                OS: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: Static Analyzer
          Assignee: kremenek at apple.com
          Reporter: rrh at newrelic.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130416/3daaa157/attachment.html>

From bugzilla-daemon at llvm.org  Mon Apr 15 22:29:42 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 16 Apr 2013 05:29:42 +0000
Subject: [LLVMbugs] [Bug 15756] scan-build confused by pointer arithmetic on
 2nd argument to read
In-Reply-To: <bug-15756-206@http.llvm.org/bugs/>
References: <bug-15756-206@http.llvm.org/bugs/>
Message-ID: <bug-15756-206-j9lw9UhEVY@http.llvm.org/bugs/>

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

Robert Henry <rrh at newrelic.com> changed:

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

--- Comment #3 from Robert Henry <rrh at newrelic.com> ---
My analysis of the code was wrong.  The loop body will never be entered if the
read returns -1.  Tools win!

Please disregard.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130416/688c7d81/attachment.html>

From bugzilla-daemon at llvm.org  Mon Apr 15 22:47:04 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 16 Apr 2013 05:47:04 +0000
Subject: [LLVMbugs] [Bug 15757] New: Mysterious error with inheriting
 constructor, delegating constructor, and noexcept specifier
Message-ID: <bug-15757-206@http.llvm.org/bugs/>

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

            Bug ID: 15757
           Summary: Mysterious error with inheriting constructor,
                    delegating constructor, and noexcept specifier
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++11
          Assignee: unassignedclangbugs at nondot.org
          Reporter: eric at boostpro.com
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified

This is as far as I've been able to narrow this problem down. It seems to be
some strange confluence of C++11 features that is causing the perfect storm:

{{{
    struct S
    {};

    template<typename X, typename Y>
    struct T
    {
        template<typename A>
        T(X x, A &&a)
        {}

        template<typename A>
        explicit T(A &&a)
            noexcept(noexcept(
                T(X(), static_cast<A &&>(a))
            ))
          : T(X(), static_cast<A &&>(a))
        {}
    };

    template<typename X, typename Y>
    struct U
      : T<X, Y>
    {
        using T<X, Y>::T;
    };

    // Comment this function out and everything works
    U<S, char> foo(char ch)
    {
        return U<S, char>(ch);
    }

    int main()
    {
        U<S, int>  a(42);   // This works
        U<S, char> b('4');  // This fails
    }
}}}

The error I'm getting is:

1>  "C:/cygwin/usr/local/bin/clang++.exe" -c -O0 -std=gnu++11 main.cpp -o
main.o
1>  main.cpp:14:20: error: cannot cast from lvalue of type 'char' to rvalue
reference type 'S &&'; types are not compatible
1>              T(X(), static_cast<A &&>(a))
1>                     ^~~~~~~~~~~~~~~~~~~~
1>  main.cpp:24:20: note: in instantiation of exception specification for
'T<char>' requested here
1>      using T<X, Y>::T;
1>                     ^
1>  main.cpp:36:16: note: inheriting constructor for 'U<S, char>' first
required here
1>      U<S, char> b('4');  // This fails
1>                 ^
1>  1 error generated.

I can't make any sense of the error message. Seemingly innocuous changes to the
code, like commenting out the foo function or the noexcept clause, make the
error go away.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130416/55513d92/attachment.html>

From bugzilla-daemon at llvm.org  Tue Apr 16 00:09:58 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 16 Apr 2013 07:09:58 +0000
Subject: [LLVMbugs] [Bug 15758] New: Incorrect vectorization of a long
 double array by packed vectors
Message-ID: <bug-15758-206@http.llvm.org/bugs/>

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

            Bug ID: 15758
           Summary: Incorrect vectorization of a long double array by
                    packed vectors
           Product: clang
           Version: 3.2
          Hardware: Macintosh
                OS: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: dtakahashi42 at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

With loop-vectorizer is enabled by -mllvm -vectorize-loops, clang automatically
vectorizes the assignment on a long-double array (16 bytes aligned) by
assignment on 16-bytes-aligned-x86_fp80-packed vectors. Because of the
alignment mismatch between array's elements and packed elements, subsequent
access on the array produces incorrect result.

Below is the test case.
int main (void) {
  long double x[1027];

  for (int i = 0; i < 1027; i++) {
    x[i] = (long double) i;
  }

  for (int i = 0; i < 1027; i++) {
    assert (x[i] == (long double) i);
  }

  return 0;
}

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130416/e21a1e82/attachment.html>

From bugzilla-daemon at llvm.org  Tue Apr 16 00:22:32 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 16 Apr 2013 07:22:32 +0000
Subject: [LLVMbugs] [Bug 15735] list-initialization of array new-expression
 requires declared default constructor
In-Reply-To: <bug-15735-206@http.llvm.org/bugs/>
References: <bug-15735-206@http.llvm.org/bugs/>
Message-ID: <bug-15735-206-ag60mx0yMP@http.llvm.org/bugs/>

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

Ed Catmur <ed at catmur.co.uk> changed:

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

--- Comment #2 from Ed Catmur <ed at catmur.co.uk> ---
I may be missing something, but this bug report is about the default
constructor, not the destructor.  If I delete the destructor the compilation
error is different.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130416/62ea7230/attachment.html>

From bugzilla-daemon at llvm.org  Tue Apr 16 01:10:49 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 16 Apr 2013 08:10:49 +0000
Subject: [LLVMbugs] [Bug 15759] New: Invalid constraint in asm crashes
Message-ID: <bug-15759-206@http.llvm.org/bugs/>

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

            Bug ID: 15759
           Summary: Invalid constraint in asm crashes
           Product: clang
           Version: 3.2
          Hardware: Macintosh
                OS: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: bruce.mitchener at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 10355
  --> http://llvm.org/bugs/attachment.cgi?id=10355&action=edit
Example C file for the bug

Attached sample causes compiler crash:

batavia:invalid_asm_constraint bruce$ /usr/local/bin/clang -o test.o -c test.c
Assertion failed: (Verify(getFunctionType(), constraints) && "Function type not
legal for constraints!"), function InlineAsm, file InlineAsm.cpp, line 47.
0  clang             0x000000010fc6b656 char const* std::__find<char const*,
char>(char const*, char const*, char const&, std::random_access_iterator_tag) +
3494
1  clang             0x000000010fc6b9e9 char const* std::__find<char const*,
char>(char const*, char const*, char const&, std::random_access_iterator_tag) +
4409
2  libsystem_c.dylib 0x00007fff95e088ea _sigtramp + 26
3  libsystem_c.dylib 000000000000000000 _sigtramp + 18446603338001643312
4  clang             0x000000010fc6b861 char const* std::__find<char const*,
char>(char const*, char const*, char const&, std::random_access_iterator_tag) +
4017
5  clang             0x000000010fc6b84b char const* std::__find<char const*,
char>(char const*, char const*, char const&, std::random_access_iterator_tag) +
3995
6  clang             0x000000010fbde5d0 void*
llvm::object_creator<llvm::sys::SmartRWMutex<true> >() + 6342
7  clang             0x000000010fbdff8f
std::_Rb_tree<std::pair<llvm::PointerType*, llvm::InlineAsmKeyType>,
std::pair<std::pair<llvm::PointerType*, llvm::InlineAsmKeyType> const,
llvm::InlineAsm*>, std::_Select1st<std::pair<std::pair<llvm::PointerType*,
llvm::InlineAsmKeyType> const, llvm::InlineAsm*> >,
std::less<std::pair<llvm::PointerType*, llvm::InlineAsmKeyType> >,
std::allocator<std::pair<std::pair<llvm::PointerType*, llvm::InlineAsmKeyType>
const, llvm::InlineAsm*> > >::find(std::pair<llvm::PointerType*,
llvm::InlineAsmKeyType> const&) + 1025
8  clang             0x000000010fbdfcef
std::_Rb_tree<std::pair<llvm::PointerType*, llvm::InlineAsmKeyType>,
std::pair<std::pair<llvm::PointerType*, llvm::InlineAsmKeyType> const,
llvm::InlineAsm*>, std::_Select1st<std::pair<std::pair<llvm::PointerType*,
llvm::InlineAsmKeyType> const, llvm::InlineAsm*> >,
std::less<std::pair<llvm::PointerType*, llvm::InlineAsmKeyType> >,
std::allocator<std::pair<std::pair<llvm::PointerType*, llvm::InlineAsmKeyType>
const, llvm::InlineAsm*> > >::find(std::pair<llvm::PointerType*,
llvm::InlineAsmKeyType> const&) + 353
9  clang             0x000000010fbdef8d void*
llvm::object_creator<llvm::sys::SmartRWMutex<true> >() + 8835
10 clang             0x000000010fbde4b9 void*
llvm::object_creator<llvm::sys::SmartRWMutex<true> >() + 6063
11 clang             0x000000010ef45151 std::vector<std::pair<unsigned int,
clang::CodeGen::CGBitFieldInfo const*>, std::allocator<std::pair<unsigned int,
clang::CodeGen::CGBitFieldInfo const*> >
>::_M_insert_aux(__gnu_cxx::__normal_iterator<std::pair<unsigned int,
clang::CodeGen::CGBitFieldInfo const*>*, std::vector<std::pair<unsigned int,
clang::CodeGen::CGBitFieldInfo const*>, std::allocator<std::pair<unsigned int,
clang::CodeGen::CGBitFieldInfo const*> > > >, std::pair<unsigned int,
clang::CodeGen::CGBitFieldInfo const*> const&) + 15719
12 clang             0x000000010ef424c7 std::vector<std::pair<unsigned int,
clang::CodeGen::CGBitFieldInfo const*>, std::allocator<std::pair<unsigned int,
clang::CodeGen::CGBitFieldInfo const*> >
>::_M_insert_aux(__gnu_cxx::__normal_iterator<std::pair<unsigned int,
clang::CodeGen::CGBitFieldInfo const*>*, std::vector<std::pair<unsigned int,
clang::CodeGen::CGBitFieldInfo const*>, std::allocator<std::pair<unsigned int,
clang::CodeGen::CGBitFieldInfo const*> > > >, std::pair<unsigned int,
clang::CodeGen::CGBitFieldInfo const*> const&) + 4317
13 clang             0x000000010ef45f73 std::vector<std::pair<unsigned int,
clang::CodeGen::CGBitFieldInfo const*>, std::allocator<std::pair<unsigned int,
clang::CodeGen::CGBitFieldInfo const*> >
>::_M_insert_aux(__gnu_cxx::__normal_iterator<std::pair<unsigned int,
clang::CodeGen::CGBitFieldInfo const*>*, std::vector<std::pair<unsigned int,
clang::CodeGen::CGBitFieldInfo const*>, std::allocator<std::pair<unsigned int,
clang::CodeGen::CGBitFieldInfo const*> > > >, std::pair<unsigned int,
clang::CodeGen::CGBitFieldInfo const*> const&) + 19337
14 clang             0x000000010ef42929 std::vector<std::pair<unsigned int,
clang::CodeGen::CGBitFieldInfo const*>, std::allocator<std::pair<unsigned int,
clang::CodeGen::CGBitFieldInfo const*> >
>::_M_insert_aux(__gnu_cxx::__normal_iterator<std::pair<unsigned int,
clang::CodeGen::CGBitFieldInfo const*>*, std::vector<std::pair<unsigned int,
clang::CodeGen::CGBitFieldInfo const*>, std::allocator<std::pair<unsigned int,
clang::CodeGen::CGBitFieldInfo const*> > > >, std::pair<unsigned int,
clang::CodeGen::CGBitFieldInfo const*> const&) + 5439
15 clang             0x000000010ef423c3 std::vector<std::pair<unsigned int,
clang::CodeGen::CGBitFieldInfo const*>, std::allocator<std::pair<unsigned int,
clang::CodeGen::CGBitFieldInfo const*> >
>::_M_insert_aux(__gnu_cxx::__normal_iterator<std::pair<unsigned int,
clang::CodeGen::CGBitFieldInfo const*>*, std::vector<std::pair<unsigned int,
clang::CodeGen::CGBitFieldInfo const*>, std::allocator<std::pair<unsigned int,
clang::CodeGen::CGBitFieldInfo const*> > > >, std::pair<unsigned int,
clang::CodeGen::CGBitFieldInfo const*> const&) + 4057
16 clang             0x000000010ef4ffb4 std::vector<std::pair<unsigned int,
unsigned int>, std::allocator<std::pair<unsigned int, unsigned int> >
>::operator=(std::vector<std::pair<unsigned int, unsigned int>,
std::allocator<std::pair<unsigned int, unsigned int> > > const&) + 8610
17 clang             0x000000010ef502c0 std::vector<std::pair<unsigned int,
unsigned int>, std::allocator<std::pair<unsigned int, unsigned int> >
>::operator=(std::vector<std::pair<unsigned int, unsigned int>,
std::allocator<std::pair<unsigned int, unsigned int> > > const&) + 9390
18 clang             0x000000010ef574d3 std::vector<std::pair<unsigned int,
unsigned int>, std::allocator<std::pair<unsigned int, unsigned int> >
>::operator=(std::vector<std::pair<unsigned int, unsigned int>,
std::allocator<std::pair<unsigned int, unsigned int> > > const&) + 38593
19 clang             0x000000010ef551e3 std::vector<std::pair<unsigned int,
unsigned int>, std::allocator<std::pair<unsigned int, unsigned int> >
>::operator=(std::vector<std::pair<unsigned int, unsigned int>,
std::allocator<std::pair<unsigned int, unsigned int> > > const&) + 29649
20 clang             0x000000010ef568e0 std::vector<std::pair<unsigned int,
unsigned int>, std::allocator<std::pair<unsigned int, unsigned int> >
>::operator=(std::vector<std::pair<unsigned int, unsigned int>,
std::allocator<std::pair<unsigned int, unsigned int> > > const&) + 35534
21 clang             0x000000010ef5ac4f std::vector<std::pair<unsigned int,
unsigned int>, std::allocator<std::pair<unsigned int, unsigned int> >
>::operator=(std::vector<std::pair<unsigned int, unsigned int>,
std::allocator<std::pair<unsigned int, unsigned int> > > const&) + 52797
22 clang             0x000000010ef6f6fd std::vector<std::pair<llvm::WeakVH,
llvm::Constant*>, std::allocator<std::pair<llvm::WeakVH, llvm::Constant*> >
>::_M_insert_aux(__gnu_cxx::__normal_iterator<std::pair<llvm::WeakVH,
llvm::Constant*>*, std::vector<std::pair<llvm::WeakVH, llvm::Constant*>,
std::allocator<std::pair<llvm::WeakVH, llvm::Constant*> > > >,
std::pair<llvm::WeakVH, llvm::Constant*> const&) + 4031
23 clang             0x000000010ef4d998 std::vector<clang::CXXRecordDecl
const*, std::allocator<clang::CXXRecordDecl const*>
>::_M_insert_aux(__gnu_cxx::__normal_iterator<clang::CXXRecordDecl const**,
std::vector<clang::CXXRecordDecl const*, std::allocator<clang::CXXRecordDecl
const*> > >, clang::CXXRecordDecl const* const&) + 6328
24 clang             0x000000010ef7b816 std::vector<std::pair<llvm::WeakVH,
llvm::Constant*>, std::allocator<std::pair<llvm::WeakVH, llvm::Constant*> >
>::_M_insert_aux(__gnu_cxx::__normal_iterator<std::pair<llvm::WeakVH,
llvm::Constant*>*, std::vector<std::pair<llvm::WeakVH, llvm::Constant*>,
std::allocator<std::pair<llvm::WeakVH, llvm::Constant*> > > >,
std::pair<llvm::WeakVH, llvm::Constant*> const&) + 53464
25 clang             0x000000010ef4d019 std::vector<clang::CXXRecordDecl
const*, std::allocator<clang::CXXRecordDecl const*>
>::_M_insert_aux(__gnu_cxx::__normal_iterator<clang::CXXRecordDecl const**,
std::vector<clang::CXXRecordDecl const*, std::allocator<clang::CXXRecordDecl
const*> > >, clang::CXXRecordDecl const* const&) + 3897
26 clang             0x000000010edbac36 std::_Rb_tree<clang::edit::FileOffset,
std::pair<clang::edit::FileOffset const, clang::edit::EditedSource::FileEdit>,
std::_Select1st<std::pair<clang::edit::FileOffset const,
clang::edit::EditedSource::FileEdit> >, std::less<clang::edit::FileOffset>,
std::allocator<std::pair<clang::edit::FileOffset const,
clang::edit::EditedSource::FileEdit> >
>::_M_erase(std::_Rb_tree_node<std::pair<clang::edit::FileOffset const,
clang::edit::EditedSource::FileEdit> >*) + 3676
27 clang             0x000000010eda3699 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&) + 11177
28 clang             0x000000010ed7b1fa std::_Rb_tree<std::string, std::string,
std::_Identity<std::string>, std::less<std::string>,
std::allocator<std::string> >::_M_insert_unique(std::string const&) + 3802
29 clang             0x000000010ed750bc
30 clang             0x000000010ed79c50 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&) +
7350
31 libdyld.dylib     0x00007fff8c69f7e1 start + 0
Stack dump:
0.    Program arguments: /usr/local/Cellar/llvm/3.2/bin/clang -cc1 -triple
x86_64-apple-macosx10.8.0 -emit-obj -mrelax-all -disable-free -main-file-name
test.c -mrelocation-model pic -pic-level 2 -mdisable-fp-elim -masm-verbose
-munwind-tables -target-cpu core2 -target-linker-version 136 -coverage-file
/Users/bruce/Development/llvm_bugs/invalid_asm_constraint/test.o -resource-dir
/usr/local/Cellar/llvm/3.2/bin/../lib/clang/3.2 -fmodule-cache-path
/var/folders/pj/fcfyqt6n2r5cjygxgtnfmv7h0000gn/T/clang-module-cache
-fdebug-compilation-dir
/Users/bruce/Development/llvm_bugs/invalid_asm_constraint -ferror-limit 19
-fmessage-length 204 -stack-protector 1 -mstackrealign -fblocks
-fobjc-runtime=macosx-10.8.0 -fobjc-dispatch-method=mixed
-fobjc-default-synthesize-properties -fencode-extended-block-signature
-fdiagnostics-show-option -fcolor-diagnostics -o test.o -x c test.c
1.    test.c:7:1: current parser token 'int'
2.    test.c:1:8: LLVM IR generation of declaration 'get'
3.    test.c:1:8: Generating code for declaration 'get'
4.    test.c:1:14: 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 version 3.2 (tags/RELEASE_32/final)
Target: x86_64-apple-darwin12.2.1
Thread model: posix
clang: note: diagnostic msg: PLEASE submit a bug report to
http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and
associated run script.
clang: note: diagnostic msg:
********************

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130416/d7ccc8da/attachment.html>

From bugzilla-daemon at llvm.org  Tue Apr 16 02:52:40 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 16 Apr 2013 09:52:40 +0000
Subject: [LLVMbugs] [Bug 15760] New: clang fails to support some msvc inline
 assembler syntax
Message-ID: <bug-15760-206@http.llvm.org/bugs/>

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

            Bug ID: 15760
           Summary: clang fails to support some msvc inline assembler
                    syntax
           Product: clang
           Version: unspecified
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
          Assignee: unassignedclangbugs at nondot.org
          Reporter: jmuizelaar at mozilla.com
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified

The following function fails to compile with:
test.c:4:28: error: unexpected token in argument list

void f()
{
        __asm {
                        mov ebp, (4 + 4) * -16
        }
}

This snippet comes from jxrlib.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130416/d7654cdc/attachment.html>

From bugzilla-daemon at llvm.org  Tue Apr 16 05:40:31 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 16 Apr 2013 12:40:31 +0000
Subject: [LLVMbugs] [Bug 15761] New: missing trailing space in EXTRA_FLAGS
 prevents libc++ from compiling
Message-ID: <bug-15761-206@http.llvm.org/bugs/>

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

            Bug ID: 15761
           Summary: missing trailing space in EXTRA_FLAGS prevents libc++
                    from compiling
           Product: libc++
           Version: 3.2
          Hardware: Macintosh
                OS: MacOS X
            Status: NEW
          Severity: release blocker
          Priority: P
         Component: All Bugs
          Assignee: hhinnant at apple.com
          Reporter: gonzalobg88 at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

There is a missing space at the end of the EXTRA_FLAGS variable inside the
buildit script that prevents libc++ from compiling. Currently: 

EXTRA_FLAGS="-std=c++0x -fstrict-aliasing -Wall -Wextra -Wshadow -Wconversion \ 
             -Wnewline-eof -Wpadded -Wmissing-prototypes -Wstrict-aliasing=2 \  
             -Wstrict-overflow=4"

Produces the following error in MacOS:

+
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++
-c -g -Os -arch i386 -arch x86_64 -std=c++0x -fstrict-aliasing -Wall -Wextra
-Wshadow -Wconversion -Wnewline-eof -Wpadded -Wmissing-prototypes
-Wstrict-aliasing=2 -Wstrict-overflow=4-isysroot
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/
-nostdinc++ -I../include ../src/algorithm.cpp
clang: warning: unknown warning option '-Wstrict-overflow=4-isysroot'; did you
mean '-Wshift-overflow'?
clang: warning:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/:
'linker' input unused
warning: unknown warning option '-Wstrict-overflow=4-isysroot'; did you mean
'-Wshift-overflow'? [-Wunknown-warning-option]


As you see there is a missing space between -Wstrict-overflow=4 and -isysroot. 

This can be fixed by just appending an extra space:

EXTRA_FLAGS="-std=c++0x -fstrict-aliasing -Wall -Wextra -Wshadow -Wconversion \ 
             -Wnewline-eof -Wpadded -Wmissing-prototypes -Wstrict-aliasing=2 \  
             -Wstrict-overflow=4 "

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130416/8db9ba90/attachment.html>

From bugzilla-daemon at llvm.org  Tue Apr 16 09:02:57 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 16 Apr 2013 16:02:57 +0000
Subject: [LLVMbugs] [Bug 4296] Add parser detection/error recovery for
	nested functions
In-Reply-To: <bug-4296-206@http.llvm.org/bugs/>
References: <bug-4296-206@http.llvm.org/bugs/>
Message-ID: <bug-4296-206-MWcaN6fYAm@http.llvm.org/bugs/>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #5 from Douglas Gregor <dgregor at apple.com> ---
Fixed in r179603

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130416/7e673476/attachment.html>

From bugzilla-daemon at llvm.org  Tue Apr 16 10:28:13 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 16 Apr 2013 17:28:13 +0000
Subject: [LLVMbugs] [Bug 15754] addressof returns wrong address when there
 is user provided conversion operator to char&
In-Reply-To: <bug-15754-206@http.llvm.org/bugs/>
References: <bug-15754-206@http.llvm.org/bugs/>
Message-ID: <bug-15754-206-SshN1HWMle@http.llvm.org/bugs/>

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

Howard Hinnant <hhinnant at apple.com> changed:

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

--- Comment #1 from Howard Hinnant <hhinnant at apple.com> ---
Fix Committed revision 179608.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130416/ed5a397b/attachment.html>

From bugzilla-daemon at llvm.org  Tue Apr 16 10:34:36 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 16 Apr 2013 17:34:36 +0000
Subject: [LLVMbugs] [Bug 15761] missing trailing space in EXTRA_FLAGS
 prevents libc++ from compiling
In-Reply-To: <bug-15761-206@http.llvm.org/bugs/>
References: <bug-15761-206@http.llvm.org/bugs/>
Message-ID: <bug-15761-206-6WNyPoOgl5@http.llvm.org/bugs/>

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

Howard Hinnant <hhinnant at apple.com> changed:

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

--- Comment #1 from Howard Hinnant <hhinnant at apple.com> ---
Fix Committed revision 179609.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130416/56ede1b0/attachment.html>

From bugzilla-daemon at llvm.org  Tue Apr 16 12:32:06 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 16 Apr 2013 19:32:06 +0000
Subject: [LLVMbugs] [Bug 14422] -frewrite-includes should rewrite
 __has_include and friends
In-Reply-To: <bug-14422-206@http.llvm.org/bugs/>
References: <bug-14422-206@http.llvm.org/bugs/>
Message-ID: <bug-14422-206-VDoY9wHltw@http.llvm.org/bugs/>

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

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

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

--- Comment #1 from Benjamin Kramer <benny.kra at gmail.com> ---
Implemented in r179616.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130416/f9ba057a/attachment.html>

From bugzilla-daemon at llvm.org  Tue Apr 16 14:27:38 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 16 Apr 2013 21:27:38 +0000
Subject: [LLVMbugs] [Bug 15762] New: clang -fixit hits an assertions when
 given two files
Message-ID: <bug-15762-206@http.llvm.org/bugs/>

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

            Bug ID: 15762
           Summary: clang -fixit hits an assertions when given two files
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: rtrieu at google.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

clang -cc1 -fixit a b

llvm/tools/clang/include/clang/Basic/Diagnostic.h:371: clang::SourceManager&
clang::DiagnosticsEngine::getSourceManager() const: Assertion `SourceMgr &&
"SourceManager not set!"' failed.

Running Clang fixit with any two files will cause an assertion failure.

Tested at r179627.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130416/12946099/attachment.html>

From bugzilla-daemon at llvm.org  Tue Apr 16 18:36:05 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 17 Apr 2013 01:36:05 +0000
Subject: [LLVMbugs] [Bug 15763] New: emits PPC asm with relocation overflow,
 displacement too large [powerpc-darwin8]
Message-ID: <bug-15763-206@http.llvm.org/bugs/>

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

            Bug ID: 15763
           Summary: emits PPC asm with relocation overflow, displacement
                    too large [powerpc-darwin8]
           Product: libraries
           Version: trunk
          Hardware: Macintosh
                OS: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: PowerPC
          Assignee: unassignedbugs at nondot.org
          Reporter: fang at csl.cornell.edu
                CC: llvmbugs at cs.uiuc.edu
        Depends on: 15726
    Classification: Unclassified

Using -no-integrated-as, my stage-2 build of LLVMSupport on powerpc-darwin8 now
halts at:

Linking CXX shared library ../libLLVMSupport.dylib
cd /Users/fang/local/src/LLVM-svn/gcc40-stage2-build/lib/Support &&
/Volumes/Mercedes2/sw/bin/cmake -E cmake_link_script
CMakeFiles/LLVMSupport.dir/link.txt --verbose=1
/Volumes/Isolde/sources/LLVM-svn/gcc40-cmake-build/bin/clang++ 
-I/usr/lib/gcc/powerpc-apple-darwin8/4.0.1/include -fno-common
-no-integrated-as -fno-dwarf2-cfi-asm -fPIC -fvisibility-inlines-hidden -Wall
-W -Wno-unused-parameter -Wwrite-strings -pedantic -Wno-long-long
-Wnon-virtual-dtor -fno-rtti -isysroot /Developer/SDKs/MacOSX10.4u.sdk
-dynamiclib -Wl,-headerpad_max_install_names -target 10.4
-L/Users/fang/local/src/LLVM-svn/gcc40-cmake-build/lib/clang/3.3/lib/darwin
-lclang_rt.ppc -o ../libLLVMSupport.dylib -install_name
/Users/fang/local/src/LLVM-svn/gcc40-stage2-build/lib/libLLVMSupport.dylib
CMakeFiles/LLVMSupport.dir/APFloat.cpp.o CMakeFiles/LLVMSupport.dir/APInt.cpp.o
CMakeFiles/LLVMSupport.dir/APSInt.cpp.o
CMakeFiles/LLVMSupport.dir/Allocator.cpp.o
CMakeFiles/LLVMSupport.dir/BlockFrequency.cpp.o
CMakeFiles/LLVMSupport.dir/BranchProbability.cpp.o
CMakeFiles/LLVMSupport.dir/circular_raw_ostream.cpp.o
CMakeFiles/LLVMSupport.dir/CommandLine.cpp.o
CMakeFiles/LLVMSupport.dir/ConstantRange.cpp.o
CMakeFiles/LLVMSupport.dir/ConvertUTF.c.o
CMakeFiles/LLVMSupport.dir/ConvertUTFWrapper.cpp.o
CMakeFiles/LLVMSupport.dir/CrashRecoveryContext.cpp.o
CMakeFiles/LLVMSupport.dir/DataExtractor.cpp.o
CMakeFiles/LLVMSupport.dir/DataStream.cpp.o
CMakeFiles/LLVMSupport.dir/Debug.cpp.o
CMakeFiles/LLVMSupport.dir/DeltaAlgorithm.cpp.o
CMakeFiles/LLVMSupport.dir/DAGDeltaAlgorithm.cpp.o
CMakeFiles/LLVMSupport.dir/Dwarf.cpp.o
CMakeFiles/LLVMSupport.dir/ErrorHandling.cpp.o
CMakeFiles/LLVMSupport.dir/FileUtilities.cpp.o
CMakeFiles/LLVMSupport.dir/FileOutputBuffer.cpp.o
CMakeFiles/LLVMSupport.dir/FoldingSet.cpp.o
CMakeFiles/LLVMSupport.dir/Format.cpp.o
CMakeFiles/LLVMSupport.dir/FormattedStream.cpp.o
CMakeFiles/LLVMSupport.dir/GraphWriter.cpp.o
CMakeFiles/LLVMSupport.dir/Hashing.cpp.o
CMakeFiles/LLVMSupport.dir/IntEqClasses.cpp.o
CMakeFiles/LLVMSupport.dir/IntervalMap.cpp.o
CMakeFiles/LLVMSupport.dir/IntrusiveRefCntPtr.cpp.o
CMakeFiles/LLVMSupport.dir/IsInf.cpp.o CMakeFiles/LLVMSupport.dir/IsNAN.cpp.o
CMakeFiles/LLVMSupport.dir/Locale.cpp.o
CMakeFiles/LLVMSupport.dir/LockFileManager.cpp.o
CMakeFiles/LLVMSupport.dir/ManagedStatic.cpp.o
CMakeFiles/LLVMSupport.dir/MemoryBuffer.cpp.o
CMakeFiles/LLVMSupport.dir/MemoryObject.cpp.o
CMakeFiles/LLVMSupport.dir/PluginLoader.cpp.o
CMakeFiles/LLVMSupport.dir/PrettyStackTrace.cpp.o
CMakeFiles/LLVMSupport.dir/Regex.cpp.o
CMakeFiles/LLVMSupport.dir/SmallPtrSet.cpp.o
CMakeFiles/LLVMSupport.dir/SmallVector.cpp.o
CMakeFiles/LLVMSupport.dir/SourceMgr.cpp.o
CMakeFiles/LLVMSupport.dir/Statistic.cpp.o
CMakeFiles/LLVMSupport.dir/StreamableMemoryObject.cpp.o
CMakeFiles/LLVMSupport.dir/StringExtras.cpp.o
CMakeFiles/LLVMSupport.dir/StringMap.cpp.o
CMakeFiles/LLVMSupport.dir/StringPool.cpp.o
CMakeFiles/LLVMSupport.dir/StringRef.cpp.o
CMakeFiles/LLVMSupport.dir/SystemUtils.cpp.o
CMakeFiles/LLVMSupport.dir/Timer.cpp.o
CMakeFiles/LLVMSupport.dir/ToolOutputFile.cpp.o
CMakeFiles/LLVMSupport.dir/Triple.cpp.o CMakeFiles/LLVMSupport.dir/Twine.cpp.o
CMakeFiles/LLVMSupport.dir/YAMLParser.cpp.o
CMakeFiles/LLVMSupport.dir/YAMLTraits.cpp.o
CMakeFiles/LLVMSupport.dir/raw_os_ostream.cpp.o
CMakeFiles/LLVMSupport.dir/raw_ostream.cpp.o
CMakeFiles/LLVMSupport.dir/regcomp.c.o CMakeFiles/LLVMSupport.dir/regerror.c.o
CMakeFiles/LLVMSupport.dir/regexec.c.o CMakeFiles/LLVMSupport.dir/regfree.c.o
CMakeFiles/LLVMSupport.dir/regstrlcpy.c.o
CMakeFiles/LLVMSupport.dir/Atomic.cpp.o
CMakeFiles/LLVMSupport.dir/Disassembler.cpp.o
CMakeFiles/LLVMSupport.dir/DynamicLibrary.cpp.o
CMakeFiles/LLVMSupport.dir/Errno.cpp.o CMakeFiles/LLVMSupport.dir/Host.cpp.o
CMakeFiles/LLVMSupport.dir/IncludeFile.cpp.o
CMakeFiles/LLVMSupport.dir/Memory.cpp.o CMakeFiles/LLVMSupport.dir/Mutex.cpp.o
CMakeFiles/LLVMSupport.dir/Path.cpp.o CMakeFiles/LLVMSupport.dir/PathV2.cpp.o
CMakeFiles/LLVMSupport.dir/Process.cpp.o
CMakeFiles/LLVMSupport.dir/Program.cpp.o
CMakeFiles/LLVMSupport.dir/RWMutex.cpp.o
CMakeFiles/LLVMSupport.dir/SearchForAddressOfSpecialSymbol.cpp.o
CMakeFiles/LLVMSupport.dir/Signals.cpp.o
CMakeFiles/LLVMSupport.dir/system_error.cpp.o
CMakeFiles/LLVMSupport.dir/TargetRegistry.cpp.o
CMakeFiles/LLVMSupport.dir/ThreadLocal.cpp.o
CMakeFiles/LLVMSupport.dir/Threading.cpp.o
CMakeFiles/LLVMSupport.dir/TimeValue.cpp.o
CMakeFiles/LLVMSupport.dir/Valgrind.cpp.o
CMakeFiles/LLVMSupport.dir/Watchdog.cpp.o
CMakeFiles/LLVMSupport.dir/stacktrace.cc.o -lpthread -lclang_rt.ppc
ld: CMakeFiles/LLVMSupport.dir/APInt.cpp.o relocation overflow for relocation
entry 9 in section (__TEXT,__picsymbolstub1) (displacement too large)
ld: CMakeFiles/LLVMSupport.dir/APInt.cpp.o relocation overflow for relocation
entry 14 in section (__TEXT,__picsymbolstub1) (displacement too large)
ld: CMakeFiles/LLVMSupport.dir/APInt.cpp.o relocation overflow for relocation
entry 19 in section (__TEXT,__picsymbolstub1) (displacement too large)
ld: CMakeFiles/LLVMSupport.dir/Allocator.cpp.o relocation overflow for
relocation entry 4 in section (__TEXT,__picsymbolstub1) (displacement too
large)
ld: CMakeFiles/LLVMSupport.dir/Allocator.cpp.o relocation overflow for
relocation entry 9 in section (__TEXT,__picsymbolstub1) (displacement too
large)
ld: CMakeFiles/LLVMSupport.dir/BlockFrequency.cpp.o relocation overflow for
relocation entry 4 in section (__TEXT,__picsymbolstub1) (displacement too
large)
ld: CMakeFiles/LLVMSupport.dir/BranchProbability.cpp.o relocation overflow for
relocation entry 9 in section (__TEXT,__picsymbolstub1) (displacement too
large)
ld: CMakeFiles/LLVMSupport.dir/circular_raw_ostream.cpp.o relocation overflow
for relocation entry 4 in section (__TEXT,__picsymbolstub1) (displacement too
large)
... more ...

This doesn't involve the MC code yet.
The system assembler /usr/bin/as doesn't complain.
Only the linker does.
Is the assembly generated bad?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130417/278350e4/attachment.html>

From bugzilla-daemon at llvm.org  Wed Apr 17 01:31:45 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 17 Apr 2013 08:31:45 +0000
Subject: [LLVMbugs] [Bug 11612] _Atomic does not allow initialisation --
 needed for ATOMIC_VAR_INIT()
In-Reply-To: <bug-11612-206@http.llvm.org/bugs/>
References: <bug-11612-206@http.llvm.org/bugs/>
Message-ID: <bug-11612-206-GDYrrCoFHU@http.llvm.org/bugs/>

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

Serge Pavlov <sepavloff at gmail.com> changed:

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

--- Comment #2 from Serge Pavlov <sepavloff at gmail.com> ---
Atomics are already implemented in clang (r179662), see examples of
initialization in regression test CodeGen/c11atomics.c.
So closing the bug.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130417/0026bc8d/attachment.html>

From bugzilla-daemon at llvm.org  Wed Apr 17 01:54:57 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 17 Apr 2013 08:54:57 +0000
Subject: [LLVMbugs] [Bug 13457] [Windows] Explicit __cdecl function pointers
 are not compatible with implicit ones
In-Reply-To: <bug-13457-206@http.llvm.org/bugs/>
References: <bug-13457-206@http.llvm.org/bugs/>
Message-ID: <bug-13457-206-AuZk0ezu5R@http.llvm.org/bugs/>

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

Bug 13457 depends on bug 15291, which changed state.

Bug 15291 Summary: Noreturn adjustment in overload resolution for function templates
http://llvm.org/bugs/show_bug.cgi?id=15291

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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130417/67090507/attachment.html>

From bugzilla-daemon at llvm.org  Wed Apr 17 01:54:56 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 17 Apr 2013 08:54:56 +0000
Subject: [LLVMbugs] [Bug 15291] Noreturn adjustment in overload resolution
 for function templates
In-Reply-To: <bug-15291-206@http.llvm.org/bugs/>
References: <bug-15291-206@http.llvm.org/bugs/>
Message-ID: <bug-15291-206-R4APy8kmxx@http.llvm.org/bugs/>

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

Alexander Zinenko <ftynse at gmail.com> changed:

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

--- Comment #3 from Alexander Zinenko <ftynse at gmail.com> ---
Fixed as of r179680.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130417/782f931d/attachment.html>

From bugzilla-daemon at llvm.org  Wed Apr 17 02:06:13 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 17 Apr 2013 09:06:13 +0000
Subject: [LLVMbugs] [Bug 15764] New: unable to match template friend
 conversion operator in redeclaration lookup
Message-ID: <bug-15764-206@http.llvm.org/bugs/>

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

            Bug ID: 15764
           Summary: unable to match template friend conversion operator in
                    redeclaration lookup
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++11
          Assignee: unassignedclangbugs at nondot.org
          Reporter: richard-llvm at metafoo.co.uk
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Clang rejects this:

template<typename T, typename U> using X = T(*)(U);
struct S { template<typename T, typename U> operator X<T,U>(); };
struct U { template<typename T, typename U> friend S::operator X<T,U>(); };

error: no function named 'operator type-parameter-0-0 (*)(struct U)' with type
'X<T, U> ()' was found in the specified scope

This code is valid; EDG and g++ accept.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130417/d3e2ba71/attachment.html>

From bugzilla-daemon at llvm.org  Wed Apr 17 02:19:55 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 17 Apr 2013 09:19:55 +0000
Subject: [LLVMbugs] [Bug 15765] New: inline assembly and =g constraint on
 output argument
Message-ID: <bug-15765-206@http.llvm.org/bugs/>

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

            Bug ID: 15765
           Summary: inline assembly and =g constraint on output argument
           Product: new-bugs
           Version: 3.2
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: bruce.mitchener at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

In emscripten, we support having JS as "inline assembly" (it makes perfect
sense in context).

With a very simple program:

    double get() {
      double ret = 0;
      __asm __volatile__("12/3.3":"=r"(ret));
      return ret;
    }

    int main() {
      return (int)get();
    }

And compiling it:

    /usr/local/bin/clang -target i386-pc-linux-gnu -emit-llvm -S -o m-r.ll
test.c

the inline asm compiles to:

    %0 = call double asm sideeffect "12/3.3",
"=r,~{dirflag},~{fpsr},~{flags}"() nounwind, !srcloc !0

However, changing it to a =g constraint instead of =r results in this:

    call void asm sideeffect "12/3.3",
"=*imr,~{dirflag},~{fpsr},~{flags}"(double* %ret) nounwind, !srcloc !0

This shows that it isn't picking up the value into ret.

Is =g permissible here or must I use =r?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130417/18f6095d/attachment.html>

From bugzilla-daemon at llvm.org  Wed Apr 17 02:57:51 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 17 Apr 2013 09:57:51 +0000
Subject: [LLVMbugs] [Bug 13924] Regression(likely r163022): macro expansion
 is broken in microsoft mode
In-Reply-To: <bug-13924-206@http.llvm.org/bugs/>
References: <bug-13924-206@http.llvm.org/bugs/>
Message-ID: <bug-13924-206-LO25Y0RQyf@http.llvm.org/bugs/>

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

Will Wilson <lantictac at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
                 CC|                            |lantictac at gmail.com
         Resolution|FIXED                       |---

--- Comment #2 from Will Wilson <lantictac at gmail.com> ---
As the original patch was reverted due to some regressions I've reopened this
to ensure it's not forgotten.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130417/79fef88f/attachment.html>

From bugzilla-daemon at llvm.org  Wed Apr 17 03:00:06 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 17 Apr 2013 10:00:06 +0000
Subject: [LLVMbugs] [Bug 15766] New: fatal error: error in backend: Cannot
 select: 0x9956be8: i32 = fabs 0x995a980 [ORD=256] [ID=18]
Message-ID: <bug-15766-206@http.llvm.org/bugs/>

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

            Bug ID: 15766
           Summary: fatal error: error in backend: Cannot select:
                    0x9956be8: i32 = fabs 0x995a980 [ORD=256] [ID=18]
           Product: clang
           Version: 3.2
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: paulepanter at users.sourceforge.net
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Under Debian Sid/unstable building Midori from git works with gcc

    $ gcc --version
    gcc-4.7.real (Debian 4.7.2-15) 4.7.2
    Copyright (C) 2012 Free Software Foundation, Inc.
    This is free software; see the source for copying conditions.  There is NO
    warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

but fails with Clang.

    $ clang --version
    Debian clang version 3.2-1~exp6 (tags/RELEASE_32/final) (based on LLVM 3.2)
    Target: i386-pc-linux-gnu
    Thread model: posix
    $ git clone git://git.xfce.org/apps/midori

Add `--depth 1` clone if you do not want the whole history. Note, that I only
tested with the commit below.

    $ cd midori
    $ git describe
    0.5.0-68-g7e985a2

Get dependencies. Under Debian run `sudo aptitude build-dep midori`.

    $ ./waf clean
    […]
    $ CC=clang ./waf configure
    Checking for release version             : 0.5.0-68-g7e985a2 
    Checking for program gcc or cc           : clang 
    Checking for program cpp                 : /usr/bin/cpp 
    Checking for program ar                  : /usr/bin/ar 
    Checking for program ranlib              : /usr/bin/ranlib 
    Checking for gcc                         : ok  
    Checking for program valac               : /usr/bin/valac 
    Checking for gobject-2.0                 : yes 
    Checking for gthread-2.0                 : yes 
    Checking for program version valac >= 0.1.6 : ok 0.16.1 
    Checking for program glib-genmarshal        : /usr/bin/glib-genmarshal 
    Checking for program glib-mkenums           : /usr/bin/glib-mkenums 
    Checking for program msgfmt                 : /usr/bin/msgfmt 
    Checking for program intltool-merge         : /usr/bin/intltool-merge 
    Checking for header locale.h                : yes 
    Checking for program rsvg-convert           : /usr/bin/rsvg-convert 
    Checking for gtk-doc                        : disabled 
    Checking for libnotify                      : 0.7.5 
    Checking for granite                        : disabled 
    Checking for zeitgeist-1.0 >= 0.3.14        : 0.3.18 
    Checking for library m                      : yes 
    Checking for gmodule-2.0                    : 2.32.4 
    Checking for gio-2.0 >= 2.22.0              : 2.32.4 
    Checking for x11                            : 1.5.0 
    Checking for header X11/extensions/scrnsaver.h : yes 
    Checking for library Xss                       : yes 
    Checking for gtk+-2.0 >= 2.16.0                : 2.24.10 
    Checking for webkit-1.0 >= 1.1.17              : 1.8.1 
    Checking for gcr-3-gtk2 >= 2.32                : no 
    gcr-3-gtk2 >= 2.32 not found 
    Checking for javascriptcoregtk-1.0 >= 1.5.1    : 1.8.1 
    Checking for unique-1.0 >= 0.9                 : 1.1.6 
    Checking for libsoup-2.4 >= 2.27.90            : 2.38.1 
    Checking for libxml-2.0 >= 2.6                 : 2.8.0 
    Checking for sqlite3 >= 3.6.19                 : 3.7.16.1 
    Checking for header unistd.h                   : yes 
    Checking for header signal.h                   : yes 
    'configure' finished successfully (10.926s)
    $ ./waf build
    Waf: Entering directory `/src/midori/_build'
    [  1/158] valac: katze/katze-separatoraction.vala katze/midori-hsts.vala
katze/midori-paths.vala katze/midori-uri.vala midori/midori-completion.vala
midori/midori-dialog.vala midori/midori-download.vala
midori/midori-extensions-column.vala midori/midori-historycompletion.vala
midori/midori-panedaction.vala midori/midori-searchcompletion.vala
midori/midori-settings.vala midori/midori-speeddial.vala midori/midori-tab.vala
midori/midori-viewable.vala midori/midori-viewcompletion.vala ->
_build/default/katze/katze-separatoraction.c
_build/default/midori/midori-core.h _build/default/midori/midori-core.vapi
_build/default/midori/midori-core.deps _build/default/katze/midori-hsts.c
_build/default/midori/midori-core.h _build/default/midori/midori-core.vapi
_build/default/midori/midori-core.deps _build/default/katze/midori-paths.c
_build/default/midori/midori-core.h _build/default/midori/midori-core.vapi
_build/default/midori/midori-core.deps _build/default/katze/midori-uri.c
_build/default/midori/midori-core.h _build/default/midori/midori-core.vapi
_build/default/midori/midori-core.deps
_build/default/midori/midori-completion.c _build/default/midori/midori-core.h
_build/default/midori/midori-core.vapi _build/default/midori/midori-core.deps
_build/default/midori/midori-dialog.c _build/default/midori/midori-core.h
_build/default/midori/midori-core.vapi _build/default/midori/midori-core.deps
_build/default/midori/midori-download.c _build/default/midori/midori-core.h
_build/default/midori/midori-core.vapi _build/default/midori/midori-core.deps
_build/default/midori/midori-extensions-column.c
_build/default/midori/midori-core.h _build/default/midori/midori-core.vapi
_build/default/midori/midori-core.deps
_build/default/midori/midori-historycompletion.c
_build/default/midori/midori-core.h _build/default/midori/midori-core.vapi
_build/default/midori/midori-core.deps
_build/default/midori/midori-panedaction.c _build/default/midori/midori-core.h
_build/default/midori/midori-core.vapi _build/default/midori/midori-core.deps
_build/default/midori/midori-searchcompletion.c
_build/default/midori/midori-core.h _build/default/midori/midori-core.vapi
_build/default/midori/midori-core.deps _build/default/midori/midori-settings.c
_build/default/midori/midori-core.h _build/default/midori/midori-core.vapi
_build/default/midori/midori-core.deps _build/default/midori/midori-speeddial.c
_build/default/midori/midori-core.h _build/default/midori/midori-core.vapi
_build/default/midori/midori-core.deps _build/default/midori/midori-tab.c
_build/default/midori/midori-core.h _build/default/midori/midori-core.vapi
_build/default/midori/midori-core.deps _build/default/midori/midori-viewable.c
_build/default/midori/midori-core.h _build/default/midori/midori-core.vapi
_build/default/midori/midori-core.deps
_build/default/midori/midori-viewcompletion.c
_build/default/midori/midori-core.h _build/default/midori/midori-core.vapi
_build/default/midori/midori-core.deps
    ../katze/midori-uri.vala:19.60-19.74: warning: use of possibly unassigned
parameter `path'
    ../katze/midori-uri.vala:173.34-173.49: warning: use of possibly unassigned
parameter `label'
    ../katze/midori-uri.vala:173.13-173.31: warning: use of possibly unassigned
parameter `checksum'
    ../midori/midori-download.vala:271.66-271.84: warning: use of possibly
unassigned parameter `basename'
    ../midori/midori-speeddial.vala:121.43-121.56: warning: use of possibly
unassigned parameter `count'
    [  2/158] cc: _build/default/katze/katze-separatoraction.c ->
_build/default/katze/katze-separatoraction_1.o
    [  3/158] cc: _build/default/katze/midori-hsts.c ->
_build/default/katze/midori-hsts_1.o
    fatal error: error in backend: Cannot select: 0x9956be8: i32 = fabs
0x995a980 [ORD=256] [ID=18]
          dbg:/src/midori/katze/midori-hsts.vala:23
      0x995a980: i32 = zero_extend 0x995b288 [ID=17]
        0x995b288: i8 = X86ISD::SETCC 0x99568b8, 0x995b8e8 [ID=16]
          0x99568b8: i8 = Constant<9> [ID=10]
          0x995b8e8: i32 = X86ISD::CMP 0x995c758, 0x995aa90 [ID=14]
            0x995c758: i32,ch = load 0x98f6500, 0x9956cf8,
0x995be50<LD4[FixedStack-2]> [ORD=254] [ID=12]
              0x9956cf8: i32 = FrameIndex<-2> [ORD=254] [ID=3]
              0x995be50: i32 = undef [ORD=254] [ID=2]
            0x995aa90: i32 = Constant<0> [ORD=254] [ID=6]
    In function: midori_hsts_directive_construct_from_header
    Waf: Leaving directory `/src/midori/_build'
    Build failed:  -> task failed (err #1): 
        {task: cc midori-hsts.c -> midori-hsts_1.o}

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130417/9f3b6945/attachment.html>

From bugzilla-daemon at llvm.org  Wed Apr 17 03:01:40 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 17 Apr 2013 10:01:40 +0000
Subject: [LLVMbugs] [Bug 13924] Regression(likely r163022): macro expansion
 is broken in microsoft mode
In-Reply-To: <bug-13924-206@http.llvm.org/bugs/>
References: <bug-13924-206@http.llvm.org/bugs/>
Message-ID: <bug-13924-206-ej9EDEe02q@http.llvm.org/bugs/>

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

Will Wilson <lantictac at gmail.com> changed:

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

--- Comment #3 from Will Wilson <lantictac at gmail.com> ---
My apologies. This bug is for the regression caused by the fix for the issue I
meant to add to Bugzilla - resetting this to original fixed status.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130417/71e4dbc5/attachment.html>

From bugzilla-daemon at llvm.org  Wed Apr 17 05:19:16 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 17 Apr 2013 12:19:16 +0000
Subject: [LLVMbugs] [Bug 15765] inline assembly and =g constraint on output
	argument
In-Reply-To: <bug-15765-206@http.llvm.org/bugs/>
References: <bug-15765-206@http.llvm.org/bugs/>
Message-ID: <bug-15765-206-3Z42B1syKt@http.llvm.org/bugs/>

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

Duncan Sands <baldrick at free.fr> changed:

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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130417/ac144073/attachment.html>

From bugzilla-daemon at llvm.org  Wed Apr 17 06:30:49 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 17 Apr 2013 13:30:49 +0000
Subject: [LLVMbugs] [Bug 15767] New: Calls to @llvm.annotation.i32 not being
 removed before code generation
Message-ID: <bug-15767-206@http.llvm.org/bugs/>

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

            Bug ID: 15767
           Summary: Calls to @llvm.annotation.i32 not being removed before
                    code generation
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Common Code Generator Code
          Assignee: unassignedbugs at nondot.org
          Reporter: khilan.gudka at cl.cam.ac.uk
                CC: csdavec at swan.ac.uk, llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 10359
  --> http://llvm.org/bugs/attachment.cgi?id=10359&action=edit
Test case

Hi

This bug is similar to #15253 (http://llvm.org/bugs/show_bug.cgi?id=15253).

Annotations added using the clang builtin __builtin_annotation get turned into
calls to the intrinsic @llvm.annotation.i32. However, these intrinsic calls do
not seem to be removed before code generation because the following fatal error
occurs in the backend:

"fatal error: error in backend: Cannot select: intrinsic %llvm.annotation"

Cheers

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130417/60f03677/attachment.html>

From bugzilla-daemon at llvm.org  Wed Apr 17 07:22:35 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 17 Apr 2013 14:22:35 +0000
Subject: [LLVMbugs] [Bug 13676] [Windows] Segmentation fault when returning
 a struct from a function or instance method
In-Reply-To: <bug-13676-206@http.llvm.org/bugs/>
References: <bug-13676-206@http.llvm.org/bugs/>
Message-ID: <bug-13676-206-HpwQ8f5k57@http.llvm.org/bugs/>

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

Timur Iskhodzhanov <timurrrr at google.com> changed:

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

--- Comment #7 from Timur Iskhodzhanov <timurrrr at google.com> ---
A fix for everything I know except for __cdecl methods has been committed as
r179681.
I'll file an issue for __cdecl soon.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130417/96cac233/attachment.html>

From bugzilla-daemon at llvm.org  Wed Apr 17 07:22:37 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 17 Apr 2013 14:22:37 +0000
Subject: [LLVMbugs] [Bug 12477] [meta] Support Microsoft C++ ABI
In-Reply-To: <bug-12477-206@http.llvm.org/bugs/>
References: <bug-12477-206@http.llvm.org/bugs/>
Message-ID: <bug-12477-206-ruoAZqQxxk@http.llvm.org/bugs/>

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

Bug 12477 depends on bug 13676, which changed state.

Bug 13676 Summary: [Windows] Segmentation fault when returning a struct from a function or instance method
http://llvm.org/bugs/show_bug.cgi?id=13676

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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130417/430438ee/attachment.html>

From bugzilla-daemon at llvm.org  Wed Apr 17 07:50:03 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 17 Apr 2013 14:50:03 +0000
Subject: [LLVMbugs] [Bug 15768] New: [-cxx-abi microsoft] __cdecl methods
 returning structures misbehave
Message-ID: <bug-15768-206@http.llvm.org/bugs/>

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

            Bug ID: 15768
           Summary: [-cxx-abi microsoft] __cdecl methods returning
                    structures misbehave
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
          Assignee: unassignedclangbugs at nondot.org
          Reporter: timurrrr at google.com
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified

----------------
$ cat cl.cpp
extern "C" int printf(const char *fmt, ...);

struct S {
  int a, b, c;
};

struct This {
  S __cdecl foo(S x);
  int field;
};

int main(void) {
  This obj;
  obj.field = 13;
  S arg;
  arg.a = 99;
  S s = obj.foo(arg);
  printf("obj.field = %d\n", obj.field);
  return 0;
}
----------------
$ cat clang.cpp
extern "C" int printf(const char *fmt, ...);

struct S {
  int a, b, c;
};

struct This {
  S __cdecl foo(S x);
  int field;
};

S __cdecl This::foo(S x) {
  S ret;
  ret.a = 42;
  printf("field = %d, x.a = %d\n", field, x.a);
  field = 77;
  return ret;
}
----------------
$ cl cl.cpp clang.cpp && ./cl.exe
field = 13, x.a = 99
obj.field = 77
----------------
$ clang -Xclang -cxx-abi -Xclang microsoft clang.cpp -c && \
  cl -nologo -c cl.cpp && link clang.o cl.obj && ./clang.exe
field = -2, x.a = 99
obj.field = 42
(As of Clang r179681)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130417/8ca7af7d/attachment.html>

From bugzilla-daemon at llvm.org  Wed Apr 17 08:19:31 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 17 Apr 2013 15:19:31 +0000
Subject: [LLVMbugs] [Bug 15766] fatal error: error in backend: Cannot
 select: 0x9956be8: i32 = fabs 0x995a980 [ORD=256] [ID=18]
In-Reply-To: <bug-15766-206@http.llvm.org/bugs/>
References: <bug-15766-206@http.llvm.org/bugs/>
Message-ID: <bug-15766-206-BqsykGdFx0@http.llvm.org/bugs/>

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

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

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

--- Comment #1 from Benjamin Kramer <benny.kra at gmail.com> ---


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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130417/6709cebf/attachment.html>

From bugzilla-daemon at llvm.org  Wed Apr 17 08:31:48 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 17 Apr 2013 15:31:48 +0000
Subject: [LLVMbugs] [Bug 15769] New: need eager instantiation of default
 template arguments
Message-ID: <bug-15769-206@http.llvm.org/bugs/>

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

            Bug ID: 15769
           Summary: need eager instantiation of default template arguments
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++11
          Assignee: unassignedclangbugs at nondot.org
          Reporter: richard-llvm at metafoo.co.uk
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified

This is ill-formed (with a required diagnostic):

  #include <type_traits>

  template<class T>
  struct X {
    template<class U = typename T::type>
    static void foo(int){}
    static void foo(...){}
  };

  int main(){
    X<std::enable_if<false>>::foo(0);
  }

g++ and EDG reject, clang accepts.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130417/abff045f/attachment.html>

From bugzilla-daemon at llvm.org  Wed Apr 17 09:54:43 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 17 Apr 2013 16:54:43 +0000
Subject: [LLVMbugs] [Bug 15770] New: mergefunc could improve in face of
	virtual methods?
Message-ID: <bug-15770-206@http.llvm.org/bugs/>

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

            Bug ID: 15770
           Summary: mergefunc could improve in face of virtual methods?
           Product: new-bugs
           Version: 3.2
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: bruce.mitchener at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 10360
  --> http://llvm.org/bugs/attachment.cgi?id=10360&action=edit
Example C++ file

With emscripten, we'd like to be able to use the mergefunc optimization pass
and in looking at the results of using it, a lot of thunks are created for
virtual methods, presumably due to vtable references.

I've attached an example C++ file that demonstrates a very basic case of this.
Why do we need the thunk in this situation? Do we really need the bitcast?

I compiled the attached file as follows:

    /usr/local/bin/clang++ -emit-llvm -S -o test.ll -c test.cpp

And then ran opt:

    /usr/local/bin/opt -debug -mergefunc test.ll -o opt-test.bc

And that told me:

    Args: /usr/local/bin/opt -debug -mergefunc test.ll -o opt-test.bc
    size of module: 11
    size of worklist: 8
    Inserting as unique: main
    Inserting as unique: _ZN1BC1Ev
    Inserting as unique: _ZN1CC1Ev
    Inserting as unique: _ZN1CC2Ev
    Inserting as unique: _ZN1AC2Ev
    Inserting as unique: _ZN1C3fooEi
    Inserting as unique: _ZN1BC2Ev
      _ZN1C3fooEi == _ZN1B3fooEi
    writeThunk: _ZN1B3fooEi
    size of FnSet: 7

Any chance this could be better?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130417/eb714afd/attachment.html>

From bugzilla-daemon at llvm.org  Wed Apr 17 11:58:08 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 17 Apr 2013 18:58:08 +0000
Subject: [LLVMbugs] [Bug 15772] New: no diagnostic for template friend which
 names nonexistent class member
Message-ID: <bug-15772-206@http.llvm.org/bugs/>

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

            Bug ID: 15772
           Summary: no diagnostic for template friend which names
                    nonexistent class member
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
          Assignee: unassignedclangbugs at nondot.org
          Reporter: richard-llvm at metafoo.co.uk
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Clang accepts this:

  struct X { const char *f(); };
  struct B { template<typename T> friend void X::f(T); };

It looks like we're injecting the friend template into the scope of X rather
than requiring it to redeclare a member in X. We do diagnose if there is no
function named 'f' in X, however.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130417/1b8077d3/attachment.html>

From bugzilla-daemon at llvm.org  Wed Apr 17 12:02:31 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 17 Apr 2013 19:02:31 +0000
Subject: [LLVMbugs] [Bug 15755] Failed to inherit variadic template
 constructor from base's base.
In-Reply-To: <bug-15755-206@http.llvm.org/bugs/>
References: <bug-15755-206@http.llvm.org/bugs/>
Message-ID: <bug-15755-206-XeTgAs4sNY@http.llvm.org/bugs/>

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

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> ---
We were treating parameter packs like parameters with default arguments when
building the set of inherited constructors. Fixed in r179708, thanks for the
report.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130417/7e20d234/attachment.html>

From bugzilla-daemon at llvm.org  Wed Apr 17 12:14:14 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 17 Apr 2013 19:14:14 +0000
Subject: [LLVMbugs] [Bug 12070] Clang errors while semantic checking with
 incomplete class member pointer type
In-Reply-To: <bug-12070-206@http.llvm.org/bugs/>
References: <bug-12070-206@http.llvm.org/bugs/>
Message-ID: <bug-12070-206-nPvd0zOkMH@http.llvm.org/bugs/>

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

João Matos <ripzonetriton at gmail.com> changed:

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

--- Comment #22 from João Matos <ripzonetriton at gmail.com> ---
Should be fixed as of r178283.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130417/f348d14d/attachment.html>

From bugzilla-daemon at llvm.org  Wed Apr 17 12:14:17 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 17 Apr 2013 19:14:17 +0000
Subject: [LLVMbugs] [Bug 13707] [meta] VCPP compatibility issues
In-Reply-To: <bug-13707-206@http.llvm.org/bugs/>
References: <bug-13707-206@http.llvm.org/bugs/>
Message-ID: <bug-13707-206-c7Skk9MkhX@http.llvm.org/bugs/>

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

Bug 13707 depends on bug 12070, which changed state.

Bug 12070 Summary: Clang errors while semantic checking with incomplete class member pointer type
http://llvm.org/bugs/show_bug.cgi?id=12070

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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130417/13631798/attachment.html>

From bugzilla-daemon at llvm.org  Wed Apr 17 12:24:24 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 17 Apr 2013 19:24:24 +0000
Subject: [LLVMbugs] [Bug 15613] [-verify] expected-warning does not allow me
 to specify the file
In-Reply-To: <bug-15613-206@http.llvm.org/bugs/>
References: <bug-15613-206@http.llvm.org/bugs/>
Message-ID: <bug-15613-206-5UAj8z2YsV@http.llvm.org/bugs/>

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

Andy Gibbs <andyg1001 at hotmail.co.uk> changed:

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

--- Comment #5 from Andy Gibbs <andyg1001 at hotmail.co.uk> ---
All done!

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130417/5695abec/attachment.html>

From bugzilla-daemon at llvm.org  Wed Apr 17 12:24:41 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 17 Apr 2013 19:24:41 +0000
Subject: [LLVMbugs] [Bug 15773] New: X86_64: Assertion failure "Unknown
 mismatch!" in SelectionDAGBuilder
Message-ID: <bug-15773-206@http.llvm.org/bugs/>

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

            Bug ID: 15773
           Summary: X86_64: Assertion failure "Unknown mismatch!" in
                    SelectionDAGBuilder
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Windows XP
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: X86
          Assignee: unassignedbugs at nondot.org
          Reporter: kai at redstar.de
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 10363
  --> http://llvm.org/bugs/attachment.cgi?id=10363&action=edit
.ll file crashing llc

The attached bug.ll creates the following failure:

Assertion failed: (PartVT.isInteger() || PartVT == MVT::x86mmx) &&
ValueVT.isInteger() && "Unknown mismatch!", file
D:\OpenSource\LLVM\llvm-git\lib\CodeGen\SelectionDAG\SelectionDAGBuilder.cpp,
line 371
Stack dump:
0.    Program arguments: llc bug.ll 
1.    Running pass 'Function Pass Manager' on module 'bug.ll'.
2.    Running pass 'X86 DAG->DAG Instruction Selection' on function '@ldexpl'
0x000007FEE8D856A2 (0x000007FE0000000A 0x0000000100000001 0x000000CB00000000
0x000007FEE8F4E6A0), exit() + 0x172 bytes(s)
0x000007FEE8EAFB44 (0x000007FEE8F4E6A0 0x000007FEE8F50BD0 0x0000000140E17590
0x0000000140E174F0), abort() + 0x24 bytes(s)
0x000007FEE8E9AB94 (0x0000000140E17590 0x0000000140E174F0 0xCCCCCCCC00000173
0xCCCCCCCCCCCCCCCC), _wassert() + 0xE74 bytes(s)
0x000000013FB9507E (0x0000000000DC1FE0 0x0000000000000000 0x0000000000BAB610
0x0000000000BAB358), getCopyToParts() + 0x3FE bytes(s),
d:\opensource\llvm\llvm-git\lib\codegen\selectiondag\selectiondagbuilder.cpp,
line 371 + 0x79 byte(s)
0x000000013FB96E6C (0x0000000000BAB970 0x0000000000BADEF0 0x0000000000DC1FE0
0x0000000000000000), `anonymous namespace'::RegsForValue::getCopyToRegs() +
0x2CC bytes(s),
d:\opensource\llvm\llvm-git\lib\codegen\selectiondag\selectiondagbuilder.cpp,
line 781
0x000000013FB87571 (0x0000000000DC2810 0x0000000000D7F38A 0xCCCCCCCCCCCCCCCC
0xCCCCCCCCCCCCCCCC), llvm::SelectionDAGBuilder::visitInlineAsm() + 0x2421
bytes(s),
d:\opensource\llvm\llvm-git\lib\codegen\selectiondag\selectiondagbuilder.cpp,
line 6263
0x000000013FB83928 (0x0000000000DC2810 0x0000000000D7F388 0xCCCCCCCCCCCCCCCC
0xCCCCCCCCCCCCCCCC), llvm::SelectionDAGBuilder::visitCall() + 0x88 bytes(s),
d:\opensource\llvm\llvm-git\lib\codegen\selectiondag\selectiondagbuilder.cpp,
line 5524
0x000000013FB6F14B (0x0000000000DC2810 0xCCCCCCCC00000030 0x0000000000D7F388
0xCCCCCCCCCCCCCCCC), llvm::SelectionDAGBuilder::visit() + 0x42B bytes(s),
d:\opensource\llvm\llvm-git\include\llvm\ir\instruction.def, line 164 + 0xF
byte(s)
0x000000013FB6ECCB (0x0000000000DC2810 0x0000000000D7F388 0xCCCCCCCCCCCCCCCC
0xCCCCCCCCCCCCCCCC), llvm::SelectionDAGBuilder::visit() + 0x7B bytes(s),
d:\opensource\llvm\llvm-git\lib\codegen\selectiondag\selectiondagbuilder.cpp,
line 958
0x000000013FA844B8 (0x0000000000DC1C20 0x0000000000D9E158 0x0000000000D9E0A8
0x0000000000BAE6F4), llvm::SelectionDAGISel::SelectBasicBlock() + 0x98
bytes(s),
d:\opensource\llvm\llvm-git\lib\codegen\selectiondag\selectiondagisel.cpp, line
513 + 0x1E byte(s)
0x000000013FA8433C (0x0000000000DC1C20 0x0000000000D9EB30 0x0000000000DB0F40
0x0000000000D9CFC0), llvm::SelectionDAGISel::SelectAllBasicBlocks() + 0xBEC
bytes(s),
d:\opensource\llvm\llvm-git\lib\codegen\selectiondag\selectiondagisel.cpp, line
1198
0x000000013FA7D018 (0x0000000000DC1C20 0x0000000000DEF840 0xCCCCCCCCCCCCCCCC
0xCCCCCCCCCCCCCCCC), llvm::SelectionDAGISel::runOnMachineFunction() + 0x3E8
bytes(s),
d:\opensource\llvm\llvm-git\lib\codegen\selectiondag\selectiondagisel.cpp, line
387
0x000000013FECA4E7 (0x0000000000DC1C20 0x0000000000D9EB30 0x0000000000D9EB30
0xCCCCCCCC00000004), llvm::MachineFunctionPass::runOnFunction() + 0x67
bytes(s), d:\opensource\llvm\llvm-git\lib\codegen\machinefunctionpass.cpp, line
34
0x000000014038A4FE (0x0000000000DA6CF0 0x0000000000D9EB30 0xCCCCCCCCCCCCCCCC
0xCCCCCCCCCCCCCCCC), llvm::FPPassManager::runOnFunction() + 0x1AE bytes(s),
d:\opensource\llvm\llvm-git\lib\ir\passmanager.cpp, line 1530 + 0x37 byte(s)
0x000000014038A714 (0x0000000000DA6CF0 0x0000000000D8E790 0x0000000000D8E790
0xCCCCCCCC00000005), llvm::FPPassManager::runOnModule() + 0x94 bytes(s),
d:\opensource\llvm\llvm-git\lib\ir\passmanager.cpp, line 1550 + 0x23 byte(s)
0x000000014038C121 (0x0000000000D9CDF0 0x0000000000D8E790 0xCCCCCCCCCCCCCCCC
0xCCCCCCCCCCCCCCCC), llvm::MPPassManager::runOnModule() + 0x311 bytes(s),
d:\opensource\llvm\llvm-git\lib\ir\passmanager.cpp, line 1608 + 0x40 byte(s)
0x000000014038C954 (0x0000000000DB0BF0 0x0000000000D8E790 0xCCCCCCCCCCCCCCCC
0xCCCCCCCCCCCCCCCC), llvm::PassManagerImpl::run() + 0x174 bytes(s),
d:\opensource\llvm\llvm-git\lib\ir\passmanager.cpp, line 1703 + 0x2A byte(s)
0x000000014038AC96 (0x0000000000BAF748 0x0000000000D8E790 0x0000000000BAF790
0x0000000000000000), llvm::PassManager::run() + 0x36 bytes(s),
d:\opensource\llvm\llvm-git\lib\ir\passmanager.cpp, line 1739
0x000000013F53629E (0x0000000000D78090 0x0000000000D84F80 0x0000000140B0BC30
0xCCCCCCCCCCCCCCCC), compileModule() + 0x17AE bytes(s),
d:\opensource\llvm\llvm-git\tools\llc\llc.cpp, line 378
0x000000013F536B4F (0x0000000100000002 0x0000000000D78090 0x0000000000000000
0x000000014065CFB6), main() + 0x11F bytes(s),
d:\opensource\llvm\llvm-git\tools\llc\llc.cpp, line 195 + 0x12 byte(s)
0x000000014065BD0D (0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000000000), __tmainCRTStartup() + 0x19D bytes(s),
f:\dd\vctools\crt_bld\self_64_amd64\crt\src\crtexe.c, line 536 + 0x19 byte(s)
0x000000014065BE3E (0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000000000), mainCRTStartup() + 0xE bytes(s),
f:\dd\vctools\crt_bld\self_64_amd64\crt\src\crtexe.c, line 377
0x00000000778D652D (0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000000000), BaseThreadInitThunk() + 0xD bytes(s)
0x0000000077B0C521 (0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000000000), RtlUserThreadStart() + 0x21 bytes(s)

if compiled with llc bug.ll on Windows 7 64bit.

The code was produced by LDC based on the following source:
// Loads exponent of a floating-point number.
real ldexpl(real arg, int exp)
{
    pragma(LDC_allow_inline);
    return __asm!(real)("fscale", "={st},{st(1)},{st},~{st(1)}", exp, arg);
}

Expected instruction sequence is something like this:

        fild exp;
        fld arg;
        fscale;
        fstp arg;

I assume that the fild instruction causes the problem.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130417/c25c4b5f/attachment.html>

From bugzilla-daemon at llvm.org  Wed Apr 17 13:02:53 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 17 Apr 2013 20:02:53 +0000
Subject: [LLVMbugs] [Bug 15465] Emscripten tracking bug
In-Reply-To: <bug-15465-206@http.llvm.org/bugs/>
References: <bug-15465-206@http.llvm.org/bugs/>
Message-ID: <bug-15465-206-evB3cUQMfU@http.llvm.org/bugs/>

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

Bug 15465 depends on bug 15000, which changed state.

Bug 15000 Summary: Dead Store Elimination takes a very long time (and has no effect)
http://llvm.org/bugs/show_bug.cgi?id=15000

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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130417/cd73d7f3/attachment.html>

From bugzilla-daemon at llvm.org  Wed Apr 17 13:02:52 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 17 Apr 2013 20:02:52 +0000
Subject: [LLVMbugs] [Bug 15000] Dead Store Elimination takes a very long
 time (and has no effect)
In-Reply-To: <bug-15000-206@http.llvm.org/bugs/>
References: <bug-15000-206@http.llvm.org/bugs/>
Message-ID: <bug-15000-206-yFn40p7mU9@http.llvm.org/bugs/>

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

Bill Wendling <wendling at apple.com> changed:

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

--- Comment #9 from Bill Wendling <wendling at apple.com> ---
I lowered the limit here:

Sending        lib/Analysis/MemoryDependenceAnalysis.cpp
Transmitting file data .
Committed revision 179713.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130417/ce885394/attachment.html>

From bugzilla-daemon at llvm.org  Wed Apr 17 14:05:17 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 17 Apr 2013 21:05:17 +0000
Subject: [LLVMbugs] [Bug 15760] clang fails to support some msvc inline
	assembler syntax
In-Reply-To: <bug-15760-206@http.llvm.org/bugs/>
References: <bug-15760-206@http.llvm.org/bugs/>
Message-ID: <bug-15760-206-2AIu76u824@http.llvm.org/bugs/>

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

Chad Rosier <chad.rosier at gmail.com> changed:

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

--- Comment #2 from Chad Rosier <chad.rosier at gmail.com> ---
This should be fixed with r179610, r179611, r179655, r179656, r179719 and
r179720.  Test case revisions added for completeness.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130417/95089c7b/attachment.html>

From bugzilla-daemon at llvm.org  Wed Apr 17 18:43:50 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 18 Apr 2013 01:43:50 +0000
Subject: [LLVMbugs] [Bug 13580] Problem in preprocessing pragma with block
	comments
In-Reply-To: <bug-13580-206@http.llvm.org/bugs/>
References: <bug-13580-206@http.llvm.org/bugs/>
Message-ID: <bug-13580-206-GzvLg7KfK0@http.llvm.org/bugs/>

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

Argyrios Kyrtzidis <akyrtzi at gmail.com> changed:

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

--- Comment #2 from Argyrios Kyrtzidis <akyrtzi at gmail.com> ---
Fixed in r179743.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130418/69134ebb/attachment.html>

From bugzilla-daemon at llvm.org  Wed Apr 17 18:55:08 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 18 Apr 2013 01:55:08 +0000
Subject: [LLVMbugs] [Bug 14332] Implement -fsplit-stack
In-Reply-To: <bug-14332-206@http.llvm.org/bugs/>
References: <bug-14332-206@http.llvm.org/bugs/>
Message-ID: <bug-14332-206-paPnfDratx@http.llvm.org/bugs/>

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

David Blaikie <dblaikie at gmail.com> changed:

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

--- Comment #6 from David Blaikie <dblaikie at gmail.com> ---
Seems this does get the GDB test suite passed the initial problem of not
supporting the flag at all, but it doesn't actually pass the test. The test was
hiding behind a "is GCC" check which I've modified to include Clang now.

XFailed the test in r179744

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130418/ab010d6e/attachment.html>

From bugzilla-daemon at llvm.org  Wed Apr 17 18:55:09 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 18 Apr 2013 01:55:09 +0000
Subject: [LLVMbugs] [Bug 14330] Clang does not pass the GDB 7.5 test suite
In-Reply-To: <bug-14330-206@http.llvm.org/bugs/>
References: <bug-14330-206@http.llvm.org/bugs/>
Message-ID: <bug-14330-206-wb2ro4OGC6@http.llvm.org/bugs/>

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

Bug 14330 depends on bug 14332, which changed state.

Bug 14332 Summary: Implement -fsplit-stack
http://llvm.org/bugs/show_bug.cgi?id=14332

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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130418/2391b8d5/attachment.html>

From bugzilla-daemon at llvm.org  Wed Apr 17 21:10:12 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 18 Apr 2013 04:10:12 +0000
Subject: [LLVMbugs] [Bug 15774] New: BoolAssignmentChecker not catching
	literals
Message-ID: <bug-15774-206@http.llvm.org/bugs/>

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

            Bug ID: 15774
           Summary: BoolAssignmentChecker not catching literals
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: Static Analyzer
          Assignee: kremenek at apple.com
          Reporter: adamschn at umich.edu
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

I'm not sure if this is by design, but it doesn't seem like the bool assignment
checker is reporting a bug for the use of integer literals. For example, cases
like this don't produce warnings:

void test_cppbool_initialization() {
  bool x = 2;  // expected warning
  x = 3; // expected-warning
}

I thought that the current structure with getting as a DefinedSVal would catch
literal assignment, but that doesn't seem to be the case.

If someone could point me in the right direction, I would be interested in
fixing/extending this behavior.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130418/6dc0aced/attachment.html>

From bugzilla-daemon at llvm.org  Wed Apr 17 21:35:05 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 18 Apr 2013 04:35:05 +0000
Subject: [LLVMbugs] [Bug 15775] New: Allow increment to extended vector types
Message-ID: <bug-15775-206@http.llvm.org/bugs/>

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

            Bug ID: 15775
           Summary: Allow increment to extended vector types
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
          Assignee: unassignedclangbugs at nondot.org
          Reporter: john at multicorewareinc.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 10365
  --> http://llvm.org/bugs/attachment.cgi?id=10365&action=edit
Increment of extended vector type

>From the OpenCL 1.1 Specification, 6.3.c, "The arithmetic post- and
pre-increment and decrement operators (-- and ++) operate on built-in scalar
and vector types except the built-in scalar and vector float types.  All unary
operators work component-wise on their operands."  

The attached OpenCL kernel program relying on this behavior fails semantic
checking with the error:
test.cl:5:7: error: cannot increment value of type 'int4'

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130418/27d9c301/attachment.html>

From bugzilla-daemon at llvm.org  Thu Apr 18 01:27:24 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 18 Apr 2013 08:27:24 +0000
Subject: [LLVMbugs] [Bug 15776] New: clang frontend command failed due to
	signal
Message-ID: <bug-15776-206@http.llvm.org/bugs/>

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

            Bug ID: 15776
           Summary: clang frontend command failed due to signal
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: canri62 at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

I tried to build clang with './configure --enable-optimized', but get error:

  COMPILE:   clang_linux/full-i386/i386:
/apsara/huian/llvm_proposal/llvm/projects/compiler-rt/lib/gcc_personality_v0.c
clang: /apsara/huian/llvm_proposal/llvm/include/llvm/ADT/IntervalMap.h:626:
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 =
unsign
ed int, unsigned int N = 9u, Traits = llvm::IntervalMapInfo<llvm::SlotIndex>]:
Assertion `!Traits::stopLess(b, a) && "Invalid interval"' failed.
0  clang           0x000000000298aa72 llvm::sys::PrintStackTrace(_IO_FILE*) +
34
1  clang           0x000000000298b7d7
2  libpthread.so.0 0x000000385a60e7c0
3  libc.so.6       0x0000003859e30265 gsignal + 53
4  libc.so.6       0x0000003859e31d10 abort + 272
5  libc.so.6       0x0000003859e296e6 __assert_fail + 246
6  clang           0x000000000235fdd3
llvm::IntervalMapImpl::LeafNode<llvm::SlotIndex, unsigned int, 9u,
llvm::IntervalMapInfo<llvm::SlotIndex> >::insertFrom(
unsigned int&, unsigned int, llvm::SlotIndex, llvm::SlotIndex, unsigned int) +
739
7  clang           0x0000000002361cec
8  clang           0x0000000002356b4a
llvm::SplitEditor::useIntv(llvm::SlotIndex, llvm::SlotIndex) + 90
9  clang           0x0000000002357816
llvm::SplitEditor::splitRegInBlock(llvm::SplitAnalysis::BlockInfo const&,
unsigned int, llvm::SlotIndex) + 1350
10 clang           0x00000000022fd3ec
11 clang           0x0000000002301b13
12 clang           0x000000000230695d
13 clang           0x0000000002306e7d
14 clang           0x0000000002434666 llvm::RegAllocBase::allocatePhysRegs() +
278
15 clang           0x0000000002300b1f
16 clang           0x0000000002287fd5
llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 53
17 clang           0x000000000290bd15
llvm::FPPassManager::runOnFunction(llvm::Function&) + 677
18 clang           0x000000000290bdab
llvm::FPPassManager::runOnModule(llvm::Module&) + 43
19 clang           0x000000000290b93f
llvm::MPPassManager::runOnModule(llvm::Module&) + 751
20 clang           0x000000000290d592 llvm::PassManagerImpl::run(llvm::Module&)
+ 290
21 clang           0x000000000290d6ad llvm::PassManager::run(llvm::Module&) +
13
22 clang           0x000000000091d1b9
clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::CodeGenOptions
const&, clang::TargetOptions const&, clang::La
ngOptions const&, llvm::Module*, clang::BackendAction, llvm::raw_ostream*) +
1897
23 clang           0x0000000000919e83
24 clang           0x0000000000b2b067 clang::ParseAST(clang::Sema&, bool, bool)
+ 391
25 clang           0x0000000000917c9c clang::CodeGenAction::ExecuteAction() +
60
26 clang           0x00000000006fdd29 clang::FrontendAction::Execute() + 297
27 clang           0x00000000006d4f6e
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 350
28 clang           0x00000000006ac31c
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 892
28 clang           0x00000000006ac31c
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 892
29 clang           0x00000000006a2bf4 cc1_main(char const**, char const**, char
const*, void*) + 1268
30 clang           0x00000000006aa2f5 main + 5637
31 libc.so.6       0x0000003859e1d994 __libc_start_main + 244
32 clang           0x00000000006a1899
Stack dump:
0.      Program arguments:
/apsara/huian/llvm_proposal/llvm_build/Release+Asserts/bin/clang -cc1 -triple
i386-unknown-linux-gnu -emit-obj -disable-free -main-file-name
gcc_personality_v0.c -mrelocation-model pic -pic-level 2 -fmath-errno
-masm-verbose -mconstructor-aliases -target-cpu pentium4 -target-linker-version
2.17.50.0.6 -momit-leaf-frame-pointer -coverage-file
/apsara/huian/llvm_proposal/llvm_build/tools/clang/runtime/compiler-rt/clang_linux/full-i386/i386/SubDir.lib/gcc_personality_v0.o
-resource-dir
/apsara/huian/llvm_proposal/llvm_build/Release+Asserts/bin/../lib/clang/3.3
-isysroot /apsara/huian/llvm_proposal/llvm/projects/compiler-rt/SDKs/linux
-internal-isystem
/apsara/huian/llvm_proposal/llvm/projects/compiler-rt/SDKs/linux/usr/local/include
-internal-isystem
/apsara/huian/llvm_proposal/llvm_build/Release+Asserts/bin/../lib/clang/3.3/include
-internal-externc-isystem
/apsara/huian/llvm_proposal/llvm/projects/compiler-rt/SDKs/linux/include
-internal-externc-isystem
/apsara/huian/llvm_proposal/llvm/projects/compiler-rt/SDKs/linux/usr/include
-O3 -Wall -Werror -fdebug-compilation-dir
/apsara/huian/llvm_proposal/llvm_build/tools/clang/runtime/compiler-rt
-ferror-limit 19 -fmessage-length 158 -mstackrealign -fobjc-runtime=gcc
-fobjc-default-synthesize-properties -fdiagnostics-show-option
-fcolor-diagnostics -backend-option -vectorize-loops -o
/apsara/huian/llvm_proposal/llvm_build/tools/clang/runtime/compiler-rt/clang_linux/full-i386/i386/SubDir.lib/gcc_personality_v0.o
-x c
/apsara/huian/llvm_proposal/llvm/projects/compiler-rt/lib/gcc_personality_v0.c
1.      <eof> parser at end of file
2.      Code generation
3.      Running pass 'Function Pass Manager' on module
'/apsara/huian/llvm_proposal/llvm/projects/compiler-rt/lib/gcc_personality_v0.c'.
4.      Running pass 'Greedy Register Allocator' on function
'@readEncodedPointer'
clang: error: unable to execute command: Aborted
clang: error: clang frontend command failed due to signal (use -v to see
invocation)
clang version 3.3 (trunk 179747)
Target: i386-unknown-linux-gnu
Thread model: posix
clang: note: diagnostic msg: PLEASE submit a bug report to
http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and
associated run script.
clang: note: diagnostic msg:

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130418/93356bb4/attachment.html>

From bugzilla-daemon at llvm.org  Thu Apr 18 02:05:51 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 18 Apr 2013 09:05:51 +0000
Subject: [LLVMbugs] [Bug 15777] New: SROA::performScalarRepl comment claims
 to work on all alloca's in function, but it only add ones in the entry block
Message-ID: <bug-15777-206@http.llvm.org/bugs/>

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

            Bug ID: 15777
           Summary: SROA::performScalarRepl comment claims to work on all
                    alloca's in function, but it only add ones in the
                    entry block
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Scalar Optimizations
          Assignee: unassignedbugs at nondot.org
          Reporter: sschiffli at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Here is the code snippet that I am confused about:
...
// performScalarRepl - This algorithm is a simple worklist driven algorithm,
// which runs on all of the alloca instructions in the function, removing them
// if they are only used by getelementptr instructions.
//
bool SROA::performScalarRepl(Function &F) {
  std::vector<AllocaInst*> WorkList;

  // Scan the entry basic block, adding allocas to the worklist.
  BasicBlock &BB = F.getEntryBlock();
  for (BasicBlock::iterator I = BB.begin(), E = BB.end(); I != E; ++I)
    if (AllocaInst *A = dyn_cast<AllocaInst>(I))
      WorkList.push_back(A);
...

Is it a code bug in that we are supposed to add all alloca's in the function to
the worklist?  Or is this a comment bug, or something else that I am missing.

Would there be any reason to only allow alloca's in the entry block to be
optimized?  I played around with adding all, and it fixed the optimization bug
I was seeing.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130418/01444da0/attachment.html>

From bugzilla-daemon at llvm.org  Thu Apr 18 02:58:22 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 18 Apr 2013 09:58:22 +0000
Subject: [LLVMbugs] [Bug 15778] New: Initialization inner vector
Message-ID: <bug-15778-206@http.llvm.org/bugs/>

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

            Bug ID: 15778
           Summary: Initialization inner vector
           Product: libc++
           Version: unspecified
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: All Bugs
          Assignee: hhinnant at apple.com
          Reporter: vladimir91.bondar at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

It doesn't work
vector<vector<bool> > vec(10, vector<bool>(10));
after that all inner vectors have a zero size.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130418/6dd256fe/attachment.html>

From bugzilla-daemon at llvm.org  Thu Apr 18 03:52:30 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 18 Apr 2013 10:52:30 +0000
Subject: [LLVMbugs] [Bug 13686] -Wdocumentation warns about @return of
 struct not yet declared
In-Reply-To: <bug-13686-206@http.llvm.org/bugs/>
References: <bug-13686-206@http.llvm.org/bugs/>
Message-ID: <bug-13686-206-D1mxVGoTPY@http.llvm.org/bugs/>

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

Dmitri Gribenko <gribozavr at gmail.com> changed:

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

--- Comment #2 from Dmitri Gribenko <gribozavr at gmail.com> ---
Fariborz Jahanian fixed this issue in r179722.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130418/507f078e/attachment.html>

From bugzilla-daemon at llvm.org  Thu Apr 18 06:23:53 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 18 Apr 2013 13:23:53 +0000
Subject: [LLVMbugs] [Bug 15759] Invalid constraint in inline asm crashes
In-Reply-To: <bug-15759-206@http.llvm.org/bugs/>
References: <bug-15759-206@http.llvm.org/bugs/>
Message-ID: <bug-15759-206-U3axjnK7ZP@http.llvm.org/bugs/>

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
                 CC|                            |benny.kra at gmail.com
         Resolution|---                         |FIXED

--- Comment #4 from Benjamin Kramer <benny.kra at gmail.com> ---
clang properly rejects this test case with r179756.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130418/0fd34b7c/attachment.html>

From bugzilla-daemon at llvm.org  Thu Apr 18 06:27:35 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 18 Apr 2013 13:27:35 +0000
Subject: [LLVMbugs] [Bug 15778] Initialization inner vector
In-Reply-To: <bug-15778-206@http.llvm.org/bugs/>
References: <bug-15778-206@http.llvm.org/bugs/>
Message-ID: <bug-15778-206-PUPEtGTRvu@http.llvm.org/bugs/>

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

Howard Hinnant <hhinnant at apple.com> changed:

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

--- Comment #4 from Howard Hinnant <hhinnant at apple.com> ---
No problem.  I imagine that the Xcode displayer is not aware that vector<bool>
is specialized to pack bools into bits.  That is required by the standard and
has been surprising people for 15 years now...

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130418/9a783d10/attachment.html>

From bugzilla-daemon at llvm.org  Thu Apr 18 07:26:30 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 18 Apr 2013 14:26:30 +0000
Subject: [LLVMbugs] [Bug 15779] New: jnz mnemonic not supported in ms-inline
	asm
Message-ID: <bug-15779-206@http.llvm.org/bugs/>

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

            Bug ID: 15779
           Summary: jnz mnemonic not supported in ms-inline asm
           Product: clang
           Version: unspecified
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
          Assignee: unassignedclangbugs at nondot.org
          Reporter: jmuizelaar at mozilla.com
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified

void f()
{
Loop0:
    __asm {
         jnz Loop0
    }

}

gives:
<inline asm>:2:2: error: invalid instruction mnemonic 'jnz'

This also comes from jxrlib

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130418/dd9e537c/attachment.html>

From bugzilla-daemon at llvm.org  Thu Apr 18 07:29:26 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 18 Apr 2013 14:29:26 +0000
Subject: [LLVMbugs] [Bug 15748] clang hangs at -O3 on loop
In-Reply-To: <bug-15748-206@http.llvm.org/bugs/>
References: <bug-15748-206@http.llvm.org/bugs/>
Message-ID: <bug-15748-206-re4cZuWH9R@http.llvm.org/bugs/>

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

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> ---
Fixed in r179757.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130418/2fdb9218/attachment.html>

From bugzilla-daemon at llvm.org  Thu Apr 18 07:45:24 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 18 Apr 2013 14:45:24 +0000
Subject: [LLVMbugs] [Bug 15780] New: Extended vector literals cannot include
 smaller extended vectors outside OpenCL context
Message-ID: <bug-15780-206@http.llvm.org/bugs/>

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

            Bug ID: 15780
           Summary: Extended vector literals cannot include smaller
                    extended vectors outside OpenCL context
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
          Assignee: unassignedclangbugs at nondot.org
          Reporter: john at multicorewareinc.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 10369
  --> http://llvm.org/bugs/attachment.cgi?id=10369&action=edit
.c file initializing an int4 from two int2s.

Unless the language mode is set to OpenCL, a vector initializer fusing multiple
smaller vectors into a larger vector is disallowed for extended vectors. 
Simple test case is attached, and fails with error:

"test.c:6:15: error: initializing 'int4' with an expression of incompatible
type"

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130418/184b86b2/attachment.html>

From bugzilla-daemon at llvm.org  Thu Apr 18 09:22:33 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 18 Apr 2013 16:22:33 +0000
Subject: [LLVMbugs] [Bug 15781] New: Conditional operators on extended
 vectors fail for vector/scalar selections outside OpenCL
Message-ID: <bug-15781-206@http.llvm.org/bugs/>

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

            Bug ID: 15781
           Summary: Conditional operators on extended vectors fail for
                    vector/scalar selections outside OpenCL
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: john at multicorewareinc.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130418/9540671d/attachment.html>

From bugzilla-daemon at llvm.org  Thu Apr 18 09:44:56 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 18 Apr 2013 16:44:56 +0000
Subject: [LLVMbugs] [Bug 15674] Broken switch when compiling with
	optimizations
In-Reply-To: <bug-15674-206@http.llvm.org/bugs/>
References: <bug-15674-206@http.llvm.org/bugs/>
Message-ID: <bug-15674-206-iRnJ83lpYK@http.llvm.org/bugs/>

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

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

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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130418/b96087f7/attachment.html>

From bugzilla-daemon at llvm.org  Thu Apr 18 10:43:20 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 18 Apr 2013 17:43:20 +0000
Subject: [LLVMbugs] [Bug 15777] SROA::performScalarRepl comment claims to
 work on all alloca's in function, but it only add ones in the entry block
In-Reply-To: <bug-15777-206@http.llvm.org/bugs/>
References: <bug-15777-206@http.llvm.org/bugs/>
Message-ID: <bug-15777-206-v3ctYkoOg0@http.llvm.org/bugs/>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #1 from Chris Lattner <clattner at apple.com> ---
The comment is wrong.  Promoting allocas in the entryblock is the right thing:

The comment is fixed in r179775

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130418/2756a886/attachment.html>

From bugzilla-daemon at llvm.org  Thu Apr 18 10:45:41 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 18 Apr 2013 17:45:41 +0000
Subject: [LLVMbugs] [Bug 15782] New: optimize bitwise operations across bswap
Message-ID: <bug-15782-206@http.llvm.org/bugs/>

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

            Bug ID: 15782
           Summary: optimize bitwise operations across bswap
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Scalar Optimizations
          Assignee: unassignedbugs at nondot.org
          Reporter: b.r.longbons at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Currently (using debian package of 3.3~svn177638), code like the following
cannot be optimized:

uint32_t frob(uint32_t a, uint32_t b)
{
    return __builtin_bswap32(__builtin_bswap32(a) | __builtin_bswap32(b));
}

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130418/b22563dd/attachment.html>

From bugzilla-daemon at llvm.org  Thu Apr 18 10:47:51 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 18 Apr 2013 17:47:51 +0000
Subject: [LLVMbugs] [Bug 15783] New: Improve diagnostic when a destructor is
 implicitly deleted due to private operator delete
Message-ID: <bug-15783-206@http.llvm.org/bugs/>

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

            Bug ID: 15783
           Summary: Improve diagnostic when a destructor is implicitly
                    deleted due to private operator delete
           Product: clang
           Version: unspecified
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++11
          Assignee: unassignedclangbugs at nondot.org
          Reporter: nicolasweber at gmx.de
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified

template <typename Type> class IsInstrumented {
  class yes { char m; };
  class no { yes m[2]; };
  struct BaseMixin {
    void reportMemoryUsage() const {}
  };
  struct Base : public Type, public BaseMixin {
  };
  template <typename T, T t> class Helper {
  };
  template <typename U>
  static no
  deduce(U *, Helper<void(BaseMixin::*)() const, &U::reportMemoryUsage> * = 0);
  static yes deduce(...);
public:
  static const bool result = sizeof(yes) == sizeof(deduce((Base *)(0)));
};

template <typename T> bool hasReportMemoryUsage(const T *object) {
  return IsInstrumented<T>::result;
}

class Timer {
  void operator delete(void *p) {}
public:
  virtual ~Timer();
};
bool f() {
  Timer m_cacheTimer;
  return hasReportMemoryUsage(&m_cacheTimer);
}


The error message from r178563 looks like this:

$ third_party/llvm-build/Release+Asserts/bin/clang -c repro.ii -std=gnu++11
repro.ii:7:10: error: deleted function '~Base' cannot override a non-deleted
function
  struct Base : public Type, public BaseMixin {
         ^
repro.ii:13:51: note: in instantiation of member class
'IsInstrumented<Timer>::Base' requested here
  deduce(U *, Helper<void(BaseMixin::*)() const, &U::reportMemoryUsage> * = 0);
                                                  ^
repro.ii:13:3: note: while substituting deduced template arguments into
function template 'deduce' [with U = IsInstrumented<Timer>::Base]
  deduce(U *, Helper<void(BaseMixin::*)() const, &U::reportMemoryUsage> * = 0);
  ^
repro.ii:20:10: note: in instantiation of template class
'IsInstrumented<Timer>' requested here
  return IsInstrumented<T>::result;
         ^
repro.ii:30:10: note: in instantiation of function template specialization
'hasReportMemoryUsage<Timer>' requested here
  return hasReportMemoryUsage(&m_cacheTimer);
         ^
repro.ii:26:11: note: overridden virtual function is here
  virtual ~Timer();
          ^
1 error generated.


Says Richard: """Yes, the diagnostic seems to be correct, if unhelpful. Feel
free to file a bug on the diagnostic (if not, I'll try to remember to fix this
but can't promise!). We should be pointing out that the function is implicitly
deleted because it would otherwise try to call an inaccessible class-specific
'operator delete'."""

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130418/5c42e960/attachment.html>

From bugzilla-daemon at llvm.org  Thu Apr 18 11:08:26 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 18 Apr 2013 18:08:26 +0000
Subject: [LLVMbugs] [Bug 15785] New: OpenCL errors using vector/scalar
 conditionals and short integer types
Message-ID: <bug-15785-206@http.llvm.org/bugs/>

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

            Bug ID: 15785
           Summary: OpenCL errors using vector/scalar conditionals and
                    short integer types
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: john at multicorewareinc.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 10371
  --> http://llvm.org/bugs/attachment.cgi?id=10371&action=edit
.cl test file using short integer vector/scalar selection

Using an extended vector conditional on short integer types fails when one of
the operands is a scalar, because it performs usual unary casts before checking
compatibility between the scalar and vector types, causing type
incompatibilities incongruent with the OpenCL 1.1 Specification 6.3.i.

Quick test case attached, which gives the following errors:


test_conditional.cl:10:22: error: can't convert between vector values of
different
      size ('int' and 'short4')
  avec = conditional ? default_val : avec;
                     ^ ~~~~~~~~~~~   ~~~~
test_conditional.cl:12:22: error: can't convert between vector values of
different
      size ('short4' and 'int')
  avec = conditional ? avec : default_val;
                     ^ ~~~~   ~~~~~~~~~~~

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130418/508bbcd2/attachment.html>

From bugzilla-daemon at llvm.org  Thu Apr 18 12:21:46 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 18 Apr 2013 19:21:46 +0000
Subject: [LLVMbugs] [Bug 15786] New: Frontend crash,
	assertion in Attributes.cpp
Message-ID: <bug-15786-206@http.llvm.org/bugs/>

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

            Bug ID: 15786
           Summary: Frontend crash, assertion in Attributes.cpp
           Product: clang
           Version: 3.2
          Hardware: Macintosh
                OS: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
          Assignee: unassignedclangbugs at nondot.org
          Reporter: bhiggins at arbor.net
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

eng-6-20:cpp_primes bhiggins$ clang++ ./main.cc -o main
Assertion failed: (Attrs[i].Attrs.hasAttributes() && "Pointless attribute!"),
function get, file Attributes.cpp, line 367.
0  clang             0x000000010564ba82 _ZL15PrintStackTracePv + 34
1  clang             0x000000010564c069 _ZL13SignalHandleri + 745
2  libsystem_c.dylib 0x00007fff91c6bcfa _sigtramp + 26
3  libsystem_c.dylib 0xfa90516000000001 _sigtramp + 18054879643247919905
4  clang             0x000000010564bcd6 abort + 22
5  clang             0x000000010564bc98 __assert_rtn + 56
6  clang             0x000000010553c5c6
llvm::AttrListPtr::get(llvm::LLVMContext&,
llvm::ArrayRef<llvm::AttributeWithIndex>) + 566
7  clang             0x000000010404ffca
clang::CodeGen::CodeGenModule::SetLLVMFunctionAttributes(clang::Decl const*,
clang::CodeGen::CGFunctionInfo const&, llvm::Function*) + 122
8  clang             0x00000001040506e9
clang::CodeGen::CodeGenModule::SetFunctionAttributes(clang::GlobalDecl,
llvm::Function*, bool) + 153
9  clang             0x0000000104052017
clang::CodeGen::CodeGenModule::GetOrCreateLLVMFunction(llvm::StringRef,
llvm::Type*, clang::GlobalDecl, bool, llvm::Attributes) + 343
10 clang             0x000000010405431b
clang::CodeGen::CodeGenModule::GetAddrOfFunction(clang::GlobalDecl,
llvm::Type*, bool) + 123
11 clang             0x0000000103fc33c0
clang::CodeGen::CodeGenFunction::EmitCXXMemberCallExpr(clang::CXXMemberCallExpr
const*, clang::CodeGen::ReturnValueSlot) + 2480
12 clang             0x0000000103fb5cc0
clang::CodeGen::CodeGenFunction::EmitCallExpr(clang::CallExpr const*,
clang::CodeGen::ReturnValueSlot) + 224
13 clang             0x0000000103fe93ab (anonymous
namespace)::ScalarExprEmitter::VisitCallExpr(clang::CallExpr const*) + 203
14 clang             0x0000000103fe2943 clang::StmtVisitorBase<clang::make_ptr,
(anonymous namespace)::ScalarExprEmitter, llvm::Value*>::Visit(clang::Stmt*) +
14787
15 clang             0x0000000103fd95cf
clang::CodeGen::CodeGenFunction::EmitScalarExpr(clang::Expr const*, bool) + 95
16 clang             0x0000000103fa79c5
clang::CodeGen::CodeGenFunction::EvaluateExprAsBool(clang::Expr const*) + 293
17 clang             0x000000010404b504
clang::CodeGen::CodeGenFunction::EmitBranchOnBoolExpr(clang::Expr const*,
llvm::BasicBlock*, llvm::BasicBlock*) + 2020
18 clang             0x000000010404b34a
clang::CodeGen::CodeGenFunction::EmitBranchOnBoolExpr(clang::Expr const*,
llvm::BasicBlock*, llvm::BasicBlock*) + 1578
19 clang             0x0000000104038de8
clang::CodeGen::CodeGenFunction::EmitIfStmt(clang::IfStmt const&) + 360
20 clang             0x0000000104038683
clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*) + 451
21 clang             0x000000010403d6cc
clang::CodeGen::CodeGenFunction::EmitCompoundStmt(clang::CompoundStmt const&,
bool, clang::CodeGen::AggValueSlot) + 236
22 clang             0x0000000104038aad
clang::CodeGen::CodeGenFunction::EmitSimpleStmt(clang::Stmt const*) + 125
23 clang             0x00000001040384e9
clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*) + 41
24 clang             0x00000001040394f5
clang::CodeGen::CodeGenFunction::EmitWhileStmt(clang::WhileStmt const&) + 1301
25 clang             0x0000000104038693
clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*) + 467
26 clang             0x000000010403d6cc
clang::CodeGen::CodeGenFunction::EmitCompoundStmt(clang::CompoundStmt const&,
bool, clang::CodeGen::AggValueSlot) + 236
27 clang             0x0000000104038aad
clang::CodeGen::CodeGenFunction::EmitSimpleStmt(clang::Stmt const*) + 125
28 clang             0x00000001040384e9
clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*) + 41
29 clang             0x000000010404a53e
clang::CodeGen::CodeGenFunction::GenerateCode(clang::GlobalDecl,
llvm::Function*, clang::CodeGen::CGFunctionInfo const&) + 750
30 clang             0x00000001040538bb
clang::CodeGen::CodeGenModule::EmitGlobalFunctionDefinition(clang::GlobalDecl)
+ 2107
31 clang             0x00000001040509d8
clang::CodeGen::CodeGenModule::EmitGlobalDefinition(clang::GlobalDecl) + 344
32 clang             0x00000001040529b1
clang::CodeGen::CodeGenModule::EmitGlobal(clang::GlobalDecl) + 689
33 clang             0x0000000104058248
clang::CodeGen::CodeGenModule::EmitTopLevelDecl(clang::Decl*) + 296
34 clang             0x00000001040775cf (anonymous
namespace)::CodeGeneratorImpl::HandleTopLevelDecl(clang::DeclGroupRef) + 127
35 clang             0x000000010404736a
clang::BackendConsumer::HandleTopLevelDecl(clang::DeclGroupRef) + 170
36 clang             0x0000000104085582 clang::ParseAST(clang::Sema&, bool,
bool) + 322
37 clang             0x00000001040466f2 clang::CodeGenAction::ExecuteAction() +
1314
38 clang             0x0000000103e1361b clang::FrontendAction::Execute() + 107
39 clang             0x0000000103df4ddf
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 1007
40 clang             0x0000000103db6a9d
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 3533
41 clang             0x0000000103dae291 cc1_main(char const**, char const**,
char const*, void*) + 849
42 clang             0x0000000103db27c3 main + 739
43 clang             0x0000000103dadf34 start + 52
Stack dump:
0.    Program arguments:
/Users/bhiggins/Work/llvm-3.2.src/Release+Asserts/bin/clang -cc1 -triple
x86_64-apple-macosx10.7.0 -emit-obj -mrelax-all -disable-free -main-file-name
main.cc -mrelocation-model pic -pic-level 2 -mdisable-fp-elim -masm-verbose
-munwind-tables -target-cpu core2 -target-linker-version 123.2.1 -resource-dir
/Users/bhiggins/Work/llvm-3.2.src/Release+Asserts/bin/../lib/clang/3.2
-fmodule-cache-path
/var/folders/49/0mf81n_j1zb3swgkn_95by4c0000gn/T/clang-module-cache
-fdeprecated-macro -fdebug-compilation-dir /Users/bhiggins/Work/cpp_primes
-ferror-limit 19 -fmessage-length 224 -stack-protector 1 -mstackrealign
-fblocks -fobjc-runtime=macosx-10.7.0 -fobjc-dispatch-method=mixed
-fobjc-default-synthesize-properties -fencode-extended-block-signature
-fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o
/var/folders/49/0mf81n_j1zb3swgkn_95by4c0000gn/T/main-JzTZ7K.o -x c++ ./main.cc 
1.    <eof> parser at end of file
2.    ./main.cc:33:5: LLVM IR generation of declaration 'main'
3.    ./main.cc:33:5: Generating code for declaration 'main'
4.    ./main.cc:34:1: LLVM IR generation of compound statement ('{}')
5.    ./main.cc:37:39: 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 version 3.2 (tags/RELEASE_32/final)
Target: x86_64-apple-darwin11.4.2
Thread model: posix
clang: note: diagnostic msg: PLEASE submit a bug report to
http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and
associated run script.
clang: note: diagnostic msg: 
********************

PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang: note: diagnostic msg:
/var/folders/49/0mf81n_j1zb3swgkn_95by4c0000gn/T/main-DTFNhz.cpp
clang: note: diagnostic msg:
/var/folders/49/0mf81n_j1zb3swgkn_95by4c0000gn/T/main-DTFNhz.sh
clang: note: diagnostic msg: 

********************

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130418/3fce339a/attachment.html>

From bugzilla-daemon at llvm.org  Thu Apr 18 14:05:35 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 18 Apr 2013 21:05:35 +0000
Subject: [LLVMbugs] [Bug 12781] -Wuninitialized does not understand
 conditional operators
In-Reply-To: <bug-12781-206@http.llvm.org/bugs/>
References: <bug-12781-206@http.llvm.org/bugs/>
Message-ID: <bug-12781-206-t78O7HQR3t@http.llvm.org/bugs/>

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

rtrieu at google.com changed:

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

--- Comment #1 from rtrieu at google.com ---
Testing again, -Wuninitialized now fires on all three test cases.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130418/211011a9/attachment.html>

From bugzilla-daemon at llvm.org  Thu Apr 18 15:41:40 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 18 Apr 2013 22:41:40 +0000
Subject: [LLVMbugs] [Bug 15787] New: Assert in
 llvm::MachineRegisterInfo::clearVirtRegs: Vreg use list non-empty still
Message-ID: <bug-15787-206@http.llvm.org/bugs/>

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

            Bug ID: 15787
           Summary: Assert in llvm::MachineRegisterInfo::clearVirtRegs:
                    Vreg use list non-empty still
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Common Code Generator Code
          Assignee: unassignedbugs at nondot.org
          Reporter: hfinkel at anl.gov
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 10373
  --> http://llvm.org/bugs/attachment.cgi?id=10373&action=edit
bugpoint reduced test case

I may have found a bug in the register allocator. To see the bug, first apply
the attached patch (which makes the PPC optimizeCompareInst function more
aggressive than it should be), and then run the attached test case using:
-mtriple=powerpc64-unknown-linux-gnu -mcpu=pwr7 -- While applying the patch
will make optimizeCompareInst make a transformation that it can't guarantee is
legal, I don't think that the register allocator should care about that.

It currently asserts like this:
llc: llvm-trunk/lib/CodeGen/MachineRegisterInfo.cpp:111: void
llvm::MachineRegisterInfo::clearVirtRegs(): Assertion
`VRegInfo[TargetRegisterInfo::index2VirtReg(i)].second == 0 && "Vreg use list
non-empty still?"' failed.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130418/a55631f2/attachment.html>

From bugzilla-daemon at llvm.org  Thu Apr 18 18:50:10 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 19 Apr 2013 01:50:10 +0000
Subject: [LLVMbugs] [Bug 14824] Optimization arm_ldst_opt inserts newly
 generated instruction vldmia at incorrect position
In-Reply-To: <bug-14824-206@http.llvm.org/bugs/>
References: <bug-14824-206@http.llvm.org/bugs/>
Message-ID: <bug-14824-206-JcTvybAsdk@http.llvm.org/bugs/>

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

Hao Liu <hao.liu8822 at gmail.com> changed:

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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130419/21df1c87/attachment.html>

From bugzilla-daemon at llvm.org  Thu Apr 18 18:50:42 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 19 Apr 2013 01:50:42 +0000
Subject: [LLVMbugs] [Bug 15318] AsmPrinter crashes with assertion
In-Reply-To: <bug-15318-206@http.llvm.org/bugs/>
References: <bug-15318-206@http.llvm.org/bugs/>
Message-ID: <bug-15318-206-g2WNjtgAik@http.llvm.org/bugs/>

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

Hao Liu <hao.liu8822 at gmail.com> changed:

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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130419/74259e53/attachment.html>

From bugzilla-daemon at llvm.org  Thu Apr 18 18:57:49 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 19 Apr 2013 01:57:49 +0000
Subject: [LLVMbugs] [Bug 15788] New: problem with function section attribute
Message-ID: <bug-15788-206@http.llvm.org/bugs/>

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

            Bug ID: 15788
           Summary: problem with function section attribute
           Product: tools
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: llc
          Assignee: unassignedbugs at nondot.org
          Reporter: rkotler at mips.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Consider the following code:

void x(int i) __attribute((section(".mySection,\"aw\", at progbits#")));

void x(int i) {
}


If you compile this with gcc you get:

    .file    "sectbug.c"
    .section    .mySection,"aw", at progbits#,"ax", at progbits
.globl x


 With Clang you get

    .file    "sectbug.c"
    .section    ".mySection,\"aw\", at progbits#","ax", at progbits
    .globl    x


It needs to unquote the string.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130419/5acc643f/attachment.html>

From bugzilla-daemon at llvm.org  Fri Apr 19 02:28:27 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 19 Apr 2013 09:28:27 +0000
Subject: [LLVMbugs] [Bug 15789] New: Assertion failed: (E->isRValue() &&
 E->getType()->isIntegralOrEnumerationType()),
 function EvaluateIntegerOrLValue, file ExprConstant.cpp, line 4068.
Message-ID: <bug-15789-206@http.llvm.org/bugs/>

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

            Bug ID: 15789
           Summary: Assertion failed: (E->isRValue() &&
                    E->getType()->isIntegralOrEnumerationType()), function
                    EvaluateIntegerOrLValue, file ExprConstant.cpp, line
                    4068.
           Product: clang
           Version: 3.2
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: cohara87 at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 10377
  --> http://llvm.org/bugs/attachment.cgi?id=10377&action=edit
crash-Ilzh2e.c

Assertion failed: (E->isRValue() &&
E->getType()->isIntegralOrEnumerationType()), function EvaluateIntegerOrLValue,
file ExprConstant.cpp, line 4068.
0  clang             0x000000010e8a13ff char const* std::__find<char const*,
char>(char const*, char const*, char const&, std::random_access_iterator_tag) +
3585
1  clang             0x000000010e8a1791 char const* std::__find<char const*,
char>(char const*, char const*, char const&, std::random_access_iterator_tag) +
4499
2  libsystem_c.dylib 0x00007fff8b438cfa _sigtramp + 26
3  libsystem_c.dylib 0x00007f8a090257b0 _sigtramp + 18446743569013066448
4  clang             0x000000010e8a1614 char const* std::__find<char const*,
char>(char const*, char const*, char const&, std::random_access_iterator_tag) +
4118
5  clang             0x000000010e8a15e2 char const* std::__find<char const*,
char>(char const*, char const*, char const&, std::random_access_iterator_tag) +
4068
6  clang             0x000000010e1748b7
clang::operator==(clang::specific_attr_iterator<clang::UuidAttr,
llvm::SmallVector<clang::Attr*, 2u> >,
clang::specific_attr_iterator<clang::UuidAttr, llvm::SmallVector<clang::Attr*,
2u> >) + 92626
7  clang             0x000000010e1746a4
clang::operator==(clang::specific_attr_iterator<clang::UuidAttr,
llvm::SmallVector<clang::Attr*, 2u> >,
clang::specific_attr_iterator<clang::UuidAttr, llvm::SmallVector<clang::Attr*,
2u> >) + 92095
8  clang             0x000000010e17f974
clang::operator==(clang::specific_attr_iterator<clang::UuidAttr,
llvm::SmallVector<clang::Attr*, 2u> >,
clang::specific_attr_iterator<clang::UuidAttr, llvm::SmallVector<clang::Attr*,
2u> >) + 137871
9  clang             0x000000010e16445d
clang::operator==(clang::specific_attr_iterator<clang::UuidAttr,
llvm::SmallVector<clang::Attr*, 2u> >,
clang::specific_attr_iterator<clang::UuidAttr, llvm::SmallVector<clang::Attr*,
2u> >) + 25976
10 clang             0x000000010e163a90
clang::operator==(clang::specific_attr_iterator<clang::UuidAttr,
llvm::SmallVector<clang::Attr*, 2u> >,
clang::specific_attr_iterator<clang::UuidAttr, llvm::SmallVector<clang::Attr*,
2u> >) + 23467
11 clang             0x000000010e15fe21
clang::operator==(clang::specific_attr_iterator<clang::UuidAttr,
llvm::SmallVector<clang::Attr*, 2u> >,
clang::specific_attr_iterator<clang::UuidAttr, llvm::SmallVector<clang::Attr*,
2u> >) + 7996
12 clang             0x000000010e15fd8b
clang::operator==(clang::specific_attr_iterator<clang::UuidAttr,
llvm::SmallVector<clang::Attr*, 2u> >,
clang::specific_attr_iterator<clang::UuidAttr, llvm::SmallVector<clang::Attr*,
2u> >) + 7846
13 clang             0x000000010db2c5a1
clang::operator==(clang::specific_attr_iterator<clang::InitPriorityAttr,
llvm::SmallVector<clang::Attr*, 2u> >,
clang::specific_attr_iterator<clang::InitPriorityAttr,
llvm::SmallVector<clang::Attr*, 2u> >) + 145722
14 clang             0x000000010db2e2ef
clang::operator==(clang::specific_attr_iterator<clang::InitPriorityAttr,
llvm::SmallVector<clang::Attr*, 2u> >,
clang::specific_attr_iterator<clang::InitPriorityAttr,
llvm::SmallVector<clang::Attr*, 2u> >) + 153224
15 clang             0x000000010db2c1b5
clang::operator==(clang::specific_attr_iterator<clang::InitPriorityAttr,
llvm::SmallVector<clang::Attr*, 2u> >,
clang::specific_attr_iterator<clang::InitPriorityAttr,
llvm::SmallVector<clang::Attr*, 2u> >) + 144718
16 clang             0x000000010db2bf4b
clang::operator==(clang::specific_attr_iterator<clang::InitPriorityAttr,
llvm::SmallVector<clang::Attr*, 2u> >,
clang::specific_attr_iterator<clang::InitPriorityAttr,
llvm::SmallVector<clang::Attr*, 2u> >) + 144100
17 clang             0x000000010db8b039
clang::operator==(clang::specific_attr_iterator<clang::NoInstrumentFunctionAttr,
llvm::SmallVector<clang::Attr*, 2u> >,
clang::specific_attr_iterator<clang::NoInstrumentFunctionAttr,
llvm::SmallVector<clang::Attr*, 2u> >) + 20642
18 clang             0x000000010db88b3c
clang::operator==(clang::specific_attr_iterator<clang::NoInstrumentFunctionAttr,
llvm::SmallVector<clang::Attr*, 2u> >,
clang::specific_attr_iterator<clang::NoInstrumentFunctionAttr,
llvm::SmallVector<clang::Attr*, 2u> >) + 11173
19 clang             0x000000010db8a1c1
clang::operator==(clang::specific_attr_iterator<clang::NoInstrumentFunctionAttr,
llvm::SmallVector<clang::Attr*, 2u> >,
clang::specific_attr_iterator<clang::NoInstrumentFunctionAttr,
llvm::SmallVector<clang::Attr*, 2u> >) + 16938
20 clang             0x000000010db8e078
clang::operator==(clang::specific_attr_iterator<clang::NoInstrumentFunctionAttr,
llvm::SmallVector<clang::Attr*, 2u> >,
clang::specific_attr_iterator<clang::NoInstrumentFunctionAttr,
llvm::SmallVector<clang::Attr*, 2u> >) + 32993
21 clang             0x000000010dba3283 std::vector<std::pair<llvm::WeakVH,
llvm::Constant*>, std::allocator<std::pair<llvm::WeakVH, llvm::Constant*> >
>::_M_insert_aux(__gnu_cxx::__normal_iterator<std::pair<llvm::WeakVH,
llvm::Constant*>*, std::vector<std::pair<llvm::WeakVH, llvm::Constant*>,
std::allocator<std::pair<llvm::WeakVH, llvm::Constant*> > > >,
std::pair<llvm::WeakVH, llvm::Constant*> const&) + 3935
22 clang             0x000000010db81213 llvm::ParseIR(llvm::MemoryBuffer*,
llvm::SMDiagnostic&, llvm::LLVMContext&) + 969
23 clang             0x000000010dbaf24e
clang::operator==(clang::specific_attr_iterator<clang::MBlazeInterruptHandlerAttr,
llvm::SmallVector<clang::Attr*, 2u> >,
clang::specific_attr_iterator<clang::MBlazeInterruptHandlerAttr,
llvm::SmallVector<clang::Attr*, 2u> >) + 835
24 clang             0x000000010db80b1d std::vector<clang::CXXRecordDecl
const*, std::allocator<clang::CXXRecordDecl const*>
>::_M_insert_aux(__gnu_cxx::__normal_iterator<clang::CXXRecordDecl const**,
std::vector<clang::CXXRecordDecl const*, std::allocator<clang::CXXRecordDecl
const*> > >, clang::CXXRecordDecl const* const&) + 5105
25 clang             0x000000010d9f2a5a std::_Rb_tree<clang::edit::FileOffset,
std::pair<clang::edit::FileOffset const, clang::edit::EditedSource::FileEdit>,
std::_Select1st<std::pair<clang::edit::FileOffset const,
clang::edit::EditedSource::FileEdit> >, std::less<clang::edit::FileOffset>,
std::allocator<std::pair<clang::edit::FileOffset const,
clang::edit::EditedSource::FileEdit> >
>::_M_erase(std::_Rb_tree_node<std::pair<clang::edit::FileOffset const,
clang::edit::EditedSource::FileEdit> >*) + 3902
26 clang             0x000000010d9dacaa 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&) + 11528
27 clang             0x000000010d9b1fe6 std::_Rb_tree<std::string, std::string,
std::_Identity<std::string>, std::less<std::string>,
std::allocator<std::string> >::_M_insert(std::_Rb_tree_node_base*,
std::_Rb_tree_node_base*, std::string const&) + 3628
28 clang             0x000000010d9ac216 _mh_execute_header + 4630
29 clang             0x000000010d9af33c 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&) +
1192
30 clang             0x000000010d9abf34 _mh_execute_header + 3892
Stack dump:
0.    Program arguments: /usr/local/Cellar/llvm/3.2/bin/clang -cc1 -triple
x86_64-apple-macosx10.7.0 -emit-obj -mrelax-all -disable-free -main-file-name
crash.c -mrelocation-model pic -pic-level 2 -mdisable-fp-elim -masm-verbose
-munwind-tables -target-cpu core2 -target-linker-version 134.9 -resource-dir
/usr/local/Cellar/llvm/3.2/bin/../lib/clang/3.2 -fmodule-cache-path
/var/folders/yp/j3l1fw9n14vd35yrtknnh_km0000gn/T/clang-module-cache
-fdebug-compilation-dir /Users/chris/Downloads -ferror-limit 19
-fmessage-length 238 -stack-protector 1 -mstackrealign -fblocks
-fobjc-runtime=macosx-10.7.0 -fobjc-dispatch-method=mixed
-fobjc-default-synthesize-properties -fencode-extended-block-signature
-fdiagnostics-show-option -fcolor-diagnostics -o
/var/folders/yp/j3l1fw9n14vd35yrtknnh_km0000gn/T/crash-5Rb2nx.o -x c crash.c
1.    <eof> parser at end of file
2.    crash.c:4:9: LLVM IR generation of declaration 'vector'
3.    crash.c:4:9: Generating code for declaration 'vector'
clang: error: unable to execute command: Illegal instruction: 4
clang: error: clang frontend command failed due to signal (use -v to see
invocation)
clang version 3.2 (tags/RELEASE_32/final)
Target: x86_64-apple-darwin11.4.2
Thread model: posix
clang: note: diagnostic msg: PLEASE submit a bug report to
http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and
associated run script.
clang: note: diagnostic msg:
********************

PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang: note: diagnostic msg:
/var/folders/yp/j3l1fw9n14vd35yrtknnh_km0000gn/T/crash-Ilzh2e.c
clang: note: diagnostic msg:
/var/folders/yp/j3l1fw9n14vd35yrtknnh_km0000gn/T/crash-Ilzh2e.sh
clang: note: diagnostic msg:

********************

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130419/57ed7f0f/attachment.html>

From bugzilla-daemon at llvm.org  Fri Apr 19 03:41:52 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 19 Apr 2013 10:41:52 +0000
Subject: [LLVMbugs] [Bug 14037] #pragma pack in nested struct rejected,
 and with poor diagnostics
In-Reply-To: <bug-14037-206@http.llvm.org/bugs/>
References: <bug-14037-206@http.llvm.org/bugs/>
Message-ID: <bug-14037-206-6FFEi6LzfN@http.llvm.org/bugs/>

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

Matti Niemenmaa <matti.niemenmaa+llvmbugs at iki.fi> changed:

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

--- Comment #5 from Matti Niemenmaa <matti.niemenmaa+llvmbugs at iki.fi> ---
Evidently this was a duplicate of Bug 13580, which is now fixed since r179743.

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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130419/53ed0c44/attachment.html>

From bugzilla-daemon at llvm.org  Fri Apr 19 03:46:30 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 19 Apr 2013 10:46:30 +0000
Subject: [LLVMbugs] [Bug 15790] New: MallocWithAnnotations should support
 annotating a realloc-like function
Message-ID: <bug-15790-206@http.llvm.org/bugs/>

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

            Bug ID: 15790
           Summary: MallocWithAnnotations should support annotating a
                    realloc-like function
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Static Analyzer
          Assignee: kremenek at apple.com
          Reporter: bruce.r.stephens at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

I'd expect something like the following to be possible (wrapping realloc).
It seems not to work.

#include <stdlib.h>

void *my_realloc(void *ptr, size_t size)
  __attribute__((ownership_takes(malloc,1)))
  __attribute__((ownership_returns(malloc,2)));

void
test()
{
  void *ptr = malloc(10);
  ptr = my_realloc(ptr, 11);
  free(ptr);
}

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130419/49e17a1c/attachment.html>

From bugzilla-daemon at llvm.org  Fri Apr 19 04:06:39 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 19 Apr 2013 11:06:39 +0000
Subject: [LLVMbugs] [Bug 15791] New: Assertion failed: V, Mask,
 KnownOne and KnownZero should have same BitWidth
Message-ID: <bug-15791-206@http.llvm.org/bugs/>

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

            Bug ID: 15791
           Summary: Assertion failed: V, Mask, KnownOne and KnownZero
                    should have same BitWidth
           Product: new-bugs
           Version: trunk
          Hardware: Macintosh
                OS: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: schnetter at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

I received the following error message from clang:

Command:
{{{
clang++-mp-3.3    -Wall -g -std=c++11 -stdlib=libc++ -march=native -O3   -o
CMakeFiles/test.dir/test.cc.o -c /Users/eschnett/src/cc/vecmathlib/test.cc
}}}
This is the current version in MacPorts.

Error:
{{{
Assertion failed: ((!TD || TD->getTypeSizeInBits(V->getType()->getScalarType())
== BitWidth) && (!V->getType()->isIntOrIntVectorTy() ||
V->getType()->getScalarSizeInBits() == BitWidth) && KnownZero.getBitWidth() ==
BitWidth && KnownOne.getBitWidth() == BitWidth && "V, Mask, KnownOne and
KnownZero should have same BitWidth"), function ComputeMaskedBits, file
ValueTracking.cpp, line 243.
0  libLLVM-3.3svn.dylib 0x000000010bd884b5 llvm::sys::PrintStackTrace(__sFILE*)
+ 37
1  libLLVM-3.3svn.dylib 0x000000010bd88b29 SignalHandler(int) + 713
2  libsystem_c.dylib    0x00007fff90a8594a _sigtramp + 26
3  libsystem_c.dylib    0x0000000100000020 _sigtramp + 1868015344
4  libLLVM-3.3svn.dylib 0x000000010bd887b6 abort + 22
5  libLLVM-3.3svn.dylib 0x000000010bd88775 __assert_rtn + 53
6  libLLVM-3.3svn.dylib 0x000000010b5874ad
llvm::ComputeMaskedBits(llvm::Value*, llvm::APInt&, llvm::APInt&,
llvm::DataLayout const*, unsigned int) + 17485
7  libLLVM-3.3svn.dylib 0x000000010b4a75c3
llvm::ConstantFoldInstOperands(unsigned int, llvm::Type*,
llvm::ArrayRef<llvm::Constant*>, llvm::DataLayout const*,
llvm::TargetLibraryInfo const*) + 339
8  libLLVM-3.3svn.dylib 0x000000010b4d7402 SimplifyAndInst(llvm::Value*,
llvm::Value*, Query const&, unsigned int) + 786
9  libLLVM-3.3svn.dylib 0x000000010b4db58d SimplifyBinOp(unsigned int,
llvm::Value*, llvm::Value*, Query const&, unsigned int) + 429
10 libLLVM-3.3svn.dylib 0x000000010b4db3d3 llvm::SimplifyBinOp(unsigned int,
llvm::Value*, llvm::Value*, llvm::DataLayout const*, llvm::TargetLibraryInfo
const*, llvm::DominatorTree const*) + 35
11 libLLVM-3.3svn.dylib 0x000000010bf458e6 (anonymous
namespace)::CallAnalyzer::visitBinaryOperator(llvm::BinaryOperator&) + 294
12 libLLVM-3.3svn.dylib 0x000000010bf42925 llvm::InstVisitor<(anonymous
namespace)::CallAnalyzer, bool>::visit(llvm::Instruction&) + 1733
13 libLLVM-3.3svn.dylib 0x000000010bf41eed (anonymous
namespace)::CallAnalyzer::analyzeCall(llvm::CallSite) + 4189
14 libLLVM-3.3svn.dylib 0x000000010bf406fd
llvm::InlineCostAnalysis::getInlineCost(llvm::CallSite, llvm::Function*, int) +
701
15 libLLVM-3.3svn.dylib 0x000000010bf403f5
llvm::InlineCostAnalysis::getInlineCost(llvm::CallSite, int) + 69
16 libLLVM-3.3svn.dylib 0x000000010bf6d501
llvm::Inliner::shouldInline(llvm::CallSite) + 33
17 libLLVM-3.3svn.dylib 0x000000010bf6e7e7
llvm::Inliner::runOnSCC(llvm::CallGraphSCC&) + 2743
18 libLLVM-3.3svn.dylib 0x000000010bf6d252 (anonymous
namespace)::SimpleInliner::runOnSCC(llvm::CallGraphSCC&) + 50
19 libLLVM-3.3svn.dylib 0x000000010bf3707c (anonymous
namespace)::CGPassManager::runOnModule(llvm::Module&) + 1692
20 libLLVM-3.3svn.dylib 0x000000010b838d88
llvm::MPPassManager::runOnModule(llvm::Module&) + 376
21 libLLVM-3.3svn.dylib 0x000000010b839316
llvm::PassManagerImpl::run(llvm::Module&) + 182
22 libLLVM-3.3svn.dylib 0x000000010b83950d
llvm::PassManager::run(llvm::Module&) + 13
23 clang                0x000000010a099668
clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::CodeGenOptions
const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::Module*,
clang::BackendAction, llvm::raw_ostream*) + 5352
24 clang                0x000000010a17deec
clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) + 620
25 clang                0x000000010a1b9496 clang::ParseAST(clang::Sema&, bool,
bool) + 518
26 clang                0x000000010a17d1d5
clang::CodeGenAction::ExecuteAction() + 1205
27 clang                0x0000000109f7154c clang::FrontendAction::Execute() +
124
28 clang                0x0000000109f5039f
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 1007
29 clang                0x0000000109f22f14
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 3652
30 clang                0x0000000109f1a4e5 cc1_main(char const**, char const**,
char const*, void*) + 837
31 clang                0x0000000109f1ed54 main + 708
32 libdyld.dylib        0x00007fff98a237e1 start + 0
Stack dump:
0.    Program arguments: /opt/local/libexec/llvm-3.3/bin/clang -cc1 -triple
x86_64-apple-macosx10.8.0 -emit-obj -disable-free -main-file-name test.cc
-mrelocation-model pic -pic-level 2 -mdisable-fp-elim -masm-verbose
-munwind-tables -target-cpu core-avx-i -target-linker-version 134.9 -g
-coverage-file /Users/eschnett/src/cc/vecmathlib/CMakeFiles/test.dir/test.cc.o
-resource-dir /opt/local/libexec/llvm-3.3/bin/../lib/clang/3.3 -stdlib=libc++
-O3 -Wall -std=c++11 -fdeprecated-macro -fdebug-compilation-dir
/Users/eschnett/src/cc/vecmathlib -ferror-limit 19 -fmessage-length 80
-stack-protector 1 -mstackrealign -fblocks -fobjc-runtime=macosx-10.8.0
-fobjc-dispatch-method=mixed -fobjc-default-synthesize-properties
-fencode-extended-block-signature -fcxx-exceptions -fexceptions
-fdiagnostics-show-option -fcolor-diagnostics -backend-option -vectorize-loops
-o CMakeFiles/test.dir/test.cc.o -x c++
/Users/eschnett/src/cc/vecmathlib/test.cc 
1.    <eof> parser at end of file
2.    Per-module optimization passes
3.    Running pass 'CallGraph Pass Manager' on module
'/Users/eschnett/src/cc/vecmathlib/test.cc'.
clang: error: unable to execute command: Illegal instruction: 4
clang: error: clang frontend command failed due to signal (use -v to see
invocation)
clang version 3.3 (trunk 179575)
Target: x86_64-apple-darwin12.3.0
Thread model: posix
clang: note: diagnostic msg: PLEASE submit a bug report to
http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and
associated run script.
clang: note: diagnostic msg: 
********************

PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang: note: diagnostic msg:
/var/folders/gl/zvl8d6415vsbkd50nnll95k40000gs/T/test-ufUll1.cpp
clang: note: diagnostic msg:
/var/folders/gl/zvl8d6415vsbkd50nnll95k40000gs/T/test-ufUll1.sh
clang: note: diagnostic msg: 

********************
}}}

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130419/11512226/attachment.html>

From bugzilla-daemon at llvm.org  Fri Apr 19 04:17:45 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 19 Apr 2013 11:17:45 +0000
Subject: [LLVMbugs] [Bug 15792] New: LLVM ERROR: Cannot select: intrinsic
 %llvm.x86.sse41.blendvps
Message-ID: <bug-15792-206@http.llvm.org/bugs/>

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

            Bug ID: 15792
           Summary: LLVM ERROR: Cannot select: intrinsic
                    %llvm.x86.sse41.blendvps
           Product: new-bugs
           Version: trunk
          Hardware: Macintosh
                OS: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: schnetter at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 10381
  --> http://llvm.org/bugs/attachment.cgi?id=10381&action=edit
preprocessed source code

When I execute the commands:
{{{
clang++-mp-3.3    -Wall -g -std=c++11 -stdlib=libc++ -march=native -O4   -o
CMakeFiles/bench.dir/bench.cc.o -c /Users/eschnett/src/cc/vecmathlib/bench.cc
clang++-mp-3.3 -v    -Wall -g -std=c++11 -stdlib=libc++ -march=native -O4
-Wl,-search_paths_first -Wl,-headerpad_max_install_names  
CMakeFiles/bench.dir/bench.cc.o  -o bench  
}}}

then I receive this error:
{{{
clang version 3.3 (trunk 179575)
Target: x86_64-apple-darwin12.3.0
Thread model: posix
 "/opt/local/libexec/llvm-3.3/bin/ld" -demangle -dynamic -arch x86_64
-macosx_version_min 10.8.0 -o bench -search_paths_first
-headerpad_max_install_names CMakeFiles/bench.dir/bench.cc.o -lc++ -lSystem
/opt/local/libexec/llvm-3.3/bin/../lib/clang/3.3/lib/darwin/libclang_rt.osx.a
LLVM ERROR: Cannot select: intrinsic %llvm.x86.sse41.blendvps
clang: error: linker command failed with exit code 1 (use -v to see invocation)
}}}

Things work fine if I replace -O4 by -O3. My processor does support the
blendvps instruction.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130419/0b0caee8/attachment.html>

From bugzilla-daemon at llvm.org  Fri Apr 19 08:02:12 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 19 Apr 2013 15:02:12 +0000
Subject: [LLVMbugs] [Bug 15794] New: Loop Vectorizer: Crashes with the use
 of llvm.loop.parallel metadata
Message-ID: <bug-15794-206@http.llvm.org/bugs/>

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

            Bug ID: 15794
           Summary: Loop Vectorizer: Crashes with the use of
                    llvm.loop.parallel metadata
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Loop Optimizer
          Assignee: unassignedbugs at nondot.org
          Reporter: muhammad.t.ahmad at intel.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

I have C code[1] that I compile to the LLVM IR[2] and manually add the
llvm.loop.parallel and llvm.mem.parallel_loop_access metadata and run `opt` on
like so:

$ opt test.ll -o - -loop-vectorize -force-vector-unroll=1 -force-vector-width=4
-dce -instcombine -S -debug

Running the above fails with the following error. I am not sure what is causing
this.
http://sprunge.us/AWRM

[1] C Code:
http://sprunge.us/jIOU?c

[2] LLVM IR:
http://sprunge.us/aTCI?llvm


(I am using sprunge for this because it's a lot of code and not very readable
unless highlighted. If required, I can attach/paste the code here.)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130419/d775f1a9/attachment.html>

From bugzilla-daemon at llvm.org  Fri Apr 19 10:01:36 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 19 Apr 2013 17:01:36 +0000
Subject: [LLVMbugs] [Bug 15791] Assertion failed: V, Mask,
 KnownOne and KnownZero should have same BitWidth
In-Reply-To: <bug-15791-206@http.llvm.org/bugs/>
References: <bug-15791-206@http.llvm.org/bugs/>
Message-ID: <bug-15791-206-VdCzx0NsNM@http.llvm.org/bugs/>

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

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

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

--- Comment #3 from Benjamin Kramer <benny.kra at gmail.com> ---
Fixed in r179859.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130419/f0624954/attachment.html>

From bugzilla-daemon at llvm.org  Fri Apr 19 11:21:25 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 19 Apr 2013 18:21:25 +0000
Subject: [LLVMbugs] [Bug 15795] New: [arm disassembler] Disassembler can't
 read llvm created object
Message-ID: <bug-15795-206@http.llvm.org/bugs/>

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

            Bug ID: 15795
           Summary: [arm disassembler] Disassembler can't read llvm
                    created object
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: ARM
          Assignee: unassignedbugs at nondot.org
          Reporter: echristo at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

~/builds/build-llvm/Debug+Asserts/bin/llc -filetype=obj
2011-01-19-MergedGlobalDbg.ll

~/builds/build-llvm/Debug+Asserts/bin/llvm-objdump -disassemble
2011-01-19-MergedGlobalDbg.o

_get3:
      28:    40 f2 84 32                                      addlo    pc, r4,
#4
      2c:    c0 f2 00 02                                      andeq    pc, r0,
#12
      30:    7a 44 91 78                                      ldmvc    r1, {r1,
r3, r4, r5, r6, r10, lr}
/Users/echristo/builds/build-llvm/Debug+Asserts/bin/llvm-objdump: warning:
invalid instruction encoding
      35:    70 08 46 70                                      subvc    r0, r6,
r0, ror r8
      39:    47 00 bf 40                                      adcsmi    r0, pc,
r7, asr #32

otool -tv gives:

_get3:
00000028    f2403284    movw    r2, #900
0000002c    f2c00200    movt    r2, #0
00000030        447a    add    r2, pc
00000032        7891    ldrb    r1, [r2, #2]
00000034        7090    strb    r0, [r2, #2]
00000036        4608    mov    r0, r1
00000038        4770    bx    lr
0000003a        bf00    nop

which isn't even close to what llvm-objdump is giving.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130419/1bd37f11/attachment.html>

From bugzilla-daemon at llvm.org  Fri Apr 19 11:50:15 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 19 Apr 2013 18:50:15 +0000
Subject: [LLVMbugs] [Bug 15796] New: Outdated SourceLevelDebugging.html
Message-ID: <bug-15796-206@http.llvm.org/bugs/>

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

            Bug ID: 15796
           Summary: Outdated SourceLevelDebugging.html
           Product: clang
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Documentation
          Assignee: unassignedclangbugs at nondot.org
          Reporter: ggreif at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

What version of DWARF does Clang/LLVM support?

http://llvm.org/docs/SourceLevelDebugging.html#philosophy-behind-llvm-debugging-information
appears to suggest DWARF3

also the link http://www.eagercon.com/dwarf/dwarf3std.htm seems to be a very
old one --> dwarfstd.org

It should be documented how Clang/LLVM can be instructed to emit older DWARF
for legacy tools (-gdwarf-2 or -gdwarf-3).

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130419/d073616e/attachment.html>

From bugzilla-daemon at llvm.org  Fri Apr 19 13:04:29 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 19 Apr 2013 20:04:29 +0000
Subject: [LLVMbugs] [Bug 15786] Frontend crash, assertion in Attributes.cpp
In-Reply-To: <bug-15786-206@http.llvm.org/bugs/>
References: <bug-15786-206@http.llvm.org/bugs/>
Message-ID: <bug-15786-206-cmVXKZHmSU@http.llvm.org/bugs/>

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

Bill Wendling <wendling at apple.com> changed:

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

--- Comment #2 from Bill Wendling <wendling at apple.com> ---
I'm surprised you got an assertion failure. The 3.2 binaries should have been
compiled without assertions turned on.

Anyway, I'm not seeing this with ToT.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130419/1a08f2dd/attachment.html>

From bugzilla-daemon at llvm.org  Fri Apr 19 13:14:49 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 19 Apr 2013 20:14:49 +0000
Subject: [LLVMbugs] [Bug 15797] New: Better warning when using c++11 enum
 classes without -std=c++11
Message-ID: <bug-15797-206@http.llvm.org/bugs/>

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

            Bug ID: 15797
           Summary: Better warning when using c++11 enum classes without
                    -std=c++11
           Product: clang
           Version: unspecified
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++11
          Assignee: unassignedclangbugs at nondot.org
          Reporter: echristo at gmail.com
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified

This error message:

athyra:~/tmp> ~/builds/build-llvm/Debug+Asserts/bin/clang -g -c foo.cpp -o
clang.o
foo.cpp:1:6: error: expected identifier or '{'
enum struct Colour { grey };
     ^

probably should mention turning on C++11.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130419/7afa5702/attachment.html>

From bugzilla-daemon at llvm.org  Fri Apr 19 14:21:36 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 19 Apr 2013 21:21:36 +0000
Subject: [LLVMbugs] [Bug 12477] [meta] Support Microsoft C++ ABI
In-Reply-To: <bug-12477-206@http.llvm.org/bugs/>
References: <bug-12477-206@http.llvm.org/bugs/>
Message-ID: <bug-12477-206-52FKDlUTTr@http.llvm.org/bugs/>

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

Bug 12477 depends on bug 14410, which changed state.

Bug 14410 Summary: [-cxx-abi microsoft] Wrong mangling of __stdcall functions?
http://llvm.org/bugs/show_bug.cgi?id=14410

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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130419/543bbd32/attachment.html>

From bugzilla-daemon at llvm.org  Fri Apr 19 14:21:34 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 19 Apr 2013 21:21:34 +0000
Subject: [LLVMbugs] [Bug 14410] [-cxx-abi microsoft] Wrong mangling of
 __stdcall functions?
In-Reply-To: <bug-14410-206@http.llvm.org/bugs/>
References: <bug-14410-206@http.llvm.org/bugs/>
Message-ID: <bug-14410-206-MKBfvkb88z@http.llvm.org/bugs/>

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

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> ---
Fixed in r179889

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130419/9c78d61e/attachment.html>

From bugzilla-daemon at llvm.org  Fri Apr 19 15:06:31 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 19 Apr 2013 22:06:31 +0000
Subject: [LLVMbugs] [Bug 15744] extern "C" linkage ignored for a static
	function
In-Reply-To: <bug-15744-206@http.llvm.org/bugs/>
References: <bug-15744-206@http.llvm.org/bugs/>
Message-ID: <bug-15744-206-LXbU67T3so@http.llvm.org/bugs/>

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

/dev/humancontroller <M8R-9yw8a5 at mailinator.com> changed:

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

--- Comment #2 from /dev/humancontroller <M8R-9yw8a5 at mailinator.com> ---
> This bug was fixed

WRONG.

Compilation still fails with -O2.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130419/3ade4143/attachment.html>

From bugzilla-daemon at llvm.org  Fri Apr 19 15:06:46 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 19 Apr 2013 22:06:46 +0000
Subject: [LLVMbugs] [Bug 15798] New: Regression(r178606): Clang runs out of
 registers when building libyuv's row_posix for 32bit with -fPIC
Message-ID: <bug-15798-206@http.llvm.org/bugs/>

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

            Bug ID: 15798
           Summary: Regression(r178606): Clang runs out of registers when
                    building libyuv's row_posix for 32bit with -fPIC
           Product: clang
           Version: unspecified
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Driver
          Assignee: unassignedclangbugs at nondot.org
          Reporter: nicolasweber at gmx.de
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 10387
  --> http://llvm.org/bugs/attachment.cgi?id=10387&action=edit
Repro case out.ii

thakis at yearofthelinuxdesktop:/usr/local/google/chrome/src$
third_party/llvm-build/Release+Asserts/bin/clang --versionclang version 3.3
(trunk 178606)
Target: x86_64-unknown-linux-gnu
Thread model: posix
thakis at yearofthelinuxdesktop:/usr/local/google/chrome/src$
third_party/llvm-build/Release+Asserts/bin/clang  -c out.ii -m32 -fPIC
../../third_party/libyuv/source/row_posix.cc:1825:5: error: ran out of
registers during register allocation
    "movdqa    %[kShuffleMaskARGBToRGB24_0],%%xmm5 \n"
    ^
../../third_party/libyuv/source/row_posix.cc:1880:5: error: ran out of
registers during register allocation
    "movdqa    %[kShuffleMaskARGBToRAW_0],%%xmm5 \n"
    ^
2 errors generated.


Used to work one revision earlier:

thakis at yearofthelinuxdesktop:/usr/local/google/chrome/src$
third_party/llvm-build/Release+Asserts/bin/clang --version
clang version 3.3 (trunk 178605)
Target: x86_64-unknown-linux-gnu
Thread model: posix
thakis at yearofthelinuxdesktop:/usr/local/google/chrome/src$
third_party/llvm-build/Release+Asserts/bin/clang  -c out.ii -m32 -fPIC
# works



I suppose the workaround is to pass -momit-leaf-frame-pointer, which
effectively reverts r178606 user-side, but the change description doesn't say
why the change was done and the change does regress functionality, so maybe it
should be undone as well.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130419/f0ab7ab8/attachment.html>

From bugzilla-daemon at llvm.org  Fri Apr 19 15:15:43 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 19 Apr 2013 22:15:43 +0000
Subject: [LLVMbugs] [Bug 13795] MIPS inline asm() fails on register
 constraints with "couldn't allocate output register for constraint '{$2}'"
In-Reply-To: <bug-13795-206@http.llvm.org/bugs/>
References: <bug-13795-206@http.llvm.org/bugs/>
Message-ID: <bug-13795-206-Rbf2uxxyeg@http.llvm.org/bugs/>

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

Jack Carter <jcarter at mips.com> changed:

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

--- Comment #6 from Jack Carter <jcarter at mips.com> ---
Assertion fixed by unknown previous commit.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130419/a499e0d1/attachment.html>

From bugzilla-daemon at llvm.org  Fri Apr 19 15:55:01 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 19 Apr 2013 22:55:01 +0000
Subject: [LLVMbugs] [Bug 15787] Assert in
 llvm::MachineRegisterInfo::clearVirtRegs: Vreg use list non-empty still
In-Reply-To: <bug-15787-206@http.llvm.org/bugs/>
References: <bug-15787-206@http.llvm.org/bugs/>
Message-ID: <bug-15787-206-h0OVdkZ142@http.llvm.org/bugs/>

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

Hal Finkel <hfinkel at anl.gov> changed:

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

--- Comment #8 from Hal Finkel <hfinkel at anl.gov> ---
(In reply to comment #7)
> (In reply to comment #6)
> > I suspect the problems is here:
> > 
> >   SmallVector<std::pair<MachineOperand*, PPC::Predicate>, 4>
> >       OperandsToUpdate;
> >   SmallVector<std::pair<MachineOperand*, MachineOperand*>, 4>
> >       OperandsToSwap;
> > 
> > When you add operands to an MI, all operand pointers and references are
> > invalidated, just like a std::vector.
> 
> Okay, thanks for looking at this! The OperandsToSwap array is going to go
> away shortly; so I'll retest with the new version.

Yep; this was the problem. Thanks again!

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130419/0e291e68/attachment.html>

From bugzilla-daemon at llvm.org  Fri Apr 19 17:42:03 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 20 Apr 2013 00:42:03 +0000
Subject: [LLVMbugs] [Bug 15774] BoolAssignmentChecker not catching literals
In-Reply-To: <bug-15774-206@http.llvm.org/bugs/>
References: <bug-15774-206@http.llvm.org/bugs/>
Message-ID: <bug-15774-206-xB90MeaO5Q@http.llvm.org/bugs/>

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

Jordan Rose <jordan_rose at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |jordan_rose at apple.com
         Resolution|---                         |INVALID

--- Comment #1 from Jordan Rose <jordan_rose at apple.com> ---
BoolAssignmentChecker isn't actually for checking C++/C99 bool; it's for types
that are intended to be used as boolean variables but are actually typedefs of
small integers, like Objective-C's BOOL.

Why the distinction? For 'bool', coercion/casting always gives the same answer
as testing with an if, while, or ?:. But for 'BOOL', a cast results in
truncation, rather than truth-testing.

Similarly, you can safely compare a 'bool' variable against 'false' or 'true',
but a 'BOOL' variable may not always be 'NO' (0) or 'YES' (1), although it
probably ought to be.

So, yes, this is by design. You could argue that relying on an implicit
int-to-boolean conversion is bad style, but that would be a separate argument,
not a bug in the current checker. :-)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130420/d43dca70/attachment.html>

From bugzilla-daemon at llvm.org  Fri Apr 19 18:10:11 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 20 Apr 2013 01:10:11 +0000
Subject: [LLVMbugs] [Bug 15744] extern "C" linkage ignored for a static
	function
In-Reply-To: <bug-15744-206@http.llvm.org/bugs/>
References: <bug-15744-206@http.llvm.org/bugs/>
Message-ID: <bug-15744-206-plD5hwsBLZ@http.llvm.org/bugs/>

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
                 CC|                            |rafael.espindola at gmail.com
         Resolution|---                         |FIXED

--- Comment #3 from Rafael Ávila de Espíndola <rafael.espindola at gmail.com> ---
First, note that the firefox code is wrong and should be changed to not depend
on the name of functions without C language linkage.

Second, the compatibility hack in clang is in place and working.

Third, what is missing is a bug a bug in globalopt that causes it to remove the
alias. A patch is under code review.

Fourth, it is really impolite to keep pestering people on IRC and now on
bugzilla. Please stop.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130420/d9b12445/attachment.html>

From bugzilla-daemon at llvm.org  Sat Apr 20 07:17:29 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 20 Apr 2013 14:17:29 +0000
Subject: [LLVMbugs] [Bug 15799] New: Variadic pack at the beginning of
 function parameters not seen as a non-deduced context
Message-ID: <bug-15799-206@http.llvm.org/bugs/>

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

            Bug ID: 15799
           Summary: Variadic pack at the beginning of function parameters
                    not seen as a non-deduced context
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++11
          Assignee: unassignedclangbugs at nondot.org
          Reporter: hivemaster at hotmail.de
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified

The following simple snippet fails to compile:

template<typename T> struct any{ template<typename U> any(U){} };

template<typename... Ts, typename T>
T back(any<Ts>..., T);

int main(){
    using _ = decltype(back<int>(true, 42));
}

With:

main.cpp:7:24: error: no matching function for call to 'back'
    using _ = decltype(back<int>(true, 42));
                       ^~~~~~~~~
main.cpp:4:3: note: candidate template ignored: couldn't infer template
argument 'T'
T back(any<Ts>..., T);

May be related to http://llvm.org/bugs/show_bug.cgi?id=9020

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130420/18318770/attachment.html>

From bugzilla-daemon at llvm.org  Sat Apr 20 10:01:18 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 20 Apr 2013 17:01:18 +0000
Subject: [LLVMbugs] [Bug 15800] New: SLP vectorizer crash
Message-ID: <bug-15800-206@http.llvm.org/bugs/>

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

            Bug ID: 15800
           Summary: SLP vectorizer crash
           Product: clang
           Version: trunk
          Hardware: Macintosh
                OS: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: LLVM Codegen
          Assignee: unassignedclangbugs at nondot.org
          Reporter: vince at macports.org
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 10388
  --> http://llvm.org/bugs/attachment.cgi?id=10388&action=edit
Preprocessed source and other /tmp files

Clang (r179938) SLP vectorizer crashes on this code (see attachement):

Assertion failed: (isValidElementType(ElementType) && "Elements of a VectorType
must be a primitive type"), function get, file Type.cpp, line 714.
0  libLLVM-3.3svn.dylib 0x000000010bd11468 llvm::sys::PrintStackTrace(__sFILE*)
+ 40
1  libLLVM-3.3svn.dylib 0x000000010bd11a54 SignalHandler(int) + 548
2  libsystem_c.dylib    0x00007fff8c24d94a _sigtramp + 26
3  libsystem_c.dylib    0x00007fcbd05cc990 _sigtramp + 1144516704
4  libLLVM-3.3svn.dylib 0x000000010bd11786 abort + 22
5  libLLVM-3.3svn.dylib 0x000000010bd11761 __assert_rtn + 81
6  libLLVM-3.3svn.dylib 0x000000010b7c620d llvm::VectorType::get(llvm::Type*,
unsigned int) + 301
7  libLLVM-3.3svn.dylib 0x000000010bdbe93b
llvm::BoUpSLP::getScalarizationCost(llvm::ArrayRef<llvm::Value*>) + 59
8  libLLVM-3.3svn.dylib 0x000000010bdbc053 (anonymous
namespace)::SLPVectorizer::tryToVectorizePair(llvm::Value*, llvm::Value*,
llvm::BoUpSLP&) + 307
9  libLLVM-3.3svn.dylib 0x000000010bdbb597 (anonymous
namespace)::SLPVectorizer::runOnFunction(llvm::Function&) + 1047
10 libLLVM-3.3svn.dylib 0x000000010b7ba85b
llvm::FPPassManager::runOnFunction(llvm::Function&) + 347
11 libLLVM-3.3svn.dylib 0x000000010bebf9cb (anonymous
namespace)::CGPassManager::runOnModule(llvm::Module&) + 1563
12 libLLVM-3.3svn.dylib 0x000000010b7bae51
llvm::MPPassManager::runOnModule(llvm::Module&) + 433
13 libLLVM-3.3svn.dylib 0x000000010b7bb3dc
llvm::PassManagerImpl::run(llvm::Module&) + 204
14 libLLVM-3.3svn.dylib 0x000000010b7bb5cd
llvm::PassManager::run(llvm::Module&) + 13
15 clang                0x000000010a01223a
clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::CodeGenOptions
const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::Module*,
clang::BackendAction, llvm::raw_ostream*) + 5546
16 clang                0x000000010a0f523a
clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) + 602
17 clang                0x000000010a1323e4 clang::ParseAST(clang::Sema&, bool,
bool) + 516
18 clang                0x000000010a0f42b6
clang::CodeGenAction::ExecuteAction() + 534
19 clang                0x0000000109ee5ed7 clang::FrontendAction::Execute() +
119
20 clang                0x0000000109ec29bd
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 957
21 clang                0x0000000109e9429a
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 3690
22 clang                0x0000000109e8b620 cc1_main(char const**, char const**,
char const*, void*) + 816
23 clang                0x0000000109e916b9 main + 6937
24 libdyld.dylib        0x00007fff917537e1 start + 0
Stack dump:
0.    Program arguments: /opt/local/libexec/llvm-3.3/bin/clang -cc1 -triple
x86_64-apple-macosx10.8.0 -emit-obj -disable-free -main-file-name gmmsearch.c
-mrelocation-model pic -pic-level 2 -masm-verbose -munwind-tables -target-cpu
corei7-avx -target-feature +avx -target-linker-version 134.9 -coverage-file
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_math_atlas/atlas/work/atlas-3.10.1/build/tune/blas/gemm/gmmsearch.o
-resource-dir /opt/local/libexec/llvm-3.3/bin/../lib/clang/3.3 -D
L2SIZE=4194304 -D Add_ -D F77_INTEGER=int -D StringSunStyle -D ATL_OS_OSX -D
ATL_ARCH_Corei2 -D ATL_CPUMHZ=2300 -D ATL_AVX -D ATL_SSE3 -D ATL_SSE2 -D
ATL_SSE1 -D ATL_USE64BITS -D ATL_GAS_x8664 -D ATL_DYLIBS -D PentiumCPS=2300 -D
ATL_FULL_LAPACK -D ATL_NCPU=4 -I
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_math_atlas/atlas/work/atlas-3.10.1/build/include
-I
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_math_atlas/atlas/work/atlas-3.10.1/build/..//include
-I
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_math_atlas/atlas/work/atlas-3.10.1/build/..//include/contrib
-I/opt/local/include -O3 -fdebug-compilation-dir
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_math_atlas/atlas/work/atlas-3.10.1/build/tune/blas/gemm
-ferror-limit 19 -fmessage-length 0 -stack-protector 1 -mstackrealign -fblocks
-fobjc-runtime=macosx-10.8.0 -fobjc-dispatch-method=mixed
-fobjc-default-synthesize-properties -fencode-extended-block-signature
-fdiagnostics-show-option -backend-option -vectorize-loops -backend-option
-vectorize-slp -o gmmsearch.o -x c
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_math_atlas/atlas/work/atlas-3.10.1/build/..//tune/blas/gemm/gmmsearch.c 
1.    <eof> parser at end of file
2.    Per-module optimization passes
3.    Running pass 'CallGraph Pass Manager' on module
'/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_math_atlas/atlas/work/atlas-3.10.1/build/..//tune/blas/gemm/gmmsearch.c'.
4.    Running pass 'SLP Vectorizer' on function '@GetMuNus'
clang: error: unable to execute command: Illegal instruction: 4
clang: error: clang frontend command failed due to signal (use -v to see
invocation)
clang version 3.3 (trunk 179938)
Target: x86_64-apple-darwin12.3.0
Thread model: posix
clang: note: diagnostic msg: PLEASE submit a bug report to
http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and
associated run script.
clang: note: diagnostic msg: 
********************

PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang: note: diagnostic msg: /tmp/gmmsearch-kavQsv.c
clang: note: diagnostic msg: /tmp/gmmsearch-kavQsv.sh
clang: note: diagnostic msg: 

********************

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130420/46099bea/attachment.html>

From bugzilla-daemon at llvm.org  Sat Apr 20 11:25:30 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 20 Apr 2013 18:25:30 +0000
Subject: [LLVMbugs] [Bug 11128] Failed assertion: `Result.isInvalid() &&
 "C++ binary operator overloading is missing candidates!"'
In-Reply-To: <bug-11128-206@http.llvm.org/bugs/>
References: <bug-11128-206@http.llvm.org/bugs/>
Message-ID: <bug-11128-206-pegfW3opJ0@http.llvm.org/bugs/>

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

Elias Pipping <pipping at exherbo.org> changed:

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

--- Comment #3 from Elias Pipping <pipping at exherbo.org> ---
With clang 3.2, this now really seems to be fixed.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130420/fcf359c1/attachment.html>

From bugzilla-daemon at llvm.org  Sat Apr 20 12:49:09 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 20 Apr 2013 19:49:09 +0000
Subject: [LLVMbugs] [Bug 15676] clang segfaults when cross compiling
 arch/arm/mm/context.c for ARM (Linux Kernel Build)
In-Reply-To: <bug-15676-206@http.llvm.org/bugs/>
References: <bug-15676-206@http.llvm.org/bugs/>
Message-ID: <bug-15676-206-PcHXW6YXC8@http.llvm.org/bugs/>

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

Tim Northover <t.p.northover at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |t.p.northover at gmail.com
         Resolution|---                         |FIXED

--- Comment #3 from Tim Northover <t.p.northover at gmail.com> ---
I believe this is fixed in r179956. All noted test-cases successfully compile.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130420/0cb3f696/attachment.html>

From bugzilla-daemon at llvm.org  Sat Apr 20 12:49:11 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 20 Apr 2013 19:49:11 +0000
Subject: [LLVMbugs] [Bug 4068] [META] Compiling the Linux kernel with clang
In-Reply-To: <bug-4068-206@http.llvm.org/bugs/>
References: <bug-4068-206@http.llvm.org/bugs/>
Message-ID: <bug-4068-206-3T7XUq0xkR@http.llvm.org/bugs/>

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

Bug 4068 depends on bug 15676, which changed state.

Bug 15676 Summary: clang segfaults when cross compiling arch/arm/mm/context.c for ARM (Linux Kernel Build)
http://llvm.org/bugs/show_bug.cgi?id=15676

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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130420/06883c49/attachment.html>

From bugzilla-daemon at llvm.org  Sat Apr 20 15:43:26 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 20 Apr 2013 22:43:26 +0000
Subject: [LLVMbugs] [Bug 15800] SLP vectorizer crash
In-Reply-To: <bug-15800-206@http.llvm.org/bugs/>
References: <bug-15800-206@http.llvm.org/bugs/>
Message-ID: <bug-15800-206-TkvJpZ1k6z@http.llvm.org/bugs/>

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

Nadav Rotem <nrotem at apple.com> changed:

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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130420/e0eb7d53/attachment.html>

From bugzilla-daemon at llvm.org  Sat Apr 20 15:45:49 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 20 Apr 2013 22:45:49 +0000
Subject: [LLVMbugs] [Bug 15801] New: illegal use of decltype in destructor
 silently accepted
Message-ID: <bug-15801-206@http.llvm.org/bugs/>

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

            Bug ID: 15801
           Summary: illegal use of decltype in destructor silently
                    accepted
           Product: clang
           Version: 3.1
          Hardware: PC
                OS: other
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++11
          Assignee: unassignedclangbugs at nondot.org
          Reporter: mmehlich at semanticdesigns.com
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Source code:

extern "C" int printf(const char *, ...);

struct C {
    C *c;
    C() { printf("CREATE\n"); }
    ~decltype(*c)() { printf("DECLTYPE DESTROY\n"); }
    ~C() { printf("DESTROY\n"); }
};
int main() {
    C c{};
}

The line ~decltype(*c)()... should be reported as malformed as the destructor
must use the name of the destructor's class (12.4).

Using the compilation command
  clang -std=c++11 test.cpp -o out.exe -stdc++
the code does compile without any errors or warning.

The resulting executable calls the user-provided constructor C() 
but no user-provided destructor...

-- version of clang used:
>>> clang -v
clang version 3.1 (branches/release_31)
Target: i386-pc-cygwin
Thread model: posix

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130420/8d8cabd7/attachment.html>

From bugzilla-daemon at llvm.org  Sat Apr 20 16:48:05 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 20 Apr 2013 23:48:05 +0000
Subject: [LLVMbugs] [Bug 15802] New: On windows %INCLUDE% ending in \ leads
 to clang hanging when trying to kick of new process
Message-ID: <bug-15802-206@http.llvm.org/bugs/>

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

            Bug ID: 15802
           Summary: On windows %INCLUDE% ending in \ leads to clang
                    hanging when trying to kick of new process
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: van_kessel at freenet.de
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 10389
  --> http://llvm.org/bugs/attachment.cgi?id=10389&action=edit
possible patch

On Windows, invoking "clang test.c" makes clang hang during startup if
%INCLUDE% ends in a \ and presumably some similar conditions as well.

The problem has been described by user qble on
http://stackoverflow.com/questions/15992645/clang-compiler-hangs-on-windows

When clang gets invoked with actual work, it assembles a list of arguments and
kicks of a new process. Among those arguments is the include environment
variable on windows. In case this variable contains spaces or some other (e.g.
"C:\Program Files\SomeVendor\Include\") or some other special characters, clang
adds quotation marks around this string so that it stays a single argument to
the new process. If the argument ends in an uneven number (typically one) of
backslashes though, the quotation mark becomes escaped and thus instead of a
invocation like

clang "C:\Program Files\SomeVendor\Include\\" someOtherArg

which makes 

argv[1] = "C:\\Program Files\\SomeVendor\\Include\\"
argv[2] = "someOtherArg"

it becomes

clang "C:\Program Files\SomeVendor\Include\" someOtherArg

which is a unterminated 

argv[1] =  "C:\\Program Files\\SomeVendor\\Include\" someOtherArg ...


The problem can easily be fixed by escaping uneven trailing backslashes by just
adding another one. I have added a pach to llvm\lib\Support\Windows which fixes
the problem, I didn't feel like messing around with c-strings like the rest of
that code does. If you feel strongly about it, I could also write a patch in
keeping with the c-style code and without unnecessary copies (though I don't
think that code is remotely performance critical)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130420/63741a8e/attachment.html>

From bugzilla-daemon at llvm.org  Sat Apr 20 20:18:53 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 21 Apr 2013 03:18:53 +0000
Subject: [LLVMbugs] [Bug 15803] New: __extension__ does not suppress
 pedantic warning for flexible array member in c89 mode
Message-ID: <bug-15803-206@http.llvm.org/bugs/>

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

            Bug ID: 15803
           Summary: __extension__ does not suppress pedantic warning for
                    flexible array member in c89 mode
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
          Assignee: unassignedclangbugs at nondot.org
          Reporter: crigler at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

This testcase produces a warning even though __extension__ is used.

clang -std=c89 -pedantic:

struct foo {
int len;
__extension__ char buf[];
};

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130421/a88d7d09/attachment.html>

From bugzilla-daemon at llvm.org  Sun Apr 21 02:47:40 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 21 Apr 2013 09:47:40 +0000
Subject: [LLVMbugs] [Bug 15801] illegal use of decltype in destructor
	silently accepted
In-Reply-To: <bug-15801-206@http.llvm.org/bugs/>
References: <bug-15801-206@http.llvm.org/bugs/>
Message-ID: <bug-15801-206-ze7GHydayn@http.llvm.org/bugs/>

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

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

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

--- Comment #1 from Anton Korobeynikov <asl at math.spbu.ru> ---
I'm seeing:

$ clang++ 1.cpp 
1.cpp:6:6: error: expected the class name after '~' to name a destructor
    ~decltype(*c)() { printf("DECLTYPE DESTROY\n"); }
     ^
1.cpp:6:16: error: C++ requires a type specifier for all declarations
    ~decltype(*c)() { printf("DECLTYPE DESTROY\n"); }
              ~^
1.cpp:10:8: error: expected ';' at end of declaration
    C c{};
       ^
       ;

So, fixed after 3.1

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130421/5df7cc38/attachment.html>

From bugzilla-daemon at llvm.org  Sun Apr 21 02:54:40 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 21 Apr 2013 09:54:40 +0000
Subject: [LLVMbugs] [Bug 9906] Clang incorrectly fails to detect nested
 struct in class definition with Boost.
In-Reply-To: <bug-9906-206@http.llvm.org/bugs/>
References: <bug-9906-206@http.llvm.org/bugs/>
Message-ID: <bug-9906-206-9DH3fVrCYd@http.llvm.org/bugs/>

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

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

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

--- Comment #1 from Anton Korobeynikov <asl at math.spbu.ru> ---
We do not produce error anymore here.

I have:

$ clang++ -v
Apple LLVM version 4.2 (clang-425.0.27) (based on LLVM 3.2svn)
Target: x86_64-apple-darwin11.4.2
Thread model: posix

Boost 1.51

Please reopen if something is still broken for you.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130421/1045b600/attachment.html>

From bugzilla-daemon at llvm.org  Sun Apr 21 02:59:26 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 21 Apr 2013 09:59:26 +0000
Subject: [LLVMbugs] [Bug 10759] clang crashes from gcc torture test
 g++.dg/overload/defrag1.C
In-Reply-To: <bug-10759-206@http.llvm.org/bugs/>
References: <bug-10759-206@http.llvm.org/bugs/>
Message-ID: <bug-10759-206-3IVi8A06OH@http.llvm.org/bugs/>

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

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

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

--- Comment #1 from Anton Korobeynikov <asl at math.spbu.ru> ---
Does not crash for me anymore:

$ clang++ defarg1.C 
defarg1.C:4:21: error: call to function 'foo' that is neither visible in the
template definition nor found by argument-dependent lookup
int foo (T t, int = foo(T()));
                    ^
defarg1.C:8:3: note: in instantiation of default function argument expression
for 'foo<int>' required here
  foo(0);                       // { dg-error "default argument" }
  ^
defarg1.C:4:5: note: 'foo' should be declared prior to the call site
int foo (T t, int = foo(T()));
    ^
1 error generated.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130421/5d3f7d29/attachment.html>

From bugzilla-daemon at llvm.org  Sun Apr 21 03:03:57 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 21 Apr 2013 10:03:57 +0000
Subject: [LLVMbugs] [Bug 15801] illegal use of decltype in destructor
	silently accepted
In-Reply-To: <bug-15801-206@http.llvm.org/bugs/>
References: <bug-15801-206@http.llvm.org/bugs/>
Message-ID: <bug-15801-206-YDlnx03Je3@http.llvm.org/bugs/>

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

Stefan van Kessel <van_kessel at freenet.de> changed:

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

--- Comment #2 from Stefan van Kessel <van_kessel at freenet.de> ---
I can still reproduce the error on the trunk (3.3).

clang++ 1.cpp -std=c++11

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130421/7166c02a/attachment.html>

From bugzilla-daemon at llvm.org  Sun Apr 21 03:03:59 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 21 Apr 2013 10:03:59 +0000
Subject: [LLVMbugs] [Bug 11781] clang segmentation fault
In-Reply-To: <bug-11781-206@http.llvm.org/bugs/>
References: <bug-11781-206@http.llvm.org/bugs/>
Message-ID: <bug-11781-206-OYlBNczpW1@http.llvm.org/bugs/>

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

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> ---
Closing. No testcase, no response.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130421/96df3ddf/attachment.html>

From bugzilla-daemon at llvm.org  Sun Apr 21 03:06:08 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 21 Apr 2013 10:06:08 +0000
Subject: [LLVMbugs] [Bug 11873] LLVM IR Code Generation Error
In-Reply-To: <bug-11873-206@http.llvm.org/bugs/>
References: <bug-11873-206@http.llvm.org/bugs/>
Message-ID: <bug-11873-206-Y2WLH2MKIX@http.llvm.org/bugs/>

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

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> ---
No testcase, no response. Closing.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130421/b914d4c9/attachment.html>

From bugzilla-daemon at llvm.org  Sun Apr 21 03:08:14 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 21 Apr 2013 10:08:14 +0000
Subject: [LLVMbugs] [Bug 11910] Storage-class extern inside function body on
 tentatively static symbols breaks later definitions
In-Reply-To: <bug-11910-206@http.llvm.org/bugs/>
References: <bug-11910-206@http.llvm.org/bugs/>
Message-ID: <bug-11910-206-5Roo06c185@http.llvm.org/bugs/>

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

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

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

--- Comment #2 from Anton Korobeynikov <asl at math.spbu.ru> ---
ToT correctly handles it.

First testcase compiles w/o error for me. Second yields:

$ clang 1.c
1.c:6:5: error: non-static declaration of 'var' follows static declaration
int var = 0;
    ^
1.c:1:12: note: previous definition is here
static int var;
           ^
1 error generated.


Please reopen is something is still broken

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130421/0da5e929/attachment.html>

From bugzilla-daemon at llvm.org  Sun Apr 21 05:47:02 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 21 Apr 2013 12:47:02 +0000
Subject: [LLVMbugs] [Bug 15804] New: crash with __is_trivially_constructible
 for class template
Message-ID: <bug-15804-206@http.llvm.org/bugs/>

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

            Bug ID: 15804
           Summary: crash with __is_trivially_constructible for class
                    template
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++11
          Assignee: unassignedclangbugs at nondot.org
          Reporter: hivemaster at hotmail.de
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 10393
  --> http://llvm.org/bugs/attachment.cgi?id=10393&action=edit
clang output

The following snippet crashes Clang:

template<class Iterator>
struct X{
  Iterator p;
  X() : p(Iterator()){}
};

static_assert(__is_trivially_constructible(X<int*>), "...");

int main(){}

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130421/b5ca7806/attachment.html>

From bugzilla-daemon at llvm.org  Sun Apr 21 09:33:10 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 21 Apr 2013 16:33:10 +0000
Subject: [LLVMbugs] [Bug 11709] va_list on ARM is different from AAPCS 7.1.4
In-Reply-To: <bug-11709-206@http.llvm.org/bugs/>
References: <bug-11709-206@http.llvm.org/bugs/>
Message-ID: <bug-11709-206-fZQsaToGiY@http.llvm.org/bugs/>

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

Saleem Abdulrasool <compnerd at compnerd.org> changed:

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

--- Comment #9 from Saleem Abdulrasool <compnerd at compnerd.org> ---
Yeah, ISTR that this was fixed a while back.  Marking as FIXED, someone can
re-open it if it isn't the case.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130421/d9c573a2/attachment.html>

From bugzilla-daemon at llvm.org  Sun Apr 21 09:57:35 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 21 Apr 2013 16:57:35 +0000
Subject: [LLVMbugs] [Bug 15805] New: lib/Transforms/Scalar/SROA.cpp:3058:
 Assertion `SI.getFalseValue() != OldPtr && "Pointer is both operands!"'
 failed
Message-ID: <bug-15805-206@http.llvm.org/bugs/>

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

            Bug ID: 15805
           Summary: lib/Transforms/Scalar/SROA.cpp:3058: Assertion
                    `SI.getFalseValue() != OldPtr && "Pointer is both
                    operands!"' failed
           Product: new-bugs
           Version: unspecified
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: antoine.balestrat at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Using LLVM/Clang as of 179981 :

$ cat point.c
int a, b;

void f(void)
{
    while(1);
}

void g(void)
{
    long c, *p = 0;

    f();

    while(c++)
        p = &c;

    b && (p = &c);
    a = a ? c : *p;
}

$ clong -O1 -w point.c
clang: /home/merkil/clang/llvm/lib/Transforms/Scalar/SROA.cpp:3058: bool
{anonymous}::AllocaPartitionRewriter::visitSelectInst(llvm::SelectInst&):
Assertion `SI.getFalseValue() != OldPtr && "Pointer is both operands!"' failed.
0  clang           0x0000000001d63352 llvm::sys::PrintStackTrace(_IO_FILE*) +
34
1  clang           0x0000000001d63071
2  libpthread.so.0 0x00007fad9a565030
3  libc.so.6       0x00007fad99653475 gsignal + 53
4  libc.so.6       0x00007fad996566f0 abort + 384
5  libc.so.6       0x00007fad9964c621 __assert_fail + 241
6  clang           0x00000000019c17aa
7  clang           0x00000000019c950a
8  clang           0x00000000019ca1a1
9  clang           0x00000000019ca6a5
10 clang           0x00000000019cd349
11 clang           0x00000000019cd546
12 clang           0x0000000001cfd61f
llvm::FPPassManager::runOnFunction(llvm::Function&) + 655
13 clang           0x0000000001abad16
14 clang           0x0000000001cfd147
llvm::MPPassManager::runOnModule(llvm::Module&) + 663
15 clang           0x0000000001cfd2ef llvm::PassManagerImpl::run(llvm::Module&)
+ 207
16 clang           0x00000000008f6372
clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::CodeGenOptions
const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::Module*,
clang::BackendAction, llvm::raw_ostream*) + 3458
17 clang           0x00000000008f3fef
18 clang           0x0000000000a572ba clang::ParseAST(clang::Sema&, bool, bool)
+ 538
19 clang           0x00000000008f277e clang::CodeGenAction::ExecuteAction() +
78
20 clang           0x000000000077b989 clang::FrontendAction::Execute() + 265
21 clang           0x000000000075deea
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 346
22 clang           0x0000000000745b12
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1794
23 clang           0x000000000073fe18 cc1_main(char const**, char const**, char
const*, void*) + 920
24 clang           0x0000000000733590 main + 7744
25 libc.so.6       0x00007fad9963fead __libc_start_main + 253
26 clang           0x000000000073f8d1
Stack dump:
0.    Program arguments: /home/merkil/clang/build/Release+Asserts/bin/clang
-cc1 -triple x86_64-unknown-linux-gnu -emit-obj -disable-free -main-file-name
point.c -mrelocation-model static -fmath-errno -masm-verbose
-mconstructor-aliases -munwind-tables -fuse-init-array -target-cpu x86-64
-target-linker-version 2.22 -momit-leaf-frame-pointer -resource-dir
/home/merkil/clang/build/Release+Asserts/bin/../lib/clang/3.3 -internal-isystem
/usr/local/include -internal-isystem
/home/merkil/clang/build/Release+Asserts/bin/../lib/clang/3.3/include
-internal-externc-isystem /usr/include/x86_64-linux-gnu
-internal-externc-isystem /include -internal-externc-isystem /usr/include -O1
-w -fdebug-compilation-dir /home/merkil/creduce/creduce -ferror-limit 19
-fmessage-length 0 -mstackrealign -fobjc-runtime=gcc
-fobjc-default-synthesize-properties -fdiagnostics-show-option -backend-option
-vectorize-loops -o /tmp/point-DEY8DY.o -x c point.c 
1.    <eof> parser at end of file
2.    Per-module optimization passes
3.    Running pass 'CallGraph Pass Manager' on module 'point.c'.
4.    Running pass 'SROA' on function '@g'
clang: error: unable to execute command: Aborted
clang: error: clang frontend command failed due to signal (use -v to see
invocation)
clang version 3.3 (trunk 179981)
Target: x86_64-unknown-linux-gnu
Thread model: posix

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130421/a60e3046/attachment.html>

From bugzilla-daemon at llvm.org  Sun Apr 21 10:48:53 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 21 Apr 2013 17:48:53 +0000
Subject: [LLVMbugs] [Bug 15805] lib/Transforms/Scalar/SROA.cpp:3058:
 Assertion `SI.getFalseValue() != OldPtr && "Pointer is both operands!"'
 failed
In-Reply-To: <bug-15805-206@http.llvm.org/bugs/>
References: <bug-15805-206@http.llvm.org/bugs/>
Message-ID: <bug-15805-206-d8phA24KrP@http.llvm.org/bugs/>

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

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> ---
Fixed in r179982.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130421/fa01f61f/attachment.html>

From bugzilla-daemon at llvm.org  Sun Apr 21 11:03:56 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 21 Apr 2013 18:03:56 +0000
Subject: [LLVMbugs] [Bug 15008] Assertion `C1->getType() == C2->getType() &&
 "Operand types in binary constant expression should match"' failed
In-Reply-To: <bug-15008-206@http.llvm.org/bugs/>
References: <bug-15008-206@http.llvm.org/bugs/>
Message-ID: <bug-15008-206-Xf4ZJUpuZs@http.llvm.org/bugs/>

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

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

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

--- Comment #4 from Benjamin Kramer <benny.kra at gmail.com> ---
Closing bug.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130421/b8ba8878/attachment.html>

From bugzilla-daemon at llvm.org  Sun Apr 21 11:04:04 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 21 Apr 2013 18:04:04 +0000
Subject: [LLVMbugs] [Bug 14749] UNREACHABLE executed: Cannot emit physreg
 copy instruction !
In-Reply-To: <bug-14749-206@http.llvm.org/bugs/>
References: <bug-14749-206@http.llvm.org/bugs/>
Message-ID: <bug-14749-206-gbRinL8yYP@http.llvm.org/bugs/>

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

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

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

--- Comment #3 from Benjamin Kramer <benny.kra at gmail.com> ---
Closing bug.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130421/790ae6cb/attachment.html>

From bugzilla-daemon at llvm.org  Sun Apr 21 11:06:52 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 21 Apr 2013 18:06:52 +0000
Subject: [LLVMbugs] [Bug 14544] Assertion `isa<X>(Val) && "cast<Ty>()
 argument of incompatible type!"' failed in Loop Vectorization
In-Reply-To: <bug-14544-206@http.llvm.org/bugs/>
References: <bug-14544-206@http.llvm.org/bugs/>
Message-ID: <bug-14544-206-qkesYXzcAi@http.llvm.org/bugs/>

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

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

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

--- Comment #1 from Benjamin Kramer <benny.kra at gmail.com> ---
The loop vectorizer was still in early stages when this bug was filed. It works
a lot better now and I can't reproduce the crash with trunk.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130421/69076b51/attachment.html>

From bugzilla-daemon at llvm.org  Sun Apr 21 11:07:03 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 21 Apr 2013 18:07:03 +0000
Subject: [LLVMbugs] [Bug 14546] "Instruction does not dominate all uses" in
 Loop Vectorization
In-Reply-To: <bug-14546-206@http.llvm.org/bugs/>
References: <bug-14546-206@http.llvm.org/bugs/>
Message-ID: <bug-14546-206-DhnrHrv4Dr@http.llvm.org/bugs/>

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

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

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

--- Comment #2 from Benjamin Kramer <benny.kra at gmail.com> ---
The loop vectorizer was still in early stages when this bug was filed. It works
a lot better now and I can't reproduce the crash with trunk.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130421/5ac25460/attachment.html>

From bugzilla-daemon at llvm.org  Sun Apr 21 15:35:56 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 21 Apr 2013 22:35:56 +0000
Subject: [LLVMbugs] [Bug 15806] New: Naked attribute still has return
	statement
Message-ID: <bug-15806-206@http.llvm.org/bugs/>

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

            Bug ID: 15806
           Summary: Naked attribute still has return statement
           Product: tools
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: llc
          Assignee: unassignedbugs at nondot.org
          Reporter: rkotler at mips.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

when the naked function attribute is present, there should be no return
statement.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130421/f17d9d99/attachment.html>

From bugzilla-daemon at llvm.org  Sun Apr 21 16:57:07 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 21 Apr 2013 23:57:07 +0000
Subject: [LLVMbugs] [Bug 15807] New: Segfault in llvm-tblgen for
 ARMGenAsmMatcher prevents compilation of 3.2 and 3.3 trunk
Message-ID: <bug-15807-206@http.llvm.org/bugs/>

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

            Bug ID: 15807
           Summary: Segfault in llvm-tblgen for ARMGenAsmMatcher prevents
                    compilation of 3.2 and 3.3 trunk
           Product: libraries
           Version: trunk
          Hardware: Other
                OS: other
            Status: NEW
          Severity: release blocker
          Priority: P
         Component: MC
          Assignee: unassignedbugs at nondot.org
          Reporter: s_bugzilla at nedprod.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Tried building clang + LLVM release 3.2 and trunk 3.3. Both fail with this
issue.

My configuration: Samsung ARM Chromebook running Ubuntu inside a chroot via
crouton.


Configure used: ./configure --build=armv7l-unknown-linux-gnueabihf \
--host=armv7l-unknown-linux-gnueabihf \
--target=armv7l-unknown-linux-gnueabihf --with-cpu=cortex-a9 \
--with-float=hard --with-abi=aapcs-vfp --with-fpu=neon \
--enable-targets=arm --enable-optimized --enable-assertions


Segfaults here in build process:
make[3]: Leaving directory `/home/ned/clang-3.2-staging/lib/MC/MCDisassembler'
make[2]: Leaving directory `/home/ned/clang-3.2-staging/lib/MC'
Stack dump:
0.      Program arguments:
/home/ned/clang-3.2-staging/Release+Asserts/bin/llvm-tblgen -I
/home/ned/llvm-3.2.src/lib/Target/ARM -I /home/ned/llvm-3.2.
src/include -I /home/ned/llvm-3.2.src/include -I
/home/ned/llvm-3.2.src/lib/Target -gen-asm-matcher -o
/home/ned/clang-3.2-staging/lib/Target/ARM/Rele
ase+Asserts/ARMGenAsmMatcher.inc.tmp
/home/ned/llvm-3.2.src/lib/Target/ARM/ARM.td 
make[3]: ***
[/home/ned/clang-3.2-staging/lib/Target/ARM/Release+Asserts/ARMGenAsmMatcher.inc.tmp]
Segmentation fault (core dumped)
make[3]: Target `all' not remade because of errors.
make[3]: Target `all' not remade because of errors.


Running gdb on this yields:
GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2.1) 7.4-2012.04
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "arm-linux-gnueabihf".
For bug reporting instructions, please see:
<http://bugs.launchpad.net/gdb-linaro/>...
Reading symbols from
/home/ned/clang-3.2-staging/Release+Asserts/bin/llvm-tblgen...(no debugging
symbols found)...done.
(gdb) run
Starting program: /home/ned/clang-3.2-staging/Release+Asserts/bin/llvm-tblgen
-I=/home/ned/llvm-3.2.src/lib/Target/ARM -I=/home/ned/llvm-3.2.src/inclu
de -I=/home/ned/llvm-3.2.src/include -I=/home/ned/llvm-3.2.src/lib/Target
-gen-asm-matcher -o /home/ned/clang-3.2-staging/lib/Target/ARM/Release+Asser
ts/ARMGenAsmMatcher.inc.tmp /home/ned/llvm-3.2.src/lib/Target/ARM/ARM.td
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
Program received signal SIGSEGV, Segmentation fault.
0x001ca860 in llvm::StringRef::lower() const ()
(gdb) bt
#0  0x001ca860 in llvm::StringRef::lower() const ()
#1  0x0002c1dc in (anonymous namespace)::MatchableInfo::initialize((anonymous
namespace)::AsmMatcherInfo const&, llvm::SmallPtrSet<llvm::Record*, 16u>
&, int, std::string&) ()
#2  0x0001aae8 in (anonymous namespace)::AsmMatcherInfo::buildInfo() ()
#3  0x0000b9a4 in (anonymous
namespace)::AsmMatcherEmitter::run(llvm::raw_ostream&) ()
#4  0x0000b858 in llvm::EmitAsmMatcher(llvm::RecordKeeper&, llvm::raw_ostream&)
()
#5  0x0014a340 in (anonymous namespace)::LLVMTableGenMain(llvm::raw_ostream&,
llvm::RecordKeeper&) ()
#6  0x0015bd24 in llvm::TableGenMain(char*, bool (*)(llvm::raw_ostream&,
llvm::RecordKeeper&)) ()
#7  0x0014a22c in main ()
(gdb) 


Not sure what's gone wrong here. Could be a weirdness in the Chromebook kernel,
could be the chroot, could be something ARM-specific.

I attach a core dump for your information.

Niall

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130421/4190c5bb/attachment.html>

From bugzilla-daemon at llvm.org  Sun Apr 21 17:44:35 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 22 Apr 2013 00:44:35 +0000
Subject: [LLVMbugs] [Bug 15808] New: clang crashes when compiling template
Message-ID: <bug-15808-206@http.llvm.org/bugs/>

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

            Bug ID: 15808
           Summary: clang crashes when compiling template
           Product: clang
           Version: 3.2
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
          Assignee: unassignedclangbugs at nondot.org
          Reporter: llvmbugs-9floo at rtdt.eu
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 10395
  --> http://llvm.org/bugs/attachment.cgi?id=10395&action=edit
reduced example file to trigger bug

Not sure if this is a bug. When compiling broken code clang crashes.
Works if line is changed to "struct foo<T> *temp = new struct foo<T>;"

console output:
###############################
clang: SemaTemplateInstantiate.cpp:2683: llvm::PointerUnion<clang::Decl*,
llvm::SmallVector<clang::Decl*, 4u>*>*
clang::LocalInstantiationScope::findInstantiationOf(const clang::Decl*):
Assertion `isa<LabelDecl>(D) && "declaration not instantiated in this scope"'
failed.
0  clang     0x09e87d18
1  clang     0x09e88284
2            0xb77b3400 __kernel_sigreturn + 0
3            0xb77b3424 __kernel_vsyscall + 16
4  libc.so.6 0xb750e941 gsignal + 81
5  libc.so.6 0xb7511d72 abort + 386
6  libc.so.6 0xb7507b58 __assert_fail + 248
7  clang     0x08a79219
clang::LocalInstantiationScope::findInstantiationOf(clang::Decl const*) + 425
Stack dump:
0.      Program arguments: /llvm/llvm-3.2.src/Release+Asserts/bin-array
-target-cpu pentium4 -target-linker-version 2.22
-momit-leaf-frame-pointeclude/c++/4.7 -internal-isystem
/usr/lib/gcc/i486-linux-gnu/4.7/../../../../inclsrc/Release+Asserts/bin/../lib/clang/3.2/include
-internal-externc-isystem /usr/ -fobjc-runtime=gcc -fcxx-exceptions
-fexceptions -fdiagnostics-show-option -fco
1.      <eof> parser at end of file
2.      a.cpp:8:3: instantiating function definition 'a'
clang: error: unable to execute command: Aborted
clang: error: clang frontend command failed due to signal (use -v to see
invocat
clang version 3.2 (tags/RELEASE_32/final)
Target: i386-pc-linux-gnu
Thread model: posix
clang: note: diagnostic msg: PLEASE submit a bug report to
http://llvm.org/bugs/
clang: note: diagnostic msg: 
********************

PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang: note: diagnostic msg: /tmp/a-z2Qjxz.cpp
clang: note: diagnostic msg: /tmp/a-z2Qjxz.sh
clang: note: diagnostic msg: 

********************

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130422/ed9d9b4a/attachment.html>

From bugzilla-daemon at llvm.org  Sun Apr 21 18:43:47 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 22 Apr 2013 01:43:47 +0000
Subject: [LLVMbugs] [Bug 15809] New: Optimization: Failure to recognize
 right shift will result in either 0 or 1.
Message-ID: <bug-15809-206@http.llvm.org/bugs/>

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

            Bug ID: 15809
           Summary: Optimization: Failure to recognize right shift will
                    result in either 0 or 1.
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Scalar Optimizations
          Assignee: unassignedbugs at nondot.org
          Reporter: silvas at purdue.edu
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 10397
  --> http://llvm.org/bugs/attachment.cgi?id=10397&action=edit
test_bitmap.c

(all of this is with clang -O2 at r179948)

The code for `test_bitmap_ternary` is 5 bytes smaller than `test_bitmap_shift`,
2 instructions shorter, and avoids 2 non-immediate shifts (possibly just 1 on
architectures that don't have something like x86 BT). I think the issue is a
failure to recognize that there is only one set bit, so shifting back by the
same amount gives exactly either 0 or 1.

int test_bitmap_ternary(int shift, int bitmap)
{
    return ((1 << shift) & bitmap) ? 1 : 0;
}

int test_bitmap_shift(int shift, int bitmap)
{
    return ((1 << shift) & bitmap) >> shift;
}

The problem is exacerbated with some more decoration (adding !! doesn't affect
the codegen for `test_bitmap_ternary`):

int test_bitmap_shift_notnot(int shift, int bitmap)
{
    return !!(((1 << shift) & bitmap) >> shift);
}


define i32 @test_bitmap_ternary(i32 %shift, i32 %bitmap) #0 {
  %1 = shl i32 1, %shift
  %2 = and i32 %1, %bitmap
  %3 = icmp ne i32 %2, 0
  %4 = zext i1 %3 to i32
  ret i32 %4
}

define i32 @test_bitmap_shift(i32 %shift, i32 %bitmap) #0 {
  %1 = shl i32 1, %shift
  %2 = and i32 %1, %bitmap
  %3 = ashr i32 %2, %shift
  ret i32 %3
}

define i32 @test_bitmap_shift_notnot(i32 %shift, i32 %bitmap) #0 {
  %1 = shl i32 1, %shift
  %2 = and i32 %1, %bitmap
  %3 = ashr i32 %2, %shift
  %4 = icmp ne i32 %3, 0
  %5 = zext i1 %4 to i32
  ret i32 %5
}


0000000000000050 <test_bitmap_ternary>:
  50:   0f a3 fe                bt     %edi,%esi
  53:   19 c0                   sbb    %eax,%eax
  55:   83 e0 01                and    $0x1,%eax
  58:   c3                      retq   

0000000000000060 <test_bitmap_shift>:
  60:   89 f9                   mov    %edi,%ecx
  62:   b8 01 00 00 00          mov    $0x1,%eax
  67:   d3 e0                   shl    %cl,%eax
  69:   21 f0                   and    %esi,%eax
  6b:   d3 f8                   sar    %cl,%eax
  6d:   c3                      retq   

0000000000000060 <test_bitmap_shift_notnot>:
  60:   89 f9                   mov    %edi,%ecx
  62:   b8 01 00 00 00          mov    $0x1,%eax
  67:   d3 e0                   shl    %cl,%eax
  69:   21 f0                   and    %esi,%eax
  6b:   d3 f8                   sar    %cl,%eax
  6d:   85 c0                   test   %eax,%eax
  6f:   0f 95 c0                setne  %al
  72:   0f b6 c0                movzbl %al,%eax
  75:   c3                      retq

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130422/0ae41b78/attachment.html>

From bugzilla-daemon at llvm.org  Sun Apr 21 19:32:14 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 22 Apr 2013 02:32:14 +0000
Subject: [LLVMbugs] [Bug 15810] New: _xgetbv not declared
Message-ID: <bug-15810-206@http.llvm.org/bugs/>

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

            Bug ID: 15810
           Summary: _xgetbv not declared
           Product: new-bugs
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: jeffrey.beu.uz8yz6yl at hotmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Hello,

Within

Function: static bool OSHasAVXSupport()
Line : 122
File: llvm\lib\Support\Host.cpp

the conclusion of the premise 
#elif defined(_MSC_FULL_VER) && _MSC_FULL_VER >= 160040219 
doesn't appear to be true on my computer. It results in the typical not
declared error. This error results in failed builds for many other components -
I think due to the tablegen program not being built.

Given my version of Visual Studio 2010 is 160040219 I simply removed the = in
>= and everything seemed to compile fine thereafter.

It could be possible the error is localised to my Machine however MSDN doesn't
have xgetbv listed under
VS2010(http://msdn.microsoft.com/en-us/library/azcs88h2%28v=vs.100%29.aspx) but
is does for VS2012(http://msdn.microsoft.com/en-us/library/hh977022.aspx). Also
a quick grep of my include directories doesn't find any matches either. This
leads me to have some confidence it is not localised to my machine.

Thanks for the great work.

Jeff Beu

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130422/ab77f4fd/attachment.html>

From bugzilla-daemon at llvm.org  Sun Apr 21 20:03:39 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 22 Apr 2013 03:03:39 +0000
Subject: [LLVMbugs] [Bug 15811] New: DependenceAnalysis is not access size
	aware.
Message-ID: <bug-15811-206@http.llvm.org/bugs/>

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

            Bug ID: 15811
           Summary: DependenceAnalysis is not access size aware.
           Product: libraries
           Version: trunk
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Global Analyses
          Assignee: unassignedbugs at nondot.org
          Reporter: etherzhhb at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 10398
  --> http://llvm.org/bugs/attachment.cgi?id=10398&action=edit
The patch to add the fail case.

Consider the following function:

define i64 @alias(i32* nocapture %A) nounwind uwtable {
entry:
  %arrayidx = getelementptr inbounds i32* %A, i64 1
  store i32 2, i32* %arrayidx, align 4
  %0 = bitcast i32* %A to i64*
  %1 = load i64* %0, align 8
  ret i64 %1
}

Ignoring size of the memory location accessed in
store i32 2, i32* %arrayidx, align 4
and
%1 = load i64* %0, align 8,

The addresses pointed by %arrayidx and %0 doesn't alias each other, and hence
DependenceAnalysis claims there is not dependencies from the store to the load,
and gives the following output:
da analyze - none!
da analyze - none!
da analyze - none!

However, the above result is incorrect (at least for x86), there should be a
dependency from from the store to the load, because the memory location written
by the store overlap with the memory location read by the load.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130422/81ed1f52/attachment.html>

From bugzilla-daemon at llvm.org  Sun Apr 21 23:06:16 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 22 Apr 2013 06:06:16 +0000
Subject: [LLVMbugs] [Bug 8717] LLVM MC does not know how to handle
	.subsection derective
In-Reply-To: <bug-8717-206@http.llvm.org/bugs/>
References: <bug-8717-206@http.llvm.org/bugs/>
Message-ID: <bug-8717-206-CoeQBGR40O@http.llvm.org/bugs/>

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

Peter Collingbourne <peter at pcc.me.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |peter at pcc.me.uk
         Resolution|---                         |FIXED

--- Comment #9 from Peter Collingbourne <peter at pcc.me.uk> ---
Fixed in r179725.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130422/e8ee987f/attachment.html>

From bugzilla-daemon at llvm.org  Mon Apr 22 01:22:41 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 22 Apr 2013 08:22:41 +0000
Subject: [LLVMbugs] [Bug 15812] New: Need an ASTMatcher that ignores
 implicit casts, parentheses, and CXX construct expressions
Message-ID: <bug-15812-206@http.llvm.org/bugs/>

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

            Bug ID: 15812
           Summary: Need an ASTMatcher that ignores implicit casts,
                    parentheses, and CXX construct expressions
           Product: clang
           Version: unspecified
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: eisinger at google.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

I'm trying to write an AST matcher for a return statement where the actual
return type is a class, and so the AST includes not only ImplicitCastExpr and
MaterializeTemporaryExpr, but also CXXConstructExpr

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130422/372a32f3/attachment.html>

From bugzilla-daemon at llvm.org  Mon Apr 22 04:14:03 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 22 Apr 2013 11:14:03 +0000
Subject: [LLVMbugs] [Bug 15814] New: rvalue references with template static
	initializers
Message-ID: <bug-15814-206@http.llvm.org/bugs/>

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

            Bug ID: 15814
           Summary: rvalue references with template static initializers
           Product: clang
           Version: 3.2
          Hardware: PC
                OS: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
          Assignee: unassignedclangbugs at nondot.org
          Reporter: alexey.frolov at intel.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 10403
  --> http://llvm.org/bugs/attachment.cgi?id=10403&action=edit
Preprocessed source and associated run script

$ clang++ -c   -O2  -std=c++0x source.cpp

0  clang++           0x000000010fd1f925 PrintStackTrace(void*) + 37
1  clang++           0x000000010fd1fdc4 SignalHandler(int) + 564
2  libsystem_c.dylib 0x00007fff8fa658ea _sigtramp + 26
3  libsystem_c.dylib 0x00007f97a34fc080 _sigtramp + 18446743627362822064
4  clang++           0x000000010fd1fb76 abort + 22
5  clang++           0x000000010fd1fb51 __assert_rtn + 81
6  clang++           0x000000010f328992
clang::Expr::EvaluateKnownConstInt(clang::ASTContext const&) const + 210
7  clang++           0x000000010f31a84a
clang::Expr::isNullPointerConstant(clang::ASTContext&,
clang::Expr::NullPointerConstantValueDependence) const + 1242
8  clang++           0x000000010ec5ca7b (anonymous
namespace)::CheckImplicitConversion(clang::Sema&, clang::Expr*,
clang::QualType, clang::SourceLocation, bool*) + 2075
9  clang++           0x000000010ec5796f (anonymous
namespace)::AnalyzeImplicitConversions(clang::Sema&, clang::Expr*,
clang::SourceLocation) + 703
10 clang++           0x000000010ec57bed (anonymous
namespace)::AnalyzeImplicitConversions(clang::Sema&, clang::Expr*,
clang::SourceLocation) + 1341
11 clang++           0x000000010ecbdc17
clang::Sema::AddInitializerToDecl(clang::Decl*, clang::Expr*, bool, bool) +
3799
12 clang++           0x000000010eece5bd
clang::TemplateDeclInstantiator::VisitVarDecl(clang::VarDecl*) + 1581
13 clang++           0x000000010eed9382
clang::Sema::InstantiateStaticDataMemberDefinition(clang::SourceLocation,
clang::VarDecl*, bool, bool) + 1570
14 clang++           0x000000010eefa389
clang::Sema::RequireCompleteExprType(clang::Expr*, clang::Sema::TypeDiagnoser&)
+ 345
15 clang++           0x000000010ed49a87
clang::Sema::CheckUnaryExprOrTypeTraitOperand(clang::Expr*,
clang::UnaryExprOrTypeTrait) + 279
16 clang++           0x000000010ed4a717
clang::Sema::CreateUnaryExprOrTypeTraitExpr(clang::Expr*,
clang::SourceLocation, clang::UnaryExprOrTypeTrait) + 439
17 clang++           0x000000010ed4aaaf
clang::Sema::ActOnUnaryExprOrTypeTraitExpr(clang::SourceLocation,
clang::UnaryExprOrTypeTrait, bool, void*, clang::SourceRange const&) + 95
18 clang++           0x000000010eb98c0a
clang::Parser::ParseUnaryExprOrTypeTraitExpression() + 730
19 clang++           0x000000010eb929ca
clang::Parser::ParseCastExpression(bool, bool, bool&,
clang::Parser::TypeCastState) + 1786
20 clang++           0x000000010eb8fa77
clang::Parser::ParseAssignmentExpression(clang::Parser::TypeCastState) + 135
21 clang++           0x000000010eb73673
clang::Parser::ParseDeclarationAfterDeclaratorAndAttributes(clang::Declarator&,
clang::Parser::ParsedTemplateInfo const&) + 1971
22 clang++           0x000000010eb71da8
clang::Parser::ParseDeclGroup(clang::ParsingDeclSpec&, unsigned int, bool,
clang::SourceLocation*, clang::Parser::ForRangeInit*) + 1656
23 clang++           0x000000010ebe6ad7
clang::Parser::ParseDeclOrFunctionDefInternal(clang::Parser::ParsedAttributesWithRange&,
clang::ParsingDeclSpec&, clang::AccessSpecifier) + 679
24 clang++           0x000000010ebe652f
clang::Parser::ParseDeclarationOrFunctionDefinition(clang::Parser::ParsedAttributesWithRange&,
clang::ParsingDeclSpec*, clang::AccessSpecifier) + 351
25 clang++           0x000000010ebe5a17
clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&,
clang::ParsingDeclSpec*) + 3223
26 clang++           0x000000010ebe4d04
clang::Parser::ParseTopLevelDecl(clang::OpaquePtr<clang::DeclGroupRef>&) + 308
27 clang++           0x000000010eb64a16 clang::ParseAST(clang::Sema&, bool,
bool) + 438
28 clang++           0x000000010eb26468 clang::CodeGenAction::ExecuteAction() +
520
29 clang++           0x000000010e91415d clang::FrontendAction::Execute() + 109
30 clang++           0x000000010e8f4c5d
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 957
31 clang++           0x000000010e8b968d
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 3645
32 clang++           0x000000010e8b0f15 cc1_main(char const**, char const**,
char const*, void*) + 725
33 clang++           0x000000010e8b5c25 main + 3077
34 clang++           0x000000010e8b0c34 start + 52
Stack dump:
0.      Program arguments:
/Volumes/Export/users/alexfrol/workspaces/ws_iclang/dev/build_objs/efi2mac_debug/bin/clang++
-cc1 -triple x86_64-apple-macosx10.8.0 -emit-obj -disable-free -main-file-name
source.cpp -mrelocation-model pic -pic-level 2 -mdisable-fp-elim -masm-verbose
-munwind-tables -target-cpu core2 -target-linker-version 134.9 -coverage-file
/Volumes/Export/users/alexfrol/tc/iclang/r_value_referencesCpp/source.o
-resource-dir
/Volumes/Export/users/alexfrol/workspaces/ws_iclang/dev/build_objs/efi2mac_debug/bin/lib/clang/3.2
-fmodule-cache-path
/var/folders/zz/zyxvpxvq6csfxvn_n01bt3xw0_yhzg/T/clang-module-cache -O2
-std=c++0x -fdeprecated-macro -fdebug-compilation-dir
/nfs/ims/home/alexfrol/workspace/tc/iclang/r_value_referencesCpp -ferror-limit
19 -fmessage-length 120 -stack-protector 1 -mstackrealign -fblocks
-fobjc-runtime=macosx-10.8.0 -fobjc-dispatch-method=mixed
-fobjc-default-synthesize-properties -fencode-extended-block-signature
-fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o
source.o -x c++ source.cpp
1.      source.cpp:15:39: current parser token '/'
clang++: error: unable to execute command: Illegal instruction: 4
clang++: error: clang frontend command failed due to signal (use -v to see
invocation)
Intel(R) Compiler based on clang version 3.2 (trunk 260) (based on LLVM 3.2svn)
Target: x86_64-apple-darwin12.2.0
Thread model: posix
clang++: note: diagnostic msg: PLEASE submit a bug report to
http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and
associated run script.
clang++: note: diagnostic msg:

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130422/0654a713/attachment.html>

From bugzilla-daemon at llvm.org  Mon Apr 22 05:20:30 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 22 Apr 2013 12:20:30 +0000
Subject: [LLVMbugs] [Bug 15806] Naked attribute still has return statement
In-Reply-To: <bug-15806-206@http.llvm.org/bugs/>
References: <bug-15806-206@http.llvm.org/bugs/>
Message-ID: <bug-15806-206-bFXQVQBy0M@http.llvm.org/bugs/>

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

Duncan Sands <baldrick at free.fr> changed:

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

--- Comment #4 from Duncan Sands <baldrick at free.fr> ---
Every LLVM IR function definition is required to contain at least one basic
block.  Every basic block is required to end with a terminator instruction. 
Thus every function contains at least one instruction.  There is no way to have
a "null function" at the IR level.  All kinds of places in LLVM (eg just about
every optimizer) depend on this invariant, so it isn't going to change.

Maybe you can have your inline asm take care of control flow itself, i.e. just
explicitly put the instructions that should be run at the end of the function
in the inline asm?  If there is an extraneous "ret" instruction following that
code, it should then be harmless.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130422/d6f62216/attachment.html>

From bugzilla-daemon at llvm.org  Mon Apr 22 06:09:31 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 22 Apr 2013 13:09:31 +0000
Subject: [LLVMbugs] [Bug 15815] New: MS Compatibility: add support for
	__wchar_t
Message-ID: <bug-15815-206@http.llvm.org/bugs/>

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

            Bug ID: 15815
           Summary: MS Compatibility: add support for __wchar_t
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
          Assignee: unassignedclangbugs at nondot.org
          Reporter: hans at chromium.org
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Add support for the __wchar_t builtin type.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130422/e6b4e2d0/attachment.html>

From bugzilla-daemon at llvm.org  Mon Apr 22 07:11:20 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 22 Apr 2013 14:11:20 +0000
Subject: [LLVMbugs] [Bug 11869] `extern "C" extern void foo();
	` shouldn't compile
In-Reply-To: <bug-11869-206@http.llvm.org/bugs/>
References: <bug-11869-206@http.llvm.org/bugs/>
Message-ID: <bug-11869-206-VRwpDLsXkn@http.llvm.org/bugs/>

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

Timur Iskhodzhanov <timurrrr at google.com> changed:

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

--- Comment #3 from Timur Iskhodzhanov <timurrrr at google.com> ---
Yes, thanks!

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130422/84ae5065/attachment.html>

From bugzilla-daemon at llvm.org  Mon Apr 22 07:12:37 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 22 Apr 2013 14:12:37 +0000
Subject: [LLVMbugs] [Bug 15818] New: Regression afer commit 179786
 (InstCombiner::visitExtractElementInst() enhancement)
Message-ID: <bug-15818-206@http.llvm.org/bugs/>

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

            Bug ID: 15818
           Summary: Regression afer commit 179786
                    (InstCombiner::visitExtractElementInst() enhancement)
           Product: new-bugs
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: babokin at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 10404
  --> http://llvm.org/bugs/attachment.cgi?id=10404&action=edit
Reproducer

> llvm-as instcombine_bug.ll
> opt -instcombine instcombine_bug.bc -disable-output
Instruction does not dominate all uses!
  %sub_b_load28_to_int32_ = add i32 %b_load28_to_int32, -2
  %0 = extractelement <8 x float> %floatval.i.i, i32 %sub_b_load28_to_int32_
Broken module found, compilation aborted!
0  opt             0x00000000012219c2 llvm::sys::PrintStackTrace(_IO_FILE*) +
34
1  opt             0x0000000001221619
2  libpthread.so.0 0x00000037eb40efe0
3  libc.so.6       0x00000037eac35935 gsignal + 53
4  libc.so.6       0x00000037eac370e8 abort + 328
5  opt             0x00000000011d5e96
6  opt             0x00000000011deab2
7  opt             0x00000000011bcc7f
llvm::FPPassManager::runOnFunction(llvm::Function&) + 655
8  opt             0x00000000011bcccb
llvm::FPPassManager::runOnModule(llvm::Module&) + 43
9  opt             0x00000000011bc777
llvm::MPPassManager::runOnModule(llvm::Module&) + 663
10 opt             0x00000000011bc937 llvm::PassManagerImpl::run(llvm::Module&)
+ 231
11 opt             0x00000000005762b4 main + 3716
12 libc.so.6       0x00000037eac21735 __libc_start_main + 245
13 opt             0x0000000000586ca5
Stack dump:
0.      Program arguments: opt -instcombine instcombine_bug.bc -disable-output
1.      Running pass 'Function Pass Manager' on module 'instcombine_bug.bc'.
2.      Running pass 'Module Verifier' on function
'@f_fu___un_3C_unf_3E_un_3C_unf_3E_unf'
Aborted (core dumped)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130422/2b50d99b/attachment.html>

From bugzilla-daemon at llvm.org  Mon Apr 22 07:23:20 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 22 Apr 2013 14:23:20 +0000
Subject: [LLVMbugs] [Bug 15819] New: Poor recovery for use of unknown
	identifier
Message-ID: <bug-15819-206@http.llvm.org/bugs/>

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

            Bug ID: 15819
           Summary: Poor recovery for use of unknown identifier
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
          Assignee: unassignedclangbugs at nondot.org
          Reporter: richard-llvm at metafoo.co.uk
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified

<stdin>:1:29: error: unknown type name 'B'
struct A {}; void f() { A x(B); }
                            ^
<stdin>:1:28: warning: parentheses were disambiguated as a function declaration
[-Wvexing-parse]
struct A {}; void f() { A x(B); }
                           ^~~
<stdin>:1:29: note: add a pair of parentheses to declare a variable
struct A {}; void f() { A x(B); }
                            ^
                            ( )

Um. What. The first diagnostic is bad -- we should be expecting 'B' to be a
variable, not a type, here, because a function declaration at block scope is
very unlikely.

The second diagnostic is very bad. I'm not sure whether we kept the type or
dropped it, but either way, we shouldn't issue this diagnostic if we had a
parse error in the declaration. The note is also broken -- observe that it
suggests adding the close-paren after the existing close-paren, not before it
where it belongs.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130422/ef55d0a2/attachment.html>

From bugzilla-daemon at llvm.org  Mon Apr 22 07:45:41 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 22 Apr 2013 14:45:41 +0000
Subject: [LLVMbugs] [Bug 15820] New: libcxx "make install" should not
	require rsync
Message-ID: <bug-15820-206@http.llvm.org/bugs/>

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

            Bug ID: 15820
           Summary: libcxx "make install" should not require rsync
           Product: libc++
           Version: unspecified
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: All Bugs
          Assignee: hhinnant at apple.com
          Reporter: emikulic at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130422/712c1b0f/attachment.html>

From bugzilla-daemon at llvm.org  Mon Apr 22 08:57:51 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 22 Apr 2013 15:57:51 +0000
Subject: [LLVMbugs] [Bug 15807] Segfault in llvm-tblgen for ARMGenAsmMatcher
 prevents compilation of 3.2 and 3.3 trunk
In-Reply-To: <bug-15807-206@http.llvm.org/bugs/>
References: <bug-15807-206@http.llvm.org/bugs/>
Message-ID: <bug-15807-206-4T2Msu0eV3@http.llvm.org/bugs/>

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

Niall Douglas <s_bugzilla at nedprod.com> changed:

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

--- Comment #5 from Niall Douglas <s_bugzilla at nedprod.com> ---
Ah okay. I figured if it was supplied by Ubuntu it was expected to work. No
chance of an assert(I am not running on ARM hf) for the 3.0 branch? :)

I guess bug closed as wontfix. Thanks for the help.

Niall

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130422/570b288e/attachment.html>

From bugzilla-daemon at llvm.org  Mon Apr 22 10:07:37 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 22 Apr 2013 17:07:37 +0000
Subject: [LLVMbugs] [Bug 14965] Better error message for GEP with partially
 defined contents
In-Reply-To: <bug-14965-206@http.llvm.org/bugs/>
References: <bug-14965-206@http.llvm.org/bugs/>
Message-ID: <bug-14965-206-drmDd4K11X@http.llvm.org/bugs/>

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

Eli Bendersky <eliben at gmail.com> changed:

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

--- Comment #2 from Eli Bendersky <eliben at gmail.com> ---
Fix committed in r180030

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130422/ea790dec/attachment.html>

From bugzilla-daemon at llvm.org  Mon Apr 22 11:44:03 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 22 Apr 2013 18:44:03 +0000
Subject: [LLVMbugs] [Bug 9344] ARM sub-architecture support
In-Reply-To: <bug-9344-206@http.llvm.org/bugs/>
References: <bug-9344-206@http.llvm.org/bugs/>
Message-ID: <bug-9344-206-33OVZKYPoG@http.llvm.org/bugs/>

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

Renato Golin <renato.golin at linaro.org> changed:

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

--- Comment #4 from Renato Golin <renato.golin at linaro.org> ---
Closing this bug as it's not an issue any more for a while.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130422/6f72d66e/attachment.html>

From bugzilla-daemon at llvm.org  Mon Apr 22 12:10:55 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 22 Apr 2013 19:10:55 +0000
Subject: [LLVMbugs] [Bug 15802] On windows %INCLUDE% ending in \ leads to
 clang hanging when trying to kick of new process
In-Reply-To: <bug-15802-206@http.llvm.org/bugs/>
References: <bug-15802-206@http.llvm.org/bugs/>
Message-ID: <bug-15802-206-yKCgW7ynah@http.llvm.org/bugs/>

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

reid.kleckner at gmail.com <reid.kleckner at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED
           Assignee|unassignedclangbugs at nondot. |reid.kleckner at gmail.com
                   |org                         |

--- Comment #4 from reid.kleckner at gmail.com <reid.kleckner at gmail.com> ---
Right, as well as before any quote in the original string.

I implemented that in r180035, and your test case works for me with clang now.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130422/bf5c542f/attachment.html>

From bugzilla-daemon at llvm.org  Mon Apr 22 12:42:19 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 22 Apr 2013 19:42:19 +0000
Subject: [LLVMbugs] [Bug 15247] [BBVectorizer] Possible regression of
 vectorization of Linpack on ARM
In-Reply-To: <bug-15247-206@http.llvm.org/bugs/>
References: <bug-15247-206@http.llvm.org/bugs/>
Message-ID: <bug-15247-206-yR0PV3APcc@http.llvm.org/bugs/>

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

Renato Golin <renato.golin at linaro.org> changed:

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

--- Comment #7 from Renato Golin <renato.golin at linaro.org> ---
The difference in performance between GCC and Clang is that Clang defaults to
Cortex-A8 and doesn't do all the optimizations that A9 allows. If I specify
-mcpu=cortex-a9 on the command line, the performances are statistically
identical.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130422/fb039329/attachment.html>

From bugzilla-daemon at llvm.org  Mon Apr 22 12:44:12 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 22 Apr 2013 19:44:12 +0000
Subject: [LLVMbugs] [Bug 15620] fpcmp skews lines in comparison
In-Reply-To: <bug-15620-206@http.llvm.org/bugs/>
References: <bug-15620-206@http.llvm.org/bugs/>
Message-ID: <bug-15620-206-m8iyHeGwmz@http.llvm.org/bugs/>

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

Renato Golin <renato.golin at linaro.org> changed:

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

--- Comment #3 from Renato Golin <renato.golin at linaro.org> ---
Fixed in r178957

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130422/7a3e11bd/attachment.html>

From bugzilla-daemon at llvm.org  Mon Apr 22 12:50:23 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 22 Apr 2013 19:50:23 +0000
Subject: [LLVMbugs] [Bug 9582] ARM/Thumb/Data mapping symbols not being
	generated
In-Reply-To: <bug-9582-206@http.llvm.org/bugs/>
References: <bug-9582-206@http.llvm.org/bugs/>
Message-ID: <bug-9582-206-njTsdoEZFW@http.llvm.org/bugs/>

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

Renato Golin <renato.golin at linaro.org> changed:

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

--- Comment #6 from Renato Golin <renato.golin at linaro.org> ---
Fixed in r169609

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130422/6fa85a7e/attachment.html>

From bugzilla-daemon at llvm.org  Mon Apr 22 14:40:28 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 22 Apr 2013 21:40:28 +0000
Subject: [LLVMbugs] [Bug 15821] New: failed assertion `(PtrInfo.V == 0 ||
 isa<PointerType>(PtrInfo.V->getType())) && "invalid pointer value"'
 atCodeGen/MachineInstr.cpp:428
Message-ID: <bug-15821-206@http.llvm.org/bugs/>

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

            Bug ID: 15821
           Summary: failed assertion `(PtrInfo.V == 0 ||
                    isa<PointerType>(PtrInfo.V->getType())) && "invalid
                    pointer value"' atCodeGen/MachineInstr.cpp:428
           Product: libraries
           Version: trunk
          Hardware: Macintosh
                OS: MacOS X
            Status: NEW
          Keywords: compile-fail
          Severity: normal
          Priority: P
         Component: Backend: PowerPC
          Assignee: unassignedbugs at nondot.org
          Reporter: fang at csl.cornell.edu
                CC: annulen at yandex.ru, hfinkel at anl.gov,
                    llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Report separated from bug 14779.

% ../../../gcc40-cmake-build/bin/clang++ -c SetTheory.cpp -o SetTheory.o
/Users/fang/local/src/LLVM-svn/llvm/lib/CodeGen/MachineInstr.cpp:428: failed
assertion `(PtrInfo.V == 0 || isa<PointerType>(PtrInfo.V->getType())) &&
"invalid pointer value"'
Stack dump:
0.      Program arguments:
/Volumes/Isolde/builds/LLVM/gcc40-cmake-build/bin/clang-3.1 -cc1 -triple
powerpc-apple-macosx10.4.0 -emit-obj -mrelax-all -disable-free -main-file-name
SetTheory.cpp -mrelocation-model pic -pic-level 2 -mdisable-fp-elim
-masm-verbose -coverage-file
/Users/fang/local/src/LLVM-svn/gcc40-stage2-build/lib/DebugInfo/SetTheory.o
-resource-dir
/Volumes/Isolde/builds/LLVM/gcc40-cmake-build/bin/../lib/clang/3.3
-fdeprecated-macro -fdebug-compilation-dir
/Users/fang/local/src/LLVM-svn/gcc40-stage2-build/lib/DebugInfo -ferror-limit
19 -fmessage-length 80 -mstackrealign -fblocks -fblocks-runtime-optional
-fobjc-runtime=macosx-10.4.0 -fobjc-default-synthesize-properties
-fencode-extended-block-signature -fcxx-exceptions -fexceptions
-fdiagnostics-show-option -fcolor-diagnostics -backend-option -vectorize-loops
-o SetTheory.o -x c++ SetTheory.cpp 
1.      <eof> parser at end of file
2.      Code generation
3.      Running pass 'Function Pass Manager' on module 'SetTheory.cpp'.
4.      Running pass 'PowerPC DAG->DAG Pattern Instruction Selection' on
function '@_ZN1F6apply2ER1CPiR1AxS4_1B'
clang-3.1: error: unable to execute command: Abort trap
clang-3.1: error: clang frontend command failed due to signal (use -v to see
invocation)
clang version 3.3 
Target: powerpc-apple-darwin8.11.0
Thread model: posix
clang-3.1: note: diagnostic msg: PLEASE submit a bug report to
http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and
associated run script.
clang-3.1: note: diagnostic msg: 
********************

PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang-3.1: note: diagnostic msg: /tmp/SetTheory-af7r6O.cpp
clang-3.1: note: diagnostic msg: /tmp/SetTheory-af7r6O.sh
clang-3.1: note: diagnostic msg: 

********************

Reduced test case from Konstantin in bug 14779:
% cat SetTheory.cpp
class A;
class B {};
class C
{
public:
    typedef A RecSet;
    C();
};
struct D  {
    virtual void apply2(C &p1, int *, C::RecSet &p3, long long ,  C::RecSet
&p5, B ) ;
};
struct F :  D {
    void apply2(C &p1, int *, C::RecSet &p3, long long, C::RecSet &p5, B ) {  
}
};
C::C()
{
    F();
}

This occurs on the powerpc-darwin8 branch (last trunk merge r179582).

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130422/ccf93708/attachment.html>

From bugzilla-daemon at llvm.org  Mon Apr 22 15:15:08 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 22 Apr 2013 22:15:08 +0000
Subject: [LLVMbugs] [Bug 15822] New: DeadStoreElimination ("-dse")
 eliminates a store that isn't dead
Message-ID: <bug-15822-206@http.llvm.org/bugs/>

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

            Bug ID: 15822
           Summary: DeadStoreElimination ("-dse") eliminates a store that
                    isn't dead
           Product: tools
           Version: trunk
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: opt
          Assignee: unassignedbugs at nondot.org
          Reporter: mseaborn at chromium.org
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

DeadStoreElimination ("-dse") eliminates a store that isn't dead.

In the following test case, which is a reduced version of
SingleSource/UnitTests/byval-alignment.c from the LLVM test suite, @do_copy()
should set @g0 to 1234:


@g0 = global i32 zeroinitializer, align 4
@init_val = global i32 1234, align 4

declare void @llvm.memcpy.p0i8.p0i8.i32(i8* nocapture, i8* nocapture, i32, i32,
i1)

define void @f0(i8* %y) noinline {
  tail call void @llvm.memcpy.p0i8.p0i8.i32(i8* bitcast (i32* @g0 to i8*), i8*
%y, i32 4, i32 1, i1 false)
  ret void
}

define void @do_copy() {
  %copy = alloca i32, align 4
  %copy_cast = bitcast i32* %copy to i8*
  %init_val_cast = bitcast i32* @init_val to i8*
  call void @llvm.memcpy.p0i8.p0i8.i32(i8* %copy_cast, i8* %init_val_cast, i32
4, i32 1, i1 false)
  tail call void @f0(i8* %copy_cast)
  ret void
}


However, "-dse" removes the memcpy() from @do_copy so that it will copy
uninitialised data to @g0:

$ opt -basicaa -dse byval-min.ll -S -o -
...
define void @do_copy() {
  %copy = alloca i32, align 4
  %copy_cast = bitcast i32* %copy to i8*
  tail call void @f0(i8* %copy_cast)
  ret void
}

This also occurs with "opt -std-link-opts".

This occurs in at least LLVM 3.0, 3.1 and r176253.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130422/807c45ff/attachment.html>

From bugzilla-daemon at llvm.org  Mon Apr 22 15:24:18 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 22 Apr 2013 22:24:18 +0000
Subject: [LLVMbugs] [Bug 15779] jnz mnemonic not supported in ms-inline asm
In-Reply-To: <bug-15779-206@http.llvm.org/bugs/>
References: <bug-15779-206@http.llvm.org/bugs/>
Message-ID: <bug-15779-206-HvSVSrXcvv@http.llvm.org/bugs/>

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

Chad Rosier <chad.rosier at gmail.com> changed:

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

--- Comment #1 from Chad Rosier <chad.rosier at gmail.com> ---
Jeff,
Have you tried this with ToT?  I believe this issue should have be fixed with
r179804 and r179813.

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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130422/d1fda54d/attachment.html>

From bugzilla-daemon at llvm.org  Mon Apr 22 15:39:23 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 22 Apr 2013 22:39:23 +0000
Subject: [LLVMbugs] [Bug 15823] New: Address sanitizer interacts badly with
 -Wl, --as-needed on linux
Message-ID: <bug-15823-206@http.llvm.org/bugs/>

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

            Bug ID: 15823
           Summary: Address sanitizer interacts badly with -Wl,--as-needed
                    on linux
           Product: clang
           Version: unspecified
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Driver
          Assignee: unassignedclangbugs at nondot.org
          Reporter: nicolasweber at gmx.de
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

On Ubuntu Lucid:

thakis at yearofthelinuxdesktop:/usr/local/google/chrome/src$ cat test.cc
#include <dlfcn.h>
#include <stdio.h>
#include <time.h>

int main() {
  struct timespec ts; clock_gettime(CLOCK_REALTIME, &ts);

  printf("%p\n", dlsym(RTLD_NEXT, "malloc"));
  printf("%p\n", dlsym(RTLD_NEXT, "clock_gettime"));
}
thakis at yearofthelinuxdesktop:/usr/local/google/chrome/src$
third_party/llvm-build/Release+Asserts/bin/clang -fsanitize=address
-Wl,--as-needed -o foo test.cc -ldl -lrt 
thakis at yearofthelinuxdesktop:/usr/local/google/chrome/src$ ./foo 
ASAN:SIGSEGV
=================================================================
==2748==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc
0x000000000000 sp 0x7fff99327e98 bp 0x7fff99327ed0 T0)
AddressSanitizer can not provide additional info.
==2748==ABORTING


This happens because ld ends up not linking in librt:

thakis at yearofthelinuxdesktop:/usr/local/google/chrome/src$ ldd foo
    linux-vdso.so.1 =>  (0x00007fffc41ba000)
    libdl.so.2 => /lib/libdl.so.2 (0x00007ffa37f07000)
    libpthread.so.0 => /lib/libpthread.so.0 (0x00007ffa37cea000)
    libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00007ffa37ad2000)
    libc.so.6 => /lib/libc.so.6 (0x00007ffa3774c0


However, asan (and the other sans, I think) rely on dlsym(RTLD_NEXT,
"clock_gettime") to return a valid function so that the intercepting function
can call through to the real function. But since there's no dependency on
librt.1.so, dlsym() just returns NULL.


The only thing I can think of that can be done about this is to have the driver
strip out --as-needed when doing a sanitizer build.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130422/8cf37fe0/attachment.html>

From bugzilla-daemon at llvm.org  Mon Apr 22 15:55:24 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 22 Apr 2013 22:55:24 +0000
Subject: [LLVMbugs] [Bug 15822] DeadStoreElimination ("-dse") eliminates a
 store that isn't dead
In-Reply-To: <bug-15822-206@http.llvm.org/bugs/>
References: <bug-15822-206@http.llvm.org/bugs/>
Message-ID: <bug-15822-206-d7rx8g9b8w@http.llvm.org/bugs/>

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

Mark Seaborn <mseaborn at chromium.org> changed:

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

--- Comment #2 from Mark Seaborn <mseaborn at chromium.org> ---
Ah, thanks.  Removing "tail" from "tail call void @f0(i8* %copy_cast)" does
indeed fix this.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130422/458c46d2/attachment.html>

From bugzilla-daemon at llvm.org  Mon Apr 22 16:19:41 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 22 Apr 2013 23:19:41 +0000
Subject: [LLVMbugs] [Bug 15394] Assertion `!Failed && "Calling an
 incorrectly devirtualized method"' failed
In-Reply-To: <bug-15394-206@http.llvm.org/bugs/>
References: <bug-15394-206@http.llvm.org/bugs/>
Message-ID: <bug-15394-206-3Yxaam0Ean@http.llvm.org/bugs/>

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

Joshua Naismith <fakju666 at o2.pl> changed:

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

--- Comment #3 from Joshua Naismith <fakju666 at o2.pl> ---
It does, thanks.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130422/d4161b7f/attachment.html>

From bugzilla-daemon at llvm.org  Mon Apr 22 17:11:48 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 23 Apr 2013 00:11:48 +0000
Subject: [LLVMbugs] [Bug 15275] ccc-analyzer does not define __SSSE3__
In-Reply-To: <bug-15275-206@http.llvm.org/bugs/>
References: <bug-15275-206@http.llvm.org/bugs/>
Message-ID: <bug-15275-206-7QI7bRff05@http.llvm.org/bugs/>

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

Ted Kremenek <kremenek at apple.com> changed:

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

--- Comment #5 from Ted Kremenek <kremenek at apple.com> ---
Let's go with whitelisting all -m* options for now.

Implemented: r180073

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130423/c5084330/attachment.html>

From bugzilla-daemon at llvm.org  Mon Apr 22 17:47:13 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 23 Apr 2013 00:47:13 +0000
Subject: [LLVMbugs] [Bug 15806] Naked attribute still has return statement
In-Reply-To: <bug-15806-206@http.llvm.org/bugs/>
References: <bug-15806-206@http.llvm.org/bugs/>
Message-ID: <bug-15806-206-n0MustOpQy@http.llvm.org/bugs/>

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

reed kotler <rkotler at mips.com> changed:

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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130423/0ef893a6/attachment.html>

From bugzilla-daemon at llvm.org  Mon Apr 22 19:51:01 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 23 Apr 2013 02:51:01 +0000
Subject: [LLVMbugs] [Bug 15797] Better warning when using c++11 enum classes
 without -std=c++11
In-Reply-To: <bug-15797-206@http.llvm.org/bugs/>
References: <bug-15797-206@http.llvm.org/bugs/>
Message-ID: <bug-15797-206-vqA9vsTTHd@http.llvm.org/bugs/>

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

rtrieu at google.com changed:

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

--- Comment #1 from rtrieu at google.com ---
r180076 has Clang accept and warn that this is a C++11 feature in non C++11
modes.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130423/c886d5ac/attachment.html>

From bugzilla-daemon at llvm.org  Mon Apr 22 22:27:58 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 23 Apr 2013 05:27:58 +0000
Subject: [LLVMbugs] [Bug 15825] New: [not-a-bug,
 powerpc-darwin8] bad_alloc during assembly of
 RecursiveASTVisitorTest.cpp
Message-ID: <bug-15825-206@http.llvm.org/bugs/>

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

            Bug ID: 15825
           Summary: [not-a-bug, powerpc-darwin8] bad_alloc during assembly
                    of RecursiveASTVisitorTest.cpp
           Product: Test Suite
           Version: trunk
          Hardware: Macintosh
                OS: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: Programs Tests
          Assignee: unassignedbugs at nondot.org
          Reporter: fang at csl.cornell.edu
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

This is not a bug, but should be documented.
On powerpc-darwin8, RecursiveASTVisitorTest causes the system assembler to
bad_alloc/out-of-memory.
System compiler is apple-gcc-4.0.1, and assembler is Apple's GNU as 1.38.
This did not occur before r179583, and was first observed r180052.

[ 88%] Building CXX object
tools/clang/unittests/Tooling/CMakeFiles/ToolingTests.dir/RecursiveASTVisitorTest.cpp.o
cd
/Users/fang/local/src/LLVM-svn/gcc40-cmake-build/tools/clang/unittests/Tooling
&& /Users/fang/local/bin/ccg++   -DCLANG_ENABLE_ARCMT -DCLANG_ENABLE_REWRITER
-DCLANG_ENABLE_STATIC_ANALYZER -DGTEST_HAS_RTTI=0 -D_DEBUG -D_GNU_SOURCE
-D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
-fno-common -fPIC -fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter
-Wwrite-strings -Wno-missing-field-initializers -pedantic -Wno-long-long
-Wno-uninitialized -Wnon-virtual-dtor -fno-common -Woverloaded-virtual
-Wcast-qual -fno-strict-aliasing -g
-I/Users/fang/local/src/LLVM-svn/gcc40-cmake-build/tools/clang/unittests/Tooling
-I/Users/fang/local/src/LLVM-svn/llvm/tools/clang/unittests/Tooling
-I/Users/fang/local/src/LLVM-svn/llvm/tools/clang/include
-I/Users/fang/local/src/LLVM-svn/gcc40-cmake-build/tools/clang/include
-I/Users/fang/local/src/LLVM-svn/gcc40-cmake-build/include
-I/Users/fang/local/src/LLVM-svn/llvm/include
-I/Users/fang/local/src/LLVM-svn/llvm/utils/unittest/googletest/include   
-fno-exceptions  -fno-rtti -Wno-variadic-macros -o
CMakeFiles/ToolingTests.dir/RecursiveASTVisitorTest.cpp.o -c
/Users/fang/local/src/LLVM-svn/llvm/tools/clang/unittests/Tooling/RecursiveASTVisitorTest.cpp
as(20706) malloc: *** vm_allocate(size=2147487744) failed (error code=3)
as(20706) malloc: *** error: can't allocate region
as(20706) malloc: *** set a breakpoint in szone_error to debug
/var/tmp//ccxE0lI4.s:34316:FATAL:virtual memory exceeded
make[3]: ***
[tools/clang/unittests/Tooling/CMakeFiles/ToolingTests.dir/RecursiveASTVisitorTest.cpp.o]
Error 1

This will need to be diagnosed and worked around, I'm afraid.
I cannot resume check-clang without a workaround or fix.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130423/199999de/attachment.html>

From bugzilla-daemon at llvm.org  Tue Apr 23 00:22:10 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 23 Apr 2013 07:22:10 +0000
Subject: [LLVMbugs] [Bug 15808] clang crashes when compiling broken template
In-Reply-To: <bug-15808-206@http.llvm.org/bugs/>
References: <bug-15808-206@http.llvm.org/bugs/>
Message-ID: <bug-15808-206-GZ9Al9j9kz@http.llvm.org/bugs/>

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

Nikola Smiljanić <popizdeh at gmail.com> changed:

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

--- Comment #2 from Nikola Smiljanić <popizdeh at gmail.com> ---
ToT gives:

test.cpp:13:36: error: elaborated type refers to a template
  struct foo<T> *temp = new struct foo;
                                   ^
I'll close this as FIXED.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130423/f1406d4e/attachment.html>

From bugzilla-daemon at llvm.org  Tue Apr 23 01:09:20 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 23 Apr 2013 08:09:20 +0000
Subject: [LLVMbugs] [Bug 15794] Loop Vectorizer: Crashes with the use of
 llvm.loop.parallel metadata
In-Reply-To: <bug-15794-206@http.llvm.org/bugs/>
References: <bug-15794-206@http.llvm.org/bugs/>
Message-ID: <bug-15794-206-m04o0Sceq7@http.llvm.org/bugs/>

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

Pekka Jääskeläinen <pekka.jaaskelainen at tut.fi> changed:

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

--- Comment #12 from Pekka Jääskeläinen <pekka.jaaskelainen at tut.fi> ---
Fixed in r180081.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130423/d733d5cb/attachment.html>

From bugzilla-daemon at llvm.org  Tue Apr 23 03:01:38 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 23 Apr 2013 10:01:38 +0000
Subject: [LLVMbugs] [Bug 15826] New: clang hits assert in
 clang::ASTContext::getASTRecordLayout
Message-ID: <bug-15826-206@http.llvm.org/bugs/>

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

            Bug ID: 15826
           Summary: clang hits assert in
                    clang::ASTContext::getASTRecordLayout
           Product: clang
           Version: 3.2
          Hardware: PC
                OS: FreeBSD
            Status: NEW
          Severity: normal
          Priority: P
         Component: LLVM Codegen
          Assignee: unassignedclangbugs at nondot.org
          Reporter: glebius at FreeBSD.org
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

(gdb) bt
#0  0x000000000183c17a in kill ()
#1  0x000000000183af56 in abort ()
#2  0x0000000001829a6a in __assert ()
#3  0x0000000000cc940b in clang::ASTContext::getASTRecordLayout (
    this=<value optimized out>, D=0x802ce3d40)
    at
/usr/src/aio/lib/clang/libclangast/../../../contrib/llvm/tools/clang/lib/AST/RecordLayoutBuilder.cpp:2470
#4  0x0000000000d7d486 in clang::ASTContext::getTypeInfoImpl (
    this=<value optimized out>, T=<value optimized out>)
    at
/usr/src/aio/lib/clang/libclangast/../../../contrib/llvm/tools/clang/lib/AST/ASTContext.cpp:1534
#5  0x0000000000d7cc5a in clang::ASTContext::getTypeInfo (this=0x80283a000, 
    T=0x802ce3dc0)
    at
/usr/src/aio/lib/clang/libclangast/../../../contrib/llvm/tools/clang/lib/AST/ASTContext.cpp:1301
#6  0x0000000000d7d5ac in clang::ASTContext::getTypeInfoImpl (
    this=0x80283a000, T=<value optimized out>)
    at
/usr/src/aio/lib/clang/libclangast/../../../contrib/llvm/tools/clang/lib/AST/ASTContext.cpp:1598
#7  0x0000000000d7cc5a in clang::ASTContext::getTypeInfo (this=0x80283a000, 
    T=0x802ce3df0)
    at
/usr/src/aio/lib/clang/libclangast/../../../contrib/llvm/tools/clang/lib/AST/ASTContext.cpp:1301
---Type <return> to continue, or q <return> to quit---
#8  0x0000000000d7cb62 in clang::ASTContext::getTypeInfoInChars (
    this=0x80283a000, T=0x6)
    at
/usr/src/aio/lib/clang/libclangast/../../../contrib/llvm/tools/clang/lib/AST/ASTContext.cpp:1286
#9  0x0000000000ccc6c8 in (anonymous
namespace)::RecordLayoutBuilder::LayoutField (this=0x7fffffff95e8,
D=0x802ce4170)
    at
/usr/src/aio/lib/clang/libclangast/../../../contrib/llvm/tools/clang/lib/AST/RecordLayoutBuilder.cpp:2068
#10 0x0000000000cceb64 in (anonymous
namespace)::RecordLayoutBuilder::LayoutFields (this=0x7fffffff95e8, D=<value
optimized out>)
    at
/usr/src/aio/lib/clang/libclangast/../../../contrib/llvm/tools/clang/lib/AST/RecordLayoutBuilder.cpp:1835
#11 0x0000000000cc8921 in clang::ASTContext::getASTRecordLayout (
    this=0x80283a000, D=0x802ce3a20)
    at
/usr/src/aio/lib/clang/libclangast/../../../contrib/llvm/tools/clang/lib/AST/RecordLayoutBuilder.cpp:1638
#12 0x00000000005d2bde in clang::CodeGen::CodeGenTypes::ComputeRecordLayout (
    this=0x8028e38a8, D=0x802ce3a20, Ty=0x8030d18f0)
    at
/usr/src/aio/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/CGRecordLayoutBuilder.cpp:208
#13 0x000000000068640e in clang::CodeGen::CodeGenTypes::ConvertRecordDeclType (
    this=0x8028e38a8, RD=<value optimized out>)
    at
/usr/src/aio/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/---Type
<return> to continue, or q <return> to quit---
lib/CodeGen/CodeGenTypes.cpp:660
#14 0x00000000006852ad in clang::CodeGen::CodeGenTypes::ConvertType (
    this=0x8028e38a8)
    at
/usr/src/aio/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/CodeGenTypes.cpp:295
#15 0x00000000006851d5 in clang::CodeGen::CodeGenTypes::ConvertTypeForMem (
    this=0x8028e38a8)
    at
/usr/src/aio/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/CodeGenTypes.cpp:88
#16 0x00000000005d4786 in (anonymous
namespace)::CGRecordLayoutBuilder::LayoutFields (this=0x7fffffffa028, D=<value
optimized out>)
    at
/usr/src/aio/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/CGRecordLayoutBuilder.cpp:398
#17 0x00000000005d2cb9 in clang::CodeGen::CodeGenTypes::ComputeRecordLayout (
    this=0x8028e38a8, D=0x802ce2df0, Ty=0x802914c90)
    at
/usr/src/aio/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/CGRecordLayoutBuilder.cpp:218
#18 0x000000000068640e in clang::CodeGen::CodeGenTypes::ConvertRecordDeclType (
    this=0x8028e38a8, RD=<value optimized out>)
    at
/usr/src/aio/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/CodeGenTypes.cpp:660
#19 0x00000000006860c7 in clang::CodeGen::CodeGenTypes::UpdateCompletedType (
    this=<value optimized out>, TD=<value optimized out>)
---Type <return> to continue, or q <return> to quit---
    at
/usr/src/aio/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/CodeGenTypes.cpp:262
#20 0x0000000000576189 in (anonymous
namespace)::CodeGeneratorImpl::HandleTagDeclDefinition (this=0x8028343c0,
D=0x802ce2df0)
    at
/usr/src/aio/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/ModuleBuilder.cpp:81
#21 0x000000000057430b in clang::BackendConsumer::HandleTagDeclDefinition (
    this=0x802820240, D=0x802ce2df0)
    at
/usr/src/aio/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/CodeGenAction.cpp:171
#22 0x000000000091b1c2 in clang::Sema::ActOnTagFinishDefinition (
    this=0x8028df000, S=<value optimized out>, TagD=0x802ce2df0)
    at
/usr/src/aio/lib/clang/libclangsema/../../../contrib/llvm/tools/clang/lib/Sema/SemaDecl.cpp:10189
#23 0x00000000006e39c2 in clang::Parser::ParseStructUnionBody (
    this=0x80280f600, TagType=17, TagDecl=0x802ce2df0)
    at
/usr/src/aio/lib/clang/libclangparse/../../../contrib/llvm/tools/clang/lib/Parse/ParseDecl.cpp:3174
#24 0x00000000006c9c38 in clang::Parser::ParseClassSpecifier (
    this=0x80280f600, TagTokKind=<value optimized out>, DS=@0x7fffffffb668, 
    TemplateInfo=@0x7fffffffb5e0, AS=clang::AS_none, 
    EnteringContext=<value optimized out>, Attributes=<value optimized out>)
    at
/usr/src/aio/lib/clang/libclangparse/../../../contrib/llvm/tools/clang/li---Type
<return> to continue, or q <return> to quit---
b/Parse/ParseDeclCXX.cpp:1559
#25 0x00000000006dba18 in clang::Parser::ParseDeclarationSpecifiers (
    this=0x80280f600, DS=@0x7fffffffb668, TemplateInfo=@0x7fffffffb5e0, 
    AS=clang::AS_none, DSContext=clang::Parser::DSC_top_level, LateAttrs=0x0)
    at
/usr/src/aio/lib/clang/libclangparse/../../../contrib/llvm/tools/clang/lib/Parse/ParseDecl.cpp:2852
#26 0x000000000068c480 in clang::Parser::ParseDeclOrFunctionDefInternal (
    this=0x80280f600, attrs=@0x7fffffffbd88, DS=@0x7fffffffb668, 
    AS=clang::AS_none)
    at
/usr/src/aio/lib/clang/libclangparse/../../../contrib/llvm/tools/clang/lib/Parse/Parser.cpp:831
#27 0x000000000068c080 in clang::Parser::ParseDeclarationOrFunctionDefinition (
    this=0x80280f600, attrs=@0x7fffffffbd88, DS=<value optimized out>, 
    AS=clang::AS_none)
    at
/usr/src/aio/lib/clang/libclangparse/../../../contrib/llvm/tools/clang/lib/Parse/Parser.cpp:897
#28 0x000000000068b8c3 in clang::Parser::ParseExternalDeclaration (
    this=<value optimized out>, attrs=<value optimized out>, 
    DS=<value optimized out>)
    at
/usr/src/aio/lib/clang/libclangparse/../../../contrib/llvm/tools/clang/lib/Parse/Parser.cpp:762
#29 0x000000000068ae80 in clang::Parser::ParseTopLevelDecl (this=0x80280f600, 
    Result=@0x7fffffffbe08)
---Type <return> to continue, or q <return> to quit---
    at
/usr/src/aio/lib/clang/libclangparse/../../../contrib/llvm/tools/clang/lib/Parse/Parser.cpp:567
#30 0x0000000000688256 in clang::ParseAST (S=@0x8028df000, PrintStats=false, 
    SkipFunctionBodies=<value optimized out>)
    at
/usr/src/aio/lib/clang/libclangparse/../../../contrib/llvm/tools/clang/lib/Parse/ParseAST.cpp:144
#31 0x00000000005736e1 in clang::CodeGenAction::ExecuteAction (
    this=0x80282b140)
    at
/usr/src/aio/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/CodeGenAction.cpp:423
#32 0x000000000042f177 in clang::FrontendAction::Execute (
    this=<value optimized out>)
    at
/usr/src/aio/lib/clang/libclangfrontend/../../../contrib/llvm/tools/clang/lib/Frontend/FrontendAction.cpp:376
#33 0x0000000000448fff in clang::CompilerInstance::ExecuteAction (
    this=0x8028200c0, Act=@0x80282b140)
    at
/usr/src/aio/lib/clang/libclangfrontend/../../../contrib/llvm/tools/clang/lib/Frontend/CompilerInstance.cpp:691
#34 0x0000000000407f94 in clang::ExecuteCompilerInvocation (Clang=0x8028200c0)
    at
/usr/src/aio/lib/clang/libclangfrontendtool/../../../contrib/llvm/tools/clang/lib/FrontendTool/ExecuteCompilerInvocation.cpp:236
#35 0x0000000000400693 in cc1_main (ArgBegin=<value optimized out>, 
    ArgEnd=0x7fffffffce01, Argv0=0x80280d148 "/usr/bin/cc", MainAddr=0x404250)
---Type <return> to continue, or q <return> to quit---
    at
/usr/src/aio/usr.bin/clang/clang/../../../contrib/llvm/tools/clang/tools/driver/cc1_main.cpp:99
#36 0x00000000004059f6 in main (argc_=<value optimized out>, 
    argv_=<value optimized out>)
    at
/usr/src/aio/usr.bin/clang/clang/../../../contrib/llvm/tools/clang/tools/driver/driver.cpp:357

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130423/caeeb990/attachment.html>

From bugzilla-daemon at llvm.org  Tue Apr 23 05:46:56 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 23 Apr 2013 12:46:56 +0000
Subject: [LLVMbugs] [Bug 15818] Regression afer commit 179786
 (InstCombiner::visitExtractElementInst() enhancement)
In-Reply-To: <bug-15818-206@http.llvm.org/bugs/>
References: <bug-15818-206@http.llvm.org/bugs/>
Message-ID: <bug-15818-206-OQDhG76LMY@http.llvm.org/bugs/>

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

ashemer <anat.shemer at intel.com> changed:

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

--- Comment #4 from ashemer <anat.shemer at intel.com> ---
vslidation in the trunk passes. Also Dmitry wrote:

The patch look good to me. It also fixes all the problems, that I observed with
previous patch - I got several fails in ISPC compiler testing
(ispc.github.com).

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130423/165f8efb/attachment.html>

From bugzilla-daemon at llvm.org  Tue Apr 23 06:23:51 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 23 Apr 2013 13:23:51 +0000
Subject: [LLVMbugs] [Bug 15829] New: clang-3.2 does not pass 26 tests
Message-ID: <bug-15829-206@http.llvm.org/bugs/>

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

            Bug ID: 15829
           Summary: clang-3.2 does not pass 26 tests
           Product: clang
           Version: 3.2
          Hardware: Other
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: Hugo.Mildenberger at web.de
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 10409
  --> http://llvm.org/bugs/attachment.cgi?id=10409&action=edit
clang-3.2 gentoo build log

clang-3.2 was compiled using gcc-4.7.2 (Gentoo Hardened amd64 4.7.2-r1 p1.5,
pie-0.5.5). The complete build log is attached. In the build log, among the
errors in the condensed list below, a similar pattern appears several times:

 Exit Code: 1
 Command Output (stderr):
 --
 opt: <stdin>:22:39: error: expected '{' in function body
 define i32 @s0_load_x(%struct.s0* %a) #0 {
                                     ^
--


XFAIL: Clang :: ARCMT/GC-check-warn-nsalloc.m (1 of 6207)
XFAIL: Clang :: Analysis/outofbound-notwork.c (264 of 6207)
XFAIL: Clang :: Analysis/string-fail.c (311 of 6207)
XFAIL: Clang :: CXX/basic/basic.lookup/basic.lookup.qual/p6-0x.cpp (360 of
6207)
XFAIL: Clang :: CXX/basic/basic.lookup/basic.lookup.unqual/p15.cpp (367 of
6207)
XFAIL: Clang :: CXX/dcl.dcl/dcl.spec/dcl.fct.spec/p4.cpp (480 of 6207)
XFAIL: Clang :: CXX/dcl.dcl/dcl.spec/dcl.stc/p10.cpp (484 of 6207)
XFAIL: Clang :: CXX/temp/temp.param/p14.cpp (816 of 6207)
XFAIL: Clang :: CXX/temp/temp.res/temp.dep.res/temp.point/p1.cpp (827 of 6207)
 FAIL: Clang :: CodeGen/2005-06-15-ExpandGotoInternalProblem.c (1039 of 6207)
XFAIL: Clang :: CodeGen/blocks-2.c (1312 of 6207)
 FAIL: Clang :: CodeGen/extern-weak.c (1422 of 6207)
XFAIL: Clang :: CodeGen/libcalls-d.c (1468 of 6207)
XFAIL: Clang :: CodeGen/libcalls-ld.c (1470 of 6207)
 FAIL: Clang :: CodeGen/packed-structure.c (1536 of 6207)
XFAIL: Clang :: CodeGenCXX/conversion-function.cpp (1809 of 6207)
XFAIL: Clang :: CodeGenCXX/debug-info-limit-type.cpp (1875 of 6207)
 FAIL: Clang :: CodeGenCXX/for-range-temporaries.cpp (1934 of 6207)
 FAIL: Clang :: CodeGenCXX/for-range.cpp (1935 of 6207)
XFAIL: Clang :: FixIt/fixit-pmem.cpp (2725 of 6207)
XFAIL: Clang :: PCH/changed-files.c (3239 of 6207)
XFAIL: Clang :: PCH/pr4489.c (3319 of 6207)
XFAIL: Clang :: PCH/source-manager-stack.c (3335 of 6207)
XFAIL: Clang :: Parser/cxx-ambig-decl-expr-xfail.cpp (3390 of 6207)
XFAIL: Clang :: SemaCXX/switch-implicit-fallthrough-cxx98.cpp (4558 of 6207)
XFAIL: Clang :: SemaTemplate/instantiate-function-1.mm (5266 of 6207)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130423/50f60556/attachment.html>

From bugzilla-daemon at llvm.org  Tue Apr 23 06:46:07 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 23 Apr 2013 13:46:07 +0000
Subject: [LLVMbugs] [Bug 15830] New: Vectorizer produces incorrect results
 for regex code
Message-ID: <bug-15830-206@http.llvm.org/bugs/>

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

            Bug ID: 15830
           Summary: Vectorizer produces incorrect results for regex code
           Product: new-bugs
           Version: trunk
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: dimitry at andric.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 10410
  --> http://llvm.org/bugs/attachment.cgi?id=10410&action=edit
Testcase for regcomp() vectorization problem

Recently we upgraded clang in FreeBSD to trunk r178860.  Afterwards, some
people reported problems with configure scripts, caused by sed failing to
replace certain strings, e.g. @CC@ and such.  These people all had the
following settings in common:

- amd64 (x86_64) architecture
- core2 or higher CPUs, and using -march=native
- using -O3 or equivalent optimization flags

After some searching, this turned out to be a miscompilation in regcomp.c, the
libc source containing a part of the regular expression parsing logic.  One of
the functions, computejumps(), computes a Boyer-Moore jump table:

static void
computejumps(struct parse *p, struct re_guts *g)
{
        int ch;
        int mindex;

        /* Avoid making errors worse */
        if (p->error != 0)
                return;

        g->charjump = (int*) malloc((NC + 1) * sizeof(int));
        if (g->charjump == NULL)        /* Not a fatal error */
                return;
        /* Adjust for signed chars, if necessary */
        g->charjump = &g->charjump[-(CHAR_MIN)];

        /* If the character does not exist in the pattern, the jump
         * is equal to the number of characters in the pattern.
         */
        for (ch = CHAR_MIN; ch < (CHAR_MAX + 1); ch++)
                g->charjump[ch] = g->mlen;

        /* If the character does exist, compute the jump that would
         * take us to the last character in the pattern equal to it
         * (notice that we match right to left, so that last character
         * is the first one that would be matched).
         */
        for (mindex = 0; mindex < g->mlen; mindex++)
                g->charjump[(int)g->must[mindex]] = g->mlen - mindex - 1;
}

When this function is inlined into the main regcomp() function at -O3, and the
vectorizer optimizes the last for loop, something is done incorrectly, and the
resulting table sometimes has one faulty entry.

I have attached a sample testcase, that shows the problem at runtime.  If the
sample is compiled with -O2, or with -O3 -fno-vectorize, it will run without
displaying anything.  If it is compiled with -O3, it will display:

charjump[67] is 5 instead of 4

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130423/bab3b7e4/attachment.html>

From bugzilla-daemon at llvm.org  Tue Apr 23 09:02:07 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 23 Apr 2013 16:02:07 +0000
Subject: [LLVMbugs] [Bug 15831] New: Python bindings don't report errors in
	get_size
Message-ID: <bug-15831-206@http.llvm.org/bugs/>

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

            Bug ID: 15831
           Summary: Python bindings don't report errors in get_size
           Product: new-bugs
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: magnus.reftel at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

In plain libclang, the clang_Type_getSizeOf function returns either a size or a
negative enum value taken from CXTypeLayoutError. The Python wrapper, get_size,
simply casts the value to an unsigned 64-bit integer. This means that if
get_size is called for a variable whose size isn't known (e.g. a
variable-length array), then a very large number (0xffffffffffffffc, in the
case of a VLA) is returned instead of an error.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130423/3b67525a/attachment.html>

From bugzilla-daemon at llvm.org  Tue Apr 23 10:13:47 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 23 Apr 2013 17:13:47 +0000
Subject: [LLVMbugs] [Bug 15830] Vectorizer produces incorrect results for
	regex code
In-Reply-To: <bug-15830-206@http.llvm.org/bugs/>
References: <bug-15830-206@http.llvm.org/bugs/>
Message-ID: <bug-15830-206-UaJf9SCsra@http.llvm.org/bugs/>

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

Nadav Rotem <nrotem at apple.com> changed:

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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130423/14b5329d/attachment.html>

From bugzilla-daemon at llvm.org  Tue Apr 23 10:31:21 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 23 Apr 2013 17:31:21 +0000
Subject: [LLVMbugs] [Bug 12597] libcxx "make install" without privileges
 fails due to "chown root"
In-Reply-To: <bug-12597-206@http.llvm.org/bugs/>
References: <bug-12597-206@http.llvm.org/bugs/>
Message-ID: <bug-12597-206-RmIPxex5jS@http.llvm.org/bugs/>

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

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

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

--- Comment #7 from Bob Wilson <bob.wilson at apple.com> ---
I removed the chown command in svn r180122.  I don't think there's any reason
to keep it.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130423/8411a67b/attachment.html>

From bugzilla-daemon at llvm.org  Tue Apr 23 11:01:53 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 23 Apr 2013 18:01:53 +0000
Subject: [LLVMbugs] [Bug 15810] _xgetbv not declared
In-Reply-To: <bug-15810-206@http.llvm.org/bugs/>
References: <bug-15810-206@http.llvm.org/bugs/>
Message-ID: <bug-15810-206-qSTifx4LGa@http.llvm.org/bugs/>

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

Serge Pavlov <sepavloff at gmail.com> changed:

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

--- Comment #5 from Serge Pavlov <sepavloff at gmail.com> ---
Fixed in revision 180125

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130423/5b8dff93/attachment.html>

From bugzilla-daemon at llvm.org  Tue Apr 23 11:52:15 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 23 Apr 2013 18:52:15 +0000
Subject: [LLVMbugs] [Bug 15820] libcxx "make install" should not require
	rsync
In-Reply-To: <bug-15820-206@http.llvm.org/bugs/>
References: <bug-15820-206@http.llvm.org/bugs/>
Message-ID: <bug-15820-206-opmtQ5DEwy@http.llvm.org/bugs/>

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

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

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

--- Comment #3 from Bob Wilson <bob.wilson at apple.com> ---
I changed it to use tar instead of rsync.  svn r180132.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130423/97cd1a98/attachment.html>

From bugzilla-daemon at llvm.org  Tue Apr 23 12:45:48 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 23 Apr 2013 19:45:48 +0000
Subject: [LLVMbugs] [Bug 5225] clang --analyze crash on trivial C code
In-Reply-To: <bug-5225-206@http.llvm.org/bugs/>
References: <bug-5225-206@http.llvm.org/bugs/>
Message-ID: <bug-5225-206-6Foa20bvJZ@http.llvm.org/bugs/>

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

Jordan Rose <jordan_rose at apple.com> changed:

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

--- Comment #9 from Jordan Rose <jordan_rose at apple.com> ---
Many years later, this example works fine. Closing.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130423/505ac817/attachment.html>

From bugzilla-daemon at llvm.org  Tue Apr 23 14:42:54 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 23 Apr 2013 21:42:54 +0000
Subject: [LLVMbugs] [Bug 15746] R600: Build failure on openSUSE
In-Reply-To: <bug-15746-206@http.llvm.org/bugs/>
References: <bug-15746-206@http.llvm.org/bugs/>
Message-ID: <bug-15746-206-MJgfFuctCT@http.llvm.org/bugs/>

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

Johannes Obermayr <johannesobermayr at gmx.de> changed:

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

--- Comment #3 from Johannes Obermayr <johannesobermayr at gmx.de> ---
Thanks for fixing this.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130423/5a1778d5/attachment.html>

From bugzilla-daemon at llvm.org  Tue Apr 23 16:09:20 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 23 Apr 2013 23:09:20 +0000
Subject: [LLVMbugs] [Bug 14758] asan does not compile on OS X
In-Reply-To: <bug-14758-206@http.llvm.org/bugs/>
References: <bug-14758-206@http.llvm.org/bugs/>
Message-ID: <bug-14758-206-ayQEqGv31O@http.llvm.org/bugs/>

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

Michael Gottesman <mgottesman at apple.com> changed:

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

--- Comment #4 from Michael Gottesman <mgottesman at apple.com> ---
Closing

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130423/59293d99/attachment.html>

From bugzilla-daemon at llvm.org  Tue Apr 23 16:11:37 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 23 Apr 2013 23:11:37 +0000
Subject: [LLVMbugs] [Bug 13911] [execution time regression] - 16.78%
 regression 462.libquantom clang.i386.Os.flto
In-Reply-To: <bug-13911-206@http.llvm.org/bugs/>
References: <bug-13911-206@http.llvm.org/bugs/>
Message-ID: <bug-13911-206-vBDsbTpcSy@http.llvm.org/bugs/>

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

Michael Gottesman <mgottesman at apple.com> changed:

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

--- Comment #6 from Michael Gottesman <mgottesman at apple.com> ---
Closing (old/stale).

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130423/67c6baac/attachment.html>

From bugzilla-daemon at llvm.org  Tue Apr 23 16:40:17 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 23 Apr 2013 23:40:17 +0000
Subject: [LLVMbugs] [Bug 15832] New: Crash in static analyzer on template
 with optional constructor parameter
Message-ID: <bug-15832-206@http.llvm.org/bugs/>

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

            Bug ID: 15832
           Summary: Crash in static analyzer on template with optional
                    constructor parameter
           Product: clang
           Version: trunk
          Hardware: Macintosh
                OS: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: Static Analyzer
          Assignee: kremenek at apple.com
          Reporter: bugzilla at jwwalker.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 10411
  --> http://llvm.org/bugs/attachment.cgi?id=10411&action=edit
source (not preprocessed) showing bug

Overview:  When I run the static analyzer on a certain C++ file, clang crashes
with a bad instruction error.

Steps to reproduce:
Run the analyzer on the attached file.

Actual results:
Crash (bad instruction error), with a log beginning:
Assertion failed: (Val && "isa<> used on a null pointer"), function doit, file
/open-source/llvm/include/llvm/Support/Casting.h, line 97.0

Expect results:

Maybe some analyzer warnings.


Build Date & Platform:

$ /opt/bin/clang --version
clang version 3.3 (trunk 180122) (llvm/trunk 180121)
Target: x86_64-apple-darwin11.4.2
Thread model: posix


Additional Information:

If I change the line defining the variable str1 to str1(NULL), the crash goes
away.


Mac OS crash log:

Process:         clang [49444]
Path:            /opt/bin/clang
Identifier:      clang
Version:         3.3 (???)
Code Type:       X86-64 (Native)
Parent Process:  clang [49443]

Date/Time:       2013-04-23 16:39:39.796 -0700
OS Version:      Mac OS X 10.7.5 (11G63)
Report Version:  9

Interval Since Last Report:          88475 sec
Crashes Since Last Report:           75
Per-App Crashes Since Last Report:   74
Anonymous UUID:                      C6540820-F0A3-4E61-82D4-3424027652A3

Crashed Thread:  0  Dispatch queue: com.apple.main-thread

Exception Type:  EXC_BAD_INSTRUCTION (SIGILL)
Exception Codes: 0x0000000000000001, 0x0000000000000000

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   clang                             0x000000010358a850 0x101d73000 + 25262160
1   clang                             0x000000010358a821 0x101d73000 + 25262113
2   clang                             0x0000000102489ce5 0x101d73000 + 7433445
3   clang                             0x000000010248702f 0x101d73000 + 7421999
4   clang                             0x0000000102491f8f 0x101d73000 + 7466895
5   clang                             0x0000000102492655 0x101d73000 + 7468629
6   clang                             0x00000001024cf37d 0x101d73000 + 7717757
7   clang                             0x00000001024e1a68 0x101d73000 + 7793256
8   clang                             0x00000001024f9596 0x101d73000 + 7890326
9   clang                             0x00000001024e86ba 0x101d73000 + 7820986
10  clang                             0x00000001024d7336 0x101d73000 + 7750454
11  clang                             0x00000001024d6f48 0x101d73000 + 7749448
12  clang                             0x00000001024d6b52 0x101d73000 + 7748434
13  clang                             0x00000001023e8184 0x101d73000 + 6771076
14  clang                             0x00000001023e7925 0x101d73000 + 6768933
15  clang                             0x00000001023e588e 0x101d73000 + 6760590
16  clang                             0x000000010204e774 0x101d73000 + 2996084
17  clang                             0x0000000101dd6957 0x101d73000 + 407895
18  clang                             0x0000000101db282d 0x101d73000 + 260141
19  clang                             0x0000000101d7d1ca 0x101d73000 + 41418
20  clang                             0x0000000101d74370 0x101d73000 + 4976
21  clang                             0x0000000101d7a4e9 0x101d73000 + 29929
22  clang                             0x0000000101d74034 0x101d73000 + 4148

Thread 0 crashed with X86 Thread State (64-bit):
  rax: 0x0000000000000000  rbx: 0x0000000103f3aef0  rcx: 0x00007fff8be70e42 
rdx: 0xffffffffffffffff
  rdi: 0x000000000000003c  rsi: 0x0000000000000000  rbp: 0x00007fff6196ebb0 
rsp: 0x00007fff6196ebb0
   r8: 0x0000000000000000   r9: 0x00000000000f4240  r10: 0x0000000000000001 
r11: 0x00007fff73920228
  r12: 0x0000000000000001  r13: 0x00007fdce3c5b7a0  r14: 0x0000000000000000 
r15: 0x00007fdce3c506a8
  rip: 0x000000010358a850  rfl: 0x0000000000010206  cr2: 0x00007fdce3a60008
Logical CPU: 2

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130423/dc6bf8c8/attachment.html>

From bugzilla-daemon at llvm.org  Tue Apr 23 20:07:02 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 24 Apr 2013 03:07:02 +0000
Subject: [LLVMbugs] [Bug 15833] New: Assertion `Idx < Size && "Out-of-bounds
 Bit access."' failed
Message-ID: <bug-15833-206@http.llvm.org/bugs/>

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

            Bug ID: 15833
           Summary: Assertion `Idx < Size && "Out-of-bounds Bit access."'
                    failed
           Product: clang
           Version: trunk
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Static Analyzer
          Assignee: kremenek at apple.com
          Reporter: fakju666 at o2.pl
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 10415
  --> http://llvm.org/bugs/attachment.cgi?id=10415&action=edit
Testcase + stack

Tested with the latest trunk (release+asserts build). Minimized testcase +
stack are attached, invoke with:

clang -cc1 -analyze -analyzer-checker alpha test.c

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130424/6730eb3d/attachment.html>

From bugzilla-daemon at llvm.org  Wed Apr 24 00:26:26 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 24 Apr 2013 07:26:26 +0000
Subject: [LLVMbugs] [Bug 10124] libclang: clang_CXCursorSet_contains()
 returns opposite of correct value
In-Reply-To: <bug-10124-206@http.llvm.org/bugs/>
References: <bug-10124-206@http.llvm.org/bugs/>
Message-ID: <bug-10124-206-IogxJD6Hha@http.llvm.org/bugs/>

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

Ted Kremenek <kremenek at apple.com> changed:

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

--- Comment #7 from Ted Kremenek <kremenek at apple.com> ---
Jens' patch applied in r180177.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130424/5706a3d8/attachment.html>

From bugzilla-daemon at llvm.org  Wed Apr 24 02:38:24 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 24 Apr 2013 09:38:24 +0000
Subject: [LLVMbugs] [Bug 8447] TEST 'Clang :: Driver/hello.c' FAILED on
	x86_64
In-Reply-To: <bug-8447-206@http.llvm.org/bugs/>
References: <bug-8447-206@http.llvm.org/bugs/>
Message-ID: <bug-8447-206-Jkggn8rTmE@http.llvm.org/bugs/>

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

Nikola Smiljanić <popizdeh at gmail.com> changed:

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

--- Comment #2 from Nikola Smiljanić <popizdeh at gmail.com> ---
This test file no longer exists, I'll close the bug.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130424/3dfb4c91/attachment.html>

From bugzilla-daemon at llvm.org  Wed Apr 24 02:48:56 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 24 Apr 2013 09:48:56 +0000
Subject: [LLVMbugs] [Bug 10753] clang crashes from gcc torture test
	gcc.dg/20020425-1.c
In-Reply-To: <bug-10753-206@http.llvm.org/bugs/>
References: <bug-10753-206@http.llvm.org/bugs/>
Message-ID: <bug-10753-206-Nh5Ym8oKCg@http.llvm.org/bugs/>

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

Nikola Smiljanić <popizdeh at gmail.com> changed:

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

--- Comment #1 from Nikola Smiljanić <popizdeh at gmail.com> ---
No longer crashes, only gives an undeclared reference to 'main' error.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130424/f20a4198/attachment.html>

From bugzilla-daemon at llvm.org  Wed Apr 24 02:51:43 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 24 Apr 2013 09:51:43 +0000
Subject: [LLVMbugs] [Bug 10760] clang crashes from gcc torture test
 g++.dg/parse/stack1.C
In-Reply-To: <bug-10760-206@http.llvm.org/bugs/>
References: <bug-10760-206@http.llvm.org/bugs/>
Message-ID: <bug-10760-206-PGRhsJJiEk@http.llvm.org/bugs/>

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

Nikola Smiljanić <popizdeh at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |popizdeh at gmail.com
         Resolution|---                         |DUPLICATE

--- Comment #2 from Nikola Smiljanić <popizdeh at gmail.com> ---
Attached file is the same as in PR10753 and none of them crash any more.
Marking this as duplicate.

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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130424/777c581a/attachment.html>

From bugzilla-daemon at llvm.org  Wed Apr 24 02:58:07 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 24 Apr 2013 09:58:07 +0000
Subject: [LLVMbugs] [Bug 10908] command line switch -- isn't supported,
	openssl crashes
In-Reply-To: <bug-10908-206@http.llvm.org/bugs/>
References: <bug-10908-206@http.llvm.org/bugs/>
Message-ID: <bug-10908-206-aSWmYOXSp8@http.llvm.org/bugs/>

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

Nikola Smiljanić <popizdeh at gmail.com> changed:

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

--- Comment #11 from Nikola Smiljanić <popizdeh at gmail.com> ---
Closing this as fixed.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130424/16e6acb0/attachment.html>

From bugzilla-daemon at llvm.org  Wed Apr 24 03:07:23 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 24 Apr 2013 10:07:23 +0000
Subject: [LLVMbugs] [Bug 15834] New: clang crashes on i386 when doing
 operations on uint128_t
Message-ID: <bug-15834-206@http.llvm.org/bugs/>

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

            Bug ID: 15834
           Summary: clang crashes on i386 when doing operations on
                    uint128_t
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
          Assignee: unassignedclangbugs at nondot.org
          Reporter: sylvestre at debian.org
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 10416
  --> http://llvm.org/bugs/attachment.cgi?id=10416&action=edit
Preprocessed source

With clang r180084 (from http://llvm.org/apt/)

---
#include <stdint.h>
typedef unsigned uint128_t __attribute__((mode(TI)));
int main() {
  uint64_t a = ((uint64_t)2000000000) * 1000000000;
  uint64_t b = ((uint64_t)1234567890) << 24;
  uint128_t c = ((uint128_t)a) * b;
  return 0;
}
---
crashes with
$ clang foo.c 
0  libLLVM-3.3.so.1 0xf6f713bf llvm::sys::PrintStackTrace(_IO_FILE*) + 47
1  libLLVM-3.3.so.1 0xf6f7161f
2  libLLVM-3.3.so.1 0xf6f711d4
3  linux-gate.so.1  0xf77a3400 __kernel_sigreturn + 0
4  libLLVM-3.3.so.1 0xf6ea00a8 llvm::SelectionDAG::getNode(unsigned int,
llvm::DebugLoc, llvm::EVT, llvm::SDValue) + 2536
5  libLLVM-3.3.so.1 0xf6eb1dff
6  libLLVM-3.3.so.1 0xf6eb17b8
7  libLLVM-3.3.so.1 0xf6eb7a2f
llvm::TargetLowering::LowerCallTo(llvm::TargetLowering::CallLoweringInfo&)
const + 3535
8  libLLVM-3.3.so.1 0xf6f088a7
llvm::TargetLowering::makeLibCall(llvm::SelectionDAG&, llvm::RTLIB::Libcall,
llvm::EVT, llvm::SDValue const*, unsigned int, bool, llvm::DebugLoc) const +
615
9  libLLVM-3.3.so.1 0xf6e2b54d
10 libLLVM-3.3.so.1 0xf6e34772
11 libLLVM-3.3.so.1 0xf6e44df4
12 libLLVM-3.3.so.1 0xf6e45b37 llvm::SelectionDAG::LegalizeTypes() + 903
13 libLLVM-3.3.so.1 0xf6eee73d llvm::SelectionDAGISel::CodeGenAndEmitDAG() +
205
14 libLLVM-3.3.so.1 0xf6eefd58
llvm::SelectionDAGISel::SelectBasicBlock(llvm::ilist_iterator<llvm::Instruction
const>, llvm::ilist_iterator<llvm::Instruction const>, bool&) + 168
15 libLLVM-3.3.so.1 0xf6ef41f9
llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) + 1801
16 libLLVM-3.3.so.1 0xf6ef58e0
llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) + 640
17 libLLVM-3.3.so.1 0xf66ea5ee
llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 126
18 libLLVM-3.3.so.1 0xf68c3a2c
llvm::FPPassManager::runOnFunction(llvm::Function&) + 620
19 libLLVM-3.3.so.1 0xf68c3a78 llvm::FPPassManager::runOnModule(llvm::Module&)
+ 56
20 libLLVM-3.3.so.1 0xf68c35a4 llvm::MPPassManager::runOnModule(llvm::Module&)
+ 596
21 libLLVM-3.3.so.1 0xf68c3722 llvm::PassManagerImpl::run(llvm::Module&) + 210
22 libLLVM-3.3.so.1 0xf68c37b6 llvm::PassManager::run(llvm::Module&) + 38
23 clang            0x0834e637
clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::CodeGenOptions
const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::Module*,
clang::BackendAction, llvm::raw_ostream*) + 3799
24 clang            0x0834c25a
25 clang            0x084d0a45 clang::ParseAST(clang::Sema&, bool, bool) + 645
26 clang            0x081dbee8 clang::ASTFrontendAction::ExecuteAction() + 120
27 clang            0x0834b2f1 clang::CodeGenAction::ExecuteAction() + 33
28 clang            0x081dc438 clang::FrontendAction::Execute() + 168
29 clang            0x081bd885
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 261
30 clang            0x081a7197
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1463
31 clang            0x0819f230 cc1_main(char const**, char const**, char
const*, void*) + 1120
32 clang            0x081a608b main + 7435
33 libc.so.6        0xf5d9e5b5 __libc_start_main + 245
34 clang            0x0819ec11
Stack dump:
0.    Program arguments: /usr/bin/clang -cc1 -triple i386-pc-linux-gnu
-emit-obj -mrelax-all -disable-free -disable-llvm-verifier -main-file-name
foo.c -mrelocation-model static -mdisable-fp-elim -fmath-errno -masm-verbose
-mconstructor-aliases -fuse-init-array -target-cpu pentium4
-target-linker-version 2.22 -resource-dir /usr/bin/../lib/clang/3.3
-internal-isystem /usr/local/include -internal-isystem
/usr/bin/../lib/clang/3.3/include -internal-isystem
/usr/include/clang/3.3/include/ -internal-externc-isystem
/usr/include/i386-linux-gnu -internal-externc-isystem
/usr/include/i486-linux-gnu -internal-externc-isystem /usr/include
-fdebug-compilation-dir /tmp -ferror-limit 19 -fmessage-length 90
-mstackrealign -fobjc-runtime=gcc -fobjc-default-synthesize-properties
-fdiagnostics-show-option -fcolor-diagnostics -backend-option -vectorize-loops
-o /tmp/foo-vOiFvg.o -x c foo.c 
1.    <eof> parser at end of file
2.    Code generation
3.    Running pass 'Function Pass Manager' on module 'foo.c'.
4.    Running pass 'X86 DAG->DAG Instruction Selection' on function '@main'
clang: error: unable to execute command: Segmentation fault
clang: error: clang frontend command failed due to signal (use -v to see
invocation)
Debian clang version 3.3-1~exp1 (trunk) (based on LLVM 3.3)
Target: i386-pc-linux-gnu
Thread model: posix
clang: note: diagnostic msg: PLEASE submit a bug report to
http://bugs.debian.org/ and include the crash backtrace, preprocessed source,
and associated run script.
clang: note: diagnostic msg: 
********************

PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang: note: diagnostic msg: /tmp/foo-mR92eq.c
clang: note: diagnostic msg: /tmp/foo-mR92eq.sh
clang: note: diagnostic msg: 

********************

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130424/951f0615/attachment.html>

From bugzilla-daemon at llvm.org  Wed Apr 24 03:18:18 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 24 Apr 2013 10:18:18 +0000
Subject: [LLVMbugs] [Bug 9611] clang doesn't handle -MMD properly
In-Reply-To: <bug-9611-206@http.llvm.org/bugs/>
References: <bug-9611-206@http.llvm.org/bugs/>
Message-ID: <bug-9611-206-loNWV8Vtcr@http.llvm.org/bugs/>

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

Nikola Smiljanić <popizdeh at gmail.com> changed:

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

--- Comment #3 from Nikola Smiljanić <popizdeh at gmail.com> ---
This seems to be working just fine on newer versions, closing as fixed.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130424/ff44ccee/attachment.html>

From bugzilla-daemon at llvm.org  Wed Apr 24 04:52:23 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 24 Apr 2013 11:52:23 +0000
Subject: [LLVMbugs] [Bug 15835] New: Clang crashes when trying to call
 typedef to function type
Message-ID: <bug-15835-206@http.llvm.org/bugs/>

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

            Bug ID: 15835
           Summary: Clang crashes when trying to call typedef to function
                    type
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: iu.biryukov at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 10418
  --> http://llvm.org/bugs/attachment.cgi?id=10418&action=edit
clang output before crash and source that crashed it

This code crashes clang:

    typedef int foo();

    int test() {
      foo();
    }

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130424/d9122a77/attachment.html>

From bugzilla-daemon at llvm.org  Wed Apr 24 05:52:49 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 24 Apr 2013 12:52:49 +0000
Subject: [LLVMbugs] [Bug 15836] New: Analyzer doesn't know
 sizeof(id)==sizeof(NSObject *), causes false +ve
Message-ID: <bug-15836-206@http.llvm.org/bugs/>

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

            Bug ID: 15836
           Summary: Analyzer doesn't know sizeof(id)==sizeof(NSObject *),
                    causes false +ve
           Product: clang
           Version: 3.2
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Static Analyzer
          Assignee: kremenek at apple.com
          Reporter: iamleeg at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

This is tested with Xcode 4.6.2's analyzer, I haven't had the opportunity to
test with clang trunk yet.

Test case:

#import <Foundation/Foundation.h>

int main(int argc, const char * argv[])
{

    @autoreleasepool {
        __unsafe_unretained NSObject **objectArray = (__unsafe_unretained
NSObject **)malloc(sizeof(id) * 10);
        free(objectArray);
    }
    return 0;
}


Actual result:

Result of 'malloc' is converted to a pointer of type 'NSObject
*__unsafe_unretained', which is incompatible with sizeof operand type 'id'

Expected result:

There shouldn't be an issue. The type outside the malloc() call is a pointer to
an object of the same size as the type inside the sizeof() macro—a pointer to
an Objective-C object.

Workaround:

change the type inside sizeof to "NSObject *". This suppresses the analyzer
report, which specifically occurs when the analyzer compares 'id' to a typed
ObjC object pointer.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130424/8f796287/attachment.html>

From bugzilla-daemon at llvm.org  Wed Apr 24 08:40:13 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 24 Apr 2013 15:40:13 +0000
Subject: [LLVMbugs] [Bug 15837] New: chromium libyuv source runs out of
 registers during register allocation
Message-ID: <bug-15837-206@http.llvm.org/bugs/>

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

            Bug ID: 15837
           Summary: chromium libyuv source runs out of registers during
                    register allocation
           Product: new-bugs
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: dimitry at andric.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 10421
  --> http://llvm.org/bugs/attachment.cgi?id=10421&action=edit
Runs out of registers when built with -O2 -fPIC -m32

A subcomponent of Chromium failed to compile with relatively recent clang 3.3,
giving the following error messages:

third_party/libyuv/source/row_posix.cc:1818:5: error: ran out of registers
during register allocation
    "movdqa    %[kShuffleMaskARGBToRGB24_0],%%xmm5 \n"
    ^
third_party/libyuv/source/row_posix.cc:1873:5: error: ran out of registers
during register allocation
    "movdqa    %[kShuffleMaskARGBToRAW_0],%%xmm5 \n"
    ^

Compilation flags: -O2 -fPIC -m32.  This used to compile with older versions of
clang: the last trunk version I had that was able to build it was r176408,
r178624 (the next one I had archived) was not able to build it anymore.

A reduced testcase is attached.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130424/3e5d7907/attachment.html>

From bugzilla-daemon at llvm.org  Wed Apr 24 14:42:08 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 24 Apr 2013 21:42:08 +0000
Subject: [LLVMbugs] [Bug 15838] New: SlotIndexes::getInstructionIndex(const
 llvm::MachineInstr*) const: Assertion `itr != mi2iMap.end() && "Instruction
 not found in maps."' failed.
Message-ID: <bug-15838-206@http.llvm.org/bugs/>

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

            Bug ID: 15838
           Summary: SlotIndexes::getInstructionIndex(const
                    llvm::MachineInstr*) const: Assertion `itr !=
                    mi2iMap.end() && "Instruction not found in maps."'
                    failed.
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Common Code Generator Code
          Assignee: unassignedbugs at nondot.org
          Reporter: hfinkel at anl.gov
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 10422
  --> http://llvm.org/bugs/attachment.cgi?id=10422&action=edit
bugpoint reduced test case

The attached test case now crashes with this assertion:

llc:
/nfs2/hfinkel/src/llvm-trunk-writable/include/llvm/CodeGen/SlotIndexes.h:410:
llvm::SlotIndex llvm::SlotIndexes::getInstructionIndex(const
llvm::MachineInstr*) const: Assertion `itr != mi2iMap.end() && "Instruction not
found in maps."' failed.

I believe this may be related to "r180193 - MI Sched: eliminate local vreg
copies.".

Run with -mtriple=powerpc64-unknown-linux-gnu -mcpu=ppc64 -enable-misched

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130424/1199b3ae/attachment.html>

From bugzilla-daemon at llvm.org  Wed Apr 24 15:02:05 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 24 Apr 2013 22:02:05 +0000
Subject: [LLVMbugs] [Bug 15839] New: [C99] clang crashes on compound literal
 initialization with address-of as element.
Message-ID: <bug-15839-206@http.llvm.org/bugs/>

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

            Bug ID: 15839
           Summary: [C99] clang crashes on compound literal initialization
                    with address-of as element.
           Product: clang
           Version: unspecified
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
          Assignee: unassignedclangbugs at nondot.org
          Reporter: pichet2000 at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

given test.c:

int x;
struct S { int x : 2; };
struct S b = (struct S){ &x };

clang test.c

This will crash clang. 
I believe this is invalid c99 code since &x is not a constant expression.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130424/7bf496bf/attachment.html>

From bugzilla-daemon at llvm.org  Wed Apr 24 15:06:36 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 24 Apr 2013 22:06:36 +0000
Subject: [LLVMbugs] [Bug 15840] New: gstreamer causes assert "Wrong
 topological sorting", function InitDAGTopologicalSorting
Message-ID: <bug-15840-206@http.llvm.org/bugs/>

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

            Bug ID: 15840
           Summary: gstreamer causes assert "Wrong topological sorting",
                    function InitDAGTopologicalSorting
           Product: new-bugs
           Version: trunk
          Hardware: PC
                OS: FreeBSD
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: dimitry at andric.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 10423
  --> http://llvm.org/bugs/attachment.cgi?id=10423&action=edit
Testcase for InitDAGTopologicalSorting assertion failure

Reduced testcase attached.  Compiling with "-target i386-unknown-freebsd10 -O2
-c gstatomicqueue-testcase.c" results in:

Assertion failed: (Node2Index[SU->NodeNum] > Node2Index[I->getSUnit()->NodeNum]
&& "Wrong topological sorting"), function InitDAGTopologicalSorting, file
/share/dim/src/llvm/trunk/lib/CodeGen/ScheduleDAG.cpp, line 511.
Stack dump:
0.      Program arguments:
/home/dim/obj/llvm-180108M-trunk-freebsd10-i386-aconf-rel-1/Release+Asserts/bin/clang
-cc1 -triple i386-unknown-freebsd10 -emit-obj -disable-free -main-file-name
gstatomicqueue-testcase.c -mrelocation-model static -mdisable-fp-elim
-masm-verbose -mconstructor-aliases -target-cpu i486 -target-linker-version
2.23.1 -coverage-file
/share/dim/src/llvm/bugs/gstreamer/gstatomicqueue-testcase.o -resource-dir
/home/dim/obj/llvm-180108M-trunk-freebsd10-i386-aconf-rel-1/Release+Asserts/bin/../lib/clang/3.3
-O2 -fdebug-compilation-dir /share/dim/src/llvm/bugs/gstreamer -ferror-limit 19
-fmessage-length 278 -mstackrealign -fobjc-runtime=gnustep
-fobjc-default-synthesize-properties -fdiagnostics-show-option
-fcolor-diagnostics -backend-option -vectorize-loops -o
gstatomicqueue-testcase.o -x c gstatomicqueue-testcase.c
1.      <eof> parser at end of file
2.      Code generation
3.      Running pass 'Function Pass Manager' on module
'gstatomicqueue-testcase.c'.
4.      Running pass 'X86 DAG->DAG Instruction Selection' on function
'@gst_atomic_queue_push'
clang: error: unable to execute command: Abort trap (core dumped)
clang: error: clang frontend command failed due to signal (use -v to see
invocation)
clang version 3.3 (trunk 180108)
Target: i386-unknown-freebsd10
Thread model: posix

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130424/87e6b698/attachment.html>

From bugzilla-daemon at llvm.org  Wed Apr 24 15:50:53 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 24 Apr 2013 22:50:53 +0000
Subject: [LLVMbugs] [Bug 15841] New: linkage check for friend function
Message-ID: <bug-15841-206@http.llvm.org/bugs/>

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

            Bug ID: 15841
           Summary: linkage check for friend function
           Product: clang
           Version: unspecified
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
          Assignee: unassignedclangbugs at nondot.org
          Reporter: weimingz at codeaurora.org
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified

R171139 checks linkage compatibility. However, the friend function may need to
check lexical parent's linkage declaration.

For example:
extern "C" {
class Foo {
  int val;
  friend int bar(Foo &);
};
}

extern "C" int bar(Foo &f) {
  return f.val;
}

Clang complains

error: declaration of 'bar' has a different language linkage
extern "C" int bar(Foo &f) {
               ^

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130424/b4c4c713/attachment.html>

From bugzilla-daemon at llvm.org  Wed Apr 24 16:23:15 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 24 Apr 2013 23:23:15 +0000
Subject: [LLVMbugs] [Bug 15838] SlotIndexes::getInstructionIndex(const
 llvm::MachineInstr*) const: Assertion `itr != mi2iMap.end() && "Instruction
 not found in maps."' failed.
In-Reply-To: <bug-15838-206@http.llvm.org/bugs/>
References: <bug-15838-206@http.llvm.org/bugs/>
Message-ID: <bug-15838-206-zy8ZCaQcDu@http.llvm.org/bugs/>

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

Andrew Trick <atrick at apple.com> changed:

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

--- Comment #1 from Andrew Trick <atrick at apple.com> ---
Fixed in r180227.

The new subpass expected a nonempty block. Which is usually true but we don't
filter out blocks with multiple dbg.value.

Some day I must figure out how to reduce metadata so I can checkin test cases
like this.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130424/b4ed6f46/attachment.html>

From bugzilla-daemon at llvm.org  Wed Apr 24 16:54:50 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 24 Apr 2013 23:54:50 +0000
Subject: [LLVMbugs] [Bug 15842] New: need to check for a placeholder in
 argument to noexcept
Message-ID: <bug-15842-206@http.llvm.org/bugs/>

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

            Bug ID: 15842
           Summary: need to check for a placeholder in argument to
                    noexcept
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++11
          Assignee: unassignedclangbugs at nondot.org
          Reporter: richard-llvm at metafoo.co.uk
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified

We accept this invalid code:

void f();
void f(int);
bool b = noexcept(f);

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130424/d6070608/attachment.html>

From bugzilla-daemon at llvm.org  Wed Apr 24 17:48:24 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 25 Apr 2013 00:48:24 +0000
Subject: [LLVMbugs] [Bug 15832] Crash in static analyzer on template with
 optional constructor parameter
In-Reply-To: <bug-15832-206@http.llvm.org/bugs/>
References: <bug-15832-206@http.llvm.org/bugs/>
Message-ID: <bug-15832-206-CMADyZFg6g@http.llvm.org/bugs/>

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

Anna Zaks <ganna at apple.com> changed:

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

--- Comment #6 from Anna Zaks <ganna at apple.com> ---
Fixed in r180234. Thanks for the reduced test case!

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130425/6f040037/attachment.html>

From bugzilla-daemon at llvm.org  Wed Apr 24 18:42:27 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 25 Apr 2013 01:42:27 +0000
Subject: [LLVMbugs] [Bug 15843] New: Scan-view pages return 404 file not
	found
Message-ID: <bug-15843-206@http.llvm.org/bugs/>

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

            Bug ID: 15843
           Summary: Scan-view pages return 404 file not found
           Product: clang
           Version: 3.2
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Static Analyzer
          Assignee: kremenek at apple.com
          Reporter: Flaeme.flow at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

I'm using scan-build/scan-view 3.2-5 on Arch Linux with the official package.
Scan-build works fine, generates the correct files, and detects some simple
errors. I can directly open the files in my browser and it works fine. However,
the pages served by scan-build return 404's. To be exact (wrapped in "'s for
easy viewing):
"""
Error response

Error code 404.

Message: File not found.

Error code explanation: 404 = Nothing matches the given URI.
"""
Output of scan-build (I try explicitly going to /index.html here after the
first failure):
"""
 $ scan-view --debug --debug --debug --auto-reload --port=12009
/tmp/scan-build-2013-04-24-3
/usr/bin/scan-view: Waiting for server.Starting scan-view at:
http://127.0.0.1:12009
  Use Ctrl-C to exit.
../usr/bin/scan-view: SERVER: waiting...
/usr/bin/scan-view: SERVER: sending path "/index.html"
/usr/bin/scan-view: SERVER: localhost.localdomain - - [24/Apr/2013 19:41:21]
code 404, message File not found
/usr/bin/scan-view: SERVER: localhost.localdomain - - [24/Apr/2013 19:41:21]
"GET / HTTP/1.0" 404 -
/usr/bin/scan-view: Starting webbrowser...
 /usr/bin/scan-view: SERVER: waiting...
/usr/bin/scan-view: SERVER: sending path "/index.html"
/usr/bin/scan-view: SERVER: localhost.localdomain - - [24/Apr/2013 19:41:25]
code 404, message File not found
/usr/bin/scan-view: SERVER: localhost.localdomain - - [24/Apr/2013 19:41:25]
"GET / HTTP/1.1" 404 -
/usr/bin/scan-view: SERVER: waiting...
Created new window in existing browser session.
/usr/bin/scan-view: SERVER: localhost.localdomain - - [24/Apr/2013 19:41:27]
code 404, message File not found
/usr/bin/scan-view: SERVER: localhost.localdomain - - [24/Apr/2013 19:41:27]
"GET /favicon.ico HTTP/1.1" 404 -
/usr/bin/scan-view: SERVER: waiting...
/usr/bin/scan-view: SERVER: sending path "/index.html"
/usr/bin/scan-view: SERVER: localhost.localdomain - - [24/Apr/2013 19:41:55]
code 404, message File not found
/usr/bin/scan-view: SERVER: localhost.localdomain - - [24/Apr/2013 19:41:55]
"GET /index.html HTTP/1.1" 404 -
/usr/bin/scan-view: SERVER: waiting...
/usr/bin/scan-view: SERVER: localhost.localdomain - - [24/Apr/2013 19:41:57]
code 404, message File not found
/usr/bin/scan-view: SERVER: localhost.localdomain - - [24/Apr/2013 19:41:57]
"GET /favicon.ico HTTP/1.1" 404 -
/usr/bin/scan-view: SERVER: waiting...
^C
"""

No combination of options to scan-view seem to help.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130425/837a4458/attachment.html>

From bugzilla-daemon at llvm.org  Wed Apr 24 20:05:58 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 25 Apr 2013 03:05:58 +0000
Subject: [LLVMbugs] [Bug 12617] assertion failed in textdiagnostic.cpp
In-Reply-To: <bug-12617-206@http.llvm.org/bugs/>
References: <bug-12617-206@http.llvm.org/bugs/>
Message-ID: <bug-12617-206-8XhNbFR0SW@http.llvm.org/bugs/>

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

rtrieu at google.com changed:

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

--- Comment #1 from rtrieu at google.com ---
$ clang -x c a.o
a.o:1:1: error: expected identifier or '('
<U+007F>ELF<U+0001><U+0001><U+0001><U+0003>
^
a.o:1:9: warning: null character ignored [-Wnull-character]
<U+007F>ELF<U+0001><U+0001><U+0001><U+0003>
                                           ^
a.o:1:10: warning: null character ignored [-Wnull-character]
<U+007F>ELF<U+0001><U+0001><U+0001><U+0003><U+0000>
                                                   ^
a.o:1:11: warning: null character ignored [-Wnull-character]
<U+007F>ELF<U+0001><U+0001><U+0001><U+0003><U+0000><U+0000>
                                                           ^
a.o:1:12: warning: null character ignored [-Wnull-character]
<U+007F>ELF<U+0001><U+0001><U+0001><U+0003><U+0000><U+0000><U+0000>
                                                                   ^
a.o:1:13: warning: null character ignored [-Wnull-character]
<U+007F>ELF<U+0001><U+0001><U+0001><U+0003><U+0000><U+0000><U+0000><U+0000>
                                                                           ^

...
Lots more messages
...

a.o:2:49: error: source file is not valid UTF-8
  ...<89><E5><83><EC><U+0008><8B>E<U+0008><89><E1><89><U+0001><C7>A<U+0004>
     ^
a.o:2:50: error: source file is not valid UTF-8
  ...<E5><83><EC><U+0008><8B>E<U+0008><89><E1><89><U+0001><C7>A<U+0004>
     ^
fatal error: too many errors emitted, stopping now [-ferror-limit=]
67 warnings and 20 errors generated.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130425/29d4f5e0/attachment.html>

From bugzilla-daemon at llvm.org  Wed Apr 24 21:31:01 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 25 Apr 2013 04:31:01 +0000
Subject: [LLVMbugs] [Bug 12477] [meta] Support Microsoft C++ ABI
In-Reply-To: <bug-12477-206@http.llvm.org/bugs/>
References: <bug-12477-206@http.llvm.org/bugs/>
Message-ID: <bug-12477-206-J2mY94l1qR@http.llvm.org/bugs/>

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

Bug 12477 depends on bug 13182, which changed state.

Bug 13182 Summary: [Windows] const arrays are not mangled properly
http://llvm.org/bugs/show_bug.cgi?id=13182

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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130425/466e60cc/attachment.html>

From bugzilla-daemon at llvm.org  Wed Apr 24 21:31:00 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 25 Apr 2013 04:31:00 +0000
Subject: [LLVMbugs] [Bug 13182] [Windows] const arrays are not mangled
	properly
In-Reply-To: <bug-13182-206@http.llvm.org/bugs/>
References: <bug-13182-206@http.llvm.org/bugs/>
Message-ID: <bug-13182-206-70qRcdwPiw@http.llvm.org/bugs/>

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

Peter Collingbourne <peter at pcc.me.uk> changed:

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

--- Comment #7 from Peter Collingbourne <peter at pcc.me.uk> ---
Fixed by r180250.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130425/3dfc990e/attachment.html>

From bugzilla-daemon at llvm.org  Wed Apr 24 23:08:12 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 25 Apr 2013 06:08:12 +0000
Subject: [LLVMbugs] [Bug 13169] Clang driver warning: argument unused during
 compilation: '-fixit'
In-Reply-To: <bug-13169-206@http.llvm.org/bugs/>
References: <bug-13169-206@http.llvm.org/bugs/>
Message-ID: <bug-13169-206-5gXNzvAJFv@http.llvm.org/bugs/>

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

Nikola Smiljanić <popizdeh at gmail.com> changed:

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

--- Comment #3 from Nikola Smiljanić <popizdeh at gmail.com> ---
-fixit no longer shows up in the help text (tested r180185). Closing as fixed.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130425/8e084bfe/attachment.html>

From bugzilla-daemon at llvm.org  Thu Apr 25 01:43:22 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 25 Apr 2013 08:43:22 +0000
Subject: [LLVMbugs] [Bug 15844] New: several XOP intrinsics are missing from
	xopintrin.h
Message-ID: <bug-15844-206@http.llvm.org/bugs/>

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

            Bug ID: 15844
           Summary: several XOP intrinsics are missing from xopintrin.h
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Headers
          Assignee: unassignedclangbugs at nondot.org
          Reporter: kretz at kde.org
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Code that works with GCC doesn't compile with clang because of missing XOP
intrinsics. Specifically I'm missing:
_mm_comtrue_epu8
_mm_comlt_epu16
_mm_comgt_epu16
_mm_comlt_epu32
_mm_comgt_epu32

>From a quick look at the diff between xopintrin.h of GCC and clang there seem
to be even more intrinsics missing.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130425/33df562d/attachment.html>

From bugzilla-daemon at llvm.org  Thu Apr 25 04:54:56 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 25 Apr 2013 11:54:56 +0000
Subject: [LLVMbugs] [Bug 15837] chromium libyuv source runs out of registers
 during register allocation
In-Reply-To: <bug-15837-206@http.llvm.org/bugs/>
References: <bug-15837-206@http.llvm.org/bugs/>
Message-ID: <bug-15837-206-xxz1tHnJid@http.llvm.org/bugs/>

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

Hans Wennborg <hans at chromium.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |hans at chromium.org
         Resolution|---                         |DUPLICATE

--- Comment #2 from Hans Wennborg <hans at chromium.org> ---
Marking as duplicate of Bug 15798.

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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130425/b0c40055/attachment.html>

From bugzilla-daemon at llvm.org  Thu Apr 25 07:23:09 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 25 Apr 2013 14:23:09 +0000
Subject: [LLVMbugs] [Bug 15845] New: Clang accepts invalid code
Message-ID: <bug-15845-206@http.llvm.org/bugs/>

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

            Bug ID: 15845
           Summary: Clang accepts invalid code
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
          Assignee: unassignedclangbugs at nondot.org
          Reporter: iu.biryukov at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

I did ran clang++(from trunk) on source file of this single line of code:

    int foo(xxx); 

and this code got accepted with a warning:

  0.cpp:1:9: warning: type specifier missing, defaults to 'int'
[-Wimplicit-int]
  int foo(xxx);
          ^~~
  1 warning generated.


I believe this is a regression, since older versions of clang was reporting an
error on the same code:

  0.cpp:1:7: error: unknown type name 'xxx'
  int foo(xxx);

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130425/a02e467e/attachment.html>

From bugzilla-daemon at llvm.org  Thu Apr 25 13:14:02 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 25 Apr 2013 20:14:02 +0000
Subject: [LLVMbugs] [Bug 15841] linkage check for friend function
In-Reply-To: <bug-15841-206@http.llvm.org/bugs/>
References: <bug-15841-206@http.llvm.org/bugs/>
Message-ID: <bug-15841-206-mvmUAAuA1j@http.llvm.org/bugs/>

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

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

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

--- Comment #4 from Rafael Ávila de Espíndola <rafael.espindola at gmail.com> ---
Fixed in r180571.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130425/2bfa32ab/attachment.html>

From bugzilla-daemon at llvm.org  Thu Apr 25 16:15:41 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 25 Apr 2013 23:15:41 +0000
Subject: [LLVMbugs] [Bug 15846] New: False positive "potential leak of an
 object" with wrapper reset method
Message-ID: <bug-15846-206@http.llvm.org/bugs/>

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

            Bug ID: 15846
           Summary: False positive "potential leak of an object" with
                    wrapper reset method
           Product: clang
           Version: trunk
          Hardware: Macintosh
                OS: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: Static Analyzer
          Assignee: kremenek at apple.com
          Reporter: bugzilla at jwwalker.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 10427
  --> http://llvm.org/bugs/attachment.cgi?id=10427&action=edit
RetainCountFalsePositive.cpp

Overview:

When using a wrapper class that holds a reference-counted Core Foundation
object, the static analyzer reports a potential leak whenever I have the
wrapper take ownership of an object.


Steps to reproduce:

Analyze the attached Mac C++ source file.


Actual results:

"Potential leak of an object" warning.


Expected results:

No warnings.


Build date:

clang version 3.3 (trunk 180561) (llvm/trunk 180467)
Target: x86_64-apple-darwin11.4.2
Thread model: posix


Additional Information:

If I comment out the line "if (ptr_ != p)" in the Reset method, the warning
goes away.  I guess the analyzer is "thinking" that the test might fail, so p
might not be assigned to ptr_.  But I can't see any way that
CFStringCreateWithCString could return a pointer that is already in the ptr_
member.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130425/0ca69c1d/attachment.html>

From bugzilla-daemon at llvm.org  Thu Apr 25 17:02:53 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 26 Apr 2013 00:02:53 +0000
Subject: [LLVMbugs] [Bug 15846] False positive "potential leak of an object"
 with wrapper reset method
In-Reply-To: <bug-15846-206@http.llvm.org/bugs/>
References: <bug-15846-206@http.llvm.org/bugs/>
Message-ID: <bug-15846-206-KnlXHce2Fq@http.llvm.org/bugs/>

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

Jordan Rose <jordan_rose at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |jordan_rose at apple.com
         Resolution|---                         |INVALID

--- Comment #1 from Jordan Rose <jordan_rose at apple.com> ---
CFStringCreateWithCString could some day do some magic uniquing and return the
same string back. (Seems very reasonable for, say, the empty string.)

More seriously, you have an implementation that's broken in certain edge cases,
and just because this probably isn't one of them today doesn't mean that the
code is really correct. You can always use an assertion instead of a comparison
if you don't want to handle that case.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130426/5ab21b1f/attachment.html>

From bugzilla-daemon at llvm.org  Thu Apr 25 22:18:59 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 26 Apr 2013 05:18:59 +0000
Subject: [LLVMbugs] [Bug 15847] New: Add support for gnu_printf format
	attribute
Message-ID: <bug-15847-206@http.llvm.org/bugs/>

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

            Bug ID: 15847
           Summary: Add support for gnu_printf format attribute
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Windows XP
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: net147 at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

The gnu_printf format attribute was added in GCC 4.4 by
http://gcc.gnu.org/viewcvs/gcc?view=revision&revision=133365.

As Clang defines __GNUC__, Clang should also support the gnu_printf format
attribute.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130426/37399df3/attachment.html>

From bugzilla-daemon at llvm.org  Thu Apr 25 22:34:13 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 26 Apr 2013 05:34:13 +0000
Subject: [LLVMbugs] [Bug 15848] New: Add support for ms_printf format
	attribute
Message-ID: <bug-15848-206@http.llvm.org/bugs/>

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

            Bug ID: 15848
           Summary: Add support for ms_printf format attribute
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Windows XP
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: net147 at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

The C runtime on Windows XP and older does not support %lld and some other
format strings used by GNU printf. You need to use %I64d instead of %lld.

The ms_printf format attribute should be implemented to check against MS format
strings and the printf format attribute should default to ms_printf on Windows
when used with MinGW GCC.

This has already been implemented in GCC 4.4:
http://gcc.gnu.org/viewcvs/gcc?view=revision&revision=133365

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130426/3bca33ed/attachment.html>

From bugzilla-daemon at llvm.org  Fri Apr 26 03:16:45 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 26 Apr 2013 10:16:45 +0000
Subject: [LLVMbugs] [Bug 15849] New: Failure to expand a predefined macro
Message-ID: <bug-15849-206@http.llvm.org/bugs/>

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

            Bug ID: 15849
           Summary: Failure to expand a predefined macro
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
          Assignee: unassignedclangbugs at nondot.org
          Reporter: eremeev at viva64.com
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified

I am using Clang, built from trunk on a Windows system using Visual C++ 10
compiler. When running clang with the –E flag (preprocess only) on the
following code:
int _tmain(int argc, _TCHAR* argv[])
{
    char* A = __DATE__;
    char* B = ""__TIME__;
    char* C = ""__FILE__;
    char* D = "" __FILE__;
    return 0;
}

It generates the following output from the preprocessor:
int wmain(int argc, _TCHAR* argv[])
{
 char* A = "Apr 26 2013";
 char* B = ""__TIME__;
 char* C = ""__FILE__;
 char* D = "" "c:/Viva64SelfTester/src/fceu/testDate/testDate.cpp";
 return 0;
}

As evident, the predefine macros (__TIME__ and __FILE__) are not expanded by
the preprocessor at all. It happens when you place the string constant just
before the macro itself. Notice, that if you add a space between the macro and
the string, the macro is expanded properly.

We've encountered this bug on the latest release branch (3.2), as well as on
the current trunk. It was not present in the version we were utilizing before
(trunk 156904).

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130426/12324eda/attachment.html>

From bugzilla-daemon at llvm.org  Fri Apr 26 03:29:04 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 26 Apr 2013 10:29:04 +0000
Subject: [LLVMbugs] [Bug 15849] Failure to expand a predefined macro
In-Reply-To: <bug-15849-206@http.llvm.org/bugs/>
References: <bug-15849-206@http.llvm.org/bugs/>
Message-ID: <bug-15849-206-Q2Rt61ZxNP@http.llvm.org/bugs/>

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

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> ---
This is a C++11 feature (User-defined literals). GCC in C++11 mode gives the
same output, MSVC doesn't support UDLs yet.

To get the expected behavior compile in C++98 mode.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130426/ed8450bb/attachment.html>

From bugzilla-daemon at llvm.org  Fri Apr 26 05:16:30 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 26 Apr 2013 12:16:30 +0000
Subject: [LLVMbugs] [Bug 15850] New: container ::empty should be
 __attribute__((warn_unused_result))
Message-ID: <bug-15850-206@http.llvm.org/bugs/>

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

            Bug ID: 15850
           Summary: container ::empty should be
                    __attribute__((warn_unused_result))
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
          Assignee: unassignedclangbugs at nondot.org
          Reporter: richard-llvm at metafoo.co.uk
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Here's a common beginner mistake with standard library containers:

  std::vector<int> vi;
  // ...

  // empty the vector
  vi.empty();

We should warn on this -- adding __attribute__((warn_unused_result)) to empty
should do the trick.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130426/921bbe1b/attachment.html>

From bugzilla-daemon at llvm.org  Fri Apr 26 08:25:04 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 26 Apr 2013 15:25:04 +0000
Subject: [LLVMbugs] [Bug 15851] New: Clang hangs at -O1
Message-ID: <bug-15851-206@http.llvm.org/bugs/>

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

            Bug ID: 15851
           Summary: Clang hangs at -O1
           Product: new-bugs
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: antoine.balestrat at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Using LLVM/Clang as of r180602 :

$ cat inf.c
void f(void)
{
    int i, **p;

    f();
    for(;; i++)
        for(i = 0; i < 2; i++)
            (i /= 2) && (**p = 0);
}

$ ulimit -t 60

$ clong -O1 -w inf.c
0  clang           0x0000000001d6ab62 llvm::sys::PrintStackTrace(_IO_FILE*) +
34
1  clang           0x0000000001d6a881
2  libpthread.so.0 0x00007f74b261d030
3  libc.so.6       0x00007f74b1751132
4  libc.so.6       0x00007f74b1754aac cfree + 108
5  clang           0x0000000001d1a1b3 llvm::Value::~Value() + 515
6  clang           0x0000000001cee907
7  clang           0x0000000001b26825
8  clang           0x0000000001a71ff2
llvm::SimplifyInstructionsInBlock(llvm::BasicBlock*, llvm::DataLayout const*,
llvm::TargetLibraryInfo const*) + 354
9  clang           0x0000000001969d95
10 clang           0x000000000196ab19
11 clang           0x000000000196bdea
12 clang           0x0000000001d049af
llvm::FPPassManager::runOnFunction(llvm::Function&) + 655
13 clang           0x0000000001ac20f6
14 clang           0x0000000001d044d7
llvm::MPPassManager::runOnModule(llvm::Module&) + 663
15 clang           0x0000000001d0467f llvm::PassManagerImpl::run(llvm::Module&)
+ 207
16 clang           0x00000000008f66b2
clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::CodeGenOptions
const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::Module*,
clang::BackendAction, llvm::raw_ostream*) + 3458
17 clang           0x00000000008f432f
18 clang           0x0000000000a5793a clang::ParseAST(clang::Sema&, bool, bool)
+ 538
19 clang           0x00000000008f2abe clang::CodeGenAction::ExecuteAction() +
78
20 clang           0x000000000077b499 clang::FrontendAction::Execute() + 265
21 clang           0x000000000075d9fa
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 346
22 clang           0x00000000007456a2
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1794
23 clang           0x000000000073f9a8 cc1_main(char const**, char const**, char
const*, void*) + 920
24 clang           0x00000000007330c0 main + 7744
25 libc.so.6       0x00007f74b16f7ead __libc_start_main + 253
26 clang           0x000000000073f461
Stack dump:
0.    Program arguments: /home/merkil/clang/build/Release+Asserts/bin/clang
-cc1 -triple x86_64-unknown-linux-gnu -emit-obj -disable-free -main-file-name
inf.c -mrelocation-model static -fmath-errno -masm-verbose
-mconstructor-aliases -munwind-tables -fuse-init-array -target-cpu x86-64
-target-linker-version 2.22 -momit-leaf-frame-pointer -resource-dir
/home/merkil/clang/build/Release+Asserts/bin/../lib/clang/3.3 -internal-isystem
/usr/local/include -internal-isystem
/home/merkil/clang/build/Release+Asserts/bin/../lib/clang/3.3/include
-internal-externc-isystem /usr/include/x86_64-linux-gnu
-internal-externc-isystem /include -internal-externc-isystem /usr/include -O1
-w -fdebug-compilation-dir /home/merkil -ferror-limit 19 -fmessage-length 169
-mstackrealign -fobjc-runtime=gcc -fobjc-default-synthesize-properties
-fdiagnostics-show-option -fcolor-diagnostics -backend-option -vectorize-loops
-o /tmp/inf-ne2Y62.o -x c inf.c 
1.    <eof> parser at end of file
2.    Per-module optimization passes
3.    Running pass 'CallGraph Pass Manager' on module 'inf.c'.
4.    Running pass 'Jump Threading' on function '@f'
clang: error: unable to execute command: CPU time limit exceeded
clang: error: clang frontend command failed due to signal (use -v to see
invocation)
clang version 3.3 (trunk 180602)
Target: x86_64-unknown-linux-gnu
Thread model: posix
clang: note: diagnostic msg: PLEASE submit a bug report to
http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and
associated run script.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130426/90bb5ee4/attachment.html>

From bugzilla-daemon at llvm.org  Fri Apr 26 08:25:11 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 26 Apr 2013 15:25:11 +0000
Subject: [LLVMbugs] [Bug 15852] New: using T::T inside template <typename T>
 not accepted, leads to bogus errors.
Message-ID: <bug-15852-206@http.llvm.org/bugs/>

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

            Bug ID: 15852
           Summary: using T::T inside template <typename T> not
                    accepted,leads to bogus errors.
           Product: clang
           Version: trunk
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++11
          Assignee: unassignedclangbugs at nondot.org
          Reporter: benjamin.redelings at duke.edu
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 10429
  --> http://llvm.org/bugs/attachment.cgi?id=10429&action=edit
Test case

The attached test case leads to the following compilation errors:

$ clang++ -std=c++11 test.C
test.C:32:17: error: template argument for template type parameter must be a
type
  Box(const Box<T>&) = default;
                ^
test.C:11:19: note: template parameter is declared here
template<typename T>
                  ^
test.C:33:22: error: unknown type name 'T'
  explicit Box(const T& t):T(t) {}
                     ^
test.C:15:41: error: template argument for template type parameter must be a
type
  Box<T>* clone() const {return new Box<T>(*this);}
                                        ^
test.C:11:19: note: template parameter is declared here
template<typename T>
                  ^
test.C:29:12: error: no member named 'T' in 'A'
  using T::T;
        ~~~^
test.C:38:10: note: in instantiation of template class 'Box<A>' requested here
  Box<A> a;
         ^
4 errors generated.

These errors go away if "using T::T" is commented out.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130426/f816c864/attachment.html>

From bugzilla-daemon at llvm.org  Fri Apr 26 08:59:47 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 26 Apr 2013 15:59:47 +0000
Subject: [LLVMbugs] [Bug 15853] New: __has_attribute does not parse C++11
 namespaced attributes
Message-ID: <bug-15853-206@http.llvm.org/bugs/>

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

            Bug ID: 15853
           Summary: __has_attribute does not parse C++11 namespaced
                    attributes
           Product: clang
           Version: unspecified
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++11
          Assignee: unassignedclangbugs at nondot.org
          Reporter: arcata at gmail.com
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Testing for a namespaced attribute with __has_attribute gives a parse error:

////
#if __has_attribute(clang::fallthrough)
#warning "clang::fallthrough supported"
#endif
////

----
foo.cpp:1:5: error: builtin feature check macro requires a parenthesized
identifier
#if __has_attribute(clang::fallthrough)
    ^
foo.cpp:1:26: error: invalid token at start of a preprocessor expression
#if __has_attribute(clang::fallthrough)
----

Testing with the un-namespaced name works:

////
#if __has_attribute(fallthrough)
#warning "fallthrough supported...somewhere"
#endif
////

----
#if __has_attribute(fallthrough)
#warning "fallthrough supported...somewhere"
#endif
----

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130426/ebe421f5/attachment.html>

From bugzilla-daemon at llvm.org  Fri Apr 26 14:40:32 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 26 Apr 2013 21:40:32 +0000
Subject: [LLVMbugs] [Bug 14658] debug info DW_AT_comp_dir is not the same
 path as that used to resolve file names
In-Reply-To: <bug-14658-206@http.llvm.org/bugs/>
References: <bug-14658-206@http.llvm.org/bugs/>
Message-ID: <bug-14658-206-H6MZiN500l@http.llvm.org/bugs/>

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

Chad Rosier <chad.rosier at gmail.com> changed:

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

--- Comment #1 from Chad Rosier <chad.rosier at gmail.com> ---
I believe this has been fixed as of clang r180628.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130426/feca5869/attachment.html>

From bugzilla-daemon at llvm.org  Fri Apr 26 14:40:33 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 26 Apr 2013 21:40:33 +0000
Subject: [LLVMbugs] [Bug 14330] Clang does not pass the GDB 7.5 test suite
In-Reply-To: <bug-14330-206@http.llvm.org/bugs/>
References: <bug-14330-206@http.llvm.org/bugs/>
Message-ID: <bug-14330-206-4I15dyxVef@http.llvm.org/bugs/>

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

Bug 14330 depends on bug 14658, which changed state.

Bug 14658 Summary: debug info DW_AT_comp_dir is not the same path as that used to resolve file names
http://llvm.org/bugs/show_bug.cgi?id=14658

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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130426/37cba43e/attachment.html>

From bugzilla-daemon at llvm.org  Fri Apr 26 15:24:53 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 26 Apr 2013 22:24:53 +0000
Subject: [LLVMbugs] [Bug 15855] New: False positive null pointer dereference
 with integer arithmetic
Message-ID: <bug-15855-206@http.llvm.org/bugs/>

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

            Bug ID: 15855
           Summary: False positive null pointer dereference with integer
                    arithmetic
           Product: clang
           Version: trunk
          Hardware: Macintosh
                OS: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: Static Analyzer
          Assignee: kremenek at apple.com
          Reporter: bugzilla at jwwalker.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Overview:

I get a null pointer dereference warning that assumes a certain variable is
negative, when in fact one can easily deduce that the variable cannot be
negative.


Steps to reproduce:

Analyze this code:

-------------------------
static void Foo( int numFaces )
{
    int* ptr = 0;

    int absFaces;
    if (numFaces > 0)
    {
        absFaces = numFaces;
    }
    else
    {
        absFaces = - numFaces;
    }

    if (absFaces < 0)
    {
        *ptr = 99;
    }
}
-------------------------


Actual results:

"Dereference of null pointer (loaded from variable 'ptr')
  'ptr' initialized to a null pointer value
  Assuming 'numFaces' is <= 0
  Assuming 'absFaces' is < 0"


Expected results:

No warnings, or maybe something saying that a line is unreachable.


Build date:

clang version 3.3 (trunk 180622)
Target: x86_64-apple-darwin11.4.2
Thread model: posix

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130426/bcac3fbb/attachment.html>

From bugzilla-daemon at llvm.org  Fri Apr 26 17:53:33 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 27 Apr 2013 00:53:33 +0000
Subject: [LLVMbugs] [Bug 15763] emits PPC asm with relocation overflow,
 displacement too large [powerpc-darwin8]
In-Reply-To: <bug-15763-206@http.llvm.org/bugs/>
References: <bug-15763-206@http.llvm.org/bugs/>
Message-ID: <bug-15763-206-cIobQKmDzx@http.llvm.org/bugs/>

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

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

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

--- Comment #21 from Rafael Ávila de Espíndola <rafael.espindola at gmail.com> ---
Fixed in r180657.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130427/bd096a43/attachment.html>

From bugzilla-daemon at llvm.org  Sat Apr 27 08:59:35 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 27 Apr 2013 15:59:35 +0000
Subject: [LLVMbugs] [Bug 15852] using T::T inside template <typename T> not
 accepted, leads to bogus errors.
In-Reply-To: <bug-15852-206@http.llvm.org/bugs/>
References: <bug-15852-206@http.llvm.org/bugs/>
Message-ID: <bug-15852-206-g1I3IYlWfN@http.llvm.org/bugs/>

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

Richard Smith <richard-llvm at metafoo.co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |richard-llvm at metafoo.co.uk
         Resolution|---                         |WORKSFORME

--- Comment #2 from Richard Smith <richard-llvm at metafoo.co.uk> ---
That SVN checkout is too old; Clang did not fully support inheriting
constructors in r177638. Test case works fine in trunk.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130427/033db3e3/attachment.html>

From bugzilla-daemon at llvm.org  Sat Apr 27 12:06:20 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 27 Apr 2013 19:06:20 +0000
Subject: [LLVMbugs] [Bug 15857] New: BB vectorization: wrongly selected
 vectorization pair breaks load/store order
Message-ID: <bug-15857-206@http.llvm.org/bugs/>

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

            Bug ID: 15857
           Summary: BB vectorization: wrongly selected vectorization pair
                    breaks load/store order
           Product: new-bugs
           Version: trunk
          Hardware: Macintosh
                OS: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: dtakahashi42 at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

With the Basic Block vectorization, llvm can fuse multiple store instructions
into a vector instruction. However, it sometimes misses to find the depending
load instructions, and reverses the order of the load and the store
instructions.

The attached c-source and .ll testcase indicates this problem. After the BB
vectorization pass, the llvm assembly of,
  store double %sub3, double* %x, align 8                       ; 1.1
  store double 1.000000e+00, double* %y, align 8
  %0 = load double* %x, align 8                                 ; 1.2
  %arrayidx6 = getelementptr inbounds double* %x, i64 1
  store double %0, double* %arrayidx6, align 8                  ; 1.3
is transformed to,
  %0 = bitcast double* %x to <2 x double>*
  store double 1.000000e+00, double* %y, align 8
  %1 = load double* %x, align 8                                 ; 2.1
  %2 = insertelement <2 x double> undef, double %sub3, i32 0
  %3 = insertelement <2 x double> %2, double %1, i32 1
  store <2 x double> %3, <2 x double>* %0, align 8              ; 2.2
Before the optimization, %x is stored before its load (1.1 and 1.2), but after
then, the store instruction is fused to another store (1.3) and moved to the
last (2.2). As a result, the load instruction (2.1) loads an undesirable value.
I would like to make a simpler test case, but I could not do it because the
generated code is highly sensitive to the combination of optimization flags and
the lest of code.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130427/3a0bff9c/attachment.html>

From bugzilla-daemon at llvm.org  Sat Apr 27 12:31:46 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 27 Apr 2013 19:31:46 +0000
Subject: [LLVMbugs] [Bug 15858] New: Non-type parameter link failure
Message-ID: <bug-15858-206@http.llvm.org/bugs/>

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

            Bug ID: 15858
           Summary: Non-type parameter link failure
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++11
          Assignee: unassignedclangbugs at nondot.org
          Reporter: kjw.chiu at gmail.com
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified

When using decltype on a function pointer template parameter to define
a data member, it seems to generate an incorrect external reference.
This code:

    template <typename R, typename P, R F(P)>
    struct B {
        B() { v = F; }
        decltype(F) v;
    };

    void foo(int) {}

    int main() {
        B<void, int, &foo> o;
    }

results in this error:

    $ clang++ --version
    clang version 3.3 (trunk 180631)
    Target: x86_64-unknown-linux-gnu
    Thread model: posix
    $ clang++ -std=c++11 bug.cpp
    /tmp/bug-FYJpAX.o: In function `B<void, int, &(foo(int))>::B()':
   
bug.cpp:(.text._ZN1BIviXadL_Z3fooiEEEC2Ev[_ZN1BIviXadL_Z3fooiEEEC2Ev]+0x14):
undefined reference to `B<void, int, &(foo(int))>::v'
    clang: error: linker command failed with exit code 1 (use -v to see
invocation)

The compiler seems to have treated v as if it were a static data member.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130427/58a91094/attachment.html>

From bugzilla-daemon at llvm.org  Sat Apr 27 12:58:43 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 27 Apr 2013 19:58:43 +0000
Subject: [LLVMbugs] [Bug 15843] Scan-view pages return 404 file not found
In-Reply-To: <bug-15843-206@http.llvm.org/bugs/>
References: <bug-15843-206@http.llvm.org/bugs/>
Message-ID: <bug-15843-206-6AS5Ae28N2@http.llvm.org/bugs/>

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

Flaeme <Flaeme.flow at gmail.com> changed:

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

--- Comment #4 from Flaeme <Flaeme.flow at gmail.com> ---
Aha. Yes, that fixed it. Thanks for looking into it, it worked perfectly.
Marking as RESOLVED - WORKSFORME for now.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130427/a490ec44/attachment.html>

From bugzilla-daemon at llvm.org  Sat Apr 27 17:25:00 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 28 Apr 2013 00:25:00 +0000
Subject: [LLVMbugs] [Bug 15859] New: Variables named `_` should not trigger
 -Wunused-parameter
Message-ID: <bug-15859-206@http.llvm.org/bugs/>

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

            Bug ID: 15859
           Summary: Variables named `_` should not trigger
                    -Wunused-parameter
           Product: clang
           Version: unspecified
          Hardware: All
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: kenneth at ballenegger.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

It is common convention in other programming languages to use the variable name
`_` for unused parameters. In C, with blocks for callbacks, and in Objective-C
when using the delegation pattern, there are many valid use cases in which one
would not use a parameter (eg. when your block type / method signature is
defined in a third party api).

I think it would be best not to trigger the `unused-parameter` warning for
variables named `_`. That would enable users of the API to specify their
intention to actually not use the variable.

For example:

    - (IBAction)someAction:(id)_ { // <- warning, unused parameter
        printf("Hello, world!\n");
    }

Or:

    // In an API:
    void calculate_something(MyBlock callback);
    typedef void(^MyBlock)(int, char *info_message);

    // In end-developer code:
    {
        calculate_something(^(int i, char *_) { // <- warning
            printf("Int is: %d\n", i);
        });
    }

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130428/eac5bebd/attachment.html>

From bugzilla-daemon at llvm.org  Sat Apr 27 22:14:29 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 28 Apr 2013 05:14:29 +0000
Subject: [LLVMbugs] [Bug 15860] New: Constructor name resolution
Message-ID: <bug-15860-206@http.llvm.org/bugs/>

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

            Bug ID: 15860
           Summary: Constructor name resolution
           Product: clang
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
          Assignee: unassignedclangbugs at nondot.org
          Reporter: adamschn at umich.edu
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Clang compiles this sample fine:

struct foo {
  foo();
};

int main() { foo::foo bar; }

but both g++ and VS2012 reject it. The relevant section in the standard is
C++11[class.qual]p2, specifically:
 [...] the constructor is not an acceptable lookup result in an
 elaborated-type-specifier so the constructor would not be used
 in place of the injected-class-name [...]

Is clang being too permissive here?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130428/92832e15/attachment.html>

From bugzilla-daemon at llvm.org  Sun Apr 28 04:54:29 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 28 Apr 2013 11:54:29 +0000
Subject: [LLVMbugs] [Bug 15861] New: INVOKE ambiguously implemented
 (result_of and __invoke)
Message-ID: <bug-15861-206@http.llvm.org/bugs/>

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

            Bug ID: 15861
           Summary: INVOKE ambiguously implemented (result_of and
                    __invoke)
           Product: libc++
           Version: unspecified
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: All Bugs
          Assignee: hhinnant at apple.com
          Reporter: hivemaster at hotmail.de
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

The following example doesn't compile because of the ambiguous overloads of
`__invoke`:

#include <type_traits>

struct wat { wat& operator*() { return *this; } void foo(); };

int main(){
  using type = std::result_of<decltype(&wat::foo)(wat)>::type;
}

The standard (indirectly) states in 20.8.1 [func.require] p1 that the second
bullet only applies if the first bullet does not, through the restrictions on
the type of `t1`. The same problem appears with member data pointers (bullets 3
and 4).

One possible resolution is to remove the respective overloads from overload
resolution depending on whether the type of `t1` is a type derived from the
class of the member pointer.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130428/cb7016eb/attachment.html>

From bugzilla-daemon at llvm.org  Sun Apr 28 08:28:23 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 28 Apr 2013 15:28:23 +0000
Subject: [LLVMbugs] [Bug 15862] New: recipe for target all failed on
 i686-pc-cygwin on Vista 32bit with Cygwin
Message-ID: <bug-15862-206@http.llvm.org/bugs/>

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

            Bug ID: 15862
           Summary: recipe for target all failed on i686-pc-cygwin on
                    Vista 32bit with Cygwin
           Product: Build scripts
           Version: trunk
          Hardware: PC
                OS: other
            Status: NEW
          Severity: normal
          Priority: P
         Component: Makefiles
          Assignee: unassignedbugs at nondot.org
          Reporter: thadguidry at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Kathy at Kathy-PC ~/build
$ make
llvm[0]: Constructing LLVMBuild project information.
make[1]: Entering directory `/home/Kathy/build/lib/Support'
llvm[1]: Compiling APFloat.cpp for Debug+Asserts build
In file included from /home/Kathy/llvm/include/llvm/ADT/FoldingSet.h:20,
                 from /home/Kathy/llvm/lib/Support/APFloat.cpp:17:
/home/Kathy/llvm/include/llvm/ADT/StringRef.h:342: error: `template<class T>
typename llvm::enable_if_c<(! std::numeric_limits<_Tp>::is_signed), bool>::type
llvm::StringRef::getAsInteger(unsigned int, T&) const' and `template<class T>
typename llvm::enable_if_c< std::numeric_limits<_Tp>::is_signed, bool>::type
llvm::StringRef::getAsInteger(unsigned int, T&) const' cannot be overloaded
/home/Kathy/llvm/Makefile.rules:1615: recipe for target
`/home/Kathy/build/lib/Support/Debug+Asserts/APFloat.o' failed
make[1]: *** [/home/Kathy/build/lib/Support/Debug+Asserts/APFloat.o] Error 1
make[1]: Leaving directory `/home/Kathy/build/lib/Support'
/home/Kathy/llvm/Makefile.rules:866: recipe for target `all' failed
make: *** [all] Error 1

Kathy at Kathy-PC ~/build
$

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130428/f3b24a00/attachment.html>

From bugzilla-daemon at llvm.org  Sun Apr 28 10:45:51 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 28 Apr 2013 17:45:51 +0000
Subject: [LLVMbugs] [Bug 15863] New: Assertion `symIntExpr->getType() ==
 resultTy' failed
Message-ID: <bug-15863-206@http.llvm.org/bugs/>

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

            Bug ID: 15863
           Summary: Assertion `symIntExpr->getType() == resultTy' failed
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Static Analyzer
          Assignee: kremenek at apple.com
          Reporter: dimhen at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

[reduced from curl-7.21.3::curl_main.c]
$ cat x.i
_Bool a;
fn1 ()
{
    a = fn2 ();
    !a;
}

$ /home/dimhen/build/csa/Release+Asserts/bin/clang --version
clang version 3.3 (trunk 180688)
Target: x86_64-unknown-linux-gnu
Thread model: posix

$ /home/dimhen/build/csa/Release+Asserts/bin/clang --analyze x.i
clang:
/home/dimhen/src/llvm/tools/clang/lib/StaticAnalyzer/Core/SimpleSValBuilder.cpp:443:
virtual clang::ento::SVal
{anonymous}::SimpleSValBuilder::evalBinOpNN(clang::ento::ProgramStateRef,
clang::BinaryOperator::Opcode, clang::ento::NonLoc, clang::ento::NonLoc,
clang::QualType): Assertion `symIntExpr->getType() == resultTy' failed.
0  clang           0x0000000001deab62 _ZN4llvm3sys15PrintStackTraceEP8_IO_FILE
+ 34
1  clang           0x0000000001dea7b9
2  libpthread.so.0 0x0000003eb020f000
3  libc.so.6       0x0000003eafa35ba5 gsignal + 53
4  libc.so.6       0x0000003eafa37358 abort + 328
5  libc.so.6       0x0000003eafa2e972
6  libc.so.6       0x0000003eafa2ea22
7  clang           0x0000000000f21112
8  clang           0x0000000000ec45d5
_ZN5clang4ento10ExprEngine18VisitUnaryOperatorEPKNS_13UnaryOperatorEPNS0_12ExplodedNodeERNS0_15ExplodedNodeSetE
+ 2533
9  clang           0x0000000000eb4c05
_ZN5clang4ento10ExprEngine5VisitEPKNS_4StmtEPNS0_12ExplodedNodeERNS0_15ExplodedNodeSetE
+ 7269
10 clang           0x0000000000eb4f88
_ZN5clang4ento10ExprEngine11ProcessStmtENS_7CFGStmtEPNS0_12ExplodedNodeE + 712
11 clang           0x0000000000eb5263
_ZN5clang4ento10ExprEngine17processCFGElementENS_10CFGElementEPNS0_12ExplodedNodeEjPNS0_18NodeBuilderContextE
+ 227
12 clang           0x0000000000e9c180
_ZN5clang4ento10CoreEngine14HandlePostStmtEPKNS_8CFGBlockEjPNS0_12ExplodedNodeE
+ 128
13 clang           0x0000000000e9d04c
_ZN5clang4ento10CoreEngine16dispatchWorkItemEPNS0_12ExplodedNodeENS_12ProgramPointERKNS0_12WorkListUnitE
+ 92
14 clang           0x0000000000e9d40d
_ZN5clang4ento10CoreEngine15ExecuteWorkListEPKNS_15LocationContextEjN4llvm18IntrusiveRefCntPtrIKNS0_12ProgramStateEEE
+ 253
15 clang           0x0000000000d21210
16 clang           0x0000000000d21e7a
17 clang           0x0000000000d2de86
18 clang           0x000000000096058a _ZN5clang8ParseASTERNS_4SemaEbb + 538
19 clang           0x0000000000655519 _ZN5clang14FrontendAction7ExecuteEv + 265
20 clang           0x0000000000635905
_ZN5clang16CompilerInstance13ExecuteActionERNS_14FrontendActionE + 341
21 clang           0x000000000061cb72
_ZN5clang25ExecuteCompilerInvocationEPNS_16CompilerInstanceE + 1794
22 clang           0x0000000000614538 _Z8cc1_mainPPKcS1_S0_Pv + 888
23 clang           0x000000000061bdf0 main + 4992
24 libc.so.6       0x0000003eafa21a05 __libc_start_main + 245
25 clang           0x00000000006134f9
Stack dump:
0.    Program arguments: /home/dimhen/build/csa/Release+Asserts/bin/clang -cc1
-triple x86_64-unknown-linux-gnu -analyze -disable-free -main-file-name x.i
-analyzer-store=region -analyzer-opt-analyze-nested-blocks
-analyzer-eagerly-assume -analyzer-checker=core -analyzer-checker=unix
-analyzer-checker=deadcode
-analyzer-checker=security.insecureAPI.UncheckedReturn
-analyzer-checker=security.insecureAPI.getpw
-analyzer-checker=security.insecureAPI.gets
-analyzer-checker=security.insecureAPI.mktemp
-analyzer-checker=security.insecureAPI.mkstemp
-analyzer-checker=security.insecureAPI.vfork -analyzer-output plist -w
-mrelocation-model static -mdisable-fp-elim -fmath-errno -masm-verbose
-mconstructor-aliases -munwind-tables -fuse-init-array -target-cpu x86-64
-target-linker-version 2.23.51.0.1 -resource-dir
/home/dimhen/build/csa/Release+Asserts/bin/../lib/clang/3.3
-fdebug-compilation-dir /home/dimhen/errs/clang/curl_main -ferror-limit 19
-fmessage-length 173 -mstackrealign -fobjc-runtime=gcc
-fobjc-default-synthesize-properties -fdiagnostics-show-option
-fcolor-diagnostics -backend-option -vectorize-loops -o x.plist -x cpp-output
x.i 
1.    <eof> parser at end of file
2.    x.i:5:5: Error evaluating statement
3.    x.i:5:5: Error evaluating statement
clang: error: unable to execute command: Aborted (core dumped)
clang: error: clang frontend command failed due to signal (use -v to see
invocation)
clang version 3.3 (trunk 180688)
Target: x86_64-unknown-linux-gnu
Thread model: posix
clang: note: diagnostic msg: PLEASE submit a bug report to
http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and
associated run script.
clang: note: diagnostic msg: Error generating preprocessed source(s) - no
preprocessable inputs.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130428/8b859908/attachment.html>

From bugzilla-daemon at llvm.org  Mon Apr 29 06:03:57 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 29 Apr 2013 13:03:57 +0000
Subject: [LLVMbugs] [Bug 15860] Constructor name resolution
In-Reply-To: <bug-15860-206@http.llvm.org/bugs/>
References: <bug-15860-206@http.llvm.org/bugs/>
Message-ID: <bug-15860-206-3ksUDNuJeo@http.llvm.org/bugs/>

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

Richard Smith <richard-llvm at metafoo.co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |richard-llvm at metafoo.co.uk
         Resolution|---                         |DUPLICATE

--- Comment #1 from Richard Smith <richard-llvm at metafoo.co.uk> ---


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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130429/db6867fa/attachment.html>

From bugzilla-daemon at llvm.org  Mon Apr 29 07:36:19 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 29 Apr 2013 14:36:19 +0000
Subject: [LLVMbugs] [Bug 15843] Scan-view pages return 404 file not found
In-Reply-To: <bug-15843-206@http.llvm.org/bugs/>
References: <bug-15843-206@http.llvm.org/bugs/>
Message-ID: <bug-15843-206-997TMRelQU@http.llvm.org/bugs/>

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

Flaeme <Flaeme.flow at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|WORKSFORME                  |REMIND

--- Comment #5 from Flaeme <Flaeme.flow at gmail.com> ---
Oops, I am the worst at tags.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130429/79ae44a9/attachment.html>

From bugzilla-daemon at llvm.org  Mon Apr 29 09:33:37 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 29 Apr 2013 16:33:37 +0000
Subject: [LLVMbugs] [Bug 15864] New: _Atomic auto is accepted but not deduced
Message-ID: <bug-15864-206@http.llvm.org/bugs/>

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

            Bug ID: 15864
           Summary: _Atomic auto is accepted but not deduced
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++11
          Assignee: unassignedclangbugs at nondot.org
          Reporter: richard-llvm at metafoo.co.uk
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified

This crashes in CodeGen:

_Atomic auto n = 0;

... because we don't try to deduce the 'auto' type (because
getContainedAutoType doesn't find it). We can't deduce 'auto' in this position
anyway; we should either support such deduction and make it work or just reject
_Atomic auto.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130429/571cce51/attachment.html>

From bugzilla-daemon at llvm.org  Mon Apr 29 10:37:41 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 29 Apr 2013 17:37:41 +0000
Subject: [LLVMbugs] [Bug 15865] New: Clang fails to match ObjC pointers to
 pointer template parameters under ARC
Message-ID: <bug-15865-206@http.llvm.org/bugs/>

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

            Bug ID: 15865
           Summary: Clang fails to match ObjC pointers to pointer template
                    parameters under ARC
           Product: clang
           Version: 3.2
          Hardware: Macintosh
                OS: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++11
          Assignee: unassignedclangbugs at nondot.org
          Reporter: scoward at pivotallabs.com
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Summary:
When ARC is enabled, C++ candidate templates' pointer template parameters fail
to match objective-C object pointers.


Steps to reproduce:
Compile the following main.mm file, with and without ARC:

#import <Foundation/Foundation.h>

template <typename T>
void testing(const T & whoCares) {
    NSLog(@"================> Non pointer template");
}

template <typename T>
void testing(T * const & whoCares) {
    NSLog(@"================> Pointer template");
}

int main(int argc, const char * argv[])
{
    NSString *stringObject = @"hi";
    char *cString = "abc";
    testing(1);
    testing(cString);
    testing(stringObject);
    testing<NSString>(stringObject);
    return 0;
}


Expected Results:
The template with the pointer parameter should be instantiated for cString and
stringObject, without needing to parameterize the template explicitly, as
demonstrated by the output when compiled without ARC:

================> Non pointer template
================> Pointer template
================> Pointer template
================> Pointer template


Actual Results:
When ARC is enabled and the template is not parameterized explicitly, the
non-pointer template is instantiated if the pointer is an objective-c type, as
demonstrated by the output when compiled with ARC:

================> Non pointer template
================> Pointer template
================> Non pointer template         <== WRONG
================> Pointer template

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130429/49325757/attachment.html>

From bugzilla-daemon at llvm.org  Mon Apr 29 10:43:20 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 29 Apr 2013 17:43:20 +0000
Subject: [LLVMbugs] [Bug 15843] Scan-view pages return 404 file not found
In-Reply-To: <bug-15843-206@http.llvm.org/bugs/>
References: <bug-15843-206@http.llvm.org/bugs/>
Message-ID: <bug-15843-206-RNgLi0bmBy@http.llvm.org/bugs/>

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

Jordan Rose <jordan_rose at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jordan_rose at apple.com
         Resolution|REMIND                      |FIXED

--- Comment #6 from Jordan Rose <jordan_rose at apple.com> ---
Committed in r180715, so it'll go out in the next checker build.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130429/3fd91a17/attachment.html>

From bugzilla-daemon at llvm.org  Mon Apr 29 12:40:52 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 29 Apr 2013 19:40:52 +0000
Subject: [LLVMbugs] [Bug 15866] New: SROA builds needlessly complex
	shufflevectors
Message-ID: <bug-15866-206@http.llvm.org/bugs/>

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

            Bug ID: 15866
           Summary: SROA builds needlessly complex shufflevectors
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Scalar Optimizations
          Assignee: unassignedbugs at nondot.org
          Reporter: grosbach at apple.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 10439
  --> http://llvm.org/bugs/attachment.cgi?id=10439&action=edit
fubarness inside!

For the attached input, SROA creates a series of vector shuffles that just end
up recreating the original vector before storing it. No other optimization
cleans it up and codegen doesn't either, so we end up with horrible scalarized
vector operations.

In the attached testcase, using the inline function causes the above nastiness.
Interestingly, just replacing the call with the actual stores results in code
that works fine. See if "#if 0/#else" in the testcase.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130429/63039c02/attachment.html>

From bugzilla-daemon at llvm.org  Mon Apr 29 14:53:45 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 29 Apr 2013 21:53:45 +0000
Subject: [LLVMbugs] [Bug 15867] New: cin doesn't support unget()
Message-ID: <bug-15867-206@http.llvm.org/bugs/>

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

            Bug ID: 15867
           Summary: cin doesn't support unget()
           Product: libc++
           Version: unspecified
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: All Bugs
          Assignee: hhinnant at apple.com
          Reporter: joerg at NetBSD.org
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 10440
  --> http://llvm.org/bugs/attachment.cgi?id=10440&action=edit
Test case

See attached test case. There is at least one program (ATF) in the wild that
depends on this behavior, which works fine with libstdc++.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130429/264f04b0/attachment.html>

From bugzilla-daemon at llvm.org  Tue Apr 30 02:42:55 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 30 Apr 2013 09:42:55 +0000
Subject: [LLVMbugs] [Bug 15752] Current trunk miscompiles Firefox
In-Reply-To: <bug-15752-206@http.llvm.org/bugs/>
References: <bug-15752-206@http.llvm.org/bugs/>
Message-ID: <bug-15752-206-GC33g2dGZI@http.llvm.org/bugs/>

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

octoploid <octoploid at yandex.com> changed:

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

--- Comment #1 from octoploid <octoploid at yandex.com> ---
Must have been fixed in the last few days.
Firefox now starts without crashing.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130430/a27c190f/attachment.html>

From bugzilla-daemon at llvm.org  Tue Apr 30 07:25:25 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 30 Apr 2013 14:25:25 +0000
Subject: [LLVMbugs] [Bug 15868] New: Argument passing fails for large
 arguments type by value for arm.
Message-ID: <bug-15868-206@http.llvm.org/bugs/>

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

            Bug ID: 15868
           Summary: Argument passing fails for large arguments type by
                    value for arm.
           Product: clang
           Version: 3.2
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: LLVM Codegen
          Assignee: unassignedclangbugs at nondot.org
          Reporter: rahul.s1 at samsung.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 10441
  --> http://llvm.org/bugs/attachment.cgi?id=10441&action=edit
the test case

The architecture is Arm.


For the attached test cases,
when the structure passed is of large size , Clang is clearly sending a pointer
type to an address as function parameter.
but while accessing the parameter on callee side,
we are getting wrong values.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130430/063b0941/attachment.html>

From bugzilla-daemon at llvm.org  Tue Apr 30 08:39:19 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 30 Apr 2013 15:39:19 +0000
Subject: [LLVMbugs] [Bug 15869] New: DIE Value form not supported yet
Message-ID: <bug-15869-206@http.llvm.org/bugs/>

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

            Bug ID: 15869
           Summary: DIE Value form not supported yet
           Product: compiler-rt
           Version: unspecified
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: compiler-rt
          Assignee: unassignedbugs at nondot.org
          Reporter: andreas.boerner at w84u.org
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Compilation aborts with stack trace and the instruction to file a bug:

clang: note: diagnostic msg: PLEASE submit a bug report to
http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and
associated run script.


screen output:
DIE Value form not supported yet
UNREACHABLE executed at /mnt/data/pack/llvm/lib/CodeGen/AsmPrinter/DIE.cpp:243!
0  clang           0x0000000001b3dcb5 llvm::sys::PrintStackTrace(_IO_FILE*) +
37
1  clang           0x0000000001b3e1a3
2  libpthread.so.0 0x00002afc646b7cb0
3  libc.so.6       0x00002afc6552e425 gsignal + 53
4  libc.so.6       0x00002afc65531b8b abort + 379
5  clang           0x0000000001b2bf88 llvm::llvm_unreachable_internal(char
const*, char const*, unsigned int) + 440
6  clang           0x00000000015b018e
llvm::DIEInteger::SizeOf(llvm::AsmPrinter*, unsigned int) const + 206
7  clang           0x00000000015a2ef1
llvm::DwarfUnits::computeSizeAndOffset(llvm::DIE*, unsigned int) + 225
8  clang           0x00000000015a2f47
llvm::DwarfUnits::computeSizeAndOffset(llvm::DIE*, unsigned int) + 311
9  clang           0x00000000015a2f47
llvm::DwarfUnits::computeSizeAndOffset(llvm::DIE*, unsigned int) + 311
10 clang           0x00000000015a2f47
llvm::DwarfUnits::computeSizeAndOffset(llvm::DIE*, unsigned int) + 311
11 clang           0x00000000015a2f47
llvm::DwarfUnits::computeSizeAndOffset(llvm::DIE*, unsigned int) + 311
12 clang           0x000000000159c0ba llvm::DwarfDebug::finalizeModuleInfo() +
234
13 clang           0x000000000159c3e9 llvm::DwarfDebug::endModule() + 41
14 clang           0x000000000158d457
llvm::AsmPrinter::doFinalization(llvm::Module&) + 503
15 clang           0x0000000001adf33e
llvm::FPPassManager::doFinalization(llvm::Module&) + 94
16 clang           0x0000000001adf642
llvm::MPPassManager::runOnModule(llvm::Module&) + 674
17 clang           0x0000000001adfbeb llvm::PassManagerImpl::run(llvm::Module&)
+ 539
18 clang           0x0000000001adfd5a llvm::PassManager::run(llvm::Module&) +
10
19 clang           0x00000000007b0727
clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::CodeGenOptions
const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::Module*,
clang::BackendAction, llvm::raw_ostream*) + 6023
20 clang           0x00000000007ae2a3
21 clang           0x00000000008f75d3 clang::ParseAST(clang::Sema&, bool, bool)
+ 515
22 clang           0x00000000007ad5a2 clang::CodeGenAction::ExecuteAction() +
194
23 clang           0x0000000000634b31 clang::FrontendAction::Execute() + 113
24 clang           0x0000000000614a5d
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 909
25 clang           0x00000000005fb6c7
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 3031
26 clang           0x00000000005f260e cc1_main(char const**, char const**, char
const*, void*) + 574
27 clang           0x00000000005f8804 main + 7284
28 libc.so.6       0x00002afc6551976d __libc_start_main + 237
29 clang           0x00000000005f22ed
Stack dump:
0.    Program arguments: /mnt/data/pack/llvm-build/Release+Asserts/bin/clang
-cc1 -triple x86_64-unknown-linux-gnu -emit-obj -mrelax-all -disable-free
-main-file-name PrimeGenerator.cc -mrelocation-model static -mdisable-fp-elim
-fmath-errno -masm-verbose -mconstructor-aliases -munwind-tables
-fuse-init-array -target-cpu k8 -target-linker-version 2.22.90.20120924 -g
-coverage-file
/home/andy/hg/c2/apps/primeCounter/projects/clang++ut/CMakeFiles/pc.dir/home/andy/hg/c2/apps/primeCounter/src/common/PrimeGenerator.cc.o
-resource-dir /mnt/data/pack/llvm-build/Release+Asserts/bin/../lib/clang/3.3 -I
/mnt/data/pack/gcc-4-8-0/libstdc++-v3/include -I
/mnt/data/pack/libstc++/include -I /opt/gcc-4.8.0/include/c++/4.8.0 -I
/opt/gcc-4.8.0/include/c++/4.8.0/x86_64-unknown-linux-gnu -I
/home/andy/hg/c2/apps/primeCounter/projects/clang++ut/../../src/src_ut -I
/home/andy/hg/c2/apps/primeCounter/projects/clang++ut/../../src/common -I
/home/andy/hg/c2/apps/primeCounter/projects/clang++ut/../../src/common/framework
-I
/home/andy/hg/c2/apps/primeCounter/projects/clang++ut/../../src/common/framework/observer
-I
/home/andy/hg/c2/apps/primeCounter/projects/clang++ut/../../src/common/framework/system
-internal-isystem /usr/include/c++/v1 -internal-isystem /usr/local/include
-internal-isystem
/mnt/data/pack/llvm-build/Release+Asserts/bin/../lib/clang/3.3/include
-internal-externc-isystem /usr/include/x86_64-linux-gnu
-internal-externc-isystem /include -internal-externc-isystem /usr/include -O0
-Wall -Weffc++ -std=gnu++11 -fdeprecated-macro -fdebug-compilation-dir
/home/andy/hg/c2/apps/primeCounter/projects/clang++ut -ferror-limit 19
-fmessage-length 0 -mstackrealign -fobjc-runtime=gcc
-fobjc-default-synthesize-properties -fcxx-exceptions -fexceptions
-fdiagnostics-show-option -backend-option -vectorize-loops -o
CMakeFiles/pc.dir/home/andy/hg/c2/apps/primeCounter/src/common/PrimeGenerator.cc.o
-x c++ /home/andy/hg/c2/apps/primeCounter/src/common/PrimeGenerator.cc 
1.    <eof> parser at end of file
2.    Code generation
clang: error: unable to execute command: Aborted (core dumped)
clang: error: clang frontend command failed due to signal (use -v to see
invocation)
clang version 3.3 (trunk 178622)
Target: x86_64-unknown-linux-gnu
Thread model: posix
clang: note: diagnostic msg: PLEASE submit a bug report to
http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and
associated run script.
clang: note: diagnostic msg: 
********************

PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang: note: diagnostic msg: /tmp/PrimeGenerator-dhS2Fc.cpp
clang: note: diagnostic msg: /tmp/PrimeGenerator-dhS2Fc.sh
clang: note: diagnostic msg: 

********************


===================================
the content of /tmp/PrimeGenerator-dhS2Fc.sh is:

/mnt/data/pack/llvm-build/Release+Asserts/bin/clang -cc1 -triple
x86_64-unknown-linux-gnu -emit-obj -mrelax-all -disable-free -main-file-name
PrimeGenerator.cc -mrelocation-model static -mdisable-fp-elim -fmath-errno
-masm-verbose -mconstructor-aliases -munwind-tables -fuse-init-array
-target-cpu k8 -target-linker-version 2.22.90.20120924 -g -O0 -Wall -Weffc++
-std=gnu++11 -fdeprecated-macro -ferror-limit 19 -fmessage-length 0
-mstackrealign -fobjc-runtime=gcc -fobjc-default-synthesize-properties
-fcxx-exceptions -fexceptions -fdiagnostics-show-option -backend-option
-vectorize-loops -x c++ PrimeGenerator-dhS2Fc.cpp

===================================
$ clang++ --version
clang version 3.3 (trunk 178622)
Target: x86_64-unknown-linux-gnu
Thread model: posix

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130430/5c0fccb7/attachment.html>

From bugzilla-daemon at llvm.org  Tue Apr 30 09:21:29 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 30 Apr 2013 16:21:29 +0000
Subject: [LLVMbugs] [Bug 15870] New: Xcode 4.6 static analyzer false
 positive calling non-virtual C++ methods on NULL pointers where method
 implementation provides NULL check
Message-ID: <bug-15870-206@http.llvm.org/bugs/>

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

            Bug ID: 15870
           Summary: Xcode 4.6 static analyzer false positive calling
                    non-virtual C++ methods on NULL pointers where method
                    implementation provides NULL check
           Product: clang
           Version: unspecified
          Hardware: Macintosh
                OS: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: Static Analyzer
          Assignee: kremenek at apple.com
          Reporter: rob at ragfield.name
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Run the following code through the Xcode 4.6.2 static analyzer:


#include <iostream>
#include <math.h>

class FooBar
{
public:
    void method() { std::cout << "this is " << (this ? "NOT NULL" : "NULL") <<
"\n"; }
};

int main(int argc, const char * argv[])
{
    FooBar* foo = NULL;
    foo->method();
    return 0;
}


It produces the following issue:

FooBar/main.cpp:21:2: Called C++ object pointer is null

even though the code works fine.  My large project has this issue flagged
hundreds of times, making the static analyzer not as useful to me as it used to
be.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130430/8ffb5b40/attachment.html>

From bugzilla-daemon at llvm.org  Tue Apr 30 09:31:00 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 30 Apr 2013 16:31:00 +0000
Subject: [LLVMbugs] [Bug 15871] New: Clang hangs with -backend-option
	-vectorize-loops
Message-ID: <bug-15871-206@http.llvm.org/bugs/>

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

            Bug ID: 15871
           Summary: Clang hangs with -backend-option -vectorize-loops
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: choller at mozilla.com
                CC: llvmbugs at cs.uiuc.edu, rafael.espindola at gmail.com
    Classification: Unclassified

I've hit this when building mozilla-central and reduced the original C file
from 30k lines down to this small (but nonsense) example:


enum __rlimit_resource {
        RUSAGE_SELF = 0
};
struct event {
        struct event_base *ev_base;
};
int min_heap_elem_greater(
                        //struct event *a, 
                        struct event *b
                        ) {}
struct eventop {
        X(event_io_map, event_map_entry);
        struct event_base {
                const struct eventop *evsel;
        };
};



When compiling this with the following command line:

llvm/build/bin/clang-3.3 -cc1 -emit-obj -backend-option -vectorize-loops test.c

my clang hangs and seems to infinitely loop. Removing the backend-option
vectorize-loops seems to resolve the problem. Tested on LLVM r180778.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130430/0f698e03/attachment.html>

From bugzilla-daemon at llvm.org  Tue Apr 30 12:11:22 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 30 Apr 2013 19:11:22 +0000
Subject: [LLVMbugs] [Bug 15872] New: some shuffles get decomposed to
 insert/extract sequence with avx
Message-ID: <bug-15872-206@http.llvm.org/bugs/>

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

            Bug ID: 15872
           Summary: some shuffles get decomposed to insert/extract
                    sequence with avx
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: X86
          Assignee: unassignedbugs at nondot.org
          Reporter: sroland at vmware.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Some rather simple but non-native shuffles produce completely horrendous code
because they get decomposed to single element inserts/extracts.
Here's an example:

define <4 x i32> @shuf(<8 x i32> %inval, <4 x i32>* %ptr1) {
entry:
  %0 = shufflevector <8 x i32> %inval, <8 x i32> %inval, <4 x i32> <i32 0, i32
1, i32 4, i32 5>
  %1 = shufflevector <8 x i32> %inval, <8 x i32> %inval, <4 x i32> <i32 2, i32
3, i32 6, i32 7>
  store <4 x i32> %0, <4 x i32>* %ptr1, align 16
  ret <4 x i32> %1

This generates:

        vpextrd $1, %xmm0, %eax
        vmovd   %xmm0, %ecx
        vmovd   %ecx, %xmm1
        vpinsrd $1, %eax, %xmm1, %xmm2
        vextractf128    $1, %ymm0, %xmm1
        vmovd   %xmm1, %eax
        vpinsrd $2, %eax, %xmm2, %xmm2
        vpextrd $1, %xmm1, %eax
        vpinsrd $3, %eax, %xmm2, %xmm2
        vmovdqa %xmm2, (%rdi)
        vpextrd $3, %xmm0, %eax
        vpextrd $2, %xmm0, %ecx
        vmovd   %ecx, %xmm0
        vpinsrd $1, %eax, %xmm0, %xmm0
        vpextrd $2, %xmm1, %eax
        vpinsrd $2, %eax, %xmm0, %xmm0
        vpextrd $3, %xmm1, %eax
        vpinsrd $3, %eax, %xmm0, %xmm0
        vzeroupper
        ret

which is quite obviously a disaster.
(With float instead of i32 values it will produce
        vpshufd $1, %xmm0, %xmm1
        vinsertps       $16, %xmm1, %xmm0, %xmm2
        vextractf128    $1, %ymm0, %xmm1
        vinsertps       $32, %xmm1, %xmm2, %xmm2
        vpshufd $1, %xmm1, %xmm3
        vinsertps       $48, %xmm3, %xmm2, %xmm2
        vmovaps %xmm2, (%rdi)
        vpshufd $3, %xmm0, %xmm2
        vmovhlps        %xmm0, %xmm0, %xmm0
        vinsertps       $16, %xmm2, %xmm0, %xmm0
        vmovhlps        %xmm1, %xmm1, %xmm2
        vinsertps       $32, %xmm2, %xmm0, %xmm0
        vpshufd $3, %xmm1, %xmm1
        vinsertps       $48, %xmm1, %xmm0, %xmm0
        vzeroupper
        ret
which is not really much better neither.)

But this should really just be (or something similar, there's quite some
options, for instance using vshufps):
        vextractf128    $1, %ymm0, %xmm1
        vmovlhps        %xmm0, %xmm1, %xmm2
        vmovaps         %xmm2, (%rdi)
        vunpckhpd       %xmm0, %xmm1, %xmm0
        vzeroupper
        ret

This is somewhat similar to http://llvm.org/bugs/show_bug.cgi?id=12413 but that
one was fixed.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130430/6370ad7b/attachment.html>

From bugzilla-daemon at llvm.org  Tue Apr 30 12:59:54 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 30 Apr 2013 19:59:54 +0000
Subject: [LLVMbugs] [Bug 15873] New: IR Builder: Ability to insert comments
Message-ID: <bug-15873-206@http.llvm.org/bugs/>

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

            Bug ID: 15873
           Summary: IR Builder: Ability to insert comments
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Bitcode Writer
          Assignee: unassignedbugs at nondot.org
          Reporter: superjoe30 at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

When writing a program that uses the IR Builder to generate IR code, it would
be extremely helpful to be able to insert comments so that when you look at
module.Dump() you can see some debug information.

For example, something like this:

LLVMBasicBlockRef entry = LLVMAppendBasicBlock(fac, "entry");
LLVMPrependComment(entry, "converted from such and such code");
...
LLVMValueRef If = LLVMBuildICmp(builder, LLVMIntEQ, n,
LLVMConstInt(LLVMInt32Type(), 0, 0), "n == 0");
LLVMPrependComment(If, "blah blah blah");

And when the module is dumped, looks something like this:

; converted from such and such code
entry:

...

; blah blah blah
%0 = icmp eq i32 0, 0

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130430/506a7be9/attachment.html>

From bugzilla-daemon at llvm.org  Tue Apr 30 13:33:23 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 30 Apr 2013 20:33:23 +0000
Subject: [LLVMbugs] [Bug 8605] [X86 COFF MC Assembler] Unsupported
 EmitRawText called on Windows
In-Reply-To: <bug-8605-206@http.llvm.org/bugs/>
References: <bug-8605-206@http.llvm.org/bugs/>
Message-ID: <bug-8605-206-GJ8ISWF24y@http.llvm.org/bugs/>

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

reid.kleckner at gmail.com <reid.kleckner at gmail.com> changed:

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

--- Comment #13 from reid.kleckner at gmail.com <reid.kleckner at gmail.com> ---
This appears to have been fixed.  'llc -filetype=obj simple.ll' works for me on
Windows.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130430/3f82a7da/attachment.html>

From bugzilla-daemon at llvm.org  Tue Apr 30 13:33:25 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 30 Apr 2013 20:33:25 +0000
Subject: [LLVMbugs] [Bug 13707] [meta] VCPP compatibility issues
In-Reply-To: <bug-13707-206@http.llvm.org/bugs/>
References: <bug-13707-206@http.llvm.org/bugs/>
Message-ID: <bug-13707-206-s7FlOutYFu@http.llvm.org/bugs/>

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

Bug 13707 depends on bug 8605, which changed state.

Bug 8605 Summary: [X86 COFF MC Assembler] Unsupported EmitRawText called on Windows
http://llvm.org/bugs/show_bug.cgi?id=8605

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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130430/fa073772/attachment.html>

From bugzilla-daemon at llvm.org  Tue Apr 30 13:54:39 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 30 Apr 2013 20:54:39 +0000
Subject: [LLVMbugs] [Bug 15866] SROA builds needlessly complex shufflevectors
In-Reply-To: <bug-15866-206@http.llvm.org/bugs/>
References: <bug-15866-206@http.llvm.org/bugs/>
Message-ID: <bug-15866-206-WImrXDQEH0@http.llvm.org/bugs/>

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

Jim Grosbach <grosbach at apple.com> changed:

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

--- Comment #8 from Jim Grosbach <grosbach at apple.com> ---
r180802

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130430/3aabf329/attachment.html>

From bugzilla-daemon at llvm.org  Tue Apr 30 15:59:00 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 30 Apr 2013 22:59:00 +0000
Subject: [LLVMbugs] [Bug 15874] New: crash when compiling with armadillo
	library
Message-ID: <bug-15874-206@http.llvm.org/bugs/>

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

            Bug ID: 15874
           Summary: crash when compiling with armadillo library
           Product: clang
           Version: 3.2
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: mousekrup at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 10445
  --> http://llvm.org/bugs/attachment.cgi?id=10445&action=edit
source files as came from

Clang crashed when I was trying to compile attached code. I believe the
armadillo library is the cause.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130430/dd69ce89/attachment.html>

From bugzilla-daemon at llvm.org  Tue Apr 30 16:23:27 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 30 Apr 2013 23:23:27 +0000
Subject: [LLVMbugs] [Bug 15875] New: [-cxx-abi microsoft] Implement standard
 member pointers
Message-ID: <bug-15875-206@http.llvm.org/bugs/>

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

            Bug ID: 15875
           Summary: [-cxx-abi microsoft] Implement standard member
                    pointers
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Windows XP
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: C++
          Assignee: unassignedclangbugs at nondot.org
          Reporter: reid.kleckner at gmail.com
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified

This issue covers finishing up all the member pointer related issues in the
MSVC C++ ABI.

Things that are done:
- null memptr emission
- null testing
- memptr comparison
- data memptr emission

Things TODO that I'm aware of:
- func memptr emission
- virtual func memptr emission (requires vcall thunks)
- memptr conversion
- constant memptr emission, which requires applying a conversion at compile
time to make an llvm::Constant.
- memptr conversion through a virtually derived class (http://llvm.org/PR15713)

This is separate from http://llvm.org/PR15713, which is about implementing
conversions through virtual bases.  I may hit that as I work through these
issues, but I consider it a nice to have.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130430/1f50a531/attachment.html>

From bugzilla-daemon at llvm.org  Tue Apr 30 18:00:56 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 01 May 2013 01:00:56 +0000
Subject: [LLVMbugs] [Bug 12148] alignment of empty base class not inherited
In-Reply-To: <bug-12148-206@http.llvm.org/bugs/>
References: <bug-12148-206@http.llvm.org/bugs/>
Message-ID: <bug-12148-206-CxwTYo2FGZ@http.llvm.org/bugs/>

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

Richard Smith <richard-llvm at metafoo.co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |richard-llvm at metafoo.co.uk
         Resolution|---                         |DUPLICATE

--- Comment #3 from Richard Smith <richard-llvm at metafoo.co.uk> ---


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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130501/fe9b27e0/attachment.html>

From bugzilla-daemon at llvm.org  Tue Apr 30 18:13:17 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 01 May 2013 01:13:17 +0000
Subject: [LLVMbugs] [Bug 15876] New: Assertion `i == DstIdx ||
 !MI->getOperand(i).isReg() || MI->getOperand(i).getReg() != RegA' failed
Message-ID: <bug-15876-206@http.llvm.org/bugs/>

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

            Bug ID: 15876
           Summary: Assertion `i == DstIdx || !MI->getOperand(i).isReg()
                    || MI->getOperand(i).getReg() != RegA' failed
           Product: new-bugs
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: clang at martinien.de
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Hi,

the following inline asm causes an assert on current trunk/Linux x86-64.
Removing e.g. the "eax" in the destroyed register list makes it work.


void f()
{
    int i = 1, eax;
    __asm__ ("nop"
        : "=a" (eax)
        : "0" (i)
        : "eax" );
}


clang: /local/mar_/llvmtrunk/lib/CodeGen/TwoAddressInstructionPass.cpp:1384:
void <anonymous
namespace>::TwoAddressInstructionPass::processTiedPairs(llvm::MachineInstr *,
TiedPairList &, unsigned int &): Assertion `i == DstIdx ||
!MI->getOperand(i).isReg() || MI->getOperand(i).getReg() != RegA' failed.
0  clang           0x0000000001f34af2 _ZN4llvm3sys15PrintStackTraceEP8_IO_FILE
+ 34
1  clang           0x0000000001f35023
2  libpthread.so.0 0x00002ad848dfe6b0
3  libc.so.6       0x00002ad849bc5945 gsignal + 53
4  libc.so.6       0x00002ad849bc6f21 abort + 385
5  libc.so.6       0x00002ad849bbe810 __assert_fail + 240
6  clang           0x0000000001ab2eeb
7  clang           0x00000000019ebd54
_ZN4llvm19MachineFunctionPass13runOnFunctionERNS_8FunctionE + 116
8  clang           0x0000000001ed3c0c
_ZN4llvm13FPPassManager13runOnFunctionERNS_8FunctionE + 444
9  clang           0x0000000001ed3e0b
_ZN4llvm13FPPassManager11runOnModuleERNS_6ModuleE + 59
10 clang           0x0000000001ed417e
_ZN4llvm13MPPassManager11runOnModuleERNS_6ModuleE + 494
11 clang           0x0000000001ed4788
_ZN4llvm15PassManagerImpl3runERNS_6ModuleE + 456
12 clang           0x0000000001ed492a _ZN4llvm11PassManager3runERNS_6ModuleE +
10
13 clang           0x00000000008152a7
_ZN5clang17EmitBackendOutputERNS_17DiagnosticsEngineERKNS_14CodeGenOptionsERKNS_13TargetOptionsERKNS_11LangOptionsEPN4llvm6ModuleENS_13BackendActionEPNSB_11raw_ostreamE
+ 6039
14 clang           0x0000000000812dea
15 clang           0x000000000095d9c5 _ZN5clang8ParseASTERNS_4SemaEbb + 549
16 clang           0x0000000000812034 _ZN5clang13CodeGenAction13ExecuteActionEv
+ 196
17 clang           0x000000000069ae27 _ZN5clang14FrontendAction7ExecuteEv + 119
18 clang           0x0000000000679c6d
_ZN5clang16CompilerInstance13ExecuteActionERNS_14FrontendActionE + 989
19 clang           0x00000000006602a2
_ZN5clang25ExecuteCompilerInvocationEPNS_16CompilerInstanceE + 3778
20 clang           0x0000000000656924 _Z8cc1_mainPPKcS1_S0_Pv + 772
21 clang           0x000000000065d310 main + 7328
22 libc.so.6       0x00002ad849bb1bc6 __libc_start_main + 230
23 clang           0x0000000000656559


1.      <eof> parser at end of file
2.      Code generation
3.      Running pass 'Function Pass Manager' on module 'm.cpp'.
4.      Running pass 'Two-Address instruction pass' on function '@_Z1fv'
clang: error: unable to execute command: Aborted
clang: error: clang frontend command failed due to signal (use -v to see
invocation)
clang version 3.3 (trunk 180834)
Target: x86_64-unknown-linux-gnu
Thread model: posix


Best regards,
Martin

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130501/a3ee9019/attachment.html>

From bugzilla-daemon at llvm.org  Tue Apr 30 18:32:05 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 01 May 2013 01:32:05 +0000
Subject: [LLVMbugs] [Bug 15877] New: configure complains that cxxabi.h is
 present but cannot be compiled
Message-ID: <bug-15877-206@http.llvm.org/bugs/>

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

            Bug ID: 15877
           Summary: configure complains that cxxabi.h is present but
                    cannot be compiled
           Product: Build scripts
           Version: trunk
          Hardware: Macintosh
                OS: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: autoconf
          Assignee: unassignedbugs at nondot.org
          Reporter: bugzilla at jwwalker.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

I was in a build directory that's a sibling of the llvm repository directory,
and typed

  ../llvm/configure --prefix=/opt --enable-optimized

Among lots of output was this:

checking cxxabi.h usability... no
checking cxxabi.h presence... yes
configure: WARNING: cxxabi.h: present but cannot be compiled
configure: WARNING: cxxabi.h:     check for missing prerequisite headers?
configure: WARNING: cxxabi.h: see the Autoconf documentation
configure: WARNING: cxxabi.h:     section "Present But Cannot Be Compiled"
configure: WARNING: cxxabi.h: proceeding with the preprocessor's result
configure: WARNING: cxxabi.h: in the future, the compiler will take precedence
configure: WARNING:     ## ------------------------------------ ##
configure: WARNING:     ## Report this to http://llvm.org/bugs/ ##
configure: WARNING:     ## ------------------------------------ ##
checking for cxxabi.h... yes


I don't know what it's about, but it says to report it.

llvm svn revision 180835.  Mac OS X 10.7.5.  Xcode 4.6.2.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130501/4621b5e3/attachment.html>

From bugzilla-daemon at llvm.org  Tue Apr 30 18:42:53 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 01 May 2013 01:42:53 +0000
Subject: [LLVMbugs] [Bug 15878] New: partial specialization of template
 class after using namespace causes non-template class error
Message-ID: <bug-15878-206@http.llvm.org/bugs/>

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

            Bug ID: 15878
           Summary: partial specialization of template class after using
                    namespace causes non-template class error
           Product: clang
           Version: 3.1
          Hardware: PC
                OS: Windows XP
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
          Assignee: unassignedclangbugs at nondot.org
          Reporter: mmehlich at semanticdesigns.com
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Code:

namespace A {
    namespace B {
        template <typename T> class X;
    }
    using namespace B;
    template<typename T> class X;
    template<typename T> class X<T*> { };
};

clang 3.1 output:

>>> clang test.cpp
test.cpp:7:29: error: explicit specialization of non-template class 'X'
        template<typename T> class X<T*> { };
                                   ^~~~~
1 error generated.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130501/00de8370/attachment.html>

From bugzilla-daemon at llvm.org  Tue Apr 30 20:25:38 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 01 May 2013 03:25:38 +0000
Subject: [LLVMbugs] [Bug 15880] New: Attempts to generate x86 rol
 instructions yield sub-optimal results
Message-ID: <bug-15880-206@http.llvm.org/bugs/>

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

            Bug ID: 15880
           Summary: Attempts to generate x86 rol instructions yield
                    sub-optimal results
           Product: libraries
           Version: 3.2
          Hardware: Macintosh
                OS: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: X86
          Assignee: unassignedbugs at nondot.org
          Reporter: crynoid2k7 at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 10446
  --> http://llvm.org/bugs/attachment.cgi?id=10446&action=edit
tarball containing llvm and resulting x86 asm for 8,16,32, and 64 bit single
and double rotates

The x86 backend recognizes a rotate-left by N bits from an expression shifted
left by N OR'd with the same expression shifted right by the width of the
expression minus N.

It should always generate a rol instruction for 8, 16, 32, and 64 bit operands;
however, for 16 bit operands it selects a shldw instruction with the src and
dst operands equal.  While functionally correct, the opcode is suboptimal (is
there ever a scenario where shld c, X, X is preferable to rol c, X?).

Furthermore, if you perform two back-to-back rotates to an expression, the 8
and 32 bit versions use back-to-back rol instructions, the 16 bit version uses
two back-to-back shldw instructions, and the 64-bit version performs a shldq
followed by a rolq.

The same behavior manifests for right rotates.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130501/102dd150/attachment.html>

From bugzilla-daemon at llvm.org  Tue Apr 30 20:27:16 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 01 May 2013 03:27:16 +0000
Subject: [LLVMbugs] [Bug 15881] New: clang fails to detect delete x; return x
Message-ID: <bug-15881-206@http.llvm.org/bugs/>

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

            Bug ID: 15881
           Summary: clang fails to detect delete x; return x
           Product: clang
           Version: unspecified
          Hardware: Macintosh
                OS: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: Static Analyzer
          Assignee: kremenek at apple.com
          Reporter: peter at stairways.com.au
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Mac, Xcode 4.6.2, Apple LLVM version 4.2 (clang-425.0.24) (based on LLVM
3.2svn), Objective C++.

Neither clang with lots of warning enabled, nor the static analyser detect this
simple failure case:

HBaseAction*
AMouseMoveAndClick::Merge( HBaseAction* action )
{
    AMouseMoveAndClick* newAction = new AMouseMoveAndClick( *this );
    delete newAction;
    return newAction;
}

Shouldn't pretty much any use of a deleted variable be flagged as an error?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130501/242f2981/attachment.html>

From bugzilla-daemon at llvm.org  Tue Apr 30 21:24:01 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 01 May 2013 04:24:01 +0000
Subject: [LLVMbugs] [Bug 15882] New: opt -loop-vectorize breaks this function
Message-ID: <bug-15882-206@http.llvm.org/bugs/>

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

            Bug ID: 15882
           Summary: opt -loop-vectorize breaks this function
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Interprocedural Optimizations
          Assignee: unassignedbugs at nondot.org
          Reporter: rafael.espindola at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 10447
  --> http://llvm.org/bugs/attachment.cgi?id=10447&action=edit
testcase

Producing a .o from this testcase and linking it with the rest of firefox
produces a working binary.

Running opt -loop-vectorize on this single (but large) function produces a
browser that crashes at startup.

Hopefully this is enough for someone familiar with the vectorizer to see what
is going wrong, but if not I can try to put the remaining object files
somewhere (or reduce this further, but probably not this week).

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130501/b5b0182a/attachment.html>

From bugzilla-daemon at llvm.org  Tue Apr 30 23:59:01 2013
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 01 May 2013 06:59:01 +0000
Subject: [LLVMbugs] [Bug 15845] Clang accepts invalid code
In-Reply-To: <bug-15845-206@http.llvm.org/bugs/>
References: <bug-15845-206@http.llvm.org/bugs/>
Message-ID: <bug-15845-206-eHLPsCabU2@http.llvm.org/bugs/>

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

Serge Pavlov <sepavloff at gmail.com> changed:

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

--- Comment #6 from Serge Pavlov <sepavloff at gmail.com> ---
Fixed in r180822.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130501/ed5ac46a/attachment.html>