On Fri, 27 Sep 2024, Jakub Jelinek wrote:
> On Fri, Sep 27, 2024 at 12:14:47PM +0200, Richard Biener wrote:
> > I can investigate a bit when there's a testcase showing the issue.
>
> The testcase is pr78687.C with Marek's cp-gimplify.cc patch.
OK, I can reproduce. The main issue I see is that S
On Fri, Sep 27, 2024 at 12:14:47PM +0200, Richard Biener wrote:
> I can investigate a bit when there's a testcase showing the issue.
The testcase is pr78687.C with Marek's cp-gimplify.cc patch.
Or the
struct S { union U { struct T { void *a, *b, *c, *d, *e; } t; struct V {} v; }
u; unsigned long
On Fri, 27 Sep 2024, Jakub Jelinek wrote:
> On Fri, Sep 27, 2024 at 08:16:43AM +0200, Richard Biener wrote:
> > > __attribute__((noinline))
> > > struct ref_proxy f ()
> > > {
> > >struct ref_proxy ptr;
> > >struct ref_proxy D.10036;
> > >struct ref_proxy type;
> > >struct ref_prox
On Fri, Sep 27, 2024 at 08:16:43AM +0200, Richard Biener wrote:
> > __attribute__((noinline))
> > struct ref_proxy f ()
> > {
> >struct ref_proxy ptr;
> >struct ref_proxy D.10036;
> >struct ref_proxy type;
> >struct ref_proxy type;
> >struct qual_option D.10031;
> >struct re
On Thu, 26 Sep 2024, Marek Polacek wrote:
> On Wed, Sep 25, 2024 at 08:45:50PM -0400, Jason Merrill wrote:
> > On 9/25/24 4:21 PM, Marek Polacek wrote:
> > > On Wed, Sep 25, 2024 at 08:54:46AM -0400, Jason Merrill wrote:
> > > > On 9/24/24 5:10 PM, Marek Polacek wrote:
> > > > > On Fri, Sep 20, 20
On Wed, Sep 25, 2024 at 08:45:50PM -0400, Jason Merrill wrote:
> On 9/25/24 4:21 PM, Marek Polacek wrote:
> > On Wed, Sep 25, 2024 at 08:54:46AM -0400, Jason Merrill wrote:
> > > On 9/24/24 5:10 PM, Marek Polacek wrote:
> > > > On Fri, Sep 20, 2024 at 06:39:52PM -0400, Jason Merrill wrote:
> > > >
On 9/25/24 4:21 PM, Marek Polacek wrote:
On Wed, Sep 25, 2024 at 08:54:46AM -0400, Jason Merrill wrote:
On 9/24/24 5:10 PM, Marek Polacek wrote:
On Fri, Sep 20, 2024 at 06:39:52PM -0400, Jason Merrill wrote:
On 9/20/24 12:18 AM, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-g
On Wed, Sep 25, 2024 at 08:54:46AM -0400, Jason Merrill wrote:
> On 9/24/24 5:10 PM, Marek Polacek wrote:
> > On Fri, Sep 20, 2024 at 06:39:52PM -0400, Jason Merrill wrote:
> > > On 9/20/24 12:18 AM, Marek Polacek wrote:
> > > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
> > > >
On 9/24/24 5:10 PM, Marek Polacek wrote:
On Fri, Sep 20, 2024 at 06:39:52PM -0400, Jason Merrill wrote:
On 9/20/24 12:18 AM, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
This PR reports a missed optimization. When we have:
Str str{"Test"};
On Sat, Sep 21, 2024 at 05:00:51PM +0200, Jakub Jelinek wrote:
> On Fri, Sep 20, 2024 at 07:03:45PM -0400, Jason Merrill wrote:
> > > The CALL_EXPR case in cp_fold uses !flag_no_inline instead, that makes
> > > more
> > > sense to me.
> > > Because checking "noinline" attribute (which means don't
On Fri, Sep 20, 2024 at 06:39:52PM -0400, Jason Merrill wrote:
> On 9/20/24 12:18 AM, Marek Polacek wrote:
> > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
> >
> > -- >8 --
> > This PR reports a missed optimization. When we have:
> >
> >Str str{"Test"};
> >callback(str);
On Fri, Sep 20, 2024 at 07:03:45PM -0400, Jason Merrill wrote:
> > The CALL_EXPR case in cp_fold uses !flag_no_inline instead, that makes more
> > sense to me.
> > Because checking "noinline" attribute (which means don't inline this
> > function) on current_function_decl rather than on functions be
On 9/20/24 12:40 AM, Jakub Jelinek wrote:
On Fri, Sep 20, 2024 at 06:18:15PM -0400, Marek Polacek wrote:
--- a/gcc/cp/cp-gimplify.cc
+++ b/gcc/cp/cp-gimplify.cc
@@ -1473,6 +1473,20 @@ cp_fold_r (tree *stmt_p, int *walk_subtrees, void *data_)
that case, strip it in favor of this one. */
On Fri, Sep 20, 2024 at 06:18:15PM -0400, Marek Polacek wrote:
> --- a/gcc/cp/cp-gimplify.cc
> +++ b/gcc/cp/cp-gimplify.cc
> @@ -1473,6 +1473,20 @@ cp_fold_r (tree *stmt_p, int *walk_subtrees, void
> *data_)
>that case, strip it in favor of this one. */
>if (tree &init = TARGET_EX
On 9/20/24 12:18 AM, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
This PR reports a missed optimization. When we have:
Str str{"Test"};
callback(str);
as in the test, we're able to evaluate the Str::Str() call at compile
time. But when we h
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
This PR reports a missed optimization. When we have:
Str str{"Test"};
callback(str);
as in the test, we're able to evaluate the Str::Str() call at compile
time. But when we have:
callback(Str{"Test"});
we are not. W
16 matches
Mail list logo
