www.digitalmars.com         C & C++   DMDScript  

D.gnu - master branch broken

reply Johannes Pfau <nospam example.com> writes:
See
https://d.puremagic.com/test-results/test_data.ghtml?projectid=2&runid=62582&logid=13

(Didn't see this in my local tests, it probably needs a complete gdc
rebuild to happen)
Mar 22 2014
next sibling parent Iain Buclaw <ibuclaw gdcproject.org> writes:
On 22 March 2014 18:20, Johannes Pfau <nospam example.com> wrote:
 See
 https://d.puremagic.com/test-results/test_data.ghtml?projectid=2&runid=62582&logid=13

 (Didn't see this in my local tests, it probably needs a complete gdc
 rebuild to happen)

Hmm, didn't see that either.
Mar 22 2014
prev sibling next sibling parent Brad Roberts <braddr puremagic.com> writes:
On 3/22/14, 12:02 PM, Iain Buclaw wrote:
 On 22 March 2014 18:20, Johannes Pfau <nospam example.com> wrote:
 See
 https://d.puremagic.com/test-results/test_data.ghtml?projectid=2&runid=62582&logid=13

 (Didn't see this in my local tests, it probably needs a complete gdc
 rebuild to happen)

Hmm, didn't see that either.

Has the minimum base gcc version moved forward again? Why isn't the GDC repo a fork of gcc rather than depend on a tarball to apply on top of? Currently the auto-testers are using this snapshot: 4.9-20131201.
Mar 22 2014
prev sibling next sibling parent Johannes Pfau <nospam example.com> writes:
Am Sat, 22 Mar 2014 14:50:22 -0700
schrieb Brad Roberts <braddr puremagic.com>:

 On 3/22/14, 12:02 PM, Iain Buclaw wrote:
 On 22 March 2014 18:20, Johannes Pfau <nospam example.com> wrote:
 See
 https://d.puremagic.com/test-results/test_data.ghtml?projectid=2&runid=62582&logid=13

 (Didn't see this in my local tests, it probably needs a complete
 gdc rebuild to happen)

Hmm, didn't see that either.

Has the minimum base gcc version moved forward again?

I don't think that's the case here, at least there's no obvious change that could require a newer snapshot.
 Why isn't the
 GDC repo a fork of gcc rather than depend on a tarball to apply on
 top of?  Currently the auto-testers are using this snapshot:
 4.9-20131201.
 

The GCC sources are quite big, even bigger as a git repo with history so I'd like to keep the GDC sources separated (this way it's also easier to see GDC changes vs normal GCC code). But I understand that it's probably quite annoying for you to update the snapshots manually. How about this: We add a gcc.json file to the root folder in the git repository (for every branch). gcc.json would look like this: { "base-version":"4.9", "snapshot": "20131201" } If snapshot is present and non-empty a snapshot has to be used. Otherwise all stable releases should work, e.g. { "base-version":"4.8", "snapshot": "" } would work with 4.8.0, 4.8.1, 4.8.2, ... We then sync the snapshot field in gcc.json to the snapshot we're using locally.
Mar 23 2014
prev sibling next sibling parent Iain Buclaw <ibuclaw gdcproject.org> writes:
On 23 March 2014 09:31, Johannes Pfau <nospam example.com> wrote:
 Am Sat, 22 Mar 2014 14:50:22 -0700
 schrieb Brad Roberts <braddr puremagic.com>:

 On 3/22/14, 12:02 PM, Iain Buclaw wrote:
 On 22 March 2014 18:20, Johannes Pfau <nospam example.com> wrote:
 See
 https://d.puremagic.com/test-results/test_data.ghtml?projectid=2&runid=62582&logid=13

 (Didn't see this in my local tests, it probably needs a complete
 gdc rebuild to happen)

Hmm, didn't see that either.

Has the minimum base gcc version moved forward again?

I don't think that's the case here, at least there's no obvious change that could require a newer snapshot.
 Why isn't the
 GDC repo a fork of gcc rather than depend on a tarball to apply on
 top of?  Currently the auto-testers are using this snapshot:
 4.9-20131201.

The GCC sources are quite big, even bigger as a git repo with history so I'd like to keep the GDC sources separated (this way it's also easier to see GDC changes vs normal GCC code). But I understand that it's probably quite annoying for you to update the snapshots manually. How about this: We add a gcc.json file to the root folder in the git repository (for every branch). gcc.json would look like this: { "base-version":"4.9", "snapshot": "20131201" } If snapshot is present and non-empty a snapshot has to be used. Otherwise all stable releases should work, e.g. { "base-version":"4.8", "snapshot": "" } would work with 4.8.0, 4.8.1, 4.8.2, ... We then sync the snapshot field in gcc.json to the snapshot we're using locally.

Can be done, it would be nice to get GCC 4.8/GCC 4.7 on the autotester as well as snapshot builds.
Mar 23 2014
prev sibling next sibling parent Iain Buclaw <ibuclaw gdcproject.org> writes:
On 23 March 2014 09:31, Johannes Pfau <nospam example.com> wrote:
 Am Sat, 22 Mar 2014 14:50:22 -0700
 schrieb Brad Roberts <braddr puremagic.com>:

 On 3/22/14, 12:02 PM, Iain Buclaw wrote:
 On 22 March 2014 18:20, Johannes Pfau <nospam example.com> wrote:
 See
 https://d.puremagic.com/test-results/test_data.ghtml?projectid=2&runid=62582&logid=13

 (Didn't see this in my local tests, it probably needs a complete
 gdc rebuild to happen)

Hmm, didn't see that either.

Has the minimum base gcc version moved forward again?

I don't think that's the case here, at least there's no obvious change that could require a newer snapshot.

In this case, it's a GCC GC bug. Fix incoming.
Mar 23 2014
prev sibling next sibling parent Brad Roberts <braddr puremagic.com> writes:
I'm not at all concerned about space, and not sure why most developers would
be.  Assuming that the 
GDC changes were done on a non-master branch, and that master reflects the GCC
master, then seeing 
what the GDC changes are would be a typical git operation: git diff master..GDC.

But I can deal with a json config file if necessary.  Even better / easier,
would be a file with a 
single line that is the name of the file that should exist, ie:

-----
gcc-4.9-20131201.tar.bz2
-----

I don't mind updating the tester as it stands today, but I kinda need to _know_
it needs to be 
updated.  Waiting for things to fail, waiting for someone to notice, and
waiting for someone to 
diagnose it as being 'too old' all sucks. :)

If the GDC repo contained 3 branches, GDC-4.7, GDC-4.8, and GDC-4.9, having the
auto-tester work on 
them would be _trivial_.  I could enable that right now.  It takes less than 5
minutes to do for new 
DMD branches.

On 3/23/14, 2:31 AM, Johannes Pfau wrote:
 Am Sat, 22 Mar 2014 14:50:22 -0700
 schrieb Brad Roberts <braddr puremagic.com>:

 On 3/22/14, 12:02 PM, Iain Buclaw wrote:
 On 22 March 2014 18:20, Johannes Pfau <nospam example.com> wrote:
 See
 https://d.puremagic.com/test-results/test_data.ghtml?projectid=2&runid=62582&logid=13

 (Didn't see this in my local tests, it probably needs a complete
 gdc rebuild to happen)

Hmm, didn't see that either.

Has the minimum base gcc version moved forward again?

I don't think that's the case here, at least there's no obvious change that could require a newer snapshot.
 Why isn't the
 GDC repo a fork of gcc rather than depend on a tarball to apply on
 top of?  Currently the auto-testers are using this snapshot:
 4.9-20131201.

The GCC sources are quite big, even bigger as a git repo with history so I'd like to keep the GDC sources separated (this way it's also easier to see GDC changes vs normal GCC code). But I understand that it's probably quite annoying for you to update the snapshots manually. How about this: We add a gcc.json file to the root folder in the git repository (for every branch). gcc.json would look like this: { "base-version":"4.9", "snapshot": "20131201" } If snapshot is present and non-empty a snapshot has to be used. Otherwise all stable releases should work, e.g. { "base-version":"4.8", "snapshot": "" } would work with 4.8.0, 4.8.1, 4.8.2, ... We then sync the snapshot field in gcc.json to the snapshot we're using locally.

Mar 23 2014
prev sibling next sibling parent Iain Buclaw <ibuclaw gdcproject.org> writes:
On 23 March 2014 21:58, Brad Roberts <braddr puremagic.com> wrote:
 I'm not at all concerned about space, and not sure why most developers would
 be.  Assuming that the GDC changes were done on a non-master branch, and
 that master reflects the GCC master, then seeing what the GDC changes are
 would be a typical git operation: git diff master..GDC.

 But I can deal with a json config file if necessary.  Even better / easier,
 would be a file with a single line that is the name of the file that should
 exist, ie:

 -----
 gcc-4.9-20131201.tar.bz2
 -----

 I don't mind updating the tester as it stands today, but I kinda need to
 _know_ it needs to be updated.  Waiting for things to fail, waiting for
 someone to notice, and waiting for someone to diagnose it as being 'too old'
 all sucks. :)

I'll try to remember to update the snapshot version each time I rebase my GCC sources. ;)
 If the GDC repo contained 3 branches, GDC-4.7, GDC-4.8, and GDC-4.9, having
 the auto-tester work on them would be _trivial_.  I could enable that right
 now.  It takes less than 5 minutes to do for new DMD branches.

https://github.com/D-Programming-GDC/GDC/branches master is synonymous with GDC-4.9
Mar 23 2014
prev sibling next sibling parent Brad Roberts <braddr puremagic.com> writes:
On 3/23/14, 3:44 PM, Iain Buclaw wrote:
 On 23 March 2014 21:58, Brad Roberts <braddr puremagic.com> wrote:
 I'm not at all concerned about space, and not sure why most developers would
 be.  Assuming that the GDC changes were done on a non-master branch, and
 that master reflects the GCC master, then seeing what the GDC changes are
 would be a typical git operation: git diff master..GDC.

 But I can deal with a json config file if necessary.  Even better / easier,
 would be a file with a single line that is the name of the file that should
 exist, ie:

 -----
 gcc-4.9-20131201.tar.bz2
 -----

 I don't mind updating the tester as it stands today, but I kinda need to
 _know_ it needs to be updated.  Waiting for things to fail, waiting for
 someone to notice, and waiting for someone to diagnose it as being 'too old'
 all sucks. :)

I'll try to remember to update the snapshot version each time I rebase my GCC sources. ;)
 If the GDC repo contained 3 branches, GDC-4.7, GDC-4.8, and GDC-4.9, having
 the auto-tester work on them would be _trivial_.  I could enable that right
 now.  It takes less than 5 minutes to do for new DMD branches.

https://github.com/D-Programming-GDC/GDC/branches master is synonymous with GDC-4.9

I was referring back to having the repository be complete, not just the delta on top of gcc. As deltas it's no longer a "checkout and build" process. Not hard steps, to be sure, but more steps that are gdc build process specific.
Mar 23 2014
prev sibling next sibling parent Iain Buclaw <ibuclaw gdcproject.org> writes:
On 23 March 2014 19:28, Iain Buclaw <ibuclaw gdcproject.org> wrote:
 On 23 March 2014 09:31, Johannes Pfau <nospam example.com> wrote:
 Am Sat, 22 Mar 2014 14:50:22 -0700
 schrieb Brad Roberts <braddr puremagic.com>:

 On 3/22/14, 12:02 PM, Iain Buclaw wrote:
 On 22 March 2014 18:20, Johannes Pfau <nospam example.com> wrote:
 See
 https://d.puremagic.com/test-results/test_data.ghtml?projectid=2&runid=62582&logid=13

 (Didn't see this in my local tests, it probably needs a complete
 gdc rebuild to happen)

Hmm, didn't see that either.

Has the minimum base gcc version moved forward again?

I don't think that's the case here, at least there's no obvious change that could require a newer snapshot.

In this case, it's a GCC GC bug. Fix incoming.

Still failing with a second unrelated issue. Looks like wrong code sent to back-end (trying to compile an ERROR_MARK) - I probably exposed a couple wrong handling of errors in the backend through some refactoring. What I might end up doing is submitting a new visitor to walk all trees and assert if an error expression is found, that at least safe guards me from having to put in workarounds to handle junk codegen. :-)
Mar 24 2014
prev sibling next sibling parent Johannes Pfau <nospam example.com> writes:
Am Sun, 23 Mar 2014 14:58:01 -0700
schrieb Brad Roberts <braddr puremagic.com>:

 I'm not at all concerned about space, and not sure why most
 developers would be.  Assuming that the GDC changes were done on a
 non-master branch, and that master reflects the GCC master, then
 seeing what the GDC changes are would be a typical git operation: git
 diff master..GDC.

It's not really space, it's the time needed for a git clone. Cloning gdc already takes 12 min here. Cloning the gcc repo takes 4 hours and 50 min. I end up cloning gdc more often than I like (testing build scripts, testing gdc on new machines, ...) Also linux distributions want to use GDC with the same GCC version they normally use. So if a distribution uses gcc-4.8.1 but our sources are gcc-4.8.2 only that'd be a problem. The current approach always works for all minor versions.
 
 But I can deal with a json config file if necessary.  Even better /
 easier, would be a file with a single line that is the name of the
 file that should exist, ie:
 
 -----
 gcc-4.9-20131201.tar.bz2
 -----
 
 I don't mind updating the tester as it stands today, but I kinda need
 to _know_ it needs to be updated.  Waiting for things to fail,
 waiting for someone to notice, and waiting for someone to diagnose it
 as being 'too old' all sucks. :)

OK, I've added a gcc.version file to all branches. It's the name of the source archive without the 'tar.bz2' file extension. https://github.com/D-Programming-GDC/GDC/blob/master/gcc.version https://github.com/D-Programming-GDC/GDC/blob/gdc-4.8/gcc.version https://github.com/D-Programming-GDC/GDC/blob/gdc-4.7/gcc.version
 
 If the GDC repo contained 3 branches, GDC-4.7, GDC-4.8, and GDC-4.9,
 having the auto-tester work on them would be _trivial_.  I could
 enable that right now.  It takes less than 5 minutes to do for new
 DMD branches.
 

Mar 24 2014
prev sibling next sibling parent Iain Buclaw <ibuclaw gdcproject.org> writes:
On 24 March 2014 08:27, Johannes Pfau <nospam example.com> wrote:
 Am Sun, 23 Mar 2014 14:58:01 -0700
 schrieb Brad Roberts <braddr puremagic.com>:

 I'm not at all concerned about space, and not sure why most
 developers would be.  Assuming that the GDC changes were done on a
 non-master branch, and that master reflects the GCC master, then
 seeing what the GDC changes are would be a typical git operation: git
 diff master..GDC.

It's not really space, it's the time needed for a git clone. Cloning gdc already takes 12 min here. Cloning the gcc repo takes 4 hours and 50 min. I end up cloning gdc more often than I like (testing build scripts, testing gdc on new machines, ...)

If it's taking that long, you can just switch to git+ssh cloning. That's what I did when I push up my gdb mirror (took about 3 hours for the initial push after endless timeout+retries with http).
 Also linux distributions want to use GDC with the same GCC version they
 normally use. So if a distribution uses gcc-4.8.1 but our sources are
 gcc-4.8.2 only that'd be a problem. The current approach always works
 for all minor versions.

I don't think that would be a problem. Or at least I've never had to change anything testing minor releases.
Mar 24 2014
prev sibling next sibling parent Iain Buclaw <ibuclaw gdcproject.org> writes:
On 24 March 2014 07:34, Iain Buclaw <ibuclaw gdcproject.org> wrote:
 On 23 March 2014 19:28, Iain Buclaw <ibuclaw gdcproject.org> wrote:
 On 23 March 2014 09:31, Johannes Pfau <nospam example.com> wrote:
 Am Sat, 22 Mar 2014 14:50:22 -0700
 schrieb Brad Roberts <braddr puremagic.com>:

 On 3/22/14, 12:02 PM, Iain Buclaw wrote:
 On 22 March 2014 18:20, Johannes Pfau <nospam example.com> wrote:
 See
 https://d.puremagic.com/test-results/test_data.ghtml?projectid=2&runid=62582&logid=13

 (Didn't see this in my local tests, it probably needs a complete
 gdc rebuild to happen)

Hmm, didn't see that either.

Has the minimum base gcc version moved forward again?

I don't think that's the case here, at least there's no obvious change that could require a newer snapshot.

In this case, it's a GCC GC bug. Fix incoming.

Still failing with a second unrelated issue. Looks like wrong code sent to back-end (trying to compile an ERROR_MARK) - I probably exposed a couple wrong handling of errors in the backend through some refactoring. What I might end up doing is submitting a new visitor to walk all trees and assert if an error expression is found, that at least safe guards me from having to put in workarounds to handle junk codegen. :-)

Green again. I've also bumped the snapshot version to 20140330. :) http://d.puremagic.com/test-results/?projectid=2
Mar 31 2014
prev sibling parent Brad Roberts <braddr puremagic.com> writes:
On 3/31/14, 10:06 AM, Iain Buclaw wrote:
 On 24 March 2014 07:34, Iain Buclaw <ibuclaw gdcproject.org> wrote:
 On 23 March 2014 19:28, Iain Buclaw <ibuclaw gdcproject.org> wrote:
 On 23 March 2014 09:31, Johannes Pfau <nospam example.com> wrote:
 Am Sat, 22 Mar 2014 14:50:22 -0700
 schrieb Brad Roberts <braddr puremagic.com>:

 On 3/22/14, 12:02 PM, Iain Buclaw wrote:
 On 22 March 2014 18:20, Johannes Pfau <nospam example.com> wrote:
 See
 https://d.puremagic.com/test-results/test_data.ghtml?projectid=2&runid=62582&logid=13

 (Didn't see this in my local tests, it probably needs a complete
 gdc rebuild to happen)

Hmm, didn't see that either.

Has the minimum base gcc version moved forward again?

I don't think that's the case here, at least there's no obvious change that could require a newer snapshot.

In this case, it's a GCC GC bug. Fix incoming.

Still failing with a second unrelated issue. Looks like wrong code sent to back-end (trying to compile an ERROR_MARK) - I probably exposed a couple wrong handling of errors in the backend through some refactoring. What I might end up doing is submitting a new visitor to walk all trees and assert if an error expression is found, that at least safe guards me from having to put in workarounds to handle junk codegen. :-)

Green again. I've also bumped the snapshot version to 20140330. :) http://d.puremagic.com/test-results/?projectid=2

Good for the green. I'll add support for paying attention to that version file soonish.. but probably not today.
Mar 31 2014