[Bug c/110234] New: [RISCV] Improper endian encoding when using floats and doubles with -mbig-endian

[branislav.brzak at syrmia dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110234

            Bug ID: 110234
           Summary: [RISCV] Improper endian encoding when using floats and
                    doubles with -mbig-endian
           Product: gcc
           Version: 12.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: branislav.brzak at syrmia dot com
  Target Milestone: ---

Problem description
RISCV Gcc has a -mbig-endian flag that is supposed to flip endian on every
available data type, except instructions stored in `.text`. However, there is
an issue with how floats and doubles are stored. With the following min repro:


.section .text
.global _start
_start:
    j _start

.section .data
float1: .float 1.1


That is compiled with the following makefile:

all:
        riscv64-unknown-linux-gnu-gcc -ffreestanding -nostdlib -march=rv64imafd
-mno-riscv-attribute -mabi=lp64d -Tlink.ld -nostartfiles -mcmodel=medany
-Wl,--no-warn-rwx-segments -g -o le_test.elf test.s
        riscv64-unknown-linux-gnu-gcc -ffreestanding -nostdlib -march=rv64imafd
-mno-riscv-attribute -mabi=lp64d -Tlink.ld -nostartfiles -mcmodel=medany
-Wl,--no-warn-rwx-segments -mbig-endian -g -o be_test.elf test.s
        riscv64-unknown-elf-objdump -D le_test.elf > le_test.dump  
        riscv64-unknown-elf-objdump -D be_test.elf > be_test.dump
        riscv64-unknown-linux-gnu-objcopy -O binary le_test.elf le_test.bin
        riscv64-unknown-linux-gnu-objcopy -O binary be_test.elf be_test.bin
        xxd le_test.bin > le_test.hex
        xxd be_test.bin > be_test.hex

diff:
        @diff le_test.hex be_test.hex


Doing `make diff` on the resulting hex dumps gives:

1c1
< 00000000: 6f00 0000 0000 0000 cdcc 8c3f 0000 0000  o..........?....
---
> 00000000: 6f00 0000 0000 0000 cccd 3f8c 0000 0000  o.........?.....


Upper one is the LE binary while the lower one is BE. Here we can see that
compared to LE (that is properly encoded), BE's endian is flipped only on 2
byte boundaries. The correct BE sequence in this case would be

3f 8c cc cd

2 byte stores are also reflected in the elf file as well:

GCC version info

riscv64-unknown-linux-gnu-gcc -v       
Using built-in specs.
COLLECT_GCC=riscv64-unknown-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/opt/riscv/libexec/gcc/riscv64-unknown-linux-gnu/12.2.0/lto-wrapper
Target: riscv64-unknown-linux-gnu
Configured with: /home/fix/tasks/riscvbe/new/riscv-gnu-toolchain/gcc/configure
--target=riscv64-unknown-linux-gnu --prefix=/opt/riscv
--with-sysroot=/opt/riscv/sysroot --with-pkgversion=g2ee5e430018
--with-system-zlib --enable-shared --enable-tls
--enable-languages=c,c++,fortran --disable-libmudflap --disable-libssp
--disable-libquadmath --disable-libsanitizer --disable-nls --disable-bootstrap
--src=.././gcc --disable-multilib --with-abi=lp64d --with-arch=rv64imafdc
--with-tune=rocket --with-isa-spec=20191213 'CFLAGS_FOR_TARGET=-O2   
-mcmodel=medlow' 'CXXFLAGS_FOR_TARGET=-O2    -mcmodel=medlow'
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.2.0 (g2ee5e430018)