Python-3.2 (SVN) bug [was syntax question]

[Helmut Jarausch]

I wrote
I'm trying to build the recent Python-3.2a (SVN).
It fails in
Lib/tokenize.py (line 87)


85 def group(*choices): return '(' + '|'.join(choices) + ')'
86 def any(*choices): return group(*choices) + '*'
87 def maybe(*choices): return group(*choices) + '?'

with: TypeError: group() argument after ** must be a mapping, not tuple


Meanwhile I could narrow this down to the --with-tsc configure option.
Without it, it builds just fine.

Helmut.

--
Helmut Jarausch

Lehrstuhl fuer Numerische Mathematik
RWTH - Aachen University
D 52056 Aachen, Germany

 

[Mark Dickinson]

I wrote
I'm trying to build the recent Python-3.2a (SVN).
It fails in
Lib/tokenize.py  (line 87)

85  def group(*choices): return '(' + '|'.join(choices) + ')'
86  def any(*choices): return group(*choices) + '*'
87  def maybe(*choices): return group(*choices) + '?'

with: TypeError: group() argument after ** must be a mapping, not tuple

It looks like there's already a tracker issue open for this (or
for something that looks an awful lot like this issue):

http://bugs.python.org/issue6603

but work on that bug has stalled, because core developers have
been unable to reproduce the problem.

It would be really helpful if you could add a comment to that
bug report, giving as much system information (including
compiler information) as possible. If you can come up with any
ideas about what might be causing the failure, that would also
be useful.

Like Antoine, I'd be inclined to suspect that it's a compiler bug,
but it could also be caused by some not-quite-standards-compliant
C code in Python somewhere. What happens if you turn compiler
optimizations off? (E.g., by editing configure.in to remove all
occurrences of '-O3' and then rerunning autoconf and autoheader.)

Thanks,

Mark

 

[Mark Dickinson]

I wrote
I'm trying to build the recent Python-3.2a (SVN).
It fails in
Lib/tokenize.py  (line 87) [...]
with: TypeError: group() argument after ** must be a mapping, not tuple

I believe I've found the source of this problem: the --with-tsc
configure option enables some buggy inline assembly: see the
READ_TIMESTAMP macro in Python/ceval.c. This uses the constraint
"A" for the output of the x86 'rdtsc' instruction; for x86 that's
fine, but for x86_64 it apparently refers to the 'rax' register,
which is wrong: rdtsc loads its result into the edx and eax
registers. So the edx register ends up being clobbered without
gcc knowing about it, and all hell breaks loose as a result.

So it is a Python bug, not a compiler bug. I've updated the
bug report, and the bug should be fixed soonish.

Thanks for reporting this, and for whittling the failure down
to the --with-tsc configure option!

Mark