D.gnu - master branch broken
- Johannes Pfau (4/4) Mar 22 2014 See
- Iain Buclaw (2/6) Mar 22 2014 Hmm, didn't see that either.
- Brad Roberts (4/11) Mar 22 2014 Has the minimum base gcc version moved forward again? Why isn't the GDC...
- Johannes Pfau (24/40) Mar 23 2014 I don't think that's the case here, at least there's no obvious change
- Iain Buclaw (3/43) Mar 23 2014 Can be done, it would be nice to get GCC 4.8/GCC 4.7 on the autotester
- Iain Buclaw (3/18) Mar 23 2014 In this case, it's a GCC GC bug.
- Brad Roberts (15/55) Mar 23 2014 I'm not at all concerned about space, and not sure why most developers w...
- Johannes Pfau (15/39) Mar 24 2014 It's not really space, it's the time needed for a git clone. Cloning gdc
- Iain Buclaw (6/21) Mar 24 2014 If it's taking that long, you can just switch to git+ssh cloning.
- Iain Buclaw (5/22) Mar 23 2014 I'll try to remember to update the snapshot version each time I rebase
- Brad Roberts (4/32) Mar 23 2014 I was referring back to having the repository be complete, not just the ...
- Iain Buclaw (8/29) Mar 24 2014 Still failing with a second unrelated issue. Looks like wrong code
- Iain Buclaw (3/34) Mar 31 2014 Green again. I've also bumped the snapshot version to 20140330. :)
- Brad Roberts (3/38) Mar 31 2014 Good for the green. I'll add support for paying attention to that versi...
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
Iain Buclaw <ibuclaw gdcproject.org> 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
On 3/22/14, 12:02 PM, Iain Buclaw wrote:On 22 March 2014 18:20, Johannes Pfau <nospam example.com> wrote: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.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
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:I don't think that's the case here, at least there's no obvious change that could require a newer snapshot.On 22 March 2014 18:20, Johannes Pfau <nospam example.com> wrote:Has the minimum base gcc version moved forward again?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.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
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>:Can be done, it would be nice to get GCC 4.8/GCC 4.7 on the autotester as well as snapshot builds.On 3/22/14, 12:02 PM, Iain Buclaw wrote:I don't think that's the case here, at least there's no obvious change that could require a newer snapshot.On 22 March 2014 18:20, Johannes Pfau <nospam example.com> wrote:Has the minimum base gcc version moved forward again?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.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
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>:In this case, it's a GCC GC bug. Fix incoming.On 3/22/14, 12:02 PM, Iain Buclaw wrote:I don't think that's the case here, at least there's no obvious change that could require a newer snapshot.On 22 March 2014 18:20, Johannes Pfau <nospam example.com> wrote:Has the minimum base gcc version moved forward again?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 23 2014
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:I don't think that's the case here, at least there's no obvious change that could require a newer snapshot.On 22 March 2014 18:20, Johannes Pfau <nospam example.com> wrote:Has the minimum base gcc version moved forward again?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.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
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.versionIf 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
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>: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).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.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
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
On 3/23/14, 3:44 PM, Iain Buclaw wrote:On 23 March 2014 21:58, Brad Roberts <braddr puremagic.com> wrote: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.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
On 23 March 2014 19:28, Iain Buclaw <ibuclaw gdcproject.org> wrote:On 23 March 2014 09:31, Johannes Pfau <nospam example.com> wrote: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. :-)Am Sat, 22 Mar 2014 14:50:22 -0700 schrieb Brad Roberts <braddr puremagic.com>:In this case, it's a GCC GC bug. Fix incoming.On 3/22/14, 12:02 PM, Iain Buclaw wrote:I don't think that's the case here, at least there's no obvious change that could require a newer snapshot.On 22 March 2014 18:20, Johannes Pfau <nospam example.com> wrote:Has the minimum base gcc version moved forward again?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 24 2014
On 24 March 2014 07:34, Iain Buclaw <ibuclaw gdcproject.org> wrote:On 23 March 2014 19:28, Iain Buclaw <ibuclaw gdcproject.org> wrote:Green again. I've also bumped the snapshot version to 20140330. :) http://d.puremagic.com/test-results/?projectid=2On 23 March 2014 09:31, Johannes Pfau <nospam example.com> wrote: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. :-)Am Sat, 22 Mar 2014 14:50:22 -0700 schrieb Brad Roberts <braddr puremagic.com>:In this case, it's a GCC GC bug. Fix incoming.On 3/22/14, 12:02 PM, Iain Buclaw wrote:I don't think that's the case here, at least there's no obvious change that could require a newer snapshot.On 22 March 2014 18:20, Johannes Pfau <nospam example.com> wrote:Has the minimum base gcc version moved forward again?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 31 2014
On 3/31/14, 10:06 AM, Iain Buclaw wrote:On 24 March 2014 07:34, Iain Buclaw <ibuclaw gdcproject.org> wrote:Good for the green. I'll add support for paying attention to that version file soonish.. but probably not today.On 23 March 2014 19:28, Iain Buclaw <ibuclaw gdcproject.org> wrote:Green again. I've also bumped the snapshot version to 20140330. :) http://d.puremagic.com/test-results/?projectid=2On 23 March 2014 09:31, Johannes Pfau <nospam example.com> wrote: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. :-)Am Sat, 22 Mar 2014 14:50:22 -0700 schrieb Brad Roberts <braddr puremagic.com>:In this case, it's a GCC GC bug. Fix incoming.On 3/22/14, 12:02 PM, Iain Buclaw wrote:I don't think that's the case here, at least there's no obvious change that could require a newer snapshot.On 22 March 2014 18:20, Johannes Pfau <nospam example.com> wrote:Has the minimum base gcc version moved forward again?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 31 2014