Re: [PATCH] audo-detect and use -moutline-atomics compilation flag for aarch64 - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [PATCH] audo-detect and use -moutline-atomics compilation flag for aarch64
Date
Msg-id 888692.1601489331@sss.pgh.pa.us
Whole thread Raw
In response to Re: [PATCH] audo-detect and use -moutline-atomics compilation flag for aarch64  ("Zidenberg, Tsahi" <tsahee@amazon.com>)
List pgsql-hackers
"Zidenberg, Tsahi" <tsahee@amazon.com> writes:
> On 29/09/2020, 10:21, "Heikki Linnakangas" <hlinnaka@iki.fi> wrote:
>>>>>> If it's a good idea to use -moutline-atomics, I would expect the
>>>>>> compiler or distribution to enable it by default. And as you pointed
>>>>>> out, many have.

> -moutline-atomics is only enabled by default on the gcc-10 branch where
> it was originally developed. It was important enough to be backported
> to previous versions and picked up by e.g. ubuntu and amazon-linux.
> However, outline-atomics is not enabled by default in any backports that
> I'm aware of. Ubuntu 20.04 even turned it off by default for gcc-10,
> which seems like a compatibility step with the main gcc-9 compiler.
> Always-enabled outline-atomic is, sadly, many years in the
> future for release systems.

I don't find this argument terribly convincing.  I agree that it'll be
a couple years before gcc 10 is in use in "stable production" systems.
But it seems to me that big-iron aarch64 is also some way off from
appearing in stable production systems.  By the time this actually
matters to any measurable fraction of our users, distros will have
converged on reasonable default settings for this option.

In the meantime, you are asking that we more or less permanently expend
configure cycles on checking for an option that seems to have a pretty
short expected useful life, even on the small minority of builds where
it'll do anything at all.  The cost/benefit ratio doesn't seem very
attractive.

None of this prevents somebody from applying the switch in their own
builds, of course.  But I concur with Heikki's reasoning that it's
probably not a great idea for us to, by default, override the distro's
default on this.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: Retry Cached Remote Connections for postgres_fdw in case remote backend gets killed/goes away
Next
From: Tom Lane
Date:
Subject: Re: BUG #16419: wrong parsing BC year in to_date() function