[GHC] #12628: __GLASGOW_HASKELL_LLVM__ is no longer an Int
#12628: __GLASGOW_HASKELL_LLVM__ is no longer an Int -------------------------------------+------------------------------------- Reporter: nicolast | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Driver | Version: 8.0.1 Keywords: llvm cpp | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- From the user guide (http://ghc.readthedocs.io/en/8.0.1/phases.html#index-8) {{{ __GLASGOW_HASKELL_LLVM__ Only defined when -fllvm is specified. When GHC is using version x.y.z of LLVM, the value of __GLASGOW_HASKELL_LLVM__ is the integer ⟨xy⟩. }}} This is not the case, though, due to 29310b622801733e1b29a9a61988406872db13ca which changes {{{figureLlvmVersion :: DynFlags -> IO (Maybe Int)}}} into {{{figureLlvmVersion :: DynFlags -> IO (Maybe (Int, Int))}}}, and the driver just {{{show}}}ing the result (https://github.com/ghc/ghc/blob/29310b622801733e1b29a9a61988406872db13ca/com...) As a result, the macro value which used to be a numeric value is now something like {{{(3, 7)}}}. I'm now using a work-around (https://github.com/NicolasT/reedsolomon/commit/9d25ad6a26a29c90b82daacbf4063...), but ''or'' the 'tuple value' should become 'official API', ''or'' this is a regression to be fixed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12628> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler
#12628: __GLASGOW_HASKELL_LLVM__ is no longer an Int -------------------------------------+------------------------------------- Reporter: nicolast | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Driver | Version: 8.0.1 Resolution: | Keywords: llvm cpp Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nicolast): Working on a patch to restore old behaviour. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12628#comment:1> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler
#12628: __GLASGOW_HASKELL_LLVM__ is no longer an Int -------------------------------------+------------------------------------- Reporter: nicolast | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Driver | Version: 8.0.1 Resolution: | Keywords: llvm cpp Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Thanks nicolast! However, I wonder whether we should take this opportunity to apply a bit of foresight. In particular what happens when we reach LLVM 3.10? Or for that matter 10.0? Perhaps we should either, * split this macro up into `__GLASGOW_HASKELL_LLVM_MAJOR_VERSION__` and `__GLASGOW_HASKELL_LLVM_MINOR_VERSION__`, or * pad `__GLASGOW_HASKELL_LLVM__` with zeros to ensure that we have room to grow (although this would sadly not be backwards compatible). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12628#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler
#12628: __GLASGOW_HASKELL_LLVM__ is no longer an Int -------------------------------------+------------------------------------- Reporter: nicolast | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Driver | Version: 8.0.1 Resolution: | Keywords: llvm cpp Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nicolast): I considered this as well, and the pre-8.0.1 behaviour is indeed prone to the examples you provided, so simply reverting to the old method may not be the way to go. Proposal: - Consider the 8.0.1 'tuple' value to be a mistake/oversight and use a plain integer anyway - Format {{{__GLASGOW_HASKELL_LLVM__}} similar to {{__GLASGOW_HASKELL__}}}: {{{ __GLASGOW_HASKELL__ For version x.y.z of GHC, the value of __GLASGOW_HASKELL__ is the integer ⟨xyy⟩ (if ⟨y⟩ is a single digit, then a leading zero is added, so for example in version 6.2 of GHC, __GLASGOW_HASKELL__==602). More information in GHC version numbering policy. }}} I believe this encoding should be fine and, in a way, backwards compatible: - *Or* one was using GHC < 8, which has {{{__GLASGOW_HASKELL_LLVM__}}} defined as {{{34}}}, {{{35}}} or whichever other version was ever supported - *Or* one is using GHC 8.0.1, and a specific work-around to handle the tuple case - *Or* one is using GHC > 8.0.1, and (for now) {{{__GLASGOW_HASKELL_LLVM__}}} will be {{{307}}}. *If* one was using the macro value in a conditional, then - Or one was doing an equality check, which will still work out nicely: or it's some old LLVM version, or it's LLVM 3.7 for GHC 8.0.1 (tuple), or it's 307 - Or one was doing a comparison. Again, we can exclude the GHC 8.0.1 case. If one checks whether the LLVM version is, say, 3.5 or lower, then {{{__GLASGOW_HASKELL_LLVM__ <= 35}}} will do 'the right thing' for {{{307}}} or whatever later version. - Similarly, {{{__GLASGOW_HASKELL_LLVM__ > 35}}} will work out nicely for {{{307}}}. As such, I believe that if we make the change (add padding) now, things should be 'morally' backwards compatible. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12628#comment:3> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler
#12628: __GLASGOW_HASKELL_LLVM__ is no longer an Int -------------------------------------+------------------------------------- Reporter: nicolast | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Driver | Version: 8.0.1 Resolution: | Keywords: llvm cpp Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by erikd): +1 for `307`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12628#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler
#12628: __GLASGOW_HASKELL_LLVM__ is no longer an Int -------------------------------------+------------------------------------- Reporter: nicolast | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Driver | Version: 8.0.1 Resolution: | Keywords: llvm cpp Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari <ben@…>): In [changeset:"b0d53a839da0149e0142da036b6ebf5a01b3216f/ghc" b0d53a83/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b0d53a839da0149e0142da036b6ebf5a01b3216f" Turn `__GLASGOW_HASKELL_LLVM__` into an integer again In GHC < 8.0.1, the value of `__GLASGOW_HASKELL_LLVM__`, exposed through the preprocessor when compiled with `-fllvm`, was an integer value, encoded according to some rules specified in the user guide. Due to an oversight, in GHC 8.0.1 the value of this define became a tuple, exposed as e.g. `(3, 7)`. This was an unintended regression. This patch turns the value of the `__GLASGOW_HASKELL_LLVM__` definition into a single integer again, but changes the formatting of said number slightly. Before, any LLVM version where the major or minor component >= 10 would cause ambiguous values for `__GLASGOW_HASKELL_LLVM__`. With this patch, the value is in line with `__GLASGOW_HASKELL__`, adding a padding `0` in-between major and minor component if applicable (we assume no minors >= 100 will ever exist). The documentation in the user guide is updated accordingly, and a reference is made in the 8.0.2 release notes. Test Plan: validate Reviewers: bgamari, erikd Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2552 GHC Trac Issues: #12628 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12628#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler
#12628: __GLASGOW_HASKELL_LLVM__ is no longer an Int -------------------------------------+------------------------------------- Reporter: nicolast | Owner: Type: bug | Status: merge Priority: normal | Milestone: 8.0.2 Component: Driver | Version: 8.0.1 Resolution: | Keywords: llvm cpp Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => merge -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12628#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler
#12628: __GLASGOW_HASKELL_LLVM__ is no longer an Int -------------------------------------+------------------------------------- Reporter: nicolast | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Driver | Version: 8.0.1 Resolution: fixed | Keywords: llvm cpp Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: comment:5 merged to `ghc-8.0` as 3b13a0426f59b47fb27646c694caf1df55a684e3. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12628#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler
participants (1)
-
GHC