On Wed, Nov 28, 2012 at 1:52 PM, Richard Smith <span dir="ltr"><<a href="mailto:richard@metafoo.co.uk" target="_blank">richard@metafoo.co.uk</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">On Wed, Nov 28, 2012 at 1:31 PM, Eli Friedman <span dir="ltr"><<a href="mailto:eli.friedman@gmail.com" target="_blank">eli.friedman@gmail.com</a>></span> wrote:<br></div></div><div class="gmail_quote">
<div><div class="h5"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div>On Wed, Nov 28, 2012 at 1:25 PM, Richard Smith <<a href="mailto:richard@metafoo.co.uk" target="_blank">richard@metafoo.co.uk</a>> wrote:<br>
> On Wed, Nov 28, 2012 at 12:59 PM, Eli Friedman <<a href="mailto:eli.friedman@gmail.com" target="_blank">eli.friedman@gmail.com</a>><br>
> wrote:<br>
>><br>
>> On Wed, Nov 28, 2012 at 9:17 AM, Rafael Espíndola<br>
>> <<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>> wrote:<br>
>> > Thanks Richard for pointing me some missing cases. The attached patch<br>
>> > takes a step back and merge only the return types.<br>
>> ><br>
>> > Richard suggested avoiding the merging when the new Decl is a k&r<br>
>> > definition, but at this point of the code we haven't attached the body<br>
>> > yet. It would also be nice if we could handle both definitions and<br>
>> > declarations uniformly.<br>
>> ><br>
>> > I debugged why CodeGen was complaining and the problem is that by<br>
>> > merging just the function types we end up with a ParmVarDecl whose<br>
>> > type doesn't match the corresponding type in the FunctionProtoType and<br>
>> > CodeGen asserts. Two options that would still let us merge the full<br>
>> > types is making CodeGen cope with it (produce a llvm cast) or patching<br>
>> > the type of the ParmVarDecl too. Do you think we should do it?<br>
>><br>
>> Patching the type of the ParmVarDecl would be appropriate.<br>
><br>
><br>
> Given:<br>
><br>
> int f(int);<br>
> int f(a)<br>
>   char a;<br>
> {<br>
>   return sizeof(a);<br>
> }<br>
><br>
> I would expect 1 to be returned, not 4.<br>
<br>
</div></div>Yes, you're right.<br>
<br>
I was thinking of:<br>
int f(int (*)[10]);<br>
int f(int (*x)[]) {<br>
  return sizeof(*x); // 40<br>
}<br>
<br>
But maybe not relevant to this discussion?</blockquote><div><br></div></div></div><div>I'd expect that to also be ill-formed. The type of the 'x' parameter is int(*)[]</div></div></blockquote><div><br></div><div>
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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div>even though the type of the function is int(int(*)[10]), by my interpretation (and GCC and EDG agree). It seems to me that CodeGen is just wrong to assume that the type of a ParmVarDecl matches the type of the corresponding parameter in the function's type, and it'll need to insert casts as necessary.</div>

</div>
</blockquote></div><br>