Re: Is Safe Haskell intended to allow segfaults?

[David Terei]

Thanks for bringing this up Ryan, it's an interesting direction of thought.

It's been a while since we originally designed SafeHaskell, so I can't
remember our thinking very well with this area. I believe it came down
to the following:

* Our primary concern was to be able to 'trust the types', which is
perhaps a little weaker than 'type safety'. So IO can do ugly things,
but at least we know that, and know what something without IO, or
using a restricted IO monad can do.
* Our intuition was that offering stronger guarantees about IO would
be very difficult -- I don't remember how far we explored this
intuition.
* We were also motivated very strongly by the security use case, that
may have sadly blinded us a little to something more ambitious as you
propose.

If you have the energy, it'd be great to put some of this thinking
into a wiki page (https://ghc.haskell.org/trac/ghc/wiki/SafeHaskell)
and flesh out a first approximation of what IO API's cause issues. Is
it just Ptr not carrying bounds around with it? Maybe, but then we
need to secure how Ptr's can be created, which excludes FFI returning
Ptr's.

I imagine in Java, that I can construct an invalid pointer in foreign
code, and then cause segfaults without the Java code having any
issues. Just guessing at this, so very interested to know how it's
prevented if I can't.

Securing the memory model may be very challenging. E.g., as Russ Cox
points out, in Go one can use a data race to break type safety. Does
GHC-Haskell have any similar issues? What performance impact would
result from fixing these edge cases?

http://research.swtch.com/gorace

I think your (1) proposal is reasonable and desirable, but we'd really
want to understand the difficulty further to guide us between 1--3.

Cheers,
David

On 8 August 2016 at 13:00, Ryan Newton  wrote:
> Hi Ed,
>
> Thanks, I went back to the paper and read those sections.
>
> It sounds like this design heavily reflects the untrusted-code use case.  I
> believe ceding the entire IO monad is too pessimistic, and it's also against
> the spirit of the type safety guarantee mentioned in the paper:
>
> "Type safety. In Milner’s famous phrase, well-typed programs do not go
> wrong. "
>
> There's not really very much discussion of this "punting on IO" decision in
> the paper.  The paper mentions not deleting users files as an example of a
> higher level security policy -- and a reason not  to try to lock down IO --
> but that's not really the issue here.
>
> Sure, there are many use cases that require an RIO newtype, but the memory
> model and memory protection are really internal to the language.  My
> interest is in a type safe language with a memory model in the IO monad.  I
> think it's quite reasonable to expect Safe Haskell to be as safe as Java!
> There are hundreds of thousands or millions of lines of code written in the
> IO monad [1], and a lot of that code could probably be memory safe by
> construction.
>
> One question I have for people is which of the following they would favor:
>
> Redefine -XSafe to guarantee something about IO and its memory safety (and
> even its memory model)
> Add a fourth safety level, "SafeExceptIO", that corresponds to the current
> guarantees, while extending "Safe" to say something about IO.
> Leave safe Haskell as it is.
>
> (2) sounds a bit clunky to me, and I favor (1) most of all.
>
> Best,
>   -Ryan
>
> [1] 17M lines on hackage total, hard to count how much is in an IO monad or
> related monad.
>
>
> On Mon, Aug 8, 2016 at 2:05 PM, Edward Z. Yang  wrote:
>>
>> Hello Ryan,
>>
>> The guarantee that Safe Haskell gives with regards to IO is a little
>> subtle and is mentioned in Section 3.1 of the paper, and detailed
>> in Section 5.1. Essentially, to use Safe Haskell, you are responsible
>> for defining the type at which untrusted code is to be called.
>> Using an untrusted value at type IO a in main imposes no safety
>> restrictions by design--it's up to the user of Safe Haskell to
>> decide what kind of security properties it needs out of user code.
>>
>> Edward
>>
>> Excerpts from Ryan Newton's message of 2016-08-08 13:27:16 -0400:
>> > We're trying to spend some cycles pushing on Safe Haskell within the
>> > stackage packages.  (It's looking like a slog.)
>> >
>> > But we're running up against some basic questions regarding the core
>> > packages and Safe Haskell guarantees.  The manual currently says:
>> >
>> > 
>> >
>> >
>> > *Functions in the IO monad are still allowed and behave as usual. *
>> > As usual?  So it is ok to segfault GHC?  Elsewhere it says "in the safe
>> > language you can trust the types", and I'd always assumed that meant
>> > Safe
>> > Haskell is a type safe language, even in the IO fragment.
>> >
>> > Was there an explicit decision to allow segfaults and memory corruption?
>> > This can happen not just with FFI calls but 

Re: Generalized Newtype Deriving not allowed in Safe Haskell

[David Terei]

Done, sent a new email thread out. Can find on wiki page here:

https://ghc.haskell.org/trac/ghc/wiki/SafeRoles

On 13 April 2015 at 18:18, David Terei dave.te...@gmail.com wrote:
 Good advice. I'll set that up soon.

 On 13 April 2015 at 00:10, Simon Peyton Jones simo...@microsoft.com wrote:
 David

 If you would like to lead a debate, and drive it to a conclusion, that would 
 be most helpful.

 Usually it's constructive to write a wiki page that sets out the design 
 choices, with examples to illustrate their consequences, to set the terms of 
 the debate.  Otherwise you risk misunderstandings, with red herrings being 
 discussed repeatedly.

 Thanks

 Simon

 |  -Original Message-
 |  From: davidte...@gmail.com [mailto:davidte...@gmail.com] On Behalf Of
 |  David Terei
 |  Sent: 12 April 2015 09:52
 |  To: Simon Peyton Jones
 |  Cc: Omari Norman; ghc-devs@haskell.org; haskell Cafe
 |  Subject: Re: Generalized Newtype Deriving not allowed in Safe Haskell
 |
 |  On 10 April 2015 at 01:48, Simon Peyton Jones simo...@microsoft.com
 |  wrote:
 |   |  prefer, such as only exporting the Coerce instance if all the
 |   | constructors are exported, it seems that the ship sailed on these
 |  
 |   Coercible is relatively recent; I don't think we should regard it as
 |  cast in stone.
 |  
 |   But yes, the Coerbible instance of a newtype is only available when
 |  the data constructor for the newtype is lexically in scope.
 |
 |  Yes, so as you point out in the paper, this is done to preserve
 |  abstractions, but the same rule isn't applied to data types since some
 |  types like IORef don't even have constructors that can be in scope.
 |
 |  Ideally I'd like to find a way forward that works for everyone and
 |  isn't just a Safe Haskell mode setting.
 |
 |  I think the first question is, are there situations where you'd want to
 |  use `coerce` internally to a module but disallow it externally? The
 |  role mechanism is a little awkward as it doesn't allow this (although
 |  it does for newtype's). If yes, then I think we should start there.
 |
 |  If it seems we don't need external vs internal control, then we could
 |  simply change the default to be that GHC sets referential type
 |  parameters to nominal and allows them to be weakened to referential
 |  through role annotations. We could use hackage to test how much
 |  breakage this would cause.
 |
 |  The third option is something Safe Haskell specific, so probably
 |  applying the newtype constructor rule to data types.
 |
 |  
 |   Simon
 |  
 |   |  -Original Message-
 |   |  From: davidte...@gmail.com [mailto:davidte...@gmail.com] On Behalf
 |   | Of  David Terei
 |   |  Sent: 10 April 2015 09:38
 |   |  To: Simon Peyton Jones
 |   |  Cc: Omari Norman; haskell Cafe; ghc-devs@haskell.org
 |   |  Subject: Re: Generalized Newtype Deriving not allowed in Safe
 |   | Haskell
 |   |
 |   |  I'll prepare a patch for the userguide soon.
 |   |
 |   |  As for something better, yes I think we can and should. It's on my
 |   | todo  list :) Basically, the new-GND design has all the mechanisms
 |   | to be  safe, but sadly the defaults are rather worrying. Without
 |   | explicit  annotations from the user, module abstractions are
 |  broken.
 |   | This is why  we left GND out of Safe Haskell for the moment as it
 |  is
 |   | a subtle and  easy mistake to make.
 |   |
 |   |  If the module contained explicit role annotations then it could be
 |   | allowed. The discussion in
 |   |  https://ghc.haskell.org/trac/ghc/ticket/8827 has other solutions
 |   | that I  prefer, such as only exporting the Coerce instance if all
 |   | the  constructors are exported, it seems that the ship sailed on
 |   | these  bigger changes sadly.
 |   |
 |   |  Cheers,
 |   |  David
 |   |
 |   |  On 9 April 2015 at 00:56, Simon Peyton Jones
 |   | simo...@microsoft.com
 |   |  wrote:
 |   |   There is a long discussion on
 |   |   https://ghc.haskell.org/trac/ghc/ticket/8827
 |   |   about whether the new Coercible story makes GND ok for Safe
 |  Haskell.
 |   |   At a type-soundness level, definitely yes.  But there are other
 |   |  less-clear-cut issues like “breaking abstractions” to consider.
 |   | The   decision on the ticket   (comment:36) seems to be: GND
 |  stays
 |   | out of Safe Haskell for now, but   there is room for a better
 |   | proposal.
 |   |  
 |   |  
 |   |  
 |   |   I don’t have an opinion myself. David Terei and David Mazieres
 |   | are in   the driving seat, but I’m sure they’ll be responsive to
 |  user input.
 |   |  
 |   |  
 |   |  
 |   |   However, I think the user manual may not have kept up with
 |  #8827.
 |   |  The
 |   |   sentence “GeneralizedNewtypeDeriving — It can be used to violate
 |   |  constructor access control, by allowing untrusted code to
 |   | manipulate   protected data types in ways the data type author did
 |   | not intend,   breaking invariants they have established.”
 |  vanished
 |   | from the 7.8

Roles, GND, Data.Coerce

[David Terei]

All,

An issue that came up with GHC 7.8 was the design of Roles and
Data.Coerce, with it's ability to break module abstractions by
default, requiring programmers adopt explicit role annotations to
enforce some types of invariants for abstract data types.

Because of this issue, as of now, GND  Data.Coerce are still disabled
in Safe Haskell. We'd like to change this but need feedback from
everyone.

I've written up a wiki page with lots of information on the issue:

https://ghc.haskell.org/trac/ghc/wiki/SafeRoles

Please read, it has information on how Roles work, the problem it
raises and subtleties in the current system. Possible paths forward
are also there, but I'll include below.

Please be aware that this discussion is about Roles in general, not
specifically how when using -XSafe. Ideally we'd come up with a
solution that works regardless of if using Safe Haskell or not.

I personally like option (3), although it isn't clear to me how hairy
the implementation would be.

== Possible Paths Forward for Roles ==

1) Do Nothing -- Keep Roles  GND unchanged, keep them unsafe in Safe Haskell.

2) Accept as Safe -- Keep Roles  GND unchanged, accept them as safe
in Safe Haskell and warn users that they neednominal role annotations
on ADTs.

3) In-scope constructor restriction for lifting instances -- The
newtype constructor restriction for unwrapping instances could be
extended to both data types, and the lifting instances of Data.Coerce.
This is, GND  Coercing under a type constructor is allowed if (a) all
involved constructors are in scope, or (b) the constructors involved
have been explicitly declared to allow coercion without them being in
scope. I.e., (b) allows library authors to opt-into the current GHC
behavior. This would require new syntax, probably just an explicit
deriving Coercible statement.

4) Change default role to nominal -- This will prioritize safety over
GND, and the belief is that it may break a lot of code. Worse, that it
will be an ongoing tax as role annotations will be needed to enable
GND.

5) Nominal default when constructors aren't exported -- When a module
doesn't export all the constructors of a data type, then the type
parameters of the data type should default to nominal. This heuristic
seems to capture somewhat the intention of the user, but given the
practice of defining an Internal module that exports everything, it
seems of limited use.

6) Nominal default in future -- Add a new extension,
SafeNewtypeDeriving that switches the default role to nominal, but
continue to provide a deprecated GND extension to help with the
transition. The claims in support of representational roles as default
though believe that nominal by default has an ongoing, continuous tax,
not just a transition cost. So it isn't clear that any scheme like
this satisfies that argument.

7) Safe Haskell Specific -- Many of the above approaches could be
adopted in a Safe Haskell specific manner. This isn't ideal as it
makes safe-inference harder and Safe Haskell less likely to remain
viable going forward. Richard suggests one such idea.

==

The belief by many people seems to be that (4) and (6) would be too
much of burden. I'd like to avoid (7) if possible. It isn't clear to
me if (7) ends up better than (2).

I'm going to try to setup some infastructure for compiling Hackage so
that we can measure how impactful these changes would be.

Cheers,
David
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Generalized Newtype Deriving not allowed in Safe Haskell

[David Terei]

Good advice. I'll set that up soon.

On 13 April 2015 at 00:10, Simon Peyton Jones simo...@microsoft.com wrote:
 David

 If you would like to lead a debate, and drive it to a conclusion, that would 
 be most helpful.

 Usually it's constructive to write a wiki page that sets out the design 
 choices, with examples to illustrate their consequences, to set the terms of 
 the debate.  Otherwise you risk misunderstandings, with red herrings being 
 discussed repeatedly.

 Thanks

 Simon

 |  -Original Message-
 |  From: davidte...@gmail.com [mailto:davidte...@gmail.com] On Behalf Of
 |  David Terei
 |  Sent: 12 April 2015 09:52
 |  To: Simon Peyton Jones
 |  Cc: Omari Norman; ghc-devs@haskell.org; haskell Cafe
 |  Subject: Re: Generalized Newtype Deriving not allowed in Safe Haskell
 |
 |  On 10 April 2015 at 01:48, Simon Peyton Jones simo...@microsoft.com
 |  wrote:
 |   |  prefer, such as only exporting the Coerce instance if all the
 |   | constructors are exported, it seems that the ship sailed on these
 |  
 |   Coercible is relatively recent; I don't think we should regard it as
 |  cast in stone.
 |  
 |   But yes, the Coerbible instance of a newtype is only available when
 |  the data constructor for the newtype is lexically in scope.
 |
 |  Yes, so as you point out in the paper, this is done to preserve
 |  abstractions, but the same rule isn't applied to data types since some
 |  types like IORef don't even have constructors that can be in scope.
 |
 |  Ideally I'd like to find a way forward that works for everyone and
 |  isn't just a Safe Haskell mode setting.
 |
 |  I think the first question is, are there situations where you'd want to
 |  use `coerce` internally to a module but disallow it externally? The
 |  role mechanism is a little awkward as it doesn't allow this (although
 |  it does for newtype's). If yes, then I think we should start there.
 |
 |  If it seems we don't need external vs internal control, then we could
 |  simply change the default to be that GHC sets referential type
 |  parameters to nominal and allows them to be weakened to referential
 |  through role annotations. We could use hackage to test how much
 |  breakage this would cause.
 |
 |  The third option is something Safe Haskell specific, so probably
 |  applying the newtype constructor rule to data types.
 |
 |  
 |   Simon
 |  
 |   |  -Original Message-
 |   |  From: davidte...@gmail.com [mailto:davidte...@gmail.com] On Behalf
 |   | Of  David Terei
 |   |  Sent: 10 April 2015 09:38
 |   |  To: Simon Peyton Jones
 |   |  Cc: Omari Norman; haskell Cafe; ghc-devs@haskell.org
 |   |  Subject: Re: Generalized Newtype Deriving not allowed in Safe
 |   | Haskell
 |   |
 |   |  I'll prepare a patch for the userguide soon.
 |   |
 |   |  As for something better, yes I think we can and should. It's on my
 |   | todo  list :) Basically, the new-GND design has all the mechanisms
 |   | to be  safe, but sadly the defaults are rather worrying. Without
 |   | explicit  annotations from the user, module abstractions are
 |  broken.
 |   | This is why  we left GND out of Safe Haskell for the moment as it
 |  is
 |   | a subtle and  easy mistake to make.
 |   |
 |   |  If the module contained explicit role annotations then it could be
 |   | allowed. The discussion in
 |   |  https://ghc.haskell.org/trac/ghc/ticket/8827 has other solutions
 |   | that I  prefer, such as only exporting the Coerce instance if all
 |   | the  constructors are exported, it seems that the ship sailed on
 |   | these  bigger changes sadly.
 |   |
 |   |  Cheers,
 |   |  David
 |   |
 |   |  On 9 April 2015 at 00:56, Simon Peyton Jones
 |   | simo...@microsoft.com
 |   |  wrote:
 |   |   There is a long discussion on
 |   |   https://ghc.haskell.org/trac/ghc/ticket/8827
 |   |   about whether the new Coercible story makes GND ok for Safe
 |  Haskell.
 |   |   At a type-soundness level, definitely yes.  But there are other
 |   |  less-clear-cut issues like “breaking abstractions” to consider.
 |   | The   decision on the ticket   (comment:36) seems to be: GND
 |  stays
 |   | out of Safe Haskell for now, but   there is room for a better
 |   | proposal.
 |   |  
 |   |  
 |   |  
 |   |   I don’t have an opinion myself. David Terei and David Mazieres
 |   | are in   the driving seat, but I’m sure they’ll be responsive to
 |  user input.
 |   |  
 |   |  
 |   |  
 |   |   However, I think the user manual may not have kept up with
 |  #8827.
 |   |  The
 |   |   sentence “GeneralizedNewtypeDeriving — It can be used to violate
 |   |  constructor access control, by allowing untrusted code to
 |   | manipulate   protected data types in ways the data type author did
 |   | not intend,   breaking invariants they have established.”
 |  vanished
 |   | from the 7.8   user manual (links below).  Maybe it should be
 |  restored.
 |   |  
 |   |  
 |   |  
 |   |   Safe Haskell aficionados, would you like to offer a patch for
 |  the
 |   | manual

Re: Generalized Newtype Deriving not allowed in Safe Haskell

[David Terei]

On 12 April 2015 at 13:01, Richard Eisenberg e...@cis.upenn.edu wrote:

 On Apr 12, 2015, at 9:51 AM, David Terei dave.te...@gmail.com wrote:

 Ideally I'd like to find a way forward that works for everyone and
 isn't just a Safe Haskell mode setting.

 Agreed. I'm not convinced this can be done, but it's certainly worth trying.


 I think the first question is, are there situations where you'd want
 to use `coerce` internally to a module but disallow it externally? The
 role mechanism is a little awkward as it doesn't allow this (although
 it does for newtype's). If yes, then I think we should start there.

 Yes, the ability to use `coerce` within one module but not elsewhere would be 
 nice. This can currently be simulated (without too much difficulty) with 
 newtypes. A datatype D can have a more permissive role signature than an 
 equivalent newtype N (where `newtype N = MkN D`). The package then exports N 
 (without its constructor). This effectively allows local uses of `coerce`, 
 even for datatypes. A more direct mechanism would be better, but I don't 
 think we should bend over backwards for it.


 If it seems we don't need external vs internal control, then we could
 simply change the default to be that GHC sets referential type
 parameters to nominal and allows them to be weakened to referential
 through role annotations. We could use hackage to test how much
 breakage this would cause.

 I worry that the breakage would be significant. But, now that authors have 
 had a chance to put in role annotations, maybe it wouldn't be so bad. The 
 change to GHC to make this happen is trivial: just change default_role in 
 TcTyDecls.initialRoleEnv1. I don't have the infrastructure around to make an 
 all-of-Hackage test, but I'm happy to support someone else who does.

A way to temper this as discussed in the ticket is to have the default
be determined by the export list. A data type with all it's
constructors exported can default to representational roles when
possible, while nominal roles would be the default when a subset of
constructors are exported.

This is more complex for users to understand, but does map to the
semantics expected under Haskell2010. It may be best to drive this
decision with data.

Luckily we've also got infrastructure for testing against Hackage:
http://hackage.haskell.org/package/hackager


 Richard
 ___
 ghc-devs mailing list
 ghc-devs@haskell.org
 http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Proposal: Improving the LLVM backend by packaging it

[David Terei]

Late to the conversation sorry.

I think this sounds like a good plan. Given we are planning to stick with a 
vanilla LLVM but just fix the version, it seems it should make it reasonable to 
have distro’s support this. We can provide binaries easily, but also just a 
declaration that llvm-3.4 is the current supported version, so please package 
that and tell GHC where to find it.

We already do this in a weak way by checking which version of LLVM the user is 
using and issuing a warning when it’s one we don’t support.

The other aspect that would be very useful is if all the build machines tested 
with LLVM as well. It’s a lot of work to support LLVM across all the platforms 
we support and to track changes across both communities. Automated testing of 
the currently supported LLVM version and LLVM-HEAD would be great.

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

Re: [commit: ghc] master: Be consistent with placement of Safe Haskell mode at top of file (2a523eb)

[David Terei]

Necessary is a strong statement, it's obviously not as it's style.

I personally think it's better to have Safe Haskell pragmas at the top
as they aren't like other pragmas, they don't just turn something on
but make a hard statement about the module in question. As such it
seems better to me to keep them at the top to retain this distinction
from other pragmas.

If you feel or others a different style is better, that's fine. There
isn't any consistent style with pragmas so I introduced one. If
considering my argument above you prefer alphabetical then feel free
to revert the patch. It would be nice if we had a consistent style
though with pragmas. I don't care strongly what it is, just that it
exists.

Cheers,
David

On 21 November 2014 13:30, Herbert Valerio Riedel h...@gnu.org wrote:
 Hello David,

 On 2014-11-21 at 22:03:23 +0100, git-4Dsf34iY/nkouohngz6...@public.gmane.org 
 wrote:

 [...]

 commit 2a523ebf091478aea39deef28073320bed628434
 Author: David Terei code-a0igw9aefh2m2scgvva...@public.gmane.org
 Date:   Wed Nov 19 18:29:51 2014 -0800

 Be consistent with placement of Safe Haskell mode at top of file

 Why is that necessary?

 Fwiw, I'm afraid that's gonna be hard to retain; it's more
 obvious/easier to keep all LANGUAGE pragmas in alphabetic order (I've
 probably done that a couple of times in `base` deliberately myself) than
 to introduce such an artificial ordering on the language pragmas.

 The reason is, you can instruct an editor to select the first paragraph
 which comprises the block of one-per-line language-pragmas is, and have
 it sorted it alphabetically. That's just a few keystrokes. But it's
 rather difficult to teach the editor to use an ordering relation other
 than the usual alphabetic/lexicographic ordering.

 Cheers,
   hvr
 ___
 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: Overlapping and incoherent instances

[David Terei]

This is great! It's nice to see something finer grain.

We'd of course like to bring Safe Haskell into the picture though! Our
concern with the new design as it stands is the OVERLAPS flag. We'd
prefer it to be eliminated in favor of requiring developers specify
both OVERLAPPABLE and OVERLAPS if that truly is their intention.

# Why?

## Long Version
https://ghc.haskell.org/trac/ghc/wiki/SafeHaskell/NewOverlappingInstances#NewOverlappingInstances--a.k.aInstanceSpecificPragmas

## Short Version (kind-of)
The security implications of OVERLAPPABLE vs. OVERLAPPING are fairly
different. Remember, in Safe Haskell we apply a policy of only
allowing instances from a module M compiled with `-XSafe` to overlap
other instances from module M. If it overlaps (and is the most
specific overlap) instances from modules other than M then we don't
allow this to succeed. This is done to ensure that untrusted code
compiled with `-XSafe` can't alter the behavior of existing code, some
of which may be part of the TCB and security critical.

Brining the new finer grained pragmas into the story we get the following:
* OVERLAPPABLE is the programmer communicating that they can be
overlapped, an open instance if you will. We want to relax the above
restriction and allow instances from `-XSafe` modules to overlap
instances from their own module AND instances declared OVERLAPPABLE
that reside in any module.
* OVERLAPPING is the programming simply declaring they may overlap
less specific instances. We want to keep the above restriction for
these instances. That is, a instance I1 from a `-XSafe` module M won't
be able to overlap as the most specific instance, a instance I2 from
another module if I2 is marked as OVERLAPPING.

This distinction enables new encodings in Safe Haskell by allowing
security library authors to distinguish how untrusted code can overlap
their instances. In some way giving them open vs closed instances.

This distinction is subtle and important. Having a pragma OVERLAPS
that implies both glosses over this and will encourage developers to
use this without much thought.

## Safe Inference
We can also safely infer a module that only has OVERLAPPABLE instances
as safe, while ones that contain OVERLAPPING or OVERLAPS instances
must be regarded as unsafe since there is a difference in semantics of
these pragmas under Safe vs Unsafe.

So we also have an advantage if developers are more specific about
what they want, than just defaulting to OVERLAPS.

Cheers,
David

On 29 July 2014 02:11, Simon Peyton Jones simo...@microsoft.com wrote:
 Friends

 One of GHC’s more widely-used features is overlapping (and sometimes
 incoherent) instances.  The user-manual documentation is here.

 The use of overlapping/incoherent instances is controlled by LANGUAGE
 pragmas: OverlappingInstances and IncoherentInstances respectively.

 However the overlap/incoherent-ness is a property of the *instance
 declaration* itself, and has been for a long time.  Using LANGUAGE
 OverlappingInstances simply sets the “I am an overlapping instance” flag for
 every instance declaration in that module.

 This is a Big Hammer.  It give no clue about *which* particular instances
 the programmer is expecting to be overlapped, nor which are doing the
 overlapping.It brutally applies to every instance in the module.
 Moreover, when looking at an instance declaration, there is no nearby clue
 that it might be overlapped.  The clue might be in the command line that
 compiles that module!

 Iavor has recently implemented per-instance-declaration pragmas, so you can
 say

 instance {-# OVERLAPPABLE #-} Show a = Show [a] where …

 instance {-# OVERLAPPING #-} Show [Char] where …

 This is much more precise (it affects only those specific instances) and it
 is much clearer (you see it when you see the instance declaration).

 This new feature will be in GHC 7.10 and I’m sure you will be happy about
 that.  But I propose also to deprecate the LANGUAGE pragmas
 OverlappingInstances and IncoherentInstances, as way to encourage everyone
 to use the new feature instead of the old big hammer.  The old LANGUAGE
 pragmas will continue to work, of course, for at least another complete
 release cycle.  We could make that two cycles if it was helpful.

 However, if you want deprecation-free libraries, it will entail a wave of
 library updates.

 This email is just to warn you, and to let you yell if you think this is a
 bad idea.   It would actually not be difficult to retain the old LANGUAGE
 pragmas indefinitely – it just seems wrong not to actively push authors in
 the right direction.

 These deprecations of course popped up in the test suite, so I’ve been
 replacing them with per-instance pragmas there too.  Interestingly in some
 cases, when looking for which instances needed the pragmas, I found…none. So
 OverlappingInstances was entirely unnecessary.  Maybe library authors will
 find that too!

 Simon


 ___
 

Re: [GHC] #4213: LLVM: Add support for TNTC to LLVM compiler suite

[David Terei]

Firstly, its cool that LLVM has added this. It seems we could indeed
implement TNTC with it. However based my quick understanding we couldnt
implement it in a wag compatible with the current design.

I believe the LLVM feature only allows us to place data at the very start
of the function, after the label not before it. And your meant to ensure
the very first instruction of the function is a jump that jumps over the
data. We could use this, Simon Marlow and I discussed such a design in the
past. But it's a change from the current scheme so the NCG would also need
to change and it isn't clear if it would be as good as our current design.

The other issue is that fixing TNTC doesn't eliminate the mangler. We use
it for a few different reasons now. I can think of at least 3 I believe:
TNTC, SIMD, and Windows.

As for moving to the LLVM api. No, I think that isn't a great idea. I'm not
convinced its will gain much compilation speed improvement. This is
testable vy measuring how much time is actually spent invoking the LLVM
binaries and how much time they spend serializing and parsing files.

Given we need to go to an intermediary file of assembly for the mangler...

Using the API also creates a GHC build time dependency on LLVM. Right now
we avoid that which has advantages.

On 22/05/2014 10:12 pm, GHC ghc-devs@haskell.org wrote:

 #4213: LLVM: Add support for TNTC to LLVM compiler suite
 -+
 Reporter:  dterei|Owner:  dterei
 Type:  feature request   |   Status:  new
 Priority:  low   |Milestone:  7.6.2
Component:  Compiler (LLVM)   |  Version:  6.13
   Resolution:| Keywords:
 Operating System:  Unknown/Multiple  | Architecture:  Unknown/Multiple
  Type of failure:  None/Unknown  |   Difficulty:  Unknown
Test Case:|   Blocked By:
 Blocking:|  Related Tickets:
 -+

 Comment (by awson):

  I'm extremely sorry for a kind of OT. There is another LLVM/infotable
  related ticket, which I don't know how to solve
  [https://ghc.haskell.org/trac/ghc/ticket/8974 without the mangler]. Could
  you, please, look into it and check if we can fix that without mangler
or,
  perhaps, understand what a feature we could ask LLVM people to introduce.

 --
 Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/4213#comment:14
 GHC http://www.haskell.org/ghc/
 The Glasgow Haskell Compiler
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: We need to add role annotations for 7.8

[David Terei]

Adding in GHC-DEV. Yes, sorry for no contact, my GHC email filter was
misconfigured so only got alerted when SPJ emailed me directly a few
days back.


On 18 March 2014 17:36, David Mazieres expires 2014-06-16 PDT
mazieres-i58umkudjfnfpfdx6jbbn3y...@temporary-address.scs.stanford.edu
wrote:
 At Fri, 14 Mar 2014 18:45:16 +0100,
 Mikhail Glushenkov wrote:

 Hi Richard,

  The real trouble with making this decision is that we have no real
  guidance. We've tried contacting David Terei (the originator of
  Safe Haskell) several times to no avail. If you are an actual
  consumer of Safe Haskell and would like to share your opinion on
  this front, I do encourage you to make a ticket, essentially
  requesting a resurrection of the extra Safe checks.

 Yes, it would be nice if David Terei or David Mazières (CC:ed) could comment.

 Sadly, it appears some mail may not have made it through to David
 Terei's mailbox.

 At any rate, David and I just discussed the new Coerce typeclass.
 Based on David's understanding of its behavior, it sounds pretty
 dangerous for Safe Haskell.  At a minimum, the programmer is going to
 need to understand a lot more than Haskell 2010 to write secure code.

 Based on my possibly limited understanding of the new
 feature--automatically generating instances of the Coerce type seems
 very un-Haskell-like.  By analogy, we could automatically generate
 instance of Read and Show (or add equivalent DebugRead/DebugShow
 classes) wherever possible, but this would similarly break abstraction
 by providing effective access to non-exported constructors.

 I understand why there is a need for something better than
 GeneralizedNewtypeDeriving.  However, implementing Coerce as a
 typeclass has the very serious disadvantage that there is no Haskell
 mechanism for controlling instance exports.  And if we are going to
 add a new mechanism (roles) to control such exports, exporting an
 instance that is never requested and that undermines modularity and
 abstraction is an unfortunate default.

 It may be too late for this, but a cleaner solution more in keeping
 with other extensions would be to have a -XDeriveCoerce extension that
 allows Coerce to be explicitly derived when safe.  This could be
 combined with leaving the previous behavior of
 GeneralizedNewtypeDeriving and just deprecating the language feature.

 Though controlling instance exports does not have a precedent, another
 option might be to special-case the Coerce class and only export
 instances of Coerce when all constructors of a type are also exported.
 This would prevent anyone from using Coerce to do things they couldn't
 already do manually.

 David

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

Re: how to checkout proper submodules

[David Terei]

On 5 June 2013 01:43, Manuel M T Chakravarty c...@cse.unsw.edu.au wrote:

 I agree with Austin and Johan. It's a bizarre setup. Submodules have their
 pain points (which we already have to deal with), but the ability to
 properly snapshot and branch the whole tree would be a serious benefit IMO.

 Manuel

 PS: While we are at it, why don't we just have the main repos on GitHub
 and use forks and pull requests like the rest of the world? (Using Git, but
 not GitHub's superb infrastructure, seems like a terrible waste to me.)


I'd be all for this. We partially use the GitHub infrastructure since trac
broke and I changed the emails to point to GitHub instead. I also often do
code reviews with other devs on a personal GHC fork on github before
merging in.

I believe it would also help encourage more contributors (especially for
libraries) but others have expressed disagreement with this point of view
in the past and I'm not in hold of data.

Either way, I'm glad git bisect may soon work. We'll finally be able to use
the whole feature set of a version control tool :)  (other piece was the
move from darcs - git which gave us a working annotate).


 Simon Peyton-Jones simo...@microsoft.com:
  For the avoidance of doubt, I totally support what Austin and Johan are
 saying:
 
  I find the current setup confusing too.
 
  I'm totally persuaded of the merits of git bisect etc.
 
  I am the opposite of a git power-user (a git weedy-user?).  I will be
 content to do whatever I'm told workflow-wise, provided I am told clearly
 in words of one syllable.
 
  I *very strongly* want to reduce barriers to entry for would-be
 contributors, and this is clearly a barrier we could lower.  Making Kazu,
 Austin, Johan, etc more productive is massively valuable.
 
  There may be some history to how we arrived at this point, but that
 should not constrain for the future.  We can change our workflow.   I would
 want Ian and Simon to be thoroughly on board, but I regard the current
 setup as totally open to improvement.  Please!
 
  BTW, Ian has written it up quite carefully here:
 http://hackage.haskell.org/trac/ghc/wiki/Repositories, and the linked
 page http://hackage.haskell.org/trac/ghc/wiki/Repositories/Upstream.
 
  Simon
 
 
 
  | -Original Message-
  | From: ghc-devs-boun...@haskell.org [mailto:
 ghc-devs-boun...@haskell.org]
  | On Behalf Of Austin Seipp
  | Sent: 05 June 2013 07:35
  | To: Johan Tibell
  | Cc: ghc-devs@haskell.org
  | Subject: Re: how to checkout proper submodules
  |
  | I absolutely agree here, FWIW. We should only do this if there is a
  | clear consensus on doing so and everyone doing active development is
  | comfortable with it. And it's entirely possible submodules are
  | inadequate for some reason that I'm not aware of which is a
  | show-stopper.
  |
  | However, the notion of impact-on-contributors cuts both ways. GHC has
  | an extremely small team of hackers as it stands, and we are lucky to
  | have *amazing* contributors like Kazu, Andreas, yourself, Simon 
  | Simon, and numerous others help make GHC what it is. Much of this is
  | volunteer work. But as the Haskell community grows, and we are at a
  | loss of other full-time contributors like Simon Marlow, I think we are
  | beginning to see the strain on GHC and its current contributors. So,
  | it's important to evaluate what we're doing right and wrong. This
  | feedback loop is always present even if seasoned contributors can live
  | with it - but new contributors will definitely be impacted.
  |
  | In this instance, I honestly find it disheartening that the answer to
  | things like getting older revisions of the source code in HEAD, or
  | techniques like bisection is basically that doesn't work. The second
  | is unfortunate, but the latter is pretty legitimately worrying. It
  | would be one thing if this was a one-off occurrence of some odd
  | developer-workflow. But I have answered the fundamental question here
  | (submodules vs free-floating clones) a handful of times myself at
  | least, experienced the pain of the decision myself when doing
  | rollbacks, and I'm sure other contributors can say the same.
  |
  | GHC is already a large, industry-strength software project with years
  | of work put behind it. The barrier to entry and contribution is not
  | exactly small, but I think we've all done a good job. I'd love to see
  | more people contributing. But I cannot help but find these discussions
  | a bit sad, where contributors are impaired due to regular/traditional
  | development workflows like rollbacks are rendered useless - due to
  | some odd source control discrepancy that nobody else on the planet
  | seems to suffer from.
  |
  | I guess the short version is basically that that you're absolutely
  | right: the time of Simon, Ian, and other high-profile contributors is
  | *extremely* important. But I'd also rather not have people like Kazu
  | potentially spend hours or even days doing what simple 

Re: STM Commentary

[David Terei]

The wiki is 'official' but also very open -- everyone is happy with
info being put up there sonner than later and with mistakes.


On 17 May 2013 14:15, Ryan Yates fryguy...@gmail.com wrote:

 On Fri, May 17, 2013 at 4:19 PM, Ian Lynagh i...@well-typed.com wrote:

 Why not put it on
 http://hackage.haskell.org/trac/ghc/wiki/Commentary/Rts/STM
 ? If you sign up for an account on the trac then you should be able to
 edit that page.


 Sure, I wanted to make sure that anyone who wanted had a chance to review
 it before it ends up somewhere official :D.

 Ryan

 ___
 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: Safe Haskell validate failure

[David Terei]

I thought the parallel problems had all been resolved. I'll try to
replicate locally.


On 23 April 2013 01:11, Simon Peyton-Jones simo...@microsoft.com wrote:

  When running validate I got these failures (below) from Safe Haskell.

 ** **

 Unexpected failures:

ghci/scripts   Defer02 [bad stderr] (ghci)

indexed-types/should_fail  T7786 [stderr mismatch] (normal)

perf/compiler  T3064 [stat too good] (normal)

safeHaskell/check/pkg01ImpSafeOnly01 [exit code non-0] (normal)

safeHaskell/check/pkg01ImpSafeOnly02 [exit code non-0] (normal)

safeHaskell/check/pkg01ImpSafeOnly03 [stderr mismatch] (normal)

safeHaskell/check/pkg01ImpSafeOnly04 [exit code non-0] (normal)

safeHaskell/check/pkg01ImpSafeOnly05 [stderr mismatch] (normal)

safeHaskell/check/pkg01ImpSafeOnly06 [exit code non-0] (normal)

safeHaskell/check/pkg01ImpSafeOnly07 [stderr mismatch] (normal)

safeHaskell/check/pkg01ImpSafeOnly08 [stderr mismatch] (normal)

safeHaskell/check/pkg01ImpSafeOnly09 [stderr mismatch] (normal)

safeHaskell/check/pkg01ImpSafeOnly10 [exit code non-0] (normal)

safeHaskell/check/pkg01safePkg01 [bad exit code] (normal)

 ** **

 ** **

 But when I manually did 

   cd testsuite/tests/safeHaskell/check

   make

 ** **

 all went fine.  Everything passed.  Could this be a parallel-make synch
 problem or something?  Or a make-clean problem?

 ** **

 Simon

 ** **

 = ImpSafeOnly01(normal) 1163 of 3620 [0, 0, 0]

 cd ./safeHaskell/check/pkg01  $MAKE -s --no-print-directory
 mkPackageDatabase.ImpSafeOnly01 VANILLA=--disable-library-vanilla
 PROF=--disable-library-profiling DYN=--enable-shared

 Wrong exit code (expected 0 , actual 2 )

 Stdout:

 pdb.safePkg01/local.db:

 safePkg01-1.0

 ** **

 trusted: False

 ** **

 M_SafePkg

 ** **

 Stderr:

 pdb.safePkg01/dist/build/M_SafePkg.hi: openBinaryFile: does not exist (No
 such file or directory)

 make[3]: *** [safePkg01] Error 1

 ** **

 *** unexpected failure for safePkg01(normal)

 cd ./safeHaskell/check/pkg01  $MAKE -s --no-print-directory
 cleanPackageDatabase.safePkg01

 = ImpSafeOnly02(normal) 1164 of 3620 [0, 1, 0]

 cd ./safeHaskell/check/pkg01  $MAKE -s --no-print-directory
 mkPackageDatabase.ImpSafeOnly02 VANILLA=--disable-library-vanilla
 PROF=--disable-library-profiling DYN=--enable-shared

 cd ./safeHaskell/check/pkg01 
 '/5playpen/simonpj/HEAD/bindisttest/install   dir/bin/ghc' -fforce-recomp
 -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts
 -fno-ghci-history -c ImpSafeOnly01.hs  -fpackage-trust -package-db
 pdb.ImpSafeOnly01/local.db -trust base  ImpSafeOnly01.comp.stderr 21***
 *

 Compile failed (status 256) errors were:

 ** **

 ImpSafeOnly01.hs:4:1:

 Failed to load interface for 'M_SafePkg'

 There are files missing in the 'safePkg01-1.0' package,

 try running 'ghc-pkg check'.

 Use -v to see a list of the files searched for.

 ** **

 *** unexpected failure for ImpSafeOnly01(normal)

 ___
 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: [commit: ghc] master: Implement type family instance support for :info (#4175) (ca39e77)

[David Terei]

Maybe an easy solution is to just use Github for now? i.e., simply
change the commit hook that send the email to link to:

https://github.com/ghc/ghc/commit/ca39e777907f8b16d8ede82e040b6f17fad99c9e

Cheers,
David

On 15 March 2013 12:15, Gabriel Dos Reis g...@integrable-solutions.net wrote:
 On Fri, Mar 15, 2013 at 10:55 AM, Simon Peyton Jones
 simo...@microsoft.com wrote:
 Repository : http://darcs.haskell.org/ghc.git/

 On branch  : master

 http://hackage.haskell.org/trac/ghc/changeset/ca39e777907f8b16d8ede82e040b6f17fad99c9e

 I've noticed, for about a week now, that the link embedded in
 commit messages no longer work as Trac appears to be unable
 to resolve them :-((

 -- Gaby

 ___
 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: LLVM 3.2 failure

[David Terei]

urgh... really need to get a LLVM build bot up and running.

I'm tied up for next week or two so won't be able to address this
soon. Thanks though Austin for your work here and everyone else, great
to have the pain shared :).

Cheers,
David

On 14 March 2013 10:00, Geoffrey Mainland mainl...@apeiron.net wrote:
 At least they didn't re-roll the release tarball a second time :)

 Would be good to confirm that we built from the same source tree. I am
 building LLVM HEAD right now and will try that with GHC.

 Geoff

 On 03/14/2013 04:54 PM, Austin Seipp wrote:
 The LLVM 3.2 tarball has an annoying bug: it specifies the version as
 '3.2svn' and not 3.2. So it's kind of difficult to distinguish them.
 You can verify this by downloading the 3.2 tarball from their website
 and looking at autoconf's AC_INIT line:

 $ pwd
 /Users/a/Downloads/llvm-3.2.src
 $ grep 3.2svn autoconf/configure.ac
 AC_INIT([LLVM],[3.2svn],[http://llvm.org/bugs/])

 It's likely Jan is using the right version. It's annoying as hell this
 bug is there, though* and LLVM developers don't generally do
 point-releases or update the tarballs. It's probably stuck like this
 until LLVM 3.3.

 * Any interested parties can find a patch for the 3.2 tarball here,
 but you'll of course have to apply manually and rebuild:

 https://github.com/thoughtpolice/homebrew/blob/35d39a504e619a3443abae0e249b366cc0ae4428/Library/Formula/llvm.rb#L108


 On Thu, Mar 14, 2013 at 11:47 AM, Geoffrey Mainland
 mainl...@apeiron.net wrote:
 On 03/14/2013 04:40 PM, Jan Stolarek wrote:
 If you type llc -version at the command line, it really says it's 3.2?
 You don't seem to believe me :)

 Given that Austin and I have the stage 2 compiler failure and you don't,
 I think it is reasonable do double check :)

 [killy@xerxes : ~] llc --version
 LLVM (http://llvm.org/):
   LLVM version 3.2svn
   Optimized build with assertions.
   Built Mar 14 2013 (09:02:06).
   Default target: x86_64-unknown-linux-gnu
   Host CPU: corei7

   Registered Targets:
 arm  - ARM
 cellspu  - STI CBEA Cell SPU [experimental]
 cpp  - C++ backend
 hexagon  - Hexagon
 mblaze   - MBlaze
 mips - Mips
 mips64   - Mips64 [experimental]
 mips64el - Mips64el [experimental]
 mipsel   - Mipsel
 msp430   - MSP430 [experimental]
 nvptx- NVIDIA PTX 32-bit
 nvptx64  - NVIDIA PTX 64-bit
 ppc32- PowerPC 32
 ppc64- PowerPC 64
 sparc- Sparc
 sparcv9  - Sparc V9
 thumb- Thumb
 x86  - 32-bit X86: Pentium-Pro and above
 x86-64   - 64-bit X86: EM64T and AMD64
 xcore- XCore
 [killy@xerxes : ~] opt --version
 LLVM (http://llvm.org/):
   LLVM version 3.2svn
   Optimized build with assertions.
   Built Mar 14 2013 (09:02:06).
   Default target: x86_64-unknown-linux-gnu
   Host CPU: corei7

 So at this point we are clearly dealing with a system-specific
 problem. The possible differences
 that come to my mind are:
 - I'm using LLVM 3.2 compiled from source, while you might be using a
 pre-built version from the
 repository
 - And I'm also using GHC 7.6.2 that I compiled by myself, instead of
 pre-built binaries available
 at GHC web site. Are you using the binaries or do you also compiled
 your GHC from sources?

 Janek

 I built LLVM 3.2 from source, but from the release tarball, not
 subversion. Does your svn checkout correspond exactly to the source in
 the 3.2 release tarball?

 I also built both GHC 7.4.2 and 7.6.2 from source (release tarballs),
 both using the native back end. Since it's the stage 2 compiler that is
 failing, it's difficult to see why this would matter.

 Geoff


 ___
 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: [commit: ghc] master: Change how dependency generation works; fixes #7381 (af072fc)

[David Terei]

Ian,

I think this patch or one related to it may have broken the expected behaviour.

Previously I could do:

$ ghc -M Main.hs

but now executing the above gives the error You must specify at least
one -dep-suffix. I can get the old behaviour by doing:

$ ghc -M Main.hs -dep-suffix=''

If the new behaviour is the expected one, then the userguide is now out of date.

Cheers,
David

On 2 November 2012 16:38, Ian Lynagh ig...@earth.li wrote:
 Repository : ssh://darcs.haskell.org//srv/darcs/ghc

 On branch  : master

 http://hackage.haskell.org/trac/ghc/changeset/af072fc35d8dbe7962e62700da052593e999c0ef

---

 commit af072fc35d8dbe7962e62700da052593e999c0ef
 Author: Ian Lynagh i...@well-typed.com
 Date:   Fri Nov 2 21:42:33 2012 +

 Change how dependency generation works; fixes #7381

 We now do the initial dependency generation for the vanilla way
 regardless of what way flags and hisuf/osuf flags are given. This
 makes it easier to generate the right dependency info in the end.

---

  compiler/main/DriverMkDepend.hs |   41 ++
  ghc.mk  |5 
  ghc/ghc.mk  |2 +-
  rules/build-dependencies.mk |   12 +--
  4 files changed, 31 insertions(+), 29 deletions(-)

 diff --git a/compiler/main/DriverMkDepend.hs b/compiler/main/DriverMkDepend.hs
 index 953b2c4..7355e31 100644
 --- a/compiler/main/DriverMkDepend.hs
 +++ b/compiler/main/DriverMkDepend.hs
 @@ -51,7 +51,25 @@ import Data.Maybe   ( isJust )
  doMkDependHS :: GhcMonad m = [FilePath] - m ()
  doMkDependHS srcs = do
  -- Initialisation
 -dflags - GHC.getSessionDynFlags
 +dflags0 - GHC.getSessionDynFlags
 +
 +-- We kludge things a bit for dependency generation. Rather than
 +-- generating dependencies for each way separately, we generate
 +-- them once and then duplicate them for each way's osuf/hisuf.
 +-- We therefore do the initial dependency generation with an empty
 +-- way and .o/.hi extensions, regardless of any flags that might
 +-- be specified.
 +let dflags = dflags0 {
 + ways = [],
 + buildTag = mkBuildTag [],
 + hiSuf = hi,
 + objectSuf = o
 + }
 +_ - GHC.setSessionDynFlags dflags
 +
 +when (null (depSuffixes dflags)) $
 +ghcError (ProgramError You must specify at least one -dep-suffix)
 +
  files - liftIO $ beginMkDependHS dflags

  -- Do the downsweep to find all the modules
 @@ -263,24 +281,13 @@ writeDependency root hdl targets dep
  -
  insertSuffixes
  :: FilePath -- Original filename;   e.g. foo.o
 -- [String] -- Extra suffices   e.g. [x,y]
 -- [FilePath]   -- Zapped filenames e.g. [foo.o, foo.x_o, 
 foo.y_o]
 +- [String] -- Suffix prefixes  e.g. [x_, y_]
 +- [FilePath]   -- Zapped filenames e.g. [foo.x_o, foo.y_o]
  -- Note that that the extra bit gets inserted *before* the old suffix
 --- We assume the old suffix contains no dots, so we can strip it 
 with removeSuffix
 -
 --- NOTE: we used to have this comment
 --- In order to construct hi files with alternate suffixes, we
 --- now have to find the basename of the hi file.  This is
 --- difficult because we can't just split the hi filename
 --- at the last dot - the hisuf might have dots in it.  So we
 --- check whether the hi filename ends in hisuf, and if it 
 does,
 --- we strip off hisuf, otherwise we strip everything after 
 the
 --- last dot.
 --- But I'm not sure we care about hisufs with dots in them.
 --- Lots of other things will break first!
 -
 +-- We assume the old suffix contains no dots, so we know where to
 +-- split it
  insertSuffixes file_name extras
 -  = file_name : [ basename . (extra ++ _ ++ suffix) | extra - extras ]
 +  = [ basename . (extra ++ suffix) | extra - extras ]
where
  (basename, suffix) = case splitExtension file_name of
   -- Drop the . from the extension
 diff --git a/ghc.mk b/ghc.mk
 index c1544ad..6c0a29a 100644
 --- a/ghc.mk
 +++ b/ghc.mk
 @@ -138,6 +138,11 @@ ifeq $(findstring v,$(GhcLibWays)) 
  $(error v is not in $$(GhcLibWays), and $$(DYNAMIC_BY_DEFAULT) is not YES)
  endif
  endif
 +ifeq $(GhcProfiled) YES
 +ifeq $(findstring p,$(GhcLibWays)) 
 +$(error p is not in $$(GhcLibWays), and $$(GhcProfiled) is YES)
 +endif
 +endif
  endif

  ifeq $(phase) 
 diff --git a/ghc/ghc.mk b/ghc/ghc.mk
 index ac8ce66..809756e 100644
 --- a/ghc/ghc.mk
 +++ b/ghc/ghc.mk
 @@ -64,7 +64,7 @@ ghc_stage3_MORE_HC_OPTS += -threaded
  endif

  ifeq $(GhcProfiled) YES
 

Re: [commit: ghc] simd: Fixup stack spills when generating AVX instructions. (b787b5d)

[David Terei]

Do we have a longer term solution for this? I love the SIMD work, so
please don't take this as a complaint, I agree with getting it done
for now with the mangler and truth is it's doubtful we'll et around to
adding TNTC support to LLVM anytime soon, so mangler is here to stay
for now.

BUT. I would like to see some thought about how in an ideal world with
lots of free time to hack on GHC we'd kill the mangler. Do we know
that plan for this patch? If so it may be nice to document it
somewhere and perhaps create a trac ticket.

On 14 February 2013 23:16, Geoffrey Mainland gmain...@microsoft.com wrote:
 Repository : ssh://darcs.haskell.org//srv/darcs/ghc

 On branch  : simd

 http://hackage.haskell.org/trac/ghc/changeset/b787b5d1e687fb28643cdd6a847ccc26bb014a79

---

 commit b787b5d1e687fb28643cdd6a847ccc26bb014a79
 Author: Geoffrey Mainland gmain...@microsoft.com
 Date:   Sat Nov 26 12:45:23 2011 +

 Fixup stack spills when generating AVX instructions.

 LLVM uses aligned AVX moves to spill values onto the stack, which requires
 32-bye aligned stacks. Since the stack in only 16-byte aligned, LLVM 
 inserts
 extra instructions that munge the stack pointer. This is very very bad 
 for the
 GHC calling convention, so we tell LLVM to assume the stack is 32-byte
 aligned. This patch rewrites the spill instructions that LLVM generates 
 so they
 do not require an aligned stack.

---

  compiler/llvmGen/LlvmMangler.hs |   38 ++
  1 files changed, 38 insertions(+), 0 deletions(-)

 diff --git a/compiler/llvmGen/LlvmMangler.hs b/compiler/llvmGen/LlvmMangler.hs
 index 83a2be7..745dcc6 100644
 --- a/compiler/llvmGen/LlvmMangler.hs
 +++ b/compiler/llvmGen/LlvmMangler.hs
 @@ -20,6 +20,10 @@ import System.IO
  import Data.List ( sortBy )
  import Data.Function ( on )

 +#if x86_64_TARGET_ARCH
 +#define REWRITE_AVX
 +#endif
 +
  -- Magic Strings
  secStmt, infoSec, newLine, textStmt, dataStmt, syntaxUnified :: B.ByteString
  secStmt   = B.pack \t.section\t
 @@ -47,6 +51,7 @@ llvmFixupAsm dflags f1 f2 = {-# SCC llvm_mangler #-} do
  w - openBinaryFile f2 WriteMode
  ss - readSections r w
  hClose r
 +let fixed = (map rewriteAVX . fixTables) ss
  let fixed = fixTables ss
  mapM_ (writeSection w) fixed
  hClose w
 @@ -90,6 +95,39 @@ writeSection w (hdr, cts) = do
  B.hPutStrLn w hdr
B.hPutStrLn w cts

 +#if REWRITE_AVX
 +rewriteAVX :: Section - Section
 +rewriteAVX = rewriteVmovaps . rewriteVmovdqa
 +
 +rewriteVmovdqa :: Section - Section
 +rewriteVmovdqa = rewriteInstructions vmovdqa vmovdqu
 +  where
 +vmovdqa, vmovdqu :: B.ByteString
 +vmovdqa = B.pack vmovdqa
 +vmovdqu = B.pack vmovdqu
 +
 +rewriteVmovap :: Section - Section
 +rewriteVmovap = rewriteInstructions vmovap vmovup
 +  where
 +vmovap, vmovup :: B.ByteString
 +vmovap = B.pack vmovap
 +vmovup = B.pack vmovup
 +
 +rewriteInstructions :: B.ByteString - B.ByteString - Section - Section
 +rewriteInstructions matchBS replaceBS (hdr, cts) =
 +(hdr, loop cts)
 +  where
 +loop :: B.ByteString - B.ByteString
 +loop cts =
 +case B.breakSubstring cts matchBS of
 +  (hd,tl) | B.null tl - hd
 +  | otherwise - hd `B.append` replaceBS `B.append`
 + loop (B.drop (B.length matchBS) tl)
 +#else /* !REWRITE_AVX */
 +rewriteAVX :: Section - Section
 +rewriteAVX = id
 +#endif /* !REWRITE_SSE */
 +
  -- | Reorder and convert sections so info tables end up next to the
  -- code. Also does stack fixups.
  fixTables :: [Section] - [Section]



 ___
 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: GHC 7.8 release?

[David Terei]

On 10 February 2013 13:02, Simon Peyton-Jones simo...@microsoft.com wrote:
 What I am still missing is this:

 |  Mark is asking for major GHC releases every year at the most, preferably
 |  less frequently.  That means major GHC releases in the sense that we do
 |  them now, where libraries change, and a wave of package updates are
 |  required to get everything working.

 What causes the wave of package updates?  Just because GHC 7.8 (say) comes 
 out, no package author need lift a finger.  The Haskell Platform sets the 
 pace for package updates. When the Haskell Platform comes out, now THAT is 
 indeed a trigger for a wave of updates.  Authors of packages in HP are forced 
 to act; authors of other packages want their packages to work with the next 
 HP.

 But there is no reason why package authors should respond to GHC releases, 
 provided we signpost it accurately.

 You may ask what use is a GHC release that doesn't cause a wave of updates?  
 And hence that doesn't work with at least some libraries.  Well, it's a very 
 useful forcing function to get new features actually out and tested.   Of 
 course we could just not do that, and say build from source, but a release 
 brings a welcome discipline.  But under this story, release or not-release 
 would be a Little Deal, not a Big Deal.  The benefits are modest; the costs 
 are modest.

 In short, I'm continuing to propose that we stick to the current story, but 
 signpost it better. If it ain't broke, don't fix it --- or at least fix only 
 the bits that are broken, which is the signposting.

My understanding of the proposed changes (which I'm also supportive
of) is to separate GHC improvements that break existing libraries (or
perhaps even simply add language level features), and those that are
improvements under-the-hood (e.g., bug fixes, performance
improvements).

So rather than 7.8 be a huge single release containing new type level
features, SIMD, the new code-generator. There would be two releases,
one containing just say the new-code-generator, improvements to the IO
manager, potentially also DPH... another release would containing new
language level improvements.

So then HP can benefit from improvements to the existing language and
API without having to also pull in breaking (or just extending)
changes...

It's the issue of a research compiler Vs. and industrial compiler and
managing that more explicitly in the release model.

Cheers,
David


 Simon

 |
 |  Johan, Manuel and Carter are saying that they want releases that add
 |  features but don't break code, i.e. a non-API-breaking release, as a way
 |  to get the new bits into the hands of the punters sooner.  This is
 |  something that we don't do right now, and it would entail a change to
 |  our workflow and release schedule.
 |
 |  It doesn't mean no API changes at all - we would have to allow APIs to
 |  be extended, because many feature additions come with new primops, or
 |  new supporting code in the ghc-prim or base packages.  The package
 |  version policy states precisely what it means to extend an API
 |  (http://www.haskell.org/haskellwiki/Package_versioning_policy) and most
 |  third-party packages will still work so long as we only bump the minor
 |  versions of the packages that come with GHC.
 |
 |  The GHC package itself would have to be exempt, because it contains
 |  every module in GHC, and hence would be impossible to keep stable if we
 |  are modifying the compiler to add new features.
 |
 |  Of course it's not practical to maintain an extra branch of GHC for
 |  non-API-breaking development - two branches is already plenty.  So there
 |  would need to be an API-freeze for a while between the major release and
 |  the non-API-breaking release, during which time people developing API
 |  changes would need to work on branches.
 |
 |  Is it workable?  I'm not sure, but I think it's worth a try.  I wouldn't
 |  want to see this replace the patchlevel bugfix releases that we already
 |  do, and as Ian points out, there isn't a lot of room in the release
 |  schedule for more releases, unless we stretch out the timescales, doing
 |  major releases less frequently.
 |
 |  Cheers,
 |   Simon
 |
 |
 |   ·Haskell Platform
 |  
 |   ·Patch-level releases
 |  
 |   ·New releases
 |  
 |  
 |   if that’s so, all we need is better signposting.   And I’m all for that!
 |  
 |   Have I got this right?
 |  
 |  
 |   Simon
 |  
 |   *From:*Mark Lentczner [mailto:mark.lentcz...@gmail.com]
 |   *Sent:* 09 February 2013 17:48
 |   *To:* Simon Marlow; Manuel M T Chakravarty; Johan Tibell; Simon
 |   Peyton-Jones; Mark Lentczner; andreas.voel...@gmail.com; Carter
 |   Schonwald; kosti...@gmail.com; Edsko de Vries; ghc-devs@haskell.org;
 |   glasgow-haskell-users
 |   *Subject:* Re: GHC 7.8 release?
 |  
 |   We seem to be circling ever closer to consensus here! Yay!
 |  
 |   I think the distinction of non-API breaking and API breaking release is
 |   very important. Refining SPJ's 

Re: nofib comparisons between 7.0.4, 7.4.2, 7.6.1, and 7.6.2

[David Terei]

On 5 February 2013 01:24, Nicolas Frisby nicolas.fri...@gmail.com wrote:
 Is anyone familiar with the fibon directory within the nofib.git
 repository?

 http://darcs.haskell.org/nofib/fibon/

Yes. They are from here: https://github.com/dmpots/fibon

Fibon is a newer, alternative benchmarking suite for Haskell done by
David M Peixotto. I've used it at times but sadly haven't had much
luck, it always seems to take many hours to run on my machine.


 Johan, this at least seems like an potential home for the additional
 programs you suggested adding. In particular, it has Repa, Dph, Shootout,
 and Hackage subdirectories.

 I'm doing a GHC HQ internship at the moment, and one of the
 just-needs-to-happen tasks on my (growing) todo list is to look into fibon.

 SPJ recalls that not all of the various building infrastructures were
 getting along. Anyone know the story? Thanks!


 On Mon, Feb 4, 2013 at 10:33 PM, Johan Tibell johan.tib...@gmail.com
 wrote:

 Hi all,

 I haven't had much time to do performance tzar work yet, but I did run
 nofib on the last few GHC releases to see the current trend. The benchmarks
 where run on my 64-bit Core i7-3770 @ 3.40GHz Linux machine. Here are the
 results:

 7.0.4 to 7.4.2:


 
 Program   SizeAllocs   Runtime   Elapsed  TotalMem

 
 Min  -1.6%-57.3%-39.1%-36.4%-25.0%
 Max +21.5%   +121.5%+24.5%+25.4%   +300.0%
  Geometric Mean  +8.5% -0.7% -7.1% -5.2% +2.0%

 The big loser here in terms of runtime is kahan, which I added to test
 tight loops involving unboxed arrays and floating point arithmetic. I
 believe there was a regression in fromIntegral RULES during this release,
 which meant that some conversions between fixed-width types went via
 Integer, causing unnecessary allocation.

 7.4.2 to 7.6.1:


 
 Program   SizeAllocs   Runtime   Elapsed  TotalMem

 
 Min  -5.1%-23.8%-11.8%-12.9%-50.0%
 Max  +5.3%   +225.5% +7.2% +8.8%   +200.0%
  Geometric Mean  -0.4% +2.1% +0.3% +0.2% +0.7%

 The biggest loser here in terms of runtime is integrate. I haven't
 looked into why yet.

 7.6.1 to 7.6.2:


 
 Program   SizeAllocs   Runtime   Elapsed  TotalMem

 
 Min  -2.9% +0.0% -4.8% -4.4% -1.9%
 Max  +0.0% +1.0% +4.5% +6.4%+20.8%
  Geometric Mean  -1.7% +0.0% +0.1% +0.3% +0.2%

 I have two takeaways:

  * It's worthwhile running nofib before releases as it does find some
 programs that regressed.
  * There are some other regressions out there (i.e. in code on Hackage)
 that aren't reflected here, suggesting that we need to add more programs to
 nofib.

 Cheers,
 Johan


 ___
 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


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

Re: nofib comparisons between 7.0.4, 7.4.2, 7.6.1, and 7.6.2

[David Terei]

On 5 February 2013 09:34, Johan Tibell johan.tib...@gmail.com wrote:
 On Tue, Feb 5, 2013 at 3:19 AM, David Terei davidte...@gmail.com wrote:

 On 5 February 2013 02:13, Simon Peyton-Jones simo...@microsoft.com
 wrote:
  I believe fibon/ was helpfully added by someone, but never integrated
  into
  the nofib build system.  Just needs doing, I think

 No I spent a fair amount of effort fixing this up about 9 months back.
 At that stage it worked fine, I haven't run for 6 months so not sure
 any more but they should be close to working at the least.


 Instead of trying to get fibon to work I'll try to get some of the shootout
 benchmarks into nofib. These are small micro benchmarks that shouldn't
 require anything special to run.

Agreed. The issue with the fibon folder as a whole is a lot of the
benchmarks have substantial dependencies as they are taken from
Hackage to represent real world programs. This is handled in a very
ugly fashion right now by just including a copy of the source of all
dependencies. So overtime it will always break as GHC and base
changes.

Shootout and some of them though don't have dependencies, so we should
look at moving them out of the fibon folder and enabling them by
default. After that we can look at better ways to handle the
dependencies of the remaining fibon benchmarks.

Why are you creating new shootout benchmarks though rather than simply
move the exiting Shootout folder from fibon/Shootout to the top level
and fixing the makefile?

Some of this discussion going forward may make more sense on trac.
There is trac ticket for improving nofib in general here:
http://hackage.haskell.org/trac/ghc/ticket/5793

Cheers,
David


 -- Johan


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

Re: links to diffs on ghc-commit emails seem to be broken

[David Terei]

I believe Ian disabled the Git integration features of Trac recently
as the machine running it has been acting up. Not sure when this will
be re-enable, potentially not until we move to a new machine.

Cheers,
David

On 4 February 2013 12:36, Carter Schonwald carter.schonw...@gmail.com wrote:
 Hey all,
 links seem to not work, though they are included in the emails

 eg
 from the email

 [commit: ghc] master: Move AsmCodeGen.makeFarBranches to PPC.Instr (#709)
 (aa1d7d3)

 http://hackage.haskell.org/trac/ghc/changeset/aa1d7d35ac27625c9aa67fe71c186f79600f0201

 *should* these be broken or is something needing to be fixed up?

 thanks
 -Carter

 ___
 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: simd branch ready for review

[David Terei]

On 31 January 2013 12:30, Geoffrey Mainland mainl...@apeiron.net wrote:
 On 01/31/2013 07:10 PM, David Terei wrote:
 On 31 January 2013 09:52, Geoffrey Mainland mainl...@apeiron.net wrote:
 On 01/31/2013 12:56 PM, Simon Marlow wrote:
 On 31/01/13 11:38, Geoffrey Mainland wrote:
 * Win32 issues

 Modern 32-bit x86 *NIX systems align the stack to 16-bytes, but Win32
 aligns only to 4-bytes. LLVM does not assume 16-byte stack
 alignment. Instead, on platforms where 16-byte stack alignment is not
 guaranteed, it 1) always outputs a function prologue that 2) aligns
 the stack to a 16-byte boundary with an and instructions, and it
 also 3) disables tail calls. Because LLVM aligns the stack for a
 function that has SSE register spills, it also generates movaps
 instructions (aligned SSE moves) for the spills.

 I must be misunderstanding your use of always above, because that
 would imply that the LLVM backend doesn't work on Win32 at all. Maybe
 LLVM only aligns the stack when it needs to store SSE values?

 You are correct---the stack-aligning prologue is only added by LLVM when
 SSE values are written to the stack, so this wasn't a problem before we
 had SSE support.

 This makes SSE support on Win32 difficult, and in my opinion not
 worth worrying about.

 The alternative is to 1) patch LLVM to disable the stack-alignment
 code so that we recover the ability to use tail calls and so that ebp
 scribbled over by the prologue and 2) patch the mangler to rewrite
 LLVM's movaps (move aligned) instructions to movups (move unaligned)
 instructions. I have these patches, but they are not included in the
 simd branch.

 I don't have an opinion here - maybe ask David T what he'd prefer.

 Requiring an LLVM hack seems pretty bad, and David yelled when I changed
 the mangler since he wants to get rid of it eventually. My patches are
 still around, so if we decide Win32 support is important, I can always
 add the changes.

 Not supporting Win32 sucks but yes, I want to move to just requiring
 LLVM un-patched and no mangler. How ugly are the patches for LLVM? I'd
 be supportive of it if the plan is to get them merged upstream.
 Otherwise, I don't think it is worth the effort of having to carry
 around our own patched LLVM for installation on windows.

 The patch against LLVM 3.0 is here:

 https://github.com/mainland/ghc-simd-tests/blob/master/patches/llvm-3.0.patch

 If you were to look, you'd see that it's not appropriate for upstream
 integration. Please don't look :)

Done :).


 Since we have support for Win64 as of GHC 7.6, I vote that we forget
 about Win32 support for SSE.

Yes, I meant to ask about Win64. Strongly agreed.


 Simon, this reminds me of two other issues...

 1) SSE vector values are only passed in registers on x86-64 anyway right
 now. MAX_REAL_FLOAT_REG and MAX_REAL_DOUBLE_REG are both #defined to 0
 on x86-32 in includes/stg/MachRegs.h. Are floats and double not passed
 in registers on x86-32? I'm confused as to how this works. The GHC
 calling convention in LLVM certainly says they are passed in registers.

Not on x86-32. From the LLVM userguide on the GHC calling convention:

On X86-32 only supports up to 4 bit type parameters. No floating
point types are supported.
On X86-64 only supports up to 10 bit type parameters and 6 floating
point parameters.


 2) SSE support is processor and platform dependent. What is the proper
 way for the programmer to know what SSE primitives are available? A CPP
 define? If so, what should it be called?

 Right now one can look at the TARGET_* and __GLASGOW_HASKELL_LLVM__ CPP
 macros and make a decision as to whether or not SSE primitives are
 available, but that's not a great solution. Also, what happens when we
 want to add AVX support? How do we control the inclusion of AVX support
 when building GHC, and how do we let the programmer know that the AVX
 primops/primtypes are available for use?

 Geoff


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

Re: [PATCH] do not use -rpath-link linker option on Solaris

[David Terei]

Looks good, just validated and pushed.

On 24 January 2013 13:28, Karel Gardas karel.gar...@centrum.cz wrote:
 This patch removes usage of -rpath-link option on Solaris OS since it is
 not supported by the Solaris' linker and its usage causes failures of a lot
 of `dyn' testcases
 ---
  compiler/main/DriverPipeline.hs |   11 ++-
  1 files changed, 10 insertions(+), 1 deletions(-)

 diff --git a/compiler/main/DriverPipeline.hs b/compiler/main/DriverPipeline.hs
 index f47aea7..34d045c 100644
 --- a/compiler/main/DriverPipeline.hs
 +++ b/compiler/main/DriverPipeline.hs
 @@ -1752,7 +1752,16 @@ linkBinary dflags o_files dep_packages = do
rpath = if gopt Opt_RPath dflags
then [-Wl,-rpath,  -Wl, ++ libpath]
else []
 -  in [-L ++ l, -Wl,-rpath-link, -Wl, ++ l] ++ rpath
 +  -- Solaris 11's linker does not support -rpath-link 
 option. It silently
 +  -- ignores it and then complains about next option which 
 is -lsome
 +  -- dir as being a directory and not expected object file, 
 E.g
 +  -- ld: elf error: file
 +  -- /tmp/ghc-src/libraries/base/dist-install/build:
 +  -- elf_begin: I/O error: region read: Is a directory
 +  rpath-link = if (platformOS platform) == OSSolaris2
 +   then []
 +   else [-Wl,-rpath-link, -Wl, ++ l]
 +  in [-L ++ l] ++ rpath-link ++ rpath
   | otherwise = [-L ++ l]

  let lib_paths = libraryPaths dflags
 --
 1.7.3.2


 ___
 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: [PATCH] fix runtests to set LD_LIBRARY_PATH environment variable

[David Terei]

Committed. Thanks!

On 24 January 2013 13:28, Karel Gardas karel.gar...@centrum.cz wrote:
 This patch follows Windows and Darwin way of setting environment variable
 to set the file-system paths to GHC's shared libraries. It does the same
 thing for any other OS, which should be Unix-like OS presumably. This
 patch fixes a lot of `dyn' tests failures on Solaris which fail with following
 error message:
 Failed to open shared library: ld.so.1: T3807-load: fatal: libffi.so.6: open 
 failed: No such file or directory
 ---
  driver/runtests.py |   48 ++--
  1 files changed, 26 insertions(+), 22 deletions(-)

 diff --git a/driver/runtests.py b/driver/runtests.py
 index 66e3bf4..16deda6 100644
 --- a/driver/runtests.py
 +++ b/driver/runtests.py
 @@ -181,28 +181,32 @@ from testlib import *

  # On Windows we need to set $PATH to include the paths to all the DLLs
  # in order for the dynamic library tests to work.
 -if windows or darwin:
 -pkginfo = getStdout([config.ghc_pkg, 'dump'])
 -topdir = config.libdir
 -for line in pkginfo.split('\n'):
 -if line.startswith('library-dirs:'):
 -path = line.rstrip()
 -path = re.sub('^library-dirs: ', '', path)
 -path = re.sub('\\$topdir', topdir, path)
 -if path.startswith(''):
 -path = re.sub('^(.*)$', '\\1', path)
 -path = re.sub('(.)', '\\1', path)
 -if windows:
 -if config.cygwin:
 -# On cygwin we can't put c:\foo in $PATH, as : is a
 -# field separator. So convert to /cygdrive/c/foo instead.
 -# Other pythons use ; as the separator, so no problem.
 -path = re.sub('([a-zA-Z]):', '/cygdrive/\\1', path)
 -path = re.sub('', '/', path)
 -os.environ['PATH'] = os.pathsep.join([path, 
 os.environ.get(PATH, )])
 -else:
 -# darwin
 -os.environ['DYLD_LIBRARY_PATH'] = os.pathsep.join([path, 
 os.environ.get(DYLD_LIBRARY_PATH, )])
 +# if windows or darwin:
 +pkginfo = getStdout([config.ghc_pkg, 'dump'])
 +topdir = config.libdir
 +for line in pkginfo.split('\n'):
 +if line.startswith('library-dirs:'):
 +path = line.rstrip()
 +path = re.sub('^library-dirs: ', '', path)
 +path = re.sub('\\$topdir', topdir, path)
 +if path.startswith(''):
 +path = re.sub('^(.*)$', '\\1', path)
 +path = re.sub('(.)', '\\1', path)
 +if windows:
 +if config.cygwin:
 +# On cygwin we can't put c:\foo in $PATH, as : is a
 +# field separator. So convert to /cygdrive/c/foo instead.
 +# Other pythons use ; as the separator, so no problem.
 +path = re.sub('([a-zA-Z]):', '/cygdrive/\\1', path)
 +path = re.sub('', '/', path)
 +os.environ['PATH'] = os.pathsep.join([path, 
 os.environ.get(PATH, )])
 +elif darwin:
 +# darwin
 +os.environ['DYLD_LIBRARY_PATH'] = os.pathsep.join([path, 
 os.environ.get(DYLD_LIBRARY_PATH, )])
 +else:
 +# unix
 +os.environ['LD_LIBRARY_PATH'] = os.pathsep.join([path, 
 os.environ.get(LD_LIBRARY_PATH, )])
 +

  global testopts_local
  testopts_local.x = TestOptions()
 --
 1.7.3.2


 ___
 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: LLVM failures

[David Terei]

My guess is llc doesn't like the arguments being passed to it. Try
running llc as follows:

$ llc -version

(one dash, not two). That works fine on linux and osx. Does it not
work on windows?

Cheers,
David

On 16 January 2013 21:30, Simon Peyton-Jones simo...@microsoft.com wrote:
 | Remember getting these errors, and I remember fixing them by having
 | llc-3.0 and opt-3.0 in the path.

 Hmm. Well, HP has llc 3.1 so if that doesn't work it's a right nuisance.

 David said to try -v2. Here's the result

 *** LlVM CodeGen:
 Error (figuring out LLVM version): : runInteractiveProcess: invalid argument 
 (Invalid argument)

 no location info:
 Warning: Couldn't figure out LLVM version!
  Make sure you have installed LLVM

 I have no idea what invalid argument means. I can do further experiments if 
 told what to try.

 Simon

 | -Original Message-
 | From: ghc-devs-boun...@haskell.org [mailto:ghc-devs-boun...@haskell.org]
 | On Behalf Of Nathan Hüsken
 | Sent: 16 January 2013 09:15
 | To: ghc-devs@haskell.org
 | Subject: Re: LLVM failures
 |
 | Remember getting these errors, and I remember fixing them by having
 | llc-3.0 and opt-3.0 in the path.
 |
 | On 01/14/2013 06:56 PM, Simon Peyton-Jones wrote:
 |  I'm getting testsuite failures like this on Windows
 | 
 |  no location info:
 |  Warning: Couldn't figure out LLVM version!
 |   Make sure you have installed LLVM
 | 
 |  Fair enough, but shouldn't 'configure' find out if I have LLVM.  And
 | if I don't, shouldn't the tests be disabled?
 | 
 |  Do we have instructions for installing LLVM on Windows?
 | 
 |  Simon
 | 
 | 
 | 
 |  ___
 |  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

 ___
 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: LLVM failures

[David Terei]

OK I'll try to get a windows machine up and fix this in the next week or so.

On 16 January 2013 23:29, Simon Peyton-Jones simo...@microsoft.com wrote:
 It's fine.  llc -version (one dash) works ok.  see below

 bash-3.1$ llc -version
 LLVM (http://llvm.org/):
   LLVM version 3.1
   Optimized build with assertions.
   Built May 22 2012 (00:18:58).
   Default target: i686-pc-mingw32
   Host CPU: corei7

   Registered Targets:
 arm  - ARM
 cellspu  - STI CBEA Cell SPU [experimental]
 cpp  - C++ backend
 hexagon  - Hexagon
 mblaze   - MBlaze
 mips - Mips
 mips64   - Mips64 [experimental]
 mips64el - Mips64el [experimental]
 mipsel   - Mipsel
 msp430   - MSP430 [experimental]
 ppc32- PowerPC 32
 ppc64- PowerPC 64
 ptx32- PTX (32-bit) [Experimental]
 ptx64- PTX (64-bit) [Experimental]
 sparc- Sparc
 sparcv9  - Sparc V9
 thumb- Thumb
 x86  - 32-bit X86: Pentium-Pro and above
 x86-64   - 64-bit X86: EM64T and AMD64
 xcore- XCore
 bash-3.1$

 | -Original Message-
 | From: David Terei [mailto:davidte...@gmail.com]
 | Sent: 16 January 2013 10:59
 | To: Simon Peyton-Jones
 | Cc: Nathan Hüsken; ghc-devs@haskell.org
 | Subject: Re: LLVM failures
 |
 | My guess is llc doesn't like the arguments being passed to it. Try
 | running llc as follows:
 |
 | $ llc -version
 |
 | (one dash, not two). That works fine on linux and osx. Does it not work
 | on windows?
 |
 | Cheers,
 | David
 |
 | On 16 January 2013 21:30, Simon Peyton-Jones simo...@microsoft.com
 | wrote:
 |  | Remember getting these errors, and I remember fixing them by having
 |  | llc-3.0 and opt-3.0 in the path.
 | 
 |  Hmm. Well, HP has llc 3.1 so if that doesn't work it's a right
 | nuisance.
 | 
 |  David said to try -v2. Here's the result
 | 
 |  *** LlVM CodeGen:
 |  Error (figuring out LLVM version): : runInteractiveProcess: invalid
 |  argument (Invalid argument)
 | 
 |  no location info:
 |  Warning: Couldn't figure out LLVM version!
 |   Make sure you have installed LLVM
 | 
 |  I have no idea what invalid argument means. I can do further
 | experiments if told what to try.
 | 
 |  Simon
 | 
 |  | -Original Message-
 |  | From: ghc-devs-boun...@haskell.org
 |  | [mailto:ghc-devs-boun...@haskell.org]
 |  | On Behalf Of Nathan Hüsken
 |  | Sent: 16 January 2013 09:15
 |  | To: ghc-devs@haskell.org
 |  | Subject: Re: LLVM failures
 |  |
 |  | Remember getting these errors, and I remember fixing them by having
 |  | llc-3.0 and opt-3.0 in the path.
 |  |
 |  | On 01/14/2013 06:56 PM, Simon Peyton-Jones wrote:
 |  |  I'm getting testsuite failures like this on Windows
 |  | 
 |  |  no location info:
 |  |  Warning: Couldn't figure out LLVM version!
 |  |   Make sure you have installed LLVM
 |  | 
 |  |  Fair enough, but shouldn't 'configure' find out if I have LLVM.
 |  |  And
 |  | if I don't, shouldn't the tests be disabled?
 |  | 
 |  |  Do we have instructions for installing LLVM on Windows?
 |  | 
 |  |  Simon
 |  | 
 |  | 
 |  | 
 |  |  ___
 |  |  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
 | 
 |  ___
 |  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