[Bug c/89269] New: RISC-V stack variable as global variable

[rtos.pharos at outlook dot com]

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

            Bug ID: 89269
           Summary: RISC-V stack variable as global variable
           Product: gcc
           Version: 8.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: rtos.pharos at outlook dot com
  Target Milestone: ---

Hello all,

I'm working on Pharos operating system
https://sourceforge.net/projects/rtospharos/ (maybe this information could be
useful for debugging the issue).

In RISC-V (riscv64-unknown-elf-gcc) version 8.2.0 the following code:


void aperiodicThread0_0()
{
    PharosHwQueueSendR sendResult;
    uint8_t message[] = {
        0xda , 0x4f , 0xc2 , 4 , 5 , 6 , 7 , 8
    };

 .
 . 
 .

}

(the important part is the message variable that is declared on the stack) this
code compiles into:

    800013ac:   1101                    addi    sp,sp,-32
    800013ae:   ec06                    sd      ra,24(sp)
    800013b0:   e822                    sd      s0,16(sp)
    800013b2:   1000                    addi    s0,sp,32
    PharosHwQueueSendR sendResult;
    uint8_t message[] = {
    800013b4:   00bff797                auipc   a5,0xbff
    800013b8:   04c78793                addi    a5,a5,76 # 80c00400
<partition1BssEnd>
    800013bc:   639c                    ld      a5,0(a5)
    800013be:   fef43023                sd      a5,-32(s0)
        0xda , 0x4f , 0xc2 , 4 , 5 , 6 , 7 , 8


That is, the "message" variable is placed after the partition1BssEnd section
(this is defined on the linker script). Even with optimizations (this code was
compiled -O0) this should not occur. In short, I am developing an OS with
everything defined statically, so that at startup the OS already knows where to
place every global variable and we can protect the memory of each
partition/process. If variables that should on stack are placed on a global
section (not even on the partition that they belong to) that screws up the
mechanism.

Best regards,
Pharos Team