On Thu, Sep 03, 2020 at 10:53:37PM -0400, Tom Lane wrote:
> Noah Misch writes:
> > We do assume dereferencing NULL would crash, but we also assume this
> > optimization doesn't happen:
>
> > #ifndef REMOVE_MEMCPY
> > memcpy(dest, src, n);
> > #endif
> > if (src)
> > pause();
>
> > [
Peter Geoghegan writes:
> On Thu, Sep 3, 2020 at 7:53 PM Tom Lane wrote:
>> I'd still leave -fdelete-null-pointer-checks
>> enabled, because it can make valid and useful optimizations in
>> other cases.
> Is there any evidence that that's true? I wouldn't assume that the gcc
> people exercised g
On Thu, Sep 3, 2020 at 7:53 PM Tom Lane wrote:
> Hm. I would not blame that on -fdelete-null-pointer-checks per se.
> Rather the problem is what we were touching on before: the dubious
> but standard-approved assumption that memcpy's arguments cannot be
> null.
Isn't it both, together? That is,
Noah Misch writes:
> We do assume dereferencing NULL would crash, but we also assume this
> optimization doesn't happen:
> #ifndef REMOVE_MEMCPY
> memcpy(dest, src, n);
> #endif
> if (src)
> pause();
> [ gcc believes the if-test is unnecessary ]
Hm. I would not blame that on -fde
On Sat, Aug 29, 2020 at 12:36:42PM -0400, Tom Lane wrote:
> Peter Geoghegan writes:
> > I wonder if we should start using -fno-delete-null-pointer-checks:
> > https://lkml.org/lkml/2018/4/4/601
> > This may not be strictly relevant to the discussion, but I was
> > reminded of it just now and thoug
Hi,
On 2020-08-31 17:35:14 -0300, Ranier Vilela wrote:
> Em seg., 31 de ago. de 2020 às 17:05, Andres Freund
> escreveu:
> > So it seems Rainier needs to turn this test off, because it actually is
> > intentional.
> >
> No problem.
> If intentional, the code at TransactionIdPrecedes, already know
Em seg., 31 de ago. de 2020 às 17:05, Andres Freund
escreveu:
> Hi,
>
> On 2020-08-31 12:38:51 -0700, Peter Geoghegan wrote:
> > On Mon, Aug 31, 2020 at 11:42 AM Andres Freund
> wrote:
> > > Unsigned integer overflow is well defined in the standard. So I don't
> understand what this is purportin
Em seg., 31 de ago. de 2020 às 16:39, Peter Geoghegan escreveu:
> On Mon, Aug 31, 2020 at 11:42 AM Andres Freund wrote:
> > Unsigned integer overflow is well defined in the standard. So I don't
> understand what this is purporting to warn about.
>
> Presumably it's simply warning that the value
Hi,
On 2020-08-31 12:38:51 -0700, Peter Geoghegan wrote:
> On Mon, Aug 31, 2020 at 11:42 AM Andres Freund wrote:
> > Unsigned integer overflow is well defined in the standard. So I don't
> > understand what this is purporting to warn about.
>
> Presumably it's simply warning that the value -429
On Mon, Aug 31, 2020 at 11:42 AM Andres Freund wrote:
> Unsigned integer overflow is well defined in the standard. So I don't
> understand what this is purporting to warn about.
Presumably it's simply warning that the value -4294901760 (i.e. the
result of 3 - 4294901763) cannot be faithfully rep
Hi,
On August 31, 2020 11:08:49 AM PDT, Ranier Vilela wrote:
>Em seg., 31 de ago. de 2020 às 14:43, Ranier Vilela
>
>escreveu:
>
>> Em seg., 31 de ago. de 2020 às 14:00, Alvaro Herrera <
>> alvhe...@2ndquadrant.com> escreveu:
>>
>>> On 2020-Aug-31, Ranier Vilela wrote:
>>>
>>> > More troubles wi
Em seg., 31 de ago. de 2020 às 14:43, Ranier Vilela
escreveu:
> Em seg., 31 de ago. de 2020 às 14:00, Alvaro Herrera <
> alvhe...@2ndquadrant.com> escreveu:
>
>> On 2020-Aug-31, Ranier Vilela wrote:
>>
>> > More troubles with undefined-behavior.
>> >
>> > This type of code can leaves overflow:
>>
Em seg., 31 de ago. de 2020 às 14:00, Alvaro Herrera <
alvhe...@2ndquadrant.com> escreveu:
> On 2020-Aug-31, Ranier Vilela wrote:
>
> > More troubles with undefined-behavior.
> >
> > This type of code can leaves overflow:
> > var = (cast) (expression);
> > diff = (int32) (id1 - id2);
> >
> > See:
On 2020-Aug-31, Ranier Vilela wrote:
> More troubles with undefined-behavior.
>
> This type of code can leaves overflow:
> var = (cast) (expression);
> diff = (int32) (id1 - id2);
>
> See:
> diff64 = ((long int) d1 - (long int) d2);
> diff64=-4294901760
Did you compile this with gcc -f
More troubles with undefined-behavior.
This type of code can leaves overflow:
var = (cast) (expression);
diff = (int32) (id1 - id2);
See:
diff64 = ((long int) d1 - (long int) d2);
diff64=-4294901760
#include
#include
int main()
{
unsigned int d1 = 3;
unsigned int d2 = 4294901
Peter Geoghegan writes:
> I wonder if we should start using -fno-delete-null-pointer-checks:
> https://lkml.org/lkml/2018/4/4/601
> This may not be strictly relevant to the discussion, but I was
> reminded of it just now and thought I'd mention it.
Hmm. gcc 8.3 defines this as:
Assume that
Em sex., 28 de ago. de 2020 às 03:04, Noah Misch
escreveu:
> On Thu, Aug 27, 2020 at 11:11:47PM -0400, Tom Lane wrote:
> > Noah Misch writes:
> > > On Thu, Aug 27, 2020 at 12:57:20PM -0400, Alvaro Herrera wrote:
> > >> Looks legit, and at least per commit 13bba02271dc we do fix such
> things,
>
On Thu, Aug 27, 2020 at 11:04 PM Noah Misch wrote:
> On Thu, Aug 27, 2020 at 11:11:47PM -0400, Tom Lane wrote:
> > It's surely not hard to visualize cases where necessary code could
> > be optimized away if the compiler thinks it's entitled to assume
> > such things.
>
> Good point.
I wonder if w
Em sex., 28 de ago. de 2020 às 00:11, Tom Lane escreveu:
>
> In other words, the C standard made a damfool decision and now we need
> to deal with the consequences of that as perpetrated by other fools.
> Still, it's all hypothetical so far --- does anyone have examples of
> actual rather than th
On Thu, Aug 27, 2020 at 11:11:47PM -0400, Tom Lane wrote:
> Noah Misch writes:
> > On Thu, Aug 27, 2020 at 12:57:20PM -0400, Alvaro Herrera wrote:
> >> Looks legit, and at least per commit 13bba02271dc we do fix such things,
> >> even if it's useless in practice.
> >> Given that no buildfarm membe
Noah Misch writes:
> On Thu, Aug 27, 2020 at 12:57:20PM -0400, Alvaro Herrera wrote:
>> Looks legit, and at least per commit 13bba02271dc we do fix such things,
>> even if it's useless in practice.
>> Given that no buildfarm member has ever complained, this exercise seems
>> pretty pointless.
> L
On Thu, Aug 27, 2020 at 12:57:20PM -0400, Alvaro Herrera wrote:
> On 2020-Aug-27, Ranier Vilela wrote:
> > indexcmds.c (1162):
> > memcpy(part_oids, partdesc->oids, sizeof(Oid) * nparts);
>
> Looks legit, and at least per commit 13bba02271dc we do fix such things,
> even if it's useless in practic
On 2020-Aug-27, Ranier Vilela wrote:
> If we are passing a null pointer in these places and it should not be done,
> it is a sign that perhaps these calls should not or should not be made, and
> they can be avoided.
Feel free to send a patch.
--
Álvaro Herrerahttps://www.2ndQuad
Em qui., 27 de ago. de 2020 às 13:57, Alvaro Herrera <
alvhe...@2ndquadrant.com> escreveu:
> On 2020-Aug-27, Ranier Vilela wrote:
>
> > indexcmds.c (1162):
> > memcpy(part_oids, partdesc->oids, sizeof(Oid) * nparts);
>
> Looks legit, and at least per commit 13bba02271dc we do fix such things,
> ev
Em qui., 27 de ago. de 2020 às 13:57, Alvaro Herrera <
alvhe...@2ndquadrant.com> escreveu:
> On 2020-Aug-27, Ranier Vilela wrote:
>
> > indexcmds.c (1162):
> > memcpy(part_oids, partdesc->oids, sizeof(Oid) * nparts);
>
> Looks legit, and at least per commit 13bba02271dc we do fix such things,
> ev
On 2020-Aug-27, Ranier Vilela wrote:
> indexcmds.c (1162):
> memcpy(part_oids, partdesc->oids, sizeof(Oid) * nparts);
Looks legit, and at least per commit 13bba02271dc we do fix such things,
even if it's useless in practice.
Given that no buildfarm member has ever complained, this exercise seems
26 matches
Mail list logo
