* [PATCH] c, c++: alignas and alignof void [PR104944]
@ 2022-03-24 15:49 Marek Polacek
2022-03-24 16:02 ` Jason Merrill
0 siblings, 1 reply; 7+ messages in thread
From: Marek Polacek @ 2022-03-24 15:49 UTC (permalink / raw)
To: Joseph Myers, Jason Merrill, GCC Patches
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.
(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.)
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
PR c++/104944
gcc/c-family/ChangeLog:
* c-common.cc (c_sizeof_or_alignof_type): Do not allow alignof(void).
gcc/cp/ChangeLog:
* typeck.cc (cxx_alignas_expr): Call cxx_sizeof_or_alignof_type with
complain == true.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/alignas20.C: New test.
* gcc.dg/c11-align-10.c: New test.
---
gcc/c-family/c-common.cc | 20 +++++++++++++++-----
gcc/cp/typeck.cc | 14 ++++++++------
gcc/testsuite/g++.dg/cpp0x/alignas20.C | 24 ++++++++++++++++++++++++
gcc/testsuite/gcc.dg/c11-align-10.c | 18 ++++++++++++++++++
4 files changed, 65 insertions(+), 11 deletions(-)
create mode 100644 gcc/testsuite/g++.dg/cpp0x/alignas20.C
create mode 100644 gcc/testsuite/gcc.dg/c11-align-10.c
diff --git a/gcc/c-family/c-common.cc b/gcc/c-family/c-common.cc
index d034837bb5b..8b76eba64c2 100644
--- a/gcc/c-family/c-common.cc
+++ b/gcc/c-family/c-common.cc
@@ -3849,7 +3849,7 @@ c_common_get_alias_set (tree t)
the IS_SIZEOF parameter indicates which operator is being applied.
The COMPLAIN flag controls whether we should diagnose possibly
ill-formed constructs or not. LOC is the location of the SIZEOF or
- TYPEOF operator. If MIN_ALIGNOF, the least alignment required for
+ ALIGNOF operator. If MIN_ALIGNOF, the least alignment required for
a type in any context should be returned, rather than the normal
alignment for that type. */
@@ -3891,10 +3891,20 @@ c_sizeof_or_alignof_type (location_t loc,
}
else if (type_code == VOID_TYPE || type_code == ERROR_MARK)
{
- if (type_code == VOID_TYPE
- && complain && warn_pointer_arith)
- pedwarn (loc, OPT_Wpointer_arith,
- "invalid application of %qs to a void type", op_name);
+ if (type_code == VOID_TYPE && complain)
+ {
+ /* sizeof(void) is a GNU extension. */
+ if (is_sizeof)
+ pedwarn (loc, OPT_Wpointer_arith,
+ "invalid application of %qs to a void type", op_name);
+ /* But alignof(void) is not. */
+ else
+ {
+ error_at (loc, "invalid application of %qs to a void type",
+ op_name);
+ return error_mark_node;
+ }
+ }
else if (!complain)
return error_mark_node;
value = size_one_node;
diff --git a/gcc/cp/typeck.cc b/gcc/cp/typeck.cc
index 516fa574ef6..96653c4f96e 100644
--- a/gcc/cp/typeck.cc
+++ b/gcc/cp/typeck.cc
@@ -1873,9 +1873,9 @@ compparms (const_tree parms1, const_tree parms2)
}
\f
-/* 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
@@ -2132,11 +2132,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..f04f27927e2
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/alignas20.C
@@ -0,0 +1,24 @@
+// PR c++/104944
+// { dg-do compile { target c++11 } }
+
+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(inc); // { dg-error "invalid application" }
+}
diff --git a/gcc/testsuite/gcc.dg/c11-align-10.c b/gcc/testsuite/gcc.dg/c11-align-10.c
new file mode 100644
index 00000000000..9943113fda2
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/c11-align-10.c
@@ -0,0 +1,18 @@
+/* PR c++/104944 */
+/* { dg-do compile } */
+/* { dg-options "-std=c11 -pedantic-errors" } */
+
+extern int a[];
+
+struct S {
+ _Alignas(void) int arr1[10]; /* { dg-error "invalid application" } */
+ _Alignas(__typeof(a)) int arr2[10]; /* { dg-error "invalid application" } */
+};
+
+void
+g ()
+{
+ int s1 = _Alignof(void); /* { dg-error "invalid application" } */
+ int s2 = _Alignof(const void); /* { dg-error "invalid application" } */
+ int s3 = _Alignof(__typeof(a)); /* { dg-error "invalid application" } */
+}
base-commit: a3f78748fab6b24e3d4a8b319afd3f8afa17248f
--
2.35.1
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] c, c++: alignas and alignof void [PR104944]
2022-03-24 15:49 [PATCH] c, c++: alignas and alignof void [PR104944] Marek Polacek
@ 2022-03-24 16:02 ` Jason Merrill
2022-03-24 19:56 ` [PATCH v2] " Marek Polacek
0 siblings, 1 reply; 7+ messages in thread
From: Jason Merrill @ 2022-03-24 16:02 UTC (permalink / raw)
To: Marek Polacek, Joseph Myers, GCC Patches
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.
> (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.)
>
> Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
>
> PR c++/104944
>
> gcc/c-family/ChangeLog:
>
> * c-common.cc (c_sizeof_or_alignof_type): Do not allow alignof(void).
>
> gcc/cp/ChangeLog:
>
> * typeck.cc (cxx_alignas_expr): Call cxx_sizeof_or_alignof_type with
> complain == true.
>
> gcc/testsuite/ChangeLog:
>
> * g++.dg/cpp0x/alignas20.C: New test.
> * gcc.dg/c11-align-10.c: New test.
> ---
> gcc/c-family/c-common.cc | 20 +++++++++++++++-----
> gcc/cp/typeck.cc | 14 ++++++++------
> gcc/testsuite/g++.dg/cpp0x/alignas20.C | 24 ++++++++++++++++++++++++
> gcc/testsuite/gcc.dg/c11-align-10.c | 18 ++++++++++++++++++
> 4 files changed, 65 insertions(+), 11 deletions(-)
> create mode 100644 gcc/testsuite/g++.dg/cpp0x/alignas20.C
> create mode 100644 gcc/testsuite/gcc.dg/c11-align-10.c
>
> diff --git a/gcc/c-family/c-common.cc b/gcc/c-family/c-common.cc
> index d034837bb5b..8b76eba64c2 100644
> --- a/gcc/c-family/c-common.cc
> +++ b/gcc/c-family/c-common.cc
> @@ -3849,7 +3849,7 @@ c_common_get_alias_set (tree t)
> the IS_SIZEOF parameter indicates which operator is being applied.
> The COMPLAIN flag controls whether we should diagnose possibly
> ill-formed constructs or not. LOC is the location of the SIZEOF or
> - TYPEOF operator. If MIN_ALIGNOF, the least alignment required for
> + ALIGNOF operator. If MIN_ALIGNOF, the least alignment required for
> a type in any context should be returned, rather than the normal
> alignment for that type. */
>
> @@ -3891,10 +3891,20 @@ c_sizeof_or_alignof_type (location_t loc,
> }
> else if (type_code == VOID_TYPE || type_code == ERROR_MARK)
> {
> - if (type_code == VOID_TYPE
> - && complain && warn_pointer_arith)
> - pedwarn (loc, OPT_Wpointer_arith,
> - "invalid application of %qs to a void type", op_name);
> + if (type_code == VOID_TYPE && complain)
> + {
> + /* sizeof(void) is a GNU extension. */
> + if (is_sizeof)
> + pedwarn (loc, OPT_Wpointer_arith,
> + "invalid application of %qs to a void type", op_name);
> + /* But alignof(void) is not. */
> + else
> + {
> + error_at (loc, "invalid application of %qs to a void type",
> + op_name);
> + return error_mark_node;
> + }
> + }
> else if (!complain)
> return error_mark_node;
> value = size_one_node;
> diff --git a/gcc/cp/typeck.cc b/gcc/cp/typeck.cc
> index 516fa574ef6..96653c4f96e 100644
> --- a/gcc/cp/typeck.cc
> +++ b/gcc/cp/typeck.cc
> @@ -1873,9 +1873,9 @@ compparms (const_tree parms1, const_tree parms2)
> }
>
> \f
> -/* 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
> @@ -2132,11 +2132,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..f04f27927e2
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/cpp0x/alignas20.C
> @@ -0,0 +1,24 @@
> +// PR c++/104944
> +// { dg-do compile { target c++11 } }
> +
> +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(inc); // { dg-error "invalid application" }
> +}
> diff --git a/gcc/testsuite/gcc.dg/c11-align-10.c b/gcc/testsuite/gcc.dg/c11-align-10.c
> new file mode 100644
> index 00000000000..9943113fda2
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/c11-align-10.c
> @@ -0,0 +1,18 @@
> +/* PR c++/104944 */
> +/* { dg-do compile } */
> +/* { dg-options "-std=c11 -pedantic-errors" } */
> +
> +extern int a[];
> +
> +struct S {
> + _Alignas(void) int arr1[10]; /* { dg-error "invalid application" } */
> + _Alignas(__typeof(a)) int arr2[10]; /* { dg-error "invalid application" } */
> +};
> +
> +void
> +g ()
> +{
> + int s1 = _Alignof(void); /* { dg-error "invalid application" } */
> + int s2 = _Alignof(const void); /* { dg-error "invalid application" } */
> + int s3 = _Alignof(__typeof(a)); /* { dg-error "invalid application" } */
> +}
>
> base-commit: a3f78748fab6b24e3d4a8b319afd3f8afa17248f
^ permalink raw reply [flat|nested] 7+ messages in thread
* [PATCH v2] c++: alignas and alignof void [PR104944]
2022-03-24 16:02 ` Jason Merrill
@ 2022-03-24 19:56 ` Marek Polacek
2022-03-24 21:12 ` Jason Merrill
0 siblings, 1 reply; 7+ messages in thread
From: Marek Polacek @ 2022-03-24 19:56 UTC (permalink / raw)
To: Jason Merrill; +Cc: Joseph Myers, GCC Patches
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?
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >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, so I'd like to reject it in C too, but it's
probably not a good time to do so in stage4.
(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/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.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/alignas20.C: New test.
---
gcc/c-family/c-common.cc | 20 +++++++++++++++-----
gcc/cp/typeck.cc | 14 ++++++++------
gcc/testsuite/g++.dg/cpp0x/alignas20.C | 24 ++++++++++++++++++++++++
3 files changed, 47 insertions(+), 11 deletions(-)
create mode 100644 gcc/testsuite/g++.dg/cpp0x/alignas20.C
diff --git a/gcc/c-family/c-common.cc b/gcc/c-family/c-common.cc
index d034837bb5b..f99717f540b 100644
--- a/gcc/c-family/c-common.cc
+++ b/gcc/c-family/c-common.cc
@@ -3849,7 +3849,7 @@ c_common_get_alias_set (tree t)
the IS_SIZEOF parameter indicates which operator is being applied.
The COMPLAIN flag controls whether we should diagnose possibly
ill-formed constructs or not. LOC is the location of the SIZEOF or
- TYPEOF operator. If MIN_ALIGNOF, the least alignment required for
+ ALIGNOF operator. If MIN_ALIGNOF, the least alignment required for
a type in any context should be returned, rather than the normal
alignment for that type. */
@@ -3891,10 +3891,20 @@ c_sizeof_or_alignof_type (location_t loc,
}
else if (type_code == VOID_TYPE || type_code == ERROR_MARK)
{
- if (type_code == VOID_TYPE
- && complain && warn_pointer_arith)
- pedwarn (loc, OPT_Wpointer_arith,
- "invalid application of %qs to a void type", op_name);
+ if (type_code == VOID_TYPE && complain)
+ {
+ /* sizeof(void) is a GNU extension. */
+ if (is_sizeof || !c_dialect_cxx ())
+ pedwarn (loc, OPT_Wpointer_arith,
+ "invalid application of %qs to a void type", op_name);
+ /* But alignof(void) is not (in C++). */
+ else
+ {
+ error_at (loc, "invalid application of %qs to a void type",
+ op_name);
+ return error_mark_node;
+ }
+ }
else if (!complain)
return error_mark_node;
value = size_one_node;
diff --git a/gcc/cp/typeck.cc b/gcc/cp/typeck.cc
index 516fa574ef6..96653c4f96e 100644
--- a/gcc/cp/typeck.cc
+++ b/gcc/cp/typeck.cc
@@ -1873,9 +1873,9 @@ compparms (const_tree parms1, const_tree parms2)
}
\f
-/* 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
@@ -2132,11 +2132,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..f04f27927e2
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/alignas20.C
@@ -0,0 +1,24 @@
+// PR c++/104944
+// { dg-do compile { target c++11 } }
+
+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(inc); // { dg-error "invalid application" }
+}
base-commit: 346ab5a54a831ad9c78afcbd8dfe98e0e07e3070
--
2.35.1
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH v2] c++: alignas and alignof void [PR104944]
2022-03-24 19:56 ` [PATCH v2] " Marek Polacek
@ 2022-03-24 21:12 ` Jason Merrill
2022-03-24 22:43 ` [PATCH v3] " Marek Polacek
0 siblings, 1 reply; 7+ messages in thread
From: Jason Merrill @ 2022-03-24 21:12 UTC (permalink / raw)
To: Marek Polacek; +Cc: Joseph Myers, GCC Patches
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.
> Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
>
> -- >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, so I'd like to reject it in C too, but it's
> probably not a good time to do so in stage4.
>
> (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/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.
> gcc/testsuite/ChangeLog:
>
> * g++.dg/cpp0x/alignas20.C: New test.
> ---
> gcc/c-family/c-common.cc | 20 +++++++++++++++-----
> gcc/cp/typeck.cc | 14 ++++++++------
> gcc/testsuite/g++.dg/cpp0x/alignas20.C | 24 ++++++++++++++++++++++++
> 3 files changed, 47 insertions(+), 11 deletions(-)
> create mode 100644 gcc/testsuite/g++.dg/cpp0x/alignas20.C
>
> diff --git a/gcc/c-family/c-common.cc b/gcc/c-family/c-common.cc
> index d034837bb5b..f99717f540b 100644
> --- a/gcc/c-family/c-common.cc
> +++ b/gcc/c-family/c-common.cc
> @@ -3849,7 +3849,7 @@ c_common_get_alias_set (tree t)
> the IS_SIZEOF parameter indicates which operator is being applied.
> The COMPLAIN flag controls whether we should diagnose possibly
> ill-formed constructs or not. LOC is the location of the SIZEOF or
> - TYPEOF operator. If MIN_ALIGNOF, the least alignment required for
> + ALIGNOF operator. If MIN_ALIGNOF, the least alignment required for
> a type in any context should be returned, rather than the normal
> alignment for that type. */
>
> @@ -3891,10 +3891,20 @@ c_sizeof_or_alignof_type (location_t loc,
> }
> else if (type_code == VOID_TYPE || type_code == ERROR_MARK)
> {
> - if (type_code == VOID_TYPE
> - && complain && warn_pointer_arith)
> - pedwarn (loc, OPT_Wpointer_arith,
> - "invalid application of %qs to a void type", op_name);
> + if (type_code == VOID_TYPE && complain)
> + {
> + /* sizeof(void) is a GNU extension. */
> + if (is_sizeof || !c_dialect_cxx ())
> + pedwarn (loc, OPT_Wpointer_arith,
> + "invalid application of %qs to a void type", op_name);
> + /* But alignof(void) is not (in C++). */
> + else
> + {
> + error_at (loc, "invalid application of %qs to a void type",
> + op_name);
> + return error_mark_node;
> + }
> + }
> else if (!complain)
> return error_mark_node;
> value = size_one_node;
> diff --git a/gcc/cp/typeck.cc b/gcc/cp/typeck.cc
> index 516fa574ef6..96653c4f96e 100644
> --- a/gcc/cp/typeck.cc
> +++ b/gcc/cp/typeck.cc
> @@ -1873,9 +1873,9 @@ compparms (const_tree parms1, const_tree parms2)
> }
>
> \f
> -/* 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
> @@ -2132,11 +2132,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..f04f27927e2
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/cpp0x/alignas20.C
> @@ -0,0 +1,24 @@
> +// PR c++/104944
> +// { dg-do compile { target c++11 } }
> +
> +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(inc); // { dg-error "invalid application" }
> +}
>
> base-commit: 346ab5a54a831ad9c78afcbd8dfe98e0e07e3070
^ permalink raw reply [flat|nested] 7+ messages in thread
* [PATCH v3] c++: alignas and alignof void [PR104944]
2022-03-24 21:12 ` Jason Merrill
@ 2022-03-24 22:43 ` Marek Polacek
2022-03-25 13:36 ` Jason Merrill
0 siblings, 1 reply; 7+ messages in thread
From: Marek Polacek @ 2022-03-24 22:43 UTC (permalink / raw)
To: Jason Merrill; +Cc: Joseph Myers, GCC Patches
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)
}
\f
-/* 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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH v3] c++: alignas and alignof void [PR104944]
2022-03-24 22:43 ` [PATCH v3] " Marek Polacek
@ 2022-03-25 13:36 ` Jason Merrill
2022-03-25 14:04 ` Marek Polacek
0 siblings, 1 reply; 7+ messages in thread
From: Jason Merrill @ 2022-03-25 13:36 UTC (permalink / raw)
To: Marek Polacek; +Cc: Joseph Myers, GCC Patches
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.
> 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)
> }
>
> \f
> -/* 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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH v3] c++: alignas and alignof void [PR104944]
2022-03-25 13:36 ` Jason Merrill
@ 2022-03-25 14:04 ` Marek Polacek
0 siblings, 0 replies; 7+ messages in thread
From: Marek Polacek @ 2022-03-25 14:04 UTC (permalink / raw)
To: Jason Merrill; +Cc: Joseph Myers, GCC Patches
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
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2022-03-25 14:04 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-03-24 15:49 [PATCH] c, c++: alignas and alignof void [PR104944] Marek Polacek
2022-03-24 16:02 ` Jason Merrill
2022-03-24 19:56 ` [PATCH v2] " Marek Polacek
2022-03-24 21:12 ` Jason Merrill
2022-03-24 22:43 ` [PATCH v3] " Marek Polacek
2022-03-25 13:36 ` Jason Merrill
2022-03-25 14:04 ` Marek Polacek
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).