User Details
- User Since
- Jul 10 2012, 10:35 AM (559 w, 4 d)
Tue, Mar 28
I figured out. The test is really a corner case and it's not representative of real code. It artificially creates a chain of 1024 recursive template instantiations and the deepest level started requiring one more template instantiation for std::string after this patch. This is definitely not a problem elsewhere.
This commit increases compilation time by ~15% and increases recursive template instantiation depth (thus, requiring adjusting -ftemplate-depth=2048) in some of our internal test code. Admittedly, it's using templates in a sort of a compiler-load-test-like way, but this change may affect compilation time for real code as well (it's just not likely to hit the default -ftemplate-depth=1024 limit and I don't have a good idea of how to find this code with reasonable effort).
Thu, Mar 16
The following snippet (reduced from a version of mysql) compiles well before this commit and fails to compile after it (https://gcc.godbolt.org/z/zrGbbbWb5):
Feb 23 2023
Feb 15 2023
Feb 14 2023
Feb 1 2023
The implementation with two different class names seems much cleaner. Thanks!
@philnik could you commit one of the proposed abi_tag fixes?
Jan 31 2023
Jan 26 2023
We've found the cause of the problems @asbirlea reported above: violation of aliasing rules. Something similar to this snippet: https://gcc.godbolt.org/z/3Y9GEMW4e
This patch breaks our cuda compilations. The output file isn't created after it:
$ echo 'extern "C" __attribute__((global)) void q() {}' >q.cc $ good-clang \ -nocudainc -x cuda \ --cuda-path=somepath/cuda/ \ -Wno-unknown-cuda-version --cuda-device-only \ -c q.cc -o qqq-good.o \ && bad-clang \ -nocudainc -x cuda \ --cuda-path=somepath/cuda/ \ -Wno-unknown-cuda-version --cuda-device-only \ -c q.cc -o qqq-bad.o \ && ls qqq*.o qqq-good.o
Jan 25 2023
Thanks for preparing this fix! I've verified that it fixes the original reproducer as well.
Jan 24 2023
It looks like there's no easy fix for now, right? I'm about to revert this commit (12cb1cb3720de8d164196010123ce1a8901d8122) to unblock us.
There's another interesting issue (reduced from https://unicode-org.github.io/icu-docs/apidoc/dev/icu4c/stringpiece_8h_source.html) I bisected to this commit: https://gcc.godbolt.org/z/W5x1s9KbK
Jan 23 2023
Jan 22 2023
Unfortunately, there's another problem, which doesn't get fixed by https://reviews.llvm.org/D142166 / 2e25204779e5b972d668bf66a0014c1325813b35:
assert.h assertion failed at llvm/lib/Target/X86/X86ISelLowering.cpp:31466 in std::pair<Value *, BitTestKind> FindSingleBitChange(Value *): I != nullptr @ 0x56257abc9524 __assert_fail @ 0x562578c7fd1c FindSingleBitChange() @ 0x562578c7f6dd llvm::X86TargetLowering::shouldExpandLogicAtomicRMWInIR() @ 0x562578c8098b llvm::X86TargetLowering::shouldExpandAtomicRMWInIR() @ 0x5625790a6099 (anonymous namespace)::AtomicExpand::tryExpandAtomicRMW() @ 0x5625790a59dd (anonymous namespace)::AtomicExpand::runOnFunction() @ 0x56257a86e87d llvm::FPPassManager::runOnFunction() @ 0x56257a876104 llvm::FPPassManager::runOnModule() @ 0x56257a86ef7c llvm::legacy::PassManagerImpl::run() @ 0x562575bad581 clang::EmitBackendOutput() @ 0x562575baabe9 clang::BackendConsumer::HandleTranslationUnit() @ 0x562576a85e5c clang::ParseAST() @ 0x5625767cbf23 clang::FrontendAction::Execute() @ 0x562576741cad clang::CompilerInstance::ExecuteAction() @ 0x5625757871e8 clang::ExecuteCompilerInvocation() @ 0x56257577ae41 cc1_main() @ 0x562575776ec8 ExecuteCC1Tool() @ 0x5625768ed317 llvm::function_ref<>::callback_fn<>() @ 0x56257aa23d20 llvm::CrashRecoveryContext::RunSafely() @ 0x5625768ecb63 clang::driver::CC1Command::Execute() @ 0x5625768ab2e6 clang::driver::Compilation::ExecuteCommand() @ 0x5625768ab60f clang::driver::Compilation::ExecuteJobs() @ 0x5625768caf70 clang::driver::Driver::ExecuteCompilation() @ 0x562575776027 clang_main() @ 0x7f8f04be3633 __libc_start_main @ 0x562575772bea _start
Jan 12 2023
Jan 11 2023
My little investigation shows that most of our problems were fixed at 07ecdd9b1a8af51f07d5f4dfe46845c801482a39, but some were fixed even before that.
Jan 10 2023
Jan 6 2023
Jan 5 2023
Heads up: I suspect that this commit breaks the nvptx64-nvidia-cuda target. I have a few cuda files that stop working correctly after this commit, and I'm reducing one of the tests.
Jan 4 2023
Jan 3 2023
Dec 23 2022
It took significantly longer than I expected, but this is what I came up with. The code below changes behavior when compiled with this commit:
Dec 21 2022
Dec 19 2022
Hi Roman, this might be causing some miscompiles in our code. I'm now trying to reduce the test case. I'll notify you when I have more information.
Dec 16 2022
I will revert this patch. Please ensure the provided test case works fine before recommitting.
Dec 6 2022
There's another problem with this patch. Please ensure it's fixed before recommitting. Clang hangs while compiling the following short snippet reduced from an open-source library (compiled on x86-64, linux):
There's a problem in the previous iteration of this patch (https://reviews.llvm.org/D138774). It made clang hang while compiling the following short snippet reduced from an open-source library (compiled on x86-64, linux):
$ cat q.c char *texsubexpr(char *expression, char *subexpr) { char *texchar(); if (*expression) return texchar(expression, subexpr); }
Dec 3 2022
Rebased.
LGTM modulo open comments.
Dec 1 2022
Nov 29 2022
Nov 25 2022
Nov 20 2022
Heads up: this commit has broken compilation in a small number of cases: some #includes from modularized headers now fail to be found. I'm still trying to figure out what exactly happened, but some behavior has definitely changed by this commit.
Nov 18 2022
And another problem with this patch: there's another pattern (or multiple different patterns?) in the code, that result in around 3x clang memory usage increase after this patch. The result of -print-stats doesn't make it clear where the additional allocations come from:
Nov 10 2022
Thanks for adding this diagnostic! I wonder whether we can include SLoc usage information into -print-stats output?
Nov 8 2022
Nov 7 2022
Given the broad impact of this in our code I'm inclined to revert the patch
to unblock us. The test case I have so far is still too large, but I hope
to get something shareable tomorrow.
Hi Matheus, 279fe6281d2ca5b2318c7437316c28750feaac8d causes compilation timeout on some of our internal files. We're trying to get a test case we can share, but so far the only information I can provide is compiler perf profile difference:
Oct 23 2022
Undo LGTM, since we decided to go with a revert.
FYI, I've reverted f83347b0bedb22ea676861c8e4e2ed9c31371ade and 74e4f778cf16cbf7163b5c6de6027a43f5e9169f.
Oct 22 2022
LG, thanks!
Oct 6 2022
We started seeing incorrect behavior in some code after this commit. The test case is here: https://gcc.godbolt.org/z/hhj64noKs.