Thread overview | ||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
March 22, 2014 master branch broken | ||||
---|---|---|---|---|
| ||||
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) |
March 22, 2014 Re: master branch broken | ||||
---|---|---|---|---|
| ||||
Posted in reply to Johannes Pfau | 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.
|
March 22, 2014 Re: master branch broken | ||||
---|---|---|---|---|
| ||||
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.
|
March 23, 2014 Re: master branch broken | ||||
---|---|---|---|---|
| ||||
Posted in reply to Brad Roberts | 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. |
March 23, 2014 Re: master branch broken | ||||
---|---|---|---|---|
| ||||
Posted in reply to Johannes Pfau | 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.
|
March 23, 2014 Re: master branch broken | ||||
---|---|---|---|---|
| ||||
Posted in reply to Johannes Pfau | 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.
|
March 23, 2014 Re: master branch broken | ||||
---|---|---|---|---|
| ||||
Posted in reply to Johannes Pfau | 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.
>
|
March 23, 2014 Re: master branch broken | ||||
---|---|---|---|---|
| ||||
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 |
March 24, 2014 Re: master branch broken | ||||
---|---|---|---|---|
| ||||
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.
|
March 24, 2014 Re: master branch broken | ||||
---|---|---|---|---|
| ||||
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. :-)
|
Copyright © 1999-2021 by the D Language Foundation