Even weirder is when I configure master for nucleo-h743zi2:jubmo, build
it, I don't see warnings from arch/arm/src/armv7-m/arm_hardfault.c, but
if I then attempt to compile the preprocessed source for
arch/arm/src/armv7-m/arm_hardfault.c (using either version of the ARM
compiler) it now generates the following warning:
peter@legion:~/git/nuttx/nuttx-master/nuttx/arch/arm/src$ arm-none-eabi-gcc -c
-Wstrict-prototypes -Wno-attributes -Wno-unknown-pragmas -Wno-psabi -Os
-fno-strict-aliasing -fomit-frame-pointer --param=min-pagesize=0 -fno-common -Wall
-Wshadow -Wundef -ffunction-sections -fdata-sections "-g" -mlittle-endian
-march=armv7e-m -mtune=cortex-m7 -mfpu=fpv5-d16 -mfloat-abi=hard -mthumb -Wa,-mthumb
-Wa,-mimplicit-it=always -isystem /home/peter/git/nuttx/nuttx-master/nuttx/include
-D__NuttX__ -DNDEBUG -D__KERNEL__ -I
/home/peter/git/nuttx/nuttx-master/nuttx/arch/arm/src/chip -I
/home/peter/git/nuttx/nuttx-master/nuttx/arch/arm/src/common -I
/home/peter/git/nuttx/nuttx-master/nuttx/arch/arm/src/armv7-m -I
/home/peter/git/nuttx/nuttx-master/nuttx/sched /tmp/arm_hardfault.c -o
/tmp/arm_hardfault.o
/tmp/arm_hardfault.c: In function 'arm_hardfault':
/tmp/arm_hardfault.c:4864:12: warning: the address of 'cfsr' will always
evaluate as 'true' [-Waddress]
4864 | ((void)(1 || &(
| ^~
/tmp/arm_hardfault.c:4869:12: warning: the address of 'hfsr' will always
evaluate as 'true' [-Waddress]
4869 | ((void)(1 || &(
| ^~
peter@legion:~/git/nuttx/nuttx-master/nuttx/arch/arm/src$
The warning is is generated from the UNUSED() macro meant to suppress
unused parameter warnings from the compiler. Why it takes removing all
the linemarkers from the preprocessed source to generate the warning is
what's so confusing...
On 2/23/26 01:24, Peter Barada wrote:
Tomek,
Using arm-gcc-none-eabi-gcc-14.2.1 from the STMicroelectronics Arduino
toolchain "arm-none-eabi-gcc-14.2.1 (xPack GNU Arm Embedded GCC
x86_64) 14.2.1 20241119" I see the _same_ behavior where no format
warnings are generated without removing linemarkers from the
preprocessed source.
The following tiny testcase (copmiled using "-Wall -c test.c" )
elicits the format warning from either compiler version as expected:
typedef __UINT32_TYPE__ uint32_t;
extern uint32_t getreg32(uint32_t addr);
extern void setreg32(uint32_t addr, uint32_t value);
extern void syslog(int priority, const char *fmt, ...) \
__attribute__((__format__(__printf__, 2, 3)));
void testcase(uint32_t addr, uint32_t value)
{
syslog(6, "%s: " "%08x[%08x]->%08x\n", __FUNCTION__, addr, getreg32(addr),
value);
setreg32(addr, value);
}
The question I have is why doesn't building Nuttx (with DEBUG_IRQ_INFO
enabled) for arm (nucleo-h743zi2:jumbo in my case) cause stm32_irq.c
to show the same format warning??
On 2/22/26 20:05, Tomek CEDRO wrote:
What happens on GCC 14.2? I know this one is preferred :-)
--
CeDeROM, SQ7MHZ,http://www.tomek.cedro.info
On Sun, Feb 22, 2026 at 11:12 PM Peter Barada<[email protected]> wrote:
This is _really_ weird. I'm seeing what looks (to me) to be a bug in
arm-none-eabig-gcc where it _may_ generate format warnings (or not) when
run over functionally equivalent source using same compilation options.
I'm trying to understand why a syslog call using a format of "%08x" and
an argument of uint32_t doesn't cause a format warning when built using
arm-none-eabi-gcc (version 13.2.1 20231009) on my Ubuntu machine.
I configured nuttx fornucelo-h743zi2:jumbo, tweaked the configuration
to enable DEBUG_IRQ_INFO, and built with V=1 to get the compiler command
line for arch/arm/src/chip/stm32_irq.c:
tools/configure.sh -l nucleo-h743zi2jumbo
kconfig-tweak --file .config -e DEBUG_IRQ_INFO
make V=1 -j $(nproc)
Then chdir into arch/arm/src and generate preprocessed source of
chip/stm32_irq.c into /tmp/stm32_irq.c using the complication command
from the build:
cd arch/arm/src
# setup BASE_DIR to root of nuttx tree
BASE_DIR=/home/peter/git/nuttx/github/nucleo-h743zi2-warnings/nuttx
# setup COMPILER_OPTIONS for what gets passed to gcc
COMPILER_OPTIONS="-Wstrict-prototypes -Wno-attributes -Wno-unknown-pragmas" \
" -Wno-psabi -Os -fno-strict-aliasing -fomit-frame-pointer" \
" --param=min-pagesize=0 -fno-common -Wall -Wshadow -Wundef" \
" -ffunction-sections -fdata-sections "-g" -mlittle-endian" \
" -march=armv7e-m -mtune=cortex-m7 -mfpu=fpv5-d16 -mfloat-abi=hard" \
" -mthumb -Wa,-mthumb -Wa,-mimplicit-it=always -isystem"
# Generate /tmp/stm32_irq.c from chip/stm32_irq.c
arm-none-eabi-gcc -E $COMPILER_OPTIONS $BASE_DIR/include -D__NuttX__ \
-DNDEBUG -D__KERNEL__ -I $BASE_DIR/arch/arm/src/chip \
-I $BASE_DIR/arch/arm/src/common -I $BASE_DIR/arch/arm/src/armv7-m \
-I $BASE_DIR/sched chip/stm32_irq.c -o /tmp/stm32_irq.c
# Compile the result file using same compiler options:
arm-none-eabi-gcc -E $COMPILER_OPTIONS $BASE_DIR/include -D__NuttX__ \
-DNDEBUG -D__KERNEL__ -I $BASE_DIR/arch/arm/src/chip \
-I $BASE_DIR/arch/arm/src/common -I $BASE_DIR/arch/arm/src/armv7-m \
-I $BASE_DIR/sched chip/stm32_irq.c -o /tmp/stm32_irq.c
# So far no errors (yes, get a preprocessow warning, can ignore)
The above should just generate a preprofcessing warning. Now it gets
strange:
# Remove _all_ the preprocessor generated linemarkers and compile again:
sed -ie '/^#/d' /tmp/stm32_irq.c
arm-none-eabi-gcc -E $COMPILER_OPTIONS $BASE_DIR/include -D__NuttX__ \
-DNDEBUG -D__KERNEL__ -I $BASE_DIR/arch/arm/src/chip \
-I $BASE_DIR/arch/arm/src/common -I $BASE_DIR/arch/arm/src/armv7-m \
-I $BASE_DIR/sched chip/stm32_irq.c -o /tmp/stm32_irq.c
And now I see format warnings (here's the first):
/tmp/stm32_irq.c: In function 'stm32_dumpnvic':
/tmp/stm32_irq.c:4875:12: warning: format '%x' expects argument of type
'unsigned int', but argument 4 has type 'uint32_t' {aka 'long unsigned int'}
[-Wformat=]
4875 | syslog(6, "%s: "
| ^~~~~~
......
4878 | getreg32((0xe000e000 + 0x0d04)), getreg32((0xe000e000 + 0x0d08))
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| |
| uint32_t {aka long unsigned int}
/tmp/stm32_irq.c:4876:20: note: format string is defined here
4876 | " INTCTRL: %08x VECTAB: %08x\n"
| ~~~^
| |
| unsigned int
| %08lx
Could someone who builds stm32 on Ubuntu try out above commands
(changing BASE_DIR to match your tree) and tell me if you see same
results where format warnings magically appear? Any ideas why gcc
generates format warnings over same source - only after removing all the
preprocessor linemarkers?
Thanks in advance!
--
Peter Barada
[email protected]
--
Peter Barada
[email protected]
--
Peter Barada
[email protected]
