Heikki Linnakangas writes:
> On 02/01/2015 03:56 PM, Martijn van Oosterhout wrote:
>> If you want the compiler to catch this, I don't see any way without
>> requiring the code to indicate specifically which local variables it
>> intends to use, or not using the locals at all by using a seperate
>>
On 02/01/2015 03:56 PM, Martijn van Oosterhout wrote:
If you want the compiler to catch this, I don't see any way without
requiring the code to indicate specifically which local variables it
intends to use, or not using the locals at all by using a seperate
cleanup function (as discussed elsewher
Martijn van Oosterhout writes:
> Never mind, it doesn't work. It's not that GCC doesn't know setjmp() is
> special, it does (the returns_twice attribute). So GCC does the above
> effectivly itself. The problem is that local variables may be stored
> in memory over calls in the PG_TRY() block, vo
On Sun, Jan 25, 2015 at 07:11:12PM -0500, Tom Lane wrote:
> Martijn van Oosterhout writes:
> > On Sun, Jan 25, 2015 at 02:02:47PM -0500, Tom Lane wrote:
> > It's a bit of a long shot, but perhaps if you put something like:
>
> > asm volatile("":"":"":"memory")
>
> > at the beginning of the catch
On Mon, Jan 26, 2015 at 1:34 PM, Andres Freund wrote:
> I guess we'd need to tie it into PG_exception_stack levels, so it
> correctly handles nesting with sigsetjmp locations. In contrast to
> sigsetjmp() style handlers we can't rely on PG_CATCH cleaning up that
> state.
I was thinking that PG_TR
> >> Aside from any reduction in the need
> >> for volatile, this might actually perform slightly better, because
> >> sigsetjmp() is a system call on some platforms. There are probably
> >> few cases where that actually matters, but the one in pq_getmessage(),
> >> for example, might not be entir
> That's pretty similar to to PG_ENSURE_ERROR_CLEANUP, except that that is
> also called after FATAL errors. If we do this, we probably should try to
> come up with a easier to understand naming scheme. PG_TRY_WITH_CLEANUP
> vs. PG_ENSURE_ERROR_CLEANUP isn't very clear to a reader.
Yep.
>> Instea
On 2015-01-26 11:18:41 -0500, Tom Lane wrote:
> Also and perhaps more to the point, I'm no longer convinced that this sort
> of thing doesn't require any volatile markers. The fundamental problem
> we're hitting with PG_TRY is that the compiler is optimizing on the
> assumption that no "unexpected
Robert Haas writes:
> On Sun, Jan 25, 2015 at 2:02 PM, Tom Lane wrote:
>> This is scary as hell. I intend to go around and manually audit
>> every single PG_TRY in the current source code, but that is obviously
>> not a long-term solution. Anybody have an idea about how we might
>> get trustwor
On 2015-01-26 10:52:07 -0500, Robert Haas wrote:
> On Sun, Jan 25, 2015 at 2:02 PM, Tom Lane wrote:
> > This is scary as hell. I intend to go around and manually audit
> > every single PG_TRY in the current source code, but that is obviously
> > not a long-term solution. Anybody have an idea abo
On Sun, Jan 25, 2015 at 2:02 PM, Tom Lane wrote:
> This is scary as hell. I intend to go around and manually audit
> every single PG_TRY in the current source code, but that is obviously
> not a long-term solution. Anybody have an idea about how we might
> get trustworthy mechanical detection of
Andres Freund writes:
> On 2015-01-25 14:02:47 -0500, Tom Lane wrote:
>> I've been looking for other instances of the problem Mark Wilding
>> pointed out, about missing "volatile" markers on variables that
>> are modified in PG_TRY blocks and then used in the PG_CATCH stanzas.
>> There definitely
On 2015-01-25 15:40:10 -0500, Tom Lane wrote:
> Greg Stark writes:
> > Perhaps Clang has a more useful warning?
>
> Clang, at least the version on my Mac, doesn't warn either with the
> settings we normally use, and it doesn't have -Wclobber at all.
> I tried turning on -Weverything, and it still
Hi,
On 2015-01-25 14:02:47 -0500, Tom Lane wrote:
> I've been looking for other instances of the problem Mark Wilding
> pointed out, about missing "volatile" markers on variables that
> are modified in PG_TRY blocks and then used in the PG_CATCH stanzas.
> There definitely are some. Current gcc v
Martijn van Oosterhout writes:
> On Sun, Jan 25, 2015 at 02:02:47PM -0500, Tom Lane wrote:
>> This is scary as hell. I intend to go around and manually audit
>> every single PG_TRY in the current source code, but that is obviously
>> not a long-term solution. Anybody have an idea about how we mi
On Sun, Jan 25, 2015 at 02:02:47PM -0500, Tom Lane wrote:
> and compared the assembly language generated with and without adding
> "volatile" to Tmpfd's declaration. Without "volatile" (ie, in the
> code as shipped), gcc optimizes away the assignment "Tmpfd = -1"
> within PG_TRY, and it also optim
Greg Stark writes:
> Some Google(tm)ing does turn up plenty of other people complaining about
> similar behaviour. This report seems to have the most enlightening response:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54561
Yeah, I saw that before too. I got an interesting response from Jakub
Some Google(tm)ing does turn up plenty of other people complaining about
similar behaviour. This report seems to have the most enlightening response:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54561
Perhaps Clang has a more useful warning?
I've been looking for other instances of the problem Mark Wilding
pointed out, about missing "volatile" markers on variables that
are modified in PG_TRY blocks and then used in the PG_CATCH stanzas.
There definitely are some. Current gcc versions do not warn about that.
If you turn on -Wclobbered
19 matches
Mail list logo
