Earliest support of __alignof__ in GCC - c++

I need a portable way to determine alignment requirements of a structure, where portability includes legacy versions of GCC. Parts of project are stuck with embedded platforms supporting pre-C++11 standard only, as early as GCC v.3.6.
There is a non-ISO __alignof__ (a macro? a function?) analog of C++11 operator alignof which I can use, but what is the earliest version of GCC compiler would support it? Were there alternatives or changes in naming?

The oldest version of GCC with documentation available online at gcc.gnu.org is 2.95.3. That version does support __alignof__ extension.

Related

Is compiler language support common to all compiler ports

I'm using GNU Arm Embedded Toolchain 10-2020-q4-major (arm-none-eabi-* 10.2.1) and I would like to take advantage of modern c++ features.
So I'm trying to find out which c++ features (language core features as well as libstdc++ features) are available with this particular toolchain. I read through this matrix https://gcc.gnu.org/projects/cxx-status.html, and they don't seem to distinguish between different compiler ports.
How could I find if I could use C++17 or C++20 features for example ?
Regards,
Hugo
As you can see on the gcc.gnu site you listed, all of the C++17 and C++20 features are listed. The "Available in GCC?" specifies which version of the GCC compiler is required to have a given feature available. It is essentially not your toolchain, but the compiler (as part of that tool chain) that defines your feature set.
In your given case, that you are using a GCC compiler for arm-non-eabi architecture, does not change this feature set, the version of the compiler does. So, with your arm-non-eabi-g++-10.2.1 you should have all the features for that compiler version available.

Are extensions for parallelism going to be available for the new C++17 Standard?

First of all, C++17 changes are listed in this post. Today I downloaded clang to check if it was complete for C++17 (as gcc hasn't implemented everything yet), and here you can read:
Clang 5 and later implement all the features of the C++ 2017 Draft International Standard.
You can use Clang in C++17 mode with the -std=c++17 option (use -std=c++1z in Clang 4 and earlier).
Then, I assume that all features of C++17 have been added in clang 5.0, but checking all of them, I couldn't find the extensions for parallelism of stl algorithms and so on. I tried adding the header <execution> to test the new feature, but nothing seems to work.
I'm suspencting that this feature "maybe" won't be available, but I'm not sure because there's almost no information about it.
I think Intel implemented something in its compiler, but I'm not really into it since I use Linux.
Are extensions for parallelism going to be available for the new C++17 Standard?
Yes, extensions for parallelism have been merged into the ISO C++ Standard.
Clang 5 and later implement all the features of the C++ 2017 Draft International Standard.
This seems to refer only to core language features. You probably want to check the libc++ and/or libstdc++ conformance status instead.
https://libcxx.llvm.org/cxx1z_status.html
https://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html
In the above links, P0024 is not marked as implemented.

Is there a GSL implementation I can use with GCC 4.9.x?

Microsoft's (Core) Guidelines Support Library implementation is said to support GCC 5.1 - but does not specify support for other versions. Higher versions seem to be ok (anyway, 5.3.1 on my Debian Stretch) - but building the tests with GCC 4.9.3 fails.
Has anybody else implemented the GSL?
Can I use MS GSL anyway, somehow?
If not, can I use some safe subset of it? (Probably not, I know)
If not, isn't it a problem that only people with newer compilers can have a guidelines support libraries? Even though their older compilers support C++11 or even C++14?
Yes, there is one I know of: gsl-lite.
It worked fine for me so far. But I changed my compiler to a newer version and did not need it anymore.
You can also use (a rather small) subset of Microsofts implementation. If you do not need the span-classes. These are gsl_assert.h (Expects, Ensures) and gsl_utils.h (narrow, final_act, ...). I think I might have adjusted just some constexpr related things.

C++14 support in GCC is experimental

Quoting from the GCC page on C++14 support
Important: Because the final ISO C++14 standard was only recently published, GCC's support is experimental. No attempt will be made to maintain backward compatibility with implementations of C++14 features that do not reflect the final standard.
I could not find the official GCC definition of experimental. Does it only apply to backward compatibility wrt non-standard features, as the last sentence mentions? Or does it also indicate stability, or lack thereof? An earlier sentence on the same page says
C++14 features are available as part of the "mainline" GCC compiler in the trunk of GCC's Subversion repository and in GCC 4.8 and later.
To me, this suggests stability. Is this the case? In particular, my question is about GCC 4.9, since that is the earliest version with full C++14 support, according to the aforementioned page.
There is no "official GCC definition", only the official English definition.
The passage means that, where GCC previously implemented experimental prototypes of then-upcoming C++14 features before C++14 was published, future versions will not bother to try to maintain backward compatibility with those experiments.
Backward compatibility between two versions is only maintained with respect to features that were in an International Standard at the time that they were included in those versions.
This is because, prior to standard publication, the specification of new C++ features can change rather dramatically. It would be madness to guarantee that early experiments in support for them would be forwards compatible with the final, true feature as eventually published in a standard.
In short: use experimental features at your own risk and do not expect them to work the same way in the next version of GCC.

Which gcc version is needed to use unordered_map from C++11?

I am currently on RHEL 5.4 with gcc 4.1 installed, but I want to use unordered_map. As I found out, this is only introduced in C++11 to the standard, and therefore not available. One alternative would be using __gnu_cxx::hash_map, but I would prefer using standards.
On another development host I happend to have RHEL 6.4 and gcc 4.4, which knows unordered_map, but gives the following warning:
../include/c++/4.4.7/c++0x_warning.h:31:2: error: #error This file requires compiler and library support for the upcoming ISO C++ standard, C++0x. This support is currently experimental, and must be enabled with the -std=c++0x or -std=gnu++0x compiler options.
From the gcc homepage I can't seem to find out which gcc version supports unordered_map.
[edit]
To clarify my question:
I am stuck to several operating systems and their versions by customer requirements, therefore I cannot always update to the latest GCC version and be happy. I need to maintain compatibility of my software across all platforms.
I am therefore searching for the minimum GCC version required to use unordered_map. I am aware of the fact that supplying -std=c++0x to GCC fixes the error above, but I dont know how far the "experimental" warning means I should not be using unordered_map.
Some guys in this thread strongly advise not to use this experimental C++11 implementation
... so what should I do?
You cannot find such information on the GCC page. There is information about library features, but only about current version of GCC. In your GCC 4.4, you can simply use -std=c++0x flag to remove the warning.
If you are scared about experimental and cannot update the compiler - just don't use unordered_map from C++11. You can write your own, use one from tr1, or use the one from boost, no matter.
If you just look at GCC site - there is message there:
Important: GCC's support for C++11 is still experimental. Some
features were implemented based on early proposals, and no attempt
will be made to maintain backward compatibility when they are updated
to match the final C++11 standard.
By the way, all features of the C++11 standard are realized in GCC, it's actually old standard, since now C++14 is already approved, but support is still expiremental.
I have no idea WHY it's still experimental, for example on clang site:
Clang fully implements all published ISO C++ standards including
C++11, as well as the upcoming C++14 standard, and some parts of the
fledgling C++1z standard, and is considered a production-quality C++
compiler.
And only C++1z support is experimental.
You should upgrade to gcc 4.9.2, if you can. Otherwise use gcc 4.4. They'll both need the -std=c++0x option.