diff mbox

[wwwdocs] Re: gcc.gnu.org/simtest-howto.html (was: Question for ARM person re asm_fprintf)(

Message ID 1408136539.25011.4.camel@yam-132-YW-E178-FTW
State New
Headers show

Commit Message

Oleg Endo Aug. 15, 2014, 9:02 p.m. UTC 
On Fri, 2014-08-15 at 22:58 +0200, Oleg Endo wrote:
> On Mon, 2014-08-04 at 08:19 +0200, Oleg Endo wrote:
> > 
> > On Aug 4, 2014, at 6:00 AM, Gerald Pfeifer <gerald@pfeifer.com> wrote:
> > 
> > > On Wed, 23 Jul 2014, Hans-Peter Nilsson wrote:
> > >> The page <https://gcc.gnu.org/simtest-howto.html> is
> > >> unfortunately out of date (e.g. binutils+sim now lives in the
> > >> same git repo) but it gives you the idea.
> > > 
> > > Sooo, any volunteer to update this page?  Doesn't have to be
> > > perfect, even incremental improvements help.
> > > 
> > > Or is it bad enough that we should rather remove this unless/
> > > until someone steps up?
> > 
> > Since I'm basically doing all the testing in sh-sim, I could try to update that page.
> 
> How about the attached .html as a replacement for the current one?
> I removed the requirement of setting up a combined tree, as I believe
> it makes things much more easy.  At least it's been working for me
> that way.  Is this helpful / OK to commit?

Maybe a patch is better in this case, instead of the whole .html.

Cheers,
Oleg

Comments

Hans-Peter Nilsson Aug. 17, 2014, 8:56 p.m. UTC | #1 
On Fri, 15 Aug 2014, Oleg Endo wrote:
> > How about the attached .html as a replacement for the current one?
> > I removed the requirement of setting up a combined tree, as I believe
> > it makes things much more easy.  At least it's been working for me
> > that way.  Is this helpful / OK to commit?
>
> Maybe a patch is better in this case, instead of the whole .html.

hm no likey, this is simply changing too much and making it
SH-specific.  Also, /usr/local is the default.

brgds, H-P
Oleg Endo Aug. 18, 2014, 8:46 p.m. UTC | #2 
On Sun, 2014-08-17 at 16:56 -0400, Hans-Peter Nilsson wrote:
> On Fri, 15 Aug 2014, Oleg Endo wrote:
> > > How about the attached .html as a replacement for the current one?
> > > I removed the requirement of setting up a combined tree, as I believe
> > > it makes things much more easy.  At least it's been working for me
> > > that way.  Is this helpful / OK to commit?
> >
> > Maybe a patch is better in this case, instead of the whole .html.
> 
> hm no likey, this is simply changing too much and making it
> SH-specific.  Also, /usr/local is the default.

I thought the it would work for other targets by replacing "sh-elf" with
"$TARGET".  However, I can't test all of those.  Maybe maintainers/users
of other targets can comment on the applicability beyond SH.
I'm afraid that's all I can do for now.

Cheers,
Oleg
Hans-Peter Nilsson Aug. 18, 2014, 8:57 p.m. UTC | #3 
On Mon, 18 Aug 2014, Oleg Endo wrote:
> On Sun, 2014-08-17 at 16:56 -0400, Hans-Peter Nilsson wrote:
> > On Fri, 15 Aug 2014, Oleg Endo wrote:
> > > > How about the attached .html as a replacement for the current one?
> > > > I removed the requirement of setting up a combined tree, as I believe
> > > > it makes things much more easy.  At least it's been working for me
> > > > that way.  Is this helpful / OK to commit?
> > >
> > > Maybe a patch is better in this case, instead of the whole .html.
> >
> > hm no likey, this is simply changing too much and making it
> > SH-specific.  Also, /usr/local is the default.
>
> I thought the it would work for other targets by replacing "sh-elf" with
> "$TARGET".  However, I can't test all of those.  Maybe maintainers/users
> of other targets can comment on the applicability beyond SH.
> I'm afraid that's all I can do for now.

I'll pick this up.  After all, I'm supposedly the maintainer of
that page...  thanks.

brgds, H-P
Oleg Endo Aug. 18, 2014, 9:15 p.m. UTC | #4 
On Mon, 2014-08-18 at 16:57 -0400, Hans-Peter Nilsson wrote:
> On Mon, 18 Aug 2014, Oleg Endo wrote:
> > On Sun, 2014-08-17 at 16:56 -0400, Hans-Peter Nilsson wrote:
> > > On Fri, 15 Aug 2014, Oleg Endo wrote:
> > > > > How about the attached .html as a replacement for the current one?
> > > > > I removed the requirement of setting up a combined tree, as I believe
> > > > > it makes things much more easy.  At least it's been working for me
> > > > > that way.  Is this helpful / OK to commit?
> > > >
> > > > Maybe a patch is better in this case, instead of the whole .html.
> > >
> > > hm no likey, this is simply changing too much and making it
> > > SH-specific.  Also, /usr/local is the default.
> >
> > I thought the it would work for other targets by replacing "sh-elf" with
> > "$TARGET".  However, I can't test all of those.  Maybe maintainers/users
> > of other targets can comment on the applicability beyond SH.
> > I'm afraid that's all I can do for now.
> 
> I'll pick this up.  After all, I'm supposedly the maintainer of
> that page...  thanks.

BTW, I've just noticed that I've duplicated the 'Passing options and
running multiple testsuites' section mentioned on
https://gcc.gnu.org/install/test.html .  Maybe the sim-test page could
be simply integrated into the test.html page in a stripped down form.
Most parts of my description have actually nothing to do with
sim-testing, but are just one way of setting up a newlib based cross
toolchain.  Maybe that can be put as a cross toolchain example somewhere
else on the wwwdocs, like https://gcc.gnu.org/install/build.html

Cheers,
Oleg
Hans-Peter Nilsson Aug. 19, 2014, 11:02 a.m. UTC | #5 
On Mon, 18 Aug 2014, Oleg Endo wrote:
> On Mon, 2014-08-18 at 16:57 -0400, Hans-Peter Nilsson wrote:
> > On Mon, 18 Aug 2014, Oleg Endo wrote:
> > > On Sun, 2014-08-17 at 16:56 -0400, Hans-Peter Nilsson wrote:
> > > > On Fri, 15 Aug 2014, Oleg Endo wrote:
> > > > > > How about the attached .html as a replacement for the current one?
> > > > > > I removed the requirement of setting up a combined tree, as I believe
> > > > > > it makes things much more easy.  At least it's been working for me
> > > > > > that way.  Is this helpful / OK to commit?
> > > > >
> > > > > Maybe a patch is better in this case, instead of the whole .html.
> > > >
> > > > hm no likey, this is simply changing too much and making it
> > > > SH-specific.  Also, /usr/local is the default.
> > >
> > > I thought the it would work for other targets by replacing "sh-elf" with
> > > "$TARGET".  However, I can't test all of those.  Maybe maintainers/users
> > > of other targets can comment on the applicability beyond SH.
> > > I'm afraid that's all I can do for now.
> >
> > I'll pick this up.  After all, I'm supposedly the maintainer of
> > that page...  thanks.
>
> BTW, I've just noticed that I've duplicated the 'Passing options and
> running multiple testsuites' section mentioned on
> https://gcc.gnu.org/install/test.html .  Maybe the sim-test page could
> be simply integrated into the test.html page in a stripped down form.

There's certainly an unexpected disconnect but I think a link
would be better than inlining.

> Most parts of my description have actually nothing to do with
> sim-testing, but are just one way of setting up a newlib based cross
> toolchain.  Maybe that can be put as a cross toolchain example somewhere
> else on the wwwdocs, like https://gcc.gnu.org/install/build.html

Sounds like a good idea.  BTW, to check out the web pages to
generate patches, see <http://gcc.gnu.org/about.html#cvs>.

brgds, H-P
Oleg Endo Aug. 19, 2014, 7:33 p.m. UTC | #6 
On Tue, 2014-08-19 at 07:02 -0400, Hans-Peter Nilsson wrote:
> On Mon, 18 Aug 2014, Oleg Endo wrote:
> > On Mon, 2014-08-18 at 16:57 -0400, Hans-Peter Nilsson wrote:
> > > On Mon, 18 Aug 2014, Oleg Endo wrote:
> > > > On Sun, 2014-08-17 at 16:56 -0400, Hans-Peter Nilsson wrote:
> > > > > On Fri, 15 Aug 2014, Oleg Endo wrote:
> > > > > > > How about the attached .html as a replacement for the current one?
> > > > > > > I removed the requirement of setting up a combined tree, as I believe
> > > > > > > it makes things much more easy.  At least it's been working for me
> > > > > > > that way.  Is this helpful / OK to commit?
> > > > > >
> > > > > > Maybe a patch is better in this case, instead of the whole .html.
> > > > >
> > > > > hm no likey, this is simply changing too much and making it
> > > > > SH-specific.  Also, /usr/local is the default.
> > > >
> > > > I thought the it would work for other targets by replacing "sh-elf" with
> > > > "$TARGET".  However, I can't test all of those.  Maybe maintainers/users
> > > > of other targets can comment on the applicability beyond SH.
> > > > I'm afraid that's all I can do for now.
> > >
> > > I'll pick this up.  After all, I'm supposedly the maintainer of
> > > that page...  thanks.
> >
> > BTW, I've just noticed that I've duplicated the 'Passing options and
> > running multiple testsuites' section mentioned on
> > https://gcc.gnu.org/install/test.html .  Maybe the sim-test page could
> > be simply integrated into the test.html page in a stripped down form.
> 
> There's certainly an unexpected disconnect but I think a link
> would be better than inlining.
> 
> > Most parts of my description have actually nothing to do with
> > sim-testing, but are just one way of setting up a newlib based cross
> > toolchain.  Maybe that can be put as a cross toolchain example somewhere
> > else on the wwwdocs, like https://gcc.gnu.org/install/build.html
> 
> Sounds like a good idea.  BTW, to check out the web pages to
> generate patches, see <http://gcc.gnu.org/about.html#cvs>.

I know.  It's been in place here for a while.  See also my previous
wwwdoc commits.  I don't know how I got the funny idea to send the .html
instead of the patch before ...

Cheers,
Oleg
diff mbox

Patch

? simtest_howto.patch
Index: simtest-howto.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/simtest-howto.html,v
retrieving revision 1.29
diff -u -r1.29 simtest-howto.html
--- simtest-howto.html	27 Jun 2014 11:48:46 -0000	1.29
+++ simtest-howto.html	15 Aug 2014 21:00:31 -0000
@@ -1,9 +1,41 @@ 
-<html>
-  <head>
-    <title>How to test GCC on a simulator</title>
-  </head>
+<?xml version="1.0" encoding="utf-8"?>
+  <!DOCTYPE html
+            PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+            "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+ 
+
+
+ 
+
+
+
+
+
+
+
+
+
+
+     <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
+  
+       <head>
+ 
+    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+    <link rev="made" href="mailto:gcc@gcc.gnu.org" />
+    <link rel="shortcut icon" href="https://gcc.gnu.org/favicon.ico" />
+    <link rel="stylesheet" type="text/css" href="https://gcc.gnu.org/gcc.css" />
+  
+     <title>
+How to test GCC on a simulator
+- GNU Project - Free Software Foundation (FSF)</title>
+  
+   </head>
+ 
 
   <body>
+
+
+
     <h1>How to test GCC on a simulator</h1>
 
     <p>Several GCC targets can be tested using simulators.  These allow
@@ -11,270 +43,280 @@ 
     access to hardware, or for targets that have general characteristics
     you'd like to test, like endianness or word size.</p>
 
-    <p>All of the instructions here start out from a directory we'll
-    call <code>${TOP}</code>, which is initially empty.</p>
-
-    <h2>Set up sources</h2>
-
-    <p>Testing with a simulator requires use of a combined tree;
-    you can't easily build newlib, required for simulator testing,
-    outside of a combined tree, and the build of the other components
-    is easiest in a combined tree.</p>
-
-    <p>The combined tree contains GCC sources plus several modules of
-    the <code>src</code> tree: <code>binutils</code> and
-    <code>newlib</code> for the build and <code>sim</code> for the
-    simulators. If you already build with a combined tree you can use
-    your current setup; if not, these instructions will get you the
-    sources you need.</p>
-
-    <h3>Check out initial CVS trees</h3>
-
-    <p>If you don't yet have either tree you'll need to do an initial
-    check-outs.</p>
+    <h2>Setup</h2>
 
-    <p>Check out mainline GCC:</p>
+    <p>Testing with a simulator requires an installation of a working
+    GCC toolchain and a GDB simulator.  For a list of supported targets please
+    refer to the <a href="http://www.sourceware.org/gdb/download/onlinedocs/gdb.html#Embedded-Processors">GDB documentation</a>.
+    The following describes how to create a Renesas SuperH cross compiler
+    setup that can be used for simulator testing.
+    </p>
 
+    <p>All of the instructions here start out from a directory we'll
+    call <code>${TOP}</code>, which contains the following directories with
+    unpacked sources:
+    <ul>
+    <li><code>${TOP}/binutils-src</code></li>
+    <li><code>${TOP}/gcc-src</code></li>
+    <li><code>${TOP}/newlib-src</code></li>
+    <li><code>${TOP}/gdb-src</code></li>
+    </ul>
+    and the following corresponding build directories which are initially
+    empty:
+    <ul>
+    <li><code>${TOP}/binutils-build</code></li>
+    <li><code>${TOP}/gcc-build</code></li>
+    <li><code>${TOP}/newlib-build</code></li>
+    <li><code>${TOP}/gdb-build</code></li>
+    </ul>
+    To keep things simple, all parts of the cross toolchain will be installed
+    into <code>/usr/local</code>, which usually requires superuser rights for
+    writing.  If that is inconvenient, you might also install it into another
+    place.
+    </p>
+    
+    <h3>Build and install Binutils</h3>
 <pre>
-cd ${TOP}
-svn checkout svn://gcc.gnu.org/svn/gcc/trunk gcc
-# This makes sure that file timestamps are in order initially.
-cd ${TOP}/gcc
-contrib/gcc_update --touch
+cd ${TOP}/binutils-build
+../binutils-src/configure --target=sh-elf --prefix=/usr/local --disable-nls --disable-werror
+make all
+sudo make install
 </pre>
+    This should have installed the cross binutils for the target, e.g.
+    <code>sh-elf-as</code> is the assembler for our SuperH target.
 
-    <p>Check out the <code>src</code> tree:</p>
 
+    <h3>Build and install GCC (compiler only)</h3>
 <pre>
-cd ${TOP}
-cvs -d :pserver:anoncvs@sourceware.org:/cvs/src login
-# You will be prompted for a password; reply with "anoncvs".
-cvs -d :pserver:anoncvs@sourceware.org:/cvs/src co binutils newlib sim
+cd ${TOP}/gcc-build
+../gcc-src/configure --target=sh-elf --prefix=/usr/local --enable-languages=c,c++ --disable-nls --disable-werror --with-newlib --enable-lto --enable-multilib
+make all-gcc
+sudo make install-gcc
 </pre>
+    This should have installed the cross compiler for the target, e.g.
+    <code>sh-elf-gcc</code> is the compiler for our SuperH target.
 
-    <h3>Update CVS trees</h3>
-
-    <p>You can update existing CVS trees rather than starting from
-    scratch each time.  Update the GCC tree using the
-    <code>gcc_update</code> script, which touches generated files and
-    handles directory changes in the tree.  Be sure to do this from
-    the directory in which you did the original check-out, NOT in the
-    combined tree:</p>
-
+    <h3>Build and install C target runtime library</h3>
 <pre>
-cd ${TOP}/gcc
-contrib/gcc_update
+cd ${TOP}/newlib-build
+../newlib-src/configure --target=sh-elf --prefix=/usr/local --enable-lto --enable-multilib
+make all
+sudo make install
 </pre>
 
-    <p>Update the <code>src</code> tree with the same sequence of
-    commands that you used to check out that tree initially, invoked from
-    the <code>src</code> directory (NOT from within the combined tree).</p>
-
-    <h3>Create a combined tree</h3>
-
-    <p>Create a tree that consists of all of the files from the GCC and
-    binutils/sim/newlib source trees (including several simulators in
-    <code>src/sim</code>), with the GCC files overriding the
-    binutils/sim/newlib files when there's a conflict.  It's done this
-    way because the GCC files are the master copy.  To save on disk
-    space, these commands actually make a tree of hard links rather
-    than duplicating all the files:</p>
+    <h3>Build and install GCC (full)</h3>
+<pre>
+cd ${TOP}/gcc-build
+rm -rf *
+../gcc-src/configure --target=sh-elf --prefix=/usr/local --enable-languages=c,c++ --disable-nls --disable-werror --with-newlib --enable-lto --enable-multilib
+make all
+sudo make install
+</pre>
+    This should have installed the cross compiler along with the cross compiled
+    runtime libraries such as <code>libgcc</code> and <code>libstdc++</code>
+    for our SuperH target.
 
+    <h3>Build and install GDB</h3>
+<pre>
+cd ${TOP}/gdb-build
+../gdb-src/configure --target=sh-elf --prefix=/usr/local
+make all
+sudo make install
+</pre>
+    This should have installed the cross GDB for the target along with the
+    simulator, e.g. <code>sh-elf-run</code> invokes the simulator for our
+    SuperH target.
+    <p>
+    Depending on the simulated target and its implementation in GDB, there
+    might be host system related issues.  E.g. at the time of this writing,
+    the SuperH GDB simulator does not work properly on 64 bit hosts.
+    There might also be differences in simulated floating point calculations
+    which may cause some of the GCC tests to fail.
+    To build a 32 bit GDB on a x86_64 host do the following:
 <pre>
-cd ${TOP}
-rm -rf combined
-mkdir combined
-cd src &amp;&amp; find . -print | cpio -pdlm ../combined &amp;&amp; cd ..
-cd gcc &amp;&amp; find . -print | cpio -pdlmu ../combined &amp;&amp; cd ..
+cd ${TOP}/gdb-build
+export CFLAGS="-O2 -m32 -msse -mfpmath=sse"
+export CXXFLAGS="-O2 -m32 -msse -mfpmath=sse"
+../gdb-src/configure --target=sh-elf --prefix=/usr/local --enable-interwork --enable-multilib
+make all
+sudo make install
 </pre>
+    Notice that the configure script will try to look for the required
+    libraries as 32 bit versions, which you might have to install separately in
+    addition to the 64 bit libraries.
+    </p>
 
-    <h2>Build it</h2>
 
-    <p>Use a recent version of GCC as the build compiler, no earlier
-    than 2.95.</p>
+    <h2>Test it</h2>
 
-    <p>The target name suitable for the simulator is usually `*-elf' for a
-    target `*'.  There are some exceptions, for instance on powerpc
-    it's powerpc-eabi or powerpc-eabisim.  Here we build
-    <code>arm-elf</code>.</p>
+    Your cross toolchain should now be ready.  You might want to briefly test
+    this by compiling the following C++ program:
+<pre>
+#include &lt;iostream&gt;
 
+int main (void)
+{
+  std::cout << "Alice calling Bob." << std::endl;
+  return 0;
+}
+</pre>
+    as follows:
 <pre>
-cd ${TOP}
-mkdir build install
-cd build
-../combined/configure \
-    --target=arm-elf --prefix=${TOP}/install
-make
+sh-elf-g++ main.cpp
+sh-elf-run a.out
 </pre>
 
-    <h2>Test it</h2>
+
+    <h2>Run the GCC Testsuite</h2>
 
     <p>The only trick here is that you want DejaGNU to use the simulator
     rather than trying to run the output on the build system.  For
     example:</p>
 
 <pre>
-cd ${TOP}/build
-make check-gcc check-target-libstdc++-v3 RUNTESTFLAGS=--target_board=arm-sim
+cd ${TOP}/gcc-build
+make check-gcc check-target-libstdc++-v3 RUNTESTFLAGS=--target_board=sh-sim
 </pre>
 or just
 <pre>
-cd ${TOP}/build
-make check RUNTESTFLAGS=--target_board=arm-sim
+cd ${TOP}/gcc-build
+make check RUNTESTFLAGS=--target_board=sh-sim
 </pre>
 to exercise the just-built gcc on every test-suite in the tree.
 
     <p>The only reliable way (apart from guessing that it's probably
     `*-sim') to find out the name of the target board is to look in the
     DejaGNU sources, in <code>/usr/share/dejagnu/baseboards</code>, for
-    something that looks right.  Or you can use this table of combinations
-    that at one time compiled, usable as test-targets with the
-    instructions above.</p>
-
-    <p>You can compare your test results against the archived results
-    linked below to detect major problems.  As always, if you're testing
-    a patch you should compare your results with and without the patch.</p>
-
-    <p>The target characteristic can help you determine which targets to
-    use to broaden the scope of your testing.  A cc0 target uses a
-    single condition code register, cc0, which is set as a side effect
-    of most instructions.  The compiler cannot insert other instructions
-    between the instruction that sets cc0 and the one that uses it.
-    Because of this, a cc0 target causes
-    significantly different code to be generated and can matter more
-    than word size and endianness in terms of detecting new breakage.</p>
-
+    something that looks right.  As a starting point you can also use the
+    following table:
+    
 <table border="0" cellspacing="5" cellpadding="5">
 <tr valign="top" align="left">
- <th>Target</th><th>Simulator</th><th>Comments</th><th>Test Results</th>
+ <th>Target</th><th>Simulator</th>
 </tr>
 
 <tr valign="top">
  <td>arm-elf</td>
  <td>arm-sim</td>
- <td>32-bit word, little endian</td>
- <td>
- <a href="https://gcc.gnu.org/ml/gcc-testresults/2003-05/msg00592.html">3.3 20030509 (prerelease)</a>
- <br />
- <a href="https://gcc.gnu.org/ml/gcc-testresults/2003-04/msg00949.html">3.2.3 20030415 (prerelease)</a>
- </td>
 </tr>
 
 <tr valign="top">
  <td>fr30-elf</td>
  <td>fr30-sim</td>
- <td>32-bit word, big endian</td>
- <td>
- <a href="https://gcc.gnu.org/ml/gcc-testresults/2003-05/msg00766.html">3.3 20030509 (prerelease)</a>
- </td>
 </tr>
 
 <tr valign="top">
  <td>h8300-coff</td>
  <td>h8300-sim</td>
- <td>cc0 target, big endian</td>
- <td>
- <a href="https://gcc.gnu.org/ml/gcc-testresults/2003-05/msg00624.html">3.3 20030509 (prerelease)</a>
- <br />
- <a href="https://gcc.gnu.org/ml/gcc-testresults/2003-04/msg00967.html">3.2.3 20030415 (prerelease)</a>
- </td>
 </tr>
 
 <tr valign="top">
  <td>m32r-elf</td>
  <td>m32r-sim</td>
- <td>32-bit word, big endian</td>
- <td>
- <a href="https://gcc.gnu.org/ml/gcc-testresults/2003-05/msg01478.html">3.3</a>
- </td>
 </tr>
 
 <tr valign="top">
  <td>mips-elf</td>
  <td>mips-sim</td>
- <td>big endian</td>
- <td>
- <a href="https://gcc.gnu.org/ml/gcc-testresults/2005-11/msg00636.html">4.1.0 20051112 (experimental)</a>
- <br />
- <a href="https://gcc.gnu.org/ml/gcc-testresults/2003-05/msg00619.html">3.3 20030509 (prerelease)</a>
- </td>
 </tr>
 
 <tr valign="top">
  <td>mipsisa64-elf</td>
  <td>mips-sim-idt64</td>
- <td>&nbsp;</td>
- <td>
- <a href="https://gcc.gnu.org/ml/gcc-testresults/2003-06/msg00335.html">3.4 20030605 (experimental)</a>
- </td>
 </tr>
 
 <tr valign="top">
  <td>mn10300-elf</td>
  <td>mn10300-sim</td>
- <td>cc0 target, little endian</td>
- <td>
- <a href="https://gcc.gnu.org/ml/gcc-testresults/2003-05/msg00632.html">3.3 20030509 (prerelease)</a>
- <br />
- <a href="https://gcc.gnu.org/ml/gcc-testresults/2003-04/msg00972.html">3.2.3 20030415 (prerelease)</a>
- </td>
 </tr>
 
 <tr valign="top">
  <td>powerpc-eabisim</td>
  <td>powerpc-sim</td>
- <td>32-bit word, big endian</td>
- <td>
- <a href="https://gcc.gnu.org/ml/gcc-testresults/2003-03/msg00033.html">3.4 20030301 (experimental)</a>
- </td>
 </tr>
 
 <tr valign="top">
  <td>sh-coff</td>
  <td>sh-hms</td>
- <td>&nbsp;</td>
- <td>
- <a href="https://gcc.gnu.org/ml/gcc-testresults/2003-05/msg00622.html">3.3 20030509 (prerelease)</a>
- <br />
- <a href="https://gcc.gnu.org/ml/gcc-testresults/2003-04/msg00964.html">3.2.3 20030415 (prerelease)</a>
- </td>
 </tr>
 
 <tr valign="top">
  <td>sh-elf</td>
  <td>sh-sim</td>
- <td>big endian</td>
- <td>
- <a href="https://gcc.gnu.org/ml/gcc-testresults/2006-02/msg01441.html">4.2.0 20060226 (experimental)</a>
- <br />
- <a href="https://gcc.gnu.org/ml/gcc-testresults/2003-06/msg00315.html">3.4 20030605 (experimental)</a>
- <br />
- <a href="https://gcc.gnu.org/ml/gcc-testresults/2003-05/msg00631.html">3.3 20030509 (prerelease)</a>
- <br />
- <a href="https://gcc.gnu.org/ml/gcc-testresults/2003-04/msg00970.html">3.2.3 20030415 (prerelease)</a>
- </td>
 </tr>
 
 <tr valign="top">
  <td>sparc-elf</td>
  <td>sparc-sim</td>
- <td>&nbsp;</td>
- <td>
- <a href="https://gcc.gnu.org/ml/gcc-testresults/2003-05/msg00587.html">3.3 20030507 (prerelease)</a>
- <br />
- <a href="https://gcc.gnu.org/ml/gcc-testresults/2003-04/msg00942.html">3.2.3 20030415 (prerelease)</a>
- </td>
 </tr>
 
 <tr valign="top">
  <td>v850-elf</td>
  <td>v850-sim</td>
- <td>cc0 target, 32-bit word, little endian</td>
- <td>
- <a href="https://gcc.gnu.org/ml/gcc-testresults/2003-04/msg00978.html">3.2.3 20030415 (prerelease)</a>
- </td>
 </tr>
 
 </table>
+    </p>
+
+    <p>You can compare your test results against the <a href="https://gcc.gnu.org/ml/gcc-testresults/">archived results</a>.
+    Notice that running tests on simulators will often show more failures than
+    usual due to restrained memory capacity of the simulator and lack of other
+    features such as threads.  As always, if you're testing a patch you should
+    compare your results with and without the patch.</p>
+
+    <p>The target characteristic can help you determine which targets to
+    use to broaden the scope of your testing.  A cc0 target uses a
+    single condition code register, cc0, which is set as a side effect
+    of most instructions.  The compiler cannot insert other instructions
+    between the instruction that sets cc0 and the one that uses it.
+    Because of this, a cc0 target causes significantly different code to be
+    generated and can matter more than word size and endianness in terms of
+    detecting new breakage.</p>
+
+    <p>In order to run the tests with various combinations of compiler flags
+    that control the target's architecture settings e.g. the following can be
+    used:
+<pre>
+make -k check RUNTESTFLAGS="--target_board=sh-sim\{-m2/-ml,-m2/-mb,-m2a/-mb,-m2a-single/-mb,-m4/-ml,-m4/-mb,-m4-single/-ml,-m4-single/-mb,-m4a-single/-ml,-m4a-single/-mb}"
+</pre>
+    which will run the GCC testsuite ten times for different combinations of
+    processor and endianness configurations of the SuperH target.  Depending on
+    how the cross GCC was configured, specifying additional compiler options
+    might be necessary to get meaningful results.  E.g. the SuperH compiler as
+    configured above will by default generate code for big endian SH-1 if no
+    further options are specified, which covers only a subset of the SuperH ISA.
+    </p>
+
+<!-- ==================================================================== -->
+
+<div class="copyright">
+
+<address style="margin-top:0;">For questions related to the use of GCC,
+please consult these web pages and the
+<a href="https://gcc.gnu.org/onlinedocs/">GCC manuals</a>. If that fails,
+the <a href="mailto:gcc-help@gcc.gnu.org">gcc-help@gcc.gnu.org</a>
+mailing list might help.
+Comments on these web pages and the development of GCC are welcome on our
+developer list at <a href="mailto:gcc@gcc.gnu.org">gcc@gcc.gnu.org</a>.
+All of <a href="https://gcc.gnu.org/lists.html">our lists</a>
+have public archives.
+</address>
+
+<p>Copyright (C)
+<a href="http://www.fsf.org">Free Software Foundation, Inc.</a>
+Verbatim copying and distribution of this entire article is
+permitted in any medium, provided this notice is preserved.</p>
+
+<p style="margin-bottom:0;">These pages are
+<a href="https://gcc.gnu.org/about.html">maintained by the GCC team</a>.
+Last modified 2014-06-27<!-- IGNORE DIFF
+--><a href="http://validator.w3.org/check/referer">.</a></p>
+
+</div>
+
+<!-- ==================================================================== -->
+
 </body>
-</html>
+     </html>
+  
+