Re: Redeclaration of used symbols

[Jan Hubicka <hubicka at ucw dot cz>]

> Jan Hubicka <jh@suse.cz> writes:
> 
> | > 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.
> 
> actually, in that case, duplicate_decls should do nothing -- except
> making the min in scope (but that is the job of a separate code anyway).
> 
> | 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
> 
> Is duplicate_decls responsible for that?

Not, but we call finalize_function before that and never look into the
declaration afterwards.
> 
> | Very irritating is also possiblity of redefining extern inline functions
> | like
> | 
> | extern inline int t()
> | {
> |   something...
> | }
> | int t()
> | {
> |   something else...
> | }
> 
> Yep. :-(  
> Fortunately, those pathologies are ruled out in C++.
> 
> | 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.  
> 
> hmm, messy.
Yep and it will be the same for noinline and other examples.
I would simply prohit backward declarations except for those doing
absolutely nothing, if it were up to me only :)
> 
> [...]
> 
> | 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.
> 
> hmm, is this documented behaviour, or is it just an undocumented
> implementation strategy?

Manual does not get into such a detail and only show that it is possible
to use forward declaration.

The worst case I am aware of is glibc that first include header and
later use typeof extension to change assembler name.  This comes before
first use of that function and I guess we have to deal with this case,
but I would like to rule out the case above (simplified from compile
testusite)

Honza