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 ?
Thanks,
Prathamesh
>
> Regards,
> Prathamesh
>>
>> Christophe
>>
>>> Does it look OK?
>>>
>>> Thanks,
>>> Prathamesh
