Re: performance regressions

[Joachim Breitner]

Hi,

Am Sonntag, den 14.12.2014, 22:37 -0500 schrieb Richard Eisenberg:
> Of course, I now see that it wasn't a full fix.
> 
> This is all most assuredly my fault.

I wouldn’t call it a fault. Where wood is chopped, splinters must fall.
(Hopefully correct translation of a German idiom.)

We don’t _have_ to catch everything before it hits master, it is already
pretty good if we manage to catch and fix regressions later.

I guess we could use the known_broken feature of the test suite more
quickly, to signal that an issue is being worked on and to avoid others
from stumbling over test suite failures.

> - Travis has not picked up on these errors.

unfortunately, travis is slighly less useful since a few weeks due to
T5681 failing (possibly due to the use of LLVM-3.4), but I’m still
waiting for an reply on that issue.

But it wouldn’t have helped you: Travis generally skips all performance
tests. These used to be far less reliable when I set up travis (this got
better due to the removal of some of the max_bytes_allocated tests, and
also due to harbormaster and ghcspeed monitoring), and also because we
still hardly make the 50 minute deadline on Travis.

So do not rely on Travis for performance measurements.
(This is documented on https://ghc.haskell.org/trac/ghc/wiki/Travis, but
it needs to become common knowledge.)


Greetings,
Joachim

-- 
Joachim “nomeata” Breitner
  m...@joachim-breitner.de • http://www.joachim-breitner.de/
  Jabber: nome...@joachim-breitner.de  • GPG-Key: 0xF0FBF51F
  Debian Developer: nome...@debian.org



signature.asc
Description: This is a digitally signed message part
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Reachable modules from DynFlags out of date

[Simon Peyton Jones]

Hum.  "Reachable modules from DynFlags out of date"   What can I do now?
Validated ok on my windows laptop.  So I'm sorry but it looks as if I have 
broken HEAD.  Could revert but I'd prefer to fix.
I did change some imports.
Thanks
Simon

HC [stage 1] compiler/stage2/build/SPARC/CodeGen.o

HC [stage 1] compiler/stage2/build/LlvmCodeGen.o

Reachable modules from DynFlags out of date


___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Reachable modules from DynFlags out of date

[Alan & Kim Zimmerman]

edit compiler/ghc.mk and change the definition of
compiler_stage2_dll0_MODULES according to your error message.

On Mon, Dec 15, 2014 at 12:58 PM, Simon Peyton Jones 
wrote:
>
>  Hum.  “Reachable modules from DynFlags out of date”   What can I do
> now?
>
> Validated ok on my windows laptop.  So I’m sorry but it looks as if I have
> broken HEAD.  Could revert but I’d prefer to fix.
>
> I did change some imports.
>
> Thanks
>
> Simon
>
>
>
> HC [stage 1] compiler/stage2/build/SPARC/CodeGen.o
>
> HC [stage 1] compiler/stage2/build/LlvmCodeGen.o
>
> Reachable modules from DynFlags out of date
>
>
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

RE: Reachable modules from DynFlags out of date

[Simon Peyton Jones]

Yes, but what change would you suggest?  The error message doesn’t suggest a 
particular change to me.

Simon

From: Alan & Kim Zimmerman [mailto:alan.z...@gmail.com]
Sent: 15 December 2014 11:16
To: Simon Peyton Jones
Cc: ghc-devs@haskell.org
Subject: Re: Reachable modules from DynFlags out of date

edit compiler/ghc.mk and change the definition of 
compiler_stage2_dll0_MODULES according to your error message.

On Mon, Dec 15, 2014 at 12:58 PM, Simon Peyton Jones 
mailto:simo...@microsoft.com>> wrote:
Hum.  “Reachable modules from DynFlags out of date”   What can I do now?
Validated ok on my windows laptop.  So I’m sorry but it looks as if I have 
broken HEAD.  Could revert but I’d prefer to fix.
I did change some imports.
Thanks
Simon

HC [stage 1] compiler/stage2/build/SPARC/CodeGen.o

HC [stage 1] compiler/stage2/build/LlvmCodeGen.o

Reachable modules from DynFlags out of date



___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Reachable modules from DynFlags out of date

[Alan & Kim Zimmerman]

When I have hit this the error message normally lists the items that should
be added or remove.

What is the full error message?

On Mon, Dec 15, 2014 at 1:20 PM, Simon Peyton Jones 
wrote:
>
>  Yes, but what change would you suggest?  The error message doesn’t
> suggest a particular change to me.
>
>
>
> Simon
>
>
>
> *From:* Alan & Kim Zimmerman [mailto:alan.z...@gmail.com]
> *Sent:* 15 December 2014 11:16
> *To:* Simon Peyton Jones
> *Cc:* ghc-devs@haskell.org
> *Subject:* Re: Reachable modules from DynFlags out of date
>
>
>
> edit compiler/ghc.mk and change the definition of
> compiler_stage2_dll0_MODULES according to your error message.
>
>
>
> On Mon, Dec 15, 2014 at 12:58 PM, Simon Peyton Jones <
> simo...@microsoft.com> wrote:
>
>  Hum.  “Reachable modules from DynFlags out of date”   What can I do
> now?
>
> Validated ok on my windows laptop.  So I’m sorry but it looks as if I have
> broken HEAD.  Could revert but I’d prefer to fix.
>
> I did change some imports.
>
> Thanks
>
> Simon
>
>
>
> HC [stage 1] compiler/stage2/build/SPARC/CodeGen.o
>
> HC [stage 1] compiler/stage2/build/LlvmCodeGen.o
>
> Reachable modules from DynFlags out of date
>
>
>
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

RE: Reachable modules from DynFlags out of date

[Simon Peyton Jones]

This is what I have right now
https://phabricator.haskell.org/harbormaster/build/2630/

My machine is not talking to the repo today, so I can’t do a local build ☹

Simon

From: Alan & Kim Zimmerman [mailto:alan.z...@gmail.com]
Sent: 15 December 2014 11:22
To: Simon Peyton Jones
Cc: ghc-devs@haskell.org
Subject: Re: Reachable modules from DynFlags out of date

When I have hit this the error message normally lists the items that should be 
added or remove.
What is the full error message?

On Mon, Dec 15, 2014 at 1:20 PM, Simon Peyton Jones 
mailto:simo...@microsoft.com>> wrote:
Yes, but what change would you suggest?  The error message doesn’t suggest a 
particular change to me.

Simon

From: Alan & Kim Zimmerman 
[mailto:alan.z...@gmail.com]
Sent: 15 December 2014 11:16
To: Simon Peyton Jones
Cc: ghc-devs@haskell.org
Subject: Re: Reachable modules from DynFlags out of date

edit compiler/ghc.mk and change the definition of 
compiler_stage2_dll0_MODULES according to your error message.

On Mon, Dec 15, 2014 at 12:58 PM, Simon Peyton Jones 
mailto:simo...@microsoft.com>> wrote:
Hum.  “Reachable modules from DynFlags out of date”   What can I do now?
Validated ok on my windows laptop.  So I’m sorry but it looks as if I have 
broken HEAD.  Could revert but I’d prefer to fix.
I did change some imports.
Thanks
Simon

HC [stage 1] compiler/stage2/build/SPARC/CodeGen.o

HC [stage 1] compiler/stage2/build/LlvmCodeGen.o

Reachable modules from DynFlags out of date



___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Reachable modules from DynFlags out of date

[Alan & Kim Zimmerman]

I suspect you need to add all of

Extra modules: AsmCodeGen ByteCodeGen ByteCodeLink CPrim CSE CallArity
CgUtils Check CmmBuildInfoTables CmmCommonBlockElim CmmContFlowOpt
CmmLayoutStack CmmLex CmmLint CmmLive CmmOpt CmmParse CmmPipeline
CmmProcPoint CmmSink CodeOutput Convert CoreMonad CorePrep CoreToStg
Coverage Desugar DmdAnal DsArrows DsBinds DsCCall DsExpr DsForeign DsGRHSs
DsListComp DsMeta DsUtils DynamicLoading FamInst FlagChecker FloatIn
FloatOut FunDeps GraphBase GraphColor GraphOps GraphPpr HaddockUtils
HeaderInfo HscMain HscStats Inst Instruction LibFFI LiberateCase Linker
Llvm Llvm.AbsSyn Llvm.MetaData Llvm.PpLlvm Llvm.Types LlvmCodeGen
LlvmCodeGen.Base LlvmCodeGen.CodeGen LlvmCodeGen.Data LlvmCodeGen.Ppr
LlvmCodeGen.Regs LlvmMangler Match MatchCon MatchLit MkIface NCGMonad
ObjLink PIC PPC.CodeGen PPC.Cond PPC.Instr PPC.Ppr PPC.RegInfo PPC.Regs
Parser Plugins PprBase PprC PprTyThing ProfInit RdrHsSyn
RegAlloc.Graph.Main RegAlloc.Graph.Spill RegAlloc.Graph.SpillClean
RegAlloc.Graph.SpillCost RegAlloc.Graph.Stats RegAlloc.Graph.TrivColorable
RegAlloc.Linear.Base RegAlloc.Linear.FreeRegs RegAlloc.Linear.JoinToTargets
RegAlloc.Linear.Main RegAlloc.Linear.PPC.FreeRegs
RegAlloc.Linear.SPARC.FreeRegs RegAlloc.Linear.StackMap
RegAlloc.Linear.State RegAlloc.Linear.Stats RegAlloc.Linear.X86.FreeRegs
RegAlloc.Linear.X86_64.FreeRegs RegAlloc.Liveness RnBinds RnEnv RnExpr
RnHsDoc RnNames RnPat RnSource RnSplice RnTypes SAT SCCfinal SPARC.AddrMode
SPARC.Base SPARC.CodeGen SPARC.CodeGen.Amode SPARC.CodeGen.Base
SPARC.CodeGen.CondCode SPARC.CodeGen.Expand SPARC.CodeGen.Gen32
SPARC.CodeGen.Gen64 SPARC.CodeGen.Sanity SPARC.Cond SPARC.Imm SPARC.Instr
SPARC.Ppr SPARC.Regs SPARC.ShortcutJump SPARC.Stack SetLevels SimplCore
SimplEnv SimplMonad SimplStg SimplUtils Simplify Size SpecConstr Specialise
State StaticPtrTable StgCmm StgCmmBind StgCmmCon StgCmmExpr StgCmmExtCode
StgCmmForeign StgCmmHeap StgCmmHpc StgCmmPrim StgLint StgStats SysTools
TargetReg TcAnnotations TcArrows TcBinds TcCanonical TcClassDcl TcDefaults
TcDeriv TcEnv TcErrors TcExpr TcFlatten TcForeign TcGenDeriv TcGenGenerics
TcHsSyn TcHsType TcInstDcls TcInteract TcMType TcMatches TcPat TcPatSyn
TcRnDriver TcRules TcSMonad TcSimplify TcSplice TcTyClsDecls TcTyDecls
TcUnify TcValidity TidyPgm UnVarGraph UnariseStg Vectorise
Vectorise.Builtins Vectorise.Builtins.Base Vectorise.Builtins.Initialise
Vectorise.Convert Vectorise.Env Vectorise.Exp Vectorise.Generic.Description
Vectorise.Generic.PADict Vectorise.Generic.PAMethods
Vectorise.Generic.PData Vectorise.Monad Vectorise.Monad.Base
Vectorise.Monad.Global Vectorise.Monad.InstEnv Vectorise.Monad.Local
Vectorise.Monad.Naming Vectorise.Type.Classify Vectorise.Type.Env
Vectorise.Type.TyConDecl Vectorise.Type.Type Vectorise.Utils
Vectorise.Utils.Base Vectorise.Utils.Closure Vectorise.Utils.Hoisting
Vectorise.Utils.PADict Vectorise.Utils.Poly Vectorise.Var Vectorise.Vect
WorkWrap WwLib X86.CodeGen X86.Cond X86.Instr X86.Ppr X86.RegInfo X86.Regs

which sounds a bit extreme. I have only ever had one or two, and normally
as a result of creating a new module or adding an import to something.



On Mon, Dec 15, 2014 at 1:50 PM, Simon Peyton Jones 
wrote:
>
>  This is what I have right now
>
> https://phabricator.haskell.org/harbormaster/build/2630/
>
>
>
> My machine is not talking to the repo today, so I can’t do a local build L
>
>
>
> Simon
>
>
>
> *From:* Alan & Kim Zimmerman [mailto:alan.z...@gmail.com]
> *Sent:* 15 December 2014 11:22
>
> *To:* Simon Peyton Jones
> *Cc:* ghc-devs@haskell.org
> *Subject:* Re: Reachable modules from DynFlags out of date
>
>
>
> When I have hit this the error message normally lists the items that
> should be added or remove.
>
> What is the full error message?
>
>
>
> On Mon, Dec 15, 2014 at 1:20 PM, Simon Peyton Jones 
> wrote:
>
>  Yes, but what change would you suggest?  The error message doesn’t
> suggest a particular change to me.
>
>
>
> Simon
>
>
>
> *From:* Alan & Kim Zimmerman [mailto:alan.z...@gmail.com]
> *Sent:* 15 December 2014 11:16
> *To:* Simon Peyton Jones
> *Cc:* ghc-devs@haskell.org
> *Subject:* Re: Reachable modules from DynFlags out of date
>
>
>
> edit compiler/ghc.mk and change the definition of
> compiler_stage2_dll0_MODULES according to your error message.
>
>
>
> On Mon, Dec 15, 2014 at 12:58 PM, Simon Peyton Jones <
> simo...@microsoft.com> wrote:
>
>  Hum.  “Reachable modules from DynFlags out of date”   What can I do
> now?
>
> Validated ok on my windows laptop.  So I’m sorry but it looks as if I have
> broken HEAD.  Could revert but I’d prefer to fix.
>
> I did change some imports.
>
> Thanks
>
> Simon
>
>
>
> HC [stage 1] compiler/stage2/build/SPARC/CodeGen.o
>
> HC [stage 1] compiler/stage2/build/LlvmCodeGen.o
>
> Reachable modules from DynFlags out of date
>
>
>
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
>

RE: Implicit Locations in GHC

[Simon Peyton Jones]

Eric

I'd love to see it happen.  High payoff, low pain.

See https://ghc.haskell.org/trac/ghc/ticket/9049
No existing branch that I know of.  

I'm copying some other people who might be interested.

Let me know how I can help.

Simon

|  -Original Message-
|  From: Eric Seidel [mailto:e...@seidel.io]
|  Sent: 12 December 2014 22:11
|  To: Simon Peyton Jones
|  Subject: Implicit Locations in GHC
|  
|  Hi Simon,
|  
|  I just noticed your wiki page
|  
|  
|  https://ghc.haskell.org/trac/ghc/wiki/ExplicitCallStack/ImplicitLocati
|  ons
|  
|  Interestingly, I talked to Iavor a few weeks back about the exact same
|  idea, and briefly started working on a branch before being consumed by
|  various work things..
|  
|  Anyway, I think I may have some extra free time coming up, and I'd be
|  happy to throw some of it at implementing this proposal. Is there an
|  existing branch that I should look at?
|  
|  Eric
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Reachable modules from DynFlags out of date

[Jan Stolarek]

> I suspect you need to add all of
I believe Simon needs to figure out the diff, ie. which modules are displayed 
in the dependency 
list but are missing in the compiler/ghc.mk file. I recall I had to done the 
same in one of my 
commits:

https://github.com/jstolarek/ghc/commit/53948f915140396acd1b80c6a7a252b2d1e12635#diff-ba0ee6a425ab9ec6d7a2ef6c394ba455

Janek

___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

RE: Reachable modules from DynFlags out of date

[Simon Peyton Jones]

|  ...do you mind if I revert that one (to unbreak GHC HEAD), and you re-
|  push that commit once it's sorted out?

yes, go ahead.

I just wish I *understood* what was going on.

Sorry about this

S
|  -Original Message-
|  From: Herbert Valerio Riedel [mailto:hvrie...@gmail.com]
|  Sent: 15 December 2014 13:45
|  To: Simon Peyton Jones
|  Subject: Re: Reachable modules from DynFlags out of date
|  
|  Hello Simon,
|  
|  On 2014-12-15 at 11:58:13 +0100, Simon Peyton Jones wrote:
|  > Hum.  "Reachable modules from DynFlags out of date"   What can I do
|  now?
|  > Validated ok on my windows laptop.  So I'm sorry but it looks as if
|  I
|  > have broken HEAD.  Could revert but I'd prefer to fix.
|  > I did change some imports. 
|  
|  ...do you mind if I revert that one (to unbreak GHC HEAD), and you re-
|  push that commit once it's sorted out?
|  
|  Cheers,
|hvr
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

RE: Reachable modules from DynFlags out of date

[Simon Peyton Jones]

Aha.  I think I have it.  "Hooks" shouldn't import DsMonad.  Working on it now

|  -Original Message-
|  From: Herbert Valerio Riedel [mailto:hvrie...@gmail.com]
|  Sent: 15 December 2014 13:45
|  To: Simon Peyton Jones
|  Subject: Re: Reachable modules from DynFlags out of date
|  
|  Hello Simon,
|  
|  On 2014-12-15 at 11:58:13 +0100, Simon Peyton Jones wrote:
|  > Hum.  "Reachable modules from DynFlags out of date"   What can I do
|  now?
|  > Validated ok on my windows laptop.  So I'm sorry but it looks as if
|  I
|  > have broken HEAD.  Could revert but I'd prefer to fix.
|  > I did change some imports.
|  
|  ...do you mind if I revert that one (to unbreak GHC HEAD), and you re-
|  push that commit once it's sorted out?
|  
|  Cheers,
|hvr
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Last call for 7.8.4

[Austin Seipp]

Hello *,

I've just pushed a final round of patches to the 7.8 branch, including
the notorious Cabal fix for the -fPIC bug that was discussed earlier
in the week, and a handful of other bugfixes for ARM among other
things (/cc Joachim :)

I am planning on making the final 7.8.4 release this week; barring any
pending minor issues (e.g. build wibbles) in the tree (which I do not
think should be needed), the only thing I will commit is A) release
notes and B) the version number changes.

There will not likely be a 7.8.4-rc2, so this is a last call for any
bugs you'd like to see fixed. I may have missed something

-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: performance regressions

[Joachim Breitner]

Hi,

Am Montag, den 15.12.2014, 10:58 -0500 schrieb Ben Gamari:
> >> - Travis has not picked up on these errors.
> >
> > unfortunately, travis is slighly less useful since a few weeks due to
> > T5681 failing (possibly due to the use of LLVM-3.4), but I’m still
> > waiting for an reply on that issue.
> >
> You aren't looking for a response from me on this, are you? I just
> checked and I don't seem to have any outstanding messages from you but
> it's entirely possible I overlooked something.

this is independent of our arm issues, and I think a tad older; I did
not direct it to anyone specific.

But I guess you are likely a person that can tell what’s wrong here:

Am Sonntag, den 30.11.2014, 20:01 +0100 schrieb Joachim Breitner:
> Compile failed (status 256) errors were:
> /tmp/ghc16123_0/ghc16123_5.s: Assembler messages:
> 
> /tmp/ghc16123_0/ghc16123_5.s:26:0:
>  Error: can't resolve `.rodata' {.rodata section} - 
> `Main_zdwwork_info$def' {.text section}
> 
> /tmp/ghc16123_0/ghc16123_5.s:46:0:
>  Error: can't resolve `.rodata' {.rodata section} - `Main_work_info$def' 
> {.text section}
> 
> /tmp/ghc16123_0/ghc16123_5.s:66:0:
>  Error: can't resolve `.rodata' {.rodata section} - `Main_main1_info$def' 
> {.text section}
> 
> /tmp/ghc16123_0/ghc16123_5.s:86:0:
>  Error: can't resolve `.rodata' {.rodata section} - `Main_main_info$def' 
> {.text section}
> 
> /tmp/ghc16123_0/ghc16123_5.s:106:0:
>  Error: can't resolve `.rodata' {.rodata section} - `Main_main2_info$def' 
> {.text section}
> 
> /tmp/ghc16123_0/ghc16123_5.s:126:0:
>  Error: can't resolve `.rodata' {.rodata section} - 
> `ZCMain_main_info$def' {.text section}
> 
> *** unexpected failure for T5681(optllvm)
> 
> https://s3.amazonaws.com/archive.travis-ci.org/jobs/42557559/log.txt
> 
> Any ideas?

Is it possible that this is due the llvm version used? Do we support 3.4
in GHC HEAD?

   Using LLVM tools
  llc   : /usr/local/clang-3.4/bin/llc
  opt   : /usr/local/clang-3.4/bin/opt

(http://smart-cactus.org/~ben/posts/2014-11-28-state-of-llvm-backend.html does 
not talk about GHC HEAD explicitly. Should I look at the 7.10 row? Does that 
mean that 3.4 is not supported? Shouldn’t the build system, or at least the 
compiler, fail harder and more helpfully in this case?)


Greetings,
Joachim



-- 
Joachim “nomeata” Breitner
  m...@joachim-breitner.de • http://www.joachim-breitner.de/
  Jabber: nome...@joachim-breitner.de  • GPG-Key: 0xF0FBF51F
  Debian Developer: nome...@debian.org



signature.asc
Description: This is a digitally signed message part
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: performance regressions

[Ben Gamari]

Joachim Breitner  writes:

> Hi,
>
> Am Sonntag, den 14.12.2014, 22:37 -0500 schrieb Richard Eisenberg:

snip
>
>> - Travis has not picked up on these errors.
>
> unfortunately, travis is slighly less useful since a few weeks due to
> T5681 failing (possibly due to the use of LLVM-3.4), but I’m still
> waiting for an reply on that issue.
>
You aren't looking for a response from me on this, are you? I just
checked and I don't seem to have any outstanding messages from you but
it's entirely possible I overlooked something.

Cheers,

- Ben



pgpy6aPIougxw.pgp
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Last call for 7.8.4

[Johan Tibell]

I will make the actual cabal 1.18 release today as the RCs looked good.

On Mon, Dec 15, 2014 at 4:28 PM, Austin Seipp  wrote:
>
> Hello *,
>
> I've just pushed a final round of patches to the 7.8 branch, including
> the notorious Cabal fix for the -fPIC bug that was discussed earlier
> in the week, and a handful of other bugfixes for ARM among other
> things (/cc Joachim :)
>
> I am planning on making the final 7.8.4 release this week; barring any
> pending minor issues (e.g. build wibbles) in the tree (which I do not
> think should be needed), the only thing I will commit is A) release
> notes and B) the version number changes.
>
> There will not likely be a 7.8.4-rc2, so this is a last call for any
> bugs you'd like to see fixed. I may have missed something
>
> --
> Regards,
>
> Austin Seipp, Haskell Consultant
> Well-Typed LLP, http://www.well-typed.com/
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: performance regressions

[Ben Gamari]

Joachim Breitner  writes:

> Hi,
>
> Am Montag, den 15.12.2014, 10:58 -0500 schrieb Ben Gamari:
>> >> - Travis has not picked up on these errors.
>> >
>> > unfortunately, travis is slighly less useful since a few weeks due to
>> > T5681 failing (possibly due to the use of LLVM-3.4), but I’m still
>> > waiting for an reply on that issue.
>> >
>> You aren't looking for a response from me on this, are you? I just
>> checked and I don't seem to have any outstanding messages from you but
>> it's entirely possible I overlooked something.
>
> this is independent of our arm issues, and I think a tad older; I did
> not direct it to anyone specific.
>
> But I guess you are likely a person that can tell what’s wrong here:
>
> Am Sonntag, den 30.11.2014, 20:01 +0100 schrieb Joachim Breitner:
>> Compile failed (status 256) errors were:
>> /tmp/ghc16123_0/ghc16123_5.s: Assembler messages:
>> 
>> /tmp/ghc16123_0/ghc16123_5.s:26:0:
>>  Error: can't resolve `.rodata' {.rodata section} - 
>> `Main_zdwwork_info$def' {.text section}
>> 
>> /tmp/ghc16123_0/ghc16123_5.s:46:0:
>>  Error: can't resolve `.rodata' {.rodata section} - `Main_work_info$def' 
>> {.text section}
>> 
>> /tmp/ghc16123_0/ghc16123_5.s:66:0:
>>  Error: can't resolve `.rodata' {.rodata section} - 
>> `Main_main1_info$def' {.text section}
>> 
>> /tmp/ghc16123_0/ghc16123_5.s:86:0:
>>  Error: can't resolve `.rodata' {.rodata section} - `Main_main_info$def' 
>> {.text section}
>> 
>> /tmp/ghc16123_0/ghc16123_5.s:106:0:
>>  Error: can't resolve `.rodata' {.rodata section} - 
>> `Main_main2_info$def' {.text section}
>> 
>> /tmp/ghc16123_0/ghc16123_5.s:126:0:
>>  Error: can't resolve `.rodata' {.rodata section} - 
>> `ZCMain_main_info$def' {.text section}
>> 
>> *** unexpected failure for T5681(optllvm)
>> 
>> https://s3.amazonaws.com/archive.travis-ci.org/jobs/42557559/log.txt
>> 
>> Any ideas?
>
> Is it possible that this is due the llvm version used? Do we support 3.4
> in GHC HEAD?
>
>Using LLVM tools
>   llc   : /usr/local/clang-3.4/bin/llc
>   opt   : /usr/local/clang-3.4/bin/opt
>
> (http://smart-cactus.org/~ben/posts/2014-11-28-state-of-llvm-backend.html
> does not talk about GHC HEAD explicitly. Should I look at the 7.10
> row? Does that mean that 3.4 is not supported? Shouldn’t the build
> system, or at least the compiler, fail harder and more helpfully in
> this case?)
>
LLVM 3.4 appears to have an unfortunate behavior whereby it will lose track
of which section symbols with Internal linkage belong.  I haven't had a
chance to delve into this too deeply, however given that both 3.3 and
3.5 behave as expected I'm pretty sure this a bug. There are a few
options here,

  a. Mark the `$def` symbols as ExternallyVisible, working around the
  issue at the expense of exposing internal symbols to the outside
  world.

  b. Mark LLVM 3.4 as unsupported

At the moment I'm leaning towards (b) since I haven't had a chance to
think through the implications of (a); if nothing else I suspect this
wouldn't help the DLL symbol table size issues on Windows. Giving up on
LLVM 3.4 might be unfortunate for a good number of users, however.

Ultimately this underlines the need to package LLVM with GHC.

Cheers,

- Ben




pgpkUijPcDKUI.pgp
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

RE: more parser conflicts?

[Simon Peyton Jones]

It would be great to have a patch that documents all this

Simon

|  -Original Message-
|  From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of
|  Sergei Trofimovich
|  Sent: 13 December 2014 15:20
|  To: GHC Devs
|  Cc: Simon Marlow; Dr. ERDI Gergo; Mike Izbicki
|  Subject: Re: more parser conflicts?
|  
|  On Wed, 03 Dec 2014 11:59:42 +
|  Simon Marlow  wrote:
|  
|  > >> In unrelated work, I saw this scroll across when happy'ing the
|  parser:
|  > >>
|  > >>> shift/reduce conflicts:  60
|  > >>> reduce/reduce conflicts: 16
|  > >>
|  > >> These numbers seem quite a bit higher than what I last remember
|  > >> (which is something like 48 and 1, not 60 and 16). Does anyone
|  know why?
|  
|  4 of reduce/reduce conflicts are result of exact rule copy:
|  https://phabricator.haskell.org/D569
|  
|  > reduce/reduce conflicts are bad, especially so since they're
|  > undocumented.  We don't know whether this introduced parser bugs or
|  not.
|  >   Mike - could you look at this please?  It was your commit that
|  > introduced the new conflicts.
|  
|  Agreed.
|  
|  11 more reduce/reduce (of left 12) came from single scary rule added
|  in
|  > commit bc2289e13d9586be087bd8136943dc35a0130c88
|  >ghc generates more user-friendly error messages
|  
|  exp10 :: { LHsExpr RdrName }
|  ...
|   | 'let' binds {% parseErrorSDoc (combineLocs $1 $2) $ text
|   "parse error in let binding: missing
|  required 'in'"
|  }
|  
|  The other rules add shift/reduce conflicts as follows:
|  
|  -- parsing error messages go below here
|  {- s/r:1 r/r:0 -}
|  | '\\' apat apats opt_asig '->' {% parseErrorSDoc (combineLocs $1
|  $5) $ text
| "parse error in
|  lambda: no expression after '->'"
|  {- s/r:1 r/r:0 -}
|  | '\\'   {% parseErrorSDoc
|  (getLoc $1) $ text
| "parse error:
|  naked lambda expression '\'"
|  }
|  {- s/r:1 r/r:0 -}
|  | 'let' binds 'in'   {% parseErrorSDoc
|  (combineLocs $1 $2) $ text
| "parse error in
|  let binding: missing expression after 'in'"
|  }
|  {- s/r:0 r/r:11 -}
|   | 'let' binds{% parseErrorSDoc
|  (combineLocs $1 $2) $ text
|  "parse error
|  in let binding: missing required 'in'"
|   }
|  {- s/r:0 r/r:0 -}
|  | 'let'  {% parseErrorSDoc
|  (getLoc $1) $ text
| "parse error:
|  naked let binding"
| }
|  {- s/r:1 r/r:0 -}
|  | 'if' exp optSemi 'then' exp optSemi 'else' {% hintIf
|  (combineLocs $1 $5) "else clause empty" }
|  {- s/r:2 r/r:0 -}
|  | 'if' exp optSemi 'then' exp optSemi{% hintIf
|  (combineLocs $1 $5) "missing required else clause" }
|  {- s/r:1 r/r:0 -}
|  | 'if' exp optSemi 'then'{% hintIf
|  (combineLocs $1 $2) "then clause empty" }
|  {- s/r:2 r/r:0 -}
|  | 'if' exp optSemi   {% hintIf
|  (combineLocs $1 $2) "missing required then and else clauses"
|  {- s/r:2 r/r:0 -}
|  | 'if'   {% hintIf (getLoc
|  $1) "naked if statement" }
|  {- s/r:0 r/r:0 -}
|  | 'case' exp 'of'{% parseErrorSDoc
|  (combineLocs $1 $2) $ text
|  "parse error
|  in case statement: missing list after '->'"
|}
|  {- s/r:1 r/r:0 -}
|  | 'case' exp {% parseErrorSDoc
|  (combineLocs $1 $2) $ text
| "parse error in
|  case statement: missing required 'of'"
|   }
|  {- s/r:1 r/r:0 -}
|  | 'case' {% parseErrorSDoc
|  (getLoc $1) $ text
|  "parse error:
|  naked case statement"
|}
|  
|  Shift/reduces look harmless (like MultiWayIf ambiguity) as they seem
|  to resolve as shift correctly.
|  
|  --
|  
|Sergei
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: [commit: ghc] master: Improve documentation of syntax for promoted lists (a972bdd)

[Gabor Greif]

Hmm, shouldn't that be -XDataKinds (instead of -XTypeOperators)?


also:
  umambiguous ---> unambiguous
  becuase ---> because

Cheers,

Gabor

On 12/15/14, g...@git.haskell.org  wrote:
> Repository : ssh://g...@git.haskell.org/ghc
>
> On branch  : master
> Link   :
> http://ghc.haskell.org/trac/ghc/changeset/a972bddfc8115d80d774383a55202a293dc68595/ghc
>
>>---
>
> commit a972bddfc8115d80d774383a55202a293dc68595
> Author: Simon Peyton Jones 
> Date:   Mon Dec 15 17:08:29 2014 +
>
> Improve documentation of syntax for promoted lists
>
> THe documentation in 7.9.4 of promoted list and tuple types was
> misleading, which led to Trac #9882.  This patch makes explicit
> that only type-level with two or more elements can have the
> quote omitted.
>
>
>>---
>
> a972bddfc8115d80d774383a55202a293dc68595
>  compiler/parser/Parser.y  |  8 ++--
>  docs/users_guide/glasgow_exts.xml | 19 ---
>  2 files changed, 22 insertions(+), 5 deletions(-)
>
> diff --git a/compiler/parser/Parser.y b/compiler/parser/Parser.y
> index bffe6e1..235d34a 100644
> --- a/compiler/parser/Parser.y
> +++ b/compiler/parser/Parser.y
> @@ -1483,6 +1483,10 @@ atype :: { LHsType RdrName }
> [mo $2,mc $4] }
>  | SIMPLEQUOTE var   { sLL $1 $> $ HsTyVar $
> unLoc $2 }
>
> +-- Two or more [ty, ty, ty] must be a promoted list type, just as
> +-- if you had written '[ty, ty, ty]
> +-- (One means a list type, zero means the list type constructor,
> +-- so you have to quote those.)
>  | '[' ctype ',' comma_types1 ']'  {% ams (sLL $1 $> $
> HsExplicitListTy
>   placeHolderKind ($2 :
> $4))
>   [mo $1, mj AnnComma $3,mc
> $5] }
> @@ -1503,11 +1507,11 @@ inst_types1 :: { [LHsType RdrName] }
>  | inst_type ',' inst_types1{% addAnnotation (gl $1) AnnComma
> (gl $2)
>>> return ($1 : $3) }
>
> -comma_types0  :: { [LHsType RdrName] }
> +comma_types0  :: { [LHsType RdrName] }  -- Zero or more:  ty,ty,ty
>  : comma_types1  { $1 }
>  | {- empty -}   { [] }
>
> -comma_types1:: { [LHsType RdrName] }
> +comma_types1:: { [LHsType RdrName] }  -- One or more:  ty,ty,ty
>  : ctype{ [$1] }
>  | ctype  ',' comma_types1  {% addAnnotation (gl $1) AnnComma
> (gl $2)
>>> return ($1 : $3) }
> diff --git a/docs/users_guide/glasgow_exts.xml
> b/docs/users_guide/glasgow_exts.xml
> index e12703f..7edca07 100644
> --- a/docs/users_guide/glasgow_exts.xml
> +++ b/docs/users_guide/glasgow_exts.xml
> @@ -6882,9 +6882,9 @@ is a single quote.
>  
>
>  
> -Promoted lists and tuples types
> +Promoted list and tuple types
>  
> -Haskell's list and tuple types are natively promoted to kinds, and enjoy
> the
> +With -XTypeOperators, Haskell's list and tuple types are
> natively promoted to kinds, and enjoy the
>  same convenient syntax at the type level, albeit prefixed with a quote:
>  
>  data HList :: [*] -> * where
> @@ -6893,8 +6893,21 @@ data HList :: [*] -> * where
>
>  data Tuple :: (*,*) -> * where
>Tuple :: a -> b -> Tuple '(a,b)
> +
> +foo0 :: HList '[]
> +foo0 = HNil
> +
> +foo1 :: HList '[Int]
> +foo1 = HCons (3::Int) HNil
> +
> +foo2 :: HList [Int, Bool]
> +foo2 = ...
>  
> -Note that this requires -XTypeOperators.
> +For type-level lists of two or more elements,
> +such as the signature of foo2 above, the quote may be
> omitted because the meaning is
> +umambiguous. But for lists of one or zero elements (as in
> foo0
> +and foo1), the quote is required, becuase the types
> []
> +and [Int] have existing meanings in Haskell.
>  
>  
>
>
> ___
> ghc-commits mailing list
> ghc-comm...@haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-commits
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

RE: [commit: ghc] master: Improve documentation of syntax for promoted lists (a972bdd)

[Simon Peyton Jones]

Ah yes, thanks; TypeOperators is needed for the (':), but DataKinds for 
everything else.

I'll modify.

Simon


|  -Original Message-
|  From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of
|  Gabor Greif
|  Sent: 15 December 2014 17:27
|  To: ghc-devs@haskell.org
|  Subject: Re: [commit: ghc] master: Improve documentation of syntax for
|  promoted lists (a972bdd)
|  
|  Hmm, shouldn't that be -XDataKinds (instead of -XTypeOperators)?
|  
|  
|  also:
|umambiguous ---> unambiguous
|becuase ---> because
|  
|  Cheers,
|  
|  Gabor
|  
|  On 12/15/14, g...@git.haskell.org  wrote:
|  > Repository : ssh://g...@git.haskell.org/ghc
|  >
|  > On branch  : master
|  > Link   :
|  >
|  http://ghc.haskell.org/trac/ghc/changeset/a972bddfc8115d80d774383a5520
|  > 2a293dc68595/ghc
|  >
|  >>---
|  >
|  > commit a972bddfc8115d80d774383a55202a293dc68595
|  > Author: Simon Peyton Jones 
|  > Date:   Mon Dec 15 17:08:29 2014 +
|  >
|  > Improve documentation of syntax for promoted lists
|  >
|  > THe documentation in 7.9.4 of promoted list and tuple types was
|  > misleading, which led to Trac #9882.  This patch makes explicit
|  > that only type-level with two or more elements can have the
|  > quote omitted.
|  >
|  >
|  >>---
|  >
|  > a972bddfc8115d80d774383a55202a293dc68595
|  >  compiler/parser/Parser.y  |  8 ++--
|  >  docs/users_guide/glasgow_exts.xml | 19 ---
|  >  2 files changed, 22 insertions(+), 5 deletions(-)
|  >
|  > diff --git a/compiler/parser/Parser.y b/compiler/parser/Parser.y
|  index
|  > bffe6e1..235d34a 100644
|  > --- a/compiler/parser/Parser.y
|  > +++ b/compiler/parser/Parser.y
|  > @@ -1483,6 +1483,10 @@ atype :: { LHsType RdrName }
|  > [mo $2,mc
|  $4] }
|  >  | SIMPLEQUOTE var   { sLL $1 $> $
|  HsTyVar $
|  > unLoc $2 }
|  >
|  > +-- Two or more [ty, ty, ty] must be a promoted list type,
|  just as
|  > +-- if you had written '[ty, ty, ty]
|  > +-- (One means a list type, zero means the list type
|  constructor,
|  > +-- so you have to quote those.)
|  >  | '[' ctype ',' comma_types1 ']'  {% ams (sLL $1 $> $
|  > HsExplicitListTy
|  >
|  placeHolderKind ($2 :
|  > $4))
|  >   [mo $1, mj
|  AnnComma
|  > $3,mc $5] } @@ -1503,11 +1507,11 @@ inst_types1 :: { [LHsType
|  RdrName]
|  > }
|  >  | inst_type ',' inst_types1{% addAnnotation (gl $1)
|  AnnComma
|  > (gl $2)
|  >>> return ($1 : $3) }
|  >
|  > -comma_types0  :: { [LHsType RdrName] }
|  > +comma_types0  :: { [LHsType RdrName] }  -- Zero or more:  ty,ty,ty
|  >  : comma_types1  { $1 }
|  >  | {- empty -}   { [] }
|  >
|  > -comma_types1:: { [LHsType RdrName] }
|  > +comma_types1:: { [LHsType RdrName] }  -- One or more:  ty,ty,ty
|  >  : ctype{ [$1] }
|  >  | ctype  ',' comma_types1  {% addAnnotation (gl $1)
|  AnnComma
|  > (gl $2)
|  >>> return ($1 : $3) }
|  diff
|  > --git a/docs/users_guide/glasgow_exts.xml
|  > b/docs/users_guide/glasgow_exts.xml
|  > index e12703f..7edca07 100644
|  > --- a/docs/users_guide/glasgow_exts.xml
|  > +++ b/docs/users_guide/glasgow_exts.xml
|  > @@ -6882,9 +6882,9 @@ is a single quote.  
|  >
|  >   -Promoted lists and
|  > tuples types
|  > +Promoted list and tuple types
|  >  
|  > -Haskell's list and tuple types are natively promoted to kinds, and
|  > enjoy the
|  > +With -XTypeOperators, Haskell's list and tuple
|  types
|  > +are
|  > natively promoted to kinds, and enjoy the  same convenient syntax at
|  > the type level, albeit prefixed with a quote:
|  >  
|  >  data HList :: [*] -> * where
|  > @@ -6893,8 +6893,21 @@ data HList :: [*] -> * where
|  >
|  >  data Tuple :: (*,*) -> * where
|  >Tuple :: a -> b -> Tuple '(a,b)
|  > +
|  > +foo0 :: HList '[]
|  > +foo0 = HNil
|  > +
|  > +foo1 :: HList '[Int]
|  > +foo1 = HCons (3::Int) HNil
|  > +
|  > +foo2 :: HList [Int, Bool]
|  > +foo2 = ...
|  >  
|  > -Note that this requires -XTypeOperators.
|  > +For type-level lists of two or more elements,
|  > +such as the signature of foo2 above, the quote
|  may
|  > +be
|  > omitted because the meaning is
|  > +umambiguous. But for lists of one or zero elements (as in
|  > foo0
|  > +and foo1), the quote is required, becuase the
|  > +types
|  > []
|  > +and [Int] have existing meanings in Haskell.
|  >  
|  >  
|  >
|  >
|  > ___
|  > ghc-commits mailing list
|  > ghc-comm...@haskell.org
|  > http://www.haskell.org/mailman/listinfo/ghc-commits
|  >
|  

RE: [Diffusion] [Build Failed] rGHC3f87866ad536: Fix dll-split problem with patch 'Make Core Lint check for locally-bound…

[Simon Peyton Jones]

This failure is in STM!!  I don't think that can be my fault :-(

|  -Original Message-
|  From: nore...@phabricator.haskell.org
|  [mailto:nore...@phabricator.haskell.org]
|  Sent: 15 December 2014 17:28
|  To: Simon Peyton Jones
|  Subject: [Diffusion] [Build Failed] rGHC3f87866ad536: Fix dll-split
|  problem with patch 'Make Core Lint check for locally-bound…
|  
|  Harbormaster failed to build B2627: rGHC3f87866ad536: Fix dll-split
|  problem with patch 'Make Core Lint check for locally-bound…!
|  
|  USERS
|simonpj (Author)
|GHC - Core/System FC (Auditor)
|GHC - Driver (Auditor)
|GHC - Type checker/inferencer (Auditor)
|  
|  COMMIT
|https://phabricator.haskell.org/rGHC3f87866ad536
|  
|  EMAIL PREFERENCES
|https://phabricator.haskell.org/settings/panel/emailpreferences/
|  
|  To: simonpj, GHC - Core/System FC, GHC - Driver, GHC - Type
|  checker/inferencer
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: [Diffusion] [Build Failed] rGHC3f87866ad536: Fix dll-split problem with patch 'Make Core Lint check for locally-bound…

[Austin Seipp]

Yeah, this was what I was referring to when we were talking when I
said "I'm going to kick myself if I broke the build" this morning :)

I broke the build. Therefore, I will fix it and then kick myself.

Fix incoming.

On Mon, Dec 15, 2014 at 11:42 AM, Simon Peyton Jones
 wrote:
> This failure is in STM!!  I don't think that can be my fault :-(
>
> |  -Original Message-
> |  From: nore...@phabricator.haskell.org
> |  [mailto:nore...@phabricator.haskell.org]
> |  Sent: 15 December 2014 17:28
> |  To: Simon Peyton Jones
> |  Subject: [Diffusion] [Build Failed] rGHC3f87866ad536: Fix dll-split
> |  problem with patch 'Make Core Lint check for locally-bound…
> |
> |  Harbormaster failed to build B2627: rGHC3f87866ad536: Fix dll-split
> |  problem with patch 'Make Core Lint check for locally-bound…!
> |
> |  USERS
> |simonpj (Author)
> |GHC - Core/System FC (Auditor)
> |GHC - Driver (Auditor)
> |GHC - Type checker/inferencer (Auditor)
> |
> |  COMMIT
> |https://phabricator.haskell.org/rGHC3f87866ad536
> |
> |  EMAIL PREFERENCES
> |https://phabricator.haskell.org/settings/panel/emailpreferences/
> |
> |  To: simonpj, GHC - Core/System FC, GHC - Driver, GHC - Type
> |  checker/inferencer
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs



-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: [Diffusion] [Build Failed] rGHC3f87866ad536: Fix dll-split problem with patch 'Make Core Lint check for locally-bound…

[Austin Seipp]

Should be fixed, sorry for the annoyance!

On Mon, Dec 15, 2014 at 11:43 AM, Austin Seipp  wrote:
> Yeah, this was what I was referring to when we were talking when I
> said "I'm going to kick myself if I broke the build" this morning :)
>
> I broke the build. Therefore, I will fix it and then kick myself.
>
> Fix incoming.
>
> On Mon, Dec 15, 2014 at 11:42 AM, Simon Peyton Jones
>  wrote:
>> This failure is in STM!!  I don't think that can be my fault :-(
>>
>> |  -Original Message-
>> |  From: nore...@phabricator.haskell.org
>> |  [mailto:nore...@phabricator.haskell.org]
>> |  Sent: 15 December 2014 17:28
>> |  To: Simon Peyton Jones
>> |  Subject: [Diffusion] [Build Failed] rGHC3f87866ad536: Fix dll-split
>> |  problem with patch 'Make Core Lint check for locally-bound…
>> |
>> |  Harbormaster failed to build B2627: rGHC3f87866ad536: Fix dll-split
>> |  problem with patch 'Make Core Lint check for locally-bound…!
>> |
>> |  USERS
>> |simonpj (Author)
>> |GHC - Core/System FC (Auditor)
>> |GHC - Driver (Auditor)
>> |GHC - Type checker/inferencer (Auditor)
>> |
>> |  COMMIT
>> |https://phabricator.haskell.org/rGHC3f87866ad536
>> |
>> |  EMAIL PREFERENCES
>> |https://phabricator.haskell.org/settings/panel/emailpreferences/
>> |
>> |  To: simonpj, GHC - Core/System FC, GHC - Driver, GHC - Type
>> |  checker/inferencer
>> ___
>> ghc-devs mailing list
>> ghc-devs@haskell.org
>> http://www.haskell.org/mailman/listinfo/ghc-devs
>
>
>
> --
> Regards,
>
> Austin Seipp, Haskell Consultant
> Well-Typed LLP, http://www.well-typed.com/



-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Last call for 7.8.4

[Lennart Kolmodin]

2014-12-15 18:28 GMT+03:00 Austin Seipp :
>
> Hello *,
>
> I've just pushed a final round of patches to the 7.8 branch, including
> the notorious Cabal fix for the -fPIC bug that was discussed earlier
> in the week, and a handful of other bugfixes for ARM among other
> things (/cc Joachim :)
>

Please also consider
https://phabricator.haskell.org/D554
Fixes a small but annoying bug with bash completion for 7.8.
Should be very low risk as it only affects the --show-options flag.


> I am planning on making the final 7.8.4 release this week; barring any
> pending minor issues (e.g. build wibbles) in the tree (which I do not
> think should be needed), the only thing I will commit is A) release
> notes and B) the version number changes.
>
> There will not likely be a 7.8.4-rc2, so this is a last call for any
> bugs you'd like to see fixed. I may have missed something
>
> --
> Regards,
>
> Austin Seipp, Haskell Consultant
> Well-Typed LLP, http://www.well-typed.com/
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

API Annotatons in a FunBind

[Alan & Kim Zimmerman]

After individual FunBinds have been parsed, they are combined in
getMonoBind.

In the process, all the original FunBind fun_id's bar one are discarded,
including its location.

This causes a problem for source-to-source conversions of functions such as
the following

(&&&  ) [] [] =  []
xs&&&   [] =  xs
(  &&&  ) [] ys =  ys

Where there are compound RdrNames, and each has different spacing.

I am proposing to add a (Maybe (Located id)) to the Match datatype to deal
with this.


data Match id body
  = Match
Maybe (Located id) -- fun_id in subsequent function equations
[LPat id]   -- The patterns
(Maybe (LHsType id))-- A type signature for the result of the
match
-- Nothing after typechecking
(GRHSs id body)

Is this a problem?

Alan
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Last call for 7.8.4

[Johan Tibell]

Cabal 1.18.1.5 is out.

On Mon, Dec 15, 2014 at 5:16 PM, Johan Tibell 
wrote:
>
> I will make the actual cabal 1.18 release today as the RCs looked good.
>
> On Mon, Dec 15, 2014 at 4:28 PM, Austin Seipp 
> wrote:
>>
>> Hello *,
>>
>> I've just pushed a final round of patches to the 7.8 branch, including
>> the notorious Cabal fix for the -fPIC bug that was discussed earlier
>> in the week, and a handful of other bugfixes for ARM among other
>> things (/cc Joachim :)
>>
>> I am planning on making the final 7.8.4 release this week; barring any
>> pending minor issues (e.g. build wibbles) in the tree (which I do not
>> think should be needed), the only thing I will commit is A) release
>> notes and B) the version number changes.
>>
>> There will not likely be a 7.8.4-rc2, so this is a last call for any
>> bugs you'd like to see fixed. I may have missed something
>>
>> --
>> Regards,
>>
>> Austin Seipp, Haskell Consultant
>> Well-Typed LLP, http://www.well-typed.com/
>> ___
>> ghc-devs mailing list
>> ghc-devs@haskell.org
>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: performance regressions

[Richard Eisenberg]

I've made progress, but still need some help.

It turns out that a monadic combinator (that I wrote) is mostly responsible:

> zipWithAndUnzipM :: Monad m
>  => (a -> b -> m (c, d)) -> [a] -> [b] -> m ([c], [d])
> zipWithAndUnzipM f (x:xs) (y:ys)
>   = do { (c, d) <- f x y
>; (cs, ds) <- zipWithAndUnzipM f xs ys
>; return (c:cs, d:ds) }
> zipWithAndUnzipM _ _ _ = return ([], [])
> 

Using this combinator instead of writing the algorithm directly cost me 30% 
allocation overhead!

Can anyone tell me: why? Have I made some horrible mistake in the 
implementation? 
And, relatedly: how can I fix this? I want to learn from this experience how to 
avoid this problem next time...

Unfortunately, my commit causes 50% overhead, not 30%, so I'm not out of the 
woods yet. Hopefully, another 20% of good news tomorrow.

Thanks!
Richard

On Dec 15, 2014, at 11:33 AM, Ben Gamari  wrote:

> Joachim Breitner  writes:
> 
>> Hi,
>> 
>> Am Montag, den 15.12.2014, 10:58 -0500 schrieb Ben Gamari:
> - Travis has not picked up on these errors.
 
 unfortunately, travis is slighly less useful since a few weeks due to
 T5681 failing (possibly due to the use of LLVM-3.4), but I’m still
 waiting for an reply on that issue.
 
>>> You aren't looking for a response from me on this, are you? I just
>>> checked and I don't seem to have any outstanding messages from you but
>>> it's entirely possible I overlooked something.
>> 
>> this is independent of our arm issues, and I think a tad older; I did
>> not direct it to anyone specific.
>> 
>> But I guess you are likely a person that can tell what’s wrong here:
>> 
>> Am Sonntag, den 30.11.2014, 20:01 +0100 schrieb Joachim Breitner:
>>> Compile failed (status 256) errors were:
>>> /tmp/ghc16123_0/ghc16123_5.s: Assembler messages:
>>> 
>>> /tmp/ghc16123_0/ghc16123_5.s:26:0:
>>> Error: can't resolve `.rodata' {.rodata section} - 
>>> `Main_zdwwork_info$def' {.text section}
>>> 
>>> /tmp/ghc16123_0/ghc16123_5.s:46:0:
>>> Error: can't resolve `.rodata' {.rodata section} - `Main_work_info$def' 
>>> {.text section}
>>> 
>>> /tmp/ghc16123_0/ghc16123_5.s:66:0:
>>> Error: can't resolve `.rodata' {.rodata section} - 
>>> `Main_main1_info$def' {.text section}
>>> 
>>> /tmp/ghc16123_0/ghc16123_5.s:86:0:
>>> Error: can't resolve `.rodata' {.rodata section} - `Main_main_info$def' 
>>> {.text section}
>>> 
>>> /tmp/ghc16123_0/ghc16123_5.s:106:0:
>>> Error: can't resolve `.rodata' {.rodata section} - 
>>> `Main_main2_info$def' {.text section}
>>> 
>>> /tmp/ghc16123_0/ghc16123_5.s:126:0:
>>> Error: can't resolve `.rodata' {.rodata section} - 
>>> `ZCMain_main_info$def' {.text section}
>>> 
>>> *** unexpected failure for T5681(optllvm)
>>> 
>>> https://s3.amazonaws.com/archive.travis-ci.org/jobs/42557559/log.txt
>>> 
>>> Any ideas?
>> 
>> Is it possible that this is due the llvm version used? Do we support 3.4
>> in GHC HEAD?
>> 
>>   Using LLVM tools
>>  llc   : /usr/local/clang-3.4/bin/llc
>>  opt   : /usr/local/clang-3.4/bin/opt
>> 
>> (http://smart-cactus.org/~ben/posts/2014-11-28-state-of-llvm-backend.html
>> does not talk about GHC HEAD explicitly. Should I look at the 7.10
>> row? Does that mean that 3.4 is not supported? Shouldn’t the build
>> system, or at least the compiler, fail harder and more helpfully in
>> this case?)
>> 
> LLVM 3.4 appears to have an unfortunate behavior whereby it will lose track
> of which section symbols with Internal linkage belong.  I haven't had a
> chance to delve into this too deeply, however given that both 3.3 and
> 3.5 behave as expected I'm pretty sure this a bug. There are a few
> options here,
> 
>  a. Mark the `$def` symbols as ExternallyVisible, working around the
>  issue at the expense of exposing internal symbols to the outside
>  world.
> 
>  b. Mark LLVM 3.4 as unsupported
> 
> At the moment I'm leaning towards (b) since I haven't had a chance to
> think through the implications of (a); if nothing else I suspect this
> wouldn't help the DLL symbol table size issues on Windows. Giving up on
> LLVM 3.4 might be unfortunate for a good number of users, however.
> 
> Ultimately this underlines the need to package LLVM with GHC.
> 
> Cheers,
> 
> - Ben
> 
> 
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs

___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs