Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
  • Sign in / Register
GHC
GHC
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 4,248
    • Issues 4,248
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
    • Iterations
  • Merge Requests 391
    • Merge Requests 391
  • Requirements
    • Requirements
    • List
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
  • Security & Compliance
    • Security & Compliance
    • Dependency List
    • License Compliance
  • Operations
    • Operations
    • Incidents
    • Environments
  • Analytics
    • Analytics
    • CI / CD
    • Code Review
    • Insights
    • Issue
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
  • Glasgow Haskell Compiler
  • GHCGHC
  • Issues
  • #5165

Closed
Open
Opened May 01, 2011 by Edward Z. Yang@ezyangDeveloper

GHC doesn't optimize FP excess precision properly

jmcarthur helped in constructing the test case. Consider the following program:

module Main where

{-# NOINLINE x #-}
{-# NOINLINE y #-}
x, y :: Double
x = 3
y = 7

main = print $ x/y == (3/7 :: Double)

When run on 32-bit Linux, we get the following results:

ezyang@javelin:~$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.0.3
ezyang@javelin:~$ ghc --make Bar.hs -o Bar -O0 -fforce-recomp && ./Bar
[1 of 1] Compiling Main             ( Bar.hs, Bar.o )
Linking Bar ...
True
ezyang@javelin:~$ ghc --make Bar.hs -o Bar -O -fforce-recomp && ./Bar
[1 of 1] Compiling Main             ( Bar.hs, Bar.o )
Linking Bar ...
False

The second result should be True (and only false if -fexcess-precision is specified). I also tested on a devel2 build of GHC HEAD and got similar results.

This appears to be a regression from 6.12.1:

ezyang@javelin:~$ /usr/bin/ghc --version
The Glorious Glasgow Haskell Compilation System, version 6.12.1
ezyang@javelin:~$ /usr/bin/ghc --make Bar.hs -o Bar -O && ./Bar
True

I also kind of suspect -fexcess-precision doesn't do anything for the native codegen (based on source code surfing), but it's hard to tell with this current bug.

Trac metadata
Trac field Value
Version 7.1
Type Bug
TypeOfFailure OtherFailure
Priority normal
Resolution Unresolved
Component Compiler
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Architecture
Assignee
Assign to
7.6.1
Milestone
7.6.1
Assign milestone
Time tracking
None
Due date
None
Reference: ghc/ghc#5165