GCC build failed for native with your patch on 2003-09-05T11:02:39Z.

[Jan Hubicka]

> > Jan Hubicka <jh@suse.cz> writes:
> > 
> > > > 
> > > > On Saturday, Sep 6, 2003, at 12:01 US/Pacific, Jan Hubicka wrote:
> > > > >In the case you have a testcase I can try to look into it.
> > > > >(After all I had to deal with a tons of similar issues)
> > > > 
> > > > Here is the reduced testcase (I think this is a Darwin specific bug 
> > > > meaning
> > > > the Darwin's backend does not expect the variable to change to being a
> > > > common symbol from a non-common, I will be looking into this, Darwin's 
> > > > backend
> > > > might just have to be rewritten, I already rewrote the PIC code part
> > > > The right asm does not have ".comm __ZN5ctypeIcE2idE,1" but
> > > >         .globl __ZN5ctypeIcE2idE
> > > > .data
> > > > __ZN5ctypeIcE2idE:
> > > >         .space 1
> > > > So it looks like unit-at-a-time is marking _ZN5ctypeIcE2idE 
> > > > (ctype<char>::id)
> > > > as a common symbol but it did it after Darwin's backend saw it as a 
> > > > non-common.
> > > 
> > > This sounds really interesting.  With unit-at-a-time we should not tell
> > > backend anything before finalizing all the flags.  Hmm...
> > 
> > The problem is that encode_section_info is being called from
> > cp_finish_decl, but then later on comdat_linkage is called from many
> > places including import_export_decl.  This breaks Darwin's current
> > ugly way of doing PIC, but even if Darwin used all the new features
> > like SYMBOL_REF_LOCAL_P it wouldn't help because they are wrong too
> > (because default_binds_local_p_1 also looks at DECL_COMMON).
> 
> I am attaching patch I am just about to test (it may require adding code
> to deal with functions in cp/decl2.c bits), but it fixes testcase sent
> by Andrew.
OK, it has passed my testing on i386.  Would be possible to verify
whether it works for you?  I will commit it as obvious then.

Honza