From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgbf(at)twiska(dot)com, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: snapper vs. HEAD |
Date: | 2020-03-30 00:56:10 |
Message-ID: | 20200330005610.qqe73ybfd4awclw5@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2020-03-29 20:25:32 -0400, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
> > If you still have the environment it might make sense to check wether
> > it's related to one of the other options. But otherwise I wouldn't be
> > against the proposal.
>
> I could, but it's mighty slow, so I don't especially want to try all 2^N
> combinations. Do you have any specific cases in mind?
I'd be most suspicious of -fstack-protector --param=ssp-buffer-size=4
and -D_FORTIFY_SOURCE=2. The first two have direct codegen implications,
the latter can lead to quite different headers being included and adds a
lot of size tracking to the optimizer.
> (I guess we can exclude LDFLAGS, since the assembly output is visibly
> bad.)
Seems likely.
Is it visibly bad when looking at the .s of gistget.c "directly", or
when disassembling the fiinal binary? Because I've seen linkers screw up
on a larger scale than I'd have expected in the past.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Kyotaro Horiguchi | 2020-03-30 00:57:01 | Re: [PATCH] Redudant initilization |
Previous Message | David Steele | 2020-03-30 00:54:41 | Re: backup manifests |