From: Jason Merrill <jason@redhat.com>
To: "H.J. Lu" <hjl.tools@gmail.com>
Cc: Richard Guenther <richard.guenther@gmail.com>,
"Joseph S. Myers" <joseph@codesourcery.com>,
Martin Sebor <msebor@gmail.com>,
GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: V8 [PATCH] C/C++: Add -Waddress-of-packed-member
Date: Tue, 18 Dec 2018 22:14:00 -0000 [thread overview]
Message-ID: <7f0ae96e-87b8-5db9-97b5-90094c4dace7@redhat.com> (raw)
In-Reply-To: <CAMe9rOq-_k1ntkAxbDCKY=OdFrzdS+Z6b_MZdVOwWRTFCP4_Mg@mail.gmail.com>
On 12/18/18 4:12 PM, H.J. Lu wrote:
> On Tue, Dec 18, 2018 at 12:36 PM Jason Merrill <jason@redhat.com> wrote:
>>
>> On 12/18/18 9:10 AM, H.J. Lu wrote:
>>> + switch (TREE_CODE (rhs))
>>> + {
>>> + case ADDR_EXPR:
>>> + base = TREE_OPERAND (rhs, 0);
>>> + while (handled_component_p (base))
>>> + {
>>> + if (TREE_CODE (base) == COMPONENT_REF)
>>> + break;
>>> + base = TREE_OPERAND (base, 0);
>>> + }
>>> + if (TREE_CODE (base) != COMPONENT_REF)
>>> + return NULL_TREE;
>>> + object = TREE_OPERAND (base, 0);
>>> + field = TREE_OPERAND (base, 1);
>>> + break;
>>> + case COMPONENT_REF:
>>> + object = TREE_OPERAND (rhs, 0);
>>> + field = TREE_OPERAND (rhs, 1);
>>> + break;
>>> + default:
>>> + return NULL_TREE;
>>> + }
>>> +
>>> + tree context = check_alignment_of_packed_member (type, field);
>>> + if (context)
>>> + return context;
>>> +
>>> + /* Check alignment of the object. */
>>> + while (TREE_CODE (object) == COMPONENT_REF)
>>> + {
>>> + field = TREE_OPERAND (object, 1);
>>> + context = check_alignment_of_packed_member (type, field);
>>> + if (context)
>>> + return context;
>>> + object = TREE_OPERAND (object, 0);
>>> + }
>>> +
>>
>> You can see interleaved COMPONENT_REF and ARRAY_REF that this still
>> doesn't look like it will handle, something like
>>
>> struct A
>> {
>> int i;
>> };
>>
>> struct B
>> {
>> char c;
>> __attribute ((packed)) A ar[4];
>> };
>>
>> B b;
>>
>> int *p = &b.ar[1].i;
>>
>> Rather than have a loop in the ADDR_EXPR case of the switch, you can
>> handle everything in the lower loop. And not have a switch at all, just
>> strip any ADDR_EXPR before the loop.
>
> I changed it to
>
> if (TREE_CODE (rhs) == ADDR_EXPR)
> rhs = TREE_OPERAND (rhs, 0);
> while (handled_component_p (rhs))
> {
> if (TREE_CODE (rhs) == COMPONENT_REF)
> break;
> rhs = TREE_OPERAND (rhs, 0);
> }
>
> if (TREE_CODE (rhs) != COMPONENT_REF)
> return NULL_TREE;
>
> object = TREE_OPERAND (rhs, 0);
> field = TREE_OPERAND (rhs, 1);
That still doesn't warn about my testcase above.
> [hjl@gnu-cfl-1 pr51628-6]$ cat a.i
> struct A
> {
> int i;
> } __attribute ((packed));
>
> struct B
> {
> char c;
> struct A ar[4];
> };
>
> struct B b;
>
> int *p = &b.ar[1].i;
This testcase is importantly different because 'i' is packed, whereas in
my testcase only the ar member of B is packed.
My suggestion was that this loop:
> + /* Check alignment of the object. */
> + while (TREE_CODE (object) == COMPONENT_REF)
> + {
> + field = TREE_OPERAND (object, 1);
> + context = check_alignment_of_packed_member (type, field);
> + if (context)
> + return context;
> + object = TREE_OPERAND (object, 0);
> + }
could loop over all handled_component_p, but only call
check_alignment_of_packed_member for COMPONENT_REF.
> + if (TREE_CODE (rhs) != COND_EXPR)
> + {
> + while (TREE_CODE (rhs) == COMPOUND_EXPR)
> + rhs = TREE_OPERAND (rhs, 1);
What if you have a COND_EXPR inside a COMPOUND_EXPR?
Jason
next prev parent reply other threads:[~2018-12-18 22:14 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-25 15:47 V4 " H.J. Lu
2018-11-04 15:16 ` PING: " H.J. Lu
2018-11-25 14:38 ` PING^2: " H.J. Lu
2018-12-13 20:50 ` Jason Merrill
2018-12-14 0:09 ` V5 " H.J. Lu
2018-12-14 22:10 ` Jason Merrill
2018-12-14 22:48 ` V6 " H.J. Lu
2018-12-17 9:39 ` Richard Biener
2018-12-17 12:43 ` H.J. Lu
2018-12-17 13:34 ` Richard Biener
2018-12-17 13:53 ` Jason Merrill
2018-12-18 14:11 ` V7 " H.J. Lu
2018-12-18 20:36 ` Jason Merrill
2018-12-18 21:13 ` V8 " H.J. Lu
2018-12-18 22:14 ` Jason Merrill [this message]
2018-12-19 14:52 ` H.J. Lu
2018-12-19 17:36 ` V9 " H.J. Lu
2018-12-20 19:40 ` Jason Merrill
2018-12-20 20:07 ` V10 " H.J. Lu
2018-12-20 21:31 ` Jason Merrill
2018-12-20 21:47 ` H.J. Lu
2018-12-19 3:19 ` V8 " Sandra Loosemore
2018-12-19 14:53 ` H.J. Lu
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=7f0ae96e-87b8-5db9-97b5-90094c4dace7@redhat.com \
--to=jason@redhat.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=hjl.tools@gmail.com \
--cc=joseph@codesourcery.com \
--cc=msebor@gmail.com \
--cc=richard.guenther@gmail.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).