This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Bug or feature - merging linkage declarations from static forced-inline functions


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]