[llvm-bugs] [Bug 43360] [meta] 9.0.1 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=43360 Bug 43360 depends on bug 44269, which changed state. Bug 44269 Summary: please backport https://reviews.llvm.org/D71302 to 9.x https://bugs.llvm.org/show_bug.cgi?id=44269 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 44269] please backport https://reviews.llvm.org/D71302 to 9.x
https://bugs.llvm.org/show_bug.cgi?id=44269 Tom Stellard changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #1 from Tom Stellard --- Sorry, we've already passed the deadline for backport requests, so this won't make it in. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 44268] Assertion `is() && "Invalid accessor called"' failed.
https://bugs.llvm.org/show_bug.cgi?id=44268
Richard Smith changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #2 from Richard Smith ---
Reduced to:
int b(void *c) __attribute__((enable_if(__builtin_object_size(c, 0), "")));
int a = b(new int);
or:
constexpr int f() {
void *c = new int;
return __builtin_object_size(c, 0);
}
Fixed in llvmorg-10-init-11960-gc5b890e9224
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 44295] Crash in CStringChecker
https://bugs.llvm.org/show_bug.cgi?id=44295 Artem Dergachev changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Artem Dergachev --- Thanks, fixed in f450dd63a14d! -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 44300] New: Bad source/line debug information for one address in Chrome
https://bugs.llvm.org/show_bug.cgi?id=44300 Bug ID: 44300 Summary: Bad source/line debug information for one address in Chrome Product: clang Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: C++ Assignee: unassignedclangb...@nondot.org Reporter: brucedaw...@chromium.org CC: blitzrak...@gmail.com, dgre...@apple.com, erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk In crash/df2293b94ced16ae on the main thread (not the thread that crashed) most of the stack entries lead to the correct source code but the entry for > chrome_child.dll!ChromeMain does not. In the windbg "kc" output this is the function between ContentMain and Launch: 09 chrome_child!content::ContentMain 0a chrome_child!ChromeMain 0b chrome!MainDllLoader::Launch To see the behavior you have to have symbol server enabled (of course) and also source indexing. This lets VS or windbg download the source code, which it does for all other functions on the stack. In fact the debuggers download chrome_main.cc but then refuse to use it. The VS source search information says: Locating source for 'c:\b\s\w\ir\cache\builder\src\chrome\app\chrome_main.cc'. (No checksum.) The file 'c:\b\s\w\ir\cache\builder\src\chrome\app\chrome_main.cc' does not exist. Looking in script documents for 'c:\b\s\w\ir\cache\builder\src\chrome\app\chrome_main.cc'... The debugger found source in the following locations: 1: c:\src\chromium3\src\chrome\app\chrome_main.cc (No checksum.) 2: C:\ProgramData\dbg\src\chrome\app\chrome_main.cc\6f041b45cf25952a5892abd8f0211373572fa48c\chrome_main.cc (No checksum.) The debugger will use the source at location 1. This sounds familiar but I can't tell what is going on. I don't know how VS found the source code that windbg downloaded, why it didn't find the source code that it downloaded, and why it decided to use the repo copy of the source code which is almost certainly wrong. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 43908] constexpr and __declspec(property(...))) don't work together
https://bugs.llvm.org/show_bug.cgi?id=43908 Richard Smith changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Richard Smith --- Yes, that patch added support for constant evaluation of PseudoObjectExprs for a completely different reason. But nonetheless, the support is there now :) -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 44299] New: Unsupported value of LLVM_USE_SANITIZER: Address; Undefined
https://bugs.llvm.org/show_bug.cgi?id=44299 Bug ID: 44299 Summary: Unsupported value of LLVM_USE_SANITIZER: Address;Undefined Product: libc++ Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: All Bugs Assignee: unassignedclangb...@nondot.org Reporter: da...@doublewise.net CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com https://llvm.org/docs/CMake.html state "Possible values are Address, Memory, MemoryWithOrigins, Undefined, Thread, and Address;Undefined." libcxx refuses to allow "Address;Undefined" as an option. CMake Warning at /home/david/llvm-concepts/libcxx/CMakeLists.txt:696 (message): Unsupported value of LLVM_USE_SANITIZER: Address;Undefined Call Stack (most recent call first): /home/david/llvm-concepts/libcxx/CMakeLists.txt:710 (get_sanitizer_flags) This combination should be allowed. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40253] combined target teams implements shared clause as firstprivate
https://bugs.llvm.org/show_bug.cgi?id=40253 Alexey Bataev changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #1 from Alexey Bataev --- It was already fixed. *** This bug has been marked as a duplicate of bug 43175 *** -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 44298] New: ELF symbol size for CFI vtable seems incorrect.
https://bugs.llvm.org/show_bug.cgi?id=44298 Bug ID: 44298 Summary: ELF symbol size for CFI vtable seems incorrect. Product: clang Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: LLVM Codegen Assignee: unassignedclangb...@nondot.org Reporter: netforc...@gmail.com CC: llvm-bugs@lists.llvm.org, neeil...@live.com, richard-l...@metafoo.co.uk Hello, It seems the symbols for CFI vtables could get incorrect sizes. For each vtable entries, instead of the actual size of the stub, it seems the total size of the vtable is being used. We could reproduce it with simple example. $ cd `mktemp -d` $ git clone https://github.com/trailofbits/clang-cfi-showcase $ cd clang-cfi-showcase/ $ clang -g -flto -fsanitize=cfi -fvisibility=default cfi_icall.c $ objdump -dS a.out ... 00401478 : 401478: e9 83 fe ff ff jmpq 401300 40147d: cc int3 40147e: cc int3 40147f: cc int3 00401480 : 401480: e9 bb fe ff ff jmpq 401340 401485: cc int3 401486: cc int3 401487: cc int3 00401488 : 401488: e9 53 ff ff ff jmpq 4013e0 40148d: cc int3 40148e: cc int3 40148f: cc int3 ... $ readelf -sW a.out Num:Value Size TypeBind Vis Ndx Name ... 43: 0040148024 FUNCLOCAL DEFAULT 13 bad_int_arg ... 47: 0040147824 FUNCLOCAL DEFAULT 13 int_arg ... 49: 0040148824 FUNCLOCAL DEFAULT 13 not_entry_point ... This makes the symbols in the vtable overlap. To generate AutoFDO profile, we have some tool list all symbols for a list of addresses, and this many overlapping symbols cause our tool OOM. We believe the same issue was noticed by Chrome folks too: https://bugs.chromium.org/p/chromium/issues/detail?id=947114 Could you take a look if more accurate symbol sizes can be given? Thank you in advance, HK -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 44297] New: --stack-first should be the default WASM memory layout
https://bugs.llvm.org/show_bug.cgi?id=44297 Bug ID: 44297 Summary: --stack-first should be the default WASM memory layout Product: lld Version: unspecified Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: wasm Assignee: unassignedb...@nondot.org Reporter: bhol...@mozilla.com CC: llvm-bugs@lists.llvm.org, s...@chromium.org At present, lldb defaults to locating global variables first in linear memory, followed by the stack. This improves code-size by reducing the size of instructions which load globals via constant offset, since smaller constants can be represented with fewer bits. However, it also means that stack overflows will clobber those globals before wrapping past address zero and faulting. lld offers the --stack-first option, which rustc adopted [1] after struggling with inexplicable memory corruption caused by stack overflows. I think this should probably be the default, so that clang inherits the same behavior. Given that stack overflows in native code generally fault rather than triggering memory corruption, C/C++ developers tend not to work very hard to ensure they never happen. [1] https://github.com/rust-lang/rust/blob/d825e35ee8325146e6c175a4c61bcb645b347d5e/src/librustc_target/spec/wasm32_base.rs#L25 -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 44296] New: Catch assigning to const object in ubsan
https://bugs.llvm.org/show_bug.cgi?id=44296
Bug ID: 44296
Summary: Catch assigning to const object in ubsan
Product: new-bugs
Version: 9.0
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: anoye...@gmail.com
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org
$ clang++ --version
clang version 9.0.0 (tags/RELEASE_900/final)
Target: x86_64-apple-darwin19.2.0
Thread model: posix
InstalledDir: /usr/local/opt/llvm/bin
$ cat test.cc
int main(int argc, char** argv) {
const int x = 0;
const_cast(x) = 1;
return x;
}
$ clang++ -fsanitize=undefined test.cc
$ ./a.out
According to https://en.cppreference.com/w/cpp/language/const_cast this invokes
undefined behavior. I was hoping ubsan would complain, but it did not.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 44284] [regression] const llvm::MCExpr *llvm::MCSymbol::getVariableValue(bool) const: Assertion `isVariable() && "Invalid accessor!"' failed.
https://bugs.llvm.org/show_bug.cgi?id=44284 Fangrui Song changed: What|Removed |Added Status|CONFIRMED |RESOLVED Assignee|unassignedb...@nondot.org |i...@maskray.me Fixed By Commit(s)||f99eedeb72644671cd584f48e4c ||136d47f6b0020 Resolution|--- |FIXED --- Comment #4 from Fangrui Song --- Fixed by D71443/commit f99eedeb72644671cd584f48e4c136d47f6b0020. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 44295] New: Crash in CStringChecker
https://bugs.llvm.org/show_bug.cgi?id=44295 Bug ID: 44295 Summary: Crash in CStringChecker Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Static Analyzer Assignee: dcough...@apple.com Reporter: xazax@gmail.com CC: dcough...@apple.com, llvm-bugs@lists.llvm.org Created attachment 22934 --> https://bugs.llvm.org/attachment.cgi?id=22934&action=edit Preprocessed file for reproducing the crash. This is the stacktrace: #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 #1 0x7708d8ad in __GI_abort () at abort.c:79 #2 0x7708d77f in __assert_fail_base (fmt=0x771efbc0 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x30 "hasVal", file=0x341355 "/usr/local/google/home/xazax/LLVM/llvm/include/llvm/ADT/Optional.h", line=173, function=) at assert.c:92 #3 0x7709b542 in __GI___assert_fail (assertion=0x30 "hasVal", file=0x341355 "/usr/local/google/home/xazax/LLVM/llvm/include/llvm/ADT/Optional.h", line=173, function=0x598ff5 "T &llvm::optional_detail::OptionalStorage::getValue() & [T = clang::ento::NonLoc]") at assert.c:101 #4 0x036be8ed in (anonymous namespace)::CStringChecker::evalStrcpyCommon (this=, C=..., CE=0x4e05e70, ReturnEnd=false, IsBounded=true, appendK=(anonymous namespace)::ConcatFnKind::strlcat, returnPtr=) at clang/include/clang/StaticAnalyzer/Core/PathSensitive/SVals.h:104 #5 0x036b657b in (anonymous namespace)::CStringChecker::evalStrlcat (this=0x2, C=..., CE=0x0) at clang/lib/StaticAnalyzer/Checkers/CStringChecker.cpp:1527 #6 0x036c11f2 in (anonymous namespace)::CStringChecker::evalCall (this=, Call=..., C=...) at clang/lib/StaticAnalyzer/Checkers/CStringChecker.cpp:2297 #7 clang::ento::eval::Call::_evalCall<(anonymous namespace)::CStringChecker> (checker=, Call=..., C=...) at clang/include/clang/StaticAnalyzer/Core/Checker.h:479 #8 0x0392d9b3 in clang::ento::CheckerFn::operator()(clang::ento::CallEvent const&, clang::ento::CheckerContext&) const (this=, ps=..., ps=...) at clang/include/clang/StaticAnalyzer/Core/CheckerManager.h:69 #9 clang::ento::CheckerManager::runCheckersForEvalCall (this=0x4ce6da0, Dst=..., Src=..., Call=..., Eng=...) at clang/lib/StaticAnalyzer/Core/CheckerManager.cpp:674 #10 0x0396a09e in clang::ento::ExprEngine::evalCall (this=0x7fffae98, Dst=..., Pred=, Call=...) at clang/lib/StaticAnalyzer/Core/ExprEngineCallAndReturn.cpp:587 #11 0x03969e24 in clang::ento::ExprEngine::VisitCallExpr (this=0x7fffae98, CE=0x4e05e70, Pred=, dst=...) at clang/lib/StaticAnalyzer/Core/ExprEngineCallAndReturn.cpp:514 #12 0x03949fec in clang::ento::ExprEngine::Visit (this=0x7fffae98, S=0x4e05e70, Pred=0x4ecfdc8, DstTop=...) at clang/lib/StaticAnalyzer/Core/ExprEngine.cpp:1603 #13 0x039465a4 in clang::ento::ExprEngine::ProcessStmt (this=0x7fffae98, currStmt=, Pred=) at clang/lib/StaticAnalyzer/Core/ExprEngine.cpp:791 #14 0x039461f9 in clang::ento::ExprEngine::processCFGElement (this=0x7fffae98, E=..., Pred=0x4ed0110, StmtIdx=11, Ctx=0x7fffacb0) at clang/lib/StaticAnalyzer/Core/ExprEngine.cpp:637 #15 0x03933b41 in clang::ento::CoreEngine::HandlePostStmt (this=, B=, StmtIdx=0, Pred=0x770a2cfb <__GI_raise+267>) at clang/lib/StaticAnalyzer/Core/CoreEngine.cpp:467 #16 0x03932bc9 in clang::ento::CoreEngine::ExecuteWorkList (this=0x7fffaeb8, L=, Steps=218621, InitState=...) at clang/lib/StaticAnalyzer/Core/CoreEngine.cpp:148 #17 0x0368dced in clang::ento::ExprEngine::ExecuteWorkList (this=0x7fffae98, L=0x0, Steps=0) at clang/include/clang/StaticAnalyzer/Core/PathSensitive/ExprEngine.h:168 #18 (anonymous namespace)::AnalysisConsumer::RunPathSensitiveChecks (this=0x4ce6710, D=0x4df7ba8, IMode=clang::ento::ExprEngine::Inline_Regular, VisitedCallees=0x7fffb200) at clang/lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp:818 #19 (anonymous namespace)::AnalysisConsumer::HandleCode (this=0x4ce6710, D=0x4df7ba8, Mode=2, IMode=clang::ento::ExprEngine::Inline_Regular, VisitedCallees=) at clang/lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp:791 #20 0x03670457 in (anonymous namespace)::AnalysisConsumer::HandleDeclsCallGraph (this=0x4ce6710, LocalTUDeclsSize=) at clang/lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp:580 #21 (anonymous namespace)::AnalysisConsumer::runAnalysisOnTranslationUnit (this=0x4ce6710, C=...) at clang/lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp:631 #22 (anonymous namespace)::AnalysisConsumer::HandleTranslationUnit (this=0x4ce6710, C=...) at clang/lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp:661 #23 0x039e6e93 in clang::ParseAST (S=..., PrintStats=, SkipFunctionBodies=) at clang/lib/Parse/ParseAST.cpp:171 #24 0x02fbccd1 in clang::Fron
[llvm-bugs] Issue 17578 in oss-fuzz: llvm:clang-fuzzer: ASSERT: RHS.U.VAL != 0 && "Divide by zero?"
Updates: Labels: Deadline-Approaching Comment #2 on issue 17578 by sheriff...@chromium.org: llvm:clang-fuzzer: ASSERT: RHS.U.VAL != 0 && "Divide by zero?" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=17578#c2 This bug is approaching its deadline for being fixed, and will be automatically derestricted within 7 days. If a fix is planned within 2 weeks after the deadline has passed, a grace extension can be granted. - Your friendly Sheriffbot -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 44294] New: The address space is not printed correctly in function parameters
https://bugs.llvm.org/show_bug.cgi?id=44294
Bug ID: 44294
Summary: The address space is not printed correctly in function
parameters
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: OpenCL
Assignee: unassignedclangb...@nondot.org
Reporter: anastasia.stul...@arm.com
CC: anastasia.stul...@arm.com, llvm-bugs@lists.llvm.org
Clang looses information about address space of function parameters in some
cases. See examples from review:
https://reviews.llvm.org/D71272#inline-646266
void myRead(read_only image1d_t);
typedef write_only image1d_t img1d_wo;
kernel void k1(img1d_wo img) {
myRead(img); // expected-error {{passing '__private img1d_wo' (aka '__private
__write_only image1d_t') to parameter of incompatible type '__read_only
image1d_t'}}
}
or
void f_gen(__generic int *arg_gen) {}
void f(){
__constant int *var_sub;
f_gen(var_sub); // expected-error {{passing '__constant int *__private' to
parameter of type '__generic int *' changes address space of pointer}}
}
'__private' is not printed in the second type in both cases.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 44293] New: weird InstantiateFunction timings with PCH
https://bugs.llvm.org/show_bug.cgi?id=44293
Bug ID: 44293
Summary: weird InstantiateFunction timings with PCH
Product: clang
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Keywords: slow-compile
Severity: normal
Priority: P
Component: Frontend
Assignee: unassignedclangb...@nondot.org
Reporter: tras...@gmail.com
CC: llvm-bugs@lists.llvm.org, neeil...@live.com,
richard-l...@metafoo.co.uk
I tested -ftime-trace on a minimal Catch2 setup on Windows (VS2019 Preview):
https://github.com/Trass3r/catch2test
set CC=clang
set CXX=clang++
cmake -G Ninja ..
When using PCH it mostly spends time instantiating functions in test.cpp of
course.
Oddly it reports most time (over 60ms) is spent on
std::_Hash_representation which simply forwards to _Fnv1a_append_value
which only takes less than 1 ms:
{"pid":1,"tid":0,"ph":"X","ts":128232,"dur":689,"name":"InstantiateFunction","args":{"detail":"std::_Fnv1a_append_value"}},{"pid":1,"tid":0,"ph":"X","ts":65113,"dur":63810,"name":"InstantiateFunction","args":{"detail":"std::_Hash_representation"}},
Without PCH it needs 400 us:
{"pid":1,"tid":0,"ph":"X","ts":869250,"dur":239,"name":"InstantiateFunction","args":{"detail":"std::_Fnv1a_append_value"}},{"pid":1,"tid":0,"ph":"X","ts":869082,"dur":409,"name":"InstantiateFunction","args":{"detail":"std::_Hash_representation"}},
Maybe the timings are skewed by some PCH reading?
At least it is misleading when you are looking for optimization opportunities
and it points you at the wrong location.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 44292] New: Parser crash
https://bugs.llvm.org/show_bug.cgi?id=44292
Bug ID: 44292
Summary: Parser crash
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: w1rpujqxs5d0srw18wks6ez4hko...@cmx.ietfng.org
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
This fragment of a program
// RUN: %clang_cc1 -triple powerpc64le-unknown-linux-gnu -disable-free
-main-file-name OutputSections.cpp -fmath-errno -masm-verbose -U NDEBUG
-pedantic -fdeprecated-macro -ferror-limit 19 -fmessage-length 0
-fvisibility-inlines-hidden -fno-signed-char -fobjc-runtime=gcc
-fdiagnostics-show-option -fcolor-diagnostics -o - -emit-llvm -O0
-Wimplicit-int %s
template class a;
b() { a< char >::append(
is, of course, invalid, but triggers after diagnostic reporting:
clang: /cheri/source/llvm-project/clang/lib/Parse/ParseExprCXX.cpp:585:
clang::ExprResult clang::Parser::tryParseCXXIdExpression(clang::CXXScopeSpec &,
bool, clang::Token &): Assertion `SS.isEmpty() && "undeclared non-type
annotation should be unqualified"' failed.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 44291] New: Possible inconsistency with parameter packs in both deductible and non-deductible contexts
https://bugs.llvm.org/show_bug.cgi?id=44291
Bug ID: 44291
Summary: Possible inconsistency with parameter packs in both
deductible and non-deductible contexts
Product: clang
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: pierre.landr...@web.de
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
Code snippet:
**
template
struct Identity
{
using type = T;
};
template
using IdentityType = typename Identity::type;
template
int extraArgAfterPack(
int (* const func)(TArgs...),
IdentityType... nonDeducibleArgs,
int extraArg)
{
return (*func)(nonDeducibleArgs...) + extraArg;
}
template
int extraArgBeforePack(
int (* const func)(TArgs...),
int extraArg,
IdentityType... nonDeducibleArgs)
{
return (*func)(nonDeducibleArgs...) + extraArg;
}
int f(const int& i)
{
return i;
}
int main()
{
return extraArgAfterPack(&f, 22, 20); // (1) Fails to compile
//return extraArgAfterPack(&f, 22, 20); // (2) Compiles
//return extraArgBeforePack(&f, 20, 22);// (3) Compiles
}
**
Item (1) of the preceeding code fails to compile under clang 4.0.0 onwards (it
compiles in lower versions, however). I suppose, this has to do with:
"when a function parameter pack appears in a non-deduced context (14.8.2.5),
the type of that parameter pack is never deduced."
In each function signature, the parameter pack appears both in a deductible and
a non-deductible context. Hence, it should be correct, that the code fails to
compile in item (1). Specifying the template parameters explicitly (as in item
(2)) gets rid of this problem, since no deduction occurs.
However, the same situation as in (1) applies to item (3) with the difference,
that the non-deductible parameter pack is now trailing. Thus, one might have to
consider
"A trailing template parameter pack (14.5.3) not otherwise deduced will be
deduced to an empty sequence of template arguments"
The pack is still non-deductible and the first point should apply. What is the
correct behaviour here?
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
