[Bug target/64212] [4.9/5 Regression] ICE [in noninterposable_alias, at symtab.c:1706]

["ktietz at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

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

--- Comment #3 from Kai Tietz <ktietz at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #2)
> Reduced testcase:
> 
> inline void
> foo (void)
> {
> }
> 
> __attribute__ ((__dllimport__))
> void foo (void);
> 
> void
> bar (void)
> {
>   foo ();
> }
> 
> No options are needed, reproduced with x86_64-linux -> x86_64-mingw32 cross.
> ICEs the same even with an extra extern void foo (void); prototype above the
> inline, and no matter whether -std=gnu89 or -std=c11 is used.
> Kai, is this even meant to be valid (i.e. shouldn't we reject this - adding
> dllimport attribute after inline fn definition)?  And, is it really a
> regression?  Don't have time to build cross-compilers for older gcc
> versions, perhaps you have some older ones around?

I think this scenario is valid.  Of course it is better style for having first
the prototype and then its inline-function.

So by changing sample this way:

__attribute__ ((__dllimport__))
void foo (void);

inline void
foo (void)
{
}

void
bar (void)
{
  foo ();
}

There is no ICE.  The point here is that dllimport indicates that function is
external, but by the dllimport-attribute 'function_and_variable_visibility'
pass gets confused. In symtab_node::noninterposable_alias() we assert on
'decl_binds_to_current_def_p' returning true, which is of course the case for
the inline-case.