Bjarne Stroustrup’s Plan for Bringing Safety to C++ (The New Stack)

Posted Nov 9, 2023 23:15 UTC (Thu) by foom (subscriber, #14868)
In reply to: Bjarne Stroustrup’s Plan for Bringing Safety to C++ (The New Stack) by farnz
Parent article: Bjarne Stroustrup’s Plan for Bringing Safety to C++ (The New Stack)

> And note that, by the nature of -fwrapv, every case where it regresses performance is one where the source code is already buggy

Nope.

The flag only affects the _results_ if the program previously exhibited UB, but, it removes flexibility from the optimizer by requiring the result be wrapped. This may require additional conditions or less efficient code. If the more-optimal version didn't produce the correct result when the value wrapped, it cannot be used any more.

Bjarne Stroustrup’s Plan for Bringing Safety to C++ (The New Stack)

Posted Nov 10, 2023 13:55 UTC (Fri) by Wol (subscriber, #4433) [Link] (4 responses)

Which is why my take is that - ON A 2S COMPLEMENT PROCESSOR - -fwrapv should be defined as the default. So by default, you get the expected behaviour.

Then they can compile SPECInt with a flag that switches off fwrapv to give the old behaviour and say "you want speed? Here you are! But it's safe by default".

So UB has now become hardware- or implementation-defined behaviour but the old behaviour is still available if you want it.

Cheers,
Wol

Bjarne Stroustrup’s Plan for Bringing Safety to C++ (The New Stack)

Posted Nov 10, 2023 14:00 UTC (Fri) by farnz (subscriber, #17727) [Link]

Now go and convince the Clang, GCC, Fedora or Debian maintainers that this should be the default state. That's the hard part - getting anyone whose decisions will influence the C standards body to declare that they want less UB, even at the expense of a few % of speed on some benchmarks.

Bjarne Stroustrup’s Plan for Bringing Safety to C++ (The New Stack)

Posted Nov 13, 2023 13:13 UTC (Mon) by paulj (subscriber, #341) [Link] (2 responses)

Is there anything that's been produced in the last 10 years that is /not/ twos-complement? (If "nothing" - in the last 20?)

Bjarne Stroustrup’s Plan for Bringing Safety to C++ (The New Stack)

Posted Nov 13, 2023 17:14 UTC (Mon) by kreijack (guest, #43513) [Link]

> Is there anything that's been produced in the last 10 years that is /not/ twos-complement? (If "nothing" - in the last 20?)

My understanding is that the ISO c++20 standard already mandates the two's complement:

If you look at https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2218.htm, you can find more information; even an analysis about which processor is/was not "two's complement".

And also it seems that C23 also is following the same path.

Anyway I think that the right question is "which architecture" supported by GCC (or CLANG...) is/isn't two's complement.

https://en.wikipedia.org/wiki/C23_(C_standard_revision)#cite_note-N2412-62
https://en.wikipedia.org/wiki/C%2B%2B20#cite_note-32
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/...

Bjarne Stroustrup’s Plan for Bringing Safety to C++ (The New Stack)

Posted Nov 14, 2023 14:30 UTC (Tue) by mathstuf (subscriber, #69389) [Link]

For "basic" operations, probably very few. What about vectorized operations? Are they consistently twos-complement? How about GPU and other specialized hardware?