[PATCH RFA] always process -B paths first.

[Chris Demetriou <cgd at google dot com>]

The libgomp tests use -B to find libgomp.spec in the libgomp build
directory.  The 32-bit libgomp multilib tests use a -B path to the
32-bit libgomp build directory, and the 64-bit tests do likewise.  In
each case, the directory named in the -B path is the directory which
contains libgomp.spec.

Paths specified with -B args are supposed to be checked first.
Unfortunately, right now, when handling multilibs, gcc.c's
for_each_path processes path prefixes with the multilib suffix, then
goes back and dos the entire list again without the multilib prefix.

With clean sources as of a couple of days ago, built on an Ubuntu
Hardy system for x86_64-linux (I've marked the -B/foobar paths with
*******):

[cgd@cgda gcc-cgd-clean]$ inst/bin/gcc -B/foobar/ -m32
-print-search-dirs | sed -e 's,$,\n,' -e 's,:,\n,g'
install
 /usr/local/google/cgda-local/cgd/proj/gcc/gcc-cgd-clean/inst/bin/../lib/gcc/x86_64-linux/4.5.0/

programs
 =/foobar/x86_64-linux/4.5.0/
/foobar/
/usr/local/google/cgda-local/cgd/proj/gcc/gcc-cgd-clean/inst/bin/../libexec/gcc/x86_64-linux/4.5.0/
/usr/local/google/cgda-local/cgd/proj/gcc/gcc-cgd-clean/inst/bin/../libexec/gcc/
/usr/local/google/cgda-local/cgd/proj/gcc/gcc-cgd-clean/inst/bin/../lib/gcc/x86_64-linux/4.5.0/../../../../x86_64-linux/bin/x86_64-linux/4.5.0/
/usr/local/google/cgda-local/cgd/proj/gcc/gcc-cgd-clean/inst/bin/../lib/gcc/x86_64-linux/4.5.0/../../../../x86_64-linux/bin/

libraries
 =/foobar/x86_64-linux/4.5.0/32/    *******
/foobar/32/    *******
/usr/local/google/cgda-local/cgd/proj/gcc/gcc-cgd-clean/inst/bin/../lib/gcc/x86_64-linux/4.5.0/32/
/usr/local/google/cgda-local/cgd/proj/gcc/gcc-cgd-clean/inst/bin/../lib/gcc/32/
/usr/local/google/cgda-local/cgd/proj/gcc/gcc-cgd-clean/inst/bin/../lib/gcc/x86_64-linux/4.5.0/../../../../x86_64-linux/lib/x86_64-linux/4.5.0/32/
/usr/local/google/cgda-local/cgd/proj/gcc/gcc-cgd-clean/inst/bin/../lib/gcc/x86_64-linux/4.5.0/../../../../x86_64-linux/lib/../lib32/
/usr/local/google/cgda-local/cgd/proj/gcc/gcc-cgd-clean/inst/bin/../lib/gcc/x86_64-linux/4.5.0/../../../x86_64-linux/4.5.0/32/
/usr/local/google/cgda-local/cgd/proj/gcc/gcc-cgd-clean/inst/bin/../lib/gcc/x86_64-linux/4.5.0/../../../../lib32/
/lib/x86_64-linux/4.5.0/32/
/lib/../lib32/
/usr/lib/x86_64-linux/4.5.0/32/
/usr/lib/../lib32/
/foobar/x86_64-linux/4.5.0/    *******
/foobar/    *******
/usr/local/google/cgda-local/cgd/proj/gcc/gcc-cgd-clean/inst/bin/../lib/gcc/x86_64-linux/4.5.0/
/usr/local/google/cgda-local/cgd/proj/gcc/gcc-cgd-clean/inst/bin/../lib/gcc/
/usr/local/google/cgda-local/cgd/proj/gcc/gcc-cgd-clean/inst/bin/../lib/gcc/x86_64-linux/4.5.0/../../../../x86_64-linux/lib/x86_64-linux/4.5.0/
/usr/local/google/cgda-local/cgd/proj/gcc/gcc-cgd-clean/inst/bin/../lib/gcc/x86_64-linux/4.5.0/../../../../x86_64-linux/lib/
/usr/local/google/cgda-local/cgd/proj/gcc/gcc-cgd-clean/inst/bin/../lib/gcc/x86_64-linux/4.5.0/../../../x86_64-linux/4.5.0/
/usr/local/google/cgda-local/cgd/proj/gcc/gcc-cgd-clean/inst/bin/../lib/gcc/x86_64-linux/4.5.0/../../../
/lib/x86_64-linux/4.5.0/
/lib/
/usr/lib/x86_64-linux/4.5.0/
/usr/lib/

Note how they're not all at the start ofr the library directory list.

On one system I have (with a special build of libc and an older
version of gcc -- I can't really change it), one of the system library
paths with the mutilib suffix (e.g., /lib/../lib32) contains a
libgomp.spec which is incompatible with current libgomp.  With the
current -B behaviour, this bogus libgomp.spec is found in by the
libgomp -m32 tests (since the dir with the multilib suffix is tested
first), causing virtually all of the tests to fail.

If you've got a 64-bit Ubuntu system, you can replicate this problem
by doing "echo BROKEN > /lib32/libgomp.spec", then running the libgomp
tests with RUNTESTFLAGS="--target_board 'unix{-m32,-m64}'".  Normally
all libgomp tests pass (-m32 and -m64) for me, with BROKEN in
/lib32/libgomp.spec there are ~1000 -m32 failures.

The expected behaviour (at least, what I expect from historical
behaviour and from the -B description in the manual page 8-) is that
all of the -B-derived paths should come first.  The attached patch
implements this.

With this patch applied, the path list is:

[cgd@cgda gcc-cgd]$ inst/bin/gcc -B/foobar/ -m32 -print-search-dirs |
sed -e 's,$,\n,' -e 's,:,\n,g'
install
 /usr/local/google/cgda-local/cgd/proj/gcc/gcc-cgd/inst/bin/../lib/gcc/x86_64-linux/4.5.0/

programs
 =/foobar/x86_64-linux/4.5.0/
/foobar/
/usr/local/google/cgda-local/cgd/proj/gcc/gcc-cgd/inst/bin/../libexec/gcc/x86_64-linux/4.5.0/
/usr/local/google/cgda-local/cgd/proj/gcc/gcc-cgd/inst/bin/../libexec/gcc/
/usr/local/google/cgda-local/cgd/proj/gcc/gcc-cgd/inst/bin/../lib/gcc/x86_64-linux/4.5.0/../../../../x86_64-linux/bin/x86_64-linux/4.5.0/
/usr/local/google/cgda-local/cgd/proj/gcc/gcc-cgd/inst/bin/../lib/gcc/x86_64-linux/4.5.0/../../../../x86_64-linux/bin/

libraries
 =/foobar/x86_64-linux/4.5.0/32/
/foobar/32/
/foobar/x86_64-linux/4.5.0/
/foobar/
/usr/local/google/cgda-local/cgd/proj/gcc/gcc-cgd/inst/bin/../lib/gcc/x86_64-linux/4.5.0/32/
/usr/local/google/cgda-local/cgd/proj/gcc/gcc-cgd/inst/bin/../lib/gcc/32/
/usr/local/google/cgda-local/cgd/proj/gcc/gcc-cgd/inst/bin/../lib/gcc/x86_64-linux/4.5.0/../../../../x86_64-linux/lib/x86_64-linux/4.5.0/32/
/usr/local/google/cgda-local/cgd/proj/gcc/gcc-cgd/inst/bin/../lib/gcc/x86_64-linux/4.5.0/../../../../x86_64-linux/lib/../lib32/
/usr/local/google/cgda-local/cgd/proj/gcc/gcc-cgd/inst/bin/../lib/gcc/x86_64-linux/4.5.0/../../../x86_64-linux/4.5.0/32/
/usr/local/google/cgda-local/cgd/proj/gcc/gcc-cgd/inst/bin/../lib/gcc/x86_64-linux/4.5.0/../../../../lib32/
/lib/x86_64-linux/4.5.0/32/
/lib/../lib32/
/usr/lib/x86_64-linux/4.5.0/32/
/usr/lib/../lib32/
/usr/local/google/cgda-local/cgd/proj/gcc/gcc-cgd/inst/bin/../lib/gcc/x86_64-linux/4.5.0/
/usr/local/google/cgda-local/cgd/proj/gcc/gcc-cgd/inst/bin/../lib/gcc/
/usr/local/google/cgda-local/cgd/proj/gcc/gcc-cgd/inst/bin/../lib/gcc/x86_64-linux/4.5.0/../../../../x86_64-linux/lib/x86_64-linux/4.5.0/
/usr/local/google/cgda-local/cgd/proj/gcc/gcc-cgd/inst/bin/../lib/gcc/x86_64-linux/4.5.0/../../../../x86_64-linux/lib/
/usr/local/google/cgda-local/cgd/proj/gcc/gcc-cgd/inst/bin/../lib/gcc/x86_64-linux/4.5.0/../../../x86_64-linux/4.5.0/
/usr/local/google/cgda-local/cgd/proj/gcc/gcc-cgd/inst/bin/../lib/gcc/x86_64-linux/4.5.0/../../../
/lib/x86_64-linux/4.5.0/
/lib/
/usr/lib/x86_64-linux/4.5.0/
/usr/lib/

As you can see all of the -B-relative paths show up first in the list.
 With this change, all of the libgomp tests pass even with a bogus
libgomp.spec in /lib32.


IMO the path list handling is still a little bit funky because if you
use -B/foobar/ -B/foobar2/ you get:
libraries
 =/foobar/x86_64-linux/4.5.0/32/
/foobar/32/
/foobar2/x86_64-linux/4.5.0/32/
/foobar2/32/
/foobar/x86_64-linux/4.5.0/
/foobar/
/foobar2/x86_64-linux/4.5.0/
/foobar2/
...

but the *exact* behaviour isn't specified AFAICT.   I could see an
argument that says that the each path in the list should be tried with
and then without the multilib suffix... but I suspect that might have
negative consequences on some systems.


bootstrapped before/after for x86_64-linux, tested before/after with
make -j3 check -k RUNTESTFLAGS="--target_board 'unix{-m32,-m64}'".
Testsuite results identical.

Added the bogus /lib32/libgomp.spec, re-ran just the libgomp tests
with make check RUNTESTFLAGS="--target_board 'unix{-m32,-m64}'".
Unmodified sources fail ~1000 -m32 tests, with this patch all pass.


chris
----
2009-09-03  Chris Demetriou  <cgd@google.com>

        * gcc.c (for_each_path_with_priority): Renamed from for_each_path,
        priority argument added, changed to process one priority at a time.
        (for_each_path): New implementation: call for_each_path_with_priority
        for each path_prefix_priority value.
        (path_prefix_priority): Move up in file (to be above for_each_path).
        (add_prefix, add_sysrooted_prefix): Fix name of path_prefix_priority
        in comment.

Attachment: Bpaths.patch
Description: Binary data