From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by sourceware.org (Postfix) with ESMTPS id CAF493857407 for ; Thu, 16 Sep 2021 10:59:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org CAF493857407 Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id D13AA22382; Thu, 16 Sep 2021 10:59:45 +0000 (UTC) Received: from murzim.suse.de (murzim.suse.de [10.160.4.192]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id 42D7BA3B95; Thu, 16 Sep 2021 10:59:41 +0000 (UTC) Date: Thu, 16 Sep 2021 12:59:44 +0200 (CEST) From: Richard Biener To: Jakub Jelinek cc: gcc-patches@gcc.gnu.org Subject: Re: [PATCH] middle-end/102360 - adjust .DEFERRED_INIT expansion In-Reply-To: <20210916105135.GH304296@tucnak> Message-ID: <28qn2oq-o15n-96n9-3977-177670645o@fhfr.qr> References: <98o56o49-7r8r-s95q-83o5-n7o8ss4ppnpq@fhfr.qr> <20210916102612.GG304296@tucnak> <47pp8q27-r5q9-67o7-4prr-o411r7q514o3@fhfr.qr> <20210916105135.GH304296@tucnak> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-4.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham 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: Thu, 16 Sep 2021 10:59:48 -0000 On Thu, 16 Sep 2021, Jakub Jelinek wrote: > On Thu, Sep 16, 2021 at 12:41:20PM +0200, Richard Biener wrote: > > On Thu, 16 Sep 2021, Jakub Jelinek wrote: > > > > > On Thu, Sep 16, 2021 at 11:48:49AM +0200, Richard Biener via Gcc-patches wrote: > > > > 2021-09-16 Richard Biener > > > > > > > > PR middle-end/102360 > > > > * internal-fn.c (expand_DEFERRED_INIT): Make pattern-init > > > > of non-memory more robust. > > > > > > > > * g++.dg/pr102360.C: New testcase. > > > > + if (can_native_interpret_type_p (var_type)) > > > > + init = native_interpret_expr (var_type, buf, total_bytes); > > > > + else > > > > + { > > > > + tree itype = build_nonstandard_integer_type (total_bytes * 8, 1); > > > > > > Shouldn't that 8 be BITS_PER_UNIT ? > > > I know we have tons of problems with BITS_PER_UNIT is not 8, but adding > > > further ones is unnecessary. > > > > Well, a byte is 8 bits and we do > > > > unsigned HOST_WIDE_INT total_bytes > > = tree_to_uhwi (TYPE_SIZE_UNIT (var_type)); > > > > if (init_type == AUTO_INIT_PATTERN) > > { > > unsigned char *buf = (unsigned char *) xmalloc (total_bytes); > > memset (buf, INIT_PATTERN_VALUE, total_bytes); > > > > and thus mix host and target here. I suppose it should be instead > > > > unsigned HOST_WIDE_INT total_bytes > > = tree_to_uhwi (TYPE_SIZE (var_type)) / (BITS_PER_UNIT / 8); > > > > or so... in this light * 8 for the build_nonstandard_integer_type > > use is correct, no? If total_bytes is really _bytes_. > > Typically for the native_interpret/native_encode we punt if > BITS_PER_UNIT != 8 || CHAR_BIT != 8 because nobody had the energy > to deal with the weird platforms (especially if we have currently > none, I believe dsp16xx that had 16-bit bytes had been removed in 4.0 > and c4x that had 32-bit bytes had been removed in 4.3) > - dunno if the DEFERRED_INIT etc. code has those guards or not > and it clearly documents that this code is not ready for other > configurations. > A byte is not necessarily 8 bits, that is just the most common > size for it, and TYPE_SIZE_UNIT is number of BITS_PER_UNIT bit units. OK, I'll do s/8/BITS_PER_UNIT/ - I also see that we have int_size_in_bytes returning TYPE_SIZE_UNIT and that TYPE_SIZE_UNIT is documented to yeild the type size in 'bytes'. I do believe that we should officially declare hosts with CHAR_BIT != 8 as unsupported and as you say support for targets with BITS_PER_UNIT != 8 is likely bit-rotten. Richard.