Re: BUG #7516: PL/Perl crash

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