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

Mikhail Ramalho via cfe-dev cfe-dev at lists.llvm.org
Thu Dec 12 10:31:31 PST 2019

We don't actually want to add an option to clang, I phrased that

We use libtooling to generate the program AST; clang is only the frontend
to our tool.

We have no intent to break the ABI, or to expose such flag to the command
line. If we indeed need a flag to achieve this, it would be an option when
creating the ASTContext.

Em qui., 12 de dez. de 2019 às 14:21, Reid Kleckner <rnk at google.com>

> 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


Mikhail Ramalho.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20191212/7a43983f/attachment.html>

More information about the cfe-dev mailing list