From bugzilla-daemon at llvm.org  Sat Nov  1 01:17:33 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 01 Nov 2014 08:17:33 +0000
Subject: [LLVMbugs] [Bug 21440] Inconsistent Output at O1 optimization level
In-Reply-To: <bug-21440-206@http.llvm.org/bugs/>
References: <bug-21440-206@http.llvm.org/bugs/>
Message-ID: <bug-21440-206-Y6bhvJ4BPJ@http.llvm.org/bugs/>

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

Suyog Sarda <sardask01 at gmail.com> changed:

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

--- Comment #5 from Suyog Sarda <sardask01 at gmail.com> ---
-fwrapv flag make things clear.

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

From bugzilla-daemon at llvm.org  Sat Nov  1 01:25:54 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 01 Nov 2014 08:25:54 +0000
Subject: [LLVMbugs] [Bug 21441] New: Please change clang's component C++1y
 to C++14, and add component C++1z
Message-ID: <bug-21441-206@http.llvm.org/bugs/>

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

            Bug ID: 21441
           Summary: Please change clang's component C++1y to C++14, and
                    add component C++1z
           Product: Bugzilla Admin
           Version: unspecified
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Products
          Assignee: unassignedbugs at nondot.org
          Reporter: jonathan.sauer at gmx.de
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

As C++14 has been published, clang's component "C++1y" should be renamed to
"C++14". Also, as clang has been gaining initial support for C++1z, a component
"C++1z" should be added 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/20141101/5746a142/attachment.html>

From bugzilla-daemon at llvm.org  Sat Nov  1 01:32:05 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 01 Nov 2014 08:32:05 +0000
Subject: [LLVMbugs] [Bug 21442] New: Product "Packaging",
 component "binary tarballs" does not CC llvmbugs@cs.uiuc.edu by
 default
Message-ID: <bug-21442-206@http.llvm.org/bugs/>

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

            Bug ID: 21442
           Summary: Product "Packaging", component "binary tarballs" does
                    not CC llvmbugs at cs.uiuc.edu by default
           Product: Bugzilla Admin
           Version: unspecified
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Mail
          Assignee: unassignedbugs at nondot.org
          Reporter: jonathan.sauer at gmx.de
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Summary says it all: Currently the Bugzilla product "Packaging"'s component
"binary tarballs" does not automatically add llvmbugs at cs.uiuc.edu to a new
bug's CC list.

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

From bugzilla-daemon at llvm.org  Sat Nov  1 04:58:15 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 01 Nov 2014 11:58:15 +0000
Subject: [LLVMbugs] [Bug 21443] New: [PPC64] Wrong register generated for
 inline assembler
Message-ID: <bug-21443-206@http.llvm.org/bugs/>

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

            Bug ID: 21443
           Summary: [PPC64] Wrong register generated for inline assembler
           Product: libraries
           Version: trunk
          Hardware: All
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: PowerPC
          Assignee: unassignedbugs at nondot.org
          Reporter: kai at redstar.de
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 13270
  --> http://llvm.org/bugs/attachment.cgi?id=13270&action=edit
.ll file demonstrating the bug

The attached file ppc_inline.ll works fine if compiled with -O0 but not with a
higher optimization level. Root cause is that a std 23, 0(0) is generated which
causes a segmentation fault.

The original source is part of the D runtime library, see here:
https://github.com/ldc-developers/druntime/blob/ldc/src/core/thread.d#L2148

The purpose of the code is to store all nonvolatile GPRs on the stack to enable
the garbage collector to scan the register 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/20141101/4597e9ea/attachment.html>

From bugzilla-daemon at llvm.org  Sat Nov  1 09:38:29 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 01 Nov 2014 16:38:29 +0000
Subject: [LLVMbugs] [Bug 21444] New: Simple _Unwind_Backtrace test fails on
	ARM
Message-ID: <bug-21444-206@http.llvm.org/bugs/>

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

            Bug ID: 21444
           Summary: Simple _Unwind_Backtrace test fails on ARM
           Product: libc++abi
           Version: unspecified
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: All Bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: renato.golin at linaro.org
                CC: llvmbugs at cs.uiuc.edu, mclow.lists at gmail.com
    Classification: Unclassified

http://lab.llvm.org:8011/builders/libcxx-libcxxabi-arm-linux/builds/23/steps/test.libcxxabi/logs/stdio

backtrace_test.cpp:59: int main(): Assertion `nothrow_ntraced > 1' 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/20141101/6ed9cfd0/attachment.html>

From bugzilla-daemon at llvm.org  Sat Nov  1 11:43:56 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 01 Nov 2014 18:43:56 +0000
Subject: [LLVMbugs] [Bug 21445] New: clang crashes on valid code at -O1 and
 above on x86_64-linux-gnu
Message-ID: <bug-21445-206@http.llvm.org/bugs/>

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

            Bug ID: 21445
           Summary: clang crashes on valid code at -O1 and above on
                    x86_64-linux-gnu
           Product: clang
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: su at cs.ucdavis.edu
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

The current clang trunk and 3.5.0 crash when compiling the following test case
at -O1 and above in both 32-bit and 64-bit modes on x86_64-linux-gnu. 

This is a regression from clang 3.4.x. 

$ clang-trunk -v
clang version 3.6.0 (trunk 220897)
Target: x86_64-unknown-linux-gnu
Thread model: posix
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6.4
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7.3
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8.1
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Selected multilib: .;@m64
$ 
$ clang-trunk -O0 -c small.c
$ clang-3.4.2 -O1 -c small.c
$ 
$ clang-trunk -O1 -c small.c
clang: /tmp/llvm/include/llvm/Support/Casting.h:237: typename cast_retty<X, Y
*>::ret_type llvm::cast(Y *) [X = llvm::Instruction, Y = llvm::Value]:
Assertion `isa<X>(Val) && "cast<Ty>() argument of incompatible type!"' failed.
#0 0x28de3fa llvm::sys::PrintStackTrace(_IO_FILE*)
(/usr/local/clang-trunk/bin/clang+0x28de3fa)
#1 0x28dfabb (/usr/local/clang-trunk/bin/clang+0x28dfabb)
#2 0x7f9caa08acb0 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0xfcb0)
#3 0x7f9ca93c30d5 gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x360d5)
#4 0x7f9ca93c683b abort (/lib/x86_64-linux-gnu/libc.so.6+0x3983b)
#5 0x7f9ca93bbd9e (/lib/x86_64-linux-gnu/libc.so.6+0x2ed9e)
#6 0x7f9ca93bbe42 (/lib/x86_64-linux-gnu/libc.so.6+0x2ee42)
#7 0x24c3949 (/usr/local/clang-trunk/bin/clang+0x24c3949)
#8 0x24c0c54 (/usr/local/clang-trunk/bin/clang+0x24c0c54)
#9 0x247dcfb (/usr/local/clang-trunk/bin/clang+0x247dcfb)
#10 0x247ea30 (/usr/local/clang-trunk/bin/clang+0x247ea30)
#11 0x286d513 llvm::FPPassManager::runOnFunction(llvm::Function&)
(/usr/local/clang-trunk/bin/clang+0x286d513)
#12 0x286d78b llvm::FPPassManager::runOnModule(llvm::Module&)
(/usr/local/clang-trunk/bin/clang+0x286d78b)
#13 0x286dce7 llvm::legacy::PassManagerImpl::run(llvm::Module&)
(/usr/local/clang-trunk/bin/clang+0x286dce7)
#14 0x8f5d33 clang::EmitBackendOutput(clang::DiagnosticsEngine&,
clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions
const&, llvm::StringRef, llvm::Module*, clang::BackendAction,
llvm::raw_ostream*) (/usr/local/clang-trunk/bin/clang+0x8f5d33)
#15 0x8eaa05 (/usr/local/clang-trunk/bin/clang+0x8eaa05)
#16 0xaed043 clang::ParseAST(clang::Sema&, bool, bool)
(/usr/local/clang-trunk/bin/clang+0xaed043)
#17 0x6fc02e clang::FrontendAction::Execute()
(/usr/local/clang-trunk/bin/clang+0x6fc02e)
#18 0x6cf3cc clang::CompilerInstance::ExecuteAction(clang::FrontendAction&)
(/usr/local/clang-trunk/bin/clang+0x6cf3cc)
#19 0x6b1622 clang::ExecuteCompilerInvocation(clang::CompilerInstance*)
(/usr/local/clang-trunk/bin/clang+0x6b1622)
#20 0x6a7d77 cc1_main(llvm::ArrayRef<char const*>, char const*, void*)
(/usr/local/clang-trunk/bin/clang+0x6a7d77)
#21 0x6afccb main (/usr/local/clang-trunk/bin/clang+0x6afccb)
#22 0x7f9ca93ae76d __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2176d)
#23 0x6a79e9 _start (/usr/local/clang-trunk/bin/clang+0x6a79e9)
Stack dump:
0.    Program arguments: /usr/local/clang-trunk/bin/clang -cc1 -triple
x86_64-unknown-linux-gnu -emit-obj -disable-free -main-file-name small.c
-mrelocation-model static -mthread-model posix -fmath-errno -masm-verbose
-mconstructor-aliases -munwind-tables -fuse-init-array -target-cpu x86-64
-target-linker-version 2.22 -momit-leaf-frame-pointer -dwarf-column-info
-coverage-file /home/su/small.c -resource-dir
/usr/local/clang-trunk/bin/../lib/clang/3.6.0 -internal-isystem
/usr/local/include -internal-isystem
/usr/local/clang-trunk/bin/../lib/clang/3.6.0/include -internal-externc-isystem
/usr/include/x86_64-linux-gnu -internal-externc-isystem /include
-internal-externc-isystem /usr/include -O1 -fdebug-compilation-dir /home/su
-ferror-limit 19 -fmessage-length 113 -mstackrealign -fobjc-runtime=gcc
-fdiagnostics-show-option -fcolor-diagnostics -o small.o -x c small.c 
1.    <eof> parser at end of file
2.    Per-module optimization passes
3.    Running pass 'Function Pass Manager' on module 'small.c'.
4.    Running pass 'Combine redundant instructions' on function '@fn1'
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.6.0 (trunk 220897)
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/small-de8c1c.c
clang: note: diagnostic msg: /tmp/small-de8c1c.sh
clang: note: diagnostic msg: 

********************
$ 


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


int b[2], d;
static int *c = &b[1];
unsigned char e, g;

void
fn1 ()
{
  int *h = &d;
  g = (c != h) - 1;
  if (e * g)
    while (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/20141101/26928559/attachment.html>

From bugzilla-daemon at llvm.org  Sat Nov  1 16:46:42 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 01 Nov 2014 23:46:42 +0000
Subject: [LLVMbugs] [Bug 21445] clang crashes on valid code at -O1 and above
 on x86_64-linux-gnu
In-Reply-To: <bug-21445-206@http.llvm.org/bugs/>
References: <bug-21445-206@http.llvm.org/bugs/>
Message-ID: <bug-21445-206-6CCNXVAksR@http.llvm.org/bugs/>

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

David Majnemer <david.majnemer at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED
           Assignee|unassignedclangbugs at nondot. |david.majnemer at gmail.com
                   |org                         |

--- Comment #2 from David Majnemer <david.majnemer at gmail.com> ---
Fixed in r221069.

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

From bugzilla-daemon at llvm.org  Sat Nov  1 19:54:42 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 02 Nov 2014 02:54:42 +0000
Subject: [LLVMbugs] [Bug 21446] New: Trailing decltype in variadic function
 with explicitly specified template parameters fails
Message-ID: <bug-21446-206@http.llvm.org/bugs/>

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

            Bug ID: 21446
           Summary: Trailing decltype in variadic function with explicitly
                    specified template parameters fails
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++11
          Assignee: unassignedclangbugs at nondot.org
          Reporter: eniebler at boost.org
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified

This code fails to compile:

    template<typename...Us>
    void boinc(Us...us)
    {}

    template<typename ... Us>
    auto foo(Us...us) -> decltype(boinc(((Us)us)...))
    {
    }

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

The error I get is:

test.cpp:13:5: error: no matching function for call to 'foo'
    foo<int, int, int>(0,0,0);
    ^~~~~~~~~~~~~~~~~~
test.cpp:7:6: note: candidate template ignored: substitution failure
      [with Us = <int, int, int>]: pack expansion contains parameter packs 'Us'
and 'us' that have different lengths (3 vs. 4)
auto foo(Us...us) -> decltype(boinc(((Us)us)...))
     ^                                      ~~~
1 error generated.


This is obviously bogus.

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

From bugzilla-daemon at llvm.org  Sat Nov  1 22:12:52 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 02 Nov 2014 05:12:52 +0000
Subject: [LLVMbugs] [Bug 21441] Please change clang's component C++1y to
 C++14, and add component C++1z
In-Reply-To: <bug-21441-206@http.llvm.org/bugs/>
References: <bug-21441-206@http.llvm.org/bugs/>
Message-ID: <bug-21441-206-vwPnIURBte@http.llvm.org/bugs/>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #1 from Chris Lattner <clattner at apple.com> ---
Done, 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/20141102/aef83a65/attachment.html>

From bugzilla-daemon at llvm.org  Sat Nov  1 22:19:34 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 02 Nov 2014 05:19:34 +0000
Subject: [LLVMbugs] [Bug 21447] New: string_view::to_string() is not marked
	const
Message-ID: <bug-21447-206@http.llvm.org/bugs/>

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

            Bug ID: 21447
           Summary: string_view::to_string() is not marked const
           Product: libc++
           Version: unspecified
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: All Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: jvp4846 at g.rit.edu
                CC: llvmbugs at cs.uiuc.edu, mclow.lists at gmail.com
    Classification: Unclassified

The implementation of std::experimental::string_view::to_string() isn't marked
const, even though n4082[1] says it should be. The std::string conversion
operator *is* marked const, however.

If no one fixes this in a day or two, I'll write up a patch. I assume I'd have
to write tests for this?

[1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4082.pdf

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

From bugzilla-daemon at llvm.org  Sun Nov  2 01:36:06 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 02 Nov 2014 09:36:06 +0000
Subject: [LLVMbugs] [Bug 21448] New: Loads are not combined across
	llvm.assume
Message-ID: <bug-21448-206@http.llvm.org/bugs/>

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

            Bug ID: 21448
           Summary: Loads are not combined across llvm.assume
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Scalar Optimizations
          Assignee: unassignedbugs at nondot.org
          Reporter: kfischer at college.harvard.edu
                CC: hfinkel at anl.gov, llvmbugs at cs.uiuc.edu
    Classification: Unclassified

I tried out the llvm.assume functionality and unfortunately it caused a rather
large regression in my test case because several loads were no longer combined
across the llvm.assume. I presume this is because LoadCombine does not know
that llvm.assume does not write to memory.

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

From bugzilla-daemon at llvm.org  Sun Nov  2 01:47:21 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 02 Nov 2014 09:47:21 +0000
Subject: [LLVMbugs] [Bug 18254] Templated lambda cause with C++ modules
In-Reply-To: <bug-18254-206@http.llvm.org/bugs/>
References: <bug-18254-206@http.llvm.org/bugs/>
Message-ID: <bug-18254-206-AUsuPO2i0T@http.llvm.org/bugs/>

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

Vassil Vassilev <vvasilev at cern.ch> changed:

           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/20141102/4e77ced0/attachment.html>

From bugzilla-daemon at llvm.org  Sun Nov  2 03:51:04 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 02 Nov 2014 11:51:04 +0000
Subject: [LLVMbugs] [Bug 21449] New: Assertion EST != EST_Unevaluated && EST
 != EST_Uninstantiated with destructor and uniform initialization
Message-ID: <bug-21449-206@http.llvm.org/bugs/>

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

            Bug ID: 21449
           Summary: Assertion EST != EST_Unevaluated && EST !=
                    EST_Uninstantiated with destructor and uniform
                    initialization
           Product: clang
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++11
          Assignee: unassignedclangbugs at nondot.org
          Reporter: jonathan.sauer at gmx.de
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 13271
  --> http://llvm.org/bugs/attachment.cgi?id=13271&action=edit
log of clang execution

The following code crashes clang r220759 with an assertion:

struct Bar {
  Bar();
  ~Bar();
};

struct Foo {
  Bar a, b;
};

Foo* makeFoo()
{
  return new Foo {
    /*Bar*/{  },
    /*Bar*/{  }
  };
}

This results in (full log attached):

% ~/LLVM/build/Release+Asserts/bin/clang++ -std=c++11 -c clang.cpp
Assertion failed: (EST != EST_Unevaluated && EST != EST_Uninstantiated),
function isNothrow, file
/Users/rynnsauer/LLVM/llvm/tools/clang/lib/AST/Type.cpp, line 1701.
0  clang                    0x000000010f157f0f
llvm::sys::PrintStackTrace(__sFILE*) + 47
1  clang                    0x000000010f15872b SignalHandler(int) + 555
2  libsystem_platform.dylib 0x00007fff8ffe35aa _sigtramp + 26
3  libsystem_platform.dylib 000000000000000000 _sigtramp + 1879165552
4  clang                    0x000000010f1584e6 abort + 22
5  clang                    0x000000010f1584c1 __assert_rtn + 81
6  clang                    0x000000010e4764f0
clang::FunctionProtoType::isNothrow(clang::ASTContext const&, bool) const + 256
7  clang                    0x000000010d722130
clang::CodeGen::CodeGenModule::ConstructAttributeList(clang::CodeGen::CGFunctionInfo
const&, clang::Decl const*, llvm::SmallVector<llvm::AttributeSet, 8u>&,
unsigned int&, bool) + 528
8  clang                    0x000000010d831af7
clang::CodeGen::CodeGenModule::SetFunctionAttributes(clang::GlobalDecl,
llvm::Function*, bool) + 199
9  clang                    0x000000010d833d1b
clang::CodeGen::CodeGenModule::GetOrCreateLLVMFunction(llvm::StringRef,
llvm::Type*, clang::GlobalDecl, bool, bool, llvm::AttributeSet) + 523
10 clang                    0x000000010d71b7fb
clang::CodeGen::CodeGenModule::getAddrOfCXXStructor(clang::CXXMethodDecl
const*, clang::CodeGen::StructorType, clang::CodeGen::CGFunctionInfo const*,
llvm::FunctionType*, bool) + 283
11 clang                    0x000000010d882f32 (anonymous
namespace)::ItaniumCXXABI::EmitDestructorCall(clang::CodeGen::CodeGenFunction&,
clang::CXXDestructorDecl const*, clang::CXXDtorType, bool, bool, llvm::Value*)
+ 258
[...]

Doing one of the following will make the crash disappear:

- Removing Bar's destructor.
- Changing makeFoo's return type from Foo* to Foo.
- Uncommenting one or both of the Bar's inside makeFoo.

This bug is similar to bug 20619: The same assertion is triggered, however not
in the context of a lambda function.

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

From bugzilla-daemon at llvm.org  Sun Nov  2 07:35:53 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 02 Nov 2014 15:35:53 +0000
Subject: [LLVMbugs] [Bug 21428] Truncated output of negative int64_t to
 std::ostream with std::hex
In-Reply-To: <bug-21428-206@http.llvm.org/bugs/>
References: <bug-21428-206@http.llvm.org/bugs/>
Message-ID: <bug-21428-206-8SviWwGc3h@http.llvm.org/bugs/>

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

Marshall Clow (home) <mclow.lists at gmail.com> changed:

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

--- Comment #5 from Marshall Clow (home) <mclow.lists at gmail.com> ---
Fixed in revision 221101.

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

From bugzilla-daemon at llvm.org  Sun Nov  2 07:36:09 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 02 Nov 2014 15:36:09 +0000
Subject: [LLVMbugs] [Bug 21428] Truncated output of negative int64_t to
 std::ostream with std::hex
In-Reply-To: <bug-21428-206@http.llvm.org/bugs/>
References: <bug-21428-206@http.llvm.org/bugs/>
Message-ID: <bug-21428-206-4zdnKAXJJ9@http.llvm.org/bugs/>

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

Marshall Clow (home) <mclow.lists at gmail.com> changed:

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

--- Comment #6 from Marshall Clow (home) <mclow.lists at gmail.com> ---
Sorry - wrong 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/20141102/a8c7a420/attachment.html>

From bugzilla-daemon at llvm.org  Sun Nov  2 07:36:33 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 02 Nov 2014 15:36:33 +0000
Subject: [LLVMbugs] [Bug 21447] string_view::to_string() is not marked const
In-Reply-To: <bug-21447-206@http.llvm.org/bugs/>
References: <bug-21447-206@http.llvm.org/bugs/>
Message-ID: <bug-21447-206-bR2DlqD1Fy@http.llvm.org/bugs/>

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

Marshall Clow (home) <mclow.lists at gmail.com> changed:

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

--- Comment #1 from Marshall Clow (home) <mclow.lists at gmail.com> ---
Fixed in revision 221101

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

From bugzilla-daemon at llvm.org  Sun Nov  2 08:31:38 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 02 Nov 2014 16:31:38 +0000
Subject: [LLVMbugs] [Bug 21450] New: building boost on windows
Message-ID: <bug-21450-206@http.llvm.org/bugs/>

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

            Bug ID: 21450
           Summary: building boost on windows
           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: kreuzerkrieg at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Hi
it is more a question than a bug not sure how to qualify it. I'm trying to
build boost using pure msvc build chain and llvm (clang-cl), no mingw or
whatever Linux stuff for windows. I've spent two days searching for the answer,
applied numerous command line switches withno result, it still fails for
exception generating code. I've followed the link here
http://lists.boost.org/boost-build/2013/10/27057.php and still it cannot handle
exception code. I've added /GR- /D _HAS_EXCEPTIONS=0 to the command line in
clang-win.jam but it still does not compile with the same
".\boost/throw_exception.hpp(69,5) : error: cannot compile this throw
expression yet".
so the question, is it possible at all? and I guess I'm not the first one to
ask this question. may we have a tutorial how to build boost 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/20141102/6bb45c5b/attachment.html>

From bugzilla-daemon at llvm.org  Sun Nov  2 12:05:38 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 02 Nov 2014 20:05:38 +0000
Subject: [LLVMbugs] [Bug 21451] New: PowerPC cc clobber should be an alias
	for cr0
Message-ID: <bug-21451-206@http.llvm.org/bugs/>

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

            Bug ID: 21451
           Summary: PowerPC cc clobber should be an alias for cr0
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: PowerPC
          Assignee: unassignedbugs at nondot.org
          Reporter: anton at samba.org
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

In bug 19326 we made "cc" represent a clobber of the entire condition register.
It turns out "cc" is actually an alias for "cr0":

https://lists.ozlabs.org/pipermail/linuxppc-dev/2014-November/122391.html

I had the same incorrect assumption.

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

From bugzilla-daemon at llvm.org  Sun Nov  2 12:23:50 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 02 Nov 2014 20:23:50 +0000
Subject: [LLVMbugs] [Bug 21452] New: PowerPC inline assembly "=&r"
	constraint failing
Message-ID: <bug-21452-206@http.llvm.org/bugs/>

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

            Bug ID: 21452
           Summary: PowerPC inline assembly "=&r" constraint failing
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: PowerPC
          Assignee: unassignedbugs at nondot.org
          Reporter: anton at samba.org
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 13272
  --> http://llvm.org/bugs/attachment.cgi?id=13272&action=edit
Inline assembly testcase

The attached testcase built with -O2 -mcpu=power7 is buggy.

        asm volatile("  lwsync\n"
                     "1:        lwarx   %0,0,%1         # atomic_dec_return\n"
                     "  addic   %0,%0,-1\n"
                     "  stwcx.  %0,0,%1\n"
                     "  bne-    1b\n"
                     "  sync\n"
                     :"=&r"(t)
                     :"r"(&v->counter)
                     :"cr0", "xer", "memory");

"=&r" should be enough to prevent t and v->counter ending up in the same
register, but it does:

1:    lwarx    30,0,30        # atomic_dec_return
    addic    30,30,-1
    stwcx.    30,0,30

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

From bugzilla-daemon at llvm.org  Sun Nov  2 15:30:18 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 02 Nov 2014 23:30:18 +0000
Subject: [LLVMbugs] [Bug 13825] [patch] fixed unused std::string variable
In-Reply-To: <bug-13825-206@http.llvm.org/bugs/>
References: <bug-13825-206@http.llvm.org/bugs/>
Message-ID: <bug-13825-206-PY75t6jVfW@http.llvm.org/bugs/>

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

Will Dietz <willdtz at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |llvmbugs at cs.uiuc.edu
          Component|New Bugs                    |new bugs
            Version|trunk                       |unspecified
           Assignee|jtcriswel at gmail.com         |unassignedbugs at nondot.org
            Product|DSA                         |new-bugs

--- Comment #1 from Will Dietz <willdtz at gmail.com> ---
Looks like wrong project, not DSA.

Resetting project and assignment, not sure where this goes.  Is this code still
part of LLVM?

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

From bugzilla-daemon at llvm.org  Sun Nov  2 17:26:45 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 03 Nov 2014 01:26:45 +0000
Subject: [LLVMbugs] [Bug 21460] New: Segfault istream.tellg() and
	unordered_map
Message-ID: <bug-21460-206@http.llvm.org/bugs/>

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

            Bug ID: 21460
           Summary: Segfault istream.tellg() and unordered_map
           Product: clang
           Version: 3.5
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: release blocker
          Priority: P
         Component: C++
          Assignee: unassignedclangbugs at nondot.org
          Reporter: mail at tylor.io
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified

I get a segfault when calling tellg() on any istream.

#include <string>
#include <sstream>

int main() {
  std::string str = "Hello, world";
  std::istringstream in(str);
  std::string word;
  in >> word;
  int pos = in.tellg();
}

I also get a segfault when trying to insert an element into a unordered_map

#include <unordered_map>

int main() {
  std::unordered_map<int, int> int_map;
  int_map[2] = 3;
}

When I run this through gdb I get this:

Program received signal SIGSEGV, Segmentation fault.
0x000000006fc8cac8 in ?? () from c:\msys64\mingw64\bin\libstdc++-6.dll

I running this on Windows 7 using the mingw64 package via msys2
I don't get this behavior with g++ 4.9.1 or in the mingw32 package of the same
version.

$ clang++ --version
clang version 3.5.0 (tags/RELEASE_350/final)
Target: x86_64-w64-windows-gnu
Thread model: posix

$ uname -a
MINGW64_NT-6.1 tower 2.0.0(0.279/5/3) 2014-10-27 06:58 x86_64 Msys

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

From bugzilla-daemon at llvm.org  Mon Nov  3 01:17:05 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 03 Nov 2014 09:17:05 +0000
Subject: [LLVMbugs] [Bug 21461] New: Unsupported Modifier error :
 UNREACHABLE executed at
 ..../lib/Target/PowerPC/MCTargetDesc/PPCELFObjectWriter.cpp:78!
Message-ID: <bug-21461-206@http.llvm.org/bugs/>

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

            Bug ID: 21461
           Summary: Unsupported Modifier error : UNREACHABLE executed at
                    ..../lib/Target/PowerPC/MCTargetDesc/PPCELFObjectWrite
                    r.cpp:78!
           Product: clang
           Version: 3.2
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
          Assignee: unassignedclangbugs at nondot.org
          Reporter: llvm at web.de
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

The following call of clang breaks with an error message - it should compile a
test code with a Hello Word C code for a powerpc target:

 clang -integrated-as -g -fmemsafety -mrelocation-model static -target powerpc
tc.c  -L/home/uid04950/WORK/LLVM_INSTALL/lib
-I/home/uid04950/WORK/LLVM_INSTALL/include 

Target: powerpc
Thread model: posix
 "/home/uid04950/WORK/LLVM_INSTALL/bin/clang" -cc1 -triple powerpc -emit-obj
-mrelax-all -disable-free -main-file-name tc.c -mrelocation-model static
-mdisable-fp-elim -fmath-errno -mconstructor-aliases -target-cpu ppc
-target-linker-version 2.24.51.20140703 -momit-leaf-frame-pointer -v -g
-resource-dir /home/uid04950/WORK/LLVM_INSTALL/bin/../lib/clang/3.2 -I
/home/uid04950/WORK/LLVM_INSTALL/include -fmodule-cache-path
/var/tmp/clang-module-cache -fdebug-compilation-dir
/home/uid04950/WORK/LLVM_INSTALL -ferror-limit 19 -fmessage-length 271
-fmemsafety -mstackrealign -fno-signed-char -fobjc-runtime=gcc
-fdiagnostics-show-option -fcolor-diagnostics -o /tmp/tc-DJ01MW.o -x c tc.c
clang -cc1 version 3.2 based upon LLVM 3.2svn default target
powerpc-unknown-elf
ignoring nonexistent directory "/usr/local/include"
#include "..." search starts here:
#include <...> search starts here:
 /home/uid04950/WORK/LLVM_INSTALL/include
 /home/uid04950/WORK/LLVM_INSTALL/bin/../lib/clang/3.2/include
 /usr/include
End of search list.
Unsupported Modifier
UNREACHABLE executed at
/home/uid04950/WORK/LLVM_SRC/lib/Target/PowerPC/MCTargetDesc/PPCELFObjectWriter.cpp:78!
Stack dump:
0.      Program arguments: /home/uid04950/WORK/LLVM_INSTALL/bin/clang -cc1
-triple powerpc -emit-obj -mrelax-all -disable-free -main-file-name tc.c
-mrelocation-model static -mdisable-fp-elim -fmath-errno -mconstructor-aliases
-target-cpu ppc -target-linker-version 2.24.51.20140703
-momit-leaf-frame-pointer -v -g -resource-dir
/home/uid04950/WORK/LLVM_INSTALL/bin/../lib/clang/3.2 -I
/home/uid04950/WORK/LLVM_INSTALL/include -fmodule-cache-path
/var/tmp/clang-module-cache -fdebug-compilation-dir
/home/uid04950/WORK/LLVM_INSTALL -ferror-limit 19 -fmessage-length 271
-fmemsafety -mstackrealign -fno-signed-char -fobjc-runtime=gcc
-fdiagnostics-show-option -fcolor-diagnostics -o /tmp/tc-DJ01MW.o -x c tc.c
1.      <eof> parser at end of file
2.      Code generation
3.      Running pass 'Function Pass Manager' on module 'tc.c'.
clang: error: unable to execute command: Aborted
clang: error: clang frontend command failed due to signal (use -v to see
invocation)
clang version 3.2 (:
http://llvm.org/svn/llvm-project/safecode/branches/release_32/tools/clang)
Target: powerpc
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/tc-Fl8CKf.c
clang: note: diagnostic msg: /tmp/tc-Fl8CKf.sh
clang: note: diagnostic msg:

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


 /tmp/tc-Fl8CKf.sh:
/home/uid04950/WORK/LLVM_INSTALL/bin/clang -cc1 -triple powerpc -emit-obj
-mrelax-all -disable-free -main-file-name tc.c -mrelocation-model static
-mdisable-fp-elim -fmath-errno -mconstructor-aliases -target-cpu ppc
-target-linker-version 2.24.51.20140703 -momit-leaf-frame-pointer -v -g
-ferror-limit 19 -fmessage-length 271 -fmemsafety -mstackrealign
-fno-signed-char -fobjc-runtime=gcc -fdiagnostics-show-option
-fcolor-diagnostics -x c tc-Fl8CKf.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/20141103/b855ae32/attachment.html>

From bugzilla-daemon at llvm.org  Mon Nov  3 01:46:52 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 03 Nov 2014 09:46:52 +0000
Subject: [LLVMbugs] [Bug 20878] clang version 3.5 is not selectable as
	version
In-Reply-To: <bug-20878-206@http.llvm.org/bugs/>
References: <bug-20878-206@http.llvm.org/bugs/>
Message-ID: <bug-20878-206-jJvRbdN2zb@http.llvm.org/bugs/>

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

jwillemsen at remedy.nl <jwillemsen at remedy.nl> changed:

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

--- Comment #1 from jwillemsen at remedy.nl <jwillemsen at remedy.nl> ---
closing, 3.5 is now available

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

From bugzilla-daemon at llvm.org  Mon Nov  3 06:52:09 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 03 Nov 2014 14:52:09 +0000
Subject: [LLVMbugs] [Bug 21366] clang and mingw disagree about dllexported
	classes
In-Reply-To: <bug-21366-206@http.llvm.org/bugs/>
References: <bug-21366-206@http.llvm.org/bugs/>
Message-ID: <bug-21366-206-x4P1cV4JZb@http.llvm.org/bugs/>

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

Hans Wennborg <hans at chromium.org> changed:

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

--- Comment #3 from Hans Wennborg <hans at chromium.org> ---
Looking closer, it seems that MinGW never dllimport's an inline function. It
even warns or errors if the user tries to put the attribute on a function.

This should now be fixed in r221154.

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

From bugzilla-daemon at llvm.org  Mon Nov  3 08:10:13 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 03 Nov 2014 16:10:13 +0000
Subject: [LLVMbugs] [Bug 21462] New: lib/Target/Mips/MipsABIInfo.h:40:
 performance problem ?
Message-ID: <bug-21462-206@http.llvm.org/bugs/>

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

            Bug ID: 21462
           Summary: lib/Target/Mips/MipsABIInfo.h:40: performance problem
                    ?
           Product: new-bugs
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: dcb314 at hotmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

lib/Target/Mips/MipsABIInfo.h:40]: (performance) Function parameter 'Other'
should be passed by reference.

  bool operator<(const MipsABIInfo Other) const {

Maybe

  bool operator<(const MipsABIInfo & Other) const {

would 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/20141103/2d9133c6/attachment.html>

From bugzilla-daemon at llvm.org  Mon Nov  3 08:14:22 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 03 Nov 2014 16:14:22 +0000
Subject: [LLVMbugs] [Bug 21463] New:
 tools/clang/lib/Driver/ToolChains.cpp:2091: 2 * performance problem ?
Message-ID: <bug-21463-206@http.llvm.org/bugs/>

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

            Bug ID: 21463
           Summary: tools/clang/lib/Driver/ToolChains.cpp:2091: 2 *
                    performance problem ?
           Product: new-bugs
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: dcb314 at hotmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

> [trunk/llvm/tools/clang/lib/Driver/ToolChains.cpp:2091]: (performance) Function parameter 'Ver' should be passed by reference.
> [trunk/llvm/tools/clang/lib/Driver/ToolChains.cpp:2092]: (performance) Function parameter 'MarchString' should be passed by reference.

static void GetHexagonLibraryPaths(
  const ArgList &Args,
  const std::string Ver,
  const std::string MarchString,
  const std::string &InstalledDir,
  ToolChain::path_list *LibPaths)

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

From bugzilla-daemon at llvm.org  Mon Nov  3 08:15:53 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 03 Nov 2014 16:15:53 +0000
Subject: [LLVMbugs] [Bug 21464] New: tools/llvm-objdump/MachODump.cpp:127:
 possible performance problem ?
Message-ID: <bug-21464-206@http.llvm.org/bugs/>

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

            Bug ID: 21464
           Summary: tools/llvm-objdump/MachODump.cpp:127: possible
                    performance problem ?
           Product: new-bugs
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: dcb314 at hotmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

> [trunk/llvm/tools/llvm-objdump/MachODump.cpp:127]: (performance) Function parameter 'i' should be passed by reference.
> [trunk/llvm/tools/llvm-objdump/MachODump.cpp:128]: (performance) Function parameter 'j' should be passed by reference.

static bool compareDiceTableEntries(const DiceTableEntry i,
                                    const DiceTableEntry j) {

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

From bugzilla-daemon at llvm.org  Mon Nov  3 08:20:18 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 03 Nov 2014 16:20:18 +0000
Subject: [LLVMbugs] [Bug 21399] Don't dllexport vftable in anonymous classes
In-Reply-To: <bug-21399-206@http.llvm.org/bugs/>
References: <bug-21399-206@http.llvm.org/bugs/>
Message-ID: <bug-21399-206-Cb8FhjChhN@http.llvm.org/bugs/>

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

Hans Wennborg <hans at chromium.org> changed:

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

--- Comment #1 from Hans Wennborg <hans at chromium.org> ---
Seeing as we already error for exporting/importing functions with internal
linkage, I figure we should do the same for classes.

r221160

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

From bugzilla-daemon at llvm.org  Mon Nov  3 09:48:01 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 03 Nov 2014 17:48:01 +0000
Subject: [LLVMbugs] [Bug 21250] Cannot select: intrinsic %llvm.x86.sse41.dpps
In-Reply-To: <bug-21250-206@http.llvm.org/bugs/>
References: <bug-21250-206@http.llvm.org/bugs/>
Message-ID: <bug-21250-206-xKUNxpXTdl@http.llvm.org/bugs/>

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

Sanjay Patel <spatel+llvm at rotateright.com> changed:

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

--- Comment #5 from Sanjay Patel <spatel+llvm at rotateright.com> ---
The crashing should have been fixed in Clang trunk with:
http://llvm.org/viewvc/llvm-project?view=revision&revision=217311

Please reopen if this is still not working 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/20141103/953e4da0/attachment.html>

From bugzilla-daemon at llvm.org  Mon Nov  3 10:39:20 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 03 Nov 2014 18:39:20 +0000
Subject: [LLVMbugs] [Bug 21465] New: [NVPTX] byval parameters are
	incorrectly lowered
Message-ID: <bug-21465-206@http.llvm.org/bugs/>

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

            Bug ID: 21465
           Summary: [NVPTX] byval parameters are incorrectly lowered
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: PTX
          Assignee: unassignedbugs at nondot.org
          Reporter: wujingyue at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

The current backend treats the base address of a byval parameter as a generic
pointer. However, generic loads don't actually work with a pointer to the
parameter space. Here's a small test case to reproduce this issue:

CUDA:

struct S {
  int a, b;
};

__attribute__((global)) void TakesStruct(S input, int *output) {
  *output = input.b;
}

LLVM IR:

target datalayout = "e-i64:64-v16:16-v32:32-n16:32:64"
target triple = "nvptx64-unknown-unknown"

%struct.S = type { i32, i32 }

; Function Attrs: nounwind
define void @_Z11TakesStruct1SPi(%struct.S* byval nocapture readonly %input,
i32* nocapture %output) #0 {
entry:
  %b = getelementptr inbounds %struct.S* %input, i64 0, i32 1
  %0 = load i32* %b, align 4, !tbaa !2
  store i32 %0, i32* %output, align 4, !tbaa !7
  ret void
}

attributes #0 = { nounwind "less-precise-fpmad"="false"
"no-frame-pointer-elim"="false" "no-infs-fp-math"="false"
"no-nans-fp-math"="false" "stack-protector-buffer-size"="8"
"unsafe-fp-math"="false" "use-soft-float"="false" }

!nvvm.annotations = !{!0}
!llvm.ident = !{!1}

!0 = metadata !{void (%struct.S*, i32*)* @_Z11TakesStruct1SPi, metadata
!"kernel", i32 1}
!1 = metadata !{metadata !"clang version 3.6.0 (http://llvm.org/git/clang.git
1f064ca0a944bf0279b0d6508268a4ea0a354b8e) (http://llvm.org/git/llvm.git
8744520b533617fbbd55ef12ea936961f5225cf5)"}
!2 = metadata !{metadata !3, metadata !4, i64 4}
!3 = metadata !{metadata !"_ZTS1S", metadata !4, i64 0, metadata !4, i64 4}
!4 = metadata !{metadata !"int", metadata !5, i64 0}
!5 = metadata !{metadata !"omnipotent char", metadata !6, i64 0}
!6 = metadata !{metadata !"Simple C/C++ TBAA"}
!7 = metadata !{metadata !4, metadata !4, i64 0}

PTX (sm_35):

//
// Generated by LLVM NVPTX Back-End
//

.version 3.2
.target sm_35
.address_size 64

    // .globl    _Z11TakesStruct1SPi
                                        // @_Z11TakesStruct1SPi
.visible .entry _Z11TakesStruct1SPi(
    .param .align 4 .b8 _Z11TakesStruct1SPi_param_0[8],
    .param .u64 _Z11TakesStruct1SPi_param_1
)
{
    .reg .s32     %r<2>;
    .reg .s64     %rd<3>;

// BB#0:                                // %entry
    mov.b64    %rd1, _Z11TakesStruct1SPi_param_0;
    ld.param.u64     %rd2, [_Z11TakesStruct1SPi_param_1];
    ld.u32     %r1, [%rd1+4];
    st.u32     [%rd2], %r1;
    ret;
}

The problematic instructions are:
    mov.b64    %rd1, _Z11TakesStruct1SPi_param_0;
    ld.u32     %r1, [%rd1+4];
The compiled kernel crashes because the ld.u32 loads from a pointer to the
parameter space.

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

From bugzilla-daemon at llvm.org  Mon Nov  3 12:23:48 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 03 Nov 2014 20:23:48 +0000
Subject: [LLVMbugs] [Bug 21448] Loads are not combined across llvm.assume
In-Reply-To: <bug-21448-206@http.llvm.org/bugs/>
References: <bug-21448-206@http.llvm.org/bugs/>
Message-ID: <bug-21448-206-mGkpyVaEw3@http.llvm.org/bugs/>

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

Hal Finkel <hfinkel at anl.gov> changed:

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

--- Comment #8 from Hal Finkel <hfinkel at anl.gov> ---
With r221175, both unoptimized-assume.ll and unoptimized.ll, run through opt
-mem2reg -instcombine -early-cse, result in 7 loads.

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

From bugzilla-daemon at llvm.org  Mon Nov  3 13:18:18 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 03 Nov 2014 21:18:18 +0000
Subject: [LLVMbugs] [Bug 21466] New: Many memory leaks
Message-ID: <bug-21466-206@http.llvm.org/bugs/>

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

            Bug ID: 21466
           Summary: Many memory leaks
           Product: lld
           Version: unspecified
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: All Bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: rafael.espindola at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 13280
  --> http://llvm.org/bugs/attachment.cgi?id=13280&action=edit
leaks

Attached is the asan output of running just

./bin/llvm-lit -sv ./tools/lld/test/pecoff/trivial.test

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

From bugzilla-daemon at llvm.org  Mon Nov  3 13:30:43 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 03 Nov 2014 21:30:43 +0000
Subject: [LLVMbugs] [Bug 21027] r218166 broke building the C code output
 from the MIDL compiler
In-Reply-To: <bug-21027-206@http.llvm.org/bugs/>
References: <bug-21027-206@http.llvm.org/bugs/>
Message-ID: <bug-21027-206-DMKomq9rdL@http.llvm.org/bugs/>

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

Reid Kleckner <rnk at google.com> changed:

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

--- Comment #10 from Reid Kleckner <rnk at google.com> ---
I downgraded this to a warning in r218394 and forgot to close this out, but
I've gone further in r221184 by making it not warn at all for unprototyped
definitions.

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

From bugzilla-daemon at llvm.org  Mon Nov  3 13:42:35 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 03 Nov 2014 21:42:35 +0000
Subject: [LLVMbugs] [Bug 21467] New: clang hangs on valid code at -Os and
 above on x86_64-linux-gnu
Message-ID: <bug-21467-206@http.llvm.org/bugs/>

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

            Bug ID: 21467
           Summary: clang hangs on valid code at -Os and above on
                    x86_64-linux-gnu
           Product: clang
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: su at cs.ucdavis.edu
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

The following test case causes the current clang trunk to hang when compiling
at -Os and above in both 32-bit and 64-bit modes on x86_64-linux-gnu.

It is regression from 3.1 and affects all earlier versions of clang since 3.2.
It also seems to affect MacOS X. 

This should be different from PR 21377, which also affects clang 3.1.  

$ clang-trunk -v
clang version 3.6.0 (trunk 220839)
Target: x86_64-unknown-linux-gnu
Thread model: posix
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.8
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.8.1
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.4
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.4.6
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.4.7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6.4
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7.3
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8.1
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Selected multilib: .;@m64
$ 
$ clang-trunk -O1 -c small.c
$ clang-3.1 -Os -c small.c
$ 
$ timeout -s 9 30 clang-trunk -Os -c small.c
Killed
$ 


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


struct { int f1; } b;
char a;
int c;

short
fn1 (int p1, int p2)
{
  return p2 == 0 ? p1 : p1 / p2;
}

void fn2 () { }

void
fn3 ()
{
  fn2 ();
  unsigned char d = 0;
  while (1)
    {
      d |= a;
      c = fn1 (10, 1);
      if (fn1 (1, c))
    d |= 0;
      else
    b.f1 = 0;
      d |= a;
    }
}

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

From bugzilla-daemon at llvm.org  Mon Nov  3 13:56:58 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 03 Nov 2014 21:56:58 +0000
Subject: [LLVMbugs] [Bug 21377] clang hangs on valid code at -Os and above
 on x86_64-linux-gnu
In-Reply-To: <bug-21377-206@http.llvm.org/bugs/>
References: <bug-21377-206@http.llvm.org/bugs/>
Message-ID: <bug-21377-206-OSX5aezTMv@http.llvm.org/bugs/>

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

David Majnemer <david.majnemer at gmail.com> changed:

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

--- Comment #3 from David Majnemer <david.majnemer at gmail.com> ---
Fixed in r221187.

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

From bugzilla-daemon at llvm.org  Mon Nov  3 14:01:20 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 03 Nov 2014 22:01:20 +0000
Subject: [LLVMbugs] [Bug 21468] New: GVN should be able to sink instruction
 into the latch
Message-ID: <bug-21468-206@http.llvm.org/bugs/>

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

            Bug ID: 21468
           Summary: GVN should be able to sink instruction into the latch
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Scalar Optimizations
          Assignee: unassignedbugs at nondot.org
          Reporter: david.majnemer at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

The following used to be optimized by FoldOpIntoPhi before r221187 but this
stopped being the case after it was determine that permitting FoldOpIntoPhi to
insert instructions that the PHI may reach will lead to infinite loops. 
Perhaps GVN should catch this instead.

; CHECK: fold_phi
define float @fold_phi(float %a) nounwind {
entry:
  br label %for.body

for.body:
; CHECK: phi float
; CHECK-NEXT: br i1 undef
  %sum.057 = phi float [ 0.000000e+00, %entry ], [ %add5, %bb0 ]
  %add5 = fadd float %sum.057, 1.0 ;; Should be moved to the latch!
  br i1 undef, label %bb0, label %end

; CHECK: bb0:
bb0:
; CHECK: fadd float
  br label %for.body

end:
  ret float %add5
}

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

From bugzilla-daemon at llvm.org  Mon Nov  3 14:33:17 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 03 Nov 2014 22:33:17 +0000
Subject: [LLVMbugs] [Bug 21469] New: heap-buffer-overflow
Message-ID: <bug-21469-206@http.llvm.org/bugs/>

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

            Bug ID: 21469
           Summary: heap-buffer-overflow
           Product: lld
           Version: unspecified
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: All Bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: rafael.espindola at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Other than leaks, the two failing tests with asan are

    lld :: mach-o/write-final-sections.yaml
    lld :: pecoff/seh.test

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

From bugzilla-daemon at llvm.org  Mon Nov  3 14:34:53 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 03 Nov 2014 22:34:53 +0000
Subject: [LLVMbugs] [Bug 21470] New: Clang miscompiles fabs on
	x86_64-w64-windows-gnu
Message-ID: <bug-21470-206@http.llvm.org/bugs/>

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

            Bug ID: 21470
           Summary: Clang miscompiles fabs on x86_64-w64-windows-gnu
           Product: clang
           Version: 3.5
          Hardware: PC
                OS: other
            Status: NEW
          Severity: normal
          Priority: P
         Component: LLVM Codegen
          Assignee: unassignedclangbugs at nondot.org
          Reporter: szabo.antal.92 at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

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

Clang miscompiles fabs on windows x64 using -O1 or greater, if it's parameter
is passed by reference to another function. Instead of the correct value, it
always returns 0. I couldn't reproduce the bug by separately optimizing with
opt, but using "clang -O1 -mllvm -print-before-all -mllvm -print-after-all
bug.cpp" I found that the "Interprocedural Sparse Conditional Constant
Propagation" pass is probably the cause; it replaces the correct return value
in @fabs with an undef ( see https://gist.github.com/Sh4rK/4ec63273c387f9978799
). Test case attached.

Clang version:
Downloaded from the MSYS2 project with pacman, package
"mingw64/mingw-w64-x86_64-clang" version 3.5.0-5 ( MSYS2 installation
instructions: http://sourceforge.net/p/msys2/wiki/MSYS2%20installation/ )

clang -v
clang version 3.5.0 (tags/RELEASE_350/final)
Target: x86_64-w64-windows-gnu
Thread model: posix

OS: Windows 8 x64

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

From bugzilla-daemon at llvm.org  Mon Nov  3 16:27:10 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 04 Nov 2014 00:27:10 +0000
Subject: [LLVMbugs] [Bug 21471] New: Encoded compilation options in bitcode
	file
Message-ID: <bug-21471-206@http.llvm.org/bugs/>

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

            Bug ID: 21471
           Summary: Encoded compilation options in bitcode file
           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: dexonsmith at apple.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Many command-line options specified when compiling individual translation units
are ignored in the context of LTO.  In particular, we don't properly encode all
options in the bitcode, and those that we do often aren't respected by CodeGen
and IR passes. 

Eric is currently restructuring the LLVM backend to support per-function
subtarget info, which gets us most of the way there.

However, many options are sent to the backend as global flags (via -mllvm or
-backend-option) instead of as function attributes.  Also, some function
attributes are duplicated via other mechanisms, so I suspect not all the
attributes are actually respected.

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

From bugzilla-daemon at llvm.org  Mon Nov  3 16:27:52 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 04 Nov 2014 00:27:52 +0000
Subject: [LLVMbugs] [Bug 21470] Clang miscompiles fabs on
	x86_64-w64-windows-gnu
In-Reply-To: <bug-21470-206@http.llvm.org/bugs/>
References: <bug-21470-206@http.llvm.org/bugs/>
Message-ID: <bug-21470-206-9X7EFttLxd@http.llvm.org/bugs/>

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

Nick Lewycky <nlewycky at google.com> changed:

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

--- Comment #7 from Nick Lewycky <nlewycky at google.com> ---
Right. The function has to retain its non-returnedness, and it does. It can't
just replace it with nothing but a "ret undef". Sorry, I misunderstood when
Reid told me about this bug, I thought it was replacing it with a "ret undef"
and no infinite self-recursion.

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

From bugzilla-daemon at llvm.org  Mon Nov  3 16:38:33 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 04 Nov 2014 00:38:33 +0000
Subject: [LLVMbugs] [Bug 21470] Clang miscompiles fabs on
	x86_64-w64-windows-gnu
In-Reply-To: <bug-21470-206@http.llvm.org/bugs/>
References: <bug-21470-206@http.llvm.org/bugs/>
Message-ID: <bug-21470-206-jrZ2tyGrj5@http.llvm.org/bugs/>

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

Reid Kleckner <rnk at google.com> changed:

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

--- Comment #9 from Reid Kleckner <rnk at google.com> ---
(In reply to comment #7)
> Right. The function has to retain its non-returnedness, and it does. It
> can't just replace it with nothing but a "ret undef". Sorry, I misunderstood
> when Reid told me about this bug, I thought it was replacing it with a "ret
> undef" and no infinite self-recursion.

We do in fact do that, however:

$ cat t.cpp
extern "C" int foo() { return foo(); }

$ clang -cc1 t.cpp -emit-llvm -O2 -o - | grep @foo -A3
define i32 @foo() #0 {
entry:
  ret i32 undef
}

Probably because the call to foo has no users and foo is "readonly" so we do a
later cleanup to delete 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/20141104/52c00a3b/attachment.html>

From bugzilla-daemon at llvm.org  Mon Nov  3 16:41:27 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 04 Nov 2014 00:41:27 +0000
Subject: [LLVMbugs] [Bug 21472] New: Support/DataTypes.h requires C99
 defines even when compiling in C11 mode
Message-ID: <bug-21472-206@http.llvm.org/bugs/>

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

            Bug ID: 21472
           Summary: Support/DataTypes.h requires C99 defines even when
                    compiling in C11 mode
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Support Libraries
          Assignee: unassignedbugs at nondot.org
          Reporter: tilkax at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

$ echo '#include <llvm/Support/DataTypes.h>' | clang -std=c11 -xc -
In file included from <stdin>:1:
/usr/include/llvm/Support/DataTypes.h:58:3: error: "Must #define
__STDC_LIMIT_MACROS before #including Support/DataTypes.h"
# error "Must #define __STDC_LIMIT_MACROS before #including
Support/DataTypes.h"
  ^
/usr/include/llvm/Support/DataTypes.h:62:3: error: "Must #define
__STDC_CONSTANT_MACROS before " "#including Support/DataTypes.h"
# error "Must #define __STDC_CONSTANT_MACROS before " \
  ^
2 errors generated.

The explanation in DataTypes.h:
"Note that this header's correct operation depends on __STDC_LIMIT_MACROS being
defined.  We would define it here, but in order to prevent Bad Things happening
when system headers or C++ STL headers include stdint.h before we define it
here, we define it on the g++ command line (in Makefile.rules)."

I don't think this applies when compiling in C11 mode, e.g. when including this
header from third-party code.

Suggested fix: Surround the error message with "#if __STDC_VERSION__ < 201112L"
or something to that effect.

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

From bugzilla-daemon at llvm.org  Mon Nov  3 17:47:31 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 04 Nov 2014 01:47:31 +0000
Subject: [LLVMbugs] [Bug 21473] New: [CFGSimplification] Generate none
 optimized constant ADD operations
Message-ID: <bug-21473-206@http.llvm.org/bugs/>

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

            Bug ID: 21473
           Summary: [CFGSimplification] Generate none optimized constant
                    ADD operations
           Product: new-bugs
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: Hao.Liu at arm.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 13285
  --> http://llvm.org/bugs/attachment.cgi?id=13285&action=edit
CFGSimplification Test Case

To reproduce by following command lines:
clang -O3 -S -emit-llvm simple.c
llc -march=aarch64 < simple.ll -print-after-all

We can see that in AArch64 backend, CFGSimplification generate none optimized
ADDs as follows:
...
%inc.1.1 = add nsw i32 2, 1
...
%inc.2.1 = add nsw i32 %inc.1.1, 1
...
%inc.1.2 = add nsw i32 %inc.1.1, 2
...

Such ADDs can be replaced by constants 3, 4, 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/20141104/090e9ba9/attachment.html>

From bugzilla-daemon at llvm.org  Mon Nov  3 19:17:11 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 04 Nov 2014 03:17:11 +0000
Subject: [LLVMbugs] [Bug 21467] clang hangs on valid code at -Os and above
 on x86_64-linux-gnu
In-Reply-To: <bug-21467-206@http.llvm.org/bugs/>
References: <bug-21467-206@http.llvm.org/bugs/>
Message-ID: <bug-21467-206-MAnWIhVvcz@http.llvm.org/bugs/>

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

David Majnemer <david.majnemer at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |david.majnemer at gmail.com
         Resolution|---                         |INVALID

--- Comment #1 from David Majnemer <david.majnemer at gmail.com> ---
This test case cannot link because it has no entry point.  Feel free to reopen
this PR with a program which links.

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

From bugzilla-daemon at llvm.org  Mon Nov  3 19:19:26 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 04 Nov 2014 03:19:26 +0000
Subject: [LLVMbugs] [Bug 21467] clang hangs on valid code at -Os and above
 on x86_64-linux-gnu
In-Reply-To: <bug-21467-206@http.llvm.org/bugs/>
References: <bug-21467-206@http.llvm.org/bugs/>
Message-ID: <bug-21467-206-w6HQE1QYQz@http.llvm.org/bugs/>

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

David Majnemer <david.majnemer at gmail.com> changed:

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

--- Comment #2 from David Majnemer <david.majnemer at gmail.com> ---
Ah, nevermind.  I misunderstood, reopening.

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

From bugzilla-daemon at llvm.org  Mon Nov  3 21:20:00 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 04 Nov 2014 05:20:00 +0000
Subject: [LLVMbugs] [Bug 21467] clang hangs on valid code at -Os and above
 on x86_64-linux-gnu
In-Reply-To: <bug-21467-206@http.llvm.org/bugs/>
References: <bug-21467-206@http.llvm.org/bugs/>
Message-ID: <bug-21467-206-EzgCmafplI@http.llvm.org/bugs/>

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

David Majnemer <david.majnemer at gmail.com> changed:

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

--- Comment #3 from David Majnemer <david.majnemer at gmail.com> ---
I can't reproduce on LLVM after r221187, reverting r221187 leads to a
reproduction.  Feel free to reopen if you can still reproduce.

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

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

From bugzilla-daemon at llvm.org  Tue Nov  4 00:42:53 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 04 Nov 2014 08:42:53 +0000
Subject: [LLVMbugs] [Bug 21464] tools/llvm-objdump/MachODump.cpp:127:
 possible performance problem ?
In-Reply-To: <bug-21464-206@http.llvm.org/bugs/>
References: <bug-21464-206@http.llvm.org/bugs/>
Message-ID: <bug-21464-206-jFuLFvqyrl@http.llvm.org/bugs/>

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

David Majnemer <david.majnemer at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |david.majnemer at gmail.com
         Resolution|---                         |FIXED
           Assignee|unassignedbugs at nondot.org   |david.majnemer at gmail.com

--- Comment #1 from David Majnemer <david.majnemer at gmail.com> ---
Fixed in r221247.

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

From bugzilla-daemon at llvm.org  Tue Nov  4 00:55:46 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 04 Nov 2014 08:55:46 +0000
Subject: [LLVMbugs] [Bug 21463] tools/clang/lib/Driver/ToolChains.cpp:2091:
 2 * performance problem ?
In-Reply-To: <bug-21463-206@http.llvm.org/bugs/>
References: <bug-21463-206@http.llvm.org/bugs/>
Message-ID: <bug-21463-206-bE6Ha3ccd2@http.llvm.org/bugs/>

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

David Majnemer <david.majnemer at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |david.majnemer at gmail.com
         Resolution|---                         |FIXED
           Assignee|unassignedbugs at nondot.org   |david.majnemer at gmail.com

--- Comment #1 from David Majnemer <david.majnemer at gmail.com> ---
Fixed in r221249.

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

From bugzilla-daemon at llvm.org  Tue Nov  4 04:13:42 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 04 Nov 2014 12:13:42 +0000
Subject: [LLVMbugs] [Bug 21474] New: BGEU not implemented
Message-ID: <bug-21474-206@http.llvm.org/bugs/>

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

            Bug ID: 21474
           Summary: BGEU not implemented
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: MIPS
          Assignee: unassignedbugs at nondot.org
          Reporter: csdavec at swan.ac.uk
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

The GNU assembler implements BGEU as a pseudo that expands to SLTU followed by
BEQZ.  LLVM is currently missing this, which is a blocker for FreeBSD libc.

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

From bugzilla-daemon at llvm.org  Tue Nov  4 04:30:09 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 04 Nov 2014 12:30:09 +0000
Subject: [LLVMbugs] [Bug 21475] New: compiler-rt (git) CMake Error in
 AArch64 platform with GCC compiler
Message-ID: <bug-21475-206@http.llvm.org/bugs/>

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

            Bug ID: 21475
           Summary: compiler-rt (git) CMake Error in AArch64 platform with
                    GCC compiler
           Product: compiler-rt
           Version: unspecified
          Hardware: Other
                OS: Linux
            Status: NEW
          Severity: release blocker
          Priority: P
         Component: compiler-rt
          Assignee: unassignedbugs at nondot.org
          Reporter: yuxing.tang at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 13287
  --> http://llvm.org/bugs/attachment.cgi?id=13287&action=edit
the patch file for compiler-rt/cmake/config-ix.cmake in aarch64 platform

I got this Problem when try to build the whole llvm git tree in AArch64
platform. A simple test error in compiler-rt just stop the configuration
progress.

   It seems cmake try to do some compiling test before the real build, but it
failed in aarch64. Form the log. I figure out the possible cause is the wrong
"-march" parameters for gcc. It seems the cmake build system try to push
"-march=aarch64" into the compiler testing command. After checking the current
gcc document and testing gcc-4.8.3 and gcc-4.9.0, I'm sure current gcc release
just recognize "-march=armv8-a", not "-march=aarch64"

  The problem is in compiler-rt/cmake/config-ix.cmake file. If the platform is
aarch32, cmake will push the right parameter "-march=armv8-a". If the platform
is aarch64, the paramter will change to "-march=aarch64", which the gcc cannot
handle. So I produce a simple patch.

********************* possible patch ************************
--- ./llvmGIT/llvm/projects/compiler-rt/cmake/config-ix.cmake   2014-11-04
19:25:39.827152526 +0800
+++ ./llvm/projects/compiler-rt/cmake/config-ix.cmake   2014-10-28
08:25:15.189851798 +0800
@@ -148,7 +148,7 @@
   elseif("${COMPILER_RT_TEST_TARGET_ARCH}" MATCHES "aarch32")
     test_target_arch(aarch32 "-march=armv8-a")
   elseif("${COMPILER_RT_TEST_TARGET_ARCH}" MATCHES "aarch64")
-    test_target_arch(aarch64 "-march=aarch64")
+    test_target_arch(aarch64 "-march=armv8-a")
   endif()
   set(COMPILER_RT_OS_SUFFIX "")
 endif()

*************************************************
This patch just work for aarch64/Linux-gcc platform
I have tested this patch has no side effect in x86_64/Linux-gcc. but
aarch64/Linux-llvm or aarch64/MacOS has not been tested.


***************** The Error message log just as below *************

CMake Error at projects/compiler-rt/cmake/config-ix.cmake:87 (message):
  Cannot compile for aarch64:
 ...
 ...  
CMakeFiles/cmTryCompileExec4150267559.dir/simple.cc.o -c
  /home/xxx/SourceCode/llvmGIT/build/CMakeFiles/simple.cc

  /home/xxx/SourceCode/llvmGIT/build/CMakeFiles/simple.cc:1:0: error: unknown
  value ‘aarch64’ for -march
 ...
 ...  
make: *** [cmTryCompileExec4150267559/fast] Error 2

Call Stack (most recent call first):
  projects/compiler-rt/cmake/config-ix.cmake:151 (test_target_arch)
  projects/compiler-rt/CMakeLists.txt:216 (include)


-- Configuring incomplete, errors occurred!

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

From bugzilla-daemon at llvm.org  Tue Nov  4 04:53:52 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 04 Nov 2014 12:53:52 +0000
Subject: [LLVMbugs] [Bug 21476] New: sanitizer_platform_limits_posix.cc(git)
 build error in aarch64 platrom
Message-ID: <bug-21476-206@http.llvm.org/bugs/>

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

            Bug ID: 21476
           Summary: sanitizer_platform_limits_posix.cc(git) build error in
                    aarch64 platrom
           Product: compiler-rt
           Version: unspecified
          Hardware: Other
                OS: Linux
            Status: NEW
          Severity: release blocker
          Priority: P
         Component: compiler-rt
          Assignee: unassignedbugs at nondot.org
          Reporter: yuxing.tang at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 13288
  --> http://llvm.org/bugs/attachment.cgi?id=13288&action=edit
the patch file for
compiler-rt/lib/sanitizer_common/santizer_platform_limits_posix.h

I got this problem during the build of llvm git source tree. Just during the
build of sanitizer_platform_limits_posix.cc.o in compiler-rt, the error rise
for wrong CHECK_TYPE_SIZE(__kernel_old_gid_t).

  after dig into the source code, I find in the line #472 in
sanitizer_platform_limits_posix.h has been changed since the end of September.
The aarch64 don't use "unsigned int" for __sanitizer__kernel_old_git_t, but
change to "unsigned shot".

  I just put this line back to the same as 3.5.0. The problem solved.

**** so the possible patch below **********
---
./llvmGIT/llvm/projects/compiler-rt/lib/sanitizer_common/sanitizer_platform_limits_posix.h
 2014-11-04 19:25:39.907146059 +0800
+++
./llvm/projects/compiler-rt/lib/sanitizer_common/sanitizer_platform_limits_posix.h
 2014-11-04 17:08:34.903162640 +0800
@@ -472,7 +472,7 @@
   typedef long __sanitizer___kernel_off_t;
 #endif

-#if defined(__powerpc__) || defined(__mips__)
+#if defined(__powerpc__) || defined(__aarch64__) || defined(__mips__)
   typedef unsigned int __sanitizer___kernel_old_uid_t;
   typedef unsigned int __sanitizer___kernel_old_gid_t;
 #else

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

**** the error message below ***********
[ 62%] Building CXX object
projects/compiler-rt/lib/sanitizer_common/CMakeFiles/RTSan
itizerCommon.aarch64.dir/sanitizer_platform_limits_posix.cc.o
In file included from
/home/tyx/SourceCode/llvm/projects/compiler-rt/lib/sanitizer_co
mmon/sanitizer_platform_limits_posix.cc:178:0:
/home/xxx/SourceCode/llvm/projects/compiler-rt/lib/sanitizer_common/sanitizer_interna
l_defs.h:274:72: error: size of array ‘assertion_failed__1008’ is negative
     typedef char IMPL_PASTE(assertion_failed_##_, line)[2*(int)(pred)-1]

...
...

/home/xxx/SourceCode/llvm/projects/compiler-rt/lib/sanitizer_common/sanitizer_platfor
m_limits_posix.cc:1009:1: note: in expansion of macro ‘CHECK_TYPE_SIZE’
 CHECK_TYPE_SIZE(__kernel_old_gid_t);
 ^
cc1plus: warning: unrecognized command line option "-Wno-c99-extensions"
[enabled by 
default]
cc1plus: warning: unrecognized command line option "-Wno-gnu" [enabled by
default]
make[2]: ***
[projects/compiler-rt/lib/sanitizer_common/CMakeFiles/RTSanitizerCommon.
aarch64.dir/sanitizer_platform_limits_posix.cc.o] Error 1
make[1]: ***
[projects/compiler-rt/lib/sanitizer_common/CMakeFiles/RTSanitizerCommon.
aarch64.dir/all] Error 2
make: *** [all] Error 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/20141104/b40df54c/attachment.html>

From bugzilla-daemon at llvm.org  Tue Nov  4 06:29:57 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 04 Nov 2014 14:29:57 +0000
Subject: [LLVMbugs] [Bug 15590] Following 5 tests in Tooling test directory
 fail with clang-check on a 64bit version of Windows 7.
In-Reply-To: <bug-15590-206@http.llvm.org/bugs/>
References: <bug-15590-206@http.llvm.org/bugs/>
Message-ID: <bug-15590-206-5Et5x0PnLC@http.llvm.org/bugs/>

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

NAKAMURA Takumi <geek4civic at gmail.com> changed:

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

--- Comment #3 from NAKAMURA Takumi <geek4civic at gmail.com> ---
- auto-detect-from-source-parent.cpp
- auto-detect-from-source.cpp
- clang-check-autodetect-dir.cpp

Backslash (aka JPY sign) should be avoided as possible in JSON.
Fixed in r221266.


- auto-detect-from-source-parent-of-cwd.cpp
- clang-check-pwd.cpp

They are still suppressed due to limitation of Lit internal runner.
Removed mention in r221267.

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

From bugzilla-daemon at llvm.org  Tue Nov  4 09:01:31 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 04 Nov 2014 17:01:31 +0000
Subject: [LLVMbugs] [Bug 21477] New: exact shift right of constant not
 optimized (instcombine / value tracking)
Message-ID: <bug-21477-206@http.llvm.org/bugs/>

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

            Bug ID: 21477
           Summary: exact shift right of constant not optimized
                    (instcombine / value tracking)
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Scalar Optimizations
          Assignee: unassignedbugs at nondot.org
          Reporter: spatel+llvm at rotateright.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

[Follow-on from bug 21412.]

An exact shift right guarantees that no set bits are shifted out, so this:

define i32 @exact_shift(i32 %shiftval) {
  %shr = lshr exact i32 1, %shiftval
  ret i32 %shr
}

...should be optimized to:

define i32 @exact_shift(i32 %shiftval) {
  ret i32 1
}

Ie, %shiftval must be zero, or we have undefined behavior / poison.

In the other bug, the shift is followed by division, so the ideal optimization
for:

define i32 @exact_div(i32 %x, i32 %shiftval) {
  %shr = lshr exact i32 1, %shiftval
  %div = udiv i32 %x, %shr
  ret i32 %div
}

...will be:

define i32 @exact_div(i32 %x, i32 %shiftval) {
  ret i32 %x
}

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

From bugzilla-daemon at llvm.org  Tue Nov  4 09:26:45 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 04 Nov 2014 17:26:45 +0000
Subject: [LLVMbugs] [Bug 17236] missed opportunity to use vector FMA
	instruction
In-Reply-To: <bug-17236-206@http.llvm.org/bugs/>
References: <bug-17236-206@http.llvm.org/bugs/>
Message-ID: <bug-17236-206-7zCnm5GIOf@http.llvm.org/bugs/>

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

Bug 17236 depends on bug 17172, which changed state.

Bug 17172 Summary: [SLP vectorization] missed opportunity to use absolute value vector instruction (vpabsd)
http://llvm.org/bugs/show_bug.cgi?id=17172

           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/20141104/0ef78112/attachment.html>

From bugzilla-daemon at llvm.org  Tue Nov  4 09:26:41 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 04 Nov 2014 17:26:41 +0000
Subject: [LLVMbugs] [Bug 17172] [SLP vectorization] missed opportunity to
 use absolute value vector instruction (vpabsd)
In-Reply-To: <bug-17172-206@http.llvm.org/bugs/>
References: <bug-17172-206@http.llvm.org/bugs/>
Message-ID: <bug-17172-206-c9WO3jWbmz@http.llvm.org/bugs/>

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

Sanjay Patel <spatel+llvm at rotateright.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |spatel+llvm at rotateright.com
         Resolution|---                         |FIXED

--- Comment #7 from Sanjay Patel <spatel+llvm at rotateright.com> ---
This got fixed in the SLP vectorizer / cost-model sometime in the last year:

$ ./clang -v
clang version 3.6.0 (221222)
Target: x86_64-apple-darwin13.4.0
Thread model: posix


$ ./clang -O3 -fomit-frame-pointer -march=corei7-avx vpsad.c -S -o -
    .section    __TEXT,__text,regular,pure_instructions
    .macosx_version_min 10, 9
    .globl    _foo
    .align    4, 0x90
_foo:                                   ## @foo
    .cfi_startproc
## BB#0:                                ## %entry
    vpabsd    (%rdi), %xmm0
    vmovdqu    %xmm0, (%rdi)
    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/20141104/c1db43ad/attachment.html>

From bugzilla-daemon at llvm.org  Tue Nov  4 09:44:43 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 04 Nov 2014 17:44:43 +0000
Subject: [LLVMbugs] [Bug 21478] New: MIPS assertions failed when
 disassembling SC and CACHE instructions
Message-ID: <bug-21478-206@http.llvm.org/bugs/>

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

            Bug ID: 21478
           Summary: MIPS assertions failed when disassembling SC and CACHE
                    instructions
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: MIPS
          Assignee: unassignedbugs at nondot.org
          Reporter: csdavec at swan.ac.uk
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

A few instructions in the MIPS back end (SC and CACHE) have MemOpnd operands
that confuse the disassembler.  They are a single operand, but the disassembler
treats them as two, resulting assertion failures because the operands are out
of range.

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

From bugzilla-daemon at llvm.org  Tue Nov  4 10:19:08 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 04 Nov 2014 18:19:08 +0000
Subject: [LLVMbugs] [Bug 21479] New: Regression Suite Failure: Win64 Visual
 Studio 12 2013
Message-ID: <bug-21479-206@http.llvm.org/bugs/>

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

            Bug ID: 21479
           Summary: Regression Suite Failure: Win64 Visual Studio 12 2013
           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: arcfide at sacrideo.us
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

After building llvm/clang from trunk or 3.5.0 release, configuring with CMake
using the "Visual Studio 12 2013 Win64" configuration, and then building with
ALL_BUILD using any of the targets (Release/Debug/RelWithDebInfo) and the x64
target platform, running the check-all target gives 68 regression suite
failures. 

Configuring CMake to use "Visual Studio 12 2013" (32-bit instead of 64-bit)
instead, the build works and all regression suite tests pass. 

In Summary, it appears that building llvm/clang as a 64-bit binary on Windows
8.1 x64 does not work, while building clang as a 32-bit binary on the same does
work.

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

From bugzilla-daemon at llvm.org  Tue Nov  4 10:42:03 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 04 Nov 2014 18:42:03 +0000
Subject: [LLVMbugs] [Bug 21480] New: SROA asserts with "Cannot have vector
 types of different sizes!"
Message-ID: <bug-21480-206@http.llvm.org/bugs/>

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

            Bug ID: 21480
           Summary: SROA asserts with "Cannot have vector types of
                    different sizes!"
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Scalar Optimizations
          Assignee: unassignedbugs at nondot.org
          Reporter: fraser at codeplay.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

I get the following assert in SROA:

/home/fraser/llvm-trunk/llvm/lib/Transforms/Scalar/SROA.cpp:1746:
isVectorPromotionViable(const llvm::DataLayout&, llvm::Type*, uint64_t,
uint64_t, {anonymous}::AllocaSlices::const_range,
llvm::ArrayRef<{anonymous}::Slice*>)::<lambda(llvm::VectorType*,
llvm::VectorType*)>: Assertion `DL.getTypeSizeInBits(RHSTy) ==
DL.getTypeSizeInBits(LHSTy) && "Cannot have vector types of different sizes!"'
failed.

I'm compiling the IR snippet below with the following command:

clang -cc1 -O3 -emit-llvm-bc -o test.bc test.ll

=== test.ll ===
define <3 x float> @uint3_as_float3(<3 x i32> %x) #0 {
entry:
  %x.addr = alloca <3 x i32>, align 16
  %extractVec = shufflevector <3 x i32> %x, <3 x i32> undef, <4 x i32> <i32 0,
i32 1, i32 2, i32 undef>
  %storetmp = bitcast <3 x i32>* %x.addr to <4 x i32>*
  store <4 x i32> %extractVec, <4 x i32>* %storetmp, align 16
  %0 = bitcast <3 x i32>* %x.addr to <3 x float>*
  %castToVec4 = bitcast <3 x float>* %0 to <4 x float>*
  %loadVec4 = load <4 x float>* %castToVec4
  %extractVec1 = shufflevector <4 x float> %loadVec4, <4 x float> undef, <3 x
i32> <i32 0, i32 1, i32 2>
  ret <3 x float> %extractVec1
}


RHSTy is <4 x i32> and LHSTy is <3 x i32>

The full crash backtrace is attached here:

clang-3.5: /home/fraser/llvm-trunk/llvm/lib/Transforms/Scalar/SROA.cpp:1746:
isVectorPromotionViable(const llvm::DataLayout&, llvm::Type*, uint64_t,
uint64_t, {anonymous}::AllocaSlices::const_range,
llvm::ArrayRef<{anonymous}::Slice*>)::<lambda(llvm::VectorType*,
llvm::VectorType*)>: Assertion `DL.getTypeSizeInBits(RHSTy) ==
DL.getTypeSizeInBits(LHSTy) && "Cannot have vector types of different sizes!"'
failed.
#0 0x959123e llvm::sys::PrintStackTrace(_IO_FILE*)
/home/fraser/llvm-trunk/llvm/lib/Support/Unix/Signals.inc:423:0
#1 0x959147e PrintStackTraceSignalHandler(void*)
/home/fraser/llvm-trunk/llvm/lib/Support/Unix/Signals.inc:480:0
#2 0x9590223 SignalHandler(int)
/home/fraser/llvm-trunk/llvm/lib/Support/Unix/Signals.inc:199:0
#3 0xf7717cc0 (linux-gate.so.1+0xcc0)
#4 0xf7717cf0 (linux-gate.so.1+0xcf0)
#5 0xf7350f37 __GI_raise (/usr/lib32/libc.so.6+0x2bf37)
#6 0xf7352579 __GI_abort (/usr/lib32/libc.so.6+0x2d579)
#7 0xf734a007 __assert_fail_base (/usr/lib32/libc.so.6+0x25007)
#8 0xf734a08b (/usr/lib32/libc.so.6+0x2508b)
#9 0x9d02797 isVectorPromotionViable(llvm::DataLayout const&, llvm::Type*,
unsigned long long, unsigned long long, llvm::iterator_range<(anonymous
namespace)::Slice const*>, llvm::ArrayRef<(anonymous
namespace)::Slice*>)::{lambda(llvm::VectorType*,
llvm::VectorType*)#3}::operator()(llvm::VectorType*, llvm::VectorType*) const
/home/fraser/llvm-trunk/llvm/lib/Transforms/Scalar/SROA.cpp:1747:0
#10 0x9d137f2 bool
__gnu_cxx::__ops::_Iter_comp_iter<isVectorPromotionViable(llvm::DataLayout
const&, llvm::Type*, unsigned long long, unsigned long long,
llvm::iterator_range<(anonymous namespace)::Slice const*>,
llvm::ArrayRef<(anonymous namespace)::Slice*>)::{lambda(llvm::VectorType*,
llvm::VectorType*)#3}>::operator()<llvm::VectorType**,
__gnu_cxx::__ops::_Iter_comp_iter<isVectorPromotionViable(llvm::DataLayout
const&, llvm::Type*, unsigned long long, unsigned long long,
llvm::iterator_range<(anonymous namespace)::Slice const*>,
llvm::ArrayRef<(anonymous namespace)::Slice*>)::{lambda(llvm::VectorType*,
llvm::VectorType*)#3}>::operator()>(llvm::VectorType**,
__gnu_cxx::__ops::_Iter_comp_iter<isVectorPromotionViable(llvm::DataLayout
const&, llvm::Type*, unsigned long long, unsigned long long,
llvm::iterator_range<(anonymous namespace)::Slice const*>,
llvm::ArrayRef<(anonymous namespace)::Slice*>)::{lambda(llvm::VectorType*,
llvm::VectorType*)#3}>::operator())
/usr/include/c++/4.9.1/bits/predefined_ops.h:121:0
#11 0x9d15c6d void std::__insertion_sort<llvm::VectorType**,
__gnu_cxx::__ops::_Iter_comp_iter<isVectorPromotionViable(llvm::DataLayout
const&, llvm::Type*, unsigned long long, unsigned long long,
llvm::iterator_range<(anonymous namespace)::Slice const*>,
llvm::ArrayRef<(anonymous namespace)::Slice*>)::{lambda(llvm::VectorType*,
llvm::VectorType*)#3}> >(llvm::VectorType**,
__gnu_cxx::__ops::_Iter_comp_iter<isVectorPromotionViable(llvm::DataLayout
const&, llvm::Type*, unsigned long long, unsigned long long,
llvm::iterator_range<(anonymous namespace)::Slice const*>,
llvm::ArrayRef<(anonymous namespace)::Slice*>)::{lambda(llvm::VectorType*,
llvm::VectorType*)#3}>,
__gnu_cxx::__ops::_Iter_comp_iter<isVectorPromotionViable(llvm::DataLayout
const&, llvm::Type*, unsigned long long, unsigned long long,
llvm::iterator_range<(anonymous namespace)::Slice const*>,
llvm::ArrayRef<(anonymous namespace)::Slice*>)::{lambda(llvm::VectorType*,
llvm::VectorType*)#3}>) /usr/include/c++/4.9.1/bits/stl_algo.h:1846:0
#12 0x9d13779 void std::__final_insertion_sort<llvm::VectorType**,
__gnu_cxx::__ops::_Iter_comp_iter<isVectorPromotionViable(llvm::DataLayout
const&, llvm::Type*, unsigned long long, unsigned long long,
llvm::iterator_range<(anonymous namespace)::Slice const*>,
llvm::ArrayRef<(anonymous namespace)::Slice*>)::{lambda(llvm::VectorType*,
llvm::VectorType*)#3}> >(llvm::VectorType**,
__gnu_cxx::__ops::_Iter_comp_iter<isVectorPromotionViable(llvm::DataLayout
const&, llvm::Type*, unsigned long long, unsigned long long,
llvm::iterator_range<(anonymous namespace)::Slice const*>,
llvm::ArrayRef<(anonymous namespace)::Slice*>)::{lambda(llvm::VectorType*,
llvm::VectorType*)#3}>,
__gnu_cxx::__ops::_Iter_comp_iter<isVectorPromotionViable(llvm::DataLayout
const&, llvm::Type*, unsigned long long, unsigned long long,
llvm::iterator_range<(anonymous namespace)::Slice const*>,
llvm::ArrayRef<(anonymous namespace)::Slice*>)::{lambda(llvm::VectorType*,
llvm::VectorType*)#3}>) /usr/include/c++/4.9.1/bits/stl_algo.h:1889:0
#13 0x9d10bc1 void std::__sort<llvm::VectorType**,
__gnu_cxx::__ops::_Iter_comp_iter<isVectorPromotionViable(llvm::DataLayout
const&, llvm::Type*, unsigned long long, unsigned long long,
llvm::iterator_range<(anonymous namespace)::Slice const*>,
llvm::ArrayRef<(anonymous namespace)::Slice*>)::{lambda(llvm::VectorType*,
llvm::VectorType*)#3}> >(llvm::VectorType**,
__gnu_cxx::__ops::_Iter_comp_iter<isVectorPromotionViable(llvm::DataLayout
const&, llvm::Type*, unsigned long long, unsigned long long,
llvm::iterator_range<(anonymous namespace)::Slice const*>,
llvm::ArrayRef<(anonymous namespace)::Slice*>)::{lambda(llvm::VectorType*,
llvm::VectorType*)#3}>,
__gnu_cxx::__ops::_Iter_comp_iter<isVectorPromotionViable(llvm::DataLayout
const&, llvm::Type*, unsigned long long, unsigned long long,
llvm::iterator_range<(anonymous namespace)::Slice const*>,
llvm::ArrayRef<(anonymous namespace)::Slice*>)::{lambda(llvm::VectorType*,
llvm::VectorType*)#3}>) /usr/include/c++/4.9.1/bits/stl_algo.h:1970:0
#14 0x9d0e0a8 void std::sort<llvm::VectorType**,
isVectorPromotionViable(llvm::DataLayout const&, llvm::Type*, unsigned long
long, unsigned long long, llvm::iterator_range<(anonymous namespace)::Slice
const*>, llvm::ArrayRef<(anonymous
namespace)::Slice*>)::{lambda(llvm::VectorType*,
llvm::VectorType*)#3}>(llvm::VectorType**,
isVectorPromotionViable(llvm::DataLayout const&, llvm::Type*, unsigned long
long, unsigned long long, llvm::iterator_range<(anonymous namespace)::Slice
const*>, llvm::ArrayRef<(anonymous
namespace)::Slice*>)::{lambda(llvm::VectorType*, llvm::VectorType*)#3},
isVectorPromotionViable(llvm::DataLayout const&, llvm::Type*, unsigned long
long, unsigned long long, llvm::iterator_range<(anonymous namespace)::Slice
const*>, llvm::ArrayRef<(anonymous
namespace)::Slice*>)::{lambda(llvm::VectorType*, llvm::VectorType*)#3})
/usr/include/c++/4.9.1/bits/stl_algo.h:4707:0
#15 0x9d02cd9 isVectorPromotionViable(llvm::DataLayout const&, llvm::Type*,
unsigned long long, unsigned long long, llvm::iterator_range<(anonymous
namespace)::Slice const*>, llvm::ArrayRef<(anonymous namespace)::Slice*>)
/home/fraser/llvm-trunk/llvm/lib/Transforms/Scalar/SROA.cpp:1753:0
#16 0x9d0a285 (anonymous namespace)::SROA::rewritePartition(llvm::AllocaInst&,
(anonymous namespace)::AllocaSlices&, (anonymous namespace)::Slice*, (anonymous
namespace)::Slice*, long long, long long, llvm::ArrayRef<(anonymous
namespace)::Slice*>)
/home/fraser/llvm-trunk/llvm/lib/Transforms/Scalar/SROA.cpp:3217:0
#17 0x9d0b1bb (anonymous namespace)::SROA::splitAlloca(llvm::AllocaInst&,
(anonymous namespace)::AllocaSlices&)
/home/fraser/llvm-trunk/llvm/lib/Transforms/Scalar/SROA.cpp:3412:0
#18 0x9d0b9ff (anonymous namespace)::SROA::runOnAlloca(llvm::AllocaInst&)
/home/fraser/llvm-trunk/llvm/lib/Transforms/Scalar/SROA.cpp:3542:0
#19 0x9d0c6cf (anonymous namespace)::SROA::runOnFunction(llvm::Function&)
/home/fraser/llvm-trunk/llvm/lib/Transforms/Scalar/SROA.cpp:3708:0
#20 0x9247792 llvm::FPPassManager::runOnFunction(llvm::Function&)
/home/fraser/llvm-trunk/llvm/lib/IR/LegacyPassManager.cpp:1541:0
#21 0x9247511 llvm::legacy::FunctionPassManagerImpl::run(llvm::Function&)
/home/fraser/llvm-trunk/llvm/lib/IR/LegacyPassManager.cpp:1490:0
#22 0x924710d llvm::legacy::FunctionPassManager::run(llvm::Function&)
/home/fraser/llvm-trunk/llvm/lib/IR/LegacyPassManager.cpp:1408:0
#23 0x9a7a03c (anonymous
namespace)::EmitAssemblyHelper::EmitAssembly(clang::BackendAction,
llvm::raw_ostream*)
/home/fraser/llvm-trunk/llvm/tools/clang/lib/CodeGen/BackendUtil.cpp:586:0
#24 0x9a7a19e clang::EmitBackendOutput(clang::DiagnosticsEngine&,
clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions
const&, llvm::StringRef, llvm::Module*, clang::BackendAction,
llvm::raw_ostream*)
/home/fraser/llvm-trunk/llvm/tools/clang/lib/CodeGen/BackendUtil.cpp:609:0
#25 0x9a639e9 clang::CodeGenAction::ExecuteAction()
/home/fraser/llvm-trunk/llvm/tools/clang/lib/CodeGen/CodeGenAction.cpp:723:0
#26 0x976bf45 clang::FrontendAction::Execute()
/home/fraser/llvm-trunk/llvm/tools/clang/lib/Frontend/FrontendAction.cpp:428:0
#27 0x9735640 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&)
/home/fraser/llvm-trunk/llvm/tools/clang/lib/Frontend/CompilerInstance.cpp:801:0
#28 0x9871d0e clang::ExecuteCompilerInvocation(clang::CompilerInstance*)
/home/fraser/llvm-trunk/llvm/tools/clang/lib/FrontendTool/ExecuteCompilerInvocation.cpp:222:0
#29 0x8bc6181 cc1_main(llvm::ArrayRef<char const*>, char const*, void*)
/home/fraser/llvm-trunk/llvm/tools/clang/tools/driver/cc1_main.cpp:110:0
#30 0x8bbe769 ExecuteCC1Tool(llvm::ArrayRef<char const*>, llvm::StringRef)
/home/fraser/llvm-trunk/llvm/tools/clang/tools/driver/driver.cpp:371:0
#31 0x8bbed11 main
/home/fraser/llvm-trunk/llvm/tools/clang/tools/driver/driver.cpp:417:0
#32 0xf733ce5e __libc_start_main (/usr/lib32/libc.so.6+0x17e5e)
#33 0x8bbbb31 _start (/home/fraser/llvm-trunk/build/bin/clang-3.5+0x8bbbb31)
Stack dump:
0.      Program arguments: /home/fraser/llvm-trunk/build/bin/clang-3.5 -cc1
-triple x86_64-unknown-linux-gnu -emit-obj -disable-free -main-file-name
test.ll -mrelocation-model static -mthread-model posix -fmath-errno
-masm-verbose -mconstructor-aliases -munwind-tables -fuse-init-array
-target-cpu x86-64 -momit-leaf-frame-pointer -dwarf-column-info -resource-dir
/home/fraser/llvm-trunk/build/bin/../lib/clang/3.6.0 -O3
-fdebug-compilation-dir /home/fraser -ferror-limit 19 -fmessage-length 135
-mstackrealign -fobjc-runtime=gcc -fdiagnostics-show-option -fcolor-diagnostics
-vectorize-loops -vectorize-slp -o /tmp/test-b90a0f.o -x ir test.ll 
1.      Per-function optimization
2.      Running pass 'SROA' on function '@uint3_as_float3'

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

From bugzilla-daemon at llvm.org  Tue Nov  4 14:11:31 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 04 Nov 2014 22:11:31 +0000
Subject: [LLVMbugs] [Bug 21328] Un-necessary relocations generated for local
 label subtractions in apple_xxx debug sections
In-Reply-To: <bug-21328-206@http.llvm.org/bugs/>
References: <bug-21328-206@http.llvm.org/bugs/>
Message-ID: <bug-21328-206-elhAcFVAEv@http.llvm.org/bugs/>

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

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

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

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

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

From bugzilla-daemon at llvm.org  Tue Nov  4 14:45:20 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 04 Nov 2014 22:45:20 +0000
Subject: [LLVMbugs] [Bug 21481] New: Overload is incorrectly ignored
Message-ID: <bug-21481-206@http.llvm.org/bugs/>

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

            Bug ID: 21481
           Summary: Overload is incorrectly ignored
           Product: clang
           Version: 3.5
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++11
          Assignee: unassignedclangbugs at nondot.org
          Reporter: graeser at mi.fu-berlin.de
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 13290
  --> http://llvm.org/bugs/attachment.cgi?id=13290&action=edit
Test case failing with clang-3.5. Compile with -std=c++11

Under certain conditions clang ignores a function overload due to a
substitution failure although substitution should succeed. Suppose you have

  template<class... T>
  struct Foo
  {};

  template<class T0, class... T>
  struct Foo<T0, T...>
  {
    typedef T0 First;
  };

and two overloaded functions selected using enable_if

  template<class C, class... T,
    typename std::enable_if<std::is_same<C, Foo<> >::value, int>::type =0>
  int bar()
  {
      return 0;
  }

  template<class C, class... T,
    typename std::enable_if<!(std::is_same<C, Foo<> >::value), int>::type =0>
  auto bar()
    -> decltype(typename C::First()) // This should be OK by SFINAE
  {
      return 0;
  }

Then substitution of C::First should work for C=Foo<int>. However clang rejects
bar<Foo<int>, char>(). Surprisingly the overload is used if the additional char
parameter is omitted or if an instance of Foo<int> is created in main().

A test case that fails with clang-3.5 is attached. Notice that the variadic
templates seem to be necessary to trigger the problem.

Side note: gcc-4.8 accepts the 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/20141104/839cc73e/attachment.html>

From bugzilla-daemon at llvm.org  Tue Nov  4 15:49:26 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 04 Nov 2014 23:49:26 +0000
Subject: [LLVMbugs] [Bug 21412] wrong code at -O3 on x86_64-linux-gnu (LICM)
In-Reply-To: <bug-21412-206@http.llvm.org/bugs/>
References: <bug-21412-206@http.llvm.org/bugs/>
Message-ID: <bug-21412-206-rTHqwkPavh@http.llvm.org/bugs/>

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

David Majnemer <david.majnemer at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED
           Assignee|unassignedclangbugs at nondot. |david.majnemer at gmail.com
                   |org                         |

--- Comment #11 from David Majnemer <david.majnemer at gmail.com> ---
Fixed in r221318.

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

From bugzilla-daemon at llvm.org  Tue Nov  4 16:06:49 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 05 Nov 2014 00:06:49 +0000
Subject: [LLVMbugs] [Bug 21482] New: dependency-dump.m fails with super-long
	pathname
Message-ID: <bug-21482-206@http.llvm.org/bugs/>

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

            Bug ID: 21482
           Summary: dependency-dump.m fails with super-long pathname
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: Modules
          Assignee: unassignedclangbugs at nondot.org
          Reporter: paul_robinson at playstation.sony.com
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 13291
  --> http://llvm.org/bugs/attachment.cgi?id=13291&action=edit
repro script

Our internal Windows bots use some pretty long path names, and
something about how Modules works is tripping over them.

I've attached a .bat script that will repro this failure outside of
the lit framework; that makes it easy to manipulate the length of the
directory name passed to -fmodules-cache-path and -module-dependency-dir.
As attached, the script causes FileCheck to fail as follows:

e:\upstream\llvm\tools\clang\test\Modules\dependency-dump.m:9:9: error:
expected
 string not found in input
// VFS: 'name': "SubFramework.h"
        ^
e:\cmplr\scratch\incredible-ridiculously-long-directory-component\incredible-rid
iculously-long-directory-component\123456789012345678901\vfs\vfs.yaml:1:1:
note:
 scanning from here
{
^
e:\cmplr\scratch\incredible-ridiculously-long-directory-component\incredible-rid
iculously-long-directory-component\123456789012345678901\vfs\vfs.yaml:26:2:
note
: possible intended match here
 'name': "Sub.h",
 ^

But, if you make that directory name 1 character shorter, it passes.

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

From bugzilla-daemon at llvm.org  Tue Nov  4 17:00:17 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 05 Nov 2014 01:00:17 +0000
Subject: [LLVMbugs] [Bug 21477] exact shift right of constant not optimized
 (instcombine / value tracking)
In-Reply-To: <bug-21477-206@http.llvm.org/bugs/>
References: <bug-21477-206@http.llvm.org/bugs/>
Message-ID: <bug-21477-206-b68fQCkvXF@http.llvm.org/bugs/>

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

David Majnemer <david.majnemer at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |david.majnemer at gmail.com
         Resolution|---                         |FIXED
           Assignee|unassignedbugs at nondot.org   |david.majnemer at gmail.com

--- Comment #1 from David Majnemer <david.majnemer at gmail.com> ---
Fixed in r221325.

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

From bugzilla-daemon at llvm.org  Tue Nov  4 18:00:59 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 05 Nov 2014 02:00:59 +0000
Subject: [LLVMbugs] [Bug 21484] New: Clang crashes on lambdas with arguments
 of invalid types derived from template arguments
Message-ID: <bug-21484-206@http.llvm.org/bugs/>

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

            Bug ID: 21484
           Summary: Clang crashes on lambdas with arguments of invalid
                    types derived from template arguments
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
          Assignee: unassignedclangbugs at nondot.org
          Reporter: rtrieu at google.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Code:
template<class T>
void bar(T t) {
  auto x = [](typename T::ns::type &k) {}; 
}

class S {};

void foo() {
  bar(5);
  bar(S());
}

Commandline:
clang -std=c++11 test.cc

Error:
bar(5) produces:
test.cc:3:24: error: type 'int' cannot be used prior to '::' because it has no
      members
  auto x = [](typename T::ns::type &k) {};
                       ^
test.cc:9:3: note: in instantiation of function template specialization
      'bar<int>' requested here
  bar(5);
  ^

bar(S()) [with bar(5) commented out] produces:
test.cc:3:27: error: no member named 'ns' in 'S'
  auto x = [](typename T::ns::type &k) {};
                       ~~~^
test.cc:10:3: note: in instantiation of function template specialization
      'bar<S>' requested here
  bar(S());
  ^

Assertion:
clang-3.6: ../tools/clang/lib/Sema/TypeLocBuilder.h:106: clang::TypeSourceInfo
*clang::TypeLocBuilder::getTypeSourceInfo(clang::ASTContext &,
clang::QualType): Assertion `T == LastTy && "type doesn't match last type
pushed!"' failed.

QualType T in the assertion is a null QualType.

I suspect that TransformLambdaExpr (which calls getTypeSoucreInfo at lint 9017
and triggers the assertion) is not handling invalid types properly along all
paths.

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

From bugzilla-daemon at llvm.org  Tue Nov  4 23:14:31 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 05 Nov 2014 07:14:31 +0000
Subject: [LLVMbugs] [Bug 19227] line_iterator is confused with CRLF
In-Reply-To: <bug-19227-206@http.llvm.org/bugs/>
References: <bug-19227-206@http.llvm.org/bugs/>
Message-ID: <bug-19227-206-RD7d11avMX@http.llvm.org/bugs/>

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

NAKAMURA Takumi <geek4civic at gmail.com> changed:

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

--- Comment #1 from NAKAMURA Takumi <geek4civic at gmail.com> ---
Fixed in r221153.

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

From bugzilla-daemon at llvm.org  Tue Nov  4 23:30:13 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 05 Nov 2014 07:30:13 +0000
Subject: [LLVMbugs] [Bug 13147] CMake-generated Makefiles block one
 library's source files on the previous library's link step
In-Reply-To: <bug-13147-206@http.llvm.org/bugs/>
References: <bug-13147-206@http.llvm.org/bugs/>
Message-ID: <bug-13147-206-3787phZwDo@http.llvm.org/bugs/>

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

NAKAMURA Takumi <geek4civic at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
                 CC|                            |brad.king at kitware.com
         Resolution|---                         |FIXED

--- Comment #4 from NAKAMURA Takumi <geek4civic at gmail.com> ---
Resolved to introduce target_link_libraries(INTERFACE) and "objlib" stuff.

We could also cut redundant deps between tblgen and each source file, if CMake
introduced "pre-generate" hook. 

Add hook for project-defined check-build-system actions
http://www.cmake.org/Bug/view.php?id=14729

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

From bugzilla-daemon at llvm.org  Tue Nov  4 23:33:03 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 05 Nov 2014 07:33:03 +0000
Subject: [LLVMbugs] [Bug 14976] Lit malforms multiline RUN: line,
 eg. clang/test/Preprocessor/macro-multiline.c
In-Reply-To: <bug-14976-206@http.llvm.org/bugs/>
References: <bug-14976-206@http.llvm.org/bugs/>
Message-ID: <bug-14976-206-9ZvGLhq9Fx@http.llvm.org/bugs/>

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

NAKAMURA Takumi <geek4civic at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |alp at nuanti.com,
                   |                            |geek4civic at gmail.com
         Resolution|---                         |WONTFIX

--- Comment #1 from NAKAMURA Takumi <geek4civic at gmail.com> ---
Alp tweaked the test in r206703 and I think we might not fix Lit for this
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/20141105/e7f24135/attachment.html>

From bugzilla-daemon at llvm.org  Tue Nov  4 23:36:14 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 05 Nov 2014 07:36:14 +0000
Subject: [LLVMbugs] [Bug 18809] DebugInfo/empty.ll crashes for targeting
 pecoff/dw2 (cygming).
In-Reply-To: <bug-18809-206@http.llvm.org/bugs/>
References: <bug-18809-206@http.llvm.org/bugs/>
Message-ID: <bug-18809-206-eWEYSX2dxV@http.llvm.org/bugs/>

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

NAKAMURA Takumi <geek4civic at gmail.com> changed:

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

--- Comment #6 from NAKAMURA Takumi <geek4civic at gmail.com> ---
David Blaikie fixed it in r204780.

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

From bugzilla-daemon at llvm.org  Tue Nov  4 23:38:13 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 05 Nov 2014 07:38:13 +0000
Subject: [LLVMbugs] [Bug 20321] CLANG_ENABLE_REWRITER=0 makes crash report
 unavailable (preprocessed source is not generated)
In-Reply-To: <bug-20321-206@http.llvm.org/bugs/>
References: <bug-20321-206@http.llvm.org/bugs/>
Message-ID: <bug-20321-206-o8G9Ew3qDr@http.llvm.org/bugs/>

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

NAKAMURA Takumi <geek4civic at gmail.com> changed:

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

--- Comment #3 from NAKAMURA Takumi <geek4civic at gmail.com> ---
Rafael, sure. Closed.

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

From bugzilla-daemon at llvm.org  Wed Nov  5 02:48:23 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 05 Nov 2014 10:48:23 +0000
Subject: [LLVMbugs] [Bug 9780] [Win32] constant may be emitted to .rdata
In-Reply-To: <bug-9780-206@http.llvm.org/bugs/>
References: <bug-9780-206@http.llvm.org/bugs/>
Message-ID: <bug-9780-206-G8DENNmxhh@http.llvm.org/bugs/>

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

NAKAMURA Takumi <geek4civic at gmail.com> changed:

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

--- Comment #1 from NAKAMURA Takumi <geek4civic at gmail.com> ---
David Majnemer fixed it in r187956. See also bug 16831.

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

From bugzilla-daemon at llvm.org  Wed Nov  5 03:50:08 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 05 Nov 2014 11:50:08 +0000
Subject: [LLVMbugs] [Bug 21485] New: -fsanitize=bounds does not detect
 out-of-bounds access
Message-ID: <bug-21485-206@http.llvm.org/bugs/>

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

            Bug ID: 21485
           Summary: -fsanitize=bounds does not detect out-of-bounds access
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: polacek at redhat.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

int a[10];
void
foo (int x)
{
  int v = a[x]++;
}

int
main ()
{
  foo (10);
}

$ clang -fsanitize=bounds -O2 u2.c; ./a.out 
says nothing.  If I change foo (10); to foo (11);, then it's detected:
u2.c:5:11: runtime error: index 11 out of bounds for type 'int [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/20141105/08fb96f2/attachment.html>

From bugzilla-daemon at llvm.org  Wed Nov  5 04:46:33 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 05 Nov 2014 12:46:33 +0000
Subject: [LLVMbugs] [Bug 21486] New: [mips] isel crash
Message-ID: <bug-21486-206@http.llvm.org/bugs/>

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

            Bug ID: 21486
           Summary: [mips] isel crash
           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: tima0900 at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 13292
  --> http://llvm.org/bugs/attachment.cgi?id=13292&action=edit
c source file

Hi,
we have a c-file that crashes with clang.
Tried with the 3.5 release as well as with a fairly new clang(trunk about 1.5
months old).
It crashes during instruction selection. The input is attached.
The output of clang:
C:\Program Files\LLVM\bin>clang -c -EL -G 0 -O2 -mips1 -fsigned-char -target
mips-unknown-unknown -D__MIPSEL -DNDEBUG -w -S -I"D:\D7FBGen\include"
-I"D:\D7FBGen\sde\include"
"E:\REC_BEO_BR_39\GeneratedFiles\TDC-FM\BEO39_body.c" -o
"E:\REC_BEO_BR_39\GeneratedFiles\TDC-FM\BEO39_body.s" -v
clang version 3.5.0 (217039)
Target: mipsel-unknown-unknown
Thread model: posix
 "C:\Program Files\LLVM\bin\clang.exe" -cc1 -triple mipsel-unknown-unknown -S
-disable-free -main-file-name BEO39_body.c -mrelocation-model static
-mdisable-fp-elim -fmath-errno -no-integrated-as -mconstructor-aliases
-target-cpu mips1 -target-feature -n64 -target-feature +o32 -target-abi o32
-mfloat-abi hard -mllvm -mips-ssection-threshold=0 -v -dwarf-column-info
-coverage-file "E:\\REC_BEO_BR_39\\GeneratedFiles\\TDC-FM\\BEO39_body.s"
-resource-dir "C:\\Program Files\\LLVM\\bin\\..\\lib\\clang\\3.5.0" -D __MIPSEL
-D NDEBUG -I "D:\\D7FBGen\\include" -I "D:\\D7FBGen\\sde\\include" -O2 -w
-fno-dwarf-directory-asm -fdebug-compilation-dir "C:\\Program Files\\LLVM\\bin"
-ferror-limit 19 -fmessage-length 9999 -mstackrealign -fobjc-runtime=gcc
-fdiagnostics-show-option -fcolor-diagnostics -vectorize-loops -vectorize-slp
-o "E:\\REC_BEO_BR_39\\GeneratedFiles\\TDC-FM\\BEO39_body.s" -x c
"E:\\REC_BEO_BR_39\\GeneratedFiles\\TDC-FM\\BEO39_body.c"
clang -cc1 version 3.5.0 based upon LLVM 3.5.0 default target
i686-pc-windows-gnu
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory "/usr/include"
#include "..." search starts here:
#include <...> search starts here:
 D:\D7FBGen\include
 D:\D7FBGen\sde\include
 C:\Program Files\LLVM\bin\..\lib\clang\3.5.0\include
End of search list.
fatal error: error in backend: Cannot select: 0x4cce258: f64 = select
0x4ccda80, 0x4ccdf90, 0x4ccd330 [ORD=18] [ID=57]
  0x4ccda80: i32 = or 0x4ccd4e0, 0x4ccc2e0 [ORD=16] [ID=56]
    0x4ccd4e0: i32 = MipsISD::CMovFP_T 0x4ccdb10, 0x4ccd960, 0x4ccc0a0,
0x4ccd9f0 [ORD=14] [ID=55]
      0x4ccdb10: i32 = Constant<1> [ID=17]
      0x4ccd960: i32 = Register %FCC0 [ID=18]
      0x4ccc0a0: i32 = Constant<0> [ID=19]
      0x4ccd9f0: glue = MipsISD::FPCmp 0x4cccf40, 0x4cccd90, 0x4ccc640 [ORD=14]
[ID=52]
        0x4cccf40: f32,ch = load 0x4ccdc30, 0x4ccce20,
0x4ccdd50<LD4[%field11](tbaa=<badref>)> [ORD=12] [ID=50]
          0x4ccce20: i32 = add 0x4ccca30, 0x4ccde70 [ORD=11] [ID=33]
            0x4ccca30: i32,ch = CopyFromReg 0x48fb6c0, 0x4ccc910 [ORD=2]
[ID=24]
              0x4ccc910: i32 = Register %vreg357 [ID=1]
            0x4ccde70: i32 = Constant<28> [ID=5]
          0x4ccdd50: i32 = undef [ID=3]
        0x4cccd90: f32,ch = load 0x48fb6c0, 0x4ccbe68,
0x4ccdd50<LD4[ConstantPool]> [ID=38]
          0x4ccbe68: i32 = add 0x4ccc5b0, 0x4ccc760 [ID=35]
            0x4ccc5b0: i32 = MipsISD::Hi 0x4ccc520 [ID=25]
              0x4ccc520: i32 = TargetConstantPool<float 0x3E112E0BE0000000> 0
[TF=5] [ID=20]
            0x4ccc760: i32 = MipsISD::Lo 0x4ccd7b0 [ID=26]
              0x4ccd7b0: i32 = TargetConstantPool<float 0x3E112E0BE0000000> 0
[TF=6] [ID=21]
          0x4ccdd50: i32 = undef [ID=3]
        0x4ccc640: i32 = Constant<4> [ID=16]
    0x4ccc2e0: i32 = MipsISD::CMovFP_T 0x4ccdb10, 0x4ccd960, 0x4ccc0a0,
0x4ccc250 [ORD=15] [ID=54]
      0x4ccdb10: i32 = Constant<1> [ID=17]
      0x4ccd960: i32 = Register %FCC0 [ID=18]
      0x4ccc0a0: i32 = Constant<0> [ID=19]
      0x4ccc250: glue = MipsISD::FPCmp 0x4cccf40, 0x4cccf40, 0x4ccdb10 [ORD=15]
[ID=51]
        0x4cccf40: f32,ch = load 0x4ccdc30, 0x4ccce20,
0x4ccdd50<LD4[%field11](tbaa=<badref>)> [ORD=12] [ID=50]
          0x4ccce20: i32 = add 0x4ccca30, 0x4ccde70 [ORD=11] [ID=33]
            0x4ccca30: i32,ch = CopyFromReg 0x48fb6c0, 0x4ccc910 [ORD=2]
[ID=24]
              0x4ccc910: i32 = Register %vreg357 [ID=1]
            0x4ccde70: i32 = Constant<28> [ID=5]
          0x4ccdd50: i32 = undef [ID=3]
        0x4cccf40: f32,ch = load 0x4ccdc30, 0x4ccce20,
0x4ccdd50<LD4[%field11](tbaa=<badref>)> [ORD=12] [ID=50]
          0x4ccce20: i32 = add 0x4ccca30, 0x4ccde70 [ORD=11] [ID=33]
            0x4ccca30: i32,ch = CopyFromReg 0x48fb6c0, 0x4ccc910 [ORD=2]
[ID=24]
              0x4ccc910: i32 = Register %vreg357 [ID=1]
            0x4ccde70: i32 = Constant<28> [ID=5]
          0x4ccdd50: i32 = undef [ID=3]
        0x4ccdb10: i32 = Constant<1> [ID=17]
  0x4ccdf90: f64,ch = load 0x48fb6c0, 0x4ccba78, 0x4ccdd50<LD8[ConstantPool]>
[ID=39]
    0x4ccba78: i32 = add 0x4ccbb08, 0x4ccd8d0 [ID=36]
      0x4ccbb08: i32 = MipsISD::Hi 0x4ccceb0 [ID=27]
        0x4ccceb0: i32 = TargetConstantPool<double 1.000000e-09> 0 [TF=5]
[ID=22]
      0x4ccd8d0: i32 = MipsISD::Lo 0x4ccc400 [ID=28]
        0x4ccc400: i32 = TargetConstantPool<double 1.000000e-09> 0 [TF=6]
[ID=23]
    0x4ccdd50: i32 = undef [ID=3]
  0x4ccd330: f64 = fp_extend 0x4cccf40 [ORD=13] [ID=53]
    0x4cccf40: f32,ch = load 0x4ccdc30, 0x4ccce20,
0x4ccdd50<LD4[%field11](tbaa=<badref>)> [ORD=12] [ID=50]
      0x4ccce20: i32 = add 0x4ccca30, 0x4ccde70 [ORD=11] [ID=33]
        0x4ccca30: i32,ch = CopyFromReg 0x48fb6c0, 0x4ccc910 [ORD=2] [ID=24]
          0x4ccc910: i32 = Register %vreg357 [ID=1]
        0x4ccde70: i32 = Constant<28> [ID=5]
      0x4ccdd50: i32 = undef [ID=3]
In function: _ZN18REC_BEO_BR_39_User4stepEv
Stack dump:
0.      Program arguments: C:\Program Files\LLVM\bin\clang.exe -cc1 -triple
mipsel-unknown-unknown -S -disable-free -main-file-name BEO39_body.c
-mrelocation-model static -mdisable-fp-elim -fmath-errno -no-integrated-as
-mconstructor-aliases -target-cpu mips1 -target-feature -n64 -target-feature
+o32 -target-abi o32 -mfloat-abi hard -mllvm -mips-ssection-threshold=0 -v
-dwarf-column-info -coverage-file
E:\REC_BEO_BR_39\GeneratedFiles\TDC-FM\BEO39_body.s -resource-dir C:\Program
Files\LLVM\bin\..\lib\clang\3.5.0 -D __MIPSEL -D NDEBUG -I D:\D7FBGen\include
-I D:\D7FBGen\sde\include -O2 -w -fno-dwarf-directory-asm
-fdebug-compilation-dir C:\Program Files\LLVM\bin -ferror-limit 19
-fmessage-length 9999 -mstackrealign -fobjc-runtime=gcc
-fdiagnostics-show-option -fcolor-diagnostics -vectorize-loops -vectorize-slp
-o E:\REC_BEO_BR_39\GeneratedFiles\TDC-FM\BEO39_body.s -x c
E:\REC_BEO_BR_39\GeneratedFiles\TDC-FM\BEO39_body.c
1.      <eof> parser at end of file
2.      Code generation
3.      Running pass 'Function Pass Manager' on module
'E:\REC_BEO_BR_39\GeneratedFiles\TDC-FM\BEO39_body.c'.
4.      Running pass 'MIPS DAG->DAG Pattern Instruction Selection' on function
'@_ZN18REC_BEO_BR_39_User4stepEv'
clang.exe: error: clang frontend command failed with exit code 70 (use -v to
see invocation)
clang version 3.5.0 (217039)
Target: mipsel-unknown-unknown
Thread model: posix
clang.exe: 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/20141105/64d092e0/attachment.html>

From bugzilla-daemon at llvm.org  Wed Nov  5 06:33:22 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 05 Nov 2014 14:33:22 +0000
Subject: [LLVMbugs] [Bug 21487] New: Incorrect detection of nil object
Message-ID: <bug-21487-206@http.llvm.org/bugs/>

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

            Bug ID: 21487
           Summary: Incorrect detection of nil object
           Product: clang
           Version: 3.5
          Hardware: Macintosh
                OS: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: Static Analyzer
          Assignee: kremenek at apple.com
          Reporter: jacobisrael at mail.usf.edu
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Under NON-ARC

NSString *fileName = nil;

if(){
   if(){
      if(){
        fileName = [[NSString alloc] initWithString:iconfileName];
        // ....
      }
   }
}

if(fileName)
{
   //   ...
  [fileName release];
}

// Analyzer complains that fileName could be a potential 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/20141105/7447d2f4/attachment.html>

From bugzilla-daemon at llvm.org  Wed Nov  5 07:27:56 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 05 Nov 2014 15:27:56 +0000
Subject: [LLVMbugs] [Bug 21488] New: Assertion failed:
 (isa<clang::sema::LambdaScopeInfo>( FunctionScopes[FunctionScopes.size() -
 1]) && "The function on the top of sema's function-info stack must be a
 lambda")
Message-ID: <bug-21488-206@http.llvm.org/bugs/>

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

            Bug ID: 21488
           Summary: Assertion failed: (isa<clang::sema::LambdaScopeInfo>(
                    FunctionScopes[FunctionScopes.size() - 1]) && "The
                    function on the top of sema's function-info stack must
                    be a lambda")
           Product: clang
           Version: trunk
          Hardware: Macintosh
                OS: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++14
          Assignee: unassignedclangbugs at nondot.org
          Reporter: ldionne.2 at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

The following code causes Clang r221326 to segfault:

------------------------------------------------------------------------------
#include <tuple>

std::tuple<int> id(std::tuple<int> x) { return x; }

template <typename Xs>
auto depth4(Xs xs) {
    int s;
    auto capture = [=](auto _) { _(xs), s; };
    capture(id);
}

template <typename Xs>
auto depth3(Xs xs) {
    depth4(xs);
}

template <typename Xs>
auto depth2(Xs xs) {
    depth3(xs);
}

template <typename Xs>
auto depth1(Xs xs) {
    depth2(xs);
}

int main() {
    std::tuple<int> xs;
    depth1(xs);
}
------------------------------------------------------------------------------

Note that the code will also _sometimes_ compile, and other times Clang will
simply stay stuck at 100% CPU usage until I kill it. Doing even slight
modifications like removing one depthN function seems to make Clang happy,
so I wasn't able to reduce the example more than that.

When it segfaults, the exact output is:
------------------------------------------------------------------------------
> ~/code/llvm/debug/bin/clang++ -std=c++1y -o /dev/null ~/desktop/bugreports/segfault_capture/main.cpp
Assertion failed: (isa<clang::sema::LambdaScopeInfo>(
FunctionScopes[FunctionScopes.size() - 1]) && "The function on the top of
sema's function-info stack must be a lambda"), function
getStackIndexOfNearestEnclosingCaptureReadyLambda, file
/Users/ldionne/code/llvm/tools/clang/lib/Sema/SemaLambda.cpp, line 72.
0  clang-3.6                0x000000011194410e
llvm::sys::PrintStackTrace(__sFILE*) + 46
1  clang-3.6                0x00000001119454bb
PrintStackTraceSignalHandler(void*) + 27
2  clang-3.6                0x0000000111945905 SignalHandler(int) + 565
3  libsystem_platform.dylib 0x00007fff8c10a5aa _sigtramp + 26
4  clang-3.6                0x0000000113da0d1b
clang::DeclarationNameInfo::DeclarationNameInfo(clang::DeclarationName,
clang::SourceLocation, clang::DeclarationNameLoc) + 43
5  clang-3.6                0x00000001119454eb raise + 27
6  clang-3.6                0x00000001119455a2 abort + 18
7  clang-3.6                0x0000000111945581 __assert_rtn + 129
8  clang-3.6                0x000000011350ffe7
getStackIndexOfNearestEnclosingCaptureReadyLambda(llvm::ArrayRef<clang::sema::FunctionScopeInfo
const*>, clang::VarDecl*) + 167
9  clang-3.6                0x000000011350fcbd
clang::getStackIndexOfNearestEnclosingCaptureCapableLambda(llvm::ArrayRef<clang::sema::FunctionScopeInfo
const*>, clang::VarDecl*, clang::Sema&) + 93
10 clang-3.6                0x000000011347963f
CheckIfAnyEnclosingLambdasMustCaptureAnyPotentialCaptures(clang::Expr*,
clang::sema::LambdaScopeInfo*, clang::Sema&) + 559
11 clang-3.6                0x0000000113479259
clang::Sema::ActOnFinishFullExpr(clang::Expr*, clang::SourceLocation, bool,
bool, bool) + 1337
12 clang-3.6                0x00000001135e4207
clang::Sema::ActOnExprStmt(clang::ActionResult<clang::Expr*, true>) + 135
13 clang-3.6                0x000000011375a778 clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformStmt(clang::Stmt*) + 2920
14 clang-3.6                0x000000011376f9dc clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformCompoundStmt(clang::CompoundStmt*,
bool) + 236
15 clang-3.6                0x000000011376737a clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformCompoundStmt(clang::CompoundStmt*)
+ 42
16 clang-3.6                0x0000000113759e03 clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformStmt(clang::Stmt*) + 499
17 clang-3.6                0x000000011378a94a clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformLambdaScope(clang::LambdaExpr*,
clang::CXXMethodDecl*,
llvm::ArrayRef<std::__1::pair<clang::ActionResult<clang::Expr*, true>,
clang::QualType> >) + 2938
18 clang-3.6                0x0000000113789dc0 (anonymous
namespace)::TemplateInstantiator::TransformLambdaScope(clang::LambdaExpr*,
clang::CXXMethodDecl*,
llvm::ArrayRef<std::__1::pair<clang::ActionResult<clang::Expr*, true>,
clang::QualType> >) + 192
19 clang-3.6                0x000000011378926c clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformLambdaExpr(clang::LambdaExpr*) +
2380
20 clang-3.6                0x00000001137803d2 (anonymous
namespace)::TemplateInstantiator::TransformLambdaExpr(clang::LambdaExpr*) + 98
21 clang-3.6                0x000000011375b6d7 clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformExpr(clang::Expr*) + 3095
22 clang-3.6                0x000000011375c329 clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformInitializer(clang::Expr*, bool) +
457
23 clang-3.6                0x0000000113757cf9
clang::Sema::SubstInitializer(clang::Expr*,
clang::MultiLevelTemplateArgumentList const&, bool) + 121
24 clang-3.6                0x00000001137b1092
clang::Sema::InstantiateVariableInitializer(clang::VarDecl*, clang::VarDecl*,
clang::MultiLevelTemplateArgumentList const&) + 242
25 clang-3.6                0x000000011379fd34
clang::Sema::BuildVariableInstantiation(clang::VarDecl*, clang::VarDecl*,
clang::MultiLevelTemplateArgumentList const&,
llvm::SmallVector<clang::Sema::LateInstantiatedAttribute, 16u>*,
clang::DeclContext*, clang::LocalInstantiationScope*, bool) + 2180
26 clang-3.6                0x000000011379efdc
clang::TemplateDeclInstantiator::VisitVarDecl(clang::VarDecl*, bool) + 1004
27 clang-3.6                0x000000011379ebe2
clang::TemplateDeclInstantiator::VisitVarDecl(clang::VarDecl*) + 34
28 clang-3.6                0x000000011379051b
clang::declvisitor::Base<clang::declvisitor::make_ptr,
clang::TemplateDeclInstantiator, clang::Decl*>::Visit(clang::Decl*) + 1435
29 clang-3.6                0x00000001137a8b72
clang::Sema::SubstDecl(clang::Decl*, clang::DeclContext*,
clang::MultiLevelTemplateArgumentList const&) + 162
30 clang-3.6                0x000000011376b4e4 (anonymous
namespace)::TemplateInstantiator::TransformDefinition(clang::SourceLocation,
clang::Decl*) + 84
31 clang-3.6                0x000000011376748f clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformDeclStmt(clang::DeclStmt*) + 207
32 clang-3.6                0x0000000113759e65 clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformStmt(clang::Stmt*) + 597
33 clang-3.6                0x000000011376f9dc clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformCompoundStmt(clang::CompoundStmt*,
bool) + 236
34 clang-3.6                0x000000011376737a clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformCompoundStmt(clang::CompoundStmt*)
+ 42
35 clang-3.6                0x0000000113759e03 clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformStmt(clang::Stmt*) + 499
36 clang-3.6                0x0000000113759be1
clang::Sema::SubstStmt(clang::Stmt*, clang::MultiLevelTemplateArgumentList
const&) + 129
37 clang-3.6                0x00000001137af279
clang::Sema::InstantiateFunctionDefinition(clang::SourceLocation,
clang::FunctionDecl*, bool, bool) + 3801
38 clang-3.6                0x0000000113709fb8
clang::Sema::DeduceReturnType(clang::FunctionDecl*, clang::SourceLocation,
bool) + 184
39 clang-3.6                0x00000001133643d0
clang::Sema::DiagnoseUseOfDecl(clang::NamedDecl*, clang::SourceLocation,
clang::ObjCInterfaceDecl const*, bool) + 912
40 clang-3.6                0x00000001135b1be0
clang::FinishOverloadedCallExpr(clang::Sema&, clang::Scope*, clang::Expr*,
clang::UnresolvedLookupExpr*, clang::SourceLocation,
llvm::MutableArrayRef<clang::Expr*>, clang::SourceLocation, clang::Expr*,
clang::OverloadCandidateSet*, clang::OverloadCandidate**,
clang::OverloadingResult, bool) + 464
41 clang-3.6                0x00000001135b19a9
clang::Sema::BuildOverloadedCallExpr(clang::Scope*, clang::Expr*,
clang::UnresolvedLookupExpr*, clang::SourceLocation,
llvm::MutableArrayRef<clang::Expr*>, clang::SourceLocation, clang::Expr*, bool)
+ 681
42 clang-3.6                0x000000011336a378
clang::Sema::ActOnCallExpr(clang::Scope*, clang::Expr*, clang::SourceLocation,
llvm::MutableArrayRef<clang::Expr*>, clang::SourceLocation, clang::Expr*, bool)
+ 2360
43 clang-3.6                0x000000011378c6a7 clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::RebuildCallExpr(clang::Expr*,
clang::SourceLocation, llvm::MutableArrayRef<clang::Expr*>,
clang::SourceLocation, clang::Expr*) + 167
44 clang-3.6                0x000000011378d253 clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformCallExpr(clang::CallExpr*) + 611
45 clang-3.6                0x000000011377d532 (anonymous
namespace)::TemplateInstantiator::TransformCallExpr(clang::CallExpr*) + 66
46 clang-3.6                0x000000011375b0e8 clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformExpr(clang::Expr*) + 1576
47 clang-3.6                0x000000011375a733 clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformStmt(clang::Stmt*) + 2851
48 clang-3.6                0x000000011376f9dc clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformCompoundStmt(clang::CompoundStmt*,
bool) + 236
49 clang-3.6                0x000000011376737a clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformCompoundStmt(clang::CompoundStmt*)
+ 42
50 clang-3.6                0x0000000113759e03 clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformStmt(clang::Stmt*) + 499
51 clang-3.6                0x0000000113759be1
clang::Sema::SubstStmt(clang::Stmt*, clang::MultiLevelTemplateArgumentList
const&) + 129
52 clang-3.6                0x00000001137af279
clang::Sema::InstantiateFunctionDefinition(clang::SourceLocation,
clang::FunctionDecl*, bool, bool) + 3801
53 clang-3.6                0x0000000113709fb8
clang::Sema::DeduceReturnType(clang::FunctionDecl*, clang::SourceLocation,
bool) + 184
54 clang-3.6                0x00000001133643d0
clang::Sema::DiagnoseUseOfDecl(clang::NamedDecl*, clang::SourceLocation,
clang::ObjCInterfaceDecl const*, bool) + 912
55 clang-3.6                0x00000001135b1be0
clang::FinishOverloadedCallExpr(clang::Sema&, clang::Scope*, clang::Expr*,
clang::UnresolvedLookupExpr*, clang::SourceLocation,
llvm::MutableArrayRef<clang::Expr*>, clang::SourceLocation, clang::Expr*,
clang::OverloadCandidateSet*, clang::OverloadCandidate**,
clang::OverloadingResult, bool) + 464
56 clang-3.6                0x00000001135b19a9
clang::Sema::BuildOverloadedCallExpr(clang::Scope*, clang::Expr*,
clang::UnresolvedLookupExpr*, clang::SourceLocation,
llvm::MutableArrayRef<clang::Expr*>, clang::SourceLocation, clang::Expr*, bool)
+ 681
57 clang-3.6                0x000000011336a378
clang::Sema::ActOnCallExpr(clang::Scope*, clang::Expr*, clang::SourceLocation,
llvm::MutableArrayRef<clang::Expr*>, clang::SourceLocation, clang::Expr*, bool)
+ 2360
58 clang-3.6                0x000000011378c6a7 clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::RebuildCallExpr(clang::Expr*,
clang::SourceLocation, llvm::MutableArrayRef<clang::Expr*>,
clang::SourceLocation, clang::Expr*) + 167
59 clang-3.6                0x000000011378d253 clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformCallExpr(clang::CallExpr*) + 611
60 clang-3.6                0x000000011377d532 (anonymous
namespace)::TemplateInstantiator::TransformCallExpr(clang::CallExpr*) + 66
61 clang-3.6                0x000000011375b0e8 clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformExpr(clang::Expr*) + 1576
62 clang-3.6                0x000000011375a733 clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformStmt(clang::Stmt*) + 2851
63 clang-3.6                0x000000011376f9dc clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformCompoundStmt(clang::CompoundStmt*,
bool) + 236
64 clang-3.6                0x000000011376737a clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformCompoundStmt(clang::CompoundStmt*)
+ 42
65 clang-3.6                0x0000000113759e03 clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformStmt(clang::Stmt*) + 499
66 clang-3.6                0x0000000113759be1
clang::Sema::SubstStmt(clang::Stmt*, clang::MultiLevelTemplateArgumentList
const&) + 129
67 clang-3.6                0x00000001137af279
clang::Sema::InstantiateFunctionDefinition(clang::SourceLocation,
clang::FunctionDecl*, bool, bool) + 3801
68 clang-3.6                0x0000000113709fb8
clang::Sema::DeduceReturnType(clang::FunctionDecl*, clang::SourceLocation,
bool) + 184
69 clang-3.6                0x00000001133643d0
clang::Sema::DiagnoseUseOfDecl(clang::NamedDecl*, clang::SourceLocation,
clang::ObjCInterfaceDecl const*, bool) + 912
70 clang-3.6                0x00000001135b1be0
clang::FinishOverloadedCallExpr(clang::Sema&, clang::Scope*, clang::Expr*,
clang::UnresolvedLookupExpr*, clang::SourceLocation,
llvm::MutableArrayRef<clang::Expr*>, clang::SourceLocation, clang::Expr*,
clang::OverloadCandidateSet*, clang::OverloadCandidate**,
clang::OverloadingResult, bool) + 464
71 clang-3.6                0x00000001135b19a9
clang::Sema::BuildOverloadedCallExpr(clang::Scope*, clang::Expr*,
clang::UnresolvedLookupExpr*, clang::SourceLocation,
llvm::MutableArrayRef<clang::Expr*>, clang::SourceLocation, clang::Expr*, bool)
+ 681
72 clang-3.6                0x000000011336a378
clang::Sema::ActOnCallExpr(clang::Scope*, clang::Expr*, clang::SourceLocation,
llvm::MutableArrayRef<clang::Expr*>, clang::SourceLocation, clang::Expr*, bool)
+ 2360
73 clang-3.6                0x000000011378c6a7 clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::RebuildCallExpr(clang::Expr*,
clang::SourceLocation, llvm::MutableArrayRef<clang::Expr*>,
clang::SourceLocation, clang::Expr*) + 167
74 clang-3.6                0x000000011378d253 clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformCallExpr(clang::CallExpr*) + 611
75 clang-3.6                0x000000011377d532 (anonymous
namespace)::TemplateInstantiator::TransformCallExpr(clang::CallExpr*) + 66
76 clang-3.6                0x000000011375b0e8 clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformExpr(clang::Expr*) + 1576
77 clang-3.6                0x000000011375a733 clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformStmt(clang::Stmt*) + 2851
78 clang-3.6                0x000000011376f9dc clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformCompoundStmt(clang::CompoundStmt*,
bool) + 236
79 clang-3.6                0x000000011376737a clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformCompoundStmt(clang::CompoundStmt*)
+ 42
80 clang-3.6                0x0000000113759e03 clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformStmt(clang::Stmt*) + 499
81 clang-3.6                0x0000000113759be1
clang::Sema::SubstStmt(clang::Stmt*, clang::MultiLevelTemplateArgumentList
const&) + 129
82 clang-3.6                0x00000001137af279
clang::Sema::InstantiateFunctionDefinition(clang::SourceLocation,
clang::FunctionDecl*, bool, bool) + 3801
83 clang-3.6                0x0000000113709fb8
clang::Sema::DeduceReturnType(clang::FunctionDecl*, clang::SourceLocation,
bool) + 184
84 clang-3.6                0x00000001133643d0
clang::Sema::DiagnoseUseOfDecl(clang::NamedDecl*, clang::SourceLocation,
clang::ObjCInterfaceDecl const*, bool) + 912
85 clang-3.6                0x00000001135b1be0
clang::FinishOverloadedCallExpr(clang::Sema&, clang::Scope*, clang::Expr*,
clang::UnresolvedLookupExpr*, clang::SourceLocation,
llvm::MutableArrayRef<clang::Expr*>, clang::SourceLocation, clang::Expr*,
clang::OverloadCandidateSet*, clang::OverloadCandidate**,
clang::OverloadingResult, bool) + 464
86 clang-3.6                0x00000001135b19a9
clang::Sema::BuildOverloadedCallExpr(clang::Scope*, clang::Expr*,
clang::UnresolvedLookupExpr*, clang::SourceLocation,
llvm::MutableArrayRef<clang::Expr*>, clang::SourceLocation, clang::Expr*, bool)
+ 681
87 clang-3.6                0x000000011336a378
clang::Sema::ActOnCallExpr(clang::Scope*, clang::Expr*, clang::SourceLocation,
llvm::MutableArrayRef<clang::Expr*>, clang::SourceLocation, clang::Expr*, bool)
+ 2360
88 clang-3.6                0x0000000112e60b7c
clang::Parser::ParsePostfixExpressionSuffix(clang::ActionResult<clang::Expr*,
true>) + 3580
89 clang-3.6                0x0000000112e65a69
clang::Parser::ParseCastExpression(bool, bool, bool&,
clang::Parser::TypeCastState) + 17225
90 clang-3.6                0x0000000112e5fc83
clang::Parser::ParseCastExpression(bool, bool, clang::Parser::TypeCastState) +
83
91 clang-3.6                0x0000000112e5eb74
clang::Parser::ParseAssignmentExpression(clang::Parser::TypeCastState) + 196
92 clang-3.6                0x0000000112e5ea7f
clang::Parser::ParseExpression(clang::Parser::TypeCastState) + 31
93 clang-3.6                0x0000000112ea46ac
clang::Parser::ParseExprStatement() + 60
94 clang-3.6                0x0000000112ea3689
clang::Parser::ParseStatementOrDeclarationAfterAttributes(llvm::SmallVector<clang::Stmt*,
32u>&, bool, clang::SourceLocation*, clang::Parser::ParsedAttributesWithRange&)
+ 2649
95 clang-3.6                0x0000000112ea2ae5
clang::Parser::ParseStatementOrDeclaration(llvm::SmallVector<clang::Stmt*,
32u>&, bool, clang::SourceLocation*) + 133
96 clang-3.6                0x0000000112ea9f62
clang::Parser::ParseCompoundStatementBody(bool) + 1282
97 clang-3.6                0x0000000112eaaad8
clang::Parser::ParseFunctionStatementBody(clang::Decl*,
clang::Parser::ParseScope&) + 328
98 clang-3.6                0x0000000112ec764d
clang::Parser::ParseFunctionDefinition(clang::ParsingDeclarator&,
clang::Parser::ParsedTemplateInfo const&, clang::Parser::LateParsedAttrList*) +
3709
99 clang-3.6                0x0000000112e30f08
clang::Parser::ParseDeclGroup(clang::ParsingDeclSpec&, unsigned int, bool,
clang::SourceLocation*, clang::Parser::ForRangeInit*) + 520
100 clang-3.6                0x0000000112ec67bc
clang::Parser::ParseDeclOrFunctionDefInternal(clang::Parser::ParsedAttributesWithRange&,
clang::ParsingDeclSpec&, clang::AccessSpecifier) + 1228
101 clang-3.6                0x0000000112ec5ed5
clang::Parser::ParseDeclarationOrFunctionDefinition(clang::Parser::ParsedAttributesWithRange&,
clang::ParsingDeclSpec*, clang::AccessSpecifier) + 197
102 clang-3.6                0x0000000112ec5660
clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&,
clang::ParsingDeclSpec*) + 3456
103 clang-3.6                0x0000000112ec4895
clang::Parser::ParseTopLevelDecl(clang::OpaquePtr<clang::DeclGroupRef>&) + 773
104 clang-3.6                0x0000000112e1efec clang::ParseAST(clang::Sema&,
bool, bool) + 988
105 clang-3.6                0x0000000111d8eb3a
clang::ASTFrontendAction::ExecuteAction() + 522
106 clang-3.6                0x0000000112341853
clang::CodeGenAction::ExecuteAction() + 3939
107 clang-3.6                0x0000000111d8e0b8
clang::FrontendAction::Execute() + 120
108 clang-3.6                0x0000000111d1fe49
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 1017
109 clang-3.6                0x0000000111dfdff1
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 3201
110 clang-3.6                0x000000010fff6290 cc1_main(llvm::ArrayRef<char
const*>, char const*, void*) + 2496
111 clang-3.6                0x000000010ffe964b
ExecuteCC1Tool(llvm::ArrayRef<char const*>, llvm::StringRef) + 171
112 clang-3.6                0x000000010ffe8407 main + 1271
113 libdyld.dylib            0x00007fff8b48c5fd start + 1
Stack dump:
0.  Program arguments: /Users/ldionne/code/llvm/debug/bin/clang-3.6 -cc1
-triple x86_64-apple-macosx10.9.0 -emit-obj -mrelax-all -disable-free
-main-file-name main.cpp -mrelocation-model pic -pic-level 2 -mthread-model
posix -mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu core2
-dwarf-column-info -resource-dir
/Users/ldionne/code/llvm/debug/bin/../lib/clang/3.6.0 -stdlib=libc++ -std=c++1y
-fdeprecated-macro -fdebug-compilation-dir /Users/ldionne/code/hana/debug
-ferror-limit 19 -fmessage-length 0 -stack-protector 1 -mstackrealign -fblocks
-fobjc-runtime=macosx-10.9.0 -fencode-extended-block-signature -fcxx-exceptions
-fexceptions -fmax-type-align=16 -fdiagnostics-show-option -o
/var/folders/6f/d7xhg3bx4zq467t3d6kb4fr80000gn/T/main-330091.o -x c++
/Users/ldionne/desktop/bugreports/segfault_capture/main.cpp 
1.  /Users/ldionne/desktop/bugreports/segfault_capture/main.cpp:31:14: current
parser token ')'
2.  /Users/ldionne/desktop/bugreports/segfault_capture/main.cpp:29:12: parsing
function body 'main'
3.  /Users/ldionne/desktop/bugreports/segfault_capture/main.cpp:29:12: in
compound statement ('{}')
clang-3.6: error: unable to execute command: Illegal instruction: 4
clang-3.6: error: clang frontend command failed due to signal (use -v to see
invocation)
clang version 3.6.0 
Target: x86_64-apple-darwin13.4.0
Thread model: posix
clang-3.6: 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.6: 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.6: note: diagnostic msg:
/var/folders/6f/d7xhg3bx4zq467t3d6kb4fr80000gn/T/main-c04c11.cpp
clang-3.6: note: diagnostic msg:
/var/folders/6f/d7xhg3bx4zq467t3d6kb4fr80000gn/T/main-c04c11.sh
clang-3.6: 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/20141105/dcdb1507/attachment.html>

From bugzilla-daemon at llvm.org  Wed Nov  5 10:21:47 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 05 Nov 2014 18:21:47 +0000
Subject: [LLVMbugs] [Bug 21465] [NVPTX] byval parameters are incorrectly
	lowered
In-Reply-To: <bug-21465-206@http.llvm.org/bugs/>
References: <bug-21465-206@http.llvm.org/bugs/>
Message-ID: <bug-21465-206-lB5NxhTpeS@http.llvm.org/bugs/>

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

Justin Holewinski <justin.holewinski at gmail.com> changed:

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

--- Comment #4 from Justin Holewinski <justin.holewinski at gmail.com> ---
Should be fixed in r221377.  However, this requires an opt-level pass, so
you'll have to add -nvptx-lower-struct-args to your opt line.

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

From bugzilla-daemon at llvm.org  Wed Nov  5 10:26:18 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 05 Nov 2014 18:26:18 +0000
Subject: [LLVMbugs] [Bug 21490] New: LTO treats ObjC @selector's as compile
 time constants, which they are not
Message-ID: <bug-21490-206@http.llvm.org/bugs/>

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

            Bug ID: 21490
           Summary: LTO treats ObjC @selector's as compile time constants,
                    which they are not
           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: freik at fb.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

For static/global values initialized with @selector syntax, the link time
optimizer treats them as if they're compile-time constants. This is true for
OSX and iOS.

Compile this -O2 (or -O3) with & without -flto:

#include <stdio.h>
#import <Foundation/Foundation.h>

@interface MyInterface : NSObject
  // This selector also exists on NSString, so it gets adjusted at load time
  -(NSUInteger)length;
@end

static SEL MySel = @selector(length);

int main(int argc, const char * argv[]) {
  if (@selector(length) != MySel) {
    printf("LTO BUG!\n");
    return -1;
  }
  return 0;
}

The workaround for this issue is to use sel_registerName("length") instead of
the @selector syntax, though this is much slower.

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

From bugzilla-daemon at llvm.org  Wed Nov  5 12:52:31 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 05 Nov 2014 20:52:31 +0000
Subject: [LLVMbugs] [Bug 21491] New: Add to C libclang API the ability to
 detect whether namespace are inline, whether a template type is a pack,
 and whether an enum is scoped
Message-ID: <bug-21491-206@http.llvm.org/bugs/>

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

            Bug ID: 21491
           Summary: Add to C libclang API the ability to detect whether
                    namespace are inline, whether a template type is a
                    pack, and whether an enum is scoped
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: libclang
          Assignee: unassignedclangbugs at nondot.org
          Reporter: s_bugzilla at nedprod.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Inline namespaces:

  bool isInline=false;
  {
    using namespace clang;
    const Decl *D = static_cast<const Decl *>(cursor.data[0]);
    if(const NamespaceDecl *TD = dyn_cast_or_null<NamespaceDecl>(D))
    {
      isInline=TD->isInline();
    }
  }

Parameter packs:

                        bool isPack=false;
                        {
                          using namespace clang;
                          QualType T =
QualType::getFromOpaquePtr(type.data[0]);
                          if (!T.isNull())
                          {
                            isPack=T->containsUnexpandedParameterPack();
                          }
                        }


Scoped enums:

                  bool isScoped=false;
                  {
                    using namespace clang;
                    const Decl *D = static_cast<const Decl *>(cursor.data[0]);
                    if(const EnumDecl *TD = dyn_cast_or_null<EnumDecl>(D))
                    {
                      isScoped=TD->isScoped();
                    }
                  }

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

From bugzilla-daemon at llvm.org  Wed Nov  5 13:34:36 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 05 Nov 2014 21:34:36 +0000
Subject: [LLVMbugs] [Bug 21492] New: Fused Multiply-Add (FMA) yields wrong
 results when inlined
Message-ID: <bug-21492-206@http.llvm.org/bugs/>

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

            Bug ID: 21492
           Summary: Fused Multiply-Add (FMA) yields wrong results when
                    inlined
           Product: new-bugs
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: dan.spencer.np at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Reproducible in:

* x86-64 Ubuntu 14.04, clang++ 3.4 and 3.5.1
* x86-64 Ubuntu 14.04, Rust nightly

If the third argument to std::fma() in C++11 or Float::mul_add() in Rust is 0,
it always returns the first argument. If the third argument is != 0, it returns
the correct result. This happens for both the float and double types.
The issue occurs only when all arguments are constants and compiler
optimizations are turned on. This is why I believe this is an issue with LLVM
inlining the call.
gcc does not produce this issue.

clang++ -O2 --std=c++11 fmatest.cpp

    #include <cmath>
    #include <iostream>

    int main() {
        // prints "10"
        std::cout << std::fma(10.0f, 20.0f, 0.0f) << std::endl;

        // prints "200.001" (10*20 + 0.001)
        std::cout << std::fma(10.0f, 20.0f, 0.001f) << std::endl;
        return 0;
    }

rustc -O fmatest.rs

    fn main() {
        // prints "10"
        println!("{}", Float::mul_add(10.0f32, 20.0, 0.0));

        // prints "200.001007" (10*20 + 0.001)
        println!("{}", Float::mul_add(10.0f32, 20.0, 0.001));
    }

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

From bugzilla-daemon at llvm.org  Wed Nov  5 13:44:48 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 05 Nov 2014 21:44:48 +0000
Subject: [LLVMbugs] [Bug 21493] New: Compilation error when initializing in
 an agreggate containing a deleted copy constructor using initializer list
 from a template function
Message-ID: <bug-21493-206@http.llvm.org/bugs/>

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

            Bug ID: 21493
           Summary: Compilation error when initializing in an agreggate
                    containing a deleted copy constructor using
                    initializer list from  a template function
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++11
          Assignee: unassignedclangbugs at nondot.org
          Reporter: ogoffart at kde.org
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified

This valid code:

struct X  { X(int);  X(const X&) = delete; };
struct A { X v; };
template <typename T> void id() { A s{ {0 } }; }
int main() { id<A>(); }

does not compile:

test.cc:3:43: error: call to deleted constructor of 'X'
template <typename T> void id() {  A s  { {0 }  }; }
                                          ^~~~
test.cc:4:14: note: in instantiation of function template specialization
'id<A>' requested here
int main() { id<A>(); }
             ^
test.cc:1:22: note: 'X' has been explicitly marked deleted here
struct X  { X(int);  X(const X&) = 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/20141105/bf3ce690/attachment.html>

From bugzilla-daemon at llvm.org  Wed Nov  5 14:05:16 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 05 Nov 2014 22:05:16 +0000
Subject: [LLVMbugs] [Bug 21494] New: It might be worth it to lazy link
	globals too
Message-ID: <bug-21494-206@http.llvm.org/bugs/>

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

            Bug ID: 21494
           Summary: It might be worth it to lazy link globals too
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Linker
          Assignee: unassignedbugs at nondot.org
          Reporter: rafael.espindola at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Given

@foo = private global i8 0
define private void @foo2() {
  ret void
}

@bar = linkonce_odr global i8 0
define linkonce_odr void @bar2() {
  ret void
}


The linker will copy the globals, but not the functions. It would probably be a
good idea to be lazy about the globals too.

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

From bugzilla-daemon at llvm.org  Wed Nov  5 14:35:39 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 05 Nov 2014 22:35:39 +0000
Subject: [LLVMbugs] [Bug 21492] Fused Multiply-Add (FMA) yields wrong
 results when inlined
In-Reply-To: <bug-21492-206@http.llvm.org/bugs/>
References: <bug-21492-206@http.llvm.org/bugs/>
Message-ID: <bug-21492-206-nzq0YXgiZE@http.llvm.org/bugs/>

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

Hal Finkel <hfinkel at anl.gov> changed:

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

--- Comment #3 from Hal Finkel <hfinkel at anl.gov> ---
Confirmed (fixed by r220776).

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

From bugzilla-daemon at llvm.org  Wed Nov  5 15:01:35 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 05 Nov 2014 23:01:35 +0000
Subject: [LLVMbugs] [Bug 21495] New: clang should prevent the .c files to
 get overwritten
Message-ID: <bug-21495-206@http.llvm.org/bugs/>

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

            Bug ID: 21495
           Summary: clang should prevent the .c files to get overwritten
           Product: clang
           Version: unspecified
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
          Assignee: unassignedclangbugs at nondot.org
          Reporter: wkoszek at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

>From gcc bug report; clang is 'vulnerable' too:
==================
Suggestion: prevent GCC from overwriting source code files when invoked as:

gcc source.c -o source.c

Background: I use command completion heavily. Very often while in coding mood I
do:

gcc myfile.c -o myf<TAB>

not to type "myfile", which is long. But after completion kicks in, I sometimes
forget to do <BACKSPACE><BACKSPACE>.

And .c file gets overwritten.

It'd be nice to have GCC catch this. And if you really want to do it, maybe run
GCC with: --yes-im-sure-i-want-to-overwrite-my-source-code switch.

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

GCC links:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63462
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36312

This feature has been checked-in to Clang already. Would be nice to see Clang
fixed too.

Thanks,
Wojciech

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

From bugzilla-daemon at llvm.org  Wed Nov  5 16:41:50 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 06 Nov 2014 00:41:50 +0000
Subject: [LLVMbugs] [Bug 17655] [-cxx-abi microsoft] Support non-trivial
 pass-by-value method thunks
In-Reply-To: <bug-17655-206@http.llvm.org/bugs/>
References: <bug-17655-206@http.llvm.org/bugs/>
Message-ID: <bug-17655-206-QMJ5xLRrIi@http.llvm.org/bugs/>

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

Reid Kleckner <rnk at google.com> changed:

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

--- Comment #6 from Reid Kleckner <rnk at google.com> ---
This was fixed at some point, I think by testing if the function prototype is
lowerable.

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

From bugzilla-daemon at llvm.org  Wed Nov  5 16:43:33 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 06 Nov 2014 00:43:33 +0000
Subject: [LLVMbugs] [Bug 21398] Homegeneous aggregates with C++ base classes
 passed incorrectly on PPC64, ARM, and Aarch64
In-Reply-To: <bug-21398-206@http.llvm.org/bugs/>
References: <bug-21398-206@http.llvm.org/bugs/>
Message-ID: <bug-21398-206-UN9WUEbNSc@http.llvm.org/bugs/>

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

Reid Kleckner <rnk at google.com> changed:

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

--- Comment #6 from Reid Kleckner <rnk at google.com> ---
Should be fixed for ARM and AArch64 with r220972.

Really closing this time.

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

From bugzilla-daemon at llvm.org  Wed Nov  5 16:52:38 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 06 Nov 2014 00:52:38 +0000
Subject: [LLVMbugs] [Bug 17832] Assertion failed: SS.isEmpty() &&
 "qualifiers should be already handled"
In-Reply-To: <bug-17832-206@http.llvm.org/bugs/>
References: <bug-17832-206@http.llvm.org/bugs/>
Message-ID: <bug-17832-206-wHYdO8xiqS@http.llvm.org/bugs/>

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

Reid Kleckner <rnk at google.com> changed:

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

--- Comment #2 from Reid Kleckner <rnk at google.com> ---
This no longer reproduces, we give errors:

t.cpp:1:38: error: expected class name
template <class T> struct B : public A {};
                                     ^
t.cpp:3:20: error: no member named 'f' in the global namespace
  C(int &&) : _D(::f(0)) {}
                 ~~^
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/20141106/bfd78019/attachment.html>

From bugzilla-daemon at llvm.org  Wed Nov  5 18:34:49 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 06 Nov 2014 02:34:49 +0000
Subject: [LLVMbugs] [Bug 21496] New: string_view::remove_prefix,
 remove_suffix should leave n > size() UB
Message-ID: <bug-21496-206@http.llvm.org/bugs/>

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

            Bug ID: 21496
           Summary: string_view::remove_prefix, remove_suffix should leave
                    n > size() UB
           Product: libc++
           Version: unspecified
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: All Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: lichray at gmail.com
                CC: llvmbugs at cs.uiuc.edu, mclow.lists at gmail.com
    Classification: Unclassified

They have explicit narrow contract:

  Requires: n <= size()

, but the libc++ made them work same as n == size(), which creates portability
problems.  For reference, libstdc++'s remove_prefix is guarded by assertion,
remove_suffix is just `this->_M_len -= __n;` (which may worth to be guarded as
well, but that's their 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/20141106/2d357f5d/attachment.html>

From bugzilla-daemon at llvm.org  Wed Nov  5 21:09:06 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 06 Nov 2014 05:09:06 +0000
Subject: [LLVMbugs] [Bug 21497] New: miscompilation after SVN r220256
Message-ID: <bug-21497-206@http.llvm.org/bugs/>

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

            Bug ID: 21497
           Summary: miscompilation after SVN r220256
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: X86
          Assignee: unassignedbugs at nondot.org
          Reporter: compnerd at compnerd.org
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Slightly reduced test case:

// RUN: %clang -fPIC -target i686-windows-itanium -c %s

extern int a();
extern int b();
extern int c();
extern int d();

int test(long long ll, void *pv) {
  int result = 1;
  switch (ll) {
  case 1:
    result = a();
    break;
  case 2:
    result = c();
    break;
  case 3:
    result = d();
    break;
  case 4:
    if (pv == 0) {
      (void)d();
      result = b();
    } else {
    }
    break;
  }
  return (result);
}

Setting SetDirectiveSuppressesReloc to true corrects 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/20141106/01fe80e5/attachment.html>

From bugzilla-daemon at llvm.org  Thu Nov  6 01:45:47 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 06 Nov 2014 09:45:47 +0000
Subject: [LLVMbugs] [Bug 21498] New: UBSan: check size/type mismatch of
 global variables across modules
Message-ID: <bug-21498-206@http.llvm.org/bugs/>

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

            Bug ID: 21498
           Summary: UBSan: check size/type mismatch of global variables
                    across modules
           Product: clang
           Version: trunk
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: y.gribov at samsung.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

C99 states that declaring same global variable with incompatible types in
different units of translation is undefined behavior (6.7.5.2 item 6). So e.g.
having int a[10]; in tmp.c and int a[100]; in tmp2.c would be a UB. We should
be able to check this easily by registering all referenced globals in .c in
libubsan via callbacks at program start. Libubsan could than find size/type
mismatches and report warning.

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

From bugzilla-daemon at llvm.org  Thu Nov  6 04:20:29 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 06 Nov 2014 12:20:29 +0000
Subject: [LLVMbugs] [Bug 21499] New: __sync_bool_compare_and_swap
Message-ID: <bug-21499-206@http.llvm.org/bugs/>

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

            Bug ID: 21499
           Summary: __sync_bool_compare_and_swap
           Product: clang
           Version: 3.5
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: keith at bostic.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

In clang 3.5, we're seeing __sync_bool_compare_and_swap not working as
documented. If we switch from __sync_bool_compare_and_swap to
__sync_val_compare_and_swap, our tests start passing again.

We don't see the same failure with clang 3.6.

The test is relatively complex (MongoDB test suite running on top of the
WiredTiger storage engine), so it's tough to create a standalone test.

If this is interesting, we'd be happy to run any tests or diagnostics that
would be helpful, the failure reproduces reliably.

keith at bostic.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/20141106/7e3fc636/attachment.html>

From bugzilla-daemon at llvm.org  Thu Nov  6 05:13:01 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 06 Nov 2014 13:13:01 +0000
Subject: [LLVMbugs] [Bug 21500] New: Incorrect assembly in .macro
Message-ID: <bug-21500-206@http.llvm.org/bugs/>

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

            Bug ID: 21500
           Summary: Incorrect assembly in .macro
           Product: new-bugs
           Version: 3.4
          Hardware: PC
                OS: FreeBSD
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: rth at twiddle.net
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

$ cat z.S
#define FOO    15
.macro    bar
    andl    $FOO, %eax
.endm
    bar
$ cc -c z.S
$ objdump -d z.o

z.o:     file format elf64-x86-64-freebsd


Disassembly of section .text:

0000000000000000 <.text>:
   0:    23 04 25 05 00 00 00     and    0x5,%eax


Note "0x5" not the expected "0xf".

$ cc -v
FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512
Target: x86_64-unknown-freebsd10.1
Thread model: posix
Selected GCC installation:

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

From bugzilla-daemon at llvm.org  Thu Nov  6 05:24:55 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 06 Nov 2014 13:24:55 +0000
Subject: [LLVMbugs] [Bug 21501] New: .org confused by .align
Message-ID: <bug-21501-206@http.llvm.org/bugs/>

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

            Bug ID: 21501
           Summary: .org confused by .align
           Product: new-bugs
           Version: 3.4
          Hardware: PC
                OS: FreeBSD
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: rth at twiddle.net
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

The assembler is attempting to resolve expressions before resolving alignment.

$ cat z.S
0:
    .org    0b + 3, 0x90
    .align    8
    .org    0b + 11, 0x90
$ cc -c z.S
z.S:4:7: error: expected assembly-time absolute expression
 .org 0b + 11, 0x90

Note that this works with gas:

$ as -o z.o z.S
$ objdump -dr z.o

z.o:     file format elf64-x86-64-freebsd


Disassembly of section .text:

0000000000000000 <.text>:
   0:    90                       nop
   1:    90                       nop
   2:    90                       nop
   3:    0f 1f 44 00 00           nopl   0x0(%rax,%rax,1)
   8:    90                       nop
   9:    90                       nop
   a:    90                       nop

$ as --version
GNU assembler (GNU Binutils) 2.24
Copyright 2013 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or later.
This program has absolutely no warranty.
This assembler was configured for a target of `x86_64-portbld-freebsd10.0'.
$ cc --version
FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512
Target: x86_64-unknown-freebsd10.1
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/20141106/05ab2727/attachment.html>

From bugzilla-daemon at llvm.org  Thu Nov  6 06:01:19 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 06 Nov 2014 14:01:19 +0000
Subject: [LLVMbugs] [Bug 18086] Implement Pragma Vectorize -
	Choice/Parameters
In-Reply-To: <bug-18086-206@http.llvm.org/bugs/>
References: <bug-18086-206@http.llvm.org/bugs/>
Message-ID: <bug-18086-206-sm1wZchhJV@http.llvm.org/bugs/>

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

Renato Golin <renato.golin at linaro.org> 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/20141106/ae2601d2/attachment.html>

From bugzilla-daemon at llvm.org  Thu Nov  6 06:02:44 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 06 Nov 2014 14:02:44 +0000
Subject: [LLVMbugs] [Bug 20683] Create a Target description API which is
 able (and responsible) to parse all common options
In-Reply-To: <bug-20683-206@http.llvm.org/bugs/>
References: <bug-20683-206@http.llvm.org/bugs/>
Message-ID: <bug-20683-206-WIyaNguNfT@http.llvm.org/bugs/>

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

Renato Golin <renato.golin at linaro.org> changed:

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

--- Comment #1 from Renato Golin <renato.golin at linaro.org> ---


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

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

From bugzilla-daemon at llvm.org  Thu Nov  6 06:41:11 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 06 Nov 2014 14:41:11 +0000
Subject: [LLVMbugs] [Bug 21497] miscompilation after SVN r220256
In-Reply-To: <bug-21497-206@http.llvm.org/bugs/>
References: <bug-21497-206@http.llvm.org/bugs/>
Message-ID: <bug-21497-206-NPk9WKqmKY@http.llvm.org/bugs/>

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

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

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

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

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

From bugzilla-daemon at llvm.org  Thu Nov  6 08:22:33 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 06 Nov 2014 16:22:33 +0000
Subject: [LLVMbugs] [Bug 21498] UBSan: check size/type mismatch of global
 variables across modules
In-Reply-To: <bug-21498-206@http.llvm.org/bugs/>
References: <bug-21498-206@http.llvm.org/bugs/>
Message-ID: <bug-21498-206-jxu894T1XO@http.llvm.org/bugs/>

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

Kostya Serebryany <kcc at google.com> changed:

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

--- Comment #1 from Kostya Serebryany <kcc at google.com> ---
This feature is present in asan: 
https://code.google.com/p/address-sanitizer/wiki/OneDefinitionRuleViolation

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

From bugzilla-daemon at llvm.org  Thu Nov  6 08:23:01 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 06 Nov 2014 16:23:01 +0000
Subject: [LLVMbugs] [Bug 8787] Support/Regex is unaware of LLP64(Win64)
In-Reply-To: <bug-8787-206@http.llvm.org/bugs/>
References: <bug-8787-206@http.llvm.org/bugs/>
Message-ID: <bug-8787-206-Lk39WcTVWA@http.llvm.org/bugs/>

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

Reid Kleckner <rnk at google.com> changed:

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

--- Comment #3 from Reid Kleckner <rnk at google.com> ---
(In reply to comment #2)
> I have committed above as r121942.
> I think it is still workaround.
> I added FIXME and I will leave this issue opened.
> 
> /* FIXME: 'states' is assumed as 'long' on small version. */
> 
> Consider, to 'states, giving 'uint64_t' on i686,
> and giving 'short' on any hosts.

I don't think we need to do anything here. This workaround has held up fine for
four years, and by the time it stops working we can switch to C++11 <regex>.
This is still marked as blocking a win64 self-host, which already works.

Feel free to reopen if you feel otherwise.

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

From bugzilla-daemon at llvm.org  Thu Nov  6 08:23:03 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 06 Nov 2014 16:23:03 +0000
Subject: [LLVMbugs] [Bug 9100] [META][Win64] Selfhosting clang/llvm on/for
	Windows x64
In-Reply-To: <bug-9100-206@http.llvm.org/bugs/>
References: <bug-9100-206@http.llvm.org/bugs/>
Message-ID: <bug-9100-206-uWKN1C8aj8@http.llvm.org/bugs/>

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

Bug 9100 depends on bug 8787, which changed state.

Bug 8787 Summary: Support/Regex is unaware of LLP64(Win64)
http://llvm.org/bugs/show_bug.cgi?id=8787

           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/20141106/4340c151/attachment.html>

From bugzilla-daemon at llvm.org  Thu Nov  6 08:29:19 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 06 Nov 2014 16:29:19 +0000
Subject: [LLVMbugs] [Bug 8833] [Win64] clang/test: LLP64-unaware tests
In-Reply-To: <bug-8833-206@http.llvm.org/bugs/>
References: <bug-8833-206@http.llvm.org/bugs/>
Message-ID: <bug-8833-206-2ItvOGkIql@http.llvm.org/bugs/>

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

Bug 8833 depends on bug 13819, which changed state.

Bug 13819 Summary: __SIZE_TYPE__ is incompatible to -pedantic with LLP64 Win64
http://llvm.org/bugs/show_bug.cgi?id=13819

           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/20141106/c940230f/attachment.html>

From bugzilla-daemon at llvm.org  Thu Nov  6 08:29:18 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 06 Nov 2014 16:29:18 +0000
Subject: [LLVMbugs] [Bug 13819] __SIZE_TYPE__ is incompatible to -pedantic
 with LLP64 Win64
In-Reply-To: <bug-13819-206@http.llvm.org/bugs/>
References: <bug-13819-206@http.llvm.org/bugs/>
Message-ID: <bug-13819-206-WRtNq5a6Mf@http.llvm.org/bugs/>

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

Reid Kleckner <rnk at google.com> changed:

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

--- Comment #3 from Reid Kleckner <rnk at google.com> ---
I think we can close this out. We don't warn by default. We warn with -pedantic
in c++98 and say that it's a C++11 extension (-Wc++11-long-long).  Time will
make this problem go away as users move to 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/20141106/b56333e5/attachment.html>

From bugzilla-daemon at llvm.org  Thu Nov  6 08:36:20 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 06 Nov 2014 16:36:20 +0000
Subject: [LLVMbugs] [Bug 11534] Properly lookup .lib files on command line
 on MS/Windows.
In-Reply-To: <bug-11534-206@http.llvm.org/bugs/>
References: <bug-11534-206@http.llvm.org/bugs/>
Message-ID: <bug-11534-206-VrSIeSb7Ab@http.llvm.org/bugs/>

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

Reid Kleckner <rnk at google.com> changed:

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

--- Comment #7 from Reid Kleckner <rnk at google.com> ---
(In reply to comment #6)
> Shouldn't this bug be closed? clang-cl already handles .lib files.

Yep.

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

From bugzilla-daemon at llvm.org  Thu Nov  6 08:36:23 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 06 Nov 2014 16:36:23 +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-KRr79NEnGk@http.llvm.org/bugs/>

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

Bug 13707 depends on bug 11534, which changed state.

Bug 11534 Summary: Properly lookup .lib files on command line on MS/Windows.
http://llvm.org/bugs/show_bug.cgi?id=11534

           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/20141106/7f9a971e/attachment.html>

From bugzilla-daemon at llvm.org  Thu Nov  6 09:26:30 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 06 Nov 2014 17:26:30 +0000
Subject: [LLVMbugs] [Bug 21498] UBSan: check size/type mismatch of global
 variables across modules
In-Reply-To: <bug-21498-206@http.llvm.org/bugs/>
References: <bug-21498-206@http.llvm.org/bugs/>
Message-ID: <bug-21498-206-pNBa8yf2Bs@http.llvm.org/bugs/>

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

Yury Gribov <y.gribov at samsung.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         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/20141106/8236d8df/attachment.html>

From bugzilla-daemon at llvm.org  Thu Nov  6 09:53:45 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 06 Nov 2014 17:53:45 +0000
Subject: [LLVMbugs] [Bug 21502] New:
 __has_feature(cxx_reference_qualified_functions) should be checked when
 defining LLVM_HAS_RVALUE_REFERENCE_THIS
Message-ID: <bug-21502-206@http.llvm.org/bugs/>

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

            Bug ID: 21502
           Summary: __has_feature(cxx_reference_qualified_functions)
                    should be checked when defining
                    LLVM_HAS_RVALUE_REFERENCE_THIS
           Product: clang
           Version: unspecified
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
          Assignee: unassignedclangbugs at nondot.org
          Reporter: igor.bronstein at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

LLVM_HAS_RVALUE_REFERENCE_THIS macro is defined int Compiler.h:
http://llvm.org/docs/doxygen/html/Compiler_8h.html#a563b0d795936bbc69d7a40c6791c5827

in the way as follows:
00080 #if __has_feature(cxx_rvalue_references) || LLVM_GNUC_PREREQ(4, 8, 1)
00081 #define LLVM_HAS_RVALUE_REFERENCE_THIS 1
00082 #else
00083 #define LLVM_HAS_RVALUE_REFERENCE_THIS 0
00084 #endif

Shouldn't its definition look like:

00080 #if __has_feature(cxx_reference_qualified_functions) ||
LLVM_GNUC_PREREQ(4, 8, 1)
00081 #define LLVM_HAS_RVALUE_REFERENCE_THIS 1
00082 #else
00083 #define LLVM_HAS_RVALUE_REFERENCE_THIS 0
00084 #endif

instead? __has_feature(cxx_reference_qualified_functions) checks whether Clang
support "Extending move semantics to *this" C+11 feature:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2439.htm

and that's exactly what the LLVM_HAS_RVALUE_REFERENCE_THIS is intended for.

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

From bugzilla-daemon at llvm.org  Thu Nov  6 10:19:01 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 06 Nov 2014 18:19:01 +0000
Subject: [LLVMbugs] [Bug 21503] New: checker-276 published on web site
 doesn't support new parameters from Xcode 6
Message-ID: <bug-21503-206@http.llvm.org/bugs/>

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

            Bug ID: 21503
           Summary: checker-276 published on web site doesn't support new
                    parameters from Xcode 6
           Product: clang
           Version: 3.5
          Hardware: Macintosh
                OS: MacOS X
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Static Analyzer
          Assignee: kremenek at apple.com
          Reporter: francis.labrie at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

checker-276 published on February 19, 2014 is the latest version available on
the Clang Static Analyser web site at http://clang-analyzer.llvm.org/.

Unfortunately, this version seems to be too old for Xcode 6: some new
parameters are not supported and make our Jenkins jobs to fail. Example:

clang: error: unknown argument: '-fmodule-implementation-of'
clang: error: cannot specify -o when generating multiple output files
Command /usr/checker-276/bin/clang failed with exit code 1

Would it be possible to update the Clang Static Analyser package on that site
to make it compatible with latest Xcode release? 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/20141106/41b46ca3/attachment.html>

From bugzilla-daemon at llvm.org  Thu Nov  6 10:32:20 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 06 Nov 2014 18:32:20 +0000
Subject: [LLVMbugs] [Bug 21504] New: should we forward our complex math to
	libm?
Message-ID: <bug-21504-206@http.llvm.org/bugs/>

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

            Bug ID: 21504
           Summary: should we forward our complex math to libm?
           Product: libc++
           Version: unspecified
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: All Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: danalbert at google.com
                CC: llvmbugs at cs.uiuc.edu, mclow.lists at gmail.com
    Classification: Unclassified

Is there any reason we're not delegating the math in <complex> to <complex.h>?
I don't believe any of us look at this code too closely (or very often), so
delegating to the lower library means we wouldn't have to worry about it any
more.

It looks like we don't have any tests for accuracy of these functions, whereas
the math libraries will be focused on 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/20141106/dec8cad7/attachment.html>

From bugzilla-daemon at llvm.org  Thu Nov  6 10:57:56 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 06 Nov 2014 18:57:56 +0000
Subject: [LLVMbugs] [Bug 21505] New: Quoting in the compilation database
 example is wrong
Message-ID: <bug-21505-206@http.llvm.org/bugs/>

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

            Bug ID: 21505
           Summary: Quoting in the compilation database example is wrong
           Product: Documentation
           Version: trunk
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: General docs
          Assignee: unassignedbugs at nondot.org
          Reporter: dpb at corrigendum.ru
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

... or at least misleading.

I'm talking about this page:
<http://clang.llvm.org/docs/JSONCompilationDatabase.html>.

The example compilation command is, in JSON:

"/usr/bin/clang++ -Irelative -DSOMEDEF=\"With spaces, quotes and \\-es.\" -c -o
file.o file.cc"

Unapplying the JSON quoting, we get the shell command:

/usr/bin/clang++ -Irelative -DSOMEDEF="With spaces, quotes and \-es." -c -o
file.o file.cc

Unapplying the shell quoting, we get the argument list:

/usr/bin/clang++
-Irelative
-DSOMEDEF=With spaces, quotes and \-es.
-c
-o
file.o
file.cc

(Or at least we should get this argument list. Note that in the shell syntax, \
isn't special unless followed by one of $`"\ or a newline:
<http://pubs.opengroup.org/onlinepubs/007904975/utilities/xcu_chap02.html#tag_02_02_03>.
However, testing shows that the backslash actually disappears at this stage, so
Clang probably implements this incorrectly.)

The -D argument, as written, produces a macro definition analogous to the
following:

#define SOMEDEF With spaces, quotes and \-es.

Which, I guess, is legal, but insensible. I doubt this definition can ever be
used in a legal C++ program.

Now, as far as what the correct command should be... I'm assuming the intention
is to yield a definition like this:

#define SOMEDEF "With spaces, quotes and \\-es."

Then the argument needs to be:

-DSOMEDEF="With spaces, quotes and \\-es."

Applying shell quoting gives us:

"-DSOMEDEF=\"With spaces, quotes and \\\\-es.\""

And applying JSON quoting (and adding the other arguments) yields:

"/usr/bin/clang++ -Irelative \"-DSOMEDEF=\\\"With spaces, quotes and
\\\\\\\\-es.\\\"\" -c -o file.o file.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/20141106/7c68449a/attachment.html>

From bugzilla-daemon at llvm.org  Thu Nov  6 12:17:46 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 06 Nov 2014 20:17:46 +0000
Subject: [LLVMbugs] [Bug 21175] trunk lib/builtins/assembly.h: missing
 #define THUMB_FUNC for __APPLE__ __ARM_ARCH_ISA_THUMB != 2
In-Reply-To: <bug-21175-206@http.llvm.org/bugs/>
References: <bug-21175-206@http.llvm.org/bugs/>
Message-ID: <bug-21175-206-17LukAICbI@http.llvm.org/bugs/>

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

Stephan Bergmann <stephan.bergmann.secondary at googlemail.com> changed:

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

--- Comment #1 from Stephan Bergmann <stephan.bergmann.secondary at googlemail.com> ---
since obsoleted with r219182

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

From bugzilla-daemon at llvm.org  Thu Nov  6 13:11:30 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 06 Nov 2014 21:11:30 +0000
Subject: [LLVMbugs] [Bug 8787] Support/Regex is unaware of LLP64(Win64)
In-Reply-To: <bug-8787-206@http.llvm.org/bugs/>
References: <bug-8787-206@http.llvm.org/bugs/>
Message-ID: <bug-8787-206-RqaISx3sYY@http.llvm.org/bugs/>

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

NAKAMURA Takumi <geek4civic at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|FIXED                       |WONTFIX

--- Comment #4 from NAKAMURA Takumi <geek4civic at gmail.com> ---
Yes, we won't fix this 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/20141106/982f0052/attachment.html>

From bugzilla-daemon at llvm.org  Thu Nov  6 13:23:54 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 06 Nov 2014 21:23:54 +0000
Subject: [LLVMbugs] [Bug 13819] __SIZE_TYPE__ is incompatible to -pedantic
 with LLP64 Win64
In-Reply-To: <bug-13819-206@http.llvm.org/bugs/>
References: <bug-13819-206@http.llvm.org/bugs/>
Message-ID: <bug-13819-206-md8kFZmPxl@http.llvm.org/bugs/>

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

NAKAMURA Takumi <geek4civic at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |geek4civic at gmail.com
         Resolution|FIXED                       |WONTFIX

--- Comment #4 from NAKAMURA Takumi <geek4civic at gmail.com> ---
We won't consider naked __SIZE_TYPE__ is used outside of system headers and
-pedantic doesn't warn unless -Wsystem-headers even with -std=c++98.

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

From bugzilla-daemon at llvm.org  Thu Nov  6 13:24:37 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 06 Nov 2014 21:24:37 +0000
Subject: [LLVMbugs] [Bug 21506] New: libc++ should have its own classic_table
Message-ID: <bug-21506-206@http.llvm.org/bugs/>

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

            Bug ID: 21506
           Summary: libc++ should have its own classic_table
           Product: libc++
           Version: unspecified
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: All Bugs
          Assignee: danalbert at google.com
          Reporter: danalbert at google.com
                CC: eric at efcs.ca, jonathan at codesourcery.com,
                    llvmbugs at cs.uiuc.edu, mclow.lists at gmail.com
    Classification: Unclassified

We should probably be shipping our own classic_table instead of relying on one
from the underlying C library.

1. The C library isn't required to even provide such a table. IIRC, musl does
not.
2. The underlying type of the table is undefined, as are the values that map to
each mask. This is responsible for the #ifdef hell stew in [1].
3. Some C libraries (bionic, openbsd, and newlib, possibly others) use an 8-bit
mask for the table. It's still not 100% clear if this is okay, or if we need to
be able to define more than 8 values such that for any two values a and b, a &
b == 0. There are known failures in some libc++ tests [2] caused by this.
Defining our own table with a mask that is at least 16-bits wide (possibly 32)
would get us out of this mess.

I'll upload a patch soonish (once I find time) that does this unless anyone has
good reasons not to take this approach.

[1]: https://github.com/llvm-mirror/libcxx/blob/master/include/__locale#L324
[2]:
localization/locale.categories/category.ctype/locale.ctype.byname/is_1.pass.cpp
localization/locale.categories/category.ctype/locale.ctype.byname/scan_is.pass.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/20141106/b4394ac8/attachment.html>

From bugzilla-daemon at llvm.org  Thu Nov  6 14:20:31 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 06 Nov 2014 22:20:31 +0000
Subject: [LLVMbugs] [Bug 21507] New: [x86] unnecessary shuffling/moves with
 unary AVX/SSE scalar math ops
Message-ID: <bug-21507-206@http.llvm.org/bugs/>

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

            Bug ID: 21507
           Summary: [x86] unnecessary shuffling/moves with unary AVX/SSE
                    scalar math ops
           Product: new-bugs
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: spatel+llvm at rotateright.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Each of these functions should produce a single math instruction; no shuffling
or moves are needed:

$ cat unary_sse.c
#include <xmmintrin.h>

__m128 recip(__m128 x) {
        return _mm_rcp_ss(x);
}

__m128 square_root(__m128 x) {
        return _mm_sqrt_ss(x);
}

__m128 recip_square_root(__m128 x) {
        return _mm_rsqrt_ss(x);
}

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

With an AVX subtarget, we always get a bonus shuffle:

$ ./clang unary_sse.c -O1 -fomit-frame-pointer -march=btver2 -S -o -
...
_recip:                                 ## @recip
    .cfi_startproc
## BB#0:                                ## %entry
    vrcpss    %xmm0, %xmm0, %xmm1
    vblendps    $1, %xmm1, %xmm0, %xmm0 ## xmm0 = xmm1[0],xmm0[1,2,3]
    retq
    .cfi_endproc

    .globl    _square_root
    .align    4, 0x90
_square_root:                           ## @square_root
    .cfi_startproc
## BB#0:                                ## %entry
    vsqrtss    %xmm0, %xmm0, %xmm1
    vblendps    $1, %xmm1, %xmm0, %xmm0 ## xmm0 = xmm1[0],xmm0[1,2,3]
    retq
    .cfi_endproc

    .globl    _recip_square_root
    .align    4, 0x90
_recip_square_root:                     ## @recip_square_root
    .cfi_startproc
## BB#0:                                ## %entry
    vrsqrtss    %xmm0, %xmm0, %xmm1
    vblendps    $1, %xmm1, %xmm0, %xmm0 ## xmm0 = xmm1[0],xmm0[1,2,3]
    retq


With an SSE-only subtarget, we get bonus moves:

$ ./clang unary_sse.c -O1 -fomit-frame-pointer -march=core2 -S -o -
...
_recip:                                 ## @recip
    .cfi_startproc
## BB#0:                                ## %entry
    movaps    %xmm0, %xmm1
    rcpss    %xmm1, %xmm1
    movss    %xmm1, %xmm0
    retq
    .cfi_endproc

    .globl    _square_root
    .align    4, 0x90
_square_root:                           ## @square_root
    .cfi_startproc
## BB#0:                                ## %entry
    sqrtss    %xmm0, %xmm1
    movss    %xmm1, %xmm0
    retq
    .cfi_endproc

    .globl    _recip_square_root
    .align    4, 0x90
_recip_square_root:                     ## @recip_square_root
    .cfi_startproc
## BB#0:                                ## %entry
    movaps    %xmm0, %xmm1
    rsqrtss    %xmm1, %xmm1
    movss    %xmm1, %xmm0
    retq

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

$ ./clang -v
clang version 3.6.0 (221350)
Target: x86_64-apple-darwin13.4.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/20141106/248dba98/attachment.html>

From bugzilla-daemon at llvm.org  Thu Nov  6 14:43:59 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 06 Nov 2014 22:43:59 +0000
Subject: [LLVMbugs] [Bug 15242] bugpoint fails checks when compiled with
 cmake+sharedlibs+debug
In-Reply-To: <bug-15242-206@http.llvm.org/bugs/>
References: <bug-15242-206@http.llvm.org/bugs/>
Message-ID: <bug-15242-206-wkGof3d8Kn@http.llvm.org/bugs/>

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

NAKAMURA Takumi <geek4civic at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |daniel.sanders at imgtec.com
         Resolution|---                         |FIXED

--- Comment #1 from NAKAMURA Takumi <geek4civic at gmail.com> ---
Daniel Sanders fixed it in r193420.

    [bugpoint] Increase the default memory limit for subprocesses to 300MB.

    It seems that the increased size of the binaries in a shared library build
is
    causing the subprocess to exceed the 100MB memory limit. This patch
therefore
    increases the default limit to a level at which these tests pass.

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

From bugzilla-daemon at llvm.org  Thu Nov  6 15:12:03 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 06 Nov 2014 23:12:03 +0000
Subject: [LLVMbugs] [Bug 21508] New: Crash in 'Loop Vectorization'
Message-ID: <bug-21508-206@http.llvm.org/bugs/>

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

            Bug ID: 21508
           Summary: Crash in 'Loop Vectorization'
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: eocallaghan at alterapraxis.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 13301
  --> http://llvm.org/bugs/attachment.cgi?id=13301&action=edit
invocation script

edward at sundancekid:~$ sh nbHtInit-46ae8a.sh 

clang: /home/edward/llvm/include/llvm/IR/DataLayout.h:498: uint64_t
llvm::DataLayout::getTypeSizeInBits(llvm::Type *) const: Assertion
`Ty->isSized() && "Cannot getTypeInfo() on a type that is unsized!"' failed.
#0 0x292361a llvm::sys::PrintStackTrace(_IO_FILE*)
(/usr/local/bin/clang+0x292361a)
#1 0x2924cdb (/usr/local/bin/clang+0x2924cdb)
#2 0x7f1424c000a0 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0xf0a0)
#3 0x7f1423cec165 gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x32165)
#4 0x7f1423cef3e0 abort (/lib/x86_64-linux-gnu/libc.so.6+0x353e0)
#5 0x7f1423ce5311 __assert_fail (/lib/x86_64-linux-gnu/libc.so.6+0x2b311)
#6 0x96b7c8 (/usr/local/bin/clang+0x96b7c8)
#7 0x18a6a50 (/usr/local/bin/clang+0x18a6a50)
#8 0x18a12ce (/usr/local/bin/clang+0x18a12ce)
#9 0x18a00be (/usr/local/bin/clang+0x18a00be)
#10 0x28b3ed3 llvm::FPPassManager::runOnFunction(llvm::Function&)
(/usr/local/bin/clang+0x28b3ed3)
#11 0x28b414b llvm::FPPassManager::runOnModule(llvm::Module&)
(/usr/local/bin/clang+0x28b414b)
#12 0x28b46a7 llvm::legacy::PassManagerImpl::run(llvm::Module&)
(/usr/local/bin/clang+0x28b46a7)
#13 0x94c7f3 clang::EmitBackendOutput(clang::DiagnosticsEngine&,
clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions
const&, llvm::StringRef, llvm::Module*, clang::BackendAction,
llvm::raw_ostream*) (/usr/local/bin/clang+0x94c7f3)
#14 0x9414c5 (/usr/local/bin/clang+0x9414c5)
#15 0xb43b33 clang::ParseAST(clang::Sema&, bool, bool)
(/usr/local/bin/clang+0xb43b33)
#16 0x7522de clang::FrontendAction::Execute() (/usr/local/bin/clang+0x7522de)
#17 0x7254ac clang::CompilerInstance::ExecuteAction(clang::FrontendAction&)
(/usr/local/bin/clang+0x7254ac)
#18 0x707702 clang::ExecuteCompilerInvocation(clang::CompilerInstance*)
(/usr/local/bin/clang+0x707702)
#19 0x6fe537 cc1_main(llvm::ArrayRef<char const*>, char const*, void*)
(/usr/local/bin/clang+0x6fe537)
#20 0x705d15 main (/usr/local/bin/clang+0x705d15)
#21 0x7f1423cd8ead __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x1eead)
#22 0x6fe1a9 _start (/usr/local/bin/clang+0x6fe1a9)
Stack dump:
0.    Program arguments: /usr/local/bin/clang -cc1 -triple i386--linux-elf -S
-disable-free -main-file-name nbHtInit.c -mrelocation-model static
-mthread-model posix -mno-zero-initialized-in-bss -relaxed-aliasing
-fmath-errno -masm-verbose -no-integrated-as -mconstructor-aliases
-fuse-init-array -target-cpu pentium4 -target-feature -mmx -target-feature
+sse3 -target-linker-version 2.22 -momit-leaf-frame-pointer -g
-dwarf-column-info -nostdsysteminc -nobuiltininc -D __PRE_RAM__ -Os -Wall
-Wundef -Wstrict-prototypes -Wmissing-prototypes -Wwrite-strings
-Wredundant-decls -Wno-trigraphs -Wstrict-aliasing -Wshadow -fconst-strings
-fno-dwarf-directory-asm -ferror-limit 19 -fmessage-length 0 -ffreestanding
-mstackrealign -fno-builtin -fobjc-runtime=gcc -fno-common
-fdiagnostics-show-option -vectorize-loops -vectorize-slp -x c
nbHtInit-46ae8a.c 
1.    <eof> parser at end of file
2.    Per-module optimization passes
3.    Running pass 'Function Pass Manager' on module 'nbHtInit-46ae8a.c'.
4.    Running pass 'Loop Vectorization' on function '@NbInitRasParityMacro'
Aborted



edward at sundancekid:~$ uname -a
Linux sundancekid 3.16-0.bpo.2-amd64 #1 SMP Debian 3.16.3-2~bpo70+1
(2014-09-21) x86_64 GNU/Linux

edward at sundancekid:~$ clang --version
clang version 3.6.0 (trunk 220769)
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/20141106/8b717c7c/attachment.html>

From bugzilla-daemon at llvm.org  Thu Nov  6 15:20:12 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 06 Nov 2014 23:20:12 +0000
Subject: [LLVMbugs] [Bug 19474] GlobalOpt removes SectionAttr unexpecedly
In-Reply-To: <bug-19474-206@http.llvm.org/bugs/>
References: <bug-19474-206@http.llvm.org/bugs/>
Message-ID: <bug-19474-206-hpCED6yiuE@http.llvm.org/bugs/>

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

Reid Kleckner <rnk at google.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |david.majnemer at gmail.com
         Resolution|---                         |INVALID

--- Comment #2 from Reid Kleckner <rnk at google.com> ---
I discussed this with David Majnemer, and we think LLVM is working as intended.
You need to mark the data as "used" somehow to prevent its deletion or
localization.

The first test case is making the static global a local variable of main,
because LLVM knows that main is the program entry point, and it cannot be
invoked twice.

The second test case is just LLVM deleting an unreferenced global.

In both cases, adding __attribute__((used)) will resolve the issue.

GCC also has the same behavior. Consider this code:

void f() {
  static int a_var __attribute__((section("MySection"))) = 10;
}

GCC with -O2 will not emit the a_var global.

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

From bugzilla-daemon at llvm.org  Thu Nov  6 15:51:37 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 06 Nov 2014 23:51:37 +0000
Subject: [LLVMbugs] [Bug 21509] New: available externally typeinfos not
	implemented
Message-ID: <bug-21509-206@http.llvm.org/bugs/>

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

            Bug ID: 21509
           Summary: available externally typeinfos not implemented
           Product: clang
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: LLVM Codegen
          Assignee: unassignedclangbugs at nondot.org
          Reporter: compnerd at compnerd.org
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Test case:

// %clang -target i686-windows-itanium -c %s -o /dev/null

class __declspec(dllimport) base {
public:
  base() {}

  const char *value() const;
  virtual void method() const = 0;
};

class __declspec(dllimport) wrapper {
public:
  wrapper(base *);
};

class __declspec(dllimport) derived : public base {
public:
  derived() : base() {}
  virtual void method() const { (void)value(); }
};

class __declspec(dllimport) test {
public:
  test() : w(new derived()) {}
  wrapper w;
};

test t;

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

From bugzilla-daemon at llvm.org  Thu Nov  6 16:32:39 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 07 Nov 2014 00:32:39 +0000
Subject: [LLVMbugs] [Bug 21508] Crash in 'Loop Vectorization'
In-Reply-To: <bug-21508-206@http.llvm.org/bugs/>
References: <bug-21508-206@http.llvm.org/bugs/>
Message-ID: <bug-21508-206-6xbG5yOzyB@http.llvm.org/bugs/>

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

David Majnemer <david.majnemer at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
          Component|-New Bugs                   |Loop Optimizer
         Resolution|---                         |FIXED
           Assignee|unassignedclangbugs at nondot. |unassignedbugs at nondot.org
                   |org                         |
            Product|clang                       |libraries

--- Comment #5 from David Majnemer <david.majnemer at gmail.com> ---
Fixed in r221501.

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

From bugzilla-daemon at llvm.org  Thu Nov  6 16:54:47 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 07 Nov 2014 00:54:47 +0000
Subject: [LLVMbugs] [Bug 21510] New: X86-32: Clang passes fewer vectors in
 SSE registers than GCC
Message-ID: <bug-21510-206@http.llvm.org/bugs/>

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

            Bug ID: 21510
           Summary: X86-32: Clang passes fewer vectors in SSE registers
                    than GCC
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: X86
          Assignee: unassignedbugs at nondot.org
          Reporter: rnk at google.com
                CC: grosbach at apple.com, llvmbugs at cs.uiuc.edu,
                    paul_robinson at playstation.sony.com,
                    rafael.espindola at gmail.com, rjmccall at apple.com
    Classification: Unclassified

Clang's 32-bit x86 calling convention rules only pass 4 vectors in registers:

def CC_X86_32_Common : CallingConv<[
...
  // The first 4 SSE vector arguments are passed in XMM registers.
  CCIfNotVarArg<CCIfType<[v16i8, v8i16, v4i32, v2i64, v4f32, v2f64],
                CCAssignToReg<[XMM0, XMM1, XMM2, XMM3]>>>,

  // The first 4 AVX 256-bit vector arguments are passed in YMM registers.
  CCIfNotVarArg<CCIfType<[v32i8, v16i16, v8i32, v4i64, v8f32, v4f64],
                CCIfSubtarget<"hasFp256()",
                CCAssignToReg<[YMM0, YMM1, YMM2, YMM3]>>>>,
...

GCC will use all of XMM0-XMM7 to pass arguments, so Clang is ABI incompatible.

It looks like Clang was trying to match gcc's behavior with -msseregparm, which
is documented to only use the first four XMM registers for floating point
arguments. However, for true vector arguments (not float / double), gcc
currently uses up to eight registers.

So, are we broken here? If so, can we fix it, or are users relying heavily on
our x86_32 ABI stability? Can we fix the problem for YMM and ZMM registers at
least? Should we make this conditional on OS to make clang backwards compatible
with itself on Mac, BSD, etc, and compatible with the dominant system compiler
(GCC) on 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/20141107/570b558c/attachment.html>

From bugzilla-daemon at llvm.org  Thu Nov  6 17:52:04 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 07 Nov 2014 01:52:04 +0000
Subject: [LLVMbugs] [Bug 21511] New: Spurious DWARF tag for static const
	member
Message-ID: <bug-21511-206@http.llvm.org/bugs/>

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

            Bug ID: 21511
           Summary: Spurious DWARF tag for static const member
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: LLVM Codegen
          Assignee: unassignedclangbugs at nondot.org
          Reporter: paul_robinson at playstation.sony.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

With current trunk, compiling this source:

struct X {
  static const int constant = 1;
};
//const int X::constant;
int foo() {
  return X::constant;
}

The DWARF for the struct shows up as
  DW_TAG_structure_type
    DW_TAG_member
    DW_TAG_variable

where the variable has DW_AT_specification pointing to the member,
and both the member and the variable have DW_AT_const_value = 1.

Un-comment the explicit definition and the DW_TAG_variable shows up
at the top level, where you'd expect, and without DW_AT_const_value.

I *think* omitting the explicit definition is legal C++, but the 
DW_TAG_variable being a child of DW_TAG_structure_type is just weird.

Pretty sure this started happening in the past month or so, before that
I wasn't seeing DW_TAG_variable at all.

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

From bugzilla-daemon at llvm.org  Thu Nov  6 21:55:45 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 07 Nov 2014 05:55:45 +0000
Subject: [LLVMbugs] [Bug 21512] New: clang crashes at -O1 and above on
	x86_64-linux-gnu
Message-ID: <bug-21512-206@http.llvm.org/bugs/>

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

            Bug ID: 21512
           Summary: clang crashes at -O1 and above on x86_64-linux-gnu
           Product: clang
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: su at cs.ucdavis.edu
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

The current clang trunk and 3.5.0 crash when compiling the following test case
at -O1 and above in both 32-bit and 64-bit modes on x86_64-linux-gnu. 

This is a regression from clang 3.4.x. 

$ clang-trunk -v
clang version 3.6.0 (trunk 220839)
Target: x86_64-unknown-linux-gnu
Thread model: posix
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.8
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.8.1
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.4
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.4.6
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.4.7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6.4
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7.3
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8.1
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Selected multilib: .;@m64
$ 
$ clang-trunk -O0 -c small.c
$ clang-3.4.2 -O1 -c small.c
$ 
$ clang-trunk -O1 -c small.c
clang: /tmp/llvm/lib/Transforms/Scalar/SCCP.cpp:120: bool (anonymous
namespace)::LatticeVal::markConstant(llvm::Constant *): Assertion
`getLatticeValue() == forcedconstant && "Cannot move from overdefined to
constant!"' failed.
#0 0x28d6a5a llvm::sys::PrintStackTrace(_IO_FILE*)
(/usr/local/clang-trunk/bin/clang+0x28d6a5a)
#1 0x28d811b (/usr/local/clang-trunk/bin/clang+0x28d811b)
#2 0x7fd202365cb0 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0xfcb0)
#3 0x7fd2011840d5 gsignal
/build/buildd/eglibc-2.15/signal/../nptl/sysdeps/unix/sysv/linux/raise.c:64:0
#4 0x7fd20118783b abort /build/buildd/eglibc-2.15/stdlib/abort.c:93:0
#5 0x7fd20117cd9e __assert_fail_base
/build/buildd/eglibc-2.15/assert/assert.c:55:0
#6 0x7fd20117ce42 (/lib/x86_64-linux-gnu/libc.so.6+0x2ee42)
#7 0x240ff8c (/usr/local/clang-trunk/bin/clang+0x240ff8c)
#8 0x240f7e0 (/usr/local/clang-trunk/bin/clang+0x240f7e0)
#9 0x241360a (/usr/local/clang-trunk/bin/clang+0x241360a)
#10 0x240cd9b (/usr/local/clang-trunk/bin/clang+0x240cd9b)
#11 0x240b240 (/usr/local/clang-trunk/bin/clang+0x240b240)
#12 0x2866347 llvm::legacy::PassManagerImpl::run(llvm::Module&)
(/usr/local/clang-trunk/bin/clang+0x2866347)
#13 0x8f5a23 clang::EmitBackendOutput(clang::DiagnosticsEngine&,
clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions
const&, llvm::StringRef, llvm::Module*, clang::BackendAction,
llvm::raw_ostream*) (/usr/local/clang-trunk/bin/clang+0x8f5a23)
#14 0x8ea6f5 (/usr/local/clang-trunk/bin/clang+0x8ea6f5)
#15 0xaec5d3 clang::ParseAST(clang::Sema&, bool, bool)
(/usr/local/clang-trunk/bin/clang+0xaec5d3)
#16 0x6fbd9e clang::FrontendAction::Execute()
(/usr/local/clang-trunk/bin/clang+0x6fbd9e)
#17 0x6cf0fc clang::CompilerInstance::ExecuteAction(clang::FrontendAction&)
(/usr/local/clang-trunk/bin/clang+0x6cf0fc)
#18 0x6b1352 clang::ExecuteCompilerInvocation(clang::CompilerInstance*)
(/usr/local/clang-trunk/bin/clang+0x6b1352)
#19 0x6a7b27 cc1_main(llvm::ArrayRef<char const*>, char const*, void*)
(/usr/local/clang-trunk/bin/clang+0x6a7b27)
#20 0x6af9f5 main (/usr/local/clang-trunk/bin/clang+0x6af9f5)
#21 0x7fd20116f76d __libc_start_main
/build/buildd/eglibc-2.15/csu/libc-start.c:258:0
#22 0x6a7799 _start (/usr/local/clang-trunk/bin/clang+0x6a7799)
Stack dump:
0.    Program arguments: /usr/local/clang-trunk/bin/clang -cc1 -triple
x86_64-unknown-linux-gnu -emit-obj -disable-free -main-file-name small.c
-mrelocation-model static -mthread-model posix -fmath-errno -masm-verbose
-mconstructor-aliases -munwind-tables -fuse-init-array -target-cpu x86-64
-target-linker-version 2.22 -momit-leaf-frame-pointer -dwarf-column-info
-coverage-file
/data2/c-hunter-results/C/insert-bugs/REDUCED/20140106-clang-m32-m64-O1-O2-O3-build-0631/small.c
-resource-dir /usr/local/clang-trunk/bin/../lib/clang/3.6.0 -internal-isystem
/usr/local/include -internal-isystem
/usr/local/clang-trunk/bin/../lib/clang/3.6.0/include -internal-externc-isystem
/usr/include/x86_64-linux-gnu -internal-externc-isystem /include
-internal-externc-isystem /usr/include -O1 -fdebug-compilation-dir
/data2/c-hunter-results/C/insert-bugs/REDUCED/20140106-clang-m32-m64-O1-O2-O3-build-0631
-ferror-limit 19 -fmessage-length 161 -mstackrealign -fobjc-runtime=gcc
-fdiagnostics-show-option -fcolor-diagnostics -o small.o -x c small.c 
1.    <eof> parser at end of file
2.    Per-module optimization passes
3.    Running pass 'Interprocedural Sparse Conditional Constant Propagation' on
module 'small.c'.
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.6.0 (trunk 220839)
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/small-a6fb8f.c
clang: note: diagnostic msg: /tmp/small-a6fb8f.sh
clang: note: diagnostic msg: 

********************
$ 


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


long long a;
int b, c;

long long
fn1 ()
{
  int d[1];
  c = 0;
  return d[0] && b; 
}

int
fn2 ()
{
  a = fn1 ();
  return __builtin_parityll (a);
}

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

From bugzilla-daemon at llvm.org  Thu Nov  6 23:26:59 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 07 Nov 2014 07:26:59 +0000
Subject: [LLVMbugs] [Bug 21512] clang crashes at -O1 and above on
	x86_64-linux-gnu
In-Reply-To: <bug-21512-206@http.llvm.org/bugs/>
References: <bug-21512-206@http.llvm.org/bugs/>
Message-ID: <bug-21512-206-LzSWHbRscw@http.llvm.org/bugs/>

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

David Majnemer <david.majnemer at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED
           Assignee|unassignedclangbugs at nondot. |david.majnemer at gmail.com
                   |org                         |

--- Comment #2 from David Majnemer <david.majnemer at gmail.com> ---
Fixed in r221511.

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

From bugzilla-daemon at llvm.org  Thu Nov  6 23:28:55 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 07 Nov 2014 07:28:55 +0000
Subject: [LLVMbugs] [Bug 21512] clang crashes at -O1 and above on
	x86_64-linux-gnu
In-Reply-To: <bug-21512-206@http.llvm.org/bugs/>
References: <bug-21512-206@http.llvm.org/bugs/>
Message-ID: <bug-21512-206-plLXwUE7mK@http.llvm.org/bugs/>

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

David Majnemer <david.majnemer at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
          Component|-New Bugs                   |Scalar Optimizations
         Resolution|FIXED                       |---
           Assignee|david.majnemer at gmail.com    |unassignedbugs at nondot.org
            Product|clang                       |libraries

--- Comment #3 from David Majnemer <david.majnemer at gmail.com> ---
Disregard that, I've marked the wrong 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/20141107/4991bf78/attachment.html>

From bugzilla-daemon at llvm.org  Thu Nov  6 23:29:10 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 07 Nov 2014 07:29:10 +0000
Subject: [LLVMbugs] [Bug 21509] available externally typeinfos not
	implemented
In-Reply-To: <bug-21509-206@http.llvm.org/bugs/>
References: <bug-21509-206@http.llvm.org/bugs/>
Message-ID: <bug-21509-206-4RjdE6C96u@http.llvm.org/bugs/>

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

David Majnemer <david.majnemer at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED
           Assignee|unassignedclangbugs at nondot. |david.majnemer at gmail.com
                   |org                         |

--- Comment #3 from David Majnemer <david.majnemer at gmail.com> ---
Fixed in r221511.

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

From bugzilla-daemon at llvm.org  Fri Nov  7 00:11:42 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 07 Nov 2014 08:11:42 +0000
Subject: [LLVMbugs] [Bug 21513] New: llc Assertion `ResNo < NumValues &&
 "Illegal result number!"' failed
Message-ID: <bug-21513-206@http.llvm.org/bugs/>

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

            Bug ID: 21513
           Summary: llc Assertion `ResNo < NumValues && "Illegal result
                    number!"' failed
           Product: tools
           Version: 3.4
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: llc
          Assignee: unassignedbugs at nondot.org
          Reporter: heechun_lim at tmax.co.kr
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

llvm 3.4, 64-bit linux.

----------------------------------------------------
llc: /home/compiler/llvm/include/llvm/CodeGen/SelectionDAGNodes.h:610:
llvm::EVT llvm::SDNode::getValueType(unsigned int) const: Assertion `ResNo <
NumValues && "Illegal result number!"' failed.
0  libLLVMSupport.so      0x00007f6a267b07d8
llvm::sys::PrintStackTrace(_IO_FILE*) + 38
1  libLLVMSupport.so      0x00007f6a267b0a55
2  libLLVMSupport.so      0x00007f6a267b048b
3  libpthread.so.0        0x000000351d20f500
4  libc.so.6              0x000000351ca328e5 gsignal + 53
5  libc.so.6              0x000000351ca340c5 abort + 373
6  libc.so.6              0x000000351ca2ba0e
7  libc.so.6              0x000000351ca2bad0 __assert_perror_fail + 0
8  libLLVMSelectionDAG.so 0x00007f6a2a82f226
9  libLLVMSelectionDAG.so 0x00007f6a2a82f5ae
10 libLLVMSelectionDAG.so 0x00007f6a2a938a82
llvm::SelectionDAG::getStore(llvm::SDValue, llvm::SDLoc, llvm::SDValue,
llvm::SDValue, llvm::MachinePointerInfo, bool, bool, unsigned int, llvm::MDNode
const*) + 420
11 libLLVMSelectionDAG.so 0x00007f6a2a96e8d8
llvm::SelectionDAGBuilder::visitStore(llvm::StoreInst const&) + 1650
12 libLLVMSelectionDAG.so 0x00007f6a2a959cbd
llvm::SelectionDAGBuilder::visit(unsigned int, llvm::User const&) + 807
13 libLLVMSelectionDAG.so 0x00007f6a2a95990c
llvm::SelectionDAGBuilder::visit(llvm::Instruction const&) + 140
14 libLLVMSelectionDAG.so 0x00007f6a2a9b2638
llvm::SelectionDAGISel::SelectBasicBlock(llvm::ilist_iterator<llvm::Instruction
const>, llvm::ilist_iterator<llvm::Instruction const>, bool&) + 68
15 libLLVMSelectionDAG.so 0x00007f6a2a9b543e
llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) + 3124
16 libLLVMSelectionDAG.so 0x00007f6a2a9b1921
llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) + 1191
17 libLLVMCodeGen.so      0x00007f6a297566b5
llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 95
18 libLLVMCore.so         0x00007f6a27286d61
llvm::FPPassManager::runOnFunction(llvm::Function&) + 393
19 libLLVMCore.so         0x00007f6a27286f61
llvm::FPPassManager::runOnModule(llvm::Module&) + 89
20 libLLVMCore.so         0x00007f6a272872d9
21 libLLVMCore.so         0x00007f6a272878e8
llvm::legacy::PassManagerImpl::run(llvm::Module&) + 254
22 libLLVMCore.so         0x00007f6a27287aff
llvm::legacy::PassManager::run(llvm::Module&) + 39
23 llc                    0x000000000040bfb9
24 llc                    0x000000000040b09b
25 libc.so.6              0x000000351ca1ecdd __libc_start_main + 253
26 llc                    0x000000000040a9e9
Stack dump:
0.      Program arguments: llc test23.ll
1.      Running pass 'Function Pass Manager' on module 'test23.ll'.
2.      Running pass 'X86 DAG->DAG Instruction Selection' on function '@main'
Aborted (core dumped)

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

test23.ll
----------------------------------------------------
target datalayout =
"e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"

%"#TEM4_Desc" = type { i16, i16, i16, i16, [100 x %T_ENTRY_Desc] }
%T_ENTRY_Desc = type { %KEY_Desc.1, [5 x i8], [5 x [5 x i8]], [10 x
%TKY_SGRP_Desc.2], [100 x %Y_ENTRY_Desc] }
%KEY_Desc.1 = type { [2 x i8], [4 x i8] }
%TKY_SGRP_Desc.2 = type { [2 x i8], [1 x i8], [5 x [5 x i8]], [10 x i8] }
%Y_ENTRY_Desc = type { %PCODE_KEY_Desc }
%PCODE_KEY_Desc = type { [2 x i8], [2 x i8], [19 x i8] }

define i32 @main() {
entry:
  %retval = alloca i32, align 4
  %"#TEM4" = alloca %"#TEM4_Desc", align 2
  store %"#TEM4_Desc" { i16 25600, i16 25600, i16 0, i16 0, [100 x
%T_ENTRY_Desc] zeroinitializer }, %"#TEM4_Desc"* %"#TEM4", align 2
  ret i32 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/20141107/df33a4fc/attachment.html>

From bugzilla-daemon at llvm.org  Fri Nov  7 00:54:44 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 07 Nov 2014 08:54:44 +0000
Subject: [LLVMbugs] [Bug 21512] clang crashes at -O1 and above on
	x86_64-linux-gnu
In-Reply-To: <bug-21512-206@http.llvm.org/bugs/>
References: <bug-21512-206@http.llvm.org/bugs/>
Message-ID: <bug-21512-206-VzcZANE3P1@http.llvm.org/bugs/>

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

David Majnemer <david.majnemer at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|---                         |FIXED
           Assignee|unassignedbugs at nondot.org   |david.majnemer at gmail.com

--- Comment #4 from David Majnemer <david.majnemer at gmail.com> ---
Fixed in r221513.

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

From bugzilla-daemon at llvm.org  Fri Nov  7 06:34:37 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 07 Nov 2014 14:34:37 +0000
Subject: [LLVMbugs] [Bug 21514] New: compiler-rt/lib/builtins/muldi3.c:
 Infinite loop/stack overflow in __muldi3
Message-ID: <bug-21514-206@http.llvm.org/bugs/>

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

            Bug ID: 21514
           Summary: compiler-rt/lib/builtins/muldi3.c:  Infinite
                    loop/stack overflow in __muldi3
           Product: compiler-rt
           Version: unspecified
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: compiler-rt
          Assignee: unassignedbugs at nondot.org
          Reporter: troshkovdanil at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

__muldi3(di_int a, di_int b)
{
    dwords x;
    x.all = a;
    dwords y;
    y.all = b;
    dwords r;
    r.all = __muldsi3(x.s.low, y.s.low);
    r.s.high += x.s.high * y.s.low + x.s.low * y.s.high;
    return r.all;
}

Function recursively uses itself (r.s.high += x.s.high * y.s.low + x.s.low *
y.s.high).
It occurs quite legally...
Dumps (-mllvm -print-after-all):

; Function Attrs: nounwind
define i64 @__muldi3(i64 %a, i64 %b) #0 {
entry:
  %x.sroa.0.0.extract.trunc = trunc i64 %a to i32
  %x.sroa.3.0.extract.shift = lshr i64 %a, 32
  %x.sroa.3.0.extract.trunc = trunc i64 %x.sroa.3.0.extract.shift to i32
  %y.sroa.0.0.extract.trunc = trunc i64 %b to i32
  %y.sroa.3.0.extract.shift = lshr i64 %b, 32
  %y.sroa.3.0.extract.trunc = trunc i64 %y.sroa.3.0.extract.shift to i32
  %call = call fastcc i64 @__muldsi3(i32 %x.sroa.0.0.extract.trunc, i32
%y.sroa.0.0.extract.trunc)
  %r.sroa.0.0.extract.trunc = trunc i64 %call to i32
  %r.sroa.2.0.extract.shift = lshr i64 %call, 32
  %r.sroa.2.0.extract.trunc = trunc i64 %r.sroa.2.0.extract.shift to i32
  %mul = mul i32 %x.sroa.3.0.extract.trunc, %y.sroa.0.0.extract.trunc
  %mul12 = mul i32 %x.sroa.0.0.extract.trunc, %y.sroa.3.0.extract.trunc
  %add = add i32 %mul, %mul12
  %add15 = add i32 %r.sroa.2.0.extract.trunc, %add
  %r.sroa.2.0.insert.ext = zext i32 %add15 to i64
  %r.sroa.2.0.insert.shift = shl i64 %r.sroa.2.0.insert.ext, 32
  %r.sroa.0.0.insert.ext = zext i32 %r.sroa.0.0.extract.trunc to i64
  %r.sroa.0.0.insert.mask = and i64 %r.sroa.2.0.insert.shift, -4294967296
  %r.sroa.0.0.insert.insert = or i64 %r.sroa.0.0.insert.mask,
%r.sroa.0.0.insert.ext
  ret i64 %r.sroa.0.0.insert.insert
}
.....
*** IR Dump After Combine redundant instructions ***
; Function Attrs: nounwind
define i64 @__muldi3(i64 %a, i64 %b) #0 {
entry:
  %x.sroa.0.0.extract.trunc = trunc i64 %a to i32
  %x.sroa.3.0.extract.shift = lshr i64 %a, 32
  %y.sroa.0.0.extract.trunc = trunc i64 %b to i32
  %y.sroa.3.0.extract.shift = lshr i64 %b, 32
  %call = call fastcc i64 @__muldsi3(i32 %x.sroa.0.0.extract.trunc, i32
%y.sroa.0.0.extract.trunc)
  %mul = mul i64 %x.sroa.3.0.extract.shift, %b
  %mul12 = mul i64 %y.sroa.3.0.extract.shift, %a
  %add = add i64 %mul, %mul12
  %add1519 = shl i64 %add, 32
  %r.sroa.2.0.extract.shift20 = add i64 %call, %add1519
  ret i64 %r.sroa.2.0.extract.shift20
}

And (mul i64) is __muldi3...

I've looked for similar problems in the Internet and found something like this:

https://groups.google.com/forum/#!topic/llvm-dev/c-i8S5tOSYg

So it looks like the solution is to explicitly use builtins:

     r.all = __muldsi3(x.s.low, y.s.low);
-    r.s.high += x.s.high * y.s.low + x.s.low * y.s.high;
+    r.s.high += __mulsi3(x.s.high, y.s.low) + __mulsi3(x.s.low, y.s.high);
     return r.all;

But we have no __mulsi3...

Any ideas?

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

From bugzilla-daemon at llvm.org  Fri Nov  7 07:47:37 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 07 Nov 2014 15:47:37 +0000
Subject: [LLVMbugs] [Bug 21515] New: .cfi_adjust_cfa_offset not reset across
 .cfi_endproc
Message-ID: <bug-21515-206@http.llvm.org/bugs/>

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

            Bug ID: 21515
           Summary: .cfi_adjust_cfa_offset not reset across .cfi_endproc
           Product: new-bugs
           Version: 3.4
          Hardware: PC
                OS: FreeBSD
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: rth at twiddle.net
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

$ cat z.s
    .cfi_startproc
    nop
    .cfi_adjust_cfa_offset 4
    .cfi_endproc

    .cfi_startproc
    nop
    .cfi_adjust_cfa_offset 4
    .cfi_endproc
$ cc -c z.s
$ readelf -wf z.o 
The section .eh_frame contains:

00000000 00000014 00000000 CIE
  Version:               1
  Augmentation:          "zR"
  Code alignment factor: 1
  Data alignment factor: -4
  Return address column: 8
  Augmentation data:     1b

  DW_CFA_def_cfa: r4 ofs 4
  DW_CFA_offset: r8 at cfa-4
  DW_CFA_nop
  DW_CFA_nop

00000018 00000010 0000001c FDE cie=00000000 pc=00000000..00000001
  DW_CFA_advance_loc: 1 to 00000001
  DW_CFA_def_cfa_offset: 8

0000002c 00000010 00000030 FDE cie=00000000 pc=00000001..00000002
  DW_CFA_advance_loc: 1 to 00000002
  DW_CFA_def_cfa_offset: 12

The 12 on the last line should be 8.

FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512
Target: i386-unknown-freebsd10.1
Thread model: posix
Selected GCC installation:

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

From bugzilla-daemon at llvm.org  Fri Nov  7 17:43:38 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 08 Nov 2014 01:43:38 +0000
Subject: [LLVMbugs] [Bug 21500] Incorrect assembly in .macro
In-Reply-To: <bug-21500-206@http.llvm.org/bugs/>
References: <bug-21500-206@http.llvm.org/bugs/>
Message-ID: <bug-21500-206-DzB0Xe6icu@http.llvm.org/bugs/>

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

Dimitry Andric <dimitry at andric.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |dimitry at andric.com
         Resolution|---                         |FIXED

--- Comment #1 from Dimitry Andric <dimitry at andric.com> ---
This is fixed in trunk r201784, which is not in clang 3.4.1.  Since the fix is
fairly simple, I will import this revision into FreeBSD.

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

From bugzilla-daemon at llvm.org  Fri Nov  7 23:51:08 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 08 Nov 2014 07:51:08 +0000
Subject: [LLVMbugs] [Bug 21516] New: clang crashes in adjustRemoval with
	four byte input
Message-ID: <bug-21516-206@http.llvm.org/bugs/>

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

            Bug ID: 21516
           Summary: clang crashes in adjustRemoval with four byte input
           Product: clang
           Version: unspecified
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
          Assignee: unassignedclangbugs at nondot.org
          Reporter: david.majnemer at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 13304
  --> http://llvm.org/bugs/attachment.cgi?id=13304&action=edit
crashing input

run clang with attached file:
~/llvm/Debug+Asserts/bin/clang -cc1 -x c++ t.cpp

#8 0x11461a1 llvm::StringRef::operator[](unsigned long) const
~/llvm/src/include/llvm/ADT/StringRef.h:192:0 
#9 0x38bc79c adjustRemoval(clang::SourceManager const&, clang::LangOptions
const&, clang::SourceLocation, clang::edit::FileOffset, unsigned int&,
llvm::StringRef&) ~/llvm/src/tools/clang/lib/Edit/EditedSource.cpp:301:0
#10 0x38bc977 applyRewrite(clang::edit::EditsReceiver&, llvm::StringRef,
clang::edit::FileOffset, unsigned int, clang::SourceManager const&,
clang::LangOptions const&)
~/llvm/src/tools/clang/lib/Edit/EditedSource.cpp:322:0
#11 0x38bcd94
clang::edit::EditedSource::applyRewrites(clang::edit::EditsReceiver&)
~/llvm/src/tools/clang/lib/Edit/EditedSource.cpp:370:0  
#12 0x2519c4d mergeFixits(llvm::ArrayRef<clang::FixItHint>,
clang::SourceManager const&, clang::LangOptions const&,
llvm::SmallVectorImpl<clang::FixItHint>&)
~/llvm/src/tools/clang/lib/Frontend/DiagnosticRenderer.cpp:119:0
#13 0x2519e8f 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*>)
~/llvm/src/tools/clang/lib/Frontend/DiagnosticRenderer.cpp:145:0
#14 0x244dc8c
clang::TextDiagnosticPrinter::HandleDiagnostic(clang::DiagnosticsEngine::Level,
clang::Diagnostic const&)
~/llvm/src/tools/clang/lib/Frontend/TextDiagnosticPrinter.cpp:160:0 
#15 0x2318d37 clang::DiagnosticIDs::EmitDiag(clang::DiagnosticsEngine&,
clang::DiagnosticIDs::Level) const
~/llvm/src/tools/clang/lib/Basic/DiagnosticIDs.cpp:687:0
#16 0x2318cb9 clang::DiagnosticIDs::ProcessDiag(clang::DiagnosticsEngine&)
const ~/llvm/src/tools/clang/lib/Basic/DiagnosticIDs.cpp:679:0
#17 0x230bebb clang::DiagnosticsEngine::ProcessDiag()
~/llvm/src/tools/clang/include/clang/Basic/Diagnostic.h:795:0
#18 0x230e052 clang::DiagnosticsEngine::EmitCurrentDiagnostic(bool)
~/llvm/src/tools/clang/lib/Basic/Diagnostic.cpp:371:0
#19 0x11470b8 clang::DiagnosticBuilder::Emit()
~/llvm/src/tools/clang/include/clang/Basic/Diagnostic.h:930:0
#20 0x11470e6 clang::DiagnosticBuilder::~DiagnosticBuilder()
~/llvm/src/tools/clang/include/clang/Basic/Diagnostic.h:957:0
#21 0x3ecf406 clang::Lexer::LexUnicode(clang::Token&, unsigned int, char
const*) ~/llvm/src/tools/clang/lib/Lex/Lexer.cpp:2847:0
#22 0x3ed1306 clang::Lexer::LexTokenInternal(clang::Token&, bool)
~/llvm/src/tools/clang/lib/Lex/Lexer.cpp:3597:0
#23 0x3ecf588 clang::Lexer::Lex(clang::Token&)
~/llvm/src/tools/clang/lib/Lex/Lexer.cpp:2891:0
#24 0x3f20d11 clang::Preprocessor::Lex(clang::Token&)
~/llvm/src/tools/clang/lib/Lex/Preprocessor.cpp:691:0
#25 0x3eeddc4 clang::Preprocessor::PeekAhead(unsigned int)
~/llvm/src/tools/clang/lib/Lex/PPCaching.cpp:89:0 
#26 0x311a3b2 clang::Preprocessor::LookAhead(unsigned int)
~/llvm/src/tools/clang/include/clang/Lex/Preprocessor.h:875:0
#27 0x311c601 clang::Parser::NextToken()
~/llvm/src/tools/clang/include/clang/Parse/Parser.h:530:0
#28 0x3164208
clang::Parser::ParseOptionalCXXScopeSpecifier(clang::CXXScopeSpec&,
clang::OpaquePtr<clang::QualType>, bool, bool*, bool, clang::IdentifierInfo**)
~/llvm/src/tools/clang/lib/Parse/ParseExprCXX.cpp:418:0
#29 0x3123bd8 clang::Parser::TryAnnotateCXXScopeToken(bool)
~/llvm/src/tools/clang/lib/Parse/Parser.cpp:1690:0 
#30 0x3135f0c clang::Parser::ParseDeclarationSpecifiers(clang::DeclSpec&,
clang::Parser::ParsedTemplateInfo const&, clang::AccessSpecifier,
clang::Parser::DeclSpecContext, clang::Parser::LateParsedAttrList*)
~/llvm/src/tools/clang/lib/Parse/ParseDecl.cpp:2782:0
#31 0x31207db
clang::Parser::ParseDeclOrFunctionDefInternal(clang::Parser::ParsedAttributesWithRange&,
clang::ParsingDeclSpec&, clang::AccessSpecifier)
~/llvm/src/tools/clang/lib/Parse/Parser.cpp:841:0 
#32 0x3120c81
clang::Parser::ParseDeclarationOrFunctionDefinition(clang::Parser::ParsedAttributesWithRange&,
clang::ParsingDeclSpec*, clang::AccessSpecifier)
~/llvm/src/tools/clang/lib/Parse/Parser.cpp:910:0
#33 0x3120468
clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&,
clang::ParsingDeclSpec*) ~/llvm/src/tools/clang/lib/Parse/Parser.cpp:768:0 
#34 0x311fabb
clang::Parser::ParseTopLevelDecl(clang::OpaquePtr<clang::DeclGroupRef>&)
~/llvm/src/tools/clang/lib/Parse/Parser.cpp:569:0
#35 0x3119097 clang::ParseAST(clang::Sema&, bool, bool)
~/llvm/src/tools/clang/lib/Parse/ParseAST.cpp:135:0
#36 0x2414248 clang::ASTFrontendAction::ExecuteAction()
~/llvm/src/tools/clang/lib/Frontend/FrontendAction.cpp:528:0
#37 0x2413d23 clang::FrontendAction::Execute()
~/llvm/src/tools/clang/lib/Frontend/FrontendAction.cpp:432:0
#38 0x23dcaae clang::CompilerInstance::ExecuteAction(clang::FrontendAction&)
~/llvm/src/tools/clang/lib/Frontend/CompilerInstance.cpp:802:0
#39 0x2524023 clang::ExecuteCompilerInvocation(clang::CompilerInstance*)
~/llvm/src/tools/clang/lib/FrontendTool/ExecuteCompilerInvocation.cpp:222:0
#40 0x1150990 cc1_main(llvm::ArrayRef<char const*>, char const*, void*)
~/llvm/src/tools/clang/tools/driver/cc1_main.cpp:110:0
#41 0x1148dd4 ExecuteCC1Tool(llvm::ArrayRef<char const*>, llvm::StringRef)
~/llvm/src/tools/clang/tools/driver/driver.cpp:371:0
#42 0x11493b4 main ~/llvm/src/tools/clang/tools/driver/driver.cpp:417: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/20141108/356f9389/attachment.html>

From bugzilla-daemon at llvm.org  Sat Nov  8 08:51:02 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 08 Nov 2014 16:51:02 +0000
Subject: [LLVMbugs] [Bug 21517] New: crash on ill formed code
Message-ID: <bug-21517-206@http.llvm.org/bugs/>

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

            Bug ID: 21517
           Summary: crash on ill formed code
           Product: clang
           Version: unspecified
          Hardware: PC
                OS: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++11
          Assignee: unassignedclangbugs at nondot.org
          Reporter: Axel.Naumann at cern.ch
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 13305
  --> http://llvm.org/bugs/attachment.cgi?id=13305&action=edit
reproducer / PP sources

I can reproduce this with

clang version 3.6.0 (git at github.com:llvm-mirror/clang.git
5e7180b8436993360d97b8d749f75cbdcc3967c4) (git at github.com:llvm-mirror/llvm.git
6128ca928de2c07590c8867566adfc161844e72a)
Target: x86_64-apple-darwin13.4.0
Thread model: posix

and

Apple LLVM version 6.0 (clang-600.0.54) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin13.4.0
Thread model: posix


running


$ clang++ -std=c++1y -fsyntax-only capture.cxx
capture.cxx:12:27: error: attempt to use a deleted function
capture<S> gen() { return S(); }
                          ^
capture.cxx:6:3: note: '~capture' has been explicitly marked deleted here
  ~capture() = delete;
  ^
0  clang                    0x000000010ee4a1fb void
std::__1::seed_seq::generate<unsigned int*>(unsigned int*, unsigned int*) +
10539
1  clang                    0x000000010ee4a96b void
std::__1::seed_seq::generate<unsigned int*>(unsigned int*, unsigned int*) +
12443
2  libsystem_platform.dylib 0x00007fff9003c5aa _sigtramp + 26
3  libsystem_platform.dylib 000000000000000000 _sigtramp + 1878801008
4  clang                    0x000000010dc2b9c5 void
std::__1::vector<clang::FixItHint, std::__1::allocator<clang::FixItHint>
>::__push_back_slow_path<clang::FixItHint>(clang::FixItHint&&) + 62629
5  clang                    0x000000010dc2567e void
std::__1::vector<clang::FixItHint, std::__1::allocator<clang::FixItHint>
>::__push_back_slow_path<clang::FixItHint>(clang::FixItHint&&) + 37214
6  clang                    0x000000010dc2fb87 void
std::__1::vector<clang::FixItHint, std::__1::allocator<clang::FixItHint>
>::__push_back_slow_path<clang::FixItHint>(clang::FixItHint&&) + 79463
7  clang                    0x000000010dccb383
llvm::SmallVectorTemplateBase<clang::OverloadCandidate, false>::grow(unsigned
long) + 85507
8  clang                    0x000000010dccd1c5
llvm::SmallVectorTemplateBase<clang::OverloadCandidate, false>::grow(unsigned
long) + 93253
9  clang                    0x000000010dccccfe
llvm::SmallVectorTemplateBase<clang::OverloadCandidate, false>::grow(unsigned
long) + 92030
10 clang                    0x000000010d98256a
llvm::SmallVectorImpl<clang::LambdaIntroducer::LambdaCapture>::operator=(llvm::SmallVectorImpl<clang::LambdaIntroducer::LambdaCapture>&&)
+ 136218
11 clang                    0x000000010d97de7f
llvm::SmallVectorImpl<clang::LambdaIntroducer::LambdaCapture>::operator=(llvm::SmallVectorImpl<clang::LambdaIntroducer::LambdaCapture>&&)
+ 118063
12 clang                    0x000000010d97d0d9
llvm::SmallVectorImpl<clang::LambdaIntroducer::LambdaCapture>::operator=(llvm::SmallVectorImpl<clang::LambdaIntroducer::LambdaCapture>&&)
+ 114569
13 clang                    0x000000010d983b6f
llvm::SmallVectorImpl<clang::LambdaIntroducer::LambdaCapture>::operator=(llvm::SmallVectorImpl<clang::LambdaIntroducer::LambdaCapture>&&)
+ 141855
14 clang                    0x000000010d98445e
llvm::SmallVectorImpl<clang::LambdaIntroducer::LambdaCapture>::operator=(llvm::SmallVectorImpl<clang::LambdaIntroducer::LambdaCapture>&&)
+ 144142
15 clang                    0x000000010d997de5
llvm::SmallVectorTemplateBase<clang::ParsedTemplateArgument,
false>::grow(unsigned long) + 37989
16 clang                    0x000000010d9254a5 void
std::__1::vector<clang::CodeGen::LValue,
std::__1::allocator<clang::CodeGen::LValue>
>::__push_back_slow_path<clang::CodeGen::LValue const&>(clang::CodeGen::LValue
const&&&) + 65237
17 clang                    0x000000010d99737c
llvm::SmallVectorTemplateBase<clang::ParsedTemplateArgument,
false>::grow(unsigned long) + 35324
18 clang                    0x000000010d996dc9
llvm::SmallVectorTemplateBase<clang::ParsedTemplateArgument,
false>::grow(unsigned long) + 33865
19 clang                    0x000000010d996296
llvm::SmallVectorTemplateBase<clang::ParsedTemplateArgument,
false>::grow(unsigned long) + 30998
20 clang                    0x000000010d995603
llvm::SmallVectorTemplateBase<clang::ParsedTemplateArgument,
false>::grow(unsigned long) + 27779
21 clang                    0x000000010d915986 void
std::__1::vector<clang::CodeGen::LValue,
std::__1::allocator<clang::CodeGen::LValue>
>::__push_back_slow_path<clang::CodeGen::LValue const&>(clang::CodeGen::LValue
const&&&) + 950
22 clang                    0x000000010d5c644e
std::__1::__tree<std::__1::__value_type<clang::edit::FileOffset,
clang::edit::EditedSource::FileEdit>,
std::__1::__map_value_compare<clang::edit::FileOffset,
std::__1::__value_type<clang::edit::FileOffset,
clang::edit::EditedSource::FileEdit>, std::__1::less<clang::edit::FileOffset>,
true>, std::__1::allocator<std::__1::__value_type<clang::edit::FileOffset,
clang::edit::EditedSource::FileEdit> >
>::destroy(std::__1::__tree_node<std::__1::__value_type<clang::edit::FileOffset,
clang::edit::EditedSource::FileEdit>, void*>*) + 5694
23 clang                    0x000000010d598023 void
std::__1::vector<clang::FrontendInputFile,
std::__1::allocator<clang::FrontendInputFile>
>::__push_back_slow_path<clang::FrontendInputFile
const&>(clang::FrontendInputFile const&&&) + 20755
24 clang                    0x000000010d55bed6 void
std::__1::__tree_balance_after_insert<std::__1::__tree_node_base<void*>*>(std::__1::__tree_node_base<void*>*,
std::__1::__tree_node_base<void*>*) + 4678
25 clang                    0x000000010d553413
26 clang                    0x000000010d557d60 void
std::__1::vector<llvm::SourceMgr::SrcBuffer,
std::__1::allocator<llvm::SourceMgr::SrcBuffer>
>::__push_back_slow_path<llvm::SourceMgr::SrcBuffer>(llvm::SourceMgr::SrcBuffer&&)
+ 2048
27 libdyld.dylib            0x00007fff92caa5fd start + 1
28 libdyld.dylib            0x0000000000000030 start + 1832213044
Stack dump:
0.    Program arguments: /Users/axel/build/llvm/opt-inst/bin/clang -cc1 -triple
x86_64-apple-macosx10.9.0 -fsyntax-only -disable-free -disable-llvm-verifier
-main-file-name capture.cxx -mrelocation-model pic -pic-level 2 -mthread-model
posix -mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu core2
-target-linker-version 241.9 -dwarf-column-info -resource-dir
/Users/axel/build/llvm/opt-inst/bin/../lib/clang/3.6.0 -stdlib=libc++
-std=c++1y -fdeprecated-macro -fdebug-compilation-dir
/Users/axel/Dropbox/CxxISO -ferror-limit 19 -fmessage-length 127
-stack-protector 1 -mstackrealign -fblocks -fobjc-runtime=macosx-10.9.0
-fencode-extended-block-signature -fcxx-exceptions -fexceptions
-fmax-type-align=16 -fdiagnostics-show-option -fcolor-diagnostics -x c++
capture.cxx
1.    capture.cxx:12:30: current parser token ';'
2.    capture.cxx:12:18: parsing function body 'gen'
3.    capture.cxx:12:18: 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.6.0 (git at github.com:llvm-mirror/clang.git
5e7180b8436993360d97b8d749f75cbdcc3967c4) (git at github.com:llvm-mirror/llvm.git
6128ca928de2c07590c8867566adfc161844e72a)
Target: x86_64-apple-darwin13.4.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/b1/xp46rm512wv7mbrx82vpf3m00000gn/T/capture-836176.cpp
clang: note: diagnostic msg:
/var/folders/b1/xp46rm512wv7mbrx82vpf3m00000gn/T/capture-836176.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/20141108/2838265b/attachment.html>

From bugzilla-daemon at llvm.org  Mon Nov 10 07:32:38 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 10 Nov 2014 15:32:38 +0000
Subject: [LLVMbugs] [Bug 21518] New: addvsi3 & subvsi3 don't trap when they
	should
Message-ID: <bug-21518-206@http.llvm.org/bugs/>

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

            Bug ID: 21518
           Summary: addvsi3 & subvsi3 don't trap when they should
           Product: compiler-rt
           Version: unspecified
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: compiler-rt
          Assignee: unassignedbugs at nondot.org
          Reporter: fxcoudert at gcc.gnu.org
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 13307
  --> http://llvm.org/bugs/attachment.cgi?id=13307&action=edit
Patch fixing the issue

The code in {add,sub}v.i3 routines does not trap when it should, because it
performs the actual add/subtract operation in signed arithmetic, rather than
unsigned. I found this when GCC incorrectly uses the symbols from Mac OS X
Yosemite's libcompiler_rt.dylib, and those fail to abort when they should.
(Original GCC bug report is here, explaining some of the context:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62018).

The attached patch fixes it. I hope it can 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/20141110/fcdbfde9/attachment.html>

From bugzilla-daemon at llvm.org  Mon Nov 10 11:09:48 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 10 Nov 2014 19:09:48 +0000
Subject: [LLVMbugs] [Bug 21490] LTO treats ObjC @selector's as compile time
 constants, which they are not
In-Reply-To: <bug-21490-206@http.llvm.org/bugs/>
References: <bug-21490-206@http.llvm.org/bugs/>
Message-ID: <bug-21490-206-XOewRW6F3G@http.llvm.org/bugs/>

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

Kevin Frei <freik at fb.com> changed:

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

--- Comment #3 from Kevin Frei <freik at fb.com> ---
Change #221620 checked in by rafael.espindola at gmail.com for freik...

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

From bugzilla-daemon at llvm.org  Mon Nov 10 12:22:44 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 10 Nov 2014 20:22:44 +0000
Subject: [LLVMbugs] [Bug 21520] New: [windows] gmock's ElementsAreArray()
 with a string literal is miscompiled somehow for x64
Message-ID: <bug-21520-206@http.llvm.org/bugs/>

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

            Bug ID: 21520
           Summary: [windows] gmock's ElementsAreArray() with a string
                    literal is miscompiled somehow for x64
           Product: clang
           Version: unspecified
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
          Assignee: unassignedclangbugs at nondot.org
          Reporter: nicolasweber at gmx.de
                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/20141110/05e80398/attachment.html>

From bugzilla-daemon at llvm.org  Mon Nov 10 12:49:46 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 10 Nov 2014 20:49:46 +0000
Subject: [LLVMbugs] [Bug 20494] wrong code at -O2 and -O3 on
 x86_64-linux-gnu (only in 64-bit mode and affecting all clang versions)
 (scalar division)
In-Reply-To: <bug-20494-206@http.llvm.org/bugs/>
References: <bug-20494-206@http.llvm.org/bugs/>
Message-ID: <bug-20494-206-2VZVuyjoPZ@http.llvm.org/bugs/>

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

Michael Kuperstein <michael.m.kuperstein at intel.com> changed:

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

--- Comment #10 from Michael Kuperstein <michael.m.kuperstein at intel.com> ---
Fixed in r221626.

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

From bugzilla-daemon at llvm.org  Mon Nov 10 13:14:07 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 10 Nov 2014 21:14:07 +0000
Subject: [LLVMbugs] [Bug 21521] New:
 lib/Target/PowerPC/PPCGenInstrInfo.inc:4347:0: error: unterminated #ifdef
Message-ID: <bug-21521-206@http.llvm.org/bugs/>

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

            Bug ID: 21521
           Summary: lib/Target/PowerPC/PPCGenInstrInfo.inc:4347:0: error:
                    unterminated #ifdef
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: octoploid at yandex.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

On ppc64 I get:
In file included from
/home/trippels/llvm-project/llvm/lib/Target/PowerPC/MCTargetDesc/PPCMCTargetDesc.h:70:0,
                 from
/home/trippels/llvm-project/llvm/lib/Target/PowerPC/PPC.h:18,
                 from
/home/trippels/llvm-project/llvm/lib/Target/PowerPC/TargetInfo/PowerPCTargetInfo.cpp:10:
/home/trippels/llvm_build_dir/lib/Target/PowerPC/PPCGenInstrInfo.inc:4347:0:
error: unterminated #ifdef
 #ifdef GET_INSTRMAP_INFO
 ^


from /home/trippels/llvm_build_dir/lib/Target/PowerPC/PPCGenInstrInfo.inc:

4704 } // End llvm namespace#endif // GET_INSTRMAP_INFO

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

From bugzilla-daemon at llvm.org  Mon Nov 10 13:31:53 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 10 Nov 2014 21:31:53 +0000
Subject: [LLVMbugs] [Bug 21521]
 lib/Target/PowerPC/PPCGenInstrInfo.inc:4347:0: error: unterminated #ifdef
In-Reply-To: <bug-21521-206@http.llvm.org/bugs/>
References: <bug-21521-206@http.llvm.org/bugs/>
Message-ID: <bug-21521-206-w0ki7DjRdM@http.llvm.org/bugs/>

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

octoploid <octoploid at yandex.com> changed:

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

--- Comment #1 from octoploid <octoploid at yandex.com> ---
Hmm, it only happens when I build with gcc-5.0.
So probably llvm-tblgen gets miscompiled.

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

From bugzilla-daemon at llvm.org  Mon Nov 10 13:35:32 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 10 Nov 2014 21:35:32 +0000
Subject: [LLVMbugs] [Bug 21316] Address sanitizer dylib not found with clang
 3.5.0 binary for OS X
In-Reply-To: <bug-21316-206@http.llvm.org/bugs/>
References: <bug-21316-206@http.llvm.org/bugs/>
Message-ID: <bug-21316-206-iGX0nbuClW@http.llvm.org/bugs/>

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

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/20141110/cc17b771/attachment.html>

From bugzilla-daemon at llvm.org  Mon Nov 10 15:36:59 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 10 Nov 2014 23:36:59 +0000
Subject: [LLVMbugs] [Bug 6561] ARM JIT CodeEmitter VMOVDneon "Unhandled
 instruction encoding format!"
In-Reply-To: <bug-6561-206@http.llvm.org/bugs/>
References: <bug-6561-206@http.llvm.org/bugs/>
Message-ID: <bug-6561-206-rSs6QxJg0x@http.llvm.org/bugs/>

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

Lang Hames <lhames at gmail.com> changed:

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

--- Comment #5 from Lang Hames <lhames at gmail.com> ---
The legacy JIT has been removed from LLVM trunk, so this bug is no longer
valid.

NEON instructions are expected to work correctly in MCJIT (the new JIT). If
they do not, please file a new report.

Closing due to removal of the old JIT.

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

From bugzilla-daemon at llvm.org  Mon Nov 10 15:54:32 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 10 Nov 2014 23:54:32 +0000
Subject: [LLVMbugs] [Bug 21523] New: MCJIT debugging support.
Message-ID: <bug-21523-206@http.llvm.org/bugs/>

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

            Bug ID: 21523
           Summary: MCJIT debugging support.
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Generic Execution Engine Support
          Assignee: unassignedbugs at nondot.org
          Reporter: lhames at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

I'm creating this bug to track work on debugging support for MCJIT.

As discussed at the dev meeting, the best way forward is probably to develop a
minimal object format that the JIT can construct to hold the DWARF, plus any
symbol table info needed by the debugger.

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

From bugzilla-daemon at llvm.org  Mon Nov 10 17:05:33 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 11 Nov 2014 01:05:33 +0000
Subject: [LLVMbugs] [Bug 20494] wrong code at -O2 and -O3 on
 x86_64-linux-gnu (only in 64-bit mode and affecting all clang versions)
 (scalar division)
In-Reply-To: <bug-20494-206@http.llvm.org/bugs/>
References: <bug-20494-206@http.llvm.org/bugs/>
Message-ID: <bug-20494-206-GxKNLfLIg0@http.llvm.org/bugs/>

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

David Majnemer <david.majnemer at gmail.com> changed:

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

--- Comment #11 from David Majnemer <david.majnemer at gmail.com> ---
r221626 was reverted in r221629.

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

From bugzilla-daemon at llvm.org  Mon Nov 10 19:46:06 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 11 Nov 2014 03:46:06 +0000
Subject: [LLVMbugs] [Bug 21524] New: diagnostics missing from -Wc++-compat
Message-ID: <bug-21524-206@http.llvm.org/bugs/>

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

            Bug ID: 21524
           Summary: diagnostics missing from -Wc++-compat
           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

>From http://lists.cs.uiuc.edu/pipermail/cfe-dev/2014-November/039875.html

clang doesn't print warning for following test-case:

compiled with: clang -fsyntax-only -Wc++-compat

int new;
struct A
{
  struct B
  {
    int x;
  }bs;
  int y;
};
struct B b;


gcc -fsyntax-only -Wc++-compat prints following warnings (gcc-4.9.1 ubuntu):

t.c:1:5: warning: identifier ‘new’ conflicts with C++ keyword [-Wc++-compat]
 int new;
      ^
t.c:13:8: warning: struct defined in struct or union is not visible in
C++ [-Wc++-compat]
 struct B b;
           ^
t.c:5:10: note: struct defined here
   struct 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/20141111/a25c9c14/attachment.html>

From bugzilla-daemon at llvm.org  Mon Nov 10 21:27:56 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 11 Nov 2014 05:27:56 +0000
Subject: [LLVMbugs] [Bug 21345] Test failure when compiling with PowerPC
	support
In-Reply-To: <bug-21345-206@http.llvm.org/bugs/>
References: <bug-21345-206@http.llvm.org/bugs/>
Message-ID: <bug-21345-206-cdfLfaWGRO@http.llvm.org/bugs/>

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

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

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

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

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

From bugzilla-daemon at llvm.org  Mon Nov 10 23:20:11 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 11 Nov 2014 07:20:11 +0000
Subject: [LLVMbugs] [Bug 21525] New: Segmentation fault: Using template
 specialization and default function attributes
Message-ID: <bug-21525-206@http.llvm.org/bugs/>

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

            Bug ID: 21525
           Summary: Segmentation fault: Using template specialization and
                    default function attributes
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
          Assignee: unassignedclangbugs at nondot.org
          Reporter: matthias.scholz at gmail.com
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 13310
  --> http://llvm.org/bugs/attachment.cgi?id=13310&action=edit
Source

Clang crashes with the following snippet:

#include <iostream>

template <typename type, typename unit, unit Default>
class Base
{
public:
   template <typename settype>
   inline void set( settype v1 = 0, unit v2 = Default  )
   { std::cout << __PRETTY_FUNCTION__ << std::endl; }
};


enum eUnit
{
   Default = 10
};

typedef Base< int, eUnit, Default > BType;

template<>
template<typename settype>
inline void BType::set( settype v1, eUnit v2 )
{ std::cout << __PRETTY_FUNCTION__ << std::endl; }


int main( void )
{
   BType v;

   // Working
   v.set( 1, Default );
   // Seg fault
   v.set( 1 );

   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/20141111/d91c9917/attachment.html>

From bugzilla-daemon at llvm.org  Tue Nov 11 00:16:58 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 11 Nov 2014 08:16:58 +0000
Subject: [LLVMbugs] [Bug 20494] wrong code at -O2 and -O3 on
 x86_64-linux-gnu (only in 64-bit mode and affecting all clang versions)
 (scalar division)
In-Reply-To: <bug-20494-206@http.llvm.org/bugs/>
References: <bug-20494-206@http.llvm.org/bugs/>
Message-ID: <bug-20494-206-tjIc5Y7dyT@http.llvm.org/bugs/>

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

Michael Kuperstein <michael.m.kuperstein at intel.com> changed:

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

--- Comment #12 from Michael Kuperstein <michael.m.kuperstein at intel.com> ---
Fix recommitted as r221672, should stick this time, sorry for the noise.

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

From bugzilla-daemon at llvm.org  Tue Nov 11 00:46:28 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 11 Nov 2014 08:46:28 +0000
Subject: [LLVMbugs] [Bug 21520] [windows] gmock's ElementsAreArray() with a
 string literal is miscompiled somehow for x64
In-Reply-To: <bug-21520-206@http.llvm.org/bugs/>
References: <bug-21520-206@http.llvm.org/bugs/>
Message-ID: <bug-21520-206-KJIlA98wyq@http.llvm.org/bugs/>

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

David Majnemer <david.majnemer at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED
           Assignee|david.majnemer at gmail.com    |unassignedclangbugs at nondot.
                   |                            |org

--- Comment #11 from David Majnemer <david.majnemer at gmail.com> ---
Fixed in r221678.

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

From bugzilla-daemon at llvm.org  Tue Nov 11 02:50:52 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 11 Nov 2014 10:50:52 +0000
Subject: [LLVMbugs] [Bug 21526] New: findInstantiationOf(): Assertion
 `isa<LabelDecl>(D) && "declaration not instantiated in this scope"
Message-ID: <bug-21526-206@http.llvm.org/bugs/>

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

            Bug ID: 21526
           Summary: findInstantiationOf(): Assertion `isa<LabelDecl>(D) &&
                    "declaration not instantiated in this scope"
           Product: clang
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
          Assignee: unassignedclangbugs at nondot.org
          Reporter: david.abdurachmanov at gmail.com
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 13313
  --> http://llvm.org/bugs/attachment.cgi?id=13313&action=edit
Full output

There are a number of such bug reports, majority of them are old and marked
RESOLVED and FIXED.

Attaching the output (incl. stack trace, assert details and more), files
generated by Clang (incl. pre-processed source).

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

From bugzilla-daemon at llvm.org  Tue Nov 11 04:29:08 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 11 Nov 2014 12:29:08 +0000
Subject: [LLVMbugs] [Bug 21527] New: CGPassManager::RefreshCallGraph():
 Assertion `CallSites.empty() && "Dangling pointers found in call sites
 map"' failed.
Message-ID: <bug-21527-206@http.llvm.org/bugs/>

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

            Bug ID: 21527
           Summary: CGPassManager::RefreshCallGraph(): Assertion
                    `CallSites.empty() && "Dangling pointers found in call
                    sites map"' failed.
           Product: clang
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
          Assignee: unassignedclangbugs at nondot.org
          Reporter: david.abdurachmanov at gmail.com
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified

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

Attaching run script, pre-processed source and output.

Commits used:
LLVM  : e1e1392e13ef3f5e97fbdd15ca8d60d63f69a862
        https://llvm.org/svn/llvm-project/llvm/trunk at 221579
Clang : 9443d047e89e716928fd87d277fca673afc2ec43
        https://llvm.org/svn/llvm-project/cfe/trunk at 221576

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

From bugzilla-daemon at llvm.org  Tue Nov 11 05:06:37 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 11 Nov 2014 13:06:37 +0000
Subject: [LLVMbugs] [Bug 21527] CGPassManager::RefreshCallGraph(): Assertion
 `CallSites.empty() && "Dangling pointers found in call sites map"' failed.
In-Reply-To: <bug-21527-206@http.llvm.org/bugs/>
References: <bug-21527-206@http.llvm.org/bugs/>
Message-ID: <bug-21527-206-N1N0Fr62g5@http.llvm.org/bugs/>

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

jonathan.sauer at gmx.de changed:

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

--- Comment #3 from jonathan.sauer at gmx.de ---
This looks like a duplicate of bug 21403.

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

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

From bugzilla-daemon at llvm.org  Tue Nov 11 05:37:21 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 11 Nov 2014 13:37:21 +0000
Subject: [LLVMbugs] [Bug 20528] [mips] Tracking ticket for big-endian
	N32/N64 ABI issues
In-Reply-To: <bug-20528-206@http.llvm.org/bugs/>
References: <bug-20528-206@http.llvm.org/bugs/>
Message-ID: <bug-20528-206-YageQMSHH2@http.llvm.org/bugs/>

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

Bug 20528 depends on bug 19612, which changed state.

Bug 19612 Summary: bad codegen on MIPS va_arg
http://llvm.org/bugs/show_bug.cgi?id=19612

           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/20141111/60a54d9a/attachment.html>

From bugzilla-daemon at llvm.org  Tue Nov 11 05:37:18 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 11 Nov 2014 13:37:18 +0000
Subject: [LLVMbugs] [Bug 19612] bad codegen on MIPS va_arg
In-Reply-To: <bug-19612-206@http.llvm.org/bugs/>
References: <bug-19612-206@http.llvm.org/bugs/>
Message-ID: <bug-19612-206-M2hJyIrL00@http.llvm.org/bugs/>

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

Daniel Sanders <daniel.sanders at imgtec.com> changed:

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

--- Comment #7 from Daniel Sanders <daniel.sanders at imgtec.com> ---
I believe this is fixed from r221604 onwards. Let me know if you still have
problems.

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

From bugzilla-daemon at llvm.org  Tue Nov 11 05:38:10 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 11 Nov 2014 13:38:10 +0000
Subject: [LLVMbugs] [Bug 20528] [mips] Tracking ticket for big-endian
	N32/N64 ABI issues
In-Reply-To: <bug-20528-206@http.llvm.org/bugs/>
References: <bug-20528-206@http.llvm.org/bugs/>
Message-ID: <bug-20528-206-JJjQuDUv5E@http.llvm.org/bugs/>

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

Bug 20528 depends on bug 20286, which changed state.

Bug 20286 Summary: struct members not left-justified in function arguments on MIPS64
http://llvm.org/bugs/show_bug.cgi?id=20286

           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/20141111/38c1e69e/attachment.html>

From bugzilla-daemon at llvm.org  Tue Nov 11 05:38:09 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 11 Nov 2014 13:38:09 +0000
Subject: [LLVMbugs] [Bug 20286] struct members not left-justified in
 function arguments on MIPS64
In-Reply-To: <bug-20286-206@http.llvm.org/bugs/>
References: <bug-20286-206@http.llvm.org/bugs/>
Message-ID: <bug-20286-206-4ENGRcSySL@http.llvm.org/bugs/>

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

Daniel Sanders <daniel.sanders at imgtec.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |daniel.sanders at imgtec.com
         Resolution|---                         |FIXED

--- Comment #3 from Daniel Sanders <daniel.sanders at imgtec.com> ---
I believe this is fixed from r221604 onwards. Let me know if you still have
problems.

I've noticed a similar issue in big-endian O32 but that's should be a separate
ticket.

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

From bugzilla-daemon at llvm.org  Tue Nov 11 05:38:29 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 11 Nov 2014 13:38:29 +0000
Subject: [LLVMbugs] [Bug 20528] [mips] Tracking ticket for big-endian
	N32/N64 ABI issues
In-Reply-To: <bug-20528-206@http.llvm.org/bugs/>
References: <bug-20528-206@http.llvm.org/bugs/>
Message-ID: <bug-20528-206-dNL6pPSGpY@http.llvm.org/bugs/>

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

Bug 20528 depends on bug 20302, which changed state.

Bug 20302 Summary: small arguments stored on stack in high words on MIPS64
http://llvm.org/bugs/show_bug.cgi?id=20302

           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/20141111/c6171788/attachment.html>

From bugzilla-daemon at llvm.org  Tue Nov 11 05:38:28 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 11 Nov 2014 13:38:28 +0000
Subject: [LLVMbugs] [Bug 20302] small arguments stored on stack in high
	words on MIPS64
In-Reply-To: <bug-20302-206@http.llvm.org/bugs/>
References: <bug-20302-206@http.llvm.org/bugs/>
Message-ID: <bug-20302-206-SlcheGCaCK@http.llvm.org/bugs/>

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

Daniel Sanders <daniel.sanders at imgtec.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |daniel.sanders at imgtec.com
         Resolution|---                         |FIXED

--- Comment #2 from Daniel Sanders <daniel.sanders at imgtec.com> ---
I believe this is fixed from r221604 onwards. Let me know if you still have
problems.

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

From bugzilla-daemon at llvm.org  Tue Nov 11 05:38:43 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 11 Nov 2014 13:38:43 +0000
Subject: [LLVMbugs] [Bug 21262] Clang passes arguments incorrectly for
 64-bit big-endian MIPS
In-Reply-To: <bug-21262-206@http.llvm.org/bugs/>
References: <bug-21262-206@http.llvm.org/bugs/>
Message-ID: <bug-21262-206-DJt6V2GDiA@http.llvm.org/bugs/>

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

Daniel Sanders <daniel.sanders at imgtec.com> changed:

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

--- Comment #6 from Daniel Sanders <daniel.sanders at imgtec.com> ---
I believe this is fixed from r221604 onwards. Let me know if you still have
problems.

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

From bugzilla-daemon at llvm.org  Tue Nov 11 05:38:45 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 11 Nov 2014 13:38:45 +0000
Subject: [LLVMbugs] [Bug 20528] [mips] Tracking ticket for big-endian
	N32/N64 ABI issues
In-Reply-To: <bug-20528-206@http.llvm.org/bugs/>
References: <bug-20528-206@http.llvm.org/bugs/>
Message-ID: <bug-20528-206-bp81iy9IgU@http.llvm.org/bugs/>

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

Bug 20528 depends on bug 21262, which changed state.

Bug 21262 Summary: Clang passes arguments incorrectly for 64-bit big-endian MIPS
http://llvm.org/bugs/show_bug.cgi?id=21262

           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/20141111/b548b6db/attachment.html>

From bugzilla-daemon at llvm.org  Tue Nov 11 05:39:10 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 11 Nov 2014 13:39:10 +0000
Subject: [LLVMbugs] [Bug 20528] [mips] Tracking ticket for big-endian
	N32/N64 ABI issues
In-Reply-To: <bug-20528-206@http.llvm.org/bugs/>
References: <bug-20528-206@http.llvm.org/bugs/>
Message-ID: <bug-20528-206-i3MqT5UFuh@http.llvm.org/bugs/>

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

Daniel Sanders <daniel.sanders at imgtec.com> changed:

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

--- Comment #5 from Daniel Sanders <daniel.sanders at imgtec.com> ---
I believe this is fixed from r221604 onwards. Let me know if you still have
problems.

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

From bugzilla-daemon at llvm.org  Tue Nov 11 06:55:39 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 11 Nov 2014 14:55:39 +0000
Subject: [LLVMbugs] [Bug 21528] New: [Windows] Stack traces don't contain
 namespaces in function names since r220544
Message-ID: <bug-21528-206@http.llvm.org/bugs/>

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

            Bug ID: 21528
           Summary: [Windows] Stack traces don't contain namespaces in
                    function names since r220544
           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

Stack traces contain mangled function names since r220544

Example:
--------------------------
#include <malloc.h>

namespace foo {
template<int x>
void bar(char *p) {
  *p = x;
}
}

int main() {
  char *buffer = (char*)malloc(42);
  free(buffer);
  foo::bar<42>(buffer);
}
--------------------------
$ clang-cl.exe -fsanitize=address -Zi test.cpp -Fezz.exe && zz.exe 2>&1 | head

Expected:
...
    #0 0x11d12d6 in foo::bar<42> ...
    #1 0x11d1153 in main ...

Actual:
...
    #0 0x3612d6 in bar<42> ...
    #1 0x361153 in 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/20141111/6446353d/attachment.html>

From bugzilla-daemon at llvm.org  Tue Nov 11 06:58:40 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 11 Nov 2014 14:58:40 +0000
Subject: [LLVMbugs] [Bug 21529] New: Inefficient encoding when using direct
 object emission
Message-ID: <bug-21529-206@http.llvm.org/bugs/>

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

            Bug ID: 21529
           Summary: Inefficient encoding when using direct object emission
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: MC
          Assignee: rafael.espindola at gmail.com
          Reporter: rafael.espindola at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

given 

define void @f() {
  %foo = alloca i8, align 32
  ret void
}

we produce

48 81 e4 e0 ff ff ff                             andq    $-32, %rsp

when using direct object emission from llc

and

48 83 e4 e0                                      andq    $-32, %rsp

if printing assembly and reading it back in with llvm-mc

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

From bugzilla-daemon at llvm.org  Tue Nov 11 09:28:56 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 11 Nov 2014 17:28:56 +0000
Subject: [LLVMbugs] [Bug 21530] New: Detect integer demotions in UBSan
Message-ID: <bug-21530-206@http.llvm.org/bugs/>

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

            Bug ID: 21530
           Summary: Detect integer demotions in UBSan
           Product: clang
           Version: trunk
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: y.gribov at samsung.com
                CC: kcc at google.com, llvmbugs at cs.uiuc.edu,
                    vonosmas at gmail.com, y.gribov at samsung.com
    Classification: Unclassified

UBSan currently does not check integer demotions i.e. casts from wider integer
type to a smaller one. This is indeed not undefined behavior but rather
implementation defined. Still, loosing higher bits when downcasting ints to
chars is a constant source of bugs and it would be nice to have an optional
check for it (like we already have for float-cast-overflow).

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

From bugzilla-daemon at llvm.org  Tue Nov 11 09:46:34 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 11 Nov 2014 17:46:34 +0000
Subject: [LLVMbugs] [Bug 21531] New: crash on parameter pack in switch case
Message-ID: <bug-21531-206@http.llvm.org/bugs/>

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

            Bug ID: 21531
           Summary: crash on parameter pack in switch case
           Product: clang
           Version: 3.5
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++11
          Assignee: unassignedclangbugs at nondot.org
          Reporter: rhainin1 at binghamton.edu
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 13318
  --> http://llvm.org/bugs/attachment.cgi?id=13318&action=edit
cpp post-processed

When using a parameter pack in a switch case (invalid code).  clang crashes. 
The code to produce:

template <int... Is>
int f(int i) {
    switch (i) {
        case Is:
            return 0;
    }
}

int main() {
    f<1,2,3>(1);
}


The backtrace:
expandcase.cpp:4:14: error: expression contains unexpanded parameter pack 'Is'
        case Is:
             ^~
0  clang           0x00000000026f1cd2 llvm::sys::PrintStackTrace(_IO_FILE*) +
34
1  clang           0x00000000026f1574
2  libpthread.so.0 0x00007fb841892030
3  clang           0x0000000000fadf5f
clang::Sema::ActOnFinishSwitchStmt(clang::SourceLocation, clang::Stmt*,
clang::Stmt*) + 847
4  clang           0x0000000000d26b98
clang::Parser::ParseSwitchStatement(clang::SourceLocation*) + 536
5  clang           0x0000000000d2452b
clang::Parser::ParseStatementOrDeclarationAfterAttributes(llvm::SmallVector<clang::Stmt*,
32u>&, bool, clang::SourceLocation*, clang::Parser::ParsedAttributesWithRange&)
+ 2075
6  clang           0x0000000000d24a98
clang::Parser::ParseStatementOrDeclaration(llvm::SmallVector<clang::Stmt*,
32u>&, bool, clang::SourceLocation*) + 120
7  clang           0x0000000000d27a66
clang::Parser::ParseCompoundStatementBody(bool) + 1846
8  clang           0x0000000000d29b46
clang::Parser::ParseFunctionStatementBody(clang::Decl*,
clang::Parser::ParseScope&) + 198
9  clang           0x0000000000cc3abd
clang::Parser::ParseFunctionDefinition(clang::ParsingDeclarator&,
clang::Parser::ParsedTemplateInfo const&, clang::Parser::LateParsedAttrList*) +
1277
10 clang           0x0000000000d34da7
clang::Parser::ParseSingleDeclarationAfterTemplate(unsigned int,
clang::Parser::ParsedTemplateInfo const&, clang::ParsingDeclRAIIObject&,
clang::SourceLocation&, clang::AccessSpecifier, clang::AttributeList*) + 3831
11 clang           0x0000000000d35a53
clang::Parser::ParseTemplateDeclarationOrSpecialization(unsigned int,
clang::SourceLocation&, clang::AccessSpecifier, clang::AttributeList*) + 963
12 clang           0x0000000000d35cfa
clang::Parser::ParseDeclarationStartingWithTemplate(unsigned int,
clang::SourceLocation&, clang::AccessSpecifier, clang::AttributeList*) + 138
13 clang           0x0000000000cdbf14
clang::Parser::ParseDeclaration(llvm::SmallVector<clang::Stmt*, 32u>&, unsigned
int, clang::SourceLocation&, clang::Parser::ParsedAttributesWithRange&) + 612
14 clang           0x0000000000cc4cb1
clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&,
clang::ParsingDeclSpec*) + 337
15 clang           0x0000000000cc5390
clang::Parser::ParseTopLevelDecl(clang::OpaquePtr<clang::DeclGroupRef>&) + 448
16 clang           0x0000000000cbcac0 clang::ParseAST(clang::Sema&, bool, bool)
+ 400
17 clang           0x0000000000b3102b clang::CodeGenAction::ExecuteAction() +
59
18 clang           0x00000000009a2d26 clang::FrontendAction::Execute() + 118
19 clang           0x000000000097db70
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 320
20 clang           0x0000000000966b63
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 2115
21 clang           0x0000000000960118 cc1_main(char const**, char const**, char
const*, void*) + 1384
22 clang           0x000000000093a962 main + 1362
23 libc.so.6       0x00007fb840746ead __libc_start_main + 253
24 clang           0x000000000095f4ed
Stack dump:
0.    Program arguments:
/import/linux/home/kchiu/packages/linux-x86_64/llvm-3.5.0/bin/clang -cc1
-triple x86_64-unknown-linux-gnu -emit-obj -mrelax-all -disable-free
-main-file-name expandcase.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.24
-dwarf-column-info -resource-dir
/import/linux/home/kchiu/packages/linux-x86_64/llvm-3.5.0/bin/../lib/clang/3.5.0
-internal-isystem
/home/kchiu/packages/linux-x86_64/gcc-4.9.1/lib/gcc/x86_64-unknown-linux-gnu/4.9.1/../../../../include/c++/4.9.1
-internal-isystem
/home/kchiu/packages/linux-x86_64/gcc-4.9.1/lib/gcc/x86_64-unknown-linux-gnu/4.9.1/../../../../include/c++/4.9.1/x86_64-unknown-linux-gnu
-internal-isystem
/home/kchiu/packages/linux-x86_64/gcc-4.9.1/lib/gcc/x86_64-unknown-linux-gnu/4.9.1/../../../../include/c++/4.9.1/backward
-internal-isystem /usr/local/include -internal-isystem
/import/linux/home/kchiu/packages/linux-x86_64/llvm-3.5.0/bin/../lib/clang/3.5.0/include
-internal-externc-isystem /usr/include/x86_64-linux-gnu
-internal-externc-isystem /include -internal-externc-isystem /usr/include
-std=c++11 -fdeprecated-macro -fdebug-compilation-dir
/import/linux/home/rhainin1 -ferror-limit 19 -fmessage-length 0 -mstackrealign
-fobjc-runtime=gcc -fcxx-exceptions -fexceptions -fdiagnostics-show-option -o
/tmp/expandcase-03aba5.o -x c++ expandcase.cpp 
1.    expandcase.cpp:7:1: current parser token '}'
2.    expandcase.cpp:2:14: parsing function body 'f'
3.    expandcase.cpp:2:14: in compound statement ('{}')
clang: error: unable to execute command: Segmentation fault
clang: error: clang frontend command failed due to signal (use -v to see
invocation)
clang version 3.5.0 (tags/RELEASE_350/final)
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/expandcase-365a30.cpp
clang: note: diagnostic msg: /tmp/expandcase-365a30.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/20141111/e9d658f4/attachment.html>

From bugzilla-daemon at llvm.org  Tue Nov 11 11:16:04 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 11 Nov 2014 19:16:04 +0000
Subject: [LLVMbugs] [Bug 1269] Add support for "non-call" exceptions,
	eliminate invoke
In-Reply-To: <bug-1269-206@http.llvm.org/bugs/>
References: <bug-1269-206@http.llvm.org/bugs/>
Message-ID: <bug-1269-206-EPGeCClZsv@http.llvm.org/bugs/>

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

Reid Kleckner <rnk at google.com> changed:

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

--- Comment #35 from Reid Kleckner <rnk at google.com> ---
I think we can safely say that we're not going to do 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/20141111/9f2488d6/attachment.html>

From bugzilla-daemon at llvm.org  Tue Nov 11 11:23:50 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 11 Nov 2014 19:23:50 +0000
Subject: [LLVMbugs] [Bug 14175] gperftools compilation fails
In-Reply-To: <bug-14175-206@http.llvm.org/bugs/>
References: <bug-14175-206@http.llvm.org/bugs/>
Message-ID: <bug-14175-206-9CuUhmctAA@http.llvm.org/bugs/>

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

Marshall Clow (home) <mclow.lists at gmail.com> changed:

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

--- Comment #7 from Marshall Clow (home) <mclow.lists at gmail.com> ---
Fixed in revision 221697.

Thanks for your patience.

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

From bugzilla-daemon at llvm.org  Tue Nov 11 11:47:44 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 11 Nov 2014 19:47:44 +0000
Subject: [LLVMbugs] [Bug 21529] Inefficient encoding when using direct
	object emission
In-Reply-To: <bug-21529-206@http.llvm.org/bugs/>
References: <bug-21529-206@http.llvm.org/bugs/>
Message-ID: <bug-21529-206-48S4G9eTpQ@http.llvm.org/bugs/>

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

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/20141111/2e8cc029/attachment.html>

From bugzilla-daemon at llvm.org  Tue Nov 11 11:49:33 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 11 Nov 2014 19:49:33 +0000
Subject: [LLVMbugs] [Bug 20644] Too strong optimization with -O2 generates
	invalid code
In-Reply-To: <bug-20644-206@http.llvm.org/bugs/>
References: <bug-20644-206@http.llvm.org/bugs/>
Message-ID: <bug-20644-206-OlS50AED6Q@http.llvm.org/bugs/>

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

Hans Wennborg <hans at chromium.org> changed:

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

--- Comment #4 from Hans Wennborg <hans at chromium.org> ---
Looks like Issue 20494 is the same problem, and was recently fixed.

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

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

From bugzilla-daemon at llvm.org  Tue Nov 11 12:41:55 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 11 Nov 2014 20:41:55 +0000
Subject: [LLVMbugs] [Bug 21532] New: Separate Metadata from the Value
	hierarchy
Message-ID: <bug-21532-206@http.llvm.org/bugs/>

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

            Bug ID: 21532
           Summary: Separate Metadata from the Value hierarchy
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Core LLVM classes
          Assignee: unassignedbugs at nondot.org
          Reporter: dexonsmith at apple.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

As detailed in the recent RFC [1], we should have two distinct class
hierarchies: Metadata and Value.

[1]: http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-November/078668.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/20141111/ec8aced8/attachment.html>

From bugzilla-daemon at llvm.org  Tue Nov 11 12:45:34 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 11 Nov 2014 20:45:34 +0000
Subject: [LLVMbugs] [Bug 21533] New: Replace debug info intrinsics with
 metadata attachments
Message-ID: <bug-21533-206@http.llvm.org/bugs/>

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

            Bug ID: 21533
           Summary: Replace debug info intrinsics with metadata
                    attachments
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: DebugInfo
          Assignee: unassignedbugs at nondot.org
          Reporter: dexonsmith at apple.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

As a step toward separating metadata from the value hierarchy (bug 21532), we
need to replace debug info intrinsics with metadata attachments.

A prerequisite includes new IR support for metadata attachments to function
arguments (`llvm::Argument`).

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

From bugzilla-daemon at llvm.org  Tue Nov 11 12:46:06 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 11 Nov 2014 20:46:06 +0000
Subject: [LLVMbugs] [Bug 16091] Crash in codegen with deducted return type
 in overloaded template member function with -gdwarf-2
In-Reply-To: <bug-16091-206@http.llvm.org/bugs/>
References: <bug-16091-206@http.llvm.org/bugs/>
Message-ID: <bug-16091-206-QaPnZQnJBR@http.llvm.org/bugs/>

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

David Blaikie <dblaikie at gmail.com> changed:

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

--- Comment #9 from David Blaikie <dblaikie at gmail.com> ---
Fixed enough not to break builds in r221704.

This representation works well with GDB and I imagine any other debugger/debug
info client (since they must already be able to handle member function
templates, implicit special members, etc)... 

Maybe some day someone might want to implement the DWARF5 format, once major
debuggers can cope with it correctly.

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

From bugzilla-daemon at llvm.org  Tue Nov 11 13:03:16 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 11 Nov 2014 21:03:16 +0000
Subject: [LLVMbugs] [Bug 21534] New: chromium build error on FreeBSD
Message-ID: <bug-21534-206@http.llvm.org/bugs/>

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

            Bug ID: 21534
           Summary: chromium build error on FreeBSD
           Product: clang
           Version: 3.3
          Hardware: PC
                OS: FreeBSD
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: nospam at morphium.org
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

uname -a

FreeBSD rstark.munix.us 10.0-RELEASE-p7 FreeBSD 10.0-RELEASE-p7 #1 r268805: Thu
Jul 17 15:41:46 CDT 2014     root at rstark.munix.us:/usr/obj/usr/src/sys/GENERIC 
amd64

clang -v

FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610
Target: x86_64-unknown-freebsd10.0
Thread model: posix

Overview: A fresh install of chromium fails, output said to file a bug.



[root at rstark /]# portmaster /usr/ports/www/chromium

===>>> Port directory: /usr/ports/www/chromium

===>>> Launching 'make checksum' for www/chromium in background
===>>> Gathering dependency list for www/chromium from ports
===>>> Initial dependency check complete for www/chromium


===>>> Starting build for www/chromium <<<===

===>>> All dependencies are up to date

===>  Cleaning for chromium-38.0.2125.111

To build Chromium, you should have around 1 GB of memory
and a fair amount of free diskspace (~ 3.7GB).

Make sure you have Python build with the SEM option ON
(default in python27-2.7.8 since r361735)
===>  License BSD3CLAUSE LGPL21 MPL accepted by the user
===>  Found saved configuration for chromium-32.0.1700.77
===>   chromium-38.0.2125.111 depends on file: /usr/local/sbin/pkg - found
===> Fetching all distfiles required by chromium-38.0.2125.111 for building
===>  Extracting for chromium-38.0.2125.111
=> SHA256 Checksum OK for chromium-38.0.2125.111.tar.xz.
===>  Patching for chromium-38.0.2125.111
===>  Applying extra patch /usr/ports/www/chromium/files/extra-patch-clang
===>  Applying FreeBSD patches for chromium-38.0.2125.111
===>   chromium-38.0.2125.111 depends on file: /usr/local/bin/gperf - found
===>   chromium-38.0.2125.111 depends on executable: bash - found
===>   chromium-38.0.2125.111 depends on executable: yasm - found
===>   chromium-38.0.2125.111 depends on executable: flock - found
===>   chromium-38.0.2125.111 depends on file:
/usr/local/include/linux/videodev2.h - found
===>   chromium-38.0.2125.111 depends on file: /usr/local/share/usbids/usb.ids
- found
===>   chromium-38.0.2125.111 depends on executable: bison - found
===>   chromium-38.0.2125.111 depends on executable: update-desktop-database -
found
===>   chromium-38.0.2125.111 depends on executable: pkgconf - found
===>   chromium-38.0.2125.111 depends on executable: ninja - found
===>   chromium-38.0.2125.111 depends on file: /usr/local/bin/python2.7 - found
===>   chromium-38.0.2125.111 depends on executable: python2 - found
===>   chromium-38.0.2125.111 depends on file:
/usr/local/libdata/pkgconfig/scrnsaverproto.pc - found
===>   chromium-38.0.2125.111 depends on file:
/usr/local/libdata/pkgconfig/x11.pc - found
===>   chromium-38.0.2125.111 depends on file:
/usr/local/libdata/pkgconfig/xproto.pc - found
===>   chromium-38.0.2125.111 depends on file:
/usr/local/libdata/pkgconfig/xscrnsaver.pc - found
===>   chromium-38.0.2125.111 depends on file:
/usr/local/libdata/pkgconfig/xtst.pc - found
===>   chromium-38.0.2125.111 depends on executable: gtk-update-icon-cache -
found
===>   chromium-38.0.2125.111 depends on file: /usr/local/bin/intltool-extract
- found
===>   chromium-38.0.2125.111 depends on file: /usr/local/bin/perl5.16.3 -
found
===>   chromium-38.0.2125.111 depends on shared library: libcairo.so - found
(/usr/local/lib/libcairo.so.2.11200.16)
===>   chromium-38.0.2125.111 depends on shared library: libdbus-1.so - found
(/usr/local/lib/libdbus-1.so.3.8.7)
===>   chromium-38.0.2125.111 depends on shared library: libdbus-glib-1.so -
found (/usr/local/lib/libdbus-glib-1.so.2.2.2)
===>   chromium-38.0.2125.111 depends on shared library: libasound.so - found
(/usr/local/lib/libasound.so.2.0.0)
===>   chromium-38.0.2125.111 depends on shared library: libfreetype.so - found
(/usr/local/lib/libfreetype.so.6.11.2)
===>   chromium-38.0.2125.111 depends on shared library: libnss3.so - found
(/usr/local/lib/nss/libnss3.so.1)
===>   chromium-38.0.2125.111 depends on shared library: libFLAC.so - found
(/usr/local/lib/libFLAC.so.11)
===>   chromium-38.0.2125.111 depends on shared library: libgnome-keyring.so -
found (/usr/local/lib/libgnome-keyring.so.0.1.1)
===>   chromium-38.0.2125.111 depends on shared library: libharfbuzz.so - found
(/usr/local/lib/libharfbuzz.so.0.928.0)
===>   chromium-38.0.2125.111 depends on shared library: libcups.so - found
(/usr/local/lib/libcups.so.2)
===>   chromium-38.0.2125.111 depends on shared library: libevent.so - found
(/usr/local/lib/libevent-2.0.so.5.1.9)
===>   chromium-38.0.2125.111 depends on shared library: libexif.so - found
(/usr/local/lib/libexif.so.12.3.3)
===>   chromium-38.0.2125.111 depends on shared library: libgcrypt.so - found
(/usr/local/lib/libgcrypt.so.20.0.1)
===>   chromium-38.0.2125.111 depends on shared library: libpci.so - found
(/usr/local/lib/libpci.so.3)
===>   chromium-38.0.2125.111 depends on shared library: libdrm.so - found
(/usr/local/lib/libdrm.so.2.4.0)
===>   chromium-38.0.2125.111 depends on shared library: libicuuc.so - found
(/usr/local/lib/libicuuc.so.53.1)
===>   chromium-38.0.2125.111 depends on shared library: libjpeg.so - found
(/usr/local/lib/libjpeg.so.11)
===>   chromium-38.0.2125.111 depends on shared library: libjsoncpp.so - found
(/usr/local/lib/libjsoncpp.so.0)
===>   chromium-38.0.2125.111 depends on shared library: libnspr4.so - found
(/usr/local/lib/libnspr4.so.1)
===>   chromium-38.0.2125.111 depends on shared library: libprotobuf.so - found
(/usr/local/lib/libprotobuf.so.9.0.0)
===>   chromium-38.0.2125.111 depends on shared library: libpng.so - found
(/usr/local/lib/libpng15.so.15)
===>   chromium-38.0.2125.111 depends on shared library: libre2.so - found
(/usr/local/lib/libre2.so.0.0.0)
===>   chromium-38.0.2125.111 depends on shared library: libsnappy.so - found
(/usr/local/lib/libsnappy.so.1.2.0)
===>   chromium-38.0.2125.111 depends on shared library: libspeechd.so - found
(/usr/local/lib/libspeechd.so.2.4.0)
===>   chromium-38.0.2125.111 depends on shared library: libspeex.so - found
(/usr/local/lib/libspeex.so.1.5.0)
===>   chromium-38.0.2125.111 depends on shared library: libxml2.so - found
(/usr/local/lib/libxml2.so.2.9.2)
===>   chromium-38.0.2125.111 depends on shared library: libwebp.so - found
(/usr/local/lib/libwebp.so.5.0.1)
===>   chromium-38.0.2125.111 depends on shared library: libatk-1.0.so - found
(/usr/local/lib/libatk-1.0.so.0.20809.1)
===>   chromium-38.0.2125.111 depends on shared library: libdconf.so - found
(/usr/local/lib/libdconf.so.1)
===>   chromium-38.0.2125.111 depends on shared library: libgconf-2.so - found
(/usr/local/lib/libgconf-2.so.4.1.5)
===>   chromium-38.0.2125.111 depends on shared library: libgdk_pixbuf-2.0.so -
found (/usr/local/lib/libgdk_pixbuf-2.0.so.0.2800.2)
===>   chromium-38.0.2125.111 depends on shared library: libglib-2.0.so - found
(/usr/local/lib/libglib-2.0.so.0.3600.3)
===>   chromium-38.0.2125.111 depends on shared library: libpcre.so - found
(/usr/local/lib/libpcre.so.3)
===>   chromium-38.0.2125.111 depends on shared library: libgtk-x11-2.0.so -
found (/usr/local/lib/libgtk-x11-2.0.so.0.2400.22)
===>   chromium-38.0.2125.111 depends on shared library: libIDL-2.so - found
(/usr/local/lib/libIDL-2.so.0.0.0)
===>   chromium-38.0.2125.111 depends on shared library: libxml2.so - found
(/usr/local/lib/libxml2.so.2.9.2)
===>   chromium-38.0.2125.111 depends on shared library: libxslt.so - found
(/usr/local/lib/libxslt.so.2)
===>   chromium-38.0.2125.111 depends on shared library: libORBit-2.so - found
(/usr/local/lib/libORBit-2.so.0.1.0)
===>   chromium-38.0.2125.111 depends on shared library: libpango-1.0.so -
found (/usr/local/lib/libpango-1.0.so.0.3400.1)
===>  Configuring for chromium-38.0.2125.111
===>   FreeBSD 10 autotools fix applied to
/usr/ports/www/chromium/work/chromium-38.0.2125.111/sdch/open-vcdiff/configure
===>   FreeBSD 10 autotools fix applied to
/usr/ports/www/chromium/work/chromium-38.0.2125.111/sdch/open-vcdiff/aclocal.m4
===>   FreeBSD 10 autotools fix applied to
/usr/ports/www/chromium/work/chromium-38.0.2125.111/sdch/open-vcdiff/m4/libtool.m4
===>   FreeBSD 10 autotools fix applied to
/usr/ports/www/chromium/work/chromium-38.0.2125.111/third_party/sqlite/src/configure
===>   FreeBSD 10 autotools fix applied to
/usr/ports/www/chromium/work/chromium-38.0.2125.111/third_party/sqlite/src/aclocal.m4
===>   FreeBSD 10 autotools fix applied to
/usr/ports/www/chromium/work/chromium-38.0.2125.111/third_party/freetype2/src/configure
===>   FreeBSD 10 autotools fix applied to
/usr/ports/www/chromium/work/chromium-38.0.2125.111/third_party/libvpx/source/libvpx/configure
===>   FreeBSD 10 autotools fix applied to
/usr/ports/www/chromium/work/chromium-38.0.2125.111/third_party/xdg-utils/configure
===>   FreeBSD 10 autotools fix applied to
/usr/ports/www/chromium/work/chromium-38.0.2125.111/third_party/opus/src/m4/libtool.m4
===>   FreeBSD 10 autotools fix applied to
/usr/ports/www/chromium/work/chromium-38.0.2125.111/third_party/opus/src/aclocal.m4
===>   FreeBSD 10 autotools fix applied to
/usr/ports/www/chromium/work/chromium-38.0.2125.111/third_party/opus/src/configure
===>   FreeBSD 10 autotools fix applied to
/usr/ports/www/chromium/work/chromium-38.0.2125.111/third_party/libxml/src/aclocal.m4
===>   FreeBSD 10 autotools fix applied to
/usr/ports/www/chromium/work/chromium-38.0.2125.111/third_party/libxml/src/acinclude.m4
===>   FreeBSD 10 autotools fix applied to
/usr/ports/www/chromium/work/chromium-38.0.2125.111/third_party/libxml/src/configure
===>   FreeBSD 10 autotools fix applied to
/usr/ports/www/chromium/work/chromium-38.0.2125.111/third_party/libevent/configure
===>   FreeBSD 10 autotools fix applied to
/usr/ports/www/chromium/work/chromium-38.0.2125.111/third_party/libevent/aclocal.m4
===>   FreeBSD 10 autotools fix applied to
/usr/ports/www/chromium/work/chromium-38.0.2125.111/third_party/ffmpeg/configure
===>   FreeBSD 10 autotools fix applied to
/usr/ports/www/chromium/work/chromium-38.0.2125.111/third_party/talloc/configure
===>   FreeBSD 10 autotools fix applied to
/usr/ports/www/chromium/work/chromium-38.0.2125.111/third_party/talloc/libreplace/aclocal.m4
===>   FreeBSD 10 autotools fix applied to
/usr/ports/www/chromium/work/chromium-38.0.2125.111/third_party/talloc/aclocal.m4
===>   FreeBSD 10 autotools fix applied to
/usr/ports/www/chromium/work/chromium-38.0.2125.111/third_party/mesa/src/acinclude.m4
===>   FreeBSD 10 autotools fix applied to
/usr/ports/www/chromium/work/chromium-38.0.2125.111/third_party/yasm/source/patched-yasm/config/config.rpath
===>   FreeBSD 10 autotools fix applied to
/usr/ports/www/chromium/work/chromium-38.0.2125.111/third_party/yasm/source/patched-yasm/configure
===>   FreeBSD 10 autotools fix applied to
/usr/ports/www/chromium/work/chromium-38.0.2125.111/third_party/yasm/source/patched-yasm/aclocal.m4
===>   FreeBSD 10 autotools fix applied to
/usr/ports/www/chromium/work/chromium-38.0.2125.111/third_party/tcmalloc/vendor/m4/libtool.m4
===>   FreeBSD 10 autotools fix applied to
/usr/ports/www/chromium/work/chromium-38.0.2125.111/third_party/tcmalloc/vendor/aclocal.m4
===>   FreeBSD 10 autotools fix applied to
/usr/ports/www/chromium/work/chromium-38.0.2125.111/third_party/tcmalloc/vendor/configure
===>   FreeBSD 10 autotools fix applied to
/usr/ports/www/chromium/work/chromium-38.0.2125.111/third_party/icu/source/aclocal.m4
===>   FreeBSD 10 autotools fix applied to
/usr/ports/www/chromium/work/chromium-38.0.2125.111/third_party/icu/source/configure
===>   FreeBSD 10 autotools fix applied to
/usr/ports/www/chromium/work/chromium-38.0.2125.111/third_party/icu/source/acinclude.m4
cd /usr/ports/www/chromium/work/chromium-38.0.2125.111 &&
/usr/local/bin/python2.7  ./build/linux/unbundle/remove_bundled_libraries.py 
'base/third_party/dmg_fp'  'base/third_party/dynamic_annotations' 
'base/third_party/icu'  'base/third_party/nspr' 
'base/third_party/superfasthash'  'base/third_party/symbolize' 
'base/third_party/valgrind'  'base/third_party/xdg_mime' 
'base/third_party/xdg_user_dirs'  'breakpad/src/third_party/curl' 
'chrome/third_party/mock4js'  'chrome/third_party/mozilla_security_manager' 
'courgette/third_party'  'crypto/third_party/nss' 
'net/third_party/mozilla_security_manager'  'net/third_party/nss' 
'third_party/WebKit'  'third_party/angle'  'third_party/angle/src/third_party' 
'third_party/blanketjs'  'third_party/brotli'  'third_party/boringssl' 
'third_party/cacheinvalidation'  'third_party/cld' 
'third_party/cros_system_api'  'third_party/dom_distiller_js' 
'third_party/dom_distiller_js/package/proto_gen/third_party/dom_distiller_js' 
'third_party/ffmpeg'  'third_party/fips181'  'third_party/flot' 
'third_party/hunspell'  'third_party/iccjpeg'  'third_party/icu/icu.isolate' 
'third_party/jinja2'  'third_party/jstemplate'  'third_party/khronos' 
'third_party/leveldatabase'  'third_party/libaddressinput' 
'third_party/libjingle'  'third_party/libphonenumber'  'third_party/libsrtp' 
'third_party/libvpx'  'third_party/libvpx/source/libvpx/third_party/x86inc' 
'third_party/libwebm'  'third_party/libxml/chromium'  'third_party/libXNVCtrl' 
'third_party/libyuv'  'third_party/lss'  'third_party/lzma_sdk' 
'third_party/markupsafe'  'third_party/mesa'  'third_party/modp_b64' 
'third_party/mt19937ar'  'third_party/npapi'  'third_party/opus' 
'third_party/ots'  'third_party/pdfium'  'third_party/pdfium/third_party' 
'third_party/ply'  'third_party/polymer'  'third_party/pywebsocket' 
'third_party/qcms'  'third_party/qunit'  'third_party/readability' 
'third_party/sfntly'  'third_party/sinonjs'  'third_party/skia' 
'third_party/smhasher'  'third_party/sqlite'  'third_party/tcmalloc' 
'third_party/tlslite'  'third_party/trace-viewer' 
'third_party/trace-viewer/third_party' 
'third_party/trace-viewer/third_party/tvcm/third_party'  'third_party/undoview'
 'third_party/usrsctp'  'third_party/webdriver'  'third_party/webrtc' 
'third_party/widevine'  'third_party/x86inc'  'third_party/yasm' 
'third_party/zlib'  'url/third_party/mozilla'  'v8/src/third_party/valgrind' 
'v8/third_party/fdlibm'  --do-remove || false
cd /usr/ports/www/chromium/work/chromium-38.0.2125.111 &&
/usr/local/bin/python2.7  ./build/linux/unbundle/replace_gyp_files.py 
-Dclang_use_chrome_plugins=0 -Dlinux_breakpad=0 -Dlinux_use_heapchecker=0
-Dlinux_strip_binary=1 -Dtest_isolation_mode=noop -Ddisable_nacl=1
-Denable_extensions=1 -Denable_one_click_signin=1 -Denable_openmax=1
-Denable_webrtc=1 -Dwerror= -Dno_gc_sections=1 -Dos_ver=1000510
-Dprefix_dir=/usr/local -Dpython_ver=2.7 -Duse_allocator=none -Duse_cups=1
-Dlinux_link_gsettings=1 -Dlinux_link_libpci=1 -Dlinux_link_libspeechd=1
-Dlibspeechd_h_prefix=speech-dispatcher/
-Dusb_ids_path=/usr/local/share/usbids/usb.ids -Dwant_separate_host_toolset=0
-Duse_system_bzip2=1 -Duse_system_flac=1 -Duse_system_harfbuzz=1
-Duse_system_icu=1 -Duse_system_jsoncpp=1 -Duse_system_libevent=1
-Duse_system_libexif=1 -Duse_system_libjpeg=1 -Duse_system_libpng=1
-Duse_system_libusb=1 -Duse_system_libwebp=1 -Duse_system_libxml=1
-Duse_system_libxslt=1 -Duse_system_nspr=1 -Duse_system_protobuf=1
-Duse_system_re2=1 -Duse_system_snappy=1 -Duse_system_speex=1
-Duse_system_xdg_utils=1 -Duse_system_yasm=1
-Dflapper_version_h_file='/usr/ports/www/chromium/work/chromium-38.0.2125.111/flapper_version.h'
-Dgoogle_api_key=AIzaSyBsp9n41JLW8jCokwn7vhoaMejDFRd1mp8
-Dgoogle_default_client_id=996322985003.apps.googleusercontent.com
-Dgoogle_default_client_secret=IR1za9-1VK0zZ0f_O8MVFicn
-Dffmpeg_branding=Chrome -Dproprietary_codecs=1 -Duse_gconf=1
-Duse_pulseaudio=0 -Dclang=1 || false
echo > /usr/ports/www/chromium/work/chromium-38.0.2125.111/flapper_version.h
cd /usr/ports/www/chromium/work/chromium-38.0.2125.111 && /usr/bin/env
XDG_DATA_HOME=/usr/ports/www/chromium/work 
XDG_CONFIG_HOME=/usr/ports/www/chromium/work  HOME=/usr/ports/www/chromium/work
TMPDIR="/tmp" CC="cc"  CXX="c++"  GYP_GENERATORS=ninja 
GYP_DEFINES="clang_use_chrome_plugins=0  linux_breakpad=0 
linux_use_heapchecker=0  linux_strip_binary=1  test_isolation_mode=noop 
disable_nacl=1  enable_extensions=1  enable_one_click_signin=1 
enable_openmax=1  enable_webrtc=1  werror=  no_gc_sections=1  os_ver=1000510 
prefix_dir=/usr/local  python_ver=2.7  use_allocator=none  use_cups=1 
linux_link_gsettings=1  linux_link_libpci=1  linux_link_libspeechd=1 
libspeechd_h_prefix=speech-dispatcher/ 
usb_ids_path=/usr/local/share/usbids/usb.ids  want_separate_host_toolset=0 
use_system_bzip2=1  use_system_flac=1  use_system_harfbuzz=1  use_system_icu=1 
use_system_jsoncpp=1  use_system_libevent=1  use_system_libexif=1 
use_system_libjpeg=1  use_system_libpng=1  use_system_libusb=1 
use_system_libwebp=1  use_system_libxml=1  use_system_libxslt=1 
use_system_nspr=1  use_system_protobuf=1  use_system_re2=1  use_system_snappy=1
 use_system_speex=1  use_system_xdg_utils=1  use_system_yasm=1
flapper_version_h_file='/usr/ports/www/chromium/work/chromium-38.0.2125.111/flapper_version.h'
google_api_key=AIzaSyBsp9n41JLW8jCokwn7vhoaMejDFRd1mp8 
google_default_client_id=996322985003.apps.googleusercontent.com 
google_default_client_secret=IR1za9-1VK0zZ0f_O8MVFicn ffmpeg_branding=Chrome
proprietary_codecs=1 use_gconf=1 use_pulseaudio=0 clang=1"
XDG_DATA_HOME=/usr/ports/www/chromium/work 
XDG_CONFIG_HOME=/usr/ports/www/chromium/work  HOME=/usr/ports/www/chromium/work
TMPDIR="/tmp" PKG_CONFIG=pkgconf ac_cv_path_PERL=/usr/local/bin/perl
ac_cv_path_PERL_PATH=/usr/local/bin/perl PYTHON="/usr/local/bin/python2.7"
AR=/usr/bin/ar CFLAGS="-O2 -pipe -fno-stack-protector
-isystem/usr/local/include -Wno-unknown-warning-option -fstack-protector
-fno-strict-aliasing"  CPPFLAGS=""  CXXFLAGS="-O2 -pipe -fno-stack-protector
-isystem/usr/local/include -Wno-unknown-warning-option -fstack-protector
-fno-strict-aliasing"  LDFLAGS=" -fstack-protector"
XDG_DATA_HOME=/usr/ports/www/chromium/work 
XDG_CONFIG_HOME=/usr/ports/www/chromium/work  HOME=/usr/ports/www/chromium/work
TMPDIR="/tmp" SHELL=/bin/sh CONFIG_SHELL=/bin/sh /usr/local/bin/python2.7 
./build/gyp_chromium chrome/chrome.gyp --depth .
Updating projects from gyp files...
===>  Building for chromium-38.0.2125.111
ninja: Entering directory `out/Release'
[234/15297] CXX obj/v8/src/base/platform/v8_libbase.platform-posix.o
../../v8/src/base/platform/platform-posix.cc:331:1: warning: control reaches
end of non-void function [-Wreturn-type]
}
^
1 warning generated.
[547/15297] RULE Generating C++ and Py... code from copresence/proto/rpcs.proto
[libprotobuf WARNING google/protobuf/descriptor.cc:5411] Warning: Unused
import: "rpcs.proto" imports "enums.proto" which is not used.
[637/15297] RULE Generating C++ and Python code from feedback/proto/web.proto
[libprotobuf WARNING google/protobuf/descriptor.cc:5411] Warning: Unused
import: "web.proto" imports "math.proto" which is not used.
[941/15297] RULE Generating C++ and Py...ol/synced_notification_specifics.proto
[libprotobuf WARNING google/protobuf/descriptor.cc:5411] Warning: Unused
import: "synced_notification_specifics.proto" imports
"synced_notification_render.proto" which is not used.
[1224/15297] CXX obj/base/posix/base.unix_domain_socket_linux.o
../../base/posix/unix_domain_socket_linux.cc:46:13: warning: unused variable
'enable' [-Wunused-variable]
  const int enable = 1;
            ^
1 warning generated.
[2120/15297] CXX obj/base/base.sync_socket_posix.o
../../base/sync_socket_posix.cc:133:15: warning: comparison of integers of
different signs: 'Handle' (aka 'int') and 'unsigned int' [-Wsign-compare]
  if (handle_ >= FD_SETSIZE)
      ~~~~~~~ ^  ~~~~~~~~~~
1 warning generated.
[2200/15297] CXX obj/base/base.sys_info_posix.o
../../base/sys_info_posix.cc:46:5: warning: unused variable
'g_lazy_number_of_processors' [-Wunused-variable]
    g_lazy_number_of_processors = LAZY_INSTANCE_INITIALIZER;
    ^
1 warning generated.
[3385/15297] CXX obj/components/storag...rage_monitor.storage_monitor_freebsd.o
../../components/storage_monitor/storage_monitor_freebsd.cc:45:29: warning:
unused function 'EjectPathOnFileThread' [-Wunused-function]
StorageMonitor::EjectStatus EjectPathOnFileThread(
                            ^
1 warning generated.
[5614/15297] CXX obj/third_party/webrt...urce/webrtc_video_coding.codec_timer.o
FAILED: c++ -MMD -MF
obj/third_party/webrtc/modules/video_coding/main/source/webrtc_video_coding.codec_timer.o.d
-DV8_DEPRECATION_WARNINGS -D_FILE_OFFSET_BITS=64 -DNO_TCMALLOC -DDISABLE_NACL
-DCHROMIUM_BUILD -DCR_CLANG_REVISION=214024 -DTOOLKIT_VIEWS=1 -DUSE_AURA=1
-DUSE_ASH=1 -DUSE_PANGO=1 -DUSE_CAIRO=1 -DUSE_GLIB=1
-DUSE_DEFAULT_RENDER_THEME=1 -DUSE_LIBJPEG_TURBO=1 -DUSE_X11=1
-DUSE_CLIPBOARD_AURAX11=1 -DENABLE_ONE_CLICK_SIGNIN -DUSE_XI2_MT=2
-DENABLE_REMOTING=1 -DENABLE_WEBRTC=1 -DUSE_PROPRIETARY_CODECS
-DENABLE_CONFIGURATION_POLICY -DENABLE_NOTIFICATIONS -DENABLE_EGLIMAGE=1
-DENABLE_TASK_MANAGER=1 -DENABLE_EXTENSIONS=1 -DENABLE_PLUGINS=1
-DENABLE_SESSION_SERVICE=1 -DENABLE_THEMES=1 -DENABLE_AUTOFILL_DIALOG=1
-DENABLE_BACKGROUND=1 -DENABLE_GOOGLE_NOW=1 -DCLD_VERSION=2
-DCLD2_DATA_SOURCE=static -DENABLE_FULL_PRINTING=1 -DENABLE_PRINTING=1
-DENABLE_SPELLCHECK=1 -DENABLE_CAPTIVE_PORTAL_DETECTION=1 -DENABLE_APP_LIST=1
-DENABLE_SETTINGS_APP=1 -DENABLE_MANAGED_USERS=1
'-DDATA_REDUCTION_FALLBACK_HOST="http://compress.googlezip.net:80/"'
'-DDATA_REDUCTION_DEV_HOST="http://proxy-dev.googlezip.net:80/"'
'-DSPDY_PROXY_AUTH_ORIGIN="https://proxy.googlezip.net:443/"'
'-DDATA_REDUCTION_PROXY_PROBE_URL="http://check.googlezip.net/connect"'
'-DDATA_REDUCTION_PROXY_WARMUP_URL="http://www.gstatic.com/generate_204"'
-DENABLE_MDNS=1 -DENABLE_SERVICE_DISCOVERY=1 -DWEBRTC_RESTRICT_LOGGING
-DWEBRTC_MODULE_UTILITY_VIDEO -DWEBRTC_CHROMIUM_BUILD -DLOGGING_INSIDE_WEBRTC
-DWEBRTC_POSIX -DWEBRTC_BSD -DWEBRTC_LINUX -DWEBRTC_THREAD_RR -DUSE_NSS=1
-D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -DNDEBUG -DNVALGRIND
-DDYNAMIC_ANNOTATIONS_ENABLED=0 -D_FORTIFY_SOURCE=2 -Igen -I../..
-I../../third_party/webrtc/overrides -I../../third_party
-I../../third_party/webrtc/common_video/interface
-I../../third_party/webrtc/common_video/libyuv/include
-I../../third_party/webrtc/system_wrappers/interface -fstack-protector
--param=ssp-buffer-size=4  -pthread -fno-exceptions -fno-strict-aliasing -Wall
-Wno-unused-parameter -Wno-missing-field-initializers -fvisibility=hidden -pipe
-fPIC -Wno-reserved-user-defined-literal -fcolor-diagnostics -Wheader-hygiene
-Wno-char-subscripts -Wno-unneeded-internal-declaration
-Wno-covered-switch-default -Wstring-conversion -Wno-c++11-narrowing
-Wno-deprecated-register -m64 -march=x86-64 -O2 -fdata-sections
-ffunction-sections -fno-slp-vectorize -funwind-tables -O2 -pipe
-fno-stack-protector -isystem/usr/local/include -Wno-unknown-warning-option
-fstack-protector -fno-strict-aliasing -fno-rtti -fno-threadsafe-statics
-fvisibility-inlines-hidden -Wsign-compare -std=gnu++11  -c
../../third_party/webrtc/modules/video_coding/main/source/codec_timer.cc -o
obj/third_party/webrtc/modules/video_coding/main/source/webrtc_video_coding.codec_timer.o
Stack dump:
0.      Program arguments: /usr/bin/c++ -cc1 -triple x86_64-unknown-freebsd10.0
-emit-obj -disable-free -disable-llvm-verifier -main-file-name codec_timer.cc
-mrelocation-model pic -pic-level 2 -mdisable-fp-elim -relaxed-aliasing
-masm-verbose -mconstructor-aliases -munwind-tables -target-cpu x86-64
-ffunction-sections -fdata-sections -coverage-file
/usr/ports/www/chromium/work/chromium-38.0.2125.111/out/Release/obj/third_party/webrtc/modules/video_coding/main/source/webrtc_video_coding.codec_timer.o
-resource-dir /usr/bin/../lib/clang/3.3 -dependency-file
obj/third_party/webrtc/modules/video_coding/main/source/webrtc_video_coding.codec_timer.o.d
-MT
obj/third_party/webrtc/modules/video_coding/main/source/webrtc_video_coding.codec_timer.o
-isystem /usr/local/include -D V8_DEPRECATION_WARNINGS -D _FILE_OFFSET_BITS=64
-D NO_TCMALLOC -D DISABLE_NACL -D CHROMIUM_BUILD -D CR_CLANG_REVISION=214024 -D
TOOLKIT_VIEWS=1 -D USE_AURA=1 -D USE_ASH=1 -D USE_PANGO=1 -D USE_CAIRO=1 -D
USE_GLIB=1 -D USE_DEFAULT_RENDER_THEME=1 -D USE_LIBJPEG_TURBO=1 -D USE_X11=1 -D
USE_CLIPBOARD_AURAX11=1 -D ENABLE_ONE_CLICK_SIGNIN -D USE_XI2_MT=2 -D
ENABLE_REMOTING=1 -D ENABLE_WEBRTC=1 -D USE_PROPRIETARY_CODECS -D
ENABLE_CONFIGURATION_POLICY -D ENABLE_NOTIFICATIONS -D ENABLE_EGLIMAGE=1 -D
ENABLE_TASK_MANAGER=1 -D ENABLE_EXTENSIONS=1 -D ENABLE_PLUGINS=1 -D
ENABLE_SESSION_SERVICE=1 -D ENABLE_THEMES=1 -D ENABLE_AUTOFILL_DIALOG=1 -D
ENABLE_BACKGROUND=1 -D ENABLE_GOOGLE_NOW=1 -D CLD_VERSION=2 -D
CLD2_DATA_SOURCE=static -D ENABLE_FULL_PRINTING=1 -D ENABLE_PRINTING=1 -D
ENABLE_SPELLCHECK=1 -D ENABLE_CAPTIVE_PORTAL_DETECTION=1 -D ENABLE_APP_LIST=1
-D ENABLE_SETTINGS_APP=1 -D ENABLE_MANAGED_USERS=1 -D
DATA_REDUCTION_FALLBACK_HOST="http://compress.googlezip.net:80/" -D
DATA_REDUCTION_DEV_HOST="http://proxy-dev.googlezip.net:80/" -D
SPDY_PROXY_AUTH_ORIGIN="https://proxy.googlezip.net:443/" -D
DATA_REDUCTION_PROXY_PROBE_URL="http://check.googlezip.net/connect" -D
DATA_REDUCTION_PROXY_WARMUP_URL="http://www.gstatic.com/generate_204" -D
ENABLE_MDNS=1 -D ENABLE_SERVICE_DISCOVERY=1 -D WEBRTC_RESTRICT_LOGGING -D
WEBRTC_MODULE_UTILITY_VIDEO -D WEBRTC_CHROMIUM_BUILD -D LOGGING_INSIDE_WEBRTC
-D WEBRTC_POSIX -D WEBRTC_BSD -D WEBRTC_LINUX -D WEBRTC_THREAD_RR -D USE_NSS=1
-D __STDC_CONSTANT_MACROS -D __STDC_FORMAT_MACROS -D NDEBUG -D NVALGRIND -D
DYNAMIC_ANNOTATIONS_ENABLED=0 -D _FORTIFY_SOURCE=2 -I gen -I ../.. -I
../../third_party/webrtc/overrides -I ../../third_party -I
../../third_party/webrtc/common_video/interface -I
../../third_party/webrtc/common_video/libyuv/include -I
../../third_party/webrtc/system_wrappers/interface -internal-isystem
/usr/include/c++/v1 -O2 -Wall -Wno-unused-parameter
-Wno-missing-field-initializers -Wno-reserved-user-defined-literal
-Wheader-hygiene -Wno-char-subscripts -Wno-unneeded-internal-declaration
-Wno-covered-switch-default -Wstring-conversion -Wno-c++11-narrowing
-Wno-deprecated-register -Wno-unknown-warning-option -Wsign-compare
-std=gnu++11 -fdeprecated-macro -fdebug-compilation-dir
/usr/ports/www/chromium/work/chromium-38.0.2125.111/out/Release -ferror-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-runtime=gnustep
-fobjc-default-synthesize-properties -fdiagnostics-show-option
-fcolor-diagnostics -backend-option -vectorize-loops -o
obj/third_party/webrtc/modules/video_coding/main/source/webrtc_video_coding.codec_timer.o
-x c++ ../../third_party/webrtc/modules/video_coding/main/source/codec_timer.cc 
1.      <eof> parser at end of file
2.      Code generation
3.      Running pass 'Function Pass Manager' on module
'../../third_party/webrtc/modules/video_coding/main/source/codec_timer.cc'.
4.      Running pass 'X86 DAG->DAG Instruction Selection' on function
'@_ZN6webrtc13VCMCodecTimerC2Ev'
c++: error: unable to execute command: Segmentation fault (core dumped)
c++: error: clang frontend command failed due to signal (use -v to see
invocation)
FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610
Target: x86_64-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: 
********************

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

********************
[5614/15297] CXX obj/third_party/webrt...e/webrtc_video_coding.codec_database.o
ninja: build stopped: subcommand failed.
===> Compilation failed unexpectedly.
Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to
the maintainer.
*** Error code 1

Stop.
make[1]: stopped in /usr/ports/www/chromium
*** Error code 1

Stop.
make: stopped in /usr/ports/www/chromium

===>>> make build failed for www/chromium
===>>> Aborting update


===>>> You can restart from the point of failure with this command line:
       portmaster <flags> www/chromium

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

From bugzilla-daemon at llvm.org  Tue Nov 11 14:07:35 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 11 Nov 2014 22:07:35 +0000
Subject: [LLVMbugs] [Bug 21496] string_view::remove_prefix,
 remove_suffix should leave n > size() UB
In-Reply-To: <bug-21496-206@http.llvm.org/bugs/>
References: <bug-21496-206@http.llvm.org/bugs/>
Message-ID: <bug-21496-206-vNKctWp26A@http.llvm.org/bugs/>

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

Marshall Clow (home) <mclow.lists at gmail.com> changed:

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

--- Comment #5 from Marshall Clow (home) <mclow.lists at gmail.com> ---
Replaced the checks with a _LIBCPP_ASSERT in revision 221717.

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

From bugzilla-daemon at llvm.org  Tue Nov 11 14:18:14 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 11 Nov 2014 22:18:14 +0000
Subject: [LLVMbugs] [Bug 21536] New: clang incorrectly deduces template
	parameter pack
Message-ID: <bug-21536-206@http.llvm.org/bugs/>

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

            Bug ID: 21536
           Summary: clang incorrectly deduces template parameter pack
           Product: clang
           Version: 3.5
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++11
          Assignee: unassignedclangbugs at nondot.org
          Reporter: hui.li at me.com
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Clang 3.5 is unable to compile the following code:

template < typename, typename... >
struct X {};

template < typename... T >
void foo(const X<T...>&)
{}

int main()
{
   X<int,int> x;
   foo(x);
}


The error I got reads:

t.cpp:11:4: error: no matching function for call to 'foo'
   foo(x);
   ^~~
t.cpp:5:6: note: candidate template ignored: substitution failure [with T =
<>]: too few template arguments for class template 'X'
void foo(const X<T...>&)
     ^         ~
1 error generated.


GCC 4.8.3 is able to compile 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/20141111/1ec8f6a0/attachment.html>

From bugzilla-daemon at llvm.org  Tue Nov 11 14:38:07 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 11 Nov 2014 22:38:07 +0000
Subject: [LLVMbugs] [Bug 21537] New: Clang warnings are inconsistent between
 compiling from C source to object code and preprocessed C source to object
 code
Message-ID: <bug-21537-206@http.llvm.org/bugs/>

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

            Bug ID: 21537
           Summary: Clang warnings are inconsistent between compiling from
                    C source to object code and preprocessed C source to
                    object code
           Product: clang
           Version: 3.5
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
          Assignee: unassignedclangbugs at nondot.org
          Reporter: jonathan.hamilton at imgtec.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 13322
  --> http://llvm.org/bugs/attachment.cgi?id=13322&action=edit
C test code having a tautological comparison as the result of a preprocessor
macro expansion.

Clang appears to handle some symbols differently with respect to warnings
depending on if the code is the result of a preprocessor macro expansion or
not.

This causes an inconsistency between pre-processing and compiling a source file
in one step to preprocessing then compiling as two stages.

For example, using the attached test program building (with clang 3.5.0 on
x86_64) with the following command line:

clang -Werror tautological-compare-in-macro.c -o /dev/null -c

succeeds with no warnings/errors. However running:

clang -Werror tautological-compare-in-macro.c -o
tautological-compare-in-macro.p -E
clang -Werror -x c tautological-compare-in-macro.p -o /dev/null -c

causes it to emit a warning (-Wtautological-compare, which causes this to fail
due to -Werror)

This is rather annoying when large projects add -Werror to their build systems.
This example was specifically seen (and significantly simplified from) a file
in Android.

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

From bugzilla-daemon at llvm.org  Tue Nov 11 14:45:37 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 11 Nov 2014 22:45:37 +0000
Subject: [LLVMbugs] [Bug 21537] Clang warnings are inconsistent between
 compiling from C source to object code and preprocessed C source to object
 code
In-Reply-To: <bug-21537-206@http.llvm.org/bugs/>
References: <bug-21537-206@http.llvm.org/bugs/>
Message-ID: <bug-21537-206-VvFtqVHRmE@http.llvm.org/bugs/>

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

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> ---
It is not the intention of the Clang project to produce the same diagnostics on
preprocessed and unpreprocessed source code.

If there's a particular diagnostic quality issue that might be addressed we can
look into it, but in some cases macro-ness is the best signal we have to remove
false positives and we might have to sacrifice some true positives for that
gain in signal/noise on a particular diagnostic.

If you have a particular need to take preprocessed code and compile it and get
the same result, you could consider using the -frewrite-includes mode that only
does #includes and leaves the macros in tact, this should generally produce
similar/identical diagnostics when compiled. (this can be used for distributed
build systems that need to send single input files to their build nodes)

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

From bugzilla-daemon at llvm.org  Tue Nov 11 15:12:44 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 11 Nov 2014 23:12:44 +0000
Subject: [LLVMbugs] [Bug 21348] -Wignored-qualifier noisy on common pattern
In-Reply-To: <bug-21348-206@http.llvm.org/bugs/>
References: <bug-21348-206@http.llvm.org/bugs/>
Message-ID: <bug-21348-206-97S1DYeyux@http.llvm.org/bugs/>

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

Sean Silva <chisophugis at gmail.com> changed:

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

--- Comment #10 from Sean Silva <chisophugis at gmail.com> ---
(In reply to comment #8)
> Yes its to abstract an issue with some ABIs, and really comes into its own
> when a vector library is cross platform.
> 
> For instance Win32 only passes 3 128bit vectors in register and the rest get
> passed on the stack (and a not a guaranteed 16-byte aligned stack at
> that..). Other targets have issues with passing different size vectors
> (64bit, 256bit, ....), especially when they aren't native.
> 
> The _arg pattern allows us to hide all pass-by-reference vs pass-by-value
> issues - and when used by lightweight functions that get inlined many of
> those reference loads disappear as well.
> 
> But given that _arg types have the potential to be pass-by-reference I'd
> highly recommend to do everything possible to keep the const qualifier on
> all typedefs - otherwise you have the potential to develop on a
> pass-by-value target and not see const modification compile errors that only
> occur on pass-by-reference, or even worse modify the referenced value.

Thanks Simon. That clarifies things. Now that I look at it, all of the cases
I've seen actually use these variations:

typedef const Vec4& Vec4_arg;
// or
typedef const Vec4 Vec4_arg;

which are const anyway, so I guess it makes sense to have clang warn on `const
Vec4_arg` since the const there is just redundant (rather than actively
deceiving as in the case that motivated the warning and that Arthur was talking
about).

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

From bugzilla-daemon at llvm.org  Tue Nov 11 17:44:03 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 12 Nov 2014 01:44:03 +0000
Subject: [LLVMbugs] [Bug 21536] clang incorrectly deduces template parameter
	pack
In-Reply-To: <bug-21536-206@http.llvm.org/bugs/>
References: <bug-21536-206@http.llvm.org/bugs/>
Message-ID: <bug-21536-206-BU4XnwtBf9@http.llvm.org/bugs/>

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

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> ---
Yikes. Fixed in r221748.

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

From bugzilla-daemon at llvm.org  Tue Nov 11 17:46:57 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 12 Nov 2014 01:46:57 +0000
Subject: [LLVMbugs] [Bug 21538] New: Provides a way to extract the path of
 libcompiler_rt
Message-ID: <bug-21538-206@http.llvm.org/bugs/>

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

            Bug ID: 21538
           Summary: Provides a way to extract the path of libcompiler_rt
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Driver
          Assignee: unassignedclangbugs at nondot.org
          Reporter: eocallaghan at alterapraxis.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 13323
  --> http://llvm.org/bugs/attachment.cgi?id=13323&action=edit
Frontend driver patch

Hi,

Attached is a path that provides a way to get at the path of libcompiler_rt
from the frontend much the same way '-print-libgcc-file-name' works to get at
libgcc.a

We need this (it blocks us) in Coreboot.org as our build system is very low
level and this kind of granularity of control is used during link-time with our
rather demanding/tentative linker scripts.

Seems people in the IRC are very busy these days to quickly take care of this
one so i'll leave it here. I've done my best on the test case also so this is
like 98% the way there, I just need someone to take care of the rest.

Kind Regards,
Edward.

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

From bugzilla-daemon at llvm.org  Tue Nov 11 18:02:37 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 12 Nov 2014 02:02:37 +0000
Subject: [LLVMbugs] [Bug 21539] New: TableGen errors if operand with
 suboperands used without repeating type in output pattern
Message-ID: <bug-21539-206@http.llvm.org/bugs/>

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

            Bug ID: 21539
           Summary: TableGen errors if operand with suboperands used
                    without repeating type in output pattern
           Product: tools
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: TableGen
          Assignee: unassignedbugs at nondot.org
          Reporter: Matthew.Arsenault at amd.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

If you attempt to use a custom Operand type with suboperands, and don't repeat
the type in the output pattern, there is an error from operand number mismatch.
For any other operand type, just specifying the name of the operand in the
result is enough.

e.g.

def MEMOP  : Operand<iPTR> {
  let MIOperandInfo = (ops PtrRC:$base, PtrRC:$reg, PtrRC:$offset);
  let PrintMethod = "printAddrMode3Op";
}

// OK, MEMOP explicitly mentioned in output pattern
class LDPat<Instruction inst, SDPatternOperator ldnode, ValueType vt> : Pat <
  (vt (ldnode (LoadAddr MEMOP:$address))),
  (inst MEMOP:$address) 
>;

// Errors, the complex operand only counts towards one operand of the output
instruction and errors when it should count as 3
class LDPat<Instruction inst, SDPatternOperator ldnode, ValueType vt> : Pat <
  (vt (ldnode (LoadAddr MEMOP:$address))),
  (inst $address)
>;





The problem is in CodeGenDAGPatterns.cpp:

          if (Child->getNumMIResults(CDP) < NumArgs) {
            // Match first sub-operand against the child we already have.
            Record *SubRec = cast<DefInit>(MIOpInfo->getArg(0))->getDef();
            MadeChange |=
              Child->UpdateNodeTypeFromInst(ChildResNo, SubRec, TP);

            // And the remaining sub-operands against subsequent children.
            for (unsigned Arg = 1; Arg < NumArgs; ++Arg) {
              if (ChildNo >= getNumChildren()) {
                emitTooFewOperandsError(TP, getOperator()->getName(),
                                        getNumChildren());
                return false;
              }
              Child = getChild(ChildNo++);

              SubRec = cast<DefInit>(MIOpInfo->getArg(Arg))->getDef();
              MadeChange |=
                Child->UpdateNodeTypeFromInst(ChildResNo, SubRec, TP);
            }
            continue;
          }

In the working case with the explicitly specified Operand type,
Child->getNumMIResults(CDP)
returns the correct 3 from the isLeaf() / dyn_cast<DefInit>() path. In the
broken case, this only returns 1 where the leaf is an UnsetInit. I'm not really
sure what this is attempting to do in the case where
Child->getNumMIResults(CDP) < NumArgs). Is it trying to allow using multiple
operands that together make up the components of a single complex operand?

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

From bugzilla-daemon at llvm.org  Tue Nov 11 18:03:55 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 12 Nov 2014 02:03:55 +0000
Subject: [LLVMbugs] [Bug 20893] trunk  217475 and -g -O2 causing crash
In-Reply-To: <bug-20893-206@http.llvm.org/bugs/>
References: <bug-20893-206@http.llvm.org/bugs/>
Message-ID: <bug-20893-206-L5ZhajFCfE@http.llvm.org/bugs/>

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

Frederic Riss <friss at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
                 CC|                            |friss at apple.com
         Resolution|---                         |FIXED

--- Comment #8 from Frederic Riss <friss at apple.com> ---
Fixed by r221709

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

From bugzilla-daemon at llvm.org  Tue Nov 11 18:18:49 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 12 Nov 2014 02:18:49 +0000
Subject: [LLVMbugs] [Bug 21540] New: The -object_path_lto option should
 support paths to directories
Message-ID: <bug-21540-206@http.llvm.org/bugs/>

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

            Bug ID: 21540
           Summary: The -object_path_lto option should support paths to
                    directories
           Product: lld
           Version: unspecified
          Hardware: PC
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: All Bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: kulakov.ilya at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

It's not always possible to modify invocations to the linker, especially when
you compile 3rd party projects or use some build system. Therefore it's often
quite hard to enable LTO because linker requires unique path to
"-object_path_lto" in order to make utils like dsymutil.

The solution should be fairly simple: allow to specify path to a directory and
create whatever unique files automatically.

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

From bugzilla-daemon at llvm.org  Tue Nov 11 20:34:16 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 12 Nov 2014 04:34:16 +0000
Subject: [LLVMbugs] [Bug 21221] bogus unused-local-typedef warning
In-Reply-To: <bug-21221-206@http.llvm.org/bugs/>
References: <bug-21221-206@http.llvm.org/bugs/>
Message-ID: <bug-21221-206-4s69HcObe1@http.llvm.org/bugs/>

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

Nico Weber <nicolasweber at gmx.de> changed:

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

--- Comment #2 from Nico Weber <nicolasweber at gmx.de> ---
landed (with test and a minor tweak) in r221771, 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/20141112/35071270/attachment.html>

From bugzilla-daemon at llvm.org  Tue Nov 11 21:56:14 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 12 Nov 2014 05:56:14 +0000
Subject: [LLVMbugs] [Bug 21541] New: poor codegen for unaligned fixed-size
 memcpy/memmove
Message-ID: <bug-21541-206@http.llvm.org/bugs/>

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

            Bug ID: 21541
           Summary: poor codegen for unaligned fixed-size memcpy/memmove
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: X86
          Assignee: unassignedbugs at nondot.org
          Reporter: chisophugis at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

void copy32byte(void *pDst, const void *pSrc) {                                 
  __builtin_memmove(pDst, pSrc, 32);
}


clang++ -O3 -march=btver2 -c testcopy.cpp -o test.o

generates:

__Z10copy32bytePvPKv:
0000000000000000        pushq   %rbp
0000000000000001        movq    %rsp, %rbp
0000000000000004        movq    (%rsi), %rax
0000000000000007        movq    0x8(%rsi), %rcx
000000000000000b        movq    0x10(%rsi), %rdx
000000000000000f        movq    0x18(%rsi), %rsi
0000000000000013        movq    %rsi, 0x18(%rdi)
0000000000000017        movq    %rdx, 0x10(%rdi)
000000000000001b        movq    %rcx, 0x8(%rdi)
000000000000001f        movq    %rax, (%rdi)
0000000000000022        popq    %rbp
0000000000000023        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/20141112/4ac22529/attachment.html>

From bugzilla-daemon at llvm.org  Wed Nov 12 00:38:55 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 12 Nov 2014 08:38:55 +0000
Subject: [LLVMbugs] [Bug 21542] New: Division by zero not found for floating
 point values
Message-ID: <bug-21542-206@http.llvm.org/bugs/>

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

            Bug ID: 21542
           Summary: Division by zero not found for floating point values
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Static Analyzer
          Assignee: kremenek at apple.com
          Reporter: matthias.scholz at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Example on: http://clang-analyzer.llvm.org/available_checks.html works but the
following short snippet is not detected:

int main()
{
   double y = 0.0;
   double x = 1.0 / y; // not found

   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/20141112/5a1ce78c/attachment.html>

From bugzilla-daemon at llvm.org  Wed Nov 12 02:13:59 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 12 Nov 2014 10:13:59 +0000
Subject: [LLVMbugs] [Bug 21230] Performance regression in vector shuffle +
	pmaddwd
In-Reply-To: <bug-21230-206@http.llvm.org/bugs/>
References: <bug-21230-206@http.llvm.org/bugs/>
Message-ID: <bug-21230-206-DhSGerP6ne@http.llvm.org/bugs/>

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

Chandler Carruth <chandlerc at gmail.com> changed:

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

--- Comment #1 from Chandler Carruth <chandlerc at gmail.com> ---
Fixed in r221779 thanks to Clay Wood's analysis and work to identify the 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/20141112/8525965c/attachment.html>

From bugzilla-daemon at llvm.org  Wed Nov 12 04:41:28 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 12 Nov 2014 12:41:28 +0000
Subject: [LLVMbugs] [Bug 21543] New: Support 64 bit long double
Message-ID: <bug-21543-206@http.llvm.org/bugs/>

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

            Bug ID: 21543
           Summary: Support 64 bit long double
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Driver
          Assignee: unassignedclangbugs at nondot.org
          Reporter: mail+llvm at tzik.jp
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

GCC has -mlong-double-64 that forces the size of long double to 64 bit.
Though Clang doesn't have that or any equivalent.

This option is required to build Bionic with 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/20141112/47134d4f/attachment.html>

From bugzilla-daemon at llvm.org  Wed Nov 12 06:11:34 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 12 Nov 2014 14:11:34 +0000
Subject: [LLVMbugs] [Bug 21546] New: Cannot mark lambda operator() as
	noreturn
Message-ID: <bug-21546-206@http.llvm.org/bugs/>

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

            Bug ID: 21546
           Summary: Cannot mark lambda operator() as noreturn
           Product: clang
           Version: trunk
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++11
          Assignee: unassignedclangbugs at nondot.org
          Reporter: gonzalobg88 at gmail.com
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Minimal example:

#include<iostream>
int main() {
  []() [[noreturn]] { std::exit(1); }();
  return 0;
}

produces: "error: 'noreturn' attribute cannot be applied to types"

Under gcc this works fine. 

I don't know where should one put [[noreturn]], but there should be a way to
mark the operator() of a lambda as noreturn.

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

From bugzilla-daemon at llvm.org  Wed Nov 12 06:13:13 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 12 Nov 2014 14:13:13 +0000
Subject: [LLVMbugs] [Bug 21547] New: Clang codegen asserts "An asserting
 value handle still pointed to this value!"
Message-ID: <bug-21547-206@http.llvm.org/bugs/>

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

            Bug ID: 21547
           Summary: Clang codegen asserts "An asserting value handle still
                    pointed to this value!"
           Product: clang
           Version: unspecified
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Modules
          Assignee: unassignedclangbugs at nondot.org
          Reporter: vvasilev at cern.ch
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Index: Inputs/PRN2/module.modulemap
===================================================================
--- Inputs/PRN2/module.modulemap    (revision 0)
+++ Inputs/PRN2/module.modulemap    (revision 0)
@@ -0,0 +1,4 @@
+module M {
+  header "FirstHeader.h"
+  export *
+}
Index: Inputs/PRN2/FirstHeader.h
===================================================================
--- Inputs/PRN2/FirstHeader.h    (revision 0)
+++ Inputs/PRN2/FirstHeader.h    (revision 0)
@@ -0,0 +1,14 @@
+template<class Element> struct TMatrixT;
+typedef TMatrixT<double> TMatrixD;
+
+void f(const TMatrixD &m);
+
+template<class Element> struct TMatrixT {
+   template <class Element2> TMatrixT(const TMatrixT<Element2> &);
+   ~TMatrixT() {}
+   void Determinant () { f(*this); }
+
+};
+
+template struct TMatrixT<float>;
+template struct TMatrixT<double>;
Index: prN2.cpp
===================================================================
--- prN2.cpp    (revision 0)
+++ prN2.cpp    (revision 0)
@@ -0,0 +1,4 @@
+// RUN: rm -rf %t
+// RUN: %clang -fmodules -fmodules-cache-path=%t -x c++ %s
+
+#include "Inputs/PRN2/FirstHeader.h"


// Crash:

/home/vvassilev/workspace/llvm/obj/Debug+Asserts/bin/clang -fmodules
-fmodules-cache-path=/home/vvassilev/workspace/llvm/obj/tools/clang/test/Modules/Output/prN2.cpp.tmp
-x c++ /home/vvassilev/workspace/llvm/src/tools/clang/test/Modules/prN2.cpp
While deleting: void (%struct.TMatrixT.0*)* %
An asserting value handle still pointed to this value!
UNREACHABLE executed at
/home/vvassilev/workspace/llvm/src/lib/IR/Value.cpp:765!
0  clang           0x000000000393ad7e llvm::sys::PrintStackTrace(_IO_FILE*) +
46
1  clang           0x000000000393bb3b
2  clang           0x000000000393de34
3  libpthread.so.0 0x00007f1acdea1cb0
4  libc.so.6       0x00007f1acccb70d5 gsignal + 53
5  libc.so.6       0x00007f1acccba83b abort + 379
6  clang           0x000000000391c8f6
7  clang           0x00000000038c20fc
llvm::ValueHandleBase::ValueIsDeleted(llvm::Value*) + 716
8  clang           0x00000000038c1c9c llvm::Value::~Value() + 60
9  clang           0x00000000036653b8
10 clang           0x0000000003665355
11 clang           0x000000000385ee7b
12 clang           0x000000000377efe1
13 clang           0x000000000377ec16 llvm::Function::~Function() + 246
14 clang           0x000000000377eb09 llvm::Function::~Function() + 25
15 clang           0x0000000002864dfe
16 clang           0x0000000002864588
17 clang           0x000000000377db35 llvm::Function::eraseFromParent() + 69
18 clang           0x0000000000e8dd1a
19 clang           0x0000000000e8d770
20 clang           0x0000000000dc338b
clang::CodeGen::CodeGenModule::EmitGlobalDefinition(clang::GlobalDecl,
llvm::GlobalValue*) + 491
21 clang           0x0000000000dc581c
clang::CodeGen::CodeGenModule::EmitGlobal(clang::GlobalDecl) + 876
22 clang           0x0000000000e89ed0
23 clang           0x0000000000dc8faf
clang::CodeGen::CodeGenModule::EmitTopLevelDecl(clang::Decl*) + 847
24 clang           0x0000000000d1f00d
25 clang           0x0000000000d06b48
26 clang           0x00000000023c7d87
clang::ASTConsumer::HandleInterestingDecl(clang::DeclGroupRef) + 55
27 clang           0x0000000000b97a81
clang::ASTReader::PassInterestingDeclToConsumer(clang::Decl*) + 129
28 clang           0x0000000000b978c6
clang::ASTReader::PassInterestingDeclsToConsumer() + 214
29 clang           0x0000000000ba4c82 clang::ASTReader::FinishedDeserializing()
+ 178
30 clang           0x0000000000ba4cac non-virtual thunk to
clang::ASTReader::FinishedDeserializing() + 28
31 clang           0x0000000000b6f92c
32 clang           0x0000000000c1c3f1 clang::ASTReader::ReadDeclRecord(unsigned
int) + 4289
33 clang           0x0000000000b8775c clang::ASTReader::GetDecl(unsigned int) +
188
34 clang           0x0000000000b97ce3
clang::ASTReader::StartTranslationUnit(clang::ASTConsumer*) + 131
35 clang           0x0000000000b97d4f non-virtual thunk to
clang::ASTReader::StartTranslationUnit(clang::ASTConsumer*) + 47
36 clang           0x0000000001038229 clang::ParseAST(clang::Sema&, bool, bool)
+ 313
37 clang           0x00000000009a6cb9 clang::ASTFrontendAction::ExecuteAction()
+ 345
38 clang           0x0000000000d063c7 clang::CodeGenAction::ExecuteAction() +
1527
39 clang           0x00000000009a64c8 clang::FrontendAction::Execute() + 120
40 clang           0x0000000000962ad8
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 824
41 clang           0x0000000000919b17
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1063
42 clang           0x0000000000902245 cc1_main(llvm::ArrayRef<char const*>,
char const*, void*) + 741
43 clang           0x0000000000911c3b
44 clang           0x0000000000910d14 main + 1028
45 libc.so.6       0x00007f1accca276d __libc_start_main + 237
46 clang           0x0000000000901609
Stack dump:
0.    Program arguments:
/home/vvassilev/workspace/llvm/obj/Debug+Asserts/bin/clang -cc1 -triple
x86_64-unknown-linux-gnu -emit-obj -mrelax-all -disable-free -main-file-name
prN2.cpp -mrelocation-model static -mthread-model posix -mdisable-fp-elim
-fmath-errno -masm-verbose -mconstructor-aliases -munwind-tables
-fuse-init-array -target-cpu x86-64 -target-linker-version 2.22
-dwarf-column-info -resource-dir
/home/vvassilev/workspace/llvm/obj/Debug+Asserts/bin/../lib/clang/3.6.0
-internal-isystem /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8
-internal-isystem
/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/x86_64-linux-gnu/c++/4.8
-internal-isystem
/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/x86_64-linux-gnu/c++/4.8
-internal-isystem
/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/backward
-internal-isystem /usr/local/include -internal-isystem
/home/vvassilev/workspace/llvm/obj/Debug+Asserts/bin/../lib/clang/3.6.0/include
-internal-externc-isystem /usr/include/x86_64-linux-gnu
-internal-externc-isystem /include -internal-externc-isystem /usr/include
-fdeprecated-macro -fdebug-compilation-dir
/home/vvassilev/workspace/llvm/obj/tools/clang -ferror-limit 19
-fmessage-length 178 -mstackrealign -fmodules
-fmodules-cache-path=/home/vvassilev/workspace/llvm/obj/tools/clang/test/Modules/Output/prN2.cpp.tmp
-fobjc-runtime=gcc -fcxx-exceptions -fexceptions -fdiagnostics-show-option
-fcolor-diagnostics -o /tmp/prN2-74f79e.o -x c++
/home/vvassilev/workspace/llvm/src/tools/clang/test/Modules/prN2.cpp 
1.    /home/vvassilev/workspace/llvm/src/tools/clang/test/Modules/prN2.cpp:4:1:
at annotation token
2.   
/home/vvassilev/workspace/llvm/src/tools/clang/test/Modules/Inputs/PRN2/FirstHeader.h:8:4:
LLVM IR generation of declaration 'TMatrixT<double>::~TMatrixT'
3.   
/home/vvassilev/workspace/llvm/src/tools/clang/test/Modules/Inputs/PRN2/FirstHeader.h:8:4:
Generating code for declaration 'TMatrixT<double>::~TMatrixT'

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

From bugzilla-daemon at llvm.org  Wed Nov 12 07:48:51 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 12 Nov 2014 15:48:51 +0000
Subject: [LLVMbugs] [Bug 21546] Cannot mark lambda operator() as noreturn
In-Reply-To: <bug-21546-206@http.llvm.org/bugs/>
References: <bug-21546-206@http.llvm.org/bugs/>
Message-ID: <bug-21546-206-MSWv3qsVJ1@http.llvm.org/bugs/>

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

Gonzalo BG <gonzalobg88 at gmail.com> changed:

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

--- Comment #2 from Gonzalo BG <gonzalobg88 at gmail.com> ---
As of this answer, this is not a bug and clang is doing the right thing:
http://stackoverflow.com/a/26890547/1422197

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

From bugzilla-daemon at llvm.org  Wed Nov 12 08:03:37 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 12 Nov 2014 16:03:37 +0000
Subject: [LLVMbugs] [Bug 20243] [X86] Call to __tls_get_addr makes the
 function non-leaf after it was determined to be a leaf
In-Reply-To: <bug-20243-206@http.llvm.org/bugs/>
References: <bug-20243-206@http.llvm.org/bugs/>
Message-ID: <bug-20243-206-tSUA2j1USE@http.llvm.org/bugs/>

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

Dario Domizioli <dario.domizioli at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED
           Assignee|unassignedbugs at nondot.org   |dario.domizioli at gmail.com

--- Comment #1 from Dario Domizioli <dario.domizioli at gmail.com> ---

Fixed by r221695.

The ISel lowering creating the pseudo-instruction corresponding to the call to
__tls_get_addr now informs the MachineFrameInfo that the function has calls and
therefore is not a leaf.

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

From bugzilla-daemon at llvm.org  Wed Nov 12 10:53:54 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 12 Nov 2014 18:53:54 +0000
Subject: [LLVMbugs] [Bug 21548] New: Assertion failed: (!VT.isSimple() ||
 (unsigned)VT.getSimpleVT().SimpleTy < array_lengthof(RegClassForVT)),
 function isTypeLegal
Message-ID: <bug-21548-206@http.llvm.org/bugs/>

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

            Bug ID: 21548
           Summary: Assertion failed: (!VT.isSimple() ||
                    (unsigned)VT.getSimpleVT().SimpleTy <
                    array_lengthof(RegClassForVT)), function isTypeLegal
           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: grosbach at apple.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 13326
  --> http://llvm.org/bugs/attachment.cgi?id=13326&action=edit
testcase from llvm-stress

CodeGenPrepare tries to sink shift and truncate instructions into the basic
block of their users heuristically. It fails, however, in the case of a
truncate to i1 which is then fed into a select of pointers.

  %Tr = trunc i32 %B to i1
...
  %Sl54 = select i1 %Tr, i64* %A1, i64* %2

The check in SinkShiftAndTruncate() for CodeGenPrepare.cpp calls:
if (TLI.isOperationLegalOrCustom(ISDOpcode, EVT::getEVT(TruncUser->getType(),
true)))

When the type is iPTR, that check goes badly (at least for AArch64). There's
even a relevant FIXME right above which is related.
    // If the use is actually a legal node, there will not be an                
    // implicit truncate.                                                       
    // FIXME: always querying the result type is just an                        
    // approximation; some nodes' legality is determined by the                 
    // operand or other means. There's no good way to find out though.


Either that conditional needs to handle SELECT directly (likely, since the
result type is unrelated to the heuristic when the operand from the trunc is
the conditional) and/or the lower level isTypeLegal() check should know what to
do with iPTR.

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

From bugzilla-daemon at llvm.org  Wed Nov 12 11:18:50 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 12 Nov 2014 19:18:50 +0000
Subject: [LLVMbugs] [Bug 21549] New: Assertion failed: (Op.getValueType() ==
 MVT::f16 && "Inconsistent bitcast? Only 16-bit types should be i16 or f16"),
 function ReplaceBITCASTResults
Message-ID: <bug-21549-206@http.llvm.org/bugs/>

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

            Bug ID: 21549
           Summary: Assertion failed: (Op.getValueType() == MVT::f16 &&
                    "Inconsistent bitcast? Only 16-bit types should be i16
                    or f16"), function ReplaceBITCASTResults
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: AArch64
          Assignee: unassignedbugs at nondot.org
          Reporter: grosbach at apple.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

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

Vector types that end up 16-bits in size break that assertion.

(lldb) p N->dumpr()
0x104ccdc08: i16 = bitcast [ORD=3] [ID=0] 0x104ccdb00
  0x104ccdb00: v16i1 = vector_shuffle<0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0> [ORD=3]
[ID=-3] 0x104ccd8f0, 0x10404af18: v16i1 = undef [ID=-3]

Context is:

static void ReplaceBITCASTResults(SDNode *N, SmallVectorImpl<SDValue> &Results, 
                                  SelectionDAG &DAG) {                          
  if (N->getValueType(0) != MVT::i16)                                           
    return;                                                                     

  SDLoc DL(N);                                                                  
  SDValue Op = N->getOperand(0);                                                
  assert(Op.getValueType() == MVT::f16 &&                                       
         "Inconsistent bitcast? Only 16-bit types should be i16 or f16");       
  Op = SDValue(                                                                 
      DAG.getMachineNode(TargetOpcode::INSERT_SUBREG, DL, MVT::f32,             
                         DAG.getUNDEF(MVT::i32), Op,                            
                         DAG.getTargetConstant(AArch64::hsub, MVT::i32)),       
      0);                                                                       
  Op = DAG.getNode(ISD::BITCAST, DL, MVT::i32, Op);                             
  Results.push_back(DAG.getNode(ISD::TRUNCATE, DL, MVT::i16, Op));              
}

Using an insert_subreg w/ a vector type (especially a non-legal one like v16i1)
is likely to go extremely poorly. Somewhere earlier we've done some custom
lowering that results in this bitcast. Either that code shouldn't be doing that
at all (likely) or this code needs to know how to deal with vectors that end up
16 bits in size. One could probably construct a testcase from v2i8 here as well
to avoid the oddness of vectors of i1.

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

From bugzilla-daemon at llvm.org  Wed Nov 12 11:55:55 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 12 Nov 2014 19:55:55 +0000
Subject: [LLVMbugs] [Bug 19031] Small testcase uses extreme amount of memory
 if compiled with -g and -mrelocation-model static
In-Reply-To: <bug-19031-206@http.llvm.org/bugs/>
References: <bug-19031-206@http.llvm.org/bugs/>
Message-ID: <bug-19031-206-P2FTwHYelz@http.llvm.org/bugs/>

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

Dimitry Andric <dimitry at andric.com> changed:

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

--- Comment #3 from Dimitry Andric <dimitry at andric.com> ---
Fixed by r221709, similar to bug 20893.

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

From bugzilla-daemon at llvm.org  Wed Nov 12 12:21:02 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 12 Nov 2014 20:21:02 +0000
Subject: [LLVMbugs] [Bug 21403] Assertion "Dangling pointers found in call
 sites map" with -ffast-math and __builtin_sqrtf
In-Reply-To: <bug-21403-206@http.llvm.org/bugs/>
References: <bug-21403-206@http.llvm.org/bugs/>
Message-ID: <bug-21403-206-bhYBq5m7EN@http.llvm.org/bugs/>

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

Sanjay Patel <spatel+llvm at rotateright.com> changed:

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

--- Comment #12 from Sanjay Patel <spatel+llvm at rotateright.com> ---
Should be fixed with:
http://reviews.llvm.org/rL221802

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

From bugzilla-daemon at llvm.org  Wed Nov 12 14:08:26 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 12 Nov 2014 22:08:26 +0000
Subject: [LLVMbugs] [Bug 21385] optimize reciprocals with fast-math (x86)
In-Reply-To: <bug-21385-206@http.llvm.org/bugs/>
References: <bug-21385-206@http.llvm.org/bugs/>
Message-ID: <bug-21385-206-3WTe7RFKHf@http.llvm.org/bugs/>

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

Sanjay Patel <spatel+llvm at rotateright.com> changed:

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

--- Comment #19 from Sanjay Patel <spatel+llvm at rotateright.com> ---
Refinement accuracy made configurable via cl::opt:
http://llvm.org/viewvc/llvm-project?view=revision&revision=221819

With that, I think we can resolve this bug as fixed.

The customer can control generation of rcpps/rcpss with "-use-recip-est" and
control the speed vs. accuracy trade-off with "-x86-recip-refinement-steps".

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

From bugzilla-daemon at llvm.org  Wed Nov 12 14:18:18 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 12 Nov 2014 22:18:18 +0000
Subject: [LLVMbugs] [Bug 21548] Assertion failed: (!VT.isSimple() ||
 (unsigned)VT.getSimpleVT().SimpleTy < array_lengthof(RegClassForVT)),
 function isTypeLegal
In-Reply-To: <bug-21548-206@http.llvm.org/bugs/>
References: <bug-21548-206@http.llvm.org/bugs/>
Message-ID: <bug-21548-206-468xDpXqNg@http.llvm.org/bugs/>

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

Ahmed Bougacha <ahmed.bougacha at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
           See Also|                            |http://llvm.org/bugs/show_b
                   |                            |ug.cgi?id=20474
         Resolution|---                         |FIXED

--- Comment #2 from Ahmed Bougacha <ahmed.bougacha at gmail.com> ---
I went ahead and committed r221820.

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

From bugzilla-daemon at llvm.org  Wed Nov 12 15:05:33 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 12 Nov 2014 23:05:33 +0000
Subject: [LLVMbugs] [Bug 21518] addvsi3 & subvsi3 don't trap when they should
In-Reply-To: <bug-21518-206@http.llvm.org/bugs/>
References: <bug-21518-206@http.llvm.org/bugs/>
Message-ID: <bug-21518-206-hNWC6EDYc1@http.llvm.org/bugs/>

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

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

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

--- Comment #1 from Bob Wilson <bob.wilson at apple.com> ---
I asked Steve Canon and Duncan Exon Smith to review the patch. The only
question that came up was whether the code with the patch still has undefined
behavior. Tim Northover pointed out that according to C99 6.3.1.3p3,
overflowing unsigned to signed conversion is implementation defined, not
undefined, behavior. Since compiler-rt is part of the compiler and we control
the implementation, that should be OK.

I've committed the patch as r221826.

(This was tracked internally as rdar://problem/18924081.)

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

From bugzilla-daemon at llvm.org  Wed Nov 12 15:43:54 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 12 Nov 2014 23:43:54 +0000
Subject: [LLVMbugs] [Bug 19372] assertion "Replacement.isCanonical() &&
 "replacement types must always be canonical""
In-Reply-To: <bug-19372-206@http.llvm.org/bugs/>
References: <bug-19372-206@http.llvm.org/bugs/>
Message-ID: <bug-19372-206-kTny0ECxCd@http.llvm.org/bugs/>

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

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

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

--- Comment #8 from Richard Smith <richard-llvm at metafoo.co.uk> ---
Fixed in r221832.

And now I understand the problem, here's a simpler reducer:

template<typename...> struct S;
template<typename ...A> using X = S<A...>;
template<typename ...A> using Y = X<A..., A...>;

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

From bugzilla-daemon at llvm.org  Wed Nov 12 16:19:38 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 13 Nov 2014 00:19:38 +0000
Subject: [LLVMbugs] [Bug 21482] dependency-dump.m fails with super-long
	pathname
In-Reply-To: <bug-21482-206@http.llvm.org/bugs/>
References: <bug-21482-206@http.llvm.org/bugs/>
Message-ID: <bug-21482-206-r2X7Iiey2a@http.llvm.org/bugs/>

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

Paul Robinson <paul_robinson at playstation.sony.com> changed:

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

--- Comment #4 from Paul Robinson <paul_robinson at playstation.sony.com> ---
Support/Windows/Path.inc fixed in r221841.  This solves my original problem.

Reid Kleckner pointed out that other parts of Support handle path names
independently, and these could also be taught to use the special Windows
prefix '\\?\'.  I'll leave that for another task, and close 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/20141113/3422a4be/attachment.html>

From bugzilla-daemon at llvm.org  Wed Nov 12 16:53:18 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 13 Nov 2014 00:53:18 +0000
Subject: [LLVMbugs] [Bug 21268] CMake build doesn't set HOST_LINK_VERSION
In-Reply-To: <bug-21268-206@http.llvm.org/bugs/>
References: <bug-21268-206@http.llvm.org/bugs/>
Message-ID: <bug-21268-206-aMxUfcpjft@http.llvm.org/bugs/>

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

Hans Wennborg <hans at chromium.org> changed:

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

--- Comment #1 from Hans Wennborg <hans at chromium.org> ---
Fixed in r221844.

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

From bugzilla-daemon at llvm.org  Wed Nov 12 17:24:59 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 13 Nov 2014 01:24:59 +0000
Subject: [LLVMbugs] [Bug 21551] New: ptx backend is producing invalid code
	for me
Message-ID: <bug-21551-206@http.llvm.org/bugs/>

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

            Bug ID: 21551
           Summary: ptx backend is producing invalid code for me
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: PTX
          Assignee: unassignedbugs at nondot.org
          Reporter: ryan.burn at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 13329
  --> http://llvm.org/bugs/attachment.cgi?id=13329&action=edit
kernel file i'm running on

when I run "llc -mcpu=sm_35 kernel.ll -o kernel.ptx" on the attached LLVM IR,
the resulting ptx code is invalid. I get the following error when running ptxas
on it.

$ptxas -arch=sm_35 kernel.ptx 
ptxas kernel.ptx, line 9; fatal   : Parsing error near 'satyr_kernel': syntax
error
ptxas fatal   : Ptx assembly aborted due to errors

attached kernel.ll and kernel.ptx

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

From bugzilla-daemon at llvm.org  Wed Nov 12 17:39:20 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 13 Nov 2014 01:39:20 +0000
Subject: [LLVMbugs] [Bug 21552] New: Bindings/Go/go.test fails when there's
 no c++11-capable compiler in the environment
Message-ID: <bug-21552-206@http.llvm.org/bugs/>

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

            Bug ID: 21552
           Summary: Bindings/Go/go.test fails when there's no
                    c++11-capable compiler in the environment
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Core LLVM classes
          Assignee: unassignedbugs at nondot.org
          Reporter: hans at chromium.org
                CC: llvmbugs at cs.uiuc.edu, nicolasweber at gmx.de,
                    peter at pcc.me.uk
    Classification: Unclassified

Bindings/Go/go.test fails on my machine when running in an environment that
doesn't have a C++11-capable compiler on PATH.

>From what I understand, the test runs cmake, inputs flags based on llvm-flags
and then tries to build parts of LLVM, which seems a little brittle.




FAIL: LLVM :: Bindings/Go/go.test (15805 of 19507)
******************** TEST 'LLVM :: Bindings/Go/go.test' FAILED
********************
Script:
--
cd
/usr/local/google/work/chromium/src/third_party/llvm/test/Bindings/Go/../../../bindings/go/llvm
&&  env
CGO_CPPFLAGS="$(/work/chromium/src/third_party/llvm-build/Release+Asserts/./bin/llvm-config
--cppflags)"      CGO_CXXFLAGS=-std=c++11     
CGO_LDFLAGS="$(/work/chromium/src/third_party/llvm-build/Release+Asserts/./bin/llvm-config
--ldflags --libs --system-libs                                 $(../build.sh
--print-components)) $CGO_LDFLAGS"      /usr/lib/google-golang/bin/go test
-tags byollvm .
--
Exit Code: 2

Command Output (stdout):
--
FAIL    _/usr/local/google/work/chromium/src/third_party/llvm/bindings/go/llvm
[build failed]

--
Command Output (stderr):
--
+ llvm_components='all-targets analysis asmparser asmprinter bitreader
bitwriter codegen core debuginfo executionengine instrumentation interpreter
ipo irreader linker mc mcjit objcarcopts option profiledata scalaropts support
target '
+ '[' --print-components = --print-components ']'
+ echo all-targets analysis asmparser asmprinter bitreader bitwriter codegen
core debuginfo executionengine instrumentation interpreter ipo irreader linker
mc mcjit objcarcopts option profiledata scalaropts support target
+ exit 0
# _/usr/local/google/work/chromium/src/third_party/llvm/bindings/go/llvm
/work/chromium/src/third_party/llvm-build/Release+Asserts/lib/libLLVMMCJIT.a(MCJIT.cpp.o):/work/chromium/src/third_party/llvm/lib/ExecutionEngine/MCJIT/MCJIT.cpp:function
llvm::LinkingMemoryManager::getSymbolAddress(std::string const&): error:
undefined reference to 'std::__throw_out_of_range_fmt(char const*, ...)'
/work/chromium/src/third_party/llvm-build/Release+Asserts/lib/libLLVMX86CodeGen.a(X86ISelLowering.cpp.o):/work/chromium/src/third_party/llvm/lib/Target/X86/X86ISelLowering.cpp:function
llvm::X86TargetLowering::LowerVECTOR_SHUFFLE(llvm::SDValue,
llvm::SelectionDAG&) const: error: undefined reference to
'std::__throw_out_of_range_fmt(char const*, ...)'
/work/chromium/src/third_party/llvm-build/Release+Asserts/lib/libLLVMAsmPrinter.a(DwarfDebug.cpp.o):/work/chromium/src/third_party/llvm/lib/CodeGen/AsmPrinter/DwarfDebug.cpp:function
llvm::LexicalScopes::LexicalScopes(): error: undefined reference to
'std::__detail::_Prime_rehash_policy::_M_next_bkt(unsigned long) const'
/work/chromium/src/third_party/llvm-build/Release+Asserts/lib/libLLVMAsmPrinter.a(DwarfDebug.cpp.o):/work/chromium/src/third_party/llvm/lib/CodeGen/AsmPrinter/DwarfDebug.cpp:function
llvm::LexicalScopes::LexicalScopes(): error: undefined reference to
'std::__detail::_Prime_rehash_policy::_M_next_bkt(unsigned long) const'
/work/chromium/src/third_party/llvm-build/Release+Asserts/lib/libLLVMAsmPrinter.a(DwarfDebug.cpp.o):/work/chromium/src/third_party/llvm/lib/CodeGen/AsmPrinter/DwarfDebug.cpp:function
llvm::LexicalScopes::LexicalScopes(): error: undefined reference to
'std::__detail::_Prime_rehash_policy::_M_next_bkt(unsigned long) const'
/work/chromium/src/third_party/llvm-build/Release+Asserts/lib/libLLVMAsmPrinter.a(WinCodeViewLineTables.cpp.o):/work/chromium/src/third_party/llvm/lib/CodeGen/AsmPrinter/WinCodeViewLineTables.cpp:function
llvm::WinCodeViewLineTables::getFullFilepath(llvm::MDNode const*): error:
undefined reference to 'std::__throw_out_of_range_fmt(char const*, ...)'
/work/chromium/src/third_party/llvm-build/Release+Asserts/lib/libLLVMAsmPrinter.a(WinCodeViewLineTables.cpp.o):/work/chromium/src/third_party/llvm/lib/CodeGen/AsmPrinter/WinCodeViewLineTables.cpp:function
llvm::WinCodeViewLineTables::getFullFilepath(llvm::MDNode const*): error:
undefined reference to 'std::__throw_out_of_range_fmt(char const*, ...)'
/work/chromium/src/third_party/llvm-build/Release+Asserts/lib/libLLVMCodeGen.a(LexicalScopes.cpp.o):/work/chromium/src/third_party/llvm/lib/CodeGen/LexicalScopes.cpp:function
_ZNSt10_HashtableIPKN4llvm6MDNodeESt4pairIKS3_NS0_12LexicalScopeEESaIS7_ENSt8__detail10_Select1stESt8equal_toIS3_ESt4hashIS3_ENS9_18_Mod_range_hashingENS9_20_Default_ranged_hashENS9_20_Prime_rehash_policyENS9_17_Hashtable_traitsILb0ELb0ELb1EEEE10_M_emplaceIJRKSt21piecewise_construct_tSt5tupleIJRNS0_12DIDescriptorEEESP_IJRPS6_SR_ODnObEEEEES4_INS9_14_Node_iteratorIS7_Lb0ELb0EEEbESt17integral_constantIbLb1EEDpOT_:
error: undefined reference to
'std::__detail::_Prime_rehash_policy::_M_need_rehash(unsigned long, unsigned
long, unsigned long) const'
/work/chromium/src/third_party/llvm-build/Release+Asserts/lib/libLLVMCodeGen.a(LexicalScopes.cpp.o):/work/chromium/src/third_party/llvm/lib/CodeGen/LexicalScopes.cpp:function
_ZNSt10_HashtableISt4pairIPKN4llvm6MDNodeES4_ES0_IKS5_NS1_12LexicalScopeEESaIS8_ENSt8__detail10_Select1stESt8equal_toIS5_ENS1_9pair_hashIS4_S4_EENSA_18_Mod_range_hashingENSA_20_Default_ranged_hashENSA_20_Prime_rehash_policyENSA_17_Hashtable_traitsILb1ELb0ELb1EEEE10_M_emplaceIJRKSt21piecewise_construct_tSt5tupleIJS5_EESQ_IJPS7_NS1_14DILexicalBlockEPS2_bEEEEES0_INSA_14_Node_iteratorIS8_Lb0ELb1EEEbESt17integral_constantIbLb1EEDpOT_:
error: undefined reference to
'std::__detail::_Prime_rehash_policy::_M_need_rehash(unsigned long, unsigned
long, unsigned long) const'
/work/chromium/src/third_party/llvm-build/Release+Asserts/lib/libLLVMCodeGen.a(LexicalScopes.cpp.o):/work/chromium/src/third_party/llvm/lib/CodeGen/LexicalScopes.cpp:function
_ZNSt10_HashtableIPKN4llvm6MDNodeESt4pairIKS3_NS0_12LexicalScopeEESaIS7_ENSt8__detail10_Select1stESt8equal_toIS3_ESt4hashIS3_ENS9_18_Mod_range_hashingENS9_20_Default_ranged_hashENS9_20_Prime_rehash_policyENS9_17_Hashtable_traitsILb0ELb0ELb1EEEE10_M_emplaceIJRKSt21piecewise_construct_tSt5tupleIJPS1_EESP_IJPS6_NS0_12DIDescriptorEDnbEEEEES4_INS9_14_Node_iteratorIS7_Lb0ELb0EEEbESt17integral_constantIbLb1EEDpOT_:
error: undefined reference to
'std::__detail::_Prime_rehash_policy::_M_need_rehash(unsigned long, unsigned
long, unsigned long) const'
clang-3.6: error: linker command failed with exit code 1 (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/20141113/5d24dc05/attachment.html>

From bugzilla-daemon at llvm.org  Wed Nov 12 19:19:23 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 13 Nov 2014 03:19:23 +0000
Subject: [LLVMbugs] [Bug 21554] New: clang doesn't apply proper calling
 conventions when using spir as target
Message-ID: <bug-21554-206@http.llvm.org/bugs/>

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

            Bug ID: 21554
           Summary: clang doesn't apply proper calling conventions when
                    using spir as target
           Product: clang
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: LLVM Codegen
          Assignee: unassignedclangbugs at nondot.org
          Reporter: ryan.burn at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 13331
  --> http://llvm.org/bugs/attachment.cgi?id=13331&action=edit
fix for problem

when compiling an .cl file with spir as the target using a command like

clang -cc1 -emit-llvm-bc -triple spir64-unknown-unknown -cl-kernel-arg-info
-fno-builtin add.cl

the kernel misses the required "spir_kernel" calling convention specifier

I attached a patch from https://github.com/KhronosGroup/SPIR for the file

llvm/tools/clang/lib/CodeGen/TargetInfo.cpp

that will fix he 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/20141113/ea083218/attachment.html>

From bugzilla-daemon at llvm.org  Wed Nov 12 19:32:32 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 13 Nov 2014 03:32:32 +0000
Subject: [LLVMbugs] [Bug 21555] New: "-cl-kernel-arg-info" option does not
 work correctly when compiling with spir as target
Message-ID: <bug-21555-206@http.llvm.org/bugs/>

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

            Bug ID: 21555
           Summary: "-cl-kernel-arg-info" option does not work correctly
                    when compiling with spir as target
           Product: clang
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: LLVM Codegen
          Assignee: unassignedclangbugs at nondot.org
          Reporter: ryan.burn at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 13332
  --> http://llvm.org/bugs/attachment.cgi?id=13332&action=edit
with "-cl-kernel-arg-info" option

>From the spir specification section 2.4:

"""
These objects are gen- erated for every kernel, with an exception for the
kernel_arg_name metadata, which is generated only when the -cl-kernel-arg-info
build option is specified for compilation.
"""

The argument is only mean to omit the metadata for the "kernel_arg_name" node,
yet it omits the metadata for all many of the other metadata nodes (like
"kernel_arg_type")

I attached the files add.ll and add-no-arg-info.ll that show 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/20141113/09ee7bf8/attachment.html>

From bugzilla-daemon at llvm.org  Wed Nov 12 20:53:05 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 13 Nov 2014 04:53:05 +0000
Subject: [LLVMbugs] [Bug 21556] New: Comparison between new pointer and
 stack address not optimized away.
Message-ID: <bug-21556-206@http.llvm.org/bugs/>

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

            Bug ID: 21556
           Summary: Comparison between new pointer and stack address not
                    optimized away.
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Scalar Optimizations
          Assignee: unassignedbugs at nondot.org
          Reporter: jmuizelaar at mozilla.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

The following code compiles to code with a conditional branch which should be
possible to optimize away.

void p()
{
        int *mData;
        int mStackData[10];
        mData = new int[12];
        if (mData != mStackData) {
                delete[] mData;
        }
}

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

From bugzilla-daemon at llvm.org  Wed Nov 12 23:26:51 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 13 Nov 2014 07:26:51 +0000
Subject: [LLVMbugs] [Bug 21557] New: "getVRegDef assumes a single definition
 or no definition" cause by FastIsel
Message-ID: <bug-21557-206@http.llvm.org/bugs/>

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

            Bug ID: 21557
           Summary: "getVRegDef assumes a single definition or no
                    definition" cause by FastIsel
           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: kfischer at college.harvard.edu
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 13335
  --> http://llvm.org/bugs/attachment.cgi?id=13335&action=edit
Reproducing bitcode

The attached bitcode crashes `llc -fast-isel` on trunk. 

Stack trace is as follows:

```
ssertion failed: ((I.atEnd() || std::next(I) == def_instr_end()) && "getVRegDef
assumes a single definition or no definition"), function getVRegDef, file
/Users/kfischer/julia/deps/llvm-svn/lib/CodeGen/MachineRegisterInfo.cpp, line
306.
0  libLLVM-3.6svn.dylib     0x000000010deda42e
llvm::sys::PrintStackTrace(__sFILE*) + 46
1  libLLVM-3.6svn.dylib     0x000000010dedb7db
PrintStackTraceSignalHandler(void*) + 27
2  libLLVM-3.6svn.dylib     0x000000010dedbc25 SignalHandler(int) + 565
3  libsystem_platform.dylib 0x00007fff99da1f1a _sigtramp + 26
4  libsystem_platform.dylib 0x0000000000000004 _sigtramp + 1713758468
5  libLLVM-3.6svn.dylib     0x000000010dedb80b raise + 27
6  libLLVM-3.6svn.dylib     0x000000010dedb8c2 abort + 18
7  libLLVM-3.6svn.dylib     0x000000010dedb8a1 __assert_rtn + 129
8  libLLVM-3.6svn.dylib     0x000000010d1783d9
llvm::MachineRegisterInfo::getVRegDef(unsigned int) const + 281
9  libLLVM-3.6svn.dylib     0x000000010d0d3211 (anonymous
namespace)::MachineCSE::PerformTrivialCopyPropagation(llvm::MachineInstr*,
llvm::MachineBasicBlock*) + 193
10 libLLVM-3.6svn.dylib     0x000000010d0d2111 (anonymous
namespace)::MachineCSE::ProcessBlock(llvm::MachineBasicBlock*) + 305
11 libLLVM-3.6svn.dylib     0x000000010d0d1e17 (anonymous
namespace)::MachineCSE::PerformCSE(llvm::DomTreeNodeBase<llvm::MachineBasicBlock>*)
+ 583
12 libLLVM-3.6svn.dylib     0x000000010d0d1bb1 (anonymous
namespace)::MachineCSE::runOnMachineFunction(llvm::MachineFunction&) + 209
13 libLLVM-3.6svn.dylib     0x000000010d10fe8e
llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 110
14 libLLVM-3.6svn.dylib     0x000000010d52a3fb
llvm::FPPassManager::runOnFunction(llvm::Function&) + 427
15 libLLVM-3.6svn.dylib     0x000000010d52a708
llvm::FPPassManager::runOnModule(llvm::Module&) + 104
16 libLLVM-3.6svn.dylib     0x000000010d52b114 (anonymous
namespace)::MPPassManager::runOnModule(llvm::Module&) + 1412
17 libLLVM-3.6svn.dylib     0x000000010d52a9be
llvm::legacy::PassManagerImpl::run(llvm::Module&) + 302
18 libLLVM-3.6svn.dylib     0x000000010d52b891
llvm::legacy::PassManager::run(llvm::Module&) + 33
```

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

From bugzilla-daemon at llvm.org  Thu Nov 13 03:55:37 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 13 Nov 2014 11:55:37 +0000
Subject: [LLVMbugs] [Bug 21534] chromium build error on FreeBSD
In-Reply-To: <bug-21534-206@http.llvm.org/bugs/>
References: <bug-21534-206@http.llvm.org/bugs/>
Message-ID: <bug-21534-206-nU19vqZpRq@http.llvm.org/bugs/>

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

Dimitry Andric <dimitry at andric.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |dimitry at andric.com
         Resolution|---                         |WORKSFORME

--- Comment #3 from Dimitry Andric <dimitry at andric.com> ---
Your test case compiles just fine for me on FreeBSD 10.0-RELEASE with clang
3.3, and with all versions of clang that I tried (roughly, a few dozen versions
from 3.3 through 3.4 to the latest trunk).  So I'm closing this as WORKSFORME.

If your crash is consistently repeatable, and your machine is not suffering
from any bad RAM or other hardware issues, please reopen.

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

From bugzilla-daemon at llvm.org  Thu Nov 13 05:48:01 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 13 Nov 2014 13:48:01 +0000
Subject: [LLVMbugs] [Bug 21558] New: Clang halts with -mllvm
 -inline-threshold=10000 option
Message-ID: <bug-21558-206@http.llvm.org/bugs/>

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

            Bug ID: 21558
           Summary: Clang halts with -mllvm -inline-threshold=10000 option
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: lminih at ya.ru
                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/20141113/6d0fdedc/attachment.html>

From bugzilla-daemon at llvm.org  Thu Nov 13 06:56:06 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 13 Nov 2014 14:56:06 +0000
Subject: [LLVMbugs] [Bug 21559] New: Some x86_64 don't run with Cmake on
	FreeBSD
Message-ID: <bug-21559-206@http.llvm.org/bugs/>

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

            Bug ID: 21559
           Summary: Some x86_64 don't run with Cmake on FreeBSD
           Product: Build scripts
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: cmake
          Assignee: unassignedbugs at nondot.org
          Reporter: tstellar at gmail.com
                CC: llvmbugs at cs.uiuc.edu, pasi.parviainen at iki.fi
            Blocks: 15732
    Classification: Unclassified

Better canonicalization or architecture names is need with CMake.  FreeBSD
identifies itself as amd64, but tests expect x86_64.

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

From bugzilla-daemon at llvm.org  Thu Nov 13 07:18:14 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 13 Nov 2014 15:18:14 +0000
Subject: [LLVMbugs] [Bug 21560] New: Add support to cmake for using
 installed versions of LLVM and Clang
Message-ID: <bug-21560-206@http.llvm.org/bugs/>

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

            Bug ID: 21560
           Summary: Add support to cmake for using installed versions of
                    LLVM and Clang
           Product: Build scripts
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: cmake
          Assignee: unassignedbugs at nondot.org
          Reporter: tstellar at gmail.com
                CC: brooks at freebsd.org, dan at su-root.co.uk,
                    llvmbugs at cs.uiuc.edu, rnk at google.com
            Blocks: 15732
    Classification: Unclassified

Cmake should support building Clang against an installed LLVM and LLDB against
an installed LLVM and 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/20141113/d894ab64/attachment.html>

From bugzilla-daemon at llvm.org  Thu Nov 13 07:24:02 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 13 Nov 2014 15:24:02 +0000
Subject: [LLVMbugs] [Bug 21561] New: Update release scripts to use CMake
Message-ID: <bug-21561-206@http.llvm.org/bugs/>

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

            Bug ID: 21561
           Summary: Update release scripts to use CMake
           Product: Build scripts
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: cmake
          Assignee: unassignedbugs at nondot.org
          Reporter: tstellar at gmail.com
                CC: llvmbugs at cs.uiuc.edu
            Blocks: 15732
    Classification: Unclassified

utils/release/test-release.sh is using autoconf.

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

From bugzilla-daemon at llvm.org  Thu Nov 13 07:34:34 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 13 Nov 2014 15:34:34 +0000
Subject: [LLVMbugs] [Bug 21562] New: Add a CMake equivalent for
 make/platform/clang_darwin.mk in compiler_rt
Message-ID: <bug-21562-206@http.llvm.org/bugs/>

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

            Bug ID: 21562
           Summary: Add a CMake equivalent for
                    make/platform/clang_darwin.mk in compiler_rt
           Product: Build scripts
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: cmake
          Assignee: unassignedbugs at nondot.org
          Reporter: tstellar at gmail.com
                CC: bob.wilson at apple.com, llvmbugs at cs.uiuc.edu
            Blocks: 15732
    Classification: Unclassified

clang_darwin.mk is just a makefile, so we may be able to invocate it directly
from CMake rather than trying to duplicate its functionality in CMakeLists.txt

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

From bugzilla-daemon at llvm.org  Thu Nov 13 07:36:01 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 13 Nov 2014 15:36:01 +0000
Subject: [LLVMbugs] [Bug 21563] New: Improve Windows long path name support
Message-ID: <bug-21563-206@http.llvm.org/bugs/>

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

            Bug ID: 21563
           Summary: Improve Windows long path name support
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: Support Libraries
          Assignee: unassignedbugs at nondot.org
          Reporter: paul_robinson at playstation.sony.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

PR21482 (fix in r221841) addressed long path name support in the Path corner
of libSupport.  However there are also some path-name related Windows API calls
in Support/Windows/Program.inc that could benefit from the same treatment.

RedirectIO() should be updated for long path names. The widenPath() function
in Path.inc could be promoted to the path:: namespace for this purpose.

Execute() does various things; the place that handles the actual program name
should be updated for long path names, unless we decide that it would be
stupid to put an executable program in a directory where CMD.EXE couldn't
find it, and therefore in practice is not a problem. The other places that
use UTF8ToUTF16 in that function look like they're not path-related.

I looked at all other calls to UTF8ToUTF16 and they all looked like they
did not need the long-path-name treatment (uses were e.g. file encoding,
or passing environment variable names to Unicode APIs).

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

From bugzilla-daemon at llvm.org  Thu Nov 13 08:28:21 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 13 Nov 2014 16:28:21 +0000
Subject: [LLVMbugs] [Bug 21564] New: 'std::defaultfloat' manipulator seems
 not to be present
Message-ID: <bug-21564-206@http.llvm.org/bugs/>

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

            Bug ID: 21564
           Summary: 'std::defaultfloat' manipulator seems not to be
                    present
           Product: libc++
           Version: 3.4
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: All Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: santilopez01 at gmail.com
                CC: llvmbugs at cs.uiuc.edu, mclow.lists at gmail.com
    Classification: Unclassified

clang++ compiler seems no to find the std::defaultfloat manipulator. I get an
error when trying to compile the following code:

#include <iostream>
using namespace std;

int main()
{
   cout << defaultfloat << 1234;
}

I type the following in the command-line:

 $clang++-3.4 precision_float.cxx -std=c++11 -Wall

And I obtain:

 precision_float.cxx:15:10: error: use of undeclared identifier 'defaultfloat'
        cout << defaultfloat

Am I doing something wrong?

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

From bugzilla-daemon at llvm.org  Thu Nov 13 09:02:59 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 13 Nov 2014 17:02:59 +0000
Subject: [LLVMbugs] [Bug 21564] 'std::defaultfloat' manipulator seems not to
	be present
In-Reply-To: <bug-21564-206@http.llvm.org/bugs/>
References: <bug-21564-206@http.llvm.org/bugs/>
Message-ID: <bug-21564-206-hha5AOYmmf@http.llvm.org/bugs/>

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

Marshall Clow (home) <mclow.lists at gmail.com> changed:

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

--- Comment #2 from Marshall Clow (home) <mclow.lists at gmail.com> ---
After further correspondence with Santiago, it turns out that he's using
libstdc++, not libc++ (and libstdc++ does not implement std::defaultfloat).

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

From bugzilla-daemon at llvm.org  Thu Nov 13 11:15:09 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 13 Nov 2014 19:15:09 +0000
Subject: [LLVMbugs] [Bug 21424] Linker error related to RTTI? for
 -fsanitize=undefined with clang 3.6.0
In-Reply-To: <bug-21424-206@http.llvm.org/bugs/>
References: <bug-21424-206@http.llvm.org/bugs/>
Message-ID: <bug-21424-206-nQmCvLSG4R@http.llvm.org/bugs/>

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

Tobias Markmann <tm at ayena.de> changed:

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

--- Comment #6 from Tobias Markmann <tm at ayena.de> ---
Similar to http://llvm.org/bugs/show_bug.cgi?id=21359 . Sad that compiler +
linker can't inform the user about this 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/20141113/4e3ced6b/attachment.html>

From bugzilla-daemon at llvm.org  Thu Nov 13 12:02:15 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 13 Nov 2014 20:02:15 +0000
Subject: [LLVMbugs] [Bug 21437] Members declared later in a class appear to
 be unavailable in noexcept expressions
In-Reply-To: <bug-21437-206@http.llvm.org/bugs/>
References: <bug-21437-206@http.llvm.org/bugs/>
Message-ID: <bug-21437-206-OkWYeh5C7I@http.llvm.org/bugs/>

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

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 #4 from Richard Smith <richard-llvm at metafoo.co.uk> ---
Fixed in r221918.

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

From bugzilla-daemon at llvm.org  Thu Nov 13 14:10:36 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 13 Nov 2014 22:10:36 +0000
Subject: [LLVMbugs] [Bug 21565] New: r221918 breaks bootstrap on Fedora
	20/x86-64
Message-ID: <bug-21565-206@http.llvm.org/bugs/>

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

            Bug ID: 21565
           Summary: r221918 breaks bootstrap on Fedora 20/x86-64
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
          Assignee: unassignedclangbugs at nondot.org
          Reporter: hjl.tools at gmail.com
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified

On Fedora 20/x86-64, r221918:

773d19cce43a660639a26fca94ca387c2faf4d39 is the first bad commit
commit 773d19cce43a660639a26fca94ca387c2faf4d39
Author: Richard Smith <richard-llvm at metafoo.co.uk>
Date:   Thu Nov 13 20:01:57 2014 +0000

    PR21437, final part of DR1330: delay-parsing of exception-specifications.
This
    is a re-commit of Doug's r154844 (modernized and updated to fit into
current
    Clang).


    git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk at 221918
91177308-0d34-0410-b5e6-96231b3b80d8

caused:

In file included from /export/ssd/git/llvm/lib/Support/Timer.cpp:14:
In file included from /export/ssd/git/llvm/include/llvm/Support/Timer.h:13:
In file included from /export/ssd/git/llvm/include/llvm/ADT/StringRef.h:13:
In file included from
/usr/lib/gcc/x86_64-redhat-linux/4.8.3/../../../../include/c++/4.8.3/algorithm:60:
In file included from
/usr/lib/gcc/x86_64-redhat-linux/4.8.3/../../../../include/c++/4.8.3/utility:70:
/usr/lib/gcc/x86_64-redhat-linux/4.8.3/../../../../include/c++/4.8.3/bits/stl_pair.h:195:37:
error: too many arguments to function call, expected single argument '__p',
have 2 arguments
      noexcept(noexcept(swap(first, __p.first))
                        ~~~~        ^~~~~~~~~
/usr/lib/gcc/x86_64-redhat-linux/4.8.3/../../../../include/c++/4.8.3/bits/stl_pair.h:255:23:
note: in instantiation of exception specification for 'swap' requested here
    noexcept(noexcept(__x.swap(__y)))
                      ^
/usr/lib/gcc/x86_64-redhat-linux/4.8.3/../../../../include/c++/4.8.3/bits/stl_algobase.h:147:7:
note: in instantiation of exception specification for 'swap<llvm::TimeRecord,
std::basic_string<char> >' requested here
      swap(*__a, *__b);
      ^
/usr/lib/gcc/x86_64-redhat-linux/4.8.3/../../../../include/c++/4.8.3/bits/stl_algo.h:88:11:
note: in instantiation of function template specialization
'std::iter_swap<__gnu_cxx::__normal_iterator<std::pair<llvm::TimeRecord,
std::basic_string<char> > *, std::vector<std::pair<llvm::TimeRecord,
std::basic_string<char> >, std::allocator<std::pair<llvm::TimeRecord,
std::basic_string<char> > > > >,
__gnu_cxx::__normal_iterator<std::pair<llvm::TimeRecord,
std::basic_string<char> > *, std::vector<std::pair<llvm::TimeRecord,
std::basic_string<char> >, std::allocator<std::pair<llvm::TimeRecord,
std::basic_string<char> > > > > >' requested here
            std::iter_swap(__result, __b);
                 ^
/usr/lib/gcc/x86_64-redhat-linux/4.8.3/../../../../include/c++/4.8.3/bits/stl_algo.h:2282:12:
note: in instantiation of function template specialization
'std::__move_median_to_first<__gnu_cxx::__normal_iterator<std::pair<llvm::TimeRecord,
std::basic_string<char> > *, std::vector<std::pair<llvm::TimeRecord,
std::basic_string<char> >, std::allocator<std::pair<llvm::TimeRecord,
std::basic_string<char> > > > > >' requested here
      std::__move_median_to_first(__first, __first + 1, __mid, __last - 1);
           ^
/usr/lib/gcc/x86_64-redhat-linux/4.8.3/../../../../include/c++/4.8.3/bits/stl_algo.h:2315:11:
note: in instantiation of function template specialization
'std::__unguarded_partition_pivot<__gnu_cxx::__normal_iterator<std::pair<llvm::TimeRecord,
std::basic_string<char> > *, std::vector<std::pair<llvm::TimeRecord,
std::basic_string<char> >, std::allocator<std::pair<llvm::TimeRecord,
std::basic_string<char> > > > > >' requested here
            std::__unguarded_partition_pivot(__first, __last);
                 ^
/usr/lib/gcc/x86_64-redhat-linux/4.8.3/../../../../include/c++/4.8.3/bits/stl_algo.h:5451:9:
note: in instantiation of function template specialization
'std::__introsort_loop<__gnu_cxx::__normal_iterator<std::pair<llvm::TimeRecord,
std::basic_string<char> > *, std::vector<std::pair<llvm::TimeRecord,
std::basic_string<char> >, std::allocator<std::pair<llvm::TimeRecord,
std::basic_string<char> > > > >, long>' requested here
          std::__introsort_loop(__first, __last,
               ^
/export/ssd/git/llvm/lib/Support/Timer.cpp:316:8: note: in instantiation of
function template specialization
'std::sort<__gnu_cxx::__normal_iterator<std::pair<llvm::TimeRecord,
std::basic_string<char> > *, std::vector<std::pair<llvm::TimeRecord,
std::basic_string<char> >, std::allocator<std::pair<llvm::TimeRecord,
std::basic_string<char> > > > > >' requested here
  std::sort(TimersToPrint.begin(), TimersToPrint.end());
       ^
/usr/lib/gcc/x86_64-redhat-linux/4.8.3/../../../../include/c++/4.8.3/bits/stl_pair.h:193:7:
note: 'swap' declared here
      void
      ^
llvm[4]: Compiling raw_os_ostream.cpp for Release+Asserts build
1 error generated.
make[4]: ***
[/export/build/gnu/llvm-clang-bootstrap/stage2/build-x86_64-linux/lib/Support/Release+Asserts/Timer.o]
Error 1
make[4]: *** Waiting for unfinished jobs....
make[4]: Leaving directory
`/export/build/gnu/llvm-clang-bootstrap/stage2/build-x86_64-linux/lib/Support'
make[3]: *** [all] Error 1
make[3]: Leaving directory `/export/build/gnu/llvm-clang-boot

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

From bugzilla-daemon at llvm.org  Thu Nov 13 14:16:11 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 13 Nov 2014 22:16:11 +0000
Subject: [LLVMbugs] [Bug 21566] New: Crash when stripping debug symbols from
 lazily loaded module
Message-ID: <bug-21566-206@http.llvm.org/bugs/>

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

            Bug ID: 21566
           Summary: Crash when stripping debug symbols from lazily loaded
                    module
           Product: tools
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: extract
          Assignee: unassignedbugs at nondot.org
          Reporter: pete.cooper at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 13342
  --> http://llvm.org/bugs/attachment.cgi?id=13342&action=edit
The original C++ file

Compiling with LLVM and clang r221928, I get a crash if the attached file is
stripped of debug info while being lazily loaded.

Using llvm-extract seems to be the only want to demonstrate a lazy module
loading test right now.  If you patch llvm-extract with the attached patch,
then it will:
- Load the module lazily
- Strip the debug info
- Materialize the function.

Note that I'm calling it with
- clang++ lazy.cpp -o lazy.bc -emit-llvm -c -g
- llvm-extract -rfunc=".*foo" lazy.bc -o ext.bc

This is probably a bug in lazy materialization itself, or perhaps an
unsupported configuration.

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

From bugzilla-daemon at llvm.org  Thu Nov 13 16:38:24 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 14 Nov 2014 00:38:24 +0000
Subject: [LLVMbugs] [Bug 21565] r221918 breaks bootstrap on Fedora 20/x86-64
In-Reply-To: <bug-21565-206@http.llvm.org/bugs/>
References: <bug-21565-206@http.llvm.org/bugs/>
Message-ID: <bug-21565-206-Bq9iG3P9xL@http.llvm.org/bugs/>

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

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

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

--- Comment #1 from Richard Smith <richard-llvm at metafoo.co.uk> ---
OK, so... the libstdc++ code is wrong, with or without DR1330, but we need to
support it. I've added a terrible hack in r221955. Please reopen if that's not
sufficient to get things working 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/20141114/b1a9a634/attachment.html>

From bugzilla-daemon at llvm.org  Thu Nov 13 16:39:52 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 14 Nov 2014 00:39:52 +0000
Subject: [LLVMbugs] [Bug 5053] [windows JIT] incorrect 'frem' behaviour with
	floats
In-Reply-To: <bug-5053-206@http.llvm.org/bugs/>
References: <bug-5053-206@http.llvm.org/bugs/>
Message-ID: <bug-5053-206-bHALC6hoY0@http.llvm.org/bugs/>

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

Swaroop Sridhar <llvm.bugzilla at gmail.com> changed:

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

--- Comment #9 from Swaroop Sridhar <llvm.bugzilla at gmail.com> ---
 r221947 - Fix symbol resolution of floating point libc builtins in MCJIT

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

From bugzilla-daemon at llvm.org  Thu Nov 13 17:03:28 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 14 Nov 2014 01:03:28 +0000
Subject: [LLVMbugs] [Bug 18597] Problem with
 add_llvm_loadable_module/LLVM_LIBRARY_OUTPUT_INTDIR
In-Reply-To: <bug-18597-206@http.llvm.org/bugs/>
References: <bug-18597-206@http.llvm.org/bugs/>
Message-ID: <bug-18597-206-xfzJlcXUfP@http.llvm.org/bugs/>

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

NAKAMURA Takumi <geek4civic at gmail.com> changed:

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

--- Comment #1 from NAKAMURA Takumi <geek4civic at gmail.com> ---
I think r212313 fixed this. Sorry for the delay and inconvenience.

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

From bugzilla-daemon at llvm.org  Thu Nov 13 17:21:32 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 14 Nov 2014 01:21:32 +0000
Subject: [LLVMbugs] [Bug 21568] New: Cannot add rpath
Message-ID: <bug-21568-206@http.llvm.org/bugs/>

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

            Bug ID: 21568
           Summary: Cannot add rpath
           Product: Build scripts
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: cmake
          Assignee: unassignedbugs at nondot.org
          Reporter: sstewartgallus00 at mylangara.bc.ca
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

I need to add a custom rpath to the binaries so that I can build LLVM with a
newer GCC and associated C++ standard libraries (LD_LIBRARY_PATH doesn't work
with some tools because they lose that environment variable.)

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

From bugzilla-daemon at llvm.org  Thu Nov 13 17:23:51 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 14 Nov 2014 01:23:51 +0000
Subject: [LLVMbugs] [Bug 21569] New: Can't `make install prefix=/tmp/llvm'
	with CMake.
Message-ID: <bug-21569-206@http.llvm.org/bugs/>

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

            Bug ID: 21569
           Summary: Can't `make install prefix=/tmp/llvm' with CMake.
           Product: Build scripts
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: cmake
          Assignee: unassignedbugs at nondot.org
          Reporter: sstewartgallus00 at mylangara.bc.ca
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

The bug at http://llvm.org/bugs/show_bug.cgi?id=739 is similar but this bug is
for 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/20141114/482fea10/attachment.html>

From bugzilla-daemon at llvm.org  Thu Nov 13 17:28:08 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 14 Nov 2014 01:28:08 +0000
Subject: [LLVMbugs] [Bug 21570] New: Cannot set default configuration
	options for CMake
Message-ID: <bug-21570-206@http.llvm.org/bugs/>

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

            Bug ID: 21570
           Summary: Cannot set default configuration options for CMake
           Product: Build scripts
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: cmake
          Assignee: unassignedbugs at nondot.org
          Reporter: sstewartgallus00 at mylangara.bc.ca
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

I can set default configuration options for Autotools build systems using
CONFIG_SITE but I cannot do something similar for 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/20141114/03af03fc/attachment.html>

From bugzilla-daemon at llvm.org  Thu Nov 13 17:31:33 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 14 Nov 2014 01:31:33 +0000
Subject: [LLVMbugs] [Bug 21352] Vector lowering: Assertion `isReg() && "This
 is not a register operand!"' failed.
In-Reply-To: <bug-21352-206@http.llvm.org/bugs/>
References: <bug-21352-206@http.llvm.org/bugs/>
Message-ID: <bug-21352-206-rRI7DRk1P3@http.llvm.org/bugs/>

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

Tim Northover <t.p.northover at gmail.com> changed:

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

--- Comment #5 from Tim Northover <t.p.northover at gmail.com> ---
Should be fixed by r221961.

The issue was a stray TargetConstant in a position that's too generic; it
wasn't being selected (using TargetConstant is basically a promise to ISel that
whatever instruction gets generated will be able to cope with that 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/20141114/e5dc5fd2/attachment.html>

From bugzilla-daemon at llvm.org  Thu Nov 13 18:26:12 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 14 Nov 2014 02:26:12 +0000
Subject: [LLVMbugs] [Bug 21569] Can't `make install prefix=/tmp/llvm' with
	CMake.
In-Reply-To: <bug-21569-206@http.llvm.org/bugs/>
References: <bug-21569-206@http.llvm.org/bugs/>
Message-ID: <bug-21569-206-hOQVmW1x2f@http.llvm.org/bugs/>

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

NAKAMURA Takumi <geek4civic at gmail.com> changed:

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

--- Comment #3 from NAKAMURA Takumi <geek4civic at gmail.com> ---
CMake doesn't allow to override install prefix at build time.
You should reconfigure cmake with -DCMAKE_INSTALL_PREFIX.

This is not an issue in our build scripts.

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

From bugzilla-daemon at llvm.org  Thu Nov 13 18:26:12 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 14 Nov 2014 02:26:12 +0000
Subject: [LLVMbugs] [Bug 15732] [META] CMake build equivalent to the
	autotools build
In-Reply-To: <bug-15732-206@http.llvm.org/bugs/>
References: <bug-15732-206@http.llvm.org/bugs/>
Message-ID: <bug-15732-206-f2Ee1rPq2d@http.llvm.org/bugs/>

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

Bug 15732 depends on bug 21569, which changed state.

Bug 21569 Summary: Can't `make install prefix=/tmp/llvm' with CMake.
http://llvm.org/bugs/show_bug.cgi?id=21569

           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/20141114/71c69a78/attachment.html>

From bugzilla-daemon at llvm.org  Thu Nov 13 23:46:12 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 14 Nov 2014 07:46:12 +0000
Subject: [LLVMbugs] [Bug 21571] New: /Zo not supported in visual sutdio 2013
 update 3 and above
Message-ID: <bug-21571-206@http.llvm.org/bugs/>

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

            Bug ID: 21571
           Summary: /Zo not supported in visual sutdio 2013 update 3 and
                    above
           Product: clang
           Version: unspecified
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++11
          Assignee: unassignedclangbugs at nondot.org
          Reporter: jmecosta at gmail.com
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified

"E:\prod\toolkits\toolkits.msbuild" (default target) (1) ->
(BuildToolkits target) ->
  E:\prod\toolkits\toolkits.msbuild(31,9): error :
[Toolkitsx64Release]:clang-cl.exe : error : no such file or directory: '/Zo'
[E:\prod\toolkits\tools\tools.vcxproj]
  E:\prod\toolkits\toolkits.msbuild(31,9): error : [Toolkitsx64Release]: Error
Code: 1.
  E:\prod\toolkits\toolkits.msbuild(31,9): error : ArgumentException: The tasks
array included at least one null element.\r
E:\prod\toolkits\toolkits.msbuild(31,9): error : Parameter name: tasks\r
E:\prod\toolkits\toolkits.msbuild(31,9): error :

    0 Warning(s)
    6 Error(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/20141114/34cb4f0f/attachment.html>

From bugzilla-daemon at llvm.org  Fri Nov 14 04:18:05 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 14 Nov 2014 12:18:05 +0000
Subject: [LLVMbugs] [Bug 21572] New: Vector element count mismatch!
Message-ID: <bug-21572-206@http.llvm.org/bugs/>

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

            Bug ID: 21572
           Summary: Vector element count mismatch!
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: ARM
          Assignee: unassignedbugs at nondot.org
          Reporter: eugeni.stepanov at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

$ cat >1.cc
void f (short *pb, float *pf)
{
    for (int i = 0; i < 8; ++i)
      pb[i] = pf[i] * 2;
}

$ clang++ -cc1 -triple armv7--linux-androideabi -emit-obj -O2 -vectorize-slp
1.cc
clang++: ../lib/CodeGen/SelectionDAG/SelectionDAG.cpp:2877: llvm::SDValue
llvm::SelectionDAG::getNode(unsigned int, llvm::SDLoc, llvm::EVT,
llvm::SDValue): Assertion `(!VT.isVector() || VT.getVectorNumElements() ==
Operand.getValueType().getVectorNumElements()) && "Vector element count
mismatch!"' failed.
0  clang++         0x000000000141d1a8 llvm::sys::PrintStackTrace(_IO_FILE*) +
40
1  clang++         0x000000000141e80b
2  libpthread.so.0 0x00007f1c932f2340
3  libc.so.6       0x00007f1c92519bb9 gsignal + 57
4  libc.so.6       0x00007f1c9251cfc8 abort + 328
5  libc.so.6       0x00007f1c92512a76
6  libc.so.6       0x00007f1c92512b22
7  clang++         0x0000000001725206 llvm::SelectionDAG::getNode(unsigned int,
llvm::SDLoc, llvm::EVT, llvm::SDValue) + 11942
8  clang++         0x00000000008a5667
llvm::ARMTargetLowering::PerformDAGCombine(llvm::SDNode*,
llvm::TargetLowering::DAGCombinerInfo&) const + 22791
9  clang++         0x0000000001697c17
10 clang++         0x00000000016972a4
llvm::SelectionDAG::Combine(llvm::CombineLevel, llvm::AliasAnalysis&,
llvm::CodeGenOpt::Level) + 2324
11 clang++         0x000000000179755e
llvm::SelectionDAGISel::CodeGenAndEmitDAG() + 910
12 clang++         0x0000000001796a18
llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) + 8632
13 clang++         0x0000000001793924
llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) + 1316
14 clang++         0x000000000085ad46
15 clang++         0x0000000000f1eccc
llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 124
16 clang++         0x00000000011468b3
llvm::FPPassManager::runOnFunction(llvm::Function&) + 499
17 clang++         0x0000000001146b2b
llvm::FPPassManager::runOnModule(llvm::Module&) + 43
18 clang++         0x0000000001147087
llvm::legacy::PassManagerImpl::run(llvm::Module&) + 935
19 clang++         0x0000000001844c0d
clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::CodeGenOptions
const&, clang::TargetOptions const&, clang::LangOptions const&,
llvm::StringRef, llvm::Module*, clang::BackendAction, llvm::raw_ostream*) +
7517
20 clang++         0x0000000001839c95
21 clang++         0x0000000001dd46f3 clang::ParseAST(clang::Sema&, bool, bool)
+ 483
22 clang++         0x00000000015bcf3e clang::FrontendAction::Execute() + 62
23 clang++         0x000000000158eacc
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 892
24 clang++         0x0000000001640192
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 3090
25 clang++         0x00000000006c2ca7 cc1_main(llvm::ArrayRef<char const*>,
char const*, void*) + 679
26 clang++         0x00000000006c1a52 main + 12290
27 libc.so.6       0x00007f1c92504ec5 __libc_start_main + 245
28 clang++         0x00000000006be94b
Stack dump:
0.      Program arguments: /code/llvm/build/bin/clang++ -cc1 -triple
armv7--linux-androideabi -emit-obj -O2 -vectorize-slp 1.ii 
1.      <eof> parser at end of file
2.      Code generation
3.      Running pass 'Function Pass Manager' on module '1.ii'.
4.      Running pass 'ARM Instruction Selection' on function '@_Z1fPsPf'


Bitcode:
# cat >1.ll
target datalayout = "e-m:e-p:32:32-i64:64-v128:64:128-a:0:32-n32-S64"
target triple = "armv7--linux-androideabi"

; Function Attrs: nounwind
define void @_Z1fPsPf(i16* nocapture %pb, float* nocapture readonly %pf) #0 {
entry:
  %0 = bitcast float* %pf to <8 x float>*
  %1 = load <8 x float>* %0, align 4
  %2 = fmul <8 x float> %1, <float 2.000000e+00, float 2.000000e+00, float
2.000000e+00, float 2.000000e+00, float 2.000000e+00, float 2.000000e+00, float
2.000000e+00, float 2.000000e+00>
  %3 = fptosi <8 x float> %2 to <8 x i16>
  %4 = bitcast i16* %pb to <8 x i16>*
  store <8 x i16> %3, <8 x i16>* %4, align 2
  ret void
}

attributes #0 = { nounwind "less-precise-fpmad"="false"
"no-frame-pointer-elim"="false" "no-infs-fp-math"="false"
"no-nans-fp-math"="false" "no-realign-stack" "stack-protector-buffer-size"="8"
"unsafe-fp-math"="false" "use-soft-float"="false" }

# llc 1.ll
...
the same 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/20141114/f4f28a36/attachment.html>

From bugzilla-daemon at llvm.org  Fri Nov 14 05:14:42 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 14 Nov 2014 13:14:42 +0000
Subject: [LLVMbugs] [Bug 21306] Incomplete VSX support on POWER.
In-Reply-To: <bug-21306-206@http.llvm.org/bugs/>
References: <bug-21306-206@http.llvm.org/bugs/>
Message-ID: <bug-21306-206-2dC9z4LrjW@http.llvm.org/bugs/>

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

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

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

--- Comment #2 from Bill Schmidt <wschmidt at linux.vnet.ibm.com> ---
With today's fixes, the attached test case now compiles cleanly with -maltivec
-mvsx.

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

From bugzilla-daemon at llvm.org  Fri Nov 14 07:47:18 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 14 Nov 2014 15:47:18 +0000
Subject: [LLVMbugs] [Bug 21573] New: libxcb-1.11 miscompiles with Clang -O2
 on x86_32/linux
Message-ID: <bug-21573-206@http.llvm.org/bugs/>

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

            Bug ID: 21573
           Summary: libxcb-1.11 miscompiles with Clang -O2 on x86_32/linux
           Product: new-bugs
           Version: unspecified
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: joakim.gebart at eistec.se
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

The function get_peer_sock_name in src/xcb_auth.c of libxcb-1.11 generates
broken assembly code on x86_32 when compiled with Clang/LLVM-3.5.0 using -O2
optimization level, this does not happen on -O1 or lower level, it also seems
to work correctly on x86_64 even with -O2.

The C code first calls malloc(), then checks the returned pointer for NULL,
finally calls the function getpeername() or getsockname() via a function
pointer, using the malloc'ed pointer as second argument.

When compiled with -O2 the assembly code generated will (incorrectly)
dereference the pointer returned by malloc() and pass the value pointed at as
second argument to the getpeername() function call.

By coincidence, the uninitialized malloced area may contain a valid pointer
which results in a corrupt heap since the getpeername function will write its
result to an incorrect address.

C-code snippet below:

/* Return a dynamically allocated socket address structure according
   to the value returned by either getpeername() or getsockname()
   (according to POSIX, applications should not assume a particular
   length for `sockaddr_un.sun_path') */
static struct sockaddr *get_peer_sock_name(int (*socket_func)(int,
                                                              struct sockaddr
*,
                                                              socklen_t *),
                                           int fd)
{
    socklen_t socknamelen = sizeof(struct sockaddr) + INITIAL_SOCKNAME_SLACK;
    socklen_t actual_socknamelen = socknamelen;
    struct sockaddr *sockname = malloc(socknamelen);

    if (sockname == NULL)
        return NULL;

    /* Both getpeername() and getsockname() truncates sockname if
       there is not enough space and set the required length in
       actual_socknamelen */
    if (socket_func(fd, sockname, &actual_socknamelen) == -1) // <======= This
is where the incorrect dereference happens. /////////////
        goto sock_or_realloc_error;

    if (actual_socknamelen > socknamelen)
    {
        struct sockaddr *new_sockname = NULL;
        socknamelen = actual_socknamelen;

        if ((new_sockname = realloc(sockname, actual_socknamelen)) == NULL)
            goto sock_or_realloc_error;

        sockname = new_sockname;

        if (socket_func(fd, sockname, &actual_socknamelen) == -1 ||
            actual_socknamelen > socknamelen)
            goto sock_or_realloc_error;
    }

    return sockname;

 sock_or_realloc_error:
    free(sockname);
    return NULL;
}

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

From bugzilla-daemon at llvm.org  Fri Nov 14 08:24:18 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 14 Nov 2014 16:24:18 +0000
Subject: [LLVMbugs] [Bug 21574] New: std::is_constructible for scalar types
 only allows implicit conversion
Message-ID: <bug-21574-206@http.llvm.org/bugs/>

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

            Bug ID: 21574
           Summary: std::is_constructible for scalar types only allows
                    implicit conversion
           Product: libc++
           Version: unspecified
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: All Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: sebastian at theophil.net
                CC: llvmbugs at cs.uiuc.edu, mclow.lists at gmail.com
    Classification: Unclassified

Created attachment 13349
  --> http://llvm.org/bugs/attachment.cgi?id=13349&action=edit
Reproduction of bug

When T is a scalar type, the library implementation of std::is_constructible<T,
Arg> returns true iff Arg is implicitly convertible to T. 

However, the C++11 standard section  20.9.4.3 says: 

> Given the following function prototype:
> 
> template <class T>
> typename add_rvalue_reference<T>::type create();
> 
> the predicate condition for a template specialization is_constructible<T, Args...> shall be satisfied if and only if the following variable definition would be well-formed for some invented variable t:
> 
> T t(create<Args>()...);

To reproduce, compile attached file with "c++ -std=c++11 multiprecision.cpp"
using clang version <= 3.4 or clang shipping with Xcode 6.1

The static_assert fails but the explicit construction does not. 

I've tried clang 3.5 at http://melpon.org/wandbox and the static_assert does
not fail anymore. BUT, from looking at
http://llvm.org/svn/llvm-project/libcxx/trunk/include/type_traits it seems that
libcxx now checks for the compiler feature "is_constructible" and uses that if
available, which apparently produces the expected result. 

The manual implementation below still contains the same error from what I can
see.

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

From bugzilla-daemon at llvm.org  Fri Nov 14 08:27:08 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 14 Nov 2014 16:27:08 +0000
Subject: [LLVMbugs] [Bug 21575] New: Order of code generated for fastisel is
 wrong from X86 .td files dealing with VBROADCASTSSZr
Message-ID: <bug-21575-206@http.llvm.org/bugs/>

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

            Bug ID: 21575
           Summary: Order of code generated for fastisel is wrong from X86
                    .td files dealing with VBROADCASTSSZr
           Product: new-bugs
           Version: unspecified
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: seurer at linux.vnet.ibm.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

There is an issue in the X86 .td files dealing with VBROADCASTSSZr where the
ordering of the output for code generated for fastisel is wrong.

In X86GenFastISel.inc:

unsigned fastEmit_X86ISD_VBROADCAST_MVT_v4f32_MVT_v16f32_r(unsigned Op0, bool
Op0IsKill) {
  return fastEmitInst_r(X86::VBROADCASTSSZr, &X86::VR512RegClass, Op0,
Op0IsKill);
  if ((Subtarget->hasAVX512())) {
    return fastEmitInst_r(X86::VBROADCASTSSZr, &X86::VR512RegClass, Op0,
Op0IsKill);
  }
}

The "bare" return makes the if statement into dead code.

Note that how these are ordered is going to change to be based on the
complexity.  But even with that change the above still occurs so the
complexities of those instructions appears to be wrong 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/20141114/b08fa1b3/attachment.html>

From bugzilla-daemon at llvm.org  Fri Nov 14 08:49:03 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 14 Nov 2014 16:49:03 +0000
Subject: [LLVMbugs] [Bug 21576] New: Infinite loop in opt -instcombine
Message-ID: <bug-21576-206@http.llvm.org/bugs/>

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

            Bug ID: 21576
           Summary: Infinite loop in opt -instcombine
           Product: tools
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: opt
          Assignee: unassignedbugs at nondot.org
          Reporter: russell_gallop at sn.scee.net
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

$ cat bugpoint-reduced-simplified.ll
define void @autogen_SD2047654124() {
BB:
  %A = alloca <1 x double>
  %L = load <1 x double>* %A
  %B = frem <1 x double> %L, %L
  br label %CF33

CF33:                                             ; preds = %CF33, %BB
  br i1 undef, label %CF33, label %CF34

CF34:                                             ; preds = %CF34, %CF33
  %Tr = fptrunc <1 x double> %B to <1 x float>
  %E13 = extractelement <1 x float> %Tr, i32 0
  br i1 undef, label %CF34, label %CF35

CF35:                                             ; preds = %CF34
  %B29 = fdiv float 0xC08DAF2180000000, %E13
  ret void
}
$ opt -instcombine bugpoint-reduced-simplified.ll -o out.ll

Gets stuck in infinite loop using ever-increasing amounts of memory.

Reproduced with trunk 222002.

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

From bugzilla-daemon at llvm.org  Fri Nov 14 10:25:00 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 14 Nov 2014 18:25:00 +0000
Subject: [LLVMbugs] [Bug 21571] /Zo not supported in visual sutdio 2013
 update 3 and above
In-Reply-To: <bug-21571-206@http.llvm.org/bugs/>
References: <bug-21571-206@http.llvm.org/bugs/>
Message-ID: <bug-21571-206-3k639Wrqfo@http.llvm.org/bugs/>

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

Hans Wennborg <hans at chromium.org> changed:

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

--- Comment #1 from Hans Wennborg <hans at chromium.org> ---
Should be fixed in r222013.

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

From bugzilla-daemon at llvm.org  Fri Nov 14 10:30:00 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 14 Nov 2014 18:30:00 +0000
Subject: [LLVMbugs] [Bug 21577] New: 'Malformed block',
 using libLTO version 'LLVM version 3.5svn'
Message-ID: <bug-21577-206@http.llvm.org/bugs/>

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

            Bug ID: 21577
           Summary: 'Malformed block', using libLTO version 'LLVM version
                    3.5svn'
           Product: lld
           Version: unspecified
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: All Bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: kulakov.ilya at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

I'm building OpenSSL using with LTO:

    ./Configure
        no-ssl2
        darwin64-x86_64-cc
        zlib-dynamic
        enable-cms
        shared
        -isysroot ...MacOSX10.10.sdk
        -mmacosx-version-min=10.8
        -mssse3
        -gdwarf-4
        -fslp-vectorize
        -fvectorize
        -flto
        -Xlinker -dead_strip
        -Xlinker -object_path_lto
        -Xlinker /tmp/$(@F).lto.o"

The same command worked for me many times. Then once it failed to build under
the exactly same environment with the following error:

ld: in libcrypto.a(tasn_typ.o), could not parse object file
libcrypto.a(tasn_typ.o): 'Malformed block', using libLTO version 'LLVM version
3.5svn' for architecture x86_64

I just deleted all intermediate files and started build from scratch and it
finished without a 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/20141114/c8d578fc/attachment.html>

From bugzilla-daemon at llvm.org  Fri Nov 14 11:20:42 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 14 Nov 2014 19:20:42 +0000
Subject: [LLVMbugs] [Bug 21578] New: wrong code at -Os and above on
	x86_64-linux-gnu
Message-ID: <bug-21578-206@http.llvm.org/bugs/>

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

            Bug ID: 21578
           Summary: wrong code at -Os and above on x86_64-linux-gnu
           Product: clang
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: su at cs.ucdavis.edu
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

The current clang trunk miscompiles the following code at -Os and above on
x86_64-linux-gnu in both 32-bit and 64-bit modes.

This is a regression from 3.5.0. 

$ clang-trunk -v
clang version 3.6.0 (trunk 220897)
Target: x86_64-unknown-linux-gnu
Thread model: posix
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6.4
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7.3
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8.1
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Selected multilib: .;@m64
$ 
$ clang-trunk -O1 small.c; a.out
$ clang-3.5.0 -Os small.c; a.out
$ 
$ clang-trunk -Os small.c       
$ a.out
Aborted (core dumped)
$ 


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


short a;

short
fn1 (int p1, int p2)
{
  return p1 * p2;
}

int
main ()
{
  while (fn1 (++a, 3))
    ; 

  if (a != 0) 
    __builtin_abort (); 

  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/20141114/7d4a3ed4/attachment.html>

From bugzilla-daemon at llvm.org  Fri Nov 14 11:25:45 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 14 Nov 2014 19:25:45 +0000
Subject: [LLVMbugs] [Bug 15732] [META] CMake build equivalent to the
	autotools build
In-Reply-To: <bug-15732-206@http.llvm.org/bugs/>
References: <bug-15732-206@http.llvm.org/bugs/>
Message-ID: <bug-15732-206-7tDBfHhOpz@http.llvm.org/bugs/>

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

Bug 15732 depends on bug 21569, which changed state.

Bug 21569 Summary: Can't `make install prefix=/tmp/llvm' with CMake.
http://llvm.org/bugs/show_bug.cgi?id=21569

           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/20141114/8c12af9e/attachment.html>

From bugzilla-daemon at llvm.org  Fri Nov 14 11:25:45 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 14 Nov 2014 19:25:45 +0000
Subject: [LLVMbugs] [Bug 21569] Can't `make install prefix=/tmp/llvm' with
	CMake.
In-Reply-To: <bug-21569-206@http.llvm.org/bugs/>
References: <bug-21569-206@http.llvm.org/bugs/>
Message-ID: <bug-21569-206-YubTcosq83@http.llvm.org/bugs/>

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

Steven Stewart-Gallus <sstewartgallus00 at mylangara.bc.ca> changed:

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

--- Comment #4 from Steven Stewart-Gallus <sstewartgallus00 at mylangara.bc.ca> ---
You are correct that this is an issue with CMake and Clang's build scripts.
However, I was specifically asked by Tom Stellard (see
http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-November/078763.html) to open
an issue for this if I felt this issue blocks bug 15732 (that CMake was a good
enough replacement for Autotools.) If CMake is NOT a good enough replacement
than Autotools than it is not a good enough replacement for Autotools
regardless of whether it is your fault.

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

From bugzilla-daemon at llvm.org  Fri Nov 14 13:21:33 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 14 Nov 2014 21:21:33 +0000
Subject: [LLVMbugs] [Bug 21576] Infinite loop in opt -instcombine
In-Reply-To: <bug-21576-206@http.llvm.org/bugs/>
References: <bug-21576-206@http.llvm.org/bugs/>
Message-ID: <bug-21576-206-lPlBMjK6I0@http.llvm.org/bugs/>

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

David Majnemer <david.majnemer at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |david.majnemer at gmail.com
         Resolution|---                         |FIXED
           Assignee|unassignedbugs at nondot.org   |david.majnemer at gmail.com

--- Comment #1 from David Majnemer <david.majnemer at gmail.com> ---
Fixed in r222040.

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

From bugzilla-daemon at llvm.org  Fri Nov 14 16:57:22 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 15 Nov 2014 00:57:22 +0000
Subject: [LLVMbugs] [Bug 21579] New: Memory Sanitizer causes wide string
 test failures in libc++
Message-ID: <bug-21579-206@http.llvm.org/bugs/>

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

            Bug ID: 21579
           Summary: Memory Sanitizer causes wide string test failures in
                    libc++
           Product: compiler-rt
           Version: unspecified
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: compiler-rt
          Assignee: unassignedbugs at nondot.org
          Reporter: eric at efcs.ca
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

When testing libc++ with MSAN tests involving wide strings start to fail
without MSAN producing any output. The assertions in these tests do not fail
when MSAN is disabled. 

The output of the test run can be found here:
http://lab.llvm.org:8011/builders/libcxx-libcxxabi-x86_64-linux-ubuntu-msan/builds/9/steps/test.libcxx/logs/stdio

libc++ is compiled with the sanitizer flags:
-fno-omit-frame-pointer -fsanitize=memory

Let me know if I can provide anything more.

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

From bugzilla-daemon at llvm.org  Fri Nov 14 17:45:34 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 15 Nov 2014 01:45:34 +0000
Subject: [LLVMbugs] [Bug 21573] libxcb-1.11 miscompiles with Clang -O2 on
	x86_32/linux
In-Reply-To: <bug-21573-206@http.llvm.org/bugs/>
References: <bug-21573-206@http.llvm.org/bugs/>
Message-ID: <bug-21573-206-RWqPiVJ1YA@http.llvm.org/bugs/>

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

Reid Kleckner <rnk at google.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED
           Assignee|unassignedbugs at nondot.org   |rnk at google.com

--- Comment #8 from Reid Kleckner <rnk at google.com> ---
I went and looked at sys/socket.h, and it uses transparent unions. After
reading the gcc docs
(https://gcc.gnu.org/onlinedocs/gcc/Type-Attributes.html#index-g_t_0040code_007btransparent_005funion_007d-attribute-3157),
we decided this was a bug in clang. transparent union changes how the value is
passed.

Turns out, we had a test case with a FIXME already documenting the problem. I
fixed it in r222074.

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

From bugzilla-daemon at llvm.org  Fri Nov 14 20:40:03 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 15 Nov 2014 04:40:03 +0000
Subject: [LLVMbugs] [Bug 21580] New: Undefined behavior in
	readEncodedPointer()
Message-ID: <bug-21580-206@http.llvm.org/bugs/>

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

            Bug ID: 21580
           Summary: Undefined behavior in readEncodedPointer()
           Product: libc++abi
           Version: unspecified
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: All Bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: eric at efcs.ca
                CC: llvmbugs at cs.uiuc.edu, mclow.lists at gmail.com
    Classification: Unclassified

The following error occurs almost everywhere libc++abi is used with UBSAN. 


libcxxabi/src/cxa_personality.cpp:252:18: runtime error: load of misaligned
address 0x000000428c39 for type 'uint32_t' (aka 'unsigned int'), which requires
4 byte alignment
0x000000428c39: note: pointer points here
 03 35 03  27 00 00 00 00 22 00 00  00 00 00 00 00 00 22 00  00 00 13 00 00 00
3a 00  00 00 03 35 00

To recreate this error configure libc++abi with -DLLVM_USE_SANITIZER=Undefined
and run the libc++abi test suite. There will be multiple failures caused by
this.

I also tried running libc++'s testsuite with libcxxrt and UBSAN. I found that
the exact same error occurred in libcxxrt's implementation of reading an
encoded 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/20141115/e6a8f19b/attachment.html>

From bugzilla-daemon at llvm.org  Sat Nov 15 05:33:10 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 15 Nov 2014 13:33:10 +0000
Subject: [LLVMbugs] [Bug 21223] Assertion in X86 backend - vector
	extract/shuffle
In-Reply-To: <bug-21223-206@http.llvm.org/bugs/>
References: <bug-21223-206@http.llvm.org/bugs/>
Message-ID: <bug-21223-206-t77ugfHpqW@http.llvm.org/bugs/>

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

Simon Pilgrim <llvm-dev at redking.me.uk> changed:

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

--- Comment #3 from Simon Pilgrim <llvm-dev at redking.me.uk> ---
Confirmed test cases were fixed at r220592

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

From bugzilla-daemon at llvm.org  Sat Nov 15 10:52:33 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 15 Nov 2014 18:52:33 +0000
Subject: [LLVMbugs] [Bug 21581] New: libc++ iostream's bad() member function
 is returning true, always
Message-ID: <bug-21581-206@http.llvm.org/bugs/>

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

            Bug ID: 21581
           Summary: libc++ iostream's bad() member function is returning
                    true, always
           Product: libc++
           Version: 3.4
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: All Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: santilopez01 at gmail.com
                CC: llvmbugs at cs.uiuc.edu, mclow.lists at gmail.com
    Classification: Unclassified

Created attachment 13352
  --> http://llvm.org/bugs/attachment.cgi?id=13352&action=edit
Source code plus binaries

So I compiled the code I have attached using the following flags:

clang++ -std=c++11 -std=libc++ -Wall -v *.cxx -o out_clang

The program compiles but it throws an exception immediately after I enter some
input (I do a check for istream.bad(), on romans.cxx). The weird thing is that
I also compile the code using g++ front end:

g++ -std=c++11 -Wall *.cxx -o out_gcc

And the code executes fine. I include the source code, plus the aforementioned
binaries I obtained from each call. I have gcc 4.9.2 and clang 3.6.

I checked the code with valgrind and it doesn't complaint on any of the
binaries.

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

From bugzilla-daemon at llvm.org  Sat Nov 15 10:56:40 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 15 Nov 2014 18:56:40 +0000
Subject: [LLVMbugs] [Bug 21582] New: wrong code at -O1 and above on
	x86_64-linux-gnu
Message-ID: <bug-21582-206@http.llvm.org/bugs/>

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

            Bug ID: 21582
           Summary: wrong code at -O1 and above on x86_64-linux-gnu
           Product: clang
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: su at cs.ucdavis.edu
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

The current clang trunk miscompiles the following code at -O1 and above on
x86_64-linux-gnu in both 32-bit and 64-bit modes.

This also affects 3.5.0, and is a regression from 3.4.x. 

$ clang-trunk -v
clang version 3.6.0 (trunk 220897)
Target: x86_64-unknown-linux-gnu
Thread model: posix
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6.4
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7.3
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8.1
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Selected multilib: .;@m64
$ 
$ clang-trunk -O0 small.c; a.out
1
$ clang-3.4.2 -O1 small.c; a.out
1
$ 
$ clang-trunk -O1 small.c; a.out
0
$ clang-3.5.0 -O1 small.c; a.out
0
$


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


int printf (const char *, ...);

int a, b, c, e, k, l;

struct
{
  int f1;
} d;

void
fn1 ()
{
  if (d.f1)
    for (c = 0; a;)
      for (; l;)
    ;
}

int
fn2 ()
{
  for (; b < 1; b++)
    for (; k; k++)
      fn1 ();
  return 0;
}

int
fn3 ()
{
  int g = 0, h;
  int i[1][1] = { {1} };
  for (;;)
    {
      b = 0;
      for (; g < 1; g++)
    h = i[0][g] != fn2 ();
      if (++e)
    return 0;
      g = h;
    }
}

int
main ()
{
  fn3 ();
  printf ("%d\n", b);
  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/20141115/ff526007/attachment.html>

From bugzilla-daemon at llvm.org  Sat Nov 15 16:58:12 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 16 Nov 2014 00:58:12 +0000
Subject: [LLVMbugs] [Bug 21532] Separate Metadata from the Value hierarchy
In-Reply-To: <bug-21532-206@http.llvm.org/bugs/>
References: <bug-21532-206@http.llvm.org/bugs/>
Message-ID: <bug-21532-206-kkg1UHNoH2@http.llvm.org/bugs/>

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

Bug 21532 depends on bug 21533, which changed state.

Bug 21533 Summary: Replace debug info intrinsics with metadata attachments
http://llvm.org/bugs/show_bug.cgi?id=21533

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

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

From bugzilla-daemon at llvm.org  Sat Nov 15 16:58:12 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 16 Nov 2014 00:58:12 +0000
Subject: [LLVMbugs] [Bug 21432] First-class (metadata-based) IR for debug
	info
In-Reply-To: <bug-21432-206@http.llvm.org/bugs/>
References: <bug-21432-206@http.llvm.org/bugs/>
Message-ID: <bug-21432-206-Frep9ExUU7@http.llvm.org/bugs/>

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

Bug 21432 depends on bug 21533, which changed state.

Bug 21533 Summary: Replace debug info intrinsics with metadata attachments
http://llvm.org/bugs/show_bug.cgi?id=21533

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

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

From bugzilla-daemon at llvm.org  Sat Nov 15 16:58:07 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 16 Nov 2014 00:58:07 +0000
Subject: [LLVMbugs] [Bug 21533] Replace debug info intrinsics with metadata
	attachments
In-Reply-To: <bug-21533-206@http.llvm.org/bugs/>
References: <bug-21533-206@http.llvm.org/bugs/>
Message-ID: <bug-21533-206-ZhHiS0knwL@http.llvm.org/bugs/>

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

Duncan <dexonsmith at apple.com> changed:

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

--- Comment #29 from Duncan <dexonsmith at apple.com> ---
Once I dug into what argument metadata attachments really look like, I figured
out [1] this would be a major semantic change, and fallout from that would be
hard to diagnose.

This might still be a good idea some day, but closing as won't fix for now.

[1]: http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-November/078773.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/20141116/a7f2fc5d/attachment.html>

From bugzilla-daemon at llvm.org  Sun Nov 16 10:11:46 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 16 Nov 2014 18:11:46 +0000
Subject: [LLVMbugs] [Bug 21585] New: [DependenceAnalysis] collectUpperBound
 triggers asserts
Message-ID: <bug-21585-206@http.llvm.org/bugs/>

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

            Bug ID: 21585
           Summary: [DependenceAnalysis] collectUpperBound triggers
                    asserts
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Global Analyses
          Assignee: unassignedbugs at nondot.org
          Reporter: wujingyue at gmail.com
                CC: llvmbugs at cs.uiuc.edu, sebpop at gmail.com
    Classification: Unclassified

Created attachment 13354
  --> http://llvm.org/bugs/attachment.cgi?id=13354&action=edit
the test that triggers assertion failures

collectUpperBound assumes the type of the back edge count is no wider than the
desired type (T). However, this assumption does not hold at least in
strongSIVTest where the type of Delta may be narrower. 

In the attached test case, the back edge count is i64 100, but the Delta
(derived from i32 %i and i32 5) is of i32. 

define void @i32_subscript(i32* %a) {
entry:
  br label %for.body

for.body:
  %i = phi i32 [ 0, %entry ], [ %i.inc, %for.body ]
  %a.addr = getelementptr i32* %a, i32 %i
  %a.addr.2 = getelementptr i32* %a, i32 5
  %0 = load i32* %a.addr, align 4
  %1 = add i32 %0, 1
  store i32 %1, i32* %a.addr.2, align 4
  %i.inc = add nsw i32 %i, 1
  %i.inc.ext = sext i32 %i to i64
  %exitcond = icmp ne i64 %i.inc.ext, 100
  br i1 %exitcond, label %for.body, label %for.end

for.end:
  ret void
}

Note: this issue is similar to PR18082 in that both are caused by sort of type
mismatching. However, the type mismatch in PR18082 is caused by
removeMatchingExtensions, and this bug is not. 

Jingyue

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

From bugzilla-daemon at llvm.org  Sun Nov 16 15:56:23 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 16 Nov 2014 23:56:23 +0000
Subject: [LLVMbugs] [Bug 21586] New: libc++ operator>>(istream&,
 std::string &s) not throwing exception when failbit is set and
 failbit exceptions enabled
Message-ID: <bug-21586-206@http.llvm.org/bugs/>

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

            Bug ID: 21586
           Summary: libc++ operator>>(istream&, std::string &s) not
                    throwing exception when failbit is set and failbit
                    exceptions enabled
           Product: libc++
           Version: unspecified
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: All Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: seth.cantrell at gmail.com
                CC: llvmbugs at cs.uiuc.edu, mclow.lists at gmail.com
    Classification: Unclassified

I have a simple program which I believe should be throwing an exception:

    // http://coliru.stacked-crooked.com/a/464c105f4ec53104

    #include <sstream>
    #include <string>

    int main() {
        std::stringstream ss("");
        ss.exceptions(std::ios::failbit);
        std::string s;
        ss >> s; // not throwing an exception under libc++
    }

With libstdc++ and VC++'s this program does indeed throw an exception. However
with libc++ it does not. Interestingly a direct check of the streams failbit
shows that libc++'s implementation is setting the failbit, as are the other
implementations, but for some reason this does not cause an exception to be
thrown when the streaming operator fails.

    // http://coliru.stacked-crooked.com/a/e4a649ee145b0475

    #include <sstream>
    #include <string>
    #include <iostream>

    int main() {
        std::stringstream ss("");
        std::string s;
        ss >> s;
        std::cout << ss.fail() << '\n'; // prints '1' for all tested
implementations
    }

If failbit exceptions are enabled after the bit is set, the .exceptions()
member function throws as expected:

    // http://coliru.stacked-crooked.com/a/601cb5d7c5c2b156

    #include <sstream>
    #include <string>

    int main() {
        std::stringstream ss("");
        std::string s;
        ss >> s;
        ss.exceptions(std::ios::failbit); // throws on all tested
implementations
    }

I don't know what version of libc++ is being used on
coliru.stacked-crooked.com, but I'm also reproducing this issue with r222085 /
9a1468f79ea23f14a258af094af06993fe72e3a9

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

From bugzilla-daemon at llvm.org  Sun Nov 16 20:23:51 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 17 Nov 2014 04:23:51 +0000
Subject: [LLVMbugs] [Bug 21587] New: Failed to recognize init selector when
 using precompiled header
Message-ID: <bug-21587-206@http.llvm.org/bugs/>

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

            Bug ID: 21587
           Summary: Failed to recognize init selector when using
                    precompiled header
           Product: clang
           Version: trunk
          Hardware: PC
                OS: MacOS X
            Status: NEW
          Severity: release blocker
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: 191919 at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 13355
  --> http://llvm.org/bugs/attachment.cgi?id=13355&action=edit
The build environment

clang svn trunk (222117 as I am submitting this bug) failed gave the following
message

```
1.mm:7:23: error: 'init' is unavailable
        return [[self alloc] init];
                             ^
/System/Library/Frameworks/Foundation.framework/Headers/NSLocale.h:39:1: note:
'init' has been explicitly marked unavailable here
- (instancetype)init NS_UNAVAILABLE;     /* do not invoke; not a valid
initializer for this class */
^
1 error generated.
```

when compiling a trivial source code like this when using PCH.


```
@interface Bug : NSResponder
@end

@implementation Bug

+ (instancetype)bug {
    return [[self alloc] init];
}

@end
```

The code should be ok and is compilable by svn 21xxxx.

I have attached the source codes and Makefile, please change /opt/bin/clang as
need.

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

From bugzilla-daemon at llvm.org  Mon Nov 17 02:44:22 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 17 Nov 2014 10:44:22 +0000
Subject: [LLVMbugs] [Bug 21588] New: [mips] Assertion when returning structs
 of arrays of 64-bit types for N32 (possibly N64 too)
Message-ID: <bug-21588-206@http.llvm.org/bugs/>

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

            Bug ID: 21588
           Summary: [mips] Assertion when returning structs of arrays of
                    64-bit types for N32 (possibly N64 too)
           Product: new-bugs
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: daniel.sanders at imgtec.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

The following tests generated by ABITestGen.py trigger assertions for the N32
ABI:
struct T1 { unsigned long long T2[3] field0 } fn20557(void)
union T1 { unsigned long long T2[3] field0 } fn20576(void)
struct T1 { unsigned long long T2[4] field0 } fn21469(void)
union T1 { unsigned long long T2[4] field0 } fn21488(void)
struct T1 { signed long long T2[3] field0 } fn38797(void)
union T1 { signed long long T2[3] field0 } fn38816(void)
struct T1 { signed long long T2[4] field0 } fn39709(void)
union T1 { signed long long T2[4] field0 } fn39728(void)
struct T1 { double T2[3] field0 } fn49741(void)
union T1 { double T2[3] field0 } fn49760(void)
struct T1 { double T2[4] field0 } fn50653(void)
union T1 { double T2[4] field0 } fn50672(void)
struct T1 { long double T2[2] field0 } fn52477(void)
union T1 { long double T2[2] field0 } fn52477(void)
struct T1 { long double T2[3] field0 } fn53389(void)
union T1 { long double T2[3] field0 } fn53408(void)
struct T1 { long double T2[4] field0 } fn54301(void)
union T1 { long double T2[4] field0 } fn54320(void)

They're the only failures in the first 100,000 tests.
It's likely that N64 does the same thing but this hasn't been confirmed yet.

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

From bugzilla-daemon at llvm.org  Mon Nov 17 05:17:53 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 17 Nov 2014 13:17:53 +0000
Subject: [LLVMbugs] [Bug 21589] New: clang-cl.exe does not reproduce
 semantic of cl.exe's /Fo switch correctly
Message-ID: <bug-21589-206@http.llvm.org/bugs/>

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

            Bug ID: 21589
           Summary: clang-cl.exe does not reproduce semantic of cl.exe's
                    /Fo switch correctly
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: Driver
          Assignee: unassignedclangbugs at nondot.org
          Reporter: frerich.raabe+llvmbug at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Overview
--------
The clang-cl.exe driver as shipped with clang version 3.6.0 (221592) does not
reproduce the semantic of the /Fo switch correctly.

How to Reproduce
----------------
1. Create a source file 'x.cpp' containing just

    void f() {}

2. Compile the source file by running

    clang-cl /c /Fo x.cpp

Actual Results
--------------
clang-cl.exe prints an error message saying

  clang-cl.exe: error: argument to '/Fo' is missing (expected 1 value)

Expected Results
----------------
clang does not print any output. Instead, it compiles the given source file,
and writes an object file with the default name -- x.obj

Build Date & Platform
---------------------
clang version 3.6.0 (221592)
Target: i686-pc-windows-msvc
Thread model: posix

Additional Information
----------------------
Contrary to what the MSDN documentation and the "cl.exe /help" output says, the
/Fo switch (which can be used to define the name of the output file) does *not*
require an argument. If no argment is given, the default name will be used
(i.e. it appears to behave as if /Fo was not specified at all).

This differene in behaviour unfortunately breaks using clang-cl as a drop-in
replacement for cl for setups which rely on compiler invocations to work even
if no argument to /Fo is given.

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

From bugzilla-daemon at llvm.org  Mon Nov 17 05:39:42 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 17 Nov 2014 13:39:42 +0000
Subject: [LLVMbugs] [Bug 21575] Order of code generated for fastisel is
 wrong from X86 .td files dealing with VBROADCASTSSZr
In-Reply-To: <bug-21575-206@http.llvm.org/bugs/>
References: <bug-21575-206@http.llvm.org/bugs/>
Message-ID: <bug-21575-206-7SByjZ9LHe@http.llvm.org/bugs/>

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |wschmidt at linux.vnet.ibm.com
         Resolution|---                         |FIXED

--- Comment #2 from Bill Schmidt <wschmidt at linux.vnet.ibm.com> ---
Craig Topper has fixed this in r224843:

http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20141110/244843.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/20141117/fa45fb13/attachment.html>

From bugzilla-daemon at llvm.org  Mon Nov 17 06:31:16 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 17 Nov 2014 14:31:16 +0000
Subject: [LLVMbugs] [Bug 21588] [mips] Assertion when returning structs of
 arrays of 64-bit types for N32 (possibly N64 too)
In-Reply-To: <bug-21588-206@http.llvm.org/bugs/>
References: <bug-21588-206@http.llvm.org/bugs/>
Message-ID: <bug-21588-206-QtESjf0eie@http.llvm.org/bugs/>

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

Daniel Sanders <daniel.sanders at imgtec.com> changed:

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

--- Comment #1 from Daniel Sanders <daniel.sanders at imgtec.com> ---
We've already fixed this. It appears the build I left running was compiled
before fixing the contents of OriginalArgWasFloat for sret arguments.

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

From bugzilla-daemon at llvm.org  Mon Nov 17 07:45:07 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 17 Nov 2014 15:45:07 +0000
Subject: [LLVMbugs] [Bug 21590] New: fatal error: error in backend: Do not
 know how to split this operator's operand!
Message-ID: <bug-21590-206@http.llvm.org/bugs/>

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

            Bug ID: 21590
           Summary: fatal error: error in backend: Do not know how to
                    split this operator's operand!
           Product: clang
           Version: trunk
          Hardware: Other
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: bero at lindev.ch
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Trying to build current AOSP for ARMv7 with clang (tried both the version of
3.5 that is included in AOSP and a relatively current 3.6 snapshot) fails
saying "fatal error in backend: Do not know how to split this operator's
operand!" without giving much of an indication of what operand it's talking
about.

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

From bugzilla-daemon at llvm.org  Mon Nov 17 09:08:35 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 17 Nov 2014 17:08:35 +0000
Subject: [LLVMbugs] [Bug 21592] New: GlobalOpt::CleanupPointerRootUsers
 could pass nullptr to dyn_cast
Message-ID: <bug-21592-206@http.llvm.org/bugs/>

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

            Bug ID: 21592
           Summary: GlobalOpt::CleanupPointerRootUsers could pass nullptr
                    to dyn_cast
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Interprocedural Optimizations
          Assignee: unassignedbugs at nondot.org
          Reporter: vedun at ispras.ru
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 13358
  --> http://llvm.org/bugs/attachment.cgi?id=13358&action=edit
Proposed patch

https://github.com/llvm-mirror/llvm/blob/master/lib/Transforms/IPO/GlobalOpt.cpp#L222
:

222: GlobalVariable *MemSrc = dyn_cast<GlobalVariable>(MTI->getSource());
223: if (MemSrc && MemSrc->isConstant()) {
224:     Changed = true;
225:     MTI->eraseFromParent();
226: } else if (Instruction *I = dyn_cast<Instruction>(MemSrc)) {
227:     if (I->hasOneUse())
228:     Dead.push_back(std::make_pair(I, MTI));
229: }

if MTI->getSource() is an Instruction, dyn_cast(222) returns nullptr, so  the
condition (223) would be false, and dyn_cast (226) would fail due to MemSrc
being null. 

Probably, the author meant that dyn_cast (226) should use the return of
MTI->getSource(). In this case, the attached patch fixes 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/20141117/cc1233dd/attachment.html>

From bugzilla-daemon at llvm.org  Mon Nov 17 11:24:30 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 17 Nov 2014 19:24:30 +0000
Subject: [LLVMbugs] [Bug 21589] clang-cl.exe does not reproduce semantic of
 cl.exe's /Fo switch correctly
In-Reply-To: <bug-21589-206@http.llvm.org/bugs/>
References: <bug-21589-206@http.llvm.org/bugs/>
Message-ID: <bug-21589-206-MRPZIf5NRz@http.llvm.org/bugs/>

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

Hans Wennborg <hans at chromium.org> changed:

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

--- Comment #2 from Hans Wennborg <hans at chromium.org> ---
Thanks for the bug report! Fixed in r222164.

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

From bugzilla-daemon at llvm.org  Mon Nov 17 13:57:20 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 17 Nov 2014 21:57:20 +0000
Subject: [LLVMbugs] [Bug 21593] New: Modules design problems for
	linux/packagers
Message-ID: <bug-21593-206@http.llvm.org/bugs/>

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

            Bug ID: 21593
           Summary: Modules design problems for linux/packagers
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Modules
          Assignee: unassignedclangbugs at nondot.org
          Reporter: steveire at gmail.com
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified

As per

 http://thread.gmane.org/gmane.comp.compilers.clang.devel/39209/focus=39534

the current design might not be good enough for them. I have not investigated
whether the suggestion of using extern module declarations in a
/usr/local/module.modulemap, but requiring every library to include a script to
update that may not be viable. Requires asking packagers.

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

From bugzilla-daemon at llvm.org  Mon Nov 17 15:37:47 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 17 Nov 2014 23:37:47 +0000
Subject: [LLVMbugs] [Bug 19195] crash on valid codegen'ing member class
 template with in-class initialized member
In-Reply-To: <bug-19195-206@http.llvm.org/bugs/>
References: <bug-19195-206@http.llvm.org/bugs/>
Message-ID: <bug-19195-206-qcDPHaxE8I@http.llvm.org/bugs/>

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

Reid Kleckner <rnk at google.com> changed:

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

--- Comment #2 from Reid Kleckner <rnk at google.com> ---
r222192

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

From bugzilla-daemon at llvm.org  Mon Nov 17 15:54:21 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 17 Nov 2014 23:54:21 +0000
Subject: [LLVMbugs] [Bug 20603] clang crashes under SPARC on 'typedef
 __typeof__((int*)0) intptr_t; '
In-Reply-To: <bug-20603-206@http.llvm.org/bugs/>
References: <bug-20603-206@http.llvm.org/bugs/>
Message-ID: <bug-20603-206-jkJROj9q3d@http.llvm.org/bugs/>

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

Reid Kleckner <rnk at google.com> changed:

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

--- Comment #4 from Reid Kleckner <rnk at google.com> ---
I can't repro this with clang 3.5 or 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/20141117/f0230e21/attachment.html>

From bugzilla-daemon at llvm.org  Mon Nov 17 16:38:51 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 18 Nov 2014 00:38:51 +0000
Subject: [LLVMbugs] [Bug 19612] bad codegen on MIPS va_arg
In-Reply-To: <bug-19612-206@http.llvm.org/bugs/>
References: <bug-19612-206@http.llvm.org/bugs/>
Message-ID: <bug-19612-206-np1yfdXRWE@http.llvm.org/bugs/>

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

Martin Sebor <msebor at gmail.com> changed:

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

--- Comment #8 from Martin Sebor <msebor at gmail.com> ---
This doesn't appear to be fixed. Here's a simplified test case and the output
as of r221712:

int foo (__builtin_va_list va) {
    return __builtin_va_arg (va, int);
}
    .text
    .abicalls
    .option    pic0
    .section    .mdebug.abiN32,"", at progbits
    .nan    legacy
    .file    "t.c"
    .text
    .globl    foo
    .align    3
    .type    foo, at function
    .set    nomicromips
    .set    nomips16
    .ent    foo
foo:
    .frame    $sp,0,$ra
    .mask     0x00000000,0
    .fmask    0x00000000,0
    .set    noreorder
    .set    nomacro
    .set    noat
    sll    $1, $4, 0
    lw    $2, 0($1)   <<< reading the more significant word
    jr    $ra
    nop
    .set    at
    .set    macro
    .set    reorder
    .end    foo
$tmp0:
    .size    foo, ($tmp0)-foo


    .ident    "clang version 3.6.0 (trunk) (llvm/trunk 221712)"
    .section    ".note.GNU-stack","", at progbits
    .text

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

From bugzilla-daemon at llvm.org  Mon Nov 17 16:38:53 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 18 Nov 2014 00:38:53 +0000
Subject: [LLVMbugs] [Bug 20528] [mips] Tracking ticket for big-endian
	N32/N64 ABI issues
In-Reply-To: <bug-20528-206@http.llvm.org/bugs/>
References: <bug-20528-206@http.llvm.org/bugs/>
Message-ID: <bug-20528-206-88nXTMqFOe@http.llvm.org/bugs/>

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

Bug 20528 depends on bug 19612, which changed state.

Bug 19612 Summary: bad codegen on MIPS va_arg
http://llvm.org/bugs/show_bug.cgi?id=19612

           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/20141118/f4a88cd0/attachment.html>

From bugzilla-daemon at llvm.org  Tue Nov 18 04:27:08 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 18 Nov 2014 12:27:08 +0000
Subject: [LLVMbugs] [Bug 21576] Infinite loop in opt -instcombine
In-Reply-To: <bug-21576-206@http.llvm.org/bugs/>
References: <bug-21576-206@http.llvm.org/bugs/>
Message-ID: <bug-21576-206-S5ms1JsWtn@http.llvm.org/bugs/>

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

Russell Gallop <russell_gallop at sn.scee.net> changed:

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

--- Comment #2 from Russell Gallop <russell_gallop at sn.scee.net> ---
Thanks for the quick response, David.

Manman, you reverted the fix at r222203 due to a bot failure. It looks like the
bot is still failing after this revert. Can you clarify the reason for
suspecting this patch?

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

From bugzilla-daemon at llvm.org  Tue Nov 18 08:24:38 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 18 Nov 2014 16:24:38 +0000
Subject: [LLVMbugs] [Bug 21594] New: [AArch64][FastISel] Generates invalid
 shift immediate greater than 31 (lsr w10, w8, #32)
Message-ID: <bug-21594-206@http.llvm.org/bugs/>

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

            Bug ID: 21594
           Summary: [AArch64][FastISel] Generates invalid shift immediate
                    greater than 31 (lsr w10, w8, #32)
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: ASSIGNED
          Severity: normal
          Priority: P
         Component: Backend: AArch64
          Assignee: juergen at apple.com
          Reporter: mcrosier at codeaurora.org
                CC: apazos at codeaurora.org, llvmbugs at cs.uiuc.edu,
                    mcrosier at codeaurora.org, t.p.northover at gmail.com
    Classification: Unclassified

When running with fast-isel the assembler is complaining about an invalid
immediate value on a shift instruction:

Error: immediate value out of range 0 to 31 at operand 3 -- `lsr w10,w10,#32'

Reduced test case:
--------------------------------------------------
$> more test.ll

; ModuleID = 'test.ll'
target datalayout = "e-m:e-i64:64-i128:128-n32:64-S128"
target triple = "aarch64--linux-gnu"

%struct.element_t = type { i32 }

@list = internal constant [0 x %struct.element_t] zeroinitializer, align 4

define internal i32* @tink() {
entry:
  %call = call i32 bitcast (i32 (...)* @foo to i32 ()*)()
  %tobool = icmp ne i32 %call, 0
  br i1 %tobool, label %lor.lhs.false, label %if.then

lor.lhs.false:                                    ; preds = %entry
  %mul = mul nsw i32 1, undef
  %idx.ext = sext i32 %mul to i64
  %add.ptr = getelementptr inbounds i8* undef, i64 %idx.ext
  %call1 = call i32 bitcast (i32 (...)* @foo to i32 (i8*, i32)*)(i8* %add.ptr,
i32 undef)
  %tobool2 = icmp ne i32 %call1, 0
  br i1 %tobool2, label %lor.lhs.false3, label %if.then

lor.lhs.false3:                                   ; preds = %lor.lhs.false
  %mul4 = mul nsw i32 2, undef
  %idx.ext5 = sext i32 %mul4 to i64
  %add.ptr6 = getelementptr inbounds i8* undef, i64 %idx.ext5
  %call7 = call i32 bitcast (i32 (...)* @foo to i32 (i8*, i32)*)(i8* %add.ptr6,
i32 undef)
  %tobool8 = icmp ne i32 %call7, 0
  br i1 %tobool8, label %if.end, label %if.then

if.then:                                          ; preds = %lor.lhs.false3,
%lor.lhs.false, %entry
  br label %if.end

if.end:                                           ; preds = %if.then,
%lor.lhs.false3
  ret i32* undef
}

declare i32 @foo(...)
--------------------------------------------------

Reproduce with:
$> llc -O0 test.ll -o - | grep lsr
        lsr     w10, w8, #32

The regression looks to have been introduced around 08/27-08/28.

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

From bugzilla-daemon at llvm.org  Tue Nov 18 09:31:56 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 18 Nov 2014 17:31:56 +0000
Subject: [LLVMbugs] [Bug 21578] wrong code at -Os and above on
	x86_64-linux-gnu (SCEV)
In-Reply-To: <bug-21578-206@http.llvm.org/bugs/>
References: <bug-21578-206@http.llvm.org/bugs/>
Message-ID: <bug-21578-206-j6vwc8dngo@http.llvm.org/bugs/>

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

Sanjay Patel <spatel+llvm at rotateright.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |spatel+llvm at rotateright.com
         Resolution|---                         |FIXED
            Summary|wrong code at -Os and above |wrong code at -Os and above
                   |on x86_64-linux-gnu         |on x86_64-linux-gnu (SCEV)

--- Comment #6 from Sanjay Patel <spatel+llvm at rotateright.com> ---
Marking as fixed. There was a 2nd related patch here:
http://llvm.org/viewvc/llvm-project?view=revision&revision=222104

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

From bugzilla-daemon at llvm.org  Tue Nov 18 09:46:40 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 18 Nov 2014 17:46:40 +0000
Subject: [LLVMbugs] [Bug 21596] New: Pointer to an address returned from
 function does not correlate to pointer to address in function. This causes
 access to different place in memory, than was expected.
Message-ID: <bug-21596-206@http.llvm.org/bugs/>

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

            Bug ID: 21596
           Summary: Pointer to an address returned from function does not
                    correlate to pointer to address in function. This
                    causes access to different place in memory, than was
                    expected.
           Product: clang
           Version: 3.5
          Hardware: Macintosh
                OS: MacOS X
            Status: NEW
          Severity: release blocker
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: jendas1 at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Version of llvm:
Apple LLVM version 6.0 (clang-600.0.54) (based on LLVM 3.5svn)
Code that shows the error:
#include <stdio.h>
#include <stdlib.h>

int ** create_2d_array (int size) {
    int ** array = (int **)malloc(sizeof(int)*size);
    printf("Address: 0x%llx\n", (long long) &array);
    for (int i = 0; i < size; i++) {
        array[i] = (int *)malloc(sizeof(int)*size);
        for (int j = 0; j < size; j++) {
            array[i][j] = 100;
            printf("%5d ", array[i][j]);
        }
        printf("\n");
    }
    return array;
}
void print_2d_array(int ** array, int size) {

    for (int i = 0; i < size; i++) {
        for (int j = 0; j < size; j++) {
            printf("%5d ", array[i][j]);
        }
        printf("\n");
    }
}
int main(int argc, const char * argv[]) {
    int ** array = create_2d_array(3);
    printf("Address: 0x%llx\n", (long long) &array);
    print_2d_array(array, 3);
    return 0;
}

Expected output is:

Address: something
  100   100   100 
  100   100   100 
  100   100   100 
Address: something
  100   100   100 
  100   100   100 
  100   100   100 

I've got:

Address: 0x7fff5fbff760
  100   100   100 
  100   100   100 
  100   100   100 
Address: 0x7fff5fbff788
1070432     1   100 
  100   100   100 
  100   100   100

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

From bugzilla-daemon at llvm.org  Tue Nov 18 10:04:00 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 18 Nov 2014 18:04:00 +0000
Subject: [LLVMbugs] [Bug 21596] Pointer to an address returned from function
 does not correlate to pointer to address in function. This causes access to
 different place in memory than was expected.
In-Reply-To: <bug-21596-206@http.llvm.org/bugs/>
References: <bug-21596-206@http.llvm.org/bugs/>
Message-ID: <bug-21596-206-4AC3EVna6s@http.llvm.org/bugs/>

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

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

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

--- Comment #1 from Richard Smith <richard-llvm at metafoo.co.uk> ---
You're taking the address of a local variable. Try replacing &array with array
in your printfs.

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

From bugzilla-daemon at llvm.org  Tue Nov 18 10:13:33 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 18 Nov 2014 18:13:33 +0000
Subject: [LLVMbugs] [Bug 21596] Pointer to an address returned from function
 does not correlate to pointer to address in function. This causes access to
 different place in memory than was expected.
In-Reply-To: <bug-21596-206@http.llvm.org/bugs/>
References: <bug-21596-206@http.llvm.org/bugs/>
Message-ID: <bug-21596-206-hC73YsKsfB@http.llvm.org/bugs/>

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

jendas1 at gmail.com changed:

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

--- Comment #2 from jendas1 at gmail.com ---
Yes, the addresses are now the same, but that wasn't the main bug I wanted to
issue. Main problem is that the values in the array are somewhat modified.
(check the first line in the output). When I run this program compiled by
another compiler it works as expected. (All values are 100).
Updated output (LLVM):
Address: 0x100105530
  100   100   100 
  100   100   100 
  100   100   100 
Address: 0x100105530
1070432     1   100 
  100   100   100 
  100   100   100

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

From bugzilla-daemon at llvm.org  Tue Nov 18 10:50:06 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 18 Nov 2014 18:50:06 +0000
Subject: [LLVMbugs] [Bug 21596] Modification of data pointed to by a pointer.
In-Reply-To: <bug-21596-206@http.llvm.org/bugs/>
References: <bug-21596-206@http.llvm.org/bugs/>
Message-ID: <bug-21596-206-peQTDI1GP1@http.llvm.org/bugs/>

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

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

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

--- Comment #4 from Anton Korobeynikov <asl at math.spbu.ru> ---
You also need to allocate memory properly. E.g. first malloc should be
malloc(sizeof(int*)*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/20141118/3bd13764/attachment.html>

From bugzilla-daemon at llvm.org  Tue Nov 18 10:50:30 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 18 Nov 2014 18:50:30 +0000
Subject: [LLVMbugs] [Bug 21597] New: Any regular expression should not match
 an empty sequence if match_not_null is specified
Message-ID: <bug-21597-206@http.llvm.org/bugs/>

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

            Bug ID: 21597
           Summary: Any regular expression should not match an empty
                    sequence if match_not_null is specified
           Product: libc++
           Version: unspecified
          Hardware: Other
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: All Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: kariya_mitsuru at hotmail.com
                CC: llvmbugs at cs.uiuc.edu, mclow.lists at gmail.com
    Classification: Unclassified

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

The sample code below should output "not match" but it outputs "match:0, 0" if
it is compiled by clang 3.6.0.

====================================================================================================
#include <iostream>
#include <regex>

int main()
{
    std::cmatch m;
    auto result = std::regex_search("a", m, std::regex("b*"),
std::regex_constants::match_not_null);
    if (result) {
        std::cout << "match:" << m.position() << ", " << m.length() <<
std::endl;
    } else {
        std::cout << "not match" << std::endl;
    }
}
====================================================================================================
cf. http://melpon.org/wandbox/permlink/TPxMmBQOGj7FsFMZ

According to C++11 standard 28.5.2[re.matchflag]/Table 139, "The expression
shall not match an empty sequence." if match_not_null is specified.


Note that the sample code of the Boost.regex version outputs "not match".
cf. http://melpon.org/wandbox/permlink/v1HhsIs8d2LrmUk9
(Sorry, It is compiled by gcc for restriction of Wandbox.)

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

From bugzilla-daemon at llvm.org  Tue Nov 18 11:59:52 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 18 Nov 2014 19:59:52 +0000
Subject: [LLVMbugs] [Bug 21594] [AArch64][FastISel] Generates invalid shift
 immediate greater than 31 (lsr w10, w8, #32)
In-Reply-To: <bug-21594-206@http.llvm.org/bugs/>
References: <bug-21594-206@http.llvm.org/bugs/>
Message-ID: <bug-21594-206-3PEmWIvIVE@http.llvm.org/bugs/>

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

Juergen Ributzka <juergen at apple.com> changed:

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

--- Comment #1 from Juergen Ributzka <juergen at apple.com> ---
Fixed in r222247.

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

From bugzilla-daemon at llvm.org  Tue Nov 18 12:01:38 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 18 Nov 2014 20:01:38 +0000
Subject: [LLVMbugs] [Bug 21600] New: [AArch64] Prefer tbz/tbnz before cmp+br
 in AND expression
Message-ID: <bug-21600-206@http.llvm.org/bugs/>

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

            Bug ID: 21600
           Summary: [AArch64] Prefer tbz/tbnz before cmp+br in AND
                    expression
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: ASSIGNED
          Severity: normal
          Priority: P
         Component: Backend: AArch64
          Assignee: mcrosier at codeaurora.org
          Reporter: mcrosier at codeaurora.org
                CC: kevinqindev at gmail.com, llvmbugs at cs.uiuc.edu,
                    t.p.northover at gmail.com
    Classification: Unclassified

Given the following IR,

  %cmp0 = icmp slt i64 %a, 0
  %cmp1 = icmp eq i32 %b, 1
  %and = and i1 %cmp0, %cmp1
  br i1 %and, label %if.then, label %if.end

the following assembly is generated:

        tbz     x0, #63, .LBB0_3
        cmp      w1, #1
        b.ne    .LBB0_3
        bl      t
.LBB0_3:                                // %if.end

However, if we commute the 'and' operands as such,

  %cmp0 = icmp slt i64 %a, 0
  %cmp1 = icmp eq i32 %b, 1
  %and = and i1 %cmp1, %cmp0
  br i1 %and, label %if.then, label %if.end

the following assembly is generated:

        cmp      w1, #1
        b.ne    .LBB1_3
        tbz     x0, #63, .LBB1_3
        bl      t
.LBB1_3:                                // %if.end

We should prefer the former code sequence by commuting the 'and' operands.

Complete test cases:
----------------------------------------------------------------------------
; RUN: llc -O1 -march=aarch64 < %s | FileCheck %s

declare void @t()

define void @test1(i64 %a, i32 %b) {
entry:
  %cmp0 = icmp slt i64 %a, 0
  %cmp1 = icmp eq i32 %b, 1
  %and = and i1 %cmp0, %cmp1
  br i1 %and, label %if.then, label %if.end

if.then:
  call void @t()
  br label %if.end

if.end:
  ret void
}

define void @test2(i64 %a, i32 %b) {
entry:
  %cmp0 = icmp slt i64 %a, 0
  %cmp1 = icmp eq i32 %b, 1
  %and = and i1 %cmp1, %cmp0
  br i1 %and, label %if.then, label %if.end

if.then:
  call void @t()
  br label %if.end

if.end:
  ret void
}

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

From bugzilla-daemon at llvm.org  Tue Nov 18 12:40:35 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 18 Nov 2014 20:40:35 +0000
Subject: [LLVMbugs] [Bug 20395] argument unused during compilation:
	'-stdlib=libc++'
In-Reply-To: <bug-20395-206@http.llvm.org/bugs/>
References: <bug-20395-206@http.llvm.org/bugs/>
Message-ID: <bug-20395-206-qBlInG2v7A@http.llvm.org/bugs/>

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

Eric Fiselier <eric at efcs.ca> changed:

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

--- Comment #2 from Eric Fiselier <eric at efcs.ca> ---
Fixed in r222252.

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

From bugzilla-daemon at llvm.org  Tue Nov 18 13:05:06 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 18 Nov 2014 21:05:06 +0000
Subject: [LLVMbugs] [Bug 20385] LLVM (through clang) doesn't distinguish
 between -fpic and -fPIC
In-Reply-To: <bug-20385-206@http.llvm.org/bugs/>
References: <bug-20385-206@http.llvm.org/bugs/>
Message-ID: <bug-20385-206-muuh5KQCQe@http.llvm.org/bugs/>

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

Justin Hibbits <chmeeedalf at gmail.com> changed:

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

--- Comment #3 from Justin Hibbits <chmeeedalf at gmail.com> ---
This is fixed in:
clang: r222227
llvm: r221510,221791,221792,221793

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

From bugzilla-daemon at llvm.org  Tue Nov 18 13:24:37 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 18 Nov 2014 21:24:37 +0000
Subject: [LLVMbugs] [Bug 21601] New: clang crashes on invalid(?) code
Message-ID: <bug-21601-206@http.llvm.org/bugs/>

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

            Bug ID: 21601
           Summary: clang crashes on invalid(?) code
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: t.poechtrager at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 13366
  --> http://llvm.org/bugs/attachment.cgi?id=13366&action=edit
preprocessed source file + runscript

$ cat crash.cpp
#include <unordered_map>
std::unordered_map<unsigned, unsigned> test[2] = {};
// or std::unordered_map<unsigned, unsigned> test[2]{};

---

Version: r222237 (3.5 seems also affected).

$ clang++ crash.cpp -std=c++11
#0 0x11fcf68 llvm::sys::PrintStackTrace(_IO_FILE*)
(/opt/other/llvm-trunk/bin/clang-3.6+0x11fcf68)
#1 0x11fe4eb SignalHandler(int) (/opt/other/llvm-trunk/bin/clang-3.6+0x11fe4eb)
#2 0x7fa56f41bc90 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0xfc90)
#3 0x1e62dd7 (anonymous
namespace)::InitListChecker::PerformEmptyInit(clang::Sema&,
clang::SourceLocation, clang::InitializedEntity const&, bool)
(/opt/other/llvm-trunk/bin/clang-3.6+0x1e62dd7)
#4 0x1e61e94 (anonymous
namespace)::InitListChecker::FillInEmptyInitializations(clang::InitializedEntity
const&, clang::InitListExpr*, bool&)
(/opt/other/llvm-trunk/bin/clang-3.6+0x1e61e94)
#5 0x1e5d50e (anonymous
namespace)::InitListChecker::InitListChecker(clang::Sema&,
clang::InitializedEntity const&, clang::InitListExpr*, clang::QualType&, bool)
(/opt/other/llvm-trunk/bin/clang-3.6+0x1e5d50e)
#6 0x1e54426 clang::InitializationSequence::Perform(clang::Sema&,
clang::InitializedEntity const&, clang::InitializationKind const&,
llvm::MutableArrayRef<clang::Expr*>, clang::QualType*)
(/opt/other/llvm-trunk/bin/clang-3.6+0x1e54426)
#7 0x1cb30fa clang::Sema::AddInitializerToDecl(clang::Decl*, clang::Expr*,
bool, bool) (/opt/other/llvm-trunk/bin/clang-3.6+0x1cb30fa)
#8 0x1a6c1a9
clang::Parser::ParseDeclarationAfterDeclaratorAndAttributes(clang::Declarator&,
clang::Parser::ParsedTemplateInfo const&, clang::Parser::ForRangeInit*)
(/opt/other/llvm-trunk/bin/clang-3.6+0x1a6c1a9)
#9 0x1a6a01f clang::Parser::ParseDeclGroup(clang::ParsingDeclSpec&, unsigned
int, bool, clang::SourceLocation*, clang::Parser::ForRangeInit*)
(/opt/other/llvm-trunk/bin/clang-3.6+0x1a6a01f)
#10 0x1a593da
clang::Parser::ParseDeclOrFunctionDefInternal(clang::Parser::ParsedAttributesWithRange&,
clang::ParsingDeclSpec&, clang::AccessSpecifier)
(/opt/other/llvm-trunk/bin/clang-3.6+0x1a593da)
#11 0x1a58eb0
clang::Parser::ParseDeclarationOrFunctionDefinition(clang::Parser::ParsedAttributesWithRange&,
clang::ParsingDeclSpec*, clang::AccessSpecifier)
(/opt/other/llvm-trunk/bin/clang-3.6+0x1a58eb0)
#12 0x1a58281
clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&,
clang::ParsingDeclSpec*) (/opt/other/llvm-trunk/bin/clang-3.6+0x1a58281)
#13 0x1a57528
clang::Parser::ParseTopLevelDecl(clang::OpaquePtr<clang::DeclGroupRef>&)
(/opt/other/llvm-trunk/bin/clang-3.6+0x1a57528)
#14 0x1a53ca6 clang::ParseAST(clang::Sema&, bool, bool)
(/opt/other/llvm-trunk/bin/clang-3.6+0x1a53ca6)
#15 0x137a219 clang::FrontendAction::Execute()
(/opt/other/llvm-trunk/bin/clang-3.6+0x137a219)
#16 0x134c7e3 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&)
(/opt/other/llvm-trunk/bin/clang-3.6+0x134c7e3)
#17 0x13f0229 clang::ExecuteCompilerInvocation(clang::CompilerInstance*)
(/opt/other/llvm-trunk/bin/clang-3.6+0x13f0229)
#18 0x6bafcc cc1_main(llvm::ArrayRef<char const*>, char const*, void*)
(/opt/other/llvm-trunk/bin/clang-3.6+0x6bafcc)
#19 0x6b9d69 main (/opt/other/llvm-trunk/bin/clang-3.6+0x6b9d69)
#20 0x7fa56e623ec5 __libc_start_main
/build/buildd/glibc-2.19/csu/libc-start.c:321:0
#21 0x6b6bda _start (/opt/other/llvm-trunk/bin/clang-3.6+0x6b6bda)
Stack dump:
0.      Program arguments: /opt/other/llvm-trunk/bin/clang-3.6 -cc1 -triple
x86_64-unknown-linux-gnu -emit-obj -mrelax-all -disable-free
-disable-llvm-verifier -main-file-name crash.cpp -mrelocation-model static
-mthread-model posix -mdisable-fp-elim -fmath-errno -masm-verbose
-mconstructor-aliases -munwind-tables -fuse-init-array -target-cpu x86-64
-dwarf-column-info -resource-dir /opt/other/llvm-trunk/bin/../lib/clang/3.6.0
-internal-isystem /usr/lib/gcc/x86_64-linux-gnu/4.9/../../../../include/c++/4.9
-internal-isystem
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../../include/x86_64-linux-gnu/c++/4.9
-internal-isystem
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../../include/x86_64-linux-gnu/c++/4.9
-internal-isystem
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../../include/c++/4.9/backward
-internal-isystem /usr/local/include -internal-isystem
/opt/other/llvm-trunk/bin/../lib/clang/3.6.0/include -internal-externc-isystem
/usr/include/x86_64-linux-gnu -internal-externc-isystem /include
-internal-externc-isystem /usr/include -std=c++11 -fdeprecated-macro
-fdebug-compilation-dir /home/thomas/tmp -ferror-limit 19 -fmessage-length 237
-mstackrealign -fobjc-runtime=gcc -fcxx-exceptions -fexceptions
-fdiagnostics-show-option -fcolor-diagnostics -o /tmp/crash-13cc96.o -x c++
crash.cpp 
1.      crash.cpp:2:52: current parser token ';'
clang-3.6: error: unable to execute command: Segmentation fault (core dumped)
clang-3.6: error: clang frontend command failed due to signal (use -v to see
invocation)
clang version 3.6.0 
Target: x86_64-unknown-linux-gnu
Thread model: posix
clang-3.6: 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.6: 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.6: note: diagnostic msg: /tmp/crash-a69667.cpp
clang-3.6: note: diagnostic msg: /tmp/crash-a69667.sh
clang-3.6: 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/20141118/edc0cdf9/attachment.html>

From bugzilla-daemon at llvm.org  Tue Nov 18 14:07:08 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 18 Nov 2014 22:07:08 +0000
Subject: [LLVMbugs] [Bug 21576] Infinite loop in opt -instcombine
In-Reply-To: <bug-21576-206@http.llvm.org/bugs/>
References: <bug-21576-206@http.llvm.org/bugs/>
Message-ID: <bug-21576-206-tGpbDFzuvy@http.llvm.org/bugs/>

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

David Majnemer <david.majnemer at gmail.com> changed:

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

--- Comment #4 from David Majnemer <david.majnemer at gmail.com> ---
Fixed in r222265.

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

From bugzilla-daemon at llvm.org  Tue Nov 18 15:04:41 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 18 Nov 2014 23:04:41 +0000
Subject: [LLVMbugs] [Bug 19793] c++1y tuple constructor mistakes arguments
 for allocator?
In-Reply-To: <bug-19793-206@http.llvm.org/bugs/>
References: <bug-19793-206@http.llvm.org/bugs/>
Message-ID: <bug-19793-206-UQxXVqh536@http.llvm.org/bugs/>

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

Eric Fiselier <eric at efcs.ca> changed:

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

--- Comment #8 from Eric Fiselier <eric at efcs.ca> ---
This bug was fixed in r219785, which was a resolution to bug #21157.
More test cases related to this bug were added in r222278.

Closing as RESOLVED 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/20141118/cf921961/attachment.html>

From bugzilla-daemon at llvm.org  Tue Nov 18 15:54:38 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 18 Nov 2014 23:54:38 +0000
Subject: [LLVMbugs] [Bug 21602] New: Typo correction fails to mention a
 template by the same name
Message-ID: <bug-21602-206@http.llvm.org/bugs/>

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

            Bug ID: 21602
           Summary: Typo correction fails to mention a template by the
                    same name
           Product: clang
           Version: unspecified
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
          Assignee: rikka at google.com
          Reporter: dblaikie at gmail.com
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Attempting to use StringSet (a template with a single default type argument) I
got this error:

llvm/src/tools/clang/lib/ARCMigrate/ObjCMT.cpp:104:9: error: no type named
'StringSet' in namespace 'llvm'; did you mean 'StringRef'?
  llvm::StringSet WhiteListFilenames;
  ~~~~~~^~~~~~~~~
        StringRef

All I really needed was to put "<>" after "StringSet" and it compiles/does what
I want.

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

From bugzilla-daemon at llvm.org  Tue Nov 18 17:56:49 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 19 Nov 2014 01:56:49 +0000
Subject: [LLVMbugs] [Bug 21603] New: Codegen error for uitofp <4 x i32> %2
 to <4 x double> on AVX.
Message-ID: <bug-21603-206@http.llvm.org/bugs/>

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

            Bug ID: 21603
           Summary: Codegen error for uitofp <4 x i32> %2 to <4 x double>
                    on AVX.
           Product: new-bugs
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: zalman at google.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 13368
  --> http://llvm.org/bugs/attachment.cgi?id=13368&action=edit
llvm assembly for the erroneous case

The attached test generates incorrect output when compiled with:
    clang -O -mavx ~/llvm_bug.ll ~/llvm_bug_test.c -o /tmp/foo
and correct output when compiled with:
    clang -O ~/llvm_bug.ll ~/llvm_bug_test.c -o /tmp/foo

(On an x86 system.)

This bug was originally found in a Halide test case and repros on Linux and Mac
OS.

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

From bugzilla-daemon at llvm.org  Tue Nov 18 21:59:26 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 19 Nov 2014 05:59:26 +0000
Subject: [LLVMbugs] [Bug 21604] New: crash after "error in backend: Broken
 function found"
Message-ID: <bug-21604-206@http.llvm.org/bugs/>

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

            Bug ID: 21604
           Summary: crash after "error in backend: Broken function found"
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: eocallaghan at alterapraxis.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

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

Attributes 'optsize and optnone' are incompatible!
i8* ()* @find_fsp
fatal error: error in backend: Broken function found, compilation aborted!

Test case 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/20141119/d655f02f/attachment.html>

From bugzilla-daemon at llvm.org  Wed Nov 19 00:27:49 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 19 Nov 2014 08:27:49 +0000
Subject: [LLVMbugs] [Bug 21605] New: Parsing error when including meta.hpp
 from github.com/ericniebler/range-v3/
Message-ID: <bug-21605-206@http.llvm.org/bugs/>

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

            Bug ID: 21605
           Summary: Parsing error when including meta.hpp from
                    github.com/ericniebler/range-v3/
           Product: clang
           Version: trunk
          Hardware: Macintosh
                OS: MacOS X
            Status: NEW
          Severity: release blocker
          Priority: P
         Component: Frontend
          Assignee: unassignedclangbugs at nondot.org
          Reporter: anders at sjogren.info
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

When trying to include Eric Niebler's Ranges library (which is the
implementation of the D4128 Standard library proposal,
https://ericniebler.github.io/std/wg21/D4128.html), a parsing error occurs
using clang 3.6(trunk 216817), while for clang 3.5 (as shipped by Apple) it
works fine.

Repro-steps:
--1--
Get ranges library from
https://github.com/ericniebler/range-v3/tree/25a773c8690c990c6a3ebd654981946953b1f86b

--2--
cd range-v3/include/

--3--
Create test.cpp:
#include "range/v3/utility/meta.hpp"
int main(int argc, const char* argv[]){
  return 0;
}

--4--
Try to compile:
clang -I. -std=c++11 test.cpp

Result:
Assertion failed: (Replacement.isCanonical() && "replacement types must always
be canonical"), function getSubstTemplateTypeParmType, file ASTContext.cpp,
line 3047.
0  libLLVM-3.6svn.dylib     0x0000000104c8b71f
llvm::sys::PrintStackTrace(__sFILE*) + 40
1  libLLVM-3.6svn.dylib     0x0000000104c8badf SignalHandler(int) + 205
2  libsystem_platform.dylib 0x00007fff931abf1a _sigtramp + 26
3  libsystem_platform.dylib 0x00007fff6ad96764 _sigtramp + 3619596388
4  libLLVM-3.6svn.dylib     0x0000000104c8b971 abort + 22
5  libLLVM-3.6svn.dylib     0x0000000104c8b95b abort + 0
6  clang                    0x000000010331de3a
clang::ASTContext::getSubstTemplateTypeParmPackType(clang::TemplateTypeParmType
const*, clang::TemplateArgument const&) + 0
7  clang                    0x0000000102f956d6 clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformType(clang::TypeLocBuilder&,
clang::TypeLoc) + 6570
8  clang                    0x0000000102f93aa0 clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformType(clang::TypeSourceInfo*) + 192
9  clang                    0x0000000102f9fe5b clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformTemplateArgument(clang::TemplateArgumentLoc
const&, clang::TemplateArgumentLoc&) + 119
10 clang                    0x0000000102fa1b51 bool
clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformTemplateArguments<clang::TemplateArgumentLocContainerIterator<clang::DependentTemplateSpecializationTypeLoc>
>(clang::TemplateArgumentLocContainerIterator<clang::DependentTemplateSpecializationTypeLoc>,
clang::TemplateArgumentLocContainerIterator<clang::DependentTemplateSpecializationTypeLoc>,
clang::TemplateArgumentListInfo&) + 829
11 clang                    0x0000000102fb2ef6 clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformDependentTemplateSpecializationType(clang::TypeLocBuilder&,
clang::DependentTemplateSpecializationTypeLoc, clang::NestedNameSpecifierLoc) +
174
12 clang                    0x0000000102f95c48 clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformType(clang::TypeLocBuilder&,
clang::TypeLoc) + 7964
13 clang                    0x0000000102f93aa0 clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformType(clang::TypeSourceInfo*) + 192
14 clang                    0x0000000102f97238 clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformType(clang::QualType) + 52
15 clang                    0x0000000102f9718f
clang::Sema::SubstType(clang::QualType, clang::MultiLevelTemplateArgumentList
const&, clang::SourceLocation, clang::DeclarationName) + 107
16 clang                    0x0000000102f33cc7
clang::Sema::CheckTemplateIdType(clang::TemplateName, clang::SourceLocation,
clang::TemplateArgumentListInfo&) + 1669
17 clang                    0x0000000102f34d0a
clang::Sema::ActOnTemplateIdType(clang::CXXScopeSpec&, clang::SourceLocation,
clang::OpaquePtr<clang::TemplateName>, clang::SourceLocation,
clang::SourceLocation, llvm::MutableArrayRef<clang::ParsedTemplateArgument>,
clang::SourceLocation, bool) + 594
18 clang                    0x0000000102cd4ac5
clang::Parser::AnnotateTemplateIdTokenAsType() + 143
19 clang                    0x0000000102c8a8f8
clang::Parser::ParseDeclarationSpecifiers(clang::DeclSpec&,
clang::Parser::ParsedTemplateInfo const&, clang::AccessSpecifier,
clang::Parser::DeclSpecContext, clang::Parser::LateParsedAttrList*) + 2632
20 clang                    0x0000000102c83dc6
clang::Parser::ParseSpecifierQualifierList(clang::DeclSpec&,
clang::AccessSpecifier, clang::Parser::DeclSpecContext) + 68
21 clang                    0x0000000102c83c11
clang::Parser::ParseTypeName(clang::SourceRange*,
clang::Declarator::TheContext, clang::AccessSpecifier, clang::Decl**,
clang::ParsedAttributes*) + 285
22 clang                    0x0000000102c9930a
clang::Parser::ParseUsingDeclaration(unsigned int,
clang::Parser::ParsedTemplateInfo const&, clang::SourceLocation,
clang::SourceLocation&, clang::AccessSpecifier, clang::Decl**) + 2254
23 clang                    0x0000000102c9ebe7
clang::Parser::ParseCXXClassMemberDeclaration(clang::AccessSpecifier,
clang::AttributeList*, clang::Parser::ParsedTemplateInfo const&,
clang::ParsingDeclRAIIObject*) + 1823
24 clang                    0x0000000102cd1d16
clang::Parser::ParseSingleDeclarationAfterTemplate(unsigned int,
clang::Parser::ParsedTemplateInfo const&, clang::ParsingDeclRAIIObject&,
clang::SourceLocation&, clang::AccessSpecifier, clang::AttributeList*) + 298
25 clang                    0x0000000102cd1947
clang::Parser::ParseTemplateDeclarationOrSpecialization(unsigned int,
clang::SourceLocation&, clang::AccessSpecifier, clang::AttributeList*) + 777
26 clang                    0x0000000102cd151f
clang::Parser::ParseDeclarationStartingWithTemplate(unsigned int,
clang::SourceLocation&, clang::AccessSpecifier, clang::AttributeList*) + 95
27 clang                    0x0000000102c9e874
clang::Parser::ParseCXXClassMemberDeclaration(clang::AccessSpecifier,
clang::AttributeList*, clang::Parser::ParsedTemplateInfo const&,
clang::ParsingDeclRAIIObject*) + 940
28 clang                    0x0000000102c9d008
clang::Parser::ParseCXXMemberSpecification(clang::SourceLocation,
clang::SourceLocation, clang::Parser::ParsedAttributesWithRange&, unsigned int,
clang::Decl*) + 1596
29 clang                    0x0000000102c9c54f
clang::Parser::ParseClassSpecifier(clang::tok::TokenKind,
clang::SourceLocation, clang::DeclSpec&, clang::Parser::ParsedTemplateInfo
const&, clang::AccessSpecifier, bool, clang::Parser::DeclSpecContext,
clang::Parser::ParsedAttributesWithRange&) + 6053
30 clang                    0x0000000102c8a46a
clang::Parser::ParseDeclarationSpecifiers(clang::DeclSpec&,
clang::Parser::ParsedTemplateInfo const&, clang::AccessSpecifier,
clang::Parser::DeclSpecContext, clang::Parser::LateParsedAttrList*) + 1466
31 clang                    0x0000000102cd1e0e
clang::Parser::ParseSingleDeclarationAfterTemplate(unsigned int,
clang::Parser::ParsedTemplateInfo const&, clang::ParsingDeclRAIIObject&,
clang::SourceLocation&, clang::AccessSpecifier, clang::AttributeList*) + 546
32 clang                    0x0000000102cd1947
clang::Parser::ParseTemplateDeclarationOrSpecialization(unsigned int,
clang::SourceLocation&, clang::AccessSpecifier, clang::AttributeList*) + 777
33 clang                    0x0000000102cd151f
clang::Parser::ParseDeclarationStartingWithTemplate(unsigned int,
clang::SourceLocation&, clang::AccessSpecifier, clang::AttributeList*) + 95
34 clang                    0x0000000102c89bde
clang::Parser::ParseDeclaration(llvm::SmallVector<clang::Stmt*, 32u>&, unsigned
int, clang::SourceLocation&, clang::Parser::ParsedAttributesWithRange&) + 392
35 clang                    0x0000000102cda0ba
clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&,
clang::ParsingDeclSpec*) + 1966
36 clang                    0x0000000102c981da
clang::Parser::ParseInnerNamespace(std::__1::vector<clang::SourceLocation,
std::__1::allocator<clang::SourceLocation> >&,
std::__1::vector<clang::IdentifierInfo*,
std::__1::allocator<clang::IdentifierInfo*> >&,
std::__1::vector<clang::SourceLocation,
std::__1::allocator<clang::SourceLocation> >&, unsigned int,
clang::SourceLocation&, clang::ParsedAttributes&,
clang::BalancedDelimiterTracker&) + 174
37 clang                    0x0000000102c97eb7
clang::Parser::ParseNamespace(unsigned int, clang::SourceLocation&,
clang::SourceLocation) + 3763
38 clang                    0x0000000102c89b45
clang::Parser::ParseDeclaration(llvm::SmallVector<clang::Stmt*, 32u>&, unsigned
int, clang::SourceLocation&, clang::Parser::ParsedAttributesWithRange&) + 239
39 clang                    0x0000000102cda12b
clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&,
clang::ParsingDeclSpec*) + 2079
40 clang                    0x0000000102c981da
clang::Parser::ParseInnerNamespace(std::__1::vector<clang::SourceLocation,
std::__1::allocator<clang::SourceLocation> >&,
std::__1::vector<clang::IdentifierInfo*,
std::__1::allocator<clang::IdentifierInfo*> >&,
std::__1::vector<clang::SourceLocation,
std::__1::allocator<clang::SourceLocation> >&, unsigned int,
clang::SourceLocation&, clang::ParsedAttributes&,
clang::BalancedDelimiterTracker&) + 174
41 clang                    0x0000000102c97eb7
clang::Parser::ParseNamespace(unsigned int, clang::SourceLocation&,
clang::SourceLocation) + 3763
42 clang                    0x0000000102c89b45
clang::Parser::ParseDeclaration(llvm::SmallVector<clang::Stmt*, 32u>&, unsigned
int, clang::SourceLocation&, clang::Parser::ParsedAttributesWithRange&) + 239
43 clang                    0x0000000102cda0ba
clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&,
clang::ParsingDeclSpec*) + 1966
44 clang                    0x0000000102cd98b3
clang::Parser::ParseTopLevelDecl(clang::OpaquePtr<clang::DeclGroupRef>&) + 329
45 clang                    0x0000000102c808ad clang::ParseAST(clang::Sema&,
bool, bool) + 332
46 clang                    0x0000000102c1389b
clang::CodeGenAction::ExecuteAction() + 563
47 clang                    0x00000001029f5493 clang::FrontendAction::Execute()
+ 67
48 clang                    0x00000001029d211a
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 544
49 clang                    0x00000001029a23c0
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 3912
50 clang                    0x000000010299ab0e cc1_main(llvm::ArrayRef<char
const*>, char const*, void*) + 1054
51 clang                    0x00000001029a0766 main + 8179
52 libdyld.dylib            0x00007fff870505c9 start + 1
Stack dump:
0.    Program arguments: /opt/local/libexec/llvm-3.6/bin/clang -cc1 -triple
x86_64-apple-macosx10.10.0 -emit-obj -mrelax-all -disable-free -main-file-name
test.cpp -mrelocation-model pic -pic-level 2 -mdisable-fp-elim -masm-verbose
-munwind-tables -target-cpu core2 -target-linker-version 236.3
-dwarf-column-info -resource-dir
/opt/local/libexec/llvm-3.6/bin/../lib/clang/3.6.0 -I . -stdlib=libc++
-std=c++11 -fdeprecated-macro -fdebug-compilation-dir
/Users/d97sjan/Dropbox/src/cpp/bigdata_regression/include -ferror-limit 19
-fmessage-length 162 -stack-protector 1 -mstackrealign -fblocks
-fobjc-runtime=macosx-10.10.0 -fencode-extended-block-signature
-fcxx-exceptions -fexceptions -fmax-type-align=16 -fdiagnostics-show-option
-fcolor-diagnostics -o
/var/folders/zj/615n13hn0b79rs3jb2m7zdtc0000gn/T/test-e6ef3f.o -x c++ test.cpp 
1.    ./range/v3/utility/meta.hpp:120:27: at annotation token
2.    ./range/v3/utility/meta.hpp:18:1: parsing namespace 'ranges'
3.    ./range/v3/utility/meta.hpp:20:12: parsing namespace 'v3'
4.    ./range/v3/utility/meta.hpp:117:9: parsing struct/union/class body
'meta_bind_front'
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.6.0 (trunk 216817)
Target: x86_64-apple-darwin14.0.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: 
********************

===Specifics on version===
--Causing bug--
clang 3.6 from macports (updated 2014-11-19)
clang-3.6 @3.6-r216817 lang/llvm-3.6
$ clang --version
clang version 3.6.0 (trunk 216817)
Target: x86_64-apple-darwin14.0.0
Thread model: posix

--Working--
$ /usr/bin/clang --version
Apple LLVM version 6.0 (clang-600.0.54) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin14.0.0
Thread model: posix

===Preprocessed data===
Source test-806ba4.cpp: 
attached as file

Run script test-806ba4.sh: 
"/opt/local/libexec/llvm-3.6/bin/clang" -cc1 -triple x86_64-apple-macosx10.10.0
-emit-obj -mrelax-all -disable-free -main-file-name test.cpp -mrelocation-model
pic -pic-level 2 -mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu
core2 -target-linker-version 236.3 -dwarf-column-info -stdlib=libc++ -std=c++11
-fdeprecated-macro -ferror-limit 19 -fmessage-length 162 -stack-protector 1
-mstackrealign -fblocks -fobjc-runtime=macosx-10.10.0
-fencode-extended-block-signature -fcxx-exceptions -fexceptions
-fmax-type-align=16 -fdiagnostics-show-option -fcolor-diagnostics -x c++
test-806ba4.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/20141119/1ee43ddf/attachment.html>

From bugzilla-daemon at llvm.org  Wed Nov 19 01:41:36 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 19 Nov 2014 09:41:36 +0000
Subject: [LLVMbugs] [Bug 21582] wrong code at -O1 and above on
	x86_64-linux-gnu
In-Reply-To: <bug-21582-206@http.llvm.org/bugs/>
References: <bug-21582-206@http.llvm.org/bugs/>
Message-ID: <bug-21582-206-KCZ7WntLx7@http.llvm.org/bugs/>

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

David Majnemer <david.majnemer at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED
           Assignee|unassignedclangbugs at nondot. |david.majnemer at gmail.com
                   |org                         |

--- Comment #6 from David Majnemer <david.majnemer at gmail.com> ---
Fixed in r222338.

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

From bugzilla-daemon at llvm.org  Wed Nov 19 02:43:06 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 19 Nov 2014 10:43:06 +0000
Subject: [LLVMbugs] [Bug 21605] Parsing error when including meta.hpp from
 github.com/ericniebler/range-v3/
In-Reply-To: <bug-21605-206@http.llvm.org/bugs/>
References: <bug-21605-206@http.llvm.org/bugs/>
Message-ID: <bug-21605-206-dxpC8qaiwx@http.llvm.org/bugs/>

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

David Majnemer <david.majnemer at gmail.com> changed:

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

--- Comment #3 from David Majnemer <david.majnemer at gmail.com> ---
This was fixed in r221832.

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

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

From bugzilla-daemon at llvm.org  Wed Nov 19 04:23:29 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 19 Nov 2014 12:23:29 +0000
Subject: [LLVMbugs] [Bug 21607] New: Use-of-uninitialized-value in
	MachODump.cpp
Message-ID: <bug-21607-206@http.llvm.org/bugs/>

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

            Bug ID: 21607
           Summary: Use-of-uninitialized-value in MachODump.cpp
           Product: tools
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: llvm-dis
          Assignee: unassignedbugs at nondot.org
          Reporter: eugeni.stepanov at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

./bin/llvm-objdump -d -m -no-show-raw-insn -full-leading-addr -print-imm-hex
../test/tools/llvm-objdump/AArch64/Inputs/hello.obj.macho-aarch64

../test/tools/llvm-objdump/AArch64/Inputs/hello.obj.macho-aarch64:

ltmp0:
_main:
0000000000000000    stp    x29, x30, [sp, #-16]!
0000000000000004==16907== WARNING: MemorySanitizer: use-of-uninitialized-value
    #0 0x7f631da2c3b2 in SymbolizerSymbolLookUp(void*, unsigned long, unsigned
long*, unsigned long, char const**)
/code/llvm/build-msan/../tools/llvm-objdump/MachODump.cpp:1472:14
    #1 0x7f631dc2c2c6 in
llvm::AArch64ExternalSymbolizer::tryAddingSymbolicOperand(llvm::MCInst&,
llvm::raw_ostream&, long, unsigned long, bool, unsigned long, unsigned long)
/code/llvm/build-msan/../lib/Target/AArch64/Disassembler/AArch64ExternalSymbolizer.cpp:131:9
    #2 0x7f631e546f77 in
llvm::MCDisassembler::tryAddingSymbolicOperand(llvm::MCInst&, long, unsigned
long, bool, unsigned long, unsigned long) const
/code/llvm/build-msan/../lib/MC/MCDisassembler/MCDisassembler.cpp:25:12
    #3 0x7f631dc0b1e5 in DecodeBaseAddSubImm
/code/llvm/build-msan/../lib/Target/AArch64/Disassembler/AArch64Disassembler.cpp:1473:8
    #4 0x7f631dc0b1e5 in llvm::MCDisassembler::DecodeStatus
llvm::decodeToMCInst<unsigned int>(llvm::MCDisassembler::DecodeStatus, unsigned
int, unsigned int, llvm::MCInst&, unsigned long, void const*)
/code/llvm/build-msan/lib/Target/AArch64/AArch64GenDisassemblerTables.inc:11576
    #5 0x7f631dba5350 in decodeInstruction<unsigned int>
/code/llvm/build-msan/lib/Target/AArch64/AArch64GenDisassemblerTables.inc:12753:14
    #6 0x7f631dba5350 in
llvm::AArch64Disassembler::getInstruction(llvm::MCInst&, unsigned long&,
llvm::ArrayRef<unsigned char>, unsigned long, llvm::raw_ostream&,
llvm::raw_ostream&) const
/code/llvm/build-msan/../lib/Target/AArch64/Disassembler/AArch64Disassembler.cpp:219
    #7 0x7f631da142bd in DisassembleInputMachO2(llvm::StringRef,
llvm::object::MachOObjectFile*)
/code/llvm/build-msan/../tools/llvm-objdump/MachODump.cpp:1924:21
    #8 0x7f631da08a71 in llvm::DisassembleInputMachO(llvm::StringRef)
/code/llvm/build-msan/../tools/llvm-objdump/MachODump.cpp:259:3
    #9 0x7f631d9c6925 in DumpInput
/code/llvm/build-msan/../tools/llvm-objdump/llvm-objdump.cpp:835:5
    #10 0x7f631d9c6925 in
for_each<std::__1::__wrap_iter<std::__1::basic_string<char> *>, void
(*)(llvm::StringRef)> /code/llvm/build/bin/../include/c++/v1/algorithm:853
    #11 0x7f631d9c6925 in main
/code/llvm/build-msan/../tools/llvm-objdump/llvm-objdump.cpp:895
    #12 0x7f631b8ecec4 in __libc_start_main
/build/buildd/eglibc-2.19/csu/libc-start.c:287
    #13 0x7f631d976d6a in _start
(/code/llvm/build-msan/bin/llvm-objdump+0x15bd6a)

  Uninitialized value was created by an allocation of 'SymbolizerInfo' in the
stack frame of function
'_ZL22DisassembleInputMachO2N4llvm9StringRefEPNS_6object15MachOObjectFileE'
    #0 0x7f631da09410 in DisassembleInputMachO2(llvm::StringRef,
llvm::object::MachOObjectFile*)
/code/llvm/build-msan/../tools/llvm-objdump/MachODump.cpp:1589

SymbolizerInfo has 2 uninitialized fields at this point: adrp_addr and
adrp_inst.

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

From bugzilla-daemon at llvm.org  Wed Nov 19 07:33:52 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 19 Nov 2014 15:33:52 +0000
Subject: [LLVMbugs] [Bug 18846] needless avx spill/reload
In-Reply-To: <bug-18846-206@http.llvm.org/bugs/>
References: <bug-18846-206@http.llvm.org/bugs/>
Message-ID: <bug-18846-206-5TVtTjPNwE@http.llvm.org/bugs/>

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

Simon Pilgrim <llvm-dev at redking.me.uk> changed:

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

--- Comment #4 from Simon Pilgrim <llvm-dev at redking.me.uk> ---
Fixed in rL222281

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

From bugzilla-daemon at llvm.org  Wed Nov 19 08:04:40 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 19 Nov 2014 16:04:40 +0000
Subject: [LLVMbugs] [Bug 21608] New: [mips] Small structures handled
 incorrectly by va_arg() for all big-endian ABI's
Message-ID: <bug-21608-206@http.llvm.org/bugs/>

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

            Bug ID: 21608
           Summary: [mips] Small structures handled incorrectly by
                    va_arg() for all big-endian ABI's
           Product: new-bugs
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: daniel.sanders at imgtec.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

For example:
  struct f {
    char a;
  };
is only handled correctly for the first va_arg() call.

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

From bugzilla-daemon at llvm.org  Wed Nov 19 09:11:47 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 19 Nov 2014 17:11:47 +0000
Subject: [LLVMbugs] [Bug 21609] New: [AsmPrinter] DwarfFile: Assertion
 `(LS->getParent() || CurNum != ArgNum) && "Duplicate argument for top level
 (non-inlined) function"' failed.
Message-ID: <bug-21609-206@http.llvm.org/bugs/>

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

            Bug ID: 21609
           Summary: [AsmPrinter] DwarfFile: Assertion `(LS->getParent() ||
                    CurNum != ArgNum) && "Duplicate argument for top level
                    (non-inlined) function"' failed.
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: AArch64
          Assignee: unassignedbugs at nondot.org
          Reporter: mcrosier at codeaurora.org
                CC: apazos at codeaurora.org, dblaikie at gmail.com,
                    llvmbugs at cs.uiuc.edu
    Classification: Unclassified

llvm/lib/CodeGen/AsmPrinter/DwarfFile.cpp:177: void
llvm::DwarfFile::addScopeVariable(llvm::LexicalScope*, llvm::DbgVariable*):
Assertion `(LS->getParent() || CurNum != ArgNum) && "Duplicate argument for top
level (non-inlined) function"' failed.

Reduced test case:

struct S {
  int m;
  S(int i) : m(i) {}

  int f
(int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,!
 int,int,i
 nt,int,int,int,int,int,char)
const { return 0; }
};

int main(void) {
  const S s(0);
  return
s.f(1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1);
}

Reproduce with:
clang-3.6 "-cc1" "-triple" "aarch64--linux-gnu" "-emit-obj" "-mrelax-all"
"-disable-free" "-main-file-name" "foo.ii" "-mrelocation-model" "static"
"-mthread-model" "posix" "-mdisable-fp-elim" "-fmath-errno" "-masm-verbose"
"-mconstructor-aliases" "-fuse-init-array" "-target-cpu" "cortex-a57"
"-target-feature" "+neon" "-target-feature" "+crc" "-target-feature" "+crypto"
"-target-abi" "aapcs" "-g" "-dwarf-column-info" "-coverage-file"
"/prj/llvm-arm/home/mrosier/foo.o" "-O0" "-fdeprecated-macro" "-ferror-limit"
"19" "-fmessage-length" "267" "-mstackrealign"
"-fallow-half-arguments-and-returns" "-fno-signed-char" "-fobjc-runtime=gcc"
"-fcxx-exceptions" "-fexceptions" "-fdiagnostics-show-option"
"-fcolor-diagnostics" "-o" "foo.o" "-x" "c++-cpp-output" "foo.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/20141119/8db6f928/attachment.html>

From bugzilla-daemon at llvm.org  Wed Nov 19 11:31:31 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 19 Nov 2014 19:31:31 +0000
Subject: [LLVMbugs] [Bug 20728] APFloat::fusedMultiplyAdd is broken,
 leading to incorrect constant folding for libc fmal calls.
In-Reply-To: <bug-20728-206@http.llvm.org/bugs/>
References: <bug-20728-206@http.llvm.org/bugs/>
Message-ID: <bug-20728-206-hbYf54ImSc@http.llvm.org/bugs/>

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

Lang Hames <lhames at gmail.com> changed:

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

--- Comment #6 from Lang Hames <lhames at gmail.com> ---
Fixed in r222374.

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

From bugzilla-daemon at llvm.org  Wed Nov 19 11:42:55 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 19 Nov 2014 19:42:55 +0000
Subject: [LLVMbugs] [Bug 21511] Spurious DWARF tag for static const member
In-Reply-To: <bug-21511-206@http.llvm.org/bugs/>
References: <bug-21511-206@http.llvm.org/bugs/>
Message-ID: <bug-21511-206-t5hKXshHEP@http.llvm.org/bugs/>

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

David Blaikie <dblaikie at gmail.com> changed:

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

--- Comment #2 from David Blaikie <dblaikie at gmail.com> ---
Fixed in r222377

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

From bugzilla-daemon at llvm.org  Wed Nov 19 12:25:06 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 19 Nov 2014 20:25:06 +0000
Subject: [LLVMbugs] [Bug 21607] Use-of-uninitialized-value in MachODump.cpp
In-Reply-To: <bug-21607-206@http.llvm.org/bugs/>
References: <bug-21607-206@http.llvm.org/bugs/>
Message-ID: <bug-21607-206-C3dVpSZ774@http.llvm.org/bugs/>

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

Kevin Enderby <enderby at apple.com> changed:

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

--- Comment #3 from Kevin Enderby <enderby at apple.com> ---
Fixed with commit r222385.

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

From bugzilla-daemon at llvm.org  Wed Nov 19 12:48:15 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 19 Nov 2014 20:48:15 +0000
Subject: [LLVMbugs] [Bug 21610] New: Different IR if intermediate variable
 used for fcmp + select
Message-ID: <bug-21610-206@http.llvm.org/bugs/>

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

            Bug ID: 21610
           Summary: Different IR if intermediate variable used for fcmp +
                    select
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Scalar Optimizations
          Assignee: unassignedbugs at nondot.org
          Reporter: Matthew.Arsenault at amd.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

I expect these 2 functions to produce the same optimized IR, but they currently
end up using a different fcmp type.


float max_uge_f32_0(float a, float b)
{
    bool cmp = !(a < b);
    return cmp ? b : a;
}

float max_uge_f32_2(float a, float b)
{
    return !(a < b) ? b : a;
}


clang -O3 for this produces:


define float @max_uge_f32_0(float %a, float %b) #0 {
  %1 = fcmp uge float %a, %b
  %2 = select i1 %1, float %b, float %a
  ret float %2
}

define float @max_uge_f32_2(float %a, float %b) #0 {
  %1 = fcmp olt float %a, %b
  %2 = select i1 %1, float %a, float %b
  ret float %2
}

I expect the second's results for the first, swapping the select operands and
using the ordered comparison. However, the first version is using the original
select order with the unordered compare.

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

From bugzilla-daemon at llvm.org  Wed Nov 19 22:41:56 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 20 Nov 2014 06:41:56 +0000
Subject: [LLVMbugs] [Bug 21611] New: Reassociate: nsw/nuw dropped when
 merging add into mul
Message-ID: <bug-21611-206@http.llvm.org/bugs/>

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

            Bug ID: 21611
           Summary: Reassociate: nsw/nuw dropped when merging add into mul
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Scalar Optimizations
          Assignee: unassignedbugs at nondot.org
          Reporter: david.majnemer at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

consider:
define i32 @triple_i(i32 %x) {
  %1 = add nsw i32 %x, %x
  %2 = add nsw i32 %1, %x
  ret i32 %2
}

after running with opt -reassociate:
define i32 @triple_i(i32 %x) {
  %factor = mul i32 %x, 3
  ret i32 %factor
}

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

From bugzilla-daemon at llvm.org  Thu Nov 20 01:39:34 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 20 Nov 2014 09:39:34 +0000
Subject: [LLVMbugs] [Bug 21612] New: .d files should contain relative paths
 if relative paths are specified in the module map
Message-ID: <bug-21612-206@http.llvm.org/bugs/>

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

            Bug ID: 21612
           Summary: .d files should contain relative paths if relative
                    paths are specified in the module map
           Product: clang
           Version: unspecified
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Modules
          Assignee: unassignedclangbugs at nondot.org
          Reporter: klimek at google.com
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Basic test (minus correct CHECK line ;)

test/Modules/dependency-gen.cppmap:
// RUN: cd %S
// RUN: %clang_cc1 -x c++ -fmodule-name=test -emit-module dependency-gen.cppmap
dependency-file %t.d -MT %t.pcm
// RUN: FileCheck %s < %t.d
module "test" {
  header "Inputs/dependency-gen.h"
}

Currently the .d file will contain the absolute path to
Inputs/dependency-gen.h, which is explicitly done when we create the C++ code
buffer with the #include lines.
The relative path in the module file means "relatively to the module file",
which is actually very similar to how -include directives are handled. The main
reason we can't trigger the same code path as -include currently is that we
don't have a file, as the code we parse is in a virtual buffer, which has no
way to point back to the module map file.

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

From bugzilla-daemon at llvm.org  Thu Nov 20 02:39:30 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 20 Nov 2014 10:39:30 +0000
Subject: [LLVMbugs] [Bug 21613] New: Clang MIPS: invalid input constraint
	'0' in asm
Message-ID: <bug-21613-206@http.llvm.org/bugs/>

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

            Bug ID: 21613
           Summary: Clang MIPS: invalid input constraint '0' in asm
           Product: clang
           Version: 3.5
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: npennequ at cisco.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

When compiling a file that includes linux_syscall_support.h[1] for MIPS
(-target mipsel-linux-uclibc -march=mips32), the following errors occur:

./linux_syscall_support.h:2977:14: error: invalid input constraint '0' in asm
  LSS_INLINE _syscall1(void *,  brk,             void *,      e)
             ^
./linux_syscall_support.h:2596:27: note: expanded from macro '_syscall1'
        LSS_REG(4, arg1); LSS_BODY(type, name, "=r", "r"(__r4));              \
                          ^
./linux_syscall_support.h:2583:35: note: expanded from macro 'LSS_BODY'
                                : "0"(__v0), ##__VA_ARGS__                    \
                                  ^
./linux_syscall_support.h:2978:14: error: invalid input constraint '0' in asm
  LSS_INLINE _syscall1(int,     chdir,           const char *,p)
             ^
./linux_syscall_support.h:2596:27: note: expanded from macro '_syscall1'
        LSS_REG(4, arg1); LSS_BODY(type, name, "=r", "r"(__r4));              \
                          ^
./linux_syscall_support.h:2583:35: note: expanded from macro 'LSS_BODY'
                                : "0"(__v0), ##__VA_ARGS__                    \
                                  ^

(many more of the same follow)

The same code compiles without error using mipsel-linux-uclibc-gcc 4.5.3 and
4.8.3.

$ clang --version
clang version 3.5.0 (trunk 214024)
Target: x86_64-unknown-linux-gnu
Thread model: posix

[1]
https://code.google.com/p/linux-syscall-support/source/browse/trunk/lss/linux_syscall_support.h

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

From bugzilla-daemon at llvm.org  Thu Nov 20 04:56:56 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 20 Nov 2014 12:56:56 +0000
Subject: [LLVMbugs] [Bug 21614] New: strcmp() (that does "x"[3]) generates
 an unused-value warning on 32bit
Message-ID: <bug-21614-206@http.llvm.org/bugs/>

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

            Bug ID: 21614
           Summary: strcmp() (that does "x"[3]) generates an unused-value
                    warning on 32bit
           Product: clang
           Version: unspecified
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: lkundrak at v3.sk
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

On Fedora 21 with glibc 2.20 the following happens:

[lkundrak at belphegor libnm-core]$ cat tc1.c 
#include <string.h>

void
f ()
{
    strcmp ("something", "0");
}

[lkundrak at belphegor libnm-core]$ clang -O2 -Wno-unused-value -c tc1.c
tc1.c:6:1986: warning: array index 2 is past the end of the array (which
contains 2 elements) [-Warray-bounds]
 __extension__ ({ size_t __s1_len, __s2_len; (__builtin_constant_p
("something") && __builtin_constant_p ("0") && (__s1_len = strlen
("something"), __s2_len = strlen ("0"), (!((size_t)(const void *)(("something")
+ 1) - (size_t)(const void *)("something") == 1) || __s1_len >= 4) &&
(!((size_t)(const void *)(("0") + 1) - (size_t)(const void *)("0") == 1) ||
__s2_len >= 4)) ? __builtin_strcmp ("something", "0") : (__builtin_constant_p
("something") && ((size_t)(const void *)(("something") + 1) - (size_t)(const
void *)("something") == 1) && (__s1_len = strlen ("something"), __s1_len < 4) ?
(__builtin_constant_p ("0") && ((size_t)(const void *)(("0") + 1) -
(size_t)(const void *)("0") == 1) ? __builtin_strcmp ("something", "0") :
(__extension__ ({ const unsigned char *__s2 = (const unsigned char *) (const
char *) ("0"); int __result = (((const unsigned char *) (const char *)
("something"))[0] - __s2[0]); if (__s1_len > 0 && __result == 0) { __result =
(((const unsigned char *) (const char *) ("something"))[1] - __s2[1]); if
(__s1_len > 1 && __result == 0) { __result = (((const unsigned char *) (const
char *) ("something"))[2] - __s2[2]); if (__s1_len > 2 && __result == 0)
__result = (((const unsigned char *) (const char *) ("something"))[3] -
__s2[3]); } } __result; }))) : (__builtin_constant_p ("0") && ((size_t)(const
void *)(("0") + 1) - (size_t)(const void *)("0") == 1) && (__s2_len = strlen
("0"), __s2_len < 4) ? (__builtin_constant_p ("something") && ((size_t)(const
void *)(("something") + 1) - (size_t)(const void *)("something") == 1) ?
__builtin_strcmp ("something", "0") : (- (__extension__ ({ const unsigned char
*__s2 = (const unsigned char *) (const char *) ("something"); int __result =
(((const unsigned char *) (const char *) ("0"))[0] - __s2[0]); if (__s2_len > 0
&& __result == 0) { __result = (((const unsigned char *) (const char *)
("0"))[1] - __s2[1]); if (__s2_len > 1 && __result == 0) { __result = (((const
unsigned char *) (const char *) ("0"))[2] - __s2[2]); if (__s2_len > 2 &&
__result == 0) __result = (((const unsigned char *) (const char *) ("0"))[3] -
__s2[3]); } } __result; })))) : __builtin_strcmp ("something", "0")))); });
                                                                               
                                                                               
                                                                               
                                                                               
                                                                               
                                                                               
                                                                               
                                                                               
                                                                               
                                                                               
                                                                               
                                                                               
                                                                               
                                                                               
                                                                               
                                                                               
                                                                               
                                                                               
                                                                               
                                                                               
                                                                               
                                                                               
                                                                               
                                                                               
                                                                 ^     ~
tc1.c:6:2095: warning: array index 3 is past the end of the array (which
contains 2 elements) [-Warray-bounds]
 __extension__ ({ size_t __s1_len, __s2_len; (__builtin_constant_p
("something") && __builtin_constant_p ("0") && (__s1_len = strlen
("something"), __s2_len = strlen ("0"), (!((size_t)(const void *)(("something")
+ 1) - (size_t)(const void *)("something") == 1) || __s1_len >= 4) &&
(!((size_t)(const void *)(("0") + 1) - (size_t)(const void *)("0") == 1) ||
__s2_len >= 4)) ? __builtin_strcmp ("something", "0") : (__builtin_constant_p
("something") && ((size_t)(const void *)(("something") + 1) - (size_t)(const
void *)("something") == 1) && (__s1_len = strlen ("something"), __s1_len < 4) ?
(__builtin_constant_p ("0") && ((size_t)(const void *)(("0") + 1) -
(size_t)(const void *)("0") == 1) ? __builtin_strcmp ("something", "0") :
(__extension__ ({ const unsigned char *__s2 = (const unsigned char *) (const
char *) ("0"); int __result = (((const unsigned char *) (const char *)
("something"))[0] - __s2[0]); if (__s1_len > 0 && __result == 0) { __result =
(((const unsigned char *) (const char *) ("something"))[1] - __s2[1]); if
(__s1_len > 1 && __result == 0) { __result = (((const unsigned char *) (const
char *) ("something"))[2] - __s2[2]); if (__s1_len > 2 && __result == 0)
__result = (((const unsigned char *) (const char *) ("something"))[3] -
__s2[3]); } } __result; }))) : (__builtin_constant_p ("0") && ((size_t)(const
void *)(("0") + 1) - (size_t)(const void *)("0") == 1) && (__s2_len = strlen
("0"), __s2_len < 4) ? (__builtin_constant_p ("something") && ((size_t)(const
void *)(("something") + 1) - (size_t)(const void *)("something") == 1) ?
__builtin_strcmp ("something", "0") : (- (__extension__ ({ const unsigned char
*__s2 = (const unsigned char *) (const char *) ("something"); int __result =
(((const unsigned char *) (const char *) ("0"))[0] - __s2[0]); if (__s2_len > 0
&& __result == 0) { __result = (((const unsigned char *) (const char *)
("0"))[1] - __s2[1]); if (__s2_len > 1 && __result == 0) { __result = (((const
unsigned char *) (const char *) ("0"))[2] - __s2[2]); if (__s2_len > 2 &&
__result == 0) __result = (((const unsigned char *) (const char *) ("0"))[3] -
__s2[3]); } } __result; })))) : __builtin_strcmp ("something", "0")))); });
                                                                               
                                                                               
                                                                               
                                                                               
                                                                               
                                                                               
                                                                               
                                                                               
                                                                               
                                                                               
                                                                               
                                                                               
                                                                               
                                                                               
                                                                               
                                                                               
                                                                               
                                                                               
                                                                               
                                                                               
                                                                               
                                                                               
                                                                               
                                                                               
                                                                               
                                                                               
              ^     ~
2 warnings 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/20141120/5e5c1b69/attachment.html>

From bugzilla-daemon at llvm.org  Thu Nov 20 07:58:17 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 20 Nov 2014 15:58:17 +0000
Subject: [LLVMbugs] [Bug 21615] New: ld: could not parse object file *.o:
 'Invalid value'
Message-ID: <bug-21615-206@http.llvm.org/bugs/>

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

            Bug ID: 21615
           Summary: ld: could not parse object file *.o: 'Invalid value'
           Product: clang
           Version: 3.5
          Hardware: PC
                OS: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
          Assignee: unassignedclangbugs at nondot.org
          Reporter: ruslan_baratov at yahoo.com
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Error while compiling simple main.cpp with LTO optimization:

> cat main.cpp 
#include <iostream>

int main() {
  std::cout << "hello" << std::endl;
}

> clang++ -flto main.cpp
ld: could not parse object file /var/folders/*/main-*.o: 'Invalid value', using
libLTO version 'LLVM version 3.5svn' file '/var/folders/*/main-*.o' for
architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Version of clang:
    http://llvm.org/releases/3.5.0/clang+llvm-3.5.0-macosx-apple-darwin.tar.xz

OS X Yosemite Version 10.10.1:
    > uname -a
    Darwin mac-osx-x64 14.0.0 Darwin Kernel Version 14.0.0: Fri Sep 19 00:26:44
PDT 2014; root:xnu-2782.1.97~2/RELEASE_X86_64 x86_64

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

From bugzilla-daemon at llvm.org  Thu Nov 20 08:06:42 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 20 Nov 2014 16:06:42 +0000
Subject: [LLVMbugs] [Bug 21616] New: LowerSwitch pass fail weirdly
Message-ID: <bug-21616-206@http.llvm.org/bugs/>

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

            Bug ID: 21616
           Summary: LowerSwitch pass fail weirdly
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Transformation Utilities
          Assignee: unassignedbugs at nondot.org
          Reporter: julien.rinaldini at heig-vd.ch
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

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

The LowerSwitch pass failed in some cases.

After some investigation, I found that the pass fails because of the "case
'9':". If I remove this case, everything works fine.

I'm not sure, but I think it comes from the clustering part of the pass. the
caracter '9' and the caracter ':' follow each other in the ascii table, so it
try to cluster it together (but they don't have the same BB successor).

ps: my LLVM version is the 3.5 release (but didn't appear in the 'version'
field).

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

From bugzilla-daemon at llvm.org  Thu Nov 20 08:09:39 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 20 Nov 2014 16:09:39 +0000
Subject: [LLVMbugs] [Bug 21617] New: wrong optimization of C++11 code on ARM
 and other targets
Message-ID: <bug-21617-206@http.llvm.org/bugs/>

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

            Bug ID: 21617
           Summary: wrong optimization of C++11 code on ARM and other
                    targets
           Product: tools
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: llc
          Assignee: unassignedbugs at nondot.org
          Reporter: sohachak at mpi-sws.org
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 13379
  --> http://llvm.org/bugs/attachment.cgi?id=13379&action=edit
cpp, IR, s files

Hi,

The following C++11 source code is compiled by LLVM for ARM architecture.

Source
----------
 int read() {
 int r0,r1,r2;
 r0 = x.load(memory_order_relaxed);
 r1 = y.load(memory_order_acquire);
 r2 = x.load(memory_order_relaxed);
return (r0+r1+r2);
}

Compilation command 
---------------------
clang++ -std=c++11 -emit-llvm -pthread <filename>.cpp -S;opt -O3 <filename>.ll
-S  > <filename>.opt.bc;llc -march=arm -O3 <filename>.opt.bc

Target
-------- 
@ BB#0:                                 @ %entry
        push    {r4, r5, r6, r11, lr}
        add     r11, sp, #12
        sub     sp, sp, #4
        ldr     r4, .LCPI0_0
        mov     r6, #0
        mov     r1, #0
        mov     r2, #0
        mov     r3, #0
        str     r6, [sp]
        mov     r0, r4
        bl      __sync_val_compare_and_swap_8
        mov     r5, r0
        ldr     r0, .LCPI0_1
        mov     r1, #0
        mov     r2, #0
        mov     r3, #0
        str     r6, [sp]
        bl      __sync_val_compare_and_swap_8
        add     r5, r0, r5
        mov     r0, r4
        mov     r1, #0
        mov     r2, #0
        mov     r3, #0
        str     r6, [sp]
        bl      __sync_val_compare_and_swap_8
        add     r0, r5, r0
        sub     sp, r11, #12
        pop     {r4, r5, r6, r11, lr}
        mov     pc, lr
        .align  2
@ BB#1:
.LCPI0_0:
        .long   x
.LCPI0_1:
        .long   y
.Ltmp0:
        .size   _Z4readv, .Ltmp0-_Z4readv
.Leh_func_end0:
        .fnend



The second load operation of x is removed in the compilation. 

This is a wrong compilation when following thread is running in parallel

void write() {
  x.store(500, memory_order_relaxed);
  y.store(10, memory_order_release);
}

In this source program following the C++11 semantics in read() function 
if r1 = 10 then r2 = 500 and thus read() should never return 10.
However, in the target program read() may return 10 when 
r1 = 0 /\ r1 = 10 /\ r2 = 0. This is a new behavior 
in the taget program which never happens in the source program. 

Note: 
1. Repeated relaxed load operation should not be removed if there is 
any acquire operation between them. 

2. The load removal is observed in llc IR dump after "Expand ISel
Pseudo-instructions".

3. Such load removal optimization is observed while 
generating code for following targets
arm, armeb, mips, mips64, mips64el, msp430, 
nvptx, nvptx64, ppc32, sparc, thumb, thumbeb, xcore.

Attached are the cpp, .s and LLVM IR files as a testcase.

Thanks & Regards,
soham

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

From bugzilla-daemon at llvm.org  Thu Nov 20 08:21:18 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 20 Nov 2014 16:21:18 +0000
Subject: [LLVMbugs] [Bug 15542] clang crash when implementing Andrei's
	expected<T>
In-Reply-To: <bug-15542-206@http.llvm.org/bugs/>
References: <bug-15542-206@http.llvm.org/bugs/>
Message-ID: <bug-15542-206-KfKay07yPw@http.llvm.org/bugs/>

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

Tomasz Miąsko <tomasz.miasko at gmail.com> changed:

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

--- Comment #6 from Tomasz Miąsko <tomasz.miasko at gmail.com> ---
Fixed in r222402.

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

From bugzilla-daemon at llvm.org  Thu Nov 20 08:21:30 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 20 Nov 2014 16:21:30 +0000
Subject: [LLVMbugs] [Bug 21618] New: libclang_rt.asan_osx_dynamic.dylib
	incorrect RPATH
Message-ID: <bug-21618-206@http.llvm.org/bugs/>

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

            Bug ID: 21618
           Summary: libclang_rt.asan_osx_dynamic.dylib incorrect RPATH
           Product: clang
           Version: 3.5
          Hardware: PC
                OS: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
          Assignee: unassignedclangbugs at nondot.org
          Reporter: ruslan_baratov at yahoo.com
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified

*asan*.dylib has an incorrect rpath:

> otool -L lib/clang/3.5.0/lib/darwin/libclang_rt.asan_osx_dynamic.dylib
   
/private/tmp/llvm-release/final/Phase3/Release/llvmCore-3.5.0-final.obj/Release/lib/clang/3.5.0/lib/darwin/libclang_rt.asan_osx_dynamic.dylib
(compatibility version 0.0.0, current version 0.0.0)
    /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version
120.0.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version
1197.1.1)

It's probably some temporary build location which not exists.

This lead to error:
> cat main.cpp
#include <iostream>
int main() {
  std::cout << "hello" << std::endl;
}
> clang++ -fsanitize=address main.cpp -o foo && ./foo
dyld: Library not loaded:
/private/tmp/llvm-release/final/Phase3/Release/llvmCore-3.5.0-final.obj/Release/lib/clang/3.5.0/lib/darwin/libclang_rt.asan_osx_dynamic.dylib
  Referenced from: /.../foo
  Reason: image not found
Trace/BPT trap: 5

Simple workaround:
> install_name_tool /path/to/real/*.dylib -id /path/to/real/*.dylib

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

From bugzilla-daemon at llvm.org  Thu Nov 20 08:38:58 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 20 Nov 2014 16:38:58 +0000
Subject: [LLVMbugs] [Bug 21577] 'Malformed block',
 using libLTO version 'LLVM version 3.5svn'
In-Reply-To: <bug-21577-206@http.llvm.org/bugs/>
References: <bug-21577-206@http.llvm.org/bugs/>
Message-ID: <bug-21577-206-U1eyNWmeAW@http.llvm.org/bugs/>

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

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

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

--- Comment #3 from Rafael Ávila de Espíndola <rafael.espindola at gmail.com> ---
(In reply to comment #2)
> As long as clang overwrites created object files there should not be any
> problems.
> 
> Disk corruption is of course possible, but it could be race condition in
> linker code as well.
> 
> Mac OS X 10.10
> Apple LLVM version 6.0 (clang-600.0.54) (based on LLVM 3.5svn)

Without a testcase with upstream llvm/clang you will have to report this to
Apple.

If you notice this happening with the open source version, please save the
corrupted file.

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

From bugzilla-daemon at llvm.org  Thu Nov 20 08:57:47 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 20 Nov 2014 16:57:47 +0000
Subject: [LLVMbugs] [Bug 21616] LowerSwitch pass fail weirdly
In-Reply-To: <bug-21616-206@http.llvm.org/bugs/>
References: <bug-21616-206@http.llvm.org/bugs/>
Message-ID: <bug-21616-206-a46SWt5bQh@http.llvm.org/bugs/>

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

pyknite <julien.rinaldini at heig-vd.ch> 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/20141120/0300f2ab/attachment.html>

From bugzilla-daemon at llvm.org  Thu Nov 20 09:44:43 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 20 Nov 2014 17:44:43 +0000
Subject: [LLVMbugs] [Bug 21618] libclang_rt.asan_osx_dynamic.dylib incorrect
	RPATH
In-Reply-To: <bug-21618-206@http.llvm.org/bugs/>
References: <bug-21618-206@http.llvm.org/bugs/>
Message-ID: <bug-21618-206-B0hVXKwpcN@http.llvm.org/bugs/>

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

jonathan.sauer at gmx.de changed:

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

--- Comment #1 from jonathan.sauer at gmx.de ---


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

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

From bugzilla-daemon at llvm.org  Thu Nov 20 11:42:00 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 20 Nov 2014 19:42:00 +0000
Subject: [LLVMbugs] [Bug 21565] r221918 breaks bootstrap on Fedora 20/x86-64
In-Reply-To: <bug-21565-206@http.llvm.org/bugs/>
References: <bug-21565-206@http.llvm.org/bugs/>
Message-ID: <bug-21565-206-9aMmuS2ixW@http.llvm.org/bugs/>

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

Reid Kleckner <rnk at google.com> changed:

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

--- Comment #5 from Reid Kleckner <rnk at google.com> ---
Richard, your egregious hack also fires on *exactly the same case* in MSVC's
Dinkumware STL, which expects the lazy behavior, not the eager behavior.

Worse than that, it's hard for me to make a preprocessed source file that
retains the system header-ness due to http://llvm.org/PR20553.

Do we have any better indicators for which STL we're using? Worst case we can
disable this hack when Triple::isWindowsMSVCEnvironment(), but I know that Sony
for example uses Dinkumware on non-Windows OSs.

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

From bugzilla-daemon at llvm.org  Thu Nov 20 14:33:44 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 20 Nov 2014 22:33:44 +0000
Subject: [LLVMbugs] [Bug 21565] r221918 breaks bootstrap on Fedora 20/x86-64
In-Reply-To: <bug-21565-206@http.llvm.org/bugs/>
References: <bug-21565-206@http.llvm.org/bugs/>
Message-ID: <bug-21565-206-QQOsK5ht9d@http.llvm.org/bugs/>

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

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

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

--- Comment #6 from Richard Smith <richard-llvm at metafoo.co.uk> ---
I've made the conditions that enable this workaround even more specific in
r222471. In addition to checking that the exception specification is for a
'std::X::swap' member function (where X is array, pair, priority_queue, stack,
or queue), we also check that it starts with 'noexcept(noexcept(swap'.

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

From bugzilla-daemon at llvm.org  Thu Nov 20 14:58:58 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 20 Nov 2014 22:58:58 +0000
Subject: [LLVMbugs] [Bug 21621] New: Race condition in ASAN with detached
	threads.
Message-ID: <bug-21621-206@http.llvm.org/bugs/>

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

            Bug ID: 21621
           Summary: Race condition in ASAN with detached threads.
           Product: compiler-rt
           Version: unspecified
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: compiler-rt
          Assignee: unassignedbugs at nondot.org
          Reporter: eric at efcs.ca
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

There seems to be a race condition between when ASAN checks for leaks and when
detached threads exit and free their resources. For example the below test
detects a leak with both libc++ and libstdc++. However when the main thread
waits for the spawned thread to exit no leak is detected.

// clang++ -std=c++11 -fsanitize=address -lpthread test.cpp
#include <thread>
#include <chrono>

void func()
{
    std::this_thread::sleep_for(std::chrono::milliseconds(500));
}

int main() {
    std::thread(func).detach();
    // Enable to see ASAN pass.
    //std::this_thread::sleep_for(std::chrono::milliseconds(600));
}

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

From bugzilla-daemon at llvm.org  Thu Nov 20 16:30:23 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 21 Nov 2014 00:30:23 +0000
Subject: [LLVMbugs] [Bug 21565] r221918 breaks bootstrap on Fedora 20/x86-64
In-Reply-To: <bug-21565-206@http.llvm.org/bugs/>
References: <bug-21565-206@http.llvm.org/bugs/>
Message-ID: <bug-21565-206-iNTV3jFmbj@http.llvm.org/bugs/>

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

Paul Robinson <paul_robinson at playstation.sony.com> changed:

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

--- Comment #7 from Paul Robinson <paul_robinson at playstation.sony.com> ---
Thanks for pointing this out, Reid!  Yes, we trip over it, in <tuple>,
I just hadn't noticed it yet.

My most recent Clang update is based on r222093, and it gets caught by this.
I patched it with r222471, which didn't help; once you get done with macro
expansion we have the token sequence
  noexcept(noexcept(swap(declval<sometype&>(), declval<sometype&>())) && ....
in the exception-specification for tuple::swap(tuple&).  At least I think
it's tuple::swap(), sometimes this template stuff is hard for me to parse.

Anyway, it's still a problem for us.

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

From bugzilla-daemon at llvm.org  Thu Nov 20 17:27:26 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 21 Nov 2014 01:27:26 +0000
Subject: [LLVMbugs] [Bug 21565] r221918 breaks bootstrap on Fedora 20/x86-64
In-Reply-To: <bug-21565-206@http.llvm.org/bugs/>
References: <bug-21565-206@http.llvm.org/bugs/>
Message-ID: <bug-21565-206-6HMCMFURHP@http.llvm.org/bugs/>

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

Paul Robinson <paul_robinson at playstation.sony.com> changed:

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

--- Comment #12 from Paul Robinson <paul_robinson at playstation.sony.com> ---
(In reply to comment #11)
> I could also trivially add 'tuple' to the list of types for which we deploy
> the workaround, if you would prefer.

I tried adding 'tuple' to the list in isLibstdcxxEagerExceptionSpecHack
but that didn't do the trick.  We need to fix our header anyway (as I look
at other headers, I see that mostly they do the kind of thing you suggest).
We don't release compilers and libraries independently so it won't be a
real problem.

Marking as resolved.

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

From bugzilla-daemon at llvm.org  Thu Nov 20 18:38:02 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 21 Nov 2014 02:38:02 +0000
Subject: [LLVMbugs] [Bug 21480] SROA asserts with "Cannot have vector types
 of different sizes!"
In-Reply-To: <bug-21480-206@http.llvm.org/bugs/>
References: <bug-21480-206@http.llvm.org/bugs/>
Message-ID: <bug-21480-206-TLvPZJqnB5@http.llvm.org/bugs/>

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

David Majnemer <david.majnemer at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED
           Assignee|unassignedbugs at nondot.org   |david.majnemer at gmail.com

--- Comment #3 from David Majnemer <david.majnemer at gmail.com> ---
Fixed in r222499.

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

From bugzilla-daemon at llvm.org  Thu Nov 20 18:45:41 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 21 Nov 2014 02:45:41 +0000
Subject: [LLVMbugs] [Bug 21622] New: [SCEV] New Trip Count Computation cause
 Overflow assertion in MachineBlockFrequency
Message-ID: <bug-21622-206@http.llvm.org/bugs/>

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

            Bug ID: 21622
           Summary: [SCEV] New Trip Count Computation cause Overflow
                    assertion in MachineBlockFrequency
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Global Analyses
          Assignee: unassignedbugs at nondot.org
          Reporter: zhaoshiz at codeaurora.org
                CC: apazos at codeaurora.org, chandlerc at gmail.com,
                    llvmbugs at cs.uiuc.edu, mcrosier at codeaurora.org
    Classification: Unclassified

Created attachment 13380
  --> http://llvm.org/bugs/attachment.cgi?id=13380&action=edit
C Test case

> clang --target=aarch64-linux-gnu  -mcpu=cortex-a57 -Ofast test.c -mllvm -unroll-allow-partial -mllvm -unroll-threshold=1000 -c -o test.o
> clang-3.6: /prj/llvm-arm/home/nightly/src/community-mainline/llvm/lib/Analysis/BlockFrequencyInfoImpl.cpp:125: void combineWeight({anonymous}::Weight&, const Weight&): Assertion `W.Amount < W.Amount + OtherW.Amount && "Unexpected overflow"' failed.

The commit below changes how SCEV computes loop trip count:

> -    dyn_cast<SCEVConstant>(getBackedgeTakenCount(L));
> +      dyn_cast<SCEVConstant>(getExitCount(L, ExitingBlock));

This results in a loop previously considered runtime (trip count is 0) becomes
a compile time loop (trip count is 255).

With '-unroll-allow-partial' and '-unroll-threshold=1000', loop unroll pass
chooses to unroll this loop by a factor of 85.

As a result, a substantial number of branches are targeting the same landing
block, eventually overflow BlockFrequency calculation.


commit ed05e3703e07dfeae33acdd3cc5ad07b5f5b86c6
Author: Mark Heffernan <meheff at google.com>
Date:   Fri Oct 10 10:39:11 2014

    This patch de-pessimizes the calculation of loop trip counts in
    ScalarEvolution in the presence of multiple exits. Previously all
    loops exits had to have identical counts for a loop trip count to be
    considered computable. This pessimization was implemented by calling
    getBackedgeTakenCount(L) rather than getExitCount(L, ExitingBlock)
    inside of ScalarEvolution::getSmallConstantTripCount() (see the FIXME
    in the comments of that function). The pessimization was added to fix
    a corner case involving undefined behavior (pr/16130). This patch more
    precisely handles the undefined behavior case allowing the pessimization
    to be removed.

    ControlsExit replaces IsSubExpr to more precisely track the case where
    undefined behavior is expected to occur. Because undefined behavior is
    tracked more precisely we can remove MustExit from ExitLimit. MustExit
    was used to track the case where the limit was computed potentially
    assuming undefined behavior even if undefined behavior didn't necessarily
    occur.


    git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk at 219517
91177308-0d34-0410-b5e6-96231b3b80d8

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

From bugzilla-daemon at llvm.org  Thu Nov 20 21:19:16 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 21 Nov 2014 05:19:16 +0000
Subject: [LLVMbugs] [Bug 21323] FindExternalVisibleDeclsByName iterator
 invalidation when using modules
In-Reply-To: <bug-21323-206@http.llvm.org/bugs/>
References: <bug-21323-206@http.llvm.org/bugs/>
Message-ID: <bug-21323-206-n2tOie6iqu@http.llvm.org/bugs/>

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

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> ---
Should be fixed in r222506; please let me know if you still have problems here.
Also, if you happen to have a reduced testcase, that'd be very useful.

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

From bugzilla-daemon at llvm.org  Thu Nov 20 22:05:18 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 21 Nov 2014 06:05:18 +0000
Subject: [LLVMbugs] [Bug 21623] New: Instcombine folds constant
 @llvm.fma.f80 to wrong value
Message-ID: <bug-21623-206@http.llvm.org/bugs/>

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

            Bug ID: 21623
           Summary: Instcombine folds constant @llvm.fma.f80 to wrong
                    value
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Transformation Utilities
          Assignee: unassignedbugs at nondot.org
          Reporter: mail+llvm at tzik.jp
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

InstCombine folds constant @llvm.fma.f80 to wrong value.
This can reproduce as follows, where llvm.fma.f80 is folded to
0xK40008000000000000000, which is 2.0L.

$ cat foo.ll
declare x86_fp80 @llvm.fma.f80(x86_fp80, x86_fp80, x86_fp80)

define x86_fp80 @test() {
  %1 = call x86_fp80 @llvm.fma.f80(
      x86_fp80 0xK40008000000000000000, ; 2.0L
      x86_fp80 0xK4000C000000000000000, ; 3.0L
      x86_fp80 0xK40018000000000000000) ; 4.0L

  ret x86_fp80 %1 ; should be 10.0L
}

$ opt -instcombine -S -o - foo.ll
; ModuleID = 'hoge.ll'

; Function Attrs: nounwind readnone
declare x86_fp80 @llvm.fma.f80(x86_fp80, x86_fp80, x86_fp80) #0

define x86_fp80 @test() {
  ret x86_fp80 0xK40008000000000000000
}

attributes #0 = { nounwind readnone }

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

From bugzilla-daemon at llvm.org  Thu Nov 20 22:25:13 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 21 Nov 2014 06:25:13 +0000
Subject: [LLVMbugs] [Bug 21623] Instcombine folds constant @llvm.fma.f80 to
	wrong value
In-Reply-To: <bug-21623-206@http.llvm.org/bugs/>
References: <bug-21623-206@http.llvm.org/bugs/>
Message-ID: <bug-21623-206-g0Ag3JTPdn@http.llvm.org/bugs/>

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

Taiju Tsuiki <mail+llvm at tzik.jp> changed:

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

--- Comment #1 from Taiju Tsuiki <mail+llvm at tzik.jp> ---


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

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

From bugzilla-daemon at llvm.org  Thu Nov 20 22:54:35 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 21 Nov 2014 06:54:35 +0000
Subject: [LLVMbugs] [Bug 21624] New: -fmodules causes failure of inclusion
 of STL headers
Message-ID: <bug-21624-206@http.llvm.org/bugs/>

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

            Bug ID: 21624
           Summary: -fmodules causes failure of inclusion of STL headers
           Product: clang
           Version: trunk
          Hardware: PC
                OS: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
          Assignee: unassignedclangbugs at nondot.org
          Reporter: 191919 at gmail.com
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified

clang version 3.6.0 (trunk 222503) failed to compile trivial code that includes
STL header when using -fmodule:

The code:

```
#include <vector>

int main() {}
```

Compile it with:


```
$ /opt/bin/clang++ -fmodules -c -o m mm.cpp    
```

clang gave the following error messages:

```
While building module 'std' imported from mm.cpp:1:
In file included from <module-includes>:4:
In file included from /usr/include/c++/v1/ccomplex:21:
In file included from /usr/include/c++/v1/complex:247:
In file included from /usr/include/c++/v1/sstream:174:
In file included from /usr/include/c++/v1/ostream:140:
/usr/include/c++/v1/locale:873:26: error: use of undeclared identifier
'strtoll_l'; did you mean 'wcstoll_l'?
        long long __ll = strtoll_l(__a, &__p2, __base, _LIBCPP_GET_C_LOCALE);
                         ^
/usr/include/xlocale/_wchar.h:98:2: note: 'wcstoll_l' declared here
        wcstoll_l(const wchar_t * __restrict, wchar_t ** __restrict, int,
        ^
While building module 'std' imported from mm.cpp:1:
In file included from <module-includes>:4:
In file included from /usr/include/c++/v1/ccomplex:21:
In file included from /usr/include/c++/v1/complex:247:
In file included from /usr/include/c++/v1/sstream:174:
In file included from /usr/include/c++/v1/ostream:140:
/usr/include/c++/v1/locale:873:36: error: cannot initialize a parameter of type
'const wchar_t *' with an lvalue of type 'const char *'
        long long __ll = strtoll_l(__a, &__p2, __base, _LIBCPP_GET_C_LOCALE);
                                   ^~~
/usr/include/xlocale/_wchar.h:98:38: note: passing argument to parameter here
        wcstoll_l(const wchar_t * __restrict, wchar_t ** __restrict, int,
                                            ^
While building module 'std' imported from mm.cpp:1:
In file included from <module-includes>:4:
In file included from /usr/include/c++/v1/ccomplex:21:
In file included from /usr/include/c++/v1/complex:247:
In file included from /usr/include/c++/v1/sstream:174:
In file included from /usr/include/c++/v1/ostream:140:
/usr/include/c++/v1/locale:913:35: error: use of undeclared identifier
'strtoull_l'; did you mean 'wcstoull_l'?
        unsigned long long __ll = strtoull_l(__a, &__p2, __base,
_LIBCPP_GET_C_LOCALE);
                                  ^
/usr/include/xlocale/_wchar.h:101:2: note: 'wcstoull_l' declared here
        wcstoull_l(const wchar_t * __restrict, wchar_t ** __restrict, int,
        ^
While building module 'std' imported from mm.cpp:1:
In file included from <module-includes>:4:
In file included from /usr/include/c++/v1/ccomplex:21:
In file included from /usr/include/c++/v1/complex:247:
In file included from /usr/include/c++/v1/sstream:174:
In file included from /usr/include/c++/v1/ostream:140:
/usr/include/c++/v1/locale:913:46: error: cannot initialize a parameter of type
'const wchar_t *' with an lvalue of type 'const char *'
        unsigned long long __ll = strtoull_l(__a, &__p2, __base,
_LIBCPP_GET_C_LOCALE);
                                             ^~~
/usr/include/xlocale/_wchar.h:101:39: note: passing argument to parameter here
        wcstoull_l(const wchar_t * __restrict, wchar_t ** __restrict, int,
                                             ^
While building module 'std' imported from mm.cpp:1:
In file included from <module-includes>:4:
In file included from /usr/include/c++/v1/ccomplex:21:
In file included from /usr/include/c++/v1/complex:247:
In file included from /usr/include/c++/v1/sstream:174:
In file included from /usr/include/c++/v1/ostream:140:
/usr/include/c++/v1/locale:943:28: error: use of undeclared identifier
'strtold_l'
        long double __ld = strtold_l(__a, &__p2, _LIBCPP_GET_C_LOCALE);
                           ^
mm.cpp:1:10: fatal error: could not build module 'std'
#include <vector>
 ~~~~~~~~^
6 errors generated.
```

Xcode's stock clang (Apple LLVM version 6.0 (clang-600.0.54) (based on LLVM
3.5svn)) is ok with `-fmodules`.

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

From bugzilla-daemon at llvm.org  Thu Nov 20 23:53:06 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 21 Nov 2014 07:53:06 +0000
Subject: [LLVMbugs] [Bug 21625] New: LTO linking error on x86_64-linux-gnu
Message-ID: <bug-21625-206@http.llvm.org/bugs/>

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

            Bug ID: 21625
           Summary: LTO linking error on x86_64-linux-gnu
           Product: clang
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: su at cs.ucdavis.edu
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

The following code causes a linker error when it is compiled on
x86_64-linux-gnu by the current clang trunk using LTO in 64-bit mode, but not
in 32-bit mode. 

This also affects 3.2, 3.3, 3.4.x, and 3.5.0. 

$ clang-trunk -v
clang version 3.6.0 (trunk 220839)
Target: x86_64-unknown-linux-gnu
Thread model: posix
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.8
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.8.1
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.4
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.4.6
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.4.7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6.4
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7.3
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8.1
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Selected multilib: .;@m64
$ 
$ clang-trunk -O0 fn1.c main.c
$ a.out
$ 
$ clang-trunk -flto -O0 fn1.c main.c
ld: /tmp/llvm/lib/Analysis/MemoryDependenceAnalysis.cpp:1365: bool
llvm::MemoryDependenceAnalysis::getNonLocalPointerDepFromBB(const
llvm::PHITransAddr &, const AliasAnalysis::Location &, bool, llvm::BasicBlock
*, SmallVectorImpl<llvm::NonLocalDepResult> &, DenseMap<llvm::BasicBlock *,
llvm::Value *> &, bool): Assertion `I->getResult().isNonLocal() && "Should only
be here with transparent block"' failed.
clang: error: unable to execute command: Aborted (core dumped)
clang: error: linker command failed due to signal (use -v to see invocation)
$ 
$ cat fn1.c
struct
{
  int f0;
} c;

int a, b, d;

int
fn1 ()
{
  int e, h = 0, *f = &a, **g = &f; 
  for (c.f0 = 0; c.f0;)
    {
      int ***i = &g;
      for (; d < 1; d++)
    for (; c.f0; c.f0--)
      for (; h;)
        f = **i;
      b++;
      int *j = 0, **k = &j;
      for (e = 0; e;)
    {
      int ***l = &k;
      for (;;)
        **l = 0;
    }
      return **k;
    }
  return **g;
}
$ cat main.c
extern int fn1 ();

int
main ()
{
  fn1 ();
  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/20141121/307784ee/attachment.html>

From bugzilla-daemon at llvm.org  Fri Nov 21 00:42:37 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 21 Nov 2014 08:42:37 +0000
Subject: [LLVMbugs] [Bug 21626] New: clang failed to compile Objective-C++
 code with -fmodules
Message-ID: <bug-21626-206@http.llvm.org/bugs/>

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

            Bug ID: 21626
           Summary: clang failed to compile Objective-C++ code with
                    -fmodules
           Product: clang
           Version: trunk
          Hardware: PC
                OS: MacOS X
            Status: NEW
          Severity: release blocker
          Priority: P
         Component: Modules
          Assignee: unassignedclangbugs at nondot.org
          Reporter: 191919 at gmail.com
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified

clang svn (clang version 3.6.0 (trunk 222512)) failed to compile the following
trivial code when compiling it as Objective-C++ code:

```
#import <Cocoa/Cocoa.h>

int main() {
}
```

The command line to compile it was:

$ /opt/bin/clang++ -fmodules -c -o m m.mm

It gave a huge bunch of error messages:

```
While building module 'Cocoa' imported from m.mm:1:
While building module 'Foundation' imported from
/System/Library/Frameworks/Cocoa.framework/Headers/Cocoa.h:12:
While building module 'CoreFoundation' imported from
/System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:6:
While building module 'Dispatch' imported from
/System/Library/Frameworks/CoreFoundation.framework/Headers/CFStream.h:15:
In file included from <module-includes>:1:
In file included from /usr/include/dispatch/dispatch.h:52:
/usr/include/dispatch/queue.h:368:1: error: import of C++ module
'Darwin.sys.qos' appears within extern "C" language linkage specification
#include <sys/qos.h>
^
/usr/include/dispatch/queue.h:69:1: note: extern "C" language linkage
specification begins here
__BEGIN_DECLS
^
/usr/include/sys/cdefs.h:71:23: note: expanded from macro '__BEGIN_DECLS'
#define __BEGIN_DECLS   extern "C" {
                        ^
While building module 'Cocoa' imported from m.mm:1:
While building module 'Foundation' imported from
/System/Library/Frameworks/Cocoa.framework/Headers/Cocoa.h:12:
While building module 'CoreFoundation' imported from
/System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:6:
In file included from <module-includes>:1:
In file included from
/System/Library/Frameworks/CoreFoundation.framework/Headers/CoreFoundation.h:55:
In file included from
/System/Library/Frameworks/CoreFoundation.framework/Headers/CFPropertyList.h:13:
/System/Library/Frameworks/CoreFoundation.framework/Headers/CFStream.h:15:10:
fatal error: could not build module 'Dispatch'
#include <dispatch/dispatch.h>
 ~~~~~~~~^
While building module 'Cocoa' imported from m.mm:1:
While building module 'Foundation' imported from
/System/Library/Frameworks/Cocoa.framework/Headers/Cocoa.h:12:
In file included from <module-includes>:1:
/System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:6:10:
fatal error: could not build module 'CoreFoundation'
#include <CoreFoundation/CoreFoundation.h>
 ~~~~~~~~^
While building module 'Cocoa' imported from m.mm:1:
While building module 'Foundation' imported from
/System/Library/Frameworks/Cocoa.framework/Headers/Cocoa.h:12:
While building module 'CoreGraphics' imported from
/System/Library/Frameworks/Foundation.framework/Headers/NSGeometry.h:12:
In file included from <module-includes>:1:
In file included from
/System/Library/Frameworks/CoreGraphics.framework/Headers/CoreGraphics.h:10:
In file included from
/System/Library/Frameworks/CoreGraphics.framework/Headers/CGAffineTransform.h:11:
/System/Library/Frameworks/CoreGraphics.framework/Headers/CGGeometry.h:9:10:
fatal error: could not build module 'CoreFoundation'
#include <CoreFoundation/CFDictionary.h>
 ~~~~~~~~^
While building module 'Cocoa' imported from m.mm:1:
While building module 'Foundation' imported from
/System/Library/Frameworks/Cocoa.framework/Headers/Cocoa.h:12:
While building module 'CoreGraphics' imported from
/System/Library/Frameworks/Foundation.framework/Headers/NSGeometry.h:12:
While building module 'IOKit' imported from
/System/Library/Frameworks/CoreGraphics.framework/Headers/CGDisplayConfiguration.h:8:
In file included from <module-includes>:2:
/System/Library/Frameworks/IOKit.framework/Headers/IODataQueueClient.h:30:1:
error: import of C++ module 'Darwin.Availability' appears within extern "C"
      language linkage specification
#include <AvailabilityMacros.h>
^
/System/Library/Frameworks/IOKit.framework/Headers/IODataQueueClient.h:29:1:
note: extern "C" language linkage specification begins here
__BEGIN_DECLS
^
/usr/include/sys/cdefs.h:71:23: note: expanded from macro '__BEGIN_DECLS'
#define __BEGIN_DECLS   extern "C" {
                        ^
While building module 'Cocoa' imported from m.mm:1:
While building module 'Foundation' imported from
/System/Library/Frameworks/Cocoa.framework/Headers/Cocoa.h:12:
While building module 'CoreGraphics' imported from
/System/Library/Frameworks/Foundation.framework/Headers/NSGeometry.h:12:
While building module 'IOKit' imported from
/System/Library/Frameworks/CoreGraphics.framework/Headers/CGDisplayConfiguration.h:8:
While building module 'libkern' imported from
/System/Library/Frameworks/IOKit.framework/Headers/IODataQueueClient.h:31:
In file included from <module-includes>:3:
/usr/include/libkern/OSReturn.h:46:1: error: import of C++ module
'Darwin.Mach.error' appears within extern "C" language linkage specification
#include <mach/error.h>
^
/usr/include/libkern/OSReturn.h:44:1: note: extern "C" language linkage
specification begins here
__BEGIN_DECLS
^
/usr/include/sys/cdefs.h:71:23: note: expanded from macro '__BEGIN_DECLS'
#define __BEGIN_DECLS   extern "C" {
                        ^
While building module 'Cocoa' imported from m.mm:1:
While building module 'Foundation' imported from
/System/Library/Frameworks/Cocoa.framework/Headers/Cocoa.h:12:
While building module 'CoreGraphics' imported from
/System/Library/Frameworks/Foundation.framework/Headers/NSGeometry.h:12:
While building module 'IOKit' imported from
/System/Library/Frameworks/CoreGraphics.framework/Headers/CGDisplayConfiguration.h:8:
In file included from <module-includes>:2:
/System/Library/Frameworks/IOKit.framework/Headers/IODataQueueClient.h:31:10:
fatal error: could not build module 'libkern'
#include <libkern/OSTypes.h>
 ~~~~~~~~^
While building module 'Cocoa' imported from m.mm:1:
While building module 'Foundation' imported from
/System/Library/Frameworks/Cocoa.framework/Headers/Cocoa.h:12:
While building module 'CoreGraphics' imported from
/System/Library/Frameworks/Foundation.framework/Headers/NSGeometry.h:12:
While building module 'IOSurface' imported from
/System/Library/Frameworks/CoreGraphics.framework/Headers/CGDisplayStream.h:9:
In file included from <module-includes>:1:
In file included from
/System/Library/Frameworks/IOSurface.framework/Headers/IOSurface.h:12:
/System/Library/Frameworks/IOSurface.framework/Headers/IOSurfaceBase.h:29:10:
fatal error: could not build module 'CoreFoundation'
#include <CoreFoundation/CFBase.h>
 ~~~~~~~~^
While building module 'Cocoa' imported from m.mm:1:
While building module 'Foundation' imported from
/System/Library/Frameworks/Cocoa.framework/Headers/Cocoa.h:12:
While building module 'CoreGraphics' imported from
/System/Library/Frameworks/Foundation.framework/Headers/NSGeometry.h:12:
While building module 'IOSurface' imported from
/System/Library/Frameworks/CoreGraphics.framework/Headers/CGDisplayStream.h:9:
While building module 'XPC' imported from
/System/Library/Frameworks/IOSurface.framework/Headers/IOSurfaceBase.h:30:
In file included from <module-includes>:1:
/usr/include/xpc/xpc.h:7:10: fatal error: could not build module 'Dispatch'
#include <dispatch/dispatch.h>
 ~~~~~~~~^
While building module 'Cocoa' imported from m.mm:1:
While building module 'Foundation' imported from
/System/Library/Frameworks/Cocoa.framework/Headers/Cocoa.h:12:
While building module 'Security' imported from
/System/Library/Frameworks/Foundation.framework/Headers/NSURLCredential.h:9:
In file included from <module-includes>:1:
In file included from
/System/Library/Frameworks/Security.framework/Headers/Security.h:44:
In file included from
/System/Library/Frameworks/Security.framework/Headers/oidsalg.h:29:
/System/Library/Frameworks/Security.framework/Headers/SecAsn1Types.h:42:10:
fatal error: could not build module 'CoreFoundation'
#include <CoreFoundation/CFBase.h>              /* Boolean */
 ~~~~~~~~^
While building module 'Cocoa' imported from m.mm:1:
While building module 'Foundation' imported from
/System/Library/Frameworks/Cocoa.framework/Headers/Cocoa.h:12:
While building module 'CoreServices' imported from
/System/Library/Frameworks/Foundation.framework/Headers/NSURLError.h:12:
In file included from <module-includes>:1:
/System/Library/Frameworks/CoreServices.framework/Headers/CoreServices.h:19:10:
fatal error: could not build module 'CoreFoundation'
#include <CoreFoundation/CoreFoundation.h>
 ~~~~~~~~^
While building module 'Cocoa' imported from m.mm:1:
While building module 'Foundation' imported from
/System/Library/Frameworks/Cocoa.framework/Headers/Cocoa.h:12:
While building module 'CoreServices' imported from
/System/Library/Frameworks/Foundation.framework/Headers/NSURLError.h:12:
While building module 'DiskArbitration' imported from
/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/Files.h:56:
In file included from <module-includes>:1:
/System/Library/Frameworks/DiskArbitration.framework/Headers/DiskArbitration.h:27:10:
fatal error: could not build module 'CoreFoundation'
#include <CoreFoundation/CoreFoundation.h>
 ~~~~~~~~^
While building module 'Cocoa' imported from m.mm:1:
While building module 'Foundation' imported from
/System/Library/Frameworks/Cocoa.framework/Headers/Cocoa.h:12:
While building module 'CoreServices' imported from
/System/Library/Frameworks/Foundation.framework/Headers/NSURLError.h:12:
While building module 'CFNetwork' imported from
/System/Library/Frameworks/CoreServices.framework/Headers/CoreServices.h:31:
In file included from <module-includes>:1:
/System/Library/Frameworks/CFNetwork.framework/Headers/CFNetwork.h:18:10: fatal
error: could not build module 'CoreFoundation'
#include <CoreFoundation/CoreFoundation.h>
 ~~~~~~~~^
While building module 'Cocoa' imported from m.mm:1:
While building module 'Foundation' imported from
/System/Library/Frameworks/Cocoa.framework/Headers/Cocoa.h:12:
While building module 'ApplicationServices' imported from
/System/Library/Frameworks/Foundation.framework/Headers/NSAppleEventDescriptor.h:7:
In file included from <module-includes>:1:
/System/Library/Frameworks/ApplicationServices.framework/Headers/ApplicationServices.h:23:10:
fatal error: could not build module 'CoreServices'
#include <CoreServices/CoreServices.h>
 ~~~~~~~~^
While building module 'Cocoa' imported from m.mm:1:
While building module 'Foundation' imported from
/System/Library/Frameworks/Cocoa.framework/Headers/Cocoa.h:12:
While building module 'ApplicationServices' imported from
/System/Library/Frameworks/Foundation.framework/Headers/NSAppleEventDescriptor.h:7:
While building module 'CoreText' imported from
/System/Library/Frameworks/ApplicationServices.framework/Frameworks/ATS.framework/Headers/SFNTLayoutTypes.h:16:
In file included from <module-includes>:1:
In file included from
/System/Library/Frameworks/ApplicationServices.framework/Frameworks/CoreText.framework/Headers/CoreText.h:21:
In file included from
/System/Library/Frameworks/CoreText.framework/Headers/CTFont.h:21:
In file included from
/System/Library/Frameworks/CoreText.framework/Headers/CTFontDescriptor.h:21:
/System/Library/Frameworks/CoreText.framework/Headers/CTFontTraits.h:13:10:
fatal error: could not build module 'CoreFoundation'
#include <CoreFoundation/CFNumber.h>
 ~~~~~~~~^
While building module 'Cocoa' imported from m.mm:1:
While building module 'Foundation' imported from
/System/Library/Frameworks/Cocoa.framework/Headers/Cocoa.h:12:
While building module 'ApplicationServices' imported from
/System/Library/Frameworks/Foundation.framework/Headers/NSAppleEventDescriptor.h:7:
While building module 'ImageIO' imported from
/System/Library/Frameworks/ApplicationServices.framework/Headers/ApplicationServices.h:47:
In file included from <module-includes>:1:
/System/Library/Frameworks/ApplicationServices.framework/Frameworks/ImageIO.framework/Headers/ImageIO.h:11:10:
fatal error: could not build module
      'CoreFoundation'
#include <CoreFoundation/CoreFoundation.h>
 ~~~~~~~~^
While building module 'Cocoa' imported from m.mm:1:
In file included from <module-includes>:1:
/System/Library/Frameworks/Cocoa.framework/Headers/Cocoa.h:12:9: fatal error:
could not build module 'Foundation'
#import <Foundation/Foundation.h>
 ~~~~~~~^
While building module 'Cocoa' imported from m.mm:1:
While building module 'AppKit' imported from
/System/Library/Frameworks/Cocoa.framework/Headers/Cocoa.h:13:
In file included from <module-includes>:1:
/System/Library/Frameworks/AppKit.framework/Headers/AppKit.h:10:9: fatal error:
could not build module 'Foundation'
#import <Foundation/Foundation.h>
 ~~~~~~~^
While building module 'Cocoa' imported from m.mm:1:
While building module 'AppKit' imported from
/System/Library/Frameworks/Cocoa.framework/Headers/Cocoa.h:13:
While building module 'QuartzCore' imported from
/System/Library/Frameworks/AppKit.framework/Headers/NSColor.h:36:
In file included from <module-includes>:1:
In file included from
/System/Library/Frameworks/QuartzCore.framework/Headers/CAAnimation.h:6:
In file included from
/System/Library/Frameworks/QuartzCore.framework/Headers/CALayer.h:6:
In file included from
/System/Library/Frameworks/QuartzCore.framework/Headers/CAMediaTiming.h:6:
/System/Library/Frameworks/QuartzCore.framework/Headers/CABase.h:16:10: fatal
error: could not build module 'CoreFoundation'
#include <CoreFoundation/CoreFoundation.h>
 ~~~~~~~~^
While building module 'Cocoa' imported from m.mm:1:
While building module 'AppKit' imported from
/System/Library/Frameworks/Cocoa.framework/Headers/Cocoa.h:13:
While building module 'QuartzCore' imported from
/System/Library/Frameworks/AppKit.framework/Headers/NSColor.h:36:
While building module 'CoreVideo' imported from
/System/Library/Frameworks/QuartzCore.framework/Headers/CAOpenGLLayer.h:7:
In file included from <module-includes>:1:
In file included from
/System/Library/Frameworks/CoreVideo.framework/Headers/CoreVideo.h:20:
In file included from
/System/Library/Frameworks/CoreVideo.framework/Headers/CVReturn.h:21:
/System/Library/Frameworks/CoreVideo.framework/Headers/CVBase.h:51:10: fatal
error: could not build module 'CoreFoundation'
#include <CoreFoundation/CFBase.h>
 ~~~~~~~~^
While building module 'Cocoa' imported from m.mm:1:
While building module 'AppKit' imported from
/System/Library/Frameworks/Cocoa.framework/Headers/Cocoa.h:13:
While building module 'CoreData' imported from
/System/Library/Frameworks/AppKit.framework/Headers/NSPredicateEditorRowTemplate.h:12:
In file included from <module-includes>:1:
/System/Library/Frameworks/CoreData.framework/Headers/CoreData.h:8:9: fatal
error: could not build module 'Foundation'
#import <Foundation/Foundation.h>
 ~~~~~~~^
m.mm:1:9: fatal error: could not build module 'Cocoa'
#import <Cocoa/Cocoa.h>
 ~~~~~~~^
22 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/20141121/16d24359/attachment.html>

From bugzilla-daemon at llvm.org  Fri Nov 21 02:01:45 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 21 Nov 2014 10:01:45 +0000
Subject: [LLVMbugs] [Bug 21628] New: Increase limit of parameters in
 variadic template packs?
Message-ID: <bug-21628-206@http.llvm.org/bugs/>

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

            Bug ID: 21628
           Summary: Increase limit of parameters in variadic template
                    packs?
           Product: clang
           Version: 3.5
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++11
          Assignee: unassignedclangbugs at nondot.org
          Reporter: dimanne at ya.ru
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified

template <class TUndInt, class TV>
constexpr TUndInt CalcMax(TV V) noexcept { return static_cast<TUndInt>(V); }

template <class TUndInt, class TV, class ...TVs>
constexpr TUndInt CalcMax(TV V, TVs... Vs) noexcept {
    return static_cast<TUndInt>(V) > CalcMax<TUndInt>(Vs...) ?
static_cast<TUndInt>(V) : CalcMax<TUndInt>(Vs...);
}

template <class TVs, TVs... Vs>
class TClass {
   static const auto MaxNotInc = CalcMax<TVs>(Vs...) + 1;
};

int main() {
   TClass<int, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11
            , 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24
                                                                  >  Object;
   return 0;
}



If you shall try to compile above example, you get following error message:

$ clang++ --std=c++11 main.cpp 
main.cpp:2:42: error: in-class initializer for static data member is not a
constant expression
constexpr TUndInt CalcMax(TV V) noexcept { return static_cast<TUndInt>(V); }
                                         ^
main.cpp:17:70: note: in instantiation of template class
      'TClass<int, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16,
17, 18, 19, 20, 21, 22, 23, 24>' requested here
                                                                  >  Object;
                                                                     ^
1 error generated.

but it you decrease number of parameters by commenting out this line
, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24
all works well.



$ clang++ --version
Ubuntu clang version 3.5.0-4ubuntu2 (tags/RELEASE_350/final) (based on LLVM
3.5.0)
Target: x86_64-pc-linux-gnu
Thread model: posix

$ uname -a
Linux DimanNeYa 3.16.0-24-generic #32-Ubuntu SMP Tue Oct 28 13:07:32 UTC 2014
x86_64 x86_64 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/20141121/b9142cfa/attachment.html>

From bugzilla-daemon at llvm.org  Fri Nov 21 02:20:16 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 21 Nov 2014 10:20:16 +0000
Subject: [LLVMbugs] [Bug 21629] New: Warning "missing braces around
 initializer" causing problems with std::array
Message-ID: <bug-21629-206@http.llvm.org/bugs/>

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

            Bug ID: 21629
           Summary: Warning "missing braces around initializer" causing
                    problems with std::array
           Product: clang
           Version: trunk
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++11
          Assignee: unassignedclangbugs at nondot.org
          Reporter: ehysta at gmail.com
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Similar bug as in GCC: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25137

It was resolved with "-Wmissing-braces will no longer be enabled in GCC's -Wall
(for C++ mode), as of 4.8, for precisely the reason you describe.".

Clang: http://coliru.stacked-crooked.com/a/784733e4c860f68e
GCC: http://coliru.stacked-crooked.com/a/5c58c123f2108df5

Code:
#include <array>

template<typename T, size_t N>
struct static_array
{
    T elems[N];
};

int main() {
    std::array<int, 3> a = {1,2,3}; // warning: suggest braces around
initialization of subobject
    static_array<int, 3> b = {1,2,3}; // same
    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/20141121/53b8e0cd/attachment.html>

From bugzilla-daemon at llvm.org  Fri Nov 21 06:52:31 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 21 Nov 2014 14:52:31 +0000
Subject: [LLVMbugs] [Bug 21409] wrong code from loop with FP (loop unrolling)
In-Reply-To: <bug-21409-206@http.llvm.org/bugs/>
References: <bug-21409-206@http.llvm.org/bugs/>
Message-ID: <bug-21409-206-P3ZiBgyoUv@http.llvm.org/bugs/>

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

Sanjay Patel <spatel+llvm at rotateright.com> changed:

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

--- Comment #5 from Sanjay Patel <spatel+llvm at rotateright.com> ---
Should be fixed by:
http://llvm.org/viewvc/llvm-project?view=revision&revision=222451

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

From bugzilla-daemon at llvm.org  Fri Nov 21 09:08:05 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 21 Nov 2014 17:08:05 +0000
Subject: [LLVMbugs] [Bug 21603] Codegen error for uitofp <4 x i32> %2 to <4
 x double> on AVX.
In-Reply-To: <bug-21603-206@http.llvm.org/bugs/>
References: <bug-21603-206@http.llvm.org/bugs/>
Message-ID: <bug-21603-206-0ijpBLMmP0@http.llvm.org/bugs/>

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

Sanjay Patel <spatel+llvm at rotateright.com> changed:

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

--- Comment #2 from Sanjay Patel <spatel+llvm at rotateright.com> ---
I think this was fixed by:
http://llvm.org/viewvc/llvm-project?view=revision&revision=222489

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

From bugzilla-daemon at llvm.org  Fri Nov 21 10:10:11 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 21 Nov 2014 18:10:11 +0000
Subject: [LLVMbugs] [Bug 21631] New: [AArch64] Poor codegen for
 BitfieldInsertOpFromOr when operands are commuted
Message-ID: <bug-21631-206@http.llvm.org/bugs/>

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

            Bug ID: 21631
           Summary: [AArch64] Poor codegen for BitfieldInsertOpFromOr when
                    operands are commuted
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: AArch64
          Assignee: unassignedbugs at nondot.org
          Reporter: mcrosier at codeaurora.org
                CC: apazos at codeaurora.org, james.molloy at arm.com,
                    llvmbugs at cs.uiuc.edu, t.p.northover at gmail.com
    Classification: Unclassified

AFAICT, we can generate

        lsl     w8, w2, #16
        and     w0, w8, #0xff0000
        bfxil   w0, w1, #0, #16

as

        and     w0, w1, #0xffff
        bfi     w0, w2, #16, #8

removing the extra shift instruction.

Test cases:
$> more test.ll 
target datalayout = "e-m:e-i64:64-i128:128-n32:64-S128"
target triple = "aarch64--linux-gnu"

define i32 @good(i32 %x, i32 %code, i32 %mode) {
entry:
  %bf.value = and i32 %code, 65535
  %bf.value2 = shl i32 %mode, 16
  %bf.shl = and i32 %bf.value2, 16711680
  %bf.set = or i32 %bf.shl, %bf.value
  ret i32 %bf.set
}

define i32 @bad(i32 %x, i32 %code, i32 %mode) {
entry:
  %bf.value = and i32 %code, 65535
  %bf.value2 = shl i32 %mode, 16
  %bf.shl = and i32 %bf.value2, 16711680
  %bf.set = or i32 %bf.value, %bf.shl
  ret i32 %bf.set
}

Reproduce:
$> llc -O3 test.ll -o -
        .text
        .file   "test.ll"
        .globl  good
        .align  2
        .type   good, at function
good:                                   // @good
        .cfi_startproc
// BB#0:                                // %entry
        and     w0, w1, #0xffff
        bfi     w0, w2, #16, #8
        ret
.Ltmp1:
        .size   good, .Ltmp1-good
        .cfi_endproc

        .globl  bad
        .align  2
        .type   bad, at function
bad:                                    // @bad
        .cfi_startproc
// BB#0:                                // %entry
        lsl     w8, w2, #16
        and     w0, w8, #0xff0000
        bfxil   w0, w1, #0, #16
        ret
.Ltmp3:
        .size   bad, .Ltmp3-bad
        .cfi_endproc

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

From bugzilla-daemon at llvm.org  Fri Nov 21 10:52:35 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 21 Nov 2014 18:52:35 +0000
Subject: [LLVMbugs] [Bug 21632] New: Assertion failure in
 CXXNameMangler::mangleFunctionParam with typeid() of VLA
Message-ID: <bug-21632-206@http.llvm.org/bugs/>

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

            Bug ID: 21632
           Summary: Assertion failure in
                    CXXNameMangler::mangleFunctionParam with typeid() of
                    VLA
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
          Assignee: unassignedclangbugs at nondot.org
          Reporter: warren_ristow at playstation.sony.com
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified

This is a low-priority issue.

When compiling the following test-case:

  #include <typeinfo>
  #include <stdio.h>

  void foo(int i) {
    char bar[i];

    printf("%s\n", typeid(bar).name());

    return;
  }

with a Release+Asserts build of Clang, an assertion-failure triggers.  A
Release (without Asserts) version compiles it successfully (and without any
warnings).  FTR, in the Release version, 'typeid(bar).name()' returns "Afp__c",
whereas if (for example) the literal 17 had been used for the array (as in
'char bar[17];'), then it returns "A17_c".  I've tested this with a modern
compiler (r222492), but the behavior appears to have existed for a long time.

The assertion-failure is:

  clang: llvm/tools/clang/lib/AST/ItaniumMangle.cpp:3292:
    void (anonymous namespace)::CXXNameMangler::mangleFunctionParam(const
clang::ParmVarDecl *):
    Assertion `parmDepth < FunctionTypeDepth.getDepth()' failed.

Note that the test-case contains ill-formed C++ code.  Specifically, the
typeid() of a Variable-Length array type is ill-formed.  For reference, the
link:

  http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3639.html

contains the following example, which explicitly has a typeid() of a VLA
indicated as being ill-formed:

  void f(std::size_t n)
  {
    int a[n];
    unsigned int x = sizeof(a);            // ill-formed
    const std::type_info& ti = typeid(a);  // ill-formed
    typedef int t[n];                      // ill-formed
  }

g++ considers this to be a user-error (tested with g++ version 4.8.2, but
probably is an error with all relevant versions of g++).  Also tested with
other compilers, and it's considered a user-error.  Likely, the Clang fix will
be to consider it a user-error, and then the ICE will be avoided.

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

From bugzilla-daemon at llvm.org  Fri Nov 21 11:26:03 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 21 Nov 2014 19:26:03 +0000
Subject: [LLVMbugs] [Bug 21633] New: In git/svn trunk,
 make for .../llvm  fails building tools/extras
Message-ID: <bug-21633-206@http.llvm.org/bugs/>

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

            Bug ID: 21633
           Summary: In git/svn trunk, make for .../llvm  fails building
                    tools/extras
           Product: Build scripts
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Makefiles
          Assignee: unassignedbugs at nondot.org
          Reporter: robfowlerhpc at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Did a git pull on llvm and clang on my Ubuntu 14.04 laptop with all current
patches so I could do some work at a conference investigating a code generation
(performance, not correctness) bug (that was present) in clang 3.4.2, i.e., to
ensure that the bug was still present.

make failed after crunching for a couple of hours with complaints about not
finding an iterator deep in the bowels of clang.  (Sorry, the sysout from make
s long gone) I then did "svn update" for both llvm and clang to (trunk 222399),
did a vanilla reconfigure, make clean, and make.  The process failed somewhere
lse with complaints about not finding some directory related to gcc.  (Sorry,
that's gone too.) At that point I uninstalled and reinstalled gcc/g+ 4.8.2
binaries from the Ubuntu repository.  I also decided to accelerate the process,
so I cut back on the  target set.  In the penultimate iteration:

----------------------------
build$ ../llvm/configure --prefix=/home/xxx --enable-targets="nvptx x86_64"

build$ make

<< lots elided >>

llvm[5]: Compiling PreprocessorTracker.cpp for Debug+Asserts build
/home/rjf/LLVM-clang/llvm/tools/clang/tools/extra/modularize/PreprocessorTracker.cpp:
In member function ‘void
Modularize::PreprocessorTrackerImpl::handleHeaderEntry(clang::Preprocessor&,
llvm::StringRef)’:
/home/rjf/LLVM-clang/llvm/tools/clang/tools/extra/modularize/PreprocessorTracker.cpp:960:24:
error: no match for ‘operator!’ (operand type is
‘std::pair<llvm::NoneType, bool>’)
       InNestedHeader = !HeadersInThisCompile.insert(H);
                        ^
/home/rjf/LLVM-clang/llvm/tools/clang/tools/extra/modularize/PreprocessorTracker.cpp:960:24:
note: candidate is:
/home/rjf/LLVM-clang/llvm/tools/clang/tools/extra/modularize/PreprocessorTracker.cpp:960:24:
note: operator!(bool) <built-in>
/home/rjf/LLVM-clang/llvm/tools/clang/tools/extra/modularize/PreprocessorTracker.cpp:960:24:
note:   no known conversion for argument 1 from
‘std::pair<llvm::NoneType, bool>’ to ‘bool’

<< make continued past this point, but eventually bails from this error.>>
-----------------------------------------

At that point I got rid of the extras directories in the distribution tree and
all was copacetic regarding subsequent make and make install of the mainline
clang, 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/20141121/6a9c4d34/attachment.html>

From bugzilla-daemon at llvm.org  Fri Nov 21 11:58:10 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 21 Nov 2014 19:58:10 +0000
Subject: [LLVMbugs] [Bug 21633] In git/svn trunk,
 make for .../llvm  fails building tools/extras
In-Reply-To: <bug-21633-206@http.llvm.org/bugs/>
References: <bug-21633-206@http.llvm.org/bugs/>
Message-ID: <bug-21633-206-ucYnXcFh05@http.llvm.org/bugs/>

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

Reid Kleckner <rnk at google.com> changed:

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

--- Comment #1 from Reid Kleckner <rnk at google.com> ---
This API break in should've been fixed r222336. The clang-tools-extra repo is
separate from clang, so you have to make sure to update it along with clang and
llvm when you update them. Please reopen if you still have issues.

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

From bugzilla-daemon at llvm.org  Fri Nov 21 12:25:48 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 21 Nov 2014 20:25:48 +0000
Subject: [LLVMbugs] [Bug 21635] New: C++ math functions and errno
 dependencies not captured correctly in LLVM builtins
Message-ID: <bug-21635-206@http.llvm.org/bugs/>

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

            Bug ID: 21635
           Summary: C++ math functions and errno dependencies not captured
                    correctly in LLVM builtins
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
          Assignee: unassignedclangbugs at nondot.org
          Reporter: lawrence at codeaurora.org
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 13383
  --> http://llvm.org/bugs/attachment.cgi?id=13383&action=edit
IR Dump for the testcase

The problem is exposed by a very small testcase which do a log(-4) then check
errno, the program doesn’t run correctly if I compile it with llvm for arm 32
bit at O1 and above, the reason is the call to the log function is moved down
after errno checking; If I replace std::log with log,  program can run
correctly, see my command line and testcase below and IR dump in attached t.ll:

clang -mcpu=cortex-a9 -O1   -static -Wno-return-type -fmath-errno -static
-trigraphs -fexceptions t.C  -o t
./t

//t.C
#ifdef NO_CPP_C_HEADERS
#include <math.h>
#else
#include <cmath>
#endif

#include <errno.h>
#include <stdio.h>

float          x3 = -4.0f;
int            locflg=0;

int
main( void )
{
  float          val;

  val = std::log(x3);    // clang generated a call to _ZSt3logf()，which
contains a call to logf(), because std::log is just a wrapper of
__builtin_logf()
  //val = log(x3);       // clang generated a call to log() directly
  if (errno != EDOM) {
    locflg = 1;
    printf( "std::log: GOT %f, EXPECTED EDOM\n", val);
  }

return( locflg );
}

After some debugging, I think the root cause is because of the attribute “c” of
“Fnc” in the following line of tools/clang/include/clang/Basic/Builtins.def:
BUILTIN(__builtin_logf , "dd"  , "Fnc")

“c” means const, then later clang will set the function attribute to readnone
based on that (CodeGenModule::ConstructAttributeList of
tools/clang/lib/CodeGen/CGCall.cpp), that will enable optimizer to do a lot of
unsafe optimization such as move logf pass errno checking, that should not
happen since I have –fmath-errno option.

For C version log function, the attribute is “Fne” according to the following
line in the same Builtins.def
LIBBUILTIN(log, "dd", "fne", "math.h", ALL_LANGUAGES)

Note that “e” mean “const, but only when -fmath-errno=0”, that’s the correct
attribute, and that’s why the optimizer doesn’t do the unsafe optimization.

During filing this bug, I noticed there were related bug #11858 and #5971,
however I think mine is a little bit different since I have -fmath-errno:

so my questions are:

1. why does __builtin_logf and its brothers has different attributes than log
and its brothers?

2. If __builtin_logfs and logs should all have "Fnc", then there should be a
later mechanism in clang to remove readnone if -fmath-errno is present, but I
found none.

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

From bugzilla-daemon at llvm.org  Fri Nov 21 12:43:18 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 21 Nov 2014 20:43:18 +0000
Subject: [LLVMbugs] [Bug 21636] New: -no-integrated-as is broken on Mac OS X
 (Unknown pseudo-op: .macosx_version_min)
Message-ID: <bug-21636-206@http.llvm.org/bugs/>

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

            Bug ID: 21636
           Summary: -no-integrated-as is broken on Mac OS X (Unknown
                    pseudo-op: .macosx_version_min)
           Product: clang
           Version: trunk
          Hardware: Macintosh
                OS: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: t.poechtrager at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

$ cat test.c
int main(){}

$ ~/llvm-trunk/bin/clang test.c -no-integrated-as
/var/folders/yv/43njmxj17k7gv_04z6m21krm0000gn/T/test-4988d4.s:2:Unknown
pseudo-op: .macosx_version_min
/var/folders/yv/43njmxj17k7gv_04z6m21krm0000gn/T/test-4988d4.s:2:Rest of line
ignored. 1st junk character valued 49 (1).
[...]

---

cctools version: 855
clang version: trunk (3.5 seems also affected)

---

$ ~/llvm-trunk/bin/clang test.c -S -o-
        .section        __TEXT,__text,regular,pure_instructions
        .macosx_version_min 10, 9
        .globl  _main
        .align  4, 0x90
_main:                                  ## @main
## BB#0:
        pushl   %ebp
        movl    %esp, %ebp
        movl    $0, %eax
        popl    %ebp
        retl


.subsections_via_symbols

---

Apple Clang:

$ clang test.c -S -o-
        .section        __TEXT,__text,regular,pure_instructions
        .globl  _main
        .align  4, 0x90
_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
        popq    %rbp
        ret
        .cfi_endproc


.subsections_via_symbols

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

From bugzilla-daemon at llvm.org  Fri Nov 21 13:09:26 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 21 Nov 2014 21:09:26 +0000
Subject: [LLVMbugs] [Bug 21632] Assertion failure in
 CXXNameMangler::mangleFunctionParam with typeid() of VLA
In-Reply-To: <bug-21632-206@http.llvm.org/bugs/>
References: <bug-21632-206@http.llvm.org/bugs/>
Message-ID: <bug-21632-206-Qv31vpoB6U@http.llvm.org/bugs/>

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

David Majnemer <david.majnemer at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |david.majnemer at gmail.com
         Resolution|---                         |FIXED
           Assignee|unassignedclangbugs at nondot. |david.majnemer at gmail.com
                   |org                         |

--- Comment #1 from David Majnemer <david.majnemer at gmail.com> ---
Fixed in r222569.

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

From bugzilla-daemon at llvm.org  Fri Nov 21 13:16:28 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 21 Nov 2014 21:16:28 +0000
Subject: [LLVMbugs] [Bug 13772] Casting away qualifiers not warned about
In-Reply-To: <bug-13772-206@http.llvm.org/bugs/>
References: <bug-13772-206@http.llvm.org/bugs/>
Message-ID: <bug-13772-206-klSDiwRZTv@http.llvm.org/bugs/>

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

Roman Divacky <rdivacky at freebsd.org> changed:

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

--- Comment #1 from Roman Divacky <rdivacky at freebsd.org> ---
Implemented in r222568.

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

From bugzilla-daemon at llvm.org  Fri Nov 21 13:18:01 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 21 Nov 2014 21:18:01 +0000
Subject: [LLVMbugs] [Bug 4802] -Wcast-qual not implemented
In-Reply-To: <bug-4802-206@http.llvm.org/bugs/>
References: <bug-4802-206@http.llvm.org/bugs/>
Message-ID: <bug-4802-206-WL6cyTWb8x@http.llvm.org/bugs/>

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

Roman Divacky <rdivacky at freebsd.org> changed:

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

--- Comment #3 from Roman Divacky <rdivacky at freebsd.org> ---
This was (re)implemented in r222568.

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

From bugzilla-daemon at llvm.org  Fri Nov 21 13:48:15 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 21 Nov 2014 21:48:15 +0000
Subject: [LLVMbugs] [Bug 21637] New: [AArch64] A57LoadBalancing rewrites
 registers and introduces miscompile
Message-ID: <bug-21637-206@http.llvm.org/bugs/>

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

            Bug ID: 21637
           Summary: [AArch64] A57LoadBalancing rewrites registers and
                    introduces miscompile
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: ASSIGNED
          Severity: normal
          Priority: P
         Component: Backend: AArch64
          Assignee: james.molloy at arm.com
          Reporter: mcrosier at codeaurora.org
                CC: apazos at codeaurora.org, llvmbugs at cs.uiuc.edu,
                    t.p.northover at gmail.com, zhaoshiz at codeaurora.org
    Classification: Unclassified

Unfortunately, I can't reproduce this on top of trunk, but I'll describe the
issue as best I can.

I have some IR that look like the following:

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

  %call8.i = tail call double @floor(double %div7.i)
  %mul9.i = fmul double %call8.i, 6.000000e+00
  %sub10.i = fsub double %div3.i, %mul9.i

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

Lowering of the floor instruction results in two instructions being emitted:

1.) FRINTMSr to compute the floor value and
2.) FRINTXDr to check for an exception if the result was rounded (base on Tim's
comments on IRC)

See AArch64ISelDAGToDAG::SelectLIMB() for the implementation details.

Also from AArch64InstrInfo.td:

// FRINTX is inserted to set the flags as required by FENV_ACCESS ON behavior
// in the C spec. Setting hasSideEffects ensures it is not DCE'd.
// <rdar://problem/13715968>
// TODO: We should really model the FPSR flags correctly. This is really ugly.
let hasSideEffects = 1 in {
defm FRINTX : SingleOperandFPData<0b1110, "frintx", frint>;
}

The FRINTXDr instruction defines a D register, but it has not use and is marked
dead.

    %D0<def,dead> = FRINTXDr %D28<kill>;

Thus, the RegisterScavenger is free to scavenge this register.

----

Coming into the LoadBalancing pass we have MachineInstrs like the below.
The A57LoadBalancing pass then rewrites D11 to D0 introducing the correctness
issue:

    %D11<def> = FMULDrr %D30<kill>, %D26<kill>;
    %D5<def> = FSUBDrr %D10<kill>, %D31<kill>;
    %D0<def,dead> = FRINTXDr %D28<kill>;
    %D6<def> = FSUBDrr %D14<kill>, %D11<kill>;

becomes:

    %D0<def> = FMULDrr %D30<kill>, %D26<kill>;
    %D5<def> = FSUBDrr %D10<kill>, %D31<kill>;
    %D0<def,dead> = FRINTXDr %D28<kill>;
    %D6<def> = FSUBDrr %D14<kill>, %D0<kill>;

FSUBDrr is now using the incorrect value from the FRINTXDr instruction.

Tim suggest the pass is not correctly checking liveness, which seems
reasonable, but I'm not familiar with the pass.

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

From bugzilla-daemon at llvm.org  Fri Nov 21 13:53:31 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 21 Nov 2014 21:53:31 +0000
Subject: [LLVMbugs] [Bug 21638] New: Segfault when running Talos Principle
	Public Test
Message-ID: <bug-21638-206@http.llvm.org/bugs/>

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

            Bug ID: 21638
           Summary: Segfault when running Talos Principle Public Test
           Product: new-bugs
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: bugspam+llvm at moreofthesa.me.uk
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 13384
  --> http://llvm.org/bugs/attachment.cgi?id=13384&action=edit
Partial backtrace

100% repeatable crash (segfault) after showing the titles. Run-time environment
is SteamOS, but with libgl1-mesa-glx 10.3.2-1 and libllvm3.5 3.5-6 from Debian
jessie; hw is Bonaire XTX.

I also tested using the versions which Valve distributes; it crashes sooner.

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

From bugzilla-daemon at llvm.org  Fri Nov 21 15:08:17 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 21 Nov 2014 23:08:17 +0000
Subject: [LLVMbugs] [Bug 21639] New: llvm::sys::process::get_self is not
	thread-safe
Message-ID: <bug-21639-206@http.llvm.org/bugs/>

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

            Bug ID: 21639
           Summary: llvm::sys::process::get_self is not thread-safe
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: Support Libraries
          Assignee: unassignedbugs at nondot.org
          Reporter: nico.rieck at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

llvm::sys::process::get_self() is not thread-safe (at least on Windows) because
initialization of function local statics is not thread-safe. I've been bitten
by this with random crashes when using Clang in a multi-threaded application.

As long as the minimum required MSVC version does not implement thread-safe
static initialization this should be guarded explicitly (maybe with
ManagedStatic?).

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

From bugzilla-daemon at llvm.org  Fri Nov 21 15:10:40 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 21 Nov 2014 23:10:40 +0000
Subject: [LLVMbugs] [Bug 21624] -fmodules causes failure of inclusion of STL
	headers
In-Reply-To: <bug-21624-206@http.llvm.org/bugs/>
References: <bug-21624-206@http.llvm.org/bugs/>
Message-ID: <bug-21624-206-7bAqVqqBct@http.llvm.org/bugs/>

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

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 is a problem with the Apple system headers, not with Clang or libc++.

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

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

From bugzilla-daemon at llvm.org  Fri Nov 21 15:13:10 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 21 Nov 2014 23:13:10 +0000
Subject: [LLVMbugs] [Bug 21626] clang failed to compile Objective-C++ code
 with -fmodules
In-Reply-To: <bug-21626-206@http.llvm.org/bugs/>
References: <bug-21626-206@http.llvm.org/bugs/>
Message-ID: <bug-21626-206-xZmeYAQPcb@http.llvm.org/bugs/>

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

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

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

--- Comment #1 from Richard Smith <richard-llvm at metafoo.co.uk> ---
This is a problem with the Apple module maps, not with Clang. You can try
adding the [extern_c] attribute to the /usr/include module map to fix this, but
I don't know if that's all you'll need to do.

Please contact Apple to get this issue 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/20141121/bd24f736/attachment.html>

From bugzilla-daemon at llvm.org  Fri Nov 21 15:20:01 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 21 Nov 2014 23:20:01 +0000
Subject: [LLVMbugs] [Bug 21628] Increase limit of number of parameters in
 variadic template packs?
In-Reply-To: <bug-21628-206@http.llvm.org/bugs/>
References: <bug-21628-206@http.llvm.org/bugs/>
Message-ID: <bug-21628-206-s0947AroHP@http.llvm.org/bugs/>

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

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

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

--- Comment #3 from Richard Smith <richard-llvm at metafoo.co.uk> ---
Your code is slow because your algorithm is bad:

template <class TUndInt, class TV, class ...TVs>
constexpr TUndInt CalcMax(TV V, TVs... Vs) noexcept {
    return static_cast<TUndInt>(V) > CalcMax<TUndInt>(Vs...) ?
static_cast<TUndInt>(V) : CalcMax<TUndInt>(Vs...);
}

For a list of N elements, this calls CalcMax on a list of N-1 elements twice.
Thus your function's runtime is O(2^N). When your list has 25 elements, this
hits Clang's limit for complexity of constexpr evaluation.

g++ happens to memoize constexpr evaluations, which hides performance problems
in code like this, but Clang does not.

If you switch to a better algorithm, your problem will go away. For instance:

template <class TUndInt, class TV1, class TV2, class ...TVs>
constexpr TUndInt CalcMax(TV1 V1, TV2 V2, TVs... Vs) noexcept {
    return static_cast<TUndInt>(V1) > static_cast<TUndInt>(V2)
               ? CalcMax<TUndInt>(V1, Vs...)
               : CalcMax<TUndInt>(V2, Vs...);
}

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

From bugzilla-daemon at llvm.org  Fri Nov 21 17:04:12 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 22 Nov 2014 01:04:12 +0000
Subject: [LLVMbugs] [Bug 21640] New: X86 disassembler skips over some bytes
Message-ID: <bug-21640-206@http.llvm.org/bugs/>

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

            Bug ID: 21640
           Summary: X86 disassembler skips over some bytes
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: MC
          Assignee: unassignedbugs at nondot.org
          Reporter: david.majnemer at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

consider:
echo '0x2e 0x24 0x2e' | ~/llvm/AFL/bin/llvm-mc --disassemble
-triple=x86_64-pc-linux -show-encoding -show-inst

this gives us:
 .text
 andb   $46, %al                # encoding: [0x24,0x2e]
                                        # <MCInst #197 AND8i8
                                        #  <MCOperand Imm:46>>

What happened to 0x2e?  It is is a cs segment override prefix but gets no
mention in the disassembly.

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

From bugzilla-daemon at llvm.org  Fri Nov 21 17:28:17 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 22 Nov 2014 01:28:17 +0000
Subject: [LLVMbugs] [Bug 21626] clang failed to compile Objective-C++ code
 with -fmodules
In-Reply-To: <bug-21626-206@http.llvm.org/bugs/>
References: <bug-21626-206@http.llvm.org/bugs/>
Message-ID: <bug-21626-206-Kgh8EjOUIK@http.llvm.org/bugs/>

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

jh <191919 at gmail.com> changed:

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

--- Comment #2 from jh <191919 at gmail.com> ---
There is no module map in /usr/include (see below).

I can write one, but there are C and C++ linkages for different header files, I
can't assume they are all entern_c.

Xcode 6.1's clang (Apple LLVM version 6.0 (clang-600.0.54) (based on LLVM
3.5svn)) compiles the code successfully with `-fmodules`.

------

$ cd /
$ find . -name \*modulemap\*

# System frameworks

./System/Library/PrivateFrameworks/ExchangeWebServices.framework/Versions/A/Modules/module.modulemap


# Below are the module maps in /Application/Xcode.app:

./Applications/Utilities/Tower.app/Contents/Frameworks/FNAppKit.framework/Versions/A/Modules/module.modulemap
./Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/Library/PrivateFrameworks/DVTPlaygroundCommunication.framework/Modules/module.modulemap
./Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk/System/Library/Frameworks/Metal.framework/Modules/module.modulemap
./Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/Library/PrivateFrameworks/DVTPlaygroundCommunication.framework/Modules/module.modulemap
./Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/System/Library/PrivateFrameworks/ExchangeWebServices.framework/Versions/A/Modules/module.modulemap
./Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/sourcekitd.framework/Versions/A/Modules/module.modulemap

# Below are clang's installation directory

./opt/include/clang-c/module.modulemap
./opt/lib/clang/3.6.0/include/module.modulemap

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

From bugzilla-daemon at llvm.org  Fri Nov 21 18:19:30 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 22 Nov 2014 02:19:30 +0000
Subject: [LLVMbugs] [Bug 21641] New: LLVM ERROR: Do not know how to split
 the result of this operator!
Message-ID: <bug-21641-206@http.llvm.org/bugs/>

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

            Bug ID: 21641
           Summary: LLVM ERROR: Do not know how to split the result of
                    this operator!
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: LLVM assembly language parser
          Assignee: unassignedbugs at nondot.org
          Reporter: david at ixit.cz
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

LLVM 3.5 or LLVM get me error
"LLVM ERROR: Do not know how to split the result of this operator!"
 for lot operations done by Mesa llvmpipe.

LLVM is compiled with -march=native.

On my A8-3870 I getting these errors, on AMD Athlon 64 X2 TK-55 same examples
work very well.

Attaching /proc/cpuinfo

processor       : 3
vendor_id       : AuthenticAMD
cpu family      : 18
model           : 1
model name      : AMD A8-3870 APU with Radeon(tm) HD Graphics
stepping        : 0
microcode       : 0x3000027
cpu MHz         : 3300.000
cache size      : 1024 KB
physical id     : 0
siblings        : 4
core id         : 3
cpu cores       : 4
apicid          : 3
initial apicid  : 3
fpu             : yes
fpu_exception   : yes
cpuid level     : 6
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb
rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc extd_apicid
aperfmperf pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy
abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt arat hw_pstate npt lbrv
svm_lock nrip_save pausefilter
bogomips        : 6929.95
TLB size        : 1536 4K pages
clflush size    : 64
cache_alignment : 64
address sizes   : 40 bits physical, 48 bits virtual
power management: ts ttp tm stc 100mhzsteps hwpstate

I can do tests if needed except compiling LLVM with debug.

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

From bugzilla-daemon at llvm.org  Sat Nov 22 01:43:04 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 22 Nov 2014 09:43:04 +0000
Subject: [LLVMbugs] [Bug 21643] New: __attribute__((address_space)) doesn't
 work with atomic builtins
Message-ID: <bug-21643-206@http.llvm.org/bugs/>

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

            Bug ID: 21643
           Summary: __attribute__((address_space)) doesn't work with
                    atomic builtins
           Product: clang
           Version: 3.5
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: admin at chys.info
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Test case:

void foo() {
        typedef int __attribute__((address_space(257))) *ptr_fs_t;
        __atomic_or_fetch((ptr_fs_t)0x308, 1, __ATOMIC_RELAXED);
}


Expected result:

        lock
        orl     $1, %fs:776
        retq


Actual result 1 (clang 3.5.0):

        lock
        orl     $1, 776
        retq


Actual result 2 (trunk version):

clang-3.6: /home/x/prog/P/llvm/lib/IR/Constants.cpp:1556: static llvm::Constant
*llvm::ConstantExpr::getCast(unsigned int, llvm::Constant *, llvm::Type *,
bool): Assertion `CastInst::castIsValid(opc, C, Ty) && "Invalid constantexpr
cast!"' failed.
#0 0x1431ce8 llvm::sys::PrintStackTrace(_IO_FILE*)
(/usr/local/llvm-svn/bin/clang-3.6+0x1431ce8)
#1 0x143339b SignalHandler(int) (/usr/local/llvm-svn/bin/clang-3.6+0x143339b)
#2 0x7f79065994e0 (/lib64/libpthread.so.0+0x104e0)
#3 0x7f7905a065d7 gsignal (/lib64/libc.so.6+0x385d7)
#4 0x7f7905a078f8 abort (/lib64/libc.so.6+0x398f8)
#5 0x7f79059ff706 (/lib64/libc.so.6+0x31706)
#6 0x7f79059ff7b2 (/lib64/libc.so.6+0x317b2)
#7 0x10a1a94 (/usr/local/llvm-svn/bin/clang-3.6+0x10a1a94)
#8 0x1a2b992
clang::CodeGen::CodeGenFunction::EmitAtomicExpr(clang::AtomicExpr*,
llvm::Value*) (/usr/local/llvm-svn/bin/clang-3.6+0x1a2b992)
#9 0x19c887e clang::StmtVisitorBase<clang::make_ptr, (anonymous
namespace)::ScalarExprEmitter, llvm::Value*>::Visit(clang::Stmt*)
(/usr/local/llvm-svn/bin/clang-3.6+0x19c887e)
#10 0x19be6a3 clang::CodeGen::CodeGenFunction::EmitScalarExpr(clang::Expr
const*, bool) (/usr/local/llvm-svn/bin/clang-3.6+0x19be6a3)
#11 0x1991439 clang::CodeGen::CodeGenFunction::EmitAnyExpr(clang::Expr const*,
clang::CodeGen::AggValueSlot, bool)
(/usr/local/llvm-svn/bin/clang-3.6+0x1991439)
#12 0x1894c41 clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*)
(/usr/local/llvm-svn/bin/clang-3.6+0x1894c41)
#13 0x189dd4b
clang::CodeGen::CodeGenFunction::EmitCompoundStmtWithoutScope(clang::CompoundStmt
const&, bool, clang::CodeGen::AggValueSlot)
(/usr/local/llvm-svn/bin/clang-3.6+0x189dd4b)
#14 0x18b1817
clang::CodeGen::CodeGenFunction::EmitFunctionBody(clang::CodeGen::FunctionArgList&,
clang::Stmt const*) (/usr/local/llvm-svn/bin/clang-3.6+0x18b1817)
#15 0x18b1ebd clang::CodeGen::CodeGenFunction::GenerateCode(clang::GlobalDecl,
llvm::Function*, clang::CodeGen::CGFunctionInfo const&)
(/usr/local/llvm-svn/bin/clang-3.6+0x18b1ebd)
#16 0x18c0fcf
clang::CodeGen::CodeGenModule::EmitGlobalFunctionDefinition(clang::GlobalDecl,
llvm::GlobalValue*) (/usr/local/llvm-svn/bin/clang-3.6+0x18c0fcf)
#17 0x18bdd8f
clang::CodeGen::CodeGenModule::EmitGlobalDefinition(clang::GlobalDecl,
llvm::GlobalValue*) (/usr/local/llvm-svn/bin/clang-3.6+0x18bdd8f)
#18 0x18c29e1 clang::CodeGen::CodeGenModule::EmitTopLevelDecl(clang::Decl*)
(/usr/local/llvm-svn/bin/clang-3.6+0x18c29e1)
#19 0x1860fff (anonymous
namespace)::CodeGeneratorImpl::HandleTopLevelDecl(clang::DeclGroupRef)
(/usr/local/llvm-svn/bin/clang-3.6+0x1860fff)
#20 0x1858227 clang::BackendConsumer::HandleTopLevelDecl(clang::DeclGroupRef)
(/usr/local/llvm-svn/bin/clang-3.6+0x1858227)
#21 0x1e1e1d3 clang::ParseAST(clang::Sema&, bool, bool)
(/usr/local/llvm-svn/bin/clang-3.6+0x1e1e1d3)
#22 0x15d3a5e clang::FrontendAction::Execute()
(/usr/local/llvm-svn/bin/clang-3.6+0x15d3a5e)
#23 0x15a4c9c clang::CompilerInstance::ExecuteAction(clang::FrontendAction&)
(/usr/local/llvm-svn/bin/clang-3.6+0x15a4c9c)
#24 0x165a9d2 clang::ExecuteCompilerInvocation(clang::CompilerInstance*)
(/usr/local/llvm-svn/bin/clang-3.6+0x165a9d2)
#25 0x6c74fe cc1_main(llvm::ArrayRef<char const*>, char const*, void*)
(/usr/local/llvm-svn/bin/clang-3.6+0x6c74fe)
#26 0x6c5f05 main (/usr/local/llvm-svn/bin/clang-3.6+0x6c5f05)
#27 0x7f79059f2dc5 __libc_start_main (/lib64/libc.so.6+0x24dc5)
#28 0x6c2cdd _start (/usr/local/llvm-svn/bin/clang-3.6+0x6c2cdd)
Stack dump:
0.      Program arguments: /usr/local/llvm-svn/bin/clang-3.6 -cc1 -triple
x86_64-unknown-linux-gnu -S -disable-free -main-file-name a.c
-mrelocation-model static -mthread-model posix -fmath-errno -masm-verbose
-mconstructor-aliases -munwind-tables -fuse-init-array -target-cpu x86-64
-momit-leaf-frame-pointer -dwarf-column-info -coverage-file /tmp/a.c
-resource-dir /usr/local/llvm-svn/bin/../lib/clang/3.6.0 -internal-isystem
/usr/local/include -internal-isystem
/usr/local/llvm-svn/bin/../lib/clang/3.6.0/include -internal-externc-isystem
/include -internal-externc-isystem /usr/include -O2 -fdebug-compilation-dir
/tmp -ferror-limit 19 -fmessage-length 230 -mstackrealign -fobjc-runtime=gcc
-fdiagnostics-show-option -fcolor-diagnostics -vectorize-loops -vectorize-slp
-o a.s -x c a.c 
1.      a.c:7:1: current parser token 'int'
2.      a.c:3:6: LLVM IR generation of declaration 'foo'
3.      a.c:3:6: Generating code for declaration 'foo'
clang-3.6: error: unable to execute command: Aborted
clang-3.6: error: clang frontend command failed due to signal (use -v to see
invocation)
clang version 3.6.0 
Target: x86_64-unknown-linux-gnu
Thread model: posix
clang-3.6: 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.6: 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/20141122/c18cce36/attachment.html>

From bugzilla-daemon at llvm.org  Sat Nov 22 02:47:35 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 22 Nov 2014 10:47:35 +0000
Subject: [LLVMbugs] [Bug 21643] __attribute__((address_space)) doesn't work
 with atomic builtins
In-Reply-To: <bug-21643-206@http.llvm.org/bugs/>
References: <bug-21643-206@http.llvm.org/bugs/>
Message-ID: <bug-21643-206-9QmoL47gS3@http.llvm.org/bugs/>

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

David Majnemer <david.majnemer at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED
           Assignee|unassignedclangbugs at nondot. |david.majnemer at gmail.com
                   |org                         |

--- Comment #2 from David Majnemer <david.majnemer at gmail.com> ---
Fixed in r222615.

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

From bugzilla-daemon at llvm.org  Sat Nov 22 13:39:14 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 22 Nov 2014 21:39:14 +0000
Subject: [LLVMbugs] [Bug 21644] New: COMDAT causes GNU AS for ARM crash
Message-ID: <bug-21644-206@http.llvm.org/bugs/>

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

            Bug ID: 21644
           Summary: COMDAT causes GNU AS for ARM crash
           Product: clang
           Version: unspecified
          Hardware: PC
                OS: Linux
            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

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

r218141 "In the Itanium ABI, move stuff to the comdat of variables with static
init." causes gnu as crash for ARM in some cases:

mytest.s: Assembler messages:
mytest.s:106: Internal error!
Assertion failure in get_line_subseg at
/prj/llvm-arm/home/sgundapa/crosstool_linaro/src/crosstool-ng-linaro-1.13.1-4.8-2014.01/builds/arm-linux-gnueabi-linux/.build/src/binutils-linaro-2.24-2013.12/gas/dwarf2dbg.c
line 271.


GNU assembelr version is :
GNU assembler version 2.24 (arm-linux-gnueabi) using BFD version (crosstool-NG
linaro-1.13.1-4.8-2014.01 - Linaro GCC 2013.11) 2.24


Attached are the test case and generated assembly files.

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

From bugzilla-daemon at llvm.org  Sat Nov 22 20:02:24 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 23 Nov 2014 04:02:24 +0000
Subject: [LLVMbugs] [Bug 21645] New: Assertion `VT.getSizeInBits() ==
 Operand.getValueType().getSizeInBits() && "Cannot BITCAST between types of
 different sizes!"' failed
Message-ID: <bug-21645-206@http.llvm.org/bugs/>

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

            Bug ID: 21645
           Summary: Assertion `VT.getSizeInBits() ==
                    Operand.getValueType().getSizeInBits() && "Cannot
                    BITCAST between types of different sizes!"' failed
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: ARM
          Assignee: unassignedbugs at nondot.org
          Reporter: joerg at NetBSD.org
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

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

Build attached source with -O2 for ARM.

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

From bugzilla-daemon at llvm.org  Sun Nov 23 02:20:08 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 23 Nov 2014 10:20:08 +0000
Subject: [LLVMbugs] [Bug 21647] New: While the code compiles with g++ with
 clang it generates a bug
Message-ID: <bug-21647-206@http.llvm.org/bugs/>

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

            Bug ID: 21647
           Summary: While the code compiles with g++ with clang it
                    generates a bug
           Product: clang
           Version: unspecified
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: gkourtis at freemail.gr
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 13389
  --> http://llvm.org/bugs/attachment.cgi?id=13389&action=edit
The compiler hangs

/bin/sh -c 'make -j4 -e -f  Makefile'
----------Building project:[ napl20 - mx32clang ]----------
make[1]: Entering directory '/home/gk/.codelite/workspace01/napl20'
/usr/bin/clang++   -c  "/home/gk/Dropbox/workspace01/napl20/main.cpp" -mx32
-std=c++14 -O0 -g -funsigned-char -fpermissive -Wno-logical-op-parentheses   -o
./mx32/main.cpp.o -I. -I/usr/include/x86_64-linux-gnu/c++/4.9/x32
-I/usr/include/x86_64-linux-gnu
fatal error: error in backend: Cannot select: 0x4854048: ch = brind
0x4853a88:1, 0x4853a88 [ORD=1] [ID=10]
  0x4853a88: i32,ch = load 0x4853980:1, 0x4835350, 0x484d578<LD4[JumpTable]>
[ORD=1] [ID=9]
    0x4835350: i32 = add 0x4833a68, 0x4837270 [ORD=1] [ID=8]
      0x4833a68: i32 = shl 0x4853980, 0x48459b0 [ORD=1] [ID=7]
        0x4853980: i32,ch = CopyFromReg 0x4582490, 0x4842a08 [ORD=1] [ID=5]
          0x4842a08: i32 = Register %vreg41 [ID=1]
        0x48459b0: i8 = Constant<2> [ID=4]
      0x4837270: i32 = X86ISD::Wrapper 0x4805d00 [ID=6]
        0x4805d00: i32 = TargetJumpTable<0> [ID=3]
    0x484d578: i32 = undef [ID=2]
In function: _Z6newobjIiE3objS0_PKT_jjjb
clang: error: clang frontend command failed with exit code 70 (use -v to see
invocation)
Ubuntu clang version 3.5.0-4ubuntu2 (tags/RELEASE_350/final) (based on LLVM
3.5.0)
Target: x86_64-pc-linux-gnux32
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/main-7567a4.cpp
clang: note: diagnostic msg: /tmp/main-7567a4.sh
clang: note: diagnostic msg:

********************
napl20.mk:91: recipe for target 'mx32/main.cpp.o' failed
make[1]: *** [mx32/main.cpp.o] Error 70
make[1]: Leaving directory '/home/gk/.codelite/workspace01/napl20'
Makefile:4: recipe for target 'All' failed
make: *** [All] Error 2
1 errors, 0 warnings

The code of the function is:

template<typename T> obj newobj(
  obj Class,const T* pValues=nullptr,uWord size=1,uWord elements=1,uWord
exL=0,bool isReference=false
)
{
// the function constructs an object of type "Class" that containes elements of
type T.
// The number of elements is elements. The execution Level is given defaults to
passive=0
    tobj o=reserveVect();
    o.Class(Class);
    o.executionLevel(exL);
    o.readOnly(false);o.reference(isReference);o.keepAlive(false);

    switch(Class.w) {
        case _classAggregate:
        case _classString:{
            if(size<=std::numeric_limits<suWord>::max()){ 
                hAggregateBase_<T,suWord>
*p=o.allocateBody<hAggregateBase_<T,suWord>,T>(size);
                p->size=size;
                if(pValues) memcpy(p+1,pValues,sizeof(T)*elements);
                p->n=elements;break;
            }else{
                hAggregateBase_<T,uWord>
*p=o.allocateBody<hAggregateBase_<T,uWord>,T>(size);
                p->size=size;
                if(pValues) memcpy(p+1,pValues,sizeof(T)*elements);
                p->n=elements;break;
            }        
        }
        classVarAggregate(_classVar,o,hVarBase<T>,) // it is correct that the
last arg is missing
        classBasicData(_classFloat,o,hFixBase<T>,T)
        classBasicData(_classDouble,o,hFixBase<T>,T)
        classBasicData(_classInt,o,hFixBase<T>,T)
        case _classUndefined:
            break;
        case _classPrimitive:
            o.executeP((primitiveP)pValues);
            break;// in that case the elements parameter is ignored.
        default:
            assert0(false,"Problem in newobj");
    }
    gctest();
    return 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/20141123/41560ae6/attachment.html>

From bugzilla-daemon at llvm.org  Sun Nov 23 07:10:24 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 23 Nov 2014 15:10:24 +0000
Subject: [LLVMbugs] [Bug 21648] New: Improve clang++ message for
	ref-qualifier
Message-ID: <bug-21648-206@http.llvm.org/bugs/>

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

            Bug ID: 21648
           Summary: Improve clang++ message for ref-qualifier
           Product: clang
           Version: 3.5
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++11
          Assignee: unassignedclangbugs at nondot.org
          Reporter: vncgxb at clrmail.com
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified

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

When I compile the attached code with 'clang++ -std=c++11 main.cc', clang
produces the following line (besides others):

main.cc:4:7: note: candidate function not viable: no known conversion from
'Foo' to 'Foo' for object argument

Please change the message to something that is clearer, because at first I was
wondering why a conversion should be needed at all. Foo is Foo after all. Thank
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/20141123/415a6b05/attachment.html>

From bugzilla-daemon at llvm.org  Sun Nov 23 07:12:12 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 23 Nov 2014 15:12:12 +0000
Subject: [LLVMbugs] [Bug 21649] New: Please support https!
Message-ID: <bug-21649-206@http.llvm.org/bugs/>

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

            Bug ID: 21649
           Summary: Please support https!
           Product: Bugzilla Admin
           Version: unspecified
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: UI
          Assignee: unassignedbugs at nondot.org
          Reporter: vncgxb at clrmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Bugzilla handles email addresses and passwords but doesn't use https. Please
change that asap.

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

From bugzilla-daemon at llvm.org  Sun Nov 23 12:16:10 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 23 Nov 2014 20:16:10 +0000
Subject: [LLVMbugs] [Bug 21626] clang failed to compile Objective-C++ code
 with -fmodules
In-Reply-To: <bug-21626-206@http.llvm.org/bugs/>
References: <bug-21626-206@http.llvm.org/bugs/>
Message-ID: <bug-21626-206-LSRtPzbI6s@http.llvm.org/bugs/>

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

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

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

--- Comment #5 from Richard Smith <richard-llvm at metafoo.co.uk> ---
The next problem is with the CoreFoundation module map. Again, this is an Apple
problem not a Clang one. The reason why this "works" with XCode 6.1 is that
-fmodules does nothing in C++ mode there.

Ultimately, the problem is that the module maps you're using have not been made
to work with C++, and they don't.

The point of [extern_c] is twofold: (1) it builds the target module in an
implicit extern "C" context (which affects its semantics in lots of ways), and
(2) it allows the module to be imported in an extern "C" context. You don't
want (2) without (1), because that can lead to silent and hard-to-diagnose
build breaks.

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

From bugzilla-daemon at llvm.org  Sun Nov 23 17:58:05 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 24 Nov 2014 01:58:05 +0000
Subject: [LLVMbugs] [Bug 21626] clang failed to compile Objective-C++ code
 with -fmodules
In-Reply-To: <bug-21626-206@http.llvm.org/bugs/>
References: <bug-21626-206@http.llvm.org/bugs/>
Message-ID: <bug-21626-206-1dmZ0KkD85@http.llvm.org/bugs/>

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

jh <191919 at gmail.com> changed:

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

--- Comment #6 from jh <191919 at gmail.com> ---
> The point of [extern_c] is twofold: (1) it builds the
> target module in an implicit extern "C" context (which
> affects its semantics in lots of ways), and (2) it
> allows the module to be imported in an extern "C"
> context. You don't want (2) without (1), because that
> can lead to silent and hard-to-diagnose build breaks.

Thank you for the explanation.

I don't know whether it is correct: `module` works like precompiled headers
which works fine without [extern_c]. Since `extern "C"` is a linkage, i.e., it
is used in link-time, and the linker works fine with current defines in
headers, why another marker is needed at compile-time?

> The next problem is with the CoreFoundation module map.
> Again, this is an Apple problem not a Clang one. The
> reason why this "works" with XCode 6.1 is that -fmodules
> does nothing in C++ mode there.

> Ultimately, the problem is that the module maps you're
> using have not been made to work with C++, and they don't.

I have modified all module maps in OS X SDK and recompile the code, this time
the header-file-scattering problem.

In OS X/iOS SDK, header files in one framework could be in another framework,
for example: IORegistryEntry.h belongs to IOKit，but it is placed under
Kernel.framework. I know this is Apple's problem, too, but the old question:
without `-fmodules`, the compiler works fine with locating the file in both
objective-C and C++ mode.


```
While building module 'Cocoa' imported from m.mm:1:
While building module 'Foundation' imported from
/System/Library/Frameworks/Cocoa.framework/Headers/Cocoa.h:12:
While building module 'CoreGraphics' imported from
/System/Library/Frameworks/Foundation.framework/Headers/NSGeometry.h:12:
While building module 'IOKit' imported from
/System/Library/Frameworks/CoreGraphics.framework/Headers/CGDisplayConfiguration.h:8:
In file included from <module-includes>:126:
/System/Library/Frameworks/IOKit.framework/Headers/video/IOVideoDevice.h:12:10:
fatal error: 'IOKit/IOService.h' file not found
#include <IOKit/IOService.h>
         ^
While building module 'Cocoa' imported from m.mm:1:
While building module 'Foundation' imported from
/System/Library/Frameworks/Cocoa.framework/Headers/Cocoa.h:12:
While building module 'CoreGraphics' imported from
/System/Library/Frameworks/Foundation.framework/Headers/NSGeometry.h:12:
In file included from <module-includes>:1:
In file included from
/System/Library/Frameworks/CoreGraphics.framework/Headers/CoreGraphics.h:41:
/System/Library/Frameworks/CoreGraphics.framework/Headers/CGDisplayConfiguration.h:8:10:
fatal error: could not build module 'IOKit'
#include <IOKit/IOKitLib.h>
 ~~~~~~~~^
While building module 'Cocoa' imported from m.mm:1:
While building module 'Foundation' imported from
/System/Library/Frameworks/Cocoa.framework/Headers/Cocoa.h:12:
While building module 'CoreGraphics' imported from
/System/Library/Frameworks/Foundation.framework/Headers/NSGeometry.h:12:
While building module 'IOSurface' imported from
/System/Library/Frameworks/CoreGraphics.framework/Headers/CGDisplayStream.h:9:
In file included from <module-includes>:1:
In file included from
/System/Library/Frameworks/IOSurface.framework/Headers/IOSurface.h:13:
/System/Library/Frameworks/IOSurface.framework/Headers/IOSurfaceAPI.h:12:10:
fatal error: could not build module 'IOKit'
#include <IOKit/IOKitLib.h>
 ~~~~~~~~^
While building module 'Cocoa' imported from m.mm:1:
While building module 'Foundation' imported from
/System/Library/Frameworks/Cocoa.framework/Headers/Cocoa.h:12:
In file included from <module-includes>:1:
In file included from
/System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:42:
In file included from
/System/Library/Frameworks/Foundation.framework/Headers/NSKeyedArchiver.h:8:
/System/Library/Frameworks/Foundation.framework/Headers/NSGeometry.h:12:9:
fatal error: could not build module 'CoreGraphics'
#import <CoreGraphics/CGBase.h>
 ~~~~~~~^
While building module 'Cocoa' imported from m.mm:1:
While building module 'Foundation' imported from
/System/Library/Frameworks/Cocoa.framework/Headers/Cocoa.h:12:
While building module 'CoreServices' imported from
/System/Library/Frameworks/Foundation.framework/Headers/NSURLError.h:12:
While building module 'DiskArbitration' imported from
/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/Files.h:56:
In file included from <module-includes>:1:
In file included from
/System/Library/Frameworks/DiskArbitration.framework/Headers/DiskArbitration.h:29:
/System/Library/Frameworks/DiskArbitration.framework/Headers/DADisk.h:28:10:
fatal error: could not build module 'IOKit'
#include <IOKit/IOKitLib.h>
 ~~~~~~~~^
While building module 'Cocoa' imported from m.mm:1:
While building module 'Foundation' imported from
/System/Library/Frameworks/Cocoa.framework/Headers/Cocoa.h:12:
While building module 'CoreServices' imported from
/System/Library/Frameworks/Foundation.framework/Headers/NSURLError.h:12:
In file included from <module-includes>:1:
In file included from
/System/Library/Frameworks/CoreServices.framework/Headers/CoreServices.h:23:
In file included from
/System/Library/Frameworks/CoreServices.framework/Frameworks/AE.framework/Headers/AE.h:20:
In file included from
/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/CarbonCore.h:87:
In file included from
/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/Components.h:26:
/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/Files.h:56:10:
fatal error: could not build module 'DiskArbitration'
#include <DiskArbitration/DADisk.h>
 ~~~~~~~~^
While building module 'Cocoa' imported from m.mm:1:
While building module 'Foundation' imported from
/System/Library/Frameworks/Cocoa.framework/Headers/Cocoa.h:12:
While building module 'ApplicationServices' imported from
/System/Library/Frameworks/Foundation.framework/Headers/NSAppleEventDescriptor.h:7:
In file included from <module-includes>:1:
/System/Library/Frameworks/ApplicationServices.framework/Headers/ApplicationServices.h:23:10:
fatal error: could not build module 'CoreServices'
#include <CoreServices/CoreServices.h>
 ~~~~~~~~^
While building module 'Cocoa' imported from m.mm:1:
While building module 'Foundation' imported from
/System/Library/Frameworks/Cocoa.framework/Headers/Cocoa.h:12:
While building module 'ApplicationServices' imported from
/System/Library/Frameworks/Foundation.framework/Headers/NSAppleEventDescriptor.h:7:
While building module 'CoreText' imported from
/System/Library/Frameworks/ApplicationServices.framework/Frameworks/ATS.framework/Headers/SFNTLayoutTypes.h:16:
In file included from <module-includes>:1:
In file included from
/System/Library/Frameworks/ApplicationServices.framework/Frameworks/CoreText.framework/Headers/CoreText.h:21:
In file included from
/System/Library/Frameworks/CoreText.framework/Headers/CTFont.h:21:
/System/Library/Frameworks/CoreText.framework/Headers/CTFontDescriptor.h:28:10:
fatal error: could not build module 'CoreGraphics'
#include <CoreGraphics/CGAffineTransform.h>
 ~~~~~~~~^
While building module 'Cocoa' imported from m.mm:1:
While building module 'Foundation' imported from
/System/Library/Frameworks/Cocoa.framework/Headers/Cocoa.h:12:
While building module 'ApplicationServices' imported from
/System/Library/Frameworks/Foundation.framework/Headers/NSAppleEventDescriptor.h:7:
While building module 'ImageIO' imported from
/System/Library/Frameworks/ApplicationServices.framework/Headers/ApplicationServices.h:47:
In file included from <module-includes>:1:
In file included from
/System/Library/Frameworks/ApplicationServices.framework/Frameworks/ImageIO.framework/Headers/ImageIO.h:16:
/System/Library/Frameworks/ImageIO.framework/Headers/CGImageSource.h:14:10:
fatal error: could not build module 'CoreGraphics'
#include <CoreGraphics/CoreGraphics.h>
 ~~~~~~~~^
While building module 'Cocoa' imported from m.mm:1:
In file included from <module-includes>:1:
/System/Library/Frameworks/Cocoa.framework/Headers/Cocoa.h:12:9: fatal error:
could not build module 'Foundation'
#import <Foundation/Foundation.h>
 ~~~~~~~^
While building module 'Cocoa' imported from m.mm:1:
While building module 'AppKit' imported from
/System/Library/Frameworks/Cocoa.framework/Headers/Cocoa.h:13:
In file included from <module-includes>:1:
/System/Library/Frameworks/AppKit.framework/Headers/AppKit.h:10:9: fatal error:
could not build module 'Foundation'
#import <Foundation/Foundation.h>
 ~~~~~~~^
While building module 'Cocoa' imported from m.mm:1:
While building module 'AppKit' imported from
/System/Library/Frameworks/Cocoa.framework/Headers/Cocoa.h:13:
While building module 'QuartzCore' imported from
/System/Library/Frameworks/AppKit.framework/Headers/NSColor.h:36:
In file included from <module-includes>:1:
In file included from
/System/Library/Frameworks/QuartzCore.framework/Headers/CAAnimation.h:6:
In file included from
/System/Library/Frameworks/QuartzCore.framework/Headers/CALayer.h:6:
In file included from
/System/Library/Frameworks/QuartzCore.framework/Headers/CAMediaTiming.h:6:
/System/Library/Frameworks/QuartzCore.framework/Headers/CABase.h:17:10: fatal
error: could not build module 'ApplicationServices'
#include <ApplicationServices/ApplicationServices.h>
 ~~~~~~~~^
While building module 'Cocoa' imported from m.mm:1:
While building module 'AppKit' imported from
/System/Library/Frameworks/Cocoa.framework/Headers/Cocoa.h:13:
While building module 'QuartzCore' imported from
/System/Library/Frameworks/AppKit.framework/Headers/NSColor.h:36:
While building module 'CoreVideo' imported from
/System/Library/Frameworks/QuartzCore.framework/Headers/CAOpenGLLayer.h:7:
In file included from <module-includes>:1:
In file included from
/System/Library/Frameworks/CoreVideo.framework/Headers/CoreVideo.h:25:
/System/Library/Frameworks/CoreVideo.framework/Headers/CVDisplayLink.h:24:10:
fatal error: could not build module 'ApplicationServices'
#include <ApplicationServices/ApplicationServices.h>
 ~~~~~~~~^
While building module 'Cocoa' imported from m.mm:1:
While building module 'AppKit' imported from
/System/Library/Frameworks/Cocoa.framework/Headers/Cocoa.h:13:
While building module 'CoreData' imported from
/System/Library/Frameworks/AppKit.framework/Headers/NSPredicateEditorRowTemplate.h:12:
In file included from <module-includes>:1:
/System/Library/Frameworks/CoreData.framework/Headers/CoreData.h:8:9: fatal
error: could not build module 'Foundation'
#import <Foundation/Foundation.h>
 ~~~~~~~^
m.mm:1:9: fatal error: could not build module 'Cocoa'
#import <Cocoa/Cocoa.h>
 ~~~~~~~^
15 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/20141124/e2d24a1e/attachment.html>

From bugzilla-daemon at llvm.org  Sun Nov 23 20:49:09 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 24 Nov 2014 04:49:09 +0000
Subject: [LLVMbugs] [Bug 21650] New: PowerPC attn instruction missing from
	assembler
Message-ID: <bug-21650-206@http.llvm.org/bugs/>

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

            Bug ID: 21650
           Summary: PowerPC attn instruction missing from assembler
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: PowerPC
          Assignee: unassignedbugs at nondot.org
          Reporter: anton at samba.org
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

I get an error when assembling code containing the attn instruction:

foo.S: error: unrecognized instruction mnemonic
 attn
 ^

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

From bugzilla-daemon at llvm.org  Sun Nov 23 21:36:34 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 24 Nov 2014 05:36:34 +0000
Subject: [LLVMbugs] [Bug 21651] New: opt crash
Message-ID: <bug-21651-206@http.llvm.org/bugs/>

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

            Bug ID: 21651
           Summary: opt crash
           Product: new-bugs
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: regehr at cs.utah.edu
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

regehr at regehr-M51AC:~$ llvm-as < foo.ll | opt -O3
WARNING: You're attempting to print out a bitcode file.
This is inadvisable as it may cause display problems. If
you REALLY want to taste LLVM bitcode first-hand, you
can force output with the `-f' option.

#0 0x137f812 llvm::sys::PrintStackTrace(_IO_FILE*)
(/home/regehr/z/compiler-install/llvm-r222644-install/bin/opt+0x137f812)
#1 0x137d9a1 SignalHandler(int)
(/home/regehr/z/compiler-install/llvm-r222644-install/bin/opt+0x137d9a1)
#2 0x7f3583734340 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x10340)
#3 0xfcd050 llvm::DataLayout::getLargestLegalIntTypeSize() const
(/home/regehr/z/compiler-install/llvm-r222644-install/bin/opt+0xfcd050)
#4 0x1106f0e llvm::InstCombiner::visitSwitchInst(llvm::SwitchInst&)
(/home/regehr/z/compiler-install/llvm-r222644-install/bin/opt+0x1106f0e)
#5 0x1110eee llvm::InstCombiner::DoOneIteration(llvm::Function&, unsigned int)
(/home/regehr/z/compiler-install/llvm-r222644-install/bin/opt+0x1110eee)
#6 0x1111e18 llvm::InstCombiner::runOnFunction(llvm::Function&)
(/home/regehr/z/compiler-install/llvm-r222644-install/bin/opt+0x1111e18)
#7 0x107644f llvm::FPPassManager::runOnFunction(llvm::Function&)
(/home/regehr/z/compiler-install/llvm-r222644-install/bin/opt+0x107644f)
#8 0x10b2d29 (anonymous namespace)::CGPassManager::runOnModule(llvm::Module&)
(/home/regehr/z/compiler-install/llvm-r222644-install/bin/opt+0x10b2d29)
#9 0x1076bfd llvm::legacy::PassManagerImpl::run(llvm::Module&)
(/home/regehr/z/compiler-install/llvm-r222644-install/bin/opt+0x1076bfd)
#10 0x604a5f main
(/home/regehr/z/compiler-install/llvm-r222644-install/bin/opt+0x604a5f)
#11 0x7f3582934ec5 __libc_start_main
/build/buildd/eglibc-2.19/csu/libc-start.c:321:0
#12 0x627e01 _start
(/home/regehr/z/compiler-install/llvm-r222644-install/bin/opt+0x627e01)
Stack dump:
0.    Program arguments: opt -O3 
1.    Running pass 'CallGraph Pass Manager' on module '<stdin>'.
2.    Running pass 'Combine redundant instructions' on function '@foo'
Segmentation fault (core dumped)


regehr at regehr-M51AC:~$ opt --version
LLVM (http://llvm.org/):
  LLVM version 3.6.0svn
  Optimized build with assertions.
  Built Nov 23 2014 (21:45:31).
  Default target: x86_64-unknown-linux-gnu
  Host CPU: core-avx2


regehr at regehr-M51AC:~$ cat foo.ll
@dummy1 = global i32 0, align 4
@dummy2 = global i32 0, align 4
@dummy3 = global i32 0, align 4
define void @foo(i64 %x1) {
foo0:
  %0 = and i64 3, %x1
  %1 = icmp eq i64 2, %0
  %2 = icmp eq i64 0, %0
  %3 = and i64 1, %x1
  %tmp0 = icmp eq i1 0, %1
  br i1 %tmp0, label %cont0, label %out
cont0:
  %tmp1 = icmp eq i1 0, %2
  br i1 %tmp1, label %cont1, label %out
cont1:
  %cand = icmp eq i64 1, %3
  br i1 %cand, label %return, label %dead
return:
  %dummy1w = atomicrmw add i32* @dummy1, i32 1 monotonic
  ret void
dead:
  %dummy2w = atomicrmw add i32* @dummy2, i32 1 monotonic
  ret void
out:
  %dummy3w = atomicrmw add i32* @dummy3, i32 1 monotonic
  ret void
}

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

From bugzilla-daemon at llvm.org  Sun Nov 23 23:26:35 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 24 Nov 2014 07:26:35 +0000
Subject: [LLVMbugs] [Bug 21651] opt crash
In-Reply-To: <bug-21651-206@http.llvm.org/bugs/>
References: <bug-21651-206@http.llvm.org/bugs/>
Message-ID: <bug-21651-206-Y2wbWsUm3o@http.llvm.org/bugs/>

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

David Majnemer <david.majnemer at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED
           Assignee|unassignedbugs at nondot.org   |david.majnemer at gmail.com

--- Comment #3 from David Majnemer <david.majnemer at gmail.com> ---
Fixed in r222645.

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

From bugzilla-daemon at llvm.org  Mon Nov 24 05:47:29 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 24 Nov 2014 13:47:29 +0000
Subject: [LLVMbugs] [Bug 21652] New: powerpc64le integrated assembler
 doesn't set correct st_other bits on destructor symbols
Message-ID: <bug-21652-206@http.llvm.org/bugs/>

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

            Bug ID: 21652
           Summary: powerpc64le integrated assembler doesn't set correct
                    st_other bits on destructor symbols
           Product: libraries
           Version: trunk
          Hardware: Other
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: PowerPC
          Assignee: unassignedbugs at nondot.org
          Reporter: jay.foad at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

When I build the address sanitizer unit tests on powerpc64le Linux, I see this
oddness in one of the object files:

$ objdump -x
projects/compiler-rt/lib/asan/tests/ASAN_NOINST_TEST_OBJECTS.gtest-all.cc.powerpc64le-inline.o
| grep " _ZN7testing8internal2RED.Ev"
0000000000000000 g     F .text._ZN7testing8internal2RED2Ev    0000000000000080
_ZN7testing8internal2RED1Ev
0000000000000000 g     F .text._ZN7testing8internal2RED2Ev    0000000000000080
0x60 _ZN7testing8internal2RED2Ev

These two symbols are at the same address, but have different st_other bits.
These st_other bits tell you how to find the function's local entry point; 0x60
means that it's two instructions past the global entry point.

If you link this .o file with ld.bfd then the difference seems harmless, but if
you link with ld.gold then you get real problems: a local call to
_ZN7testing8internal2RED1Ev turns into a bl to the *global* entry point, but
r12 isn't set up properly. The causes the resulting executable
"Asan-powerpc64le-inline-Noinst-Test" to segfault.

A workaround is to compile with -no-integrated-as. Then both symbols get the
same st_other bits:

0000000000000000 g     F .text._ZN7testing8internal2RED2Ev    0000000000000080
0x60 _ZN7testing8internal2RED2Ev
0000000000000000 g     F .text._ZN7testing8internal2RED2Ev    0000000000000080
0x60 _ZN7testing8internal2RED1Ev

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

From bugzilla-daemon at llvm.org  Mon Nov 24 06:17:55 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 24 Nov 2014 14:17:55 +0000
Subject: [LLVMbugs] [Bug 21653] New: [REGRESSION] Crash in llvm::formLCSSA
Message-ID: <bug-21653-206@http.llvm.org/bugs/>

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

            Bug ID: 21653
           Summary: [REGRESSION] Crash in llvm::formLCSSA
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: ismail at donmez.ws
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Produced with clang r222646 on Linux x86-64.

> clang -c -O2 testcase.i        
testcase.i:16:20: warning: implicit declaration of function 'av_mallocz' is
invalid in C99 [-Wimplicit-function-declaration]
    HEVCPPS *pps = av_mallocz(sizeof(*pps));
                   ^
testcase.i:16:14: warning: incompatible integer to pointer conversion
initializing 'HEVCPPS *' (aka 'struct HEVCPPS *') with an
      expression of type 'int' [-Wint-conversion]
    HEVCPPS *pps = av_mallocz(sizeof(*pps));
             ^     ~~~~~~~~~~~~~~~~~~~~~~~~
testcase.i:29:1: warning: control reaches end of non-void function
[-Wreturn-type]
}
^
#0 0x7fbe45b9c03a llvm::sys::PrintStackTrace(_IO_FILE*)
(/opt/clang/lib64/libLLVMSupport.so+0xb603a)
#1 0x7fbe45b9d4ab (/opt/clang/lib64/libLLVMSupport.so+0xb74ab)
#2 0x7fbe4410d170 __restore_rt (/lib64/libc.so.6+0x35170)
#3 0x7fbe45859e38 llvm::formLCSSA(llvm::Loop&, llvm::DominatorTree&,
llvm::ScalarEvolution*) (/opt/clang/lib64/libLLVMTransformUtils.so+0x4fe38)
#4 0x7fbe4585a2d8 llvm::formLCSSARecursively(llvm::Loop&, llvm::DominatorTree&,
llvm::ScalarEvolution*) (/opt/clang/lib64/libLLVMTransformUtils.so+0x502d8)
#5 0x7fbe4585a2be llvm::formLCSSARecursively(llvm::Loop&, llvm::DominatorTree&,
llvm::ScalarEvolution*) (/opt/clang/lib64/libLLVMTransformUtils.so+0x502be)
#6 0x7fbe4585a2be llvm::formLCSSARecursively(llvm::Loop&, llvm::DominatorTree&,
llvm::ScalarEvolution*) (/opt/clang/lib64/libLLVMTransformUtils.so+0x502be)
#7 0x7fbe4585a6f8 (/opt/clang/lib64/libLLVMTransformUtils.so+0x506f8)
#8 0x7fbe475a33b3 llvm::FPPassManager::runOnFunction(llvm::Function&)
(/opt/clang/lib64/libLLVMCore.so+0x17b3b3)
#9 0x7fbe4720a2fd (/opt/clang/lib64/libLLVMipa.so+0xf2fd)
#10 0x7fbe475a3b57 llvm::legacy::PassManagerImpl::run(llvm::Module&)
(/opt/clang/lib64/libLLVMCore.so+0x17bb57)
#11 0x7fbe3eb23063 clang::EmitBackendOutput(clang::DiagnosticsEngine&,
clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions
const&, llvm::StringRef, llvm::Module*, clang::BackendAction,
llvm::raw_ostream*) (/opt/clang/lib64/libclangCodeGen.so+0x60063)
#12 0x7fbe3ec67c4a (/opt/clang/lib64/libclangCodeGen.so+0x1a4c4a)
#13 0x7fbe3fdcd073 clang::ParseAST(clang::Sema&, bool, bool)
(/opt/clang/lib64/libclangParse.so+0x2a073)
#14 0x7fbe44c2b4de clang::FrontendAction::Execute()
(/opt/clang/lib64/libclangFrontend.so+0xa74de)
#15 0x7fbe44bfe51c
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&)
(/opt/clang/lib64/libclangFrontend.so+0x7a51c)
#16 0x7fbe449821b5 clang::ExecuteCompilerInvocation(clang::CompilerInstance*)
(/opt/clang/lib64/libclangFrontendTool.so+0x31b5)
#17 0x40f3d3 cc1_main(llvm::ArrayRef<char const*>, char const*, void*)
(/opt/clang/bin/clang-3.6+0x40f3d3)
#18 0x40da94 main (/opt/clang/bin/clang-3.6+0x40da94)
#19 0x7fbe440f9b45 __libc_start_main (/lib64/libc.so.6+0x21b45)
#20 0x40add9 _start (/opt/clang/bin/clang-3.6+0x40add9)
Stack dump:
0.      Program arguments: /opt/clang/bin/clang-3.6 -cc1 -triple
x86_64-suse-linux -emit-obj -disable-free -main-file-name testcase.i
-mrelocation-model static -mthread-model posix -fmath-errno -masm-verbose
-mconstructor-aliases -munwind-tables -fuse-init-array -target-cpu x86-64
-momit-leaf-frame-pointer -dwarf-column-info -coverage-file
/havana/t/i/delta-2006.08.03/testcase.i -resource-dir
/opt/clang/bin/../lib64/clang/3.6.0 -O2 -std=c11 -fdebug-compilation-dir
/havana/t/i/delta-2006.08.03 -ferror-limit 19 -fmessage-length 132
-mstackrealign -fobjc-runtime=gcc -fdiagnostics-show-option -fcolor-diagnostics
-vectorize-loops -vectorize-slp -o testcase.o -x cpp-output testcase.i
1.      <eof> parser at end of file
2.      Per-module optimization passes
3.      Running pass 'CallGraph Pass Manager' on module 'testcase.i'.
4.      Running pass 'Loop-Closed SSA Form Pass' on function
'@ff_hevc_decode_nal_pps'
clang-3.6: error: unable to execute command: Segmentation fault
clang-3.6: error: clang frontend command failed due to signal (use -v to see
invocation)
clang version 3.6.0 (trunk 222646)
Target: x86_64-suse-linux
Thread model: posix
clang-3.6: 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.6: note: diagnostic msg: Error generating preprocessed source(s) - no
preprocessable inputs.

> cat testcase.i
typedef struct HEVCWindow {
    unsigned int log2_min_tb_size;
    unsigned int log2_ctb_size;
    int min_tb_width;
    int min_tb_height;
} HEVCSPS;
typedef struct HEVCPPS {
    int *ctb_addr_rs_to_ts;
    int *min_tb_addr_zs;
} HEVCPPS;
int ff_hevc_decode_nal_pps()
{
    HEVCSPS      *sps = 0;
    int log2_diff_ctb_min_tb_size;
    int i, j, x, y, ctb_addr_rs, tile_id;
    HEVCPPS *pps = av_mallocz(sizeof(*pps));
    log2_diff_ctb_min_tb_size = sps->log2_ctb_size - sps->log2_min_tb_size;
    for (y = 0; y < sps->min_tb_height; y++) {
        for (x = 0; x < sps->min_tb_width; x++) {
            int val         = pps->ctb_addr_rs_to_ts[ctb_addr_rs] <<
                              (log2_diff_ctb_min_tb_size * 2);
            for (i = 0; i < log2_diff_ctb_min_tb_size; i++) {
                int m = 1 << i;
                val += (m & x ? m * m : 0) + (m & y ? 2 * m * m : 0);
            }
            pps->min_tb_addr_zs[y * sps->min_tb_width + x] = 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/20141124/417b39e6/attachment.html>

From bugzilla-daemon at llvm.org  Mon Nov 24 08:15:35 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 24 Nov 2014 16:15:35 +0000
Subject: [LLVMbugs] [Bug 21636] -no-integrated-as is broken on Mac OS X
 (Unknown pseudo-op: .macosx_version_min)
In-Reply-To: <bug-21636-206@http.llvm.org/bugs/>
References: <bug-21636-206@http.llvm.org/bugs/>
Message-ID: <bug-21636-206-PA5DyZt8oV@http.llvm.org/bugs/>

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |grosbach at apple.com,
                   |                            |rafael.espindola at gmail.com
         Resolution|---                         |WONTFIX

--- Comment #2 from Rafael Ávila de Espíndola <rafael.espindola at gmail.com> ---
The cctools assembler is not supported.

Jim suggested printing a warning from the driver if trying to use
-no-integrated on OS X, but we should not try to print assembly that the old
assembler understands.

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

From bugzilla-daemon at llvm.org  Mon Nov 24 08:41:54 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 24 Nov 2014 16:41:54 +0000
Subject: [LLVMbugs] [Bug 21653] [REGRESSION] Crash in llvm::formLCSSA
In-Reply-To: <bug-21653-206@http.llvm.org/bugs/>
References: <bug-21653-206@http.llvm.org/bugs/>
Message-ID: <bug-21653-206-FVMeX4i08c@http.llvm.org/bugs/>

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

David Majnemer <david.majnemer at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
          Component|-New Bugs                   |Scalar Optimizations
         Resolution|---                         |FIXED
           Assignee|unassignedclangbugs at nondot. |david.majnemer at gmail.com
                   |org                         |
            Product|clang                       |libraries

--- Comment #4 from David Majnemer <david.majnemer at gmail.com> ---
Fixed in r222659.

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

From bugzilla-daemon at llvm.org  Mon Nov 24 10:06:33 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 24 Nov 2014 18:06:33 +0000
Subject: [LLVMbugs] [Bug 21563] Improve Windows long path name support
In-Reply-To: <bug-21563-206@http.llvm.org/bugs/>
References: <bug-21563-206@http.llvm.org/bugs/>
Message-ID: <bug-21563-206-vVh9MQp1ux@http.llvm.org/bugs/>

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

Paul Robinson <paul_robinson at playstation.sony.com> changed:

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

--- Comment #1 from Paul Robinson <paul_robinson at playstation.sony.com> ---
Done in r222671.

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

From bugzilla-daemon at llvm.org  Mon Nov 24 10:10:22 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 24 Nov 2014 18:10:22 +0000
Subject: [LLVMbugs] [Bug 21626] clang failed to compile Objective-C++ code
 with -fmodules
In-Reply-To: <bug-21626-206@http.llvm.org/bugs/>
References: <bug-21626-206@http.llvm.org/bugs/>
Message-ID: <bug-21626-206-AJbFNj3c3h@http.llvm.org/bugs/>

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

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

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

--- Comment #7 from Richard Smith <richard-llvm at metafoo.co.uk> ---
Bugzilla is not a good forum for providing assistance with an issue like this;
please start a thread on cfe-dev at cs.uiuc.edu

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

From bugzilla-daemon at llvm.org  Mon Nov 24 10:10:41 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 24 Nov 2014 18:10:41 +0000
Subject: [LLVMbugs] [Bug 21652] powerpc64le integrated assembler doesn't set
 correct st_other bits on destructor symbols
In-Reply-To: <bug-21652-206@http.llvm.org/bugs/>
References: <bug-21652-206@http.llvm.org/bugs/>
Message-ID: <bug-21652-206-6nbsS09mWn@http.llvm.org/bugs/>

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

Ulrich Weigand <uweigand at de.ibm.com> changed:

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

--- Comment #4 from Ulrich Weigand <uweigand at de.ibm.com> ---
Fixed in rev. 222672.

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

From bugzilla-daemon at llvm.org  Mon Nov 24 10:58:47 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 24 Nov 2014 18:58:47 +0000
Subject: [LLVMbugs] [Bug 21637] [AArch64] A57LoadBalancing rewrites
 registers and introduces miscompile
In-Reply-To: <bug-21637-206@http.llvm.org/bugs/>
References: <bug-21637-206@http.llvm.org/bugs/>
Message-ID: <bug-21637-206-OtazvlfK26@http.llvm.org/bugs/>

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

Chad Rosier <mcrosier at codeaurora.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED
           Assignee|james.molloy at arm.com        |mcrosier at codeaurora.org

--- Comment #4 from Chad Rosier <mcrosier at codeaurora.org> ---
Committed r222677.

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

From bugzilla-daemon at llvm.org  Mon Nov 24 12:49:38 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 24 Nov 2014 20:49:38 +0000
Subject: [LLVMbugs] [Bug 21655] New: [mach-o] Symbol offset not relevant in
 out-of-order nlists
Message-ID: <bug-21655-206@http.llvm.org/bugs/>

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

            Bug ID: 21655
           Summary: [mach-o] Symbol offset not relevant in out-of-order
                    nlists
           Product: lld
           Version: unspecified
          Hardware: PC
                OS: All
            Status: NEW
          Severity: release blocker
          Priority: P
         Component: All Bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: dmlamb at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

In MachONormalizedFileBinaryReader.cpp at around ln432, the symtab nlists are
incorrectly assumed to be in-order from local to global to undefined. As a
result, relocations in MachONormalizedFileToAtoms.cpp at ln538 are improperly
assigned. The symbol index corresponds to whatever order the nlist is in, thus
all symbols should be parsed to the same array, rather than three disparate
ones. 

Symptoms shown are cstrings and other data relocations appear to work if viewed
in a Mach-o reader, they will just point to the wrong entry in that nlist. Keep
in mind for repro that it's entirely possible the nlist is in the right order,
given a small symtab.

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

From bugzilla-daemon at llvm.org  Mon Nov 24 12:53:06 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 24 Nov 2014 20:53:06 +0000
Subject: [LLVMbugs] [Bug 21604] crash after "error in backend: Broken
	function found"
In-Reply-To: <bug-21604-206@http.llvm.org/bugs/>
References: <bug-21604-206@http.llvm.org/bugs/>
Message-ID: <bug-21604-206-8tHAm6I6xn@http.llvm.org/bugs/>

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

Paul Robinson <paul_robinson at playstation.sony.com> changed:

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

--- Comment #4 from Paul Robinson <paul_robinson at playstation.sony.com> ---
Should be fixed in r222683.

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

From bugzilla-daemon at llvm.org  Mon Nov 24 12:55:33 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 24 Nov 2014 20:55:33 +0000
Subject: [LLVMbugs] [Bug 21656] New: Incorrect error on undeclared variable
	use
Message-ID: <bug-21656-206@http.llvm.org/bugs/>

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

            Bug ID: 21656
           Summary: Incorrect error on undeclared variable use
           Product: clang
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
          Assignee: unassignedclangbugs at nondot.org
          Reporter: Matthew.Arsenault at amd.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Using r222680

int main(int argc, char *argv[])
{
    float x = 1.0f;
    x = (float) arst;
}


This produces the unhelpful error:
error: operand of type '<dependent type>' where arithmetic or pointer type is
required
1 error generated.

which doesn't even include a line number.

clang 3.4 produces the correct error:
clang_warning_bug.c:5:17: error: use of undeclared identifier 'arst'
    x = (float) arst;
                ^
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/20141124/18df6eb0/attachment.html>

From bugzilla-daemon at llvm.org  Mon Nov 24 13:51:16 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 24 Nov 2014 21:51:16 +0000
Subject: [LLVMbugs] [Bug 21656] Incorrect error on undeclared variable use
In-Reply-To: <bug-21656-206@http.llvm.org/bugs/>
References: <bug-21656-206@http.llvm.org/bugs/>
Message-ID: <bug-21656-206-s586CXdtT4@http.llvm.org/bugs/>

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

Kaelyn Takata <rikka at google.com> changed:

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

--- Comment #2 from Kaelyn Takata <rikka at google.com> ---
Indeed it was fallout in the form of a code path not covered by any of the
regression tests where a type-dependent TypoExpr node would be seen by a
non-C++ code path that tried to check the expression's type and failed. I've
fixed this case and added a test in r222694.

As an aside, the assertion in ~Sema from r222552 would have been triggered if
asserts were enable, highlighting the fact that a typo had been encountered but
never corrected (i.e. a TypoExpr was created but never diagnosed) and providing
a better indication of what went wrong than the generated error message had. ;)

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

From bugzilla-daemon at llvm.org  Mon Nov 24 14:34:47 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 24 Nov 2014 22:34:47 +0000
Subject: [LLVMbugs] [Bug 21660] New: [mach-o] Relocations don't use
	offsetInTo
Message-ID: <bug-21660-206@http.llvm.org/bugs/>

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

            Bug ID: 21660
           Summary: [mach-o] Relocations don't use offsetInTo
           Product: lld
           Version: unspecified
          Hardware: PC
                OS: All
            Status: NEW
          Severity: release blocker
          Priority: P
         Component: All Bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: dmlamb at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Function et al relocations don't point to the correct address as they appear to
point to the atom's start address. See ArchHandler_arm.cpp ln850 for example.
toAddress seems to point to the Atom's address. offsetInTo should be added to
the addend.

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

From bugzilla-daemon at llvm.org  Mon Nov 24 15:15:56 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 24 Nov 2014 23:15:56 +0000
Subject: [LLVMbugs] [Bug 21610] Different IR if intermediate variable used
 for fcmp + select
In-Reply-To: <bug-21610-206@http.llvm.org/bugs/>
References: <bug-21610-206@http.llvm.org/bugs/>
Message-ID: <bug-21610-206-kjdotV400x@http.llvm.org/bugs/>

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

Matt Arsenault <Matthew.Arsenault at amd.com> changed:

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

--- Comment #2 from Matt Arsenault <Matthew.Arsenault at amd.com> ---
r222705 canonicalizes fcmp + select to use ordered compares

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

From bugzilla-daemon at llvm.org  Mon Nov 24 16:00:44 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 25 Nov 2014 00:00:44 +0000
Subject: [LLVMbugs] [Bug 21661] New: Clang crashes on valid(?) explicit
	instantiation
Message-ID: <bug-21661-206@http.llvm.org/bugs/>

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

            Bug ID: 21661
           Summary: Clang crashes on valid(?) explicit instantiation
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
          Assignee: unassignedclangbugs at nondot.org
          Reporter: zilla at kayari.org
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified

template<typename T>
struct S
{
  void foo(int) { }
  template<typename U> void foo(U) { }
};

template void S<char>::foo(int);  // XXX

I'm trying to instantiate the non-template, but it crashes clang++, backtrace
below.

I'm not sure if this is actually valid, because I don't see anything in
[temp.explicit] that says how the compiler should determine I mean the
non-template member function of the class template, rather than the member
function template.  G++ says it's ambiguous, but I've reported that as a bug.
EDG compiles the code, but instantiates the member function template, which is
not what I was trying to do.


clang:
/home/jwakely/src/llvm/llvm/tools/clang/lib/Sema/SemaTemplateDeduction.cpp:4488:
clang::UnresolvedSetIterator
clang::Sema::getMostSpecialized(clang::UnresolvedSetIterator,
clang::UnresolvedSetIterator, clang::TemplateSpecCandidateSet &,
clang::SourceLocation, const clang::PartialDiagnostic &, const
clang::PartialDiagnostic &, const clang::PartialDiagnostic &, bool,
clang::QualType): Assertion `BestTemplate && "Not a function template
specialization?"' failed.
0  clang           0x000000000232b738 llvm::sys::PrintStackTrace(_IO_FILE*) +
40
1  clang           0x000000000232ccbb
2  libpthread.so.0 0x000000394a00f6d0
3  libc.so.6       0x0000003949835877 gsignal + 55
4  libc.so.6       0x0000003949836f68 abort + 328
5  libc.so.6       0x000000394982e7d6
6  libc.so.6       0x000000394982e882
7  clang           0x0000000000f2267d
8  clang           0x0000000000edd44b
clang::Sema::ActOnExplicitInstantiation(clang::Scope*, clang::SourceLocation,
clang::SourceLocation, clang::Declarator&) + 5307
9  clang           0x0000000000aa6970
clang::Parser::ParseDeclarationAfterDeclaratorAndAttributes(clang::Declarator&,
clang::Parser::ParsedTemplateInfo const&, clang::Parser::ForRangeInit*) + 144
10 clang           0x0000000000b184df
clang::Parser::ParseSingleDeclarationAfterTemplate(unsigned int,
clang::Parser::ParsedTemplateInfo const&, clang::ParsingDeclRAIIObject&,
clang::SourceLocation&, clang::AccessSpecifier, clang::AttributeList*) + 3471
11 clang           0x0000000000b16fa4
clang::Parser::ParseExplicitInstantiation(unsigned int, clang::SourceLocation,
clang::SourceLocation, clang::SourceLocation&, clang::AccessSpecifier) + 148
12 clang           0x0000000000b16e68
clang::Parser::ParseDeclarationStartingWithTemplate(unsigned int,
clang::SourceLocation&, clang::AccessSpecifier, clang::AttributeList*) + 376
13 clang           0x0000000000aa0d6f clang::Parser::ParseDeclaration(unsigned
int, clang::SourceLocation&, clang::Parser::ParsedAttributesWithRange&) + 815
14 clang           0x0000000000a91532
clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&,
clang::ParsingDeclSpec*) + 1634
15 clang           0x0000000000a90d9d
clang::Parser::ParseTopLevelDecl(clang::OpaquePtr<clang::DeclGroupRef>&) + 477
16 clang           0x0000000000a8ca86 clang::ParseAST(clang::Sema&, bool, bool)
+ 406
17 clang           0x000000000088f1bc clang::CodeGenAction::ExecuteAction() +
204
18 clang           0x00000000006a1a9e clang::FrontendAction::Execute() + 62
19 clang           0x00000000006746bc
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 892
20 clang           0x000000000065794a
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 3050
21 clang           0x000000000064e73e cc1_main(llvm::ArrayRef<char const*>,
char const*, void*) + 526
22 clang           0x0000000000656053 main + 12275
23 libc.so.6       0x0000003949821d65 __libc_start_main + 245
24 clang           0x000000000064e469
Stack dump:
0.      Program arguments: /home/jwakely/src/llvm/3.x/bin/clang -cc1 -triple
x86_64-unknown-linux-gnu -emit-obj -mrelax-all -disable-free -main-file-name
inst.cc -mrelocation-model static -mthread-model posix -mdisable-fp-elim
-fmath-errno -masm-verbose -mconstructor-aliases -munwind-tables
-fuse-init-array -target-cpu x86-64 -target-linker-version 2.24
-dwarf-column-info -resource-dir
/home/jwakely/src/llvm/3.x/bin/../lib/clang/3.6.0 -internal-isystem
/usr/lib/gcc/x86_64-redhat-linux/4.8.3/../../../../include/c++/4.8.3
-internal-isystem
/usr/lib/gcc/x86_64-redhat-linux/4.8.3/../../../../include/c++/4.8.3/x86_64-redhat-linux
-internal-isystem
/usr/lib/gcc/x86_64-redhat-linux/4.8.3/../../../../include/c++/4.8.3/backward
-internal-isystem /usr/local/include -internal-isystem
/home/jwakely/src/llvm/3.x/bin/../lib/clang/3.6.0/include
-internal-externc-isystem /include -internal-externc-isystem /usr/include
-fdeprecated-macro -fdebug-compilation-dir /tmp -ferror-limit 19
-fmessage-length 237 -mstackrealign -fobjc-runtime=gcc -fcxx-exceptions
-fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o
/tmp/inst-e7a824.o -x c++ inst.cc 
1.      inst.cc:8:32: 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.6.0 (trunk 222677)
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/20141125/24f59fab/attachment.html>

From bugzilla-daemon at llvm.org  Mon Nov 24 17:31:20 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 25 Nov 2014 01:31:20 +0000
Subject: [LLVMbugs] [Bug 21661] Clang crashes on valid(?) explicit
	instantiation
In-Reply-To: <bug-21661-206@http.llvm.org/bugs/>
References: <bug-21661-206@http.llvm.org/bugs/>
Message-ID: <bug-21661-206-F8qUfXF3AN@http.llvm.org/bugs/>

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

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> ---
The handling of this case is core issue 1665; IIRC the resolution will be that
we should prefer the non-template in this case (the current core wording would
prefer the template). You can instead instantiate the template by using
'template void S<char>::foo<>(int);', in exactly the same way that a call to
foo(0) would pick the non-template and a call to foo<>(0) would pick the
template).

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

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

From bugzilla-daemon at llvm.org  Tue Nov 25 01:01:10 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 25 Nov 2014 09:01:10 +0000
Subject: [LLVMbugs] [Bug 21420] Master Android tracking bug for official
 clang platform support
In-Reply-To: <bug-21420-206@http.llvm.org/bugs/>
References: <bug-21420-206@http.llvm.org/bugs/>
Message-ID: <bug-21420-206-Nl3piyEqIr@http.llvm.org/bugs/>

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

Bug 21420 depends on bug 17391, which changed state.

Bug 17391 Summary: Clang does not define __ARM_FEATURE_DSP for compatible devices
http://llvm.org/bugs/show_bug.cgi?id=17391

           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/20141125/70cab57b/attachment.html>

From bugzilla-daemon at llvm.org  Tue Nov 25 01:01:09 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 25 Nov 2014 09:01:09 +0000
Subject: [LLVMbugs] [Bug 17391] Clang does not define __ARM_FEATURE_DSP for
 compatible devices
In-Reply-To: <bug-17391-206@http.llvm.org/bugs/>
References: <bug-17391-206@http.llvm.org/bugs/>
Message-ID: <bug-17391-206-DOHrOAaWpf@http.llvm.org/bugs/>

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

Sergey Dmitrouk <sdmitrouk at accesssoftek.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |sdmitrouk at accesssoftek.com
         Resolution|---                         |FIXED
           Assignee|unassignedclangbugs at nondot. |sdmitrouk at accesssoftek.com
                   |org                         |

--- Comment #1 from Sergey Dmitrouk <sdmitrouk at accesssoftek.com> ---
Fixed in r222741.

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

From bugzilla-daemon at llvm.org  Tue Nov 25 01:26:10 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 25 Nov 2014 09:26:10 +0000
Subject: [LLVMbugs] [Bug 21330] clang-cl miscompiles insertion of struct
 value into std::map
In-Reply-To: <bug-21330-206@http.llvm.org/bugs/>
References: <bug-21330-206@http.llvm.org/bugs/>
Message-ID: <bug-21330-206-T5fdHvwWmB@http.llvm.org/bugs/>

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

Chandler Carruth <chandlerc at gmail.com> changed:

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

--- Comment #7 from Chandler Carruth <chandlerc at gmail.com> ---
Re-landed the offending patch with fixes (and crazy more reduced test cases) in
r222742. Thanks for the reduction and revert!

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

From bugzilla-daemon at llvm.org  Tue Nov 25 01:41:03 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 25 Nov 2014 09:41:03 +0000
Subject: [LLVMbugs] [Bug 21384] Can't build compiler-rt as part of llvm
In-Reply-To: <bug-21384-206@http.llvm.org/bugs/>
References: <bug-21384-206@http.llvm.org/bugs/>
Message-ID: <bug-21384-206-zpwRQboqgL@http.llvm.org/bugs/>

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

Heinz Wiesinger <pprkut at slackware.com> changed:

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

--- Comment #1 from Heinz Wiesinger <pprkut at slackware.com> ---
Ok, so the problem here was with llvm's build system not supporting libdir
properly. clang is configured to look for its resources in ../lib64 but llvm
temporarily puts it into ../lib within the build tree before we run make
install. This leads to clang not finding the resource dir when run from within
the build tree, but it works fine once installed. Patching the build system to
install things in 'Release/lib64' instead of 'Release/lib' fixed this issue for
me.

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

From bugzilla-daemon at llvm.org  Tue Nov 25 01:57:53 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 25 Nov 2014 09:57:53 +0000
Subject: [LLVMbugs] [Bug 21664] New: Crash while capture template
 std::function in lambdas
Message-ID: <bug-21664-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=21664

            Bug ID: 21664
           Summary: Crash while capture template std::function in lambdas
           Product: clang
           Version: 3.4
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++11
          Assignee: unassignedclangbugs at nondot.org
          Reporter: kamil.rojewski at gmail.com
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified

When trying to capture a template std::function alias in a lambda by value, I
am experiencing a crash in the resulting binary. Here is a code snippet showing
this error:

#include <functional>

template<class T>
using Callback = std::function<void (T)>;

std::function<void ()> f(const Callback<int> &callback)
{
    return [=] {
        callback(0); // crash here
    };
}

int main()
{
    auto lambda = f([](int) { });
    lambda();
    return 0;
}

This also happens when explicitly capturing "callback". To work around the
crash, the variable needs to be captured using generalized capture:

#include <functional>

template<class T>
using Callback = std::function<void (T)>;

std::function<void ()> f(const Callback<int> &callback)
{
    return [=, callback = callback] {
        callback(0);                   // no crash now
    };
}

int main()
{
    auto lambda = f([](int) { });
    lambda();
    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/20141125/ea1b5d45/attachment.html>

From bugzilla-daemon at llvm.org  Tue Nov 25 10:36:15 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 25 Nov 2014 18:36:15 +0000
Subject: [LLVMbugs] [Bug 21238] Insufficient Lazy Value Info calculation
 loses jump threading opportunity
In-Reply-To: <bug-21238-206@http.llvm.org/bugs/>
References: <bug-21238-206@http.llvm.org/bugs/>
Message-ID: <bug-21238-206-GgO4Jm7jOf@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=21238

Hans Wennborg <hans at chromium.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |hans at chromium.org
         Resolution|---                         |FIXED

--- Comment #1 from Hans Wennborg <hans at chromium.org> ---
Fixed in r222768.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20141125/d1d74776/attachment.html>

From bugzilla-daemon at llvm.org  Tue Nov 25 11:03:10 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 25 Nov 2014 19:03:10 +0000
Subject: [LLVMbugs] [Bug 21668] New: -Wpointer-bool-conversion doesn't work
 when the attribute is on the parameter decl
Message-ID: <bug-21668-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=21668

            Bug ID: 21668
           Summary: -Wpointer-bool-conversion doesn't work when the
                    attribute is on the parameter decl
           Product: clang
           Version: unspecified
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
          Assignee: rtrieu at google.com
          Reporter: rnk at google.com
                CC: llvmbugs at cs.uiuc.edu, richard-llvm at metafoo.co.uk
    Classification: Unclassified

Consider:
__attribute__((nonnull(1))) int f(const char *p) {
  if (p) // warns
    return 1;
  return 0;
}

int g(__attribute__((nonnull)) const char *p) {
  if (p) // does not warn!
    return 1;
  return 0;
}

The test in test/CodeGen/nonnull.c suggests that this should work, but
apparently it does 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/20141125/4370156a/attachment.html>

From bugzilla-daemon at llvm.org  Tue Nov 25 11:33:42 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 25 Nov 2014 19:33:42 +0000
Subject: [LLVMbugs] [Bug 21649] Please support https!
In-Reply-To: <bug-21649-206@http.llvm.org/bugs/>
References: <bug-21649-206@http.llvm.org/bugs/>
Message-ID: <bug-21649-206-EAAMFA1XEK@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=21649

Reid Kleckner <rnk at google.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |DUPLICATE

--- Comment #1 from Reid Kleckner <rnk at google.com> ---
This is a symptom of a more general lack of https services. I agree, most of
them should be served securely.

*** This bug has been marked as a duplicate of bug 15653 ***

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20141125/db45bef2/attachment.html>

From bugzilla-daemon at llvm.org  Tue Nov 25 12:23:45 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 25 Nov 2014 20:23:45 +0000
Subject: [LLVMbugs] [Bug 21669] New: undeclared identifier used in
 atomic_load crashes clang
Message-ID: <bug-21669-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=21669

            Bug ID: 21669
           Summary: undeclared identifier used in atomic_load crashes
                    clang
           Product: clang
           Version: unspecified
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
          Assignee: unassignedclangbugs at nondot.org
          Reporter: david.majnemer at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

void f(int *i) {
  __atomic_load(i, i, something_something);
}

we think we have a dependent expression and die in
clang::Expr::isIntegerConstantExpr

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20141125/2cfaebae/attachment.html>

From bugzilla-daemon at llvm.org  Tue Nov 25 13:25:46 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 25 Nov 2014 21:25:46 +0000
Subject: [LLVMbugs] [Bug 21671] New: backend crash with large structure
	variables
Message-ID: <bug-21671-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=21671

            Bug ID: 21671
           Summary: backend crash with large structure variables
           Product: clang
           Version: 3.5
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: LLVM Codegen
          Assignee: unassignedclangbugs at nondot.org
          Reporter: Dale.Martin at mathworks.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 13395
  --> http://llvm.org/bugs/attachment.cgi?id=13395&action=edit
An example that crashes when process with llc

The X86 backend crashes when compiling the attached example that has load/store
of large structures "alloca"ed on the stack. It looks like a merge_values
instruction with more than 16k children gets generated, despite the fact that
the number is stored in an unsigned short.

Note that if you slight reduce the number of nested fields, the example will
generate code it takes many minutes and generates thousands of discrete movb
instructions.

The workaround is to directly call memcpy instead of using load/store but this
seems like it is intended to work as is and that an optimization should be
responsible for generating the memcpy and that it should not have to come from
a front-end 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/20141125/05e96f46/attachment.html>

From bugzilla-daemon at llvm.org  Tue Nov 25 13:36:06 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 25 Nov 2014 21:36:06 +0000
Subject: [LLVMbugs] [Bug 17898] const qualifier accepted on ctor
	declaration/definition
In-Reply-To: <bug-17898-206@http.llvm.org/bugs/>
References: <bug-17898-206@http.llvm.org/bugs/>
Message-ID: <bug-17898-206-6dkgvcgM7U@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=17898

Nathan Sidwell <nathan at acm.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |nathan at acm.org
         Resolution|---                         |FIXED

--- Comment #2 from Nathan Sidwell <nathan at acm.org> ---
This appears resolved:
17898.cc:4:3: error: constructor cannot have a return type
  const X() { i=0; }
  ^~~~~~

A similar error is emitted for volatile

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20141125/7750fcde/attachment.html>

From bugzilla-daemon at llvm.org  Tue Nov 25 14:20:26 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 25 Nov 2014 22:20:26 +0000
Subject: [LLVMbugs] [Bug 21579] Memory Sanitizer causes wide string test
 failures in libc++
In-Reply-To: <bug-21579-206@http.llvm.org/bugs/>
References: <bug-21579-206@http.llvm.org/bugs/>
Message-ID: <bug-21579-206-YPZ3d6rQ2o@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=21579

Eric Fiselier <eric at efcs.ca> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #3 from Eric Fiselier <eric at efcs.ca> ---
Fixed in r222673.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20141125/2b8f767e/attachment.html>

From bugzilla-daemon at llvm.org  Tue Nov 25 15:04:25 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 25 Nov 2014 23:04:25 +0000
Subject: [LLVMbugs] [Bug 21669] undeclared identifier used in atomic_load
	crashes clang
In-Reply-To: <bug-21669-206@http.llvm.org/bugs/>
References: <bug-21669-206@http.llvm.org/bugs/>
Message-ID: <bug-21669-206-xIdmXMGAgd@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=21669

Kaelyn Takata <rikka at google.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #2 from Kaelyn Takata <rikka at google.com> ---
Yes this is related to the delayed typo correction work, and affects both C++
and non-C++ code. Specifically, Sema::BuildResolvedCallExpr will "bail out
early if calling a builtin with custom typechecking", skipping the normal code
path wherein the TypoExpr would have been handled. Fixed in r222797.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20141125/813aa5ea/attachment.html>

From bugzilla-daemon at llvm.org  Tue Nov 25 17:25:37 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 26 Nov 2014 01:25:37 +0000
Subject: [LLVMbugs] [Bug 21672] New: r220138 caused binary size increase in
	Chromium
Message-ID: <bug-21672-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=21672

            Bug ID: 21672
           Summary: r220138 caused binary size increase in Chromium
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Scalar Optimizations
          Assignee: unassignedbugs at nondot.org
          Reporter: hans at chromium.org
                CC: chandlerc at gmail.com, llvmbugs at cs.uiuc.edu,
                    nicolasweber at gmx.de
    Classification: Unclassified

Created attachment 13397
  --> http://llvm.org/bugs/attachment.cgi?id=13397&action=edit
Preprocessed source

(Moving this from the list:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20141124/246194.html)

r220138 caused a 97 KB binary size increase in Chromium on 64-bit Linux.

Attaching preprocessed source for one TU that was significantly affected.

Build command:

 clang++ -fstack-protector --param=ssp-buffer-size=4 -fno-strict-aliasing
-fvisibility=hidden -fPIC -pthread -m64 -march=x86-64 -O2 -fno-ident
-fdata-sections -ffunction-sections -funwind-tables -fno-exceptions -fno-rtti
-fno-threadsafe-statics -fvisibility-inlines-hidden -w -std=gnu++11 -c
/tmp/ash.resize_shadow_controller.ii -o a.o

Sizes before and after your change, and at ToT:

   text    data     bss     dec     hex filename
   2626     184       0    2810     afa /tmp/220137.o
   2853     184       0    3037     bdd /tmp/220138.o
   2853     184       0    3037     bdd /tmp/222768.o


Looking at the IR diff for one of the functions that's grown (46 bytes), it's
not obvious what's going on besides some bitcasts and loads being reordered.
Looking at the asm however, it seems the loop is laid out a bit different. I'm
not sure what would cause 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/20141126/43cdf10a/attachment.html>

From bugzilla-daemon at llvm.org  Wed Nov 26 02:26:00 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 26 Nov 2014 10:26:00 +0000
Subject: [LLVMbugs] [Bug 21673] New: OpenCL vector ternary selection
 triggers internal error (invalid LLVM IR?)
Message-ID: <bug-21673-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=21673

            Bug ID: 21673
           Summary: OpenCL vector ternary selection triggers internal
                    error (invalid LLVM IR?)
           Product: clang
           Version: 3.5
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
          Assignee: unassignedclangbugs at nondot.org
          Reporter: bruno-llvm at defraine.net
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 13399
  --> http://llvm.org/bugs/attachment.cgi?id=13399&action=edit
test.cl

Hello,

The attached simple OpenCL file triggers a compiler internal error (using O2
for target x86_64):

$ clang -O2 -c llvm.cl
0  libLLVM-3.5.so  0x00002b1eddf6bae2 llvm::sys::PrintStackTrace(_IO_FILE*) +
34
1  libLLVM-3.5.so  0x00002b1eddf6b619
2  libpthread.so.0 0x00002b1edfb94b70
3  libLLVM-3.5.so  0x00002b1ede55249c llvm::SelectionDAG::getNode(unsigned int,
llvm::SDLoc, llvm::EVT, llvm::SDValue, llvm::SDValue, bool, bool, bool) + 172
4  libLLVM-3.5.so  0x00002b1ede4ea247
5  libLLVM-3.5.so  0x00002b1ede4ee4a8
6  libLLVM-3.5.so  0x00002b1ede4f5a84
7  libLLVM-3.5.so  0x00002b1ede4f63ea llvm::SelectionDAG::LegalizeTypes() + 922
8  libLLVM-3.5.so  0x00002b1ede5aa683
llvm::SelectionDAGISel::CodeGenAndEmitDAG() + 211
9  libLLVM-3.5.so  0x00002b1ede5b0dfa
llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) + 1018
10 libLLVM-3.5.so  0x00002b1ede5b247a
llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) + 586
11 libLLVM-3.5.so  0x00002b1ede35be00
12 libLLVM-3.5.so  0x00002b1edded46df
llvm::FPPassManager::runOnFunction(llvm::Function&) + 607
13 libLLVM-3.5.so  0x00002b1edded471b
llvm::FPPassManager::runOnModule(llvm::Module&) + 43
14 libLLVM-3.5.so  0x00002b1edded4357
llvm::legacy::PassManagerImpl::run(llvm::Module&) + 759
15 clang           0x000000000073ef26
clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::CodeGenOptions
const&, clang::TargetOptions const&, clang::LangOptions const&,
llvm::StringRef, llvm::Module*, clang::BackendAction, llvm::raw_ostream*) +
3110
16 clang           0x0000000000739761
17 clang           0x00000000008ce9da clang::ParseAST(clang::Sema&, bool, bool)
+ 522
18 clang           0x00000000005af38e clang::FrontendAction::Execute() + 142
19 clang           0x000000000058cb15
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 245
20 clang           0x000000000057549d
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1917
21 clang           0x000000000056d398 cc1_main(char const**, char const**, char
const*, void*) + 1208
22 clang           0x0000000000574187 main + 8455
23 libc.so.6       0x00002b1ee0bca994 __libc_start_main + 244
24 clang           0x000000000056c299
Stack dump:
0.      Program arguments:
/slowfs/de02asip01/sgasip/ipd/install/RedHatEnterpriseClient-5.7/llvm/bin/clang
-cc1 -triple x86_64-unknown-linux-gnu -S -disable-free -disable-llvm-verifier
-main-file-name llvm.cl -mrelocation-model static -fmath-errno -masm-verbose
-mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version
2.17.50.0.6 -momit-leaf-frame-pointer -dwarf-column-info -coverage-file
/slowfs/de02asip01/brunodf/llvm.s -resource-dir
/slowfs/de02asip01/sgasip/ipd/install/RedHatEnterpriseClient-5.7/llvm/bin/../lib/clang/3.5.0
-internal-isystem /usr/local/include -internal-isystem
/slowfs/de02asip01/sgasip/ipd/install/RedHatEnterpriseClient-5.7/llvm/bin/../lib/clang/3.5.0/include
-internal-externc-isystem /include -internal-externc-isystem /usr/include -O2
-fdebug-compilation-dir /slowfs/de02asip01/brunodf -ferror-limit 19
-fmessage-length 144 -mstackrealign -fobjc-runtime=gcc
-fdiagnostics-show-option -fcolor-diagnostics -vectorize-loops -vectorize-slp
-o llvm.s -x cl llvm.cl 
1.      <eof> parser at end of file
2.      Code generation
3.      Running pass 'Function Pass Manager' on module 'llvm.cl'.
4.      Running pass 'X86 DAG->DAG Instruction Selection' on function '@foo'
clang: error: unable to execute command: Segmentation fault
clang: error: clang frontend command failed due to signal (use -v to see
invocation)
clang version 3.5.0 (tags/RELEASE_350/final)
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/llvm-48d3d9.cl
clang: note: diagnostic msg: /tmp/llvm-48d3d9.sh
clang: note: diagnostic msg: 

********************

This is the generated LLVM IR:

; ModuleID = 'llvm.cl'
target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"

; Function Attrs: nounwind readnone uwtable
define <4 x i32> @foo(double %a.coerce, <4 x i32> %b, <4 x i32> %c) #0 {
  %1 = bitcast double %a.coerce to <4 x i16>
  %.lobit = ashr <4 x i16> %1, <i16 15, i16 15, i16 15, i16 15>
  %2 = xor <4 x i16> %.lobit, <i16 -1, i16 -1, i16 -1, i16 -1>
  %3 = and <4 x i32> %c, <4 x i16> %2
  %4 = and <4 x i16> %.lobit, <4 x i32> %b
  %5 = or <4 x i32> %3, %4
  ret <4 x i32> %5
}

attributes #0 = { nounwind readnone uwtable "less-precise-fpmad"="false"
"no-frame-pointer-elim"="false" "no-infs-fp-math"="false"
"no-nans-fp-math"="false" "stack-protector-buffer-size"="8"
"unsafe-fp-math"="false" "use-soft-float"="false" }

!llvm.ident = !{!0}

!0 = metadata !{metadata !"clang version 3.5.0 (tags/RELEASE_350/final)"}


The operation "and <4 x i16> %.lobit, <4 x i32> %b" does not look correct
(different argument types).

Note: this may be illegal code that can be rejected:
- The OpenCL specification, section 6.3.i on the ternary selection operator
"exp1 ? exp2 : exp3" states "If the result [of evaluating exp1] is a vector
value, then this is equivalent to calling select(exp3, exp2, exp1)".
- In table 6.14, for "gentype select (gentype a, gentype b, igentype c)" it is
stated that "igentype [and ugentype] must have the same number of elements and
bits as gentype".
- In this example, "igentype" (short4) and "gentype" (int4) have the same
number of elements, but a different number of bits.
- While the requirement of the same number of elements is essential for the
semantics of "select", the requirement of the same number of bits is not
strictly needed, the semantics of "select" is clear.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20141126/9780e608/attachment.html>

From bugzilla-daemon at llvm.org  Wed Nov 26 07:33:08 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 26 Nov 2014 15:33:08 +0000
Subject: [LLVMbugs] [Bug 21674] New: Stand-alone compilation fails,
 due to std=c++11 flag missing.
Message-ID: <bug-21674-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=21674

            Bug ID: 21674
           Summary: Stand-alone compilation fails, due to std=c++11 flag
                    missing.
           Product: libc++abi
           Version: 3.4
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: All Bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: hannes_weisbach at gmx.net
                CC: llvmbugs at cs.uiuc.edu, mclow.lists at gmail.com
    Classification: Unclassified

I tried to do a "stand alone" compilation of libcxxabi according to
http://libcxxabi.llvm.org:

svn co http://llvm.org/svn/llvm-project/libcxxabi/trunk libcxxabi (rev 222832)
mkdir build
cd build
cmake -DLIBCXXABI_LIBCXX_INCLUDES=path/to/libcxx/include ..
DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++
-- The C compiler identification is Clang 3.5.0
-- The CXX compiler identification is Clang 3.5.0
[...]

make
Scanning dependencies of target cxxabi
[  5%] Building CXX object src/CMakeFiles/cxxabi.dir/abort_message.cpp.o
[ 11%] Building CXX object src/CMakeFiles/cxxabi.dir/cxa_aux_runtime.cpp.o
[ 17%] Building CXX object src/CMakeFiles/cxxabi.dir/cxa_default_handlers.cpp.o
In file included from
/home/hannesweisbach/libcxxabi/src/cxa_default_handlers.cpp:19:
In file included from /home/hannesweisbach/libcxxabi/src/cxa_exception.hpp:19:
/home/hannesweisbach/libcxxabi/include/unwind.h:44:27: warning: commas at the
end of enumerator lists are a C++11 extension [-Wc++11-extensions]
  _URC_CONTINUE_UNWIND = 8,
                          ^
1 warning generated.
[ 23%] Building CXX object src/CMakeFiles/cxxabi.dir/cxa_demangle.cpp.o
/home/hannesweisbach/libcxxabi/src/cxa_demangle.cpp:10:33: warning: variadic
macros are a C99 feature [-Wvariadic-macros]
#define _LIBCPP_EXTERN_TEMPLATE(...)
                                ^
/home/hannesweisbach/libcxxabi/src/cxa_demangle.cpp:60:10: warning: 'auto' type
specifier is a C++11 extension [-Wc++11-extensions]
    for (auto& s : db.names)
         ^
/home/hannesweisbach/libcxxabi/src/cxa_demangle.cpp:60:18: warning: range-based
for loop is a C++11 extension [-Wc++11-extensions]
    for (auto& s : db.names)
                 ^
/home/hannesweisbach/libcxxabi/src/cxa_demangle.cpp:64:10: warning: 'auto' type
specifier is a C++11 extension [-Wc++11-extensions]
    for (auto& v : db.subs)
         ^
/home/hannesweisbach/libcxxabi/src/cxa_demangle.cpp:64:18: warning: range-based
for loop is a C++11 extension [-Wc++11-extensions]
    for (auto& v : db.subs)
                 ^
/home/hannesweisbach/libcxxabi/src/cxa_demangle.cpp:70:14: warning: 'auto' type
specifier is a C++11 extension [-Wc++11-extensions]
        for (auto& s : v)
             ^
/home/hannesweisbach/libcxxabi/src/cxa_demangle.cpp:70:22: warning: range-based
for loop is a C++11 extension [-Wc++11-extensions]
        for (auto& s : v)
                     ^
/home/hannesweisbach/libcxxabi/src/cxa_demangle.cpp:76:10: warning: 'auto' type
specifier is a C++11 extension [-Wc++11-extensions]
    for (auto& t : db.template_param)
         ^
/home/hannesweisbach/libcxxabi/src/cxa_demangle.cpp:76:18: warning: range-based
for loop is a C++11 extension [-Wc++11-extensions]
    for (auto& t : db.template_param)
                 ^
/home/hannesweisbach/libcxxabi/src/cxa_demangle.cpp:80:14: warning: 'auto' type
specifier is a C++11 extension [-Wc++11-extensions]
        for (auto& v : t)
             ^
/home/hannesweisbach/libcxxabi/src/cxa_demangle.cpp:80:22: warning: range-based
for loop is a C++11 extension [-Wc++11-extensions]
        for (auto& v : t)
                     ^
/home/hannesweisbach/libcxxabi/src/cxa_demangle.cpp:86:18: warning: 'auto' type
specifier is a C++11 extension [-Wc++11-extensions]
            for (auto& s : v)
                 ^
/home/hannesweisbach/libcxxabi/src/cxa_demangle.cpp:86:26: warning: range-based
for loop is a C++11 extension [-Wc++11-extensions]
            for (auto& s : v)
                         ^
/home/hannesweisbach/libcxxabi/src/cxa_demangle.cpp:141:12: error: unknown type
name 'constexpr'
    static constexpr const char* spec = "%af";
           ^
[...]

When adding the flag "-std=c++11" manually everything works fine:
rm -rf *
cmake -DCMAKE_CXX_FLAGS="-std=c++11"
-DLIBCXXABI_LIBCXX_INCLUDES=../../libcxx/include .. -DCMAKE_C_COMPILER=clang
-DCMAKE_CXX_COMPILER=clang++
-- The C compiler identification is Clang 3.5.0
-- The CXX compiler identification is Clang 3.5.0
[...]
make
[Usual output. *No errors, no warnings*]

Hope this helps.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20141126/5dadbcef/attachment.html>

From bugzilla-daemon at llvm.org  Wed Nov 26 08:28:32 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 26 Nov 2014 16:28:32 +0000
Subject: [LLVMbugs] [Bug 21675] New: [aarch64] miscompile llvm.ctpop.i32
Message-ID: <bug-21675-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=21675

            Bug ID: 21675
           Summary: [aarch64] miscompile llvm.ctpop.i32
           Product: tools
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: llc
          Assignee: unassignedbugs at nondot.org
          Reporter: cole945 at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

This code loads v2i32 to count 1-bits in the 1st element.
The result is wrong, because the 2nd element is also being counted.
The original case counts both elements, this is just a reduced
case in order to reproduce the bug.

Bitcode for reproducing the case
-- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 --
target datalayout = "e-m:e-i64:64-i128:128-n32:64-S128"
target triple = "aarch64-unknown-linux-gnueabihf"

declare i32 @llvm.ctpop.i32(i32) #1

define i32 @cnt2(<2 x i32> addrspace(1)* %src) {
  %1 = getelementptr inbounds <2 x i32> addrspace(1)* %src, i64 0
  %2 = load <2 x i32> addrspace(1)* %1, align 8

  %3 = extractelement <2 x i32> %2, i64 0
  %4 = tail call i32 @llvm.ctpop.i32(i32 %3) #2

  ret i32 %4
}
-- 8< -- 8< -- 8< -- 8< -- 8< -- 8< -- 8< -- 8< -- 8< --


Actual result:
        ldr     d0, [x0]
        cnt     v0.8b, v0.8b
        uaddlv  h0, v0.8b
        fmov    w0, s0
        ret


Expected result:
        ldr     d0, [x0]
        mov     s0, v0.s[0]    <--
        cnt     v0.8b, v0.8b
        uaddlv  h0, v0.8b
        fmov    w0, s0
        ret


Without the 'mov' to clear upper 32-bit,
the 2nd element is being counted.

I think this is a bug of 'LowerCTPOP'.
Insert-subreg doesn't enforces the semantic of zero-extend.
A explicit zero-extend must be used instead.
Otherwise, the COPY (insert-subreg) will be eliminated by
register-coalescing pass.

-- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 --
diff --git a/lib/Target/AArch64/AArch64ISelLowering.cpp
b/lib/Target/AArch64/AArch64ISelLowering.cpp
index 1d74f6e..69cde10 100644
--- a/lib/Target/AArch64/AArch64ISelLowering.cpp
+++ b/lib/Target/AArch64/AArch64ISelLowering.cpp
@@ -3116,18 +3116,13 @@ SDValue AArch64TargetLowering::LowerCTPOP(SDValue Op,
SelectionDAG &DAG) const {
   SDValue Val = Op.getOperand(0);
   SDLoc DL(Op);
   EVT VT = Op.getValueType();
-  SDValue ZeroVec = DAG.getUNDEF(MVT::v8i8);

-  SDValue VecVal;
   if (VT == MVT::i32) {
-    VecVal = DAG.getNode(ISD::BITCAST, DL, MVT::f32, Val);
-    VecVal = DAG.getTargetInsertSubreg(AArch64::ssub, DL, MVT::v8i8, ZeroVec,
-                                       VecVal);
-  } else {
-    VecVal = DAG.getNode(ISD::BITCAST, DL, MVT::v8i8, Val);
+    Val = DAG.getNode(ISD::ZERO_EXTEND, DL, MVT::i64, Val);
   }
+  Val = DAG.getNode(ISD::BITCAST, DL, MVT::v8i8, Val);

-  SDValue CtPop = DAG.getNode(ISD::CTPOP, DL, MVT::v8i8, VecVal);
+  SDValue CtPop = DAG.getNode(ISD::CTPOP, DL, MVT::v8i8, Val);
   SDValue UaddLV = DAG.getNode(
       ISD::INTRINSIC_WO_CHAIN, DL, MVT::i32,
       DAG.getConstant(Intrinsic::aarch64_neon_uaddlv, MVT::i32), CtPop);
--
-- 8< -- 8< -- 8< -- 8< -- 8< -- 8< -- 8< -- 8< -- 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/20141126/c9438621/attachment.html>

From bugzilla-daemon at llvm.org  Wed Nov 26 11:34:29 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 26 Nov 2014 19:34:29 +0000
Subject: [LLVMbugs] [Bug 21678] New: UNREACHABLE with bad datalayout
	specifier
Message-ID: <bug-21678-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=21678

            Bug ID: 21678
           Summary: UNREACHABLE with bad datalayout specifier
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: Core LLVM classes
          Assignee: unassignedbugs at nondot.org
          Reporter: paul_robinson at playstation.sony.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Given this input:
    target datalayout = "e-g:64:64"
llc crashes with:
Unknown specifier in datalayout string
UNREACHABLE executed at /..../IR/DataLayout.cpp:341!

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20141126/40851b59/attachment.html>

From bugzilla-daemon at llvm.org  Wed Nov 26 12:40:25 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 26 Nov 2014 20:40:25 +0000
Subject: [LLVMbugs] [Bug 21679] New: ICE on invalid "int x = { y["
Message-ID: <bug-21679-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=21679

            Bug ID: 21679
           Summary: ICE on invalid "int x = { y["
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
          Assignee: unassignedclangbugs at nondot.org
          Reporter: greg_bedwell at sn.scee.net
                CC: llvmbugs at cs.uiuc.edu, rikka at google.com
    Classification: Unclassified

Since r222551 ("Enable ActOnIdExpression to use delayed typo correction for
non-C++ code when calling DiagnoseEmptyLookup"), the following (invalid) C++
input has started causing clang to crash.  I've verified that it produces the
expected compilation errors without crashing in r222550 but is still crashing
as of r222849:

// begin
int x = { y[
// end

$ clang -c small_ice.cpp -fsyntax-only -target x86_64-unknown-unknown
small_ice.cpp:3:7: error: expected expression
// end
      ^
small_ice.cpp:3:7: error: expected ']'
small_ice.cpp:2:12: note: to match this '['
int x = { y[
           ^
Stack dump:
0.      Program arguments: c:\work\public_svn\cached_builds\222551\clang.exe
-cc1 -triple x86_64-unknown-unknown -fsyntax-only -disable-free -main-file-name
small_ice.cpp -mrelocation-model static -mthread-model posix -mdisable-fp-elim
-fmath-errno -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu
x86-64 -dwarf-column-info -resource-dir
c:\work\public_svn\cached_builds\222551\..\lib\clang\3.6.0 -fdeprecated-macro
-fdebug-compilation-dir C:\tmp -ferror-limit 19 -fmessage-length 120
-mstackrealign -fobjc-runtime=gcc -fcxx-exceptions -fexceptions
-diagnostics-show-option -fcolor-diagnostics -x c++ small_ice.cpp
1.      <eof> parser at end of file

<snip rest of crash 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/20141126/d5d52568/attachment.html>

From bugzilla-daemon at llvm.org  Wed Nov 26 18:11:39 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 27 Nov 2014 02:11:39 +0000
Subject: [LLVMbugs] [Bug 21680] New: clang crashes at -O1 and above on
	x86_64-linux-gnu
Message-ID: <bug-21680-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=21680

            Bug ID: 21680
           Summary: clang crashes at -O1 and above on x86_64-linux-gnu
           Product: clang
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: su at cs.ucdavis.edu
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

The current clang trunk crashes when compiling the following testcase at -O1
and above in both 32-bit and 64-bit modes on x86_64-linux-gnu. 

This also affects earlier versions of clang since 3.2. 

$ clang-trunk -v
clang version 3.6.0 (trunk 220839)
Target: x86_64-unknown-linux-gnu
Thread model: posix
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.8
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.8.1
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.4
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.4.6
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.4.7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6.4
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7.3
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8.1
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Selected multilib: .;@m64
$ 
$ clang-trunk -O0 small.c
$ 
$ clang-trunk -O1 small.c
clang: /tmp/llvm/lib/Transforms/Scalar/SCCP.cpp:120: bool (anonymous
namespace)::LatticeVal::markConstant(llvm::Constant *): Assertion
`getLatticeValue() == forcedconstant && "Cannot move from overdefined to
constant!"' failed.
#0 0x28d6a5a llvm::sys::PrintStackTrace(_IO_FILE*)
(/usr/local/clang-trunk/bin/clang+0x28d6a5a)
#1 0x28d811b (/usr/local/clang-trunk/bin/clang+0x28d811b)
#2 0x7f3dd06d9cb0 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0xfcb0)
#3 0x7f3dcf4f80d5 gsignal
/build/buildd/eglibc-2.15/signal/../nptl/sysdeps/unix/sysv/linux/raise.c:64:0
#4 0x7f3dcf4fb83b abort /build/buildd/eglibc-2.15/stdlib/abort.c:93:0
#5 0x7f3dcf4f0d9e __assert_fail_base
/build/buildd/eglibc-2.15/assert/assert.c:55:0
#6 0x7f3dcf4f0e42 (/lib/x86_64-linux-gnu/libc.so.6+0x2ee42)
#7 0x240ff8c (/usr/local/clang-trunk/bin/clang+0x240ff8c)
#8 0x240f7e0 (/usr/local/clang-trunk/bin/clang+0x240f7e0)
#9 0x241360a (/usr/local/clang-trunk/bin/clang+0x241360a)
#10 0x240cd9b (/usr/local/clang-trunk/bin/clang+0x240cd9b)
#11 0x240b240 (/usr/local/clang-trunk/bin/clang+0x240b240)
#12 0x2866347 llvm::legacy::PassManagerImpl::run(llvm::Module&)
(/usr/local/clang-trunk/bin/clang+0x2866347)
#13 0x8f5a23 clang::EmitBackendOutput(clang::DiagnosticsEngine&,
clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions
const&, llvm::StringRef, llvm::Module*, clang::BackendAction,
llvm::raw_ostream*) (/usr/local/clang-trunk/bin/clang+0x8f5a23)
#14 0x8ea6f5 (/usr/local/clang-trunk/bin/clang+0x8ea6f5)
#15 0xaec5d3 clang::ParseAST(clang::Sema&, bool, bool)
(/usr/local/clang-trunk/bin/clang+0xaec5d3)
#16 0x6fbd9e clang::FrontendAction::Execute()
(/usr/local/clang-trunk/bin/clang+0x6fbd9e)
#17 0x6cf0fc clang::CompilerInstance::ExecuteAction(clang::FrontendAction&)
(/usr/local/clang-trunk/bin/clang+0x6cf0fc)
#18 0x6b1352 clang::ExecuteCompilerInvocation(clang::CompilerInstance*)
(/usr/local/clang-trunk/bin/clang+0x6b1352)
#19 0x6a7b27 cc1_main(llvm::ArrayRef<char const*>, char const*, void*)
(/usr/local/clang-trunk/bin/clang+0x6a7b27)
#20 0x6af9f5 main (/usr/local/clang-trunk/bin/clang+0x6af9f5)
#21 0x7f3dcf4e376d __libc_start_main
/build/buildd/eglibc-2.15/csu/libc-start.c:258:0
#22 0x6a7799 _start (/usr/local/clang-trunk/bin/clang+0x6a7799)
Stack dump:
0.    Program arguments: /usr/local/clang-trunk/bin/clang -cc1 -triple
x86_64-unknown-linux-gnu -emit-obj -disable-free -main-file-name small.c
-mrelocation-model static -mthread-model posix -fmath-errno -masm-verbose
-mconstructor-aliases -munwind-tables -fuse-init-array -target-cpu x86-64
-target-linker-version 2.22 -momit-leaf-frame-pointer -dwarf-column-info
-resource-dir /usr/local/clang-trunk/bin/../lib/clang/3.6.0 -internal-isystem
/usr/local/include -internal-isystem
/usr/local/clang-trunk/bin/../lib/clang/3.6.0/include -internal-externc-isystem
/usr/include/x86_64-linux-gnu -internal-externc-isystem /include
-internal-externc-isystem /usr/include -O1 -fdebug-compilation-dir
/data2/c-hunter-results/C/trans-bugs/REDUCED/20141126-clang-m32-m64-O1-O2-O3-Os-build-test929430
-ferror-limit 19 -fmessage-length 118 -mstackrealign -fobjc-runtime=gcc
-fdiagnostics-show-option -fcolor-diagnostics -o /tmp/small-ec10a6.o -x c
small.c 
1.    <eof> parser at end of file
2.    Per-module optimization passes
3.    Running pass 'Interprocedural Sparse Conditional Constant Propagation' on
module 'small.c'.
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.6.0 (trunk 220839)
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/small-e90260.c
clang: note: diagnostic msg: /tmp/small-e90260.sh
clang: note: diagnostic msg: 

********************
$ 


-------------------


int a, d;
long long c;

long long
fn1 ()
{
  int b; 
  if (b)
    return a;
  return 0;
}

void
fn2 ()
{
  c = fn1 ();
  d = __builtin_bswap64 (c);
}

int
main ()
{
  fn2 (); 
  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/20141127/0df5ac00/attachment.html>

From bugzilla-daemon at llvm.org  Wed Nov 26 18:56:54 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 27 Nov 2014 02:56:54 +0000
Subject: [LLVMbugs] [Bug 21680] clang crashes at -O1 and above on
	x86_64-linux-gnu
In-Reply-To: <bug-21680-206@http.llvm.org/bugs/>
References: <bug-21680-206@http.llvm.org/bugs/>
Message-ID: <bug-21680-206-SN0OSBzCwN@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=21680

David Majnemer <david.majnemer at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |david.majnemer at gmail.com
         Resolution|---                         |WORKSFORME

--- Comment #1 from David Majnemer <david.majnemer at gmail.com> ---
I can't reproduce on:
clang version 3.6.0 (trunk 222865) (llvm/trunk 222864)

Feel free to reopen if you can reproduce on a version at least as new as mine.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20141127/7f46a0e8/attachment.html>

From bugzilla-daemon at llvm.org  Thu Nov 27 04:11:32 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 27 Nov 2014 12:11:32 +0000
Subject: [LLVMbugs] [Bug 21681] New: Memory leak in FileArchive::find()
Message-ID: <bug-21681-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=21681

            Bug ID: 21681
           Summary: Memory leak in FileArchive::find()
           Product: lld
           Version: unspecified
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: All Bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: devlists at shadowlab.org
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

In Resolver::handleArchiveFile(), there is a call to archiveFile->find() that
may end up calling FileArchive::find().

FileArchive::find() create a new File (enclosed in a unique_ptr) and then
return it by releasing ownership (comment before the return statement: "// give
up the pointer so that this object no longer manages it").

The problem is that find() is a virtual method and may or may not returns a
owned pointer. The caller (Resolver) has no way to know if it should delete the
pointer after use. In fact, other implementation of ArchiveLibraryFile returns
a owned-pointer that must not be freed by the find() caller.

I think a solution could be to add a FileVectorT to FileArchive to keep track
of all returned files, and delete them when the FileArchive is destroyed.

Anyway, we should clarify the ownership of the pointer returned by the
ArchiveLibraryFile::find() virtual method and make sure all subclasses conform
to that contract.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20141127/5cb58fcc/attachment.html>

From bugzilla-daemon at llvm.org  Thu Nov 27 04:17:26 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 27 Nov 2014 12:17:26 +0000
Subject: [LLVMbugs] [Bug 21682] New: TrieEdge leak in
 MachONormalizedFileBinaryWriter.cpp
Message-ID: <bug-21682-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=21682

            Bug ID: 21682
           Summary: TrieEdge leak in MachONormalizedFileBinaryWriter.cpp
           Product: lld
           Version: unspecified
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: All Bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: devlists at shadowlab.org
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

TrieNode uses a SmallVector to store TrieEdge children.
But TrieNode is allocated using an llvm::bumpPtr allocator, and so its
destructor is never invoked when the memory is freed. As a result the
SmallVector destructor is never call either, and as the SmallVector is not
allocator aware, the memory managed by the SmallVector leaks.

A possible solution would be to use an other structure to store the TrieEdge
(chained list) that does not require additional memory allocation.
TrieEdge will contain a pointer to its sibling, and will be allocated using the
llvm bumpPtr allocator.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20141127/196bf1c1/attachment.html>

From bugzilla-daemon at llvm.org  Thu Nov 27 04:20:42 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 27 Nov 2014 12:20:42 +0000
Subject: [LLVMbugs] [Bug 21683] New: SimpleReference leak in
	SimpleDefinedAtom
Message-ID: <bug-21683-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=21683

            Bug ID: 21683
           Summary: SimpleReference leak in SimpleDefinedAtom
           Product: lld
           Version: unspecified
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: All Bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: devlists at shadowlab.org
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

When linking, SimpleDefinedAtom are allocated using a llvm::bumpPtr (at least
for Mach-O linking).

The SimpleDefinedAtom destructor is never called, and so its
std::vector<SimpleReference> member is never destroyed.

After linking clang, it results in a leaks of more than 177000 SimpleReference
objects (65MB).

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20141127/6549d7f4/attachment.html>

From bugzilla-daemon at llvm.org  Thu Nov 27 07:30:41 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 27 Nov 2014 15:30:41 +0000
Subject: [LLVMbugs] [Bug 21674] Stand-alone compilation fails,
 due to std=c++11 flag missing.
In-Reply-To: <bug-21674-206@http.llvm.org/bugs/>
References: <bug-21674-206@http.llvm.org/bugs/>
Message-ID: <bug-21674-206-a4TMpXLPNg@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=21674

Marshall Clow (home) <mclow.lists at gmail.com> 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/20141127/b16bb21a/attachment.html>

From bugzilla-daemon at llvm.org  Thu Nov 27 07:37:52 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 27 Nov 2014 15:37:52 +0000
Subject: [LLVMbugs] [Bug 21684] New: Ellipsis at end of generic lambda
 parameter-declaration-clause should be parsed as a parameter pack
Message-ID: <bug-21684-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=21684

            Bug ID: 21684
           Summary: Ellipsis at end of generic lambda
                    parameter-declaration-clause should be parsed as a
                    parameter pack
           Product: clang
           Version: 3.5
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++14
          Assignee: unassignedclangbugs at nondot.org
          Reporter: ed at catmur.co.uk
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

void f() { [](auto...){}(); }

prog.cc:1:12: error: no matching function for call to object of type '(lambda
at prog.cc:1:12)'
void f() { [](auto...){}(); }
          ^~~~~~~~~~~~~
prog.cc:1:12: note: candidate function template not viable: requires at least 1
argument, but 0 were provided
1 error generated.

According to [dcl.fct]/14 the ellipsis should be parsed as part of the
abstract-declarator; however gcc parses it as part of the
parameter-declaration-clause.

gcc is similarly incorrect; according to
http://www.reddit.com/r/cpp/comments/2nkcvi/generic_lambda_inconsistency/ MSVC
(latest CTP) is correct.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20141127/0fab13cd/attachment.html>

From bugzilla-daemon at llvm.org  Thu Nov 27 10:56:27 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 27 Nov 2014 18:56:27 +0000
Subject: [LLVMbugs] [Bug 21685] New: NVPTX emits incorrect PTX for weak_odr
 (and potentially other linkage types)
Message-ID: <bug-21685-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=21685

            Bug ID: 21685
           Summary: NVPTX emits incorrect PTX for weak_odr (and
                    potentially other linkage types)
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: PTX
          Assignee: unassignedbugs at nondot.org
          Reporter: wujingyue at gmail.com
                CC: justin.holewinski at gmail.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Given the following IR

target datalayout = "e-i64:64-v16:16-v32:32-n16:32:64"
target triple = "nvptx64-unknown-unknown"

define weak_odr void @foo() {
entry:
  ret void
}

!nvvm.annotations = !{!0}

!0 = metadata !{void ()* @foo, metadata !"kernel", i32 1}

The NVPTX backend emits

/
// Generated by LLVM NVPTX Back-End
//

.version 3.2
.target sm_35
.address_size 64

        .weak   foo
                                        // @foo
.weak .entry foo(

)
{


// BB#0:                                // %entry
        ret;
}

I found a similar issue was discussed in
http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-June/050610.html. While it's
possible for us to workaround, it prevents explicit template instantiation
which is something we need in longer term. For instance, 

template <typename T>
__global__ void foo(T x) {
  bar<T>(x);
}

template __global__ void foo<float>(float x);

I looked at the code of AsmPrinter. It looks like we can solve this issue at
least for GlobalVariables by inheriting function EmitGlobalVariable. A lot of
logic there (such as thread local variable) is unnecessary/non-existent for
NVPTX anyway. 

Jingyue

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20141127/28fa8c79/attachment.html>

From bugzilla-daemon at llvm.org  Thu Nov 27 11:55:33 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 27 Nov 2014 19:55:33 +0000
Subject: [LLVMbugs] [Bug 21686] New: libc++ doesn't build when
 _LIBCPP_HAS_NO_MONOTONIC_CLOCK is defined.
Message-ID: <bug-21686-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=21686

            Bug ID: 21686
           Summary: libc++ doesn't build when
                    _LIBCPP_HAS_NO_MONOTONIC_CLOCK is defined.
           Product: libc++
           Version: unspecified
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: All Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: eric at efcs.ca
                CC: llvmbugs at cs.uiuc.edu, mclow.lists at gmail.com
    Classification: Unclassified

Adding a bug for this so I don't forget about it.
_LIBCPP_HAS_NO_MONOTONIC_CLOCK causes build failures in different mutex types.
_LIBCPP_HAS_NOM_MONOTONIC_CLOCK seems to be related to _LIBCPP_HAS_NO_THREADS
and libc++ will build fine if both are defined.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20141127/9cf650d9/attachment.html>

From bugzilla-daemon at llvm.org  Thu Nov 27 14:15:00 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 27 Nov 2014 22:15:00 +0000
Subject: [LLVMbugs] [Bug 21687] New: The redecl chain doesn't get updated
 when newer decl has computed exception spec and the previous doesn't.
Message-ID: <bug-21687-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=21687

            Bug ID: 21687
           Summary: The redecl chain doesn't get updated when newer decl
                    has computed exception spec and the previous doesn't.
           Product: clang
           Version: unspecified
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Modules
          Assignee: unassignedclangbugs at nondot.org
          Reporter: vvasilev at cern.ch
                CC: dgregor at apple.com, 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/20141127/0d75460d/attachment.html>

From bugzilla-daemon at llvm.org  Thu Nov 27 21:40:22 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 28 Nov 2014 05:40:22 +0000
Subject: [LLVMbugs] [Bug 21385] optimize reciprocals with fast-math (x86)
In-Reply-To: <bug-21385-206@http.llvm.org/bugs/>
References: <bug-21385-206@http.llvm.org/bugs/>
Message-ID: <bug-21385-206-4Q7E2FComC@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=21385

Steven Noonan <steven at uplinklabs.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
                 CC|                            |steven at uplinklabs.net
         Resolution|FIXED                       |---

--- Comment #23 from Steven Noonan <steven at uplinklabs.net> ---
I'd like to reopen this issue to ask why FeatureUseSqrtEst and
FeatureUseRecipEst were only enabled for Jaguar. It has demonstrable benefits
on many if not all of the other x86 microarchitectures. Is there a reason it
cannot be enabled more broadly?

I'm not sure what GCC's criteria is for enabling it, but I've seen reciprocal
square root estimate enabled on every x86 -march= I know of whenever
-ffast-math is specified and SSE is available. For example, even as far back as
-march=pentium3 rsqrtss is used:

float rsqrtf(float f)
{
        return 1.0f / sqrtf(f);
}

$ gcc -m32 -O3 -ffast-math -mfpmath=sse -march=pentium3 -S -o - rsqrt.c
[...]
rsqrtf:

        subl    $4, %esp
        rsqrtss 8(%esp), %xmm1
        movss   8(%esp), %xmm0
        mulss   %xmm1, %xmm0
        mulss   %xmm1, %xmm0
        mulss   .LC1, %xmm1
        addss   .LC0, %xmm0
        mulss   %xmm1, %xmm0
        movss   %xmm0, (%esp)
        flds    (%esp)
        popl    %eax
        ret
.LC0:
        .long   3225419776
.LC1:
        .long   3204448256


GCC does not, however, emit reciprocal estimates, even with -march=haswell.
It's possible that GCC does not implement any selection of RCPSS:

float recipf(float f)
{
        return 1.0f / f;
}

$ gcc -O3 -ffast-math -mfpmath=sse -march=haswell -S -o - recip.c
[...]
        vmovss  .LC0(%rip), %xmm1
        vdivss  %xmm0, %xmm1, %xmm0
        ret
.LC0:
        .long   1065353216

At the very least I'd like to see reciprocal square root estimates added by
default on x86 for -ffast-math. How can we get such a change implemented? Is it
a matter of building confidence in the safety and benefit of such a change?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20141128/e4ef3f01/attachment.html>

From bugzilla-daemon at llvm.org  Fri Nov 28 02:30:29 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 28 Nov 2014 10:30:29 +0000
Subject: [LLVMbugs] [Bug 21688] New: clang objective-c++ incorrect mangling
 for function with multiple id parameters
Message-ID: <bug-21688-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=21688

            Bug ID: 21688
           Summary: clang objective-c++ incorrect mangling for function
                    with multiple id parameters
           Product: clang
           Version: 3.5
          Hardware: Macintosh
                OS: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: LLVM Codegen
          Assignee: unassignedclangbugs at nondot.org
          Reporter: joao at abecasis.name
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Consider:

  // mangling.cpp

  struct objc_selector;
  struct objc_object;

  typedef struct objc_selector *SEL;
  typedef struct objc_object *id;

  struct NSObject;

  void good1(id, id) { }
  void good2(struct NSObject *, id, id) { }
  void good3(struct NSObject *, SEL, id) { }

  void bad1(struct NSObject *, SEL, id,  id) { }
  void bad2(struct NSObject *, SEL, id,  id, id) { }

Compiling this code as Objective C++ generates what seems to be incorrect name
mangling for the "bad" functions:

  $ clang++ -x objective-c++ -c mangling.cc && nm mangling.o | c++filt
  0000000000000138 short EH_frame0
  0000000000000050 T bad1(NSObject*, objc_selector*, objc_object*, objc_object)
  00000000000001c8 S bad1(NSObject*, objc_selector*, objc_object*, objc_object)
(.eh)
  0000000000000070 T bad2(NSObject*, objc_selector*, objc_object*, objc_object,
objc_object)
  00000000000001f0 S bad2(NSObject*, objc_selector*, objc_object*, objc_object,
objc_object) (.eh)
  0000000000000000 T good1(objc_object*, objc_object*)
  0000000000000150 S good1(objc_object*, objc_object*) (.eh)
  0000000000000010 T good2(NSObject*, objc_object*, objc_object*)
  0000000000000178 S good2(NSObject*, objc_object*, objc_object*) (.eh)
  0000000000000030 T good3(NSObject*, objc_selector*, objc_object*)
  00000000000001a0 S good3(NSObject*, objc_selector*, objc_object*) (.eh)

Compiling as C++ generates what seems to be the correct mangling:

  $ clang++ -x c++ -c mangling.cc && nm mangling.o | c++filt
  0000000000000130 short EH_frame0
  0000000000000050 T bad1(NSObject*, objc_selector*, objc_object*,
objc_object*)
  00000000000001c0 S bad1(NSObject*, objc_selector*, objc_object*,
objc_object*) (.eh)
  0000000000000070 T bad2(NSObject*, objc_selector*, objc_object*,
objc_object*, objc_object*)
  00000000000001e8 S bad2(NSObject*, objc_selector*, objc_object*,
objc_object*, objc_object*) (.eh)
  0000000000000000 T good1(objc_object*, objc_object*)
  0000000000000148 S good1(objc_object*, objc_object*) (.eh)
  0000000000000010 T good2(NSObject*, objc_object*, objc_object*)
  0000000000000170 S good2(NSObject*, objc_object*, objc_object*) (.eh)
  0000000000000030 T good3(NSObject*, objc_selector*, objc_object*)
  0000000000000198 S good3(NSObject*, objc_selector*, objc_object*) (.eh)

My main issue here is that the mangling is inconsistent if code is compiled as
Objective-C++ or C++, which prevents using a function compiled as Objective C++
to be used in plain 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/20141128/00b2e8f8/attachment.html>

From bugzilla-daemon at llvm.org  Fri Nov 28 04:46:54 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 28 Nov 2014 12:46:54 +0000
Subject: [LLVMbugs] [Bug 21671] backend crash with large structure variables
In-Reply-To: <bug-21671-206@http.llvm.org/bugs/>
References: <bug-21671-206@http.llvm.org/bugs/>
Message-ID: <bug-21671-206-PysqqfEuRo@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=21671

Dale Martin <Dale.Martin at mathworks.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |DUPLICATE

--- Comment #3 from Dale Martin <Dale.Martin at mathworks.com> ---
Marking as dup of PR-21513

*** This bug has been marked as a duplicate of bug 21513 ***

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20141128/99671cf1/attachment.html>

From bugzilla-daemon at llvm.org  Fri Nov 28 13:33:23 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 28 Nov 2014 21:33:23 +0000
Subject: [LLVMbugs] [Bug 21689] New: missing-field-initializers too
 aggressive for C's {0}
Message-ID: <bug-21689-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=21689

            Bug ID: 21689
           Summary: missing-field-initializers too aggressive for C's {0}
           Product: clang
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
          Assignee: unassignedclangbugs at nondot.org
          Reporter: danalbert at google.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Clang will warn on `{0}` as -Wmissing-field-initializers even in C code. The
language provides this to explicitly say "initialize everything to zero". Some
discussion here:
http://clang-developers.42468.n3.nabble.com/Wmissing-field-initializers-td3761260.html

I'm fine with John's solution of only relaxing this for C 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/20141128/85fa5320/attachment.html>

From bugzilla-daemon at llvm.org  Fri Nov 28 14:23:34 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 28 Nov 2014 22:23:34 +0000
Subject: [LLVMbugs] [Bug 21688] clang objective-c++ incorrect mangling for
 function with multiple id parameters
In-Reply-To: <bug-21688-206@http.llvm.org/bugs/>
References: <bug-21688-206@http.llvm.org/bugs/>
Message-ID: <bug-21688-206-Y1sbIHqQul@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=21688

David Majnemer <david.majnemer at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |david.majnemer at gmail.com
         Resolution|---                         |FIXED
           Assignee|unassignedclangbugs at nondot. |david.majnemer at gmail.com
                   |org                         |

--- Comment #1 from David Majnemer <david.majnemer at gmail.com> ---
Fixed in r222941.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20141128/06211af1/attachment.html>

From bugzilla-daemon at llvm.org  Sat Nov 29 06:29:57 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 29 Nov 2014 14:29:57 +0000
Subject: [LLVMbugs] [Bug 21690] New: static __thread T* ptr(0);
 error: initializer for thread-local variable must be a constant
 expression (while T* ptr = 0 will work)
Message-ID: <bug-21690-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=21690

            Bug ID: 21690
           Summary: static __thread T* ptr(0); error: initializer for
                    thread-local variable must be a constant expression
                    (while T* ptr = 0 will work)
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
          Assignee: unassignedclangbugs at nondot.org
          Reporter: david.abdurachmanov at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

I bumped Clang to pre-3.6 (65d8b4c4998b3a0c20934ea72ede72ef4838a004, r222081,
~15 Nov). Have not checked the trunk version.

$ cat test.cc
template <typename T>
void dummy() {
 static __thread T* ptr(0);
}

$ clang++ -std=c++11 test.cc
test.cc:3:25: error: initializer for thread-local variable must be a constant
expression
 static __thread T* ptr(0);
                       ^~~
test.cc:3:22: note: use 'thread_local' to allow this
 static __thread T* ptr(0);
                    ^
1 error generated.

The following will work:

static __thread T* ptr;
static __thread T* ptr = 0;
static __thread T* ptr = nullptr;
static thread_local T* ptr(nullptr);

The following will not work:

static __thread T* ptr{0};
static __thread T* ptr(0);

It works with c-like initialization, but not with constructor initialization or
uniform initialization.

We are assigning initial value of pointer (nullptr), isn't nullptr/0 are
constant expression 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/20141129/b1fabc22/attachment.html>

From bugzilla-daemon at llvm.org  Sat Nov 29 06:52:12 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 29 Nov 2014 14:52:12 +0000
Subject: [LLVMbugs] [Bug 21691] New: [META] Compiling the Coreboot with clang
Message-ID: <bug-21691-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=21691

            Bug ID: 21691
           Summary: [META] Compiling the Coreboot with clang
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: eocallaghan at alterapraxis.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

This is a meta-bug, other bugs that prevent building Coreboot with clang will
be made to depend on it.

We should keep this bug open, until someone no longer needs local patches to
have Coreboot built with 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/20141129/0844ac86/attachment.html>

From bugzilla-daemon at llvm.org  Sat Nov 29 16:34:29 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 30 Nov 2014 00:34:29 +0000
Subject: [LLVMbugs] [Bug 21693] New: libLTO opportunistically links unused
 libraries (libedit, libncurses, libffi)
Message-ID: <bug-21693-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=21693

            Bug ID: 21693
           Summary: libLTO opportunistically links unused libraries
                    (libedit, libncurses, libffi)
           Product: tools
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: lto
          Assignee: unassignedbugs at nondot.org
          Reporter: jeremyhu at apple.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

$ otool -L llvm-3.6/lib/libLTO.dylib 
llvm-3.6/lib/libLTO.dylib:
    /opt/local/libexec/llvm-3.6/lib/libLTO.dylib (compatibility version 0.0.0,
current version 0.0.0)
    /opt/local/libexec/llvm-3.6/lib/libLLVM-3.6svn.dylib (compatibility version
0.0.0, current version 0.0.0)
    /opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current version
1.2.8)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version
1213.0.0)
    /opt/local/lib/libffi.6.dylib (compatibility version 7.0.0, current version
7.4.0)
    /opt/local/lib/libedit.0.dylib (compatibility version 1.0.0, current
version 1.51.0)
    /opt/local/lib/libncurses.5.dylib (compatibility version 5.0.0, current
version 5.0.0)
    /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version
120.0.0)

but nm -m shows that only symbols from libLLVM, libSystem, and libc++ are used.
 The other links are unnecessary.

Looking back at what I have on this system, this has been the case for quite
some time.  The oldest libLTO that I have is from 3.3, and it pulls in zlib and
libffi (but libedit and ncurses cam in some time more recently).

$ otool -L llvm-3.3/lib/libLTO.dylib 
llvm-3.3/lib/libLTO.dylib:
    /opt/local/libexec/llvm-3.3/lib/libLTO.dylib (compatibility version 0.0.0,
current version 0.0.0)
    /opt/local/libexec/llvm-3.3/lib/libLLVM-3.3.dylib (compatibility version
0.0.0, current version 0.0.0)
    /opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current version
1.2.8)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version
1213.0.0)
    /opt/local/lib/libffi.6.dylib (compatibility version 7.0.0, current version
7.2.0)
    /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version
120.0.0)

These are built via MacPorts on OSX.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20141130/ec341766/attachment.html>

From bugzilla-daemon at llvm.org  Sat Nov 29 19:48:10 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 30 Nov 2014 03:48:10 +0000
Subject: [LLVMbugs] [Bug 21694] New: wrong code at -Os and above on
	x86_64-linux-gnu
Message-ID: <bug-21694-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=21694

            Bug ID: 21694
           Summary: wrong code at -Os and above on x86_64-linux-gnu
           Product: clang
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: su at cs.ucdavis.edu
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

The current clang trunk miscompiles the following code at -Os and above on
x86_64-linux-gnu in both 32-bit and 64-bit modes.

This is a regression from 3.5.0.  

$ clang-trunk -v
clang version 3.6.0 (trunk 222928)
Target: x86_64-unknown-linux-gnu
Thread model: posix
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.8
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.8.1
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.4
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.4.6
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.4.7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6.4
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7.3
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8.1
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Selected multilib: .;@m64
$ 
$ clang-trunk -O1 small.c; a.out
$ clang-3.5.0 -Os small.c; a.out
$ 
$ clang-trunk -Os small.c
$ a.out
Aborted (core dumped)
$ 


------------------------


int a = 1, c, *f = &c;
int volatile e;
short b, *d = &b;

static int
fn1 (int *p)
{
  for (b = 1; b != 4; b += 5)
    if (*p)
      e = 0;
    else
      return 0;
  *f = *d;
  return 0;
}

int
main ()
{
  int *g = &a;
  fn1 (g);

  if (c != 4) 
    __builtin_abort (); 

  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/20141130/8adf7df4/attachment.html>

From bugzilla-daemon at llvm.org  Sun Nov 30 02:17:56 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 30 Nov 2014 10:17:56 +0000
Subject: [LLVMbugs] [Bug 21650] PowerPC attn and cache inhibited storage
 instructions missing from assembler
In-Reply-To: <bug-21650-206@http.llvm.org/bugs/>
References: <bug-21650-206@http.llvm.org/bugs/>
Message-ID: <bug-21650-206-tFGT7jMkyq@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=21650

Hal Finkel <hfinkel at anl.gov> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #6 from Hal Finkel <hfinkel at anl.gov> ---
(In reply to comment #5)
> attn added in r222712.

and *cix added in r222976.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20141130/be5fad89/attachment.html>

From bugzilla-daemon at llvm.org  Sun Nov 30 04:08:39 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 30 Nov 2014 12:08:39 +0000
Subject: [LLVMbugs] [Bug 21695] New: Integrated assembler fails to set the
 target architecture from .arch
Message-ID: <bug-21695-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=21695

            Bug ID: 21695
           Summary: Integrated assembler fails to set the target
                    architecture from .arch
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: FreeBSD
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: ARM
          Assignee: unassignedbugs at nondot.org
          Reporter: andrew at fubar.geek.nz
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 13406
  --> http://llvm.org/bugs/attachment.cgi?id=13406&action=edit
Simple test case, build with clang -c -target arm-gnueabi-linux cpu-test.s

The attached test case, when built with "clang -c -target arm-gnueabi-linux
cpu-test.s", fails to assemble with the llvm integrated assembler with the
following error:

cpu-test.s:2:1: error: instruction requires: data-barriers
dsb

We use .arch in the FreeBSD kernel to build assembly code that will target a
known architecture however it may not have -march argument set causing the
build to fail.

In binutils the .arch directive sets the current target architecture, it can
then be changed later to a new architecture if needed.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20141130/e62cb1dc/attachment.html>

From bugzilla-daemon at llvm.org  Sun Nov 30 14:19:46 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 30 Nov 2014 22:19:46 +0000
Subject: [LLVMbugs] [Bug 21698] New: no asm/errno.h from
	/usr/include/linux/errno.h
Message-ID: <bug-21698-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=21698

            Bug ID: 21698
           Summary: no asm/errno.h from /usr/include/linux/errno.h
           Product: compiler-rt
           Version: 3.4
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: release blocker
          Priority: P
         Component: compiler-rt
          Assignee: unassignedbugs at nondot.org
          Reporter: kangus at jaga.us
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Build stopped after GCDAPorfiling.c included errno.h and errno.h included
asm/errno.h which does not exist.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20141130/47e2dd1e/attachment.html>