This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch] PR54645 move location_adhoc_data map into GC
On Mon, Sep 24, 2012 at 10:23 PM, Hans-Peter Nilsson <hp@bitrange.com> wrote:
> On Fri, 21 Sep 2012, Dehao Chen wrote:
>> This patch moves location_adhoc_data into GC, and also rebuild the
>> hash table when reading in the PCH. After the patch, PCH can work as
>> expected.
>>
>> Bootstrapped and passed gcc regression tests on x8664_linux.
>
> If you have a moment to consider improvements for the
> test-instructions at
> <http://gcc.gnu.org/contribute.html#testing> to try and avoid
> this situation (introducing regressions), that'd be nice; IIUC
> it wasn't clear enough that the "make check" must be at the top
> tree? It seems to say so but maybe that's somehow in a blind
> spot.
>
>>
>> OK for trunk?
>>
>> Thanks,
>> Dehao
>>
>> libcpp/ChangeLog:
>> 2012-09-21 Dehao Chen <dehao@google.com>
>>
>> PR middle-end/54645
>> * include/line-map.h (location_adhoc_data): Move location_adhoc_data
>> into GC.
>> (location_adhoc_data_map): Likewise.
>> (line_maps): Likewise.
>> (rebuild_location_adhoc_htab): New Function.
>> * line-map.c (+rebuild_location_adhoc_htab): new Funcion.
>> (get_combined_adhoc_loc): Move location_adhoc_data into GC.
>> (location_adhoc_data_fini): Likewise.
>> (linemap_init): Likewise.
>> (location_adhoc_data_init): Remove Function.
>>
>> gcc/ChangeLog:
>> 2012-09-21 Dehao Chen <dehao@google.com>
>>
>> PR middle-end/54645
>> * c-family/c-pch.c (c_common_read_pch): Rebuild the location_adhoc_data
>> map when read in the pch.
>
>
> I can't say anything insightful about this patch other than the
> nitpick below (i.e. I see nothing wrong with it) but I'd
> encourage a proper review of it to resolve the PCH regressions.
> There's no PCH section in MAINTAINERS, but "next-of-kin" global
> maintainers CC:ed.
IMHO the PCH implementation is awkward and that is enough of a reason
to remove PCH in its current form.
Richard.
> I have just a nitpicking remark: please break the overlong
> lines. I noticed the ones with htab_create calls as my viewer
> helpfully broke the lines at 80 columns at the last comma.
>
> brgds, H-P