[PATCH, testsuite]: Test compat _Complex varargs passing

[Uros Bizjak]

On Mon, Sep 5, 2016 at 1:45 PM, Joseph Myers  wrote:
> On Sun, 4 Sep 2016, Uros Bizjak wrote:
>
>> It looks that different handling of _Complex char, _Complex short and
>> _Complex float is there on purpose. Is (was?) there a limitation in a
>> c language standard that prevents passing of these arguments as
>> varargs?
>
> Well, ISO C doesn't define complex integers at all.  But it's deliberate
> (see DR#206) that _Complex float doesn't promote to _Complex double in
> variable arguments.  And there is nothing in ISO C to stop _Complex float
> being passed in variable arguments.
>
> For all these types including the complex integer ones: given that the
> front end doesn't promote them, they should be usable in variable
> arguments.

Attached patch adds various _Complex variable arguments tests to
scalar-by-value-4 and scalar-return-4 tests. These tests previously
erroneously claimed that these argument types are unsupported as
variable arguments.

2016-09-08  Uros Bizjak  

* gcc.dg/compat/scalar-by-value-4_x.c: Also test passing of
variable arguments.
* gcc.dg/compat/scalar-by-value-4_y.c (testva##NAME): New.
* gcc.dg/compat/scalar-by-value-4_main.c: Update description comment.
* gcc.dg/compat/scalar-return-4_x.c: Also test returning of
variable argument.
* gcc.dg/compat/scalar-return-4_y.c (testva##NAME): New.
* gcc.dg/compat/scalar-return-4_main.c: Update description comment.

Tested on x86_64-linux-gnu {,-m32}.

OK for mainline?

Uros.
diff --git a/gcc/testsuite/gcc.dg/compat/scalar-by-value-4_main.c 
b/gcc/testsuite/gcc.dg/compat/scalar-by-value-4_main.c
index 8164b44..bd024c0 100644
--- a/gcc/testsuite/gcc.dg/compat/scalar-by-value-4_main.c
+++ b/gcc/testsuite/gcc.dg/compat/scalar-by-value-4_main.c
@@ -1,5 +1,5 @@
 /* Test passing scalars by value.  This test includes _Complex types
-   whose real and imaginary parts cannot be used in variable-length
+   whose real and imaginary parts can be used in variable-length
argument lists.  */
 
 extern void scalar_by_value_4_x (void);
diff --git a/gcc/testsuite/gcc.dg/compat/scalar-by-value-4_x.c 
b/gcc/testsuite/gcc.dg/compat/scalar-by-value-4_x.c
index a4e73c9..a36a060 100644
--- a/gcc/testsuite/gcc.dg/compat/scalar-by-value-4_x.c
+++ b/gcc/testsuite/gcc.dg/compat/scalar-by-value-4_x.c
@@ -13,6 +13,7 @@ test##NAME (TYPE x01, TYPE x02, TYPE x03, TYPE x04,   
\
 TYPE x05, TYPE x06, TYPE x07, TYPE x08,\
 TYPE x09, TYPE x10, TYPE x11, TYPE x12,\
 TYPE x13, TYPE x14, TYPE x15, TYPE x16);   \
+extern void testva##NAME (int n, ...); \
\
 void   \
 check##NAME (TYPE x, TYPE v)   \
@@ -62,6 +63,81 @@ testit##NAME (void)  
\
  g13##NAME, g14##NAME, g15##NAME, g16##NAME);  \
   DEBUG_NL;\
   DEBUG_FPUTS (#NAME); \
+  DEBUG_FPUTS (" testva:");\
+  DEBUG_NL;\
+  testva##NAME (1, \
+   g01##NAME); \
+  DEBUG_NL;\
+  testva##NAME (2, \
+   g01##NAME, g02##NAME);  \
+  DEBUG_NL;\
+  testva##NAME (3, \
+   g01##NAME, g02##NAME, g03##NAME);   \
+  DEBUG_NL;\
+  testva##NAME (4, \
+   g01##NAME, g02##NAME, g03##NAME, g04##NAME);\
+  DEBUG_NL;\
+  testva##NAME (5, \
+   g01##NAME, g02##NAME, g03##NAME, g04##NAME, \
+   g05##NAME); \
+  DEBUG_NL;\
+  testva##NAME (6, \
+   g01##NAME, g02##NAME, g03##NAME, g04##NAME, \
+   g05##NAME, g06##NAME);  \
+  DEBUG_NL;\
+  testva##NAME (7, \
+   g01##NAME, g02##NAME, g03##NAME, g04##NAME, \
+   g05##NAME, g06##NAME, g07##NAME);   \
+  DEBUG_NL;\
+  testva##NAME (8, \
+   g01##NAME, g02##NAME, g03##NAME, g04##NAME, \
+ 

Re: Advice sought for debugging a lto1 ICE (was: Implement C _FloatN, _FloatNx types [version 6])

[Thomas Schwinge]

Hi!

On Wed, 7 Sep 2016 14:23:18 +0200, Richard Biener  
wrote:
> On Wed, Sep 7, 2016 at 1:52 PM, Thomas Schwinge  
> wrote:
> > I trimmed the CC list -- I'm looking for advice about debugging a lto1
> > ICE.
> >
> > On Fri, 19 Aug 2016 11:05:59 +, Joseph Myers  
> > wrote:
> >> On Fri, 19 Aug 2016, Richard Biener wrote:
> >> > Can you quickly verify if LTO works with the new types?  I don't see 
> >> > anything
> >> > that would prevent it but having new global trees and backends 
> >> > initializing them
> >> > might come up with surprises (see tree-streamer.c:preload_common_nodes)
> >>
> >> Well, the execution tests are in gcc.dg/torture, which is run with various
> >> options including -flto (and I've checked the testsuite logs to confirm
> >> these tests are indeed run with such options).  Is there something else
> >> you think should be tested?
> >
> > As I noted in :
> >
> > As of the PR32187 commit r239625 "Implement C _FloatN, _FloatNx types", 
> > nvptx
> > offloading is broken, ICEs in LTO stream-in.  Probably some kind of 
> > data-type
> > mismatch that is not visible with Intel MIC offloading (using the same 
> > data
> > types) but explodes with nvptx.  I'm having a look.
> >
> > I know how to use "-save-temps -v" to re-run the ICEing lto1 in GDB; a
> > backtrace of the ICE looks as follows:
> >
> > #0  fancy_abort (file=file@entry=0x10d61d0 
> > "[...]/source-gcc/gcc/vec.h", line=line@entry=727, 
> > function=function@entry=0x10d6e3a 
> > <_ZZN3vecIP9tree_node7va_heap8vl_embedEixEjE12__FUNCTION__> "operator[]") 
> > at [...]/source-gcc/gcc/diagnostic.c:1414
> > #1  0x0058c9ef in vec > vl_embed>::operator[] (this=0x16919c0, ix=ix@entry=185) at 
> > [...]/source-gcc/gcc/vec.h:727
> > #2  0x0058ca33 in vec::operator[] 
> > (this=this@entry=0x1691998, ix=ix@entry=185) at 
> > [...]/source-gcc/gcc/vec.h:1211
> 
> so it wants tree 185 which is (given the low number) likely one streamed by
> preload_common_nodes.  This is carefully crafted to _not_ diverge by
> frontend (!) it wasn't even designed to cope with global trees being present
> or not dependent on target (well, because the target is always the
> same! mind you!)

Scary.  ;-/

> Now -- in theory it should deal with NULLs just fine (resulting in
> error_mark_node), but it can diverge when there are additional
> compount types (like vectors, complex
> or array or record types) whose element types are not in the set of
> global trees.
> The complex _FloatN types would be such a case given they appear before their
> components.  That mixes up the ordering at least.

ACK, but that's also an issue for "regular" float/complex float, which
also is in "reverse" order.  But that's "fixed" by the recursion in
gcc/tree-streamer.c:record_common_node for "TREE_CODE (node) ==
COMPLEX_TYPE".  This likewise seems to work for the _FloatN types.  (I've
put "fixed" in quotes -- doesn't that recursion mean that we're thus
putting "complex float", "float", [...], "float" (again) into the cache?
Anyway that's for later...)

> So I suggest to add a print_tree to where it does the 
> streamer_tree_cache_append
> and compare cc1 and lto1 outcome.

Thanks for all your suggestions!

As far as I can tell, tree 185 is in fact among the first trees just
after the preloaded ones...  (See record_common_node followed by
streamer_tree_cache_append with "ix == hash" vs., from "ix=180" onwards,
streamer_tree_cache_append called from elsewhere with "ix != hash".)
(I'm also noticing that this cache first is built from "ix=0" through
"ix=179", then apparently discarded, and rebuilt again, which seems
surprising but which I've not yet looked into; hopefully unrelated
issue.)  I'll continue to poke at this, but wanted to given an update
here at least.

[...]
PID=12052 [...]/source-gcc/gcc/tree-streamer.c:272:record_common_node
  constant 64>
unit size  constant 8>
align 64 symtab 0 alias set -1 canonical type 0x768e23f0 precision 
64>
PID=12052 
[...]/source-gcc/gcc/tree-streamer.c:214:streamer_tree_cache_append
  ix=178 hash=178 tree=0x768e23f0
  constant 64>
unit size  constant 8>
align 64 symtab 0 alias set -1 canonical type 0x768e23f0 precision 
64>
PID=12052 [...]/source-gcc/gcc/tree-streamer.c:272:record_common_node
  constant 128>
unit size  constant 16>
align 64 symtab 0 alias set -1 canonical type 0x768e2690 precision 
128>
PID=12052 
[...]/source-gcc/gcc/tree-streamer.c:214:streamer_tree_cache_append
  ix=179 hash=179 tree=0x768e2690
  constant 128>
unit size  constant 16>
align 64 symtab 0 alias set -1 canonical type 0x768e2690 precision 
128>
PID=12052 
[...]/source-gcc/gcc/tree-streamer.c:214:streamer_tree_cache_append
  ix=180 hash=1889092561 tree=0x768cc930
 
PID=12052 
[...]/source-gcc/gcc/tree-streamer.c:214:streamer_tree_cache_append
  

Re: why do we need xtensa-config.h?

[Oleksij Rempel]

Am 07.09.2016 um 18:21 schrieb augustine.sterl...@gmail.com:
> On Tue, Sep 6, 2016 at 11:55 PM, Thomas Schwinge
>  wrote:
>> Hi!
>>
>> Neither do I really know anything about Xtensa, nor do I have a lot of
>> experience in these parts of GCC back ends, but:
> 
> There is a lot of background to know here. Unfortunately, I have no
> familiarity with making debian packages, so I'm unfamiliar with that
> side of it.
> 
> First--and perhaps most important--the current method of configuring
> GCC for xtensa targets has worked well for nearly two decades. As far
> as I know, it is rare to encounter problems. Because of that, the bar
> to change it will probably be fairly high to change it.
> 
>> On Tue, 6 Sep 2016 20:42:53 +0200, Oleksij Rempel  
>> wrote:
>>> i'm one of ath9k-htc-firmware developers. Currently i'm looking for the
>>> way to provide this firmware as opensource/free package for debian. Main
>>> problem seems to be the need to patch gcc xtensa-config.h to make it
>>> suitable for our CPU.
>>>
>>> I have fallowing questions:
>>>
>>> do we really need this patch?
>>> https://github.com/qca/open-ath9k-htc-firmware/blob/master/local/patches/gcc.patch
>>
>> That I can't tell.  ;-)
> 
> You need something like that patch, for sure.
> 
>>> Is it possible or welcome to extend gcc to be configurable without
>>> patching it all the time?
>>
>> Yes, I would think.  The macros modified in the above patch to GCC's
>> include/xtensa-config.h file look like these ought to be modifiable with
>> -m* options defined by the Xtensa back end, and you'd then assign
>> specific defaults to a specific CPU variant, and build GCC (or build a
>> multilib) for that configuration.
> 
> Today, there are literally hundreds of variants of the xtensa cpu
> actually realized and in use. Having a list of all those variants and
> their defaults inside gcc would be awkward and unwieldy.
> 
> But--and here's the rub--literally tomorrow, someone could design a
> hundred more that are different from all of the ones already out
> there. There is literally an unlimited number of potential variants,
> each with potentially brand new, never conceived instructions. (Adding
> clever custom instructions is xtensa's raison d'etre.)
> 
> With the current configurability mechanism, supporting all of those
> variants inside gcc (and, in fact, the rest of the gnu-toolchain) is
> simply a matter of using the correct xtensa-config.h for that
> particular variant. If we were to go with the "-m with defaults"
> mechanism, we would need some way of adding the defaults for the new
> variant to gcc.
> 
> But that is patching gcc also, and once you go there, you may as well
> use the original method.
> 
>>
>> This file include/xtensa-config.h is #included in
>> gcc/config/xtensa/xtensa.h and libgcc/config/xtensa/crti.S,
> 
> Note that "-m" options can't change the instructions in crti.S and
> lib?funcs.S, but macros can and do.
> 
> 
> 
> On the debian packaging side. Forgive me for my ignorance on the
> topic; I don't know that the tool-flow is, or what the requirements
> are. As far as I am aware, this is the first time someone has tried to
> make a debian package for xtensa.

The point is to provide a package for "free" repository. It means, any
one should be able to use "apt-get source package_name", patch it and
recompile it from source.

Right now it would work, but the package scripts should download
toolchain source, patch and compile it and the compile actual firmware.
This is wary high overhead.

This is why i asked my self, why the toolchain can't be modular or
configurable enough to work without patching and recompiling it.

> Anyway, I wouldn't expect patching gcc (or configuring it) for an
> individual package is the right thing. It should probably happen as
> part of some kind of "setup toolchain" step.
> 
> Typically, patching gcc for a xtensa config happens just once
> immediately after designing the processor, or--if you aren't the
> designer yourself--when one starts development for that variant.

after quick look i noticed that:
XSHAL_USE_ABSOLUTE_LITERALS affects TRAMPOLINE_SIZE. This seems to be
hardcoded every where in gcc, so can't be changed dynamically?

XCHAL_HAVE_MUL32_HIGH probably can be changed dynamically.
XCHAL_ICACHE_SIZE and XCHAL_DCACHE_SIZE will enable or disable part of
__xtensa_sync_caches, why not to make it dynamically as command line option?


IMO most of xtensa-config.h can be changed on runtime. Or do i miss some
thing?

> Surely if someone is building this package, they would have already
> built some other software for that particular xtensa target. (Perhaps
> as part of a larger debian build?)
> 
> Also, this package should probably only be built when targeting this
> particular xtensa variant (not xtensa generally). I don't know how one
> restricts this in the debian packaging mechanism.
> 
> Hope this helps, and I'm happy to answer more questions.
> 

currently this patch affects 15 options. Surely it makes n

Re: why do we need xtensa-config.h?

[augustine.sterl...@gmail.com]

On Thu, Sep 8, 2016 at 8:14 AM, Oleksij Rempel  wrote:
> Am 07.09.2016 um 18:21 schrieb augustine.sterl...@gmail.com:
>> On Tue, Sep 6, 2016 at 11:55 PM, Thomas Schwinge
>>  wrote:
>>> Hi!
>>>
>>> Neither do I really know anything about Xtensa, nor do I have a lot of
>>> experience in these parts of GCC back ends, but:
>>
>> There is a lot of background to know here. Unfortunately, I have no
>> familiarity with making debian packages, so I'm unfamiliar with that
>> side of it.
>>
>> First--and perhaps most important--the current method of configuring
>> GCC for xtensa targets has worked well for nearly two decades. As far
>> as I know, it is rare to encounter problems. Because of that, the bar
>> to change it will probably be fairly high to change it.
>>
>>> On Tue, 6 Sep 2016 20:42:53 +0200, Oleksij Rempel  
>>> wrote:
 i'm one of ath9k-htc-firmware developers. Currently i'm looking for the
 way to provide this firmware as opensource/free package for debian. Main
 problem seems to be the need to patch gcc xtensa-config.h to make it
 suitable for our CPU.

 I have fallowing questions:

 do we really need this patch?
 https://github.com/qca/open-ath9k-htc-firmware/blob/master/local/patches/gcc.patch
>>>
>>> That I can't tell.  ;-)
>>
>> You need something like that patch, for sure.
>>
 Is it possible or welcome to extend gcc to be configurable without
 patching it all the time?
>>>
>>> Yes, I would think.  The macros modified in the above patch to GCC's
>>> include/xtensa-config.h file look like these ought to be modifiable with
>>> -m* options defined by the Xtensa back end, and you'd then assign
>>> specific defaults to a specific CPU variant, and build GCC (or build a
>>> multilib) for that configuration.
>>
>> Today, there are literally hundreds of variants of the xtensa cpu
>> actually realized and in use. Having a list of all those variants and
>> their defaults inside gcc would be awkward and unwieldy.
>>
>> But--and here's the rub--literally tomorrow, someone could design a
>> hundred more that are different from all of the ones already out
>> there. There is literally an unlimited number of potential variants,
>> each with potentially brand new, never conceived instructions. (Adding
>> clever custom instructions is xtensa's raison d'etre.)
>>
>> With the current configurability mechanism, supporting all of those
>> variants inside gcc (and, in fact, the rest of the gnu-toolchain) is
>> simply a matter of using the correct xtensa-config.h for that
>> particular variant. If we were to go with the "-m with defaults"
>> mechanism, we would need some way of adding the defaults for the new
>> variant to gcc.
>>
>> But that is patching gcc also, and once you go there, you may as well
>> use the original method.
>>
>>>
>>> This file include/xtensa-config.h is #included in
>>> gcc/config/xtensa/xtensa.h and libgcc/config/xtensa/crti.S,
>>
>> Note that "-m" options can't change the instructions in crti.S and
>> lib?funcs.S, but macros can and do.
>>
>>
>>
>> On the debian packaging side. Forgive me for my ignorance on the
>> topic; I don't know that the tool-flow is, or what the requirements
>> are. As far as I am aware, this is the first time someone has tried to
>> make a debian package for xtensa.
>
> The point is to provide a package for "free" repository. It means, any
> one should be able to use "apt-get source package_name", patch it and
> recompile it from source.
>
> Right now it would work, but the package scripts should download
> toolchain source, patch and compile it and the compile actual firmware.
> This is wary high overhead.
>
> This is why i asked my self, why the toolchain can't be modular or
> configurable enough to work without patching and recompiling it.
>
>> Anyway, I wouldn't expect patching gcc (or configuring it) for an
>> individual package is the right thing. It should probably happen as
>> part of some kind of "setup toolchain" step.
>>
>> Typically, patching gcc for a xtensa config happens just once
>> immediately after designing the processor, or--if you aren't the
>> designer yourself--when one starts development for that variant.
>
> after quick look i noticed that:
> XSHAL_USE_ABSOLUTE_LITERALS affects TRAMPOLINE_SIZE. This seems to be
> hardcoded every where in gcc, so can't be changed dynamically?

TRAMPOLINE_SIZE is used in quite a few places (so beyond my authority
to accept patches), but I suspect it would be acceptable to put a
function behind TRAMPOLINE_SIZE that calculated the value dynamically.

>
> XCHAL_HAVE_MUL32_HIGH probably can be changed dynamically.
> XCHAL_ICACHE_SIZE and XCHAL_DCACHE_SIZE will enable or disable part of
> __xtensa_sync_caches, why not to make it dynamically as command line option?
>
>
> IMO most of xtensa-config.h can be changed on runtime. Or do i miss some
> thing?

Unless we can make it all of what xtensa-config.h provides, we don't
really solve the problem.

Also, I'm wary of adding command l

Re: why do we need xtensa-config.h?

[Oleksij Rempel]

Am 08.09.2016 um 18:10 schrieb augustine.sterl...@gmail.com:
> On Thu, Sep 8, 2016 at 8:14 AM, Oleksij Rempel  wrote:
>> Am 07.09.2016 um 18:21 schrieb augustine.sterl...@gmail.com:
>>> On Tue, Sep 6, 2016 at 11:55 PM, Thomas Schwinge
>>>  wrote:
 Hi!

 Neither do I really know anything about Xtensa, nor do I have a lot of
 experience in these parts of GCC back ends, but:
>>>
>>> There is a lot of background to know here. Unfortunately, I have no
>>> familiarity with making debian packages, so I'm unfamiliar with that
>>> side of it.
>>>
>>> First--and perhaps most important--the current method of configuring
>>> GCC for xtensa targets has worked well for nearly two decades. As far
>>> as I know, it is rare to encounter problems. Because of that, the bar
>>> to change it will probably be fairly high to change it.
>>>
 On Tue, 6 Sep 2016 20:42:53 +0200, Oleksij Rempel  
 wrote:
> i'm one of ath9k-htc-firmware developers. Currently i'm looking for the
> way to provide this firmware as opensource/free package for debian. Main
> problem seems to be the need to patch gcc xtensa-config.h to make it
> suitable for our CPU.
>
> I have fallowing questions:
>
> do we really need this patch?
> https://github.com/qca/open-ath9k-htc-firmware/blob/master/local/patches/gcc.patch

 That I can't tell.  ;-)
>>>
>>> You need something like that patch, for sure.
>>>
> Is it possible or welcome to extend gcc to be configurable without
> patching it all the time?

 Yes, I would think.  The macros modified in the above patch to GCC's
 include/xtensa-config.h file look like these ought to be modifiable with
 -m* options defined by the Xtensa back end, and you'd then assign
 specific defaults to a specific CPU variant, and build GCC (or build a
 multilib) for that configuration.
>>>
>>> Today, there are literally hundreds of variants of the xtensa cpu
>>> actually realized and in use. Having a list of all those variants and
>>> their defaults inside gcc would be awkward and unwieldy.
>>>
>>> But--and here's the rub--literally tomorrow, someone could design a
>>> hundred more that are different from all of the ones already out
>>> there. There is literally an unlimited number of potential variants,
>>> each with potentially brand new, never conceived instructions. (Adding
>>> clever custom instructions is xtensa's raison d'etre.)
>>>
>>> With the current configurability mechanism, supporting all of those
>>> variants inside gcc (and, in fact, the rest of the gnu-toolchain) is
>>> simply a matter of using the correct xtensa-config.h for that
>>> particular variant. If we were to go with the "-m with defaults"
>>> mechanism, we would need some way of adding the defaults for the new
>>> variant to gcc.
>>>
>>> But that is patching gcc also, and once you go there, you may as well
>>> use the original method.
>>>

 This file include/xtensa-config.h is #included in
 gcc/config/xtensa/xtensa.h and libgcc/config/xtensa/crti.S,
>>>
>>> Note that "-m" options can't change the instructions in crti.S and
>>> lib?funcs.S, but macros can and do.
>>>
>>>
>>>
>>> On the debian packaging side. Forgive me for my ignorance on the
>>> topic; I don't know that the tool-flow is, or what the requirements
>>> are. As far as I am aware, this is the first time someone has tried to
>>> make a debian package for xtensa.
>>
>> The point is to provide a package for "free" repository. It means, any
>> one should be able to use "apt-get source package_name", patch it and
>> recompile it from source.
>>
>> Right now it would work, but the package scripts should download
>> toolchain source, patch and compile it and the compile actual firmware.
>> This is wary high overhead.
>>
>> This is why i asked my self, why the toolchain can't be modular or
>> configurable enough to work without patching and recompiling it.
>>
>>> Anyway, I wouldn't expect patching gcc (or configuring it) for an
>>> individual package is the right thing. It should probably happen as
>>> part of some kind of "setup toolchain" step.
>>>
>>> Typically, patching gcc for a xtensa config happens just once
>>> immediately after designing the processor, or--if you aren't the
>>> designer yourself--when one starts development for that variant.
>>
>> after quick look i noticed that:
>> XSHAL_USE_ABSOLUTE_LITERALS affects TRAMPOLINE_SIZE. This seems to be
>> hardcoded every where in gcc, so can't be changed dynamically?
> 
> TRAMPOLINE_SIZE is used in quite a few places (so beyond my authority
> to accept patches), but I suspect it would be acceptable to put a
> function behind TRAMPOLINE_SIZE that calculated the value dynamically.
> 
>>
>> XCHAL_HAVE_MUL32_HIGH probably can be changed dynamically.
>> XCHAL_ICACHE_SIZE and XCHAL_DCACHE_SIZE will enable or disable part of
>> __xtensa_sync_caches, why not to make it dynamically as command line option?
>>
>>
>> IMO most of xtensa-config.h can be 

gcc-6-20160908 is now available

[gccadmin]

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

This snapshot has been generated from the GCC 6 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-6-branch 
revision 240038

You'll find:

 gcc-6-20160908.tar.bz2   Complete GCC

  MD5=befb90f66fcbe4f742dbe14644da077d
  SHA1=7cc96ea766f967979b529ae0d0cb60db92d8bf99

Diffs from 6-20160901 are available in the diffs/ subdirectory.

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