Re: GCC 4.3.0 Status Report (2008-02-14)

[Manuel López-Ibáñez]

On 15/02/2008, Ralf Corsepius <[EMAIL PROTECTED]> wrote:
>
>  On Thu, 2008-02-14 at 22:17 +, Joseph S. Myers wrote:
>  > On Thu, 14 Feb 2008, Joel Sherrill wrote:
>
>  > > The m68k/coldfire is suffering from this regression the
>  > > RTEMS community really would like to see resolved.
>  > >
>  > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35088
>  >
>  > Please try this patch; I've had it around for a while for what looks like
>  > a similar problem on m68k-uclinux but haven't got round to doing the
>  > necessary regression testing (and didn't know the bug in question was a
>  > regression, or have a reduced testcase).  (Is it a regression?  That bug
>  > isn't marked as such, and only regression fixes are going on trunk at
>  > present.)
>
>  Well, what to consider to be a regression is a matter of POV. :)

Don't think so. A regression is something that used to work and not it
doesn't. You only have to give the version where it worked and the
version where it started failing.

That bug is not marked as a regression probably because no relevant
maintainer has looked at it. Whether the relevant maintainers missed
it or they don't have time to deal with it, that I ignore.

Cheers,

Manuel.

Re: GCC 4.3.0 Status Report (2008-02-14)

[Joseph S. Myers]

On Fri, 15 Feb 2008, Ralf Corsepius wrote:

> > 2007-09-26  Joseph Myers  <[EMAIL PROTECTED]>
> > 
> > * config/m68k/m68k.h (DWARF_CIE_DATA_ALIGNMENT): Define.
> > 
> > Index: gcc/config/m68k/m68k.h
> > ===
> > --- gcc/config/m68k/m68k.h
> > +++ gcc/config/m68k/m68k.h
> > @@ -317,6 +317,8 @@
> >  #define STRICT_ALIGNMENT (TARGET_STRICT_ALIGNMENT)
> >  #define M68K_HONOR_TARGET_STRICT_ALIGNMENT 1
> >  
> > +#define DWARF_CIE_DATA_ALIGNMENT -2
> > +
> >  #define INT_TYPE_SIZE (TARGET_SHORT ? 16 : 32)
> >  
> >  /* Define these to avoid dependence on meaning of `int'.  */
> > 
> 
> Thanks for the patch, I don't know if it does the "right thing(tm)", 
> but it at least lets building rtems succeed, i.e. it seems to solve
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35088)

In that case, OK to commit to trunk?

(The patch rationale is that 4-byte stack alignment is not always 
guaranteed on m68k/ColdFire, only 2-byte.)

-- 
Joseph S. Myers
[EMAIL PROTECTED]

Re: GCC 4.3.0 Status Report (2008-02-14)

[Andreas Schwab]

"Joseph S. Myers" <[EMAIL PROTECTED]> writes:

> On Fri, 15 Feb 2008, Ralf Corsepius wrote:
>
>> > 2007-09-26  Joseph Myers  <[EMAIL PROTECTED]>
>> > 
>> >* config/m68k/m68k.h (DWARF_CIE_DATA_ALIGNMENT): Define.
>> > 
>> > Index: gcc/config/m68k/m68k.h
>> > ===
>> > --- gcc/config/m68k/m68k.h
>> > +++ gcc/config/m68k/m68k.h
>> > @@ -317,6 +317,8 @@
>> >  #define STRICT_ALIGNMENT (TARGET_STRICT_ALIGNMENT)
>> >  #define M68K_HONOR_TARGET_STRICT_ALIGNMENT 1
>> >  
>> > +#define DWARF_CIE_DATA_ALIGNMENT -2
>> > +
>> >  #define INT_TYPE_SIZE (TARGET_SHORT ? 16 : 32)
>> >  
>> >  /* Define these to avoid dependence on meaning of `int'.  */
>> > 
>> 
>> Thanks for the patch, I don't know if it does the "right thing(tm)", 
>> but it at least lets building rtems succeed, i.e. it seems to solve
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35088)
>
> In that case, OK to commit to trunk?

Yes, this is ok.

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: lto

[Vladimir N. Makarov]

Jan Hubicka wrote:


I have to admit that i had not considered the issue of having the later
stages of compilation of one function feed into the early stages of
another.   The problem with this is that it implies a serial ordering of
the compilation and that is not going to yield a usable system for
compiling very large programs. 
   



Yes, this is why I wanted to bring this in.  I am not expert for whole
program register allocation, but my understanding is that it can really
help, especially on machine like x86-64, where saving
prologues/epilogues are relatively expensive.  It seems to me that it
can't scale to really big programs, but it don't have to if we subdivide
the programs sanely (ie do equivalent of region based compilation for
large function).   As long as the calls crossing boundaries are not very
frequent, we should be all happy.

Vladimir, Andrew, I am sure you know a lot more about global RA.
Is it resonable to expect that RA needs to propagate things just down in
topological order and can we split the program to resonably sized chunks
where the RA can be handled locally?

 

IP RA as currenly implemented in IRA does propagate info only down in 
topological order.  But a good IP RA (e.g. Minimal cost inter-procedural 
regiter allocator http://citeseer.ist.psu.edu/kurlander96minimum.html) 
needs to propagate info up and down.


But I am quite skeptical about IP RA.  To be sucessfull it needs that 
the called function is small and uses few registers.  Such functions 
should be just inlined.  It solves IP RA besides other problems.  
Intel/Sun/Pathscale compilers make very aggressive function inlining 
during LTO.  Therefore the code generated by the compilers with LTO is 
much bigger (e.g. LTO in pathscale results in 30% bigger code for x86_64 
SPECINT2000 and by the way improves the code by 4% and makes the 
compiler 50% slower).


In overall I don't think that IP RA is important thing and worth to be 
implemented.

Re: lto

[Diego Novillo]

On 2/14/08 12:46 PM, Kenneth Zadeck wrote:


Comments?


Your idea seems fine to me.  Unless I'm not understanding you 
completely, it does not really conflict with what we're trying to do in 
whopr.


The main goal of whopr is to support transformations that can be 
expressed in terms of a local generation phase, a global analysis that 
decides an optimization plan and then a final transformation phase that 
applies that plan.


The first and last steps are meant to run in parallel.  The distribution 
of tasks can be done outside of the compiler (ideally, via 'make -j' or 
distcc or what have you).


Certainly, not every IPA transformation can fit this plan, anything that 
needs iterating or has cascading effects may not apply.  But for the 
main IPA transformations (notably inlining), this structure produces 
good results.  If I understand Jan correctly, this is what he means by 
'Big IPA' in his last message.


So, if you build the mechanisms to read/write LTO information from 
files, and the ability to load things on demand, that's great.  We do 
not need to arrive to the final solution in one step, incremental little 
victories are a lot more important.  In fact, I very strongly suggest 
doing this incrementally.


The only thing that I'd like to watch out for is to keep the 
implementation flexible so that we don't need to re-implement many 
things from scratch when we are ready to extend the system.



Thanks.  Diego.

Re: lto

[Jan Hubicka]

> Your idea seems fine to me.  Unless I'm not understanding you 
> completely, it does not really conflict with what we're trying to do in 
> whopr.
> 
> The main goal of whopr is to support transformations that can be 
> expressed in terms of a local generation phase, a global analysis that 
> decides an optimization plan and then a final transformation phase that 
> applies that plan.
> 
> The first and last steps are meant to run in parallel.  The distribution 
> of tasks can be done outside of the compiler (ideally, via 'make -j' or 
> distcc or what have you).
> 
> Certainly, not every IPA transformation can fit this plan, anything that 
> needs iterating or has cascading effects may not apply.  But for the 
> main IPA transformations (notably inlining), this structure produces 
> good results.  If I understand Jan correctly, this is what he means by 
> 'Big IPA' in his last message.

Yes, what I mant by Big ipa is precisely IPA organized by local
analysis/global execution and local modification passes as described in
whopr.  The original callgraph code was organized this way (it is
described in 2003 gccsummit paper) since I hoped at that time the IL
writting to be possible soon after tree-SSA merge and watned the code to
be ready for this.  The experience with this organization of IPA was
that while inlining/constant propagation and analysis fit well nicely,
some other cases didn't introducing pass ordering difficulties. This is
why I think combination of both approaches might lead to easier to
maintain and probably more effective IPA.

In general for good performance we want to push as much work as possible
into the compilation stage instead of linktime stage.  We will probably
want to do some of IPA optimization (mostly targetted to reduction of
code size) at that stage too, early inlining was one of cases
particularly meant for that.
> 
> So, if you build the mechanisms to read/write LTO information from 
> files, and the ability to load things on demand, that's great.  We do 
> not need to arrive to the final solution in one step, incremental little 
> victories are a lot more important.  In fact, I very strongly suggest 
> doing this incrementally.

Looks like all the possible scenarios have the first few things in
common: ie be able to read functions one by one from object files,
reorganize IPA passes to the three parts and be able to serialize the
summaries.

Honza
> 
> The only thing that I'd like to watch out for is to keep the 
> implementation flexible so that we don't need to re-implement many 
> things from scratch when we are ready to extend the system.
> 
> 
> Thanks.  Diego.

Re: lto

[Jan Hubicka]

> IP RA as currenly implemented in IRA does propagate info only down in 
> topological order.  But a good IP RA (e.g. Minimal cost inter-procedural 
> regiter allocator http://citeseer.ist.psu.edu/kurlander96minimum.html) 
> needs to propagate info up and down.
> 
> But I am quite skeptical about IP RA.  To be sucessfull it needs that 
> the called function is small and uses few registers.  Such functions 
> should be just inlined.  It solves IP RA besides other problems.  
> Intel/Sun/Pathscale compilers make very aggressive function inlining 
> during LTO.  Therefore the code generated by the compilers with LTO is 
> much bigger (e.g. LTO in pathscale results in 30% bigger code for x86_64 
> SPECINT2000 and by the way improves the code by 4% and makes the 
> compiler 50% slower).

It seems to me that you can afford such a tradeoff if you are targetting
primarily CPU houngry software.  We need to handle the other cases (ie
system utilities or openoffice, say) where the code size is about major
bottleneck, so it seems to me that we don't want to make such an extreme
tradeoffs (though our current implementation of inliner heruistics will
do precisely that too)

Honza
> 
> In overall I don't think that IP RA is important thing and worth to be 
> implemented.

Re: lto

[Vladimir N. Makarov]

Jan Hubicka wrote:

IP RA as currenly implemented in IRA does propagate info only down in 
topological order.  But a good IP RA (e.g. Minimal cost inter-procedural 
regiter allocator http://citeseer.ist.psu.edu/kurlander96minimum.html) 
needs to propagate info up and down.


But I am quite skeptical about IP RA.  To be sucessfull it needs that 
the called function is small and uses few registers.  Such functions 
should be just inlined.  It solves IP RA besides other problems.  
Intel/Sun/Pathscale compilers make very aggressive function inlining 
during LTO.  Therefore the code generated by the compilers with LTO is 
much bigger (e.g. LTO in pathscale results in 30% bigger code for x86_64 
SPECINT2000 and by the way improves the code by 4% and makes the 
compiler 50% slower).
   



It seems to me that you can afford such a tradeoff if you are targetting
primarily CPU houngry software.  We need to handle the other cases (ie
system utilities or openoffice, say) where the code size is about major
bottleneck, so it seems to me that we don't want to make such an extreme
tradeoffs (though our current implementation of inliner heruistics will
do precisely that too)
 

I am agree with you.  We should not forget embedded market where the 
code size is more imortant but we should provide an option for  market 
on which  Pathscale/Intel/Sun compilers are oriented.


With this point of view, we have a lot of resources because gcc 
generates the smallest code.  E.g. In averages Intel compiler generates 
80% bigger code for SPECINT2000 with -O2 and 7 times bigger with -fast.  
It generates even bigger code with -Os (code size optimizations) than 
GCC for -O3.  The same is about the compilation speed.  GCC with -O3 is 
much faster (30%-40%) than all mentioned compilers in peak performance 
mode (-fast, -Ofast).  So I think we have some resouces which we could 
spend to improve the code performance for this market.

Problem with libiberty's hash tables

[FX]

Hi all,

I've started using libiberty's hashtab in libgfortran for some of my
gfortran work to track memory allocations in the library. I store
custom structures in a hash table, each structure containing a unique
pointer (it is a malloc'ed address) that is used for the hash. When I
traverse the table elements after having inserted a few, I get twice
the number I expect. It's probably a beginner's mistake, and will be
easy to spot, but I haven't managed to understand what I'm doing
wrong.

Here is a small, self-contained testcase of what I'm doing:

#include 
#include 
#include 
#include "hashtab.h"

static htab_t tab = NULL;

typedef struct
{
  void *p;
  const char *file;
} allocation_t;

static hashval_t hashval (const void *a)
{
  return htab_hash_pointer (a);
}

static int hasheq (const void *a, const void *b)
{
  return (((allocation_t *) a)->p == ((allocation_t *) b)->p);
}

static void do_nothing (void *a __attribute__((unused))) { ; }

void add_entry (const char *file)
{
  void *p = malloc (1);
  allocation_t *a;

  /* Register this allocation.  */
  a = (allocation_t *) htab_find_slot (tab, p, INSERT);
  a->p = p;
  a->file = file;

  printf ("Inserted at slot: %p\n", a);
}

static int
report_callback (void **slot, void *ptr __attribute__((unused)))
{
  printf ("Slot %p in file '%s'\n", slot, ((allocation_t *) slot)->file);
  return 1;
}

void
report ()
{
  printf ("Number of elements: %lu\n", (unsigned long) htab_elements (tab));
  htab_traverse_noresize (tab, report_callback, NULL);
  htab_delete (tab);
}

int main (void)
{
  tab = htab_create_alloc (128, hashval, hasheq, do_nothing, calloc, free);

  add_entry ("foo");
  add_entry ("bar");
  add_entry ("gee");
  report ();
  return 0;
}


So, I store three allocation_t structures in the table, each
containing a pointer and a pointer to a constant character string. At
the end, when traversing the hash table, the callback function is
called 6 times:

gcc hash.c -I ../../trunk/include/ -liberty -L lib64 -W -Wall && ./a.out
Inserted at slot: 0x503210
Inserted at slot: 0x503230
Inserted at slot: 0x503250
Number of elements: 3
Slot 0x503210 in file 'foo'
Slot 0x503218 in file '(null)'
Slot 0x503230 in file 'bar'
Slot 0x503238 in file '(null)'
Slot 0x503250 in file 'gee'
Slot 0x503258 in file '(null)'


I'd be glad if someone familiar with libiberty could give me a hint of
what's going wrong.

Thanks,
FX

-- 
FX Coudert
http://www.homepages.ucl.ac.uk/~uccafco/

Re: Problem with libiberty's hash tables

[FX]

Ouch... I got it, it indeed was a beginner mistake. Looking through
GCC to see how it used these hash tables, I noticed the problem. Sorry
for the noise!

PS: for posterity, the error was:

>   /* Register this allocation.  */
>   a = (allocation_t *) htab_find_slot (tab, p, INSERT);
>   a->p = p;
>   a->file = file;

This should have been:
  allocation_t **a;

  /* Register this allocation.  */
  a = (allocation_t **) htab_find_slot (tab, p, INSERT);
  *a = malloc (sizeof (allocation_t));
  (*a)->p = p;
  (*a)->file = file;

and later accordingly.

-- 
FX Coudert
http://www.homepages.ucl.ac.uk/~uccafco/

Re: GCC 4.3.0 Status Report (2008-02-14)

[Joel Sherrill]

Joseph S. Myers wrote:

On Thu, 14 Feb 2008, Joel Sherrill wrote:

  

Alexandre Pereira Nunes wrote:


Also regarding ARM, PR31849
(http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31849
) is a show stopper,
at least for some embedded bare metal targets, i.e. arm-elf and
arm-none-eabi.

Until size optimization at least matches gcc 4.2, gcc 4.3 will have very
limited audience there. I'm not aware of gcc internals in order to help
with a fix, but I'm available to help testing, should anyone requires that.


  

The m68k/coldfire is suffering from this regression the
RTEMS community really would like to see resolved.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35088



Please try this patch; I've had it around for a while for what looks like
a similar problem on m68k-uclinux but haven't got round to doing the
necessary regression testing (and didn't know the bug in question was a
regression, or have a reduced testcase).  (Is it a regression?  That bug
isn't marked as such, and only regression fixes are going on trunk at
present.)

  
First .. thanks. 


I'm sorry it wasn't marked as a regression  Ralf and I were just
trying to file all gcc issues we spotted building tools
and RTEMS using the CVS.  If you don't file them, they don't
get any attention.  In the future I will try to make
sure we always mark them as regressions.

FWIW we have RPMs for cross RTEMS RPMs back to the
gcc 3.2 days so it is pretty easy for anyone to check if
something on a cross is a regression.  Depending on the
RTEMS version, there are normally 10-12 targets available.

2007-09-26  Joseph Myers  <[EMAIL PROTECTED]>

* config/m68k/m68k.h (DWARF_CIE_DATA_ALIGNMENT): Define.

Index: gcc/config/m68k/m68k.h
===
--- gcc/config/m68k/m68k.h
+++ gcc/config/m68k/m68k.h
@@ -317,6 +317,8 @@
 #define STRICT_ALIGNMENT (TARGET_STRICT_ALIGNMENT)
 #define M68K_HONOR_TARGET_STRICT_ALIGNMENT 1

+#define DWARF_CIE_DATA_ALIGNMENT -2
+
 #define INT_TYPE_SIZE (TARGET_SHORT ? 16 : 32)

 /* Define these to avoid dependence on meaning of `int'.  */

--
Joseph S. Myers
[EMAIL PROTECTED]
  



--
Joel Sherrill, Ph.D. Director of Research & Development
[EMAIL PROTECTED]On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
  Support Available (256) 722-9985

Re: lto

[Jan Hubicka]

> I am agree with you.  We should not forget embedded market where the 
> code size is more imortant but we should provide an option for  market 
> on which  Pathscale/Intel/Sun compilers are oriented.
> 
> With this point of view, we have a lot of resources because gcc 
> generates the smallest code.  E.g. In averages Intel compiler generates 
> 80% bigger code for SPECINT2000 with -O2 and 7 times bigger with -fast.  
> It generates even bigger code with -Os (code size optimizations) than 
> GCC for -O3.  The same is about the compilation speed.  GCC with -O3 is 
> much faster (30%-40%) than all mentioned compilers in peak performance 
> mode (-fast, -Ofast).  So I think we have some resouces which we could 
> spend to improve the code performance for this market.

Actually with my experiments about --combine and -fwhole-program
combination I was more easilly getting noticeable code size savings for
"LTO" at -O2 than noticeale performance improvements at -O3 (I didn't
get even that 4% you mention on pathscale, it was about 1-2% if I remember
correctly with about 20% code size regression).
Just few of SPEC2000 benchmarks has important crossmodule inlining
oppurtunities in them).  I will try to dig out the numbers.

So the initial LTO will probably be good for people caring about code
size: not just the embedded marked, but I hope that as soon as we get
--lto resonably working for C good portion of Linux distro can be built
this way with noticeable benefits at load times of all the small tools
we use daily.  With code/data segment reordering we ought to get less
memory dirtified at during initialization of compiled application too.

It is hoped that as we implement better IPA alias analysis and similar
optimizations, the need for inlining of large function bodies will be
actually reduced. IP RA fits pretty well this plan IMO.

Honza

Re: Problem with libiberty's hash tables

[Paolo Bonzini]

FX wrote:

Hi all,

I've started using libiberty's hashtab in libgfortran for some of my
gfortran work to track memory allocations in the library. I store
custom structures in a hash table, each structure containing a unique
pointer (it is a malloc'ed address) that is used for the hash. When I
traverse the table elements after having inserted a few, I get twice
the number I expect. It's probably a beginner's mistake, and will be
easy to spot, but I haven't managed to understand what I'm doing
wrong.


If you don't need GC and you don't need delete (the latter I can't see 
from your example), a pointer_map is much easier to use.


Paolo

Re: Problem with libiberty's hash tables

[FX]

>  If you don't need GC and you don't need delete (the latter I can't see
>  from your example), a pointer_map is much easier to use.

I'm going to use it for registering memory allocation: pointers
malloc'ed will be registered, along with the source location of the
allocation; when freed, I fetch the entry that was registered for this
pointer, and remove it from the table. The structures left at the end
(which correspond to memory leaks) are then displayed to allow the
user to fix his leaks. The CPU usage is probably the limiting factor,
here, as I want to avoid slowing the program down more than necessary.

I guess that, because I need to delete entries, the pointer_map
wouldn't work, is that right? Plus, pointer_map is not library code...

Thanks for the suggestion, I'll look more deeply into pointer-set.c.
FX

-- 
FX Coudert
http://www.homepages.ucl.ac.uk/~uccafco/

compilation flow

[Dasarath Weeratunge]

I'm trying to extract the C front end of GCC with all tree lowering
passes, and call graph generation. I do not need ssa conversion. Is
tree_rest_of_compilation the correct place to cut the compiler
pipeline for this?

thanks,
-- dasarath

Re: compilation flow

[Diego Novillo]

On 2/15/08 1:27 PM, Dasarath Weeratunge wrote:

I'm trying to extract the C front end of GCC with all tree lowering
passes, and call graph generation. I do not need ssa conversion. Is
tree_rest_of_compilation the correct place to cut the compiler
pipeline for this?


No.  See passes.c:init_optimization_passes.


Diego.

GCC Test Question

[Joel Sherrill]

Hi,

Thanks to Dave Korn and Hans-Peter Nillson,
I have managed to get the GCC test suite
running on 3 RTEMS targets so far and post
results.  I now have need some advice
in fine-tuning things.

+ I have failures on i386 because I am
 running the tests on qemu configured
 as an i386 w/FPU.  That means there is
 no MMX or SSE support at all. I think
 is the root of about 75% (~300) of the
 executable failures.  What is the right
 thing to do and how do I do it?

 Results for review:

http://gcc.gnu.org/ml/gcc-testresults/2008-02/msg00944.html

 FWIW the toolset supports the SSE and this
 is just a simulator limitation.  I think this
 same issue could also be occuring psim on Altivec
 and sis with the SPARC multimedia extensions.

+ I don't have simulators or hardware for
 a number of the targets.  I would like to
 verify that all the executable tests at least
 compile and link.  Would it be confuse anyone
 on those targets if I rigged things so all
 of the executables passed? (e.g. a fake simulator
 that printed "*** EXIT code 0"

--
Joel Sherrill, Ph.D. Director of Research & Development
[EMAIL PROTECTED]On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
  Support Available (256) 722-9985

Re: Problem with libiberty's hash tables

[Paolo Bonzini]

If the latter, of course you could write pointer_map_delete yourself; 
it might be worthwhile since pointer maps are a tad faster than 
libiberty hashtabs.  It's on my todo list, but I wrote pointer_map for 
my private work on gcc and it was not needed at the time.


But didn't you say the need to remove entries (quite frequently, 
actually) makes pointer_map unsuitable?


No, it's just that the code isn't there.

Paolo

Re: Problem with libiberty's hash tables

[Jakub Jelinek]

On Fri, Feb 15, 2008 at 09:13:34PM +0100, Paolo Bonzini wrote:
> 
> > The structures left at the end
> >(which correspond to memory leaks) are then displayed to allow the
> >user to fix his leaks. The CPU usage is probably the limiting factor,
> >here, as I want to avoid slowing the program down more than necessary.
> 
> Sure it's faster this way, but what's wrong with valgrind? ;-)

Or when only talking about memory leaks 
MALLOC_TRACE=myapp.log ./myapp args
mtrace ./myapp myapp.log

Jakub

gcc-4.3-20080215 is now available

[gccadmin]

Snapshot gcc-4.3-20080215 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20080215/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 4.3 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 132353

You'll find:

gcc-4.3-20080215.tar.bz2  Complete GCC (includes all of below)

gcc-core-4.3-20080215.tar.bz2 C front end and core compiler

gcc-ada-4.3-20080215.tar.bz2  Ada front end and runtime

gcc-fortran-4.3-20080215.tar.bz2  Fortran front end and runtime

gcc-g++-4.3-20080215.tar.bz2  C++ front end and runtime

gcc-java-4.3-20080215.tar.bz2 Java front end and runtime

gcc-objc-4.3-20080215.tar.bz2 Objective-C front end and runtime

gcc-testsuite-4.3-20080215.tar.bz2The GCC testsuite

Diffs from 4.3-20080208 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.3
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.

Re: Problem with libiberty's hash tables

[FX Coudert]

Sure it's faster this way, but what's wrong with valgrind? ;-


valgrind (and mtrace) are OS-specific. Also, tracking memory  
allocations has other benefits, like allowing to give memory  
statistics (what are the largest allocations, how much is used for  
compiler-generated temporaries, etc.).


What do you mean, is not library code?  Do you need it in  
libgfortran or in GCC?


In libgfortran.

If the latter, of course you could write pointer_map_delete  
yourself; it might be worthwhile since pointer maps are a tad  
faster than libiberty hashtabs.  It's on my todo list, but I wrote  
pointer_map for my private work on gcc and it was not needed at the  
time.


But didn't you say the need to remove entries (quite frequently,  
actually) makes pointer_map unsuitable?


FX

--
François-Xavier Coudert
http://www.homepages.ucl.ac.uk/~uccafco/

Re: Problem with libiberty's hash tables

[Paolo Bonzini]

 The structures left at the end
(which correspond to memory leaks) are then displayed to allow the
user to fix his leaks. The CPU usage is probably the limiting factor,
here, as I want to avoid slowing the program down more than necessary.


Sure it's faster this way, but what's wrong with valgrind? ;-)


I guess that, because I need to delete entries, the pointer_map
wouldn't work, is that right? Plus, pointer_map is not library code...


What do you mean, is not library code?  Do you need it in libgfortran or 
in GCC?


If the latter, of course you could write pointer_map_delete yourself; it 
might be worthwhile since pointer maps are a tad faster than libiberty 
hashtabs.  It's on my todo list, but I wrote pointer_map for my private 
work on gcc and it was not needed at the time.


Paolo

Site and link suggestion - File-Extensions.org

[Petr Novotny - File Extensions Resource]

Hello,
can you please add link to our website File-Extensions.org at your page 
http://gcc.gnu.org/ml/fortran/2007-01/msg00158.html as a resource about 
computer file extensions?

Our site URL: http://www.file-extensions.org/
File-Extensions.org - Large file extensions and file types resource website

Description: 
Find file extension details here including easy-to-understand descriptions and 
associated applications. Quickly search by extension, view common and most 
visited extensions, and click 
to extension categories including audio and music files, multimedia, graphic 
and image file types and others.

I look forward to hearing from you soon.

Thanks a lot 

Petr Novotny
File-Extensions.org 

Re: GCC Test Question

[Uros Bizjak]

Hello!


+ I have failures on i386 because I am
 running the tests on qemu configured
 as an i386 w/FPU.  That means there is
 no MMX or SSE support at all. I think
 is the root of about 75% (~300) of the
 executable failures.  What is the right
 thing to do and how do I do it?


Does qemu return correct cpuid data for simulated processor?

In gcc.target/i386, supported features are detected using cpuid, i.e. 
sse in sse-check.h:


--cut here--
 if (!__get_cpuid (1, &eax, &ebx, &ecx, &edx))
   return 0;

 /* Run SSE test only if host has SSE support.  */
 if (edx & bit_SSE)
   sse_test ();

 return 0;
--cut here--

In gcc.dg/vect, the support is checked by trapping SIGILL, if insn is 
not recignized (tree-vect.h):


--cut here--
#elif defined(__i386__) || defined(__x86_64__)
 /* SSE2 instruction: movsd %xmm0,%xmm0 */
--cut here--

(Although I think that for x86, we could implement feature check using 
cpuid here, too)



Since all profiling tests fails, you should disable profiling checks for 
rtems in testsuite/lib/target-supports.exp, function 
check_profiling_available.


Uros.