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

[Mikhail Ramalho via cfe-dev]

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

> 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.
>
>
Yeah, we are trying to force the type whenever we can but it ends up
introducing inconsistencies in the AST :/


> 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/c09d31fc/attachment.html>