[Bug fortran/68358] Some tests in gfortran.dg fail when compiled with '-g -flto' and Xcode 7

["iains at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68358

--- Comment #10 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Nenad Vukicevic from comment #9)
> On 11/24/15 12:07 PM, iains at gcc dot gnu.org wrote:
> 
> > So I agree, the root problem is that we are creating something that the newer
> > version of dsymutil doesn't understand - it could be we're making a mistake or
> > new dsymutil could be still green.
> 
> I tried to run Clang's llvm-dsymutil form the locally built clang tools.
>  Fails the same way.  And the error is coming from this routine:
> 
> 124 /// Interpret the STAB entries to fill the DebugMap.
> 125 void MachODebugMapParser::handleStabSymbolTableEntry(uint32_t
> 
> 
> > What happens if you do a clang link and then do "dsymutil result"?
> 
> Linking with clang and "dsymutil result" produces similar results -
> 'failed to insert symbol' messages.  But then it complains on lots of
> object files as it cannot find them.
> 
> I checked the clang code (and some logs) and clang does NOT call
> dsymutil for our case.
> 
> Note that we are compiling through a fairly complex UPC driver, part of
> Berkeley UPC toolset, and we get this warnings only if our back-end
> compiler is GCC from our GNU UPC branch (which is in sync with the
> trunk).  Using Clang as back-end compiler does not produce warning as
> they do not run the tool at the and - linking phase.

OK so it appears that we do have two issues;

1. that we're (incorrectly) calling dsymutil for "link only" cases where
there's no LTO involved (and that seems to be a typo in the argument to
post_ld_pass() on line 820).  We located the PR that gave rise to the change
(61352) and will just double-check that we do not regress that with the change.
 Could you make the change locally and see if it makes the problem "go away"?
(I note that it doesn't in any way fix #2).

2. Some as yet unexplained issue with new dsymutil
it's probable that if you can do something like:

clang a.o b.o .... z.o -g -o t 
dsymutil t
and get errors - then the right thing is to file a radar (since that's really
only using ld64 and dsymutil - which are both outside the GCC source base).

It's possible that there's some fault  with symbols in the object files that
doesn't somehow affect linking and doesn't trip up nm .. but adversely affects
dsymutil - not sure I can exactly envision that right now.