)]}'
{
  "commit": "8aaa5f6e62075c8bd3cfe7ec2d4f3543b3e6eccd",
  "tree": "e758c33cad315b58a0de1b5c5530839efe570b57",
  "parents": [
    "0a970b2702183d290df044858fd4df13ef698924"
  ],
  "author": {
    "name": "Oleg Tolmatcev",
    "email": "oleg.tolmatcev@gmail.com",
    "time": "Wed Sep 16 20:41:23 2026 +0200"
  },
  "committer": {
    "name": "Jonathan Yong",
    "email": "10walls@gmail.com",
    "time": "Fri Sep 25 11:55:12 2026 +0000"
  },
  "message": "function: honour over-alignment in assign_stack_local [PR54412]\n\nTargets that cannot guarantee arbitrary stack alignment cap stack slots at\nMAX_SUPPORTED_STACK_ALIGNMENT.  Win64 SEH caps MAX_STACK_ALIGNMENT at 128\nbits; aarch64 does not define MAX_STACK_ALIGNMENT and is capped at\nSTACK_BOUNDARY, also 128 bits.  assign_stack_local silently ignored any\nalignment beyond that cap.\n\nA 256-bit vector requires 32-byte alignment, but its slot could therefore\nreceive only 16-byte alignment while later MEM attributes still claimed 32.\nx86 could select vmovaps from that MEM_ALIGN and fault on the under-aligned\nslot (PR54412, MSYS2/MINGW-packages#1209).  An escaped pointer has the same\nproblem even when the local move is unaligned, since its type still promises\nthe callee a 32-byte-aligned object.\n\nMake assign_stack_local_1 honour an explicit alignment beyond the cap by\nreserving enough space and aligning an address inside it at run time, as\nassign_parm_setup_block already did for BLKmode parameters and\nexpand_stack_vars does for locals.  Base the extra space on the alignment\nguaranteed for VIRTUAL_STACK_VARS_REGNUM rather than on the maximum alignment\nsupported by the backend, since the frame itself is not guaranteed to have\nthe latter alignment on all targets.\n\nLet a new internal assign_stack_local_2 return the address before run-time\nalignment.  Store it in the temp slot and realign the address on reuse, while\navoiding splitting or combining over-aligned slots.\n\nHonour required temporary alignment at run time, but cap merely preferred\nalignment.  Preserve zero-size behavior and the target\u0027s preferred stack\nboundary, and emit run-time alignment only during expansion to RTL.\n\nUse ASLK_REDUCE_ALIGN where less alignment is acceptable: LRA spill slots and\nthe deliberately over-aligned SJLJ function context.\n\nRegtested on x86_64-pc-linux-gnu and, under QEMU, on\naarch64-unknown-linux-gnu, with no new failures.\n\ngcc/ChangeLog:\n\n\tPR target/54412\n\t* except.cc (sjlj_build_landing_pads): Pass ASLK_REDUCE_ALIGN.\n\t* function.cc (assign_stack_local_2): New function, split from\n\tassign_stack_local_1.  Honour an explicit alignment beyond\n\tMAX_SUPPORTED_STACK_ALIGNMENT by overallocating the slot and aligning\n\tits address at run time.  Optionally return the address before run-time\n\talignment.\n\t(assign_stack_local_1): Wrap assign_stack_local_2.\n\t(temp_slot): Add base_addr.\n\t(assign_stack_temp_for_type): Distinguish required and preferred\n\talignment.  Record the address before run-time alignment and recalculate\n\tthe aligned address when reusing an over-aligned slot.  Do not split an\n\tover-aligned BLKmode slot.\n\t(combine_temp_slots): Do not combine over-aligned slots.\n\t(assign_parm_setup_block): Let assign_stack_local align the slot.\n\t* lra-spills.cc (assign_mem_slot): Pass ASLK_REDUCE_ALIGN.\n\nSigned-off-by: Oleg Tolmatcev \u003coleg.tolmatcev@gmail.com\u003e\nSigned-off-by: Jonathan Yong \u003c10walls@gmail.com\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "98876833ee1e8fc9f309005548f58131c101e1f7",
      "old_mode": 33188,
      "old_path": "gcc/except.cc",
      "new_id": "e3b8645733614abc158c9929c2565acaa44f7f36",
      "new_mode": 33188,
      "new_path": "gcc/except.cc"
    },
    {
      "type": "modify",
      "old_id": "0a0e83badae197775e028d9f87ab3b77592c5e08",
      "old_mode": 33188,
      "old_path": "gcc/function.cc",
      "new_id": "675c07d3b08087bb033fdf604901966b619624fc",
      "new_mode": 33188,
      "new_path": "gcc/function.cc"
    },
    {
      "type": "modify",
      "old_id": "07801e39d5cdeecebfa6667cb79da8962e82faf7",
      "old_mode": 33188,
      "old_path": "gcc/lra-spills.cc",
      "new_id": "f55839f50b7bdbe0b5fc76092bbf4da85078f6e5",
      "new_mode": 33188,
      "new_path": "gcc/lra-spills.cc"
    }
  ]
}