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 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
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
@@ -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
@@ -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
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
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.
LGTM too, I've checked that the
`-DLIBCXX_STATICALLY_LINK_ABI_IN_STATIC_LIBRARY=ON` works. We, and other
bare-metal driver using toolchains can adopt that.
https://github.com/llvm/llvm-project/pull/101259
_
@@ -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
@@ -382,38 +382,6 @@ void BareMetal::AddClangCXXStdlibIncludeArgs(const ArgList
&DriverArgs,
}
}
-void BareMetal::AddCXXStdlibLibArgs(const ArgList &Args,
-ArgStringList &CmdArgs) const {
- switch (GetCXXStdlibType(Args)) {
- case ToolC
https://github.com/smithp35 approved this pull request.
After discussion in the PAuthABI call. We agreed that it would be best to have
an exemplar of how a signing schema for a platform should be encoded rather
than always using the individual options.
Anton mentioned that we can document that
https://github.com/smithp35 commented:
Does this need a clang command line option at this point? Would it be possible
to live with a {{-mllvm}} option to turn on signed GOT? I would expect signed
GOT (or not) would be part of a higher-level signing schema and not toggled at
a low-level via cla
https://github.com/smithp35 commented:
Apologies for the delay in responding, been a bit backed up. I like the idea of
pauthtest as it does give some leeway to change the signing schema.
I expect that with some work this could be made to work with bare-metal targets
too, but I think it is best
@@ -1546,16 +1581,28 @@ static void CollectARMPACBTIOptions(const ToolChain
&TC, const ArgList &Args,
CmdArgs.push_back(
Args.MakeArgString(Twine("-msign-return-address=") + Scope));
- if (Scope != "none")
+ if (Scope != "none") {
+if (Triple.getEnvironment() ==
https://github.com/smithp35 edited
https://github.com/llvm/llvm-project/pull/97237
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
smithp35 wrote:
I can't find a `-Wno-something-c++20-aggregate-init` in clang.
The closest I can find is
https://clang.llvm.org/docs/DiagnosticsReference.html#wc-20-compat which has a
text string
```
warning: aggregate initialization of type A with user-declared constructors is
incompatible
smithp35 wrote:
Apologies for the length of the post, it could probably do with more revisions
and research but I thought it better to send what I have and refine later after
comments. Most of this is a summation of a discussion had in the PAuthABI call,
followed by my attempts at analysing th
smithp35 wrote:
Apologies, it looks like I'm not going to get this out this morning, still
working on it.
https://github.com/llvm/llvm-project/pull/97237
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/li
smithp35 wrote:
Apologies for the delay, I was out of office Thursday/Friday and wanted to
discuss some possible options on the Monday call. I'll write something up based
on the discussion tomorrow (Tuesday 9th) morning. I am at a conference for a
lot of the week, so I maybe a bit slower to re
https://github.com/smithp35 approved this pull request.
Thanks for the update LGTM. I've set approved, but please wait for a few days
to let other reviewers comment.
https://github.com/llvm/llvm-project/pull/97827
___
cfe-commits mailing list
cfe-comm
@@ -0,0 +1,4 @@
+// RUN: %clang --target=aarch64-none-elf -march=armv8.9-a+rcpc3
-print-multi-flags-experimental -c %s 2>&1 | FileCheck %s
+
smithp35 wrote:
I think it could be worth a comment here explaining what the test is checking
for as it would likely nee
@@ -0,0 +1,4 @@
+// RUN: %clang --target=aarch64-none-elf -march=armv8.9-a+rcpc3
-print-multi-flags-experimental -c %s 2>&1 | FileCheck %s
+
+// CHECK: -march=armv8.9-a
+// CHECK-SAME: +rcpc+rcpc3+
smithp35 wrote:
I'm wondering if a `CHECK-NOT ++` could be used
https://github.com/smithp35 commented:
A couple of comments on the test, but otherwise from the Arm and AArch64
feature modelling this looks good to me. I agree that we are not losing any
useful functionality by omitting implicit flags that have no command line value.
https://github.com/llvm/l
https://github.com/smithp35 edited
https://github.com/llvm/llvm-project/pull/97827
___
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.
My apologies, I missed this one in my github mail folder.
LGTM, thanks for the update.
https://github.com/llvm/llvm-project/pull/97378
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http
https://github.com/smithp35 edited
https://github.com/llvm/llvm-project/pull/97237
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/smithp35 commented:
I'm wondering if it is worth resurrecting
https://discourse.llvm.org/t/aarch64-pauthabi-options-for-command-line-options-to-use-the-pauthabi-and-set-signing-schema/73479
to see if we can get some more visibility on this. It has also been almost a
year sin
@@ -1537,11 +1570,16 @@ static void CollectARMPACBTIOptions(const ToolChain
&TC, const ArgList &Args,
if (!isAArch64 && PBP.Key == "b_key")
D.Diag(diag::warn_unsupported_branch_protection)
<< "b-key" << A->getAsString(Args);
+if (!isAArch64 && PBP.HasPa
@@ -1484,6 +1484,39 @@ void AddUnalignedAccessWarning(ArgStringList &CmdArgs) {
}
}
+static void handlePAuthABIOption(const ArgList &DriverArgs,
smithp35 wrote:
I think it will be worth a comment above and possibly inline explaining the ABI
implications of t
https://github.com/smithp35 commented:
As I understand it we are implicitly defining the default signing schema for
ELF platforms with `-mbranch-protection=pauthabi` .
Is there any thought on how we want to manage signing schemas going forward?
For example I can imagine looking an environment
https://github.com/smithp35 edited
https://github.com/llvm/llvm-project/pull/97237
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,25 @@
+// RUN: not %clang -### -c --target=x86_64 -Wa,--crel %s 2>&1 | FileCheck %s
--check-prefix=NOEXP
+
+// NOEXP: error: -Wa,--allow-experimental-crel must be specified to use
-Wa,--crel. CREL is experimental and takes a non-standard section type code
+
+// RUN: %
@@ -801,6 +801,9 @@ def warn_drv_missing_multilib : Warning<
def note_drv_available_multilibs : Note<
"available multilibs are:%0">;
+def err_drv_experimental_crel : Error<
+ "-Wa,--allow-experimental-crel must be specified to use -Wa,--crel. CREL is
experimental and takes
@@ -0,0 +1,25 @@
+// RUN: not %clang -### -c --target=x86_64 -Wa,--crel %s 2>&1 | FileCheck %s
--check-prefix=NOEXP
+
+// NOEXP: error: -Wa,--allow-experimental-crel must be specified to use
-Wa,--crel. CREL is experimental and takes a non-standard section type code
+
+// RUN: %
https://github.com/smithp35 edited
https://github.com/llvm/llvm-project/pull/97378
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/smithp35 commented:
A few small comments, but otherwise looks good to me.
https://github.com/llvm/llvm-project/pull/97378
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-com
https://github.com/smithp35 approved this pull request.
LGTM from me too.
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
@@ -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
@@ -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
@@ -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,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
@@ -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
@@ -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 R_X86_64_N
@@ -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,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
@@ -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 &os) {
+ uint OffsetMask = 8, Offset = 0, Addend = 0;
+ uint32_t Symi
https://github.com/smithp35 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/smithp35 commented:
I've finished going through the patches now. Apologies for the delay.
I don't think I have too many substantive comments. Overall this looks like it
implements the specification as described in the confluence page.
https://github.com/llvm/llvm-project/pul
https://github.com/smithp35 approved this pull request.
I think it is reasonable to proceed given the RFC and the response.
https://github.com/llvm/llvm-project/pull/91082
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/c
@@ -1022,6 +1027,40 @@ ELFObjectFile::section_rel_begin(DataRefImpl Sec)
const {
uintptr_t SHT = reinterpret_cast((*SectionsOrErr).begin());
RelData.d.a = (Sec.p - SHT) / EF.getHeader().e_shentsize;
RelData.d.b = 0;
+ if (reinterpret_cast(Sec.p)->sh_type == ELF::SHT_CRE
@@ -1142,6 +1193,13 @@ ELFObjectFile::getRela(DataRefImpl Rela) const {
return *Ret;
}
+template
smithp35 wrote:
Is there any way this can be called before Crels has been populated? If not
then please ignore the rest of the comment.
It looks like getRelo
@@ -446,6 +450,7 @@ template class ELFObjectFile : public
ELFObjectFileBase {
const Elf_Rel *getRel(DataRefImpl Rel) const;
const Elf_Rela *getRela(DataRefImpl Rela) const;
+ Elf_Crel getCrel(DataRefImpl Rel) const;
smithp35 wrote:
Perhaps use CRel as
@@ -292,6 +293,9 @@ template class ELFObjectFile : public
ELFObjectFileBase {
const Elf_Shdr *DotSymtabSec = nullptr; // Symbol table section.
const Elf_Shdr *DotSymtabShndxSec = nullptr; // SHT_SYMTAB_SHNDX section.
+ // Hold CREL relocations for SectionRef::relocation
@@ -1117,9 +1166,11 @@ void ELFObjectFile::getRelocationTypeName(
template
Expected
ELFObjectFile::getRelocationAddend(DataRefImpl Rel) const {
- if (getRelSection(Rel)->sh_type != ELF::SHT_RELA)
-return createError("Section is not SHT_RELA");
- return (int64_t)getRela(R
@@ -321,6 +321,11 @@ class ELFFile {
std::vector decode_relrs(Elf_Relr_Range relrs) const;
+ uint64_t crelHeader(ArrayRef Content) const;
+ using RelsOrRelas = std::pair, std::vector>;
smithp35 wrote:
There is an identically named type in LLD which has a
https://github.com/smithp35 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/smithp35 commented:
Some initial comments based on a read of the ELFObjectFile. I haven't got as
far as the test and tools.
One general thought is whether it is worth adding in some more constants. For
example:
```
if (B & 1)
```
Could be something like:
```
if (B & DeltaSym
smithp35 wrote:
I think it would be useful to nominate a source as the canonical reference for
the specification which is updated along with any implementation changes. I
think
https://discourse.llvm.org/t/rfc-crel-a-compact-relocation-format-for-elf/77600/3
is a good starting point.
Possibl
https://github.com/smithp35 commented:
Code change LGTM.
Although currently trivial, would it be worth adding a Driver test for it.
Something like
https://github.com/llvm/llvm-project/blob/main/clang/test/Driver/funique-internal-linkage-names.c
https://github.com/llvm/llvm-project/pull/915
smithp35 wrote:
I will take a look, but may take me a while to go through it. Some very quick
comments:
* Would `--enable-experimental-crel` be a better name than
`--experimental-crel` that makes it clear that the option is just an unlock of
another flag, and not a flag in of itself?
* I agree
smithp35 wrote:
Thanks for the additional context. My main concern is that we're undoing the
consensus of https://reviews.llvm.org/D45164 which if I've understood the
comments properly was "There is a reasonable expectation that compiled (not
assembled) code should be identical, or at least as
https://github.com/smithp35 commented:
The code-changes look good, what I'm less sure about is whether this is the
right thing to do unconditionally.
A few months ago I would likely to have said this wouldn't matter that much as
most people don't use `-S` in there build systems so any failure
@@ -277,6 +277,8 @@ namespace llvm {
/// Use unique names for basic block sections.
unsigned UniqueBasicBlockSectionNames : 1;
+unsigned SeparateNamedSections : 1;
smithp35 wrote:
Almost all of the other flags have Doxygen comments. Worth somethin
@@ -221,6 +221,11 @@ New Compiler Flags
- ``-fexperimental-modules-reduced-bmi`` enables the Reduced BMI for C++20
named modules.
See the document of standard C++ modules for details.
+- ``-fseparate-named-sections`` uses separate unique sections for global
+ symbols in na
https://github.com/smithp35 commented:
Thanks for working on this! Just a couple of small comment suggestions from me.
https://github.com/llvm/llvm-project/pull/91028
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-b
https://github.com/smithp35 edited
https://github.com/llvm/llvm-project/pull/91028
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/smithp35 commented:
There was a previous attempt at doing something similar with more global
registers r6-r11 in https://reviews.llvm.org/D68862 based on
http://lists.llvm.org/pipermail/llvm-dev/2018-December/128706.html
This got reverted, and unfortunately didn't get picked
https://github.com/smithp35 approved this pull request.
LGTM, thanks for the confirmation.
https://github.com/llvm/llvm-project/pull/88287
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commi
smithp35 wrote:
Apologies I read the comments, rather than go through the code. It looks the
code has already made the v8-r imply a generic CPU.
So it looks like the code is doing what my proposal states so no objections
from me and apologies for the noise.
https://github.com/llvm/llvm-projec
smithp35 wrote:
I can chime in with an opinion but unfortunately I think it may be different to
everyone elses!
This is a bit of an awkward situation as I think we have to balance several
things:
* Consistency between v8-R and AArch32 (ARM) and AArch64 (more consistent the
better)
* Consisten
smithp35 wrote:
No objections from me. I would prefer there not to be a difference for assembly
at different optimisation levels.
I can't find any evidence that this affects Arm (Thumb to be precise) assembly
at all. For example:
```
.text
b dest// b.n 2-byte branch
smithp35 wrote:
> > If possible I would prefer to keep -m[no-]unaligned-access for AArch64.
> > The history of this option name derives from Arm's proprietary compiler
> > [developer.arm.com/documentation/dui0472/m/Compiler-Command-line-Options/--unaligned-accessno-unaligned-access](https://
https://github.com/smithp35 commented:
If possible I would prefer to keep -m[no-]unaligned-access for AArch64.
The history of this option name derives from Arm's proprietary compiler
https://developer.arm.com/documentation/dui0472/m/Compiler-Command-line-Options/--unaligned-accessno-unalign
@@ -321,9 +321,11 @@ void aarch64::getAArch64TargetFeatures(const Driver &D,
}
}
- if (Arg *A = Args.getLastArg(options::OPT_mno_unaligned_access,
- options::OPT_munaligned_access)) {
-if (A->getOption().matches(options::OPT_mno_unalign
smithp35 wrote:
Off the top of my head we default to `-ffunction-sections` and
`-fdata-sections` as this helps Garbage Collection, and we have a linker
feature that can merge constant pool entries between functions that needs the
gaps between the functions.
https://github.com/llvm/llvm-proj
@@ -895,20 +895,18 @@ llvm::ARM::FPUKind arm::getARMTargetFeatures(const Driver
&D,
// defaults this bit to 0 and handles it as a system-wide (not
// per-process) setting. It is therefore safe to assume that ARMv7+
// Linux targets support unaligned accesses. The s
@@ -3,6 +3,7 @@
; RUN: llc -mtriple=riscv64 < %s | FileCheck %s --check-prefix=RV64
@var = external dso_local global i32, align 4
+@a = external global [2 x [2 x i32]], align 4
smithp35 wrote:
Did you mean to change this file in this PR? I think this change h
https://github.com/smithp35 edited
https://github.com/llvm/llvm-project/pull/80255
___
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 response. LGTM.
I think the RISCV inline-asm-S-constraint.ll is no longer necessary thanks to
#80201
https://github.com/llvm/llvm-project/pull/80255
___
cfe-commits mailing list
c
smithp35 wrote:
Apologies I'll send a new pull request with the typo fixed. Probably the
fastest thing to do than trying to get my local branch back into the same state
to recreate the additional commit.
https://github.com/llvm/llvm-project/pull/80272
__
https://github.com/smithp35 closed
https://github.com/llvm/llvm-project/pull/80272
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
smithp35 wrote:
Apologies managed to mess up my branch when trying to fix the typo. I'll try
and fix.
https://github.com/llvm/llvm-project/pull/80272
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listin
smithp35 wrote:
Just to make sure I've understood:
* x86_64's support for constraint "s" was hoisted into the target independent
TargetLowering in https://reviews.llvm.org/D61560
* Clang's implementation of constraint "s" isn't restricted to non-PIC/non-PIE
like GCC's
* We can implement constr
https://github.com/smithp35 approved this pull request.
Code changes LGTM too. I can't think of a case when a C/C++ compiler would
directly generate a reference to an SHN_ABS symbol as I don't think there is a
way of expressing such a symbol in C/C++ and debug generation concentrates on
descri
Stefan =?utf-8?q?Gränitz?= ,
Stefan =?utf-8?q?Gränitz?= ,
Stefan =?utf-8?q?Gränitz?=
Message-ID:
In-Reply-To:
smithp35 wrote:
> Thanks for your notes @smithp35. This worked out nicely! A test for Thumb B
> to Arm interworking is todo, because we need support for `R_ARM_THM_JUMP11`
> first. I
@@ -316,9 +308,25 @@ class Symbol {
// This field is a index to the symbol's version definition.
uint16_t verdefIndex;
- // Version definition index.
- uint16_t versionId;
+ // Used by a Defined symbol with protected or default visibility, to record
+ // the verdef ind
https://github.com/smithp35 edited
https://github.com/llvm/llvm-project/pull/71272
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/smithp35 commented:
I think it makes sense to reuse the field if we can save a flag. The potential
for someone to use the versionId as an index, or otherwise misuse it in the
future makes me a bit nervous.
A possible alternative is to use a different name for the versionId,
https://github.com/smithp35 commented:
I'm happy with this on the AArch64 side.
If clang for a target defaults to position independent code this may lead to
some -mcmodel=large projects failing to build, at least until they add -fno-pic
Could we add this to the release notes? Perhaps in the f
@@ -770,6 +770,9 @@ void AArch64::relocateAlloc(InputSectionBase &sec, uint8_t
*buf) const {
uint64_t secAddr = sec.getOutputSection()->addr;
if (auto *s = dyn_cast(&sec))
secAddr += s->outSecOff;
+ else if (auto *eh = dyn_cast(&sec))
smithp35 wrote:
https://github.com/smithp35 commented:
This will only fix the problem for AArch64, but it also affects other targets.
Assuming relocateAlloc is the best place to fix this, then it would need
applying in all instances of relocateAlloc.
https://github.com/llvm/llvm-project/pull/65966
___
https://github.com/smithp35 edited
https://github.com/llvm/llvm-project/pull/65966
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
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
Author: Peter Smith
Date: 2020-08-06T13:47:21+01:00
New Revision: 839d974ee0e45f09b9665b4eed734ca1ba174d25
URL:
https://github.com/llvm/llvm-project/commit/839d974ee0e45f09b9665b4eed734ca1ba174d25
DIFF:
https://github.com/llvm/llvm-project/commit/839d974ee0e45f09b9665b4eed734ca1ba174d25.diff
L
Author: KAWASHIMA Takahiro
Date: 2020-01-13T10:16:53Z
New Revision: 10c11e4e2d05cf0e8f8251f50d84ce77eb1e9b8d
URL:
https://github.com/llvm/llvm-project/commit/10c11e4e2d05cf0e8f8251f50d84ce77eb1e9b8d
DIFF:
https://github.com/llvm/llvm-project/commit/10c11e4e2d05cf0e8f8251f50d84ce77eb1e9b8d.diff
Hello Erich,
The test added in this commit is failing on the Arm and Hexagon
builders. I think that this is because the expected type "long" in the
warning text is "int" on these platforms (possibly other 32-bit host
platforms).
The raw output from an Arm machine is:
llvm-project/clang/test/SemaC
This commit, specifically the changes made to
CodeGenCXX/cxx2a-three-way-comparison.cpp, are failing on all the Arm
and AArch64 builders that run check-clang and some of the other
non-X86 builders as well like S390 and PPC.
It seems to be the // RUN: not %clang_cc1 -std=c++2a -emit-llvm %s -o
- -t
Author: psmith
Date: Mon Oct 22 03:40:52 2018
New Revision: 344890
URL: http://llvm.org/viewvc/llvm-project?rev=344890&view=rev
Log:
[ARM][AArch64] Add LLVM_FALLTHROUGH to silence warning [NFC]
A follow up to D52784 to add in LLVM_FALLTHROUGH where there is an
intentional fall through in a switch
1 - 100 of 119 matches
Mail list logo
