As of 6.5.20050610 this still occurs on both the intel mac and intel
linux (Gcc 4.0.1 gcc 4.0.2 respectively). Setting -fno-inline for
gcc has no effect.
-reilly hayes
On May 9, 2006, at 1:20 AM, Simon Marlow wrote:
Often I find these are the result of gcc inlining something, or
Thanks, I'm looking into it.
-- Don
rfh:
As of 6.5.20050610 this still occurs on both the intel mac and intel
linux (Gcc 4.0.1 gcc 4.0.2 respectively). Setting -fno-inline for
gcc has no effect.
-reilly hayes
On May 9, 2006, at 1:20 AM, Simon Marlow wrote:
Often I find these
On 12 May 2006 00:47, John Meacham wrote:
On Thu, May 11, 2006 at 02:57:30PM +0100, Simon Marlow wrote:
On the other hand, keeping intermediate Doubles to 80-bit precision
is both (a) non-portable and (b) unpredictable (the programmer
doesn't know which intermediates are going to be stored in
simonmar:
On 12 May 2006 00:47, John Meacham wrote:
On Thu, May 11, 2006 at 02:57:30PM +0100, Simon Marlow wrote:
On the other hand, keeping intermediate Doubles to 80-bit precision
is both (a) non-portable and (b) unpredictable (the programmer
doesn't know which intermediates are going
Donald Bruce Stewart wrote:
simonmar:
On 12 May 2006 00:47, John Meacham wrote:
On Thu, May 11, 2006 at 02:57:30PM +0100, Simon Marlow wrote:
On the other hand, keeping intermediate Doubles to 80-bit precision
is both (a) non-portable and (b) unpredictable (the programmer
doesn't know
I'm pretty sure this is to do with calls to strlen() from Data.ByteString.
Can you check for sure that gcc is being passed -fno-builtin? (use ghc -v).
Failing that, we might have to use a private version of strlen() that
gcc doesn't try to inline.
Cheers,
Simon
Reilly Hayes wrote:
john:
On Fri, May 12, 2006 at 10:19:18AM +0100, Simon Marlow wrote:
Especially since even:
checking Haskell type for intmax_t... not supported
checking Haskell type for uintmax_t... not supported
aren't universal :)
Well, yes. Any suggestions for what to do here? Make
Hello Simon,
Wednesday, May 10, 2006, 4:12:18 PM, you wrote:
The GC is currently single-threaded, but we have an intern who started
here this week (Roshan James) who is working on a parallel
implementation of the GC.
GREAT! if you browse Intel/AMD news, you should know that they plan to
Bulat Ziganshin wrote:
moreover, afaiu, this means that ghc-compiled programs will no more
stall for several seconds doing major GC that is also very important
for any user-interactive program (especially games :) )
Unfortunately it won't completely remove the latency of a major GC,
although
Friends,
A couple of weeks ago Simon M advertised the possibility that he and I
might run a GHC Hackathon, in Portland, later this year prior to ICFP
(Sept 14-16 or thereabouts). The idea is that we'd give an extended
tutorial about GHC's glorious innards. Then we'd have some hacking time
in
Gentlemen,
ghc -v was not required, as I am building this using .hc files from
another host. Adding -fno-builtin to the CC opts did resolve the
problem. Furthermore, I believe I have confirmed that strlen is the
problem by succesfully compiling the library using -fno-builtin-
strlen
I'm continuing in my quest to produce a clean build of GHC for Mac
intel. I'm using registerised .hc files built on 386 linux.
I suspect today's problem is pretty easy to figure out for a GHC
expert, but I'm not. When I try to build utils/genapply, the link
fails because the symbols
On 5/13/06, Reilly Hayes [EMAIL PROTECTED] wrote:
Hi
I suspect today's problem is pretty easy to figure out for a GHC
expert, but I'm not. When I try to build utils/genapply, the link
fails because the symbols _GHCziList_lvl22_closure and
_GHCziList_zdwlen_info are undefined. I'll include the
Simon, how do you want to proceed with this? Just add
-fno-builtin-strlen to the .hc bootstrappping CC flags?
-- Don
rfh:
Gentlemen,
ghc -v was not required, as I am building this using .hc files from
another host. Adding -fno-builtin to the CC opts did resolve the
problem.
14 matches
Mail list logo
