I wrote: > Apparently the reasoning is that current_call_data is a static and > therefore the compiler can see everything that can happen to it and > therefore this store into current_call_data is dead code, since the > store six lines below will replace it. Sigh. I shall file a bug, > but I've found that the current crop of gcc maintainers are quite > likely to reject such reports.
Filed at https://bugzilla.redhat.com/show_bug.cgi?id=857236 On the good side: developing a minimal test case showed me that the code is incorrectly compiled only if perl.h has been included. (WTF? No, I don't know why.) So at least this gcc bug should only be affecting plperl.c and not the rest of postgres. > We could fix the immediate problem by marking current_call_data volatile > (I've tested that this makes the problem go away on F17), but I think > what we'd better do instead is mark pg_re_throw() as noreturn. > Hopefully that will also prevent this misoptimization, as well as > similar ones that might be happening elsewhere. But, of course, pg_re_throw() already is marked noreturn. A probably less costly solution than marking current_call_data volatile is just to make it not-static. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs