[Bug middle-end/86202] [8/9 Regression] ICE in get_range_info, at tree-ssanames.c:407

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86202

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
The issue is that the frontend ends up with

 <function_decl 0x7ffff6939200 memcpy
    type <function_type 0x7ffff69bd690
...
        arg-types <tree_list 0x7ffff69ba938 value <pointer_type 0x7ffff68b4000>
            chain <tree_list 0x7ffff69ba910 value <pointer_type 0x7ffff68b4000>
                chain <tree_list 0x7ffff69ba8e8 value <pointer_type
0x7ffff68b8e70>
                    chain <tree_list 0x7ffff68a8820 value <void_type
0x7ffff68acf18 void>>>>>

 ^^^

        pointer_to_this <pointer_type 0x7ffff69bd9d8>>
    addressable used nothrow public external built-in decl_3 decl_5 QI t.c:1:7
    align:8 warn_if_not_align:0 built-in: BUILT_IN_NORMAL:BUILT_IN_MEMCPY
context <translation_unit_decl 0x7ffff68a1258 t.c>
^^^

so it puts BUILT_IN_NORMAL:BUILT_IN_MEMCPY on a decl with argument
types that do not match that of the MEMCPY builtin.

I think this is a more general issue with decl merging and not an issue
of rejecting incompatible declarations.

If we accept _any_ mismatch then we need to keep two decls and _not_
merge them.

Note that the original builtin decl is still there and it does have the
correct types.  So eventually the only issue is that we set the
BUILT_IN_NORMAL:BUILT_IN_MEMCPY attribution to mismatched decls.