I can tell you exactly where it's created: line 2107 of `Simplify.lhs` (in today's HEAD), in function `simplAlt`.
However I'm suspicious of adding a special case for float/double here. Rather, I think we should prohibit using Core-language `case` expressions to scrutinise float/double, so that `case` (in Core) behaves in a simple,
#9238: Negative zero broken -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #7858, #9451 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): Replying to [comment:6 simonpj]: predictable way.
Rather I think we should probably generate {{{ case eqDouble# ds1 0.0## of True -> ... False -> ... }}} (or, rather, today's unboxed-boolean version). Now the magic is
confined to how `eqDouble#` is implemented, which is the proper place for it. simonpj, how do you think your suggestion should interact with the `litEq` rule? As far as I can tell this `PrelRule` is responsible for most of the floating-point pattern matches that we are seeing. As you essentially suggesting we disable `litEq` for floating-point types? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9238#comment:13 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler