16 Sep, 2008

1 commit

  • Some architectures (like powerpc) provide status information on the exact
    type of invalid exception. This is pretty straight forward as we already
    report invalid exceptions via FP_SET_EXCEPTION.

    We add new flags (FP_EX_INVALID_*) the architecture code can define if it
    wants the exact invalid exception reported.

    We had to split out the INF/INF and 0/0 cases for divide to allow reporting
    the two invalid forms properly.

    Signed-off-by: Kumar Gala
    Acked-by: David S. Miller

    Kumar Gala
     

19 Aug, 2007

1 commit


17 Aug, 2007

1 commit

  • The underflow exception cases were wrong.

    This is one weird area of ieee1754 handling in that the underflow
    behavior changes based upon whether underflow is enabled in the trap
    enable mask of the FPU control register. As a specific case the Sparc
    V9 manual gives us the following description:

    --------------------
    If UFM = 0: Underflow occurs if a nonzero result is tiny and a
    loss of accuracy occurs. Tininess may be detected
    before or after rounding. Loss of accuracy may be
    either a denormalization loss or an inexact result.

    If UFM = 1: Underflow occurs if a nonzero result is tiny.
    Tininess may be detected before or after rounding.
    --------------------

    What this amounts to in the packing case is if we go subnormal,
    we set underflow if any of the following are true:

    1) rounding sets inexact
    2) we ended up rounding back up to normal (this is the case where
    we set the exponent to 1 and set the fraction to zero), this
    should set inexact too
    3) underflow is set in FPU control register trap-enable mask

    The initially discovered example was "DBL_MIN / 16.0" which
    incorrectly generated an underflow. It should not, unless underflow
    is set in the trap-enable mask of the FPU csr.

    Another example, "0x0.0000000000001p-1022 / 16.0", should signal both
    inexact and underflow. The cpu implementations and ieee1754
    literature is very clear about this. This is case #2 above.

    However, if underflow is set in the trap enable mask, only underflow
    should be set and reported as a trap. That is handled properly by the
    prioritization logic in

    arch/sparc{,64}/math-emu/math.c:record_exception().

    Based upon a report and test case from Jakub Jelinek.

    Signed-off-by: David S. Miller

    David S. Miller
     

17 Apr, 2005

1 commit

  • Initial git repository build. I'm not bothering with the full history,
    even though we have it. We can create a separate "historical" git
    archive of that later if we want to, and in the meantime it's about
    3.2GB when imported into git - space that would just make the early
    git days unnecessarily complicated, when we don't have a lot of good
    infrastructure for it.

    Let it rip!

    Linus Torvalds