[llvm-bugs] [Bug 39901] clobbered return value from this-adjustment thunk returning a member pointer
https://bugs.llvm.org/show_bug.cgi?id=39901 Hans Wennborg changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #4 from Hans Wennborg --- Committed in r348569 -- 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 39908] New: [InstCombine] GEP is wrongly optimized for 32-bit targets
https://bugs.llvm.org/show_bug.cgi?id=39908
Bug ID: 39908
Summary: [InstCombine] GEP is wrongly optimized for 32-bit
targets
Product: new-bugs
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: mati...@gmail.com
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org
Forwarding https://github.com/rust-lang/rust/issues/52026
Minimal example by neivv and rkruppe:
```
target datalayout = "p:32:32"
%S = type { [2 x i32] }
define i1 @foo([0 x %S]* %p, i32 %n) {
%start.cast = bitcast [0 x %S]* %p to %S*
%end = getelementptr inbounds [0 x %S], [0 x %S]* %p, i32 0, i32 %n, i32 0,
i32 0
%end.cast = bitcast i32* %end to %S*
%last = getelementptr inbounds %S, %S* %end.cast, i32 -1
%cmp = icmp eq %S* %last, %start.cast
ret i1 %cmp
}
```
GodBolt link: https://godbolt.org/z/C84Axg
For 32 bit targets it turns to:
define i1 @foo([0 x %S]* %p, i32 %n) {
%cmp = icmp eq i32 %n, -536870911
ret i1 %cmp
}
While 64 bit targets are optimized correctly:
define i1 @foo([0 x %S]* %p, i32 %n) {
%cmp = icmp eq i32 %n, 1
ret i1 %cmp
}
Explanation of the issue from
https://github.com/rust-lang/rust/issues/52026#issuecomment-403628144:
In this issue, the code is comparing roughly (S *)slice_start == (S
*)slice_start + slice_len - 1.
This function is extracting the constant byte offset, -8, and dividing it by 8,
sizeof(S). However, before that, compiling to a 32-bit target, the values are
masked by PtrSizeMask 0x, which discards the sign bit of int64 and
gives +4294967288, which divided by 8 is the same 536870911 which ends up being
in the result.
--
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 39909] New: Build docs for macOS should mention DevToolsSecurity
https://bugs.llvm.org/show_bug.cgi?id=39909 Bug ID: 39909 Summary: Build docs for macOS should mention DevToolsSecurity Product: lldb Version: unspecified Hardware: All OS: MacOS X Status: NEW Severity: enhancement Priority: P Component: All Bugs Assignee: lldb-...@lists.llvm.org Reporter: martongab...@gmail.com CC: llvm-bugs@lists.llvm.org (macOS, mojave, Xcode 10.1) When we build LLDB for macOS with cmake/ninja via ssh and we want to execute "ninja check-lldb" then we must execute first: "sudo /usr/sbin/DevToolsSecurity --enable" This should be mentioned in the build docs. -- 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 39910] New: Libcxx should be a dependency of check-lldb target
https://bugs.llvm.org/show_bug.cgi?id=39910 Bug ID: 39910 Summary: Libcxx should be a dependency of check-lldb target Product: lldb Version: unspecified Hardware: PC OS: MacOS X Status: NEW Severity: enhancement Priority: P Component: All Bugs Assignee: lldb-...@lists.llvm.org Reporter: martongab...@gmail.com CC: llvm-bugs@lists.llvm.org macOS mojave, Xcode 10.1 Running "ninja check-lldb" fails with libcxx errors, unless libcxx is checked out into the llvm tree. -- 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 39911] New: Lambda call operator invoked if streamed to std::cout
https://bugs.llvm.org/show_bug.cgi?id=39911
Bug ID: 39911
Summary: Lambda call operator invoked if streamed to std::cout
Product: clang
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: golka.ger...@gmail.com
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
Consider the following code:
int main()
{
auto lam = [](auto x) {return x*2;};
std::cout << lam; // fails with: "error: invalid operands to binary
expression ('std::basic_ostream' and 'int')"
}
If a lambda is passed to std::cout compilation does not fail as expected. It
fails but for the wrong reason ("invalid operands to binary expression, rather
than "no matching function call"). It seems that the call operator is
instantiated (and called with iostream as input) somewhere in the overload
resolution. I think that this is not correct. The problem in my use case is,
that this breaks expression sfinae.
See the more comprehensive example here: https://godbolt.org/z/-6fz0o
The code works as expected with gcc and msvc, so I guess it's a clang problem.
--
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 39912] New: Change llvm call once check for PowerPC(ppc64le)
https://bugs.llvm.org/show_bug.cgi?id=39912 Bug ID: 39912 Summary: Change llvm call once check for PowerPC(ppc64le) Product: libraries Version: trunk Hardware: PC OS: other Status: NEW Severity: release blocker Priority: P Component: Backend: PowerPC Assignee: unassignedb...@nondot.org Reporter: sarvesh.ta...@ibm.com CC: llvm-bugs@lists.llvm.org, nemanja.i@gmail.com Created attachment 21200 --> https://bugs.llvm.org/attachment.cgi?id=21200&action=edit Patch to fix call_once errors on PowerPC64le This change is required to resolve the call_once related errors seen while building the Swift toolchain on PowerPC64LE. -- 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 39913] New: alpha.deadcode.UnreachableCode trivial false positive
https://bugs.llvm.org/show_bug.cgi?id=39913
Bug ID: 39913
Summary: alpha.deadcode.UnreachableCode trivial false positive
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Static Analyzer
Assignee: dcough...@apple.com
Reporter: abramo.bagn...@bugseng.com
CC: dcough...@apple.com, llvm-bugs@lists.llvm.org
The typescript below shows the wrong warning and the proof it is wrong:
abramo@igor:/tmp$ cat p.c
#include
void g() {
printf("reached\n");
}
void f(int btn) {
static int x = 0;
if (btn == x) {
if (btn != 0) {
g();
} else {
x = 2;
}
}
}
abramo@igor:/tmp$ cat q.c
extern void f(int);
int main() {
f(0);
f(2);
}
abramo@igor:/tmp$ scan-build-8 -enable-checker alpha.deadcode.UnreachableCode
gcc p.c q.c
scan-build: Using '/usr/lib/llvm-8/bin/clang' for static analysis
p.c:11:9: warning: This statement is never executed
g();
^
1 warning generated.
scan-build: 1 bug found.
scan-build: Run 'scan-view /tmp/scan-build-2018-12-07-124451-16359-1' to
examine bug reports.
abramo@igor:/tmp$ ./a.out
reached
--
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 39880] Trunk build fails rev 348300
https://bugs.llvm.org/show_bug.cgi?id=39880 Benedikt Tröster changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED -- 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 39714] -fast-isel=0 for armv7 can result in 4-byte Reload without corresponding 4-byte Spill
https://bugs.llvm.org/show_bug.cgi?id=39714 Tim Northover changed: What|Removed |Added Resolution|--- |FIXED CC||t.p.northo...@gmail.com Status|NEW |RESOLVED --- Comment #1 from Tim Northover --- It's another ARMFrameLowering.cpp bug. There is an earlier store that LLVM thinks is going to the same slot, but it's miscalculating the offset from r6 in the load because it thinks the neighbouring "sub sp, sp, ..." affects it. Should be fixed in r348591. -- 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 39914] New: Incorrect code when right shifting signed int by more than its size
https://bugs.llvm.org/show_bug.cgi?id=39914
Bug ID: 39914
Summary: Incorrect code when right shifting signed int by more
than its size
Product: clang
Version: 7.0
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: bugzi...@poradnik-webmastera.com
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org,
neeil...@live.com, richard-l...@metafoo.co.uk
When signed int is shifted right by more than its width, results will be either
0 or -1. However clang always evaluates this as 0. Sample code below, compiled
with "-O3 -march=skylake-avx512".
[code]
void f();
void g();
void test(int n)
{
if (n >> 222)
f();
else
g();
}
[/code]
[asm]
test(int): # @test(int)
jmp g() # TAILCALL
[/asm]
--
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 39914] Incorrect code when right shifting signed int by more than its size
https://bugs.llvm.org/show_bug.cgi?id=39914 Hal Finkel changed: What|Removed |Added Resolution|--- |INVALID Status|NEW |RESOLVED --- Comment #1 from Hal Finkel --- While I understand why you think that should be true, given how the operation might work at the hardware level, the C/C++ specifications don't define the behavior of shifts greater-than or equal-to the number of bits in the type. Clang's behavior here is not a bug. The optimizer optimizes code assuming that code that exhibits undefined behavior is not actually executed (and, thus, it doesn't really matter what it does). You might find it useful to compile your code with -fsanitize=undefined to enable the undefined-behavior sanitizer. -- 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 39915] New: LLVMDisasmInstruction returns 1 for invalid instruction (x86 prefix only)
https://bugs.llvm.org/show_bug.cgi?id=39915
Bug ID: 39915
Summary: LLVMDisasmInstruction returns 1 for invalid
instruction (x86 prefix only)
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: MC
Assignee: unassignedb...@nondot.org
Reporter: p.anto...@catenacyber.fr
CC: llvm-bugs@lists.llvm.org
I am doing differential fuzzing between llvm-mc and capstone.
The following snippet of code has `LLVMDisasmInstruction` returning 1.
But the documentation http://llvm.org/doxygen/group__LLVMCDisassembler.html
states that it should return 0 if there was no valid instruction.
It looks to me that a x86 prefix without anything else is not a valid
instruction.
```
extern "C" int LLVMFuzzerReturnOneInput() {
LLVMDisasmContextRef Ctx;
uint8_t Data[1] = {0xf2};
size_t Size = 1;
char AssemblyText[80];
std::vector DataCopy(Data, Data + Size);
uint8_t *p = DataCopy.data();
int r = 1;
Ctx = LLVMCreateDisasmCPUFeatures("x86_64", "", "", nullptr, 0, nullptr,
nullptr);
if (LLVMSetDisasmOptions(Ctx, LLVMDisassembler_Option_AsmPrinterVariant) ==
0) {
abort();
}
assert(Ctx);
if (LLVMDisasmInstruction(Ctx, p, Size, 0, AssemblyText, 80) > 0) {
r = 0;
}
LLVMDisasmDispose(Ctx);
return r;
}
```
--
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] Issue 11778 in oss-fuzz: llvm/clang-fuzzer: Stack-overflow in clang::FunctionProtoType::getExtProtoInfo
Comment #1 on issue 11778 by ClusterFuzz-External: llvm/clang-fuzzer: Stack-overflow in clang::FunctionProtoType::getExtProtoInfo https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=11778#c1 ClusterFuzz has detected this issue as fixed in range 201812060233:201812070233. Detailed report: https://oss-fuzz.com/testcase?key=5638360400396288 Project: llvm Fuzzer: libFuzzer_llvm_clang-fuzzer Fuzz target binary: clang-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Stack-overflow Crash Address: 0x7ffd5bf79b88 Crash State: clang::FunctionProtoType::getExtProtoInfo clang::FunctionProtoType::Profile llvm::ContextualFoldingSetclang::ASTContext&>::NodeEq Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201806300739:201807010808 Fixed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201812060233:201812070233 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5638360400396288 See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md for more information. If you suspect that the result above is incorrect, try re-doing that job on the test case report page. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 11778 in oss-fuzz: llvm/clang-fuzzer: Stack-overflow in clang::FunctionProtoType::getExtProtoInfo
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #2 on issue 11778 by ClusterFuzz-External: llvm/clang-fuzzer: Stack-overflow in clang::FunctionProtoType::getExtProtoInfo https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=11778#c2 ClusterFuzz testcase 5638360400396288 is verified as fixed, so closing issue as verified. If this is incorrect, please file a bug on https://github.com/google/oss-fuzz/issues/new -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 32023] Failure to recognize rotate when subtract and shifts are fed by truncates from different types
https://bugs.llvm.org/show_bug.cgi?id=32023 Sanjay Patel changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #9 from Sanjay Patel --- Reopening - had to disable the truncation: https://reviews.llvm.org/rL348604 ...because it conflicts with an existing combine. -- 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] Issue 10371 in oss-fuzz: llvm/clang-fuzzer: ASSERT: 0 && "Invalid SLocOffset or bad function choice"
Updates: Labels: Deadline-Approaching Comment #4 on issue 10371 by sheriff...@chromium.org: llvm/clang-fuzzer: ASSERT: 0 && "Invalid SLocOffset or bad function choice" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=10371#c4 This bug is approaching its deadline for being fixed, and will be automatically derestricted within 7 days. If a fix is planned within 2 weeks after the deadline has passed, a grace extension can be granted. - Your friendly Sheriffbot -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 10380 in oss-fuzz: llvm/clang-fuzzer: Stack-overflow in clang::Preprocessor::CachingLex
Updates: Labels: Deadline-Approaching Comment #3 on issue 10380 by sheriff...@chromium.org: llvm/clang-fuzzer: Stack-overflow in clang::Preprocessor::CachingLex https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=10380#c3 This bug is approaching its deadline for being fixed, and will be automatically derestricted within 7 days. If a fix is planned within 2 weeks after the deadline has passed, a grace extension can be granted. - Your friendly Sheriffbot -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 39911] Lambda call operator invoked if streamed to std::cout
https://bugs.llvm.org/show_bug.cgi?id=39911 hst...@ca.ibm.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #3 from hst...@ca.ibm.com --- > The code works as expected with gcc and msvc, so I guess it's a clang problem. ICC and MSVC behave the same as Clang here: ICC: https://godbolt.org/z/nncyHU MSVC: https://godbolt.org/z/U7k7zj GCC behaves the same if the lambda parameter is declared as `auto &` to better match the function-to-pointer parameter types: https://godbolt.org/z/WQ5mvq -- 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] Issue 11782 in oss-fuzz: llvm/clang-fuzzer: Stack-overflow in processTypeAttrs
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@gmail.com, eney...@google.com, llvm-b...@lists.llvm.org, j...@chromium.org, v...@apple.com, mitchphi...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer Proj-llvm Reported-2018-12-07 Type: Bug New issue 11782 by ClusterFuzz-External: llvm/clang-fuzzer: Stack-overflow in processTypeAttrs https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=11782 Detailed report: https://oss-fuzz.com/testcase?key=5694989946847232 Project: llvm Fuzzer: libFuzzer_llvm_clang-fuzzer Fuzz target binary: clang-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Stack-overflow Crash Address: 0x7ffcc67deff8 Crash State: processTypeAttrs ConvertDeclSpecToType GetDeclSpecTypeForDeclarator Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201808310127:201809010125 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5694989946847232 Issue filed automatically. See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md for more information. When you fix this bug, please * mention the fix revision(s). * state whether the bug was a short-lived regression or an old bug in any stable releases. * add any other useful information. This information can help downstream consumers. If you need to contact the OSS-Fuzz team with a question, concern, or any other feedback, please file an issue at https://github.com/google/oss-fuzz/issues. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 39916] New: Invalid code generation and ICE when template references local static constexpr variable by pointer
https://bugs.llvm.org/show_bug.cgi?id=39916
Bug ID: 39916
Summary: Invalid code generation and ICE when template
references local static constexpr variable by pointer
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: release blocker
Priority: P
Component: C++'17
Assignee: unassignedclangb...@nondot.org
Reporter: andyg1...@hotmail.co.uk
CC: blitzrak...@gmail.com, erik.pilking...@gmail.com,
llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk
The following minimised code fragment generates incorrect code in all clang
version from 4.0 (oldest I have) up to trunk (tested using godbolt and -O2
-std=c++1z):
template
struct S
{
static int Value() { return *X; }
};
template
int fn()
{
static constexpr int value = 10;
return S<&value>::Value();
}
int test()
{
return fn(); // will return 0 not 10
}
There are ways that the code can be made to produce correct values:
1. Move the 'static constexpr int value = 10' line up to the global scope
2. Remove the template from 'int fn()' to make it a plain function
3. Change the template parameter in struct S from 'const int* X' to 'const
int& X'
So, for example, the following compiles correctly...
template
struct S
{
static int Value() { return X; }
};
template
int fn()
{
static constexpr int value = 10;
return S::Value();
}
int test()
{
return fn(); // will return 0 not 10
}
The following, slightly more complex example, crashes the compiler:
template
struct S
{
static int Value() { return *X; }
};
template
int fn()
{
const int c = ([]() {
static constexpr int value = 10;
return S<&value>::Value();
})();
return c;
}
int test()
{
return fn();
}
Again, any one of the three "solutions" above solves the problem. So the issue
seems to be in the specific use of pointers in the template for S when called
from another templated function.
However, while we're here, this also crashes the compiler:
template
struct S
{
static int Value() { return X; }
};
template
int fn()
{
const int c = ([]() {
static int value = 10; // not const or constexpr!
return S::Value();
})();
return c;
}
int test()
{
return fn();
}
But utilising a second "solution" from above means this is ok again:
template
struct S
{
static int Value() { return X; }
};
int fn()
{
const int c = ([]() {
static int value = 10;
return S::Value();
})();
return c;
}
int test()
{
return fn();
}
--
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 39917] New: r343018 triggers miscompile of Regression-C++-throw_rethrow_test
https://bugs.llvm.org/show_bug.cgi?id=39917 Bug ID: 39917 Summary: r343018 triggers miscompile of Regression-C++-throw_rethrow_test Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Common Code Generator Code Assignee: unassignedb...@nondot.org Reporter: v...@apple.com CC: llvm-bugs@lists.llvm.org I traced down a miscompile I’m seeing to this commit. Consider these two IR files (generated from SingleSource/Regression/C++/EH/Regression-C++-throw_rethrow_test). One is compiled normally (at -Os). The other is compiled with hot/cold splitting, which outlines a `resume` instruction and moves some code into a “cold” function. Before this commit, both tests would terminate and print the correct result: - clang++ no-outlining.ll -o no-outlining && ./no-outlining # Prints correct result and exits. - clang++ with-outlining.ll -o with-outlining && ./with-outlining # Prints correct result and exits. (expected) $ ./no-outlining # (or ./with-outlining) 0: 1 1: 1 2: 1 3: 2 4: 2 5: 2 6: 3 7: 3 8: 3 However, after this commit, the “with-outlining” binary hangs: (bug) $ ./with-outlining.bad 0: 1 1: 1 2: 1 3: 2 4: 2 5: 2 ^C I've attached the assembly for the “with-outlining” binary before and after this commit. If I revert this commit locally, I get the expected result again on “with-outlining.ll”. -- 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 39918] New: [llvm-exegesis] DIV64r "snippet crashed while running"
https://bugs.llvm.org/show_bug.cgi?id=39918 Bug ID: 39918 Summary: [llvm-exegesis] DIV64r "snippet crashed while running" Product: tools Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: llvm-exegesis Assignee: unassignedb...@nondot.org Reporter: llvm-...@redking.me.uk CC: clement.cour...@gmail.com, gchate...@google.com, llvm-bugs@lists.llvm.org llvm-exegesis -mode=uops -opcode-name=DIV64r Check generated assembly with: /usr/bin/objdump -d /tmp/snippet-80e6ba.o --- mode:uops key: instructions: - 'DIV64r RSI' config: '' register_initial_values: - 'RSI=0x0' - 'RAX=0x0' - 'RDX=0x0' cpu_name:btver2 llvm_triple: x86_64-unknown-linux-gnu num_repetitions: 1 measurements:[] error: snippet crashed while running info:instruction is serial, repeating a random one. assembled_snippet: 48BE48B848BA48F7F648F7F648F7F648F7F648F7F648F7F648F7F648F7F648F7F648F7F648F7F648F7F648F7F648F7F648F7F648F7F6C3 latency fails in the same way -- 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 39919] New: store happening to wrongly loaded address with thumb2
https://bugs.llvm.org/show_bug.cgi?id=39919
Bug ID: 39919
Summary: store happening to wrongly loaded address with thumb2
Product: clang
Version: 7.0
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: LLVM Codegen
Assignee: unassignedclangb...@nondot.org
Reporter: raj.k...@gmail.com
CC: llvm-bugs@lists.llvm.org, neeil...@live.com,
richard-l...@metafoo.co.uk
Created attachment 21205
--> https://bugs.llvm.org/attachment.cgi?id=21205&action=edit
testcase
This issue pops up when compiling busybox for arm using thumb2 ISA. Getty
applet segfaults.
Program received signal SIGSEGV, Segmentation fault.
getty_main (argc=, argv=0x7efffd58) at loginutils/getty.c:561
warning: Source file is more recent than executable.
561 G.eol = '\r';
This is also present in the attached reproducer
clang -target armv7l-linux-gnueabihf -S -Os -mthumb getty.c
=
.code 16 @ @getty_main
.thumb_func
getty_main:
.fnstart
@ %bb.0:
.save {r4, r5, r6, r7, lr}
push{r4, r5, r6, r7, lr}
.setfp r7, sp, #12
add r7, sp, #12
.save {r11}
str r11, [sp, #-4]!
.pad#16
sub sp, #16
mov.w r0, #260
mov r6, r1
bl xzalloc <--- allocate ptr_to_globals
struct (return address of mem in r0)
ldr r2, .LCPI0_0
ldr r3, .LCPI0_1
.LPC0_0:
add r2, pc
ldr r5, .LCPI0_2
ldr r1, .LCPI0_3
.LPC0_1:
add r3, pc
ldr r4, [r2] <--- loads the address of
ptr_to_globals struct
.LPC0_2:
add r5, pc
str r0, [r2] <-- Stores the address
returned from xzalloc()
.LPC0_3:
add r1, pc
@APP
@NO_APP
str r3, [r0, #20]
add.w r2, r4, #20
str r5, [r0, #4]
movsr0, #13
strb.w r0, [r4, #68] <- Stores '\r' to globals+68 which is
location of ptr_to_globals.eol
addsr0, r4, #4
add.w r3, r4, #8
strdr2, r0, [sp]
add.w r2, r4, #16
mov r0, r6
str r4, [sp, #8]
bl getopt32
add sp, #16
ldr r11, [sp], #4
pop {r4, r5, r6, r7, pc}
.p2align2
===
As can be seen above, it has loaded address of ptr_to_globals into r4 before
return of xzalloc() in r0 is stored into 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 39550] Miscompilations on AArch64 since "[SimplifyCFG] don't sink common insts too soon"
https://bugs.llvm.org/show_bug.cgi?id=39550 Tom Stellard changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED Fixed By Commit(s)|r346203 r348444 |r346203 r348444 r348636 ||r348642 --- Comment #14 from Tom Stellard --- Merged: r348636 r348642 -- 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 39106] [meta] 7.0.1 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=39106 Bug 39106 depends on bug 39550, which changed state. Bug 39550 Summary: Miscompilations on AArch64 since "[SimplifyCFG] don't sink common insts too soon" https://bugs.llvm.org/show_bug.cgi?id=39550 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 39919] store happening to wrongly loaded address with thumb2
https://bugs.llvm.org/show_bug.cgi?id=39919 Eli Friedman changed: What|Removed |Added Resolution|--- |INVALID CC||efrie...@codeaurora.org Status|NEW |RESOLVED --- Comment #2 from Eli Friedman --- I can't reproduce the behavior you're seeing with the C testcase... but in any case, writing to a const variable is undefined behavior (C99 6.7.3 paragraph 5). -- 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 39920] New: [X86] Failure to use PHADDD on Intel CPUs on the second to last step of a v8i32 pairwise reduction
https://bugs.llvm.org/show_bug.cgi?id=39920
Bug ID: 39920
Summary: [X86] Failure to use PHADDD on Intel CPUs on the
second to last step of a v8i32 pairwise reduction
Product: libraries
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: Backend: X86
Assignee: unassignedb...@nondot.org
Reporter: craig.top...@gmail.com
CC: craig.top...@gmail.com, llvm-bugs@lists.llvm.org,
llvm-...@redking.me.uk, spatel+l...@rotateright.com
I think we should use HADDPS for the first reduction step of this on Intel CPUs
define fastcc i32 @pairwise_reduction4i32(<4 x i32> %rdx, i32 %f1) {
%rdx.shuf.1.0 = shufflevector <4 x i32> %rdx, <4 x i32> undef,<4 x i32>
%rdx.shuf.1.1 = shufflevector <4 x i32> %rdx, <4 x i32> undef,<4 x i32>
%bin.rdx8 = add <4 x i32> %rdx.shuf.1.0, %rdx.shuf.1.1
%rdx.shuf.2.0 = shufflevector <4 x i32> %bin.rdx8, <4 x i32> undef,<4 x i32>
%rdx.shuf.2.1 = shufflevector <4 x i32> %bin.rdx8, <4 x i32> undef,<4 x i32>
%bin.rdx9 = add <4 x i32> %rdx.shuf.2.0, %rdx.shuf.2.1
%r = extractelement <4 x i32> %bin.rdx9, i32 0
ret i32 %r
}
This is the assembly we get on sse4.1
pshufd $232, %xmm0, %xmm1 # xmm1 = xmm0[0,2,2,3]
pshufd $237, %xmm0, %xmm0 # xmm0 = xmm0[1,3,2,3]
paddd %xmm1, %xmm0
pshufd $229, %xmm0, %xmm1 # xmm1 = xmm0[1,1,2,3]
paddd %xmm0, %xmm1
movd%xmm1, %eax
retq
PHADDD uses 2 shuffles internally on Intel CPus, but as you can see the
assembly we emitted also uses 2 shuffles. So I don't think we saved anything by
avoiding PHADDD.
--
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 39921] New: [X86] AVX2 should use an extract_subvector and phadd for the first step of a pairwise v8i32 addition reduction
https://bugs.llvm.org/show_bug.cgi?id=39921
Bug ID: 39921
Summary: [X86] AVX2 should use an extract_subvector and phadd
for the first step of a pairwise v8i32 addition
reduction
Product: libraries
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: Backend: X86
Assignee: unassignedb...@nondot.org
Reporter: craig.top...@gmail.com
CC: craig.top...@gmail.com, llvm-bugs@lists.llvm.org,
llvm-...@redking.me.uk, spatel+l...@rotateright.com
For this IR I think we should use an extract subvector and a v4i32 phaddd for
the first step
define i32 @pairwise_reduction8i32(<8 x i32> %rdx, i32 %f1) {
%rdx.shuf.0.0 = shufflevector <8 x i32> %rdx, <8 x i32> undef, <8 x i32>
%rdx.shuf.0.1 = shufflevector <8 x i32> %rdx, <8 x i32> undef, <8 x i32>
%bin.rdx = add <8 x i32> %rdx.shuf.0.0, %rdx.shuf.0.1
%rdx.shuf.1.0 = shufflevector <8 x i32> %bin.rdx, <8 x i32> undef,<8 x i32>
%rdx.shuf.1.1 = shufflevector <8 x i32> %bin.rdx, <8 x i32> undef,<8 x i32>
%bin.rdx8 = add <8 x i32> %rdx.shuf.1.0, %rdx.shuf.1.1
%rdx.shuf.2.0 = shufflevector <8 x i32> %bin.rdx8, <8 x i32> undef,<8 x i32>
%rdx.shuf.2.1 = shufflevector <8 x i32> %bin.rdx8, <8 x i32> undef,<8 x i32>
%bin.rdx9 = add <8 x i32> %rdx.shuf.2.0, %rdx.shuf.2.1
%r = extractelement <8 x i32> %bin.rdx9, i32 0
ret i32 %r
}
Instead we generate this
vpshufd $232, %ymm0, %ymm1 # ymm1 = ymm0[0,2,2,3,4,6,6,7]
vpermq $232, %ymm1, %ymm1 # ymm1 = ymm1[0,2,2,3]
vpshufd $237, %ymm0, %ymm0 # ymm0 = ymm0[1,3,2,3,5,7,6,7]
vpermq $232, %ymm0, %ymm0 # ymm0 = ymm0[0,2,2,3]
vpaddd %xmm0, %xmm1, %xmm0
vpshufd $232, %xmm0, %xmm1 # xmm1 = xmm0[0,2,2,3]
vpshufd $237, %xmm0, %xmm0 # xmm0 = xmm0[1,3,2,3]
vpaddd %ymm0, %ymm1, %ymm0
vpshufd $229, %xmm0, %xmm1 # xmm1 = xmm0[1,1,2,3]
vpaddd %xmm1, %xmm0, %xmm0
vmovd %xmm0, %eax
That's 4 shuffles and vpaddd. But using vextracti128 and phaddd is only 3
shuffles on Intel hardware.
--
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] Issue 11788 in oss-fuzz: llvm/clang-fuzzer: Stack-overflow in clang::Lexer::LexTokenInternal
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@gmail.com, eney...@google.com, llvm-b...@lists.llvm.org, j...@chromium.org, v...@apple.com, mitchphi...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer Proj-llvm Reported-2018-12-08 Type: Bug New issue 11788 by ClusterFuzz-External: llvm/clang-fuzzer: Stack-overflow in clang::Lexer::LexTokenInternal https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=11788 Detailed report: https://oss-fuzz.com/testcase?key=5644306044420096 Project: llvm Fuzzer: libFuzzer_llvm_clang-fuzzer Fuzz target binary: clang-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Stack-overflow Crash Address: 0x7ffc5dbeee60 Crash State: clang::Lexer::LexTokenInternal clang::Lexer::Lex clang::Preprocessor::Lex Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201812060233:201812070233 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5644306044420096 Issue filed automatically. See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md for more information. When you fix this bug, please * mention the fix revision(s). * state whether the bug was a short-lived regression or an old bug in any stable releases. * add any other useful information. This information can help downstream consumers. If you need to contact the OSS-Fuzz team with a question, concern, or any other feedback, please file an issue at https://github.com/google/oss-fuzz/issues. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 33672] [Win][MSVC2017] Failed to find MSBuild toolsets directory
https://bugs.llvm.org/show_bug.cgi?id=33672 Mikhail Strelnikov changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #10 from Mikhail Strelnikov --- Since the file install.bat was removed, there is no reason to complain. -- 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 39540] Cherry-pick 345826, 345839, and 345838 into 7.0.1
https://bugs.llvm.org/show_bug.cgi?id=39540 Tom Stellard changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED Fixed By Commit(s)|r342152 r345826 r345838 |r342152 r345826 r345838 |r345839 |r345839 r348681 r348682 ||r348684 r348686 --- Comment #10 from Tom Stellard --- Merged: r348681 r348682 r348684 r348686 -- 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 39106] [meta] 7.0.1 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=39106 Bug 39106 depends on bug 39540, which changed state. Bug 39540 Summary: Cherry-pick 345826, 345839, and 345838 into 7.0.1 https://bugs.llvm.org/show_bug.cgi?id=39540 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
