On Fri, Jun 02, 2006 at 08:23:49AM +0200, Wolfgang Mües wrote:
> Rask,
>
> (_only_ adding the clobber statement),
> I get
> >0/newlib/li bc/argz/argz_create_sep.c:60: error: unrecognizable insn:
> (insn 192 21 24 0 (set (reg:QI 1 r1) (reg:QI 4 r4)) -1
> (nil) (nil))
>
> What do you mean wit
Hi, all
This patch results a performance increase of 4% for SPECfp2000 and 13% for NAS
benchmark suite on
Itanium-2 system, respectively. More performance increase is hopeful by further
tuning the
parameters and improving the prefetch algorithm at tree level.
Details of NAS benchmarks are list
On Thu, 1 Jun 2006, Joe Buck wrote:
> Let's just add the info to the table. Here is a proposed patch.
> Note that I resorted by date and added an explanation. I think
> that the attempt to sort by release number became increasingly
> untenable after 3.4, because we now have heavy overlapping. Be
Canqun Yang wrote:
Hi, all
This patch results a performance increase of 4% for SPECfp2000 and 13% for NAS
benchmark suite on
Itanium-2 system, respectively. More performance increase is hopeful by further
tuning the
parameters and improving the prefetch algorithm at tree level.
Hi Canqun,
On 6/2/06, Canqun Yang <[EMAIL PROTECTED]> wrote:
This patch results a performance increase of 4% for SPECfp2000 and 13% for NAS
benchmark suite on
Itanium-2 system, respectively. More performance increase is hopeful by further
tuning the
parameters and improving the prefetch algorithm at tree
--- Andrey Belevantsev <[EMAIL PROTECTED]>:
> Canqun Yang wrote:
> > Hi, all
> >
> > This patch results a performance increase of 4% for SPECfp2000 and 13% for
> > NAS benchmark suite
> on
> > Itanium-2 system, respectively. More performance increase is hopeful by
> > further tuning the
> > par
Hello,
First a short description of a problem we are seeing, then a couple
of related questions on addressability checks in the gimplifier.
>From a simple Ada testcase which I can provide if need be, the front-end
is producing a MODIFY_EXPR with a lhs of the following shape when we get
to gimplif
On Thu, 2006-06-01 at 16:05, Mark Shinwell wrote:
> Mark Mitchell wrote:
> > Mark Shinwell wrote:
> >> As for the remaining problem, I suggest that we could:
> >>
> >> (i) always return the hard frame pointer, and disable FP elimination in
> >> the current function; or
> >>
> >> (iii) ...the same a
Richard Earnshaw wrote:
I'm not keen on this. On some machines a frame pointer is *very*
expensive, both in terms of the code required to set it up, and the
resulting loss of a register which affects code quality (in addition, on
Thumb, the frame pointer can access much less data on the stack th
> Mark Shinwell writes:
Mark> If the hard frame pointer is forced by default, then targets which are
Mark> particularly badly affected can simply define INITIAL_FRAME_ADDRESS_RTX.
Mark> Since such targets would presumably not have to force reload to keep
Mark> the frame pointer, then definitio
On 6/2/06, Gerald Pfeifer <[EMAIL PROTECTED]> wrote:
Mind to send/commit a patch to complete releases.html with 4.x
releases and add a step to releasing.html? (Basically you just
need to revert revision 1.26 of that file.)
Joe Buck beat me to it and you applied it for him. Thanks to
both of y
David Edelsohn wrote:
Mark Shinwell writes:
Mark> If the hard frame pointer is forced by default, then targets which are
Mark> particularly badly affected can simply define INITIAL_FRAME_ADDRESS_RTX.
Mark> Since such targets would presumably not have to force reload to keep
Mark> the frame poin
On Fri, 2006-06-02 at 14:57, Mark Shinwell wrote:
> Richard Earnshaw wrote:
> > I'm not keen on this. On some machines a frame pointer is *very*
> > expensive, both in terms of the code required to set it up, and the
> > resulting loss of a register which affects code quality (in addition, on
> >
On Fri, 2006-06-02 at 15:30, Mark Shinwell wrote:
> However when dealing with __builtin_frame_address, we must return the
> correct value from this function no matter what the value of count. This
> patch therefore forces use of a hard FP in such situations.
Eh? The manual explicitly says that
Canqun,
Nice job getting this ready for the current version of gcc!
Question: does gcc now know the difference between prefetching to cache L1 via
"lfetch", as opposed to prefetching only to level L2 via "lfetch.nt1"? For
floating point data, the latter is the only interesting case because flo
On Fri, Jun 02, 2006 at 04:20:21PM +0100, Richard Earnshaw wrote:
> On Fri, 2006-06-02 at 15:30, Mark Shinwell wrote:
>
> > However when dealing with __builtin_frame_address, we must return the
> > correct value from this function no matter what the value of count. This
> > patch therefore forces
> __builtin_frame_address(n) is not required to work for any value other
> than n=0. It's not clear what it means anyway on a function that
> eliminates the frame pointer.
>
> On ARM you *cannot* walk the stack frames without additional
> information. Frames are private to each function and there
On Fri, 2006-06-02 at 16:28, Paul Brook wrote:
> I agree that in general you need ancillary information way to get a backtrace
> on Arm. However if you assume only Arm code code and -fno-omit-frame-pointer
> then you can walk the frames. Given this assumption I think it make sense to
> have _b_f
On Fri, Jun 02, 2006 at 04:32:07PM +0100, Richard Earnshaw wrote:
> On Fri, 2006-06-02 at 16:28, Paul Brook wrote:
> > I agree that in general you need ancillary information way to get a
> > backtrace
> > on Arm. However if you assume only Arm code code and
> > -fno-omit-frame-pointer
> > then
How to reproduce this problem
-
1) Take some C file. I used for instance dwarf.c from
the new binutils distribution.
2) Generate an assembler listing of this file
3) Using objdump -s dwarf.o I dump all the
sections of the executable in hexadecimal format.
Put the
Richard Earnshaw wrote:
> The only chance you have for producing a backtrace() is to have
> unwinding information similar to that provided for exception unwinding.
> This would describe to the unwinder how that frames code is laid out so
> that it can unpick it.
I'd suggest we leave backtrace()
On Fri, 2006-06-02 at 16:35, Daniel Jacobowitz wrote:
> On Fri, Jun 02, 2006 at 04:32:07PM +0100, Richard Earnshaw wrote:
> > On Fri, 2006-06-02 at 16:28, Paul Brook wrote:
> > > I agree that in general you need ancillary information way to get a
> > > backtrace
> > > on Arm. However if you assum
On Friday 02 June 2006 16:44, Richard Earnshaw wrote:
> On Fri, 2006-06-02 at 16:35, Daniel Jacobowitz wrote:
> > On Fri, Jun 02, 2006 at 04:32:07PM +0100, Richard Earnshaw wrote:
> > > On Fri, 2006-06-02 at 16:28, Paul Brook wrote:
> > > > I agree that in general you need ancillary information way
On Fri, 2006-06-02 at 16:46, Mark Mitchell wrote:
> Richard, I can't tell from your comments how you think _b_f_a(0) should
> be implemented on ARM. We could use Mark's logic (forcing a hard frame
> pointer), but stuff it into INITIAL_FRAME_ADDRESS_RTX. We could also
> try to reimplement the thin
On Jun 2, 2006, at 8:46 AM, jacob navia wrote:
How to reproduce this problem
-
WHERE AM I WRONG ?
You should write to [EMAIL PROTECTED] if you want
a high probility of your question about the assembler
being answered.
-- Pinski
Richard stallman write last night:
I agree to the use of the Eclipse front end to generate
Java byte codes.
Note this does not mean importing Eclispe code into the gcc source or
release tree. We need to decide on a practical way to have people
grab a compatible version of ecj.
--
I took a quick pass at implementing the comparisons in a more suitable
lanugage. Run time is now a few seconds on both platforms. About the
same as compare_tests on my old ibook/OSX and much faster on FC3.
Trials show the same results as before.
For anyone interested, the new version is attached
On Fri, Jun 02, 2006 at 10:59:58AM -0700, Per Bothner wrote:
> Richard stallman write last night:
>
> I agree to the use of the Eclipse front end to generate
> Java byte codes.
>
> Note this does not mean importing Eclispe code into the gcc source or
> release tree. We need to decide o
Hi,
Here are some gcc 4.1.1 build reports.
#1: i686-pc-linux-gnu, Red Hat EL3: C, C++, ObjC, and Java.
"Native" tools were used.
Test results: http://gcc.gnu.org/ml/gcc-testresults/2006-06/msg00019.html
#2: ia64-unknown-linux-gnu, Red Hat Advanced Workstation 2.1AW. C, C++, ObjC.
bin
I haven't tried to build Java on Solaris in quite a while because it
takes so long.
My attempt to build on Solaris 2.8 with binutils 2.16.1 died with
/bin/ksh ./libtool --tag=GCJ --mode=link
/remote/atg2/jbuck/solaris.tmp/411/gcc/gcj
-B/remote/atg2/jbuck/solaris.tmp/411/sparc-sun-solaris2.8/lib
On 6/2/06, Davis, Mark <[EMAIL PROTECTED]> wrote:
Question: does gcc now know the difference between prefetching to cache L1 via
"lfetch", as opposed to prefetching only to level L2 via "lfetch.nt1"?
The ia64 backend knows the difference, see the prefetch pattern in ia64.md.
But ia64 is the on
On 6/3/06, Steven Bosscher <[EMAIL PROTECTED]> wrote:
> For floating point data, the latter is the only interesting case because
float loads only
> access the L2. Thus using "lfetch" for floating point arrays will
unnecessarily wipe out
> the contents of L1. (gcc 3.2.3 only seems to generate
Snapshot gcc-4.1-20060602 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20060602/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.1 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
On Jun 2, 2006, at 11:08 AM, James Lemke wrote:
I took a quick pass at implementing the comparisons in a more suitable
lanugage. Run time is now a few seconds on both platforms. About the
same as compare_tests on my old ibook/OSX and much faster on FC3.
Since Ben and I seem interested in this
--- "Davis, Mark" <[EMAIL PROTECTED]>:
> Canqun,
>
> Nice job getting this ready for the current version of gcc!
>
> Question: does gcc now know the difference between prefetching to cache L1
> via "lfetch", as
> opposed to prefetching only to level L2 via "lfetch.nt1"? For floating point
>
h8300 has an HImode insv pattern. If you try to use it with an SImode
argument, expmed.c uses gen_lowpart to force it into the desired mode.
However, gen_lowpart eventually fails for pseudos on big endian:
rtx
gen_rtx_SUBREG (enum machine_mode mode, rtx reg, int offset)
{
gcc_assert (validate_
"Steven Bosscher" <[EMAIL PROTECTED]> writes:
> On 6/2/06, Davis, Mark <[EMAIL PROTECTED]> wrote:
> > Question: does gcc now know the difference between prefetching to cache L1
> > via
> > "lfetch", as opposed to prefetching only to level L2 via "lfetch.nt1"?
>
> The ia64 backend knows the diffe
37 matches
Mail list logo
