Relying on precise integer calculation with double
Hi,
This is likely to be the one FAQ you've all learned to answer but as I
was bitten by it, I just wanted to make sure that what I saw was expected.
I've used -ffast-math for a slight speedup of floating point
arithmetics, but I've also used doubles to store integers. Since
integers (up to a certain size) can be stored without loss of precision
in a double it's been no problems until I started using gcc 4.0 (this
is with gcc 4.0.1 on a fedora core 3, x86 system).
Now I see my "exact" integer arithmetic converted to inexact fractional
double arithmetic. More specifically a division by 7 (can be exactly
represented in a double) is converted to a multiplication by 0.14285...
(about 1/7) and then rounding errors can make my "integers" get another
value.
Is this to be expected? Should I stop using
-funsafe-math-optimizations? Somehow I've been tricked into thinking
that it would be safe to use that flag unless I relied on extreme
precision or behaviour related to NaN or +-Inf, and that normal simple
arithmetics should still give the same result.
So there you have it. Now you can kick me. ;-)
Test program below. Expected 1, get 3. Compiled with
gcc -O2 -ffast-math
-
#include
int foo(double diff_days)
{
if(diff_days/7.0 != (int)(diff_days/7.0))
return 3;
return 1;
}
int main(int argc, char** argv)
{
printf("Return value (7.0/7.0) = %d\n", foo(7.0));
}
Best Regards
Daniel
Re: Relying on precise integer calculation with double
Daniel Bratell writes:
> This is likely to be the one FAQ you've all learned to answer but
> as I was bitten by it, I just wanted to make sure that what I saw
> was expected.
>
> I've used -ffast-math for a slight speedup of floating point
> arithmetics, but I've also used doubles to store integers. Since
> integers (up to a certain size) can be stored without loss of
> precision in a double it's been no problems until I started using
> gcc 4.0 (this is with gcc 4.0.1 on a fedora core 3, x86 system).
>
> Now I see my "exact" integer arithmetic converted to inexact
> fractional double arithmetic. More specifically a division by 7
> (can be exactly represented in a double) is converted to a
> multiplication by 0.14285... (about 1/7) and then rounding errors
> can make my "integers" get another value.
Yes. That's one of the things -ffast-math does.
> Is this to be expected? Should I stop using
> -funsafe-math-optimizations? Somehow I've been tricked into
> thinking that it would be safe to use that flag unless I relied on
> extreme precision or behaviour related to NaN or +-Inf, and that
> normal simple arithmetics should still give the same result.
>
> So there you have it. Now you can kick me. ;-)
>
> Test program below. Expected 1, get 3. Compiled with
> gcc -O2 -ffast-math
>
> -
>
> #include
>
> int foo(double diff_days)
> {
>if(diff_days/7.0 != (int)(diff_days/7.0))
> return 3;
>return 1;
> }
>
> int main(int argc, char** argv)
> {
>printf("Return value (7.0/7.0) = %d\n", foo(7.0));
> }
>
>
This is due to the most popular gcc bug of all, PR323. See
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323.
gcc implements division by 7 by multiplying by
0.14285714285714284921269268124888185.
The result of this is 0.4448884876874217298 (raw
0x3ffefc00).
If you stored this in a variable and used -ffloat-store, the problem
you see wouldn't happen.
// if(diff_days/7.0 != (int)(diff_days/7.0))
if(x != (int)(diff_days/7.0))
$ gcc -O2 -ffast-math p.c -save-temps -g -ffloat-store
$ ./a.out
1
Andrew.
Re: mips-elf target
Niklaus kirjoitti: Hi, Until now i have only build cross toolchains for linux systems. I guess "for totally self-built Linux-from-scratch" systems, not cross toolchains for usual Linuces like RedHats, SuSEs, Fedoras, Ubuntus etc. Usually i build crossgcc in 2 parts, one is before glibc is built , the other is after glibc is built. For usual Linuces the glibc is already built and included with the Linux distro. Just as are all those X11, Gnome, KDE etc. libraries. So these are normally NOT built, only copied from the target system or from its install stuff (RPM-packages for glibc etc.). And the GCC build happens in only one stage after building the target binutils. Is there any way where i can skip the step glibc and build the whole gcc compiler. As told, this is the expected way to build a crosscompiler for Linux - to build it in only one stage! If yes how do i build the whole gcc without glibc. I have binutils for the target already installed. I only need c and c++ languages. I doing it for vr4131 (mips-elf) target. The mips-elf target uses (usually) newlib as its target C library. And there is that '--with-newlib' option which should enable anyone to build a GCC (no 'native' choice! so it is vain to add the 'cross-' for telling it is not a native-GCC) without the (complete) target C library being available during the GCC build. The 'libiberty' and 'libstdc++-v3' configure scripts SHOULD NOT use any link tests for solving the target C library properties, the '--with-newlib' tells what the C library is and what it has. In this issue the new gcc-4.x releases seem to have restored the old bug : doing link tests with the target C library during the libstdc++-v3 configure ! So with gcc-3.4.x and older sources using '--with-newlib' should enable you to build the complete GCC with libiberty and libstdc++-v3 when having only the generic newlib headers preinstalled before the GCC build. The place, for instance 'newlib-1.13.0/newlib/libc/include', is well-known and copying this into the final '$prefix/$target/include' (the newlib install puts the final headers with possible additions/fixes for the target there) should be enough. But this "should" is optimism, there has been that "sys-include-bug" mess over 10 years without no-one of the GCC developers ever caring to fix it ! And the libiberty configure stuff has claimed that the functions 'asprintf()', 'strdup()' and 'vasprintf()' are missing from newlib although these appeared into it years ago! So one must take care that the target headers can be seen also in the '$prefix/$target/sys-include' during the GCC build! And take care that they cannot be seen there AFTER the build, IF copying them there, using symlink is not dangerous, when using the compiler, the stuff in the 'sys-include' will be searched before the 'include'. The 'sys-include' is the equivalent to the SYSTEM_INCLUDE_DIR in a native GCC and the 'include' is the equivalent to the STANDARD_INCLUDE_DIR, or usually the '/usr/include' in a native GCC. Somehow the GCC developers have mixed apples and oranges and still think the '$prefix/$target/sys-include' being the equivalent to the '/usr/include' If you don't require the target C library at all, and not use C++, then just don't build newlib at all! And it can be fully possible that you don't need even the newlib headers for producing the 'libgcc.a' ! But producing it shouldn't hurt... So your steps would be : 1. copy the generic newlib headers into the '$prefix/mips-elf/include'. Then symlink this to be seen also as the '$prefix/mips-elf/sys-include'. 2. configure the GCC sources using '--target=mips-elf --with-newlib --enable-languages=c,c++' 3. build the GCC, also the libiberty and libstdc++-v3 subdirs should succeed. The protos in the newlib headers can clash with the reimplementations in libiberty. If so, your homework is to search for the 'newlib' in the 'libiberty/configure*' and fix them by editing the mentioned three functions from the lists where they are claimed to be missing from newlib Install GCC. 4. configure and build newlib using the same '--prefix=$prefix' and '--target=mips-elf' as you used already with binutils and GCC. Then install newlib. 5. try compiling and linking your "Hello World"... This is the hardest step because only the true Legolas, Tinuviel etc. fans believe all elves being real creatures. The 'mips-elf' is not a real target like 'mips-linux-gnu' and therefore requires some special linker script being used to describe the 'real target' (a MIPS based board with monitor firmware or something). Newlib comes with linker scripts for IDT, PMON-based (a free monitor) etc. MIPS boards. Some homework expected before the "Hello World" succeeds...
Open-source projects supporting GIMPLE
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi there are there any open-source projects supporting GIMPLE (e.g. as the input IR for compilation purposes) and specifically focus on: a) tree transformations b) automating the backend development process Thanks in advance Nikolaos Kavvadias -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFENQucMPiy0tCWlz4RAib8AKCfkxBYaF3qOD6Vh7Mbim2t6FuM9ACbBlCg wkxCcbCzlADZ5AZckIkI3zM= =ESGZ -END PGP SIGNATURE-
Re: GCC port for V8-uRISC (8 bit CPU)
Thank you all for informations. Regards, Nemanja - Original Message - From: "Dave Hudson" <[EMAIL PROTECTED]> To: "Alan Lehotsky" <[EMAIL PROTECTED]>; "Nemanja Popov" <[EMAIL PROTECTED]>; Sent: Wednesday, April 05, 2006 7:21 PM Subject: RE: GCC port for V8-uRISC (8 bit CPU) FWIW we did get really great code generation for the IP2k in the end although it took some rather unpleasant machine-dependent-reorg stuff to work around the fact almost every instruction used a singe 8-bit accumulator registerr :-) Other ports to look at would be the AVR (8-bit RISC with 32 registers) and 68HC11 (more traditional accumulator-style 8-bit CPU). The AVR is a pretty nice clean port. Regards, Dave * -Original Message- * From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On * Behalf Of Alan Lehotsky * Sent: 05 April 2006 17:49 * To: Nemanja Popov; gcc@gcc.gnu.org * Subject: Re: GCC port for V8-uRISC (8 bit CPU) * * I participated in a port to an 8-bit internet toaster 4 years * ago (the Ubicom IP2k chip). * * It's distributed as part of the gcc-3.x releases, but has * been dropped from the gcc-4.x distributions. * * The IP2k was a very restrictive environment, and it took a * lot of work to get it to generate really tight code. * I'd definely suggest looking at gcc/config/ip2k to see how we * did it * * -Original Message- * >From: Nemanja Popov <[EMAIL PROTECTED]> * >Sent: Apr 5, 2006 9:50 AM * >To: gcc@gcc.gnu.org * >Subject: GCC port for V8-uRISC (8 bit CPU) * > * >Hi, * > * >Can somebody please explain to me is it reasonable and * possible to port * >gcc (version 4.xx) to 8 bit cpu architecture. * >I would appreciate precise explanation why it is possible or not. * > * >CPU is V8-uRISC. * > * >V8-uRISC Features are: * > * > 8-bit ALU * > 64K byte addressing capability * > Accumulator (R0) * > Seven 8-bit General Purpose Registers (R1-R7) Multiple register * > banks are easily implemented 16-bit Program Counter and * Stack Pointer * > * >Thanks in advance for all informations. * >Regards, * >Nemanja Popov * > * * * __ NOD32 1.1473 (20060405) Information __ This message was checked by NOD32 antivirus system. http://www.eset.com
Re: Relying on precise integer calculation with double
On Thu, 6 Apr 2006, Daniel Bratell wrote: > that it would be safe to use that flag unless I relied on extreme > precision or behaviour related to NaN or +-Inf, and that normal simple > arithmetics should still give the same result. Unfortunately, with -ffast-math simple arithemtics no longer have precisely the same result. Converting the division into multiplication by reciprocal sometimes results in numbers that can't precisely be represented such as 1/7. Of course, in this case you are relying on "extreme precision" as you describe it above. As pointed out by Andrew the result is 0.4448884876874217298 which should be close enough to one for most -ffast-math applications. The real problem is the source line: >if(diff_days/7.0 != (int)(diff_days/7.0)) Here you're using C's default FP->int conversion with is truncation towards zero. The fact that 0. is less than 1 means the result is zero. Instead, you should probably use "rint" or "round" or "lround" to return the nearest integer. Roger --
Successful gcc 4.0.3 build on alphaev68-dec-osf5.1bTru64(c,c++,f95,objc,java,treelang)
[EMAIL PROTECTED]:~#gcc -v Using built-in specs. Target: alphaev68-dec-osf5.1b Configured with: ../configure --host=alphaev68-dec-osf5.1b --enable-threads=posix --enable-languages=c,c++,f95,objc,java,treelang --prefix=/usr/local --enable-version-specific-runtime-libs --enable-shared --enable-libgcj --enable-nls --enable-interpreter Thread model: posix gcc version 4.0.3 see my previous email: http://gcc.gnu.org/ml/gcc/2005-07/msg00601.html for f95 and java compilation. Sincerely, Stefano Curtarolo -- Prof. Stefano Curtarolo Assistant Professor of Materials Science Duke University, Dept. Mechanical Engineering and Materials Science 144 Hudson Hall, Box 90300, Durham, NC 27708-0300 phone 919-660-5506 [EMAIL PROTECTED] http://alpha.mems.duke.edu -- The chief enemy of creativity is "good" sense (Picasso). Conformity is the refuge of the unimaginative.
Build report for gcc 4.1.0 on powerpc-apple-darwin8.5.0
powerpc-apple-darwin8.5.0 /usr/local/gcc-4.1.0/bin/gcc -v Using built-in specs. Target: powerpc-apple-darwin8.5.0 Configured with: ../gcc-4.1.0/configure --prefix=/usr/local/gcc-4.1.0 --with-gmp=/usr/local/gmp-4.2 --with-mpfr=/usr/local/gmp-4.2 Thread model: posix gcc version 4.1.0 Languages: default, c, c++, fortran, java, obj-c
Ipa and CONSTRUCTOR in global vars
I am updating GNU Pascal to work with gcc-4.x. I have hit the following problem: `get_base_var' (in ipa-utils.c:224) can not handle a CONSTRUCTOR and I get ICE. AFAICS the CONSTRUCTOR in question comes from initializer of global variable. More precisely, I have a global variable with an initializer. This initialize is a CONSTRUCTOR. One of its components is ADDR_EXPR of another CONSTRUCTOR. Now, the question is: should `get_base_var' be extended to handle CONSTRUCTOR nodes or is ADDR_EXPR of a CONSTRUCTOR forbidden from getting there? -- Waldek Hebisch [EMAIL PROTECTED]
[gnu.org #283065] Confirming the mailing of your assignment
Hello Nic, Thank you for contributing to GNU software. We'll send you the appropriate papers through the post Please sign and return the original in the envelope provided. Once the FSF has signed it, we will send you a digital copy in pdf format for your records. If your employment status changes, please remember to notify us. A change in employers, or a change in your employment status, can effect your continuing assignment. Thank you for your contribution! All the best, Jonas Jacobson Assignment Administrator Free Software Foundation 51 Franklin Street, Fifth Floor Boston, MA 02110 Phone +1-617-542-5942 Fax +1-617-542-2652
Re: preview of the tree-check pass (Re: gcc project)
On Wed, 2006-04-05 at 09:12, Zack Weinberg wrote:
> It's an interesting system. I wonder if it's powerful enough to express
> the rather complicated constraints on objects of type va_list. Warnings
> for violations of those constraints would be valuable - there are common
> portability errors that could be caught - but it's never been important
> enough to write a custom check pass for it. If your system can handle
> it, we could consider (assuming it's included) providing the check file
> that defines them with GCC as a worked example, maybe even including it
> in -Wall (which would ensure that your pass got exercised and therefore
> didn't break through disuse).
>
> I describe the constraints in
> http://gcc.gnu.org/ml/gcc-patches/2002-06/msg01293.html
> and can explain further if they don't make sense. (I don't swear that
> I have them perfectly accurate, but I'm pretty sure.)
Very interesting problem! The short answer is:
1. you can solve 1/3 of your problem with the current tree-check pass
2. by hacking a bit the pass, we could easily solve a second third
3. the third third :°) is a bit trickier, actually you cannot express it
in the framework without extending it more seriously.
Here are the details.
Looking at your specification of the va_arg check, it is formulated as
two automata: one for the caller function, and one for the called
("mangling") function. There are three error cases (corresponding to the
3 thirds above):
1. (in the caller:) exiting the function after a va_start() without an
va_end().
This can be expressed directly today as:
from "va_start(%X,%_)"
to "return" or "return(%_)"
avoid "va_end(%X)"
Actually, because the check is performed on the preprocessed form, the
names of the calls have to be a bit different:
from "__builtin_va_start(%X,%_,%_)"
to "return" or "return(%_)"
avoid "__builtin_va_end(%X)"
2. (in the mangler:) calling va_start() or va_end() on a va_list
parameter.
In principle, this can be expressed simply as:
from "va_list %X;"
to "return" or "return(%_)"
The problem is that currently the pass scans only statements in the CFG,
not declarations, so the "from" expression will never match. Moreover,
the declaration of %X should be a formal parameter, not a local
variable.
The first problem could be handled by simply scanning declarations as an
entry block for the CFG.
The second problem could be handled by complementing the "from" pattern
with a call to the gcc API (as Diego intended to define one), e.g.:
from "va_list %X;" | PARM_DECL_P(X)
to "return" or "return(%_)"
3. (in the caller:) exiting the function after a va_start() then a call
to the mangler without an va_end().
This one involves more than a from/to/avoid; it is of the form
from/then/to/avoid. In other words, the corresponding automaton has more
than three states, which is the limit of my current framework. The
reason why I chose this limitation in the first place is to ensure taht
checking is linear in time and space. I'm not sure this should be
re-considered.
Cheers,
Nic.
gcc-4.0-20060406 is now available
Snapshot gcc-4.0-20060406 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.0-20060406/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.0 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_0-branch revision 112740 You'll find: gcc-4.0-20060406.tar.bz2 Complete GCC (includes all of below) gcc-core-4.0-20060406.tar.bz2 C front end and core compiler gcc-ada-4.0-20060406.tar.bz2 Ada front end and runtime gcc-fortran-4.0-20060406.tar.bz2 Fortran front end and runtime gcc-g++-4.0-20060406.tar.bz2 C++ front end and runtime gcc-java-4.0-20060406.tar.bz2 Java front end and runtime gcc-objc-4.0-20060406.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.0-20060406.tar.bz2The GCC testsuite Diffs from 4.0-20060330 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.0 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: Ipa and CONSTRUCTOR in global vars
> Now, the question is: should `get_base_var' be extended to handle > CONSTRUCTOR nodes or is ADDR_EXPR of a CONSTRUCTOR forbidden from > getting there? The latter. See PR c++/23171 and PR ada/22533. -- Eric Botcazou
Re: preview of the tree-check pass (Re: gcc project)
On Thu, Apr 06, 2006 at 11:58:20PM +0200, Nic Volanschi wrote: > 3. (in the caller:) exiting the function after a va_start() then a call > to the mangler without an va_end(). > This one involves more than a from/to/avoid; it is of the form > from/then/to/avoid. In other words, the corresponding automaton has more > than three states, which is the limit of my current framework. The > reason why I chose this limitation in the first place is to ensure taht > checking is linear in time and space. I'm not sure this should be > re-considered. The limitation is, I think, too strict. Other path-based tools (for example, Coverity's) handle cases like this, and limit the combinatorial explosion by cutting off after exploring a fixed number of paths .
Flag of inline assembly ??
Hi, Is there a flag in gcc that indicate that we are in the inline assembly ? thanks, Aladdin
Addressing mode in inline assembly
Hello , If it is possible to restrict the addressing mode of inline assembly? For example,in normal mode that we accept the addressing mode BASE+OFFSET, but do not like it in inline assembly. Is there any one can give me a hand? thanks a lot! Aladdin
