On 2017-09-28 20:56:57 -0700, Andres Freund wrote:
> +1, I saw the same in a bleeding edge c++ version.
err, gcc version.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2017-09-28 20:01:37 -0400, Tom Lane wrote:
> I wondered how pervasive this behavior is. AFAICS it is *not* required
> by the C standard; C99 does not say that the left operand of assignment
> must be evaluated first, in fact it says that the order of evaluation is
> unspecified.
FWIW, it's bei
Andres Freund writes:
> On 2017-09-28 18:39:03 -0400, Tom Lane wrote:
>> + * Note: the reason for using a temporary variable "d", here
>> and in
>> + * other places, is that some compilers think "*op->resvalue =
>> f();"
>> + * requires them to evaluate op->re
On 2017-09-28 18:39:03 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2017-09-28 16:21:34 -0400, Tom Lane wrote:
> >> We could save a pointless register spill
> >> and reload if there were a temporary variable in there,
>
> > Makes sense. Do you want to make it so, or shall I?
>
> I just
Andres Freund writes:
> On 2017-09-28 16:21:34 -0400, Tom Lane wrote:
>> We could save a pointless register spill
>> and reload if there were a temporary variable in there,
> Makes sense. Do you want to make it so, or shall I?
I just finished testing a patch, as attached. On my machine (again,
Hi,
On 2017-09-28 16:21:34 -0400, Tom Lane wrote:
> I noticed the following while poking around with perf:
>
>| fcinfo->isnull = false;
>|b5b: movb $0x0,0x1c(%rdx)
>| *op->resvalue =
> op->d.func.fn_addr(fcinfo);
