https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84829
--- Comment #11 from rguenther at suse dot de <rguenther at suse dot de> --- On Mon, 12 Mar 2018, carlos at redhat dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84829 > > --- Comment #8 from Carlos O'Donell <carlos at redhat dot com> --- > (In reply to Florian Weimer from comment #6) > > (In reply to Jakub Jelinek from comment #5) > > > -mieee-fp does affect code generation on x86 and m68k, but I don't see how > > > it is related to any changes in glibc. > > > And besides code generation changes it affects whether -lieee is linked in > > > or not. > > > > It matters from the users' point of view. I think it's better to give them > > a build error when they use unsupported functionality, rather than giving > > the wrong results at run time. The overloaded nature of -mieee-fp makes > > this difficult to achieve, though. > > I agree. > > My own opinion is that I would rather see a link-time failure for user > applications that use any interfaces that are no longer supported for building > new programs. > > Therefore it is that -mieee-fp is no longer supported with glibc 2.27, you > cannot use it, and it will not work. You must XFAIL any such tests if you are > using a glibc with the obsoleted matherr, _LIB_VERSION, and libieee.a > functionality. So if a program linked gainst -lieee and glibc 2.26 is run on a system with glibc 2.27 and thus obsolete/removed matherr support will it receive any error at runtime or does it silently fail to run properly? At least libieee.a doesn't seem to provide anything that would cause such a program fail to run? If there's indeed no visible error besides matherr no longer being invoked I see no issue with glibc providing an empty stub-libieee.a.
