[PATCH] D47280: [Sema][ObjC] Do not DiagnoseUseOfDecl in LookupMemberExpr

steven_wu created this revision. steven_wu added reviewers: erik.pilkington, arphaman, doug.gregor. Remove the call to DiagnoseUseOfDecl in LookupMemberExpr because: 1. LookupMemberExpr eagerly lookup both getter and setter, reguardless if they are used or not. It causes wrong diagnostics if you

[PATCH] D47280: [Sema][ObjC] Do not DiagnoseUseOfDecl in LookupMemberExpr

This revision was automatically updated to reflect the committed changes. Closed by commit rC333148: [Sema][ObjC] Do not DiagnoseUseOfDecl in LookupMemberExpr (authored by steven_wu, committed by ). Changed prior to commit: https://reviews.llvm.org/D47280?vs=148279&id=148327#toc Repository:

[PATCH] D51189: [Sema][ObjC] Infer availability of +new from availability of -init

steven_wu added a comment. I feel like this is a much tricky situation than just new and init. Following example is the same situation. __attribute__((objc_root_class)) @interface NSObject - (void) foo; - (void) bar; @end @implementation NSObject - (void) foo {} - (void) bar {

[PATCH] D51440: [ToolChains] Link to compiler-rt with -L + -l when possible

steven_wu added a comment. I do prefer the current approach especially on Darwin. Some concerns of switching to use "-L + -l" are: 1. clang and compiler-rt are rev-locked. Inferring the compiler-rt from resource-dir and passing to linker with the full path can prevent mistakes of mixing them u

[PATCH] D41087: [Preprocessor] Implement __is_target_{arch|vendor|os|environment} function-like builtin macros

steven_wu accepted this revision. steven_wu added a comment. LGTM https://reviews.llvm.org/D41087 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D41076: [driver][darwin] Set the 'simulator' environment when it's specified in '-target'

steven_wu added a comment. Other than the comment inline, LGTM. Comment at: lib/Driver/ToolChains/Darwin.cpp:1603 // Recognize iOS targets with an x86 architecture as the iOS simulator. - if (Platform != MacOS && (getTriple().getArch() == llvm::Triple::x86 || -

[PATCH] D41425: [darwin][driver] Warn about mismatching --version-min rather than superfluous --version-min compiler option

steven_wu accepted this revision. steven_wu added a comment. Just a small suggestion. Looks good otherwise. Comment at: lib/Driver/ToolChains/Darwin.cpp:1536 + Driver::GetReleaseVersion(OSVersionArgTarget->getOSVersion(), + ArgMajor

[PATCH] D41425: [darwin][driver] Warn about mismatching --version-min rather than superfluous --version-min compiler option

steven_wu added inline comments. Comment at: lib/Driver/ToolChains/Darwin.cpp:1536 + Driver::GetReleaseVersion(OSVersionArgTarget->getOSVersion(), + ArgMajor, ArgMinor, ArgMicro, HadExtra) && + VersionTuple(TargetMajor, Targ

[PATCH] D41780: Preserve unknown STDC pragma through preprocessor

steven_wu created this revision. steven_wu added reviewers: efriedma, rsmith, arphaman. should keep the unknown STDC pragma through preprocessor and we also should not emit warning for unknown STDC pragma during preprocessor. rdar://problem/35724351 Repository: rC Clang https://reviews.llvm.

[PATCH] D41780: Preserve unknown STDC pragma through preprocessor

steven_wu added a comment. In https://reviews.llvm.org/D41780#968664, @efriedma wrote: > If you move all the #pragma STDC handlers from the lexer to the parser, you > might be able to avoid adding an explicit STDC handler in > PrintPreprocessedOutput.cpp. If it is safe to do that, I can chang

[PATCH] D41780: Preserve unknown STDC pragma through preprocessor

steven_wu updated this revision to Diff 128794. steven_wu added a comment. Move STDC pragma handler to parser. Repository: rC Clang https://reviews.llvm.org/D41780 Files: include/clang/Basic/DiagnosticLexKinds.td include/clang/Basic/DiagnosticParseKinds.td include/clang/Parse/Parser.h

[PATCH] D41780: Preserve unknown STDC pragma through preprocessor

This revision was automatically updated to reflect the committed changes. steven_wu marked an inline comment as done. Closed by commit rL321909: Preserve unknown STDC pragma through preprocessor (authored by steven_wu, committed by ). Repository: rL LLVM https://reviews.llvm.org/D41780 Files:

[PATCH] D44670: [CXX] Templates specialization visibility can be wrong

steven_wu created this revision. steven_wu added reviewers: rsmith, arphaman. Under some conditions, LinkageComputer can get the visibility for ClassTemplateSpecializationDecl wrong because it failed to find the Decl that has the explicit visibility. This fixes: llvm.org/bugs/pr36810 rdar://probl

[PATCH] D56608: [Darwin][Driver] Don't pass a file as object_path_lto during ThinLTO

steven_wu created this revision. steven_wu added reviewers: arphaman, dexonsmith. Herald added subscribers: jkorous, inglorion, mehdi_amini. After r327851, Driver::GetTemporaryPath will create the file rather than just create a potientially unqine filename. If clang driver pass the file as paramet

[PATCH] D56608: [Darwin][Driver] Don't pass a file as object_path_lto during ThinLTO

steven_wu updated this revision to Diff 181324. steven_wu added a comment. I was planning to add a test but I am not sure how to check the file type of temporary files. I add a test to check for temp file names because I do create file and directory with different prefix. Repository: rC Cla

[PATCH] D56608: [Darwin][Driver] Don't pass a file as object_path_lto during ThinLTO

steven_wu updated this revision to Diff 181325. steven_wu added a comment. Fix the comment Repository: rC Clang CHANGES SINCE LAST ACTION https://reviews.llvm.org/D56608/new/ https://reviews.llvm.org/D56608 Files: include/clang/Driver/Driver.h lib/Driver/Driver.cpp lib/Driver/ToolCh

[PATCH] D56608: [Darwin][Driver] Don't pass a file as object_path_lto during ThinLTO

This revision was automatically updated to reflect the committed changes. Closed by commit rC350970: [Darwin][Driver] Don't pass a file as object_path_lto during ThinLTO (authored by steven_wu, committed by ). Changed prior to commit: https://reviews.llvm.org/D56608?vs=181325&id=181361#toc Rep

[PATCH] D55525: [Driver] Add support for -fembed-bitcode for assembly file

steven_wu created this revision. steven_wu added reviewers: compnerd, dexonsmith. Herald added a subscriber: jkorous. Handle -fembed-bitcode for assembly inputs. When the input file is assembly, write a marker as "__LLVM,__asm" section. Fix llvm.org/pr39659 Repository: rC Clang https://revie

[PATCH] D21230: Do not embed all the cc1 options in bitcode commandline

steven_wu abandoned this revision. steven_wu added a comment. Herald added subscribers: jkorous, mehdi_amini. This is upstreamed by Saleem already CHANGES SINCE LAST ACTION https://reviews.llvm.org/D21230/new/ https://reviews.llvm.org/D21230 ___

[PATCH] D60302: [CodeGen][ObjC] Emit the retainRV marker as a module flag instead of named metadata.

steven_wu added a comment. I talked with Akira offline and we think this is probably the best approach to fix this LTO issue. I will leave others to comment if they think otherwise. Repository: rC Clang CHANGES SINCE LAST ACTION https://reviews.llvm.org/D60302/new/ https://reviews.llvm.or

[PATCH] D60516: [LTO] Add plumbing to save stats during LTO on Darwin.

steven_wu accepted this revision. steven_wu added a comment. This revision is now accepted and ready to land. LGTM with one additional small comments Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D60516/new/ https://reviews.llvm.org/D60516 __

[PATCH] D60516: [LTO] Add plumbing to save stats during LTO on Darwin.

steven_wu added a comment. forgot to save the inline comments. Comment at: llvm/lib/LTO/LTOCodeGenerator.cpp:601 // If statistics were requested, print them out after codegen. - if (llvm::AreStatisticsEnabled()) + if (llvm::AreStatisticsEnabled() && !StatsFile) llvm::

[PATCH] D61627: [clang driver] Allow -fembed-bitcode combined with -mno-red-zone

steven_wu added a comment. The main concern for adding this `blacklist` was because of long term maintainability since the option is going to be embedded into bitcode. Looking at this specific option, I have no reason against because it doesn't affect embedded compiler flags. I added Tim to se

[PATCH] D61627: [clang driver] Allow -fembed-bitcode combined with -mno-red-zone

steven_wu added a comment. In D61627#1493674 , @compnerd wrote: > @steven_wu - yeah, `-mred-zone`, `-mno-red-zone` does impact the ABI, at > least on x86_64. It changes the way that the arguments are spilled and the > stack layout. Well, I am not con

[PATCH] D61627: [clang driver] Allow -fembed-bitcode combined with -mno-red-zone

steven_wu added a comment. Like I said, I am not worried that -mno-red-zone itself changes the ABI. As long as LLVM still respect the attribute the same way, it is fine. I want to consult Tim to make sure we can support re-targeting no red zone from armv7k to arm64_32. The intention for the bl

[PATCH] D52252: Driver: render arguments for the embedded bitcode correctly

steven_wu added a comment. Thanks for doing this! Can you add some test cases just to be complete? Other than that, LGTM! Repository: rC Clang https://reviews.llvm.org/D52252 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.l

[PATCH] D43737: Improve -Winfinite-recursion

steven_wu added a comment. Herald added a project: LLVM. Sorry for following up late on the patch. Removing the reachability testing for the exit block causes false positive for infinite loop cases like this: void l() { static int count = 5; if (count >0) { count--; l();

[PATCH] D57991: [Driver][Darwin] Emit an error when using -pg on OS without support for it.

steven_wu accepted this revision. steven_wu added a comment. This revision is now accepted and ready to land. LGTM with a suggestion to make code cleaner. Comment at: clang/include/clang/Basic/DiagnosticDriverKinds.td:101 + "the clang compiler does not support -pg option on Da

[PATCH] D58122: Restore Check for Unreachable Exit Block in -Winfinite-recursion

steven_wu accepted this revision. steven_wu added a comment. LGTM Repository: rC Clang CHANGES SINCE LAST ACTION https://reviews.llvm.org/D58122/new/ https://reviews.llvm.org/D58122 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https

[PATCH] D61627: [clang driver] Allow -fembed-bitcode combined with -mno-red-zone

steven_wu added a comment. In D61627#1497919 , @wanders wrote: > > Why are you interested in expending this list? > > I have a (kernel) that is compiled with `-mno-red-zone` and `-mcmodel=large` > which I want to compile with `-fembed-bitcode` for a debug

[PATCH] D60162: [ThinLTO] Add module flags for TargetLibraryInfoImpl and use in LTO backends

steven_wu added a comment. Thanks for doing this. I think module flag is a good idea. Some comments inline. Comment at: clang/test/CodeGen/svml-calls.ll:16 + +define void @sin_f64(double* nocapture %varray) { +; CHECK-LABEL: @sin_f64( Personally, I think codege

[PATCH] D60162: [ThinLTO] Add module flags for TargetLibraryInfoImpl and use in LTO backends

steven_wu added inline comments. Comment at: llvm/lib/LTO/LTOBackend.cpp:221 +static TargetLibraryInfoImpl *createTLII(Module &Mod, TargetMachine *TM) { + TargetLibraryInfoImpl *TLII = tejohnson wrote: > tejohnson wrote: > > steven_wu wrote: > > > Should this

[PATCH] D55525: [Driver] Add support for -fembed-bitcode for assembly file

steven_wu added a comment. In D55525#1327742 , @compnerd wrote: > This really feels odd. Why not expect that the developer will add the > content themselves? I'm not sure I understand the motivation for this change. The main motivation for upstreaming

[PATCH] D55525: [Driver] Add support for -fembed-bitcode for assembly file

This revision was automatically updated to reflect the committed changes. Closed by commit rC348943: [Driver] Add support for -fembed-bitcode for assembly file (authored by steven_wu, committed by ). Changed prior to commit: https://reviews.llvm.org/D55525?vs=177563&id=177867#toc Repository:

[PATCH] D55673: [darwin] parse the SDK settings from SDKSettings.json if it exists and pass in the -target-sdk-version to the compiler and backend

steven_wu added a comment. See comments inline. Comment at: include/clang/Driver/DarwinSDKInfo.h:1 +//===--- DarwinSDKInfo.h - SDK Information parser for darwin *- C++ -*-===// +// Can this just be in Toolchains/Darwin.h? Comment at: inc

[PATCH] D55673: [darwin] parse the SDK settings from SDKSettings.json if it exists and pass in the -target-sdk-version to the compiler and backend

steven_wu accepted this revision. steven_wu added a comment. This revision is now accepted and ready to land. Other than a small design choice commented inline, LGTM. Comment at: include/clang/Driver/DarwinSDKInfo.h:36 +/// SDK has no SDKSettings.json, or a valid \c DarwinSDKIn

[PATCH] D55673: [darwin] parse the SDK settings from SDKSettings.json if it exists and pass in the -target-sdk-version to the compiler and backend

steven_wu added inline comments. Comment at: include/clang/Driver/DarwinSDKInfo.h:36 +/// SDK has no SDKSettings.json, or a valid \c DarwinSDKInfo otherwise. +Expected> parseDarwinSDKInfo(llvm::vfs::FileSystem &VFS, + StringRef

[PATCH] D67559: [Sema] Split of versions of -Wimplicit-{float,int}-conversion for Objective-C BOOL

steven_wu added a comment. The diagnostics message looks good to me. Repository: rC Clang CHANGES SINCE LAST ACTION https://reviews.llvm.org/D67559/new/ https://reviews.llvm.org/D67559 ___ cfe-commits mailing list cfe-commits@lists.llvm.org ht

[PATCH] D45699: [Availability] Improve availability to consider functions run at load time

steven_wu created this revision. steven_wu added a reviewer: arphaman. There are some functions/methods that run when the application launches or the library loads. Those functions will run reguardless the OS version as long as it satifies the minimum deployment target. Annotate them with availabi

[PATCH] D45699: [Availability] Improve availability to consider functions run at load time

steven_wu added a comment. Thanks for reviewing Erik! Comment at: lib/Sema/SemaDecl.cpp:9134-9151 + // Diagnose availability attributes. Availability cannot be used on functions + // that are run during load/unload. + for (const auto& attr: NewFD->attrs()) { +if (!isa(at

[PATCH] D45699: [Availability] Improve availability to consider functions run at load time

steven_wu updated this revision to Diff 142713. steven_wu added a comment. Address review feedback. Fix typos and comments. Repository: rC Clang https://reviews.llvm.org/D45699 Files: include/clang/Basic/DiagnosticSemaKinds.td lib/Sema/SemaDecl.cpp lib/Sema/SemaDeclAttr.cpp lib/Sema/

[PATCH] D45699: [Availability] Improve availability to consider functions run at load time

steven_wu updated this revision to Diff 142717. steven_wu added a comment. Address review feedback Repository: rC Clang https://reviews.llvm.org/D45699 Files: include/clang/Basic/DiagnosticSemaKinds.td lib/Sema/SemaDecl.cpp lib/Sema/SemaDeclAttr.cpp lib/Sema/SemaDeclObjC.cpp test/S

[PATCH] D45699: [Availability] Improve availability to consider functions run at load time

This revision was automatically updated to reflect the committed changes. Closed by commit rC330166: [Availability] Improve availability to consider functions run at load time (authored by steven_wu, committed by ). Changed prior to commit: https://reviews.llvm.org/D45699?vs=142717&id=142718#to

[PATCH] D44670: [CXX] Templates specialization visibility can be wrong

steven_wu updated this revision to Diff 142961. steven_wu added a comment. Address review feedback Repository: rC Clang https://reviews.llvm.org/D44670 Files: lib/AST/Decl.cpp test/CodeGenCXX/visibility-pr36810.cpp Index: test/CodeGenCXX/visibility-pr36810.cpp =

[PATCH] D44670: [CXX] Templates specialization visibility can be wrong

steven_wu added inline comments. Comment at: lib/AST/Decl.cpp:1078 +for (const auto *RD : + spec->getSpecializedTemplate()->getTemplatedDecl()->redecls()) { + auto Vis = getVisibilityOf(RD, kind); doug.gregor wrote: > Do we want to look at *all*

[PATCH] D44670: [CXX] Templates specialization visibility can be wrong

This revision was automatically updated to reflect the committed changes. Closed by commit rL330338: [CXX] Templates specialization visibility can be wrong (authored by steven_wu, committed by ). Herald added a subscriber: llvm-commits. Repository: rL LLVM https://reviews.llvm.org/D44670 File

[PATCH] D44670: [CXX] Templates specialization visibility can be wrong

This revision was automatically updated to reflect the committed changes. Closed by commit rC330338: [CXX] Templates specialization visibility can be wrong (authored by steven_wu, committed by ). Changed prior to commit: https://reviews.llvm.org/D44670?vs=142961&id=143103#toc Repository: rC

[PATCH] D48849: [Driver][Darwin] Use Host Triple to infer target os version

steven_wu created this revision. steven_wu added reviewers: arphaman, dexonsmith. When clang required to infer target os version from --target option and the os version is not specified in targets, check the host triple. If the host and target are both macOS, use host triple to infer target os ver

[PATCH] D48849: [Driver][Darwin] Use Host Triple to infer target os version

steven_wu added a comment. Unfortunately, I wasn't able to write a test for this because the host triple in the configuration can either be x86_64-apple-darwin* or x86_64-apple-macosx*, but the one used passed by driver is always macosx one. I can't reliably compare those two. Repository: r

[PATCH] D48849: [Driver][Darwin] Use Host Triple to infer target os version

steven_wu updated this revision to Diff 153814. steven_wu added a comment. Update patch. Use a better API. Repository: rC Clang https://reviews.llvm.org/D48849 Files: lib/Driver/ToolChains/Darwin.cpp test/Driver/clang-g-opts.c Index: test/Driver/clang-g-opts.c =

[PATCH] D48849: [Driver][Darwin] Use Host Triple to infer target os version

steven_wu updated this revision to Diff 153816. steven_wu added a comment. Rebase the commit correctly Repository: rC Clang https://reviews.llvm.org/D48849 Files: lib/Driver/ToolChains/Darwin.cpp test/Driver/clang-g-opts.c Index: test/Driver/clang-g-opts.c =

[PATCH] D48849: [Driver][Darwin] Use Host Triple to infer target os version

steven_wu added a comment. In https://reviews.llvm.org/D48849#1150246, @arphaman wrote: > Hmm, the driver should not call `inferDeploymentTargetFromArch` when > `-target` is passed. Or am I missing something? Good call. This only handles the *-apple-darwin case. Maybe the same should happen t

[PATCH] D48849: [Driver][Darwin] Use Host Triple to infer target os version

steven_wu updated this revision to Diff 153822. steven_wu added a comment. handle *-apple-macosx target option Repository: rC Clang https://reviews.llvm.org/D48849 Files: lib/Driver/ToolChains/Darwin.cpp test/Driver/clang-g-opts.c test/Driver/target-triple-deployment.c Index: test/Dr

[PATCH] D48849: [Driver][Darwin] Use Host Triple to infer target os version

steven_wu updated this revision to Diff 153836. steven_wu added a comment. It is easier and cleaner if I just fold everything into getOSVersion. Repository: rC Clang https://reviews.llvm.org/D48849 Files: lib/Driver/ToolChains/Darwin.cpp test/Driver/clang-g-opts.c test/Driver/target-tr

[PATCH] D48849: [Driver][Darwin] Use Host Triple to infer target os version

This revision was automatically updated to reflect the committed changes. Closed by commit rL336168: [Driver][Darwin] Use Host Triple to infer target os version (authored by steven_wu, committed by ). Herald added a subscriber: llvm-commits. Repository: rL LLVM https://reviews.llvm.org/D48849

[PATCH] D69327: [Clang][ThinLTO] Add a cache for compile phase output.

steven_wu added a comment. Can you clarify what do you mean by 'waste time optimizing a file that finally hit the object file cache'? No matter what build system to use, it should figure out during an incremental build that the input wasn't changed and not rerun the clang invocation on the sam

[PATCH] D69327: [Clang][ThinLTO] Add a cache for compile phase output.

steven_wu added a comment. In D69327#1719411 , @ychen wrote: > Thanks for the inputs @steven_wu @tejohnson. Totally agree with the points > you brought up. One last thing I'm not quite sure is the caching of > `-fthin-link-bitcode`. It is a `-cc1` option

[PATCH] D69327: [Clang][ThinLTO] Add a cache for compile phase output.

steven_wu added a comment. `ccache` does not have the support for this, I am just saying that this can be easily implemented in `ccache` and that would be much better than the proposed solution here. If we need to add a clang driver flag so build system can better support to detect thin bitcod

[PATCH] D69406: [clang][ThinLTO] Promote cc1 -fthin_link_bitcode to driver -fthinlto_link_bitcode

steven_wu accepted this revision. steven_wu added a comment. This revision is now accepted and ready to land. LGTM. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D69406/new/ https://reviews.llvm.org/D69406

[PATCH] D79511: [ObjC] Add compatibility mode for type checking of qualified id block parameters.

steven_wu added inline comments. Comment at: clang/lib/Driver/ToolChains/Darwin.cpp:2382 + // Foundation/NSItemProvider.h. + CC1Args.push_back("-fcompatibility-qualified-id-block-type-checking"); } Not that I know there is a better place to put this option, th

[PATCH] D84564: [darwin] build and link with a separate compiler-rt builtins library for device simulators

steven_wu accepted this revision. steven_wu added a comment. This revision is now accepted and ready to land. LGTM Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D84564/new/ https://reviews.llvm.org/D84564 _

[PATCH] D83813: [clang] Teach -fembed-bitcode option not to embed W_value Group

steven_wu created this revision. steven_wu added reviewers: zixuw, arphaman. Herald added subscribers: ributzka, dexonsmith, jkorous. Herald added a project: clang. -fembed-bitcode options doesn't embed warning options since they are useless to code generation. Make sure it handles the W_value gro

[PATCH] D83813: [clang] Teach -fembed-bitcode option not to embed W_value Group

steven_wu updated this revision to Diff 277975. steven_wu added a comment. Use `Option::match` instead. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D83813/new/ https://reviews.llvm.org/D83813 Files: clang/lib/Frontend/CompilerInvocation.cpp c

[PATCH] D83813: [clang] Teach -fembed-bitcode option not to embed W_value Group

This revision was automatically updated to reflect the committed changes. Closed by commit rG2b42080b51c9: [clang] Teach -fembed-bitcode option not to embed W_value Group (authored by steven_wu). Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D83813/ne

[PATCH] D82428: [clang][driver] allow `-arch arm64` to be used to build for mac when on Apple Silicon Mac without explicit `-target`

steven_wu accepted this revision. steven_wu added a comment. This revision is now accepted and ready to land. LGTM. Not sure if it makes more sense to break the patch into two commits: - config.guess change is for building the correct host triple on apple silicon machine without explicitly spec

[PATCH] D82696: [darwin][driver] isMacosxVersionLT should check against the minimum supported OS version

steven_wu accepted this revision. steven_wu added a comment. This revision is now accepted and ready to land. LGTM CHANGES SINCE LAST ACTION https://reviews.llvm.org/D82696/new/ https://reviews.llvm.org/D82696 ___ cfe-commits mailing list cfe-com

[PATCH] D82777: Clang Driver: Use Apple ld64's new @response-file support.

steven_wu accepted this revision. steven_wu added a comment. This revision is now accepted and ready to land. LGTM. Agree this is ugly but the clean up looks fine. Not sure how to write a test as well but I can see the `@` file path is triggered correctly. Repository: rG LLVM Github Monorepo

[PATCH] D82782: Clang Driver: refactor support for writing response files to be specified at Command creation, rather than as part of the Tool.

steven_wu accepted this revision. steven_wu added a comment. This revision is now accepted and ready to land. LGTM. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D82782/new/ https://reviews.llvm.org/D82782

[PATCH] D85367: [clang, test, Darwin] Fix tests expecting Darwin target

steven_wu accepted this revision. steven_wu added a comment. This revision is now accepted and ready to land. LGTM Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D85367/new/ https://reviews.llvm.org/D85367 ___

[PATCH] D84908: [darwin][compiler-rt] build libclang_rt.sim.a Apple Silicon slice, if SDK supports it

steven_wu accepted this revision. steven_wu added a comment. This revision is now accepted and ready to land. LGTM CHANGES SINCE LAST ACTION https://reviews.llvm.org/D84908/new/ https://reviews.llvm.org/D84908 ___ cfe-commits mailing list cfe-commi

[PATCH] D41035: [driver][darwin] Refactor the target selection code, NFC

steven_wu added a comment. LGTM. Repository: rC Clang https://reviews.llvm.org/D41035 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D131469: [Clang] change default storing path of `-ftime-trace`

steven_wu added a comment. In D131469#3768308 , @dongjunduo wrote: > In D131469#3768288 , @dyung wrote: > >> In D131469#3768283 , @dongjunduo >> wrote: >> >>> In D131469

[PATCH] D131469: [Clang] change default storing path of `-ftime-trace`

steven_wu added a comment. In D131469#3768500 , @dongjunduo wrote: > These related commits have been reverted temporarily. Thanks. Another way to do this is that as you don't really care what linker does in this test case, you just need to fake a linke

[PATCH] D131469: [Clang] change default storing path of `-ftime-trace`

steven_wu accepted this revision. steven_wu added a comment. Thanks Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D131469/new/ https://reviews.llvm.org/D131469 ___ cfe-commits mailing list cfe-commits@lis

[PATCH] D133509: Frontend: Adopt llvm::vfs::OutputBackend in CompilerInstance

steven_wu created this revision. steven_wu added reviewers: sammccall, benlangmuir, raghavmedicherla, kzhuravl, dexonsmith. Herald added a subscriber: ributzka. Herald added a project: All. steven_wu requested review of this revision. Herald added a project: clang. Herald added a subscriber: cfe-c

[PATCH] D95497: Frontend: Respect -working-directory when checking if output files can be written

steven_wu accepted this revision. steven_wu added a comment. This revision is now accepted and ready to land. LGTM. I will commit this if no objection. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D95497/new/ https://reviews.llvm.org/D95497 _

[PATCH] D95497: Frontend: Respect -working-directory when checking if output files can be written

steven_wu requested changes to this revision. steven_wu added a comment. This revision now requires changes to proceed. Actually, we need to fix the case when output is '-'. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D95497/new/ https://reviews.llvm.org/D95497 ___

[PATCH] D95497: Frontend: Respect -working-directory when checking if output files can be written

steven_wu updated this revision to Diff 458823. steven_wu edited the summary of this revision. steven_wu added a comment. Rebase patch and fix the problem when the input is '-' Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D95497/new/ https://review

[PATCH] D95497: Frontend: Respect -working-directory when checking if output files can be written

This revision was automatically updated to reflect the committed changes. Closed by commit rG493766e06847: Frontend: Respect -working-directory when checking if output files can be… (authored by steven_wu). Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.or

[PATCH] D129220: [clang] Cleanup ASTContext before output files in crash recovery for modules

steven_wu accepted this revision. steven_wu added a comment. LGTM. Thanks! Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D129220/new/ https://reviews.llvm.org/D129220 ___ cfe-commits mailing list cfe-comm

[PATCH] D106316: [clang][darwin] Add support for the -mtargetos= option to the driver

steven_wu added a comment. Looks good in general. Just one corner case that we need to decide with direction we go, following command builds arm64-ios and x86_64-ios-simulator: `clang -arch arm64 -arch x86_64 -c -o test.o test.c -mios-version-min=14` Should we document and deprecate that behavior

[PATCH] D118352: [clang][ABI] New c++20 modules mangling scheme

steven_wu added a comment. In D118352#3368922 , @ChuanqiXu wrote: > In D118352#3368919 , @phosek wrote: > >> We're also seeing this issue on our Mac bots, is it possible to revert it? > > I've reverted it. Since t

[PATCH] D121332: Cleanup includes: DebugInfo & CodeGen

steven_wu added a comment. This breaks implicit module on macOS bots: https://green.lab.llvm.org/green/job/lldb-cmake/42098/console Error message: /Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/llvm/include/llvm/CodeGen/MachinePipeliner.h:136:3: error: missing '#include "llvm/A

[PATCH] D72404: [ThinLTO/FullLTO] Support Os and Oz

steven_wu added a comment. I just saw this. I know it is a good idea to have choice during link time for the pipeline configuration and from your benchmark it also has size impact on the output. I also feel like this is going in the wrong direction as if I have part of the object files built wi

[PATCH] D118862: [clang][driver] add clang driver support for emitting macho files with two build version load commands

steven_wu accepted this revision. steven_wu added a comment. This revision is now accepted and ready to land. LGTM Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D118862/new/ https://reviews.llvm.org/D118862 _

[PATCH] D130205: [Darwin toolchain] Tune the logic for finding arclite.

This revision was landed with ongoing or failed builds. This revision was automatically updated to reflect the committed changes. Closed by commit rGd0728260577d: [Darwin toolchain] Tune the logic for finding arclite. (authored by steven_wu). Repository: rG LLVM Github Monorepo CHANGES SINCE L

[PATCH] D125974: [clang] Limit bitcode option ignorelist to Darwin

steven_wu added a comment. LGTM. Can you add a test for your usecase? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D125974/new/ https://reviews.llvm.org/D125974 ___ cfe-commits mailing list cfe-commits@l

[PATCH] D125847: LTO: Decide upfront whether to use opaque/non-opaque pointer types

steven_wu added a comment. Is there any issues currently if we just always use opaque pointer in LTO? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D125847/new/ https://reviews.llvm.org/D125847 ___ cfe-co

[PATCH] D125847: LTO: Decide upfront whether to use opaque/non-opaque pointer types

steven_wu added a comment. In D125847#3528111 , @aeubanks wrote: > I'm still looking into a whole program devirtualization bug that only repros > with opaque pointers, and there are still potential performance issues to > look into Thanks. Maybe here i

[PATCH] D88114: [clang]Test ensuring -fembed-bitcode passed to cc1 captures pre-opt bitcode.

steven_wu added a comment. I am not sure what exactly is expected here. What is your definition for pre-optimized bitcode and how your test case ensures that? Can you explain a bit more for context? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D88

[PATCH] D88114: [clang]Test ensuring -fembed-bitcode passed to cc1 captures pre-opt bitcode.

steven_wu added a comment. In D88114#2288737 , @mtrofin wrote: > In D88114#2288732 , @steven_wu wrote: > >> I am not sure what exactly is expected here. What is your definition for >> pre-optimized bitcode and how

[PATCH] D88114: [clang]Test ensuring -fembed-bitcode passed to cc1 captures pre-opt bitcode.

steven_wu added a comment. Ok, I guess we are on the same page. The idea sounds fine to me. I would suggest just check that the output matches the input file as much as possible, rather than just check a label and a call instruction. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST AC

[PATCH] D88114: [clang]Test ensuring -fembed-bitcode passed to cc1 captures pre-opt bitcode.

steven_wu accepted this revision. steven_wu added a comment. This revision is now accepted and ready to land. LGTM Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D88114/new/ https://reviews.llvm.org/D88114 ___

[PATCH] D102479: [clang][driver] Treat unkonwn -flto= values as -flto

steven_wu added a comment. I don't think current implementation is the best idea. I think is better to make the gcc compatible LTO value to be a clang Driver only option, give them an option name, and handle them separately in driver to invoke correct fullLTO cc1 command, so that: - The value

[PATCH] D102479: [clang][driver] Treat unkonwn -flto= values as -flto

steven_wu accepted this revision. steven_wu added a comment. This revision is now accepted and ready to land. LGTM CHANGES SINCE LAST ACTION https://reviews.llvm.org/D102479/new/ https://reviews.llvm.org/D102479 ___ cfe-commits mailing list cfe-com

[PATCH] D103547: Don't delete the module you're inspecting

steven_wu added a comment. Can you create a new test for clang Driver instead of rewrite the cc1 test? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D103547/new/ https://reviews.llvm.org/D103547 ___ cfe-c

[PATCH] D103547: Don't delete the module you're inspecting

steven_wu accepted this revision. steven_wu added a comment. This revision is now accepted and ready to land. LGTM Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D103547/new/ https://reviews.llvm.org/D103547 _

[PATCH] D93003: [libunwind][ELF] Hide unw_getcontext with LIBUNWIND_HIDE_SYMBOLS

steven_wu added inline comments. Comment at: libunwind/src/assembly.h:82 .globl SYMBOL_NAME(aliasname) SEPARATOR \ - WEAK_SYMBOL(aliasname) SEPARATOR \ + EXPORT_SYMBOL(SYMBOL_NAME(aliasname))

[PATCH] D93003: [libunwind] unw_* alias fixes for ELF and Mach-O

steven_wu added a comment. In D93003#2566906 , @rprichard wrote: > Maybe this is blocked on someone from Apple reviewing the Mach-O parts? This is fine with me for how Apple builds libunwind. I am not sure if the open source libunwind build for MachO do

[PATCH] D93003: [libunwind] unw_* alias fixes for ELF and Mach-O

steven_wu accepted this revision. steven_wu added a comment. My main concern is just that weak alias for libc++abi that never worked for Darwin :) LGTM. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D93003/new/ https://reviews.llvm.org/D93003 ___

  1   2   3   >