GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T19:11:25Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/1856Improve error message for mutally recursive modules2019-07-07T19:11:25ZguestImprove error message for mutally recursive modulesWhen I am trying to compile the following modules:
```
File: Files.hs
module Files where
import SecMonad
File: Lattice.hs
module Lattice where
File: Ref.hs
module Ref where
import SecMonad
File: Screen.hs
module Screen where...When I am trying to compile the following modules:
```
File: Files.hs
module Files where
import SecMonad
File: Lattice.hs
module Lattice where
File: Ref.hs
module Ref where
import SecMonad
File: Screen.hs
module Screen where
import SecMonad
File: Sec.hs
module Sec where
import Lattice
File: SecLib.hs (OBSERVE HERE THAT THE NAME OF THE
MODULE IS NOT THE SAME AS THE FILE)
module SecMonad where
import Lattice
import Sec
import SecMonad
import Files
import Screen
import Ref
File: SecMonad.hs
module SecMonad where
import Lattice
import Sec
```
I got the message:
```
ale@localhost ~/Sec7 $ ghci SecLib.hs -fglasgow-exts
GHCi, version 6.8.1: http://www.haskell.org/ghc/ :? for help
Loading package base ... linking ... done.
[1 of 4] Compiling Lattice ( Lattice.hs, interpreted )
[2 of 4] Compiling Sec ( Sec.hs, interpreted )
[3 of 4] Compiling SecIO ( SecIO.hs, interpreted )
Module imports form a cycle for modules:
main:Resources imports: Files Lattice
main:Files imports: SecMonad SecIO Lattice
main:SecMonad
imports: Resources Ref Screen Files SecMonad SecIO Sec Lattice
main:Ref imports: SecMonad SecIO Sec Lattice Data.IORef
main:Screen imports: SecMonad SecIO Lattice
Failed, modules loaded: SecIO, Lattice, Sec.
*SecIO>
```
I think that it would be of great help if the compiler can check if the names of the modules match the name of the files. It took me a while to discover the stupid mistake, and I believe that, when you have a large number of mobules, it might be difficult to find this bug. So, a simple check would help a lot in this situation.
That is it!6.12 branchSimon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/2191A way to programmatically cause GHC to report the cost center stack associate...2019-07-07T19:09:47ZSamuel BronsonA way to programmatically cause GHC to report the cost center stack associated with a valueI find that I often wish I could ask GHC to tell me "where did \*that\* value come from?" as I debug JHC. Since GHC obviously can track this information, it seems like it would be fairly simple to implement a way for it to report this in...I find that I often wish I could ask GHC to tell me "where did \*that\* value come from?" as I debug JHC. Since GHC obviously can track this information, it seems like it would be fairly simple to implement a way for it to report this information as instructed by a running program. Perhaps:
reportCssFor :: a -\> b -\> b
I wouldn't really have any desire to use this on thunks, since when I want to do this it is usually because I don't like the value (i.e. it isn't in the right normal form), and to know this I must already have evaluated it.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.8.2 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Profiling |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"A way to programmatically cause GHC to report the cost center stack associated with a value","status":"New","operating_system":"Unknown","component":"Profiling","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.8.2","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"FeatureRequest","description":"I find that I often wish I could ask GHC to tell me \"where did *that* value come from?\" as I debug JHC. Since GHC obviously can track this information, it seems like it would be fairly simple to implement a way for it to report this information as instructed by a running program. Perhaps:\r\n\r\nreportCssFor :: a -> b -> b\r\n\r\nI wouldn't really have any desire to use this on thunks, since when I want to do this it is usually because I don't like the value (i.e. it isn't in the right normal form), and to know this I must already have evaluated it.","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchSimon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/2197GHCi doesn't work when built with way=p2019-07-07T19:09:45ZSamuel BronsonGHCi doesn't work when built with way=pI don't really mind so much that Cabal etc. don't support building GHCi profiling libs (it would be easy enough to do by hand), but the fact that GHCi tries to load the un-profiling GHCi libs is a bit annoying... it doesn't work too well...I don't really mind so much that Cabal etc. don't support building GHCi profiling libs (it would be easy enough to do by hand), but the fact that GHCi tries to load the un-profiling GHCi libs is a bit annoying... it doesn't work too well...
```
naesten@hydrogen:~/hacking/haskell/ghc-hashedrepo% ./compiler/stage2/ghc-inplace_p --interactive
GHCi, version 6.9.20080305: http://www.haskell.org/ghc/ :? for help
ghc_p-6.9.20080305: /home/naesten/hacking/haskell/ghc-hashedrepo/libraries/ghc-prim/dist/build/HSghc-prim-0.1.o: unknown symbol `traceCcszh_fast'
Loading package ghc-prim ... linking ... ghc_p-6.9.20080305: unable to load package `ghc-prim'
```6.12 branchSimon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/2493implement proposed Qualified Operator syntax2019-07-07T19:08:20ZIsaac Dupreeimplement proposed Qualified Operator syntaxproposed for haskell', we like the idea, we should implement it.
http://hackage.haskell.org/trac/haskell-prime/wiki/QualifiedOperators
http://thread.gmane.org/gmane.comp.lang.haskell.prime/2439/focus=2449
Need to decide on a name for ...proposed for haskell', we like the idea, we should implement it.
http://hackage.haskell.org/trac/haskell-prime/wiki/QualifiedOperators
http://thread.gmane.org/gmane.comp.lang.haskell.prime/2439/focus=2449
Need to decide on a name for the LANGUAGE flag (hmm.. !SanerQualifiedOperators?), as well as implementing the modified syntax( as a toggle-able thing).
while searching the wiki to see if the ticket existed already, I found an old ticket of mine that seems mentioned an instance of the exact syntax we've proposed, #1383 :-)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.8.3 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"implement proposed Qualified Operator syntax","status":"New","operating_system":"Unknown","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.8.3","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"FeatureRequest","description":"proposed for haskell', we like the idea, we should implement it.\r\n\r\nhttp://hackage.haskell.org/trac/haskell-prime/wiki/QualifiedOperators\r\n\r\nhttp://thread.gmane.org/gmane.comp.lang.haskell.prime/2439/focus=2449\r\n\r\nNeed to decide on a name for the LANGUAGE flag (hmm.. !SanerQualifiedOperators?), as well as implementing the modified syntax( as a toggle-able thing).\r\n\r\nwhile searching the wiki to see if the ticket existed already, I found an old ticket of mine that seems mentioned an instance of the exact syntax we've proposed, #1383 :-)","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchSimon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/2500Unrecognised pragma complained about twice2019-07-07T19:08:18ZSimon Peyton JonesUnrecognised pragma complained about twice```
module Foo where
{-# FOO wibble #-}
f x = x
```
We get two complaints:
```
c:/simonpj/darcs/HEAD/ghc/stage1-inplace/ghc -c Foo.hs
Foo.hs:3:0: Unrecognised pragma
Foo.hs:3:0: Unrecognised pragma
sh-2.04$
```
<details><summary>T...```
module Foo where
{-# FOO wibble #-}
f x = x
```
We get two complaints:
```
c:/simonpj/darcs/HEAD/ghc/stage1-inplace/ghc -c Foo.hs
Foo.hs:3:0: Unrecognised pragma
Foo.hs:3:0: Unrecognised pragma
sh-2.04$
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.8.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"Unrecognised pragma complained about twice","status":"New","operating_system":"Unknown","component":"Compiler","related":[],"milestone":"6.10 branch","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.8.3","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"{{{\r\nmodule Foo where\r\n\r\n{-# FOO wibble #-}\r\nf x = x\r\n}}}\r\nWe get two complaints:\r\n{{{\r\nc:/simonpj/darcs/HEAD/ghc/stage1-inplace/ghc -c Foo.hs\r\n\r\nFoo.hs:3:0: Unrecognised pragma\r\n\r\nFoo.hs:3:0: Unrecognised pragma\r\nsh-2.04$ \r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchSimon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/2682Keep going after failed search for module in current directory2019-07-07T19:07:22ZajdKeep going after failed search for module in current directoryInside a package's source directory after the package has been installed, if I type `ghci` and then `import MODNAME`, where MODNAME is a module in the package, GHCi throws an error: `module main:MODNAME is not loaded`, even though MODNAM...Inside a package's source directory after the package has been installed, if I type `ghci` and then `import MODNAME`, where MODNAME is a module in the package, GHCi throws an error: `module main:MODNAME is not loaded`, even though MODNAME is part of the package (in its system-installed state). The desired behavior, I think, is to keep on going and realize that MODNAME is a module in an already-installed package, and then load that.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.8.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Keep going after failed search for module in current directory","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.8.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Inside a package's source directory after the package has been installed, if I type {{{ghci}}} and then {{{import MODNAME}}}, where MODNAME is a module in the package, GHCi throws an error: {{{module main:MODNAME is not loaded}}}, even though MODNAME is part of the package (in its system-installed state). The desired behavior, I think, is to keep on going and realize that MODNAME is a module in an already-installed package, and then load that.","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchSimon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/2699broken pipe errors are too noisy2019-07-07T19:07:17ZBertram Felgenhauerbroken pipe errors are too noisyThe following program
```
main = mapM_ print fibs where fibs = 0 : 1 : zipWith (+) fibs (tail fibs)
```
produces this output when piped through `head` on a shell:
```
# ./a.out | head -n 1
0
a.out: <stdout>: commitAndReleaseBuffer: re...The following program
```
main = mapM_ print fibs where fibs = 0 : 1 : zipWith (+) fibs (tail fibs)
```
produces this output when piped through `head` on a shell:
```
# ./a.out | head -n 1
0
a.out: <stdout>: commitAndReleaseBuffer: resource vanished (Broken pipe)
#
```
The final error message is annoying. It would be nice if the RTS suppressed it.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"broken pipe errors are too noisy","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The following program\r\n\r\n{{{\r\nmain = mapM_ print fibs where fibs = 0 : 1 : zipWith (+) fibs (tail fibs)\r\n}}}\r\n\r\nproduces this output when piped through {{{head}}} on a shell:\r\n\r\n{{{\r\n# ./a.out | head -n 1\r\n0\r\na.out: <stdout>: commitAndReleaseBuffer: resource vanished (Broken pipe)\r\n#\r\n}}}\r\n\r\nThe final error message is annoying. It would be nice if the RTS suppressed it.","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchSimon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/2712Parallel GC scheduling problems2019-07-07T19:07:13ZSimon MarlowParallel GC scheduling problemsThe parallel GC uses its own gang of threads separate from those used to run the program. This is causing performance loss, severe in some cases, especially when the number of GC threads and mutator threads equals the number of processor...The parallel GC uses its own gang of threads separate from those used to run the program. This is causing performance loss, severe in some cases, especially when the number of GC threads and mutator threads equals the number of processor cores. In this case, when the GC spins up, the OS has to schedule N threads onto N cores, where all cores already have other threads running. It has to correctly choose to bump the old mutator threads off to make room for the new GC threads, but at least on Linux it doesn't always succeed in doing this, and there can be a delay while the scheduler sorts things out (as much as 50ms). The measurements I've been using to test the parallel GC so far have been mostly on single-threaded programs, so this problem only emerged recently.
Really we ought to be using the mutator threads as GC threads too. Things are made slightly more complicated by the fact that some of the mutator threads might not be awake when we GC, if not all cores are busy. Perhaps we should bite the bullet and try to set affinity masks.
If this is affecting you, try turning off the parallel GC, or reducing the number of threads it uses, with e.g. `+RTS -g1`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Parallel GC scheduling problems","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"6.10.2","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"simonmar"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The parallel GC uses its own gang of threads separate from those used to run the program. This is causing performance loss, severe in some cases, especially when the number of GC threads and mutator threads equals the number of processor cores. In this case, when the GC spins up, the OS has to schedule N threads onto N cores, where all cores already have other threads running. It has to correctly choose to bump the old mutator threads off to make room for the new GC threads, but at least on Linux it doesn't always succeed in doing this, and there can be a delay while the scheduler sorts things out (as much as 50ms). The measurements I've been using to test the parallel GC so far have been mostly on single-threaded programs, so this problem only emerged recently.\r\n\r\nReally we ought to be using the mutator threads as GC threads too. Things are made slightly more complicated by the fact that some of the mutator threads might not be awake when we GC, if not all cores are busy. Perhaps we should bite the bullet and try to set affinity masks.\r\n\r\nIf this is affecting you, try turning off the parallel GC, or reducing the number of threads it uses, with e.g. `+RTS -g1`.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchSimon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/2860Redundant unblocking in POSIX generic_handler2019-07-07T19:06:31ZdshRedundant unblocking in POSIX generic_handlerGeneric handler redundantly unblocks signal at the end of generic handler.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.1...Generic handler redundantly unblocks signal at the end of generic handler.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Linux |
| Architecture | x86_64 (amd64) |
</details>
<!-- {"blocked_by":[],"summary":"Redundant unblocking in POSIX generic_handler","status":"New","operating_system":"Linux","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":["POSIX","generic_handler"],"differentials":[],"test_case":"","architecture":"x86_64 (amd64)","cc":[""],"type":"Bug","description":"Generic handler redundantly unblocks signal at the end of generic handler.","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchSimon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/2868`par` `pseq` does not work as expected2019-07-07T19:06:29Zhoangta`par` `pseq` does not work as expectedThe following Wombat program is from "A Tutorial on Parallel and Concurrent Programming in Haskell". It does not work as expected on my computer (Core(TM)2 Quad CPU). Only one core is used when I watch by "mpstat -P ALL 1 200". I compile...The following Wombat program is from "A Tutorial on Parallel and Concurrent Programming in Haskell". It does not work as expected on my computer (Core(TM)2 Quad CPU). Only one core is used when I watch by "mpstat -P ALL 1 200". I compile and run by:
```
ghc --make -threaded wombat.hs
./wombat +RTS -N4
```
and the result is:
```
par sum: 119201850
par time: 20.932636 seconds.
seq sum: 119201850
seq time: 20.926783 seconds.
```
Please check if is is a bug.
```
---- wombat.hs ----
import System.Time
import Control.Parallel
fib :: Int -> Int
fib 0 = 0
fib 1 = 1
fib n = fib (n-1) + fib (n-2)
secDiff :: ClockTime -> ClockTime -> Float
secDiff (TOD secs1 psecs1) (TOD secs2 psecs2) =
fromInteger (psecs2 - psecs1) / 1e12 + fromInteger (secs2 - secs1)
mkList :: Int -> [Int]
mkList n = [1..n-1]
relprime :: Int -> Int -> Bool
relprime x y = gcd x y == 1
euler :: Int -> Int
euler n = length (filter (relprime n) (mkList n))
sumEuler :: Int -> Int
sumEuler = sum . (map euler) . mkList
seqSumFibEuler:: Int -> Int -> Int
seqSumFibEuler a b = fib a + sumEuler b
parSumFibEuler a b = f `par` (e `pseq` (e+ f))
where
f = fib a
e = sumEuler b
r1 = seqSumFibEuler 40 7450
r2 = parSumFibEuler 40 7450
main :: IO ()
main =
do
t0 <- getClockTime
pseq r1 (return())
t1 <- getClockTime
putStrLn ("seq sum: " ++ show r1)
putStrLn ("seq time: " ++ show (secDiff t0 t1) ++ " seconds.")
t0 <- getClockTime
pseq r2 (return())
t1 <- getClockTime
putStrLn ("par sum: " ++ show r2)
putStrLn ("par time: " ++ show (secDiff t0 t1) ++ " seconds.")
```6.12 branchSimon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/2881Basic Fibonacci function using Word causes ghci to panic. - 6.10.12019-07-07T19:06:26ZAlex MasonBasic Fibonacci function using Word causes ghci to panic. - 6.10.1When inputting the function:
```
let fib :: Word -> Word; fib 0 = 1; fib 1 = 1; fib n = l + r where l = fib (n-2); r = fib (n-1)
```
GHCi produces a panic error:
```
ghc: panic! (the 'impossible' happened)
(GHC version 6.10.1 for i3...When inputting the function:
```
let fib :: Word -> Word; fib 0 = 1; fib 1 = 1; fib n = l + r where l = fib (n-2); r = fib (n-1)
```
GHCi produces a panic error:
```
ghc: panic! (the 'impossible' happened)
(GHC version 6.10.1 for i386-apple-darwin):
schemeE(AnnCase).my_discr __word 0
```
It has been confirmed on both OS X 10.5.5 and linux
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | x86 |
</details>
<!-- {"blocked_by":[],"summary":"Basif Fibonacci function using Word causes ghci to panic. - 6.10.1","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":["Word","fibonacci","panic"],"differentials":[],"test_case":"","architecture":"x86","cc":[""],"type":"Bug","description":"When inputting the function:\r\n\r\n{{{\r\nlet fib :: Word -> Word; fib 0 = 1; fib 1 = 1; fib n = l + r where l = fib (n-2); r = fib (n-1)\r\n}}}\r\n\r\nGHCi produces a panic error:\r\n\r\n{{{\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 6.10.1 for i386-apple-darwin):\r\n\tschemeE(AnnCase).my_discr __word 0\r\n}}}\r\n\r\nIt has been confirmed on both OS X 10.5.5 and linux\r\n\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchSimon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/3019sparc membar asm instruction requires mode parameter2019-07-07T19:05:51Zduncansparc membar asm instruction requires mode parameterThe new `parallel/WSDeque.c` uses `store_load_barrier()` from `includes/SMP.h`.
```
EXTERN_INLINE void
store_load_barrier(void) {
#if i386_HOST_ARCH
__asm__ __volatile__ ("lock; addl $0,0(%%esp)" : : : "memory");
#elif x86_64_HOST_A...The new `parallel/WSDeque.c` uses `store_load_barrier()` from `includes/SMP.h`.
```
EXTERN_INLINE void
store_load_barrier(void) {
#if i386_HOST_ARCH
__asm__ __volatile__ ("lock; addl $0,0(%%esp)" : : : "memory");
#elif x86_64_HOST_ARCH
__asm__ __volatile__ ("lock; addq $0,0(%%rsp)" : : : "memory");
#elif powerpc_HOST_ARCH
__asm__ __volatile__ ("msync" : : : "memory");
#elif sparc_HOST_ARCH
/* Sparc in TSO mode does not require write/write barriers. */
__asm__ __volatile__ ("membar" : : : "memory");
#elif !defined(WITHSMP)
return;
#else
#error memory barriers unimplemented on this architecture
#endif
```
In particular for sparc the bit:
```
/* Sparc in TSO mode does not require write/write barriers. */
__asm__ __volatile__ ("membar" : : : "memory");
```
This is not right. The membar assembly statement requires a parameter to specify which kind of memory barrier is required. For `store_load_barrier()` it is of course `membar #StoreLoad`.
Without this the assembler complains:
```
/usr/ccs/bin/as: "parallel/WSDeque.s", line 11: error: statement syntax
```
With `#StoreLoad` added it's fine.
Note also that the comment appears to be wrong
```
/* Sparc in TSO mode does not require write/write barriers. */
```
This is `store_load_barrier()` not `store_store_barrier()` so it is exactly and only this case that is required.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.11 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"sparc membar asm instruction requires mode parameter","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"simonmar"},"version":"6.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The new `parallel/WSDeque.c` uses `store_load_barrier()` from `includes/SMP.h`.\r\n\r\n{{{\r\nEXTERN_INLINE void\r\nstore_load_barrier(void) {\r\n#if i386_HOST_ARCH\r\n __asm__ __volatile__ (\"lock; addl $0,0(%%esp)\" : : : \"memory\");\r\n#elif x86_64_HOST_ARCH\r\n __asm__ __volatile__ (\"lock; addq $0,0(%%rsp)\" : : : \"memory\");\r\n#elif powerpc_HOST_ARCH\r\n __asm__ __volatile__ (\"msync\" : : : \"memory\");\r\n#elif sparc_HOST_ARCH\r\n /* Sparc in TSO mode does not require write/write barriers. */\r\n __asm__ __volatile__ (\"membar\" : : : \"memory\");\r\n#elif !defined(WITHSMP)\r\n return;\r\n#else\r\n#error memory barriers unimplemented on this architecture\r\n#endif\r\n}}}\r\n\r\nIn particular for sparc the bit:\r\n{{{\r\n /* Sparc in TSO mode does not require write/write barriers. */\r\n __asm__ __volatile__ (\"membar\" : : : \"memory\");\r\n}}}\r\n\r\nThis is not right. The membar assembly statement requires a parameter to specify which kind of memory barrier is required. For `store_load_barrier()` it is of course `membar #StoreLoad`.\r\n\r\nWithout this the assembler complains:\r\n{{{\r\n/usr/ccs/bin/as: \"parallel/WSDeque.s\", line 11: error: statement syntax\r\n}}}\r\n\r\nWith `#StoreLoad` added it's fine.\r\n\r\nNote also that the comment appears to be wrong\r\n{{{\r\n /* Sparc in TSO mode does not require write/write barriers. */\r\n}}}\r\nThis is `store_load_barrier()` not `store_store_barrier()` so it is exactly and only this case that is required.","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchSimon MarlowSimon Marlow