With this PR:

$ spack arch
linux-ubuntu18.04-broadwell

$ spack spec zlib %gcc@4.8
Input spec
--------------------------------
zlib%gcc@4.8

Concretized
--------------------------------
==> Warning: cannot build optimized binaries for "broadwell" using gcc@4.8. Downgrading the target to "haswell"
zlib@1.2.11%gcc@4.8+optimize+pic+shared arch=linux-ubuntu18.04-haswell

Marked the PR as draft as I am not sure how we want to treat preferences in packages.yaml - should we error out or downgrade as above when we have a target preference in packages.yaml and we specify a compiler that doesn't support it?

Proposed wording change to make it clear where the limitation is coming from:

Instead of:

Warning: cannot build optimized binaries for "broadwell" using gcc@4.8. Downgrading the target to "haswell"

Say:

Warning: gcc@4.8 cannot build optimized binaries for 'broadwell'. Using best target possible: 'haswell'

should we error out or downgrade as above when we have a target preference in packages.yaml and we specify a compiler that doesn't support it?

For now, downgrade and warn here too, as packages.yaml has always been a soft preference. There is probably a larger discussion about enabling it to have hard constraints. @becker33: thoughts?

For now, downgrade and warn here too, as packages.yaml has always been a soft preference.

The current behavior for target is a hard requirement. With this packages.yaml:

packages:
  all:
    target: [icelake]

I get the following output when compiling with old compilers:

$ spack spec zlib %gcc@4.8
Input spec
--------------------------------
zlib%gcc@4.8

Concretized
--------------------------------
==> Error: cannot produce optimized binary for micro-architecture 'icelake' with gcc@4.8 [supported compiler versions are 8.0:]

Is this to be considered a bug that needs fixing?

@tgamblin With the latest commit target preferences in packages.yaml are considered soft preferences. Added unit tests to ensure that.