Re: The bug

From	Keith Thompson <kst-u@mib.org>
Newsgroups	comp.lang.c
Subject	Re: The bug
Date	2018-02-08 14:15 -0800
Organization	None to speak of
Message-ID	<lny3k3w2k5.fsf@kst-u.example.com> (permalink)
References	<p5ignt$45g$1@dont-email.me>

Show all headers | View raw

jacobnavia <jacob@jacob.remcomp.fr> writes:
[...]

> Following the lead that David Brown told me, I noticed that if you
> compile this with
> -fwrapv
> the bug disappears.

That's not surprising; see below.

> What is happening in line 23?
>
> 23             lp = ((__int128)(*p)) * (*q);
>
> This specifies that:
> 1) The 64 bit unsigned value stored at the location pointed to by "p" 
> should be converted into a signed 128 bit value.
> 2) That value should be multiplied in 128 bit with the unsigned 64 bit 
> value pointed to by "q".
> 3) The result of the 128 bit multiplication should be stored in the 
> unsigned 128 bit number "lp".
> 4) Since the rank of a 128 bit integer is higher than the rank of the 64 
> bit value, the multiplication is a signed multiplication.
>
> Where is here an undefined behavior?

I'll assume that __int128 is treated as a signed 128-bit integer type.
gcc doesn't quite treat it that way, but for these purposes I think the
assumption is valid and consistent with the observed behavior.

In the left operand, *p is a 64-bit unsigned integer (unsigned long
long), converted to a 128-bit signed type.  The right operand, which is
also of type unsigned long long, is implicitly converted to the same
128-bit signed type.

If the result of the multiplication exceeds 2**127-1, that's an overflow
and the behavior is undefined.  I added some printf calls to your
program, and you are getting results that exceed 2**127-1.  gcc's
optimization assumes that the behavior is defined, causing unexpected
results.

-fwrapv causes gcc to define the behavior of signed overflow.

[...]
> Is this a bug in the optimizer?
> Or I am doing some "UB"?

The latter.

(Speaking of bugs, I recently emailed you a bug report for lcc-win64.
Did you receive it?  Should I post it to comp.compilers.lcc?)

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

Thread

The bug jacobnavia <jacob@jacob.remcomp.fr> - 2018-02-08 22:50 +0100
  Re: The bug Keith Thompson <kst-u@mib.org> - 2018-02-08 14:15 -0800
  Re: The bug jacobnavia <jacob@jacob.remcomp.fr> - 2018-02-13 10:25 +0100
    Re: The bug David Brown <david.brown@hesbynett.no> - 2018-02-13 10:51 +0100
      Re: The bug jacobnavia <jacob@jacob.remcomp.fr> - 2018-02-13 11:19 +0100
        Re: The bug David Brown <david.brown@hesbynett.no> - 2018-02-13 12:23 +0100
      Re: The bug Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-02-13 08:19 -0800
        Re: The bug David Brown <david.brown@hesbynett.no> - 2018-02-15 10:52 +0100
    Re: The bug Noob <root@127.0.0.1> - 2018-02-13 16:19 +0100
      Re: The bug Tim Rentsch <txr@alumni.caltech.edu> - 2018-02-19 12:11 -0800
        Re: The bug supercat@casperkitty.com - 2018-02-19 16:31 -0800
          Re: The bug Tim Rentsch <txr@alumni.caltech.edu> - 2018-02-21 23:03 -0800
            Re: The bug supercat@casperkitty.com - 2018-02-23 16:40 -0800
              Re: The bug Richard Damon <Richard@Damon-Family.org> - 2018-02-24 05:57 -0500
              Re: The bug Tim Rentsch <txr@alumni.caltech.edu> - 2018-02-24 13:11 -0800
                Re: The bug Anton Shepelev <anton.txt@gmail.com> - 2018-02-25 00:15 +0300
    Re: The bug Keith Thompson <kst-u@mib.org> - 2018-02-13 11:44 -0800
      Re: The bug asetofsymbols@gmail.com - 2018-02-13 12:13 -0800
      Re: The bug Noob <root@127.0.0.1> - 2018-02-15 09:45 +0100

csiph-web