From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <hubicka@kam.mff.cuni.cz>
Received: from nikam.ms.mff.cuni.cz (nikam.ms.mff.cuni.cz [195.113.20.16])
 by sourceware.org (Postfix) with ESMTPS id A1380385BF92
 for <gcc-patches@gcc.gnu.org>; Fri,  3 Apr 2020 15:26:10 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org A1380385BF92
Authentication-Results: sourceware.org;
 dmarc=none (p=none dis=none) header.from=ucw.cz
Authentication-Results: sourceware.org;
 spf=none smtp.mailfrom=hubicka@kam.mff.cuni.cz
Received: by nikam.ms.mff.cuni.cz (Postfix, from userid 16202)
 id 3CBEA280435; Fri,  3 Apr 2020 17:26:09 +0200 (CEST)
Date: Fri, 3 Apr 2020 17:26:09 +0200
From: Jan Hubicka <hubicka@ucw.cz>
To: Martin =?iso-8859-2?Q?Li=B9ka?= <mliska@suse.cz>
Cc: Richard Biener <richard.guenther@gmail.com>,
 GCC Patches <gcc-patches@gcc.gnu.org>, Marc Glisse <marc.glisse@inria.fr>
Subject: Re: [PATCH] Check DECL_CONTEXT of new/delete operators.
Message-ID: <20200403152609.GA35629@kam.mff.cuni.cz>
References: <af29444d-118a-4818-26ca-bbe468a587dd@suse.cz>
 <CAFiYyc03b7gQONwgma3s7TsX-Ga-8ZFy8SW8SiEZgzjor--e4A@mail.gmail.com>
 <20200331122907.GB62067@kam.mff.cuni.cz>
 <65230a52-c025-a6e3-0d31-409d37e9b2c9@suse.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <65230a52-c025-a6e3-0d31-409d37e9b2c9@suse.cz>
User-Agent: Mutt/1.10.1 (2018-07-13)
X-Spam-Status: No, score=-31.1 required=5.0 tests=BAYES_00,
 HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY,
 RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE,
 TXREP autolearn=no autolearn_force=no version=3.4.2
X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on
 server2.sourceware.org
X-BeenThere: gcc-patches@gcc.gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Gcc-patches mailing list <gcc-patches.gcc.gnu.org>
List-Unsubscribe: <http://gcc.gnu.org/mailman/options/gcc-patches>,
 <mailto:gcc-patches-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc-patches/>
List-Post: <mailto:gcc-patches@gcc.gnu.org>
List-Help: <mailto:gcc-patches-request@gcc.gnu.org?subject=help>
List-Subscribe: <http://gcc.gnu.org/mailman/listinfo/gcc-patches>,
 <mailto:gcc-patches-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Apr 2020 15:26:12 -0000

> On 3/31/20 2:29 PM, Jan Hubicka wrote:
> > Well, I basically went through all pointers and tried to get rid of as
> > many of them as possible.  CONTEXT pointers do increase size of SCCs
> > that increases chance they will not get merged and also processing time
> > of merging algorithm.  I guess if we need to stream more contexts we
> > could do that (and check the effect on merging and average SCC size)
> 
> Ok, do we want to stream contexts just for the new/delete operators?
> Can you please prepare a streaming patch?
Hi,
I am still not convinced that context is useful here.
It took me a while to understand what the code does and why it fails,
but here is a testcase.
It fails for me with your patch and -O2 --param early-inlining-insns=100

The invalid transform is to remove pair
base:new and B:delete
B:new gets inlined and we get count out of sync.

Honza

#include <stdio.h>
volatile int idx;
struct base
{
  __attribute__((malloc,noinline))
  static void* operator new(unsigned long sz)
  {
    return ::operator new(sz);
  }

  __attribute__((malloc,noinline))
  static void operator delete(void* ptr)
  {
    --count[idx];
    ::operator delete(ptr);
  }
  volatile static int count[2];
};
volatile int base::count[2] = {0,0};
struct B:base
{
  static void* operator new(unsigned long sz)
  {
    ++count[idx];
    return base::operator new(sz);
  }

};


volatile int c=1;

int main(){
  for (int i; i<c;i++)
    {
      idx=0;
      delete new B;
      if (B::count[0] != 0)
	__builtin_abort ();
    }


  return 0;
}