[llvm-bugs] [Bug 46465] New: libcxx/src/CMakeLists.txt includes thread_win32.cpp regardless of LIBCXX_HAS_WIN32_THREAD_API
https://bugs.llvm.org/show_bug.cgi?id=46465 Bug ID: 46465 Summary: libcxx/src/CMakeLists.txt includes thread_win32.cpp regardless of LIBCXX_HAS_WIN32_THREAD_API Product: libc++ Version: 10.0 Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: unassignedclangb...@nondot.org Reporter: usaonmon...@gmail.com CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com libcxx/src/CMakeLists.txt has the following fragment: if(WIN32) list(APPEND LIBCXX_SOURCES support/win32/locale_win32.cpp support/win32/support.cpp support/win32/thread_win32.cpp ) If LIBCXX_HAS_PTHREAD_API is ON and LIBCXX_HAS_WIN32_THREAD_API is OFF (MINGW), this causes linker errors. It should be: if(WIN32) list(APPEND LIBCXX_SOURCES support/win32/locale_win32.cpp support/win32/support.cpp ) if (LIBCXX_HAS_WIN32_THREAD_API) list(APPEND LIBCXX_SOURCES support/win32/thread_win32.cpp ) endif() -- 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 46466] New: [DWARF] Does not generate nested enumerations.
https://bugs.llvm.org/show_bug.cgi?id=46466
Bug ID: 46466
Summary: [DWARF] Does not generate nested enumerations.
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: DebugInfo
Assignee: unassignedb...@nondot.org
Reporter: international.phan...@gmail.com
CC: jdevliegh...@apple.com, keith.wal...@arm.com,
llvm-bugs@lists.llvm.org,
paul_robin...@playstation.sony.com
For the given test:
//--
struct Struct {
union Union {
enum NestedEnum { RED, BLUE };
};
Union U;
};
Struct S;
int test() {
return S.U.BLUE;
}
//--
The DWARF generated does not include any references to the enumerators 'RED'
and 'BLUE'.
DWARF generated by GCC, CodeView generated by Clang and MSVC, it does include
such references.
--
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 46467] New: [AMDGPU][MC] Invalid default value of MTBUF 'format' modifier
https://bugs.llvm.org/show_bug.cgi?id=46467 Bug ID: 46467 Summary: [AMDGPU][MC] Invalid default value of MTBUF 'format' modifier Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: Backend: AMDGPU Assignee: unassignedb...@nondot.org Reporter: dpreobrazhen...@luxoft.com CC: llvm-bugs@lists.llvm.org Currently used default value for MTBUF 'format' modifier is 0, i.e. data format is BUF_DATA_FORMAT_INVALID. This is useless in practice and is not compatible with SP3 which uses default format value 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] Issue 17742 in oss-fuzz: llvm:clang-fuzzer: Stack-overflow in getDefaultInitValue
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #3 on issue 17742 by ClusterFuzz-External: llvm:clang-fuzzer: Stack-overflow in getDefaultInitValue https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=17742#c3 ClusterFuzz testcase 5646333809000448 is verified as fixed in https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202006250153:202006260202 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 40908] Segfault in StmtPrinter::VisitIntegerLiteral for __int128 values
https://bugs.llvm.org/show_bug.cgi?id=40908 David Stone changed: What|Removed |Added Resolution|--- |DUPLICATE CC||da...@doublewise.net Status|NEW |RESOLVED --- Comment #1 from David Stone --- *** This bug has been marked as a duplicate of bug 35677 *** -- 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 46166] PCH restrictions on floating-point command line options are too strict
https://bugs.llvm.org/show_bug.cgi?id=46166 Melanie Blower changed: What|Removed |Added Resolution|--- |FIXED Fixed By Commit(s)||9518763d710bfb Status|NEW |RESOLVED --- Comment #4 from Melanie Blower --- Code review here, https://reviews.llvm.org/D81869 -- 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 46468] New: LibFuzzer exits with code 77
https://bugs.llvm.org/show_bug.cgi?id=46468 Bug ID: 46468 Summary: LibFuzzer exits with code 77 Product: compiler-rt Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: fuzzer Assignee: unassignedb...@nondot.org Reporter: cem.f.karan@mail.mil CC: llvm-bugs@lists.llvm.org I'm using LibFuzzer via bolero. The related bug on that project is [here](https://github.com/camshaft/bolero/issues/18). When I run bolero, I get the following: ```bash cargo bolero fuzz -t 100sec communications::messages::message::tests::merge Finished test [unoptimized + debuginfo] target(s) in 0.07s running 1 test WARNING: Failed to find function "__sanitizer_acquire_crash_state". WARNING: Failed to find function "__sanitizer_print_stack_trace". WARNING: Failed to find function "__sanitizer_set_death_callback". INFO: Seed: 1089555166 INFO: Loaded 1 modules (1159931 inline 8-bit counters): 1159931 [0x5600931efe00, 0x56009330b0fb), INFO: Loaded 1 PC tables (1159931 PCs): 1159931 [0x56009330b100,0x5600944be0b0), INFO: 1663 files found in /home/cfkaran2/Documents/repositories/bit_network/bit_network_library/src/communications/messages/__fuzz__/communications__messages__message__tests__merge/corpus INFO: -max_len is not provided; libFuzzer will not generate inputs larger than 4096 bytes INFO: seed corpus: files: 1663 min: 1b max: 1617b total: 672085b rss: 84Mb #1664 INITED cov: 7151 ft: 29966 corp: 535/164Kb exec/s: 832 rss: 95Mb #1916 NEWcov: 7151 ft: 29971 corp: 536/166Kb lim: 1577 exec/s: 638 rss: 95Mb L: 1511/1567 MS: 2 ChangeASCIIInt-ChangeBit- #2008 REDUCE cov: 7151 ft: 29971 corp: 536/166Kb lim: 1577 exec/s: 669 rss: 95Mb L: 875/1567 MS: 2 ChangeBinInt-EraseBytes- #2048 pulse cov: 7151 ft: 29971 corp: 536/166Kb lim: 1577 exec/s: 682 rss: 95Mb #2225 NEWcov: 7151 ft: 29979 corp: 537/166Kb lim: 1577 exec/s: 741 rss: 95Mb L: 152/1567 MS: 2 ChangeBit-ChangeBit- F failures: failures: communications::messages::message::tests::merge test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 353 filtered out ==30473== ERROR: libFuzzer: fuzz target exited SUMMARY: libFuzzer: fuzz target exited MS: 2 InsertByte-ChangeByte-; base unit: a5cab92cdd25d4d8fbe849e1c08cf3c9da97daec artifact_prefix='/home/cfkaran2/Documents/repositories/bit_network/bit_network_library/src/communications/messages/__fuzz__/communications__messages__message__tests__merge/crashes/'; Test unit written to /home/cfkaran2/Documents/repositories/bit_network/bit_network_library/src/communications/messages/__fuzz__/communications__messages__message__tests__merge/crashes/crash-b90311f056ed895f4fd4ab9374f090e292023fa6 error: process exited with status 77 ``` Bolero doesn't have such an exit number, and neither does my own code. The only exit code I found that matched came from within LibFuzzer, and it indicates an internal error. Is there anything I can do to give you a better bug report than this? -- 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 38701] link error with CUDA9.2
https://bugs.llvm.org/show_bug.cgi?id=38701 Ye Luo changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #4 from Ye Luo --- Since I no more see similar errors in 2020. I will mark it as resolved. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 25284] ProgramState::assumeInBound does not handle large values well
https://bugs.llvm.org/show_bug.cgi?id=25284 Artem Dergachev changed: What|Removed |Added Resolution|--- |WORKSFORME Status|NEW |RESOLVED --- Comment #5 from Artem Dergachev --- This probably got fixed by https://reviews.llvm.org/D16063. -- 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 46469] New: All Qt apps are silently built inoperable when compiled with clang using LTO ("signal not found")
https://bugs.llvm.org/show_bug.cgi?id=46469
Bug ID: 46469
Summary: All Qt apps are silently built inoperable when
compiled with clang using LTO ("signal not found")
Product: clang
Version: 10.0
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: virtuous...@gmail.com
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
I've noticed that all packages that use Qt and that I tried to build with clang
using LTO were unable to draw their GUI at all or got stuck after creating a
window. Apparently, it's a known old… "feature" for which I failed to find a
report here.
https://www.reddit.com/r/cpp_questions/comments/82jpz5/qt5_signal_broken_by_lto/
https://bugreports.qt.io/browse/QTBUG-43556
https://bugreports.qt.io/browse/QTBUG-61710
https://github.com/InBetweenNames/gentooLTO/issues/444
So, Qt guys refuse to change anything and say that their code is correct and
allege that clang guys say the same. However, building broken binaries without
erroring-out is definitively not OK. If Qt code is truly correct it would be
nice for clang to avoid misoptimising it or, if clang code is correct, detect
such usage and skip optimising it. Or, again, at least erroring-out. What if
entire distribution would be built with clang with LTO by default ?
--
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 46470] New: JSONTest.Integers is flaky
https://bugs.llvm.org/show_bug.cgi?id=46470 Bug ID: 46470 Summary: JSONTest.Integers is flaky Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: Support Libraries Assignee: unassignedb...@nondot.org Reporter: nicolaswe...@gmx.de CC: llvm-bugs@lists.llvm.org Just failed on a Windows bot once here: https://logs.chromium.org/logs/chromium/buildbucket/cr-buildbucket.appspot.com/8876405792703724976/+/steps/package_clang/0/stdout -- 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 46444] clang UsersManual, option misspelled (ffinite-math should be spelled ffinite-math-only)
https://bugs.llvm.org/show_bug.cgi?id=46444 Melanie Blower changed: What|Removed |Added Summary|clang doesn't recognize |clang UsersManual, option |option ffinite-math |misspelled (ffinite-math ||should be spelled ||ffinite-math-only) Fixed By Commit(s)||commit ||7cc5307c73caa72f22edd4208b1 ||75e3c36eec46e Resolution|--- |FIXED Status|NEW |RESOLVED -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 41999] Error: bad immediate value for offset (4096)
https://bugs.llvm.org/show_bug.cgi?id=41999 Nick Desaulniers changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 4068] [Meta] Compiling the Linux kernel with clang
https://bugs.llvm.org/show_bug.cgi?id=4068 Bug 4068 depends on bug 41999, which changed state. Bug 41999 Summary: Error: bad immediate value for offset (4096) https://bugs.llvm.org/show_bug.cgi?id=41999 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 4068] [Meta] Compiling the Linux kernel with clang
https://bugs.llvm.org/show_bug.cgi?id=4068 Bug 4068 depends on bug 45826, which changed state. Bug 45826 Summary: using arm thumb register r7 in inline asm with -pg https://bugs.llvm.org/show_bug.cgi?id=45826 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 45826] using arm thumb register r7 in inline asm with -pg
https://bugs.llvm.org/show_bug.cgi?id=45826 Nick Desaulniers changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #5 from Nick Desaulniers --- Closing this, as it looks like a KI on the GCC side: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69690 -- 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 45309] [meta] 10.0.1 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=45309 Bug 45309 depends on bug 45333, which changed state. Bug 45333 Summary: r372359 causes stack overflow parsing large array https://bugs.llvm.org/show_bug.cgi?id=45333 What|Removed |Added Status|CONFIRMED |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 45333] r372359 causes stack overflow parsing large array
https://bugs.llvm.org/show_bug.cgi?id=45333 Tom Stellard changed: What|Removed |Added Resolution|--- |FIXED Fixed By Commit(s)|c6eb584c64872fbb779df14acd3 |c6eb584c64872fbb779df14acd3 |1c1f3947f6e52 |1c1f3947f6e52 77d76b71d7d Status|CONFIRMED |RESOLVED --- Comment #7 from Tom Stellard --- Merged: 77d76b71d7d -- 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 45579] UNREACHABLE executed at llvm/lib/CodeGen/SelectionDAG/TargetLowering.cpp:5726!
https://bugs.llvm.org/show_bug.cgi?id=45579 Tom Stellard changed: What|Removed |Added Resolution|--- |FIXED Fixed By Commit(s)|3906ae387f0775dfe4426e43367 |3906ae387f0775dfe4426e43367 |48269fafbd190 |48269fafbd190 76ceebb0d96 Status|NEW |RESOLVED --- Comment #7 from Tom Stellard --- Merged: 76ceebb0d96 -- 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 45309] [meta] 10.0.1 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=45309 Bug 45309 depends on bug 45579, which changed state. Bug 45579 Summary: UNREACHABLE executed at llvm/lib/CodeGen/SelectionDAG/TargetLowering.cpp:5726! https://bugs.llvm.org/show_bug.cgi?id=45579 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 41309] member functions shadow template arguments resulting in "reference to non-static member function must be called" error
https://bugs.llvm.org/show_bug.cgi?id=41309
Richard Smith changed:
What|Removed |Added
Fixed By Commit(s)||d1446017f3fdc2f6a9efba22200
||8d20afa1e26cc
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #5 from Richard Smith ---
> Moreover, in CWG458, where the special handling of template members of class
> templates was added to [temp.local]p7, there is similar code:
[...]
> And CWG think that it should be ill-formed:
CWG recently discussed this again, and decided that the rule in the standard is
correct as-is (reversing the decision from March 2004). Each template parameter
scope is associated with some enclosing lexical scope, and the template
parameters are searched after that enclosing lexical scope is searched. For
example, in:
template struct A {
template struct B {
template void f();
};
};
template template template void
A::B::f() {
// #1
}
a lookup from #1 will consider V, then B (and non-dependent base classes),
then U, then A (and non-dependent base classes), then T, then the global
namespace scope.
The rules in this area will be clarified by the upcoming P1787.
I recently implemented that (longstanding but not previously implemented by any
compiler) rule in d1446017f3fdc2f6a9efba222008d20afa1e26cc.
--
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 46471] New: Assertion `materialized_use_empty() && "Uses remain when a value is destroyed!"' failed
https://bugs.llvm.org/show_bug.cgi?id=46471 Bug ID: 46471 Summary: Assertion `materialized_use_empty() && "Uses remain when a value is destroyed!"' failed Product: new-bugs Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: vsevolod.livins...@frtk.ru CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org Error: >$ clang++ -O3 -march=skx -c func.cpp While deleting: i64 % Use still stuck around after Def is destroyed: %sunkaddr242 = mul i64 , 8 clang++: /home/vlivinsk/workspace/llvm/llvm-trunk/llvm/lib/IR/Value.cpp:96: llvm::Value::~Value(): Assertion `materialized_use_empty() && "Uses remain when a value is destroyed!"' failed. PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace, preprocessed source, and associated run script. Stack dump: 0. Program arguments: clang++ -O3 -march=skx -c func.cpp 1. parser at end of file 2. Code generation 3. Running pass 'Function Pass Manager' on module 'func.cpp'. 4. Running pass 'CodeGen Prepare' on function '@_Z1it' #0 0x561d9217fade llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/clang-11+0x2394ade) #1 0x561d9217d8b4 llvm::sys::RunSignalHandlers() (/clang-11+0x23928b4) #2 0x561d9217db31 llvm::sys::CleanupOnSignal(unsigned long) (/clang-11+0x2392b31) #3 0x561d920ebb98 CrashRecoverySignalHandler(int) (/clang-11+0x2300b98) #4 0x7f53bb08f540 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x15540) #5 0x7f53bab243eb raise /build/glibc-t7JzpG/glibc-2.30/signal/../sysdeps/unix/sysv/linux/raise.c:51:1 #6 0x7f53bab03899 abort /build/glibc-t7JzpG/glibc-2.30/stdlib/abort.c:81:7 #7 0x7f53bab03769 get_sysdep_segment_value /build/glibc-t7JzpG/glibc-2.30/intl/loadmsgcat.c:509:8 #8 0x7f53bab03769 _nl_load_domain /build/glibc-t7JzpG/glibc-2.30/intl/loadmsgcat.c:970:34 #9 0x7f53bab15006 (/lib/x86_64-linux-gnu/libc.so.6+0x37006) #10 0x561d91b0f09b (/clang-11+0x1d2409b) #11 0x561d91b0f0f8 llvm::Value::deleteValue() (/clang-11+0x1d240f8) #12 0x561d91549dde (anonymous namespace)::CodeGenPrepare::runOnFunction(llvm::Function&) (.part.0) (/clang-11+0x175edde) #13 0x561d91ab7d0c llvm::FPPassManager::runOnFunction(llvm::Function&) (/clang-11+0x1cccd0c) #14 0x561d91ab83d9 llvm::FPPassManager::runOnModule(llvm::Module&) (/clang-11+0x1ccd3d9) #15 0x561d91ab8787 llvm::legacy::PassManagerImpl::run(llvm::Module&) (/clang-11+0x1ccd787) #16 0x561d9242c773 clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::HeaderSearchOptions const&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::DataLayout const&, llvm::Module*, clang::BackendAction, std::unique_ptr >) (/clang-11+0x2641773) #17 0x561d93113b71 clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) (/clang-11+0x3328b71) #18 0x561d93e918e9 clang::ParseAST(clang::Sema&, bool, bool) (/clang-11+0x40a68e9) #19 0x561d93112678 clang::CodeGenAction::ExecuteAction() (/clang-11+0x3327678) #20 0x561d92a54d79 clang::FrontendAction::Execute() (/clang-11+0x2c69d79) #21 0x561d92a0bb0e clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) (/clang-11+0x2c20b0e) #22 0x561d92b29f70 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) (/clang-11+0x2d3ef70) #23 0x561d90a15139 cc1_main(llvm::ArrayRef, char const*, void*) (/clang-11+0xc2a139) #24 0x561d90a124e8 ExecuteCC1Tool(llvm::SmallVectorImpl&) (/clang-11+0xc274e8) #25 0x561d928cde59 void llvm::function_ref::callback_fn >, std::__cxx11::basic_string, std::allocator >*, bool*) const::'lambda'()>(long) (/clang-11+0x2ae2e59) #26 0x561d920ebd1c llvm::CrashRecoveryContext::RunSafely(llvm::function_ref) (/clang-11+0x2300d1c) #27 0x561d928ce786 clang::driver::CC1Command::Execute(llvm::ArrayRef >, std::__cxx11::basic_string, std::allocator >*, bool*) const (.part.0) (/clang-11+0x2ae3786) #28 0x561d928a5e8c clang::driver::Compilation::ExecuteCommand(clang::driver::Command const&, clang::driver::Command const*&) const (/clang-11+0x2abae8c) #29 0x561d928a67c6 clang::driver::Compilation::ExecuteJobs(clang::driver::JobList const&, llvm::SmallVectorImpl >&) const (/clang-11+0x2abb7c6) #30 0x561d928afb69 clang::driver::Driver::ExecuteCompilation(clang::driver::Compilation&, llvm::SmallVectorImpl >&) (/clang-11+0x2ac4b69) #31 0x561d909950f9 main (/clang-11+0xbaa0f9) #32 0x7f53bab051e3 __libc_start_main /build/glibc-t7JzpG/glibc-2.30/csu/../csu/libc-start.c:342:3 #33 0x561d90a1203e _start (/clang-11+0xc2703e) clang-11: error: clang frontend command failed due to signal (use -v to see invocation) clang version 11.0.0 (https://github.com/llvm/llvm-project.git ae74252341a0e985a3b637c9b6c30aed9b
[llvm-bugs] [Bug 46472] New: Optimize some bit magic into a faster pattern when nand is not available
https://bugs.llvm.org/show_bug.cgi?id=46472
Bug ID: 46472
Summary: Optimize some bit magic into a faster pattern when
nand is not available
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: gabrav...@gmail.com
CC: llvm-bugs@lists.llvm.org
int f(int a, int b, int c)
{
return (a & ~c) | (b & c);
}
Unless the target architecture has a nand intruction available (such as x86
with BMI) this can be optimized to `return ((b ^ a) & c) ^ a;`. This
transformation is done by GCC (though sadly it also does it when nand is
available), but not by LLVM
--
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 46473] New: LLD/COFF does not correctly align TLS section
https://bugs.llvm.org/show_bug.cgi?id=46473
Bug ID: 46473
Summary: LLD/COFF does not correctly align TLS section
Product: lld
Version: unspecified
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: COFF
Assignee: unassignedb...@nondot.org
Reporter: me+l...@luqman.ca
CC: llvm-bugs@lists.llvm.org
Reported at https://github.com/rust-lang/rust/issues/72145
It looks like LLD/COFF doesn't emit properly aligned TLS sections.
Test program:
```C++
#include
#include
__declspec( thread ) char tb = 42;
__declspec( thread ) char zb32[32];
int main()
{
printf("%p %p\n", &tb, zb32);
*(__m256 *)zb32 = _mm256_set_ps(0, 0, 0, 0, 0, 0, 0, 0);
printf("All good\n");
return 0;
}
```
Using ld=link:
> clang repro.cpp -march=sandybridge -O3 -o repro.exe -fuse-ld=link -g
> .\repro.exe
024472806E40 024472806E60
All good
Using ld=lld-link:
> .\repro.exe
01E5D2CE6D30 01E5D2CE6D50
(crashes at this point)
0:000> .excr
rax=0022 rbx=01e5d2ce6e20 rcx=
rdx=0001 rsi=01e5d2ce6d10 rdi=01e5d2cf1660
rip=7ff6d5a01036 rsp=000c855bfb30 rbp=
r8=7ff6d5a61bb0 r9=01e5d2cef812 r10=
r11=000c855bfa20 r12= r13=
r14= r15=
iopl=0 nv up ei pl nz na pe nc
cs=0033 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010202
repro!main+0x36:
7ff6`d5a01036 c5fc29864000 vmovaps ymmword ptr [rsi+40h],ymm0
ds:01e5`d2ce6d50=00
The tls derived pointer is not properly aligned.
The thread local itself and the store to it is marked as align 32:
@"?zb32@@3PADA" = dso_local thread_local global [32 x i8] zeroinitializer,
align 32, !dbg !14
store <8 x float> zeroinitializer, <8 x float>* bitcast ([32 x i8]*
@"?zb32@@3PADA" to <8 x float>*), align 32, !dbg !45, !tbaa !46
Digging into it, as far as I can tell when ntdll is allocating the TLS slots
they're 16 byte aligned.
But looking at the dumpbin output for the ld=lld-link case we see:
Dump of file repro.exe
File Type: EXECUTABLE IMAGE
Section contains the following TLS directory:
000140069000 Start of raw data
000140069060 End of raw data
000140060BC8 Address of index
000140059898 Address of callbacks
0 Size of zero fill
Characteristics
(no align specified)
Compared to the dumpbin output for the ld=link case:
Dump of file repro.exe
File Type: EXECUTABLE IMAGE
Section contains the following TLS directory:
00014008C000 Start of raw data
00014008C26C End of raw data
00014008307C Address of index
00014006D8A8 Address of callbacks
0 Size of zero fill
0060 Characteristics
32 byte align
>lld-link --version
LLD 10.0.0
>clang --version
clang version 10.0.0
Target: x86_64-pc-windows-msvc
Thread model: posix
InstalledDir: C:\Program Files\LLVM\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] Issue 23742 in oss-fuzz: llvm:clang-fuzzer: Stack-overflow in clang::StmtVisitorBase::Visit
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@gmail.com, d...@google.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 OS-Linux Proj-llvm Reported-2020-06-27 Type: Bug New issue 23742 by ClusterFuzz-External: llvm:clang-fuzzer: Stack-overflow in clang::StmtVisitorBase::Visit https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=23742 Detailed Report: https://oss-fuzz.com/testcase?key=5654726678151168 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: clang-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Stack-overflow Crash Address: 0x7ffc03d45f60 Crash State: clang::StmtVisitorBase::Visit Evaluate IntExprEvaluator::VisitBinaryOperator Sanitizer: address (ASAN) Crash Revision: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&revision=202006260202 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5654726678151168 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 46475] New: Failure to optimize xor pattern to xor
https://bugs.llvm.org/show_bug.cgi?id=46475
Bug ID: 46475
Summary: Failure to optimize xor pattern to xor
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: gabrav...@gmail.com
CC: llvm-bugs@lists.llvm.org
bool f(bool a, bool b)
{
return ((a & b) ^ b) | ((a & b) ^ a);
}
This can be optimized to `return a ^ b;`. This transformation is done by GCC,
but not by LLVM.
--
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 46476] New: Failure to optimize tautological comparisons of comparisons to a single one
https://bugs.llvm.org/show_bug.cgi?id=46476
Bug ID: 46476
Summary: Failure to optimize tautological comparisons of
comparisons to a single one
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: gabrav...@gmail.com
CC: llvm-bugs@lists.llvm.org
int f(int a, int b)
{
return (((b != 0) & (a == 0)) | ((a != 0) & (b == 0)));
}
This can be optimized to `(a != 0) ^ (b != 0)`. I originally found this while
compiling this code :
inline bool nand(bool a, bool b)
{
return !(a && b);
}
int f(int a, int b)
{
return nand(nand(b, nand(a, a)), nand(a, nand(b, b)));
}
Which GCC compiles to the above example, and that LLVM optimizes with the
transformation I gave (strangely, LLVM does not seem to optimize the example at
the top of this bug report to the transformed version if directly given the top
example, which is why I'm giving these details as I'm thinking there could be
some kind of UB weirdness or something like that with the transformations here)
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 46477] New: Clang crashed in "clang::Sema::ActOnEnumBody()"
https://bugs.llvm.org/show_bug.cgi?id=46477
Bug ID: 46477
Summary: Clang crashed in "clang::Sema::ActOnEnumBody()"
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Frontend
Assignee: unassignedclangb...@nondot.org
Reporter: haoxi...@gmail.com
CC: llvm-bugs@lists.llvm.org, neeil...@live.com,
richard-l...@metafoo.co.uk
This code, bug.cc ,reduce by C-Reduce, makes clang-trunk crashed.
$cat bug.cc
long a enum : decltype(0 = a)::b {
$clang++ bug.cc
bug.cc:1:7: error: expected ';' after top level declarator
long a enum : decltype(0 = a)::b {
^
;
bug.cc:1:26: error: expression is not assignable
long a enum : decltype(0 = a)::b {
~ ^
bug.cc:1:15: error: missing 'typename' prior to dependent type name
'decltype((0, a))::b'
long a enum : decltype(0 = a)::b {
^~
typename
bug.cc:1:35: error: expected identifier
long a enum : decltype(0 = a)::b {
^
bug.cc:1:35: error: expected '}'
bug.cc:1:34: note: to match this '{'
long a enum : decltype(0 = a)::b {
^
PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash
backtrace, preprocessed source, and associated run script.
Stack dump:
0. Program arguments:
/home/haoxin/corpus-compilers/llvm-trunk/llvm-project-master/build/bin/clang-11
-cc1 -triple x86_64-unknown-linux-gnu -emit-obj -mrelax-all -disable-free
-disable-llvm-verifier -discard-value-names -main-file-name bug.cc
-mrelocation-model static -mframe-pointer=all -fmath-errno -fno-rounding-math
-mconstructor-aliases -munwind-tables -target-cpu x86-64 -dwarf-column-info
-fno-split-dwarf-inlining -debugger-tuning=gdb -resource-dir
/home/haoxin/corpus-compilers/llvm-trunk/llvm-project-master/build/lib/clang/11.0.0
-internal-isystem
/usr/lib/gcc/x86_64-linux-gnu/5.4.0/../../../../include/c++/5.4.0
-internal-isystem
/usr/lib/gcc/x86_64-linux-gnu/5.4.0/../../../../include/x86_64-linux-gnu/c++/5.4.0
-internal-isystem
/usr/lib/gcc/x86_64-linux-gnu/5.4.0/../../../../include/x86_64-linux-gnu/c++/5.4.0
-internal-isystem
/usr/lib/gcc/x86_64-linux-gnu/5.4.0/../../../../include/c++/5.4.0/backward
-internal-isystem /usr/local/include -internal-isystem
/home/haoxin/corpus-compilers/llvm-trunk/llvm-project-master/build/lib/clang/11.0.0/include
-internal-externc-isystem /usr/include/x86_64-linux-gnu
-internal-externc-isystem /include -internal-externc-isystem /usr/include
-fdeprecated-macro -fdebug-compilation-dir
/home/haoxin/compilers/new-scg/new-scg-build/map_test/clang-test/creduce
-ferror-limit 19 -fgnuc-version=4.2.1 -fcxx-exceptions -fexceptions
-fcolor-diagnostics -faddrsig -o /tmp/bug-2d86d7.o -x c++ bug.cc
1. parser at end of file
#0 0x0221f084 PrintStackTraceSignalHandler(void*)
(/home/haoxin/corpus-compilers/llvm-trunk/llvm-project-master/build/bin/clang-11+0x221f084)
#1 0x0221ce4e llvm::sys::RunSignalHandlers()
(/home/haoxin/corpus-compilers/llvm-trunk/llvm-project-master/build/bin/clang-11+0x221ce4e)
#2 0x0221f385 SignalHandler(int)
(/home/haoxin/corpus-compilers/llvm-trunk/llvm-project-master/build/bin/clang-11+0x221f385)
#3 0x7fc760741390 __restore_rt
(/lib/x86_64-linux-gnu/libpthread.so.0+0x11390)
#4 0x03f3cea2 clang::ASTContext::getTypeInfoImpl(clang::Type const*)
const
(/home/haoxin/corpus-compilers/llvm-trunk/llvm-project-master/build/bin/clang-11+0x3f3cea2)
#5 0x03f3e183 clang::ASTContext::getTypeInfo(clang::Type const*) const
(/home/haoxin/corpus-compilers/llvm-trunk/llvm-project-master/build/bin/clang-11+0x3f3e183)
#6 0x03f4f08d clang::ASTContext::getIntWidth(clang::QualType) const
(/home/haoxin/corpus-compilers/llvm-trunk/llvm-project-master/build/bin/clang-11+0x3f4f08d)
#7 0x038a61c6 clang::Sema::ActOnEnumBody(clang::SourceLocation,
clang::SourceRange, clang::Decl*, llvm::ArrayRef, clang::Scope*,
clang::ParsedAttributesView const&)
(/home/haoxin/corpus-compilers/llvm-trunk/llvm-project-master/build/bin/clang-11+0x38a61c6)
#8 0x03690c39 clang::Parser::ParseEnumBody(clang::SourceLocation,
clang::Decl*)
(/home/haoxin/corpus-compilers/llvm-trunk/llvm-project-master/build/bin/clang-11+0x3690c39)
#9 0x0368d722 clang::Parser::ParseEnumSpecifier(clang::SourceLocation,
clang::DeclSpec&, clang::Parser::ParsedTemplateInfo const&,
clang::AccessSpecifier, clang::Parser::DeclSpecContext)
(/home/haoxin/corpus-compilers/llvm-trunk/llvm-project-master/build/bin/clang-11+0x368d722)
#10 0x036849b0
clang::Parser::ParseDeclarationSpecifiers(clang::DeclSpec&,
clang::Parser::ParsedTemplateInfo const&, clang::AccessSpecifier,
clang::Parser::DeclSpecContext, clang::Parser::LateParsedAttrList*)
(/home/haoxin/corpus-compilers/llvm-trunk/llvm-pro
[llvm-bugs] [Bug 46364] .init section incorrectly filled (padded) with int3 instructions
https://bugs.llvm.org/show_bug.cgi?id=46364 Fangrui Song changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |WONTFIX --- Comment #4 from Fangrui Song --- % cat a.sh echo '.section .init,"ax"; .balign 4; ret' > a.s cc -c a.s ld.bfd a.o a.o GNU ld pads the gap with a NOP which may take several forms (90, 66 90, 0f 1f 00, etc): 401000: c3 ret 401001: 0f 1f 00nopDWORD PTR [rax] 401004: c3 ret while LLD pads the gap with a sequence of 0xcc. .init/.fini/.ctors/.dtors/DT_INIT/DT_FINI have been obsoleted for many years. The replacement .init_array/.fini_array/DT_INIT_ARRAY/DT_FINI_ARRAY have great support (https://github.com/dlang/dmd/pull/10562 ). libc implementations of some newer ABIs (aarch64,riscv) don't even support .init/.fini at all. Many modern glibc configurations don't even run DT_INIT. Working around the incorrect sh_addralign has very little value and is in contrary with the spirit of the trap gap patch. -- 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
