Re: [PATCH] ARM half-precision floating point, 5/8 (detect constant overflow)

[Sandra Loosemore <sandra at codesourcery dot com>]

Richard Guenther wrote:
> On Thu, Apr 16, 2009 at 12:23 AM, Sandra Loosemore
> <sandra@codesourcery.com> wrote:
> > This patch adds some logic to detect overflow on compile-time
> > constant conversions between floating-point formats.  There's nothing
> > specific to half-precision here, but the main thing it's intended to
> > catch is overflows in conversions to formats that can't represent
> > infinities -- specifically, the ARM alternative half-precision
> > representation.
>
> Can you test this on another architecture which lacks support
> for NaNs or Infs?  I seem to remember that the Cell SPU at
> least lacks them for floats(?).
>
> How does the C frontend react to TREE_OVERFLOW set on
> constant initializers (which we are allowed to accept?).
>
> If Joseph thinks this is ok the patch is ok if it passes
> bootstrap / testing on another target with lacking NaN/Inf support.

It looks like carrying out this level of testing would be a non-trivial amount 
of effort.  I have discovered that, while we do in fact have some Cell hardware 
at CodeSourcery, we've never tried to build or test an SPU compiler before. 
And, as far as I can tell, the GNU SPU tools treat this as a 
bare-metal/ELF/newlib target; can you even bootstrap GCC on this machine at all?

Perhaps the SPU port maintainers can provide some assistance here, or comment on 
what they'd consider appropriate testing for this patch?  In particular, note 
that this is a change to compile-time behavior only; it causes some additional 
overflow cases to be detected and warned about when you compile with -pedantic. 
 So I'm not sure, exactly, what the point of doing execution testing or a full 
bootstrap would be.

Also.... it appears that the only other floating-point formats without NaN/Inf 
support that GCC knows about are the various VAX formats, and we don't have 
hardware to test that at CodeSourcery, either.

-Sandra