'Re: [Haskell-cafe] rounding and undefined behavior'

[prev in list] [next in list] [prev in thread] [next in thread] 

List:       haskell-cafe
Subject:    Re: [Haskell-cafe] rounding and undefined behavior
From:       Neil Mayhew <neil_mayhew () users ! sourceforge ! net>
Date:       2019-02-28 1:06:05
Message-ID: fa878427-7fdc-a0ee-6fec-73b3f048188e () users ! sourceforge ! net
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]

Hi Matt,

On 2019-02-27 4:31 PM, Matt Peddie wrote:
> For me [gcc] returns 32767 if I enable optimizations and 0 if I don't.

Yes, I get 0 without optimizations. Looking at the generated assembly 
(with gcc -S) I can see that the non-optimized code is converting the 
double to a 32-bit integer using a hardware instruction (cvttsd2si) but 
in the optimized case it's using a precomputed value. It's strange that 
the precomputed value doesn't match, but as Ian said, all bets are off 
anyway.

According to one authority 
<https://www.felixcloutier.com/x86/cvttsd2si>, the conversion produces 
the 32-bit value 0x80000000. When truncated to int16_t this is 0.

> Clang returns 0 independent of any flag changes I tried.

Clang's code uses a precomputed value even without optimization.

Looking at GHC's generated core, it converts the Double to an Int and 
then narrows down to Int16 after that.

—Neil

[Attachment #5 (text/html)]

<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">Hi Matt,<br>
      <br>
      On 2019-02-27 4:31 PM, Matt Peddie wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAAwKdvhkGJ1hd7TXQZYBjg1VUQ-J0ch26MhWTUsy6p1TL1YSzw@mail.gmail.com">For
      me [gcc] returns 32767 if I enable optimizations and 0 if I don't.</blockquote>
    <br>
    Yes, I get 0 without optimizations. Looking at the generated
    assembly (with gcc -S) I can see that the non-optimized code is
    converting the double to a 32-bit integer using a hardware
    instruction (cvttsd2si) but in the optimized case it's using a
    precomputed value. It's strange that the precomputed value doesn't
    match, but as Ian said, all bets are off anyway.<br>
    <br>
    According to <a moz-do-not-send="true"
      href="https://www.felixcloutier.com/x86/cvttsd2si">one authority</a>,
    the conversion produces the 32-bit value 0x80000000. When truncated
    to <tt>int16_t</tt> this is 0.<br>
    <br>
    <blockquote type="cite"
cite="mid:CAAwKdvhkGJ1hd7TXQZYBjg1VUQ-J0ch26MhWTUsy6p1TL1YSzw@mail.gmail.com">Clang
      returns 0 independent of any flag changes I tried.</blockquote>
    <br>
    Clang's code uses a precomputed value even without optimization.<br>
    <br>
    Looking at GHC's generated core, it converts the Double to an Int
    and then narrows down to Int16 after that.<br>
    <br>
    —Neil<br>
  </body>
</html>

[Attachment #6 (text/plain)]

_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.

[prev in list] [next in list] [prev in thread] [next in thread] 