[patch] Delay __fastcall attribute checking utnil after merging declarations
Nico Weber
thakis at chromium.org
Tue Aug 19 11:07:47 PDT 2014
On Tue, Aug 19, 2014 at 10:40 AM, Nico Weber <thakis at chromium.org> wrote:
> (adding back cfe-commits, which I had accidentally dropped.)
>
> On Thu, Jul 31, 2014 at 1:04 PM, Reid Kleckner <rnk at google.com> wrote:
>
>> On Thu, Jul 31, 2014 at 11:16 AM, Nico Weber <thakis at chromium.org> wrote:
>>
>>> On Thu, Jul 31, 2014 at 9:45 AM, Nico Weber <thakis at chromium.org> wrote:
>>>
>>>> Thanks!
>>>>
>>>> On Tue, Jul 29, 2014 at 10:40 AM, Reid Kleckner <rnk at google.com> wrote:
>>>>
>>>>> + // Diagnose the use of X86 fastcall on unprototyped functions.
>>>>>
>>>>> We should also diagnose unprototyped stdcall functions, but I'm not
>>>>> sure if that would be too disruptive. Currently we accept this and always
>>>>> call _f at 0:
>>>>> void __stdcall f();
>>>>> int main() {
>>>>> f(1);
>>>>> f(1, 2);
>>>>> f(1, 2, 3);
>>>>> }
>>>>>
>>>>> MSVC rejects with "t.c(5) : error C2708: 'f' : actual parameters
>>>>> length in bytes differs from previous call or reference".
>>>>>
>>>>
>>>> I added a TODO for adding this and reshuffled the if to make this easy
>>>> to add. I'll give it a try once this patch is in.
>>>>
>>>
>>>
>> Actually, should this happen for all isCalleeCleanup() calling
>>> conventions? I suppose thiscall always has a prototype, but pascal(l :-P)
>>> might not?
>>>
>>
>> That sounds like the right predicate, considering we verifier-fail on
>> this in plain C mode:
>> void __thiscall f();
>> int main() { f(1); }
>>
>> MSVC rejects __thiscall in C mode, but we don't.
>>
>
> I did give it a try, and rejecting stdcall fires on Windows SDK headers:
>
> ...win8sdk/Include/um\imm.h(432,13) : error(clang): function with no
> prototype cannot use stdcall calling convention
> BOOL WINAPI ImmDisableLegacyIME();
> ^
>
…but it looks like this is the only function that gets this wrong (at least
in a chromium build).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140819/e3899435/attachment.html>
More information about the cfe-commits
mailing list