https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61047
Bernhard Kaindl <bernhard.kaindl at thalesgroup dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |bernhard.kaindl@thalesgroup
| |.com
--- Comment #20 from Bernhard Kaindl <bernhard.kaindl at thalesgroup dot com>
---
For people reviewing this, I want to summarize:
Eric submitted a fix for this and explains it [required read]:
https://gcc.gnu.org/ml/gcc-patches/2014-03/msg01200.html
The archive has no objections and Richard Biener said:
Looks reasonable to me.
The basic bug is that gcc does not eliminate the load of e[2837] (which is dead
code) right way - which may never be reached since b is limited to < 2:
for (; b < 2; b++)
{
a = 0;
if (b == 2837)
a = e[b];
As written in Comment 3:
> Note how the load at insn 28 is guarded by comparing ax against #2837. CE3
> transforms that into an unconditional load and we blow up reading the
> out-of-range stack slot.
As far as I understand: The patch fixes a bug in rtx_addr_can_trap_p_1() which
is called to check if an access can trap, where the bug is that
rtx_addr_can_trap_p_1() does not take the offset of the object (in this case
e[2837]) into account, and returns the info that the access is safe, which it
is not, because it is out of bounds (and out of the stack too)
The patch only fixes the wrong information returned by this function that the
access is safe by returning 1 when the offset causes the access to be outside
of the stack.
So this patch fixes a clear bug which leads to wrong code generated by gcc.
I think that the patch is clear in scope, only fixes a specific case unless
rtx_addr_can_trap_p_1() was refactored, it should be feasible to apply to
trunk, 5.1 and 4.9.
