------- Comment #5 from joseph at codesourcery dot com 2008-02-15 21:50 ------- Subject: Re: [4.1/4.2/4.3 Regression] exp->expf transformation incorrect with -fmath-errno
On Fri, 15 Feb 2008, rguenth at gcc dot gnu dot org wrote: > Ok, so with -fmath-errno the middle-end has to assume that the C library will > set errno appropriately for all math functions this is specified, even if > optional. Right? So we could at most detect at compile-time if there is a Yes, I think the compiler should avoid losing errno settings from library functions. > macro named math_errhandling and defined to a constant by the library that > says it doesn't set errno and in this case clear -fmath-errno? I don't think detecting the macro is a particularly useful idea, unlike hardcoding for particular targets as is done for Darwin. I think the right way for the macro to be handled with glibc is for it to expand to a reference to a variable that libc sets at startup. libc would set it based on information about the flags used to compile every translation unit in the program, including those that went into shared libraries loaded. If something was compiled with -fno-math-errno, for example, some function calls in the program might not get errno settings, so the math_errhandling value should not indicate that errno is guaranteed to be set. The information about flags used would be stored in object files using object attributes, and converted by the static linker to some form for libc to use. (But there's no real point making the compiler generate those object attributes without agreement from the libc side.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35202