This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH RFA] always process -B paths first.
ping?
On Fri, Sep 4, 2009 at 23:55, Chris Demetriou <cgd@google.com> wrote:
> 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.
>