diff mbox

[wwwdocs] Update changes.html with libstdc++ changes

Message ID alpine.LSU.2.20.1504081233230.9357@tuna.site
State New
Headers show

Commit Message

Gerald Pfeifer April 8, 2015, 11:06 a.m. UTC 
On Sat, 6 Dec 2014, Jonathan Wakely wrote:
> I'm also noting one old change in the GCC 4.5 page, and
> removing/changing some links to the C++0x status table. The list of
> features supported on trunk is fairly irrelevant to someone looking at
> the 4.4 release notes, so I've linked to the docs for the relevant
> release

This was a good change, thank you.

The only drawback of this, and some similar cases, is that we now
risk referring to older versions on a release branch.  I do not
have a good idea how to best handle this, so for now I updated
references to online documentation to the latest versions (4.8.4 
and 4.9.2, respectively).

Gerald

Comments

Jonathan Wakely April 8, 2015, 11:14 a.m. UTC | #1 
On 08/04/15 13:06 +0200, Gerald Pfeifer wrote:
>On Sat, 6 Dec 2014, Jonathan Wakely wrote:
>> I'm also noting one old change in the GCC 4.5 page, and
>> removing/changing some links to the C++0x status table. The list of
>> features supported on trunk is fairly irrelevant to someone looking at
>> the 4.4 release notes, so I've linked to the docs for the relevant
>> release
>
>This was a good change, thank you.
>
>The only drawback of this, and some similar cases, is that we now
>risk referring to older versions on a release branch.  I do not
>have a good idea how to best handle this, so for now I updated
>references to online documentation to the latest versions (4.8.4
>and 4.9.2, respectively).

Yes, I realised that problem when making the change and linking to the
versions that were current at the time. One option would be to add a
gcc-4.8 symlink that points to the latest gcc-4.8.x version, but that
adds more work for the release managers and only has a small benefit.

Alternatively, since we only tend to have four or five releases from a
branch, we could just update them manually when we remember to. That's
only necessary until the branch closes, at which point the latest
release won't change. It's not a huge problem if the links don't go
to the latest docs immediately IMHO.
Gerald Pfeifer April 20, 2015, 8:18 a.m. UTC | #2 
On Wed, 8 Apr 2015, Jonathan Wakely wrote:
>> The only drawback of this, and some similar cases, is that we now
>> risk referring to older versions on a release branch.
> Yes, I realised that problem when making the change and linking to the
> versions that were current at the time. One option would be to add a
> gcc-4.8 symlink that points to the latest gcc-4.8.x version, but that
> adds more work for the release managers and only has a small benefit.

Agreed.

> Alternatively, since we only tend to have four or five releases from a
> branch, we could just update them manually when we remember to. That's
> only necessary until the branch closes, at which point the latest
> release won't change. It's not a huge problem if the links don't go
> to the latest docs immediately IMHO.

Agreed, and agreed.  Let's just keep an eye on it and (try to)
update when a new release of an existing branch comes out.

Gerald
diff mbox

Patch

Index: gcc-4.8/changes.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.8/changes.html,v
retrieving revision 1.131
diff -u -r1.131 changes.html
--- gcc-4.8/changes.html	19 Dec 2014 11:38:57 -0000	1.131
+++ gcc-4.8/changes.html	8 Apr 2015 10:30:59 -0000
@@ -292,7 +292,7 @@ 
   <h4>Runtime Library (libstdc++)</h4>
 
   <ul>
-    <li><a href="https://gcc.gnu.org/onlinedocs/gcc-4.8.3/libstdc++/manual/manual/status.html#status.iso.2011">
+    <li><a href="https://gcc.gnu.org/onlinedocs/gcc-4.8.4/libstdc++/manual/manual/status.html#status.iso.2011">
        Improved experimental support for the new ISO C++ standard, C++11</a>,
        including:
        <ul>
Index: gcc-4.9/changes.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.9/changes.html,v
retrieving revision 1.84
diff -u -r1.84 changes.html
--- gcc-4.9/changes.html	31 Dec 2014 10:51:19 -0000	1.84
+++ gcc-4.9/changes.html	8 Apr 2015 10:31:00 -0000
@@ -128,7 +128,7 @@ 
 	and starting with the 4.9.1 release also in the Fortran compiler.
 	The new <code>-fopenmp-simd</code> option can be used to enable OpenMP's
 	SIMD directives, while ignoring other OpenMP directives. The new <a
-	href="https://gcc.gnu.org/onlinedocs/gcc-4.9.0/gcc/Optimize-Options.html#index-fsimd-cost-model-908"
+	href="https://gcc.gnu.org/onlinedocs/gcc-4.9.2/gcc/Optimize-Options.html#index-fsimd-cost-model-908"
 	><code>-fsimd-cost-model=</code></a> option permits to tune the
 	vectorization cost model for loops annotated with OpenMP and Cilk
 	Plus <code>simd</code> directives; <code>-Wopenmp-simd</code> warns when
@@ -151,7 +151,7 @@ 
   <ul>
     <li>Support for colorizing diagnostics emitted by GCC has been added.
     The <code><a
-    href="https://gcc.gnu.org/onlinedocs/gcc-4.9.0/gcc/Language-Independent-Options.html#index-fdiagnostics-color-252"
+    href="https://gcc.gnu.org/onlinedocs/gcc-4.9.2/gcc/Language-Independent-Options.html#index-fdiagnostics-color-252"
     >-fdiagnostics-color=auto</a></code> will enable it when
     outputting to terminals, <code>-fdiagnostics-color=always</code>
     unconditionally.  The <code>GCC_COLORS</code> environment variable
@@ -177,7 +177,7 @@ 
     </pre></li>
 
     <li>With the new <a
-    href="https://gcc.gnu.org/onlinedocs/gcc-4.9.0/gcc/Loop-Specific-Pragmas.html"
+    href="https://gcc.gnu.org/onlinedocs/gcc-4.9.2/gcc/Loop-Specific-Pragmas.html"
     ><code>#pragma GCC ivdep</code></a>, the user can assert that there are no
     loop-carried dependencies which would prevent concurrent execution of
     consecutive iterations using SIMD (single instruction multiple data)
@@ -383,7 +383,7 @@ 
       <li>ABI changes:
       <ul>
         <li>The <a
-          href="https://gcc.gnu.org/onlinedocs/gcc-4.9.0/gfortran/Argument-passing-conventions.html"
+          href="https://gcc.gnu.org/onlinedocs/gcc-4.9.2/gfortran/Argument-passing-conventions.html"
           >argument passing ABI</a> has changed for scalar dummy
   	  arguments of type <code>INTEGER</code>, <code>REAL</code>,
 	  <code>COMPLEX</code> and <code>LOGICAL</code>, which have
@@ -418,7 +418,7 @@ 
       controlled by the <code>-Wzerotrip</code> option, which is implied by
       <code>-Wall</code>.</li>
     <li>The new <code>NO_ARG_CHECK</code> attribute of the <a
-      href="https://gcc.gnu.org/onlinedocs/gcc-4.9.0/gfortran/GNU-Fortran-Compiler-Directives.html"
+      href="https://gcc.gnu.org/onlinedocs/gcc-4.9.2/gfortran/GNU-Fortran-Compiler-Directives.html"
       ><code>!GCC$</code> directive</a> can be used to disable the
       type-kind-rank (TKR) argument check for a dummy argument. The feature
       is similar to ISO/IEC TS 29133:2012's <code>TYPE(*)</code>, except that
@@ -452,7 +452,7 @@ 
         the execution and any exception (but inexact) is signaling, a warning is
         printed to <code>ERROR_UNIT</code>, indicating which exceptions are
         signaling. The <code><a
-        href="https://gcc.gnu.org/onlinedocs/gcc-4.9.0/gfortran/Debugging-Options.html"
+        href="https://gcc.gnu.org/onlinedocs/gcc-4.9.2/gfortran/Debugging-Options.html"
         >-ffpe-summary=</a></code> command-line option can be used to fine-tune
         for which exceptions the warning should be shown.</li>
       <li>Rounding on input (<code>READ</code>) is now handled on systems where
@@ -597,7 +597,7 @@ 
       having to compile the entire file with the <code>-mxxx</code> option.
       This improves the usability of x86 intrinsics and is particularly useful
       when doing <a
-      href="https://gcc.gnu.org/onlinedocs/gcc-4.9.0/gcc/Function-Multiversioning.html"
+      href="https://gcc.gnu.org/onlinedocs/gcc-4.9.2/gcc/Function-Multiversioning.html"
       >Function Multiversioning</a>.
     </li>
     <li>GCC now supports the new Intel microarchitecture named Silvermont