Bug 61626 - Cast temporary produces wrong result
Summary: Cast temporary produces wrong result
Status: RESOLVED DUPLICATE of bug 323
Alias: None
Product: gcc
Classification: Unclassified
Component: c (show other bugs)
Version: 4.8.2
: P3 minor
Target Milestone: ---
Assignee: Not yet assigned to anyone
Depends on:
Reported: 2014-06-27 00:01 UTC by meidingerc1
Modified: 2014-06-27 03:23 UTC (History)
0 users

See Also:
Known to work:
Known to fail:
Last reconfirmed:

The source and .i and others required by the instructions. (10.59 KB, application/x-bzip2)
2014-06-27 00:01 UTC, meidingerc1

Note You need to log in before you can comment on or make changes to this bug.
Description meidingerc1 2014-06-27 00:01:22 UTC
Created attachment 33015 [details]
The source and .i and others required by the instructions.

This code:

#include <stdio.h>

int main() {
    long long sm = 0x7FFFFFFFFFFFFFFF;
    double dm = (double)sm;
    double value = 9223372036854775800.0;
    printf("%s\n", (((double)sm) == value ? "true" : "false"));
    printf("%s\n", (dm ==           value ? "true" : "false"));

causes the problem.
One would expect that both lines of output would be the same, but the bug causes
the output to be

The bug occurs in gcc version 4.8.2 on the 32-bit Intel version of Kubuntu 14.04.
It also occurs in g++ version 4.8.2 on the same system, and on other current and recent 32-bit Intel releases of Kubuntu and Fedora with various versions of g++ 4.7 and 4.8.

The bug does not occur in g++ on any 64-bit Intel system I tried, with versions 4.7.* and 4.8.*.
The bug does not occur in g++ on a 32-bit ARM system (Chromebook) running Gentoo and g++ version 4.8.2.

Furthermore, the bug does not occur in gcc or g++ version 4.9.0 on the 32-bit version of Kubuntu 14.04.
Was the bug fixed by accident or purposefully?  I couldn't find any mention of the bug in the database.

Perhaps the only actions needed are to figure out why the bug occurs in earlier versions, and add a regression test to make sure it doesn't recur.

A .tar.bz2 file containg the relevant files is attached.
Comment 1 Andrew Pinski 2014-06-27 00:06:54 UTC
Dup of bug 323.

*** This bug has been marked as a duplicate of bug 323 ***
Comment 2 meidingerc1 2014-06-27 01:43:30 UTC
I dispute that bug 61626 is a duplicate of 323.  The 323 bug doesn't show up on the system where I confirmed 61626.
Comment 3 Andrew Pinski 2014-06-27 03:23:28 UTC
0x7FFFFFFFFFFFFFFF is not exactly presentably in 64bit (double) precision floating point.  But is 80bit (the underlying precision of x86/x87).  So yes this is exactly the same issue as bug 323.