public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
From: jmurray@dsrnet.com
To: gcc-gnats@gcc.gnu.org
Subject: c/2582: implicit cast assignment from int to float problem with x86
Date: Wed, 18 Apr 2001 14:36:00 -0000	[thread overview]
Message-ID: <20010418213025.27637.qmail@sourceware.cygnus.com> (raw)

>Number:         2582
>Category:       c
>Synopsis:       implicit cast assignment from int to float problem with x86
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          wrong-code
>Submitter-Id:   net
>Arrival-Date:   Wed Apr 18 14:36:01 PDT 2001
>Closed-Date:
>Last-Modified:
>Originator:     Joseph Murray
>Release:        gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)
>Organization:
>Environment:
Red Hat Linux 6.2 w/ the Linux 2.2.18 Kernel
However, this is present on all versions of Linux for x86 that we have found. We have tested on single processor, dual processor, quad processor, and octal processor with the 2.2.xx kernels and the 2.4.xx kernels and several versions of gcc and g++.

uname -a results:
Linux compaq1a 2.2.18 #1 SMP Fri Apr 6 14:55:49 EDT 2001 i686 unknown.
>Description:
We had an extensive discussion with a number of different groups on this problem but never found a good solution. We have tested this on Win98 w/ a Borland Compiler, on several versions of Linux with several versions of GCC, and on several RISC based workstations with GCC and other compilers.

This routine works as anticipated on all RISC machines regardless of the compiler but fails on all x86 based machines (that we have) with GCC. If we declare the variables volatile it works. My problem is that I have 600000 lines of code and I can't declare variables volatile everywhere or find all of the potential locations of this problem.

A routine that demonstrates the problem is below. I can provide several other examples. It was suggested previously that the floating point unit was being put into truncate mode from its default round-to mode. I don't know how to overcome this without major ramifications on the code baseline.

A summary of the routine is:

1. Assign some values to some integer variables.
2. Assign a floating point value from the division of two cast integers.
3. Assign a floating point value from the multiplication of two floats.
4. Assign an integer from a cast of a floating point product.
5. Assign an integer from a cast of a floating point number.

Result:

This is equiv to num = .35 * 20

3 results in: 7.0000000000 (actually probably 6.999999?rounded to 7.00000000)
4 results in: 6 <------- PROBLEM WITH INPLACE ASSIGNMENT
5 results in: 7 (correct answer)

Example routine:
-------------------------------------------------------
#include <stdio.h>

int main(void) {

  /* Assign some values to ints */
  int iaa = 28;
  int ibb = 80;
  int icc = 20;

  int imm, immO;
  float fll;
  float ftmp;

  fll = (float)iaa / (float)ibb;

  imm = ftmp = fll * (float)icc;

  printf("Direct assign float to float = %.10f\n", ftmp);
  printf(" Inplace assign float to int = %d\n", imm);

  immO = ftmp;
  printf("  Direct assign float to int = %d\n", immO);

  return(0);
}
-------------------------------------------------------

We can not find all of the instances of this problem and often it is undetectable in many of the normalization processes of our systems. However, the results are wrong and lead to the wrong solution.
>How-To-Repeat:
#include <stdio.h>

int main(void) {

  /* Assign some values to ints */
  int iaa = 28;
  int ibb = 80;
  int icc = 20;

  int imm, immO;
  float fll;
  float ftmp;

  fll = (float)iaa / (float)ibb;

  imm = ftmp = fll * (float)icc;

  printf("Direct assign float to float = %.10f\n", ftmp);
  printf(" Inplace assign float to int = %d\n", imm);

  immO = ftmp;
  printf("  Direct assign float to int = %d\n", immO);

  return(0);
}
>Fix:
A fix is to declare the variables volatile which ultimately changes the output assembly. Alternately, you can program to force all intermediate variables to be set to an appropriate type before truncation. This is difficult for existing baselines and inplace checks.
>Release-Note:
>Audit-Trail:
>Unformatted:


             reply	other threads:[~2001-04-18 14:36 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-04-18 14:36 jmurray [this message]
2001-04-18 15:46 Joe Murray
2001-04-23  9:36 Joe Murray
2002-10-10 11:46 hubicka

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20010418213025.27637.qmail@sourceware.cygnus.com \
    --to=jmurray@dsrnet.com \
    --cc=gcc-gnats@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).