[cfe-dev] Treatment of __restrict__

[Douglas Gregor]

On May 22, 2010, at 2:20 AM, Roberto Bagnara wrote:

> 
> void f(const char *__restrict__ out) {
>   out++;
> }
> 
> The above testcase brings to the generation of the
> following dump:
> 
> void f(char const *restrict out) (CompoundStmt 0x27ce5b0 <d.c:1:38, line:4:1>
>   (DeclStmt 0x27be5a0 <line:2:3, col:29>
>     0x27d2bc0 "char const *restrict d"
>   (BinaryOperator 0x27d2d20 <line:3:3, col:7> 'char const *' '='
>     (DeclRefExpr 0x27d2c20 <col:3> 'char const *restrict' Var='d' 0x27d2bc0)
>     (ImplicitCastExpr 0x27d2ce0 <col:7> 'char const *restrict' <Unknown>
>       (ImplicitCastExpr 0x27d2ca0 <col:7> 'char const *' <NoOp>
>         (DeclRefExpr 0x27d2c60 <col:7> 'char const *restrict' ParmVar='out' 0x27cf800)))))

I think your actual test case was:

	void f(const char *__restrict__ out) {
	  const char *restrict d;
	  d = out;
	}

> This indicates that:
> 
> - two apparently useless implicit casts are generated;

The innercast is from the lvalue-to-rvalue conversion, which strips qualifiers (C99 6.3.2.1p2). The outer cast adjusts the type of the right-hand side to match that of the left-hand side. I don't like the fact that we have an "unknown" conversion there, but otherwise this looks fine.

> - the BinaryOperator node's type has lost the restrict qualifier.


The result of assignment is the unqualified type of the left-hand side (C99 6.5.16p3), so this is also correct.

	- Doug