[llvm-commits] [compiler-rt] r165913 - /compiler-rt/trunk/lib/ubsan/ubsan_value.cc

David Blaikie dblaikie at gmail.com
Thu Nov 29 14:47:31 PST 2012


On Thu, Nov 29, 2012 at 2:42 PM, Richard Smith <richard at metafoo.co.uk> wrote:
> On Thu, Nov 29, 2012 at 1:53 PM, David Blaikie <dblaikie at gmail.com> wrote:
>>
>> On Sun, Oct 14, 2012 at 4:53 PM, Richard Smith
>> <richard-llvm at metafoo.co.uk> wrote:
>> > Author: rsmith
>> > Date: Sun Oct 14 18:53:37 2012
>> > New Revision: 165913
>> >
>> > URL: http://llvm.org/viewvc/llvm-project?rev=165913&view=rev
>> > Log:
>> > Provide a slightly more helpful diagnostic if -fcatch-undefined-behavior
>> > finds
>> > a problem with __int128 arithmetic but the runtime was not built with
>> > __int128
>> > support.
>>
>> Would it be possible for the test cases that depend on this would be
>> marked as untested/xfail/something on platforms that don't support it?
>
>
> It should be possible, yes. It's a little tricky (it depends on both the
> target and on the compiler used to build compiler-rt), but I'll have a look.
>
>>
>> Building with clang is actually failing for me, strangely enough. (I
>> assume clang should be supporting __int128? since when?)
>
>
> Clang has provided __int128 for a while, but it didn't actually work for
> 32-bit targets. Now it only provides __int128 on targets where it works (and
> it defines __SIZEOF_INT128__ on those targets, just like gcc). Removing
> __int128 usage for versions of Clang in this window fixed both 32-bit builds
> with those compilers and builds with older versions of Clang with no
> __int128 support (such as the one shipped with the latest Xcode), at the
> expense of 64-bit builds with recent-but-not-trunk Clangs losing __int128
> support.
>
> If you try again with a trunk Clang as your $CXX, it should work. Let me
> know if not.

Yeah, I saw that your int128 check depends on r168856 so I rebuilt &
installed that then rebuilt with that - ran cleanly.



More information about the llvm-commits mailing list