On 12 January 2018 at 23:25, Jakub Jelinek wrote:
> On Fri, Jan 12, 2018 at 10:38:39AM -0700, Jeff Law wrote:
>> >>> Thanks for pointing it out. I see it there as well with
>> >>> Prathamesh's test case, though not with the test case in
>> >>> bug 83543. It is the same root cause in both. I agr
On Fri, Jan 12, 2018 at 10:38:39AM -0700, Jeff Law wrote:
> >>> Thanks for pointing it out. I see it there as well with
> >>> Prathamesh's test case, though not with the test case in
> >>> bug 83543. It is the same root cause in both. I agree
> >>> that enhancing the strlen pass to handle this c
On 01/12/2018 09:23 AM, Martin Sebor wrote:
> On 01/11/2018 11:44 PM, Prathamesh Kulkarni wrote:
>> On 12 January 2018 at 06:15, Martin Sebor wrote:
>>> On 01/11/2018 02:48 PM, Rainer Orth wrote:
Hi Martin,
>> I am not sure why constant string is not emitted for
>> arm-linux
On 01/11/2018 11:44 PM, Prathamesh Kulkarni wrote:
On 12 January 2018 at 06:15, Martin Sebor wrote:
On 01/11/2018 02:48 PM, Rainer Orth wrote:
Hi Martin,
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
On 12 January 2018 at 06:15, Martin Sebor wrote:
> On 01/11/2018 02:48 PM, Rainer Orth wrote:
>>
>> Hi Martin,
>>
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 ?
>>>
>>>
>>>
On 01/11/2018 02:48 PM, Rainer Orth wrote:
Hi Martin,
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 pow
Hi Martin,
>> 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 8346
x 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
On 11 January 2018 at 16:14, Prathamesh Kulkarni
wrote:
> On 11 January 2018 at 14:52, Christophe Lyon
> wrote:
>> Hi
>>
>> On 10 January 2018 at 19:42, Prathamesh Kulkarni
>> wrote:
>>> Hi,
>>> I have attached patch for PR81703 rebased on Mar
On 11 January 2018 at 14:52, Christophe Lyon wrote:
> Hi
>
> On 10 January 2018 at 19:42, Prathamesh Kulkarni
> wrote:
>> Hi,
>> I have attached patch for PR81703 rebased on Martin's fix for PR83501
>> posted here since both had considerable overlaps:
>>
Hi
On 10 January 2018 at 19:42, Prathamesh Kulkarni
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 b
On 01/10/2018 11:42 AM, Prathamesh Kulkarni 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
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 fai
On 01/03/2018 02:29 PM, Martin Sebor wrote:
> Prathamesh's fix restores the optimization for the test case
> reported in the bug (thanks!) but it isn't sufficient to bring
> GCC 8 completely up to par with 7. Prior GCC versions are able
> to compute the string length in the test case below but GCC
Prathamesh's fix restores the optimization for the test case
reported in the bug (thanks!) but it isn't sufficient to bring
GCC 8 completely up to par with 7. Prior GCC versions are able
to compute the string length in the test case below but GCC 8
cannot.
char d[8];
const char s[] = "123456
On 2 January 2018 at 19:29, Richard Biener wrote:
> On Thu, Dec 28, 2017 at 8:42 AM, Prathamesh Kulkarni
> wrote:
>> On 21 December 2017 at 12:53, Prathamesh Kulkarni
>> wrote:
>>> Hi Jakub,
>>> Based on your suggestions in PR83501, I have updated the patc
On Thu, Dec 28, 2017 at 8:42 AM, Prathamesh Kulkarni
wrote:
> On 21 December 2017 at 12:53, Prathamesh Kulkarni
> wrote:
>> Hi Jakub,
>> Based on your suggestions in PR83501, I have updated the patch to
>> check for integer_zerop for 2nd operand of mem_ref.
>>
&g
On 21 December 2017 at 12:53, Prathamesh Kulkarni
wrote:
> Hi Jakub,
> Based on your suggestions in PR83501, I have updated the patch to
> check for integer_zerop for 2nd operand of mem_ref.
>
> With the patch, Warray-bounds started warning for the following test
> in Warray-
Hi Jakub,
Based on your suggestions in PR83501, I have updated the patch to
check for integer_zerop for 2nd operand of mem_ref.
With the patch, Warray-bounds started warning for the following test
in Warray-bounds-3.c in line 362 and thus I removed xfail on it:
TM (a5, "0123", ma.a5
19 matches
Mail list logo
