On Wed, Nov 28, 2012 at 3:35 PM, Rafael Espíndola
<[email protected]> wrote:
>> I think I wasn't very clear here. My interpretation is: The type of the 'x'
>> variable within the definition of 'f' is int(*)[]. That 'x' is not a
>> redeclaration of the parameter in the previous 'f' declaration, so its type
>> doesn't get merged, even though the type of the function does get merged.
>>
>
> OK, I have added the testcases from this thread and updated the
> comment to not suggest patching the ParmVarDecl. Can you think of a
> sema test that would capture us merging the function type and not just
> the return type?
void f(int (*)[10]);
void f(int (*)[]);
void g() {
int x[5];
f(&x);
}
gcc gives "warning: passing argument 1 of ‘f’ from incompatible
pointer type"; clang should print a similar warning.
> What is the behavior you would expect from CodeGen? Given
>
> void f(int);
> void f(a)
> char a;
> {
> int v[sizeof(a) == 1 ? 1 : -1];
> }
>
> Should it produce a f(i32) that truncates its argument?
Yes, this should continue to work the same way it works on trunk.
-Eli
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
