Upstream 11.3 known problems?

[ilg-ul]

I prepared a new release for the xPack GNU RISC-V Embedded GCC, which now uses the upstream sources instead of the SiFive repos.

The toolchain seems functional, it remains to be seen how compatible it is with the old 10.2 customised by SiFive.

Are there any known problems with the upstream 11.3 that I should warn the users about?

[ilg-ul]

Another question is related to multilibs.

I see some of them were automatically suffixed with _zicsr, although I did not request for this in the configuration I passed to the multilib generator.

For example:

rv32i/ilp32;@march=rv32i@mabi=ilp32
rv32ia/ilp32;@march=rv32ia@mabi=ilp32
rv32iac/ilp32;@march=rv32iac@mabi=ilp32
rv32iaf_zicsr/ilp32f;@march=rv32iaf_zicsr@mabi=ilp32f
rv32iafc_zicsr/ilp32f;@march=rv32iafc_zicsr@mabi=ilp32f
rv32iafd_zicsr/ilp32d;@march=rv32iafd_zicsr@mabi=ilp32d
rv32iafdc_zicsr/ilp32d;@march=rv32iafdc_zicsr@mabi=ilp32d
rv32ic/ilp32;@march=rv32ic@mabi=ilp32
rv32if_zicsr/ilp32f;@march=rv32if_zicsr@mabi=ilp32f
rv32ifc_zicsr/ilp32f;@march=rv32ifc_zicsr@mabi=ilp32f
rv32ifd_zicsr/ilp32d;@march=rv32ifd_zicsr@mabi=ilp32d
rv32ifdc_zicsr/ilp32d;@march=rv32ifdc_zicsr@mabi=ilp32d
rv32im/ilp32;@march=rv32im@mabi=ilp32
rv32ima/ilp32;@march=rv32ima@mabi=ilp32
rv32imaf_zicsr/ilp32f;@march=rv32imaf_zicsr@mabi=ilp32f
rv32imafc_zicsr/ilp32f;@march=rv32imafc_zicsr@mabi=ilp32f
rv32imafd_zicsr/ilp32d;@march=rv32imafd_zicsr@mabi=ilp32d
rv32imafdc_zicsr/ilp32d;@march=rv32imafdc_zicsr@mabi=ilp32d
rv32imc/ilp32;@march=rv32imc@mabi=ilp32
rv32imf_zicsr/ilp32f;@march=rv32imf_zicsr@mabi=ilp32f
rv32imfc_zicsr/ilp32f;@march=rv32imfc_zicsr@mabi=ilp32f
rv32imfd_zicsr/ilp32d;@march=rv32imfd_zicsr@mabi=ilp32d
rv32imfdc_zicsr/ilp32d;@march=rv32imfdc_zicsr@mabi=ilp32d

Is this the expected behaviour?

[jim-wilson]

I'm not aware of any major problem with gcc-11.3.

gcc-11 by default does not check for zicsr. gcc-12 will check for it by default. Binutils had to be fixed first. binutils-2.37 from last year doesn't check for zicsr. binutils-2.38 released in January this year does. So to avoid conflicts between gcc-11 and binutils-2.38, we added some minimal zicsr support to gcc-11.3. If you use last year's binutils with last year's gcc, you shouldn't have any problem.

Note that F implies zicsr, so it is all of the FP configurations that are adding zicsr even though you didn't ask for it, because you did ask for F support.

Also note that isa v2.2 rv32i is equivalent to isa 20191213 rv32i_zicsr as the ISA was changed to split zicsr out of the base I instruction set. You can choose whether you want to use zicsr by choosing your isa version by using the -misa-spec= option. And note that isa v2.2 rv32gc and isa 20191213 rv32gc are the same, as the meaning of g was changed to include zicsr in the newer ISA spec version.

We will have yet another ISA backward compatibility break with this year's ISA update, as some more instructions were removed from the I base instruction set and added to the new zicntr extension. This affects the rdtime, rdcycle, rdinstret and the rv32 *h versions. In the future, you will need rv32i_zicntr to use these instructions. Though some people are discussing exactly how the tools should handle this, so we might not require zicntr right away.

[ilg-ul]

I'm not aware of any major problem with gcc-11.3.

Thank you, Jim. Then it should be ok.

I don't know if it'll compile the SiFive examples. Are the extensions (like interrupt attributes) upstream?

If you use last year's binutils with last year's gcc, you shouldn't have any problem

I used the latest versions available (gcc 11.3, binutils 2.38, newlib 4.2.0.20211231, gdb 11.2), with the latest dependencies.

The input multilib configuration was:

        GCC_MULTILIB=${GCC_MULTILIB:-"\
          rv32e-ilp32e-- \
          rv32ea-ilp32e-- \
          rv32eac-ilp32e-- \
          rv32ec-ilp32e-- \
          rv32em-ilp32e-- \
          rv32ema-ilp32e-- \
          rv32emac-ilp32e-- \
          rv32emc-ilp32e-- \
          \
          rv32i-ilp32-- \
          rv32ia-ilp32-- \
          rv32iac-ilp32-- \
          rv32iaf-ilp32f-- \
          rv32iafc-ilp32f-- \
          rv32iafd-ilp32d-- \
          rv32iafdc-ilp32d-- \
          rv32ic-ilp32-- \
          rv32if-ilp32f-- \
          rv32ifc-ilp32f-- \
          rv32ifd-ilp32d-- \
          rv32ifdc-ilp32d-- \
          rv32im-ilp32-- \
          rv32ima-ilp32-- \
          rv32imaf-ilp32f-- \
          rv32imafc-ilp32f-- \
          rv32imafd-ilp32d-- \
          rv32imafdc-ilp32d-- \
          rv32imc-ilp32-- \
          rv32imf-ilp32f-- \
          rv32imfc-ilp32f-- \
          rv32imfd-ilp32d-- \
          rv32imfdc-ilp32d-- \
          \
          rv64i-lp64-- \
          rv64ia-lp64-- \
          rv64iac-lp64-- \
          rv64iaf-lp64f-- \
          rv64iafc-lp64f-- \
          rv64iafd-lp64d-- \
          rv64iafdc-lp64d-- \
          rv64ic-lp64-- \
          rv64if-lp64f-- \
          rv64ifc-lp64f-- \
          rv64ifd-lp64d-- \
          rv64ifdc-lp64d-- \
          rv64im-lp64-- \
          rv64ima-lp64-- \
          rv64imac-lp64-- \
          rv64imaf-lp64f-- \
          rv64imafc-lp64f-- \
          rv64imafd-lp64d-- \
          rv64imafdc-lp64d-- \
          rv64imc-lp64-- \
          rv64imf-lp64f-- \
          rv64imfc-lp64f-- \
          rv64imfd-lp64d-- \
          rv64imfdc-lp64d-- \
        "}

The build configurations were exactly the same as for building arm-none-eabi and aarch64-none-elf, suggested by Arm.

The toolchain is named riscv-none-elf.

In the future, you will need rv32i_zicntr to use these instructions.

Please note that for generic toolchains, this list of libraries is already very large, and the size of the archive is about 475 MB, so any combinatorial additions will double this size and the toolchain will become unpractical, for example when installing it on CI servers for each run.

[kito-cheng]

IIRC one of multi-lib handler patch we didn't merge to trunk yet.

Ref: https://github.com/riscv-collab/riscv-gnu-toolchain/issues/1038

In the future, you will need rv32i_zicntr to use these instructions.

Please note that for generic toolchains, this list of libraries is already very large, and the size of the archive is about 475 MB, so any combinatorial additions will double this size and the toolchain will become unpractical, for example when installing it on CI servers for each run.

Actually that's cause by ISA spec rather than toolchain...

[ilg-ul]

one of multi-lib handler patch we didn't merge to trunk yet.

This seems to affect the Linux toolchain, not the bare-metal. Is this correct?

[kito-cheng]

This seems to affect the Linux toolchain, not the bare-metal. Is this correct?

That’s very useful to reduce the multi-lib reuse rule for bare-metal.

[ilg-ul]

Yes, your patch would be useful for bare-metal toolchains, I'll pick it in the next release.

My previous question was related to the the bug reporting the missing C++ headers rv64gc/lp64d, which uses --enable-linux.

Should I mention anything about it in my release notes, or it affects only Linux toolchains?

[ilg-ul]

The new 11.3 seems functional, it compiled my old HiFive1 projects, so I can proceed with the release.

Apart from RVV support and SiFive interrupt attributes, are there any other changes compared to the SiFive 10.2 toolchain, worth mentioning in the release notes?