[PATCH] D45383: Strip reference from a va_list object in C when merging parameter types.
Erich Keane via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Mon Apr 9 09:10:50 PDT 2018
erichkeane added a comment.
In https://reviews.llvm.org/D45383#1061797, @efriedma wrote:
> > vprintf is handled using the exact same code-paths. SO, it'll have its 2nd parameter created with type 'char*&'
>
> vprintf is defined in the C standard as "int vprintf(const char *format, va_list arg);"; on Windows, that's equivalent to "int vprintf(const char *format, char* arg);". If a reference is showing up anywhere, something has gone seriously wrong before we get anywhere near the type merging code.
Hrm... looking back again, I believe you're right. I did a more careful grepping and found that only 4 builtins and 3 C99 library functions have this issue. Basically, anything with a 'A' in the parameter spec in Builtins.def. I don't know how I got attached to vprintf, I apologize for the wasted time.
The functions with this problem are:
__builtins_va_start, __builtins_va_end, __builtins_va_copy, and __builtin_stdarg_start.
va_start, va_end, va_copy.
I don't see redeclaring the latter 3 as being disallowed, so I presume that we'd not be able to prevent that. I'm really open to suggestions, as thinking over the weekend has convinced me that this patch is a little bit hacky. I'd like some solution for the assertion, but I'm not sure I see one. I note that godbolt (https://godbolt.org/g/qkryPR) doesn't show the assert as it is a non-assert build. Would we be OK with simply relaxing the '!isreferencetype' assert to something like, "!isReferenceType || isVaListTypeRef"?
Repository:
rC Clang
https://reviews.llvm.org/D45383
More information about the cfe-commits
mailing list