With clang-3.5.0 (but not gcc-4.9.2, nor the intel compiler) I get the message:
use of undeclared identifier '_mm_cvtsi64x_si128'; did you mean '_mm_cvtsi64_si128'
This is an intrinsic that I find documented in the intel intrisics guide, and the code in question does have the include that's documented as required in the intinsics guide:
#include "emmintrin.h"
I was wondering if this error was a result of not passing the right -mcpu= flags, but I tried -mcpu=nahelem, which should be sufficient for this sse2 instruction. Any idea if this intrinsic is supported in clang, and if it is, what compilation flags are required to allow it's use?
It looks like there are a couple of alternate intrinsic names in intel's emmintrin.h:
#define _mm_load_pd1 _mm_load1_pd
#define _mm_set_pd1 _mm_set1_pd
#define _mm_store_pd1 _mm_store1_pd
#define _mm_cvtsi64x_si128 _mm_cvtsi64_si128
#define _mm_cvtsi128_si64x _mm_cvtsi128_si64
Looks like clang's emmintrin.h doesn't have any of these alternate names, but that I can just adjust our code to use the non-alternates (our code is using both of the last two alternate names above).
Related
If I can do this in Delphi,
{$IFDEF VER350}
/* Declare, define, do stuff ... */
{$ENDIF}
why can't I do this in C++Buider,
#ifdef VER350
// Declare, define, do stuff ...
#endif
How do I get the compiler version in C++Builder?
Because the compiler doesn't define the same macro or do that kind of thing in the same way as Delphi.
According to this webpage, the macro you are looking for is called __BCPLUSPLUS__ and you have to check if it is equal to the version code you are looking for. See this page for the Delphi - C++ Builder equivalents.
However, the versioning is not quite as straight forward as in the case of Delphi and the table at the bottom of the page doesn't seem to have been updated to include the version of C++ Builder that corresponds to Delphi VER350. Still, it stands to reason that since the VER340 equivalent is listed as 0x0750 and the one before that was 0x0740, then the latest is most likely 0x0760. It is an easy check on your end in any case.
It would look something like
#if __BCPLUSPLUS__ == 0x0760
...
#endif
First question here.
I have some troubles with the XCode Build System, specifically with preprocessor definitions.
I'm trying to define a macro for the objective-c runtime to avoid enforcing the dispatch functions to be cast to an appropriate function pointer type. The usual way to go would be to use #define OBJC_OLD_DISPATCH_PROTOTYPES and then include the header on the next line. Once the header gets included, the macro is already defined and the header is configured accordingly.
But that's where it starts to get weird!
The macro is not recognized at all and the header gets included as if the #define statement was not there so it fails to #define OBJC_OLD_DISPATCH_PROTOTYPES and it gets (re?)defined as 0.
main.c
#include <stdio.h>
#define OBJC_OLD_DISPATCH_PROTOTYPES 1
#include <objc/objc-runtime.h>
int main(int argc, const char * argv[]) {
// From there:
// - Build System: OBJC_OLD_DISPATCH_PROTOTYPES is always 0, except if defined in build settings
// - Clang (only): OBJC_OLD_DISPATCH_PROTOTYPES is 1
printf("%d\n", OBJC_OLD_DISPATCH_PROTOTYPES);
}
The build system acts as expected when the preprocessor macro is defined in the project build settings under the "Apple Clang - Preprocessing" section. It defines the global macro using the -D parameter of clang making it available to any files used by the project.
However, source code compiles correctly when I use clang from a terminal using clang main.c.
Could someone tell me what I need to configure for the build system to behave normally?
It gives a warning when building with Xcode IDE:
Ambiguous expansion of macro 'OBJC_OLD_DISPATCH_PROTOTYPES'
and the output is indeed 0 using Xcode directly, but 1 with clang main.c. The difference is that Xcode uses clang with enabled modules by default: You get the same warning on the command line if you enable modules there:
clang -fmodules main.c
Solution
In Xcode, select the target, go to the "Build Settings" tab and in the "Apple Clang - Language - Modules" section, switch the "Enable Modules (C and Objective-C)" entry to 'NO':
Then you get the expected result in both cases, regardless of whether you use Xcode or Clang on the command line.
Explanation:
If you use modules the following happens:
instead of the preprocessor including the text and compiling the result, a binary representation of the module is used
modules are (independently) precompiled, i.e. they use the definitions from the time the module was precompiled
consequently, preprocess definitions from the code before the include/import statement have no effect on the module (nor on other imported modules).
if modules are enabled, not only #imports are affected, but also #includes are translated into module imports under the hood
So you have a contradictory definitions for the OBJC_OLD_DISPATCH_PROTOTYPES.
The precompiled module uses a 0 for OBJC_OLD_DISPATCH_PROTOTYPES and you redefine it as 1.
BTW: if you use
#define OBJC_OLD_DISPATCH_PROTOTYPES 0
then you use the same definition that the precompiled module is using and therefore there is no warning about an ambiguous expansion of the macro even if modules are enabled.
Without enabled modules, the preprocessor includes the text, compiles the result and returns the expected result, i.e. in objc.h the desired typedef are used.
The implementation of function memcmp in glibc uses the macro DBLALIGN(eg, DBLALIG(a3, a0, srcli)) to compare two unsinged int integer. DBLALIGN is delcared as follows. However, the definition of __insn_dword_align is not found in glibc source codes. Where can I find it. Thank you!
#ifdef __tilegx__
#define DBLALIGN __insn_dblalign
#define REVBYTES __insn_revbytes
#else
#define DBLALIGN __insn_dword_align
#define REVBYTES __insn_bytex
#endif
It's a gcc builtin. See e.g. here.
I cannot find the definition
You wouldn't find a definition for any builtin. That's what "builtin" means: the compiler recognizes builtin by name and emits required instructions directly to assembly.
I have installed the current stable JEDI Code library in C++ Builder XE3 on Windows 7 x32. It works fine, but only as long as I don't include files like JclFileUtils.hpp which are including JclWin32.hpp. Then I get always the compiler error E2040: "Declaration terminated incorrectly" (in file JclWin32.hpp, line 682, second line in the following code snippet):
#define NetApi32 L"netapi32.dll"
static const System::Int8 CSIDL_PROGRAM_FILESX86 = System::Int8(0x2a);
#define RT_MANIFEST (System::WideChar *)(0x18)
I neither have an idea were this error comes from, nor could I found any hints to this. What could be the cause? Thanks in advance.
I got help and the solution for this problem. Just replace the static const declaration:
static const System::Int8 CSIDL_PROGRAM_FILESX86 = System::Int8(0x2a);
with this macro definition:
#define CSIDL_PROGRAM_FILESX86 0x2a
This is a bug in JclWin32.pas.
In C/C++, the Win32 API declares CSIDL values in Microsoft's shlobj.h header using preprocessor #define statements, eg:
#define CSIDL_PROGRAM_FILESX86 0x002a
After the preprocessor is run and performs #define symbol replacements, the compiler ends up seeing the following invalid declaration in JclWin32.hpp:
static const System::Int8 0x002a = System::Int8(0x2a);
JCL should not be re-declaring CSIDL_PROGRAM_FILESX86 (or any other CSIDL value) at all. It should be either:
using Delphi's own Winapi.ShlObj unit, which already declares CSIDL values.
if not using the Winapi.ShlObj unit, then it should at least be declaring its manual CSIDL values as {$EXTERNALSYM} so they do not appear in the generated JclWin32.hpp file. If needed, JCL can include an {$HPPEMIT '#include <shlobj.h>'} statement to pull in the existing Win32 API declarations for C/C++ projects to use.
I am trying to use QT in iOS.
#include <QtGui/qprinter.h>
QPrinter print;
Above code gives "Variable has incomplete type 'QPrinter'" error. Though QtGui/qprinter.h has complete definition for QPrinter. Any ideas how to resolve this problem?
The qprinter.h file has this preprocessor condition before the definition of QPrinter:
#ifndef QT_NO_PRINTER
// class QPrinter {
// ...
// }
#endif
Maybe on iOS QT_NO_PRINTER is defined, perhaps because it is not supported? I can't find any official documentation that says as much, but it would be easy enough to test if that macro is defined in your build.