Hans-Peter Nilsson wrote:
> On Thu, 16 Feb 2006, Sylvain Munaut wrote:
>
>>Move/Load/Store without flag is no problem. But for add, to allow
>>multiword add, carry is needed and I can't make it optionnal.
>
>
> As I hinted, perhaps you can have the multiword carry a separate
> one from the flags
Mark Mitchell wrote:
> > Mark, is it ok for Olivier to apply the patch mentioned here on
> > 4.1?
> Yes, thanks.
I have been away for a couple of days and see that the patch has been
committed to the various branches. Thanks :)
Andrew Pinski <[EMAIL PROTECTED]> writes:
> Now I run into another problem:
> /Users/pinskia/src/gcc/local/gcc/objdir.objc/./prev-gcc/xgcc
> -B/Users/pinskia/src/gcc/local/gcc/objdir.objc/./prev-gcc/
> -B/Volumes/temp/gcc/local.objc/powerpc-apple-darwin7.9.0/bin/ -c -g
> -O2 -mdynamic-no-pic -
Mark Mitchell wrote:
> Please download, build, and test. Please use these tarballs, rather
> than the current SVN branch, so that we test packaging, and other
> similar issues.
Here it looks good so far on i686-pc-linux-gnu
http://gcc.gnu.org/ml/gcc-testresults/2006-02/msg01036.html
Regards
Gr
No help? :-)
BTW Is there any documenation on machine?
I am looking at this one:
http://www.mhatt.aps.anl.gov/dohn/programming/gcc/gccint.html#SEC_Top
it might have been something else?
Thank you.
- Forwarded message from [EMAIL PROTECTED] -
Date: Wed, 08 Feb 2006 08:02:20 -0600
Andrew Haley wrote:
As a comparison point, I get
real73m39.275s
user113m19.549s
sys 15m26.010s
for the bootstrap: that's 1h14 elapsed time. That's on a "AMD
Athlon(tm) 64 X2 Dual Core Processor 4800+" (2.4 GHz) with make -j3.
That's 129min of CPU time in 74min of elapsed time, a
Joern RENNECKE writes:
> Andrew Haley wrote:
>
> >
> >As a comparison point, I get
> >
> >real73m39.275s
> >user113m19.549s
> >sys 15m26.010s
> >
> >for the bootstrap: that's 1h14 elapsed time. That's on a "AMD
> >Athlon(tm) 64 X2 Dual Core Processor 4800+" (2.4 GHz) with
Andrew Haley wrote:
> Is that using the i686 or amd64 instruction set? If the latter, does it
> use 32 or 64 bit pointers?
The latter. Yes.
So which pointer size does the host compiler use, and which pointer size
is used in
the gcc that is bootstrapped?
This RAM also has flashing L
Joern RENNECKE writes:
> Andrew Haley wrote:
>
> > > Is that using the i686 or amd64 instruction set? If the latter, does it
> > > use 32 or 64 bit pointers?
> >
> >The latter. Yes.
> >
> >
> So which pointer size does the host compiler use, and which pointer size
> is used in
> t
On Wed, 1 Feb 2006, H. J. Lu wrote:
> My memory hog patch for make has 2 typos. This patch fixes them.
Thanks, H. J. What's the upstream status of your patches? Did you
submit your updated patch there as well?
(As long as this patch, or a similar change, has not become part of a
released versi
In libjava/classpath there are two .cvsignore files which haven't been
deleted yet:
native/jni/midi-alsa/.cvsignore
native/jni/midi-dssi/.cvsignore
Should they go, too?
They are also in GCC 4.1.0 RC1.
Regards,
Volker
>
> In libjava/classpath there are two .cvsignore files which haven't been
> deleted yet:
>
> native/jni/midi-alsa/.cvsignore
> native/jni/midi-dssi/.cvsignore
>
> Should they go, too?
> They are also in GCC 4.1.0 RC1.
They are imported from upstream :).
-- Pinski
Hello,
I have the interesting and somewhat taunting task of providing a
toolchain that assumes -msoft-float unless told otherwise. Obviously,
this can be arranged with appropriate changes to the specs, however I'd
like to integrate this in a way that would benefit everybody.
The general idea
On Mon, Feb 20, 2006 at 06:54:07PM +0100, Simon Richter wrote:
> Hello,
>
> I have the interesting and somewhat taunting task of providing a
> toolchain that assumes -msoft-float unless told otherwise. Obviously,
> this can be arranged with appropriate changes to the specs, however I'd
> like t
Andrew Pinski writes:
> >
> > In libjava/classpath there are two .cvsignore files which haven't been
> > deleted yet:
> >
> > native/jni/midi-alsa/.cvsignore
> > native/jni/midi-dssi/.cvsignore
> >
> > Should they go, too?
> > They are also in GCC 4.1.0 RC1.
>
> They are imported
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bootstrap failure in libjava on ia64-unknown-linux-gnu.
Failure in building jv-convert:
/bin/sh ./libtool --tag=GCJ --mode=link
/disk1/SCRATCH/gcc-build/Linux/ia64-unknown-linux-gnu/gcc-4.1.0-RC1/gcc-4.1.0-RC1/gcc/gcj
- -B/disk1/SCRATCH/gcc-build/Linu
Hello,
Working on an arm-vxworks port for Ada, we noticed that both
NO_DOT_IN_LABEL and NO_DOLLAR_IN_LABEL are defined, the former from
config/vxworks.h and the latter from arm/aout.h.
Is it really intended this way ?
NO_DOT_IN_LABEL is actually #undef'ed from config/vxworks.h, but the
arm/aout.
Gerald wrote:
>On Wed, 1 Feb 2006, H. J. Lu wrote:
>> My memory hog patch for make has 2 typos. This patch fixes them.
>Thanks, H. J. What's the upstream status of your patches?
I think they're in upstream (hopefully H.J. will confirm that).
I know that the O(N^2) bug that Jeff Evarts found and f
On Mon, Feb 20, 2006 at 10:51:13AM -0800, Dan Kegel wrote:
> Gerald wrote:
> >On Wed, 1 Feb 2006, H. J. Lu wrote:
> >> My memory hog patch for make has 2 typos. This patch fixes them.
> >Thanks, H. J. What's the upstream status of your patches?
>
> I think they're in upstream (hopefully H.J. will
DJ Delorie wrote:
There's not much difference between multi-core and multi-cpu, and I've
been building multi-cpu for years.
Some multi-core processors come with less L2 cache than their multi-CPU
counterparts.
Also, multi-cpu itself comes in different varieties, with Intels Xeons going
for t
On Wed, Feb 01, 2006 at 01:21:03PM -0500, Andrew Pinski wrote:
> >
> > We ran into a problem building KDE on HP-UX 11.23/IA with the HP C++
> > compiler. The compiler mangled a function name in a .cpp file though
> > it was declared extern "C" in the .h file. After a post to the HP C++
> > develop
On Feb 17, 2006, at 8:04 PM, Serge Dundich wrote:
I need to define the constant memory address/offset in i386 gcc
inline asm,
i.e. immediate value without $ prefix, so I can use it as a
constant offset for
some memory address statement.
Is there any way to do that?
Sure, the manual descr
On Mon, Feb 20, 2006 at 07:30:41PM +, Joern RENNECKE wrote:
> the bottleneck of a shared memory bus, but the operating system must
> allocate
> most memory locally to each CPU to avoid a bottleneck in the cross-connect
> of the processors.
>
Linux kernel 2.6.16-rc1 and above supports
percpu
H. J. Lu wrote:
On Mon, Feb 20, 2006 at 07:30:41PM +, Joern RENNECKE wrote:
the bottleneck of a shared memory bus, but the operating system must
allocate
most memory locally to each CPU to avoid a bottleneck in the cross-connect
of the processors.
Linux kernel 2.6.16-rc1 and abo
Laurent GUERBY wrote:
On a Pentium III 1GHz, bootstrap is 5h55 and check 5h30
(on an older version of the tree),
Was this before top-level bootstrap?
On Mon, Feb 20, 2006 at 07:58:35PM +, Joern RENNECKE wrote:
> H. J. Lu wrote:
>
> >On Mon, Feb 20, 2006 at 07:30:41PM +, Joern RENNECKE wrote:
> >
> >
> >>the bottleneck of a shared memory bus, but the operating system must
> >>allocate
> >>most memory locally to each CPU to avoid a bott
On Sun, 2006-02-19 at 20:43 +0100, Laurent GUERBY wrote:
> On Sun, 2006-02-19 at 14:23 -0500, Richard Kenner wrote:
> > "Second, for a given integer type (such as
> > natural___XDLU_0_2147483647), the type for the nodes in TYPE_MIN_VALUE
> > and TYPE_MAX_VALUE really should be a natural
On 2/20/06, Jeffrey A Law <[EMAIL PROTECTED]> wrote:
> On Sun, 2006-02-19 at 20:43 +0100, Laurent GUERBY wrote:
> > On Sun, 2006-02-19 at 14:23 -0500, Richard Kenner wrote:
> > > "Second, for a given integer type (such as
> > > natural___XDLU_0_2147483647), the type for the nodes in TYPE_MI
Which leaves us with a very fundamental issue. Namely that we can not
use TYPE_MIN_VALUE or TYPE_MAX_VALUE for ranges.
The point is that it *is* supposed to be usable in general. If it can't
be used in a specific case, let's address that specific case and understand
what needs fixing
Indeed. Ada should in this case generate
R = (T)( (basetype)100 + (basetype)X - (basetype)X )
i.e. carry out all arithmetic explicitly in the basetype and only for
stores and loads use the subtype.
That is indeed required by the language and what is normally generated.
It
> Some multi-core processors come with less L2 cache than their multi-CPU
> counterparts.
This, and your other arguments, while valid, apply independently of
the CPU. There are a lot of factors that determine compile speed.
FYI SGIs tend to have crossbars.
> Was that UMA or NUMA, and how far u
On 2/20/06, Richard Kenner <[EMAIL PROTECTED]> wrote:
> Indeed. Ada should in this case generate
>
>R = (T)( (basetype)100 + (basetype)X - (basetype)X )
>
> i.e. carry out all arithmetic explicitly in the basetype and only for
> stores and loads use the subtype.
>
> That is
On Mon, 2006-02-20 at 19:40 +1100, Greg Schafer wrote:
> Mark Mitchell wrote:
>
> > Please download, build, and test. Please use these tarballs, rather
> > than the current SVN branch, so that we test packaging, and other
> > similar issues.
>
> Here it looks good so far on i686-pc-linux-gnu
>
On Feb 20, 2006, at 6:30 PM, Laurent GUERBY wrote:
one libstdc++ amd64 FAIL:
FAIL: abi_check
That is because you did not supply --enable-__cxa_atexit
to configure. This has been mentioned so many times it
might as well enabled it by default for GNU/Linux.
-- Pinski
Mark Mitchell wrote:
> GCC 4.1.0 RC1 is here:
>
> ftp://gcc.gnu.org/pub/gcc/prerelease-4.1.0-20060219
Looking fine on s390-ibm-linux and s390x-ibm-linux:
http://gcc.gnu.org/ml/gcc-testresults/2006-02/msg01094.html
http://gcc.gnu.org/ml/gcc-testresults/2006-02/msg01095.html
except for the recent
On Mon, 2006-02-20 at 18:34 -0500, Andrew Pinski wrote:
> On Feb 20, 2006, at 6:30 PM, Laurent GUERBY wrote:
>
> > one libstdc++ amd64 FAIL:
> >
> > FAIL: abi_check
>
> That is because you did not supply --enable-__cxa_atexit
> to configure. This has been mentioned so many times it
> might as we
> http://gcc.gnu.org/ml/gcc-testresults/2006-02/msg01095.html
FAIL: cc1010b
Artifact or real failure?
--
Eric Botcazou
Eric Botcazou <[EMAIL PROTECTED]> wrote on 21.02.2006 01:10:58:
> > http://gcc.gnu.org/ml/gcc-testresults/2006-02/msg01095.html
>
> FAIL: cc1010b
>
> Artifact or real failure?
One of the usual artifacts ...
Mit freundlichen Gruessen / Best Regards
Ulrich Weigand
--
Dr. Ulrich Weigand
GN
> One of the usual artifacts ...
Thanks. I've personally got them on Linux only, never ever on Solaris.
--
Eric Botcazou
[EMAIL PROTECTED] trunk]$ ../trunk/configure --enable-languages=c,fortran
--prefix=/home/wf/local
[EMAIL PROTECTED] trunk]$ make
[snip]
make[3]: Entering directory `/home/wf/svngcc/trunkbld/libiberty'
if [ x"" != x ]; then \
gcc -c -DHAVE_CONFIG_H -g -I. -I../../trunk/libiberty/../include -W -
> I think this is caused by a typos error in libiberty/pexecute.c. Doesn't
> anyone
> else see it?
Already fixed.
--- DJ Delorie <[EMAIL PROTECTED]>写道:
>
> > I think this is caused by a typos error in libiberty/pexecute.c. Doesn't
> anyone
> > else see it?
>
> Already fixed.
>
OK. Thanks.
Feng Wang
___
雅虎1G免费邮箱
Hi,
I've been testing gcc-4.1 RC1 on x86-linux-gnu with SPEC CPU 2000.
There are two main reasons I did this:
a) gcc is used for research experimentation and many research folks rely
on SPECCPU2000
b) I, in particular, need SPEC CPU 2000 to work with profile driven
feedback.
I
On Feb 20, 2006, at 11:54 PM, [EMAIL PROTECTED] wrote:
Hi,
I've been testing gcc-4.1 RC1 on x86-linux-gnu with SPEC CPU 2000.
Benchmark Plain compile Profile Driven Compile
168.wupwise Vt C2,Vt
172.mgridVt
On Feb 21, 2006, at 12:05 AM, Andrew Pinski wrote:
You need the alliterative source for this test.
s/alliterative/alternative/
-- Pinski
Hi,
While I read the mips.md, I find there are some constraints used in
function call templates, such as 'c' and 'j'. But these two
constraints seem not be defined and I can't find their explanation
both in source files and gcc internal. Well, aren't there anywhere I
missed? Otherwise, how can they
"Eric Fisher" <[EMAIL PROTECTED]> writes:
> While I read the mips.md, I find there are some constraints used in
> function call templates, such as 'c' and 'j'. But these two
> constraints seem not be defined and I can't find their explanation
> both in source files and gcc internal. Well, aren't t
On Tue, Feb 21, 2006 at 12:45:15AM +0100, Ulrich Weigand wrote:
> except for the recently introduced test case
> FAIL: gcc.dg/20060218-1.c (test for errors, line 6)
> FAIL: gcc.dg/20060218-1.c (test for excess errors)
This one should be already fixed on gcc-4_1-branch (after RC1
was released I co
48 matches
Mail list logo
