Re: Copies of the GCC repository

> Most svn side operations create subpools for loops that may allocate > per-iteration memory due to calls to other functions, etc, and clear it > each iteration to avoid such per iteration allocations become too large. > Some don't. FWIW, the first (and only) time I tried to do a svn diff on lots

Successfull build & install of GCC 4.0.2

Dear sirs, As per your request in gcc-4.0.2/INSTALL/finalinstall.html, I herewith send you the following information on my build & installation of GCC: - config.guess states "i686-pc-linux-gnu" - gcc -v output: Using built-in specs. Target: i686-pc-linux-gnu Configured with ../gcc-4.0.2/co

Anh vao dia chi nay nhe

Em tim duoc dia chi cuu data cho anh roi, anh goi so may nay nhe: 04- 9875709, o do ho chuyen sua chua may vi tinh va chuyen cuu du lieu day. Day la dia chi website cua ho: http://suachua.vnn.vn anh vao do xem truoc gia ca cuu du lieu va dia chi cu the cua ho nhe.

Anh vao dia chi nay nhe

Em tim duoc dia chi cuu data cho anh roi, anh goi so may nay nhe: 04- 9875709, o do ho chuyen sua chua may vi tinh va chuyen cuu du lieu day. Day la dia chi website cua ho: http://suachua.vnn.vn anh vao do xem truoc gia ca cuu du lieu va dia chi cu the cua ho nhe.

Re: Why doesn't combine like volatiles? (volatile_ok again, sorry!)

On Tue, 2005-11-22 at 19:10, Robert Dewar wrote: > Dave Korn wrote: > > Robert Dewar wrote: > > > > > Isn't it pretty much implied by point 1, "Not more than one volatile > > memory > > ref appears in the instructions being considered"? > > No, that allows a volatile reference to be combine

[C++] Should the complexity of std::list::size() be O(n) or O(1)?

The C++ standard said Container::size() should have constant complexity (ISO/IEC 14882:1998, pp. 461, Table 65), while the std::list::size() in current STL of GCC is defined as { std::distance(begin(), end()); }, whose complexiy is O(n). Is it a bug?

Re: Why doesn't combine like volatiles? (volatile_ok again, sorry!)

Richard Earnshaw wrote: This restriction rules out, for example, using a volatile value as an input in many floating point operations (since the operations may trap depending on the values read). I don't see this at all. If you have a volatile variable that traps in this situation, then that's

Re: Copies of the GCC repository

On Wed, 2005-11-23 at 09:39 +0100, Arnaud Charlet wrote: > > Most svn side operations create subpools for loops that may allocate > > per-iteration memory due to calls to other functions, etc, and clear it > > each iteration to avoid such per iteration allocations become too large. > > Some don't.

Re: [C++] Should the complexity of std::list::size() be O(n) or O(1)?

聂久焘 wrote: > The C++ standard said Container::size() should have constant complexity > (ISO/IEC 14882:1998, pp. 461, Table 65), while the std::list::size() in > current STL of GCC is defined as { std::distance(begin(), end()); }, whose > complexiy is O(n). > > Is it a bug? > > This question wo

Compilation of Ada for Arm failed

ctive ignored :0: warning: 'nothrow' attribute directive ignored +===GNAT BUG DETECTED======+ | 4.2.0 20051123 (experimental) (arm-unknown-rtems) GCC error: | | tree check: expected class 'expression', have 'exceptiona

Re: Why doesn't combine like volatiles? (volatile_ok again, sorry!)

On Wed, 2005-11-23 at 11:41, Robert Dewar wrote: > Richard Earnshaw wrote: > > > This restriction rules out, for example, using a volatile value as an > > input in many floating point operations (since the operations may trap > > depending on the values read). > > I don't see this at all. If you

Re: Compilation of Ada for Arm failed

> So before submitting a bug report (if necessary), I wanted to know if > someone knows something about it. PR ada/22533. -- Eric Botcazou

Re: Thoughts on LLVM and LTO

On Tuesday 22 November 2005 11:45, Daniel Berlin wrote: > > Another minor nit is performance. Judging by SPEC, LLVM has some > > performance problems. It's very good for floating point (a 9% > > advantage over GCC), but GCC has a 24% advantage over LLVM 1.2 in > > integer code. I'm sure that is

Re: Why doesn't combine like volatiles? (volatile_ok again, sorry!)

Richard Earnshaw wrote: Consider a non-load/store machine that has a floating-point operation that can add a value in memory to another register: fadd Rd, Rs, (mem) // Rd = Rs + (mem) Now if (mem) is volatile and the value returned is a signalling NaN then the trap handler has no way

Re: Thoughts on LLVM and LTO

On Tuesday 22 November 2005 13:17, Benjamin Kosnik wrote: > What about compile-time performance? > Well, it's hard to say, I have not really used LLVM extensively. The only real data I have is compile times for SPECint: SPECint build times (secs) -O2

Re: dfp-branch merge plans

On Wed, 23 Nov 2005, Ben Elliston wrote: > 3. Merge in libcpp and C (only) front-end changes. > > 4. Merge in middle-end changes and internals documentation. What have you done in the way of command-line options to enable the new features? Specifically: * Decimal fp constants are already prep

Re: Register Allocation

Hi, On Tue, 22 Nov 2005, Peter Bergner wrote: > Spill Location Optimizer [page(s) 11]: > * The IBM iSeries backend has this optimization. During spilling, > it inserts copies to/from spill pseudos (essentially like another > register class) which represent the stores/loads from t

SVN conversion glitch?

Hi! While doing svn diff, I've noticed gcc/config/i386/xm-dgux.h gcc/config/i386/xm-sysv3.h gcc/config/i386/xm-sun.h gcc/config/i386/scodbx.h files popped out of nowhere on the trunk (and through 4.1 branching also on gcc-4_1-branch). The files according to ChangeLogs were clearly removed back in

Re: Register Allocation

On Fri, 2005-11-18 at 22:18 -0800, Ian Lance Taylor wrote: > Andrew MacLeod <[EMAIL PROTECTED]> writes: > Secondary/tertiary reloads and reload_in/out patterns are apparently > subsumed by the Spill Engine. Porting a target to the new framework > is going to require providing the Spill Engine wit

Re: Register Allocation

On Sun, 2005-11-20 at 01:37 +0100, Steven Bosscher wrote: > On Thursday 17 November 2005 17:53, Andrew MacLeod wrote: > > http://people.redhat.com/dnovillo/rable.pdf > > How are the insn annotations and caches you propose different from > what df.c already does? > I don't know, I haven't really

Re: Register Allocation

On Tue, 2005-11-22 at 13:26 -0600, Peter Bergner wrote: > Register Coalescing [page(s) 8]: > * We will probably need some method for telling the coalescer > that a particular copy (or type of copy/copies) should either > be completely ignored (ie, do not coalesce it even if it look

Re: The actual LLVM integration patch

On 11/22/05, Chris Lattner <[EMAIL PROTECTED]> wrote: > This is a patch vs the Apple branch as of a few weeks ago. The diff is in > gcc.patch.txt, the new files are included in the tarball. apple-local-200502-branch rev 104970 I think. Rafael

Re: Thoughts on LLVM and LTO

On Wed, 23 Nov 2005, Diego Novillo wrote: On Tuesday 22 November 2005 13:17, Benjamin Kosnik wrote: What about compile-time performance? Well, it's hard to say, I have not really used LLVM extensively. The only real data I have is compile times for SPECint: SPECint build times (sec

Re: Thoughts on LLVM and LTO

On Wednesday 23 November 2005 13:13, Chris Lattner wrote: > I assume you're timing a release build here, not a debug build. > Yes, a release build. > In any case, the LLVM time above includes the following: > [ ... ] > Well, it seems that it's too early to test LLVM, then. It's both slow and i

Re: dfp-branch merge plans

On Wed, Nov 23, 2005 at 02:05:03PM +, Joseph S. Myers wrote: > On Wed, 23 Nov 2005, Ben Elliston wrote: > > > 3. Merge in libcpp and C (only) front-end changes. > > > > 4. Merge in middle-end changes and internals documentation. > > What have you done in the way of command-line options to en

[RFC] fixproto and canadian cross builds

I'm having problems building a canadian cross to a target that uses fixproto (m68k-elf). There seems to be some inconsistency in how fix-headers is build/run. In gcc/Makefile.in we have the following comments: # gen-protos and fix-header are compiled with CC_FOR_BUILD, but they are only # used

Accidentally on the list....

Hi all; I misunderstood what this list was for and ended up on it. No instructions on the messages on how to get off and I don't' remember where I went to get on.. Can someone point me? Thanks. Eric

Re: Accidentally on the list....

On Wed, 23 Nov 2005, Eric J. Goforth wrote: > I misunderstood what this list was for and ended up on it. No > instructions on the messages on how to get off and I don't' remember > where I went to get on.. Can someone point me? Thanks. Every message on this list carries the following headers:

Re: Register Allocation

Andrew MacLeod <[EMAIL PROTECTED]> writes: > > The current reload pass includes general heuristics to handle > > reloading memory addresses. This code knows things like "if stack > > pointer plus displacement is not a valid memory address, try loading > > the displacement into a register." Many

Re: Register Allocation

On Wed, 2005-11-23 at 15:05 +0100, Michael Matz wrote: > > Spill Cost Engine [page(s) 26-29]: > > * The register allocator should not be estimating the execution > > frequency of a basic block as 10^nesting level. That information > > should be coming from the cfg which comes from

Creating a partial mirror of the repository with SVK

I've read the wiki page that explains how to mirror GCC's repository using SVK, and I would like to pick up just the parts I need so I can keep the size of the mirror below 4 Gb due to limited disk space. Specifically, I need just a few branches: gcc_3_4_branch, gcc_4_0_branch, gcc_4_1_branch, and

Re: [RFC] fixproto and canadian cross builds

Paul Brook wrote: > This suggests two options on what's supposed to happen: > (a) fix-header should actually be compiled for the "host" environment. If > host==build we run it, otherwise we just install it and let the user run it > on the build system. I think this is the right option, though,

Re: Build using --with-gmp and shared libraries

>>> Testing done on i686-linux (built with --languages=c,fortran and >>> a shared libgmp in /foo/bar, and regtested). >>> OK for mainline? OK for 4.0? ping**3, build machinery maintainers in Cc. This patch makes --with-gmp and --with-mpfr similar to --with-as and others, where you don't need to h

Re: SVN conversion glitch?

Jakub Jelinek <[EMAIL PROTECTED]> writes: > While doing svn diff, I've noticed > gcc/config/i386/xm-dgux.h > gcc/config/i386/xm-sysv3.h > gcc/config/i386/xm-sun.h > gcc/config/i386/scodbx.h > files popped out of nowhere on the trunk (and through > 4.1 branching also on gcc-4_1-branch). > The files

Re: [RFC] fixproto and canadian cross builds

Mark Mitchell <[EMAIL PROTECTED]> writes: > Hmm. A lot of the *-elf targets have use_fixproto=yes in config.gcc, > which somewhat surpises me; I'd have thought newlib didn't require that. Nathanael changed the default here: 2003-09-30 Nathanael Nerode <[EMAIL PROTECTED]> * config.gcc

Re: [RFC] fixproto and canadian cross builds

Ian Lance Taylor wrote: > So the question is why, before his change, those *-elf targets didn't > have an explicit fixproto=no, and I'm sure the answer is simply > laziness and/or lack of knowledge. fixproto is more or less a no-op > when run on modern header files, so it's not like anybody would

Default arguments and FUNCTION_TYPEs

Hi, In the C++ front end, default arguments are recorded in FUNCTION_TYPEs intead of being part of the FUNCTION_DECLs. What are the reasons for that? -- Gaby

Re: Default arguments and FUNCTION_TYPEs

Gabriel Dos Reis wrote: > Hi, > > In the C++ front end, default arguments are recorded in > FUNCTION_TYPEs intead of being part of the FUNCTION_DECLs. What are > the reasons for that? There used to be an extension that allowed default arguments on function pointer types. We agreed to kill it,

overcoming info build failures

I tracked this build problem of mine down. I expect others will experience it, too, hence this posting. If you're building from clean, you won't have this problem. Mark Mitchell's @file documentation change adds a @set directive to gcc-vers.texi in the build directory, but that file only depends

Re: overcoming info build failures

Ben Elliston wrote: > I tracked this build problem of mine down. I expect others will > experience it, too, hence this posting. If you're building from > clean, you won't have this problem. Sorry about that! -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304

Re: Default arguments and FUNCTION_TYPEs

Mark Mitchell <[EMAIL PROTECTED]> writes: | Gabriel Dos Reis wrote: | > Hi, | > | > In the C++ front end, default arguments are recorded in | > FUNCTION_TYPEs intead of being part of the FUNCTION_DECLs. What are | > the reasons for that? | | There used to be an extension that allowed default

Re: Default arguments and FUNCTION_TYPEs

Gabriel Dos Reis wrote: > Assuming the extension was gone, do you see a reason we not move the > default arguments to FUNCTION_DECLs and have FUNCTION_TYPEs use > TREE_VEC instead of TREE_LIST to hold the parameter-type list? Both things sound OK to me. -- Mark Mitchell CodeSourcery, LLC [EMAIL

Re: overcoming info build failures

On Thu, Nov 24, 2005 at 11:56:32AM +1100, Ben Elliston wrote: > I tracked this build problem of mine down. I expect others will > experience it, too, hence this posting. If you're building from > clean, you won't have this problem. > > Mark Mitchell's @file documentation change adds a @set direc

Successfull build & install of gcc-4.0.2 on MacOS-X 10.3.9-520.19

Hi all, on PowerPC G4 with MacOS-X 10.3.9 (powerpc-apple-darwin7.9.0 ) build from : Reading specs from /usr/libexec/gcc/darwin/ppc/3.3/specs Thread model: posix gcc version 3.3 20040913 (GNAT for Mac OS X build 1650) with Apple's cctools 590.12 New 4.0.2 gcc -v output : Using built-in specs.

__thread and builtin memcpy() bug

filed as $ cat bug.c #include /* memcpy() */ static #ifdef SHOWBUG __thread #endif int foo[2]; void bug(void) { int bar; (void) memcpy(&foo[0], &bar, sizeof(bar)); #ifdef SHOWBUG (void) memcpy(&foo[1], &bar, sizeof(bar)); #e

Re: Default arguments and FUNCTION_TYPEs

Mark Mitchell wrote: Gabriel Dos Reis wrote: Hi, In the C++ front end, default arguments are recorded in FUNCTION_TYPEs intead of being part of the FUNCTION_DECLs. What are the reasons for that? There used to be an extension that allowed default arguments on function pointer types. We ag

Re: Default arguments and FUNCTION_TYPEs

Gabriel Dos Reis wrote: Assuming the extension was gone, do you see a reason we not move the default arguments to FUNCTION_DECLs and have FUNCTION_TYPEs use TREE_VEC instead of TREE_LIST to hold the parameter-type list? you could probably use a VEC(tree), which I think would be even better :)