[PATCH] D155824: [LoongArch] Support -march=native and -mtune=

steven_wu accepted this revision. steven_wu added a comment. In D155824#4568904 , @xen0n wrote: > This still LGTM, @steven_wu would you please take another look so this can > get re-landed if confirmed working? The driver part LGTM. Repository: rG

[PATCH] D156014: [Clang][NVPTX] Permit use of the alias attribute for NVPTX targets

steven_wu added a comment. In D156014#4567446 , @jhuber6 wrote: > In D156014#4567363 , @steven_wu > wrote: > >> This breaks macOS bot: >>

[PATCH] D156014: [Clang][NVPTX] Permit use of the alias attribute for NVPTX targets

steven_wu added a comment. This breaks macOS bot: https://green.lab.llvm.org/green/job/clang-stage1-cmake-RA-incremental/36900/testReport/junit/Clang/SemaCUDA/alias_cu/ Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D156014/new/

[PATCH] D157119: cmake: add missing dependencies on ClangDriverOptions tablegen

steven_wu accepted this revision. steven_wu added subscribers: aprantl, dblaikie. steven_wu added a comment. This revision is now accepted and ready to land. LGTM. @aprantl @dblaikie who cares about module builds. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION

[PATCH] D155824: [LoongArch] Support -march=native and -mtune=

steven_wu added a comment. In D155824#4548921 , @SixWeining wrote: > In D155824#4548677 , @steven_wu > wrote: > >> After another look, I will need to request to revert this because this >> implementation

[PATCH] D155824: [LoongArch] Support -march=native and -mtune=

steven_wu added a comment. After another look, I will need to request to revert this because this implementation doesn't work with `-fno-integrated-cc1` at all. You can't setCPU/Tune in the driver into a global variable and expect that will work during compilation. You can reproduce with

[PATCH] D155824: [LoongArch] Support -march=native and -mtune=

steven_wu added inline comments. Comment at: llvm/lib/TargetParser/LoongArchTargetParser.cpp:19 +StringRef Arch; +StringRef TuneCPU; Why do we store `Arch` and `TuneCPU` as globals? We should not have as little global state in compiler as possible. Any reason

[PATCH] D156533: [clang][DeclPrinter] Fix missing semicolon in AST print for methods that are definitions without having a body

steven_wu added a comment. Reverted in 4098e13a7146 Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D156533/new/ https://reviews.llvm.org/D156533

[PATCH] D156533: [clang][DeclPrinter] Fix missing semicolon in AST print for methods that are definitions without having a body

steven_wu added a comment. error: aliases are not supported on darwin Maybe create a different testcase that is not supported on Darwin? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D156533/new/ https://reviews.llvm.org/D156533

[PATCH] D156533: [clang][DeclPrinter] Fix missing semicolon in AST print for methods that are definitions without having a body

steven_wu added a comment. This breaks Darwin bots: https://green.lab.llvm.org/green/job/clang-stage1-RA/35102/testReport/junit/Clang/AST/ast_print_method_decl_cpp/ Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D156533/new/

[PATCH] D153906: [clang] Allow disassembly of multi-module bitcode files

steven_wu added a comment. I don't like this doesn't write to the output file by `-o` too. I also think the output should just match `llvm-dis` output, instead of splitting into multiple files. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D153906/new/ https://reviews.llvm.org/D153906

[PATCH] D154191: [LTO] Replace llvm::writeFileAtomically with llvm::writeToOutput API.

steven_wu accepted this revision. steven_wu added a comment. This revision is now accepted and ready to land. This is generally fine. I don't see any error that should fall into `consumeError` condition that won't just error out anyway (like out of disk space, etc.) and I don't see those are

[PATCH] D154016: [clang][modules] Avoid serializing all diag mappings in non-deterministic order

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/D154016/new/ https://reviews.llvm.org/D154016 ___ cfe-commits mailing list

[PATCH] D154016: [clang][modules] Avoid serializing all diag mappings in non-deterministic order

steven_wu added inline comments. Comment at: clang/lib/Serialization/ASTWriter.cpp:3016 for (const auto : *State) { -if (I.second.isPragma() || IncludeNonPragmaStates) { - Record.push_back(I.first); - Record.push_back(I.second.serialize()); -

[PATCH] D152924: [libLTO][AIX] Respect `-f[no]-integrated-as` on AIX

steven_wu accepted this revision. steven_wu added a comment. This revision is now accepted and ready to land. I see. Sounds fine to me. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D152924/new/ https://reviews.llvm.org/D152924

[PATCH] D152924: [libLTO][AIX] Respect `-f[no]-integrated-as`

steven_wu added a comment. `lld` does not use LTOCodeGenerator. I am also not sure how disable integrated assembler suppose to work? Do you have an end to end design for how to invoke assembler during linking? For current libLTO API, this is probably going to produce assembler file buffer to

[PATCH] D141625: [DeclContext] Sort the Decls before adding into DeclContext

This revision was automatically updated to reflect the committed changes. Closed by commit rG0480748ea672: [DeclContext] Sort the Decls before adding into DeclContext (authored by steven_wu). Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D141625/new/

[PATCH] D141625: [DeclContext] Sort the Decls before adding into DeclContext

steven_wu added a comment. In D141625#4100790 , @dblaikie wrote: > In D141625#4100762 , @steven_wu > wrote: > >> I don't think it is feasible with current tool to write a test that check >> semantically the

[PATCH] D141625: [DeclContext] Sort the Decls before adding into DeclContext

steven_wu added a comment. I don't think it is feasible with current tool to write a test that check semantically the order of decls in clang module. (Let me know if that was wrong). The current test already unfortunately relies on the module layout assuming `op13` is the field for anonymous

[PATCH] D141632: [Module] Respect `-fno-pch-timestamps` when building modules

This revision was landed with ongoing or failed builds. This revision was automatically updated to reflect the committed changes. Closed by commit rG5cff68fca0bc: [Module] Respect `-fno-pch-timestamps` when building modules (authored by steven_wu). Repository: rG LLVM Github Monorepo CHANGES

[PATCH] D139052: [NFC][Profile] Access profile through VirtualFileSystem

This revision was automatically updated to reflect the committed changes. Closed by commit rG516e30175256: [NFC][Profile] Access profile through VirtualFileSystem (authored by steven_wu). Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D139052/new/

[PATCH] D141625: [DeclContext] Sort the Decls before adding into DeclContext

steven_wu added a comment. > Sorry, I'm still not really following - OK, sounds like you're saying this > test does fail at HEAD/without this patch in reverse iteration mode, and is a > bit larger than would be minimally necessary to achieve that, but also might > fail at HEAD without reverse

[PATCH] D139052: [NFC][Profile] Access profile through VirtualFileSystem

steven_wu updated this revision to Diff 493768. steven_wu added a comment. Try fix pre-merge build failure Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D139052/new/ https://reviews.llvm.org/D139052 Files:

[PATCH] D141625: [DeclContext] Sort the Decls before adding into DeclContext

steven_wu added a comment. In D141625#4094837 , @dblaikie wrote: > In D141625#4094742 , @steven_wu > wrote: > >> In D141625#4067225 , @dblaikie >> wrote: >> >>> In

[PATCH] D139052: [NFC][Profile] Access profile through VirtualFileSystem

steven_wu updated this revision to Diff 493724. steven_wu added a comment. Rebase to main. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D139052/new/ https://reviews.llvm.org/D139052 Files: clang/include/clang/CodeGen/BackendUtil.h

[PATCH] D141625: [DeclContext] Sort the Decls before adding into DeclContext

steven_wu added a comment. In D141625#4067225 , @dblaikie wrote: > In D141625#4066961 , @steven_wu > wrote: > >> No, reverse iteration will not break diff test for a small number of decls. >> Everything will be

[PATCH] D136315: [clang][Darwin] Try to guess the SDK root with xcrun when unspecified

steven_wu added a comment. In D136315#4069849 , @calebzulawski wrote: > In my situation, at least, I am the vendor of the toolchain and my > configuration file contains `--sysroot=/../path/to/sysroot` with a > known relative path to where the sysroot

[PATCH] D136315: [clang][Darwin] Try to guess the SDK root with xcrun when unspecified

steven_wu added a comment. This is not an apple platform problem. This is a cross compile problem where you have a SDK that is installed for cross compile target. In those cases, you just can't hard code the path to isysroot, and figuring out the sysroot is generally considered a problem for

[PATCH] D136315: [clang][Darwin] Try to guess the SDK root with xcrun when unspecified

steven_wu added a comment. In D136315#4069582 , @calebzulawski wrote: > That makes more sense, I thought perhaps it was using `DEFAULT_SYSROOT`. The > shim isn't smart enough to choose the sysroot from the target unfortunately. > > It looks like the

[PATCH] D136315: [clang][Darwin] Try to guess the SDK root with xcrun when unspecified

steven_wu added a comment. In D136315#4067205 , @calebzulawski wrote: > One thing to throw into the mix: Apple's clang has a default sysroot > configured, so with the default system compiler, there is no way to replicate > this "build without a

[PATCH] D141625: [DeclContext] Sort the Decls before adding into DeclContext

steven_wu added a comment. No, reverse iteration will not break diff test for a small number of decls. Everything will be in reverse order so it is the same. Current test will fail early in reverse iteration and will fail in the end statistically for forward iteration. Will pass in all

[PATCH] D136315: [clang][Darwin] Try to guess the SDK root with xcrun when unspecified

steven_wu added a comment. This breaks macOS bot too: https://green.lab.llvm.org/green/job/clang-stage1-cmake-RA-incremental/33839/ I think this changes might be more disruptive than expected. While it is encouraged to use `-isysroot` when building anything on Darwin platform, it is also

[PATCH] D141625: [DeclContext] Sort the Decls before adding into DeclContext

steven_wu updated this revision to Diff 490616. steven_wu added a comment. Update tests according to feedback Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D141625/new/ https://reviews.llvm.org/D141625 Files: clang/lib/Parse/ParseDecl.cpp

[PATCH] D141625: [DeclContext] Sort the Decls before adding into DeclContext

steven_wu added a comment. In D141625#4066466 , @dblaikie wrote: > In D141625#4066362 , @steven_wu > wrote: > >> @dblaikie Do you have any objection for committing the patch as it is? I >> don't think reverse

[PATCH] D141625: [DeclContext] Sort the Decls before adding into DeclContext

steven_wu added a comment. @dblaikie Do you have any objection for committing the patch as it is? I don't think reverse iteration test is a proper way to test for this specific bug. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D141625/new/

[PATCH] D141625: [DeclContext] Sort the Decls before adding into DeclContext

steven_wu added a comment. In D141625#4060460 , @dblaikie wrote: > In D141625#4059486 , @steven_wu > wrote: > >> @dblaikie Do we have any bots running reverse iteration? > > Hmm, not that I can see/find at a

[PATCH] D141625: [DeclContext] Sort the Decls before adding into DeclContext

steven_wu added a comment. In D141625#4059540 , @tschuett wrote: > EXPANSIVE_CHECKS will reshuffle the llvm::sort input: > https://lists.llvm.org/pipermail/llvm-dev/2018-April/122576.html This is a slightly different concern. The problem to catch is

[PATCH] D141625: [DeclContext] Sort the Decls before adding into DeclContext

steven_wu added a comment. @dblaikie Do we have any bots running reverse iteration? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D141625/new/ https://reviews.llvm.org/D141625 ___ cfe-commits mailing

[PATCH] D141625: [DeclContext] Sort the Decls before adding into DeclContext

steven_wu added a comment. In D141625#4056831 , @steven_wu wrote: > Actually, sorting in `numberAnonymousDeclsWithin` doesn't work for some > reasons. The reason for this doesn't work is `ASTWriter::WriteDeclContextLexicalBlock` also iterates on

[PATCH] D141625: [DeclContext] Sort the Decls before adding into DeclContext

steven_wu added a comment. Actually, sorting in `numberAnonymousDeclsWithin` doesn't work for some reasons. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D141625/new/ https://reviews.llvm.org/D141625 ___

[PATCH] D141625: [DeclContext] Sort the Decls before adding into DeclContext

steven_wu updated this revision to Diff 489587. steven_wu added a comment. Minor touch up on the test case. Also add some comments in test to explain what is being tested. I don't measure any performance regression from `-fsyntax-only` on Foundation.h but if there are some other performance

[PATCH] D141625: [DeclContext] Sort the Decls before adding into DeclContext

steven_wu updated this revision to Diff 489150. steven_wu added a comment. @akyrtzi has the good idea. It is really hard to control `Decl*` to get values to get an unstable iteration order from the small tests, going beyond 32 decls to get out of SmallPtrSet's small model is much consistent. Add

[PATCH] D141625: [DeclContext] Sort the Decls before adding into DeclContext

steven_wu added a comment. In D141625#4052869 , @rsmith wrote: > In D141625#4052820 , @dblaikie > wrote: > >> Yeah, might be nice to document where the instability comes from - if it >> comes from a DenseMap or

[PATCH] D141632: [Module] Respect `-fno-pch-timestamps` when building modules

steven_wu created this revision. steven_wu added reviewers: benlangmuir, akyrtzi, jansvoboda11. Herald added a subscriber: ributzka. Herald added a project: All. steven_wu requested review of this revision. Herald added a project: clang. Always respect the FrontendOption to not include timestamps

[PATCH] D141625: [DeclContext] Sort the Decls before adding into DeclContext

steven_wu created this revision. steven_wu added reviewers: jansvoboda11, akyrtzi, benlangmuir, vsapsai, rnk, dblaikie. Herald added subscribers: ributzka, mgrang. Herald added a project: All. steven_wu requested review of this revision. Herald added a project: clang. Fix a non-deterministic

[PATCH] D139052: [NFC][Profile] Access profile through VirtualFileSystem

steven_wu updated this revision to Diff 487597. steven_wu added a comment. Address review feedback. Remove NFC from title. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D139052/new/ https://reviews.llvm.org/D139052 Files:

[PATCH] D139938: [clang] Don't spuriously pass -stdlib=libc++ to CC1 on Darwin

steven_wu added a comment. In D139938#4008232 , @hans wrote: > This seems to have broken the instrprof-darwin-exports.c test, see e.g. > https://green.lab.llvm.org/green/job/clang-stage1-RA/32351/ > > I'll revert for now. It seems you still need to

[PATCH] D137838: [Support] Move TargetParsers to new component

steven_wu added a comment. Also needed a follow up fix to completely fix module `9cd6fbee7ed8` Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D137838/new/ https://reviews.llvm.org/D137838 ___ cfe-commits

[PATCH] D140164: [clang/Lexer] Enhance `Lexer::getImmediateMacroNameForDiagnostics` to return a result from non-file buffers

steven_wu accepted this revision. steven_wu added a comment. This revision is now accepted and ready to land. LGTM Comment at: clang/lib/Lex/Lexer.cpp:1050 - // If the macro's spelling has no FileID, then it's actually a token paste - // or stringization (or similar) and

[PATCH] D131858: [clang] Track the templated entity in type substitution.

steven_wu added a comment. The workaround in https://reviews.llvm.org/D139956 can get llvm-project bootstrap correctly, doesn't fix the underlying issue. The new failures is in building `SupportTests` where it issues a weird warning followed by missing symbol. It might be related to this

[PATCH] D139956: Workaround an assertion failure during module build

This revision was landed with ongoing or failed builds. This revision was automatically updated to reflect the committed changes. Closed by commit rGe77e14ecf17b: Workaround an assertion failure during module build (authored by steven_wu). Repository: rG LLVM Github Monorepo CHANGES SINCE

[PATCH] D139956: Workaround an assertion failure during module build

steven_wu created this revision. steven_wu added reviewers: mizvekov, arphaman. Herald added a subscriber: ributzka. Herald added a project: All. steven_wu requested review of this revision. Herald added a project: LLVM. After the change in https://reviews.llvm.org/D131858, clang cannot bootstrap

[PATCH] D131858: [clang] Track the templated entity in type substitution.

steven_wu added a comment. > Can you tell if this has been fixed by > https://github.com/llvm/llvm-project/commit/303f20a2cab4554a10ec225fd853709146f8c51c > ? I can still reproduce this with latest commit. It is not fixed. At least it can easily reproduce on Darwin platform with bootstrap

[PATCH] D139052: [NFC][Profile] Access profile through VirtualFileSystem

steven_wu added inline comments. Comment at: clang/lib/Frontend/CompilerInvocation.cpp:1729 + if (!Opts.ProfileInstrumentUsePath.empty()) { +auto FS = llvm::vfs::getRealFileSystem(); +setPGOUseInstrumentor(Opts, Opts.ProfileInstrumentUsePath, *FS, Diags);

[PATCH] D139052: [NFC][Profile] Access profile through VirtualFileSystem

steven_wu added inline comments. Comment at: clang/lib/CodeGen/CodeGenAction.cpp:164 LLVMIRGenerationRefCount(0), - Gen(CreateLLVMCodeGen(Diags, InFile, std::move(FS), HeaderSearchOpts, -PPOpts, CodeGenOpts, C, CoverageInfo)),

[PATCH] D139052: [NFC][Profile] Access profile through VirtualFileSystem

steven_wu updated this revision to Diff 480990. steven_wu marked 13 inline comments as done. steven_wu added a comment. Address review feedback. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D139052/new/ https://reviews.llvm.org/D139052 Files:

[PATCH] D139052: [NFC][Profile] Access profile through VirtualFileSystem

steven_wu created this revision. steven_wu added reviewers: davidxl, tejohnson, xur, akyrtzi. Herald added subscribers: Enna1, ormris, wenlei, ributzka, pengfei, hiraditya. Herald added a project: All. steven_wu requested review of this revision. Herald added projects: clang, LLVM. Herald added a

[PATCH] D136888: Move getenv for AS_SECURE_LOG_FILE to clang

steven_wu accepted this revision. steven_wu added a comment. This revision is now accepted and ready to land. LGTM except the comments from @MaskRay CHANGES SINCE LAST ACTION https://reviews.llvm.org/D136888/new/ https://reviews.llvm.org/D136888

[PATCH] D136888: Move getenv for AS_SECURE_LOG_FILE to clang

steven_wu added a comment. If we have to fix it, I slightly prefer just give it a proper option in CodeGenOption and a `cc1` and `cc1as` flag. Comment at: llvm/lib/MC/MCContext.cpp:62 -static cl::opt +static cl::opt AsSecureLogFileName("as-secure-log-file-name",

[PATCH] D136651: [Clang] Give Clang the ability to use a shared stat cache

steven_wu added a comment. > Yes, we can. I pondered doing it in the original patch but didn't see a > reason this would evolve in the future. Of course, I can't predict the > future, so maybe a version field is the safe approach. I think a version number should be good enough for now. For the

[PATCH] D136651: [Clang] Give Clang the ability to use a shared stat cache

steven_wu added inline comments. Comment at: llvm/lib/Support/VirtualFileSystem.cpp:3002 +// The format of the stat cache is (pseudo-code): +// struct stat_cache { +//char Magic[4]; // "STAT" or "Stat" Few comments about stats representation. 1.

[PATCH] D135712: [CMake] Fix FindGRPC cmake module to allow different layering

This revision was landed with ongoing or failed builds. This revision was automatically updated to reflect the committed changes. Closed by commit rG4ba360d499f6: [CMake] Fix FindGRPC cmake module to allow different layering (authored by steven_wu). Repository: rG LLVM Github Monorepo CHANGES

[PATCH] D135712: [CMake] Fix FindGRPC cmake module to allow different layering

steven_wu updated this revision to Diff 467247. steven_wu added a comment. Turn generate_proto_sources back to function and forward argument more elegantly. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D135712/new/

[PATCH] D135712: [CMake] Fix FindGRPC cmake module to allow different layering

steven_wu added inline comments. Comment at: cmake/Modules/FindGRPC.cmake:111 # They may be relative to the source dir or absolute (for generated protos). -function(generate_protos LibraryName ProtoFile) +macro(generate_protos_source GeneratedSource ProtoFile)

[PATCH] D135712: [CMake] Fix FindGRPC cmake module to allow different layering

steven_wu updated this revision to Diff 467243. steven_wu added a comment. Minor rename Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D135712/new/ https://reviews.llvm.org/D135712 Files: clang-tools-extra/clangd/CMakeLists.txt

[PATCH] D135712: [CMake] Fix FindGRPC cmake module to allow different layering

steven_wu added inline comments. Comment at: cmake/Modules/FindGRPC.cmake:111 # They may be relative to the source dir or absolute (for generated protos). -function(generate_protos LibraryName ProtoFile) +macro(generate_protos_source GeneratedSource ProtoFile)

[PATCH] D135712: [CMake] Fix FindGRPC cmake module to allow different layering

steven_wu updated this revision to Diff 467217. steven_wu added a comment. Was missing the latest feedback. Bump FindGRPC module to top layer. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D135712/new/ https://reviews.llvm.org/D135712 Files:

[PATCH] D135712: [CMake] Fix FindGRPC cmake module to allow different layering

steven_wu updated this revision to Diff 467215. steven_wu added a comment. Herald added a subscriber: bmahjour. Herald added a project: clang. Address review feedback Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D135712/new/

[PATCH] D135712: [CMake] Fix FindGRPC cmake module to allow different layering

steven_wu created this revision. steven_wu added reviewers: sammccall, akyrtzi, rymiel. Herald added subscribers: ributzka, kadircet, arphaman. Herald added a project: All. steven_wu requested review of this revision. Herald added projects: LLVM, clang-tools-extra. Herald added a subscriber:

[PATCH] D135490: [clang/Sema] Follow-up for fix of non-deterministic order of `-Wunused-variable` diagnostic

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

[PATCH] D135490: [clang/Sema] Follow-up for fix of non-deterministic order of `-Wunused-variable` diagnostic

steven_wu added a comment. I don't know too much about this. I guess have a DiagReceiver to force the emitting order is a good thing but it is kind of weird to have this just for unused warning. I am guessing my suspect of removing decl from the scope is the cause of the slow down. Maybe we

[PATCH] D135118: [clang/Sema] Fix non-deterministic order for certain kind of diagnostics

steven_wu accepted this revision. steven_wu added a comment. LGTM. `RemoveDecl` does become more expensive but I don't have better solution. I am also wondering if as follow up we should add an option to `VerifyDiagnosticConsumer` to be location aware (so the diagnostics from a file is

[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

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

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

[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

[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

[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

[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

[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

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

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

[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

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

[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

[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

[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

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

[PATCH] D111863: [libunwind] Add an interface for dynamic .eh_frame registration

steven_wu added a comment. In D111863#3071328 , @housel wrote: > In D111863#3069279 , @lhames wrote: > >> I think the ORC runtime provides a much more natural way to test this. Did >> you manage to come up with

[PATCH] D111863: [libunwind] Add an interface for dynamic .eh_frame registration

steven_wu added a comment. I don't know enough about Dwarf unwinding but the implementation looks generally good. Can you please add a testcase indicating how ORCJIT is planning to use it? Comment at: libunwind/src/DwarfParser.hpp:158 + FDE_Info

[PATCH] D108881: [clang][driver] Honor the last -flto(=.*)? argument

steven_wu accepted this revision. steven_wu added a comment. This revision is now accepted and ready to land. I am not familiar with offloading side of LTO driver but the change looks functionally the same to me. Thanks for doing this! Remember to update the commit message with the correct

[PATCH] D108881: [clang][driver] Honor the last -flto(=.*)? argument

steven_wu added a comment. In D108881#2988026 , @tejohnson wrote: > In D108881#2988016 , @steven_wu > wrote: > >> In D108881#2987990 , @mnadeem >> wrote: >> >>> In

[PATCH] D108881: [clang][driver] Honor the last -flto(=.*)? argument

steven_wu added a comment. If you didn't quite get what I mean, I am suggesting to cleanup all the reference to the old flag. Since `-flto` is rewrite by the driver to `-flto=full`, clang should not query `OPT_flto` anymore. All references to the old flag needs to be audited and removed while

[PATCH] D108881: [clang][driver] Honor the last -flto(=.*)? argument

steven_wu added a comment. In D108881#2987990 , @mnadeem wrote: > In D108881#2973735 , @steven_wu > wrote: > >> In D108881#2973719 , @mnadeem >> wrote: >> >>> In

[PATCH] D108881: [clang][driver] Honor the last -flto(=.*)? argument

steven_wu added a comment. In D108881#2973719 , @mnadeem wrote: > In D108881#2973516 , @steven_wu > wrote: > >> I will do a cleanup of `parseLTOMode` function since we don't need a >> `OptPos` parameter

[PATCH] D108881: [clang][driver] Honor the last -flto(=.*)? argument

steven_wu added a comment. I will do a cleanup of `parseLTOMode` function since we don't need a `OptPos` parameter anymore. There are few minor places references `OPT_flto` or `OPT_foffload_lto` can be cleaned up too. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION

[PATCH] D108881: [clang][driver] Honor the last -flto= flag even if an earlier -flto is present

steven_wu added a comment. I agree that it might be good to change to the behavior that last arg wins but it might be simpler to set `-flto` to be an alias of `-flto=full`: diff --git a/clang/include/clang/Driver/Options.td b/clang/include/clang/Driver/Options.td index

[PATCH] D107667: [clang/test] Run thinlto-clang-diagnostic-handler-in-be.c on x86

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

  1   2   3   >