On Thu, Feb 19, 2015 at 08:45:08AM -0800, Aldy Hernandez wrote:
> [And this time, actually CCing the list :)].
>
> Gentlemen!
>
> Reading in the compiler state for pch (gt_pch_restore) obliterates the
> DIE table, and consequently the DW_TAG_GNU_[BE]INCL* DIEs that may have
> been in it. This causes inconsistencies when reading in _any_
> pre-compiled header into a source file that uses
> -feliminate-dwarf2-dups, and consequently already has some
> DW_TAG_GNU_[BE]INCL* DIEs.
>
> Normally the DIE table should be empty this early on, especially since
> mainline generates dwarf at the end of the compilation unit, but the DIE
> table may have DW_TAG_GNU_[BE]INCL* DIEs that were created early by
> dwarf2out_start_source_file/etc or it may have the DW_TAG_compile_unit.
>
> I suppose we could merge incoming DIEs with existing DIEs and complicate
> our lives, but considering we will probably have to tackle this in the
> debug-early work, I propose we disable this combination for now (and
> possibly permanently, unless we really care about it).
>
> OK for mainline pending tests?
Wouldn't it be better to disable PCH reading if -feliminate-dwarf2-dups
is used? I mean, fail to read the PCH silently (or with warning for -Wpch
or what the warning is about why PCH couldn't be read or was ignored),
perhaps error out if you try to generate PCH with -feliminate-dwarf2-dups?
Jakub
