From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 109557 invoked by alias); 14 Jan 2020 02:58:55 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 109547 invoked by uid 89); 14 Jan 2020 02:58:55 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-10.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 spammy= X-HELO: us-smtp-1.mimecast.com Received: from us-smtp-delivery-1.mimecast.com (HELO us-smtp-1.mimecast.com) (205.139.110.120) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 14 Jan 2020 02:58:53 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1578970732; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=nLP9q+RQbb5I2yTs/iGIcnfibZ7CPPquvcg8B5EKEmw=; b=WGAGdz3fCSbp0N1jTwBLOGmzafh3Iy+CLADbpV6XQIgXnYOatvHpOtj8Guzr6p53rLcmXh 5I3CZk7VYekjvvZJDMJ9HvS4cJuWbtqICnf2ktwvODxK93uKQdcYV4PnQLS4HyHv+sxfNV 0PXAjQRD/GPGESG6qonofySoeVbtGNI= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-370-K2bkHAA_P8abhdy6iBOOLg-1; Mon, 13 Jan 2020 21:58:51 -0500 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 1D1CF100551B; Tue, 14 Jan 2020 02:58:50 +0000 (UTC) Received: from ovpn-117-41.phx2.redhat.com (ovpn-117-41.phx2.redhat.com [10.3.117.41]) by smtp.corp.redhat.com (Postfix) with ESMTP id 6E73387EFE; Tue, 14 Jan 2020 02:58:49 +0000 (UTC) Message-ID: <10454af11705eee5ca86ca83d351e81e04d6fc45.camel@redhat.com> Subject: Re: Analyzer status From: David Malcolm To: Jakub Jelinek Cc: law@redhat.com, Richard Biener , gcc-patches@gcc.gnu.org Date: Tue, 14 Jan 2020 04:52:00 -0000 In-Reply-To: <20200113235521.GX10088@tucnak> References: <20200113221024.29991-1-dmalcolm@redhat.com> <20200113225614.GV10088@tucnak> <20200113232635.GW10088@tucnak> <20200113235521.GX10088@tucnak> User-Agent: Evolution 3.32.5 (3.32.5-1.fc30) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2020-01/txt/msg00763.txt.bz2 On Tue, 2020-01-14 at 00:55 +0100, Jakub Jelinek wrote: > On Mon, Jan 13, 2020 at 06:42:06PM -0500, David Malcolm wrote: > > Thanks. Does it have warnings, though? > >=20 > > My attempt was similar, but ran into warnings from -Wclass- > > memaccess in > > four places, like this: > >=20 > > ../../src/gcc/hash-map-traits.h:102:12: warning: =E2=80=98void* > > memset(void*, > > int, size_t)=E2=80=99 clearing an object of type =E2=80=98struct > > hash_map > std::pair >::hash_entry=E2=80=99 with no trivial > > copy- > > assignment; use assignment or value-initialization instead [- > > Wclass- > > memaccess] > > 102 | memset (entry, 0, sizeof (T) * count); > > | ~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > >=20 > > where the types in question are: > >=20 > > (1) > > struct hash_map > > > ::hash_entry > > ../../src/gcc/tree-data-ref.c:844:17: required from here >=20 > I don't understand how there could be new warnings. > The patch doesn't add any new memsets, all it does is if (0) code in > alloc_entries for certain traits and in empty_slow stops using memset > for some traits and uses mark_empty loop there instead. Your patch didn't add new memsets; mine did - clearly I misspoke when saying they were similar, mine had a somewhat different approach. Sorry for the noise, and thanks for your patch. I've extended your patch to cover the various hash traits in the analyzer and it passes the analyzer's tests. I also added in the selftests from my older patch. I examined the generated code, and it seems correct: * cfg.s correctly has a call to memset (even with no optimization) for hash_table::empty_slow * the hash_map example with nonzero empty for the analyzer: analyzer/program-state.s: sm_state_map::remap_svalue_ids: hash_map map_t; correctly shows a loop of calls to mark_empty * a hash_map example with zero empty: tree-ssa.s edge_var_maps correctly has a memset in the empty_slow, even with no optimization. ...which is promising. For the graphite case, I wondered what happens if both is_empty and is_deleted are true; looking at hash-table.h, sometimes one is checked first, sometimes the other, but I don't think it matters for this case:; you have empty_zero_p =3D false,so it uses mark_empty, rather than trying to memset, which is correct - empty_zero_p being true can be thought of as a "it is safe to optimize this hash_table/hash_map by treating empty slots as all zero", if you will. I'm trying a bootstrap build and full regression suite now, for all languages (with graphite enabled, I believe). Will post the patches if it succeeds... > This was non-bootstrapped build, but I didn't see new warnings in > there, > and for tree-data-ref.c which you've mentioned I've tried to compile > with installed trunk compiler and didn't get any warnings either. >=20 > Jakub Thanks! Sorry again about getting this wrong. Dave