From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 2732638A284F for ; Fri, 7 Oct 2022 15:54:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 2732638A284F Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1665158055; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=vse6m34ELEqE7+H7C3Sjlg+SxRJKEii92VXlaH6stvo=; b=GJ2+HmJlwJha0kQXKlVK/U0wFNkNof2Q6MxtW7ZHLbfCgoxNrWHqod2XYINZmtC7DxTrAl UwAJDgqyV+CmFDAXjGU0NquajAK5Cc6wKqrRrWmJd9ce0RDCgIDPMY2059Es1f456C2wYg 9uPGOA1BqJeDAcIon+DF0k1PBZI8Tkg= Received: from mail-qv1-f71.google.com (mail-qv1-f71.google.com [209.85.219.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-336-P9WEJl3-PVei9KjwJNm4lQ-1; Fri, 07 Oct 2022 11:54:15 -0400 X-MC-Unique: P9WEJl3-PVei9KjwJNm4lQ-1 Received: by mail-qv1-f71.google.com with SMTP id t19-20020a056214119300b004b03f58b1abso3165070qvv.17 for ; Fri, 07 Oct 2022 08:54:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:references:message-id:in-reply-to:subject:cc:to:date :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=vse6m34ELEqE7+H7C3Sjlg+SxRJKEii92VXlaH6stvo=; b=iQVhhYbPDKzparKhv8cDm17pwVHziIZwm8yQEPVPvYRC6lbsiXNn1LunSF0BmZbOCx QfiClX4V7M3k6Imbhi5qn/NupOsLHnu3ADHJdU3LK7PxH4qVF4fwPsxbEA4us8FwU+sc bR6YXLiE0XPXgkqEEyIhXoDk0Ui/cq9HeSw1qzljmUNOgqJbwpqOs0qGNSBz17xYi27G Cx4XkRGuSw/aFXnBXKwTST0CTCupZAS8gldFBIaqzeUC+1pcl3iCPlWEuk8RJD+DlroF asWTJiBU5sQLwLtwKdINfsEIa3yIUICi0O+wDYycqNXXEL1mboROK7zg8gjxKkg07fdj FQ1w== X-Gm-Message-State: ACrzQf3u4EA3Agm6hHzyhyc5z5I1zs//VOyxBF4EXhGkLwsKZguVub0D tE26sqlie6XhV/GxKx/MWxtIP2fB+r6JROYh2x0ChABpgsK443FKqbD1QCXtjgFIAIcvfX6s1Om RanICDEQxkc8+v8gHLg== X-Received: by 2002:ac8:4e8d:0:b0:35d:5047:9dec with SMTP id 13-20020ac84e8d000000b0035d50479decmr4620963qtp.259.1665158054022; Fri, 07 Oct 2022 08:54:14 -0700 (PDT) X-Google-Smtp-Source: AMsMyM41MlpXhQyCW4+QZfNLmQdQqcJxHuylSWFq5TU/0Yrh9PUob4inAs8icHNiNm8bKnvyO35Mig== X-Received: by 2002:ac8:4e8d:0:b0:35d:5047:9dec with SMTP id 13-20020ac84e8d000000b0035d50479decmr4620944qtp.259.1665158053718; Fri, 07 Oct 2022 08:54:13 -0700 (PDT) Received: from [192.168.1.130] (ool-457670bb.dyn.optonline.net. [69.118.112.187]) by smtp.gmail.com with ESMTPSA id bi39-20020a05620a31a700b006b945519488sm2182818qkb.88.2022.10.07.08.54.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 07 Oct 2022 08:54:13 -0700 (PDT) From: Patrick Palka X-Google-Original-From: Patrick Palka Date: Fri, 7 Oct 2022 11:54:12 -0400 (EDT) To: Nathan Sidwell cc: Patrick Palka , gcc-patches@gcc.gnu.org, jason@redhat.com Subject: Re: [PATCH] c++ modules: ICE with bitfield member in class template In-Reply-To: Message-ID: <0c9897ef-2817-0e4d-b7b0-c4f128ad97f6@idea> References: <20221007150952.102429-1-ppalka@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-14.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Fri, 7 Oct 2022, Nathan Sidwell wrote: > On 10/7/22 11:09, Patrick Palka wrote: > > According to grokbitfield, DECL_BITFIELD_REPRESENTATIVE may "temporarily" > > contain the width of the bitfield until we layout the class type (after > > which it'll contain a FIELD_DECL). But for a class template, it'll always > > be the width since we don't/can't layout dependent types. > > > > Tested on x86_64-pc-linux-gnu, does this look OK for trunk? > > ok, but could you add a comment on why it might not be a decl? Thanks a lot, I added a comment and committed the following: -- >8 -- Subject: [PATCH] c++ modules: ICE with bitfield in class template According to grokbitfield, DECL_BIT_FIELD_REPRESENTATIVE may temporarily contain the width of the bitfield until we layout the class type (after which it'll contain a decl). Thus for a bitfield in a class template it'll always be the width, and this patch makes us avoid ICEing from mark_class_def in this case. gcc/cp/ChangeLog: * module.cc (trees_out::mark_class_def): Guard against DECL_BIT_FIELD_REPRESENTATIVE not being a decl. gcc/testsuite/ChangeLog: * g++.dg/modules/bfield-3.H: New test. --- gcc/cp/module.cc | 6 +++++- gcc/testsuite/g++.dg/modules/bfield-3.H | 8 ++++++++ 2 files changed, 13 insertions(+), 1 deletion(-) create mode 100644 gcc/testsuite/g++.dg/modules/bfield-3.H diff --git a/gcc/cp/module.cc b/gcc/cp/module.cc index cb1929bc5d5..a7c199c00a4 100644 --- a/gcc/cp/module.cc +++ b/gcc/cp/module.cc @@ -11919,7 +11919,11 @@ trees_out::mark_class_def (tree defn) mark_class_member (member); if (TREE_CODE (member) == FIELD_DECL) if (tree repr = DECL_BIT_FIELD_REPRESENTATIVE (member)) - mark_declaration (repr, false); + /* If we're marking a class template definition, then + DECL_BIT_FIELD_REPRESENTATIVE will contain the width + instead of a decl (as set by grokbitfield). */ + if (DECL_P (repr)) + mark_declaration (repr, false); } /* Mark the binfo hierarchy. */ diff --git a/gcc/testsuite/g++.dg/modules/bfield-3.H b/gcc/testsuite/g++.dg/modules/bfield-3.H new file mode 100644 index 00000000000..4fd4db7116a --- /dev/null +++ b/gcc/testsuite/g++.dg/modules/bfield-3.H @@ -0,0 +1,8 @@ +// { dg-additional-options -fmodule-header } +// { dg-module-cmi {} } + +template +struct A { + int x : 1; + int y : N; +}; -- 2.38.0.rc2