[Bug tree-optimization/27394] New: double -> char conversion varies with optimization level

[Bug tree-optimization/27394] New: double -> char conversion varies with optimization level

[amylaar at gcc dot gnu dot org]

This testcase:

int
f
()
{
  double d = 128.;
  return (signed char) d;
}


int
main ()
{
  return f () != -128;
}

Succeeds at -O0 and fails at -O1.  While the C standard says that the result
of the conversion is unspecified, it is a quality of implementation issue to
give, where reasonably possible, the same results when optimizing as when
not optimizing.  Doing otherwise makes debugging unnecessarily difficult.


-- 
           Summary: double -> char conversion varies with optimization level
           Product: gcc
           Version: 4.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: amylaar at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27394

[Bug tree-optimization/27394] double -> char conversion varies with optimization level

[amylaar at gcc dot gnu dot org]

------- Comment #1 from amylaar at gcc dot gnu dot org  2006-05-02 17:53 -------
In 3.x, double -> char/int conversion was done consistently with the documented
behaviour of integer -> signed integer type conversion.
http://gcc.gnu.org/onlinedocs/gcc-4.1.0/gcc/Integers-implementation.html#Integers-implementation.

In 4.1, fold-const.c:fold_convert_const_int_from_real implements java
semantics.

I think for consistency, when folding a floating point value to an integer
type of smaller width than integer_type_node, it should be converted to
integer_type first, and then from there to the target type, using the
language-specific semantics.


-- 

amylaar at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to fail|                            |4.1.0 4.2.0
      Known to work|                            |3.2.3


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27394

[Bug tree-optimization/27394] double -> char conversion varies with optimization level

[pinskia at gcc dot gnu dot org]

------- Comment #2 from pinskia at gcc dot gnu dot org  2006-05-02 17:54 -------
(In reply to comment #1)
> In 3.x, double -> char/int conversion was done consistently with the documented

And there is a dup of this bug some where which has been closed and I cannot
find it right now.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27394

[Bug tree-optimization/27394] double -> char conversion varies with optimization level

[pinskia at gcc dot gnu dot org]

------- Comment #3 from pinskia at gcc dot gnu dot org  2006-05-02 17:58 -------
See PR 9325 and PR 6391.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27394

[Bug tree-optimization/27394] double -> char conversion varies with optimization level

[pinskia at gcc dot gnu dot org]

------- Comment #4 from pinskia at gcc dot gnu dot org  2006-05-02 18:00 -------
(In reply to comment #1)
> In 3.x, double -> char/int conversion was done consistently with the documented
> behaviour of integer -> signed integer type conversion.
> http://gcc.gnu.org/onlinedocs/gcc-4.1.0/gcc/Integers-implementation.html#Integers-implementation.

That has nothing to do with float -> integer type conversion.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27394

[Bug tree-optimization/27394] double -> char conversion varies with optimization level

[amylaar at gcc dot gnu dot org]

------- Comment #5 from amylaar at gcc dot gnu dot org  2006-05-02 18:21 -------
(In reply to comment #4)
> (In reply to comment #1)
> > In 3.x, double -> char/int conversion was done consistently with the documented
> > behaviour of integer -> signed integer type conversion.
> > http://gcc.gnu.org/onlinedocs/gcc-4.1.0/gcc/Integers-implementation.html#Integers-implementation.
> 
> That has nothing to do with float -> integer type conversion.

Actually, it has, in two ways:

- The wording is inexact.  You could argue that 128. is an integer in floating 
  point representation and thus covered by this clause.  Although from the
  context, it appears that that was not the intent.
- When the return statement is changed to "return (signed char)(int) d;",
  the clause applies, and indeed the behaviour becomes consistent.
  Having different semantics when you add an itermediate cast to int before
  casting to signed char is somewhat surprising.
  (I.e. although a conforming implementation, it does not follow the rule
   of least surprise.)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27394

[Bug tree-optimization/27394] double -> char conversion varies with optimization level

[schwab at suse dot de]

------- Comment #6 from schwab at suse dot de  2006-05-03 09:17 -------
> While the C standard says that the result of the conversion is unspecified,

The standard says that the behaviour is undefined (6.3.1.4#1).  That is even
true when converting to unsigned.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27394

[Bug tree-optimization/27394] double -> char conversion varies with optimization level

[pinskia at gcc dot gnu dot org]

------- Comment #7 from pinskia at gcc dot gnu dot org  2006-05-29 22:19 -------
This is invalid, the conversion is undefined.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27394

[Bug tree-optimization/27394] double -> char conversion varies with optimization level

[amylaar at gcc dot gnu dot org]

------- Comment #8 from amylaar at gcc dot gnu dot org  2006-11-15 16:28 -------
This is still a quality of implementation issue.  Changing the behaviour of the
program when the optimization level changes makes debugging harder, and we
could easily avoid the change in this instance.


-- 

amylaar at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
OtherBugsDependingO|                            |29842
              nThis|                            |
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|INVALID                     |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27394