On Thu, 9 Jan 2014 16:22:33, Richard Earnshaw wrote:
>
> On 09/01/14 08:26, Bernd Edlinger wrote:
>> Hi,
>>
>> On Thu, 9 Jan 2014 15:01:54, Yoey Ye wrote:
>>>
>>> Sandra, Bernd,
>>>
>>> Can you take a look at
>>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59734
>>>
>>> It seems a siimple case stil
> No. This example was working in 4.6 and broken in 4.7 and 4.8.
> Well, 4.7 should have warned about that.
The 4.7 branch is not closed so it's not too late to add the warning there.
--
Eric Botcazou
> No. This example was working in 4.6 and broken in 4.7 and 4.8.
Note that it probably broke in 4.7.1 because the DECL_BIT_FIELD_REPRESENTATIVE
stuff was backported after the initial 4.7.0 release.
--
Eric Botcazou
Hi,
Philippe Baril Lecavalier writes:
> I have been experimenting with buildbot lately, and I would be glad to
> help in providing it. If there is interest, I could have a prototype and
> a detailed proposal ready in a few days. It could serve GCC, binutils
> and some important libraries as well.
On 10/01/14 08:49, Bernd Edlinger wrote:
> On Thu, 9 Jan 2014 16:22:33, Richard Earnshaw wrote:
>>
>> On 09/01/14 08:26, Bernd Edlinger wrote:
>>> Hi,
>>>
>>> On Thu, 9 Jan 2014 15:01:54, Yoey Ye wrote:
Sandra, Bernd,
Can you take a look at
http://gcc.gnu.org/bugzilla/show_
On 01/10/14 10:11, Richard Sandiford wrote:
Hi,
Philippe Baril Lecavalier writes:
I have been experimenting with buildbot lately, and I would be glad to
help in providing it. If there is interest, I could have a prototype and
a detailed proposal ready in a few days. It could serve GCC, binutil
Hello,
I have been investigating a few loops and while looking at:
void matrix_mul_vect(unsigned int N, int *C, short *A, short *B) {
unsigned int i,j;
for (i=0; i 64)
;; succ: 5 [91.0%] (FALLTHRU)
;; 6 [9.0%] (LOOP_EXIT)
;; lr out 6 [bp] 7 [sp] 16 [argp] 20 [frame]
On Fri, Jan 10, 2014 at 2:17 PM, Paulo Matos wrote:
> Hello,
>
> I have been investigating a few loops and while looking at:
> void matrix_mul_vect(unsigned int N, int *C, short *A, short *B) {
> unsigned int i,j;
> for (i=0; i C[i]=0;
> for (j=0; jC[i]+=A[i*N+j] * B[j];
> }
> }
> }
>
On, Fri, 10 Jan 2014 09:41:06, Richard Earnshaw wrote:
>
> On 10/01/14 08:49, Bernd Edlinger wrote:
>> On Thu, 9 Jan 2014 16:22:33, Richard Earnshaw wrote:
>>>
>>> On 09/01/14 08:26, Bernd Edlinger wrote:
Hi,
On Thu, 9 Jan 2014 15:01:54, Yoey Ye wrote:
>
> Sandra, Bernd,
On Fri, Jan 10, 2014 at 2:30 PM, Bernd Edlinger
wrote:
> On, Fri, 10 Jan 2014 09:41:06, Richard Earnshaw wrote:
>>
>> On 10/01/14 08:49, Bernd Edlinger wrote:
>>> On Thu, 9 Jan 2014 16:22:33, Richard Earnshaw wrote:
On 09/01/14 08:26, Bernd Edlinger wrote:
> Hi,
>
> On Thu, 9
On 10/01/14 13:45, Richard Biener wrote:
> On Fri, Jan 10, 2014 at 2:30 PM, Bernd Edlinger
> wrote:
>> On, Fri, 10 Jan 2014 09:41:06, Richard Earnshaw wrote:
>>>
>>> On 10/01/14 08:49, Bernd Edlinger wrote:
On Thu, 9 Jan 2014 16:22:33, Richard Earnshaw wrote:
>
> On 09/01/14 08:26, Be
On Fri, 10 Jan 2014 14:45:12, Richard Biener wrote:
>
> On Fri, Jan 10, 2014 at 2:30 PM, Bernd Edlinger
> wrote:
>> On, Fri, 10 Jan 2014 09:41:06, Richard Earnshaw wrote:
>>>
>>> On 10/01/14 08:49, Bernd Edlinger wrote:
On Thu, 9 Jan 2014 16:22:33, Richard Earnshaw wrote:
>
> On 09/01
Paulo Matos
> -Original Message-
> From: Richard Biener [mailto:richard.guent...@gmail.com]
> Sent: 10 January 2014 13:25
> To: Paulo Matos
> Cc: gcc@gcc.gnu.org
> Subject: Re: Useless statement in loop latch looks like performance regression
>
> Most likely changes to SSA coalescing a
On 01/10/14 10:03, Paulo Matos wrote:
Paulo Matos
-Original Message-
From: Richard Biener [mailto:richard.guent...@gmail.com]
Sent: 10 January 2014 13:25
To: Paulo Matos
Cc: gcc@gcc.gnu.org
Subject: Re: Useless statement in loop latch looks like performance regression
Most likely ch
Hi,
I think I found a bug in gcc 4.7.3 in gcc/caller-save.c at line 158 :
gcc_assert (cached_reg_save_code[reg][mode]);
should be :
gcc_assert (cached_reg_save_code[reg][mode] != -1);
because cached_reg_save_code contains INSN_CODES that can be equal to 0 (see
attached patch)
In
Hi,
When I relaxed CANNOT_CHANGE_MODE_CLASS to undefined for AArch64,
gcc.c-torture/execute/copysign1.c generates incorrect code because LRA cannot
seem to handle subregs like
(subreg:DI (reg:TF hard_reg) 8)
on hard registers where the subreg byte offset is unaligned to a hard register
bou
Jeff Law wrote:
>On 01/10/14 10:03, Paulo Matos wrote:
>>
>>
>> Paulo Matos
>>
>>
>>> -Original Message-
>>> From: Richard Biener [mailto:richard.guent...@gmail.com]
>>> Sent: 10 January 2014 13:25
>>> To: Paulo Matos
>>> Cc: gcc@gcc.gnu.org
>>> Subject: Re: Useless statement in loop latch
> In my backend movdi pattern has unfortunately code '0' (depends on pattern
> declaration order). When gcc tried to determine if my DI regs can be saved
> and restore as 'caller saves' (in caller-save.c::init_caller_save()) it
> failed on this wrong assertion.
I'd arrange for avoiding code 0 inst
On 01/10/14 14:44, Eric Botcazou wrote:
In my backend movdi pattern has unfortunately code '0' (depends on pattern
declaration order). When gcc tried to determine if my DI regs can be saved
and restore as 'caller saves' (in caller-save.c::init_caller_save()) it
failed on this wrong assertion.
I
> Agreed, but the assert in caller-save is still wrong and ought to be fixed.
Not clear to me: if you just fix it, you won't realize that the cache is
disabled for the code 0 insn. And there might be other parts of the RTL
middle-end expecting non-zero codes.
--
Eric Botcazou
> I think I found a bug in gcc 4.7.3 in gcc/caller-save.c at line 158 :
>
> gcc_assert (cached_reg_save_code[reg][mode]);
>
> should be :
>
> gcc_assert (cached_reg_save_code[reg][mode] != -1);
>
> because cached_reg_save_code contains INSN_CODES that can be equal to 0
This is PR55036.
21 matches
Mail list logo
