Hi, it was exactly to the day one year ago, when I posted this patch the first time: [PATCH] PR rtl-optimization/61047: https://gcc.gnu.org/ml/gcc-patches/2014-06/msg00996.html
The PR was suspended, but the discussion did not stop. And I personally still
see a bug like this
as an in-acceptable security risk for embedded safety systems.
The problem is, that when rtx_addr_can_trap_p_1 returns 0, that means for the
code generation
that this instruction can be moved out of any guarding if-block when that seems
profitable.
This is a latent wrong code generation bug, that happens mostly in machine
generated compiler-test code,
but the point is, we can never be sure, that this is impossible to happen in
"real" code.
So I would like to fix this now, because there are quite a few duplicated
reports of the same
bug already, and because refusing to fix a known wrong code bug is just not our
style.
I have boot-strapped and regression tested the patch with all languages again
on x86_64-linux-gnu.
The patch still works unmodified, and all I would have to change on the
original patch files
will be the year: s/2014/2015/g ;)
Thanks
Bernd.
gcc/ChangeLog:
2014-06-11 Bernd Edlinger <bernd.edlin...@hotmail.de>
PR rtl-optimization/61047
* rtlanal.c (get_initial_register_offset): New function.
(rtx_addr_can_trap_p_1): Check offsets of stack references.
testsuite/ChangeLog:
2014-06-11 Bernd Edlinger <bernd.edlin...@hotmail.de>
PR rtl-optimization/61047
* gcc.c-torture/execute/20140611-1.c: New testcase.
patch-pr61047.diff
Description: Binary data
