Hi!
I've compiled gcc 8.0.1-RC-20180427 to test it with my projects.
There's one new warning for which I cannot tell whether this is a bug
in headers or a bug in gcc.
I have a header from ARM that looks like this (there are more such
functions than these two):
-- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 --
#define __STATIC_FORCEINLINE __attribute__((always_inline))
static inline
...
__STATIC_FORCEINLINE uint64_t __SMLALD (uint32_t op1, uint32_t op2, uint64_t
acc)
{
union llreg_u{
uint32_t w32[2];
uint64_t w64;
} llr;
llr.w64 = acc;
#ifndef __ARMEB__ /* Little endian */
__ASM volatile ("smlald %0, %1, %2, %3" : "=r" (llr.w32[0]), "=r"
(llr.w32[1]): "r" (op1), "r" (op2) , "0" (llr.w32[0]), "1" (llr.w32[1]) );
#else /* Big endian */
__ASM volatile ("smlald %0, %1, %2, %3" : "=r" (llr.w32[1]), "=r"
(llr.w32[0]): "r" (op1), "r" (op2) , "0" (llr.w32[1]), "1" (llr.w32[0]) );
#endif
return(llr.w64);
}
__STATIC_FORCEINLINE uint64_t __SMLALDX (uint32_t op1, uint32_t op2, uint64_t
acc)
{
union llreg_u{
uint32_t w32[2];
uint64_t w64;
} llr;
llr.w64 = acc;
#ifndef __ARMEB__ /* Little endian */
__ASM volatile ("smlaldx %0, %1, %2, %3" : "=r" (llr.w32[0]), "=r"
(llr.w32[1]): "r" (op1), "r" (op2) , "0" (llr.w32[0]), "1" (llr.w32[1]) );
#else /* Big endian */
__ASM volatile ("smlaldx %0, %1, %2, %3" : "=r" (llr.w32[1]), "=r"
(llr.w32[0]): "r" (op1), "r" (op2) , "0" (llr.w32[1]), "1" (llr.w32[0]) );
#endif
return(llr.w64);
}
-- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 --
https://github.com/ARM-software/CMSIS_5/blob/develop/CMSIS/Core/Include/cmsis_gcc.h#L1929
Important thing here is that I do _NOT_ use any of these functions in
the code - they are just in the headers.
However GCC behaves as if it would merge all these functions into one
code block (via copy & paste), so it sees all the
definitions/declarations of llr as conflicting:
-- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 --
In file included from
source/architecture/ARM/ARMv6-M-ARMv7-M/external/CMSIS/cmsis_compiler.h:48,
from
source/architecture/ARM/ARMv6-M-ARMv7-M/external/CMSIS/core_cm4.h:162,
from
source/chip/STM32/STM32F4/external/CMSIS-STM32F4/stm32f407xx.h:183,
from
source/chip/STM32/STM32F4/external/CMSIS-STM32F4/stm32f4xx.h:151,
from
source/chip/STM32/STM32F4/include/distortos/chip/CMSIS-proxy.h:69,
from
source/architecture/ARM/ARMv6-M-ARMv7-M/ARMv6-M-ARMv7-M-requestFunctionExecution.cpp:16:
source/architecture/ARM/ARMv6-M-ARMv7-M/external/CMSIS/cmsis_gcc.h: In function
'uint64_t __SMLALDX(uint32_t, uint32_t, uint64_t)':
source/architecture/ARM/ARMv6-M-ARMv7-M/external/CMSIS/cmsis_gcc.h:1947:5:
warning: conflicting C language linkage declaration '__SMLALDX(uint32_t,
uint32_t, uint64_t)::llreg_u llr'
} llr;
^~~
In file included from
source/architecture/ARM/ARMv6-M-ARMv7-M/external/CMSIS/cmsis_compiler.h:48,
from
source/architecture/ARM/ARMv6-M-ARMv7-M/external/CMSIS/core_cm4.h:162,
from
source/chip/STM32/STM32F4/external/CMSIS-STM32F4/stm32f407xx.h:183,
from
source/chip/STM32/STM32F4/external/CMSIS-STM32F4/stm32f4xx.h:151,
from
source/chip/STM32/STM32F4/include/distortos/chip/CMSIS-proxy.h:69,
from
source/architecture/ARM/ARMv6-M-ARMv7-M/ARMv6-M-ARMv7-M-requestFunctionExecution.cpp:16:
source/architecture/ARM/ARMv6-M-ARMv7-M/external/CMSIS/cmsis_gcc.h:1930:5:
note: previous declaration '__SMLALD(uint32_t, uint32_t, uint64_t)::llreg_u llr'
} llr;
^~~
-- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 --
Now my question is - who is right here: are the headers correct nad gcc
wrong, or are the headers wrong and gcc right? This code was warning
free for previous versions of gcc. I'm asking because I'm not sure
where should I file the bug - in ARM CMSIS or in gcc's bugzilla.
Regards and thanks for info,
FCh
