)]}'
{
  "commit": "4beeff3c2bf125de9dda8b374ffc9ec052d02810",
  "tree": "b682613108aa207c3495efde93b532180e5dbebd",
  "parents": [
    "5a0c86a17b467e867bf1c0cd8fd6b5bacb82f1d1"
  ],
  "author": {
    "name": "Mintsuki",
    "email": "36459316+Mintsuki@users.noreply.github.com",
    "time": "Wed Sep 16 10:04:20 2026 +0200"
  },
  "committer": {
    "name": "GitHub",
    "email": "noreply@github.com",
    "time": "Wed Sep 16 10:04:20 2026 +0200"
  },
  "message": "[clang][LoongArch] Emit \"target-abi\" module flag (#223647)\n\nThe LoongArch backend reads the ABI from the \"target-abi\" module flag,\nbut clang only emits that flag for ARM, PowerPC and RISC-V. Since LTO code\ngeneration doesn\u0027t see the -target-abi option passed to clang, it falls\nback to the default ABI of the target, which is lp64d for\nloongarch64-unknown-elf, regardless of the ABI the code was compiled for.\n\nWhen an FPU is enabled, this silently miscompiles code built for another\nABI. For example, with -mabi\u003dlp64s, functions get the lp64d calling\nconvention after LTO, passing and returning floating-point values in FP registers \ninstead of general-purpose ones, and the output is marked as double-float. Nothing\nreports this if every object goes through LTO. For instance, a shared library\nbuilt this way links without error, and so does lp64s code built without LTO that\nuses it. Without an FPU, the generated code keeps the soft-float calling\nconvention, but the output is still marked as double-float.\n\nThe mismatch only shows up as an error when LTO output is linked\ntogether with relocatable objects built without LTO, which LLD rejects with \"cannot\nlink object files with different ABI\".\n\nThis patch adds LoongArch to the targets for which clang emits the flag,\nso LTO uses the ABI the code was compiled for. It follows the per-target\napproach taken for ARM (#217601) and PowerPC (#221669), and leaves the existing \nTODO about emitting the flag for every target with a non-empty ABI name as is.\n\nWith the flag present, LTO-linking bitcode built for different LoongArch\nABIs now fails with \"linking module flags \u0027target-abi\u0027: IDs have conflicting\nvalues\" instead of silently picking a single ABI. A -target-abi given to the LTO\nbackend that disagrees with the flag is now also an error. Both match the\nexisting RISC-V behavior.\n\nAssisted-by: Claude Code (Claude Opus 5)\n\nSigned-off-by: Mintsuki \u003cmintsuki@protonmail.com\u003e",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "287d1b7b617f864c3e8132f0b5f6f3d3ece3666c",
      "old_mode": 33188,
      "old_path": "clang/lib/CodeGen/CodeGenModule.cpp",
      "new_id": "ed69ef3e71135867981ce535778147d20d2924b2",
      "new_mode": 33188,
      "new_path": "clang/lib/CodeGen/CodeGenModule.cpp"
    },
    {
      "type": "add",
      "old_id": "0000000000000000000000000000000000000000",
      "old_mode": 0,
      "old_path": "/dev/null",
      "new_id": "5a4826aff180bd42c06ab27b3aeaabae62f280c4",
      "new_mode": 33188,
      "new_path": "clang/test/CodeGen/LoongArch/target-abi-module-flag.c"
    }
  ]
}