I added some primops about a month ago
(4ee4ab01c1d97845aecb7707ad2f9a80933e7a49) that call __sync_fetch_and_add,
a gcc/llvm builtin. I'm a bit surprised to see this error. The GCC manual
[1] says:
Not all operations are supported by all target processors. If a
particular operation cannot be
You can rollback the commit (git revert
4ee4ab01c1d97845aecb7707ad2f9a80933e7a49)
and push that to the repo if you wish. I will try to re-add the primop
again after I figure out what's wrong.
On Wed, Jul 16, 2014 at 9:37 AM, Johan Tibell johan.tib...@gmail.com
wrote:
I added some primops about
Hi,
I guess it’s time to talk about this, especially as Richard just brought
it up again...
I felt that we were seriously lacking in our grip on performance issues.
We don’t even know whether 6.8.3 was better or worse than 6.8.3 or 7.6.4
in terms of nofib, not to speak of the effect of each
This is great. I wanted this for a long time.
Joachim, could you write a wiki page with step-by-step instructions for how
to set this up, detailed enough that e.g. one of our infrastructure
volunteers could set it up on another machine.
Haskell infrastructure people, do we have a (e.g. Hetzner)
On 07/15/2014 09:01 AM, Simon Peyton Jones wrote:
Herbert, Austin
I've just made a change to GHC that has a (trivial) knock-on effect in
Haddock, so I had to update the submodule. Here is what I did, after
consulting Austin.
Can I humbly implore you both (or someone) to write down the
I won't have time to fix this today and I will be out until Tuesday so I
suggest you run
git revert 4ee4ab01c1d97845aecb7707ad2f9a80933e7a49
and push the result to origin/master to unblock yourself (and any other GHC
devs on Windows?)
On Wed, Jul 16, 2014 at 9:56 AM, Johan Tibell
I have built ghc on windows after that was added with no issue.
I can take a look this evening and see how HEAD works for me.
The standard gcc in the tarballs is 4.6.3, which is getting long in the tooth,
there is an issue on trac to upgrade it.
-- Niklas
- Ursprungligt meddelande
Hi all,
I'm trying to use Phab for the first time this morning, and hitting a fair
number of obstacles. I'm writing up my experiences here in order to figure out
which of these are my fault, which can be fixed, and which are just things to
live with; and also to help others who may go down the
Huh. We're not generating the atomics assembly directly ourselves?
On Wednesday, July 16, 2014, Johan Tibell johan.tib...@gmail.com wrote:
I added some primops about a month ago
(4ee4ab01c1d97845aecb7707ad2f9a80933e7a49) that call __sync_fetch_and_add,
a gcc/llvm builtin. I'm a bit surprised
Hi all,
I wanted to make a comment in a Phab revision and refer to performance of a
particular commit. So, I found the Local commits section of my page
(https://phabricator.haskell.org/D73). But, those SHA's (Commit and Tree)
seem not to be related to others. The correct SHA, as I can see it,
We are on x86(-64), but not on other archs. Simon, which arch are you on?
On Wed, Jul 16, 2014 at 5:58 PM, Carter Schonwald
carter.schonw...@gmail.com wrote:
Huh. We're not generating the atomics assembly directly ourselves?
On Wednesday, July 16, 2014, Johan Tibell johan.tib...@gmail.com
I'll be out until Tuesday.
I would much appreciate if someone with a Windows setup could help me debug
this. These symbols are supposed to be defined by GCC somewhere (as GCC is
outputting these when it cannot convert __sync_fetch_and_add into assembly
instructions.)
On Wed, Jul 16, 2014 at
2014-07-16 20:57 GMT+02:00 Niklas Larsson metanik...@gmail.com:
I get the same failure when I try to build HEAD. Turns out the error occurs
on the 32-bit Windows build, and my successful build was a 64-bit build. My
64-bit build still succeeds.
Perhaps you should specify -march=i586 for the C
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/14/2014 01:16 PM, Karel Gardas wrote:
On 07/14/14 02:53 PM, Christian Maeder wrote:
Hi Karel,
usually I do not build HEAD. My attempt starting to do so failed
as follows:
git clone git://git.haskell.org/ghc.git cd ghc ./sync-all get
Hi,
Am Dienstag, den 15.07.2014, 23:34 +0200 schrieb Joachim Breitner:
Am Dienstag, den 15.07.2014, 08:38 + schrieb Simon Peyton Jones:
This is all fantastic, thank you Joachim. But how would a new GHC dev
find out this information? Could it please be documented on the wiki?
Yes, I
Speaking more as a bystander than anything else, I'd recommend that the ghc
dev team just go ahead and detab files. Yes, merging branches will be
painful, but it's a one-time pain. Better that than the ongoing pain mixed
tabs and spaces seem to be causing.
And merging doesn't even have to be that
This bug report might shed some light on this:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47460
I wonder if I've misunderstood the GCC docs at
https://gcc.gnu.org/onlinedocs/gcc-4.9.1/gcc/_005f_005fsync-Builtins.html#_005f_005fsync-Builtins.
My reading of the docs was that if the platform
Hello,
here is a bit of git theory that may be useful:
- a git repository is a graph, where each node is a *commit* (it
identifies the state of the entire repo), and the edges keep track of what
happened after what.
- a *branch* is a pointer to a specific commit, where we plan to extend
the
2014-07-16 23:56 GMT+02:00 Johan Tibell johan.tib...@gmail.com:
My reading of the docs was that if the platform doesn't support the needed
instructions then GCC will generated a call to e.g. __sync_fetch_and_add_1,
where that function *is provided by GCC* as a fallback.
I guess GCC would
Hi Austin,
Thanks!
Should have mentioned that I updated the README and streamlined
installation process for my class at BayHac.
The new README is here if you'd like to pull it in:
https://github.com/ghc-ios/ghc-ios-scripts/blob/master/README.md
(raw:
On Thu, Jul 17, 2014 at 12:23 AM, Páli Gábor János pali.ga...@gmail.com wrote:
2014-07-16 23:56 GMT+02:00 Johan Tibell johan.tib...@gmail.com:
My reading of the docs was that if the platform doesn't support the needed
instructions then GCC will generated a call to e.g. __sync_fetch_and_add_1,
I think it all works ok if the object files goes the normal way, the gnu
linker knows what to do with those symbols when it links with the gcc lib.
But for some reason (template haskell?) the ghc linker gets involved when
compiling the vector library, and it pukes on those symbols.
I hope they
2014-07-17 0:47 GMT+02:00 Niklas Larsson metanik...@gmail.com:
I hope they can just be done away with at the source, that is to make gcc
generate the assembly primitives. GHC should already be built with i686, but
does that reach ghc-prim?
This depends on GCC -- if no -march=XXX is explicitly
Hi,
1) I had some untracked files in a submodule repo. I couldn't find a way
to get `arc diff` to ignore these, as they appeared to git to be a
change in a tracked file (that is, a change to a submodule, which is
considered tracked). `git stash` offered no help, so I had to delete the
untracked
it looks like the atomics available differ in older gccs
https://gcc.gnu.org/onlinedocs/gcc-4.5.4/gcc/Atomic-Builtins.html#Atomic-Builtins
https://gcc.gnu.org/onlinedocs/gcc-4.2.4/gcc/Atomic-Builtins.html#Atomic-Builtins
On Wed, Jul 16, 2014 at 6:51 PM, Páli Gábor János pali.ga...@gmail.com
25 matches
Mail list logo
