[llvm-bugs] Issue 31292 in oss-fuzz: llvm:llvm-opt-fuzzer--x86_64-sccp: Out-of-memory in llvm-opt-fuzzer--x86_64-sccp
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 Reproducible Engine-libfuzzer OS-Linux Proj-llvm Reported-2021-02-23 Type: Bug New issue 31292 by ClusterFuzz-External: llvm:llvm-opt-fuzzer--x86_64-sccp: Out-of-memory in llvm-opt-fuzzer--x86_64-sccp https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=31292 Detailed Report: https://oss-fuzz.com/testcase?key=5918984757182464 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: llvm-opt-fuzzer--x86_64-sccp Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Out-of-memory (exceeds 2560 MB) Crash Address: Crash State: llvm-opt-fuzzer--x86_64-sccp Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201802070726:201802080701 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5918984757182464 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 49328] New: Fix fatal error reported on Windows when stdout fed to process which terminates before all output written
https://bugs.llvm.org/show_bug.cgi?id=49328
Bug ID: 49328
Summary: Fix fatal error reported on Windows when stdout fed to
process which terminates before all output written
Product: tools
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: llvm-objdump
Assignee: unassignedb...@nondot.org
Reporter: jh7370.2...@my.bristol.ac.uk
CC: llvm-bugs@lists.llvm.org
I'm filing this against llvm-objdump, as that was the tool where this was first
noticed, but the issue is likely generic to most tools that produce stdout
output that might be redirected to the stdin of another process. If the other
process terminates before reading all the output (for example a tool like
"head"), then a crash in llvm-objdump is seen.
Example head.c:
#include
static char buf[10240];
extern int atoi(const char *);
int main(int argc, char **argv)
{
int i, n = atoi(argv[1]);
for (i=0; illvm-objdump -d test.elf | head 10
LLVM ERROR: IO failure on output stream: invalid argument
PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash
backtrace.
Sometimes the backtrace doesn't appear after this, sometimes it does.
I debugged the behaviour. The error is reported because an error is stored in
the raw_fd_ostream for stdout, which hasn't been cleared, and as such a
report_fatal_error is triggered in the raw_fd_ostream's destructor. The error
is originally generated during a call to write_impl, and actually comes from
the call to ::write in that function. ::write sets errno to EINVAL, which is
the value stored in the stream's EC member.
After digging into the behaviour of ::write, I discovered the actual error
comes from an underlying call to WriteFile, after which the GetLastError()
return is ERROR_NO_DATA. Later, this value is translated into EINVAL for
placing in errno, which is not a particularly useful value for errno, as it
could represent a number of different failures. ERROR_NO_DATA on the other hand
is somewhat clearer - it appears to signal that the reader end of the pipe has
been closed when the writer attempts to write to it. I have searched around,
and the documentation for this behaviour is virtually non-existent, although
there are others who have confirmed that the error we see is seen by them in
the same situation too.
Fortunately, ERROR_NO_DATA is still returned by GetLastError by the time
::write returns. As such, we could detect this specific error value if errno is
EINVAL and do something different to what we do now. As it seems not
unreasonable for a process to hang up after it has received all the data it
wants, it might make sense to throw away all subsequent output if that error
has ever been detected. It doesn't seem right that we get a fatal error (i.e. a
crash) instead.
--
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 49329] New: Crash on invalid: ResolveSingleFunctionTemplateSpecialization
https://bugs.llvm.org/show_bug.cgi?id=49329
Bug ID: 49329
Summary: Crash on invalid:
ResolveSingleFunctionTemplateSpecialization
Product: clang
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: hok...@google.com
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
Testcase:
template
class C {
public:
template
class Type {
};
};
template
class A {
public:
void foo() {
C::template Type<2>;
}
};
void test() {
A a;
a.foo();
}
Crash stack trace:
clang: llvm-project/llvm/include/llvm/Support/Casting.h:269: typename
cast_retty::ret_type llvm::cast(Y *) [X = clang::FunctionTemplateDecl,
Y = clang::NamedDecl]: Assertion `isa(Val) && "cast() argument of
incompatible type!"' failed.
PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash
backtrace, preprocessed source, and associated run script.
Stack dump:
0. Program arguments: ./bin/clang -cc1 -ast-dump /tmp/t1.cpp
1. parser at end of file
2. /tmp/t1.cpp:13:8: instantiating function definition 'A::foo'
#0 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int)
llvm-project/llvm/lib/Support/Unix/Signals.inc:565:11
#1 PrintStackTraceSignalHandler(void*)
llvm-project/llvm/lib/Support/Unix/Signals.inc:632:1
#2 llvm::sys::RunSignalHandlers()
llvm-project/llvm/lib/Support/Signals.cpp:70:5
#3 SignalHandler(int) llvm-project/llvm/lib/Support/Unix/Signals.inc:407:1
#4 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x14140)
#5 raise ./signal/../sysdeps/unix/sysv/linux/raise.c:51:1
#6 abort ./stdlib/abort.c:81:7
#7 get_sysdep_segment_value ./intl/loadmsgcat.c:509:8
#8 _nl_load_domain ./intl/loadmsgcat.c:970:34
#9 (/lib/x86_64-linux-gnu/libc.so.6+0x34662)
#10 llvm::cast_retty::ret_type
llvm::cast(clang::NamedDecl*)
llvm-project/llvm/include/llvm/Support/Casting.h:270:10
#11
clang::Sema::ResolveSingleFunctionTemplateSpecialization(clang::OverloadExpr*,
bool, clang::DeclAccessPair*)
llvm-project/clang/lib/Sema/SemaOverload.cpp:12460:27
#12
clang::Sema::ResolveAndFixSingleFunctionTemplateSpecialization(clang::ActionResult&, bool, bool, clang::SourceRange, clang::QualType, unsigned int)
llvm-project/clang/lib/Sema/SemaOverload.cpp:12525:21
#13 clang::Sema::CheckPlaceholderExpr(clang::Expr*)
llvm-project/clang/lib/Sema/SemaExpr.cpp:19272:9
#14 clang::Sema::ActOnFinishFullExpr(clang::Expr*, clang::SourceLocation, bool,
bool) llvm-project/clang/lib/Sema/SemaExprCXX.cpp:8388:16
#15 clang::Sema::ActOnExprStmt(clang::ActionResult, bool)
llvm-project/clang/lib/Sema/SemaStmt.cpp:49:8
#16 clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformStmt(clang::Stmt*,
clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::StmtDiscardKind)
llvm-project/clang/lib/Sema/TreeTransform.h:3687:24
#17 clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformCompoundStmt(clang::CompoundStmt*,
bool) llvm-project/clang/lib/Sema/TreeTransform.h:7109:38
#18 clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformCompoundStmt(clang::CompoundStmt*)
llvm-project/clang/lib/Sema/TreeTransform.h:7095:23
#19 clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformStmt(clang::Stmt*,
clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::StmtDiscardKind)
llvm-project/build-debug/tools/clang/include/clang/AST/StmtNodes.inc:73:1
#20 clang::Sema::SubstStmt(clang::Stmt*, clang::MultiLevelTemplateArgumentList
const&) llvm-project/clang/lib/Sema/SemaTemplateInstantiate.cpp:3460:23
#21 clang::Sema::InstantiateFunctionDefinition(clang::SourceLocation,
clang::FunctionDecl*, bool, bool, bool)
llvm-project/clang/lib/Sema/SemaTemplateInstantiateDecl.cpp:4892:14
#22 clang::Sema::PerformPendingInstantiations(bool)
llvm-project/clang/lib/Sema/SemaTemplateInstantiateDecl.cpp:6139:13
#23 clang::Sema::ActOnEndOfTranslationUnitFragment(clang::Sema::TUFragmentKind)
llvm-project/clang/lib/Sema/Sema.cpp:995:3
#24 clang::Sema::ActOnEndOfTranslationUnit()
llvm-project/clang/lib/Sema/Sema.cpp:1030:5
Looks like this is a regression, it is in trunk, but not reproducible in
clang-11.0.1.
--
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 48416] TestConflictingSymbols :: test_conflicting_symbols fails on FreeBSD
https://bugs.llvm.org/show_bug.cgi?id=48416 Michał Górny changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #1 from Michał Górny --- I can no longer reproduce the failure, so I guess it's been fixed independently. I'm removing the XFAIL from the test. -- 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 49331] New: generate links to source files with element definitions in clang-doc markdown
https://bugs.llvm.org/show_bug.cgi?id=49331 Bug ID: 49331 Summary: generate links to source files with element definitions in clang-doc markdown Product: clang-tools-extra Version: unspecified Hardware: Macintosh OS: MacOS X Status: NEW Severity: enhancement Priority: P Component: clang-doc Assignee: unassignedclangb...@nondot.org Reporter: mbo...@bellsouth.net CC: llvm-bugs@lists.llvm.org, pho...@chromium.org Hello, First of all, thank you for your work. I recently tried clang-doc to see if it would be a potential replacement for doxygen for a documentation site I am working on. One nice feature of doxygen is that it will create links to source files that define functions/variables/etc with the line highlighted. I am not sure how achievable this would be, but I have seen it elsewhere like the documentation for rust packages and have found it useful. Since the documentation is pretty bare bones at the moment, this may be an existing clang-doc feature, in which case I apologize. -- 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 31143 in oss-fuzz: llvm:llvm-isel-fuzzer--aarch64-gisel: ASSERT: DstTy.getSizeInBits() < SrcTy.getSizeInBits() && "invalid widening trunc"
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #1 on issue 31143 by ClusterFuzz-External: llvm:llvm-isel-fuzzer--aarch64-gisel: ASSERT: DstTy.getSizeInBits() < SrcTy.getSizeInBits() && "invalid widening trunc" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=31143#c1 ClusterFuzz testcase 6029046246932480 is verified as fixed in https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202102220625:202102230619 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 49332] New: Default constructors of node-based containers don't construct allocators
https://bugs.llvm.org/show_bug.cgi?id=49332
Bug ID: 49332
Summary: Default constructors of node-based containers don't
construct allocators
Product: libc++
Version: 11.0
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: malts...@gmail.com
CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com
Consider the following code:
https://godbolt.org/z/Tn73Me
#include
#include
#include
#include
#include
#include
#include
int n_alloc = 0;
struct alloc : public std::allocator {
alloc() { n_alloc++; };
};
int main(void)
{
std::vector c1;
printf("n_alloc: %d\n", n_alloc);
std::deque c2;
printf("n_alloc: %d\n", n_alloc);
std::forward_list c3;
printf("n_alloc: %d\n", n_alloc);
std::list c4;
printf("n_alloc: %d\n", n_alloc);
std::set, alloc> c5;
printf("n_alloc: %d\n", n_alloc);
std::unordered_set, std::equal_to, alloc> c6;
printf("n_alloc: %d\n", n_alloc);
}
In [forwardlist.overview], the default constructor is specified as follows:
forward_list() : forward_list(Allocator()) { }
Similarly for other containers.
So, the expected output of the above program is:
1
2
3
4
5
6
But with libc++ (recent trunk version) the output is:
1
2
2
2
2
2
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 49118] [Integrated Assembler][Thumb2] ldr and str missing .w suffix aliases
https://bugs.llvm.org/show_bug.cgi?id=49118 Nick Desaulniers changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #11 from Nick Desaulniers --- https://reviews.llvm.org/rG1e204ac78952cf7e4fcf335423e80007388d3979 -- 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 49333] New: Compilation error in NVPTX deviceRLTs
https://bugs.llvm.org/show_bug.cgi?id=49333 Bug ID: 49333 Summary: Compilation error in NVPTX deviceRLTs Product: OpenMP Version: unspecified Hardware: PC OS: All Status: NEW Severity: release blocker Priority: P Component: Runtime Library Assignee: unassignedb...@nondot.org Reporter: tianshilei1...@gmail.com CC: llvm-bugs@lists.llvm.org A compilation error occurred when compiling OpenMP NVPTX deviceRTLs with Clang in the release branch. ``` FAILED: openmp/libomptarget/deviceRTLs/nvptx/target_impl.cu-cuda_111-sm_60.bc cd build-release/runtimes/runtimes-bins/openmp/libomptarget/deviceRTLs/nvptx && build-release/./bin/clang -S -x c++ -O1 -std=c++14 -target nvptx64 -Xclang -emit-llvm-bc -Xclang -aux-triple -Xclang x86_64-unknown-linux-gnu -fopenmp -fopenmp-cuda-mode -Xclang -fopenmp-is-device -D__CUDACC__ -Illvm-project/openmp/libomptarget/deviceRTLs -Illvm-project/openmp/libomptarget/deviceRTLs/nvptx/src -DOMPTARGET_NVPTX_DEBUG=0 -Xclang -target-cpu -Xclang sm_60 -D__CUDA_ARCH__=600 -Xclang -target-feature -Xclang +ptx71 -DCUDA_VERSION=11100 llvm-project/openmp/libomptarget/deviceRTLs/nvptx/src/target_impl.cu -o target_impl.cu-cuda_111-sm_60.bc llvm-project/openmp/libomptarget/deviceRTLs/nvptx/src/target_impl.cu:71:10: error: '__nvvm_shfl_sync_idx_i32' needs target feature ptx60|ptx61|ptx63|ptx64|ptx65|ptx70 return __nvvm_shfl_sync_idx_i32(Mask, Var, SrcLane, 0x1f); ^ llvm-project/openmp/libomptarget/deviceRTLs/nvptx/src/target_impl.cu:82:10: error: '__nvvm_shfl_sync_down_i32' needs target feature ptx60|ptx61|ptx63|ptx64|ptx65|ptx70 return __nvvm_shfl_sync_down_i32(Mask, Var, Delta, T); ^ llvm-project/openmp/libomptarget/deviceRTLs/nvptx/src/target_impl.cu:92:3: error: '__nvvm_bar_warp_sync' needs target feature ptx60|ptx61|ptx63|ptx64|ptx65|ptx70 __nvvm_bar_warp_sync(Mask); ^ ``` -- 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 49334] New: Segfault when running code with target nowait compiled for x86 offloading
https://bugs.llvm.org/show_bug.cgi?id=49334 Bug ID: 49334 Summary: Segfault when running code with target nowait compiled for x86 offloading Product: OpenMP Version: unspecified Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: Runtime Library Assignee: unassignedb...@nondot.org Reporter: tianshilei1...@gmail.com CC: llvm-bugs@lists.llvm.org Created attachment 24567 --> https://bugs.llvm.org/attachment.cgi?id=24567&action=edit reproducer The test case is attached. Compilation command: ``` $ clang++ -fopenmp -fopenmp-targets=x86_64 bug.cpp ``` -- 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 48902] [meta] 12.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=48902 Bug 48902 depends on bug 49333, which changed state. Bug 49333 Summary: Compilation error in NVPTX deviceRLTs https://bugs.llvm.org/show_bug.cgi?id=49333 What|Removed |Added Status|CONFIRMED |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
[llvm-bugs] [Bug 49333] Compilation error in NVPTX deviceRLTs
https://bugs.llvm.org/show_bug.cgi?id=49333 Tom Stellard changed: What|Removed |Added Status|CONFIRMED |RESOLVED Fixed By Commit(s)|89827fd404f954605663776e746 |89827fd404f954605663776e746 |ec351bde61348 |ec351bde61348 2f74c2204827 Resolution|--- |FIXED --- Comment #4 from Tom Stellard --- Merged: 2f74c2204827 -- 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 49140] Cherry-pick f74318491134356a19ba2d9673f89c8b74ff3692 to 12.x release
https://bugs.llvm.org/show_bug.cgi?id=49140 Tom Stellard changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 48902] [meta] 12.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=48902 Bug 48902 depends on bug 49140, which changed state. Bug 49140 Summary: Cherry-pick f74318491134356a19ba2d9673f89c8b74ff3692 to 12.x release https://bugs.llvm.org/show_bug.cgi?id=49140 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 49257] -mharden-sls=all caused some kernels fail too boot
https://bugs.llvm.org/show_bug.cgi?id=49257 Nick Desaulniers changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |INVALID --- Comment #5 from Nick Desaulniers --- Makes sense, thanks for the additional info. -- 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 4068] [Meta] Compiling the Linux kernel with clang
https://bugs.llvm.org/show_bug.cgi?id=4068 Bug 4068 depends on bug 49257, which changed state. Bug 49257 Summary: -mharden-sls=all caused some kernels fail too boot https://bugs.llvm.org/show_bug.cgi?id=49257 What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |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 49214] [NewPM] Failure to build SPEC17 (compiler hang)
https://bugs.llvm.org/show_bug.cgi?id=49214 Jonas Paulsson changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Jonas Paulsson --- > It's not hanging for me. The legacy PM finishes in 16s, the new PM finishes > in 20s. Thanks for taking a look - this seems to be gone now after 468fa03 "Only verify LazyCallGraph under expensive checks" -- 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 49006] llvm.var.annotation and llvm.ptr.annotation aren't auto-upgraded
https://bugs.llvm.org/show_bug.cgi?id=49006 Tom Stellard changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Fixed By Commit(s)|9a827906cb95e7c3ae94627558d |9a827906cb95e7c3ae94627558d |a67b47ffde249 |a67b47ffde249 eccac5a8aec9 --- Comment #9 from Tom Stellard --- Merged: eccac5a8aec9 -- 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 48902] [meta] 12.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=48902 Bug 48902 depends on bug 49006, which changed state. Bug 49006 Summary: llvm.var.annotation and llvm.ptr.annotation aren't auto-upgraded https://bugs.llvm.org/show_bug.cgi?id=49006 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 49317] [meta] 12.0.1 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=49317 Bug 49317 depends on bug 49006, which changed state. Bug 49006 Summary: llvm.var.annotation and llvm.ptr.annotation aren't auto-upgraded https://bugs.llvm.org/show_bug.cgi?id=49006 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 49335] New: libcall simplification not reliably being applied by early instcombine
https://bugs.llvm.org/show_bug.cgi?id=49335
Bug ID: 49335
Summary: libcall simplification not reliably being applied by
early instcombine
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: richard-l...@metafoo.co.uk
CC: llvm-bugs@lists.llvm.org
Testcase (https://godbolt.org/z/s3cxzv):
#include
bool f(llvm::StringRef s) {
return s.size() > 1 && s[0] == '0';
}
bool g(llvm::StringRef s) {
return s.startswith("0") && s != "0";
}
I would expect `f` and `g` to produce equivalent code, but they don't. `f`
produces a branch on size followed by a comparison of s[0]:
%3 = icmp ugt i64 %1, 1
br i1 %3, label %4, label %7
4:; preds = %2
%5 = load i8, i8* %0, align 1, !tbaa !2
%6 = icmp eq i8 %5, 48
br label %7
7:; preds = %4, %2
%8 = phi i1 [ false, %2 ], [ %6, %4 ]
ret i1 %8
That seems fine. But `g` compares `s[0]` against `'0'` twice:
%3 = icmp eq i64 %1, 0
br i1 %3, label %12, label %4
4:; preds = %2
%5 = load i8, i8* %0, align 1
%6 = icmp eq i8 %5, 48
br i1 %6, label %7, label %12
7:; preds = %4
%8 = icmp eq i64 %1, 1
br i1 %8, label %9, label %12
9:; preds = %7
%10 = load i8, i8* %0, align 1
%11 = icmp ne i8 %10, 48
br label %12
12: ; preds = %2, %9, %7, %4
%13 = phi i1 [ false, %4 ], [ true, %7 ], [ %11, %9 ], [ false, %2 ]
ret i1 %13
We don't seem to notice that %10 is identical to %5.
It looks like (https://godbolt.org/z/MaPvMY) the second load is part of a call
to @bcmp until too late. Early InstCombinePasses leave the @bcmp call alone,
and it's only transformed to a load-and-compare by the InstCombinePass that
runs immediately after the BDCE pass, but we don't do any more GVN after that
point.
It's not clear to me why the pre-GVN InstCombine doesn't fire on the @bcmp
call:
%10 = tail call i32 @bcmp(i8* nonnull %0, i8* getelementptr inbounds ([2 x
i8], [2 x i8]* @.str, i64 0, i64 0), i64 %1) #7
... but the post-GVN InstCombine does fire on an apparently-identical call. (In
fact, the entire function appears to be identical according to
-print-after-all, but InstCombine does different things?)
--
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 31316 in oss-fuzz: llvm:clang-fuzzer: ASSERT: DS.getAttributes().empty() && "No attribute expected"
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 Reproducible Stability-Memory-MemorySanitizer Engine-libfuzzer OS-Linux Proj-llvm Reported-2021-02-24 Type: Bug New issue 31316 by ClusterFuzz-External: llvm:clang-fuzzer: ASSERT: DS.getAttributes().empty() && "No attribute expected" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=31316 Detailed Report: https://oss-fuzz.com/testcase?key=6325477242437632 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: clang-fuzzer Job Type: libfuzzer_msan_llvm Platform Id: linux Crash Type: ASSERT Crash Address: Crash State: DS.getAttributes().empty() && "No attribute expected" clang::Sema::BuildAnonymousStructOrUnion clang::Sema::ParsedFreeStandingDeclSpec Sanitizer: memory (MSAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_msan_llvm&range=201912200437:201912220428 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=6325477242437632 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 49336] New: Conditional branches are exchanged unoptimally
https://bugs.llvm.org/show_bug.cgi?id=49336
Bug ID: 49336
Summary: Conditional branches are exchanged unoptimally
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Backend: X86
Assignee: unassignedb...@nondot.org
Reporter: car...@google.com
CC: craig.top...@gmail.com, llvm-bugs@lists.llvm.org,
llvm-...@redking.me.uk, pengfei.w...@intel.com,
spatel+l...@rotateright.com
The following code is extracted from zippy. Compile it with -O2
#include
#define PREDICT_FALSE(x) __builtin_expect((x), 0)
volatile int g;
std::pair
foo(char* ip, char* ip_limit, int op) {
do {
char* old_ip = ip;
int tag_type = g;
ip = ip + 1;
int offset = *old_ip;
if (offset < 8) {
ip = ip + 2;
}
int delta = op - offset;
if (PREDICT_FALSE(delta < 0)) {
if (tag_type != 0) {
ip = old_ip;
break;
}
}
op += 8;
} while (ip < ip_limit);
return {ip, op};
}
LLVM generates:
_Z3fooPcS_i:# @_Z3fooPcS_i
.cfi_startproc
# %bb.0:# %entry
movq%rdi, %rax
jmp .LBB0_1
.p2align4, 0x90
.LBB0_3:# %cleanup
# in Loop: Header=BB0_1 Depth=1
movb%r8b, %cl
leaq(%rax,%rcx,2), %rax
addq$1, %rax
addl$8, %edx
cmpq%rsi, %rax
jae .LBB0_4
.LBB0_1:# %do.body
# =>This Inner Loop Header: Depth=1
movlg(%rip), %r9d
movsbl (%rax), %edi
xorl%ecx, %ecx
cmpl$8, %edi
setl%r8b
testl %r9d, %r9d // if (tag_type != 0)
je .LBB0_3
# %bb.2:# %do.body
# in Loop: Header=BB0_1 Depth=1
cmpl%edi, %edx // if (PREDICT_FALSE(delta < 0))
jge .LBB0_3
.LBB0_4:# %do.end
retq
The condition (tag_type != 0) is unpredictable, but (delta < 0) is predicted as
false, so the unpredictable condition (tag_type != 0) is rarely executed.
But in the generated code, llvm changed the order of the two conditions, so the
unpredictable condition is always executed, causes more branch mis-prediction.
--
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 49251] Undefined symbol with CFI and __attribute__((__used__))
https://bugs.llvm.org/show_bug.cgi?id=49251 Teresa Johnson changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Teresa Johnson --- The fix went in at fde55a9c9bf147241249ae478760ae69dd1925ed. Note that the commit causing this issue caused an additional issue that I also just fixed at 0a5949dcfa31d599353fb4ccf4d207bdae7c7281. -- 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 48389] ld64.lld.darwinnew unwind info is incorrect
https://bugs.llvm.org/show_bug.cgi?id=48389 Jez Ng changed: What|Removed |Added Fixed By Commit(s)||rG4a5e111aea7ac78190211a254 ||9f8d0d53ee2f01d Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|unassignedb...@nondot.org |jezr...@gmail.com -- 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 49337] New: accept-invalid: __builtin_types_compatible_p pollutes the environment of tag type checking
https://bugs.llvm.org/show_bug.cgi?id=49337
Bug ID: 49337
Summary: accept-invalid: __builtin_types_compatible_p pollutes
the environment of tag type checking
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: zhan3...@purdue.edu
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org,
neeil...@live.com, richard-l...@metafoo.co.uk
I am not sure how to accurately describe the problem. In short,
Following code is obviously invalid, as the use of 'X' with tag type does not
match previous declaration (https://godbolt.org/z/qad8vz).
$ cat case1.c
struct X {
union X {
int b;
long c;
} d;
} a;
int main() { return 0; }
However, when we put this erroneous declaration into a
__builtin_types_compatible_p function, clang accepts it
(https://godbolt.org/z/TrxTzs). Note that it is rejected by GCC
(https://godbolt.org/z/rWde88).
$ cat case2.c
int main() {
int a = __builtin_types_compatible_p(int, struct X {
union X {
int b;
long c;
} d;
});
return a;
}
Even worse, this invalid __builtin_types_compatible_p may additionally affects
other statements (https://godbolt.org/z/avxvzj), which, at least, gives the
wrong error reports.
$ cat case3.c
int main() {
int a = __builtin_types_compatible_p(int, struct X {
union X {
int b;
long c;
} d;
});
enum X { A, B } h;
h = A;
return a;
}
$ clang case3.c
#1 with x86-64 clang (trunk)
case3.c:10:9: error: use of undeclared identifier 'A'
h = A;
^
1 error generated.
--
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 49185] opt -O3 crashes with Assertion `NewL->getParentLoop() == ParentL && "All of the new loops must be siblings of the current loop!"' failed. with new PM
https://bugs.llvm.org/show_bug.cgi?id=49185 Mikael Holmén changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #6 from Mikael Holmén --- (In reply to Arthur Eubanks from comment #5) > There's no way to get a list of passes for -O3 under the new PM. > Almost every time I debug an opt problem I start with "opt -O " and I want to reach an "opt " reproducer to get an as small and stable reproducer as possible that isolates the real problem. Normally I use -debug-pass=Arguments along with reducing the input program, and in most cases I end up with what I want. How do we achieve this with the new PM then? I'm sure people already working with the new PM want to do the same thing, so how do you do? I already sent an email to llvm-dev with this question but unfortunately got zero replies so far: https://lists.llvm.org/pipermail/llvm-dev/2021-February/148551.html > I can't repro the crash locally at head. Perhaps it's fixed? Or maybe I'm > not specifying the right backend target since it's not specified in the .ll > file. Yes it was fixed in f70cdc5b5c. -- 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
