From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 109347 invoked by alias); 6 Oct 2015 21:44:02 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 109329 invoked by uid 89); 6 Oct 2015 21:44:01 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Tue, 06 Oct 2015 21:43:59 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id 7F0912F6 for ; Tue, 6 Oct 2015 21:43:58 +0000 (UTC) Received: from localhost.localdomain (ovpn-113-105.phx2.redhat.com [10.3.113.105]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t96LhvJC002249; Tue, 6 Oct 2015 17:43:58 -0400 Subject: Re: [patch 0/3] Header file reduction. To: Andrew MacLeod , Bernd Schmidt , gcc-patches References: <560DEA79.8050709@redhat.com> <56127AA4.9090707@redhat.com> <5612D925.2040806@redhat.com> From: Jeff Law Message-ID: <5614409D.8080007@redhat.com> Date: Tue, 06 Oct 2015 21:44:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <5612D925.2040806@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-10/txt/msg00643.txt.bz2 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. > > >> * 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