From bugzilla-daemon at llvm.org Mon Sep 1 02:02:15 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 01 Sep 2014 09:02:15 +0000
Subject: [LLVMbugs] [Bug 20823] New: Using -no-failure-reports makes
scan-build hang
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=20823
Bug ID: 20823
Summary: Using -no-failure-reports makes scan-build hang
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Static Analyzer
Assignee: kremenek at apple.com
Reporter: Jani_Lahtinen at mcafee.com
CC: llvmbugs at cs.uiuc.edu
Classification: Unclassified
If I use 'scan-build -no-failure-report' the build get stuck.
$ strace scan-build make
...
open("/etc/localtime", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=1883, ...}) = 0
fstat(3, {st_mode=S_IFREG|0644, st_size=1883, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f1355448000
read(3, "TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\5\0\0\0\5\0\0\0\0"..., 4096)
= 1883
lseek(3, -1201, SEEK_CUR) = 682
read(3, "TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\6\0\0\0\6\0\0\0\0"..., 4096)
= 1201
close(3) = 0
munmap(0x7f1355448000, 4096) = 0
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From bugzilla-daemon at llvm.org Mon Sep 1 03:35:27 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 01 Sep 2014 10:35:27 +0000
Subject: [LLVMbugs] [Bug 20655] setAlreadyVectorized does not delete
obsolete metadata
In-Reply-To:
References:
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=20655
Renato Golin changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|REOPENED |RESOLVED
CC| |seth.cantrell at gmail.com
Resolution|--- |FIXED
--- Comment #8 from Renato Golin ---
It seems MSVC 2012 is happy with the code, thanks Seth Cantrell for the tip.
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From bugzilla-daemon at llvm.org Mon Sep 1 04:37:03 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 01 Sep 2014 11:37:03 +0000
Subject: [LLVMbugs] [Bug 20825] New: "extern template" seems to invoke
explicit instanciation but it should prohibit it.
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=20825
Bug ID: 20825
Summary: "extern template" seems to invoke explicit
instanciation but it should prohibit it.
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: C++11
Assignee: unassignedclangbugs at nondot.org
Reporter: gw.fossdev at gmail.com
CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
Classification: Unclassified
Created attachment 12967
--> http://llvm.org/bugs/attachment.cgi?id=12967&action=edit
A simple test case to illustrate the problem.
If I understood N1448 of the C++11 standard correctly, then "extern template"
should inhibit (implicite) instansiation. However, diagnostics now tell me that
explicit instantiation is actually invoked, inhibiting to partially specialize
static member variables.
The test case given below issues the following disgnostics with
Debian clang version 3.5.0-+rc1-2 (tags/RELEASE_35/rc1) (based on LLVM 3.5.0)
==============
testcase.cc:12:34: error: explicit specialization of 'info' after instantiation
template <> const char * A::info = "This is int";
^
testcase.cc:9:23: note: explicit instantiation first required here
extern template class A;
^
testcase.cc:13:35: error: explicit specialization of 'info' after instantiation
template <> const char * A::info = "This is char";
^
testcase.cc:10:23: note: explicit instantiation first required here
extern template class A;
^
2 errors generated.
=============
g++ (4.9) compiles and links this code fine.
In the code that made me aware of the problem the "extern template" is of
course located in a header file, and hence the specialization can not be added
before the "extern template" because it results in multiple definitions at link
time. On the other hand, using "extern template" is required to enforce
visibility attributes.
Many thanks.
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From bugzilla-daemon at llvm.org Mon Sep 1 09:30:27 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 01 Sep 2014 16:30:27 +0000
Subject: [LLVMbugs] [Bug 19922] Broken debugging info compiled with -g -O0
gives while debugging in lldb within functions
In-Reply-To:
References:
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=19922
Frederic Riss changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
CC| |friss at apple.com
Resolution|--- |WORKSFORME
--- Comment #4 from Frederic Riss ---
This doesn't happen anymore on LLVM master, the function parameters have
function wide live ranges. I have confirmed the issue on a few months old
compiler, the fix is quite recent.
I'm marking this 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:
From bugzilla-daemon at llvm.org Mon Sep 1 10:14:37 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 01 Sep 2014 17:14:37 +0000
Subject: [LLVMbugs] [Bug 20826] New: compiled code crash in std::string
destructor in lambda capture on PPC 32
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=20826
Bug ID: 20826
Summary: compiled code crash in std::string destructor in
lambda capture on PPC 32
Product: clang
Version: trunk
Hardware: Other
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: C++11
Assignee: unassignedclangbugs at nondot.org
Reporter: bayoubengal at mac.com
CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
Classification: Unclassified
I'm cross-compiling. host == OSX 10.9. target == -target powerpc-unknown-linux
-m32 -mcpu=e500v2 -std=c++14. clang code version == 'clang version 3.6.0 (trunk
216704)' std lib flag == '-stdlib=libc++'. optimization flags == '-g -O0'
The code crashes in the basic_string destructor with the system complaining of
a double free of a pointer. I do indeed see this pointer being passed to free()
multiple times. However, I have no discerned if the pointer is being
reallocated each time.
message from system == '*** glibc detected *** /test/testPocosn_static: double
free or corruption (fasttop): 0x100940e0 ***
======= Backtrace: ========='
partial backtrace of the crash...
#4 0x1000673c in deallocate (this=0x8214924e, __p=0x4 )
at
/Volumes/dev/devel/testPoco/../PrgSDK_1/comx_p2020/supernode_3/linuxSDK3.8/usr/include/c++/v1/memory:1636
#5 deallocate (__a=..., __p=0x0, __n=0) at
/Volumes/dev/devel/testPoco/../PrgSDK_1/comx_p2020/supernode_3/linuxSDK3.8/usr/include/c++/v1/memory:1447
#6 std::__1::basic_string,
std::__1::allocator >::~basic_string (this=0x0)
at
/Volumes/dev/devel/testPoco/../PrgSDK_1/comx_p2020/supernode_3/linuxSDK3.8/usr/include/c++/v1/string:2244
#7 0x8256c9a2 in ?? ()
code snippet:
(This code runs fine when targeting OSX 10.9/x86_64)
#include
#include
#include
#include
int main(int argc, char** argv)
{
std::string tmpCaptureTest="test a captured string";
auto tmpCallback = [=](const std::string& s, int i , double d)
{
std::cout << tmpCaptureTest << s << i << d << std::endl;
return 43;
};
std::packaged_task
tmpTask(tmpCallback);
std::future tmpTaskResult = tmpTask.get_future();
auto tmpArg1 = "test";
auto tmpArg2 = 56;
auto tmpArg3 = 3.7;
auto tmpDispatchCallbackWrapper = [=, tmpTask2 = std::move(tmpTask)] ()
mutable
{
tmpTask2(tmpArg1, tmpArg2, tmpArg3);
};
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:
From bugzilla-daemon at llvm.org Mon Sep 1 12:23:28 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 01 Sep 2014 19:23:28 +0000
Subject: [LLVMbugs] [Bug 20827] New: clang 3.3 suggests initializing
pthread_t to NULL
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=20827
Bug ID: 20827
Summary: clang 3.3 suggests initializing pthread_t to NULL
Product: clang
Version: 3.3
Hardware: PC
OS: FreeBSD
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
wtperf.c:1867:28: warning: variable 'monitor_thread' may be uninitialized when
used here [-Wconditional-uninitialized]
(t_ret = pthread_join(monitor_thread, NULL)) != 0) {
^~~~~~~~~~~~~~
wtperf.c:1744:26: note: initialize the variable 'monitor_thread' to silence
this
warning
pthread_t monitor_thread;
^
= NULL
AFAIK, it's never legal to initialize a pthread_t value to anything 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:
From bugzilla-daemon at llvm.org Mon Sep 1 14:27:37 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 01 Sep 2014 21:27:37 +0000
Subject: [LLVMbugs] [Bug 20822] clang crashes on valid code at -O1 and above
on x86_64-linux-gnu
In-Reply-To:
References:
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=20822
David Majnemer changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |FIXED
Assignee|unassignedclangbugs at nondot. |david.majnemer at gmail.com
|org |
--- Comment #4 from David Majnemer ---
Fixed in r216891.
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From bugzilla-daemon at llvm.org Mon Sep 1 17:33:41 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 02 Sep 2014 00:33:41 +0000
Subject: [LLVMbugs] [Bug 20828] New: Regression(216776:216812): Assertion
failed: MRI->getVRegDef(reg) && "Register use before def!",
file llvm\lib\CodeGen\LiveVariables.cpp, line 133
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=20828
Bug ID: 20828
Summary: Regression(216776:216812): Assertion failed:
MRI->getVRegDef(reg) && "Register use before def!",
file llvm\lib\CodeGen\LiveVariables.cpp, line 133
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: nicolasweber at gmx.de
CC: llvmbugs at cs.uiuc.edu
Classification: Unclassified
This appeared on our bot here:
http://build.chromium.org/p/chromium.fyi/builders/Cr%20Win%20Clang/builds/166/steps/compile/logs/stdio
Will post more details tomorrow.
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From bugzilla-daemon at llvm.org Mon Sep 1 23:09:51 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 02 Sep 2014 06:09:51 +0000
Subject: [LLVMbugs] [Bug 20829] New: Initialization of union type
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=20829
Bug ID: 20829
Summary: Initialization of union type
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
Assignee: unassignedclangbugs at nondot.org
Reporter: Jani_Lahtinen at mcafee.com
CC: llvmbugs at cs.uiuc.edu
Classification: Unclassified
The following code:
typedef union {
struct {
int a:1;
int b:1;
int c:1;
int d:1;
};
uint8_t mask;
} foo;
int main(void)
{
foo x;
x.mask = 0xff;
x = (foo){.a = 1};
printf("%02x\n", x.mask);
return 0;
}
when compiled with -O0 prints two hex-digits the last of which is one, and the
first is random.
C99 standard says:
6.7.8 Initialization
...
8. Except where explicitly stated otherwise, for the purposes of this subclause
unnamed members of objects of structure and union type do not participate in
initialization. Unnamed members of structure objects have indeterminate value
even after initialization.
...
21. If there are fewer initializers in a brace-enclosed list than there are
elements or members
of an aggregate, or fewer characters in a string literal used to initialize an
array of known
size than there are elements in the array, the remainder of the aggregate shall
be
initialized implicitly the same as objects that have static storage duration.
I am unsure is the Clang behaviour according to standard or not.
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From bugzilla-daemon at llvm.org Mon Sep 1 23:28:29 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 02 Sep 2014 06:28:29 +0000
Subject: [LLVMbugs] [Bug 20024] Change to "split up an indexed load if only
the base pointer value is live" breaks PPC self-hosting
In-Reply-To:
References:
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=20024
Hal Finkel changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #2 from Hal Finkel ---
You were indeed correct, the problem was an interaction with
ISD::TargetConstants (as explained in the commit message). Reapplied in
r216898.
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From bugzilla-daemon at llvm.org Mon Sep 1 23:42:01 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 02 Sep 2014 06:42:01 +0000
Subject: [LLVMbugs] [Bug 20830] New: std::vector ctor for POD type from
pointer range results in horrible codegen
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=20830
Bug ID: 20830
Summary: std::vector ctor for POD type from pointer range
results in horrible codegen
Product: libc++
Version: unspecified
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: unassignedclangbugs at nondot.org
Reporter: arseny.kapoulkine at gmail.com
CC: llvmbugs at cs.uiuc.edu, mclow.lists at gmail.com
Classification: Unclassified
Created attachment 12970
--> http://llvm.org/bugs/attachment.cgi?id=12970&action=edit
Full disassembly for the problematic code
Using clang from Xcode 6 Beta 3:
Apple LLVM version 6.0 (clang-600.0.38) (based on LLVM 3.5svn)
Compiling the following code:
std::vector build(const char* data, size_t size) { return
std::vector(data, data + size); }
Results in the assembly with *this* as an inner loop (clang++ -O3):
LBB0_5: ## =>This Inner Loop Header: Depth=1
testq %rcx, %rcx
movl $0, %eax
je LBB0_7
## BB#6: ## in Loop: Header=BB0_5 Depth=1
movb (%rbx), %al
movb %al, (%rcx)
movq 8(%r14), %rax
LBB0_7: ##
%_ZNSt3__116allocator_traitsINS_9allocatorIcEEE9constructIccEEvRS2_PT_RKT0_.exit.i.i.i
## in Loop: Header=BB0_5 Depth=1
incq %rax
movq %rax, 8(%r14)
incq %rbx
decq %r15
movq %rax, %rcx
jne LBB0_5
With -stdlib=libstdc++ I get "callq _memcpy" instead.
Changing libc++ sources to hoist __end_ into a local does not help very much -
it removes redundant load/store instructions for __end_ but the loop is still
there.
Also I'm not sure why "decq %r15" is here - as far as I can see compiler should
have removed it. Can someone confirm that this part looks like a separate
optimization issue and warrants filing a separate LLVM bug?
Full disassembly dump attached.
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From bugzilla-daemon at llvm.org Mon Sep 1 23:42:15 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 02 Sep 2014 06:42:15 +0000
Subject: [LLVMbugs] [Bug 20831] New: std::vector ctor for POD type from
pointer range results in horrible codegen
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=20831
Bug ID: 20831
Summary: std::vector ctor for POD type from pointer range
results in horrible codegen
Product: libc++
Version: unspecified
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: unassignedclangbugs at nondot.org
Reporter: arseny.kapoulkine at gmail.com
CC: llvmbugs at cs.uiuc.edu, mclow.lists at gmail.com
Classification: Unclassified
Using clang from Xcode 6 Beta 3:
Apple LLVM version 6.0 (clang-600.0.38) (based on LLVM 3.5svn)
Compiling the following code:
std::vector build(const char* data, size_t size) { return
std::vector(data, data + size); }
Results in the assembly with *this* as an inner loop (clang++ -O3):
LBB0_5: ## =>This Inner Loop Header: Depth=1
testq %rcx, %rcx
movl $0, %eax
je LBB0_7
## BB#6: ## in Loop: Header=BB0_5 Depth=1
movb (%rbx), %al
movb %al, (%rcx)
movq 8(%r14), %rax
LBB0_7: ##
%_ZNSt3__116allocator_traitsINS_9allocatorIcEEE9constructIccEEvRS2_PT_RKT0_.exit.i.i.i
## in Loop: Header=BB0_5 Depth=1
incq %rax
movq %rax, 8(%r14)
incq %rbx
decq %r15
movq %rax, %rcx
jne LBB0_5
With -stdlib=libstdc++ I get "callq _memcpy" instead.
Changing libc++ sources to hoist __end_ into a local does not help very much -
it removes redundant load/store instructions for __end_ but the loop is still
there.
Also I'm not sure why "decq %r15" is here - as far as I can see compiler should
have removed it. Can someone confirm that this part looks like a separate
optimization issue and warrants filing a separate LLVM bug?
Full disassembly dump attached.
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From bugzilla-daemon at llvm.org Tue Sep 2 01:40:18 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 02 Sep 2014 08:40:18 +0000
Subject: [LLVMbugs] [Bug 20832] New: APFloat::fusedMultiplyAdd is broken
when addend is
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=20832
Bug ID: 20832
Summary: APFloat::fusedMultiplyAdd is broken when addend is 0
Product: libraries
Version: trunk
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Support Libraries
Assignee: unassignedbugs at nondot.org
Reporter: greg_bedwell at sn.scee.net
CC: llvmbugs at cs.uiuc.edu
Classification: Unclassified
I believe the following testcase demonstrates a bug in
APFloat::fusedMultiplyAdd. I would expect this to produce a result of 56
((7*8)+0) but instead it produces 7. The addend being 0 seems to be the key.
----------------------------------------------------------------------
declare double @llvm.fma.f64(double, double, double) nounwind
define double @_Z4testv() nounwind {
%1 = call double @llvm.fma.f64(double 7.000000e+00, double 8.000000e+00,
double 0.000000e+00)
ret double %1
}
----------------------------------------------------------------------
Using r216885:
llc test.ll -mtriple=x86_64-unknown-unknown -o -
we get the following constant generated:
.quad 4619567317775286272 # double 7
Within the function APFloat::fusedMultiplyAdd it calls multiplySpecials which
returns opOK allowing the call to addOrSubtract to occur, however at no point
is the actual multiplication performed, meaning that we essentially do 7+0,
ignoring the multiplicand entirely.
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From bugzilla-daemon at llvm.org Tue Sep 2 04:23:22 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 02 Sep 2014 11:23:22 +0000
Subject: [LLVMbugs] [Bug 20830] std::vector ctor for POD type from pointer
range results in horrible codegen
In-Reply-To:
References:
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=20830
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 seems to be a duplicate of bug 20831
*** This bug has been marked as a duplicate of bug 20831 ***
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From bugzilla-daemon at llvm.org Tue Sep 2 06:04:45 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 02 Sep 2014 13:04:45 +0000
Subject: [LLVMbugs] [Bug 20833] New: Crash on invalid
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=20833
Bug ID: 20833
Summary: Crash on invalid
Product: clang
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: C++
Assignee: unassignedclangbugs at nondot.org
Reporter: klimek at google.com
CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
Classification: Unclassified
Created attachment 12974
--> http://llvm.org/bugs/attachment.cgi?id=12974&action=edit
Crash report
$ cat /tmp/t.cc
template
struct A {
T t;
};
template
void g(F f) {
auto a = A{};
auto xf = [a, f]() {};
int x = sizeof(xf);
};
void f() {
g([] {});
}
See attached crash report.
$ cat /tmp/crash-report
/tmp/t.cc:3:5: error: field has incomplete type 'void'
T t;
^
/tmp/t.cc:7:12: note: in instantiation of template class 'A' requested
here
auto a = A{};
^
/tmp/t.cc:12:3: note: in instantiation of function template specialization
'g<(lambda at /tmp/t.cc:12:5)>' requested here
g([] {});
^
clang-3.5:
/usr/local/google/home/klimek/src/llvm/tools/clang/lib/AST/ASTContext.cpp:1694:
clang::TypeInfo clang::ASTContext::getTypeInfoImpl(const clang::Type *) const:
Assertion `!A->getDeducedType().isNull() && "cannot request the size of an
undeduced or dependent auto type"' failed.
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From bugzilla-daemon at llvm.org Tue Sep 2 06:31:04 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 02 Sep 2014 13:31:04 +0000
Subject: [LLVMbugs] [Bug 20833] Crash on invalid
In-Reply-To:
References:
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=20833
Alexander Kornienko changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
CC| |alexfh at google.com
Resolution|--- |DUPLICATE
--- Comment #1 from Alexander Kornienko ---
*** This bug has been marked as a duplicate of bug 20731 ***
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From bugzilla-daemon at llvm.org Tue Sep 2 06:31:19 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 02 Sep 2014 13:31:19 +0000
Subject: [LLVMbugs] [Bug 20745] Assertion `!A->getDeducedType().isNull() &&
"cannot request the size of an undeduced or dependent auto type"'
In-Reply-To:
References:
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=20745
Alexander Kornienko changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |DUPLICATE
--- Comment #2 from Alexander Kornienko ---
*** This bug has been marked as a duplicate of bug 20731 ***
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From bugzilla-daemon at llvm.org Tue Sep 2 08:47:48 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 02 Sep 2014 15:47:48 +0000
Subject: [LLVMbugs] [Bug 20834] New: is_trivially_destructible yields wrong
value for arrays of unknown bound
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=20834
Bug ID: 20834
Summary: is_trivially_destructible yields wrong value for
arrays of unknown bound
Product: libc++
Version: unspecified
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: unassignedclangbugs at nondot.org
Reporter: kaballo86 at hotmail.com
CC: llvmbugs at cs.uiuc.edu, mclow.lists at gmail.com
Classification: Unclassified
std::is_trivially_destructible::value is true, but arrays of unknown bound
are incomplete object types and so std::is_destructible::value is false.
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From bugzilla-daemon at llvm.org Tue Sep 2 08:54:44 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 02 Sep 2014 15:54:44 +0000
Subject: [LLVMbugs] [Bug 20835] New: llc -march=cpp doesn't work well with
strings containing '\0'
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=20835
Bug ID: 20835
Summary: llc -march=cpp doesn't work well with strings
containing '\0'
Product: tools
Version: trunk
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: llc
Assignee: unassignedbugs at nondot.org
Reporter: virgile.bello at gmail.com
CC: llvmbugs at cs.uiuc.edu
Classification: Unclassified
Example:
static const UTF8 firstByteMark[7] = { 0x00, 0x00, 0xC0, 0xE0, 0xF0, 0xF8, 0xFC
};
gets converted to:
Constant *const_array_80 = ConstantDataArray::getString(mod->getContext(),
"\x00\x00\xC0\xE0\xF0\xF8\xFC", false);
However, since StringRef will implicitely do a strlen, it will thinks it's a
zero sized string. As a result, it fails later because global and constant
types don't match.
Calling StringRef with explicit size should fix the issue:
Constant *const_array_80 = ConstantDataArray::getString(mod->getContext(),
StringRef("\x00\x00\xC0\xE0\xF0\xF8\xFC", 7), false);
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From bugzilla-daemon at llvm.org Tue Sep 2 09:03:46 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 02 Sep 2014 16:03:46 +0000
Subject: [LLVMbugs] [Bug 20821] clang-cl doesn't accept two implicit
conversions with a smart pointer pattern in the same way that MSVC does
In-Reply-To:
References:
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=20821
Hans Wennborg changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |WONTFIX
--- Comment #1 from Hans Wennborg ---
> It seems like MSVC first invokes SP::operator T*() and then invokes the ctor taking the T* from it, which requires another implicit conversion from D* to B*. I don't think this is valid C++, but we may want to support it for compat with MSVC.
I'm surprised that they allow that (it seems to compile with the 14 CTP too).
Unless we really can't avoid it, I don't think we should support this.
For smart pointers, I think the common thing to do is to provide templates for
converting copy constructors and assignment operators, something like:
template SP {
...
template SP(SP other) { ... }
template void operator=(SP other);
}
I'll mark this wontfix for now.
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From bugzilla-daemon at llvm.org Tue Sep 2 09:20:11 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 02 Sep 2014 16:20:11 +0000
Subject: [LLVMbugs] [Bug 20834] is_trivially_destructible yields wrong value
for arrays of unknown bound
In-Reply-To:
References:
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=20834
Marshall Clow (home) changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |FIXED
Assignee|unassignedclangbugs at nondot. |mclow.lists at gmail.com
|org |
--- Comment #1 from Marshall Clow (home) ---
Fixed in revision 216909.
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From bugzilla-daemon at llvm.org Tue Sep 2 09:22:52 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 02 Sep 2014 16:22:52 +0000
Subject: [LLVMbugs] [Bug 19798] licm crash
In-Reply-To:
References:
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=19798
David Majnemer changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |FIXED
Assignee|amara.emerson at gmail.com |david.majnemer at gmail.com
--- Comment #5 from David Majnemer ---
Fixed in r216911.
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From bugzilla-daemon at llvm.org Tue Sep 2 09:28:58 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 02 Sep 2014 16:28:58 +0000
Subject: [LLVMbugs] [Bug 19670] wrong code at -O2 on x86_64-linux-gnu
(affecting trunk and 3.4) (indvars, nuw)
In-Reply-To:
References:
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=19670
David Majnemer changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
CC| |david.majnemer at gmail.com
Resolution|--- |WORKSFORME
--- Comment #5 from David Majnemer ---
As of r216911, I see the following:
cond.false.i.i.i: ; preds = %for.inc.split.i.i
%add.i.i.i = add nsw i32 %j.0.ph.i.i, 1
br label %for.cond.outer.i.i
The program doesn't infloop on -O3.
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From bugzilla-daemon at llvm.org Tue Sep 2 09:34:37 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 02 Sep 2014 16:34:37 +0000
Subject: [LLVMbugs] [Bug 17794] wrong code at -O2 on x86_64-linux-gnu
(generated code hangs)
In-Reply-To:
References:
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=17794
David Majnemer changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|REOPENED |RESOLVED
CC| |david.majnemer at gmail.com
Resolution|--- |WORKSFORME
--- Comment #5 from David Majnemer ---
Works for me on r216911. Neither test case results in a hang.
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From bugzilla-daemon at llvm.org Tue Sep 2 10:36:14 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 02 Sep 2014 17:36:14 +0000
Subject: [LLVMbugs] [Bug 20836] New: Missing const in
is_copy_constructible/assignable
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=20836
Bug ID: 20836
Summary: Missing const in is_copy_constructible/assignable
Product: libc++
Version: unspecified
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: unassignedclangbugs at nondot.org
Reporter: kaballo86 at hotmail.com
CC: llvmbugs at cs.uiuc.edu, mclow.lists at gmail.com
Classification: Unclassified
Created attachment 12977
--> http://llvm.org/bugs/attachment.cgi?id=12977&action=edit
proposed fix
The implementations of copy-constructible/assignable related traits apply const
to a reference type, which is ignored. This results in the following assertions
firing when they should hold:
#include
struct T {
T(T&) = default;
T& operator=(T&) = default;
};
int main() {
static_assert(!std::is_copy_assignable::value, "is_copy_assignable");
static_assert(!std::is_nothrow_copy_assignable::value,
"is_nothrow_copy_assignable");
static_assert(!std::is_copy_constructible::value,
"is_copy_constructible");
static_assert(!std::is_nothrow_copy_constructible::value,
"is_nothrow_copy_constructible");
}
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From bugzilla-daemon at llvm.org Tue Sep 2 11:40:12 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 02 Sep 2014 18:40:12 +0000
Subject: [LLVMbugs] [Bug 20837] New: libc++ std::sort has O(n^2) worst case,
standard mandates O(N log(N))
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=20837
Bug ID: 20837
Summary: libc++ std::sort has O(n^2) worst case, standard
mandates O(N log(N))
Product: libc++
Version: unspecified
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: unassignedclangbugs at nondot.org
Reporter: orsonpeters at gmail.com
CC: llvmbugs at cs.uiuc.edu, mclow.lists at gmail.com
Classification: Unclassified
Created attachment 12978
--> http://llvm.org/bugs/attachment.cgi?id=12978&action=edit
Evidence for quadratic worst case.
The C++ standard mandates that `std::sort` has complexity O(N log(N)), but
libc++'s implementation takes O(N^2) in the worst case.
As proof I've attached a program that constructs a worst case input for several
sizes. It also instruments the number of comparisons used to sort these worst
cases and prints the results. The technique used is described in the 1999 paper
"A Killer Adversary for Quicksort" by M. D. McIlroy.
Compiling and running:
$ clang++ -O2 -m64 -march=native -std=c++11 -stdlib=libc++ main.cpp
-nodefaultlibs -lc++ -lc++abi -lm -lc -lgcc_s -lgcc && ./a.out
N: comparisons
100: 2479
200: 10229
400: 40729
800: 161729
1600: 448698
3200: 1413898
6400: 5264298
This is clearly quadratic. To illustrate this defect more, these are the
comparison counts given by compiling using libstdc++:
$ clang++ -O2 -m64 -march=native -std=c++11 main.cpp && ./a.out
N: comparisons
100: 1742
200: 4260
400: 10035
800: 22784
1600: 51049
3200: 112386
6400: 244850
Inspecting the source of shows the cause of the issue: there is no
introsort implemented, only quicksort (albeit with non-trivial optimizations,
but nothing preventing the worst case). I've written a patch that augments the
current implementation to make it work as an introspective sort, switching to
heapsort if the recursion depth exceeds 2*floor(log(N)). This post can only
have one attachment, so I'll post it as an attachment to a comment.
Having not contributed to libc++ before I'm not 100% familiar with all coding
styles/(un)written rules. My changes are rather minimal though, so I've just
followed what style could be found in context. And of course I knowingly submit
my code under the libc++ licenses, the MIT license and the UIUC License.
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From bugzilla-daemon at llvm.org Tue Sep 2 11:41:30 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 02 Sep 2014 18:41:30 +0000
Subject: [LLVMbugs] [Bug 20775] AArch64: crash in performSelectCombine()
In-Reply-To:
References:
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=20775
Jim Grosbach changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #4 from Jim Grosbach ---
Confirmed this is working as of r216725 & r216734. Thanks, Tim.
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From bugzilla-daemon at llvm.org Tue Sep 2 12:30:55 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 02 Sep 2014 19:30:55 +0000
Subject: [LLVMbugs] [Bug 20828] Regression(216780): Assertion failed:
MRI->getVRegDef(reg) && "Register use before def!",
file llvm\lib\CodeGen\LiveVariables.cpp, line 133
In-Reply-To:
References:
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=20828
Reid Kleckner changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #10 from Reid Kleckner ---
Fixed in r216929.
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From bugzilla-daemon at llvm.org Tue Sep 2 12:46:13 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 02 Sep 2014 19:46:13 +0000
Subject: [LLVMbugs] [Bug 20731] Assertion failure when taking the size of
ill-formed lambda
In-Reply-To:
References:
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=20731
rtrieu at google.com changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #3 from rtrieu at google.com ---
Fixed in r216936
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From bugzilla-daemon at llvm.org Tue Sep 2 13:17:35 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 02 Sep 2014 20:17:35 +0000
Subject: [LLVMbugs] [Bug 20825] "extern template" seems to invoke explicit
instanciation but it should prohibit it.
In-Reply-To:
References:
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=20825
Reid Kleckner changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
CC| |rnk at google.com
Resolution|--- |INVALID
--- Comment #1 from Reid Kleckner ---
I think you can forward declare your specialization of the static data member
like so:
// Start .h
template class A {
public:
static const char *info;
};
template <> const char *A::info;
template <> const char *A::info;
extern template class A;
extern template class A;
// Start .cpp
#include
template <> const char *A::info = "This is int";
template <> const char *A::info = "This is char";
int main(int, char **) {
std::cout << "A:" << A::info << "\n";
std::cout << "A:" << A::info << "\n";
return 0;
}
template class A;
template class A;
----
Otherwise, the compiler can do things like inline the generic, unspecialized
version of an inline function into your program. Consider:
template
struct A { static int f() { return sizeof(int); } };
extern template struct A;
int main() {
return A::f();
}
After optimizations, main will return 4, even if some other TU contains:
template <> int A::f() { return 5; };
This specialization can be similarly forward declared as:
template <> int A::f();
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From bugzilla-daemon at llvm.org Tue Sep 2 14:07:51 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 02 Sep 2014 21:07:51 +0000
Subject: [LLVMbugs] [Bug 20838] New: assertion "Leftover temporaries in
function" triggered on calls which may throw
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=20838
Bug ID: 20838
Summary: assertion "Leftover temporaries in function" triggered
on calls which may throw
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: compnerd at compnerd.org
CC: llvmbugs at cs.uiuc.edu
Classification: Unclassified
Created attachment 12980
--> http://llvm.org/bugs/attachment.cgi?id=12980&action=edit
reduced.mm
This occurs with 3.4 and current trunk. If you have a complex statement, e.g.
a stack block and an implicit conversion which may throw an exception, the
temporary value cleanup is not triggered, resulting in an assertion triggering.
The reduced test case demonstrates this.
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From bugzilla-daemon at llvm.org Tue Sep 2 14:37:45 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 02 Sep 2014 21:37:45 +0000
Subject: [LLVMbugs] [Bug 20839] New: Build fails (something related to mutex)
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=20839
Bug ID: 20839
Summary: Build fails (something related to mutex)
Product: libc++
Version: unspecified
Hardware: Macintosh
OS: MacOS X
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: unassignedclangbugs at nondot.org
Reporter: chisophugis at gmail.com
CC: llvmbugs at cs.uiuc.edu, mclow.lists at gmail.com
Classification: Unclassified
Created attachment 12981
--> http://llvm.org/bugs/attachment.cgi?id=12981&action=edit
The build errors that I'm seeing.
I'm seeing these errors when building on mac at r216561
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From bugzilla-daemon at llvm.org Tue Sep 2 14:58:03 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 02 Sep 2014 21:58:03 +0000
Subject: [LLVMbugs] [Bug 20839] Build fails (something related to mutex)
In-Reply-To:
References:
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=20839
Jonathan Roelofs changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
CC| |jonathan at codesourcery.com
Resolution|--- |FIXED
--- Comment #3 from Jonathan Roelofs ---
Oops, my fault. Fixed in r216975.
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From bugzilla-daemon at llvm.org Tue Sep 2 15:19:17 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 02 Sep 2014 22:19:17 +0000
Subject: [LLVMbugs] [Bug 20653] MS ABI: Mangling collision for pointers to
virtual member functions of multiple inheritance classes
In-Reply-To:
References:
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=20653
Reid Kleckner changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #1 from Reid Kleckner ---
Fixed in r216782.
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From bugzilla-daemon at llvm.org Tue Sep 2 15:19:18 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 02 Sep 2014 22:19:18 +0000
Subject: [LLVMbugs] [Bug 12477] [meta] Support Microsoft C++ ABI
In-Reply-To:
References:
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=12477
Bug 12477 depends on bug 20653, which changed state.
Bug 20653 Summary: MS ABI: Mangling collision for pointers to virtual member functions of multiple inheritance classes
http://llvm.org/bugs/show_bug.cgi?id=20653
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:
From bugzilla-daemon at llvm.org Tue Sep 2 15:19:19 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 02 Sep 2014 22:19:19 +0000
Subject: [LLVMbugs] [Bug 18887] [META] Compiling Chromium on Windows with
clang-cl
In-Reply-To:
References:
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=18887
Bug 18887 depends on bug 20653, which changed state.
Bug 20653 Summary: MS ABI: Mangling collision for pointers to virtual member functions of multiple inheritance classes
http://llvm.org/bugs/show_bug.cgi?id=20653
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:
From bugzilla-daemon at llvm.org Tue Sep 2 15:46:36 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 02 Sep 2014 22:46:36 +0000
Subject: [LLVMbugs] [Bug 17281] relaxed atomic operations lead to vastly
inefficient code
In-Reply-To:
References:
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=17281
Robin Morisset changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution|--- |FIXED
--- Comment #3 from Robin Morisset ---
Fixed by:
http://reviews.llvm.org/D4797
http://reviews.llvm.org/D4796
(which just landed).
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From bugzilla-daemon at llvm.org Tue Sep 2 23:09:48 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 03 Sep 2014 06:09:48 +0000
Subject: [LLVMbugs] [Bug 20840] New: Clang autoconf build doesn't generate
PROFILE-PIC version of compiler-rt
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=20840
Bug ID: 20840
Summary: Clang autoconf build doesn't generate PROFILE-PIC
version of compiler-rt
Product: compiler-rt
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Keywords: compile-fail
Severity: normal
Priority: P
Component: compiler-rt
Assignee: unassignedbugs at nondot.org
Reporter: alaviss0 at gmail.com
CC: llvmbugs at cs.uiuc.edu
Classification: Unclassified
Overview:
Building LLVM/Clang with GNU autoconf (./configure) doesn't generate
libclang_rt.profile-pic-x86_64.a needed for clang to link with
"-fprofile-instr-generate -fPIC"
Steps to Reproduce:
1) Compile LLVM/clang with GNU autoconf, below is the options I've used
./configure \
--prefix=/usr \
--sysconfdir=/etc \
--enable-shared \
--enable-libffi \
--enable-targets=all \
--disable-expensive-checks \
--disable-debug-runtime \
--disable-assertions \
--with-binutils-include=/usr/include \
--with-python=/usr/bin/python2 \
--enable-cxx1y --enable-libcpp \
--enable-optimized
2) Build an library with {C,CXX}FLAGS="-fprofile-instr-generate"
Expected Results:
Build successful with no problems
Actual Results:
Build failed, GNU ld error:
/usr/bin/ld: error: cannot open
/usr/bin/../lib/clang/3.6.0/lib/linux/libclang_rt.profile-pic-x86_64.a: No such
file or directory
Additional Information: libclang_rt.profile-pic-x86_64.a presents in cmake
build
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From bugzilla-daemon at llvm.org Tue Sep 2 23:58:53 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 03 Sep 2014 06:58:53 +0000
Subject: [LLVMbugs] [Bug 18364] LLVM+Clang emits movw instruction with
-march=armv5te.
In-Reply-To:
References:
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=18364
Dimitry Andric changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #6 from Dimitry Andric ---
Fixed in r216989 (plus followup r216990).
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From bugzilla-daemon at llvm.org Wed Sep 3 10:43:04 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 03 Sep 2014 17:43:04 +0000
Subject: [LLVMbugs] [Bug 20802] [SLP vectorizer] fast-math and wrap/exact
flags are not preserved
In-Reply-To:
References:
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=20802
Sanjay Patel changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #12 from Sanjay Patel ---
Patch checked in at:
http://llvm.org/viewvc/llvm-project?view=revision&revision=217051
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From bugzilla-daemon at llvm.org Wed Sep 3 12:16:24 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 03 Sep 2014 19:16:24 +0000
Subject: [LLVMbugs] [Bug 18950] Clang does not emit
DW_TAG_unspecified_parameters for varargs function
In-Reply-To:
References:
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=18950
Adrian Prantl changed:
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:
From bugzilla-daemon at llvm.org Wed Sep 3 12:26:03 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 03 Sep 2014 19:26:03 +0000
Subject: [LLVMbugs] [Bug 17611] Emit cmpxchg16b loops for i128 atomicrmw
instructions when mattr=+cx16
In-Reply-To:
References:
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=17611
Robin Morisset changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
CC| |morisset at google.com
Resolution|--- |FIXED
--- Comment #1 from Robin Morisset ---
I just tried this, and llvm emits the expected code with cmpxchg16b.
It has probably been fixed at some point during the year since this bug was
filed.
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From bugzilla-daemon at llvm.org Wed Sep 3 13:10:47 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 03 Sep 2014 20:10:47 +0000
Subject: [LLVMbugs] [Bug 20355] wrong code at -O2 and -O3 on
x86_64-linux-gnu (codegen)
In-Reply-To:
References:
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=20355
Sanjay Patel changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|REOPENED |RESOLVED
Resolution|--- |FIXED
--- Comment #14 from Sanjay Patel ---
The mask was fixed in:
http://llvm.org/viewvc/llvm-project?view=revision&revision=215604
Resolving as fixed.
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From bugzilla-daemon at llvm.org Wed Sep 3 16:05:32 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 03 Sep 2014 23:05:32 +0000
Subject: [LLVMbugs] [Bug 20680] wrong code at -O3 on x86_64-linux-gnu (wrong
nuw before indvars)
In-Reply-To:
References:
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=20680
David Majnemer changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |FIXED
Assignee|unassignedclangbugs at nondot. |david.majnemer at gmail.com
|org |
--- Comment #3 from David Majnemer ---
Sanjay, your analysis was spot on.
indvars was trying to optimize the loop exit condition by using the
post-incremented induction variable. However, this is unsafe if the incremented
value has wrapping flags as it could be poison.
Fixed in r217102.
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From bugzilla-daemon at llvm.org Wed Sep 3 16:12:20 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 03 Sep 2014 23:12:20 +0000
Subject: [LLVMbugs] [Bug 20816] serialization::isRedeclarableDeclKind has
three incosistencies with actual inheritance
In-Reply-To:
References:
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=20816
Richard Smith changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
CC| |richard-llvm at metafoo.co.uk
Resolution|--- |FIXED
--- Comment #1 from Richard Smith ---
As of r217103, NamespaceAliasDecl is Redeclarable, as it should be. The other
two are correct; they inherit from VarDecl, which in general is Redeclarable,
but those two forms of VarDecl are not actually redeclarable.
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From bugzilla-daemon at llvm.org Wed Sep 3 16:30:32 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 03 Sep 2014 23:30:32 +0000
Subject: [LLVMbugs] [Bug 20829] Initialization of union type
In-Reply-To:
References:
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=20829
Richard Smith changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
CC| |richard-llvm at metafoo.co.uk
Resolution|--- |INVALID
--- Comment #1 from Richard Smith ---
Neither of the quoted portions of the C standard seem relevant; there are no
members corresponding to padding, unnamed or otherwise.
The relevant section is:
6.2.6.1/6: "When a value is stored in an object of structure or union type,
including in a member object, the bytes of the object representation that
correspond to any padding bytes take unspecified values."
6.2.6.1/7: "When a value is stored in a member of an object of union type, the
bytes of the object representation that do not correspond to that member but do
correspond to other members take unspecified values."
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From bugzilla-daemon at llvm.org Wed Sep 3 16:34:06 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 03 Sep 2014 23:34:06 +0000
Subject: [LLVMbugs] [Bug 20841] New: LLVM fails to use flags from atomic
instructions
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=20841
Bug ID: 20841
Summary: LLVM fails to use flags from atomic instructions
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Backend: X86
Assignee: unassignedbugs at nondot.org
Reporter: david.majnemer at gmail.com
CC: llvmbugs at cs.uiuc.edu
Classification: Unclassified
consider:
define zeroext i1 @f(i32* %x) {
entry:
%0 = atomicrmw add i32* %x, i32 1 seq_cst
%cmp = icmp ne i32 %0, 0
ret i1 %cmp
}
this gets CodeGen'd as:
movl $1, %eax
lock
xaddl %eax, (%rdi)
testl %eax, %eax
setne %al
retq
Note that the ZF flag was already set from the xadd instruction, the test
instruction is redundant.
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From bugzilla-daemon at llvm.org Wed Sep 3 17:07:14 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 04 Sep 2014 00:07:14 +0000
Subject: [LLVMbugs] [Bug 19428] intrinsic function __sync_lock_test_and_set
does not generate code for int128
In-Reply-To:
References:
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=19428
Robin Morisset changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
CC| |morisset at google.com
Resolution|--- |FIXED
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From bugzilla-daemon at llvm.org Wed Sep 3 18:14:08 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 04 Sep 2014 01:14:08 +0000
Subject: [LLVMbugs] [Bug 20842] New: clang -fsanitize=address is extremely
slow on unittests/Support/ConvertUTFTest.cpp
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=20842
Bug ID: 20842
Summary: clang -fsanitize=address is extremely slow on
unittests/Support/ConvertUTFTest.cpp
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: C++
Assignee: unassignedclangbugs at nondot.org
Reporter: vonosmas at gmail.com
CC: dgregor at apple.com, kcc at google.com,
llvmbugs at cs.uiuc.edu
Classification: Unclassified
ASan bootstrap on the buildbot is currently broken because the compilation of
unittests/Support/ConvertUTFTest.cpp times out.
The guilty pass is MachineSinking::runOnMachineFunction()
The source file in question has 1500-line function with hundreds of EXPECT_TRUE
statements. I haven't yet figured out what change slowed things down that
significantly.
To reproduce, build LLVM with clang as a host compiler and
-DCMAKE_BUILD_TYPE=Release -DLLVM_USE_SANITIZER=Address and run "make
check-llvm"
(or just use preprocessed .cpp and .sh file attached).
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From bugzilla-daemon at llvm.org Thu Sep 4 03:51:52 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 04 Sep 2014 10:51:52 +0000
Subject: [LLVMbugs] [Bug 20843] New: binomial_distribution is
broken.
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=20843
Bug ID: 20843
Summary: binomial_distribution is broken.
Product: libc++
Version: 3.4
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: unassignedclangbugs at nondot.org
Reporter: ineaugh at gmail.com
CC: llvmbugs at cs.uiuc.edu, mclow.lists at gmail.com
Classification: Unclassified
The binomial_distribution class from must allow any of the following
types as result_type, required by the c++ standard: short, int, long, long
long, unsigned short, unsigned int, unsigned long, or unsigned long long.
However, when binomial_distribution is used, it will often return
values outside of its supposed range, which are in fact -2 casted to the
unsigned type.
Note that using unsigned types with binomial_distribution makes sense, because
its result must never be negative.
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From bugzilla-daemon at llvm.org Thu Sep 4 04:56:31 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 04 Sep 2014 11:56:31 +0000
Subject: [LLVMbugs] [Bug 20746] clang fails to parse mingw-w64's secure api
headers (cannot add 'dllimport' attribute)
In-Reply-To:
References:
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=20746
Thomas Pöchtrager changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|FIXED |---
--- Comment #5 from Thomas Pöchtrager ---
Has this been forgotten to be merged into the 3.5 branch?
I am still getting errors with the latest 3.5 sources.
$ clang -v
clang version 3.5.0 (217142)
$ clang [...] test.i
In file included from test.c:2:
In file included from /opt/other/mingw/i686-w64-mingw32/include/conio.h:125:
/opt/other/mingw/i686-w64-mingw32/include/sec_api/conio_s.h:30:70: error:
redeclaration of '_cgetws_s' cannot add 'dllimport' attribute
__attribute__ ((__dllimport__)) errno_t __attribute__((__cdecl__)) _cgetws_s
(wchar_t *_Buffer,size_t _SizeInWords,size_t *_SizeRead);
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From bugzilla-daemon at llvm.org Thu Sep 4 05:02:16 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 04 Sep 2014 12:02:16 +0000
Subject: [LLVMbugs] [Bug 20746] clang fails to parse mingw-w64's secure api
headers (cannot add 'dllimport' attribute)
In-Reply-To:
References:
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=20746
Anton Korobeynikov changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|REOPENED |RESOLVED
CC| |asl at math.spbu.ru
Resolution|--- |FIXED
--- Comment #6 from Anton Korobeynikov ---
It was not forgotten. The change happened long after 3.5 was branched and since
it's not a regression, it will be included into 3.6
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From bugzilla-daemon at llvm.org Thu Sep 4 05:08:03 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 04 Sep 2014 12:08:03 +0000
Subject: [LLVMbugs] [Bug 20746] clang fails to parse mingw-w64's secure api
headers (cannot add 'dllimport' attribute)
In-Reply-To:
References:
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=20746
Thomas Pöchtrager changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|FIXED |---
--- Comment #7 from Thomas Pöchtrager ---
Yes I know it's fixed in 3.6, but shouldn't it be fixed in 3.5 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:
From bugzilla-daemon at llvm.org Thu Sep 4 05:23:16 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 04 Sep 2014 12:23:16 +0000
Subject: [LLVMbugs] [Bug 20746] clang fails to parse mingw-w64's secure api
headers (cannot add 'dllimport' attribute)
In-Reply-To:
References:
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=20746
Anton Korobeynikov changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|REOPENED |RESOLVED
Resolution|--- |FIXED
--- Comment #8 from Anton Korobeynikov ---
(In reply to comment #7)
> Yes I know it's fixed in 3.6, but shouldn't it be fixed in 3.5 as well?
No. As I said - the change was committed long after 3.5 was branched. There are
two reasons, why this won't go in 3.5:
1. It's not a regression wrt 3.4
2. It was already too late for any non-release-critical change to be included
into 3.5
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From bugzilla-daemon at llvm.org Thu Sep 4 05:54:49 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 04 Sep 2014 12:54:49 +0000
Subject: [LLVMbugs] [Bug 20844] New: Brace-init of non-const references
produces code that crashes
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=20844
Bug ID: 20844
Summary: Brace-init of non-const references produces code that
crashes
Product: clang
Version: 3.4
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: C++11
Assignee: unassignedclangbugs at nondot.org
Reporter: petar335335 at gmail.com
CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
Classification: Unclassified
Created attachment 12983
--> http://llvm.org/bugs/attachment.cgi?id=12983&action=edit
the program used to reproduce the bug
The attached program produces the following and crashes on Ubuntu LTS 14.04
AMD64:
-----------------------------------------------------------------
random value
65
Segmentation Fault
-----------------------------------------------------------------
If I remove the brace-init in the X's initializer list and replace it with
()-init, everything seems to work as expected.
Additionally, X x2{s()} produces the correct result even with brace-init.
Compiled with no warnings or errors:
clang++ brace_ref_init.cpp -o brace_ref_init -std=c++11
On gcc:
g++ brace_ref_init.cpp -o brace_ref_init -std=c++11
gcc doesn't compile it, saying:
-----------------------------------------------------------------
brace_ref_init.cpp: In instantiation of ‘X::X(T&) [with T = S]’:
brace_ref_init.cpp:39:17: required from here
brace_ref_init.cpp:27:18: error: invalid initialization of non-const reference
of type ‘D&’ from an rvalue of type ‘’
X(T& v) : d{v} {} // brace-init of d causes incorect behaviour
^
brace_ref_init.cpp: In instantiation of ‘X::X(T&) [with T = D]’:
brace_ref_init.cpp:40:19: required from here
brace_ref_init.cpp:27:18: error: invalid initialization of non-const reference
of type ‘D&’ from an rvalue of type ‘’
-----------------------------------------------------------------
GCC bug report that I think is related:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50025
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From bugzilla-daemon at llvm.org Thu Sep 4 05:58:09 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 04 Sep 2014 12:58:09 +0000
Subject: [LLVMbugs] [Bug 20845] New: TypedefDecl pointer from TypedefType
can point to uninstantiated template typedef
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=20845
Bug ID: 20845
Summary: TypedefDecl pointer from TypedefType can point to
uninstantiated template typedef
Product: clang
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
Assignee: unassignedclangbugs at nondot.org
Reporter: schindler at virtamed.com
CC: llvmbugs at cs.uiuc.edu
Classification: Unclassified
Consider the following code:
template class Test
{
typedef int size_type;
void function(size_type value) {}
};
Test instance;
When traversing the ast, I look at the CXXMethodDecl for
Test::function(...), I do the following:
auto param= decl->parameters()[0];
auto paramtype = param->getType();
TypedefType* td = paramtype.getTypePtr()->getAs();
TypedefDecl* tddecl = td->getDecl();
The problem is that tddecl points to the TypedefDecl within the context of
ClassTemplateTecl and not the specific TypedefDecl of the
ClasstemplateSpecializationDecl. In case the typedef is dependent as well, this
problem does not occur.
This is a problem because I have a clang-based tool where the context of the
TypedefDecl is important.
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From bugzilla-daemon at llvm.org Thu Sep 4 07:45:02 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 04 Sep 2014 14:45:02 +0000
Subject: [LLVMbugs] [Bug 20749] libc++ assumes too much about pthread_t
In-Reply-To:
References:
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=20749
Marshall Clow (home) changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |INVALID
--- Comment #10 from Marshall Clow (home) ---
Closing this bug.
Strictly speaking, a C++ library that uses pthreads *has* to use non-portable
methods; the C++ standard requires features that are not in the pthreads
specification.
Down the road, the implementation in libc++ may have to change to work with
other pthread implementations, but better there than in client code.
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From bugzilla-daemon at llvm.org Thu Sep 4 08:56:54 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 04 Sep 2014 15:56:54 +0000
Subject: [LLVMbugs] [Bug 20214] AddressSanitizer should support -MD on
Windows
In-Reply-To:
References:
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=20214
Timur Iskhodzhanov changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution|--- |FIXED
--- Comment #17 from Timur Iskhodzhanov ---
I've managed to run Chromium's chrome.exe with just one source file excluded
from the build due to a non-RTL bug (http://crbug.com/410839), thus I declare
RTL -MD working.
Please file separate PRs in case you have any problems.
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From bugzilla-daemon at llvm.org Thu Sep 4 09:35:34 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 04 Sep 2014 16:35:34 +0000
Subject: [LLVMbugs] [Bug 20847] New: variadic function with AMD64 abi and
windows calling convention
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=20847
Bug ID: 20847
Summary: variadic function with AMD64 abi and windows calling
convention
Product: clang
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: LLVM Codegen
Assignee: unassignedclangbugs at nondot.org
Reporter: maxime.madau at hp.com
CC: llvmbugs at cs.uiuc.edu
Classification: Unclassified
Created attachment 12986
--> http://llvm.org/bugs/attachment.cgi?id=12986&action=edit
test code
Hi,
Architecture: linux x86-64.
Compilation command line : clang hello.c -o hello
expected output: 1 2 3 4 5 6 7 8 9 10
output: 1 2 3 4 5 6 1 2 3 4 5 6 7 8 9 10
When using __attribute__((ms_abi)) on a variadic function with more than 6
arguments, the program will reiterate at the beginning of the argument passed
on the stack (test code attached).
Firstly, clang pushes all arguments after the first 6 arguments (creates the
register save area) in the stack before the base pointer. Then clang emits the
va_arg and va_list for System V AMD64 and thus instead of going on the stack
and accessing all arguments one-by-one like Microsoft calling convention does,
it goes through the stack until gp_offset is > 48 (e.g until the end of the
register save area, which is located before the base pointer in my program).
Finally, it reiterates starting from the beginning of the register save area.
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From bugzilla-daemon at llvm.org Thu Sep 4 11:16:46 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 04 Sep 2014 18:16:46 +0000
Subject: [LLVMbugs] [Bug 19667] Win64 binaries are undebuggable due to lack
of pdata unwind info
In-Reply-To:
References:
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=19667
Reid Kleckner changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #3 from Reid Kleckner ---
With r217178 and r217176 unwind info seems to work. I expect there are bugs,
but we'll file them separately.
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From bugzilla-daemon at llvm.org Thu Sep 4 13:32:37 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 04 Sep 2014 20:32:37 +0000
Subject: [LLVMbugs] [Bug 17201] MS inline assembly should assume asm block
sets the return value.
In-Reply-To:
References:
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=17201
Reid Kleckner changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #13 from Reid Kleckner ---
Fixed in r217187.
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From bugzilla-daemon at llvm.org Thu Sep 4 13:32:39 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 04 Sep 2014 20:32:39 +0000
Subject: [LLVMbugs] [Bug 13340] [Windows] Support MSVC __asm syntax
In-Reply-To:
References:
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=13340
Bug 13340 depends on bug 17201, which changed state.
Bug 17201 Summary: MS inline assembly should assume asm block sets the return value.
http://llvm.org/bugs/show_bug.cgi?id=17201
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:
From bugzilla-daemon at llvm.org Thu Sep 4 13:41:20 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 04 Sep 2014 20:41:20 +0000
Subject: [LLVMbugs] [Bug 20848] New: EngineBuilder setMCJITMemoryManager and
setJITMemoryManager
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=20848
Bug ID: 20848
Summary: EngineBuilder setMCJITMemoryManager and
setJITMemoryManager
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: yaron.keren at gmail.com
CC: llvmbugs at cs.uiuc.edu
Classification: Unclassified
Should setJITMemoryManager be eliminated, renamed or merged with
setMCJITMemoryManager?
it seems it is used not to provide a JIT memory manager (no JIT now) but to
install an alternative one which is used by MCJIT.
Same for MCJMM and JMM.
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From bugzilla-daemon at llvm.org Thu Sep 4 15:11:59 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 04 Sep 2014 22:11:59 +0000
Subject: [LLVMbugs] [Bug 20849] New: clang miscompiles basic C code
involving modulo at -O3
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=20849
Bug ID: 20849
Summary: clang miscompiles basic C code involving modulo at -O3
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
Assignee: unassignedclangbugs at nondot.org
Reporter: michaelni at gmx.at
CC: llvmbugs at cs.uiuc.edu
Classification: Unclassified
Created attachment 12987
--> http://llvm.org/bugs/attachment.cgi?id=12987&action=edit
testcase
the attached code when compiled with -O3
gives totally wrong output on x86_64
that is values larger than 126
version:
Ubuntu clang version 3.5.0-svn216089-1~exp1 (branches/release_35) (based on
LLVM 3.5.0)
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From bugzilla-daemon at llvm.org Thu Sep 4 15:14:58 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 04 Sep 2014 22:14:58 +0000
Subject: [LLVMbugs] [Bug 20844] C++11 uniform-init of non-const references
produces code that crashes
In-Reply-To:
References:
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=20844
Richard Smith changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #4 from Richard Smith ---
Fixed in r217197:
/usr/local/google/home/richardsmith/Downloads/brace_ref_init (1).cpp:27:17:
error: no viable conversion from 'S' to 'uint64_t' (aka 'unsigned long')
X(T& v) : d{v} {} // brace-init of d causes incorect behaviour
^
/usr/local/google/home/richardsmith/Downloads/brace_ref_init (1).cpp:39:13:
note: in instantiation of function template specialization 'X::X' requested
here
const X x1{s};
^
/usr/local/google/home/richardsmith/Downloads/brace_ref_init (1).cpp:15:5:
note: candidate function
operator D& () { return d; }
^
/usr/local/google/home/richardsmith/Downloads/brace_ref_init (1).cpp:16:5:
note: candidate function
operator const D& () const { return d; }
^
/usr/local/google/home/richardsmith/Downloads/brace_ref_init (1).cpp:32:8:
note: in initialization of temporary of type 'D' created to list-initialize
this
reference
D& d;
^
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From bugzilla-daemon at llvm.org Thu Sep 4 15:17:56 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 04 Sep 2014 22:17:56 +0000
Subject: [LLVMbugs] [Bug 18791] Naked attribute: clang emits extraneous,
stack-altering code for naked functions that have a parameter.
In-Reply-To:
References:
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=18791
Hans Wennborg changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #1 from Hans Wennborg ---
Should be fixed in r217198.
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From bugzilla-daemon at llvm.org Thu Sep 4 15:18:10 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 04 Sep 2014 22:18:10 +0000
Subject: [LLVMbugs] [Bug 20028] clang-cl adds an extra 'ret' to
__declspec(naked) functions
In-Reply-To:
References:
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=20028
Hans Wennborg changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #1 from Hans Wennborg ---
Should be fixed in r217198.
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From bugzilla-daemon at llvm.org Thu Sep 4 15:57:24 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 04 Sep 2014 22:57:24 +0000
Subject: [LLVMbugs] [Bug 20850] New: should be able to simplify vector loop
induction variables
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=20850
Bug ID: 20850
Summary: should be able to simplify vector loop induction
variables
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Loop Optimizer
Assignee: unassignedbugs at nondot.org
Reporter: richard-llvm at metafoo.co.uk
CC: llvmbugs at cs.uiuc.edu
Classification: Unclassified
Consider this testcase from PR20849:
#include
int main() {
int i;
unsigned char in[1000];
for (i = 0; i < 1000; i++)
in[i] = i % 127;
for (i = 0; i < 1000; i++)
printf("%d\n", in[i]);
return 0;
}
The first loop produces the following IR at -O3:
entry:
%in = alloca [1000 x i8], align 16
%0 = getelementptr inbounds [1000 x i8]* %in, i64 0, i64 0
call void @llvm.lifetime.start(i64 1000, i8* %0) #1
br label %vector.body
vector.body: ; preds = %vector.body,
%entry
%index = phi i64 [ 0, %entry ], [ %index.next, %vector.body ]
%1 = trunc i64 %index to i32
%broadcast.splatinsert22 = insertelement <4 x i32> undef, i32 %1, i32 0
%broadcast.splat23 = shufflevector <4 x i32> %broadcast.splatinsert22, <4 x
i32> undef, <4 x i32> zeroinitializer
%induction24 = add <4 x i32> %broadcast.splat23,
%induction25 = add <4 x i32> %broadcast.splat23,
%2 = srem <4 x i32> %induction24,
%3 = srem <4 x i32> %induction25,
%4 = trunc <4 x i32> %2 to <4 x i8>
%5 = trunc <4 x i32> %3 to <4 x i8>
%6 = getelementptr inbounds [1000 x i8]* %in, i64 0, i64 %index
%7 = bitcast i8* %6 to <4 x i8>*
store <4 x i8> %4, <4 x i8>* %7, align 8, !tbaa !1
%.sum26 = or i64 %index, 4
%8 = getelementptr [1000 x i8]* %in, i64 0, i64 %.sum26
%9 = bitcast i8* %8 to <4 x i8>*
store <4 x i8> %5, <4 x i8>* %9, align 4, !tbaa !1
%index.next = add i64 %index, 8
%10 = icmp eq i64 %index.next, 1000
br i1 %10, label %for.body3.preheader, label %vector.body, !llvm.loop !4
This is dumb. Instead of a broadcast and two adds in each iteration of the
loop, we should rewrite the loop to start at and
, and add 8 to each element on each iteration.
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From bugzilla-daemon at llvm.org Thu Sep 4 18:07:44 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 05 Sep 2014 01:07:44 +0000
Subject: [LLVMbugs] [Bug 20851] New: MCJIT is failing when used with more
that one module
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=20851
Bug ID: 20851
Summary: MCJIT is failing when used with more that one module
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Target-Independent JIT
Assignee: unassignedbugs at nondot.org
Reporter: deadalnix at gmail.com
CC: llvmbugs at cs.uiuc.edu
Classification: Unclassified
Sample code: http://pastebin.com/fL1yTVCk
Compilation: gcc fail.c -m64
`/Users/amaury/d/llvm/build/Debug+Asserts/bin/llvm-config --cflags`
`/Users/amaury/d/llvm/build/Debug+Asserts/bin/llvm-config --ldflags`
`/Users/amaury/d/llvm/build/Debug+Asserts/bin/llvm-config --libs` -lc++
-lncurses -lz
$ ./a.out
; ModuleID = 'm1'
; ModuleID = 'm2'
define i32 @foo() {
ret i32 42
}
Bus error: 10
Further exploration showed me that the failure happen when calling the Jitted
function. It look like the generated code is invalid.
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From bugzilla-daemon at llvm.org Thu Sep 4 21:00:21 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 05 Sep 2014 04:00:21 +0000
Subject: [LLVMbugs] [Bug 20852] New: slp-vectorize-aggressive causing
"Invalid Operands for Select"
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=20852
Bug ID: 20852
Summary: slp-vectorize-aggressive causing "Invalid Operands for
Select"
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Loop Optimizer
Assignee: unassignedbugs at nondot.org
Reporter: ryan.osial at gmail.com
CC: llvmbugs at cs.uiuc.edu
Classification: Unclassified
While compiling Firefox 32, found that -fslp-vectorize-aggressive caused an
error:
ryan at osnap-linux ~/projects/nobackup/llvm/git/llvm/build $
./Debug+Asserts/bin/clang++ /tmp/TiledContentClient.cpp -c
-fslp-vectorize-aggressive -pipe -march=native -fno-exceptions
-fno-strict-aliasing -fno-rtti -fno-exceptions -fno-math-errno -std=gnu++0x
-pthread -pipe -O2
../../dist/include/jspubtd.h:512:51: warning: offset of on non-standard-layout
type 'js::PerThreadDataFriendFields::RuntimeDummy' [-Winvalid-offsetof]
static const size_t RuntimeMainThreadOffset =
__builtin_offsetof(RuntimeDummy, mainThread);
Invalid operands for select instruction!
%.retval.sroa.6.12.vec.insert.i75 = select <2 x i1> %or.cond.i74, <4 x float>
zeroinitializer, <4 x float> %sub.i62
fatal error: error in backend: Broken function found, compilation aborted!
clang: error: clang frontend command failed with exit code 70 (use -v to see
invocation)
clang version 3.6.0 (http://llvm.org/git/clang.git
77f909b268d79378221b4163112596afe177d177) (http://llvm.org/git/llvm.git
b20b9bf9fd60ba1d769e33ff6680099473d59a7d)
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:
From bugzilla-daemon at llvm.org Fri Sep 5 01:12:11 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 05 Sep 2014 08:12:11 +0000
Subject: [LLVMbugs] [Bug 20853] New: ARM: Negative offset support problem
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=20853
Bug ID: 20853
Summary: ARM: Negative offset support problem
Product: tools
Version: trunk
Hardware: Other
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: llc
Assignee: unassignedbugs at nondot.org
Reporter: ioblakov at dev.rtsoft.ru
CC: llvmbugs at cs.uiuc.edu
Classification: Unclassified
Created attachment 12990
--> http://llvm.org/bugs/attachment.cgi?id=12990&action=edit
Test
ARM compiler can use negative offset (imm12) only for a frame access.
The following example (n.c) shows problem:
int sum(int *p)
{
return p[-4] + p[-2] + p[0] + p[2] + p[4];
}
clang --target=arm -mcpu=cortex-a9 -S -mfloat-abi=soft -O3 n.c
sum:
sub r1, r0, #16 <<< instead of using [r0, #-16] to load a p[-4]
sub r2, r0, #8 <<< instead of using [r0, #-8] to load a p[-2]
ldr r1, [r1]
ldr r2, [r2]
ldr r3, [r0, #8]
add r1, r2, r1
ldr r2, [r0]
ldr r0, [r0, #16]
add r1, r1, r2
add r1, r1, r3
add r0, r1, r0
bx lr
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From bugzilla-daemon at llvm.org Fri Sep 5 04:45:31 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 05 Sep 2014 11:45:31 +0000
Subject: [LLVMbugs] [Bug 20854] New: Template instantiation fails with
undefined reference
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=20854
Bug ID: 20854
Summary: Template instantiation fails with undefined reference
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: C++
Assignee: unassignedclangbugs at nondot.org
Reporter: wpoely86 at gmail.com
CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
Classification: Unclassified
Created attachment 12992
--> http://llvm.org/bugs/attachment.cgi?id=12992&action=edit
The example that fails
I've make a small piece of code (see attachment) that compiles fine with GCC
4.9.1 and icpc-2015.0.090 but not with Clang-3.5.
I've split up the definition and declaration of a template class in the usual
way: in the cpp file, all templates used have been explicitly Instantiation.
If you put everything in the header, everything works fine.
Clang fails with undefined reference to the template class. If I look at the
symbols in the object file generated by Clang and GCC:
GCC:
0000000000000000 W BlockStructure::BlockStructure(int)
0000000000000000 W BlockStructure::BlockStructure(int)
0000000000000000 n _ZN14BlockStructureI6MatrixEC5Ei
0000000000000000 W BlockStructure::~BlockStructure()
0000000000000000 W BlockStructure::~BlockStructure()
0000000000000000 W BlockStructure::~BlockStructure()
0000000000000000 n _ZN14BlockStructureI6MatrixED5Ev
0000000000000000 V typeinfo for BlockStructure
0000000000000000 V typeinfo name for BlockStructure
0000000000000000 V vtable for BlockStructure
U vtable for __cxxabiv1::__class_type_info
U operator delete(void*)
Clang:
0000000000000000 r GCC_except_table1
U _Unwind_Resume
0000000000000000 W BlockStructure::~BlockStructure()
0000000000000000 W BlockStructure::~BlockStructure()
0000000000000000 V typeinfo for BlockStructure
0000000000000000 V typeinfo name for BlockStructure
0000000000000000 V vtable for BlockStructure
U vtable for __cxxabiv1::__class_type_info
U operator delete(void*)
U __gxx_personality_v0
It seems like Clang skips the instantiation of the templates with expecting of
the destructor?
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From bugzilla-daemon at llvm.org Fri Sep 5 06:07:05 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 05 Sep 2014 13:07:05 +0000
Subject: [LLVMbugs] [Bug 20855] New: tuple with a reference to a temporary
(C++11): static_assert: "Attempted to construct a reference element in a
tuple with an rvalue"
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=20855
Bug ID: 20855
Summary: tuple with a reference to a temporary (C++11):
static_assert: "Attempted to construct a reference
element in a tuple with an rvalue"
Product: libc++
Version: unspecified
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: unassignedclangbugs at nondot.org
Reporter: mark at chromium.org
CC: llvmbugs at cs.uiuc.edu, mclow.lists at gmail.com
Classification: Unclassified
Created attachment 12993
--> http://llvm.org/bugs/attachment.cgi?id=12993&action=edit
Testcase
When creating a tuple that contains a reference to a temporary, this
static_assert is triggered:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/tuple:210:10:
error:
static_assert failed "Attempted to construct a reference element in a
tuple with an rvalue"
{static_assert(!is_reference<_Hp>::value ||
^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This check seems overzealous. In my seemingly-valid code, the temporary in
question outlives the reference to it, and there doesn’t appear to be any
reason to restrict this.
A testcase is attached. It can be built with “clang++ -std=c++11
-stdlib=libc++”.
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From bugzilla-daemon at llvm.org Fri Sep 5 08:15:12 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 05 Sep 2014 15:15:12 +0000
Subject: [LLVMbugs] [Bug 20854] Template instantiation fails with undefined
reference
In-Reply-To:
References:
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=20854
David Blaikie changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
CC| |dblaikie at gmail.com,
| |richard-llvm at metafoo.co.uk
Resolution|--- |INVALID
--- Comment #2 from David Blaikie ---
Richard can possibly sanity check my language lawyering, but this seems By
Design to me:
C++11 14.7.2\9 reads:
"An explicit instantiation definition that names a class template
specialization explicitly instantiates the class template specialization and is
an explicit instantiation definition of only those members that have been
defined at the point of instantiation."
Since your explicit instantiation definition appears before the definition of
the members of your class template, the explicit instantiation definition does
not instantiate those members.
I haven't checked the 14 wording. Also can't explain why that behavior would've
changed in GCC 4.9
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From bugzilla-daemon at llvm.org Fri Sep 5 08:16:20 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 05 Sep 2014 15:16:20 +0000
Subject: [LLVMbugs] [Bug 20856] New: wrong code (FP exception) at -O3 on
x86_64-linux-gnu (affecting 3.4.1 and later)
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=20856
Bug ID: 20856
Summary: wrong code (FP exception) at -O3 on x86_64-linux-gnu
(affecting 3.4.1 and later)
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 -O3 on
x86_64-linux-gnu (in both 32-bit and 64-bit modes).
This is a regression from 3.4.
$ clang-trunk -v
clang version 3.6.0 (trunk 216814)
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 -O2 small.c; a.out
$ clang-3.4 -O3 small.c; a.out
$
$ clang-trunk -O3 small.c
$ ./a.out
Floating point exception (core dumped)
$
---------------------------------
int a, b, *d, g, i, **j;
short *f;
static char c;
struct
{
int f2;
} e;
void
fn1 (char *p)
{
i = a / *p;
}
void
fn2 (int p)
{
short h;
fn1 (&c);
f = &h;
for (; g < 1; g++)
if (c && p)
*j = 0;
}
void
fn3 (int *p)
{
fn2 (*p);
}
void
fn4 ()
{
b = 0;
for (c = -7; c; c++)
{
fn3 (&b);
for (; e.f2;)
*d = 0;
}
}
int
main ()
{
fn4 ();
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:
From bugzilla-daemon at llvm.org Fri Sep 5 10:24:20 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 05 Sep 2014 17:24:20 +0000
Subject: [LLVMbugs] [Bug 20857] New: Assertion failure compiling a local
class member function that declares a VLA using a typedef from an enclosing
scope
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=20857
Bug ID: 20857
Summary: Assertion failure compiling a local class member
function that declares a VLA using a typedef from an
enclosing scope
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: C++
Assignee: unassignedclangbugs at nondot.org
Reporter: thonermann at coverity.com
CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
Classification: Unclassified
$ cat t.cpp
extern int n;
void f() {
typedef int vla[n];
struct LS {
void mf() {
vla v;
}
};
LS ls;
ls.mf();
}
$ clang++ --version
clang version 3.4 (tags/RELEASE_34/final)
Target: x86_64-unknown-linux-gnu
Thread model: posix
$ clang++ -c t.cpp
clang: .../CodeGenFunction.cpp:1260: std::pair
clang::CodeGen::CodeGenFunction::getVLASize(const clang::VariableArrayType*):
Assertion `vlaSize && "no size for VLA!"' failed.
0 clang 0x0000000002607c32 llvm::sys::PrintStackTrace(_IO_FILE*) +
34
1 clang 0x0000000002607019
2 libpthread.so.0 0x00007ff034c26cb0
3 libc.so.6 0x00007ff033c50425 gsignal + 53
4 libc.so.6 0x00007ff033c53b8b abort + 379
5 libc.so.6 0x00007ff033c490ee
6 libc.so.6 0x00007ff033c49192
7 clang 0x000000000096c0d9
clang::CodeGen::CodeGenFunction::getVLASize(clang::VariableArrayType const*) +
985
8 clang 0x000000000096c25b
clang::CodeGen::CodeGenFunction::getVLASize(clang::QualType) + 43
9 clang 0x0000000000a09733
clang::CodeGen::CodeGenFunction::EmitAutoVarAlloca(clang::VarDecl const&) + 211
10 clang 0x0000000000a0a3b6
clang::CodeGen::CodeGenFunction::EmitAutoVarDecl(clang::VarDecl const&) + 22
11 clang 0x0000000000954267
clang::CodeGen::CodeGenFunction::EmitDeclStmt(clang::DeclStmt const&) + 103
12 clang 0x000000000095d6e5
clang::CodeGen::CodeGenFunction::EmitSimpleStmt(clang::Stmt const*) + 277
13 clang 0x0000000000959667
clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*) + 39
14 clang 0x000000000095d1d0
clang::CodeGen::CodeGenFunction::EmitCompoundStmtWithoutScope(clang::CompoundStmt
const&, bool, clang::CodeGen::AggValueSlot) + 80
15 clang 0x0000000000966d4a
clang::CodeGen::CodeGenFunction::EmitFunctionBody(clang::CodeGen::FunctionArgList&,
clang::Stmt const*) + 74
16 clang 0x000000000096b37b
clang::CodeGen::CodeGenFunction::GenerateCode(clang::GlobalDecl,
llvm::Function*, clang::CodeGen::CGFunctionInfo const&) + 635
17 clang 0x000000000098d29e
clang::CodeGen::CodeGenModule::EmitGlobalFunctionDefinition(clang::GlobalDecl)
+ 654
18 clang 0x000000000098d5e1
clang::CodeGen::CodeGenModule::EmitGlobalDefinition(clang::GlobalDecl) + 225
19 clang 0x000000000098eaf7
clang::CodeGen::CodeGenModule::EmitDeferred() + 183
20 clang 0x000000000098eb7d clang::CodeGen::CodeGenModule::Release()
+ 13
21 clang 0x000000000091f62a
22 clang 0x0000000000acf1d4 clang::ParseAST(clang::Sema&, bool, bool)
+ 372
23 clang 0x000000000078e15a clang::FrontendAction::Execute() + 282
24 clang 0x00000000007703f0
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 352
25 clang 0x0000000000755e4d
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1693
26 clang 0x000000000074f110 cc1_main(char const**, char const**, char
const*, void*) + 1232
27 clang 0x0000000000732479 main + 665
28 libc.so.6 0x00007ff033c3b76d __libc_start_main + 237
29 clang 0x000000000074eacd
Stack dump:
0. Program arguments: .../clang -cc1 -triple x86_64-unknown-linux-gnu
-emit-obj -mrelax-all -disable-free -main-file-name t.cpp -mrelocation-model
static -mdisable-fp-elim -fmath-errno -masm-verbose -mconstructor-aliases
-munwind-tables -target-cpu x86-64 -target-linker-version 2.22 -coverage-file
/nfs/thonermann/tmp/tmp/t.o -resource-dir
/nfs/thonermann/products/linux-x86/clang-3.4-opt/bin/../lib/clang/3.4
-internal-isystem /usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../include/c++/4.6
-internal-isystem
/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../include/c++/4.6/x86_64-linux-gnu
-internal-isystem
/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../include/c++/4.6/backward
-internal-isystem
/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../include/x86_64-linux-gnu/c++/4.6
-internal-isystem /usr/local/include -internal-isystem
/nfs/thonermann/products/linux-x86/clang-3.4-opt/bin/../lib/clang/3.4/include
-internal-externc-isystem /usr/include/x86_64-linux-gnu
-internal-externc-isystem /include -internal-externc-isystem /usr/include
-fdeprecated-macro -fdebug-compilation-dir /nfs/thonermann/tmp/tmp
-ferror-limit 19 -fmessage-length 197 -mstackrealign -fobjc-runtime=gcc
-fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics
-vectorize-slp -o t.o -x c++ t.cpp
1. parser at end of file
2. Per-file LLVM IR generation
3. t.cpp:5:14: Generating code for declaration 'f()::LS::mf'
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.4 (tags/RELEASE_34/final)
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:
From bugzilla-daemon at llvm.org Fri Sep 5 10:33:01 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 05 Sep 2014 17:33:01 +0000
Subject: [LLVMbugs] [Bug 20849] clang miscompiles basic C code involving
modulo at -O3
In-Reply-To:
References:
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=20849
Sanjay Patel changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
CC| |spatel+llvm at rotateright.com
Resolution|--- |DUPLICATE
--- Comment #3 from Sanjay Patel ---
(In reply to comment #1)
> This works for me with Clang trunk at r217196. It would be good to figure
> out which change fixed this and get it into 3.5.1.
Hi Richard,
This was fixed with r214011 (bug 20355):
http://llvm.org/viewvc/llvm-project?view=revision&revision=214011
There was one more fix related to that vector division code at r215604:
http://llvm.org/viewvc/llvm-project?view=revision&revision=215604
Note that integer division is still miscompiling:
bug 20494
*** This bug has been marked as a duplicate of bug 20355 ***
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From bugzilla-daemon at llvm.org Fri Sep 5 10:37:27 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 05 Sep 2014 17:37:27 +0000
Subject: [LLVMbugs] [Bug 20523] release_3.5:
llvm::DbgValueHistoryMap::endInstrRange(const llvm::MDNode *,
const llvm::MachineInstr &): Assertion `Ranges.back().first->getParent() ==
MI.getParent()' failed.
In-Reply-To:
References:
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=20523
Adrian Prantl 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:
From bugzilla-daemon at llvm.org Fri Sep 5 10:49:09 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 05 Sep 2014 17:49:09 +0000
Subject: [LLVMbugs] [Bug 20552] -frewrite-includes produces files with
inconsistent line endings
In-Reply-To:
References:
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=20552
Reid Kleckner changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #1 from Reid Kleckner ---
Fixed in r217259.
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From bugzilla-daemon at llvm.org Fri Sep 5 10:51:44 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 05 Sep 2014 17:51:44 +0000
Subject: [LLVMbugs] [Bug 19530] LLVM generates incorrect tailcall on x86
In-Reply-To:
References:
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=19530
Reid Kleckner changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #3 from Reid Kleckner ---
Really closing... Keno fixed this in r216117.
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From bugzilla-daemon at llvm.org Fri Sep 5 11:08:03 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 05 Sep 2014 18:08:03 +0000
Subject: [LLVMbugs] [Bug 20793] Third field of llvm.global_ctors not used on
ELF
In-Reply-To:
References:
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=20793
Rafael Ávila de Espíndola changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #3 from Rafael Ávila de Espíndola ---
Fixed in r217264.
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From bugzilla-daemon at llvm.org Fri Sep 5 11:54:17 2014
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 05 Sep 2014 18:54:17 +0000
Subject: [LLVMbugs] [Bug 20856] wrong code (FP exception) at -O3 on
x86_64-linux-gnu (affecting 3.4.1 and later)
In-Reply-To:
References:
Message-ID:
http://llvm.org/bugs/show_bug.cgi?id=20856
Sanjay Patel changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |DUPLICATE
--- Comment #2 from Sanjay Patel