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.129.124]) by sourceware.org (Postfix) with ESMTPS id 41A083945C1A for ; Fri, 1 Apr 2022 09:02:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 41A083945C1A Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-1-xZmo2RdjNOSKw5p18DjVuQ-1; Fri, 01 Apr 2022 05:02:29 -0400 X-MC-Unique: xZmo2RdjNOSKw5p18DjVuQ-1 Received: from smtp.corp.redhat.com (int-mx09.intmail.prod.int.rdu2.redhat.com [10.11.54.9]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 7F6A53822223; Fri, 1 Apr 2022 09:02:29 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.194.220]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 3E4065E1A47; Fri, 1 Apr 2022 09:02:29 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.16.1/8.16.1) with ESMTPS id 23192QAs002723 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Fri, 1 Apr 2022 11:02:26 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.16.1/8.16.1/Submit) id 23192KIf002722; Fri, 1 Apr 2022 11:02:20 +0200 Resent-From: Jakub Jelinek Resent-Date: Fri, 1 Apr 2022 11:02:20 +0200 Resent-Message-ID: Resent-To: Xi Ruoyao , gcc-patches@gcc.gnu.org, Richard Sandiford , Jakub Jelinek , YunQiang Su Date: Thu, 31 Mar 2022 19:04:35 +0200 From: Jakub Jelinek To: Xi Ruoyao Cc: gcc-patches@gcc.gnu.org, Jakub Jelinek , Richard Sandiford , YunQiang Su Subject: Re: [PATCH] mips: Emit psabi diagnostic for return values affected by C++ zero-width bit-field ABI change [PR 102024] Message-ID: Reply-To: Jakub Jelinek References: <03bbbd29325ec7f76809ef63ef8f92f930442a18.camel@mengyan1223.wang> MIME-Version: 1.0 In-Reply-To: <03bbbd29325ec7f76809ef63ef8f92f930442a18.camel@mengyan1223.wang> X-Scanned-By: MIMEDefang 2.85 on 10.11.54.9 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2022 09:02:38 -0000 On Fri, Apr 01, 2022 at 12:13:30AM +0800, Xi Ruoyao wrote: > --- a/gcc/config/mips/mips.cc > +++ b/gcc/config/mips/mips.cc > @@ -6274,10 +6274,17 @@ mips_callee_copies (cumulative_args_t, const function_arg_info &arg) > > For n32 & n64, a structure with one or two fields is returned in > floating-point registers as long as every field has a floating-point > - type. */ > + type. > + > + The C++ FE used to remove zero-width bit-fields in GCC 11 and earlier. > + To make a proper diagnostic, this function will set HAS_ZERO_WIDTH_BF > + to 1 once a C++ zero-width bit-field shows up, and then ignore it. > + Then the caller can determine if this zero-width bit-field will make a > + difference and emit a -Wpsabi inform. */ > > static int > -mips_fpr_return_fields (const_tree valtype, tree *fields) > +mips_fpr_return_fields (const_tree valtype, tree *fields, > + int *has_zero_width_bf) Use bool * and = true ? > @@ -6319,11 +6332,14 @@ static bool > mips_return_in_msb (const_tree valtype) > { > tree fields[2]; > + int has_zero_width_bf = 0; I think it would be better to match more closely what the code did before. if (!TARGET_NEWABI || !TARGET_BIG_ENDIAN || !AGGREGATE_TYPE_P (valtype)) return false; tree fields[2]; bool has_zero_width_bf = false; return (mips_fpr_return_fields (valtype, fields, &has_zero_width_bf) == 0 || has_zero_width_bf); > + int use_fpr = mips_fpr_return_fields (valtype, fields, > + &has_zero_width_bf); > > return (TARGET_NEWABI > && TARGET_BIG_ENDIAN > && AGGREGATE_TYPE_P (valtype) > - && mips_fpr_return_fields (valtype, fields) == 0); > + && (use_fpr == 0 || has_zero_width_bf)); > } > > /* Return true if the function return value MODE will get returned in a > @@ -6418,8 +6434,35 @@ mips_function_value_1 (const_tree valtype, const_tree fn_decl_or_type, > return values, promote the mode here too. */ > mode = promote_function_mode (valtype, mode, &unsigned_p, func, 1); > > + int has_zero_width_bf = 0; See above for int -> bool and 0 -> false. > + int use_fpr = mips_fpr_return_fields (valtype, fields, > + &has_zero_width_bf); > + if (TARGET_HARD_FLOAT && > + warn_psabi && > + has_zero_width_bf && > + use_fpr != 0) &&s need to go at the start of next line, not end of line. > + { > + static unsigned last_reported_type_uid; > + unsigned uid = TYPE_UID (TYPE_MAIN_VARIANT (valtype)); > + if (uid != last_reported_type_uid) > + { > + static const char *url = Similarly for = > + CHANGES_ROOT_URL > + "gcc-12/changes.html#zero_width_bitfields"; > + inform (input_location, > + "the ABI for returning a value containing " > + "zero-width bit-fields but otherwise an aggregate " > + "with only one or two floating-point fields was " > + "retconned in GCC %{12.1%}", url); In this diagnostics it is ok to talk about bit-fields as that is the only thing that changes (compared to the other patch). But again, was retconned -> changed ? Jakub