From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) by sourceware.org (Postfix) with ESMTPS id 853893858D28 for ; Mon, 24 Apr 2023 08:31:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 853893858D28 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-lj1-x22a.google.com with SMTP id 38308e7fff4ca-2a8bae45579so36729851fa.0 for ; Mon, 24 Apr 2023 01:31:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1682325086; x=1684917086; 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=Zn++CVtV33Ywi+Vb0hmveJLo4prFoKMoUBsoJPWqIRo=; b=iZoYK79mhsOkxuA5Qe8jCBdrVZ/5AQy9J9WkSonSf9qrlbokpTYHT9ofsLcR6qdh8V AWyeA5h41Bhb/T3Eua0E3aLARf1YOEWwZ3bQJLQZFGw2OTceXLMlw5aUPWUw0OrpKPGk KH6YDYW3m+gbu0DZamBTQXs9OBNRE7ZGjGGhQB3yJrKubzSB3rqgOoaLV4zwq3LdVOVq qdx2vM2ZEw0c9oLmnxmEZ77MJZIHlBIW3VOpMpuU7AxbveuFBONHSME2mZLY4Q0fIySI pzh7GvCydYtLG1NbGT2bdbj2oQ9IBNjfxSU9Snf01gmN3EzkALhKatx3XfkeXPQi0heN 30pA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682325086; x=1684917086; 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=Zn++CVtV33Ywi+Vb0hmveJLo4prFoKMoUBsoJPWqIRo=; b=SKb9CE2R1YwVYsbflVK0pRL0cpQFj1oHf1trf452oMhtR3cGTgFmpMVeNGDJX82wDi nbWK2T1VVD1jSHy3q+7AJVVlps5rGu2Y7QPjLPOcz4PfEksnUz3V6jnMikXOgS8uRFZN YZ7u2wep6N6iMKfPxoW31FnDHGdSNEoIqCc8GcxTqybemAJZ+SHfc8OFiZDAHfJO4Ujg tQGVgq8xZ8H8vbEkIiigZsJS+BoUOqQIm1DBwriv5u0wxmx4SwTyxVwl5yLEpRuunKhG SzBgdQbc4loYlHBAgRzL22GbWQJYKopBJSOouqOsVrRbg/PO7yh8ZaBNsI1z+hU8GuyV EU/A== X-Gm-Message-State: AAQBX9fiRKJeVbuDXuuLyrXwRLbHcnkb+mQmesMYiicsHCGoPt84Mu6A khFWurNtxsk852pduUy8pwGOOJzS33NVu2h9aVg= X-Google-Smtp-Source: AKy350apvc483OuT3SfrOtNdGc1Jvfl/AAzh/jhXBgwH4Oay+6xKiLTQh94zFx9tlrQ0IOMhrftVNGaKS1lFQom9chI= X-Received: by 2002:a2e:83c5:0:b0:2a7:9cd3:3cc4 with SMTP id s5-20020a2e83c5000000b002a79cd33cc4mr2550619ljh.15.1682325085705; Mon, 24 Apr 2023 01:31:25 -0700 (PDT) MIME-Version: 1.0 References: <20230424074332.141890-1-aldyh@redhat.com> In-Reply-To: <20230424074332.141890-1-aldyh@redhat.com> From: Richard Biener Date: Mon, 24 Apr 2023 10:30:00 +0200 Message-ID: Subject: Re: [PATCH] Pass correct type to irange::contains_p() in ipa-cp.cc. To: Aldy Hernandez Cc: GCC patches , Andrew MacLeod Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-7.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,GIT_PATCH_0,RCVD_IN_DNSWL_NONE,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 Mon, Apr 24, 2023 at 9:44=E2=80=AFAM Aldy Hernandez via Gcc-patches wrote: > > There is a call to contains_p() in ipa-cp.cc which passes incompatible > types. This currently works because deep in the call chain, the legacy > code uses tree_int_cst_lt which performs the operation with > widest_int. With the upcoming removal of legacy, contains_p() will be > stricter. > > OK pending tests? > > gcc/ChangeLog: > > * ipa-cp.cc (ipa_range_contains_p): New. > (decide_whether_version_node): Use it. > --- > gcc/ipa-cp.cc | 16 +++++++++++++++- > 1 file changed, 15 insertions(+), 1 deletion(-) > > diff --git a/gcc/ipa-cp.cc b/gcc/ipa-cp.cc > index b3e0f62e400..c8013563796 100644 > --- a/gcc/ipa-cp.cc > +++ b/gcc/ipa-cp.cc > @@ -6180,6 +6180,19 @@ decide_about_value (struct cgraph_node *node, int = index, HOST_WIDE_INT offset, > return true; > } > > +/* Like irange::contains_p(), but convert VAL to the range of R if > + necessary. */ > + > +static inline bool > +ipa_range_contains_p (const irange &r, tree val) > +{ > + if (r.undefined_p ()) > + return false; > + > + val =3D fold_convert (r.type (), val); I think that's wrong, it might truncate 'val'. I think we'd want if (r.undefined_p () || !int_fits_type_p (val, r.type ())) return false; but then I wonder whether contains_p should have an overload with widest_int or handle "out of bounds" values itself more gracefully? Thanks, Richard. > + return r.contains_p (val); > +} > + > /* Decide whether and what specialized clones of NODE should be created.= */ > > static bool > @@ -6221,7 +6234,8 @@ decide_whether_version_node (struct cgraph_node *no= de) > supports this only for integers now. */ > if (TREE_CODE (val->value) =3D=3D INTEGER_CST > && !plats->m_value_range.bottom_p () > - && !plats->m_value_range.m_vr.contains_p (val->value)) > + && !ipa_range_contains_p (plats->m_value_range.m_vr, > + val->value)) > { > /* This can happen also if a constant present in the so= urce > code falls outside of the range of parameter's type,= so we > -- > 2.40.0 >