Mark Mitchell wrote:
> Joseph S. Myers wrote:
>
>> The rules that unmodified memory may alias were a deliberate change in the
>> FDIS relative to the previous public draft; see
>> <http://www.open-std.org/jtc1/sc22/wg14/www/docs/n866.htm>:
>
> That explains why I had no memory of this, despite having researched
> "restrict" pretty carefully in earlier drafts. That also explains why
> other compilers in the field implements "restrict" as meaning "does not
> alias", independent of what's modified.
>
> Danny, does your more comprehensive treatment of "restrict" still
> optimize test cases like the one in the PR I filed?
>
Test cases of mine, which fail to optimize, involve a scalar argument,
performing arithmetic between a scalar and an array. In the C case,
-fargument-noalias brings optimization, which is not promoted by
restrict keyword. Using an explicit local copy of the argument should
work as well. Could that be a reason for avoiding the optimization?
I think the likely use of restrict by various compilers comes into play
only when a possibly aliased variable is modified, as pointed out
previously. Such optimization could result in "broken" results anyway,
wwhen array bounds violations occur, so I guess there's no way to check,
other than by extending bounds checking.