From: Siddhesh Poyarekar <siddhesh@gotplt.org>
To: Qing Zhao <qing.zhao@oracle.com>
Cc: jakub Jelinek <jakub@redhat.com>,
"gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>
Subject: Re: Another bug for __builtin_object_size? (Or expected behavior)
Date: Thu, 17 Aug 2023 15:59:16 -0400 [thread overview]
Message-ID: <1863cd09-20ad-32c2-a98e-8c96ddd9f72a@gotplt.org> (raw)
In-Reply-To: <A6E2FF79-EAAF-48C2-865B-2B0D416CBDF5@oracle.com>
On 2023-08-17 15:27, Qing Zhao wrote:
>> Yes, that's it. Maybe it's more correct if instead of MAX_EXPR if for OST_MINIMUM we stick with the early_objsz answer if it's non-zero. I'm not sure if that's the case for maximum size though, my gut says it isn't.
>
> So, the major purpose for adding the early object size phase is for computing SUBobjects size more precisely before the subobject information lost?
I suppose it's more about being able to do it at all, rather than precision.
> Then, I think whatever MIN or MAX, the early phase has more precise information than the later phase, we should use its result if it’s NOT UNKNOWN?
We can't be sure about that though, can we? For example for something
like this:
struct S
{
int a;
char b[10];
int c;
};
size_t foo (struct S *s)
{
return __builtin_object_size (s->b, 1);
}
size_t bar ()
{
struct S *in = malloc (8);
return foo (in);
}
returns 10 for __builtin_object_size in early_objsz but when it sees the
malloc in the later objsz pass, it returns 4:
$ gcc/cc1 -fdump-tree-objsz-details -quiet -o - -O bug.c
...
foo:
.LFB0:
.cfi_startproc
movl $10, %eax
ret
.cfi_endproc
...
bar:
.LFB1:
.cfi_startproc
movl $4, %eax
ret
.cfi_endproc
...
In fact, this ends up returning the wrong result for OST_MINIMUM:
$ gcc/cc1 -fdump-tree-objsz-details -quiet -o - -O bug.c
...
foo:
.LFB0:
.cfi_startproc
movl $10, %eax
ret
.cfi_endproc
...
bar:
.LFB1:
.cfi_startproc
movl $10, %eax
ret
.cfi_endproc
...
bar ought to have returned 4 too (and I'm betting the later objsz must
have seen that) but it got overridden by the earlier estimate of 10.
We probably need smarter heuristics on choosing between the estimate of
the early_objsz and late objsz passes each by itself isn't good enough
for subobjects.
Thanks,
Sid
next prev parent reply other threads:[~2023-08-17 19:59 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-16 15:59 Qing Zhao
2023-08-16 20:16 ` Qing Zhao
2023-08-17 11:00 ` Siddhesh Poyarekar
2023-08-17 13:58 ` Qing Zhao
2023-08-17 17:49 ` Siddhesh Poyarekar
2023-08-17 19:27 ` Qing Zhao
2023-08-17 19:59 ` Siddhesh Poyarekar [this message]
2023-08-17 20:23 ` Qing Zhao
2023-08-17 20:57 ` Siddhesh Poyarekar
2023-08-17 21:25 ` Qing Zhao
2023-08-17 21:32 ` Siddhesh Poyarekar
2023-08-18 16:00 ` Qing Zhao
2023-08-23 16:40 ` Qing Zhao
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=1863cd09-20ad-32c2-a98e-8c96ddd9f72a@gotplt.org \
--to=siddhesh@gotplt.org \
--cc=gcc-patches@gcc.gnu.org \
--cc=jakub@redhat.com \
--cc=qing.zhao@oracle.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).