#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 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 Ben Gamari ): 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: 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