The following program results in compiler warnings if the include statement in line 4 is added (uncommented).
Compiler: gcc version 8.1.0 (i686-win32-dwarf-rev0, Built by MinGW-W64 project)
#define __STDC_FORMAT_MACROS
// Adding this and -Wall results in compiler warning
//#include "stdio.h"
#include <cstdint>
#include <cinttypes>
#include <cstdio>
int main()
{
int64_t i = 0;
printf("%" PRId64, i);
}
The warnings are:
testlld.cpp:11:14: warning: unknown conversion type character 'l' in format [-Wformat=]
std::printf("%" PRId64, i);
^
testlld.cpp:11:14: warning: too many arguments for format [-Wformat-extra-args]
testlld.cpp:11:14: warning: unknown conversion type character 'l' in format [-Wformat=]
testlld.cpp:11:14: warning: too many arguments for format [-Wformat-extra-args]
Can someone explain what happens?
I can of course fix this by using only <cstdio>, which would be the correct thing in this case.
But it leads to another question...
Say I have a header file that is included by two implementation files - one compiled with a C compiler and one compiled with a C++ compiler. The header file would need to use "stdio.h" since it needs to compile with a C compiler. Does this mean that all code including that header file must also use "stdio.h" and NOT <cstdio>, even if it is C++ code?
This seems to be a known bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60434
This makes sense since - despite the warning - the 64 bit integer is printed correctly.
By the way, when compiling as C (changing the included headers to .h), the format string defined by PRId64 is I64d. Using this format string gives no warning neither when compiling as C nor as C++. Hence a possible workaround is to use
printf("%I64d", i);
Another option is to build with -D__USE_MINGW_ANSI_STDIO.
Following the suggestions above, I did the following, which compiles without warnings.
// Needed to define the macros for data types in inttypes.h
#define __STDC_FORMAT_MACROS
// This part in header file (.h) re-used by this file as well as .c files compiled with C compiler
#ifdef __cplusplus
#include <cstdio>
#else
#include "stdio.h"
#endif
#include <cstdint>
#include <cinttypes>
#include <cstdio>
int main()
{
int64_t i = 0;
printf("%" PRId64, i);
}
This looks like a good (the right?) solution for me.
Related
I have here a small test app which uses isnan from <math.h>:
#include <iostream>
#include <math.h>
int main()
{
double d = NAN;
std::cout << isnan(d) << '\n';
return 0;
}
Build and run under 3 different standards:
$ g++ -std=c++98 main.cpp; ./a.out
1
$ g++ -std=c++11 main.cpp; ./a.out
1
$ g++ -std=c++14 main.cpp; ./a.out
1
Now we also include <cmath>, and test with both isnan and std::isnan:
#include <iostream>
#include <cmath>
#include <math.h>
int main()
{
double d = NAN;
std::cout << std::isnan(d) << '\n';
std::cout << isnan(d) << '\n';
return 0;
}
Build and run:
C++98 works
$ g++ -std=c++98 main.cpp; ./a.out
1
1
C++11 and C++14 don't, isnan is not found.
$ g++ -std=c++11 main.cpp
main.cpp: In function ‘int main()’:
main.cpp:10:25: error: ‘isnan’ was not declared in this scope
std::cout << isnan(d) << '\n';
^
main.cpp:10:25: note: suggested alternative:
In file included from main.cpp:3:0:
/usr/include/c++/5/cmath:641:5: note: ‘std::isnan’
isnan(_Tp __x)
^
$ g++ -std=c++14 main.cpp
main.cpp: In function ‘int main()’:
main.cpp:10:25: error: ‘isnan’ was not declared in this scope
std::cout << isnan(d) << '\n';
^
main.cpp:10:25: note: suggested alternative:
In file included from main.cpp:3:0:
/usr/include/c++/5/cmath:641:5: note: ‘std::isnan’
isnan(_Tp __x)
^
Note the order of inclusion is not important. If I include <cmath> before <math.h> or after, the result is the same.
Questions
Why is isnan gone?
Without having to go back and change old code to compile under the new standard, is there any way to fix this?
Briefly summarizing the pertinent points, mostly from Jonathan Wakely's excellent blog post:
glibc <2.23's math.h declares the obsolete X/Open int isnan(double); that is incompatible with the C99/C++11 version (bool isnan(double);).
glibc 2.23's math.h fixes this by not declaring the isnan function in C++11 or later.
All of them still define an isnan macro. #include <cmath> nukes that macro as required by the C++ standard.
GCC 6's libstdc++ provides its own special math.h header that declares a bool isnan(double); in the global namespace (unless the libc math.h declares the obsolete signature) and also nukes the macros as required by the standard.
Before GCC 6, #include <math.h> simply included the header from your libc, so the macro isn't nuked.
#include <cmath> always nukes the macros.
Net result, in C++11 mode:
glibc < 2.23, GCC < 6: <math.h> uses the macro; <cmath> uses obsolete signature
glibc >= 2.23, GCC < 6: <math.h> uses the macro; <cmath> results in error
glibc < 2.23, GCC >= 6: <math.h> and <cmath> use obsolete signature
glibc >= 2.23, GCC >= 6: <math.h> and <cmath> use standard signature
If you look inside <cmath> from GCC, it has this:
. . .
#include <math.h>
. . .
#undef isnan
That's why the order doesn't matter - whenever you #include <cmath>, <math.h> is auto-included and its contents is (partially) nuked.
Attempting to include it again will have no effect because of #ifndef _MATH_H.
Now, what does the standard have to say about this behavior?
[depr.c.headers]:
... every C header, each
of which has a name of the form name.h, behaves as if each name placed
in the standard library namespace by the corresponding cname header is
placed within the global namespace scope. It is unspecified whether
these names are first declared or defined within namespace scope
([basic.scope.namespace]) of the namespace std and are then injected
into the global namespace scope by explicit using-declarations
([namespace.udecl]).
[ Example: The header <cstdlib> assuredly provides its declarations
and definitions within the namespace std. It may also provide these
names within the global namespace. The header <stdlib.h> assuredly
provides the same declarations and definitions within the global
namespace, much as in the C Standard. It may also provide these names
within the namespace std. — end example ]
So it's OK that <cmath> does not provide isnan in the global namespace.
But it's a gray area what should happen when both are included in one compilation unit, although one could argue that the statement above implies that both versions must interoperate, in which case it would be a bug in GCC/libstdc++ (some versions).
A lot of the functions inside math.h are actually macros. Since this is not idiomatic c++ the header cmath contains following code:
...
#undef isinf
#undef isnan
#undef isnormal
...
And implements then all those undefined macros as function in the namespace std. This is at least true for gcc 6.1.1. That's why your compiler can't find isnan.
Macro DOMAIN in math.h collides with enums and possibly other types. I don't know what to make of it.
#include <algorithm>
enum Type { DOMAIN };
int main(){
Type t = Type::DOMAIN;
return 0;
}
Compile with flag -std=c++11. The C99 version of this code compiles perfectly fine though:
#include <algorithm>
enum Type { DOMAIN };
int main(){
Type t = DOMAIN;
return 0;
}
I checked the source code and the library is to blame. algorithm includes stl_algo.h, in which there is ifdef:
#if __cplusplus >= 201103L
#include <random> // for std::uniform_int_distribution
#include <functional> // for std::bind
#endif
The following code compiles fine on c++11 compiler:
#include <random>
#include <iostream>
int main(){
std::cout << DOMAIN << std::endl;
return 0;
}
Is it a feature or a bug?
EDIT* dirty fix:
#ifdef DOMAIN
#undef DOMAIN
#endif
It's a bug (or a "wart" if you want to be generous).
All the rest of this answer refers only to GCC and the Gnu standard C library headers. The man page references are to a linux system (but I've added links to man7.org).
The DOMAIN macro comes from math.h's System V support. (See man matherr.) System V support is normally enabled by defining the _SVID_SOURCE feature-test macro (see man feature_test_macros), but it is enabled along with a raft of other extensions if _GNU_SOURCE is defined, or by default if no feature test macros are defined.
gcc predefines _GNU_SOURCE for C programs if the --std option is omitted or set to gnu##. The various --std=c## options cause __STRICT_ANSI__ to be defined. Consequently, compiling C code with some explicit C standard will suppress the System V extensions. That needs to be done because the System V extensions are not standards-compatible, not even with Posix, because they pollute the global namespace. (DOMAIN is just one example of this pollution.)
However, g++ defines _GNU_SOURCE even if --std=c++## is specified, and consequently the System V extensions will sneak in. (Thanks to #dyp for the link to this libstdc++ FAQ entry. and this long and inconclusive discussion from 2001 on the GCC mailing list)
An ugly workaround is to set up the features yourself, and then undefine __USE_SVID:
#include <features.h>
#undef __USE_SVID
#include <random>
#include <iostream>
int main(){
std::cout << DOMAIN << std::endl;
return 0;
}
(Live on coliru)
IMHO, this should not be necessary. But there it is.
§ 17.6.5.2 [res.on.headers] / 1 of N4140 says:
A C++ header may include other C++ headers. A C++ header shall provide the declarations and definitions that appear in its synopsis. A C++ header shown in its synopsis as including other C++ headers shall provide
the declarations and definitions that appear in the synopses of those other headers.
Therefore, it is valid for <algorithm> to #include <cmath> which injects the offending macro constant into your namespace.
Note, however, that your “quick and dirty fix” is disallowed by the standard (§ 17.6.4.3.1 [macro.names] / 1):
A translation unit that includes a standard library header shall not #define or #undef names declared in any standard library header.
You'll have to choose a name different from DOMAIN for your enum constant.
I have a very complicated program and i have simplified it in order to make my problem easy to understand: I have a 2 scripts and 1 header: time_analysis.cu, DSMC_kernel_float.cu and DSMC_kernel_float.h;
Here is the time_analysis.cu
#include <cstdlib>
#include <cstdio>
#include <algorithm>
#include <math.h>
#include <cutil.h>
#include <stdio.h>
#include <assert.h>
#include <memory.h>
#include <string.h>
#include <time.h>
#include <cuda_gl_interop.h>
#include <cutil_math.h>
#include "math_constants.h"
#include "vector_types.h"
#include "vector_functions.h"
typedef struct {
int seme;
} iniran;
typedef struct{
int jp1;
int jp2;
float kx;
float ky;
float kz;
} stato_struct;
stato_struct* coll_CPU=0;
stato_struct* coll2dev=0;
stato_struct* coll_GPU=0;
#include "DSMC_kernel_float.h"
//==============================================================
int main(void){
int N_thread = 4;
int ind;
coll_CPU[0].jp1= 0;
coll_CPU[1].jp2= 1;
coll_CPU[2].kx= 2;
coll_CPU[3].ky= 3;
coll_CPU[4].kz= 4;
for(ind=0;ind<=5;ind++){
coll2dev[ind]=coll_CPU[ind];
}
coll2dev=(stato_struct*) malloc(N_thread*sizeof(stato_struct));
CUDA_SAFE_CALL(cudaMalloc((void**)&coll_GPU, N_thread*sizeof(stato_struct)));
CUDA_SAFE_CALL(cudaMemcpy(coll_GPU,coll2dev,N_thread*sizeof(stato_struct), cudaMemcpyHostToDevice));
CollisioniGPU<<<4,N_thread>>>(coll_GPU);
CUT_CHECK_ERROR("Esecuzione kernel fallita");
CUDA_SAFE_CALL(cudaMemcpy(coll2dev, coll_GPU, N_thread*sizeof(stato_struct),cudaMemcpyDeviceToHost));
free(coll2dev);
CUDA_SAFE_CALL(cudaFree(coll_GPU));
free(coll_CPU);
return 0;
}
Here is the DSMC_kernel_float.cu
// Kernel della DSMC
#include "DSMC_kernel_float.h"
__global__ void CollisioniGPU(stato_struct *coll_GPU){
coll_GPU[0].vAx=1;
coll_GPU[1].vAy=1;
coll_GPU[2].vAz=1;
coll_GPU[3].tetaAp=1;
coll_GPU[4].phiAp=1;
}
Here is the DSMC_kernel_float.h
__global__ void CollisioniGPU(stato_struct* coll_GPU);
However when i type nvcc -I common/inc -rdc=true time_analysis.cu DSMC_kernel_float.cu in the terminal I get a weird message error and i don't understand why
DSMC_kernel_float.h(1): error: attribute "global" does not apply here
DSMC_kernel_float.h(1): error: incomplete type is not allowed
DSMC_kernel_float.h(1): error: identifier "stato_struct" is undefined
DSMC_kernel_float.h(1): error: identifier "coll_GPU" is undefined
DSMC_kernel_float.cu(4): error: variable "CollisioniGPU" has already been defined
DSMC_kernel_float.cu(4): error: attribute "global" does not apply here
DSMC_kernel_float.cu(4): error: incomplete type is not allowed
DSMC_kernel_float.cu(4): error: expected a ";"
At end of source: warning: parsing restarts here after previous syntax error
8 errors detected in the compilation of "/tmp/tmpxft_00003f1f_00000000-22_DSMC_kernel_float.cpp1.ii".
From what I read in the internet, I believe the error is cause by the struct but i don't understand how i could fix it to make the program work properly; how is possible that global does not apply here if i have other examples where it seems to be just fine?
Note: commom/inc is the folder provided by Nvidia in order to make Cuda compile correctly.
Regarding this statement:
Note: commom/inc is the folder provided by Nvidia in order to make Cuda compile correctly.
That's a mischaracterization. The referenced files (cutil.h and cutil_math.h) and macros (e.g. CUT_CHECK_ERROR) were provided in fairly old CUDA releases (prior to CUDA 5.0) as part of the cuda sample codes that were delivered at that time. They are not required "in order to make Cuda compile correctly." Furthermore, their use should be considered deprecated (refer to the CUDA 5.0 toolkit release notes). And if you are actually using an old toolkit like that, I would suggest upgrading to a newer one.
Regarding the compile issues, as #talonmies has pointed out, the compiler has no way of knowing what the definition of stato_struct is, when compiling any module that does not contain the definition (whether directly or included). This would be the case for your DSMC_kernel_float.cu module, which is where all your compile errors are coming from.
At first glance, it would seem that a sensible fix would be to move the typedef containing the stato_struct definition from your time_analysis.cu file into your header file (DSMC_kernel_float.h) and move the #include statement for that to the top of the time_analysis.cu file, along with your other includes.
However, it appears that your DSMC_kernel_analysis.cu file believes that there are a variety of members of that stato_struct:
__global__ void CollisioniGPU(stato_struct *coll_GPU){
coll_GPU[0].vAx=1;
coll_GPU[1].vAy=1;
coll_GPU[2].vAz=1;
coll_GPU[3].tetaAp=1;
coll_GPU[4].phiAp=1;
}
which are not part of your current definition of stato_struct:
typedef struct{
int jp1;
int jp2;
float kx;
float ky;
float kz;
} stato_struct;
So this is confusing code, and I don't think anyone else can sort that out for you. You will either need two separate struct definitions, with separate names, or else you will need to modify your stato_struct definition to include those members (.vAx, .vAy, .vAz, .tetaAp, .phiAp).
The (mis)handling of this struct definition and the resultant errors have nothing to do with CUDA. This is arising out of the C/C++ language expectations.
The following program, when compiled as C++ with GCC 4.8.1
#include <inttypes.h>
#include <stdint.h>
#include <stdio.h>
int main() {
uintptr_t i = 0;
i--;
printf("%" PRIuPTR "\n", i);
return 0;
}
gives the following error message
a.cc: In function 'int main()':
a.cc:8:13: error: expected ')' before 'PRIuPTR'
printf("%" PRIuPTR "\n", i);
^
It compiles and runs correctly with the Microsoft compiler, and even with GCC when compiled as C.
Am I missing something, or is this a bug in GCC? If the latter, is there a workaround?
The C standard says this about including the C header from C++:
C++ implementations should define these macros only when __STDC_FORMAT_MACROS is defined
before <inttypes.h> is included.
and it seems that GCC follows this recommendation, while Microsoft doesn't.
Rather than defining this macro and including the deprecated C header, a better solution is to use the C++ header <cinttypes>, which defines these macros unconditionally. (As noted in the comments, the C++ standard specifically says that the macro has no effect on the C++ header.)
Alternatively, stop using the C library when there's a more convenient (and typesafe) C++ alternative, std::cout << i;
I am trying to compile a 8hz mp3 encoder - C code in QT Creator.
In a file l3psy.c that starts like this
#include <stdio.h>
#include "types.h"
#include "error.h"
#include "layer3.h"
#include "l3psy.h"
#include "fft.h"
#include "tables.h"
The build step complains about PI being undeclared here
for(i=0;i<BLKSIZE;i++) window[i] = 0.5*(1-cos(2.0*PI*(i-0.5)/BLKSIZE));
But types.h, which is obviously included, starts like this:
#ifndef TYPES_H
#define TYPES_H
#include <stdio.h>
#include <time.h>
#include "portableio.h"
#ifdef PI
#undef PI
#define PI 3.14159265358979
#endif
#define PI4 .78539816339745
#define PI64 .049087385212
therefore, there is no way for PI to be undeclared.
What can be the problem here?
also, aside from that stopper, I also get complains about "implicit declaration of function abort" and "implicit declaration of function exit" and "incompatible implicit declaration of built-in function 'exit'", but, they are standard functions of c, why would it complain?
For the first problem, about PI, see Pascal Cuoq's comment (that's all).
For the problems with implicit declarations being reported, you haven't included the relevant header(s) for those functions. IIRC exit and abort are declared by <stdlib.h. But check it out.
Cheers & hth.,