I'm using the official release of ARM GCC 2018 Q4 Major. For this C code:
int main(void) { return 0; }
the compiler produces a warning:
$ arm-none-eabi-gcc -mstructure-size-boundary=32 main.c
cc1.exe: warning: option '-mstructure-size-boundary' is deprecated
Is it possible to suppress this warning? The flag -Wno-deprecated has no effect.
I need to use the -mstructure-size-boundary option because I need to link against someone else's closed source compiled libraries that used the same setting. (Well, I guess I could edit their headers and manually set trailing struct padding but that would not be Plan A).
Related
I am trying to build cmake source, which requires C++11.
The build halts and apparently the complaint is that C++11 is not detected. The g++ mode is actually set to -std=gnu++17
This is part of the console log
---------------------------------------------
CMake 3.18.20200919, Copyright 2000-2020 Kitware, Inc. and Contributors
Found GNU toolchain
C compiler on this system is: gcc
C++ compiler on this system is: g++ -std=gnu++17
Makefile processor on this system is: make
g++ has setenv
g++ has unsetenv
g++ does not have environ in stdlib.h
g++ has stl wstring
g++ has <ext/stdio_filebuf.h>
---------------------------------------------
g++ -std=gnu++17 -DCMAKE_BOOTSTRAP -DCMake_HAVE_CXX_MAKE_UNIQUE=1 -c $HOME/Apps/CMake-master/Source/cmAddCustomCommandCommand.cxx -o cmAddCustomCommandCommand.o
This is part of the error in the log file...
In file included from /usr/include/c++/5/unordered_map:35:0,
from cmake_bootstrap_11920_test.cxx:4:
/usr/include/c++/5/bits/c++0x_warning.h:32:2: error: #error This file requires compiler and library support for the ISO C++ 2011 standard. This support must be enabled with the -std=c++11 or -std=gnu++11 compiler options.
#error This file requires compiler and library support \
^
cmake_bootstrap_11920_test.cxx:7:2: error: #error "Compiler is not in a mode aware of C++11."
#error "Compiler is not in a mode aware of C++11."
^
cmake_bootstrap_11920_test.cxx:70:16: warning: non-static data member initializers only available with -std=c++11 or -std=gnu++11
int Member = 1;
Looking around on the web, I noticed that C++11 is only available after gcc version 4.6.
I checked my version, and it seems to be above.
g++ --version
g++ (Ubuntu 5.4.0-6ubuntu1~16.04.12) 5.4.0 20160609
I understand the -std=c++11 flag is used to enable the C++11 features in g++, but I don't seem to know what I am doing in this case.
I tried editing the CompileFlags.cmake file, but no change occurs.
I came upon this page which points to the cmake source I am using.
It says...
bootstrap: Require compiler mode aware of C++11
Some compilers have enough features enabled in their default modes to
pass our simple C++11 unique_ptr check but do not enable enough to build
CMake. Poison this case so that we choose one of the explicit `-std=`
options for such compilers.
Not sure what that means exactly.
How exactly do I change the g++ mode, to C++11, so that on running the bootstrap command, C++11 is used?
Or, in other words, how do I change std to point to C++11 (-std=c++11)?
First of all, you have g++ version 5.4.0 in your host PC installed, which is good, cause it means this is also supports the C++11, which you want to use.
To set it up, you could define it in your CMakeList.txt file:
set (CMAKE_CXX_STANDARD 11)
that should do the trick.
Please also check the documentation:
https://cmake.org/cmake/help/v3.1/variable/CMAKE_CXX_STANDARD.html
Usually, I would suggest to use the latest standard that you compiler is supporting (https://gcc.gnu.org/projects/cxx-status.html), cause you'll get also the latest features introduced in that standard. Exception for this rather in case you are working with legacy codes.
I am using an inline global variable which works well for the purpose of it.
class MyClass {
public:
void Func() {
}
}
inline MyClass myClass; // global inline variable
Above works well for my purpose but I get a warning when my code compiles on gcc with compiler below C++17. Following is the warning
warning: inline variables are only available with -std=c++1z or
-std=gnu++1z
Question:
How can I suppress the warning on gcc?
I tried to suppress the warning by using a #pragma like below
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wc++17-extensions"
inline MyClass myClass;
#pragma GCC diagnostic pop
Above #pragma technique works on clang, but looks like GCC to not understand the #pragma? I just want to brute force suppress the warning on GCC. How can I do that?
Looks like gcc warning options list does not even mention about this?
https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html
I am using gcc (GCC) 7.3.0
To understand why you cannot suppress this warning, look at what happens if the code is compiled with a compiler that does not support inline variables. (Inline variable support started with gcc 7.) Older versions of gcc process your code and spit out error: 'myClass' declared as an 'inline' variable. Not a warning, but an unsuppressible error. Hard stop; object code not produced.
Newer versions of gcc are able to be more understanding and helpful, but at the same time they have an obligation to maintain some degree of compatibility with older compilers. These newer compilers can recognize this C++17 feature, and it's been determined that ignoring "inline" downgrades the error to a warning (compilation does not necessarily need to stop). Furthermore, the message was given information about how to resolve this situation (assuming the code is correct). At the same time, this warning is still essentially the error produced by older versions of gcc, just given a makeover to make it more user-friendly. It cannot be suppressed any more than the old error could. Your choices are to write valid pre-17 code or to enable C++17 features.
with _GLIBCXX_USE_CXX11_ABI=0
std::function of GCC-4 is different of GCC-5 and follwing versions.
The following code show you the fact:
==> lib.cc <==
#include <functional>
std::function<int(const void*p)> holder;
int run_holder(const void *p)
{
return holder(p);
}
==> main.cc <==
#include <stdio.h>
#include <functional>
extern int run_holder(const void*p);
extern std::function<int(const void*p)> holder;
int foo(const void* p)
{
printf("p=%p\n", p);
return 0;
}
int main()
{
holder = foo;
foo((void*)0x12345678);
holder((void*)0x12345678);
run_holder((void*)0x12345678);
}
==> make.sh <==
#!/bin/bash
GCC4=/usr/bin/g++
GCCN="scl enable devtoolset-5 -- g++"
$GCC4 -std=c++11 -c -g lib.cc -shared -o libfoo.so &&
$GCCN -std=c++11 -L. -lfoo -g main.cc -o a.out &&
LD_LIBRARY_PATH=. ./a.out
expected result, something like:
p=0x12345678
p=0x12345678
p=0x12345678
actual result:
p=0x12345678
./make.sh: line 6: 973 Segmentation fault LD_LIBRARY_PATH=. ./a.out
The reason is the implementation of std::function changes without document.
gcc4: /usr/include/c++/4.8.2/functional:2430
typedef _Res (*_Invoker_type)(const _Any_data&, _ArgTypes...);
gcc5: /opt/rh/devtoolset-4/root/usr/include/c++/5.3.1/functional:2226
gcc8: /opt/rh/devtoolset-8/root/usr/include/c++/8/bits/std_function.h:609
using _Invoker_type = _Res (*)(const _Any_data&, _ArgTypes&&...);
So I can not write a .so using std::function compiled by gcc4 and used by gcc5/6/7/8. There is no macro like _GLIBCXX_USE_CXX11_ABI can control the behavior.
So I can not write a .so using std::function compiled by gcc4 and used by gcc5/6/7/8.
Correct. Neither Red Hat nor the GCC project has ever claimed that's possible, quite the opposite. C++11 support in GCC 4.x was incomplete and unstable, and subject to ABI changes and API changes. What you're trying to do was never supported.
I've explained this in more detail at https://stackoverflow.com/a/49119902/981959
The Developer Toolset documentation covers it too (emphasis mine):
"A compiler in C++11 or C++14 mode is only guaranteed to be compatible with another compiler in C++11 or C++14 mode if they are from the same release series (for example from Red Hat Developer Toolset 6.x).
...
"Using the C++14 language version is supported in Red Hat Developer Toolset when all C++ objects compiled with the respective flag have been built using Red Hat Developer Toolset 6 or later. Objects compiled by the system GCC in its default mode of C++98 are also compatible, but objects compiled with the system GCC in C++11 or C++14 mode are not compatible."
There is no macro like _GLIBCXX_USE_CXX11_ABI can control the behavior.
We do not provide macros to control things that are unsupported and cannot work.
If you want to use C++11 with a mix of GCC versions you need to use a release that has stable, non-experimental support for C++11. So not GCC 4.x.
I have the following code:
#include <ctype.h>
void myfn(void)
{
uint8_t any0 = 'c';
char any1 = 'c';
if (isprint(any0))
{
return;
}
if (isprint(any1))
{
return;
}
}
When I compile it with gcc for arm, I get the following error:
error: array subscript has type 'char' [-Werror=char-subscripts]
if (isprint(any1))
^
If I pass an unit8_t to isprint, the compiler is happy, but not if I pass it a char.
The prototype for isprint is:
int isprint(int c);
It expects an int as parameter, I give it a char.
I would expect it to complain about the type of the parameter, but not something unrelated as 'array subscript'.
The error goes away if I change the call to:
if (isprint((uint8_t)any1))
Is there something I have overlooked?
The compiler I use is:
GNU C (15:4.9.3+svn231177-1) version 4.9.3 20150529 (prerelease) (arm-none-eabi)
compiled by GNU C version 5.2.1 20151129, GMP version 6.1.0, MPFR version 3.1.3, MPC version 1.0.3
warning: MPFR header version 3.1.3 differs from library version 3.1.4.
Commandline options:
'-v' '-fshort-enums' '-specs=nosys.specs' '-specs=nano.specs'
'-mfloat-abi=soft' '-save-temps' '-Werror' '-Wpedantic' '-pedantic-errors' '-mthumb' '-fno-builtin' '-mcpu=cortex-m0' '-Wall' '-std=gnu99' '-ffunction-sections'
'-fdata-sections' '-fomit-frame-pointer' '-mabi=aapcs' '-fno-unroll-loops' '-ffast-math' '-ftree-vectorize' '-Og' '-g'
If I compile the same code with the gcc compiler for AVR /usr/bin/avr-gcc (using similar commandline options and I intentionally added option -Werror=char-subscripts), it doesn't complain about isprint. So it seems to be something related to the ARM compiler.
It turned out that the implementation of isprint for ARM is a macro and, more importantly, header file ctype.h contains the following comment:
These macros are intentionally written in a manner that will trigger
a gcc -Wall warning if the user mistakenly passes a 'char' instead of
an int containing an 'unsigned char'.
For AVR, header file ctype.h contains:
extern int isprint(int __c) __ATTR_CONST__;
This explains the difference in behaviour when compiling for AVR or for ARM.
I cannot make the method to temporarily disable warnings in GCC (see How to disable GCC warnings for a few lines of code) work, at least not for the "unknown-pragmas" warning.
Compiling this code ...
#pragma comment(user,"This should depend on the command line options")
#pragma GCC diagnostic warning "-Wunknown-pragmas"
#pragma comment(user,"This should cause a warning")
#pragma GCC diagnostic error "-Wunknown-pragmas"
#pragma comment(user,"This should cause an error")
#pragma GCC diagnostic ignored "-Wunknown-pragmas"
#pragma comment(user,"This should be ignored")
... produces either no warning/error (except that the linker complais about a missing main), or when using -Wall or just -Wunknown-pragmas it produces one warning for each of the comment pragmas.
The behaviour that I would have expected is that each comment should have caused exactly what the comment says.
I think I can back my expectation with the documentation:
At the moment only warnings (normally controlled by ‘-W...’) can be controlled, and not all of them. Use -fdiagnostics-show-option to determine which diagnostics are controllable and which option controls them.
The warnings I get show as
warning: ignoring #pragma comment [-Wunknown-pragmas]
and as the part in brackets tells us,
this diagnostic is controllable
and the option -Wunknown-pragmas controls it
Hence my code should work.
So what am I doing wrong?
version info:
$ gcc --version
gcc (Ubuntu 5.4.0-6ubuntu1~16.04.11) 5.4.0 20160609
This is a long-standing missing feature in the GCC C++ front end:
C++ preprocessor ignores #pragma GCC diagnostic
Warnings generated by preprocessing cannot be controlled using programs in g++. Unlike the C front end, pragmas are processed only after the preprocessing phase in the C++ front end.