Bug 18550 - Remainder on floating point doesn't return the expected result
Summary: Remainder on floating point doesn't return the expected result
Status: RESOLVED WORKSFORME
Alias: None
Product: gcc
Classification: Unclassified
Component: java (show other bugs)
Version: 4.0.0
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-11-18 19:22 UTC by Olivier Thomann
Modified: 2005-07-23 22:49 UTC (History)
2 users (show)

See Also:
Host:
Target: i686-pc-mingw32
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Olivier Thomann 2004-11-18 19:22:44 UTC
Using gcj,

gcj (GCC) 4.0.0 20040924 (experimental)
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

I built the following program into an executable. The expected result is false,
but when I run the executable I get true. I think the JLS (second edition) are
pretty clear that the right answer is false, since: f % Float.POSITIVE_INFINITY
should reply f. See:
http://java.sun.com/docs/books/jls/second_edition/html/expressions.doc.html#24956

public class X {

	public static void main(String args[]) {
		System.out.println(3.14f % Float.POSITIVE_INFINITY != Float.NaN);
	}
}

Here is the ant script use to run it:
<?xml version="1.0" encoding="UTF-8"?>
<project name="export-executable" default="build_executable">
    <target name="build_executable">
        <echo message="compiling resources   -> .o"/>
	    <echo message="compiling sources      -> .o"/>
        <apply failonerror="true" executable="${gcc-path}/bin/gcj.exe"
dest="${work}" parallel="false">
  			 <arg value="--verbose"/>
            <arg value="--classpath=${work}"/>
            <arg value="-O0"/>
            <arg value="-c"/>
            <arg value="-fassume-compiled"/>
            <arg value="-march=pentium4"/>
            <arg value="-mfpmath=sse"/>
            <srcfile/>
            <arg value="-o"/>
            <targetfile/>
            <fileset dir="${work}" includes="**/*.java"/>
            <mapper type="glob" from="*.java" to="*.o"/>
        </apply>

        <echo message="linking .o -> ${binaryname}"/>
        <apply failonerror="true" executable="${gcc-path}/bin/gcj.exe"
parallel="true">
        	<arg value="--verbose"/>
            <arg line ="-o ${dest}${binaryname}.exe"/>
            <arg value="-fassume-compiled"/>
            <arg value="-march=pentium4"/>
            <arg value="-mfpmath=sse"/>
            <arg line="--main=X"/>
            <fileset dir="${work}" includes="**/*.o"/>
       </apply>
    </target>
</project>

it is called inside another ant script that sets what file should be compiled.

Here is the output I get when doing the compilation:
Reading specs from
c:/java_tools/thisiscool-gcc/gcc-4.0/bin/../lib/gcc/i686-pc-mingw32/4.0.0/specs
Reading specs from
c:/java_tools/thisiscool-gcc/gcc-4.0/bin/../lib/gcc/i686-pc-mingw32/4.0.0/../../../../i686-pc-mingw32/lib/libgcj.spec
rename spec lib to liborig
Configured with: /datal/gcc/gcc/configure --prefix=/datal/gcc/build/wingcc
--build=i686-pc-linux-gnu --host=i686-pc-mingw32 --target=i686-pc-mingw32
--enable-languages=c,c++,java --with-gcc --with-gnu-as --with-gnu-ld
--enable-threads=win32 --disable-nls --disable-win32-registry --disable-shared
--disable-debug --without-newlib --enable-libgcj --disable-java-awt --without-x
--enable-java-gc=boehm --disable-libgcj-debug --enable-interpreter
--enable-hash-synchronization --enable-sjlj-exceptions --enable-libgcj-multifile
--enable-libgcj-mingw-osapi=ansi
Thread model: win32
gcc version 4.0.0 20040924 (experimental)
c:/java_tools/thisiscool-gcc/gcc-4.0/bin/../libexec/gcc/i686-pc-mingw32/4.0.0/jc1.exe
C:\eclipse\workspaces\bingcj\tmp\X.java -fhash-synchronization
-fuse-divide-subroutine -fcheck-references -fuse-boehm-gc -fnon-call-exceptions
-fno-omit-frame-pointer -fkeep-inline-functions -quiet -dumpbase X.java
-march=pentium4 -mfpmath=sse -auxbase-strip C:\eclipse\workspaces\bingcj\tmp\X.o
-O0 -version -fclasspath=../../bingcj/tmp/ -fassume-compiled -o
C:\DOCUME~1\othomann\LOCALS~1\Temp/ccOUaaaa.s
GNU Java version 4.0.0 20040924 (experimental) (i686-pc-mingw32)
compiled by GNU C version 4.0.0 20040924 (experimental).
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Class path starts here:
../../bingcj/tmp/
c:\java_tools\thisiscool-gcc\gcc-4.0\bin\../lib/gcc/../../share/java/libgcj-4.0.0.jar/
(system) (zip)
c:/java_tools/thisiscool-gcc/gcc-4.0/bin/../lib/gcc/i686-pc-mingw32/4.0.0/../../../../i686-pc-mingw32/bin/as.exe
-o C:\eclipse\workspaces\bingcj\tmp\X.o
C:\DOCUME~1\othomann\LOCALS~1\Temp/ccOUaaaa.s
     [echo] linking .o -> Toto310
Reading specs from
c:/java_tools/thisiscool-gcc/gcc-4.0/bin/../lib/gcc/i686-pc-mingw32/4.0.0/specs
Reading specs from
c:/java_tools/thisiscool-gcc/gcc-4.0/bin/../lib/gcc/i686-pc-mingw32/4.0.0/../../../../i686-pc-mingw32/lib/libgcj.spec
rename spec lib to liborig
Configured with: /datal/gcc/gcc/configure --prefix=/datal/gcc/build/wingcc
--build=i686-pc-linux-gnu --host=i686-pc-mingw32 --target=i686-pc-mingw32
--enable-languages=c,c++,java --with-gcc --with-gnu-as --with-gnu-ld
--enable-threads=win32 --disable-nls --disable-win32-registry --disable-shared
--disable-debug --without-newlib --enable-libgcj --disable-java-awt --without-x
--enable-java-gc=boehm --disable-libgcj-debug --enable-interpreter
--enable-hash-synchronization --enable-sjlj-exceptions --enable-libgcj-multifile
--enable-libgcj-mingw-osapi=ansi
Thread model: win32
gcc version 4.0.0 20040924 (experimental)
c:/java_tools/thisiscool-gcc/gcc-4.0/bin/../libexec/gcc/i686-pc-mingw32/4.0.0/jvgenmain.exe
Xmain C:\DOCUME~1\othomann\LOCALS~1\Temp/cccraaaa.i
c:/java_tools/thisiscool-gcc/gcc-4.0/bin/../libexec/gcc/i686-pc-mingw32/4.0.0/cc1.exe
C:\DOCUME~1\othomann\LOCALS~1\Temp/cccraaaa.i -quiet -dumpbase Xmain.c
-march=pentium4 -mfpmath=sse -g1 -version -fdollars-in-identifiers -o
C:\DOCUME~1\othomann\LOCALS~1\Temp/cceIaaaa.s
GNU C version 4.0.0 20040924 (experimental) (i686-pc-mingw32)
compiled by GNU C version 4.0.0 20040924 (experimental).
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
c:/java_tools/thisiscool-gcc/gcc-4.0/bin/../lib/gcc/i686-pc-mingw32/4.0.0/../../../../i686-pc-mingw32/bin/as.exe
-o C:\DOCUME~1\othomann\LOCALS~1\Temp/ccgZaaaa.o
C:\DOCUME~1\othomann\LOCALS~1\Temp/cceIaaaa.s
c:/java_tools/thisiscool-gcc/gcc-4.0/bin/../lib/gcc/i686-pc-mingw32/4.0.0/../../../../i686-pc-mingw32/bin/ld.exe
-Bdynamic -o ../../bingcj/Toto310.exe
c:/java_tools/thisiscool-gcc/gcc-4.0/bin/../lib/gcc/i686-pc-mingw32/4.0.0/../../../../i686-pc-mingw32/lib/crt2.o
-Lc:/java_tools/thisiscool-gcc/gcc-4.0/bin/../lib/gcc/i686-pc-mingw32/4.0.0
-Lc:/java_tools/thisiscool-gcc/gcc-4.0/bin/../lib/gcc
-Lc:/java_tools/thisiscool-gcc/gcc-4.0/bin/../lib/gcc/i686-pc-mingw32/4.0.0/../../../../i686-pc-mingw32/lib
C:\DOCUME~1\othomann\LOCALS~1\Temp/ccgZaaaa.o
C:\eclipse\workspaces\bingcj\tmp\X.o -lmingw32 -lgcc -lmoldname -lmingwex
-lmsvcrt --start-group -lgcj --whole-archive -lswtimgloader --no-whole-archive
--end-group -lm -lgdi32 -lws2_32 -lmingw32 -lgcc -lmoldname -lmingwex -lmsvcrt
-luser32 -lkernel32 -ladvapi32 -lshell32 -lmingw32 -lgcc -lmoldname -lmingwex
-lmsvcrt

Thanks for letting me know if there is a workaround this issue. I tried with gcj
3.4:
gcj (GCC) 3.4.0 20040316 (prerelease)
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

with the same result.
Comment 1 Olivier Thomann 2004-11-18 19:26:43 UTC
Sorry, my test case was wrong. Here is the right one:

public class X {

	public static void main(String args[]) {
		System.out.println(3.14f % Float.POSITIVE_INFINITY);
	}
}

I expect the output to be: 3.14, but instead I get NaN.
Comment 2 Andrew Pinski 2004-11-18 20:36:11 UTC
It works on the mainline on powerpc-darwin.  This might be a mygwin bug as the front-end just makes 
the call to fmod.
Comment 3 Andrew Pinski 2004-11-20 18:40:06 UTC
This is a mygwin bug as I only just get a call to fmod:
        call    fmod
Comment 4 Olivier Thomann 2004-11-22 02:20:58 UTC
So where should I report this bug?
Comment 5 Andrew Pinski 2004-11-22 02:27:01 UTC
http://www.mingw.org/bugs.shtml