GCC build failed for native with your patch on 2003-09-05T11:02:39Z.
Sat Sep 6 21:51:00 GMT 2003
Jan Hubicka <firstname.lastname@example.org> 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 <email@example.com>
More information about the Gcc-regression