On 25 November 2013 09:00, Brad Roberts <braddr@puremagic.com> wrote:
> I noticed that the GDC auto-tester failed the most recent build cycle.  I assumed it was due to having an old snapshot.  After updating it, the build failed in the same way.
>
> The 'old' snapshot:  GCC_VER=4.9-20130929
> The one it's running now:  GCC_VER=4.9-20131117
>
> The errors:
>
> In file included from ../../gcc-4.9-20131117/gcc/d/d-lang.cc:22:0:
> ../../gcc-4.9-20131117/gcc/d/d-system.h:42:21: fatal error: attribs.h: No
> such file or directory
>  #include "attribs.h"
>                      ^
> compilation terminated.
> In file included from ../../gcc-4.9-20131117/gcc/d/d-decls.cc:19:0:
> ../../gcc-4.9-20131117/gcc/d/d-system.h:42:21: fatal error: attribs.h: No
> such file or directory
>  #include "attribs.h"
>                      ^
> compilation terminated.


Yep, there's been some middle-end changes.  Sorry, next time I'll give you heads up.

...Which, incidentally, might come very soon, as there are some other front-end breaking changes in the pipeline with a new wide-int.h header.


Regards
Iain

On 25 November 2013 10:32, Iain Buclaw <ibuclaw@gdcproject.org> wrote:
> On 25 November 2013 09:00, Brad Roberts <braddr@puremagic.com> wrote:
>> I noticed that the GDC auto-tester failed the most recent build cycle.  I assumed it was due to having an old snapshot.  After updating it, the build failed in the same way.
>>
>> The 'old' snapshot:  GCC_VER=4.9-20130929
>> The one it's running now:  GCC_VER=4.9-20131117
>>
>> The errors:
>>
>> In file included from ../../gcc-4.9-20131117/gcc/d/d-lang.cc:22:0:
>> ../../gcc-4.9-20131117/gcc/d/d-system.h:42:21: fatal error: attribs.h: No
>> such file or directory
>>  #include "attribs.h"
>>                      ^
>> compilation terminated.
>> In file included from ../../gcc-4.9-20131117/gcc/d/d-decls.cc:19:0:
>> ../../gcc-4.9-20131117/gcc/d/d-system.h:42:21: fatal error: attribs.h: No
>> such file or directory
>>  #include "attribs.h"
>>                      ^
>> compilation terminated.
>
>
> Yep, there's been some middle-end changes.  Sorry, next time I'll give you heads up.
>
> ...Which, incidentally, might come very soon, as there are some other front-end breaking changes in the pipeline with a new wide-int.h header.
>


And the last GDC change has been untested (so far).

On 11/25/13 2:35 AM, Iain Buclaw wrote:
> On 25 November 2013 10:32, Iain Buclaw <ibuclaw@gdcproject.org> wrote:
>>
>> Yep, there's been some middle-end changes.  Sorry, next time I'll give
>> you heads up.
>>
>> ...Which, incidentally, might come very soon, as there are some other
>> front-end breaking changes in the pipeline with a new wide-int.h
>> header.
>>
>
>
> And the last GDC change has been untested (so far).

Well, if you're not worried that the build/tests are broken, I probably shouldn't be either, but I am pondering on ways of increasing the visibility of the state of the system.  The only 'no work to be done' state is a healthy green master branch.  I'm considering adding a once every X days (daily, weekly, etc) status summary email with what open work there is to be done (broken master, open pulls, etc).

I don't consider it right for master branches to be in a broken state, ever.  But I don't own the code under test, so it's not up to me. :)

On 25 November 2013 19:35, Brad Roberts <braddr@puremagic.com> wrote:
> On 11/25/13 2:35 AM, Iain Buclaw wrote:
>>
>> On 25 November 2013 10:32, Iain Buclaw <ibuclaw@gdcproject.org> wrote:
>>>
>>>
>>> Yep, there's been some middle-end changes.  Sorry, next time I'll give you heads up.
>>>
>>> ...Which, incidentally, might come very soon, as there are some other front-end breaking changes in the pipeline with a new wide-int.h header.
>>>
>>
>>
>> And the last GDC change has been untested (so far).
>
>
> Well, if you're not worried that the build/tests are broken, I probably shouldn't be either, but I am pondering on ways of increasing the visibility of the state of the system.  The only 'no work to be done' state is a healthy green master branch.  I'm considering adding a once every X days (daily, weekly, etc) status summary email with what open work there is to be done (broken master, open pulls, etc).
>
> I don't consider it right for master branches to be in a broken state, ever. But I don't own the code under test, so it's not up to me. :)
>

It's a kind of special case thing.  I'm currently doing this 2.064 merge in small steps (just taking a monthly development snapshot and working my way up because to merge the entire amount of changes is too much to track down breakages).  So it's merge, push, run testsuite, get things stable, repeat at the moment, and will be until 2.064 merge is complete.

On 25 November 2013 20:34, Iain Buclaw <ibuclaw@gdcproject.org> wrote:
> On 25 November 2013 19:35, Brad Roberts <braddr@puremagic.com> wrote:
>> On 11/25/13 2:35 AM, Iain Buclaw wrote:
>>>
>>> On 25 November 2013 10:32, Iain Buclaw <ibuclaw@gdcproject.org> wrote:
>>>>
>>>>
>>>> Yep, there's been some middle-end changes.  Sorry, next time I'll give you heads up.
>>>>
>>>> ...Which, incidentally, might come very soon, as there are some other front-end breaking changes in the pipeline with a new wide-int.h header.
>>>>
>>>
>>>
>>> And the last GDC change has been untested (so far).
>>
>>
>> Well, if you're not worried that the build/tests are broken, I probably shouldn't be either, but I am pondering on ways of increasing the visibility of the state of the system.  The only 'no work to be done' state is a healthy green master branch.  I'm considering adding a once every X days (daily, weekly, etc) status summary email with what open work there is to be done (broken master, open pulls, etc).
>>
>> I don't consider it right for master branches to be in a broken state, ever. But I don't own the code under test, so it's not up to me. :)
>>
>
> It's a kind of special case thing.  I'm currently doing this 2.064 merge in small steps (just taking a monthly development snapshot and working my way up because to merge the entire amount of changes is too much to track down breakages).  So it's merge, push, run testsuite, get things stable, repeat at the moment, and will be until 2.064 merge is complete.

Testsuite should be passing now on latest gdc head and gcc snapshots. Until the next D frontend merge gets done sometime tomorrow.

On 11/25/13 3:00 PM, Iain Buclaw wrote:
> On 25 November 2013 20:34, Iain Buclaw <ibuclaw@gdcproject.org> wrote:
>> On 25 November 2013 19:35, Brad Roberts <braddr@puremagic.com> wrote:
>>> On 11/25/13 2:35 AM, Iain Buclaw wrote:
>>>>
>>>> On 25 November 2013 10:32, Iain Buclaw <ibuclaw@gdcproject.org> wrote:
>>>>>
>>>>>
>>>>> Yep, there's been some middle-end changes.  Sorry, next time I'll give
>>>>> you heads up.
>>>>>
>>>>> ...Which, incidentally, might come very soon, as there are some other
>>>>> front-end breaking changes in the pipeline with a new wide-int.h
>>>>> header.
>>>>>
>>>>
>>>>
>>>> And the last GDC change has been untested (so far).
>>>
>>>
>>> Well, if you're not worried that the build/tests are broken, I probably
>>> shouldn't be either, but I am pondering on ways of increasing the visibility
>>> of the state of the system.  The only 'no work to be done' state is a
>>> healthy green master branch.  I'm considering adding a once every X days
>>> (daily, weekly, etc) status summary email with what open work there is to be
>>> done (broken master, open pulls, etc).
>>>
>>> I don't consider it right for master branches to be in a broken state, ever.
>>> But I don't own the code under test, so it's not up to me. :)
>>>
>>
>> It's a kind of special case thing.  I'm currently doing this 2.064
>> merge in small steps (just taking a monthly development snapshot and
>> working my way up because to merge the entire amount of changes is too
>> much to track down breakages).  So it's merge, push, run testsuite,
>> get things stable, repeat at the moment, and will be until 2.064 merge
>> is complete.
>
> Testsuite should be passing now on latest gdc head and gcc snapshots.
> Until the next D frontend merge gets done sometime tomorrow.
>

Is 20131117 new enough that it should pass?  The most recent build cycle didn't.  Same error.