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 #1 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
See what I said on #glibc on 2016-02-22.  In short: the present form is 
deliberate and required for use within glibc built for soft-float where 
use of these macros is runtime-conditional.  It would be OK to use 
explicitly VFP forms in the !__SOFTFP__ case (both inside and outside 
glibc; outside glibc this code isn't used for __SOFTFP__ anyway).

[2016-02-22 23:11:49] <norris> I'm seeing some clang issues on ARM/glibc, 
due to a glibc FPU macro
[2016-02-22 23:12:03] <norris> llvm folks seem to suggest it's glibc's 
problem: https://llvm.org/bugs/show_bug.cgi?id=23998
[2016-02-22 23:12:25] <norris> should I file a glibc bug?
[2016-02-22 23:15:27] <jsm28> norris: glibc deliberately uses the mrc/mcr 
forms of coprocessor instructions in various cases.
[2016-02-22 23:15:50] <jsm28> norris: For example, these macros need to 
work in runtime conditional code in glibc that is compiled without VFP 
enabled in the compiler.
[2016-02-22 23:16:08] <jsm28> norris: So use of vmrs/vmsr would not be 
appropriate.
[2016-02-22 23:17:04] <jsm28> norris: Though when not compiling glibc, 
these macro definitions are conditional on VFP being enabled, so you 
should never see them with VFP disabled.
[2016-02-22 23:18:02] <jsm28> norris: So if you want to file a glibc bug, 
you'll need a better justification of why these instructions are actually 
invalid in this context (VFP enabled), not the assertions about another 
way to write them.
[2016-02-22 23:49:06] <norris> jsm28: hmm, well the LLVM devs seem to 
think these instructions aren't required on ARV v7a, even with VFP. I'm 
not much of an expert to convince otherwise
[2016-02-22 23:49:14] <norris> jsm28: thanks though!
[2016-02-22 23:49:26] <jsm28> norris: I don't consider this a meaningful 
thing to think.
[2016-02-22 23:49:59] <jsm28> norris: They are, or are meant to be, simply 
the generic way of writing certain VFP instructions.  I.e., they must be 
supported exactly when those VFP instructions are supported.
[2016-02-22 23:50:49] <jsm28> norris: If they didn't correctly correspond 
to the encodings of those VFP instructions, the problem would be much more 
obvious.  So I must assume they are correctly encoded.
[2016-02-22 23:52:03] <jsm28> norris: As far as I'm concerned, it's 
fundamentally ill-conceived for an assembler to try to reject these ways 
of writing these instructions, as the LLVM assembler apparently is doing.

-- 
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]