[llvm-bugs] Issue 38807 in oss-fuzz: llvm:clang-objc-fuzzer: ASSERT: Index < Size
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevl...@apple.com, igm...@gmail.com, d...@google.com, mit...@google.com, bigch...@gmail.com, eney...@google.com, llvm-...@lists.llvm.org, j...@chromium.org, v...@apple.com, mitch...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Reproducible Stability-Memory-MemorySanitizer Engine-libfuzzer OS-Linux Proj-llvm Reported-2021-09-16 Type: Bug New issue 38807 by ClusterFuzz-External: llvm:clang-objc-fuzzer: ASSERT: Index < Size https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=38807 Detailed Report: https://oss-fuzz.com/testcase?key=5556093678387200 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: clang-objc-fuzzer Job Type: libfuzzer_msan_llvm Platform Id: linux Crash Type: ASSERT Crash Address: Crash State: Index < Size expandArray HandleDestructionImpl Sanitizer: memory (MSAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_msan_llvm&range=201910210337:201910220425 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5556093678387200 Issue filed automatically. See https://google.github.io/oss-fuzz/advanced-topics/reproducing for instructions to reproduce this bug locally. When you fix this bug, please * mention the fix revision(s). * state whether the bug was a short-lived regression or an old bug in any stable releases. * add any other useful information. This information can help downstream consumers. If you need to contact the OSS-Fuzz team with a question, concern, or any other feedback, please file an issue at https://github.com/google/oss-fuzz/issues. Comments on individual Monorail issues are not monitored. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 38814 in oss-fuzz: llvm:llvm-dwarfdump-fuzzer: ASSERT: DwarfVersion != 0 && "line table prologue has no dwarf version information"
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevl...@apple.com, igm...@gmail.com, d...@google.com, mit...@google.com, bigch...@gmail.com, eney...@google.com, llvm-...@lists.llvm.org, j...@chromium.org, v...@apple.com, mitch...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer OS-Linux Proj-llvm Reported-2021-09-16 Type: Bug New issue 38814 by ClusterFuzz-External: llvm:llvm-dwarfdump-fuzzer: ASSERT: DwarfVersion != 0 && "line table prologue has no dwarf version information" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=38814 Detailed Report: https://oss-fuzz.com/testcase?key=6012376860721152 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: llvm-dwarfdump-fuzzer Job Type: libfuzzer_msan_llvm Platform Id: linux Crash Type: ASSERT Crash Address: Crash State: DwarfVersion != 0 && "line table prologue has no dwarf version information" llvm::DWARFDebugLine::Prologue::getFileNameByIndex dumpAttribute Sanitizer: memory (MSAN) Crash Revision: https://oss-fuzz.com/revisions?job=libfuzzer_msan_llvm&revision=202011180625 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=6012376860721152 Issue filed automatically. See https://google.github.io/oss-fuzz/advanced-topics/reproducing for instructions to reproduce this bug locally. When you fix this bug, please * mention the fix revision(s). * state whether the bug was a short-lived regression or an old bug in any stable releases. * add any other useful information. This information can help downstream consumers. If you need to contact the OSS-Fuzz team with a question, concern, or any other feedback, please file an issue at https://github.com/google/oss-fuzz/issues. Comments on individual Monorail issues are not monitored. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 38828 in oss-fuzz: llvm:llvm-isel-fuzzer--aarch64-O2: ASSERT: N1.getValueType() == N2.getValueType() && N1.getValueType() == VT && "Binary ope
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevl...@apple.com, igm...@gmail.com, d...@google.com, mit...@google.com, bigch...@gmail.com, eney...@google.com, llvm-...@lists.llvm.org, j...@chromium.org, v...@apple.com, mitch...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Reproducible Stability-Memory-MemorySanitizer Engine-libfuzzer OS-Linux Proj-llvm Reported-2021-09-16 Type: Bug New issue 38828 by ClusterFuzz-External: llvm:llvm-isel-fuzzer--aarch64-O2: ASSERT: N1.getValueType() == N2.getValueType() && N1.getValueType() == VT && "Binary ope https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=38828 Detailed Report: https://oss-fuzz.com/testcase?key=6501556506198016 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: llvm-isel-fuzzer--aarch64-O2 Job Type: libfuzzer_msan_llvm Platform Id: linux Crash Type: ASSERT Crash Address: Crash State: N1.getValueType() == N2.getValueType() && N1.getValueType() == VT && "Binary ope llvm::SelectionDAG::getNode DAGCombiner::visitADDLike Sanitizer: memory (MSAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_msan_llvm&range=202002230352:202002250348 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=6501556506198016 Issue filed automatically. See https://google.github.io/oss-fuzz/advanced-topics/reproducing for instructions to reproduce this bug locally. When you fix this bug, please * mention the fix revision(s). * state whether the bug was a short-lived regression or an old bug in any stable releases. * add any other useful information. This information can help downstream consumers. If you need to contact the OSS-Fuzz team with a question, concern, or any other feedback, please file an issue at https://github.com/google/oss-fuzz/issues. Comments on individual Monorail issues are not monitored. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 27686 in oss-fuzz: llvm: Fuzzing build failure
Comment #48 on issue 27686 by ClusterFuzz-External: llvm: Fuzzing build failure https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=27686#c48 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-5a360b73-134e-457f-95b1-fd5441218866.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 48889] ScalarExprEmitter::VisitAbstractConditionalOperator(const clang::AbstractConditionalOperator*): Assertion `!RHS && "LHS and RHS types must match"' failed
https://bugs.llvm.org/show_bug.cgi?id=48889 maic changed: What|Removed |Added Status|CONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #7 from maic --- Might be fixed by https://reviews.llvm.org/D99466 -- 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 25200] clang-format strips new line on <
https://bugs.llvm.org/show_bug.cgi?id=25200 maic changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from maic --- This was fixed in the meantime -- 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 51879] New: UBSan false positive vptr with -O1
https://bugs.llvm.org/show_bug.cgi?id=51879 Bug ID: 51879 Summary: UBSan false positive vptr with -O1 Product: compiler-rt Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: ubsan Assignee: unassignedb...@nondot.org Reporter: mai...@live.de CC: llvm-bugs@lists.llvm.org Created attachment 25265 --> https://bugs.llvm.org/attachment.cgi?id=25265&action=edit 1.cpp Steps to reproduce with -O1. (Other optimization levels pass fine.) $ clang++-13 -std=c++17 -O1 -fsanitize=undefined ./1.cpp && ./a.out 1.cpp:12:25: runtime error: member call on address 0x00d50238 which does not point to an object of type 'A' 0x00d50238: note: object has invalid vptr 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ^~~ invalid vptr SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior 1.cpp:12:25 in UndefinedBehaviorSanitizer:DEADLYSIGNAL ==462339==ERROR: UndefinedBehaviorSanitizer: SEGV on unknown address 0x (pc 0x004274e7 bp 0x sp 0x7ffecb558b00 T462339) ==462339==The signal is caused by a READ memory access. ==462339==Hint: address points to the zero page. -- 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 48945] [meta] 11.1.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=48945 H. Vetinari changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED CC||h.vetin...@gmx.com --- Comment #2 from H. Vetinari --- Release has happened, closing 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 51880] New: [OpenMP] Merge 41a6b50c2596 into 13.0.0
https://bugs.llvm.org/show_bug.cgi?id=51880
Bug ID: 51880
Summary: [OpenMP] Merge 41a6b50c2596 into 13.0.0
Product: OpenMP
Version: unspecified
Hardware: All
OS: All
Status: NEW
Severity: release blocker
Priority: P
Component: Clang Compiler Support
Assignee: unassignedclangb...@nondot.org
Reporter: dimi...@andric.com
CC: llvm-bugs@lists.llvm.org
Please merge https://github.com/llvm/llvm-project/commit/41a6b50c2596
("[OpenMP]Fix PR51349: Remove AlwaysInline for if regions") into 13.0.0.
Otherwise many OpenMP programs will fail to compile, with a fatal backend
error. See also bug 51349.
--
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 51881] New: Crash on invalid use of `_Nonnull` attribute through an alias template
https://bugs.llvm.org/show_bug.cgi?id=51881 Bug ID: 51881 Summary: Crash on invalid use of `_Nonnull` attribute through an alias template Product: clang Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: Frontend Assignee: unassignedclangb...@nondot.org Reporter: chandl...@gmail.com CC: llvm-bugs@lists.llvm.org, neeil...@live.com, richard-l...@metafoo.co.uk https://compiler-explorer.com/z/EKfcebd97 ``` template using Nonnull = T _Nonnull; Nonnull x; ``` >From compiler explorer: ``` 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: /opt/compiler-explorer/clang-trunk/bin/clang++ -g -o /app/output.s -mllvm --x86-asm-syntax=intel -S --gcc-toolchain=/opt/compiler-explorer/gcc-snapshot -fcolor-diagnostics -fno-crash-diagnostics -std=c++20 -O2 -march=haswell -fsanitize=null -fno-inline 1. :4:1: at annotation token #0 0x55ebf938a22f PrintStackTraceSignalHandler(void*) Signals.cpp:0:0 #1 0x55ebf93880f0 llvm::sys::CleanupOnSignal(unsigned long) (/opt/compiler-explorer/clang-trunk/bin/clang+++0x35880f0) #2 0x55ebf92d8a68 CrashRecoverySignalHandler(int) CrashRecoveryContext.cpp:0:0 #3 0x7f02e24143c0 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x153c0) #4 0x55ebfb934947 clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformAttributedType(clang::TypeLocBuilder&, clang::AttributedTypeLoc) SemaTemplateInstantiate.cpp:0:0 #5 0x55ebfb9242cb clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformType(clang::TypeLocBuilder&, clang::TypeLoc) SemaTemplateInstantiate.cpp:0:0 #6 0x55ebfb927a2a clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformType(clang::TypeSourceInfo*) SemaTemplateInstantiate.cpp:0:0 #7 0x55ebfb927b38 clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformType(clang::QualType) SemaTemplateInstantiate.cpp:0:0 #8 0x55ebfb92894c clang::Sema::SubstType(clang::QualType, clang::MultiLevelTemplateArgumentList const&, clang::SourceLocation, clang::DeclarationName) (/opt/compiler-explorer/clang-trunk/bin/clang+++0x5b2894c) #9 0x55ebfb841180 clang::Sema::CheckTemplateIdType(clang::TemplateName, clang::SourceLocation, clang::TemplateArgumentListInfo&) (/opt/compiler-explorer/clang-trunk/bin/clang+++0x5a41180) #10 0x55ebfb842baf clang::Sema::ActOnTemplateIdType(clang::Scope*, clang::CXXScopeSpec&, clang::SourceLocation, clang::OpaquePtr, clang::IdentifierInfo*, clang::SourceLocation, clang::SourceLocation, llvm::MutableArrayRef, clang::SourceLocation, bool, bool) (/opt/compiler-explorer/clang-trunk/bin/clang+++0x5a42baf) #11 0x55ebfb21316d clang::Parser::AnnotateTemplateIdTokenAsType(clang::CXXScopeSpec&, bool) (/opt/compiler-explorer/clang-trunk/bin/clang+++0x541316d) #12 0x55ebfb17c3c2 clang::Parser::ParseDeclarationSpecifiers(clang::DeclSpec&, clang::Parser::ParsedTemplateInfo const&, clang::AccessSpecifier, clang::Parser::DeclSpecContext, clang::Parser::LateParsedAttrList*) (/opt/compiler-explorer/clang-trunk/bin/clang+++0x537c3c2) #13 0x55ebfb1515af clang::Parser::ParseDeclOrFunctionDefInternal(clang::ParsedAttributesWithRange&, clang::ParsingDeclSpec&, clang::AccessSpecifier) (/opt/compiler-explorer/clang-trunk/bin/clang+++0x53515af) #14 0x55ebfb151e31 clang::Parser::ParseDeclarationOrFunctionDefinition(clang::ParsedAttributesWithRange&, clang::ParsingDeclSpec*, clang::AccessSpecifier) (.part.280) Parser.cpp:0:0 #15 0x55ebfb157d59 clang::Parser::ParseExternalDeclaration(clang::ParsedAttributesWithRange&, clang::ParsingDeclSpec*) (/opt/compiler-explorer/clang-trunk/bin/clang+++0x5357d59) #16 0x55ebfb159179 clang::Parser::ParseTopLevelDecl(clang::OpaquePtr&, bool) (/opt/compiler-explorer/clang-trunk/bin/clang+++0x5359179) #17 0x55ebfb14c9d9 clang::ParseAST(clang::Sema&, bool, bool) (/opt/compiler-explorer/clang-trunk/bin/clang+++0x534c9d9) #18 0x55ebfa2fa762 clang::CodeGenAction::ExecuteAction() (/opt/compiler-explorer/clang-trunk/bin/clang+++0x44fa762) #19 0x55ebf9c985e1 clang::FrontendAction::Execute() (/opt/compiler-explorer/clang-trunk/bin/clang+++0x3e985e1) #20 0x55ebf9c35942 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) (/opt/compiler-explorer/clang-trunk/bin/clang+++0x3e35942) #21 0x55ebf9d658e3 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) (/opt/compiler-explorer/clang-trunk/bin/clang+++0x3f658e3) #22 0x55ebf70cf6dc cc1_main(llvm::ArrayRef, char const*, void*) (/opt/compiler-explorer/clang-trunk/bin/clang+++0x12cf6dc) #23 0x55ebf70cb75d ExecuteCC1Tool(llvm::SmallVectorImpl&) driver.cpp:0:0 #24 0x55ebf9add095 void llvm::
[llvm-bugs] [Bug 51882] New: "fragment is larger than or outside of variable" and "fragment covers entire variable" with LTO
https://bugs.llvm.org/show_bug.cgi?id=51882
Bug ID: 51882
Summary: "fragment is larger than or outside of variable" and
"fragment covers entire variable" with LTO
Product: new-bugs
Version: unspecified
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: efrie...@quicinc.com
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org
Testcase follows. The given code is an ODR violation, but it shouldn't crash.
a.cpp:
struct X {
long a;
bool b;
};
void f() { X z; z.b=true; }
b.cpp:
struct X {
long a;
};
X y;
$ clang -shared -flto b.cpp a.cpp -fuse-ld=lld -g -O
fragment covers entire variable
call void @llvm.dbg.declare(metadata i64* undef, metadata !23, metadata
!DIExpression(DW_OP_LLVM_fragment, 0, 64)), !dbg !24
!23 = !DILocalVariable(name: "z", scope: !19, file: !10, line: 5, type: !5)
fragment is larger than or outside of variable
call void @llvm.dbg.declare(metadata [7 x i8]* undef, metadata !23, metadata
!DIExpression(DW_OP_LLVM_fragment, 72, 56)), !dbg !24
!23 = !DILocalVariable(name: "z", scope: !19, file: !10, line: 5, type: !5)
fragment is larger than or outside of variable
call void @llvm.dbg.value(metadata i8 1, metadata !23, metadata
!DIExpression(DW_OP_LLVM_fragment, 64, 8)), !dbg !25
!23 = !DILocalVariable(name: "z", scope: !19, file: !10, line: 5, type: !5)
LLVM ERROR: Broken module found, compilation aborted!
PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash
backtrace.
Stack dump:
0. Program arguments:
/usr2/efriedma/local/upstream-build-release/bin/ld.lld -z relro
--hash-style=gnu --eh-frame-hdr -m elf_x86_64 -shared -o a.out
/usr/lib/x86_64-linux-gnu/crti.o
/usr/lib/gcc/x86_64-linux-gnu/5.4.0/crtbeginS.o
-L/usr/lib/gcc/x86_64-linux-gnu/5.4.0 -L/lib/x86_64-linux-gnu -L/lib/../lib64
-L/usr/lib/x86_64-linux-gnu
-L/local/mnt2/workspace2/efriedma/upstream-build-release/bin/../lib -L/lib
-L/usr/lib -plugin-opt=mcpu=x86-64 -plugin-opt=O1 /tmp/b-359201.o
/tmp/a-fa0ce5.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed
-lgcc_s --no-as-needed /usr/lib/gcc/x86_64-linux-gnu/5.4.0/crtendS.o
/usr/lib/x86_64-linux-gnu/crtn.o
#0 0x03185493 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int)
(/usr2/efriedma/local/upstream-build-release/bin/ld.lld+0x3185493)
#1 0x0318305e llvm::sys::RunSignalHandlers()
(/usr2/efriedma/local/upstream-build-release/bin/ld.lld+0x318305e)
#2 0x03185a86 SignalHandler(int) Signals.cpp:0:0
#3 0x7f8d80370390 __restore_rt
(/lib/x86_64-linux-gnu/libpthread.so.0+0x11390)
#4 0x7f8d7ed5a438 raise
/build/glibc-e6zv40/glibc-2.23/signal/../sysdeps/unix/sysv/linux/raise.c:54:0
#5 0x7f8d7ed5c03a abort /build/glibc-e6zv40/glibc-2.23/stdlib/abort.c:91:0
#6 0x030ebaa8
(/usr2/efriedma/local/upstream-build-release/bin/ld.lld+0x30ebaa8)
#7 0x030eb8f8
(/usr2/efriedma/local/upstream-build-release/bin/ld.lld+0x30eb8f8)
#8 0x066b9896
(/usr2/efriedma/local/upstream-build-release/bin/ld.lld+0x66b9896)
#9 0x0492e4cd llvm::detail::PassModel >::run(llvm::Module&,
llvm::AnalysisManager&) LTOBackend.cpp:0:0
#10 0x0668c0ef llvm::PassManager >::run(llvm::Module&,
llvm::AnalysisManager&)
(/usr2/efriedma/local/upstream-build-release/bin/ld.lld+0x668c0ef)
#11 0x04927ded llvm::lto::opt(llvm::lto::Config const&,
llvm::TargetMachine*, unsigned int, llvm::Module&, bool,
llvm::ModuleSummaryIndex*, llvm::ModuleSummaryIndex const*,
std::__1::vector > const&)
(/usr2/efriedma/local/upstream-build-release/bin/ld.lld+0x4927ded)
#12 0x0492941a llvm::lto::backend(llvm::lto::Config const&,
std::__1::function > (unsigned int)>,
unsigned int, llvm::Module&, llvm::ModuleSummaryIndex&)
(/usr2/efriedma/local/upstream-build-release/bin/ld.lld+0x492941a)
#13 0x04919783
llvm::lto::LTO::runRegularLTO(std::__1::function > (unsigned int)>)
(/usr2/efriedma/local/upstream-build-release/bin/ld.lld+0x4919783)
#14 0x04918b45
llvm::lto::LTO::run(std::__1::function > (unsigned int)>,
std::__1::function > (unsigned int)>
(unsigned int, llvm::StringRef)>)
(/usr2/efriedma/local/upstream-build-release/bin/ld.lld+0x4918b45)
#15 0x0331c4f4 lld::elf::BitcodeCompiler::compile()
(/usr2/efriedma/local/upstream-build-release/bin/ld.lld+0x331c4f4)
#16 0x0327e136 void
lld::elf::LinkerDriver::compileBitcodeFiles >() (/usr2/efriedma/local/upstream-build-release/bin/ld.lld+0x327e136)
#17 0x03269617 void
lld::elf::LinkerDriver::link >(llvm::opt::InputArgList&)
(/usr2/efriedma/local/upstream-build-release/bin/ld.lld+0x3269617)
#18 0x032582fc lld::elf::LinkerDriver::linkerMain(llvm::ArrayRef) (/usr2/efriedma/local/upstream-build-release/bin/ld.lld+0x32582fc)
#19 0x03256352 lld::elf::link(llvm::ArrayRef
[llvm-bugs] [Bug 51883] New: Undefined Reference to static constexpr when compiling with -fprofile-instr-generate
https://bugs.llvm.org/show_bug.cgi?id=51883
Bug ID: 51883
Summary: Undefined Reference to static constexpr when compiling
with -fprofile-instr-generate
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: C++14
Assignee: unassignedclangb...@nondot.org
Reporter: thoren.paul...@gmail.com
CC: blitzrak...@gmail.com, erik.pilking...@gmail.com,
llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk
Godbolt link: https://godbolt.org/z/vqEjKEKch
When I compile the following code with `-Oz -std=c++14
-fprofile-instr-generate`, it refers to the undefined symbol kUndefined, which
causes "undefined reference" at link time.
```
#include
class Foo {
private:
static constexpr int kUndefined = 4;
public:
int Bar(int a);
};
int Foo::Bar(int a) {
return std::max(a, kUndefined);
}
```
It seems this is because std::max takes its arguments by reference, so if it
doesn't get inlined (consequence of -Oz), code is generated referring to
kUndefined, but there is no code generated to define kUndefined.
--
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 51884] New: Clang build fails when build directory contains space character
https://bugs.llvm.org/show_bug.cgi?id=51884
Bug ID: 51884
Summary: Clang build fails when build directory contains space
character
Product: clang
Version: unspecified
Hardware: Macintosh
OS: MacOS X
Status: NEW
Severity: normal
Priority: P
Component: Driver
Assignee: unassignedclangb...@nondot.org
Reporter: bsp2bsp-l...@yahoo.com
CC: llvm-bugs@lists.llvm.org, neeil...@live.com,
richard-l...@metafoo.co.uk
Clang build fails when build directory contains space character.
Error messages:
[ 95%] Linking CXX executable ../../../../bin/clang
clang: error: no such file or directory:
'Space/Net/llvm/Build/tools/clang/tools/driver/Info.plist'
make[2]: *** [bin/clang-14] Error 1
make[1]: *** [tools/clang/tools/driver/CMakeFiles/clang.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs
The path name is actually:
'Dev Space/Net/llvm/Build/tools/clang/tools/driver/Info.plist'
This is corrective patch:
cd ".../llvm-project/clang/tools/driver"
patch <<'EOFF'
--- CMakeLists.txt2021-09-14 13:10:43.0 -0700
+++ CMakeLists-fixed.txt2021-09-14 13:13:16.0 -0700
@@ -82,7 +82,7 @@
set(TOOL_INFO_PLIST_OUT "${CMAKE_CURRENT_BINARY_DIR}/${TOOL_INFO_PLIST}")
target_link_libraries(clang
PRIVATE
-"-Wl,-sectcreate,__TEXT,__info_plist,${TOOL_INFO_PLIST_OUT}")
+"-Wl,-sectcreate,__TEXT,__info_plist,\"${TOOL_INFO_PLIST_OUT}\"")
configure_file("${TOOL_INFO_PLIST}.in" "${TOOL_INFO_PLIST_OUT}" @ONLY)
set(TOOL_INFO_UTI)
EOFF
--
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 51885] New: [C++20] Defaulting a comparison operator on second declaration should be diagnosed
https://bugs.llvm.org/show_bug.cgi?id=51885
Bug ID: 51885
Summary: [C++20] Defaulting a comparison operator on second
declaration should be diagnosed
Product: clang
Version: trunk
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: C++2a
Assignee: unassignedclangb...@nondot.org
Reporter: arthur.j.odw...@gmail.com
CC: blitzrak...@gmail.com, erik.pilking...@gmail.com,
llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk
https://eel.is/c++draft/class.compare.default#1.sentence-4
> A definition of a comparison operator as defaulted that appears in a class
> shall be the first declaration of that function.
IIUC, this sentence is designed to prevent people from default'ing a
"non-hidden" friend, like this:
// https://godbolt.org/z/6Tdac86TP
struct B;
bool operator==(const B&, const B&);
struct B {
friend bool operator==(const B&, const B&) = default;
};
int main() { B b; return b == b; }
However, Clang trunk does not diagnose any problem with this code. Instead,
Clang quietly pretends that the friend declaration wasn't there at all.
FWIW, GCC also does not diagnose this code, but GCC quietly *accepts* the
friend declaration (so we don't get any undefined symbol for operator== and the
program links fine).
--
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 24871] LLVMHello will not build if path contains a space.
https://bugs.llvm.org/show_bug.cgi?id=24871 Shivam Gupta changed: What|Removed |Added CC||shivam98@gmail.com Fixed By Commit(s)||https://github.com/llvm/llv ||m-project/commit/3eb01f99fb ||87b0d1f87ce998ae13c9fca5bd0 ||39d 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
