This patch fixes PR middle_end/82333. 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. I have done bootstraps on x86-64 and little endian power8 systems. Both systems bootstrapped fine and there were no regressions in the test suite. I verified that the new test case in the powerpc test directory passes. Can I check this into the trunk? Can I also check this info the active branches (gcc 6/7) providing it causes no regressions? [gcc] 2017-11-09 Michael Meissner PR middle_end/82333 * varasm.c (compare_constant): Take the mode of the constants into account when comparing floating point constants. [gcc/testsuite] 2017-11-09 Michael Meissner PR middle_end/82333 * gcc.target/powerpc/pr82333.c: New test. -- Michael Meissner, IBM IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA email: meissner@linux.vnet.ibm.com, phone: +1 (978) 899-4797