public inbox for libc-ports@sourceware.org
 help / color / mirror / Atom feed
From: Roland McGrath <roland@hack.frob.com>
To: "Joseph S. Myers" <joseph@codesourcery.com>
Cc: <libc-ports@sourceware.org>
Subject: Re: Dynamic VFP support and math/test-fpucw
Date: Mon, 17 Jun 2013 22:03:00 -0000	[thread overview]
Message-ID: <20130617220309.C0B982C0AA@topped-with-meat.com> (raw)
In-Reply-To: Joseph S. Myers's message of  Monday, 17 June 2013 21:40:53 +0000 <Pine.LNX.4.64.1306172135580.15498@digraph.polyomino.org.uk>

> 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

      reply	other threads:[~2013-06-17 22:03 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-17 19:18 Joseph S. Myers
2013-06-17 19:41 ` Roland McGrath
2013-06-17 21:40   ` Joseph S. Myers
2013-06-17 22:03     ` Roland McGrath [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130617220309.C0B982C0AA@topped-with-meat.com \
    --to=roland@hack.frob.com \
    --cc=joseph@codesourcery.com \
    --cc=libc-ports@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).