https://github.com/aganea approved this pull request.
https://github.com/llvm/llvm-project/pull/145737
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
aganea wrote:
> Would it be sufficient to change the `/Fo...` argument to `-Fo...` ?
You actually have to add hyphens before %s in the tests, such as:
`// RUN: not %clang_cl -c --target=x86_64-windows-msvc -O2 /Z7
-fms-secure-hotpatch-functions-file=%S/this-file-is-intentionally-missing-do-not
aganea wrote:
> #145737 for fix.
>
> I tried moving my checkout dir to `/Users`, but this had no effect on the
> tests.
You can also check the test command lines and the outputs by running a single
test in a more verbose more, such as:
```
> py {build_folder}/bin/llvm-lit.py -a -vv
> clang/t
aganea wrote:
> #145737 for fix.
>
> I tried moving my checkout dir to `/Users`, but this had no effect on the
> tests.
@nico might know a repro perhaps.
https://github.com/llvm/llvm-project/pull/145565
___
cfe-commits mailing list
cfe-commits@lists
aganea wrote:
> I just tried building and running tests under Ubuntu 24.04. The tests passed,
> i.e. they didn't hit the same problem. So I don't have an easy way to verify
> a fix.
I recall on MacOS the issue happens in a /Users/ folder (with this exact
casing). Are you able to move the chec
aganea wrote:
> Is there a way I could have detected this during my local builds, before
> submitting a PR?
I assume checking out the repo on a Linux box under /opt/… and running the
tests would yield the same issue, but I haven’t tried it.
https://github.com/llvm/llvm-project/pull/145565
___
aganea wrote:
> Both the original patch and the redo break the [Solaris/amd64
> buildbot](https://lab.llvm.org/staging/#/builders/120/builds/9897). I wonder
> if somehow the fact that the source lives in `/opt/llvm-buildbot` somehow
> interferes with Windows command line parsing?
Yes, the fil
@@ -560,11 +560,12 @@ bool AsmPrinter::doInitialization(Module &M) {
}
if (MAI->doesSupportDebugInformation()) {
-bool EmitCodeView = M.getCodeViewFlag();
-if (EmitCodeView &&
-(TM.getTargetTriple().isOSWindows() || TM.getTargetTriple().isUEFI()))
+// O
@@ -613,19 +613,30 @@ static SourceLanguage MapDWLangToCVLang(unsigned DWLang) {
void CodeViewDebug::beginModule(Module *M) {
// If module doesn't have named metadata anchors or COFF debug section
aganea wrote:
Adjust comment.
https://github.com/llvm/llvm-pr
@@ -98,6 +98,9 @@ class LLVM_LIBRARY_VISIBILITY CodeViewDebug : public
DebugHandlerBase {
/// The codeview CPU type used by the translation unit.
codeview::CPUType TheCPU;
+ /// Whether to emit compiler information only.
+ bool NoDebug = false;
aganea w
https://github.com/aganea commented:
This PR will all depend on the course taken on
https://github.com/llvm/llvm-project/pull/142970
https://github.com/llvm/llvm-project/pull/142969
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists
https://github.com/aganea edited
https://github.com/llvm/llvm-project/pull/142969
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,57 @@
+; RUN: llc -filetype=obj -o - %s | llvm-readobj --codeview - | FileCheck %s
+
+; ModuleID = 'a.c'
+source_filename = "a.c"
+target datalayout =
"e-m:w-p270:32:32-p271:32:32-p272:64:64-i64:64-i128:128-f80:128-n8:16:32:64-S128"
+target triple = "x86_64-unknown-win
aganea wrote:
> In this version, Clang emits a full debug IR, but if we're going to do this
> by default, it probably makes more sense to emit just a minimal `llvm.dbg.cu`
> when debug info isn’t otherwise enabled. I’ve already experimented with that
> approach.
Yes, I think one of my worry re
aganea wrote:
The other a bit related point to this, is perhaps we should re-evaluate
enabling `/HOTPATCH` at all times on x64 targets, like MSVC.
https://github.com/llvm/llvm-project/pull/142970
___
cfe-commits mailing list
cfe-commits@lists.llvm.or
aganea wrote:
MSVC emits this debug section at all times (S_OBJNAME and S_COMPILE3). Can't we
do the same without checking for the `getModuleFlag("ms-hotpatch")` flag?
https://github.com/llvm/llvm-project/pull/142970
___
cfe-commits mailing list
cfe-c
https://github.com/aganea approved this pull request.
LGTM. Perhaps you might want to wait a few days before commiting, in case
others would like to comment.
https://github.com/llvm/llvm-project/pull/138972
___
cfe-commits mailing list
cfe-commits@lis
@@ -0,0 +1,283 @@
+//===-- WindowsHotPatch.cpp - Support for Windows hotpatching
-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Ap
https://github.com/aganea edited
https://github.com/llvm/llvm-project/pull/138972
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/aganea edited
https://github.com/llvm/llvm-project/pull/138972
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/aganea edited
https://github.com/llvm/llvm-project/pull/138972
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/aganea edited
https://github.com/llvm/llvm-project/pull/138972
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/aganea edited
https://github.com/llvm/llvm-project/pull/138972
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,283 @@
+//===-- WindowsHotPatch.cpp - Support for Windows hotpatching
-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Ap
https://github.com/aganea commented:
The patch looks good to me, but I have one last question:
https://github.com/llvm/llvm-project/pull/138972
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-
https://github.com/aganea edited
https://github.com/llvm/llvm-project/pull/138972
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -176,6 +176,21 @@ class CallerSym : public SymbolRecord {
uint32_t RecordOffset = 0;
};
+class HotPatchFuncSym : public SymbolRecord {
aganea wrote:
Thanks! Would that tooling remain proprietary, or is it something that will be
open-sourced as well, for
@@ -453,6 +453,37 @@ CodeGenModule::CodeGenModule(ASTContext &C,
if (Context.getTargetInfo().getTriple().getArch() == llvm::Triple::x86)
getModule().addModuleFlag(llvm::Module::Error, "NumRegisterParameters",
CodeGenOpts.NumRegisterParameters
@@ -0,0 +1,20 @@
+// This verifies that hotpatch function attributes are correctly propagated
when compiling directly to OBJ.
+//
+// RUN: %clang_cl -c --target=x86_64-windows-msvc -O2 /Z7
-fms-hotpatch-functions-file=%S/ms-hotpatch-functions.txt /Fo%t.obj %s
ag
https://github.com/aganea edited
https://github.com/llvm/llvm-project/pull/138972
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/aganea edited
https://github.com/llvm/llvm-project/pull/138972
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -453,6 +453,37 @@ CodeGenModule::CodeGenModule(ASTContext &C,
if (Context.getTargetInfo().getTriple().getArch() == llvm::Triple::x86)
getModule().addModuleFlag(llvm::Module::Error, "NumRegisterParameters",
CodeGenOpts.NumRegisterParameters
@@ -0,0 +1,18 @@
+// This verifies that hotpatch function attributes are correctly propagated
through LLVM IR when compiling with LTO.
+//
+// RUN: %clang_cl -c --target=x86_64-windows-msvc -O2 /Z7
-fms-hotpatch-functions-file=%S/ms-hotpatch-functions.txt -flto /Fo%t.bc %s
-
@@ -0,0 +1,242 @@
+//===-- WindowsHotPatch.cpp - Support for Windows hotpatching
-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Ap
@@ -807,6 +809,32 @@ void CodeViewDebug::emitObjName() {
endSymbolRecord(CompilerEnd);
}
+void CodeViewDebug::emitHotPatchInformation() {
aganea wrote:
As mentionned before, maybe better to rename to
`emitSecureHotPatchInformation()`
https://github.com/ll
@@ -250,6 +250,7 @@ add_llvm_component_library(LLVMCodeGen
VirtRegMap.cpp
WasmEHPrepare.cpp
WindowScheduler.cpp
+ WindowsHotPatch.cpp
aganea wrote:
Similarily, `WindowsSecureHotPatch.cpp`?
https://github.com/llvm/llvm-project/pull/138972
__
@@ -6946,6 +6946,16 @@ void Clang::ConstructJob(Compilation &C, const JobAction
&JA,
Args.AddLastArg(CmdArgs, options::OPT_fms_hotpatch);
+ if (Arg *A = Args.getLastArg(options::OPT_fms_hotpatch_functions_file)) {
aganea wrote:
Idem, extra brace.
https:
aganea wrote:
Oh so all this dance (`_ref_` and the additional metadata) is for code page
integrity purposes? To keep them unmodified in memory? So how does then the
kernel use the PE metadata if it doesn't patch the code memory pages of the
initial (running) image? Is there an additional mech
aganea wrote:
Thanks for the answer.
Are these new flags `-fms-hotpatch-functions-file=` and
`-fms-hotpatch-functions-list=` populated with data maintained manually by the
Windows developpers?
If I understand correctly, what you describe as "symbols that were hot-patched"
means functions tha
@@ -0,0 +1,20 @@
+// This verifies that hotpatch function attributes are correctly propagated
when compiling directly to OBJ.
+//
+// RUN: %clang_cl -c --target=x86_64-windows-msvc -O2 /Z7
-fms-hotpatch-functions-file=%S/ms-hotpatch-functions.txt /Fo%t.obj %s
ag
@@ -176,6 +176,21 @@ class CallerSym : public SymbolRecord {
uint32_t RecordOffset = 0;
};
+class HotPatchFuncSym : public SymbolRecord {
aganea wrote:
Out of curiosity (related to my other questions), historically Windows updates
only deliver binaries (DL
aganea wrote:
Since the [MSVC
flag](https://learn.microsoft.com/en-us/cpp/build/reference/hotpatch-create-hotpatchable-image?view=msvc-170)
`/HOTPATCH` has been supported in LLVM and clang-cl for quite a while now (see
[this](https://reviews.llvm.org/D116511), and #77245 and #87639) the
descr
Author: Alexandre Ganea
Date: 2025-04-11T17:50:15-04:00
New Revision: 46135ade9ec0b7fd975b5d3923aea95f4d416296
URL:
https://github.com/llvm/llvm-project/commit/46135ade9ec0b7fd975b5d3923aea95f4d416296
DIFF:
https://github.com/llvm/llvm-project/commit/46135ade9ec0b7fd975b5d3923aea95f4d416296.dif
Author: Alexandre Ganea
Date: 2025-04-11T17:50:14-04:00
New Revision: 12c4be1ba8513b4c0f43945c0f266d7f871a978a
URL:
https://github.com/llvm/llvm-project/commit/12c4be1ba8513b4c0f43945c0f266d7f871a978a
DIFF:
https://github.com/llvm/llvm-project/commit/12c4be1ba8513b4c0f43945c0f266d7f871a978a.dif
@@ -1206,6 +1245,19 @@ void Writer::createMiscChunks() {
IMAGE_DLL_CHARACTERISTICS_EX_CET_COMPAT));
}
+ if (writeLTO) {
+debugRecords.emplace_back(COFF::IMAGE_DEBUG_TYPE_POGO,
+ make(ltcg));
aganea wrote:
I had a more in-depth look at this. Overall I don't agree with the whole
direction of this patch. I don't think it's wise for LLD to emit debug
records/`coffgrp` that do not match what MSVC is generating. We can't just
blindly emit a record with the string of the debug type (ie.
aganea wrote:
> I would like to benchmark `lld` after this change, since I have added a loop
> that goes through every section of every object file. Could someone point in
> the direction of a good benchmark for that? I was thinking I can benchmark on
> the linking of `clang` or any other big
aganea wrote:
I am just curious what is the purpose of this? Is it just for feature parity?
Can you also investigate if MSVC emits other special things/sections in the
binary in LTCG/PGO builds?
https://github.com/llvm/llvm-project/pull/114260
___
cf
@@ -0,0 +1,13 @@
+// This test checks if Window PE file compiled with -flto option contains a
magic
+// string "LTCG" to indicate LTO compilation.
+
+// REQUIRES: system-windows
+
+// RUN: %clang --target=x86_64-pc-windows-msvc -flto -fuse-ld=lld %s -o %t.exe
+// RUN: dumpbin /H
https://github.com/aganea edited
https://github.com/llvm/llvm-project/pull/114260
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,13 @@
+// This test checks if Window PE file compiled with -flto option contains a
magic
+// string "LTCG" to indicate LTO compilation.
+
+// REQUIRES: system-windows
+
+// RUN: %clang --target=x86_64-pc-windows-msvc -flto -fuse-ld=lld %s -o %t.exe
+// RUN: dumpbin /H
https://github.com/aganea edited
https://github.com/llvm/llvm-project/pull/109795
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -7,7 +7,10 @@
//===--===//
//
/// \file
-/// Defines the virtual file system interface vfs::FileSystem.
+/// Provides abstract filesystem APIs to decouple from OS-level file access.
+///
+/// This allows re
@@ -648,18 +648,54 @@ class InBeforeInTUCacheEntry {
/// instances.
using ModuleBuildStack = ArrayRef>;
-/// This class handles loading and caching of source files into memory.
+/// The SourceManager describes the compiler's view of source code.
///
-/// This object owns the
@@ -648,18 +648,54 @@ class InBeforeInTUCacheEntry {
/// instances.
using ModuleBuildStack = ArrayRef>;
-/// This class handles loading and caching of source files into memory.
+/// The SourceManager describes the compiler's view of source code.
///
-/// This object owns the
https://github.com/aganea approved this pull request.
https://github.com/llvm/llvm-project/pull/108342
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/aganea approved this pull request.
https://github.com/llvm/llvm-project/pull/106369
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
aganea wrote:
> I always set Argv0 and Commandline, even if they are just an empty string.
> Some tools had issues if those were not set. We already did use the empty
> string for BuildInfoRecord::TypeServerPDB, so now its also more consistent.
Ah yes, that's good. Looks good, thanks again!
aganea wrote:
The code LG but I’d like please @nebulark if you can explain de unit tests
changes? Why those offset changes? The code should emit the same thing as
before?
https://github.com/llvm/llvm-project/pull/106369
___
cfe-commits mailing list
c
aganea wrote:
> Maded the suggested changes. Continuing looking into the failing tests. This
> is my first llvm pr and I need some time to figure out the issues those are
> indicating and replicating those locally.
I recommend that you build a Debug target, ie. `cmake -DCMAKE_BUILD_TYPE=Debug
https://github.com/aganea edited
https://github.com/llvm/llvm-project/pull/106369
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -321,6 +322,41 @@ static bool actionRequiresCodeGen(BackendAction Action) {
Action != Backend_EmitLL;
}
+static std::string flattenClangCommandLine(ArrayRef Args,
+ StringRef MainFilename) {
+ std::string FlatCmdLine;
+ raw_st
@@ -91,8 +91,11 @@ class MCTargetOptions {
std::string SplitDwarfFile;
std::string AsSecureLogFile;
- const char *Argv0 = nullptr;
- ArrayRef CommandLineArgs;
+ // This will be set as compiler path in LF_BUILDINFO
aganea wrote:
You would need to refer
https://github.com/aganea commented:
Sounds good, but please correct the failing BuildKit tests (below) before we
can go further.
https://github.com/llvm/llvm-project/pull/106369
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.ll
https://github.com/aganea edited
https://github.com/llvm/llvm-project/pull/106369
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -893,6 +893,8 @@ static TypeIndex getStringIdTypeIdx(GlobalTypeTableBuilder
&TypeTable,
return TypeTable.writeLeafType(SIR);
}
+// This just exists for backwards compatability for the deprecated
MCTargetOptions::CommandLineArgs
+// It assumed a clang compiler frontend
@@ -950,9 +952,16 @@ void CodeViewDebug::emitBuildInfo() {
if (Asm->TM.Options.MCOptions.Argv0 != nullptr) {
BuildInfoArgs[BuildInfoRecord::BuildTool] =
getStringIdTypeIdx(TypeTable, Asm->TM.Options.MCOptions.Argv0);
-BuildInfoArgs[BuildInfoRecord::CommandLine
https://github.com/aganea requested changes to this pull request.
https://github.com/llvm/llvm-project/pull/106369
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -92,8 +92,15 @@ class MCTargetOptions {
std::string AsSecureLogFile;
const char *Argv0 = nullptr;
+
+ // Deprecated: Use FlatCommandlineArgs instead
+ // Arguments here are interpreted as coming from clang, formated and end up
in LF_BUILDINFO as CommandLineArgs
A
@@ -92,8 +92,15 @@ class MCTargetOptions {
std::string AsSecureLogFile;
const char *Argv0 = nullptr;
aganea wrote:
Would you mind please moving (and adapting) the comment that you've added here
above? Both Argv0 and CommandLineArgs are only used for stor
https://github.com/aganea approved this pull request.
Thanks for the explanation!
https://github.com/llvm/llvm-project/pull/102540
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
aganea wrote:
To give the whole picture, the story is that while building the LLVM package on
Windows, I was seeing this:
```
[51/52] Running sanitizer_common testsllvm-lit.py:
C:\src\git\llvm-project\llvm\utils\lit\lit\llvm\config.py:57: note: using lit
tools: C:\Program Files\Git\usr\bin\
ll
https://github.com/aganea edited
https://github.com/llvm/llvm-project/pull/102834
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/aganea edited
https://github.com/llvm/llvm-project/pull/102834
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/aganea edited
https://github.com/llvm/llvm-project/pull/102834
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/aganea edited
https://github.com/llvm/llvm-project/pull/102834
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/aganea created
https://github.com/llvm/llvm-project/pull/102834
Before this PR, `clang --print-runtime-dir` used to report a non-existant
directory if `LLVM_ENABLE_PER_TARGET_RUNTIME_DIR=OFF`.
We now check if any of the known runtime directories exist before printing on
std
https://github.com/aganea closed
https://github.com/llvm/llvm-project/pull/102681
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/aganea updated
https://github.com/llvm/llvm-project/pull/102681
>From 16efda65bb3d30b67b3215d7e8d69a105e2d771c Mon Sep 17 00:00:00 2001
From: Alexandre Ganea
Date: Fri, 9 Aug 2024 16:32:09 -0400
Subject: [PATCH 1/2] [Clang][CodeGen] Fix a bad codegen when building Clang
with
aganea wrote:
> Might be nice to clean this up in the future when Microsoft releases a fix.
I can add a comment to that effect.
https://github.com/llvm/llvm-project/pull/102681
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm
https://github.com/aganea approved this pull request.
This solves the performance issue I was seeing on Windows with a C++ clang
database. Thanks again for doing this @jansvoboda11!
https://github.com/llvm/llvm-project/pull/88800
___
cfe-commits maili
aganea wrote:
> This enables more efficient implementation of the caching VFS in #88800.
Thanks @jansvoboda11 for working on this, I appreciate. One question, what do
you mean by "more efficient"?
https://github.com/llvm/llvm-project/pull/102540
___
https://github.com/aganea edited
https://github.com/llvm/llvm-project/pull/102681
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/aganea edited
https://github.com/llvm/llvm-project/pull/102681
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/aganea edited
https://github.com/llvm/llvm-project/pull/102681
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/aganea edited
https://github.com/llvm/llvm-project/pull/102681
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/aganea edited
https://github.com/llvm/llvm-project/pull/102681
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/aganea created
https://github.com/llvm/llvm-project/pull/102681
Before this PR, when using the latest MSVC `Microsoft (R) C/C++ Optimizing
Compiler Version 19.40.33813 for x64` one of the Clang unit test used to fail:
`CodeGenObjC/gnustep2-direct-method.m`, see full failure
aganea wrote:
Ping @jansvoboda11! Just checking if you had time to finish this PR, to then
possibly integrate it into 19.x.
https://github.com/llvm/llvm-project/pull/88800
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/
aganea wrote:
> I will say, `-fno-eliminate-unused-debug-types` is a really heavy hammer that
> makes debug info much larger - and my understanding was that games tended to
> have trouble with large debug builds, so I'd be surprised if this was a great
> path forward.
Absolutely, this is only
aganea wrote:
> Yes, feel free to take over that part, thanks!
@amykhuang : I took a look at https://reviews.llvm.org/D89286. It works but
doesn't fix the most problematic case where the `constexpr` member needs an
evaluation that relies on dependent values:
```
template
struct C {
https://github.com/aganea closed https://github.com/llvm/llvm-project/pull/95259
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
aganea wrote:
Thanks @amykhuang for taking a look!
I won't close https://github.com/llvm/llvm-project/issues/46924 right away,
since we also need https://reviews.llvm.org/D89286. Do you mind if I took
ownership of that patch and send a PR crediting you?
https://github.com/llvm/llvm-project/pu
https://github.com/aganea edited https://github.com/llvm/llvm-project/pull/95259
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/aganea edited https://github.com/llvm/llvm-project/pull/95259
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/aganea created
https://github.com/llvm/llvm-project/pull/95259
This is used to set DebugInfoKind to "UnusedTypeInfo". This helps in the
context Unreal Engine and NATVIS files that reference unused otherwise `static
constexpr` class members. See
https://udn.unrealengine.com/
https://github.com/aganea closed https://github.com/llvm/llvm-project/pull/89950
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/aganea updated
https://github.com/llvm/llvm-project/pull/89950
>From 13c411018e491fc2be4f4118a56f9b8cf2e5b76f Mon Sep 17 00:00:00 2001
From: Alexandre Ganea
Date: Wed, 17 Apr 2024 16:28:21 -0400
Subject: [PATCH 1/5] [clang-scan-deps] Expand response files before the
argument
aganea wrote:
@jansvoboda11 Do you see any further changes for this PR? Can I land it?
https://github.com/llvm/llvm-project/pull/89950
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
aganea wrote:
Ping @jansvoboda11! Are you able to get back to this soon? LG generally, just
missing a test case above. Thanks!
https://github.com/llvm/llvm-project/pull/88800
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.o
1 - 100 of 240 matches
Mail list logo
