[Bug tree-optimization/35202] [4.1/4.2/4.3 Regression] exp->expf transformation incorrect with -fmath-errno

["joseph at codesourcery dot com" <gcc-bugzilla at gcc dot gnu dot org>]

------- 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