public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug testsuite/39215]  New: Running Testsuite with Multilib Flags exposes many errors in Testsuite (and gcc)
@ 2009-02-17 16:22 rob1weld at aol dot com
  2009-02-22  1:27 ` [Bug testsuite/39215] " rob1weld at aol dot com
  2010-04-28 19:40 ` ro at gcc dot gnu dot org
  0 siblings, 2 replies; 4+ messages in thread
From: rob1weld at aol dot com @ 2009-02-17 16:22 UTC (permalink / raw)
  To: gcc-bugs

This comment ( http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39150#c1 ) says:
"How is this major, this is an enhancement to the build system.  
i386-solaris is a multi arch target so it includes the x86_64 
solaris target also."


Attempts to run the Testsuite in 'Multilib-Mode' on the Target
"i386-pc-solaris2.11" exposes many failures:

Results for 4.4.0 20090216 (experimental) [trunk revision 144203] (GCC)
testsuite on i386-pc-solaris2.11
http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg01622.html

Thanks,
Rob

PS: I filed the ICE as a separate BUG.


-- 
           Summary: Running Testsuite with Multilib Flags exposes many
                    errors in Testsuite (and gcc)
           Product: gcc
           Version: 4.4.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: testsuite
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: rob1weld at aol dot com
 GCC build triplet: i386-pc-solaris2.11
  GCC host triplet: i386-pc-solaris2.11
GCC target triplet: i386-pc-solaris2.11


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39215


^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug testsuite/39215] Running Testsuite with Multilib Flags exposes many errors in Testsuite (and gcc)
  2009-02-17 16:22 [Bug testsuite/39215] New: Running Testsuite with Multilib Flags exposes many errors in Testsuite (and gcc) rob1weld at aol dot com
@ 2009-02-22  1:27 ` rob1weld at aol dot com
  2010-04-28 19:40 ` ro at gcc dot gnu dot org
  1 sibling, 0 replies; 4+ messages in thread
From: rob1weld at aol dot com @ 2009-02-22  1:27 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #1 from rob1weld at aol dot com  2009-02-22 01:27 -------
Here are two more results. 

The first is created using "gmake -i check" and the second with 
gmake -i -k check RUNTESTFLAGS="--target_board=unix\{-m64,-m32\}" .


Results for 4.4.0 20090220 (experimental) [trunk revision 144331] (GCC)
testsuite on i386-pc-solaris2.11
http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg02052.html


Results for 4.4.0 20090220 (experimental) [trunk revision 144331] (GCC)
testsuite on i386-pc-solaris2.11 (variations: -m64, -m32)
http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg02143.html

-----

Note these oddities when comparing the tests:

1.
In the 1st link these ACATS tests fail: ce2102c ce2401f la14016
In the 2nd link these ACATS tests fail: ce2109c ce3403c
The gcc compiler gives different results when the Testsuite is
ran again on the exact same gcc as the first (not recompiled).

2.
If you compare the "# of unexpected failures" in the "gcc Summary"
of the first link with the "gcc Summary for unix/-m32" in the second
link your will see that there is one test result that is different 
(the rest the same), that is pretty close, but not identical.

3. The "gcc Summary for unix/-m64" in the second link is _very_
different from the "gcc Summary" given in the first link yet I
am booted in 64-Bit Boot Mode. (See Note 2, I 'nearly' match the
32-Bit Boot Mode).

4. The "gfortran Summary" in the first link and the "gfortran 
Summary for unix/-m32" in the second link _are_ identical. This
further supports the theory that "the code prefers testing (and 
passing those tests) in 32-Bit Boot Mode". This is unfortunate
for 64-Bit Boot Mode. There are also other test that show these
tendencies and none that oppose this theory.

5.
In the "gnat tests" for "target unix/-m64" in the second link there 
are an enormous number of FAILs compared to the 32-Bit tests.


Part of the trouble is evident in the "gnat Summary":

=== gnat Summary for unix/-m64 ===

# of expected passes        255
# of unexpected failures    206
# of expected failures      6

Running target unix/-m32

=== gnat Summary for unix/-m32 ===

# of expected passes        607
# of expected failures      6

=== gnat Summary ===

# of expected passes        862
# of unexpected failures    206
# of expected failures      12

Wildly different results.


6. 
Look at the result for LibJava both 64-Bit and 32-Bit
tests are nearly _identical_! This is how all the tests
should be (except for the tests that can only run in
one of the two modes, or are expected to provide a 
different result for each mode; thus each would use
different code and be subject to different results).

7.
Luckily the "libstdc++ Summary" shows it works about
as well as the LibJava (nearly perfectly matched) and
thus _probably_ supports 64 and 32 bit compilation
correctly (once the "unexpected failures" are fixed).

Rob


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39215


^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug testsuite/39215] Running Testsuite with Multilib Flags exposes many errors in Testsuite (and gcc)
  2009-02-17 16:22 [Bug testsuite/39215] New: Running Testsuite with Multilib Flags exposes many errors in Testsuite (and gcc) rob1weld at aol dot com
  2009-02-22  1:27 ` [Bug testsuite/39215] " rob1weld at aol dot com
@ 2010-04-28 19:40 ` ro at gcc dot gnu dot org
  1 sibling, 0 replies; 4+ messages in thread
From: ro at gcc dot gnu dot org @ 2010-04-28 19:40 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #2 from ro at gcc dot gnu dot org  2010-04-28 19:40 -------
It's pretty much impossible to deal with PRs that bundle dozens of different
issues together (or with postings to gcc-testresults that have almost as much
boilerplate, comments and explantions as actual results).

Many of the bugs you've seen should be fixed on mainline and the 4.5 branch,
if anything important is missing, please file *separate* bug reports for each
issue so they can be investigated and fixed one by one.


-- 

ro at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ro at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39215


^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug testsuite/39215] Running Testsuite with Multilib Flags exposes many errors in Testsuite (and gcc)
       [not found] <bug-39215-4@http.gcc.gnu.org/bugzilla/>
@ 2011-07-18 16:36 ` ro at gcc dot gnu.org
  0 siblings, 0 replies; 4+ messages in thread
From: ro at gcc dot gnu.org @ 2011-07-18 16:36 UTC (permalink / raw)
  To: gcc-bugs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39215

Rainer Orth <ro at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |FIXED

--- Comment #3 from Rainer Orth <ro at gcc dot gnu.org> 2011-07-18 16:34:28 UTC ---
Solaris/x86 testresults are practically clean these days, for both multilibs
and both 32-bit default and 64-bit default configurations.


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2011-07-18 16:36 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-02-17 16:22 [Bug testsuite/39215] New: Running Testsuite with Multilib Flags exposes many errors in Testsuite (and gcc) rob1weld at aol dot com
2009-02-22  1:27 ` [Bug testsuite/39215] " rob1weld at aol dot com
2010-04-28 19:40 ` ro at gcc dot gnu dot org
     [not found] <bug-39215-4@http.gcc.gnu.org/bugzilla/>
2011-07-18 16:36 ` ro at gcc dot gnu.org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).