End of GCC 4.6 Stage 1: October 27, 2010

[Mark Mitchell]

We (GCC RMs) plan to close GCC 4.6 Stage 1 on or or about October 27,
2010 (the closing day of the GCC Summit).  Major features should be
checked in prior to this point.  Please let us know if you have a major
feature that you think you will not be able to get checked in prior to
October 27th.

Thank you,

-- 
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713

Re: End of GCC 4.6 Stage 1: October 27, 2010

[NightStrike]

We would like x86_64-w64-mingw32 to become a secondary target for 4.6.
 What has to be checked off for that to happen?  I have an
auto-testsuite-thinger running constantly now and posting results to
the ML (it takes several days to do a full dl/build/test, so it's not
daily, but it's continuous).

On Tue, Aug 31, 2010 at 11:59 AM, Mark Mitchell  wrote:
> We (GCC RMs) plan to close GCC 4.6 Stage 1 on or or about October 27,
> 2010 (the closing day of the GCC Summit).  Major features should be
> checked in prior to this point.  Please let us know if you have a major
> feature that you think you will not be able to get checked in prior to
> October 27th.
>
> Thank you,
>
> --
> Mark Mitchell
> CodeSourcery
> m...@codesourcery.com
> (650) 331-3385 x713
>

Re: End of GCC 4.6 Stage 1: October 27, 2010

[Mark Mitchell]

On 9/4/2010 9:23 PM, NightStrike wrote:

> We would like x86_64-w64-mingw32 to become a secondary target for 4.6.

Who is "we" in this context?

> What has to be checked off for that to happen? 

It's not so much a matter of "checking off".  It's a combination of the
SC's perception of the importance of the target and the technical stats
of the port.  I can raise the issue with the SC, if you like, but,
personally, I'm not sure that 64-bit Windows is significant enough as a
target platform for GCC to merit that status.

Thanks,

-- 
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713

Re: End of GCC 4.6 Stage 1: October 27, 2010

[NightStrike]

On Sun, Sep 5, 2010 at 2:03 PM, Mark Mitchell  wrote:
> On 9/4/2010 9:23 PM, NightStrike wrote:
>
>> We would like x86_64-w64-mingw32 to become a secondary target for 4.6.
>
> Who is "we" in this context?

Sorry, that would be Kai Tietz, myself, and the entire mingw-w64.sf.net project.

>> What has to be checked off for that to happen?
>
> It's not so much a matter of "checking off".  It's a combination of the
> SC's perception of the importance of the target and the technical stats
> of the port.  I can raise the issue with the SC, if you like, but,
> personally, I'm not sure that 64-bit Windows is significant enough as a
> target platform for GCC to merit that status.

Ouch.  What criteria do you use for that analysis?  I will endeavor to
prove our importance :)

Note that 32-bit windows is already a secondary platform.

Re: End of GCC 4.6 Stage 1: October 27, 2010

[Mark Mitchell]

On 9/5/2010 11:23 AM, NightStrike wrote:

>> It's not so much a matter of "checking off".  It's a combination of the
>> SC's perception of the importance of the target and the technical stats
>> of the port.  I can raise the issue with the SC, if you like, but,
>> personally, I'm not sure that 64-bit Windows is significant enough as a
>> target platform for GCC to merit that status.
> 
> Ouch.  What criteria do you use for that analysis? 

I can't say what criteria the SC uses; I don't know what basis other SC
members use to decide.

I use my own instincts (which, I admit, is not a scientific basis) for
deciding.  I spend much of my life talking to various stakeholders in
GCC, and so I have a reasonable feel for where people are presently
using GCC, and where they would like to use it.  Thus far, I've
certainly heard of some interest in 64-bit Windows, but nowhere near as
much as 32-bit Windows or Cygwin.

I certainly don't mind raising the issue, if you want me to do that; I'm
happy to carry messages to the SC independent of my own opinions.

-- 
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713

Re: End of GCC 4.6 Stage 1: October 27, 2010

[NightStrike]

On Sun, Sep 5, 2010 at 2:29 PM, Mark Mitchell  wrote:
> On 9/5/2010 11:23 AM, NightStrike wrote:
>
>>> It's not so much a matter of "checking off".  It's a combination of the
>>> SC's perception of the importance of the target and the technical stats
>>> of the port.  I can raise the issue with the SC, if you like, but,
>>> personally, I'm not sure that 64-bit Windows is significant enough as a
>>> target platform for GCC to merit that status.
>>
>> Ouch.  What criteria do you use for that analysis?
>
> I can't say what criteria the SC uses; I don't know what basis other SC
> members use to decide.
>
> I use my own instincts (which, I admit, is not a scientific basis) for
> deciding.  I spend much of my life talking to various stakeholders in
> GCC, and so I have a reasonable feel for where people are presently
> using GCC, and where they would like to use it.  Thus far, I've
> certainly heard of some interest in 64-bit Windows, but nowhere near as
> much as 32-bit Windows or Cygwin.
>
> I certainly don't mind raising the issue, if you want me to do that; I'm
> happy to carry messages to the SC independent of my own opinions.

Yes, definitely bring it up.  I'm just trying to get more cards
stacked in our favor :)

Re: End of GCC 4.6 Stage 1: October 27, 2010

[Mark Mitchell]

On 9/5/2010 11:34 AM, NightStrike wrote:

>> I certainly don't mind raising the issue, if you want me to do that; I'm
>> happy to carry messages to the SC independent of my own opinions.
> 
> Yes, definitely bring it up.  I'm just trying to get more cards
> stacked in our favor :)

OK, I've asked the SC to consider it.

-- 
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713

Re: End of GCC 4.6 Stage 1: October 27, 2010

[Gerald Pfeifer]

On Sun, 5 Sep 2010, NightStrike wrote:
> Yes, definitely bring it up.  I'm just trying to get more cards
> stacked in our favor :)

Do you have a pointer to testresults you'd like us to use for reference?

>From our release criteria, for secondary platforms we have:

  • The compiler bootstraps successfully, and the C++ runtime library
builds.
  • The DejaGNU testsuite has been run, and a substantial majority of the 
tests pass.

Gerald

Re: End of GCC 4.6 Stage 1: October 27, 2010

[Tobias Burnus]

Gerald Pfeifer wrote:

Do you have a pointer to testresults you'd like us to use for reference?

 From our release criteria, for secondary platforms we have:

   • The compiler bootstraps successfully, and the C++ runtime library
 builds.
   • The DejaGNU testsuite has been run, and a substantial majority of the
 tests pass.


See for instance:
  http://gcc.gnu.org/ml/gcc-testresults/2010-09/msg00295.html

=== g++ Summary ===

# of expected passes24917
# of unexpected failures18
# of expected failures  150
# of unsupported tests  587

=== gcc Summary ===

# of expected passes66682
# of unexpected failures49
# of unexpected successes   3
# of expected failures  199
# of unresolved testcases   3
# of unsupported tests  1311

=== gfortran Summary ===

# of expected passes35917
# of unexpected failures36
# of expected failures  40
# of unsupported tests  101

=== obj-c++ Summary ===

# of expected passes489
# of unexpected failures54
# of expected failures  3
# of unsupported tests  15

=== objc Summary ===

# of expected passes658
# of unexpected failures84
# of unsupported tests  20

Re: End of GCC 4.6 Stage 1: October 27, 2010

[Richard Guenther]

On Mon, 6 Sep 2010, Tobias Burnus wrote:

> Gerald Pfeifer wrote:
> > Do you have a pointer to testresults you'd like us to use for reference?
> > 
> >  From our release criteria, for secondary platforms we have:
> > 
> >• The compiler bootstraps successfully, and the C++ runtime library
> >  builds.
> >• The DejaGNU testsuite has been run, and a substantial majority of the
> >  tests pass.
> 
> See for instance:
>   http://gcc.gnu.org/ml/gcc-testresults/2010-09/msg00295.html

There are no libstdc++ results in that.

Richard.

Re: End of GCC 4.6 Stage 1: October 27, 2010

[NightStrike]

On Mon, Sep 6, 2010 at 5:21 AM, Richard Guenther  wrote:
> On Mon, 6 Sep 2010, Tobias Burnus wrote:
>
>> Gerald Pfeifer wrote:
>> > Do you have a pointer to testresults you'd like us to use for reference?
>> >
>> >  From our release criteria, for secondary platforms we have:
>> >
>> >    • The compiler bootstraps successfully, and the C++ runtime library
>> >      builds.
>> >    • The DejaGNU testsuite has been run, and a substantial majority of the
>> >      tests pass.
>>
>> See for instance:
>>   http://gcc.gnu.org/ml/gcc-testresults/2010-09/msg00295.html
>
> There are no libstdc++ results in that.
>
> Richard.

This is true.  I always run make check-gcc.  What should I be doing instead?

Re: End of GCC 4.6 Stage 1: October 27, 2010

[Richard Guenther]

On Mon, Sep 6, 2010 at 6:19 PM, NightStrike  wrote:
> On Mon, Sep 6, 2010 at 5:21 AM, Richard Guenther  wrote:
>> On Mon, 6 Sep 2010, Tobias Burnus wrote:
>>
>>> Gerald Pfeifer wrote:
>>> > Do you have a pointer to testresults you'd like us to use for reference?
>>> >
>>> >  From our release criteria, for secondary platforms we have:
>>> >
>>> >    • The compiler bootstraps successfully, and the C++ runtime library
>>> >      builds.
>>> >    • The DejaGNU testsuite has been run, and a substantial majority of the
>>> >      tests pass.
>>>
>>> See for instance:
>>>   http://gcc.gnu.org/ml/gcc-testresults/2010-09/msg00295.html
>>
>> There are no libstdc++ results in that.
>>
>> Richard.
>
> This is true.  I always run make check-gcc.  What should I be doing instead?

make -k check

Re: End of GCC 4.6 Stage 1: October 27, 2010

[Tim Prince]

 On 9/6/2010 9:21 AM, Richard Guenther wrote:

On Mon, Sep 6, 2010 at 6:19 PM, NightStrike  wrote:

On Mon, Sep 6, 2010 at 5:21 AM, Richard Guenther  wrote:

On Mon, 6 Sep 2010, Tobias Burnus wrote:


Gerald Pfeifer wrote:

Do you have a pointer to testresults you'd like us to use for reference?

  From our release criteria, for secondary platforms we have:

• The compiler bootstraps successfully, and the C++ runtime library
  builds.
• The DejaGNU testsuite has been run, and a substantial majority of the
  tests pass.

See for instance:
   http://gcc.gnu.org/ml/gcc-testresults/2010-09/msg00295.html

There are no libstdc++ results in that.

Richard.

This is true.  I always run make check-gcc.  What should I be doing instead?

make -k check

make check-c++ runs both g++ and libstdc++-v3 testsuites.

--
Tim Prince

Re: End of GCC 4.6 Stage 1: October 27, 2010

[NightStrike]

On Mon, Sep 6, 2010 at 12:21 PM, Richard Guenther
 wrote:
> On Mon, Sep 6, 2010 at 6:19 PM, NightStrike  wrote:
>> On Mon, Sep 6, 2010 at 5:21 AM, Richard Guenther  wrote:
>>> On Mon, 6 Sep 2010, Tobias Burnus wrote:
>>>
 Gerald Pfeifer wrote:
 > Do you have a pointer to testresults you'd like us to use for reference?
 >
 >  From our release criteria, for secondary platforms we have:
 >
 >    • The compiler bootstraps successfully, and the C++ runtime library
 >      builds.
 >    • The DejaGNU testsuite has been run, and a substantial majority of 
 > the
 >      tests pass.

 See for instance:
   http://gcc.gnu.org/ml/gcc-testresults/2010-09/msg00295.html
>>>
>>> There are no libstdc++ results in that.
>>>
>>> Richard.
>>
>> This is true.  I always run make check-gcc.  What should I be doing instead?
>
> make -k check
>

Ugh.  And I thought I was golden :)

This apparently requires autogen to do something about
fixincludes/check.tpl.  I have no idea what that is or what that
means

I'll report back.  Any insight you can provide is greatly appreciated.

Re: End of GCC 4.6 Stage 1: October 27, 2010

[Andrew Haley]

On 09/06/2010 06:18 PM, NightStrike wrote:
> On Mon, Sep 6, 2010 at 12:21 PM, Richard Guenther
>  wrote:
>> On Mon, Sep 6, 2010 at 6:19 PM, NightStrike  wrote:
>>> On Mon, Sep 6, 2010 at 5:21 AM, Richard Guenther  wrote:
 On Mon, 6 Sep 2010, Tobias Burnus wrote:

> Gerald Pfeifer wrote:
>> Do you have a pointer to testresults you'd like us to use for reference?
>>
>>  From our release criteria, for secondary platforms we have:
>>
>>• The compiler bootstraps successfully, and the C++ runtime library
>>  builds.
>>• The DejaGNU testsuite has been run, and a substantial majority of 
>> the
>>  tests pass.
>
> See for instance:
>   http://gcc.gnu.org/ml/gcc-testresults/2010-09/msg00295.html

 There are no libstdc++ results in that.

 Richard.
>>>
>>> This is true.  I always run make check-gcc.  What should I be doing instead?
>>
>> make -k check
>>
> 
> Ugh.  And I thought I was golden :)
> 
> This apparently requires autogen to do something about
> fixincludes/check.tpl.  I have no idea what that is or what that
> means

Just ignore the fixincludes test results.

Andrew.

Re: End of GCC 4.6 Stage 1: October 27, 2010

[NightStrike]

On Mon, Sep 6, 2010 at 1:24 PM, Andrew Haley  wrote:
> On 09/06/2010 06:18 PM, NightStrike wrote:
>> On Mon, Sep 6, 2010 at 12:21 PM, Richard Guenther
>>  wrote:
>>> On Mon, Sep 6, 2010 at 6:19 PM, NightStrike  wrote:
 On Mon, Sep 6, 2010 at 5:21 AM, Richard Guenther  wrote:
> On Mon, 6 Sep 2010, Tobias Burnus wrote:
>
>> Gerald Pfeifer wrote:
>>> Do you have a pointer to testresults you'd like us to use for reference?
>>>
>>>  From our release criteria, for secondary platforms we have:
>>>
>>>    • The compiler bootstraps successfully, and the C++ runtime library
>>>      builds.
>>>    • The DejaGNU testsuite has been run, and a substantial majority of 
>>> the
>>>      tests pass.
>>
>> See for instance:
>>   http://gcc.gnu.org/ml/gcc-testresults/2010-09/msg00295.html
>
> There are no libstdc++ results in that.
>
> Richard.

 This is true.  I always run make check-gcc.  What should I be doing 
 instead?
>>>
>>> make -k check
>>>
>>
>> Ugh.  And I thought I was golden :)
>>
>> This apparently requires autogen to do something about
>> fixincludes/check.tpl.  I have no idea what that is or what that
>> means
>
> Just ignore the fixincludes test results.
>
> Andrew.
>

Thanks!  Life just got easier again :)

Running it with -j5.  Hopefully cygwin doesn't barf on that.. I know
cygwin used to have issues with -j.

Re: End of GCC 4.6 Stage 1: October 27, 2010

[NightStrike]

On Mon, Sep 6, 2010 at 1:32 PM, NightStrike  wrote:
> On Mon, Sep 6, 2010 at 1:24 PM, Andrew Haley  wrote:
>> On 09/06/2010 06:18 PM, NightStrike wrote:
>>> On Mon, Sep 6, 2010 at 12:21 PM, Richard Guenther
>>>  wrote:
 On Mon, Sep 6, 2010 at 6:19 PM, NightStrike  wrote:
> On Mon, Sep 6, 2010 at 5:21 AM, Richard Guenther  
> wrote:
>> On Mon, 6 Sep 2010, Tobias Burnus wrote:
>>
>>> Gerald Pfeifer wrote:
 Do you have a pointer to testresults you'd like us to use for 
 reference?

  From our release criteria, for secondary platforms we have:

    • The compiler bootstraps successfully, and the C++ runtime library
      builds.
    • The DejaGNU testsuite has been run, and a substantial majority of 
 the
      tests pass.
>>>
>>> See for instance:
>>>   http://gcc.gnu.org/ml/gcc-testresults/2010-09/msg00295.html
>>
>> There are no libstdc++ results in that.
>>
>> Richard.
>
> This is true.  I always run make check-gcc.  What should I be doing 
> instead?

 make -k check

>>>
>>> Ugh.  And I thought I was golden :)
>>>
>>> This apparently requires autogen to do something about
>>> fixincludes/check.tpl.  I have no idea what that is or what that
>>> means
>>
>> Just ignore the fixincludes test results.
>>
>> Andrew.
>>
>
> Thanks!  Life just got easier again :)
>
> Running it with -j5.  Hopefully cygwin doesn't barf on that.. I know
> cygwin used to have issues with -j.
>

Ok, so it took a while to eventually find out that cygwin still
malfunctions with -j, and I get lots of "fork() blows because it can't
figure out how to find ubiquitous resources" errors.  However, I
eventually got this to finish:

http://gcc.gnu.org/ml/gcc-testresults/2010-09/msg01864.html

So there's a complete testsuite that includes libstdc++ this time.  I
will now have this running continuously.

Note that you won't see results every day -- it takes a LONG time to
do this, mostly because I can't do -j on cygwin.  I imagine results
will be every 4 days or so if I run continuously.

Is this enough now for us to qualify?

Re: End of GCC 4.6 Stage 1: October 27, 2010

[Jonathan Wakely]

On 20 September 2010 17:33, NightStrike wrote:
>
> Ok, so it took a while to eventually find out that cygwin still
> malfunctions with -j, and I get lots of "fork() blows because it can't
> figure out how to find ubiquitous resources" errors.  However, I
> eventually got this to finish:
>
> http://gcc.gnu.org/ml/gcc-testresults/2010-09/msg01864.html
>
> So there's a complete testsuite that includes libstdc++ this time.  I
> will now have this running continuously.
>
> Note that you won't see results every day -- it takes a LONG time to
> do this, mostly because I can't do -j on cygwin.  I imagine results
> will be every 4 days or so if I run continuously.
>
> Is this enough now for us to qualify?

Could you send me your libstdc++.log file?
I'm curious about some of the libstdc++ failures, which are in pretty
simple tests that shouldn't be target dependent.  There might be
something simple in testsuite_hooks.h or another common file that
causes all those failures.

Re: End of GCC 4.6 Stage 1: October 27, 2010

[NightStrike]

On Mon, Sep 20, 2010 at 2:22 PM, Jonathan Wakely  wrote:
> On 20 September 2010 17:33, NightStrike wrote:
>>
>> Ok, so it took a while to eventually find out that cygwin still
>> malfunctions with -j, and I get lots of "fork() blows because it can't
>> figure out how to find ubiquitous resources" errors.  However, I
>> eventually got this to finish:
>>
>> http://gcc.gnu.org/ml/gcc-testresults/2010-09/msg01864.html
>>
>> So there's a complete testsuite that includes libstdc++ this time.  I
>> will now have this running continuously.
>>
>> Note that you won't see results every day -- it takes a LONG time to
>> do this, mostly because I can't do -j on cygwin.  I imagine results
>> will be every 4 days or so if I run continuously.
>>
>> Is this enough now for us to qualify?
>
> Could you send me your libstdc++.log file?
> I'm curious about some of the libstdc++ failures, which are in pretty
> simple tests that shouldn't be target dependent.  There might be
> something simple in testsuite_hooks.h or another common file that
> causes all those failures.
>

I already killed that build, so I'll have to do it on the next one.
The toolchain is broken once again here:

x86_64-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -I../../../build/mingw/mingw-w64-crt
 -m32 -I../../../build/mingw/mingw-w64-crt/include -D_CRTBLD -I/tmp/build/root/x
86_64-w64-mingw32/include   -pipe -std=gnu99 -Wall -Wextra -Wformat -Wstrict-ali
asing -Wshadow -Wpacked -Winline -Wimplicit-function-declaration -Wmissing-noret
urn -Wmissing-prototypes -g -O2 -MT math/lib32_libmingwex_a-sf_erf.o -MD -MP -MF
 math/.deps/lib32_libmingwex_a-sf_erf.Tpo -c -o math/lib32_libmingwex_a-sf_erf.o
 `test -f 'math/sf_erf.c' || echo '../../../build/mingw/mingw-w64-crt/'`math/sf_
erf.c
../../../build/mingw/mingw-w64-crt/math/sf_erf.c: In function `__trunc_float_wor
d.isra.0':
../../../build/mingw/mingw-w64-crt/math/sf_erf.c:268:1: internal compiler error:
 tree check: expected var_decl, have debug_expr_decl in const_value_known_p, at
varpool.c:375
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[2]: *** [math/lib32_libmingwex_a-sf_erf.o] Error 1
make[2]: Leaving directory `/tmp/build/mingw/obj'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/tmp/build/mingw/obj'
make: *** [build/mingw/obj/.compile.marker] Error 2


so it'll have to wait :( :(

Re: End of GCC 4.6 Stage 1: October 27, 2010

[Dave Korn]

On 21/09/2010 02:51, NightStrike wrote:

> The toolchain is broken once again here:
> 
> x86_64-w64-mingw32-gcc -DHAVE_CONFIG_H -I. 
> -I../../../build/mingw/mingw-w64-crt
>  -m32 -I../../../build/mingw/mingw-w64-crt/include -D_CRTBLD 
> -I/tmp/build/root/x
> 86_64-w64-mingw32/include   -pipe -std=gnu99 -Wall -Wextra -Wformat 
> -Wstrict-ali
> asing -Wshadow -Wpacked -Winline -Wimplicit-function-declaration 
> -Wmissing-noret
> urn -Wmissing-prototypes -g -O2 -MT math/lib32_libmingwex_a-sf_erf.o -MD -MP 
> -MF
>  math/.deps/lib32_libmingwex_a-sf_erf.Tpo -c -o 
> math/lib32_libmingwex_a-sf_erf.o
>  `test -f 'math/sf_erf.c' || echo 
> '../../../build/mingw/mingw-w64-crt/'`math/sf_
> erf.c
> ../../../build/mingw/mingw-w64-crt/math/sf_erf.c: In function 
> `__trunc_float_wor
> d.isra.0':
> ../../../build/mingw/mingw-w64-crt/math/sf_erf.c:268:1: internal compiler 
> error:
>  tree check: expected var_decl, have debug_expr_decl in const_value_known_p, 
> at
> varpool.c:375


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45738

cheers,
  DaveK

Re: End of GCC 4.6 Stage 1: October 27, 2010

[NightStrike]

On Tue, Sep 21, 2010 at 9:26 AM, Dave Korn  wrote:
> On 21/09/2010 02:51, NightStrike wrote:
>
>> The toolchain is broken once again here:
>>
>> x86_64-w64-mingw32-gcc -DHAVE_CONFIG_H -I. 
>> -I../../../build/mingw/mingw-w64-crt
>>  -m32 -I../../../build/mingw/mingw-w64-crt/include -D_CRTBLD 
>> -I/tmp/build/root/x
>> 86_64-w64-mingw32/include   -pipe -std=gnu99 -Wall -Wextra -Wformat 
>> -Wstrict-ali
>> asing -Wshadow -Wpacked -Winline -Wimplicit-function-declaration 
>> -Wmissing-noret
>> urn -Wmissing-prototypes -g -O2 -MT math/lib32_libmingwex_a-sf_erf.o -MD -MP 
>> -MF
>>  math/.deps/lib32_libmingwex_a-sf_erf.Tpo -c -o 
>> math/lib32_libmingwex_a-sf_erf.o
>>  `test -f 'math/sf_erf.c' || echo 
>> '../../../build/mingw/mingw-w64-crt/'`math/sf_
>> erf.c
>> ../../../build/mingw/mingw-w64-crt/math/sf_erf.c: In function 
>> `__trunc_float_wor
>> d.isra.0':
>> ../../../build/mingw/mingw-w64-crt/math/sf_erf.c:268:1: internal compiler 
>> error:
>>  tree check: expected var_decl, have debug_expr_decl in const_value_known_p, 
>> at
>> varpool.c:375
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45738
>
>    cheers,
>      DaveK
>

Thanks.  Hope it gets fixed fast.  I will post a new testsuite once
that bug is closed.

Re: End of GCC 4.6 Stage 1: October 27, 2010

[NightStrike]

On Thu, Sep 23, 2010 at 9:53 AM, NightStrike  wrote:
> On Tue, Sep 21, 2010 at 9:26 AM, Dave Korn  wrote:
>> On 21/09/2010 02:51, NightStrike wrote:
>>
>>> The toolchain is broken once again here:
>>>
>>> x86_64-w64-mingw32-gcc -DHAVE_CONFIG_H -I. 
>>> -I../../../build/mingw/mingw-w64-crt
>>>  -m32 -I../../../build/mingw/mingw-w64-crt/include -D_CRTBLD 
>>> -I/tmp/build/root/x
>>> 86_64-w64-mingw32/include   -pipe -std=gnu99 -Wall -Wextra -Wformat 
>>> -Wstrict-ali
>>> asing -Wshadow -Wpacked -Winline -Wimplicit-function-declaration 
>>> -Wmissing-noret
>>> urn -Wmissing-prototypes -g -O2 -MT math/lib32_libmingwex_a-sf_erf.o -MD 
>>> -MP -MF
>>>  math/.deps/lib32_libmingwex_a-sf_erf.Tpo -c -o 
>>> math/lib32_libmingwex_a-sf_erf.o
>>>  `test -f 'math/sf_erf.c' || echo 
>>> '../../../build/mingw/mingw-w64-crt/'`math/sf_
>>> erf.c
>>> ../../../build/mingw/mingw-w64-crt/math/sf_erf.c: In function 
>>> `__trunc_float_wor
>>> d.isra.0':
>>> ../../../build/mingw/mingw-w64-crt/math/sf_erf.c:268:1: internal compiler 
>>> error:
>>>  tree check: expected var_decl, have debug_expr_decl in 
>>> const_value_known_p, at
>>> varpool.c:375
>>
>>
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45738
>>
>>    cheers,
>>      DaveK
>>
>
> Thanks.  Hope it gets fixed fast.  I will post a new testsuite once
> that bug is closed.
>

http://gcc.gnu.org/ml/gcc-testresults/2010-10/msg00624.html

Re: End of GCC 4.6 Stage 1: October 27, 2010

[Jonathan Wakely]

On 8 October 2010 16:56, NightStrike wrote:
>
> http://gcc.gnu.org/ml/gcc-testresults/2010-10/msg00624.html

There are a lot of failures there, including quite a few tests which
don't look platform-dependent.

Can you send me the libstdc++-v3/testsuite/libstdc++.log so I can see
what's failing?  A lot of them look locale-related, so could just be
disabled if the platform doesn't support them.  Others are more
concerning and shouldn't be failing on any platform.

Re: End of GCC 4.6 Stage 1: October 27, 2010

[Kai Tietz]

2010/10/8 Jonathan Wakely :
> On 8 October 2010 16:56, NightStrike wrote:
>>
>> http://gcc.gnu.org/ml/gcc-testresults/2010-10/msg00624.html
>
> There are a lot of failures there, including quite a few tests which
> don't look platform-dependent.
>
> Can you send me the libstdc++-v3/testsuite/libstdc++.log so I can see
> what's failing?  A lot of them look locale-related, so could just be
> disabled if the platform doesn't support them.  Others are more
> concerning and shouldn't be failing on any platform.
>

The locale stuff is related to printf-family and 'long double' types.
Here is a special handling for printf functions necessary to use here
instead the gnu-version of printf-family (_mingw_ routines) we
provide.

Kai

-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination

Re: End of GCC 4.6 Stage 1: October 27, 2010

[NightStrike]

On Fri, Oct 8, 2010 at 12:06 PM, Jonathan Wakely  wrote:
> On 8 October 2010 16:56, NightStrike wrote:
>>
>> http://gcc.gnu.org/ml/gcc-testresults/2010-10/msg00624.html
>
> There are a lot of failures there, including quite a few tests which
> don't look platform-dependent.
>
> Can you send me the libstdc++-v3/testsuite/libstdc++.log so I can see
> what's failing?  A lot of them look locale-related, so could just be
> disabled if the platform doesn't support them.  Others are more
> concerning and shouldn't be failing on any platform.
>

Sent log offlist

Re: End of GCC 4.6 Stage 1: October 27, 2010

[Jonathan Wakely]

Most of the failing libstdc++ tests which shouldn't be
platform-dependent fail with this message:
sh: /usr/bin/stty: Bad address

libstdc++-v3/config/os/mingw32/error_constants.h is missing several
entries, causing failures in the 19_diagnostics tests.

There are a few failures in 23_containers/vector/ext_pointer which
might be caused by an inttype definition on the platform, I'm not
sure.  A bugzilla PR should probably be opened if there isn't one
already.

Re: End of GCC 4.6 Stage 1: October 27, 2010

[NightStrike]

On Fri, Oct 8, 2010 at 2:04 PM, Jonathan Wakely  wrote:
> Most of the failing libstdc++ tests which shouldn't be
> platform-dependent fail with this message:
> sh: /usr/bin/stty: Bad address

This Bad address stuff is due to some conflict with cygwin.  We really
need to work with cygwin folks to find a proper fix, but are having
difficulty.

Dave, can you work with Kai to help troubleshoot that, by any chance?

Re: End of GCC 4.6 Stage 1: October 27, 2010

[Richard Guenther]

On Fri, 8 Oct 2010, NightStrike wrote:

> On Thu, Sep 23, 2010 at 9:53 AM, NightStrike  wrote:
> > On Tue, Sep 21, 2010 at 9:26 AM, Dave Korn  
> > wrote:
> >> On 21/09/2010 02:51, NightStrike wrote:
> >>
> >>> The toolchain is broken once again here:
> >>>
> >>> x86_64-w64-mingw32-gcc -DHAVE_CONFIG_H -I. 
> >>> -I../../../build/mingw/mingw-w64-crt
> >>>  -m32 -I../../../build/mingw/mingw-w64-crt/include -D_CRTBLD 
> >>> -I/tmp/build/root/x
> >>> 86_64-w64-mingw32/include   -pipe -std=gnu99 -Wall -Wextra -Wformat 
> >>> -Wstrict-ali
> >>> asing -Wshadow -Wpacked -Winline -Wimplicit-function-declaration 
> >>> -Wmissing-noret
> >>> urn -Wmissing-prototypes -g -O2 -MT math/lib32_libmingwex_a-sf_erf.o -MD 
> >>> -MP -MF
> >>>  math/.deps/lib32_libmingwex_a-sf_erf.Tpo -c -o 
> >>> math/lib32_libmingwex_a-sf_erf.o
> >>>  `test -f 'math/sf_erf.c' || echo 
> >>> '../../../build/mingw/mingw-w64-crt/'`math/sf_
> >>> erf.c
> >>> ../../../build/mingw/mingw-w64-crt/math/sf_erf.c: In function 
> >>> `__trunc_float_wor
> >>> d.isra.0':
> >>> ../../../build/mingw/mingw-w64-crt/math/sf_erf.c:268:1: internal compiler 
> >>> error:
> >>>  tree check: expected var_decl, have debug_expr_decl in 
> >>> const_value_known_p, at
> >>> varpool.c:375
> >>
> >>
> >> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45738
> >>
> >>    cheers,
> >>      DaveK
> >>
> >
> > Thanks.  Hope it gets fixed fast.  I will post a new testsuite once
> > that bug is closed.
> >
> 
> http://gcc.gnu.org/ml/gcc-testresults/2010-10/msg00624.html

Please also post results for the 4.5 branch.  I think it doesn't make
any sense to include a target in the list of primary or secondary
targets if it didn't work reasonably for at least one release.

Thanks,
Richard.

Re: End of GCC 4.6 Stage 1: October 27, 2010

[NightStrike]

On Fri, Oct 8, 2010 at 5:09 PM, Richard Guenther  wrote:

> Please also post results for the 4.5 branch.  I think it doesn't make
> any sense to include a target in the list of primary or secondary
> targets if it didn't work reasonably for at least one release.
>
> Thanks,
> Richard.

Ok.  Does that have to be done regularly?

Re: End of GCC 4.6 Stage 1: October 27, 2010

[Richard Guenther]

On Fri, 8 Oct 2010, NightStrike wrote:

> On Fri, Oct 8, 2010 at 5:09 PM, Richard Guenther  wrote:
> 
> > Please also post results for the 4.5 branch.  I think it doesn't make
> > any sense to include a target in the list of primary or secondary
> > targets if it didn't work reasonably for at least one release.
> >
> > Thanks,
> > Richard.
> 
> Ok.  Does that have to be done regularly?

Not as regularly as for trunk.  But catching regressions on a
branch is still important.

Richard.

-- 
Richard Guenther 
Novell / SUSE Labs
SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 - GF: Markus Rex

Re: End of GCC 4.6 Stage 1: October 27, 2010

[Dave Korn]

On 08/10/2010 19:10, NightStrike wrote:
> On Fri, Oct 8, 2010 at 2:04 PM, Jonathan Wakely  wrote:
>> Most of the failing libstdc++ tests which shouldn't be
>> platform-dependent fail with this message:
>> sh: /usr/bin/stty: Bad address
> 
> This Bad address stuff is due to some conflict with cygwin.  We really
> need to work with cygwin folks to find a proper fix, but are having
> difficulty.
> 
> Dave, can you work with Kai to help troubleshoot that, by any chance?

  I'm pretty busy at the moment, and you're the one who actually has the
problem manifesting itself, plus all the log files and build dirs that you'd
need to figure out what it is that's going wrong.

cheers,
  DaveK

Re: End of GCC 4.6 Stage 1: October 27, 2010

[NightStrike]

On Fri, Oct 8, 2010 at 12:06 PM, Jonathan Wakely  wrote:
> On 8 October 2010 16:56, NightStrike wrote:
>>
>> http://gcc.gnu.org/ml/gcc-testresults/2010-10/msg00624.html
>
> There are a lot of failures there, including quite a few tests which
> don't look platform-dependent.
>
> Can you send me the libstdc++-v3/testsuite/libstdc++.log so I can see
> what's failing?  A lot of them look locale-related, so could just be
> disabled if the platform doesn't support them.  Others are more
> concerning and shouldn't be failing on any platform.
>

Updated tests:
http://gcc.gnu.org/ml/gcc-testresults/2011-02/msg02657.html