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

Thu Oct 11 07:39:06 PDT 2018

Ben, what do you think about just reverting to what we had before
r322838? It seems we still don't know how to do this in a way that
doesn't break with (old) GCC, and I'm guessing it's not really worth
the trouble that the optimization brings?

As for if we can do anything for 7.0.1, I don't know.

On Wed, Oct 3, 2018 at 12:21 AM, Kern Handa <kern.handa at gmail.com> wrote:
> 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
>>> >
>>>
>