[llvm-bugs] [Bug 30560] New: std::bind does invoke constexpr functions two times with different parameter types
https://llvm.org/bugs/show_bug.cgi?id=30560
Bug ID: 30560
Summary: std::bind does invoke constexpr functions two times
with different parameter types
Product: libc++
Version: 3.9
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: benni.b...@gmail.com
CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com
Classification: Unclassified
My example is based on https://llvm.org/bugs/show_bug.cgi?id=23141
//> Code
#include
#include
struct Foo{
template < typename U >
void operator()(U&& u)const{
static_assert(std::is_same< U, int& >::value, "");
}
};
struct Bar{
template < typename U >
constexpr void operator()(U&& u)const{
static_assert(std::is_same< U, int& >::value, "");
}
};
int main(){
std::bind(Foo(), 42)(); // OK without constexpr
std::bind(Bar(), 42)(); // Error with constexpr
}
//< Code End
>$ clang++ -stdlib=libc++ -std=c++1z -o test test.cpp
---> Output
test.cpp:15:3: error: static_assert failed ""
static_assert(std::is_same< U, int& >::value, "");
^ ~~
/media/data/programme/llvm-3.9.0/bin/../include/c++/v1/type_traits:4287:23:
note: in instantiation of function template specialization
'Bar::operator()' requested here
_LIBCPP_INVOKE_RETURN(_VSTD::forward<_Fp>(__f)(_VSTD::forward<_Args>(__args)...))
^
/media/data/programme/llvm-3.9.0/bin/../include/c++/v1/__config:451:15: note:
expanded from macro '_VSTD'
#define _VSTD std::_LIBCPP_NAMESPACE
^
/media/data/programme/llvm-3.9.0/bin/../include/c++/v1/type_traits:4304:9:
note: while substituting deduced template arguments into function template
'__invoke' [with _Fp = const Bar, _Args = ]
_VSTD::__invoke(_VSTD::declval<_Fp>(), _VSTD::declval<_Args>()...));
^
/media/data/programme/llvm-3.9.0/bin/../include/c++/v1/__config:451:15: note:
expanded from macro '_VSTD'
#define _VSTD std::_LIBCPP_NAMESPACE
^
/media/data/programme/llvm-3.9.0/bin/../include/c++/v1/functional:2149:31:
note: in instantiation of template class 'std::__1::__invokable_r' requested here
static const bool value = __invokable<_Fp,
^
/media/data/programme/llvm-3.9.0/bin/../include/c++/v1/functional:2154:18:
note: in instantiation of template class
'std::__1::__is_valid_bind_return,
std::__1::tuple<> >' requested here
bool = __is_valid_bind_return<_Fp, _BoundArgs, _TupleUj>::value>
^
/media/data/programme/llvm-3.9.0/bin/../include/c++/v1/functional:2260:18:
note: in instantiation of default argument for '__bind_return, std::__1::tuple<> >' required here
typename __bind_return >::type
^~~
test.cpp:22:22: note: while substituting deduced template arguments into
function template 'operator()' [with _Args = <>]
std::bind(Bar(), 42)(); // Error with constexpr
^
1 error generated.
<--- Output End
The problem is that '_Args' is 'const int &', but it should be 'int&'. If I
force the static_assert to fail by checking if 'U' equals 'void', I get two
different substituten paths:
//> Code
#include
#include
struct Bar{
template < typename U >
constexpr void operator()(U&& u)const{
static_assert(std::is_same< U, void >::value, "");
}
};
int main(){
std::bind(Bar(), 42)();
}
//< Code End
>$ clang++ -stdlib=libc++ -std=c++1z -o test test.cpp
---> Output
test.cpp:9:3: error: static_assert failed ""
static_assert(std::is_same< U, void >::value, "");
^ ~~
/media/data/programme/llvm-3.9.0/bin/../include/c++/v1/type_traits:4287:23:
note: in instantiation of function template specialization 'Bar::operator()' requested here
_LIBCPP_INVOKE_RETURN(_VSTD::forward<_Fp>(__f)(_VSTD::forward<_Args>(__args)...))
^
/media/data/programme/llvm-3.9.0/bin/../include/c++/v1/__config:451:15: note:
expanded from macro '_VSTD'
#define _VSTD std::_LIBCPP_NAMESPACE
^
/media/data/programme/llvm-3.9.0/bin/../include/c++/v1/type_traits:4304:9:
note: while substituting deduced template arguments into function template
'__invoke' [with _Fp = Bar, _Args = ]
_VSTD::__invoke(_VSTD::declval<_Fp>(), _VSTD::declval<_Args>()...));
^
/media/data/programme/llvm-3.9.0/bin/../include/c++/v1/__config:451:15: note:
expanded from macro '_VSTD'
#define _VSTD std::_LIBCPP_NAMESPACE
^
/media/data/programme/llvm-3.9.0/bin/../include/c++/v1/functional:2142:31:
note: in instantiation of template class 'std::__1::__invokable_r' request
[llvm-bugs] [Bug 30561] New: [AVX512F] Suboptimal code generated for a _mm_mask_move_sd expansion
https://llvm.org/bugs/show_bug.cgi?id=30561
Bug ID: 30561
Summary: [AVX512F] Suboptimal code generated for a
_mm_mask_move_sd expansion
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Backend: X86
Assignee: unassignedb...@nondot.org
Reporter: zvi.racko...@intel.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
We currently do not support the AVX512F _mm_mask_move_sd
[https://software.intel.com/sites/landingpage/IntrinsicsGuide/#text=_mm_mask_move_sd]
intrinics, but a reasonable expansion of this intrinsics to LLVM IR may be:
define <2 x double> _mm_mask_move_sd(<4 x float> %__W, i8 zeroext %__U, <2 x
double> %__A, <2 x double> %__B) local_unnamed_addr #2 {
entry:
%0 = bitcast <4 x float> %__W to <2 x double>
%and.i = and i8 %__U, 1
%tobool.i = icmp ne i8 %and.i, 0
%__B.elt.i = extractelement <2 x double> %__B, i32 0
%__W.elt.i = extractelement <2 x double> %0, i32 0
%vecext.i = select i1 %tobool.i, double %__B.elt.i, double %__W.elt.i
%vecins.i = insertelement <2 x double> %__A, double %vecext.i, i32 0
ret <2 x double> %vecins.i
}
which should be lowered to:
==
kmovw %edi, %k1
vmovsd%xmm2, %xmm1, %xmm0{%k1}
retq
==
'llc -mcpu=knl' generates:
==
testb $1, %dil
jne .LBB0_2
# BB#1: # %entry
vmovapd %xmm0, %xmm2
.LBB0_2:# %entry
vmovsd %xmm2, %xmm1, %xmm0 # xmm0 = xmm2[0],xmm1[1]
retq
==
--
You are receiving this mail because:
You are on the CC list for the bug.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 30562] New: Selection DAG error: Detected cycle in SelectionDAG
https://llvm.org/bugs/show_bug.cgi?id=30562 Bug ID: 30562 Summary: Selection DAG error: Detected cycle in SelectionDAG Product: new-bugs Version: 3.9 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: serge.guel...@telecom-bretagne.eu CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 17376 --> https://llvm.org/bugs/attachment.cgi?id=17376&action=edit Faulty input bitcode While compiling the reduced test case in attachment, the compiler crashes with the backtrace below. Changing vector to scalar fixes the issue... Overran sorted position: t14: ch = store t0, t2, t11, undef:i64 t2: v2i64,ch = CopyFromReg t0, Register:v2i64 %vreg0 t1: v2i64 = Register %vreg0 t11: i64 = add t8, t10 t8: i64,ch = CopyFromReg t0, Register:i64 %vreg2 t7: i64 = Register %vreg2 t10: i64 = shl t42, Constant:i8<3> t42: i64,ch = load]> t14, t41, undef:i64 t41: i64 = add t47, t11 t47: i64 = shl t5, Constant:i8<3> t5: i64 = sign_extend t4 t4: i32,ch = CopyFromReg t0, Register:i32 %vreg4 t3: i32 = Register %vreg4 t38: i8 = Constant<3> t11: i64 = add t8, t10 t8: i64,ch = CopyFromReg t0, Register:i64 %vreg2 t7: i64 = Register %vreg2 t10: i64 = shl t42, Constant:i8<3> t42: i64,ch = load]> t14, t41, undef:i64 t41: i64 = add t47, t11 t47: i64 = shl t5, Constant:i8<3> t11: i64 = add t8, t10 t13: i64 = undef t38: i8 = Constant<3> t13: i64 = undef t38: i8 = Constant<3> t13: i64 = undef Checking if this is due to cycles Detected cycle in SelectionDAG Offending node: t42: i64,ch = load]> t14, t41, undef:i64 t41: i64 = add t47, t11 t47: i64 = shl t5, Constant:i8<3> t5: i64 = sign_extend t4 t4: i32,ch = CopyFromReg t0, Register:i32 %vreg4 t3: i32 = Register %vreg4 t38: i8 = Constant<3> t11: i64 = add t8, t10 t8: i64,ch = CopyFromReg t0, Register:i64 %vreg2 t7: i64 = Register %vreg2 t10: i64 = shl t42, Constant:i8<3> t42: i64,ch = load]> t14, t41, undef:i64 t41: i64 = add t47, t11 t47: i64 = shl t5, Constant:i8<3> t5: i64 = sign_extend t4 t4: i32,ch = CopyFromReg t0, Register:i32 %vreg4 t3: i32 = Register %vreg4 t38: i8 = Constant<3> t11: i64 = add t8, t10 t8: i64,ch = CopyFromReg t0, Register:i64 %vreg2 t7: i64 = Register %vreg2 t10: i64 = shl t42, Constant:i8<3> t42: i64,ch = load]> t14, t41, undef:i64 t41: i64 = add t47, t11 t13: i64 = undef t38: i8 = Constant<3> t13: i64 = undef t38: i8 = Constant<3> t13: i64 = undef #0 0x7fe83ffe4d88 llvm::sys::PrintStackTrace(llvm::raw_ostream&) /tmp/_nbuild/../lib/Support/Unix/Signals.inc:402:13 #1 0x7fe83ffe5416 bool __gnu_cxx::operator!=*, std::vector, std::allocator > > >(__gnu_cxx::__normal_iterator*, std::vector, std::allocator > > > const&, __gnu_cxx::__normal_iterator*, std::vector, std::allocator > > > const&) /usr/bin/../lib/gcc/x86_64-linux-gnu/6.1.1/../../../../include/c++/6.1.1/bits/stl_iterator.h:873:27 #2 0x7fe83ffe5416 llvm::sys::RunSignalHandlers() /tmp/_nbuild/../lib/Support/Signals.cpp:44:0 #3 0x7fe83ffe5416 SignalHandler(int) /tmp/_nbuild/../lib/Support/Unix/Signals.inc:246:0 #4 0x7fe846bbaeb0 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x10eb0) #5 0x7fe83dfd3198 gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x33198) #6 0x7fe83dfd461a abort (/lib/x86_64-linux-gnu/libc.so.6+0x3461a) #7 0x7fe83ae1cde7 llvm::raw_ostream::operator<<(llvm::StringRef) /tmp/_nbuild/../include/llvm/Support/raw_ostream.h:169:7 #8 0x7fe83ae1cde7 llvm::raw_ostream::operator<<(char const*) /tmp/_nbuild/../include/llvm/Support/raw_ostream.h:179:0 #9 0x7fe83ae1cde7 checkForCyclesHelper(llvm::SDNode const*, llvm::SmallPtrSetImpl&, llvm::SmallPtrSetImpl&, llvm::SelectionDAG const*) /tmp/_nbuild/../lib/CodeGen/SelectionDAG/SelectionDAG.cpp:7282:0 #10 0x7fe83ae1ccf1 llvm::iterator_adaptor_base >::operator++() /tmp/_nbuild/../include/llvm/ADT/iterator.h:211:5 #11 0x7fe83ae1ccf1 checkForCyclesHelper(llvm::SDNode const*, llvm::SmallPtrSetImpl&, llvm::SmallPtrSetImpl&, llvm::SelectionDAG const*) /tmp/_nbuild/../lib/CodeGen/SelectionDAG/SelectionDAG.cpp:7286:0 #12 0x7fe83ae1ccf1 llvm::iterator_adaptor_base >::operator++() /tmp/_nbuild/../include/llvm/ADT/iterator.h:211:5 #13 0x7fe83ae1ccf1 checkForCyclesHelper(llvm::SDNode const*, llvm::SmallPtrSetImpl&, llvm::Sm
[llvm-bugs] [Bug 30563] New: [AVX512F] Suboptimal code generated for a _mm_mask_store_sd expansion
https://llvm.org/bugs/show_bug.cgi?id=30563
Bug ID: 30563
Summary: [AVX512F] Suboptimal code generated for a
_mm_mask_store_sd expansion
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Backend: X86
Assignee: unassignedb...@nondot.org
Reporter: zvi.racko...@intel.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
We currently do not support the AVX512F _mm_mask_store_sd
[https://software.intel.com/sites/landingpage/IntrinsicsGuide/#text=_mm_mask_store_sd]
intrinics, but a reasonable expansion of this intrinsics to LLVM IR may be:
define void @_mm_mask_store_sd(double* nocapture %__W, i8 zeroext %__U, <2 x
double> %__A) local_unnamed_addr {
entry:
%tobool.i = trunc i8 %__U to i1
%mask = insertelement <2 x i1> , i1 %tobool.i, i32 0
%V = bitcast double * %__W to <2 x double>*
call void @llvm.masked.store.v2f64.p0v2f64(<2 x double> %__A, <2 x double>*
%V, i32 16, <2 x i1> %mask)
ret void
}
declare void @llvm.masked.store.v2f64.p0v2f64(<2 x double>, <2 x double>*,
i32, <2 x i1>)
which should be lowered to:
==
kmovw %esi, %k1
vmovsd%xmm0, (%rdi){%k1}
==
'llc -mcpu=knl' generates:
==
vmovq %rsi, %xmm1
vpsllq $63, %xmm1, %xmm1
vpsrad $31, %xmm1, %xmm1
vpshufd $245, %xmm1, %xmm1 # xmm1 = xmm1[1,1,3,3]
vmaskmovpd %xmm0, %xmm1, (%rdi)
retq
==
'llc -mcpu=skylake-avx512' generates:
==
andl$1, %esi
kmovw %esi, %k0
kxorw %k0, %k0, %k1
kshiftrw$1, %k1, %k1
kshiftlw$1, %k1, %k1
korw%k0, %k1, %k1
vmovapd %xmm0, (%rdi) {%k1}
retq
==
--
You are receiving this mail because:
You are on the CC list for the bug.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 30428] Infer nsw/nuw flags for increment/decrement if relational comparison succeeded
https://llvm.org/bugs/show_bug.cgi?id=30428 Matti Niemenmaa changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #6 from Matti Niemenmaa --- Turns out this was already dealt with as part of Bug 28620, which has a fix in trunk that currently requires explicit activation due to it causing other regressions: opt -cvp-dont-process-adds=false -correlated-propagation infers the nsw/nuw flags nicely. But only for adds — it doesn't do anything for sub instructions. Currently this doesn't matter, since that would anyway be undone by the fact that 'sub nuw Y, 1' is canonicalized into 'add Y, -1', but dealing with that seems like a separate issue so I'm marking this as a duplicate. *** This bug has been marked as a duplicate of bug 28620 *** -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 30564] New: Optimizer bug causes infinite loop in cuda code
https://llvm.org/bugs/show_bug.cgi?id=30564
Bug ID: 30564
Summary: Optimizer bug causes infinite loop in cuda code
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: CUDA
Assignee: unassignedclangb...@nondot.org
Reporter: crtr...@sandia.gov
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Created attachment 17377
--> https://llvm.org/bugs/attachment.cgi?id=17377&action=edit
Reproducer
This bug is present in 3.9 and current head.
I have some code which essentially does a lock loop with a while construct to
implement arbitrary atomic operations. We use that in production using NVCC,
but the code infinitely loops at optimization level O2 or higher with clang. I
can workaround the bug by adding another check on the loop variable. Putting
print statements in shows the check is never triggered and behaviour of the
lock loop is as expected.
A reproducer is attached. The build.clang and build.cuda files have build
lines, please change paths so they work for you. Removing the -DBUG puts in the
workaround (i.e. the additional check and printf). Also change on the clang
build -O2 to -O1 as another way to make it work.
This is the offending function (the lock functions just do a simple hash and
try to grep a lock from a global array):
template < typename T >
__inline__ __device__
T atomic_fetch_add( volatile T * const dest , const T & val )
{
T return_val;
// This is a way to (hopefully) avoid dead lock in a warp
int done = 1;
while ( done>0 ) {
done++;
bool locked = lock_address_cuda_space( (void*) dest );
if( locked ) {
return_val = *dest;
*dest = return_val + val;
unlock_address_cuda_space( (void*) dest );
done = 0;
}
#ifndef BUG
printf("Done: %i %i %i\n",threadIdx.y,done,locked?1:0);
if(done==100) done = 0;
#endif
}
return return_val;
}
--
You are receiving this mail because:
You are on the CC list for the bug.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 30566] New: clang asserts when compiling lambda with a initialized capture
https://llvm.org/bugs/show_bug.cgi?id=30566
Bug ID: 30566
Summary: clang asserts when compiling lambda with a initialized
capture
Product: clang
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: C++14
Assignee: unassignedclangb...@nondot.org
Reporter: ahata...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
$ cat t2.cpp
int name1;
int foo1(int *a) {
auto s1= [name=name](int *a) -> int {
return *a;
};
return sizeof(s1);
}
$ clang++ -std=c++14 t2.cpp -c -o /dev/null
t2.cpp:4:18: error: use of undeclared identifier 'name'; did you mean 'name1'?
auto s1= [name=name](int *a) -> int {
^~~~
name1
t2.cpp:1:5: note: 'name1' declared here
int name1;
^
Assertion failed: (!A->getDeducedType().isNull() && "cannot request the size of
an undeduced or dependent auto type"), function getTypeInfoImpl, file
/Users/ahatanaka/projects/llvm/git/llvm/tools/clang/lib/AST/ASTContext.cpp,
line 1856.
Stack dump:
--
You are receiving this mail because:
You are on the CC list for the bug.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 30567] New: Cuda Nested lambda (lambda inside a device function) requires __device__ annotation
https://llvm.org/bugs/show_bug.cgi?id=30567
Bug ID: 30567
Summary: Cuda Nested lambda (lambda inside a device function)
requires __device__ annotation
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: CUDA
Assignee: unassignedclangb...@nondot.org
Reporter: crtr...@sandia.gov
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Created attachment 17381
--> https://llvm.org/bugs/attachment.cgi?id=17381&action=edit
Reproducer example
With NVCC lambdas which are declared inside a __device__ (or __host__
__device__ ) function automatically get promoted to __device__ or __host__
__device__. In fact one is not even allowed to mark the operator. In clang one
must mark it though. This situation makes me write a lot of ifdefs.
Would it be possible to make lambda operators inherit the the attribute from
its scope if not explicitly specified? I am attaching a reproducer
demonstrating what I currently need to do to make it work.
Here are the error messages from NVCC if I use "[=] (const int& i) __device__"
main.cpp(14): warning: a __host__ function("lambda []::operator()") redeclared
with __device__, hence treated as a __host__ __device__ function
main.cpp(16): error: The operator() function for a lambda cannot be explicitly
annotated with execution space annotations (__host__/__device__/__global__),
the annotations are derived from its closure class
1 error detected in the compilation of
"/tmp/tmpxft_0001e52a_-9_main.cpp1.ii".
and if I use "[=] __device__ (const int& i)":
main.cpp(14): error: An explicit __device__ lambda must be defined inside a
__host__ or __host__ __device__ function
1 error detected in the compilation of
"/tmp/tmpxft_0001e53a_-9_main.cpp1.ii".
--
You are receiving this mail because:
You are on the CC list for the bug.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 29129] lldb-mi expressions that have spaces aren't parsed properly for -var-create
https://llvm.org/bugs/show_bug.cgi?id=29129 edmu...@microsoft.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from edmu...@microsoft.com --- This was fixed and merged. https://reviews.llvm.org/D24202 -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 30568] New: [lldb-mi] -var-assign doesn't accept some valid values
https://llvm.org/bugs/show_bug.cgi?id=30568 Bug ID: 30568 Summary: [lldb-mi] -var-assign doesn't accept some valid values Product: lldb Version: 3.9 Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-...@lists.llvm.org Reporter: edmu...@microsoft.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Related to https://llvm.org/bugs/show_bug.cgi?id=30423 -var-assign should allow assigning certain values to variables. The supported types seems to be ints and floats (different encodings). For example, assigning a valid value such as "true", "false", "'a'" all fail. These assignments succeed if the "equivalent" integer value is used instead (1, 0, 97 (ascii), respectively). Other debuggers like GDB do support these values to be used with the command -var-assign. Repro (where z is a boolean variable): -var-create - - "z" --thread 1 --frame 0 ^done,name="var2",numchild="0",value="true",type="bool",thread-id="1",has_more="0" (gdb) ## Assigning "false" fails -var-assign var2 "false" ^error,msg="expression could not be evaluated" (gdb) ## Assigning "0" succeeds -var-assign var2 "0" ^done,value="false" (gdb) -var-evaluate-expression var2 ^done,value="false" (gdb) The expected behavior is the same as GDB: -var-create - * "z" ^done,name="var1",numchild="0",value="true",type="bool",thread-id="1",has_more="0" (gdb) -var-assign var1 "false" ^done,value="false" (gdb) -var-evaluate-expression var1 ^done,value="false" (gdb) -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 28499] Crashes on the boost XML parser
https://llvm.org/bugs/show_bug.cgi?id=28499 Reid Kleckner changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from Reid Kleckner --- Nobody can repro, so I assume we fixed it. -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 30552] [codeview] LLVM should emit T_CHAR instead of T_INT1 for PDB
https://llvm.org/bugs/show_bug.cgi?id=30552 Reid Kleckner changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Reid Kleckner --- r282739 -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 30564] Optimizer bug causes infinite loop in cuda code
https://llvm.org/bugs/show_bug.cgi?id=30564 Justin Lebar changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WORKSFORME --- Comment #19 from Justin Lebar --- If you have time, I'd certainly appreciate updating our docs to summarize this conversation. I'm sure this is not the last time someone will file a bug like this. https://github.com/llvm-project/llvm-project/blob/master/llvm/docs/CompileCudaWithLLVM.rst, which corresponds to http://llvm.org/docs/CompileCudaWithLLVM.html -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 30569] New: Functions missing in .arange
https://llvm.org/bugs/show_bug.cgi?id=30569 Bug ID: 30569 Summary: Functions missing in .arange Product: libraries Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: DebugInfo Assignee: unassignedb...@nondot.org Reporter: cl...@martinien.de CC: llvm-bugs@lists.llvm.org Classification: Unclassified Hi, we have a custom callstack printer that does not work on clang 3.9 anymore. It unwinds the stack and looks up function/file name/line number for the code locations from DWARF. But for some functions properly listed in .debuginfo with DW_AT_low_pc/DW_AT_high_pc there is no corresponding code location in the .arange section which could be mapped to a translation unit, so for some frames we get missing file names/line numbers. This only affects some functions in a translation unit. I have a pretty small reproducer which has one function with correct and one with broken .arange info, unfortunately I still depend on a custom STL implementation which pulls in lots of headers which I cannot attach here :( Comparing the output between clang 3.7 and 3.9 I see that the location info for the two functions get merged into one chunk in 3.7, so the printer can find the translation unit for both functions using that info. In 3.9 this merging does not seem to happen and the code area of one function is listed only. I tried to bisect but hit bug 27728 in between. I will continue trying to reduce the reproducer, but perhaps someone has an idea already? Thanks and Best regards, Martin -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 30570] New: Memory model spec allows for tearing between same-size accesses
https://llvm.org/bugs/show_bug.cgi?id=30570 Bug ID: 30570 Summary: Memory model spec allows for tearing between same-size accesses Product: new-bugs Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: ajeff...@mozilla.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified At the moment, the LLVM memory model specification allows for tearing. This is correct for mixed-size or unaligned access, for example if mutexes are used for large accesses, and atomic instructions are used for small accesses. Unfortunately, the spec as it currently stands allows for tearing even when the accesses are all of the same size. The problem is that in http://llvm.org/docs/LangRef.html#memory-model-for-concurrent-operations, there is no guarantee that each of the W_byte operations observed by one R come from the same W, even when all accesses are to the same address range. Adding a new sentence to the specification would fix this, something like "If an atomic read R can only see atomic writes to the same address range, then there must be a single write W such that each R_byte in R chooses a W_byte from W." -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 26483] CUDA __device__ lambdas generating incorrect code
https://llvm.org/bugs/show_bug.cgi?id=26483 Justin Lebar changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Justin Lebar --- Based on discussion in bug 30564 and comment #2, I'm going to call this fixed. -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 26481] CUDA __global__ lambdas shouldn't be allowed to capture by reference
https://llvm.org/bugs/show_bug.cgi?id=26481 Justin Lebar changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 30503] SSE instructions are generated with SSE disabled
https://llvm.org/bugs/show_bug.cgi?id=30503 Reid Kleckner changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Reid Kleckner --- r282819 -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 16333] NVPTX fails to generate loads/stores with literal offsets
https://llvm.org/bugs/show_bug.cgi?id=16333 Justin Lebar changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #3 from Justin Lebar --- This seems to be a bug with a closed-source fork of LLVM, not with LLVM itself? If so, this is the wrong bug tracker. Feel free to reopen if I'm missing something. -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 30541] lld's page size handling is inconsistent with Binutils linkers
https://llvm.org/bugs/show_bug.cgi?id=30541 Petr Hosek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 30571] New: Last upgrade broke email notification: they are now sent as HTML only
https://llvm.org/bugs/show_bug.cgi?id=30571 Bug ID: 30571 Summary: Last upgrade broke email notification: they are now sent as HTML only Product: Phabricator Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: unassignedb...@nondot.org Reporter: mehdi.am...@apple.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified This is: 1) Breaking the archive, see for instance: http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20160926/172081.html 2) Preventing to answer inline efficiently by email as it has always been possible. -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 30572] New: Can't delete inline comment after last upgrade
https://llvm.org/bugs/show_bug.cgi?id=30572 Bug ID: 30572 Summary: Can't delete inline comment after last upgrade Product: Phabricator Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: unassignedb...@nondot.org Reporter: mehdi.am...@apple.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified I can now only edit, but not delete comment. When I click on the trash it grays and stays like that forever. -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 30573] New: 510.parest_r is giving Compilation Error at O3 with TOT(PPC)
https://llvm.org/bugs/show_bug.cgi?id=30573 Bug ID: 30573 Summary: 510.parest_r is giving Compilation Error at O3 with TOT(PPC) Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Backend: PowerPC Assignee: unassignedb...@nondot.org Reporter: risba...@in.ibm.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 30574] New: 526.blender_r is giving Compilation Error at O3 with LLVM TOT(PPC)
https://llvm.org/bugs/show_bug.cgi?id=30574 Bug ID: 30574 Summary: 526.blender_r is giving Compilation Error at O3 with LLVM TOT(PPC) Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Backend: PowerPC Assignee: unassignedb...@nondot.org Reporter: risba...@in.ibm.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
