Re: [cfe-users] Clang9 UBSan and GMP
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] SimplifyICmpInst - icmp eq/ne %X,
undef -> undef"
(My bisection command was
ninja -C build.release -j900 clang && ( cd /tmp/gmp-6.1.2/build &&
make clean && CC=/work/llvm.monorepo/build.release/bin/clang
../configure && make -j50 && make check )
)
Comparing the object files of GMP builds using that LLVM version and
the one right before, shows a diff in ./tests/mpn/t-sqrlo.o
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
|| mpn_cmp (refp, pp, n) != 0)
{
It looks like the "scratch[-1] != s_before" expression was previously
folded to false, but now it's folded to undef (and the branch ends up
going the other way). That matches the commit message from the
bisection.
It seems the memory pointed to by scratch is never initialized, so the
code is reading uninitialized memory. I'm not a language lawyer, but
it smells like Undefined Behaviour.
The source has a commented out block that I guess would initialize
scratch. Maybe the fix is to reinstate that code, or also comment out
or remove the code that accesses scratch?
Thanks,
Hans
On Sat, Oct 26, 2019 at 12:14 AM David Blaikie via cfe-users
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 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 wrote:
>>
>> 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 consuming.
>>
>> 1. https://gmplib.org
>>
>>
>> > On 25 Oct 2019, at 23:38, David Blaikie wrote:
>> >
>> > 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 indication as to where the problem is (in the code, in one
>> > of the compilers, etc).
___
cfe-users mailing list
cfe-users@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
Re: [cfe-users] Clang9 UBSan and GMP
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
enabled environment to test whether it would've caught this bug or not)
On Thu, Nov 7, 2019 at 9:15 AM Hans Åberg wrote:
>
> > 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
> > || mpn_cmp (refp, pp, n) != 0)
> > {
> >
> > It looks like the "scratch[-1] != s_before" expression was previously
> > folded to false, but now it's folded to undef (and the branch ends up
> > going the other way). That matches the commit message from the
> > bisection.
>
> GMP bugs may be reported to their bug list, and the UBSan might be
> strengthened to capture this.
>
>
>
___
cfe-users mailing list
cfe-users@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
Re: [cfe-users] Clang9 UBSan and GMP
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)
==115793==
On Thu, Nov 7, 2019 at 9:42 AM David Blaikie wrote:
> 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 enabled environment to test whether it would've caught this bug or
> not)
>
> On Thu, Nov 7, 2019 at 9:15 AM Hans Åberg wrote:
>
>>
>> > 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
>> > || mpn_cmp (refp, pp, n) != 0)
>> > {
>> >
>> > It looks like the "scratch[-1] != s_before" expression was previously
>> > folded to false, but now it's folded to undef (and the branch ends up
>> > going the other way). That matches the commit message from the
>> > bisection.
>>
>> GMP bugs may be reported to their bug list, and the UBSan might be
>> strengthened to capture this.
>>
>>
>>
___
cfe-users mailing list
cfe-users@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
[cfe-users] error: inline function '_BitScanForward' is not defined
Hi Team, While compiling my source cpp file which is including intrin.h, clang is throwing the following error error: inline function '_BitScanForward' is not defined [-Werror,-Wundefined -inline] _BitScanForward ( I checked clang headers for definition but in clang intrin.h header file its just declared as inline but not defined. Ref: https://github.com/llvm-mirror/clang/blob/master/lib/Headers/intrin.h#L146 Ideally inline functions has to be defined in header file itself right? But why is clang not defining function definitions in the header file? Is there any specific reason for doing so? Thanks, Pendyala ___ cfe-users mailing list cfe-users@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
