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
Related
I am trying to compile the boost log library and I keep getting this error from the dump_avx2.cpp file
error: always_inline function '_mm256_set1_epi32' requires target feature 'sse4.2', but would be inlined into function 'dump_data_avx2' that is compiled without support for 'sse4.2'
boost/boost/libs/log/src/dump_avx2.cpp:71:31: note: expanded from macro 'BOOST_LOG_AUX_MM_CONSTANTS'
const __m256i mm_char_0 = _mm256_set1_epi32(0x30303030);\
^
I get a lot of errors that are very similar to the one above, all of them have the same error message but different locations in the file where they occur, for reference I am on the commit hash 68701167a1020b0b4c47b76e31d3a3da9e2faf3f for the Boost.Log submodule as fetched from the github repo (https://github.com/boostorg/boost)
Does anyone know how I can go about resolving this issue? I am building with a C++14 compiler and this is what I get when I type g++ --version
Apple LLVM version 8.0.0 (clang-800.0.42.1)
Thanks!
Note I should clarify that in this context it is required that I compile this library separately.
Note There seem to be two related source files dump_ssse3.cpp and the mentioned dump_avx2.cpp file, do I have to compile only one of them? I cannot make out what to do from the Jamfile in the build folder :(
That looks like a bug in clang (LLVM). First, the intrinsic belongs to AVX2, not SSE4.2. Second, the whole dump_avx2.cpp file is compiled with -mavx2, so the required extensions are enabled. You can see the compiler switches in the error message from b2. And no, both dump_ssse3.cpp and dump_avx2.cpp should be compiled. The library does runtime detection of the available instructions in the CPU and selects the proper implementation.
I have a project that uses OpenMP (which doesn't seem to be available in the current OS X default clang setup) but would also like to use LTO. I have sections of the code in SIMD intrinsics using SSE4 and found that G++ was unable to link this code without using the OS X provided clang linker (flag -Wa,-q). G++ 5.10 is installed via Homebrew and compiled with without multilib.
I can compile with LTO using clang but then I lose the parallel 'for's, when I add -flto to G++ I get:
lto1: internal compiler error: in add_symbol_to_partition_1, at lto/lto-partition.c:211
lto1: internal compiler error: Abort trap: 6
g++-5: internal compiler error: Abort trap: 6 (program lto1)
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://github.com/Homebrew/homebrew/issues> for instructions.
lto-wrapper: fatal error: g++-5 returned 4 exit status
compilation terminated.
collect2: fatal error: lto-wrapper returned 1 exit status
compilation terminated.
This also occurs without -Wa,-q if I remove the intrinsics so that it can compile the remaining code.
I have tried a simple two file program that compiles fine with LTO in G++ so I'm not sure what the problem is. Whilst LTO doesn't seem to make a huge amount of difference to this code, in clang I've measured about 7% which is non-negligible as the program takes a while to run.
I know the error says to submit a bug report but I don't want to unless I know it's not just my own stupidity.
Does anyone have experience of this sort of problem, or have I actually run into a compiler bug? (haven't come across one before to my knowledge)
Cheers!
Compilers are never supposed to report ICEs. It's a bug. It may already be a reported bug, but it is most certainly a bug.
I am currently in the process of switching compilers.
From microtech to GNU GCC/G++ coldfire..
I keep receiving the following error and can not find a simple solution:
warning: ANSI C++ forbids declaration `interrupt' with no type
I know the line that it is failing on:
friend interrupt void IrqCtmMCSM2(void);
Could someone offer suggestions please?
Thanks for your time.
It's a simple question really, and refers to Linux (as opposed to Windows or Mac).
How do you generate a warning message from the C or C++ compiler that must have the word 'suspicious' in it, and must refer to (-Wmain).
(update)
Thanks Boann - I got some of those Warnings, but I also got Error - error: ‘::main’ must return ‘int’.
The reason I'm asking this question is that a week ago my compiler (GCC 4.8.1) came out with this warning saying 'suspicious' and that it was caused by Wmain. So I put -Wno-main and the warning went away and it compiled fine. Just recently it has started complaining making it an actual Error and not compiling. So I'm kind of worried that somehow the mother ship has covertly updated my compiler over the internet, without me knowing, and changed it to treat it as error. (I was probably using 'int4' as the return type which I forever have typedef'd as signed long int.
I note there's -Wmain referenced in g++ man page so it must be for something, but what warning is there that isn't overruled by an error??
At offset 557284 (decimal) of the g++ executable I found "Warn about suspicious declarations of "main".
For what it's worth,
struct suspicious {};
int main(suspicious) {}
Output with g++ -Wall, GCC 4.8.2:
warning: first argument of 'int main(suspicious)' should be 'int' [-Wmain]
If you refer to the -Wmain parameter of GCC, you get the warning by giving main odd arguments, an odd return type, or giving it static linkage. This will do it:
static float main(float x) {
return 0;
}
Compiled with gcc -Wmain, it displays these warnings; they do not actually contain the word 'suspicious' though:
warning: return type of 'main' is not 'int'
warning: first argument of 'main' should be 'int'
warning: 'main' takes only zero or two arguments
warning: 'main' is normally a non-static function
I just downloaded the sources for gcc 4.8.1 and searched all relevant files for the word "suspicious".
There are a number of occurrences, but as far as I can tell, there's no way an error message for a C or C++ source file can contain the word "suspicious". It's possible but unlikely that there was a local modification.
Is it possible that you're mistaken about what the error message said? If you have a log containing the error message, please update your question to show the exact message your received.
If you're concerned that your compiler may have been updated without your knowledge, you might check the timestamp of the compiler executable and of any programs it invokes (use gcc -v to check that). But gcc itself doesn't automatically update itself. If you're using it on a system administered by someone else, automatic updates are to be expected. If you administer the system yourself, you may have configured it to update software without manual intervention; if so, that's not a gcc issue. I don't know what "mother ship" you're referring to.
I am trying to compile a c++ program in Linux, using the command in the shell
$ g++ -Wall *.cpp -o prog
and for some reason it keeps on giving me a weird error:
g++: Internal error: Bus error (program cc1plus) Please submit a full
bug report. See for
instructions.
I searched the net for this bus error, and it says that it has to do with something about accessing illegal memory.
Can someone maybe clarify things a bit more for me?
This error message is telling you that there's a bug in the g++ compiler itself.
Try to narrow it down by removing bits and pieces of your source file until the problem goes away. You're not trying to fix your program, you're just trying to find the part that is breaking the compiler. Once you've found it, you can either give a better bug description or you can change your code to work around it.
Or just download the latest version of the g++ compiler and hope that it's already fixed.
Your problem is not in your code, is the compiler (g++) that is crashing and producing that Bus Error, it's possible you have an outdated version of such compiler and need to update, or you're lucky and found a real bug in g++.
I would try compiling each source file separately, to check what part of the source code triggers the error.