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

Geoff Keating geoffk@geoffk.org
Sat Sep 6 21:51:00 GMT 2003

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

- Geoffrey Keating <geoffk@geoffk.org>

More information about the Gcc-regression mailing list