[llvm-bugs] [Bug 31803] Canonicalization of rbit for ARMv8 64 bit fails
https://llvm.org/bugs/show_bug.cgi?id=31803 Gonzalo BG changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #4 from Gonzalo BG --- So i've failed to reproduce this with clang trunk on aarch64: https://godbolt.org/g/DHS2xz clang 4.0 lowers __builtin_bitreverse to rbit properly. On x86 the 32 and 64 bit versions of bitreverse look very good, but the generated code for the 8-bit version looks worse than the naive implementation: https://godbolt.org/g/kAlOC7 I'm closing this and filling a new issue for the bitreverse.i8 instruction. -- 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 31810] New: llvm.bitreverse.i8 on x86 lowers to questionable assembly
https://llvm.org/bugs/show_bug.cgi?id=31810 Bug ID: 31810 Summary: llvm.bitreverse.i8 on x86 lowers to questionable assembly Product: clang Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: LLVM Codegen Assignee: unassignedclangb...@nondot.org Reporter: gonzalob...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified On x86 the 32 and 64 bit versions of bitreverse look very good, but the generated code for the 8-bit version looks worse than the naive implementation: https://godbolt.org/g/kAlOC7 @bitrev_8_naive(unsigned char) mov eax, 2149582850 imulrax, rdi movabs rcx, 36578664720 and rcx, rax movabs rax, 4311810305 imulrax, rcx shr rax, 32 ret vs llvm.bitreverse.i8: @bitrev_8(unsigned char) rol dil, 4 mov eax, edi and al, 51 shl al, 2 and dil, -52 shr dil, 2 or dil, al mov eax, edi and al, 85 add al, al and dil, -86 shr dil or dil, al mov eax, edi ret -- 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 31811] New: return value propagation in asm/naked function
https://llvm.org/bugs/show_bug.cgi?id=31811
Bug ID: 31811
Summary: return value propagation in asm/naked function
Product: libraries
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: Interprocedural Optimizations
Assignee: unassignedb...@nondot.org
Reporter: c...@remobjects.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
The null propagation code should not propagate function results for naked
functions as else it's impossible to have asm code that returns it's own value:
When having a naked function like:
; Function Attrs: naked noinline optnone
define i32 @callcatch(i32, i32) #3 !dbg !10103 {
BasicBlock8472:
call void asm "\0D\0Apushl %ebp\0D\0Amovl 8(%esp),%eax\0D\0Amovl 12(%esp),
%ebp\0D\0Acalll *%eax\0D\0Apopl %ebp\0D\0Aretl\0D\0A", ""(), !dbg !10104,
!srcloc !10106 // this returns in eax
ret i32 0, !dbg !10104
}
; Function Attrs: naked noinline optnone
define void @jumptocont(i32, i32, i32) #3 !dbg !10107 {
BasicBlock8473:
call void asm "\0D\0Amovl 12(%esp), %ebp\0D\0Amovl 4(%esp),
%eax\0D\0Amovl 8(%esp), %esp\0D\0Ajmpl *%eax\0D\0A", ""(), !dbg !10108,
!srcloc !10110
ret void, !dbg !10108
}
and calling code is like;
%530 = call i32 @callcatch(i32 %528, i32 %529) #3, !dbg !7648
store i32 %530, i32* %20, !dbg !7648
%531 = load i32, i32* %20, !dbg !7630
...
call void @jumptocont(i32 %531, i32 %532, i32 %533) #3, !dbg
However the return constant propagation code from
http://llvm.org/docs/doxygen/html/IPConstantPropagation_8cpp_source.html
finds the ret i32 0 and ends up calling jumptocont with i32 0 as a first
parameter, which wasn't what I wanted. Ending up like:
%189 = tail call i32 @callcatchn(i32 %188, i32 %12) #10, !dbg !7019
tail call void @jumptocont(i32 0, i32 %14, i32 %12) #10, !dbg !7022
ie using the ret i32 0 as input for jumptocont, which it shouldn't.
--
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 31812] New: libLLVMSupport.a gets linked twice during CMake based builds
https://llvm.org/bugs/show_bug.cgi?id=31812 Bug ID: 31812 Summary: libLLVMSupport.a gets linked twice during CMake based builds Product: Build scripts Version: 3.9 Hardware: Other OS: Linux Status: NEW Severity: normal Priority: P Component: cmake Assignee: unassignedb...@nondot.org Reporter: awais_be...@mentor.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Cross building LLVM 3.9.1 sometimes fail reporting undefined symbols in libLLVMSupport static library. Doing a bit of log digging shows that libLLVMSupport gets linked twice (both for NATIVE and target builds) and when this multiple linking step takes place concurrently the libLLVMSupport static library gets corrupted and the mentioned build failure is seen. This was discussed on the llvm-dev mailing list and I was asked to report this here. The mailing list entry is: http://lists.llvm.org/pipermail/llvm-dev/2017-January/109570.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 31813] New: Cannot parse numbers in linker script
https://llvm.org/bugs/show_bug.cgi?id=31813 Bug ID: 31813 Summary: Cannot parse numbers in linker script Product: lld Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: unassignedb...@nondot.org Reporter: jonathanchesterfi...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Given a linker script fragment like: .text 0x4000: lld reports: malformed number: 0x4000: Either of the following are accepted: .text 0x4000 : .text (0x4000): Changing from hex to decimal makes no difference. Expected behaviour: Identify 0x4000 as s number. -- 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 31814] New: MacroArgs getNumArguments() yields unexpected results: Twice the expected amount
https://llvm.org/bugs/show_bug.cgi?id=31814
Bug ID: 31814
Summary: MacroArgs getNumArguments() yields unexpected results:
Twice the expected amount
Product: clang
Version: 3.9
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: sebald.ziegler.maill...@ikolus.de
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Created attachment 17918
--> https://llvm.org/bugs/attachment.cgi?id=17918&action=edit
clang tool - which applied on the above example results in 4 instead of 2
Context: Writing a new clang tool
When using MacroArgs in this context:
void MacroExpands(const Token &MacroNameTok, const MacroDefinition &MD,
SourceRange Range, const MacroArgs *Args) {
...
}
to iterate over all macro arguments, Args->getNumArguments() yields twice the
expected amount of arguments. When trying to access the additional ones then
the program segfaults.
For this example:
#define MAX(x,y) ((x>y)?x:y)
int main(int argc, char** argv) {
int a=5;
int b=7;
return MAX(a,b);
}
Args->getNumArguments() is 4.
This does not seem to be intended behaviour. Or am I mistaken?
--
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 31154] offload library missing cmake build machinary
https://llvm.org/bugs/show_bug.cgi?id=31154 Jonas Hahnfeld changed: What|Removed |Added Status|NEW |RESOLVED CC||hah...@hahnjo.de Resolution|--- |WONTFIX --- Comment #1 from Jonas Hahnfeld --- liboffload is Intel's library for the Intel Xeon Phi. The now committed libomptarget is meant to be used with Clang and has support for CMake. -- 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 3316] Constant folding for 'frem' is flaky
https://llvm.org/bugs/show_bug.cgi?id=3316
simonby...@gmail.com changed:
What|Removed |Added
Status|RESOLVED|REOPENED
CC||simonby...@gmail.com
Resolution|FIXED |---
--- Comment #9 from simonby...@gmail.com ---
I'm seeing a similar problem, though for different constant values, in LLVM
3.9.1:
$ cat frem.ll
define double @test1() {
entry:
%y = frem double 3.00e-01, 1.00e-02
ret double %y
}
Compiled without optimisations gives the correct answer:
$ llc frem.ll && ./frem
0x1.47ae147ae1471p-7
However applying a constprop pass gives an incorrect answer:
$ opt -S -constprop frem.ll
; ModuleID = 'frem.ll'
source_filename = "frem.ll"
define double @test1() {
entry:
ret double 0.00e+00
}
downstream issue: https://github.com/JuliaLang/julia/issues/14089
--
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 31815] New: spurious Wunused-lambda-capture warning?
https://llvm.org/bugs/show_bug.cgi?id=31815
Bug ID: 31815
Summary: spurious Wunused-lambda-capture warning?
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: C++14
Assignee: unassignedclangb...@nondot.org
Reporter: rhalber...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
#include
auto sq(int c, int x) { return c * x * x; }
struct S {
template
void for_each(Fun fun) const {
for (auto i = 1; i < 4; ++i) {
fun(i);
}
}
};
int main()
{
S s;
auto sum = 0;
s.for_each([&, i = 2](auto c) mutable {
sum += sq(c, i++);
});
std::cout << sum; // 70 = 1 * 4 + 2 * 9 + 3 * 16
}
Works with clang up to 4.0 and gcc up to 7.0 SVN. Gives -Wunused-lambda-capture
for Clang 5.0 SVN tip-of-trunk
See also http://stackoverflow.com/q/41960347/819272
--
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 31816] New: Clang-CL diagnoses ternary ambiguity which cl.exe allows
https://llvm.org/bugs/show_bug.cgi?id=31816
Bug ID: 31816
Summary: Clang-CL diagnoses ternary ambiguity which cl.exe
allows
Product: clang
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: steve...@gmail.com
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org
Classification: Unclassified
Given
struct MyBool
{
MyBool(bool b = false) {}
operator bool() const { return false; }
};
int main()
{
MyBool mb;
bool result = true ? false : mb;
return 0;
}
C:\dev\tmp>cl /c main.cpp
Microsoft (R) C/C++ Optimizing Compiler Version 19.00.24325.6 for x86
Copyright (C) Microsoft Corporation. All rights reserved.
main.cpp
C:\dev\tmp>"c:\dev\src\llvm\build\Release\msbuild-bin\cl.exe" /c main.cpp
main.cpp(11,21): error: conditional expression is ambiguous; 'bool' can be
converted to 'MyBool' and vice versa
bool result = true ? false : mb;
^ ~ ~~
1 error generated.
It could be considered to match the behavior of cl.exe
--
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 31817] New: AVX512 Regression: KNL backend does not use KNL processor features, SKX works
https://llvm.org/bugs/show_bug.cgi?id=31817
Bug ID: 31817
Summary: AVX512 Regression: KNL backend does not use KNL
processor features, SKX works
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Backend: X86
Assignee: unassignedb...@nondot.org
Reporter: wenzel.ja...@epfl.ch
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
I've noticed a serious performance and code generation regression on Clang's
KNL (= Knight's Landing) target.
With the latest trunk version of Clang & LLVM, the compiler no longer makes use
of any of the new AVX512 architectural features when working with non-512bit
registers (XMM & ZMM). This includes making full use of all 32 registers
(instead of 16) and using extensions such as builtin broadcasting of constants.
Losing half of the registers in particular is a serious performance regression
-- this wasn't the case with older versions of Clang.
Interestingly, the SKX == skylake-avx512 target remains unaffected.
Here is an example for the broadcasting of constants. Consider the following
snippet:
#include
__m256 mul_constant(__m256 x) {
return _mm256_mul_ps(x, _mm256_set1_ps(1234.f));
}
Compiling this for the "SKX" target produces the following code:
$ clang-5.0 -march=knl -O3 -S -fomit-frame-pointer test.c -o test.o
Assembly (cleaned up):
_mul_constant:
vmulps LCPI0_0(%rip){1to8}, %ymm0, %ymm0<- good!
retq
On the other hand, compiling for "KNL" yields
$ clang-5.0 -march=knl -O3 -S -fomit-frame-pointer test.c -o test.o
Assembly (cleaned up):
_mul_constant:
vbroadcastssLCPI0_0(%rip), %ymm1<- ?!?
vmulps %ymm1, %ymm0, %ymm0 <- code should be
identical
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 31818] New: No support for gcc "alloc_align" function attribute
https://llvm.org/bugs/show_bug.cgi?id=31818 Bug ID: 31818 Summary: No support for gcc "alloc_align" function attribute Product: clang Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: marina.yats...@intel.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified The following compiles with gcc 6.3 but doesn't compile with llvm: void* my_memalign(int, int) __attribute__((alloc_align(1))); The alloc_align attribute documentation can be found here: https://gcc.gnu.org/onlinedocs/gcc-4.9.2/gcc/Function-Attributes.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 31782] Linking against macOS prebuilt binaries causes linker warnings around std::__1::__call_once_proxy
https://llvm.org/bugs/show_bug.cgi?id=31782 Hans Wennborg changed: What|Removed |Added Status|NEW |RESOLVED CC|h...@hanshq.net |h...@chromium.org Resolution|--- |FIXED --- Comment #2 from Hans Wennborg --- Merged in r293645. -- 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] [meta] 4.0.0 Release Blockers
https://llvm.org/bugs/show_bug.cgi?id=31622 Bug 31622 depends on bug 31782, which changed state. Bug 31782 Summary: Linking against macOS prebuilt binaries causes linker warnings around std::__1::__call_once_proxy https://llvm.org/bugs/show_bug.cgi?id=31782 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 31710] Assertion `ChainNode->getOpcode() != ISD::DELETED_NODE && "Deleted node left in chain"' failed.
https://llvm.org/bugs/show_bug.cgi?id=31710 Hans Wennborg changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #13 from Hans Wennborg --- (In reply to comment #12) > Fixed on trunk in r293522. > > Hans: would you mind cherry picking this into 4.0? Merged in r293650. -- 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] [meta] 4.0.0 Release Blockers
https://llvm.org/bugs/show_bug.cgi?id=31622 Bug 31622 depends on bug 31710, which changed state. Bug 31710 Summary: Assertion `ChainNode->getOpcode() != ISD::DELETED_NODE && "Deleted node left in chain"' failed. https://llvm.org/bugs/show_bug.cgi?id=31710 What|Removed |Added Status|ASSIGNED|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 31820] New: operator<(std::nullptr_t, std::nullptr_t) should be allowed
https://llvm.org/bugs/show_bug.cgi?id=31820 Bug ID: 31820 Summary: operator<(std::nullptr_t, std::nullptr_t) should be allowed Product: libc++ Version: 4.0 Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: unassignedclangb...@nondot.org Reporter: jared.gr...@gmail.com CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com Classification: Unclassified Recently, Richard Smith made a change to address two DR's: Commit: https://github.com/llvm-mirror/clang/commit/c1d70e9b5c41fdb4c565638715a03a83503b7fae The gist of the patch was to disallow "nullptr < p", which I agree makes sense. However, when p is actually std::nullptr_t, then it is now a compiler error, and I don't agree with this. std::nullptr_t should be a regular type in all the Stepanov ways unless there's a good reason to disallow it. I don't see why the std::nullptr_t should not be totally ordered (in the trivial way). This is not a theoretical problem because it did break a line of code in a JSON library that I use. It was easy to work around but I dont think the code should be disallowed: https://github.com/dropbox/json11/blob/master/json11.cpp#L166 Here, the code ends up trying to do "this->m_value < other.m_value" where both members are std::nullptr_t (in the implementation for Value). I would like to ask that libc++ put back the overload to make "nullptr < nullptr" allowed as an extension. GCC and MSVC both allow this, and clang did until the latest version. -- 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 31821] New: Inconsistent error message for unqualifed address of member
https://llvm.org/bugs/show_bug.cgi?id=31821
Bug ID: 31821
Summary: Inconsistent error message for unqualifed address of
member
Product: clang
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: tdeli...@uwaterloo.ca
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org
Classification: Unclassified
When given the following code, clang generates an error and proposes a fix to
the given error :
-
class parent { protected:
virtual void foo() = 0;
};
template class child : public parent {
void (parent::*foo_ptr)() = &foo;
};
-
$ clang private.cpp -std=c++11
private.cpp:7:30: error: must explicitly qualify name of member function
when taking its address
void (parent::*foo_ptr)() = &foo;
^~~~
parent::
1 error generated.
Updating the code according to the error message still fails :
-
class parent { protected:
virtual void foo() = 0;
};
template class child : public parent {
void (parent::*foo_ptr)() = &parent::foo;
};
-
$ clang private.cpp -std=c++11
private.cpp:6:39: error: 'foo' is a protected member of 'parent'
void (parent::*foo_ptr)() = &parent::foo;
^
private.cpp:2:15: note: must name member using the type of the current
context 'child'
virtual void foo() = 0;
^
1 error generated.
The error messages should be consistent and propose fixes that will not
generate more errors.
--
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 31822] New: Unknown builtin type! UNREACHABLE executed at ASTContext.cpp:1683!
https://llvm.org/bugs/show_bug.cgi?id=31822
Bug ID: 31822
Summary: Unknown builtin type! UNREACHABLE executed at
ASTContext.cpp:1683!
Product: new-bugs
Version: unspecified
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: yaron.ke...@gmail.com
CC: dblai...@gmail.com, llvm-bugs@lists.llvm.org
Classification: Unclassified
clang version 5.0.0 (trunk 293644)
clang -c -std=c++11 of:
struct stringer_for {
stringer_for(int);
};
template void do_log(Args &&args) {
[](auto &&) {}(stringer_for(args));
}
void foo() { do_log(2); }
--
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 31808] [InstCombine] miscompile at -O2 with revision 257897
https://llvm.org/bugs/show_bug.cgi?id=31808 Hans Wennborg changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Hans Wennborg --- (In reply to comment #4) > (In reply to comment #1) > > Hans, think this should be a blocker for 4.0? > > Sounds like we have a simple fix, so let's do that. I'll reply on the commit > email to discuss merging. r293669. -- 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] [meta] 4.0.0 Release Blockers
https://llvm.org/bugs/show_bug.cgi?id=31622 Bug 31622 depends on bug 31808, which changed state. Bug 31808 Summary: [InstCombine] miscompile at -O2 with revision 257897 https://llvm.org/bugs/show_bug.cgi?id=31808 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 31823] New: Pick r293673 to 4.0 branch to fix code generation crash
https://llvm.org/bugs/show_bug.cgi?id=31823 Bug ID: 31823 Summary: Pick r293673 to 4.0 branch to fix code generation crash Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Common Code Generator Code Assignee: unassignedb...@nondot.org Reporter: ma...@braunis.de CC: llvm-bugs@lists.llvm.org Classification: Unclassified r293673 is an obvious fix for a code generation crash/assert that should get picked for the 4.0 branch. -- 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 31223] [X86][AVX512] Should KSHIFT map to X86ISD::VSHLI and VSRLI ?
https://llvm.org/bugs/show_bug.cgi?id=31223 Craig Topper changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Craig Topper --- I didn't know this bug existed. I noticed the same weird thing you did. Closing as fixed in r293448. -- 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 31824] New: Support /WHOLEARCHIVE
https://llvm.org/bugs/show_bug.cgi?id=31824 Bug ID: 31824 Summary: Support /WHOLEARCHIVE Product: lld Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: COFF Assignee: unassignedb...@nondot.org Reporter: r...@google.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified link.exe grew a /wholearchive flag in VS2015 update 2: https://msdn.microsoft.com/en-us/library/mt732963.aspx We need to support that. -- 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 31825] New: ClangConfig find_package() fix backport (r293632)
https://llvm.org/bugs/show_bug.cgi?id=31825 Bug ID: 31825 Summary: ClangConfig find_package() fix backport (r293632) Product: clang Version: 4.0 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: mgo...@gentoo.org CC: llvm-bugs@lists.llvm.org Classification: Unclassified Please backport r293632 to 4.0.0. This is necessary to ensure that prefixed clang install does not get accidentally mixed with another LLVM install on PATH, e.g. when building LLDB. -- 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 31826] New: Clang sometimes does not properly link classes inherited from dllimported classes
https://llvm.org/bugs/show_bug.cgi?id=31826
Bug ID: 31826
Summary: Clang sometimes does not properly link classes
inherited from dllimported classes
Product: clang
Version: 3.9
Hardware: PC
OS: other
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: m...@groundctl.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Code is as follows:
==> x.cpp <==
#define DECL __declspec(dllexport)
#include "header.h"
==> y.cpp <==
#define DECL __declspec(dllimport)
#include "header.h"
int main() {
t2 s;
}
==> header.h <==
struct DECL t {
virtual void fun() = 0;
};
struct t2 : t {
virtual void fun() {}
};
When using mingw64 6.2, if x.cpp is compiled as x.dll and y.cpp is compiled as
an executable linking x.dll, the linker fails with undefined references to
`_imp___ZTV1t' and `typeinfo for t'. This code works fine with both gcc 6.2
and Visual Studio 2015.
Adding a virtual function to t defined in x.cpp causes this issue to go away.
--
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 31781] -Wunused-const-variable doesn't warn for ObjC types if ARC is enabled
https://llvm.org/bugs/show_bug.cgi?id=31781 John McCall changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID |--- --- Comment #2 from John McCall --- No, I think warning about an unused global variable is still pretty reasonable under ARC. There are plenty of ways to suppress the warning if you're really relying on the side-effects of destruction. -- 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 31827] New: Crash when declaring friend with full namespace and decltype(auto)
https://llvm.org/bugs/show_bug.cgi?id=31827
Bug ID: 31827
Summary: Crash when declaring friend with full namespace and
decltype(auto)
Product: clang
Version: 3.9
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Frontend
Assignee: unassignedclangb...@nondot.org
Reporter: gufi...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Minimal case:
namespace code {
template
decltype(auto) test(T&&);
struct Test {
template
friend decltype(auto) ::code::test(T&&);
};
}
Removing ::code:: make this code compile under clang.
--
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 31817] AVX512 Regression: KNL backend does not use KNL processor features, SKX works
https://llvm.org/bugs/show_bug.cgi?id=31817 Wenzel Jakob changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #3 from Wenzel Jakob --- You are right! -- and my bug report was nonsense. I had always assumed that the extension to 32 registers and broadcasting were part of the EVEX encoding in AVX512F and thus also applied to XMM* and YMM* on KNL. But they clearly aren't (my KNL machine nicely confirms this by generating segfaults when it executes these instructions). Thank you for the clarification, and sorry about the noise! -- 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 31828] New: assembler warning "entity size for SHF_MERGE not specified"
https://llvm.org/bugs/show_bug.cgi?id=31828
Bug ID: 31828
Summary: assembler warning "entity size for SHF_MERGE not
specified"
Product: new-bugs
Version: 3.9
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: a...@linaro.org
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
I found this while building the Linux kernel, in
drivers/soc/tegra/fuse/speedo-tegra124.c:
$ clang -Wall -O2 -no-integrated-as -fno-strict-overflow -c test.c
/tmp/test-d0fed2.s: Assembler messages:
/tmp/test-d0fed2.s:25: Warning: entity size for SHF_MERGE not specified
$ cat test.c
static int a[][1] __attribute__((__section__(".init.rodata"))) = {{}};
int b;
int fn1(void) {
for (;;)
if (a[b][0])
for (;;)
;
}
It appears to be related to a old bug that was marked fixed in 2010
https://llvm.org/bugs/show_bug.cgi?id=4650
--
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 31829] New: clang -Wuninitialized annoying false positive
https://llvm.org/bugs/show_bug.cgi?id=31829
Bug ID: 31829
Summary: clang -Wuninitialized annoying false positive
Product: new-bugs
Version: 3.9
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: a...@linaro.org
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
A common construct from the Linux kernel causes many false positive warnings at
the default warning level. The test case is mostly reduced but kept to look
like kernel code for clarity:
$ clang -c test.c
test.c:31:29: warning: variable 'c' is uninitialized when used within its own
initialization [-Wuninitialized]
DECLARE_COMPLETION_ONSTACK(c);
^
test.c:17:65: note: expanded from macro 'DECLARE_COMPLETION_ONSTACK'
struct completion work = COMPLETION_INITIALIZER_ONSTACK(work)
^~~~
test.c:14:36: note: expanded from macro 'COMPLETION_INITIALIZER_ONSTACK'
({ init_completion(&work); work; })
^~~~
1 warning generated.
$ gcc -Wall -Wextra -Wuninitialized -O2 -c test.c # no output
$ cat test.c
struct __wait_queue_head {
int lock;
};
typedef struct __wait_queue_head wait_queue_head_t;
struct completion {
unsigned int done;
wait_queue_head_t wait;
};
#define COMPLETION_INITIALIZER_ONSTACK(work) \
({ init_completion(&work); work; })
#define DECLARE_COMPLETION_ONSTACK(work) \
struct completion work = COMPLETION_INITIALIZER_ONSTACK(work)
extern void init_waitqueue_head(wait_queue_head_t *);
static inline void init_completion(struct completion *x)
{
x->done = 0;
init_waitqueue_head(&x->wait);
}
extern int f2(struct completion *);
int f1(void)
{
DECLARE_COMPLETION_ONSTACK(c);
return f2(&c);
}
There seems to be a special case for detecting "self-assignment in declaration"
in clang, which is usually a bug, but this specific construct is clearly
correct, as we do initialize the variable immediately before using 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 31830] New: clang: error: unable to execute command: Segmentation fault (core dumped)
https://llvm.org/bugs/show_bug.cgi?id=31830 Bug ID: 31830 Summary: clang: error: unable to execute command: Segmentation fault (core dumped) Product: new-bugs Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: valentin.g...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Encountered a bug while building Firefox on linux clang version 3.8.1-12ubuntu1 (tags/RELEASE_381/final) Target: x86_64-pc-linux-gnu Thread model: posix InstalledDir: /usr/bin https://gist.github.com/52432c9be7302c1d006a18425bd2ba9c clang-error.txt https://gist.github.com/f738992d753eeabeb38c0fb97c6f03ef ContentChild-1df279.cpp https://gist.github.com/ae529b3ddb5ea5d207b5af593618e4d5 ContentChild-1df279.sh -- 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 31831] New: clang-cl does not evaluate arguments left-to-right in initializer-list constructor call
https://llvm.org/bugs/show_bug.cgi?id=31831
Bug ID: 31831
Summary: clang-cl does not evaluate arguments left-to-right in
initializer-list constructor call
Product: clang
Version: trunk
Hardware: PC
OS: Windows 2000
Status: NEW
Severity: normal
Priority: P
Component: C++11
Assignee: unassignedclangb...@nondot.org
Reporter: h...@chromium.org
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org
Blocks: 13707
Classification: Unclassified
For example:
int f();
int g();
int h();
struct Base {
Base(int a, int b, int c);
};
struct Derived : public Base {
Derived();
};
Derived::Derived() : Base{f(), g(), h()} {}
MSVC: (https://godbolt.org/g/7T91wC)
f(), g(), h()
clang-cl: (https://godbolt.org/g/Xmb51J)
h(), g(), f()
clang linux: (https://godbolt.org/g/5aFLCF)
f(), g(), h()
This came up in Chromium recently, where some new code relies on using
initializer lists to force the order of evaluation.
--
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 31811] return value propagation in asm/naked function
https://llvm.org/bugs/show_bug.cgi?id=31811 Davide Italiano 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 31755] carry detection missed optimization in chained add-with-carry
https://llvm.org/bugs/show_bug.cgi?id=31755 deadalnix changed: What|Removed |Added Status|NEW |RESOLVED CC||deadal...@gmail.com Resolution|--- |DUPLICATE --- Comment #1 from deadalnix --- *** This bug has been marked as a duplicate of bug 31719 *** -- 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 31832] New: Cherry pick r293730 to 4.0 branch
https://llvm.org/bugs/show_bug.cgi?id=31832 Bug ID: 31832 Summary: Cherry pick r293730 to 4.0 branch Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: MC Assignee: unassignedb...@nondot.org Reporter: ma...@braunis.de CC: llvm-bugs@lists.llvm.org Classification: Unclassified r293730 fixes an assertion failure when printing ARM assembly using thread local variables. (See also the discussion in https://reviews.llvm.org/D29315) -- 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 31833] New: Apply r 292878 to 4.0 release branch
https://llvm.org/bugs/show_bug.cgi?id=31833 Bug ID: 31833 Summary: Apply r 292878 to 4.0 release branch Product: lld Version: unspecified Hardware: All OS: OpenBSD Status: NEW Severity: normal Priority: P Component: ELF Assignee: unassignedb...@nondot.org Reporter: b...@comstyle.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Fixes building shared libraries on OpenBSD. -- 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
