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.) PR c++/104944 gcc/cp/ChangeLog: * typeck.cc (cxx_sizeof_or_alignof_type): Diagnose alignof(void). (cxx_alignas_expr): Call cxx_sizeof_or_alignof_type with complain == true. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/alignas20.C: New test. --- gcc/cp/typeck.cc | 21 +++++++++++++++------ gcc/testsuite/g++.dg/cpp0x/alignas20.C | 26 ++++++++++++++++++++++++++ 2 files changed, 41 insertions(+), 6 deletions(-) create mode 100644 gcc/testsuite/g++.dg/cpp0x/alignas20.C diff --git a/gcc/cp/typeck.cc b/gcc/cp/typeck.cc index 516fa574ef6..26a7cb4b50d 100644 --- a/gcc/cp/typeck.cc +++ b/gcc/cp/typeck.cc @@ -1873,9 +1873,9 @@ compparms (const_tree parms1, const_tree parms2) } -/* Process a sizeof or alignof expression where the operand is a - type. STD_ALIGNOF indicates whether an alignof has C++11 (minimum alignment) - or GNU (preferred alignment) semantics; it is ignored if op is +/* Process a sizeof or alignof expression where the operand is a type. + STD_ALIGNOF indicates whether an alignof has C++11 (minimum alignment) + or GNU (preferred alignment) semantics; it is ignored if OP is SIZEOF_EXPR. */ tree @@ -1899,6 +1899,13 @@ cxx_sizeof_or_alignof_type (location_t loc, tree type, enum tree_code op, else return error_mark_node; } + else if (VOID_TYPE_P (type) && std_alignof) + { + if (complain) + error_at (loc, "invalid application of %qs to a void type", + OVL_OP_INFO (false, op)->name); + return error_mark_node; + } bool dependent_p = dependent_type_p (type); if (!dependent_p) @@ -2132,11 +2139,13 @@ cxx_alignas_expr (tree e) /* [dcl.align]/3: When the alignment-specifier is of the form - alignas(type-id ), it shall have the same effect as - alignas(alignof(type-id )). */ + alignas(type-id), it shall have the same effect as + alignas(alignof(type-id)). */ return cxx_sizeof_or_alignof_type (input_location, - e, ALIGNOF_EXPR, true, false); + e, ALIGNOF_EXPR, + /*std_alignof=*/true, + /*complain=*/true); /* If we reach this point, it means the alignas expression if of the form "alignas(assignment-expression)", so we should follow diff --git a/gcc/testsuite/g++.dg/cpp0x/alignas20.C b/gcc/testsuite/g++.dg/cpp0x/alignas20.C new file mode 100644 index 00000000000..01a55f3d4a4 --- /dev/null +++ b/gcc/testsuite/g++.dg/cpp0x/alignas20.C @@ -0,0 +1,26 @@ +// PR c++/104944 +// { dg-do compile { target c++11 } } +// { dg-options "-Wpedantic" } + +struct inc; + +struct alignas(inc) S1 { }; // { dg-error "invalid application" } +struct alignas(void) S2 { }; // { dg-error "invalid application" } + +template <typename T> +struct alignas(T) S4 {}; // { dg-error "invalid application" } + +template <typename T> +struct alignas(T) S5 {}; // { dg-error "invalid application" } + +S4<void> s1; +S5<inc> s2; + +void +g () +{ + auto s1 = alignof(void); // { dg-error "invalid application" } + auto s2 = alignof(const void); // { dg-error "invalid application" } + auto s3 = __alignof(void); // { dg-warning "invalid application" } + auto s4 = alignof(inc); // { dg-error "invalid application" } +} base-commit: 346ab5a54a831ad9c78afcbd8dfe98e0e07e3070 -- 2.35.1