Index: chapter05/gcc-pass1.xml
===================================================================
--- chapter05/gcc-pass1.xml	(revision 0bf4dfe63c985c180eaa7feadf6a4703f2dc9fd4)
+++ chapter05/gcc-pass1.xml	(revision 8a8177f9b93774426694ffd5b72e4f8aef4f316d)
@@ -105,4 +105,8 @@
 
 <screen><userinput remap="pre">sed -i '/k prot/agcc_cv_libc_provides_ssp=yes' gcc/configure</userinput></screen>
+
+    <para>Also fix a problem identified upstream:</para>
+
+<screen><userinput remap="pre">sed -i 's/if \((code.*))\)/if (\1 \&amp;\&amp; \!DEBUG_INSN_P (insn))/' gcc/sched-deps.c</userinput></screen>
 
     <para>The GCC documentation recommends building GCC outside of the
Index: chapter05/gcc-pass2.xml
===================================================================
--- chapter05/gcc-pass2.xml	(revision 0bf4dfe63c985c180eaa7feadf6a4703f2dc9fd4)
+++ chapter05/gcc-pass2.xml	(revision 8a8177f9b93774426694ffd5b72e4f8aef4f316d)
@@ -95,4 +95,8 @@
 tar -xf ../mpc-&mpc-version;.tar.gz
 mv -v mpc-&mpc-version; mpc</userinput></screen>
+
+    <para>As in the first build of GCC, fix a problem identified upstream:</para>
+
+<screen><userinput remap="pre">sed -i 's/if \((code.*))\)/if (\1 \&amp;\&amp; \!DEBUG_INSN_P (insn))/' gcc/sched-deps.c</userinput></screen>
 
     <para>Create a separate build directory again:</para>
Index: chapter06/gcc.xml
===================================================================
--- chapter06/gcc.xml	(revision 0bf4dfe63c985c180eaa7feadf6a4703f2dc9fd4)
+++ chapter06/gcc.xml	(revision 8a8177f9b93774426694ffd5b72e4f8aef4f316d)
@@ -41,4 +41,9 @@
   <sect2 role="installation">
     <title>Installation of GCC</title>
+
+    <para>As in Chapter 5, fix a problem identified upstream:</para>
+
+<screen><userinput remap="pre">sed -i 's/if \((code.*))\)/if (\1 \&amp;\&amp; \!DEBUG_INSN_P (insn))/' gcc/sched-deps.c</userinput></screen>
+
 <!--
     <para>First fix a problem identified upstream that causes some 
@@ -131,8 +136,8 @@
 
     <para>A few unexpected failures cannot always be avoided. The GCC developers
-    are usually aware of these issues, but have not resolved them yet. In
+    are usually aware of these issues, but have not resolved them yet. <!-- In
     particular, the <filename class="libraryfile">libmudflap</filename> tests
     are known to be particularly problematic as a result of a bug in GCC
-    (<ulink url="http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20003"/>).
+    (<ulink url="http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20003"/>). -->
     Unless the test results are vastly different from those at the above URL,
     it is safe to continue.</para>
@@ -322,5 +327,5 @@
         <seg>libasan.{a,so}, libatomic.{a,so}, libgcc.a, libgcc_eh.a, 
         libgcc_s.so, libgcov.a, libgomp.{a,so}, libiberty.a, libitm.{a,so},
-        liblto_plugin.so, libmudflap.{a,so}, libmudflapth.{a,so},
+        liblto_plugin.so, 
         libquadmath.{a,so}, libssp.{a,so},
         libssp_nonshared.a, libstdc++.{a,so}, libsupc++.a and libtsan.{a,so}</seg>
@@ -502,5 +507,5 @@
         </listitem>
       </varlistentry>
-
+<!--
       <varlistentry id="libmudflap">
         <term><filename class="libraryfile">libmudflap</filename></term>
@@ -513,5 +518,5 @@
         </listitem>
       </varlistentry>
-
+-->
       <varlistentry id="libquadmath">
         <term><filename class="libraryfile">libquadmath</filename></term>
Index: chapter06/pkgmgt.xml
===================================================================
--- chapter06/pkgmgt.xml	(revision 0bf4dfe63c985c180eaa7feadf6a4703f2dc9fd4)
+++ chapter06/pkgmgt.xml	(revision 8a8177f9b93774426694ffd5b72e4f8aef4f316d)
@@ -52,12 +52,8 @@
     <itemizedlist>
       <listitem>
-        <para>If one of the toolchain packages (Glibc, GCC or Binutils) needs
-        to be upgraded to a newer minor version, it is safer to rebuild LFS.
-        Though you <emphasis>may</emphasis> be able to get by rebuilding all
-        the packages in their dependency order, we do not recommend it. For
-        example, if glibc-2.2.x needs to be updated to glibc-2.3.x, it is safer
-        to rebuild. For micro version updates, a simple reinstallation usually
-        works, but is not guaranteed. For example, upgrading from glibc-2.3.4
-        to glibc-2.3.5 will not usually cause any problems.</para>
+        <para>If Glibc needs to be upgraded to a newer version, (e.g.  from
+        glibc-2.19 to glibc-2.20, it is safer to rebuild LFS.  Though you
+        <emphasis>may</emphasis> be able to rebuild all the packages in their
+        dependency order, we do not recommend it.  </para>
       </listitem>
 
