Does the latest GCC toolchain support the Zfinx?

[Micronana]

Hi,
Is the Zfinx extension supported in the latest GCC toolchain?
I just found some commits related with Zfinx, but not sure whether is the toolchain avaliable for Zfinx?

If not, can anyone kindly tell me where I can get the toolchian that supports Zfinx?

[kito-cheng]

Zfinx has supported on upstream, and will be part of GCC 13, which will release at end of April.
So you can switch gcc to master branch if you want get it a try, but I forgot which binuilts has support that...so you could also check out to master branch for binutils too.

[Micronana]

Zfinx has supported on upstream, and will be part of GCC 13, which will release at end of April. So you can switch gcc to master branch if you want get it a try, but I forgot which binuilts has support that...so you could also check out to master branch for binutils too.

Thank you so much，I‘ll have a try .

[TommyMurphyTM1234]

Further info that may be of use?

• https://wiki.riscv.org/display/HOME/Zfinx+TG
• https://gcc.gnu.org/pipermail/gcc-patches/2021-November/thread.html#583437
• https://sourceware.org/pipermail/binutils/2022-February/thread.html#119570

[Micronana]

Further info that may be of use?

• https://wiki.riscv.org/display/HOME/Zfinx+TG
• https://gcc.gnu.org/pipermail/gcc-patches/2021-November/thread.html#583437
• https://sourceware.org/pipermail/binutils/2022-February/thread.html#119570

Thanks for you information.

@kito-cheng @TommyMurphyTM1234
What -march and -mabi should I use when generate the gcc compiler ?

Following is what I have done:

1. I used "--with-arch=rv32imfc_zbb_zbc_zbs_zfinx ---with-abi=ilp32f " to generate gcc compiler.
2. use “riscv32-unknown-elf-gcc -march=rv32imfc_zfinx -mabi=ilp32f -S test_fpu.c”
   it generate code with F-extension intruction using F register but not X register, like this:

_main:
	addi	sp,sp,-48
	sw	s0,44(sp)
	addi	s0,sp,48
	fsw	fa0,-36(s0)
	fsw	fa1,-40(s0)
	flw	fa4,-36(s0)
	flw	fa5,-40(s0)
	fadd.s	fa5,fa4,fa5
	fsw	fa5,-20(s0)
	flw	fa5,-20(s0)
	fmv.s	fa0,fa5
	lw	s0,44(sp)
	addi	sp,sp,48
	jr	ra
	.size	main, .-main
	.ident	"GCC: (GNU) 12.2.0"_

3. use “riscv32-unknown-elf-gcc -march=rv32imc_zfinx -mabi=ilp32f -S test_fpu.c”, run failed like this:
   [(cc1: error: requested ABI requires '-march' to subsume the 'F' extension)]

[TommyMurphyTM1234]

3. use “riscv32-unknown-elf-gcc -march=rv32imc_zfinx -mabi=ilp32f -S test_fpu.c”, run failed like this:
   riscv32-unknown-elf-gcc: error: '-march=rv32imcf_zfinx': ISA string is not in canonical order. 'f'

The problem here, as stated by the error message, is that f is in the wrong (non-canonicalised) place. You specified rv32imcf_zfinx whereas it should be rv32imfc_zfinx.

Other than that I don't understand what your issue is as the other stuff seems to be ok?

[Micronana]

3. use “riscv32-unknown-elf-gcc -march=rv32imc_zfinx -mabi=ilp32f -S test_fpu.c”, run failed like this:
   riscv32-unknown-elf-gcc: error: '-march=rv32imcf_zfinx': ISA string is not in canonical order. 'f'

The problem here, as stated by the error message, is that f is in the wrong (non-canonicalised) place. You specified rv32imcf_zfinx whereas it should be rv32imfc_zfinx.

Other than that I don't understand what your issue is as the other stuff seems to be ok?

Sorry, I pasted the wrong message. It is :
cc1: error: requested ABI requires '-march' to subsume the 'F' extension

I supposed having used wrong -march and -mabi, so the compiler can't generate Zfinx intruction using X register.

[TommyMurphyTM1234]

-march=rv32imc_zfinx -mabi=ilp32f
Sorry, I pasted the wrong message. It is : cc1: error: requested ABI requires '-march' to subsume the 'F' extension

Again, the error message is telling you what's wrong.
-mabi=ilp32f expects that the architecture includes the F extension. E.g. -march=rv32imfc -mabi=ilp32f.

My understanding is that one of the integer ABIs must be used when using the zfinx extension. E.g. -march=rv32imc_zfinx -mabi=ilp32.

I'm not sure that -march=...f_zfinx (which you mentioned above) makes sense as it seems to involve conflicting extensions.

[kito-cheng]

I realized gcc didn't check f and zfinx isn't a valid combination, prepare patch for fixing that.

[TommyMurphyTM1234]

I realized gcc didn't check f and zfinx isn't a valid combination, prepare patch for fixing that.

Hi @kito-cheng - just to clarify, I'm not certain that f and zfinx are incompatible extensions - but it seems logical that they would be since the latter is effectively (or actually?) a subset of the former? Maybe the spec clarifies?

I don't know if there's any issue with d andzfinx too?

Also, an early revision of the zfinx spec said that an integer ABI was required but subsequently that was removed and the ratified spec says that the relevant ABI was being dealt with in another forum.

In my opinion, all of this seems very confusing.

[kito-cheng]

https://github.com/riscv/riscv-isa-manual/blob/master/src/zfinx.tex#L23 spec has say F is incompatible with Zfinx.

I don't know if there's any issue with d and zfinx too?

Yeah, and the logic would be little implicitly here, D implied F and F is incompatible with Zfinx, so D is incompatible with Zfinx. (e.g. -march=rv32id_zfinx === -march=rv32ifd_zfinx => f conflict with zfinx)

Also, an early revision of the zfinx spec said that an integer ABI was required but subsequently that was removed and the ratified spec says that the relevant ABI was being dealt with in another forum.

ilp32f/ilp32d/lp64f/lp64d will require argument/return value passed in FPR, which is impossible with Zfinx extension, so that's also kind of implication that zfinx must use ilp32/ilp32e/lp64

[TommyMurphyTM1234]

ilp32f/ilp32d/lp64f/lp64d will require argument/return value passed in FPR, which is impossible with Zfinx extension, so that's also kind of implication that zfinx must use ilp32/ilp32e/lp64

What about lp64e which, I believe, is another possibility?

• Add the LP64E ABI, to support RV64E riscv-non-isa/riscv-elf-psabi-doc#299

And what about the zfinx spec referring to ABI work elsewhere?

• https://github.com/riscv/riscv-zfinx/blob/main/Zfinx_ISA_spec_addendum.adoc#abi

[kito-cheng]

What about lp64e which, I believe, is another possibility?

Yes, lp64e is also possible but just it isn't merge yet so I didn't mention.

And what about the zfinx spec referring to ABI work elsewhere?

https://github.com/riscv-non-isa/riscv-elf-psabi-doc/blob/master/riscv-cc.adoc#named-abis

NOTE: This means code targeting the Zfinx extension always uses the ILP32, ILP32E or LP64 integer calling-convention only ABIs as there is no dedicated hardware floating-point register file.

And related discussions:
riscv-non-isa/riscv-elf-psabi-doc#198
riscv-non-isa/riscv-elf-psabi-doc#166
riscv-non-isa/riscv-elf-psabi-doc#189

[TommyMurphyTM1234]

I'm a bit unclear if this issue needs to remain open?

[Micronana]

Yes, it can be closed now.
Thank you all. :)

[pulkitgupta1217]

Hi, now that gcc 13.1 has been released (https://gcc.gnu.org/gcc-13/) what is the timeline for integrating it into the standard toolchain here so that we can get zfinx/zdinx support?

Should we instead be pulling in the 13.1 release branch of gcc ourselves and using that? And if so, this will likely require changes to the commit IDs and versions we need for binutils, glibc, etc?

[TommyMurphyTM1234]

Hi, now that gcc 13.1 has been released (https://gcc.gnu.org/gcc-13/) what is the timeline for integrating it into the standard toolchain here so that we can get zfinx/zdinx support?

Waiting on this PR to be cleared:

• bump gcc to 13.1 release #1239

Should we instead be pulling in the 13.1 release branch of gcc ourselves and using that?

Until that PR is integrated, yes.

And if so, this will likely require changes to the commit IDs and versions we need for binutils, glibc, etc?

I don't think so?

[pulkitgupta1217]

Thanks for the fast update. Since it looks like tests are passing for the PR, I'm hoping that the timeline is pretty fast? We can survive for a few days without the update so I don't want to change up our scripts/containers/etc from using the master branch here.