Re: Request for clarification on the 128bit long double requirments
Roland McGrath wrote: >>* If GCC 4.1.0 does not support the new ABI, but GCC 4.1.1 does support >>that, would it be possible to activate the support on the GLIBC 2.4 branch? > > This is not an option. When glibc 2.4 is released, the GLIBC_2.4 version > set will never change again. Each platform will either change by the first > 2.4 release, or it will not change until the next ABI-changing release > (presumably 2.5, and not especially soon). Thanks for the clarification and explanation. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: Request for clarification on the 128bit long double requirments
> * If GCC 4.1.0 does not support the new ABI, but GCC 4.1.1 does support > that, would it be possible to activate the support on the GLIBC 2.4 branch? This is not an option. When glibc 2.4 is released, the GLIBC_2.4 version set will never change again. Each platform will either change by the first 2.4 release, or it will not change until the next ABI-changing release (presumably 2.5, and not especially soon). > Given that the GLIBC with the support is fully backwards-compatible with > older GLIBCs, it seems that it would be possible to enable the support > later on the GLIBC 2.4 branch, when compilers that can support the > feature become available. The glibc sources are not the issue. The ABI is the issue. It is easy to make changes at any time that change the ABI, as far as glibc itself is concerned. But every time we change the glibc ABI at all, it is a significant burden on all system makers and by extension on all users. To merely remain backwards compatible with existing binaries, we can define replacement symbols in a newer version set. To do this without muddying the waters terribly for distribution tools and for users, we cannot add anything to a version set that existed in any past releases, but must add a new version set every time the ABI expands to include new versions of some symbols. This is the only way we ever make ABI additions, and the package tools understand it correctly. Even with perfectly well-ordered glibc ABI changes, the mere fact of a change and the introduction of a new version set, is a significant burden on system makers, software binary purveyors for glibc-based systems, and users. (If you are tempted to chip away at the general case I'm describing here, with "but it only affects programs using long double", note that the ABI change moves printf to the new version set on affected platforms.) Any such change means that newly built binaries may require a glibc with the new version set, and thus cannot be installed on any installation of existing OS versions based on glibc 2.4, that have not been upgraded with the new ABI support. For these reasons, the deployment of any new glibc version set is a big deal for everyone concerned with the platform. Thus we have a rather large granularity; 2.4 will be well over a year since the previous glibc ABI was frozen. System makers will stay on one glibc ABI for a long time, it will form the basis of the next round of ABI standards like LSB's, etc. Thanks, Roland
Re: Request for clarification on the 128bit long double requirments
Roland McGrath wrote: > I told those maintainers that glibc 2.4 would not support a new long double > ABI for each platform unless GCC 4.1 as released could compile that glibc. > The glibc sources make it easy enough to switch a platform down the line > (for the glibc 2.5 ABI, whenever that next release period comes along). Thanks for the explanation. To clarify this statement: * If GCC 4.1.0 does not support the new ABI, but GCC 4.1.1 does support that, would it be possible to activate the support on the GLIBC 2.4 branch? * If GCC 4.1.x does not support the new ABI, but some later GCC does, will it be possible to either (a) activate the support on the GLIBC 2.4 branch, or (b) add it to the then-current development mainline for GLIBC? (I assume the answer to "b" is "yes", from the above, but I want to clarify because I'd hear that this was a now-or-never change in GLIBC.) Given that the GLIBC with the support is fully backwards-compatible with older GLIBCs, it seems that it would be possible to enable the support later on the GLIBC 2.4 branch, when compilers that can support the feature become available. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: Request for clarification on the 128bit long double requirments
I hope I can clarify the situation. Planning and communication surely
could have been much better, and as the person who coordinated the efforts
that were made, I can be blamed for what we did and when we did it. glibc
has lacked the manpower to be as organized as we would like to be, and
given what we do have, frankly I have no apologies about how we've
scheduled our work.
glibc has not imposed any requirements on GCC. The maintainers for the
affected platforms have known for a long time that the long double type
ought to change and that the sticking point was the glibc compatibility.
Anyone involved in glibc development has known this was on the table for
2.4, and that it would be happening by sometime around now. We did the
glibc work to support -mlong-double-128 for powerpc64, sparc, and alpha.
The support requires building glibc with a GCC that supports -mlong-double-128.
At least as far back as 4.0 (and I think 3.4 as well, modulo compiler bugs)
this works for those platforms. glibc does not mandate any change to GCC.
(glibc is built to support both the old and new long double type ABIs at
both link and compile time, depending on the use of -mlong-double-128 or
its default setting by GCC.)
The glibc work is now ready and it is easy to switch on for each platform
that has used the double==long double ABI in the past. I contacted the GCC
maintainers for s390 and powerpc(32) to suggest we start supporting a good
long double type on those platforms as well. In the case of s390, we
learned that the -mlong-double-128 support was not yet in the compiler at
all. In the case of powerpc32, we learned that its -mlong-double-128
supported only IEEE quad format, while powerpc64 supported IBM extended
format, and the consensus on behalf of powerpc users was that a single long
double format across the 32/64 powerpc architecture is what GNU/Linux users
should have. The upshot is that both s390 and powerpc(32) would require
new GCC changes in order to compile for the new glibc long double ABI. I
told those maintainers that glibc 2.4 would not support a new long double
ABI for each platform unless GCC 4.1 as released could compile that glibc.
The glibc sources make it easy enough to switch a platform down the line
(for the glibc 2.5 ABI, whenever that next release period comes along).
But all agreed that it would be in users' interests not to delay another
year in having a worthwhile long double type for their platforms, and also
in users' interests to have the change happen at the same time for as many
platforms as possible so that efforts to document and explain the change to
users could be consolidated.
Each platform's maintainers took the decision to try to make the necessary
changes in GCC 4.1 so that -mlong-double-128 can be used to compile glibc
2.4, and took the responsibility for that decision with the GCC community.
>From what I gather, the GCC maintainers as whole agreed that these changes
were worth having in 4.1 despite the poor planning. glibc has not forced
anything on GCC maintainers. If s390 -mlong-double-128 support is not in
GCC 4.1, the new long double ABI will not be in glibc 2.4 for s390.
If powerpc -m32 -mlong-double-128 -mabi=ibmlongdouble support is not in
GCC 4.1, the new long double ABI will not be in glibc 2.4 for powerpc(32).
Since the GCC maintainers for these platforms told me that GCC 4.1 would
have it, we have already started building glibc using the new support.
glibc has nothing to do with libstdc++ and does not mandate any changes to
it. Since glibc can support -mlong-double-128, we can expect users will
want libstdc++ to support it as well, with compatibility for old binaries
and for new compiles using either -mlong-double-64 or -mlong-double-128, as
glibc has. As I understand it, the libstdc++ maintainers decided it was
worthwhile to try to support this in GCC 4.1 for the benefit of users on
platforms where -mlong-double-128 is available.
On no platform does glibc force GCC to change its default to -mlong-double-128.
The glibc build itself passes -mlong-double-128, so it can be compiled with
older GCCs on most platforms. A glibc 2.4 installation will work for
a compiler that defaults to -mlong-double-128 or one that defaults to
-mlong-double-64. It is up to the GCC maintainers to decide what the
default is for each platform. As I understand it, the maintainers for
{s390*,powerpc*,sparc*,alpha}-*-linux* configurations decided that making
the default -mlong-double-128 in GCC 4.1 would be beneficial to users.
That decision certainliy does require that the libstdc++ compatibility work
be finished in the 4.1 release. But glibc does not make this requirement.
Thanks,
Roland
Re: Request for clarification on the 128bit long double requirments
> I would like to understand better why and how this GCC 4.1 requirement > for adding 128bit long double support came about. Although the lack of 128-bit long-double support has been discussed on and off for sometime on the parisc-linux list, I hadn't realized this was now a requirement for GCC 4.1. Should I file a PR? Dave -- J. David Anglin [EMAIL PROTECTED] National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
Re: Request for clarification on the 128bit long double requirments
> > I would like to understand better why and how this GCC 4.1 requirement > for adding 128bit long double support came about. Maybe better > understanding how this "mistake" came to happen will better understand > why GCC 4.1 will be delayed because of this change? > > What I am looking for is the dicussion where glibc decided to > move over and to require GCC to move over too. What I can > find is mails from July and March of last year for a glibc One correct, July and March of 2004 which makes the idea almost two years old. And that means the gcc patches should have been worked out all the way back then instead of cramming them in for this month. -- Pinski
