Re: ARM interworking question
On Wed, 21 Jan 2009 09:49:00 + Richard Earnshaw wrote: > > [...] > No, this shouldn't be happening unless a) you are doing something > wrong; b) the options you are supplying to the compiler/linker are > suggesting some sort of stubs are necessary. It was case a), an option left in the makefile that should not have been there. It was also a case a write-before-read operation on my part, the README-interwork in gcc/config/arm was most enlightening. My sincere apologies for generating noise. Zoltan
Re: Size of the GCC repository
Bernd Roesch wrote: > if the size is a problem, Well, not normally, yesterday wanted to have something working as soon as possible and 5G more (vs the docs) meant hours for me :( Today will apply a wwwdocs patchlet as obvious. > i find out that the test programs eat most space > in gcc project, depend on cluster size of harddrives.test have only few > bytes but there are many files > I unpack some times ago gcc and g++ and tests it take 12 GB > > without tests used size was then only 400 mb. > That's an useful information, didn't consider it at the outset. Thanks. Paolo.
Re: Size of the GCC repository
Paolo Carlini wrote: > Well, not normally, yesterday wanted to have something working as soon > as possible and 5G more (vs the docs) meant hours for me :( Today will > apply a wwwdocs patchlet as obvious. > This. Paolo. / 2008-01-22 Paolo Carlini * htdocs/rsync.html: Update size of the repository. Index: htdocs/rsync.html === RCS file: /cvs/gcc/wwwdocs/htdocs/rsync.html,v retrieving revision 1.17 diff -u -r1.17 rsync.html --- htdocs/rsync.html 19 Oct 2008 23:44:46 - 1.17 +++ htdocs/rsync.html 22 Jan 2009 10:03:15 - @@ -18,7 +18,7 @@ Getting a local copy of GCC repository using rsync The GCC repository is available at rsync://gcc.gnu.org/gcc-svn. -The whole repository takes over 12G of disk space, +The whole repository currently takes about 17G of disk space, which takes a substantial time to transfer. Subsequent synchronizations will be much faster, though, as rsync uses a smart algorithm to only transfer differences over the network.
Re: Size of the GCC repository
Paolo Carlini writes: > for the record, today I started an rsync to get a local copy of the > repository and, at variance with the information in: > > http://gcc.gnu.org/rsync.html > > the size I'm seeing is already > 17G, and counting... The git mirror contains the same information in 455024Kb. :-) Andreas. -- Andreas Schwab, SuSE Labs, sch...@suse.de 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."
Antwort: Re: Size of the GCC repository
Paolo Carlini wrote: > Paolo Carlini wrote: > > Well, not normally, yesterday wanted to have something working as soon > > as possible and 5G more (vs the docs) meant hours for me :( Today will > > apply a wwwdocs patchlet as obvious. > > > This. > > Paolo. > -The whole repository takes over 12G of disk space, > +The whole repository currently takes about 17G of disk space, Or better ? +The whole repository takes about 17G of disk space at the start +of 2009, growing about 3G per year. Markus Milleder PS: Raw data from the CVS history of rsync.html, the growth is from the last 2 numbers: 09.03.2001 0,45 02.12.2002 0,95 14.06.2003 1,20 13.05.2005 2,80 28.10.2005 7,80 18.06.2007 12,00 22.01.2009 17,00
Re: Antwort: Re: Size of the GCC repository
Markus Milleder wrote: > Or better ? > +The whole repository takes about 17G of disk space at the start > +of 2009, growing about 3G per year. > I think you can commit it as obvious, thanks! Paolo.
Re: DWARF register numbering discrepancy on SPARC between GCC and GDB
> Ok, so it seems the fix is to reinstate the override in sol2.h, > right? This wouldn't change anything except for Solaris. The fix is probably to wipe out the SVR4 definition (and consequently all definitions in config/sparc since the remaining ones will duplicate the default). -- Eric Botcazou
Re: GCC 4.3.3 Release Candidate available from gcc.gnu.org
Richard Guenther schrieb: > A release candidate for GCC 4.3.3 is available from > > ftp://gcc.gnu.org/pub/gcc/snapshots/4.3.3-RC-20090117/ > > and shortly its mirrors. It has been generated from SVN revision 143460. Lucas did do two test rebuilds of the current Debian lenny/testing archive for i486 using the Debian gcc-4.3 packages, one based on gcc-4_3-branch from 20080905 and one based on gcc-4_3-branch from 20090117 including the proposed patch for PR38905. progressions (in terms of packages): - ed, testsuite runs sucessful - freefem3d: fixed build failure - gambit: fixed build failure - ilmbase: fixed build failure - gmsh: fixed link failure - speech-tools: fixed build failure - texmacs: fixed build failure - xapian-core: testsuite runs sucessful regression: - debtags, filed PR38902 the builds for btanks, dcmtk, gnat-gps, gnome-games, insighttoolkit, latex-cjk-chinese-arphic, linux-2.6, lyx, openjdk-6, openoffice.org were not finished in time. Matthias
Re: GCC 4.3.3 Release Candidate available from gcc.gnu.org
On Thu, 22 Jan 2009, Matthias Klose wrote:
> Richard Guenther schrieb:
> > A release candidate for GCC 4.3.3 is available from
> >
> > ftp://gcc.gnu.org/pub/gcc/snapshots/4.3.3-RC-20090117/
> >
> > and shortly its mirrors. It has been generated from SVN revision 143460.
>
> Lucas did do two test rebuilds of the current Debian lenny/testing archive for
> i486 using the Debian gcc-4.3 packages, one based on gcc-4_3-branch from
> 20080905 and one based on gcc-4_3-branch from 20090117 including the proposed
> patch for PR38905.
>
> progressions (in terms of packages):
>
> - ed, testsuite runs sucessful
> - freefem3d: fixed build failure
> - gambit: fixed build failure
> - ilmbase: fixed build failure
> - gmsh: fixed link failure
> - speech-tools: fixed build failure
> - texmacs: fixed build failure
> - xapian-core: testsuite runs sucessful
>
> regression:
>
> - debtags, filed PR38902
Which looks invalid. We now reject
class Foo {
enum { TAGS = 1 };
template
void foo(TAGS x, int i)
{
switch (i) {
case TAGS:;
}
}
};
which we previously accepted.
Richard.
Re: Size of the GCC repository
Gerald Pfeifer wrote: On Thu, 22 Jan 2009, Paolo Carlini wrote: This. Thanks, Paolo! Scary how quickly this is growing... Gerald Well it's probably growing more slowly than a) disk capactiy at reasonable price b) broadband bandwidths in general As long as that's true, no need to get too worried :-) Yes, if people are on slow lines, they are in trouble, but really you need a decent download bandwidth if you are going to do software development, and after all a single 45 min TV episode downloaded is 1gig from amazon these days :-)
Re: Size of the GCC repository
On Thu, 22 Jan 2009, Paolo Carlini wrote: > This. Thanks, Paolo! Scary how quickly this is growing... Gerald
Document error on TARGET_ASM_NAMED_SECTION ?
Hello, According to current GCC internal manual. http://gcc.gnu.org/onlinedocs/gccint/File-Framework.html#index-TARGET_005fASM_005fNAMED_005fSECTION-4335 - Target Hook: void TARGET_ASM_NAMED_SECTION (const char *name, unsigned int flags, unsigned int align) Output assembly directives to switch to section name. The section should have attributes as specified by flags, which is a bit mask of the SECTION_* flags defined in output.h. If align is nonzero, it contains an alignment in bytes to be used for the section, otherwise some target default should be used. Only targets that must specify an alignment within the section directive need pay attention to align - we will still use ASM_OUTPUT_ALIGN. But the actually the third argument should be "tree decl" instead of "unsigned int align". The following is the default hook. default_elf_asm_named_section (const char *name, unsigned int flags, tree decl ATTRIBUTE_UNUSED) Is it an error or do I miss something? Cheers, Bingfeng Mei
Re: Document error on TARGET_ASM_NAMED_SECTION ?
"Bingfeng Mei" writes: > According to current GCC internal manual. > http://gcc.gnu.org/onlinedocs/gccint/File-Framework.html#index-TARGET_005fASM_005fNAMED_005fSECTION-4335 > > - Target Hook: void TARGET_ASM_NAMED_SECTION (const char *name, unsigned int > flags, unsigned int align) > > Output assembly directives to switch to section name. The section should > have attributes as specified by flags, which is a bit mask of the SECTION_* > flags defined in output.h. If align is nonzero, it contains an alignment in > bytes to be used for the section, otherwise some target default should be > used. Only targets that must specify an alignment within the section > directive need pay attention to align - we will still use ASM_OUTPUT_ALIGN. > > > But the actually the third argument should be "tree decl" instead of > "unsigned int align". The following is the default hook. > > default_elf_asm_named_section (const char *name, unsigned int flags, > tree decl ATTRIBUTE_UNUSED) > > Is it an error or do I miss something? It is an error in the documentation. Ian
gcc-4.3-20090122 is now available
Snapshot gcc-4.3-20090122 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20090122/ 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/branches/gcc-4_3-branch revision 143576 You'll find: gcc-4.3-20090122.tar.bz2 Complete GCC (includes all of below) gcc-core-4.3-20090122.tar.bz2 C front end and core compiler gcc-ada-4.3-20090122.tar.bz2 Ada front end and runtime gcc-fortran-4.3-20090122.tar.bz2 Fortran front end and runtime gcc-g++-4.3-20090122.tar.bz2 C++ front end and runtime gcc-java-4.3-20090122.tar.bz2 Java front end and runtime gcc-objc-4.3-20090122.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.3-20090122.tar.bz2The GCC testsuite Diffs from 4.3-20090115 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.
[graphite] Polyhedral Compilation Package Interface Specification
Below is a link to the Polyhderal Compilation Package Interface, which will be used as an interface between the polyhedral representation and GIMPLE. This will be integrated in the Graphite branch and we will propose this for GCC 4.5. http://gcc.gnu.org/wiki/Graphite?action=AttachFile&do=view&target=pcp.pdf Abstract The CLooG library provides code generation capabilities from a polyhedral representation. CLooG was designed to be a component of a compiler infrastructure, there is no existing framework to support transformations, dependence information or tracking additional information such as location information. Currently the internal representation is used as an interface to CLooG. This document defines the interface to the Polyhedral Compilation Package (PCP) which is a loop-optimization framework, including a language to interface between PCP and GCC. The goal is to create a package that will provide loop optimization and analysis capabilities to GCC.
