From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from hedgehog.birch.relay.mailchannels.net (hedgehog.birch.relay.mailchannels.net [23.83.209.81]) by sourceware.org (Postfix) with ESMTPS id 565F83858D28 for ; Tue, 31 Jan 2023 13:01:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 565F83858D28 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=gotplt.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gotplt.org X-Sender-Id: dreamhost|x-authsender|siddhesh@gotplt.org Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 4B85B880E4B; Tue, 31 Jan 2023 13:01:05 +0000 (UTC) Received: from pdx1-sub0-mail-a305.dreamhost.com (unknown [127.0.0.6]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id B873C88138D; Tue, 31 Jan 2023 13:01:04 +0000 (UTC) ARC-Seal: i=1; s=arc-2022; d=mailchannels.net; t=1675170064; a=rsa-sha256; cv=none; b=FMLj2P6N8fS3YImzBNo7c8N0DkcvdgPpPhOYhZnTkHFZ01ysp3RZwMPXTUfVeYM7AcmkOj xxGgzskbAhr7VaGUytwRc2Tmzs0CLlW40x6uoPMrX/FLVKbSuoFQPQVfnJrhX54dEKLi9e CtvZW9o52lElDPolcj3QQ3FljVo9EDEtzgmthpypIB+OXjnZM9K/4n767hA2/johnVDI42 lj1xc6oMtuHD+Cd6vdmit9rNw1aA/LvdxmmgHeJr9X7NVvVBIbtg6Tq09YMAT9UtWRW0Oq cg2I2NGOdRKL8rliq7aetvJWfD9B4Y65ByFJWlJHda0L+1NvRm9SzV49UG84Dw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=mailchannels.net; s=arc-2022; t=1675170064; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=yc8DQ1bfp90CBxf6iBYKfJbdWkMrAXFcmhhfktzDbpQ=; b=CnGHa3zTxmY6Jz3Hkefmc2SAVjJI4SfqonjOQqh8Zvd0A+U0F863JtQ6NF1DJ6ZSzVBJY2 ufFCWXS7ueSLIBWplixzEXHgHMctj5NEKcOziAfyXoeVBWXntldvRuhPpaL+VW4MBcgCmm JIHCojv4Xe1oXueONmV15Ge0KOjHQAR5uLtuLjNhCVaQOaBlUkpNDZvtuvzetqunj2HxY/ sMsFyWSX6HAn96gd+Oy+UVEH7BYKbXP7IbvS2SkGQT0J4iWVOKpXG3blqsHQuEzKLkZCku U5tAbD/l0gei8VBXEh/mqgRBTJI2/NSIkbCLF0qzKCk7Cv0e1spJRxxHrrHW8w== ARC-Authentication-Results: i=1; rspamd-544f66f495-gdfkw; auth=pass smtp.auth=dreamhost smtp.mailfrom=siddhesh@gotplt.org X-Sender-Id: dreamhost|x-authsender|siddhesh@gotplt.org X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|siddhesh@gotplt.org X-MailChannels-Auth-Id: dreamhost X-Lyrical-Lettuce: 595b2603469eb2b4_1675170064990_4193729771 X-MC-Loop-Signature: 1675170064990:244074754 X-MC-Ingress-Time: 1675170064990 Received: from pdx1-sub0-mail-a305.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384) by 100.109.138.31 (trex/6.7.1); Tue, 31 Jan 2023 13:01:04 +0000 Received: from [192.168.0.182] (bras-vprn-toroon4834w-lp130-07-174-93-43-36.dsl.bell.ca [174.93.43.36]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: siddhesh@gotplt.org) by pdx1-sub0-mail-a305.dreamhost.com (Postfix) with ESMTPSA id 4P5lXw19vYzK1; Tue, 31 Jan 2023 05:01:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gotplt.org; s=dreamhost; t=1675170064; bh=yc8DQ1bfp90CBxf6iBYKfJbdWkMrAXFcmhhfktzDbpQ=; h=Date:Subject:To:Cc:From:Content-Type:Content-Transfer-Encoding; b=j8ytl+2dIPU+r8I/CPcHbkgypNTzOUM4e8XtXvq2H5BlkpBg6G1Aw+7M0UDv0KROs Bpx0SONn1yMdHgW7Wnm0orh3rarJmyiBtKrlz6Qgws/qYGKETGsJe+44ynKH7+UHsE g8SQbga/gSyeqgBVL9BE7W68ugC1aHOxtQrusOz33Lcp8gsQCpfAjnsfjokanv7FEp KJyc9SbxTK5p3FhMfjBRJkevFLtpwiqRodnVTS+RJTIZjjBUMogFWoXcfkQuCJJkK8 wyRpCUAMsUSVsY6FRI0brmB+OBRFp2eYZtMox9ed4ttk9a1Zf7AuV/EDH3QiWILWij MNHk5WzqO0aRA== Message-ID: <37d199ec-d69d-a650-f184-0ec2b04d3290@gotplt.org> Date: Tue, 31 Jan 2023 08:01:02 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.5.0 Subject: Re: [PATCH 2/2] tree-object-size: More consistent behaviour with flex arrays Content-Language: en-US To: Jakub Jelinek Cc: gcc-patches@gcc.gnu.org References: <20221221222554.4141678-1-siddhesh@gotplt.org> <20221221222554.4141678-3-siddhesh@gotplt.org> From: Siddhesh Poyarekar In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3031.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS,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 2023-01-31 07:46, Jakub Jelinek wrote: > On Wed, Dec 21, 2022 at 05:25:54PM -0500, Siddhesh Poyarekar wrote: >> The tree object size pass tries to fail when it detects a flex array in >> the struct, but it ends up doing the right thing only when the flex >> array is in the outermost struct. For nested cases (such as arrays >> nested in a union or an inner struct), it ends up taking whatever value >> the flex array is declared with, using zero for the standard flex array, >> i.e. []. >> >> Rework subobject size computation to make it more consistent across the >> board, honoring -fstrict-flex-arrays. With this change, any array at >> the end of the struct will end up causing __bos to use the allocated >> value of the outer object, bailing out in the maximum case when it can't >> find it. In the minimum case, it will return the subscript value or the >> allocated value of the outer object, whichever is larger. > > I think it is way too late in the GCC 13 cycle to change behavior here > except for when -fstrict-flex-arrays is used. I agree. > Plus, am not really convinced it is a good idea to change the behavior > here except for the new options, programs in the wild took 2+ years > to acommodate for what we GCC requiring and am not sure they'd be willing > to be adjusted again. The behaviour change basically does two things: better minimum object size estimates and more conservative object size estimates for trailing arrays. ISTM that this should in fact reduce breakages due to flex arrays, although one could argue that protection gets reduced for trailing arrays without -fstrict-flex-arrays. It wouldn't cause non-mitigation behaviour changes though, would it? We don't need to rush this of course, we could consider this for gcc 14 given that we're well into stage 4. Thanks, Sid