Re: Heads-Up: early LTO debug to land, breaking Mach-O / [X]COFF
On Wed, 23 Aug 2017, Rainer Orth wrote: > Hi Richard, > > > On Fri, 12 May 2017, Richard Biener wrote: > > > >> > >> This is a heads-up that I am in the process of implementing the last > >> of Jasons review comments on the dwarf2out parts of early LTO debug > >> support. I hope to post final patches early next week after thoroughly > >> re-testing everything. > >> > >> Note that Mach-O and [X]COFF support in the simple-object machinery > >> is still missing for the early LTO debug feature so I am going to > >> break LTOing with DWARF debuginfo on Darwin and Windows (CCing > >> maintainers). Mach-O support has been worked on a bit by Iain > >> and myself but the simple-object piece is still missing. > >> A workaround is to use stabs on these targets with LTO. > > unfortunately, the patch not only broke LTO on Darwin, but bootstrap > completely (seen on x86_64-apple-darwin17.0.0): > > /var/gcc/src/hg/trunk/local/gcc/dwarf2out.c: In function 'void > init_sections_and_labels(bool)': > /var/gcc/src/hg/trunk/local/gcc/dwarf2out.c:27184:1: error: '%ld' directive > writing between 1 and 10 bytes into a region of size 9 > [-Werror=format-overflow=] > init_sections_and_labels (bool early_lto_debug) > ^~~~ > /var/gcc/src/hg/trunk/local/gcc/dwarf2out.c:27184:1: note: directive argument > in the range [0, 4294967295] > In file included from ./tm.h:21:0, > from /var/gcc/src/hg/trunk/local/gcc/target.h:52, > from /var/gcc/src/hg/trunk/local/gcc/dwarf2out.c:61: > /var/gcc/src/hg/trunk/local/gcc/config/darwin.h:759:15: note: 'sprintf' > output between 23 and 32 bytes into a destination of size 30 >sprintf (LABEL, "*%s%ld", PREFIX, (long)(NUM)); \ >^~ > /var/gcc/src/hg/trunk/local/gcc/dwarf2out.c:27210:4: note: in expansion of > macro 'ASM_GENERATE_INTERNAL_LABEL' > ASM_GENERATE_INTERNAL_LABEL (debug_skeleton_line_section_label, > ^~~ > /var/gcc/src/hg/trunk/local/gcc/dwarf2out.c:27184:1: error: '%ld' directive > writing between 1 and 10 bytes into a region of size 7 > [-Werror=format-overflow=] > init_sections_and_labels (bool early_lto_debug) > ^~~~ > /var/gcc/src/hg/trunk/local/gcc/dwarf2out.c:27184:1: note: directive argument > in the range [0, 4294967295] > In file included from ./tm.h:21:0, > from /var/gcc/src/hg/trunk/local/gcc/target.h:52, > from /var/gcc/src/hg/trunk/local/gcc/dwarf2out.c:61: > /var/gcc/src/hg/trunk/local/gcc/config/darwin.h:759:15: note: 'sprintf' > output between 25 and 34 bytes into a destination of size 30 >sprintf (LABEL, "*%s%ld", PREFIX, (long)(NUM)); \ >^~ > /var/gcc/src/hg/trunk/local/gcc/dwarf2out.c:27229:4: note: in expansion of > macro 'ASM_GENERATE_INTERNAL_LABEL' > ASM_GENERATE_INTERNAL_LABEL (debug_skeleton_abbrev_section_label, > ^~~ > /var/gcc/src/hg/trunk/local/gcc/dwarf2out.c:27184:1: error: '%ld' directive > writing between 1 and 10 bytes into a region of size 9 > [-Werror=format-overflow=] > init_sections_and_labels (bool early_lto_debug) > ^~~~ > /var/gcc/src/hg/trunk/local/gcc/dwarf2out.c:27184:1: note: directive argument > in the range [0, 4294967295] > In file included from ./tm.h:21:0, > from /var/gcc/src/hg/trunk/local/gcc/target.h:52, > from /var/gcc/src/hg/trunk/local/gcc/dwarf2out.c:61: > /var/gcc/src/hg/trunk/local/gcc/config/darwin.h:759:15: note: 'sprintf' > output between 23 and 32 bytes into a destination of size 30 >sprintf (LABEL, "*%s%ld", PREFIX, (long)(NUM)); \ >^~ > /var/gcc/src/hg/trunk/local/gcc/dwarf2out.c:27238:4: note: in expansion of > macro 'ASM_GENERATE_INTERNAL_LABEL' > ASM_GENERATE_INTERNAL_LABEL (debug_skeleton_line_section_label, > ^~~ > /var/gcc/src/hg/trunk/local/gcc/dwarf2out.c:27184:1: error: '%ld' directive > writing between 1 and 10 bytes into a region of size 9 > [-Werror=format-overflow=] > init_sections_and_labels (bool early_lto_debug) > ^~~~ > /var/gcc/src/hg/trunk/local/gcc/dwarf2out.c:27184:1: note: directive argument > in the range [0, 4294967295] > In file included from ./tm.h:21:0, > from /var/gcc/src/hg/trunk/local/gcc/target.h:52, > from /var/gcc/src/hg/trunk/local/gcc/dwarf2out.c:61: > /var/gcc/src/hg/trunk/local/gcc/config/darwin.h:759:15: note: 'sprintf' > output between 23 and 32 bytes into a destination of size 30 >sprintf (LABEL, "*%s%ld", PREFIX, (long)(NUM)); \ >^~ > /var/gcc/src/hg/trunk/local/gcc/dwarf2out.c:27245:4: note: in expansion of > macro 'ASM_GENERATE_INTERNAL_LABEL' > ASM_GENERATE_INTERNAL_LABEL (debug_skeleton_info_section_la
misleading "-Wmisleading-indentation" warning on break in switch/case?
Hi
I got a code base with the following indentation style for break within
switch/case:
---%<---
#include
int main(void)
{
const char *c = "XX";
int out = 0;
switch (c[0]) {
case 'X': if (strcmp(c, "XX")) out = 1; break; /* ok */
case 'Y': if (strcmp(c, "XY") &&
!strcmp(c, "YY")
) out = 1; break; /* not ok ? */
}
}
---%<---
With
$ gcc --version
gcc (GCC) 7.1.1 20170622 (Red Hat 7.1.1-3)
I get the following with -Wall or -Wmisleading-indentation on:
> d.c: In function 'main':
> d.c:10:13: warning: this 'if' clause does not guard...
> [-Wmisleading-indentation]
>case 'Y': if (strcmp(c, "XY") &&
> ^~
> d.c:12:14: note: ...this statement, but the latter is misleadingly indented
> as if it were guarded by the 'if'
>) out = 1; break;
> ^
> d.c:6:7: warning: variable 'out' set but not used [-Wunused-but-set-variable]
>int out = 0;
>^~~
Droping/aligning the second break on its own line silences the warning,
but I see no reason to do so. Pls. advise!
Stefan
RE: [RFC v2] MIPS ABI Extension for IEEE Std 754 Non-Compliant Interlinking
Hi Matthew, On Fri, 11 Nov 2016, Matthew Fortune wrote: > This means that a user consciously creating an object that 'needs' ieee > compliance via use of -fieee=strict or -mieee=strict is thwarted by the > next user who builds the executable. This kind of scenario can occur with > a static library prepared by an expert in floating point and then someone > casually including that into a bigger application. Obviously a similar > issue is present with the rules around executable and shared libraries > where the executable's compliance mode can override a shared library > but at this level we are not losing any information and the executable > has either very specifically been set to 'relaxed' mode or the kernel > has set legacy to mean relaxed. The latter can at least be fixed by > changing the kernel. Losing information in a static link cannot be > fixed. I think I can see your point and I admit I may have oversimplified the model, losing a piece of crucial information and consequently control. What I can propose is a changed model which requires three states at compilation/assembly, and then four states at link/load time automatically determined by the input objects, with a possible influence of linker command-line options to prevent certain transitions. These are (names up to discussion): 1. Strict -- known to require the NaN encodings to match, 2. Unknown -- may or may not require the NaN encodings to match, 3. Unneeded -- known not to require the NaN encodings to match -- at compilation/assembly and: A. Strict -- enforcing matching NaN encodings -- built from strict, unknown and unneeded objects of the matching NaN encoding, B. Unknown -- matching the NaN encodings, but not enforcing it -- built from unknown and unneeded objects of the matching NaN encoding, C. Unneeded -- not requiring the NaN encodings to match -- built from only unneeded objects of the matching NaN encoding, D. Relaxed -- known not to match either NaN encoding -- built from unknown and unneeded objects of which at least one does not match the NaN encoding of the remaining objects, or from at least one relaxed object. -- at link/load time. Any other object combinations would result in a link/load failure, e.g. you could not mix A with a D object, or any object not matching the NaN encoding. The difference between B and C is at the run time -- the treatment of B is controlled by the "ieee754=" kernel option, whereas C always ignores NaN compatibility of the hardware. The difference between C and D is at the link/load time -- C can be upgraded to A or B, but D is inherently lost and remains at D. At the ELF binary level B objects correspond to what I previously referred to as legacy objects, i.e. no extra annotation beyond the EF_MIPS_NAN2008 bit. There could be a linker command-line option to prevent a transition from B to D from happening if not desired, causing a link failure. The states would be maintained at run-time, when a DSO is dlopen(3)ed. A would accept A, B or C if matching the NaN encoding, and stay at A. B would accept B or C if matching the NaN encoding, and stay at B. With the relaxed kernel configuration B would also accept B or C using the opposite NaN encoding or D, and switch to D. C would accept C if matching the NaN encoding, and stay at C. C would accept B if matching the NaN encoding, and switch to B. C would accept B or C using the opposite NaN encoding or D, and switch to D. Any other combinations would cause a dlopen(3) failure. In this model only the initial state is determined by the main executable and further transitions are possible as dynamic objects are added, making the use of prctl(3) to switch states more prominent. One unfortunate consequence is that dlopen(3)ing an A DSO from a B or C executable switches its state to A permanently making it impossible to subsequently dlopen(3) a D DSO even though it would have be allowed beforehand. Perhaps it would be possible to track state transitions and restore the B or C state as appropriate when the A DSO is dlclose(3)d. Likewise with B or C to D and C to B state transitions. In this model I think I would recommend distributions to have the compiler configured for 2 by default, so that user-built software comes out as B (with a link-time transition to D disallowed by default), however distributed software compiled as 3 and consequently linked as C, with any pieces identified as doing proper math compiled as 1 and consequently linked as A, for both NaN encodings if required. The reason is I think we need to draw a line somewhere and conclude that while we can try to minimise the damage caused by the hardware peculiarities created by the architecture maintainers we cannot prevent all cases of bad software builds caused by gross incompetence. Does this model match your expectations? If so, then I'll work on a specification update and a corresponding user interfa
Successful bootstrap and install of gcc (GCC) 7.2.0 on aarch64-unknown-linux-gnu
Hi, Here's a report of a successful build and install of GCC: $ gcc-7.2.0/config.guess aarch64-unknown-linux-gnu $ newcompiler/bin/gcc -v Using built-in specs. COLLECT_GCC=newcompiler/bin/gcc COLLECT_LTO_WRAPPER=/home/aaro/gcctest/newcompiler/libexec/gcc/aarch64-unknown-linux-gnu/7.2.0/lto-wrapper Target: aarch64-unknown-linux-gnu Configured with: ../gcc-7.2.0/configure --with-arch=armv8-a+crc --with-cpu=cortex-a53 --enable-fix-cortex-a53-835769 --enable-fix-cortex-a53-843419 --disable-multilib --disable-nls --prefix=/home/aaro/gcctest/newcompiler --enable-languages=c,c++ --host=aarch64-unknown-linux-gnu --build=aarch64-unknown-linux-gnu --target=aarch64-unknown-linux-gnu --with-system-zlib --with-sysroot=/ Thread model: posix gcc version 7.2.0 (GCC) -- Build environment -- host: raspberrypi-3 distro: los.git rootfs=f834d native=f834d kernel: Linux 4.12.0-rpi3-los_f834d binutils: GNU binutils 2.29 make: GNU Make 4.2.1 libc: GNU C Library (GNU libc) stable release version 2.25 zlib: 1.2.11 mpfr: 3.1.3 gmp: 60102 -- Time consumed -- configure: real0m 20.41s user0m 14.17s sys 0m 3.97s bootstrap: real7h 57m 07s user25h 28m 25s sys 40m 4.21s install:real6m 8.02s user0m 32.07s sys 0m 32.38s -- Hardware details --- MemTotal: 942112 kB processor : 0 BogoMIPS: 38.40 Features: fp asimd evtstrm crc32 cpuid CPU implementer : 0x41 CPU architecture: 8 CPU variant : 0x0 CPU part: 0xd03 CPU revision: 4 processor : 1 BogoMIPS: 38.40 Features: fp asimd evtstrm crc32 cpuid CPU implementer : 0x41 CPU architecture: 8 CPU variant : 0x0 CPU part: 0xd03 CPU revision: 4 processor : 2 BogoMIPS: 38.40 Features: fp asimd evtstrm crc32 cpuid CPU implementer : 0x41 CPU architecture: 8 CPU variant : 0x0 CPU part: 0xd03 CPU revision: 4 processor : 3 BogoMIPS: 38.40 Features: fp asimd evtstrm crc32 cpuid CPU implementer : 0x41 CPU architecture: 8 CPU variant : 0x0 CPU part: 0xd03 CPU revision: 4 A.
Successful bootstrap and install of gcc (GCC) 7.2.0 on armv7l-unknown-linux-gnueabi
Hi, Here's a report of a successful build and install of GCC: $ gcc-7.2.0/config.guess armv7l-unknown-linux-gnueabi $ newcompiler/bin/gcc -v Using built-in specs. COLLECT_GCC=newcompiler/bin/gcc COLLECT_LTO_WRAPPER=/home/aaro/gcctest/newcompiler/libexec/gcc/arm-unknown-linux-gnueabi/7.2.0/lto-wrapper Target: arm-unknown-linux-gnueabi Configured with: ../gcc-7.2.0/configure --with-arch=armv4t --with-float=soft --disable-nls --prefix=/home/aaro/gcctest/newcompiler --enable-languages=c,c++ --host=arm-unknown-linux-gnueabi --build=arm-unknown-linux-gnueabi --target=arm-unknown-linux-gnueabi --with-system-zlib --with-sysroot=/ Thread model: posix gcc version 7.2.0 (GCC) -- Build environment -- host: raspberrypi-2 distro: los.git rootfs=f834d native=f834d kernel: Linux 4.12.0-rpi2-los_f834d binutils: GNU binutils 2.29 make: GNU Make 4.2.1 libc: GNU C Library (GNU libc) stable release version 2.25 zlib: 1.2.11 mpfr: 3.1.3 gmp: 60102 -- Time consumed -- configure: real0m 24.25s user0m 25.06s sys 0m 7.22s bootstrap: real13h 19m 32s user44h 1m 40s sys 2h 2m 45s install:real9m 6.08s user3m 25.60s sys 6m 53.32s -- Hardware details --- MemTotal: 983548 kB processor : 0 model name : ARMv7 Processor rev 5 (v7l) BogoMIPS: 38.40 Features: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x0 CPU part: 0xc07 CPU revision: 5 processor : 1 model name : ARMv7 Processor rev 5 (v7l) BogoMIPS: 38.40 Features: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x0 CPU part: 0xc07 CPU revision: 5 processor : 2 model name : ARMv7 Processor rev 5 (v7l) BogoMIPS: 38.40 Features: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x0 CPU part: 0xc07 CPU revision: 5 processor : 3 model name : ARMv7 Processor rev 5 (v7l) BogoMIPS: 38.40 Features: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x0 CPU part: 0xc07 CPU revision: 5 Hardware: BCM2835 Revision: A.
Successful bootstrap and install of gcc (GCC) 7.2.0 on mips64el-unknown-linux-gnu
Hi, Here's a report of a successful build and install of GCC: $ gcc-7.2.0/config.guess mips64el-unknown-linux-gnu $ newcompiler/bin/gcc -v Using built-in specs. COLLECT_GCC=newcompiler/bin/gcc COLLECT_LTO_WRAPPER=/home/aaro/gcctest/newcompiler/libexec/gcc/mipsel-unknown-linux-gnu/7.2.0/lto-wrapper Target: mipsel-unknown-linux-gnu Configured with: ../gcc-7.2.0/configure --with-arch=loongson2f --with-abi=32 --with-fp-32=xx --enable-targets=all --disable-nls --prefix=/home/aaro/gcctest/newcompiler --enable-languages=c,c++ --host=mipsel-unknown-linux-gnu --build=mipsel-unknown-linux-gnu --target=mipsel-unknown-linux-gnu --with-system-zlib --with-sysroot=/ Thread model: posix gcc version 7.2.0 (GCC) -- Build environment -- host: fuloong-minipc distro: los.git rootfs=f834d native=f834d kernel: Linux 4.12.0-lemote-los_f834d binutils: GNU binutils 2.29 make: GNU Make 4.2.1 libc: GNU C Library (GNU libc) stable release version 2.25 zlib: 1.2.11 mpfr: 3.1.3 gmp: 60102 -- Time consumed -- configure: real0m 24.30s user0m 15.87s sys 0m 6.24s bootstrap: real55h 51m 33s user51h 46m 38s sys 3h 14m 16s install:real16m 8.47s user6m 3.60s sys 7m 26.03s -- Hardware details --- MemTotal: 493856 kB system type : lemote-fuloong-2f-box machine : Unknown processor : 0 cpu model : ICT Loongson-2 V0.3 FPU V0.1 BogoMIPS: 528.38 wait instruction: yes microsecond timers : yes tlb_entries : 64 extra interrupt vector : no hardware watchpoint : yes, count: 0, address/irw mask: [] isa : mips2 mips3 ASEs implemented: shadow register sets: 1 kscratch registers : 0 package : 0 core: 0 VCED exceptions : not available VCEI exceptions : not available A.
Successful bootstrap and install of gcc (GCC) 7.2.0 on x86_64-pc-linux-gnu
Hi, Here's a report of a successful build and install of GCC: $ gcc-7.2.0/config.guess x86_64-pc-linux-gnu $ newcompiler/bin/gcc -v Using built-in specs. COLLECT_GCC=newcompiler/bin/gcc COLLECT_LTO_WRAPPER=/home/aaro/gcctest/newcompiler/libexec/gcc/x86_64-unknown-linux-gnu/7.2.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc-7.2.0/configure --with-arch=nocona --disable-multilib --disable-nls --prefix=/home/aaro/gcctest/newcompiler --enable-languages=c,c++,go --host=x86_64-unknown-linux-gnu --build=x86_64-unknown-linux-gnu --target=x86_64-unknown-linux-gnu --with-system-zlib --with-sysroot=/ Thread model: posix gcc version 7.2.0 (GCC) -- Build environment -- host: amd-fx-6350 distro: los.git rootfs=f834d native=f834d kernel: Linux 4.12.0-pc-los_f834d binutils: GNU binutils 2.29 make: GNU Make 4.2.1 libc: GNU C Library (GNU libc) stable release version 2.25 zlib: 1.2.11 mpfr: 3.1.3 gmp: 60102 -- Time consumed -- configure: real0m 4.71s user0m 2.90s sys 0m 0.36s bootstrap: real43m 8.22s user3h 23m 12s sys 4m 5.79s install:real0m 5.54s user0m 9.03s sys 0m 2.61s -- Hardware details --- MemTotal: 16154112 kB processor : 0 vendor_id : AuthenticAMD cpu family : 21 model : 2 model name : AMD FX(tm)-6350 Six-Core Processor stepping: 0 microcode : 0x600081c cpu MHz : 1400.000 cache size : 2048 KB physical id : 0 siblings: 6 core id : 0 cpu cores : 3 apicid : 16 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 popcnt aes xsave avx f16c lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs xop skinit wdt lwp fma4 tce nodeid_msr tbm topoext perfctr_core perfctr_nb cpb hw_pstate vmmcall bmi1 arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold bugs: fxsave_leak sysret_ss_attrs null_seg bogomips: 7800.50 TLB size: 1536 4K pages clflush size: 64 cache_alignment : 64 address sizes : 48 bits physical, 48 bits virtual power management: ts ttp tm 100mhzsteps hwpstate cpb eff_freq_ro processor : 1 vendor_id : AuthenticAMD cpu family : 21 model : 2 model name : AMD FX(tm)-6350 Six-Core Processor stepping: 0 microcode : 0x600081c cpu MHz : 2000.000 cache size : 2048 KB physical id : 0 siblings: 6 core id : 1 cpu cores : 3 apicid : 17 initial apicid : 1 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 popcnt aes xsave avx f16c lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs xop skinit wdt lwp fma4 tce nodeid_msr tbm topoext perfctr_core perfctr_nb cpb hw_pstate vmmcall bmi1 arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold bugs: fxsave_leak sysret_ss_attrs null_seg bogomips: 7910.78 TLB size: 1536 4K pages clflush size: 64 cache_alignment : 64 address sizes : 48 bits physical, 48 bits virtual power management: ts ttp tm 100mhzsteps hwpstate cpb eff_freq_ro processor : 2 vendor_id : AuthenticAMD cpu family : 21 model : 2 model name : AMD FX(tm)-6350 Six-Core Processor stepping: 0 microcode : 0x600081c cpu MHz : 3900.000 cache size : 2048 KB physical id : 0 siblings: 6 core id : 2 cpu cores : 3 apicid : 18 initial apicid : 2 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 popcnt aes xsave avx f16c lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4
gcc-7-20170824 is now available
Snapshot gcc-7-20170824 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/7-20170824/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 7 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-7-branch revision 251342 You'll find: gcc-7-20170824.tar.xzComplete GCC SHA256=07a0bed8c2b6960a73d95859ba3bf03c8de2df7911f0f4f4ed468e457d3014fe SHA1=598de6fed53d634a02b589ddc75a6ed9dc0a9ebf Diffs from 7-20170817 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-7 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.
