Re: v13: Performance regression related to FORTIFY_SOURCE

From: Andres Freund <andres(at)anarazel(dot)de>
To: Jeff Davis <pgsql(at)j-davis(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org, Peter Geoghegan <pg(at)bowt(dot)ie>
Subject: Re: v13: Performance regression related to FORTIFY_SOURCE
Date: 2020-06-06 02:45:01
Message-ID: 20200606024501.dnp3qqprnqu5dd24@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2020-06-05 18:39:28 -0700, Jeff Davis wrote:
> On Fri, 2020-06-05 at 14:49 -0700, Andres Freund wrote:
> > FWIW, with gcc 10 and glibc 2.30 I don't see such a switch. Taking a
> > profile shows me:
>
> ...
>
> > 4.65 │ → callq memcpy(at)plt
> > │ LogicalTapeWrite():
> >
> > I.e. normal memcpy is getting called.
> >
> > That's with -D_FORTIFY_SOURCE=2
>
> That's good news, although people will be using ubuntu 18.04 for a
> while.
>
> Just to confirm, would you mind trying the example programs in the GCC
> bug report?
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95556

I get "call memcpy(at)PLT" for both files. With various debian versions of
gcc (7,8,9,10). But, very curiously, I do see the difference when
compiling with gcc-snapshot (which is a debian package wrapping a recent
snapshot from upstream gcc).

Greetings,

Andres Freund

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2020-06-06 02:52:47 Re: Atomic operations within spinlocks
Previous Message Andres Freund 2020-06-06 02:31:03 Re: Atomic operations within spinlocks