diff mbox series

stdatomic: make atomics compatible with GCC-14

Message ID 6fb0cc60744e112cd396dc6ca15d8adc9ade39cf.camel@espressif.com
State New
Headers
Series stdatomic: make atomics compatible with GCC-14 |

Commit Message

Alexey Lapshin July 8, 2024, 7:38 a.m. UTC 
  https://gcc.gnu.org/pipermail/gcc-patches/2023-September/631525.html
brings c_atomic and cxx_atomic definitions into GCC.
This patch makes atomics type detection correct for GCC.
---
 newlib/libc/include/stdatomic.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

-- 
2.34.1

Comments

Sebastian Huber July 9, 2024, 6:14 a.m. UTC | #1 
Hello Alexey,

this file was imported from FreeBSD. So, it would be good to fix this issue first in FreeBSD.

If GCC provides the c_atomic and cxx_atomic extensions, then why can't we use them for this header file?

Independent of this, GCC provides its own stdatomic.h header file for a while which should be found before the Newlib header if you use standard compiler search paths.

----- Am 8. Jul 2024 um 9:38 schrieb Alexey Lapshin alexey.lapshin@espressif.com:

> https://gcc.gnu.org/pipermail/gcc-patches/2023-September/631525.html
> brings c_atomic and cxx_atomic definitions into GCC.
> This patch makes atomics type detection correct for GCC.
> ---
> newlib/libc/include/stdatomic.h | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/newlib/libc/include/stdatomic.h b/newlib/libc/include/stdatomic.h
> index d58e795eb..fb1a7a0c2 100644
> --- a/newlib/libc/include/stdatomic.h
> +++ b/newlib/libc/include/stdatomic.h
> @@ -33,7 +33,8 @@
> #include <sys/cdefs.h>
> #include <sys/_types.h>
> 
> -#if __has_extension(c_atomic) || __has_extension(cxx_atomic)
> +#if defined(__clang__) && \
> +    (__has_extension(c_atomic) || __has_extension(cxx_atomic))
> #define	__CLANG_ATOMICS
> #elif __GNUC_PREREQ__(4, 7)
> #define	__GNUC_ATOMICS
> --
> 2.34.1
Alexey Lapshin July 9, 2024, 6:27 a.m. UTC | #2 
> If GCC provides the c_atomic and cxx_atomic extensions, then why can't we use them for this header file?

To keep code simple. Anyway GCC will go into `#elif __GNUC_PREREQ__(4, 7)` branch
Corinna Vinschen July 9, 2024, 10:38 a.m. UTC | #3 
On Jul  9 06:27, Alexey Lapshin wrote:
> > If GCC provides the c_atomic and cxx_atomic extensions, then why can't we use them for this header file?
> 
> To keep code simple. Anyway GCC will go into `#elif __GNUC_PREREQ__(4, 7)` branch

Ok, but given that GCC actually supports the __CLANG_ATOMICS expression,
I wonder if this isn't just a case of a badly named macro?


Corinna
diff mbox series

Patch

diff --git a/newlib/libc/include/stdatomic.h b/newlib/libc/include/stdatomic.h
index d58e795eb..fb1a7a0c2 100644
--- a/newlib/libc/include/stdatomic.h
+++ b/newlib/libc/include/stdatomic.h
@@ -33,7 +33,8 @@ 
 #include <sys/cdefs.h>
 #include <sys/_types.h>
 
-#if __has_extension(c_atomic) || __has_extension(cxx_atomic)
+#if defined(__clang__) && \
+    (__has_extension(c_atomic) || __has_extension(cxx_atomic))
 #define	__CLANG_ATOMICS
 #elif __GNUC_PREREQ__(4, 7)
 #define	__GNUC_ATOMICS