[Bug bootstrap/66448] [6 Regression] Bootstrap fails on darwin after r224161

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

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

--- Comment #18 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Aldy Hernandez from comment #17)
> Created attachment 35744 [details]
> Call check_die on type DIEs and avoid DW_AT_aritificial attribs
> 

> >> I can't reproduce any of these with a cross compiler.  I'm building a cross
> >> with:
> >>
> >> --enable-languages=c,c++ --disable-bootstrap --disable-multilib
> >> --target=i686-darwin
> > 
> > The triple for the platform I'm testing on is :  x86_64-apple-darwin12
> 
> As a side note, if *-apple-darwin{10,12} is the more common variant (as
> opposed to *-apple-darwin which uses stabs), may I suggest speaking with the
> SC to put a more recent darwin on the secondary platform list instead of

I must confess, I was under the impression that the p2 was i686-apple-darwin10.
However, that is somewhat out of date (we should prob really default to
x86_64-apple-darwin??)  I think it's prob a good idea for the day-to-day Darwin
folks to discuss with the nominated maintainers and come up with some
recommendation to the SC.

> i686-apple-darwin which is stabs (and nobody cares bout stabs ;-)).
indeed ;-)

> >> ...but I still can't get cc1plus to trigger any ICE with the attached patch.
> > 
> > me neither - nevertheless...
> 
> Well, I was testing stabs apparently, but even so, the reason why the ICE
> did not trigger was because the duplicate attributes appear on a type DIE,
> not a decl DIE.  I was able to reproduce by looking at the assembly.
> 
> I added a check for type DIEs and found a slew of problems on Linux as well.
> It seems the Linux linker is far more permissive wrt dwarf.

Heh.. the "canaries" have their usesâ FWIW, ld64 and the other Darwin tools
used to be more forgiving too - they are gradually checking more and more and
being picky about atuff.

>  The attached
> patch fixes all the problems you reported that I could reproduce with a
> cross compiler for x86_64-apple-darwin10.  It also passes bootstrap and
> tests on x86-64 Linux.
> 
> Could you test it properly on darwin?

$ grep -rH "invalid DW" gcc/testsuite |wc -l
       0
thanks!

==== opinion needed:

OK - so now I have one remaining problem.  The change in my intial patch to
make the creation of the "extern int __CFConstantStringClassReference" lazily,
regresses obj-c++ (and, yes, I do care - it's needed to build some interesting
projects).

The reason is that the (lazy) creation will occur in some arbitrary scope - but
the decl really needs to be "pushdecl_top_level".  Unfortunatley, there's no
langhook for that (and Ada doesn't actually provide such a thing, AFAICT).

So â maybe I can find some (probably icky) way around this for Obj-C++ .. or
perhaps recommend a langhook for pushdecl_top_level().

An alternative is to say that var decls created at built-ins init time do not
need  debug?  If you were agreeable with this then a patch like 

 && DECL_SOURCE_LOCATION (decl) != BUILTINS_LOCATION

 as an additional test at passes.c:338, might be worth evaluating?

â or maybe it's practical to init debug before the inits?

WDYT?

(we need to move forward to unbreak Darwin bootstrap, so that we don't get
behind on catching other things - so I'd be inclined to the original patch as
band-aid, in the interim, if all elase fails)