Hi all,
  We now support 3.5, 3.6, 3.7, 3.8, 3.9, 4.0, 5.0 ... that's 7 versions of LLVM, quite a bunch!

How long do we want to keep supporting LLVM 3.5 and 3.6? Can we remove support from LDC >= 1.4?

Not that it is bothering me a whole lot, but for example looking at the debuginfo code is annoying with all the #ifdef'ing.
Culling 3.5 and 3.6 support would also save a bit of TravisCI time.

cheers,
  Johan

On Friday, 14 July 2017 at 11:49:13 UTC, Johan Engelen wrote:
> How long do we want to keep supporting LLVM 3.5 and 3.6? Can we remove support from LDC >= 1.4?
>
> Not that it is bothering me a whole lot, but for example looking at the debuginfo code is annoying with all the #ifdef'ing.
> Culling 3.5 and 3.6 support would also save a bit of TravisCI time.

Fine with me. Ubuntu 14.04 is still on unsupported LLVM 3.4, 16.04 already on LLVM 3.8, and SPIR-V apparently not restricted to 3.6 anymore.

I was going to suggest culling < 3.7 support as well.

I'm still toying with the idea of going with a vendored LLVM so we can more efficiently support work like Android, SPIR-V, etc., but for now I guess there isn't really a reason to throw a wrench into the distro packaging process.

 — David

On 14 Jul 2017, at 13:31, kinke via digitalmars-d-ldc wrote:

> On Friday, 14 July 2017 at 11:49:13 UTC, Johan Engelen wrote:
>> How long do we want to keep supporting LLVM 3.5 and 3.6? Can we remove support from LDC >= 1.4?
>>
>> Not that it is bothering me a whole lot, but for example looking at the debuginfo code is annoying with all the #ifdef'ing.
>> Culling 3.5 and 3.6 support would also save a bit of TravisCI time.
>
> Fine with me. Ubuntu 14.04 is still on unsupported LLVM 3.4, 16.04 already on LLVM 3.8, and SPIR-V apparently not restricted to 3.6 anymore.

Johan: +1
David: +1
kinke: +1

Kay, what do you think? Is dropping LLVM < 3.7 OK for your stuff?


On Friday, 14 July 2017 at 12:42:34 UTC, David Nadlinger wrote:
> I was going to suggest culling < 3.7 support as well.
>
> I'm still toying with the idea of going with a vendored LLVM so we can more efficiently support work like Android, SPIR-V, etc., but for now I guess there isn't really a reason to throw a wrench into the distro packaging process.
>
>  — David
>
> On 14 Jul 2017, at 13:31, kinke via digitalmars-d-ldc wrote:
>
>> On Friday, 14 July 2017 at 11:49:13 UTC, Johan Engelen wrote:
>>> How long do we want to keep supporting LLVM 3.5 and 3.6? Can we remove support from LDC >= 1.4?
>>>
>>> Not that it is bothering me a whole lot, but for example looking at the debuginfo code is annoying with all the #ifdef'ing.
>>> Culling 3.5 and 3.6 support would also save a bit of TravisCI time.
>>
>> Fine with me. Ubuntu 14.04 is still on unsupported LLVM 3.4, 16.04 already on LLVM 3.8, and SPIR-V apparently not restricted to 3.6 anymore.

On Friday, 14 July 2017 at 13:51:39 UTC, Johan Engelen wrote:
> Johan: +1
> David: +1
> kinke: +1
>
> Kay, what do you think? Is dropping LLVM < 3.7 OK for your stuff?
>
>
> On Friday, 14 July 2017 at 12:42:34 UTC, David Nadlinger wrote:
>> I was going to suggest culling < 3.7 support as well.
>>
>> I'm still toying with the idea of going with a vendored LLVM so we can more efficiently support work like Android, SPIR-V, etc., but for now I guess there isn't really a reason to throw a wrench into the distro packaging process.
>>
>>  — David
>>
>> On 14 Jul 2017, at 13:31, kinke via digitalmars-d-ldc wrote:
>>
>>> On Friday, 14 July 2017 at 11:49:13 UTC, Johan Engelen wrote:
>>>> How long do we want to keep supporting LLVM 3.5 and 3.6? Can we remove support from LDC >= 1.4?
>>>>
>>>> Not that it is bothering me a whole lot, but for example looking at the debuginfo code is annoying with all the #ifdef'ing.
>>>> Culling 3.5 and 3.6 support would also save a bit of TravisCI time.
>>>
>>> Fine with me. Ubuntu 14.04 is still on unsupported LLVM 3.4, 16.04 already on LLVM 3.8, and SPIR-V apparently not restricted to 3.6 anymore.

An ancillary request, can someone with an ARM board put up a native linux/armhf build for 1.3.0?  The last time we did, 1.1.0, it got 60% of the download count of the Win32 build:

http://www.somsubhra.com/github-release-stats/?username=ldc-developers&repository=ldc

As for llvm, no problem with dropping the old ones.

On Friday, 14 July 2017 at 13:51:39 UTC, Johan Engelen wrote:
> Johan: +1
> David: +1
> kinke: +1
>
> Kay, what do you think? Is dropping LLVM < 3.7 OK for your stuff?

+1

SPIRV is master only.

The only thing I remember was that @Pursche was trying to do some PS4 stuff on an old LLVM almost exactly a year ago, but I haven't heard anything recent.

On 14.07.2017 14:42, David Nadlinger via digitalmars-d-ldc wrote:
> I was going to suggest culling < 3.7 support as well.
> 
> I'm still toying with the idea of going with a vendored LLVM so we can more efficiently support work like Android, SPIR-V, etc., but for now I guess there isn't really a reason to throw a wrench into the distro packaging process.

That could also help getting a D specific language identifier into CodeView debug information to support mago with the VS Concord debug engine.

I just filed a bug report against LLVM (https://bugs.llvm.org/show_bug.cgi?id=33899) to have this added to master, but it won't help for releases build against older LLVM versions.

On Friday, 14 July 2017 at 11:49:13 UTC, Johan Engelen wrote:
> 
> Culling 3.5 and 3.6 support

Really nice that it's gone from master.
OK to remove it from ltsmaster then too, right?

- Johan

On Sunday, 30 July 2017 at 20:02:29 UTC, Johan Engelen wrote:
> On Friday, 14 July 2017 at 11:49:13 UTC, Johan Engelen wrote:
>> 
>> Culling 3.5 and 3.6 support
>
> Really nice that it's gone from master.
> OK to remove it from ltsmaster then too, right?

IMO, yes.

On Sunday, 30 July 2017 at 20:02:29 UTC, Johan Engelen wrote:
> On Friday, 14 July 2017 at 11:49:13 UTC, Johan Engelen wrote:
>> 
>> Culling 3.5 and 3.6 support
>
> Really nice that it's gone from master.
> OK to remove it from ltsmaster then too, right?
>
> - Johan

I build ltsmaster on Android/ARM against llvm 4.0.1, haven't had a problem.  Since it's up to date with the latest llvm, I see no reason to support the really old versions.