From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) by sourceware.org (Postfix) with ESMTPS id B94063858CDA for ; Thu, 30 Mar 2023 06:42:19 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B94063858CDA Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-lf1-x12c.google.com with SMTP id j11so23179980lfg.13 for ; Wed, 29 Mar 2023 23:42:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1680158538; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=ygH7mts7wgOiCSC5ahK9ZMR3fvUVdJnGu+2rN/x6Gew=; b=Gmay8umgE+eEjKnaV883FYQuzm9dEIqIhNTXdlyySSyg3f/HLEeEjhkn1mmfwfZl57 0eBi1vO17b1sBsfc0TsmS5HvBJHtQip6N4YmkZHfgQQbGn+0OFtf2PjGwetW7AGPV5xg dOUeYk4EVB9z65syP0mqr4Q0TawMrYTESv/YtSCkc3azSn0q4U5MPNBCEzn34HJUL5EU YlXu9zllXUKXFTSq19fcAwS6uiw5k4Do9RNM15+gY8hsmeX6GkrCWGyiPybr9182lWHL CYS3SGCH3widXAXdjz8sVzYxkNxlFE1yB2CZUN27fzKJ31CQ15B5vj6TtRp/kLl54AM6 g0Xw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680158538; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=ygH7mts7wgOiCSC5ahK9ZMR3fvUVdJnGu+2rN/x6Gew=; b=bB+A6vCQvCrZu9o//PFsIAZ6jXtlbIZrtcSvwg7VhNsp/JaAfC2FCG4dWevsw9yRhx fzaDXo3H2YDWq4TWwj5+FvBCXcyavGTRx1GtcuKyIVqionnjvzNguV6turzb17l5gWR7 V3Rcz/oiWUNgsNa7UbjvbcSzDMJS8C7GkDVxYGPi/6K9sat4ea/f6AY8nTlmvlu4XYPE e10OWMWullBT0+F4Ep7xEfrEXErrGAQNnryyGd5zlw7DyVC6BG4O85qPWRhGilDOPeYn Cd7GMYEv98LXNe9aLs+ITGeT7WhXBmbJi4Q8TIjnKChPr5BBvZvc+h8PC0C1dtPx0uJx oyNQ== X-Gm-Message-State: AAQBX9fJmT43dtUWZib/bodmDDebW4c0gn83/1qxwG8CfSLse9oqo+nr +ennI49Wrbp9wOjVOD30/9ih6jFO8OgBGlY8KEw= X-Google-Smtp-Source: AKy350Y/EYX5Ziz/RyO5yoJkeSpeC8dhYUNetKqDRLW55qZiKJn5uekcS4bbPaJZQyPaJDJDRmrweYYcpAFIKseWrPc= X-Received: by 2002:ac2:5dd7:0:b0:4e8:44ee:e2d with SMTP id x23-20020ac25dd7000000b004e844ee0e2dmr6682404lfq.5.1680158538043; Wed, 29 Mar 2023 23:42:18 -0700 (PDT) MIME-Version: 1.0 References: <54bb3bc9-e0c1-b5ab-4447-5908b09fd19f@redhat.com> In-Reply-To: <54bb3bc9-e0c1-b5ab-4447-5908b09fd19f@redhat.com> From: Richard Biener Date: Thu, 30 Mar 2023 08:42:05 +0200 Message-ID: Subject: Re: recomputation and PR 109154 To: Andrew MacLeod Cc: gcc-patches , Jakub Jelinek , "hernandez, aldy" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,KAM_NUMSUBJECT,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=no 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 Wed, Mar 29, 2023 at 7:22=E2=80=AFPM Andrew MacLeod wrote: > > The patch, or a slight variation (attached), in the PR allows us to > generate better ranges be recomputing longer instruction sequences on > outgoing edges. > > This in fact also fixes > XPASS: gcc.dg/Walloca-13.c (test for bogus messages, line 11) > > [local count: 1073741824]: > _1 =3D p_5(D) - q_6(D); > _2 =3D _1 /[ex] 4; > n_7 =3D (long unsigned int) _2; > _11 =3D (long unsigned int) _1; > if (_11 <=3D 396) > goto ; [33.00%] > else > goto ; [67.00%] > > [local count: 354334800]: > _3 =3D __builtin_alloca (n_7); > > Where _2 was recomputed before, but n_7 was not. Now it is, and we > correctly do not issue the warning any more. awesome., > > however, as seems to be the case often, better ranges result in, I now ge= t: > > FAIL: 23_containers/vector/bool/allocator/copy.cc (test for excess errors= ) > > because we now generate: > > /opt/notnfs/amacleod/master/build/x86_64-pc-linux-gnu/libstdc++-v3/includ= e/bits/stl_algobase.h:437: > warning: =E2=80=98void* __builtin_memmove(void*, const void*, long unsign= ed > int)=E2=80=99 writing between 9 and 9223372036854775807 bytes into a regi= on of > size 8 overflows the destination [-Wstringop-overflow=3D] > > I see: > > .... > _216 =3D operator new (8); > > _216 : [irange] long unsigned int * [1, +INF] > ...... > > [local count: 86938296]: > D.245552 =3D{v} {CLOBBER(eol)}; > _74 =3D v1.D.217578._M_impl.D.217043._M_start.D.58619._M_p; > _638 =3D (long int) _74; > _261 =3D -_638; > _383 =3D (long unsigned int) _261; > if (_638 < -8) > goto ; [90.00%] > else > goto ; [10.00%] > > _261 : [irange] long int [-9223372036854775807, +INF] > _383 : [irange] long unsigned int [0, > 9223372036854775807][9223372036854775809, +INF] > 8->12 (T) _74 : [irange] _Bit_type * [1, +INF] > 8->12 (T) _261 : [irange] long int [9, +INF] NONZERO > 0x7fffffffffffffff > 8->12 (T) _383 : [irange] long unsigned int [9, > 9223372036854775807] NONZERO 0x7fffffffffffffff > 8->12 (T) _638 : [irange] long int [-INF, -9] > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D BB 12 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D > _74 [irange] _Bit_type * [9223372036854775808, 18446744073709551607] > _383 [irange] long unsigned int [9, 9223372036854775807] NONZERO > 0x7fffffffffffffff > [local count: 78244465]: > __builtin_memmove (_216, _74, _383); > > > > The change is that we now recompute _383 which we didnt before. so we > are seeing memmove being called on what is effectively: > memmove (operator new (8), _74, [9, 9223372036854775807]) > And thus the warning. > > IS this one of the warnings that has been causing issues? and now Im > triggering it again? Yeah, we see these kind of diagnostics on code that's supposed to be not reachable but we don't figure that out (missed-optimization) or the code is written in a way that doesn't make this obvious. > > Back at fixup_cfg3 time, it looks like: > > _261 =3D __last$D58797$_M_p_245 - _247; > _262 =3D _261 > 8; > _263 =3D (long int) _262; > _264 =3D __builtin_expect (_263, 1); > if (_264 !=3D 0) > goto ; [90.00%] > else > goto ; [10.00%] > .................. > [local count: 78244465]: > _265 =3D (long unsigned int) _261; > __builtin_memmove (_246, _247, _265); > > So the builtin expect certainly implies it is expecting to have a value >= 8 > > Early on the code looks like: > _1 =3D __last_10(D) - __first_11(D); > _Num_12 =3D _1 /[ex] 8; > _2 =3D _Num_12 > 1; > _3 =3D (long int) _2; > _4 =3D __builtin_expect (_3, 1); > if (_4 !=3D 0) > goto ; [INV] > else > goto ; [INV] > > : > _Num.28_5 =3D (long unsigned int) _Num_12; > _6 =3D _Num.28_5 * 8; > __builtin_memmove (__result_14(D), __first_11(D), _6); > > > SO it does still do basically the same thing. > > Im not sure whether this is pointing out something real or another false > positive... > > Andrew