Float CmpResult seems to be of the wrong type

[antoyo]

Hi.
I'm currently trying to make some new f128 tests pass for cg_gcc and I believe I found out the issue: it seems the CmpResult type is aliased wrongly to i32 while it should be aliased to i64 (or at least long) on x86-64.

The type is defined here as a i32 while the comment just above point to this that mentions that it should be a long.

Could you please double-check that it indeed should be a long and not a i32?

It seems like it should be a int on Aarch64, according to the LLVM code linked above.

Thanks.

[tgross35]

That's interesting, agreed that it should be a long. I'll update to match LLVM's logic here. I tried to double check against GCC but the exact logic is a bit hidden behind the __libgcc_cmp_return__ mode and I have no idea where that is actually getting set https://github.com/search?q=repo%3Agcc-mirror%2Fgcc+%2Flibgcc_cmp_return_mode%2F+path%3Agcc&type=code.

Out of curiosity, how did you notice the difference here? I guess if LLVM only reads the lower bits of the return but GCC checks the whole register, that would be visible.

[antoyo]

Out of curiosity, how did you notice the difference here? I guess if LLVM only reads the lower bits of the return but GCC checks the whole register, that would be visible.

In cg_gcc, I saw the following instruction to check the result:

test    rax, rax

while cg_llvm had:

test    eax, eax

I tried to double check against GCC but the exact logic is a bit hidden behind the __libgcc_cmp_return__ mode and I have no idea where that is actually getting set

From a quick glance, this is a target hook that can be overwritten by the backend (see here for Aarch64 for instance).
The default value seems to be defined here.

Thanks!

[tgross35]

Oh, so I guess my searches just didn't find anything because GH doesn't index the 30k line GCC target files :)

Posted a fix in #920, would you mind reviewing?

[beetrees]

Inconsistent with the compilers, the GCC docs list int as the return type for the comparison functions.

[tgross35]

For completeness, I checked for other overrides. Doesn't seem like anything other than aarch64 uses anything different:

// src/gcc/gcc/targhooks.cc
scalar_int_mode
default_libgcc_cmp_return_mode (void)
{
  return word_mode;
}

// src/gcc/gcc/config/aarch64/aarch64.cc
#undef TARGET_LIBGCC_CMP_RETURN_MODE
#define TARGET_LIBGCC_CMP_RETURN_MODE aarch64_libgcc_cmp_return_mode

static scalar_int_mode
aarch64_libgcc_cmp_return_mode (void)
{
  return SImode;
}

// src/gcc/gcc/config/rs6000/rs6000.cc
#undef TARGET_LIBGCC_CMP_RETURN_MODE
#define TARGET_LIBGCC_CMP_RETURN_MODE rs6000_abi_word_mode

static scalar_int_mode
rs6000_abi_word_mode (void)
{
  return TARGET_32BIT ? SImode : DImode;
}

// src/gcc/gcc/config/s390/s390.cc
#undef TARGET_LIBGCC_CMP_RETURN_MODE
#define TARGET_LIBGCC_CMP_RETURN_MODE s390_libgcc_cmp_return_mode

static scalar_int_mode
s390_libgcc_cmp_return_mode (void)
{
  return TARGET_64BIT ? DImode : SImode;
}

// libgcc/config/avr/avr-lib.h

#ifdef FLOAT
#define CMPtype QItype

[antoyo]

Posted a fix in #920, would you mind reviewing?

Yes, I'll test this with cg_gcc when the CI passes.

[tgross35]

Inconsistent with the compilers, the GCC docs list int as the return type for the comparison functions.

Submitted https://gcc.gnu.org/pipermail/gcc-patches/2025-May/684626.html