[Bug 157] using -O{1,2,3} together with -g causes ICE (seg fault)

via D.gnu d.gnu at puremagic.com
Wed Aug 2 11:18:34 PDT 2017


https://bugzilla.gdcproject.org/show_bug.cgi?id=157

--- Comment #5 from Iain Buclaw <ibuclaw at gdcproject.org> ---
> So this explains why this bug vanished in newer releases. We may still have a template emission bug here though:

Are you sure?  I mean, if this is a nested instantiation, then it will be
treated as non-public (static in the C sense).  So any unreferenced functions
will be removed by the middle-end.


> @Iain any idea what to do about GCC 4.9 and 4.8? I could probably just amend the GCC patches to bave like GCC 5+ and always use the lto codepath... Or maybe this really is our fault as we're not emitting the toChars function.

I guess I see no problem just using backport, so long as it works.  But at the
same time, I'd like to minimise just how much effort is put into the older
versions.  Granted that they should be effectively in maintenance mode by now.
;-)


Looking at 4.9, I see that the same patch was applied as version 5.  So I was
initially unsure why you have a problem.

https://gcc.gnu.org/viewcvs/gcc/branches/gcc-4_9-branch/gcc/dwarf2out.c?r1=224072&r2=224071&pathrev=224072

But then I saw that infact this patch resulted in a regression in both 4.9 and
5, and the fix for that is where the real divergence happened.

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

So removing the !lto path won't help, it seemss.  The "proper" fix is already
done in master (calling register_main_translation_unit), so I assume this is in
all branches up to gcc-5 as well.

https://github.com/D-Programming-GDC/GDC/blob/3823c2f71bd7bc10c5184055eb9ee49da18106c0/gcc/d/d-lang.cc#L1380-L1392

Incidentally, done when addressing some other debugging woes.

https://github.com/D-Programming-GDC/GDC/commit/3c59416afa83bb0f2edd85fab3115c589b826306

-- 
You are receiving this mail because:
You are watching all bug changes.


More information about the D.gnu mailing list