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