Re: Fixed-Point Arithmetic Project

[Duncan Sands]

> 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 the Ada front-end people will be interested: the Ada language
incorporates binary and decimal fixed point types.  AFAIK, it is all
done using emulation at the moment.

Best wishes,

Duncan.

Re: Fixed-Point Arithmetic Project

[Arnaud Charlet]

> > 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 the Ada front-end people will be interested: the Ada language
> incorporates binary and decimal fixed point types.  AFAIK, it is all
> done using emulation at the moment.

Not sure what you mean by "emulation". The implementation provided in
GNAT is indeed a full implementation of Ada fixed point semantics.

It can probably be used either as a reference implementation, or as a base for
comparison (e.g. correctness comparison).

Arno

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

[Richard Guenther]

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 to mainline some time?
>
>
> tree-ssa-forwprop:eliminate_unncessary_casts approach is
> considered not appropriate for mainline (because
> tree-combiner will take care of it.) so I do not plan to merge
> it to mainline. I discussed this with tree-ssa folks when we
> were chasing gzip performance. They preferred to wait for
> tree-combiner instead of gaining gzip performance improvement
> using this short term approach.

The Tree combiner is semi dead as I have other work to do now.  But I hear
PRE is able to do some stuff like this (and already does for some simple 
testcases).


Yes, we should be able to catch more of these at the point the new
VN code will go in.

Richard.

Re: Fixed-Point Arithmetic Project

[Duncan Sands]

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 future. If you have 
> > > any suggestions or comments, please respond.
> > 
> > I expect the Ada front-end people will be interested: the Ada language
> > incorporates binary and decimal fixed point types.  AFAIK, it is all
> > done using emulation at the moment.
> 
> Not sure what you mean by "emulation". The implementation provided in
> GNAT is indeed a full implementation of Ada fixed point semantics.

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.

> It can probably be used either as a reference implementation, or as a base for
> comparison (e.g. correctness comparison).

Best wishes,

Duncan.

Re: Upgrading a cross compiler from GCC 3.4.6 to 4.1.1

[Kai Ruottu]

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 the HAL read one's thoughts or what?


fp-bit.c: In function '__extendsfdf2':
fp-bit.c:1513: internal compiler error: in emit_push_insn, at expr.c:3722


It is interesting that the GCC build went this far without knowing what on
earth the $target should be

is there a way out of this?
is the internal compiler error generated due to gcc_assert?


This "building a crosscompiler without defining the $target" must be some
"rocket science" which I haven't yet seen after producing more than 1000
crosscompilers...  I apologize my ignorance but could someone explain what
on earth this kind of configuration should produce?  A "crosscompiler 
for the

native target" or what?

Re: Fixed-Point Arithmetic Project

[Laurent GUERBY]

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 Ada (currently checks are expensive so enabled
only by the -gnato flag and done by the front end).

Laurent

Re: Verifier for sub-variables vs mem-ssa

[Daniel Berlin]

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_DEF ;
  u[0] = 1;

  #   SFT.0_3 = V_MUST_DEF ;
  u[0] = 0;

  #   SFT.0_4 = V_MAY_DEF ;
  u[1] = 1;

  #   SFT.0_5 = V_MAY_DEF ;
  u[2] = 2;

  [ ... ]
}

Which does not trigger the validation error, but I believe it's less precise
than what is computed in mem-ssa.  Certainly u[1] and u[2] cannot affect u[0].
Nor can they affect each other, but this is undefined code, so it's not such a
big deal.

The verifier is being tricked because it uses a fairly simple test:

  if (is_virtual && var_ann (SSA_NAME_VAR (ssa_name))
  && get_subvars_for_var (SSA_NAME_VAR (ssa_name)) != NULL)
{
  error ("found real variable when subvariables should have appeared");


I'm meaning to change the verifier to check if the statement is really
referencing a sub-variable, but first I wanted to check if the idea
makes sense.



Sure. If you want to make the verifier trigger less on undefined code
because you are optimizing it better, feel free!

Just be careful you don't get tricked by the pointer version of the above.

struct foo {
int a[1];
};

struct foo *b = malloc(sizeof(foo) + 30 ints)
b->a[24] = 9;

We guarantee this will work.

--Dan

Re: GCC 4.3 Platform List

[Daniel Jacobowitz]

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 done a whole debian etch installation that way -
> see http://zoy.org/~walken/gxemul-etch/HOWTO.html for the instructions.

FYI, we've done both ARM and MIPS testing using qemu, both in user
emulation mode - where it's a fairly drop-in replacement for the
gdb simulators - and in system mode.  However, it doesn't really
make up for testing on hardware.  Not unless someone donates a
lot of time to run good hardware certification tests on it, anyway :-)

-- 
Daniel Jacobowitz
CodeSourcery

Re: Verifier for sub-variables vs mem-ssa

[Diego Novillo]

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 version of the above.
> 
> struct foo {
> int a[1];
> };
> 
> struct foo *b = malloc(sizeof(foo) + 30 ints)
> b->a[24] = 9;
> 
Well, sure.  We don't create subvariables here.

Explicit field layout

[Ricardo FERNANDEZ PASCUAL]

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 it.


   For the case of explicit record size, what I am doing currently is 
modifying the TYPE_SIZE() of the declaration after the call to 
layout_type. It seems to work, but I am not sure if this is the correct 
way to do this.


   As for setting the explicit field offset, I haven't tried to do it 
yet. Would it be enough to set the DECL_FIELD_OFFSET and 
DECL_FIELD_BIT_OFFSET fields of each field declaration manually? When 
should it be done (after calling layout_type or before)?


   Any pointers would be greatly appreciated.


Thank you in advance,
Ricardo Fernández Pascual.

Re: cast to pointer from integer of different size

[Jack Howarth]

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
as well and do a test build tonight.
  Jack

Re: cast to pointer from integer of different size

[Peter Bergner]

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)(char *)ecif->rvalue;
> 
> Does that sound right? If so, I'll file a PR for this
> as well and do a test build tonight.

That in itself isn't sufficient, since next_arg is defined as
an unsigned * pointer.  That would also need to be changed to
unsigned long *next_arg.

Peter

Re: Explicit field layout

[Duncan Sands]

> 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 it.

Ada provides this.  See for example section 13.5 of the reference manual
(http://www.adaic.com/standards/index.html).

Best wishes,

Duncan.

Re: cast to pointer from integer of different size

[Jack Howarth]

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 *next_arg = stack + 6; /* 6 reserved positions.  */
+  unsigned long *next_arg = stack + 6; /* 6 reserved positions.  */
 
   int i = ecif->cif->nargs;
   double double_tmp;
@@ -114,7 +114,7 @@
  Return values are referenced by r3, so r4 is the first parameter.  */
 
   if (flags & FLAG_RETVAL_REFERENCE)
-*next_arg++ = (unsigned)(char *)ecif->rvalue;
+*next_arg++ = (unsigned long)(char *)ecif->rvalue;
 
   /* Now for the arguments.  */
   for (;

I'll test that tonight. I've opened this up as PR29181.
 Jack

Re: cast to pointer from integer of different size

[Jack Howarth]

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 libffi testsuite.
Jack

Re: cast to pointer from integer of different size

[Peter Bergner]

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 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
> > as well and do a test build tonight.
> 
> That in itself isn't sufficient, since next_arg is defined as
> an unsigned * pointer.  That would also need to be changed to
> unsigned long *next_arg.

Doing a quick glance through the file, there are a number of other
potential pointer truncations going on that should be looked into:

Probably should be unsigned long *:

  /* 'stacktop' points at the previous backchain pointer.  */
  unsigned *const stacktop = stack + (bytes / sizeof(unsigned));

Probably should be (unsigned long):

  FFI_ASSERT(((unsigned)(char *)stack & 0xF) == 0);
  FFI_ASSERT(((unsigned)(char *)stacktop & 0xF) == 0);

Without knowing the code (ie, is FFI_TYPE_POINTER 8 bytes?),
you may need to change this to (*unsigned long *)*p_argv
and change gprvalue to unsigned long.

case FFI_TYPE_INT:
case FFI_TYPE_UINT32:
case FFI_TYPE_SINT32:
case FFI_TYPE_POINTER:
  gprvalue = *(unsigned *)*p_argv;

I said "potential" pointer truncations above, because I haven't spent
the time to determine what the code is actually trying to do or what
the range of input values are.  It maybe that the above is harmless,
but someone should verify that.

Peter

Re: cast to pointer from integer of different size

[Ian Lance Taylor]

[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 for failure on some future system.

Ian

RE: cast to pointer from integer of different size

[Dave Korn]

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 there.  I think using "unsigned
> long" is just setting yourself up for failure on some future system.


  64 bits ought to be enough for anybody!  


  ;-)

cheers,
  DaveK
-- 
Can't think of a witty .sigline today

Re: Explicit field layout

[Bernd Jendrissek]

-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 appreciated.

Are you sure you want to do that, instead of using, say, rpcgen?
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.4 (GNU/Linux)
Comment: Please fetch my new key 804177F8 from hkp://wwwkeys.eu.pgp.net/

iD8DBQFFFBHFwyMv24BBd/gRAg35AJ9bdnEbyIpKWgsoaKrA1UBPO3k6xwCfbie9
PAmhpGYxarzLBaCdEldudZo=
=o4kk
-END PGP SIGNATURE-

Re: cast to pointer from integer of different size

[Paul Brook]

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 *)ecif->rvalue;
> >
> > Sure looks like you want uintptr_t there.  I think using "unsigned
> > long" is just setting yourself up for failure on some future system.
>
>   64 bits ought to be enough for anybody!  

I think Ian means there are stupid, broken systems where long is smaller than 
a pointer (64-bit windows anyone?).

Paul

RE: cast to pointer from integer of different size

[Dave Korn]

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... 
 
*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 for failure on some future system.
>> 
>>   64 bits ought to be enough for anybody!  
> 
> I think Ian means there are stupid, broken systems where long is smaller
> than a pointer (64-bit windows anyone?).

  Well, yeh.  LLP64 exists.  Then again, 64 bits *isn't* going to be enough
for everybody for all time either.  :)  It's Friday afternoon, and it's just
gone five past beer o'clock, you weren't expecting a sensible comment from me
were you ??!?

  Have a good weekend everyone, I'm out of here.  Jack, FWIW I totally agree
with Ian (when I'm being serious), uintptr_t is the right thing to use because
it's defined as an integer of whatever size is big enough to contain any
pointer on the target system, and is therefore guaranteed to work and be
correct everywhere and forever; it's made-for-purpose to the job.

cheers,
  DaveK
-- 
Can't think of a witty .sigline today

Re: GCC 4.3 Platform List

[Loren James Rittle]

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 restart automatic daily reporting.

Daily reports from FreeBSD machines should be flowing once again.

Regards,
Loren

Darwin as primary platform

[Geoffrey Keating]

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 Darwin targets, by far, the  
most popular hosted targets which are routinely used by cross- 
compilation.


I think that powerpc-darwin has met the criteria for being a primary  
platform for the last several major releases, and this should  
continue through the 4.3 release.  I expect that for the 4.3 release  
i386-darwin will also achieve this level of quality.


I discussed this with my management and we agreed that we would  
recommend that powerpc-darwin together with i386-darwin be a primary  
platform for the 4.3 release.




smime.p7s
Description: S/MIME cryptographic signature

Re: Darwin as primary platform

[Jack Howarth]

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 should at least be secondary with an eye to making
them primary in gcc 4.4.
Jack 

Re: Darwin as primary platform

[Geoffrey Keating]

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? With Apple's 64-bit commitment
in Leopard, they should at least be secondary with an eye to making
them primary in gcc 4.4.


They are not platforms at all; they are command-line flags.  They  
would be treated the same way as any similar command-line flag on a  
primary platform, say -m64 on AIX.  The importance of any problem  
with them would be determined based on things like how much code is  
affected, the impact on users, the dangerousness of the fix, etc.


I caution that Apple has made no firm commitment to 64-bit GUI  
support, or any other feature, in Leopard.  As the small grey print  
at the bottom of   
says, "All features referenced in the Mac OS X Leopard Sneak Peek are  
subject to change."


From a tools perspective, the additional 64-bit support in Leopard  
mostly translates to 64-bit support in objective-C and objective-C++,  
and there doesn't seem to be any especial problem with this even in 4.2.

smime.p7s
Description: S/MIME cryptographic signature

gcc-4.1-20060922 is now available

[gccadmin]

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/gcc-4_1-branch 
revision 117153

You'll find:

gcc-4.1-20060922.tar.bz2  Complete GCC (includes all of below)

gcc-core-4.1-20060922.tar.bz2 C front end and core compiler

gcc-ada-4.1-20060922.tar.bz2  Ada front end and runtime

gcc-fortran-4.1-20060922.tar.bz2  Fortran front end and runtime

gcc-g++-4.1-20060922.tar.bz2  C++ front end and runtime

gcc-java-4.1-20060922.tar.bz2 Java front end and runtime

gcc-objc-4.1-20060922.tar.bz2 Objective-C front end and runtime

gcc-testsuite-4.1-20060922.tar.bz2The GCC testsuite

Diffs from 4.1-20060915 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.1
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

simple pthread consumes memory

[balazs]

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.

Balazs


I compile by:g++ -lpthread main.cpp

#include 

void* myfunction( void* ptr ) {
int sum = 0;
for( int i = 0; i < 20; i++ )
sum *= i;
}

int main( int argc, char* argv[] ) {
pthread_t mythread;

pthread_create( &mythread, 0, &myfunction, NULL );
pthread_join( mythread, NULL );
}

-- 
View this message in context: 
http://www.nabble.com/simple-pthread-consumes-memory-tf2320485.html#a6456330
Sent from the gcc - Dev mailing list archive at Nabble.com.

Re: simple pthread consumes memory

[Mike Stump]

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-memory-tf2320485.html#a6456330

Sent from the gcc - Dev mailing list archive at Nabble.com.


Maybe nabble should have post moderation.

Re: simple pthread consumes memory

[Lothar Werzinger]

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 a large
stack, you can specify a custom stack size when creating the thread.

Re: Darwin as primary platform

[Bradley Lucier]

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 more memory than a  
32-bit compiler provides.


Just a comment.

Brad

Re: Darwin as primary platform

[Eric Christopher]

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 compiler options, require more memory than a 32-bit 
compiler provides.


Just a comment.



You may or may not have noticed that there are no 64-bit native targets 
for darwin.


-eric

Re: Verifier for sub-variables vs mem-ssa

[Daniel Berlin]

>
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 :)