flang in llvm@11.0.1+flang accepted architectures are... off

[nicholas-sly]

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 list

    arm,            // ARM (little endian): arm, armv.*, xscale
    armeb,          // ARM (big endian): armeb
    aarch64,        // AArch64 (little endian): aarch64
    aarch64_be,     // AArch64 (big endian): aarch64_be
    aarch64_32,     // AArch64 (little endian) ILP32: aarch64_32
    arc,            // ARC: Synopsys ARC
    avr,            // AVR: Atmel AVR microcontroller
    bpfel,          // eBPF or extended BPF or 64-bit BPF (little endian)
    bpfeb,          // eBPF or extended BPF or 64-bit BPF (big endian)
    hexagon,        // Hexagon: hexagon
    mips,           // MIPS: mips, mipsallegrex, mipsr6
    mipsel,         // MIPSEL: mipsel, mipsallegrexe, mipsr6el
    mips64,         // MIPS64: mips64, mips64r6, mipsn32, mipsn32r6
    mips64el,       // MIPS64EL: mips64el, mips64r6el, mipsn32el, mipsn32r6el
    msp430,         // MSP430: msp430
    ppc,            // PPC: powerpc
    ppc64,          // PPC64: powerpc64, ppu
    ppc64le,        // PPC64LE: powerpc64le
    r600,           // R600: AMD GPUs HD2XXX - HD6XXX
    amdgcn,         // AMDGCN: AMD GCN GPUs
    riscv32,        // RISC-V (32-bit): riscv32
    riscv64,        // RISC-V (64-bit): riscv64
    sparc,          // Sparc: sparc
    sparcv9,        // Sparcv9: Sparcv9
    sparcel,        // Sparc: (endianness = little). NB: 'Sparcle' is a CPU variant
    systemz,        // SystemZ: s390x
    tce,            // TCE (http://tce.cs.tut.fi/): tce
    tcele,          // TCE little endian (http://tce.cs.tut.fi/): tcele
    thumb,          // Thumb (little endian): thumb, thumbv.*
    thumbeb,        // Thumb (big endian): thumbeb
    x86,            // X86: i[3-9]86
    x86_64,         // X86-64: amd64, x86_64
    xcore,          // XCore: xcore
    nvptx,          // NVPTX: 32-bit
    nvptx64,        // NVPTX: 64-bit
    le32,           // le32: generic little-endian 32-bit CPU (PNaCl)
    le64,           // le64: generic little-endian 64-bit CPU (PNaCl)
    amdil,          // AMDIL
    amdil64,        // AMDIL with 64-bit pointers
    hsail,          // AMD HSAIL
    hsail64,        // AMD HSAIL with 64-bit pointers
    spir,           // SPIR: standard portable IR for OpenCL 32-bit version
    spir64,         // SPIR: standard portable IR for OpenCL 64-bit version
    kalimba,        // Kalimba: generic kalimba
    shave,          // SHAVE: Movidius vector VLIW processors
    lanai,          // Lanai: Lanai 32-bit
    wasm32,         // WebAssembly with 32-bit pointers
    wasm64,         // WebAssembly with 64-bit pointers
    renderscript32, // 32-bit RenderScript
    renderscript64, // 64-bit RenderScript
    ve,             // NEC SX-Aurora Vector Engine
    ```

This was born of hitting failures with Spack defaulting to `-march=broadwell` and that failing.  Below are some other attempts.  Clearly, the list above isn't comprehensive as `pentium4` isn't on that list but was recognized by the compiler.

-bash-4.2$ flang -march=haswell -o hello hello_world.f90
f951: error: bad value (haswell) for -march= switch
-bash-4.2$ flang -march=x86_64 -o hello hello_world.f90
f951: error: bad value (x86_64) for -march= switch
-bash-4.2$ flang -march=x86 -o hello hello_world.f90
f951: error: bad value (x86) for -march= switch
-bash-4.2$ flang -march=aarch64 -o hello hello_world.f90
f951: error: bad value (aarch64) for -march= switch
-bash-4.2$ flang -march=icelake -o hello hello_world.f90
f951: error: bad value (icelake) for -march= switch
-bash-4.2$ flang -march=pentium4 -o hello hello_world.f90
f951: error: CPU you selected does not support x86-64 instruction set
f951: error: CPU you selected does not support x86-64 instruction set
-bash-4.2$ flang -march=x86-64 -o hello hello_world.f90
-bash-4.2$

[alalazo]

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:

1. How did you install flang?
2. How can one reproduce the error you see?

[nicholas-sly]

1. 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"
   }
  },

2. 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 program

You 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]

@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]

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]

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]

Related to #88