This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch 0/3] Header file reduction.
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Jeff Law <law at redhat dot com>
- Cc: Andrew MacLeod <amacleod at redhat dot com>, Bernd Schmidt <bschmidt at redhat dot com>, gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 7 Oct 2015 10:16:02 +0200
- Subject: Re: [patch 0/3] Header file reduction.
- Authentication-results: sourceware.org; auth=none
- References: <560DEA79 dot 8050709 at redhat dot com> <56127AA4 dot 9090707 at redhat dot com> <5612D925 dot 2040806 at redhat dot com> <5614409D dot 8080007 at redhat dot com>
On Tue, Oct 6, 2015 at 11:43 PM, Jeff Law <law@redhat.com> wrote:
> On 10/05/2015 02:10 PM, Andrew MacLeod wrote:
>>>
>>>
>>> Is the bitmap/obstack example really one of a change that is
>>> desirable? I think if a file uses obstacks then an include of
>>> obstack.h is perfectly fine, giving us freedom to e.g. change bitmaps
>>> not to use obstacks. Given that multiple headers include obstack.h,
>>> and pretty much everything seems to indirectly include bitmap.h
>>> anyway, maybe a better change would be to just include it always in
>>> system.h.
>>
>>
>> Its just an example of the sort of redundant includes the tool removes.
>
> It may not be the best example. The tools don't treat obstack specially
> (nor should they IMHO). So let's pretend it's not obstack.h which has been
> arguably a core part of GCC for a long time.
>
>>
>> I don't see the point in leaving redundant #includes in the source
>> code because of direct uses from that header in the source. I'm not
>> even sure how I could automate detecting that accurately.. Going
>> forward, If anyone ever makes a change which removes a header from an
>> include file, they just have to correct the fallout. heh. Thats kinda
>> all I've done for 4 months :-) At least we'll have grasp of the
>> ramifications..
>
> And the last sentence is the key here. We're trying to get to a point where
> we can make certain kinds of changes, then have the compiler spit out
> errors, fix the errors and have a high degree of confidence that the final
> change is correct and that we've found all the places that need to change.
>
> The change could be as simple as moving a function declaration to its
> natural place, collecting interfaces & data into classes, or something more
> ambitious like removing trees from the backend. Folks will note that these
> are all refactorings that we don't want to change any observable behaviour.
>
>
>
>
>
>>> * diff -c is somewhat unusual and I find diff -u much more readable.
>>
>>
>> unsual? I've been using -cp for the past 2 decades and no one has ever
>> mentioned it before... poking around the wiki I see it mentions you
>> can use either -up or -cp.
>>
>> I guess I could repackage things using -up... I don't even know where
>> my script is to change it :-). is -u what everyone uses now? no one
>> has mentioned it before that I am aware of.
>
> I'm probably the last person in the world that still generally prefers -cp
> :-) I'm getting to the point where I can tolerate -u.
No, I prefer -cp too - diff just too easily makes a mess out of diffs with -u,
esp. if you have re-indenting going on as well.
Richard.
>
>>
>>
>>> * Maybe the patches for reordering and removing should be split, also
>>> for readability and for easier future identification of problems.
>>>
>> I was trying to avoid too much churn on 550ish files... I didn't think
>> each one needed 2 sets of check-ins. It could be done, but it will
>> take a while. The reordering patch can be quickly generated, but the
>> reduction on all those files will take the better part of a week.
>>
>> My theory is it perfectly safe to back out any single file from the
>> patch set if we discover it has an issue and then examine what the root
>> of the problem is..
>>
>> tool patch coming shortly... probably tomorrow now.
>
> I haven't looked at the 3 patches in detail yet. Given my familiarity with
> the overall process/goal, I can probably handle them as-is. They're just big
> mechanical changes.
>
> jeff