Post AlKeVi7Axv7ffwdqD2 by nil@furry.engineer
 (DIR) More posts by nil@furry.engineer
 (DIR) Post #AlJJHc2mRpAyb63uUq by nil@furry.engineer
       2024-08-25T01:30:12Z
       
       2 likes, 4 repeats
       
       oh my fucking god. so i was having a problem when i enabled optimizations when compiling the doom port. memcpy ended up overwriting itself. so i looked into what was happening, and apparently memcpy just kept calling itself over and over. the reason? i was compiling my own version of memcpy, because i wasn't using the standard library, but i also didn't use the "-ffreestanding" flag, so gcc assumed i *did* have the standard library. so gcc, in its infinite wisdom, turned memcpy into another call to memcpy, resulting in a stack overflow.
       
 (DIR) Post #AlJJhvI5VjX3oslfIO by mothcompute@vixen.zone
       2024-08-25T01:51:52Z
       
       0 likes, 0 repeats
       
       @nil i dont know much about riscv but even assuming that was correct surely such an optimization couldve just been like. a `jmp memcpy`
       
 (DIR) Post #AlKeVi7Axv7ffwdqD2 by nil@furry.engineer
       2024-08-25T14:04:49Z
       
       0 likes, 0 repeats
       
       @lda @mothcompute the thing is that memcpy returns a pointer to dest, even though the return value of memcpy is rarely used. so the memcpy optimization, it seems, ignores what memcpy returns. so it had to keep space for the code that returns the dest pointer. if you remove that return, then it becomes a tail call (skipping over the memcpy call if length is 0, for some reason)https://godbolt.org/z/3reYrMjK9
       
 (DIR) Post #AlKeVivrvRfkDAMKDw by mothcompute@vixen.zone
       2024-08-25T17:19:39Z
       
       0 likes, 0 repeats
       
       @nil @lda i cannot even begin to imagine the kind of thought process that went into that decision. to do this in the compiler no less