Open nicholas-sly opened 3 years ago
alalazo
commented
3 years ago This needs to be investigated. The list you found is very likely that of the families that are supported (e.g. x86_64). Also, I never understood why, but LLVM has a way of specifying micro-architecture support for its tools that is different to that used for compiler frontends (which are meant to be compatible with GNU GCC). Can you post:
flang?
nicholas-sly
commented
3 years ago llvm was installed using Spack with GCC@10.2.0 that was also built using Spack. The version string for the Spack installation is 0.16.0-885-7f86cc87b0 as it came from develop at that commit. The concrete spec for this LLVM installation is:
"llvm": {
"version": "11.0.1",
"arch": {
"platform": "linux",
"platform_os": "rhel7",
"target": {
"name": "broadwell",
"vendor": "GenuineIntel",
"features": [
"adx",
"aes",
"avx",
"avx2",
"bmi1",
"bmi2",
"f16c",
"fma",
"mmx",
"movbe",
"pclmulqdq",
"popcnt",
"rdrand",
"rdseed",
"sse",
"sse2",
"sse4_1",
"sse4_2",
"ssse3"
],
"generation": 0,
"parents": [
"haswell"
]
}
},
"compiler": {
"name": "gcc",
"version": "10.2.0"
},
"namespace": "builtin",
"parameters": {
"all_targets": true,
"build_type": "Release",
"clang": true,
"code_signing": false,
"compiler-rt": true,
"cuda": false,
"cuda_arch": [
"none"
],
"flang": true,
"gold": true,
"internal_unwind": true,
"ipo": false,
"libcxx": true,
"lld": true,
"lldb": true,
"llvm_dylib": false,
"mlir": false,
"omp_debug": false,
"omp_tsan": true,
"polly": true,
"python": true,
"shared_libs": false,
"split_dwarf": false,
"cflags": [],
"cppflags": [],
"cxxflags": [],
"fflags": [],
"ldflags": [],
"ldlibs": []
},
"dependencies": {
"binutils": {
"hash": "dwhryfot345nrjyzfvqmnyd25sgfi7pz",
"type": [
"build",
"link"
]
},
"cmake": {
"hash": "rwws5essxu5gteok5uysl3ghnieqmun7",
"type": [
"build"
]
},
"hwloc": {
"hash": "73rormyoqr67qa2sminsybstxigh2iew",
"type": [
"build",
"link"
]
},
"libedit": {
"hash": "q3wywgntwhtlcfdvfev74mbe54ohjxak",
"type": [
"build",
"link"
]
},
"ncurses": {
"hash": "ttzjnlni63ajssuwtjw7np3vc5nnntni",
"type": [
"build",
"link"
]
},
"perl-data-dumper": {
"hash": "yxufsftsvaa2ukwhhfwduzhlg4ik5pc7",
"type": [
"build"
]
},
"pkgconf": {
"hash": "uwunvrwsde3xavivqtsgky2qs62ly6a4",
"type": [
"build"
]
},
"py-six": {
"hash": "a2lwbvgrq6bzknjroylr4wqbul4wqinv",
"type": [
"build",
"link"
]
},
"python": {
"hash": "ap6kl6rpyj5gcugyhxoqmc25q6r7iqxh",
"type": [
"build",
"link",
"run"
]
},
"swig": {
"hash": "csu7sq4biq6dipef52p544hut4bwfwzo",
"type": [
"build",
"link"
]
},
"z3": {
"hash": "ftwih56dv6oi5kbmud5xo56ttysypt3p",
"type": [
"build",
"link"
]
}
},
"hash": "jcg2rg7dfa3hzkxqtms5coqsnp5ulacm"
}
},The error was initially produced when Spack tried to install something that required the fortran component to be functional and it threw the f951 error from above. It was reproduced by loading the llvm with spack load llvm and trying to build a simple hello_world.f90 program with the flang compiler. The example program is:
-bash-4.2$ cat hello_world.f90
program hello
print *, "Hello World!"
end programYou can see the flang invocation to build this in the initial comment.
Let me know if I can provide any further information to help with this issue.
alalazo
commented
3 years ago @trws @naromero77 Does this seem familiar? I skimmed through the issues in the flang repository at https://github.com/flang-compiler/flang but couldn't see any mention of people having issues with -march.
trws
commented
3 years ago It does not. A build like that should have built for all target architectures, but I'm not sure if flang necessarily uses the same set since it requires MLIR and is still in integration. @naromero77, do you know what the flang list is supposed to look like?
wyphan
commented
2 years ago I skimmed through the issues in the flang repository at https://github.com/flang-compiler/flang but couldn't see any mention of people having issues with
-march.
@alalazo That's classic Flang, not the new LLVM flang based on F18.
Edit: for LLVM flang see https://github.com/llvm/llvm-project/tree/main/flang
alalazo
commented
1 year ago Related to archspec/archspec-json#88
The
-march=<value>flag for compilation with flang under llvm@11.0.1 has an unexpected list of accepted architecture names. I found a file in the install directory with the following listThis was born of hitting failures with Spack defaulting to
-march=broadwelland that failing. Below are some other attempts. Clearly, the list above isn't comprehensive aspentium4isn't on that list but was recognized by the compiler.