Re: [ANNOUNCE] GHC 8.0.2 release candidate 1

[Jens Petersen]

On 26 November 2016 at 07:38, Ben Gamari  wrote:

> http://downloads.haskell.org/~ghc/8.0.2-rc1/
>

Thank you, I built it for Fedora 25 (just released last week) and Rawhide:

https://copr.fedorainfracloud.org/coprs/petersen/ghc-8.0.2

Hopefully there will be a build for F24 soon too.

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

Re: [ANNOUNCE] GHC 8.0.2 release candidate 1

[Jens Petersen]

On 28 November 2016 at 16:37, Jens Petersen  wrote:

> I think it is not being generated.
>

Well it might be generated, but it is not getting installed properly by
default anyway.

Looks like a buildsystem regression to me wrt to 8.0.1: I guess we should
> file a bug...
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: [ANNOUNCE] GHC 8.0.2 release candidate 1

[Jens Petersen]

On 26 November 2016 at 22:46, Ben Gamari  wrote:

> > /usr/bin/install -c -m 644  docs/users_guide/build-man/ghc.1
> > "/usr/local/share/man/man1"
> > install: /usr/local/share/man/man1/ghc.1: No such file or directory
> > make[1]: *** [install_man] Error 71
> > make: *** [install] Error 2
>

I already mentioned this in a private mail to Ben.


> Thanks for the report, George! That is quite odd indeed. It sounds like
> /usr/local/share/man/man1/ghc.1 may have been a symlink to a directory
> which does not exist (possibly?).
>

I don't think so.  If you look at
ghc-8.0.1.20161117-x86_64-centos67-linux.tar.xz for example you will it
does not contain ghc.1 either: I think it is not being generated.
Looks like a buildsystem regression to me wrt to 8.0.1: I guess we should
file a bug...

Here
https://copr-be.cloud.fedoraproject.org/results/petersen/ghc-8.0.2/fedora-rawhide-i386/00479814-ghc/build.log.gz
is a complete buildlog and
https://github.com/fedora-haskell/ghc/commit/97b08fb4732a548db8e2bf7c8011b4419ac70d29
is my packaging workaround.

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

Re: Status of "Improved LLVM backend"

[Moritz Angermann]

> On Nov 27, 2016, at 10:17 PM, Michal Terepeta  
> wrote:
> 
> > Hi,
> > 
> > I’m trying to implement a bitcode producing llvm backend[1], which would 
> > potentially
> > allow to use a range of llvm versions with ghc. However, this is only 
> > tangentially
> > relevant to the improved llvm backend, as Austin correctly pointed out[2], 
> > as there are
> > other complications besides the fragility of the textual representation.
> > 
> > So this is mostly only relevant to the improved ir you mentioned. The 
> > bitcode code gen
> > plugin right now follows mostly the textual ir generation, but tries to 
> > prevent the
> > ubiquitous symbol to i8* casting. The llvm gen turns cmm into ir, at this 
> > point however
> > at that point, the wordsize has been embedded already, which means that the 
> > current
> > textual llvm gen as well as the bitcode llvm gen try to figure out if 
> > relative access is
> > in multiple wordsizes to use llvms getElementPointer.
> 
> That sounds interesting, do you know where could I find out more about this?
> (both when it comes to the current LLVM codegen and yours)

For the llvm code gen in ghc it’s usually the `_fast` suffix functions. See [1] 
and
the `genStore_fast` 30 lines further down.  My bitcode llvm gen follows that 
file [1],
almost identically, as can be seen in [2].  However the `_fast` path is 
currently
disabled. 

An example of the generated ir for the current llvm backend, and the bitcode 
backend,
(textual ir, via llvm-dis) can be found in [3] and [4] respectively.

> 
> > I don’t know if generating llvm from stg instead of cmm would be a better
> > approach, which is what ghcjs and eta do as far as I know.
> 
> Wouldn't a step from STG to LLVM be much harder (LLVM IR is a pretty low-level
> representation compared to STG)? There are also a few passes on the Cmm level
> that seem necessary, e.g., `cmmLayoutStack`.

There is certainly a tradeoff between retaining more high-level information and 
having to lower them oneself.  If I remember luite correctly, he said he had a 
similar
intermediate format to cmm, just not cmm but something richer, which allows
to better target javascript.  The question basically boils down to asking if 
cmm is
too low-level for llvm already; the embedding of wordsizes is an example where 
I think
cmm might be to low-level for llvm.

—
[1]: 
https://github.com/ghc/ghc/blob/master/compiler/llvmGen/LlvmCodeGen/CodeGen.hs#L824
[2]: 
https://github.com/angerman/data-bitcode-plugin/blob/master/src/Data/BitCode/LLVM/Gen.hs
[3]: https://gist.github.com/angerman/32ce9395e73cfea3348fcc7da108cd0a
[4]: https://gist.github.com/angerman/d87db1657aac4e06a0886801aaf44329
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: [ANNOUNCE] GHC 8.0.2 release candidate 1

[Judah Jacobson]

Thanks Ben!  When testing, I found that a type checker regression from 7.10
to 8.0 that I thought/hoped was resolved is in fact still present in this
release candidate.  I filed a new bug:
https://ghc.haskell.org/trac/ghc/ticket/12885

It originally seemed the same as #12175.  But unfortunately, although that
problem is resolved in 8.0.2-rc1, this one is still around (though they may
still be related).

Thanks,
-Judah


On Fri, Nov 25, 2016 at 2:38 PM, Ben Gamari  wrote:

>
> Hello everyone,
>
> The GHC team is happy to (finally!) announce the first candiate of the
> 8.0.2 release of the Glasgow Haskell Compiler. Source and binary
> distributions are available at
>
> http://downloads.haskell.org/~ghc/8.0.2-rc1/
>
> This is the first of what will hopefully be only two release candidates
> leading up the final 8.0.2 release. This release will fix a number bugs
> found in 8.0.1 including,
>
>   * Interface file build determinism (#4012).
>
>   * Compatibility with macOS Sierra and GCC compilers which compile
> position-independent executables by default
>
>   * Runtime linker fixes on Windows (see #12797)
>
>   * A compiler bug which resulted in undefined reference errors while
> compiling some packages (see #12076)
>
>   * Compatability with systems which use the gold linker
>
>   * A number of memory consistency bugs in the runtime system
>
>   * A number of efficiency issues in the threaded runtime which manifest
> on larger core counts and large numbers of bound threads.
>
>   * A typechecker bug which caused some programs using
> -XDefaultSignatures to be incorrectly accepted.
>
>   * More than two-hundred other bugs. See Trac [1] for a complete
> listing.
>
> Unfortunately there is one known bug (#12757) which can result in
> runtime crashes which is still lurking in -rc1. This will be fixed in
> -rc2, which will be released in about a week.
>
> As always, let us know if you encounter trouble. Thanks to everyone who
> has contributed so far!
>
> Happy testing,
>
> - Ben
>
>
> [1] https://ghc.haskell.org/trac/ghc/query?status=closed;
> milestone=8.0.2=id=summary=status=type&
> col=priority=milestone=component=priority
>
> ___
> 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: [ANNOUNCE] GHC 8.0.2 release candidate 1

[Brandon Allbery]

On Sun, Nov 27, 2016 at 8:30 AM, Tuncer Ayaz  wrote:

> However, what's changed from 8.0.1 to 8.0.2 to trigger this? I mean,
> is a point release supposed to do this? I would expect 8.0 to 8.1 to
> break, but find it surprising x.0.1 to x.0.2 would as well.
>

ImpredicativeTypes has *always* been broken, just in different ways in
every release. Worse, it never had a real specification, therefore no
tests. I think it's just going to be ripped out finally in the next major
release, since VisibleTypeApplication should handle most of the use cases.

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Status of "Improved LLVM backend"

[Michal Terepeta]

> Hi,
>
> I’m trying to implement a bitcode producing llvm backend[1], which would
potentially
> allow to use a range of llvm versions with ghc. However, this is only
tangentially
> relevant to the improved llvm backend, as Austin correctly pointed
out[2], as there are
> other complications besides the fragility of the textual representation.
>
> So this is mostly only relevant to the improved ir you mentioned. The
bitcode code gen
> plugin right now follows mostly the textual ir generation, but tries to
prevent the
> ubiquitous symbol to i8* casting. The llvm gen turns cmm into ir, at this
point however
> at that point, the wordsize has been embedded already, which means that
the current
> textual llvm gen as well as the bitcode llvm gen try to figure out if
relative access is
> in multiple wordsizes to use llvms getElementPointer.

That sounds interesting, do you know where could I find out more about this?
(both when it comes to the current LLVM codegen and yours)

> I don’t know if generating llvm from stg instead of cmm would be a better
> approach, which is what ghcjs and eta do as far as I know.

Wouldn't a step from STG to LLVM be much harder (LLVM IR is a pretty
low-level
representation compared to STG)? There are also a few passes on the Cmm
level
that seem necessary, e.g., `cmmLayoutStack`.

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

Re: [ANNOUNCE] GHC 8.0.2 release candidate 1

[Tuncer Ayaz]

On 27 November 2016 at 01:37, Tuncer Ayaz  wrote:
> On 25 November 2016 at 23:38, Ben Gamari  wrote:
> >
> > As always, let us know if you encounter trouble. Thanks to everyone
> > who has contributed so far!
>
> No trouble building and running rc1, but some code in xmonad-contrib
> that builds fine with 8.0.1 doesn't with 8.0.2-rc1. Not sure if it's
> broken code or a ghc regression.
>
> https://github.com/xmonad/xmonad-contrib/issues/123

It's a leftover use of ImpredicativeTypes and getting fixed[2]

However, what's changed from 8.0.1 to 8.0.2 to trigger this? I mean,
is a point release supposed to do this? I would expect 8.0 to 8.1 to
break, but find it surprising x.0.1 to x.0.2 would as well.

IIRC ImpredicativeTypes has been obsoleted a long time ago, and maybe
8.0.2 has fixes which catches code that slipped through before. That's
an explanation that would make sense. In that case, it seems ok.

[2] https://github.com/xmonad/xmonad-contrib/pull/124
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs