On Wed, 16 Jan 2013, Eric Botcazou wrote:
> > Not necessarily. The following is a 4.7 variant of the patch
> > (on trunk get_object_alignment_1 got one extra output which
> > moved the align return value to by-reference).
>
> OK, I obviously didn't try very hard here...
>
> > Can you give it te
> Not necessarily. The following is a 4.7 variant of the patch
> (on trunk get_object_alignment_1 got one extra output which
> moved the align return value to by-reference).
OK, I obviously didn't try very hard here...
> Can you give it testing on the branch and a strict-align target?
>
> Thank
On Tue, 15 Jan 2013, Eric Botcazou wrote:
> > I have applied the minimal fix to trunk now. We retain the clearly
> > incorrect fact that the !align_computed path only ever increases
> > alignment (it's only ever set previously to either BITS_PER_UNIT
> > or via the MEM_REF block). I will momenta
> I have applied the minimal fix to trunk now. We retain the clearly
> incorrect fact that the !align_computed path only ever increases
> alignment (it's only ever set previously to either BITS_PER_UNIT
> or via the MEM_REF block). I will momentarily test a followup
> removing that block for trun
On Fri, 11 Jan 2013, Richard Biener wrote:
> On Thu, 10 Jan 2013, Eric Botcazou wrote:
>
> > > The problem with this intermediate inconsistency is that ...
> > >
> > > > That's why only the final result should matter and need be correct.
> > >
> > > ... this can't be ensured anymore. In some c
On Thu, 10 Jan 2013, Eric Botcazou wrote:
> > The problem with this intermediate inconsistency is that ...
> >
> > > That's why only the final result should matter and need be correct.
> >
> > ... this can't be ensured anymore. In some cases the inconsistency
> > between the mem attributes and
> The problem with this intermediate inconsistency is that ...
>
> > That's why only the final result should matter and need be correct.
>
> ... this can't be ensured anymore. In some cases the inconsistency
> between the mem attributes and what XEXP(MEM, 0) represents can't be
> repaired by the
On Thu, 10 Jan 2013, Michael Matz wrote:
> Hi,
>
> On Thu, 10 Jan 2013, Eric Botcazou wrote:
>
> > > Going over this what's strange as well is that we adjust MEM_SIZE
> > > with bitpos, too. At least when the MEM has non-BLKmode this
> > > means that MEMs mode and MEM_SIZE is inconsistent? Or
Hi,
On Thu, 10 Jan 2013, Eric Botcazou wrote:
> > Going over this what's strange as well is that we adjust MEM_SIZE
> > with bitpos, too. At least when the MEM has non-BLKmode this
> > means that MEMs mode and MEM_SIZE is inconsistent? Or how do
> > a MEMs mode and MEM_SIZE relate?
>
> Yes, th
> Going over this what's strange as well is that we adjust MEM_SIZE
> with bitpos, too. At least when the MEM has non-BLKmode this
> means that MEMs mode and MEM_SIZE is inconsistent? Or how do
> a MEMs mode and MEM_SIZE relate?
Yes, the MEM attributes are incomplete/inconsistent between the cal
On Thu, 10 Jan 2013, Richard Biener wrote:
> On Thu, 10 Jan 2013, Richard Biener wrote:
>
> > On Wed, 9 Jan 2013, Eric Botcazou wrote:
> >
> > > > This fixes PR55882 - set_mem_attributes_minus_bitpos misses to
> > > > account for the to-be applied bitpos when computing MEM_ALIGN.
> > > > It extr
On Thu, 10 Jan 2013, Richard Biener wrote:
> On Wed, 9 Jan 2013, Eric Botcazou wrote:
>
> > > This fixes PR55882 - set_mem_attributes_minus_bitpos misses to
> > > account for the to-be applied bitpos when computing MEM_ALIGN.
> > > It extracts alignment from 't' instead of &t - bitpos.
> > >
> >
On Wed, 9 Jan 2013, Eric Botcazou wrote:
> > This fixes PR55882 - set_mem_attributes_minus_bitpos misses to
> > account for the to-be applied bitpos when computing MEM_ALIGN.
> > It extracts alignment from 't' instead of &t - bitpos.
> >
> > Bootstrapped and tested on x86_64-unknown-linux-gnu, bo
> This fixes PR55882 - set_mem_attributes_minus_bitpos misses to
> account for the to-be applied bitpos when computing MEM_ALIGN.
> It extracts alignment from 't' instead of &t - bitpos.
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu, bootstrap
> and regtest running on mips.
>
> Does thi
This fixes PR55882 - set_mem_attributes_minus_bitpos misses to
account for the to-be applied bitpos when computing MEM_ALIGN.
It extracts alignment from 't' instead of &t - bitpos.
Bootstrapped and tested on x86_64-unknown-linux-gnu, bootstrap
and regtest running on mips.
Does this look sensible
15 matches
Mail list logo
