the configure script checks whether $CC compiles with -OPT:Olimit=0. For IRIX 5.3's cc, for example, although it is not supported, it only gives a warning and compiles nonetheless:

cc -OPT:Olimit=0 c.c
cc: Warning: -OPT options are ignored

The configure script tests do not check for this, so they do use that option. It's not so much of a problem that we constantly get respective warnings while
compiling; what's more of a problem (and therefore I call it a bug) is that python's configure does not go on checking for other optimizations. Therefore, on IRIX 5.3 with cc the -Olimit=1500 option, which would be needed, is not being configured.

Suggestion: also check whether there's anything on stderr while compiling the test code, and if so, don't use that particular option. Assuming make uses some /bin/sh you might use cc -OPT:Olimit=0 c.c 2>&1 >/dev/null and check whether there's any output (or maybe there are more elegant solutions).

This still happens with Python 2.6b3, 3.0b3 and 2.5.2 and Sun Studio 12
on Solaris Sparc.

Like mentioned in Issue1162001, the problem seems to be, that cc returns
0 if -OPT:Olimit=0 is used:

--($ ~)-- cc  -OPT:Olimit=0 test1.c; echo $?
cc: Warning: illegal option -OPT:Olimit=0
0

--($ ~)-- gcc  -OPT:Olimit=0 test1.c; echo $?
cc1: error: invalid option argument `-OPT:Olimit=0'
1

I ran this configure:

CXX=/opt/SUNWspro/bin/CC CC=/opt/SUNWspro/bin/cc ./configure
--prefix=$HOME/.software/python-2.6b3 --disable-ipv6 --enable-shared
--without-gcc --with-threads --with-doc-strings

The prefix was always different, of course :)

--($ ~)-- gcc --version
gcc (GCC) 3.4.3 (csl-sol210-3_4-branch+sol_rpath)
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

--($ ~)-- version # for cc
Machine hardware:   sun4u
OS version:         5.10
Processor type:     sparc
Hardware:           SUNW,Sun-Fire-480R

The following components are installed on your system:


Sun Studio 12
        Sun Studio 12 C Compiler
        Sun Studio 12 C++ Compiler
        Sun Studio 12 Tools.h++ 7.1
        Sun Studio 12 C++ Standard 64-bit Class Library
        Sun Studio 12 Garbage Collector 
        Sun Studio 12 Fortran 95 
        Sun Studio 12 Debugging Tools (including dbx)
        Sun Studio 12 IDE
        Sun Studio 12 Debugger GUI
        Sun Studio 12 Performance Analyzer (including collect, ...)
        Sun Studio 12 X-Designer 
        Sun Studio 12 VIM editor
        Sun Studio 12 XEmacs editor
        Sun Studio 12 Performance Library 
        Sun Studio 12 LockLint
        Sun Studio 12 Building Software (including dmake)
        Sun Studio 12 Documentation Set

version of "/opt/SUNWspro/bin/../prod/bin/../../bin/cc": Sun C 5.9
SunOS_sparc Patch 124867-01 2007/07/12
version of "/opt/SUNWspro/bin/../prod/bin/../../bin/CC": Sun C++ 5.9
SunOS_sparc Patch 124863-01 2007/07/25
version of "/opt/SUNWspro/bin/../prod/bin/../../bin/f90": Sun Fortran 95
8.3 SunOS_sparc Patch 127000-01 2007/07/18
version of "/opt/SUNWspro/bin/../prod/bin/../../bin/dbx": Sun Dbx
Debugger 7.6 SunOS_sparc Patch 124872-01 2007/07/12
version of "/opt/SUNWspro/bin/../prod/bin/../../bin/analyzer": Sun
Analyzer 7.6 SunOS_sparc Patch 126995-01 2007/07/17
version of "/opt/SUNWspro/bin/../prod/bin/../../bin/dmake": Sun
Distributed Make 7.8 SunOS_sparc Patch 126503-01 2007/07/19

Yep, this is an annoying misfeature of Sun Studio. There is no way to
affect this behaviour. There is a Sun Studio bug filed for this
(-errwarn should affect this behaviour, but it doesn't).

Here's some example m4 that libvirt uses to check this case properly:

AC_DEFUN([gl_COMPILER_FLAGS],
  [AC_MSG_CHECKING(whether compiler accepts $1)
   AC_SUBST(COMPILER_FLAGS)
   ac_save_CFLAGS="$CFLAGS"
   CFLAGS="$CFLAGS $1"
   AC_TRY_LINK([], [], has_option=yes, has_option=no,)
   echo 'int x;' >conftest.c
   $CC $CFLAGS -c conftest.c 2>conftest.err
   ret=$?
   if test $ret != 0 -o -s conftest.err -o $has_option = "no"; then
       AC_MSG_RESULT(no)
   else
       AC_MSG_RESULT(yes)
       COMPILER_FLAGS="$COMPILER_FLAGS $1"
   fi
   CFLAGS="$ac_save_CFLAGS"
   rm -f conftest*
 ])

This is a Sun Studio problem not a Python problem.

That's a little abrupt. Whilst it would be nice if the compiler had a correct return value, it occurs with multiple compilers, and I pointed
you to a suitable workaround Python could employ. Even if Studio gets fixed, there are previous releases out there for a long time.

Even worse, a nasty hack was added just for Intel's compiler as seen in
http://bugs.python.org/issue1162001

I agree, it is the job of the autotools to handle system portability
issues such as this, and thus this can be considered a fixable bug.
However, it is the kind of thing that is only going to get fixed if
someone whom it affects can propose a patch, since I doubt any of the
current active committers have affected systems on which to test it.

The patch should be against the py3k trunk, and we'll need at least one
other person whom this affects to review the patch before a committer
can apply it.

If have the same issue with Oracle Studio 12.2 on Solaris 10 with Python 2.7.1:

....
cc -G -L/livraison/test/sparc-sun-solaris2.10/support/support-2.6.x-py27/lib -L/livraison/test/sparc-sun-solaris2.10/support/support-internal-2.6.x-py27/lib -L/livraison/test/sparc-sun-solaris2.10/support/support-2.6.x-py27/lib -L/livraison/test/sparc-sun-solaris2.10/support/support-internal-2.6.x-py27/lib -OPT:Olimit=0 -g -DNDEBUG -xO4 -I. -IInclude -I./Include -I/livraison/test/sparc-sun-solaris2.10/support/support-2.6.x-py27/include -I/livraison/test/sparc-sun-solaris2.10/support/support-2.6.x-py27/include/ncurses -I/livraison/test/sparc-sun-solaris2.10/support/support-internal-2.6.x-py27/include build/temp.solaris-2.10-sun4u-2.7/san_u10/home/recette/ssa/support-2.6.x/Python-2.7.1/Modules/_struct.o -L/livraison/test/sparc-sun-solaris2.10/support/support-2.6.x-py27/lib -L/usr/local/lib -L. -lpython2.7 -o build/lib.solaris-2.10-sun4u-2.7/_struct.so
cc: Warning: Option -OPT:Olimit=0 passed to ld, if ld is invoked, ignored otherwise
/usr/ccs/bin/ld: illegal option -- O
usage: ld [-6:abc:d:e:f:h:il:mo:p:rstu:z:B:CD:F:GI:L:M:N:P:Q:R:S:VY:?] file(s)

Was fixed in r85656 by Martin (in 3.2), but needs backporting.

Who is best placed to backport the fix?

The 3.2 change r85656 removes OPT:Olimit, IMO this should not be backported.

But 2.7 already has this warning fixed for icc:
http://hg.python.org/cpython/rev/e7c96c1d144b/
We should do the same here. What's the correct way to detect Oracle Studio compiler?

This also affects Python 2.7 / 3.1 on FreeBSD 10.x with CC=clang

Referencing the PR here: http://www.freebsd.org/cgi/query-pr.cgi?pr=182952

Would like to see the commit backported as well.