_cdecl not recognized correctly on windows

[rubenvb]

Bugzilla Link	10997
Resolution	WONTFIX
Resolved on	Oct 17, 2011 08:58
Version	trunk
OS	Windows NT
CC	@efriedma-quic

Extended Description

Compiling the mingw-w64 CRT with clang, I ran into this error:
m:/Development/Source/mingw-w64/stable/v2.x/mingw-w64-crt/misc/isblank.c:4:11: error: expected ';' after top level declarator
int _cdecl isblank (int _C)
^
;
1 error generated.

This does not happen for x86. The above code can serve as a standalone testcase.

[rubenvb]

My ap

[rubenvb]

My apologies, this is equally an error on 32-bit.

[efriedma-quic]

Hmm... we should be able to parse that as long as -fms-extensions is on; maybe the driver is messing up?

[rubenvb]

Hmm... we should be able to parse that as long as -fms-extensions is on; maybe
the driver is messing up?

The mingw-w64 CRT is not compiled with this flag, gcc does not require it.

Enabling it, makes the error go away. I would say that in sake of keeping compatibility with MinGW(-w64)/GCC, _cdecl should also be recognized without -fms-extensions.

Thanks!

[llvmbot]

Ruben, please make sure if _cdecl would be defined as macro with gcc.
IIRC, mingw32-gcc does not provide such reserved keywords.

I guess, on this issue, a few predefines might be lacking for mingw build tree.

Or, we may add predefined _cdecl as macro, not as keyword.

[llvmbot]

With gcc-4.4.0 (gcc.exe (TDM-1 mingw32) 4.4.0), I have checked as below;

$ echo '_cdecl void foo();' | gcc -E -std=c99 -

GCC always has the definition of "__cdecl" (two underscores).

attribute((cdecl)) void foo();

With -std=c99 (and w/o gnu extension), "_cdecl" (one underscore) is not defined.

_cdecl void foo();

and cc1 does not allow _cdecl.

:1: error: expected '=', ',', ';', 'asm' or 'attribute' before 'void'

We may define __cdecl and _cdecl things as predefinitions on cygming.

ps. yeah, it might be possible to enable __declspec and __cdecl (as token) on cygming, not only msvc.

[rubenvb]

patch to remedy the problem
Attached patch moves the _cdecl ALIAS outside MS extension mode. This behavior is compatible with GCC (ie GCC also allows this without any extra compilers flags).

I tested this on the mingw-w64 CRT (which uses "_cdecl") and my patch resolves the problem.

[efriedma-quic]

The attached patch isn't acceptable; it breaks code in -std=c99 mode that uses _cdecl as an identifier. If I'm understanding correctly, the issue is that _cdecl needs to be keyword in -std=gnu99 mode without -fms-extensions on mingw? We can add a KEYMINGW marking for keywords if we really need it...

[rubenvb]

The attached patch isn't acceptable; it breaks code in -std=c99 mode that uses
_cdecl as an identifier. If I'm understanding correctly, the issue is that
_cdecl needs to be keyword in -std=gnu99 mode without -fms-extensions on mingw?
We can add a KEYMINGW marking for keywords if we really need it...

I understand your objections. In fact, having looked through the TokenKinds.def file, I have a probably equally unacceptable suggestion, but hear me out... (maybe better suited on the mailing list...)

In light of existing code compatibility with MSVC and MinGW code, it would greatly help reduce Clang problems in platform-specific keywords and extensions if it would enable most of what is currently hidden under -fms-extensions by default on --mingw32 and --win32, at least for those keywords and features that make sense for both MinGW and MSVC, leading to a perhaps better suited "KEYWINDOWS" marking, leaving the currently MinGW incompatible (if any) extensions under the current KEYMS and KEYBORLAND markings. It would be harmful to further split MinGW and MSVC, especially if Clang can bridge the gap of missing compiler features in GCC that MinGW cannot work around there.

Yes, this will put strain on full C99 compatibility, but as the platform crudely places extra keywords in non-implementation namespace, it's a choice of compatibility.

[rubenvb]

Never mmind my kind of nonsensical discussion. I submitted a patch to mingw-w64 to change _cdecl to __cdecl, which is equivalent and purely C99 compatible. I will close this as soon as the patch there lands.

[rubenvb]

The MinGW-w64 source is patched, this is a non-issue.