This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: PATCH: remove two old/non-FAQ entries from faq.html
- From: "Joseph S. Myers" <jsm28 at cam dot ac dot uk>
- To: Gerald Pfeifer <pfeifer at dbai dot tuwien dot ac dot at>
- Cc: <gcc-patches at gcc dot gnu dot org>
- Date: Sun, 29 Dec 2002 22:55:10 +0000 (GMT)
- Subject: Re: PATCH: remove two old/non-FAQ entries from faq.html
On Sun, 29 Dec 2002, Gerald Pfeifer wrote:
> Our FAQ is showing its age quite a bit, so here is a first set up
> updates (actually cleanups).
>
> Gerald
>
> Remove two questions from the EGCS/GCC 2.95 era: "Virtual memory
> exhausted" and "How to work around too long C++ symbol names?
> (-fsquangle</tt>)"
Conversely, there are entries from that period that are absent but linked
to from release notes (whether to #... entries that no longer exist, or
remaining links to the old FOM; target-specific entries were never
restored to faq.html). This patch deals with those by creating a separate
file for 2.95-era FAQs referenced by release notes; OK to commit? (The
entries are taken essentially verbatim from the old faq.html.)
(There are also FOM references in the libstdc++ FAQ - which the libstdc++
maintainers should deal with - and in service.texi (commented out).)
Index: egcs-1.0/caveats.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/egcs-1.0/caveats.html,v
retrieving revision 1.11
diff -u -r1.11 caveats.html
--- egcs-1.0/caveats.html 11 Feb 2002 05:57:09 -0000 1.11
+++ egcs-1.0/caveats.html 29 Dec 2002 22:46:49 -0000
@@ -22,7 +22,7 @@
<li> Some versions of the Linux kernel have bugs which prevent them
from being compiled or from running when compiled by EGCS. See
- <a href="http://gcc.gnu.org/fom_serv/cache/24.html";>the FAQ</a>
+ <a href="../gcc-2.95/faq.html#linuxkernel">the FAQ</a>
for additional information.</li>
<li> In general, EGCS is more rigorous about rejecting invalid C++ code
Index: egcs-1.1/caveats.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/egcs-1.1/caveats.html,v
retrieving revision 1.14
diff -u -r1.14 caveats.html
--- egcs-1.1/caveats.html 11 Feb 2002 09:47:47 -0000 1.14
+++ egcs-1.1/caveats.html 29 Dec 2002 22:46:49 -0000
@@ -17,7 +17,7 @@
<li> Some versions of the Linux kernel have bugs which prevent them
from being compiled or from running when compiled by EGCS. See
- <a href="http://gcc.gnu.org/fom_serv/cache/24.html";>the FAQ</a>
+ <a href="../gcc-2.95/faq.html#linuxkernel">the FAQ</a>
for additional information.</li>
<li> In general, EGCS is more rigorous about rejecting invalid C++ code
Index: gcc-2.95/caveats.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-2.95/caveats.html,v
retrieving revision 1.18
diff -u -r1.18 caveats.html
--- gcc-2.95/caveats.html 26 Jan 2002 15:15:54 -0000 1.18
+++ gcc-2.95/caveats.html 29 Dec 2002 22:46:49 -0000
@@ -11,7 +11,7 @@
<li>GCC 2.95 will issue an error for invalid asm statements that had been
silently accepted by earlier versions of the compiler. This is particularly
noticeable when compiling older versions of the Linux kernel (2.0.xx).
- Please refer to the <a href="../faq.html#asmclobber">FAQ</a> for more
+ Please refer to the <a href="faq.html#asmclobber">FAQ</a> for more
information on this issue.</li>
<li>GCC 2.95 implements type based alias analysis to disambiguate memory
@@ -20,7 +20,7 @@
GCC 2.95.
Please refer to the
- <a href="http://gcc.gnu.org/fom_serv/cache/24.html";>FAQ</a> for more
+ <a href="faq.html#linuxkernel">FAQ</a> for more
information on this issue.</li>
<li>GCC 2.95 has a known bug in its handling of complex variables for
Index: gcc-2.95/faq.html
===================================================================
RCS file: gcc-2.95/faq.html
diff -N gcc-2.95/faq.html
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ gcc-2.95/faq.html 29 Dec 2002 22:46:51 -0000
@@ -0,0 +1,132 @@
+<html>
+
+<head>
+<title>GCC 2.95 FAQ</title>
+</head>
+
+<body>
+<h1>GCC 2.95 FAQ</h1>
+
+<p>This page contains some old questions that apply to GCC 2.95.x and
+older versions only. For questions applying to current GCC, see the
+<a href="../faq.html">main GCC FAQ</a>.</p>
+
+<h2><a name="asmclobber">Problems with invalid `asm' statements</a></h2>
+
+<p>Previous releases of GCC (for example, GCC 2.7.2 or EGCS 1.1.2)
+did not detect as invalid a clobber specifier that clobbered an operand.
+Instead, it could spuriously and silently generate incorrect code for
+certain non-obvious cases of source code. Even more unfortunately, the
+manual did not explicitly say that it was invalid to specify clobber
+registers that were destined to overlap
+operands; it could arguably be interpreted that it was correct to clobber
+an input operand to mark it as not holding a usable value after the asm.</p>
+
+<p>For the general case, there is no way to tell whether a specified
+clobber is <i>intended</i> to overlap with a specific (input) operand or
+is a program error, where the choice of actual register for operands
+failed to <i>avoid</i> the clobbered register. Such unavoidable overlap
+is detected by versions GCC 2.95 and newer, and flagged
+as an error rather than accepted. An error message is given, such as:</p>
+<pre>
+ foo.c: In function `foo':
+ foo.c:7: Invalid `asm' statement:
+ foo.c:7: fixed or forbidden register 0 (ax) was spilled for class AREG.
+</pre>
+<p>Unfortunately, a lot of existing software, for example the
+<a href="#linuxkernel">Linux kernel</a> version 2.0.35 for the Intel x86,
+has constructs where input operands are marked as clobbered.</p>
+
+<p>The manual now describes how to write constructs with operands that
+are modified by the construct, but not actually used. To write an asm
+which modifies an input operand but does not output anything usable,
+specify that operand as an <b>output operand</b> outputting to an
+<b>unused dummy variable</b>.</p>
+
+<p>In the following example for the x86 architecture (taken from the Linux
+2.0.35 kernel -- <tt>include/asm-i386/delay.h</tt>), the register-class
+constraint <tt>"a"</tt> denotes a register class containing the single
+register <tt>"ax"</tt> (aka. <tt>"eax"</tt>). It is therefore invalid
+to clobber <tt>"ax"</tt>; this operand has to be specified as an output
+as well as an input. The following code is therefore <b>invalid</b>:</p>
+<pre>
+extern __inline__ void
+__delay (int loops)
+{
+ __asm__ __volatile__
+ (".align 2,0x90\n1:\tdecl %0\n\tjns 1b"
+ : /* no outputs */
+ : "a" (loops)
+ : "ax");
+}
+</pre>
+<p>It could be argued that since the register class for <tt>"a"</tt> contains
+only a single register, this could be detected as an "obvious" intended
+clobber of the input operand. While that is feasible, it opens up for
+further "obvious" cases, where the level of obviousness changes from
+person to person. As there is a correct way to write such asm constructs,
+this obviousness-detection is not needed other than for reasons of
+compatibility with an existing code-base, and that code base can be
+corrected.</p>
+<p>This corrected and clobber-less version, is <b>valid</b> for GCC 2.95
+as well as for previous versions of GCC and EGCS:</p>
+<pre>
+extern __inline__ void
+__delay (int loops)
+{
+ int dummy;
+
+ __asm__ __volatile__
+ (".align 2,0x90\n1:\tdecl %0\n\tjns 1b"
+ : "=a" (dummy)
+ : "0" (loops));
+}
+</pre>
+<p>Note that the asm construct now has an output operand, but it is unused.
+Normally asm constructs with only unused output operands may be removed by
+gcc, unless marked <tt>volatile</tt> as above.</p>
+
+
+<hr>
+<h2><a name="linuxkernel">Building Linux kernels</a></h2>
+
+<p>The linux kernel violates certain aliasing rules specified in the
+ANSI/ISO standard. Starting with GCC 2.95, the gcc optimizer
+by default relies on these rules to produce more efficient code and thus
+will produce malfunctioning kernels.
+To work around this problem, the flag <CODE>-fno-strict-aliasing</CODE>
+must be added to the <CODE>CFLAGS</CODE> variable in the main kernel Makefile.</p>
+
+<p>If you try to build a 2.0.x kernel for Intel machines with any compiler
+other than GCC 2.7.2, then you are on your own.
+The 2.0.x kernels are to be built only with
+gcc 2.7.2. They use certain <code>asm</code> constructs which are
+incorrect, but (by accident) happen to work with gcc 2.7.2. If you
+insist on building 2.0.x kernels with later versions of GCC (or egcs), you may be interested in
+this <a href="http://www.suse.de/~florian/kernel+egcs.html";>patch</a>
+which fixes some of the asm problems. You will also want to change
+asm constructs to <a href="#asmclobber">avoid clobbering their input
+operands</a>.</p>
+
+<p>If you installed a recent binutils/gas snapshot on your GNU/Linux
+system, you may not be able to build the kernel because objdump does
+not understand the "-k" switch. The solution for this problem is to
+remove /usr/bin/encaps. (This is an obsolete program that was part of
+older binutils distributions; the Linux kernel's Makefile looks for
+this program to decide if you have an old or a new binutils. Problems
+occur if you installed a new binutils but haven't removed encaps,
+because the Makefile thinks you have the old one.)</p>
+
+<p>Finally, you may get errors with the X driver of the form </p>
+<pre>
+ _X11TransSocketUNIXConnect: Can't connect: errno = 111
+</pre>
+
+<p>This is a kernel bug. The function sys_iopl in arch/i386/kernel/ioport.c
+does an illegal hack which used to work but is now broken since GCC optimizes
+more aggressively . The newer 2.1.x kernels already have a fix which should
+also work in 2.0.32.</p>
+
+
+</body>
+</html>
Index: gcc-2.95/features.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-2.95/features.html,v
retrieving revision 1.36
diff -u -r1.36 features.html
--- gcc-2.95/features.html 15 Aug 2002 00:09:07 -0000 1.36
+++ gcc-2.95/features.html 29 Dec 2002 22:46:52 -0000
@@ -23,7 +23,7 @@
in loops.</li>
<li><a href="../news/alias.html">Type based alias analysis</a> is enabled by
default. Note this feature will expose bugs in the Linux kernel. Please
- refer to the <a href="http://gcc.gnu.org/fom_serv/cache/24.html";>FAQ</a>
+ refer to the <a href="faq.html#linuxkernel">FAQ</a>
for additional information on this issue.</li>
<li>Major revamp of GIV detection, combination and simplification to
improve loop performance.</li>
--
Joseph S. Myers
jsm28@cam.ac.uk