Created attachment 474748 [details]
inline-bug.tar.gz

Description of problem:
gcc 4.5.1 generates incorrect code that leads to an assertion fault during postgresql's regression tests.
This appears to be a compiler bug because (1) it goes away at optimization levels below -O2, (2) the
same code works fine on other compilers including other gcc versions, and (3) manually inlining a function that the compiler is apparently trying to automatically inline makes the problem go away.

This is not Red Hat specific --- the same failure has been observed with gcc 4.5.0 on mingw.

Version-Release number of selected component (if applicable):
gcc-4.5.1-4.fc14.x86_64
Also observed on x86 architecture.

How reproducible:
100%

Steps to Reproduce:
1. Build current postgresql git head on Fedora 14, with --with-python and --enable-cassert options.
2. Run plpython regression tests.
  
Actual results:
Fails with log entry
TRAP: FailedAssertion("!(types[i] == procStruct->proargtypes.values[pos])", File: "plpython.c", Line: 1480)

Expected results:
Should pass.

Additional info:
The assertion failure is in a piece of code that had been in PLy_procedure_create() for a long time and worked fine.  It was recently split out as a separate function for code beautification purposes.  That code still works on most compilers, but it's failing on machines using gcc 4.5.x.  Manually re-inlining the code, via simple cut and paste, makes it work again.

The failure occurs on the second iteration of this loop:

        for (i = pos = 0; i < total; i++)
	{
		HeapTuple	argTypeTup;
		Form_pg_type argTypeStruct;

		if (...)
			continue;	/* skip OUT arguments */

		Assert(types[i] == procStruct->proargtypes.values[pos]);

                ...

		pos++;
	}

Inspection of the core dump shows that indeed the two arrays being checked *do* have matching contents, so the assertion should succeed.  I suspect that the compiler is trying to optimize out the i and pos loop variables (because gdb refuses to show their values) and is getting it wrong somehow.  I have not looked into the assembly code though.

In the tarball attachment, plpython.c is the source file that provokes the failure, plpython.i is the intermediate version of this, plpython-ok.c is the source modified by manually inlining the function by simple cut and paste, and plpython-ok.i is the intermediate version of that.

The code is normally compiled like this:

gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -fwrapv -g -fpic -I. -I/usr/include/python2.7 -I../../../src/include -D_GNU_SOURCE   -c -o plpython.o plpython.c