This set of patches was first submitted on November 1st. Kewen.Lin
asked for some changes to the first set of patches. I
also tried to clean up the comments in the second patch about types that Segher
Boessenkool mentioned.
I had just re-submitted the first patch yesterday, but Segher asked that I
repost all three patches. Here is the original commentary for all three
patches, tweaked a little bit:
These 3 patches fix the problems with building GCC on PowerPC systems when long
double is configured to use the IEEE 128-bit format.
There are 3 patches in this patch set. The first two patches are required to
fix the basic problem. The third patch fixes some issues that were noticed
along the way.
The basic issue is internally within GCC there are several types for 128-bit
floating point. The types are:
1) The long double type (which use either TFmode for 128-bit long doubles
or possibly DFmode for 64-bit long doubles). In the normal case, long
double is 128-bits (TFmode) and depending on the configuration options
and the switches passed by the user at compilation time, long double is
either the 128-bit IBM double-double type or IEEE 128-bit.
2) The type for __ibm128. If long double is IBM 128-bit double-double,
internally within the compiler, this type is the same as the long
double type. If long double is either IEEE 128-bit or is 64-bit, then
this type is a separate type. If long double is not double-double,
this type will use IFmode during RTL.
3) The type for _Float128. This type is always IEEE 128-bit if it exists.
While it is a separate internal type, currently if long double is IEEE
128-bit, this type uses TFmode once it gets to RTL, but within Gimple
it is a separate type. If long double is not IEEE 128-bit, then this
type uses KFmode. All of the f128 math functions defined by the
compiler use this type. In the past, _Float128 was a C extended type
and not available in C++. Now it is a part of the C/C++ 2x standards.
4) The type for __float128. The history is I implemented __float128
first, and several releases later, we added _Float128 as a standard C
type. Unfortunately, I didn't think things through enough when
_Float128 came out. Like __ibm128, it uses the long double type if
long double is IEEE 128-bit, and now it uses the _Float128 type if long
double is not IEEE 128-bit. IMHO, this is the major problem. The two
IEEE 128-bit types should use the same type internally (or at least one
should be a qualified type of the other). Before we started adding
more support for _Float128, it mostly works, but now it doesn't with
more optimizations being done.
5) The error occurs in building _mulkc3 in libgcc, when the TFmode type in
the code is defined to use attribute((mode(TF))), but the functions
that are called all have _Float128 arguments. These are separate
types, and ultimately one of the consistancy checks fails because they
are different types.
There are 3 patches in this set:
1) The first patch rewrites how the complex 128-bit multiply and divide
functions are done in the compiler. In the old scheme, essentially
there were only two types ever being used, the long double type, and
the not long double type. The original code would make the names
called of these functions to be __multc3/__divtc3 or
__mulkc3/__divkc3. This worked because there were only two types.
With straightening out the types, so __float128/_Float128 is never the
long double type, there are potentially 3-4 types. However, the C
front end and the middle end code will not let us create two built-in
functions that have the same name.
Patch #1 patch rips out this code, and rewrites it to be cleaner.
In the original version of the patches, I disabled doing the mapping
when building libgcc because it caused problems when building __mulkc3
and __divkc3. I have removed this check, since the second patch will
allow these functions to be built without disabling the mapping.
2) The second patch fixes the problem of __float128 and _Float128 not
being the same if long double is IEEE 128-bit. After this patch, both
_Float128 and __float128 types will always use the same type. When we
get to RTL, it will always use KFmode type (and not use TFmode). The
stdc++ library will not build if we use TFmode for these types due to
the other changes.
There is a minor codegen issue that if you explicitly use long double
and call the F128 FMA (fused multiply-add) round to odd functions that
are defined to use __float128/_Float128 arguments. While we might be
able to optimize these later,
