[GHC] #12628: __GLASGOW_HASKELL_LLVM__ is no longer an Int

[GHC]

#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