Re: [GHC] #5889: -fno-prof-count-entries leads to linking errors

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [GHC] #5889: -fno-prof-count-entries leads to linking errors

GHC - devs mailing list
#5889: -fno-prof-count-entries leads to linking errors
-------------------------------------+-------------------------------------
        Reporter:  akio              |                Owner:  bgamari
            Type:  bug               |               Status:  new
        Priority:  highest           |            Milestone:  8.4.1
       Component:  Compiler          |              Version:  8.3
      Resolution:                    |             Keywords:
Operating System:  Linux             |         Architecture:  x86_64
                                     |  (amd64)
 Type of failure:  GHC rejects       |            Test Case:
  valid program                      |  profiling/should_compile/T5889
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by osa1):

 I just realized that in the test program `-fspec-constr` eliminates the
 cost centers in the use site. So

 - `-O` fails, cost centers are there in the use site
 - `-O -fspec-constr` works

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5889#comment:19>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler

_______________________________________________
ghc-tickets mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-tickets
Reply | Threaded
Open this post in threaded view
|

Re: [GHC] #5889: -fno-prof-count-entries leads to linking errors

GHC - devs mailing list
#5889: -fno-prof-count-entries leads to linking errors
-------------------------------------+-------------------------------------
        Reporter:  akio              |                Owner:  bgamari
            Type:  bug               |               Status:  new
        Priority:  highest           |            Milestone:  8.4.1
       Component:  Compiler          |              Version:  8.3
      Resolution:                    |             Keywords:
Operating System:  Linux             |         Architecture:  x86_64
                                     |  (amd64)
 Type of failure:  GHC rejects       |            Test Case:
  valid program                      |  profiling/should_compile/T5889
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by osa1):

 I just checked what simplifier pass optimizes these cost centers in the
 definition site, and then checked why the same pass does not optimize the
 same way in the use site. The pass is `post-worker-wrapper`. Before the
 pass `bar` looks like this:

 {{{
 bar
   = \ (n_a1Gx :: Integer) (m_a1Gy [Dmd=<S,U>] :: Maybe Integer) ->
       scc<bar>
       let {
         ds_s2rs [Dmd=<S(SS),U(U,U)>] :: (Integer, Integer)
         [LclId,
          Unf=Unf{Src=<vanilla>, TopLvl=False, Value=False, ConLike=False,
                  WorkFree=False, Expandable=False, Guidance=IF_ARGS [] 30
 0}]
         ds_s2rs
           = let {
               ds_s2rs [Dmd=<S(SS),U(U,U)>] :: (Integer, Integer)
               [LclId,
                Unf=Unf{Src=<vanilla>, TopLvl=False, Value=False,
 ConLike=False,
                        WorkFree=False, Expandable=False, Guidance=IF_ARGS
 [] 30 0}]
               ds_s2rs = scc<bar.(...)> split n_a1Gx m_a1Gy } in
             case ds_s2rs of ww_s2sc
             { (ww_s2sd [Dmd=<S,U>], ww_s2se [Dmd=<S,U>]) ->
                 (ww_s2sd, ww_s2se)
             } in
       plus_noinline
         (scc<bar.y>
          case ds_s2rs of { (y_a2pz [Dmd=<S,U>], z_a2pB [Dmd=<L,A>]) ->
          y_a2pz
          })
         (scc<bar.z>
          case ds_s2rs of { (y_a2pz [Dmd=<L,A>], z_a2pB [Dmd=<S,U>]) ->
          z_a2pB
          })
 }}}

 after:

 {{{
 bar
   = \ (n_a1Gx :: Integer) (m_a1Gy :: Maybe Integer) ->
       scc<bar>
       case scc<bar.(...)> split n_a1Gx m_a1Gy of
       { (ww_s2sd [Dmd=<S,U>], ww_s2se [Dmd=<S,U>]) ->
       plus_noinline ww_s2sd ww_s2se
       }
 }}}


 The same pass in `A` does nothing. The program before and after the pass
 looks like this:

 {{{
 ds_s4uU :: (Integer, Integer)
 [LclId,
  Unf=Unf{Src=<vanilla>, TopLvl=True, Value=False, ConLike=False,
          WorkFree=False, Expandable=False, Guidance=IF_ARGS [] 50 30}]
 ds_s4uU
   = scc<bar>
     scc<bar.(...)>
     case B.$wsplit n_s4uS (GHC.Base.Nothing @ Integer) of
     { (# ww1_s2sg, ww2_s2sh #) ->
     (ww1_s2sg, ww2_s2sh)
     }

 main_s37c :: String
 [LclId,
  Unf=Unf{Src=<vanilla>, TopLvl=True, Value=False, ConLike=False,
          WorkFree=False, Expandable=False, Guidance=IF_ARGS [] 110 30}]
 main_s37c
   = case GHC.Show.$w$cshowsPrec4
            0#
            (scc<bar>
             plus_noinline
               (scc<bar.y>
                case ds_s4uU of { (y_a2pz [Dmd=<S,U>], z_a2pB [Dmd=<L,A>])
 ->
                y_a2pz
                })
               (scc<bar.z>
                case ds_s4uU of { (y_a2pz [Dmd=<L,A>], z_a2pB [Dmd=<S,U>])
 ->
                z_a2pB
                }))
            (GHC.Types.[] @ Char)
     of
     { (# ww3_a376, ww4_a377 #) ->
     GHC.Types.: @ Char ww3_a376 ww4_a377
     }
 }}}

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5889#comment:20>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler

_______________________________________________
ghc-tickets mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-tickets
Reply | Threaded
Open this post in threaded view
|

Re: [GHC] #5889: -fno-prof-count-entries leads to linking errors

GHC - devs mailing list
In reply to this post by GHC - devs mailing list
#5889: -fno-prof-count-entries leads to linking errors
-------------------------------------+-------------------------------------
        Reporter:  akio              |                Owner:  bgamari
            Type:  bug               |               Status:  new
        Priority:  highest           |            Milestone:  8.4.1
       Component:  Compiler          |              Version:  8.3
      Resolution:                    |             Keywords:
Operating System:  Linux             |         Architecture:  x86_64
                                     |  (amd64)
 Type of failure:  GHC rejects       |            Test Case:
  valid program                      |  profiling/should_compile/T5889
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by osa1):

 I wonder if this could be related with inlining worker for `split`. This
 program

 {{{
 import A

 {-# NOINLINE b #-}
 b :: Integer
 b = bar 100 Nothing
 }}}

 compiles to

 {{{
 ds_r4vL :: (Integer, Integer)
 [GblId]
 ds_r4vL
   = scc<bar>
     scc<bar.(...)>
     case B.$wsplit n_r4u9 (GHC.Base.Nothing @ Integer) of
     { (# ww1_s2sg, ww2_s2sh #) ->
     (ww1_s2sg, ww2_s2sh)
     }

 b [InlPrag=NOINLINE] :: Integer
 [GblId]
 b = scc<bar>
     plus_noinline
       (scc<bar.y> case ds_r4vL of { (y_a2pz, z_a2pB) -> y_a2pz })
       (scc<bar.z> case ds_r4vL of { (y_a2pz, z_a2pB) -> z_a2pB })
 }}}

 and fails the same way.

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5889#comment:21>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler

_______________________________________________
ghc-tickets mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-tickets
Reply | Threaded
Open this post in threaded view
|

Re: [GHC] #5889: -fno-prof-count-entries leads to linking errors

GHC - devs mailing list
In reply to this post by GHC - devs mailing list
#5889: -fno-prof-count-entries leads to linking errors
-------------------------------------+-------------------------------------
        Reporter:  akio              |                Owner:  bgamari
            Type:  bug               |               Status:  new
        Priority:  highest           |            Milestone:  8.4.1
       Component:  Compiler          |              Version:  8.3
      Resolution:                    |             Keywords:
Operating System:  Linux             |         Architecture:  x86_64
                                     |  (amd64)
 Type of failure:  GHC rejects       |            Test Case:
  valid program                      |  profiling/should_compile/T5889
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by bgamari):

 > The same pass in A does nothing.

 osa1, can you clarify what `A` is?

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5889#comment:22>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler

_______________________________________________
ghc-tickets mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-tickets
Reply | Threaded
Open this post in threaded view
|

Re: [GHC] #5889: -fno-prof-count-entries leads to linking errors

GHC - devs mailing list
In reply to this post by GHC - devs mailing list
#5889: -fno-prof-count-entries leads to linking errors
-------------------------------------+-------------------------------------
        Reporter:  akio              |                Owner:  bgamari
            Type:  bug               |               Status:  new
        Priority:  highest           |            Milestone:  8.4.1
       Component:  Compiler          |              Version:  8.3
      Resolution:                    |             Keywords:
Operating System:  Linux             |         Architecture:  x86_64
                                     |  (amd64)
 Type of failure:  GHC rejects       |            Test Case:
  valid program                      |  profiling/should_compile/T5889
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by osa1):

 > osa1, can you clarify what A is?

 It's the module A in the test case
 (testsuite/tests/profiling/should_compile/T5889/A.hs) and B is the module
 B.

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5889#comment:23>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler

_______________________________________________
ghc-tickets mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-tickets
Reply | Threaded
Open this post in threaded view
|

Re: [GHC] #5889: -fno-prof-count-entries leads to linking errors

GHC - devs mailing list
In reply to this post by GHC - devs mailing list
#5889: -fno-prof-count-entries leads to linking errors
-------------------------------------+-------------------------------------
        Reporter:  akio              |                Owner:  bgamari
            Type:  bug               |               Status:  new
        Priority:  highest           |            Milestone:  8.4.1
       Component:  Compiler          |              Version:  8.3
      Resolution:                    |             Keywords:
Operating System:  Linux             |         Architecture:  x86_64
                                     |  (amd64)
 Type of failure:  GHC rejects       |            Test Case:
  valid program                      |  profiling/should_compile/T5889
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by osa1):

 We discussed this with @bgamari on IRC and I did some experimenting with
 the flags, and I think this story makes sense:

 Answer to question "why are these cost centers eliminated in the
 definition site (in module B) but not in use site (in module A)" is
 because worker for `split` is not inlined in module A. It's inlined when I
 compile module B with `-fspec-constr`:

 {{{
 Inlining done: B.$wsplit
     Inlined fn:  \ (w :: GHC.Integer.Type.Integer)
                    (w1 [Occ=Once!] :: GHC.Base.Maybe
 GHC.Integer.Type.Integer) ->
                    case w1 of {
                      GHC.Base.Nothing ->
                        (# scc<split> B.plus_noinline w B.split3,
                           scc<split> B.plus_noinline w B.split2 #);
                      GHC.Base.Just m ->
                        case scc<split> GHC.Integer.Type.eqInteger# w
 B.split1 of {
                          __DEFAULT ->
                            scc<split>
                            B.split_$s$wsplit m
 (GHC.Integer.Type.minusInteger w B.split3);
                          1# -> (# m, m #)
                        }
                    }
     Cont:   ApplyToVal nodup w
             ApplyToVal nodup w1
             Select nodup ww
             Stop[BoringCtxt] (GHC.Integer.Type.Integer,
                               GHC.Integer.Type.Integer)
 }}}

 with this I no longer get any linker errors.

 In comment:19 I said that `SpecConstr` pass doesn't actually change the
 program -- this is correct, we don't need `SpecConstr` in A, we need it in
 B to make the worker for `split` available in module A. Once we compile
 `B` with `-fspec-constr` the worker becomes available in when compiling
 `A`.

 Hopefully this explains.

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5889#comment:24>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler

_______________________________________________
ghc-tickets mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-tickets
Reply | Threaded
Open this post in threaded view
|

Re: [GHC] #5889: -fno-prof-count-entries leads to linking errors

GHC - devs mailing list
In reply to this post by GHC - devs mailing list
#5889: -fno-prof-count-entries leads to linking errors
-------------------------------------+-------------------------------------
        Reporter:  akio              |                Owner:  bgamari
            Type:  bug               |               Status:  new
        Priority:  highest           |            Milestone:  8.4.1
       Component:  Compiler          |              Version:  8.3
      Resolution:                    |             Keywords:
Operating System:  Linux             |         Architecture:  x86_64
                                     |  (amd64)
 Type of failure:  GHC rejects       |            Test Case:
  valid program                      |  profiling/should_compile/T5889
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by duog):

 I found your analysis instructive osa1, thank you.

 My current understanding is now that the cost-centres are, modulo bugs,
 removed when they aren't wrapping any work. I don't think we have any
 examples here of erroneous cost-centre removal, do you agree?

 As for how to implement alternative (2) in comment:10, Note [inline scc]
 summarises the difficulty:
 {{{
 -- Note [inline sccs]
 --
 -- It should be reasonable to add ticks to INLINE functions; however
 -- currently this tickles a bug later on because the SCCfinal pass
 -- does not look inside unfoldings to find CostCentres.  It would be
 -- difficult to fix that, because SCCfinal currently works on STG and
 -- not Core (and since it also generates CostCentres for CAFs,
 -- changing this would be difficult too).
 }}}

 Could we collect SCCs from all unfoldings in `corePrepPgm`, and union them
 with the result of `myCoreToStg`? What could go wrong? Are there any
 pathological scenarios where large numbers of SCCs would be created?

 That would fix the bug alluded to in the note, so if we go forward with
 that idea let's not forget to update the note and create a ticket for the
 task of reevaluating the sites referencing said note.

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5889#comment:25>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler

_______________________________________________
ghc-tickets mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-tickets
Reply | Threaded
Open this post in threaded view
|

Re: [GHC] #5889: -fno-prof-count-entries leads to linking errors

GHC - devs mailing list
In reply to this post by GHC - devs mailing list
#5889: -fno-prof-count-entries leads to linking errors
-------------------------------------+-------------------------------------
        Reporter:  akio              |                Owner:  bgamari
            Type:  bug               |               Status:  new
        Priority:  highest           |            Milestone:  8.4.1
       Component:  Compiler          |              Version:  8.3
      Resolution:                    |             Keywords:
Operating System:  Linux             |         Architecture:  x86_64
                                     |  (amd64)
 Type of failure:  GHC rejects       |            Test Case:
  valid program                      |  profiling/should_compile/T5889
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by osa1):

 > My current understanding is now that the cost-centres are, modulo bugs,
 removed when they aren't wrapping any work. I don't think we have any
 examples here of erroneous cost-centre removal, do you agree?

 Well, this ticket iself is an example of erroneous cost-centre removal,
 isn't it?

 I don't know answers to other questions, but I think the right thing to do
 here is to collect cost-centers in Core instead of STG (maybe in
 coreToStg).

 Because unfoldings are just Core expressions, once we have the code for
 collecting cost centers from unfoldings we can just use the same function
 for the actual program so no need for two functions for collecting cost
 centers (one collects from Core, another one from STG). So once we write
 this we can get rid of cost center collection in STG,
 `stgMassageForProfiling` would just add CAF cost centers.

 On a related note, I found this in the user manual: (8.1.1)

 > Cost centres are just program annotations. When you say -fprof-auto to
 the compiler, it automatically inserts a cost centre annotation around
 every binding not marked INLINE in your program, but you are entirely free
 to add cost centre annotations yourself.

 So GHC by default avoids this bug by not adding SCCs to INLINE functions
 but if you do it yourself you get this bug in some cases.

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5889#comment:26>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler

_______________________________________________
ghc-tickets mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-tickets
Reply | Threaded
Open this post in threaded view
|

Re: [GHC] #5889: -fno-prof-count-entries leads to linking errors

GHC - devs mailing list
In reply to this post by GHC - devs mailing list
#5889: -fno-prof-count-entries leads to linking errors
-------------------------------------+-------------------------------------
        Reporter:  akio              |                Owner:  bgamari
            Type:  bug               |               Status:  new
        Priority:  highest           |            Milestone:  8.4.1
       Component:  Compiler          |              Version:  8.3
      Resolution:                    |             Keywords:
Operating System:  Linux             |         Architecture:  x86_64
                                     |  (amd64)
 Type of failure:  GHC rejects       |            Test Case:
  valid program                      |  profiling/should_compile/T5889
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by duog):

 Replying to [comment:26 osa1]:
 > > My current understanding is now that the cost-centres are, modulo
 bugs, removed when they aren't wrapping any work. I don't think we have
 any examples here of erroneous cost-centre removal, do you agree?
 >
 > Well, this ticket iself is an example of erroneous cost-centre removal,
 isn't it?

 To be more precise, I claim that there are no simplifier bugs here; all of
 the `scc`s that are removed (by the simplifier) in the examples above are
 ok to remove.  If you disagree, can you point to one above?

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5889#comment:27>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler

_______________________________________________
ghc-tickets mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-tickets
Reply | Threaded
Open this post in threaded view
|

Re: [GHC] #5889: -fno-prof-count-entries leads to linking errors

GHC - devs mailing list
In reply to this post by GHC - devs mailing list
#5889: -fno-prof-count-entries leads to linking errors
-------------------------------------+-------------------------------------
        Reporter:  akio              |                Owner:  bgamari
            Type:  bug               |               Status:  new
        Priority:  highest           |            Milestone:  8.4.1
       Component:  Compiler          |              Version:  8.3
      Resolution:                    |             Keywords:
Operating System:  Linux             |         Architecture:  x86_64
                                     |  (amd64)
 Type of failure:  GHC rejects       |            Test Case:
  valid program                      |  profiling/should_compile/T5889
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by bgamari):

 I think we all agree that the simplifier is not at fault here. Indeed the
 approach that duog mentions comment:25 is roughly what osa1 and I have
 discussed. However, it's slightly tricky as unfoldings are currently
 dropped before we make it to `core2Stg` (in CorePrep). I doubt this will
 unacceptably increase the number of emitted cost centers although I've
 been wrong before.

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5889#comment:28>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler

_______________________________________________
ghc-tickets mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-tickets
Reply | Threaded
Open this post in threaded view
|

Re: [GHC] #5889: -fno-prof-count-entries leads to linking errors

GHC - devs mailing list
In reply to this post by GHC - devs mailing list
#5889: -fno-prof-count-entries leads to linking errors
-------------------------------------+-------------------------------------
        Reporter:  akio              |                Owner:  bgamari
            Type:  bug               |               Status:  new
        Priority:  highest           |            Milestone:  8.4.1
       Component:  Compiler          |              Version:  8.3
      Resolution:                    |             Keywords:
Operating System:  Linux             |         Architecture:  x86_64
                                     |  (amd64)
 Type of failure:  GHC rejects       |            Test Case:
  valid program                      |  profiling/should_compile/T5889
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by osa1):

 Simon, we were wrong about CorePrep not dropping unfoldings for exported
 ids, it really drops all unfoldings. There's a note

 {{{
 {- Note [Drop unfoldings and rules]
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 We want to drop the unfolding/rules on every Id:

   - We are now past interface-file generation, and in the
     codegen pipeline, so we really don't need full unfoldings/rules

   - The unfolding/rule may be keeping stuff alive that we'd like
     to discard.  See  Note [Dead code in CorePrep]

   - Getting rid of unnecessary unfoldings reduces heap usage

   - We are changing uniques, so if we didn't discard unfoldings/rules
     we'd have to substitute in them

 HOWEVER, we want to preserve evaluated-ness; see
 Note [Preserve evaluated-ness in CorePrep]

 Note [Preserve evaluated-ness in CorePrep]
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 We want to preserve the evaluated-ness of each binder (via
 evaldUnfolding) for two reasons

 * In the code generator if we have
      case x of y { Red -> e1; DEFAULT -> y }
   we can return 'y' rather than entering it, if we know
   it is evaluated (Trac #14626)

 * In the DataToTag magic (in CorePrep itself) we rely on
   evaluated-ness.  See Note Note [dataToTag magic].
 -}
 }}}

 I can also clearly see that in the code we don't distinguish exported from
 non-exported, we just zap all unfoldings (see `cpCloneBndrs` and
 `zapUnfolding`).

 So it seems to me like we may have to collect cost centers before or
 during CorePrep. I vaguely remember discussing this in the meeting and one
 of the arguments against this was that `CorePrep` is already complex
 enough so if possible it'd be nice to avoid making it even more complex.
 Are there any other reasons for not doing this in CorePrep? Can we maybe
 implement a pass before CorePrep just for cost center collection?

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5889#comment:29>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler

_______________________________________________
ghc-tickets mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-tickets
Reply | Threaded
Open this post in threaded view
|

Re: [GHC] #5889: -fno-prof-count-entries leads to linking errors

GHC - devs mailing list
In reply to this post by GHC - devs mailing list
#5889: -fno-prof-count-entries leads to linking errors
-------------------------------------+-------------------------------------
        Reporter:  akio              |                Owner:  bgamari
            Type:  bug               |               Status:  patch
        Priority:  highest           |            Milestone:  8.4.1
       Component:  Compiler          |              Version:  8.3
      Resolution:                    |             Keywords:
Operating System:  Linux             |         Architecture:  x86_64
                                     |  (amd64)
 Type of failure:  GHC rejects       |            Test Case:
  valid program                      |  profiling/should_compile/T5889
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):  Phab:D4325
       Wiki Page:                    |
-------------------------------------+-------------------------------------
Changes (by osa1):

 * status:  new => patch
 * differential:   => Phab:D4325


--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5889#comment:30>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler

_______________________________________________
ghc-tickets mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-tickets