On 01/11/2018 05:02 AM, Prathamesh Kulkarni wrote:
On 11 January 2018 at 16:14, Prathamesh Kulkarni
<prathamesh.kulka...@linaro.org> wrote:
On 11 January 2018 at 14:52, Christophe Lyon <christophe.l...@linaro.org> wrote:
Hi
On 10 January 2018 at 19:42, Prathamesh Kulkarni
<prathamesh.kulka...@linaro.org> wrote:
Hi,
I have attached patch for PR81703 rebased on Martin's fix for PR83501
posted here since both had considerable overlaps:
https://gcc.gnu.org/ml/gcc-patches/2018-01/msg00180.html
The patch passes bootstrap+test on x86_64-unknown-linux-gnu
and cross-tested on aarch64-*-*.
Currently it fails to pass validation on arm targets because of PR83775.
I don't think the new failure is because of PR83775 (which is an ICE
when calling cc1 directly without -march).
The failure we have on arm is:
FAIL: gcc.dg/strlenopt-39.c scan-tree-dump-not optimized "(abort|strlen) \\(\\)"
but just before that, we have:
PASS: gcc.dg/strlenopt-39.c (test for excess errors)
so the compilation did not ICE
Ah, I think you're right. For some reason I mixed up the two :/
Thanks for pointing out, I will take a look at the failure.
Sorry about this once again.
The real issue seems to be differences in gimplification for ARM and x86_64.
Test-case:
#define STR "1234567"
const char str[] = STR;
char dst[10];
void copy_from_local_memstr (void)
{
struct {
char s[sizeof STR];
} x = { STR };
strcpy (dst, x.s);
if (strlen (dst) != sizeof x.s - 1)
abort ();
}
The difference between x86-64 and armhf dumps starts from 004t.gimple:
- x = *.LC0;
+ x.s = "1234567";
strcpy (&dst, &x.s);
While x86_64 emits a load from constant string, armhf has x = *.LC0
and thus strlen pass doesn't convert strcpy (&dst, &x.s) to memcpy
(&dst, &x.s, 8)
which inhibits the transform added in the patch and thus the test-case fails.
I am not sure why constant string is not emitted for arm-linux-gnueabihf ?
As far as this issue is concerned, should I simply XFAIL it on arm for now ?
This is not unique to the arm back end but affects other targets
as well, including powerpc64. There's a bug open (PR 83462) for
one of the tests I recently added with the same root cause:
a case not being handled by the strlen pass. I'm tracking this
missed optimization in PR 83543. I would expect handling it
to be fairly easy but it seems that every I think that it turns
out to be anything but. Either way, either fixing 83543 or
marking this failure (and those in PR 83462) XFAIL until it
the optimization is added should work.
If you feel like tackling 83462 before stage 3 closes please
let me know so we don't duplicate our efforts.
Martin
Thanks,
Prathamesh
Regards,
Prathamesh
Christophe
Does it look OK?
Thanks,
Prathamesh
