I have a struct that is declared on the stack. Here is what the struct looks like:
struct MyStruct {
int integer;
std::vector<bool > booleanVector;
};
When I step through the following function with gdb, printing the value of s.integer and s.booleanVector.size(), the statements seem to have no effect.
MyStruct getMyStruct()
{
MyStruct s;
s.integer = 3;
s.booleanVector.resize( s.integer );
return s;
}
However, when I insert print statements such as std::cout << s.integer << std::endl; the output shows that the values of s.integer and s.booleanVector.size() have been properly changed.
I discovered that the problem seems to be associated with the struct being returned by the function in which it is declared. The problem with gdb displaying invalid information about the struct does not occur if it is not being returned by the function in which it is declared.
This is a simplified example that exhibits a problem I had while attempting to debug a project. This problem with gdb was distracting me from an actual error in my code and making it difficult to find (originally I thought the problem might be a subtle bug in my code, which is why I posted it here). Here is a complete small program that exhibits this behaviour on my system.
I guess my question is if this is just a bug with gdb or does this behaviour occur as a result of how gcc handles structs / classes that are to be returned from a function.
Note: Using gdb 6.3 with gcc 4.2 in Mac OSX 10.6 (Snow Leopard)
This was a bug in GCC (see link below).
This also happens while using the following GDB version:
i686-apple-darwin9-g++-4.0.1 (GCC) 4.0.1 (Apple Inc. build 5493)
Copyright (C) 2005 Free Software Foundation, Inc.
... and even when compiling with -O0
Here is the link to the full bug tracker on the GCC project:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44731
The programs produced are correctly-running programs. The problem was entirely related to optimizations having an effect even with the build set as 'zero optimizations,' and to improper debug info placed into the binary by gcc.
This debugging issue is fixed by upgrading to a more recent version of gcc. When the code is compiled with gcc 4.7, gdb displays correct information about the struct.
Related
Moving from using Intel compiler & VC to Apple clang 12.0.
In my code there are functions that are never called for a certain project (but needed when included in other projects). Clang insists on compiling the uncalled functions and detects errors, where Intel and VC simply skipped compilation.
These are errors that are tricky to fix for that certain project.
Is there a Clang flag that means "Don't compile if not called"?
EDIT: example:
template <class T> class A
{
public:
void foo() { garbage }; // <--- syntax error
};
int main() {
A<int> my_obj;
//my_obj.foo(); // <--- when unremarked, will fail all compilers
}
Compiler Explorer demo: Intel vs. Clang
Intel and VC compilers are relaxed until the call to foo() enters the scene.
Clang has a mode in which is tries to behave as if it's MSVC. This was introduced as part clang-cl, the driver for clang that accepts a lot of the same arguments as MSVC. You can find some information about it on the user manual and the MSVC compatibility pages.
Long story short, there is an option -fdelayed-template-parsing in clang that takes over the faulty behavior of the templates. As far as I'm aware, this ain't a 100% match, however, it is good enough.
If we add this to the example of Artyer, it compiles the code, see compiler-explorer.
From my experience of adding clang as 2nd compiler next to MSVC (it was still both on Windows using clang-cl, I didn't have to deal with the complexity of multiple OS and/or STL), I want to recommend to you to take this option as a temporary thing to get things working. Take your time removing this, as it will help making your code more maintainable.
EDIT: If you want to know more about why the compilation error is the right thing to do, you can lookup the term 2 phase lookup. You can find the announcement of it's introduction in the MSVC compiler here: https://devblogs.microsoft.com/cppblog/two-phase-name-lookup-support-comes-to-msvc/
From what I can see online, the intel compiler ain't doing 2 phase lookup either, or at least not the reporting of the errors.
I have an existing application, which uses several static libraries (all of which I am compiling). I am compiling on the command line, with make and clang, not using the IDE. Previous to Xcode 7.3, all compiled and executed as I expect. With Xcode 7.3, in my release build (which adds -O2) I am getting strange behaviour with virtual inline functions - sometimes they return completely garbage values. This seems to happen in classes which have only virtual inline methods, eg:
class MyClass
{
public:
virtual ~MyClass() { }
virtual int foo() { return 1; }
};
In my investigation of the issue (trying several related compile flags), it appears adding -fno-inlines and/or -fvisibility-inlines-hidden works around the issue, and the program executes as expected. However, from my understanding, these are simply hints on how to optimize, and should not affect program execution (specifically, the second should only affect DSOs, which I am not using). This leads me to several questions:
Searching Apple support forums, I could not find any reference to similar errors. Is this an known issue?
Is this code somehow malformed? If so, is there some way I can get feedback from the compiler (eg. via a diagnostic) about the problem?
Why do the compiler flags I mentioned fix the issue? Am I misinterpreting their meaning?
Related to problem 16611678 I need a new version of gdb in my centos 6.5 64.
I try to compile GDB (7.7, 7.6.2 and 7.5), without success, the error is related to get_tty_state() in ser-unix.c:
ser-unix.c:118:1: error: conflicting types for ‘get_tty_state’
My gcc version is 4.8.2
Before the function declaration there is preprocessor directives for defining hardwire_ttystate if HAVE_TERMIOS is defined and I think the problem come from here (if needed I can post the piece of code), as HAVE_TERMIOS is undefined.
Any help would be appreciated!
Nathanaël
After following the steps in this post I managed to make Eclipse (Indigo) recognize unique_ptr (and other C++11 new stuff). The problem is that operator-> for unique_ptr seems not to be supported in Eclipse. Here you have an example:
class Foo { void bar() { /* ... */ } };
std::unique_ptr<Foo> foo;
(*foo).bar(); // 1
foo->bar(); // 2
Case 1 works as expected: there is no error and autocompletion works. For case 2, however, Eclipse marks the statement with an error ("Method 'bar' could not be resolved"), plus autocompletion from foo-> does not work.
Most interestingly, I do not have any problems with std::shared_ptr. It only happens for std::unique_ptr.
Has anyone experienced the same problem? Does anyone know a way to fix it?
EDIT: just for clarifying purposes, the compilation process goes fine for the code snippet shown above. So, the problem is not in the compiler itself, but on Eclipse.
I have finally found a bug report in CDT describing the very same problem that I am suffering. So far, there is not a real fix for the problem but there is a workaround explained in that bug report:
Yes, GCC 4.5 is the latest GCC version whose library headers can be accurately
indexed by CDT. The main reason for failing to index 4.6 headers is CDT's lack
of support for 'constexpr' and 'nullptr', which are used extensively in the 4.6
headers (any chance of that being implemented for Juno, by the way?).
I have worked around this by having both GCC 4.5 and 4.6 installed on my
system, and pointing CDT to 4.5's headers (by setting the compiler invocation
command to 'g++-4.5' in Discovery Options) while actually compiling with 4.6.
This issue has been recently fixed, in cdt 8.1.1. Just go help->check for updates and it will be downloaded and installed. I've tested unique_ptr and it is properly indexed.
The following code crashes for me using GCC to build for ARM:
#include <vector>
using namespace std;
void foo(vector<bool>& bools) {
bools.push_back(true);
}
int main(int argc, char** argv) {
vector<bool> bools;
bool b = false;
bools.push_back(b);
}
My compiler is: arm_v5t_le-gcc (GCC) 3.4.3 (MontaVista 3.4.3-25.0.30.0501131 2005-07-23). The crash doesn't occur when building for debug, but occurs with optimizations set to -O2.
Yes, the foo function is necessary to reproduce the issue. This was very confusing at first, but I've discovered that the crash only happens when the push_back call isn't inlined. If GCC notices that the push_back method is called more than once, it won't inline it in each location. For example, I can also reproduce the crash by calling push_back twice inside of main. If you make foo static, then gcc can tell it is never called and will optimize it out, resulting in push_back getting inlined into main, resulting in the crash not occurring.
I've tried this on x86 with gcc 4.3.3, and it appears the issue is fixed for that version.
So, my questions are:
Has anyone else run into this? Perhaps there are some compiler flags I can pass in to prevent it.
Is this a bug with gcc's code generation, or is it a bug in the stl implementation (bits/stl_bvector.h)? (I plan on testing this out myself when I get the time)
If it is a problem with the compiler, is upgrading to 4.3.3 what fixes it, or is it switching to x86 from arm?
Incidentally, most other vector<bool> methods seem to work. And yes, I know that using vector<bool> isn't the best option in the world.
Can you build your own toolchain with gcc 3.4.6 and Montavista's patches? 3.4.6 is the last release of the 3.x line.
I can append some instructions for how to build an ARM cross-compiler from GCC sources if you want. I have to do it all the time, since nobody does prebuilt toolchains for Mac OS X.
I'd be really surprised if this is broken for ARM in gcc 4.x. But the only way to test is if you or someone else can try this out on an ARM-targeting gcc 4.x.
Upgrading to GCC 4 is a safe bet. Its code generation backend replaces the old RTL (Register Transfer Language) representation with SSA (Static Single Assignment). This change allowed a significant rewrite of the optimizer.