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)
