@@ -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 aar
@@ -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, Addend
@@ -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 R_X86_64_N
@@ -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
+
--
@@ -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, Addend
@@ -0,0 +1,18 @@
+# REQUIRES: powerpc-registered-target
+## Test CREL for a 32-bit big-endian target.
smithp35 wrote:
AIUI from
https://example61560.wordpress.com/wp-content/uploads/2016/11/powerpc_abi.pdf
Power PC uses RELA relocations. Would it be worth testi
@@ -3840,14 +3849,15 @@ void GNUELFDumper::printRelRelaReloc(const
Relocation &R,
template
static void printRelocHeaderFields(formatted_raw_ostream &OS, unsigned SType,
- const typename ELFT::Ehdr &EHeader) {
+
@@ -0,0 +1,180 @@
+# RUN: yaml2obj --docnum=1 %s -o %t
+# RUN: llvm-readobj -r %t | FileCheck %s --check-prefix=LLVM --match-full-lines
+# RUN: llvm-readelf -r %t | FileCheck %s --check-prefix=GNU --match-full-lines
+
+# LLVM: Relocations [
+# LLVM-NEXT: Section ([[#]]) .cr
@@ -123,6 +123,12 @@ class ContiguousBlobAccumulator {
return encodeULEB128(Val, OS);
}
+ unsigned writeSLEB128(int64_t Val) {
+if (!checkLimit(10))
smithp35 wrote:
I'm guessing 10 is from 64-bits extended to 10 groups of 7-bits extended to 8.
Unl
@@ -382,38 +382,6 @@ void BareMetal::AddClangCXXStdlibIncludeArgs(const ArgList
&DriverArgs,
}
}
-void BareMetal::AddCXXStdlibLibArgs(const ArgList &Args,
-ArgStringList &CmdArgs) const {
- switch (GetCXXStdlibType(Args)) {
- case ToolC
@@ -382,38 +382,6 @@ void BareMetal::AddClangCXXStdlibIncludeArgs(const ArgList
&DriverArgs,
}
}
-void BareMetal::AddCXXStdlibLibArgs(const ArgList &Args,
-ArgStringList &CmdArgs) const {
- switch (GetCXXStdlibType(Args)) {
- case ToolC
Author: Peter Smith
Date: 2021-09-07T15:46:19+01:00
New Revision: 5e71839f7793b3ab94e928654a493cb3d7216176
URL:
https://github.com/llvm/llvm-project/commit/5e71839f7793b3ab94e928654a493cb3d7216176
DIFF:
https://github.com/llvm/llvm-project/commit/5e71839f7793b3ab94e928654a493cb3d7216176.diff
L
smithp35 wrote:
Whatever we choose to do I think clang and llvm should be consistent. There's
no point in clang giving a warning if llvm is going to give an error.
I can see two positions most clearly:
* clang gives an error message for an eabihf target (or -mfloat-abi=hard). This
is what GCC
https://github.com/smithp35 edited
https://github.com/llvm/llvm-project/pull/110804
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/smithp35 commented:
Change looks good to me. A few small comment nits.
https://github.com/llvm/llvm-project/pull/110804
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commi
@@ -124,12 +124,11 @@ bool MultilibSet::select(const Driver &D, const
Multilib::flags_list &Flags,
}
// If this multilib is actually a placeholder containing a fatal
-// error message written by the multilib.yaml author, display that
-// error message, and ret
smithp35 wrote:
> This patch adds support for custom flags in the multilib YAML file.
>
> Details about this change can be found in this thread:
> https://discourse.llvm.org/t/rfc-multilib-custom-flags/81058
Apologies in advance for being a pain. Prior to commit, assuming that the RFC
has sta
https://github.com/smithp35 commented:
I'm not yet convinced that llvm is the right place for this error message.
There's quite a lot of test changes that I presume needed to make and at least
the LTO use case looks like we don't want to require extra information. I'd
also prefer this to be a
https://github.com/smithp35 edited
https://github.com/llvm/llvm-project/pull/111334
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -459,9 +459,6 @@ def warn_drv_assuming_mfloat_abi_is : Warning<
def warn_drv_unsupported_float_abi_by_lib : Warning<
"float ABI '%0' is not supported by current library">,
InGroup;
-def warn_drv_no_floating_point_registers: Warning<
smithp35 wrote:
This
smithp35 wrote:
> > front-end error/warning as this is a front-end/source-level mistake, with
> > better diagnostic control options available.
>
> There's a _lot_ of complicated logic required to determine, for each
> architecture, which target features affect the ABI in which ways. Are you
>
@@ -311,11 +311,15 @@ ARMBaseTargetMachine::getSubtargetImpl(const Function &F)
const {
// function that reside in TargetOptions.
resetTargetOptions(F);
I = std::make_unique(TargetTriple, CPU, FS, *this, isLittle,
-F.hasMinSi
@@ -217,15 +215,15 @@ struct MultilibSetSerialization {
template <> struct llvm::yaml::MappingTraits {
static void mapping(llvm::yaml::IO &io, MultilibSerialization &V) {
io.mapOptional("Dir", V.Dir);
-io.mapOptional("FatalError", V.FatalError);
+io.mapOptional("E
https://github.com/smithp35 edited
https://github.com/llvm/llvm-project/pull/110804
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/smithp35 approved this pull request.
Thanks for the updates. I don't have any more comments. I've approved the patch
on my side. Will be worth waiting for a bit to see if any other reviewers have
any feedback.
https://github.com/llvm/llvm-project/pull/110804
@@ -16,7 +16,7 @@
// RUN: %clang --target=arm-none-eabi -mcpu=cortex-m33 -mfloat-abi=hard -O1 %s
-flto=thin -c -o %t.call_thin.bc -DCALL_LIB
// RUN: %clang --target=arm-none-eabi -mcpu=cortex-m33 -mfloat-abi=hard -O1 %s
-flto=thin -c -o %t.define_thin.bc -DDEFINE_LIB
-// RUN
https://github.com/smithp35 edited
https://github.com/llvm/llvm-project/pull/111334
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -16,7 +16,7 @@
// RUN: %clang --target=arm-none-eabi -mcpu=cortex-m33 -mfloat-abi=hard -O1 %s
-flto=thin -c -o %t.call_thin.bc -DCALL_LIB
// RUN: %clang --target=arm-none-eabi -mcpu=cortex-m33 -mfloat-abi=hard -O1 %s
-flto=thin -c -o %t.define_thin.bc -DDEFINE_LIB
-// RUN
@@ -16,7 +16,7 @@
// RUN: %clang --target=arm-none-eabi -mcpu=cortex-m33 -mfloat-abi=hard -O1 %s
-flto=thin -c -o %t.call_thin.bc -DCALL_LIB
// RUN: %clang --target=arm-none-eabi -mcpu=cortex-m33 -mfloat-abi=hard -O1 %s
-flto=thin -c -o %t.define_thin.bc -DDEFINE_LIB
-// RUN
https://github.com/smithp35 commented:
Apologies for the delay in responding.
I don't have much to add over davemgreen and ostannard.
Leaving aside whether this should be an error in the front or back-end. As
mentioned before I haven't worked in this area for a long time, and there are
enough
=?utf-8?q?Csanád_Hajdú?=
Message-ID:
In-Reply-To:
https://github.com/smithp35 approved this pull request.
LGTM. Thanks for updating the code and test to account for Multilib. Apologies
for missing this last week.
Please leave some time for other reviewers to comment before merging.
https://
smithp35 wrote:
A couple of things I forgot to mention:
* Please can you update the in progress ReleaseNotes in
https://github.com/llvm/llvm-project/blob/main/clang/docs/ReleaseNotes.rst as
this is a potentially breaking change.
* It is fine to add `fixes https://github.com/llvm/llvm-project/is
https://github.com/smithp35 commented:
As statham-arm points out, please do replace the [FIXME]s in the description.
The first one is tpidruro, you can probably find the GCC version from the
changelog.
https://github.com/llvm/llvm-project/pull/128728
https://github.com/smithp35 edited
https://github.com/llvm/llvm-project/pull/128728
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -239,7 +240,7 @@ arm::ReadTPMode arm::getReadTPMode(const Driver &D, const
ArgList &Args,
D.Diag(diag::err_drv_invalid_mtp) << A->getAsString(Args);
return ReadTPMode::Invalid;
}
- return ReadTPMode::Soft;
+ return ReadTPMode::Auto;
smithp35 w
@@ -580,6 +581,9 @@ llvm::ARM::FPUKind arm::getARMTargetFeatures(const Driver
&D,
Features.push_back("+read-tp-tpidruro");
if (getReadTPMode(D, Args, Triple, ForAS) == ReadTPMode::TPIDRPRW)
Features.push_back("+read-tp-tpidrprw");
+ if (getReadTPMode(D, Args, Triple
@@ -580,6 +581,9 @@ llvm::ARM::FPUKind arm::getARMTargetFeatures(const Driver
&D,
Features.push_back("+read-tp-tpidruro");
smithp35 wrote:
We're calling getReadTPMode 4 times now, with the same parameters. and I don't
think it can return a different value
@@ -0,0 +1,6 @@
+// RUN: %clang --sysroot=%S/Inputs -c -fdriver-only -Werror
--target=aarch64-unknown-linux-gnu \
smithp35 wrote:
Can you check that this test still passes with a aarch64-none-elf bare-metal
target?
There's a !ForMultilib in the ARM code
https
@@ -240,7 +247,7 @@ arm::ReadTPMode arm::getReadTPMode(const Driver &D, const
ArgList &Args,
D.Diag(diag::err_drv_invalid_mtp) << A->getAsString(Args);
return ReadTPMode::Invalid;
}
- return (isHardTPSupported(Triple) ? ReadTPMode::TPIDRURO : ReadTPMode::Soft);
+
@@ -14,18 +14,18 @@
// RUN: FileCheck -check-prefix=ARMv7_THREAD_POINTER-TPIDRPRW %s
// ARMv7_THREAD_POINTER-TPIDRPRW: "-target-feature" "+read-tp-tpidrprw"
-// RUN: %clang --target=armv6t2-linux -mtp=cp15 -### -S %s 2>&1 | \
-// RUN: FileCheck -check-prefix=ARM_THREAD_POINTER
https://github.com/smithp35 commented:
I assume this is a rewrite of https://github.com/llvm/llvm-project/pull/128728
It looks like we've lost an explicit ``-mtp=auto``. I think that part is
important, my apologies if my earlier comment implied that we should remove it.
I've made a suggestion
@@ -239,7 +239,7 @@ arm::ReadTPMode arm::getReadTPMode(const Driver &D, const
ArgList &Args,
D.Diag(diag::err_drv_invalid_mtp) << A->getAsString(Args);
return ReadTPMode::Invalid;
}
- return ReadTPMode::Soft;
+ return (isHardTPSupported(Triple) ? ReadTPMode::TPID
@@ -42,4 +42,4 @@
// RUN: %clang --target=armv7-linux -### -S %s 2>&1 | \
// RUN: FileCheck -check-prefix=ARMv7_THREAD_POINTER_NON %s
-// ARMv7_THREAD_POINTER_NON-NOT: "-target-feature" "+read-tp-tpidruro"
+// ARMv7_THREAD_POINTER_NON: "-target-feature" "+read-tp-tpidruro"
---
https://github.com/smithp35 edited
https://github.com/llvm/llvm-project/pull/128901
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
smithp35 wrote:
The AArch64 ABI doesn't currently document an equivalent of `__aeabi_read_tp`
largely because in the 32-bit world not all targets have a dedicated
thread-pointer register.
I've very recently made a pull request to document the AArch64 TLS ABI
https://github.com/ARM-software/ab
@@ -110,20 +110,81 @@ static std::string computeBaseSysRoot(const Driver &D,
bool IncludeTriple) {
return std::string(SysRootDir);
}
+static bool hasGCCToolChainAlongSideClang(const Driver &D) {
+ SmallString<128> GCCDir;
+ llvm::sys::path::append(GCCDir, D.Dir, "..", D.g
https://github.com/smithp35 commented:
I'm looking at this patch in isolation, so its possible that the comments here
are addressed elasewhere.
It looks like useful functionality to add to the bare metal driver.
It also looks like there is some scope for some documentation, for users and
for
https://github.com/smithp35 edited
https://github.com/llvm/llvm-project/pull/121829
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -110,20 +110,81 @@ static std::string computeBaseSysRoot(const Driver &D,
bool IncludeTriple) {
return std::string(SysRootDir);
}
+static bool hasGCCToolChainAlongSideClang(const Driver &D) {
smithp35 wrote:
IIUC this is when we have something like clan
@@ -0,0 +1,12 @@
+// check that gnu assembler is invoked with arm baremetal as well
+
+// RUN: %clang --target=armv6m-none-eabi
--gcc-toolchain=%S/Inputs/basic_riscv32_tree -fno-integrated-as %s -### -c \
smithp35 wrote:
I'm a bit confused about this test. It i
@@ -239,12 +239,10 @@ static void getAArch64MultilibFlags(const Driver &D,
Result.push_back(BranchProtectionArg->getAsString(Args));
}
- if (Arg *AlignArg = Args.getLastArg(
- options::OPT_mstrict_align, options::OPT_mno_strict_align,
- options::OPT_mn
https://github.com/smithp35 commented:
I think it would be useful to mention in the Description that
-mno-unaligned-access and -mstrict-align are synonyms, and that we pass both
through so that the multilib.yaml file can select on either.
https://github.com/llvm/llvm-project/pull/134099
__
https://github.com/smithp35 approved this pull request.
LGTM, thanks for the update
https://github.com/llvm/llvm-project/pull/134099
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/smithp35 edited
https://github.com/llvm/llvm-project/pull/134099
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/smithp35 commented:
Apologies I've got a few more questions as I'm not sure I've understood.
https://github.com/llvm/llvm-project/pull/121829
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mail
@@ -110,20 +110,81 @@ static std::string computeBaseSysRoot(const Driver &D,
bool IncludeTriple) {
return std::string(SysRootDir);
}
+static bool hasGCCToolChainAlongSideClang(const Driver &D) {
+ SmallString<128> GCCDir;
+ llvm::sys::path::append(GCCDir, D.Dir, "..", D.g
https://github.com/smithp35 edited
https://github.com/llvm/llvm-project/pull/121829
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -110,20 +110,81 @@ static std::string computeBaseSysRoot(const Driver &D,
bool IncludeTriple) {
return std::string(SysRootDir);
}
+static bool hasGCCToolChainAlongSideClang(const Driver &D) {
smithp35 wrote:
> I am not aware if there is any common file
smithp35 wrote:
> > I'm looking at this patch in isolation, so its possible that the comments
> > here are addressed elasewhere.
> > It looks like useful functionality to add to the bare metal driver.
> > It also looks like there is some scope for some documentation, for users
> > and for toolc
@@ -110,20 +110,81 @@ static std::string computeBaseSysRoot(const Driver &D,
bool IncludeTriple) {
return std::string(SysRootDir);
}
+static bool hasGCCToolChainAlongSideClang(const Driver &D) {
+ SmallString<128> GCCDir;
+ llvm::sys::path::append(GCCDir, D.Dir, "..", D.g
101 - 160 of 160 matches
Mail list logo
