> On Oct 31, 2019, at 14:30, Hans Åberg via cfe-users
> wrote:
>
>>
>> On 31 Oct 2019, at 22:07, David Blaikie wrote:
>>
>>> On Thu, Oct 31, 2019 at 1:51 PM Hans Åberg wrote:
>>>
On 31 Oct 2019, at 21:40, David Blaikie wrote:
Such that it's not practical for the compiler d
> On 30 Oct 2019, at 23:50, David Blaikie wrote:
>
>> On Wed, Oct 30, 2019 at 2:29 PM Hans Åberg wrote:
>> Indeed, very hard to figure out. If it is some hidden undefined behavior
>> causing it, the UBSan should have caught it, but it does not.
>>
> Right - but especially with numerics (espec
> On 31 Oct 2019, at 22:07, David Blaikie wrote:
>
>> On Thu, Oct 31, 2019 at 1:51 PM Hans Åberg wrote:
>>
>> > On 31 Oct 2019, at 21:40, David Blaikie wrote:
>> >
>> >> On Thu, Oct 31, 2019 at 12:00 PM Hans Åberg wrote:
>> >>
>> >> > On 31 Oct 2019, at 18:40, David Blaikie wrote:
>> >> >
If I build clang-format from tip of master and run it
using this .clang-format file
AllowShortIfStatementsOnASingleLine: Always
it will change this single line if statement
if (x) { x++; }
into this three line if statement
if (x) {
x++;
}
How do I keep it as one line?
If I delete
Indeed, very hard to figure out. If it is some hidden undefined behavior
causing it, the UBSan should have caught it, but it does not. The link that
Matthew gave says that the GMP developers experienced a number of such issues
with Clang. One can though turn off the optimizer, and the tests pass
> On 31 Oct 2019, at 01:53, David Blaikie wrote:
>
>> Yes, but assuming that the GMP adheres to the C standard, there should be no
>> difference in the arithmetical values produced.
>
> Not necessarily - C (well, I don't know the C standard as well as I know the
> C++ standard, admittedly) do
> On 31 Oct 2019, at 00:28, David Blaikie wrote:
>
>
>
> On Wed, Oct 30, 2019 at 4:25 PM Hans Åberg wrote:
>
>> I believe that GMP is just using integer types, and then uses that to make
>> multiprecision integers, rational numbers, and floating point numbers. At
>> least MPFR uses only t
> On 31 Oct 2019, at 18:40, David Blaikie wrote:
>
>> Right, but that is something one would avoid when computing arithmetical
>> results.
>
> One would try to, yes - but that's sort of what the whole discussion is
> resolving around: Is the code correct? I don't know. I wouldn't assume it is
> On 31 Oct 2019, at 21:40, David Blaikie wrote:
>
>> On Thu, Oct 31, 2019 at 12:00 PM Hans Åberg wrote:
>>
>> > On 31 Oct 2019, at 18:40, David Blaikie wrote:
>> >
>> >> Right, but that is something one would avoid when computing arithmetical
>> >> results.
>> >
>> > One would try to, yes
