Raspberry pi Gateway with IRQ doesn't compile

[vlachoudis]

On raspberry pi v4 (latest rasbian 64bit)
When I set the my-rf24-irq-pin and try to compile the development branch I get the error

./hal/architecture/Linux/MyHwLinuxGeneric.h:106:50: error: ambiguating new declaration of ‘uint8_t __hwLock()’
  106 | #define ATOMIC_BLOCK for ( ATOMIC_BLOCK_CLEANUP, __hwLock(); \
      |                                                  ^~~~~~~~
./hal/architecture/Linux/MyHwLinuxGeneric.h:113:29: note: in expansion of macro ‘ATOMIC_BLOCK’
  113 | #define MY_CRITICAL_SECTION ATOMIC_BLOCK
      |                             ^~~~~~~~~~~~
./drivers/CircularBuffer/CircularBuffer.h:161:17: note: in expansion of macro ‘MY_CRITICAL_SECTION’
  161 |                 MY_CRITICAL_SECTION {
      |                 ^~~~~~~~~~~~~~~~~~~
./hal/architecture/Linux/MyHwLinuxGeneric.h:88:24: note: old declaration ‘void __hwLock()’
   88 | static __inline__ void __hwLock()
      |                        ^~~~~~~~
make: *** [Makefile:99: build/examples_linux/mysgw.o] Error 1

$ gcc --version
gcc (Debian 12.2.0-14) 12.2.0

[rossiniscarface]

any news on this?

[trace3k]

Adding my 2 cents here, any news?

[mfalkvidd]

#1562 is likely a fix

[trace3k]

Tried it but does not work on my RPI4 with kernel 6.6 - same error.
But there seems to be much more amiss on kernel 6.6/ Raspian Bookworm as the configure script seems to be unable to autodetect the soc or even the aarch64 flag.

[cvdenzen]

No solution, but probably the cause: raspberrypi/linux#5668

[poehlert]

So, score one for the LLMs? I'm not creating this as a PR because my C++ is pretty meh and this is using some interesting compiler constructs that I'm not familiar with but... I did get it to compile. Still testing my radio.

#define ATOMIC_BLOCK for ( ATOMIC_BLOCK_CLEANUP, __hwLock(); \
                           __atomic_loop ; __atomic_loop = 0 )

This is the offending macro in https://github.com/mysensors/MySensors/blob/3020658f9afcf8cd24dab69ef7e3028a94cb67b2/hal/architecture/Linux/MyHwLinuxGeneric.h#L106C1-L107C63 and it looks like it probably changed in GCC versions and is now getting flagged as the most vexing parse problem. I can't tell if this was always a problem in the past and now the compiler is flagging it or if it compiled differently before but I'm not going to go back and check.

I tried

#define ATOMIC_BLOCK for ( ATOMIC_BLOCK_CLEANUP, (void)__hwLock(); \
                           __atomic_loop ; __atomic_loop = 0 )

then

#define ATOMIC_BLOCK for ( ATOMIC_BLOCK_CLEANUP, __hwLock(), 0; \
                           __atomic_loop ; __atomic_loop = 0 )

and finally

#define ATOMIC_BLOCK for ( ({ ATOMIC_BLOCK_CLEANUP; __hwLock(); }); \
                           __atomic_loop ; __atomic_loop = 0 )

The last fixed the parsing problem but pulled __atomic_loop out of scope (into the compound statement expression). So I ended up just taking the suggestion to rewrite it without using the ATOMIC_BLOCK_CLEANUP macro but essentially copying the code. This has maintainability risks, though unclear if this macros is used in other contexts or just this one off.

"fixed" code is here; of course someone maybe can point out how it is bad or could be better.

#define ATOMIC_BLOCK \
        for (uint8_t __atomic_loop __attribute__((__cleanup__(__hwUnlock))) = (__hwLock(), 1); \
             __atomic_loop ; __atomic_loop = 0)