On Sat, 15 Oct 2016, Marc Glisse wrote:
> On Thu, 13 Oct 2016, Richard Biener wrote:
>
> > The patch introduces '@@' captures which do two things - first they
> > change the comparison used for matching back to operand_equal_p
> > only (thus perform "value-matching"), second the @@ capture
On Thu, 13 Oct 2016, Richard Biener wrote:
The patch introduces '@@' captures which do two things - first they
change the comparison used for matching back to operand_equal_p
only (thus perform "value-matching"), second the @@ capture denotes
the specific operand that should be refered to in
On Wed, 12 Oct 2016, Richard Biener wrote:
> On Wed, 12 Oct 2016, Marc Glisse wrote:
>
> > On Wed, 12 Oct 2016, Richard Biener wrote:
> >
> > > So with doing the same on GENERIC I hit
> > >
> > > FAIL: g++.dg/cpp1y/constexpr-array4.C -std=c++14 (test for excess errors)
> > >
> > > with the
On Wed, 12 Oct 2016, Marc Glisse wrote:
> On Wed, 12 Oct 2016, Richard Biener wrote:
>
> > So with doing the same on GENERIC I hit
> >
> > FAIL: g++.dg/cpp1y/constexpr-array4.C -std=c++14 (test for excess errors)
> >
> > with the pattern
> >
> > /* (T)(P + A) - (T)P -> (T) A */
> > (for
On Wed, 12 Oct 2016, Richard Biener wrote:
So with doing the same on GENERIC I hit
FAIL: g++.dg/cpp1y/constexpr-array4.C -std=c++14 (test for excess errors)
with the pattern
/* (T)(P + A) - (T)P -> (T) A */
(for add (plus pointer_plus)
(simplify
(minus (convert (add @0 @1))
On Tue, 11 Oct 2016, Marc Glisse wrote:
> On Tue, 11 Oct 2016, Richard Biener wrote:
>
> > > An example that regressed at -O (looking at the .optimized dump)
> > >
> > > int f(int a, unsigned b){
> > > a &= 1;
> > > b &= 1;
> > > return a
> > > }
> >
> > Yeah, but it usually also shows a
On Tue, 11 Oct 2016, Richard Biener wrote:
An example that regressed at -O (looking at the .optimized dump)
int f(int a, unsigned b){
a &= 1;
b &= 1;
return a
}
Yeah, but it usually also shows a badly written pattern:
/* (X & Y) & (X & Z) -> (X & Y) & Z
(X | Y) | (X | Z) -> (X | Y)
On Mon, 10 Oct 2016, Marc Glisse wrote:
> On Fri, 7 Oct 2016, Richard Biener wrote:
>
> > On Thu, 6 Oct 2016, Marc Glisse wrote:
> >
> > > On Wed, 5 Oct 2016, Richard Biener wrote:
> > >
> > > > > The following will fix PR77826, the issue that in match.pd matching
> > > > > up two things uses
On Fri, 7 Oct 2016, Richard Biener wrote:
On Thu, 6 Oct 2016, Marc Glisse wrote:
On Wed, 5 Oct 2016, Richard Biener wrote:
The following will fix PR77826, the issue that in match.pd matching
up two things uses operand_equal_p which is too lax about the type
of the toplevel entity (at least
On Thu, 6 Oct 2016, Marc Glisse wrote:
> On Wed, 5 Oct 2016, Richard Biener wrote:
>
> > > The following will fix PR77826, the issue that in match.pd matching
> > > up two things uses operand_equal_p which is too lax about the type
> > > of the toplevel entity (at least for integer constants).
>
On Wed, 5 Oct 2016, Richard Biener wrote:
The following will fix PR77826, the issue that in match.pd matching
up two things uses operand_equal_p which is too lax about the type
of the toplevel entity (at least for integer constants).
Bootstrap / regtest pending on x86_64-unknown-linux-gnu.
On Tue, 4 Oct 2016, Richard Biener wrote:
>
> The following will fix PR77826, the issue that in match.pd matching
> up two things uses operand_equal_p which is too lax about the type
> of the toplevel entity (at least for integer constants).
>
> Bootstrap / regtest pending on
The following will fix PR77826, the issue that in match.pd matching
up two things uses operand_equal_p which is too lax about the type
of the toplevel entity (at least for integer constants).
Bootstrap / regtest pending on x86_64-unknown-linux-gnu.
Richard.
2016-10-04 Richard Biener
13 matches
Mail list logo
