MaskRay wrote:
> I think we should update our documentation:
>
> https://github.com/llvm/llvm-project/blob/b01ac5137c28fa5e1b44a5d850cb7a6ace7d8799/clang/docs/UsersManual.rst?plain=1#L1186
>
> Overall, this seems like a sensible improvement to me and the code changes LG.
Thx. Updated
https://github.com/MaskRay edited
https://github.com/llvm/llvm-project/pull/93647
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/MaskRay updated
https://github.com/llvm/llvm-project/pull/93647
>From 9770644e7db88cff2c16109ceb8cb446741d53ea Mon Sep 17 00:00:00 2001
From: Fangrui Song
Date: Tue, 28 May 2024 21:33:55 -0700
Subject: [PATCH] =?UTF-8?q?[=F0=9D=98=80=F0=9D=97=BD=F0=9D=97=BF]=20initia?=
https://github.com/MaskRay approved this pull request.
https://github.com/llvm/llvm-project/pull/94729
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -86,6 +86,8 @@ DYNAMIC_TAG(RELRSZ, 35) // Size of Relr relocation table.
DYNAMIC_TAG(RELR, 36)// Address of relocation table (Relr entries).
DYNAMIC_TAG(RELRENT, 37) // Size of a Relr relocation entry.
+DYNAMIC_TAG(CREL, 38) // CREL relocation table
+
Author: Fangrui Song
Date: 2024-06-07T11:45:10-07:00
New Revision: c3a50879dfca9ab06ebfe52f48019bb6ac40bb4d
URL:
https://github.com/llvm/llvm-project/commit/c3a50879dfca9ab06ebfe52f48019bb6ac40bb4d
DIFF:
https://github.com/llvm/llvm-project/commit/c3a50879dfca9ab06ebfe52f48019bb6ac40bb4d.diff
https://github.com/MaskRay approved this pull request.
https://github.com/llvm/llvm-project/pull/94738
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
MaskRay wrote:
> I think other folks than myself also got a similar problem, so it's not just
> on my machine / setup.
>
> Should everybody set LLVM_DEFAULT_TARGET_TRIPLE with cmake instead of this
> patch? Sorry, not very familiar with this...
>
> Would it be ok to apply this for now?
The
MaskRay wrote:
> gcc -dumpmachine s390x-linux-gnu
Then I am afraid your clang configuration is not correct. It previously
detecting the GCC installation at `s390x-linux-gnu` is a mistake. You need to
set LLVM_DEFAULT_TARGET_TRIPLE correctly.
If for some reason you cannot change that, add
MaskRay wrote:
> `clang --version Target: s390x-ibm-linux`
What's `gcc -dumpmachine`? Is that `s390x-linux-gnu`.
If the normalized default target triple `s390x-ibm-linux`, it's not supposed to
detect a GCC installation for `s390x-linux-gnu`. You probably need to check
your
MaskRay wrote:
This is fine as a temporary workaround. What's `clang --version` on Ubuntu
s390x?
If it's390x-unknown-linux-gnu`, we have code to use `lib/s390x-linux-gnu`.
CMake LLVM_DEFAULT_TARGET_TRIPLE can be used to set the default target triple.
MaskRay wrote:
`.eh_frame` for non-C++-exception unwinding is pretty bad... As a new
architecture, you can avoid doing it...
https://ubuntu.com/blog/ubuntu-performance-engineering-with-frame-pointers-by-default
https://www.brendangregg.com/blog/2024-03-17/the-return-of-the-frame-pointers.html
https://github.com/MaskRay approved this pull request.
https://github.com/llvm/llvm-project/pull/94660
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/MaskRay approved this pull request.
https://github.com/llvm/llvm-project/pull/93783
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
MaskRay wrote:
Ping:)
(clang/docs/ReleaseNotes.rst has a conflict, which can be fixed after a rebase)
https://github.com/llvm/llvm-project/pull/93647
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
@@ -0,0 +1,31 @@
+// Test triple manipulations.
+
+// RUN: %clang -### -c %s \
+// RUN: -target i386-apple-darwin10 -mappletvsimulator-version-min=9.0
-arch x86_64 2>&1 | \
MaskRay wrote:
Perhaps 2-space indentation, which is much more common.
(`-target `
@@ -826,6 +826,10 @@ SanitizerMask Linux::getSupportedSanitizers() const {
if (IsX86_64 || IsAArch64) {
Res |= SanitizerKind::KernelHWAddress;
}
+ if (IsX86_64) {
+Res |= SanitizerKind::NumericalStability;
MaskRay wrote:
This needs a
https://github.com/MaskRay approved this pull request.
https://github.com/llvm/llvm-project/pull/93783
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -826,6 +826,10 @@ SanitizerMask Linux::getSupportedSanitizers() const {
if (IsX86_64 || IsAArch64) {
Res |= SanitizerKind::KernelHWAddress;
}
+ if (IsX86_64) {
+Res |= SanitizerKind::NumericalStability;
MaskRay wrote:
drop braces for
https://github.com/MaskRay edited
https://github.com/llvm/llvm-project/pull/93783
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/MaskRay approved this pull request.
https://github.com/llvm/llvm-project/pull/94349
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
MaskRay wrote:
(Friendly Ping:)
https://github.com/llvm/llvm-project/pull/91280
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
MaskRay wrote:
> Hi @Endilll
>
> I did a git bisect that pointed to this change as the one blocking my
> compilation on an Ubuntu docker image with clang 14.0
>
> The error I see:
>
> ```
> CMake Error at
> /test_radsan/llvm-project/compiler-rt/cmake/Modules/CheckSectionExists.cmake:72
>
MaskRay wrote:
> > I think requiring all driver tests pass with a custom DEFAULT_SYSROOT is an
> > undue burden.
> > Do you know why llvm-zorg/buildbot/osuosl/master/config/builders.py
> > llvm-clang-win-x-aarch64 needs to set DEFAULT_SYSROOT?
>
> This is the arm toolchain builders. They
MaskRay wrote:
> > The best I can do is mark them UNSUPPORTED: system-windows to get the bots
> > green again.
>
> This is not a good idea. You will disable these tests for the appropriate
> cross builders for no reason and they will became useless for them. I would
> strongly recommend to
MaskRay wrote:
> Looks like the buildbots' -DDEFAULT_SYSROOT strikes again (boo...). I think
> adding --sysroot="" is a common way to handle this for tests.
I think `DEFAULT_SYSROOT` should be phased out. Downstream users can customize
CMake `DEFAULT_SYSROOT` to set the default `--sysroot=`,
https://github.com/MaskRay updated
https://github.com/llvm/llvm-project/pull/93647
>From 9770644e7db88cff2c16109ceb8cb446741d53ea Mon Sep 17 00:00:00 2001
From: Fangrui Song
Date: Tue, 28 May 2024 21:33:55 -0700
Subject: [PATCH] =?UTF-8?q?[=F0=9D=98=80=F0=9D=97=BD=F0=9D=97=BF]=20initia?=
https://github.com/MaskRay approved this pull request.
https://github.com/llvm/llvm-project/pull/94136
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/MaskRay approved this pull request.
https://github.com/llvm/llvm-project/pull/89854
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -4141,6 +4141,20 @@
// Begin SystemZ/GCC/Linux tests
+// RUN: %clang -E -dM %s -o - 2>&1 \
+// RUN: -target s390x-ibm-zos \
MaskRay wrote:
`--target=` for new driver tests.
However, this does not test clangDriver and therefore
MaskRay wrote:
> @FHe
>
> > > > @MaskRay Got it.
> > > > The problem with that solution is that if you use --target you won't
> > > > get the correct arch. This would be a problem for any cross
> > > > compilation. For example, say you cross compile from zLinux (which
> > > > wouldn't have
https://github.com/MaskRay approved this pull request.
https://github.com/llvm/llvm-project/pull/94055
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
MaskRay wrote:
> > @gulfemsavrun Commit
> > [245491a](https://github.com/llvm/llvm-project/commit/245491a9f384e4c53421196533c2a2b693efaf8d)
> > (`[MC] Disable MCAssembler based constant folding for DwarfDebug`;
> > independent of this patch) should have fixed the compile time regression.
> >
https://github.com/MaskRay approved this pull request.
https://github.com/llvm/llvm-project/pull/93960
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/MaskRay approved this pull request.
https://github.com/llvm/llvm-project/pull/93889
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
MaskRay wrote:
Consider copying the original description to ensure that the linked issues will
be properly closed.
https://github.com/llvm/llvm-project/pull/93889
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
MaskRay wrote:
> We started seeing a build time regression in our Clang toolchain builders on
> Mac, and I bisected to this commit:
>
> 1. Build step took 1.7 hours in the last build before (clang -> build)
>
>
MaskRay wrote:
> > > I don't really understand the rationale for this, and it's kind of
> > > annoying. Most of the compiler's flags behave in the "last one wins"
> > > fashion (such as `-O2` and `-O0`) and it's always been convenient to add
> > > the flag you want at the end. Why treat
https://github.com/MaskRay closed
https://github.com/llvm/llvm-project/pull/90728
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/MaskRay approved this pull request.
LGTM. This avoids a temporary std::string, which might need a memory allocation.
https://github.com/llvm/llvm-project/pull/90728
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://github.com/MaskRay created
https://github.com/llvm/llvm-project/pull/93647
In GCC, `#pragma GCC diagnostic warning "-Wfoo"` overrides command-line
`-Werror=foo` and errors that can become warnings (pedwarn with
-pedantic-errors and permerror).
```
#pragma GCC diagnostic warning
Author: Fangrui Song
Date: 2024-05-28T15:33:59-07:00
New Revision: 20d497c26fc95c80a1bacb38820d92e5f52bec58
URL:
https://github.com/llvm/llvm-project/commit/20d497c26fc95c80a1bacb38820d92e5f52bec58
DIFF:
https://github.com/llvm/llvm-project/commit/20d497c26fc95c80a1bacb38820d92e5f52bec58.diff
MaskRay wrote:
> @MaskRay seems like this target might be too niche to go into LLVM at this
> time? is it worth considering some bar before accepting such a thing into
> LLVM, rather than encouraging folks to maintain such a thing in a branch for
> now?
Good question about the acceptance
@@ -259,7 +260,7 @@ class ELFObjectWriter : public MCObjectWriter {
void recordRelocation(MCAssembler , const MCAsmLayout ,
const MCFragment *Fragment, const MCFixup ,
MCValue Target, uint64_t ) override;
- bool usesRela(const
@@ -934,10 +943,51 @@ void ELFWriter::WriteSecHdrEntry(uint32_t Name, uint32_t
Type, uint64_t Flags,
WriteWord(EntrySize); // sh_entsize
}
+template
+static void encodeCrel(ArrayRef Relocs, raw_ostream ) {
+ uint OffsetMask = 8, Offset = 0, Addend = 0;
+ uint32_t Symidx
@@ -934,10 +943,51 @@ void ELFWriter::WriteSecHdrEntry(uint32_t Name, uint32_t
Type, uint64_t Flags,
WriteWord(EntrySize); // sh_entsize
}
+template
+static void encodeCrel(ArrayRef Relocs, raw_ostream ) {
MaskRay wrote:
done
@@ -474,9 +480,28 @@ struct Elf_Rel_Impl, true>
: public Elf_Rel_Impl, false> {
LLVM_ELF_IMPORT_TYPES(Endianness, true)
static const bool IsRela = true;
+ static const bool IsCrel = false;
Elf_Sxword r_addend; // Compute value for relocatable field by adding this.
@@ -86,6 +86,8 @@ DYNAMIC_TAG(RELRSZ, 35) // Size of Relr relocation table.
DYNAMIC_TAG(RELR, 36)// Address of relocation table (Relr entries).
DYNAMIC_TAG(RELRENT, 37) // Size of a Relr relocation entry.
+DYNAMIC_TAG(CREL, 38) // CREL relocation table
+
@@ -474,9 +480,28 @@ struct Elf_Rel_Impl, true>
: public Elf_Rel_Impl, false> {
LLVM_ELF_IMPORT_TYPES(Endianness, true)
static const bool IsRela = true;
+ static const bool IsCrel = false;
Elf_Sxword r_addend; // Compute value for relocatable field by adding this.
@@ -392,6 +393,70 @@ ELFFile::decode_relrs(Elf_Relr_Range relrs) const {
return Relocs;
}
+template
+uint64_t ELFFile::crelHeader(ArrayRef Content) const {
+ DataExtractor Data(Content, true, 8); // endian/class is irrelevant
MaskRay wrote:
done
@@ -321,6 +321,11 @@ class ELFFile {
std::vector decode_relrs(Elf_Relr_Range relrs) const;
+ uint64_t crelHeader(ArrayRef Content) const;
MaskRay wrote:
renamed to `getCrelHeader`
https://github.com/llvm/llvm-project/pull/91280
@@ -392,6 +393,70 @@ ELFFile::decode_relrs(Elf_Relr_Range relrs) const {
return Relocs;
}
+template
+uint64_t ELFFile::crelHeader(ArrayRef Content) const {
+ DataExtractor Data(Content, true, 8); // endian/class is irrelevant
+ DataExtractor::Cursor Cur(0);
+ uint64_t
https://github.com/MaskRay commented:
Thanks for the comments. Addressed
https://github.com/llvm/llvm-project/pull/91280
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/MaskRay edited
https://github.com/llvm/llvm-project/pull/91280
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/MaskRay updated
https://github.com/llvm/llvm-project/pull/91280
>From a0cfafb82db825512b0ca44778fa9d4bb435563d Mon Sep 17 00:00:00 2001
From: Fangrui Song
Date: Mon, 6 May 2024 15:37:50 -0700
Subject: [PATCH] =?UTF-8?q?[=F0=9D=98=80=F0=9D=97=BD=F0=9D=97=BF]=20initia?=
@@ -61,6 +61,9 @@ class MCTargetOptions {
bool Dwarf64 : 1;
+ // Use CREL relocation format for ELF.
+ bool Crel = false;
MaskRay wrote:
If LLVM adopts https://llvm.org/docs/Proposals/VariableNames.html , I'd like to
use `crel` instead of `cRel`. But
MaskRay wrote:
> > @MaskRay Got it.
> > The problem with that solution is that if you use --target you won't get
> > the correct arch. This would be a problem for any cross compilation. For
> > example, say you cross compile from zLinux (which wouldn't have the config
> > file), the arch
MaskRay wrote:
> I don't really understand the rationale for this, and it's kind of annoying.
> Most of the compiler's flags behave in the "last one wins" fashion (such as
> `-O2` and `-O0`) and it's always been convenient to add the flag you want at
> the end. Why treat action flags any
Author: Fangrui Song
Date: 2024-05-27T20:29:52-07:00
New Revision: 988cee7f96d6ba56dd465b9b2f3cfade3b6e2a3f
URL:
https://github.com/llvm/llvm-project/commit/988cee7f96d6ba56dd465b9b2f3cfade3b6e2a3f
DIFF:
https://github.com/llvm/llvm-project/commit/988cee7f96d6ba56dd465b9b2f3cfade3b6e2a3f.diff
MaskRay wrote:
#78065 for Hurd is a good example for clang testing.
https://github.com/llvm/llvm-project/pull/87845
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Author: Fangrui Song
Date: 2024-05-27T16:16:30-07:00
New Revision: 435ea21c897f94b5a3777a9f152e4c5bb4a371a3
URL:
https://github.com/llvm/llvm-project/commit/435ea21c897f94b5a3777a9f152e4c5bb4a371a3
DIFF:
https://github.com/llvm/llvm-project/commit/435ea21c897f94b5a3777a9f152e4c5bb4a371a3.diff
MaskRay wrote:
> [llvm] Add triples for managarm
I suggest that you split the patch into LLVM target triple part and a clang
part. That's a convention to support new targets.
https://github.com/llvm/llvm-project/pull/87845
___
cfe-commits mailing
https://github.com/MaskRay edited
https://github.com/llvm/llvm-project/pull/87845
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -279,8 +280,10 @@ class Triple {
Amplification,
OpenCL,
OpenHOS,
+Kernel,
+Mlibc,
MaskRay wrote:
I don't know how Mlibc is intended to be used but LLVM LTO warns about
differing target triples.
@@ -279,8 +280,10 @@ class Triple {
Amplification,
OpenCL,
OpenHOS,
+Kernel,
MaskRay wrote:
Why is a generic term `Kernel` added? I am concerned that it would cause
confusion to users of other OSes.
Does your OS need a different target
MaskRay wrote:
Some older `ToolChain`s were probably contributed with a lot of
`CmdArgs.push_back` uncovered by tests. They are not good examples to follow.
For new `ToolChain`s, we ensure that all constructed `CmdArgs.push_back` are
covered. This allows refactoring by someone who is
@@ -2562,7 +2566,10 @@ void
Generic_GCC::GCCInstallationDetector::AddDefaultGCCPrefixes(
static const char *const RISCV64LibDirs[] = {"/lib64", "/lib"};
static const char *const RISCV64Triples[] = {"riscv64-unknown-linux-gnu",
https://github.com/MaskRay approved this pull request.
https://github.com/llvm/llvm-project/pull/92997
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/MaskRay closed
https://github.com/llvm/llvm-project/pull/89772
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
MaskRay wrote:
> So PPC64 can use ELFv2 for `Triple::OpenBSD`. We probably want to diagnose
> this OS for PPC64, since with ELFv2 we might emit separate local and global
> entry points which means only certain values can be passed to
> `-fpatchable-function-entry` option.
This patch matches
https://github.com/MaskRay requested changes to this pull request.
https://github.com/llvm/llvm-project/pull/92997
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,49 @@
+; RUN: llc -mtriple=powerpc-unknown-linux-gnu %s -o - | FileCheck %s
--check-prefixes=CHECK,PPC32
MaskRay wrote:
`-mtriple=powerpc`. Prefer a generic ELF triple to a Linux specific one.
Suggest 2 RUN lines, `powerpc` and `powerpc64le`, to
@@ -6681,7 +6681,9 @@ void Clang::ConstructJob(Compilation , const JobAction
,
StringRef S0 = A->getValue(), S = S0;
unsigned Size, Offset = 0;
if (!Triple.isAArch64() && !Triple.isLoongArch() && !Triple.isRISCV() &&
-!Triple.isX86())
+
@@ -6,15 +6,20 @@
// RUN: %clang -target loongarch64 %s -fpatchable-function-entry=1,0 -c -###
2>&1 | FileCheck %s
// RUN: %clang -target riscv32 %s -fpatchable-function-entry=1,0 -c -### 2>&1
| FileCheck %s
// RUN: %clang -target riscv64 %s -fpatchable-function-entry=1,0 -c
@@ -0,0 +1,49 @@
+; RUN: llc -mtriple=powerpc-unknown-linux-gnu %s -o - | FileCheck %s
--check-prefixes=CHECK,PPC32
+; RUN: llc -mtriple=powerpc64-unknown-linux-gnu %s -o - | FileCheck %s
--check-prefixes=CHECK,PPC64
+
+define void @f0() {
+; CHECK-LABEL: f0:
+; CHECK-NOT:
@@ -0,0 +1,4 @@
+// RUN: %clang_cc1 -triple powerpc64-ibm-aix-xcoff -fsyntax-only -verify %s
+
+// expected-error@+1 {{'patchable_function_entry' attribute is not yet
supported on AIX}}
+__attribute__((patchable_function_entry(0))) void f();
MaskRay wrote:
Some
https://github.com/MaskRay edited
https://github.com/llvm/llvm-project/pull/92997
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Author: Fangrui Song
Date: 2024-05-23T16:03:46-07:00
New Revision: d03e56b27cd992e29482a21d88693f626f3dfffb
URL:
https://github.com/llvm/llvm-project/commit/d03e56b27cd992e29482a21d88693f626f3dfffb
DIFF:
https://github.com/llvm/llvm-project/commit/d03e56b27cd992e29482a21d88693f626f3dfffb.diff
https://github.com/MaskRay approved this pull request.
https://github.com/llvm/llvm-project/pull/92865
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -11,6 +11,8 @@
//
//===--===//
+#include "clang/Config/config.h"
MaskRay wrote:
If SystemZ.h uses CLANG_SYSTEMZ_DEFAULT_ARCH, that file should have `#include
"clang/Config/config.h"` as
@@ -801,7 +801,7 @@ static OutputDesc
*addInputSec(StringMap> ,
auto *firstIsec = cast(
cast(sec->commands[0])->sectionBases[0]);
OutputSection *firstIsecOut =
- firstIsec->flags & SHF_LINK_ORDER
MaskRay wrote:
A CppCheck issue
@@ -10,6 +10,8 @@
//
//===--===//
+#include "clang/Config/config.h"
MaskRay wrote:
unneeded include
https://github.com/llvm/llvm-project/pull/89854
@@ -11,6 +11,8 @@
//
//===--===//
+#include "clang/Config/config.h"
MaskRay wrote:
unneeded include
https://github.com/llvm/llvm-project/pull/89854
https://github.com/MaskRay approved this pull request.
Great
https://github.com/llvm/llvm-project/pull/92953
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/MaskRay closed
https://github.com/llvm/llvm-project/pull/92856
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
MaskRay wrote:
Oh, I didn't know #92820! Thanks. Landing...
https://github.com/llvm/llvm-project/pull/92856
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
MaskRay wrote:
@ilovepi I just realized that the FatLTO LLVM patch did not incorporate
https://reviews.llvm.org/D153215 . I thought it did... Hope this is not too
late.
https://github.com/llvm/llvm-project/pull/92856
___
cfe-commits mailing list
https://github.com/MaskRay created
https://github.com/llvm/llvm-project/pull/92856
This follows up to SHT_LLVM_LTO (https://reviews.llvm.org/D153215) and
resolves the comment of the FatLTO patch
https://reviews.llvm.org/D146776#4430626
>From fdf70f50de2d51223f3f04b2db4913360ded3469 Mon Sep 17
https://github.com/MaskRay approved this pull request.
https://github.com/llvm/llvm-project/pull/92841
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
MaskRay wrote:
https://discourse.llvm.org/t/rfc-nolock-and-noalloc-attributes/76837/75
contains a discussion about the subproject name.
Do you have opinions? @llvm/pr-subscribers-sanitizer @compnerd @petrhosek
@isanbard
https://github.com/llvm/llvm-project/pull/92460
@@ -0,0 +1,39 @@
+// Check that -fcf-protection does not get passed to the device-side
MaskRay wrote:
We also have unsupported-option-gpu.c to test various ignored options for GPU.
https://github.com/llvm/llvm-project/pull/88402
MaskRay wrote:
> @MaskRay It looks like the new version still causes large compile-time
> regressions for sqlite3 debug builds:
> http://llvm-compile-time-tracker.com/compare.php?from=7529fe2e92e79eef22a528a7168e4dd777d6e9bd=9500a5d02e23f9b43294e5f662ac099f8989c0e4=instructions:u
> It's
@@ -1,12 +1,12 @@
-//==- SemaRISCVVectorLookup.cpp - Name Lookup for RISC-V Vector Intrinsic -==//
+//==--- SemaRISCV.cpp --- RISC-V target-specific routines
--==//
MaskRay wrote:
The prevailing style starts with `//===-` or `//===--`
https://github.com/MaskRay approved this pull request.
https://github.com/llvm/llvm-project/pull/92682
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/MaskRay edited
https://github.com/llvm/llvm-project/pull/92682
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
MaskRay wrote:
Nice refactoring! Pushing a prerequisite commit first with `git mv
SemaRISCVVectorLookup.cpp SemaRISCV.cpp` should make git recognize this as a
file rename. This PR can be changed to rebase on that precommit.
https://github.com/llvm/llvm-project/pull/92682
@@ -0,0 +1,106 @@
+//===--- radsan_context.cpp - Realtime Sanitizer --*- C++ -*-===//
+//
+// 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:
https://github.com/MaskRay approved this pull request.
https://github.com/llvm/llvm-project/pull/92717
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Author: Fangrui Song
Date: 2024-05-19T23:35:15-07:00
New Revision: 9500a5d02e23f9b43294e5f662ac099f8989c0e4
URL:
https://github.com/llvm/llvm-project/commit/9500a5d02e23f9b43294e5f662ac099f8989c0e4
DIFF:
https://github.com/llvm/llvm-project/commit/9500a5d02e23f9b43294e5f662ac099f8989c0e4.diff
MaskRay wrote:
Removing `getUseAssemblerInfoForParsing` would make MCDwarfFrameEmitter::Emit
(for .eh_frame FDE) slow (~4% compile time regression for sqlite3.c
amalgamation) due to expensive `AttemptToFoldSymbolOffsetDifference`. For now,
make `UseAssemblerInfoForParsing` false in
1 - 100 of 2490 matches
Mail list logo
