On Tue, Jan 24, 2017 at 5:37 AM, Luc Van Oostenryck
<luc.vanoostenryck@xxxxxxxxx> wrote:
> So far, builtin functions which had some evaluate/expand method
> couldn't also have a prototype because each would have its own symbol
> and only the one for the prototype will be seen.
> This also meant that the evaluate/expand functions had to take care
> to set the correct types for they argumenst & results, which is fine
> for some generic builtins like __builtin_constant_p() it's much less
> practical for the ones like __builtin_bswap{16,32,64}().
>
> Fix this by marking the idents for the builtins we declare some
> evaluate/expand methods has being the ident of a builtin function
> and later at evaluation time, to share the methods between all the symbols
> corresponding to an identifier so marked.
This certainly fix the problem for builtin functions. However, I think there
is more general bug in sparse not limit to builtin functions. When the symbol
is declare twice, the later one did not migrate all the declare information from
the previous one.
In function external_declaration()
check_declaration(decl);
if (decl->same_symbol)
decl->definition = decl->same_symbol->definition;
Here it only migrates the definition. I think if you add symbol->op in
the migration
as well, it *should* work for your case. I haven't test this myself.
If that works for you, it is a more general fix. Want to give it a try?
We might want to extract the migration code into a new function and
later adding new code it. e.g. function attributes.
A more complicate example will involve same symbol in different scope.
void __attr_x foo(void);
void a(void)
{
void __attr_y foo(void); // foo should have both __attr_{x,y}
{
void _attr_z foo(void); // foo should have all __attr_{x,y,z}
}
// now foo should only have __attr_{x,y}
}
update:
I attach a quick and dirty patch file for you to try. It will replace
this 2/3 patch.
I just try the test suite and nothing seems complain about it.
Chris
Attachment:
migrate-same-symbol
Description: Binary data
