Jump to page: 1 2
Thread overview
master branch broken
Mar 22, 2014
Johannes Pfau
Mar 22, 2014
Iain Buclaw
Mar 22, 2014
Brad Roberts
Mar 23, 2014
Johannes Pfau
Mar 23, 2014
Iain Buclaw
Mar 23, 2014
Iain Buclaw
Mar 23, 2014
Brad Roberts
Mar 24, 2014
Johannes Pfau
Mar 24, 2014
Iain Buclaw
Mar 23, 2014
Iain Buclaw
Mar 24, 2014
Brad Roberts
Mar 24, 2014
Iain Buclaw
Mar 31, 2014
Iain Buclaw
Mar 31, 2014
Brad Roberts
March 22, 2014
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
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
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
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
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
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
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
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
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
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.  :-)
« First   ‹ Prev
1 2