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