{"payload":{"feedbackUrl":"https://github.com/orgs/community/discussions/53140","repo":{"id":744596440,"defaultBranch":"main","name":"llvm-project","ownerLogin":"rickyz","currentUserCanPush":false,"isFork":true,"isEmpty":false,"createdAt":"2024-01-17T16:13:49.000Z","ownerAvatar":"https://avatars.githubusercontent.com/u/616784?v=4","public":true,"private":false,"isOrgOwned":false},"refInfo":{"name":"","listCacheKey":"v0:1714716003.0","currentOid":""},"activityList":{"items":[{"before":"d8b6765b8fc56ec5ae39b1ff28f6cfd279706418","after":"fc4795ee6dcc7b6c5be275a8668dd50413dad6c7","ref":"refs/heads/xray_leaf_stack_alignment","pushedAt":"2024-05-28T04:25:39.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"rickyz","name":"Ricky Zhou","path":"/rickyz","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/616784?s=80&v=4"},"commit":{"message":"fixup! fixup! fixup! [xray] Fix stack alignment for custom event calls.\n\nMove test into xray-custom-log.ll.","shortMessageHtmlLink":"fixup! fixup! fixup! [xray] Fix stack alignment for custom event calls."}},{"before":"5998490edce3ab5de0c7cf291e7bd329f5ae3508","after":"d8b6765b8fc56ec5ae39b1ff28f6cfd279706418","ref":"refs/heads/xray_leaf_stack_alignment","pushedAt":"2024-05-28T03:56:22.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"rickyz","name":"Ricky Zhou","path":"/rickyz","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/616784?s=80&v=4"},"commit":{"message":"fixup! fixup! [xray] Fix stack alignment for custom event calls.\n\nUse MachineFunction::getFrameInfo","shortMessageHtmlLink":"fixup! fixup! [xray] Fix stack alignment for custom event calls."}},{"before":"abb580e748d9e31f794a993e9bb6323002d04cfd","after":"5998490edce3ab5de0c7cf291e7bd329f5ae3508","ref":"refs/heads/xray_leaf_stack_alignment","pushedAt":"2024-05-28T03:53:36.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"rickyz","name":"Ricky Zhou","path":"/rickyz","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/616784?s=80&v=4"},"commit":{"message":"fixup! [xray] Fix stack alignment for custom event calls.\n\nAdd file comment to test.","shortMessageHtmlLink":"fixup! [xray] Fix stack alignment for custom event calls."}},{"before":"1bbcedb5c9c9b4992b67d3e70554585163870866","after":"6aa0eae5add9e45a99c2c7d9be1089706ab969b5","ref":"refs/heads/xray_conditional_tail_call","pushedAt":"2024-05-28T03:32:45.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"rickyz","name":"Ricky Zhou","path":"/rickyz","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/616784?s=80&v=4"},"commit":{"message":"fixup! [xray] Handle conditional calls when lowering patchable tail calls.\n\nMerge xray-conditional-tail-call.ll into xray-tail-call-sled.ll.","shortMessageHtmlLink":"fixup! [xray] Handle conditional calls when lowering patchable tail c…"}},{"before":"fa41e53182c93634552cb9add2ebddb31bd9d7f2","after":"c2677058dfe535afcde4a3199cffe1c40372fed6","ref":"refs/heads/xray_fdr_iterator_oob","pushedAt":"2024-05-03T06:20:31.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"rickyz","name":"Ricky Zhou","path":"/rickyz","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/616784?s=80&v=4"},"commit":{"message":"[xray] Fix oob memory access in FDR BufferQueue iterator.\n\nBefore this change, the FDR BufferQueue iterator could access oob memory\ndue to checks of the form `!Buffers[Offset].Used && Offset != Max`. This\nallows access to `Buffers[Max]`, which is past the end of the `Buffers`\narray. This can lead to crashes when that memory is not mapped. Fix this\nby testing `Offset != Max` first.","shortMessageHtmlLink":"[xray] Fix oob memory access in FDR BufferQueue iterator."}},{"before":"ea7b6c358269b5bc0a8d0967c45fe41bc5763c3e","after":"fa41e53182c93634552cb9add2ebddb31bd9d7f2","ref":"refs/heads/xray_fdr_iterator_oob","pushedAt":"2024-05-03T06:08:32.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"rickyz","name":"Ricky Zhou","path":"/rickyz","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/616784?s=80&v=4"}},{"before":null,"after":"ea7b6c358269b5bc0a8d0967c45fe41bc5763c3e","ref":"refs/heads/xray_fdr_iterator_oob","pushedAt":"2024-05-03T06:00:03.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"rickyz","name":"Ricky Zhou","path":"/rickyz","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/616784?s=80&v=4"},"commit":{"message":"[xray] Fix oob memory access in FDR BufferQueue iterator.\n\nBefore this change, the FDR BufferQueue iterator could access memory out\nof due to checks of the form `!Buffers[Offset].Used && Offset != Max`,\nwhich can potentially access `Buffers[Max]`, which is past the end of\nthe `Buffers`. Fix this by testing `Offset != Max` first.","shortMessageHtmlLink":"[xray] Fix oob memory access in FDR BufferQueue iterator."}},{"before":"7d4be9f554fc6ddf6ff972d2db016915adc2cd86","after":"1bbcedb5c9c9b4992b67d3e70554585163870866","ref":"refs/heads/xray_conditional_tail_call","pushedAt":"2024-04-20T01:04:18.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"rickyz","name":"Ricky Zhou","path":"/rickyz","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/616784?s=80&v=4"},"commit":{"message":"[xray] Handle conditional calls when lowering patchable tail calls.\n\nxray instruments tail call function exits by inserting a nop sled before\nthe tail call. When tracing is enabled, the nop sled is replaced with a\ncall to `__xray_FunctionTailExit()`. This currently does not work for\nconditional tail calls, as the instrumentation assumes that the tail\ncall will be unconditional. This causes two issues:\n - `__xray_FunctionTailExit()` is inappropately called even when the\n   tail call is not taken.\n - `__xray_FunctionTailExit()`'s prologue/epilogue adjusts the stack\n   pointer with add/sub instructions. This clobbers condition flags,\n   which can flip the condition used for the tail call, leading to\n   incorrect program behavior.\n\nFix this by rewriting conditional calls when lowering patchable tail\ncalls.\n\nWith this change, a conditional patchable tail call like:\n```\n  je target\n```\n\nWill be lowered to:\n```\n  jne .fallthrough\n  .p2align 1, ..\n.Lxray_sled_N:\n  SLED_CODE\n  jmp target\n.fallthrough:\n```","shortMessageHtmlLink":"[xray] Handle conditional calls when lowering patchable tail calls."}},{"before":"64111efcdced53246013c5d3343cd3aadedc08db","after":"7d4be9f554fc6ddf6ff972d2db016915adc2cd86","ref":"refs/heads/xray_conditional_tail_call","pushedAt":"2024-04-20T00:48:27.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"rickyz","name":"Ricky Zhou","path":"/rickyz","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/616784?s=80&v=4"},"commit":{"message":"[xray] Handle conditional calls when lowering patchable tail calls.\n\nxray instruments tail call function exits by inserting a nop sled before\nthe tail call. When tracing is enabled, the nop sled is replaced with a\ncall to `__xray_FunctionTailExit()`. This currently does not work for\nconditional tail calls, as the instrumentation assumes that the tail\ncall will be unconditional. This causes two issues:\n - `__xray_FunctionTailExit()` is inappropately called even when the\n   tail call is not taken.\n - `__xray_FunctionTailExit()`'s prologue/epilogue adjusts the stack\n   pointer with add/sub instructions. This clobbers condition flags,\n   which can flip the condition used for the tail call, leading to\n   incorrect program behavior.\n\nFix this by rewriting conditional calls when lowering patchable tail\ncalls.\n\nWith this change, a conditional patchable tail call like:\n```\n  je target\n```\n\nWill be lowered to:\n```\n  jne .fallthrough\n  .p2align 1, ..\n.Lxray_sled_N:\n  SLED_CODE\n  jmp target\n.fallthrough:\n```","shortMessageHtmlLink":"[xray] Handle conditional calls when lowering patchable tail calls."}},{"before":"0e2970b1c4ad8287656860e692133fc3c1227c75","after":"64111efcdced53246013c5d3343cd3aadedc08db","ref":"refs/heads/xray_conditional_tail_call","pushedAt":"2024-04-20T00:14:49.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"rickyz","name":"Ricky Zhou","path":"/rickyz","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/616784?s=80&v=4"},"commit":{"message":"[xray] Handle conditional calls when lowering patchable tail calls.\n\nxray instruments tail call function exits by inserting a nop sled before\nthe tail call. When tracing is enabled, the nop sled is replaced with a\ncall to `__xray_FunctionTailExit()`. This currently does not work for\nconditional tail calls, as the instrumentation assumes that the tail\ncall will be unconditional. This causes two issues:\n - `__xray_FunctionTailExit()` is inappropately called even when the\n   tail call is not taken.\n - `__xray_FunctionTailExit()`'s prologue/epilogue adjusts the stack\n   pointer with add/sub instructions. This clobbers condition flags,\n   which can flip the condition used for the tail call, leading to\n   incorrect program behavior.\n\nFix this by rewriting conditional tail calls, when lowering patchable\ntail calls.\n\nWith this change, a conditional tail call like:\n```\n  je target\n```\n\nWill be lowered to:\n```\n  jne .fallthrough\n  .p2align 1, ..\n.Lxray_sled_N:\n  SLED_CODE\n  jmp target\n.fallthrough:\n```","shortMessageHtmlLink":"[xray] Handle conditional calls when lowering patchable tail calls."}},{"before":"1085c6db583b24fe733d316468bd5f1c2819e84c","after":"871902f0735839179d76638ce5c4a53e3fd462c0","ref":"refs/heads/xray_preserve_flags","pushedAt":"2024-04-19T20:41:24.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"rickyz","name":"Ricky Zhou","path":"/rickyz","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/616784?s=80&v=4"},"commit":{"message":"[xray] Preserve flags in x86_64 trampolines.\n\nPreviously, some xray trampolines would modify condition codes (before\nsaving/after restoring flags) due to stack alignment instructions, which\nuse add/sub.\n\nI am not aware of issues that this causes in practice (outside of the\nsituation described in https://github.com/llvm/llvm-project/pull/89364,\nwhich is only problematic due to a different bug). Nevertheless, it\nseems nicer and less error-prone for xray instrumentation to be as\nunobstrusive/preserve as much state as possible.","shortMessageHtmlLink":"[xray] Preserve flags in x86_64 trampolines."}},{"before":null,"after":"1085c6db583b24fe733d316468bd5f1c2819e84c","ref":"refs/heads/xray_preserve_flags","pushedAt":"2024-04-19T20:39:07.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"rickyz","name":"Ricky Zhou","path":"/rickyz","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/616784?s=80&v=4"}},{"before":"59e62e144256b920893dd5e31b372c8500b9b20e","after":"abb580e748d9e31f794a993e9bb6323002d04cfd","ref":"refs/heads/xray_leaf_stack_alignment","pushedAt":"2024-04-19T12:34:21.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"rickyz","name":"Ricky Zhou","path":"/rickyz","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/616784?s=80&v=4"},"commit":{"message":"[xray] Fix stack alignment for custom event calls.\n\nCalls to @llvm.xray.{custom,typed}event are lowered to an nop sled that\ncan be patched with a call to an instrumentation function at runtime.\nPrior to this change, x86 codegen did not guarantee that these patched\ncalls run with the appropriate stack alignment (particularly in leaf\nfunctions, where normal stack alignment assumptions may not hold).\n\nThis leads to crashes on x86, as the custom event hook can end up using\nSSE instructions that assume a 16-byte aligned stack.\n\nFix this by wrapping custom event hooks in CALLSEQ_START/CALLSEQ_END as\ndone for regular function calls. One downside of this approach is that\non functions whose stacks aren't already aligned, we may end up running\nstack alignment fixup instructions even when instrumentation is\ndisabled. An alternative could be to make the custom event assembly\ntrampolines stack-alignment-agnostic. This was the case in the past, but\nhttps://github.com/llvm/llvm-project/commit/b46c89892fe25bec197fd30f09b3a312da126422\nremoved this due to complexity in maintaining CFI directives for these\nstack adjustments. Since we are already willing to pay the call argument\nsetup cost for custom hooks when instrumentation is disabled, I am\nhoping that an extra push/pop in this hopefully uncommon unaligned stack\ncase is tolerable.","shortMessageHtmlLink":"[xray] Fix stack alignment for custom event calls."}},{"before":"7a27488d4d1c045f896d053821781dcd781683a1","after":"59e62e144256b920893dd5e31b372c8500b9b20e","ref":"refs/heads/xray_leaf_stack_alignment","pushedAt":"2024-04-19T12:33:26.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"rickyz","name":"Ricky Zhou","path":"/rickyz","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/616784?s=80&v=4"}},{"before":"884f9d3085388b58fc61c1cf4736051cee37ffda","after":"7a27488d4d1c045f896d053821781dcd781683a1","ref":"refs/heads/xray_leaf_stack_alignment","pushedAt":"2024-04-19T10:33:20.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"rickyz","name":"Ricky Zhou","path":"/rickyz","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/616784?s=80&v=4"},"commit":{"message":"[xray] Fix stack alignment for custom event calls.\n\nCalls to @llvm.xray.{custom,typed}event are lowered to an nop sled that\ncan be patched with a call to an instrumentation function at runtime.\nPrior to this change, x86 codegen did not guarantee that these patched\ncalls run with the appropriate stack alignment (particularly in leaf\nfunctions, where normal stack alignment assumptions may not hold).\n\nThis leads to crashes on x86, as the custom event hook can end up using\nSSE instructions that assume a 16-byte aligned stack.\n\nFix this by wrapping custom event hooks in CALLSEQ_START/CALLSEQ_END as\ndone for regular function calls. One downside of this approach is that\non functions whose stacks aren't already aligned, we may end up running\nstack alignment fixup instructions even when instrumentation is\ndisabled. An alternative could be to make the custom event assembly\ntrampolines stack-alignment-agnostic. This was the case in the past, but\nhttps://github.com/llvm/llvm-project/commit/b46c89892fe25bec197fd30f09b3a312da126422\nremoved this due to complexity in maintaining CFI directives for these\nstack adjustments. Since we are already willing to pay the call argument\nsetup cost for custom hooks when instrumentation is disabled, I am\nhoping that an extra push/pop in this hopefully uncommon unaligned stack\ncase is tolerable.","shortMessageHtmlLink":"[xray] Fix stack alignment for custom event calls."}},{"before":"6586fcfd80a37387afbbcef86cffad30af249ae1","after":"0e2970b1c4ad8287656860e692133fc3c1227c75","ref":"refs/heads/xray_conditional_tail_call","pushedAt":"2024-04-19T10:32:55.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"rickyz","name":"Ricky Zhou","path":"/rickyz","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/616784?s=80&v=4"},"commit":{"message":"[xray] Do not emit tail exit hooks for conditional tail calls\n\nxray instruments tail call function exits by inserting a nop sled before\nthe tail call. When tracing is enabled, the nop sled is replaced with a\ncall to `__xray_FunctionTailExit()`. This currently does not work for\nconditional tail calls, as the instrumentation assumes that the tail\ncall will be unconditional. This causes two issues:\n - `__xray_FunctionTailExit()` is inappropately called even when the\n   tail call is not taken.\n - `__xray_FunctionTailExit()`'s prologue/epilogue adjusts the stack\n   pointer with add/sub instructions. This clobbers condition flags,\n   which can flip the condition used for the tail call, leading to\n   incorrect program behavior.\n\nAvoid this misbehavior by disabling instrumentation of conditional tail\ncalls. A more comprehensive fix could be to either rewrite conditional\ntail calls to non-conditional ones, or to create specialized function\ntail exit instrumentation functions for each of the possible types of\nconditional tail calls.","shortMessageHtmlLink":"[xray] Do not emit tail exit hooks for conditional tail calls"}},{"before":null,"after":"6586fcfd80a37387afbbcef86cffad30af249ae1","ref":"refs/heads/xray_conditional_tail_call","pushedAt":"2024-04-19T10:05:12.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"rickyz","name":"Ricky Zhou","path":"/rickyz","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/616784?s=80&v=4"},"commit":{"message":"xray: Do not emit tail exit hooks for conditional tail calls\n\nxray instruments tail call function exits by inserting a nop sled before\nthe tail call. When tracing is enabled, the nop sled is replaced with a\ncall to `__xray_FunctionTailExit()`. This currently does not work for\nconditional tail calls, as the instrumentation assumes that the tail\ncall will be unconditional. This causes two issues:\n - `__xray_FunctionTailExit()` is inappropately called even when the\n   tail call is not taken.\n - `__xray_FunctionTailExit()`'s prologue/epilogue adjusts the stack\n   pointer with add/sub instructions. This clobbers condition flags,\n   which can flip the condition used for the tail call, leading to\n   incorrect program behavior.\n\nAvoid this misbehavior by disabling instrumentation of conditional tail\ncalls. A more comprehensive fix could be to either rewrite conditional\ntail calls to non-conditional ones, or to create specialized function\ntail exit instrumentation functions for each of the possible types of\nconditional tail calls.","shortMessageHtmlLink":"xray: Do not emit tail exit hooks for conditional tail calls"}},{"before":null,"after":"884f9d3085388b58fc61c1cf4736051cee37ffda","ref":"refs/heads/xray_leaf_stack_alignment","pushedAt":"2024-04-19T09:41:42.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"rickyz","name":"Ricky Zhou","path":"/rickyz","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/616784?s=80&v=4"},"commit":{"message":"xray: Fix stack alignment for custom event calls.\n\nCalls to @llvm.xray.{custom,typed}event are lowered to an nop sled that\ncan be patched with a call to an instrumentation function at runtime.\nPrior to this change, x86 codegen did not guarantee that these patched\ncalls run with the appropriate stack alignment (particularly in leaf\nfunctions, where normal stack alignment assumptions may not hold).\n\nThis leads to crashes on x86, as the custom event hook can end up using\nSSE instructions that assume a 16-byte aligned stack.\n\nFix this by wrapping custom event hooks in CALLSEQ_START/CALLSEQ_END as\ndone for regular function calls. One downside of this approach is that\non functions whose stacks aren't already aligned, we may end up running\nstack alignment fixup instructions even when instrumentation is\ndisabled. An alternative could be to make the custom event assembly\ntrampolines stack-alignment-agnostic. This was the case in the past, but\nhttps://github.com/llvm/llvm-project/commit/b46c89892fe25bec197fd30f09b3a312da126422\nremoved this due to complexity in maintaining CFI directives for these\nstack adjustments. Since we are already willing to pay the call argument\nsetup cost for custom hooks when instrumentation is disabled, I am\nhoping that an extra push/pop in this hopefully uncommon unaligned stack\ncase is tolerable.","shortMessageHtmlLink":"xray: Fix stack alignment for custom event calls."}},{"before":"58564ddf5c338edb4dee4d36db83be0136f84935","after":"e2a72fa583d9ccec7e996e15ea86f0ceddbfe63c","ref":"refs/heads/main","pushedAt":"2024-04-19T08:51:02.000Z","pushType":"push","commitsCount":9708,"pusher":{"login":"rickyz","name":"Ricky Zhou","path":"/rickyz","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/616784?s=80&v=4"},"commit":{"message":"[VPlan] Introduce recipes for VP loads and stores. (#87816)\n\nIntroduce new subclasses of VPWidenMemoryRecipe for VP\r\n(vector-predicated) loads and stores to address multiple TODOs from\r\nhttps://github.com/llvm/llvm-project/pull/76172\r\n\r\nNote that the introduction of the new recipes also improves code-gen for\r\nVP gather/scatters by removing the redundant header mask. With the new\r\napproach, it is not sufficient to look at users of the widened canonical\r\nIV to find all uses of the header mask.\r\n\r\nIn some cases, a widened IV is used instead of separately widening the\r\ncanonical IV. To handle that, first collect all VPValues representing header\r\nmasks (by looking at users of both the canonical IV and widened inductions\r\nthat are canonical) and then checking all users (recursively) of those header\r\nmasks.\r\n\r\nDepends on https://github.com/llvm/llvm-project/pull/87411.\r\n\r\nPR: https://github.com/llvm/llvm-project/pull/87816","shortMessageHtmlLink":"[VPlan] Introduce recipes for VP loads and stores. (<a class=\"issue-link js-issue-link\" data-error-text=\"Failed to load title\" data-id=\"2228613676\" data-permission-text=\"Title is private\" data-url=\"https://github.com/llvm/llvm-project/issues/87816\" data-hovercard-type=\"pull_request\" data-hovercard-url=\"/llvm/llvm-project/pull/87816/hovercard\" href=\"https://github.com/llvm/llvm-project/pull/87816\">llvm#87816</a>)"}},{"before":null,"after":"77a7691817278a96d7d94bcc05a5dcf24959f98a","ref":"refs/heads/thinlto_import_anon_type_debuginfo","pushedAt":"2024-01-17T16:14:00.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"rickyz","name":"Ricky Zhou","path":"/rickyz","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/616784?s=80&v=4"},"commit":{"message":"[ThinLTO][DebugInfo] Emit full type definitions when importing anonymous types.\n\nThis fixes some cases of missing debuginfo caused by an interaction between:\n\nhttps://github.com/llvm/llvm-project/commit/f0d66559ea345db4b2116cae044aaf3399d7e829,\nwhich drops the identifier from a DICompositeType in the module containing its\nvtable.\n\nand\n\nhttps://github.com/llvm/llvm-project/commit/a61f5e379675732666744bcba25efbc9922e016a,\nwhich causes ThinLTO to import composite types as declarations when they have\nan identifier.\n\nIf a virtual class's DICompositeType has no identifier due to the first change,\nand contains a nested anonymous type which does have an identifier, then the\nsecond change can cause ThinLTO to output the classes's DICompositeType as a\ntype definition that links to a non-defining declaration for the nested type.\nSince the nested anonyous type does not have a name, debuggers are unable to\nfind the definition for the declaration.\n\nRepro case:\n\ncat > a.h <<EOF\nclass A {\n public:\n  A();\n  virtual ~A();\n\n private:\n  union {\n    int val;\n  };\n};\nEOF\n\ncat > a.cc <<EOF\n\nA::A() { asm(\"\"); }\n\nA::~A() {}\nEOF\n\ncat > main.cc <<EOF\n\nint main(int argc, char **argv) {\n  A a;\n  return 0;\n}\nEOF\n\nclang++ -O2 -g -flto=thin -mllvm -force-import-all main.cc a.cc\ngdb ./a.out -batch -ex 'pt /rmt A'\nThe gdb command outputs:\n\ntype = class A {\n  private:\n    union {\n        <incomplete type>\n    };\n}\n\nand dwarfdump -i a.out shows a DW_TAG_class_type for A with an incomplete union\ntype (note that there is also a duplicate entry with the full union type that\ncomes after).\n\n< 1><0x0000001e>    DW_TAG_class_type\n                      DW_AT_containing_type       <0x0000001e>\n                      DW_AT_calling_convention    DW_CC_pass_by_reference\n                      DW_AT_name                  (indexed string: 0x00000007)A\n                      DW_AT_byte_size             0x00000010\n                      DW_AT_decl_file             0x00000001 /path/to/./a.h\n                      DW_AT_decl_line             0x00000001\n...\n< 2><0x0000002f>      DW_TAG_member\n                        DW_AT_type                  <0x00000037>\n                        DW_AT_decl_file             0x00000001 /path/to/./a.h\n                        DW_AT_decl_line             0x00000007\n                        DW_AT_data_member_location  8\n< 2><0x00000037>      DW_TAG_union_type\n                        DW_AT_export_symbols        yes(1)\n                        DW_AT_calling_convention    DW_CC_pass_by_value\n                        DW_AT_declaration           yes(1)\n\nThis change works around this by making ThinLTO always import full definitions\nfor anonymous types.","shortMessageHtmlLink":"[ThinLTO][DebugInfo] Emit full type definitions when importing anonym…"}}],"hasNextPage":false,"hasPreviousPage":false,"activityType":"all","actor":null,"timePeriod":"all","sort":"DESC","perPage":30,"cursor":"djE6ks8AAAAEVWxDzAA","startCursor":null,"endCursor":null}},"title":"Activity · rickyz/llvm-project"}