Re: Redeclaration of used symbols

[Gabriel Dos Reis <gdr at integrable-solutions dot net>]

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?

| 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.

[...]

| 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?

| 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.

yup.

-- gaby