From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 1F3483858C60 for ; Tue, 26 Mar 2024 17:20:56 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 1F3483858C60 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 1F3483858C60 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1711473657; cv=none; b=U4hK3ZMxYUQ1Hk+0EAeON91jzJknGhd4gFNBZAQ4Lze48Zd/GHUXHbDmoQMxmleKvMj+kPfR8RtwQXJwdpKRgAUxr7KU9rmpXfoCt3DFz/Ij6tbwQpG6TVGh+tcnxb+rJeHQE/QTqTXNzeLrzlVjFYS6ObTm6EHx8X6j62+QYWc= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1711473657; c=relaxed/simple; bh=ZEklPp9CyZVniR4CDkKjFLmIET2W9Wk7Gm5CpYxyKyM=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=RNP0Isu2WfddEshtTTndeyw3+L8zoRsnYS4HzAUEKd9SVKtOAWZjVSMfKy3FfrfN9KZoMw8lr6pMkX4MyaRj80Yctcl4dGMaVFDO1arjiuVdY21D19iU6pPMiaBb4fXcyrKX3IBBc1wWf7TnU0FnBbNRie+YxeRpI8eIoqfC2iI= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1711473655; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=SEMB/P/5CNKElrVzwMzJkv+iC6BQHXjuUDK2x1vYVkM=; b=YsupLG92opEFnC9UEoBW9HA/WGj/0yB1MEplrRTn3M7xeRPYbjMOIt7yVpqxOQ31dgCfLY foSykbKjq/40Ufc+VhtfAlxvzujWCRTHiZGAT+Hq/ZgyMgESpNJFRpa8ZYRDLJantcpdRS i3z52m7cCIbRAWC2u278Pt06Z7WPGzM= Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-520-OS59YMUCN7eYPxOGAQplSg-1; Tue, 26 Mar 2024 13:20:54 -0400 X-MC-Unique: OS59YMUCN7eYPxOGAQplSg-1 Received: by mail-wm1-f69.google.com with SMTP id 5b1f17b1804b1-4140bf38378so40861425e9.1 for ; Tue, 26 Mar 2024 10:20:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711473653; x=1712078453; h=mime-version:references:message-id:in-reply-to:subject:cc:to:from :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=vL7Fs9BejwIcdDafcPjyeKD1rJpvYfygLOtIntqemug=; b=rveqWTUuGGh6gNmqz0qISqh4G8f+h+bcHQEuyzDRhkWEnV6E0fAUDfIQy3DLM2Ibc4 0JHqihp72ygY1GE8eLmQACMy48sojeRbKFS8lnGM6jnCbO2aPfAHO+O4xe41ksMqjlVq XGFwODuDS+zFo4w6+J/EZjCtY2vszDfiV0ezwDaHyouMHY2ywWWbZvC4qN0axTBxhTXM f9AiVlffwhVQzNeiCzSpfnB3CZ6DwglBXrjOoMxXI1OubvWNeg9PtnQioP4FXQwOtqfF ZCam1j1sq3zMJu0CSObvXRkPoImA6dGTLf7ABxtiG9rh54Rh7pfjY2oCwUq8LmUsEWRA Ghpw== X-Forwarded-Encrypted: i=1; AJvYcCVqo3tkFauKDyuyhFaRkF/uVnVwOwWkFEBmx1Rpar/dRUH0k0474E6oS9mW/TZhsStWrJFBGgJNU0krPfdUkzw1YF2AcgCGjg== X-Gm-Message-State: AOJu0YzEXaH57Y1LFWtfvqN7WuzZChSYpi9oiHyW4SbuDnasKnuQGzQZ pU1ZozAGDdD7n8KX3vY5D+f0UCyFwS+/e5Yt6NF/Er5xO0vsWBvk3GsQIyIMuAjKeppHfCaE2Ug Lhp1R+BawlPh3Z3pBQnRHi1xXcSOIK7O708GVztc/U/xGwsK5vvn+Flo= X-Received: by 2002:a7b:cc89:0:b0:414:5e91:124f with SMTP id p9-20020a7bcc89000000b004145e91124fmr215967wma.23.1711473653257; Tue, 26 Mar 2024 10:20:53 -0700 (PDT) X-Google-Smtp-Source: AGHT+IEj5ArXfP7MLLcLQzCPtF+ymw8fzqOhx3OQyHW4Z2bALTbFPb3XCG2YLV8Rs/3ugu4n5y0olg== X-Received: by 2002:a7b:cc89:0:b0:414:5e91:124f with SMTP id p9-20020a7bcc89000000b004145e91124fmr215947wma.23.1711473652899; Tue, 26 Mar 2024 10:20:52 -0700 (PDT) Received: from digraph.polyomino.org.uk (digraph.polyomino.org.uk. [2001:8b0:bf73:93f7::51bb:e332]) by smtp.gmail.com with ESMTPSA id v11-20020a05600c470b00b0041488978873sm8228658wmo.44.2024.03.26.10.20.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 26 Mar 2024 10:20:52 -0700 (PDT) Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.95) (envelope-from ) id 1rpATD-000nD2-29; Tue, 26 Mar 2024 17:20:19 +0000 Date: Tue, 26 Mar 2024 17:20:19 +0000 (UTC) From: Joseph Myers To: Qing Zhao cc: "richard.guenther@gmail.com" , Siddhesh Poyarekar , "uecker@tugraz.at" , Kees Cook , "isanbard@gmail.com" , "gcc-patches@gcc.gnu.org" Subject: Re: [PATCH v7 1/5] Provide counted_by attribute to flexible array member field (PR108896) In-Reply-To: <932CCEBB-8107-4347-B94B-8F96E9CD8938@oracle.com> Message-ID: <988fa8f9-8bc6-cd26-3c69-7fc26d86c43a@redhat.com> References: <20240320131518.2292317-1-qing.zhao@oracle.com> <20240320131518.2292317-2-qing.zhao@oracle.com> <932CCEBB-8107-4347-B94B-8F96E9CD8938@oracle.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: multipart/mixed; boundary="-1152306461-463901096-1711473619=:182571" X-Spam-Status: No, score=-3.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,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: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---1152306461-463901096-1711473619=:182571 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT On Tue, 26 Mar 2024, Qing Zhao wrote: > > What happens when there are multiple counted_by attributes on the same > > field? As far as I can see, all but one end up being ignored (by the code > > that actually uses the attribute). > > In general, is there any rule for handling multiple same attributes in > GCC? i.e, from left to right, the last one wins? Or something else? I’d > like to following the consistent rule with other places in GCC. Sometimes, they are meaningful and all can be respected. (An example is the format_arg attribute, where ngettext legitimately has two such attributes.) When not meaningful, an error is appropriate. For example, with section attributes you can get error ("section of %q+D conflicts with previous declaration", *node); if different sections are named. I think that's a suitable model for the new attribute here: allow duplicates if they name the same field, but give errors if they name different fields, just as with the section attribute. Once you give an error for multiple attributes naming different fields, which one wins is just a question of error recovery; the specific choice doesn't matter much, as long as you don't get an ICE in later processing. -- Joseph S. Myers josmyers@redhat.com ---1152306461-463901096-1711473619=:182571--