Re: Redeclaration of used symbols

[Jan Hubicka <jh at suse dot cz>]

> Jan Hubicka <jh@suse.cz> writes:
> | Hard error sounds like most plausible sollution to me as well, however
> | duplicate_decls is a black magic for me, what code you do have in mind?
> 
> duplicate_decls should be broken in logical units one day...
> 
> | In general it would be nice if we can avoid changing the declarations
> | of functions and variables once they have been defined...
> 
> Yep.  You need to be careful about
> 
>   static inline int max(int a, int b) { return b > a ? a : b; }
> 
>   // ...
>   
>   void f(int a, int b)
>   {
>      extern int min(int, int);  // common practice in C
> 
>      int j = min(a, b);
>   }

This is fine for me, assuming that the extern int min(int, int) makes
duplicate_decls to simply copy the previous declaration and keep inline
and static flags on.

There are however number of cases where things may get crazy.  For
instance:

t()
{
}
int t() __attribute__ ((noinline));

In this case I will miss noinline attribute in non-unit-at-a-time mode

Very irritating is also possiblity of redefining extern inline functions
like

extern inline int t()
{
  something...
}
int t()
{
  something else...
}

I think current semantic is to use first body for all functions expanded
before second body is seen.  For functions exapnded afterwards the
function loses the always_inline behaviour and second mode is inlined.
When function is expanded depends on inlining decisions.  

Also non-unit-at-a-time code gets confused by this analyzing the function twice.
(this does not lead to any crash, but the callgraph is built
incorrectly)
I have patch to deal with this in a way that unit-at-atime always uses
the second body (as the first body is lost during parsing).

Finally funny testcase is:
extern inline int t()
{
  something...
}
extern inline int foo (void) { return 23; }
extern int foo (void) __attribute__ ((weak, alias ("xxx")));

That causes us to remove body of the extern inline function during
duplicate_decl called in second delaration.

I would love to get hard errors on as many of these testcases as
possible as dealing with these is ficiult and I think all of these have
rather funny semantics when seen by GCC.

Honza