This is the mail archive of the
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 12:56:31 +0000
- Subject: [Bug math/21047] arm: fpu_control.h: _FPU_GETCW/_FPU_SETCW is rejected by clang
- Auto-submitted: auto-generated
- References: <firstname.lastname@example.org/bugzilla/>
--- 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
[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
[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.