[llvm-bugs] Issue 28711 in oss-fuzz: llvm:clang-fuzzer: Stack-overflow in clang::Sema::CppLookupName
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-12-16 Type: Bug New issue 28711 by ClusterFuzz-External: llvm:clang-fuzzer: Stack-overflow in clang::Sema::CppLookupName https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=28711 Detailed Report: https://oss-fuzz.com/testcase?key=5179402254155776 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: clang-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Stack-overflow Crash Address: 0x7fffc2d9aff8 Crash State: clang::Sema::CppLookupName clang::Sema::LookupName clang::Sema::LookupTemplateName Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202011130615:202011140605 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5179402254155776 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 48525] dynamic_cast throws off clang-tidy's nullptr analysis
https://bugs.llvm.org/show_bug.cgi?id=48525 Nathan James changed: What|Removed |Added CC||dcough...@apple.com, ||llvm-bugs@lists.llvm.org, ||n.jame...@hotmail.co.uk Product|clang-tools-extra |clang Assignee|unassignedclangbugs@nondot. |dcough...@apple.com |org | Component|clang-tidy |Static Analyzer --- Comment #1 from Nathan James --- This is an issue with the clang static analyser, not clang tidy -- 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 45698] Handle out-of-order PT_LOADs better
https://bugs.llvm.org/show_bug.cgi?id=45698 George Rimar changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #2 from George Rimar --- Fixed in 78aea98308a85c061a87952e9842bf1e6fe097d5 -- 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 48529] New: Reassociate reorders evaluation of short-circuited comparisons
https://bugs.llvm.org/show_bug.cgi?id=48529 Bug ID: 48529 Summary: Reassociate reorders evaluation of short-circuited comparisons Product: new-bugs Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: mhil...@linux.ibm.com CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org Created attachment 24291 --> https://bugs.llvm.org/attachment.cgi?id=24291&action=edit Example that demonstrates the reordering; clang++ -g -S -O2 -o- shortcircuit.cpp The Reassociate pass can end up reordering the evaluation of short-circuited comparisons, when SimplifyCFG folded them to to OR expressions and CodeGen later unfolds the OR expressions into short-circuited form. There is a check in Reassociate that attempts to prevent reordering in these cases, yet that check happens a few lines of code too late (see below). I have attached an example that reproduces on targets X86-64 and SystemZ. In my reduced example (attached), the expression if (ab > de || ac > df || bc > cd) return 0; is first emitted as short-circuited by clang, then SimplifyCFG folds the latter two comparisons into an OR ... %cmp6 = fcmp contract ogt float %mul1, %mul4 (i.e., ac and df) %cmp8 = fcmp contract ogt float %mul2, %mul5 (i.e., bc and cd) %or.cond26 = or i1 %cmp6, %cmp8, br i1 %or.cond26, label %cleanup, label %if.end, ... and Reassociate flips the operands of the OR (ranks just happen to turn out that way) ... %or.cond26 = or i1 %cmp8, %cmp6 ... When CodeGen turns that back into short-circuited form, honoring that new order, the emitted code checks bc > cd before ac > df, potentially ignoring the intent behind the order in the code. A code comment explicitly states that behavior as undesired, with a guard to return early. However, that check ... https://github.com/llvm/llvm-project/blob/9f80ab1213e9f28b1b86f133fa7edf9a61c6f8fd/llvm/lib/Transforms/Scalar/Reassociate.cpp#L2204 // Do not reassociate boolean (i1) expressions. We want to preserve the // original order of evaluation for short-circuited comparisons that // SimplifyCFG has folded to AND/OR expressions. If the expression // is not further optimized, it is likely to be transformed back to a // short-circuited form for code gen, and the source order may have been // optimized for the most likely conditions. if (I->getType()->isIntegerTy(1)) return; ... is too late, since the reordering already happens before in canonicalizeOperands https://github.com/llvm/llvm-project/blob/9f80ab1213e9f28b1b86f133fa7edf9a61c6f8fd/llvm/lib/Transforms/Scalar/Reassociate.cpp#L2193 // Commute binary operators, to canonicalize the order of their operands. // This can potentially expose more CSE opportunities, and makes writing other // transformations simpler. if (I->isCommutative()) canonicalizeOperands(I); Moving the check for a boolean expression up above the call to canonicalizeOperands would prevent the reordering. (fwiw, that change passes the testsuite). -- 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 48530] New: [InlineCost] uninitialized InlineCost field cause behave different with Debug and Release mode
https://bugs.llvm.org/show_bug.cgi?id=48530
Bug ID: 48530
Summary: [InlineCost] uninitialized InlineCost field cause
behave different with Debug and Release mode
Product: libraries
Version: 10.0
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: Interprocedural Optimizations
Assignee: unassignedb...@nondot.org
Reporter: zhongyu...@tom.com
CC: llvm-bugs@lists.llvm.org
In the commit 2094d5a03, Add a new field InRecursiveFunction without default
value. so for a non-recursive function, the value Params.InRecursiveFunction is
not uninitialized, which is used in function updateThreshold.
@@ -178,6 +179,9 @@ struct InlineParams {
/// Compute inline cost even when the cost has exceeded the threshold.
Optional ComputeFullInlineCost;
+
+ /// Inside recursive function
+ bool InRecursiveFunction;
};
@@ -1252,6 +1253,12 @@ void InlineCostCallAnalyzer::updateThreshold(CallBase
&Call, Function &Callee) {
// Cost in updateThreshold, but the bonus depends on the logic in this
method.
if (OnlyOneCallAndLocalLinkage)
Cost -= LastCallToStaticBonus;
+
+ // Add bonus to callsites within recursive functions
+ if (Call.getCaller() != Call.getCalledFunction() &&
+ Params.InRecursiveFunction) {
+Cost -= CallerRecursiveBonus;
+ }
--
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 48531] New: opt crashed with "-licm": Assertion `MSSA->dominates(NewDef, FirstDef) && "Should have dominated the new access"' failed.
https://bugs.llvm.org/show_bug.cgi?id=48531
Bug ID: 48531
Summary: opt crashed with "-licm": Assertion
`MSSA->dominates(NewDef, FirstDef) && "Should have
dominated the new access"' failed.
Product: new-bugs
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: suochen...@163.com
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org
Created attachment 24292
--> https://bugs.llvm.org/attachment.cgi?id=24292&action=edit
bc file pased to opt
***
OS and Platform:
CentOS Linux release 7.8.2003 (Core), x86_64 GNU/Linux
***
Program:
int a, d;
short b;
long c;
void e() {
f : {
int g;
for (; 1; d++)
;
if (g) {
if (a)
goto h;
i:
if (b)
h:
goto f;
}
if (c)
goto i;
}
}
int main() {}
***
clang version:
$ clang -v
clang version 12.0.0 (/home/suocy/src/llvm-dev/llvm-project/llvm/tools/clang
cee1e7d14f4628d6174b33640d502bff3b54ae45)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /home/suocy/bin/llvm-dev/bin
Found candidate GCC installation:
/opt/rh/devtoolset-7/root/usr/lib/gcc/x86_64-redhat-linux/7
Found candidate GCC installation: /usr/lib/gcc/x86_64-redhat-linux/4.8.2
Found candidate GCC installation: /usr/lib/gcc/x86_64-redhat-linux/4.8.5
Selected GCC installation:
/opt/rh/devtoolset-7/root/usr/lib/gcc/x86_64-redhat-linux/7
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Selected multilib: .;@m64
***
Command Lines:
$ clang -O3 -mllvm -disable-llvm-optzns -c -emit-llvm a.c -o a.bc
$ opt -licm a.bc -o a.opt.bc
opt:
/home/suocy/src/llvm-dev/llvm-project/llvm/lib/Analysis/MemorySSAUpdater.cpp:508:
void llvm::MemorySSAUpdater::fixupDefs(const
llvm::SmallVectorImpl&): Assertion `MSSA->dominates(NewDef,
FirstDef) && "Should have dominated the new access"' failed.
PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash
backtrace.
Stack dump:
0. Program arguments: /home/suocy/bin/llvm-dev/bin/opt -licm a.bc -o
a.opt.bc
1. Running pass 'Function Pass Manager' on module 'a.bc'.
2. Running pass 'Loop Pass Manager' on function '@e'
3. Running pass 'Loop Invariant Code Motion' on basic block '%for.cond'
#0 0x02aa662c llvm::sys::PrintStackTrace(llvm::raw_ostream&, int)
(/home/suocy/bin/llvm-dev/bin/opt+0x2aa662c)
#1 0x02aa44a4 llvm::sys::RunSignalHandlers()
(/home/suocy/bin/llvm-dev/bin/opt+0x2aa44a4)
#2 0x02aa4603 SignalHandler(int)
(/home/suocy/bin/llvm-dev/bin/opt+0x2aa4603)
#3 0x7faffc316630 __restore_rt (/lib64/libpthread.so.0+0xf630)
#4 0x7faffaf04387 raise (/lib64/libc.so.6+0x36387)
#5 0x7faffaf05a78 abort (/lib64/libc.so.6+0x37a78)
#6 0x7faffaefd1a6 __assert_fail_base (/lib64/libc.so.6+0x2f1a6)
#7 0x7faffaefd252 (/lib64/libc.so.6+0x2f252)
#8 0x01b866d8
llvm::MemorySSAUpdater::fixupDefs(llvm::SmallVectorImpl const&)
(/home/suocy/bin/llvm-dev/bin/opt+0x1b866d8)
#9 0x01b869de llvm::MemorySSAUpdater::insertDef(llvm::MemoryDef*,
bool) (/home/suocy/bin/llvm-dev/bin/opt+0x1b869de)
#10 0x0281649a (anonymous
namespace)::LoopPromoter::doExtraRewritesBeforeFinalDeletion()
(/home/suocy/bin/llvm-dev/bin/opt+0x281649a)
#11 0x02be7d67
llvm::LoadAndStorePromoter::run(llvm::SmallVectorImpl
const&) (/home/suocy/bin/llvm-dev/bin/opt+0x2be7d67)
#12 0x02814bbf
llvm::promoteLoopAccessesToScalars(llvm::SmallSetVector
const&, llvm::SmallVectorImpl&,
llvm::SmallVectorImpl&,
llvm::SmallVectorImpl&, llvm::PredIteratorCache&,
llvm::LoopInfo*, llvm::DominatorTree*, llvm::TargetLibraryInfo const*,
llvm::Loop*, llvm::AliasSetTracker*, llvm::MemorySSAUpdater*,
llvm::ICFLoopSafetyInfo*, llvm::OptimizationRemarkEmitter*)
(/home/suocy/bin/llvm-dev/bin/opt+0x2814bbf)
#13 0x0281fe77 (anonymous
namespace)::LoopInvariantCodeMotion::runOnLoop(llvm::Loop*, llvm::AAResults*,
llvm::LoopInfo*, llvm::DominatorTree*, llvm::BlockFrequencyInfo*,
llvm::TargetLibraryInfo*, llvm::TargetTransformInfo*, llvm::ScalarEvolution*,
llvm::MemorySSA*, llvm::OptimizationRemarkEmitter*) (.part.767)
(/home/suocy/bin/llvm-dev/bin/opt+0x281fe77)
#14 0x02820bbd (anonymous
namespace)::LegacyLICMPass::runOnLoop(llvm::Loop*, llvm::LPPassManager&)
(/home/suocy/bin/llvm-dev/bin/opt+0x2820bbd)
#15 0x01b452b3 llvm::LPPassManager::runOnFunction(llvm::Function&)
(/home/suocy/bin/llvm-dev/bin/opt+0x1b452b3)
#16 0x022cdb58 llvm::FPPassManager::runOnFunction(llvm::Function&)
(/home/suocy/b
[llvm-bugs] [Bug 48491] Regression(6b3eecd22ab2): ld64.lld.darwinnew-linked programs using TLS crash at startup
https://bugs.llvm.org/show_bug.cgi?id=48491 Nico Weber changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #16 from Nico Weber --- https://reviews.llvm.org/rG31845199094418173a3beadb786767b860bfda03 -- 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 48532] New: Clang crashes when compiling libtorrent-rasterbar
https://bugs.llvm.org/show_bug.cgi?id=48532 Bug ID: 48532 Summary: Clang crashes when compiling libtorrent-rasterbar Product: clang Version: 10.0 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Frontend Assignee: unassignedclangb...@nondot.org Reporter: glas...@yandex.ru CC: llvm-bugs@lists.llvm.org, neeil...@live.com, richard-l...@metafoo.co.uk Stack dump: 0. Program arguments: /usr/bin/clang++ -DBOOST_ASIO_ENABLE_CANCELIO -DBOOST_ASIO_HAS_STD_CHRONO -DBOOST_EXCEPTION_DISABLE -DTORRENT_BUILDING_LIBRARY -DTORRENT_BUILDING_SHARED -DTORRENT_USE_ASSERTS -DTORRENT_USE_ICONV -DTORRENT_USE_LIBCRYPTO -DTORRENT_USE_OPENSSL -D_FILE_OFFSET_BITS=64 -Dtorrent_rasterbar_EXPORTS -I/home/glassez/Projects/libtorrent/include -g -fPIC -fvisibility=hidden -fvisibility-inlines-hidden -Weverything -Wno-documentation -Wno-c++98-compat-pedantic -Wno-padded -Wno-global-constructors -Wno-exit-time-destructors -Wno-weak-vtables -fexceptions -std=gnu++14 -MD -MT CMakeFiles/torrent-rasterbar.dir/src/peer_connection.cpp.o -MF CMakeFiles/torrent-rasterbar.dir/src/peer_connection.cpp.o.d -o CMakeFiles/torrent-rasterbar.dir/src/peer_connection.cpp.o -c /home/glassez/Projects/libtorrent/src/peer_connection.cpp 1. parser at end of file 2. /home/glassez/Projects/libtorrent/src/peer_connection.cpp:92:11: LLVM IR generation of declaration 'libtorrent' 3. /home/glassez/Projects/libtorrent/src/peer_connection.cpp:582:24: Generating code for declaration 'libtorrent::peer_connection::peer_log' /usr/lib/x86_64-linux-gnu/libLLVM-10.so.1(_ZN4llvm3sys15PrintStackTraceERNS_11raw_ostreamE+0x1f)[0x7f5021e9d4ff] /usr/lib/x86_64-linux-gnu/libLLVM-10.so.1(_ZN4llvm3sys17RunSignalHandlersEv+0x50)[0x7f5021e9b7b0] /usr/lib/x86_64-linux-gnu/libLLVM-10.so.1(_ZN4llvm3sys15CleanupOnSignalEm+0xdd)[0x7f5021e9cc4d] /usr/lib/x86_64-linux-gnu/libLLVM-10.so.1(+0x8d6e60)[0x7f5021df2e60] /lib/x86_64-linux-gnu/libpthread.so.0(+0x153c0)[0x7f502866d3c0] /usr/lib/x86_64-linux-gnu/libclang-cpp.so.10(_ZN5clang7CodeGen15CodeGenFunction13EmitEndEHSpecEPKNS_4DeclE+0xce)[0x7f5027097ede] /usr/lib/x86_64-linux-gnu/libclang-cpp.so.10(_ZN5clang7CodeGen15CodeGenFunction14FinishFunctionENS_14SourceLocationE+0x2d0)[0x7f502721acf0] /usr/lib/x86_64-linux-gnu/libclang-cpp.so.10(_ZN5clang7CodeGen15CodeGenFunction17EmitMustTailThunkENS_10GlobalDeclEPN4llvm5ValueENS3_14FunctionCalleeE+0x540)[0x7f502720d700] /usr/lib/x86_64-linux-gnu/libclang-cpp.so.10(_ZN5clang7CodeGen15CodeGenFunction13generateThunkEPN4llvm8FunctionERKNS0_14CGFunctionInfoENS_10GlobalDeclERKNS_9ThunkInfoEb+0xdc)[0x7f502720d80c] /usr/lib/x86_64-linux-gnu/libclang-cpp.so.10(_ZN5clang7CodeGen14CodeGenVTables14maybeEmitThunkENS_10GlobalDeclERKNS_9ThunkInfoEb+0x46e)[0x7f502720dc9e] /usr/lib/x86_64-linux-gnu/libclang-cpp.so.10(_ZN5clang7CodeGen14CodeGenVTables10EmitThunksENS_10GlobalDeclE+0x74)[0x7f502720ded4] /usr/lib/x86_64-linux-gnu/libclang-cpp.so.10(_ZN5clang7CodeGen13CodeGenModule20EmitGlobalDefinitionENS_10GlobalDeclEPN4llvm11GlobalValueE+0x209)[0x7f5027231ec9] /usr/lib/x86_64-linux-gnu/libclang-cpp.so.10(_ZN5clang7CodeGen13CodeGenModule16EmitTopLevelDeclEPNS_4DeclE+0x62)[0x7f502723a662] /usr/lib/x86_64-linux-gnu/libclang-cpp.so.10(_ZN5clang7CodeGen13CodeGenModule15EmitDeclContextEPKNS_11DeclContextE+0x2b)[0x7f502723d8eb] /usr/lib/x86_64-linux-gnu/libclang-cpp.so.10(+0x16f9dbf)[0x7f50272a9dbf] /usr/lib/x86_64-linux-gnu/libclang-cpp.so.10(+0x16679c2)[0x7f50272179c2] /usr/lib/x86_64-linux-gnu/libclang-cpp.so.10(_ZN5clang8ParseASTERNS_4SemaEbb+0x214)[0x7f5026405ba4] /usr/lib/x86_64-linux-gnu/libclang-cpp.so.10(_ZN5clang14FrontendAction7ExecuteEv+0x48)[0x7f502787be58] /usr/lib/x86_64-linux-gnu/libclang-cpp.so.10(_ZN5clang16CompilerInstance13ExecuteActionERNS_14FrontendActionE+0x621)[0x7f50278348a1] /usr/lib/x86_64-linux-gnu/libclang-cpp.so.10(_ZN5clang25ExecuteCompilerInvocationEPNS_16CompilerInstanceE+0x66f)[0x7f50278dfdaf] /usr/bin/clang++(_Z8cc1_mainN4llvm8ArrayRefIPKcEES2_Pv+0x98d)[0x41229d] /usr/bin/clang++[0x4105b1] /usr/lib/x86_64-linux-gnu/libclang-cpp.so.10(+0x19d58f2)[0x7f50275858f2] /usr/lib/x86_64-linux-gnu/libLLVM-10.so.1(_ZN4llvm20CrashRecoveryContext9RunSafelyENS_12function_refIFvvEEE+0xd7)[0x7f5021df2c67] /usr/lib/x86_64-linux-gnu/libclang-cpp.so.10(_ZNK5clang6driver10CC1Command7ExecuteEN4llvm8ArrayRefINS2_8OptionalINS2_9StringRefEPNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEPb+0x13f)[0x7f5027584e2f] /usr/lib/x86_64-linux-gnu/libclang-cpp.so.10(_ZNK5clang6driver11Compilation14ExecuteCommandERKNS0_7CommandERPS3_+0x2df)[0x7f502755d52f] /usr/lib/x86_64-linux-gnu/libclang-cpp.so.10(_ZNK5clang6driver11Compilation11ExecuteJobsERKNS0_7JobListERN4llvm15SmallVectorImplISt4pairIiPKNS0_7Command+0x7a)[0x7f502755d6da] /usr/lib/x86_64-linux-gnu/libclang-cpp.so.10(_ZN5clang6driver6Driver18ExecuteCom
[llvm-bugs] [Bug 48533] New: builtin longjmp miscompiled when jmpbuf is rbp-relative address
https://bugs.llvm.org/show_bug.cgi?id=48533 Bug ID: 48533 Summary: builtin longjmp miscompiled when jmpbuf is rbp-relative address Product: new-bugs Version: 10.0 Hardware: PC OS: FreeBSD Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: j...@mit.edu CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org Created attachment 24293 --> https://bugs.llvm.org/attachment.cgi?id=24293&action=edit bitcode that llc miscompiles If the address argument to __builtin_longjmp is %rbp-relative the longjmp is miscompiled. If I compile the attached .ll file with the 10.0 llc the function ends movq-48(%rbp), %rbp movq-40(%rbp), %rax # This load needs the original rbp movq-32(%rbp), %rsp # This load needs the original rbp jmpq*%rax Note that the first instruction overwrites %rbp but the next two instructions depend on the old value. The branch goes to a random address with a random %rsp. The same bug is present in the version of llvm 11 included with FreeBSD-CURRENT (13.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 28198 in oss-fuzz: llvm:clang-fuzzer: Stack-overflow in DiagnoseTwoPhaseLookup
Updates: Status: WontFix Comment #2 on issue 28198 by ClusterFuzz-External: llvm:clang-fuzzer: Stack-overflow in DiagnoseTwoPhaseLookup https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=28198#c2 ClusterFuzz testcase 5699236515282944 is flaky and no longer crashes, so closing issue. 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 28198 in oss-fuzz: llvm:clang-fuzzer: Stack-overflow in DiagnoseTwoPhaseLookup
Comment #3 on issue 28198 by ClusterFuzz-External: llvm:clang-fuzzer: Stack-overflow in DiagnoseTwoPhaseLookup https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=28198#c3 ClusterFuzz testcase 5699236515282944 is closed as invalid, so closing issue. -- 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 28138 in oss-fuzz: llvm:clang-fuzzer: Stack-overflow in clang::Decl::castFromDeclContext
Updates: Status: WontFix Comment #2 on issue 28138 by ClusterFuzz-External: llvm:clang-fuzzer: Stack-overflow in clang::Decl::castFromDeclContext https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=28138#c2 ClusterFuzz testcase 5719153721475072 is flaky and no longer crashes, so closing issue. 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 28138 in oss-fuzz: llvm:clang-fuzzer: Stack-overflow in clang::Decl::castFromDeclContext
Comment #3 on issue 28138 by ClusterFuzz-External: llvm:clang-fuzzer: Stack-overflow in clang::Decl::castFromDeclContext https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=28138#c3 ClusterFuzz testcase 5719153721475072 is closed as invalid, so closing issue. -- 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 48437] [flang] Flang can't evaluate constant arrays with lower bounds <= 0
https://bugs.llvm.org/show_bug.cgi?id=48437 Peter Klausler changed: What|Removed |Added Fixed By Commit(s)||07751310580fa5b7b94b6efa85d ||7964af0f699a6 Status|NEW |RESOLVED CC||pklaus...@nvidia.com 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 48357] Crash when linking arm64 Linux kernel with --emit-relocs
https://bugs.llvm.org/show_bug.cgi?id=48357 Fangrui Song changed: What|Removed |Added Status|CONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Fangrui Song --- Fixed by 16cb7910f51f0c2570b1f3406bcd8d4069e52a3e (target: 12.0.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 25917 in oss-fuzz: llvm:clangd-fuzzer: Abrt in llvm::Expected::fatalUncheckedExpected
Updates: Labels: Deadline-Approaching Comment #1 on issue 25917 by sheriffbot: llvm:clangd-fuzzer: Abrt in llvm::Expected::fatalUncheckedExpected https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=25917#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] [Bug 48517] Accidental equality of classes templated by pointer to local static constant of templated function
https://bugs.llvm.org/show_bug.cgi?id=48517 Richard Smith changed: What|Removed |Added Fixed By Commit(s)||6b760a50f52142e401a6380ff71 ||f933cda22a909 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] Issue 28725 in oss-fuzz: llvm:llvm-isel-fuzzer--x86_64-O2: Out-of-memory in llvm-isel-fuzzer--x86_64-O2
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-2020-12-16 Type: Bug New issue 28725 by ClusterFuzz-External: llvm:llvm-isel-fuzzer--x86_64-O2: Out-of-memory in llvm-isel-fuzzer--x86_64-O2 https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=28725 Detailed Report: https://oss-fuzz.com/testcase?key=5140404353761280 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: llvm-isel-fuzzer--x86_64-O2 Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Out-of-memory (exceeds 2560 MB) Crash Address: Crash State: llvm-isel-fuzzer--x86_64-O2 Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202005010248:202005020247 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5140404353761280 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 48535] New: clang-format Incorrectly Removes Space After C Style Cast When Type Is Not a Pointer
https://bugs.llvm.org/show_bug.cgi?id=48535 Bug ID: 48535 Summary: clang-format Incorrectly Removes Space After C Style Cast When Type Is Not a Pointer Product: new-bugs Version: 11.0 Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: gavin.d.how...@gmail.com CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org Created attachment 24295 --> https://bugs.llvm.org/attachment.cgi?id=24295&action=edit Style file When I set the option "SpaceAfterCStyleCast" to true, clang-format will remove a space after a C-style cast when the type inside the cast parentheses is not a pointer time. You can reproduce this by using the attached style file on https://git.yzena.com/Yzena/Yc/src/branch/master/tests/fs/fs_read.c, lines 69 and 107. If I add an asterisk after the size_t inside the parens, the space is left. I speculate that clang-format incorrectly thinks that both sets of parens are calls, i.e., that the first set is a call to a function that returns a function pointer and that the second set is a call to that supposed returned function pointer. -- 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 48536] New: ld64.lld.darwinnew exports too many symbols
https://bugs.llvm.org/show_bug.cgi?id=48536 Bug ID: 48536 Summary: ld64.lld.darwinnew exports too many symbols Product: lld Version: unspecified Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: MachO Assignee: unassignedb...@nondot.org Reporter: nicolaswe...@gmx.de CC: llvm-bugs@lists.llvm.org Get this repro file: https://drive.google.com/file/d/1_QaShjqjIACu-jMZZUB4e2wfZVziB7Ds/view?usp=sharing When linking with ld64: % nm -gUm Chromium\ Framework 3b00 (__TEXT,__text) external _ChromeAppModeStart_v6 4880 (__TEXT,__text) external _ChromeMain 0a2824b8 (__DATA,__objc_data) external _OBJC_CLASS_$_RTCDispatcher 0a282508 (__DATA,__objc_data) external _OBJC_CLASS_$_RTCEncodedImage 0a282530 (__DATA,__objc_data) external _OBJC_CLASS_$_RTCVideoCapturer 0a282580 (__DATA,__objc_data) external _OBJC_CLASS_$_RTCVideoCodecInfo 0a2825d0 (__DATA,__objc_data) external _OBJC_CLASS_$_RTCVideoEncoderQpThresholds 0a282648 (__DATA,__objc_data) external _OBJC_CLASS_$_RTCVideoEncoderSettings 0a282670 (__DATA,__objc_data) external _OBJC_CLASS_$_RTCVideoFrame 0a282490 (__DATA,__objc_data) external _OBJC_METACLASS_$_RTCDispatcher 0a2824e0 (__DATA,__objc_data) external _OBJC_METACLASS_$_RTCEncodedImage 0a282558 (__DATA,__objc_data) external _OBJC_METACLASS_$_RTCVideoCapturer 0a2825a8 (__DATA,__objc_data) external _OBJC_METACLASS_$_RTCVideoCodecInfo 0a2825f8 (__DATA,__objc_data) external _OBJC_METACLASS_$_RTCVideoEncoderQpThresholds 0a282620 (__DATA,__objc_data) external _OBJC_METACLASS_$_RTCVideoEncoderSettings 0a282698 (__DATA,__objc_data) external _OBJC_METACLASS_$_RTCVideoFrame (And the objc exports are unintentional, https://bugs.chromium.org/p/chromium/issues/detail?id=1159620 -- but that's our fault and not ld64's fault). With lld: % nm -gUm Chromium\ Framework | wc -l 797022 Looks like hidden visibility just isn't implemented at all maybe. Or maybe it's just not set in the symbol table, which is what nm looks at (and our script for checking this in chromium uses nm). -- 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 48534] Invalid nullptr diagnostic
https://bugs.llvm.org/show_bug.cgi?id=48534 Nathan James changed: What|Removed |Added Assignee|unassignedclangbugs@nondot. |dcough...@apple.com |org | CC||dcough...@apple.com, ||llvm-bugs@lists.llvm.org, ||n.jame...@hotmail.co.uk Product|clang-tools-extra |clang Component|clang-tidy |Static Analyzer --- Comment #1 from Nathan James --- Moving to Static-analyzer bugs -- 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 48264] llvm-cov: wrong code coverage for statements before fork()
https://bugs.llvm.org/show_bug.cgi?id=48264 David Blaikie changed: What|Removed |Added CC||dblai...@gmail.com Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #1 from David Blaikie --- That sounds correct to me - the program forked, so two processes reached those two lines. lldb probably only follows one of those processes. Try adding a printf/output between line 9 and 10, and you'll see it prints out twice. -- 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 48537] New: clang-format Thinks Minus Is Negative
https://bugs.llvm.org/show_bug.cgi?id=48537 Bug ID: 48537 Summary: clang-format Thinks Minus Is Negative Product: new-bugs Version: 11.0 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: gavin.d.how...@gmail.com CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org Created attachment 24298 --> https://bugs.llvm.org/attachment.cgi?id=24298&action=edit Style file clang-format can be tricked into thinking that a minus operator is a unary negative operator. Using the attached style file, run clang-format on https://git.yzena.com/Yzena/Yc/src/commit/dadbb62db6023b532bf0bbe7d73303950710937f/src/map/map.h . The spaces after the minus operators on lines 114 and 143 are 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 28731 in oss-fuzz: llvm:llvm-opt-fuzzer--x86_64-instcombine: ASSERT: isa(Val) && "cast() argument of incompatible type!"
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-2020-12-17 Type: Bug New issue 28731 by ClusterFuzz-External: llvm:llvm-opt-fuzzer--x86_64-instcombine: ASSERT: isa(Val) && "cast() argument of incompatible type!" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=28731 Detailed Report: https://oss-fuzz.com/testcase?key=5119105803878400 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: llvm-opt-fuzzer--x86_64-instcombine Job Type: libfuzzer_msan_llvm Platform Id: linux Crash Type: ASSERT Crash Address: Crash State: isa(Val) && "cast() argument of incompatible type!" llvm::InstCombinerImpl::foldGEPICmp llvm::InstCombinerImpl::visitICmpInst Sanitizer: memory (MSAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_msan_llvm&range=202008310616:202009010628 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5119105803878400 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 48264] llvm-cov: wrong code coverage for statements before fork()
https://bugs.llvm.org/show_bug.cgi?id=48264 David Blaikie changed: What|Removed |Added Resolution|INVALID |--- Status|RESOLVED|REOPENED --- Comment #5 from David Blaikie --- (In reply to Yibiao Yang from comment #4) > (In reply to David Blaikie from comment #3) > > (In reply to Yibiao Yang from comment #2) > > > (In reply to David Blaikie from comment #1) > > > > That sounds correct to me - the program forked, so two processes reached > > > > those two lines. lldb probably only follows one of those processes. > > > > > > > > Try adding a printf/output between line 9 and 10, and you'll see it > > > > prints > > > > out twice. > > > > > > Thank you very much. Yes, it is indeed fork. So there is no problem as > > > Line > > > 9 and Line 10 are marked as executed twice. > > > > > > But for Line 3 and Line 4, I was wondering that they should marked as only > > > executed once since calling to fork is at Line 9. Only at that time, there > > > are two processes. > > > > That's how fork works - a single process runs until fork is called, then > > that process is cloned into two that continue from the fork call. > > https://man7.org/linux/man-pages/man2/fork.2.html > > From this point of view, it also make sense as these two lines are marked as > executed twice. Gcov behaves differently. I think both are correct. Thank > you very much. Sorry, misunderstood your comment and I didn't look at the text closely. Yeah, it is noteworthy that the early statements show as executed twice - when they certainly were not. (the fork only executes statements after it twice). I'd guess LLVM kept the counts in memory/registers that were duplicated when the process forked, then both sets of values were added to the counts. That does seem questionable, and gcc/gcov seems more accurate 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
