This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Add a barrier in the double fma implementation


On Wed, Feb 15, 2012 at 12:17:49PM -0800, Roland McGrath wrote:
> I try to avoid knowing anything about floating-point.  But it seems like
> this would be an issue for applications too.  I wonder if fetestexcept et
> al shouldn't have barriers themselves?  I guess the public calls are actual
> functions, so they are all implicit barriers--but does that hold under
> static linking plus massive link-time interprocedural optimization (which
> could come along some day even if it's not all here yet).
> 
> Is there any use of the libc_fe* calls in which a barrier is *not*
> appropriate?
> 

The C99 standard says to use the "#pragma STDC FENV_ACCESS" to tell
the compiler to not optimize access to the floating point environment.
Unfortunately this is not implemented by GCC.

The only case that comes to mind where a barrier is not appropriate, is
when you are running an algorithm in a loop, and you want to exit the
loop when a problem appears. In that case you don't really care where
exactly the exception occurred. Actually some CPU implement deferred
exception handling, that is they don't always trigger the exception at
the place it occurred.

-- 
Aurelien Jarno	                        GPG: 1024D/F1BCDB73
aurelien@aurel32.net                 http://www.aurel32.net


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]