date:20170310

What should and should not be marked has_side_effects?

2017-03-10 Thread David Feuer

Note [PrimOp can_fail and has_side_effects] in prelude/PrimOp.hs says

> A primop "has_side_effects" if it has some *write* effect, visible
> elsewhere
> 
> - writing to the world (I/O)
> - writing to a mutable data structure (writeIORef)
> - throwing a synchronous Haskell exception
>
> [...]
>
>  * NB3: *Read* effects (like reading an IORef) don't count here,
>  
>because it doesn't matter if we don't do them, or do them more than
>once.  *Sequencing* is maintained by the data dependency of the state
>token.

But this does not actually seem to match what goes on in primops.txt.pp. The 
following, among many other seemingly read-only operations, have  
has_side_effects = True:

readMutVar# (the very example cited!), readArray#, unsafeFreezeArray#, 
unsafeThawArray#, tryReadMVar#, deRefWeak#

So what's the correct story? Do we want to change the note, or change the 
reality? The reason I happen to be looking at this is that I think the current 
arrangement allows us to define unsafeInterleaveIO in a particularly simple 
fashion:

unsafeInterleaveIO = pure . unsafePerformIO

but that's only safe as long as the interleaved IO won't float out and get 
performed before it's forced by normal IO.

But the unsafeInterleaveIO story seems much less important, in the grand 
scheme of things, than making everything else run fast. If indeed it's 
otherwise safe to mark these read-only ops has_side_effects=False, then I 
imagine we probably should do that.

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

Re: New commits

2017-03-10 Thread Ben Gamari

Simon Peyton Jones via ghc-devs  writes:

> Edward, Ben, others
> I have just pushed a patch series
>
> 2209d5e6 Comments only
>
> 4eeb3273 Drop redundant import
>
> 2d3cb34a Define TcSimplify.simplifyTopImplic and use it
>
> af6ed4a6 Fix constraint simplification in rules
>
> 48d1866e Improve error messages for skolems
>
> 7e96526a Fix TcSimplify.decideQuantification for kind variables
>
> bc0f3abd Deal with JoinIds before void types
>
> 900cfdc2 Do not generate a data-con wrapper for !Int#
> Issues:
>
> * bkpcabal03 is failing... I don't see how it can possibly have 
> anything to do with me, so I've pushed anyway.  Edward, might you look?
>
> * I get these stat failures - all improvements
>
>perf/compiler/T13035.runT13035 [stat too good] (normal)
>
>perf/compiler/T12425.runT12425 [stat too good] (optasm)
>
>perf/compiler/T9675.run T9675 [stat too good] (optasm)
>
>perf/space_leaks/T4029.run  T4029 [stat too good] (ghci)
>
>perf/should_run/T10359.run  T10359 [stat too good] (normal)
>
>perf/compiler/T1969.run T1969 [stat too good] (normal)
>
> Some of them are from before (I reported this and suggested
> re-centreing the numbers), but the last two are new, I think. Hurrah!
> Ben: might you look?

Sure.



signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Windows

2017-03-10 Thread Simon Peyton Jones via ghc-devs

Windows build is working againthank you!
(To be fair, I'm still building stage2, so have not tried the testsuite yet, 
but I live in hope.)
Simon
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

New commits

2017-03-10 Thread Simon Peyton Jones via ghc-devs

Edward, Ben, others
I have just pushed a patch series

2209d5e6 Comments only

4eeb3273 Drop redundant import

2d3cb34a Define TcSimplify.simplifyTopImplic and use it

af6ed4a6 Fix constraint simplification in rules

48d1866e Improve error messages for skolems

7e96526a Fix TcSimplify.decideQuantification for kind variables

bc0f3abd Deal with JoinIds before void types

900cfdc2 Do not generate a data-con wrapper for !Int#
Issues:

* bkpcabal03 is failing... I don't see how it can possibly have 
anything to do with me, so I've pushed anyway.  Edward, might you look?

* I get these stat failures - all improvements

   perf/compiler/T13035.runT13035 [stat too good] (normal)

   perf/compiler/T12425.runT12425 [stat too good] (optasm)

   perf/compiler/T9675.run T9675 [stat too good] (optasm)

   perf/space_leaks/T4029.run  T4029 [stat too good] (ghci)

   perf/should_run/T10359.run  T10359 [stat too good] (normal)

   perf/compiler/T1969.run T1969 [stat too good] (normal)

Some of them are from before (I reported this and suggested re-centreing the 
numbers), but the last two are new, I think.  Hurrah!   Ben: might you look?
Sorry for playing a bit fast and loose, but I'm out of time, and there are 
bug-fixes in here.
Thanks
Simon
bkpcabal03

simonpj@cam-05-unx:~/5builds/HEAD-5/testsuite/tests/backpack/cabal/bkpcabal03$ 
make bkpcabal03

rm -f -r tmp.d inst dist Setup

make -s --no-print-directory clean

'/5playpen/simonpj/HEAD-5/inplace/test   spaces/ghc-pkg' init tmp.d

'/5playpen/simonpj/HEAD-5/inplace/test   spaces/ghc-stage2' -v0 --make Setup

cp bkpcabal03.cabal.in1 bkpcabal03.cabal

# typecheck asig1

(cd asig1; 
'/home/simonpj/5builds/HEAD-5/testsuite/tests/backpack/cabal/bkpcabal03/Setup' 
-v0 configure --enable-library-vanilla --disable-shared 
--with-ghc='/5playpen/simonpj/HEAD-5/inplace/test   spaces/ghc-stage2' 
--ghc-options='-dcore-lint -dcmm-lint -no-user-package-db -rtsopts  
-fno-warn-missed-specialisations -fshow-warning-groups 
-fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output' 
--package-db='/home/simonpj/5builds/HEAD-5/testsuite/tests/backpack/cabal/bkpcabal03/tmp.d'
 
--prefix='/home/simonpj/5builds/HEAD-5/testsuite/tests/backpack/cabal/bkpcabal03/inst'
 --cid "asig1" asig1)

(cd asig1; 
'/home/simonpj/5builds/HEAD-5/testsuite/tests/backpack/cabal/bkpcabal03/Setup' 
-v0 build)

(cd asig1; 
'/home/simonpj/5builds/HEAD-5/testsuite/tests/backpack/cabal/bkpcabal03/Setup' 
-v0 copy)

(cd asig1; 
'/home/simonpj/5builds/HEAD-5/testsuite/tests/backpack/cabal/bkpcabal03/Setup' 
-v0 register)

# typecheck asig2

(cd asig2; 
'/home/simonpj/5builds/HEAD-5/testsuite/tests/backpack/cabal/bkpcabal03/Setup' 
-v0 configure --enable-library-vanilla --disable-shared 
--with-ghc='/5playpen/simonpj/HEAD-5/inplace/test   spaces/ghc-stage2' 
--ghc-options='-dcore-lint -dcmm-lint -no-user-package-db -rtsopts  
-fno-warn-missed-specialisations -fshow-warning-groups 
-fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output' 
--package-db='/home/simonpj/5builds/HEAD-5/testsuite/tests/backpack/cabal/bkpcabal03/tmp.d'
 
--prefix='/home/simonpj/5builds/HEAD-5/testsuite/tests/backpack/cabal/bkpcabal03/inst'
 --cid "asig2" asig2)

(cd asig2; 
'/home/simonpj/5builds/HEAD-5/testsuite/tests/backpack/cabal/bkpcabal03/Setup' 
-v0 build)

(cd asig2; 
'/home/simonpj/5builds/HEAD-5/testsuite/tests/backpack/cabal/bkpcabal03/Setup' 
-v0 copy)

(cd asig2; 
'/home/simonpj/5builds/HEAD-5/testsuite/tests/backpack/cabal/bkpcabal03/Setup' 
-v0 register)

# typecheck top-level

'/home/simonpj/5builds/HEAD-5/testsuite/tests/backpack/cabal/bkpcabal03/Setup' 
-v0 configure --enable-library-vanilla --disable-shared 
--with-ghc='/5playpen/simonpj/HEAD-5/inplace/test   spaces/ghc-stage2' 
--ghc-options='-dcore-lint -dcmm-lint -no-user-package-db -rtsopts  
-fno-warn-missed-specialisations -fshow-warning-groups 
-fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output' 
--package-db='/home/simonpj/5builds/HEAD-5/testsuite/tests/backpack/cabal/bkpcabal03/tmp.d'
 
--prefix='/home/simonpj/5builds/HEAD-5/testsuite/tests/backpack/cabal/bkpcabal03/inst'
 --cid "toplevel" bkpcabal03

! 
'/home/simonpj/5builds/HEAD-5/testsuite/tests/backpack/cabal/bkpcabal03/Setup' 
-v0 build



: warning: [-Wmissing-home-modules]

Modules are not listed in command line: Foo



Mod.hs:4:5: error: Variable not in scope: g :: Int

# modify mixins

cp bkpcabal03.cabal.in2 bkpcabal03.cabal

# retypecheck top-level

'/home/simonpj/5builds/HEAD-5/testsuite/tests/backpack/cabal/bkpcabal03/Setup' 
-v0 configure --enable-library-vanilla --disable-shared 
--with-ghc='/5playpen/simonpj/HEAD-5/inplace/test   spaces/ghc-stage2' 
--ghc-options='-dcore-lint -dcmm-lint -no-user-package-db -rtsopts  
-fno-warn-missed-specialisations -fshow-warning-groups 
-fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output'

Re: FW: GHC on Windows 10 15019+

2017-03-10 Thread Phyx

Hi Simon,

No it doesn't ring a bell to me, though I don't generally use the insider
builds. I think 0xc142 is a compatibility error, but what is not clear
to me is if he replaced realgcc which is a stub we make or just updated
things in the mingw folder. So I can't really tell if the error is coming
from our driver or gcc itself.

I'll have to install the build in a VM to try. Also as it stands 8.2 will
ship with an updated mingw-w64 tool chain already. It will be at 6.2.0-2 vs
very latest which is 6.3.0-3.

I'll see if I can reproduce and open a ticket accordingly.

Kind regards,
Tamar

On Fri, 10 Mar 2017, 13:15 Simon Peyton Jones via ghc-devs, <
ghc-devs@haskell.org> wrote:

> Phyx and friends: does this ring a bell?  Do we have a ticket?
>
> -Original Message-
> From: Glasgow-haskell-users [mailto:
> glasgow-haskell-users-boun...@haskell.org] On Behalf Of J. Garrett Morris
> Sent: 09 March 2017 17:54
> To: GHC users 
> Subject: GHC on Windows 10 15019+
>
> Hi y'all,
>
> I've recently run into a problem using released version of GHC on Windows
> 10, builds 15019 and later.  The problem seems to be an incompatibility
> with Mingw64---builds fail calling realgcc.exe with vaguely
> incomprehensible error messages (Program failed to start with error
> 0xc142).
>
> Replacing the packaged version of Mingw64 with a more recent build (from
> Msys2, say) restores functioning, but no longer works if there are spaces
> in the path to GHC.
>
> I've observed this on three different machines, so I don't think it's just
> a configuration oddity.  Has anyone else encountered similar problems, or
> can anyone else verify?  If so, it might be worth repackaging at least the
> latest released version with a more recent Mingw64.
>
>  /g
>
> --
> Prosperum ac felix scelus virtus vocatur
>  -- Seneca
>
> The University of Edinburgh is a charitable body, registered in Scotland,
> with registration number SC005336.
>
> ___
> Glasgow-haskell-users mailing list
> glasgow-haskell-us...@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
> ___
> 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

FW: GHC on Windows 10 15019+

2017-03-10 Thread Simon Peyton Jones via ghc-devs

Phyx and friends: does this ring a bell?  Do we have a ticket?

-Original Message-
From: Glasgow-haskell-users [mailto:glasgow-haskell-users-boun...@haskell.org] 
On Behalf Of J. Garrett Morris
Sent: 09 March 2017 17:54
To: GHC users 
Subject: GHC on Windows 10 15019+

Hi y'all,

I've recently run into a problem using released version of GHC on Windows 10, 
builds 15019 and later.  The problem seems to be an incompatibility with 
Mingw64---builds fail calling realgcc.exe with vaguely incomprehensible error 
messages (Program failed to start with error 0xc142).

Replacing the packaged version of Mingw64 with a more recent build (from Msys2, 
say) restores functioning, but no longer works if there are spaces in the path 
to GHC.

I've observed this on three different machines, so I don't think it's just a 
configuration oddity.  Has anyone else encountered similar problems, or can 
anyone else verify?  If so, it might be worth repackaging at least the latest 
released version with a more recent Mingw64.

 /g

--
Prosperum ac felix scelus virtus vocatur
 -- Seneca

The University of Edinburgh is a charitable body, registered in Scotland, with 
registration number SC005336.

___
Glasgow-haskell-users mailing list
glasgow-haskell-us...@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: Windows build failing in a new way

2017-03-10 Thread Simon Peyton Jones via ghc-devs

Actually it asked me thus:

Error:

Needed msys2 tarballs are missing. You have a few options to get them,



  * run configure with the --enable-tarballs-autodownload option

So I did as requested and ran configure with that flag.  Success:

checking for path to top of build tree... C:/code/HEAD

configure: Checking for Windows toolchain tarballs...

 100.0%

configure: Extracting Windows toolchain from archives (may take a while)...

configure: In-tree MingW-w64 tree created

configure: Making in-tree perl tree

configure: In-tree perl tree created

checking whether the C compiler works... yes

checking for C compiler default output file name... a.exe

Then I validated from scratch

sh validate --fast

and got the error I reported.

I suppose I could delete ghc-tarballs and try again.  I’ll do that when I’m 
next connected.

In case it  helps, the lines in unix64.S that are being rejected are

  .type  ffi_call_unix64,@function

…

  .sizeffi_call_unix64,.-ffi_call_unix64

..

  .type ffi_closure_unix64,@function

…

  .size ffi_closure_unix64,.-ffi_closure_unix64

…

  .section  .eh_frame,"a",@progbits

Simon

From: Phyx [mailto:loneti...@gmail.com]
Sent: 09 March 2017 16:38
To: Simon Peyton Jones ; ghc-devs@haskell.org
Subject: Re: Windows build failing in a new way


Hi Simon,

As of this morning the Windows build was working fine 
https://github.com/Mistuke/GhcWindowsBuild/commit/aa6906b2535224721d8b049cee3edcd938c3e951
 those are my nightly logs for last night at commit a02b80f

That error seems to be coming from gcc and not ghc. We did update the crt and 
maybe the scripts didn't do the right thing. Could you try nuking ghc-tarballs 
and trying again? Of course running with - -enable-tarballs-autodownloads on.

Tamar

On Thu, 9 Mar 2017, 16:28 Simon Peyton Jones via ghc-devs, 
> wrote:
My windows build is more broken than usual.  I can’t even build a GHC.
Please, could someone fix this?  I’m getting desperate.
Simon


libtool: compile:  C:/code/HEAD/inplace/mingw/bin/gcc.exe -DHAVE_CONFIG_H -I. 
-I.. -I. -I../include -Iinclude -I../src -Wall -Werror -fno-stack-protector -w 
-fexceptions -MT src/x86/ffi64.lo -MMD -MP -MF src/x86/.deps/ffi64.Tpo -c 
../src/x86/ffi64.c -o src/x86/ffi64.o

depbase=`echo src/x86/unix64.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`;\

/bin/sh ./libtool--mode=compile C:/code/HEAD/inplace/mingw/bin/gcc.exe 
-DHAVE_CONFIG_H -I. -I..  -I. -I../include -Iinclude -I../src  -I. -I../include 
-Iinclude -I../src -Wall -Werror -fno-stack-protector -w -MT src/x86/unix64.lo 
-MMD -MP -MF $depbase.Tpo -c -o src/x86/unix64.lo ../src/x86/unix64.S &&\

mv -f $depbase.Tpo $depbase.Plo

libtool: compile:  C:/code/HEAD/inplace/mingw/bin/gcc.exe -DHAVE_CONFIG_H -I. 
-I.. -I. -I../include -Iinclude -I../src -I. -I../include -Iinclude -I../src 
-Wall -Werror -fno-stack-protector -w -MT src/x86/unix64.lo -MMD -MP -MF 
src/x86/.deps/unix64.Tpo -c ../src/x86/unix64.S -o src/x86/unix64.o

../src/x86/unix64.S: Assembler messages:

../src/x86/unix64.S:45: Error: junk at end of line, first unrecognized 
character is `f'

../src/x86/unix64.S:204: Error: junk at end of line, first unrecognized 
character is `f'

../src/x86/unix64.S:208: Error: junk at end of line, first unrecognized 
character is `f'

../src/x86/unix64.S:326: Error: junk at end of line, first unrecognized 
character is `f'

../src/x86/unix64.S:334: Error: junk at end of line, first unrecognized 
character is `,'

make[5]: *** [Makefile:1335: src/x86/unix64.lo] Error 1

make[5]: Leaving directory '/c/code/HEAD/libffi/build/x86_64-pc-msys'

make[4]: *** [Makefile:1596: all-recursive] Error 1

make[4]: Leaving directory '/c/code/HEAD/libffi/build/x86_64-pc-msys'

make[3]: *** [Makefile:730: all] Error 2

make[3]: Leaving directory '/c/code/HEAD/libffi/build/x86_64-pc-msys'

make[2]: *** [Makefile:608: all-all] Error 2

rts/ghc.mk:494: 
rts/dist/build/.depend-v-l-debug-thr-thr_debug-thr_l.c_asm: No such file or 
directory

make[1]: *** [libffi/ghc.mk:115: 
libffi/stamp.ffi.static.build] Error 2

make: *** [Makefile:127: all] Error 2

/c/code/HEAD$
___
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

What should and should not be marked has_side_effects?

Re: New commits

Windows

New commits

Re: FW: GHC on Windows 10 15019+

FW: GHC on Windows 10 15019+

RE: Windows build failing in a new way

7 matches

Site Navigation

Mail list logo

Footer information