On Wed, Jul 27, 2011 at 9:23 PM, Ulrich Weigand wrote:
> Martin Jambor wrote:
>> On Wed, Jul 27, 2011 at 02:34:59PM +0200, Ulrich Weigand wrote:
>> > Martin Jambor wrote:
>> >
>> > > OK, this is what I have just committed as revision 176797 after
>> > > re-testing.
>> >
>> > Thanks, this has fixed
Martin Jambor wrote:
> On Wed, Jul 27, 2011 at 02:34:59PM +0200, Ulrich Weigand wrote:
> > Martin Jambor wrote:
> >
> > > OK, this is what I have just committed as revision 176797 after
> > > re-testing.
> >
> > Thanks, this has fixed the forwprop-5.c regression on spu-elf on mainline.
> >
> > I
Martin Jambor wrote:
> On Wed, Jul 27, 2011 at 02:34:59PM +0200, Ulrich Weigand wrote:
> > I'm seeing the same failure on the 4.6 branch -- would this patch also be
> > appropriate there?
>
> You're right, it should be applied to the 4.6 branch too. Since you
> have the setup to thest it, can you
Hi,
On Wed, Jul 27, 2011 at 02:34:59PM +0200, Ulrich Weigand wrote:
> Martin Jambor wrote:
>
> > OK, this is what I have just committed as revision 176797 after
> > re-testing.
>
> Thanks, this has fixed the forwprop-5.c regression on spu-elf on mainline.
>
> I'm seeing the same failure on the
Martin Jambor wrote:
> OK, this is what I have just committed as revision 176797 after
> re-testing.
Thanks, this has fixed the forwprop-5.c regression on spu-elf on mainline.
I'm seeing the same failure on the 4.6 branch -- would this patch also be
appropriate there?
Thanks,
Ulrich
--
Dr.
On Tue, Jul 26, 2011 at 09:39:02AM +0200, Richard Guenther wrote:
> On Mon, Jul 25, 2011 at 7:52 PM, Martin Jambor wrote:
...
> >
> > 2011-07-25 Martin Jambor
> >
> > * tree-sra.c (tree_non_mode_aligned_mem_p): Strip conversions and
> > return false for invariants.
> >
> > Index
On Mon, Jul 25, 2011 at 7:52 PM, Martin Jambor wrote:
> Hi,
>
> On Thu, Jul 21, 2011 at 11:40:32AM +0200, Martin Jambor wrote:
>> Hi,
>>
>> On Thu, Jul 21, 2011 at 10:34:35AM +0200, Richard Guenther wrote:
>> > On Wed, 20 Jul 2011, Ulrich Weigand wrote:
>> >
>> > > Richard Guenther wrote:
>> > > >
Martin Jambor wrote:
> Like this? Ulrich, can you please verify it works? I have
> bootstrapped this on x86_64 but there it obvioulsy works and my run of
> compile/testsuite on compile farm sparc64 will take some time (plus,
> the testcase you complained about passes there).
Yes, this does fix
Hi,
On Thu, Jul 21, 2011 at 11:40:32AM +0200, Martin Jambor wrote:
> Hi,
>
> On Thu, Jul 21, 2011 at 10:34:35AM +0200, Richard Guenther wrote:
> > On Wed, 20 Jul 2011, Ulrich Weigand wrote:
> >
> > > Richard Guenther wrote:
> > > > On Tue, Jul 19, 2011 at 8:20 PM, Ulrich Weigand
> > > > wrote:
Hi,
On Thu, Jul 21, 2011 at 10:34:35AM +0200, Richard Guenther wrote:
> On Wed, 20 Jul 2011, Ulrich Weigand wrote:
>
> > Richard Guenther wrote:
> > > On Tue, Jul 19, 2011 at 8:20 PM, Ulrich Weigand
> > > wrote:
> > > > The problem is that in this expression
> > > > disappear = VIEW_CONVERT_E
On Wed, 20 Jul 2011, Ulrich Weigand wrote:
> Richard Guenther wrote:
> > On Tue, Jul 19, 2011 at 8:20 PM, Ulrich Weigand wrote:
> > > The problem is that in this expression
> > > disappear = VIEW_CONVERT_EXPR(x_8);
> > > the rhs is considered unaligned and blocks the SRA transformation.
> > >
>
Richard Guenther wrote:
> On Tue, Jul 19, 2011 at 8:20 PM, Ulrich Weigand wrote:
> > The problem is that in this expression
> > disappear = VIEW_CONVERT_EXPR(x_8);
> > the rhs is considered unaligned and blocks the SRA transformation.
> >
> > The check you added for SSA_NAMEs doesn't hit, becaus
On Tue, Jul 19, 2011 at 8:20 PM, Ulrich Weigand wrote:
> Martin Jambor wrote:
>
>> I had to add a test that the analyzed expression is not an SSA name.
>> This has been approved by Rchi on IRC yesterday. Thus, I have
>> committed the following as revision 175703 after successful run of c
>> and c
Martin Jambor wrote:
> I had to add a test that the analyzed expression is not an SSA name.
> This has been approved by Rchi on IRC yesterday. Thus, I have
> committed the following as revision 175703 after successful run of c
> and c++ testsuite on sparc64 (and a bootstrap and test with another
Hi,
On Thu, Jun 30, 2011 at 06:36:01PM +0200, Martin Jambor wrote:
> Hi,
>
> On Thu, Jun 30, 2011 at 03:39:55PM +0200, Martin Jambor wrote:
> > Hi,
> >
> > I had to add a test that the analyzed expression is not an SSA name.
> > This has been approved by Rchi on IRC yesterday. Thus, I have
> >
On Thu, 30 Jun 2011, Martin Jambor wrote:
> Hi,
>
> On Thu, Jun 30, 2011 at 03:39:55PM +0200, Martin Jambor wrote:
> > Hi,
> >
> > I had to add a test that the analyzed expression is not an SSA name.
> > This has been approved by Rchi on IRC yesterday. Thus, I have
> > committed the following a
Hi,
On Thu, Jun 30, 2011 at 03:39:55PM +0200, Martin Jambor wrote:
> Hi,
>
> I had to add a test that the analyzed expression is not an SSA name.
> This has been approved by Rchi on IRC yesterday. Thus, I have
> committed the following as revision 175703 after successful run of c
> and c++ tests
Hi,
I had to add a test that the analyzed expression is not an SSA name.
This has been approved by Rchi on IRC yesterday. Thus, I have
committed the following as revision 175703 after successful run of c
and c++ testsuite on sparc64 (and a bootstrap and test with another
patch on x86_64-linux).
Hi,
On Mon, Jun 27, 2011 at 03:18:01PM +0200, Richard Guenther wrote:
> On Sun, 26 Jun 2011, Martin Jambor wrote:
>
> > Hi,
> >
> > under some circumstances involving user specified alignment and/or
> > packed attributes, SRA can create a misaligned MEM_REF. As the
> > testcase demonstrates, it
On Sun, 26 Jun 2011, Martin Jambor wrote:
> Hi,
>
> under some circumstances involving user specified alignment and/or
> packed attributes, SRA can create a misaligned MEM_REF. As the
> testcase demonstrates, it is not enough to not consider variables with
> these type attributes, mainly because
Hi,
under some circumstances involving user specified alignment and/or
packed attributes, SRA can create a misaligned MEM_REF. As the
testcase demonstrates, it is not enough to not consider variables with
these type attributes, mainly because we might attempt to load/store
the scalar replacements
21 matches
Mail list logo
