Hi,
On 2018-03-13 15:29:33 -0700, Andres Freund wrote:
> On 2018-03-14 10:32:40 +1300, Thomas Munro wrote:
> > I decided to try this on a CentOS 7.2 box. It has LLVM 3.9 in the
> > 'epel' package repo, but unfortunately it only has clang 3.4.
>
> That's a bit odd, given llvm and clang really live in the same repo...
I don't really live in the RHEL world, but I wonder if
https://developers.redhat.com/blog/2017/10/04/red-hat-adds-go-clangllvm-rust-compiler-toolsets-updates-gcc/
is relevant?
Appears to be available on centos too
https://www.softwarecollections.org/en/scls/rhscl/devtoolset-7/
I checked it out and supporting 3.4 would be a bit painful due to not
being able to directly emit module summaries. We could support that by
building the summaries separately using LLVM, but that'd be either
slower for everyone, or we'd need somewhat finnicky conditionals.
> > clang: error: unknown argument: '-fexcess-precision=standard'
> > clang: error: unknown argument: '-flto=thin'
> >
> > Ok, so I hacked src/Makefile.global.in to remove -flto=thin.
>
> I think I can get actually rid of that entirely.
Err, no, not really. Would increase overhead due to separate module
summary generation, so I'd rather not do it.
> > 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.
Greetings,
Andres Freund