This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: RFA (c-common): PATCH to add typeinfo for ARM fp16 type to libsupc++
On Thu, 12 Nov 2009, Jason Merrill wrote:
> > Also, __fp16 is only supported with a -mfp16-format option, and libstdc++
> > is not normally built with either of the two possible values for that
> > option (and so is compatible with user code using either setting), so will
> > it in fact provide that typeinfo? Building that file in libsupc++ with
> > one -mfp16-format option isn't going to work; the EABI build attributes in
> > the object file would mark it incompatible with code built with the other
> > option.
>
> Ah. So does the ARM EABI say anything about the typeinfo for __fp16? We could
> just emit it when used if it's target-specific.
I didn't see anything about it in a quick check, or notice anything in
previous detailed checks I've done for GNU toolchain EABI conformance
issues.
I think the general principle here is: the set of types whose typeinfo
should go in libsupc++ is not necessarily the same as the set of built-in
types the compiler has enabled when building libstdc++; the latter may
depend on compiler options that are not generally considered ABI-breaking,
while the former should be the same among libraries built with different
ABI compatible options. It may be appropriate to put typeinfo for some
such types (e.g. x86/x86_64 __float128?) in libsupc++, but doing so needs
to be a deliberate decision for each built-in type, and not conditional on
compiler options that might affect type availability without otherwise
affecting the ABI.
(Standard target-independent half-precision bindings for C look like being
something post-C1x, and I presume such bindings for C++ are post-C++0x;
the WG14 study group on IEEE 754-2008 bindings is explicitly supposed to
produce recommentations after C1x is done. ARM deliberately disallowed
various things in their C binding - that RealView implements, and GCC
implements for ARM - to avoid issues with possibly specifying that they be
accepted with semantics different from what WG14 might end up with.)
--
Joseph S. Myers
joseph@codesourcery.com