[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:39:54 PST 2019
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.
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 '
>> | `-ConstantArrayType 0x4148c20 'struct __va_list_tag ' 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).
>> Mikhail Ramalho.
>> cfe-dev mailing list
>> cfe-dev at lists.llvm.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cfe-dev