Re: Do we have free bits in the info pointer itself?

[Florian Weimer]

* Ryan Newton:

> Our heap object header is one word -- an info table pointer
> .
>
> Well, a 64 bit info table pointer leaves *at least* 16 high bits inside the
> object header for other purposes, right?

x86_64 has signed pointers, so the uppoer 16 bits are either all zero
or all ones.  Some systems use both, but it's rare on Linux.

Other 64-bit platforms use more bits.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Is Safe Haskell intended to allow segfaults?

[Florian Weimer]

* Mikhail Glushenkov:

> Hi,
>
> On 9 August 2016 at 01:32, David Terei  wrote:
>> I imagine in Java, that I can construct an invalid pointer in foreign
>> code, and then cause segfaults without the Java code having any
>> issues. Just guessing at this, so very interested to know how it's
>> prevented if I can't.
>
> Yes, this can be done with JNI, see e.g. [1]. Additionally, by using
> sun.misc.Unsafe [2], one can cause segfaults even from pure Java.

You can also bring the JVM into an unstable state by triggering a
VirtualMachineError, basically an out-of-memory condition, a stack
overflow, or any other unrecoverable error.

You can also exhaust limited resources such as file descriptors pretty
easily.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Add a signaling Nans rts option to ghc?

[Carter Schonwald]

IEEE standard specify infinities as distinguished from NAN.  Not that the
IEEE standard always makes the best choices (semantics of min and max being
the naughtiest ). But to the extent that hardware supoorts toggling what
values trigger failure it should be reasonably toggle -able

For Intel hardware I'll presume only hardware that has sse2 and newer, and
maybe a warm-up or sibling patch would be to excise x87 float support from
the code gen in GHC

Amusingly one intended use for the large space of nan values was to encode
the nature of the computation that created the nan.  And this was intended
to be used by language implementors.  Not sure if that will be useful.

Anyways, this and the other positive response is encouraging and I'll see
about making the time to dig into this stuff.

Merry friday all!
-Carter

On Sep 16, 2016 11:40 AM, "Ben Gamari"  wrote:

Carter Schonwald  writes:

> Hello All!
> I had some interesting conversations yesterday with a few folks and the
> take away was that I might experiment with adding an off by default rts
> flag that on applicable architectures that makes all floating point
> computations that yield Nans signaling , plus mayve some HS side hooks to
> enable or disable that per green thread if it doesn't harm no fib.  Kinda
> like the way green threads track and save / restore the state of the magic
> c error tracking variable
>
Sounds reasonable to me; debugging floating point issues is certainly a
chore and this could only help. Regarding a per-thread handling I think
we'd certainly need to benchmark. Note that rts/posix/Signals.c already has
some logic to handle SIGFPE, although it has been disabled for over a
decade due to an infinite loop where the handler immediately threw
another FPE. It would be nice to have a solution to this issue; looping
is quite bad.

Do you lump infinities into the class of NaN values? I'm not sure how
much code would fail due to "legitimate" uses of infinity if so.

Cheers,

- Ben
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: -fno-warn lines in the lexer can be removed with Alex 3.1.5

[Ben Gamari]

Ömer Sinan Ağacan  writes:

> I was working on the lexer today and realized that we can now remove
> -fno-warn lines in the lexer if we're OK with requiring Alex >=3.1.5.

No objection from me; 3.1.5 was released nearly a year ago and it's easy
enough to update.

Cheers,

- Ben



signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Add a signaling Nans rts option to ghc?

[Niklas Hambüchen]

Count me in as interested, I'd appreciate a feature to notice accidental
NaNs in my code.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Add a signaling Nans rts option to ghc?

[Ben Gamari]

Carter Schonwald  writes:

> Hello All!
> I had some interesting conversations yesterday with a few folks and the
> take away was that I might experiment with adding an off by default rts
> flag that on applicable architectures that makes all floating point
> computations that yield Nans signaling , plus mayve some HS side hooks to
> enable or disable that per green thread if it doesn't harm no fib.  Kinda
> like the way green threads track and save / restore the state of the magic
> c error tracking variable
>
Sounds reasonable to me; debugging floating point issues is certainly a
chore and this could only help. Regarding a per-thread handling I think
we'd certainly need to benchmark. Note that rts/posix/Signals.c already has
some logic to handle SIGFPE, although it has been disabled for over a
decade due to an infinite loop where the handler immediately threw
another FPE. It would be nice to have a solution to this issue; looping
is quite bad.

Do you lump infinities into the class of NaN values? I'm not sure how
much code would fail due to "legitimate" uses of infinity if so.

Cheers,

- Ben


signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Add a signaling Nans rts option to ghc?

[Carter Schonwald]

Hello All!
I had some interesting conversations yesterday with a few folks and the
take away was that I might experiment with adding an off by default rts
flag that on applicable architectures that makes all floating point
computations that yield Nans signaling , plus mayve some HS side hooks to
enable or disable that per green thread if it doesn't harm no fib.  Kinda
like the way green threads track and save / restore the state of the magic
c error tracking variable

Would this be something folks would be open to adding once I hack it out?
Most modern CPUs have some built in support for this, but having better rts
integration might make things way nicer.  Plus part of the point of the
sheer diversity of Nans as per the IEEE report is to encode the nature of
the source of the nan error.  (There are other parts of IEEE that I think
should be ignored / we should change the behavior in a way that disagrees
with IEEE choices that hinder debugging and such )
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs