This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] ARM half-precision floating point, 5/8 (detect constant overflow)
- From: Sandra Loosemore <sandra at codesourcery dot com>
- To: Richard Guenther <richard dot guenther at gmail dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>, "Joseph S. Myers" <joseph at codesourcery dot com>, trevor_smigiel at playstation dot sony dot com, andrew_pinski at playstation dot sony dot com, edelsohn at gnu dot org
- Date: Mon, 20 Apr 2009 00:04:30 -0400
- Subject: Re: [PATCH] ARM half-precision floating point, 5/8 (detect constant overflow)
- References: <49E65E6F.email@example.com> <firstname.lastname@example.org>
Richard Guenther wrote:
On Thu, Apr 16, 2009 at 12:23 AM, Sandra Loosemore
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
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.