On Mon, Jun 15, 2020 at 10:23 AM Eric Botcazou wrote:
>
> > The patch probably fixes only part of the issues with SRA and rev-storage.
>
> Well, this issue (coming from a bypass in SRA) is the first issue uncovered
> with rev-storage in SRA for years.
>
> > I see in build_ref_for_model:
> >
> >
> The patch probably fixes only part of the issues with SRA and rev-storage.
Well, this issue (coming from a bypass in SRA) is the first issue uncovered
with rev-storage in SRA for years.
> I see in build_ref_for_model:
>
> /* The flag will be set on the record type. */
> REF_REVER
On Thu, Jun 11, 2020 at 5:24 PM Eric Botcazou wrote:
>
> > I am not very good at reasoning about reverse storage order stuff but
> > can it ever happen that this reverse is not the same as racc->reverse?
> >
> > In order for that to happen, we'd have to have an assignment (folded
> > memcpy?) betw
> I am not very good at reasoning about reverse storage order stuff but
> can it ever happen that this reverse is not the same as racc->reverse?
>
> In order for that to happen, we'd have to have an assignment (folded
> memcpy?) between two aggregates in the original code that, at the same
> offse
Hi,
On Thu, Jun 11 2020, Eric Botcazou wrote:
> Hi,
>
> this fixes an issue with reverse storage order in SRA, which is caught by the
> built-in verifier:
>
> ===GNAT BUG DETECTED==+
> | 11.0.0 20200610 (experimental) (x86_64-suse-linux) GCC err
Hi,
this fixes an issue with reverse storage order in SRA, which is caught by the
built-in verifier:
===GNAT BUG DETECTED==+
| 11.0.0 20200610 (experimental) (x86_64-suse-linux) GCC error:|
| in verify_sra_access_forest, at tree-sra
