From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com [IPv6:2607:f8b0:4864:20::636]) by sourceware.org (Postfix) with ESMTPS id A6E1B385829C for ; Tue, 16 Aug 2022 12:16:40 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org A6E1B385829C Received: by mail-pl1-x636.google.com with SMTP id d16so9013822pll.11 for ; Tue, 16 Aug 2022 05:16:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:x-gm-message-state:from:to:cc; bh=j0nxdHXAaCwhNsM6qfUgDlyci0jI0Kn1mSp6rPsbFhs=; b=sJMY3R5wfD0yJPorQkIwCTk00hH0082Qlb2DoAkLS00zDMasu4Tqr8PNGmuPE/H3Mp kCvpQ2VzKv65qQ6h9rtIV0Nq6Sx16T039jzJ9Rb8ikv8pZbBCpCRs1U/EGF3BVPOMh5+ qKuLO5jQM73IzoTxI7q//fZd57z25xumbtlyp5+m8TLcXA+jsuYmEVrm5gyRwxAjptlj somN5NvSoMQ2T8iTUPctspbnUf/eLCGaGkEnoo4nkVl3Z+yy7UQ4bASRrHPshdGvA55o 9m6+k/eObxMjxz2to1ZulgSRDp0LWsYYU5QHjVC2p1xd2h+KvTJTdN8kK18chwO18px+ yJUQ== X-Gm-Message-State: ACgBeo3DePc4bBjUOriBkP0UmVJiNvopBDHmbe4IDY0Cv3ly4L78Qalh Q/4qhsdr/gHq1Kh6eGm0QgY= X-Google-Smtp-Source: AA6agR6hbphQL/6rJbLHwATVZlTUsNuQI+y0tdfUQCMnKufErufpsnx7FoajCk9VGGk4M+Hc9TpdJQ== X-Received: by 2002:a17:90b:2687:b0:1f3:1535:eda5 with SMTP id pl7-20020a17090b268700b001f31535eda5mr33755929pjb.39.1660652199501; Tue, 16 Aug 2022 05:16:39 -0700 (PDT) Received: from ?IPV6:2620:10d:c085:21cf::116f? ([2620:10d:c090:400::5:d498]) by smtp.googlemail.com with ESMTPSA id r13-20020a65498d000000b0041bb35b9e80sm7577022pgs.53.2022.08.16.05.16.37 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 16 Aug 2022 05:16:38 -0700 (PDT) Sender: Nathan Sidwell Message-ID: <45d914e0-962b-8b06-96a0-9e448302cc06@acm.org> Date: Tue, 16 Aug 2022 08:16:35 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.12.0 Subject: Re: Where in C++ module streaming to handle a new bitfield added in "tree_decl_common" Content-Language: en-US To: Richard Biener Cc: Qing Zhao , GCC Patches References: <2FC986DA-9B67-476D-9593-49F1B2BFA2A9@oracle.com> <65809051-2ecf-1f42-ec90-5d5b72935642@acm.org> From: Nathan Sidwell In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3038.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_EF, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, GIT_PATCH_0, HEADER_FROM_DIFFERENT_DOMAINS, NICE_REPLY_A, 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 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: Tue, 16 Aug 2022 12:16:44 -0000 On 8/15/22 10:03, Richard Biener wrote: > On Mon, Aug 15, 2022 at 3:29 PM Nathan Sidwell via Gcc-patches > wrote: >> >> On 8/2/22 10:44, Qing Zhao wrote: >>> Hi, Nathan, >>> >>> I am adding a new bitfield “decl_not_flexarray” in “tree_decl_common” (gcc/tree-core.h) for the new gcc feature -fstrict-flex-arrays. >>> >>> ==== >>> diff --git a/gcc/tree-core.h b/gcc/tree-core.h >>> index ea9f281f1cc..458c6e6ceea 100644 >>> --- a/gcc/tree-core.h >>> +++ b/gcc/tree-core.h >>> @@ -1813,7 +1813,10 @@ struct GTY(()) tree_decl_common { >>> TYPE_WARN_IF_NOT_ALIGN. */ >>> unsigned int warn_if_not_align : 6; >>> >>> - /* 14 bits unused. */ >>> + /* In FIELD_DECL, this is DECL_NOT_FLEXARRAY. */ >>> + unsigned int decl_not_flexarray : 1; >> >> Is it possible to invert the meaning here -- set the flag if it /IS/ a >> flexible array? negated flags can be confusing, and I see your patch >> sets it to '!is_flexible_array (...)' anyway? > > The issue is it's consumed by the middle-end but set by a single (or two) > frontends and the conservative setting is having the bit not set. That works > nicely together with touching just the frontends that want stricter behavior > than currently ... Makes sense, but is the comment incomplete? I'm guessing this flag is for FIELD_DECLs /of array type/, and not just any old FIELD_DECL? After all a field of type int is not a flexible array, but presumably doesn't need this flag setting? nathan -- Nathan Sidwell