[llvm-bugs] [Bug 41808] New: -save-temps flag does not work
https://bugs.llvm.org/show_bug.cgi?id=41808 Bug ID: 41808 Summary: -save-temps flag does not work Product: clang Version: 8.0 Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Driver Assignee: unassignedclangb...@nondot.org Reporter: pmatos@linki.tools CC: llvm-bugs@lists.llvm.org, neeil...@live.com, richard-l...@metafoo.co.uk In the clang --help output you can see: -save-temps= Save intermediate compilation results. -save-temps Save intermediate compilation results But when you try to use -save-temps (without the =) error: unknown argument '-save-temps', did you mean '-save-temps='? -- 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 31984] -frewrite-includes incorrectly removes header
https://bugs.llvm.org/show_bug.cgi?id=31984 Arvid Gerstmann changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #1 from Arvid Gerstmann --- Fixed in newer clang versions. -- 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 41786] X86WinAllocaExpander::lower - Value stored to 'AmountReg' is never read
https://bugs.llvm.org/show_bug.cgi?id=41786 Hans Wennborg changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #4 from Hans Wennborg --- r360320. Thanks again Simon for looking at the scan-build output. -- 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 41809] New: z3 fatal error while analyzing webkit
https://bugs.llvm.org/show_bug.cgi?id=41809 Bug ID: 41809 Summary: z3 fatal error while analyzing webkit Product: clang Version: 8.0 Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: C++ Assignee: unassignedclangb...@nondot.org Reporter: pmatos@linki.tools CC: blitzrak...@gmail.com, dgre...@apple.com, erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk During a WebKit (https://webkit.org/) scan-build analysis (8x branch with -analyzer-config crosscheck-with-z3=true) I get the following: $ /home/pmatos/installs/bin/clang-8 -cc1 -triple x86_64-unknown-linux-gnu -analyze -disable-free -disable-llvm-verifier -discard-value-names -main-file-name UnifiedSource-3a3c4ec0-1.cpp -analyzer-store=region -analyzer-opt-analyze-nested-blocks -analyzer-checker=core -analyzer-checker=apiModeling -analyzer-checker=unix -analyzer-checker=deadcode -analyzer-checker=cplusplus -analyzer-checker=security.insecureAPI.UncheckedReturn -analyzer-checker=security.insecureAPI.getpw -analyzer-checker=security.insecureAPI.gets -analyzer-checker=security.insecureAPI.mktemp -analyzer-checker=security.insecureAPI.mkstemp -analyzer-checker=security.insecureAPI.vfork -analyzer-checker=nullability.NullPassedToNonnull -analyzer-checker=nullability.NullReturnedFromNonnull -analyzer-output plist -w -analyzer-config-compatibility-mode=true -mrelocation-model pic -pic-level 2 -mthread-model posix -relaxed-aliasing -fmath-errno -ffp-contract=off -masm-verbose -mconstructor-aliases -munwind-tables -fuse-init-array -target-cpu x86-64 -dwarf-column-info -debugger-tuning=gdb -momit-leaf-frame-pointer -resource-dir /home/pmatos/installs/lib/clang/8.0.1 -D BUILDING_JSCONLY__ -D BUILDING_JavaScriptCore -D BUILDING_WITH_CMAKE=1 -D HAVE_CONFIG_H=1 -D JavaScriptCore_EXPORTS -D STATICALLY_LINKED_WITH_WTF -I DerivedSources/ForwardingHeaders -I . -I ../Source/JavaScriptCore -I ../Source/JavaScriptCore/API -I ../Source/JavaScriptCore/assembler -I ../Source/JavaScriptCore/b3 -I ../Source/JavaScriptCore/b3/air -I ../Source/JavaScriptCore/bindings -I ../Source/JavaScriptCore/builtins -I ../Source/JavaScriptCore/bytecode -I ../Source/JavaScriptCore/bytecompiler -I ../Source/JavaScriptCore/dfg -I ../Source/JavaScriptCore/disassembler -I ../Source/JavaScriptCore/disassembler/ARM64 -I ../Source/JavaScriptCore/disassembler/udis86 -I ../Source/JavaScriptCore/domjit -I ../Source/JavaScriptCore/ftl -I ../Source/JavaScriptCore/heap -I ../Source/JavaScriptCore/debugger -I ../Source/JavaScriptCore/inspector -I ../Source/JavaScriptCore/inspector/agents -I ../Source/JavaScriptCore/inspector/augmentable -I ../Source/JavaScriptCore/inspector/remote -I ../Source/JavaScriptCore/interpreter -I ../Source/JavaScriptCore/jit -I ../Source/JavaScriptCore/llint -I ../Source/JavaScriptCore/parser -I ../Source/JavaScriptCore/profiler -I ../Source/JavaScriptCore/runtime -I ../Source/JavaScriptCore/tools -I ../Source/JavaScriptCore/wasm -I ../Source/JavaScriptCore/wasm/js -I ../Source/JavaScriptCore/yarr -I DerivedSources/JavaScriptCore -I DerivedSources/JavaScriptCore/inspector -I DerivedSources/JavaScriptCore/runtime -I DerivedSources/JavaScriptCore/yarr -I ../Source/bmalloc -I DerivedSources -I ../Source/ThirdParty -D NDEBUG -internal-isystem /usr/lib/gcc/x86_64-linux-gnu/7.4.0/../../../../include/c++/7.4.0 -internal-isystem /usr/lib/gcc/x86_64-linux-gnu/7.4.0/../../../../include/x86_64-linux-gnu/c++/7.4.0 -internal-isystem /usr/lib/gcc/x86_64-linux-gnu/7.4.0/../../../../include/x86_64-linux-gnu/c++/7.4.0 -internal-isystem /usr/lib/gcc/x86_64-linux-gnu/7.4.0/../../../../include/c++/7.4.0/backward -internal-isystem /usr/local/include -internal-isystem /home/pmatos/installs/lib/clang/8.0.1/include -internal-externc-isystem /usr/include/x86_64-linux-gnu -internal-externc-isystem /include -internal-externc-isystem /usr/include -O3 -Wno-expansion-to-defined -Wno-attributes -Wno-psabi -Wno-noexcept-type -Wno-maybe-uninitialized -std=c++17 -fdeprecated-macro -fdebug-compilation-dir /home/pmatos/Projects/Igalia/WebKit/WebKitBuild -ferror-limit 19 -fmessage-length 0 -fno-rtti -fobjc-runtime=gcc -fdiagnostics-show-option -fcolor-diagnostics -vectorize-loops -vectorize-slp -analyzer-output=html -analyzer-config crosscheck-with-z3=true -o /home/pmatos/Projects/Igalia/WebKit/WebKitBuild/build-analysis_z3/scan-build-2019-05-09-09-46-21-907905-qrljzo0e -x c++ /home/pmatos/Projects/Igalia/WebKit/WebKitBuild/DerivedSources/JavaScriptCore/unified-sources/UnifiedSource-3a3c4ec0-1.cpp -faddrsig fatal error: error in backend: Z3 error: rm and float sorts expected UnifiedSource-3a3c4ec0-1.cpp contains only: #include "jit/AssemblyHelpers.cpp" #include "jit/BinarySwitch.cpp" #include "jit/CCallHelpers.cpp" #include "jit/CachedRecovery.cpp" #include "jit/CallFrameShu
[llvm-bugs] [Bug 41808] -save-temps flag does not work
https://bugs.llvm.org/show_bug.cgi?id=41808 Tim Northover changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #3 from Tim Northover --- OK, "clang -cc1" takes different options from the Clang driver by design then. It even has a separate help list ("clang -cc1 -help") which doesn't include the bare -save-temps option. So I think this is all behaving as intended. -- 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 10250 in oss-fuzz: llvm: Build failure
Comment #54 on issue 10250 by ClusterFuzz-External: llvm: Build failure https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=10250#c54 Friendly reminder that the the build is still failing. Please try to fix this failure to ensure that fuzzing remains productive. Latest build log: https://oss-fuzz-build-logs.storage.googleapis.com/log-2fb7a43f-e021-43e9-a9cc-60e443ef6849.txt -- 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 41810] New: Exception causes double-free of lambda capture
https://bugs.llvm.org/show_bug.cgi?id=41810 Bug ID: 41810 Summary: Exception causes double-free of lambda capture Product: clang Version: 8.0 Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: lasse.reinh...@man-es.com CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org, neeil...@live.com, richard-l...@metafoo.co.uk Following program will double-free the str object. Run with tsan or valgrind #include template void execute(F) { throw std::runtime_error(""); } int main() { std::string str{ "" }; try { execute([str]() {}); } catch (...) { } } me@ubuntu:~/clang8/telemetry/test/telemetry_data_test$ clang++ -stdlib=libc++ -pthread -std=c++17 /mnt/hgfs/F/map/ConsoleApplication1/ConsoleApplication1/ConsoleApplication1.cpp me@ubuntu:~/clang8/telemetry/test/telemetry_data_test$ valgrind ./a.out ==84029== Memcheck, a memory error detector ==84029== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==84029== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info ==84029== Command: ./a.out ==84029== ==84029== Invalid free() / delete / delete[] / realloc() ==84029==at 0x4C30F78: free (vg_replace_malloc.c:530) ==84029==by 0x400BC1: main (in /home/me/clang8/telemetry/test/telemetry_data_test/a.out) ==84029== Address 0x60fb0b0 is 0 bytes inside a block of size 48 free'd ==84029==at 0x4C30F78: free (vg_replace_malloc.c:530) ==84029==by 0x400C94: main::$_0::~$_0() (in /home/me/clang8/telemetry/test/telemetry_data_test/a.out) ==84029==by 0x400BB8: main (in /home/me/clang8/telemetry/test/telemetry_data_test/a.out) ==84029== Block was alloc'd at ==84029==at 0x4C2FDCB: malloc (vg_replace_malloc.c:299) ==84029==by 0x4EC4834: operator new(unsigned long) (in /usr/local/clang_8.0.0/lib/libc++.so.1.0) ==84029==by 0x4EC57F2: std::__1::basic_string, std::__1::allocator >::basic_string(std::__1::basic_string, std::__1::allocator > const&) (in /usr/local/clang_8.0.0/lib/libc++.so.1.0) ==84029==by 0x400B77: main (in /home/me/clang8/telemetry/test/telemetry_data_test/a.out) ==84029== ==84029== ==84029== HEAP SUMMARY: ==84029== in use at exit: 16 bytes in 1 blocks ==84029== total heap usage: 5 allocs, 5 frees, 281 bytes allocated ==84029== ==84029== LEAK SUMMARY: ==84029==definitely lost: 0 bytes in 0 blocks ==84029==indirectly lost: 0 bytes in 0 blocks ==84029== possibly lost: 0 bytes in 0 blocks ==84029==still reachable: 16 bytes in 1 blocks ==84029== suppressed: 0 bytes in 0 blocks ==84029== Rerun with --leak-check=full to see details of leaked memory ==84029== ==84029== For counts of detected and suppressed errors, rerun with: -v ==84029== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0) me@ubuntu:~/clang8/telemetry/test/telemetry_data_test$ me@ubuntu:~/clang8/telemetry/test/telemetry_data_test$ clang++ --version clang version 8.0.0 (tags/RELEASE_800/final) Target: x86_64-unknown-linux-gnu Thread model: posix InstalledDir: /usr/local/clang_8.0.0/bin -- 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 41811] New: Merge r360293 into the 8.0 branch : AMDGPU: Select VOP3 form of add
https://bugs.llvm.org/show_bug.cgi?id=41811 Bug ID: 41811 Summary: Merge r360293 into the 8.0 branch : AMDGPU: Select VOP3 form of add Product: new-bugs Version: 8.0 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: matthew.arsena...@amd.com CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org Blocks: 41221 Is it OK to merge the following revision(s) to the 8.0 branch? Referenced Bugs: https://bugs.llvm.org/show_bug.cgi?id=41221 [Bug 41221] [meta] 8.0.1 Release Blockers -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 41768] OpenMP default(none) - std::cerr is not diagnosed as "not specified in enclosing 'parallel'", unlike GCC
https://bugs.llvm.org/show_bug.cgi?id=41768 Roman Lebedev changed: What|Removed |Added CC||jdoerf...@anl.gov Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #1 from Roman Lebedev --- ... and i had to revert this & the other commit. Sorry :( This has introduced (exposed?) a crash in clang sema. The reduced testcase is A Mess, but this is what clang/utils/creduce-clang-crash.py gave me :/ I've included the original clang reproducer .cpp + .sh in tarball. struct a { constexpr int b = ; } template < bool > struct c template < typename d, typename e > bool operator<( d, e ; class f { int cbegin } class g { f blocks } template < typename > struct is_error_code_enum : a struct h { template < typename i, typename = c< is_error_condition_enum< i >::b >> h(i } operator<( h , h ; g:j() { #pragma omp parallel for default(none) for (auto a = blocks.cbegin0; a < blocks; ++a) ; ./bin/clang++ -fopenmp results in clang-9: /build/llvm/include/llvm/Support/Casting.h:264: typename llvm::cast_retty::ret_type llvm::cast(Y*) [with X = clang::sema::CapturingScopeInfo; Y = clang::sema::FunctionScopeInfo; typename llvm::cast_retty::ret_type = clang::sema::CapturingScopeInfo* ]: Assertion `isa(Val) && "cast() argument of incompatible type!"' failed. Stack dump: 0. Program arguments: /build/llvm-build-GCC-release/bin/clang-9 -cc1 -triple x86_64-unknown-linux-gnu -emit-obj -mrelax-all -disable-free -main-file-name PanasonicDecompressorV5-58eb88.reduced.cpp -mrelocation-model static -mthread-model posix -mdisable-fp-elim -fma th-errno -masm-verbose -mconstructor-aliases -munwind-tables -fuse-init-array -target-cpu x86-64 -dwarf-column-info -debugger-tuning=gdb -resource-dir /build/llvm-build-GCC-release/lib/clang/9.0.0 -internal-isystem /usr/lib64/gcc/x86_64-linux-gnu/8/../../../../include/c+ +/8 -internal-isystem /usr/lib64/gcc/x86_64-linux-gnu/8/../../../../include/x86_64-linux-gnu/c++/8 -internal-isystem /usr/lib64/gcc/x86_64-linux-gnu/8/../../../../include/x86_64-linux-gnu/c++/8 -internal-isystem /usr/lib64/gcc/x86_64-linux-gnu/8/../../../../include/c++/8 /backward -internal-isystem /usr/local/include -internal-isystem /build/llvm-build-GCC-release/lib/clang/9.0.0/include -internal-externc-isystem /usr/include/x86_64-linux-gnu -internal-externc-isystem /include -internal-externc-isystem /usr/include -fdeprecated-macro -fd ebug-compilation-dir /tmp -ferror-limit 19 -fmessage-length 271 -fopenmp -fobjc-runtime=gcc -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/PanasonicDecompressorV5-58eb88-43484c.o -x c++ PanasonicDecompressorV5-58eb88.reduced.cpp -fadd rsig 1. parser at end of file 2. PanasonicDecompressorV5-58eb88.reduced.cpp:23:9: parsing function body 'g::j' 3. PanasonicDecompressorV5-58eb88.reduced.cpp:23:9: in compound statement ('{}') #0 0x7fe89bdec96a llvm::sys::PrintStackTrace(llvm::raw_ostream&) /build/llvm/lib/Support/Unix/Signals.inc:494:22 #1 0x7fe89bdea744 llvm::sys::RunSignalHandlers() /build/llvm/lib/Support/Signals.cpp:68:20 #2 0x7fe89bdea8a5 SignalHandler(int) /build/llvm/lib/Support/Unix/Signals.inc:357:1 #3 0x7fe89b85a730 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x12730) #4 0x7fe89a3177bb raise (/lib/x86_64-linux-gnu/libc.so.6+0x377bb) #5 0x7fe89a302535 abort (/lib/x86_64-linux-gnu/libc.so.6+0x22535) #6 0x7fe89a30240f (/lib/x86_64-linux-gnu/libc.so.6+0x2240f) #7 0x7fe89a310102 (/lib/x86_64-linux-gnu/libc.so.6+0x30102) #8 0x7fe8988faa86 llvm::SmallVectorTemplateCommon::operator[](unsigned long) /build/llvm/include/llvm/ADT/SmallVector.h:149:5 #9 0x7fe8988faa86 clang::Sema::tryCaptureVariable(clang::VarDecl*, clang::SourceLocation, clang::Sema::TryCaptureKind, clang::SourceLocation, bool, clang::QualType&, clang::QualType&, unsigned int const*) /build/clang/lib/Sema/SemaExpr.cpp:15512:65 #10 0x7fe8988fae01 clang::Sema::getCapturedDeclRefType(clang::VarDecl*, clang::SourceLocation) /build/clang/lib/Sema/SemaExpr.cpp:15665:3 #11 0x7fe8988fc607 clang::Sema::BuildDeclarationNameExpr(clang::CXXScopeSpec const&, clang::DeclarationNameInfo const&, clang::NamedDecl*, clang::NamedDecl*, clang::TemplateArgumentListInfo const*, bool) /build/clang/lib/Sema/SemaExpr.cpp:3060:9 #12 0x7fe8988fcafb clang::Sema::BuildDeclarationNameExpr(clang::CXXScopeSpec const&, clang::LookupResult&, bool, bool) /build/clang/lib/Sema/SemaExpr.cpp:2891:54 #13 0x7fe8989a5b39 clang::Sema::BuildPossibleImplicitMemberExpr(clang::CXXScopeSpec const&, clang::SourceLocation, clang::LookupResult&, clang::TemplateArgumentListInfo const*, clang::Scope const*) /build/clang/lib/Sema/SemaExprMember.cpp:260:49 #14 0
[llvm-bugs] [Bug 41767] OpenMP default(none) + schedule(dynamic, variable) - difference with gcc
https://bugs.llvm.org/show_bug.cgi?id=41767 Roman Lebedev changed: What|Removed |Added CC||jdoerf...@anl.gov Status|RESOLVED|REOPENED See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=90406 Resolution|FIXED |--- --- Comment #3 from Roman Lebedev --- ... and i had to revert this & the other commit. Sorry :( This implementation isn't sound as per the standard. It erroneously diagnoses e.g. the following case: ``` $ cat test.cpp void f(int n) { #pragma omp parallel default(none) if(n) ; } ``` ``` $ ./bin/clang -fopenmp test.cpp test.cpp:2:40: error: variable 'n' must have explicitly specified data sharing attributes #pragma omp parallel default(none) if(n) ^ test.cpp:2:31: note: explicit data sharing attribute requested here #pragma omp parallel default(none) if(n) ^ 1 error generated. ``` As per OpenMP Application Programming Interface Version 5.0 November 2018: * 2.19.4.1default Clause The default clause explicitly determines the data-sharing attributes of variables that are referenced *in a parallel, teams, or task generating construct and would otherwise be implicitly determined (see Section 2.19.1.1 on page 270). * 2.6.1 Determining the Number of Threads for a parallel Region Using a variable in an if or num_threads clause expression of a parallel construct causes an implicit reference to the variable in all enclosing constructs. The if clause expression and the num_threads clause expression are evaluated in the context outside of the parallel construct, -- 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 41464] Add -h as alias for --help
https://bugs.llvm.org/show_bug.cgi?id=41464 Fangrui Song changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED CC||i...@maskray.me -- 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 41812] New: Crash in CStringChecker
https://bugs.llvm.org/show_bug.cgi?id=41812 Bug ID: 41812 Summary: Crash in CStringChecker Product: clang Version: trunk Hardware: All OS: All Status: NEW Severity: release blocker Priority: P Component: Static Analyzer Assignee: dcough...@apple.com Reporter: adam.bal...@ericsson.com CC: dcough...@apple.com, llvm-bugs@lists.llvm.org Given the following faulty C code (the programmer forgot that taking address of an array is the same as the array itself which is handled as an address): ``` char dest[255], **dest_p = &dest; char src[255]; memcmp((const void*) *dest_p, (const void *) src, sizeof(dest)); ``` Analyzing this code with any C-String checker enabled results in an assertion failure: ``` clang: llvm/tools/clang/include/clang/StaticAnalyzer/Core/PathSensitive/SVals.h:104: T clang::ento::SVal::castAs() const [with T = clang::ento::DefinedOrUnknownSVal]: Assertion `T::isKind(*this)' failed. #0 0x7fa514b947dd llvm::sys::PrintStackTrace(llvm::raw_ostream&) llvm/lib/Support/Unix/Signals.inc:494:0 #1 0x7fa514b94870 PrintStackTraceSignalHandler(void*) llvm/lib/Support/Unix/Signals.inc:558:0 #2 0x7fa514b92870 llvm::sys::RunSignalHandlers() llvm/lib/Support/Signals.cpp:68:0 #3 0x7fa514b94230 SignalHandler(int) llvm/lib/Support/Unix/Signals.inc:357:0 #4 0x7fa510428f20 (/lib/x86_64-linux-gnu/libc.so.6+0x3ef20) #5 0x7fa510428e97 raise /build/glibc-OTsEL5/glibc-2.27/signal/../sysdeps/unix/sysv/linux/raise.c:51:0 #6 0x7fa51042a801 abort /build/glibc-OTsEL5/glibc-2.27/stdlib/abort.c:81:0 #7 0x7fa51041a39a __assert_fail_base /build/glibc-OTsEL5/glibc-2.27/assert/assert.c:89:0 #8 0x7fa51041a412 (/lib/x86_64-linux-gnu/libc.so.6+0x30412) #9 0x7fa503f28a6f clang::ento::DefinedOrUnknownSVal clang::ento::SVal::castAs() const llvm/tools/clang/include/clang/StaticAnalyzer/Core/PathSensitive/SVals.h:105:0 #10 0x7fa503f58630 (anonymous namespace)::CStringChecker::evalMemcmp(clang::ento::CheckerContext&, clang::CallExpr const*) const llvm/tools/clang/lib/StaticAnalyzer/Checkers/CStringChecker.cpp:1286:0 #11 0x7fa503f5e5cc (anonymous namespace)::CStringChecker::evalCall(clang::CallExpr const*, clang::ento::CheckerContext&) const llvm/tools/clang/lib/StaticAnalyzer/Checkers/CStringChecker.cpp:2354: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 41813] New: [X86] Improve HADD/HSUB shuffle combining
https://bugs.llvm.org/show_bug.cgi?id=41813 Bug ID: 41813 Summary: [X86] Improve HADD/HSUB shuffle combining Product: libraries Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: Backend: X86 Assignee: unassignedb...@nondot.org Reporter: llvm-...@redking.me.uk CC: craig.top...@gmail.com, llvm-bugs@lists.llvm.org, llvm-...@redking.me.uk, spatel+l...@rotateright.com As noted in https://reviews.llvm.org/D61308, we should try harder to combine shuffles on either side of a HADD/HSUB instruction - possibly removing it in the process. This may be true for PACK in some cases as well. define <4 x float> @PR22377(<4 x float> %a, <4 x float> %b) { ; AVX-LABEL: PR22377: ; AVX: # %bb.0: # %entry ; AVX-NEXT:vhaddps %xmm0, %xmm0, %xmm1 ; AVX-NEXT:vshufps {{.*#+}} xmm0 = xmm0[0,2],xmm1[0,1] ; AVX-NEXT:vpermilps {{.*#+}} xmm0 = xmm0[0,2,1,3] ; AVX-NEXT:retq entry: %s1 = shufflevector <4 x float> %a, <4 x float> undef, <4 x i32> %s2 = shufflevector <4 x float> %a, <4 x float> undef, <4 x i32> %r2 = fadd <4 x float> %s1, %s2 %s3 = shufflevector <4 x float> %s2, <4 x float> %r2, <4 x i32> ret <4 x float> %s3 } Under some circumstances we could even shuffle in +0.0f values into some lanes so the HADD becomes inert. -- 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 41814] New: Re-order functions instead of in-lining
https://bugs.llvm.org/show_bug.cgi?id=41814 Bug ID: 41814 Summary: Re-order functions instead of in-lining Product: new-bugs Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: sland...@gmail.com CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org I am reporting this here so that I might get some technical feed-back on how this will interact with ldd. There are many cases where function can be optimized by ordering them in a specific way. If a function is only called by a single other function in the same shared library, it should always be after the function that calls it. There are fancier optimizations possible too, such as having memmove be both before and after memcpy, split on the branch, or jumping into the middle of a function when they do identical calculations (the function merger could probably be adapted to help with this), but this bug is only for simple re-ordering (more bugs can be opened when this is 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 41815] New: Value tracking of undefined to remove branches.
https://bugs.llvm.org/show_bug.cgi?id=41815 Bug ID: 41815 Summary: Value tracking of undefined to remove branches. Product: new-bugs Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: sland...@gmail.com CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org The following code does not need a branch, because uninitialized memory has undefined contents, and certainly shouldn't have one when the popcnt instruction is supported: struct get_sparse_ret { size_t index; bool godefault; }; struct get_sparse_ret __getsparse(size_t key, struct sparse_table_entry *map) { struct get_sparse_ret ret; if key * 64) / 64) * 64) * 16 > map[0].length) { ret.godefault = true; return ret; } ret = __getsparseinbounds(key, map); return ret; } I could put the if after the function call, but that wouldn't specify that I don't care about the first return value if the second return value is true (and C doesn't have an undefined I can set it to to communicate that). -- 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 14664 in oss-fuzz: llvm/llvm-dwarfdump-fuzzer: Abrt in llvm::llvm_unreachable_internal
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@gmail.com, mit...@google.com, bigchees...@gmail.com, eney...@google.com, llvm-b...@lists.llvm.org, j...@chromium.org, v...@apple.com, mitchphi...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer Proj-llvm Reported-2019-05-09 Type: Bug New issue 14664 by ClusterFuzz-External: llvm/llvm-dwarfdump-fuzzer: Abrt in llvm::llvm_unreachable_internal https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=14664 Detailed report: https://oss-fuzz.com/testcase?key=5698683162591232 Project: llvm Fuzzer: libFuzzer_llvm_llvm-dwarfdump-fuzzer Fuzz target binary: llvm-dwarfdump-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Abrt Crash Address: 0x0001 Crash State: llvm::llvm_unreachable_internal llvm::object::XCOFFObjectFile::isSectionVirtual llvm::DWARFContext::create Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201903270300:201904052014 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5698683162591232 Issue filed automatically. See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md 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. -- 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 13740 in oss-fuzz: llvm/clang-fuzzer: ASSERT: !T->isDependentType() && "should not see dependent types here"
Comment #2 on issue 13740 by ClusterFuzz-External: llvm/clang-fuzzer: ASSERT: !T->isDependentType() && "should not see dependent types here" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=13740#c2 ClusterFuzz has detected this issue as fixed in range 201905080309:201905090310. Detailed report: https://oss-fuzz.com/testcase?key=5637625144147968 Project: llvm Fuzzer: libFuzzer_llvm_clang-fuzzer Fuzz target binary: clang-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: ASSERT Crash Address: Crash State: !T->isDependentType() && "should not see dependent types here" clang::ASTContext::getTypeInfoImpl clang::ASTContext::getTypeInfo Sanitizer: address (ASAN) Fixed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201905080309:201905090310 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5637625144147968 See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md for instructions to reproduce this bug locally. If you suspect that the result above is incorrect, try re-doing that job on the test case report page. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 3979 in oss-fuzz: llvm/clang-fuzzer: ASSERT: !isNull() && "Cannot retrieve a NULL type pointer"
Comment #13 on issue 3979 by ClusterFuzz-External: llvm/clang-fuzzer: ASSERT: !isNull() && "Cannot retrieve a NULL type pointer" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=3979#c13 ClusterFuzz has detected this issue as fixed in range 201905080309:201905090310. Detailed report: https://oss-fuzz.com/testcase?key=4819978428612608 Project: llvm Fuzzer: libFuzzer_llvm_clang-fuzzer Fuzz target binary: clang-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: ASSERT Crash Address: Crash State: !isNull() && "Cannot retrieve a NULL type pointer" clang::Sema::ActOnCapScopeReturnStmt clang::Sema::BuildReturnStmt Sanitizer: address (ASAN) Fixed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201905080309:201905090310 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=4819978428612608 See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md for instructions to reproduce this bug locally. If you suspect that the result above is incorrect, try re-doing that job on the test case report page. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 41816] New: does not detect if a gcc installation is ONLY gcc and does not include g++
https://bugs.llvm.org/show_bug.cgi?id=41816 Bug ID: 41816 Summary: does not detect if a gcc installation is ONLY gcc and does not include g++ Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: sland...@gmail.com CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org, neeil...@live.com, richard-l...@metafoo.co.uk Installing gcc-9 package on Ubuntu (without g++-9) breaks clang, even if g++-8 is installed. (building llvm) ../include/llvm/Support/Compiler.h:19:10: fatal error: 'new' file not found #include ^ -- 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 41817] New: The linkage changes in r359260 break MIDL code
https://bugs.llvm.org/show_bug.cgi?id=41817 Bug ID: 41817 Summary: The linkage changes in r359260 break MIDL code Product: clang Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: dma...@mozilla.com CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org, neeil...@live.com, richard-l...@metafoo.co.uk The following code builds successfully with r359259 but not r359260: $ cat a.cpp extern const int x; static const int x = 3; const int* foo() { return &x; } $ cat b.cpp extern const int x; static const int x = 7; const int* bar() { return &x; } $ cat c.cpp const int* foo(); const int* bar(); int main(int argc, char**) { return argc ? *foo() : *bar(); } $ clang-cl -c a.cpp b.cpp c.cpp $ lld-link -nodefaultlib -entry:main a.obj b.obj c.obj lld-link: error: duplicate symbol: int const x in a.obj and in b.obj This pattern can be seen in code generated by MIDL, e.g. https://searchfox.org/mozilla-central/search?q=text%3AHandlerData__MIDL_ProcFormatString Since there are no templates involved here, I'm guessing this change in behavior was unintended? -- 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 3979 in oss-fuzz: llvm/clang-fuzzer: ASSERT: !isNull() && "Cannot retrieve a NULL type pointer"
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #14 on issue 3979 by ClusterFuzz-External: llvm/clang-fuzzer: ASSERT: !isNull() && "Cannot retrieve a NULL type pointer" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=3979#c14 ClusterFuzz testcase 4819978428612608 is verified as fixed, so closing issue as verified. If this is incorrect, please file a bug on https://github.com/google/oss-fuzz/issues/new -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 13740 in oss-fuzz: llvm/clang-fuzzer: ASSERT: !T->isDependentType() && "should not see dependent types here"
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #3 on issue 13740 by ClusterFuzz-External: llvm/clang-fuzzer: ASSERT: !T->isDependentType() && "should not see dependent types here" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=13740#c3 ClusterFuzz testcase 5637625144147968 is verified as fixed, so closing issue as verified. If this is incorrect, please file a bug on https://github.com/google/oss-fuzz/issues/new -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 41000] PT_NOTE segment not packed correctly
https://bugs.llvm.org/show_bug.cgi?id=41000 Fangrui Song changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Fangrui Song --- Fixed by r359853 -- 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 41763] segment fault for plt
https://bugs.llvm.org/show_bug.cgi?id=41763 Fangrui Song changed: What|Removed |Added CC||i...@maskray.me Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #4 from Fangrui Song --- Fixed by D61586/r360187 -- 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 41818] New: Merge r355141 to 8.0.1
https://bugs.llvm.org/show_bug.cgi?id=41818 Bug ID: 41818 Summary: Merge r355141 to 8.0.1 Product: lld Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: COFF Assignee: unassignedb...@nondot.org Reporter: dma...@mozilla.com CC: llvm-bugs@lists.llvm.org Depends on: 39799 Blocks: 41221 r355141 (bug 39799) is a fix for Control Flow Guard that adds more addresses to the valid-targets table. Can we merge it into 8.0.1? Referenced Bugs: https://bugs.llvm.org/show_bug.cgi?id=39799 [Bug 39799] LLD's /GUARD:CF relocation scanning heuristic ignores address-taken import thunks https://bugs.llvm.org/show_bug.cgi?id=41221 [Bug 41221] [meta] 8.0.1 Release Blockers -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 13111 in oss-fuzz: llvm/clang-fuzzer: ASSERT: CanDeclareSpecialMemberFunction(RD) && "doing special member lookup into record
Updates: Labels: Deadline-Approaching Comment #2 on issue 13111 by sheriff...@chromium.org: llvm/clang-fuzzer: ASSERT: CanDeclareSpecialMemberFunction(RD) && "doing special member lookup into record https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=13111#c2 This bug is approaching its deadline for being fixed, and will be automatically derestricted within 7 days. If a fix is planned within 2 weeks after the deadline has passed, a grace extension can be granted. - Your friendly Sheriffbot -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 13112 in oss-fuzz: llvm/llvm-opt-fuzzer--x86_64-gvn: ASSERT: castIsValid(op, S, Ty) && "Invalid cast!"
Updates: Labels: Deadline-Approaching Comment #2 on issue 13112 by sheriff...@chromium.org: llvm/llvm-opt-fuzzer--x86_64-gvn: ASSERT: castIsValid(op, S, Ty) && "Invalid cast!" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=13112#c2 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 41523] [llvm-mca] Add support for nested and overlapping region markers
https://bugs.llvm.org/show_bug.cgi?id=41523 Andrea Di Biagio changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #1 from Andrea Di Biagio --- Fixed at revision 360351 http://llvm.org/viewvc/llvm-project?view=revision&revision=360351 -- 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 14667 in oss-fuzz: llvm/clang-fuzzer: ASSERT: ParmVarDeclBits.ScopeDepthOrObjCQuals == scopeDepth && "truncation!"
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@gmail.com, mit...@google.com, bigchees...@gmail.com, eney...@google.com, llvm-b...@lists.llvm.org, j...@chromium.org, v...@apple.com, mitchphi...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer Proj-llvm Reported-2019-05-09 Type: Bug New issue 14667 by ClusterFuzz-External: llvm/clang-fuzzer: ASSERT: ParmVarDeclBits.ScopeDepthOrObjCQuals == scopeDepth && "truncation!" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=14667 Detailed report: https://oss-fuzz.com/testcase?key=5693626727792640 Project: llvm Fuzzer: libFuzzer_llvm_clang-fuzzer Fuzz target binary: clang-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: ASSERT Crash Address: Crash State: ParmVarDeclBits.ScopeDepthOrObjCQuals == scopeDepth && "truncation!" clang::Sema::ActOnParamDeclarator clang::Parser::ParseParameterDeclarationClause Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201807260237:201807261853 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5693626727792640 Issue filed automatically. See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md 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. -- 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 41819] New: Bad diagnostic when trying to copy an uncopyable type
https://bugs.llvm.org/show_bug.cgi?id=41819 Bug ID: 41819 Summary: Bad diagnostic when trying to copy an uncopyable type Product: clang Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: C++ Assignee: unassignedclangb...@nondot.org Reporter: barry.rev...@gmail.com CC: blitzrak...@gmail.com, dgre...@apple.com, erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk Same issue as gcc's bug (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90413): template struct Bar { Bar() {} Bar(const Bar&) { static_assert(sizeof(T) == 1, ""); } }; template struct Foo { Foo() {} #ifdef DEFAULT Foo(const Foo&) = default; #else Foo(const Foo& o) : b(o.b) {} #endif Bar b; }; int main() { Foo f; Foo g = f; } Without -DDEFAULT, the error points to the offending line (you can see the construction of 'g' in the error trace): source>:5:9: error: static_assert failed due to requirement 'sizeof(int) == 1' "" static_assert(sizeof(T) == 1, ""); ^ ~~ :14:25: note: in instantiation of member function 'Bar::Bar' requested here Foo(const Foo& o) : b(o.b) {} ^ :21:18: note: in instantiation of member function 'Foo::Foo' requested here Foo g = f; ^ 1 error generated. Compiler returned: 1 With -DDEFAULT, the error does not point to the offending line at all: source>:5:9: error: static_assert failed due to requirement 'sizeof(int) == 1' "" static_assert(sizeof(T) == 1, ""); ^ ~~ :12:5: note: in instantiation of member function 'Bar::Bar' requested here Foo(const Foo&) = default; ^ 1 error generated. Compiler returned: 1 In larger examples, this makes it very hard to determine the actual source of problem -- since it doesn't even appear. -- 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 41820] New: Merge r356982 into the 8.0 branch : [llvm-dlltool] Set a proper machine type for weak symbol object files
https://bugs.llvm.org/show_bug.cgi?id=41820 Bug ID: 41820 Summary: Merge r356982 into the 8.0 branch : [llvm-dlltool] Set a proper machine type for weak symbol object files Product: new-bugs Version: 8.0 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: tstel...@redhat.com CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org Blocks: 41221 Is it OK to merge the following revision(s) to the 8.0 branch? Referenced Bugs: https://bugs.llvm.org/show_bug.cgi?id=41221 [Bug 41221] [meta] 8.0.1 Release Blockers -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 21874] Feature request: support #pragma GCC diagnostic ignored
https://bugs.llvm.org/show_bug.cgi?id=21874 Shawn Landden changed: What|Removed |Added Component|Static Analyzer |-New Bugs Status|NEW |RESOLVED CC||htmldevelo...@gmail.com, ||neeil...@live.com Resolution|--- |FIXED --- Comment #5 from Shawn Landden --- I had a spelling problem. This bug is 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 41821] New: [LLVM-COV] A "break; " statement is wrongly marked as executed when it is after the "abort(); " statement in switch-case
https://bugs.llvm.org/show_bug.cgi?id=41821 Bug ID: 41821 Summary: [LLVM-COV] A "break;" statement is wrongly marked as executed when it is after the "abort();" statement in switch-case Product: Runtime Libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: libprofile library Assignee: unassignedb...@nondot.org Reporter: yangyib...@nju.edu.cn CC: llvm-bugs@lists.llvm.org $ clang -v clang version 9.0.0-svn358899-1~exp1+0~20190422164136.937~1.gbpac4d8e (trunk) Target: x86_64-pc-linux-gnu Thread model: posix InstalledDir: /usr/bin Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.8 Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.8.5 Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/6 Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/6.5.0 Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/7 Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/7.4.0 Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/8 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8.5 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.4.0 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/8 Selected GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/7.4.0 Candidate multilib: .;@m64 Candidate multilib: 32;@m32 Candidate multilib: x32;@mx32 Selected multilib: .;@m64 $ rm a.out small.lcov small.p*; clang -w -O0 -g -fcoverage-mapping -fprofile-instr-generate=small.profraw small.c; ./a.out; llvm-profdata merge small.profraw -o small.profdata; llvm-cov show a.out -instr-profile=small.profdata small.c > small.lcov; cat small.lcov 1| |int main() 2| 1|{ 3| 1| switch (8) 4| 1| { 5| 1|case 8: 6| 1| break; 7| 1|default: 8| 0| abort (); 9| 1| break; 10| 1| } 11| 1| return 0; 12| 1|} Line #9 is wrongly marked as executed. In fact, it is obvious that Line #9 is not executed. When Line #8 is removed, the coverage is correct as follows: $ rm a.out small.lcov small.p*; clang -w -O0 -g -fcoverage-mapping -fprofile-instr-generate=small.profraw small.c; ./a.out; llvm-profdata merge small.profraw -o small.profdata; llvm-cov show a.out -instr-profile=small.profdata small.c > small.lcov; cat small.lcov 1| |int main() 2| 1|{ 3| 1| switch (8) 4| 1| { 5| 1|case 8: 6| 1| break; 7| 1|default: 8| 0| // abort (); 9| 0| break; 10| 1| } 11| 1| return 0; 12| 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 41768] OpenMP default(none) - std::cerr is not diagnosed as "not specified in enclosing 'parallel'", unlike GCC
https://bugs.llvm.org/show_bug.cgi?id=41768 Alexey Bataev changed: What|Removed |Added Fixed By Commit(s)|r360061 |r360061, r360362 Status|REOPENED|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 39920] [X86] Failure to use PHADDD on Intel CPUs on the second to last step of a v8i32 pairwise reduction
https://bugs.llvm.org/show_bug.cgi?id=39920 Simon Pilgrim changed: What|Removed |Added Status|NEW |RESOLVED Fixed By Commit(s)||r360360 Resolution|--- |FIXED --- Comment #4 from Simon Pilgrim --- Fixed in rL360360 -- 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 35784] [meta][x86] Scheduler Driven Optimizations
https://bugs.llvm.org/show_bug.cgi?id=35784 Bug 35784 depends on bug 39920, which changed state. Bug 39920 Summary: [X86] Failure to use PHADDD on Intel CPUs on the second to last step of a v8i32 pairwise reduction https://bugs.llvm.org/show_bug.cgi?id=39920 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 41822] New: vfork broken with -fno-builtin
https://bugs.llvm.org/show_bug.cgi?id=41822 Bug ID: 41822 Summary: vfork broken with -fno-builtin Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: LLVM Codegen Assignee: unassignedclangb...@nondot.org Reporter: eugeni.stepa...@gmail.com CC: llvm-bugs@lists.llvm.org, neeil...@live.com, richard-l...@metafoo.co.uk -fno-builtin removes returns_twice attribute from vfork. Unlike most other attributes, this one is required for correctness. Missing returns_twice allows the optimizer to use tail calls in the caller of vfork. Child process can not use a tail call, because that is effectively a return from the caller of vfork, and it corrupts the stack of the parent process. $ cat 1.cc #include __attribute__((optnone, noinline)) static void child() { volatile bool z = false; if (!z) _exit(0); } void zzztest() { if (!vfork()) { child(); } } $ bin/clang++ -target armv7-linux 1.cc -O2 -c -fno-builtin && objdump -drl 1.o _Z7zzztestv(): 0: e92d4800push{fp, lr} 4: e1a0b00dmov fp, sp 8: ebfebl 0 8: R_ARM_CALL vfork c: e350cmp r0, #0 10: 18bd8800popne {fp, pc} 14: e8bd4800pop {fp, lr} 18: eaffb 1c <_ZL5childv> -- 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 41767] OpenMP default(none) + schedule(dynamic, variable) - difference with gcc
https://bugs.llvm.org/show_bug.cgi?id=41767 Alexey Bataev changed: What|Removed |Added Resolution|--- |FIXED Status|REOPENED|RESOLVED Fixed By Commit(s)|r360073 |r360073, r360365 -- 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 33010] Crash in statepoint lowering after 297695
https://bugs.llvm.org/show_bug.cgi?id=33010 listm...@philipreames.com changed: What|Removed |Added CC||listm...@philipreames.com Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from listm...@philipreames.com --- r360090 | reames | 2019-05-06 15:09:31 -0700 (Mon, 06 May 2019) | 7 lines Fix pr33010, a 2 year old crashing regression The problem was that we were creating a CMOV64rr , . The entire point of a TFI is that address code is not generated, so there's no way to legalize/lower this. Instead, simply prevent it's creation. Arguably, we shouldn't be using *Target*FrameIndices in StatepointLowering at all, but that's a much deeper change. -- 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 41250] Assertion failed: (Dtor && "class has literal fields and bases but no dtor?") when compiled with std=c++17
https://bugs.llvm.org/show_bug.cgi?id=41250 Jeffrey Lin changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #13 from Jeffrey Lin --- Looks like this has been fixed in the latest builds. (Verified on clang version 9.0.0 (trunk 357692) ) -- 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 41725] loop-interchange makes function broken with "opt -instcombine -licm -structurizecfg -jump-threading -loop-rotate -instcombine -loop-interchange"
https://bugs.llvm.org/show_bug.cgi?id=41725 Zhide Zhou 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 41823] New: warning: unannotated fall-through between switch labels
https://bugs.llvm.org/show_bug.cgi?id=41823 Bug ID: 41823 Summary: warning: unannotated fall-through between switch labels Product: lldb Version: unspecified Hardware: PC OS: FreeBSD Status: NEW Severity: enhancement Priority: P Component: All Bugs Assignee: lldb-...@lists.llvm.org Reporter: y...@tsoft.com CC: jdevliegh...@apple.com, llvm-bugs@lists.llvm.org In file included from /usr/ports/devel/llvm-devel/work/llvm-e9c0fded7c9ef8fde329af8495ede75aa0776a6b/tools/lldb/source/Plugins/ABI/SysV-arm/ABISysV_arm.cpp:30: /usr/ports/devel/llvm-devel/work/llvm-e9c0fded7c9ef8fde329af8495ede75aa0776a6b/tools/lldb/source/./Plugins/Process/Utility/ARMDefines.h:73:3: warning: unannotated fall-through between switch labels [-Wimplicit-fallthrough] case COND_EQ: ^ /usr/ports/devel/llvm-devel/work/llvm-e9c0fded7c9ef8fde329af8495ede75aa0776a6b/tools/lldb/source/./Plugins/Process/Utility/ARMDefines.h:73:3: note: insert 'LLVM_FALLTHROUGH;' to silence this warning case COND_EQ: ^ LLVM_FALLTHROUGH; /usr/ports/devel/llvm-devel/work/llvm-e9c0fded7c9ef8fde329af8495ede75aa0776a6b/tools/lldb/source/./Plugins/Process/Utility/ARMDefines.h:73:3: note: insert 'break;' to avoid fall-through case COND_EQ: ^ break; 1 warning 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 40740] [PowerPC64] [ELFv2] wrong .init section for large binaries (long branch thunk)
https://bugs.llvm.org/show_bug.cgi?id=40740 Fangrui Song changed: What|Removed |Added CC||i...@maskray.me Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #14 from Fangrui Song --- Should be fixed D61720/r360405 (will be included in lld 9.0.0) Please re-open if that is not the case :) The added test test/ELF/ppc64-long-branch-init.s should capture the nature of the problem quite well. Linux glibc is unaffected just because their crti.o (first piece of the .init output section) has a bl that need __plt___gmon_start_. Alfredo, I want to express my gladness that you and other folks are working on bringing up FreeBSD powerpc64. -- 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