cfi: mangle `f128` as `e` rather than `g` on platforms without `_Float128` by cezarbbb · Pull Request #163193 · rust-lang/rust

cezarbbb · 2026-09-23T04:01:35Z

On the Linux platform, only x86 and x86_64 support Float128. (see https://github.com/llvm/llvm-project/blob/bd5b1f58ae58cceab2cadb882cceb1d96f4ad33e/clang/lib/Basic/Targets/OSTargets.h#L431)
Therefore, for aarch64, the f128 type corresponds exclusively to long double.
In addition, aarch64 does not overload getLongDoubleMangling and getFloat128Mangling.(see https://github.com/llvm/llvm-project/blob/bd5b1f58ae58cceab2cadb882cceb1d96f4ad33e/clang/include/clang/Basic/TargetInfo.h#L822)
Therefore, aarch64 on Linux should send e instead of g.

For Windows and Apple aarch64, the long double type is 64-bit, so these targets need to be excluded.

The corresponding tests are added.

LLM disclosure: This commit is entirely handwritten.

r? @tgross35

rustbot · 2026-09-23T04:01:38Z

Some changes occurred in compiler/rustc_sanitizers

cc @rcvalle

Some changes occurred in tests/codegen-llvm/sanitizer

cc @rcvalle

rustbot · 2026-09-23T04:01:41Z

tgross35 is currently at their maximum review capacity.
They may take a while to respond.

tgross35 · 2026-09-23T11:13:53Z

Does Clang encode _Float128 as e as well on the target?

tgross35 · 2026-09-23T11:16:09Z

+                    // `f128` is long double (`e`) only where that's 128-bit; Apple/Windows aarch64
+                    // use a 64-bit `long double` and fall through to `g` (`_Float128`, absent there).
+                    Arch::AArch64
+                        if !tcx.sess.target.is_like_darwin && !tcx.sess.target.is_like_windows =>
+                    {
+                        "e"
+                    }


This logic should probably go in impl Target as is_long_double_f128 with a FIXME to change to long_double_type(...) -> rustc_abi::Float, since I know we'll eventually be reusing this logic.

View changes since the review

Applied. Agreed with your opinion, this logic might reused by PAC.

cezarbbb · 2026-09-24T01:03:34Z

Does Clang encode _Float128 as e as well on the target?

aarch64 on the Linux platform doesn't have a float128 type at all, so situations like Clang encoding _Float128 as e just don't happen.

tgross35 · 2026-10-02T05:55:02Z

+    pub fn is_long_double_f128(&self) -> bool {
+        self.arch == Arch::AArch64 && !self.is_like_darwin && !self.is_like_windows
+    }


match self.arch { Arch::AArch64 => !self.is_like_darwin && !self.is_like_windows, Arch::RiscV32 => true, Arch::RiscV64 => true, Arch::S390x => true, _ => false, }

Referencing my research at #140417.

View changes since the review

Thank you very much, I have reviewed the implementation in #140417. I identified two issues: first, support for loongarch64 was not taken into account; second, regarding s390x, although it should use 'e', it was explicitly overridden to 'g'. If the current function were used, it would incorrectly emit 'e', so it needs to be explicitly excluded. (Additionally, while s390x does not currently support CFI, I believe this case should still be considered, given that the current function might be reused for PAC in the future.)

Sorry to do this, but would you mind deleting this function and going back to what you had? I thought this always corresponded to long double === _Float128, but if that's not the case then I think it's better to just inline.

Done, it's inline now.

tgross35 · 2026-10-02T05:55:57Z

@@ -473,6 +472,7 @@ pub(crate) fn encode_ty<'tcx>(
                FloatTy::F64 => "d",
                FloatTy::F128 => match tcx.sess.target.arch {
                    Arch::PowerPC | Arch::PowerPC64 => "u9__ieee128", // "g" is used for __ibm128
+                    _ if tcx.sess.target.is_long_double_f128() => "e",


Please add a small note that Clang is more friendly toward long double, and not all platforms support _Float128

View changes since the review

rustbot · 2026-10-02T05:56:11Z

Reminder, once the PR becomes ready for a review, use @rustbot ready.

tgross35 · 2026-10-09T06:51:10Z

@@ -473,6 +472,14 @@ pub(crate) fn encode_ty<'tcx>(
                FloatTy::F64 => "d",
                FloatTy::F128 => match tcx.sess.target.arch {
                    Arch::PowerPC | Arch::PowerPC64 => "u9__ieee128", // "g" is used for __ibm128
+                    Arch::S390x => "g", // On s390x, `f128` corresponds to `long double`, but the psABI specifies `g` as its mangling code.


Drop this one since it will hit the fallback, then LGTM

View changes since the review

Sure. Already deleted.

cezarbbb · 2026-10-09T08:27:40Z

@rustbot ready

tgross35

Thanks!

@bors r+ rollup

View changes since this review

rust-bors · 2026-10-09T09:23:37Z

📌 Commit 200fefd has been approved by tgross35

It is now in the queue for this repository.

@tgross35

…oss35 cfi: mangle `f128` as `e` rather than `g` on platforms without `_Float128` On the Linux platform, only `x86` and `x86_64` support `Float128`. (see https://github.com/llvm/llvm-project/blob/bd5b1f58ae58cceab2cadb882cceb1d96f4ad33e/clang/lib/Basic/Targets/OSTargets.h#L431) Therefore, for aarch64, the `f128` type corresponds exclusively to `long double`. In addition, `aarch64` does not overload `getLongDoubleMangling` and `getFloat128Mangling`.(see https://github.com/llvm/llvm-project/blob/bd5b1f58ae58cceab2cadb882cceb1d96f4ad33e/clang/include/clang/Basic/TargetInfo.h#L822) Therefore, `aarch64` on Linux should send `e` instead of `g`. For Windows and Apple `aarch64`, the `long double` type is 64-bit, so these targets need to be excluded. The corresponding tests are added. LLM disclosure: This commit is entirely handwritten. r? @tgross35

@tgross35

…oss35 cfi: mangle `f128` as `e` rather than `g` on platforms without `_Float128` On the Linux platform, only `x86` and `x86_64` support `Float128`. (see https://github.com/llvm/llvm-project/blob/bd5b1f58ae58cceab2cadb882cceb1d96f4ad33e/clang/lib/Basic/Targets/OSTargets.h#L431) Therefore, for aarch64, the `f128` type corresponds exclusively to `long double`. In addition, `aarch64` does not overload `getLongDoubleMangling` and `getFloat128Mangling`.(see https://github.com/llvm/llvm-project/blob/bd5b1f58ae58cceab2cadb882cceb1d96f4ad33e/clang/include/clang/Basic/TargetInfo.h#L822) Therefore, `aarch64` on Linux should send `e` instead of `g`. For Windows and Apple `aarch64`, the `long double` type is 64-bit, so these targets need to be excluded. The corresponding tests are added. LLM disclosure: This commit is entirely handwritten. r? @tgross35

…uwer Rollup of 14 pull requests Successful merges: - #162652 (Syntactically reject leading parenthesized precise capturing lists in bare trait object types (`(use<…>)+`)) - #163337 (MIR move elimination [3/6]: PreciseLiveness) - #163954 (fix(bootstrap/darwin): fix rpath for distributed LLD) - #163193 (cfi: mangle `f128` as `e` rather than `g` on platforms without `_Float128`) - #163634 (move overflow lint computation into decorator) - #163666 (Updates the expect message library/core/src/time.rs) - #163727 (rigid aliases to non-rigid for fully normalized check) - #163745 (replace `fully_monomorphized` with `cx.typing_env()`) - #163912 (Fix debug assert failure in `note_obligation_cause_code_inner`) - #163972 (const-eval: ICE when we hit a non-const fn) - #164000 (When mentioning that closure doesn't implement trait, point at closure) - #164007 ([rustdoc] Prefer local paths over remote ones when foreign item is locally reexported) - #164017 (cg_llvm: Avoid some explicit casts to `*const c_char`) - #164025 (Less `CanonicalVarValues`)

See rust-lang#163193 for context.

@tgross35

…oss35 cfi: mangle `f128` as `e` rather than `g` on platforms without `_Float128` On the Linux platform, only `x86` and `x86_64` support `Float128`. (see https://github.com/llvm/llvm-project/blob/bd5b1f58ae58cceab2cadb882cceb1d96f4ad33e/clang/lib/Basic/Targets/OSTargets.h#L431) Therefore, for aarch64, the `f128` type corresponds exclusively to `long double`. In addition, `aarch64` does not overload `getLongDoubleMangling` and `getFloat128Mangling`.(see https://github.com/llvm/llvm-project/blob/bd5b1f58ae58cceab2cadb882cceb1d96f4ad33e/clang/include/clang/Basic/TargetInfo.h#L822) Therefore, `aarch64` on Linux should send `e` instead of `g`. For Windows and Apple `aarch64`, the `long double` type is 64-bit, so these targets need to be excluded. The corresponding tests are added. LLM disclosure: This commit is entirely handwritten. r? @tgross35

…uwer Rollup of 14 pull requests Successful merges: - #162652 (Syntactically reject leading parenthesized precise capturing lists in bare trait object types (`(use<…>)+`)) - #163337 (MIR move elimination [3/6]: PreciseLiveness) - #163954 (fix(bootstrap/darwin): fix rpath for distributed LLD) - #163193 (cfi: mangle `f128` as `e` rather than `g` on platforms without `_Float128`) - #163634 (move overflow lint computation into decorator) - #163666 (Updates the expect message library/core/src/time.rs) - #163727 (rigid aliases to non-rigid for fully normalized check) - #163745 (replace `fully_monomorphized` with `cx.typing_env()`) - #163912 (Fix debug assert failure in `note_obligation_cause_code_inner`) - #163950 (don't treat inherited opaques as defining) - #164000 (When mentioning that closure doesn't implement trait, point at closure) - #164007 ([rustdoc] Prefer local paths over remote ones when foreign item is locally reexported) - #164017 (cg_llvm: Avoid some explicit casts to `*const c_char`) - #164025 (Less `CanonicalVarValues`)

…uwer Rollup of 24 pull requests Successful merges: - #161998 ( Support type-relative assoc item paths in generic param defaults & const param types) - #162106 (Helpful suggestions for incorrect address-of mutability (2)) - #162652 (Syntactically reject leading parenthesized precise capturing lists in bare trait object types (`(use<…>)+`)) - #163337 (MIR move elimination [3/6]: PreciseLiveness) - #163938 (-Zassumptions-on-binders: rewrite alias outlives constraints more goodly) - #163939 (Better debug impls for some assumptions on binders types) - #163954 (fix(bootstrap/darwin): fix rpath for distributed LLD) - #163956 (Pass the unremapped path to the `rustc` invocation for doctests) - #164042 (Allow testing cg-gcc on any target) - #162443 (Do not retain `Normalization` goal errors in nested goals for `BestObligationVisitor:: non_trivial_candidates `) - #162908 (Fix - const parameters rejected when identical) - #163193 (cfi: mangle `f128` as `e` rather than `g` on platforms without `_Float128`) - #163634 (move overflow lint computation into decorator) - #163666 (Updates the expect message library/core/src/time.rs) - #163727 (rigid aliases to non-rigid for fully normalized check) - #163745 (replace `fully_monomorphized` with `cx.typing_env()`) - #163912 (Fix debug assert failure in `note_obligation_cause_code_inner`) - #163950 (don't treat inherited opaques as defining) - #163972 (const-eval: ICE when we hit a non-const fn) - #164000 (When mentioning that closure doesn't implement trait, point at closure) - #164007 ([rustdoc] Prefer local paths over remote ones when foreign item is locally reexported) - #164008 (properly ignore the current goal's usages) - #164017 (cg_llvm: Avoid some explicit casts to `*const c_char`) - #164025 (Less `CanonicalVarValues`)

@tgross35

Rollup merge of #163193 - cezarbbb:pac-f128-aarch64-e, r=tgross35 cfi: mangle `f128` as `e` rather than `g` on platforms without `_Float128` On the Linux platform, only `x86` and `x86_64` support `Float128`. (see https://github.com/llvm/llvm-project/blob/bd5b1f58ae58cceab2cadb882cceb1d96f4ad33e/clang/lib/Basic/Targets/OSTargets.h#L431) Therefore, for aarch64, the `f128` type corresponds exclusively to `long double`. In addition, `aarch64` does not overload `getLongDoubleMangling` and `getFloat128Mangling`.(see https://github.com/llvm/llvm-project/blob/bd5b1f58ae58cceab2cadb882cceb1d96f4ad33e/clang/include/clang/Basic/TargetInfo.h#L822) Therefore, `aarch64` on Linux should send `e` instead of `g`. For Windows and Apple `aarch64`, the `long double` type is 64-bit, so these targets need to be excluded. The corresponding tests are added. LLM disclosure: This commit is entirely handwritten. r? @tgross35

rustbot added PG-exploit-mitigations Project group: Exploit mitigations S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Sep 23, 2026

rustbot assigned tgross35 Sep 23, 2026

This comment has been minimized.

Sign in to view

cezarbbb mentioned this pull request Sep 23, 2026

[PAC] Fn ptr type discrimination tests (8/8) #159087

Open

cezarbbb force-pushed the pac-f128-aarch64-e branch from 78318cd to 52e6e34 Compare September 23, 2026 06:14

tgross35 reviewed Sep 23, 2026

View reviewed changes

cezarbbb force-pushed the pac-f128-aarch64-e branch from 52e6e34 to 6c97266 Compare September 24, 2026 01:44

tgross35 requested changes Oct 2, 2026

View reviewed changes

rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Oct 2, 2026

cezarbbb force-pushed the pac-f128-aarch64-e branch 2 times, most recently from a2dcc03 to 856a041 Compare October 9, 2026 06:19

fix f128 on aarch64 Linux incorrectly sends g

200fefd

cezarbbb force-pushed the pac-f128-aarch64-e branch from 856a041 to 7dd5566 Compare October 9, 2026 06:44

tgross35 reviewed Oct 9, 2026

View reviewed changes

cezarbbb force-pushed the pac-f128-aarch64-e branch from 7dd5566 to 200fefd Compare October 9, 2026 07:00

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Oct 9, 2026

tgross35 changed the title ~~Fix f128 on aarch64 Linux incorrectly sends g~~ cfi: mangle f128 as e rather than g on platforms without _Float128 Oct 9, 2026

tgross35 approved these changes Oct 9, 2026

View reviewed changes

rust-bors Bot added the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label Oct 9, 2026

rust-bors Bot removed the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Oct 9, 2026

JonathanBrouwer mentioned this pull request Oct 9, 2026

Rollup of 14 pull requests #164026

Closed

JonathanBrouwer mentioned this pull request Oct 9, 2026

Rollup of 14 pull requests #164027

Closed

jchlanda added a commit to jchlanda/rust that referenced this pull request Oct 9, 2026

[PAC] Encode f128 as e, not g for platforms without _Float128

0e8c557

See rust-lang#163193 for context.

JonathanBrouwer mentioned this pull request Oct 9, 2026

Rollup of 14 pull requests #164039

Closed

JonathanBrouwer mentioned this pull request Oct 9, 2026

Rollup of 24 pull requests #164052

Merged

rust-bors Bot merged commit 0dddb3c into rust-lang:main Oct 9, 2026
14 checks passed

rustbot added this to the 1.101.0 milestone Oct 9, 2026

Conversation

cezarbbb commented Sep 23, 2026

Uh oh!

rustbot commented Sep 23, 2026

Uh oh!

rustbot commented Sep 23, 2026

Uh oh!

This comment has been minimized.

tgross35 commented Sep 23, 2026

Uh oh!

tgross35 Sep 23, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

cezarbbb Sep 24, 2026

Choose a reason for hiding this comment

Uh oh!

cezarbbb commented Sep 24, 2026

Uh oh!

tgross35 Oct 2, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

cezarbbb Oct 8, 2026

Choose a reason for hiding this comment

Uh oh!

tgross35 Oct 9, 2026

Choose a reason for hiding this comment

Uh oh!

cezarbbb Oct 9, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

tgross35 Oct 2, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

cezarbbb Oct 9, 2026

Choose a reason for hiding this comment

Uh oh!

rustbot commented Oct 2, 2026

Uh oh!

tgross35 Oct 9, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

cezarbbb Oct 9, 2026

Choose a reason for hiding this comment

Uh oh!

cezarbbb commented Oct 9, 2026

Uh oh!

tgross35 left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rust-bors Bot commented Oct 9, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

tgross35 Sep 23, 2026 •

edited by rustbot

Loading

tgross35 Oct 2, 2026 •

edited by rustbot

Loading

tgross35 Oct 2, 2026 •

edited by rustbot

Loading

tgross35 Oct 9, 2026 •

edited by rustbot

Loading

tgross35 left a comment •

edited by rustbot

Loading