Tracking issue for 128-bit integer support (RFC 1504)

[nikomatsakis]

Tracking issue for rust-lang/rfcs#1504.

cc @Amanieu

Blocking stabilization:

• Casting u128::MAX to f32 is undefined #41799 (Casting u128::MAX to f32 is undefined)
• Interaction with FFI? (Tracking issue for 128-bit integer support (RFC 1504) #35118 (comment)) - rustc: Flag {i,u}128 as unsafe for FFI #44261
• separately feature gate repr(i128) - rustc: Separately feature gate repr(i128) #44262
• Implement i128 lowering for backends without stable i128 support  #45676 (u/i)128 lowering for backends without native support
  • lowering still does not work for emscripten even with the work around
• Enums with 128-bit discriminant: repr128 feature

[durka]

Is #[repr(u128)] enum SuchWideVeryDiscriminantWow { ... } allowed?

[Amanieu]

That's a good point, I don't see any reason why it shouldn't be allowed.

[durka]

The return type of the discriminant_value intrinsic needs to be updated, then :)

[nagisa]

Intrinsics are stuff internal to the compiler, therefore changes to them doesn’t need discussion in the RFCs.

[durka]

I know, I just wanted to mention it here since I didn't see enums discussed in the RFC.

[emberian]

How should FFI with this type be handled? Is there any standard ABI support for these types? AFAICT, the answer is "no", which means this type should be FFI-unsafe, and the FFI unsafety lint should be updated to reject Ty{I,Ui}nt with 128-bit sizes.

[emberian]

cc @est31

[retep998]

On Windows there is most definitely no standard i128 yet because the standard compiler (msvc) does not support __int128 yet on x86. There are some really good guesses though based on the MSDN documentation.

[est31]

Is there any standard ABI support for these types?

It depends on the architecture. SysV defines the ABI for 64 bit architectures. For x86, its most likely its not defined. Same goes for windows: it should in theory be defined for 64 bit (just sadly nobody adheres to it, its a gigantic mess), but not on x86.

This directly maps the support of the i128 type in C, and I think generally it makes little sense to have FFI for types that don't exist in C.

[est31]

bug report in llvm about the x86_64 ABI problems: https://llvm.org/bugs/show_bug.cgi?id=31362

[nagisa]

Also one in GCC: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78799

[mark-i-m]

I think this is done 🎉

[est31]

@mark-i-m congrats!

Just don't close this issue yet as like @durka pointed out, the repr128 feature is still pointing to this tracking issue.

[mark-i-m]

Could someone update the OP too create more check boxes for repr128?

[ebfull]

The checkbox for #45676 is checked in this issue but #45676 is not actually closed. What's the status of lowering on other platforms?

[nagisa]

I think that is fixed, although not in the nicest way. I closed the issue.

[est31]

@ebfull see my comment here: #35118 (comment)

i128 works on the entire x86 family as well as the ARM family. This covers all of the tier 1 platforms.
The platforms where we lack i128 support are tier 2 or 3.

What you are doing in zkcrypto/pairing#80 is exactly what I wanted to prevent by blocking stabilisation until all platforms support i128 lol, but people thought otherwise.

[ebfull]

@est31 I'm not doing zkcrypto/pairing#80 until it works on all platforms, which I mention in that issue. In the mean time all I will do is remove the i128_type feature flag, but still require users to opt into usage of u128.

[est31]

@ebfull not blaming you. I'm partially blaming myself, thought that lowering worked already. Partially I'm blaming those people who decided to stabilize before all platforms support it. And the backend vendors who refuse to take {u,i}128 seriously.

Sadly, this is more of a "stable beta" release of i128 than an arrival of a feature that can be relied upon.

[hdevalence]

It would be nice if there was a (documented) way to set a cargo feature as the default on a given architecture. From what I can tell this isn't quite possible, since the architecture-selection code happens with #[cfg(...)]s while the crate is being compiled, by which point the crate's features are already selected. Am I missing something?

The motivation is that even if u128s are available, it may not be desirable to use them, unless they actually correspond to instructions available on that platform.

[durka]

You can set cfg flags from the build script.

…

On Sun, Apr 1, 2018 at 7:19 PM, Henry de Valence ***@***.***> wrote: It would be nice if there was a (documented) way to set a cargo feature as the default on a given architecture. From what I can tell this isn't quite possible, since the architecture-selection code happens with #[cfg(...)]s while the crate is being compiled, by which point the crate's features are already selected. Am I missing something? The motivation is that even if u128s are available, it may not be desirable to use them, unless they actually correspond to instructions available on that platform. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#35118 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAC3n0sF6mXohDEJzN0dV2ggaYT631BTks5tkWB7gaJpZM4JYhaE> .

[Centril]

@mark-i-m any developments re. repr128?

[mark-i-m]

Not that I'm aware of... but I just did the stabilization. I'm not sure if if anyone has claimed ownership of that task yet...

[Centril]

@mark-i-m aw; bummer :(

Let me try some one else at random...

@nagisa 👋

[nagisa]

Nothing has changed re repr128… It is still the case that at least LLVM’s debuginfo API blocks us from implementing it at all. There’s very little incentive to work on it, though, and I’m not planning to do anything in that direction until a very convincing use-case for 128-bit enum discriminants comes up.

EDIT: That, or if days suddenly become 48-hour long.

[Centril]

Closing this in favor of the targeted issue #56071 since all remaining work has been done.