On 21/10/2025 10:12, Andre Vieira wrote: > As mentioned before there are still some failures, this version fixed some > issues with arm_return_in_memory and arm_needs_doubleword_align aswell as > addressed some comments below. > > > gcc/ChangeLog: > > * config/arm/arm.cc (TARGET_C_BITINT_TYPE_INFO): New Macro. > (arm_return_in_memory): Return true for any _BitInt(N) where N > 64. > (arm_needs_doubleword_align): Return true for any _BitInt(N) where N > > 32. > (arm_bitint_type_info): New. >
The gcc/config/arm bits look OK now. It would be slightly cleaner to use BITINT_TYPE_P rather than a comparison, but that's noise really. R. > libgcc/ChangeLog: > > * config/arm/libgcc-bpabi.ver: Add new symbols. > * config/arm/t-softfp: Enable use of floatbitinthf and pass necessary > options to build fp16. > > On 30/09/2025 09:53, Ramana Radhakrishnan wrote: >> On Mon, Sep 29, 2025 at 10:53 PM Jakub Jelinek <[email protected]> wrote: >>> On Thu, Sep 25, 2025 at 10:23:46AM +0100, Andre Vieira wrote: >>>> +/* Implement TARGET_C_BITINT_TYPE_INFO >>>> + Return true if _BitInt(N) is supported and fill its details into >>>> *INFO. */ >>>> + >>>> +bool >>>> +arm_bitint_type_info (int n, struct bitint_info *info) >>>> +{ >>>> + if (TARGET_BIG_END) >>>> + return false; >>> Why? Just that it isn't tested so far? Big endian support in the generic >>> code should be there already, s390x _BitInt works. > Yes and I also wasn't aware the Big endian support was in. I'll try to find > some spare cycles to test it locally and will enable it if most pass. >>>> --- a/libgcc/config/arm/libgcc-bpabi.ver >>>> +++ b/libgcc/config/arm/libgcc-bpabi.ver >>>> @@ -106,3 +106,11 @@ GCC_3.5 { >>>> GCC_4.3.0 { >>>> _Unwind_Backtrace >>>> } >>>> + >>>> +GCC_16.0.0 { >>> I miss >>> __mulbitint3 >>> __divmodbitint4 >>> here, that is pretty much essential to export. >>> Don't you also need %import above it from whatever was the latest >>> GCC_* symver on arm? > Done, but tbf I'm not sure about this libgcc-bpabi.ver file, I am not > entirely convinced it is used in anyway shape or form. Richard E did mention > downstream that we probably want to use GCC_14 as that's when the symbols > were added? >>>> + __fixsfbitint >>>> + __fixdfbitint >>>> + __floatbitinthf >>>> + __floatbitintsf >>>> + __floatbitintdf >>>> +} >>>> diff --git a/libgcc/config/arm/t-softfp b/libgcc/config/arm/t-softfp >>>> index 554ec9bc47b..68aff4de068 100644 >>>> --- a/libgcc/config/arm/t-softfp >>>> +++ b/libgcc/config/arm/t-softfp >>>> @@ -1,2 +1,4 @@ >>>> softfp_wrap_start := '\#if !__ARM_ARCH_ISA_ARM && __ARM_ARCH_ISA_THUMB >>>> == 1' >>>> softfp_wrap_end := '\#endif' >>>> +bitint_extras += floatbitinthf >>>> +softfp_cflags := -mfp16-format=ieee >>> Other than that LGTM but I think you want Richard/Ramana to ack it; I'd >>> suggest >>> to xfail the 2 tests for arm with a PR (and CC me on that), that can be >>> resolved incrementally. >> I'm good with the approach to xfail + PR and get that sorted . >> >> Still recovering from travel to be able to do this justice. I expect >> to have some free time on Thursday / Friday due to public holidays >> here so will get back then. >> > There was some downstream pointers from Richard E, but I'll wait for an > upstream review.
