On Mon, Jan 21, 2019 at 9:23 PM Martin Sebor <mse...@gmail.com> wrote:
>
> On 1/21/19 1:18 AM, Richard Biener wrote:
> > On Sat, Jan 19, 2019 at 12:25 AM Martin Sebor <mse...@gmail.com> wrote:
> >>
> >> Some of the -Warray-bounds and -Wrestrict tests are prone to failing
> >> on targets like arm-eabi and others that use different parameters to
> >> decide which memcpy calls should be folded to MEM_REF (those that do
> >> are copies of small power-of-two sizes where the power tends to vary
> >> from target to target and may be as little as 1). The failures then
> >> waste the time of those who maintain those secondary targets reporting
> >> failures (see * below), as well as those who wrote the tests debugging
> >> the problems and working around them.
> >>
> >> To reduce this effort (and ideally avoid these regressions going
> >> forward) the attached patch adds a new effective-target to the test
> >> harness: fold_memcpy_N. It detects the target's willingness to fold
> >> memcpy call of the given size (N). While testing this with the arm
> >> cross-compiler I also tweaked the tests that #include standard
> >> headers to only do so when __has_include says the header exists.
> >> This lets the tests pass even when using a cross-compiler without
> >> library headers installed (my default MO). If/when the warnings
> >> are improved to detect the problems regardless of the folding as
> >> I'm hoping to eventually do, this new effective-target feature
> >> can be removed.
> >
> > But all the memcpy folding does is see whether the target can
> > access unaligned {2,4,8,<max-int-mode-size>} memory. So
> > a effective target unaligned_move_{2,4,8...} would be better and
> > possibly useful in other contexts? memcpy folding might be indeed
> > a nice vehicle to test this property.
> >
> > Thus, I guess I'm only asking to rename the effective target keyword.
>
> I did this but after some more reading I no longer think we need it.
>
> > Btw, new effective targets need documenting in sourcebuild.texi
>
> Thanks for the reminder! While adding the new keyword I came across
> non_strict_align. It looks like it's pretty much same thing as what
> I'm trying to add. It's used in gcc.dg/memmove-4.c and memcpy-3.c
> (besides a few other tests) to test the folding whose absence
> the warnings depend on.
>
> So I've simplified the patch to make use of non_strict_align instead.
> I've verified the tests pass with arm-eabi, sparc-solaris2.11, and
> x86_64.
OK.
> Martin
>
> >
> > Richard.
> >
> >> Martin
> >>
> >> [*] https://gcc.gnu.org/ml/gcc-patches/2019-01/msg01056.html
>
