From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9620 invoked by alias); 30 Oct 2014 13:55:51 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 9609 invoked by uid 89); 30 Oct 2014 13:55:50 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 X-HELO: relay1.mentorg.com Date: Thu, 30 Oct 2014 13:55:00 -0000 From: "Joseph S. Myers" To: Andrew Senkevich CC: libc-alpha Subject: Re: [RFC] How to add vector math functions to Glibc In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-SW-Source: 2014-10/txt/msg00743.txt.bz2 On Thu, 30 Oct 2014, Andrew Senkevich wrote: > > Well, maybe a preliminary refactoring patch is needed that separates FUNC > > into multiple macros, one for functions used in testsuite infrastructure > > and one for functions being tested. > > > > There are lots of RUN_TEST_* macros (I don't think we should assume that > > only one of them will only ever be relevant for vector tests) - it seems a > > bad idea for every one of them to need to repeat something so cryptic as > > CONCAT (CONCAT3_1 (VEC_PREFIX_, FUNC_NAME, FUNC ( )), FUNC (FUNC_NAME)). > > But it is already old code, yesterday's patch looks so in this place: > FUNC_TEST (FUNC_NAME) (ARG) As I said, *preliminary refactoring patch*. Long sequences of variations on the same patch aren't helpful; if you find yourself sending them, you need to step back and think very carefully about how to restructure the submission to make things as clear and as easy to review as possible. That includes separating out any pieces, large or small, that are reasonably separable and can be justified on their own merits. Having separated them, you then need to make *self-contained* submissions (including all relevant rationale and background), and ping those submissions weekly as needed (I haven't seen any pings of the binutils version requirement patch). And please keep the state for your own patches in patchwork.sourceware.org clean; I see six entries there with the same description "[RFC] How to add vector math functions to Glibc", when there should be at most one. If you do need to make multiple submissions of successive versions of the same patch, consider the submission style where each submission contains both the full self-contained description and rationale (that would go in the git log message) and a separate description of what has changed relative to the previous patch version (and number each patch version). -- Joseph S. Myers joseph@codesourcery.com