From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) by sourceware.org (Postfix) with ESMTPS id 233C4385C316 for ; Fri, 1 Jul 2022 15:32:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 233C4385C316 Received: by mail-io1-xd2c.google.com with SMTP id m13so2663865ioj.0 for ; Fri, 01 Jul 2022 08:32:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=zoMuG5cMdUjBRelzSdMcPDpoHLBoKxNqgs6Wn0R8sV4=; b=ySUn6ZhNgq4tw5XC+a6uY9mW9yThgng1APLXqxOgcjUK1CIWwHClfqBt9dRYUzD5M2 U54FmvpsxYcErZ3zDNwKgJq1OX7druNTAzEpNPAJcJb1HW38TRvE5OLpLKtqzVg7f+FO jz74C8OIE+7TkPhEgfts594viI1zk1ev+ppPLsjQIz2VoX2cLgR55NpYvUIvoRnBMs5y /omF5Xu9CwcAGABnV9l/zT9UWDDCp7lRvgoo0IHK6BH7JCw5M9kFkUR1yKjgnh5dxqZH BGTUkxuOsjRmjM2trjM/+e/aHco4XF7dNPVhVzcnkEmEQdkSqYoCMAYBqMXyh9KOJJLg 7VIA== X-Gm-Message-State: AJIora8RLyQPRolNaJHq1GYYREvaw2BvkIlesTWaDGw4c4d1e4KT6oIE VzPfuDBDsDxALUUM9tyifbY= X-Google-Smtp-Source: AGRyM1tEJYRdrp9hKXkfOD0AexAYdBrE7yIew6qoWjHubah1O0muHW0BpxU7MlvWD7JehKx98/s5nA== X-Received: by 2002:a05:6638:430d:b0:33c:d3e2:ab04 with SMTP id bt13-20020a056638430d00b0033cd3e2ab04mr7787209jab.319.1656689541325; Fri, 01 Jul 2022 08:32:21 -0700 (PDT) Received: from [192.168.0.41] (184-96-231-56.hlrn.qwest.net. [184.96.231.56]) by smtp.gmail.com with ESMTPSA id j12-20020a6b794c000000b0067275a52928sm10392756iop.9.2022.07.01.08.32.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 01 Jul 2022 08:32:20 -0700 (PDT) Message-ID: <8ef7b17b-5a12-b718-7b04-f8ae7e0611bb@gmail.com> Date: Fri, 1 Jul 2022 09:32:19 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 Subject: Re: [GCC 13][PATCH] PR101836: Add a new option -fstrict-flex-array[=n] and use it in __builtin_object_size Content-Language: en-US To: Qing Zhao , Jakub Jelinek , Richard Biener Cc: gcc-patches Paul A Clarke via , kees Cook References: <6CB6B076-0635-4DE8-861E-F8EBC0B696B4@gmail.com> <7306B3D0-01A8-47F8-8BE2-F5E312FC94D1@oracle.com> From: Martin Sebor In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, NICE_REPLY_A, RCVD_IN_BARRACUDACENTRAL, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2022 15:32:25 -0000 On 7/1/22 08:01, Qing Zhao wrote: > > >> On Jul 1, 2022, at 8:59 AM, Jakub Jelinek wrote: >> >> On Fri, Jul 01, 2022 at 12:55:08PM +0000, Qing Zhao wrote: >>> If so, comparing to the current implemenation to have all the checking in middle-end, what’s the >>> major benefit of moving part of the checking into FE, and leaving the other part in middle-end? >> >> The point is recording early what FIELD_DECLs could be vs. can't possibly be >> treated like flexible array members and just use that flag in the decisions >> in the current routines in addition to what it is doing. > > Okay. > > Based on the discussion so far, I will do the following: > > 1. Add a new flag “DECL_NOT_FLEXARRAY” to FIELD_DECL; > 2. In C/C++ FE, set the new flag “DECL_NOT_FLEXARRAY” for a FIELD_DECL based on [0], [1], > [] and the option -fstrict-flex-array, and whether it’s the last field of the DECL_CONTEXT. > 3. In Middle end, Add a new utility routine is_flexible_array_member_p, which bases on > DECL_NOT_FLEXARRAY + array_at_struct_end_p to decide whether the array > reference is a real flexible array member reference. > > > Middle end currently is quite mess, array_at_struct_end_p, component_ref_size, and all the phases that > use these routines need to be updated, + new testing cases for each of the phases. > > > So, I still plan to separate the patch set into 2 parts: > > Part A: the above 1 + 2 + 3, and use these new utilities in tree-object-size.cc to resolve PR101836 first. > Then kernel can use __FORTIFY_SOURCE correctly; > > Part B: update all other phases with the new utilities + new testing cases + resolving regressions. > > Let me know if you have any comment and suggestion. It might be worth considering whether it should be possible to control the "flexible array" property separately for each trailing array member via either a #pragma or an attribute in headers that can't change the struct layout but that need to be usable in programs compiled with stricter -fstrict-flex-array=N settings. Martin > > Thanks a lot for all your help. > > Qing > >> >> Jakub >> >