Re: Patch to 1750a config for gcc-3.0.1

[Oliver dot Kellogg at t-online dot de (Oliver Kellogg)]

> With the below patches, I have been able to build a 1750a 
> cross compiler using gcc-3.0.1.
> [...]
> 2. On feeding a numerics application to the compiler, I got 
> aborts in real.c, function significand_size().
> This happens when a QImode value should be "float"ed to 
> TQFmode. The 1750a has a floatqihf2 and a floathitqf2, but 
> lacks a floatqitqf2. Interestingly, gcc-2.7.2 had the 
> intelligence to extendqihi2 the source operand and then 
> apply the floathitqf2 - apparently this intelligence has been 
> lost.

At closer look, I doubt that define_expand'ing floatqitqf2 
is the correct way to fix this. Rather, in expand_float()
(optabs.c:3942) I see the loops

  for (imode = GET_MODE (from); imode != VOIDmode;
       imode = GET_MODE_WIDER_MODE (imode))
    for (fmode = GET_MODE (to); fmode != VOIDmode;
         fmode = GET_MODE_WIDER_MODE (fmode))

The fmode loop iterates all the way out to the largest 
theoretically possible mode, XFmode, which is way beyond 
anything supported by the 1750a (and certainly a number 
of other targets.)
Rather than having significand_size() deal with 
nonsensically large input modes, wouldn't it be more 
appropriate to limit the fmode loop test to modes that 
are supported by the target?
Something along the lines of

  for (imode = GET_MODE (from); imode != VOIDmode;
       imode = GET_MODE_WIDER_MODE (imode))
    for (fmode = GET_MODE (to);
         GET_MODE_BITSIZE (fmode) <= LONG_DOUBLE_TYPE_SIZE;
         fmode = GET_MODE_WIDER_MODE (fmode))

Of course, here LONG_DOUBLE_TYPE_SIZE is assumed to be 
the widest possible float type any machine would deal with, 
which may be a flawed assumption. Sometime there seems to 
have existed a target macro, WIDEST_HARDWARE_FP_SIZE, but 
it doesn't seem to be used in gcc-3.0.1.

Before I submit any other patches I'd appreciate your thoughts.

Oliver Kellogg
-- oliver.kellogg@t-online.de