Re: # of unexpected failures 768 ?

Re: # of unexpected failures 768 ?

[Dennis Clarke]

> On 31 October 2011 15:33, Rainer Orth wrote:
>> As an asside, I'd suggest to considerably reduce your set of configure
>> options: many of them are the default (like --without-gnu-ld
>> --with-ld=/usr/ccs/bin/ld, --enable-nls, --enable-threads=posix,
>> --enable-shared, --enable-multilib, --host=i386-pc-solaris2.8
>> --build=i386-pc-solaris2.8) or unnecessary
>> (--enable-stage1-languages=c).
>
> Yes, adding completely redundant options looks like cargo cult
> programming and just confuses anyone using the compiler who tries to
> work out how it was configured.
>
>> I'm uncertain if Solaris 8/x86 still supports bare i386 machines, so it
>> might be better to keep the default of pentiumpro instead.
>
> Solaris 8 won't run on anything less than pentium, I recently
> convinced someone else to stop building GCC for i386 on Solaris:
>
> http://gcc.gnu.org/ml/gcc-help/2011-10/msg00005.html

The Os is on Vintage support until March 2012. Also, I never had problems
with it before. As for "completely redundant options" I have been building
gcc like this for a while. also never a problem before.

This is a case of "magic configure incantation" required ? I certainly
hope not.

Dennis



-- 
--
http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x1D936C72FA35B44B
+-------------------------+-----------------------------------+
| Dennis Clarke           | Solaris and Linux and Open Source |
| dclarke@blastwave.org   | Respect for open standards.       |
+-------------------------+-----------------------------------+

Re: # of unexpected failures 768 ?

[Rainer Orth]

Dennis Clarke <dclarke@blastwave.org> writes:

>>> I'm uncertain if Solaris 8/x86 still supports bare i386 machines, so it
>>> might be better to keep the default of pentiumpro instead.
>>
>> Solaris 8 won't run on anything less than pentium, I recently
>> convinced someone else to stop building GCC for i386 on Solaris:
>>
>> http://gcc.gnu.org/ml/gcc-help/2011-10/msg00005.html
>
> The Os is on Vintage support until March 2012. Also, I never had problems

That's not the question (but one reason why Solaris 8 support will be
removed after GCC 4.7).  As Jonathan documented, you can't run S8 on a
bare 80386, so there's no reason the default code generation to that CPU.

> with it before. As for "completely redundant options" I have been building
> gcc like this for a while. also never a problem before.
>
> This is a case of "magic configure incantation" required ? I certainly
> hope not.

Quite the contrary: leave out any configure option unless you absolutely
need it because the defaults don't work, document why you need them, and
re-check that info for every release.  If you think configure should
detect the condition on its own, file a bug report for that.

These `I've used them for ever' options tend to do more harm than good,
and confuse other users that check how your copy of gcc was built.  This
is especially bad for distributors like yourself, since the number of
confused people is far larger than for some company-internal build ;-)

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: # of unexpected failures 768 ?

[Jonathan Wakely]

On 31 October 2011 17:38, Rainer Orth wrote:
> Dennis Clarke <dclarke@blastwave.org> writes:
>
>>>> I'm uncertain if Solaris 8/x86 still supports bare i386 machines, so it
>>>> might be better to keep the default of pentiumpro instead.
>>>
>>> Solaris 8 won't run on anything less than pentium, I recently
>>> convinced someone else to stop building GCC for i386 on Solaris:
>>>
>>> http://gcc.gnu.org/ml/gcc-help/2011-10/msg00005.html
>>
>> The Os is on Vintage support until March 2012. Also, I never had problems
>
> That's not the question (but one reason why Solaris 8 support will be
> removed after GCC 4.7).  As Jonathan documented, you can't run S8 on a
> bare 80386, so there's no reason the default code generation to that CPU.

Quite.  In fact there are *very* good reasons not to configure for
80386: libstdc++'s configure uses the default arch being configured
for, and disables a number of features on i386 because it doesn't
support the required atomic ops.

So by configuring for i386 you will distribute a GCC package that is
missing useful features, but supports an ancient architecture that
Solaris doesn't even run on.

You should configure for pentium-pc-solaris2.8 or use --with-arch-32=pentium

Re: # of unexpected failures 768 ?

[Michael Haubenwallner]

On 10/31/11 19:20, Jonathan Wakely wrote:
> On 31 October 2011 17:38, Rainer Orth wrote:
>> Dennis Clarke <dclarke@blastwave.org> writes:
>>
>>>>> I'm uncertain if Solaris 8/x86 still supports bare i386 machines, so it
>>>>> might be better to keep the default of pentiumpro instead.
>>>>
>>>> Solaris 8 won't run on anything less than pentium, I recently
>>>> convinced someone else to stop building GCC for i386 on Solaris:
>>>>
>>>> http://gcc.gnu.org/ml/gcc-help/2011-10/msg00005.html
> 
> Quite.  In fact there are *very* good reasons not to configure for
> 80386: libstdc++'s configure uses the default arch being configured
> for, and disables a number of features on i386 because it doesn't
> support the required atomic ops.
> 
> So by configuring for i386 you will distribute a GCC package that is
> missing useful features, but supports an ancient architecture that
> Solaris doesn't even run on.
> 
> You should configure for pentium-pc-solaris2.8 or use --with-arch-32=pentium

When not configuring with '--host=i386-pc-solaris2.8', it is config.guess
that detects 'i386-pc-solaris2.8', just tried here with most recent
config.guess on i86pc Solaris2.10, result is 'i386-pc-solaris2.10'.

Actually, it is uname showing the 'i386' on Solaris:
  $ uname -p           # Prints the current host's ISA or processor type.
  i386
  $ uname -i           # Prints the name of the platform.
  i86pc

So I'd wonder if '--host=i386-pc-solaris2.8' actually does make any difference here.

Just my 2 cents.

/haubi/

Re: # of unexpected failures 768 ?

[Jonathan Wakely]

On 2 November 2011 06:52, Michael Haubenwallner wrote:
>
> On 10/31/11 19:20, Jonathan Wakely wrote:
>> On 31 October 2011 17:38, Rainer Orth wrote:
>>> Dennis Clarke <dclarke@blastwave.org> writes:
>>>
>>>>>> I'm uncertain if Solaris 8/x86 still supports bare i386 machines, so it
>>>>>> might be better to keep the default of pentiumpro instead.
>>>>>
>>>>> Solaris 8 won't run on anything less than pentium, I recently
>>>>> convinced someone else to stop building GCC for i386 on Solaris:
>>>>>
>>>>> http://gcc.gnu.org/ml/gcc-help/2011-10/msg00005.html
>>
>> Quite.  In fact there are *very* good reasons not to configure for
>> 80386: libstdc++'s configure uses the default arch being configured
>> for, and disables a number of features on i386 because it doesn't
>> support the required atomic ops.
>>
>> So by configuring for i386 you will distribute a GCC package that is
>> missing useful features, but supports an ancient architecture that
>> Solaris doesn't even run on.
>>
>> You should configure for pentium-pc-solaris2.8 or use --with-arch-32=pentium
>
> When not configuring with '--host=i386-pc-solaris2.8', it is config.guess
> that detects 'i386-pc-solaris2.8', just tried here with most recent
> config.guess on i86pc Solaris2.10, result is 'i386-pc-solaris2.10'.
>
> Actually, it is uname showing the 'i386' on Solaris:
>  $ uname -p           # Prints the current host's ISA or processor type.
>  i386
>  $ uname -i           # Prints the name of the platform.
>  i86pc
>
> So I'd wonder if '--host=i386-pc-solaris2.8' actually does make any difference here.

It's redundant if you *want* to build for that host, but the whole
point is that building for i386 is usually a very bad idea, so
--host=i586-pc-solaris2.8 would be better.

Re: # of unexpected failures 768 ?

[Michael Haubenwallner]

On 11/02/11 12:41, Jonathan Wakely wrote:
> On 2 November 2011 06:52, Michael Haubenwallner wrote:
>>
>> On 10/31/11 19:20, Jonathan Wakely wrote:
>>> On 31 October 2011 17:38, Rainer Orth wrote:
>>>> Dennis Clarke <dclarke@blastwave.org> writes:
>>>>
>>>>>>> I'm uncertain if Solaris 8/x86 still supports bare i386 machines, so it
>>>>>>> might be better to keep the default of pentiumpro instead.
>>>>>>
>>>>>> Solaris 8 won't run on anything less than pentium, I recently
>>>>>> convinced someone else to stop building GCC for i386 on Solaris:
>>>>>>
>>>>>> http://gcc.gnu.org/ml/gcc-help/2011-10/msg00005.html
>>>
>>> Quite.  In fact there are *very* good reasons not to configure for
>>> 80386: libstdc++'s configure uses the default arch being configured
>>> for, and disables a number of features on i386 because it doesn't
>>> support the required atomic ops.
>>>
>>> So by configuring for i386 you will distribute a GCC package that is
>>> missing useful features, but supports an ancient architecture that
>>> Solaris doesn't even run on.
>>>
>>> You should configure for pentium-pc-solaris2.8 or use --with-arch-32=pentium
>>
>> When not configuring with '--host=i386-pc-solaris2.8', it is config.guess
>> that detects 'i386-pc-solaris2.8', just tried here with most recent
>> config.guess on i86pc Solaris2.10, result is 'i386-pc-solaris2.10'.
>>
>> Actually, it is uname showing the 'i386' on Solaris:
>>  $ uname -p           # Prints the current host's ISA or processor type.
>>  i386
>>  $ uname -i           # Prints the name of the platform.
>>  i86pc
>>
>> So I'd wonder if '--host=i386-pc-solaris2.8' actually does make any difference here.
> 
> It's redundant if you *want* to build for that host, but the whole
> point is that building for i386 is usually a very bad idea, so
> --host=i586-pc-solaris2.8 would be better.

Erm - what I want to say is that I would really wonder if it does have /any/
influence (binary-wise) to gcc on Solaris (unlike Linux) whether to configure
for i386 or i586 (via '--host' or even '--target').

/haubi/

Re: # of unexpected failures 768 ?

[Jonathan Wakely]

On 2 November 2011 13:52, Michael Haubenwallner wrote:
>
> Erm - what I want to say is that I would really wonder if it does have /any/
> influence (binary-wise) to gcc on Solaris (unlike Linux) whether to configure
> for i386 or i586 (via '--host' or even '--target').

http://gcc.gnu.org/gcc-4.5/changes.html#x86 doesn't say it only
happens on GNU/Linux.

Re: # of unexpected failures 768 ?

[Michael Haubenwallner]

On 11/02/11 18:10, Jonathan Wakely wrote:
> On 2 November 2011 13:52, Michael Haubenwallner wrote:
>>
>> Erm - what I want to say is that I would really wonder if it does have /any/
>> influence (binary-wise) to gcc on Solaris (unlike Linux) whether to configure
>> for i386 or i586 (via '--host' or even '--target').
> 
> http://gcc.gnu.org/gcc-4.5/changes.html#x86 doesn't say it only
> happens on GNU/Linux.

Oh my dear... thank you!

But still: given that x86-solaris started with some Pentium, I just
can't believe gcc can "optimize" for real 80386 CPU on Solaris now.

Especially as i386 (from config.guess) is the default too.

/haubi/

Re: # of unexpected failures 768 ?

[Rainer Orth]

Michael Haubenwallner <michael.haubenwallner@salomon.at> writes:

> Especially as i386 (from config.guess) is the default too.

No, it's not, you're confusing the configure triplet with the default
32-bit arch.  Since GCC 4.6, the default for Solaris/x86 is pentiumpro
for Solaris 8/9 and pentium4 for Solaris 10 and beyond
(cf. gcc/config.gcc).

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: # of unexpected failures 768 ?

[Michael Haubenwallner]

On 11/02/11 19:07, Rainer Orth wrote:
> Michael Haubenwallner <michael.haubenwallner@salomon.at> writes:
> 
>> Especially as i386 (from config.guess) is the default too.
> 
> No, it's not, you're confusing the configure triplet with the default
> 32-bit arch. Since GCC 4.6, the default for Solaris/x86 is pentiumpro
> for Solaris 8/9 and pentium4 for Solaris 10 and beyond
> (cf. gcc/config.gcc).

I've meant the default "i386-pc-solaris2.*" target triplet from config.guess,
not the default 32bit arch - which always is some pentium as I've expected
(and tried to say before).

Reading [1], it really doesn't make any difference on Solaris to configure for
"i386-pc-solaris2.*" or (up to) "i786-pc-solaris2.*" target triplet, the 32bit
arch default is controlled by the solaris version (and '--with-arch-32') only.

But yes, for platforms not explicitly specifying a default $with_arch_32,
that default value is calculated [2] from the cpu-part of the target-triplet.

[1] http://gcc.gnu.org/viewcvs/trunk/gcc/config.gcc?view=markup&pathrev=180775#l1312
[2] http://gcc.gnu.org/viewcvs/trunk/gcc/config.gcc?view=markup&pathrev=180775#l2831

/haubi/

Re: # of unexpected failures 768 ?

[Ian Lance Taylor]

Michael Haubenwallner <michael.haubenwallner@salomon.at> writes:

> But still: given that x86-solaris started with some Pentium, I just
> can't believe gcc can "optimize" for real 80386 CPU on Solaris now.
>
> Especially as i386 (from config.guess) is the default too.

I'm not sure why you don't believe it.  It is what I would expect.

If we want to make this work more normally for ordinary users, I think
the right thing to do would be to patch config.guess to compute a better
value for the build system CPU on Solaris systems.

Ian

Re: # of unexpected failures 768 ?

[Rainer Orth]

Ian Lance Taylor <iant@google.com> writes:

> Michael Haubenwallner <michael.haubenwallner@salomon.at> writes:
>
>> But still: given that x86-solaris started with some Pentium, I just
>> can't believe gcc can "optimize" for real 80386 CPU on Solaris now.
>>
>> Especially as i386 (from config.guess) is the default too.
>
> I'm not sure why you don't believe it.  It is what I would expect.
>
> If we want to make this work more normally for ordinary users, I think
> the right thing to do would be to patch config.guess to compute a better
> value for the build system CPU on Solaris systems.

Please no: alpha went this route, and the consequence is that your
self-built gcc will generate code for the build system.  This breaks
completely if you have a heterogeneous collection of systems, and the
GCC build system isn't the least common denominator of them.  This
single-system mindset creates unnecessary trouble in this scenario.
GCC's configure has enough control over the default target CPU, even
without messing with config.guess, and most other programs won't care
about this at all.

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: # of unexpected failures 768 ?

[Ian Lance Taylor]

Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> writes:

> Ian Lance Taylor <iant@google.com> writes:
>
>> Michael Haubenwallner <michael.haubenwallner@salomon.at> writes:
>>
>>> But still: given that x86-solaris started with some Pentium, I just
>>> can't believe gcc can "optimize" for real 80386 CPU on Solaris now.
>>>
>>> Especially as i386 (from config.guess) is the default too.
>>
>> I'm not sure why you don't believe it.  It is what I would expect.
>>
>> If we want to make this work more normally for ordinary users, I think
>> the right thing to do would be to patch config.guess to compute a better
>> value for the build system CPU on Solaris systems.
>
> Please no: alpha went this route, and the consequence is that your
> self-built gcc will generate code for the build system.  This breaks
> completely if you have a heterogeneous collection of systems, and the
> GCC build system isn't the least common denominator of them.  This
> single-system mindset creates unnecessary trouble in this scenario.
> GCC's configure has enough control over the default target CPU, even
> without messing with config.guess, and most other programs won't care
> about this at all.

Oh, I completely agree that it would be wrong to have config.guess
produce the exact CPU used on the build system.

But having config.guess produce "i386" for an OS which does not even run
on a vanilla i386 is also wrong.  A much better choice here would be the
earliest CPU value which the OS actually supports.

Ian

Re: # of unexpected failures 768 ?

[Dennis Clarke]

> Dennis Clarke <dclarke@blastwave.org> writes:
>
>> Only the new "go" language seems to be a major issue now.
>
> The implementation of Go in the 4.6 releases does not support Solaris.
>
> Go on Solaris works on mainline.

Well, I would not have seen that coming. I should look more closely at the
various README's and changelogs.

To be honest, I scrapped my Solaris Sparc resultant compiler here :

http://gcc.gnu.org/ml/gcc-testresults/2011-11/msg00683.html

... and am starting over. With no go, and no pun inteneded.

Dennis



-- 
--
http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x1D936C72FA35B44B
+-------------------------+-----------------------------------+
| Dennis Clarke           | Solaris and Linux and Open Source |
| dclarke@blastwave.org   | Respect for open standards.       |
+-------------------------+-----------------------------------+

Re: # of unexpected failures 768 ?

[Dennis Clarke]

> Dennis Clarke <dclarke@blastwave.org> writes:
>
>> I'm not too sure how many things changed from 4.6.1 to 4.6.2 but I am
>> seeing a really large increase in the number of "unexpected failures" on
>> various tests.
>>
>> With 4.6.1 and Solaris I was able to get reasonable results :
>>
>> http://gcc.gnu.org/ml/gcc-testresults/2011-07/msg00139.html
>>
>> Then if I use the resultant compiler from a 4.6.1 build I get a massive
>> increase in failures on both i386 and Sparc :
>>
>> http://gcc.gnu.org/ml/gcc-testresults/2011-10/msg03286.html
>
> FAIL: g++.dg/ext/visibility/fvisibility-inlines-hidden-2.C scan-not-hidden
>
> All the scan-not-hidden failures are usually an indication that objdump
> isn't in your PATH.

Right, thank you. On i386 I rectified that situation with binutils however
on Sparc this was not an issue.

See results :

  http://gcc.gnu.org/ml/gcc-testresults/2011-11/msg00683.html


Only the new "go" language seems to be a major issue now.

>> This seems blatantly wrong. At what point does one throw out the result
>> of
>> a bootstrap as not-acceptable ? With any non-zero value for "unexpected
>> failures" ?
>
> There's no such number, only comparisons to other testsuite results.  In
> many cases (e.g. in the scan-not-hidden failures above), there's nothing
> wrong with the compiler, just with the test environment.  And in your
> case, only two problems account for the vast majority of the failures.
>
>> Also, I see bucket loads of these :
>>
>> FAIL: g++.dg/pch/wchar-1.C  -O2 -g -I. (internal compiler error)
>>
>> What should I think about an "internal compiler error" ?
>
> This seems fundamentally broken on your machine.  With the exception of
> the largefile.c testcases, those pass everywhere else, so you'd have to
> debug what's going on there.

Any "internal compiler error" mean throw the whole thing out and start
over. At least that is the only safe course of action in my mind.

> FAIL: gcc.c-torture/compile/limits-exprparen.c  -O0  (internal compiler
> error)
> [...]
> FAIL: gcc.c-torture/compile/limits-structnest.c  -O2  (test for excess
> errors)
> WARNING: program timed out.
>
> Those test cases have excessive stack space or runtime requirements and
> are known to fail on slow machines or those with default resource
> limits.  Those are known testcase bugs, but nobody cared about this so
> far ;-(

I'm so happy to hit those special cases :-)


> Overall, your results don't look bad to me, once you've installed
> objdump and investigated the PCH failures.

yep ... I have been digging. On Sparc things are going much better but on
i386 I have tossed the whole scenario out and am starting over from first
principles. Build everything from scratch with the Sun Studio compiler
until I hit things that need gcc. Like libgmp etc.

> As an asside, I'd suggest to considerably reduce your set of configure
> options: many of them are the default (like --without-gnu-ld
> --with-ld=/usr/ccs/bin/ld, --enable-nls, --enable-threads=posix,
> --enable-shared, --enable-multilib, --host=i386-pc-solaris2.8
> --build=i386-pc-solaris2.8) or unnecessary
> (--enable-stage1-languages=c).
>
> I'm uncertain if Solaris 8/x86 still supports bare i386 machines, so it
> might be better to keep the default of pentiumpro instead.

Yep, did that. Thank you. However on i386 things got worse, not better. I
have to toss that out and start over. On Sparc things are much better with
the exception of "go".

Thank you for the input.

Dennis


-- 
--
http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x1D936C72FA35B44B
+-------------------------+-----------------------------------+
| Dennis Clarke           | Solaris and Linux and Open Source |
| dclarke@blastwave.org   | Respect for open standards.       |
+-------------------------+-----------------------------------+

Re: # of unexpected failures 768 ?

[Ian Lance Taylor]

Dennis Clarke <dclarke@blastwave.org> writes:

> Only the new "go" language seems to be a major issue now.

The implementation of Go in the 4.6 releases does not support Solaris.

Go on Solaris works on mainline.

Ian

Re: # of unexpected failures 768 ?

[Dennis Clarke]

> Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> writes:
>
>> Ian Lance Taylor <iant@google.com> writes:
>>
>>> Michael Haubenwallner <michael.haubenwallner@salomon.at> writes:
>>>
>>>> But still: given that x86-solaris started with some Pentium, I just
>>>> can't believe gcc can "optimize" for real 80386 CPU on Solaris now.
>>>>
>>>> Especially as i386 (from config.guess) is the default too.
>>>
>>> I'm not sure why you don't believe it.  It is what I would expect.
>>>
>>> If we want to make this work more normally for ordinary users, I think
>>> the right thing to do would be to patch config.guess to compute a
>>> better
>>> value for the build system CPU on Solaris systems.
>>
>> Please no: alpha went this route, and the consequence is that your
>> self-built gcc will generate code for the build system.  This breaks
>> completely if you have a heterogeneous collection of systems, and the
>> GCC build system isn't the least common denominator of them.  This
>> single-system mindset creates unnecessary trouble in this scenario.
>> GCC's configure has enough control over the default target CPU, even
>> without messing with config.guess, and most other programs won't care
>> about this at all.
>
> Oh, I completely agree that it would be wrong to have config.guess
> produce the exact CPU used on the build system.
>
> But having config.guess produce "i386" for an OS which does not even run
> on a vanilla i386 is also wrong.  A much better choice here would be the
> earliest CPU value which the OS actually supports.

$ isalist -v
pentium_pro+mmx pentium_pro pentium+mmx pentium i486 i386 i86

I would suggest pentium_pro if one can still find one running out there.

Dennis


-- 
--
http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x1D936C72FA35B44B
+-------------------------+-----------------------------------+
| Dennis Clarke           | Solaris and Linux and Open Source |
| dclarke@blastwave.org   | Respect for open standards.       |
+-------------------------+-----------------------------------+

Re: # of unexpected failures 768 ?

[Dennis Clarke]

> Ian Lance Taylor <iant@google.com> writes:
>
>> Michael Haubenwallner <michael.haubenwallner@salomon.at> writes:
>>
>>> But still: given that x86-solaris started with some Pentium, I just
>>> can't believe gcc can "optimize" for real 80386 CPU on Solaris now.
>>>
>>> Especially as i386 (from config.guess) is the default too.
>>
>> I'm not sure why you don't believe it.  It is what I would expect.
>>
>> If we want to make this work more normally for ordinary users, I think
>> the right thing to do would be to patch config.guess to compute a better
>> value for the build system CPU on Solaris systems.
>
> Please no: alpha went this route, and the consequence is that your
> self-built gcc will generate code for the build system.  This breaks
> completely if you have a heterogeneous collection of systems, and the
> GCC build system isn't the least common denominator of them.  This
> single-system mindset creates unnecessary trouble in this scenario.
> GCC's configure has enough control over the default target CPU, even
> without messing with config.guess, and most other programs won't care
> about this at all.
>
>

Personally I am all for "it ain't broke, don't fix it".

Dennis



-- 
--
http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x1D936C72FA35B44B
+-------------------------+-----------------------------------+
| Dennis Clarke           | Solaris and Linux and Open Source |
| dclarke@blastwave.org   | Respect for open standards.       |
+-------------------------+-----------------------------------+

Re: # of unexpected failures 768 ?

[Dennis Clarke]

>> It's redundant if you *want* to build for that host, but the whole
>> point is that building for i386 is usually a very bad idea, so
>> --host=i586-pc-solaris2.8 would be better.
>
> Erm - what I want to say is that I would really wonder if it does have
> /any/
> influence (binary-wise) to gcc on Solaris (unlike Linux) whether to
> configure
> for i386 or i586 (via '--host' or even '--target').
>


Oh, well, that would be a worthwhile experiment I think.

dc


-- 
--
http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x1D936C72FA35B44B
+-------------------------+-----------------------------------+
| Dennis Clarke           | Solaris and Linux and Open Source |
| dclarke@blastwave.org   | Respect for open standards.       |
+-------------------------+-----------------------------------+

Re: # of unexpected failures 768 ?

[Dennis Clarke]

>
> Actually, it is uname showing the 'i386' on Solaris:
>   $ uname -p           # Prints the current host's ISA or processor type.
>   i386
>   $ uname -i           # Prints the name of the platform.
>   i86pc
>
> So I'd wonder if '--host=i386-pc-solaris2.8' actually does make any
> difference here.
>
> Just my 2 cents.

no prob.

Actually on Solaris you will always get 'i386' even if you are running on
a top of the line AMD Opteron 16-core machine with 8 sockets. It still
reports that it is a i386 and not x86_64 or even amd64.

Now isainfo and isalist are a whole other matter. Personally I'd like to
see conffigure take advantage of that data as it is much more rich.

On sparc you get this sort of data :

# isalist -a
sparcv9+vis sparcv9 sparcv8plus+vis sparcv8plus sparcv8 sparcv8-fsmuld
sparcv7 sparc
# isainfo -v
64-bit sparcv9 applications
32-bit sparc applications

On some old pentium box you get this :

Sun Microsystems Inc.   SunOS 5.8       Generic February 2000
$
$ isalist -a
pentium_pro+mmx pentium_pro pentium+mmx pentium i486 i386 i86
$ isainfo -v
32-bit i386 applications
$

Dennis


-- 
--
http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x1D936C72FA35B44B
+-------------------------+-----------------------------------+
| Dennis Clarke           | Solaris and Linux and Open Source |
| dclarke@blastwave.org   | Respect for open standards.       |
+-------------------------+-----------------------------------+

# of unexpected failures 768 ?

[Dennis Clarke]

I'm not too sure how many things changed from 4.6.1 to 4.6.2 but I am
seeing a really large increase in the number of "unexpected failures" on
various tests.

With 4.6.1 and Solaris I was able to get reasonable results :

http://gcc.gnu.org/ml/gcc-testresults/2011-07/msg00139.html

Then if I use the resultant compiler from a 4.6.1 build I get a massive
increase in failures on both i386 and Sparc :

http://gcc.gnu.org/ml/gcc-testresults/2011-10/msg03286.html

and thus far on Sparc I see :

                === gcc Summary ===

# of expected passes            69236
# of unexpected failures        768
# of expected failures          235
# of unresolved testcases       1
# of unsupported tests          1240
/opt/bw/src/GCC/gcc-4.6.2-SunOS5.8-sparc/gcc/xgcc  version 4.6.2
(Blastwave.org Inc Thu Oct 27 11:33:20 GMT 2011)

and :

                === g++ Summary ===

# of expected passes            26251
# of unexpected failures        101
# of unexpected successes       1
# of expected failures          169
# of unresolved testcases       1
# of unsupported tests          496
/opt/bw/src/GCC/gcc-4.6.2-SunOS5.8-sparc/gcc/testsuite/g++/../../g++ 
version 4.6.2 (Blastwave.org Inc Thu Oct 27 11:33:20 GMT 2011)

This seems blatantly wrong. At what point does one throw out the result of
a bootstrap as not-acceptable ? With any non-zero value for "unexpected
failures" ?

Also, I see bucket loads of these :

FAIL: g++.dg/pch/wchar-1.C  -O2 -g -I. (internal compiler error)

What should I think about an "internal compiler error" ?

Dennis
( concerned in Solaris world )



-- 
--
http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x1D936C72FA35B44B
+-------------------------+-----------------------------------+
| Dennis Clarke           | Solaris and Linux and Open Source |
| dclarke@blastwave.org   | Respect for open standards.       |
+-------------------------+-----------------------------------+

Re: # of unexpected failures 768 ?

[Eric Botcazou]

> Then if I use the resultant compiler from a 4.6.1 build I get a massive
> increase in failures on both i386 and Sparc :
>
> http://gcc.gnu.org/ml/gcc-testresults/2011-10/msg03286.html

This is unexpected, results are clean here:
  http://gcc.gnu.org/ml/gcc-testresults/2011-10/msg03536.html

> Also, I see bucket loads of these :
>
> FAIL: g++.dg/pch/wchar-1.C  -O2 -g -I. (internal compiler error)

PCH seems to be totally broken.  AFAIK nothing has changed between 4.6.1 and 
4.6.2 in this area.  Can you try with 4.6.1?  Did you change the machines?

-- 
Eric Botcazou

Re: # of unexpected failures 768 ?

[Rainer Orth]

Dennis Clarke <dclarke@blastwave.org> writes:

> I'm not too sure how many things changed from 4.6.1 to 4.6.2 but I am
> seeing a really large increase in the number of "unexpected failures" on
> various tests.
>
> With 4.6.1 and Solaris I was able to get reasonable results :
>
> http://gcc.gnu.org/ml/gcc-testresults/2011-07/msg00139.html
>
> Then if I use the resultant compiler from a 4.6.1 build I get a massive
> increase in failures on both i386 and Sparc :
>
> http://gcc.gnu.org/ml/gcc-testresults/2011-10/msg03286.html

FAIL: g++.dg/ext/visibility/fvisibility-inlines-hidden-2.C scan-not-hidden

All the scan-not-hidden failures are usually an indication that objdump
isn't in your PATH.

> This seems blatantly wrong. At what point does one throw out the result of
> a bootstrap as not-acceptable ? With any non-zero value for "unexpected
> failures" ?

There's no such number, only comparisons to other testsuite results.  In
many cases (e.g. in the scan-not-hidden failures above), there's nothing
wrong with the compiler, just with the test environment.  And in your
case, only two problems account for the vast majority of the failures.

> Also, I see bucket loads of these :
>
> FAIL: g++.dg/pch/wchar-1.C  -O2 -g -I. (internal compiler error)
>
> What should I think about an "internal compiler error" ?

This seems fundamentally broken on your machine.  With the exception of
the largefile.c testcases, those pass everywhere else, so you'd have to
debug what's going on there.

FAIL: gcc.c-torture/compile/limits-exprparen.c  -O0  (internal compiler error)
[...]
FAIL: gcc.c-torture/compile/limits-structnest.c  -O2  (test for excess errors)
WARNING: program timed out.

Those test cases have excessive stack space or runtime requirements and
are known to fail on slow machines or those with default resource
limits.  Those are known testcase bugs, but nobody cared about this so
far ;-(

Overall, your results don't look bad to me, once you've installed
objdump and investigated the PCH failures.

As an asside, I'd suggest to considerably reduce your set of configure
options: many of them are the default (like --without-gnu-ld
--with-ld=/usr/ccs/bin/ld, --enable-nls, --enable-threads=posix,
--enable-shared, --enable-multilib, --host=i386-pc-solaris2.8
--build=i386-pc-solaris2.8) or unnecessary
(--enable-stage1-languages=c).

I'm uncertain if Solaris 8/x86 still supports bare i386 machines, so it
might be better to keep the default of pentiumpro instead.

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: # of unexpected failures 768 ?

[Jonathan Wakely]

On 31 October 2011 15:33, Rainer Orth wrote:
> As an asside, I'd suggest to considerably reduce your set of configure
> options: many of them are the default (like --without-gnu-ld
> --with-ld=/usr/ccs/bin/ld, --enable-nls, --enable-threads=posix,
> --enable-shared, --enable-multilib, --host=i386-pc-solaris2.8
> --build=i386-pc-solaris2.8) or unnecessary
> (--enable-stage1-languages=c).

Yes, adding completely redundant options looks like cargo cult
programming and just confuses anyone using the compiler who tries to
work out how it was configured.

> I'm uncertain if Solaris 8/x86 still supports bare i386 machines, so it
> might be better to keep the default of pentiumpro instead.

Solaris 8 won't run on anything less than pentium, I recently
convinced someone else to stop building GCC for i386 on Solaris:

http://gcc.gnu.org/ml/gcc-help/2011-10/msg00005.html