Community
Participate
Working Groups
In recent versions of gcc int32_t and int64_t are defined (in sys/types.h) as: typedef int int32_t __attribute__ ((__mode__ (__SI__))) typedef int int64_t __attribute__ ((__mode__ (__DI__))) Without taking the attributes into account int32_t and int64_t map to the same type, which causes name resolution problems for functions overloaded for these types. There are more modes like __SI__ and __DI__. A complete list is available in http://gcc.gnu.org/onlinedocs/gccint/Machine-Modes.html#Machine-Modes.
A workaround for this issue is to include stdint.h in the list of the files to index up-front before sys/resource.h. stdint.h provides alternative, easier to handle definitions for int32_t and int64_t: /* There is some amount of overlap with <sys/types.h> as known by inet code */ #ifndef __int8_t_defined # define __int8_t_defined typedef signed char int8_t; typedef short int int16_t; typedef int int32_t; # if __WORDSIZE == 64 typedef long int int64_t; # else __extension__ typedef long long int int64_t; # endif #endif sys/resource.h in my version of gcc includes sys/types.h, so stdint.h has to be in front of it.
The workaround described in comment #1 doesn't solve the problem since the __int8_t_defined macro, which is defined in stdint.h becomes undefined again when sys/types.h is parsed. I don't quite understand why macro definitions don't propagate between files parsed up front. This seems problematic since, as this example shows, gcc includes contain conflicting definitions of some bindings. Marcus, do you know why macro definitions don't propagate between files parsed up-front? Given the current behavior for parsing files up-front, the last definition wins. This leads to an alternative workaround - adding stdint.h AFTER sys/types.h.
For reference here is a code fragment from sys/types.h that defines int32_t and int64_t: # define __intN_t(N, MODE) \ typedef int int##N##_t __attribute__ ((__mode__ (MODE))) # define __u_intN_t(N, MODE) \ typedef unsigned int u_int##N##_t __attribute__ ((__mode__ (MODE))) # ifndef __int8_t_defined # define __int8_t_defined __intN_t (8, __QI__); __intN_t (16, __HI__); __intN_t (32, __SI__); __intN_t (64, __DI__); # endif
(In reply to comment #2) > ... > Marcus, do you know why macro definitions don't propagate between files parsed > up-front? > ... Macro definitions are always taken from the actual files included. I assume that <stdint.h> is not included where <sys/types.h> is parsed. As a workaround you can configure the indexer with: -D__int8_t_defined "-Dint8_t=signed char" ...
(In reply to comment #4) Markus, do you know what would break if the files parsed up-front were parsed together, as if they were included in the same source file?
(In reply to comment #5) > (In reply to comment #4) > Markus, do you know what would break if the files parsed up-front were parsed > together, as if they were included in the same source file? I'd expect no problems. You can try this by specifying a single file to be parsed up-front and put the includes in there. Off topic: The users don't understand the mechanism of parsing files up front, therefore I think we should remove the preference from the ui. Instead of that we could parse a file up-front that is located in the installation, where modifications can be made if necessary.
(In reply to comment #6) > Off topic: The users don't understand the mechanism of parsing files up front, > therefore I think we should remove the preference from the ui. Instead of that > we could parse a file up-front that is located in the installation, where > modifications can be made if necessary. Agree.
Attributes have to added to AST. Without the attribute there are name resolution problems with overloaded functions, for example: void foo(int i); void foo(int64_t i); Here are relevant documents: http://gcc.gnu.org/onlinedocs/gcc/Variable-Attributes.html, C++11 (ISO/IEC 14882:2011) Section 7.6.
*** Bug 375105 has been marked as a duplicate of this bug. ***
Fixed in master.
