I am compiling with clang++ -pedantic -Werror -std=c++11
C++11 does not support variable length arrays and so the compiler warns when they are used.
g++ supports the -Wno-vla option to stop it from doing this.
This doesn't appear to work in clang++, is there an alternative that does work?
error: variable length arrays are a C99 feature [-Werror,-Wvla-extension]
int a[argc];
^
1 error generated.
clang++ helpfully tells you what flags generated the diagnostic. Just "invert" the flag, in this case: -Wno-vla-extension.
Related
I'm debugging a large code with the flags -Wall and -Wextra, but I'm getting hundreds of Unused parameter warnings which I'm not interested in. Is there a way to suppress only these warnings?
Simply append -Wno-unused-parameter... See here for details.
From the docs:
Each of these specific warning options also has a negative form
beginning -Wno- to turn off warnings; for example, -Wno-implicit.
I'd like to use a single (cross-)compiler to compile code for different ARM calling conventions: since I always want to use floating point and NEON instructions, I just want to select the hard-float calling convention or the soft-float (softfp) calling convention.
My compiler defaults to hard-float, but it supports both architectures that I need:
$ arm-linux-gnueabihf-gcc -print-multi-lib
.;
arm-linux-gnueabi;#marm#march=armv4t#mfloat-abi=soft
$
When I compile with the default parameters:
$ arm-linux-gnueabihf-g++ -Wall -o hello_world_armhf hello_world.cpp
It succeeds without any errors.
If I compile with the parameters returned by -print-multi-lib:
$ arm-linux-gnueabihf-g++ -marm -march=armv4t -mfloat-abi=soft -Wall -o hello_world hello_world.cpp
It again compiles without error (By the way, how can I test that the resultant code is hard- or soft-float?)
Unfortunately, if I try this:
$ arm-linux-gnueabihf-g++ -march=armv7-a -mthumb-interwork -mfloat-abi=softfp -mfpu=neon -Wall -o hello_world hello_world.cpp
[...]/gcc/bin/../lib/gcc/arm-linux-gnueabihf/4.7.3/../../../../arm-linux-gnueabihf/bin/ld: error: hello_world uses VFP register arguments, /tmp/ccwvfDJo.o does not
[...]/gcc/bin/../lib/gcc/arm-linux-gnueabihf/4.7.3/../../../../arm-linux-gnueabihf/bin/ld: failed to merge target specific data of file /tmp/ccwvfDJo.o
collect2: error: ld returned 1 exit status
$
I've tested some other permutations of the parameters, but it seems that anything other than the combination shown by -print-multi-lib results in an error.
I've read ARM compilation error, VFP registered used by executable, not object file but the problem there was that some parts of the binary were soft- and some were hard-float. I have a single C++ file to compile...
What parameter(s) I miss to be able to compile with -march=armv7-a -mthumb-interwork -mfloat-abi=softfp -mfpu=neon?
How is it possible that the error is about VFP register arguments while I explicitly have -mfloat-abi=softfp in the command line which prohibits VFP register arguments?
Thanks!
For the records, hello_world.cpp contains the following:
#include <iostream>
int main()
{
std::cout << "Hello, world!" << std::endl;
return 0;
}
You need another compiler with corresponding multilib support.
You can check multilib support with next command.
arm-none-eabi-gcc -print-multi-lib
.;
thumb;#mthumb
fpu;#mfloat-abi=hard
armv6-m;#mthumb#march=armv6s-m
armv7-m;#mthumb#march=armv7-m
armv7e-m;#mthumb#march=armv7e-m
armv7-ar/thumb;#mthumb#march=armv7
cortex-m7;#mthumb#mcpu=cortex-m7
armv7e-m/softfp;#mthumb#march=armv7e-m#mfloat-abi=softfp#mfpu=fpv4-sp-d16
armv7e-m/fpu;#mthumb#march=armv7e-m#mfloat-abi=hard#mfpu=fpv4-sp-d16
armv7-ar/thumb/softfp;#mthumb#march=armv7#mfloat-abi=softfp#mfpu=vfpv3-d16
armv7-ar/thumb/fpu;#mthumb#march=armv7#mfloat-abi=hard#mfpu=vfpv3-d16
cortex-m7/softfp/fpv5-sp-d16;#mthumb#mcpu=cortex-m7#mfloat-abi=softfp#mfpu=fpv5-sp-d16
cortex-m7/softfp/fpv5-d16;#mthumb#mcpu=cortex-m7#mfloat-abi=softfp#mfpu=fpv5-d16
cortex-m7/fpu/fpv5-sp-d16;#mthumb#mcpu=cortex-m7#mfloat-abi=hard#mfpu=fpv5-sp-d16
cortex-m7/fpu/fpv5-d16;#mthumb#mcpu=cortex-m7#mfloat-abi=hard#mfpu=fpv5-d16
https://stackoverflow.com/questions/37418986/how-to-interpret-the-output-of-gcc-print-multi-lib
How to interpret the output of gcc -print-multi-lib
With this configuration gcc -mfloat-abi=hard not only will build your files using FPU instructions but also link them with corresponding libs, avoiding "X uses VFP register arguments, Y does not" error.
The above-mentioned -print-multi-lib output produced by gcc with this patch and --with-multilib-list=armv6-m,armv7,armv7-m,armv7e-m,armv7-r,armv7-a,cortex-m7 configuration option.
If you are interested in building your own gcc with Cortex-A series multilib support, just use --with-multilib-list=aprofile configuration option for any arm*-*-* target without any patches (at list with gcc-6.2.0).
As per Linaro FAQ if your compiler prints arm-linux-gnueabi;#marm#march=armv4t#mfloat-abi=soft then you can only use -march=armv4t. If you want to use -march=armv7-a you need to build compiler yourself.
Following link could be helpful in building yourself GCC ARM Builds
Using the following command
gcc -c -Wall -Wextra -pedantic -ansi -std=c99 -fstack-protector-all -fstack-check -O3 root.c -o rootTESTOBJECT
I get the compiler warning
root.h:76:22: warning: ISO C does not permit named variadic macros
72 #ifdef Debug
73 #include <stdio.h>
74 #define crumb(phrase0...) printf(phrase0)
75 #else
76 #define crumb(phrase0...)
77 #endif
I believe the option
-ansi -std=c99
allows the use of variadic macros, it does according to the docs anyway...
I have tried editing line 76 to
76 #define crumb(phrase0...) printf("")
to see if this fixed the warning but with no joy.
the compiler verion is Apple's gcc, version 4.2.1
I'm not sure if I need be too concerned by this but I really don't like warnings. What flag's am I missing ?
#define crumb(phrase0...) <whatever> is giving a name (phrase0) to the variable arguments (...).
This is a GCC extension.
C99 does define a way of passing variable arguments to macros (see §6.10.3/12 and §6.10.3.1/2): the variable arguments are unnamed
on the left-hand side of the definitions (i.e. just ...), and referenced on the right-hand side as __VA_ARGS__, like this:
#define crumb(...) printf(__VA_ARGS__)
(By the way, your gcc arguments should not include both -ansi and -std=c99: -ansi specifies the earlier C standard (known variously as ANSI C, C89 or C90); the combination of both options only happens to select C99 in this case because -std=c99 appears after -ansi in the argument list, and the last one wins.)
I need to add unit tests using Cmockery to an existing build environment that uses as hand-crafted Makefile. So I need to figure out how to build cmockery.c (without automake).
When I run:
g++ -DHAVE_CONFIG_H -DPIC -I ../cmockery-0.1.2 -I /usr/include/malloc -c ../cmockery-0.1.2/cmockery.c -o obj/cmockery.o
I get a long list of errors like this:
../cmockery-0.1.2/cmockery.c: In function ‘void initialize_source_location(SourceLocation*)’:
../cmockery-0.1.2/cmockery.c:248: error: cast from ‘SourceLocation*’ to ‘int’ loses precision
Here are lines 247:248 of cmockery.c:
static void initialize_source_location(SourceLocation * const location) {
assert_true(location);
assert_true is defined on line 154 of cmockery.h:
#define assert_true(c) _assert_true((int)(c), #c, __FILE__, __LINE__)
So the problem (as the error states) is GCC doesn't like the cast from ‘SourceLocation*’ to ‘int’.
I can build Cmockery using ./configure and make (on Linux, and on Mac OS X if I export CFLAGS=-I/usr/include/malloc first), without any errors. I've tried looking at the command-line that compiles cmockery.c when I run make (after ./configure):
gcc -DHAVE_CONFIG_H -I. -I. -I./src -I./src -Isrc/google -I/usr/include/malloc -MT libcmockery_la-cmockery.lo -MD -MP -MF .deps/libcmockery_la-cmockery.Tpo -c src/cmockery.c -fno-common -DPIC -o .libs/libcmockery_la-cmockery.o
...but I don't see any options that might work around this error.
In "error: cast from 'void*' to 'int' loses precision", I see I could change (int) in cmockery.h to (intptr_t). And I've confirmed that works. But since I can build Cmockery with ./configure and make, there must be a way to get it to build without modifying the source.
Using gcc instead of g++ on my system turns that error into a warning on my system (Mandriva Linux 2010.1 64-bit) and allows the compilation to complete:
.
.
.
../cmockery-0.1.2/cmockery.c:248: warning: cast from pointer to integer of different size
.
.
.
I feel the need to point out, however, that I am generally wary when I see a whole horde of warnings on what is a relatively common platform (Linux 64-bit/GCC and I would presume others). Using the -m32 option to force compilation to a 32-bit object file does not produce any warnings, so one could presume that the source code used as-is is may not be 64-bit clean. This happens whether you use the autotools or not.
I don't know the project in question, so it might very well be OK, but in any case use with caution...
EDIT:
According to this answer to the OP's question to the cmockery mailing list, the current release is not 64-bit clean at this time. It seems that the errors/warnings were there for a good reason...
I'm compiling C++ code and I'd like to enable the -pedantic option.
I'm using GCC 4.0, running Xcode on Mac OS X Leopard.
It is for example possible to allow variadic macros and the long long type that are normally forbidden when using -pedantic (with -Wno-variadic-macros and -Wno-long-long).
But I could not find anything to disable the "comma at end of enumerator list" warning.
Is it possible?
Thanks.
A comma at the end of an enumerator is valid in C99 but not in C89, so the following will work providing your code is valid C99
gcc -std=c99 -pedantic foo.c
I'm fairly sure that it's not valid in C++ (according to g++) at all
Edit: tested this with GCC 4.2.1 on HP-UX and it works with no errors / warnings
foo.c
int main(int argc, char** argv) {
enum { A, B, };
return 0;
}
gcc -std=c99 -pedantic foo.c
In C++ it is not yet possible to disable it, even though it legal in C++11.
So in the future, when GCC is corrected, -std=c++11 should disable it.
-std=c99 only works in C, not C++ (as in the question).