public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
* One more limits question
@ 2003-01-29 22:05 Mark Mitchell
  2003-01-29 22:10 ` Richard Henderson
  0 siblings, 1 reply; 6+ messages in thread
From: Mark Mitchell @ 2003-01-29 22:05 UTC (permalink / raw)
  To: gcc, gdr, rth


I'll try not to open such a huge can of worms this time. :-)

I'm trying to figure out how this code works.

      static const bool has_quiet_NaN
	= __builtin_nanf ("") != __builtin_nanf ("");

The constant-folding machinery seems to always consider this
expression to evaluate to true, due to this code in fold:

	  /* If either operand is a NaN, the result is false with two
	     exceptions: First, an NE_EXPR is true on NaNs, but that case
	     is already handled correctly since we will be inverting the
	     result for NE_EXPR.  Second, if we had inverted a LE_EXPR
	     or a GE_EXPR into a LT_EXPR, we must return true so that it
	     will be inverted into false.  */

	  if (REAL_VALUE_ISNAN (TREE_REAL_CST (arg0))
	      || REAL_VALUE_ISNAN (TREE_REAL_CST (arg1)))
	    t1 = build_int_2 (invert && code == LT_EXPR, 0);

So I'm trying to figure out why this isn't just:

  // We don't yet have a way of computing this correctly.
  static const bool has_quiet_NaN = true;

I'm sure I'm being dense; lay it on me.

Thanks,

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: One more limits question
  2003-01-29 22:05 One more limits question Mark Mitchell
@ 2003-01-29 22:10 ` Richard Henderson
  2003-01-29 22:13   ` Mark Mitchell
  0 siblings, 1 reply; 6+ messages in thread
From: Richard Henderson @ 2003-01-29 22:10 UTC (permalink / raw)
  To: Mark Mitchell; +Cc: gcc, gdr

On Wed, Jan 29, 2003 at 12:39:48PM -0800, Mark Mitchell wrote:
> The constant-folding machinery seems to always consider this
> expression to evaluate to true, due to this code in fold:

IIRC the plan was that __builtin_nan would produce some 
non-nan value on targets that don't support them.  I don't
remember off-hand where this happens.



r~

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: One more limits question
  2003-01-29 22:10 ` Richard Henderson
@ 2003-01-29 22:13   ` Mark Mitchell
  2003-01-29 22:16     ` Richard Henderson
  0 siblings, 1 reply; 6+ messages in thread
From: Mark Mitchell @ 2003-01-29 22:13 UTC (permalink / raw)
  To: Richard Henderson; +Cc: gcc, gdr



--On Wednesday, January 29, 2003 12:50:55 PM -0800 Richard Henderson 
<rth@redhat.com> wrote:

> On Wed, Jan 29, 2003 at 12:39:48PM -0800, Mark Mitchell wrote:
>> The constant-folding machinery seems to always consider this
>> expression to evaluate to true, due to this code in fold:
>
> IIRC the plan was that __builtin_nan would produce some
> non-nan value on targets that don't support them.  I don't
> remember off-hand where this happens.

fold_builtin_nan calls real_nan.  real_nan calls get_canonical_{q,s}nan
in this case.  Those functions seem to be unconditionalized in any
way.

I also see that we have -ftrapping-math, which sets __SUPPORT_SNAN__,
which may or may not be related.

We also have MODE_HAS_NANS, but not MODE_HAS_SIGNALING_NANS.

Do you know a non-signaling-Nan target I could build a cross-compiler
for, so that I could check out how this works?

Thanks,

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: One more limits question
  2003-01-29 22:13   ` Mark Mitchell
@ 2003-01-29 22:16     ` Richard Henderson
  2003-01-29 22:29       ` Mark Mitchell
  0 siblings, 1 reply; 6+ messages in thread
From: Richard Henderson @ 2003-01-29 22:16 UTC (permalink / raw)
  To: Mark Mitchell; +Cc: gcc, gdr

On Wed, Jan 29, 2003 at 01:03:05PM -0800, Mark Mitchell wrote:
> fold_builtin_nan calls real_nan.  real_nan calls get_canonical_{q,s}nan
> in this case.  Those functions seem to be unconditionalized in any way.

Perhaps a convert_to_move, or round_for_format smashes them?
Hmm.  I see only the encode/decode things do this.  Yes, 
there's a bug here...

> Do you know a non-signaling-Nan target I could build a cross-compiler
> for, so that I could check out how this works?

Well, vax-bsd doesn't support NaNs at all.  To my knowledge
there isn't a target that supports NaN but not SNaN.


r~

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: One more limits question
  2003-01-29 22:16     ` Richard Henderson
@ 2003-01-29 22:29       ` Mark Mitchell
  2003-01-30  0:54         ` Richard Henderson
  0 siblings, 1 reply; 6+ messages in thread
From: Mark Mitchell @ 2003-01-29 22:29 UTC (permalink / raw)
  To: Richard Henderson; +Cc: gcc, gdr



--On Wednesday, January 29, 2003 01:10:32 PM -0800 Richard Henderson 
<rth@redhat.com> wrote:

>
> Well, vax-bsd doesn't support NaNs at all.  To my knowledge
> there isn't a target that supports NaN but not SNaN.

All right.  I'm thinking I'll just use MODE_HAS_NANS, then.  That
sounds like it will be more right than what is there now, and
maybe always right in practice.  Sound OK?

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: One more limits question
  2003-01-29 22:29       ` Mark Mitchell
@ 2003-01-30  0:54         ` Richard Henderson
  0 siblings, 0 replies; 6+ messages in thread
From: Richard Henderson @ 2003-01-30  0:54 UTC (permalink / raw)
  To: Mark Mitchell; +Cc: gcc, gdr

On Wed, Jan 29, 2003 at 01:45:40PM -0800, Mark Mitchell wrote:
> All right.  I'm thinking I'll just use MODE_HAS_NANS, then.  That
> sounds like it will be more right than what is there now, and
> maybe always right in practice.  Sound OK?

Sure.


r~

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2003-01-29 22:50 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-01-29 22:05 One more limits question Mark Mitchell
2003-01-29 22:10 ` Richard Henderson
2003-01-29 22:13   ` Mark Mitchell
2003-01-29 22:16     ` Richard Henderson
2003-01-29 22:29       ` Mark Mitchell
2003-01-30  0:54         ` Richard Henderson

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).