This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: RFC: Hack to make restrict more useful
On 9/3/07, Daniel Berlin <dberlin@dberlin.org> wrote:
>
> That said, second, my understanding of restrict, from reading the c99
> standard, is that it is perfectly valid for restrict pointers to alias
> each other during *loads*.. IE you can guarantee any restricted
> pointer that is stored into can't alias the other restricted pointers.
> Those only used for loads can alias each other.
>
> This comes from 6.7.3.1 #4, which says "During each execution of B,
> let L be any lvalue that has &L based on P. If L is used to access
> the value of the object X that it designates, and X is also *modiïed*
> (by any means), ... the following requirements apply:...[part about
> not being able to point to same object, basically]"
>
> They even given an example of this (two restricted pointers to arrays
> aliasing) happening.
>
> It this an incorrect reading? I'll happily admit that reading
> standards makes my brain hurt, it's worse than reading caselaw, so i'd
> love to be wrong.
>
> I'd also love to simply ignore this part, because i don't believe
> anyone who has actually *used* restrict thinks it means anything other
> than "this can't alias my other restrict pointers".
>
> I'm also pretty sure no other compiler implements this restriction
> anyway, as it removes a *lot* of useful cases of restrict. We
> certainly get it wrong. :)
How does it make a difference? If for two pointers that are only
loaded from we say they don't alias I cannot imagine a transformation
that would get anything wrong. For example EXAMPLE 2 clearly
suggests that not both pointers need to be written to. That is,
EXAMPLE 3 is merely to make it defined behavior from a standards
point of view, even if it doesn't make a difference in practice.
But, IANTL. ;)
Richard.