This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On 02/19/2015 08:50 AM, Jakub Jelinek wrote:
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),
Sure, that sounds reasonable. Patch attached.
perhaps error out if you try to generate PCH with -feliminate-dwarf2-dups?
Well, any PCH file we generate will have some sort of early DIE in it (at the very least the compilation unit DIE) and we will read these in at PCH read-in time, obliterating whatever was already there. But most importantly, with the attached patch we will not use these DW_TAG_GNU_[BE]INCL* DIEs, since the reader will avoid reading the pch file. So, I don't think erroring out at output time is necessary.
How does this look?
Attachment:
curr
Description: Text document
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |