[clang] [llvm] [PAC][Driver] Support `pauthtest` ABI for AArch64 Linux triples (PR #97237)
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 pauthtest is not a stable signing schema to be used in production, and if there ended up being a stable upstream linux signing schema -mabi=pauth (probably) then pauthtest could be removed. 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
[clang] [llvm] [PAC][clang][Driver] Add signed GOT flag (PR #96160)
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 clang.
I know that there are existing command-line options for other signing schema
affecting options, but I'm not sure if we want to add more to them.
https://github.com/llvm/llvm-project/pull/96160
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [PAC][Driver] Support `pauthtest` ABI for AArch64 Linux triples (PR #97237)
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 to stick with what has been tested so far. Not had a chance to go through the tests in detail yet. Will aim to do that before the end of the week. 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
[clang] [llvm] [PAC][Driver] Support `pauthtest` ABI for AArch64 Linux triples (PR #97237)
@@ -1546,16 +1581,28 @@ static void CollectARMPACBTIOptions(const ToolChain
, const ArgList ,
CmdArgs.push_back(
Args.MakeArgString(Twine("-msign-return-address=") + Scope));
- if (Scope != "none")
+ if (Scope != "none") {
+if (Triple.getEnvironment() == llvm::Triple::PAuthTest)
+ D.Diag(diag::err_drv_unsupported_opt_for_target)
+ << A->getAsString(Args) << Triple.getTriple();
CmdArgs.push_back(
Args.MakeArgString(Twine("-msign-return-address-key=") + Key));
- if (BranchProtectionPAuthLR)
+ }
+ if (BranchProtectionPAuthLR) {
+if (Triple.getEnvironment() == llvm::Triple::PAuthTest)
+ D.Diag(diag::err_drv_unsupported_opt_for_target)
+ << A->getAsString(Args) << Triple.getTriple();
CmdArgs.push_back(
Args.MakeArgString(Twine("-mbranch-protection-pauth-lr")));
+ }
if (IndirectBranches)
CmdArgs.push_back("-mbranch-target-enforce");
- if (GuardedControlStack)
+ if (GuardedControlStack) {
smithp35 wrote:
I think GuardedControlStack should be compatible with PAuthABI but there won't
be hardware available for some time so we could retrospectively support it
later after testing it.
Perhaps worth a comment that GCS is untested with PAuthABI, but could be
enabled after testing with a suitable system.
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
[clang] [llvm] [PAC][Driver] Support `pauthtest` ABI for AArch64 Linux triples (PR #97237)
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
[clang] [Clang][Driver] Skip empty strings in getAArch64MultilibFlags (PR #97827)
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 with C++20 ``` but this doesn't seem to have an individual warning. Did you mean to use `-Wc++20-compat`? 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
[clang] [llvm] [PAC][Driver] Implement `-mbranch-protection=pauthabi` option (PR #97237)
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 the options we discussed. My apologies if I've misrepresented or missed out anything in the call. Please feel free to correct me where I'm wrong or have missed something out. I'll be at a conference this week so I may be slow to respond. Known use cases and background. We have three known use cases for PAuthABI, with two in active development: * A platform either ELF or MachO based deploys PAuthABI in all or, most likely, a subset of programs. * A bare-metal system that can statically compile everything the same way for the device. This not in active development. * Enabling PAuthABI for testing in upstream LLVM. On each of the platforms, there is expected to be more than onesigning schema, for example kernel vs user-space. With the possible exception of return address signing, each signing schema is its own ABI. While low-level options may exist to control the signing schema, we do not expect end users to use them as they risk breaking the platform ABI. This infers that we need an option to choose between high-level signing schemas, that map to some combination of the low-level options. This mapping will need to be per-platform as Linux may choose differently to BSD. The signing schema will also need to be used as the multilib key so that a compatible set of libraries can be linked for the signing schema. On ELF the (platform, signing-schema) choice can be recorded in the ELF properties. Users of the low-level command line options cannot be easily recorded in the ELF properties. There are various platform specific choices that could be made if the low-level options are used. For example: * Record the high-level signing schema and trust the user has written the code such that it is compatible. * Reject the low-level option. * Ignore the low-level option. * Record a custom signing schema. I think that this has to be under control of the platform. My intuition is that we trust the user, perhaps with a warning, and record the high-level signing schema. On a bare-metal embedded system each toolchain can make up their own signing schema, however no toolchain is likely to provide pre-compiled libraries for every possible choice so we expect there to be a sensible default signing schema. Thoughts on `-mbranch-protection=pauthabi` While pauthabi is a form of CFI like the other mbranch-protection options there are a number of differences that cause problems: * All existing `-mbranch-protection` options have a hint space implementation so are compatible with any architecture. PAuthABI requires an extension. * All existing `-mbranch-protection` options are compatible, pauthabi conflicts with standard and pac-ret. * All existing `-mbranch-protection` options are ABI neutral, pauthabi is not and any use of it on a standard linux platform would not work. * Not got an easy way to extend with the signing schema. ### Alternatives discussed A single option using -mabi: Use the existing `-mabi` option to indicate the signing schema (or absence of signing schema) if pauthabi is not used. The `-mabi` option for AArch64 is currently permits `aapcs` (default hard-float) `aapcs-soft` and `darwinpcs`. `-mabi=pauth` // default signing schema for the platform (OS in triple). `-mabi=pauth` // named signing schema, interpreted per platform. The expands to a number of low-level options. This is determined per platform. With this information we can derive a for the ELF marking. For example: * `--target=aarch64-none-elf -mabi=pauth` * `--target=aarch64-linux-gnu -mabi=pauthkernel` There is an open question over what we should do with the theoretical combination of soft-floating point and pauth as these both use the `-mabi=` option. While each combination is its own ABI, the choice of float-abi is orthogonal to signing schema. I'm leaning towards suggesting a + or , separated list for `-mabi` with a default of aapcs (hard-float) so we don't end up doubling the number of options. So we would have `-mabi=pauth,aapcs-soft` rather than `-mabi=aapcs-soft-pauth`. I don't think that would need to be implemented until there is an actual need for it. Two options using -mabi and -msigning-schema: This is functionally equivalent to the single `-mabi=pauth` split into two options. * `-mabi=pauth enables pauthabi` * `-msigning-schema=` if `-msigning-schema` is absent then the default signing schema for the platform is used. This has the advantage of being easier to parse, but has a couple of drawbacks: * Each `-msigning-schema` is a different ABI so it is logical to have a single `-mabi` option with disjoint choices. * `-msigning-schema` without `-mabi=pauth` is meaningless. Use
[clang] [llvm] [PAC][Driver] Implement `-mbranch-protection=pauthabi` option (PR #97237)
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/listinfo/cfe-commits
[clang] [llvm] [PAC][Driver] Implement `-mbranch-protection=pauthabi` option (PR #97237)
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 respond. 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
[clang] [Clang][Driver] Skip empty strings in getAArch64MultilibFlags (PR #97827)
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-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang][Driver] Skip empty strings in getAArch64MultilibFlags (PR #97827)
@@ -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 need git blame to work it out otherwise. For example: ``` // rcpc3 implies rcpc-immo which does not have a user-visible name, check that an empty string is not produced. ``` 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
[clang] [Clang][Driver] Skip empty strings in getAArch64MultilibFlags (PR #97827)
@@ -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 as well. This test might unexpectedly pass if the ordering of the features were changed. 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
[clang] [Clang][Driver] Skip empty strings in getAArch64MultilibFlags (PR #97827)
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/llvm-project/pull/97827 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang][Driver] Skip empty strings in getAArch64MultilibFlags (PR #97827)
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
[clang] [Driver] Add -Wa, options --crel and --allow-experimental-crel (PR #97378)
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 https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [PAC][Driver] Implement `-mbranch-protection=pauthabi` option (PR #97237)
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
[clang] [llvm] [PAC][Driver] Implement `-mbranch-protection=pauthabi` option (PR #97237)
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 since that was posted. Some colleagues expressed some concern that as this was introducing a new ABI, while the existing -mbranch-protection options are ABI neutral [*], then perhaps a better option would be to use the `-mabi` option. For example `-mabi=pauthabi`. There are some advantages and disadvantages to doing that. It is explicit that there is a different ABI being used, however it is logically an extension of the CFI features in `-mbranch-protection` and some of the branch-protection modifiers such as `+ret` could be useful. Will be worth having some thoughts on how you would want to interact with existing mbranch-protection options. If pauthabi would supersede all the pointer authentication parts then it may be better to have a `-mabi` option? [*] Stack unwinding needs to be aware of signed return addresses, but these can be optional. 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
[clang] [llvm] [PAC][Driver] Implement `-mbranch-protection=pauthabi` option (PR #97237)
@@ -1537,11 +1570,16 @@ static void CollectARMPACBTIOptions(const ToolChain , const ArgList , if (!isAArch64 && PBP.Key == "b_key") D.Diag(diag::warn_unsupported_branch_protection) << "b-key" << A->getAsString(Args); +if (!isAArch64 && PBP.HasPauthABI) + D.Diag(diag::warn_unsupported_branch_protection) + << "pauthabi" << A->getAsString(Args); Scope = PBP.Scope; Key = PBP.Key; BranchProtectionPAuthLR = PBP.BranchProtectionPAuthLR; IndirectBranches = PBP.BranchTargetEnforcement; GuardedControlStack = PBP.GuardedControlStack; +if (isAArch64 && PBP.HasPauthABI) smithp35 wrote: Do we need any additional error checking for the existing branch protection options that affect pointer authentication? For example we have ``` pac-ret // return address signing with A key pac-ret+leaf // extend return address signing to leaf functions standard = pac-ret+bti+pc // enable pac-ret, bti and pc (if available on hardware). pc // Enable pc as modifier in return address signing. b-key // Use b-key for signing return address. ``` When pauthabi is used, are the other PAC related options ignored? I can see `+leaf` being potentially useful, as well as `+pc`. I think b-key is going to clash with the signing schema. The other options look to be subsets of pauthabi (unless additional command line options unless `-fno-ptrauth-returns` is used. 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
[clang] [llvm] [PAC][Driver] Implement `-mbranch-protection=pauthabi` option (PR #97237)
@@ -1484,6 +1484,39 @@ void AddUnalignedAccessWarning(ArgStringList ) {
}
}
+static void handlePAuthABIOption(const ArgList ,
smithp35 wrote:
I think it will be worth a comment above and possibly inline explaining the ABI
implications of the options.
For example:
```
Each combination of options here forms a signing schema, and in most cases each
signing schema is its own incompatible ABI. The default values of the options
represent the default signing schema.
```
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
[clang] [llvm] [PAC][Driver] Implement `-mbranch-protection=pauthabi` option (PR #97237)
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 from the triple to select a signing schema for a particular platform. I could also see a potential for a separate command line option to choose from documented named signing schemas. I don't think these need to implemented now, would be good to make sure that there are enough comments stating the ABI implications of making changes. 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
[clang] [llvm] [PAC][Driver] Implement `-mbranch-protection=pauthabi` option (PR #97237)
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
[clang] [Driver] Add -Wa, options --crel and --allow-experimental-crel (PR #97378)
@@ -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: %clang -### -c --target=x86_64 -Wa,--crel,--allow-experimental-crel %s -Werror 2>&1 | FileCheck %s +// RUN: %clang -### -c --target=x86_64 -Wa,--crel,--no-crel,--allow-experimental-crel %s -Werror 2>&1 | FileCheck %s --check-prefix=NO +// RUN: %clang -### -c --target=x86_64 -Wa,--allow-experimental-crel %s -Werror 2>&1 | FileCheck %s --check-prefix=NO +// RUN: not %clang -### -c --target=arm64-apple-darwin -Wa,--crel,--allow-experimental-crel %s 2>&1 | FileCheck %s --check-prefix=ERR +// RUN: not %clang -### -c --target=mips64 -Wa,--crel,--allow-experimental-crel %s 2>&1 | FileCheck %s --check-prefix=ERR + smithp35 wrote: Worth a test that crel isn't supported, for `--no-integrated-as` ? 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
[clang] [Driver] Add -Wa, options --crel and --allow-experimental-crel (PR #97378)
@@ -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 a non-standard section type code">; smithp35 wrote: Nit, I think "uses a non-standard section type code" would read better here. 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
[clang] [Driver] Add -Wa, options --crel and --allow-experimental-crel (PR #97378)
@@ -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: %clang -### -c --target=x86_64 -Wa,--crel,--allow-experimental-crel %s
-Werror 2>&1 | FileCheck %s
+// RUN: %clang -### -c --target=x86_64
-Wa,--crel,--no-crel,--allow-experimental-crel %s -Werror 2>&1 | FileCheck %s
--check-prefix=NO
+// RUN: %clang -### -c --target=x86_64 -Wa,--allow-experimental-crel %s
-Werror 2>&1 | FileCheck %s --check-prefix=NO
+// RUN: not %clang -### -c --target=arm64-apple-darwin
-Wa,--crel,--allow-experimental-crel %s 2>&1 | FileCheck %s --check-prefix=ERR
+// RUN: not %clang -### -c --target=mips64
-Wa,--crel,--allow-experimental-crel %s 2>&1 | FileCheck %s --check-prefix=ERR
+
+// RUN: %clang -### -c --target=aarch64 -Werror
-Wa,--crel,--allow-experimental-crel -x assembler %s -Werror 2>&1 | FileCheck
%s --check-prefix=ASM
+// RUN: not %clang -### -c --target=mips64
-Wa,--crel,--allow-experimental-crel -x assembler %s 2>&1 | FileCheck %s
--check-prefix=ERR
+
+// CHECK: "-cc1" {{.*}}"--crel"
+// NO: "-cc1"
+// NO-NOT: "--crel"
+// ASM: "-cc1as" {{.*}}"--crel"
+// ERR: error: unsupported option '-Wa,--crel' for target '{{.*}}'
+
+/// Don't bother with --allow-experimental-crel for LTO.
smithp35 wrote:
I think it would be better to say
/// --allow-experimental-crel is not required for LTO.
Could be worth mentioning that in the description.
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
[clang] [Driver] Add -Wa, options --crel and --allow-experimental-crel (PR #97378)
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
[clang] [Driver] Add -Wa, options --crel and --allow-experimental-crel (PR #97378)
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-commits
[clang] [llvm] [MC,llvm-readobj,yaml2obj] Support CREL relocation format (PR #91280)
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
[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.
Unless I've misunderstood I note that writeULEB128 above uses sizeof(uint64_t)
which may be a little too low.
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)
@@ -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 ([[#]]) .crel.text {
+# LLVM-NEXT: 0x1 R_X86_64_32 g1 0x1
+# LLVM-NEXT: 0x2 R_X86_64_64 l1 0x2
+# LLVM-NEXT: 0x0 R_X86_64_32S g1 0x
+# LLVM-NEXT: 0x4 R_X86_64_32S .text 0x8000
+# LLVM-NEXT: }
+# LLVM-NEXT: Section ([[#]]) .crelnonalloc {
+# LLVM-NEXT: 0x10 R_X86_64_64 g1 0x1
+# LLVM-NEXT: 0x20 R_X86_64_64 g2 0x2
+# LLVM-NEXT: }
+# LLVM-NEXT: ]
+
+# GNU: Relocation section '.crel.text' at offset 0x48 contains 4 entries:
+# GNU-NEXT: Offset Info Type
Symbol's Value Symbol's Name + Addend
+# GNU-NEXT: 0001 0003000a R_X86_64_32
g1 + 1
+# GNU-NEXT: 0002 00020001 R_X86_64_64
l1 + 2
+# GNU-NEXT: 0003000b R_X86_64_32S
g1 - 1
+# GNU-NEXT: 0004 0001000b R_X86_64_32S
.text - 8000
+# GNU-EMPTY:
+# GNU-NEXT: Relocation section '.crelnonalloc' at offset 0xa2 contains 2
entries:
+# GNU-NEXT: Offset Info Type
Symbol's Value Symbol's Name + Addend
+# GNU-NEXT: 0010 00030001 R_X86_64_64
g1 + 1
+# GNU-NEXT: 0020 00040001 R_X86_64_64
g2 + 2
+
+--- !ELF
+FileHeader: !FileHeader
+ Class: ELFCLASS64
+ Data: ELFDATA2LSB
+ Type: ET_REL
+ Machine: EM_X86_64
+
+Sections:
+- Name: .text
+ Type: SHT_PROGBITS
+ Content: ""
+ Flags: [SHF_ALLOC]
+- Name: .crel.text
+ Type: SHT_CREL
+ Info: .text
+ Link: .symtab
+ Relocations:
+- Offset: 0x1
+ Symbol: g1
+ Type: R_X86_64_32
+ Addend: 1
+- Offset: 0x2
+ Symbol: l1
+ Type: R_X86_64_64
+ Addend: 2
+- Offset: 0x0
+ Symbol: g1
+ Type: R_X86_64_32S
+ Addend: 0x
+- Offset: 0x4
+ Symbol: .text
+ Type: R_X86_64_32S
+ Addend: 0x8000
+- Name: nonalloc
+ Type: SHT_PROGBITS
+ Size: 0x30
+- Name: .crelnonalloc
+ Type: SHT_CREL
+ Info: nonalloc
+ Link: .symtab
+ Relocations:
+- Offset: 0x10
+ Symbol: g1
+ Type: R_X86_64_64
+ Addend: 1
+- Offset: 0x20
+ Symbol: g2
+ Type: R_X86_64_64
+ Addend: 2
+
+Symbols:
+ - Name: .text
+Type: STT_SECTION
+Section: .text
+ - Name:l1
+ - Name:g1
+Section: .text
+Value: 0x0
+Size:4
+Binding: STB_GLOBAL
+ - Name:g2
+Binding: STB_GLOBAL
+
+## Check relocation formatting on ELFCLASS32 as well.
smithp35 wrote:
It would be good to have a test for a target that doesn't have addends here
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
[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 typename ELFT::Ehdr ,
+ uint64_t CrelHdr = 0) {
bool IsRela = SType == ELF::SHT_RELA || SType == ELF::SHT_ANDROID_RELA;
if (ELFT::Is64Bits)
OS << "Offset Info Type Symbol's
"
"Value Symbol's Name";
else
OS << " Offset InfoTypeSym. Value Symbol's Name";
- if (IsRela)
+ if (IsRela || (SType == ELF::SHT_CREL && (CrelHdr & 4)))
smithp35 wrote:
I think some human readable masks may be worthwhile. For example `CrelHdr &
hasAddend`
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)
@@ -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 testing a target that uses REL relocations by default? For example 32-bit Arm is REL. Or have I misunderstood and when CREL is used a target can choose rel or rela. 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)
@@ -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;
+ uint32_t Symidx = 0, Type = 0;
+ uint64_t CurrentOffset = CBA.getOffset();
+ if (IsCrel)
+for (const ELFYAML::Relocation : *Section.Relocations)
+ OffsetMask |= Rel.Offset;
+ const int Shift = llvm::countr_zero(OffsetMask);
+ if (IsCrel)
+CBA.writeULEB128(Section.Relocations->size() * 8 + 4 + Shift);
for (const ELFYAML::Relocation : *Section.Relocations) {
const bool IsDynamic = Section.Link && (*Section.Link == ".dynsym");
-unsigned SymIdx =
+uint32_t CurSymidx =
Rel.Symbol ? toSymbolIndex(*Rel.Symbol, Section.Name, IsDynamic) : 0;
-if (IsRela) {
+if (IsCrel) {
smithp35 wrote:
Could it be worth abstracting out some of the calculations into inline
functions that could be called from both here and `ElfObjectWriter.cpp`?
I'm on the fence about this myself as while it would help with consistency
between the two implementations, and potentially any additional implementation
of the algorithm the pieces of the algorithm that can be extracted is small.
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)
@@ -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 + smithp35 wrote: While we are using a section type in the [LOOS, HIOS) range, is it worth using a dynamic tag in the [LOOS, HIOS) range. As an aside, would a tag containing the number of CRELs (NCREL for example). This in theory could be used to pre-allocate memory for an expanded CRELs. I don't think it is worth doing unless there is a clear need though. I could imagine most dynamic linkers iterating through the LEB directly. Although not strictly necessary a CREL Size (CRELSZ?) could be useful for a consumer to read all the CRELs into memory without having to read the header first to find the size. Again not worth doing unless we have a definite need for it. 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)
@@ -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_NONE foo
-# LLVM-RELOCS-NEXT: 0x4 R_X86_64_RELATIVE
+# LLVM-RELOCS-NEXT: 0x4 R_X86_64_RELATIVE -
smithp35 wrote:
Is that trailing `-` intentional?
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)
@@ -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; + uint32_t Symidx = 0, Type = 0; + uint64_t CurrentOffset = CBA.getOffset(); + if (IsCrel) smithp35 wrote: Looking at the implementation of `encodeCrel` in ELFObjectWriter.cpp the algorithm used is the same, but there are some comment differences that could apply to both. I think it would be helpful to use the same comments in both implementations. For example at this point there is: ``` // The delta offset and flags member may be larger than uint64_t. Special // case the first byte (3 flag bits and 4 offset bits). Other ULEB128 bytes // encode the remaining delta offset bits. ``` 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)
@@ -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 aarch64-registered-target %{ llvm-readelf -r %t.be.o | FileCheck %s
--check-prefix=A64BE %}
+
+# CHECK: [ 4] .data PROGBITS {{.*}}
08 00 WA 0 0 1
+# CHECK-NEXT: [ 5] .crel.dataCREL {{.*}}
2a 01 I 14 4 1
+# CHECK-NEXT: [ 6] .rodata PROGBITS {{.*}}
2b 00 A 0 0 1
+# CHECK-NEXT: [ 7] .crel.rodata CREL {{.*}}
10 01 I 14 6 1
+# CHECK-NEXT: [ 8] rodata2 PROGBITS {{.*}}
08 00 A 0 0 1
+# CHECK-NEXT: [ 9] .crelrodata2 CREL {{.*}}
05 01 I 14 8 1
+# CHECK-NEXT: [10] rodata16 PROGBITS {{.*}}
10 00 A 0 0 1
+# CHECK-NEXT: [11] .crelrodata16 CREL {{.*}}
04 01 I 14 10 1
+# CHECK-NEXT: [12] noalloc PROGBITS {{.*}}
04 00 0 0 1
+# CHECK-NEXT: [13] .crelnoalloc CREL {{.*}}
05 01 I 14 12 1
+# CHECK-NEXT: [14] .symtab SYMTAB
+
+# CHECK: Relocation section '.crel.data' at offset {{.*}} contains 7
entries:
+# CHECK-NEXT: Offset Info Type
Symbol's Value Symbol's Name + Addend
+# CHECK-NEXT: {{.*}} R_X86_64_NONE
a0 + 0
+# CHECK-NEXT: 0001 {{.*}} R_X86_64_NONE
a1 - 1
+# CHECK-NEXT: 0002 {{.*}} R_X86_64_NONE
a2 - 1
+# CHECK-NEXT: 0003 {{.*}} R_X86_64_32
a3 + 4000
+# CHECK-NEXT: 0004 {{.*}} R_X86_64_64
a0 - 8000
+# CHECK-NEXT: 0005 {{.*}} R_X86_64_64
a1 + 7fff
+# CHECK-NEXT: 0005 {{.*}} R_X86_64_32
a1 - 1
+# CHECK-EMPTY:
+# CHECK-NEXT: Relocation section '.crel.rodata' at offset {{.*}} contains 4
entries:
+# CHECK-NEXT: Offset Info Type
Symbol's Value Symbol's Name + Addend
+# CHECK-NEXT: {{.*}} R_X86_64_PC32
foo + 0
+# CHECK-NEXT: 000f {{.*}} R_X86_64_PC32
foo + 3f
+# CHECK-NEXT: 001f {{.*}} R_X86_64_PC64
foo + 7f
+# CHECK-NEXT: 0027 {{.*}} R_X86_64_PC32
_start - 1f81
+# CHECK-EMPTY:
+# CHECK-NEXT: Relocation section '.crelrodata2' at offset {{.*}} contains 2
entries:
+# CHECK-NEXT: Offset Info Type
Symbol's Value Symbol's Name + Addend
+# CHECK-NEXT: 0002 {{.*}} R_X86_64_32
.data + 0
+# CHECK-NEXT: 0008 {{.*}} R_X86_64_32
.data + 0
+# CHECK-EMPTY:
+# CHECK-NEXT: Relocation section '.crelrodata16' at offset {{.*}} contains 1
entries:
+# CHECK-NEXT: Offset Info Type
Symbol's Value Symbol's Name + Addend
+# CHECK-NEXT: 0008 {{.*}} R_X86_64_64
rodata16 + 0
+# CHECK-EMPTY:
+# CHECK-NEXT: Relocation section '.crelnoalloc' at offset {{.*}} contains 1
entries:
+# CHECK-NEXT: Offset Info Type
Symbol's Value Symbol's Name + Addend
+# CHECK-NEXT: {{.*}} R_X86_64_32
.text + 4
+
+## count * 8 + 4 + shift = 2*8+4+1 = 21
+# CHECK: Hex dump of section '.crelrodata2':
+# CHECK-NEXT: 0x 150b020a 18 .
+## count * 8 + 4 + shift = 1*8+4+3 = 15
+# CHECK: Hex dump of section '.crelrodata16':
+# CHECK-NEXT: 0x 0f0b0301 .
+
+# A64BE: {{.*}} R_AARCH64_NONE
a0 + 0
+# A64BE-NEXT: 0001 {{.*}} R_AARCH64_NONE
a1 - 1
+# A64BE-NEXT: 0002 {{.*}} R_AARCH64_NONE
a2 - 1
+# A64BE-NEXT: 0003 {{.*}} R_AARCH64_ABS32
a3 + 4000
+# A64BE-NEXT: 0004 {{.*}} R_AARCH64_ABS64
a0 - 8000
+# A64BE-NEXT: 0005 {{.*}} R_AARCH64_ABS64
a1 + 7fff
+# A64BE-NEXT: 0005 {{.*}}
[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 = 0, Type = 0;
+ // hdr & 4 indicates 3 flag bits in delta offset and flags members.
+ for (unsigned i = 0, e = Relocs.size(); i != e; ++i)
smithp35 wrote:
Given that Relocs.size() returns size_t would it be better to use size_t here?
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 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. 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] 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[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 == ELF::SHT_CREL) {
smithp35 wrote:
Is there scope for a forwards iterator that decodes a CREL when dereferenced or
incremented. That could be used in a thread-safe environment and wouldn't take
up a lot of memory.
May need to be under a different interface.
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)
@@ -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 getRelocatedSection() will need to be called first.
It looks like all the existing use cases here are safe, but if this is part of
the general API then maybe worth some additional asserts and pre-conditions
given in comments.
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)
@@ -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 the parameter name. Rel could give the idea that this is a
Rel type relocation with no addend.
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)
@@ -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::relocations().
+ mutable SmallVector, 0> Crels;
smithp35 wrote:
Are there any thread-safety concerns here?
It looks like this can be modified when obtaining an iterator?
Just thinking of a use case where multiple threads given a const reference to
an ELFObjectFile iterate through different CREL sections in the same object.
There may be no expectation that this would work though.
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)
@@ -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(Rel)->r_addend;
+ if (getRelSection(Rel)->sh_type == ELF::SHT_RELA)
+return (int64_t)getRela(Rel)->r_addend;
+ if (getRelSection(Rel)->sh_type == ELF::SHT_CREL)
smithp35 wrote:
If the addend bit in the "header" for the CREL section is 0 should this return
an Error?
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)
@@ -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 similar purpose but is
slightly different
https://github.com/llvm/llvm-project/blob/main/lld/ELF/InputSection.h#L39 . Is
this likely to clash?
In LLD this is an exclusive or, it looks like this could be an inclusive or as
both parts of the pair are accessed in `printDynamicRelocationsHelper` ;
however that might just be for implementation convenience.
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 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 & DeltaSymbolMask) ``` I'll keep looking, likely next week. 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)
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. Possible examples: * A patch to the LLVM documentation. * A blog-post that is kept up to date with the implementation. * A discourse post that is updated. 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] [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 https://github.com/llvm/llvm-project/pull/91567 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[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 agree that the section type should be in the generic range. While it is in the experimental stage it could be possible to put it in SHT_LOOS SHT_HIOS range temporarily. When there is an official ELF code in the generic range it could be changed (forcing a recompile, or a migration script), or just have the LLVM tools implicitly convert from the old code to the new. For the experimental range. * While I can give a personal opinion. This will touch multiple components of LLVM each with their own code-owners. Will probably need a signal, either on the review or via discourse threads that the community is happy to go ahead with the addition of CREL. 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] 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 as close to the assembly output. I'm not hugely concerned about that personally as I don't think there are any written guarantees and I come from a background of a toolchain that didn't come close to that (assembler output was disassembled from object file), however there were some strong opinions on the original change. Do we have any strong opinions from the other reviewers? If there is a RFC I suggest that it would be entitled something like "[RFC] Clang assembly/object equivalence for files with inline assembly". If it is worded in such a way that this is needed for the kernel and we want to check for community input then if there is no response then we can go ahead. 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
[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 failures are likely to have been of minor incovenience. However we recently encountered a customer using `-save-temps` on their main build, which produces assembly and then re-assembles it; in our case there was a problem with describing the target to the assembler so that step failed. With this in mind I'm a bit reluctant to say that this wouldn't affect anyone's use case. This could be worth a RFC on Discourse to see if there is wider support or just apathy? 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
[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 something like:
/// Emit named sections with the same name into different sections.
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] [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 named special sections (i.e. symbols annotated with + ``__attribute__((section(...)))``. This enabled linker GC to collect unused smithp35 wrote: Should it be "This enables linker GC to collect ..." 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] [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 https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[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 picked back up. One of the comments in the description of the patch is: ``` Additionally this patch now only supports r6-r11. r4 and r5 are excluded from this patch as r4 is used as hard-coded scratch register in various parts of the ARM backend. r4 also appears to be used as an input register for a Windows asm routine (__chkstk). Similarly, the ABI of the segmented stack prologue for Android and Linux seems to use r4 and r5 as input registers. A separate patch could follow to add the support for r4 and/or r5, such that the whole range of allocatable registers (r4-r11) is available. ``` My suggestions: * Describe why R4 and R5 specifically and not R6 - R11? * If R4 and R5 are required then show that the hard-coded use in the backend is no longer there. If R4 and R5 are not required I suggest picking up the changes in https://reviews.llvm.org/D68862 * Add tests, especially if registers that have other uses in procedure call standards, or frame chains are used. * Given that the original was reverted due to interactions with r6, explain what further tests that you've made such as compiling large bodies of code or fuzz tested against programs. https://github.com/llvm/llvm-project/pull/89849 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[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 https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[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. 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-commits
[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) * Consistency between clang and gcc (more consistent the better) * Historical behaviour of -march=armv8-r (how often is it used vs -mcpu) * Historical behaviour of -mcpu=cortex-r82 (keeping these stable as this is the most specific target) * Consistency with other -march and -mcpu with respect to feature enablement heuristics (helps transition between options). As a general rule/heuristic for Arm feature enablement going forward, you will find exceptions to these rules in LLVM, particularly pre Armv8. we tend towards: * -march enables the mandatory features, but not the optional features, with specific exceptions such as SVE for Armv9 and floating point and SIMD for AArch64 Armv8 * -mcpu enables the mandatory and optional features, with specific exceptions such as crypto The Cortex-R series are intended for deeply embedded applications so it is normally possible for a user to directly target the CPU rather than the architecture. As there is only one v8-R CPU I'm fully expecting most users to use `-mcpu=cortex-r82` rather than `-march=armv8-r`. With these in mind. I propose: * `-march=armv8-r` enables the mandatory architectural features and including the mandatory minimum FPU given that all implementations of v8-R have that. It doesn't make sense to make it optional for puritys sake. * Make `-march=armv8-r` use a generic CPU so that we don't need to change cortex-r82. Yes this will make the performance of v8-R worse without `-mtune`, but I think it is preferable to keep -mcpu=cortex-r82 unaltered as that is what most people will be using. * Do not change -mcpu=cortex-r82 from its current default. This is again an opinion based the weights that I put on the trade-off dimensions. 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-commits
[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 b dest2 // b.w 4-byte branch nop dest: nop .space 2048 dest2: nop ``` Regardless of what -mrelax-all is (or the llvm-mc equivalent) the first `b dest` is always the smaller branch. https://github.com/llvm/llvm-project/pull/90013 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[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 > > [developer.arm.com/documentation/dui0472/m/Compiler-Command-line-Options/--unaligned-accessno-unaligned-access](https://developer.arm.com/documentation/dui0472/m/Compiler-Command-line-Options/--unaligned-accessno-unaligned-access) > > which has been carried forward for the LLVM based Arm Compiler > > [developer.arm.com/documentation/101754/0621/armclang-Reference/armclang-Command-line-Options/-munaligned-access---mno-unaligned-access?lang=en](https://developer.arm.com/documentation/101754/0621/armclang-Reference/armclang-Command-line-Options/-munaligned-access---mno-unaligned-access?lang=en) > > Yes the proprietary compiler can always put this back as a downstream > > change. However we are trying to introduce more use of upstream clang and > > it would help migration of these projects if they didn't need to change. > > Thanks for the comments. The first link gives `--unaligned_access, > --no_unaligned_access`, which Clang doesn't support. Yes the first link is just showing the history of the name. The --unaligned_access became -munaligned-access in clang/gcc for Arm. > Does the second link mean AArch32 or AArch64? It means both. > I thinks there may be strong motivation to keep both `-m[no-]strict-align` > for AArch32 (`-mno-strict-align` was a recent introduction by LoongArch > folks) but very little for AArch64 (since GCC has always been rejecting > `-m[no-]unaligned-access`). > > Part of the motivation behind the change and #85350 is to discourage future > ports (including existing RISC-V/LoongArch) to create aliases for > architectures that don't need the aliases. I would just like to keep the `-mno-unaligned-access` alias for AArch64 if at all possible, I've no problem with it not aliasing for all targets. I think existing code coming from GCC or needing to be compatible with GCC will use `-mstrict-align` and `-mno-strict-align` and will be unaffected, however looking at the history this option has been supported in clang for AArch64 for almost 10 years. In our proprietary toolchain we've consistently used `-mno-unaligned-access` for AArch64. As mentioned previously we can always downstream patch that, although it adds yet another item to the migration guide to move people to upstream clang. Tracing the history back it looks like AArch64 -mno-unaligned-access support was added in 2014 with ``` commit e5cee260ce07f96a8bc8f82905bc319cc33106fe Author: Kevin Qin Date: Tue May 6 09:51:32 2014 + [PATCH] [ARM64] Enable alignment control option in front-end for ARM64. This patch is to get "-mno-unaligned-access" and "-munaligned-access" work in front-end for ARM64 target. llvm-svn: 208075 ``` Checking our own issue tracker I've found our own internal ticket. Which doesn't add much information, it does have: ``` ARM64 had one back-end option "arm64-strict-align" to enable strict align mode, but didn't support any command line option in front-end. This patch allows users use "-mno-unaligned-access" and "-munaligned-access" in front-end to directly control alignment settings. ``` https://github.com/llvm/llvm-project/pull/85441 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[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 https://developer.arm.com/documentation/dui0472/m/Compiler-Command-line-Options/--unaligned-accessno-unaligned-access which has been carried forward for the LLVM based Arm Compiler https://developer.arm.com/documentation/101754/0621/armclang-Reference/armclang-Command-line-Options/-munaligned-access---mno-unaligned-access?lang=en Yes the proprietary compiler can always put this back as a downstream change. However we are trying to introduce more use of upstream clang and it would help migration of these projects if they didn't need to change. https://github.com/llvm/llvm-project/pull/85441 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[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 (A->getOption().matches(options::OPT_mno_unaligned_access))
+ if (Arg *A = Args.getLastArg(
+ options::OPT_mstrict_align, options::OPT_mno_strict_align,
+ options::OPT_mno_unaligned_access, options::OPT_munaligned_access)) {
+if (A->getOption().matches(options::OPT_mstrict_align) ||
+A->getOption().matches(options::OPT_mno_unaligned_access))
smithp35 wrote:
Preventing unaligned access can be useful in AArch64, it is an option we do use
to build our embedded C-libraries with (not a focus for GCC). It is documented
in the toolchain manual
https://developer.arm.com/documentation/101754/0621/armclang-Reference/armclang-Command-line-Options/-munaligned-access---mno-unaligned-access
In summary, we'd like to keep it for AArch64.
AArch64 always has the option of using unaligned accesses, but they can be
disabled by writing the SCTLR register, and accesses to Device memory always
need to be aligned. Code that runs before the MMU is enabled runs as if Device
memory.
```
Unaligned accesses to Normal memory
The behavior of unaligned accesses to Normal memory is dependent on all of the
following:
• The instruction causing the memory access.
• The memory attributes of the accessed memory.
• The value of SCTLR_ELx.{A, nAA}.
• Whether or not FEAT_LSE2 is implemented.
```
https://github.com/llvm/llvm-project/pull/85350
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[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. https://github.com/llvm/llvm-project/pull/82400 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[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 same goes for NaCl
-// and Windows.
-//
-// The above behavior is consistent with GCC.
+// and Windows. However, ARM's forks of GCC and Clang both allow
+// unaligned accesses by default for all targets. We follow this
+// behavior and enable unaligned accesses by default for ARMv7+ targets.
+// Users can disable behavior via compiler options (-mno-unaliged-access).
+// See https://github.com/llvm/llvm-project/issues/59560 for more info.
int VersionNum = getARMSubArchVersionNumber(Triple);
if (Triple.isOSDarwin() || Triple.isOSNetBSD()) {
if (VersionNum < 6 ||
Triple.getSubArch() == llvm::Triple::SubArchType::ARMSubArch_v6m)
Features.push_back("+strict-align");
-} else if (Triple.isOSLinux() || Triple.isOSNaCl() ||
- Triple.isOSWindows()) {
- if (VersionNum < 7)
+} else if (VersionNum < 7)
smithp35 wrote:
I don't think this is quite right. Armv6 (but not Armv6-M) can support
unaligned accesses. V8-M.main (logical extension of Armv7-M) supports unaligned
accesses but v8-M.base (logical extension of Armv6-M) does not. Yet both will
get VersionNum of 8.
Although not quite at the same point Arm's downstream fork uses
```
if (VersionNum < 6 ||
Triple.getSubArch() == llvm::Triple::SubArchType::ARMSubArch_v6m ||
Triple.getSubArch() ==
llvm::Triple::SubArchType::ARMSubArch_v8m_baseline) {
Features.push_back("+strict-align");
```
I don't suppose many care about Arm v6 but we'll need to make sure that
strict-align is added for v8-m.base.
Arm's fork of clang mentions this in the documentation for
-mno-unaligned-access
https://developer.arm.com/documentation/101754/0621/armclang-Reference/armclang-Command-line-Options/-munaligned-access---mno-unaligned-access
https://github.com/llvm/llvm-project/pull/82400
___
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)
@@ -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 has already been made in #80201 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 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 cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[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 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[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 https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[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 constraint "S" in terms of constraint "s" as Clang's implementation of "s" is equivalent to AArch64 "S". On that basis this looks reasonable to me. I've not had time to pick over the details of the code/test changes though. 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
[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 describing entities in the same module. I've asked a colleague that knows more about debug generation than I do. If I get an answer I'll post another comment. There is a typo in the description (SHN_ANS) -> (SHN_ABS) https://github.com/llvm/llvm-project/pull/79238 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[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. I will work on it now. I think it's quite rare though and anyway, this > is more than RuntimeDyld ever supported. So, I think we could land it already. Thanks I'll try and take a look later today, but as I mentioned I'm probably not familiar enough with JITLink to add much value to the code-changes so feel free to land this as an improvement on what is already there. Just in case you weren't aware. The ABI does not require a stub for R_ARM_THM_JUMP11 for either range extension or interworking, the range is so small it would be quite a challenge to place a stub close enough to it. In practice this makes the 2-byte Thumb B instruction restricted to targets within the same section (or even same function), which a code-generator won't change-state. An assembly programmer might, but if they do then they have to do the interworking manually. It is possible in Thumb-1 to have a 4-byte B instruction that uses R_ARM_THM_JUMP24 that will need a stub from Thumb to Arm. This is in Call and Jump Relocations https://github.com/ARM-software/abi-aa/blob/main/aaelf32/aaelf32.rst ``` A linker may use a veneer (a sequence of instructions) to implement the relocated branch if the relocation is one of R_ARM_PC24, R_ARM_CALL, R_ARM_JUMP24, (or, in Thumb state, R_ARM_THM_CALL, R_ARM_THM_JUMP24, or R_ARM_THM_JUMP19) and: ``` https://github.com/llvm/llvm-project/pull/79082 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[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 index and whether the symbol is exported into .dynsym.
+ // * -1 (initial): not exported, binding unchanged
smithp35 wrote:
Is it work saying -1u as the field is uint16_t?
I guess this means that we'll not be able to support a program with 65535
symbol versions. Probably not likely to encounter that in practice.
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
[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, say dynamicVersion and make this private. This could have a getVersionId(), setVersionId() hasVersionId() exportDynamic() and isExportDynamic(). Essentially make all uses of the previous variables into functions that use the same underlying variable dynamicVersion but don't use it directly. Not got a strong opinion so just a suggestion. The getVersionId() could assert hasVersionId() which could check that it wasn't the magic value. 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
[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 form that users of -mcmodel=large on AArch64 are recommended to add -fno-pic. I think this is better than -mcmodel=large silently producing non position independent code. https://github.com/llvm/llvm-project/pull/70262 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[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 think this problem specific to AArch64? It would also affect the other
targets that use .eh_frame such as x86_64.
As I understand it this was triggered by the Picolibc linker script
(https://github.com/picolibc/picolibc/blob/main/picolibc.ld.in) with extract:
```
.except_ordered : {
*(.gcc_except_table *.gcc_except_table.*)
KEEP (*(.eh_frame .eh_frame.*))
*(.ARM.extab* .gnu.linkonce.armextab.*)
} >flash AT>flash :text
```
Which has the .eh_frame sections after .gcc_except_table.
I made a failing test case for x86_64 by editing the output of GNU ld's
--verbose and adding a dummy QUAD statement. I've not included the whole ld
--verbose output as it is rather long.
```
/* Insert QUAD(0) to make .eh_frame start at non 0 offset within ouptut
section */
.eh_frame : ONLY_IF_RO { QUAD(0); KEEP (*(.eh_frame)) *(.eh_frame.*) }
```
With the simple test program
```
#include
int main(void) {
try {
throw 55;
}
catch (int i) { printf("Caught int %d\n", i); }
catch (...) { printf("Caught generic\n"); }
return 0;
}
```
With results:
```
clang++ -fuse-ld=bfd throw.cpp -o throw.exe -Wl,--script=ld.script
./throw.exe
Caught int 55
clang++ -fuse-ld=lld throw.cpp -o throw.exe -Wl,--script=ld.script
./throw.exe
[1]444896 abort (core dumped) ./throw.exe
```
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] [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 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[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
LOG: [MC] Add MCSubtargetInfo to MCAlignFragment
In preparation for passing the MCSubtargetInfo (STI) through to writeNops
so that it can use the STI in operation at the time, we need to record the
STI in operation when a MCAlignFragment may write nops as padding. The
STI is currently unused, a further patch will pass it through to
writeNops.
There are many places that can create an MCAlignFragment, in most cases
we can find out the STI in operation at the time. In a few places this
isn't possible as we are in initialisation or finalisation, or are
emitting constant pools. When possible I've tried to find the most
appropriate existing fragment to obtain the STI from, when none is
available use the per module STI.
For constant pools we don't actually need to use EmitCodeAlign as the
constant pools are data anyway so falling through into it via an
executable NOP is no better than falling through into data padding.
This is a prerequisite for D45962 which uses the STI to emit the
appropriate NOP for the STI. Which can differ per fragment.
Note that involves an interface change to InitSections. It is now
called initSections and requires a SubtargetInfo as a parameter.
Differential Revision: https://reviews.llvm.org/D45961
Added:
Modified:
clang/tools/driver/cc1as_main.cpp
llvm/include/llvm/MC/MCELFStreamer.h
llvm/include/llvm/MC/MCFragment.h
llvm/include/llvm/MC/MCObjectStreamer.h
llvm/include/llvm/MC/MCStreamer.h
llvm/include/llvm/MC/MCWinCOFFStreamer.h
llvm/lib/CodeGen/AsmPrinter/AsmPrinter.cpp
llvm/lib/MC/ConstantPools.cpp
llvm/lib/MC/MCAsmStreamer.cpp
llvm/lib/MC/MCELFStreamer.cpp
llvm/lib/MC/MCObjectStreamer.cpp
llvm/lib/MC/MCParser/AsmParser.cpp
llvm/lib/MC/MCParser/MasmParser.cpp
llvm/lib/MC/MCStreamer.cpp
llvm/lib/MC/MCWinCOFFStreamer.cpp
llvm/lib/Target/AArch64/AArch64AsmPrinter.cpp
llvm/lib/Target/ARM/ARMAsmPrinter.cpp
llvm/lib/Target/ARM/ARMMCInstLower.cpp
llvm/lib/Target/ARM/AsmParser/ARMAsmParser.cpp
llvm/lib/Target/ARM/MCTargetDesc/ARMELFStreamer.cpp
llvm/lib/Target/Hexagon/AsmParser/HexagonAsmParser.cpp
llvm/lib/Target/Hexagon/HexagonAsmPrinter.cpp
llvm/lib/Target/Hexagon/HexagonTargetStreamer.h
llvm/lib/Target/Mips/MCTargetDesc/MipsTargetStreamer.cpp
llvm/lib/Target/Mips/MipsAsmPrinter.cpp
llvm/lib/Target/PowerPC/MCTargetDesc/PPCELFStreamer.cpp
llvm/lib/Target/PowerPC/MCTargetDesc/PPCXCOFFStreamer.cpp
llvm/lib/Target/PowerPC/PPCAsmPrinter.cpp
llvm/lib/Target/X86/AsmParser/X86AsmParser.cpp
llvm/lib/Target/X86/X86MCInstLower.cpp
llvm/tools/llvm-mc/Disassembler.cpp
llvm/tools/llvm-mc/llvm-mc.cpp
llvm/tools/llvm-ml/Disassembler.cpp
llvm/unittests/DebugInfo/DWARF/DWARFExpressionCopyBytesTest.cpp
Removed:
diff --git a/clang/tools/driver/cc1as_main.cpp
b/clang/tools/driver/cc1as_main.cpp
index 086ce0ea77875..6549b132f6166 100644
--- a/clang/tools/driver/cc1as_main.cpp
+++ b/clang/tools/driver/cc1as_main.cpp
@@ -490,7 +490,7 @@ static bool ExecuteAssemblerImpl(AssemblerInvocation ,
T, Ctx, std::move(MAB), std::move(OW), std::move(CE), *STI,
Opts.RelaxAll, Opts.IncrementalLinkerCompatible,
/*DWARFMustBeAtTheEnd*/ true));
-Str.get()->InitSections(Opts.NoExecStack);
+Str.get()->initSections(Opts.NoExecStack, *STI);
}
// When -fembed-bitcode is passed to clang_as, a 1-byte marker
diff --git a/llvm/include/llvm/MC/MCELFStreamer.h
b/llvm/include/llvm/MC/MCELFStreamer.h
index 8c1e22a147025..8f2b176862c85 100644
--- a/llvm/include/llvm/MC/MCELFStreamer.h
+++ b/llvm/include/llvm/MC/MCELFStreamer.h
@@ -39,7 +39,7 @@ class MCELFStreamer : public MCObjectStreamer {
/// \name MCStreamer Interface
/// @{
- void InitSections(bool NoExecStack) override;
+ void initSections(bool NoExecStack, const MCSubtargetInfo ) override;
void changeSection(MCSection *Section, const MCExpr *Subsection) override;
void emitLabel(MCSymbol *Symbol, SMLoc Loc = SMLoc()) override;
void emitLabelAtPos(MCSymbol *Symbol, SMLoc Loc, MCFragment *F,
diff --git a/llvm/include/llvm/MC/MCFragment.h
b/llvm/include/llvm/MC/MCFragment.h
index f3a785fb09b7f..d415e10ab2779 100644
--- a/llvm/include/llvm/MC/MCFragment.h
+++ b/llvm/include/llvm/MC/MCFragment.h
@@ -311,6 +311,9 @@ class MCAlignFragment : public MCFragment {
/// cannot be satisfied in this width then this fragment is ignored.
unsigned MaxBytesToEmit;
+ /// When emitting Nops some subtargets have specific nop encodings.
+ const MCSubtargetInfo *STI;
+
public:
[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 LOG: [DOCS] Add more detail to stack protector documentation The Clang -fstack-protector documentation mentions what functions are considered vulnerable but does not mention the details of the implementation such as the use of a global variable for the guard value. This brings the documentation more in line with the GCC documentation at: https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html and gives someone using the option more idea about what is protected. This partly addresses https://bugs.llvm.org/show_bug.cgi?id=42764 Differential Revision: https://reviews.llvm.org/D85239 Added: Modified: clang/docs/ClangCommandLineReference.rst clang/include/clang/Driver/Options.td Removed: diff --git a/clang/docs/ClangCommandLineReference.rst b/clang/docs/ClangCommandLineReference.rst index 8eb010eae265..4caa08a82a72 100644 --- a/clang/docs/ClangCommandLineReference.rst +++ b/clang/docs/ClangCommandLineReference.rst @@ -2136,7 +2136,7 @@ Enable stack clash protection .. option:: -fstack-protector, -fno-stack-protector -Enable stack protectors for some functions vulnerable to stack smashing. This uses a loose heuristic which considers functions vulnerable if they contain a char (or 8bit integer) array or constant sized calls to alloca, which are of greater size than ssp-buffer-size (default: 8 bytes). All variable sized calls to alloca are considered vulnerable +Enable stack protectors for some functions vulnerable to stack smashing. This uses a loose heuristic which considers functions vulnerable if they contain a char (or 8bit integer) array or constant sized calls to alloca , which are of greater size than ssp-buffer-size (default: 8 bytes). All variable sized calls to alloca are considered vulnerable. A function witha stack protector has a guard value added to the stack frame that is checked on function exit. The guard value must be positioned in the stack frame such that a buffer overflow from a vulnerable variable will overwrite the guard value before overwriting the function's return address. The reference stack guard value is stored in a global variable. .. option:: -fstack-protector-all diff --git a/clang/include/clang/Driver/Options.td b/clang/include/clang/Driver/Options.td index 786a3c362842..fc31c23e4240 100644 --- a/clang/include/clang/Driver/Options.td +++ b/clang/include/clang/Driver/Options.td @@ -1801,10 +1801,15 @@ def fstack_protector_strong : Flag<["-"], "fstack-protector-strong">, Group; def fstack_protector : Flag<["-"], "fstack-protector">, Group, HelpText<"Enable stack protectors for some functions vulnerable to stack smashing. " - "This uses a loose heuristic which considers functions vulnerable " - "if they contain a char (or 8bit integer) array or constant sized calls to " - "alloca, which are of greater size than ssp-buffer-size (default: 8 bytes). " - "All variable sized calls to alloca are considered vulnerable">; + "This uses a loose heuristic which considers functions vulnerable if they " + "contain a char (or 8bit integer) array or constant sized calls to alloca " + ", which are of greater size than ssp-buffer-size (default: 8 bytes). All " + "variable sized calls to alloca are considered vulnerable. A function with" + "a stack protector has a guard value added to the stack frame that is " + "checked on function exit. The guard value must be positioned in the " + "stack frame such that a buffer overflow from a vulnerable variable will " + "overwrite the guard value before overwriting the function's return " + "address. The reference stack guard value is stored in a global variable.">; def ftrivial_auto_var_init : Joined<["-"], "ftrivial-auto-var-init=">, Group, Flags<[CC1Option, CoreOption]>, HelpText<"Initialize trivial automatic stack variables: uninitialized (default)" " | pattern">, Values<"uninitialized,pattern">; ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[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
LOG: This option allows selecting the TLS size in the local exec TLS model,
which is the default TLS model for non-PIC objects. This allows large/
many thread local variables or a compact/fast code in an executable.
Specification is same as that of GCC. For example, the code model
option precedes the TLS size option.
TLS access models other than local-exec are not changed. It means
supoort of the large code model is only in the local exec TLS model.
Patch By KAWASHIMA Takahiro (kawashima-fj )
Reviewers: dmgreen, mstorsjo, t.p.northover, peter.smith, ostannard
Reviewd By: peter.smith
Committed by: peter.smith
Differential Revision: https://reviews.llvm.org/D71688
Added:
clang/test/Driver/tls-size.c
llvm/test/CodeGen/AArch64/arm64-tls-initial-exec.ll
llvm/test/CodeGen/AArch64/arm64-tls-local-exec.ll
Modified:
clang/include/clang/Basic/CodeGenOptions.def
clang/include/clang/Driver/Options.td
clang/lib/CodeGen/BackendUtil.cpp
clang/lib/Driver/ToolChains/Clang.cpp
clang/lib/Frontend/CompilerInvocation.cpp
llvm/include/llvm/CodeGen/CommandFlags.inc
llvm/include/llvm/Target/TargetOptions.h
llvm/lib/Target/AArch64/AArch64ISelLowering.cpp
llvm/lib/Target/AArch64/AArch64ISelLowering.h
llvm/lib/Target/AArch64/AArch64TargetMachine.cpp
Removed:
llvm/test/CodeGen/AArch64/arm64-tls-execs.ll
diff --git a/clang/include/clang/Basic/CodeGenOptions.def
b/clang/include/clang/Basic/CodeGenOptions.def
index cf8fbe251b35..50fc1836282f 100644
--- a/clang/include/clang/Basic/CodeGenOptions.def
+++ b/clang/include/clang/Basic/CodeGenOptions.def
@@ -333,6 +333,9 @@ ENUM_CODEGENOPT(VecLib, VectorLibrary, 2, NoLibrary)
/// The default TLS model to use.
ENUM_CODEGENOPT(DefaultTLSModel, TLSModel, 2, GeneralDynamicTLSModel)
+/// Bit size of immediate TLS offsets (0 == use the default).
+VALUE_CODEGENOPT(TLSSize, 8, 0)
+
/// Number of path components to strip when emitting checks. (0 == full
/// filename)
VALUE_CODEGENOPT(EmitCheckPathComponentsToStrip, 32, 0)
diff --git a/clang/include/clang/Driver/Options.td
b/clang/include/clang/Driver/Options.td
index 0fee90707d40..71b257094a98 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -2178,6 +2178,9 @@ def mwatchsimulator_version_min_EQ : Joined<["-"],
"mwatchsimulator-version-min=
def march_EQ : Joined<["-"], "march=">, Group, Flags<[CoreOption]>;
def masm_EQ : Joined<["-"], "masm=">, Group, Flags<[DriverOption]>;
def mcmodel_EQ : Joined<["-"], "mcmodel=">, Group;
+def mtls_size_EQ : Joined<["-"], "mtls-size=">, Group,
Flags<[DriverOption, CC1Option]>,
+ HelpText<"Specify bit size of immediate TLS offsets (AArch64 ELF only): "
+ "12 (for 4KB) | 24 (for 16MB, default) | 32 (for 4GB) | 48 (for
256TB, needs -mcmodel=large)">;
def mimplicit_it_EQ : Joined<["-"], "mimplicit-it=">, Group;
def mdefault_build_attributes : Joined<["-"], "mdefault-build-attributes">,
Group;
def mno_default_build_attributes : Joined<["-"],
"mno-default-build-attributes">, Group;
diff --git a/clang/lib/CodeGen/BackendUtil.cpp
b/clang/lib/CodeGen/BackendUtil.cpp
index d58bcf5a7905..0bfcab88a3a9 100644
--- a/clang/lib/CodeGen/BackendUtil.cpp
+++ b/clang/lib/CodeGen/BackendUtil.cpp
@@ -474,6 +474,7 @@ static void initTargetOptions(llvm::TargetOptions ,
Options.FunctionSections = CodeGenOpts.FunctionSections;
Options.DataSections = CodeGenOpts.DataSections;
Options.UniqueSectionNames = CodeGenOpts.UniqueSectionNames;
+ Options.TLSSize = CodeGenOpts.TLSSize;
Options.EmulatedTLS = CodeGenOpts.EmulatedTLS;
Options.ExplicitEmulatedTLS = CodeGenOpts.ExplicitEmulatedTLS;
Options.DebuggerTuning = CodeGenOpts.getDebuggerTuning();
diff --git a/clang/lib/Driver/ToolChains/Clang.cpp
b/clang/lib/Driver/ToolChains/Clang.cpp
index 4ef40e974cd6..4d924e072f57 100644
--- a/clang/lib/Driver/ToolChains/Clang.cpp
+++ b/clang/lib/Driver/ToolChains/Clang.cpp
@@ -4531,6 +4531,19 @@ void Clang::ConstructJob(Compilation , const JobAction
,
CmdArgs.push_back(A->getValue());
}
+ if (Arg *A = Args.getLastArg(options::OPT_mtls_size_EQ)) {
+StringRef Value = A->getValue();
+unsigned TLSSize = 0;
+Value.getAsInteger(10, TLSSize);
+if (!Triple.isAArch64() || !Triple.isOSBinFormatELF())
+ D.Diag(diag::err_drv_unsupported_opt_for_target)
+ << A->getOption().getName() << TripleStr;
+if (TLSSize != 12 && TLSSize != 24 && TLSSize != 32 && TLSSize != 48)
+ D.Diag(diag::err_drv_invalid_int_value)
+ << A->getOption().getName() << Value;
+
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:
llvm-project/clang/test/SemaCXX/int-ptr-cast-SFINAE.cpp:5:5: warning:
incompatible integer to pointer conversion assigning to 'int *' from
'int'; take the address with &
a -= b; // expected-warning {{incompatible integer to pointer
conversion assigning to 'int *' from 'long'}}
^ ~
&
Could you take a look and update the test?
Thanks in advance
Peter
On Thu, 17 Jan 2019 at 23:14, Erich Keane via cfe-commits
wrote:
>
> Author: erichkeane
> Date: Thu Jan 17 15:11:15 2019
> New Revision: 351495
>
> URL: http://llvm.org/viewvc/llvm-project?rev=351495=rev
> Log:
> Make integral-o-pointer conversions in SFINAE illegal.
>
> As reported in PR40362, allowing the conversion from an integral to a
> pointer type (despite being illegal in the C++ standard) will cause
> surprsing results when testing for certain behaviors in SFINAE. This
> patch converts the error to a SFINAE Error and adds a test to ensure
> that it is still a warning in non-SFINAE but an error in it.
>
> Change-Id: I1f475637fa4d83217ae37dc6b5dbf653e118fae4
>
> Added:
> cfe/trunk/test/SemaCXX/int-ptr-cast-SFINAE.cpp (with props)
> Modified:
> cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
>
> Modified: cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td?rev=351495=351494=351495=diff
> ==
> --- cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td (original)
> +++ cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td Thu Jan 17 15:11:15
> 2019
> @@ -6817,7 +6817,7 @@ def ext_typecheck_convert_int_pointer :
>"; take the address with &|"
>"; remove *|"
>"; remove &}3">,
> - InGroup;
> + InGroup, SFINAEFailure;
> def ext_typecheck_convert_pointer_void_func : Extension<
>"%select{%diff{assigning to $ from $|assigning to different types}0,1"
>"|%diff{passing $ to parameter of type $|"
>
> Added: cfe/trunk/test/SemaCXX/int-ptr-cast-SFINAE.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaCXX/int-ptr-cast-SFINAE.cpp?rev=351495=auto
> ==
> --- cfe/trunk/test/SemaCXX/int-ptr-cast-SFINAE.cpp (added)
> +++ cfe/trunk/test/SemaCXX/int-ptr-cast-SFINAE.cpp Thu Jan 17 15:11:15 2019
> @@ -0,0 +1,22 @@
> +// RUN: %clang_cc1 -fsyntax-only -verify %s
> +// RUN: %clang_cc1 -fsyntax-only -verify %s -std=c++17
> +
> +void foo(int* a, int *b) {
> + a -= b; // expected-warning {{incompatible integer to pointer conversion
> assigning to 'int *' from 'long'}}
> +}
> +
> +template T declval();
> +struct true_type { static const bool value = true; };
> +struct false_type { static const bool value = false; };
> +template struct select { using type = T; };
> +template struct select { using type =
> U; };
> +
> +
> +template
> +typename select<(sizeof(declval() -= declval(), 1) != 1), true_type,
> false_type>::type test(...);
> +template false_type test(...);
> +
> +template
> +static const auto has_minus_assign = decltype(test())::value;
> +
> +static_assert(has_minus_assign, "failed"); // expected-error
> {{static_assert failed due to requirement 'has_minus_assign' "failed"}}
>
> Propchange: cfe/trunk/test/SemaCXX/int-ptr-cast-SFINAE.cpp
> --
> svn:eol-style = native
>
> Propchange: cfe/trunk/test/SemaCXX/int-ptr-cast-SFINAE.cpp
> --
> svn:keywords = "Author Date Id Rev URL"
>
> Propchange: cfe/trunk/test/SemaCXX/int-ptr-cast-SFINAE.cpp
> --
> svn:mime-type = text/plain
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
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
- -triple %ms_abi_triple 2>&1 | FileCheck %s --check-prefix=MSABI
that is failing. I originally thought that this was due to our
builders not having the X86 target configured but it seems to be
reproducible on an Arm v7 machine (Cortex-A72) with the X86 backend
included. The triple expands to -triple i686-pc-windows-msvc
The failure appears to be common across all builders:
/home/buildbots/ppc64le-clang-test/clang-ppc64le/llvm/tools/clang/test/CodeGenCXX/cxx2a-three-way-comparison.cpp:11:11:
error: MSABI: expected string not found in input
// MSABI: define {{.*}}@"??__MA@@QEAAXH@Z"(
^
:1:1: note: scanning from here
; ModuleID =
'/home/buildbots/ppc64le-clang-test/clang-ppc64le/llvm/tools/clang/test/CodeGenCXX/cxx2a-three-way-comparison.cpp'
^
:9:23: note: possible intended match here
define dso_local x86_thiscallcc void @"??__MA@@QAEXH@Z"(%struct.A*
%this, i32) #0 align 2 {
Could you take a look?
Thanks in advance
Peter
Links to builders:
http://lab.llvm.org:8011/builders/clang-cmake-aarch64-quick
http://lab.llvm.org:8011/builders/clang-cmake-armv7-quick
http://lab.llvm.org:8011/builders/clang-s390x-linux
http://lab.llvm.org:8011/builders/clang-ppc64le-linux
On Fri, 26 Oct 2018 at 00:23, Richard Smith via cfe-commits
wrote:
>
> I've already pointed Zach at this and I think he's going to handle it.
>
> On Thu, 25 Oct 2018 at 16:00, Nico Weber via cfe-commits
> wrote:
>>
>> Could you update the demangler too?
>>
>> On Thu, Oct 25, 2018 at 6:53 PM Richard Smith via cfe-commits
>> wrote:
>>>
>>> Author: rsmith
>>> Date: Thu Oct 25 15:51:16 2018
>>> New Revision: 345330
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=345330=rev
>>> Log:
>>> Add MS ABI mangling for operator<=>.
>>>
>>> Thanks to Cameron DaCamara at Microsoft for letting us know what their
>>> chosen mangling is here!
>>>
>>> Added:
>>> cfe/trunk/test/CodeGenCXX/mangle-ms-cxx2a.cpp
>>> Modified:
>>> cfe/trunk/lib/AST/MicrosoftMangle.cpp
>>> cfe/trunk/test/CodeGenCXX/cxx2a-three-way-comparison.cpp
>>>
>>> Modified: cfe/trunk/lib/AST/MicrosoftMangle.cpp
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/MicrosoftMangle.cpp?rev=345330=345329=345330=diff
>>> ==
>>> --- cfe/trunk/lib/AST/MicrosoftMangle.cpp (original)
>>> +++ cfe/trunk/lib/AST/MicrosoftMangle.cpp Thu Oct 25 15:51:16 2018
>>> @@ -1240,15 +1240,8 @@ void MicrosoftCXXNameMangler::mangleOper
>>>case OO_Array_Delete: Out << "?_V"; break;
>>>// ::= ?__L # co_await
>>>case OO_Coawait: Out << "?__L"; break;
>>> -
>>> - case OO_Spaceship: {
>>> -// FIXME: Once MS picks a mangling, use it.
>>> -DiagnosticsEngine = Context.getDiags();
>>> -unsigned DiagID = Diags.getCustomDiagID(DiagnosticsEngine::Error,
>>> - "cannot mangle this three-way comparison operator yet");
>>> -Diags.Report(Loc, DiagID);
>>> -break;
>>> - }
>>> + // ::= ?__M # <=>
>>> + case OO_Spaceship: Out << "?__M"; break;
>>>
>>>case OO_Conditional: {
>>> DiagnosticsEngine = Context.getDiags();
>>>
>>> Modified: cfe/trunk/test/CodeGenCXX/cxx2a-three-way-comparison.cpp
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/cxx2a-three-way-comparison.cpp?rev=345330=345329=345330=diff
>>> ==
>>> --- cfe/trunk/test/CodeGenCXX/cxx2a-three-way-comparison.cpp (original)
>>> +++ cfe/trunk/test/CodeGenCXX/cxx2a-three-way-comparison.cpp Thu Oct 25
>>> 15:51:16 2018
>>> @@ -1,24 +1,28 @@
>>> -// RUN: %clang_cc1 -std=c++2a -emit-llvm %s -o - -triple
>>> %itanium_abi_triple | FileCheck %s --check-prefix=ITANIUM
>>> -// RUN: not %clang_cc1 -std=c++2a -emit-llvm %s -o - -triple
>>> %ms_abi_triple 2>&1 | FileCheck %s --check-prefix=MSABI
>>> +// RUN: %clang_cc1 -std=c++2a -emit-llvm %s -o - -triple
>>> %itanium_abi_triple | FileCheck %s --check-prefixes=CHECK,ITANIUM
>>> +// RUN: %clang_cc1 -std=c++2a -emit-llvm %s -o - -triple %ms_abi_triple |
>>> FileCheck %s --check-prefixes=CHECK,MSABI
>>> // RUN: not %clang_cc1 -std=c++2a -emit-llvm %s -o - -triple
>>> %itanium_abi_triple -DBUILTIN 2>&1 | FileCheck %s --check-prefix=BUILTIN
>>> -// MSABI: cannot mangle this three-way comparison operator yet
>>> +// RUN: not %clang_cc1 -std=c++2a -emit-llvm %s -o - -triple
>>> %ms_abi_triple -DBUILTIN 2>&1 | FileCheck %s --check-prefix=BUILTIN
>>>
>>> struct A {
>>>void operator<=>(int);
>>> };
>>>
>>> // ITANIUM: define {{.*}}@_ZN1AssEi(
>>> +// MSABI: define {{.*}}@"??__MA@@QEAAXH@Z"(
>>> void A::operator<=>(int) {}
>>>
>>> // ITANIUM: define {{.*}}@_Zssi1A(
>>> +// MSABI:
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 statement. This will hopefully silence a GCC warning. Differential Revision: https://reviews.llvm.org/D52784 Modified: cfe/trunk/lib/Driver/ToolChains/Gnu.cpp Modified: cfe/trunk/lib/Driver/ToolChains/Gnu.cpp URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/Gnu.cpp?rev=344890=344889=344890=diff == --- cfe/trunk/lib/Driver/ToolChains/Gnu.cpp (original) +++ cfe/trunk/lib/Driver/ToolChains/Gnu.cpp Mon Oct 22 03:40:52 2018 @@ -239,6 +239,7 @@ static bool isArmBigEndian(const llvm::T case llvm::Triple::armeb: case llvm::Triple::thumbeb: IsBigEndian = true; +LLVM_FALLTHROUGH; case llvm::Triple::arm: case llvm::Triple::thumb: if (Arg *A = Args.getLastArg(options::OPT_mlittle_endian, ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
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 binutils default on the system is little
endian. This also holds when -mlittle-endian is used and the binutils
default is big endian.
The patch always passes through -EL or -BE to the assembler and linker,
taking into account the target and the -mbig-endian and -mlittle-endian
flag.
Fixes pr38770
Differential Revision: https://reviews.llvm.org/D52784
Modified:
cfe/trunk/lib/Driver/ToolChains/Arch/ARM.cpp
cfe/trunk/lib/Driver/ToolChains/Arch/ARM.h
cfe/trunk/lib/Driver/ToolChains/Gnu.cpp
cfe/trunk/lib/Driver/ToolChains/NetBSD.cpp
cfe/trunk/test/Driver/linux-as.c
cfe/trunk/test/Driver/linux-ld.c
Modified: cfe/trunk/lib/Driver/ToolChains/Arch/ARM.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/Arch/ARM.cpp?rev=344597=344596=344597=diff
==
--- cfe/trunk/lib/Driver/ToolChains/Arch/ARM.cpp (original)
+++ cfe/trunk/lib/Driver/ToolChains/Arch/ARM.cpp Tue Oct 16 02:21:17 2018
@@ -643,7 +643,7 @@ StringRef arm::getLLVMArchSuffixForARM(S
return llvm::ARM::getSubArch(ArchKind);
}
-void arm::appendEBLinkFlags(const ArgList , ArgStringList ,
+void arm::appendBE8LinkFlag(const ArgList , ArgStringList ,
const llvm::Triple ) {
if (Args.hasArg(options::OPT_r))
return;
Modified: cfe/trunk/lib/Driver/ToolChains/Arch/ARM.h
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/Arch/ARM.h?rev=344597=344596=344597=diff
==
--- cfe/trunk/lib/Driver/ToolChains/Arch/ARM.h (original)
+++ cfe/trunk/lib/Driver/ToolChains/Arch/ARM.h Tue Oct 16 02:21:17 2018
@@ -29,7 +29,7 @@ StringRef getARMCPUForMArch(llvm::String
StringRef getLLVMArchSuffixForARM(llvm::StringRef CPU, llvm::StringRef Arch,
const llvm::Triple );
-void appendEBLinkFlags(const llvm::opt::ArgList ,
+void appendBE8LinkFlag(const llvm::opt::ArgList ,
llvm::opt::ArgStringList ,
const llvm::Triple );
enum class ReadTPMode {
Modified: cfe/trunk/lib/Driver/ToolChains/Gnu.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/Gnu.cpp?rev=344597=344596=344597=diff
==
--- cfe/trunk/lib/Driver/ToolChains/Gnu.cpp (original)
+++ cfe/trunk/lib/Driver/ToolChains/Gnu.cpp Tue Oct 16 02:21:17 2018
@@ -228,6 +228,29 @@ void tools::gcc::Linker::RenderExtraTool
// The types are (hopefully) good enough.
}
+// On Arm the endianness of the output file is determined by the target and
+// can be overridden by the pseudo-target flags '-mlittle-endian'/'-EL' and
+// '-mbig-endian'/'-EB'. Unlike other targets the flag does not result in a
+// normalized triple so we must handle the flag here.
+static bool isArmBigEndian(const llvm::Triple ,
+ const ArgList ) {
+ bool IsBigEndian = false;
+ switch (Triple.getArch()) {
+ case llvm::Triple::armeb:
+ case llvm::Triple::thumbeb:
+IsBigEndian = true;
+ case llvm::Triple::arm:
+ case llvm::Triple::thumb:
+if (Arg *A = Args.getLastArg(options::OPT_mlittle_endian,
+ options::OPT_mbig_endian))
+ IsBigEndian = !A->getOption().matches(options::OPT_mlittle_endian);
+break;
+ default:
+break;
+ }
+ return IsBigEndian;
+}
+
static const char *getLDMOption(const llvm::Triple , const ArgList ) {
switch (T.getArch()) {
case llvm::Triple::x86:
@@ -240,10 +263,9 @@ static const char *getLDMOption(const ll
return "aarch64linuxb";
case llvm::Triple::arm:
case llvm::Triple::thumb:
-return "armelf_linux_eabi";
case llvm::Triple::armeb:
case llvm::Triple::thumbeb:
-return "armelfb_linux_eabi";
+return isArmBigEndian(T, Args) ? "armelfb_linux_eabi" :
"armelf_linux_eabi";
case llvm::Triple::ppc:
return "elf32ppclinux";
case llvm::Triple::ppc64:
@@ -337,8 +359,13 @@ void tools::gnutools::Linker::ConstructJ
if (Args.hasArg(options::OPT_s))
CmdArgs.push_back("-s");
- if (Arch == llvm::Triple::armeb || Arch == llvm::Triple::thumbeb)
-arm::appendEBLinkFlags(Args, CmdArgs, Triple);
+ if (Triple.isARM() || Triple.isThumb() || Triple.isAArch64()) {
+bool IsBigEndian = isArmBigEndian(Triple, Args);
+if (IsBigEndian)
+ arm::appendBE8LinkFlag(Args, CmdArgs, Triple);
+IsBigEndian = IsBigEndian || Arch == llvm::Triple::aarch64_be;
+CmdArgs.push_back(IsBigEndian ? "-EB" : "-EL");
+ }
// Most Android ARM64 targets should enable the linker fix for erratum
// 843419.
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. The tests in arm-cortex-cpus.c
need to be updated to account for this change.
Differential Revision: https://reviews.llvm.org/D52595
Modified:
cfe/trunk/test/Driver/arm-cortex-cpus.c
Modified: cfe/trunk/test/Driver/arm-cortex-cpus.c
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/arm-cortex-cpus.c?rev=343304=343303=343304=diff
==
--- cfe/trunk/test/Driver/arm-cortex-cpus.c (original)
+++ cfe/trunk/test/Driver/arm-cortex-cpus.c Fri Sep 28 02:04:31 2018
@@ -73,11 +73,11 @@
// RUN: %clang -target armv6k -### -c %s 2>&1 | FileCheck
-check-prefix=CHECK-V6K %s
// RUN: %clang -target arm -march=armv6k -### -c %s 2>&1 | FileCheck
-check-prefix=CHECK-V6K %s
-// CHECK-V6K: "-cc1"{{.*}} "-triple" "armv6k-{{.*}} "-target-cpu" "arm1176j-s"
+// CHECK-V6K: "-cc1"{{.*}} "-triple" "armv6k-{{.*}} "-target-cpu" "mpcore"
// RUN: %clang -target armv6k -mthumb -### -c %s 2>&1 | FileCheck
-check-prefix=CHECK-V6K-THUMB %s
// RUN: %clang -target arm -march=armv6k -mthumb -### -c %s 2>&1 | FileCheck
-check-prefix=CHECK-V6K-THUMB %s
-// CHECK-V6K-THUMB: "-cc1"{{.*}} "-triple" "thumbv6k-{{.*}} "-target-cpu"
"arm1176j-s"
+// CHECK-V6K-THUMB: "-cc1"{{.*}} "-triple" "thumbv6k-{{.*}} "-target-cpu"
"mpcore"
// RUN: %clang -target armv6t2 -### -c %s 2>&1 | FileCheck
-check-prefix=CHECK-V6T2 %s
// RUN: %clang -target arm -march=armv6t2 -### -c %s 2>&1 | FileCheck
-check-prefix=CHECK-V6T2 %s
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
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 equivalent emulation
mode supported by gnu ld is aarch64linuxb.
Patch by: Bharathi Seshadri
Reviewed by: Peter Smith
Differential Revision: https://reviews.llvm.org/D42930
Modified:
cfe/trunk/lib/Driver/ToolChains/Gnu.cpp
cfe/trunk/test/Driver/linux-ld.c
Modified: cfe/trunk/lib/Driver/ToolChains/Gnu.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/Gnu.cpp?rev=341312=341311=341312=diff
==
--- cfe/trunk/lib/Driver/ToolChains/Gnu.cpp (original)
+++ cfe/trunk/lib/Driver/ToolChains/Gnu.cpp Mon Sep 3 05:36:32 2018
@@ -237,7 +237,7 @@ static const char *getLDMOption(const ll
case llvm::Triple::aarch64:
return "aarch64linux";
case llvm::Triple::aarch64_be:
-return "aarch64_be_linux";
+return "aarch64linuxb";
case llvm::Triple::arm:
case llvm::Triple::thumb:
return "armelf_linux_eabi";
Modified: cfe/trunk/test/Driver/linux-ld.c
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/linux-ld.c?rev=341312=341311=341312=diff
==
--- cfe/trunk/test/Driver/linux-ld.c (original)
+++ cfe/trunk/test/Driver/linux-ld.c Mon Sep 3 05:36:32 2018
@@ -1754,6 +1754,14 @@
// CHECK-ARMV7EB: "--be8"
// CHECK-ARMV7EB: "-m" "armelfb_linux_eabi"
+// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
+// RUN: --target=aarch64_be-unknown-linux \
+// RUN: --gcc-toolchain="" \
+// RUN: --sysroot=%S/Inputs/basic_linux_tree \
+// RUN: | FileCheck --check-prefix=CHECK-AARCH64BE %s
+// CHECK-AARCH64BE: "{{.*}}ld{{(.exe)?}}" "--sysroot=[[SYSROOT:[^"]+]]"
+// CHECK-AARCH64BE: "-m" "aarch64linuxb"
+
// Check dynamic-linker for musl-libc
// RUN: %clang %s -### -o %t.o 2>&1 \
// RUN: --target=i386-pc-linux-musl \
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
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 modifiers were implemented in the original
AArch64 backend but were not carried forward to the merged backend. The
A is associated with ADRP and does nothing, the L is associated with
:lo12: . Given that A and L are not supported by GCC and not supported
by the new implementation of constraint S in LLVM (see D46745) I've
altered the test to put :lo12: directly in the string so that A and L
are not needed.
Differential Revision: https://reviews.llvm.org/D46932
Modified:
cfe/trunk/test/CodeGen/aarch64-inline-asm.c
Modified: cfe/trunk/test/CodeGen/aarch64-inline-asm.c
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/aarch64-inline-asm.c?rev=332606=332605=332606=diff
==
--- cfe/trunk/test/CodeGen/aarch64-inline-asm.c (original)
+++ cfe/trunk/test/CodeGen/aarch64-inline-asm.c Thu May 17 06:17:33 2018
@@ -44,9 +44,9 @@ void test_constraints_immed(void) {
void test_constraint_S(void) {
int *addr;
-asm("adrp %0, %A1\n\t"
-"add %0, %0, %L1" : "=r"(addr) : "S"());
-// CHECK: call i32* asm "adrp $0, ${1:A}\0A\09add $0, $0, ${1:L}", "=r,S"(i64*
@var)
+asm("adrp %0, %1\n\t"
+"add %0, %0, :lo12:%1" : "=r"(addr) : "S"());
+// CHECK: call i32* asm "adrp $0, $1\0A\09add $0, $0, :lo12:$1", "=r,S"(i64*
@var)
}
void test_constraint_Q(void) {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
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 Modified: cfe/trunk/lib/Driver/ToolChains/Clang.cpp URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/Clang.cpp?rev=318648=318647=318648=diff == --- cfe/trunk/lib/Driver/ToolChains/Clang.cpp (original) +++ cfe/trunk/lib/Driver/ToolChains/Clang.cpp Mon Nov 20 05:53:55 2017 @@ -1897,7 +1897,7 @@ static void CollectArgsForIntegratedAsse // -mthumb has already been processed in ComputeLLVMTriple() // recognize but skip over here. continue; - +break; case llvm::Triple::mips: case llvm::Triple::mipsel: case llvm::Triple::mips64: ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
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 for both Arm and Thumb with the choice
made as a compilation option.
The way this is done in gcc is to pass -mthumb to the assembler with either
-Wa,-mthumb or -Xassembler -mthumb. This change adds support for these
options to clang. There is no assembler equivalent of -mno-thumb, -marm or
-mno-arm so we don't need to recognize these.
Ideally we would do all of the processing in
CollectArgsForIntegratedAssembler(). Unfortunately we need to change the
triple and at that point it is too late. Instead we look for the option
earlier in ComputeLLVMTriple().
Fixes PR34519
Differential Revision: https://reviews.llvm.org/D40127
Added:
cfe/trunk/test/Driver/arm-target-as-mthumb.s
Modified:
cfe/trunk/lib/Driver/ToolChain.cpp
cfe/trunk/lib/Driver/ToolChains/Clang.cpp
Modified: cfe/trunk/lib/Driver/ToolChain.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChain.cpp?rev=318647=318646=318647=diff
==
--- cfe/trunk/lib/Driver/ToolChain.cpp (original)
+++ cfe/trunk/lib/Driver/ToolChain.cpp Mon Nov 20 05:43:55 2017
@@ -541,11 +541,30 @@ std::string ToolChain::ComputeLLVMTriple
<< tools::arm::getARMArch(MArch, getTriple()) << "ARM";
}
-// Assembly files should start in ARM mode, unless arch is M-profile.
-// Windows is always thumb.
-if ((InputType != types::TY_PP_Asm && Args.hasFlag(options::OPT_mthumb,
- options::OPT_mno_thumb, ThumbDefault)) || IsMProfile ||
- getTriple().isOSWindows()) {
+// Check to see if an explicit choice to use thumb has been made via
+// -mthumb. For assembler files we must check for -mthumb in the options
+// passed to the assember via -Wa or -Xassembler.
+bool IsThumb = false;
+if (InputType != types::TY_PP_Asm)
+ IsThumb = Args.hasFlag(options::OPT_mthumb, options::OPT_mno_thumb,
+ ThumbDefault);
+else {
+ // Ideally we would check for these flags in
+ // CollectArgsForIntegratedAssembler but we can't change the ArchName at
+ // that point. There is no assembler equivalent of -mno-thumb, -marm, or
+ // -mno-arm.
+ for (const Arg *A :
+ Args.filtered(options::OPT_Wa_COMMA, options::OPT_Xassembler)) {
+for (StringRef Value : A->getValues()) {
+ if (Value == "-mthumb")
+IsThumb = true;
+}
+ }
+}
+// Assembly files should start in ARM mode, unless arch is M-profile, or
+// -mthumb has been passed explicitly to the assembler. Windows is always
+// thumb.
+if (IsThumb || IsMProfile || getTriple().isOSWindows()) {
if (IsBigEndian)
ArchName = "thumbeb";
else
Modified: cfe/trunk/lib/Driver/ToolChains/Clang.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/Clang.cpp?rev=318647=318646=318647=diff
==
--- cfe/trunk/lib/Driver/ToolChains/Clang.cpp (original)
+++ cfe/trunk/lib/Driver/ToolChains/Clang.cpp Mon Nov 20 05:43:55 2017
@@ -1889,6 +1889,15 @@ static void CollectArgsForIntegratedAsse
switch (C.getDefaultToolChain().getArch()) {
default:
break;
+ case llvm::Triple::thumb:
+ case llvm::Triple::thumbeb:
+ case llvm::Triple::arm:
+ case llvm::Triple::armeb:
+if (Value == "-mthumb")
+ // -mthumb has already been processed in ComputeLLVMTriple()
+ // recognize but skip over here.
+ continue;
+
case llvm::Triple::mips:
case llvm::Triple::mipsel:
case llvm::Triple::mips64:
Added: cfe/trunk/test/Driver/arm-target-as-mthumb.s
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/arm-target-as-mthumb.s?rev=318647=auto
==
--- cfe/trunk/test/Driver/arm-target-as-mthumb.s (added)
+++ cfe/trunk/test/Driver/arm-target-as-mthumb.s Mon Nov 20 05:43:55 2017
@@ -0,0 +1,17 @@
+// Make sure -mthumb does not affect assembler triple, but -Wa,-mthumb or
+// -Xassembler -mthumb does. Also check that -Wa,-mthumb or -Xassembler -mthumb
+// does not affect non assembler files.
+
+// RUN: %clang -target armv7a-linux-gnueabi -### -c -mthumb %s 2>&1 | \
+// RUN: FileCheck -check-prefix=TRIPLE-ARM %s
+// RUN: %clang -target armv7a-linux-gnueabi -### -c -Wa,-mthumb \
+// RUN: %S/Inputs/wildcard1.c 2>&1 | FileCheck -check-prefix=TRIPLE-ARM %s
+
+// TRIPLE-ARM: "-triple" "armv7--linux-gnueabi"
+
+// RUN: %clang -target armv7a-linux-gnueabi -### -c -Wa,-mthumb %s 2>&1 | \
+// RUN: FileCheck
[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 libunwind depends on the tables to
unwind the stack several tests will fail.
This change always adds -funwind-tables so that even when -fno-exceptions
is set unwind tables are generated.
fixes PR33858
Differential Revision: https://reviews.llvm.org/D37484
Modified:
libunwind/trunk/test/libunwind/test/config.py
Modified: libunwind/trunk/test/libunwind/test/config.py
URL:
http://llvm.org/viewvc/llvm-project/libunwind/trunk/test/libunwind/test/config.py?rev=316657=316656=316657=diff
==
--- libunwind/trunk/test/libunwind/test/config.py (original)
+++ libunwind/trunk/test/libunwind/test/config.py Thu Oct 26 05:02:03 2017
@@ -43,10 +43,11 @@ class Configuration(LibcxxConfiguration)
def configure_compile_flags(self):
self.cxx.compile_flags += ['-DLIBUNWIND_NO_TIMER']
-if self.get_lit_bool('enable_exceptions', True):
-self.cxx.compile_flags += ['-funwind-tables']
-else:
+if not self.get_lit_bool('enable_exceptions', True):
self.cxx.compile_flags += ['-fno-exceptions',
'-DLIBUNWIND_HAS_NO_EXCEPTIONS']
+# Stack unwinding tests need unwinding tables and these are not
+# generated by default on all Targets.
+self.cxx.compile_flags += ['-funwind-tables']
if not self.get_lit_bool('enable_threads', True):
self.cxx.compile_flags += ['-D_LIBUNWIND_HAS_NO_THREADS']
self.config.available_features.add('libunwind-no-threads')
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
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 well as setting micro-architectural features of the
-mtune cpu, this will also add the architectural features such as support
for instructions. This can result in the backend using instructions that
are supported in the -mtune cpu but not supported in the target
architecture. For example use of the v8.1-a LSE extensions with -march=v8.
This change removes the setting of -target-cpu for -mtune, the -mcpu must
be used to set -target-cpu. This has the effect of removing all non-hard
coded benefits of mtune but it does produce correct output when -mtune cpu
with a later architecture than v8 is used.
Fixes PR34625
Differential Revision: https://reviews.llvm.org/D39179
Modified:
cfe/trunk/lib/Driver/ToolChains/Arch/AArch64.cpp
cfe/trunk/test/Driver/aarch64-cpus.c
Modified: cfe/trunk/lib/Driver/ToolChains/Arch/AArch64.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/Arch/AArch64.cpp?rev=316424=316423=316424=diff
==
--- cfe/trunk/lib/Driver/ToolChains/Arch/AArch64.cpp (original)
+++ cfe/trunk/lib/Driver/ToolChains/Arch/AArch64.cpp Tue Oct 24 02:51:55 2017
@@ -20,14 +20,12 @@ using namespace clang;
using namespace llvm::opt;
/// getAArch64TargetCPU - Get the (LLVM) name of the AArch64 cpu we are
-/// targeting. Set \p A to the Arg corresponding to the -mcpu or -mtune
-/// arguments if they are provided, or to nullptr otherwise.
+/// targeting. Set \p A to the Arg corresponding to the -mcpu argument if it is
+/// provided, or to nullptr otherwise.
std::string aarch64::getAArch64TargetCPU(const ArgList , Arg *) {
std::string CPU;
- // If we have -mtune or -mcpu, use that.
- if ((A = Args.getLastArg(clang::driver::options::OPT_mtune_EQ))) {
-CPU = StringRef(A->getValue()).lower();
- } else if ((A = Args.getLastArg(options::OPT_mcpu_EQ))) {
+ // If we have -mcpu, use that.
+ if ((A = Args.getLastArg(options::OPT_mcpu_EQ))) {
StringRef Mcpu = A->getValue();
CPU = Mcpu.split("+").first.lower();
}
@@ -122,6 +120,12 @@ getAArch64MicroArchFeaturesFromMtune(con
const ArgList ,
std::vector ) {
std::string MtuneLowerCase = Mtune.lower();
+ // Check CPU name is valid
+ std::vector MtuneFeatures;
+ StringRef Tune;
+ if (!DecodeAArch64Mcpu(D, MtuneLowerCase, Tune, MtuneFeatures))
+return false;
+
// Handle CPU name is 'native'.
if (MtuneLowerCase == "native")
MtuneLowerCase = llvm::sys::getHostCPUName();
Modified: cfe/trunk/test/Driver/aarch64-cpus.c
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/aarch64-cpus.c?rev=316424=316423=316424=diff
==
--- cfe/trunk/test/Driver/aarch64-cpus.c (original)
+++ cfe/trunk/test/Driver/aarch64-cpus.c Tue Oct 24 02:51:55 2017
@@ -21,165 +21,188 @@
// RUN: %clang -target aarch64 -mcpu=cortex-a35 -### -c %s 2>&1 | FileCheck
-check-prefix=CA35 %s
// RUN: %clang -target aarch64 -mlittle-endian -mcpu=cortex-a35 -### -c %s
2>&1 | FileCheck -check-prefix=CA35 %s
// RUN: %clang -target aarch64_be -mlittle-endian -mcpu=cortex-a35 -### -c %s
2>&1 | FileCheck -check-prefix=CA35 %s
-// RUN: %clang -target aarch64 -mtune=cortex-a35 -### -c %s 2>&1 | FileCheck
-check-prefix=CA35 %s
-// RUN: %clang -target aarch64 -mlittle-endian -mtune=cortex-a35 -### -c %s
2>&1 | FileCheck -check-prefix=CA35 %s
-// RUN: %clang -target aarch64_be -mlittle-endian -mtune=cortex-a35 -### -c %s
2>&1 | FileCheck -check-prefix=CA35 %s
+// RUN: %clang -target aarch64 -mtune=cortex-a35 -### -c %s 2>&1 | FileCheck
-check-prefix=CA35-TUNE %s
+// RUN: %clang -target aarch64 -mlittle-endian -mtune=cortex-a35 -### -c %s
2>&1 | FileCheck -check-prefix=CA35-TUNE %s
+// RUN: %clang -target aarch64_be -mlittle-endian -mtune=cortex-a35 -### -c %s
2>&1 | FileCheck -check-prefix=CA35-TUNE %s
// CA35: "-cc1"{{.*}} "-triple" "aarch64{{.*}}" "-target-cpu" "cortex-a35"
+// CA35-TUNE: "-cc1"{{.*}} "-triple" "aarch64{{.*}}" "-target-cpu" "generic"
// RUN: %clang -target arm64 -mcpu=cortex-a35 -### -c %s 2>&1 | FileCheck
-check-prefix=ARM64-CA35 %s
// RUN: %clang -target arm64 -mlittle-endian -mcpu=cortex-a35 -### -c %s 2>&1
| FileCheck -check-prefix=ARM64-CA35 %s
-// RUN: %clang -target arm64 -mtune=cortex-a35 -### -c %s 2>&1 | FileCheck
-check-prefix=ARM64-CA35 %s
-// RUN: %clang -target arm64 -mlittle-endian -mtune=cortex-a35 -### -c %s 2>&1
| FileCheck -check-prefix=ARM64-CA35 %s
+// RUN: %clang -target arm64 -mtune=cortex-a35 -### -c %s 2>&1 | FileCheck
-check-prefix=ARM64-CA35-TUNE %s
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:
cfe/trunk/test/CodeGen/arm-float-helpers.c
Modified:
cfe/trunk/lib/CodeGen/TargetInfo.cpp
cfe/trunk/test/CodeGen/complex-math.c
Modified: cfe/trunk/lib/CodeGen/TargetInfo.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/TargetInfo.cpp?rev=309263=309262=309263=diff
==
--- cfe/trunk/lib/CodeGen/TargetInfo.cpp (original)
+++ cfe/trunk/lib/CodeGen/TargetInfo.cpp Thu Jul 27 03:43:53 2017
@@ -5620,17 +5620,14 @@ void ARMABIInfo::setCCs() {
// AAPCS apparently requires runtime support functions to be soft-float, but
// that's almost certainly for historic reasons (Thumb1 not supporting VFP
// most likely). It's more convenient for AAPCS16_VFP to be hard-float.
- switch (getABIKind()) {
- case APCS:
- case AAPCS16_VFP:
-if (abiCC != getLLVMDefaultCC())
+
+ // The Run-time ABI for the ARM Architecture section 4.1.2 requires
+ // AEABI-complying FP helper functions to use the base AAPCS.
+ // These AEABI functions are expanded in the ARM llvm backend, all the
builtin
+ // support functions emitted by clang such as the _Complex helpers follow the
+ // abiCC.
+ if (abiCC != getLLVMDefaultCC())
BuiltinCC = abiCC;
-break;
- case AAPCS:
- case AAPCS_VFP:
-BuiltinCC = llvm::CallingConv::ARM_AAPCS;
-break;
- }
}
ABIArgInfo ARMABIInfo::classifyArgumentType(QualType Ty,
Added: cfe/trunk/test/CodeGen/arm-float-helpers.c
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/arm-float-helpers.c?rev=309263=auto
==
--- cfe/trunk/test/CodeGen/arm-float-helpers.c (added)
+++ cfe/trunk/test/CodeGen/arm-float-helpers.c Thu Jul 27 03:43:53 2017
@@ -0,0 +1,233 @@
+// REQUIRES: arm-registered-target
+// RUN: %clang_cc1 -emit-llvm -o - -triple arm-none-linux-gnueabi %s |
FileCheck %s
+// RUN: %clang_cc1 -emit-llvm -o - -triple arm-none-linux-gnueabihf %s |
FileCheck %s
+// RUN: %clang_cc1 -emit-llvm -o - -triple arm-none-linux-gnueabi
-target-feature "+soft-float" -target-feature "+soft-float-abi" %s | FileCheck
%s
+// RUN: %clang_cc1 -emit-llvm -o - -triple arm-none-linux-gnueabi
-target-feature "+soft-float" %s | FileCheck %s
+// RUN: %clang_cc1 -emit-llvm -o - -triple arm-none-eabi %s | FileCheck %s
+// RUN: %clang_cc1 -emit-llvm -o - -triple arm-none-eabi -meabi gnu %s |
FileCheck %s
+// RUN: %clang_cc1 -emit-llvm -o - -triple arm-none-eabi %s | FileCheck %s
+// RUN: %clang_cc1 -emit-llvm -o - -triple arm-none-eabi -target-feature
"+soft-float" -target-feature "+soft-float-abi" -meabi gnu %s | FileCheck %s
+// RUN: %clang_cc1 -emit-llvm -o - -triple arm-none-eabi -target-feature
"+soft-float" -meabi gnu %s | FileCheck %s
+// RUN: %clang_cc1 -emit-llvm -o - -triple arm-none-eabihf %s | FileCheck %s
+// RUN: %clang_cc1 -emit-llvm -o - -triple arm-none-eabihf -meabi gnu %s |
FileCheck %s
+
+// The Runtime ABI for the ARM Architecture IHI0043 section 4.1.2 The
+// floating-point helper functions to always use the base AAPCS (soft-float)
+// calling convention.
+//
+// These helper functions such as __aeabi_fadd are not explicitly called by
+// clang, instead they are generated by the ARMISelLowering when they are
+// needed; clang relies on llvm to use the base AAPCS.
+//
+// In this test we check that clang is not directly calling the __aeabi_
+// functions. We rely on llvm to test that the base AAPCS is used for any
+// __aeabi_ function from 4.1.2 that is used.
+//
+// When compiled to an object file with -mfloat-abi=soft each function F
+// below should result in a call to __aeabi_F. If clang is changed to call any
+// of these functions directly the test will need to be altered to check that
+// arm_aapcscc is used.
+//
+// Note that it is only the functions in 4.1.2 that must use the base AAPCS,
+// other runtime functions such as the _Complex helper routines are not
covered.
+
+float fadd(float a, float b) { return a + b; }
+// CHECK-LABEL: define float @fadd(float %a, float %b)
+// CHECK-NOT: __aeabi_fadd
+// CHECK: %add = fadd float {{.*}}, {{.*}}
+
+float fdiv(float a, float b) { return a / b; }
+// CHECK-LABEL: define float @fdiv(float %a, float %b)
+// CHECK-NOT: __aeabi_fdiv
+// CHECK: %div = fdiv float {{.*}}, {{.*}}
+
+float fmul(float a, float b) { return a * b; }
+// CHECK-LABEL: define float @fmul(float %a, float %b)
+// CHECK-NOT: __aeabi_fmul
+// CHECK: %mul = fmul float {{.*}}, {{.*}}
+
+float fsub(float a, float b) { return a - b; }
+// CHECK-LABEL: define float @fsub(float %a, float %b)
+// CHECK-NOT: __aeabi_fsub
+// CHECK: %sub = fsub float {{.*}}, {{.*}}
+
+int fcmpeq(float
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:
cfe/trunk/test/CodeGen/arm-float-helpers.c
Modified:
cfe/trunk/lib/CodeGen/TargetInfo.cpp
cfe/trunk/test/CodeGen/complex-math.c
Modified: cfe/trunk/lib/CodeGen/TargetInfo.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/TargetInfo.cpp?rev=309259=309258=309259=diff
==
--- cfe/trunk/lib/CodeGen/TargetInfo.cpp (original)
+++ cfe/trunk/lib/CodeGen/TargetInfo.cpp Thu Jul 27 02:57:13 2017
@@ -5620,14 +5620,17 @@ void ARMABIInfo::setCCs() {
// AAPCS apparently requires runtime support functions to be soft-float, but
// that's almost certainly for historic reasons (Thumb1 not supporting VFP
// most likely). It's more convenient for AAPCS16_VFP to be hard-float.
-
- // The Run-time ABI for the ARM Architecture section 4.1.2 requires
- // AEABI-complying FP helper functions to use the base AAPCS.
- // These AEABI functions are expanded in the ARM llvm backend, all the
builtin
- // support functions emitted by clang such as the _Complex helpers follow the
- // abiCC.
- if (abiCC != getLLVMDefaultCC())
+ switch (getABIKind()) {
+ case APCS:
+ case AAPCS16_VFP:
+if (abiCC != getLLVMDefaultCC())
BuiltinCC = abiCC;
+break;
+ case AAPCS:
+ case AAPCS_VFP:
+BuiltinCC = llvm::CallingConv::ARM_AAPCS;
+break;
+ }
}
ABIArgInfo ARMABIInfo::classifyArgumentType(QualType Ty,
Removed: cfe/trunk/test/CodeGen/arm-float-helpers.c
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/arm-float-helpers.c?rev=309258=auto
==
--- cfe/trunk/test/CodeGen/arm-float-helpers.c (original)
+++ cfe/trunk/test/CodeGen/arm-float-helpers.c (removed)
@@ -1,233 +0,0 @@
-// REQUIRES: arm-registered-target
-// RUN: %clang_cc1 -emit-llvm -o - -triple arm-none-linux-gnueabi %s |
FileCheck %s
-// RUN: %clang_cc1 -emit-llvm -o - -triple arm-none-linux-gnueabihf %s |
FileCheck %s
-// RUN: %clang_cc1 -emit-llvm -o - -triple arm-none-linux-gnueabi
-target-feature "+soft-float" -target-feature "+soft-float-abi" %s | FileCheck
%s
-// RUN: %clang_cc1 -emit-llvm -o - -triple arm-none-linux-gnueabi
-target-feature "+soft-float" %s | FileCheck %s
-// RUN: %clang_cc1 -emit-llvm -o - -triple arm-none-eabi %s | FileCheck %s
-// RUN: %clang_cc1 -emit-llvm -o - -triple arm-none-eabi -meabi gnu %s |
FileCheck %s
-// RUN: %clang_cc1 -emit-llvm -o - -triple arm-none-eabi %s | FileCheck %s
-// RUN: %clang_cc1 -emit-llvm -o - -triple arm-none-eabi -target-feature
"+soft-float" -target-feature "+soft-float-abi" -meabi gnu %s | FileCheck %s
-// RUN: %clang_cc1 -emit-llvm -o - -triple arm-none-eabi -target-feature
"+soft-float" -meabi gnu %s | FileCheck %s
-// RUN: %clang_cc1 -emit-llvm -o - -triple arm-none-eabihf %s | FileCheck %s
-// RUN: %clang_cc1 -emit-llvm -o - -triple arm-none-eabihf -meabi gnu %s |
FileCheck %s
-
-// The Runtime ABI for the ARM Architecture IHI0043 section 4.1.2 The
-// floating-point helper functions to always use the base AAPCS (soft-float)
-// calling convention.
-//
-// These helper functions such as __aeabi_fadd are not explicitly called by
-// clang, instead they are generated by the ARMISelLowering when they are
-// needed; clang relies on llvm to use the base AAPCS.
-//
-// In this test we check that clang is not directly calling the __aeabi_
-// functions. We rely on llvm to test that the base AAPCS is used for any
-// __aeabi_ function from 4.1.2 that is used.
-//
-// When compiled to an object file with -mfloat-abi=soft each function F
-// below should result in a call to __aeabi_F. If clang is changed to call any
-// of these functions directly the test will need to be altered to check that
-// arm_aapcscc is used.
-//
-// Note that it is only the functions in 4.1.2 that must use the base AAPCS,
-// other runtime functions such as the _Complex helper routines are not
covered.
-
-float fadd(float a, float b) { return a + b; }
-// CHECK-LABEL: define float @fadd(float %a, float %b)
-// CHECK-NOT: __aeabi_fadd
-// CHECK: %add = fadd float %0, %1
-
-float fdiv(float a, float b) { return a / b; }
-// CHECK-LABEL: define float @fdiv(float %a, float %b)
-// CHECK-NOT: __aeabi_fdiv
-// CHECK: %div = fdiv float %0, %1
-
-float fmul(float a, float b) { return a * b; }
-// CHECK-LABEL: define float @fmul(float %a, float %b)
-// CHECK-NOT: __aeabi_fmul
-// CHECK: %mul = fmul float %0, %1
-
-float fsub(float a, float b) { return a - b; }
-// CHECK-LABEL: define float @fsub(float %a, float %b)
-// CHECK-NOT: __aeabi_fsub
-// CHECK: %sub = fsub float %0, %1
-
-int fcmpeq(float a, float b) { return a == b; }
-// CHECK-LABEL:
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 floating-point helper functions. These
functions always use the base PCS (soft-fp). However helper functions
defined outside of this document such as the complex-number multiply and
divide helpers are not covered by this requirement and should use
hard-float PCS if the target is hard-float as both compiler-rt and libgcc
for a hard-float sysroot implement these functions with a hard-float PCS.
All of the floating point helper functions that are explicitly soft float
are expanded in the llvm ARM backend. This change makes clang not force the
BuiltinCC to AAPCS for AAPCS_VFP. With this change the ARM compiler-rt
tests involving _Complex pass with both hard-fp and soft-fp targets.
Differential Revision: https://reviews.llvm.org/D35538
Added:
cfe/trunk/test/CodeGen/arm-float-helpers.c
Modified:
cfe/trunk/lib/CodeGen/TargetInfo.cpp
cfe/trunk/test/CodeGen/complex-math.c
Modified: cfe/trunk/lib/CodeGen/TargetInfo.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/TargetInfo.cpp?rev=309257=309256=309257=diff
==
--- cfe/trunk/lib/CodeGen/TargetInfo.cpp (original)
+++ cfe/trunk/lib/CodeGen/TargetInfo.cpp Thu Jul 27 02:21:41 2017
@@ -5620,17 +5620,14 @@ void ARMABIInfo::setCCs() {
// AAPCS apparently requires runtime support functions to be soft-float, but
// that's almost certainly for historic reasons (Thumb1 not supporting VFP
// most likely). It's more convenient for AAPCS16_VFP to be hard-float.
- switch (getABIKind()) {
- case APCS:
- case AAPCS16_VFP:
-if (abiCC != getLLVMDefaultCC())
+
+ // The Run-time ABI for the ARM Architecture section 4.1.2 requires
+ // AEABI-complying FP helper functions to use the base AAPCS.
+ // These AEABI functions are expanded in the ARM llvm backend, all the
builtin
+ // support functions emitted by clang such as the _Complex helpers follow the
+ // abiCC.
+ if (abiCC != getLLVMDefaultCC())
BuiltinCC = abiCC;
-break;
- case AAPCS:
- case AAPCS_VFP:
-BuiltinCC = llvm::CallingConv::ARM_AAPCS;
-break;
- }
}
ABIArgInfo ARMABIInfo::classifyArgumentType(QualType Ty,
Added: cfe/trunk/test/CodeGen/arm-float-helpers.c
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/arm-float-helpers.c?rev=309257=auto
==
--- cfe/trunk/test/CodeGen/arm-float-helpers.c (added)
+++ cfe/trunk/test/CodeGen/arm-float-helpers.c Thu Jul 27 02:21:41 2017
@@ -0,0 +1,233 @@
+// REQUIRES: arm-registered-target
+// RUN: %clang_cc1 -emit-llvm -o - -triple arm-none-linux-gnueabi %s |
FileCheck %s
+// RUN: %clang_cc1 -emit-llvm -o - -triple arm-none-linux-gnueabihf %s |
FileCheck %s
+// RUN: %clang_cc1 -emit-llvm -o - -triple arm-none-linux-gnueabi
-target-feature "+soft-float" -target-feature "+soft-float-abi" %s | FileCheck
%s
+// RUN: %clang_cc1 -emit-llvm -o - -triple arm-none-linux-gnueabi
-target-feature "+soft-float" %s | FileCheck %s
+// RUN: %clang_cc1 -emit-llvm -o - -triple arm-none-eabi %s | FileCheck %s
+// RUN: %clang_cc1 -emit-llvm -o - -triple arm-none-eabi -meabi gnu %s |
FileCheck %s
+// RUN: %clang_cc1 -emit-llvm -o - -triple arm-none-eabi %s | FileCheck %s
+// RUN: %clang_cc1 -emit-llvm -o - -triple arm-none-eabi -target-feature
"+soft-float" -target-feature "+soft-float-abi" -meabi gnu %s | FileCheck %s
+// RUN: %clang_cc1 -emit-llvm -o - -triple arm-none-eabi -target-feature
"+soft-float" -meabi gnu %s | FileCheck %s
+// RUN: %clang_cc1 -emit-llvm -o - -triple arm-none-eabihf %s | FileCheck %s
+// RUN: %clang_cc1 -emit-llvm -o - -triple arm-none-eabihf -meabi gnu %s |
FileCheck %s
+
+// The Runtime ABI for the ARM Architecture IHI0043 section 4.1.2 The
+// floating-point helper functions to always use the base AAPCS (soft-float)
+// calling convention.
+//
+// These helper functions such as __aeabi_fadd are not explicitly called by
+// clang, instead they are generated by the ARMISelLowering when they are
+// needed; clang relies on llvm to use the base AAPCS.
+//
+// In this test we check that clang is not directly calling the __aeabi_
+// functions. We rely on llvm to test that the base AAPCS is used for any
+// __aeabi_ function from 4.1.2 that is used.
+//
+// When compiled to an object file with -mfloat-abi=soft each function F
+// below should result in a call to __aeabi_F. If clang is changed to call any
+// of these functions directly the test will need to be altered to check that
+// arm_aapcscc is used.
+//
+// Note that it is only the functions in 4.1.2 that must use the base AAPCS,
+// other runtime functions such as the _Complex
