On 2/5/26 11:15 PM, Marek Polacek wrote:
On Thu, Feb 05, 2026 at 02:35:27PM +0900, Jason Merrill wrote:
On 2/5/26 1:53 AM, Marek Polacek wrote:
On Wed, Feb 04, 2026 at 08:06:18PM +0900, Jason Merrill wrote:
On 2/4/26 6:11 AM, Marek Polacek wrote:
Bootstrapped/regtested on ppc64le-pc-linux-gnu, ok for 17.0?
-- >8 --
This implements [class.bit]/2: An unnamed bit-field shall not be
declared with a cv-qualified type. This was clarified in DR 2229.
DR 2229
PR c++/123935
gcc/cp/ChangeLog:
* decl2.cc (grokbitfield): Disallow cv-qualified unnamed bit-fields.
gcc/testsuite/ChangeLog:
* g++.dg/DRs/dr2229.C: New test.
---
gcc/cp/decl2.cc | 9 +++++++++
gcc/testsuite/g++.dg/DRs/dr2229.C | 12 ++++++++++++
2 files changed, 21 insertions(+)
create mode 100644 gcc/testsuite/g++.dg/DRs/dr2229.C
diff --git a/gcc/cp/decl2.cc b/gcc/cp/decl2.cc
index 20ee662eea2..eb2294fffd0 100644
--- a/gcc/cp/decl2.cc
+++ b/gcc/cp/decl2.cc
@@ -1635,6 +1635,15 @@ grokbitfield (const cp_declarator *declarator,
return NULL_TREE;
}
+ /* [class.bit]/2 "An unnamed bit-field shall not be declared with
+ a cv-qualified type." */
+ if (!DECL_NAME (value) && TYPE_QUALS (type) != TYPE_UNQUALIFIED)
+ {
+ error_at (DECL_SOURCE_LOCATION (value),
This seems like a pedwarn rather than an error.
+ "unnamed bit-field cannot be cv-qualified");
+ return NULL_TREE;
...and then continue.
clang++ gives an error, but any diagnostic will do. Thus:
dg.exp passed on x86_64-pc-linux-gnu.
OK, thanks.
Presumably OK for 17.0. Or even trunk?
Yeah, let's save additional diagnostics for 17 at this point.
Jason
