[LLVMbugs] [Bug 23722] New: clang gives compiler where gcc does not when dealing with extern "C" function declarations
bugzilla-daemon at llvm.org
bugzilla-daemon at llvm.org
Mon Jun 1 18:06:18 PDT 2015
https://llvm.org/bugs/show_bug.cgi?id=23722
Bug ID: 23722
Summary: clang gives compiler where gcc does not when dealing
with extern "C" function declarations
Product: clang
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: C++
Assignee: unassignedclangbugs at nondot.org
Reporter: eldlistmailingz at tropicsoft.com
CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
Classification: Unclassified
I regularly test clang on Windows targeting mingw/gcc-4.8.1 against Boost
libraries. Clang is failing compilation where gcc-4.8.1 succeeds when it comes
to extern "C" declarations in Boost's internal winapi library and in the
mingw/w32api package. The code which illustrates this bug is:
#include <boost/detail/winapi/time.hpp>
#include <windows.h>
int main()
{
boost::detail::winapi::FILETIME_ ft;
boost::detail::winapi::GetSystemTimeAsFileTime(&ft);
return 0;
}
Compiled with gcc-4.8.1 using Boost bjam with command line parameters of:
-ftemplate-depth-128 -O0 -fno-inline -Wall -pedantic -g -march=i686 -m32
we get no errors and a successful compilation.
Compiled with the latest clang built from source with command line parameters
of:
-c -x c++ -O0 -g -fno-inline -Wall -g -march=i686 -m32
we get errors of:
"In file included from test_winapi.cpp:2:
In file included from /mingw/include\windows.h:62:
/mingw/include\winbase.h:1217:24: error: conflicting types for
'FileTimeToLocalFileTime'
WINBASEAPI BOOL WINAPI FileTimeToLocalFileTime(CONST FILETIME *,LPFILETIME);
^
..\..\..\boost/detail/winapi/time.hpp:73:9: note: previous declaration is here
FileTimeToLocalFileTime(const FILETIME_* lpFileTime,
^
In file included from test_winapi.cpp:2:
In file included from /mingw/include\windows.h:62:
/mingw/include\winbase.h:1394:24: error: conflicting types for 'GetSystemTime'
WINBASEAPI VOID WINAPI GetSystemTime(LPSYSTEMTIME);
^
..\..\..\boost/detail/winapi/time.hpp:76:9: note: previous declaration is here
GetSystemTime(SYSTEMTIME_* lpSystemTime);
^
In file included from test_winapi.cpp:2:
In file included from /mingw/include\windows.h:62:
/mingw/include\winbase.h:1397:24: error: conflicting types for
'GetSystemTimeAsFileTime'
WINBASEAPI void WINAPI GetSystemTimeAsFileTime(LPFILETIME);
^
..\..\..\boost/detail/winapi/time.hpp:70:9: note: previous declaration is here
GetSystemTimeAsFileTime(FILETIME_* lpFileTime);
^
In file included from test_winapi.cpp:2:
In file included from /mingw/include\windows.h:62:
/mingw/include\winbase.h:1754:24: error: conflicting types for
'SystemTimeToFileTime'
WINBASEAPI BOOL WINAPI SystemTimeToFileTime(const SYSTEMTIME*,LPFILETIME);
^
..\..\..\boost/detail/winapi/time.hpp:78:9: note: previous declaration is here
SystemTimeToFileTime(const SYSTEMTIME_* lpSystemTime,
^"
Notice that the program itself is only invoking the GetSystemTimeAsFileTime
function, but clang is saying that all "mismatched" declarations indicate
errors.
If we take a look at GetSystemTimeAsFileTime in the mingw headers we see within
an extern "C" block:
typedef struct _FILETIME {
DWORD dwLowDateTime;
DWORD dwHighDateTime;
} FILETIME,*PFILETIME,*LPFILETIME;
WINBASEAPI void WINAPI GetSystemTimeAsFileTime(LPFILETIME);
and when we preprocess this function call we see:
void __attribute__((__stdcall__)) GetSystemTimeAsFileTime(LPFILETIME);
If we take a look at GetSystemTimeAsFileTime in the Boost headers we see within
an extern "C" block:
typedef struct _FILETIME {
DWORD_ dwLowDateTime;
DWORD_ dwHighDateTime;
} FILETIME_, *PFILETIME_, *LPFILETIME_;
__declspec(dllimport) void WINAPI
GetSystemTimeAsFileTime(FILETIME_* lpFileTime);
and when we preprocess this function call we see:
__attribute__((dllimport)) void __attribute__((__stdcall__))
GetSystemTimeAsFileTime(FILETIME_* lpFileTime);
Clang appears to be saying that the since the declarations of the
GetSystemTimeAsFileTime don't match exactly because one of them has the
__attribute__((dllimport)) while the other does not, it is an error. For gcc,
which sees exactly the same preprocessed code, it is not an error.
I don't know, based on the C++ standard, whether it is an error or not but if
it is I would like it explained according to the C++ standard why it is.
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20150602/f200f56a/attachment.html>
More information about the llvm-bugs
mailing list