ARM float changes

ARM float changes

[Daniel Jacobowitz]

(Sorry for breaking threading, I have a trigger happy delete finger...)

Have you tested this change on stabs debugging?  If you were testing with
GCC head and did not do so explicitly, GCC now defaults to DWARF-2 for a
substantial number of targets.

I ask because your change is probably wrong for stabs.  Stabs _never_ sets
TYPE_FLAG_PROTOTYPED at present, and so this may break the calling of
prototyped functions taking float using stabs debugging.

default_coerce_float_to_double appears to have the opposite problem and
break DWARF-2.


For instance, my results on i386-linux, callfuncs.exp:
	  standard coercion			default coercion
	  =================			================

GCC 2.95
  stabs+	1 XPASS, 1 FAIL, 1 XFAIL	1 FAIL, 2 XPASS
  dwarf2	1 FAIL				5 FAIL

GCC 3.0.4pre
  stabs+	1 XPASS, 1 XFAIL		2 XPASS
  dwarf2	0 FAILS				4 FAIL


What particularly do these mean?
  - 1 FAIL for all the 2.95 cases is unrelated, a backtrace/prologue
problem.
  - The default coercion, which GDB uses on this target, promotes
floats on DWARF-2.  Incorrectly.
  - The "standard" coercion promotes floats incorrectly on stabs, but in two
of the four cases we promote incorrectly for DWARF-2.

Simply disabling promotion is about equivalent to default coercion.  

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: ARM float changes

[Richard Earnshaw]

> 
> For instance, my results on i386-linux, callfuncs.exp:
> 	  standard coercion			default coercion
> 	  =================			================
> 
> GCC 2.95
>   stabs+	1 XPASS, 1 FAIL, 1 XFAIL	1 FAIL, 2 XPASS
>   dwarf2	1 FAIL				5 FAIL
> 
> GCC 3.0.4pre
>   stabs+	1 XPASS, 1 XFAIL		2 XPASS
>   dwarf2	0 FAILS				4 FAIL
> 

So doesn't all this mean that the coercion model should be selected based 
on the debug-info type?  Can we do that dynamically in the back-end?

R.

Re: ARM float changes

[Andrew Cagney]

> For instance, my results on i386-linux, callfuncs.exp:
>> standard coercion			default coercion
>> =================			================
>> 
>> GCC 2.95
>> stabs+	1 XPASS, 1 FAIL, 1 XFAIL	1 FAIL, 2 XPASS
>> dwarf2	1 FAIL				5 FAIL
>> 
>> GCC 3.0.4pre
>> stabs+	1 XPASS, 1 XFAIL		2 XPASS
>> dwarf2	0 FAILS				4 FAIL
>> 
> 
> 
> So doesn't all this mean that the coercion model should be selected based 
> on the debug-info type?  Can we do that dynamically in the back-end?


I suspect, in truth the target should never have even been allowed to 
enter the picture.  The core of GDB should have set a policy based on 
debug info and then stuck with it.

The change at least makes things consistent with other modern targets. 
 From memory the comment that goes with standard_...() hints strongly 
that no target should ever be using default_...().

I think this illustrates my contention that GDB should bite the bullet 
and ``break'' some targets but fix the problem.

I can always make the next release 6.0 :-^

enjoy,
Andrew

Re: ARM float changes

[Daniel Jacobowitz]

On Fri, Feb 08, 2002 at 12:29:24PM -0500, Andrew Cagney wrote:
> >For instance, my results on i386-linux, callfuncs.exp:
> >>standard coercion			default coercion
> >>=================			================
> >>
> >>GCC 2.95
> >>stabs+	1 XPASS, 1 FAIL, 1 XFAIL	1 FAIL, 2 XPASS
> >>dwarf2	1 FAIL				5 FAIL
> >>
> >>GCC 3.0.4pre
> >>stabs+	1 XPASS, 1 XFAIL		2 XPASS
> >>dwarf2	0 FAILS				4 FAIL
> >>
> >
> >
> >So doesn't all this mean that the coercion model should be selected based 
> >on the debug-info type?  Can we do that dynamically in the back-end?
> 
> 
> I suspect, in truth the target should never have even been allowed to 
> enter the picture.  The core of GDB should have set a policy based on 
> debug info and then stuck with it.
> 
> The change at least makes things consistent with other modern targets. 
> From memory the comment that goes with standard_...() hints strongly 
> that no target should ever be using default_...().
> 
> I think this illustrates my contention that GDB should bite the bullet 
> and ``break'' some targets but fix the problem.

See my comment on gdb@ about this just now.  While standard appears to
be the way to go for DWARF-2, the right solution for stabs just seems
to be pretending we always have a prototype.  I'll look over what
various targets actually set this to... dealing with setting it based
on debug info is somewhat dubious, since debug info may be mixed in the
same objfile.

> I can always make the next release 6.0 :-^

:)

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer