Re: snapper vs. HEAD
От | Andres Freund |
---|---|
Тема | Re: snapper vs. HEAD |
Дата | |
Msg-id | 20200330005610.qqe73ybfd4awclw5@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: snapper vs. HEAD (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: snapper vs. HEAD
Re: snapper vs. HEAD |
Список | pgsql-hackers |
Hi, On 2020-03-29 20:25:32 -0400, Tom Lane wrote: > Andres Freund <andres@anarazel.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
В списке pgsql-hackers по дате отправления: