standard libraries like or or any other standard headers won't show up on code completion when I changed the compiler settings from gcc to clang. The compiler works but code completion no longer shows up standard libraries. How can I fix this.
Edit::If I changed the compiler back from clang to gcc to clang, it'd work again.
Related
I recently struggle with gcc's optimization, hope to help with performance improvement.
I found the option -freorder-blocks-and-partition.
(This option exist on very old versions of gcc, such as gcc 5.6.)
It can be used to partition cold/hot cold to separate function, together with -ffunction-sections and linker script, cold/hot code can be put into separate ELF sections (.text section and .text.cold section).
But this option only works on recent gcc version.
I test it on gcc 10.1, and use the following compiler exploration tool, make sure it works start from version 8.1:
in gcc8.1: https://godbolt.org/z/hGcnMM, the assembly code contains a function like this:
fa(int, int) [clone .cold.0]:
In gcc7.1: https://godbolt.org/z/rhqjE1, the assembly code does not contain such function.
Why does it not work on older gcc?
And is there any way to control the older version gcc to apply this optimization?
I am working on a project that uses a GCC library (SFML), which is not available for clang, as far as I know. I am using COC with vim for code completions, but for C++ it needs clangd. Is there a way to use GCC as my compiler, but still use the clangd language server?
I have also heard that there may be a way to make clang recognize GCC libraries/headers, but I've never been able to make it work right. If somebody could point me in the right direction there that would be helpfull too. But I'm used to GCC (I've been using it since I started programming C++), so being able to use clangd and GCC would be preferable.
Yes it is. I do it with ccls (which is clang based as well).
Given my installation of clang is not the standard one (I compile it, tune it to use libc++ by default, and I install it somewhere in my personal space) I have to inject paths to header files known by clang but unknown by other clang based tools.
I obtain them with
clang++ -E -xc++ - -Wp,-v < /dev/null
Regarding the other options related to the current project, I make sure to have a compile_commands.json compilation database (generated by CMake, or bear if I have no other choice), and ccls can work from there. I expect clangd to be quite similar in these aspects.
Ops, answered the wrong question.
But for those who use ccls:
create a .ccls file in your project directory and append --gcc-toolchain=/usr to it.
use this tool to generate a compile_commands.json file
see https://github.com/MaskRay/ccls/wiki/FAQ#compiling-with-gcc
I'm attempting to port a large set of modules from AIX to Linux. Unfortunately, the AIX xlc compiler allowed you to define a static function and use it prior to the definition with no prototype. Not good, but at least you get the proper static scope. In any case, the code is there, and I can't get it to compile on Linux without explicitly adding a static prototype.
So, is there any way to inhibit the "static declaration follows non-static declaration" error in gcc (or make it a warning instead of a hard error), or do I have to edit each of these modules to add prototypes wherever they're missing? As I understand it, this is a case where the standard behavior is undefined - so it's kind of nasty if gcc wouldn't allow you a way to relax its internal standard to allow for code that compiles elsewhere, no...?
This has been a hard error in GCC since 2004. The only option to get this to compile is to downgrade to a really old version of GCC. I verified that GCC 3.4.6 still compiles this, but GCC 4.0.3 does not.
Of course, depending on your target, getting GCC 3.4 to work might be close to impossible.
GCC and clang let you compile with -w to disable all warnings, but I can't see a #pragma equivalent of it. I can see only pragma support for disabling individual files.
I need this because I have code that I want to compile with high warning levels but which necessarily compiles third party code which generates arbitrary warnings.
You can kind of do it with GCC, almost, using #pragma GCC diagnostic ignored, but unluckily not very well, see here.
The problem is that you cannot just "disable all", you have to disable each single one. Plus, for some warnings it doesn't work (and the docs don't tell you which ones...).
My guess is that this somewhat preliminary and will (hopefully) be improved in the next version.
I'm trying to migrate a project which uses Boost (particularly boost::thread and boost::asio) to VxWorks.
I can't get boost to compile using the vxworks gnu compiler. I figured that this wasn't going to be an issue as I'd seen patches on the boost trac that purport to make this possible, and since the vxworks compiler is part of the gnu tool chain I should be able to follow the directions in the boost docs for cross compilation.
I'm building on windows for a ppc vxworks.
I changed the user-config.jam file as specified in the boost docs, and used the target-os=linux option to bjam, but bjam appears to hang before it can compile. Closer inspection of the commands issued by bjam (by invoking it using the -n option) reveal that it's trying to compile with boost::thread's win32 files. This can't be right, as vxworks uses pthreads.
My bjam command: .\bjam --with-thread toolset=gcc-ppc target-os=linux gcc-ppc is set in user-config to point to the g++ppc vxworks cross compiler.
What am I doing wrong? I believe I have followed the docs to the letter.
If it's #including win32 headers instead of the pthread ones, there could be a discrepancy between the set of macros your compiler is defining and the macros the boost headers are checking for. I had a problem like that with the smart pointer headers, which in an older version of boost would check for __ppc but my compiler defined __ppc__ (or vice versa, can't remember).
touch empty.cpp
ccppc -dD -E empty.cpp
That will show you what macros are predefined by your compiler.
I never tried to compile boost for VxWorks, since I only needed a few of the headers.
Try also adding
threadapi=pthread
The documentation you mention is for Boost.Build -- which is standalone build tool -- and the above flag is something specific to Boost.Thread library. What do you mean by "hang"? Because Boost libraries are huge, it sometimes take a lot of time to scan dependencies prior to build.
If it actually hangs, can you catch bjam in a debugger and produce a backtrace? Also, log of any output will help.