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

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 listllvm-dev at
lists.llvm.orghttp://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
> --
> Alastair Murray
> Principal Software Engineer, Compilers
> Codeplay Software Ltd
> Level C, Argyle House, 3 Lady Lawson St., Edinburgh, EH3 9DR
> Tel: 0131 466 0503
> Fax: 0131 557 6600
> Website: http://www.codeplay.com
> Twitter: https://twitter.com/codeplaysoft
>
> This email and any attachments may contain confidential and /or privileged
information and
> is for use by the addressee only. If you are not the intended recipient,
please notify
> Codeplay Software Ltd immediately and delete the message from your
computer. You may not
> copy or forward it, or use or disclose its contents to any other person.
Any views or other
> information in this message which do not relate to our business are not
authorized by
> Codeplay software Ltd, nor does this message form part of any contract
unless so stated.
> As internet communications are capable of data corruption Codeplay Software
Ltd does not
> accept any responsibility for any changes made to this message after it was
sent. Please
> note that Codeplay Software Ltd does not accept any liability or
responsibility for viruses
> and it is your responsibility to scan any attachments.
> Company registered in England and Wales, number: 04567874
> Registered office: Regent House, 316 Beulah Hill, London, United Kingdom,
SE19 3HF
>
> _______________________________________________
> 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/20180928/ee350959/attachment-0001.html>

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.

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

Hi Hans,

No we didn't surface this beyond submitting the patch.  As Reid pointed 
out these same ifdefs have already been removed/re-added a few times in 
2018, so while the patch works for us it isn't suitable for back-porting 
until it has been merged to trunk and the build-bots have given it a try.

It did not occur to me that it would not be possible to apply the change 
to 7.0.1, but your point make sense.

We didn't notice this during release-testing in the sense of building an 
LLVM package, but rather when linking some configurations of our own 
code against an LLVM built from the release branch.

Regards,
Alastair Murray.


On 29/09/18 09:09, Hans Wennborg 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.
>
> 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
-- 
Alastair Murray
Principal Software Engineer, Compilers
Codeplay Software Ltd
Level C, Argyle House, 3 Lady Lawson St., Edinburgh, EH3 9DR
Tel: 0131 466 0503
Fax: 0131 557 6600
Website: http://www.codeplay.com
Twitter: https://twitter.com/codeplaysoft

This email and any attachments may contain confidential and /or privileged
information and
is for use by the addressee only. If you are not the intended recipient, please
notify
Codeplay Software Ltd immediately and delete the message from your computer. You
may not
copy or forward it, or use or disclose its contents to any other person. Any
views or other
information in this message which do not relate to our business are not
authorized by
Codeplay software Ltd, nor does this message form part of any contract unless so
stated.
As internet communications are capable of data corruption Codeplay Software Ltd
does not
accept any responsibility for any changes made to this message after it was
sent. Please
note that Codeplay Software Ltd does not accept any liability or responsibility
for viruses
and it is your responsibility to scan any attachments.
Company registered in England and Wales, number: 04567874
Registered office: Regent House, 316 Beulah Hill, London, United Kingdom, SE19
3HF

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
>