[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. */ +