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

--- Comment #13 from Iain Sandoe <iains at gcc dot gnu.org> 2010-12-14 09:09:07 
UTC ---
(In reply to comment #12)
> I have regstrapped the patch in comment #7 on top of revision 167770. The
> failures corresponding to this PR are gone. However I see the following for
> both -m32 and -m64:
> 
> FAIL: g++.dg/tree-prof/partition2.C compilation,  -g  -fprofile-use
> UNRESOLVED: g++.dg/tree-prof/partition2.C execution,    -g  -fprofile-use
> FAIL: g++.dg/tree-prof/partition2.C compilation,  -O3 -g  -fprofile-use
> UNRESOLVED: g++.dg/tree-prof/partition2.C execution,    -O3 -g  -fprofile-use
> 
> the corresponding typical log entry being
> 
> Executing on host: /opt/gcc/build_w/gcc/testsuite/g++/../../g++
> -B/opt/gcc/build_w/gcc/testsuite/g++/../../
> /opt/gcc/work/gcc/testsuite/g++.dg/tree-prof/partition2.C  -nostdinc++
> -I/opt/gcc/build_w/x86_64-apple-darwin10.5.0/i386/libstdc++-v3/include/x86_64-apple-darwin10.5.0
> -I/opt/gcc/build_w/x86_64-apple-darwin10.5.0/i386/libstdc++-v3/include
> -I/opt/gcc/work/libstdc++-v3/libsupc++
> -I/opt/gcc/work/libstdc++-v3/include/backward
> -I/opt/gcc/work/libstdc++-v3/testsuite/util -fmessage-length=0  -g 
> -fnon-call-exceptions -freorder-blocks-and-partition -fprofile-use   
> -L/opt/gcc/build_w/x86_64-apple-darwin10.5.0/i386/libstdc++-v3/src/.libs 
> -B/opt/gcc/build_w/x86_64-apple-darwin10.5.0/i386/libstdc++-v3/src/.libs 
> -L/opt/gcc/build_w/x86_64-apple-darwin10.5.0/i386/libstdc++-v3/src/.libs
> -L/opt/gcc/build_w/x86_64-apple-darwin10.5.0/i386/libiberty  -multiply_defined
> suppress -lm   -m32 -o /opt/gcc/build_w/gcc/testsuite/g++/partition2.x02   
> (timeout = 300)
> warning: no debug symbols in executable (-arch i386)^M
> output is:
> warning: no debug symbols in executable (-arch i386)^M
> 
> FAIL: g++.dg/tree-prof/partition2.C compilation,  -g  -fprofile-use
> UNRESOLVED: g++.dg/tree-prof/partition2.C execution,    -g  -fprofile-use
> 
> The key option is -g (the other tests of g++.dg/tree-prof/partition2.C without
> -g succeed). I don't know if these failures come from the patch or have been
> introduced between revisions 167731 and 167770 by an other commit.

I think this is a different problem - those messages are characteristic of
dsymutil missing an input file.
This might be related to the changes made to call dsymutil within collect2.

Is it possible to isolate the command and run it with -v ? and/or -Wl,-debug ?

Reply via email to