[clang] 1650178 - [Clang] Add support for -Wno-inline-namespace-reopened-noninline

Author: Elvina Yakubova Date: 2020-06-25T18:48:50+03:00 New Revision: 16501782c8d849bc1812d527dc8466574700663d URL: https://github.com/llvm/llvm-project/commit/16501782c8d849bc1812d527dc8466574700663d DIFF: https://github.com/llvm/llvm-project/commit/16501782c8d849bc1812d527dc8466574700663d.dif

r279240 - Fixed a typo (compilation_commands.json --> compile_commands.json).

Author: asbokhan Date: Fri Aug 19 08:36:31 2016 New Revision: 279240 URL: http://llvm.org/viewvc/llvm-project?rev=279240&view=rev Log: Fixed a typo (compilation_commands.json --> compile_commands.json). Modified: cfe/trunk/docs/HowToSetupToolingForLLVM.rst Modified: cfe/trunk/docs/HowToSetup

Re: Disable fms-extensions?

Hi Zahira, -fms-extensions can obviously be disabled with -fno-ms-extensions. This won't necessarily mirrors /Za exactly, though -- as according to MS, /Za disables *all* C++ extensions, not only MS-specific ones. I doubt anyone tried to implement a mode that mirrors /Za exactly. Yours, Andrey --

r284579 - [Sema] Gcc compatibility of vector shift

Author: asbokhan Date: Wed Oct 19 07:06:10 2016 New Revision: 284579 URL: http://llvm.org/viewvc/llvm-project?rev=284579&view=rev Log: [Sema] Gcc compatibility of vector shift Gcc prints error if elements of left and right parts of a shift have different sizes. This patch is provided the GCC comp

Re: [PATCH] D12402: PR24595: clang-cl fails to compile vswriter.h header from Windows SDK 8.1 in 32 bit mode

andreybokhanko marked 8 inline comments as done. andreybokhanko added a comment. http://reviews.llvm.org/D12402 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D12402: PR24595: clang-cl fails to compile vswriter.h header from Windows SDK 8.1 in 32 bit mode

andreybokhanko updated this revision to Diff 34477. andreybokhanko added a comment. Reid, Sorry for delayed reply. All your comments are fixed (it turned out that usage of DefaultCC instead of ToCC is the root of all evil; after I fixed this, all other problems went away). Patch updated; pleas

Re: [PATCH] D12402: PR24595: clang-cl fails to compile vswriter.h header from Windows SDK 8.1 in 32 bit mode

andreybokhanko added a comment. Reid, thank you for the review! One last confirmation (see below), and I'll go ahead. Yours, Andrey Comment at: test/CodeGenCXX/ctor-dtor-alias.cpp:170 @@ -169,3 +169,3 @@ // it has a different calling conversion. - // CHECK4: call void @_ZN

Re: [PATCH] D12402: PR24595: clang-cl fails to compile vswriter.h header from Windows SDK 8.1 in 32 bit mode

andreybokhanko added inline comments. Comment at: lib/Sema/SemaType.cpp:5876 @@ +5875,3 @@ + +if (!IsCtorOrDtor) { + if (CurCC != DefaultCC || DefaultCC == ToCC) rnk wrote: > This looks like the !IsCtorOrDtor check that affects Itanium. Isn't it > alread

r247619 - PR24595: Ignore calling convention modifiers for structors in MS ABI.

Author: asbokhan Date: Mon Sep 14 16:29:57 2015 New Revision: 247619 URL: http://llvm.org/viewvc/llvm-project?rev=247619&view=rev Log: PR24595: Ignore calling convention modifiers for structors in MS ABI. MS compiler ignores calling convention modifiers for structors. This patch makes clang do th

Re: [PATCH] D12402: PR24595: clang-cl fails to compile vswriter.h header from Windows SDK 8.1 in 32 bit mode

andreybokhanko added a comment. OK -- I removed the check in Itanium ABI part, restored back the test and committed the patch. Thanks for reviewing! Repository: rL LLVM http://reviews.llvm.org/D12402 ___ cfe-commits mailing list cfe-commits@lis

Re: [PATCH] D11297: PR17829: Functions declared extern "C" with a name matching a mangled C++ function are allowed

andreybokhanko added a comment. John, (Others are welcome to chime in as well) I started to implement your suggestion, but faced with problems. Consider the following test case: 1: struct T { 2: ~T() {} 3: }; 4: 5: extern "C" void _ZN1TD1Ev(); 6: 7: int main() { 8: _ZN1TD1

Re: [PATCH] D11297: PR17829: Functions declared extern "C" with a name matching a mangled C++ function are allowed

andreybokhanko added a comment. John, Thank you for the quick reply! Let me make sure I understand what you said, using my test as an example (BTW, sorry if this is a dumb question -- I asked our local Clang experts, but no-one seems to be 100% sure what to do): 1: struct T { 2: ~T() {}

Re: [PATCH] D11297: PR17829: Functions declared extern "C" with a name matching a mangled C++ function are allowed

andreybokhanko added a comment. John, > Make sense? Yes, absolutely! -- even for me. :-) Thanks a 100! Yours, Andrey http://reviews.llvm.org/D11297 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailma

Re: [PATCH] D11297: PR17829: Functions declared extern "C" with a name matching a mangled C++ function are allowed

andreybokhanko updated this revision to Diff 33083. andreybokhanko added a comment. John, I implemented precisely what you described (or so I believe :-)) Patch is updated; please re-review. This patch implements support for functions, but not variables yet -- the patch is big enough already,

[PATCH] D12402: PR24595: clang-cl fails to compile vswriter.h header from Windows SDK 8.1 in 32 bit mode

andreybokhanko created this revision. andreybokhanko added a reviewer: rnk. andreybokhanko added a subscriber: cfe-commits. As described in PR24595, clang-cl fails to compile vswriter.h header from Windows SDK 8.1 in 32 bit mode. This patch fixes this. More on vswriter.h is here: https://msdn.m

Re: [PATCH] D11297: PR17829: Functions declared extern "C" with a name matching a mangled C++ function are allowed

andreybokhanko updated this revision to Diff 33316. andreybokhanko added a comment. All (but one) of John McCall's comments fixed. http://reviews.llvm.org/D11297 Files: include/clang/Basic/DiagnosticGroups.td include/clang/Basic/DiagnosticSemaKinds.td lib/CodeGen/CGCXX.cpp lib/CodeGen/C

Re: [PATCH] D11297: PR17829: Functions declared extern "C" with a name matching a mangled C++ function are allowed

andreybokhanko marked 3 inline comments as done. andreybokhanko added a comment. John, Thank you for the review! All your comments but one are fixed. See below for details on the single one I didn't manage to get fixed. Andrey Comment at: lib/CodeGen/CodeGenModule.h:354 @@ +

Re: [PATCH] D11297: PR17829: Functions declared extern "C" with a name matching a mangled C++ function are allowed

andreybokhanko updated this revision to Diff 33401. andreybokhanko added a comment. Fixed last note from John McCall. John, please re-review. Yours, Andrey http://reviews.llvm.org/D11297 Files: include/clang/Basic/DiagnosticGroups.td include/clang/Basic/DiagnosticSemaKinds.td lib/CodeGe

Re: [PATCH] D11297: PR17829: Functions declared extern "C" with a name matching a mangled C++ function are allowed

andreybokhanko added inline comments. Comment at: include/clang/Basic/DiagnosticSemaKinds.td:2323 @@ -2323,1 +2322,3 @@ + "definition with same mangled name as another definition">, + InGroup; def err_cyclic_alias : Error< rjmccall wrote: > I'm sorry to bring t

r246438 - PR17829: Proper diagnostic of mangled names conflicts

Author: asbokhan Date: Mon Aug 31 08:20:44 2015 New Revision: 246438 URL: http://llvm.org/viewvc/llvm-project?rev=246438&view=rev Log: PR17829: Proper diagnostic of mangled names conflicts Proper diagnostic and resolution of mangled names conflicts between C++ methods and C functions. This patch

Re: [PATCH] D11297: PR17829: Functions declared extern "C" with a name matching a mangled C++ function are allowed

andreybokhanko added a comment. In http://reviews.llvm.org/D11297#235525, @rjmccall wrote: > Yes, please make it an error. Done. John, thank you for all your patience and explanations! -- I understand that this particular review and patch author required more than the usual measure. :-( > A

Re: [PATCH] D12402: PR24595: clang-cl fails to compile vswriter.h header from Windows SDK 8.1 in 32 bit mode

andreybokhanko updated this revision to Diff 33678. andreybokhanko added a comment. Reid, thanks for looking into this! As I discovered, MS compiler transforms __stdcall to __thiscall for all structors (not only virtual ones) in 32 bit mode. In 64 bit mode, it transforms __stdcall to __cdecl fo

Re: [PATCH] D12402: PR24595: clang-cl fails to compile vswriter.h header from Windows SDK 8.1 in 32 bit mode

andreybokhanko updated this revision to Diff 33945. andreybokhanko added a comment. Patch updated after fixing all (but one) of Reid's comments. http://reviews.llvm.org/D12402 Files: include/clang/Basic/DiagnosticSemaKinds.td include/clang/Sema/DeclSpec.h include/clang/Sema/Sema.h lib/S

Re: [PATCH] D12402: PR24595: clang-cl fails to compile vswriter.h header from Windows SDK 8.1 in 32 bit mode

andreybokhanko marked 4 inline comments as done. Comment at: lib/Sema/SemaType.cpp:5873-5877 @@ +5872,7 @@ + return; + +ToCC = DefaultCC; + +// Issue a warning on ignored calling convention -- except of __stdcall. +// Again, this is what MS compiler does. +if

[PATCH] D14205: [x86] Front-end part of MCU psABI support

andreybokhanko created this revision. andreybokhanko added reviewers: rnk, DavidKreitzer, mkuper. andreybokhanko added a subscriber: cfe-commits. This patch implements front-end parts of MCU psABI (https://docs.google.com/viewer?a=v&pid=sites&srcid=ZGVmYXVsdGRvbWFpbnx4MzJhYml8Z3g6NzFhMGYzMjUzZDQz

r251786 - [x86] Front-end part of MCU psABI support

Author: asbokhan Date: Mon Nov 2 03:54:17 2015 New Revision: 251786 URL: http://llvm.org/viewvc/llvm-project?rev=251786&view=rev Log: [x86] Front-end part of MCU psABI support This patch implements two things in front-end for MCU psABI support: 1) "long double type is the same as double." 2) "N

Re: [PATCH] D14205: [x86] Front-end part of MCU psABI support

andreybokhanko added a comment. Michael, Thanks for the review! As for your comment, I will investigate and fix (if needed). Andrey Comment at: lib/Basic/Targets.cpp:2327 @@ -2325,3 +2326,3 @@ // X87 evaluates with 80 bits "long double" precision. return SSELevel ==

[PATCH] D14285: [x86] Additional small fix for MCU psABI support

andreybokhanko created this revision. andreybokhanko added reviewers: rnk, DavidKreitzer, mkuper. andreybokhanko added a subscriber: cfe-commits. This patch fixes one more thing in MCU psABI support: LongDoubleWidth should be set to 64. http://reviews.llvm.org/D14285 Files: lib/Basic/Targets.

r252156 - [x86] Additional small fix for MCU psABI support

Author: asbokhan Date: Thu Nov 5 06:43:09 2015 New Revision: 252156 URL: http://llvm.org/viewvc/llvm-project?rev=252156&view=rev Log: [x86] Additional small fix for MCU psABI support This patch fixes one more thing in MCU psABI support: LongDoubleWidth should be set to 64. Differential Revisio

[PATCH] D22913: Mention of proper support for "__unaligned" type qualifier in 3.9 clang release notes

andreybokhanko created this revision. andreybokhanko added a reviewer: hans. andreybokhanko added a subscriber: cfe-commits. This add mention of proper support for "__unaligned" type qualifier in 3.9 clang release notes. https://reviews.llvm.org/D22913 Files: docs/ReleaseNotes.rst Index: doc

r277134 - [GCC] Support for __final specifier

Author: asbokhan Date: Fri Jul 29 05:42:48 2016 New Revision: 277134 URL: http://llvm.org/viewvc/llvm-project?rev=277134&view=rev Log: [GCC] Support for __final specifier As reported in bug 28473, GCC supports "final" functionality in pre-C++11 code using the __final keyword. Clang currently sup

Re: r277134 - [GCC] Support for __final specifier

0x89ba9a in main > /mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/tools/driver/driver.cpp:380 > #24 0x7f7d81406f44 in __libc_start_main > (/lib/x86_64-linux-gnu/libc.so.6+0x21f44) > #25 0x80dded in _start > (/mnt/b/sanitizer-buildbot3/sanit

Re: [PATCH] D22970: Ensure Ident_GNU_final is properly initialized in the Parser Initialize function

andreybokhanko accepted this revision. andreybokhanko added a comment. This revision is now accepted and ready to land. LGTM I can commit this patch on Monday, when I will reach my work machine. Andrey Repository: rL LLVM https://reviews.llvm.org/D22970 __

Re: [PATCH] D21678: Fix For pr28288 - Error message in shift of vector values

andreybokhanko added a subscriber: andreybokhanko. andreybokhanko added a comment. @uweigand Ulrich, any objections here? If not, I will commit this patch tomorrow (as the author, Vladimir, doesn't have commit access yet). Andrey Repository: rL LLVM https://reviews.llvm.org/D21678 __

r278501 - Fix For pr28288 - Error message in shift of vector values

Author: asbokhan Date: Fri Aug 12 06:22:12 2016 New Revision: 278501 URL: http://llvm.org/viewvc/llvm-project?rev=278501&view=rev Log: Fix For pr28288 - Error message in shift of vector values This fixes an error in type checking of shift of vector values. Patch by Vladimir Yakovlev. Differenti

Re: [PATCH] D16626: [x86] Correct setting of WIntType for MCU target

andreybokhanko added a comment. Ping! http://reviews.llvm.org/D16626 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D16851: Update of "GCC extensions not implemented yet" in Clang User's Manual

andreybokhanko created this revision. andreybokhanko added a reviewer: rsmith. andreybokhanko added a subscriber: cfe-commits. #pragma weak, global register variables and static initialization of flexible array members are supported, so I removed them from "GCC extensions not implemented yet" li

r259780 - [x86] Correct setting of WIntType for MCU target

Author: asbokhan Date: Thu Feb 4 05:54:45 2016 New Revision: 259780 URL: http://llvm.org/viewvc/llvm-project?rev=259780&view=rev Log: [x86] Correct setting of WIntType for MCU target Differential Revision: http://reviews.llvm.org/D16626 Modified: cfe/trunk/lib/Basic/Targets.cpp cfe/trun

Re: [PATCH] D16846: PR26449: Fixes for bugs in __builtin_classify_type implementation

andreybokhanko updated this revision to Diff 46908. andreybokhanko added a comment. John, thank you for the review! I refactored EvaluateBuiltinClassifyType according to your comments; please re-review. Yours, Andrey http://reviews.llvm.org/D16846 Files: lib/AST/ExprConstant.cpp test/Sem

Re: [PATCH] D16851: Update of "GCC extensions not implemented yet" in Clang User's Manual

andreybokhanko added a comment. Ping http://reviews.llvm.org/D16851 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D16846: PR26449: Fixes for bugs in __builtin_classify_type implementation

andreybokhanko updated this revision to Diff 47475. andreybokhanko added a comment. John, thanks for the re-review! -- I did as you advised, and added *a lot* of switches. :-) Patch updated; please re-review again. http://reviews.llvm.org/D16846 Files: lib/AST/ExprConstant.cpp test/Sema/b

Re: [PATCH] D16851: Update of "GCC extensions not implemented yet" in Clang User's Manual

andreybokhanko added a comment. In http://reviews.llvm.org/D16851#349537, @silvas wrote: > Assuming the features are implemented this seems fine. LGTM. Thank you! Comment at: docs/UsersManual.rst:1698 @@ -1697,3 @@ -- clang does not support #pragma weak (`bug - 3679

r260506 - Update of "GCC extensions not implemented yet" in Clang User's Manual

Author: asbokhan Date: Thu Feb 11 04:36:06 2016 New Revision: 260506 URL: http://llvm.org/viewvc/llvm-project?rev=260506&view=rev Log: Update of "GCC extensions not implemented yet" in Clang User's Manual #pragma weak, global register variables and static initialization of flexible array members

r260519 - Partial revert of rL260506.

Author: asbokhan Date: Thu Feb 11 07:27:02 2016 New Revision: 260519 URL: http://llvm.org/viewvc/llvm-project?rev=260519&view=rev Log: Partial revert of rL260506. After some experiments I discovered that clang doesn't support static initialization of flexible array members in full, so restored th

r260881 - PR26449: Fixes for bugs in __builtin_classify_type implementation

Author: asbokhan Date: Mon Feb 15 04:39:04 2016 New Revision: 260881 URL: http://llvm.org/viewvc/llvm-project?rev=260881&view=rev Log: PR26449: Fixes for bugs in __builtin_classify_type implementation This patch fixes the following bugs in __builtin_classify_type implementation: 1) Support for me

Re: [PATCH] D16846: PR26449: Fixes for bugs in __builtin_classify_type implementation

andreybokhanko added a comment. John, thank you for all these tireless re-reviews -- very much appreciated! Yours, Andrey Repository: rL LLVM http://reviews.llvm.org/D16846 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llv

r260882 - PR26449: Tests for builtin_classify_type fix

Author: asbokhan Date: Mon Feb 15 04:44:27 2016 New Revision: 260882 URL: http://llvm.org/viewvc/llvm-project?rev=260882&view=rev Log: PR26449: Tests for builtin_classify_type fix In my previous commit (rL260881) I forget to svn add tests. This commit adds them. Differential Revision: http://rev

[PATCH] D17330: PR26648: "inline" shouldn't be recognized as a C keyword in MSVC 2013 compatibility mode

andreybokhanko created this revision. andreybokhanko added reviewers: rnk, majnemer, thakis. andreybokhanko added a subscriber: cfe-commits. See PR26648 for full description of the problem. Here I added a new keyword flag (KEYNOMS18_C) for keywords that shouldn't be enabled in MSVC 2013 mode for

Re: [PATCH] D17330: PR26648: "inline" shouldn't be recognized as a C keyword in MSVC 2013 compatibility mode

andreybokhanko added a comment. In http://reviews.llvm.org/D17330#354730, @majnemer wrote: > Why not just stick clang in C90 mode when targeting C if the > -fms-compatibility-version is 18? > > We have similar code for the C++ mode in > https://github.com/llvm-mirror/clang/blob/master/lib/Drive

Re: [PATCH] D17330: PR26648: "inline" shouldn't be recognized as a C keyword in MSVC 2013 compatibility mode

OK, so is initial patch a good one? ;-) Andrey On Wed, Feb 17, 2016 at 8:06 PM, David Majnemer wrote: > majnemer added a comment. > > In http://reviews.llvm.org/D17330#354755, @andreybokhanko wrote: > >> In http://reviews.llvm.org/D17330#354730, @majnemer wrote: >> >> > Why not just stick clang

Re: [PATCH] D17330: PR26648: "inline" shouldn't be recognized as a C keyword in MSVC 2013 compatibility mode

andreybokhanko abandoned this revision. andreybokhanko added a comment. @rnk, fair enough. OK, please consider this review request dropped. Andrey http://reviews.llvm.org/D17330 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.l

[PATCH] D17444: PR26672: [MSVC] Clang does not recognize "static_assert" keyword in C mode

andreybokhanko created this revision. andreybokhanko added reviewers: rnk, majnemer, thakis. andreybokhanko added a subscriber: cfe-commits. MS compiler recognizes "static_assert" keyword is C mode as well, while clang-cl doesn't. This patch fixes this. http://reviews.llvm.org/D17444 Files: i

Re: [PATCH] D17444: PR26672: [MSVC] Clang does not recognize "static_assert" keyword in C mode

43 PM, Aaron Ballman wrote: > On Fri, Feb 19, 2016 at 8:08 AM, Andrey Bokhanko via cfe-commits > wrote: >> andreybokhanko created this revision. >> andreybokhanko added reviewers: rnk, majnemer, thakis. >> andreybokhanko added a subscriber: cfe-commits. >> >> MS co

Re: [PATCH] D17444: PR26672: [MSVC] Clang does not recognize "static_assert" keyword in C mode

andreybokhanko updated this revision to Diff 48591. andreybokhanko added a comment. Patch updated in response to Reid's proposal (to introduce KEYMSCOMPAT). (To clarify, I agree with Aaron that we should wait for MS' response first. Though I frankly don't expect them to accept recognition of "st

Re: [PATCH] D17619: [MSVC Compat] Don't evaluate member base expressions w/o side effects

andreybokhanko added a comment. @majnemer, this error in the header is now gone. Thank you! On to more errors! ;-) Yours, Andrey Repository: rL LLVM http://reviews.llvm.org/D17619 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://l

[PATCH] D19654: PR27132: Proper mangling for __unaligned qualifier (now with PR27367 fixed)

andreybokhanko created this revision. andreybokhanko added reviewers: rnk, thakis, majnemer. andreybokhanko added a subscriber: cfe-commits. This is exactly same patch as http://reviews.llvm.org/D18596 (already reviewed and LGTMed by rnk), with a couple of changes to fix PR27367: * A check for v

Re: [PATCH] D19654: PR27132: Proper mangling for __unaligned qualifier (now with PR27367 fixed)

andreybokhanko updated this revision to Diff 55588. andreybokhanko added a comment. Fixed a bug uncovered by David Majnemer's review; added tests he asked for. http://reviews.llvm.org/D19654 Files: include/clang/AST/Type.h include/clang/Basic/AddressSpaces.h include/clang/Basic/Attr.td

Re: [PATCH] D19654: PR27132: Proper mangling for __unaligned qualifier (now with PR27367 fixed)

andreybokhanko marked 3 inline comments as done. andreybokhanko added a comment. David, thank you for the review! In http://reviews.llvm.org/D19654#416408, @majnemer wrote: > It would be good to have a test for the variable template case: > > template > T x; > > auto g() { return x; } >

Re: [PATCH] D19654: PR27132: Proper mangling for __unaligned qualifier (now with PR27367 fixed)

andreybokhanko marked 3 inline comments as done. Comment at: lib/AST/MicrosoftMangle.cpp:1583-1584 @@ -1579,2 +1582,4 @@ case QMM_Result: +// Presence of __unaligned qualifier shouldn't affect mangling here. +Quals.removeUnaligned(); if ((!IsPointer && Quals) || is

Re: [PATCH] D19654: PR27132: Proper mangling for __unaligned qualifier (now with PR27367 fixed)

andreybokhanko marked an inline comment as done. Comment at: lib/AST/MicrosoftMangle.cpp:1583-1584 @@ -1579,2 +1582,4 @@ case QMM_Result: +// Presence of __unaligned qualifier shouldn't affect mangling here. +Quals.removeUnaligned(); if ((!IsPointer && Quals) || is

Re: [PATCH] D19654: PR27132: Proper mangling for __unaligned qualifier (now with PR27367 fixed)

andreybokhanko added a comment. David, just noticed that your first question doesn't have a redefinition. For this program: __unaligned int unaligned_foo3() { return 0; } auto z = unaligned_foo3(); Both MS and us mangle z the same: ?z@@3HA Yours, Andrey http://reviews.llvm.org/D19654 ___

r268727 - [MSVC] Implementation of __unaligned as a proper type qualifier

Author: asbokhan Date: Fri May 6 06:47:55 2016 New Revision: 268727 URL: http://llvm.org/viewvc/llvm-project?rev=268727&view=rev Log: [MSVC] Implementation of __unaligned as a proper type qualifier This patch implements __unaligned (MS extension) as a proper type qualifier (before that, it was i

Re: [PATCH] D19654: PR27132: Proper mangling for __unaligned qualifier (now with PR27367 fixed)

andreybokhanko added a comment. David, thank you for the thorough review! -- it definitely made the patch stronger and me even more paranoid than the rest of Intel. :-) In http://reviews.llvm.org/D19654#422445, @majnemer wrote: > FYI, we will also want to update `getAddrOfCXXCatchHandler` and

Re: r268727 - [MSVC] Implementation of __unaligned as a proper type qualifier

tion failed: CVR && "unexpected qualifiers mismatch", file >> C:\b\build\slave\ClangToTWin64\build\src\third_party\llvm\tools\clang\lib\Sema\SemaOverload.cpp, >> line 9118 >> >> Can you revert again? Should be easy to repro, just include in a >> cc

[PATCH] D20103: PR27132: Proper mangling for __unaligned qualifier (now with both PR27367 and PR27666 fixed)

andreybokhanko created this revision. andreybokhanko added reviewers: rnk, majnemer, thakis. andreybokhanko added a subscriber: cfe-commits. This is exactly same patch as http://reviews.llvm.org/D19654 (already reviewed and LGTMed by majnemer), with a couple of changes to fix PR27666: * __unalig

Re: [PATCH] D20103: PR27132: Proper mangling for __unaligned qualifier (now with both PR27367 and PR27666 fixed)

andreybokhanko updated this revision to Diff 56874. andreybokhanko added a comment. Patch updated to address David's comments. Yours, Andrey http://reviews.llvm.org/D20103 Files: include/clang/AST/Type.h include/clang/Basic/AddressSpaces.h include/clang/Basic/Attr.td include/clang/Basi

Re: [PATCH] D20103: PR27132: Proper mangling for __unaligned qualifier (now with both PR27367 and PR27666 fixed)

andreybokhanko marked 3 inline comments as done. andreybokhanko added a comment. In http://reviews.llvm.org/D20103#425855, @majnemer wrote: > Can we test pointers to data members? Is it possible to have `__unaligned int > *S::*` or `int *S::* __unaligned` or even `__unaligned int *S::* __unalign

r269220 - [MSVC] Implementation of __unaligned as a proper type qualifier

Author: asbokhan Date: Wed May 11 13:38:21 2016 New Revision: 269220 URL: http://llvm.org/viewvc/llvm-project?rev=269220&view=rev Log: [MSVC] Implementation of __unaligned as a proper type qualifier This patch implements __unaligned (MS extension) as a proper type qualifier (before that, it was i

[PATCH] D20437: [MSVC] Support of __unaligned qualifier for function types

andreybokhanko created this revision. andreybokhanko added reviewers: rnk, majnemer. andreybokhanko added a subscriber: cfe-commits. This adds support of MS-specific "__unaligned" qualifier for function types and fixes errors described by David Majnemer in this thread: http://lists.llvm.org/pipe

Re: r269220 - [MSVC] Implementation of __unaligned as a proper type qualifier

clang::ExceptionSpecificationType, >> clang::SourceRange, ParsedType *, clang::SourceRange *, unsigned int, >> clang::Expr *, CachedTokens *, clang::SourceLocation, >> clang::SourceLocation, clang::Declarator &, TypeResult): Assertion >> `I.Fun.TypeQuals == TypeQuals && &

Re: [PATCH] D20437: [MSVC] Support of __unaligned qualifier for function types

andreybokhanko updated this revision to Diff 57907. andreybokhanko added a comment. Added a test for __unaligned arrays. http://reviews.llvm.org/D20437 Files: include/clang/AST/Type.h include/clang/Sema/DeclSpec.h lib/AST/DeclCXX.cpp lib/AST/MicrosoftMangle.cpp lib/Sema/DeclSpec.cpp

Re: [PATCH] D20437: [MSVC] Support of __unaligned qualifier for function types

andreybokhanko marked 2 inline comments as done. Comment at: include/clang/Sema/DeclSpec.h:1152-1169 @@ -1153,19 +1151,20 @@ struct ArrayTypeInfo : TypeInfoCommon { -/// The type qualifiers for the array: const/volatile/restrict/_Atomic. -unsigned TypeQuals : 4; +

[PATCH] D18596: [MSVC] PR27132: Proper mangling for __unaligned qualifier

andreybokhanko created this revision. andreybokhanko added reviewers: rnk, majnemer. andreybokhanko added a subscriber: cfe-commits. This patch implements proper mangling for MS-specific "__unaligned" qualifier. The mangling part itself is tiny; most of the patch is required to convert "__unalig

Re: [PATCH] D18596: [MSVC] PR27132: Proper mangling for __unaligned qualifier

andreybokhanko updated this revision to Diff 52208. andreybokhanko added a comment. Resolved [some of] comments made by Aaron and Reid. http://reviews.llvm.org/D18596 Files: include/clang/AST/Type.h include/clang/Basic/Attr.td include/clang/Basic/AttrDocs.td lib/AST/MicrosoftMangle.cpp

Re: [PATCH] D18596: [MSVC] PR27132: Proper mangling for __unaligned qualifier

andreybokhanko marked 3 inline comments as done. andreybokhanko added a comment. Aaron, Reid, David, thank you for the review! I resolved some of your comments. As for In http://reviews.llvm.org/D18596#386841, @aaron.ballman wrote: > I'd like to see some Sema tests for sanity checking; like app

Re: [PATCH] D18596: [MSVC] PR27132: Proper mangling for __unaligned qualifier

andreybokhanko updated this revision to Diff 52662. andreybokhanko added a comment. Added Sema test, as per Aaron's and Reid's request. http://reviews.llvm.org/D18596 Files: include/clang/AST/Type.h include/clang/Basic/Attr.td include/clang/Basic/AttrDocs.td lib/AST/MicrosoftMangle.cpp

Re: [PATCH] D18596: [MSVC] PR27132: Proper mangling for __unaligned qualifier

andreybokhanko added a comment. In http://reviews.llvm.org/D18596#388295, @aaron.ballman wrote: > Regression is a bit of a question mark, to me depending on the diagnostic. I > think warning the user "this has absolutely no effect" is a reasonable > diagnostic for that situation -- the user wro

Re: [PATCH] D18596: [MSVC] PR27132: Proper mangling for __unaligned qualifier

andreybokhanko added a comment. In http://reviews.llvm.org/D18596#392341, @majnemer wrote: > In http://reviews.llvm.org/D18596#392098, @andreybokhanko wrote: > > > Do we want to do this for an ignored qualifier? I don't see any practical > > purpose. > > > It's not ignored for Windows on ARM.

Re: [PATCH] D18596: [MSVC] PR27132: Proper mangling for __unaligned qualifier

andreybokhanko updated this revision to Diff 53022. andreybokhanko added a comment. This patch implements "__unaligned" as a qualifier (as per David Majnemer's request). Most of the changes are miscellaneous small stuff one has to add when adding a new qualifier. Other notable things are: - O

Re: [PATCH] D18596: [MSVC] PR27132: Proper mangling for __unaligned qualifier

andreybokhanko updated this revision to Diff 53509. andreybokhanko added a comment. 1. Added more comprehensive overloading tests 2. Added a warning (in C mode) / error (in C++ mode) on __unaligned to non-__unaligned type conversion Andrey http://reviews.llvm.org/D18596 Files: include/clang

Re: [PATCH] D18596: [MSVC] PR27132: Proper mangling for __unaligned qualifier

andreybokhanko marked an inline comment as done. Comment at: test/SemaCXX/MicrosoftExtensions.cpp:89 @@ +88,3 @@ +void foo_unaligned(int *arg) {} +void foo_unaligned(__unaligned int *arg) {} +void foo_unaligned(int arg) {} // expected-note {{previous definition is here}} -

r266415 - [MSVC Compat] Implementation of __unaligned (MS extension) as a type qualifier

Author: asbokhan Date: Fri Apr 15 03:03:51 2016 New Revision: 266415 URL: http://llvm.org/viewvc/llvm-project?rev=266415&view=rev Log: [MSVC Compat] Implementation of __unaligned (MS extension) as a type qualifier This patch implements __unaligned as a type qualifier; before that, it was modeled

Re: [PATCH] D18596: [MSVC] PR27132: Proper mangling for __unaligned qualifier

andreybokhanko marked an inline comment as done. andreybokhanko added a comment. Reid, thank you! Yours, Andrey Repository: rL LLVM http://reviews.llvm.org/D18596 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-

Re: [PATCH] D20437: [MSVC] Support of __unaligned qualifier for function types

andreybokhanko marked 3 inline comments as done. Comment at: lib/Sema/SemaExprCXX.cpp:937 @@ -936,2 +936,3 @@ + CXXThisTypeQuals &= Qualifiers::FastMask; S.CXXThisTypeOverride majnemer wrote: > Can you add a comment for this line. Done. Thank you for th

r270834 - [MSVC] Support for __unaligned qualifier in functions

Author: asbokhan Date: Thu May 26 05:06:01 2016 New Revision: 270834 URL: http://llvm.org/viewvc/llvm-project?rev=270834&view=rev Log: [MSVC] Support for __unaligned qualifier in functions This implements support for MS-specific __unaligned qualifier in functions and makes the following test case

Re: r269220 - [MSVC] Implementation of __unaligned as a proper type qualifier

> clang::SourceLocation, clang::ExceptionSpecificationType, >>> clang::SourceRange, ParsedType *, clang::SourceRange *, unsigned int, >>> clang::Expr *, CachedTokens *, clang::SourceLocation, >>> clang::SourceLocation, clang::Declarator &, TypeResult): Assertion >&

Re: [PATCH] D18035: [GCC] PR23529 Mangler part of attrbute abi_tag support

andreybokhanko added a comment. In http://reviews.llvm.org/D18035#448057, @hfinkel wrote: > We just received the first draft of that specification yesterday. Is this specification confidential? If not, why it hasn't been made available in this code review? Most puzzlingly, why it hasn't been s

Re: [PATCH] D18035: [GCC] PR23529 Mangler part of attrbute abi_tag support

andreybokhanko added a comment. In http://reviews.llvm.org/D18035#450247, @hfinkel wrote: > The link was posted here: > http://sourcerytools.com/pipermail/cxx-abi-dev/2016-June/002919.html - which > is the mailing list where the C++ ABI specification is discussed. Ah, I see... Dmitry told me

Re: RFC: Default language standard mode policy

It doesn't break anything for us and in general the proposal make sense to me. Yours, Andrey = Software Engineer Intel Compiler Team On Wed, Jun 29, 2016 at 10:09 PM, Richard Smith via cfe-commits < cfe-commits@lists.llvm.org> wrote: > Hi all! > > I'd like to establish a policy for Clang's

Re: [PATCH] D17444: PR26672: [MSVC] Clang does not recognize "static_assert" keyword in C mode

Now I'm completely confused... :-) Can we rely that this MS engineer has enough authority to declare this to be a bug? And more importantly -- is MS willing to fix the [supposed] bug in future MSVC compilers? I frankly don't think so... Either way, it's up to Reid to decide what to do. Reid? Yo

Re: [PATCH] D17444: PR26672: [MSVC] Clang does not recognize "static_assert" keyword in C mode

andreybokhanko abandoned this revision. andreybokhanko added a comment. It seems the discussion (http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20160229/thread.html#151860) concluded that we don't want this fix to be committed until we see some compelling code that relies on "static_as

Re: [PATCH] D15686: PR25910: clang allows two var definitions with the same mangled name

andreybokhanko added a comment. Ping! http://reviews.llvm.org/D15686 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D15686: PR25910: clang allows two var definitions with the same mangled name

andreybokhanko added inline comments. Comment at: lib/CodeGen/CodeGenModule.cpp:1235-1243 @@ -1235,9 +1234,11 @@ // different type. -// FIXME: Support for variables is not implemented yet. -if (isa(D.getDecl())) - GV = cast(GetAddrOfGlobal(D, /*IsForDefinition=*

Re: [PATCH] D15686: PR25910: clang allows two var definitions with the same mangled name

andreybokhanko updated this revision to Diff 43982. andreybokhanko marked an inline comment as done. andreybokhanko added a comment. Fixed tra's note. http://reviews.llvm.org/D15686 Files: lib/CodeGen/CodeGenModule.cpp lib/CodeGen/CodeGenModule.h test/CodeGenCXX/duplicate-mangled-name.cpp

Re: [PATCH] D15686: PR25910: clang allows two var definitions with the same mangled name

andreybokhanko updated the summary for this revision. andreybokhanko updated this revision to Diff 44425. andreybokhanko marked 7 inline comments as done. andreybokhanko added a comment. Fixed tra's notes. All the fixes are local, logic of the patch is not changed. http://reviews.llvm.org/D15686

Re: [PATCH] D15686: PR25910: clang allows two var definitions with the same mangled name

andreybokhanko added a comment. In http://reviews.llvm.org/D15686#319725, @tra wrote: > A better description of the problem would help. PR itself is somewhat short > on details. Sorry for being not clear. I expected my main reviewer to be @rjmccall, who knows exactly what the problem is. > I

Re: [PATCH] D15686: PR25910: clang allows two var definitions with the same mangled name

andreybokhanko added a comment. In http://reviews.llvm.org/D15686#325266, @rnk wrote: > I thought we already addressed this issue with @rjmccall and decided that, if > the user intentionally declares extern "C" variables with an _Z prefix, then > we know they are intentionally attempting to nam

[PATCH] D16138: Correct setting of UserLabelPrefix for MCU target

andreybokhanko created this revision. andreybokhanko added reviewers: rnk, mkuper. andreybokhanko added a subscriber: cfe-commits. Correct setting of UserLabelPrefix for MCU target http://reviews.llvm.org/D16138 Files: lib/Basic/Targets.cpp test/Preprocessor/elfiamcu-predefines.c Index: lib

Re: [PATCH] D16138: Correct setting of UserLabelPrefix for MCU target

andreybokhanko updated this revision to Diff 44726. andreybokhanko added a comment. Patch updated to be in line with llvm trunk. Sorry for the noise. http://reviews.llvm.org/D16138 Files: lib/Basic/Targets.cpp test/Preprocessor/elfiamcu-predefines.c Index: lib/Basic/Targets.cpp ===

r257754 - PR25910: clang allows two var definitions with the same mangled name

Author: asbokhan Date: Thu Jan 14 04:41:16 2016 New Revision: 257754 URL: http://llvm.org/viewvc/llvm-project?rev=257754&view=rev Log: PR25910: clang allows two var definitions with the same mangled name Proper diagnostic and resolution of mangled names' conflicts in variables. When there is a de

  1   2   >