On Fri, Mar 25, 2022 at 09:36:10AM -0400, Jason Merrill wrote:
> On 3/24/22 18:43, Marek Polacek wrote:
> > On Thu, Mar 24, 2022 at 05:12:12PM -0400, Jason Merrill wrote:
> > > On 3/24/22 15:56, Marek Polacek wrote:
> > > > On Thu, Mar 24, 2022 at 12:02:29PM -0400, Jason Merrill wrote:
> > > > > On 3/24/22 11:49, Marek Polacek wrote:
> > > > > > I started looking into this PR because in GCC 4.9 we were able to
> > > > > > detect the invalid
> > > > > >
> > > > > > struct alignas(void) S{};
> > > > > >
> > > > > > but I broke it in r210262.
> > > > > >
> > > > > > It's ill-formed code in C++:
> > > > > > [dcl.align]/3: "An alignment-specifier of the form alignas(type-id)
> > > > > > has
> > > > > > the same effect as alignas(alignof(type-id))", and [expr.align]/1:
> > > > > > "The operand shall be a type-id representing a complete object type,
> > > > > > or an array thereof, or a reference to one of those types." and void
> > > > > > is not a complete type.
> > > > > >
> > > > > > It's also invalid in C:
> > > > > > 6.7.5: _Alignas(type-name) is equivalent to
> > > > > > _Alignas(_Alignof(type-name))
> > > > > > 6.5.3.4: "The _Alignof operator shall not be applied to a function
> > > > > > type
> > > > > > or an incomplete type."
> > > > > >
> > > > > > We have a GNU extension whereby we treat sizeof(void) as 1, but I
> > > > > > assume
> > > > > > it doesn't apply to alignof, so I'd like to reject it in C too.
> > > > >
> > > > > That makes sense to me in principle, but we've allowed it since the
> > > > > beginning of version control, back when c_alignof was a separate
> > > > > function.
> > > > > Changing that seems questionable for a regression fix.
> > > >
> > > > Ok, that makes sense. How about rejecting alignof(void) in C++ only
> > > > now (where it is a regression), and maybe come back to this in GCC 13
> > > > for C?
> > >
> > > I'd probably just leave it alone for C and __alignof.
> >
> > Fair enough.
> >
> > > > PR c++/104944
> > > >
> > > > gcc/c-family/ChangeLog:
> > > >
> > > > * c-common.cc (c_sizeof_or_alignof_type): Do not allow
> > > > alignof(void)
> > > > in C++.
> > > >
> > > > gcc/cp/ChangeLog:
> > > >
> > > > * typeck.cc (cxx_alignas_expr): Call cxx_sizeof_or_alignof_type
> > > > with
> > > > complain == true.
> > >
> > > This hunk is OK. But let's put the diagnostic in
> > > cxx_sizeof_or_alignof_type, where it can depend on std_alignof.
> >
> > Like so? With this patch __alignof only produces a pedwarn (there's no
> > __alignas to worry about).
> >
> > -- >8 --
> > I started looking into this PR because in GCC 4.9 we were able to
> > detect the invalid
> >
> > struct alignas(void) S{};
> >
> > but I broke it in r210262.
> >
> > It's ill-formed code in C++:
> > [dcl.align]/3: "An alignment-specifier of the form alignas(type-id) has
> > the same effect as alignas(alignof(type-id))", and [expr.align]/1:
> > "The operand shall be a type-id representing a complete object type,
> > or an array thereof, or a reference to one of those types." and void
> > is not a complete type.
> >
> > It's also invalid in C:
> > 6.7.5: _Alignas(type-name) is equivalent to _Alignas(_Alignof(type-name))
> > 6.5.3.4: "The _Alignof operator shall not be applied to a function type
> > or an incomplete type."
> >
> > We have a GNU extension whereby we treat sizeof(void) as 1, but I assume
> > it doesn't apply to alignof, at least in C++. However, __alignof__(void)
> > is still accepted with a -Wpedantic warning.
> >
> > (We still say "invalid application of '__alignof__'" rather than
> > 'alignas' but I felt that fixing that may not be suitable as part of this
> > patch.)
>
> Do we still say '__alignof__' in this version of the patch? Seems like now
> we might as well say 'alignof'. OK with that change.
When diagnosing alignof(void) we now say 'alignof', for __alignof__(void) we
say '__alignof__', but the "incomplete type" diagnostic still always prints
'__alignof__' :(.
I'll fix the note and push, thanks!
Marek
