diff --git a/chapter05/gcc-pass1.xml b/chapter05/gcc-pass1.xml
index b0fd383f8..49612eba7 100644
--- a/chapter05/gcc-pass1.xml
+++ b/chapter05/gcc-pass1.xml
@@ -105,6 +105,10 @@ done</userinput></screen>
 
 <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
     source directory in a dedicated build directory:</para>
 
diff --git a/chapter05/gcc-pass2.xml b/chapter05/gcc-pass2.xml
index 1dce58834..1bd4c4a20 100644
--- a/chapter05/gcc-pass2.xml
+++ b/chapter05/gcc-pass2.xml
@@ -95,6 +95,10 @@ mv -v gmp-&gmp-extracted-version; gmp
 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>
 
 <screen><userinput remap="pre">mkdir -v ../gcc-build
diff --git a/chapter06/gcc.xml b/chapter06/gcc.xml
index e7efba79a..8dc997b01 100644
--- a/chapter06/gcc.xml
+++ b/chapter06/gcc.xml
@@ -40,6 +40,11 @@
 
   <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 
     programs to fail:</para>
@@ -130,10 +135,10 @@ cd ../gcc-build</userinput></screen>
     url="&test-results;"/> and <ulink url="http://gcc.gnu.org/ml/gcc-testresults/"/>.</para>
 
     <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>
 
@@ -321,7 +326,7 @@ mv -v /usr/lib/*gdb.py /usr/share/gdb/auto-load/usr/lib</userinput></screen>
 
         <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>
 
@@ -501,7 +506,7 @@ mv -v /usr/lib/*gdb.py /usr/share/gdb/auto-load/usr/lib</userinput></screen>
           </indexterm>
         </listitem>
       </varlistentry>
-
+<!--
       <varlistentry id="libmudflap">
         <term><filename class="libraryfile">libmudflap</filename></term>
         <listitem>
@@ -512,7 +517,7 @@ mv -v /usr/lib/*gdb.py /usr/share/gdb/auto-load/usr/lib</userinput></screen>
           </indexterm>
         </listitem>
       </varlistentry>
-
+-->
       <varlistentry id="libquadmath">
         <term><filename class="libraryfile">libquadmath</filename></term>
         <listitem>
diff --git a/chapter06/pkgmgt.xml b/chapter06/pkgmgt.xml
index 67ffd1cd7..b4734aba0 100644
--- a/chapter06/pkgmgt.xml
+++ b/chapter06/pkgmgt.xml
@@ -51,14 +51,10 @@
 
     <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>
 
       <listitem>