Re: compile server status?

[Jan Hubicka <hubicka at ucw dot cz>]

> On Thursday, October 30, 2003, at 12:53 AM, Jan Hubicka wrote:
> >>Per is working on detangling dup_decls so that we don't modify the old
> >>decl.  This will be really handy for C++ fragment management.  Per and
> >
> >This would be very helpfull for unit-at-a-time code as well.  Would be
> >possible to make this go into mainline soon? (well perhaps into 
> >tree-ssa
> >branch)
> 
> I'd encourage anyone that wants to see any of the technology for other 
> reasons to migrate what they want into 3.5.  The srcloc_t (or whatever 
> we call it) is an example of something that I think is good regardless 
> of other issues.  I must admit that I don't see the use of it in your 
> case.  Could you say a few words so that Per and I can ensure that it 

I have problems with decls being changed by duplicate_decls on several
places.  For instance when we do have extern inline function with later
re-definition with normal function, we have de-facto two independent
functions in one decl.  This confuses the code considerably.
Similar problems arrise when symbol is renamed.

It would be pobably best to handle such a cases as two independent
functions that can be doable pretty easilly when the decls are not
modfied.

Honza
> dove tails nicely.  I can't really push for it sooner, as I don't have 
> a firm grasp of why it would be good to have now.  With the compile 
> server it will be used to prevent the migration of information from one 
> translation unit to another unrelated translation unit.  The canonical 
> example for C++ would be:
> 
> bar.h:
> void foo();
> 
> ba.h:
> void foo() { ba(); }
> 
> bai.h:
> void foo() { bai(); }
> 
> and the two units:
> 
> #include "b.h"
> #include "ba.h"
> 
> and
> 
> #include "b.h"
> #include "bai.h"
> 
> Now, personally, I'd like this to just be an error, but the language 
> standard allows it.
> 
> Thanks.