Issue 147665
Summary Triples: Environment vs Object type
Labels new issue
Assignees
Reporter mintsuki
    Reproducer:
```c++
#include <cstdio>
#include <llvm/ADT/StringRef.h>
#include <llvm/ADT/Twine.h>
#include <llvm/TargetParser/Triple.h>
#include <llvm/TargetParser/TargetParser.h>

#define props(X) \
 X(hasEnvironment) \
    X(isArch64Bit) \
    X(isArch32Bit) \
 X(isArch16Bit) \
    X(isMacOSX) \
    X(isiOS) \
    X(isTvOS) \
 X(isWatchOS) \
    X(isWatchABI) \
    X(isXROS) \
    X(isDriverKit) \
    X(isOSzOS) \
    X(isOSDarwin) \
    X(isSimulatorEnvironment) \
    X(isMacCatalystEnvironment) \
    X(isTargetMachineMac) \
 X(isOSNetBSD) \
    X(isOSOpenBSD) \
    X(isOSFreeBSD) \
 X(isOSFuchsia) \
    X(isOSDragonFly) \
    X(isOSSolaris) \
 X(isOSIAMCU) \
    X(isOSUnknown) \
    X(isGNUEnvironment) \
 X(isOSHaiku) \
    X(isUEFI) \
    X(isOSWindows) \
 X(isKnownWindowsMSVCEnvironment) \
    X(isWindowsMSVCEnvironment) \
 X(isWindowsArm64EC) \
    X(isWindowsCoreCLREnvironment) \
 X(isWindowsItaniumEnvironment) \
    X(isWindowsCygwinEnvironment) \
 X(isWindowsGNUEnvironment) \
    X(isOSCygMing) \
    X(isOSMSVCRT) \
 X(isOSNaCl) \
    X(isOSLinux) \
    X(isOSKFreeBSD) \
 X(isOSHurd) \
    X(isOSWASI) \
    X(isOSEmscripten) \
 X(isOSGlibc) \
    X(isOSAIX) \
    X(isOSSerenity) \
 X(isOSBinFormatELF) \
    X(isOSBinFormatCOFF) \
    X(isOSBinFormatGOFF) \
    X(isOSBinFormatMachO) \
    X(isOSBinFormatWasm) \
 X(isOSBinFormatXCOFF) \
    X(isOSBinFormatDXContainer) \
    X(isPS4) \
    X(isPS5) \
    X(isPS) \
    X(isAndroid) \
    X(isMusl) \
 X(isOHOSFamily) \
    X(isOpenHOS) \
    X(isOSLiteOS) \
 X(isDXIL) \
    X(isShaderModelOS) \
    X(isVulkanOS) \
 X(isShaderStageEnvironment) \
    X(isSPIR) \
    X(isSPIRV) \
 X(isSPIRVLogical) \
    X(isNVPTX) \
    X(isAMDGCN) \
    X(isAMDGPU) \
    X(isThumb) \
    X(isARM) \
    X(isTargetEHABICompatible) \
 X(isArmT32) \
    X(isArmMClass) \
    X(isAArch64) \
 X(isLoongArch32) \
    X(isLoongArch64) \
    X(isLoongArch) \
 X(isMIPS32) \
    X(isMIPS64) \
    X(isMIPS) \
    X(isPPC) \
 X(isPPC32) \
    X(isPPC64) \
    X(isPPC64ELFv2ABI) \
 X(isPPC32SecurePlt) \
    X(isRISCV32) \
    X(isRISCV64) \
 X(isRISCV) \
    X(isSPARC32) \
    X(isSPARC64) \
    X(isSPARC) \
 X(isSystemZ) \
    X(isX86) \
    X(isVE) \
    X(isWasm) \
 X(isCSKY) \
    X(isArm64e) \
    X(isX32) \
    X(isBPF) \
 X(supportsCOMDAT) \
    X(hasDefaultEmulatedTLS) \
 X(hasDefaultTLSDESC) \
    X(hasDefaultDataSections) \
 X(hasDLLImportExport) \
    X(isLittleEndian)

#define handleProp(P) if (triple.P()) printf(" %s", #P);

const char* rstr(llvm::StringRef r) {
 if (r.size() == 0) return "(empty)";
    char* dst = (char*)malloc(r.size() + 1);
    memcpy(dst, r.begin(), r.size());
 dst[r.size()] = 0;
    return dst;
}

int main(int argc, char** argv) {
 if (argc != 2) {
        printf("Usage: %s <triple>\n", argv[0]);
 return 1;
    }
    std::string normal = llvm::Triple::normalize(argv[1]);
    printf("normalize %s -> %s\n", argv[1], normal.c_str());
    llvm::Triple triple{normal};
 printf("arch: %s\n", rstr(triple.getArchTypeName(triple.getArch())));
 printf("vendor: %s\n", rstr(triple.getVendorTypeName(triple.getVendor())));
    printf("OS: %s\n", rstr(triple.getOSTypeName(triple.getOS())));
    printf("env: %s\n", rstr(triple.getEnvironmentTypeName(triple.getEnvironment())));
 printf("object format: %s\n", rstr(triple.getObjectFormatTypeName(triple.getObjectFormat())));
 props(handleProp);
    printf("\n");
}
```

Hello,

Consider a target triple such as `x86_64-unknown-unknown-elf`.

`-elf` will be considered the object format for the final, normalised `Triple` object, but `hasEnvironment()` will return true, despite there not being a clear environment being set.

`-elf` is not a valid environment, as one can see from `triple.getEnvironmentTypeName(triple.getEnvironment())` returning `unknown`.

Is this a misunderstanding of mine, or is this a bug with the normalisation/parsing of triples? In my opinion, `hasEnvironment()` should return false as `-elf` is not a valid environment, but rather an object format.
_______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

Reply via email to