On Fri, 22 May 2020, Jason Merrill wrote:
> On 5/22/20 9:18 PM, Patrick Palka wrote:
> > On Fri, 22 May 2020, Jason Merrill wrote:
> > > On 5/20/20 10:08 PM, Patrick Palka wrote:
> > > > On Wed, 20 May 2020, Patrick Palka wrote:
> > > > > On Tue, 19 May 2020, Jason Merrill wrote:
> > > > >
> > > >
On 5/22/20 9:18 PM, Patrick Palka wrote:
On Fri, 22 May 2020, Jason Merrill wrote:
On 5/20/20 10:08 PM, Patrick Palka wrote:
On Wed, 20 May 2020, Patrick Palka wrote:
On Tue, 19 May 2020, Jason Merrill wrote:
On 5/8/20 11:42 AM, Patrick Palka wrote:
On Wed, 6 May 2020, Patrick Palka wrote:
On Fri, 22 May 2020, Jason Merrill wrote:
> On 5/20/20 10:08 PM, Patrick Palka wrote:
> > On Wed, 20 May 2020, Patrick Palka wrote:
> > > On Tue, 19 May 2020, Jason Merrill wrote:
> > >
> > > > On 5/8/20 11:42 AM, Patrick Palka wrote:
> > > > > On Wed, 6 May 2020, Patrick Palka wrote:
> > > > >
>
On 5/20/20 10:08 PM, Patrick Palka wrote:
On Wed, 20 May 2020, Patrick Palka wrote:
On Tue, 19 May 2020, Jason Merrill wrote:
On 5/8/20 11:42 AM, Patrick Palka wrote:
On Wed, 6 May 2020, Patrick Palka wrote:
On Wed, 6 May 2020, Patrick Palka wrote:
On Tue, 5 May 2020, Patrick Palka wrote:
On Wed, 20 May 2020, Patrick Palka wrote:
> On Tue, 19 May 2020, Jason Merrill wrote:
>
> > On 5/8/20 11:42 AM, Patrick Palka wrote:
> > > On Wed, 6 May 2020, Patrick Palka wrote:
> > >
> > > > On Wed, 6 May 2020, Patrick Palka wrote:
> > > >
> > > > > On Tue, 5 May 2020, Patrick Palka wrote:
>
t; -fold_cache->put (x, x);
> > + if (!c.evaluation_restricted_p ())
> > +{
> > + fold_cache->put (org_x, x);
> > + /* Prevent that we try to fold an already folded result again. */
> > + if (x != org_x)
> > + fold_cache->put
On 5/8/20 11:42 AM, Patrick Palka wrote:
On Wed, 6 May 2020, Patrick Palka wrote:
On Wed, 6 May 2020, Patrick Palka wrote:
On Tue, 5 May 2020, Patrick Palka wrote:
On Tue, 5 May 2020, Patrick Palka wrote:
Unfortunately, the previous fix to PR94038 is fragile. When the
argument to fold_fo
On Wed, 6 May 2020, Patrick Palka wrote:
> On Wed, 6 May 2020, Patrick Palka wrote:
>
> > On Tue, 5 May 2020, Patrick Palka wrote:
> >
> > > On Tue, 5 May 2020, Patrick Palka wrote:
> > >
> > > > Unfortunately, the previous fix to PR94038 is fragile. When the
> > > > argument to fold_for_warn
On Wed, 6 May 2020, Patrick Palka wrote:
> On Tue, 5 May 2020, Patrick Palka wrote:
>
> > On Tue, 5 May 2020, Patrick Palka wrote:
> >
> > > Unfortunately, the previous fix to PR94038 is fragile. When the
> > > argument to fold_for_warn is a bare CALL_EXPR, then all is well: the
> > > result of
On Tue, 5 May 2020, Patrick Palka wrote:
> On Tue, 5 May 2020, Patrick Palka wrote:
>
> > Unfortunately, the previous fix to PR94038 is fragile. When the
> > argument to fold_for_warn is a bare CALL_EXPR, then all is well: the
> > result of maybe_constant_value from fold_for_warn (with
> > uid_s
On Tue, 5 May 2020, Patrick Palka wrote:
> Unfortunately, the previous fix to PR94038 is fragile. When the
> argument to fold_for_warn is a bare CALL_EXPR, then all is well: the
> result of maybe_constant_value from fold_for_warn (with
> uid_sensitive=true) is reused via the cv_cache in the subse
Unfortunately, the previous fix to PR94038 is fragile. When the
argument to fold_for_warn is a bare CALL_EXPR, then all is well: the
result of maybe_constant_value from fold_for_warn (with
uid_sensitive=true) is reused via the cv_cache in the subsequent call to
maybe_constant_value from cp_fold (w
12 matches
Mail list logo