daily riscv gcc build

[dkm]

          Can we have RISCV GCC trunk in compiler explorer ? Like we already have RISCV Clang trunk in compiler explorer.

Originally posted by @zhongjuzhe in #2041 (comment)

[zhongjuzhe]

Are you going to support RISCV trunk GCC in compiler explorer ? I really appreciate it.

[dkm]

At least that's the plan. I've tried the naive solution, but it fails for both rv32 and 64. I have to check what's going on, but maybe you are able to help?

[ERROR]    /opt/.build/riscv64-unknown-linux-gnu/src/gcc/gcc/config/riscv/riscv-vector-builtins.def:380:10: fatal error: riscv-vector-type-indexer.gen.def: No such file or d
irectory                                                                              
[ERROR]    make[3]: *** [/opt/.build/riscv64-unknown-linux-gnu/src/gcc/gcc/config/riscv/t-riscv:29: riscv-vector-builtins-shapes.o] Error 1
[ERROR]    make[3]: *** Waiting for unfinished jobs....
[ERROR]    /opt/.build/riscv64-unknown-linux-gnu/src/gcc/gcc/config/riscv/riscv-vector-builtins.def:380:10: fatal error: riscv-vector-type-indexer.gen.def: No such file or d
irectory
[ERROR]    make[3]: *** [/opt/.build/riscv64-unknown-linux-gnu/src/gcc/gcc/config/riscv/t-riscv:42: riscv-vector-builtins-bases.o] Error

Or maybe I'm out of luck and master is currently broken? Searched quickly the mailing list and can't see anything, so must be a problem in my setup.

[zhongjuzhe]

It's generated by internal generator (genrvv-type-indexer.cc).
I build RISCV gcc with master, it works fine.

I am gonna file bugzilla: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109328
for you to let RISCV port maintainer fix that.

Thank you for reporting it.

[zhongjuzhe]

At least that's the plan. I've tried the naive solution, but it fails for both rv32 and 64. I have to check what's going on, but maybe you are able to help?

[ERROR]    /opt/.build/riscv64-unknown-linux-gnu/src/gcc/gcc/config/riscv/riscv-vector-builtins.def:380:10: fatal error: riscv-vector-type-indexer.gen.def: No such file or d
irectory                                                                              
[ERROR]    make[3]: *** [/opt/.build/riscv64-unknown-linux-gnu/src/gcc/gcc/config/riscv/t-riscv:29: riscv-vector-builtins-shapes.o] Error 1
[ERROR]    make[3]: *** Waiting for unfinished jobs....
[ERROR]    /opt/.build/riscv64-unknown-linux-gnu/src/gcc/gcc/config/riscv/riscv-vector-builtins.def:380:10: fatal error: riscv-vector-type-indexer.gen.def: No such file or d
irectory
[ERROR]    make[3]: *** [/opt/.build/riscv64-unknown-linux-gnu/src/gcc/gcc/config/riscv/t-riscv:42: riscv-vector-builtins-bases.o] Error

Or maybe I'm out of luck and master is currently broken? Searched quickly the mailing list and can't see anything, so must be a problem in my setup.

Hi, I built RISC-V master GCC. I didn't get fail as you showed. Would you mind sharing your process of building RISC-V GCC?
Thanks

[dkm]

Yes, it looks like a crosstool-ng issue. When using the tool, it fails, but jumping in the build dir and invoking the all-gcc target works correctly.

[zhongjuzhe]

What is crosstool-ng issue ? Is this GCC issue or your tool issue?
If it is GCC issue, would you mind add more information here:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109328

If it is not GCC issue, can I close the issue in GCC bugzilla as it's resolved?

Thank you so much for supporting RISC-V GCC trunk in compiler explorer.

[dkm]

That's the config I'm using with crosstool-ng (revision 1d77bd30, it's a bit old compared to master but should be ok. I'll try updating it...): (it's a .log but it's really a conf file, but github only accepts a small set of extension...)
rv-config.log

I'm wondering if crosstool-ng is setting some C_INCLUDE or similar that breaks the include logic.

[dkm]

Is it possible that the

 380   │ #include "riscv-vector-type-indexer.gen.def"

does not always work depending on how the build is configured? I guess the file is supposed to be in the build dir

[zhongjuzhe]

hmmm, this file is added by RISC-V port maintainer.
I am gonna ask @kito-cheng for help, the RISC-V port GCC maintainer.

[zhongjuzhe]

Hi, GCC folks is trying remove building dependencies to make it suitable to crossng-tool.
We will let you known as long as they have some progress.

Thank you for reporting it.

[dkm]

Thanks @zhongjuzhe ! Is there a bugzilla PR I can follow? I'll check my mail to see if there is anything about that on the dev list

[zhongjuzhe]

Yeah, it's here:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109328
Someone has proposed a solution. You can add yourself as CC list.

@kito-cheng is working on it. I think soon the solution will be merged into master GCC.

Thanks.

[kito-cheng]

https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=608388486a54afe98aed0f105a6101ae7a9ff66c fix has pushed :)

[dkm]

Thanks a lot @kito-cheng , I'll retry the build during the weekend!

[dkm]

Hmm, I still can't build both toolchains, but for other errors now.

[EXTRA]      Building C library
[ERROR]      ../sysdeps/ieee754/ldbl-128/s_modfl.c:79:29: error: conflicting types for built-in function 'modff128'; expected '_Float128(_Float128,  _Float128 *)' [-Werror=b
uiltin-declaration-mismatch]                                                          
[ERROR]      ../sysdeps/ieee754/ldbl-128/s_modfl.c:79:29: error: conflicting types for built-in function 'modff64x'; expected '_Float64x(_Float64x,  _Float64x *)' [-Werror=b
uiltin-declaration-mismatch]                                                          
[ERROR]      ../sysdeps/ieee754/dbl-64/s_modf.c:63:28: error: conflicting types for built-in function 'modff64'; expected '_Float64(_Float64,  _Float64 *)' [-Werror=builtin-
declaration-mismatch]                      
[ERROR]      ../sysdeps/ieee754/dbl-64/s_modf.c:63:28: error: conflicting types for built-in function 'modff32x'; expected '_Float32x(_Float32x,  _Float32x *)' [-Werror=buil
tin-declaration-mismatch]                                                             
[ERROR]      make[4]: *** [/opt/.build/riscv32-unknown-linux-gnu/build/build-libc/multilib/sysd-rules:689: /opt/.build/riscv32-unknown-linux-gnu/build/build-libc/multilib/ma
th/s_modf.o] Error 1                                                                                  

Maybe libc needs to be updated, I'll have a look. But how did you build @zhongjuzhe ? Did you change anything?

[zhongjuzhe]

Hmm, I still can't build both toolchains, but for other errors now.

[EXTRA]      Building C library
[ERROR]      ../sysdeps/ieee754/ldbl-128/s_modfl.c:79:29: error: conflicting types for built-in function 'modff128'; expected '_Float128(_Float128,  _Float128 *)' [-Werror=b
uiltin-declaration-mismatch]                                                          
[ERROR]      ../sysdeps/ieee754/ldbl-128/s_modfl.c:79:29: error: conflicting types for built-in function 'modff64x'; expected '_Float64x(_Float64x,  _Float64x *)' [-Werror=b
uiltin-declaration-mismatch]                                                          
[ERROR]      ../sysdeps/ieee754/dbl-64/s_modf.c:63:28: error: conflicting types for built-in function 'modff64'; expected '_Float64(_Float64,  _Float64 *)' [-Werror=builtin-
declaration-mismatch]                      
[ERROR]      ../sysdeps/ieee754/dbl-64/s_modf.c:63:28: error: conflicting types for built-in function 'modff32x'; expected '_Float32x(_Float32x,  _Float32x *)' [-Werror=buil
tin-declaration-mismatch]                                                             
[ERROR]      make[4]: *** [/opt/.build/riscv32-unknown-linux-gnu/build/build-libc/multilib/sysd-rules:689: /opt/.build/riscv32-unknown-linux-gnu/build/build-libc/multilib/ma
th/s_modf.o] Error 1                                                                                  

Maybe libc needs to be updated, I'll have a look. But how did you build @zhongjuzhe ? Did you change anything?

Thanks for reporting it. I use https://github.com/riscv-collab/riscv-gnu-toolchain
to build RISCV GNU toolchain which is widely used by RISC-V community.

This error message you showed like a multilib issue, unfortunately, I am not familiar with that.
@kito-cheng , I will ping @kito-cheng for you to take a look at it.

Besides, can you file a PR in GCC bugzilla for tracking ?
Since it is stage 4 now, we can't merge codes in GCC unitl April without a bugzilla PR tracking.

Thanks

[dkm]

It's possible that this issue is not a gcc problem, but a crosstool-ng config one. I would like to dig into it a bit more before opening a gcc pr.
I can easily point to other git repositories if you give exact URL info and give it a try.

Uptodate ct-ng gives same error, will try with more recent glibc.

[dkm]

Hmmm, looks like using latest glibc avail in ct-ng fixes the build error. I still have other unrelated issues, but am pretty confident it will work shortly :) Thanks for the help @zhongjuzhe

[dkm]

Ok, disabling the Ada compiler and bumping the glibc version fixes the issue and I can build master gcc.

[zhongjuzhe]

Thanks a lot! But I still can't see trunk RISC-V GCC in compiler explorer:
https://godbolt.org/

Do we have still other building issues in upstream RISC-V GCC for supporting trunk RISC-V GCC in compiler explorer.

Thanks~

[dkm]

Yes sorry @zhongjuzhe , there are several steps before having them online:

• having the nightly builds in order (build + upload to s3 storage)
• setup config in infra so we can actually install these compilers in our compiler pool
• setup the web part to use these compiler.

I have the first step ready, but not yet merged (see previous PR in compiler-workflows). I'll merge it now and we'll see during next build run if everything is ok. Then I'll move on to the next steps :)

edit: didn't remember it was already merged. Compilers are building as expected, see https://github.com/compiler-explorer/compiler-workflows/blob/main/build-status.md

[dkm]

Ok, merged infra config, so compilers should be installed during next run. I'll try to do the remaining config change later this week

[dkm]

This is (finally) live 🚀

[kito-cheng]

@dkm thanks!!! I saw the trunk option for both RV64 and RV32 GCC!!!!

[dkm]

@dkm thanks!!! I saw the trunk option for both RV64 and RV32 GCC!!!!

Yes! And FWIW, I've tried to enable all lang possible, so you have C, C++, Fortran, D, Objective-C and Objective-C++. The others were broken/not supported for the target (eg. Ada, Go), not yet supported by ct-ng and probably would break the build regularly (e.g. Rust, m2).

Let us know if you have any feedback/issue!

[kito-cheng]

Ooops, I admit I did't pay too much attention on those languages other than C and C++, that would be the goal of next GCC release cycle :P

[dkm]

Oh, that was not a complaint or anything, even thought I'll be happy to help with Ada and Rust (I know absolutely nothing about the others).