This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug math/21047] arm: fpu_control.h: _FPU_GETCW/_FPU_SETCW is rejected by clang


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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]