[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

[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

[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:

[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] 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 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

[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

[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] 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.

[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

[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

[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

[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)

[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

[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

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.

[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/

[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] 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`

[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

[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

[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] Dont drop a statically set NoWarningAsError flag during option… (authored by wolfgangp). Herald added a project: clang. Changed prior to commit:

[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

[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

[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

[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

[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

[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

[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 ___

[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. 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 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] 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] 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

[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

[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] 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] 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

[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] 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

[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

[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=158378#toc

[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

[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] 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:

[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=121078#toc Repository:

[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

[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 : *BB) { aprantl wrote:

[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:

[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