Re: ANNOUNCE: GHC 7.10.1 Release Candidate 1

[Herbert Valerio Riedel]

On 2014-12-28 at 04:41:45 +0100, cg wrote:

[...]

> Besides downloading a tarball, can I checkout it using git?
>
> I tried using sync-all as described on wiki [1] to checkout it:
>
> ./sync-all checkout ghc-7.10
>
> but it seems it doesn't work, there are error message like:
> error: pathspec 'ghc-7.10' did not match any file(s) known to git.

Rather follow

  
https://ghc.haskell.org/trac/ghc/wiki/Building/GettingTheSources#GettingabranchGHC7.9orlater

and/or

  https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Git/Submodules

i.e.

  git clone -b ghc-7.10 --recursive git://git.haskell.org/ghc.git

or (if you have already a GHC 7.9.x tree cloned out), use

  git checkout ghc-7.10 && git submodule update --init

to switch to the ghc-7.10 branch (and update the submodules)

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

Re: ANNOUNCE: GHC 7.10.1 Release Candidate 1

[cg]

*From:* Austin Seipp 
*Sent:* ‎Tuesday‎, ‎December‎ ‎23‎, ‎2014 ‎15‎:‎36
*To:* ghc-devs@haskell.org ,
glasgow-haskell-us...@haskell.org 

We are pleased to announce the first release candidate for GHC 7.10.1:

 https://downloads.haskell.org/~ghc/7.10.1-rc1/



Besides downloading a tarball, can I checkout it using git?

I tried using sync-all as described on wiki [1] to checkout it:

./sync-all checkout ghc-7.10

but it seems it doesn't work, there are error message like:
error: pathspec 'ghc-7.10' did not match any file(s) known to git.

[1] https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Releases



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

Re: ANNOUNCE: GHC 7.10.1 Release Candidate 1

[Tamar Christina]

Hi Edward,


You’re right, this is my mistake, I am compiling x86_64 Windows, I have not 
updated my tools to work on it yet so I’ve been using the x86_32 binaries and 
didn’t noticed that my msys2 was compiling a 64bit version.


That explains the warning, sorry for the false alarm!


Regards,

Tamar





From: Edward Z. Yang
Sent: ‎Saturday‎, ‎December‎ ‎27‎, ‎2014 ‎16‎:‎16
To: lonetiger
Cc: Austin Seipp, ghc-devs@haskell.org, glasgow-haskell-users@





Hello lonetiger,

I don't think any relevant logic changed in 7.10; however, this
commit may be relevant:

commit 8fb03bfd768ea0d5c666bbe07a50cb05214bbe92
Author: Ian Lynagh   Sun Mar 18 11:42:31 2012
Committer: Ian Lynagh   Sun Mar 18 11:42:31 2012
Original File: compiler/typecheck/TcForeign.lhs

If we say we're treating StdCall as CCall, then actually do so

But this warning should have applied even on older versions of GHC.

Are you running x86_64 Windows?  stdcall is specific to x86_32.

Edward

Excerpts from lonetiger's message of 2014-12-24 08:24:52 -0500:
> Hi,
> 
> 
> I’ve had some issues building this (and the git HEAD), it seems that the 
> config.guess and config.sub in the libffi tarball is old, it doesn’t detect 
> the platform when building with msys2. I had to unpack the tarfile and update 
> the files, after this it correctly built.
> 
> 
> Then I proceeded to try to make a shared library and got the following 
> warning:
> 
> 
> ManualCheck.hs:18:1: Warning:
> the 'stdcall' calling convention is unsupported on this platform,
> treating as ccall
> When checking declaration:
>   foreign export stdcall "testFoo" testFooA :: CInt -> IO (FooPtr)
> 
> 
> 
> Does this mean that GHC no longer supports stdcall on windows? or could this 
> be related to issue I had building?
> 
> 
> Regards,
> 
> Tamar
> 
> 
> 
> 
> 
> From: Austin Seipp
> Sent: ‎Tuesday‎, ‎December‎ ‎23‎, ‎2014 ‎15‎:‎36
> To: ghc-devs@haskell.org, glasgow-haskell-us...@haskell.org
> 
> 
> 
> 
> 
> We are pleased to announce the first release candidate for GHC 7.10.1:
> 
> https://downloads.haskell.org/~ghc/7.10.1-rc1/
> 
> This includes the source tarball and bindists for 64bit/32bit Linux
> and Windows. Binary builds for other platforms will be available
> shortly. (CentOS 6.5 binaries are not available at this time like they
> were for 7.8.x). These binaries and tarballs have an accompanying
> SHA256SUMS file signed by my GPG key id (0x3B58D86F).
> 
> We plan to make the 7.10.1 release sometime in February of 2015. We
> expect another RC to occur during January of 2015.
> 
> Please test as much as possible; bugs are much cheaper if we find them
> before the release!
>___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: ANNOUNCE: GHC 7.10.1 Release Candidate 1

[Edward Z. Yang]

Hello lonetiger,

I don't think any relevant logic changed in 7.10; however, this
commit may be relevant:

commit 8fb03bfd768ea0d5c666bbe07a50cb05214bbe92
Author: Ian Lynagh   Sun Mar 18 11:42:31 2012
Committer:  Ian Lynagh   Sun Mar 18 11:42:31 2012
Original File:  compiler/typecheck/TcForeign.lhs

If we say we're treating StdCall as CCall, then actually do so

But this warning should have applied even on older versions of GHC.

Are you running x86_64 Windows?  stdcall is specific to x86_32.

Edward

Excerpts from lonetiger's message of 2014-12-24 08:24:52 -0500:
> Hi,
> 
> 
> I’ve had some issues building this (and the git HEAD), it seems that the 
> config.guess and config.sub in the libffi tarball is old, it doesn’t detect 
> the platform when building with msys2. I had to unpack the tarfile and update 
> the files, after this it correctly built.
> 
> 
> Then I proceeded to try to make a shared library and got the following 
> warning:
> 
> 
> ManualCheck.hs:18:1: Warning:
> the 'stdcall' calling convention is unsupported on this platform,
> treating as ccall
> When checking declaration:
>   foreign export stdcall "testFoo" testFooA :: CInt -> IO (FooPtr)
> 
> 
> 
> Does this mean that GHC no longer supports stdcall on windows? or could this 
> be related to issue I had building?
> 
> 
> Regards,
> 
> Tamar
> 
> 
> 
> 
> 
> From: Austin Seipp
> Sent: ‎Tuesday‎, ‎December‎ ‎23‎, ‎2014 ‎15‎:‎36
> To: ghc-devs@haskell.org, glasgow-haskell-us...@haskell.org
> 
> 
> 
> 
> 
> We are pleased to announce the first release candidate for GHC 7.10.1:
> 
> https://downloads.haskell.org/~ghc/7.10.1-rc1/
> 
> This includes the source tarball and bindists for 64bit/32bit Linux
> and Windows. Binary builds for other platforms will be available
> shortly. (CentOS 6.5 binaries are not available at this time like they
> were for 7.8.x). These binaries and tarballs have an accompanying
> SHA256SUMS file signed by my GPG key id (0x3B58D86F).
> 
> We plan to make the 7.10.1 release sometime in February of 2015. We
> expect another RC to occur during January of 2015.
> 
> Please test as much as possible; bugs are much cheaper if we find them
> before the release!
> 
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

GHC 7.10.x migration guide

[Herbert Valerio Riedel]

Hello!

I've started collecting the most common compile-errors (and their
respective fixes) I have encountered while compiling Hackage packages
with GHC 7.10 in

  https://ghc.haskell.org/trac/ghc/wiki/Migration/7.10

Feel free to contribute to this migration guide.

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

Re: Status and future of the LLVM backend

[Erik de Castro Lopo]

Ben Gamari wrote:

> I've written down some thoughts on the current status and future
> direction of the LLVM backend here [1]. Have a look when you get a chance.
> 
> To summarize,
> 
>   * it seems like LLVM 3.4 chokes on the code produced by my 3.5 rework
> when the `$def` symbols are marked as internal
> 
>   * ARM is broken (again) due to a bug in the GHC calling convention
> implementation; an LLVM fix is waiting to be merged
> 
>   * I have code reworking TNTC for LLVM 3.6; unfortunately LLVM 3.6
> support will likely need to wait until 7.12
> 
>   * Austin's LLVM packaging proposal seems very much like the right way
> forward
> 
>   * Anticipating this proposal, I have started collecting [2]
> optimization passes

I've recently been working on amd64-linux to armhf-linux and aarch64-linux
cross-compilers. In addition to the above:

  * LLVM 3.6 that Ben mentions above has not yet been released and is 
still a work in progress. A commit to the LLVM tree made as recently
as December 17th means LLVM head no longer compiles LLVM IR code
generated by GHC (metadata issue mentioned in #9920).

  * LLVM uses C/C++ asserts liberally and these asserts get compiled out
during optimised builds (eg for Linux distributions). The removal of
these asserts results in llvm binaries that *silently* generate
incorrect binaries (see #9920 which is Ben's second bullet point above).
For instance, I built an amd64-linux to aarch64-linux cross compiler
which generated executables that crashed immediately. When I switched
to a debug version of LLVM, LLVM's opt and llc suddenly started showing
assertion failures all over.

Erik
-- 
--
Erik de Castro Lopo
http://www.mega-nerd.com/
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs