www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.ldc - LDC 0.11.0: Release branch created, Windows/OS X issues

reply "David Nadlinger" <code klickverbot.at> writes:
Hi all,

The most important piece of information first: I just created the 
branches for the upcoming 0.11.0 release. This means that furious 
hacking activity on the master branch can and should resume!

Even if we should be good to go on Linux, I didn't put together beta 
packages just yet, though. The reason for this is that we are somewhat 
stuck on both OS X and Windows/MinGW.

On OS X, we are hitting quite an ugly EH bug in LLVM 3.2 ([1], breaks 
std.file/std.parallelism optimized unit tests), which seems to be fixed 
in the upcoming 3.3 release. There are two open issue with regard to 
this, though:
  - The current branch LLVM 3.3 contains a regression [2] that breaks 
compilation of the D runtime libraries. While it is officially listed as 
a release blocker, there is no indication of the amount of work it is 
currently receiving, and we pretty much have to wait for the fix (or 
find a workaround) until we can properly start testing 3.3 on OS X.
  - The LLVM release is scheduled to take place on June 5th. Do we want 
to delay our own release until then, or should we put out the binaries 
based on the LLVM release_33 branch? I don't see a big problem with the 
latter approach, especially considering that the LLVM schedule has shown 
to be rather … flexible in the past.

Additionally, there is a frontend issue breaking initialization of 
structs containing 'real' fields in certain cases [3]. As the issue 
occurs only in 32 bit mode and OS X has pretty much transitioned to 64 
bit completely (especially because we require 10.7 anyway), I'm inclined 
to just leave this open as a known bug, waiting for the upstream fix. 
What do you think?

Now, for Windows/MinGW: I want to include a "preview" build with the 
release, and it would only be natural to use LLVM 3.3 there as well, as 
it contains my TLS-related patches. However, the current version suffers 
from another regression [4] that breaks compilation of all but the most 
trivial test cases when debug info is turned on.

To sum up, the main issue at this point are not so much the regressions 
itself, but how big a delay in our release cycle we want to accept, 
because we do not know how many problems with LLVM 3.3 there are still 
hiding behind the most apparent bugs (even if it is looking solid on 
Linux).

Thanks for your opinions!
  — David


[1] https://github.com/ldc-developers/ldc/issues/362
[2] http://llvm.org/bugs/show_bug.cgi?id=15972
[3] https://github.com/ldc-developers/ldc/issues/363
[4] http://llvm.org/bugs/show_bug.cgi?id=15408
May 20 2013
parent reply "Kai Nacke" <kai redstar.de> writes:
On Monday, 20 May 2013 at 21:01:34 UTC, David Nadlinger wrote:
 Thanks for your opinions!
  — David
The Linux version is rock solid and everybody is waiting for a release. The bug [4] is fixed now so a new user group could be attracted with MinGW build. In contrast the OS X version is broken with LLVM 3.2 and LLVM 3.3 head. And I am not sure if OS X really counts as LLVM release blocker (e.g. any PPC bug is per definition no release blocker). As summary I think we should release the 0.11.0 version. If the OS X regression gets really fixed then we can create a minor update in 2 or 3 weeks. If we wait too long now then the dmd 2.063 release is out and then we are eager to merge the new frontend... ;-) Kai
May 24 2013
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-05-24 17:01, Kai Nacke wrote:

 The Linux version is rock solid and everybody is waiting for a release.
 The bug [4] is fixed now so a new user group could be attracted with
 MinGW build.

 In contrast the OS X version is broken with LLVM 3.2 and LLVM 3.3 head.
 And I am not sure if OS X really counts as LLVM release blocker (e.g.
 any PPC bug is per definition no release blocker).
Apple started to use Intel CPU's in around 2005. I'm pretty sure the last couple of releases of Mac OS X don't support PPC any more. Apple the biggest companies behind LLVM so I'm hoping the Mac OS X version will get some attention. -- /Jacob Carlborg
May 24 2013
parent Benjamin Thaut <code benjamin-thaut.de> writes:
Am 24.05.2013 19:05, schrieb Jacob Carlborg:
 On 2013-05-24 17:01, Kai Nacke wrote:

 The Linux version is rock solid and everybody is waiting for a release.
 The bug [4] is fixed now so a new user group could be attracted with
 MinGW build.

 In contrast the OS X version is broken with LLVM 3.2 and LLVM 3.3 head.
 And I am not sure if OS X really counts as LLVM release blocker (e.g.
 any PPC bug is per definition no release blocker).
Apple started to use Intel CPU's in around 2005. I'm pretty sure the last couple of releases of Mac OS X don't support PPC any more. Apple the biggest companies behind LLVM so I'm hoping the Mac OS X version will get some attention.
If this starts to get useable on windows that would be awesome. I'm still in need of a almost up to date D compiler with some nice optimization cababilities. Kind Regards Benjamin Thaut
May 24 2013
prev sibling parent reply "David Nadlinger" <code klickverbot.at> writes:
On 24 May 2013, at 17:01, Kai Nacke wrote:
 The Linux version is rock solid and everybody is waiting for a 
 release. The bug [4] is fixed now so a new user group could be 
 attracted with MinGW build.
It is indeed, even though the std.algorithm now cause an internal assertion in ld to be hit because of overly long symbol/section names. MinGW is not really stable yet, it would only be included in the release as a beta/preview version.
 In contrast the OS X version is broken with LLVM 3.2 and LLVM 3.3 
 head. And I am not sure if OS X really counts as LLVM release blocker 
 (e.g. any PPC bug is per definition no release blocker).
We've been getting quite a number of OS X bug reports in the past, so people are definitely expecting it to work. Also, the last release.
 As summary I think we should release the 0.11.0 version. If the OS X 
 regression gets really fixed then we can
 create a minor update in 2 or 3 weeks.
Yes, this is what I was thinking as well. Does the following sound like a plan? - Release Beta 1 tomorrow, with only Linux x86/x86_64 officially included. We might also want to provide packages for the other OSes though. - Aim for pushing out the final release on June 1. If OS X TLS is fixed until then, we'll release an official 0.11.0 OS X package based on the release_33 branch; otherwise, we'll delay that. - Schedule a minor release (0.11.1) in two weeks, on June 7. This is two days after the (tentative) LLVM 3.3 release date, so we should be able to provide OS X packages there. The release would be branched off the release-0.11.0 branch and only incorporate pure bug/regression fixes. David
May 25 2013
parent reply "Kai Nacke" <kai redstar.de> writes:
On Saturday, 25 May 2013 at 19:06:38 UTC, David Nadlinger wrote:
 On 24 May 2013, at 17:01, Kai Nacke wrote:
 The Linux version is rock solid and everybody is waiting for a 
 release. The bug [4] is fixed now so a new user group could be 
 attracted with MinGW build.
It is indeed, even though the std.algorithm now cause an internal assertion in ld to be hit because of overly long symbol/section names. MinGW is not really stable yet, it would only be included in the release as a beta/preview version.
 In contrast the OS X version is broken with LLVM 3.2 and LLVM 
 3.3 head. And I am not sure if OS X really counts as LLVM 
 release blocker (e.g. any PPC bug is per definition no release 
 blocker).
We've been getting quite a number of OS X bug reports in the past, so people are definitely expecting it to work. Also, the last release.
 As summary I think we should release the 0.11.0 version. If 
 the OS X regression gets really fixed then we can
 create a minor update in 2 or 3 weeks.
Yes, this is what I was thinking as well. Does the following sound like a plan? - Release Beta 1 tomorrow, with only Linux x86/x86_64 officially included. We might also want to provide packages for the other OSes though. - Aim for pushing out the final release on June 1. If OS X TLS is fixed until then, we'll release an official 0.11.0 OS X package based on the release_33 branch; otherwise, we'll delay that. - Schedule a minor release (0.11.1) in two weeks, on June 7. This is two days after the (tentative) LLVM 3.3 release date, so we should be able to provide OS X packages there. The release would be branched off the release-0.11.0 branch and only incorporate pure bug/regression fixes. David
Sounds good! Kai
May 25 2013
parent "David Nadlinger" <see klickverbot.at> writes:
On Saturday, 25 May 2013 at 19:24:24 UTC, Kai Nacke wrote:
 Sounds good!
Ubuntu 10.04 LTS ships with the rather old CMake 2.8.0, and this version contains a quirk regarding assembler files, breaking the build due to threadasm.S. Thus, the automatic packaging scripts I kicked off on EC2 yesterday failed. Will investigate, and hopefully publish the packages soon. David
May 27 2013