Re: Fixed-Point Arithmetic Project

> We are working on a project to add fixed-point arithmetic support to GCC. > A GCC project description page is available here > http://gcc.gnu.org/wiki/FixedPointArithmetic > and we will create a GCC branch in the near future. If you have > any suggestions or comments, please respond. I expect

Re: Fixed-Point Arithmetic Project

> > We are working on a project to add fixed-point arithmetic support to GCC. > > A GCC project description page is available here > > http://gcc.gnu.org/wiki/FixedPointArithmetic > > and we will create a GCC branch in the near future. If you have > > any suggestions or comments, please respond.

Re: -ftree-vectorize can't vectorize plus?

On 9/21/06, Andrew Pinski <[EMAIL PROTECTED]> wrote: > > Hi, > > On 9/16/06, Dorit Nuzman <[EMAIL PROTECTED]> wrote: . > > >so the stuff in tree-ssa-forwprop:eliminate_unnecessary_casts in > > autovect-branch is supposed to go under this tree-combiner pass as well, or > >do you plan to merge it

Re: Fixed-Point Arithmetic Project

On Friday 22 September 2006 09:38, Arnaud Charlet wrote: > > > We are working on a project to add fixed-point arithmetic support to GCC. > > > A GCC project description page is available here > > > http://gcc.gnu.org/wiki/FixedPointArithmetic > > > and we will create a GCC branch in the near futur

Re: Upgrading a cross compiler from GCC 3.4.6 to 4.1.1

Rohit Arul Raj wrote: I am upgrading a cross-compiler from gcc3.4.6 to gcc 4.1.1. i am getting some errors while trying to build the compiler. The way in which i am building the compiler is : $configure --target= --prefix=/usr/crossgcc/ --with-newlib --disable-libssp "--target=" "Let's

Re: Fixed-Point Arithmetic Project

On Fri, 2006-09-22 at 10:09 +0200, Duncan Sands wrote: > I mean that no use is made of special hardware support. This is in > analogy to "floating point emulation", for processors with no fp support. IIRC, hardware integer overflow support access from the code generator would be useful too for Ad

Re: Verifier for sub-variables vs mem-ssa

The problem starts when the operand scanner in mem-ssa determines that since neither u[1] nor u[2] have corresponding SFTs, they get to use 'u' directly. This is different from mainline. In mainline we use SFT.0 for all of them: foo () { short unsigned int u[1]; # SFT.0_2 = V_MUST_DE

Re: GCC 4.3 Platform List

On Thu, Sep 21, 2006 at 02:52:43PM -0700, Michel Lespinasse wrote: > I'm not familiar with the kind of testing you guys usualy do on simulators - > however since this is the second time it's mentionned I should say that > mipsel binaries run just fine in the gxemul simulator. > > I've recently don

Re: Verifier for sub-variables vs mem-ssa

Daniel Berlin wrote on 09/22/06 08:44: > Sure. If you want to make the verifier trigger less on undefined code > because you are optimizing it better, feel free! > OK, thanks. I don't know 'optimizing better', for now it's just 'different'. > Just be careful you don't get tricked by the pointer

Explicit field layout

Hello, I am writing a new GCC front end. One of the features provided by my language (CIL) is explicit field layout and size for records. I don't know if any other languaje supported by GCC provides this feature. If that's the case, please point me to it so that I can see how to do i

Re: cast to pointer from integer of different size

Peter, Looking at the libffi/src/powerpc/ffi.c file, I assume that I should have the same... *next_arg++ = (unsigned long)(char *)ecif->rvalue; in ffi_darwin.c instead of the current... *next_arg++ = (unsigned)(char *)ecif->rvalue; Does that sound right? If so, I'll file a PR for this

Re: cast to pointer from integer of different size

On Fri, 2006-09-22 at 09:33 -0400, Jack Howarth wrote: > Peter, > Looking at the libffi/src/powerpc/ffi.c file, I assume that > I should have the same... > >*next_arg++ = (unsigned long)(char *)ecif->rvalue; > > in ffi_darwin.c instead of the current... > >*next_arg++ = (unsigned)(ch

Re: Explicit field layout

> I am writing a new GCC front end. One of the features provided by my > language (CIL) is explicit field layout and size for records. > > I don't know if any other languaje supported by GCC provides this > feature. If that's the case, please point me to it so that I can see how > to

Re: cast to pointer from integer of different size

Peter, Okay so what we need is... Index: ffi_darwin.c === --- ffi_darwin.c(revision 117142) +++ ffi_darwin.c(working copy) @@ -94,7 +94,7 @@ /* 'next_arg' grows up as we put parameters in it. */ - unsigned

Re: cast to pointer from integer of different size

Peter, I should have added that when I last tested libffi at -m64 on Darwin PPC and saw roughly half of the tests fail... http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29152 ...it seemed that the failures were all in the dg-output tests. Hopefully this fix will have some positive results in the

Re: cast to pointer from integer of different size

On Fri, 2006-09-22 at 08:53 -0500, Peter Bergner wrote: > On Fri, 2006-09-22 at 09:33 -0400, Jack Howarth wrote: > > Peter, > > Looking at the libffi/src/powerpc/ffi.c file, I assume that > > I should have the same... > > > >*next_arg++ = (unsigned long)(char *)ecif->rvalue; > > > > in ff

Re: cast to pointer from integer of different size

[EMAIL PROTECTED] (Jack Howarth) writes: > Looking at the libffi/src/powerpc/ffi.c file, I assume that > I should have the same... > >*next_arg++ = (unsigned long)(char *)ecif->rvalue; Sure looks like you want uintptr_t there. I think using "unsigned long" is just setting yourself up fo

RE: cast to pointer from integer of different size

On 22 September 2006 16:01, Ian Lance Taylor wrote: > [EMAIL PROTECTED] (Jack Howarth) writes: > >> Looking at the libffi/src/powerpc/ffi.c file, I assume that I should >> have the same... >> >>*next_arg++ = (unsigned long)(char *)ecif->rvalue; > > Sure looks like you want uintptr_t th

Re: Explicit field layout

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, Sep 22, 2006 at 02:58:26PM +0200, Ricardo FERNANDEZ PASCUAL wrote: >I am writing a new GCC front end. One of the features provided by my > language (CIL) is explicit field layout and size for records. >Any pointers would be greatly ap

Re: cast to pointer from integer of different size

On Friday 22 September 2006 16:56, Dave Korn wrote: > On 22 September 2006 16:01, Ian Lance Taylor wrote: > > [EMAIL PROTECTED] (Jack Howarth) writes: > >> Looking at the libffi/src/powerpc/ffi.c file, I assume that I should > >> have the same... > >> > >>*next_arg++ = (unsigned long)(char

RE: cast to pointer from integer of different size

On 22 September 2006 17:45, Paul Brook wrote: > On Friday 22 September 2006 16:56, Dave Korn wrote: >> On 22 September 2006 16:01, Ian Lance Taylor wrote: >>> [EMAIL PROTECTED] (Jack Howarth) writes: Looking at the libffi/src/powerpc/ffi.c file, I assume that I should have the same..

Re: GCC 4.3 Platform List

I wrote: > [A]utomatic reports for [*-*-freebsd] came in daily, > almost-like-clockwork from mid-2002 until October 26, 2005. It > appears that I never updated the population of freebsd.org machines > to synchronize against the SVN repository rather than CVS... Oops! > [...] I will attempt to re

Darwin as primary platform

Hi Mark, On Darwin, the most common form of development is to compile the same sources to target both powerpc-darwin and i386-darwin simultaneously. It therefore seems unnatural to make a distinction between the two. This also makes the

Re: Darwin as primary platform

Geoff, How would the powerpc-darwin -m64 support and x86_64 fit into this scheme? Would they be considered variants of the powerpc-darwin and i386-darwin architectures and thus primary platforms as well? Or would they be secondary platforms? With Apple's 64-bit commitment in Leopard, they shoul

Re: Darwin as primary platform

On 22/09/2006, at 1:54 PM, Jack Howarth wrote: Geoff, How would the powerpc-darwin -m64 support and x86_64 fit into this scheme? Would they be considered variants of the powerpc-darwin and i386-darwin architectures and thus primary platforms as well? Or would they be secondary platforms? Wi

gcc-4.1-20060922 is now available

Snapshot gcc-4.1-20060922 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20060922/ 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

simple pthread consumes memory

Hi - I start a simple pthread and the program consumes about 10 Mbytes of virtual memory. If I start 10 threads, it consumes 100 Mbytes. I don't know why this is happening to me. I tried it on two Debian and a 64 bit Ubuntu machines and the same thing happened to me. Thanks in advance for any help

Re: simple pthread consumes memory

On Sep 22, 2006, at 3:51 PM, balazs wrote: Hi - I start a simple pthread and the program consumes about 10 Mbytes of virtual memory. And why do you think that sending email to this list would be a good idea? View this message in context: http://www.nabble.com/simple-pthread- consumes-mem

Re: simple pthread consumes memory

balazs wrote: > Hi - I start a simple pthread and the program consumes about 10 Mbytes of > virtual memory. If I start 10 threads, it consumes 100 Mbytes. That's off topic, but the answer is that the default stack size for a thread on your machine seems to be 10M. If you know you don't need such

Re: Darwin as primary platform

Right now, it seems that one may not be able to build a 64-bit version of the compiler itself, on either either x86-64 or ppc64, see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28994 I notice that because some of my (automatically generated) C programs, with certain compiler options, require

Re: Darwin as primary platform

Bradley Lucier wrote: Right now, it seems that one may not be able to build a 64-bit version of the compiler itself, on either either x86-64 or ppc64, see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28994 I notice that because some of my (automatically generated) C programs, with certain comp

Re: Verifier for sub-variables vs mem-ssa

> Well, sure. We don't create subvariables here. Right now. I'm just saying you might want to make sure your code won't break when we do. Otherwise, i'll be forced to injure you severely :)