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