[gcc(refs/users/meissner/heads/work107)] Update ChangeLog.meissner

[gcc(refs/users/meissner/heads/work107)] Update ChangeLog.meissner

[Michael Meissner]

https://gcc.gnu.org/g:436390e9951bb3f589268485e2d15ceab9f1eca3

commit 436390e9951bb3f589268485e2d15ceab9f1eca3
Author: Michael Meissner <meissner@linux.ibm.com>
Date:   Fri Jan 20 16:02:27 2023 -0500

    Update ChangeLog.meissner

Diff:
---
 gcc/ChangeLog.meissner | 71 ++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 71 insertions(+)

diff --git a/gcc/ChangeLog.meissner b/gcc/ChangeLog.meissner
index 188ac07d434..9d1f94121d8 100644
--- a/gcc/ChangeLog.meissner
+++ b/gcc/ChangeLog.meissner
@@ -1,3 +1,74 @@
+==================== work107, patch #2 ====================
+
+Rework 128-bit complex multiply and divide.
+
+This patch reworks how the complex multiply and divide built-in functions are
+done.  Previously we created built-in declarations for doing long double complex
+multiply and divide when long double is IEEE 128-bit.  The old code also did not
+support __ibm128 complex multiply and divide if long double is IEEE 128-bit.
+
+In terms of history, I wrote the original code just as I was starting to test
+GCC on systems where IEEE 128-bit long double was the default.  At the time, we
+had not yet started mangling the built-in function names as a way to bridge
+going from a system with 128-bit IBM long double to 128-bin IEEE long double.
+
+The original code depends on there only being two 128-bit types invovled.  With
+the next patch in this series, this assumption will no longer be true.  When
+long double is IEEE 128-bit, there will be 2 IEEE 128-bit types (one for the
+explicit __float128/_Float128 type and one for long double).
+
+The problem is we cannot create two separate built-in functions that resolve to
+the same name.  This is a requirement of add_builtin_function and the C front
+end.  That means for the 3 possible modes (IFmode, KFmode, and TFmode), you can
+only use 2 of them.
+
+This code does not create the built-in declaration with the changed name.
+Instead, it uses the TARGET_MANGLE_DECL_ASSEMBLER_NAME hook to change the name
+before it is written out to the assembler file like it now does for all of the
+other long double built-in functions.
+
+When I wrote these patches, I discovered that __ibm128 complex multiply and
+divide had originally not been supported if long double is IEEE 128-bit as it
+would generate calls to __mulic3 and __divic3.  I added tests in the testsuite
+to verify that the correct name (i.e. __multc3 and __divtc3) is used in this
+case.
+
+I had previously sent this patch out on November 1st.  Compared to that version,
+this version no longer disables the special mapping when you are building
+libgcc, as it turns out we don't need it.
+
+I tested all 3 patchs for PR target/107299 on:
+
+    1)	LE Power10 using --with-cpu=power10 --with-long-double-format=ieee
+    2)	LE Power10 using --with-cpu=power10 --with-long-double-format=ibm
+    3)	LE Power9  using --with-cpu=power9  --with-long-double-format=ibm
+    4)	BE Power8  using --with-cpu=power8  --with-long-double-format=ibm
+
+Once all 3 patches have been applied, we can once again build GCC when long
+double is IEEE 128-bit.  There were no other regressions with these patches.
+Can I check these patches into the trunk?
+
+2023-01-20   Michael Meissner  <meissner@linux.ibm.com>
+
+gcc/
+
+	PR target/107299
+	* config/rs6000/rs6000.cc (create_complex_muldiv): Delete.
+	(init_float128_ieee): Delete code to switch complex multiply and divide
+	for long double.
+	(complex_multiply_builtin_code): New helper function.
+	(complex_divide_builtin_code): Likewise.
+	(rs6000_mangle_decl_assembler_name): Add support for mangling the name
+	of complex 128-bit multiply and divide built-in functions.
+
+gcc/testsuite/
+
+	PR target/107299
+	* gcc.target/powerpc/divic3-1.c: New test.
+	* gcc.target/powerpc/divic3-2.c: Likewise.
+	* gcc.target/powerpc/mulic3-1.c: Likewise.
+	* gcc.target/powerpc/mulic3-2.c: Likewise.
+
 ==================== work107, patch #1 ====================
 
 PR target/107299: Fix build issue when long double is IEEE 128-bit

[gcc(refs/users/meissner/heads/work107)] Update ChangeLog.meissner

[Michael Meissner]

https://gcc.gnu.org/g:b4204634312f78d07a7b6fa7d5e1fc12429cd90e

commit b4204634312f78d07a7b6fa7d5e1fc12429cd90e
Author: Michael Meissner <meissner@linux.ibm.com>
Date:   Tue Jan 24 23:42:06 2023 -0500

    Update ChangeLog.meissner

Diff:
---
 gcc/ChangeLog.meissner | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/gcc/ChangeLog.meissner b/gcc/ChangeLog.meissner
index d206862278c..6ae64a62d3b 100644
--- a/gcc/ChangeLog.meissner
+++ b/gcc/ChangeLog.meissner
@@ -1,3 +1,23 @@
+==================== work107, patch #22 ====================
+
+Update fp conversions #2
+
+2022-01-24   Michael Meissner  <meissner@linux.ibm.com>
+
+gcc/
+
+	* config/rs6000/rs6000.md (any_fp_cvt): New code iterator.
+	(fp_cvt): New code attribute.
+	(extendkftf2): Replace with <fp_cvt>kftf2.
+	(trunctfkf2): Replace with <fp_cvt>tfkf2.
+	(extendiftf2): Replace with <fp_cvt>iftf2.
+	(trunctfif2): Replace with <fp_cvt>tfif2.
+	(<fp_cvt>kftf2): Add both float_extend and float_truncate versions to
+	convert between 128-bit floating point types with the same format..
+	(<fp_cvt>tfkf2): Likewise.
+	(<fp_cvt>iftf2): Likewise.
+	(<fp_cvt>tfif2): Likewise.
+
 ==================== work107, patch #21 ====================
 
 Update float 128-bit conversions, PR target/107299.

[gcc(refs/users/meissner/heads/work107)] Update ChangeLog.meissner

[Michael Meissner]

https://gcc.gnu.org/g:bc60e6ad685b665d41c71949c295c96390591f35

commit bc60e6ad685b665d41c71949c295c96390591f35
Author: Michael Meissner <meissner@linux.ibm.com>
Date:   Tue Jan 24 22:29:53 2023 -0500

    Update ChangeLog.meissner

Diff:
---
 gcc/ChangeLog.meissner | 51 ++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 51 insertions(+)

diff --git a/gcc/ChangeLog.meissner b/gcc/ChangeLog.meissner
index 182a2e87e0d..d206862278c 100644
--- a/gcc/ChangeLog.meissner
+++ b/gcc/ChangeLog.meissner
@@ -1,3 +1,54 @@
+==================== work107, patch #21 ====================
+
+Update float 128-bit conversions, PR target/107299.
+
+This patch is a rewrite of the patch submitted on August 18th:
+
+| https://gcc.gnu.org/pipermail/gcc-patches/2022-August/599988.html
+
+This patch reworks the conversions between 128-bit binary floating point types.
+Previously, we would call rs6000_expand_float128_convert to do all conversions.
+Now, we only define the conversions between the same representation that turn
+into a NOP.  The appropriate extend or truncate insn is generated, and after
+register allocation, it is converted to a move.
+
+This patch also fixes two places where we want to override the external name
+for the conversion function, and the wrong optab was used.  Previously,
+rs6000_expand_float128_convert would handle the move or generate the call as
+needed.  Now, it lets the machine independent code generate the call.  But if
+we use the machine independent code to generate the call, we need to update the
+name for two optabs where a truncate would be used in terms of converting
+between the modes.  This patch updates those two optabs.
+
+This patch was previously submitted on December 14th, 2022.  This patch changes
+one built-in function from a FLOAT_TRUNCATE to a FLOAT_EXTEND, which is needed
+by the previous patch to genmodes.cc to allow allow the same precision to be
+used for various modes.
+
+2022-01-24   Michael Meissner  <meissner@linux.ibm.com>
+
+gcc/
+
+	PR target/107299
+	* config/rs6000/rs6000.cc (init_float128_ieee): Use the correct
+	float_extend or float_truncate optab based on how the machine converts
+	between IEEE 128-bit and IBM 128-bit.
+	* config/rs6000/rs6000.md (IFKF): Delete.
+	(IFKF_reg): Delete.
+	(extendiftf2): Rewrite to be a move if IFmode and TFmode are both IBM
+	128-bit.  Do not run if TFmode is IEEE 128-bit.
+	(extendifkf2): Delete.
+	(extendtfkf2): Delete.
+	(extendtfif2): Delete.
+	(trunciftf2): Delete.
+	(truncifkf2): Delete.
+	(trunckftf2): Delete.
+	(extendkftf2): Implement conversion of IEEE 128-bit types as a move.
+	(trunctfif2): Delete.
+	(trunctfkf2): Implement conversion of IEEE 128-bit types as a move.
+	(extend<mode>tf2_internal): Delete.
+	(extendtf<mode>2_internal): Delete.
+
 ==================== work107, patch #20 ====================
 
 Improve PowerPC 128-bit floating point types.

[gcc(refs/users/meissner/heads/work107)] Update ChangeLog.meissner

[Michael Meissner]

https://gcc.gnu.org/g:7a745792382b35c9efcd07a2baf53938235c4c30

commit 7a745792382b35c9efcd07a2baf53938235c4c30
Author: Michael Meissner <meissner@linux.ibm.com>
Date:   Tue Jan 24 22:00:53 2023 -0500

    Update ChangeLog.meissner

Diff:
---
 gcc/ChangeLog.meissner | 31 +++++++++++++++++++++++++++++++
 1 file changed, 31 insertions(+)

diff --git a/gcc/ChangeLog.meissner b/gcc/ChangeLog.meissner
index 2479292e9e8..182a2e87e0d 100644
--- a/gcc/ChangeLog.meissner
+++ b/gcc/ChangeLog.meissner
@@ -1,3 +1,34 @@
+==================== work107, patch #20 ====================
+
+Improve PowerPC 128-bit floating point types.
+
+This patch prevents __ibm128 and __float128 from being considered in the
+automatic widening that the compiler does.  This way, you don't have the
+possibility that IFmode (__ibm128) will be widened to TFmode or KFmode, even
+there is hardware to support the IEEE 128-bit operations.
+
+I also moved changing the TFmode format from ieee to ibm to rs6000-modes.def
+from rs6000.cc.
+
+2022-01-24   Michael Meissner  <meissner@linux.ibm.com>
+
+gcc/
+
+	* config/rs6000/rs6000-modes.def (IFmode): Rework to use
+	FRACTIONAL_FLOAT_MODE_NO_WIDEN.
+	(KFmode): Likewise.
+	* expr.cc (convert_mode_scalar): Don't abort if we are converting
+	floating point modes that are the same precision but use different
+	encodings.
+	* genmodes.cc (struct mode_data): Add support for no widening.
+	(blank_mode): Likewise.
+	(FRACTIONAL_FLOAT_MODE): Add support for no widening capability.
+	(FRACTIONAL_FLOAT_MODE_NO_WIDEN): New macro.
+	(make_float_mode): Add support for no widening capability.
+	(cmp_modes): Likewise.
+	(emit_mode_wider): Add support for no widening capability.
+	* machmode.def (FRACTIONAL_FLOAT_MODE_NO_WIDEN): Document.
+
 ==================== work107, rebase 1/23 ====================
 
 ==================== work107, patch #2 ====================

[gcc(refs/users/meissner/heads/work107)] Update ChangeLog.meissner

[Michael Meissner]

https://gcc.gnu.org/g:7f92b918e931ad6c26ea72e14f310d0fde3ec684

commit 7f92b918e931ad6c26ea72e14f310d0fde3ec684
Author: Michael Meissner <meissner@linux.ibm.com>
Date:   Mon Jan 23 16:19:39 2023 -0500

    Update ChangeLog.meissner

Diff:
---
 gcc/ChangeLog.meissner | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/gcc/ChangeLog.meissner b/gcc/ChangeLog.meissner
index 9d1f94121d8..2479292e9e8 100644
--- a/gcc/ChangeLog.meissner
+++ b/gcc/ChangeLog.meissner
@@ -1,3 +1,5 @@
+==================== work107, rebase 1/23 ====================
+
 ==================== work107, patch #2 ====================
 
 Rework 128-bit complex multiply and divide.

[gcc(refs/users/meissner/heads/work107)] Update ChangeLog.meissner

[Michael Meissner]

https://gcc.gnu.org/g:cd50ffa67ba91798309338dab699b208dc21d460

commit cd50ffa67ba91798309338dab699b208dc21d460
Author: Michael Meissner <meissner@linux.ibm.com>
Date:   Fri Jan 20 16:02:27 2023 -0500

    Update ChangeLog.meissner

Diff:
---
 gcc/ChangeLog.meissner | 71 ++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 71 insertions(+)

diff --git a/gcc/ChangeLog.meissner b/gcc/ChangeLog.meissner
index 188ac07d434..9d1f94121d8 100644
--- a/gcc/ChangeLog.meissner
+++ b/gcc/ChangeLog.meissner
@@ -1,3 +1,74 @@
+==================== work107, patch #2 ====================
+
+Rework 128-bit complex multiply and divide.
+
+This patch reworks how the complex multiply and divide built-in functions are
+done.  Previously we created built-in declarations for doing long double complex
+multiply and divide when long double is IEEE 128-bit.  The old code also did not
+support __ibm128 complex multiply and divide if long double is IEEE 128-bit.
+
+In terms of history, I wrote the original code just as I was starting to test
+GCC on systems where IEEE 128-bit long double was the default.  At the time, we
+had not yet started mangling the built-in function names as a way to bridge
+going from a system with 128-bit IBM long double to 128-bin IEEE long double.
+
+The original code depends on there only being two 128-bit types invovled.  With
+the next patch in this series, this assumption will no longer be true.  When
+long double is IEEE 128-bit, there will be 2 IEEE 128-bit types (one for the
+explicit __float128/_Float128 type and one for long double).
+
+The problem is we cannot create two separate built-in functions that resolve to
+the same name.  This is a requirement of add_builtin_function and the C front
+end.  That means for the 3 possible modes (IFmode, KFmode, and TFmode), you can
+only use 2 of them.
+
+This code does not create the built-in declaration with the changed name.
+Instead, it uses the TARGET_MANGLE_DECL_ASSEMBLER_NAME hook to change the name
+before it is written out to the assembler file like it now does for all of the
+other long double built-in functions.
+
+When I wrote these patches, I discovered that __ibm128 complex multiply and
+divide had originally not been supported if long double is IEEE 128-bit as it
+would generate calls to __mulic3 and __divic3.  I added tests in the testsuite
+to verify that the correct name (i.e. __multc3 and __divtc3) is used in this
+case.
+
+I had previously sent this patch out on November 1st.  Compared to that version,
+this version no longer disables the special mapping when you are building
+libgcc, as it turns out we don't need it.
+
+I tested all 3 patchs for PR target/107299 on:
+
+    1)	LE Power10 using --with-cpu=power10 --with-long-double-format=ieee
+    2)	LE Power10 using --with-cpu=power10 --with-long-double-format=ibm
+    3)	LE Power9  using --with-cpu=power9  --with-long-double-format=ibm
+    4)	BE Power8  using --with-cpu=power8  --with-long-double-format=ibm
+
+Once all 3 patches have been applied, we can once again build GCC when long
+double is IEEE 128-bit.  There were no other regressions with these patches.
+Can I check these patches into the trunk?
+
+2023-01-20   Michael Meissner  <meissner@linux.ibm.com>
+
+gcc/
+
+	PR target/107299
+	* config/rs6000/rs6000.cc (create_complex_muldiv): Delete.
+	(init_float128_ieee): Delete code to switch complex multiply and divide
+	for long double.
+	(complex_multiply_builtin_code): New helper function.
+	(complex_divide_builtin_code): Likewise.
+	(rs6000_mangle_decl_assembler_name): Add support for mangling the name
+	of complex 128-bit multiply and divide built-in functions.
+
+gcc/testsuite/
+
+	PR target/107299
+	* gcc.target/powerpc/divic3-1.c: New test.
+	* gcc.target/powerpc/divic3-2.c: Likewise.
+	* gcc.target/powerpc/mulic3-1.c: Likewise.
+	* gcc.target/powerpc/mulic3-2.c: Likewise.
+
 ==================== work107, patch #1 ====================
 
 PR target/107299: Fix build issue when long double is IEEE 128-bit

[gcc(refs/users/meissner/heads/work107)] Update ChangeLog.meissner

[Michael Meissner]

https://gcc.gnu.org/g:361a72abdd82b9038dd30243f052edbddf9ffd2f

commit 361a72abdd82b9038dd30243f052edbddf9ffd2f
Author: Michael Meissner <meissner@linux.ibm.com>
Date:   Fri Jan 20 15:34:11 2023 -0500

    Update ChangeLog.meissner

Diff:
---
 gcc/ChangeLog.meissner | 69 ++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 69 insertions(+)

diff --git a/gcc/ChangeLog.meissner b/gcc/ChangeLog.meissner
index fda09a48c25..188ac07d434 100644
--- a/gcc/ChangeLog.meissner
+++ b/gcc/ChangeLog.meissner
@@ -1,3 +1,72 @@
+==================== work107, patch #1 ====================
+
+PR target/107299: Fix build issue when long double is IEEE 128-bit
+
+This patch updates the IEEE 128-bit types used in libgcc.
+
+At the moment, we cannot build GCC when the target uses IEEE 128-bit long
+doubles, such as building the compiler for a native Fedora 36 system.  The
+build dies when it is trying to build the _mulkc3.c and _divkc3 modules.
+
+This patch changes libgcc to use long double for the IEEE 128-bit base type if
+long double is IEEE 128-bit, and it uses _Float128 otherwise.  The built-in
+functions are adjusted to be the correct version based on the IEEE 128-bit base
+type used.
+
+While it is desirable to ultimately have __float128 and _Float128 use the same
+internal type and mode within GCC, at present if you use the option
+-mabi=ieeelongdouble, the __float128 type will use the long double type and not
+the _Float128 type.  We get an internal compiler error if we combine the
+signbitf128 built-in with a long double type.
+
+I've gone through several iterations of trying to fix this within GCC, and
+there are various problems that have come up.  I developed this alternative
+patch that changes libgcc so that it does not tickle the issue.  I hope we can
+fix the compiler at some point, but right now, this is preventing people on
+Fedora 36 systems from building compilers where the default long double is IEEE
+128-bit.
+
+I have built a GCC compiler tool chain on the following platforms and there
+were no regressions caused by these patches.
+
+    *	Power10 little endian, IBM long double, --with-cpu=power10
+
+    *	Power9 little endian, IBM long double, --with-cpu=power9
+
+    *	Power8 big endian, IBM long double, --with-cpu=power8, both
+	32-bit/64-bit tests.
+
+In addition, I have built a GCC compiler tool chain on the following systems
+with IEEE 128-bit long double as the default.  Comparing the test suite runs to
+the runs for the toolchain with IBM long double as the default, I only get the
+expected differences (C++ modules test fail on IEEE long double, 3 Fortran
+tests pass on IEEE long double that fail on IBM long double, C test pr105334.c
+fails, and C test fp128_conversions.c fails on power10):
+
+    *	Power10 little endian, IEEE long double, --with-cpu=power10
+
+    *	Power9 little endian, IEEE long double, --with-cpu=power9
+
+Can I check this change into the master branch?
+
+2023-01-20   Michael Meissner  <meissner@linux.ibm.com>
+
+	PR target/107299
+	* config/rs6000/_divkc3.c (COPYSIGN): Use the correct built-in based on
+	whether long double is IBM or IEEE.
+	(INFINITY): Likewise.
+	(FABS): Likewise.
+	* config/rs6000/_mulkc3.c (COPYSIGN): Likewise.
+	(INFINITY): Likewise.
+	* config/rs6000/quad-float128.h (TF): Remove definition.
+	(TFtype): Define to be long double or _Float128.
+	(TCtype): Define to be _Complex long double or _Complex _Float128.
+	* libgcc2.h (TFtype): Allow machine config files to override this.
+	(TCtype): Likewise.
+	* soft-fp/quad.h (TFtype): Likewise.
+
+==================== work107, branch head ====================
+
 2023-01-20   Michael Meissner  <meissner@linux.ibm.com>
 
 	Clone branch

[gcc(refs/users/meissner/heads/work107)] Update ChangeLog.meissner

[Michael Meissner]

https://gcc.gnu.org/g:16d92e2fddc2e80ba6634df75b11e68204cfd73e

commit 16d92e2fddc2e80ba6634df75b11e68204cfd73e
Author: Michael Meissner <meissner@linux.ibm.com>
Date:   Fri Jan 20 15:34:11 2023 -0500

    Update ChangeLog.meissner

Diff:
---
 gcc/ChangeLog.meissner | 69 ++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 69 insertions(+)

diff --git a/gcc/ChangeLog.meissner b/gcc/ChangeLog.meissner
index fda09a48c25..188ac07d434 100644
--- a/gcc/ChangeLog.meissner
+++ b/gcc/ChangeLog.meissner
@@ -1,3 +1,72 @@
+==================== work107, patch #1 ====================
+
+PR target/107299: Fix build issue when long double is IEEE 128-bit
+
+This patch updates the IEEE 128-bit types used in libgcc.
+
+At the moment, we cannot build GCC when the target uses IEEE 128-bit long
+doubles, such as building the compiler for a native Fedora 36 system.  The
+build dies when it is trying to build the _mulkc3.c and _divkc3 modules.
+
+This patch changes libgcc to use long double for the IEEE 128-bit base type if
+long double is IEEE 128-bit, and it uses _Float128 otherwise.  The built-in
+functions are adjusted to be the correct version based on the IEEE 128-bit base
+type used.
+
+While it is desirable to ultimately have __float128 and _Float128 use the same
+internal type and mode within GCC, at present if you use the option
+-mabi=ieeelongdouble, the __float128 type will use the long double type and not
+the _Float128 type.  We get an internal compiler error if we combine the
+signbitf128 built-in with a long double type.
+
+I've gone through several iterations of trying to fix this within GCC, and
+there are various problems that have come up.  I developed this alternative
+patch that changes libgcc so that it does not tickle the issue.  I hope we can
+fix the compiler at some point, but right now, this is preventing people on
+Fedora 36 systems from building compilers where the default long double is IEEE
+128-bit.
+
+I have built a GCC compiler tool chain on the following platforms and there
+were no regressions caused by these patches.
+
+    *	Power10 little endian, IBM long double, --with-cpu=power10
+
+    *	Power9 little endian, IBM long double, --with-cpu=power9
+
+    *	Power8 big endian, IBM long double, --with-cpu=power8, both
+	32-bit/64-bit tests.
+
+In addition, I have built a GCC compiler tool chain on the following systems
+with IEEE 128-bit long double as the default.  Comparing the test suite runs to
+the runs for the toolchain with IBM long double as the default, I only get the
+expected differences (C++ modules test fail on IEEE long double, 3 Fortran
+tests pass on IEEE long double that fail on IBM long double, C test pr105334.c
+fails, and C test fp128_conversions.c fails on power10):
+
+    *	Power10 little endian, IEEE long double, --with-cpu=power10
+
+    *	Power9 little endian, IEEE long double, --with-cpu=power9
+
+Can I check this change into the master branch?
+
+2023-01-20   Michael Meissner  <meissner@linux.ibm.com>
+
+	PR target/107299
+	* config/rs6000/_divkc3.c (COPYSIGN): Use the correct built-in based on
+	whether long double is IBM or IEEE.
+	(INFINITY): Likewise.
+	(FABS): Likewise.
+	* config/rs6000/_mulkc3.c (COPYSIGN): Likewise.
+	(INFINITY): Likewise.
+	* config/rs6000/quad-float128.h (TF): Remove definition.
+	(TFtype): Define to be long double or _Float128.
+	(TCtype): Define to be _Complex long double or _Complex _Float128.
+	* libgcc2.h (TFtype): Allow machine config files to override this.
+	(TCtype): Likewise.
+	* soft-fp/quad.h (TFtype): Likewise.
+
+==================== work107, branch head ====================
+
 2023-01-20   Michael Meissner  <meissner@linux.ibm.com>
 
 	Clone branch