> On 7 Nov 2019, at 15:24, Hans Wennborg wrote:
>
> Looking at LLVM's -print-after-all shows a diff after GVN which seems
> to come from this if-statement in tests/mpn/t-sqrlo.c:
>
> if (pp[-1] != p_before || pp[n] != p_after
> || scratch[-1] != s_before || scratch[itch] != s_after
> ||
> On 2 Nov 2019, at 02:36, Matthew Fernandez
> wrote:
>
>> Both GCC and Clang can be conveniently installed using MacPorts. The Apple
>> inhouse clang is weird.
>
> I haven’t followed the rest of this thread closely, but do you have a
> reference for the GMP developers abandoning Clang on ma
> 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:
>> >> >
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
The GMP developers felt it was a compiler bug, so I think I will leave it at
that. But thanks for the tips.
> On 26 Oct 2019, at 00:32, David Blaikie wrote:
>
> UBSan doesn't catch everything - you could also try ASan and/or valgrind,
> etc. (MSan if you want, but that's a bit fussier/more wo
So then there probably is an issue with the optimization.
Just run 'gmp-6.1.2’ with MacPorts clang 9.0.0; I got:
../../../gmp-6.1.2/test-driver: line 107: 70037 Abort trap: 6 "$@" >
$log_file 2>&1
FAIL: t-sqrlo
With Apple clang 11.0.0 (clang-1100.0.33.8), I got another ‘make check’ err
That is the reason I tried the UBSan, but as it changes optimization, it does
not wrok.
> On 26 Oct 2019, at 00:14, David Blaikie wrote:
>
> Yeah, coming across compiler bugs does happen - but more often it's bugs in
> input programs. (one of the reasons compiler engineers aren't likely to ju
It is just an abort trap. The ‘make check' also passes if turning off
optimization. I would have expected UBSan to not change anything in
optimization, but merely report the issues it finds. Apparently it finds
nothing, so it may suggest a compiler bug.
> On 25 Oct 2019, at 22:34, David Blaiki
It is not my code, it belongs to gmp-6.1.2, I merely happened to come a cross
it. It passes on gcc9, so there is something that clang9 does.
> On 25 Oct 2019, at 23:15, David Blaikie wrote:
>
> It's pretty hard to conclude whether it's a bug in your code or in the
> compiler, or both, without
The sources are available at [1]; it is written in C, not C++. I was was hoping
that that something like UBSan would shed light on it, but the original
question is answered: it changes optimization. The GMP developers say that they
have caught some compiler bugs, but that is hard to do and time
The ‘make check’ of GMP 6.1.2. One of the tests fail, but with any UBSan
‘undefined’ option enabled (in ‘configure’), none.
> On 25 Oct 2019, at 18:35, David Blaikie wrote:
>
> You mentioned "the check gives one error" - which check?
___
cfe-users ma
[Please cc me, as I am not on the list.]
When compiling GMP 6.1.2 with MacPorts clang9 on MacOS 10.15, the check gives
one error, but if turning on UBSan ‘undefined’, it passes without a report.
Should it not report what it thinks is the issue?
___
c
17 matches
Mail list logo
