On Tue, 13 Mar 2012, Michael Matz wrote:
> Hi,
>
> On Mon, 12 Mar 2012, Martin Jambor wrote:
>
> > OK, the following patch changes the places where I previously called the
> > new function to call expand_expr with EXPAND_WRITE modifier and then
> > makes sure we do not perform reads into rvalu
Hi,
On Mon, 12 Mar 2012, Martin Jambor wrote:
> OK, the following patch changes the places where I previously called the
> new function to call expand_expr with EXPAND_WRITE modifier and then
> makes sure we do not perform reads into rvalues in expand_expr_real_1 in
> the contexts where I need
Hi,
On Mon, Mar 12, 2012 at 04:26:21PM +0100, Michael Matz wrote:
> Hi,
>
> On Mon, 12 Mar 2012, Martin Jambor wrote:
>
> > when we expand a misaligned MEM_REF on the LHS, we must not call the
> > code in expand_expr_real_1 if the subsequent patch is applied, because
> > the code generates code
Hi,
On Mon, 12 Mar 2012, Martin Jambor wrote:
> when we expand a misaligned MEM_REF on the LHS, we must not call the
> code in expand_expr_real_1 if the subsequent patch is applied, because
> the code generates code extracting the contents of the memory to a
> register, which is of course bad if
On Mon, 12 Mar 2012, Martin Jambor wrote:
> Hi,
>
> when we expand a misaligned MEM_REF on the LHS, we must not call the
> code in expand_expr_real_1 if the subsequent patch is applied, because
> the code generates code extracting the contents of the memory to a
> register, which is of course bad
Hi,
when we expand a misaligned MEM_REF on the LHS, we must not call the
code in expand_expr_real_1 if the subsequent patch is applied, because
the code generates code extracting the contents of the memory to a
register, which is of course bad if the intent is to write into that
memory. Therefore
