From: Siddhesh Poyarekar <siddhesh@gotplt.org>
To: Jakub Jelinek <jakub@redhat.com>
Cc: gcc-patches@gcc.gnu.org
Subject: Re: [PATCH 2/2] tree-object-size: More consistent behaviour with flex arrays
Date: Tue, 31 Jan 2023 08:01:02 -0500 [thread overview]
Message-ID: <37d199ec-d69d-a650-f184-0ec2b04d3290@gotplt.org> (raw)
In-Reply-To: <Y9kNvn4uxKBjQbvq@tucnak>
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
next prev parent reply other threads:[~2023-01-31 13:01 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-21 22:25 [PATCH 0/2] __bos and " Siddhesh Poyarekar
2022-12-21 22:25 ` [PATCH 1/2] testsuite: Run __bos tests to completion Siddhesh Poyarekar
2023-01-31 12:33 ` Jakub Jelinek
2023-02-01 16:46 ` [committed v2] " Siddhesh Poyarekar
2022-12-21 22:25 ` [PATCH 2/2] tree-object-size: More consistent behaviour with flex arrays Siddhesh Poyarekar
2023-01-26 16:20 ` Qing Zhao
2023-01-26 17:16 ` Siddhesh Poyarekar
2023-01-26 17:42 ` Qing Zhao
2023-01-31 12:46 ` Jakub Jelinek
2023-01-31 13:01 ` Siddhesh Poyarekar [this message]
2023-01-03 14:30 ` [ping][PATCH 0/2] __bos and " Siddhesh Poyarekar
2023-01-11 13:14 ` [ping2][PATCH " Siddhesh Poyarekar
2023-01-20 19:38 ` [ping3][PATCH " Siddhesh Poyarekar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=37d199ec-d69d-a650-f184-0ec2b04d3290@gotplt.org \
--to=siddhesh@gotplt.org \
--cc=gcc-patches@gcc.gnu.org \
--cc=jakub@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).