Hi,
On Thu, 12 Jun 2014 12:49:13, Richard Biener wrote:
>
> On Thu, Jun 12, 2014 at 10:36 AM, Eric Botcazou wrote:
>>> Btw, I wonder if we can simply mark the MEMs generated from spill code
>>> with MEM_NOTRAP_P so we can remove the special casing of
>>> frame-pointer-based addresses from add whi
On Thu, Jun 12, 2014 at 10:36 AM, Eric Botcazou wrote:
>> Btw, I wonder if we can simply mark the MEMs generated from spill code
>> with MEM_NOTRAP_P so we can remove the special casing of
>> frame-pointer-based addresses from add while properly initializing
>> MEM_NOTRAP_p from rtx_addr_can_trap_
On Thu, 12 Jun 2014 10:50:29, Eric Botcazou wrote:
>
>> Btw I am not sure at all, why argp-references can never be dangerous?
>> For instance in a struct with an array inside, passed as function argument?
>
> IMO there cannot be any definitive solution to this issue until after we move
> all the af
> Btw I am not sure at all, why argp-references can never be dangerous?
> For instance in a struct with an array inside, passed as function argument?
IMO there cannot be any definitive solution to this issue until after we move
all the affected optimizations from RTL to GIMPLE. In the meantime,
On Thu, 12 Jun 2014 10:36:25, Eric Botcazou wrote:
>
>> Btw, I wonder if we can simply mark the MEMs generated from spill code
>> with MEM_NOTRAP_P so we can remove the special casing of
>> frame-pointer-based addresses from add while properly initializing
>> MEM_NOTRAP_p from rtx_addr_can_trap_p?
> Btw, I wonder if we can simply mark the MEMs generated from spill code
> with MEM_NOTRAP_P so we can remove the special casing of
> frame-pointer-based addresses from add while properly initializing
> MEM_NOTRAP_p from rtx_addr_can_trap_p?
Spill code generated by the compiler itself? That's qui
On Thu, Jun 12, 2014 at 10:03 AM, Eric Botcazou wrote:
>> This patch tries to get safe lower and upper bounds where accesses
>> are always guaranteed to work. The goal is not to penalize
>> reasonable written code: When boot-strapping the whole GCC
>> only a few places were found, where this new
> This patch tries to get safe lower and upper bounds where accesses
> are always guaranteed to work. The goal is not to penalize
> reasonable written code: When boot-strapping the whole GCC
> only a few places were found, where this new check triggers.
>
> Boot-strapped and regression-tested on
Hi,
this patch fixes PR 61047, where rtx_addr_can_trap_p_1
incorrectly assumes, that all SP-relative offsets can be safely
read witout causing any traps. And therefore such references
are safe to be moved out of an if-block.
This patch tries to get safe lower and upper bounds where accesses
are a
