> 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
> ||
Looks like valgrind catches some things around here:
==115793== Conditional jump or move depends on uninitialised value(s)
==115793==at 0x402671: main (t-sqrlo.c:106)
==115793==
==115793== Conditional jump or move depends on uninitialised value(s)
==115793==at 0x40268A: main (t-sqrlo.c:107
UBSan doesn't cover this sort of thing - MSan is the sanitizer for catching
uninitialized values. (MSan is, unfortunately, a bit more finicky to use
because the whole program (including the standard library) must be compiled
with the feature enabled for it to work correctly - I don't have an MSan
e
I'm a fan of GMP, so I'll jump :-) Regardless of whether this is a bug
in LLVM or GMP, it would be satisfying to get to the root of the
problem.
Bisecting over LLVM shows that GMP's mpn test t-sqrlo starts failing
on my x86_64 Linux machine after this commit
at 8ee477a2ab6 "[InstSimplify] Simpli
> 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 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:
>> >> >
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
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:
> >> >
> >> >> Right, but that is something one would avoid when computi
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 - but that's sort of what the whole discussion is
> resolving around:
On Thu, Oct 31, 2019 at 2:30 AM Hans Åberg wrote:
>
> > 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 sta
On Wed, Oct 30, 2019 at 5:36 PM Hans Åberg wrote:
>
>
> > 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 numb
On Wed, Oct 30, 2019 at 4:25 PM Hans Åberg wrote:
>
> > 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 d
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 (especially floating point) there's
loads of room for valid but diffe
I ran the test & understand it a bit better now - so the abort is part of
the code, when the test fails, the test harness uses abort to fail.
So this isn't "clang causes abort" (it didn't select a bad instruction,
etc) this is "clang causes test failure" - this could be any number of
things in ter
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
On Fri, Oct 25, 2019 at 5:55 PM Matthew Fernandez <
matthew.fernan...@gmail.com> wrote:
> Hans, it’s challenging to give sensible advice/guesses without knowing
> which test is failing. Maybe I missed this information in the replies
> (please CC the list if you want follow up answers from more tha
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
Hans, it’s challenging to give sensible advice/guesses without knowing which
test is failing. Maybe I missed this information in the replies (please CC the
list if you want follow up answers from more than just David). I am not a GMP
developer, but note that GMP is regularly tested with ubsan an
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 work to use)
On Fri, Oct 25, 2019 at 3:16 PM Hans Åberg wrote:
> That is the reason I tried the UBSan, but as it changes optimization, it
> does not wrok.
>
>
> > On 26
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
jump on reproducing and reducing misbehaving programs, because on the odds,
it's not a bug in the compiler)
On Fri, Oct 25, 2019 at 3:12 PM Hans Åberg
It's hard to know if it's the compiler's fault without a test case - due to
the nature of undefined behavior and other things (implementation defined
behavior and unspecified behavior) in C++, that the program behaves as
expected with another compiler or another set of flags doesn't give a
strong i
It's pretty hard to conclude whether it's a bug in your code or in the
compiler, or both, without narrowing down a test case.
On Fri, Oct 25, 2019 at 2:01 PM Hans Åberg wrote:
> So then there probably is an issue with the optimization.
>
> Just run 'gmp-6.1.2’ with MacPorts clang 9.0.0; I got:
>
Hard to know what might be happening - what sort of failure you're seeing,
etc. Perhaps UBSan is stabilizing/changing unspecified rather than
undefined behavior - or the test is failing due to some undefined behavior
that UBSan doesn't catch, etc.
On Fri, Oct 25, 2019 at 11:25 AM Hans Åberg wrote
UBSan adds code to check things, it necessarily changes optimizations by
having those checks in. It shouldn't affect the behavior of programs that
don't exhibit UB (but I imagine it could affect the behavior of programs
relying on specific IB (Implementation Defined Behavior)).
Reducing a test ca
You mentioned "the check gives one error" - which check?
On Fri, Oct 25, 2019 at 8:21 AM Hans Åberg via cfe-users <
cfe-users@lists.llvm.org> wrote:
> [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 tur
[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
37 matches
Mail list logo
