Here is the patch: https://phabricator.haskell.org/D5034
--
Best, Artem
On Thu, 2 Aug 2018 at 06:26 Artem Pelenitsyn wrote:
> I'd be willing to do this.
>
> --
> Best wishes,
> Artem
>
>
> On Thu, 2 Aug 2018, 04:38 Matt Peddie, wrote:
>
>> Thanks, Ben, for chiming in. I think calling out to
Oh ok. The fix sounded like it was about core. My mistake on reading your
explanation earlier ! Thanks for clarifying!
On Wed, Aug 1, 2018 at 11:45 PM Abhiroop Sarkar
wrote:
> Oh no! it was a Cmm lint error. The register width don't come into the
> picture before Cmm. The register width in
Oh no! it was a Cmm lint error. The register width don't come into the
picture before Cmm. The register width in the Cmm is decided based on
`primRepCmmType` function(which I mentioned in the previous mail) which in
turn uses `Type` and some other info, this is where the error was hiding.
It was
The next version of cabal will have some improvements that folks may
appreciate :
Namely haddock errors or failures are treated as warnings rather than fatal
errors when building packages. This has been merged into master cabal
And I’ve been happily using an earlier version of the patch which I
So the issue was core lint type error rather than a cmm lint error? Glad
you figured it out !
But you didn’t communicate what the error you got from lint was core rather
than cmm ... :(
On Wed, Aug 1, 2018 at 11:25 PM Abhiroop Sarkar
wrote:
> Never mind I found the issue and fixed it.
>
> It
I'd be willing to do this.
--
Best wishes,
Artem
On Thu, 2 Aug 2018, 04:38 Matt Peddie, wrote:
> Thanks, Ben, for chiming in. I think calling out to C for these
> functions is the way to go if it's now feasible. (Calling out to libm
> is the workaround I'm using in the application that led
Never mind I found the issue and fixed it.
It was the definition of the `Int32` type constructor:
int32PrimTyCon = pcPrimTyCon0 int32PrimTyConName IntRep
which had to be fixed to
int32PrimTyCon = pcPrimTyCon0 int32PrimTyConName Int32Rep
Thanks anyways :)
Abhiroop
On Wed, Aug 1, 2018 at
Thanks, Ben, for chiming in. I think calling out to C for these
functions is the way to go if it's now feasible. (Calling out to libm
is the workaround I'm using in the application that led me to discover
the inaccuracy.)
Matt
On Thu, Aug 2, 2018 at 11:33 AM, Ben Gamari wrote:
> Matt Peddie
Matt Peddie writes:
> Hi George,
>
> Not a stupid question. I don't have a single source at hand, but I
> think I read in a few places on the wiki that calling out to the
> system math library is not an option due to the variety of system math
> libraries on the platforms GHC supports. It'd be
Hello,
I would appreciate some help in debugging a Cmm Lint error, I have been
stuck on for quite a while.
Basically I am adding support for Int32# on top of the In8#(D4475) and
Int16#(D5006) patches.
The Cmm being generated for the test programs are incorrect.
Taking a sample test like this (
I've rebased the diff and relaxed the assertion - do take a look if that
looks reasonable to you :)
https://phabricator.haskell.org/D4475
Cheers!
- Michal
On Wed, Jul 25, 2018 at 9:03 PM Michal Terepeta
wrote:
> Hi Carter,
>
> I didn't write this assertion. I only validated locally (IIRC at
Hi Ben,
That was spot on! I guess there's something wrong with the stack install of
happy - using the one installed from the system package manager worked
perfectly.
Best,
_ara
On Tue, 31 Jul 2018 at 16:56, Ben Gamari wrote:
> Ara Adkins writes:
>
> > Thanks all for the insight so far!
> >
>
Bother. Sorry, I did validate, but maybe not clean enough...
| -Original Message-
| From: ghc-commits On Behalf Of
| g...@git.haskell.org
| Sent: 01 August 2018 11:55
| To: ghc-comm...@haskell.org
| Subject: [commit: ghc] master: Revert "Don't inline functions with RULES too
|
13 matches
Mail list logo
