This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH, PR 57748] Check for out of bounds access, Part 2
- From: Eric Botcazou <ebotcazou at adacore dot com>
- To: Richard Biener <richard dot guenther at gmail dot com>
- Cc: gcc-patches at gcc dot gnu dot org, Bernd Edlinger <bernd dot edlinger at hotmail dot de>, Martin Jambor <mjambor at suse dot cz>
- Date: Wed, 23 Oct 2013 19:19:34 +0200
- Subject: Re: [PATCH, PR 57748] Check for out of bounds access, Part 2
- Authentication-results: sourceware.org; auth=none
- References: <20130910193228 dot GE6732 at virgil dot suse> <DUB122-W4C86060D7688821837731E4020 at phx dot gbl> <CAFiYyc1oKVqEO-xTJ8k9FKWVw_EW2w7Wk=KwdFJr7o1WTESCGg at mail dot gmail dot com>
> That looks backwards. Why should
>
> struct { V i; V j[0]; }
>
> have a different mode than
>
> struct { V j[0]; V i; }
>
> ?
Because we support out-of-bounds access for the array in the former case and
not in the latter case.
> And why should the same issue not exist for
>
> struct { V a[1]; }
>
> which is also "flexible enough" that we support accesses beyond it
> via a pointer? That struct also has V2DImode. And this is all
> because
>
> /* If this field is the whole struct, remember its mode so
> that, say, we can put a double in a class into a DF
> register instead of forcing it to live in the stack. */
> if (simple_cst_equal (TYPE_SIZE (type), DECL_SIZE (field)))
> mode = DECL_MODE (field);
>
> which is IMHO ok.
It's OK *only* if TYPE_SIZE (type) is really the size of all the objects of
the type; if it isn't, i.e. if we allow access past TYPE_SIZE (type), then we
cannot use the field's mode. So we need to decide where to draw the line.
--
Eric Botcazou