Added NEWS items for releases/linaro-6.3-2017.02-rc2.

1 files changed, 26 insertions, 20 deletions

diff --git a/components/toolchain/binaries/README.textile.series b/components/toolchain/binaries/README.textile.series
index f228ad6..2db798d 100644
--- a/components/toolchain/binaries/README.textile.series
+++ b/components/toolchain/binaries/README.textile.series
@@ -72,60 +72,66 @@ Linaro GDB 7.12 (gdb-7.12-branch)
 # for continuation lines that are not bulletted.
 {% block news %}
 
-{# Uncomment this in -rc2, because this fix isn't scheduled until then.
 {% call format("news") -%}
-Included GCC fix for upstream bugzilla PR target/78253: [5/6/7 Regression] [ARM] call weak function instead of strong when called through pointer
+A bug/regression in the compiler has been identified whereby the target function that is invoked when calling a "weak" function directly is the "strong" override, whereas when calling the function via a pointer the "weak" implementation is used.  This would be noticed as inconsisent function invocation when invoking directly vs. invoking via function pointer.  This regression has been fixed upstream and backported into Linaro GCC 6.3-2017.02-rc2.
+{% endcall %}
+{% call format("newscont") -%}
+GCC PR target/78253: [5/6/7 Regression] [ARM] call weak function instead of strong when called through pointer
 {% endcall %}
 
 {{ urlind(6,"https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78253") }}
--#}
 
 {% call format("news") -%}
-The mingw toolchains are now archived using the rsync -L option in order to avoid problems with Windows extractors and symbolic links.
+MS Windows does not support symlinks and extractors do not always handle them correctly (by copying) when unpacking archives that contain them.  The Linaro binary toolchain MS Windows extractor did not properly copy the symlinks target files/directories into the necessary directory structure when unpacking the toolchain archive which caused problems with missing dependencies for the following users of the Linaro mingw toolchains:
 {% endcall %}
 
-{{ urlind(6,"https://review.linaro.org/#/c/16415/") }}
+{{ urlind(6,"https://bugs.linaro.org/show_bug.cgi?id=2684") }}
+{{ urlind(6,"https://bugs.linaro.org/show_bug.cgi?id=2192") }}
+{{ urlind(6,"https://bugs.linaro.org/show_bug.cgi?id=2762") }}
 
 {% call format("newscont") -%}
-This resolves the following user bugs:
+This has been solved by copying files rather than using symlinks when the mingw targetted toolchain archives are created.
 {% endcall %}
 
-{{ urlind(6,"https://bugs.linaro.org/show_bug.cgi?id=2684") }}
-{{ urlind(6,"https://bugs.linaro.org/show_bug.cgi?id=2192") }}
-{{ urlind(6,"https://bugs.linaro.org/show_bug.cgi?id=2762") }}
+{{ urlind(6,"https://review.linaro.org/#/c/16415/") }}
 
 {% call format("news") -%}
-The soft-float targeted toolchains have now been configured to generate code using -mfloat-abi=soft.
+Previous versions of the Linaro GCC 6 toolchain were incorrectly generating floating-point code for soft-float Linux targets (arm-linux-gnueabi, and armeb-linux-gnueabi).  This escaped detection until recently because the soft-float targeted toolchains were configured to use general-purpose registers for passing floating-point values (which is what you would expect for soft-float toolchains) and the intra-routine floating-code was not noticed.
 {% endcall %}
 
 {% call format("newscont") -%}
-This makes arm-linux-gnueabi and armeb-linux-gnueabi toolchains use the "soft" FP ABI instead of "softfp".
+The issue would only show up on targets that were run on hardware that truly didn't have floating-point hardware where the kernel did not trap and emulate floating-point routines.  This has been solved in Linaro GCC 6.3-2017.02-rc2 by configuring the toolchain (using --with-float=soft) to generate code without any floating-point instructions at all (-mfloat-abi=soft).
 {% endcall %}
 
-{% call format("newscont") -%}
-Historically, TCWG's toolchains provided both "soft" and "softfp" multilibs, but when switching from crosstool-ng to cbuildv2/abe (which support a single multilib) "softfp" multilib was choosen.  Using "-mfloat-abi=soft" is a better choice for a gnueabi toolchain, since it doesn't require cores to have a floating-point unit.
-{% endcall %}
+{{ urlind(6,"https://review.linaro.org/#/c/16968/2") }}
 
 {% call format("newscont") -%}
-This change should not break compatibility for toolchain users since the ABI will stay the same.  The compiler and glibc libraries will not refernce FP instructions.
+This change should not break compatibility between existing binaries compiled with these toolchains since the float-point parameter passing ABI is still the same.
 {% endcall %}
 
 {% call format("news") %}
-Removed .la files from binary toolchain archive as these files break autotools builds.
+Users of Linaro's toolchain have encountered problems when building projects with Autotools (specifically libtool):
 {% endcall %}
 
 {{ urlind(6,"https://bugs.linaro.org/show_bug.cgi?id=2764") }}
 
-{% call format("news") %}
-The Linaro GCC 6.3-2017.01 snapshot added further enablement for ARMv8-M.
+{% call format("newscont") %}
+The Linaro binary toolchain releases contain *.la files, which are artifacts of the toolchain build process.  These .la files are helper files for libtool, but unlike a gcc install tree, they are not position independent and contain full paths.  Since these artifacts contain absolute paths they can actually 'mislead' user invocation of libtool into not finding required libraries (because they reference the build tree, not the install location) and hence breaking Autotools builds.  These *.la file artifacts have been removed from Linaro toolchain binaries because they are unnecessary for users.
 {% endcall %}
 
+
 {% call format("news") %}
-The Linaro GCC 6.2-2016.12 snapshot added various AArch64 bugfixes and optimizations.
+The Linaro GCC 6.3-2017.01 snapshot added further enablement for ARMv8-M and these have been incorporated into this release.
 {% endcall %}
 
 {% call format("news") -%}
-Backported glibc patch to simplify static malloc interposition [BZ #20432] to correct user identified issue.
+Compiling and statically linking some SPEC2006int tests against tcmalloc have been failing due to a problem with glibc's memory allocator function overrides.  This was fixed upstream:
+{% endcall %}
+
+{{ urlind(6,"https://sourceware.org/bugzilla/show_bug.cgi?id=20432") }}
+
+{% call format("newscont") -%}
+Backported into Linaro glibc 2.23:
 
 commit 058b5a41d56b9a8860dede14d97dd443792d064b
 Author: Florian Weimer <fweimer@redhat.com>