Generated Release Notes for linaro-GCC-6.3-2017.02-rc2.

1 files changed, 18 insertions, 12 deletions

diff --git a/components/toolchain/binaries/README.textile b/components/toolchain/binaries/README.textile
index b5701e4..78da51d 100644
--- a/components/toolchain/binaries/README.textile
+++ b/components/toolchain/binaries/README.textile
@@ -30,7 +30,7 @@ Previous releases are at:
 p((((. "http://releases.linaro.org/components/toolchain/binaries/":http://releases.linaro.org/components/toolchain/binaries/
 
 
-A description of what each ABI or triplet is can be found at:
+A description of the arm and Aarch64 target triples can be found at:
 
 p((((. "https://collaborate.linaro.org/display/TCWGPUB/ARM+and+AArch64+Target+Triples":https://collaborate.linaro.org/display/TCWGPUB/ARM+and+AArch64+Target+Triples
 
@@ -83,7 +83,17 @@ p((((. "http://git.linaro.org/toolchain":http://git.linaro.org/toolchain
 h2. NEWS for GCC 6 (as of Linaro GCC 6.3-2017.02-rc2)
 
 
-* 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 issue only affected 32-bit arm targets.  This regression has been fixed upstream and backported into Linaro GCC 6.3-2017.02-rc2.
+* 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.
+
+
+p(((. 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).
+
+p(((. "https://review.linaro.org/#/c/16968/2":https://review.linaro.org/#/c/16968/2
+
+
+p(((. This change should not break compatibility between existing binaries compiled with these toolchains since the float-point parameter passing ABI is still the same.
+
+* 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 inconsistent function invocation when invoking directly vs. invoking via function pointer.  This issue only affected 32-bit arm targets.  This regression has been fixed upstream and backported into Linaro GCC 6.3-2017.02-rc2.
 
 
 p(((. GCC PR target/78253: [5/6/7 Regression] [ARM] call weak function instead of strong when called through pointer.
@@ -91,6 +101,12 @@ p(((. GCC PR target/78253: [5/6/7 Regression] [ARM] call weak function instead o
 p(((. "https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78253":https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78253
 
 
+p(((. Linaro bugzilla #2562:
+ARM GCC 5.2 call weak function instead of strong when called through pointer
+
+p(((. "https://bugs.linaro.org/show_bug.cgi?id=2562":https://bugs.linaro.org/show_bug.cgi?id=2562
+
+
 * MS Windows does not support symlinks and the MS Windows archive extractor does not properly deep copy the symlink target files/directories into the symlinked directory structure when unpacking the toolchain archive.  This causes problems with missing dependencies when using the Linaro mingw toolchains, as identified in the following bugs:
 
 
@@ -106,16 +122,6 @@ p(((. This has been solved by copying files rather than using symlinks when the
 p(((. "https://review.linaro.org/#/c/16415/":https://review.linaro.org/#/c/16415/
 
 
-* 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.
-
-
-p(((. 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).
-
-p(((. "https://review.linaro.org/#/c/16968/2":https://review.linaro.org/#/c/16968/2
-
-
-p(((. This change should not break compatibility between existing binaries compiled with these toolchains since the float-point parameter passing ABI is still the same.
-
 * Users of Linaro's toolchain have encountered problems when building projects with Autotools (specifically libtool):