> From: Ian Lance Taylor
> I'm also not aware of processors changing as you describe, except for
> the particular special case of SIMD vector instructions. gcc can and
> does represent vector instructions as a single set.
- Understood, unfortunately hiding the multiple-set nature of instructions
On Sat, Mar 26, 2005 at 12:00:43PM -0500, Kazu Hirata wrote:
> Have you considered merging CCP and VRP (as suggested by Kenny last
> year at the summit)?
>
By merging, do you mean *replacing* CCP with VRP? Yes, it's
doable. No, it's not a good idea.
Because of its lattice evaluation, VRP is ab
BjÃrn Haase <[EMAIL PROTECTED]> writes:
> Imagine, you are having a clean md with a consistent "double set"
> representation for all the patterns that actually alter the condition code. I
> understood, that the problem for the optimization passes (e.g. combine) then
> shows up only for instruct
Hi,
Peter S. Mazinger schrieb:
I'm not sure *-*-linux-uclibc would be the right choice, as it suggests
running Linux with uclibc as your C library, which is something the
binutils need not care about. I could, however, see a case for
*-*-uclinux due to the ABI differences and the need for relocatio
ÒýÑÔ Steven Bosscher <[EMAIL PROTECTED]>:
> On Sunday 27 March 2005 03:53, Canqun Yang wrote:
> > The last ChangeLog of rtlopt-branch was written in
> > 2003. After more than one year, many impovements in
> > this branch haven't been put into the GCC HEAD.
Why?
>
> Almost all of the rtlopt branch
On Sunday 27 March 2005 03:53, Canqun Yang wrote:
> The last ChangeLog of rtlopt-branch was written in
> 2003. After more than one year, many impovements in
> this branch haven't been put into the GCC HEAD. Why?
Almost all of the rtlopt branch was merged. Prefetching is one
of the few things that
The last ChangeLog of rtlopt-branch was written in
2003. After more than one year, many impovements in
this branch haven't been put into the GCC HEAD. Why?
ÒýÑÔ Steven Bosscher <[EMAIL PROTECTED]>:
> On Saturday 26 March 2005 02:22, Canqun Yang wrote:
> > Â Â Â Â Â Â Â Â * loop.c (PREFETCH_BLO
E. Weddington wrote:
Dave Murphy wrote:
copying the compile line and removing the spurious -I and the
-I../../../gcc-4.0-20050319-new/gcc/ results in no errors.
I'm having a little trouble finding where this line is built up in
the makefiles, can anyone point me in the right direction to solve
Snapshot gcc-4.0-20050326 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.0-20050326/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.0 CVS branch
with the following options: -rgcc-ss-4_0-20050326
You'll
On Sat, 26 Mar 2005 02:17:58 +0100, Steven Bosscher <[EMAIL PROTECTED]> wrote:
> On Saturday 26 March 2005 02:22, Canqun Yang wrote:
> > * loop.c (PREFETCH_BLOCKS_BEFORE_LOOP_MAX): Defined conditionally.
> > (scan_loop): Change extra_size from 16 to 128.
> > (emit_prefetch_i
Hi Diego,
Have you considered merging CCP and VRP (as suggested by Kenny last
year at the summit)?
Originally I was thinking that ASSERT_EXPRs, or ranges gathered by VRP
rather, were very useful for jump threading, but they seem to be
useful for constant propagation, too. Consider
void bar (int
On Friday 25 March 2005 02:09, James E Wilson wrote:
> I tried it, it doesn't help. It solves neither the loop invariant code
> motion problem nor the do-loop optimization problem.
As pointed out by Andrew Pinski, the do-loop transformation was in fact
not valid. The rest of the slowdown looks l
Dave Murphy wrote:
After 3 or 4 restarts it finally appears to proceed normally until
building libgcc
make[3]: Leaving directory
`/c/projects/devkitPro/sources/arm-elf/gcc/gcc'
/c/projects/devkitPro/sources/arm-elf/gcc/gcc/xgcc
-B/c/projects/devkitPro/sources/arm-elf/gcc/gcc/
-Bc:/devkitARM_r1
On Mar 25, 2005, at 1:22 PM, Tom Tromey wrote:
"Brad" == Bradley Lucier <[EMAIL PROTECTED]> writes:
Brad> http://gcc.gnu.org/ml/gcc-testresults/2005-03/msg01559.html
I didn't see more recent results, but I suspect this problem has been
fixed.
It seems that the libjava tests have been turned off, so
> I do regular bootstraps of mainline all languages on FC3
> i686-pc-linuux-gnu and haven't seen any problemss upto Friday. I'm using
> --enable-checking=tree,misc,rtl,rtlflag which might make a difference.
You should add 'assert' with 4.x, otherwise you miss the simple assertions.
--
Eric Botc
Hi Alex,
I do regular bootstraps of mainline all languages on FC3 i686-pc-linuux-gnu
and haven't seen any
problemss upto Friday. I'm using --enable-checking=tree,misc,rtl,rtlflag which
might make a
difference.
Cheers
Graham
On Saturday 26 March 2005 04:11, Ian Lance Taylor wrote:
> I'm also not aware of processors changing as you describe,
Well, ia64 comes to mind. Take the cmp4.* instructions for example.
They are of the form "(predicate) cmp4.cmpoperator p1,p2 = cmpoperands"
where p1 and p2 are predicate registers
I've been getting bootstrap failures on i686-pc-linux-gnu for the past
few days, with --enable-languages=all,ada, on Fedora Core devel.
There are indeed differences between stage2 and stage3 targparm.o, but
upon visual inspection, they appear to be harmless, possibly some
effect of FP extra precisi
DJ Delorie <[EMAIL PROTECTED]> writes:
>> Less to maintain is all I was hoping for. I think the configure
>> scripts (both libiberty's and gcc's) could be simplified quite a bit
>> if we assumed a C89 compliant runtime library, as could libiberty.h
>> and system.h.
>
> Well, gcc can make assumpti
19 matches
Mail list logo
