On Fri, 2009-07-24 at 15:40 +0200, Danny Backx wrote:
> On Fri, 2009-07-24 at 14:51 +0200, Danny Backx wrote:
> > On Thu, 2009-07-23 at 15:06 +0200, Danny Backx wrote:
> > > On Thu, 2009-07-23 at 11:52 +0100, Dave Korn wrote:
> > > > Danny Backx wrote:
> > > > > On Thu, 2009-07-23 at 10:07 +0100, Dave Korn wrote:
> > > >
> > > > > Kai Ruottu wrote :
> > > > >> Comparing the output from some earlier working GCC with the gcc-4.4.0
> > > > >> output would reveal if something was wrong in preparing inputs for
> > > > >> the soft-float routines... Or maybe something was changed in the
> > > > >> soft-float routines... What if you try a 'libgcc.a' taken from some
> > > > >> earlier working GCC ?
> > > > >
> > > > > Did that, see below. I think this means that the stuff in libgcc.a
> > > > > cause
> > > > > the issue.
> >
> > It turns out that different functions are used :
> > - my 4.4 implementation takes its multiply code from dp-bit.c
> > - the 4.1 implementation takes it from ieee754-df.S
> >
> > I've now tweaked gcc/config/arm/t-wince-pe (to use _arm_muldivf3 instead
> > of _muldivf3 in LIB1ASMFUNCS). Then the gcc build fails (double
> > definitions). Worked around that by tweaking dp-bit.c .
> >
> > Result :
> > Foo 34 12.000000 67
> > 12 * 3 -> 36.000000
> > 36 -> 0.000000
> > 36 d -> 36.000000
> >
> > The 12 * 3 line is different from before : it displays the expected
> > result now.
> >
> > I guess I need to figure out how to make this work with Makefile work,
> > not tweaks to dp-bit.c .
> >
> > Looking further ...
>
> I need advice on how to proceed with this.
>
> It looks like the change that introduced _arm prefixes for functions in
> LIB1ASMFUNCS (in gcc/config/arm/t-wince-pe) broke things.
>
> The other place where this type of stuff is used is in
> libgcc/Makefile.in , and I think the line
>
> lib2funcs := $(filter-out $(LIB2FUNCS_EXCLUDE) $(LIB1ASMFUNCS),
> $(lib2funcs))
>
> is now broken due to the fact that the "encoding" of lib2funcs and
> LIB1ASMFUNCS is different.
>
> Unless I'm still missing something.
>
> Or is there a mechanism I haven't found yet to make sure that dp-bit.c
> and the assembler sources (such as ieee754-df.S) don't collide ?
>
> Clues, advice, please ?
>
> Danny
I saw a statement in the gcc/config/spu directory that could help.
Would it be a good idea to add stuff like this
DPBIT_FUNCS := $(filter-out _mul_df _div_df, $(DPBIT_FUNCS))
to gcc/config/arm/t-wince-pe ?
Danny
--
Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info
