[llvm-bugs] [Bug 50680] [clang-format] strange behavior for #define macro with braces
https://bugs.llvm.org/show_bug.cgi?id=50680 Owen Pan changed: What|Removed |Added Status|NEW |RESOLVED CC||owenpi...@gmail.com Resolution|--- |DUPLICATE --- Comment #1 from Owen Pan --- *** This bug has been marked as a duplicate of bug 50679 *** -- 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 41152] [DebugInfo] Better dumping of empty location expression
https://bugs.llvm.org/show_bug.cgi?id=41152 Soham Sanjay Dixit changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Soham Sanjay Dixit --- The bug has been resolved [DebugInfo] Bug 41152 - Improve dumping of empty location expressions is Solved. Link for the same. https://reviews.llvm.org/D103502 link to the github commit https://github.com/llvm/llvm-project/commit/51d969dc27a80704038b653537fc12a31f4c31f0 -- 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 50939] New: [VectorCombine] Combining permute+blend with zero into a two-source permute
https://bugs.llvm.org/show_bug.cgi?id=50939
Bug ID: 50939
Summary: [VectorCombine] Combining permute+blend with zero into
a two-source permute
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Transformation Utilities
Assignee: unassignedb...@nondot.org
Reporter: lebedev...@gmail.com
CC: llvm-bugs@lists.llvm.org
Not sure how useful this would be, but we could do the following:
https://godbolt.org/z/qnc87j9dd
define <4 x i32> @src(<4 x i32> %x) local_unnamed_addr #0 {
%permil = shufflevector <4 x i32> %x, <4 x i32> poison, <4 x i32>
%blend = shufflevector <4 x i32> , <4 x
i32> %permil, <4 x i32>
ret <4 x i32> %blend
}
define <4 x i32> @tgt(<4 x i32> %x) local_unnamed_addr #0 {
%shuf = shufflevector <4 x i32> %x, <4 x i32> zeroinitializer, <4 x i32>
ret <4 x i32> %shuf
}
Iff SK_PermuteTwoSrc is not costlier than SK_PermuteSingleSrc+SK_Select.
Though, for non-zero second source, looks like we fail to drop unneeded
vpermilps:
https://godbolt.org/z/3qhzEM933
--
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 50929] Ignored initializer clause in user-defined reduction
https://bugs.llvm.org/show_bug.cgi?id=50929 Alexey Bataev changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED Fixed By Commit(s)||7fab1146e42ca76a78cccd0aa27 ||4168c628d01de CC||a.bat...@hotmail.com --- Comment #2 from Alexey Bataev --- Fixed in 7fab1146e42ca76a78cccd0aa274168c628d01de -- 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 50914] telegram-desktop 2.8.1 crashes on startup with an Illegal Instruction if built with clang
https://bugs.llvm.org/show_bug.cgi?id=50914 Tee KOBAYASHI changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #3 from Tee KOBAYASHI --- In fact the cause seems the lack of -ffreestanding flag. UB is not relevant here. -- 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 49731] missed optimization for dead code elimination at -O3 (vs. -O1)
https://bugs.llvm.org/show_bug.cgi?id=49731 Zhendong Su changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #4 from Zhendong Su --- Thanks for the fix, Florian! -- 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 35685 in oss-fuzz: llvm:llvm-isel-fuzzer--aarch64-gisel: ASSERT: SizeInBits > 0 && "invalid scalar size"
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-2021-06-30 Type: Bug New issue 35685 by ClusterFuzz-External: llvm:llvm-isel-fuzzer--aarch64-gisel: ASSERT: SizeInBits > 0 && "invalid scalar size" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=35685 Detailed Report: https://oss-fuzz.com/testcase?key=5574809328156672 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: llvm-isel-fuzzer--aarch64-gisel Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: ASSERT Crash Address: Crash State: SizeInBits > 0 && "invalid scalar size" llvm::LegalizerHelper::lowerStore llvm::LegalizerHelper::lower Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202106290600:202106300601 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5574809328156672 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 50619] Assert in OpenMP program when parsing use_allocator clause on target directive
https://bugs.llvm.org/show_bug.cgi?id=50619 Alexey Bataev changed: What|Removed |Added Fixed By Commit(s)||44f197e94b83d389b59ce6a2a19 ||77f972e6d34e3 Status|NEW |RESOLVED CC||a.bat...@hotmail.com Resolution|--- |FIXED --- Comment #1 from Alexey Bataev --- Fixed in 44f197e94b83d389b59ce6a2a1977f972e6d34e3 -- 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 50940] New: Consider warning on redundant attributes
https://bugs.llvm.org/show_bug.cgi?id=50940
Bug ID: 50940
Summary: Consider warning on redundant attributes
Product: clang
Version: unspecified
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: Frontend
Assignee: unassignedclangb...@nondot.org
Reporter: nicolaswe...@gmx.de
CC: llvm-bugs@lists.llvm.org, neeil...@live.com,
richard-l...@metafoo.co.uk
clang currently allows this without complaint:
[[nodiscard]] [[nodiscard]] int f() { return 4; }
The duplicate `[[nodiscard]]` is harmless, but also pointless and a copy-paste
artifact. We should maybe warn on it.
We very likely shouldn't warn if one `[[nodiscard]]` is on the decl and another
on the definition.
We possibly shouldn't warn on it if one of the copies comes from a macro.
--
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 50941] New: TargetLoweringBase::getRegClassFor Assertion "This value type is not natively supported!"
https://bugs.llvm.org/show_bug.cgi?id=50941 Bug ID: 50941 Summary: TargetLoweringBase::getRegClassFor Assertion "This value type is not natively supported!" Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Common Code Generator Code Assignee: unassignedb...@nondot.org Reporter: gcc.j.kell...@hzdr.de CC: llvm-bugs@lists.llvm.org Created attachment 24989 --> https://bugs.llvm.org/attachment.cgi?id=24989&action=edit object file triggering linker error When linking a code (single unit) compiled OpenMP target=amdgcn-amd-amdhsa with trunk got the following ICE: ``` llc: /home/kelling/checkout/llvm/trunk/llvm-project/llvm/include/llvm/CodeGen/TargetLowering.h:855: virtual const llvm::TargetRegisterClass* llvm::TargetLoweringBase::getRegClassFor(llvm::MVT, bool) const: Assertion `RC && "This value type is not natively supported!"' failed. PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace. Stack dump: 0. Program arguments: /home/kelling/checkout/llvm/trunk/llvm-project/install/bin/llc monteCarloIntegration.cpp-openmp-amdgcn-amd-amdhsa-gfx906-linked.bc -mtriple=amdgcn-amd-amdhsa -mcpu=gfx906 -filetype=asm -o monteCarloIntegration.cpp-openmp-amdgcn-amd-amdhsa-gfx906.s 1. Running pass 'CallGraph Pass Manager' on module 'monteCarloIntegration.cpp-openmp-amdgcn-amd-amdhsa-gfx906-linked.bc'. 2. Running pass 'AMDGPU DAG->DAG Pattern Instruction Selection' on function '@_ZSt3loge' #0 0x560e8af24e3f PrintStackTraceSignalHandler(void*) Signals.cpp:0:0 #1 0x560e8af2268d SignalHandler(int) Signals.cpp:0:0 #2 0x7f06fc586980 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x12980) #3 0x7f06fb22afb7 raise /build/glibc-S9d2JN/glibc-2.27/signal/../sysdeps/unix/sysv/linux/raise.c:51:0 #4 0x7f06fb22c921 abort /build/glibc-S9d2JN/glibc-2.27/stdlib/abort.c:81:0 #5 0x7f06fb21c48a __assert_fail_base /build/glibc-S9d2JN/glibc-2.27/assert/assert.c:89:0 #6 0x7f06fb21c502 (/lib/x86_64-linux-gnu/libc.so.6+0x30502) #7 0x560e89c2a3db (/home/kelling/checkout/llvm/trunk/llvm-project/install/bin/llc+0xac43db) #8 0x560e8ac52b4e llvm::FunctionLoweringInfo::CreateRegs(llvm::Type*, bool) (/home/kelling/checkout/llvm/trunk/llvm-project/install/bin/llc+0x1aecb4e) #9 0x560e8ac47cf6 llvm::FunctionLoweringInfo::InitializeRegForValue(llvm::Value const*) (/home/kelling/checkout/llvm/trunk/llvm-project/install/bin/llc+0x1ae1cf6) #10 0x560e8acce849 llvm::SelectionDAGISel::LowerArguments(llvm::Function const&) (/home/kelling/checkout/llvm/trunk/llvm-project/install/bin/llc+0x1b68849) #11 0x560e8ad5553a llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) (/home/kelling/checkout/llvm/trunk/llvm-project/install/bin/llc+0x1bef53a) #12 0x560e8ad564eb llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) (.part.958) SelectionDAGISel.cpp:0:0 #13 0x560e89d3f76a (anonymous namespace)::AMDGPUDAGToDAGISel::runOnMachineFunction(llvm::MachineFunction&) AMDGPUISelDAGToDAG.cpp:0:0 #14 0x560e8a307f26 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) (/home/kelling/checkout/llvm/trunk/llvm-project/install/bin/llc+0x11a1f26) #15 0x560e8a785bf6 llvm::FPPassManager::runOnFunction(llvm::Function&) (/home/kelling/checkout/llvm/trunk/llvm-project/install/bin/llc+0x161fbf6) #16 0x560e89ec6ae4 (anonymous namespace)::CGPassManager::runOnModule(llvm::Module&) CallGraphSCCPass.cpp:0:0 #17 0x560e8a786d60 llvm::legacy::PassManagerImpl::run(llvm::Module&) (/home/kelling/checkout/llvm/trunk/llvm-project/install/bin/llc+0x1620d60) #18 0x560e897ff104 compileModule(char**, llvm::LLVMContext&) llc.cpp:0:0 #19 0x560e8977dc26 main (/home/kelling/checkout/llvm/trunk/llvm-project/install/bin/llc+0x617c26) #20 0x7f06fb20dbf7 __libc_start_main /build/glibc-S9d2JN/glibc-2.27/csu/../csu/libc-start.c:344:0 #21 0x560e897f661a _start (/home/kelling/checkout/llvm/trunk/llvm-project/install/bin/llc+0x69061a) clang-13: error: unable to execute command: Aborted (core dumped) clang-13: error: amdgcn-link command failed due to signal (use -v to see invocation) clang version 13.0.0 (https://github.com/llvm/llvm-project.git b062fff87adcfa2e252cbce43d92b61b76614bd5) Target: x86_64-unknown-linux-gnu Thread model: posix InstalledDir: /home/kelling/checkout/llvm/trunk/llvm-project/install/bin clang-13: note: diagnostic msg: Error generating preprocessed source(s). ``` This can be reproduced using the attached object file with the command: ``` clang++ -fopenmp -fopenmp=libomp -fopenmp-targets=amdgcn-amd-amdhsa -Xopenmp-target=amdgcn-amd-amdhsa -march=gfx906 --save-temps -fopenmp -fopenmp-version=40 monteCarloIntegration.cpp.o -o monteCarloIntegration /usr/lib/x86_64-linux-gnu/librt.so ``` -- You
[llvm-bugs] [Bug 50942] New: [LoopVectorizer] Vectorization of running reduction/predication
https://bugs.llvm.org/show_bug.cgi?id=50942
Bug ID: 50942
Summary: [LoopVectorizer] Vectorization of running
reduction/predication
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Loop Optimizer
Assignee: unassignedb...@nondot.org
Reporter: lebedev...@gmail.com
CC: llvm-bugs@lists.llvm.org
Consider https://godbolt.org/z/Wo86sfav1
void test(int pred, int* data, int width) {
for(int i = 0; i != width; ++i) {
int& out = data[i];
pred += out;
out = pred;
}
}
So the first element was incremented by `pred`,
and each next element is incremented by the value of all preceding elements.
This is a common pattern in image processing.
Currently we don't recognize the PHI, and don't vectorize,
even though it's somewhat simple:
https://godbolt.org/z/sEob7fE6h
That snippet as-is doesn't seem better vectorized:
https://godbolt.org/z/aMaqYz7f1
(better RThroughput, same cycle count, but more uOps/IPC)
However if we unroll x8 https://godbolt.org/z/Mb7vcGrzs
(and i do believe both loops unrolled still compute the same elt count)
i think we see a win: https://godbolt.org/z/EW77Max86
A ~third less cycles.
This makes sense because most of the computations there don't touch `pred`,
so they can be executed out-of-order, even though we won't be able to
finish and store until the previous group has finished processing.
The story will be somewhat different with two-element predictor,
different data types, etc.
Is this recipe something that could fit into LV?
--
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 35320 in oss-fuzz: llvm:llvm-opt-fuzzer--x86_64-loop_vectorize: ASSERT: Ingredient2Recipe[I] != nullptr && "Ingredient doesn't have a recipe"
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #1 on issue 35320 by ClusterFuzz-External: llvm:llvm-opt-fuzzer--x86_64-loop_vectorize: ASSERT: Ingredient2Recipe[I] != nullptr && "Ingredient doesn't have a recipe" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=35320#c1 ClusterFuzz testcase 5647893213085696 is verified as fixed in https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202106290600:202106300601 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 50943] New: Inline asm miscompile (test segfaults)
https://bugs.llvm.org/show_bug.cgi?id=50943
Bug ID: 50943
Summary: Inline asm miscompile (test segfaults)
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Backend: X86
Assignee: unassignedb...@nondot.org
Reporter: paul_robin...@playstation.sony.com
CC: craig.top...@gmail.com, llvm-bugs@lists.llvm.org,
llvm-...@redking.me.uk, pengfei.w...@intel.com,
spatel+l...@rotateright.com
Reduced from gdb test case gdb.arch/i386-avx.c
$ cat t1.c
typedef struct {
float f[8];
} v8sf_t;
v8sf_t data[] =
{
{ { 0.0, 0.125, 0.25, 0.375, 0.50, 0.625, 0.75, 0.875 } },
};
int main (int argc, char **argv) {
asm ("vmovaps 0(%0), %%ymm0\n\t"
: /* no output operands */
: "r" (data)
: "xmm0");
return 0;
}
$ gcc t1.c -o t1-gcc
$ ./t1-gcc
$ clang t1.c -o t1-clang
$ ./t1-clang
Segementation fault
$
using gcc 7.5.0 and clang 13 1f169a77
--
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 50944] New: wrong code at -Os and above on x86_64-linux-gnu
https://bugs.llvm.org/show_bug.cgi?id=50944
Bug ID: 50944
Summary: wrong code at -Os and above on x86_64-linux-gnu
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: Transformation Utilities
Assignee: unassignedb...@nondot.org
Reporter: zhendong...@inf.ethz.ch
CC: llvm-bugs@lists.llvm.org
This seems to be a recent regression.
[512] % clangtk -v
clang version 13.0.0 (https://github.com/llvm/llvm-project.git
0c96a92d8666b8eb69eb1275aed572f857182d9a)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /local/suz-local/opfuzz/bin
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/8
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6.5.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7.5.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/8
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7.5.0
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Candidate multilib: x32;@mx32
Selected multilib: .;@m64
[513] %
[513] % clangtk -O1 small.c; ./a.out
[514] %
[514] % clangtk -Os small.c
[515] % ./a.out
Aborted
[516] %
[516] % cat small.c
static int a, b, *c = &b, d;
int main() {
int e;
for (; a < 1; a++)
if (b)
d++;
b = 0;
if (!a)
b = 0 >> e;
c = 0;
if (d != 0)
__builtin_abort ();
return 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 50759] LLD handling of relocations to unresolved weak references with -pie not consistent
https://bugs.llvm.org/show_bug.cgi?id=50759 Fangrui Song changed: What|Removed |Added Assignee|unassignedb...@nondot.org |i...@maskray.me Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #3 from Fangrui Song --- Fixed by https://reviews.llvm.org/D105164 -- 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 50946] New: format-pedantic warns about passing nullptr to %p
https://bugs.llvm.org/show_bug.cgi?id=50946
Bug ID: 50946
Summary: format-pedantic warns about passing nullptr to %p
Product: clang
Version: 12.0
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: eyalr...@gmx.com
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
Godbolt: https://godbolt.org/z/1dMKE1W81
If we compile:
#include
int main()
{
printf("%p\n", nullptr);
}
with clang++ -Wformat -pedantic, we get:
:5:20: warning: format specifies type 'void *' but the argument has
type 'nullptr_t' [-Wformat-pedantic]
printf("%p\n", nullptr);
~~ ^~~
I believe that's _too_ pedantic. It is well and proper to pass nullptr to a %p
without casting 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
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 50947] New: wrong code at -Os and above on x86_64-linux-gnu
https://bugs.llvm.org/show_bug.cgi?id=50947
Bug ID: 50947
Summary: wrong code at -Os and above on x86_64-linux-gnu
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: Transformation Utilities
Assignee: unassignedb...@nondot.org
Reporter: zhendong...@inf.ethz.ch
CC: llvm-bugs@lists.llvm.org
Here is another recent regression which appears unrelated to
https://bugs.llvm.org/show_bug.cgi?id=50944.
[564] % clangtk -v
clang version 13.0.0 (https://github.com/llvm/llvm-project.git
0c96a92d8666b8eb69eb1275aed572f857182d9a)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /local/suz-local/opfuzz/bin
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/8
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6.5.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7.5.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/8
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7.5.0
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Candidate multilib: x32;@mx32
Selected multilib: .;@m64
[565] %
[565] % clangtk -O1 small.c; ./a.out
[566] %
[566] % clangtk -Os small.c
[567] % ./a.out
Aborted
[568] %
[568] % cat small.c
int a[36], b, c, d, e, f;
int main() {
for (c = 0; c < 6; c++)
for (d = 0; d < 6; d++)
for (b = 0; b < 6; b++)
a[6 + c] = a[c * 6 + c] ^ 1;
if (a[7] != 0)
__builtin_abort ();
return 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 50948] New: LLDB not clearing EXC_BAD_ACCESS exception after `thread return` (on MacOS)?
https://bugs.llvm.org/show_bug.cgi?id=50948
Bug ID: 50948
Summary: LLDB not clearing EXC_BAD_ACCESS exception after
`thread return` (on MacOS)?
Product: lldb
Version: unspecified
Hardware: PC
OS: MacOS X
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: lldb-...@lists.llvm.org
Reporter: v...@google.com
CC: jdevliegh...@apple.com, llvm-bugs@lists.llvm.org
Repro:
Using the following test code:
// bad_access.cc
1 // bad_access.cc
2 #include
3 #include
4
5 int bad_acc(void){
6printf("in bad_acc()\n");
7
8// cause bad mem access here
9return *(int*)(123);
10 }
11
12 int main () {
13printf( "hello world\n");
14// bad access here
15bad_acc();
16printf("bye world\n");
17return 0;
18 }
vyng-macbookpro2%
// Compile and run with lldb:
% clang -g -o bad_acc bad_access.cc
% lldb
(lldb) target create "bad_acc"
Current executable set to '/bad_acc' (x86_64).
(lldb)
Current executable set to '/bad_acc' (x86_64).
(lldb) run
Process 97548 launched: '/bad_acc' (x86_64)
hello world
in bad_acc()
Process 97548 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS
(code=1, address=0x7b)
frame #0: 0x00013f0b bad_acc`bad_acc() at bad_access.cc:9:10
6 printf("in bad_acc()\n");
7
8 // cause bad mem access here
-> 9 return *(int*)(123);
10 }
11
12 int main () {
Target 1: (bad_acc) stopped.
(lldb) thread return
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS
(code=1, address=0x7b)
frame #0: 0x00013f45 bad_acc`main at bad_access.cc:16:3
13 printf( "hello world\n");
14 // bad access here
15 bad_acc();
-> 16 printf("bye world\n");
17 return 0;
18 }
(lldb) register write pc `$pc-8`
(lldb) register write pc `$pc-8`
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS
(code=1, address=0x7b)
* frame #0: 0x00013f35 bad_acc`main at bad_access.cc:13:3
frame #1: 0x7fff204e8f5d libdyld.dylib`start + 1
frame #2: 0x7fff204e8f5d libdyld.dylib`start + 1
(lldb) n
Process 97548 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS
(code=1, address=0x27e80d)
frame #0: 0x00013f35 bad_acc`main at bad_access.cc:13:3
10 }
11
12 int main () {
-> 13 printf( "hello world\n");
14 // bad access here
15 bad_acc();
16 printf("bye world\n");
Target 1: (bad_acc) stopped.
--
Details:
After the processed stopped on bad_access.cc:9, I used `thread return` and two
`register write pc `$pc-8`` hoping to get back to bad_access.cc:13 to restart
the exececution.
- Expected behaviour: the exception is cleared and the program restarted.
- What actually happened: exception didn't clear and the program failed to
continue. (Even though `bt` showed that we were now back to line 13).
--
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 50949] New: VectorCombine index optimization isn't poison-safe
https://bugs.llvm.org/show_bug.cgi?id=50949
Bug ID: 50949
Summary: VectorCombine index optimization isn't poison-safe
Product: libraries
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: Scalar Optimizations
Assignee: florian_h...@apple.com
Reporter: efrie...@quicinc.com
CC: llvm-bugs@lists.llvm.org
https://reviews.llvm.org/D102476#inline-996311 . For reference, IR that is
mis-optimized:
define void @insert_store_nonconst_index_known_valid_by_and(<16 x i8>* %q, i8
zeroext %s, i32 %idx) {
entry:
%0 = load <16 x i8>, <16 x i8>* %q
%idx.clamped = and i32 %idx, 7
%vecins = insertelement <16 x i8> %0, i8 %s, i32 %idx.clamped
store <16 x i8> %vecins, <16 x i8>* %q
ret void
}
--
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 50943] Inline asm miscompile (test segfaults)
https://bugs.llvm.org/show_bug.cgi?id=50943 Paul Robinson changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #4 from Paul Robinson --- (In reply to Craig Topper from comment #3) > I'm not sure there's an alignment requirement for that array other than what > is implied by float. Versions of gcc prior to 5 use align 16 with -Os and > align 32 with -O2. > > Adding __attribute__ ((aligned (32))) to the struct definition also appears > to fix the crash. I was coming to the same conclusion. I threw in some alignof() expressions and they all report 4. Pumping up the alignment in the generated code seems rather optional. I'll resolve this as invalid and we'll patch the test to enforce the required alignment. -- 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 35110] [LazyCallGraph][Inliner] Large compile-time slow down when using new pass manager
https://bugs.llvm.org/show_bug.cgi?id=35110 Yuanfang Chen changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED CC||yuanfang.c...@sony.com --- Comment #9 from Yuanfang Chen --- Fixed by 468fa03 -- 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 50950] New: [concepts] explicit specialization 'template<>' syntax permitted when declaring a terse function template
https://bugs.llvm.org/show_bug.cgi?id=50950 Bug ID: 50950 Summary: [concepts] explicit specialization 'template<>' syntax permitted when declaring a terse function template Product: clang Version: unspecified Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: C++2a Assignee: unassignedclangb...@nondot.org Reporter: richard-l...@metafoo.co.uk CC: blitzrak...@gmail.com, erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk Clang incorrectly permits this syntax: template concept X = true; template<> void f(X auto x); ... treating the second line as the declaration of a function template. But 'template<>' always means an explicit specialization is being declared. We should diagnose the 'template<>' in this case and suggest that it be removed. -- 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 35702 in oss-fuzz: llvm:clang-fuzzer: Stack-overflow in MemoryBufferMem::getBufferIdentifier
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-2021-07-01 Type: Bug New issue 35702 by ClusterFuzz-External: llvm:clang-fuzzer: Stack-overflow in MemoryBufferMem::getBufferIdentifier https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=35702 Detailed Report: https://oss-fuzz.com/testcase?key=5109478797213696 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: clang-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Stack-overflow Crash Address: 0x7ffd3b2cae88 Crash State: MemoryBufferMem::getBufferIdentifier llvm::MemoryBuffer::getMemBufferRef clang::SrcMgr::ContentCache::getBufferOrNone Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202106290600:202106300601 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5109478797213696 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] Issue 35703 in oss-fuzz: llvm:llvm-opt-fuzzer--x86_64-loop_vectorize: ASSERT: AR && "Invalid addrec expression"
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-2021-07-01 Type: Bug New issue 35703 by ClusterFuzz-External: llvm:llvm-opt-fuzzer--x86_64-loop_vectorize: ASSERT: AR && "Invalid addrec expression" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=35703 Detailed Report: https://oss-fuzz.com/testcase?key=6024696482103296 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: llvm-opt-fuzzer--x86_64-loop_vectorize Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: ASSERT Crash Address: Crash State: AR && "Invalid addrec expression" llvm::RuntimePointerChecking::insert AccessAnalysis::createCheckForAccess Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202102190600:202102200620 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=6024696482103296 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 50951] New: Completion for designated initializers of anonymous structures
https://bugs.llvm.org/show_bug.cgi?id=50951
Bug ID: 50951
Summary: Completion for designated initializers of anonymous
structures
Product: clang-tools-extra
Version: unspecified
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: clangd
Assignee: unassignedclangb...@nondot.org
Reporter: michaelagan...@gmail.com
CC: llvm-bugs@lists.llvm.org
Completion of nested initializers now works as of clangd version 13.0.0.
Unfortunately, it does not seem to support anonymous structures and unions.
struct test {
struct {
int x;
struct {
int y;
} nested;
} nested;
struct {
int z,w;
}; // anonymous struct
};
int main()
{
struct test t = {
.nested = { .x = 3, .nested = { .y = 6 }, }, // full completion
. // no completion for anonymous struct members z,w
};
return 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] Issue 35706 in oss-fuzz: llvm:clang-fuzzer: Stack-overflow in clang::Sema::LookupName
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-2021-07-01 Type: Bug New issue 35706 by ClusterFuzz-External: llvm:clang-fuzzer: Stack-overflow in clang::Sema::LookupName https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=35706 Detailed Report: https://oss-fuzz.com/testcase?key=5141173877473280 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: clang-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Stack-overflow Crash Address: 0x7ffcf5576fc0 Crash State: clang::Sema::LookupName clang::Sema::LookupTemplateName clang::Sema::isTemplateName Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202106250604:202106260607 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5141173877473280 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
