Hi,
On 2018-03-14 22:36:52 -0400, Tom Lane wrote:
> Andres Freund <and...@anarazel.de> writes:
> > On 2018-03-13 15:29:33 -0700, Andres Freund wrote:
> >> On 2018-03-14 10:32:40 +1300, Thomas Munro wrote:
> >>> It looks
> >>> like -fexcess-precision-standard is coming from a configure test that
> >>> was run against ${CC}, not against ${CLANG}, so I hacked the generated
> >>> src/Makefile.global to remove that too, just to see if I could get
> >>> past that.
>
> >> Yea, I'd hoped we could avoid duplicating all the configure tests, but
> >> maybe not :(.
>
> > I've mostly done that now (not pushed). I've created new
> > PGAC_PROG_VARCC_VARFLAGS_OPT(compiler variable, flag variable, testflag)
> > function, which now is used to implement PGAC_PROG_CC_CFLAGS_OPT and
> > PGAC_PROG_CC_VAR_OPT (similar for CXX). That makes it reasonable to
> > test the variables clang recognizes separately.
>
> Meh.
Why? The necessary configure code isn't that large:
# Test for behaviour changing compiler flags, to keep compatibility
# with compiler used for normal postgres code. XXX expand
if test "$with_llvm" = yes ; then
PGAC_PROG_VARCC_VARFLAGS_OPT(CLANG, BITCODE_CFLAGS, [-fno-strict-aliasing])
PGAC_PROG_VARCC_VARFLAGS_OPT(CLANG, BITCODE_CFLAGS, [-fwrapv])
PGAC_PROG_VARCC_VARFLAGS_OPT(CLANG, BITCODE_CFLAGS,
[-fexcess-precision=standard])
AC_SUBST(BITCODE_CFLAGS, $BITCODE_CFLAGS)
fi
If the relevant clang version doesn't understand, say
-fno-strict-aliasing, then we'd in trouble already if it's
required. After all we do support compiling postgres with clang.
> I agree with Thomas' concern that it's not clear we can or should
> just ignore discrepancies between the -f options supported by the C
> and CLANG compilers.
What's the precise concern here? We pass these flags to work around
compiler issues / "defining our standard". As I said above, if we do not
know the right flags to make clang behave sensibly, we're in trouble
already.
For a good part of the code we already want to be compatible with
compiling postgres with one compiler, and linking to libraries compiled
with something else.
> Is it really so necessary to bring a second compiler into the mix for
> this? Why not just insist that JIT is only supported if the main build
> is done with clang, too? My experience with mixing results from different
> compilers is, eh, not positive.
I don't like that option. It doesn't really buy us much, a few lines of
config code, and one additional configure option that should normally be
autodected from the environment. Requiring a specific compiler will be
terrible on windows, seems out of line how we do development, requires
using clang which is still generates a bit slower code, prevent getting
gcc warnings etc.
Greetings,
Andres Freund
