I have the following regex expression:
(.*)[[:space:]]+(.+)[[:space:]]+(Error|Information|Trace)([[:space:]]+[1234567890]+)?([[:space:]]+[ndmptl]{1,6})?
When I try to initialize an std::regex variable with that expression, it intermittently crashes.
Here is some test code:
std::string matchRegex ("(.*)[[:space:]]+(.+)[[:space:]]+(Error|Information|Trace)([[:space:]]+[1234567890]+)?([[:space:]]+[ndmptl]{1,6})?");
std::regex rm (matchRegex); // intermittently crashes on this line
I am using gcc 5.1 on Windows 7 64-bit. In particular, I am using the TDM gcc 64 MinGW flavor of gcc.
The crash only happens when I generate 32-bit code (via the gcc flag -m32).
64-bit code always works.
Is there a bug in the std::regex implementation that might be causing this?
I checked my regex with several online regex checkers and it passed 100% of the time.
Related
For some reason when I try to get the ast-dump of any C/C++ code with Clang, I get an infinite loop which eventually results in clang: error: linker command failed with exit code 1136 or some similar error code.
I'm running Windows 10 with Clang version 13.0 (Also tried Clang 12.0 with same issues). I run the command clang -Xclang -ast-dump filename.c.
I've tried multiple files, but at this point I'm just trying to get a hello world ast (which compiles and runs fine via clang).
#include <stdio.h>
int main()
{
printf("Hello, World!\n");
return 0;
}
I'm sure I'm missing something simple, but I'd appreciate any help, thanks!
It's not an infinite loop if it terminates. :-)
The dumped AST includes stdio.h, which you included, so it's quite big (about 800 lines, when I tried it).
The error message is because the clang compiler (cc1) does not produce an object file when you pass it the -ast-dump option, but the clang driver (clang) doesn't know that. The driver is expecting to be able to link the generated object file into an executable, but it doesn't find the object file so it complains.
Use
clang -Xclang -ast-dump -fsyntax-only filename.c
to terminate the driver after the AST has been dumped.
I'm running a .cpp code where I get some string dependence error
"basic_string.tcc: No such file or directory"
which should come from some compatibility issue. On my MAC machine "clang version 11.0.0" it works but on my linux machine with gcc 6.3.0 its fails. This happens on function
line read_in(std::string filename_begin, std::string fileformat, size_type n_files)
Any idea how to debug this perhaps,
thanks, Damir
I would like to be able to convert text read from a file into multibyte characters.
I have the following C++ code on Windows that is working for me.
When I try to compile the code on Linux though it is failing.
#include <locale>
....
std::wstring_convert<std::codecvt_utf8_utf16<wchar_t>> utfconv;
std::string line;
while (std::getline(infile, line))
{
std::wstring_convert<std::codecvt_utf8_utf16<wchar_t>> utfconv;
std::wstring widestr = utfconv.from_bytes(line);
This throws the following errors:
wstring_convert is not a member of std
codecvt_utf8_utf16 is not a member of std
expected primary-expression before wchar_t
I'm using GCC Red Hat 4.4.7-4.
Based on what I read, I've imported 'locale', but it still can't find it.
If wstring_convert is not available, is there something equivalent that I can do?
Most likely your standard is not set properly. std::wstring_convert was first introduced in C++11 and deprecated in C++17, so you need to add the compiler flag -std=c++11 or -std=c++14.
EDIT:
Just saw the GCC version you're using. It's way out of date. Everything should work fine if you download GCC 4.9.x or above
You will have to use a newer GCC version. Precompiled versions are part of Developer Toolset (available as part of most Red Hat Enterprise Linux subscriptions) or as part of Software Collections for CentOS:
devtoolset-7
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.
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.