------- Comment #2 from ubizjak at gmail dot com 2009-02-06 13:45 -------
(In reply to comment #0)
> This is a bug report for gcc 4_3 branch. I will attach a test case, slightly
> reduced from zlib code. When compiling this test case for the x86_64-linux
> target with -O2 -fomit-frame-pointer, I see this at the start of the function:
-fno-omit-frame-pointer
> adler32:
> pushq %rbp
> movq %rdi, %rax
> andl $65535, %edi
> shrq $16, %rax
> movq %rsp, %rbp
> pushq %r15
> andl $65535, %eax
> movl %edx, -140(%rbp)
>
> After %rsp was copied to %rbp, %r15 was pushed. So now %rsp is 8 bytes less
> than %rbp. The red zone is 128 bytes, so this means that any reference down
> to
> -136(%rbp) is valid. However, the code actually stores a value into
> -140(%rbp). This is invalid, and can cause subtle and unpredictable bugs
> depending upon when the kernel interrupts this code.
We have several options here:
1. disable redzone with -fno-omit-frame-pointer
2. emit scheduling barrier just after the prologue for -fno-omit-frame-pointer
3. make instructions that access to redzone dependant on %rsp
Confirmed, but since -fomit-frame-pointer is the default (and works OK) it is
not a critical issue.
--
ubizjak at gmail dot com changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|0000-00-00 00:00:00 |2009-02-06 13:45:35
date| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39118
