[PATCH] D149119: [CMake] Use LLVM own tools in extract_symbols.py

This revision was automatically updated to reflect the committed changes. Closed by commit rGf649599ea933: [CMake] Use LLVM own tools in extract_symbols.py (authored by ikudrin). Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D149119/new/

[PATCH] D149119: [CMake] Use LLVM own tools in extract_symbols.py

ikudrin added a comment. In D149119#4329274 , @tmatheson wrote: > LGTM, thank you for doing this. Please give it a couple of days in case > others have comments. Thanks! In D149119#4329285 , @jhenderson

[PATCH] D149119: [CMake] Use LLVM own tools in extract_symbols.py

ikudrin updated this revision to Diff 520277. ikudrin retitled this revision from "[CMake] Use llvm-nm to extract symbols for staged LTO builds on Windows" to "[CMake] Use LLVM own tools in extract_symbols.py". ikudrin edited the summary of this revision. ikudrin added reviewers: chandlerc,

[PATCH] D149119: [CMake] Use llvm-nm to extract symbols for staged LTO builds on Windows

ikudrin added a comment. In D149119#4312518 , @simon_tatham wrote: > Do LLVM's current portability goals include the constraint that you can only > build LLVM for a platform it can also target? If not, then there surely still > needs to be //some//

[PATCH] D149119: [CMake] Use llvm-nm to extract symbols for staged LTO builds on Windows

ikudrin added a comment. In D149119#4295110 , @tmatheson wrote: > This looks like a nice addition. Would it make sense to use llvm-nm always, > not restricted to bootstrap builds? And would that work on Windows and allow > us to simplify this script

[PATCH] D149119: [CMake] Use llvm-nm to extract symbols for staged LTO builds on Windows

ikudrin created this revision. ikudrin added reviewers: john.brawn, daltenty, jsji, simon_tatham, tmatheson, mstorsjo, phosek. ikudrin added projects: LLVM, clang. Herald added subscribers: ekilmer, inglorion. Herald added a project: All. ikudrin requested review of this revision. As for now,

[PATCH] D148751: [CMake] Add llvm-lib to Clang bootstrap dependency for LTO builds on Windows

This revision was landed with ongoing or failed builds. This revision was automatically updated to reflect the committed changes. Closed by commit rG43c307fd690f: [CMake] Add llvm-lib to Clang bootstrap dependency for LTO builds on Windows (authored by ikudrin). Repository: rG LLVM Github

[PATCH] D148751: [CMake] Add llvm-lib to Clang bootstrap dependency for LTO builds on Windows

ikudrin updated this revision to Diff 515215. ikudrin marked an inline comment as done. ikudrin added a comment. - `WIN32` -> `MSVC` Thanks! CHANGES SINCE LAST ACTION https://reviews.llvm.org/D148751/new/ https://reviews.llvm.org/D148751 Files: clang/CMakeLists.txt Index:

[PATCH] D148751: [CMake] Add llvm-lib to Clang bootstrap dependency for LTO builds on Windows

ikudrin created this revision. ikudrin added reviewers: smeenai, mstorsjo, phosek, beanz. ikudrin added a project: LLVM. Herald added subscribers: ekilmer, inglorion. Herald added a project: All. ikudrin requested review of this revision. Herald added a project: clang. Herald added a subscriber:

[PATCH] D121512: [Support] Change zlib::compress to return void

ikudrin accepted this revision. ikudrin 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/D121512/new/ https://reviews.llvm.org/D121512

[PATCH] D121512: [Support] Change zlib::compress to return void

ikudrin added inline comments. Comment at: llvm/lib/ObjCopy/ELF/ELFObject.cpp:568 DebugCompressionType CompressionType, Error ) : SectionBase(Sec), CompressionType(CompressionType),

[PATCH] D113168: [clang-tblgen] Fix non-determinism in generating AttrSubMatchRulesParserStringSwitches.inc

This revision was automatically updated to reflect the committed changes. Closed by commit rG7352f42cdc3c: [clang-tblgen] Fix non-determinism in generating… (authored by ikudrin). Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D113168/new/

[PATCH] D113477: [clang-tblgen] Fix non-determinism in generating AttributeReference.rst

This revision was landed with ongoing or failed builds. This revision was automatically updated to reflect the committed changes. Closed by commit rG5b7ea8e62921: [clang-tblgen] Fix non-determinism in generating AttributeReference.rst (authored by ikudrin). Repository: rG LLVM Github Monorepo

[PATCH] D113168: [clang-tblgen] Fix non-determinism in generating AttrSubMatchRulesParserStringSwitches.inc

ikudrin added a comment. The compiler has to be deterministic and one way to check that is to recompile a relatively large project several times. For `clang`, that large project is usually `clang` itself, so it has to be compiled in a stable way. Anyway, I've prepared a fix for generating the

[PATCH] D113477: [clang-tblgen] Fix non-determinism in generating AttributeReference.rst

ikudrin created this revision. ikudrin added reviewers: aaron.ballman, arphaman, rsmith. ikudrin added a project: clang. Herald added a subscriber: mgrang. ikudrin requested review of this revision. As for now, the categories are printed in an arbitrary order which depends on the addresses of

[PATCH] D113168: [clang-tblgen] Fix non-determinism in generating AttrSubMatchRulesParserStringSwitches.inc

ikudrin added a comment. We've noticed binary differences in `clang` in several builds on our local build bots, and the patch fixed that. As for generating the documentation, the issue can be seen, for example, in Clang-12

[PATCH] D113168: [clang-tblgen] Fix non-determinism in generating AttrSubMatchRulesParserStringSwitches.inc

ikudrin created this revision. ikudrin added reviewers: arphaman, aaron.ballman, rsmith. Herald added a subscriber: mgrang. ikudrin requested review of this revision. Herald added a project: clang. `llvm::MapVector`, compared to `std::map`, guarantees the same iteration order in different runs.

[PATCH] D96865: [Driver] Honor "-gdwarf-N" at any position for assembler sources

ikudrin added a comment. In D96865#2575486 , @gregmiller wrote: > Do you have any suggestions on why we would start seeing above failures after > you commit? Was passing before. From my understanding, the areas seem to be perfectly unrelated.

[PATCH] D96865: [Driver] Honor "-gdwarf-N" at any position for assembler sources

This revision was automatically updated to reflect the committed changes. Closed by commit rGa0c9ec1f5e70: [Driver] Honor -gdwarf-N at any position for assembler sources (authored by ikudrin). Changed prior to commit: https://reviews.llvm.org/D96865?vs=324291=324502#toc Repository: rG LLVM

[PATCH] D96865: [Driver] Honor "-gdwarf-N" at any position for assembler sources

ikudrin added a comment. Thanks! Comment at: clang/test/Driver/debug-options-as.c:65 +// Check that -gdwarf-N can be placed before other options of the "-g" group. +// RUN: %clang -### -c -g -gdwarf-3 -integrated-as -x assembler %s 2>&1 \ +// RUN: | FileCheck

[PATCH] D96865: [Driver] Honor "-gdwarf-N" at any position for assembler sources

ikudrin created this revision. ikudrin added reviewers: dblaikie, probinson, aprantl, MaskRay, mehdi_amini. ikudrin added projects: LLVM, clang, debug-info. ikudrin requested review of this revision. This fixes an issue when `-gdwarf-N` switch was ignored if it was given before another debug

[PATCH] D96783: [Driver] Support -gdwarf64 for assembly files

This revision was automatically updated to reflect the committed changes. ikudrin marked 2 inline comments as done. Closed by commit rG72eee60b2451: [Driver] Support -gdwarf64 for assembly files (authored by ikudrin). Changed prior to commit:

[PATCH] D96597: [DebugInfo] Keep the DWARF64 flag in the module metadata

This revision was automatically updated to reflect the committed changes. Closed by commit rGaa842896299b: [DebugInfo] Keep the DWARF64 flag in the module metadata (authored by ikudrin). Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D96597/new/

[PATCH] D96783: [Driver] Support -gdwarf64 for assembly files

ikudrin marked 2 inline comments as done. ikudrin added inline comments. Comment at: clang/lib/Driver/ToolChains/Clang.cpp:3757-3771 + if (DwarfFormatArg && + DwarfFormatArg->getOption().matches(options::OPT_gdwarf64)) { +if (DwarfVersion < 3) +

[PATCH] D96783: [Driver] Support -gdwarf64 for assembly files

ikudrin created this revision. ikudrin added reviewers: ayermolo, dblaikie, aprantl, MaskRay. ikudrin added projects: LLVM, clang, debug-info. Herald added subscribers: jansvoboda11, dang. ikudrin requested review of this revision. The option was added in D90507

[PATCH] D96597: [DebugInfo] Keep the DWARF64 flag in the module metadata

ikudrin added a comment. Thank you, @dblaikie! Comment at: llvm/lib/CodeGen/AsmPrinter/DwarfDebug.cpp:396 + bool Dwarf64 = + (Asm->TM.Options.MCOptions.Dwarf64 || MMI->getModule()->isDwarf64()) && + DwarfVersion >= 3 && // DWARF64 was introduced in DWARFv3.

[PATCH] D96597: [DebugInfo] Keep the DWARF64 flag in the module metadata

ikudrin created this revision. ikudrin added reviewers: ayermolo, MaskRay, wenlei, dblaikie. ikudrin added projects: LLVM, clang, debug-info. Herald added subscribers: dexonsmith, ormris, hiraditya. ikudrin requested review of this revision. This allows the option to affect the LTO output.

[PATCH] D90507: [Driver] Add DWARF64 flag: -gdwarf64

ikudrin added inline comments. Comment at: clang/lib/Driver/ToolChains/Clang.cpp:4016 + auto *dwarfArgs = + Args.getLastArg(options::OPT_gdwarf64, options::OPT_gdwarf32); Maybe make this more descriptive? Comment at:

[PATCH] D90507: Adding DWARF64 clang flag: -gdwarf64

ikudrin added inline comments. Comment at: clang/include/clang/Driver/Options.td:2145-2146 HelpText<"Generate source-level debug information with dwarf version 5">; +def gdwarf64 : Flag<["-"], "gdwarf64">, Group, Flags<[CC1Option]>, + HelpText<"Generate DWARF64 debug

[PATCH] D90507: Adding DWARF64 clang flag

ikudrin added a comment. It looks like `lld/test/COFF/lto-new-pass-manager.ll.obj` was added to the patch by accident and should be removed. Comment at: clang/include/clang/Basic/CodeGenOptions.def:35 CODEGENOPT(AsmVerbose, 1, 0) ///< -dA, -fverbose-asm.

[PATCH] D90507: Adding DWARF64 clang flag

ikudrin added a comment. 1. The patch needs tests to check the added functionality. 2. DWARF64 can be generated only for a limited number of targets. There should be diagnostics for invalid switch combinations to prevent misuse. @MaskRay mentioned that in the patch for `llc`, D87011#2254749

[PATCH] D88021: [clang] Fix a misleading variable name. NFC.

This revision was automatically updated to reflect the committed changes. Closed by commit rG474d527c28f4: [clang] Fix a misleading variable name. NFC. (authored by ikudrin). Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D88021/new/

[PATCH] D88021: [clang] Fix a misleading variable name. NFC.

ikudrin created this revision. ikudrin added reviewers: thakis, hans, MaskRay. ikudrin added projects: LLVM, clang. ikudrin requested review of this revision. The variable is true when frame pointers should be omitted in leaf functions, not kept. Repository: rG LLVM Github Monorepo

[PATCH] D70527: [clang] Fix the canonicalization of paths in -fdiagnostics-absolute-paths

ikudrin added a comment. Personally, I would prefer to see the file name and path to be changed as little as possible because that would help to recognize the files better. We cannot use `remove_dots()` on POSIX OSes to simplify paths, because it may return an invalid path; thus we have to use

[PATCH] D59415: Do not resolve directory junctions for `-fdiagnostics-absolute-paths` on Windows.

ikudrin added a comment. I am not sure what you mean by "break". Can you share a reproducer? Repository: rC Clang CHANGES SINCE LAST ACTION https://reviews.llvm.org/D59415/new/ https://reviews.llvm.org/D59415 ___ cfe-commits mailing list

[PATCH] D59415: Do not resolve directory junctions for `-fdiagnostics-absolute-paths` on Windows.

This revision was automatically updated to reflect the committed changes. Closed by commit rC361598: Do not resolve directory junctions for `-fdiagnostics-absolute-paths` on… (authored by ikudrin, committed by ). Repository: rC Clang CHANGES SINCE LAST ACTION

[PATCH] D59415: Do not resolve directory junctions for `-fdiagnostics-absolute-paths` on Windows.

ikudrin updated this revision to Diff 200749. ikudrin edited the summary of this revision. ikudrin added a comment. Added a comment explaining the differences in the implementations. I would really appreciate any corrections. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D59415/new/

[PATCH] D59415: Do not resolve directory junctions for `-fdiagnostics-absolute-paths` on Windows.

ikudrin updated this revision to Diff 200252. ikudrin added a comment. - Made the patch affect only `-fdiagnostics-absolute-paths` option. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D59415/new/ https://reviews.llvm.org/D59415 Files: lib/Frontend/TextDiagnostic.cpp

[PATCH] D59415: Do not resolve directory junctions for `-fdiagnostics-absolute-paths` on Windows.

ikudrin added a comment. Ping. Please note, that, in contrary to POSIX OSes, on Windows a path like `dir1\\..` refers to `dir1`. That's why we do not need to ask the system for the fully expanded path and can do all calculations internally. Repository: rC Clang CHANGES SINCE LAST ACTION

[PATCH] D59415: Do not resolve directory junctions for `-fdiagnostics-absolute-paths` on Windows.

ikudrin marked an inline comment as done. ikudrin added inline comments. Comment at: test/Frontend/absolute-paths-windows.test:4 +// RUN: mkdir -p %t.dir\real +// RUN: cmd /c mklink /j %t.dir\junc %t.dir\real +// RUN: echo "wrong code" > %t.dir\real\foo.cpp

[PATCH] D59415: Do not resolve directory junctions for `-fdiagnostics-absolute-paths` on Windows.

ikudrin marked an inline comment as done. ikudrin added inline comments. Comment at: test/Frontend/absolute-paths-windows.test:4 +// RUN: mkdir -p %t.dir\real +// RUN: cmd /c mklink /j %t.dir\junc %t.dir\real +// RUN: echo "wrong code" > %t.dir\real\foo.cpp hans

[PATCH] D59415: Do not resolve directory junctions for `-fdiagnostics-absolute-paths` on Windows.

ikudrin created this revision. ikudrin added reviewers: ioeric, bkramer, hans, thakis, rsmith, zturner. Herald added a project: clang. This patch partially reverts D46942 . If the source file path contains directory junctions, and we resolve them when printing

[PATCH] D49589: [UBSan] Strengthen pointer checks in 'new' expressions

ikudrin added a comment. Did you consider dividing the patch into two separate changes to solve the two described issues independently? Repository: rC Clang https://reviews.llvm.org/D49589 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

[PATCH] D49589: [UBSan] Strengthen pointer checks in 'new' expressions

ikudrin added a comment. You may want to add a test for placement new, no? Repository: rC Clang https://reviews.llvm.org/D49589 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D48531: [CodeGen] Provide source locations for UBSan type checks when emitting constructor calls.

This revision was automatically updated to reflect the committed changes. Closed by commit rL335445: [CodeGen] Provide source locations for UBSan type checks when emitting… (authored by ikudrin, committed by ). Herald added a subscriber: llvm-commits. Changed prior to commit:

[PATCH] D48531: [CodeGen] Provide source locations for UBSan type checks when emitting constructor calls.

ikudrin created this revision. ikudrin added reviewers: rsmith, rjmccall. ikudrin added a project: clang. Herald added subscribers: JDevlieghere, aprantl. At the moment. when generating UBSan diagnostics for these cases, we rely on the corresponding debug information, which might be absent, and,

[PATCH] D43621: [Driver] Allow using a canonical form of '-fuse-ld=' when cross-compiling on Windows.

This revision was automatically updated to reflect the committed changes. Closed by commit rL326164: [Driver] Allow using a canonical form of -fuse-ld= when cross-compiling on… (authored by ikudrin, committed by ). Changed prior to commit: https://reviews.llvm.org/D43621?vs=135888=136026#toc

[PATCH] D43621: [Driver] Allow using a canonical form of '-fuse-ld=' when cross-compiling on Windows.

ikudrin updated this revision to Diff 135888. ikudrin added a comment. - Add a test. https://reviews.llvm.org/D43621 Files: lib/Driver/ToolChain.cpp test/Driver/Inputs/fuse_ld_windows/ld.foo.exe test/Driver/fuse-ld-windows.c Index: test/Driver/fuse-ld-windows.c

[PATCH] D43621: [Driver] Allow using a canonical form of '-fuse-ld=' when cross-compiling on Windows.

ikudrin added a comment. Not all toolchains call `ToolChain::GetLinkerPath`. For example, MSVC toolchain uses its own code: void visualstudio::Linker::ConstructJob(...) { ... StringRef Linker = Args.getLastArgValue(options::OPT_fuse_ld_EQ, "link"); if (Linker.equals_lower("lld"))

[PATCH] D43621: [Driver] Allow using a canonical form of '-fuse-ld=' when cross-compiling on Windows.

ikudrin added inline comments. Comment at: lib/Driver/ToolChain.cpp:415 // second-guess that. -if (llvm::sys::fs::exists(UseLinker)) +if (llvm::sys::fs::can_execute(UseLinker)) return UseLinker; Hahnfeld wrote: > I don't think we should do

[PATCH] D43621: [Driver] Allow using a canonical form of '-fuse-ld=' when cross-compiling on Windows.

ikudrin created this revision. ikudrin added reviewers: phosek, Hahnfeld, logan, rnk. ikudrin added a project: clang. Right now, we have to add an `.exe` suffix when using this switch, like `-fuse-ld=lld.exe`. If the suffix is omitted, `llvm::sys::fs::exists()` cannot find the file on Windows,