[llvm-bugs] Issue 26651 in oss-fuzz: llvm:clang-objc-fuzzer: Stack-overflow in llvm::FoldingSetNodeID::operator==
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevl...@apple.com, igm...@gmail.com, d...@google.com, mit...@google.com, bigch...@gmail.com, eney...@google.com, llvm-...@lists.llvm.org, j...@chromium.org, v...@apple.com, mitch...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer OS-Linux Proj-llvm Reported-2020-10-26 Type: Bug New issue 26651 by ClusterFuzz-External: llvm:clang-objc-fuzzer: Stack-overflow in llvm::FoldingSetNodeID::operator== https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=26651 Detailed Report: https://oss-fuzz.com/testcase?key=6272612206116864 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: clang-objc-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Stack-overflow Crash Address: 0x7ffe22c20ff0 Crash State: llvm::FoldingSetNodeID::operator== llvm::FoldingSetBase::FindNodeOrInsertPos clang::ASTContext::getFunctionNoProtoType Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202010190618:202010200603 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=6272612206116864 Issue filed automatically. See https://google.github.io/oss-fuzz/advanced-topics/reproducing for instructions to reproduce this bug locally. 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. Comments on individual Monorail issues are not monitored. -- 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 47967] New: Template function gets selected also if a non-template function with appropriate signature exists
https://bugs.llvm.org/show_bug.cgi?id=47967 Bug ID: 47967 Summary: Template function gets selected also if a non-template function with appropriate signature exists Product: clang Version: 10.0 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: C++ Assignee: unassignedclangb...@nondot.org Reporter: andrea_...@hotmail.com CC: blitzrak...@gmail.com, dgre...@apple.com, erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk Created attachment 24099 --> https://bugs.llvm.org/attachment.cgi?id=24099&action=edit Example code that shows the problem. In the attached example I'm declaring a template stream (<<) operator, then I'm declaring a non-template operator. In my understanding the non-template operator should have priority over the template version. However, there is a case where the template operator is selected instead of the non-template one. When I run the attached example I see the following output: # clang++ -o test test.cpp # ./test Using stream operator directly: > NON-TEMPLATE STREAM OPERATOR FOR CLASS OutsideNamespaceData > NON-TEMPLATE STREAM OPERATOR FOR CLASS data::InsideNamespaceData Using stream through function 'writeAfter': > NON-TEMPLATE STREAM OPERATOR FOR CLASS OutsideNamespaceData > NON-TEMPLATE STREAM OPERATOR FOR CLASS data::InsideNamespaceData Using stream through function 'writeBefore': > NON-TEMPLATE STREAM OPERATOR FOR CLASS OutsideNamespaceData > TEMPLATE STREAM OPERATOR The last call of the function writeBefore is using the template stream operator instead of the non-template version. I've tested the example code with clang++ 7.0.1 and 10.0.1 and both give me the same results. The "data" and "streamer" namespaces seem to play some role in this behaviour: if a remove them I get the expected behaviour. If I compile the example with g++ I get the "correct" output: # g++ -o test test.cpp # ./test Using stream operator directly: > NON-TEMPLATE STREAM OPERATOR FOR CLASS OutsideNamespaceData > NON-TEMPLATE STREAM OPERATOR FOR CLASS data::InsideNamespaceData Using stream through function 'writeAfter': > NON-TEMPLATE STREAM OPERATOR FOR CLASS OutsideNamespaceData > NON-TEMPLATE STREAM OPERATOR FOR CLASS data::InsideNamespaceData Using stream through function 'writeBefore': > NON-TEMPLATE STREAM OPERATOR FOR CLASS OutsideNamespaceData > NON-TEMPLATE STREAM OPERATOR FOR CLASS data::InsideNamespaceData Let me know if further details are required. Thanks. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 47968] New: Possible missed AVX optimization opportunity
https://bugs.llvm.org/show_bug.cgi?id=47968
Bug ID: 47968
Summary: Possible missed AVX optimization opportunity
Product: new-bugs
Version: 11.0
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: jo...@lophus.org
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org
I *think* there is a missed optimization opportunity in the following code, but
I might be wrong because I've never used AVX before yesterday so know very
little about it. Also, the optimization is probably pretty crazy, so not sure
this is something compilers would optimize in the first place...
The code computes the squared error sum of a float array.
Notes:
- main.c is just there to trick se.c into not optimization everything away.
- N is a compile-time flag to control the array size, select it from [1,
1].
- SLOW is a compile-time flag to control if the AVX or naive version of se
shall be used.
- SUM_OUTER is a compile-time flag to choose between two variants of summation
if the fast version of se.
Compile with: cc ...flags... -O3 -mavx se.c -c -o se.o && cc se.o main.c
Benchmark results (flags | mean +- std):
-DSUM_OUTER=1 -DN=10|3.1 ms +- 4.0 ms
-DSUM_OUTER=1 -DN=100 | 690.5 ms +- 245.2 ms
-DSUM_OUTER=1 -DN=1000 |3.6 ms +- 4.9
-DSUM_OUTER=1 -DN=1 | 237.9 ms +- 5.8 ms
-DN=10|3.4 ms +- 4.5 ms
-DN=100 |3.8 ms +- 5.6 ms
-DN=1000 | 998.1 ms +- 25.7 ms
-DN=1 | 253.1 ms +- 37.0 ms
-DSLOW=1 -DN=10 |2.8 ms +- 4.3 ms
-DSLOW=1 -DN=20 | 138.9 ms +- 5.9 ms
-DSLOW=1 -DN=100| 834.2 ms +- 27.7 ms
-DSLOW=1 -DN=200| 1871.0 ms +- 45.0 ms
Note that there are funny outliers in the AVX version. Not sure where they're
coming from.
--- main.c ---
#include
void run (void *);
int main () {
run(NULL);
}
--- se.c ---
#include
#include
static float slowse(float *a, float *b, size_t n) {
float out = 0;
for (size_t i = 0; i < n; i += 1) {
out += (a[i] + b[i]) * (a[i] + b[i]);
}
return out;
}
static float fastse(float *a, float *b, size_t n) {
float a_aligned[8] __attribute__ ((aligned (32)));
float b_aligned[8] __attribute__ ((aligned (32)));
float out = 0;
__m256 out1 = _mm256_set1_ps(0);
size_t i = 0;
for (; i + 8 <= n; i += 8) {
memcpy(a_aligned, a, sizeof(float) * 8);
memcpy(b_aligned, b, sizeof(float) * 8);
__m256 res = _mm256_sub_ps(_mm256_load_ps(a_aligned),
_mm256_load_ps(b_aligned));
res = _mm256_mul_ps(res, res);
#ifdef SUM_OUTER
for (size_t i = 0; i < 8; ++i) {
out += res[i];
}
}
#else
out1 = _mm256_add_ps(out1, res);
}
for (size_t i = 0; i < 8; ++i) {
out += out1[i];
}
#endif
return out + slowse(&a[i], &b[i], n - i);
}
typedef void deoptimize(float *, float *, float);
static float a[8 * N];
static float b[8 * N];
void run (deoptimize f) {
float out;
for (size_t i = 0; i < 1000; ++i) {
#ifdef SLOW
out = slowse(a, b, N);
#else
out = fastse(a, b, N);
#endif
if (f != NULL) {
f(a, b, out);
}
}
if (f != NULL) {
f(a, b, out);
}
}
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 47743] LLDB displays wrong values for packed bitfields
https://bugs.llvm.org/show_bug.cgi?id=47743 lab...@google.com changed: What|Removed |Added Resolution|--- |FIXED Status|CONFIRMED |RESOLVED Fixed By Commit(s)||97ca9ca180f0810adcc1637d1a6 ||dd32a04f63cfe -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 47969] New: opt -inline causes 'Assertion `CastInst::castIsValid(opc, C, Ty) && "Invalid constantexpr cast!"' failed.'
https://bugs.llvm.org/show_bug.cgi?id=47969 Bug ID: 47969 Summary: opt -inline causes 'Assertion `CastInst::castIsValid(opc, C, Ty) && "Invalid constantexpr cast!"' failed.' Product: new-bugs Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: mikael.hol...@ericsson.com CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org Created attachment 24100 --> https://bugs.llvm.org/attachment.cgi?id=24100&action=edit bbi 48980.ll reproducer llvm commit: 7025687799 Reproduce with: opt -S -o - bbi-48980.ll -inline Result: opt: ../lib/IR/Constants.cpp:1794: static llvm::Constant *llvm::ConstantExpr::getCast(unsigned int, llvm::Constant *, llvm::Type *, bool): Assertion `CastInst::castIsValid(opc, C, Ty) && "Invalid constantexpr cast!"' failed. This seems to be old, I've reproduced it with old saved builds from November 2016. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 47970] New: Merge cc612c29084e907900ce63ad9031ab573a64e942 into 11.0.1
https://bugs.llvm.org/show_bug.cgi?id=47970 Bug ID: 47970 Summary: Merge cc612c29084e907900ce63ad9031ab573a64e942 into 11.0.1 Product: libraries Version: 11.0 Hardware: All OS: All Status: NEW Severity: release blocker Priority: P Component: Backend: WebAssembly Assignee: unassignedb...@nondot.org Reporter: ahee...@gmail.com CC: llvm-bugs@lists.llvm.org Blocks: 47800 Please merge cc612c29084e907900ce63ad9031ab573a64e942 (https://reviews.llvm.org/D85581) into 11.0.1 branch. Referenced Bugs: https://bugs.llvm.org/show_bug.cgi?id=47800 [Bug 47800] [meta] 11.0.1 Release Blockers -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 47933] Assertion failure in WebAssemblyFastISel
https://bugs.llvm.org/show_bug.cgi?id=47933 Heejin Ahn changed: What|Removed |Added Status|NEW |RESOLVED CC||ahee...@gmail.com Resolution|--- |FIXED --- Comment #2 from Heejin Ahn --- This bug was already fixed in https://github.com/llvm/llvm-project/commit/cc612c29084e907900ce63ad9031ab573a64e942, but has not been included in the latest 11.0 release. I requested this to be included in the 11.0.1 release: https://bugs.llvm.org/show_bug.cgi?id=47970 But 11.0.1 release will be available at least after several months. Meanwhile, you can use the tip of tree LLVM, or other WebAssembly supporting toolchains, such as Emsdk that provides latest releases for all necessary toolchains. Emsdk repo: https://github.com/emscripten-core/emsdk Manual: https://emscripten.org/docs/getting_started/downloads.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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 47968] Possible missed AVX optimization opportunity
https://bugs.llvm.org/show_bug.cgi?id=47968 Sanjay Patel changed: What|Removed |Added Resolution|--- |INVALID 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 47972] New: Trunk - Runtime kernel crash on simple code
https://bugs.llvm.org/show_bug.cgi?id=47972
Bug ID: 47972
Summary: Trunk - Runtime kernel crash on simple code
Product: OpenMP
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: release blocker
Priority: P
Component: Runtime Library
Assignee: unassignedb...@nondot.org
Reporter: jo...@udel.edu
CC: llvm-bugs@lists.llvm.org
Hi everyone,
When compiling the simplest code on OMP offloading on the latest trunk commit
cae4067, the kernel breaks:
int main() {
int x_spmd;
#pragma omp target map(x_spmd)
x_spmd++;
return 0;
}
clang -fopenmp -fopenmp-targets=nvptx64 simple.c -o simple
I have tried 2 machines already and I cannot seem to find the problem.
The LIBOMPTARGET_DEGUB=1 output
Libomptarget --> Init target library!
Libomptarget --> Loading RTLs...
Libomptarget --> Loading library 'libomptarget.rtl.ppc64.so'...
Libomptarget --> Unable to load library 'libomptarget.rtl.ppc64.so':
libomptarget.rtl.ppc64.so: cannot open shared object file: No such file or
directory!
Libomptarget --> Loading library 'libomptarget.rtl.x86_64.so'...
Libomptarget --> Successfully loaded library 'libomptarget.rtl.x86_64.so'!
Libomptarget --> Registering RTL libomptarget.rtl.x86_64.so supporting 4
devices!
Libomptarget --> Loading library 'libomptarget.rtl.cuda.so'...
Target CUDA RTL --> Start initializing CUDA
Libomptarget --> Successfully loaded library 'libomptarget.rtl.cuda.so'!
Libomptarget --> Registering RTL libomptarget.rtl.cuda.so supporting 4 devices!
Libomptarget --> Loading library 'libomptarget.rtl.aarch64.so'...
Libomptarget --> Unable to load library 'libomptarget.rtl.aarch64.so':
libomptarget.rtl.aarch64.so: cannot open shared object file: No such file or
directory!
Libomptarget --> Loading library 'libomptarget.rtl.ve.so'...
Libomptarget --> Unable to load library 'libomptarget.rtl.ve.so':
libomptarget.rtl.ve.so: cannot open shared object file: No such file or
directory!
Libomptarget --> Loading library 'libomptarget.rtl.amdgpu.so'...
Libomptarget --> Unable to load library 'libomptarget.rtl.amdgpu.so':
libomptarget.rtl.amdgpu.so: cannot open shared object file: No such file or
directory!
Libomptarget --> RTLs loaded!
Libomptarget --> Image 0x00400850 is NOT compatible with RTL
libomptarget.rtl.x86_64.so!
Libomptarget --> Image 0x00400850 is compatible with RTL
libomptarget.rtl.cuda.so!
Libomptarget --> RTL 0x01df80e0 has index 0!
Libomptarget --> Registering image 0x00400850 with RTL
libomptarget.rtl.cuda.so!
Libomptarget --> Done registering entries!
Libomptarget --> Call to omp_get_num_devices returning 4
Libomptarget --> Default TARGET OFFLOAD policy is now mandatory (devices were
found)
Libomptarget --> Entering target region with entry point 0x00400800 and
device Id -1
Libomptarget --> Checking whether device 0 is ready.
Libomptarget --> Is the device 0 (local ID 0) initialized? 0
Target CUDA RTL --> Init requires flags to 1
Target CUDA RTL --> Getting device 0
Target CUDA RTL --> The primary context is inactive, set its flags to
CU_CTX_SCHED_BLOCKING_SYNC
Target CUDA RTL --> Max CUDA blocks per grid 2147483647 exceeds the hard team
limit 65536, capping at the hard limit
Target CUDA RTL --> Using 1024 CUDA threads per block
Target CUDA RTL --> Using warp size 32
Target CUDA RTL --> Device supports up to 65536 CUDA blocks and 1024 threads
with a warp size of 32
Target CUDA RTL --> Default number of teams set according to library's default
128
Target CUDA RTL --> Default number of threads set according to library's
default 128
Libomptarget --> Device 0 is ready to use.
Target CUDA RTL --> Load data from image 0x00400850
Target CUDA RTL --> Error returned from cuModuleLoadDataEx
Target CUDA RTL --> CUDA error is: device kernel image is invalid
Libomptarget --> Unable to generate entries table for device id 0.
Libomptarget --> Failed to init globals on device 0
Libomptarget --> Failed to get device 0 ready
Libomptarget error: run with env LIBOMPTARGET_INFO>1 to dump host-targetpointer
maps
Libomptarget fatal error 1: failure of target construct while offloading is
mandatory
Thanks!
Jose
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 26580 in oss-fuzz: llvm:clang-fuzzer: Stack-overflow in clang::Lexer::Lex
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #1 on issue 26580 by ClusterFuzz-External: llvm:clang-fuzzer: Stack-overflow in clang::Lexer::Lex https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=26580#c1 ClusterFuzz testcase 4646925196066816 is verified as fixed in https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202010250629:202010260620 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 47973] New: Undefined behavior in int division with INT_MIN param
https://bugs.llvm.org/show_bug.cgi?id=47973 Bug ID: 47973 Summary: Undefined behavior in int division with INT_MIN param Product: compiler-rt Version: 11.0 Hardware: All OS: All Status: NEW Severity: normal Priority: P Component: builtins Assignee: unassignedb...@nondot.org Reporter: aysheku...@gmail.com CC: llvm-bugs@lists.llvm.org In the implementation for software integer division a/b (and mod a%b) in int_div_impl.inc, the absolute values of a and b are calculated like so: a = (a ^ s_a) - s_a; (The variable s_a is -1 or 0 depending on the signedness of a.) In the case where a (or b) is INT_MIN, this can mean that we calculate INT_MAX + 1 in signed integer operations. Calculating these as unsigned integers would avoid this undefined behaviour. In a similar fashion, the return statement can result in unsigned underflow because it substracts s_a which gets promoted to unsigned UINT_MAX due to the COMPUTE_UDIV being unsigned. Rewriting it as + (-s_a) would remove the undefined behaviour. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 47974] New: SIShrinkInstructions.cpp causes warning with Visual Studio 2019 on Windows 7
https://bugs.llvm.org/show_bug.cgi?id=47974 Bug ID: 47974 Summary: SIShrinkInstructions.cpp causes warning with Visual Studio 2019 on Windows 7 Product: libraries Version: trunk Hardware: PC OS: Windows XP Status: NEW Severity: normal Priority: P Component: Backend: AMDGPU Assignee: unassignedb...@nondot.org Reporter: p...@windfall.com CC: llvm-bugs@lists.llvm.org I am building LLVM with Microsoft Visual Studio 2019. The following line in SIShrinkInstructions.cpp produces a warning, which is treated as an error. if (Size > 1 && (I->getNumImplicitOperands() > (I->isCopy() ? 0 : 1))) produces ...SIShrinkInstructions.cpp(551): warning C4018: '>': signed/unsigned mismatch The problem is fixed by using 0U and 1U. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 47971] Clang-tidy fix for clang-diagnostic-logical-not-parentheses changes behavior
https://bugs.llvm.org/show_bug.cgi?id=47971 Eugene Zelenko changed: What|Removed |Added Component|clang-tidy |Frontend CC||eugene.zele...@gmail.com, ||llvm-bugs@lists.llvm.org, ||neeil...@live.com, ||richard-l...@metafoo.co.uk Product|clang-tools-extra |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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 47976] New: Crash in C++ for OpenCL when using vectors of half
https://bugs.llvm.org/show_bug.cgi?id=47976
Bug ID: 47976
Summary: Crash in C++ for OpenCL when using vectors of half
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: OpenCL
Assignee: unassignedclangb...@nondot.org
Reporter: marco.antogn...@arm.com
CC: anastasia.stul...@arm.com, llvm-bugs@lists.llvm.org
Clang crashes when using vectors of half in C++ for OpenCL when the extension
is disabled.
half foo(half2 x) {
return x.s0;
}
https://godbolt.org/z/Tcqnh9
Crash seems to happen in:
#5 0x562f40be7f0e clang::Sema::PerformImplicitConversion(clang::Expr*,
clang::QualType, clang::StandardConversionSequence const&,
clang::Sema::AssignmentAction, clang::Sema::CheckedConversionKind)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x4ef7f0e)
Clang doesn't crash when the extension is enabled using the expected pragma
directive.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 47977] New: reinterpret_cast doesn't work between vector and scalar
https://bugs.llvm.org/show_bug.cgi?id=47977
Bug ID: 47977
Summary: reinterpret_cast doesn't work between vector and
scalar
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: OpenCL
Assignee: unassignedclangb...@nondot.org
Reporter: marco.antogn...@arm.com
CC: anastasia.stul...@arm.com, llvm-bugs@lists.llvm.org
In C++ for OpenCL, the following program doesn't compile:
int2 foo(long x) {
return reinterpret_cast(x);
}
The error is: reinterpret_cast from scalar 'long' to vector 'int2' (vector of 2
'int' values) of different size
This is unexpected. The error message is also wrong: both long and int2 have
the same size.
Replacing the cast with a C-cast works.
https://godbolt.org/z/K7vcv4
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 47978] New: Please cherry-pick CUDA fixes for PR47332 into 11.0.1
https://bugs.llvm.org/show_bug.cgi?id=47978 Bug ID: 47978 Summary: Please cherry-pick CUDA fixes for PR47332 into 11.0.1 Product: clang Version: unspecified Hardware: PC OS: All Status: NEW Severity: release blocker Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: t...@google.com CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org, neeil...@live.com, richard-l...@metafoo.co.uk Depends on: 47332 Blocks: 47800 It would be great to pick up fixes for https://bugs.llvm.org/show_bug.cgi?id=47332 65d206484c54177641d4b11d42cab1f1acc8c0c7 https://reviews.llvm.org/D89752 https://reviews.llvm.org/rG65d206484c54177641d4b11d42cab1f1acc8c0c7 e7fe125b776bf08d95e60ff3354a5c836218a0e6 https://reviews.llvm.org/D89832 https://reviews.llvm.org/rGe7fe125b776bf08d95e60ff3354a5c836218a0e6 Referenced Bugs: https://bugs.llvm.org/show_bug.cgi?id=47332 [Bug 47332] Compilation error while compiling any kernel launch statement in CUDAKernelCallExpr syntax https://bugs.llvm.org/show_bug.cgi?id=47800 [Bug 47800] [meta] 11.0.1 Release Blockers -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 47979] New: __builtin_astype doesn't work with template parameters
https://bugs.llvm.org/show_bug.cgi?id=47979
Bug ID: 47979
Summary: __builtin_astype doesn't work with template parameters
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: OpenCL
Assignee: unassignedclangb...@nondot.org
Reporter: marco.antogn...@arm.com
CC: anastasia.stul...@arm.com, llvm-bugs@lists.llvm.org
In C++ for OpenCL, when using as_typen (e.g. as_int2) or __builtin_astype with
a template parameter, Clang crashes.
int2 foo(long x) { return as_int2(x); }
template
auto bar(T x) {
return as_int2(x); // CRASH
return __builtin_astype(x, int2); // CRASH
return foo(x); // works
}
auto foobar(long x) { return bar(x); }
https://godbolt.org/z/W6cfEK
The crash seems to happen in:
#5 0x556683bca77c clang::ASTContext::getTypeInfoImpl(clang::Type const*)
const (/opt/compiler-explorer/clang-trunk/bin/clang+++0x543d77c)
Note: as_typen is implemented in terms of __builtin_astype.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 47967] Template function gets selected also if a non-template function with appropriate signature exists
https://bugs.llvm.org/show_bug.cgi?id=47967 Richard Smith changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #1 from Richard Smith --- Looks like GCC has a bug here. Overloaded operators in a template are found by unqualified lookup at the point of definition (which finds only the template) plus ADL (which only looks in namespaces associated with the argument types, in this case only namespace 'data'), so the non-template operator is not considered in this example. See http://clang.llvm.org/compatibility.html#dep_lookup for more information. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 26661 in oss-fuzz: llvm:clang-fuzzer: Stack-overflow in clang::DeclContext::lookup
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevl...@apple.com, igm...@gmail.com, d...@google.com, mit...@google.com, bigch...@gmail.com, eney...@google.com, llvm-...@lists.llvm.org, j...@chromium.org, v...@apple.com, mitch...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer OS-Linux Proj-llvm Reported-2020-10-26 Type: Bug New issue 26661 by ClusterFuzz-External: llvm:clang-fuzzer: Stack-overflow in clang::DeclContext::lookup https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=26661 Detailed Report: https://oss-fuzz.com/testcase?key=5645227588845568 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: clang-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Stack-overflow Crash Address: 0x7ffded58cc88 Crash State: clang::DeclContext::lookup LookupDirect clang::Sema::LookupQualifiedName Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201902260412:201902270426 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5645227588845568 Issue filed automatically. See https://google.github.io/oss-fuzz/advanced-topics/reproducing for instructions to reproduce this bug locally. 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. Comments on individual Monorail issues are not monitored. -- 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 47980] New: Instcombine optimization f5df5cd55 causes miscompile in CFI code for Android
https://bugs.llvm.org/show_bug.cgi?id=47980
Bug ID: 47980
Summary: Instcombine optimization f5df5cd55 causes miscompile
in CFI code for Android
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: pir...@google.com
CC: eugeni.stepa...@gmail.com, lebedev...@gmail.com,
llvm-bugs@lists.llvm.org, srhi...@google.com
Created attachment 24101
--> https://bugs.llvm.org/attachment.cgi?id=24101&action=edit
repro
https://github.com/llvm/llvm-project/commit/f5df5cd5586ae9cfb2d9e53704dfc76f47aff149
causes a miscompile for __cfi_slowpath_diag in
https://android.googlesource.com/platform/bionic/+/refs/heads/master/libdl/libdl_cfi.cpp.
The optimization in f5df5cd5586 fires for the following lines:
uintptr_t p = aligned_addr - (static_cast(v -
CFIShadow::kRegularShadowMin)
<< CFIShadow::kCfiCheckGranularity);
The optimization seems valid but it somehow triggers a downstream miscompile.
With f5df5cd5586, the trailing end of cfi_slowpath_diag looks like this:
...
a8: b002add sp, #8
aa: bdd0pop {r4, r6, r7, pc}
ac: 2400movsr4, #0
ae: f6cf 74fc movtr4, #65532 ; 0xfffc
b2: f504 3e7c add.w lr, r4, #258048 ; 0x3f000
b6: 4614mov r4, r2
b8: f36f 0411 bfc r4, #0, #18
bc: fb0c 440e mla r4, ip, lr, r4
c0: f504 2484 add.w r4, r4, #270336 ; 0x42000
c4: 3401addsr4, #1
c6: b002add sp, #8
c8: e8bd 40d0 ldmia.w sp!, {r4, r6, r7, lr}
cc: 4720bx r4
ce: bf00nop
d0: 0044andeq r0, r0, r4, asr #32
Note that the value in $r4 from address 42 is clobbered by the ldmia in 46 but
is still used as the branch target in 4a.
With f5df5cd5586 reverted,
...
a0: b002add sp, #8
a2: bdd0pop {r4, r6, r7, pc}
a4: f502 2e80 add.w lr, r2, #262144 ; 0x4
a8: f44f 5400 mov.w r4, #8192 ; 0x2000
ac: f364 0e11 bfi lr, r4, #0, #18
b0: 2400movsr4, #0
b2: f6cf 74fc movtr4, #65532 ; 0xfffc
b6: f504 347c add.w r4, r4, #258048 ; 0x3f000
ba: fb0c e404 mla r4, ip, r4, lr
be: f044 0c01 orr.w ip, r4, #1
c2: b002add sp, #8
c4: e8bd 40d0 ldmia.w sp!, {r4, r6, r7, lr}
c8: 4760bx ip
ca: bf00nop
cc: 0048andeq r0, r0, r8, asr #32
cc: R_ARM_REL32 _ZL19shadow_base_storage
Note that the address is computed in $ip instead of $r4.
To reproduce, build the attached source with the following command:
$ clang++ -c -mthumb -O2 -target armv7a-linux-androideabi -o libdl_cfi.o
libdl_cfi.ii
Note that this doesn't reproduce without -mthumb.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 47981] New: -cl-std=1.0 is not supported
https://bugs.llvm.org/show_bug.cgi?id=47981 Bug ID: 47981 Summary: -cl-std=1.0 is not supported Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: OpenCL Assignee: unassignedclangb...@nondot.org Reporter: marco.antogn...@arm.com CC: anastasia.stul...@arm.com, llvm-bugs@lists.llvm.org Clang doesn't recognise -cl-std=1.0 as a value argument, currently -std=cl1.0 has to be used instead. https://godbolt.org/z/azGzv8 error: invalid value 'cl1.0' in '-cl-std=cl1.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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 47982] New: [asan] Shadowed stack variables' name are not the exact source name.
https://bugs.llvm.org/show_bug.cgi?id=47982
Bug ID: 47982
Summary: [asan] Shadowed stack variables' name are not the
exact source name.
Product: clang
Version: unspecified
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: LLVM Codegen
Assignee: unassignedclangb...@nondot.org
Reporter: pierregoussea...@gmail.com
CC: llvm-bugs@lists.llvm.org, neeil...@live.com,
richard-l...@metafoo.co.uk
In the sample below the reported variable's name is the LLVM ir's name 'x1'
instead of 'x'.
Any ideas how to use the source's variable name instead?
Many thanks,
Pierre
///
int main()
{
int x;
{
int x;
delete &x;
}
delete &x;
return 0;
}
$ clang++ -fsanitize=address test.cpp && ./a.out
==191==ERROR: AddressSanitizer: attempting free on address which was not
malloc()-ed:
...
This frame has 2 object(s):
[32, 36) 'x' (line 3842)
[48, 52) 'x1' (line 3844) <== Memory access at offset 48 is inside this
variable
///
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 47983] New: Windows newlines cause error in parsing llvm-mca regions
https://bugs.llvm.org/show_bug.cgi?id=47983
Bug ID: 47983
Summary: Windows newlines cause error in parsing llvm-mca
regions
Product: tools
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: llvm-mca
Assignee: unassignedb...@nondot.org
Reporter: stephen.to...@sony.com
CC: andrea.dibia...@gmail.com, llvm-bugs@lists.llvm.org,
matthew.da...@sony.com
Created attachment 24102
--> https://bugs.llvm.org/attachment.cgi?id=24102&action=edit
C++ source code that reproduces issue (taken from llvm-mca docs)
llvm-mca has an error that occurs when using windows line endings, in which
LLVM-MCA-END directives with no label cannot be used with LLVM-MCA-BEGIN
directives that do have a label, such as in the following example from the
llvm-mca docs:
# LLVM-MCA-BEGIN A simple example
add %eax, %eax
# LLVM-MCA-END
A brief investigation reveals that the issue appears to exist in
AsmLexer::LexLineComment, where we have the following code:
while (CurChar != '\n' && CurChar != '\r' && CurChar != EOF)
CurChar = getNextChar();
if (CurChar == '\r' && CurPtr != CurBuf.end() && *CurPtr == '\n')
++CurPtr;
// If we have a CommentConsumer, notify it about the comment.
if (CommentConsumer) {
CommentConsumer->HandleComment(
SMLoc::getFromPointer(CommentTextStart),
StringRef(CommentTextStart, CurPtr - 1 - CommentTextStart));
}
This code shows some awareness of windows line endings, but does not handle
them correctly when calling CommentConsumer->HandleComment(); the comment
string passed in contains every character of the line but the last. This is
correct when using Unix-style line endings (\n), but not Windows-style line
endings (\r\n) for which the carriage return will be included as part of the
comment. This causes llvm-mca to see non-label directives as having the label
"\r", resulting in the following error:
$ cat reproducer.cpp
int foo(int a, int b) {
__asm volatile("# LLVM-MCA-BEGIN foo");
a += 42;
__asm volatile("# LLVM-MCA-END");
a *= b;
return a;
}
$ clang reproducer.cpp -S -o - | llvm-mca
:30:3: error: found an invalid region end directive
# LLVM-MCA-END
^
:30:3: note: unable to find an
active region named
# LLVM-MCA-END
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 24619 in oss-fuzz: llvm:llvm-isel-fuzzer--aarch64-O2: Null-dereference WRITE in llvm::AArch64FrameLowering::processFunctionBeforeFrameFinalized
Updates: Labels: Deadline-Approaching Comment #1 on issue 24619 by sheriffbot: llvm:llvm-isel-fuzzer--aarch64-O2: Null-dereference WRITE in llvm::AArch64FrameLowering::processFunctionBeforeFrameFinalized https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=24619#c1 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 24634 in oss-fuzz: llvm:clang-objc-fuzzer: ASSERT: RefExpr->isImplicitProperty()
Updates: Labels: Deadline-Approaching Comment #1 on issue 24634 by sheriffbot: llvm:clang-objc-fuzzer: ASSERT: RefExpr->isImplicitProperty() https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=24634#c1 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 26651 in oss-fuzz: llvm:clang-objc-fuzzer: Stack-overflow in llvm::FoldingSetNodeID::operator==
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #1 on issue 26651 by ClusterFuzz-External: llvm:clang-objc-fuzzer: Stack-overflow in llvm::FoldingSetNodeID::operator== https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=26651#c1 ClusterFuzz testcase 6272612206116864 is verified as fixed in https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202010250629:202010260620 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 47984] New: Optimizer generating wrong code
https://bugs.llvm.org/show_bug.cgi?id=47984 Bug ID: 47984 Summary: Optimizer generating wrong code Product: clang Version: trunk Hardware: Macintosh OS: MacOS X Status: NEW Severity: normal Priority: P Component: LLVM Codegen Assignee: unassignedclangb...@nondot.org Reporter: tbr...@outlook.com CC: llvm-bugs@lists.llvm.org, neeil...@live.com, richard-l...@metafoo.co.uk Version == Tested Clang 10 through 12. Issue == While running tests for Blender, we encountered an intermittent bug on binaries compiled with clang. It shows up in -O2 builds, not -O1, or -O0. The code inside the for-loop at [1] is not executed with -O2. That causes more problems down the line. We fixed it by marking `last_remapped_id` volatile. Another way was to access other fields of `last_remapped_id`. Steps to redo: == - git clone https://git.blender.org/blender.git - cd blender - make update - git revert 2ddecfffc3d3 --no-commit - cmake -B ../blender_build -C build_files/cmake/config/blender_lite.cmake -G Ninja -DCMAKE_BUILD_TYPE=RelWithDebInfo - cd ../blender_build && make install - ctest -R id_man -C relwithdebinfo -VV The test will fail. Diagnostics == It has been been very difficult to isolate the bug to a simple code. Even moving out the function `id_delete` to another file fixes the bug. There is a possibility that the following might be the reason of the bug (quoting from https://developer.blender.org/D9315#230626) """ Just for context, repeating what I said earlier in the chat - this is what **I think** goes on: * The crash makes sense to me now, the "MECube" (which is the default cube from the factory-startup I think) is tagged properly for deletion, but not the "OBCube" - because the loop isn't executed correctly. * The optimizer realizes that `tagged_deleted_ids` is collected the same way on each iteration (which is based on `ID.tag`) and it operates on the same data, so it assumes it will always yield the same result. * It does not realise however that `ID.tag` is changed within the loop, somewhere deeper down the call-stack (here in fact https://developer.blender.org/diffusion/B/browse/master/source/blender/blenkernel/intern/lib_remap.c$158). Note that this should be reported to the Clang team. The Godbolt links we used in the chat will hopefully be enough, although if my analysis above is correct, the code on Godbolt won't show the error, as the part of `ID.tag` being changed indirectly in the loop is missing. Maybe a simple (non-inline!) function that just modifies `ID.tag` will be enough. """ Attachments === Four files are attached: With volatile assembly With volatile optimization record Without volatile assembly Without volatile optimization record I can run more tests if needed. [1] https://developer.blender.org/diffusion/B/browse/master/source/blender/blenkernel/intern/lib_id_delete.c;2ddecfffc3d3a3a1db4ae45e8665caa2a85ab43a$293-310 if you prefer github: https://github.com/blender/blender -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 47985] New: MPI-Checker wrongly reports missing wait
https://bugs.llvm.org/show_bug.cgi?id=47985 Bug ID: 47985 Summary: MPI-Checker wrongly reports missing wait Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Static Analyzer Assignee: dcough...@apple.com Reporter: rr.underwoo...@gmail.com CC: dcough...@apple.com, llvm-bugs@lists.llvm.org Created attachment 24104 --> https://bugs.llvm.org/attachment.cgi?id=24104&action=edit reproducer MPI-Checker incorrectly warns for "no matching wait" when a non-blocking collective request is completed using MPI_Test rather than MPI_Wait. Attaching a minimal reproducer. The relevant section of the MPI Standard is as follows: (3.7.3) "The functions MPI_WAIT and MPI_TEST are used to complete a nonblocking communication...A call to MPI_TEST returns flag = true if the operation identified by request is complete. In such a case, the status object is set to contain information on the completed operation... [if the request is not an active persistant request, it] ... is deallocated and the request handle is set to MPI_REQUEST_NULL" -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 26544 in oss-fuzz: llvm:clang-fuzzer: Stack-overflow in clang::FunctionProtoType::getExceptionSpecInfo
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #1 on issue 26544 by ClusterFuzz-External: llvm:clang-fuzzer: Stack-overflow in clang::FunctionProtoType::getExceptionSpecInfo https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=26544#c1 ClusterFuzz testcase 5086308986519552 is verified as fixed in https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202010250629:202010260620 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 26569 in oss-fuzz: llvm:clang-fuzzer: Stack-overflow in clang::sema::CapturingScopeInfo::addCapture
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #1 on issue 26569 by ClusterFuzz-External: llvm:clang-fuzzer: Stack-overflow in clang::sema::CapturingScopeInfo::addCapture https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=26569#c1 ClusterFuzz testcase 5176092044034048 is verified as fixed in https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202010250629:202010260620 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 21437 in oss-fuzz: llvm:llvm-opt-fuzzer--x86_64-strength_reduce: ASSERT: (!F.ScaledReg || !F.ScaledReg->isZero()) && "Zero allocated in a scaled register
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #2 on issue 21437 by ClusterFuzz-External: llvm:llvm-opt-fuzzer--x86_64-strength_reduce: ASSERT: (!F.ScaledReg || !F.ScaledReg->isZero()) && "Zero allocated in a scaled register https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=21437#c2 ClusterFuzz testcase 5201610423926784 is verified as fixed in https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202010250629:202010260620 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 26539 in oss-fuzz: llvm:clang-fuzzer: Stack-overflow in clang::DiagnosticIDs::isUnrecoverable
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #1 on issue 26539 by ClusterFuzz-External: llvm:clang-fuzzer: Stack-overflow in clang::DiagnosticIDs::isUnrecoverable https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=26539#c1 ClusterFuzz testcase 5637772372869120 is verified as fixed in https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202010250629:202010260620 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 26661 in oss-fuzz: llvm:clang-fuzzer: Stack-overflow in clang::DeclContext::lookup
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #1 on issue 26661 by ClusterFuzz-External: llvm:clang-fuzzer: Stack-overflow in clang::DeclContext::lookup https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=26661#c1 ClusterFuzz testcase 5645227588845568 is verified as fixed in https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202010250629:202010260620 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 13195 in oss-fuzz: llvm/llvm-opt-fuzzer--x86_64-strength_reduce: Floating-point-exception in LSRInstance::GenerateAllReuseFormulae
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #4 on issue 13195 by ClusterFuzz-External: llvm/llvm-opt-fuzzer--x86_64-strength_reduce: Floating-point-exception in LSRInstance::GenerateAllReuseFormulae https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=13195#c4 ClusterFuzz testcase 5675778002386944 is verified as fixed in https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202010250629:202010260620 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 26553 in oss-fuzz: llvm:clang-fuzzer: Stack-overflow in clang::Sema::DiagnoseEmptyLookup
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #1 on issue 26553 by ClusterFuzz-External: llvm:clang-fuzzer: Stack-overflow in clang::Sema::DiagnoseEmptyLookup https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=26553#c1 ClusterFuzz testcase 6034678957735936 is verified as fixed in https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202010250629:202010260620 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 47963] Miscompilation Removes Necessary Function Call in Clang 10.0.1
https://bugs.llvm.org/show_bug.cgi?id=47963 Gavin Howard changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #6 from Gavin Howard --- Sigh...details matter. When changing `ymap_index()` recently, I added two pointer args to insert return values in. This made it bad to use the __attribute__((pure)) attribute, which I still had. My bad. Closing as INVALID. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 47945] opt -sroa causes "PHI node has multiple entries for the same basic block with different incoming values!"
https://bugs.llvm.org/show_bug.cgi?id=47945 Stanislav Mekhanoshin changed: What|Removed |Added Status|CONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Stanislav Mekhanoshin --- Fixed in https://reviews.llvm.org/rG00928a1956a1618f394ffe99fc63b0d81e1f88c7 -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 47986] New: Test bug about debug info
https://bugs.llvm.org/show_bug.cgi?id=47986 Bug ID: 47986 Summary: Test bug about debug info Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: Backend: WebAssembly Assignee: unassignedb...@nondot.org Reporter: dsch...@google.com CC: llvm-bugs@lists.llvm.org It should match -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 47986] Test bug about debug info
https://bugs.llvm.org/show_bug.cgi?id=47986 Derek Schuff changed: What|Removed |Added CC|dblai...@gmail.com, | |llvm-bugs@lists.llvm.org| -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 47987] New: Many scripts use /usr/bin/env python but python3 might not have that symlink.
https://bugs.llvm.org/show_bug.cgi?id=47987 Bug ID: 47987 Summary: Many scripts use /usr/bin/env python but python3 might not have that symlink. Product: new-bugs Version: 11.0 Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: zarniwh...@ntlworld.com CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org I initially thought that only one of the compiler-rt tests was involved, because I had been running builds and tests while the python symlink was in place, then removed it for other reasons and got an extra test failure. But grepping through llvm with clang and compiler-rt found more than 130 such files, mostly utilities and examples. With the demise of python2, not every system will install a python symlink. Certainly the compiler-rt test ran fine when converted to python3, and I see from fedora's specfile that they appear to be doing something similar for some of the others. OTOH, if you want to continue to support python2 then this sort of change will be painful. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 47798] invalid reassignment of non-absolute variable 'var_ddq_add'
https://bugs.llvm.org/show_bug.cgi?id=47798 Fangrui Song changed: What|Removed |Added CC||i...@maskray.me Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #1 from Fangrui Song --- Fixed https://github.com/ClangBuiltLinux/linux/issues/1008 We have investigated the semantics in MC - it is difficult/undesired to match GNU as in this regard. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 47707] [PPC] wrong code generated for cr operations and conditional branch
https://bugs.llvm.org/show_bug.cgi?id=47707 qsh...@cn.ibm.com changed: What|Removed |Added CC||qsh...@cn.ibm.com 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
