c - C99 - guarantees about ordering of floating-point rounding modes -

are there guarantees (in c99 standard and/or ieee-754) results obtained when using different rounding modes should ordered in particular way?

for instance, let f(rm, x) function rm rounding mode , x argument. can consider bug-free implementation should ensure following inequality?

f(fe_downward,x) <= f(fe_tonearest,x) <= f(fe_upward,x) 

as example, following code on machine contradicts hypothesis (even using recent glibc, version 2.21), , wonder if it's bug (worth reporting), or unfortunate consequence of rounding errors, means such behavior should never relied upon.

#include <math.h> #include <stdio.h> #include <stdlib.h> #include <fenv.h> #include <gnu/libc-version.h>  void set_round(int rm) {   // checks rounding mode has been set   if (fesetround(rm)) { perror("setround"); exit(1); } }  int main() {   printf("gnu libc version: %s\n", gnu_get_libc_version());   float x = 3;   set_round(fe_tonearest);   float r = log10f(x);   printf("nearest:     r = %g (%a)\n", r, r);    set_round(fe_downward);   r = log10f(x);   printf("downward:    r = %g (%a)\n", r, r);    set_round(fe_upward);   r = log10f(x);   printf("upward:      r = %g (%a)\n", r, r);    set_round(fe_towardzero);   r = log10f(x);   printf("toward zero: r = %g (%a)\n", r, r);   return 0; } 

output:

gnu libc version: 2.21 nearest:     r = 0.477121 (0x1.e89278p-2) downward:    r = 0.477121 (0x1.e8927ap-2) upward:      r = 0.477122 (0x1.e8927cp-2) toward zero: r = 0.477121 (0x1.e8927ap-2) 

edit: turns out specific example gcc "feature"¹: using clang, or activating gcc's optimization flags, or using literal constant instead of variable when calling log10f, of them result in consistent values. question still stands in general case, however.

¹ not considered bug gcc, rather surprising result due optimizations performed directly gcc without involving imprecise glibc.

no such guarantee made.

some math libraries attempt satisfy constraint for math library functions only, behavior not required standard, , quite rare (even libraries attempt provide have compromises , bugs).

for functions not in math library, attempting conform property impossible, useless anyway, , unheard of.

ieee-754 (2008) recommends, not require, specific subset of math library functions correctly rounded (or correctly-rounded versions made available), implies property you're looking for. recommendation not implemented @ present, however.