Hi,
I ran part of the testsuite on the dataflow branch for spu-elf. I
only ran compile.exp as I don't have access to hardware (at home) and I
have not figured out how to use the "free" simulator from IBM yet.
There is one regression:
gcc.c-torture/compile/930513-2.c ICEs in find_reg_note when c
Steven Bosscher wrote:
On 12/11/06, David Daney <[EMAIL PROTECTED]> wrote:
From svn r119726 (Sun, 10 Dec 2006) I am getting an ICE during
bootstrap on mipsel-linux. This is a new failure since Wed Dec 6
06:34:07 UTC 2006 (revision 119575) which bootstrapped and tested just
fine. I don't reall
Hello,
I already post this message on gcc-help but had no answer.
Does anybody have a suggestion?
--
I recently started to test 'distcc' to speedup some compilations.
Then I noticed the sizes of generated objects were not the same
compiled locally (using gcc only) and remotely (using gcc throug
You might want to file a bug at http://gcc.gnu.org/bugzilla/ for this.
On 12/11/06, David Daney <[EMAIL PROTECTED]> wrote:
Lets assume that it doesn't effect i686 or x86_64. Because if it did,
someone else would have been hit by it by now.
I'm sure it doesn't, I bootstrapped&tested on those targets (and on ia64).
So you would need a mips[el]-linux system in ord
David Daney <[EMAIL PROTECTED]> wrote:
> From svn r119726 (Sun, 10 Dec 2006) I am getting an ICE during
> bootstrap on mipsel-linux. This is a new failure since Wed Dec 6
> 06:34:07 UTC 2006 (revision 119575) which bootstrapped and tested just
> fine. I don't really want to do a regression hu
On 12/11/06, Kaz Kojima <[EMAIL PROTECTED]> wrote:
It seems that the first tree dump which differs before and
after r119711 is .099t.optimized.
In that case, this is a different problem, probably caused by the new
out-of-SSA pass. But to be sure, I suggest you revert my CSE patch
and see if th
On Mon, 2006-12-11 at 15:16 +0100, Steven Bosscher wrote:
> On 12/11/06, Kaz Kojima <[EMAIL PROTECTED]> wrote:
> > It seems that the first tree dump which differs before and
> > after r119711 is .099t.optimized.
>
> In that case, this is a different problem, probably caused by the new
> out-of-SSA
On Fri, Dec 08, 2006 at 01:02:27PM -0600, Menezes, Evandro wrote:
> HJ,
>
> I'll run the three worst offenders below and get back to y'all.
>
> The full results will take longer.
Hi Evandro,
I also saw similar issues on x86-64 with -O2 -ffast-math:
gcc-4.2 rev 116820 gcc
Hi all,
How to download GCC projects from CVS
For e.g.i tried this one
cvs -d :pserver:[EMAIL PROTECTED]:/cvsroot/gcc checkout -P
/branches./fixed-point
But it did not work.
Regards,
Rohit
You have to use subversion, not CVS. Everything is explained here:
http://gcc.gnu.org/svn.html
The command you probably want is:
svn -q checkout svn://gcc.gnu.org/svn/gcc/branches/fixed-point/ fixed-point
I hope this helps.
Cheers,
Manuel.
On 11/12/06, Rohit Arul Raj <[EMAIL PROTECTED]> wr
HJ,
> > Gcc 4.3 revision 119497 has very poor SPEC CPU 2006 FP performance
> > regressions on P4, Pentium M and Core Duo, comparing aganst
> > gcc 4.2 20060910. With -O2, the typical regressions look like
> >
> > Gcc 4.2 Gcc 4.3
> > 410.bwaves 9.89
On Mon, Dec 11, 2006 at 11:35:27AM -0600, Menezes, Evandro wrote:
> HJ,
>
> > > Gcc 4.3 revision 119497 has very poor SPEC CPU 2006 FP performance
> > > regressions on P4, Pentium M and Core Duo, comparing aganst
> > > gcc 4.2 20060910. With -O2, the typical regressions look like
> > >
> > >
Andreas Tobler wrote:
> Dominique Dhumieres wrote:
>>...
>>cc1: warnings being treated as errors
>>../../gcc-4.3-20061209/gcc/varasm.c: In function 'elf_record_gcc_switches':
>>../../gcc-4.3-20061209/gcc/varasm.c:6268: warning: format '%llu' expects type
>>'long long unsigned int', but argument 3
Hello,
currently (on x86_64) the gdb backtrace does not properly stop at the outermost
frame:
#3 0x0036ddb0610a in start_thread () from /lib64/tls/libpthread.so.0
#4 0x0036dd0c68c3 in clone () from /lib64/tls/libc.so.6
#5 0x in ?? ()
Currently it relies only on clearin
Steve Ellcey <[EMAIL PROTECTED]> writes:
> Do you know if there a GCC bug report for this defect? I couldn't find
> one in bugzilla. I am seeing this problem with IA64 HP-UX on ToT.
Should be fixed now.
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfel
On 12/11/06, H. J. Lu <[EMAIL PROTECTED]> wrote:
On Sun, Dec 10, 2006 at 09:42:35PM -0800, H. J. Lu wrote:
> On Mon, Dec 11, 2006 at 12:27:07AM -0500, Daniel Berlin wrote:
> > Hey, by chance does the attached fix it?
> >
>
> Yes, it fixes 464.h264ref with the test input. I am running the real
> i
> -Original Message-
> From: H. J. Lu [mailto:[EMAIL PROTECTED]
> Sent: Monday, December 11, 2006 1:09 PM
> To: Menezes, Evandro
> Cc: gcc@gcc.gnu.org; [EMAIL PROTECTED]; rajagopal, dwarak; Meissner,
> Michael
> Subject: Re: Serious SPEC CPU 2006 FP performance regressions on IA32
>
> On M
Hello!
I'm particularly interested in this patch
(http://gcc.gnu.org/ml/gcc-patches/2005-07/msg01128.html); pretty
nice for
users of Pentium 3 and Athlon. Has it been or will it be integrated into
mainline?
This patch heavily depends on the functionality of optimize mode
switching pass. Unf
GCC's unwinder doesn't distinguish undefined from same_value, because it
doesn't matter for EH unwinding purposes. Both mean "nothing to be done
for this register". The distinction only matters to informative unwinding
purposes like debugging. I'm not sure why libgcc's unwinder really ought
to c
"Steven Bosscher" <[EMAIL PROTECTED]> wrote:
> In that case, this is a different problem, probably caused by the new
> out-of-SSA pass. But to be sure, I suggest you revert my CSE patch
> and see if that makes the problem go away for you.
I've confirmed that that problem is remained after reverti
On 12/12/06, Kaz Kojima <[EMAIL PROTECTED]> wrote:
"Steven Bosscher" <[EMAIL PROTECTED]> wrote:
> In that case, this is a different problem, probably caused by the new
> out-of-SSA pass. But to be sure, I suggest you revert my CSE patch
> and see if that makes the problem go away for you.
I've
Hi all,
The report in
http://gcc.gnu.org/ml/gcc-testresults/2006-12/msg00459.html
claims to be from the 4_2_branch at
Mon Dec 11 08:40:27 UTC 2006 (revision 119731)
That's wrong; it's actually from
Sun Dec 10 08:39:43 UTC 2006 (revision 119704)
but the run took more than 24 hours and the cro
"Steven Bosscher" <[EMAIL PROTECTED]> wrote:
> In the mipsel-linux case, we ended up with a diamond region where the
> jump in the IF-block was folded, so that we could extend the path
> along one of the diamond's arms with the JOIN-block. This could
> happen because cse_main traversed the basic b
> The report in
>
> http://gcc.gnu.org/ml/gcc-testresults/2006-12/msg00459.html
>
> claims to be from the 4_2_branch at
>
> Mon Dec 11 08:40:27 UTC 2006 (revision 119731)
>
> That's wrong; it's actually from
>
> Sun Dec 10 08:39:43 UTC 2006 (revision 119704)
>
> but the run took more than 24 hours
On Fri, 2006-10-13 at 12:51 -0400, Carlos O'Donell wrote:
> A relocated compiler should not look in $prefix.
> Comments?
> OK for Stage1?
I do have another issue with these set of patches which I did not notice
until today.
I can no longer do inside a just built GCC do:
./cc1 t.c
or
./xgcc -B. t.c
26 matches
Mail list logo
