#11292: Generics unboxed types: TEST=GEq1 WAY=optasm is failing -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11312 | Differential Rev(s): Phab:D1714 Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [comment:8 simonpj]:
Where is this `eqAddr#` test coming from?? It's utterly bogus to compare two strings by address. This is functional programming!
I'm very uncomfortable about "fixing" this by some new delicate stuff
We have to test `eqAddr#` here because that's how `deriving Eq` deals with `Addr#`. `Addr#` is [http://git.haskell.org/ghc.git/blob/2f923ce2ab8bad6d01645c735c81bbf1b9ff1e05... one of six] privileged unlifted types which a datatype can have and still have a derived `Eq`/`Ord` instance. Internally, the `deriving` machinery compares `Addr#` fields in a datatype with `eqAddr#`/`ltAddr#`/etc., so this test just checks to see if GHC generics is equally as expressive. like NOINLINE pragmas, especially as they are entirely un-explained. I'm inclined to agree, but if we do fix this, we'd probably need to change the way `Addr#` is dealt with in datatypes as well for the sake of consistency. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11292#comment:9 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler