On Wed, 20 Nov 2024, Jakub Jelinek wrote:
> On Tue, Nov 19, 2024 at 11:08:03PM +0000, Joseph Myers wrote:
> > > --- gcc/testsuite/gcc.dg/gnu11-empty-init-1.c.jj 2024-10-15
> > > 16:14:23.411063701 +0200
> > > +++ gcc/testsuite/gcc.dg/gnu11-empty-init-1.c 2024-10-15
> > > 16:31:02.302984714 +0200
> > > @@ -0,0 +1,199 @@
> > > +/* Test GNU C11 support for empty initializers. */
> > > +/* { dg-do run } */
> > > +/* { dg-options "-std=gnu23" } */
> >
> > All these gnu11-*.c tests are using -std=gnu23, which doesn't make sense.
> > If they're meant to test what GCC does in C11 mode, use -std=gnu11; if
> > they're meant to use -std=gnu23, name them gnu23-*.c. (In either case,
> > the tests might, as now, also have -fzero-init-padding-bits= options when
> > that's part of what they're meant to test.)
>
> Oops, sorry, good catch.
> Yes, all tests meant to use -std=gnu11. Here is an updated patch with
> that
> sed -i -e s/-std=gnu23/-std=gnu11/ gcc/testsuite/gcc.dg/gnu11-empty-init*.c
> The tests still pass. Note, -std=gnu23 instead of -std=gnu11 just clears
> perhaps some more padding bits in some places, but the tests are actually
> just testing when (my reading of) the C23 standard or these new options
> imply the padding bits should be zero; the tests actually don't check that
> those bits aren't zero otherwise, as that is UB and the memset from some
> other call to -1 might not keep everything still non-zero; and testing
> e.g. gimple dumps that the zeroing doesn't occur isn't bullet proof either,
> as the gimplifier in various cases just for optimization purposes decides
> to zero anyway.
>
> Smoke tested so far, will do full bootstrap/regtest momentarily.
The C front-end / testsuite changes in the revised patch are OK
(c23-empty-init-4.c will need renaming since I've added another test with
that name today).
--
Joseph S. Myers
josmy...@redhat.com
