On Wed, Jul 8, 2020 at 10:53 AM Eric Botcazou <botca...@adacore.com> wrote: > > [Sorry for dropping the ball here] > > > But GCC does not see the reverse storage order in mymemcpy so > > it happily folds the memcpy inside it, inlines the result and then? > > You're right, this breaks, hence the following alternative: either we prevent > inlining from happening, or we declare that this is simply not supported and > warn (there is a -Wscalar-storage-order warning for problematic constructs). > > I didn't find any existing infrastructure for the former and I'm not sure it's > worth adding, so the attached implements the latter. Tested on x86-64/Linux.
OK with me. I still believe we could handle reverse storage order more "optimistically" (without all the current usage restrictions). We seem to have no problems with address-spaces in this area for example (their problematic cases are of course slightly different). Richard. > > 2020-07-08 Eric Botcazou <ebotca...@adacore.com> > > c-family/ > * c.opt (Wscalar-storage-order): Add warn_scalar_storage_order > variable. > > > 2020-07-08 Eric Botcazou <ebotca...@adacore.com> > > c/ > * c-typeck.c (convert_for_assignment): If -Wscalar-storage-order is > set, > warn for conversions between pointers that point to incompatible > scalar > storage orders. > > > 2020-07-08 Eric Botcazou <ebotca...@adacore.com> > > * gimple-fold.c (gimple_fold_builtin_memory_op): Do not fold if either > type has reverse scalar storage order. > * tree-ssa-sccvn.c (vn_reference_lookup_3): Do not propagate through a > memory copy if either type has reverse scalar storage order. > > > 2020-07-08 Eric Botcazou <ebotca...@adacore.com> > > testsuite/ > * gcc.dg/sso-11.c: New test. > * gcc.dg/sso/sso.exp: Pass -Wno-scalar-storage-order. > * gcc.dg/sso/memcpy-1.c: New test. > > > -- > Eric Botcazou
