[llvm-bugs] [Bug 53204] Warnings not triggered when function goes through macro rename (with -isystem).
Issue 53204 Summary Warnings not triggered when function goes through macro rename (with -isystem). Labels Assignees Reporter albestro Building our codebase we realized that the same kind of warning was triggered for CUSOLVER and not for CUBLAS. After a bit of investigation, we saw that **the problem is related to functions, defined in header files included with the option `-isystem`, whose name gets "translated" by a macro define**. For more details and a minimal reproducible example see https://github.com/eth-cscs/DLA-Future/pull/449#issuecomment-1012906903, but hoping to give a quick overview, next is reported the actual use-case with CUDA. ### Setup overview CUBLAS, differently from CUSOLVER, provides an header file `cublas_v2.h` that looks like this ```cpp #include "cublas_api.h" #define cublasDgemm cublasDgemm_v2 ``` and then in `cublas_api.h` there is the definition of the function ```cpp CUBLASAPI cublasStatus_t CUBLASWINAPI cublasDgemm_v2 (cublasHandle_t handle, //... ``` ### The problem Compiling with something like ```bash clang++ ... -isystem /usr/local/cuda/include -Wall ... ``` using directly `cublasDgemm_v2` warnings are triggered, while using the macro `cublasDgemm` they are not. On the opposite compiling with ```bash clang++ ... -I /usr/local/cuda/include -Wall ... ``` warnings are always triggered (i.e. with macro or direct call). I would say the expected result is to get the warnings also with the macro (this is also what happens with GCC). ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 53205] Performance regression since llvm 9 using pointers for array traversal
Issue 53205 Summary Performance regression since llvm 9 using pointers for array traversal Labels new issue Assignees Reporter outpaddling I wrote a simple benchmark using selection sort to compare performance of various compilers and interpreters: https://github.com/outpaddling/Lang-speed I noticed that clang 9 and later are much slower than clang 8 when using pointers to traverse the array. It is also much slower than the same program with subscripts. Clang 8 shows what I would expect, with pointers marginally faster than subscripts. I see this issue on both FreeBSD (clang9 and later) and MacOS (clang13), though on MacOS the pointer version takes only about 1.5x as long as subscripts. >From the run times shown below, it looks like clang stopped doing some optimizations beyond -O starting at version 9. I don't see anything in the v9 release notes about this type of optimization. [https://releases.llvm.org/9.0.0/docs/ReleaseNotes.html](https://releases.llvm.org/9.0.0/docs/ReleaseNotes.html) To reproduce: git clone https://github.com/outpaddling/Lang-speed.git cd Lang-speed ./clang-check ``` clang version 8.0.1 (tags/RELEASE_801/final) Target: x86_64-portbld-freebsd13.0 Thread model: posix InstalledDir: /usr/local/llvm80/bin -O Subscripts: 2.10 real 2.09 user 0.00 sys Pointers: 2.02 real 2.02 user 0.00 sys -O2 Subscripts: 2.11 real 2.11 user 0.00 sys Pointers: 2.02 real 2.02 user 0.00 sys -Ofast Subscripts: 2.36 real 2.35 user 0.00 sys Pointers: 2.23 real 2.22 user 0.00 sys clang version 9.0.1 Target: x86_64-portbld-freebsd13.0 Thread model: posix InstalledDir: /usr/local/llvm90/bin -O Subscripts: 2.24 real 2.23 user 0.00 sys Pointers: 4.67 real 4.67 user 0.00 sys -O2 Subscripts: 2.08 real 2.07 user 0.00 sys Pointers: 4.64 real 4.64 user 0.00 sys -Ofast Subscripts: 2.03 real 2.03 user 0.00 sys Pointers: 3.15 real 3.15 user 0.00 sys clang version 13.0.0 Target: x86_64-portbld-freebsd13.0 Thread model: posix InstalledDir: /usr/local/llvm13/bin -O Subscripts: 4.69 real 4.69 user 0.00 sys Pointers: 4.65 real 4.64 user 0.00 sys -O2 Subscripts: 2.10 real 2.10 user 0.00 sys Pointers: 4.81 real 4.80 user 0.00 sys -Ofast Subscripts: 2.13 real 2.13 user 0.00 sys Pointers: 4.74 real 4.73 user 0.00 sys ``` ___ 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 #67 on issue 27686 by ClusterFuzz-External: llvm: Fuzzing build failure https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=27686#c67 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-cd384dbf-11ff-492b-bf23-ae0469b73481.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 53206] Inliner asserts with cleanuppad
Issue
53206
Summary
Inliner asserts with cleanuppad
Labels
new issue
Assignees
Reporter
nikic
```
; RUN: opt -S -inline < %s
define void @foo() personality i32 (...)* undef {
entry:
br i1 false, label %join, label %split
split:; preds = %entry
br label %join
join: ; preds = %split, %entry
%phi = phi i64 [ 1, %split ], [ 0, %entry ]
%cmp = icmp ugt i64 1, %phi
br i1 %cmp, label %invoke1, label %exit
invoke1: ; preds = %join
invoke void undef()
to label %exit unwind label %cleanup1
cleanup1: ; preds = %invoke1
%pad1 = cleanuppad within none []
br label %cleanup1.cont
cleanup1.cont:; preds = %invoke2, %cleanup1
br i1 undef, label %cleanupret, label %invoke2
invoke2: ; preds = %cleanup1.cont
invoke void undef()
to label %cleanup1.cont unwind label %cleanup2
cleanup2: ; preds = %invoke2
%pad2 = cleanuppad within none []
br label %cleanupret
cleanupret: ; preds = %cleanup2, %cleanup1.cont
cleanupret from %pad1 unwind to caller
exit: ; preds = %invoke1, %join
ret void
}
define void @test() personality i32 (...)* undef {
invoke void @foo()
to label %exit unwind label %cleanup
exit: ; preds = %0
ret void
cleanup: ; preds = %0
%pad = cleanuppad within none []
cleanupret from %pad unwind to caller
}
```
Asserts:
```
opt: /home/npopov/repos/llvm-project/llvm/include/llvm/Support/Casting.h:255: std::enable_if_t<(! llvm::is_simple_type::value), typename llvm::cast_retty::ret_type> llvm::cast(const Y&) [with X = llvm::CleanupPadInst; Y = llvm::Use; std::enable_if_t<(! llvm::is_simple_type::value), typename llvm::cast_retty::ret_type> = llvm::CleanupPadInst*; typename llvm::cast_retty::ret_type = llvm::CleanupPadInst*]: Assertion `isa(Val) && "cast() argument of incompatible type!"' failed.
PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace.
Stack dump:
0. Program arguments: build/bin/opt -S -inline -debug-_only_=inline test064.ll
#0 0x0316a451 PrintStackTraceSignalHandler(void*) Signals.cpp:0:0
#1 0x03167c2e SignalHandler(int) Signals.cpp:0:0
#2 0x7ffabebb8750 __restore_rt (/lib64/libc.so.6+0x42750)
#3 0x7ffabec0584c __pthread_kill_implementation (/lib64/libc.so.6+0x8f84c)
#4 0x7ffabebb86a6 gsignal (/lib64/libc.so.6+0x426a6)
#5 0x7ffabeba27d3 abort (/lib64/libc.so.6+0x2c7d3)
#6 0x7ffabeba26fb _nl_load_domain.cold (/lib64/libc.so.6+0x2c6fb)
#7 0x7ffabebb1396 (/lib64/libc.so.6+0x3b396)
#8 0x03211cdf HandleInlinedEHPad(llvm::InvokeInst*, llvm::BasicBlock*, llvm::ClonedCodeInfo&) InlineFunction.cpp:0:0
#9 0x03217fd3 llvm::InlineFunction(llvm::CallBase&, llvm::InlineFunctionInfo&, llvm::AAResults*, bool, llvm::Function*) (build/bin/opt+0x3217fd3)
#10 0x02976948 llvm::InlinerPass::run(llvm::LazyCallGraph::SCC&, llvm::AnalysisManager&, llvm::LazyCallGraph&, llvm::CGSCCUpdateResult&) (build/bin/opt+0x2976948)
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 53207] [clang] "Transitive" deprecation diagnistic not emitted when coming from `-isystem`
Issue
53207
Summary
[clang] "Transitive" deprecation diagnistic not emitted when coming from `-isystem`
Labels
clang:frontend
Assignees
Reporter
LebedevRI
This has been brought up by [halide](https://github.com/halide/Halide) folk, it came up in https://github.com/halide/Halide/pull/6555.
Consider: https://godbolt.org/z/n8EaEsv4s
```c++
# 1 "include/header.hpp" 1 3
// include/header.hpp
template
struct Target {
Target(T d) {}
};
template <>
struct Target {
[[deprecated("...")]]
Target(int d) {}
};
template
struct Indirect : public Target {
Indirect(T d) : Target(d) {}
};
# 70 "include/header.hpp" 2
struct Example {
Indirect x{1};
Indirect y{1.0};
};
```
This does not emit any diags: https://godbolt.org/z/n8EaEsv4s
But if you use `-I`, you get: https://godbolt.org/z/bvs488n7v
```
:17:19: warning: 'Target' is deprecated: ... [-Wdeprecated-declarations]
Indirect(T d) : Target(d) {}
^
:22:18: note: in instantiation of member function 'Indirect::Indirect' requested here
Indirect x{1};
^
:11:5: note: 'Target' has been explicitly marked deprecated here
[[deprecated("...")]]
^
1 warning generated.
Compiler returned: 0
```
This particular case seems rather suboptimal.
While we could probably solve this easily with `-Walways-emit-deprecation-warnings` or something,
i'm wondering if this is a bug in the first place, or we can come up with some subset of cases that we could diagnose?
What do people think?
CC @AaronBallman @zygoloid @dwblaikie @alexreinking @steven-johnson
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 53208] An assertion failure in TurnSwitchRangeIntoICmp
Issue
53208
Summary
An assertion failure in TurnSwitchRangeIntoICmp
Labels
llvm:optimizations
Assignees
Reporter
kazutakahirata
The following test case triggers an assertion failure in `TurnSwitchRangeIntoICmp`.
For the assertion failure to occur, we must have `null` PHI arguments and `nonnull dereferenceable(4)`. I don't know how valid this combination is. The test case comes from the LLVM source code compiled with AutoFDO+ThinLTO. Presumably, some inlining is partly responsible for creating this strange combination because the crash does not occur with the baseline build without AutoFDO or ThinLTO.
```
$ reduced.ll
define void @0(i8 %sw, i32* %p0) {
switch i8 %sw, label %group3 [
i8 0, label %group1
i8 1, label %group1
i8 2, label %group1
i8 3, label %group1
i8 11, label %group1
i8 12, label %group1
i8 13, label %group1
i8 7, label %group1
i8 17, label %group1
i8 14, label %group1
i8 15, label %group1
i8 4, label %group2
i8 5, label %group2
i8 6, label %group2
i8 8, label %group2
i8 9, label %group2
i8 10, label %group2
]
group1:
br label %exit
group2:
br label %exit
group3:
br label %exit
exit:
%phi = phi i32* [ null, %group3 ], [ %p0, %group2 ], [ null, %group1 ]
call void @bar(i32* %phi)
ret void
}
declare void @bar(i32* nonnull dereferenceable(4))
$ ~/rel/bin/clang -O1 -c reduced.ll
warning: overriding the module target triple with x86_64-unknown-linux-gnu [-Woverride-module]
clang: /home/kazu/llvm-project/llvm/lib/Transforms/Utils/SimplifyCFG.cpp:4850: bool (anonymous namespace)::SimplifyCFGOpt::TurnSwitchRangeIntoICmp(llvm::SwitchInst *, IRBuilder<> &): Assertion `DestA && DestB && "Single-destination switch should have been folded."' 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/kazu/rel/bin/clang -O1 -c reduced.ll
1. Optimizer
#0 0x7fdd94cfcb73 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/home/kazu/rel/bin/../lib/libLLVMSupport.so.14git+0x1b6b73)
#1 0x7fdd94cfa94e llvm::sys::RunSignalHandlers() (/home/kazu/rel/bin/../lib/libLLVMSupport.so.14git+0x1b494e)
#2 0x7fdd94c18ef3 (anonymous namespace)::CrashRecoveryContextImpl::HandleCrash(int, unsigned long) CrashRecoveryContext.cpp:0:0
#3 0x7fdd94c1909e CrashRecoverySignalHandler(int) CrashRecoveryContext.cpp:0:0
#4 0x7fdd98a43200 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x13200)
#5 0x7fdd94650891 raise ./signal/../sysdeps/unix/sysv/linux/raise.c:50:1
#6 0x7fdd9463a536 abort ./stdlib/abort.c:81:7
#7 0x7fdd9463a41f get_sysdep_segment_value ./intl/loadmsgcat.c:509:8
#8 0x7fdd9463a41f _nl_load_domain ./intl/loadmsgcat.c:970:34
#9 0x7fdd94649212 (/lib/x86_64-linux-gnu/libc.so.6+0x35212)
#10 0x7fdd963c7d66 (anonymous namespace)::SimplifyCFGOpt::simplifySwitch(llvm::SwitchInst*, llvm::IRBuilder&) SimplifyCFG.cpp:0:0
#11 0x7fdd963b98d6 (anonymous namespace)::SimplifyCFGOpt::run(llvm::BasicBlock*) SimplifyCFG.cpp:0:0
#12 0x7fdd963b8554 llvm::simplifyCFG(llvm::BasicBlock*, llvm::TargetTransformInfo const&, llvm::DomTreeUpdater*, llvm::SimplifyCFGOptions const&, llvm::ArrayRef) (/home/kazu/rel/bin/../lib/libLLVMTransformUtils.so.14git+0x1be554)
#13 0x7fdd969d20ea iterativelySimplifyCFG(llvm::Function&, llvm::TargetTransformInfo const&, llvm::DomTreeUpdater*, llvm::SimplifyCFGOptions const&) SimplifyCFGPass.cpp:0:0
#14 0x7fdd969d1b10 simplifyFunctionCFGImpl(llvm::Function&, llvm::TargetTransformInfo const&, llvm::DominatorTree*, llvm::SimplifyCFGOptions const&) SimplifyCFGPass.cpp:0:0
#15 0x7fdd969d06cd simplifyFunctionCFG(llvm::Function&, llvm::TargetTransformInfo const&, llvm::DominatorTree*, llvm::SimplifyCFGOptions const&) SimplifyCFGPass.cpp:0:0
#16 0x7fdd969d043e llvm::SimplifyCFGPass::run(llvm::Function&, llvm::AnalysisManager&) (/home/kazu/rel/bin/../lib/libLLVMScalarOpts.so.14git+0x33943e)
#17 0x7fdd9372917d llvm::detail::PassModel >::run(llvm::Function&, llvm::AnalysisManager&) (/home/kazu/rel/bin/../lib/../lib/libLLVMPasses.so.14git+0x10717d)
#18 0x7fdd957b83e1 llvm::PassManager >::run(llvm::Function&, llvm::AnalysisManager&) (/home/kazu/rel/bin/../lib/libLLVMCore.so.14git+0x2863e1)
#19 0x7fdd9835fc2d llvm::detail::PassModel >, llvm::PreservedAnalyses, llvm::AnalysisManager >::run(llvm::Function&, llvm::AnalysisManager&) (/home/kazu/rel/bin/../lib/libclangCodeGen.so.14git+0xe7c2d)
#20 0x7fdd957bd07b llvm::ModuleToFunctionPassAdaptor::run(llvm::Module&, llvm::AnalysisManager&) (/home/kazu/rel/bin/../lib/libLLVMCore.so.14git+0x28b07b)
#21 0x7fdd98361d2d llvm::detail::PassMode
[llvm-bugs] [Bug 53210] Missing optimization oportunity for vectorized comparison
Issue
53210
Summary
Missing optimization oportunity for vectorized comparison
Labels
new issue
Assignees
Reporter
roman-zelenyi
LLVM does not do any vectorization in cases like below.
GCC does better job here.
```
auto foo(unsigned const * __restrict in, unsigned const *__restrict sel, unsigned *__restrict out)
{
for (int i = 0; i < 8; ++i)
{
out[i] = sel[i] == 0 ? in[i] : sel[i];
}
}
```
[Godbolt link](https://gcc.godbolt.org/z/bc9vGeE1Y).
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 53211] please cherry-pick msan build fixes b4fb42300e39c99ac5bb9d02b304b713fabdec4d
Issue 53211 Summary please cherry-pick msan build fixes b4fb42300e39c99ac5bb9d02b304b713fabdec4d Labels new issue Assignees Reporter brooksdavis The cherry-pick of 4e1a6c07052b466a2a1cd0c3ff150e4e89a6d87a in b40f07b048c40b340e4bf87e53dc134847b78205 broke msan on non-Linux systems. The fix is to cherry-pick b4fb42300e39c99ac5bb9d02b304b713fabdec4d (verified by hand application to a local tree). ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 53212] clang-format 13.0.0: LambdaBodyIndentation: OuterScope closing brace & parenthesis too indented
Issue
53212
Summary
clang-format 13.0.0: LambdaBodyIndentation: OuterScope closing brace & parenthesis too indented
Labels
new issue
Assignees
Reporter
mikezackles
Hello! I've put a minimal reproduction [here](https://github.com/mikezackles/clang-format-lambda-bug)
The relevant output is something like
```c++
some_function(
a_really_long_name, another_long_name, a_third_long_name,
[&](LineCallback line_callback) {
int a;
int b;
}); // <- This is hanging in the middle of nowhere :)
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 53213] Assertion failure in recursive concept instantiation
Issue
53213
Summary
Assertion failure in recursive concept instantiation
Labels
new issue
Assignees
Reporter
davidstone
The following invalid translation unit
```
template
concept c = requires(T t) { f(t); };
auto f(c auto);
void g() {
f(0);
}
```
causes an assertion failure in clang with the message
```
clang++: /root/llvm-project/llvm/include/llvm/ADT/FoldingSet.h:479: void llvm::FoldingSetImpl::InsertNode(T*) [with Derived = llvm::ContextualFoldingSet; T = clang::ConstraintSatisfaction]: Assertion `Inserted == N && "Node already inserted!"' 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: /opt/compiler-explorer/clang-assertions-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
1. :7:5: current parser token ')'
2. :6:10: parsing function body 'g'
3. :6:10: in compound statement ('{}')
#0 0x5565c6c4c7cf PrintStackTraceSignalHandler(void*) Signals.cpp:0:0
#1 0x5565c6c4a5d0 llvm::sys::CleanupOnSignal(unsigned long) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x3a4a5d0)
#2 0x5565c6b83658 CrashRecoverySignalHandler(int) CrashRecoveryContext.cpp:0:0
#3 0x7ff05aad93c0 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x153c0)
#4 0x7ff05a5a818b raise (/lib/x86_64-linux-gnu/libc.so.6+0x4618b)
#5 0x7ff05a587859 abort (/lib/x86_64-linux-gnu/libc.so.6+0x25859)
#6 0x7ff05a587729 (/lib/x86_64-linux-gnu/libc.so.6+0x25729)
#7 0x7ff05a598f36 (/lib/x86_64-linux-gnu/libc.so.6+0x36f36)
#8 0x5565c8d52288 clang::Sema::CheckConstraintSatisfaction(clang::NamedDecl const*, llvm::ArrayRef, llvm::ArrayRef, clang::SourceRange, clang::ConstraintSatisfaction&) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x5b52288)
#9 0x5565c926504d clang::Sema::CheckConceptTemplateId(clang::CXXScopeSpec const&, clang::SourceLocation, clang::DeclarationNameInfo const&, clang::NamedDecl*, clang::ConceptDecl*, clang::TemplateArgumentListInfo const*) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x606504d)
#10 0x5565c936c16c clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformConceptSpecializationExpr(clang::ConceptSpecializationExpr*) SemaTemplateInstantiate.cpp:0:0
#11 0x5565c9353f5e clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformExpr(clang::Expr*) SemaTemplateInstantiate.cpp:0:0
#12 0x5565c938642f clang::Sema::SubstExpr(clang::Expr*, clang::MultiLevelTemplateArgumentList const&) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x618642f)
#13 0x5565c8d50b71 calculateConstraintSatisfaction(clang::Sema&, clang::NamedDecl const*, llvm::ArrayRef, clang::SourceLocation, clang::MultiLevelTemplateArgumentList&, clang::Expr const*, clang::ConstraintSatisfaction&)::'lambda'(clang::Expr const*)::operator()(clang::Expr const*) const SemaConcept.cpp:0:0
#14 0x5565c8d51ed0 bool calculateConstraintSatisfaction, clang::SourceLocation, clang::MultiLevelTemplateArgumentList&, clang::Expr const*, clang::ConstraintSatisfaction&)::'lambda'(clang::Expr const*)>(clang::Sema&, clang::Expr const*, clang::ConstraintSatisfaction&, calculateConstraintSatisfaction(clang::Sema&, clang::NamedDecl const*, llvm::ArrayRef, clang::SourceLocation, clang::MultiLevelTemplateArgumentList&, clang::Expr const*, clang::ConstraintSatisfaction&)::'lambda'(clang::Expr const*)&&) SemaConcept.cpp:0:0
#15 0x5565c8d5269a clang::Sema::CheckConstraintSatisfaction(clang::NamedDecl const*, llvm::ArrayRef, llvm::ArrayRef, clang::SourceRange, clang::ConstraintSatisfaction&) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x5b5269a)
#16 0x5565c938d23d clang::Sema::CheckInstantiatedFunctionTemplateConstraints(clang::SourceLocation, clang::FunctionDecl*, llvm::ArrayRef, clang::ConstraintSatisfaction&) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x618d23d)
#17 0x5565c932434a clang::Sema::FinishTemplateArgumentDeduction(clang::FunctionTemplateDecl*, llvm::SmallVectorImpl&, unsigned int, clang::FunctionDecl*&, clang::sema::TemplateDeductionInfo&, llvm::SmallVectorImpl const*, bool, llvm::function_ref) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x612434a)
#18 0x5565c93251ae void llvm::function_ref::callback_fn, clang::FunctionDecl*&, clang::sema::TemplateDeductionInfo&, bool, llvm::function_ref)>)::'lambda1'()>(long) SemaTemplateDeduction.cpp:0:0
#19 0x5565c8c523ef clang::Sema::runWithSufficientStackSpace(clang::SourceLocation, llvm::function_ref) (/opt/compiler-explorer/clang-assert
[llvm-bugs] [Bug 53214] clang::Preprocessor::RemoveTopOfLexerStack has conflicting documentation
Issue 53214 Summary clang::Preprocessor::RemoveTopOfLexerStack has conflicting documentation Labels Assignees Reporter TestingPlant Currently, the documentation for [clang::Preprocessor::RemoveTopOfLexerStack](https://clang.llvm.org/doxygen/classclang_1_1Preprocessor.html#ad01e74ced3ad54db449f6c509cab3cf2) says: > This should only be used in situations where the current state of the top-of-stack lexer is known. > This should only be used in situations where the current state of the top-of-stack lexer is unknown. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 53215] Assertion failures in clang direct people to Bugzilla instead of GitHub
Issue 53215 Summary Assertion failures in clang direct people to Bugzilla instead of GitHub Labels Assignees Reporter davidstone "PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace, preprocessed source, and associated run script." should be changed to https://github.com/llvm/llvm-project/issues/ ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
