Message ID | 20250822223123.2078160-1-hjl.tools@gmail.com |
---|---|
State | New |
Headers | show |
Series | Undef __INT64_C/__UINT64_C for glibc build and test | expand |
"H.J. Lu" <hjl.tools@gmail.com> writes: > Since clang 20 defines __INT64_C and __UINT64_C as built-in macros, undef > them for glibc build and test. This fixes BZ #33311. > > Signed-off-by: H.J. Lu <hjl.tools@gmail.com> > --- > include/stdint.h | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/include/stdint.h b/include/stdint.h > index 7f428741d7..8db6187c49 100644 > --- a/include/stdint.h > +++ b/include/stdint.h > @@ -1 +1,6 @@ > +#ifndef _STDINT_H > +/* NB: Clang 20 defines them as built-in macros. */ > +#undef __INT64_C > +#undef __UINT64_C > #include <stdlib/stdint.h> > +#endif Should we just do all the others while we are at it? They are also defined [1]. Confirmed on my system: $ echo | clang -dM -E - | grep -F '_C(' #define __INT16_C(c) c #define __INT32_C(c) c #define __INT64_C(c) c##L #define __INT8_C(c) c #define __INTMAX_C(c) c##L #define __UINT16_C(c) c #define __UINT32_C(c) c##U #define __UINT64_C(c) c##UL #define __UINT8_C(c) c #define __UINTMAX_C(c) c##UL Collin [1] https://github.com/llvm/llvm-project/commit/33ad474c45e6d7a0de7bc75e15e27cf6cb9ff895
On Fri, Aug 22, 2025 at 4:37 PM Collin Funk <collin.funk1@gmail.com> wrote: > > "H.J. Lu" <hjl.tools@gmail.com> writes: > > > Since clang 20 defines __INT64_C and __UINT64_C as built-in macros, undef > > them for glibc build and test. This fixes BZ #33311. > > > > Signed-off-by: H.J. Lu <hjl.tools@gmail.com> > > --- > > include/stdint.h | 5 +++++ > > 1 file changed, 5 insertions(+) > > > > diff --git a/include/stdint.h b/include/stdint.h > > index 7f428741d7..8db6187c49 100644 > > --- a/include/stdint.h > > +++ b/include/stdint.h > > @@ -1 +1,6 @@ > > +#ifndef _STDINT_H > > +/* NB: Clang 20 defines them as built-in macros. */ > > +#undef __INT64_C > > +#undef __UINT64_C > > #include <stdlib/stdint.h> > > +#endif > > Should we just do all the others while we are at it? They are also Since stdint.h defines only __INT64_C and __UINT64_C, we don't need to do more than that. > defined [1]. Confirmed on my system: > > $ echo | clang -dM -E - | grep -F '_C(' > #define __INT16_C(c) c > #define __INT32_C(c) c > #define __INT64_C(c) c##L > #define __INT8_C(c) c > #define __INTMAX_C(c) c##L > #define __UINT16_C(c) c > #define __UINT32_C(c) c##U > #define __UINT64_C(c) c##UL > #define __UINT8_C(c) c > #define __UINTMAX_C(c) c##UL > > Collin > > [1] https://github.com/llvm/llvm-project/commit/33ad474c45e6d7a0de7bc75e15e27cf6cb9ff895
"H.J. Lu" <hjl.tools@gmail.com> writes: >> > +/* NB: Clang 20 defines them as built-in macros. */ >> > +#undef __INT64_C >> > +#undef __UINT64_C >> > #include <stdlib/stdint.h> >> > +#endif >> >> Should we just do all the others while we are at it? They are also > > Since stdint.h defines only __INT64_C and __UINT64_C, we don't > need to do more than that. Ah right, __U?INT64_C is defined because 32-bit and 64-bit systems have different definitions (i.e. using L vs LL). The others are the same. I assumed they existed, my bad. This patch is good then. Thanks. Reviewed-by: Collin Funk <collin.funk1@gmail.com> Collin
diff --git a/include/stdint.h b/include/stdint.h index 7f428741d7..8db6187c49 100644 --- a/include/stdint.h +++ b/include/stdint.h @@ -1 +1,6 @@ +#ifndef _STDINT_H +/* NB: Clang 20 defines them as built-in macros. */ +#undef __INT64_C +#undef __UINT64_C #include <stdlib/stdint.h> +#endif
Since clang 20 defines __INT64_C and __UINT64_C as built-in macros, undef them for glibc build and test. This fixes BZ #33311. Signed-off-by: H.J. Lu <hjl.tools@gmail.com> --- include/stdint.h | 5 +++++ 1 file changed, 5 insertions(+)