On 07/08/2015 04:38 PM, Tom Lane wrote:
Heikki Linnakangas <hlinn...@iki.fi> writes:
I suggest that we revert that work-around for that GCC bug, and stop
testing the pthread flags as soon as we find one that works.
OK ...
Then we can
also remove the test for whether the compiler produces any warnings.
Don't see how that follows?
That test was added after the GCC-bug workaround, because that
workaround caused warnings. The upstream philosophy is to have a list of
flags, and try them in order until you find one that works. With the
workaround that we added, after it finds one flag that makes the pthread
test program to compile, it adds every flag in the list to the command
line as long as they donn't make the test program to fail again. For
example, after it found out that "-pthread" makes the compilation to
work, it appended "-pthreads -mthreads -mt -lpthread --thread-safe" to
PTHREAD_CFLAGS, as long as none of those caused a compiler error. They
could cause warnings though. That's why we had to add the test to check
for warnings.
The only scenario where you might now get warnings if we switch to
upstream version, and didn't before, is if one of the flags makes
pthreads to work, but also creates compiler warnings, while another flag
later in the list would make it work without warnings. That's not
totally inconceivable, but I doubt it happens. In any case, there's
nothing PostgreSQL-specific about that, so if that happens, I'd like to
find out so that we can complain to the upstream.
I'll commit the upstream version, and we'll see what the buildfarm thinks.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
