https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82333
Michael Meissner <meissner at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
Component|target |middle-end
--- Comment #3 from Michael Meissner <meissner at gcc dot gnu.org> ---
The bug is due to compare_constant thinking two floating point constants are
the same if the floating point size and the internal value are the same. On
the PowerPC, long double and _Float128 both are 128-bits, but they have
different internal representations.
The bug shows up when you try to inline two functions, one that returns 0
converted to long double _Complex and the other that returns 0 converted to
_Float128 _Complex.
The function compare_constant in varasm.c thinks that these two constants are
the same, and assigns them to the same hash. When inliner tries to replace the
inline function (that returns 0) with the constant, it does moves of the real
part and the imaginary part. In the second function, the real/imaginary parts
have type KFmode, while the first function (that has the saved constant) the
real/imaginary parts have type TFmode.
The fix is to consider the type along with the precision when doing hash of the
constants.
