Hi, It seems that postgresql has a problem with a gcc 4.4 snapshot. I've last tested this with the gcc-snapshot package from Debian on x86_64 that has a snapshot from 20081213. It seems that a pointer gets changed into NULL that shouldn't. I've first asked about this on the pgsql list, see the thread starting at http://archives.postgresql.org/pgsql-hackers/2008-12/msg01813.php Kurt
Created attachment 17001 [details] preprocessed file that has the problem
plpython.c:2196: warning: dereferencing type-punned pointer will break strict-aliasing rules plpython.c:2196: warning: dereferencing pointer '_Py_TrueStruct.537' does break strict-aliasing rules plpython.c:2196: warning: dereferencing pointer '_Py_TrueStruct.537' does break strict-aliasing rules plpython.c:2956: warning: variable 'xmsg' might be clobbered by 'longjmp' or 'vfork'
( (((PyObject *) &_Py_TrueStruct))->ob_refcnt++); Yes that is obvious an alias violation.
pgsql uses -fno-strict-aliasing to compile. The command that is being used is: gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -fwrapv -g -fpic -I. -I/usr/include/python2.5 -I../../../src/include -D_GNU_SOURCE -c -o plpython.o plpython.c And I only get those warnings: plpython.c: In function 'PLyDict_FromTuple': plpython.c:1733: warning: value computed is not used plpython.c:1733: warning: value computed is not used
And actually plpython.c:2196: warning: dereferencing pointer '_Py_TrueStruct.537' does break strict-aliasing rules also means that it doesn't get miscompiled ;)
So are you saying that because in an unrelated part of the code there is an aliasing bug gcc can miscompile anything else, even if -fno-strict-aliasing is used? The problem is in the PLy_spi_execute_plan() function. oldcontext ends up being a NULL pointers while the only place it gets assigned something should set it to a non-NULL value.
Created attachment 17021 [details] Reduced test case part 1
Created attachment 17022 [details] Reduced test case part 2
I've reduced the test case. The call to siglongjmp() needs to be in a separate file. When the problem occurs the test program returns exit code 1.
This code might turn out to be undefined ...
Which part do you think think is undefined and what would you recommend to resolve it?
THis is most likely the same issue as PR 38587. Does -fno-ira fix the issue?
My version of gcc doesn't seem to support the -fno-ira option. Is that something that needs to be enabled at compile time? Can you try my test case with that option?
(In reply to comment #13) > My version of gcc doesn't seem to support the -fno-ira option. Well then it is not a snapshot of GCC 4.4.0.
I was still using: gcc (Debian 20081213-1) 4.4.0 20081212 (experimental) [trunk revision 142725] Which doesn't seem to have that option. Upgrading to the latest in Debian gives this version: gcc (Debian 20090107-1) 4.4.0 20090107 (experimental) [trunk revision 143170] Using that version and the -fno-ira option changes the result of my test case.
I am closing it as dup of PR 38587, which will be fixed by http://gcc.gnu.org/ml/gcc-patches/2009-01/msg01067.html Please re-open it if the patch above doesn't fix this bug. *** This bug has been marked as a duplicate of 38587 ***