[Bug testsuite/40699] New: [4.5 Regression] All sparcv9 libjava execution tests fail on Solaris 11/SPARC

[Bug testsuite/40699] New: [4.5 Regression] All sparcv9 libjava execution tests fail on Solaris 11/SPARC

[ro at gcc dot gnu dot org]

Between 20090522 and 20090702, all sparcv9 libjava execution tests started to
fail. libjava.log reveals:

set_ld_library_path_env_vars:
ld_library_path=.:/vol/gccsrc/obj/gcc-4.5.0-20090702/11-gcc/sparc-sun-solaris2.11/sparcv9/libjava/.libs:/vol/gccsrc/obj/gcc-4.5.0-20090702/11-gcc/./gcc
Setting LD_LIBRARY_PATH to
.:/vol/gccsrc/obj/gcc-4.5.0-20090702/11-gcc/sparc-sun-solaris2.11/sparcv9/libjava/.libs:/vol/gccsrc/obj/gcc-4.5.0-20090702/11-gcc/./gcc:.:/vol/gccsrc/obj/gcc-4.5.0-20090702/11-gcc/sparc-sun-solaris2.11/sparcv9/libjava/.libs:/vol/gccsrc/obj/gcc-4.5.0-20090702/11-gcc/./gcc:/vol/gccsrc/obj/gcc-4.5.0-20090702/11-gcc/sparc-sun-solaris2.11/libstdc++-v3/.libs:/vol/gccsrc/obj/gcc-4.5.0-20090702/11-gcc/sparc-sun-solaris2.11/libssp/.libs:/vol/gccsrc/obj/gcc-4.5.0-20090702/11-gcc/sparc-sun-solaris2.11/libgomp/.libs:/vol/gccsrc/obj/gcc-4.5.0-20090702/11-gcc/./gcc:/vol/gccsrc/obj/gcc-4.5.0-20090702/11-gcc/./prev-gcc
ld.so.1: PR9577: fatal:
/vol/gccsrc/obj/gcc-4.5.0-20090702/11-gcc/./gcc/libgcc_s.so.1: wrong ELF class:
ELFCLASS32
FAIL: PR9577 run

Compared to the 20090522 log entry

set_ld_library_path_env_vars:
ld_library_path=.:/vol/gccsrc/obj/gcc-4.5.0-20090702/11-gcc/sparc-sun-solaris2.11/sparcv9/libjava/.libs:/vol/gccsrc/obj/gcc-4.5.0-20090702/11-gcc/./gcc
Executing on host:
/vol/gccsrc/obj/gcc-4.5.0-20090702/11-gcc/sparc-sun-solaris2.11/libjava/testsuite/../libtool
--silent --tag=GCJ --mode=link
/vol/gccsrc/obj/gcc-4.5.0-20090702/11-gcc/./gcc/gcj
-B/vol/gccsrc/obj/gcc-4.5.0-20090702/11-gcc/sparc-sun-solaris2.11/libjava/
-B/vol/gccsrc/obj/gcc-4.5.0-20090702/11-gcc/./gcc/
-B/vol/gcc/sparc-sun-solaris2.11/bin/ -B/vol/gcc/sparc-sun-solaris2.11/lib/
-isystem /vol/gcc/sparc-sun-solaris2.11/include -isystem
/vol/gcc/sparc-sun-solaris2.11/sys-include    --encoding=UTF-8
-B/vol/gccsrc/obj/gcc-4.5.0-20090702/11-gcc/sparc-sun-solaris2.11/libjava/testsuite/../
/vol/gcc/src/gcc-dist/libjava/testsuite/libjava.cni/PR9577.jar natPR9577.o  -w 
-no-install --main=PR9577 -g 
-L/vol/gccsrc/obj/gcc-4.5.0-20090702/11-gcc/sparc-sun-solaris2.11/sparcv9/libjava/.libs
-lm   -m64 -o PR9577    (timeout = 300)
PASS: linking PR9577

the sparcv9 subdirectory is missing from gcc in the LD_LIBRARY_PATH, so the
wrong libgcc_s.so.1 is found.  This is most likely due to this change:

2009-06-30  Richard Sandiford  <r.sandiford@uk.ibm.com>

        * testsuite/lib/libjava.exp (libjava_init): Just add
        find_libgcc_s to libjava_libgcc_s_path, rather than every
        libgcc multilib directory.
        (libjava_arguments): Explain why we add "." to ld_library_path.
        (gcj_invoke, exec_gij, libjava_invoke): Use add_path.


-- 
           Summary: [4.5 Regression] All sparcv9 libjava execution tests
                    fail on Solaris 11/SPARC
           Product: gcc
           Version: 4.5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: testsuite
        AssignedTo: rsandifo at gcc dot gnu dot org
        ReportedBy: ro at gcc dot gnu dot org
 GCC build triplet: sparc-sun-solaris2.11
  GCC host triplet: sparc-sun-solaris2.11
GCC target triplet: sparc-sun-solaris2.11


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

[Bug testsuite/40699] [4.5 Regression] All sparcv9 libjava execution tests fail on Solaris 11/SPARC

[ro at gcc dot gnu dot org]

------- Comment #1 from ro at gcc dot gnu dot org  2009-07-09 18:08 -------
Same problem on i386-pc-solaris2.10 as of 20090702 (new since 20090622).


-- 


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

[Bug testsuite/40699] [4.5 Regression] All sparcv9 libjava execution tests fail on Solaris 11/SPARC

[rsandifo at gcc dot gnu dot org]

------- Comment #2 from rsandifo at gcc dot gnu dot org  2009-07-09 19:12 -------
Do you only see this for libjava?


-- 


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

[Bug testsuite/40699] [4.5 Regression] All sparcv9 libjava execution tests fail on Solaris 11/SPARC

[ro at techfak dot uni-bielefeld dot de]

------- Comment #3 from ro at techfak dot uni-bielefeld dot de  2009-07-09 19:17 -------
Subject: Re:  [4.5 Regression] All sparcv9 libjava execution tests fail on
Solaris 11/SPARC

rsandifo at gcc dot gnu dot org writes:

> Do you only see this for libjava?

Yes, all other library tests are normal (no massive differences between 32
and 64 bit).

        Rainer


-- 


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

[Bug testsuite/40699] [4.5 Regression] All sparcv9 libjava execution tests fail on Solaris 11/SPARC

[rsandifo at gcc dot gnu dot org]

------- Comment #4 from rsandifo at gcc dot gnu dot org  2009-07-09 19:23 -------
OK, I'm going to need some help debugging this one.  First of all,
how are you running your tests?  E.g.

  (a) are you using --target_board unix/-m64,
  (b) is -m64 the default, or
  (c) something else?

Second, this:

    [find_libgcc_s $GCJ_UNDER_TEST]

is supposed to return the directory of the 64-bit libgcc, but presumably
it isn't doing.  Could you compare the result of that command with
something like:

    [find_libgcc_s $GFORTRAN_UNDER_TEST]

which seems to work?


-- 


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

[Bug testsuite/40699] [4.5 Regression] All sparcv9 libjava execution tests fail on Solaris 11/SPARC

[ro at techfak dot uni-bielefeld dot de]

------- Comment #5 from ro at techfak dot uni-bielefeld dot de  2009-07-09 20:17 -------
Subject: Re:  [4.5 Regression] All sparcv9 libjava execution tests fail on
Solaris 11/SPARC

rsandifo at gcc dot gnu dot org writes:

> OK, I'm going to need some help debugging this one.  First of all,
> how are you running your tests?  E.g.
> 
>   (a) are you using --target_board unix/-m64,
>   (b) is -m64 the default, or
>   (c) something else?

I'm using --target_board 'unix{,-mabi=64}'.

> Second, this:
> 
>     [find_libgcc_s $GCJ_UNDER_TEST]
> 
> is supposed to return the directory of the 64-bit libgcc, but presumably
> it isn't doing.  Could you compare the result of that command with
> something like:
> 
>     [find_libgcc_s $GFORTRAN_UNDER_TEST]
> 
> which seems to work?

I've tried running runtest manually both in gcc/testsuite/gfortran like
this

> runtest --tool gfortran --srcdir /vol/gcc/src/gcc-dist/gcc/tesuite --target_board 'unix{-m64}' -v

which works correctly, and in sparc-sun-solaris2.11/libjava/testsuite like
so

> runtest INTERPRETER=yes --tool libjava --srcdir /vol/gcc/src/gcc-dist/libjava/testsuite --target_board 'unix{-m64}' -v

which fails horribly:

Expect binary is expect
Using /vol/gnu/share/dejagnu/runtest.exp as main test driver
Verbose level is 1
Login name is ro
Found
/vol/gccsrc/obj/gcc-4.5.0-20090702/11-gcc/sparc-sun-solaris2.11/libjava/testsuite/site.exp
Found
/vol/gccsrc/obj/gcc-4.5.0-20090702/11-gcc/sparc-sun-solaris2.11/libjava/testsuite/site.exp
Using test sources in /vol/gcc/src/gcc-dist/libjava/testsuite
Using test binaries in
/vol/gccsrc/obj/gcc-4.5.0-20090702/11-gcc/sparc-sun-solaris2.11/libjava/testsuite
Tool root directory is
/vol/gccsrc/obj/gcc-4.5.0-20090702/11-gcc/sparc-sun-solaris2.11
Using /vol/gnu/share/dejagnu to find libraries
WARNING: Couldn't find the global config file.
Loading /vol/gnu/share/dejagnu/utils.exp
Loading /vol/gnu/share/dejagnu/framework.exp
Loading /vol/gnu/share/dejagnu/debugger.exp
Loading /vol/gnu/share/dejagnu/remote.exp
Loading /vol/gnu/share/dejagnu/mondfe.exp
Loading /vol/gnu/share/dejagnu/xsh.exp
Loading /vol/gnu/share/dejagnu/telnet.exp
Loading /vol/gnu/share/dejagnu/rlogin.exp
Loading /vol/gnu/share/dejagnu/kermit.exp
Loading /vol/gnu/share/dejagnu/tip.exp
Loading /vol/gnu/share/dejagnu/rsh.exp
Loading /vol/gnu/share/dejagnu/ftp.exp
Loading /vol/gnu/share/dejagnu/target.exp
Loading /vol/gnu/share/dejagnu/targetdb.exp
Loading /vol/gnu/share/dejagnu/libgloss.exp
Loading library file /vol/gcc/src/gcc-dist/libjava/testsuite/lib/libjava.exp
Found
/vol/gcc/src/gcc-dist/libjava/testsuite/../../gcc/testsuite/lib/target-libpath.exp
Testing libjava
Opening log files in .
Test Run By ro on Thu Jul  9 22:03:41 2009
Native configuration is sparc-sun-solaris2.11

                === libjava tests ===

setting trap for SIGTERM to terminated
setting trap for SIGINT to interrupted by user
setting trap for SIGQUIT to interrupted by user
setting trap for SIGSEGV to segmentation violation
dirlist is /vol/gnu/share/dejagnu/baseboards
pushing config for build, name is galeras
dirlist is /vol/gnu/share/dejagnu/baseboards
pushing config for host, name is galeras
target list is unix{-m64}
Schedule of variations:
    unix/-m64

target is unix/-m64
Running target unix/-m64
dirlist is /vol/gnu/share/dejagnu/baseboards/galeras
/vol/gnu/share/dejagnu/baseboards
Using /vol/gnu/share/dejagnu/baseboards/unix.exp as board description file for
target.
Using /vol/gnu/share/dejagnu/config/unix.exp as generic interface file for
target.
Using /vol/gcc/src/gcc-dist/libjava/testsuite/config/default.exp as
tool-and-target-specific interface file.
Loading /vol/gnu/share/dejagnu/standard.exp
pushing config for target, name is unix/-m64
Running /vol/gcc/src/gcc-dist/libjava/testsuite/libjava.cni/cni.exp ...
version: 4.5.0
jar file is
/vol/gccsrc/obj/gcc-4.5.0-20090702/11-gcc/sparc-sun-solaris2.11/libjava/testsuite/../libgcj-4.5.0.jar
gcj: libgcj.spec: No such file or directory
    while executing
"exec /vol/gccsrc/obj/gcc-4.5.0-20090702/11-gcc/gcc/gcj
-B/vol/gccsrc/obj/gcc-4.5.0-20090702/11-gcc/gcc/ --encoding=UTF-8 -m64
--print-multi-directory"
    ("eval" body line 1)
    invoked from within
"eval exec $compiler [board_info target multilib_flags] 
--print-multi-directory"
    (procedure "find_libgcc_s" line 16)
    invoked from within
"find_libgcc_s $GCJ_UNDER_TEST"
    (procedure "libjava_init" line 71)
    invoked from within
"${tool}_init $test_file_name"
    invoked from within
"if [info exists tool] {
            if { [info procs "${tool}_init"] != "" } {
                ${tool}_init $test_file_name
            }
        }"
    invoked from within
"if [file exists $test_file_name] {
        set timestart [timestamp]

        if [info exists tool] {
            if { [info procs "${tool}_init"] != "" } {
                ${tool}_init..."
    (procedure "runtest" line 14)
    invoked from within
"runtest $test_name"
    ("foreach" body line 42)
    invoked from within
"foreach test_name [lsort [find ${dir} *.exp]] {
                        if { ${test_name} == "" } {
                            continue
                        }
                        # Ignore this one if asked to.
                        if { ${ignore..."
    ("foreach" body line 54)
    invoked from within
"foreach dir "${test_top_dirs}" {
                if { ${dir} != ${srcdir} } {
                    # Ignore this directory if is a directory to be
                    # ignored.
                    if {[info..."
    ("foreach" body line 121)
    invoked from within
"foreach pass $multipass {

        # multipass_name is set for `record_test' to use (see framework.exp).
        if { [lindex $pass 0] != "" } {
            set multipass_..."
    ("foreach" body line 51)
    invoked from within
"foreach current_target $target_list {
    verbose "target is $current_target"
    set current_target_name $current_target
    set tlist [split $curren..."
    (file "/vol/gnu/share/dejagnu/runtest.exp" line 1625)

Unfortunately, the same thing happens when I invoke runtest manually in the
20090522 tree where the 64-bit tests still worked correctly.  What I find,
though, are two different invocations of gcj (found with truss):

* one like this

/vol/gccsrc/obj/gcc-4.5.0-20090522/11-gcc/gcc/gcj
-B/vol/gccsrc/obj/gcc-4.5.0-20090522/11-gcc/gcc/
-B/vol/gccsrc/obj/gcc-4.5.0-20090522/11-gcc/sparc-sun-solaris2.11/libjava/testsuite/../
-v

  which finds libgcj.spec, and

* another one like this

/vol/gccsrc/obj/gcc-4.5.0-20090522/11-gcc/gcc/gcj
-B/vol/gccsrc/obj/gcc-4.5.0-20090522/11-gcc/gcc/ --encoding=UTF-8 -m64
--print-multi-directory

  which doesn't (and lacks the second -B above, since libgcj.spec is only
  located in the libjava tree).

Maybe this helps to get this resolved?

Thanks.
        Rainer


-- 


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

[Bug testsuite/40699] [4.5 Regression] All sparcv9 libjava execution tests fail on Solaris 11/SPARC

[rsandifo at gcc dot gnu dot org]

------- Comment #6 from rsandifo at gcc dot gnu dot org  2009-07-11 06:11 -------
Subject: Bug 40699

Author: rsandifo
Date: Sat Jul 11 06:10:49 2009
New Revision: 149508

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149508
Log:
gcc/testsuite/
        PR testsuite/40699
        PR testsuite/40707
        PR testsuite/40709
        * lib/gcc-defs.exp, lib/target-libpath.exp, lib/objc.exp,
        lib/gfortran.exp, lib/g++.exp, lib/obj-c++.exp, lib/c-torture.exp,
        lib/gcc-dg.exp, lib/gnat.exp, g++.dg/compat/compat.exp,
        g++.dg/compat/struct-layout-1.exp: Revert 2009-06-30 commit.

libstdc++-v3/
        PR testsuite/40699
        PR testsuite/40707
        PR testsuite/40709
        * testsuite/lib/libstdc++.exp: Revert 2009-06-30 commit.

libjava/
        PR testsuite/40699
        PR testsuite/40707
        PR testsuite/40709
        * testsuite/lib/libjava.exp: Revert 2009-06-30 commit.

libgomp/
        PR testsuite/40699
        PR testsuite/40707
        PR testsuite/40709
        * testsuite/lib/libgomp.exp: Revert 2009-07-02 and 2009-06-30 commits.
        * testsuite/libgomp.c/c.exp, testsuite/libgomp.c++/c++.exp,
        testsuite/libgomp.fortran/fortran.exp: Revert 2009-06-30 commits.

libffi/
        PR testsuite/40699
        PR testsuite/40707
        PR testsuite/40709
        * testsuite/lib/libffi-dg.exp: Revert 2009-07-02, 2009-07-01 and
        2009-06-30 commits.

libmudflap/
        PR testsuite/40699
        PR testsuite/40707
        PR testsuite/40709
        * testsuite/lib/libmudflap.exp: Revert 2009-06-30 commit.

Modified:
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/g++.dg/compat/compat.exp
    trunk/gcc/testsuite/g++.dg/compat/struct-layout-1.exp
    trunk/gcc/testsuite/lib/c-torture.exp
    trunk/gcc/testsuite/lib/g++.exp
    trunk/gcc/testsuite/lib/gcc-defs.exp
    trunk/gcc/testsuite/lib/gcc-dg.exp
    trunk/gcc/testsuite/lib/gfortran.exp
    trunk/gcc/testsuite/lib/gnat.exp
    trunk/gcc/testsuite/lib/obj-c++.exp
    trunk/gcc/testsuite/lib/objc.exp
    trunk/gcc/testsuite/lib/target-libpath.exp
    trunk/libffi/ChangeLog
    trunk/libffi/testsuite/lib/libffi-dg.exp
    trunk/libgomp/ChangeLog
    trunk/libgomp/testsuite/lib/libgomp.exp
    trunk/libgomp/testsuite/libgomp.c++/c++.exp
    trunk/libgomp/testsuite/libgomp.c/c.exp
    trunk/libgomp/testsuite/libgomp.fortran/fortran.exp
    trunk/libjava/ChangeLog
    trunk/libjava/testsuite/lib/libjava.exp
    trunk/libmudflap/ChangeLog
    trunk/libmudflap/testsuite/lib/libmudflap.exp
    trunk/libstdc++-v3/ChangeLog
    trunk/libstdc++-v3/testsuite/lib/libstdc++.exp


-- 


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

[Bug testsuite/40699] [4.5 Regression] All sparcv9 libjava execution tests fail on Solaris 11/SPARC

[rsandifo at gcc dot gnu dot org]

------- Comment #7 from rsandifo at gcc dot gnu dot org  2009-07-11 06:44 -------
"ro at techfak dot uni-bielefeld dot de" <gcc-bugzilla@gcc.gnu.org> writes:
> Unfortunately, the same thing happens when I invoke runtest manually in the
> 20090522 tree where the 64-bit tests still worked correctly.

Ah!  Thanks, that explains it.  So the --print-multi-lib command failed
before the patch too, but adding the directories for all multilibs
masked this problem.  (I was wrongly assuming it was the --print-multi-lib
invocation itself that I'd broken.)

> What I find, though, are two different invocations of gcj (found with truss):
>
> * one like this
>
> /vol/gccsrc/obj/gcc-4.5.0-20090522/11-gcc/gcc/gcj
> -B/vol/gccsrc/obj/gcc-4.5.0-20090522/11-gcc/gcc/
> -B/vol/gccsrc/obj/gcc-4.5.0-20090522/11-gcc/sparc-sun-solaris2.11/libjava/testsuite/../
> -v
>
>   which finds libgcj.spec, and
>
> * another one like this
>
> /vol/gccsrc/obj/gcc-4.5.0-20090522/11-gcc/gcc/gcj
> -B/vol/gccsrc/obj/gcc-4.5.0-20090522/11-gcc/gcc/ --encoding=UTF-8 -m64
> --print-multi-directory
>
>   which doesn't (and lacks the second -B above, since libgcj.spec is only
>   located in the libjava tree).
>
> Maybe this helps to get this resolved?

It does, thanks.  I agree that the missing -B option is the problem here.

However, the patch has already called a lot of fallout, so the best
thing seemed to be to revert it.  Thanks a lot for the help though:
it shows what needs to be fixed if I or someone else comes back
to this at a later date.


-- 

rsandifo at gcc dot gnu dot org changed:

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


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