https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106680
--- Comment #7 from Kewen Lin <linkw at gcc dot gnu.org> ---
(In reply to Sebastian Huber from comment #6)
> It seems that the change
>
> commit acc727cf02a1446dc00f8772f3f479fa3a508f8e
> Author: Kewen Lin <li...@linux.ibm.com>
> Date: Tue Dec 27 04:13:07 2022 -0600
>
> rs6000: Rework option -mpowerpc64 handling [PR106680]
>
> causes a regression for -mcpu=e6500 -m32, for example:
>
> gcc -fpreprocessed -O2 -S -mcpu=e6500 -m32 -S imfs_add_node.c.67.s
> imfs_add_node.c.67.i
>
> diff -u imfs_add_node.c.67.s.good.e2acff49fb2962b921bf8b73984b89878b61492c
> imfs_add_node.c.67.s.bad.acc727cf02a1446dc00f8772f3f479fa3a508f8e
> --- imfs_add_node.c.67.s.good.e2acff49fb2962b921bf8b73984b89878b61492c
> 2024-01-20 12:15:15.143182571 +0100
> +++ imfs_add_node.c.67.s.bad.acc727cf02a1446dc00f8772f3f479fa3a508f8e
> 2024-01-20 12:11:46.804204927 +0100
> @@ -52,8 +52,8 @@
> bne- 0,.L4
> .L2:
> mr 4,29
> - addi 3,1,8
> li 5,24
> + addi 3,1,8
> bl rtems_filesystem_eval_path_start
> lis 9,IMFS_node_clone@ha
> lwz 10,20(3)
> @@ -63,12 +63,12 @@
> cmpw 0,10,9
> beq- 0,.L24
> li 4,134
> - addi 3,1,8
> + li 3,0
> bl rtems_filesystem_eval_path_error
> .L9:
> li 31,-1
> .L10:
> - addi 3,1,8
> + li 3,0
> bl rtems_filesystem_eval_path_cleanup
> .L1:
> lwz 0,116(1)
> @@ -93,7 +93,7 @@
> lwz 9,12(31)
> li 8,96
> lhz 10,16(31)
> - addi 3,1,8
> + li 3,0
> stw 8,24(1)
> stw 9,8(1)
> stw 10,12(1)
> @@ -105,7 +105,7 @@
> cmpwi 0,9,0
> beq- 0,.L9
> li 4,22
> - addi 3,1,8
> + li 3,0
> bl rtems_filesystem_eval_path_error
> b .L9
> .p2align 4,,15
> @@ -129,12 +129,9 @@
> stw 9,0(10)
> stw 10,4(9)
> bl _Timecounter_Getbintime
> - lwz 10,64(1)
> - lwz 11,68(1)
> - stw 10,40(30)
> - stw 11,44(30)
> - stw 10,48(30)
> - stw 11,52(30)
> + ld 9,64(1)
> + std 9,40(30)
> + std 9,48(30)
> b .L10
> .cfi_endproc
> .LFE351:
>
> For the call to rtems_filesystem_eval_path_cleanup() the register 3 should
> point to a structure on the stack. Correct is:
>
> - addi 3,1,8
>
> Wrong is:
>
> + li 3,0
>
> It seems that for the -mcpu=e6500 the -m32 option has not the right effect
> and some 64-bit instructions are generated, for example ld and std plus the
As the commit log, the previous behavior that -m32 also disables -mpowerpc64 is
wrong, -m{no,}powerpc64 should be independent of -m32/-m64.
> wrong function parameters.
I supposed that the behavior you wanted with -m32 is not to enable powerpc64
(since the previous behavior is -m32 can disable -mpowerpc64 as well), so I
think you can get the previous behavior if you specify one explicit
-mno-powerpc64 when adopting -m32.
