From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com [IPv6:2a00:1450:4864:20::630]) by sourceware.org (Postfix) with ESMTPS id CAC603858C2D for ; Fri, 9 Sep 2022 07:26:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org CAC603858C2D 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-ej1-x630.google.com with SMTP id gh9so1959758ejc.8 for ; Fri, 09 Sep 2022 00:26:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date; bh=Fd5u5mFG4qRD7rgUjEGW7ACIgwrkwuiAYZLLMerNnaQ=; b=VA4ngEHwWLPm7AefO08mhd9maukCa6ZceT8DclOmePWADF9wh+x0z7kFgTaHjO2+pP s3mL8krePqICaKkCWdu2EBnhVZUiPhospKclwTMeT1akT5cdFIqzCnEcPa7dibaDHUYM /MP31hJRsOjWH2AZEkivfpUcJhqUeDLGJvOegmKVUIUfHYqk9EgWYAeVOt1Gs83PKfSz JANT+98K760cG8xeyWF3a+pPrxvFEeGtNZTdzArCzNLTPKv4Au6/UbdLMc3OMevMrdcX t5dXI99oxNcxy1M28qJFPpQcGzNwx0z+m+DW9fbFo1vDBC3mx/8Gm4l1Wrp65Vm3Mqrn 6BiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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; bh=Fd5u5mFG4qRD7rgUjEGW7ACIgwrkwuiAYZLLMerNnaQ=; b=HEuJgiWpCd0mqNQR03ntx+UDKHUSTzxrEeRk897R2DdyVaTfI8cJx8rsQNifnTgSxc 8h+VtrT7/rlst3Nt72SHA0D9I1S/KEmY/14/jDpWkJcQ4MpRy2Y145S7myDPpeJi9NJ0 SRUMjf2grV1iI5iB0wG1grzrexzA+FnqFMkFDTuPwLL/e7u6H5kyR1FmF4RYve9KT197 MGlByi99N086BHs84P5/IJMW/fRWyAM8AUQPH4okFay+JIRjmTKe6/je44Yi7MQJd2e2 NvBu1mRqR3Exf99duzSUdiep/AtKN4ZhW3ltkTPb0GH7K6QcdIKusldFpMk56WtXpvd5 7Vjg== X-Gm-Message-State: ACgBeo3DrnzdIHcn3LWq0hvn9noBWXZcbEtmCm1Fa6ObSG4wxdYCaSmQ yEXgflrgXpVpocXBKSynL5BKS40yQaozOt5Rb24= X-Google-Smtp-Source: AA6agR7hLgTMAvMjC5pCbk2D99p2yf0bcIR7lx/qV2wTnKlypwt9s916B27CRwE7hD2J+QX18H8Xz7cUe3fTFoOuJAs= X-Received: by 2002:a17:906:8a6c:b0:772:fe67:f5ea with SMTP id hy12-20020a1709068a6c00b00772fe67f5eamr5912558ejc.488.1662708364293; Fri, 09 Sep 2022 00:26:04 -0700 (PDT) MIME-Version: 1.0 References: <302a193a-2751-a404-31c6-f5b4a3e6856a@linux.ibm.com> In-Reply-To: <302a193a-2751-a404-31c6-f5b4a3e6856a@linux.ibm.com> From: Richard Biener Date: Fri, 9 Sep 2022 09:25:52 +0200 Message-ID: Subject: Re: [PATCH v2] Handle OPAQUE_TYPE specially in verify_type [PR106833] To: "Kewen.Lin" Cc: GCC Patches , Segher Boessenkool , Peter Bergner Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,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 Fri, Sep 9, 2022 at 8:51 AM Kewen.Lin wrote: > > Hi Richi, > > Thanks for the review comments! > > on 2022/9/8 15:36, Richard Biener wrote: > > > > > >> Am 08.09.2022 um 07:53 schrieb Kewen.Lin : > >> > >> =EF=BB=BFHi, > >> > >> As PR106833 shows, cv-qualified opaque type can cause ICE > >> during LTO. It exposes that we missd to handle OPAQUE_TYPE > >> well in type verification. As Richi pointed out, also > >> assuming that target will always define TYPE_MAIN_VARIANT > >> and TYPE_CANONICAL for opaque type, this patch is to check > >> both are OPAQUE_TYPE_P. Besides, it also checks the only > >> available size and alignment information as well as type > >> mode for TYPE_MAIN_VARIANT. > >> > ... > >> + > >> + if (t !=3D tv) > >> + { > >> + verify_match (TREE_CODE, t, tv); > >> + verify_match (TYPE_MODE, t, tv); > >> + verify_match (TYPE_SIZE, t, tv); > > > > TYPE_SIZE is a tree, you should probably > > Compare this with operand_equal_p. It=E2=80=99s > > Not documented to be a constant size? > > Thus some VLA vector mode might be allowed ( a poly_int size), > > Thanks for catching, I was referencing the code in function > verify_type_variant, that corresponding part seems imperfect: > > if (TREE_CODE (TYPE_SIZE (t)) !=3D PLACEHOLDER_EXPR > && TREE_CODE (TYPE_SIZE (tv)) !=3D PLACEHOLDER_EXPR) > verify_variant_match (TYPE_SIZE); > > I agree poly_int size is allowed, the patch was updated for it. > > BLKmode > > Is ruled out(?), > > Yes, it requires a mode of MODE_OPAQUE class. > > the docs say we have > > =E2=80=9AAn MODE_Opaque=E2=80=98 here but I don=E2=80=99t see > > This being verified? > > > > There is a MODE equality check, I assumed the given t already > has one MODE_OPAQUE mode, but the patch was updated to make > it explicit as you concerned. > > > The macro makes this a bit unworldly > > For the only benefit of elaborate diagnostic > > Which I think isn=E2=80=99t really necessary > > OK, fixed! > > The previous version makes just one check on TYPE_CANONICAL to > be cheap as gimple_canonical_types_compatible_p said, but > since there are just several fields to be check, this updated > version adjusted it to be the same as what's for TYPE_MAIN_VARIANT. > Hope it's fine. :) I think we'll call verify_type on the main variant as well so that would be redundant (ensured by transitivity), can you check? > Tested as before. > > Does this updated patch look good to you? Yes, please remove the checks against the main variant if the above holds, OK with or without that change depending on this outcome. Thanks, Richard. > > BR, > Kewen > ------