This is the mail archive of the ecos-discuss@sourceware.org mailing list for the eCos 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: issue with floor()


Sorry for the repeated replies to myself.

On Wed, Nov 10, 2010 at 7:00 AM, David Brennan <david@brennanhome.com> wrote:
> See results below
>
> On Wed, Nov 10, 2010 at 6:34 AM, David Brennan <david@brennanhome.com> wrote:
>> Thank you Paul,
>>
>> On Wed, Nov 10, 2010 at 12:08 AM, Paul D. DeRocco
>> <pderocco@ix.netcom.com> wrote:
>>>> From: David Brennan
>>>>
>>>> I am using a relatively recent CVS of eCos on an x86 VME
>>>> target. I am trying to get an existing application working,
>>>> and I stumbled across an unusual result.
>>>>
>>>> The code called floor() with a value of 0.048000000000000001.
>>>> the correct return value should have been 0.0.
>>>>
>>>> Single stepping through the "bit twiddling" looked like it
>>>> was pursuing the correct code path, but at this point,
>>>> somthing went wrong.
>>>>
>>>> 97 ? ? ? ? ? ? ? ? ? ?if(huge+x>0.0) {/* return 0*sign(x) if |x|<1 */
>>>> (gdb) s
>>>> 98 ? ? ? ? ? ? ? ? ? ? ? ?if(i0>=0) {i0=i1=0;}
>>>> (gdb) p i0
>>>> $4 = 8
>>>> (gdb) s
>>>> 131 ? }
>>>> (gdb) info locals
>>>> i0 = 8
>>>> j0 = -5
>>>> i = 1067989024
>>>> x = 0.048000000000000001
>>>> (gdb) li
>>>> 126 ? ? ? ? ? ? ? }
>>>> 127 ? ? ? ? ? }
>>>> 128 ? ? ? ? ? CYG_LIBM_HI(x) = i0;
>>>> 129 ? ? ? ? ? CYG_LIBM_LO(x) = i1;
>>>> 130 ? ? ? ? ? return x;
>>>> 131 ? }
>>>> 132
>>>> 133 ? #endif // ifdef CYGPKG_LIBM
>>>> 134
>>>> 135 ? // EOF s_floor.c
>>>>
>>>> It appears that the code did not run line 98 correctly.
>>>
>>> <snip>
>>>
>>>> I am using a compiler that I built (so that is most likely
>>>> the problem). I am using OS X for my host, and there are not
>>>> pre-built binaries for that.
>>>
>>> I would think examining the assembly language would clear up the mystery,
>>> especially if you find the problem persists with optimization turned off.
>>> For instance, it could be that the arithmetic doesn't work because
>>> something's busted in the FP support, but the sign test works correctly
>>> because it doesn't use an FP instruction to test the sign.
>>>
>>> --
>>>
>>> Ciao, ? ? ? ? ? ? ? Paul D. DeRocco
>>> Paul ? ? ? ? ? ? ? ?mailto:pderocco@ix.netcom.com
>>>
>>
> <snip>
>>
>> I will re-run the floor test later today without optimization. But if
>> that solves the problem, then what? Is this a gcc bug? Or a gcc
>> configuration error?
>>
>> Thanks again for your help
>> David Brennan
>>
>
> Turning off optimization allows the floor test to pass.
>
>
<snip>
>
> This will let me continue on my project. But I would like for
> optimization to work. What is the best method for approaching gcc
> maintainers about this issue?
>
> Thank you for your help
> David Brennan
>

I looked at the gcc website. Specifically about "things which are not
bugs". And it seems like the strict aliasing issue that they describe
may be relevant. So I went back and looked at the compiler output when
compiling optimized, and found this:
/opt/ecos-old/eCosIRL/OS/ecos/packages/language/c/libm/current/src/double/portable-api/s_floor.c:
In function ‘floor’:
/opt/ecos-old/eCosIRL/OS/ecos/packages/language/c/libm/current/src/double/portable-api/s_floor.c:128:
warning: dereferencing pointer ‘x.0’ does break strict-aliasing rules
/opt/ecos-old/eCosIRL/OS/ecos/packages/language/c/libm/current/src/double/portable-api/s_floor.c:128:
note: initialized from here
/opt/ecos-old/eCosIRL/OS/ecos/packages/language/c/libm/current/src/double/portable-api/s_floor.c:129:
warning: dereferencing pointer ‘x.0’ does break strict-aliasing rules
/opt/ecos-old/eCosIRL/OS/ecos/packages/language/c/libm/current/src/double/portable-api/s_floor.c:129:
note: initialized from here

(The same warning actually comes up in several of the libm files)

So it looks like this may actually be an eCos source code problem. I
can take a stab at fixing this. But if anyone happens to know right
away how to do it, I'd welcome the help. This code is not the most
straight forward.

David Brennan


Relevant description from gcc.gnu.org:

Casting does not work as expected when optimization is turned on.
This is often caused by a violation of aliasing rules, which are part
of the ISO C standard. These rules say that a program is invalid if
you try to access a variable through a pointer of an incompatible
type. This is happening in the following example where a short is
accessed through a pointer to integer (the code assumes 16-bit shorts
and 32-bit ints):

#include <stdio.h>

int main()
{
  short a[2];

  a[0]=0x1111;
  a[1]=0x1111;

  *(int *)a = 0x22222222; /* violation of aliasing rules */

  printf("%x %x\n", a[0], a[1]);
  return 0;
}
The aliasing rules were designed to allow compilers more aggressive
optimization. Basically, a compiler can assume that all changes to
variables happen through pointers or references to variables of a type
compatible to the accessed variable. Dereferencing a pointer that
violates the aliasing rules results in undefined behavior.

In the case above, the compiler may assume that no access through an
integer pointer can change the array a, consisting of shorts. Thus,
printf may be called with the original values of a[0] and a[1]. What
really happens is up to the compiler and may change with architecture
and optimization level.

Recent versions of GCC turn on the option -fstrict-aliasing (which
allows alias-based optimizations) by default with -O2. And some
architectures then really print "1111 1111" as result. Without
optimization the executable will generate the "expected" output "2222
2222".

To disable optimizations based on alias-analysis for faulty legacy
code, the option -fno-strict-aliasing can be used as a work-around.

The option -Wstrict-aliasing (which is included in -Wall) warns about
some - but not all - cases of violation of aliasing rules when
-fstrict-aliasing is active.

To fix the code above, you can use a union instead of a cast (note
that this is a GCC extension which might not work with other
compilers):

#include <stdio.h>

int main()
{
  union
  {
    short a[2];
    int i;
  } u;

  u.a[0]=0x1111;
  u.a[1]=0x1111;

  u.i = 0x22222222;

  printf("%x %x\n", u.a[0], u.a[1]);
  return 0;
}
Now the result will always be "2222 2222".

For some more insight into the subject, please have a look at this article.

--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss


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