- User Since
- Jul 10 2017, 11:37 AM (222 w, 5 d)
Wed, Oct 13
Added a test
Mon, Oct 11
Mar 18 2021
Mar 8 2021
Implemented review comment to restrict __stdcall default calling convention (for WinMain, wWinMain, and DllMain) to 32 bit Windows.
Mar 4 2021
Feb 12 2021
Sep 17 2020
Sep 16 2020
Sep 15 2020
Feb 12 2020
Actually I just noticed it still says 'Needs review' above. I'm not sure what the protocol is. Can I push the patch?
Thanks! I'll push it shortly. Just running a final ninja check-all after updating workspace.
Feb 6 2020
Thanks for taking a look Richard. This patch adds the required value-dependency check and sets type-dependency accordingly.
Jan 22 2020
Jan 9 2020
Semantic analysis for value dependent conditions is now skipped as per Erich's comment. Patch adds an argument to CheckBooleanCondition to still do the required analysis for noexcept expressions.
Jan 8 2020
Thanks for taking a look Erich!
Jan 5 2020
Dec 5 2019
Dec 3 2019
Nov 19 2019
Nov 11 2019
The patch changes type dependency of field 'std::string s' and sets it based on field type (i.e. not type-dependent).
Nov 8 2019
Thank you for letting me know. The patch has been reverted.
@rnk @gribozavr2 clang-tidy test "bugprone-string-integer-assignment.cpp" caused a bot fail on windows. From the logs it looks like the 'CHECK-FIXES' I added in that test is failing because the fix isn't applied. I am not sure why. I don't have a windows build set up and I assume a new build is going to take some time. I am not sure what the protocol for this is. Should I go ahead and revert my patch while I investigate the issue on Windows or should I just push a new patch deleting the 'CHECK-FIXES' while I look into the issue?
Thank you for taking a look Reid and Dmitri. There were no fails with check-all.
Nov 7 2019
Aug 14 2019
Thank you for letting me know. I did try reproducing the issue with check-all yesterday but was unable to. I do not think I build with 'clang-tools-extra' project enabled though. I'll take another look today.
Aug 13 2019
Aug 7 2019
Thanks for taking a look Reid! I rebased the patch and had a conflict with one of Richard's patches and so ran the lit tests again and noticed there are several new failures. I am taking a look at those now.
Jul 29 2019
Jul 17 2019
I just realized I modified the summary when I uploaded a new patch, but did not add a comment about the changes I made. Based on feedback from the bug report (https://bugs.llvm.org/show_bug.cgi?id=40982), I changed my approach for this crash. This patch changes the type dependency of the member which causes the crash.
Jun 10 2019
Apr 24 2019
I ran the test you provided and it does throw errors without instantiation
Apr 23 2019
I apologize for the confusion. I was working on an incorrect branch earlier, and so abandoned that patch and uploaded a new revision.
Nov 6 2018
Nov 2 2018
Nov 1 2018
Upstreaming it first might be better, especially since the change seems to be trivial. Is this line addition the only change proposed for the benchmark library?
Yes this line is the only change.
Do you want me to submit the patch to the benchmark library? It seems that it would help to speedup the process.
That would be helpful. Thank you!
@kbobyrev I apologize if I was unclear in the comments. I was asking if the changes proposed in the comments are alright with you since they would involve modifying benchmark/CMakelists.txt (instead of llvm/CMakeLists.txt as discussed in mailing list). As Zachary mentioned in comments, _HAS_EXCEPTIONS should be set to 0 only when exceptions are disabled. Since exception handling for benchmarks is handled in benchmark/CMakeLists.txt, I think it makes most sense to add the definition there. I have now uploaded the proposed change for review.
Oct 29 2018
Oct 25 2018
I think it makes sense to include this case just to make the flag more complete. Also, we don't really match GCC behavior for this flag. GCC emits all static constants by default (when O0). When optimized, this flag has no effect on GCC. The negation is used to not emit the constants.
Oct 9 2018
Yes. I understand. At the moment, exception handling flags are generated based on BENCHMARK_ENABLE_EXCEPTIONS in utils/benchmark/CMakeLists.txt . However, _HAS_EXCEPTIONS is not defined based on this (code below). The warnings are a result of this mismatch.
Oct 8 2018
Thanks for the information Zachary.
I do not think defining _HAS_EXCEPTIONS=0 affects C++ exceptions in the application. I thought it only affected the STL. I will verify this and update you.
Sep 4 2018
Alright. Thanks for the review. I will abandon this patch
Aug 31 2018
@lebedev.ri is there a specific reason -Wtautological-unsigned-zero-compare was removed? All the issues I am aware of talks about comparisons with min/max.
Aug 22 2018
Aug 20 2018
Based on Reid's feedback, I changed option to CodeGenOption
Aug 17 2018
This patch fell through the cracks earlier. I apologize. Based on Reid's and Erich's feedback, I am now adding the variable to @llvm.used. Additionally I modified the if statements to ensure only static variables are considered.
Feb 14 2018
I think we can use CodeGenModule::addUsedGlobal for this purpose. I noticed this is what attribute 'used' calls. I need to look into it though.
Feb 13 2018
Jan 18 2018
That makes sense. Is it not possible to implement the required functionality using a flag vs an attribute? In an earlier comment you mentioned adding the global to @llvm.used to prevent GlobalDCE from removing it. Can you not do that when using a flag?
Jan 10 2018
Thanks for the review Reid. Sorry for the delay in my response. I was OOO.
Dec 11 2017
Dec 6 2017
Nov 2 2017
No problem! Thanks!
Oct 25 2017
Updated patch to set default calling convention for main() in CheckMain()
Oct 23 2017
Sep 25 2017
I've modified the patch to emit a warning for re-declarations only. I also removed the isUsed check.
Sep 21 2017
I've updated the patch based on review comments. The changes include setting section unconditionally for extern variables and emitting a warning if section attribute is specified on a redeclaration.
Aug 28 2017
Aug 22 2017
LangRef has been updated and accepted. You can find it here - https://reviews.llvm.org/rL311459
Updated the documentation to explicitly state that section information for a variable can be explicit or inferred.
Aug 16 2017
Updated the patch to include Krzysztof's comment about explicitly stating undefined behavior for section information mismatch in global variable declaration and definition. This should cover the case where section is explicitly specified in definition but not declaration.
Corrected spelling error.
Aug 15 2017
I updated the documentation to include Simon's comments. I wasn't sure whether to include the line about section information being retained in LLVM IR, since Eli mentioned it could vary for different front-ends. I have included it in this revision.
Aug 14 2017
As per review comments, removed extra RUNS in lit test.
Aug 8 2017
Jul 21 2017
Regcall-specific checks for Lin64 now occur only if CXXABI returns false. An existing test has also been modified to verify behavior with non trivial destructors.
Jul 19 2017
As per revision comments, I moved the condition for extended precision floating type to isX86VectorTypeForVectorCall. This update will now alter behavior for complex long double type under vectorcall calling convention as well. Returns/parameters will be passed in memory.