public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Ilya Enkovich <enkovich.gnu@gmail.com>
To: Alexander Ivchenko <aivchenk@gmail.com>
Cc: GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: Pointer Bounds Checker and trailing arrays (PR68270)
Date: Fri, 25 Nov 2016 21:28:00 -0000	[thread overview]
Message-ID: <CAMbmDYbDfhEWfCK+SbBfqpvcgkjGkqVm1JGptasLDY5AajeMLA@mail.gmail.com> (raw)
In-Reply-To: <CACysShgUjpZOzbDkczA-eDdp+7y3P8qWYYeDgZcLdUQJYpCZpg@mail.gmail.com>

2016-11-25 15:47 GMT+03:00 Alexander Ivchenko <aivchenk@gmail.com>:
> Hi,
>
> The patch below addresses PR68270. could you please take a look?
>
> 2016-11-25  Alexander Ivchenko  <aivchenk@gmail.com>
>
>        * c-family/c.opt (flag_chkp_flexible_struct_trailing_arrays):
>        Add new option.
>        * tree-chkp.c (chkp_parse_array_and_component_ref): Forbid
>        narrowing when chkp_parse_array_and_component_ref is used and
>        the ARRAY_REF points to an array in the end of the struct.
>
>
>
> diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
> index 7d8a726..e45d6a2 100644
> --- a/gcc/c-family/c.opt
> +++ b/gcc/c-family/c.opt
> @@ -1166,6 +1166,11 @@ C ObjC C++ ObjC++ LTO RejectNegative Report
> Var(flag_chkp_narrow_to_innermost_ar
>  Forces Pointer Bounds Checker to use bounds of the innermost arrays in case of
>  nested static arryas access.  By default outermost array is used.
>
> +fchkp-flexible-struct-trailing-arrays
> +C ObjC C++ ObjC++ LTO RejectNegative Report
> Var(flag_chkp_flexible_struct_trailing_arrays)
> +Allow Pointer Bounds Checker to treat all trailing arrays in structures as
> +possibly flexible.

Words 'allow' and 'possibly' are confusing here. This option is about to force
checker to do something, not to give him a choice.

New option has to be documented in invoke.texi. It would also be nice to reflect
changes on GCC MPX wiki page.

We have an attribute to change compiler behavior when this option is not set.
But we have no way to make exceptions when this option is used. Should we
add one?

> +
>  fchkp-optimize
>  C ObjC C++ ObjC++ LTO Report Var(flag_chkp_optimize) Init(-1)
>  Allow Pointer Bounds Checker optimizations.  By default allowed
> diff --git a/gcc/tree-chkp.c b/gcc/tree-chkp.c
> index 2769682..40f99c3 100644
> --- a/gcc/tree-chkp.c
> +++ b/gcc/tree-chkp.c
> @@ -3425,7 +3425,9 @@ chkp_parse_array_and_component_ref (tree node, tree *ptr,
>    if (flag_chkp_narrow_bounds
>        && !flag_chkp_narrow_to_innermost_arrray
>        && (!last_comp
> -  || chkp_may_narrow_to_field (TREE_OPERAND (last_comp, 1))))
> +  || (chkp_may_narrow_to_field (TREE_OPERAND (last_comp, 1))
> +      && !(flag_chkp_flexible_struct_trailing_arrays
> +   && array_at_struct_end_p (var)))))

This is incorrect place for fix. Consider code

struct S {
  int a;
  int b[10];
};

struct S s;
int *p = s.b;

Here you need to compute bounds for p and you want your option to take effect
but in this case you won't event reach your new check because there is no
ARRAY_REF. And even if we change it to

int *p = s.b[5];

then it still would be narrowed because s.b would still be written
into 'comp_to_narrow'
variable. Correct place for fix is in chkp_may_narrow_to_field.

Also you should consider fchkp-narrow-to-innermost-arrray option. Should it
be more powerfull or not? I think fchkp-narrow-to-innermost-arrray shouldn't
narrow to variable sized fields. BTW looks like right now bnd_variable_size
attribute is ignored by fchkp-narrow-to-innermost-arrray. This is another
problem and may be fixed in another patch though.

Also patch lacks tests for various situations (with option and without, with
ARRAY_REF and without). In case of new attribute and fix for
fchkp-narrow-to-innermost-arrray behavior additional tests are required.

--
Ilya

>      {
>        comp_to_narrow = last_comp;
>        break;

  reply	other threads:[~2016-11-25 21:28 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-25 12:47 Alexander Ivchenko
2016-11-25 21:28 ` Ilya Enkovich [this message]
2016-12-20 14:55   ` Alexander Ivchenko
2016-12-21 18:03     ` Ilya Enkovich
2016-12-21 20:27       ` Alexander Ivchenko
2016-12-22  4:16         ` Ilya Enkovich
2016-12-27 13:46           ` Alexander Ivchenko
2017-01-04 10:25           ` Richard Biener

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=CAMbmDYbDfhEWfCK+SbBfqpvcgkjGkqVm1JGptasLDY5AajeMLA@mail.gmail.com \
    --to=enkovich.gnu@gmail.com \
    --cc=aivchenk@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    /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).