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

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

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

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/

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

"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 >> > =

Re: lto

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 f

Re: lto

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

Re: lto

> 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 > dec

Re: lto

> 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 I

Re: lto

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 skeptic

Problem with libiberty's hash tables

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 ta

Re: Problem with libiberty's hash tables

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;

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

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 t

Re: lto

> 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 co

Re: Problem with libiberty's hash tables

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 tra

Re: Problem with libiberty's hash tables

> 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

compilation flow

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

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_optimiz

GCC Test Question

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 m

Re: Problem with libiberty's hash tables

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 t

Re: Problem with libiberty's hash tables

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 mo

gcc-4.3-20080215 is now available

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

Re: Problem with libiberty's hash tables

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

Re: Problem with libiberty's hash tables

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 valgr

Site and link suggestion - File-Extensions.org

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 websi

Re: GCC Test Question

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