From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out2.suse.de (smtp-out2.suse.de [IPv6:2a07:de40:b251:101:10:150:64:2]) by sourceware.org (Postfix) with ESMTPS id 808A3385828C for ; Tue, 30 Jan 2024 08:54:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 808A3385828C Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.de ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 808A3385828C Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a07:de40:b251:101:10:150:64:2 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1706604845; cv=none; b=DuBAmxk+bO+sG1wyBv4gUN4JdrYnio9obTyCdCFZm/xJe6MfsbH//bwY1OpEHQ2wpKGjuzhmN/tv8oaaN91lXGSjNI1uTsYm0dBRG30CRSYhdCi3VwRfknyPeDRkSQACuUN4jrDo2Xa+gU4nTmUU6bk9BWUEa/0jOnTYKSjwQSk= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1706604845; c=relaxed/simple; bh=/DK9tdlWXKW81ZmB9gAA8RQtQ94fBwWaKt5GyccZShM=; h=DKIM-Signature:DKIM-Signature:DKIM-Signature:DKIM-Signature:Date: From:To:Subject:Message-ID:MIME-Version; b=xUkAjX8e/vNSr/wQ/eSAupHVT7/rf8lUJHZ5dnE709aAfRrIxQRSWagf2d7E2uashLm9RSI3kMYkpEIgCAyKAwl/42hQgTDiBCHDpoc+MvMl55APulhQM0bCd3nU8Xvw5Wh/lReojXAkAzfiZ3WJX+aA60LlDfx+hJhuyGxFYGc= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from [10.168.4.150] (unknown [10.168.4.150]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 475891F83C; Tue, 30 Jan 2024 08:54:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1706604842; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=r21s+yi2IlhCoSCh0w+ADe08U1svXElki/EhKEqb5VI=; b=GC8iF685y7vpb7qyu8tYBZayQDL5PLsx+fe33mrGwgqIEYnhgkCCUkJe7dEu8TR2HfXlt0 LhINtUvvTrr8jSoZWg3rzQw4sENDVtdECKCz6NxDGiKaL3Q3lQCZyveIREpFICs5tGJku7 iizON0Ps+SREtDX3weIXvCyWWd6h9To= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1706604842; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=r21s+yi2IlhCoSCh0w+ADe08U1svXElki/EhKEqb5VI=; b=1eP/hy3T9FFB9TN7Qxt/XKQibhN5gwr1rnQyk85TctLlv+qV/tO0iCb63m/W5Mgil6wBYc jVs0+RIrU3p2upBw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1706604842; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=r21s+yi2IlhCoSCh0w+ADe08U1svXElki/EhKEqb5VI=; b=GC8iF685y7vpb7qyu8tYBZayQDL5PLsx+fe33mrGwgqIEYnhgkCCUkJe7dEu8TR2HfXlt0 LhINtUvvTrr8jSoZWg3rzQw4sENDVtdECKCz6NxDGiKaL3Q3lQCZyveIREpFICs5tGJku7 iizON0Ps+SREtDX3weIXvCyWWd6h9To= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1706604842; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=r21s+yi2IlhCoSCh0w+ADe08U1svXElki/EhKEqb5VI=; b=1eP/hy3T9FFB9TN7Qxt/XKQibhN5gwr1rnQyk85TctLlv+qV/tO0iCb63m/W5Mgil6wBYc jVs0+RIrU3p2upBw== Date: Tue, 30 Jan 2024 09:48:27 +0100 (CET) From: Richard Biener To: Jakub Jelinek cc: gcc-patches@gcc.gnu.org Subject: Re: [PATCH] tree-ssa-strlen: Fix up handle_store [PR113603] In-Reply-To: Message-ID: <7q0582q8-8356-40s2-p440-2682s595ns56@fhfr.qr> References: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Authentication-Results: smtp-out2.suse.de; none X-Spamd-Result: default: False [-3.10 / 50.00]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519]; RCPT_COUNT_TWO(0.00)[2]; DBL_BLOCKED_OPENRESOLVER(0.00)[suse.de:email,tree-ssa-strlen.cc:url]; FUZZY_BLOCKED(0.00)[rspamd.com]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; BAYES_HAM(-3.00)[100.00%] X-Spam-Level: X-Spam-Score: -3.10 X-Spam-Status: No, score=-5.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Tue, 30 Jan 2024, Jakub Jelinek wrote: > Hi! > > Since r10-2101-gb631bdb3c16e85f35d3 handle_store uses > count_nonzero_bytes{,_addr} which (more recently limited to statements > with the same vuse) can walk earlier statements feeding the rhs > of the store and call get_stridx on it. > Unlike most of the other functions where get_stridx is called first on > rhs and only later on lhs, handle_store calls get_stridx on the lhs before > the count_nonzero_bytes* call and does some si->nonzero_bytes comparison > on it. > Now, strinfo structures are refcounted and it is important not to screw > it up. > What happens on the following testcase is that we call get_strinfo on the > destination idx's base (g), which returns a strinfo at that moment > with refcount of 2, one copy referenced in bb 2 final strinfos, one in bb 3 > (the vector of strinfos was unshared from the dominator there because some > other strinfo was added) and finally we process a store in bb 6. > Now, count_nonzero_bytes is called and that sees &g[1] in a PHI and > calls get_stridx on it, which in turn calls get_stridx_plus_constant > because &g + 1 address doesn't have stridx yet. This creates a new > strinfo for it: > si = new_strinfo (ptr, idx, build_int_cst (size_type_node, nonzero_chars), > basesi->full_string_p); > set_strinfo (idx, si); > and the latter call, because it is the first one in bb 6 that needs it, > unshares the stridx_to_strinfo vector (so refcount of the g strinfo becomes > 3). > Now, get_stridx_plus_constant needs to chain the new strinfo of &g[1] in > between the related strinfos, so after the g record. Because the strinfo > is now shared between the current bb and 2 other bbs, it needs to > unshare_strinfo it (creating a new strinfo which can be modified as a copy > of the old one, decrementing refcount of the old shared one and setting > refcount of the new one to 1): > if (strinfo *nextsi = get_strinfo (chainsi->next)) > { > nextsi = unshare_strinfo (nextsi); > si->next = nextsi->idx; > nextsi->prev = idx; > } > chainsi = unshare_strinfo (chainsi); > if (chainsi->first == 0) > chainsi->first = chainsi->idx; > chainsi->next = idx; > Now, the bug is that the caller of this a couple of frames above, > handle_store, holds on a pointer to this g strinfo (but doesn't know > about the unsharing, so the pointer is to the old strinfo with refcount > of 2), and later needs to update it, so it > si = unshare_strinfo (si); > and modifies some fields in it. > This creates a new strinfo (with refcount of 1 which is stored into > the vector of the current bb) based on the old strinfo for g and > decrements refcount of the old one to 1. So, now we are in inconsistent > state, because the old strinfo for g is referenced in bb 2 and bb 3 > vectors, but has just refcount of 1, and then have one strinfo (the one > created by unshare_strinfo (chainsi) in get_stridx_plus_constant) which > has refcount of 1 but isn't referenced from anywhere anymore. > Later on when we free one of the bb 2 or bb 3 vectors (forgot which) > that decrements refcount from 1 to 0 and poisons the strinfo/returns it to > the pool, but then maybe_invalidate when looking at the other bb's pointer > to it ICEs. > > The following patch fixes it by calling get_strinfo again, it is guaranteed > to return non-NULL, but could be an unshared copy instead of the originally > fetched shared one. > > I believe we only need to do this refetching for the case where get_strinfo > is called on the lhs before get_stridx is called on other operands, because > we should be always modifying (apart from the chaining changes) the strinfo > for the destination of the statements, not other strinfos just consumed in > there. > > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? OK > 2024-01-30 Jakub Jelinek > > PR tree-optimization/113603 > * tree-ssa-strlen.cc (strlen_pass::handle_store): After > count_nonzero_bytes call refetch si using get_strinfo in case it > has been unshared in the meantime. > > * gcc.c-torture/compile/pr113603.c: New test. > > --- gcc/tree-ssa-strlen.cc.jj 2024-01-29 10:20:25.000000000 +0100 > +++ gcc/tree-ssa-strlen.cc 2024-01-29 15:50:17.056461933 +0100 > @@ -5044,6 +5044,9 @@ strlen_pass::handle_store (bool *zero_wr > > if (si != NULL) > { > + /* The count_nonzero_bytes call above might have unshared si. > + Fetch it again from the vector. */ > + si = get_strinfo (idx); > /* The corresponding element is set to 1 if the first and last > element, respectively, of the sequence of characters being > written over the string described by SI ends before > --- gcc/testsuite/gcc.c-torture/compile/pr113603.c.jj 2024-01-29 16:09:54.335227319 +0100 > +++ gcc/testsuite/gcc.c-torture/compile/pr113603.c 2024-01-29 16:09:36.010481829 +0100 > @@ -0,0 +1,40 @@ > +/* PR tree-optimization/113603 */ > + > +int a, e; > +signed char b; > +int *c; > +signed char *d; > +short f; > +signed char g[3]; > + > +int * > +foo (void) > +{ > + for (int i = 0; i < 3; i++) > + g[i] = 2; > + int j[100][100] = { {}, {4} }; > + signed char *k = &g[1]; > + do > + { > + for (;;) > + { > + if (c) > + break; > + return &a; > + } > + for (f = 0;; f++) > + { > + for (b = 0; b < 2; b++) > + *c = j[b][f]; > + if (e) > + d = k; > + *k = *d; > + if (*c) > + break; > + if (f) > + break; > + } > + } > + while (f); > + return 0; > +} > > Jakub > > -- Richard Biener SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg, Germany; GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)