Build failure with GCC14

[ForceFaction]

For example this warning emitted by GCC13

reload1.c: In function ‘emit_reload_insns’:
expr.h:356:23: warning: initialization of ‘struct rtx_def * (*)(struct rtx_def *, struct rtx_def *, struct rtx_def *)’ from incompatible pointer type ‘struct rtx_def * (*)(struct rtx_def *, ..
.)’ [-Wincompatible-pointer-types]
  356 | #define GEN_FCN(CODE) (*insn_gen_function[(int) (CODE)])
      |                       ^
reload1.c:6589:60: note: in expansion of macro ‘GEN_FCN’
 6589 |                           rtx (*gen_insn)(rtx, rtx, rtx) = GEN_FCN (icode);
      |                                                            ^~~~~~~

is an error with GCC14. -Wno-error=incompatible-pointer-types may be needed.

[gelven4sec]

Hello,

I got the same issue, compiling with the -Wno-error=incompatible-pointer-types seems to build but does not pass the checks :
https://pastebin.com/VeTAD6Cn

[ForceFaction]

Hm, reading the output i'm not able to infer at which step of the build.sh step the error occurs. There is a make cc1 invocation and your error message is that gcc_arm/cc1 is missing, so there might be something wrong there. I can check tomorrow how the output looks on my system.

[ForceFaction]

I can reproduce the failure. It also only happnes with GCC14 and not with GCC13.

[ForceFaction]

This is the reason why it fails for you @gelven4sec . I don't know where this has to be fixed though. I guess since the compiler is based on a old gcc version the autoconf files should be updated. I haven't tried it and it might be tricky. Don't know if it's possible to work around that.

configure:1128: checking whether the C compiler (gcc  ) works
configure:1144: gcc -o conftest    conftest.c  1>&5
configure:1141:1: error: return type defaults to 'int' [-Wimplicit-int]
 1141 | main(){return(0);}
      | ^~~~
configure: failed program was:

#line 1139 "configure"
#include "confdefs.h"

main(){return(0);}

[ForceFaction]

@gelven4sec this should be enough to build without failure. Directly modifying the configure script is hacky though, since it will be overridden once autoconf is run.

diff --git a/gcc/Makefile b/gcc/Makefile
index 9756e90..c34b354 100644
--- a/gcc/Makefile
+++ b/gcc/Makefile
@@ -24,7 +24,7 @@ VPATH = $(srcdir)
 
 CC = gcc
 
-BASE_CFLAGS = -g -std=gnu11 -Werror-implicit-function-declaration
+BASE_CFLAGS = -g -std=gnu11 -Werror-implicit-function-declaration -Wno-error=incompatible-pointer-types
 
 INCLUDES = -I. -I$(srcdir)
 
diff --git a/gcc_arm/Makefile.in b/gcc_arm/Makefile.in
index 09a8711..10641b8 100755
--- a/gcc_arm/Makefile.in
+++ b/gcc_arm/Makefile.in
@@ -64,7 +64,7 @@ ALLOCA_FINISH = true
 XCFLAGS =
 TCFLAGS =
 # CYGNUS LOCAL nowarnings/law
-CFLAGS = -g -Werror-implicit-function-declaration
+CFLAGS = -g -Werror-implicit-function-declaration -Wno-error=incompatible-pointer-types
 BOOT_CFLAGS = -O2 $(CFLAGS)
 WARN_CFLAGS =
 # END CYGNUS LOCAL
diff --git a/gcc_arm/configure b/gcc_arm/configure
index 05c0782..0b7738d 100755
--- a/gcc_arm/configure
+++ b/gcc_arm/configure
@@ -1138,7 +1138,7 @@ cat > conftest.$ac_ext << EOF
 #line 1139 "configure"
 #include "confdefs.h"
 
-main(){return(0);}
+int main(){return(0);}
 EOF
 if { (eval echo configure:1144: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then
   ac_cv_prog_cc_works=yes

[louie-github]

Note: This also occurs when using clang version 18.1.8 (latest on Arch as of 2024-07-30):

clang -MT expr.o -MMD -MP -MF .d/expr.Td -g -std=gnu11 -Werror-implicit-function-declaration -DOLD_COMPILER  -I. -I. -c expr.c
expr.c:1044:30: error: incompatible function pointer types passing 'rtx (rtx, ...)' (aka 'struct rtx_def *(struct rtx_def *, ...)') to parameter of type 'rtx (*)(rtx, rtx)' (aka 'struct rtx_def *(*)(struct rtx_def *, struct rtx_def *)') [-Wincompatible-function-pointer-types]
 1044 |             move_by_pieces_1(GEN_FCN(icode), mode, &data);
      |                              ^~~~~~~~~~~~~~

[ForceFaction]

@louie-github does the same solution apply? Modulo naming differences in the options

[louie-github]

Yep, using your patch as-is works with clang as well. No need to change option names.