Re: mask in waitQSem
On 24/11/2014 11:12, Yuras Shumovich wrote: On Mon, 2014-11-24 at 10:09 +, Simon Marlow wrote: On 14/11/2014 21:23, Yuras Shumovich wrote: I was reviewing some exception handling code in base library, and I found this line: https://phabricator.haskell.org/diffusion/GHC/browse/master/libraries/base/Control/Concurrent/QSem.hs;165072b334ebb2ccbef38a963ac4d126f1e08c96$74 Here mask is used, but I looks completely useless for me. waitQSem itself should be called with async exceptions masked, otherwise there is no way to prevent resource leak. Do anyone know why mask is used here? I wrote that code. It looks like mask_ is important, otherwise an async exception might leave the MVar empty, no? We can't assume that waitQSem is always called inside a mask_, so it does its own mask_. Hmm, yes, you are right. Note, that in case of failure (and without external `mask`) it is not possible to determine, whether a unit of resource was reserved or not. It makes the particular instance of `QSem` unusable anymore, and we have to create other one. Probably there are situations where it is OK though. I don't think that's true: if waitQSem fails, then the semaphore has not been acquired. This guarantee is important for bracket waitQSem signalSQem to work. I just peered at the code again and I believe this is true - have you spotted a case where it might be false? If so that's a bug. Cheers, Simon Thanks, Yuras Cheers, Simon I wonder whether an author of the code tried to do something different, so there actually can be a bug hidden here. Probably uninterruptibleMask_ should be used here? (I don't think so though.) Thanks, Yuras ___ 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: mask in waitQSem
On Tue, 2014-11-25 at 13:53 +, Simon Marlow wrote: On 24/11/2014 11:12, Yuras Shumovich wrote: On Mon, 2014-11-24 at 10:09 +, Simon Marlow wrote: On 14/11/2014 21:23, Yuras Shumovich wrote: I was reviewing some exception handling code in base library, and I found this line: https://phabricator.haskell.org/diffusion/GHC/browse/master/libraries/base/Control/Concurrent/QSem.hs;165072b334ebb2ccbef38a963ac4d126f1e08c96$74 Here mask is used, but I looks completely useless for me. waitQSem itself should be called with async exceptions masked, otherwise there is no way to prevent resource leak. Do anyone know why mask is used here? I wrote that code. It looks like mask_ is important, otherwise an async exception might leave the MVar empty, no? We can't assume that waitQSem is always called inside a mask_, so it does its own mask_. Hmm, yes, you are right. Note, that in case of failure (and without external `mask`) it is not possible to determine, whether a unit of resource was reserved or not. It makes the particular instance of `QSem` unusable anymore, and we have to create other one. Probably there are situations where it is OK though. I don't think that's true: if waitQSem fails, then the semaphore has not been acquired. This guarantee is important for bracket waitQSem signalSQem to work. I just peered at the code again and I believe this is true - have you spotted a case where it might be false? If so that's a bug. The note was about the case when waitQSem is *not* called inside mask (as you said we can't assume that). In that case it can be interrupted by async exception either before entering mask_ or after leaving it. Is it true? That makes waitQSem not very useful outside bracket. When used inside bracket, it seems to be safe. Cheers, Simon Thanks, Yuras Cheers, Simon I wonder whether an author of the code tried to do something different, so there actually can be a bug hidden here. Probably uninterruptibleMask_ should be used here? (I don't think so though.) Thanks, Yuras ___ 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: mask in waitQSem
On 25/11/2014 14:03, Yuras Shumovich wrote: On Tue, 2014-11-25 at 13:53 +, Simon Marlow wrote: On 24/11/2014 11:12, Yuras Shumovich wrote: On Mon, 2014-11-24 at 10:09 +, Simon Marlow wrote: On 14/11/2014 21:23, Yuras Shumovich wrote: I was reviewing some exception handling code in base library, and I found this line: https://phabricator.haskell.org/diffusion/GHC/browse/master/libraries/base/Control/Concurrent/QSem.hs;165072b334ebb2ccbef38a963ac4d126f1e08c96$74 Here mask is used, but I looks completely useless for me. waitQSem itself should be called with async exceptions masked, otherwise there is no way to prevent resource leak. Do anyone know why mask is used here? I wrote that code. It looks like mask_ is important, otherwise an async exception might leave the MVar empty, no? We can't assume that waitQSem is always called inside a mask_, so it does its own mask_. Hmm, yes, you are right. Note, that in case of failure (and without external `mask`) it is not possible to determine, whether a unit of resource was reserved or not. It makes the particular instance of `QSem` unusable anymore, and we have to create other one. Probably there are situations where it is OK though. I don't think that's true: if waitQSem fails, then the semaphore has not been acquired. This guarantee is important for bracket waitQSem signalSQem to work. I just peered at the code again and I believe this is true - have you spotted a case where it might be false? If so that's a bug. The note was about the case when waitQSem is *not* called inside mask (as you said we can't assume that). In that case it can be interrupted by async exception either before entering mask_ or after leaving it. Is it true? That makes waitQSem not very useful outside bracket. Well, that's the case for *any* side-effecting operation outside of mask: when an exception is raised, you have no idea whether the effect took place or not. That's why we have mask. It might still be useful outside mask, if the QSem is being used locally and it's ok to discard it along with the computation. Cheers, Simon When used inside bracket, it seems to be safe. Cheers, Simon Thanks, Yuras Cheers, Simon I wonder whether an author of the code tried to do something different, so there actually can be a bug hidden here. Probably uninterruptibleMask_ should be used here? (I don't think so though.) Thanks, Yuras ___ 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: Failing tests: literals T5681 annotations
Hi,
Am Samstag, den 22.11.2014, 11:35 +0100 schrieb Joachim Breitner:
I currently observe
Unexpected results from:
TEST=literals T5681 annotations
this has improved to just
TEST=T5681 annotations
but still this needs some investigation. Maybe a problem with parallel
test runs and temporary files cleaned out too quickly?
Details:
Compile failed (status 256) errors were:
/tmp/ghc13786_0/ghc13786_5.s: Assembler messages:
/tmp/ghc13786_0/ghc13786_5.s:26:0:
Error: can't resolve `.rodata' {.rodata section} -
`Main_zdwwork_info$def' {.text section}
/tmp/ghc13786_0/ghc13786_5.s:46:0:
Error: can't resolve `.rodata' {.rodata section} - `Main_work_info$def'
{.text section}
/tmp/ghc13786_0/ghc13786_5.s:66:0:
Error: can't resolve `.rodata' {.rodata section} - `Main_main1_info$def'
{.text section}
/tmp/ghc13786_0/ghc13786_5.s:86:0:
Error: can't resolve `.rodata' {.rodata section} - `Main_main_info$def'
{.text section}
/tmp/ghc13786_0/ghc13786_5.s:106:0:
Error: can't resolve `.rodata' {.rodata section} - `Main_main2_info$def'
{.text section}
/tmp/ghc13786_0/ghc13786_5.s:126:0:
Error: can't resolve `.rodata' {.rodata section} -
`ZCMain_main_info$def' {.text section}
*** unexpected failure for T5681(optllvm)
*** unexpected failure for annotations(normal)
Wrong exit code (expected 0 , actual 2 )
Stdout:
Stderr:
/usr/bin/ld: reopening literals.o: No such file or directory
/usr/bin/ld:literals.o: bfd_stat failed: No such file or directory
/usr/bin/ld: reopening literals.o: No such file or directory
/usr/bin/ld: BFD (GNU Binutils for Ubuntu) 2.22 internal error, aborting at
../../bfd/merge.c line 873 in _bfd_merged_section_offset
/usr/bin/ld: Please report this bug.
collect2: ld returned 1 exit status
make[3]: *** [literals] Error 1
*** unexpected failure for literals(normal)
Thanks,
Joachim
--
Joachim “nomeata” Breitner
m...@joachim-breitner.de • http://www.joachim-breitner.de/
Jabber: nome...@joachim-breitner.de • GPG-Key: 0xF0FBF51F
Debian Developer: nome...@debian.org
signature.asc
Description: This is a digitally signed message part
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Re: let app invariant failure, HALP Re: how to write a ghc primop that acts on an unevaluated argument?
i'm doing a bit of benchmarking today, and it may very well be that youre
absolutely correct about all of this in practice, at least the way things
are trending.
On Tue, Nov 25, 2014 at 1:47 AM, Carter Schonwald
carter.schonw...@gmail.com wrote:
ok attached is the log of
./inplace/bin/ghc-stage2 codetester.hs -O2 -dcore-lint -fforce-recomp
-ddump-simpl -ddump-to-file -dverbose-core2core -ddump-occur-anal
-ddump-inlinings output ^1
the relevant snippet is bellow.
It looks like the Float-Out transformation is what tripping it.
That said, reading through what the semantics are implied by
has_side_effects = True, the prefetch* family of operations ARE side
effectful with respect the fact that they DO modify the CPU cache in a way
that changes what memory locations are in various levels of CPU cache, so
despite seeming read-like, they are modifying the state of the system, just
in a way that is ONLY visible wrt the performance characteristics/runtime
of the resulting program.
specifically, Duplication, Floating out, and Specultive evaluation all
change *when* the prefetch runs and changes the CPU state, and Discard
means this mutation of the CPU cache state would not happen.
if prefetch was pure semantically (ie equiv to a - () ) , they'd just be
no op, they're exclusively a tool for performance engineering, and
accordingly when and where they appear in code matters!
i'm more than happy to write out a more detailed version of this
explanation somewhere if you like.
-Carter
*** Core Linted result of Simplifier:
*** Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = True}):
*** Core Linted result of Float out(FOS {Lam = Just 0, Consts = True,
OverSatApps = True}):
*** Core Lint errors : in result of Float out(FOS {Lam = Just 0,
Consts = True,
OverSatApps = True}) ***
no location info: Warning:
In the expression: prefetchValue2#
@ [Char]
@ RealWorld
lvl_s3Oi
(prefetchValue1#
@ Int
@ RealWorld
lvl_s3Oj
(prefetchAddr3# @ RealWorld ds1_a3zg 0
ds_a3zf))
This argument does not satisfy the let/app invariant:
prefetchValue1#
@ Int
@ RealWorld
lvl_s3Oj
On Mon, Nov 24, 2014 at 10:43 PM, Carter Schonwald
carter.schonw...@gmail.com wrote:
huh, apparently i was mixing up '-' and some other similar dash
character, time to let my rebuild of ghc go through then try gain :)
On Mon, Nov 24, 2014 at 10:37 PM, Carter Schonwald
carter.schonw...@gmail.com wrote:
when i run
./inplace/bin/ghc-stage2 codetester.hs -O2 -dcore-lint -S
-fforce-recomp -ddump-simpl -ddump-to-file –dverbose-core2core
–ddump-occur-anal –ddump-inlinings
i get
target ‘–dverbose-core2core’ is not a module name or a source file
what am I doing wrong in this CLI invocation?
On Mon, Nov 24, 2014 at 10:23 AM, Simon Peyton Jones
simo...@microsoft.com wrote:
Carter
That smells wrong to me. These flags have a very carefully defined
meaning; see
Note [PrimOp can_fail and has_side_effects]
in PrimOp.lhs
If you say it has side effects when it doesn’t, you’ll confuse your
successor reading the code in five years time.
Better to find out what is going on and why. Might you do that? What
transformation invalidates the let/app invariant? Make a small test case,
use –dverbose-core2core –ddump-occur-anal –ddump-inlinings. I would far
rather that than install a land-mine in the code.
Simon
*From:* Carter Schonwald [mailto:carter.schonw...@gmail.com]
*Sent:* 24 November 2014 00:54
*To:* Edward Kmett
*Cc:* ghc-devs@haskell.org; Simon Peyton Jones; Joachim Breitner
*Subject:* Re: let app invariant failure, HALP Re: how to write a ghc
primop that acts on an unevaluated argument?
woot, solved it, at least in a way thats OK for now.
if I mark the prefetchValue operations as has_side_effects=True, the
core lint failure goes away! I'm not sure if thats the right semantics in
the long term, but it does give me a simple way to make sure it works
safely for 7.10
pardon all the noise
-Carter
On Sun, Nov 23, 2014 at 4:26 PM, Carter Schonwald
carter.schonw...@gmail.com wrote:
ok, i'm getting a let/app invariant failure when i build my test case
with O1 or O2 but not without
http://lpaste.net/114881
any help would be appreciated on how to address that
On Sun, Nov 23, 2014 at 4:13 PM, Carter Schonwald
carter.schonw...@gmail.com wrote:
yup, i have that!
wrapFetch prefetchValue0# (error this shouldn't get evaluated)
in the test suite!
in contrast
wrapFetch prefetchValue0# $! (error this shouldn't get evaluated)
does explode
has anyone tested the llvm backend changes on OS X yet?
i'm trying to test out the llvm backend on OS X with ghc head plus llvm 3.5 and i'm seeing stuff like the following. Could someone help me undestand whats going on?! 2 http://lpaste.net/115021#line23 http://lpaste.net/115021#line34 http://lpaste.net/115021#line45 http://lpaste.net/115021#line56 http://lpaste.net/115021#line67 http://lpaste.net/115021#line78 http://lpaste.net/115021#line89 http://lpaste.net/115021#line910 http://lpaste.net/115021#line1011 http://lpaste.net/115021#line11 *** Clang (Assembler):clang -m64 -fno-stack-protector -DTABLES_NEXT_TO_CODE -I. -fno-common -U__PIC__ -D__PIC__ -Qunused-arguments -x assembler -c /var/folders/py/wgp_hj9d2rl3cx48yym_ynj0gn/T/ghc89553_0/ghc89553_7.s -o TestFetch.o /var/folders/py/wgp_hj9d2rl3cx48yym_ynj0gn/T/ghc89553_0/ghc89553_7.s:3:2: error: unknown directive .macosx_version_min 10, 0 ^ no location info: Error running clang! you need clang installed to use theLLVM backend (or GHC tried to execute clang incorrectly) ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: NOTE: The STABLE freeze is scheduled to occur TODAY.
Hi all, As an update to this schedule, since we missed some of the things we were going to ship on Friday, we've delayed the creation of the ghc-7.10 branch a bit. We're hoping to get it done by this Friday. I need to merge the Partial Type Signatures work, and I believe we need to give a once over on the DWARF stuff, which SimonM will take care of. I'll send some follow up emails to specific requests shortly. On Fri, Nov 21, 2014 at 9:57 AM, Austin Seipp aus...@well-typed.com wrote: Hi friends, Today, I'm planning on trying to cut a new `ghc-7.10` branch for the stable freeze. That means I'm going to spend a lot of time merging patches and other things with several other developers because everything is crazy and so many things wow. If you have things you want me to review, then please: - Talk to me on IRC, #ghc on Freenode (I am 'thoughtpolice') - Ping me on some medium like Skype (search for me). We can schedule a chat for a short time to figure things out. - I can also do something like G+ or whatnot. - I will of course be reading my email. Please note I would actually prefer to stay *away* from email I think, since it's a larger context switch for me, but I'll actively check it still just in case you want something and need to explain it. I'll likely be doing this most of the day, so let me know what happens. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
ANNOUNCE: GHC 7.8.4 Release Candidate 1
We are pleased to announce the first release candidate for GHC 7.8.4: https://downloads.haskell.org/~ghc/7.8.4-rc1/ This includes the source tarball and bindists for 64bit Linux. Binary builds for other platforms will be available shortly. These binaries and tarballs have an accompanying SHA256SUMS file signed by my GPG key id (0x3B58D86F). We plan to make the 7.8.4 release sometime in the next few weeks. Please test as much as possible; bugs are much cheaper if we find them before the release! -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: More flexible literate Haskell extensions (Trac #9789), summary on wiki
Did you try measuring on eg, edwardk's gl package? On Thu, Nov 20, 2014 at 12:52 PM, Merijn Verstraaten mer...@inconsistent.nl wrote: Hey, I'm not really happy with an explicit extension list passed through flags, as it seems far to manual. It doesn't strike me as a very significant problem as my current work-in-progress patch only resorts to scanning the directory listing if none of the existing extensions are found. It seems unlikely that extremely large directories are in the search path. I don't think we're expecting anyone to have thousands of files in their module directories (and even thousands would take 0 time to scan...). We already try all search paths during probing so the extra overhead from large number of search paths shouldn't be substantially more than we have now. As for the weird FS support, I really don't think it's GHC's job to support people doing ridiculous things like compiling on a filesystem that doesn't support directory listings, I mean, come on! To be honest, I consider both directories with huge numbers of files (keep in mind, we'd only scan the actual module sub-directory AND that we'd need to run into directories with tens if not hundreds of thousands files to notice any real slowdown) and weird filesystems that don't support directory listing cases of so don't do that, then. Especially since these are only problems for users using non-standard module extensions. Cheers, Merijn On 20 Nov 2014, at 2:40, Sven Panne svenpa...@gmail.com wrote: 2014-11-20 9:36 GMT+01:00 Joachim Breitner m...@joachim-breitner.de: [...] With your extensions it will have to read the directory contents. In most situations, that should be fine, but it might cause minor inconveniences with very large directories, many search paths (-i flags) and/or very weird file systems (compiling from a FUSE-mounted HTTP-Server that does not support directory listing? Would work now...) Hmmm, IMHO reading directory contents is not a good idea for a compiler, for just the reasons you mentioned. A fixed set of extensions (e.g. just md and tex) would avoid this problem, but goes against the spirit of the proposal. I think we can get the best of both worlds by adding a compiler flag, e.g. --literate-extensions=md,tex. This way the compiler still has to probe only a finite set of filenames *and* we are still flexible. ___ 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
Back-porting pattern synonym type signature syntax for GHC 7.8.4 [Re: ANNOUNCE: GHC 7.8.4 Release Candidate 1]
Hi, Now that we know what the syntax of pattern synonym type signatures is going to be for GHC 7.10, would it make sense / is it not too late to backport that same syntax to 7.8.4? To recap, 7.8 doesn't support adding type signatures to pattern synonyms, but GHCi's :i and Haddock both need to produce output which has them. There's a horrible hacked-together syntax in 7.8 which is very much *not* the syntax that will be used in 7.10. Thanks, Gergo -- .--= ULLA! =-. \ http://gergo.erdi.hu \ `---= ge...@erdi.hu =---' A tojások csirkékkel szaporodnak.___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: ghc HEAD can't validate with xcode 6 clang on OS X
Hi Carter, on OS X 10.9 if i do git clone --recursive git://git.haskell.org/ghc.git ghc-valifail cd ghc-valifail perl boot ./configure --with-gcc=clang # the with gcc bit isnt needed, but making it clearly pick up clang is the point ./validate --fast No problem on my OS X 10.9. The result of CPUS=10 sh validate today: OVERALL SUMMARY for test run started at Wed Nov 26 13:50:48 2014 JST 0:04:28 spent to go through 4235 total tests, which gave rise to 16491 test cases, of which 12593 were skipped 56 had missing libraries 3768 expected passes 67 expected failures 0 caused framework failures 0 unexpected passes 6 unexpected failures 1 unexpected stat failures Unexpected failures: cabal/cabal01cabal01 [bad exit code] (normal) cabal/cabal06cabal06 [bad stdout] (normal) llvm/should_compile T5681 [exit code non-0] (optllvm) llvm/should_compile T7571 [exit code non-0] (optllvm) llvm/should_run/subsections_via_symbols subsections_via_symbols [bad exit code] (normal) rts T5435_dyn_asm [bad stdout] (normal) Unexpected stat failures: perf/compiler T4801 [stat too good] (normal) --Kazu ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
