Hi,
the attached patch mentions some changes in the Fortran frontend for
the GCC 7 cycle, and also adds the so-far missing
gcc-7/porting_to.html file.
(I added <!DOCTYPE html> and <meta charset="UTF-8"> tags to the
porting_to.html file, which is apparently what is recommended these
days; I didn't add this to any existing file)
Ok to commit?
--
Janne Blomqvist
Index: changes.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-7/changes.html,v
retrieving revision 1.32
diff -p -u -r1.32 changes.html
--- changes.html 27 Nov 2016 12:54:13 -0000 1.32
+++ changes.html 3 Jan 2017 08:26:59 -0000
@@ -338,6 +338,25 @@ of the global declaration:</p>
derived-type variables.
</li>
+ <li>
+ The <code>RANDOM_NUMBER</code> algorithm has been replaced, and
+ now has per-thread state allowing scalable random number
+ generation in multi-threaded programs.
+ </li>
+
+ <li>
+ Fortran 2003 User Defined Derived-Type IO (DTIO) is now fully supported.
+ </li>
+
+ <li>
+ Character lengths are now internally handled as
+ an <code>INTEGER(kind=C_SIZE_T)</code> variable, allowing
+ characters with more than <code>2**31</code> elements on 64-bit
+ targets. Please see <a href="porting_to.html">the GCC 7
+ porting</a> documentation if you need to call Fortran procedures
+ from C.
+ </li>
+
</ul>
<!-- <h3 id="go">Go</h3> -->
Index: porting_to.html
===================================================================
RCS file: porting_to.html
diff -N porting_to.html
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ porting_to.html 3 Jan 2017 08:26:59 -0000
@@ -0,0 +1,80 @@
+<!DOCTYPE html>
+<html>
+<head>
+<meta charset="UTF-8">
+<title>Porting to GCC 7</title>
+</head>
+
+<body>
+<h1>Porting to GCC 7</h1>
+
+<p>
+The GCC 7 release series differs from previous GCC releases in
+<a href="changes.html">a number of ways</a>. Some of
+these are a result of bug fixing, and some old behaviors have been
+intentionally changed in order to support new standards, or relaxed
+in standards-conforming ways to facilitate compilation or run-time
+performance. Some of these changes are not visible to the naked eye
+and will not cause problems when updating from older versions.
+</p>
+
+<p>
+However, some of these changes are visible, and can cause grief to
+users porting to GCC 7. This document is an effort to identify major
+issues and provide clear solutions in a quick and easily searched
+manner. Additions and suggestions for improvement are welcome.
+</p>
+
+
+<h2 id="cpp">Preprocessor issues</h2>
+
+
+<h2 id="c">C language issues</h2>
+
+
+<h2 id="cxx">C++ language issues</h2>
+
+<h2 id="fortran">Fortran language issues</h2>
+
+<p>
+The library ABI version has been increased, necessitating a
+recompilation of all Fortran code.
+
+<p>
+Character lengths are now handled as
+an <code>INTEGER(kind=C_SIZE_T)</code> variable whose size is
+dependent on the target system, allowing characters longer than 2**31
+on 64-bit targets. Prior to GCC 7, the character length was
+an <code>INTEGER(kind=4)</code> variable on all targets. If calling a
+Fortran procedure with character arguments from C without using the
+standard ISO_C_BINDING feature, the hidden character length argument
+at the end of the argument list must thus be modified to be of
+type <code>size_t</code> rather than of type <code>int</code>. For
+instance, calling the Fortran subroutine
+
+<pre><code>
+subroutine fstrlen (s, a)
+ use iso_c_binding, only: k => c_size_t
+ character(len=*) :: s
+ integer :: a
+ print*, len(s, kind=c_size_t)
+end subroutine fstrlen
+</code></pre>
+
+from C in a way that is compatible with older GFortran versions can be
+done by defining the prototype as follows:
+
+<pre><code>
+#if __GNUC__ > 6
+typedef size_t fortran_charlen_t;
+#else
+typedef int fortran_charlen_t;
+#endif
+
+void fstrlen_ (char*, int*, fortran_charlen_t);
+</code></pre>
+
+<h2 id="plugins">Plugin issues</h2>
+
+</body>
+</html>
