It is much more probable it is an application bug (relying on undefined behavior etc.) than a gcc bug, though of course that can't be ruled out.
If you suspect a miscompilation, let somebody familiar with the source code first try to see if some gcc flags makes it working again (e.g. if compiling with -O0 makes it work, or -O2 -fno-strict-aliasing, etc.). If yes, try to do a binary search between objects compiled with the working options and non-working to narrow the problem to one source file. If not, do a similar binary search between older compiler compiled objects and new compiler compiled objects.
Once you know which source file is problematic, first compile it with -W -Wall, look at all the warnings, see if some of them might not show up problem in the code, if not, try to narrow down the problem to a particular source file (and see if it can be reproduced even with -fno-inline, that helps to narrow it down to a function), then try to create a self-contained testcase calling that function with the right arguments and abort or somehow else signal if that function misbehaves.

Here's the start of the definition of that function:
static PyObject *
call_function(PyObject ***pp_stack, int oparg
#ifdef WITH_TSC
, uint64* pintr0, uint64* pintr1
#endif
)
It could be that the WITH_TSC is confused, perhaps, but there is this forwards-declaration:
#ifdef WITH_TSC
static PyObject * call_function(PyObject ***, int, uint64*, uint64*);
#else
static PyObject * call_function(PyObject ***, int);
#endif
and it appears to be used consistently throughout.
I don't know if this is significant, but frame #0 in that backtrace is reported with the arguments in reverse order to those of the declaration.
Here's the frame from the backtrace:
#0 call_function (pintr1=0xfffcf8b6be0, pintr0=0xfffcf8b6bd8, oparg=<optimized out>, pp_stack=0xfffcf8b6be8)
at /builddir/build/BUILD/Python-2.7.1/Python/ceval.c:4105
Every other frame appears to be reported with the arguments in the same order as in the declaration; this one is reported in reverse order.

no, a bodhi update is not needed, I can have a different n-v-r on PPC than on the primary archs, although I try to avoid it if possible. The only requirements are that the patch is in git so that the next python update will work out of the box on PPC and that the next n-v-r on the primary archs is higher than what we have on PPC. Both requirements are met and I can just pull in the new package.
Unfortunately python and python3 still fail to build in koji, although the builds progressed beyond the secfault issue.
I've opened bugzilla 732998 to track the new problem