Improve support for legacy GCC versions #84119
Open
+56
−14
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
zephyrbot
added
area: Toolchains
zephyrbot
requested review from
57300,
aescolar,
andyross,
ceolin,
cfriedt,
dcpleung,
jeremybettis,
keith-packard,
nashif,
nordicjm,
npitre,
peter-mitsis,
stephanosio,
TaiJuWu and
tejlmand
andyross
previously approved these changes
Jan 17, 2025
|
Looks like the commit message is one character too long. @jhol - can you amend and push? |
aescolar
reviewed
Jan 17, 2025
You understand my struggle completely! |
The -fdiagnostics-color flag is only on GCC versions 4.9.0 and newer. Previously, CMake only checked that the compiler was not the XCC compiler before using the flag. However, given that the flag us unavailable on compilers other than XCC, e.g. old versions of GCC, this patch replaces the previous logic with a flag-check using the check_set_compiler_property() CMake function. Signed-off-by: Joel Holdsworth <[email protected]>
GCC versions before 7.1.0 do not have the -fno-printf-return-value flag and give an error if it is used. This patch improves compatibility with older compilers by making CMake check for the flag's availability before using. Signed-off-by: Joel Holdsworth <[email protected]>
A legacy build of GNU ld emits the following version string: GNU ld version 2.17.50.0.9 20070103 This patch fixes the regex parsing so that the version number is correctly extracted from the string. Signed-off-by: Joel Holdsworth <[email protected]>
GCC versions before 4.5 do not have the -fno-lto flag and give an error if it is used. This patch improves compatibility with older compilers by making CMake check for the flag's availability before using. Signed-off-by: Joel Holdsworth <[email protected]>
GCC versions starting from 4.3.0 until 12.4.0 stored the limits.h header in a directory named include-fixed/ . Before 4.3.0 and after 12.4.0 i.e. from 13.1.0 onward, the header is stored in a directory named include/ . Previously, target.cmake would only detect if the GCC version was 13.1.0 or newer. This patch adds a check to also check if it is older than 4.3.0. Signed-off-by: Joel Holdsworth <[email protected]>
Support for __builtin_unreachable() was added to GCC in the 4.5.0 release. This patch adds a fallback to __builtin_trap() for older compilers which do not have this built-in available. Signed-off-by: Joel Holdsworth <[email protected]>
__SIZEOF_INT__ is required by zephyr_stdint.h, however the __SIZEOF_*__ macros were only introduced in GCC 4.3. This patch adds a work-around similar to that present in picolibc's _default_types.h which attempts to guess the correct value of the definition based on the value of __INT_MAX__ or from INT_MAX from POSIX <limits.h> . Signed-off-by: Joel Holdsworth <[email protected]>
Within the K_THREAD_DEFINE macro, a nested set of macros is expanded to
populate the values of a global _static_thread_data structure.
The K_THREAD_DEFINE macro expands to statements including the
Z_THREAD_COMMON_DEFINE macro, which expands to statements including the
Z_THREAD_INITIALIZER macro, which expands to an initialization expression
of a _static_thread_data struct. The init_delay member of that struct is
then initialized with the Z_THREAD_INIT_DELAY_INITIALIZER macro, which
expands to an expression including the SYS_TIMEOUT_MS macro which
converts a number of milliseconds to a number of ticks.
For example, take the following macro:
K_THREAD_DEFINE(
thread_X,
STACKSIZE,
thread_X_entry_point, NULL, NULL, NULL,
PRIORITY,
0,
0);
In abbreviated form, it expands as follows:
typedef struct {
int ticks;
} k_timeout_t;
struct _static_thread_data {
/* ... */
k_timeout_t init_delay;
};
struct _static_thread_data _k_thread_data_thread_X = {
/* ... */
.init_delay = (k_timeout_t){ .ticks = 0 }
};
However, in GCC versions before 5.1, the code fails to compile with the
error "initializer element is not constant", when compiled with the
following options:
gcc -std=gnu99 -c test.c
In the above code, the error can be corrected by replacing...
.init_delay = (k_timeout_t){ .ticks = 0 }
...with...
.init_delay = { .ticks = 0 }
...i.e. removing initialization with a compound literal.
In order to achieve this, this patch reworks the system of macros.
The Z_TIMEOUT_TICKS(t) macro is refactored into Z_TIMEOUT_TICKS_INIT(t)
which defines the initializer part: { .ticks = t }, and Z_TIMEOUT_TICKS(t)
which is defined as ((k_timeout_t) Z_TIMEOUT_TICKS_INIT(t)) .
For symmetry, Z_TIMEOUT_NO_WAIT_INIT is split out of Z_TIMEOUT_NO_WAIT.
Similarly, SYS_TIMEOUT_MS_INIT(ms) is split out of SYS_TIMEOUT_MS(ms) so
that the Z_THREAD_INIT_DELAY_INITIALIZER(ms) macro can use
SYS_TIMEOUT_MS_INIT(ms) which expands Z_TIMEOUT_TICKS_INIT(t) to initialize
init_delay without using a compound literal.
Signed-off-by: Joel Holdsworth <[email protected]>
|
Here is v2 of the patch-set with the following changes:
|
npitre
approved these changes
Jan 17, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This patch set corrects various code and build system issues encountered while building Zephyr with a legacy version of the GCC tool-chain. With these fixes, and various fixes to picolibc which have now been accepted upstream [1] [2], it is possible to build Zephyr on GCC version 4.1.2 and newer.