[llvm-bugs] [Bug 31469] TemplateSpecializationType with no RecordType as CXXBaseSpecifier
https://llvm.org/bugs/show_bug.cgi?id=31469 Vassil Vassilev changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Vassil Vassilev --- Fixed in r291753. -- 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 31615] New: Brackets inside inline asm crash backend
https://llvm.org/bugs/show_bug.cgi?id=31615
Bug ID: 31615
Summary: Brackets inside inline asm crash backend
Product: new-bugs
Version: 3.9
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: pmatos@linki.tools
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
The following code snippet crashs the backend:
// inlbra2.c
void foo() { __asm__("#{{[a-zA-Z]}}":::"memory"); }
int main(void) { return 0; }
Try:
$ ~/INSTALLS/clang+llvm-3.9.0-x86_64-fedora23/bin/clang -S -o- inbra2.c
.text
.file "inbra2.c"
.globl foo
.p2align4, 0x90
.type foo,@function
foo:# @foo
.cfi_startproc
# BB#0:
pushq %rbp
.Ltmp0:
.cfi_def_cfa_offset 16
.Ltmp1:
.cfi_offset %rbp, -16
movq%rsp, %rbp
.Ltmp2:
.cfi_def_cfa_register %rbp
#APP
fatal error: error in backend: Nested variants found in inline asm string:
'#$($([a-zA-Z]$)$)'
clang-3.9: error: clang frontend command failed with exit code 70 (use -v to
see invocation)
clang version 3.9.0 (tags/RELEASE_390/final)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /home/pmatos/INSTALLS/clang+llvm-3.9.0-x86_64-fedora23/bin
clang-3.9: note: diagnostic msg: PLEASE submit a bug report to
http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and
associated run script.
clang-3.9: note: diagnostic msg:
PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang-3.9: note: diagnostic msg: /tmp/inbra2-2cc6fb.c
clang-3.9: note: diagnostic msg: /tmp/inbra2-2cc6fb.sh
clang-3.9: note: diagnostic msg:
--
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 31616] New: undefined reference to pthread_create
https://llvm.org/bugs/show_bug.cgi?id=31616 Bug ID: 31616 Summary: undefined reference to pthread_create Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: libclang Assignee: unassignedclangb...@nondot.org Reporter: xiangzha...@gmail.com CC: kli...@google.com, llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 17833 --> https://llvm.org/bugs/attachment.cgi?id=17833&action=edit libclang-cmake-pthread.patch Hi clang developers, ../../../../lib/libclangIncludeFixerPlugin.a(IncludeFixerPlugin.cpp.o): In function `std::__future_base::_Async_state_impl > ()> ()>, std::unique_ptr > >::_Async_state_impl(std::_Bind_simple > ()> ()>&&)': /data/project/LLVM/llvm/tools/clang/tools/extra/include-fixer/plugin/IncludeFixerPlugin.cpp:(.text._ZNSt13__future_base17_Async_state_implISt12_Bind_simpleIFSt8functionIFSt10unique_ptrIN5clang13include_fixer11SymbolIndexESt14default_deleteIS6_EEvEEvEES9_EC2EOSD_[_ZNSt13__future_base17_Async_state_implISt12_Bind_simpleIFSt8functionIFSt10unique_ptrIN5clang13include_fixer11SymbolIndexESt14default_deleteIS6_EEvEEvEES9_EC2EOSD_]+0xdf): undefined reference to `pthread_create' clang-3.9: error: linker command failed with exit code 1 (use -v to see invocation) tools/clang/tools/libclang/CMakeFiles/libclang.dir/build.make:631: recipe for target 'lib/libclang.so.4.0' failed make[2]: *** [lib/libclang.so.4.0] Error 1 CMakeFiles/Makefile2:32067: recipe for target 'tools/clang/tools/libclang/CMakeFiles/libclang.dir/all' failed make[1]: *** [tools/clang/tools/libclang/CMakeFiles/libclang.dir/all] Error 2 Makefile:149: recipe for target 'all' failed make: *** [all] Error 2 Workaround patched! please give me some advice, thanks a lot! Regards, Leslie Zhai -- 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 31617] New: avx512 : blendm, missing instruction form.
https://llvm.org/bugs/show_bug.cgi?id=31617
Bug ID: 31617
Summary: avx512 : blendm, missing instruction form.
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Backend: X86
Assignee: unassignedb...@nondot.org
Reporter: igor.bre...@intel.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
All BLENDM instructions missing broadcast + zero mask form
test for example
// CHECK: vpblendmq zmm8 {k2} {z}, zmm8, qword ptr [rdx]{1to8}
// CHECK: # encoding: [0x62,0x72,0xbd,0xda,0x64,0x02]
vpblendmq zmm8 {k2} {z}, zmm8, qword ptr [rdx]{1to8}
--
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 31618] New: AVX512: vgatherqps/vpgatherqd has incorrect memory operand.
https://llvm.org/bugs/show_bug.cgi?id=31618
Bug ID: 31618
Summary: AVX512: vgatherqps/vpgatherqd has incorrect memory
operand.
Product: libraries
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: Backend: X86
Assignee: unassignedb...@nondot.org
Reporter: igor.bre...@intel.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
vgatherqps/vpgatherqd has incorrect memory operand.
tests
// CHECK: vgatherqps ymm8 {k2}, ymmword ptr [rdx+zmm3+256]
// CHECK: # encoding: [0x62,0x72,0x7d,0x4a,0x93,0x44,0x1a,0x40]
vgatherqps ymm8 {k2}, ymmword ptr [rdx+zmm3+256]
// CHECK: vgatherqps ymm8 {k2}, ymmword ptr [rdx+zmm3*4+256]
// CHECK: # encoding: [0x62,0x72,0x7d,0x4a,0x93,0x44,0x9a,0x40]
vgatherqps ymm8 {k2}, ymmword ptr [rdx+zmm3*4+256]
// CHECK: vgatherqps ymm8 {k2}, ymmword ptr [rdx+zmm3*4-256]
// CHECK: # encoding: [0x62,0x72,0x7d,0x4a,0x93,0x44,0x9a,0xc0]
vgatherqps ymm8 {k2}, ymmword ptr [rdx+zmm3*4-256]
// CHECK: vpgatherqd ymm8 {k2}, ymmword ptr [rdx+zmm3+256]
// CHECK: # encoding: [0x62,0x72,0x7d,0x4a,0x91,0x44,0x1a,0x40]
vpgatherqd ymm8 {k2}, ymmword ptr [rdx+zmm3+256]
// CHECK: vpgatherqd ymm8 {k2}, ymmword ptr [rdx+zmm3*4+256]
// CHECK: # encoding: [0x62,0x72,0x7d,0x4a,0x91,0x44,0x9a,0x40]
vpgatherqd ymm8 {k2}, ymmword ptr [rdx+zmm3*4+256]
// CHECK: vpgatherqd ymm8 {k2}, ymmword ptr [rdx+zmm3*4-256]
// CHECK: # encoding: [0x62,0x72,0x7d,0x4a,0x91,0x44,0x9a,0xc0]
vpgatherqd ymm8 {k2}, ymmword ptr [rdx+zmm3*4-256]
--
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 31452] Clang tidy modernize crashes on Windows when processing Visual Studio cstdio header file
https://llvm.org/bugs/show_bug.cgi?id=31452 Malcolm Parsons changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Malcolm Parsons --- *** This bug has been marked as a duplicate of bug 29135 *** -- 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 30611] BFI instruction with zero register decoded as bad BFC instruction
https://llvm.org/bugs/show_bug.cgi?id=30611 Chad Rosier changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #4 from Chad Rosier --- That sounds reasonable to me, Tim. -- 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 31619] New: LLD segfaults while linking FreeBSD EFI loader with -error-limit=0
https://llvm.org/bugs/show_bug.cgi?id=31619 Bug ID: 31619 Summary: LLD segfaults while linking FreeBSD EFI loader with -error-limit=0 Product: lld Version: unspecified Hardware: PC OS: FreeBSD Status: NEW Severity: normal Priority: P Component: ELF Assignee: unassignedb...@nondot.org Reporter: ema...@freebsd.org CC: llvm-bugs@lists.llvm.org Classification: Unclassified While investigating a failure to link the FreeBSD EFI loader (described in a comment at https://reviews.llvm.org/D28313) I encountered a segfault. (lldb) bt * thread #1: tid = 0, 0x00546b20 ld.lld`llvm::DenseMapBase, llvm::detail::DenseSetPair >, lld::Atom const*, llvm::detail::DenseSetEmpty, llvm::DenseMapInfo, llvm::detail::DenseSetPair >::initEmpty(this=0x7fffcc20) + 80 at DenseMap.h:318, name = 'lld', stop reason = signal SIGSEGV * frame #0: 0x00546b20 ld.lld`llvm::DenseMapBase, llvm::detail::DenseSetPair >, lld::Atom const*, llvm::detail::DenseSetEmpty, llvm::DenseMapInfo, llvm::detail::DenseSetPair >::initEmpty(this=0x7fffcc20) + 80 at DenseMap.h:318 frame #1: 0x005a0e19 ld.lld`lld::coff::SectionChunk::classof(C=0x) + 25 at Chunks.h:138 frame #2: 0x005a0cd8 ld.lld`llvm::cast_convert_val::doit(Val=0x000804a48120) + 8 at Casting.h:199 frame #3: 0x0058578b ld.lld`void std::__1::__sort(lld::coff::Export*, lld::coff::Export*, lld::coff::fixupExports()::$_0&) + 1835 at algorithm:3935 frame #4: 0x006251a2 ld.lld`void std::__1::vector >, std::__1::allocator > > >::__push_back_slow_path > >(std::__1::vector >&&) [inlined] std::__1::vector >, std::__1::allocator > > >::size(this=0x0008027d6c00, this=0x00080369a903, this=0x7fffcb10, __new_size=34401516544) const + 468 at vector:973 frame #5: 0x00624fce ld.lld`void std::__1::vector >, std::__1::allocator > > >::__push_back_slow_path > >(this=0x0008027cfc00, __x=0x0008027cf800) + 174 at vector:1579 frame #6: 0x006304f6 ld.lld`std::__1::__function::__func, std::__1::allocator >, int)::'lambda'(llvm::Error const&), std::__1::allocator, std::__1::allocator >, int)::'lambda'(llvm::Error const&)>, int (llvm::Error const&)>::__clone() const [inlined] std::__1::__compressed_pair, std::__1::allocator >, int)::'lambda'(llvm::Error const&)>, int (llvm::Error const&)>*, std::__1::__allocator_destructor, std::__1::allocator >, int)::'lambda'(llvm::Error const&), std::__1::allocator, std::__1::allocator >, int)::'lambda'(llvm::Error const&)>, int (llvm::Error const&)> > > >::second() + 25 at memory:3475 frame #7: 0x006304dd ld.lld`std::__1::__function::__func, std::__1::allocator >, int)::'lambda'(llvm::Error const&), std::__1::allocator, std::__1::allocator >, int)::'lambda'(llvm::Error const&)>, int (llvm::Error const&)>::__clone() const [inlined] std::__1::unique_ptr, std::__1::allocator >, int)::'lambda'(llvm::Error const&)>, int (llvm::Error const&)>, std::__1::__allocator_destructor, std::__1::allocator >, int)::'lambda'(llvm::Error const&), std::__1::allocator, std::__1::allocator >, int)::'lambda'(llvm::Error const&)>, int (llvm::Error const&)> > > >::reset(std::__1::__function::__func, std::__1::allocator >, int)::'lambda'(llvm::Error const&), std::__1::allocator, std::__1::allocator >, int)::'lambda'(llvm::Error const&)>, int (llvm::Error const&)>*) + 149 at memory:2630 frame #8: 0x00630448 ld.lld`std::__1::__function::__func, std::__1::allocator >, int)::'lambda'(llvm::Error const&), std::__1::allocator, std::__1::allocator >, int)::'lambda'(llvm::Error const&)>, int (llvm::Error const&)>::__clone() const [inlined] ~unique_ptr(this=0x7fffcb80) at memory:2598 frame #9: 0x00630448 ld.lld`std::__1::__function::__func, std::__1::allocator >, int)::'lambda'(llvm::Error const&)>, int (llvm::Error const&)>::__clone() const + 1496 at functional:1340 frame #10: 0x004fb2cb ld.lld`llvm::Triple::getOSTypeName(llvm::Triple::OSType) [inlined] StringRef(this=0x, Str=0x) + 14 at StringRef.h:83 frame #11: 0x004fb2bd ld.lld`llvm::Triple::getOSTypeName(Kind=UnknownOS) + 2541 at Triple.cpp:189 frame #12: 0x004f47ba ld.lld`std::__1::vector >::max_size(this=0x7fffd080) const + 42 at vector:956 frame #13: 0x004f3bc7 ld.lld`__split_buffer(this=0x000804819080, __cap=34435338368, __start=0, __a=0x0050) + 7 at __split_buffer:324 frame #14: 0x0046512b ld.lld`parseFlavor(std::__1::vector >&) [inlined] std::__1::vector >::operator[](this=0x007b, this=0x000804871c40, this=0x0050, LHS=StringRef at 0x7fffd298, __n=140737488343680, Str=0x000803bf6bbf, Str=0x7fffd080, RHS=StringRef at 0x7fffd288) + 23 at
[llvm-bugs] [Bug 23214] [META] Using LLD as FreeBSD's system linker
https://llvm.org/bugs/show_bug.cgi?id=23214 Bug 23214 depends on bug 31619, which changed state. Bug 31619 Summary: LLD segfaults while linking FreeBSD EFI loader with -error-limit=0 https://llvm.org/bugs/show_bug.cgi?id=31619 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 31619] LLD segfaults while linking FreeBSD EFI loader with -error-limit=0
https://llvm.org/bugs/show_bug.cgi?id=31619 ema...@freebsd.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from ema...@freebsd.org --- Fixed by r291765 -- 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 31620] New: undefined reference to '__sync_val_compare_and_swap_16'
https://llvm.org/bugs/show_bug.cgi?id=31620
Bug ID: 31620
Summary: undefined reference to
'__sync_val_compare_and_swap_16'
Product: libc++
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: dvyu...@google.com
CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com
Classification: Unclassified
I am on r291667. Linux/x86_64. libcxx and libcxxabi are checked out into
projects.
The program is:
#include
int main()
{
struct X { int a, b, c, d; };
std::atomic x;
X b, c;
x.compare_exchange_strong(b, c);
}
$ clang++ test.cc -std=c++11 -stdlib=libc++
/tmp/test-7383d8.o: In function `main':
/tmp/test.cc:(.text+0xd): undefined reference to
`__sync_val_compare_and_swap_16'
clang-4.0: error: linker command failed with exit code 1 (use -v to see
invocation)
Adding -latomic does not help, libatomic does not provide such function.
A new tsan test fails with a more elaborate error pointing to exact location,
for some reason it's generated for load function:
/tmp/lit_tmp_3Uws7l/atomic_test-af5f74.o: In function `load':
/llvm4/build/projects/compiler-rt/lib/tsan/libcxx_tsan_x86_64/include/c++/v1/atomic:893:
undefined reference to `__sync_val_compare_and_swap_16'
/tmp/lit_tmp_3Uws7l/atomic_test-af5f74.o:/llvm4/build/projects/compiler-rt/lib/tsan/libcxx_tsan_x86_64/include/c++/v1/atomic:893:
more undefined references to `__sync_val_compare_and_swap_16' follow
clang-3.9: error: linker command failed with exit code 1 (use -v to see
invocation)
What am I doing wrong?
--
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 31621] New: libcxxabi tests fail to build with ToT clang and c++1z
https://llvm.org/bugs/show_bug.cgi?id=31621 Bug ID: 31621 Summary: libcxxabi tests fail to build with ToT clang and c++1z Product: libc++abi Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: unassignedb...@nondot.org Reporter: bc...@codeaurora.org CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com Classification: Unclassified After clang commit below (r289019?) several libcxxabi tests fail to compile with the error below when using "-std=c++1z": error: ISO C++1z does not allow dynamic exception specifications [-Wdynamic-exception-spec] void f1() throw (long, char, double, std::bad_exception) ^~ llvm/projects/libcxxabi/test/unwind_05.pass.cpp:66:11: note: use 'noexcept(false)' instead void f1() throw (long, char, double, std::bad_exception) ^~ noexcept(false) 1 error generated. -- https://github.com/llvm-mirror/clang/commit/1f0155f24337194f4706f727db42f467244caa9e -- 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 31622] New: [meta] 4.0.0 Release Blockers
https://llvm.org/bugs/show_bug.cgi?id=31622 Bug ID: 31622 Summary: [meta] 4.0.0 Release Blockers Product: new-bugs Version: 4.0 Hardware: All OS: All Status: ASSIGNED Severity: normal Priority: P Component: new bugs Assignee: h...@chromium.org Reporter: h...@chromium.org CC: llvm-bugs@lists.llvm.org Classification: Unclassified This is the tracking bug for blockers of the 4.0.0 release. -- 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 31614] possible bad code generation
https://llvm.org/bugs/show_bug.cgi?id=31614 Hans Wennborg changed: What|Removed |Added Status|NEW |RESOLVED CC||ahmed.bouga...@gmail.com Resolution|--- |FIXED --- Comment #2 from Hans Wennborg --- (In reply to comment #1) > Hans, this looks like PR31367 > (https://llvm.org/bugs/show_bug.cgi?id=31367#c8). What do you think? Yes, that's exactly it. The bug was introduced in r265636, i.e. llvm 3.9. My best idea for working around it would be doing the fetch_add operation in a noinline function :-/ My fix in r291630, which will be in llvm 4, affects the repro like this: @@ -19,12 +19,13 @@ _Z13test_functionv: # @_Z13test_functionv .cfi_startproc # BB#0: # %entry + movl$1, %eax + lockxaddq %rax, foo(%rip) testq %rax, %rax setns %al - lockincqfoo(%rip) movl$value_a, %ecx movl$value_b, %edx - cmovgq %rcx, %rdx + cmovnsq %rcx, %rdx cmpl$100, (%rdx) je .LBB1_3 # BB#1: @@ -37,11 +38,12 @@ movl$foo+16, %eax cmovneq %rcx, %rax lockincq(%rax) + movl$1, %eax + lockxaddq %rax, foo(%rip) testq %rax, %rax setns %al - lockincqfoo(%rip) movl$value_b, %esi - cmovgq %rdx, %rsi + cmovnsq %rdx, %rsi cmpl$100, (%rsi) jne .LBB1_2 .LBB1_3:# %if.end.thread -- 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 31623] New: Regression in std::vector initialization in clang++ 3.9.x
https://llvm.org/bugs/show_bug.cgi?id=31623
Bug ID: 31623
Summary: Regression in std::vector initialization in clang++
3.9.x
Product: clang
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: d...@mapbox.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
clang 3.9.0 and 3.9.1 refuse to compile code that worked in 3.8.1:
```
#include
int main() {
mapbox::geometry::polygon polygon = {{ {{ { 0, 0 }, { 0, 45 }, {
45, 45 }, { 45, 0 } }} }};
}
```
mapbox/geometry/polygon.hpp can be found here:
https://github.com/mapbox/geometry.hpp/blob/master/include/mapbox/geometry/polygon.hpp
That errors with: `error: no matching constructor for initialization of 'const
mapbox::geometry::linear_ring'.
However this works:
```
Polygon polygon = { {{ { 0, 0 }, { 0, 45 }, { 45, 45 }, { 45, 0 } }} };
```
--
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 31624] New: static method invocation via objects are not considered constexpr
https://llvm.org/bugs/show_bug.cgi?id=31624
Bug ID: 31624
Summary: static method invocation via objects are not
considered constexpr
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: C++14
Assignee: unassignedclangb...@nondot.org
Reporter: m...@godbolt.org
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Consider the following (unusual) code:
struct Foo { static constexpr bool hasBar() { return true; } };
void test(const Foo &f) {
static_assert(Foo::hasBar(), ""); // -is ok
static_assert(f.hasBar(), ""); // fails on clang trunk 291576, works in GCC
}
(also on https://godbolt.org/g/qwzYvc )
All clang versions I tested it on fail with "error: static_assert expression is
not an integral constant expression". GCC and CL both allow this and consider
the call to the static method hasBar via the actual object f to be constexpr.
It's not clear to me which behaviour is correct, though instinctively I'd
imagine it to be valid to allow such calls as constexpr.
--
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 31624] static method invocation via objects are not considered constexpr
https://llvm.org/bugs/show_bug.cgi?id=31624 Richard Smith changed: What|Removed |Added Status|NEW |RESOLVED CC||richard-l...@metafoo.co.uk Resolution|--- |INVALID --- Comment #1 from Richard Smith --- Nope, GCC and CL are wrong. [expr.const]/2.10: "[An expression is not a constant expression if it would evaluate] an id-expression that refers to a variable or data member of reference type unless the reference has a preceding initialization and either — it is initialized with a constant expression or — its lifetime began within the evaluation of e;" Because the expression uses the name 'f' and that name cannot be evaluated, the expression is not a constant expression. It doesn't matter that the callee is a static function; evaluation of the LHS must succeed. Consider: (something with arbitrary non-constant side effects, f).hasBar() This is obviously not constant. -- 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 31625] New: -fno-zero-initialized-in-bss -fno-common and tentative definitions
https://llvm.org/bugs/show_bug.cgi?id=31625 Bug ID: 31625 Summary: -fno-zero-initialized-in-bss -fno-common and tentative definitions Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Frontend Assignee: unassignedclangb...@nondot.org Reporter: hst...@ca.ibm.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Clang's support for -fno-zero-initialized-in-bss does not match GCC's. In particular, when using -fno-common, tentative definitions are still placed by GCC into BSS. Online compiler: http://melpon.org/wandbox/permlink/76ugV7cPaxxqjIMl ### Source (): int x; ### Compiler invocation: clang -c -o a.o -x c -fno-common -fno-zero-initialized-in-bss - ### Additional commands: objdump -wt a.o | grep -P '\b''x\b' ### Expected output: g O .bss0004 x ### Actual output: g O .data0004 x ### clang -v: clang version 4.0.0 (trunk 290110) Target: x86_64-unknown-linux-gnu Thread model: posix InstalledDir: /usr/local/llvm-head/bin 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.3 Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6 Candidate multilib: .;@m64 Candidate multilib: 32;@m32 Selected multilib: .;@m64 -- 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
