@@ -90,35 +90,6 @@ pub type uint64_t = u64;
90
90
91
91
cfg_if ! {
92
92
if #[ cfg( all( target_arch = "aarch64" , not( target_os = "windows" ) ) ) ] {
93
- // This introduces partial support for FFI with __int128 and
94
- // equivalent types on platforms where Rust's definition is validated
95
- // to match the standard C ABI of that platform.
96
- //
97
- // Rust does not guarantee u128/i128 are sound for FFI, and its
98
- // definitions are in fact known to be incompatible. [0]
99
- //
100
- // However these problems aren't fundamental, and are just platform
101
- // inconsistencies. Specifically at the time of this writing:
102
- //
103
- // * For x64 SysV ABIs (everything but Windows), the types are underaligned.
104
- // * For all Windows ABIs, Microsoft doesn't actually officially define __int128,
105
- // and as a result different implementations don't actually agree on its ABI.
106
- //
107
- // But on the other major aarch64 platforms (android, linux, ios, macos) we have
108
- // validated that rustc has the right ABI for these types. This is important because
109
- // aarch64 uses these types in some fundamental OS types like user_fpsimd_struct,
110
- // which represents saved simd registers.
111
- //
112
- // Any API which uses these types will need to `#[ignore(improper_ctypes)]`
113
- // until the upstream rust issue is resolved, but this at least lets us make
114
- // progress on platforms where this type is important.
115
- //
116
- // The list of supported architectures and OSes is intentionally very restricted,
117
- // as careful work needs to be done to verify that a particular platform
118
- // has a conformant ABI.
119
- //
120
- // [0]: https://github.com/rust-lang/rust/issues/54341
121
-
122
93
/// C `__int128` (a GCC extension that's part of many ABIs)
123
94
pub type __int128 = i128 ;
124
95
/// C `unsigned __int128` (a GCC extension that's part of many ABIs)
@@ -127,40 +98,5 @@ cfg_if! {
127
98
pub type __int128_t = i128 ;
128
99
/// C __uint128_t (alternate name for [__uint128][])
129
100
pub type __uint128_t = u128 ;
130
-
131
- // NOTE: if you add more platforms to here, you may need to cfg
132
- // these consts. They should always match the platform's values
133
- // for `sizeof(__int128)` and `_Alignof(__int128)`.
134
- const _SIZE_128: usize = 16 ;
135
- const _ALIGN_128: usize = 16 ;
136
-
137
- // FIXME(ctest): ctest doesn't handle `_` as an identifier so these tests are temporarily
138
- // disabled.
139
- // macro_rules! static_assert_eq {
140
- // ($a:expr, $b:expr) => {
141
- // const _: [(); $a] = [(); $b];
142
- // };
143
- // }
144
- //
145
- // // Since Rust doesn't officially guarantee that these types
146
- // // have compatible ABIs, we const assert that these values have the
147
- // // known size/align of the target platform's libc. If rustc ever
148
- // // tries to regress things, it will cause a compilation error.
149
- // //
150
- // // This isn't a bullet-proof solution because e.g. it doesn't
151
- // // catch the fact that llvm and gcc disagree on how x64 __int128
152
- // // is actually *passed* on the stack (clang underaligns it for
153
- // // the same reason that rustc *never* properly aligns it).
154
- // static_assert_eq!(size_of::<__int128>(), _SIZE_128);
155
- // static_assert_eq!(align_of::<__int128>(), _ALIGN_128);
156
-
157
- // static_assert_eq!(size_of::<__uint128>(), _SIZE_128);
158
- // static_assert_eq!(align_of::<__uint128>(), _ALIGN_128);
159
-
160
- // static_assert_eq!(size_of::<__int128_t>(), _SIZE_128);
161
- // static_assert_eq!(align_of::<__int128_t>(), _ALIGN_128);
162
-
163
- // static_assert_eq!(size_of::<__uint128_t>(), _SIZE_128);
164
- // static_assert_eq!(align_of::<__uint128_t>(), _ALIGN_128);
165
101
}
166
102
}
0 commit comments