On Tue, 6 Sep 2016, Bernd Edlinger wrote: > I think that for _Float128 to become a fundamental data type, > it is *not* sufficient that gcc supports it alone, because glibc > needs to support also all the necessary math library functions.
No, the definition of basic types for a freestanding implementation is nothing to do with whether some library facilities are available. (And, in any case, the same issue applies for _Decimal128, for which the library facilities have been available in libdfp for many years.) Nor is there any reason for increases in malloc alignment in glibc to depend on other changes. > I have some doubt that it will work to change max_align_t's > alignment only based on the gcc version, I mean > there should be a way to allow the max_align_t keep at > 8 bytes if the existing glibc will not support 16 bytes. max_align_t depending on the glibc version would be worse than a simple one-off change. > macro, what the real malloc alignment will be. And probably > some builtin-macro, if gcc supports __float128, independently > of the i386, that could probably also be helpful for writing > portable applications. I expect in future portable applications to use _Float128, for which FLT128* macros in <float.h> (or the corresponding built-in macros) can be used. That doesn't allow for C++, but hopefully WG21 will decide at some point how best to support such types in C++ (maybe closer to how DFP is handled for C++). -- Joseph S. Myers jos...@codesourcery.com
