[clang] [llvm] [MC,llvm-readobj,yaml2obj] Support CREL relocation format (PR #91280)

@@ -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.

[clang] [llvm] [MC,llvm-readobj,yaml2obj] Support CREL relocation format (PR #91280)

@@ -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 ([[#]])

[clang] [llvm] [MC,llvm-readobj,yaml2obj] Support CREL relocation format (PR #91280)

@@ -3840,14 +3849,15 @@ void GNUELFDumper::printRelRelaReloc(const Relocation , template static void printRelocHeaderFields(formatted_raw_ostream , unsigned SType, - const typename ELFT::Ehdr ) { + const

[clang] [llvm] [MC,llvm-readobj,yaml2obj] Support CREL relocation format (PR #91280)

@@ -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

[clang] [llvm] [MC,llvm-readobj,yaml2obj] Support CREL relocation format (PR #91280)

@@ -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,

[clang] [llvm] [MC,llvm-readobj,yaml2obj] Support CREL relocation format (PR #91280)

@@ -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 +

[clang] [llvm] [MC,llvm-readobj,yaml2obj] Support CREL relocation format (PR #91280)

@@ -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

[clang] [llvm] [MC,llvm-readobj,yaml2obj] Support CREL relocation format (PR #91280)

@@ -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,

[clang] [llvm] [MC,llvm-readobj,yaml2obj] Support CREL relocation format (PR #91280)

@@ -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

[clang] [llvm] [MC,llvm-readobj,yaml2obj] Support CREL relocation format (PR #91280)

@@ -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

[clang] [llvm] [MC,llvm-readobj,yaml2obj] Support CREL relocation format (PR #91280)

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

[clang] [llvm] [MC,llvm-readobj,yaml2obj] Support CREL relocation format (PR #91280)

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.

[clang] [llvm] [MC] Remove UseAssemblerInfoForParsing (PR #91082)

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

[clang] [llvm] [MC,llvm-readobj,yaml2obj] Support CREL relocation format (PR #91280)

@@ -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 ==

[clang] [llvm] [MC,llvm-readobj,yaml2obj] Support CREL relocation format (PR #91280)

@@ -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

[clang] [llvm] [MC,llvm-readobj,yaml2obj] Support CREL relocation format (PR #91280)

@@ -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

[clang] [llvm] [MC,llvm-readobj,yaml2obj] Support CREL relocation format (PR #91280)

@@ -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

[clang] [llvm] [MC,llvm-readobj,yaml2obj] Support CREL relocation format (PR #91280)

@@ -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

[clang] [llvm] [MC,llvm-readobj,yaml2obj] Support CREL relocation format (PR #91280)

@@ -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

[clang] [llvm] [MC,llvm-readobj,yaml2obj] Support CREL relocation format (PR #91280)

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

[clang] [llvm] [MC,llvm-readobj,yaml2obj] Support CREL relocation format (PR #91280)

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 &

[clang] [llvm] [MC,llvm-readobj,yaml2obj] Support CREL relocation format (PR #91280)

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.

[clang] [Clang] Pass -fseparate-named-sections from the driver (PR #91567)

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

[clang] [llvm] [MC,clang,llvm-readobj,yaml2obj] Support CREL relocation format (PR #91280)

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

[clang] [llvm] [MC] Remove UseAssemblerInfoForParsing (PR #91082)

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

[clang] [llvm] [MC] Remove UseAssemblerInfoForParsing (PR #91082)

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

[clang] [llvm] [Clang] -fseparate-named-sections option (PR #91028)

@@ -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

[clang] [llvm] [Clang] -fseparate-named-sections option (PR #91028)

@@ -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

[clang] [llvm] [Clang] -fseparate-named-sections option (PR #91028)

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

[clang] [llvm] [Clang] -fseparate-named-sections option (PR #91028)

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

[clang] [llvm] [arm] Support reserving r4 and r5 alongside r9 (PR #89849)

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

[clang] [llvm] [ARM] Armv8-R does not require fp64 or neon. (PR #88287)

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

[clang] [llvm] [ARM] Armv8-R does not require fp64 or neon. (PR #88287)

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.

[clang] [llvm] [ARM] Armv8-R does not require fp64 or neon. (PR #88287)

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) *

[clang] [Driver] Don't default to -mrelax-all for non-RISCV -O0 (PR #90013)

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

[clang] [Driver,AArch64] Remove AArch32-specific -m[no-]unaligned-access (PR #85441)

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 > >

[clang] [Driver,AArch64] Remove AArch32-specific -m[no-]unaligned-access (PR #85441)

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

[clang] [Driver] Don't alias -mstrict-align to -mno-unaligned-access (PR #85350)

@@ -321,9 +321,11 @@ void aarch64::getAArch64TargetFeatures(const Driver , } } - if (Arg *A = Args.getLastArg(options::OPT_mno_unaligned_access, - options::OPT_munaligned_access)) { -if

[clang] [clang][driver] Allow unaligned access on ARMv7 and higher by default (PR #82400)

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.

[clang] [clang][driver] Allow unaligned access on ARMv7 and higher by default (PR #82400)

@@ -895,20 +895,18 @@ llvm::ARM::FPUKind arm::getARMTargetFeatures(const Driver , // 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

[llvm] [clang] [AArch64] Support optional constant offset for constraint "S" (PR #80255)

@@ -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

[llvm] [clang] [AArch64] Support optional constant offset for constraint "S" (PR #80255)

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

[llvm] [clang] [AArch64] Support optional constant offset for constraint "S" (PR #80255)

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

[lldb] [openmp] [libcxx] [mlir] [clang] [libc] [llvm] [flang] Add security group 2023 transparency report. (PR #80272)

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

[lldb] [openmp] [libcxx] [mlir] [clang] [libc] [llvm] [flang] Add security group 2023 transparency report. (PR #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

[clang] [flang] [llvm] [libc] [openmp] [lldb] [mlir] [libcxx] Add security group 2023 transparency report. (PR #80272)

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

[llvm] [clang] [AArch64] Support optional constant offset for constraint "S" (PR #80255)

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

[libcxx] [mlir] [openmp] [pstl] [clang-tools-extra] [llvm] [lld] [lldb] [clang] [ELF] Don't resolve relocations referencing SHN_ABS to tombstone in non-SHF_ALLOC sections (PR #79238)

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

[llvm] [clang] [JITLink][AArch32] Implement Armv5 ldr-pc stubs and use them for all pre-v7 targets (PR #79082)

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.

[clang] [mlir] [lld] [llvm] [flang] [ELF] Merge exportDynamic into versionId (PR #71272)

@@ -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

[flang] [lld] [mlir] [llvm] [clang] [ELF] Merge exportDynamic into versionId (PR #71272)

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

[llvm] [flang] [mlir] [lld] [clang] [ELF] Merge exportDynamic into versionId (PR #71272)

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,

[clang] [Driver] Reject unsupported -mcmodel= (PR #70262)

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

[clang] [LLD][AARCH64] lld incorrectly handles .eh_frame when it has a non-zero offset within its output section. (PR #65966)

@@ -770,6 +770,9 @@ void AArch64::relocateAlloc(InputSectionBase , uint8_t *buf) const { uint64_t secAddr = sec.getOutputSection()->addr; if (auto *s = dyn_cast()) secAddr += s->outSecOff; + else if (auto *eh = dyn_cast()) smithp35 wrote: I don't

[clang] [LLD][AARCH64] lld incorrectly handles .eh_frame when it has a non-zero offset within its output section. (PR #65966)

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

[clang] [LLD][AARCH64] lld incorrectly handles .eh_frame when it has a non-zero offset within its output section. (PR #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

[clang] 5e71839 - [MC] Add MCSubtargetInfo to MCAlignFragment

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

[clang] 839d974 - [DOCS] Add more detail to stack protector documentation

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

[clang] 10c11e4 - This option allows selecting the TLS size in the local exec TLS model,

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

Re: r351495 - Make integral-o-pointer conversions in SFINAE illegal.

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:

Re: r345330 - Add MS ABI mangling for operator<=>.

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 -

r344890 - [ARM][AArch64] Add LLVM_FALLTHROUGH to silence warning [NFC]

Author: psmith Date: Mon Oct 22 03:40:52 2018 New Revision: 344890 URL: http://llvm.org/viewvc/llvm-project?rev=344890=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

r344597 - [ARM][AArch64] Pass through endian flags to assembler and linker.

Author: psmith Date: Tue Oct 16 02:21:17 2018 New Revision: 344597 URL: http://llvm.org/viewvc/llvm-project?rev=344597=rev Log: [ARM][AArch64] Pass through endian flags to assembler and linker. The big-endian arm32 Linux builds are currently failing when the -mbig-endian flag is used but the

r343304 - [ARM] Alter test to account for change to armv6k default CPU

Author: psmith Date: Fri Sep 28 02:04:31 2018 New Revision: 343304 URL: http://llvm.org/viewvc/llvm-project?rev=343304=rev Log: [ARM] Alter test to account for change to armv6k default CPU Review D52594 will change the default in llvm for armv6k from the non-existent cpu arm1176jf-s to mpcore.

r341312 - [Aarch64] Fix linker emulation for Aarch64 big endian

Author: psmith Date: Mon Sep 3 05:36:32 2018 New Revision: 341312 URL: http://llvm.org/viewvc/llvm-project?rev=341312=rev Log: [Aarch64] Fix linker emulation for Aarch64 big endian This patch fixes target linker emulation for aarch64 big endian. aarch64_be_linux is not recognized by gnu ld. The

r332606 - [AArch64] Correct inline assembly test case for S modifier [NFC]

Author: psmith Date: Thu May 17 06:17:33 2018 New Revision: 332606 URL: http://llvm.org/viewvc/llvm-project?rev=332606=rev Log: [AArch64] Correct inline assembly test case for S modifier [NFC] The existing test for the AArch64 inline assembly constraint S uses the A and L modifiers. These

r318648 - [ARM] For assembler files recognize -Xassembler or -Wa, -mthumb

Author: psmith Date: Mon Nov 20 05:53:55 2017 New Revision: 318648 URL: http://llvm.org/viewvc/llvm-project?rev=318648=rev Log: [ARM] For assembler files recognize -Xassembler or -Wa, -mthumb Attempt to fix warning picked up by buildbot. Modified: cfe/trunk/lib/Driver/ToolChains/Clang.cpp

r318647 - [ARM] For assembler files recognize -Xassembler or -Wa, -mthumb

Author: psmith Date: Mon Nov 20 05:43:55 2017 New Revision: 318647 URL: http://llvm.org/viewvc/llvm-project?rev=318647=rev Log: [ARM] For assembler files recognize -Xassembler or -Wa, -mthumb The Unified Arm Assembler Language is designed so that the majority of assembler files can be assembled

[libunwind] r316657 - [libunwind] Always use unwind tables in tests

Author: psmith Date: Thu Oct 26 05:02:03 2017 New Revision: 316657 URL: http://llvm.org/viewvc/llvm-project?rev=316657=rev Log: [libunwind] Always use unwind tables in tests For many targets setting -fno-exceptions will prevent unwinding tables from being generated for the test programs. As

r316424 - [AArch64] Fix PR34625 -mtune without -mcpu should not set -target-cpu

Author: psmith Date: Tue Oct 24 02:51:55 2017 New Revision: 316424 URL: http://llvm.org/viewvc/llvm-project?rev=316424=rev Log: [AArch64] Fix PR34625 -mtune without -mcpu should not set -target-cpu When -mtune is used on AArch64 the -target-cpu is passed the value of the cpu given to -mtune. As

r309263 - [CodeGen][ARM] ARM runtime helper functions are not always soft-fp

Author: psmith Date: Thu Jul 27 03:43:53 2017 New Revision: 309263 URL: http://llvm.org/viewvc/llvm-project?rev=309263=rev Log: [CodeGen][ARM] ARM runtime helper functions are not always soft-fp Re-commit r309257 with less precise register checks in arm-float-helpers.c test. Added:

r309259 - [CodeGen][ARM] Revert r309257

Author: psmith Date: Thu Jul 27 02:57:13 2017 New Revision: 309259 URL: http://llvm.org/viewvc/llvm-project?rev=309259=rev Log: [CodeGen][ARM] Revert r309257 The test arm-float-helpers.c appears to be failing on some builders and needs some work to make it more robust. Removed:

r309257 - [CodeGen][ARM] ARM runtime helper functions are not always soft-fp

Author: psmith Date: Thu Jul 27 02:21:41 2017 New Revision: 309257 URL: http://llvm.org/viewvc/llvm-project?rev=309257=rev Log: [CodeGen][ARM] ARM runtime helper functions are not always soft-fp The ARM Runtime ABI document (IHI0043) defines the AEABI floating point helper functions in 4.1.2 The

[clang-tools-extra] r306385 - [NFC] Update to account for DiagnosticRenderer use of FullSourceLoc

Author: psmith Date: Tue Jun 27 03:04:04 2017 New Revision: 306385 URL: http://llvm.org/viewvc/llvm-project?rev=306385=rev Log: [NFC] Update to account for DiagnosticRenderer use of FullSourceLoc D31709 [NFC] Refactor DiagnosticRenderer to use FullSourceLoc was committed in r305684 and reverted

Re: [gentoo-musl] Re: Add support for musl-libc on Linux

Hello Lei, They look good enough for me. Unless anyone else has any objections I think you are good to go. Peter On 24 June 2016 at 04:25, Lei Zhang wrote: > 2016-06-22 16:55 GMT+08:00 Peter Smith : >> Hello Lei, >> >> Thanks for all the

Re: [gentoo-musl] Re: Add support for musl-libc on Linux

Hello Lei, Thanks for all the updates. That looks good to me from an ARM perspective. Peter On 22 June 2016 at 09:03, Lei Zhang wrote: > 2016-06-21 23:07 GMT+08:00 Peter Smith : >> Hello Lei, >> >> The changes to llvm and clang look ok to me.

Re: [gentoo-musl] Re: Add support for musl-libc on Linux

Hello Lei, The changes to llvm and clang look ok to me. I've got some suggestions for testing. For the clang patch, it looks like there isn't a test to check that musleabihf implies hard floating point. It looks like Driver/arm-mfpu.c CHECK-HF might be a good candidate to add a test. For the

Re: [gentoo-musl] Re: Add support for musl-libc on Linux

From what I can see, the EABI type is used to decide if certain __aeabi_ prefixed functions such as __aeabi_idiv are available. If Musl differs in function availability from the GNU library here I think you'll need a Musl EABI type. However if there is no difference you should be able to use the

Re: [gentoo-musl] Re: Add support for musl-libc on Linux

Hello Lei, I agree with Rafael that this is currently missing a few critical things right now, especially in the llvm patch. My (limited) understanding of musl is that it intends to support the same interface as GNUEABI and GNUEABIHF, but it is obviously a different implementation. This is what

Re: [PATCH] D21022: [ARM] Fix linker emulation for arm 32 big endian

peter.smith accepted this revision. peter.smith added a comment. This revision is now accepted and ready to land. I think the change looks fine and it looks small enough for me to approve. http://reviews.llvm.org/D21022 ___ cfe-commits mailing list

Re: [PATCH] D21022: [ARM] Fix linker emulation for arm 32 big endian

peter.smith added a comment. That looks correct to me. Certainly armebelf_linux_eabi is not recognised on a recent ld. Comment at: lib/Driver/Tools.cpp:9098 @@ -9097,3 +9097,3 @@ case llvm::Triple::thumbeb: -return "armebelf_linux_eabi"; /* TODO: check which NAME. */ +