@alalazo Thank you for looking into this. using spack develop this is what I see:

$ ./spack/bin/spack arch
linux-rhel6-broadwell

$  ./spack/bin/spack spec zlib %gcc@4.4.7
Input spec
--------------------------------
zlib%gcc@4.4.7

Concretized
--------------------------------
zlib@1.2.11%gcc@4.4.7+optimize+pic+shared arch=linux-rhel6-haswell

$ ./spack/bin/spack spec zlib %gcc@4.7.2
Input spec
--------------------------------
zlib%gcc@4.7.2

Concretized
--------------------------------
zlib@1.2.11%gcc@4.7.2+optimize+pic+shared arch=linux-rhel6-haswell

$ ./spack/bin/spack spec zlib %gcc@7.2.0
Input spec
--------------------------------
zlib%gcc@7.2.0

Concretized
--------------------------------
zlib@1.2.11%gcc@7.2.0+optimize+pic+shared arch=linux-rhel6-broadwell

on this PR I see:

$ ./old-gcc-bugfix-spack/spack/bin/spack arch
linux-rhel6-broadwell

$ ./old-gcc-bugfix-spack/spack/bin/spack spec zlib %gcc@4.4.7
Input spec
--------------------------------
zlib%gcc@4.4.7

Concretized
--------------------------------
zlib@1.2.11%gcc@4.4.7+optimize+pic+shared arch=linux-rhel6-core2

$ ./old-gcc-bugfix-spack/spack/bin/spack spec zlib %gcc@4.7.2
Input spec
--------------------------------
zlib%gcc@4.7.2

Concretized
--------------------------------
zlib@1.2.11%gcc@4.7.2+optimize+pic+shared arch=linux-rhel6-ivybridge

$ ./old-gcc-bugfix-spack/spack/bin/spack spec zlib %gcc@7.2.0
Input spec
--------------------------------
zlib%gcc@7.2.0

Concretized
--------------------------------
zlib@1.2.11%gcc@7.2.0+optimize+pic+shared arch=linux-rhel6-broadwell

Working from this PR branch spack install zlib %gcc@4.4.7 works as does spack install zlib %gcc@4.7.2 but I cannot build with gcc@7.2.0 with errors like:

    36     /tmp/cc0uMT0y.s: Assembler messages:
  >> 37     /tmp/cc0uMT0y.s:211: Error: no such instruction: `shlx %ebx,%eax,%e
            ax'
  >> 38     /tmp/cc0uMT0y.s:286: Error: no such instruction: `shrx %r14d,%esi,%

I just tested and the above error happens on develop as well. These both fail just like above:

• spack install zlib %gcc@7.2.0 arch=linux-rhel6-haswell
• spack install zlib %gcc@7.2.0 arch=linux-rhel6-broadwell

but this works:

• spack install zlib %gcc@7.2.0 arch=linux-rhel6-x86_64

@fryeguy52 Can you share more information on gcc@7.2.0? Looking at what you posted above it seems an issue with the underlying assembler, which doesn't support compiling some asm instructions correctly generated at the previous stage. Was the compiler built with Spack?

I'm able to build this with gcc 7.2.0 on ubuntu16 in the spack/tutorial image, and I was able to build with gcc 7.3.0 on quartz at LLNL (which is RHEL7). As I do not believe the changes to microarchitectures.json affect how gcc 7 is handled, I'm going to go ahead and merge this and we can see if we can resolve this RHEL6 problem in a separate issue.

@alalazo my gcc was not built with spack so I rebuilt gcc@7.2.0 with spack and am still seeing the same behavior.

@tgamblin

see if we can resolve this RHEL6 problem in a separate issue.

yes that sounds good to me

@fryeguy52 Can you show me the spec? I suspect you built it without building binutils which probably means you are using a dated as that doesn't know how to assemble the asm code generated by gcc@7.2.0.

@alalazo I rebuilt with +binutils and it works now. Thank you

Looks like this commit got rebased (or cherry-picked) as the commit 8808207 and therefore is in the v0.13.0 release:

$ git log-short --dirstat v0.13.0 --not HEAD -- lib/spack/spack/test/architecture.py

8808207 "Fixed optimization flags support for old GCC versions (#13362)"
Author: Massimiliano Culpo <massimiliano.culpo@gmail.com>
Date:   Wed Oct 23 06:40:45 2019 +0200 (7 days ago)

 100.0% lib/spack/spack/test/

...

Is that correct?

Why is the SHA1 different than what is in the v0.13.0 release? What workflow produces this change?

Just noticed the commit log runs way over 80 chars:

commit 8808207ddf711a63a67ead632f6dd7457bc22616
Author: Massimiliano Culpo <massimiliano.culpo@gmail.com>
Date:   Wed Oct 23 06:40:45 2019 +0200

    Fixed optimization flags support for old GCC versions (#13362)
    
    These changes update our gcc microarchitecture descriptions based on manuals found here https://gcc.gnu.org/onlinedocs/ and assuming that new architectures are not added during

M       lib/spack/llnl/util/cpu/microarchitectures.json
M       lib/spack/spack/test/architecture.py
M       lib/spack/spack/test/concretize.py
M       lib/spack/spack/test/modules/lmod.py

Is there no standard in Spack for line-wrapping the log message?

@bartlettroscoe

Why is the SHA1 different than what is in the v0.13.0 release? What workflow produces this change?

I'm not sure I get your question, but this has been simply squash-merged 🤔 If develop in the meanwhile advanced in its history it's normal to have different hashes.

I'm not sure I get your question, but this has been simply squash-merged thinking If develop in the meanwhile advanced in its history it's normal to have different hashes.

It is better to clean up a branch with git rebase -i, force push it, and then explicitly merge it into 'develop'. That way, the SHA1s shown in the PR will be in the 'develop' branch and you can then back out a merged PR if something goes wrong. Otherwise, this is confusing to see what PR are merged into what branch.