Hi,
I tried to build the latest Wine sources (the ones from git) with clang
on Mac OS X 10.6.1, and I'm encountering issues with inline functions.
Specifically, I get this message:
clang -m32 -c -I. -I. -I../../include -I../../include -D__WINESRC__
-D_REENTRANT -fPIC -Wall -pipe -Wpointer-arith -g -O2 -o interlocked.o
interlocked.c
/var/folders/Vv/Vvv1iGUYFBiWfsCkpG71-U+++TI/-Tmp-/cc-XxETkM.s:71:FATAL:Symbol
_interlocked_cmpxchg already defined.
clang: error: assembler command failed with exit code 1 (use -v to see
invocation)
Looking at the wine sources, I found out that interlocked_cmpxchg() is
defined "extern inline" in include/wine/port.h, and is redefined in
libs/port/interlocked.c. I suspect this is LLVM bug 2742, except that it
compiles fine with llvm-gcc.
Should I file a bug, or is this a known issue (like bug 2742)?
Thanks.
Chip
Does it compile with -std=gnu89? (clang defaults to gnu99 I think).
Best regards,
--Edwin
Török Edwin wrote:
Hi,
I tried to build the latest Wine sources (the ones from git) with clang
on Mac OS X 10.6.1, and I'm encountering issues with inline functions.
Specifically, I get this message:
clang -m32 -c -I. -I. -I../../include -I../../include -D__WINESRC__
-D_REENTRANT -fPIC -Wall -pipe -Wpointer-arith -g -O2 -o interlocked.o
interlocked.c
/var/folders/Vv/Vvv1iGUYFBiWfsCkpG71-U+++TI/-Tmp-/cc-XxETkM.s:71:FATAL:Symbol
_interlocked_cmpxchg already defined.
clang: error: assembler command failed with exit code 1 (use -v to see
invocation)
Looking at the wine sources, I found out that interlocked_cmpxchg() is
defined "extern inline" in include/wine/port.h, and is redefined in
libs/port/interlocked.c. I suspect this is LLVM bug 2742, except that it
compiles fine with llvm-gcc.
Does it compile with -std=gnu89? (clang defaults to gnu99 I think).
Best regards,
--Edwin
Sorry about not replying to all. (Need to get into the habit...)
Anyway, I got pretty far, but now I've encountered another "extern
inline" problem. clang complains about the redefinition of
GetProcessHeap() in dlls/kernel32/heap.c (where it was previously
defined in include/winbase.h). This is WITH -std=gnu89:
heap.c:254:15: error: redefinition of 'GetProcessHeap'
HANDLE WINAPI GetProcessHeap(void)
^
In file included from heap.c:59:
../../include/winbase.h:2533:29: note: previous definition is here
extern inline HANDLE WINAPI GetProcessHeap(void)
^
As I said earlier (in an email some of you may not have gotten, I got a
bunch of warning diagnostics about
__attribute__((__force_align_arg_pointer__)), which, according to a
comment in include/windef.h, is supposed to ensure the stack remains
16-byte aligned. Is this needed under clang for __stdcall functions on
Mac OS X? It's apparently needed under gcc.
Speaking of __stdcall, I got some diagnostics related to
__attribute__((__stdcall__)) being used on function pointers. gcc does
not complain about this. Is this a known issue?
Török Edwin wrote:
Hi,
I tried to build the latest Wine sources (the ones from git) with clang
on Mac OS X 10.6.1, and I'm encountering issues with inline functions.
Specifically, I get this message:
clang -m32 -c -I. -I. -I../../include -I../../include -D__WINESRC__
-D_REENTRANT -fPIC -Wall -pipe -Wpointer-arith -g -O2 -o interlocked.o
interlocked.c
/var/folders/Vv/Vvv1iGUYFBiWfsCkpG71-U+++TI/-Tmp-/cc-XxETkM.s:71:FATAL:Symbol
_interlocked_cmpxchg already defined.
clang: error: assembler command failed with exit code 1 (use -v to see
invocation)
Looking at the wine sources, I found out that interlocked_cmpxchg() is
defined "extern inline" in include/wine/port.h, and is redefined in
libs/port/interlocked.c. I suspect this is LLVM bug 2742, except that it
compiles fine with llvm-gcc.
Does it compile with -std=gnu89? (clang defaults to gnu99 I think).
Best regards,
--Edwin
Sorry about not replying to all. (Need to get into the habit...)
Anyway, I got pretty far, but now I've encountered another "extern
inline" problem. clang complains about the redefinition of
GetProcessHeap() in dlls/kernel32/heap.c (where it was previously
defined in include/winbase.h). This is WITH -std=gnu89:
heap.c:254:15: error: redefinition of 'GetProcessHeap'
HANDLE WINAPI GetProcessHeap(void)
^
In file included from heap.c:59:
../../include/winbase.h:2533:29: note: previous definition is here
extern inline HANDLE WINAPI GetProcessHeap(void)
^
Clang does not implement this feature yet. I've filed a bug report about it here:
[GNU Extension] Redefinition of "extern inline" function · Issue #5625 · llvm/llvm-project · GitHub
As I said earlier (in an email some of you may not have gotten, I got a
bunch of warning diagnostics about
__attribute__((__force_align_arg_pointer__)), which, according to a
comment in include/windef.h, is supposed to ensure the stack remains
16-byte aligned. Is this needed under clang for __stdcall functions on
Mac OS X? It's apparently needed under gcc.
We don't have support for this attribute in Clang, and I don't know whether it is necessary for what you're doing. Please file an extension request at
http://llvm.org/bugs/
Speaking of __stdcall, I got some diagnostics related to
__attribute__((__stdcall__)) being used on function pointers. gcc does
not complain about this. Is this a known issue?
Not one I know about. What diagnostics on what code?
- Doug
Douglas Gregor wrote:
Török Edwin wrote:
Hi,
I tried to build the latest Wine sources (the ones from git) with clang
on Mac OS X 10.6.1, and I'm encountering issues with inline functions.
Specifically, I get this message:
clang -m32 -c -I. -I. -I../../include -I../../include -D__WINESRC__
-D_REENTRANT -fPIC -Wall -pipe -Wpointer-arith -g -O2 -o
interlocked.o
interlocked.c
/var/folders/Vv/Vvv1iGUYFBiWfsCkpG71-U+++TI/-Tmp-/cc-XxETkM.s:71:FATAL:Symbol
_interlocked_cmpxchg already defined.
clang: error: assembler command failed with exit code 1 (use -v to see
invocation)
Looking at the wine sources, I found out that interlocked_cmpxchg() is
defined "extern inline" in include/wine/port.h, and is redefined in
libs/port/interlocked.c. I suspect this is LLVM bug 2742, except
that it
compiles fine with llvm-gcc.
Does it compile with -std=gnu89? (clang defaults to gnu99 I think).
Best regards,
--Edwin
Sorry about not replying to all. (Need to get into the habit...)
Anyway, I got pretty far, but now I've encountered another "extern
inline" problem. clang complains about the redefinition of
GetProcessHeap() in dlls/kernel32/heap.c (where it was previously
defined in include/winbase.h). This is WITH -std=gnu89:
heap.c:254:15: error: redefinition of 'GetProcessHeap'
HANDLE WINAPI GetProcessHeap(void)
^
In file included from heap.c:59:
../../include/winbase.h:2533:29: note: previous definition is here
extern inline HANDLE WINAPI GetProcessHeap(void)
^
Clang does not implement this feature yet. I've filed a bug report about
it here:
[GNU Extension] Redefinition of "extern inline" function · Issue #5625 · llvm/llvm-project · GitHub
OK.
As I said earlier (in an email some of you may not have gotten, I got a
bunch of warning diagnostics about
__attribute__((__force_align_arg_pointer__)), which, according to a
comment in include/windef.h, is supposed to ensure the stack remains
16-byte aligned. Is this needed under clang for __stdcall functions on
Mac OS X? It's apparently needed under gcc.
We don't have support for this attribute in Clang, and I don't know
whether it is necessary for what you're doing. Please file an extension
request at
http://llvm.org/bugs/
You don't? Well then, I guess, to be on the safe side, I should file a
request.
Speaking of __stdcall, I got some diagnostics related to
__attribute__((__stdcall__)) being used on function pointers. gcc does
not complain about this. Is this a known issue?
Not one I know about. What diagnostics on what code?
Basically, any code that defines a __stdcall function pointer typedef,
like this one for example:
../../include/winnt.h:5034:15: warning: '__stdcall__' attribute only
applies to
function types
typedef VOID (NTAPI * PFLS_CALLBACK_FUNCTION) ( PVOID );
^
../../include/winnt.h:44:15: note: instantiated from:
#define NTAPI __stdcall
^../../include/windef.h:57:38: note: instantiated from:
# define __stdcall __attribute__((__stdcall__))
__attribute__((__force_align_
arg_pointer__)) ^
- Doug
Thanks.
Chip
Douglas Gregor wrote:
As I said earlier (in an email some of you may not have gotten, I got a
bunch of warning diagnostics about
__attribute__((__force_align_arg_pointer__)), which, according to a
comment in include/windef.h, is supposed to ensure the stack remains
16-byte aligned. Is this needed under clang for __stdcall functions on
Mac OS X? It's apparently needed under gcc.
We don't have support for this attribute in Clang, and I don't know
whether it is necessary for what you're doing. Please file an extension
request at
http://llvm.org/bugs/
You don't? Well then, I guess, to be on the safe side, I should file a
request.
Thanks, I see it at 5254 – Clang should support __attribute__((__force_align_arg_pointer__))
Speaking of __stdcall, I got some diagnostics related to
__attribute__((__stdcall__)) being used on function pointers. gcc does
not complain about this. Is this a known issue?
Not one I know about. What diagnostics on what code?
Basically, any code that defines a __stdcall function pointer typedef,
like this one for example:
../../include/winnt.h:5034:15: warning: '__stdcall__' attribute only
applies to
function types
typedef VOID (NTAPI * PFLS_CALLBACK_FUNCTION) ( PVOID );
^
../../include/winnt.h:44:15: note: instantiated from:
#define NTAPI __stdcall
^../../include/windef.h:57:38: note: instantiated from:
# define __stdcall __attribute__((__stdcall__))
__attribute__((__force_align_
arg_pointer__)) ^
This boils down to, e.g.,
typedef void (__attribute__((stdcall)) * callback)(int, int);
which we complain about:
stdcall.c:1:30: warning: 'stdcall' attribute only applies to function types
typedef void (__attribute__((stdcall)) * callback)(int, int);
^
Basically, we don't yet have a way to encode the stdcall attribute in the type system, so we can't form a function pointer to a stdcall function. I've filed a PR for this, here:
5310 – [GCC Compatibility] Support stdcall/fastcall attribute on function types
- Doug
Douglas Gregor wrote:
Douglas Gregor wrote:
As I said earlier (in an email some of you may not have gotten, I got a
bunch of warning diagnostics about
__attribute__((__force_align_arg_pointer__)), which, according to a
comment in include/windef.h, is supposed to ensure the stack remains
16-byte aligned. Is this needed under clang for __stdcall functions on
Mac OS X? It's apparently needed under gcc.
We don't have support for this attribute in Clang, and I don't know
whether it is necessary for what you're doing. Please file an extension
request at
http://llvm.org/bugs/
You don't? Well then, I guess, to be on the safe side, I should file a
request.
Thanks, I see it at 5254 – Clang should support __attribute__((__force_align_arg_pointer__))
Speaking of __stdcall, I got some diagnostics related to
__attribute__((__stdcall__)) being used on function pointers. gcc does
not complain about this. Is this a known issue?
Not one I know about. What diagnostics on what code?
Basically, any code that defines a __stdcall function pointer typedef,
like this one for example:
../../include/winnt.h:5034:15: warning: '__stdcall__' attribute only
applies to
function types
typedef VOID (NTAPI * PFLS_CALLBACK_FUNCTION) ( PVOID );
^
../../include/winnt.h:44:15: note: instantiated from:
#define NTAPI __stdcall
^../../include/windef.h:57:38: note: instantiated from:
# define __stdcall __attribute__((__stdcall__))
__attribute__((__force_align_
arg_pointer__)) ^
This boils down to, e.g.,
typedef void (__attribute__((stdcall)) * callback)(int, int);
which we complain about:
stdcall.c:1:30: warning: 'stdcall' attribute only applies to function types
typedef void (__attribute__((stdcall)) * callback)(int, int);
^
Basically, we don't yet have a way to encode the stdcall attribute in
the type system, so we can't form a function pointer to a stdcall
function. I've filed a PR for this, here:
5310 – [GCC Compatibility] Support stdcall/fastcall attribute on function types
You did? But I already filed one here:
5280 – Clang doesn't allow __attribute__((__stdcall__)) on function pointers.
And then someone filed a dupe here:
5303 – Warning about attribude __stdcall__ applied on function pointer typedef.
- Doug
Took you a while to get back to me on this. Oh well, I've seen the
commit logs. You guys are busy with C++ support, so this is
understandable. Anyway, thanks.
Chip
Douglas Gregor wrote:
Basically, we don't yet have a way to encode the stdcall attribute in
the type system, so we can't form a function pointer to a stdcall
function. I've filed a PR for this, here:
5310 – [GCC Compatibility] Support stdcall/fastcall attribute on function types
You did? But I already filed one here:
5280 – Clang doesn't allow __attribute__((__stdcall__)) on function pointers.
Yikes, my mistake. Thanks for pointing that out.
And then someone filed a dupe here:
5303 – Warning about attribude __stdcall__ applied on function pointer typedef.
Both mine and 5303 closed as duplicates.
Took you a while to get back to me on this.
That shouldn't be typical; I was away at a C++ committee meeting for the week, so many things sent on the 19th or later got delayed.
- Doug