[llvm-dev] Ubuntu LLVM packages incompatible with clang built projects?

Tue Oct 2 15:21:21 PDT 2018

Ping. Is there any update on what the plan is for addressing this issue?

On Mon, Oct 1, 2018 at 1:29 PM Kern Handa <kern.handa at gmail.com> wrote:

> I can confirm that Alastair's patch works for me. Steps taken:
>
> 1. git checkout https://git.llvm.org/git/llvm.git/ @ 65ce2e56889
> (release_70)
> 2. configure with "CC=gcc-8 CXX=g++-8 cmake -GNinja
> -DCMAKE_BUILD_TYPE=RelWithDebInfo .. -DLLVM_TOOL_CLANG_BUILD=OFF
> -DCMAKE_INSTALL_PREFIX=$HOME/code/llvm-install/7/gcc/RelWithDebInfo"
> 3. build with "ninja install"
> 4. build my own project and link against new custom llvm build
> 5. run offending executable and notice SEGFAULT
> 6. apply patch (below)
> 7. step #2, but with install prefix changed to
> $HOME/code/llvm-install/7/gcc-patch/RelWithDebInfo
> 8. step #3 and #4
> 9. run offending executable and notice successful run
>
> If this patch can't make it in for LLVM 7.0.1, could it make 7.1? If so,
> what kind of timeline would you expect?
>
> HTH,
> Kern
>
> ------------------------------------------
>
> Patch:
>
>
> diff --git a/include/llvm/ADT/Optional.h b/include/llvm/ADT/Optional.h
> index 353e5d0ec9d..150915c5b9e 100644
> --- a/include/llvm/ADT/Optional.h
> +++ b/include/llvm/ADT/Optional.h
> @@ -108,7 +108,6 @@ template <typename T, bool IsPodLike> struct
> OptionalStorage {
>    }
>  };
>
> -#if !defined(__GNUC__) || defined(__clang__) // GCC up to GCC7
> miscompiles this.
>  /// Storage for trivially copyable types only.
>  template <typename T> struct OptionalStorage<T, true> {
>    AlignedCharArrayUnion<T> storage;
> @@ -118,14 +117,20 @@ template <typename T> struct OptionalStorage<T,
> true> {
>
>    OptionalStorage(const T &y) : hasVal(true) { new (storage.buffer) T(y);
> }
>    OptionalStorage &operator=(const T &y) {
> -    *reinterpret_cast<T *>(storage.buffer) = y;
> -    hasVal = true;
> +   if (hasVal) {
> +     // Use std::addressof to silence strict-aliasing warnings from gcc.
> +     *reinterpret_cast<T *>(std::addressof(storage.buffer)) = y;
> +   } else {
> +     // Copy assignment to uninitialized storage is undefined behavior so
> copy
> +     // construct with placement new when no value is held.
> +     new (storage.buffer) T(y);
> +     hasVal = true;
> +   }
>      return *this;
>    }
>
>    void reset() { hasVal = false; }
>  };
> -#endif
>  } // namespace optional_detail
>
>  template <typename T> class Optional {
>
>
> ------------------------------------------
>
>
>
>
> On Mon, Oct 1, 2018 at 10:47 AM Tom Stellard <tstellar at redhat.com> wrote:
>
>> On 09/29/2018 01:09 AM, Hans Wennborg via llvm-dev wrote:
>> > Trunk still has the different gcc and clang versions.
>> >
>> > What's worse, the 7.0.0 release has them too :-( I completely missed
>> > this and we can't fix it for 7.0.1 since that would also be an ABI
>> > break.
>> >
>> Is this something we could fix by adding a symbol alias to the
>> linker script for libLLVM.so?
>>
>> -Tom
>>
>> > Alastair, if you noticed this during the release testing, did you
>> > surface it anywhere?
>> >
>> >
>> > On Fri, Sep 28, 2018 at 6:07 PM, Reid Kleckner <rnk at google.com> wrote:
>> >> Just be aware that those ifdefs were recommitted and reverted several
>> times,
>> >> so I'm not sure what the state is.
>> >>
>> >> On Fri, Sep 28, 2018 at 8:48 AM Alastair Murray via llvm-dev
>> >> <llvm-dev at lists.llvm.org> wrote:
>> >>>
>> >>> Hi Kern,
>> >>>
>> >>> We also had issues with mixing GCC/Clang builds when testing the 7.0
>> >>> release branch.
>> >>>
>> >>> My colleague submitted a patch that fixed the issue for us:
>> >>> * https://reviews.llvm.org/D50710
>> >>>
>> >>> I no longer have a copy of the error we were seeing to see if it was
>> the
>> >>> same, but the fix is to llvm::OptionalStorage and your error message
>> >>> involves llvm::Optional.  The patch removes a GCC specific ifdef, and
>> >>> hopefully fixes the issue that made that necessary in the first
>> place, but
>> >>> we never really knew how the GCC miscompilation was expressed.
>> >>>
>> >>> It would be interesting to know whether this resolves your issue, but
>> >>> regardless we should give the patch a prod.
>> >>>
>> >>> Regards,
>> >>> Alastair Murray.
>> >>>
>> >>>
>> >>> On 27/09/18 08:46, Kern Handa via llvm-dev wrote:
>> >>>
>> >>> Hi folks,
>> >>>
>> >>> Not sure if this is the right mailing list target, but I'm trying out
>> the
>> >>> new LLVM 7.0 packages found at http://apt.llvm.org by porting over an
>> >>> existing LLVM 6.0 project of ours to the new version. In doing so, I
>> found
>> >>> that the executable always segfaulted at the same spot with no
>> explanation:
>> >>>
>> >>> 0x0000000000fefe33 in
>> >>>
>> llvm::RegisterTargetMachine<llvm::X86TargetMachine>::Allocator(llvm::Target
>> >>> const&, llvm::Triple const&, llvm::StringRef, llvm::StringRef,
>> >>> llvm::TargetOptions const&, llvm::Optional<llvm::R
>> >>> eloc::Model>, llvm::Optional<llvm::CodeModel::Model>,
>> >>> llvm::CodeGenOpt::Level, bool) ()
>> >>>
>> >>> This happens if I build my project and link it against LLVM 7.0 with
>> >>> either clang++ 6.1 or clang++ 7.0. This does not happen if I build my
>> >>> project with g++ 8.
>> >>>
>> >>> I have also confirmed that building LLVM 7.0 with clang++ and then
>> using
>> >>> that private build of the libraries fixes the issue.
>> >>>
>> >>> To summarize, it seems that there's an ABI incompatibility introduced
>> >>> somewhere, which means LLVM 7.0 compiled with gcc can only be used by
>> other
>> >>> projects also built with gcc. Is this something that's being
>> investigated
>> >>> and to be resolved as a fix in 7.1? If not, is there any official
>> release
>> >>> note that's remarking on this incompatibility?
>> >>>
>> >>> Thanks,
>> >>> Kern
>> > _______________________________________________
>> > LLVM Developers mailing list
>> > llvm-dev at lists.llvm.org
>> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>> >
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20181002/586e9909/attachment.html>