[PATCH libstdc++/66689] comp_ellint_3 and ellint_3 return garbage values

[Jonathan Wakely]

On 21/11/17 12:33 +0100, Florian Weimer wrote:
>On 11/18/2017 05:49 PM, Ed Smith-Rowland wrote:
>>I feel that distros are likely to pick up gcc-7 soon and I'd like to 
>>do *something*.  This would be something of a transition path.
>
>Historically, in glibc, we would have used symbol versioning for this, 
>so that existing binaries retain the old behavior.  The downside is 
>that blind recompilation will give you the change in behavior, so it 
>essentially benefits proprietary software vendors only, which is why I 
>think it's usually not appropriate to do this because either you want 
>the fix for all applications, recompiled or not, or you don't.
>
>In addition, in Fedora and downstream, we cannot backport new symbol 
>versions unless the symbol version is unique to the feature/bug fix 
>being added, due to the way RPM dependencies are generated.

None of these functions is exported from the library, they're all
header-only inline functions or function templates.

So the good news is existing binaries retain the old behaviour, but
the bad news is we can't version it easily, and so if you link
together objects built with old and new versions of GCC you have a
one-definition rule violation and the linker will just pick one of the
symbols to be kept.

We could put them in an inline namespace, so they mangle differently,
so then the old and new objects would call different versions of the
functions, with different results.