On Sat, Nov 9, 2013 at 12:18 AM, Marc Glisse wrote:
> On Wed, 6 Nov 2013, Richard Biener wrote:
>
>> So the only thing that remains is the mem_ref_offset thing and yes, I
>> guess
>> I'd prefer to use double-ints because we deal with bit offsets in the end.
>
>
> Here it is (bootstrap+testsuite on
On Wed, 6 Nov 2013, Richard Biener wrote:
So the only thing that remains is the mem_ref_offset thing and yes, I guess
I'd prefer to use double-ints because we deal with bit offsets in the end.
Here it is (bootstrap+testsuite on x86_64-unknown-linux-gnu). It feels
rather artificial to do this s
On Wed, Nov 6, 2013 at 3:08 PM, Marc Glisse wrote:
> On Wed, 6 Nov 2013, Richard Biener wrote:
>
>> On Wed, Nov 6, 2013 at 1:19 PM, Marc Glisse wrote:
>>>
>>> [Discussion started in
>>> http://gcc.gnu.org/ml/gcc-patches/2013-10/msg02472.html ]
>>>
>>>
>>> On Wed, 30 Oct 2013, Marc Glisse wrote:
>
On Wed, 6 Nov 2013, Richard Biener wrote:
On Wed, Nov 6, 2013 at 1:19 PM, Marc Glisse wrote:
[Discussion started in
http://gcc.gnu.org/ml/gcc-patches/2013-10/msg02472.html ]
On Wed, 30 Oct 2013, Marc Glisse wrote:
On Wed, 30 Oct 2013, Richard Biener wrote:
Btw, get_addr_base_and_unit_off
On Wed, Nov 6, 2013 at 1:19 PM, Marc Glisse wrote:
> [Discussion started in
> http://gcc.gnu.org/ml/gcc-patches/2013-10/msg02472.html ]
>
>
> On Wed, 30 Oct 2013, Marc Glisse wrote:
>
>> On Wed, 30 Oct 2013, Richard Biener wrote:
>>
>>> Btw, get_addr_base_and_unit_offset may also return an offsett
[Discussion started in http://gcc.gnu.org/ml/gcc-patches/2013-10/msg02472.html ]
On Wed, 30 Oct 2013, Marc Glisse wrote:
On Wed, 30 Oct 2013, Richard Biener wrote:
Btw, get_addr_base_and_unit_offset may also return an offsetted
MEM_REF (from &MEM [p_3, 17] for example). As we are interested
On Wed, 30 Oct 2013, Richard Biener wrote:
Btw, get_addr_base_and_unit_offset may also return an offsetted
MEM_REF (from &MEM [p_3, 17] for example). As we are interested in
pointers this could be handled by not requiring a memory reference
but extracting the base address and offset, covering m
On 10/30/13 03:34, Richard Biener wrote:
* tree-ssa-alias.c (stmt_kills_ref_p_1): Handle case where
ao_ref_base returns a MEM_REF.
* gcc.dg/tree-ssa/alias-26.c: New test.
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/alias-26.c
b/gcc/testsuite/gcc.dg/tree-ssa/alias-26.c
On Tue, Oct 29, 2013 at 11:23 PM, Marc Glisse wrote:
> On Tue, 29 Oct 2013, Jeff Law wrote:
>
>> Marc pointed out that the handling of various BUILT_IN_MEM* and
>> BUILT_IN_STR* functions in tree-ssa-alias.c probably wasn't working as
>> intended because the code wasn't prepared for a common retur
On Tue, Oct 29, 2013 at 10:36 PM, Jeff Law wrote:
>
> Marc pointed out that the handling of various BUILT_IN_MEM* and
> BUILT_IN_STR* functions in tree-ssa-alias.c probably wasn't working as
> intended because the code wasn't prepared for a common return value from
> ao_ref_base, particularly retu
On Tue, 29 Oct 2013, Jeff Law wrote:
Marc pointed out that the handling of various BUILT_IN_MEM* and BUILT_IN_STR*
functions in tree-ssa-alias.c probably wasn't working as intended because the
code wasn't prepared for a common return value from ao_ref_base, particularly
returns of MEM_REFs.
Marc pointed out that the handling of various BUILT_IN_MEM* and
BUILT_IN_STR* functions in tree-ssa-alias.c probably wasn't working as
intended because the code wasn't prepared for a common return value from
ao_ref_base, particularly returns of MEM_REFs.
This patch fixes the code to handle t
12 matches
Mail list logo
