From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11308 invoked by alias); 26 Jun 2010 11:00:21 -0000 Received: (qmail 11271 invoked by uid 22791); 26 Jun 2010 11:00:18 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 26 Jun 2010 11:00:08 +0000 Received: (qmail 14590 invoked from network); 26 Jun 2010 11:00:06 -0000 Received: from unknown (HELO digraph.polyomino.org.uk) (joseph@127.0.0.2) by mail.codesourcery.com with ESMTPA; 26 Jun 2010 11:00:06 -0000 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.69) (envelope-from ) id 1OST7E-0007OV-IT; Sat, 26 Jun 2010 11:00:04 +0000 Date: Sat, 26 Jun 2010 13:08:00 -0000 From: "Joseph S. Myers" To: Joern Rennecke cc: gcc-patches@gcc.gnu.org Subject: Re: RFA: Fix other/44566 In-Reply-To: <20100626061802.45a3nzzz4088o840-nzlynne@webmail.spamcop.net> Message-ID: References: <20100626061802.45a3nzzz4088o840-nzlynne@webmail.spamcop.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 X-SW-Source: 2010-06/txt/msg02663.txt.bz2 Could you give a general description of the approach you have taken, the limitations of it and the extent to which those limitations will be detected when GCC is built and run? I have a long list of things I'd expect to be included in multi-target support, from a previous analysis I did, that are not included in this patch and that I don't see how this avoids, so I'd like the high-level overview. How have you validated this patch? Have you for example built a large body of code with two single-target compilers and for both targets of a two-target compiler and verified that the code is identical for both ways of building for a given target? Ideally this would go in the installation, user and internals manuals, as applicable. The information in install.texi in this patch seems extremely limited. Random README files for bits of internals are strongly deprecated; put the information in README-multi-target in the internals manual instead. It needs to be clear from the internals manual what maintainers need to do with START_TARGET_SPECIFIC, EXTRA_TARGET, EXTRA_TARGETS_DECL, etc., when making changes to the compiler: the circumstances in which they need to include or change such code so as not to break the invariants of multi-target configurations working and generating identical code when you select any one of the multiple targets to that generated by a single-target configuration for that target. (If there isn't a clear and simple explanation with the present version of the code, that would indicate that more work is needed before it is ready to go in.) > +Usually, the compiler is only built for a sigle target tarchitecture or "single", "architecture" > +E.g. to build a cross compiler with the main target ppc-elf and the Use "@:" or comma after "E.g.". > +all selected targets must agree in how they define @var{BITS_PER_UNIT}. You mean @code{BITS_PER_UNIT}. The conversion of OVERRIDE_OPTIONS to a hook definitely needs to be submitted first as a separate patch (though the initial conversion would have the hook take (void)). Patches should not add their own ChangeLog files (ChangeLog.multi-target in this case). -- Joseph S. Myers joseph@codesourcery.com