This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Fix C++ strict-aliasing issues with memcpy folding
On Tue, 2 Feb 2010, Gabriel Dos Reis wrote:
> On Tue, Feb 2, 2010 at 8:25 AM, Richard Guenther <rguenther@suse.de> wrote:
> > On Tue, 2 Feb 2010, Gabriel Dos Reis wrote:
> >
> >> >> ah, but that transformation to plain assignment is middle-end
> >> >> gimmicks, not C++ source-level constructs. ?I think the middle-end
> >> >> should probably annotate that transformation (probably as
> >> >> a VIEW_CONVERT_EXPR?) since the standard explicitly says that one can
> >> >> move valid objects around with memcpy() (for objects of POD type.)
> >> >> And surely the library should use memcpy() to copy objects with
> >> >> statically ambiguous type.
> >> >>
> >> >> Does the annotation idea makes sense to the middle-end?
> >> >
> >> > Yes. ?I was playing with that during the weekend and have some
> >> > prototype patch that I need to clean up a bit.
> >>
> >> That would be fantastic.
> >
> > Current prototype attached. ?It bootstraps and tests fine (well,
> > before some cleanup done) but still has some minor regressions.
> >
> > The idea is to continue to fold memcpys into assignments (and thus
> > the frontends should use memcpy when they mean it).
>
> I believe this would lead to a cleaner separation of concerns, and
> probably a more refined semantics of the middle-end expects
> from the front-ends. Thanks!
>
> > To retain
> > the alias-set zeroness of the folded assignments we do the copy
> > in char[] type. ?Encoding this using TARGET_MEM_REFs:
> >
> > ?MEM[symbol: j] = MEM[symbol: i];
> >
> > where TREE_TYPE of the MEMs is char[4]. ?If later nothing takes
> > the address of j anymore we re-write the symbols into SSA form
> > like:
> >
> > ?j_7 = VIEW_CONVERT_EXPR<int>(MEM[symbol: i]);
>
> Nice.
>
> >
> > I don't consider the patch appropriate for 4.5.
> > As the memcpy folding bug isn't a regression and we have a workaround
> > for libstdc++ in place I consider not fixing the bug for 4.5.
>
> I understand.
>
> >
> > Thanks,
> > Richard.
> >
> >
> > FAIL: gcc.dg/memcpy-1.c scan-tree-dump-times optimized "nasty_local\\." 0
> >
> > ?SRA (and get_ref_base_and_extent) need to handle
> >
> > ? ?MEM[symbol: nasty_local] = MEM[symbol: a];
> > ? ?D.1958_1 = nasty_local.a;
> >
> > ?but SRA build-ref-for-offset has to be careful to build alias-set
> > ?zero references to a.
> >
> > FAIL: gfortran.dg/array_memcpy_4.f90 ?-O ?scan-tree-dump-times original "d = " 1
> >
> > ?The frontend should directly emit assignments with array type
> > ?as it probably knows that using alias-set zero memcpy is not needed.
> > ?As with Ada char_type_node doesn't have alias-set zero, so we do
> > ?not fold.
>
> would this problem be solved if the middle-end had a "memory-byte" type
> (that would have the same aliasing semantics as C/C++ "char") that all
> front-ends should be using to signal aliasing conflicts?
Yes. That should be easy to add.
Richard.