From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 7978D3858C31; Mon, 6 Mar 2023 20:05:50 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 7978D3858C31 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1678133150; bh=J0PTlbt7r99CuHvvUgLXo16T9p5sBwQMEKGp2odC4IU=; h=From:To:Subject:Date:In-Reply-To:References:From; b=gkjRt1X4Z3mN1I+nqiix9UVlT7ZrLy3q55a2tAfkKc679XH1lfYyXjY2WWHGW1qt5 eAA/Z5Mey2n2HZyXEtUIWqHDB6WbFfnSwUaQD1LF5XscU2Y9nCaXVuVTlVHXg8l4tB uF7+a3MgN2n1I7gDowVXCl4XRj8GJiKTQvX2Fuho= From: "siddhesh at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c/108896] provide "element_count" attribute to give more context to __builtin_dynamic_object_size() and -fsanitize=bounds Date: Mon, 06 Mar 2023 20:05:49 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c X-Bugzilla-Version: unknown X-Bugzilla-Keywords: X-Bugzilla-Severity: enhancement X-Bugzilla-Who: siddhesh at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: qinzhao at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D108896 --- Comment #22 from Siddhesh Poyarekar --- (In reply to Martin Uecker from comment #20) > > I haven't seen comments on Kees's first example, where "malloc" returns= an > > "__alloc_size" hint that's lost when "p" is returned from the function = (at > > least in Clang). If that information is kept around, it would expand th= e number > > of bounds checks we could perform. (Kudos if this is currently the case= in > > GCC.) >=20 > I think not. But this would not work across TU boundaries anyway. >=20 > https://godbolt.org/z/eW9GT579r It's not that the information is lost in this case, it is just not visible, unlike bug 96503 for example where the information is actually lost. The example above doesn't work because the compiler is instructed to *not* look inside foo; I'd expect something like LTO to work even across TU boundaries whenever possible. There's the external linkage gap, but I don't know if that's a relevant motivation for the kernel. >From the kernel (or distribution builds) perspective, __element_count__ will cover situations where it's not straightforward to propagate sizes, e.g. wh= ere the target code is an allocator that itself wants to enforce size constrain= ts on objects it returns, beyond the input size request. This really should have been the way __access__ was implemented, but we tied that attribute to only functions. Would it be a terrible idea to make __element_count__ more general purpose so that it ends up deprecating __access__?=