-
Notifications
You must be signed in to change notification settings - Fork 677
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
GCC 14 leads to compile errors in WRF/WPS compilation #2047
Comments
@SettRaziel Which version of the WRF code have you tried? |
I did a recompile of 4.5.0. |
I do stand partially corrected. The errors regarding -Wimplicit-function-declaration are gone with the changes provided in #1823.
I now get around 80 errors like this:
The error is an incompatible pointer type, here long int* instead of char*. Sorry had my compiler language changed to german. If you need a complete log i would change the language, restart it and add the log in english. |
@SettRaziel Thanks for testing the latest version of the model. We will take a look at this issue very soon. |
@islas When you get a chance, can you review this report? |
TYPE: bug fix KEYWORDS: gcc14, compilation, c99 SOURCE: internal DESCRIPTION OF CHANGES: Problem: From #2047 : Compilation of WRF v4.6.0 fails with GCC 14 due to new standard changes > Type checking on pointer types (-Werror=incompatible-pointer-types) > GCC no longer allows implicitly casting all pointer types to all other pointer types. This behavior is now restricted to the void * type and its qualified variations. > > To fix compilation errors resulting from that, you can add the appropriate casts, and maybe consider using void * in more places (particularly for old programs that predate the introduction of void * into the C language). > > Programs that do not carefully track pointer types are likely to contain aliasing violations, so consider building with -fno-strict-aliasing. (Whether casts are written manually or performed by GCC automatically does not make a difference in terms of strict aliasing violations.) > > A frequent source of incompatible function pointer types involves callback functions that have more specific argument types (or less specific return types) than the function pointer they are assigned to. For example, old code which attempts to sort an array of strings might look like this: ``` #include <stddef.h> #include <stdlib.h> #include <string.h> int compare (char **a, char **b) { return strcmp (*a, *b); } void sort (char **array, size_t length) { qsort (array, length, sizeof (*array), compare); } ``` Example of failure : ``` /home/aislas/wrf-model/wrf/external/RSL_LITE/c_code.c: In function ‘rsl_lite_pack_’: /home/aislas/wrf-model/wrf/external/RSL_LITE/c_code.c:487:27: error: passing argument 1 of ‘f_pack_lint_’ from incompatible pointer type [-Wincompatible-pointer-types] 487 | F_PACK_LINT ( buf, p+yp_curs, imemord, &js, &je, &ks, &ke, &is, &ie, | ^~~ | | | char * In file included from /home/aislas/wrf-model/wrf/external/RSL_LITE/c_code.c:31: /home/aislas/wrf-model/wrf/external/RSL_LITE/rsl_lite.h:200:25: note: expected ‘long int *’ but argument is of type ‘char *’ 200 | void F_PACK_LINT (long *inbuf, long *outbuf, int* memorder, int* js, int* je, int* ks, int* ke, int* is, int* ie, int* jms, int* jme, int* kms, int* kme, int* ims, int* ime, int* curs); | ~~~~~~^~~~~ /home/aislas/wrf-model/wrf/external/RSL_LITE/c_code.c:487:33: error: passing argument 2 of ‘f_pack_lint_’ from incompatible pointer type [-Wincompatible-pointer-types] 487 | F_PACK_LINT ( buf, p+yp_curs, imemord, &js, &je, &ks, &ke, &is, &ie, | ~^~~~~~~~ | | | char * /home/aislas/wrf-model/wrf/external/RSL_LITE/rsl_lite.h:200:38: note: expected ‘long int *’ but argument is of type ‘char *’ 200 | void F_PACK_LINT (long *inbuf, long *outbuf, int* memorder, int* js, int* je, int* ks, int* ke, int* is, int* ie, int* jms, int* jme, int* kms, int* kme, int* ims, int* ime, int* curs); | ~~~~~~^~~~~~ /home/aislas/wrf-model/wrf/external/RSL_LITE/c_code.c:492:26: error: passing argument 1 of ‘f_pack_int_’ from incompatible pointer type [-Wincompatible-pointer-types] 492 | F_PACK_INT ( buf, p+yp_curs, imemord, &js, &je, &ks, &ke, &is, &ie, | ^~~ | | | char * /home/aislas/wrf-model/wrf/external/RSL_LITE/rsl_lite.h:201:23: note: expected ‘int *’ but argument is of type ‘char *’ 201 | void F_PACK_INT (int *inbuf, int *outbuf, int* memorder, int* js, int* je, int* ks, int* ke, int* is, int* ie, int* jms, int* jme, int* kms, int* kme, int* ims, int* ime, int* curs); | ~~~~~^~~~~ ``` Error was reproduced AlmaLinux release 9.4 with GCC 14.1.0 Solution: Use explicit type casting ISSUE: Fixes #2047 TESTS CONDUCTED: 1. Tested on GCC 14.1.0
Hej there.
I am maintaining a project to provide wrf/wps binaries for deployment in an ArchLinux environment.
Describe the bug
With the update to gcc 14 several new changes regarding compile flags were done.
These lead to a more restrict error handling since several flags that would only lead to warnings now lead to compile errors:
Looking on the changes with gcc 14 it seems they have change the flag: GCC 14
When compiling the wrf model now these new restriction lead to these compile errors, e.g.
To Reproduce
Steps to reproduce the behavior:
Testing environment is an ArchLinux VM with Linux Kernel 6.8.9.
Compiler is gcc/gfortran with version 14.1.1.
Current compile flags: Env. Variables
Additional parameter for compilation: 35 gfortran dm+sm
Precondition: Successful compilation of netcdf, netcdf-fortran, mpich, hdf5
Running my compile routines lead to a reproducible number of around 140 of these implicit compile errors.
Workaround
Adding to the compile flags: -Wimplicit-function-declaration (issue tracked in: wrf_archlinux)
Expected behavior
No implicit functions declaration throughout the code resolving the workaround to address these issues as warnings and not as errors with the flag which might lead to other side effects during the code compilation.
Additional context
Up to gcc/gfortran 13.2.2 these implicit declarations only lead to warnings, so up to that point the compilation runs successfully.
Are there plans to refactor the code base?
The text was updated successfully, but these errors were encountered: