From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firebrick.ash.relay.mailchannels.net (firebrick.ash.relay.mailchannels.net [23.83.222.59]) by sourceware.org (Postfix) with ESMTPS id 037D9385351C for ; Fri, 20 Oct 2023 19:11:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 037D9385351C Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=gotplt.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gotplt.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 037D9385351C Authentication-Results: server2.sourceware.org; arc=pass smtp.remote-ip=23.83.222.59 ARC-Seal: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1697829066; cv=pass; b=iqPrgOb4NKapjVGVG+Msgr0ufdSen22uMYlkUyKFEKX5rsCzlqsipJybov2Hf7fadwTu401fjvvZzK9vrUYvwVFFSyHhqci65a59jqfBQMvobNwMs24ILmwM8Frrs7rzhW+eCmewUJ23pJHNAUIBhjQr7lGHF7HxF6ArOMHiF1U= ARC-Message-Signature: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1697829066; c=relaxed/simple; bh=l88mbY21w68NC5GxttCDaRlJS8vfmnnvmQQo0cPj0cQ=; h=DKIM-Signature:Message-ID:Date:MIME-Version:To:From:Subject; b=amXGhEAGnkNdx4gDUk6auCRcAWRoh6Iogn3p1HlUH57RerusyICUmZn2wtf4XLMmSc6jqON0OhZSrz8bOs8LpmdPWw6qgDObJ6ImrdWum0/Fj/VfQ2W2/yItdWAD4Dxf6iHD586szHB63wth/n3YDfv+1ffvRyIL/rIaXSe+rAA= ARC-Authentication-Results: i=2; server2.sourceware.org X-Sender-Id: dreamhost|x-authsender|siddhesh@gotplt.org Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 378C1502244; Fri, 20 Oct 2023 19:10:59 +0000 (UTC) Received: from pdx1-sub0-mail-a202.dreamhost.com (unknown [127.0.0.6]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 9D8E75022A9; Fri, 20 Oct 2023 19:10:58 +0000 (UTC) ARC-Seal: i=1; s=arc-2022; d=mailchannels.net; t=1697829058; a=rsa-sha256; cv=none; b=7+UyclINjwLBGZCjUWoPToB0tXZAP2pCfLpUcVd1k0FmxYOHJ6yxq2zoeWlBlYr96tRcYy 4kCWuUEghiTXC35LrdP6qxy10K897OVHyLbDaeTbB+Mred2Yncte6Sv5ZgVdaUyiLJQ4db CoNAgcJ1WXE2FSN8/iwDLbSQadYZgwNfKryGTPbgj7dKTuUVQgho5usSfe2Cvha2YXPLh1 btKpAj9gHGq5+65zCUI4NCSdYffTjm05SnXXdt3kIgQIWT8hzVoUrqNy6ngHxECe4LAEm3 Qa4iktoS/XMK9e2m2Y1Bh8TGPl1KXOh6wi+W26NW112Cv8ggCULgTuG7s9Vr+A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=mailchannels.net; s=arc-2022; t=1697829058; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=8vunHXuSJZEhwvHp21Lmca9hH5RTprZDe4wa2XEWCvI=; b=oxVdG3Nn5pDfUIUROk2/DYUZmRpvgLhHmfkxevcax2SbChamC51nqYNSAgQ5j4VLeR+OAv qsRcjpSw6aeZQdW/rMXIvfb7Vbmf5N4naE4E9XfRP2itL7RjJsOHKSFXq9GbKw3BL+ZYy/ A93hkyUxtFpBcODhpvKiyJcjW46Y5KEpjaZEXDoWwy5XI/eshY2LuOlWjY6Rf2gq8hVXbC hU176IeOyXSnHIkntbLx4XTOyhzm/lohIJZlGpmEm29UUV/tRBPSqMyjys2dHsHTfl84mg Zk6BQRNRnmmpgCZn2ZPfZT1PU1wS2tF3TKleCuqi0NAtCYr8UT7Fl455JqZ66g== ARC-Authentication-Results: i=1; rspamd-846f4b758b-cn49q; auth=pass smtp.auth=dreamhost smtp.mailfrom=siddhesh@gotplt.org X-Sender-Id: dreamhost|x-authsender|siddhesh@gotplt.org X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|siddhesh@gotplt.org X-MailChannels-Auth-Id: dreamhost X-Blushing-Sponge: 1153ccca4d08b233_1697829058973_3572793704 X-MC-Loop-Signature: 1697829058973:1784703665 X-MC-Ingress-Time: 1697829058972 Received: from pdx1-sub0-mail-a202.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384) by 100.117.92.198 (trex/6.9.2); Fri, 20 Oct 2023 19:10:58 +0000 Received: from [192.168.2.12] (bras-vprn-toroon4834w-lp130-02-142-113-138-136.dsl.bell.ca [142.113.138.136]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: siddhesh@gotplt.org) by pdx1-sub0-mail-a202.dreamhost.com (Postfix) with ESMTPSA id 4SBvLn5JW0z4C; Fri, 20 Oct 2023 12:10:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gotplt.org; s=dreamhost; t=1697829058; bh=8vunHXuSJZEhwvHp21Lmca9hH5RTprZDe4wa2XEWCvI=; h=Date:To:Cc:From:Subject:Content-Type:Content-Transfer-Encoding; b=EmqDq9HxXQlz/fAWdjEYtGfN8y7FZ1HnBtPFOMUgxyPnfcLT7n0ZCOka9QZmoA0cc 422JY01VTQkmfW4j1NKPyqAyrcrmHRK9auB1Qn6oSs/X9jlWqt4bTXTpWOlE6pfEON jamdSPVY9PKQOYW+7UX7ALhdkaPJf7Ui0KBEg1ZYaaiDdHyEQ7xnF9hqE0WDhZiH7k 4Qnana8O8eY6RmO6YEIMMpbxm+BJOpQTJhhX/nDJCgQMcwNbFHe+9MiooTfz+un8uC NeCsHIvAoWhVUKNHadedGkhDGV3gRZzkAsq9KPjxgmFgwjXe6qqKsUc0H4GP9ooe0R wXUFHVJTfKleg== Message-ID: Date: Fri, 20 Oct 2023 15:10:56 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.15.1 Content-Language: en-US To: Qing Zhao , Richard Biener Cc: Joseph Myers , Jakub Jelinek , gcc Patches , kees Cook , Martin Uecker , "isanbard@gmail.com" References: <22BDBC0E-1B28-46D0-BCA4-588F73B198E0@oracle.com> <46C61773-8C30-4A68-815A-E724A6A4DCEE@oracle.com> From: Siddhesh Poyarekar Subject: Re: HELP: Will the reordering happen? Re: [V3][PATCH 0/3] New attribute "counted_by" to annotate bounds for C99 FAM(PR108896) In-Reply-To: <46C61773-8C30-4A68-815A-E724A6A4DCEE@oracle.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3031.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,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: On 2023-10-20 14:38, Qing Zhao wrote: > How about the following: > > Add one more parameter to __builtin_dynamic_object_size(), i.e > > __builtin_dynamic_object_size (_1,1,array_annotated->foo)? > > When we see the structure field has counted_by attribute. Or maybe add a barrier preventing any assignments to array_annotated->foo from being reordered below the __bdos call? Basically an __asm__ with array_annotated->foo in the clobber list ought to do it I think. It may not work for something like this though: static size_t get_size_of (void *ptr) { return __bdos (ptr, 1); } void foo (size_t sz) { array_annotated = __builtin_malloc (sz); array_annotated = sz; ... __builtin_printf ("%zu\n", get_size_of (array_annotated->foo)); ... } because the call to get_size_of () may not have been inlined that early. The more fool-proof alternative may be to put a compile time barrier right below the assignment to array_annotated->foo; I reckon you could do that early in the front end by marking the size identifier and then tracking assignments to that identifier. That may have a slight runtime performance overhead since it may prevent even legitimate reordering. I can't think of another alternative at the moment... Sid