On 12/5/2013, 9:35 AM, Tejas Belagod wrote:
Vladimir Makarov wrote:
On 12/4/2013, 6:15 AM, Tejas Belagod wrote:
Hi,
I'm trying to relax CANNOT_CHANGE_MODE_CLASS for aarch64 to allow all
mode changes on FP_REGS as aarch64 does not have register-packing, but
I'm running into an LRA ICE. A test c
On 12/06/13 07:17, Richard Biener wrote:
On Fri, Dec 6, 2013 at 2:52 PM, Konstantin Vladimirov
wrote:
Hi,
Richard, I tried to add LSHIFT_EXPR case to tree-scalar-evolution.c
and now it yields code like (x86 again):
.L5:
movzbl 4(%esi,%eax,4), %edx
movb %dl, 4(%ebx,%eax,4)
addl $1, %eax
cmpl %
On Fri, 2013-12-06 at 09:05 -0500, David Edelsohn wrote:
> I am pleased to announce that the GCC Steering Committee has
> appointed Oleg Endo as co-maintainer of the SH port.
>
> Please join me in congratulating Oleg on his new role.
> Oleg, please update your listing in the MAINTAINER
On Fri, Dec 06, 2013 at 10:47:00AM +0100, Richard Biener wrote:
> On Fri, Dec 6, 2013 at 5:47 AM, Trevor Saunders wrote:
> > On Mon, Dec 02, 2013 at 12:16:18PM +0100, Richard Biener wrote:
> >> On Sun, Dec 1, 2013 at 12:30 PM, Toon Moene wrote:
> >> > http://gcc.gnu.org/ml/gcc-testresults/2013-12
On Dec 6, 2013, at 5:40 AM, Umesh Kalappa wrote:
> Hi all,
>
> We are re-targeting the gcc 4.8.1 to the 16 bit core ,where word =int
> = short = pointer= 16 , char = 8 bit and long =32 bit.
>
> We model the above requirement as
>
> #define BITS_PER_UNIT 8
>
> #define BITS_PER_WOR
On 12/06/2013 10:41 AM, Umesh Kalappa wrote:
> I’m bit confused or i'm missing something here .
The first of these is implementation-defined behaviour, and the second
is (potentially) undefined behaviour.
This is more of a generic C question than a GCC question.
Andrew.
On Fri, Dec 6, 2013 at 2:52 PM, Konstantin Vladimirov
wrote:
> Hi,
>
> Richard, I tried to add LSHIFT_EXPR case to tree-scalar-evolution.c
> and now it yields code like (x86 again):
>
> .L5:
> movzbl 4(%esi,%eax,4), %edx
> movb %dl, 4(%ebx,%eax,4)
> addl $1, %eax
> cmpl %ecx, %eax
> jne .L5
>
> So
I am pleased to announce that the GCC Steering Committee has
appointed Oleg Endo as co-maintainer of the SH port.
Please join me in congratulating Oleg on his new role.
Oleg, please update your listing in the MAINTAINERS file.
Happy hacking!
David
Hi,
Richard, I tried to add LSHIFT_EXPR case to tree-scalar-evolution.c
and now it yields code like (x86 again):
.L5:
movzbl 4(%esi,%eax,4), %edx
movb %dl, 4(%ebx,%eax,4)
addl $1, %eax
cmpl %ecx, %eax
jne .L5
So, excessive lea is gone. It is great, thank you so much. But I
wonder what else can I
On Fri, 6 Dec 2013, Konstantin Vladimirov wrote:
Consider code:
int foo(char *t, char *v, int w)
{
int i;
for (i = 1; i != w; ++i)
{
int x = i << 2;
A side note, but something too few people seem to be aware of: writing
i<<2 can pessimize code compared to i*4 (and it is never faster). That
Umesh Kalappa writes:
> Tried to compile the below sample by retargeted compiler
>
> int a =10;
>
> int b =10;
>
>
> int func()
>
> {
>
> return a+ b;
>
> }
>
> the compiler is stating that the a and b are global with short type(HI
> mode) of size 2 bytes.
Yeah, HImode sounds right in this case.
On Wed, 4 Dec 2013, Vidya Praveen wrote:
> Hi Richi,
>
> Apologies for the late response. I was on vacation.
>
> On Mon, Oct 14, 2013 at 09:04:58AM +0100, Richard Biener wrote:
> > > void
> > > foo (int *__restrict__ a,
> > > int *__restrict__ b,
> > > int c)
> > > {
> > > int i;
> >
On Fri, Dec 6, 2013 at 2:25 AM, Richard Biener
wrote:
> On Fri, Dec 6, 2013 at 11:19 AM, Konstantin Vladimirov
> wrote:
>> Hi,
>>
>> nothing changes if everything is unsigned and we are guaranteed to not
>> raise UB on overflow:
>>
>> unsigned foo(unsigned char *t, unsigned char *v, unsigned w)
>
Hi All ,
The below sample caught my attention i.e
int a ;
unsigned int b;
int func()
{
return a =b;
}
the compiler didn't warn me about the signed mismatch in the above case.
where as
int *a ;
unsigned int *b;
int func()
{
a =b;
return *a;
}
compiler warns me as
warning: pointer targets in a
Hi all,
We are re-targeting the gcc 4.8.1 to the 16 bit core ,where word =int
= short = pointer= 16 , char = 8 bit and long =32 bit.
We model the above requirement as
#define BITS_PER_UNIT 8
#define BITS_PER_WORD 16
#define UNITS_PER_WORD 2
#define POINTER_SIZE
On Fri, Dec 6, 2013 at 11:19 AM, Konstantin Vladimirov
wrote:
> Hi,
>
> nothing changes if everything is unsigned and we are guaranteed to not
> raise UB on overflow:
>
> unsigned foo(unsigned char *t, unsigned char *v, unsigned w)
> {
> unsigned i;
>
> for (i = 1; i != w; ++i)
> {
> unsigned x =
Hi,
nothing changes if everything is unsigned and we are guaranteed to not
raise UB on overflow:
unsigned foo(unsigned char *t, unsigned char *v, unsigned w)
{
unsigned i;
for (i = 1; i != w; ++i)
{
unsigned x = i << 2;
v[x + 4] = t[x + 4];
}
return 0;
}
yields:
.L5:
leal 0(,%eax,4), %edx
add
On Fri, Dec 6, 2013 at 9:30 AM, Konstantin Vladimirov
wrote:
> Hi,
>
> Consider code:
>
> int foo(char *t, char *v, int w)
> {
> int i;
>
> for (i = 1; i != w; ++i)
> {
> int x = i << 2;
> v[x + 4] = t[x + 4];
> }
>
> return 0;
> }
>
> Compile it to x86 (I used both gcc 4.7.2 and gcc 4.8.1) with o
On Fri, Dec 06, 2013 at 12:30:54PM +0400, Konstantin Vladimirov wrote:
> Consider code:
>
> int foo(char *t, char *v, int w)
> {
> int i;
>
> for (i = 1; i != w; ++i)
> {
> int x = i << 2;
> v[x + 4] = t[x + 4];
> }
>
> return 0;
> }
This is either job of ivopts pass, dunno why it doesn't consi
On Fri, Dec 6, 2013 at 9:42 AM, Richard Sandiford
wrote:
> Eric Botcazou writes:
>>> Well, I think making the simplify-rtx code conditional on the target
>>> would be the wrong way to go. If we really can't live with it being
>>> unconditional then I think we should revert it. But like I say I
On Fri, Dec 6, 2013 at 5:47 AM, Trevor Saunders wrote:
> On Mon, Dec 02, 2013 at 12:16:18PM +0100, Richard Biener wrote:
>> On Sun, Dec 1, 2013 at 12:30 PM, Toon Moene wrote:
>> > http://gcc.gnu.org/ml/gcc-testresults/2013-12/msg1.html
>> >
>> > FAILED: Bootstrap (build config: lto; languages
Hi,
Example from x86 code was only for ease of reproduction. I am pretty
sure, this is architecture-independent issue. Say on ARM:
.L2:
mov ip, r3, asl #2
add ip, ip, #4
add r3, r3, #1
ldrb r4, [r0, ip] @ zero_extendqisi2
cmp r3, r2
strb r4, [r1, ip]
bne .L2
May be improved to:
.L2:
add r3, r3,
Any gnat official release ? Maybe gnat 7.2 beta is based on 4.8, I'll try to
get this one.
-Message d'origine-
De : Andrew Pinski [mailto:pins...@gmail.com]
Envoyé : vendredi 6 décembre 2013 09:54
À : BELBACHIR Selim
Cc : Jeff Law; gcc@gcc.gnu.org
Objet : Re: Controling reloads of movsi
On 06/12/13 09:30, Konstantin Vladimirov wrote:
> Hi,
>
> Consider code:
>
> int foo(char *t, char *v, int w)
> {
> int i;
>
> for (i = 1; i != w; ++i)
> {
> int x = i << 2;
> v[x + 4] = t[x + 4];
> }
>
> return 0;
> }
>
> Compile it to x86 (I used both gcc 4.7.2 and gcc 4.8.1) with options:
>
On Fri, Dec 6, 2013 at 12:41 AM, BELBACHIR Selim
wrote:
> Hum, I can't change gcc branch because I'm tighted to gnat 7.1.2 based on gcc
> 4.7.3 (I saw that LRA was merged in 4.8). I will use a workaround for the
> moment (i.e. disable wide offset MEM on conditional moves).
> Does someone know if
On 06-Dec-13 01:34 AM, Maxim Kuvyrkov wrote:
On 6/12/2013, at 8:44 am, shmeel gutl wrote:
On 05-Dec-13 02:39 AM, Maxim Kuvyrkov wrote:
Dependency type plays a role for estimating costs and latencies between
instructions (which affects performance), but using wrong or imprecise
dependency ty
Eric Botcazou writes:
>> Well, I think making the simplify-rtx code conditional on the target
>> would be the wrong way to go. If we really can't live with it being
>> unconditional then I think we should revert it. But like I say I think
>> it would be better to make combine recognise the redun
Hum, I can't change gcc branch because I'm tighted to gnat 7.1.2 based on gcc
4.7.3 (I saw that LRA was merged in 4.8). I will use a workaround for the
moment (i.e. disable wide offset MEM on conditional moves).
Does someone know if gnat frontend will rebase on 4.8 soon :) ? (or maybe LRA
will b
Hi,
Consider code:
int foo(char *t, char *v, int w)
{
int i;
for (i = 1; i != w; ++i)
{
int x = i << 2;
v[x + 4] = t[x + 4];
}
return 0;
}
Compile it to x86 (I used both gcc 4.7.2 and gcc 4.8.1) with options:
gcc -O2 -m32 -S test.c
You will see loop, formed like:
.L5:
leal 0(,%eax,4), %edx
29 matches
Mail list logo
