• John Colvin (4/4) Oct 06 2015 http://gdcproject.org/downloads are all with gcc 5.2
• Johannes Pfau (16/23) Oct 06 2015 The gcc.version file is the version tested by the CI systems. This is
• Iain Buclaw via D.gnu (3/26) Oct 06 2015 I hope you are not backporting latest master to those branches too. ;-)
• Johannes Pfau (4/8) Oct 06 2015 I didn't have a look at the latest changes yet. Any reason why I
• Iain Buclaw via D.gnu (4/12) Oct 06 2015 Should be OK now. There's some more a breaking going on. Moving express...

John Colvin <john.loughran.colvin gmail.com> writes:

http://gdcproject.org/downloads are all with gcc 5.2

https://github.com/D-Programming-GDC/GDC/releases/tag/v2.066.1_gcc5 is with gcc
5.1, as is the gdc-5 branch

Is there a reason for this? If I want to package the latest 
"stable" gdc (must be from source), what should I work from?

Johannes Pfau <nospam example.com> writes:

Am Tue, 06 Oct 2015 12:52:23 +0000
schrieb John Colvin <john.loughran.colvin gmail.com>:

 http://gdcproject.org/downloads are all with gcc 5.2
 
 https://github.com/D-Programming-GDC/GDC/releases/tag/v2.066.1_gcc5
 is with gcc 5.1, as is the gdc-5 branch
 

The gcc.version file is the version tested by the CI systems. This is
important for the master branch which uses gcc snapshots and
older or newer snapshots often do not work.

For the release branches the version indicated in gcc.version is less
important. It's used by the autotester, but GCC does not break
compatibility in minor releases so you should always use the latest
release. 5.2 in this case.

OT: I just updated all gcc.version files. I'll push these updates once
the autotester passes.

 Is there a reason for this? If I want to package the latest 
 "stable" gdc (must be from source), what should I work from?

=> latest GCC 5 (5.2 right now) and gdc-5 branch.

We should probably add tags whenever we release updated binaries. But I
don't want to call these v2.066.1_gcc5.2 as you can use all gdc-5
commits with all GCC 5 versions. Probably v2.066.1_gcc5_r2 instead or
something like that.

"Iain Buclaw via D.gnu" <d.gnu puremagic.com> writes:

On 6 October 2015 at 17:23, Johannes Pfau via D.gnu <d.gnu puremagic.com>
wrote:

 Am Tue, 06 Oct 2015 12:52:23 +0000
 schrieb John Colvin <john.loughran.colvin gmail.com>:

 http://gdcproject.org/downloads are all with gcc 5.2

 https://github.com/D-Programming-GDC/GDC/releases/tag/v2.066.1_gcc5
 is with gcc 5.1, as is the gdc-5 branch

 The gcc.version file is the version tested by the CI systems. This is
 important for the master branch which uses gcc snapshots and
 older or newer snapshots often do not work.

 For the release branches the version indicated in gcc.version is less
 important. It's used by the autotester, but GCC does not break
 compatibility in minor releases so you should always use the latest
 release. 5.2 in this case.

 OT: I just updated all gcc.version files. I'll push these updates once
 the autotester passes.

 Is there a reason for this? If I want to package the latest
 "stable" gdc (must be from source), what should I work from?

 => latest GCC 5 (5.2 right now) and gdc-5 branch.

 We should probably add tags whenever we release updated binaries. But I
 don't want to call these v2.066.1_gcc5.2 as you can use all gdc-5
 commits with all GCC 5 versions. Probably v2.066.1_gcc5_r2 instead or
 something like that.

I hope you are not backporting latest master to those branches too. ;-)

Johannes Pfau <nospam example.com> writes:

Am Tue, 6 Oct 2015 18:13:26 +0200
schrieb "Iain Buclaw via D.gnu" <d.gnu puremagic.com>:

 
 I hope you are not backporting latest master to those branches
 too. ;-)
 

I didn't have a look at the latest changes yet. Any reason why I
shouldn't backport these?

"Iain Buclaw via D.gnu" <d.gnu puremagic.com> writes:

On 6 Oct 2015 11:50 pm, "Johannes Pfau via D.gnu" <d.gnu puremagic.com>
wrote:
 Am Tue, 6 Oct 2015 18:13:26 +0200
 schrieb "Iain Buclaw via D.gnu" <d.gnu puremagic.com>:

 I hope you are not backporting latest master to those branches
 too. ;-)

 I didn't have a look at the latest changes yet. Any reason why I
 shouldn't backport these?

Should be OK now. There's some more a breaking going on.  Moving expression
codegen to visitors and other refactorings.