I'm able to reproduce this on Debian Lenny/x86_64 with a home-built gcc
4.4.0 and the --with-computed-gotos and --with-tsc configure options.

I'm compiling with:

CC=gcc-4.4 ./configure --with-tsc --with-computed-gotos && make

The Python executable builds successfully, and then the module build
stage fails exactly as Artur described.  Here's a minimal failing example:

Python 3.2a0 (py3k:75376, Oct 12 2009, 14:32:36)
[GCC 4.4.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> def f(*args): return None
...
>>> def g(*args): return f(*args)
...
>>> g()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 1, in g
TypeError: f() argument after ** must be a mapping, not tuple

With gcc 4.3.2 I get no failure.  With either of the configure options
removed I get no failure.

After some investigation, I believe the problem is in Python/ceval.c: 
what's going on is that the inline x86 assembly for the READ_TIMESTAMP
macro is clobbering the rdx register.  This clobbering changes the value
of the 'flags' variable in _call_function_var_kw, leading the
ext_do_call to think that it's supposed to be doing a
CALL_FUNCTION_VAR_KW instead of a CALL_FUNCTION_VAR.

I believe this *is* a Python bug:  the inline assembly should be fixed
to use the eax and edx registers explicitly instead of using the "=A"
constraint;  for x86_64, "=A" apparently means the 64-bit rax register,
rather than the edx/eax pair of 32-bit registers (though it's difficult
to find any mention of this in the gcc documentation).

I don't know why the --with-computed-gotos configure option affects this.