From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5330 invoked by alias); 17 Jun 2013 22:03:13 -0000 Mailing-List: contact libc-ports-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: libc-ports-owner@sourceware.org Received: (qmail 5320 invoked by uid 89); 17 Jun 2013 22:03:13 -0000 X-Spam-SWARE-Status: No, score=-3.1 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED autolearn=ham version=3.3.1 Received: from toast.topped-with-meat.com (HELO topped-with-meat.com) (204.197.218.159) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Mon, 17 Jun 2013 22:03:11 +0000 Received: by topped-with-meat.com (Postfix, from userid 5281) id C0B982C0AA; Mon, 17 Jun 2013 15:03:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roland McGrath To: "Joseph S. Myers" Cc: Subject: Re: Dynamic VFP support and math/test-fpucw In-Reply-To: Joseph S. Myers's message of Monday, 17 June 2013 21:40:53 +0000 References: <20130617194154.2287E2C095@topped-with-meat.com> Message-Id: <20130617220309.C0B982C0AA@topped-with-meat.com> Date: Mon, 17 Jun 2013 22:03:00 -0000 X-CMAE-Score: 0 X-CMAE-Analysis: v=2.1 cv=LYSvtFvi c=1 sm=1 tr=0 a=WkljmVdYkabdwxfqvArNOQ==:117 a=14OXPxybAAAA:8 a=o-W1PLrASD0A:10 a=Z6MIti7PxpgA:10 a=kj9zAlcOel0A:10 a=hOe2yjtxAAAA:8 a=DNBEqYk1t7QA:10 a=F--PFVKCDjuVMYtZuC4A:9 a=CjuIK1q_8ugA:10 X-SW-Source: 2013-06/txt/msg00028.txt.bz2 > The trouble is, those options seem rather fragile as well. Sure. I was just offering potential paths given the status quo. We now that the eventual solution will be to clean up how we build test programs. That's not something you can rely on any time soon, but perhaps that being the plan for the future is sufficient to worry less than you might otherwise about fragility in a solution that is just a workaround pending that future. > Maybe the least bad is overriding the test with a file that just defines > e.g. _LIBC_TEST and includes the main test-fpucw.c (with fpu_control.h > then checking _LIBC_TEST). That is indeed tolerable. > The difficulty with the second is that dynamic VFP detection is used in > both libc and libm, so NOT_IN_libc isn't sufficient on its own. If this is saying something more subtle than that you'll want: #if !defined NOT_IN_libc && !defined IS_IN_libm then I am not following. > Really I suppose what's wanted, in the absence of not defining _LIBC for > tests, would be a macro such as IN_tests that gets automatically defined > for testcase code; then at least fpu_control.h could test that after > _LIBC (if it's only tested conditional on _LIBC, namespace issues > wouldn't matter for IN_tests because no user application should ever > define _LIBC). Defining IN_tests is easy enough. Having an installed header refer to an IN_* identifier (even if technically "safe") is beyond the pale, IMHO. Thanks, Roland