Re: [PATCH] D11360: Proposed patch to prevent the creation of empty (forwarding) blocks resulting from nested ifs.

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

[clang] [llvm] [LTO] A static relocation model can override the PIC level wrt treating external address as directly accessible (PR #65512)

https://github.com/wolfy1961 closed https://github.com/llvm/llvm-project/pull/65512 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [LTO] A static relocation model can override the PIC level wrt treating external address as directly accessible (PR #65512)

wolfy1961 wrote: Superseded by PR [70014](https://github.com/llvm/llvm-project/pull/70014). https://github.com/llvm/llvm-project/pull/65512 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-comm

[clang] [LTO] A static relocation model can override the PIC level wrt treating external address as directly accessible (PR #65512)

wolfy1961 wrote: Ping... Any takers? https://github.com/llvm/llvm-project/pull/65512 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] 8564e2f - [Inlining] Add a clang option to limit inlining of functions

Author: Wolfgang Pieb Date: 2022-08-18T11:56:24-07:00 New Revision: 8564e2fea559c58fecab3c7c01acf498bbe7820a URL: https://github.com/llvm/llvm-project/commit/8564e2fea559c58fecab3c7c01acf498bbe7820a DIFF: https://github.com/llvm/llvm-project/commit/8564e2fea559c58fecab3c7c01acf498bbe7820a.diff

[clang] [LTO] A static relocation model can override the PIC level wrt treating external address as directly accessible (PR #65512)

https://github.com/wolfy1961 updated https://github.com/llvm/llvm-project/pull/65512 >From 2e5abcec65c189fbb7f789816373969ee81ecfa5 Mon Sep 17 00:00:00 2001 From: wpieb Date: Tue, 5 Sep 2023 10:43:23 -0700 Subject: [PATCH 1/2] [LTO] A static relocation model can override the PIC level wrt trea

[clang] [LTO] A static relocation model can override the PIC level wrt treating external address as directly accessible (PR #65512)

wolfy1961 wrote: Ping ... https://github.com/llvm/llvm-project/pull/65512 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [LTO] A static relocation model can override the PIC level wrt treating external address as directly accessible (PR #65512)

wolfy1961 wrote: Ping ... https://github.com/llvm/llvm-project/pull/65512 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [LTO] A static relocation model can override the PIC level wrt treating external address as directly accessible (PR #65512)

https://github.com/wolfy1961 review_requested https://github.com/llvm/llvm-project/pull/65512 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [LTO] A static relocation model can override the PIC level wrt treating external address as directly accessible (PR #65512)

https://github.com/wolfy1961 created https://github.com/llvm/llvm-project/pull/65512: As described in issue [#64999](https://github.com/llvm/llvm-project/issues/64999), commit [e018cbf7208](https://github.com/llvm/llvm-project/commit/e018cbf7208b3d34f18997ddee84c66cee32fb1b) caused the symbol

[clang] [LTO] A static relocation model can override the PIC level wrt treating external address as directly accessible (PR #65512)

https://github.com/wolfy1961 review_requested https://github.com/llvm/llvm-project/pull/65512 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [LTO] A static relocation model can override the PIC level wrt treating external address as directly accessible (PR #65512)

https://github.com/wolfy1961 review_requested https://github.com/llvm/llvm-project/pull/65512 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [LTO] A static relocation model can override the PIC level wrt treating external address as directly accessible (PR #65512)

https://github.com/wolfy1961 review_requested https://github.com/llvm/llvm-project/pull/65512 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [LTO] A static relocation model can override the PIC level wrt treating external address as directly accessible (PR #65512)

https://github.com/wolfy1961 review_requested https://github.com/llvm/llvm-project/pull/65512 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang-tools-extra] f805c60 - Revert "[clangd] Implement rename by using SelectionTree and findExplicitReferences."

Author: Wolfgang Pieb Date: 2019-11-18T15:39:05-08:00 New Revision: f805c60a093325c16ce4200d2615ef48555d9cb8 URL: https://github.com/llvm/llvm-project/commit/f805c60a093325c16ce4200d2615ef48555d9cb8 DIFF: https://github.com/llvm/llvm-project/commit/f805c60a093325c16ce4200d2615ef48555d9cb8.diff

r317047 - Fix for PR33930. Short-circuit metadata mapping when cloning a varargs thunk.

Author: wolfgangp Date: Tue Oct 31 15:49:48 2017 New Revision: 317047 URL: http://llvm.org/viewvc/llvm-project?rev=317047&view=rev Log: Fix for PR33930. Short-circuit metadata mapping when cloning a varargs thunk. The cloning happens before all metadata nodes are resolved. Prevent the value mapper

r317053 - Making a couple of tests a bit more flexible wrt thunk mangling. Fixes checkin for r317047.

Author: wolfgangp Date: Tue Oct 31 17:01:20 2017 New Revision: 317053 URL: http://llvm.org/viewvc/llvm-project?rev=317053&view=rev Log: Making a couple of tests a bit more flexible wrt thunk mangling. Fixes checkin for r317047. Modified: cfe/trunk/test/CodeGenCXX/tmp-md-nodes1.cpp cfe/tr

[clang] 634430d - [MSVC][dllexport/dllimport] Propagate a dllexport/dllimport attribute to template baseclass

Author: Wolfgang Pieb Date: 2023-03-15T11:47:54-07:00 New Revision: 634430d5857e395cff62534b11c460f51c6c846a URL: https://github.com/llvm/llvm-project/commit/634430d5857e395cff62534b11c460f51c6c846a DIFF: https://github.com/llvm/llvm-project/commit/634430d5857e395cff62534b11c460f51c6c846a.diff

[clang] 477f9ce - [MSCV][dllexport/dllimport][PS] Allow UniqueExternal linkage classes with dllexport/dllimport

Author: Wolfgang Pieb Date: 2023-03-29T18:15:04Z New Revision: 477f9cea77e6d55ecddaafbedccd418750c40dbd URL: https://github.com/llvm/llvm-project/commit/477f9cea77e6d55ecddaafbedccd418750c40dbd DIFF: https://github.com/llvm/llvm-project/commit/477f9cea77e6d55ecddaafbedccd418750c40dbd.diff LOG

[clang] 5d07e04 - [TLS]: Clamp the alignment of TLS global variables if required by the target

Author: Wolfgang Pieb Date: 2023-02-08T10:34:56-08:00 New Revision: 5d07e0448e38d4be0cc7b1079d72b5e3644e941c URL: https://github.com/llvm/llvm-project/commit/5d07e0448e38d4be0cc7b1079d72b5e3644e941c DIFF: https://github.com/llvm/llvm-project/commit/5d07e0448e38d4be0cc7b1079d72b5e3644e941c.diff

r276361 - Reverting r275115 which caused PR28634.

Author: wolfgangp Date: Thu Jul 21 18:28:18 2016 New Revision: 276361 URL: http://llvm.org/viewvc/llvm-project?rev=276361&view=rev Log: Reverting r275115 which caused PR28634. When empty (forwarding) basic blocks that are referenced by user labels are removed, incorrect code may be generated. Re

r277094 - Change a test to be less prone to random failures due to

Author: wolfgangp Date: Thu Jul 28 19:54:13 2016 New Revision: 277094 URL: http://llvm.org/viewvc/llvm-project?rev=277094&view=rev Log: Change a test to be less prone to random failures due to unintended matches of label numbers to debug metadata handles in release builds. Modified: cfe/trunk

Re: [PATCH] D11360: Proposed patch to prevent the creation of empty (forwarding) blocks resulting from nested ifs.

wolfgangp updated this revision to Diff 61987. wolfgangp added a comment. Herald added a subscriber: mehdi_amini. Updating this patch against a recent revision. http://reviews.llvm.org/D11360 Files: lib/CodeGen/CGStmt.cpp test/CodeGen/forwarding-blocks-if.c Index: test/CodeGen/forwarding-b

Re: [PATCH] D11360: Proposed patch to prevent the creation of empty (forwarding) blocks resulting from nested ifs.

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

Re: [PATCH] D11360: Proposed patch to prevent the creation of empty (forwarding) blocks resulting from nested ifs.

wolfgangp updated this revision to Diff 62916. wolfgangp added a comment. Addressed review comments: documented changes and clang-formatted the test case. http://reviews.llvm.org/D11360 Files: lib/CodeGen/CGStmt.cpp test/CodeGen/forwarding-blocks-if.c Index: test/CodeGen/forwarding-blocks-

Re: [PATCH] D11360: Proposed patch to prevent the creation of empty (forwarding) blocks resulting from nested ifs.

wolfgangp added inline comments. Comment at: test/CodeGen/forwarding-blocks-if.c:17 @@ +16,3 @@ +return 0; +} + mehdi_amini wrote: > Any reason to not stick with LLVM coding convention here? No reason, thanks for pointing this out. http://reviews.llvm.org/D1

r275115 - Prevent the creation of empty (forwarding) blocks resulting from nested ifs.

Author: wolfgangp Date: Mon Jul 11 17:22:23 2016 New Revision: 275115 URL: http://llvm.org/viewvc/llvm-project?rev=275115&view=rev Log: Prevent the creation of empty (forwarding) blocks resulting from nested ifs. Summary: Nested if statements can generate empty BBs whose terminator branches unco

r275127 - Fix test submitted with r275115 (failed on ppc64 buildbots).

Author: wolfgangp Date: Mon Jul 11 18:20:28 2016 New Revision: 275127 URL: http://llvm.org/viewvc/llvm-project?rev=275127&view=rev Log: Fix test submitted with r275115 (failed on ppc64 buildbots). Modified: cfe/trunk/test/CodeGen/forwarding-blocks-if.c Modified: cfe/trunk/test/CodeGen/forwar

r275128 - Correcting the previous fix for test submitted with r275115.

Author: wolfgangp Date: Mon Jul 11 18:27:19 2016 New Revision: 275128 URL: http://llvm.org/viewvc/llvm-project?rev=275128&view=rev Log: Correcting the previous fix for test submitted with r275115. Modified: cfe/trunk/test/CodeGen/forwarding-blocks-if.c Modified: cfe/trunk/test/CodeGen/forwar

Re: [PATCH] D8822: Proposed fix for PR23076 (conditional branch debug line info)

wolfgangp added a comment. > Clang (with patch) > 3, 5, 4, 5, 7 > 9, 11, 10, 11, 14 > > So that's somewhat problematic - we shouldn't visit 11 at all. (but we are > today, as is GCC... so maybe NBD?) Well, if op&& is overloaded, wouldn't we lose the short-circuit property? If so it ma

[clang] d789ea7 - [Diagnostics] Don't drop a statically set NoWarningAsError flag during option processing

Author: Wolfgang Pieb Date: 2022-01-10T16:38:01-08:00 New Revision: d789ea713372d44e50ff52a85a198ac6bbedaef9 URL: https://github.com/llvm/llvm-project/commit/d789ea713372d44e50ff52a85a198ac6bbedaef9 DIFF: https://github.com/llvm/llvm-project/commit/d789ea713372d44e50ff52a85a198ac6bbedaef9.diff

[clang] [Clang][CodeGen] Emit fake uses before musttail calls (PR #136867)

wolfy1961 wrote: LGTM https://github.com/llvm/llvm-project/pull/136867 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D50089: [DWARF v4] Suppressing the __debug_ranges section when there are no ranges

wolfgangp created this revision. wolfgangp added reviewers: aprantl, JDevlieghere, dblaikie. One of the clang tests in debuginfo-tests (apple-accel.cpp) insists on checking for the existence of the __debug_ranges section (it requires darwin) even for trivial code which doesn't need any range lis

[PATCH] D50089: [DWARF v4] Suppressing the __debug_ranges section when there are no ranges

This revision was automatically updated to reflect the committed changes. Closed by commit rL338437: [DWARF] Do not create a .debug_ranges section when no ranges are needed. (authored by wolfgangp, committed by ). Changed prior to commit: https://reviews.llvm.org/D50089?vs=158328&id=158378#toc

[PATCH] D41044: Implementation of -fextend-lifetimes and -fextend-this-ptr to aid with debugging of optimized code

wolfgangp updated this revision to Diff 175307. wolfgangp added a comment. Rebased on r347577 with some test cases. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D41044/new/ https://reviews.llvm.org/D41044 Files: include/clang/Driver/Options.td include/clang/Frontend/CodeGenOptions.

[PATCH] D80293: [clangd] Run PreambleThread in async mode behind a flag

wolfgangp added a comment. Hi! Shortly after this patch went in, we started to see intermittent failures with the unittest TUSchedulerTests.ManyUpdates. The build server (Windows) we're running it on is quite powerful and our own hand-run tests only take about 400 ms, so we don't really unders

[PATCH] D41044: Implementation of -fextend-lifetimes and -fextend-this-ptr to aid with debugging of optimized code

wolfgangp created this revision. Herald added a subscriber: JDevlieghere. The patch implements the clang support for generating artificial uses of local variables and parameters to aid with debugging of optimized code. I presented this concept in my lightning talk "Debugging of optimized code: E

[PATCH] D41044: Implementation of -fextend-lifetimes and -fextend-this-ptr to aid with debugging of optimized code

wolfgangp added a comment. A quick note on usage: Compile your source with "clang -O2 -g -c -fextend-lifetimes foo.cpp" to see the effects (or use -fextend-this-ptr if you just want to extend the lifetime of 'this'). https://reviews.llvm.org/D41044 __

[PATCH] D122865: [HLSL][clang][Driver] Support target profile command line option.

wolfgangp added a comment. Hi, there seems to be a unit test failure, for example here . /home/buildbot/as-worker-91/clang-with-lto-ubuntu/build/stage1/tools/clang/unittests/Driver/./ClangDriverTests --gtest_filter=DxcModeTest.TargetProf

[PATCH] D122865: [HLSL][clang][Driver] Support target profile command line option.

wolfgangp added a comment. Seems to be fine now. Thanks. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D122865/new/ https://reviews.llvm.org/D122865 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

[PATCH] D103495: [static initializers] Don't put ordered dynamic initializers of static variables into global_ctors

wolfgangp created this revision. wolfgangp added reviewers: rnk, jyu2. wolfgangp requested review of this revision. Commit c19f4f8069 caused some ordered dynamic initialization of static member variables to be

[PATCH] D103495: [static initializers] Don't put ordered dynamic initializers of static variables into global_ctors

wolfgangp added a comment. In D103495#2794329 , @rnk wrote: > +@rsmith @hans @aeubanks > >> specifically when init_array is not used > > Can you elaborate on why that is? Here's what I remember, and what I guess is > happening. ELF has two initializer sc

[PATCH] D109981: [Diagnostics] Don't drop a statically set NoWarningAsError flag during option processing

wolfgangp created this revision. wolfgangp added a reviewer: dexonsmith. wolfgangp requested review of this revision. Fixes PR 51837. When a -W option is given on the command line, and the corresponding diangostic has the NoWarnOnError flag set, the flag is dropped when the severity is reevalua

[PATCH] D109981: [Diagnostics] Don't drop a statically set NoWarningAsError flag during option processing

wolfgangp added a comment. ping ... CHANGES SINCE LAST ACTION https://reviews.llvm.org/D109981/new/ https://reviews.llvm.org/D109981 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D110783: [clang] Make crash reproducer work with clang-cl

wolfgangp added a comment. In D110783#3035158 , @dyung wrote: > Hi, the test you modified Driver/crash-report.cpp is failing on the PS4 bot > after your change. Can you take a look? > > https://lab.llvm.org/buildbot/#/builders/139/builds/10939 Seems lik

[PATCH] D67429: Improve code generation for thread_local variables:

wolfgangp added a comment. Ping. Just wondering if there are any new insights on the issue reported in PR48030 . Repository: rL LLVM CHANGES SINCE LAST ACTION https://reviews.llvm.org/D67429/new/ https://reviews.llvm.org/D67429 ___

[PATCH] D103495: [static initializers] Don't put ordered dynamic initializers of static variables into global_ctors

wolfgangp updated this revision to Diff 350364. wolfgangp added a comment. Herald added subscribers: llvm-commits, jdoerfert, pengfei, jrtc27, fedor.sergeev, hiraditya, jyknight, dschuff. Herald added a project: LLVM. Following the suggestion to define an order of initialization for the entries

[PATCH] D103495: [static initializers] Emit global_ctors and global_dtors in reverse order when init_array is not used.

wolfgangp updated this revision to Diff 350644. wolfgangp retitled this revision from "[static initializers] Don't put ordered dynamic initializers of static variables into global_ctors" to "[static initializers] Emit global_ctors and global_dtors in reverse order when init_array is not used.".

[PATCH] D103495: [static initializers] Emit global_ctors and global_dtors in reverse order when init_array is not used.

wolfgangp added a comment. In D103495#2804685 , @MaskRay wrote: > > Can you check whether clang/lib/CodeGen/CGDeclCXX.cpp:507 needs any comment > update? > The subject "Don't put ordered dynamic initializers of static variables into > global_ctors"

[PATCH] D103495: [static initializers] Emit global_ctors and global_dtors in reverse order when init_array is not used.

wolfgangp added a comment. In D103495#2808247 , @rnk wrote: > So, a question for @wolfgangp and @probinson , do we need to make adjustments > to the LTO library, or is this OK as is? We never guaranteed our licensees any particular initialization order

[PATCH] D103495: [static initializers] Emit global_ctors and global_dtors in reverse order when init_array is not used.

wolfgangp added a comment. If nobody has any more objections, I'll commit this change, then. Please let me know if you think otherwise. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D103495/new/ https://reviews.llvm.org/D103495 ___ cfe-commit

[PATCH] D103495: [static initializers] Emit global_ctors and global_dtors in reverse order when .ctors/.dtors are used.

This revision was landed with ongoing or failed builds. This revision was automatically updated to reflect the committed changes. Closed by commit rG5a1589fc6d11: [static initializers] Emit global_ctors and global_dtors in reverse order when . (authored by wolfgangp). Repository: rG LLVM Github

[PATCH] D98300: [TLS] Initialization functions of dynamic TLS variables cannot be in a comdat (fix for PR48030)

wolfgangp created this revision. wolfgangp added reviewers: cfe-commits, rsmith. wolfgangp requested review of this revision. This is an attempt to fix PR48030. The initialization function of dynamic TLS variables are currently placed into comdats (on ELF at least). The wrapper functions that ar

[PATCH] D131986: [inlining] Add a clang option to control inlining of functions based on stack size

wolfgangp created this revision. wolfgangp added reviewers: mtrofin, aeubanks. Herald added a project: All. wolfgangp requested review of this revision. Herald added a subscriber: MaskRay. Adding -finline-max-stacksize= to clang. This generates the function attribute` inline-max-stacksize` (intro

[PATCH] D131986: [inlining] Add a clang option to control inlining of functions based on stack size

This revision was landed with ongoing or failed builds. This revision was automatically updated to reflect the committed changes. Closed by commit rG8564e2fea559: [Inlining] Add a clang option to limit inlining of functions (authored by wolfgangp). Herald added a project: clang. Changed prior to

[PATCH] D136078: Use-after-return sanitizer binary metadata

wolfgangp added a comment. covered.cpp and uar.cpp seem to fail on ubuntu bots here . Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D136078/new/ https://reviews.llvm.org/D

[PATCH] D39396: Fix for PR33930. Short-circuit metadata mapping when cloning a varargs thunk.

wolfgangp created this revision. The problem in PRR33930 comes about because clang is cloning a function (to generate varargs thunks) before all the Metadata nodes are resolved. The value mapper, which is used by the cloner to deal with Medatdata no

[PATCH] D39396: Fix for PR33930. Short-circuit metadata mapping when cloning a varargs thunk.

wolfgangp updated this revision to Diff 120876. wolfgangp added a comment. Incorporated review comments. https://reviews.llvm.org/D39396 Files: include/llvm/IR/Metadata.h lib/CodeGen/CGVTables.cpp test/CodeGenCXX/tmp-md-nodes1.cpp test/CodeGenCXX/tmp-md-nodes2.cpp Index: test/CodeGenCX

[PATCH] D39396: Fix for PR33930. Short-circuit metadata mapping when cloning a varargs thunk.

wolfgangp marked 5 inline comments as done. wolfgangp added inline comments. Comment at: lib/CodeGen/CGVTables.cpp:143 + for (llvm::Function::iterator BB = Fn->begin(), E = Fn->end(); BB != E; + ++BB) { +for (llvm::Instruction &I : *BB) { aprantl wrote

[PATCH] D39396: Fix for PR33930. Short-circuit metadata mapping when cloning a varargs thunk.

wolfgangp marked an inline comment as done. wolfgangp added a comment. In https://reviews.llvm.org/D39396#911306, @aprantl wrote: > This works for me, but as I said previously, perhaps we can get by with just > not having any variables described in the thunk to further simplify the code. I rem

[PATCH] D39396: Fix for PR33930. Short-circuit metadata mapping when cloning a varargs thunk.

This revision was automatically updated to reflect the committed changes. Closed by commit rL317047: Fix for PR33930. Short-circuit metadata mapping when cloning a varargs thunk. (authored by wolfgangp). Changed prior to commit: https://reviews.llvm.org/D39396?vs=120876&id=121078#toc Repositor

[PATCH] D145970: [MSVC][PS][dllexport/dllimport] Propagate a dllexport/dllimport attribute to template baseclasses

wolfgangp added a comment. In D145970#4192679 , @hans wrote: > LGTM > > I've always found this to be an interesting behavior, and I'm guessing you > found some code where it does matter :) Well, one of our customers did, anyway. The code in the descript

[PATCH] D145970: [MSVC][PS][dllexport/dllimport] Propagate a dllexport/dllimport attribute to template baseclasses

This revision was landed with ongoing or failed builds. This revision was automatically updated to reflect the committed changes. Closed by commit rG634430d5857e: [MSVC][dllexport/dllimport] Propagate a dllexport/dllimport attribute to… (authored by wolfgangp). Herald added a project: clang. Repo

[PATCH] D146338: [MSVC compatibility][dllimport/dllexport][PS] Allow dllexport/dllimport for classes with UniqueExternalLinkage

wolfgangp created this revision. wolfgangp added reviewers: hans, probinson, mstorsjo. Herald added a project: All. wolfgangp requested review of this revision. This replaces D145271 . Rather than coercing classes with UniqueExternalLInkage to ExternalLinkage as

[PATCH] D146338: [MSVC compatibility][dllimport/dllexport][PS] Allow dllexport/dllimport for classes with UniqueExternalLinkage

wolfgangp added a comment. In D146338#4206222 , @hans wrote: >> In D145271 it was suggested that we drop >> the attribute in such contexts, and this is effectively what happens. The >> compiler does not produce any exp

[PATCH] D146338: [MSVC compatibility][dllimport/dllexport][PS] Allow dllexport/dllimport for classes with UniqueExternalLinkage

wolfgangp updated this revision to Diff 507428. wolfgangp added a comment. Instead of suppressing the error message we drop the dllimport/dllexport attribute when we see that a class has UniqueExternal linkage. This will suppress exporting or importing any members, which could not be accessed o

[PATCH] D145803: [clang][DebugInfo] Emit DW_AT_type of preferred name if available

wolfgangp added a comment. In D145803#4219894 , @probinson wrote: > This is pretty different from the "always desugar to the canonical type" > habit that has always been in place. Sony has done some downstream things to > try to work around that in the

[PATCH] D146338: [MSVC compatibility][dllimport/dllexport][PS] Allow dllexport/dllimport for classes with UniqueExternalLinkage

wolfgangp updated this revision to Diff 508747. wolfgangp marked an inline comment as done. wolfgangp added a comment. Added 2 test cases that check that dll{ex,im}ported classes that are instantiated with classes with internal linkage as template arguments are not exported or imported. Had to

[PATCH] D146338: [MSVC compatibility][dllimport/dllexport][PS] Allow dllexport/dllimport for classes with UniqueExternalLinkage

wolfgangp added inline comments. Comment at: clang/test/SemaCXX/dllexport.cpp:437 +class Base {}; +class __declspec(dllexport) ExportedClass {}; hans wrote: > Is this one used somewhere? It's not. Thanks for finding it. Comment at: clang/test

[PATCH] D145271: [MSVC compatibility][DLLEXPORT/DLLIMPORT] Allow dllexport/dllimport for local classes

wolfgangp added a comment. In D145271#4171267 , @hans wrote: > Interesting! Do you have an example where this (local dllexport/import > classes) comes up in practice? A customer complained about the following code (I'm obscuring the class names) compil

[PATCH] D145271: [MSVC compatibility][DLLEXPORT/DLLIMPORT] Allow dllexport/dllimport for local classes

wolfgangp added a comment. > It still seems like the export/import there is an accident since > `Base` can't really be referenced from outside the file anyway. > > Perhaps rather than giving `Base` external linkage to allow it to > be imported/exported, the better fix would be to drop its dllimp

[PATCH] D145970: [MSVC][PS][dllexport/dllimport] Propagate a dllexport/dllimport attribute to template baseclasses

wolfgangp created this revision. wolfgangp added reviewers: probinson, bd1976llvm, hans, mstorsjo. Herald added a project: All. wolfgangp requested review of this revision. For the Playstation platform, mimic MSVC in propagating dllexport/dllimport attributes to an instantiated template base clas

[PATCH] D146338: [MSVC compatibility][dllimport/dllexport][PS] Allow dllexport/dllimport for classes with UniqueExternalLinkage

This revision was automatically updated to reflect the committed changes. Closed by commit rG477f9cea77e6: [MSCV][dllexport/dllimport][PS] Allow UniqueExternal linkage classes with… (authored by wolfgangp). Herald added a project: clang. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST A

[PATCH] D145803: [clang][DebugInfo] Emit DW_AT_type of preferred name if available

wolfgangp added a comment. > @probinson Sounds like Sony's solution also changes the `DW_AT_type` to a > non-canonical form. Do you still have concerns with the direction of this > patch? Would it cause any problems for you downstream? Sorry for the late reply. Looking at the patch I don't thin

[PATCH] D140123: [TLS] Clamp the alignment of TLS global variables if required by the target

This revision was landed with ongoing or failed builds. This revision was automatically updated to reflect the committed changes. Closed by commit rG5d07e0448e38: [TLS]: Clamp the alignment of TLS global variables if required by the target (authored by wolfgangp). Herald added a project: clang. He

[PATCH] D140123: [TLS] Clamp the alignment of TLS global variables if required by the target

wolfgangp added a comment. In D140123#4123625 , @efriedma wrote: > In D140123#4113536 , @efriedma > wrote: > >> Missing LangRef change? > > Ping? Added a LangRef entry with 776b7499ea813c06b

[PATCH] D140123: [TLS] Clamp the alignment of TLS global variables if required by the target

wolfgangp added a comment. In D140123#4124512 , @efriedma wrote: >> no separate section for module flags > > https://llvm.org/docs/LangRef.html#module-flags-metadata ? That seems to be the description of the metadata for module flags, not the documentat

[PATCH] D98300: [TLS] Initialization functions of dynamic TLS variables cannot be in a comdat (fix for PR48030)

wolfgangp added a comment. ping... CHANGES SINCE LAST ACTION https://reviews.llvm.org/D98300/new/ https://reviews.llvm.org/D98300 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D109981: [Diagnostics] Don't drop a statically set NoWarningAsError flag during option processing

This revision was automatically updated to reflect the committed changes. Closed by commit rGd789ea713372: [Diagnostics] Don't drop a statically set NoWarningAsError flag during option… (authored by wolfgangp). Herald added a project: clang. Changed prior to commit: https://reviews.llvm.org/D10

[PATCH] D109981: [Diagnostics] Don't drop a statically set NoWarningAsError flag during option processing

wolfgangp added a comment. ping ... CHANGES SINCE LAST ACTION https://reviews.llvm.org/D109981/new/ https://reviews.llvm.org/D109981 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D98300: [TLS] Initialization functions of dynamic TLS variables cannot be in a comdat (fix for PR48030)

wolfgangp added a comment. ping ... CHANGES SINCE LAST ACTION https://reviews.llvm.org/D98300/new/ https://reviews.llvm.org/D98300 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D109981: [Diagnostics] Don't drop a statically set NoWarningAsError flag during option processing

wolfgangp added a comment. ping ... CHANGES SINCE LAST ACTION https://reviews.llvm.org/D109981/new/ https://reviews.llvm.org/D109981 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits