@@ -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
https://github.com/MaskRay edited
https://github.com/llvm/llvm-project/pull/91082
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,71 @@
+# -*- Python -*-
+
+import os
+
+# Setup config name.
+config.name = "RADSAN" + config.name_suffix
+
+# Setup source root.
+config.test_source_root = os.path.dirname(__file__)
MaskRay wrote:
`msan`, `lsan`, `gwp_asan` places lit tests directly
@@ -0,0 +1,413 @@
+//===--- radsan_interceptors.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.
+//
@@ -0,0 +1,38 @@
+//===--- radsan_context.h - 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:
@@ -0,0 +1,52 @@
+//===--- radsan_stack.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:
@@ -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:
@@ -0,0 +1,50 @@
+//===--- radsan.h - 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: Apache-2.0 WITH
@@ -0,0 +1,52 @@
+//===--- radsan_stack.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:
@@ -0,0 +1,71 @@
+# -*- Python -*-
MaskRay wrote:
Delete
Some older `lit.cfg.py` files might use this because previously they were named
`lit.cfg`
https://github.com/llvm/llvm-project/pull/92460
___
cfe-commits
@@ -1382,6 +1382,10 @@ collectSanitizerRuntimes(const ToolChain , const
ArgList ,
StaticRuntimes.push_back("asan_cxx");
}
+ if (!SanArgs.needsSharedRt() && SanArgs.needsRadsanRt()) {
+StaticRuntimes.push_back("radsan");
+ }
MaskRay wrote:
I
https://github.com/MaskRay approved this pull request.
LGTM with a nit
https://github.com/llvm/llvm-project/pull/92708
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -435,9 +435,8 @@ static std::string replaceDotDot(StringRef Path) {
llvm::sys::path::const_iterator B = llvm::sys::path::begin(Path),
E = llvm::sys::path::end(Path);
while (B != E) {
-if (B->compare(".") == 0) {
-}
-else if (B->compare("..") == 0)
+
@@ -0,0 +1,100 @@
+# RUN: llvm-mc -filetype=obj -crel -triple=x86_64 %s -o %t.o
+# RUN: llvm-readelf -Sr -x .crelrodata2 -x .crelrodata16 %t.o | FileCheck %s
+
+# RUN: %if aarch64-registered-target %{ llvm-mc -filetype=obj -crel
-triple=aarch64_be %s -o %t.be.o %}
+# RUN: %if
@@ -1278,29 +1285,69 @@ void ELFState::writeSectionContent(
if (!Section.Relocations)
return;
+ const bool IsCrel = Section.Type == llvm::ELF::SHT_CREL;
const bool IsRela = Section.Type == llvm::ELF::SHT_RELA;
+ typename ELFT::uint OffsetMask = 8, Offset = 0,
@@ -3840,14 +3849,15 @@ void GNUELFDumper::printRelRelaReloc(const
Relocation ,
template
static void printRelocHeaderFields(formatted_raw_ostream , unsigned SType,
- const typename ELFT::Ehdr ) {
+ const
@@ -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
+
@@ -32,12 +32,17 @@ FileHeader:
# RUN: --match-full-lines --check-prefixes=GNU-RELOCS,GNU-PLTRELA
# LLVM-RELOCS: Dynamic Relocations {
+# LLVM-RELOCS-NEXT: 0x8 R_X86_64_64 foo 0x0
# LLVM-RELOCS-NEXT: 0x1 R_X86_64_NONE foo 0x0
# LLVM-RELOCS-NEXT: 0x2
@@ -123,6 +123,12 @@ class ContiguousBlobAccumulator {
return encodeULEB128(Val, OS);
}
+ unsigned writeSLEB128(int64_t Val) {
+if (!checkLimit(10))
MaskRay wrote:
Yes, LEB128 representing 64-bit integer needs at most 10 bytes.
I added a change
@@ -0,0 +1,18 @@
+# REQUIRES: powerpc-registered-target
+## Test CREL for a 32-bit big-endian target.
MaskRay wrote:
Thanks for the suggestion. Changed ppc to arm.
For static relocations, the RELA form is exclusively used as recommended
toolchain practice.
@@ -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
@@ -1278,29 +1285,69 @@ void ELFState::writeSectionContent(
if (!Section.Relocations)
return;
+ const bool IsCrel = Section.Type == llvm::ELF::SHT_CREL;
const bool IsRela = Section.Type == llvm::ELF::SHT_RELA;
+ typename ELFT::uint OffsetMask = 8, Offset = 0,
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?=
Author: Fangrui Song
Date: 2024-05-17T14:42:48-07:00
New Revision: e2db08f8f1a7dd37cd18705164f0c1188707e5b6
URL:
https://github.com/llvm/llvm-project/commit/e2db08f8f1a7dd37cd18705164f0c1188707e5b6
DIFF:
https://github.com/llvm/llvm-project/commit/e2db08f8f1a7dd37cd18705164f0c1188707e5b6.diff
@@ -0,0 +1,29 @@
+// RUN: %clang_cc1 -triple aarch64-none-linux-gnu -target-feature +sme -verify
-emit-llvm %s
MaskRay wrote:
`-emit-llvm-only` is more conventional when the output is unneeded.
In our internal build system, PWD is read-only and `-emit-llvm`
https://github.com/MaskRay closed
https://github.com/llvm/llvm-project/pull/92473
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
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 would be
@@ -949,11 +949,11 @@ tryEmitGlobalCompoundLiteral(ConstantEmitter ,
static llvm::Constant *
EmitArrayConstant(CodeGenModule , llvm::ArrayType *DesiredType,
- llvm::Type *CommonElementType, unsigned ArrayBound,
+ llvm::Type
https://github.com/MaskRay updated
https://github.com/llvm/llvm-project/pull/92473
>From fec942ed085d2a4004a6cefcb7fdf20a4b062ca3 Mon Sep 17 00:00:00 2001
From: Fangrui Song
Date: Thu, 16 May 2024 16:24:01 -0700
Subject: [PATCH] =?UTF-8?q?[=F0=9D=98=80=F0=9D=97=BD=F0=9D=97=BF]=20initia?=
https://github.com/MaskRay created
https://github.com/llvm/llvm-project/pull/92473
Based on @OfekShochat's https://reviews.llvm.org/D133648
init.c is the primary test for array initialization, but it uses a
32-bit triple, which would lead to an "array is too large" error. Add
the new test to
Author: Fangrui Song
Date: 2024-05-16T11:53:15-07:00
New Revision: 9a7f54ba4878c4e66c99430b52d8c014ab7b2a03
URL:
https://github.com/llvm/llvm-project/commit/9a7f54ba4878c4e66c99430b52d8c014ab7b2a03
DIFF:
https://github.com/llvm/llvm-project/commit/9a7f54ba4878c4e66c99430b52d8c014ab7b2a03.diff
https://github.com/MaskRay closed
https://github.com/llvm/llvm-project/pull/91082
___
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/91082
___
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/91082
>From 7e36c4d9f736b9b2eff29e565d22e01c29744c1e Mon Sep 17 00:00:00 2001
From: Fangrui Song
Date: Sat, 4 May 2024 13:10:21 -0700
Subject: [PATCH] =?UTF-8?q?[=F0=9D=98=80=F0=9D=97=BD=F0=9D=97=BF]=20initia?=
MaskRay wrote:
> > Thanks for the additional context. My main concern is that we're undoing
> > the consensus of [reviews.llvm.org/D45164](https://reviews.llvm.org/D45164)
> > which if I've understood the comments properly was "There is a reasonable
> > expectation that compiled (not
Author: Fangrui Song
Date: 2024-05-14T12:58:49-07:00
New Revision: 4cfe347c107485aab6bd003f99ab06aac242b0fd
URL:
https://github.com/llvm/llvm-project/commit/4cfe347c107485aab6bd003f99ab06aac242b0fd
DIFF:
https://github.com/llvm/llvm-project/commit/4cfe347c107485aab6bd003f99ab06aac242b0fd.diff
MaskRay wrote:
> This seems to [break
> something](https://lab.llvm.org/buildbot/#/builders/121/builds/41631) in
> LLVM... investigating
I've also noticed a stage-2-build issue.
```
llvm::any_of(LHS->users(),
[&](auto *U) {
return U != I &&
https://github.com/MaskRay edited
https://github.com/llvm/llvm-project/pull/91007
___
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/91007
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -2900,7 +2900,7 @@ defm clangir : BoolFOption<"clangir",
PosFlag,
NegFlag LLVM
pipeline to compile">,
BothFlags<[], [ClangOption, CC1Option], "">>;
-def emit_cir : Flag<["-"], "emit-cir">, Visibility<[CC1Option]>,
+def emit_cir : Flag<["-"], "emit-cir">,
MaskRay wrote:
> Ideally FileCheck should prefix commands with some tag to distinguish
> comments from filecheck annotations, like
> `--command-tag=@` and use as `@CHECK: xxx`, `@MYCHECK-NEXT: yyy`, etc. Making
> typo\error in both prefix and command tag will be harder, i guess. That way
>
https://github.com/MaskRay approved this pull request.
Some CHECK prefixes are auto-generated by llvm/utils/update_*_test_checks.py.
Let's say my build directory is `/tmp/Rel` while my source is at `~/llvm`, use
```
PATH=/tmp/Rel/bin:$PATH ~/llvm/llvm/utils/update_any_test_checks.py path/to/test
MaskRay wrote:
The previous failures reported by `buildkite/github-pull-requests Pending` were
genuine. I have fixed them separately.
When doing large scale cleanups, it might make sense to partition them, e.g.
llvm/ (clang/ & clang-tools-extra/) mlir/ in different PRs. The number of files
MaskRay wrote:
The clang/test/Driver codegen tests might have been removed. Note:
clang/test/Driver is to test how clangDriver passes options to cc1, not for
sema/codegen/etc.
https://github.com/llvm/llvm-project/pull/89727
___
cfe-commits mailing
1 - 100 of 2447 matches
Mail list logo
