[llvm-bugs] [Bug 90699] Issues not labelled
Issue 90699 Summary Issues not labelled Labels new issue Assignees Reporter xtaltal Can the following two issues be labelled? https://github.com/llvm/llvm-project/issues/88598 https://github.com/llvm/llvm-project/issues/88599 Close this issue after. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 90698] llvm 18 regression: LegalizerInfo.cpp:199: llvm::LegalizeActionStep llvm::LegalizeRuleSet::apply(const llvm::LegalityQuery&) const: Assertion `mutationIsSane(Rule, Query, Mutat
Issue
90698
Summary
llvm 18 regression: LegalizerInfo.cpp:199: llvm::LegalizeActionStep llvm::LegalizeRuleSet::apply(const llvm::LegalityQuery&) const: Assertion `mutationIsSane(Rule, Query, Mutation) && "legality mutation invalid for match"' failed
Labels
bug,
backend:AArch64,
regression,
platform:windows
Assignees
Reporter
andrewrk
version: release/18.x, commit 78b99c73ee4b96fe9ce0e294d4632326afb2db42
reduced.ll
```llvm
target datalayout = "e-m:w-p:64:64-i32:32-i64:64-i128:128-n32:64-S128"
target triple = "aarch64-unknown-windows-gnu"
define fastcc i16 @"behavior.cast.test.@intFromBool on vector.S.doTheTest"() {
Entry:
%0 = insertelement <3 x i1> zeroinitializer, i1 false, i32 0
%1 = call fastcc i16 null(ptr null, <3 x i1> zeroinitializer, <3 x i1> %0)
ret i16 0
}
```
```console
[nix-shell:~/src/zig/build-llvm18]$ ~/local/llvm18-assert/bin/clang -c reduced.ll -target aarch64-windows-gnu
clang: /home/andy/dev/llvm-project-18/llvm/lib/CodeGen/GlobalISel/LegalizerInfo.cpp:199: llvm::LegalizeActionStep llvm::LegalizeRuleSet::apply(const llvm::LegalityQuery&) const: Assertion `mutationIsSane(Rule, Query, Mutation) && "legality mutation invalid for match"' failed.
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace, preprocessed source, and associated run script.
Stack dump:
0. Program arguments: /home/andy/local/llvm18-assert/bin/clang -c reduced.ll -target aarch64-windows-gnu
1. Code generation
2. Running pass 'Function Pass Manager' on module 'reduced.ll'.
3. Running pass 'Legalizer' on function '@"behavior.cast.test.@intFromBool on vector.S.doTheTest"'
#0 0x0387f4db llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/home/andy/local/llvm18-assert/bin/clang+0x387f4db)
#1 0x0387c83b llvm::sys::RunSignalHandlers() (/home/andy/local/llvm18-assert/bin/clang+0x387c83b)
#2 0x037c1508 CrashRecoverySignalHandler(int) CrashRecoveryContext.cpp:0:0
#3 0x7f5bd1254a70 __restore_rt (/nix/store/anlf335xlh41yjhm114swi87406mq5pw-glibc-2.38-44/lib/libc.so.6+0x3da70)
#4 0x7f5bd12a3ddc __pthread_kill_implementation (/nix/store/anlf335xlh41yjhm114swi87406mq5pw-glibc-2.38-44/lib/libc.so.6+0x8cddc)
#5 0x7f5bd12549c6 gsignal (/nix/store/anlf335xlh41yjhm114swi87406mq5pw-glibc-2.38-44/lib/libc.so.6+0x3d9c6)
#6 0x7f5bd123d8fa abort (/nix/store/anlf335xlh41yjhm114swi87406mq5pw-glibc-2.38-44/lib/libc.so.6+0x268fa)
#7 0x7f5bd123d819 _nl_load_domain.cold (/nix/store/anlf335xlh41yjhm114swi87406mq5pw-glibc-2.38-44/lib/libc.so.6+0x26819)
#8 0x7f5bd124d3c6 (/nix/store/anlf335xlh41yjhm114swi87406mq5pw-glibc-2.38-44/lib/libc.so.6+0x363c6)
#9 0x04690593 llvm::LegalizeRuleSet::apply(llvm::LegalityQuery const&) const (/home/andy/local/llvm18-assert/bin/clang+0x4690593)
#10 0x04692066 llvm::LegalizerInfo::getAction(llvm::LegalityQuery const&) const (/home/andy/local/llvm18-assert/bin/clang+0x4692066)
#11 0x046924e6 llvm::LegalizerInfo::getAction(llvm::MachineInstr const&, llvm::MachineRegisterInfo const&) const (/home/andy/local/llvm18-assert/bin/clang+0x46924e6)
#12 0x0468f688 llvm::LegalizerHelper::legalizeInstrStep(llvm::MachineInstr&, llvm::LostDebugLocObserver&) (/home/andy/local/llvm18-assert/bin/clang+0x468f688)
#13 0x0464b138 llvm::Legalizer::legalizeMachineFunction(llvm::MachineFunction&, llvm::LegalizerInfo const&, llvm::ArrayRef, llvm::LostDebugLocObserver&, llvm::MachineIRBuilder&, llvm::GISelKnownBits*) (/home/andy/local/llvm18-assert/bin/clang+0x464b138)
#14 0x0464ca37 llvm::Legalizer::runOnMachineFunction(llvm::MachineFunction&) (.part.0) Legalizer.cpp:0:0
#15 0x02c30325 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) (.part.0) MachineFunctionPass.cpp:0:0
#16 0x03213619 llvm::FPPassManager::runOnFunction(llvm::Function&) (/home/andy/local/llvm18-assert/bin/clang+0x3213619)
#17 0x03213751 llvm::FPPassManager::runOnModule(llvm::Module&) (/home/andy/local/llvm18-assert/bin/clang+0x3213751)
#18 0x03214057 llvm::legacy::PassManagerImpl::run(llvm::Module&) (/home/andy/local/llvm18-assert/bin/clang+0x3214057)
#19 0x03aedb33 clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::HeaderSearchOptions const&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::StringRef, llvm::Module*, clang::BackendAction, llvm::IntrusiveRefCntPtr, std::unique_ptr>, clang::BackendConsumer*) (/home/andy/local/llvm18-assert/bin/clang+0x3aedb33)
#20 0x040cd0fa clang::CodeGenAction::ExecuteAction() (/home/andy/local/llvm18-assert/bin/clang+0x40cd0fa)
#21 0x0434b2c9 clang::FrontendAction::Execute() (/home/andy/local/llvm18-asse
[llvm-bugs] [Bug 90697] [bug] [x86_64] [ubuntu22.04] clang crash when compiling to bpf
Issue 90697 Summary [bug] [x86_64] [ubuntu22.04] clang crash when compiling to bpf Labels clang Assignees Reporter kohshi54 Hello. clang crashed with exit code 139 when trying to compile to bpf bytecode. Stack dump: 0. Program arguments: clang -v -target bpf -I/usr/include/x86_64-linux-gnu -I/usr/src/linux-hwe-6.5-headers-6.5.0-28/include/ -g -c hello.bpf.c 1. parser at end of file #0 0x7b4db023fd01 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/lib/x86_64-linux-gnu/libLLVM-14.so.1+0xe3fd01) #1 0x7b4db023da3e llvm::sys::RunSignalHandlers() (/lib/x86_64-linux-gnu/libLLVM-14.so.1+0xe3da3e) #2 0x7b4db023f0ab llvm::sys::CleanupOnSignal(unsigned long) (/lib/x86_64-linux-gnu/libLLVM-14.so.1+0xe3f0ab) #3 0x7b4db016bdff (/lib/x86_64-linux-gnu/libLLVM-14.so.1+0xd6bdff) #4 0x7b4daec42520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520) #5 0x7b4db6c257ce clang::ASTContext::getASTRecordLayout(clang::RecordDecl const*) const (/lib/x86_64-linux-gnu/libclang-cpp.so.14+0xe257ce) #6 0x7b4db68e5f0c clang::ASTContext::getTypeInfoImpl(clang::Type const*) const (/lib/x86_64-linux-gnu/libclang-cpp.so.14+0xae5f0c) #7 0x7b4db68e6d96 clang::ASTContext::getTypeInfo(clang::Type const*) const (/lib/x86_64-linux-gnu/libclang-cpp.so.14+0xae6d96) #8 0x7b4db68e5e2e clang::ASTContext::getTypeInfoImpl(clang::Type const*) const (/lib/x86_64-linux-gnu/libclang-cpp.so.14+0xae5e2e) #9 0x7b4db68e6d96 clang::ASTContext::getTypeInfo(clang::Type const*) const (/lib/x86_64-linux-gnu/libclang-cpp.so.14+0xae6d96) #10 0x7b4db68e6a59 clang::ASTContext::getTypeInfoInChars(clang::QualType) const (/lib/x86_64-linux-gnu/libclang-cpp.so.14+0xae6a59) #11 0x7b4db6c30d64 (/lib/x86_64-linux-gnu/libclang-cpp.so.14+0xe30d64) #12 0x7b4db6c2d316 (/lib/x86_64-linux-gnu/libclang-cpp.so.14+0xe2d316) #13 0x7b4db6c25bd9 clang::ASTContext::getASTRecordLayout(clang::RecordDecl const*) const (/lib/x86_64-linux-gnu/libclang-cpp.so.14+0xe25bd9) #14 0x7b4db791bcd3 clang::CodeGen::CodeGenTypes::ComputeRecordLayout(clang::RecordDecl const*, llvm::StructType*) (/lib/x86_64-linux-gnu/libclang-cpp.so.14+0x1b1bcd3) #15 0x7b4db7a07472 clang::CodeGen::CodeGenTypes::ConvertRecordDeclType(clang::RecordDecl const*) (/lib/x86_64-linux-gnu/libclang-cpp.so.14+0x1c07472) #16 0x7b4db7a06554 clang::CodeGen::CodeGenTypes::ConvertType(clang::QualType) (/lib/x86_64-linux-gnu/libclang-cpp.so.14+0x1c06554) #17 0x7b4db7a0646f clang::CodeGen::CodeGenTypes::ConvertTypeForMem(clang::QualType, bool) (/lib/x86_64-linux-gnu/libclang-cpp.so.14+0x1c0646f) #18 0x7b4db7a0698c clang::CodeGen::CodeGenTypes::ConvertType(clang::QualType) (/lib/x86_64-linux-gnu/libclang-cpp.so.14+0x1c0698c) #19 0x7b4db7a0646f clang::CodeGen::CodeGenTypes::ConvertTypeForMem(clang::QualType, bool) (/lib/x86_64-linux-gnu/libclang-cpp.so.14+0x1c0646f) #20 0x7b4db7920390 (/lib/x86_64-linux-gnu/libclang-cpp.so.14+0x1b20390) #21 0x7b4db791cddf (/lib/x86_64-linux-gnu/libclang-cpp.so.14+0x1b1cddf) #22 0x7b4db791bd88 clang::CodeGen::CodeGenTypes::ComputeRecordLayout(clang::RecordDecl const*, llvm::StructType*) (/lib/x86_64-linux-gnu/libclang-cpp.so.14+0x1b1bd88) #23 0x7b4db7a07472 clang::CodeGen::CodeGenTypes::ConvertRecordDeclType(clang::RecordDecl const*) (/lib/x86_64-linux-gnu/libclang-cpp.so.14+0x1c07472) #24 0x7b4db7a06554 clang::CodeGen::CodeGenTypes::ConvertType(clang::QualType) (/lib/x86_64-linux-gnu/libclang-cpp.so.14+0x1c06554) #25 0x7b4db7a0646f clang::CodeGen::CodeGenTypes::ConvertTypeForMem(clang::QualType, bool) (/lib/x86_64-linux-gnu/libclang-cpp.so.14+0x1c0646f) #26 0x7b4db79a521c clang::CodeGen::CodeGenModule::EmitExternalVarDeclaration(clang::VarDecl const*) (/lib/x86_64-linux-gnu/libclang-cpp.so.14+0x1ba521c) #27 0x7b4db6f1e962 clang::Sema::ActOnEndOfTranslationUnit() (/lib/x86_64-linux-gnu/libclang-cpp.so.14+0x111e962) #28 0x7b4db68c1c86 clang::Parser::ParseTopLevelDecl(clang::OpaquePtr&, bool) (/lib/x86_64-linux-gnu/libclang-cpp.so.14+0xac1c86) #29 0x7b4db68048dd clang::ParseAST(clang::Sema&, bool, bool) (/lib/x86_64-linux-gnu/libclang-cpp.so.14+0xa048dd) #30 0x7b4db7978b71 clang::CodeGenAction::ExecuteAction() (/lib/x86_64-linux-gnu/libclang-cpp.so.14+0x1b78b71) #31 0x7b4db8314b57 clang::FrontendAction::Execute() (/lib/x86_64-linux-gnu/libclang-cpp.so.14+0x2514b57) #32 0x7b4db826c3a6 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) (/lib/x86_64-linux-gnu/libclang-cpp.so.14+0x246c3a6) #33 0x7b4db838e45b clang::ExecuteCompilerInvocation(clang::CompilerInstance*) (/lib/x86_64-linux-gnu/libclang-cpp.so.14+0x258e45b) #34 0x0041328b cc1_main(llvm::ArrayRef, char const*, void*) (/usr/lib/llvm-14/bin/clang+0x41328b) #35 0x004114bc (/usr
[llvm-bugs] [Bug 90695] llvm 18 regression: GetElementPtrTypeIterator.h:158: llvm::TypeSize llvm::generic_gep_type_iterator::getSequentialElementStride(const llvm::DataLayout&) const [with ItTy
Issue
90695
Summary
llvm 18 regression: GetElementPtrTypeIterator.h:158: llvm::TypeSize llvm::generic_gep_type_iterator::getSequentialElementStride(const llvm::DataLayout&) const [with ItTy = llvm::Value* const*]: Assertion `DL.typeSizeEqualsStoreSize(ElemTy) && "Not byte-addressable"' failed
Labels
bug,
backend:AArch64,
regression,
platform:windows
Assignees
Reporter
andrewrk
version: release/18.x, commit 78b99c73ee4b96fe9ce0e294d4632326afb2db42
reduced.ll:
```llvm
target datalayout = "e-m:w-p:64:64-i32:32-i64:64-i128:128-n32:64-S128"
target triple = "aarch64-unknown-windows-gnu"
define fastcc i16 @"behavior.shuffle.test.@shuffle bool 1.S.doTheTest"() {
Entry:
%0 = load <2 x i1>, ptr null, align 1
%1 = shufflevector <2 x i1> %0, <2 x i1> zeroinitializer, <4 x i32>
ret i16 0
}
```
```console
[nix-shell:~/src/zig/build-llvm18]$ ~/local/llvm18-assert/bin/llc reduced.ll
llc: /home/andy/dev/llvm-project-18/llvm/include/llvm/IR/GetElementPtrTypeIterator.h:158: llvm::TypeSize llvm::generic_gep_type_iterator::getSequentialElementStride(const llvm::DataLayout&) const [with ItTy = llvm::Value* const*]: Assertion `DL.typeSizeEqualsStoreSize(ElemTy) && "Not byte-addressable"' failed.
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
Stack dump:
0. Program arguments: /home/andy/local/llvm18-assert/bin/llc reduced.ll
1. Running pass 'Function Pass Manager' on module 'reduced.ll'.
2. Running pass 'Interleaved Load Combine Pass' on function '@"behavior.shuffle.test.@shuffle bool 1.S.doTheTest"'
#0 0x0393ec9b llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/home/andy/local/llvm18-assert/bin/llc+0x393ec9b)
#1 0x0393bffb llvm::sys::RunSignalHandlers() (/home/andy/local/llvm18-assert/bin/llc+0x393bffb)
#2 0x0393c125 SignalHandler(int) Signals.cpp:0:0
#3 0x7fb01fd53a70 __restore_rt (/nix/store/anlf335xlh41yjhm114swi87406mq5pw-glibc-2.38-44/lib/libc.so.6+0x3da70)
#4 0x7fb01fda2ddc __pthread_kill_implementation (/nix/store/anlf335xlh41yjhm114swi87406mq5pw-glibc-2.38-44/lib/libc.so.6+0x8cddc)
#5 0x7fb01fd539c6 gsignal (/nix/store/anlf335xlh41yjhm114swi87406mq5pw-glibc-2.38-44/lib/libc.so.6+0x3d9c6)
#6 0x7fb01fd3c8fa abort (/nix/store/anlf335xlh41yjhm114swi87406mq5pw-glibc-2.38-44/lib/libc.so.6+0x268fa)
#7 0x7fb01fd3c819 _nl_load_domain.cold (/nix/store/anlf335xlh41yjhm114swi87406mq5pw-glibc-2.38-44/lib/libc.so.6+0x26819)
#8 0x7fb01fd4c3c6 (/nix/store/anlf335xlh41yjhm114swi87406mq5pw-glibc-2.38-44/lib/libc.so.6+0x363c6)
#9 0x02e05001 llvm::DataLayout::getIndexedOffsetInType(llvm::Type*, llvm::ArrayRef) const (/home/andy/local/llvm18-assert/bin/llc+0x2e05001)
#10 0x0282054d (anonymous namespace)::VectorInfo::computeFromLI(llvm::LoadInst*, (anonymous namespace)::VectorInfo&, llvm::DataLayout const&) InterleavedLoadCombinePass.cpp:0:0
#11 0x02823ae5 (anonymous namespace)::VectorInfo::computeFromSVI(llvm::ShuffleVectorInst*, (anonymous namespace)::VectorInfo&, llvm::DataLayout const&) InterleavedLoadCombinePass.cpp:0:0
#12 0x0282722b (anonymous namespace)::InterleavedLoadCombineImpl::run() InterleavedLoadCombinePass.cpp:0:0
#13 0x02828cfb (anonymous namespace)::InterleavedLoadCombine::runOnFunction(llvm::Function&) InterleavedLoadCombinePass.cpp:0:0
#14 0x02ef1789 llvm::FPPassManager::runOnFunction(llvm::Function&) (/home/andy/local/llvm18-assert/bin/llc+0x2ef1789)
#15 0x02ef18c1 llvm::FPPassManager::runOnModule(llvm::Module&) (/home/andy/local/llvm18-assert/bin/llc+0x2ef18c1)
#16 0x02ef21c7 llvm::legacy::PassManagerImpl::run(llvm::Module&) (/home/andy/local/llvm18-assert/bin/llc+0x2ef21c7)
#17 0x007fe10b compileModule(char**, llvm::LLVMContext&) llc.cpp:0:0
#18 0x007049a7 main (/home/andy/local/llvm18-assert/bin/llc+0x7049a7)
#19 0x7fb01fd3dfce __libc_start_call_main (/nix/store/anlf335xlh41yjhm114swi87406mq5pw-glibc-2.38-44/lib/libc.so.6+0x27fce)
#20 0x7fb01fd3e089 __libc_start_main@GLIBC_2.2.5 (/nix/store/anlf335xlh41yjhm114swi87406mq5pw-glibc-2.38-44/lib/libc.so.6+0x28089)
#21 0x007f3c25 _start (/home/andy/local/llvm18-assert/bin/llc+0x7f3c25)
Aborted (core dumped)
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 90685] Slowdown from the `final` keyword
Issue 90685 Summary Slowdown from the `final` keyword Labels new issue Assignees Reporter define-private-public Hi. I published [this blog post](https://16bpp.net/blog/post/the-performance-impact-of-cpp-final-keyword/) last week Monday about the `final` keyword. I made a note of a slowdown that was found when using clang/LLVM to compile and run the code. [On Hacker News discussion](https://news.ycombinator.com/item?id=40125240) an LLVM developer commented: > As an LLVM developer, I really wish the author filed a bug report and waited for some analysis BEFORE publishing an article (that may never get amended) that recommends not using this keyword with clang for performance reasons. I suspect there's just a bug in clang. 1. Is this an actual bug? 2. Would someone be willing to provide analysis as to what's going on? I plan on writing a follow up post shortly since the discussion surrounding everything seemed to be a bit more than I anticipated; and I feel a lot of people got the intent of the article wrong. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 90684] Do you still need commit access?
Issue 90684 Summary Do you still need commit access? Labels infrastructure:commit-access Assignees Reporter tstellar ### TLDR: If you want to retain your commit access, please comment on this issue. Otherwise, you can unsubscribe from this issue and ignore it. Commit access is not required to contribute to the project. You can still create Pull Requests without commit access. @jonathanmetzman @s-perron @bmahjour @ShivaChen @Sezoir @mariannems @ShuhongLL @Krishnakariya @vjayathirtha-nv @rarutyun @sks75220 @abelkocsis @ktomi996 @matejaMarjanovic @KappaMikey1337 @plotfi @rdzhabarov @anhtuyenibm @sidbav @zrthxn LLVM has a policy of downgrading write access to its repositories for accounts with long term inactivity. This is done because inactive accounts with high levels of access tend to be at increased risk of compromise and this is one tactic that the project employs to guard itself from malicious actors. Note that write access is not required to contribute to the project. You can still submit pull requests and have someone else merge them. Our project policy is to ping anyone with less than five 'interactions' with the repositories over a 12 month period to see if they still need commit access. An 'interaction' and be any one of: * Pushing a commit. * Merging a pull request (either their own or someone else’s). * Commenting on a PR. If you want to retain your commit access, please post a comment on this issue. If you do not want to keep your commit access, you can just ignore this issue. If you have not responded in 6 weeks, then you will move moved from the 'write' role within the project to the 'triage' role. The 'triage' role is still a privileged role and will allow you to do the following: * Review Pull Requests. * Comment on issues. * Apply/dismiss labels. * Close, reopen, and assign all issues and pull requests. * Apply milestones. * Mark duplicate issues and pull requests. * Request pull request reviews. * Hide anyone’s comments. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 90680] Bug or insufficient utility in `transform.structured.split` op
Issue 90680 Summary Bug or insufficient utility in `transform.structured.split` op Labels Assignees Reporter srcarroll First of all I've identified an inconsistency in the way static and dynamic split points are handled. basically, no matter what in the static case, a single split point is provided and works no matter how many target payloads there are (see https://github.com/llvm/llvm-project/blob/main/mlir/lib/Dialect/Linalg/TransformOps/LinalgTransformOps.cpp#L2208). Whereas with the dynamic case, the number of split points is determined by the number of payloads of the dynamic split point operand (see https://github.com/llvm/llvm-project/blob/main/mlir/lib/Dialect/Linalg/TransformOps/LinalgTransformOps.cpp#L2208). but then the number of split points is compared to the number of target payloads (https://github.com/llvm/llvm-project/blob/main/mlir/lib/Dialect/Linalg/TransformOps/LinalgTransformOps.cpp#L2200). I can't quite put my finger on it, but this seems wrong to me. For example, consider the edge case where there are no target payloads. In this case the static doesn't throw any definite failures while the dynamic case does. I think at the very least, there should be consistency here. but the question is, which one do we go with. I actually prefer how the static case works for this. because otherwise we would have to know that a payload is present to be able to use the op in the first place, which i don't think is very useful. I was working on a patch for this to handle some case i needed. but then i realized that there was this discrepancy between the number of split point payloads and number of target payloads. I admit I'm a little confused about what the relationship between these two things should actually be. But I'm almost certain they shouldn't necessarily be the same size. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 90675] [PPC] DoubleAPFloat scalbn fails to readjust high double when rounding affects its value
Issue 90675 Summary [PPC] DoubleAPFloat scalbn fails to readjust high double when rounding affects its value Labels backend:PowerPC Assignees Reporter hubert-reinterpretcast The `DoubleAPFloat` `scalbn` implementation treats the high and the low double as being independent: https://github.com/llvm/llvm-project/blob/0c0c5c475857e9cd6a2fe82fd1e46abdb174a1c1/llvm/lib/Support/APFloat.cpp#L5132-L5133 That is incorrect. As can be observed from the following (https://godbolt.org/z/r64Wfv4zW), when the low double is close to 0.5 ulps of the high double, division by a power of 2 can cause the low double to round to 0.5 ulps of the high double (which can then require that the high double be adjusted so that its value is the value of the `long double` correctly rounded to a `double`): ``` constexpr double subnorm = __DBL_DENORM_MIN__ * 3.; constexpr double subnormAdjacent = (1. + __DBL_EPSILON__) * 0x1p-1022 * 0x1p+3; extern constexpr long double theValue = (long double)subnorm + subnormAdjacent; extern constexpr long double expected = theValue / 2.; ``` The `DoubleAPFloat` implementation of `scalbnl` would (for division by 2 via an `n` of -1) produce a high double that changes from the input value only by the encoded exponent. The (correct) result produced by the division operation above differs from the input value in more than that. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 90668] Miscompilation of some forms of (x + y) * z
Issue
90668
Summary
Miscompilation of some forms of (x + y) * z
Labels
new issue
Assignees
Reporter
glandium
Reduced testcase:
```
#include
#include
size_t off(int8_t a) {
return (uint8_t)(a + 128) * 8;
}
```
With clang 18, this compiled down to:
```
add dil, -128
movzx eax, dil
shl eax, 3
ret
```
With trunk, this compiles down to:
```
movzx eax, dil
lea eax, [8*rax + 1024]
ret
```
The math in the lea is actually fine, transforming (a+128) * 8 into 8 * a + 1024. But the problem is that a is zero extended instead of sign extended, so the results are wrong for negative values.
Bisection says it started happening with 7177dc2ef7f3a50a1d8b892d7bd298f3d52a1aab.
Cc: @fengfeng09
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 90662] /llvm/lib/Object/MachOObjectFile.cpp:5197: possible cut'n'paste error ?
Issue
90662
Summary
/llvm/lib/Object/MachOObjectFile.cpp:5197: possible cut'n'paste error ?
Labels
new issue
Assignees
Reporter
dcb314
Static analyser cppcheck says:
llvm/lib/Object/MachOObjectFile.cpp:5197:18: warning: Identical condition 'ImportsEnd>Symbols', second condition is always false [identicalConditionAfterEarlyExit]
Source code is
if (ImportsEnd > Symbols)
return malformedError("bad chained fixups: imports end " +
Twine(ImportsEndOffset) + " extends past end " +
Twine(DyldChainedFixups.datasize));
if (ImportsEnd > Symbols)
return malformedError("bad chained fixups: imports end " +
Twine(ImportsEndOffset) + " overlaps with symbols");
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 90661] [BOLT] Evaluate and speedup discoverFileObjects
Issue 90661 Summary [BOLT] Evaluate and speedup discoverFileObjects Labels help wanted, good first issue, BOLT Assignees Reporter aaupov Operations with symbols such as name lookup are expensive and some binaries have millions of symbols, so it makes sense to try to reduce the symbol-related overheads. Measure how much the following cost and refactor/eliminate: 1. Checks for symbol name being equal to __asan_init and __llvm_coverage_mapping for every single symbol: https://github.com/llvm/llvm-project/blob/a1423ba4278775472523fed074de6dbdfd01898a/bolt/lib/Rewrite/RewriteInstance.cpp#L824-L837 2. FileName set for every local function symbol (with O(1M) for large binaries) while we can instead use file symbol lookup with O(log N_Syms) cost and FileSyms memory cost https://github.com/llvm/llvm-project/pull/89088 3. Merge iteration over two loops over symbols into one: https://github.com/llvm/llvm-project/blob/a1423ba4278775472523fed074de6dbdfd01898a/bolt/lib/Rewrite/RewriteInstance.cpp#L824 and https://github.com/llvm/llvm-project/blob/a1423ba4278775472523fed074de6dbdfd01898a/bolt/lib/Rewrite/RewriteInstance.cpp#L876 ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 90653] [libc][test] `atan*` and `smoke/atan*` tests need to have exception and errno checking fixed
Issue
90653
Summary
[libc][test] `atan*` and `smoke/atan*` tests need to have exception and errno checking fixed
Labels
libc
Assignees
Reporter
Flandini
These depends on `ASSERT_GE` and `EXPECT_GE` in `{ASSERT,EXPECT}_FP_EXCEPTION`. Using RoundingMode with the quick rounding mode tests ends up setting exceptions, so after switching these to `{ASSERT,EXPECT}_EQ`, these tests are failing and need to be changed to wrap the function invocation and not the entire RoundingMode test setup.
See https://github.com/llvm/llvm-project/pull/88816
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 90652] [RISCV] Assertion `LHS.getValueType() == VT && RHS.getValueType() == VT && "Cannot use select on differing types"' failed.
Issue
90652
Summary
[RISCV] Assertion `LHS.getValueType() == VT && RHS.getValueType() == VT && "Cannot use select on differing types"' failed.
Labels
backend:RISC-V,
crash
Assignees
dtcxzyw
Reporter
dtcxzyw
Reduced test case: https://godbolt.org/z/ToPME8sW1
```
define i1 @test(i64 %x, i1 %cond1, i1 %cond2) {
entry:
%sadd = call { i64, i1 } @llvm.sadd.with.overflow.i64(i64 %x, i64 1)
%ov = extractvalue { i64, i1 } %sadd, 1
%or = or i1 %cond2, %ov
%sel = select i1 %cond1, i1 %cond2, i1 %or
ret i1 %sel
}
```
```
llc: /root/llvm-project/llvm/include/llvm/CodeGen/SelectionDAG.h:1239: llvm::SDValue llvm::SelectionDAG::getSelect(const llvm::SDLoc&, llvm::EVT, llvm::SDValue, llvm::SDValue, llvm::SDValue): Assertion `LHS.getValueType() == VT && RHS.getValueType() == VT && "Cannot use select on differing types"' failed.
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
Stack dump:
0. Program arguments: /opt/compiler-explorer/clang-assertions-trunk/bin/llc -o /app/output.s -x86-asm-syntax=intel -mtriple=riscv64
1. Running pass 'Function Pass Manager' on module ''.
2. Running pass 'RISC-V DAG->DAG Pattern Instruction Selection' on function '@test'
#0 0x0395b768 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/opt/compiler-explorer/clang-assertions-trunk/bin/llc+0x395b768)
#1 0x03958ebc SignalHandler(int) Signals.cpp:0:0
#2 0x79ecb9e42520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520)
#3 0x79ecb9e969fc pthread_kill (/lib/x86_64-linux-gnu/libc.so.6+0x969fc)
#4 0x79ecb9e42476 gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x42476)
#5 0x79ecb9e287f3 abort (/lib/x86_64-linux-gnu/libc.so.6+0x287f3)
#6 0x79ecb9e2871b (/lib/x86_64-linux-gnu/libc.so.6+0x2871b)
#7 0x79ecb9e39e96 (/lib/x86_64-linux-gnu/libc.so.6+0x39e96)
#8 0x00bd692f llvm::SelectionDAG::getSelect(llvm::SDLoc const&, llvm::EVT, llvm::SDValue, llvm::SDValue, llvm::SDValue) (/opt/compiler-explorer/clang-assertions-trunk/bin/llc+0xbd692f)
#9 0x01ab4ab6 tryFoldSelectIntoOp(llvm::SDNode*, llvm::SelectionDAG&, llvm::SDValue, llvm::SDValue, bool) RISCVISelLowering.cpp:0:0
#10 0x01b125a6 llvm::RISCVTargetLowering::PerformDAGCombine(llvm::SDNode*, llvm::TargetLowering::DAGCombinerInfo&) const (/opt/compiler-explorer/clang-assertions-trunk/bin/llc+0x1b125a6)
#11 0x035cdb7d (anonymous namespace)::DAGCombiner::combine(llvm::SDNode*) DAGCombiner.cpp:0:0
#12 0x035cf48c (anonymous namespace)::DAGCombiner::Run(llvm::CombineLevel) DAGCombiner.cpp:0:0
#13 0x035d1a6a llvm::SelectionDAG::Combine(llvm::CombineLevel, llvm::AAResults*, llvm::CodeGenOptLevel) (/opt/compiler-explorer/clang-assertions-trunk/bin/llc+0x35d1a6a)
#14 0x037273d2 llvm::SelectionDAGISel::CodeGenAndEmitDAG() (/opt/compiler-explorer/clang-assertions-trunk/bin/llc+0x37273d2)
#15 0x0372af15 llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) (/opt/compiler-explorer/clang-assertions-trunk/bin/llc+0x372af15)
#16 0x0372c987 llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) (.part.0) SelectionDAGISel.cpp:0:0
#17 0x02976b71 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) (.part.0) MachineFunctionPass.cpp:0:0
#18 0x02f36633 llvm::FPPassManager::runOnFunction(llvm::Function&) (/opt/compiler-explorer/clang-assertions-trunk/bin/llc+0x2f36633)
#19 0x02f36871 llvm::FPPassManager::runOnModule(llvm::Module&) (/opt/compiler-explorer/clang-assertions-trunk/bin/llc+0x2f36871)
#20 0x02f370d5 llvm::legacy::PassManagerImpl::run(llvm::Module&) (/opt/compiler-explorer/clang-assertions-trunk/bin/llc+0x2f370d5)
#21 0x0082aa5c compileModule(char**, llvm::LLVMContext&) llc.cpp:0:0
#22 0x00728f26 main (/opt/compiler-explorer/clang-assertions-trunk/bin/llc+0x728f26)
#23 0x79ecb9e29d90 (/lib/x86_64-linux-gnu/libc.so.6+0x29d90)
#24 0x79ecb9e29e40 __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x29e40)
#25 0x0082157e _start (/opt/compiler-explorer/clang-assertions-trunk/bin/llc+0x82157e)
Program terminated with signal: SIGSEGV
Compiler returned: 139
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 90631] [HLSL] Add Intangible AST Type
Issue 90631 Summary [HLSL] Add Intangible AST Type Labels HLSL Assignees Reporter llvm-beanz HLSL has a set of _intangible types_, which are described in in the [draft HLSL Specification (**[Basic.types]**)](https://microsoft.github.io/hlsl-specs/specs/hlsl.pdf): > There are special implementation-defined types such as handle types, which fall into a category of standard intangible types. Intangible types are types that have no defined object representation or value representation, as such the size is unknown at compile time. > > A class type T is an intangible class type if it contains an base classes or members of intangible class type, standard intangible type, or arrays of such types. Standard intangible types and intangible class types are collectively called intangible types([9](https://microsoft.github.io/hlsl-specs/specs/hlsl.html#Intangible)). We need to add a new AST type for intangible types, and a way to generate the appropriate handle types. ## Acceptance Criteria * New AST Type for intangible types * New type trait builtin for `__is_intangible` * Update resource types to use intangible handle ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 90628] [RISCV] Allow RISC-V "V" instructions in inline assembly without having to add the RVV "V" extension to command line
Issue
90628
Summary
[RISCV] Allow RISC-V "V" instructions in inline assembly without having to add the RVV "V" extension to command line
Labels
new issue
Assignees
Reporter
johnplatts
Here is a snippet of code that compiles successfully with GCC but fails to compile with Clang unless the `-march=rv32gcv1p0` or `-march=rv64gcv1p0` option is added to the command line:
```
#include
#include
#include
#include
#ifndef COMPAT_HWCAP_ISA_V
#define COMPAT_HWCAP_ISA_V (1 << ('V' - 'A'))
#endif
bool IsRvv1_0Supported() {
int64_t bits = 0;
const unsigned long hw = getauxval(AT_HWCAP);
if ((hw & COMPAT_HWCAP_ISA_V) == COMPAT_HWCAP_ISA_V) {
size_t e8m1_vec_len;
#if __riscv_xlen == 64
int64_t vtype_reg_val;
#else
int32_t vtype_reg_val;
#endif
// Check that a vuint8m1_t vector is at least 16 bytes and that tail
// agnostic and mask agnostic mode are supported
asm volatile(
"vsetvli %0, zero, e8, m1, ta, ma\n\t"
"csrr %1, vtype"
: "=r"(e8m1_vec_len), "=r"(vtype_reg_val));
// The RVV target is supported if the VILL bit of VTYPE (the MSB bit of
// VTYPE) is not set and the length of a vuint8m1_t vector is at least 16
// bytes
if (vtype_reg_val >= 0 && e8m1_vec_len >= 16) {
return true;
}
}
return false;
}
```
We really want Clang to allow the above code to compile on RISC-V, even without specifying the -march=rv32gcv1p0 or -march=rv64gcv1p0 option (or another option that enables at least the RISC-V Zve32x extension), as the instructions in the inline assembly statement are only executed if the RISC-V "V" extension is present due to the check of the result returned by `getauxval(AT_HWCAP)`.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 90620] [C++20] [Modules] Cannot export type_info/operator new/operator delete
Issue
90620
Summary
[C++20] [Modules] Cannot export type_info/operator new/operator delete
Labels
new issue
Assignees
Reporter
huangqinjin
`test.cppm`
```c++
module;
#include
export module test;
extern "C++"
{
export class type_info; // 0
export void* operator new(size_t); // 1
export void* operator new[](size_t);// 2
export void operator delete(void*) noexcept;// 3
export void operator delete[](void*) noexcept; // 4
export void operator delete(void*, size_t) noexcept;// 5
export void operator delete[](void*, size_t) noexcept; // 6
}
```
targeting x86_64-linux-gnu
```shell
✗ clang --target=x86_64-linux-gnu -std=c++20 --precompile test.cppm
test.cppm:11:18: error: cannot export redeclaration 'operator new' here since the previous declaration is not exported
11 | export void* operator new(size_t); // 1
| ^
note: previous declaration is here
test.cppm:12:18: error: cannot export redeclaration 'operator new[]' here since the previous declaration is not exported
12 | export void* operator new[](size_t);// 2
| ^
note: previous declaration is here
test.cppm:13:17: error: cannot export redeclaration 'operator delete' here since the previous declaration is not exported
13 | export void operator delete(void*) noexcept;// 3
| ^
note: previous declaration is here
test.cppm:14:17: error: cannot export redeclaration 'operator delete[]' here since the previous declaration is not exported
14 | export void operator delete[](void*) noexcept; // 4
| ^
note: previous declaration is here
4 errors generated.
```
targeting x86_64-windows-msvc
```shell
✗ clang --target=x86_64-windows-msvc -std=c++20 --precompile test.cppm
test.cppm:9:18: error: cannot export redeclaration 'type_info' here since the previous declaration is not exported
9 | export class type_info; // 0
| ^
note: previous declaration is here
test.cppm:11:18: error: cannot export redeclaration 'operator new' here since the previous declaration is not exported
11 | export void* operator new(size_t); // 1
| ^
note: previous declaration is here
test.cppm:12:18: error: cannot export redeclaration 'operator new[]' here since the previous declaration is not exported
12 | export void* operator new[](size_t);// 2
| ^
note: previous declaration is here
test.cppm:13:17: error: cannot export redeclaration 'operator delete' here since the previous declaration is not exported
13 | export void operator delete(void*) noexcept;// 3
| ^
note: previous declaration is here
test.cppm:14:17: error: cannot export redeclaration 'operator delete[]' here since the previous declaration is not exported
14 | export void operator delete[](void*) noexcept; // 4
| ^
note: previous declaration is here
5 errors generated.
```
The strange thing is that other overloads of `operator new` and `operator delete` can be exported without error.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 68415 in oss-fuzz: llvm:llvm-dwarfdump-fuzzer: Null-dereference READ in llvm::DataExtractor::getU8
Status: New Owner: CC: k...@google.com, masc...@google.com, igm...@gmail.com, sammcc...@google.com, da...@adalogics.com, d...@google.com, mit...@google.com, bigch...@gmail.com, eney...@google.com, llvm-...@lists.llvm.org, jo...@devlieghere.com, 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-2024-04-30 Type: Bug New issue 68415 by ClusterFuzz-External: llvm:llvm-dwarfdump-fuzzer: Null-dereference READ in llvm::DataExtractor::getU8 https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=68415 Detailed Report: https://oss-fuzz.com/testcase?key=6257425133993984 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: llvm-dwarfdump-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Null-dereference READ Crash Address: 0x Crash State: llvm::DataExtractor::getU8 llvm::DWARFExpression::Operation::extract llvm::DWARFExpression::print Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202004090442:202004100305 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=6257425133993984 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 68401 in oss-fuzz: llvm:llvm-dwarfdump-fuzzer: Abrt in llvm::llvm_unreachable_internal
Status: New Owner: CC: k...@google.com, masc...@google.com, igm...@gmail.com, sammcc...@google.com, da...@adalogics.com, d...@google.com, mit...@google.com, bigch...@gmail.com, eney...@google.com, llvm-...@lists.llvm.org, jo...@devlieghere.com, 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-2024-04-30 Type: Bug New issue 68401 by ClusterFuzz-External: llvm:llvm-dwarfdump-fuzzer: Abrt in llvm::llvm_unreachable_internal https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=68401 Detailed Report: https://oss-fuzz.com/testcase?key=5749124381278208 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: llvm-dwarfdump-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Abrt Crash Address: 0x0001 Crash State: llvm::llvm_unreachable_internal llvm::DWARFFormValue::extractValue llvm::DWARFDebugNames::NameIndex::getEntry Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201801290646:201801300702 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5749124381278208 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 68400 in oss-fuzz: llvm:clang-fuzzer: ASSERT: DD && "queried property of class with no definition"
Status: New Owner: CC: k...@google.com, masc...@google.com, igm...@gmail.com, sammcc...@google.com, da...@adalogics.com, d...@google.com, mit...@google.com, bigch...@gmail.com, eney...@google.com, llvm-...@lists.llvm.org, jo...@devlieghere.com, 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-2024-04-30 Type: Bug New issue 68400 by ClusterFuzz-External: llvm:clang-fuzzer: ASSERT: DD && "queried property of class with no definition" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=68400 Detailed Report: https://oss-fuzz.com/testcase?key=5747178676420608 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: clang-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: ASSERT Crash Address: Crash State: DD && "queried property of class with no definition" clang::CXXRecordDecl::data clang::Sema::FinalizeVarWithDestructor Sanitizer: address (ASAN) Crash Revision: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&revision=201909210337 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5747178676420608 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 90605] [Clang] __is_trivially_assignable
Issue
90605
Summary
[Clang] __is_trivially_assignable
Labels
clang:frontend,
rejects-valid
Assignees
Reporter
philnik777
In C++03, Clang claims that a struct containing a member with a deleted assignment operator is assignable, but diagnoses the instantiation as using a deleted function.
```c++
struct Element {
Element& operator=(const Element&) = delete;
};
struct S {
Element i;
S& operator=(const S&) = default;
};
_Static_assert(!__is_trivially_assignable(S&, const S&)); // assertion fails
_Static_assert(!__is_assignable(S&, const S&)); // assertion fails
void test() {
S s;
S s2;
s2 = s; // diagnosed as an error
}
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 68383 in oss-fuzz: llvm:clang-fuzzer: Abrt in llvm::llvm_unreachable_internal
Status: New Owner: CC: k...@google.com, masc...@google.com, igm...@gmail.com, sammcc...@google.com, da...@adalogics.com, d...@google.com, mit...@google.com, bigch...@gmail.com, eney...@google.com, llvm-...@lists.llvm.org, jo...@devlieghere.com, 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-2024-04-30 Type: Bug New issue 68383 by ClusterFuzz-External: llvm:clang-fuzzer: Abrt in llvm::llvm_unreachable_internal https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=68383 Detailed Report: https://oss-fuzz.com/testcase?key=4525671903002624 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: clang-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Abrt Crash Address: 0x05393921 Crash State: llvm::llvm_unreachable_internal CXXNameMangler::mangleExpression CXXNameMangler::mangleExpression Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202006110252:202006121812 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=4525671903002624 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 90596] Overzealous -Wstrict-prototypes warnings on function definitions
Issue
90596
Summary
Overzealous -Wstrict-prototypes warnings on function definitions
Labels
new issue
Assignees
Reporter
jmarshall
Consider the following, _foo.c_:
```c
int foo() {
return 42;
}
```
Current clang (19.0.0git c3598b161a4d868b1cd10a7ee7ac37d68e5a36fe) with `-pedantic` or `-Wstrict-prototypes` produces a warning for this code:
```
clang -c -Wstrict-prototypes foo.c
foo.c:1:8: warning: a function declaration without a prototype is deprecated in all versions of C [-Wstrict-prototypes]
1 | int foo() {
|^
| void
```
The discussion in [[RFC] Enabling -Wstrict-prototypes by default in C](https://discourse.llvm.org/t/rfc-enabling-wstrict-prototypes-by-default-in-c/60521) largely focusses on encouraging users to write declarations as `int foo(void);` but I am interested in the application of this warning to function **definitions**.
The diagnostic message above is somewhat confusing as this is a function definition, not just a function declaration. More importantly, I believe there is no confusion about a function definition with an empty parameter list. In particular C17 N2176 §6.7.6.3/14 says [similar text appears in earlier versions; emphasis added]
> An identifier list declares only the identifiers of the parameters of the function. **An empty list in a function declarator that is part of a definition of that function specifies that the function has no parameters.** The empty list in a function declarator that is not part of a definition of that function specifies that no information about the number or types of the parameters is supplied. [Footnote 147: See “future language directions” (6.11.6).]
I would take this to mean that a function **definition** with an empty parameter list effectively provides a prototype, and therefore that the warning is spurious in this case. It seems unfortunate to encourage users to hypercorrect their code to define such functions as `int foo(void) { return 42; }` when the `void` doesn't add anything in a function **definition**.
I also tried to find the chapter and verse of the standard saying that this scenario is “deprecated in all versions of C”. I guess this is based on §6.11.6, which says
> The use of function declarators with empty parentheses (not prototype-format parameter type declarators) is an obsolescent feature.
Based on the two “…empty list…” sentences in the paragraph quoted above whose footnote refers to §6.11.6 and the fact that the obsolescent feature we're trying to get rid of in §6.11.6 is non-prototype declarations, I think this sentence intends only to refer to the latter and should perhaps read
> The use of function declarators **(that are not part of definitions of the respective functions)** with empty parentheses (not prototype-format parameter type declarators) is an obsolescent feature.
in which case it would not provide motivation for emitting this warning on function **definitions**. (I did not see a defect report to this effect or otherwise relating to §6.11.6.)
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 90589] [AArch64][MC] Error "Implement any new match types added!" with invalid SME2 ZIP instruction
Issue
90589
Summary
[AArch64][MC] Error "Implement any new match types added!" with invalid SME2 ZIP instruction
Labels
backend:AArch64,
crash-on-invalid,
mc
Assignees
Reporter
ostannard
This invalid SME2 instruction causes an UNREACHABLE crash in the AArch64 assembly parser:
```
$ echo "zip {z1.q-z2.q}, z0.q, z0.q" | /work/llvm/build/bin/llvm-mc --triple aarch64 -mattr=+sme2
.text
Implement any new match types added!
UNREACHABLE executed at /work/llvm/llvm-project/llvm/lib/Target/AArch64/AsmParser/AArch64AsmParser.cpp:6767!
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
Stack dump:
0. Program arguments: /work/llvm/build/bin/llvm-mc --triple aarch64 -mattr=+sme2
#0 0x55a08a559aa7 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/work/llvm/build/bin/llvm-mc+0xe05aa7)
#1 0x55a08a5577be llvm::sys::RunSignalHandlers() (/work/llvm/build/bin/llvm-mc+0xe037be)
#2 0x55a08a55a3fa SignalHandler(int) Signals.cpp:0:0
#3 0x7f45f4a42520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520)
#4 0x7f45f4a969fc __pthread_kill_implementation ./nptl/pthread_kill.c:44:76
#5 0x7f45f4a969fc __pthread_kill_internal ./nptl/pthread_kill.c:78:10
#6 0x7f45f4a969fc pthread_kill ./nptl/pthread_kill.c:89:10
#7 0x7f45f4a42476 gsignal ./signal/../sysdeps/posix/raise.c:27:6
#8 0x7f45f4a287f3 abort ./stdlib/abort.c:81:7
#9 0x55a08a534601 (/work/llvm/build/bin/llvm-mc+0xde0601)
#10 0x55a08a334195 (anonymous namespace)::AArch64AsmParser::MatchAndEmitInstruction(llvm::SMLoc, unsigned int&, llvm::SmallVectorImpl>>&, llvm::MCStreamer&, unsigned long&, bool) AArch64AsmParser.cpp:0:0
#11 0x55a08a4feb5a (anonymous namespace)::AsmParser::parseAndMatchAndEmitTargetInstruction((anonymous namespace)::ParseStatementInfo&, llvm::StringRef, llvm::AsmToken, llvm::SMLoc) AsmParser.cpp:0:0
#12 0x55a08a4f1d6f (anonymous namespace)::AsmParser::parseStatement((anonymous namespace)::ParseStatementInfo&, llvm::MCAsmParserSemaCallback*) AsmParser.cpp:0:0
#13 0x55a08a4ea9e5 (anonymous namespace)::AsmParser::Run(bool, bool) AsmParser.cpp:0:0
#14 0x55a08a2cc51b AssembleInput(char const*, llvm::Target const*, llvm::SourceMgr&, llvm::MCContext&, llvm::MCStreamer&, llvm::MCAsmInfo&, llvm::MCSubtargetInfo&, llvm::MCInstrInfo&, llvm::MCTargetOptions const&) llvm-mc.cpp:0:0
#15 0x55a08a2cb2cd main (/work/llvm/build/bin/llvm-mc+0xb772cd)
#16 0x7f45f4a29d90 __libc_start_call_main ./csu/../sysdeps/nptl/libc_start_call_main.h:58:16
#17 0x7f45f4a29e40 call_init ./csu/../csu/libc-start.c:128:20
#18 0x7f45f4a29e40 __libc_start_main ./csu/../csu/libc-start.c:379:5
#19 0x55a08a2c6465 _start (/work/llvm/build/bin/llvm-mc+0xb72465)
fish: Process 441908, '/work/llvm/build/bin/llvm-mc' from job 1, 'echo "zip {z1.q-z2.q}, z0.q, z0…' terminated by signal SIGABRT (Abort)
```
The instruction is invalid because the first register in the curly brackets must be even-numbered, but this should be reported as an error, not a crash.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 65216 in oss-fuzz: llvm:llvm-opt-fuzzer--x86_64-loop_vectorize: ASSERT: Idx >= 0 && "Invalid basic block argument!"
Updates: Status: WontFix Comment #1 on issue 65216 by ClusterFuzz-External: llvm:llvm-opt-fuzzer--x86_64-loop_vectorize: ASSERT: Idx >= 0 && "Invalid basic block argument!" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=65216#c1 ClusterFuzz testcase 6677353610477568 is closed as invalid, so closing issue. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 43221 in oss-fuzz: llvm:clang-fuzzer: ASSERT: !isNull() && "Cannot retrieve a NULL type pointer"
Updates: Status: WontFix Comment #4 on issue 43221 by ClusterFuzz-External: llvm:clang-fuzzer: ASSERT: !isNull() && "Cannot retrieve a NULL type pointer" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=43221#c4 ClusterFuzz testcase 6631396272111616 is closed as invalid, so closing issue. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 51196 in oss-fuzz: llvm:clang-fuzzer: ASSERT: B > 0 && "Bit width can't be 0."
Updates: Status: WontFix Comment #2 on issue 51196 by ClusterFuzz-External: llvm:clang-fuzzer: ASSERT: B > 0 && "Bit width can't be 0." https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=51196#c2 ClusterFuzz testcase 6605178781958144 is closed as invalid, so closing issue. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 51229 in oss-fuzz: llvm:clang-fuzzer: Stack-overflow in clang::RecursiveASTVisitor::TraverseDecl
Updates: Status: WontFix Comment #2 on issue 51229 by ClusterFuzz-External: llvm:clang-fuzzer: Stack-overflow in clang::RecursiveASTVisitor::TraverseDecl https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=51229#c2 ClusterFuzz testcase 6594598375391232 is closed as invalid, so closing issue. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 65374 in oss-fuzz: llvm:llvm-yaml-parser-fuzzer: Stack-overflow in void llvm::yaml::skip
Updates: Status: WontFix Comment #1 on issue 65374 by ClusterFuzz-External: llvm:llvm-yaml-parser-fuzzer: Stack-overflow in void llvm::yaml::skip https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=65374#c1 ClusterFuzz testcase 6540028272508928 is closed as invalid, so closing issue. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 33042 in oss-fuzz: llvm:llvm-microsoft-demangle-fuzzer: Stack-overflow in llvm::ms_demangle::Demangler::parse
Updates: Status: WontFix Comment #4 on issue 33042 by ClusterFuzz-External: llvm:llvm-microsoft-demangle-fuzzer: Stack-overflow in llvm::ms_demangle::Demangler::parse https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=33042#c4 ClusterFuzz testcase 6527584180502528 is closed as invalid, so closing issue. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 64776 in oss-fuzz: llvm:llvm-opt-fuzzer--x86_64-loop_vectorize: Null-dereference READ in llvm::StructType::getTypeAtIndex
Updates: Status: WontFix Comment #1 on issue 64776 by ClusterFuzz-External: llvm:llvm-opt-fuzzer--x86_64-loop_vectorize: Null-dereference READ in llvm::StructType::getTypeAtIndex https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=64776#c1 ClusterFuzz testcase 6517670174130176 is closed as invalid, so closing issue. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 33328 in oss-fuzz: llvm:clang-objc-fuzzer: Stack-overflow in clang::Parser::SkipUntil
Updates: Status: WontFix Comment #4 on issue 33328 by ClusterFuzz-External: llvm:clang-objc-fuzzer: Stack-overflow in clang::Parser::SkipUntil https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=33328#c4 ClusterFuzz testcase 6441486293008384 is closed as invalid, so closing issue. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 64924 in oss-fuzz: llvm:llvm-isel-fuzzer--x86_64-O2: Abrt in llvm::llvm_unreachable_internal
Updates: Status: WontFix Comment #1 on issue 64924 by ClusterFuzz-External: llvm:llvm-isel-fuzzer--x86_64-O2: Abrt in llvm::llvm_unreachable_internal https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=64924#c1 ClusterFuzz testcase 6432838563790848 is closed as invalid, so closing issue. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 50278 in oss-fuzz: llvm:clang-fuzzer: Use-of-uninitialized-value in clang::TemplateName::getKind
Updates: Status: WontFix Comment #2 on issue 50278 by ClusterFuzz-External: llvm:clang-fuzzer: Use-of-uninitialized-value in clang::TemplateName::getKind https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=50278#c2 ClusterFuzz testcase 6249243525906432 is closed as invalid, so closing issue. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 65483 in oss-fuzz: llvm:llvm-isel-fuzzer--x86_64-O2: Unexpected-exit in llvm::LLVMContext::diagnose
Updates: Status: WontFix Comment #1 on issue 65483 by ClusterFuzz-External: llvm:llvm-isel-fuzzer--x86_64-O2: Unexpected-exit in llvm::LLVMContext::diagnose https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=65483#c1 ClusterFuzz testcase 6150347533910016 is closed as invalid, so closing issue. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 52015 in oss-fuzz: llvm:clang-fuzzer: Stack-overflow in clang::Parser::ParseDirectDeclarator
Updates: Status: WontFix Comment #2 on issue 52015 by ClusterFuzz-External: llvm:clang-fuzzer: Stack-overflow in clang::Parser::ParseDirectDeclarator https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=52015#c2 ClusterFuzz testcase 6031855258566656 is closed as invalid, so closing issue. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 20946 in oss-fuzz: llvm:clang-fuzzer: Null-dereference READ in GetFullTypeForDeclarator
Updates: Status: WontFix Comment #7 on issue 20946 by ClusterFuzz-External: llvm:clang-fuzzer: Null-dereference READ in GetFullTypeForDeclarator https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=20946#c7 ClusterFuzz testcase 5970362481508352 is closed as invalid, so closing issue. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 53447 in oss-fuzz: llvm:clang-fuzzer: Stack-overflow in clang::TypePropertyCache::ensure
Updates: Status: WontFix Comment #2 on issue 53447 by ClusterFuzz-External: llvm:clang-fuzzer: Stack-overflow in clang::TypePropertyCache::ensure https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=53447#c2 ClusterFuzz testcase 5903883046354944 is closed as invalid, so closing issue. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 26936 in oss-fuzz: llvm:clang-fuzzer: ASSERT: !isValueDependent() && "Expression evaluator can't be called on a dependent expr
Updates: Status: WontFix Comment #5 on issue 26936 by ClusterFuzz-External: llvm:clang-fuzzer: ASSERT: !isValueDependent() && "Expression evaluator can't be called on a dependent expr https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=26936#c5 ClusterFuzz testcase 5757580271681536 is closed as invalid, so closing issue. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 15924 in oss-fuzz: llvm/llvm-dwarfdump-fuzzer: ASSERT: !KeyInfoT::isEqual(Val, EmptyKey) && !KeyInfoT::isEqual(Val, TombstoneKey) && "E
Updates: Status: WontFix Comment #6 on issue 15924 by ClusterFuzz-External: llvm/llvm-dwarfdump-fuzzer: ASSERT: !KeyInfoT::isEqual(Val, EmptyKey) && !KeyInfoT::isEqual(Val, TombstoneKey) && "E https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=15924#c6 ClusterFuzz testcase 5750352378331136 is closed as invalid, so closing issue. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 20938 in oss-fuzz: llvm:clang-fuzzer: Null-dereference READ in processTypeAttrs
Updates: Status: WontFix Comment #7 on issue 20938 by ClusterFuzz-External: llvm:clang-fuzzer: Null-dereference READ in processTypeAttrs https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=20938#c7 ClusterFuzz testcase 5705616855400448 is closed as invalid, so closing issue. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 49199 in oss-fuzz: llvm:clang-fuzzer: Stack-overflow in clang::StmtVisitorBase::Visit
Updates: Status: WontFix Comment #3 on issue 49199 by ClusterFuzz-External: llvm:clang-fuzzer: Stack-overflow in clang::StmtVisitorBase::Visit https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=49199#c3 ClusterFuzz testcase 5566192374382592 is closed as invalid, so closing issue. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 64824 in oss-fuzz: llvm:llvm-isel-fuzzer--x86_64-O2: ASSERT: (VTy->isFirstClassType() || VTy->isVoidTy()) && "Cannot create non-first-class v
Updates: Status: WontFix Comment #1 on issue 64824 by ClusterFuzz-External: llvm:llvm-isel-fuzzer--x86_64-O2: ASSERT: (VTy->isFirstClassType() || VTy->isVoidTy()) && "Cannot create non-first-class v https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=64824#c1 ClusterFuzz testcase 5345559573299200 is closed as invalid, so closing issue. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 39058 in oss-fuzz: llvm:clang-fuzzer: ASSERT: !isNull() && "Cannot retrieve a NULL type pointer"
Updates: Status: WontFix Comment #4 on issue 39058 by ClusterFuzz-External: llvm:clang-fuzzer: ASSERT: !isNull() && "Cannot retrieve a NULL type pointer" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=39058#c4 ClusterFuzz testcase 5328159822708736 is closed as invalid, so closing issue. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 30308 in oss-fuzz: llvm:llvm-dwarfdump-fuzzer: Crash in llvm::DWARFUnitIndex::parseImpl
Updates: Status: WontFix Comment #5 on issue 30308 by ClusterFuzz-External: llvm:llvm-dwarfdump-fuzzer: Crash in llvm::DWARFUnitIndex::parseImpl https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=30308#c5 ClusterFuzz testcase 5289587515719680 is closed as invalid, so closing issue. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 65067 in oss-fuzz: llvm:llvm-isel-fuzzer--x86_64-O2: ASSERT: (getOperand(0)->getType()->isIntOrIntVectorTy() || getOperand(0)->getType()->isP
Updates: Status: WontFix Comment #1 on issue 65067 by ClusterFuzz-External: llvm:llvm-isel-fuzzer--x86_64-O2: ASSERT: (getOperand(0)->getType()->isIntOrIntVectorTy() || getOperand(0)->getType()->isP https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=65067#c1 ClusterFuzz testcase 5282853872861184 is closed as invalid, so closing issue. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 64706 in oss-fuzz: llvm:llvm-dwarfdump-fuzzer: Abrt in llvm::llvm_unreachable_internal
Updates: Status: WontFix Comment #1 on issue 64706 by ClusterFuzz-External: llvm:llvm-dwarfdump-fuzzer: Abrt in llvm::llvm_unreachable_internal https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=64706#c1 ClusterFuzz testcase 5207109557026816 is closed as invalid, so closing issue. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 26130 in oss-fuzz: llvm:clang-fuzzer: ASSERT: SS == getCurFunction()->SwitchStack.back().getPointer() && "switch stack missing
Updates: Status: WontFix Comment #5 on issue 26130 by ClusterFuzz-External: llvm:clang-fuzzer: ASSERT: SS == getCurFunction()->SwitchStack.back().getPointer() && "switch stack missing https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=26130#c5 ClusterFuzz testcase 5188216376000512 is closed as invalid, so closing issue. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 51257 in oss-fuzz: llvm:clang-fuzzer: ASSERT: DD && "queried property of class with no definition"
Updates: Status: WontFix Comment #2 on issue 51257 by ClusterFuzz-External: llvm:clang-fuzzer: ASSERT: DD && "queried property of class with no definition" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=51257#c2 ClusterFuzz testcase 5176200262713344 is closed as invalid, so closing issue. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 27444 in oss-fuzz: llvm:llvm-dwarfdump-fuzzer: Null-dereference READ in unsigned char llvm::DataExtractor::getU
Updates: Status: WontFix Comment #5 on issue 27444 by ClusterFuzz-External: llvm:llvm-dwarfdump-fuzzer: Null-dereference READ in unsigned char llvm::DataExtractor::getU https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=27444#c5 ClusterFuzz testcase 5162010651918336 is closed as invalid, so closing issue. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 25883 in oss-fuzz: llvm:clang-objc-fuzzer: ASSERT: D && !D->isInvalidDecl() && D->isThisDeclarationADefinition() && "Invalid interf
Updates: Status: WontFix Comment #5 on issue 25883 by ClusterFuzz-External: llvm:clang-objc-fuzzer: ASSERT: D && !D->isInvalidDecl() && D->isThisDeclarationADefinition() && "Invalid interf https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=25883#c5 ClusterFuzz testcase 5155506841452544 is closed as invalid, so closing issue. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 64819 in oss-fuzz: llvm:llvm-opt-fuzzer--x86_64-loop_vectorize: ASSERT: !(Rewrite.second).empty() && "Expected to find Predicates"
Updates: Status: WontFix Comment #1 on issue 64819 by ClusterFuzz-External: llvm:llvm-opt-fuzzer--x86_64-loop_vectorize: ASSERT: !(Rewrite.second).empty() && "Expected to find Predicates" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=64819#c1 ClusterFuzz testcase 5152493814022144 is closed as invalid, so closing issue. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 64844 in oss-fuzz: llvm:llvm-isel-fuzzer--wasm32-O2: ASSERT: MBB != &MF->front() && "Can't find reaching def for virtreg"
Updates: Status: WontFix Comment #1 on issue 64844 by ClusterFuzz-External: llvm:llvm-isel-fuzzer--wasm32-O2: ASSERT: MBB != &MF->front() && "Can't find reaching def for virtreg" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=64844#c1 ClusterFuzz testcase 5150786497413120 is closed as invalid, so closing issue. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
