================ @@ -3581,8 +3582,10 @@ ConstantAddress CodeGenModule::GetAddrOfTemplateParamObject( isExternallyVisible(TPO->getLinkageAndVisibility().getLinkage()) ? llvm::GlobalValue::LinkOnceODRLinkage : llvm::GlobalValue::InternalLinkage; - auto *GV = new llvm::GlobalVariable(getModule(), Init->getType(), - /*isConstant=*/true, Linkage, Init, Name); + auto *GV = new llvm::GlobalVariable( + getModule(), Init->getType(), + /*isConstant=*/true, Linkage, Init, Name, nullptr, + llvm::GlobalValue::NotThreadLocal, GlobalsInt8PtrTy->getAddressSpace()); ---------------- efriedma-quic wrote:
If the datalayout is broken, codegen and optimizations break in other ways... the important thing here is consistency. It isn't really relevant whether the backend ultimately lowers to ELF, or WASM, or SPIRV; everything needs to agree on the properties of different address-spaces. For example, there are IR optimizations that create globals. So I'd much rather fix this problem now, rather than continue to scatter workarounds across the codebase. If the datalayout can't be fixed for some reason, we can discuss that, but I don't see any obvious reason why that would be the case. https://github.com/llvm/llvm-project/pull/88182 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits