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.
