Re: Discussion about merging Go frontend

[Dave Korn]

On 30/10/2010 01:23, Richard Henderson wrote:

>> +  if (!objfile_internal_read (objfile->descriptor,
>> +  objfile->offset + eor->shoff + shdr_size,
>> +  shdrs,
>> +  shdr_size * (shnum - 1),
>> +  &errmsg, err))
> 
> Do we really want to keep re-reading section data for every section
> lookup we do?  Can't we do this in objfile_open_read?

  It should only be necessary to do one section lookup per object file anyway.
 Keep extra data hanging around in memory in the backend just so that we can
write algorithmically inefficient code in the client?  Seems like a bad
tradeoff to me!

>> +  set_32 (hdr + offsetof (struct external_scnhdr, s_flags),
>> +  (STYP_DATA | IMAGE_SCN_ALIGN_1BYTES | IMAGE_SCN_MEM_DISCARDABLE
>> +   | IMAGE_SCN_MEM_SHARED | IMAGE_SCN_MEM_READ));
> 
> You're not recording alignment in the coff object file?

  It looks to me like he's recording an alignment of 1 byte.

> IMAGE_SCN_ALIGN_BYTES, 1 <= N <= 8192, are all defined
> with a simple function in that nibble.

  The line you quoted uses IMAGE_SCN_ALIGN_1BYTES.  That's all we'll ever need
for LTO sections.

cheers,
  DaveK

Re: Discussion about merging Go frontend

[Paolo Bonzini]

On 10/30/2010 05:30 AM, H.J. Lu wrote:

Will put

if [ Go is enabled ]; then
   boot_language=yes
fi

in cp/config-lang.in work?


It's a bit backwards, no?

Paolo

Re: Discussion about merging Go frontend

[Dave Korn]

On 29/10/2010 02:31, Ian Lance Taylor wrote:

> This implements an object file reader/writer which does everything
> required by LTO and gccgo.  The ELF code works.  I have not tested the
> Mach-O and COFF code at all beyond compiling it; I hope that somebody
> else can test those targets and fix them.
> 
> With this patch, libelf is no longer needed.

  Almost, but not quite!  The attached patch switches the lto-plugin over to
use the new objfile reader as well.

lto-plugin/ChangeLog:

* configure.ac: Don't use libelf, don't source config.gcc.
(LIBELFLIBS): Delete.
(LIBELFINC): Delete.
(LTO_FORMAT): Delete.
(SYM_STYLE): New AC_SUBST var set based on $target.
* Makefile.am (LIBELFLIBS): Delete.
(LIBELFINC): Delete.
(LTO_FORMAT): Delete.
(SYM_STYLE): Import.
(AM_CPPFLAGS): Use it.  Don't use LIBELFINC.
(liblto_plugin_la_SOURCES): Don't use LTO_FORMAT, don't include
any object-format-specific source file in the link.
(liblto_plugin_la_LIBADD): Don't use LIBELFLIBS.
* configure: Regenerate.
* Makefile.in: Regenerate.
* lto-plugin-elf.c: Delete.
* lto-plugin-coff.c: Delete.
* lto-plugin.h: Delete.
* lto-plugin.c (O_BINARY): Definition moved here from lto-plugin.h.
(LTO_SEGMENT_NAME): New definition.
(LTO_SECTION_PREFIX): Definition moved here from lto-plugin.h.
(LTO_SECTION_PREFIX_LEN): New definition.
(struct sym_aux): Struct definition moved here from lto-plugin.h.
(struct plugin_symtab): Likewise.
(struct plugin_objfile): Likewise.
(struct plugin_objfile): New struct def.
(enum symbol_style): New enum type.
(add_symbols): Make static.
(claimed_files): Likewise.
(num_claimed_files): Likewise.
(sym_style): New global.
(check): Make static.
(parse_table_entry): Likewise.  Respect sym_style when extracting
symbol from symtab entry.
(translate): Make static.
(resolve_conflicts): Likewise.
(process_symtab): New function, per-section callback version of
old object-format-specific handling from deleted lto-plugin-elf.c.
(claim_file_handler): Convert ELF-specific version from deleted
lto-plugin-elf.c to objfile interface and move here.
(process_options): Allow new '-sym-style=' option.
(onload): Don't call deleted onload_format_checks hook.

  Bootstrapped and tested all languages except java and ada on
x86_64-unknown-linux-gnu, no regressions.  There are still a couple of bugs to
iron out of the COFF-specific part of the objfile reader which I'll have fixed
later today.

  OK for trunk (once the objfile changes have gone in)?

cheers,
  DaveK

Index: lto-plugin/lto-plugin-elf.c
===
--- lto-plugin/lto-plugin-elf.c	(revision 166059)
+++ lto-plugin/lto-plugin-elf.c	(working copy)
@@ -1,157 +0,0 @@
-/* LTO plugin for gold.
-   Copyright (C) 2009, 2010 Free Software Foundation, Inc.
-   Contributed by Rafael Avila de Espindola (espind...@google.com).
-
-This program is free software; you can redistribute it and/or modify
-it under the terms of the GNU General Public License as published by
-the Free Software Foundation; either version 3, or (at your option)
-any later version.
-
-This program is distributed in the hope that it will be useful, but
-WITHOUT ANY WARRANTY; without even the implied warranty of
-MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
-General Public License for more details.
-
-You should have received a copy of the GNU General Public License
-along with this program; see the file COPYING3.  If not see
-.  */
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-/* The presence of gelf.h is checked by the toplevel configure script.  */
-#include 
-
-/* Common definitions that the object format dependent code needs.  */
-#include "lto-plugin.h"
-
-/* Process all lto symtabs of file ELF. */
-
-static int
-process_symtab (Elf *elf, struct plugin_symtab *out)
-{
-  int found = 0;
-  Elf_Scn *section = 0;
-  GElf_Ehdr header;
-  GElf_Ehdr *t = gelf_getehdr (elf, &header);
-  if (t == NULL)
-return 0;
-  assert (t == &header);
-
-  while ((section = elf_nextscn(elf, section)) != 0)
-{
-  GElf_Shdr shdr;
-  GElf_Shdr *tshdr = gelf_getshdr (section, &shdr);
-  Elf_Data *symtab;
-  const char *t;
-  assert (tshdr == &shdr);
-  t = elf_strptr (elf, header.e_shstrndx, shdr.sh_name);
-  assert (t != NULL);
-  if (strncmp (t, LTO_SECTION_PREFIX, strlen (LTO_SECTION_PREFIX)) == 0)
-	{
-	  char *s = strrchr (t, '.');
-	  if (s)
-	  sscanf (s, ".%x", &out->id);
-	  symtab = elf_getdata (section, NULL);
-	  translate (symtab->d_buf, symtab->d_buf + symtab->d_size, out);
-	  found++;
-	}
-}
-  return found;

Re: Discussion about merging Go frontend

[Dave Korn]

On 29/10/2010 02:31, Ian Lance Taylor wrote:

>   * objfile-coff.c: New file.

  A few bugs have cropped up:

> +  if (namebuf[0] == '/')
> + {
> +   size_t strindex;
> +   char *end;
> +
> +   strindex = strtol (namebuf, &end, 10);

  Needs to be strtol (namebuf + 1, 

> +  /* We don't write out any symbols.  We'll see if that causes any
> + problems.  */

  Not a chance of getting away with that, I'm afraid.  Everything expects
there to be file and section symbols and their auxiliaries.

> +  set_16 (hdr + offsetof (struct external_filehdr, f_magic), attrs->magic);
> +  set_16 (hdr + offsetof (struct external_filehdr, f_magic), nscns);

  Cut'n'pasto.  Second f_magic should be f_nscns.

> +   name_offset += namelen;

  Also needs to be namelen + 1.

  Attached are the revised version of the file, and a diff to show what I
changed.  With this version, all the tests in gcc.dg/lto/lto.exp pass as
before (i.e. there are still a couple of pre-existing FAILs that aren't 
affected).

cheers,
  DaveK
/* objfile-coff.c -- routines to manipulate COFF object files.
   Copyright 2010 Free Software Foundation, Inc.
   Written by Ian Lance Taylor, Google.

This program is free software; you can redistribute it and/or modify it
under the terms of the GNU General Public License as published by the
Free Software Foundation; either version 2, or (at your option) any
later version.

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
GNU General Public License for more details.

You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, 51 Franklin Street - Fifth Floor,
Boston, MA 02110-1301, USA.  */

#include "config.h"
#include "libiberty.h"
#include "objfile.h"

#include 
#include 

#ifdef HAVE_STDLIB_H
#include 
#endif

#ifdef HAVE_STDINT_H
#include 
#endif

#ifdef HAVE_STRING_H
#include 
#endif

#ifdef HAVE_INTTYPES_H
#include 
#endif

#include "objfile-common.h"

/* COFF structures and constants.  */

/* COFF file header.  */

struct external_filehdr
{
  unsigned char f_magic[2]; /* magic number */
  unsigned char f_nscns[2]; /* number of sections   */
  unsigned char f_timdat[4];/* time & date stamp*/
  unsigned char f_symptr[4];/* file pointer to symtab   */
  unsigned char f_nsyms[4]; /* number of symtab entries */
  unsigned char f_opthdr[2];/* sizeof(optional hdr) */
  unsigned char f_flags[2]; /* flags*/
};

/* Bits for filehdr f_flags field.  */

#define F_EXEC  (0x0002)
#define IMAGE_FILE_SYSTEM   (0x1000)
#define IMAGE_FILE_DLL  (0x2000)

/* COFF section header.  */

struct external_scnhdr
{
  unsigned char s_name[8];  /* section name */
  unsigned char s_paddr[4]; /* physical address, aliased s_nlib */
  unsigned char s_vaddr[4]; /* virtual address  */
  unsigned char s_size[4];  /* section size */
  unsigned char s_scnptr[4];/* file ptr to raw data for section */
  unsigned char s_relptr[4];/* file ptr to relocation   */
  unsigned char s_lnnoptr[4];   /* file ptr to line numbers */
  unsigned char s_nreloc[2];/* number of relocation entries */
  unsigned char s_nlnno[2]; /* number of line number entries*/
  unsigned char s_flags[4]; /* flags*/
};

/* The length of the s_name field in struct external_scnhdr.  */

#define SCNNMLEN (8)

/* Bits for scnhdr s_flags field.  This includes some bits defined
   only for PE.  This may need to be moved into coff_magic.  */

#define STYP_DATA   (1 << 6)
#define IMAGE_SCN_ALIGN_1BYTES  (1 << 20)
#define IMAGE_SCN_MEM_DISCARDABLE   (1 << 25)
#define IMAGE_SCN_MEM_SHARED(1 << 28)
#define IMAGE_SCN_MEM_READ  (1 << 30)

/* COFF symbol table entry.  */

#define E_SYMNMLEN  8   /* # characters in a symbol name*/

struct external_syment
{
  union
  {
unsigned char e_name[E_SYMNMLEN];

struct
{
  unsigned char e_zeroes[4];
  unsigned char e_offset[4];
} e;
  } e;

  unsigned char e_value[4];
  unsigned char e_scnum[2];
  unsigned char e_type[2];
  unsigned char e_sclass[1];
  unsigned char e_numaux[1];
};

/* Length allowed for filename in aux sym format 4.  */

#define E_FILNMLEN  18

/* Omits x_sym and other unused variants.  */

union external_auxent
{
  /* Aux sym format 4: file.  */
  union
  {
char x_fname[E_FILNMLEN];
struct
{
  unsigned char x_zeroes[4];
  unsigned char x_offset[4];
} x_n;
  } x_file;
  /* Aux sym format 5: section.  */
  struct
  {
unsigned char x_scnlen[4]; 

Re: TARGET_VALID_POINTER_MODE unused?

[Paul Koning]

On Oct 29, 2010, at 5:48 PM, Andrew Pinski wrote:

> On Fri, Oct 29, 2010 at 2:28 PM, Paul Koning  wrote:
>> I see documentation for TARGET_VALID_POINTER_MODE, and I see ports that 
>> define it... but I don't see any code that uses it.
> 
> Ok, there are two issues it seems.  First it is used in target.def:
> /* True if MODE is valid for a pointer in __attribute__((mode("MODE"))).  */
> DEFHOOK
> (valid_pointer_mode,
> "",
> bool, (enum machine_mode mode),
> default_valid_pointer_mode)
> 
> But the other issue is that the default
> default_addr_space_pointer_mode does not use it which means it is
> unused really.  I think we should only have one or the other hook
> really.

Thanks.  I did not know the correct string to  look for ("valid_pointer_mode" 
without the prefix).  I did find a reference or two.

What triggered the question is that I'm trying to debug a testsuite ICE in 
fortran, pdp11 target, where it aborts in convert_memory_address_addr_space 
apparently trying to make a 32 bit pointer.  But only 16 bit pointers are 
valid, ptr_mode is HImode as expected and as far as I can tell from gccint 
everything is set up correctly for that to be the only pointer type.  I don't 
have TARGET_VALID_POINTER_MODE defined and from what the documentation says it 
doesn't seem like I have to.  So where should I look to find an explanation for 
why the fortran compiler is trying to make an SImode pointer?

paul

[PATCH] Enable linker plugin for windows [was Re: Discussion about merging Go frontend]

[Dave Korn]

On 30/10/2010 11:44, Dave Korn wrote:
> On 29/10/2010 02:31, Ian Lance Taylor wrote:
> 
>> This implements an object file reader/writer which does everything
>> required by LTO and gccgo.  The ELF code works.  I have not tested the
>> Mach-O and COFF code at all beyond compiling it; I hope that somebody
>> else can test those targets and fix them.
>>
>> With this patch, libelf is no longer needed.
> 
>   Almost, but not quite!  The attached patch switches the lto-plugin over to
> use the new objfile reader as well.

>   Bootstrapped and tested all languages except java and ada on
> x86_64-unknown-linux-gnu, no regressions.  There are still a couple of bugs to
> iron out of the COFF-specific part of the objfile reader which I'll have fixed
> later today.
> 
>   OK for trunk (once the objfile changes have gone in)?

  As you'll see elsethread, I fixed the COFF problems.  This is the remaining
chunk of patch required to make the lto-plugin work on cygming targets.

gcc/ChangeLog:

* gcc.c (PLUGIN_PASSTHROUGH_SPEC): New macro factored out from
LINK_COMMAND_SPEC.
(LINK_COMMAND_SPEC): Use it.
(static_spec_functions[]): Add pass-through-libs entry.
(pass_through_libs_spec_func): Add related spec function.
* config/i386/cygming.h (PLUGIN_PASSTHROUGH_SPEC): Define.
* doc/tm.texi.in (PLUGIN_PASSTHROUGH_SPEC): Document.
(LINK_COMMAND_SPEC): Mention it.
* doc/tm.texi: Regenerate.
* doc/invoke.texi (pass-through-libs): Mention new spec function.

  Taking this for a bootstrap and test cycle now (on top of the objfile
changes).  Assuming no regressions, and one new PASS (the sole LTO test that
exercises -fuse-linker-plugin), and once all the other patches have gone in: OK?

cheers,
  DaveK

Index: gcc/doc/tm.texi
===
--- gcc/doc/tm.texi	(revision 166059)
+++ gcc/doc/tm.texi	(working copy)
@@ -406,6 +406,15 @@
 By default this is @code{%G %L %G}.
 @end defmac

+...@defmac PLUGIN_PASSTHROUGH_SPEC
+This macro is used as part of @code{LINK_COMMAND_SPEC} when the LTO plugin
+is in use.  It allows the system's standard libraries to be sent to the
+plugin as @option{-pass-through} plugin options, which causes them to be
+added at the end of the link when it may be necessary to resolve new
+undefined references generated as LTO expands builtins from the IR.  The
+default definition should suit ELF platforms.
+...@end defmac
+
 @defmac LINK_COMMAND_SPEC
 A C string constant giving the complete command line need to execute the
 linker.  When you do this, you will need to update your port each time a
@@ -413,7 +422,7 @@
 define this macro only if you need to completely redefine the command
 line for invoking the linker and there is no other way to accomplish
 the effect you need.  Overriding this macro may be avoidable by overriding
-...@code{link_gcc_c_sequence_spec} instead.
+...@code{link_gcc_c_sequence_spec} and/or @code{PLUGIN_PASSTHROUGH_SPEC} instead.
 @end defmac

 @defmac LINK_ELIMINATE_DUPLICATE_LDIRECTORIES
Index: gcc/doc/tm.texi.in
===
--- gcc/doc/tm.texi.in	(revision 166059)
+++ gcc/doc/tm.texi.in	(working copy)
@@ -406,6 +406,15 @@
 By default this is @code{%G %L %G}.
 @end defmac

+...@defmac PLUGIN_PASSTHROUGH_SPEC
+This macro is used as part of @code{LINK_COMMAND_SPEC} when the LTO plugin
+is in use.  It allows the system's standard libraries to be sent to the
+plugin as @option{-pass-through} plugin options, which causes them to be
+added at the end of the link when it may be necessary to resolve new
+undefined references generated as LTO expands builtins from the IR.  The
+default definition should suit ELF platforms.
+...@end defmac
+
 @defmac LINK_COMMAND_SPEC
 A C string constant giving the complete command line need to execute the
 linker.  When you do this, you will need to update your port each time a
@@ -413,7 +422,7 @@
 define this macro only if you need to completely redefine the command
 line for invoking the linker and there is no other way to accomplish
 the effect you need.  Overriding this macro may be avoidable by overriding
-...@code{link_gcc_c_sequence_spec} instead.
+...@code{link_gcc_c_sequence_spec} and/or @code{PLUGIN_PASSTHROUGH_SPEC} instead.
 @end defmac

 @defmac LINK_ELIMINATE_DUPLICATE_LDIRECTORIES
Index: gcc/doc/invoke.texi
===
--- gcc/doc/invoke.texi	(revision 166059)
+++ gcc/doc/invoke.texi	(working copy)
@@ -9683,6 +9683,17 @@
 %:remove-outfile(-lm)
 @end smallexample

+...@item @code{pass-through-libs}
+The @code{pass-through-libs} spec function takes any number of arguments.  It
+finds any @option{-l} options and any non-options (which it assumes are the
+names of linker input files) and returns a result containing all the found
+arguments each prepended by @option{-plugin-opt=-pass-through=} and joined b

Re: Discussion about merging Go frontend

[Richard Henderson]

On 10/30/2010 01:16 AM, Dave Korn wrote:
>> Do we really want to keep re-reading section data for every section
>> lookup we do?  Can't we do this in objfile_open_read?
> 
>   It should only be necessary to do one section lookup per object file anyway.
>  Keep extra data hanging around in memory in the backend just so that we can
> write algorithmically inefficient code in the client?  Seems like a bad
> tradeoff to me!

Uh, really?  I thought there were like a half-dozen lto sections...

>   The line you quoted uses IMAGE_SCN_ALIGN_1BYTES.  That's all we'll ever need
> for LTO sections.

Perhaps, but there's an argument to the create_section function that
specifies the alignment.  If we only need 1-byte alignment that's fine,
but we should either assert that's true, omit the argument, or properly
support it.


r~

RE: A Framework for GCC Plug-ins

[Grigori Fursin]

Hi Justin,

Thanks for the info - nice work!

I forwarded your email to cTuning mailing list because maybe some colleagues 
who are/have been working on Interactive Compilation Interface will be 
interested in this work too ...

Cheers,
Grigori

-Original Message-
From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of Justin 
Seyster
Sent: Friday, October 29, 2010 3:32 AM
To: GCC Mailing List
Subject: A Framework for GCC Plug-ins

One of my research projects for the past few months has been a
framework for writing GCC instrumentation plug-ins called InterAspect.
I am releasing the project today, and since there is a general
interest in plug-ins on this list, I wanted to send a quick
announcement with a pointer to the web site:

http://www.fsl.cs.sunysb.edu/interaspect/

The idea of compiler plug-ins has a lot of potential, which is why I
hope this framework can make compiler plug-ins in general more
accessible to people who don't have extensive background in GCC's
internal workings.

All the code for the project is available under the GPLv3.  Also, I'll
be presenting the project at the International Conference on Runtime
Verification 2010, which is next week.  Thanks a lot to everybody on
the list who helped out with questions while I was working on this.
--Justin

Re: Discussion about merging Go frontend

[Dave Korn]

On 30/10/2010 18:57, Richard Henderson wrote:
> On 10/30/2010 01:16 AM, Dave Korn wrote:
>>> Do we really want to keep re-reading section data for every section
>>> lookup we do?  Can't we do this in objfile_open_read?
>>   It should only be necessary to do one section lookup per object file 
>> anyway.
>>  Keep extra data hanging around in memory in the backend just so that we can
>> write algorithmically inefficient code in the client?  Seems like a bad
>> tradeoff to me!
> 
> Uh, really?  I thought there were like a half-dozen lto sections...

  Which we iterate over just once, and record them all in a hash table from
the per-section callback, unless I've missed something.

>>   The line you quoted uses IMAGE_SCN_ALIGN_1BYTES.  That's all we'll ever 
>> need
>> for LTO sections.
> 
> Perhaps, but there's an argument to the create_section function that
> specifies the alignment.  If we only need 1-byte alignment that's fine,
> but we should either assert that's true, omit the argument, or properly
> support it.

  Fair point.

cheers,
  DaveK

Re: Discussion about merging Go frontend

[Richard Henderson]

On 10/30/2010 11:37 AM, Dave Korn wrote:
>> Uh, really?  I thought there were like a half-dozen lto sections...
> 
>   Which we iterate over just once, and record them all in a hash table from
> the per-section callback, unless I've missed something.

Oh, right.  Nevermind then.


r~

Re: Discussion about merging Go frontend

[Dave Korn]

On 30/10/2010 19:24, Richard Henderson wrote:
> On 10/30/2010 11:37 AM, Dave Korn wrote:
>>> Uh, really?  I thought there were like a half-dozen lto sections...
>>   Which we iterate over just once, and record them all in a hash table from
>> the per-section callback, unless I've missed something.
> 
> Oh, right.  Nevermind then.
> 
> 
> r~

  It'd be worth putting a warning comment on the find_section (no "s")
function saying that it's pretty inefficient and that it is best practice to
call find_sections just once and record details rather than make multiple
calls to find_section.  (Both lto FE and lto-plugin are already architected
that way.)

cheers,
  DaveK

RFC: Add zlib source to src CVS resposity

[H.J. Lu]

Hi,

Binutils can compress/decompress debug sections if zlib is available.
I imported zlib from gcc source tree to binutils source tree. I changed
binutils to use zlib unconditionally. By default, the in-tree zlib is used.
If you configure binutis using --with-system-zlib, system zlib will be used.
My zlib changes are on hjl/zlib branch at

http://git.kernel.org/?p=devel/binutils/hjl/x86.git;a=summary

Any comments?

Thanks.

-- 
H.J.

Re: RFC: Add zlib source to src CVS resposity

[Frank Ch. Eigler]

"H.J. Lu"  writes:

> [...]  By default, the in-tree zlib is used.  If you configure
> binutis using --with-system-zlib, system zlib will be used.  [...]

Can you summarize what modern platforms lack a system zlib, and what
justifies using the proposed in-tree copy by default?

- FChE

Re: RFC: Add zlib source to src CVS resposity

[H.J. Lu]

On Sat, Oct 30, 2010 at 2:37 PM, Frank Ch. Eigler  wrote:
> "H.J. Lu"  writes:
>
>> [...]  By default, the in-tree zlib is used.  If you configure
>> binutis using --with-system-zlib, system zlib will be used.  [...]
>
> Can you summarize what modern platforms lack a system zlib, and what
> justifies using the proposed in-tree copy by default?
>

I don't know. I just want to remove those zlib checks.


-- 
H.J.

gcc-4.6-20101030 is now available

[gccadmin]

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

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

You'll find:

 gcc-4.6-20101030.tar.bz2 Complete GCC (includes all of below)

  MD5=dd3bd7cc948f1ba30134fe7a6cb7f383
  SHA1=5baa9a62fa2dff6dbe823dc83d50df16d9868eea

 gcc-core-4.6-20101030.tar.bz2C front end and core compiler

  MD5=864823955849fe6d55ff5d0266a46a45
  SHA1=2aef40377211a0b01ded5f9111bf611075d1e639

 gcc-ada-4.6-20101030.tar.bz2 Ada front end and runtime

  MD5=d94da138d9d9fff28696121fc3477302
  SHA1=c29bf130c0ab344373948d9d4862f90263a1fac0

 gcc-fortran-4.6-20101030.tar.bz2 Fortran front end and runtime

  MD5=b32413982c3e54c3d1fd89f0873e3dfb
  SHA1=0b41d6de9f4a37db7f59502e4c50c92cc368f230

 gcc-g++-4.6-20101030.tar.bz2 C++ front end and runtime

  MD5=df6ff0a7023950e51f7a0a74fdc0e5b5
  SHA1=07c68f1b9edbc41575eca3899c6a9689d7aa82ba

 gcc-java-4.6-20101030.tar.bz2Java front end and runtime

  MD5=58034949660edd649c84ea9d76e2a097
  SHA1=49639db0fd3840659126b639fdde2c19861340a6

 gcc-objc-4.6-20101030.tar.bz2Objective-C front end and runtime

  MD5=c8e7e33dea4a6ebf2a9f579cff76a088
  SHA1=e5551abace0137520ebcdd00a93f216fa18cbb15

 gcc-testsuite-4.6-20101030.tar.bz2   The GCC testsuite

  MD5=9940b2695397cfbca8838dee10691ffb
  SHA1=3f6f1b4988b5db0a00d6ac21acaa85bfec1e4b83

Diffs from 4.6-20101023 are available in the diffs/ subdirectory.

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