classification
Title: "checking whether gcc supports ParseTuple __format__... " erroneously returns yes with gcc 4.8
Type: compile error Stage: committed/rejected
Components: Build Versions: Python 3.4, Python 3.3, Python 3.2, Python 2.7
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: Alex.Leach, benjamin.peterson, dmalcolm, georg.brandl, jcea, larry, ned.deily, python-dev
Priority: release blocker Keywords: patch

Created on 2013-03-25 19:33 by dmalcolm, last changed 2013-06-16 00:54 by jcea. This issue is now closed.

Files
File name Uploaded Description Edit
00175-fix-configure-Wformat.patch dmalcolm, 2013-03-25 19:33 Work-in-progress patch against 2.7.3 tarball
Messages (11)
msg185226 - (view) Author: Dave Malcolm (dmalcolm) (Python committer) Date: 2013-03-25 19:33
It appears that gcc's -Wformat warning changed from being on by default in gcc 4.7 and earlier to being off by default in gcc 4.8, needing to be enabled with -Wformat (or -Wall), if I'm reading:
http://gcc.gnu.org/viewcvs/gcc?view=revision&revision=193304
correctly

This breaks CPython's configure.ac test:
  "Check whether GCC supports PyArg_ParseTuple format"
in that the warning the test is supposed to emit is guarded by -Wformat, hence with gcc 4.8 this test always emits:
  checking whether gcc supports ParseTuple __format__... yes
despite the fact that gcc doesn't.

This leads to the pyconfig.h defining HAVE_ATTRIBUTE_FORMAT_PARSETUPLE, and thus we get this error when trying later use the python build to build a C extension module where -Wformat (or -Wall) *is* supplied:
In file included from /usr/include/python2.7/Python.h:126:0,
                 from isys.c:20:
/usr/include/python2.7/modsupport.h:28:1: error: 'PyArg_ParseTuple' is an unrecognized format function type [-Werror=format=]
 PyAPI_FUNC(int) PyArg_ParseTuple(PyObject *, const char *, ...) Py_FORMAT_PARSETUPLE(PyArg_ParseTuple, 2, 3);

Am attaching a work-in-progress patch to supply the missing argument at configure time

Note to self: am tracking this downstream as https://bugzilla.redhat.com/show_bug.cgi?id=927358
msg187439 - (view) Author: Alex Leach (Alex.Leach) Date: 2013-04-20 16:21
The configure.ac patch works for me, on x86_64 Arch Linux. I just updated to GCC-4.8.0 and came across an overwhelming number of these warnings when compiling extension modules. Thanks for the simple fix David.

Tested on hg branch 2.7; the testsuite completes without error.
msg187463 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2013-04-20 21:25
Dave, any reason this shouldn't go into the imminent 2.7.5 and 3.3.2 releases?
msg187663 - (view) Author: Dave Malcolm (dmalcolm) (Python committer) Date: 2013-04-23 18:16
On Sat, 2013-04-20 at 21:25 +0000, Ned Deily wrote:
> Ned Deily added the comment:
> 
> Dave, any reason this shouldn't go into the imminent 2.7.5 and 3.3.2 releases?

I was trying to think of one; the only reason I can think of is if there
are any compilers out there that don't recognize "-Wformat", or have
different behaviors for this test.

That said, if "-Wformat" breaks the compile, then the configure test
should fail, and thus all should be well.

So I can't think of any issue (famous last words...)
msg187665 - (view) Author: Dave Malcolm (dmalcolm) (Python committer) Date: 2013-04-23 18:38
BTW, is that GCC format checking code available anywhere?

Am I right in thinking that it was an out-of-tree patch to GCC, from the
pre-plugin days?

[My cpychecker code adds some similar checking, but it doesn't use this
attribute]
msg187693 - (view) Author: Alex Leach (Alex.Leach) Date: 2013-04-24 10:48
I don't think I can tell you anything you don't know already, but ...

On Tue, 23 Apr 2013 19:38:18 +0100, Dave Malcolm <report@bugs.python.org>  
wrote:

> BTW, is that GCC format checking code available anywhere?

Is this what you mean?

http://gcc.gnu.org/viewcvs/gcc/trunk/gcc/c-family/c-format.c?annotate=193304&pathrev=193304

I got taken straight there from the link you sent, above...

>
> Am I right in thinking that it was an out-of-tree patch to GCC, from the
> pre-plugin days?

No idea.. GCC plugins have been around for several years now, though and  
the patch was only introduced in November. If this patch was applied to  
any past GCC distributions, I'm sure someone else would have been  
overwhelmed with warnings and would have mentioned something before now.  
Either way, it looks like the patch is going to stay.

In case you hadn't seen it already, the invoke.texi source file probably  
has the most descriptive changes:-

  http://gcc.gnu.org/viewcvs/gcc/trunk/gcc/doc/invoke.texi?r1=193304&r2=193303&pathrev=193304

KR,
Alex
msg187708 - (view) Author: Dave Malcolm (dmalcolm) (Python committer) Date: 2013-04-24 14:51
On Wed, 2013-04-24 at 10:48 +0000, Alex Leach wrote:
> Alex Leach added the comment:
> 
> I don't think I can tell you anything you don't know already, but ...
> 
> On Tue, 23 Apr 2013 19:38:18 +0100, Dave Malcolm <report@bugs.python.org>  
> wrote:
> 
> > BTW, is that GCC format checking code available anywhere?
> 
> Is this what you mean?
> 
> http://gcc.gnu.org/viewcvs/gcc/trunk/gcc/c-family/c-format.c?annotate=193304&pathrev=193304
> 
> I got taken straight there from the link you sent, above...

[snip]

> Am I right in thinking that it was an out-of-tree patch to GCC, from
the
> > pre-plugin days?
> 

Sorry that I was a bit vague.

GCC's __attribute((format(i, j, k))__ takes 3 parameters.  The first
parameter is a string code naming the mini-language expressing valid
format strings and their mapping to the types that follow in the
varargs.

I was asking about the string code "PyArg_ParseTuple" used in the
CPython configure test: the link above is the implementation of GCC's
builtin format string codes: and AFAIK the only ones it "knows" about
there are the ones in 
   static const format_kind_info format_types_orig[] =
in the above file (lines 808-873 of gcc/c-family/c-format.c)

which are codes for printf, fprintf, various internal gcc APIs,
NSString, scanf, strftime, and strfmon.

i.e. I believe that the "PyArg_ParseTuple" code is from some 3rd party
patch to GCC that never made it into GCC mainline.  Does this code still
exist anywhere?

[Not that this has any bearing on this bug and the proposed patch: I'm a
big fan of compiler attributes, and wouldn't want to remove them from
the API.]

Hope the above makes sense
msg188937 - (view) Author: Roundup Robot (python-dev) Date: 2013-05-11 18:03
New changeset 9d50af4c482f by Benjamin Peterson in branch '2.7':
-Wformat is needed by gcc 4.8 (closes #17547)
http://hg.python.org/cpython/rev/9d50af4c482f

New changeset 94a7475d3a5f by Benjamin Peterson in branch '3.3':
-Wformat is needed by gcc 4.8 (closes #17547)
http://hg.python.org/cpython/rev/94a7475d3a5f

New changeset f12e3ce66ae6 by Benjamin Peterson in branch 'default':
merge 3.3 (#17547)
http://hg.python.org/cpython/rev/f12e3ce66ae6
msg188938 - (view) Author: Benjamin Peterson (benjamin.peterson) * (Python committer) Date: 2013-05-11 18:05
We really ought to just scrap that configure test.
msg189095 - (view) Author: Benjamin Peterson (benjamin.peterson) * (Python committer) Date: 2013-05-13 04:09
I've now scrapped that test completely for 3.4. 6eab274d3e34
msg191251 - (view) Author: Jesús Cea Avión (jcea) * (Python committer) Date: 2013-06-16 00:54
This is affecting 3.2.5.
History
Date User Action Args
2013-06-16 00:54:55jceasetmessages: + msg191251
2013-06-16 00:38:05jceasetnosy: + jcea
2013-05-13 04:09:09benjamin.petersonsetmessages: + msg189095
2013-05-11 18:05:08benjamin.petersonsetmessages: + msg188938
2013-05-11 18:03:14python-devsetstatus: open -> closed

nosy: + python-dev
messages: + msg188937

resolution: fixed
stage: commit review -> committed/rejected
2013-04-28 19:19:44georg.brandlsetversions: + Python 3.2
2013-04-24 14:51:53dmalcolmsetmessages: + msg187708
2013-04-24 10:48:06Alex.Leachsetmessages: + msg187693
2013-04-23 18:38:18dmalcolmsetmessages: + msg187665
2013-04-23 18:16:02dmalcolmsetmessages: + msg187663
2013-04-20 21:41:38pitrousetpriority: normal -> release blocker
nosy: + benjamin.peterson, georg.brandl, larry
2013-04-20 21:25:20ned.deilysetversions: + Python 2.7, Python 3.3, Python 3.4, - Python 3.1, Python 3.2
nosy: + ned.deily

messages: + msg187463

stage: patch review -> commit review
2013-04-20 16:21:09Alex.Leachsetnosy: + Alex.Leach

messages: + msg187439
versions: - Python 2.6, Python 2.7, Python 3.3, Python 3.4, Python 3.5
2013-03-25 19:33:55dmalcolmcreate