No, I don't have a specific example where this fails.

But then, I haven't tried all points in 'The Matrix' of x86, powerpc,
arm, GCC, Intel, clang, PGI, XL, old compilers, new compilers, etc,
etc.

I'm impressed that Red Hat can keep their code clean enough where it
builds without warnings the way they run it. But when you release
something into the wild, people will try it on other platforms with
other compilers and I don't know if RH has tested all of them.

IMO, spack builds are sometimes a bit fragile and I'm trying to make
them more robust. In this case, I think that '-Wall -Werror' is just
asking for trouble.

But you have taunted The Machine. :-) I like to think of my alter ego
as "The Big, Bad Counter-Example Machine," where I can always find a
bug in anyone's code. I'll try poking a few more data points.

Ok, here's an example where -Werror fails the build. This example is
on a small x86 cluster at Rice with modules for Intel 2018, but it
probably happens with any Intel compiler.

spack  install  -v  -j 1  elfutils~nls  %intel

It fails on the 3rd file that icc tries to compile.

In file included from xstrndup.c(36):
system.h(94): error #1338: arithmetic on pointer to void or function type
        ssize_t ret = TEMP_FAILURE_RETRY (pwrite (fd, buf + recvd, len - recvd,
                      ^

This comes from pwrite_retry() in system.h:

static inline ssize_t __attribute__ ((unused))
pwrite_retry (int fd, const void *buf, size_t len, off_t off)
{
  ssize_t recvd = 0;

  do
    {
      ssize_t ret = TEMP_FAILURE_RETRY (pwrite (fd, buf + recvd, len - recvd,
                                                off + recvd));

With filter_file() to erase -Werror, the build succeeds, with
warnings.

So, -Werror causes Intel to fail the build over 'buf + recvd' where
buf is a 'void *'.

Elfutils might consider this example a bit out of bounds because I
think they mainly support GNU. But icc tries to emulate GNU and
passes all their configure tests, including gnu99, so ....

It also occurs to me that elfutils includes header files from other
packages: libintl.h, bzlib.h, lzma.h, zlib.h. So, that would put the
build at risk if one of those files had some old usage.

Ok?

@healther I sympathize. For me, I get worried when I see
'-Wall -Werror', very few packages can survive this.

My whole reason is to make spack builds more robust. In chess, this
is called 'prophylaxis', defending against a threat before it becomes
a threat. I'm not waiting for a compiler to complain about arithmetic
on a 'void *', or some other warning. I'll fix it ahead of time.

@adamjstewart You asked almost the same thing in PR #8912 for
libiberty. :-) (Except libiberty is complicated by the need to add
-fPIC to cflags).

This is covered in lib/spack/spack/package.py. Look for
inject_flags(), env_flags() and build_system_flags().

For fully autotools packages (including elfutils), build_system_flags()
takes the cflags='...' argument from spack and passes it to CFLAGS on
the autotools configure line (same for the other 5 flags).

Autotools packages expect to see CC, CFLAGS, etc on the configure
line, so IMO this is the correct thing to do for autotools.

Note: without build_system_flags() or flag_handler(), any spack cflags
are added to the compiler wrapper and CFLAGS is not passed to
configure. For autotools, configure will then choose a default value,
normally '-g -O2'. So, if you specify cflags with something like
this:

spack install package cflags='-O1'

Then you end up with a compile line like this, which doesn't obey the
spack install line.

/spack/wrapper/gcc -O1 ... -g -O2 ...

That's the real reason for build_system_flags(), so that cflags from
the spack install line are correctly passed through autotools
configure to the compile line.

It's complicated and IMO, spack still has some rough edges on this
point.

Anything else, or are we ready to commit?