End of GCC 4.6 Stage 1: October 27, 2010

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
mark@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 <mark@codesourcery.com> 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
> mark@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
mark@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 <mark@codesourcery.com> 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
mark@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 <mark@codesourcery.com> 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
mark@codesourcery.com
(650) 331-3385 x713

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

[Gerald Pfeifer]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 457 bytes --]

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 passes		24917
# of unexpected failures	18
# of expected failures		150
# of unsupported tests		587

		=== gcc Summary ===

# of expected passes		66682
# of unexpected failures	49
# of unexpected successes	3
# of expected failures		199
# of unresolved testcases	3
# of unsupported tests		1311

		=== gfortran Summary ===

# of expected passes		35917
# of unexpected failures	36
# of expected failures		40
# of unsupported tests		101

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

# of expected passes		489
# of unexpected failures	54
# of expected failures		3
# of unsupported tests		15

		=== objc Summary ===

# of expected passes		658
# of unexpected failures	84
# of unsupported tests		20

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

[Richard Guenther]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 557 bytes --]

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 <rguenther@suse.de> 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 <nightstrike@gmail.com> wrote:
> On Mon, Sep 6, 2010 at 5:21 AM, Richard Guenther <rguenther@suse.de> 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<nightstrike@gmail.com>  wrote:
>> On Mon, Sep 6, 2010 at 5:21 AM, Richard Guenther<rguenther@suse.de>  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
<richard.guenther@gmail.com> wrote:
> On Mon, Sep 6, 2010 at 6:19 PM, NightStrike <nightstrike@gmail.com> wrote:
>> On Mon, Sep 6, 2010 at 5:21 AM, Richard Guenther <rguenther@suse.de> 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
> <richard.guenther@gmail.com> wrote:
>> On Mon, Sep 6, 2010 at 6:19 PM, NightStrike <nightstrike@gmail.com> wrote:
>>> On Mon, Sep 6, 2010 at 5:21 AM, Richard Guenther <rguenther@suse.de> 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 <aph@redhat.com> wrote:
> On 09/06/2010 06:18 PM, NightStrike wrote:
>> On Mon, Sep 6, 2010 at 12:21 PM, Richard Guenther
>> <richard.guenther@gmail.com> wrote:
>>> On Mon, Sep 6, 2010 at 6:19 PM, NightStrike <nightstrike@gmail.com> wrote:
>>>> On Mon, Sep 6, 2010 at 5:21 AM, Richard Guenther <rguenther@suse.de> 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 <nightstrike@gmail.com> wrote:
> On Mon, Sep 6, 2010 at 1:24 PM, Andrew Haley <aph@redhat.com> wrote:
>> On 09/06/2010 06:18 PM, NightStrike wrote:
>>> On Mon, Sep 6, 2010 at 12:21 PM, Richard Guenther
>>> <richard.guenther@gmail.com> wrote:
>>>> On Mon, Sep 6, 2010 at 6:19 PM, NightStrike <nightstrike@gmail.com> wrote:
>>>>> On Mon, Sep 6, 2010 at 5:21 AM, Richard Guenther <rguenther@suse.de> 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 <jwakely.gcc@gmail.com> 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 <http://gcc.gnu.org/bugs.html> 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 <dave.korn.cygwin@gmail.com> 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 <nightstrike@gmail.com> wrote:
> On Tue, Sep 21, 2010 at 9:26 AM, Dave Korn <dave.korn.cygwin@gmail.com> 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 <jwakely.gcc@gmail.com>:
> 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_<printf> 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 <jwakely.gcc@gmail.com> 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 <jwakely.gcc@gmail.com> 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]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1726 bytes --]

On Fri, 8 Oct 2010, NightStrike wrote:

> On Thu, Sep 23, 2010 at 9:53 AM, NightStrike <nightstrike@gmail.com> wrote:
> > On Tue, Sep 21, 2010 at 9:26 AM, Dave Korn <dave.korn.cygwin@gmail.com> 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 <rguenther@suse.de> 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]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 650 bytes --]

On Fri, 8 Oct 2010, NightStrike wrote:

> On Fri, Oct 8, 2010 at 5:09 PM, Richard Guenther <rguenther@suse.de> 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 <rguenther@suse.de>
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 <jwakely.gcc@gmail.com> 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 <jwakely.gcc@gmail.com> 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