The built in atomic operations were introduced in gcc-4.1.2. However, I am using gcc on OpenIndiana which only has gcc 3.4.3. Now my question is how to use atomic operations in gcc 3.4.3? Moreover I have tried to use gcc 4.6.1 in OpenIndiana but it doesnt work, as it complains about some runtime libraries. If anyone has successfully used it, kindly let me know.
I would suggest you to upgrade your GCC compiler. A GCC 3 is an ancient thing.
If you cannot install a newer version of GCC, you should try compiling a GCC 4.6.1 compiler from its source code. (don't forget to compile it in a build tree outside of the source tree, and don't forget all the dependencies).
You did not mention or explained why your compilation of GCC 4.6.1 failed. What runtime libraries did it complain about? Did you run ldconfig after installing it?
GCC has great inline assembly support, so you could just use __asm to make your own variant of the various atomic ops. It'll be specific to your target platform however, so you'll need some good macros to switch to the right versions.
To add to existing answers - have you looked at Spec Files Extra Repository? I never used it myself but it seems like it offers gcc 4.6 compiler package.
On Solaris, the alternative could be to fall back to libc atomic_ops(3C) interfaces. These might or might not get inlined, but they're guaranteed always available (and always behave in the same way) no matter which compiler you use.
Beyond that, I second the suggestion to either upgrade your gcc, and/or to get the SunStudio 12.2 compilers (they're royalty-free; even if you only use it for testing, code quality tends to go up if it's made to work with more than one compiler ...). Yes, it'll install/run on OpenSolaris-based distributions as well.
Related
So Microsoft's MSVC from Visual Studio 2019 doesn't support C99 (or later), but it does support C89 and some constructs from C99.
Is there an option for the GCC C-compiler (not C++-compiler) to use a standard that would guarantee that the source can also be compiled with MSVC? If it compiles with -std=iso9899:199409 -pedantic under GCC, can MSVC compile it?
Is there a reason you need to care if MSVC can compile it? GCC ("mingw") can target Windows PE object files with ABI compatible with MSVC, so users could build with that, or you could even ship them binary object files/library files to use so they don't need any tooling.
Policing your code base for compatibility with a known-broken/intentionally-broken compiler does not seem like a worthwhile activity unless you actually have reason to want to use that compiler, rather than just allowing users of that compiler to link with your code.
Pretty much the only way to you can ensure it builds with MSVC and GCC is to build the code with both toolsets. In addition to language constructs, there are a number of differences in the handling of compiler-defined preprocessor symbols, differences in what the preprocessor can handle, etc.
Personally I've been doing a lot of work getting C++ code to build with MSVC and Clang, and I've hit many minor issues that have to be fixed to get things to build with both toolsets. The C/C++ language standards help make the code portable, but you still have to run it through more than one toolset to get it to build 'cleanly'.
If you want your code to be robustly portable you also should build it for multiple architectures.
For my GitHub libraries, I build for ARM, ARM64, x86, x64 on MSVC, VS 2015 Update 3/VS 2017/VS 2019, targeting Win32 desktop, UWP, and Xbox One. I also build with clang for Windows for x86 and x64. Each one finds slightly different issues, but the end result is a lot more portable.
I want to use clang on Windows to compile C code.
I'd like to know if it is in fact a standalone compiler that can do that, or are its aims somewhat different?
I've used it before, but it appears now that is was piggy-backing on top of whatever gcc compilers were lying around (mingw for example).
If I try a fresh binary installation of clang 64-bits (and I hide my mingw/gcc directories), then it can't find stdio.h for Hello World. This is running from directly inside the bin directory (C:\clang\bin). If I unhide mingw, it will compile, but then I get errors like this (one mingw compiler is in c:\win):
c:\win\bin\ld.exe cannot find -lgcc_s
Considering clang is a 438MB installation, you'd think it would have it's own include and library files! I want to use clang in place of gcc.
So, what am I doing wrong? (I've seen a few questions also about the inability to find stdio.h, but they weren't helpful. Surely clang must be able to compile Hello World by itself?!)
You are confusing compiler with linker with standard library.
Clang is a full featured independent compiler. But it does not provides the standard library (the library containing stdio.h). Traditionally, on Unix systems, the operating systems must provide the standard library it uses. But since you are using Windows, it doesn't, and for whatever reason it finds the ones from MingW installed. There are many free implementations of C standard library which are compatible with Clang.
Lastly, ld.exe is the linker, and it also, traditionally, must be provided by the system. There is one linker, lld, that I believe is being developed alongside Clang, but for whatever reason, the packager of the version you downloaded just chose to configure clang to simply call ld.
Clang is a completely separate compiler (written entirely from scratch, using LLVM). You don't need GCC to use Clang, as can be shown in the case of FreeBSD (they completely replaced GCC with Clang/LLVM and don't install GCC in the base anymore for licensing reasons). There are a variety of different C compilers other than GCC, it's just that GCC is the most common.
However, no compiler provides the standard C libraries (GCC provides some weird libraries like the one you're trying to use). C libraries are provided separately, and you need to install C libraries in order to compile any significant C program. The error message saying cannot find -lgcc_s tells me that you're trying to link against some library provided by GCC. In this case, you probably want to install that library by installing GCC (but note that you don't need GCC to use Clang.
It does appear that your version of Clang has been compiled to use GNU's linked ld, not LLVM's linked lld. As such, you'll need GCC's linker (or you can recompile clang to use LLVM's linker, or just compile the object files and use lld separately).
I think you are missing a path variable. After install you must manually add a PATH to the Windows Environment.
I heard that GCC actually assumes registers, and requires CPU to have them to work.
What work should be done to remove this dependency, and port GCC to some register-less non-Von Neuman arch, like Multiclet?
Did somebody tried this? Is there some project and experience one can use if wants to work on this ?
If not, is there some other FOSS compiler that can be ported to something like Multiclet. LLVM has pretty much the same requirements like GCC, and it is unsuitable for me since I don't know C++. So it needs to be plain C. I hear that GCC is also adding C++ code now. But I can use some older version as starting point.
Multiclet's C99 compiler is not closed source. Sources are available at their community suite. One may google it by name 'multiclet mcc lime'.
I am trying to use SSE4.2 intrinsics with clang/llvm but its not compiling, as I get cannot select intrinsic error from LLVM. On the other hand, the same code compiles flawlessly in gcc. So I thought, maybe I can compile that function with gcc, so as to have an object or library file, and then call that library function in my code, which is compiled by clang/llvm. Would that work?
It's possible to compile an object file with GCC in Linux and convert it to work in Visual Studio. I did this recently running Linux in Virtual Box on Windows converting-c-object-file-from-linux-o-to-windows-obj so this should be possible with Clang on Linux or Windows as well.
So not only can this be done cross compiler it can be done cross platform.
You need to get the calling conventions and the object file format correct (and for C++ the name mangling as well) . With GCC when you compile you can tell it which calling convention/API to use with mabi. Then, if going from Linux to Windows, you need an object file converter to convert from e.g. ELF on Linux to COFF on Windows. Of course, there are cases this probably won't work (e.g. if the module relies on a system call that is only in one platform). See the link above for more details.
For any more-or-less complicated c++ code, e.g., one that compiles to vtable - the answer is a resounding NO. The two are NOT compatible.
To illustrate the above point, try to compile the Crypto++ library with g++ (gains about 40% speedup for AES/GCM) and then link your clang++-compiled code with it.
It may or it may not work. Some elements of the ABI can be expected to be the same. For example, I believe both g++ and clang use the Itanium ABI name mangling scheme. Others elements can not. So it depends on how complex the code you're compiling is.
Also, I would suggest opening an LLVM bug for the intrinsic that could not be selected. Clang and LLVM have a very active community, and it's possible someone will pick the bug up quickly.
The product-group I work for is currently using gcc 3.4.6 (we know it is ancient) for a large low-level c-code base, and want to upgrade to a later version. We have seen performance benefits testing different versions of gcc 4.x on all hardware platforms we tested it on. We are however very scared of c-compiler bugs (for a good reason historically), and wonder if anyone has insight to which version we should upgrade to.
Are people using 4.3.2 for large code-bases and feel that it works fine?
The best quality control for gcc is the linux kernel. GCC is the compiler of choice for basically all major open source C/C++ programs. A released GCC, especially one like 4.3.X, which is in major linux distros, should be pretty good.
GCC 4.3 also has better support for optimizations on newer cpus.
When I migrated a project from GCC 3 to GCC 4 I ran several tests to ensure that behavior was the same before and after. Can you just run a run a set of (hopefully automated) tests to confirm the correct behavior? After all, you want the "correct" behavior, not necessarily the GCC 3 behavior.
I don't have a specific version for you, but why not have a 4.X and 3.4.6 installed? Then you could try and keep the code compiling on both versions, and if you run across a show-stopping bug in 4, you have an exit policy.
Use the latest one, but hunt down and understand each and every warning -Wall gives. For extra fun, there are more warning flags to frob. You do have an extensive suite of regression (and other) tests, run them all and check them.
GCC (particularly C++, but also C) has changed quite a bit. It does much better code analysis and optimization, and does handle code that turns out to invoke undefined bahaviiour differently. So code that "worked fine" but really did rely on some particular interpretation of invalid constructions will probably break. Hopefully making the compiler emit a warning or error, but no guarantee of such luck.
If you are interested in OpenMP then you will need to move to gcc 4.2 or greater. We are using 4.2.2 on a code base of around 5M lines and are not having any problems with it.
I can't say anything about 4.3.2, but my laptop is a Gentoo Linux system built with GCC 4.3.{0,1} (depending on when each package was built), and I haven't seen any problems. This is mostly just standard desktop use, though. If you have any weird code, your mileage may vary.