From: Bernd Edlinger <bernd.edlinger@hotmail.de>
To: Richard Biener <richard.guenther@gmail.com>
Cc: Eric Botcazou <ebotcazou@adacore.com>,
GCC Patches <gcc-patches@gcc.gnu.org>,
Martin Jambor <mjambor@suse.cz>, Jakub Jelinek <jakub@redhat.com>
Subject: RE: [PATCH, PR 57748] Check for out of bounds access, Part 2
Date: Thu, 07 Nov 2013 13:23:00 -0000 [thread overview]
Message-ID: <DUB122-W188369190C05F1E42EF3F0E4F30@phx.gbl> (raw)
In-Reply-To: <CAFiYyc1KcuO+HkqmDCNqehDjzj3hQBHCxKfBzqvRd7vbmyTUCg@mail.gmail.com>
Hi,
On Fri, 25 Oct 2013 12:51:13, Richard Biener wrote:
>
> On Fri, Oct 25, 2013 at 12:02 PM, Bernd Edlinger
> <bernd.edlinger@hotmail.de> wrote:
>> Hi,
>>
>>> Eh ... even
>>>
>>> register struct { int i; int a[0]; } asm ("ebx");
>>>
>>> works. Also with int a[1] but not with a[2]. So just handling trailing
>>> arrays makes this case regress as well.
>>>
>>> Now I'd call this use questionable ... but we've likely supported that
>>> for decades and cannot change that now.
>>>
>>> Back to fixing everything in expand.
>>>
>>> Richard.
>>>
>>
>> Ok, finally you asked for it.
>>
>> Here is my previous version of that patch again.
>>
>> I have now added a new value "EXPAND_REFERENCE" to the expand_modifier
>> enumeration. It is almost like EXPAND_MEMORY but it does not interfere with
>> constant values.
>>
>> I have done the same modification to VIEW_CONVERT_EXPR too, because
>> this is a possible inner reference, itself. It is however inherently hard to
>> test around this code.
>>
>> To understand this patch it is good to know what type of object the
>> return value "tem" of get_inner_reference can be.
>>
>> From the program logic at get_inner_reference it is clear that the
>> return value may *not* be BIT_FIELD_REF, COMPONENT_REF, ARRAY_REF,
>> ARRAY_RANGE_REF, REALPART_EXPR, IMAGPART_EXPR. The result may
>> be VIEW_CONVERT_EXPR only on a STRICT_ALIGNMENT target. This is probably
>> further restricted because exp is gimplified.
>>
>> Usually the result will be a MEM_REF or a SSA_NAME of the memory where
>> the structure is to be found.
>>
>> When you look at where EXPAND_MEMORY is handled you see it is special-cased
>> in TARGET_MEM_REF, MEM_REF, ARRAY_REF, COMPONENT_REF, BIT_FIELD_REF,
>> ARRAY_RANGE_REF.
>>
>> At TARGET_MEM_REF, MEM_REF, VIEW_CONVERT_EXPR, it should be the
>> same if EXPAND_MEMORY, EXPAND_WRITE or EXPAND_REFERENCE is given:
>> If it is an unaligned memory, we just return the unaligned reference.
>>
>> This was missing for VIEW_CONVERT_EXPR, and unfortunately I have no test case,
>> because it is only a problem for STRICT_ALIGNMENT targets, and even there it will
>> certainly be really hard to find test cases that exercise this code.
>>
>> In ARRAY_REF, COMPONENT_REF, BIT_FIELD_REF, ARRAY_RANGE_REF
>> we do not have to touch the handling of the outer modifier. However we pass
>> EXPAND_REFERENCE to the inner object, which should not be a recursive
>> use of any ARRAY_REF, COMPONENT_REF, BIT_FIELD_REF, ARRAY_RANGE_REF.
>>
>> TARGET_MEM_REF, MEM_REF and VIEW_CONVERT_EXPR know how to handle
>> EXPAND_REFERENCE, anything else handles it like EXPAND_NORMAL.
>>
>>
>> Boot-strapped and regression-tested on x86_64-linux-gnu
>> OK for trunk?
>
> You point to a weak spot in expansion - that it handles creating
> the base MEM to offset with handled components by recursing
> into the case that handles bare MEM_REFs. This makes the
> bare MEM_REF handling code somewhat awkward (it's the
> one to assign mem-attrs which are later adjusted for example).
>
> Maybe a better appropach than adding yet another expand
> modifier would be to split out the "base MEM" expansion part
> out of the bare MEM_REF handling code so we can call that
> instead of recursing.
>
> In this light - instead of a new expand modifier don't you want
> an actual flag that specifies we are coming from a call that
> wants to expand a base? That is, allow EXPAND_SUM
> but with the recursion flag set?
>
I think you are right. After some thought, I start to like that idea.
This way we have at least much more flexibility, how to handle the inner
references correctly, and if I change only the interfaces of expand_expr_real/real_1
that will not be used at too many places, either.
> Finally I think the recursion into the VIEW_CONVERT_EXPR case
> is only there because of the keep_aligning flag of get_inner_reference
> which should be obsolete now that we properly handle its effects
> in get_object_alignment. So you wouldn't need to adjust this path
> if we finally can get rid of that.
>
I proposed a patch for that, but did not hear from you:
http://gcc.gnu.org/ml/gcc-patches/2013-10/msg02267.html
nevertheless, even if the VIEW_CONVERT_EXPR may or may not be an inner
reference, the code there should be kept in sync with the normal_inner_ref,
and MEM_REF, IMHO.
Attached, my updated patch for PR57748, Part 2.
Boot-strapped and regression-tested on X86_64-pc-linux-gnu.
Ok for trunk?
Thanks
Bernd.
> What do others think?
>
> Thanks,
> Richard.
>
>> Thanks
>> Bernd.
next prev parent reply other threads:[~2013-11-07 12:57 UTC|newest]
Thread overview: 105+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-06 7:03 [PATCH, PR 57748] Check for out of bounds access Bernd Edlinger
2013-09-06 7:31 ` Richard Biener
[not found] ` <DUB122-W323D4AAAEA1AFA890BF243E43C0@phx.gbl>
[not found] ` <CAFiYyc13wC0jmZ4xELAiL5L5Sbh0yauZWViP2hTdR+H4s0iPSw@mail.gmail.com>
[not found] ` <DUB122-W4D571A91831593BA22438E43C0@phx.gbl>
2013-09-06 9:19 ` Richard Biener
2013-09-06 9:30 ` Bernd Edlinger
2013-09-10 21:33 ` Martin Jambor
2013-09-11 14:42 ` Bernd Edlinger
2013-09-11 14:47 ` Richard Biener
2013-09-12 21:07 ` Bernd Edlinger
2013-09-13 9:37 ` Eric Botcazou
2013-09-13 9:48 ` Bernd Edlinger
2013-09-15 19:08 ` Bernd Edlinger
2013-09-17 0:05 ` Martin Jambor
2013-09-17 10:32 ` Bernd Edlinger
2013-10-22 14:08 ` Bernd Edlinger
2013-10-23 16:02 ` Richard Biener
2013-10-24 0:09 ` Bernd Edlinger
2013-10-24 8:44 ` Eric Botcazou
2013-10-24 10:06 ` Richard Biener
2013-10-24 10:22 ` Bernd Edlinger
2013-10-25 10:40 ` Eric Botcazou
2013-11-06 15:08 ` [PATCH, PR 57748] Check for out of bounds access, Part 3 Bernd Edlinger
2013-12-03 13:27 ` [PE-POST] Adjust Bit-region in expand_assignment Bernd Edlinger
2013-12-04 5:55 ` Jeff Law
2013-12-04 7:50 ` Bernd Edlinger
2013-12-06 4:13 ` Jeff Law
2013-12-06 8:03 ` Bernd Edlinger
2013-12-06 9:49 ` Richard Biener
2013-09-17 11:07 ` [PATCH, PR 57748] Check for out of bounds access Richard Biener
2013-09-17 11:41 ` Richard Biener
2013-09-17 12:48 ` Bernd Edlinger
2013-09-24 11:40 ` Richard Biener
2013-09-24 11:56 ` Bernd Edlinger
2013-09-24 6:34 ` [PATCH, PR 57748] Check for out of bounds access, Part 2 Bernd Edlinger
2013-09-24 10:31 ` Richard Biener
2013-09-24 14:46 ` Eric Botcazou
2013-09-24 18:51 ` Martin Jambor
2013-09-25 9:51 ` Richard Biener
2013-09-25 14:56 ` Martin Jambor
2013-09-26 9:34 ` Bernd Edlinger
2013-09-26 11:18 ` Eric Botcazou
2013-09-26 12:42 ` Bernd Edlinger
2013-09-27 8:45 ` Eric Botcazou
2013-10-03 0:37 ` Bernd Edlinger
2013-10-08 8:02 ` Eric Botcazou
2013-10-08 9:22 ` Bernd Edlinger
2013-10-08 21:04 ` Eric Botcazou
2013-10-08 23:03 ` Bernd Edlinger
2013-10-11 17:27 ` Eric Botcazou
2013-10-13 8:22 ` Bernd Edlinger
2013-10-13 12:29 ` Eric Botcazou
2013-10-13 12:30 ` Bernd Edlinger
2013-10-13 14:06 ` Eric Botcazou
2013-10-22 11:02 ` Bernd Edlinger
2013-10-23 16:14 ` Richard Biener
2013-10-23 17:25 ` Martin Jambor
2013-10-23 18:05 ` Eric Botcazou
2013-10-24 8:20 ` Bernd Edlinger
2013-10-24 9:16 ` Eric Botcazou
2013-10-24 10:00 ` Bernd Edlinger
2013-10-24 10:16 ` Eric Botcazou
2013-10-24 10:50 ` Richard Biener
2013-10-24 13:09 ` Bernd Edlinger
2013-10-24 13:16 ` Richard Biener
2013-10-24 13:38 ` Bernd Edlinger
2013-10-25 7:05 ` Bernd Edlinger
2013-10-25 9:29 ` Richard Biener
2013-10-25 10:40 ` Bernd Edlinger
2013-10-25 11:10 ` Richard Biener
2013-10-25 14:01 ` Martin Jambor
2013-10-27 20:21 ` [PATCH] Remove "keep_aligning" from get_inner_reference Bernd Edlinger
2013-11-26 12:37 ` Richard Biener
2013-11-27 11:28 ` Eric Botcazou
2013-11-27 12:24 ` Bernd Edlinger
2013-11-27 12:33 ` Eric Botcazou
2013-11-27 13:30 ` Richard Biener
2013-11-27 15:10 ` Bernd Edlinger
2013-11-27 16:25 ` Eric Botcazou
2013-11-27 16:33 ` Richard Biener
2013-11-27 16:43 ` Eric Botcazou
2014-04-22 7:55 ` Bernd Edlinger
2014-04-22 8:11 ` Eric Botcazou
2014-04-22 8:33 ` Bernd Edlinger
2014-04-22 9:36 ` Eric Botcazou
2014-05-02 6:18 ` Jeff Law
2014-05-05 8:00 ` Richard Biener
2014-05-05 20:25 ` Mike Stump
2014-05-14 7:30 ` Eric Botcazou
2014-05-14 9:06 ` Bernd Edlinger
2013-11-07 13:23 ` Bernd Edlinger [this message]
2013-11-07 13:23 ` [PATCH, PR 57748] Check for out of bounds access, Part 2 Bernd Edlinger
2013-11-19 15:05 ` Bernd Edlinger
2013-11-27 16:22 ` [PING] " Bernd Edlinger
2013-11-27 17:09 ` Richard Biener
2013-11-27 22:30 ` Jeff Law
2013-11-28 12:36 ` Bernd Edlinger
2013-12-03 6:00 ` Jeff Law
2013-10-24 13:20 ` Jakub Jelinek
2013-10-24 13:42 ` Richard Biener
2013-10-24 11:14 ` Richard Biener
2013-10-24 13:13 ` Richard Biener
2013-10-23 17:45 ` Eric Botcazou
2013-09-25 13:22 ` Bernd Edlinger
2013-09-06 9:29 ` [PATCH, PR 57748] Check for out of bounds access Eric Botcazou
2013-09-06 9:30 ` Jakub Jelinek
2013-09-06 10:30 ` Bernd Edlinger
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=DUB122-W188369190C05F1E42EF3F0E4F30@phx.gbl \
--to=bernd.edlinger@hotmail.de \
--cc=ebotcazou@adacore.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=jakub@redhat.com \
--cc=mjambor@suse.cz \
--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).