Invalid ABI errors for `extern` blocks

[CohenArthur]

gccrs is currently erroring out on two extern blocks in core_arch which are needed for core 1.49:

 extern "platform-intrinsic" {
	    //pub fn simd_select_bitmask
    pub fn simd_eq<T, U>(x: T, y: T) -> U;
    pub fn simd_ne<T, U>(x: T, y: T) -> U;
    pub fn simd_lt<T, U>(x: T, y: T) -> U;
    pub fn simd_le<T, U>(x: T, y: T) -> U;
    pub fn simd_gt<T, U>(x: T, y: T) -> U;
    pub fn simd_ge<T, U>(x: T, y: T) -> U;
}
	
#[allow(improper_ctypes)]
extern "unadjusted" {
    #[link_name = "llvm.x86.rdrand.16"]
    fn x86_rdrand16_step() -> (u16, i32);
    #[link_name = "llvm.x86.rdrand.32"]
    fn x86_rdrand32_step() -> (u32, i32);
    #[link_name = "llvm.x86.rdseed.16"]
    fn x86_rdseed16_step() -> (u16, i32);
    #[link_name = "llvm.x86.rdseed.32"]
    fn x86_rdseed32_step() -> (u32, i32);
}

the expected behavior is no error. we need to eventually handle these ABIs properly, but for now we should at least recognize them so we can get through lowering

[Polygonalr]

I can take this issue

[philberty]

We will need to implement these intrinsics the usual way in rust-compile-intrinsic.cc for a starting point you could just expand:

    if (fntype->get_abi () == ABI::INTRINSIC)
      {
	Intrinsics compile (ctx);
	tree fndecl = compile.compile (fntype, ref_locus);
	ctx->insert_function_decl (fntype, fndecl);
	return;
      }

to include those 2 new ABI's and then we can implement them handy enough i reckon the usual way

[philberty]

see rust-compile-extern.h

[philberty]

we also also missing this in c-family/c-common.cc:

#define DEF_BUILTIN(ENUM, NAME, CLASS, TYPE, LIBTYPE, BOTH_P, FALLBACK_P, \
		    NONANSI_P, ATTRS, IMPLICIT, COND)			\
  if (NAME && COND)							\
    def_builtin_1 (ENUM, NAME, CLASS,                                   \
		   builtin_types[(int) TYPE],                           \
		   builtin_types[(int) LIBTYPE],                        \
		   BOTH_P, FALLBACK_P, NONANSI_P,                       \
		   built_in_attributes[(int) ATTRS], IMPLICIT);
#include "builtins.def"

  targetm.init_builtins ();

we need those targm.init_builtins for these then we need to find a way to expose target specific builtins into our rust-compile-intrinsic stuff

[philberty]

hmm then need to find the right hook to lookup target specific builtins... hmm yeah shit

we either:

#[link_name = "llvm.x86.rdrand.16"]
    fn x86_rdrand16_step() -> (u16, i32);

make a mapping of these to what the target specific builtin code will be like gcc/config/i386/i386-builtins.h or maybe change that link_name to be something more useful to us...

[CohenArthur]

Here's a patch for the lowering part at least:

From e7c252e64ba71186ba15767d0ef7bba214ebe982 Mon Sep 17 00:00:00 2001
From: Arthur Cohen <arthur.cohen@embecosm.com>
Date: Wed, 19 Aug 2026 15:55:47 +0200
Subject: [PATCH] lower unhandled ABIs properly

---
 gcc/rust/util/rust-abi.cc | 4 ++++
 gcc/rust/util/rust-abi.h  | 2 ++
 2 files changed, 6 insertions(+)

diff --git a/gcc/rust/util/rust-abi.cc b/gcc/rust/util/rust-abi.cc
index d17402e163e..3f3e1d2c34a 100644
--- a/gcc/rust/util/rust-abi.cc
+++ b/gcc/rust/util/rust-abi.cc
@@ -29,6 +29,10 @@ get_abi_from_string (const std::string &abi)
     return Rust::ABI::RUST;
   else if (abi.compare ("rust-intrinsic") == 0)
     return Rust::ABI::INTRINSIC;
+  else if (abi.compare ("platform-intrinsic") == 0)
+    return Rust::ABI::PLATFORM_INTRINSIC;
+  else if (abi.compare ("unadjusted") == 0)
+    return Rust::ABI::UNADJUSTED;
   else if (abi.compare ("C") == 0)
     return Rust::ABI::C;
   else if (abi.compare ("cdecl") == 0)
diff --git a/gcc/rust/util/rust-abi.h b/gcc/rust/util/rust-abi.h
index 357a5db95ff..a97a7f54ace 100644
--- a/gcc/rust/util/rust-abi.h
+++ b/gcc/rust/util/rust-abi.h
@@ -26,6 +26,8 @@ enum ABI
   UNKNOWN,
   RUST,
   INTRINSIC,
+  PLATFORM_INTRINSIC,
+  UNADJUSTED,
   C,
   CDECL,
   STDCALL,
-- 
2.50.1

with this added to the compiler, we get through lowering and reach typechecking issues

[philberty]

now that we have repr simd support we create GCC VECTOR_TYPE's and the regular EQ build statements will work for vectors just fine i think so those top intrinsics are simple to knock out could follow arthurs convention where we have a generic handler and pass a different tree code down for each permutation. The other intrinsics are more awkward

[CohenArthur]

Closed by #4802