[gcc(refs/vendors/ibm/heads/gcc-17-future)] Update ChangeLog.*

https://gcc.gnu.org/g:1b8b5257fae5a046d9f2b3a6f85f034aaec845e2

commit 1b8b5257fae5a046d9f2b3a6f85f034aaec845e2
Author: Michael Meissner <[email protected]>
Date:   Thu Jul 2 20:08:47 2026 -0400

    Update ChangeLog.*

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

diff --git a/gcc/ChangeLog.ibm b/gcc/ChangeLog.ibm
index 4461f38094ef..4d5d8917387c 100644
--- a/gcc/ChangeLog.ibm
+++ b/gcc/ChangeLog.ibm
@@ -1,3 +1,77 @@
+======== Patch #11 ========
+
+Fix dense math register insert/extract 512-bit problem.
+
+Kishan Parmar <[email protected]> issued a patch that made me re-examine the
+code I had put out for dense math registers.  This patch fixes the third problem
+the patch uncovered.
+
+The first problem is the insert/extract instructions were using %<n> to address
+VSX registers instead of using %x<n>.  This would give the wrong register number
+if a vector register 32..63 was used (i.e. a traditional Altivec register).
+
+The second problem was the instructions were using %L<n> to access the second
+vector pair register, which does not work for Altivec registers either without
+the patch.
+
+I have rewritten the instructions to use %x<n> for the first vector pair
+register, and %x<n>+2 to access the second vector pair register.
+
+I have committed all of the patches in my backlog (dense math registers, other
+-mcpu=future instructions, random bug fixes, support for _Float16 and
+__bfloat16, and optimizations for vector logical operations on power10/power11)
+into the IBM vendor branch:
+
+	vendors/ibm/gcc-17-future
+
+I have tested these patches on both big endian and little endian PowerPC
+servers, with no regressions.  Can I check these patches into the trunk?
+
+2026-07-02  Michael Meissner  <[email protected]>
+
+gcc/
+
+	* config/rs6000/mma.md (movxo_dm): Fix issues if vector registers 32..63
+	were used.
+	(movtdo_insert512_upper): Likewise.
+	(movtdo_insert512_lower): Likewise.
+	(movtdo_extract512): Likewise.
+
+======== Patch #10 ========
+
+Fix -mregnames issue with dense math registers.
+
+Kishan Parmar <[email protected]> issued a patch that made me re-examine the
+code I had put out for dense math registers.  This patch fixes two of these problems.
+
+The first problem is the output operand %A<n> was always printing out a number,
+even if -mregnames was used.  I fixed this by using reg_names[..] for dense math
+registers.  For power10/power11 accumulators that are overlaid on top of VSX
+registers, it just prints out the VSX register number divided by 4.
+
+The second problem is once %A<n> can print a register name instead of a number,
+the next problem is if you use -mregnames, GCC would put out %dmr<n> while the
+assembler wants %dm<n>.  I fixed this to use the correct name.
+
+I have committed all of the patches in my backlog (dense math registers, other
+-mcpu=future instructions, random bug fixes, support for _Float16 and
+__bfloat16, and optimizations for vector logical operations on power10/power11)
+into the IBM vendor branch:
+
+	vendors/ibm/gcc-17-future
+
+I have tested these patches on both big endian and little endian PowerPC
+servers, with no regressions.  Can I check these patches into the trunk?
+
+2026-07-02  Michael Meissner  <[email protected]>
+
+gcc/
+
+	* config/rs6000/rs6000.cc (alt_reg_names): Use %dm<n> for dense math
+	registers, not %dmr<n>.
+	(print_operand): Add a comment for %A<n>, of why we can't emit %dm<n>
+	since the assembler doesn't recognize %dm0 in this context.
+
 ======== Patch #9 ========
 
 Add _Float16 and __bfloat16 support.