On Wed, 18 Feb 2015, Kenneth Zadeck wrote:
> > I think the norm is dynamic, because that's what was in IEEE 754-1985,
> > with static rounding added more recently on some processors, because of
> > IEEE 754-2008. (There are other variants - IA64 having multiple dynamic
> > rounding mode regist
> On Feb 18, 2015, at 3:23 AM, Joseph Myers wrote:
>
>> On Tue, 17 Feb 2015, Kenneth Zadeck wrote:
>>
>> The fp exceptions raise some very tricky issues with respect to gcc and
>> optimization. On many machines, noisy does not mean to throw an
>> exception, it means that you set a bit and
On Tue, 17 Feb 2015, Kenneth Zadeck wrote:
> The fp exceptions raise some very tricky issues with respect to gcc and
> optimization. On many machines, noisy does not mean to throw an
> exception, it means that you set a bit and then check later. If you try
> to model this kind of behavior in
Joseph Myers writes:
> For example, on MIPS the C.cond.fmt instruction has a four-bit condition
> field: "In the cond field of the instruction: cond 2..1 specify the nature
> of the comparison (equals, less than, and so on); cond 0 specifies whether
> the comparison is ordered or unordered, i.
> On Feb 17, 2015, at 6:01 PM, Joseph Myers wrote:
>
>> On Tue, 17 Feb 2015, Kenneth Zadeck wrote:
>>
>>> On 02/17/2015 07:05 AM, Joseph Myers wrote:
On Tue, 17 Feb 2015, Richard Earnshaw wrote:
So the problem we have today is the compiler has no way to distinguish
betwe
On Tue, 17 Feb 2015, Kenneth Zadeck wrote:
> On 02/17/2015 07:05 AM, Joseph Myers wrote:
> > On Tue, 17 Feb 2015, Richard Earnshaw wrote:
> >
> > > So the problem we have today is the compiler has no way to distinguish
> > > between, say, < and __builtin_isless. According to Annex F (c99) the
>
On 02/17/2015 07:05 AM, Joseph Myers wrote:
On Tue, 17 Feb 2015, Richard Earnshaw wrote:
So the problem we have today is the compiler has no way to distinguish
between, say, < and __builtin_isless. According to Annex F (c99) the
former should be signalling while the latter quiet.
We do have
On Tue, 17 Feb 2015, Richard Earnshaw wrote:
> So the problem we have today is the compiler has no way to distinguish
> between, say, < and __builtin_isless. According to Annex F (c99) the
> former should be signalling while the latter quiet.
We do have a way: < is LT and __builtin_isless is !UN
On 15/02/15 16:08, Kenneth Zadeck wrote:
>
> On 02/14/2015 03:26 PM, Paolo Bonzini wrote:
>>
>> On 10/02/2015 22:46, Joseph Myers wrote:
>>> It may make sense to define LTGT as exactly !UNEQ, and so quiet, but the
>>> choice of definition is a matter of what's convenient for the
>>> implementation
On 02/14/2015 03:26 PM, Paolo Bonzini wrote:
On 10/02/2015 22:46, Joseph Myers wrote:
It may make sense to define LTGT as exactly !UNEQ, and so quiet, but the
choice of definition is a matter of what's convenient for the
implementation (and which choice you make determines which existing code
On 10/02/2015 22:46, Joseph Myers wrote:
> It may make sense to define LTGT as exactly !UNEQ, and so quiet, but the
> choice of definition is a matter of what's convenient for the
> implementation (and which choice you make determines which existing code
> in GCC should be considered incorrect
I vote for quiet.For three reasons:
1) it matches the expectation of what programmers expect. I view
people who do floating point as falling into two categories:
a) people who wish that there were no such thing as nans. These
people are happy to write programs with just < > <= >= ==
> But maybe more code treats LTGT as a signaling operation than otherwise, in
> accordance with the original intent, and so that's the most appropriate way
> to document it (with !UNEQ being the representation of the corresponding
> quiet operation).
SPARC supports all codes and treats everything
On Mon, 9 Feb 2015, Kenneth Zadeck wrote:
> > I don't think it's useful to have the trapping semantics unspecified for a
> > comparison operation like that. So the question is what's most useful for
> > LTGT and LTGT_EXPR to do (presumably they should do the same thing). Lots
> > of existing cod
On 02/09/2015 06:24 PM, Joseph Myers wrote:
On Mon, 9 Feb 2015, Kenneth Zadeck wrote:
@findex ge
@cindex greater than
@@ -2603,6 +2618,10 @@ Like @code{gt} and @code{gtu} but test f
@item (ge:@var{m} @var{x} @var{y})
@itemx (geu:@var{m} @var{x} @var{y})
Like @code{gt} and @code{gtu} b
On 02/09/2015 06:26 PM, Richard Henderson wrote:
On 02/09/2015 11:10 AM, Kenneth Zadeck wrote:
+@table @code
+@findex ltgt
+@cindex less than or greater than
+@item (ltgt:@var{m} @var{x} @var{y})
+@code{STORE_FLAG_VALUE} if the values represented by @var{x} and
+@var{y} are less, or greater, oth
On 02/09/2015 11:10 AM, Kenneth Zadeck wrote:
> +@table @code
> +@findex ltgt
> +@cindex less than or greater than
> +@item (ltgt:@var{m} @var{x} @var{y})
> +@code{STORE_FLAG_VALUE} if the values represented by @var{x} and
> +@var{y} are less, or greater, otherwise 0. This is a quiet operation
> +
On Mon, 9 Feb 2015, Kenneth Zadeck wrote:
> @findex ge
> @cindex greater than
> @@ -2603,6 +2618,10 @@ Like @code{gt} and @code{gtu} but test f
> @item (ge:@var{m} @var{x} @var{y})
> @itemx (geu:@var{m} @var{x} @var{y})
> Like @code{gt} and @code{gtu} but test for ``greater than or equal''.
>
Before I commit this, or do the corresponding tree level patch, I would
like this to be looked at by the FP people. I am guessing at some of
this, other parts i gleaned from various standards docs and an irc
conversation with Joseph. This should have been documented when it was
put into the
19 matches
Mail list logo
