Re: Optimization techniques and undefined behavior

From	David Brown <david.brown@hesbynett.no>
Newsgroups	comp.compilers
Subject	Re: Optimization techniques and undefined behavior
Date	2019-05-02 17:27 +0200
Organization	A noiseless patient Spider
Message-ID	<19-05-009@comp.compilers> (permalink)
References	(4 earlier) <19-04-039@comp.compilers> <19-04-042@comp.compilers> <19-04-045@comp.compilers> <19-04-049@comp.compilers> <19-05-003@comp.compilers>

Show all headers | View raw

On 01/05/2019 13:40, Bart wrote:
> On 30/04/2019 14:48, David Brown wrote:
>> On 29/04/2019 19:15, Bart wrote:
>>> On 29/04/2019 16:08, David Brown wrote:
>>>> On 29/04/2019 01:31, Bart wrote:
>>>
>>>>> then you don't want the compiler being clever about overflow.
>>>>
>>>> I /do/ want a result consistent with a single expression, or splitting
>>>> up the expression.
>>>
>>> Then the choice is between both ways giving you 1500000000, or both
>>> giving you -647483648.
>>
>> Let me repeat - I do not care what the results are here.  I don't care
>> if they are consistent with each other.  I don't care if they change
>> between runs of the compiler.  I don't care if the result is a pink
>> umbrella.
>
> So, there's a bug in the program, an inadvertent overflow. But rather
> than help in discovering that bug (such as giving the wrong results)
> gcc (and its clone Clang) conveniently pretend that such bugs cannot
> exist, and use that to give their code an unfair advantage:
>
>      #include <stdio.h>
>
>      int main(void) {
>          int x,y,z;
>
>          x=1000000000;
>          z=0;
>
>          for (int i=0; i<1000000000; ++i) {
>              y=x*3/3;
>              z+=y;
>              ++x;
>          }
>
>          printf("%d\n",x);
>          printf("%d\n",y);
>          printf("%d\n",z);
>      }
>
> Optimising compilers that don't take advantage of that undefined
> behaviour give timings here of 1.25 seconds (msvc) and 1.9 seconds
> (pelles c), with some taking much longer.
>
> The two that do, give timings of 0.22 seconds (gcc) and 0.05 seconds
> (clang).
>

Why are you worrying about timings of code with a bug?  If you have a
bug, you want the tools to try to help find the problem - and making it
an illegal operation rather than a legal nonsense operation will allow
tools to help.  Nobody cares how fast buggy code runs.

> However, there are a couple of problems: (1) they give different
> results; (2) they cheated by not doing a billion multiplies and divides.
>

It doesn't matter whether code is defined behaviour or not here - a good
compiler will do at least some of these calculations at compile time.  A
/really/ good compiler - better than gcc - would do it /all/ at compile
time.  Then it would give specific results for x, y and z in -fwrapv
mode, and a warning about overflow in normal UB mode.

And again, who cares about different results in different circumstances
from buggy code?

> Note this example also includes UB due to z+=y line, but I'm only
> interested in the bottom 32 bits, albeit signed, as a kind of checksum
> to compare with other compilers.
>

Then why not write correct code to do that?

> For that purpose, I need the final z value to be -101627306, which will
> match the same 32-bit arithmetic across languages** and in assembly.
>

It won't match many real languages - we have already seen that handling
of signed integer overflow varies a lot, with only a few doing two's
complement wrapping.

> I don't need it to be the mathematically correct 1499999999500000000,
> which seems to me what you'd like it to be. gcc/clang-O3 give me
> 1565039360 which is neither one nor the other.
>

I would not like it to be the mathematically correct answer - because
there is no defined correct answer for this C code.  If a particular C
implementation defines signed integer overflow in some way, then I
expect the answer to be consistent with that definition - if it does
not, then I don't care what the result is.

> -------------------------------
>
> (** This is the above program auto-translated from C to one of my
> languages, which is sort of interesting, this being a compiler group.
>

Sure, your language is absolutely on-topic here.

But if you want to translate your language to C, you need to translate
it to C - not to what you think C ought to be.  Given that you want your
own language to have wrapping semantics on integer overflow (hey, it's
your language - you define it in a crazy way if you want), then you
can't translate the source expressions into exactly the same thing in C.
  You need to write C code that means the same as the original.

If you didn't have such a knee-jerk allergy to the C preprocessor, I
could show you an efficient and safe way to do that.

If you are translating from C to your own language, then you can do it
directly - it is perfectly allowable to implement the undefined
behaviour by any definition that takes your fancy.

What does not make sense, of course, is to run tests in C with undefined
behaviour and expect consistent or testable results.  That is just daft.

> Normally this is just for to help in viewing torturous C source code as
> the C semantics are not translated. But tweaked with the int32() cast to
> match C's intermediate calculations (usually 64-bit here), this actually
> works:
>
>      import clib
>
>      global function main()int32 =
>          var int32 x
>          var int32 y
>          var int32 z
>          var int32 i
>
>          x := 1000000000
>          z := 0
>          i := 0
>          while i<1000000000 do
>              y := int32(x*3)/3
>              z +:= y
>              ++x
>              ++i
>          od
>          printf("%d\n",x)
>          printf("%d\n",y)
>          printf("%d\n",z)
>          return 0
>      end
>
>      proc start =
>          stop main()
>      end
>
> The results match those of the non-gcc/non-clang C compilers (apart from
> speed which is poor).)

Who cares?  The C code is buggy, so the results don't matter.

Back to comp.compilers | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Re: Optimization techniques David Brown <david.brown@hesbynett.no> - 2019-04-25 21:58 +0200
  Re: Optimization techniques Kaz Kylheku <847-115-0292@kylheku.com> - 2019-04-26 00:18 +0000
    Re: Optimization techniques David Brown <david.brown@hesbynett.no> - 2019-04-28 23:49 +0200
      Re: Optimization techniques and undefined behavior Bart <bc@freeuk.com> - 2019-04-29 00:31 +0100
        Re: Optimization techniques and undefined behavior David Brown <david.brown@hesbynett.no> - 2019-04-29 17:08 +0200
          Re: Optimization techniques and undefined behavior Christian Gollwitzer <auriocus@gmx.de> - 2019-04-29 18:10 +0200
            Re: Optimization techniques and undefined behavior David Brown <david.brown@hesbynett.no> - 2019-04-30 14:46 +0200
              Re: Optimization techniques and undefined behavior Bart <bc@freeuk.com> - 2019-05-01 13:53 +0100
                Re: Optimization techniques and undefined behavior Andy Walker <anw@cuboid.co.uk> - 2019-05-02 11:29 +0100
                Re: Optimization techniques and undefined behavior Bart <bc@freeuk.com> - 2019-05-03 00:48 +0100
                Re: Optimization techniques and undefined behavior Martin Ward <martin@gkc.org.uk> - 2019-05-03 10:52 +0100
                Re: Optimization techniques and undefined behavior George Neuner <gneuner2@comcast.net> - 2019-05-04 17:44 -0400
                Re: Bounds checking, Optimization techniques and undefined behavior George Neuner <gneuner2@comcast.net> - 2019-05-05 17:10 -0400
                Re: Optimization techniques and undefined behavior David Brown <david.brown@hesbynett.no> - 2019-05-06 08:14 +0200
                Re: Optimization techniques and undefined behavior Gene Wirchenko <genew@telus.net> - 2019-05-11 22:25 -0700
                Re: not a lot of memory, was Optimization techniques and undefined behavior Bart <bc@freeuk.com> - 2019-05-03 12:45 +0100
                Re: Optimization techniques and undefined behavior Andy Walker <anw@cuboid.co.uk> - 2019-05-03 13:29 +0100
                Re: Optimization techniques and undefined behavior Bart <bc@freeuk.com> - 2019-05-03 23:10 +0100
                Re: Optimization techniques and undefined behavior Andy Walker <anw@cuboid.co.uk> - 2019-05-04 10:45 +0100
                Re: Bounds checking, Optimization techniques and undefined behavior Bart <bc@freeuk.com> - 2019-05-05 11:14 +0100
                Re: Bounds checking, Optimization techniques and undefined behavior Hans-Peter Diettrich <DrDiettrich1@netscape.net> - 2019-05-05 20:44 +0200
                Re: Bounds checking, Optimization techniques and undefined behavior Hans-Peter Diettrich <DrDiettrich1@netscape.net> - 2019-05-06 10:15 +0200
                Re: Bounds checking, Optimization techniques and undefined behavior David Brown <david.brown@hesbynett.no> - 2019-05-07 11:04 +0200
                Re: Bounds checking, Optimization techniques and undefined behavior "Nuno Lopes" <nuno.lopes@ist.utl.pt> - 2019-05-07 22:38 +0100
                Re: Bounds checking, Optimization techniques and undefined behavior Bart <bc@freeuk.com> - 2019-05-08 01:14 +0100
                Re: Bounds checking, Optimization techniques and undefined behavior David Brown <david.brown@hesbynett.no> - 2019-05-08 09:55 +0200
                Re: Bounds checking, Optimization techniques and undefined behavior "Derek M. Jones" <derek@_NOSPAM_knosof.co.uk> - 2019-05-08 19:08 +0100
                Re: Bounds checking, Optimization techniques and undefined behavior Andy Walker <anw@cuboid.co.uk> - 2019-05-08 01:42 +0100
                Re: Bounds checking, Optimization techniques and undefined behavior David Brown <david.brown@hesbynett.no> - 2019-05-08 10:16 +0200
                Re: Bounds checking, Optimization techniques and undefined behavior Bart <bc@freeuk.com> - 2019-05-09 01:15 +0100
                Re: Bounds checking, Optimization techniques and undefined behavior David Brown <david.brown@hesbynett.no> - 2019-05-09 21:56 +0200
                Re: Bounds checking, Optimization techniques and undefined behavior David Brown <david.brown@hesbynett.no> - 2019-05-08 10:03 +0200
                Re: Bounds checking, Optimization techniques and undefined behavior David Brown <david.brown@hesbynett.no> - 2019-05-09 09:19 +0200
                Re: Bounds checking, Optimization techniques and undefined behavior Kaz Kylheku <847-115-0292@kylheku.com> - 2019-05-10 03:38 +0000
                Re: Bounds checking, Optimization techniques and undefined behavior Bart <bc@freeuk.com> - 2019-05-08 14:37 +0100
                Re: Bounds checking, Optimization techniques and undefined behavior Christopher F Clark <christopher.f.clark@compiler-resources.com> - 2019-05-06 05:05 -0400
                Re: Bounds checking, Optimization techniques and undefined behavior George Neuner <gneuner2@comcast.net> - 2019-05-05 17:38 -0400
                Re: Bounds checking, Optimization techniques and undefined behavior Bart <bc@freeuk.com> - 2019-05-06 13:07 +0100
                Re: Bounds checking, Optimization techniques and undefined behavior David Brown <david.brown@hesbynett.no> - 2019-05-07 14:01 +0200
                Re: Bounds checking, Optimization techniques and undefined behavior Andy Walker <anw@cuboid.co.uk> - 2019-05-06 01:15 +0100
                Re: Bounds checking, Optimization techniques and undefined behavior Andy Walker <anw@cuboid.co.uk> - 2019-05-06 14:40 +0100
                Re: Bounds checking, Optimization techniques and undefined behavior David Brown <david.brown@hesbynett.no> - 2019-05-07 15:05 +0200
                Re: Bounds checking, Optimization techniques and undefined behavior David Brown <david.brown@hesbynett.no> - 2019-05-08 10:18 +0200
                Re: Bounds checking, Optimization techniques and undefined behavior Jan Ziak <0xe2.0x9a.0x9b@gmail.com> - 2019-05-06 05:39 -0700
                Re: Bounds checking, Optimization techniques and undefined behavior David Brown <david.brown@hesbynett.no> - 2019-05-07 15:42 +0200
                Re: Bounds checking, Optimization techniques and undefined behavior David Brown <david.brown@hesbynett.no> - 2019-05-06 16:32 +0200
                Re: Optimization techniques and undefined behavior George Neuner <gneuner2@comcast.net> - 2019-05-04 17:59 -0400
                Re: Optimization techniques and undefined behavior David Brown <david.brown@hesbynett.no> - 2019-05-02 16:51 +0200
                Re: Optimization techniques and undefined behavior Bart <bc@freeuk.com> - 2019-05-02 20:04 +0100
                Re: Optimization techniques and undefined behavior David Brown <david.brown@hesbynett.no> - 2019-05-03 17:23 +0200
                Re: Optimization techniques and undefined behavior Bart <bc@freeuk.com> - 2019-05-03 21:10 +0100
                Re: Optimization techniques and undefined behavior Martin Ward <martin@gkc.org.uk> - 2019-05-06 13:25 +0100
                Re: Optimization techniques and undefined behavior "Derek M. Jones" <derek@_NOSPAM_knosof.co.uk> - 2019-05-06 16:32 +0100
                Re: Optimization techniques and undefined behavior David Brown <david.brown@hesbynett.no> - 2019-05-07 16:03 +0200
                Re: Optimization techniques and undefined behavior Martin Ward <martin@gkc.org.uk> - 2019-05-08 13:16 +0100
                Re: Optimization techniques and undefined behavior George Neuner <gneuner2@comcast.net> - 2019-05-08 15:13 -0400
                Re: Optimization techniques and undefined behavior "Robin Vowels" <robin51@dodo.com.au> - 2019-05-07 01:22 +1000
                Re: Optimization techniques and undefined behavior David Brown <david.brown@hesbynett.no> - 2019-05-07 16:05 +0200
                Re: Optimization techniques and undefined behavior Christian Gollwitzer <auriocus@gmx.de> - 2019-05-02 22:22 +0200
          Re: Optimization techniques and undefined behavior Bart <bc@freeuk.com> - 2019-04-29 18:15 +0100
            Re: Optimization techniques and undefined behavior David Brown <david.brown@hesbynett.no> - 2019-04-30 15:48 +0200
              Re: Optimization techniques and undefined behavior Bart <bc@freeuk.com> - 2019-05-01 12:40 +0100
                Re: Optimization techniques and undefined behavior David Brown <david.brown@hesbynett.no> - 2019-05-02 17:27 +0200
                Re: Optimization techniques and undefined behavior Bart <bc@freeuk.com> - 2019-05-02 18:59 +0100
                Re: Optimization techniques and undefined behavior David Brown <david.brown@hesbynett.no> - 2019-05-07 16:16 +0200
              Re: Optimization techniques and undefined behavior Martin Ward <martin@gkc.org.uk> - 2019-05-02 14:54 +0100
      Re: Optimization techniques and runtime checks Hans-Peter Diettrich <DrDiettrich1@netscape.net> - 2019-04-29 22:36 +0200
        Re: Optimization techniques and runtime checks David Brown <david.brown@hesbynett.no> - 2019-05-07 16:29 +0200
          Re: Optimization techniques and runtime checks Hans-Peter Diettrich <DrDiettrich1@netscape.net> - 2019-05-08 02:27 +0200
            Re: Optimization techniques and runtime checks David Brown <david.brown@hesbynett.no> - 2019-05-08 10:31 +0200
              Re: Optimization techniques and runtime checks Hans-Peter Diettrich <DrDiettrich1@netscape.net> - 2019-05-08 22:50 +0200
              Re: Optimization techniques and runtime checks "Robin Vowels" <robin51@dodo.com.au> - 2019-05-11 19:26 +1000
              Re: Optimization techniques and runtime checks Gene Wirchenko <genew@telus.net> - 2019-05-11 22:43 -0700
                Re: Optimization techniques and runtime checks David Brown <david.brown@hesbynett.no> - 2019-05-12 20:17 +0200
          Re: Optimization techniques and runtime checks Bart <bc@freeuk.com> - 2019-05-08 14:58 +0100
            Re: Optimization techniques and runtime checks David Brown <david.brown@hesbynett.no> - 2019-05-08 23:02 +0200
              Re: Optimization techniques and runtime checks Bart <bc@freeuk.com> - 2019-05-09 18:28 +0100
                Re: Optimization techniques and runtime checks David Brown <david.brown@hesbynett.no> - 2019-05-09 22:07 +0200
      Re: Optimization techniques Gene Wirchenko <genew@telus.net> - 2019-04-30 18:24 -0700
        Re: Optimization techniques David Brown <david.brown@hesbynett.no> - 2019-05-01 09:20 +0200
          Re: Optimization techniques Kaz Kylheku <847-115-0292@kylheku.com> - 2019-05-02 17:40 +0000
          Re: Optimization techniques and error detection Gene Wirchenko <genew@telus.net> - 2019-05-03 10:16 -0700
          Re: Optimization techniques "Robin Vowels" <robin51@dodo.com.au> - 2019-05-07 01:42 +1000
  Re: Optimization techniques Kaz Kylheku <847-115-0292@kylheku.com> - 2019-04-26 02:26 +0000
    Re: Optimization techniques and undefined behavior David Brown <david.brown@hesbynett.no> - 2019-04-29 00:12 +0200
      Re: Optimization techniques and undefined behavior Kaz Kylheku <847-115-0292@kylheku.com> - 2019-05-02 17:18 +0000
        Re: Optimization techniques and undefined behavior David Brown <david.brown@hesbynett.no> - 2019-05-07 16:38 +0200

csiph-web