Hello,
Tadas V wrote:
I am a computer science student and currently I am preparing my master
degree final work on "Compiler optimization on IA64 platforms". So
could you provide some information to me what is the the current
situation with gcc and IA64 platfrom - I mean what are open
optimizatio
Dear Shafi
Thanks you very much for the clear details. Definitely your inputs are
helpful.
1) I am sure that in gcc-4.0 I found there is file gmon.c in the path
gcc-4.0.0/gcc/gmon.c. Anyhow let me concentrate on gmon.c of glibc.
2) Next thing I would like to know is to better understand the gmo
2008/5/20 Andy H <[EMAIL PROTECTED]>:
>
> I came across this odd issue with testsuite test Wconversion-5.c and AVR
> target.
> I should get warning going from a unsigned value that is wider than signed
> result.
>
Yes. You should also get a warning from a unsigned value converted to
a same-width s
On Mon, May 19, 2008 at 8:50 PM, Laurent GUERBY <[EMAIL PROTECTED]> wrote:
> Hi,
>
> The GCC Compile Farm project is pleased to announce that two bi-quad
> core machines with the latest Opteron 8354 "Barcelona B3" processor and
> 16GB of RAM donated by AMD are now available online in datacenter
On Mon, 19 May 2008, Uros Bizjak wrote:
> Hello!
>
> > GCC 4.3.1 is still not ready for release as the x86 direction flag
> > issue (36079) needs to be resolved. We have reached consensus to
> > add a new flag -mcld to allow to work around the kernel bug and to
> > add a configure option to enab
On Tue, 20 May 2008, Andrey Belevantsev wrote:
> As you can see from the above page, it comes from the 2001 mini summit,
> so most of the projects mentioned there are already done.
Any chance you could make a pass through that page and remove those
items that you know have already been done, or s
I noticed that GCC 4.3 seems to put unitialized data like predefined one into
the data segment, leading to unnecessarily huge object files and binaries. The
GCC 4.01 bundled with MacOS 10.5 seems to handle it in a better way.
GCC 4.3 stores uninitialized data as "(__DATA,__data) external", while
Gerald Pfeifer wrote:
Any chance you could make a pass through that page and remove those
items that you know have already been done, or separate those that
are still open and those that have been done into two different
sections?
Sure, I would make a note to do this somewhere during stage2.
> To me too, but I still maintain that it's better to print in UTF-8 (which
> would make the langhook more useful). The recent Unicode patches for C
> possibly could use the langhook too.
OK, I need to focus on making progress and fix the current behaviour,
which is broken for gfortran (ie doesn'
Hello!
Does anybody else see build failure on 4_3 branch? My build from a
clean dir (./configure --with-mpfr=/usr/local) dies with
gcc -c -g -fkeep-inline-functions -DIN_GCC -W -Wall
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition -Wmissing-format-attribute -pe
On Tue, May 20, 2008 at 3:57 PM, Uros Bizjak <[EMAIL PROTECTED]> wrote:
> Hello!
>
> Does anybody else see build failure on 4_3 branch? My build from a
> clean dir (./configure --with-mpfr=/usr/local) dies with
>
> gcc -c -g -fkeep-inline-functions -DIN_GCC -W -Wall
> -Wwrite-strings -Wstri
On Tue, May 20, 2008 at 4:52 PM, Richard Guenther
<[EMAIL PROTECTED]> wrote:
>> Does anybody else see build failure on 4_3 branch? My build from a
>> clean dir (./configure --with-mpfr=/usr/local) dies with
> It works for me. Maybe you have a too high -j and some dependencies
> are missing? W
Hello all,
For the 16 bit target that i am currently porting can have only
positive offsets less than 0x100. (unsigned 8 bit) for offset
addressing mode.
During reload i am getting ICE because the address created is not
legitimate. So i guess i have to define the macro
LEGITIMIZE_RELOAD_ADDRESS.
B
"Mohamed Shafi" <[EMAIL PROTECTED]> writes:
> For the 16 bit target that i am currently porting can have only
> positive offsets less than 0x100. (unsigned 8 bit) for offset
> addressing mode.
I would expect reload to be able to handle this kind of thing anyhow,
assuming you define GO_IF_LEGITIMA
2008/5/20 Ian Lance Taylor <[EMAIL PROTECTED]>:
> "Mohamed Shafi" <[EMAIL PROTECTED]> writes:
>
>> For the 16 bit target that i am currently porting can have only
>> positive offsets less than 0x100. (unsigned 8 bit) for offset
>> addressing mode.
>
> I would expect reload to be able to handle this
Ian Lance Taylor wrote:
"Mohamed Shafi" <[EMAIL PROTECTED]> writes:
For the 16 bit target that i am currently porting can have only
positive offsets less than 0x100. (unsigned 8 bit) for offset
addressing mode.
I would expect reload to be able to handle this kind of thing anyhow,
assuming you
Richard Sandiford wrote:
> Also, you need to beware of cases in which operands[1] overlaps
> operands[0]. The splitter says:
>
> [(set (match_dup 2) (match_dup 4))
> (set (match_dup 3) (match_dup 5))]
>
> and operands[2] is always the highpart:
>
>operands[2] = gen_highpart(QImode, operands
On Tue, May 20, 2008 at 2:30 PM, Omar Torres <[EMAIL PROTECTED]> wrote:
> By looking at other ports, I learned that I can detect when this happens
> by using the reg_overlap_mentioned_p(). Here is one case:
> (insn 43 115 74 (set (reg:HI 7 %i0h)
> (mem/s/j:HI (plus:HI (reg/f:HI 7 %i0h [orig
On Tuesday 20 May 2008, Andrew Pinski wrote:
> On Tue, May 20, 2008 at 2:30 PM, Omar Torres <[EMAIL PROTECTED]> wrote:
> > By looking at other ports, I learned that I can detect when this happens
> > by using the reg_overlap_mentioned_p(). Here is one case:
> > (insn 43 115 74 (set (reg:HI 7 %i0h)
On Tue, May 20, 2008 at 2:47 PM, Paul Brook <[EMAIL PROTECTED]> wrote:
> Does this work reliably for straight mov patterns and during reload? Sounds
> like in the general case it would need secondary reloads, which is a whole
> lot of extra magic.
Hmm, right. Maybe something like what rs6000 does
Thanks for explanation and help
But this leave me with the conclusion that one of the following must be
wrong:
signed char xi;
xi = (int) (unsigned short int) sc;/* testcase NO WARNING - think
this is bug*/
xi = (long) (unsigned short int) sc;/* warning: conversion to
'signed char
2008/5/21 Andy H <[EMAIL PROTECTED]>:
> Thanks for explanation and help
>
> But this leave me with the conclusion that one of the following must be
> wrong:
>
> signed char xi;
>
> xi = (int) (unsigned short int) sc;/* testcase NO WARNING - think this
> is bug*/
> xi = (long) (unsigned short
On Tue, May 20, 2008 at 1:54 PM, <[EMAIL PROTECTED]> wrote:
> Dear Shafi
>
> Thanks you very much for the clear details. Definitely your inputs are
> helpful.
>
> 1) I am sure that in gcc-4.0 I found there is file gmon.c in the path
> gcc-4.0.0/gcc/gmon.c. Anyhow let me concentrate on gmon.c of g
23 matches
Mail list logo
