Hi Martin, On Tue, Jul 09, 2024 at 07:58:40AM GMT, Martin Uecker wrote: > Am Montag, dem 08.07.2024 um 22:17 +0200 schrieb Alejandro Colomar: > > Hi Martin, > > > > On Mon, Jul 08, 2024 at 06:05:08PM GMT, Martin Uecker wrote: > > > Am Montag, dem 08.07.2024 um 17:01 +0200 schrieb Alejandro Colomar: > > > > On Mon, Jul 08, 2024 at 10:30:48AM GMT, David Malcolm wrote: > > > > > > ... > > > > And then have it mean something strict, such as: The object pointed to > > > > by the pointer is not pointed to by any other pointer; period. > > > > > > > > This definition is already what -Wrestrict seems to understand. > > > > > > One of the main uses of restrict is scientific computing. In this > > > context such a definition of "restrict" would not work for many > > > important use cases. But I agree that for warning purposes the > > > definition of "restrict" in ISO C is not helpful. > > > > Do you have some examples of functions where this matters and is > > important? I'm curious to see them. Maybe we find some alternative. > > In many numerical algorithms you want to operate on > different parts of the same array object. E.g. for matrix > decompositions you want to take a row / column and add it > to another. Other examples are algorithms that decompose > some input (.e.g. high and low band in a wavelet transform) > and store it into the same output array, etc. > > Without new notation for strided array slicing, one I'll have to remove dust from my old proposal of [.nmemb]? :) > fundamentally needs the flexibility of restrict that > only guarantuees that actual accesses do not conflict. I guess a combination of [.nmemb] (or the third argument of [[gnu::access()]] and [[alx::noalias]] could be good enough for such a use case? [[alx::noalias(1)]] [[alx::noalias(2)]] void add(int a[.n], const int b[.n], n); //or [[alx::noalias(1)]] [[alx::noalias(2)]] [[gnu::access(read_write, 1, 3)]] [[gnu::access(read_only, 2, 3)]] void add(int a[], const int b[], n); mad(&arr[0], &arr[50], 50); The caller should be able to know that while the pointers can alias within the caller, they don't alias within the callee, since the callee has no right to access past the specified bound*. * The standard would have to tighten bounds in function interfaces, since right now, the value is just ignored if it doesn't come with 'static' (which I never understood), and if specified with 'static', it's just a lower bound not a strict bound. I would propose changing the meaning of [N] in a function prototype to mean a strict bound. Does that make sense? Have a lovely day! Alex > But this then implies that one can not use restrict as a > contract specification on function prototypes, but has > to analyze the implementation of a function to see if > it is used correctly. But I would not see it as a design > problem of restrict. It was simply not the intended use > case when originally designed. -- <https://www.alejandro-colomar.es/>
Attachment:
signature.asc
Description: PGP signature
