Implement C23 const-preserving standard library macros
Tomáš Glozar
tglozar@gmail.com
Fri Nov 21 12:38:28 GMT 2025
pá 21. 11. 2025 v 11:50 odesílatel Frank Scheiner
<frank.scheiner@web.de> napsal:
>
> On 19.11.25 14:29, Joseph Myers wrote:
> > On Tue, 18 Nov 2025, Paul Eggert wrote:
> >>
> >> With GCC this turns some warnings into errors. For example:
> >>
> >> int
> >> foo (char volatile *p)
> >> {
> >> return !strchr (p, 'x');
> >> }
> >>
> >> is currently a warning, but would become an error. To avoid this problem, you
> >> can change "void *: (CALL)" to "default: (CALL)". Or better, to "default:
> >> CALL" since the parentheses are unnecessary.
> >
> > Note that calling these functions with a pointer-to-volatile has never
> > been valid and still isn't valid (but it's not necessary to turn it into
> > an error if we don't want to do so).
>
> I think what Paul described above is exactly what happens to the
> toolchain builds for ia64 (and possibly other arches) since today (with
> a glibc snapshot that includes v2 of this patch):
>
I think it is a bit different.
> Since today we get (see [1]):
> ```
> libtool: compile: /usr/src/t2-src/src.gcc.ia64-toolchain.251121.040147.278918/gcc-16-20251116/objs/gcc/xgcc-wrapper /usr/src/t2-src/src.gcc.ia64-toolchain.251121.040147.278918/gcc-16-20251116/objs/./gcc/xgcc -B/usr/src/t2-src/src.gcc.ia64-toolchain.251121.040147.278918/gcc-16-20251116/objs/./gcc/ -B/usr/src/t2-src/build/ia64-toolchain-24-svn-generic-ia64-itanium2-cross-linux/TOOLCHAIN/cross/usr/ia64-t2-linux-gnu/bin/ -B/usr/src/t2-src/build/ia64-toolchain-24-svn-generic-ia64-itanium2-cross-linux/TOOLCHAIN/cross/usr/ia64-t2-linux-gnu/lib/ -isystem /usr/src/t2-src/build/ia64-toolchain-24-svn-generic-ia64-itanium2-cross-linux/TOOLCHAIN/cross/usr/ia64-t2-linux-gnu/include -isystem /usr/src/t2-src/build/ia64-toolchain-24-svn-generic-ia64-itanium2-cross-linux/TOOLCHAIN/cross/usr/ia64-t2-linux-gnu/sys-include --sysroot=/usr/src/t2-src/build/ia64-toolchain-24-svn-generic-ia64-itanium2-cross-linux -DHAVE_CONFIG_H -I. -I../../../libgomp -I../../../libgomp/config/linux/ia64 -I../../../libgomp/config/linux -I../../../libgomp/config/posix -I../../../libgomp -I../../../libgomp/../include -Wall -Werror -ftls-model=initial-exec -pthread -DUSING_INITIAL_EXEC_TLS -g -O2 -MT oacc-cuda.lo -MD -MP -MF .deps/oacc-cuda.Tpo -c ../../../libgomp/oacc-cuda.c -o oacc-cuda.o >/dev/null 2>&1
> ../../../libgomp/affinity-fmt.c: In function 'gomp_display_affinity':
> ../../../libgomp/affinity-fmt.c:330:25: error: initialization discards 'const' qualifier from pointer target type [-Werror=discarded-qualifiers]
> 330 | char *q = strchr (p + 1, '}');
> | ^~~~~~
> ```
> ...breaking the GCC builds.
>
"p" is const char *. According to the commit mesage, in C23, strchr
into const char * is also a const char *. So this warning/error is
correct. Note that this is unlike the example above, where the types
are char volatile * and int. That should not cause an error, but it
does due to an oversight in a patch, IIUC.
> [1]: https://github.com/johnny-mnemonic/toolchain-autobuilds/actions/runs/19559235881
>
> Yesterday the same GCC snapshot (gcc-16-20251116) still built fine,
> with glibc snapshot still based on
> 92186652d8653993ca51e97b895baf7edc745794 (i.e. before the v2 patch got
> committed), see [2].
>
> [2]: https://github.com/johnny-mnemonic/toolchain-autobuilds/actions/runs/19524864959
>
> The question is, where this should be fixed? In glibc or in GCC?
>
With respect to the above, it seems that GCC should be tweaked to
compile correctly with C23. See this snippet in the commit that does a
similar thing for a glibc header:
diff --git a/debug/tst-backtrace.h b/debug/tst-backtrace.h
index e1c0a82777..a48ac0f4a8 100644
--- a/debug/tst-backtrace.h
+++ b/debug/tst-backtrace.h
@@ -43,6 +43,6 @@ volatile int x;
static inline bool
match (const char *sym, const char *name)
{
- char *p = strchr (sym, '(');
+ const char *p = strchr (sym, '(');
return p != NULL && strstr (p, name) != NULL;
}
(Unless the GCC snapshot is not building with C23 and the logic is
picked up incorrectly.)
Tomas
More information about the Libc-alpha
mailing list