* Dynamic VFP support and math/test-fpucw
@ 2013-06-17 19:18 Joseph S. Myers
2013-06-17 19:41 ` Roland McGrath
0 siblings, 1 reply; 4+ messages in thread
From: Joseph S. Myers @ 2013-06-17 19:18 UTC (permalink / raw)
To: libc-ports
On ARM systems without VFP hardware, the test math/test-fpucw fails
because it tries to use _FPU_GETCW, so using unsupported VFP instructions.
Normal user programs using _FPU_GETCW in a soft-float configuration would
get the fallback soft-float version of that macro and so not have that
issue. But the condition for the soft-float version is
#if !defined(_LIBC) && defined(__SOFTFP__)
and _LIBC is defined when testcases are built, not just for building the
installed libraries.
Really I think most testcases should be built using an environment more
like that for ordinary user programs, not using internal headers
(including include/ wrappers) or defining _LIBC unless there is a specific
need to do so in a particular testcase. But in the absence of such a
testsuite overhaul, how might one best stop this testcase failing? One
obvious possibility is to use e.g. _LIBC_DYNAMIC_VFP rather than just
_LIBC in fpu_control.h, and then to define _LIBC_DYNAMIC_VFP in another
header (not used in the testcase), e.g. arm-features.h. But that would
introduce a header ordering dependency (arm-features.h needs to be
included before fpu_control.h), and while one could make arm-features.h
use #error if fpu_control.h was included first, this still seems rather
fragile.
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Dynamic VFP support and math/test-fpucw
2013-06-17 19:18 Dynamic VFP support and math/test-fpucw Joseph S. Myers
@ 2013-06-17 19:41 ` Roland McGrath
2013-06-17 21:40 ` Joseph S. Myers
0 siblings, 1 reply; 4+ messages in thread
From: Roland McGrath @ 2013-06-17 19:41 UTC (permalink / raw)
To: Joseph S. Myers; +Cc: libc-ports
You could override the test with a sysdeps/arm/test-fpucw.c.
You could override the installed fpu_control.h with a
sysdeps/arm/include/fpu_control.h that tests NOT_IN_libc or something.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Dynamic VFP support and math/test-fpucw
2013-06-17 19:41 ` Roland McGrath
@ 2013-06-17 21:40 ` Joseph S. Myers
2013-06-17 22:03 ` Roland McGrath
0 siblings, 1 reply; 4+ messages in thread
From: Joseph S. Myers @ 2013-06-17 21:40 UTC (permalink / raw)
To: Roland McGrath; +Cc: libc-ports
On Mon, 17 Jun 2013, Roland McGrath wrote:
> You could override the test with a sysdeps/arm/test-fpucw.c.
> You could override the installed fpu_control.h with a
> sysdeps/arm/include/fpu_control.h that tests NOT_IN_libc or something.
The trouble is, those options seem rather fragile as well. 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). 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. 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).
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Dynamic VFP support and math/test-fpucw
2013-06-17 21:40 ` Joseph S. Myers
@ 2013-06-17 22:03 ` Roland McGrath
0 siblings, 0 replies; 4+ messages in thread
From: Roland McGrath @ 2013-06-17 22:03 UTC (permalink / raw)
To: Joseph S. Myers; +Cc: libc-ports
> 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
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2013-06-17 22:03 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-06-17 19:18 Dynamic VFP support and math/test-fpucw 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 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).