There are many issues with the current implementation of GNU attributes to mark
functions that use long double. The idea of .gnu_attributes was to mark
objects with ABI requirements.
The two patches in this thread fixes a small subset of the GNU attributes
problems. It does not fix all of the problems.
The first patch fixes the problem that we set the GNU attribute for long double
if a type were passed or returned that uses the same representation as the long
double type (i.e. passing explicit __float128/_Float128 when long double is
IEEE 128-bit or passing __ibm128 when long double is IBM 128-bit).
The second patch eliminates the code in rs6000_emit_move to set the long double
attribute. This eliminates the false positives that occur when a type uses a
mode that is the same mode as the long double type. However, to catch the
cases where long double is used without being passed or returned, we would need
to implement a GIMPLE pass that looked for explicit long double usage.
This patch also changes the the 3 tests that tested this move support to be
'XFAIL' until we flag long double usage correctly.
The current problems with GNU attributes are:
1) Probably the most annoying bug is that they apply at an object level.
So for example libgcc_s.so.1 is marked as using IBM long double causing
warnings when linking against code that uses 64-bit long doubles even
though such code won't use any of the libgcc 128-bit long double
functions.
a) Versions of ld prior to 2.35 did not check shared library
.gnu_attributes, a bug that might allow a user to link a
soft-float shared library with hard-float code.
2) The original implementation Alan Modra wrote in 2016 to mark relocatable
object files with attributes had, and still has, bugs.
a) It is possible for an object to be marked as using IBM long
double when a function has a long double parameter that is not
used.
b) It is possible for an object to not be marked as using IBM long
double when it does. For example, a function with a pointer to
long double parameter is not recognized as using long double.
This is conceptually difficult to fix. Does merely passing a
pointer to another function constitute a use? What about a
pointer to a union containing a long double?
c) An object that defines a global long double variables is not
marked.
d) Variable argument functions that process a long double in an
argument corresponding to the ellipsis are not marked.
3) One of the problems with GNU attributes is that it would signal a long
double was used when in reality an alternate type was returned or passed,
such as passing __ibm128 or __float128 that just happens to use the same
representation as the current long double type. This is the bug being fixed
in this patch.
4) In an attempt to fix some of these problems, Mike Meissner applied a patch
to rs6000_emit_move that set the long double attribute whenever a move to or
from a register involved a long double mode, but that has bugs too.
a) With -mlong-double-64 an object that moves doubles to or from a
register would by marked as using 64-bit long double.
b) Functions that only use long double internally would wrongly
cause their object to be marked with the long double attribute.
c) 2c is not fixed by this patch, unless code in the object uses
the global variable.
--
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797
