Skip to content

Conversation

alexrp
Copy link
Member

@alexrp alexrp commented Oct 20, 2025

With this, we have target info for all architectures currently supported by Linux (except nios2, but that's at death's door anyway).

@alexrp
Copy link
Member Author

alexrp commented Oct 20, 2025

@mlugg FYI ef5f413, e6ac67d :^)

You may also be delighted to know that PA-RISC has its own homegrown unwind info format like Arm.

@alexrp alexrp force-pushed the std-target-more-arches branch from ad038b3 to fa70110 Compare October 20, 2025 02:36
else => VaListPowerPc,
},
.s390x => VaListS390x,
.sh, .sheb => VaListSh, // TODO: This is wrong for `sh_renesas`.
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mlugg thoughts on this? GCC makes the definition of the type dependent on the enclosing function's calling convention, which seems clearly sensible to me. The idea that there is a single global VaList type is just kinda fundamentally flawed in a world where we support multiple calling conventions for one target.

I figure we could remove std.builtin.VaList and instead make Sema pick one of the more specific decls based on calling convention. It seems like moving that logic into the compiler will also let us get rid of a lot of special-casing we do around the resolution of VaList.

@alexrp alexrp force-pushed the std-target-more-arches branch from fa70110 to 09b53f7 Compare October 20, 2025 10:55
@alexrp alexrp force-pushed the std-target-more-arches branch from 09b53f7 to c1100d1 Compare October 20, 2025 19:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant