On Sun, 12 Jan 2025, David Malcolm wrote: > So I've dropped the takes_int_p, takes_void_p, and > maybe_inform_empty_args_c23_transition from the patch. Here's an > updated version that keeps the rest of the changes. I'd like to get > this into GCC 15 to make build failures due to C23-incompatibilities > more readable.
Some comments in testcases still repeat the misconception about implicit (int) for unprototyped functions. OK with that fixed. > diff --git a/gcc/testsuite/gcc.dg/c23-mismatching-fn-ptr-alsatools.c > b/gcc/testsuite/gcc.dg/c23-mismatching-fn-ptr-alsatools.c > new file mode 100644 > index 000000000000..e3460e546a9a > --- /dev/null > +++ b/gcc/testsuite/gcc.dg/c23-mismatching-fn-ptr-alsatools.c > @@ -0,0 +1,21 @@ > +/* Examples of a mismatching function pointer types in > + legacy code compiled with C23 that assumed () meant (int). This comment is incorrect, unprototyped is not (int). > diff --git a/gcc/testsuite/gcc.dg/c23-mismatching-fn-ptr.c > b/gcc/testsuite/gcc.dg/c23-mismatching-fn-ptr.c > new file mode 100644 > index 000000000000..4db44f48a3f2 > --- /dev/null > +++ b/gcc/testsuite/gcc.dg/c23-mismatching-fn-ptr.c > @@ -0,0 +1,76 @@ > +/* Verify that when we complain about incompatible pointer types > + involving function pointers, we show the declaration of the > + function. > + > + In particular, check the case of > + extern void fn (); > + changing meaning in C23 (from taking int to taking void). */ Likewise. > +/* Test of storing a sighandler_t where the declaration of the > + destination might be relying on implicit int arg, which > + becomes void in C23. Likewise. -- Joseph S. Myers josmy...@redhat.com
