[cfe-dev] Force __builtin_va_list to be a char* in any architecture?

[Reid Kleckner via cfe-dev]

I apologize if this seems rude, but my initial reaction is that you should
not rely on invariants that do not hold true in practice. :) In any case,
you are already clearly aware that this assumption creates portability
problems, and I don't seek to assign blame.

I don't believe we have such an option, and I don't think we would be open
to adding one, since generally we try to discourage the proliferation of
alternative ABI variants.

On Thu, Dec 12, 2019 at 9:14 AM Mikhail Ramalho via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> Hi all,
>
> Is there any way to force __builtin_va_list to always be a char*,
> regardless of the architecture?
>
> We are using clang as a frontend in our project and our analysis relies on
> the fact that __builtin_va_list is a char* on 64 bits architecture as well,
> but we keep getting:
>
> |-TypedefDecl 0x4148c78 <<invalid sloc>> <invalid sloc> implicit
> referenced __builtin_va_list 'struct __va_list_tag [1]'
> | `-ConstantArrayType 0x4148c20 'struct __va_list_tag [1]' 1
> |   `-RecordType 0x4148aa0 'struct __va_list_tag'
> |     `-Record 0x4148a10 '__va_list_tag'
>
> I've tried several different combinations of defines but to no avail.
>
> In case it is not possible, we could submit a patch to add an option to
> force that on clang. A bit of an overkill given that we would be the only
> users (I think).
>
> Best,
>
> --
>
> Mikhail Ramalho.
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20191212/ec8ec01e/attachment.html>