Rust-GCC / Rust-GCC/gccrs

References are compared by pointer value, not according to their `PartialEq`/`PartialOrd` instances

Open
#4,537 4 comments 1 reaction 1 assignee View on GitHub

@dkm is already working on this.

Since Jul 9, 2026.

codegen
Dominant language
C++
Stars
2.9k
Forks
231
Avg merge
19h 55m
Merged PRs (30d)
67

Description

Summary

E. g. &str should be compared lexicographically, &u32 by dereferencing, etc. Trait objects (&dyn T) should not be comparable at all unless PartialEq or PartialOrd (depending on which comparison operator is used) is implemented for dyn T.

Reproducer

I tried this code:

#![feature(no_core)]
#![no_core]

#[inline(never)]
pub fn lt_ref(x: &u32, y: &u32) -> bool {
    x < y
}

#[inline(never)]
pub fn eq_str(s: &str) -> bool {
    s == "hello world"
}

trait T {}

#[inline(never)]
pub fn eq_trait_object(a: &dyn T, b: &dyn T) -> bool {
    a == b
}

pub fn main() -> i32 {
    let x = &42;
    let y = &27;
    lt_ref(x, y) as i32
}
Does the code make use of any (1.49) nightly feature ?
  • Nightly
Godbolt link

https://godbolt.org/z/qqvhTarz5

Actual behavior

The current behaviour is that comparisons on references are miscompiled.

  • lt_ref compiles to a cmp rdi, rsi, which compares the numerical pointer values of x and y.
  • eq_str is compiled to a componentwise comparison of the two components in the &str fat pointer: the pointer part and the length metadata.
  • eq_trait_object is compiled to a comparison of only the pointer part of the fat pointer, the vtable metadata is ignored.
  • main returns 1 because x has a smaller address than y.
Expected behavior

I expected to see that the code is compiled correctly (or not at all in the case of eq_trait_object because of the missing PartialEq impl).

GCC Version

679aad3804e8443ec5181fd184785d82aec42bdf

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.