From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 60214 invoked by alias); 9 Nov 2015 21:56:57 -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 60205 invoked by uid 89); 9 Nov 2015 21:56:56 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.8 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD autolearn=no version=3.3.2 X-HELO: paperclip.tbsaunde.org Received: from tbsaunde.org (HELO paperclip.tbsaunde.org) (66.228.47.254) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 09 Nov 2015 21:56:55 +0000 Received: from tsaunders-iceball.corp.tor1.mozilla.com (unknown [66.207.193.21]) by paperclip.tbsaunde.org (Postfix) with ESMTPSA id 21313C06D; Mon, 9 Nov 2015 21:56:53 +0000 (UTC) Date: Mon, 09 Nov 2015 21:56:00 -0000 From: Trevor Saunders To: Bernd Schmidt Cc: Jeff Law , tbsaunde+gcc@tbsaunde.org, gcc-patches@gcc.gnu.org Subject: Re: [PATCH 05/12] always define VMS_DEBUGGING_INFO Message-ID: <20151109215651.GI22527@tsaunders-iceball.corp.tor1.mozilla.com> References: <1447087669-14039-1-git-send-email-tbsaunde+gcc@tbsaunde.org> <1447087669-14039-6-git-send-email-tbsaunde+gcc@tbsaunde.org> <5640E729.9010605@redhat.com> <5640E98E.2040909@redhat.com> <20151109192904.GE22527@tsaunders-iceball.corp.tor1.mozilla.com> <5640F5EF.9000700@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5640F5EF.9000700@redhat.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-SW-Source: 2015-11/txt/msg01109.txt.bz2 On Mon, Nov 09, 2015 at 08:37:19PM +0100, Bernd Schmidt wrote: > On 11/09/2015 08:29 PM, Trevor Saunders wrote: > >as I said in 0/12 this did go through config-list.mk, and checking again > >this does build on alpha-dec-vms. > > The question I have is - why does it build on any other target? It's the > reference that's unconditional, not the definition. Do we have enough DCE at > -O0 to eliminate the reference? It's still incorrect IMO (and should be > fixed in the other patches as well. dce would be my guess. I guess going back to #if ing the bits that reference it, and then incrementally removing the #ifs starting with the ones defining the functions used in the structs, but given you seem to be against patches that only change ifdef to #if you might not likethat :( > > > >I'd actually really rather review them, or really deal with them in any > >way, the way they are. Smaller simpler patches that only deal with one > >thing are much better. I think the most macros that appear on one line > >are 2, so at most you could lower that to 1 change instead of 2, but who > >really cares anyway? > > Well, I do, because I get to see this stuff: > > -#if 1 < (defined (DBX_DEBUGGING_INFO) + defined (SDB_DEBUGGING_INFO) \ > +#if 1 < (defined (DBX_DEBUGGING_INFO) + (SDB_DEBUGGING_INFO) \ > + defined (DWARF2_DEBUGGING_INFO) + defined (XCOFF_DEBUGGING_INFO) > \ > + defined (VMS_DEBUGGING_INFO)) > > #if 1 < (defined (DBX_DEBUGGING_INFO) + (SDB_DEBUGGING_INFO) \ > - + defined (DWARF2_DEBUGGING_INFO) + defined (XCOFF_DEBUGGING_INFO) > \ > + + defined (DWARF2_DEBUGGING_INFO) + (XCOFF_DEBUGGING_INFO) \ > + defined (VMS_DEBUGGING_INFO)) > > #if 1 < (defined (DBX_DEBUGGING_INFO) + (SDB_DEBUGGING_INFO) \ > + defined (DWARF2_DEBUGGING_INFO) + (XCOFF_DEBUGGING_INFO) \ > - + defined (VMS_DEBUGGING_INFO)) > + + (VMS_DEBUGGING_INFO)) > > #if 1 < (defined (DBX_DEBUGGING_INFO) + (SDB_DEBUGGING_INFO) \ > - + defined (DWARF2_DEBUGGING_INFO) + (XCOFF_DEBUGGING_INFO) \ > + + (DWARF2_DEBUGGING_INFO) + (XCOFF_DEBUGGING_INFO) \ > + (VMS_DEBUGGING_INFO)) > > -#if 1 < (defined (DBX_DEBUGGING_INFO) + (SDB_DEBUGGING_INFO) \ > +#if 1 < ((DBX_DEBUGGING_INFO) + (SDB_DEBUGGING_INFO) \ > + (DWARF2_DEBUGGING_INFO) + (XCOFF_DEBUGGING_INFO) \ > + (VMS_DEBUGGING_INFO)) > > etc. other than reading this now I'm not sure what the context would be, but either way personally I really don't mind reading that, and think its simpler to reason about the correctness of one thing at a time. Trev > > > Bernd