User Details
- User Since
- Aug 26 2015, 8:20 AM (396 w, 3 d)
Mar 2 2023
Mar 1 2023
Jan 4 2023
Dec 21 2022
Dec 12 2022
Oct 9 2022
I just ran into newly-failing
$ cat test.cc struct S1 { bool operator==(int); bool operator!=(int); }; struct S2; bool operator ==(S2, S2); bool f(S1 s) { return 0 == s; }
$ clang++ -std=c++20 -fsyntax-only test.cc test.cc:7:25: error: invalid operands to binary expression ('int' and 'S1') bool f(S1 s) { return 0 == s; } ~ ^ ~ test.cc:6:6: note: candidate function not viable: no known conversion from 'int' to 'S2' for 1st argument bool operator ==(S2, S2); ^ 1 error generated.
It looks to me like this is correctly rejected now per P2468R2. But it is rather confusing that a note mentions the S2 candidate, while the relevant S1 operators == and != are not mentioned at all.
Aug 29 2022
[...]
causes a warning? I would have expected it to be suppressed in this case, as with the lax -fstrict-flex-arrays=0 default, and only to hit with the stricter -fstrict-flex-arrays=2.
Aug 16 2022
For a -DLIBCXX_ENABLE_DEBUG_MODE=ON build this now causes
$ cat test.cc #define _LIBCPP_DEBUG 1 #include <vector> static std::vector<int> v; int main() { v.push_back(0); int a = 0; for (auto i: v) a += i; return a; }
Aug 12 2022
Aug 10 2022
With this commit,
$ cat test.cc #include "boost/numeric/conversion/cast.hpp" int main() { return boost::numeric_cast<int>(0L); }
Aug 4 2022
I'm surprised that
$ cat test.c struct S { int m1; int m2[1]; }; void f(struct S * s) { s->m2[1] = 0; }
Jul 6 2022
Jul 5 2022
addressed comments on test file
added to release notes
Jul 4 2022
Jul 1 2022
added test involving template argument substitution
Jun 30 2022
Updated the prospective git commit message as follow:
[test] Check for more -fsanitize=array-bounds behavior
Jun 28 2022
Jun 27 2022
[sorry for the noise; my previous, removed comment was due to some local modifications on my end]
I'm abandoning this as the underlying https://reviews.llvm.org/D126864 "[clang] Introduce -fstrict-flex-arrays=<n> for stricter handling of flexible arrays" has been reverted for now.
see https://reviews.llvm.org/D128643 "[clang] -fsanitize=array-bounds: treat all trailing size-1 arrays as flexible" for another regression
Jun 21 2022
Jun 20 2022
Is it intended that a deleted copy assignment op as in struct S { void operator =(S &) = delete; }; (though, somewhat oddly, not in struct S { void operator =(S) = delete; };) is now marked as trivial?
Jun 15 2022
But now
#include <array>
auto b = std::begin("");fails to compile, even though [iterator.range]/1 states: "In addition to being available via inclusion of the <iterator> header, the function templates in 23.7 are
available when any of the following headers are included: <array> (22.3.2), [...]"
Jun 10 2022
There might be something fishy with this commit. My fresh from-scratch cmake --build . && cmake --build . --target install monorepo build now lacked e.g. the bin/clang++ symlink in the installation dir, and locally reverting this commit fixed that.
May 9 2022
Mar 22 2022
Dec 14 2021
So the check, for a file called e.g. "C:\test\test.h" would suggest the guard C:_TEST_TEST_H being an invalid name due to the presence of the colon.
Nov 29 2021
I commented inline at https://reviews.llvm.org/rG2b160e95c89f28a30e2481e6131073659d866a8c#1040993 "Reland [SCEV] Fix and validate ValueExprMap/ExprValueMap consistency":
Nov 5 2021
Final macros will always warn on redefinition, including situations with identical bodies and in system headers.
Sep 23 2021
ah, even better :)
Sep 22 2021
Aug 25 2021
Aug 2 2021
Bisecting shows that this commit causes
$ echo foo | clang -E -P -Jun 28 2021
Jun 25 2021
And, again for the record, with a build of LibreOffice with clang-cl (and -Xclang -std=c++2b) on Windows, at least against the C++ standard library from Visual Studio 2019 version 16.20.2, I ran into two issues in the standard library itself, when using std::getline and std::istream::operator>>:
In file included from C:/lo-clang/core/setup_native/source/win32/customactions/reg_dlls/reg_dlls.cxx:12:
C:/PROGRA~2/MIB055~1/2019/COMMUN~1/VC/Tools/MSVC/1429~1.300/Include\string(66,12): error: non-const lvalue reference to type 'basic_istream<...>' cannot bind to a temporary of type 'basic_istream<...>'
return _Istr;
^~~~~
C:/PROGRA~2/MIB055~1/2019/COMMUN~1/VC/Tools/MSVC/1429~1.300/Include\string(78,12): note: in instantiation of function template specialization 'std::getline<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t>>' requested here
return getline(_STD move(_Istr), _Str, _Delim);
^
C:/lo-clang/core/setup_native/source/win32/customactions/reg_dlls/reg_dlls.cxx(197,17): note: in instantiation of function template specialization 'std::getline<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t>>' requested here
while (std::getline(ss, sToken, L'|'))
^
1 error generated.
make[1]: *** [C:/lo-clang/core/solenv/gbuild/LinkTarget.mk:298: C:/lo-clang/core/workdir/CxxObject/setup_native/source/win32/customactions/reg_dlls/reg_dlls.o] Error 1Jun 17 2021
For the record, the one other breakage of a LibreOffice build with this is the handful of places that needed https://git.libreoffice.org/core/+/433ab39b2175bdadb4916373cd2dc8e1aabc08a5%5E%21 "Adapt implicit OString return value construction to C++23 P2266R1": In a nutshell, LO has an OString class with (non-explicit) constructors from any kind of char pointer or array, where the "array of N const char" variant (no. 3 below) is special, as it determines the string length as N - 1 (whereas all the other variants search for the terminating NUL to determine the length). That requires another constructor overload (no. 2 below) for non-const arrays, taking a non-const lvalue reference, which now causes issues when that constructor shall implicitly be used in return statements:
$ cat test.cc #include <cstddef>
Jun 14 2021
(In a build prior to https://reviews.llvm.org/rGc60dd3b2626a4d9eefd9f82f9a406b0d28d3fd72 "Revert '[clang] NRVO: Improvements and handling of more cases.'") I see the following (reduced from https://git.libreoffice.org/core/+/649313625b94e6b879848fc19b607b74375100bf/o3tl/qa/compile-temporary.cxx) started to fail under -std=c++2b with this change (and continues to compile fine with -std=c++20):
$ cat test.cc template <typename T> constexpr T& temporary(T&& x) { return x; } template <typename T> constexpr T& temporary(T&) = delete; void f(int*); int g(); void h() { f(&temporary(int())); f(&temporary(g())); }
Jun 13 2021
Jun 9 2021
LGTM
Jun 3 2021
Is it intentional that this warns about volatile variables as in
void f(char * p) {
volatile char c = 0;
c ^= *p;
}(I see that GCC warns about volatile too, at least when you replace the ^= with =, so assume the answer is "yes", but would just like to see that confirmed (ideally with a test case even?).)
May 6 2021
Bisecting shows that this started to break
$ cat test.cc void f() noexcept { __try {} __finally {} } $ clang-cl -EHs -c test.cc clang-cl: ~/github.com/llvm/llvm-project/clang/lib/CodeGen/CGCleanup.h:568: void clang::CodeGen::EHScopeStack::popTerminate(): Assertion `!empty() && "popping exception stack when not empty"' failed. PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace, preprocessed source, and associated run script. Stack dump: 0. Program arguments: ~/llvm/inst/bin/clang-cl -EHs -c test.cc 1. <eof> parser at end of file 2. test.cc:1:6: LLVM IR generation of declaration 'f' 3. test.cc:1:6: Generating code for declaration 'f' #0 0x00007f2fd211624d llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) ~/github.com/llvm/llvm-project/llvm/lib/Support/Unix/Signals.inc:569:3 #1 0x00007f2fd2114174 llvm::sys::RunSignalHandlers() ~/github.com/llvm/llvm-project/llvm/lib/Support/Signals.cpp:71:20 #2 0x00007f2fd20368c8 HandleCrash ~/github.com/llvm/llvm-project/llvm/lib/Support/CrashRecoveryContext.cpp:75:5 #3 0x00007f2fd20368c8 CrashRecoverySignalHandler(int) ~/github.com/llvm/llvm-project/llvm/lib/Support/CrashRecoveryContext.cpp:388:62 #4 0x00007f2fd68f91e0 __restore_rt sigaction.c:0:0 #5 0x00007f2fd1a4b9d5 raise /usr/src/debug/glibc-2.32-37-g760e1d2878/signal/../sysdeps/unix/sysv/linux/raise.c:50:1 #6 0x00007f2fd1a348a4 abort /usr/src/debug/glibc-2.32-37-g760e1d2878/stdlib/abort.c:81:7 #7 0x00007f2fd1a34789 get_sysdep_segment_value /usr/src/debug/glibc-2.32-37-g760e1d2878/intl/loadmsgcat.c:509:8 #8 0x00007f2fd1a34789 _nl_load_domain.cold /usr/src/debug/glibc-2.32-37-g760e1d2878/intl/loadmsgcat.c:970:34 #9 0x00007f2fd1a44026 .annobin___GI___assert_fail.end assert.c:0:0 #10 0x00007f2fd5871973 (~/llvm/inst/bin/../lib/libclangCodeGen.so.13git+0x44b973) #11 0x00007f2fd587612a (~/llvm/inst/bin/../lib/libclangCodeGen.so.13git+0x45012a) #12 0x00007f2fd5a85bbc clang::CodeGen::CodeGenFunction::FinishFunction(clang::SourceLocation) ~/github.com/llvm/llvm-project/clang/lib/CodeGen/CodeGenFunction.cpp:405:3 #13 0x00007f2fd587f703 clang::CodeGen::CodeGenFunction::GenerateSEHFinallyFunction(clang::CodeGen::CodeGenFunction&, clang::SEHFinallyStmt const&) ~/github.com/llvm/llvm-project/clang/lib/CodeGen/CGException.cpp:2005:10 #14 0x00007f2fd587f776 pushCleanup<(anonymous namespace)::PerformSEHFinally, llvm::Function*> ~/github.com/llvm/llvm-project/clang/lib/CodeGen/EHScopeStack.h:273:31 #15 0x00007f2fd587f776 clang::CodeGen::CodeGenFunction::EnterSEHTryStmt(clang::SEHTryStmt const&) ~/github.com/llvm/llvm-project/clang/lib/CodeGen/CGException.cpp:2082:43 #16 0x00007f2fd587fa87 clang::CodeGen::CodeGenFunction::getJumpDestInCurrentScope(llvm::StringRef) ~/github.com/llvm/llvm-project/clang/lib/CodeGen/CodeGenFunction.h:1096:59 #17 0x00007f2fd587fa87 clang::CodeGen::CodeGenFunction::EmitSEHTryStmt(clang::SEHTryStmt const&) ~/github.com/llvm/llvm-project/clang/lib/CodeGen/CGException.cpp:1605:65 #18 0x00007f2fd5a21de4 clang::CodeGen::CodeGenFunction::EmitCompoundStmtWithoutScope(clang::CompoundStmt const&, bool, clang::CodeGen::AggValueSlot) ~/github.com/llvm/llvm-project/clang/lib/CodeGen/CGStmt.cpp:447:31 #19 0x00007f2fd5a8499b clang::CodeGen::CodeGenFunction::EmitFunctionBody(clang::Stmt const*) ~/github.com/llvm/llvm-project/clang/lib/CodeGen/CodeGenFunction.cpp:1185:36 #20 0x00007f2fd5a9214a clang::CodeGen::CodeGenModule::getLangOpts() const ~/github.com/llvm/llvm-project/clang/lib/CodeGen/CodeGenModule.h:686:51 #21 0x00007f2fd5a9214a clang::CodeGen::CodeGenFunction::getLangOpts() const ~/github.com/llvm/llvm-project/clang/lib/CodeGen/CodeGenFunction.h:1921:67 #22 0x00007f2fd5a9214a clang::CodeGen::CodeGenFunction::GenerateCode(clang::GlobalDecl, llvm::Function*, clang::CodeGen::CGFunctionInfo const&) ~/github.com/llvm/llvm-project/clang/lib/CodeGen/CodeGenFunction.cpp:1352:19 #23 0x00007f2fd5ad447c clang::CodeGen::CodeGenModule::EmitGlobalFunctionDefinition(clang::GlobalDecl, llvm::GlobalValue*) ~/github.com/llvm/llvm-project/clang/lib/CodeGen/CodeGenModule.cpp:4791:3 #24 0x00007f2fd5ad0f7b clang::CodeGen::CodeGenModule::EmitGlobalDefinition(clang::GlobalDecl, llvm::GlobalValue*) ~/github.com/llvm/llvm-project/clang/lib/CodeGen/CodeGenModule.cpp:3177:47 #25 0x00007f2fd5ad8c8a clang::CodeGen::CodeGenModule::EmitTopLevelDecl(clang::Decl*) (.part.0) ~/github.com/llvm/llvm-project/clang/lib/CodeGen/CodeGenModule.cpp:5895:1 #26 0x00007f2fd5b4e9a1 (anonymous namespace)::CodeGeneratorImpl::HandleTopLevelDecl(clang::DeclGroupRef) ~/github.com/llvm/llvm-project/clang/lib/CodeGen/ModuleBuilder.cpp:169:67 #27 0x00007f2fd5a70b13 clang::BackendConsumer::HandleTopLevelDecl(clang::DeclGroupRef) ~/github.com/llvm/llvm-project/clang/lib/CodeGen/CodeGenAction.cpp:217:7 #28 0x00007f2fcfbbd814 clang::ParseAST(clang::Sema&, bool, bool) ~/github.com/llvm/llvm-project/clang/lib/Parse/ParseAST.cpp:162:17 #29 0x00007f2fd3e3f4b9 clang::FrontendAction::Execute() ~/github.com/llvm/llvm-project/clang/lib/Frontend/FrontendAction.cpp:949:21 #30 0x00007f2fd3dd4cd6 llvm::Error::setChecked(bool) ~/github.com/llvm/llvm-project/llvm/include/llvm/Support/Error.h:305:22 #31 0x00007f2fd3dd4cd6 llvm::Error::operator bool() ~/github.com/llvm/llvm-project/llvm/include/llvm/Support/Error.h:236:15 #32 0x00007f2fd3dd4cd6 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) ~/github.com/llvm/llvm-project/clang/lib/Frontend/CompilerInstance.cpp:955:42 #33 0x00007f2fd68e1a5b clang::ExecuteCompilerInvocation(clang::CompilerInstance*) ~/github.com/llvm/llvm-project/clang/lib/FrontendTool/ExecuteCompilerInvocation.cpp:279:32 #34 0x0000000000219694 cc1_main(llvm::ArrayRef<char const*>, char const*, void*) ~/github.com/llvm/llvm-project/clang/tools/driver/cc1_main.cpp:246:40 #35 0x0000000000212ced ExecuteCC1Tool(llvm::SmallVectorImpl<char const*>&) ~/github.com/llvm/llvm-project/clang/tools/driver/driver.cpp:335:20 #36 0x00007f2fd3b56c85 operator() ~/github.com/llvm/llvm-project/clang/lib/Driver/Job.cpp:404:32 #37 0x00007f2fd3b56c85 void llvm::function_ref<void ()>::callback_fn<clang::driver::CC1Command::Execute(llvm::ArrayRef<llvm::Optional<llvm::StringRef> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >*, bool*) const::'lambda'()>(long) ~/github.com/llvm/llvm-project/llvm/include/llvm/ADT/STLExtras.h:185:52 #38 0x00007f2fd2036a34 llvm::CrashRecoveryContext::RunSafely(llvm::function_ref<void ()>) ~/github.com/llvm/llvm-project/llvm/lib/Support/CrashRecoveryContext.cpp:425:10 #39 0x00007f2fd3b578eb clang::driver::CC1Command::Execute(llvm::ArrayRef<llvm::Optional<llvm::StringRef> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >*, bool*) const (.part.0) ~/github.com/llvm/llvm-project/clang/lib/Driver/Job.cpp:408:10 #40 0x00007f2fd3b28552 clang::driver::Compilation::ExecuteCommand(clang::driver::Command const&, clang::driver::Command const*&) const ~/github.com/llvm/llvm-project/clang/lib/Driver/Compilation.cpp:196:3 #41 0x00007f2fd3b28c31 clang::driver::Compilation::ExecuteJobs(clang::driver::JobList const&, llvm::SmallVectorImpl<std::pair<int, clang::driver::Command const*> >&) const ~/github.com/llvm/llvm-project/clang/lib/Driver/Compilation.cpp:248:5 #42 0x00007f2fd3b34d71 llvm::SmallVectorBase<unsigned int>::empty() const ~/github.com/llvm/llvm-project/llvm/include/llvm/ADT/SmallVector.h:73:47 #43 0x00007f2fd3b34d71 clang::driver::Driver::ExecuteCompilation(clang::driver::Compilation&, llvm::SmallVectorImpl<std::pair<int, clang::driver::Command const*> >&) ~/github.com/llvm/llvm-project/clang/lib/Driver/Driver.cpp:1539:28 #44 0x000000000021640a main ~/github.com/llvm/llvm-project/clang/tools/driver/driver.cpp:510:5 #45 0x00007f2fd1a361e2 __libc_start_main /usr/src/debug/glibc-2.32-37-g760e1d2878/csu/../csu/libc-start.c:314:16 #46 0x00000000002120ee _start (~/llvm/inst/bin/clang-cl+0x2120ee) clang-12: error: clang frontend command failed with exit code 134 (use -v to see invocation) clang version 13.0.0 (git@github.com:llvm/llvm-project 2224221fb3fa9738bd84221ed048247089187fce) Target: x86_64-pc-windows-msvc Thread model: posix InstalledDir: ~/llvm/inst/bin
(It still works fine if you change the function's exception specification from noexcept to throw().)
Mar 23 2021
FWIW, LibreOffice make check (which started to consistently fail with D88220) succeeds with this change.
Mar 19 2021
This change causes
Jan 19 2021
As also reported at https://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20210118/872711.html "Re: [llvm] 48d2068 - [dsymutil] Warn on timestmap mismatch between object file and debug map" about the re-revert https://github.com/llvm/llvm-project/commit/48d2068fb738302b9fba91c9bf8e4b051c3909eb "[dsymutil] Warn on timestmap mismatch between object file and debug map" (but for which there appears to be no Phabricator review of its own):
Jan 12 2021
Dec 16 2020
Ping; OK to submit? (I meanwhile also get this when compiling some code with plain Clang, not just with the LibreOffice Clang plugin where I saw it originally.)
Nov 23 2020
Nov 3 2020
Smells like this breaks various bots due to a -fsanitize=...,... option now listing 18 instead of 17 items, see http://lab.llvm.org:8011/#builders/76/builds/363, http://lab.llvm.org:8011/#builders/93/builds/430, http://lab.llvm.org:8011/#builders/66/builds/315, http://lab.llvm.org:8011/#builders/7/builds/303.
Nov 2 2020
ping
Oct 28 2020
Is there a reason why "NoQ accepted this revision." kept this at "Needs Review" rather than moving it to "This revision is now accepted and ready to land."?
Oct 27 2020
ping
ping
Oct 15 2020
Oct 2 2020
friendly ping
Sep 25 2020
ping^2
Sep 18 2020
(addressed the clang-tidy nitpick)
ping
Sep 9 2020
Sep 2 2020
I hit this with a call to getSubExprAsWriten from the LibreOffice Clang plugin, have no idea whether it can be hit from within the compiler itself. Not sure if clang/unittests/Tooling/CastExprTest.cpp is the best place to add a test for it.
Aug 12 2020
I filed https://bugs.llvm.org/show_bug.cgi?id=47139 "Misspelled -fnostack-clash-protection" now.
Fixes all the false positives it had reported for LibreOffice (which had all involved expressions containing either ~ or +).
Aug 11 2020
I think this generates a false positive with test.cc
enum E { E1 = 1, E2 = 2 };
bool f(E e) { return ((e & E1) ? 1 : 0) + ((e & E2) ? 1 : 0) > 1; }and clang++ -fsyntax-only -Wtautological-value-range-compare test.cc
test.cc:2:62: warning: result of comparison of 1-bit unsigned value > 1 is always false [-Wtautological-value-range-compare]
bool f(E e) { return ((e & E1) ? 1 : 0) + ((e & E2) ? 1 : 0) > 1; }
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^ ~Aug 10 2020
Aug 6 2020
Aug 5 2020
My naive assumption was that this warning had initially been restricted to integer literals and enumerators to avoid false positives. Hence my conservative approach of extending merely to constant integer expressions for now. Maybe Richard as the original author of the warning (IIUC) can shed some light on that original restriction?