thr3ads.net - llvm dev - [llvm-dev] Ubuntu LLVM packages incompatible with clang built projects? [Oct 2018]

If this information is useful, please help other people find it:
Share via:

Tom Stellard via llvm-dev

2018-Oct-01 17:47 UTC

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

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
>

Kern Handa via llvm-dev

2018-Oct-01 20:29 UTC

head link

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

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/20181001/1ad7de65/attachment.html>

Kern Handa via llvm-dev

2018-Oct-02 22:21 UTC

head link

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

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>

llvm dev - Oct 2018 - Ubuntu LLVM packages incompatible with clang built projects?

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

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

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