This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug math/21047] arm: fpu_control.h: _FPU_GETCW/_FPU_SETCW is rejected by clang
- From: "joseph at codesourcery dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Fri, 13 Jan 2017 17:10:10 +0000
- Subject: [Bug math/21047] arm: fpu_control.h: _FPU_GETCW/_FPU_SETCW is rejected by clang
- Auto-submitted: auto-generated
- References: <bug-21047-131@http.sourceware.org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=21047
--- Comment #3 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
I interpret such statements in terms of semantics of certain encodings
being defined elsewhere, not in terms of what source code the assembler
should accept (where there is a clear use for being able to assemble the
instructions in runtime-conditional code when VFP is otherwise disabled
and without marking the objects as depending on VFP). There is of course
the possibility of using .inst directives but then you have to deal with
ARM/Thumb encoding differences which would run into problems with
attributes being used to control whether a particular function is ARM or
Thumb, and I'm not sure it would be possible to substitute an operand
register number appropriately in such a directive.
That is, the ability to access arbitrary coprocessor numbers via the
generic names, corresponding to where the ARMv7 ARM (and v8 before version
j) says 'if coproc IN "101x" then SEE "Advanced SIMD and Floating-point";'
(and where it permits other coprocessor numbers also not allowed for v8,
as used in the setjmp / longjmp iWMMXt support) is part of the GNU
assembler syntax required for building glibc. This functionality is
however not needed in any essential way for hard-float builds or use of
the installed header so it would be reasonable for the installed header to
use the explicit VFP syntax in the hard-float case if someone wishes to
implement that, for greater compatibility with different assemblers.
--
You are receiving this mail because:
You are on the CC list for the bug.