From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x102b.google.com (mail-pj1-x102b.google.com [IPv6:2607:f8b0:4864:20::102b]) by sourceware.org (Postfix) with ESMTPS id ADBF63858D33 for ; Mon, 28 Aug 2023 15:13:23 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org ADBF63858D33 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-pj1-x102b.google.com with SMTP id 98e67ed59e1d1-26d1e5f2c35so2110024a91.2 for ; Mon, 28 Aug 2023 08:13:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1693235603; x=1693840403; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=75ltubBbPr0vLXnAuC231xcFqhOTYGAjxW4YVIp3qL4=; b=bu29opqpBPtRw0IM+RqXjt/Dzl7kewTlBVcPRZEZ6z36dLdd6UtJS/0bp3xFpdsVZh 1zkGIDf/6NA4zegsBDrwdCXBDLvixXqIsGzSZAGcEyoRPiAcQsPeAwq0cB7x64TqASHI HPh98gAolwFry2ID68VvHY2iRXixBc++PPYom8jiDypc527GsUJoWjCsRM4Fo01xhFRU CBqsg6KZcCMAeyaIhiQoLkG1vwkMqokxK+nEQhYY1hGpFO7CHKLwz6X9KEsfe6/rs4D0 ElEIqvuBmX6y/+mEEJNJfHH+Oni2wx7ugTFaC37qXwbv8o8uMitKRDnDxnNSvwvLJty2 b9sg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693235603; x=1693840403; h=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=75ltubBbPr0vLXnAuC231xcFqhOTYGAjxW4YVIp3qL4=; b=edmpdUGLHrUIpZYJqt+xky8/OI30bfSqPlv5cO1vL9A5QZOVdjZjhyN1Hd9xVo/7p1 SEr0y19FnJvTNwvkt85Py0FCpLt6Ccv/E+vN4OtcGJprztGRD5BUFdh7xGyDTzrI0aZa 5dSyhZyXBUCQ+/BmCGUyh/R86h4HSmVRn82KD0XUoBH9f+BIZm4b+QTujK/uRGsEt8Vt +V1N2nUQiDCE6pxqEp4EZ9Xv70+k3fuDihOKTszleFShmjRjdnhfU4E2/Nl3kM2wMDYs 0yynQjE2A1qED1O0v3X9BloLu2r7ioYAkCirEAcLApUBEpWHIm74lG14MyCpryOleIz3 WXJQ== X-Gm-Message-State: AOJu0YzaS2/UzXt6xGvgTgJwOiFX5/JQQ9SyjoiEhQSZipm95ecuSZE2 n2bHMqmmVn+rtUTEp3A7iQBE5nQDpUZoDwLQ0Q== X-Google-Smtp-Source: AGHT+IEuHjBps5yjXazFiLYIvJOZsejw20hePO2MbkMmS2LWfm4NLst8lqkFFNwWOFIThZG/2BJ9BBu4/g+ILhcR9zQ= X-Received: by 2002:a17:90b:909:b0:262:e6d2:2d6 with SMTP id bo9-20020a17090b090900b00262e6d202d6mr24641020pjb.47.1693235602579; Mon, 28 Aug 2023 08:13:22 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Benjamin Priour Date: Mon, 28 Aug 2023 17:13:11 +0200 Message-ID: Subject: Re: analyzer: Weekly update on extending C++ support (3) To: David Malcolm Cc: gcc@gcc.gnu.org Content-Type: multipart/alternative; boundary="0000000000009ce7d00603fd222d" X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP 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: --0000000000009ce7d00603fd222d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Test gcc.dg/analyzer/pr94362-1.c actually has an additional null_deref > warning in C++, which is not affected by exceptions > or optimizations. I will keep updated on that one. Note that no warnings > are emitted for this test in C. > > analyzer/pr94362-1.c: In function =E2=80=98const EVP_PKEY_ASN1_METHOD* > EVP_PKEY_asn1_find_str(ENGINE**, const char*, int)=E2=80=99: > analyzer/pr94362-1.c:55:16: warning: dereference of NULL =E2=80=98ameth= =E2=80=99 [CWE-476] > [-Wanalyzer-null-dereference] > analyzer/pr94362-1.c:39:29: note: (1) entry to =E2=80=98EVP_PKEY_asn1_fin= d_str=E2=80=99 > analyzer/pr94362-1.c:42:31: note: (2) =E2=80=98ameth=E2=80=99 is NULL > analyzer/pr94362-1.c:53:43: note: (3) following =E2=80=98true=E2=80=99 br= anch... > analyzer/pr94362-1.c:54:31: note: (4) ...to here > analyzer/pr94362-1.c:54:31: note: (5) calling =E2=80=98EVP_PKEY_asn1_get0= =E2=80=99 from > =E2=80=98EVP_PKEY_asn1_find_str=E2=80=99 > analyzer/pr94362-1.c:29:29: note: (6) entry to =E2=80=98EVP_PKEY_asn1_get= 0=E2=80=99 > analyzer/pr94362-1.c:32:53: note: (7) =E2=80=980=E2=80=99 is NULL > analyzer/pr94362-1.c:54:31: note: (8) returning to > =E2=80=98EVP_PKEY_asn1_find_str=E2=80=99 from =E2=80=98EVP_PKEY_asn1_get0= =E2=80=99 > analyzer/pr94362-1.c:54:31: note: (9) =E2=80=98ameth=E2=80=99 is NULL > analyzer/pr94362-1.c:55:16: note: (10) dereference of NULL =E2=80=98ameth= =E2=80=99 > > > Cheers, > Benjamin. > > As promised a quick update on that front. I've managed to pinpoint the difference between the C and C++. Compiling with -fno-exceptions -O0 the two IPA's seen by the analyzer are nearly identical, if not for one difference. const EVP_PKEY_ASN1_METHOD *EVP_PKEY_asn1_find_str(ENGINE **pe, const char *str, int len) { int i; const EVP_PKEY_ASN1_METHOD *ameth =3D (const EVP_PKEY_ASN1_METHOD *) ((vo= id *)0); ... for (i =3D EVP_PKEY_asn1_get_count(); i-- > 0;) { ameth =3D EVP_PKEY_asn1_get0(i); /* At this point, i >=3D 0 */ if (ameth->pkey_flags & 0x1) continue; return ameth; } ... } IPA when compiled by as C: : i_23 =3D EVP_PKEY_asn1_get_count (); goto ; [INV] : ameth_27 =3D EVP_PKEY_asn1_get0 (i_24); _2 =3D ameth_27->pkey_flags; _3 =3D _2 & 1; if (_3 !=3D 0) goto ; [INV] else goto ; [INV] : // predicted unlikely by continue predictor. goto ; [INV] : _28 =3D ameth_27; goto ; [INV] : # i_5 =3D PHI i.4_4 =3D i_5; i_24 =3D i.4_4 + -1; if (i.4_4 > 0) goto ; [INV] else goto ; [INV] ... and as C++ : i_23 =3D EVP_PKEY_asn1_get_count (); goto ; [INV] : ameth_28 =3D EVP_PKEY_asn1_get0 (i_24); _2 =3D ameth_28->pkey_flags; _3 =3D _2 & 1; if (_3 !=3D 0) goto ; [INV] else goto ; [INV] : // predicted unlikely by continue predictor. goto ; [INV] : _29 =3D ameth_28; goto ; [INV] : # i_5 =3D PHI i.5_4 =3D i_5; i_24 =3D i.5_4 + -1; retval.4_25 =3D i.5_4 > 0; /* Difference here. C++ stores the comparison's result before using it */ if (retval.4_25 !=3D 0) goto ; [INV] else goto ; [INV] This slight difference causes i_24 to not be part of an equivalence class in C++, although it is part of one in C. Therefore when calling ameth_28 =3D EVP_PKEY_asn1_get0 (i_24);, i_24 won't appear as constrained in C++, although we know it to be positive. Info is lost. Further down the line, because of this missing ec constraint_manager::eval_condition will evaluate to UNKNOWN, and the pending diagnostic path won't be refused but accepted as feasible in C++. constraints and equivalence classes in C: ec2: {(CONJURED(_8 =3D sk_EVP_PKEY_ASN1_METHOD_num (app_methos.1_2);, _8)+(int)1)} ec3: {(int)0 =3D=3D [m_constant]'0'} /* int since constraining 'int i_24' */ ec4: {CONJURED(_8 =3D sk_EVP_PKEY_ASN1_METHOD_num (app_methos.1_2);, _8)} /* This is the ec of i_24 */ ec5: {(int)-1 =3D=3D [m_constant]'-1'} constraints: 1: ec5 < ec4 2: ec3 < ec2 ... vs C++'s: ec2: {((CONJURED(_8 =3D sk_EVP_PKEY_ASN1_METHOD_num (app_methos.1_2);, _8)+(int)1)>(int)0)} ec3: {(bool)0 =3D=3D [m_constant]'0'} /* bool instead of int cuz constraini= ng 'bool retval.4_25' */ constraints: 1: ec2 !=3D ec3 As you can see, i_24 equivalence class does not appear in C++. I'm considering if in a condition lhs or rhs is a logical binop svalue, we should unwrap one level, so that the condition's constraint is actually applied on the inner svalue. Cheers, Benjamin. --0000000000009ce7d00603fd222d--