FAQ

On Sun, 22 Feb 2004, Derick Rethans wrote:
On Sun, 22 Feb 2004, Andi Gutmans wrote:

Huh? What platform crashes? Can you send reproducible C code?
int main(void) {
long a = -2147483648;
long b = -1;
long c;

c = a % b;
}
Does anybody has a clue *why* this gives a floating point error btw?

regards,
Derick

Search Discussions

  • Michael Spector at Feb 22, 2004 at 9:19 pm

    On Sun, 22 Feb 2004, Derick Rethans wrote:
    On Sun, 22 Feb 2004, Derick Rethans wrote:
    On Sun, 22 Feb 2004, Andi Gutmans wrote:

    Huh? What platform crashes? Can you send reproducible C code?
    int main(void) {
    long a = -2147483648;
    long b = -1;
    long c;

    c = a % b;
    }
    Does anybody has a clue *why* this gives a floating point error btw?
    May be because modulo is defined only for positive b ?
  • Derick Rethans at Feb 22, 2004 at 9:29 pm

    On Sun, 22 Feb 2004, Michael Spector wrote:
    On Sun, 22 Feb 2004, Derick Rethans wrote:
    On Sun, 22 Feb 2004, Derick Rethans wrote:
    On Sun, 22 Feb 2004, Andi Gutmans wrote:

    Huh? What platform crashes? Can you send reproducible C code?
    int main(void) {
    long a = -2147483648;
    long b = -1;
    long c;

    c = a % b;
    }
    Does anybody has a clue *why* this gives a floating point error btw?
    May be because modulo is defined only for positive b ?
    No, it works fine for -2, only the two mentioned numbers cause a FPE.

    Derick
  • Timm Friebe at Feb 22, 2004 at 9:55 pm

    On Sun, 2004-02-22 at 21:49, Derick Rethans wrote:
    On Sun, 22 Feb 2004, Derick Rethans wrote: [...]
    Does anybody has a clue *why* this gives a floating point error btw?
    Works fine with GCC 3.2.2, GCC 2.95.4 spits out "Internal compiler error
    in `float_signal', at toplev.c:2442", which I pasted into Google and
    found http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9793.

    - Timm
  • Cm at Feb 22, 2004 at 10:01 pm

    Derick Rethans wrote:
    On Sun, 22 Feb 2004, Derick Rethans wrote:

    On Sun, 22 Feb 2004, Andi Gutmans wrote:

    Huh? What platform crashes? Can you send reproducible C code?
    int main(void) {
    long a = -2147483648;
    long b = -1;
    long c;

    c = a % b;
    }

    Does anybody has a clue *why* this gives a floating point error btw?
    It's generating an idivl, which gives you an exception if the (signed)
    result is too large (a.k.a. integer overflow).

    Did you notice your compiler warning "this decimal constant is unsigned
    only in ISO C90"? ;)

    +2147483648 is: 10000000 00000000 00000000 00000000.
    -2147483648 is too large to be represented by a signed integer (as it
    would be ~(+2147483648) + 1, which gives once again: 10000000 00000000
    00000000 00000000), so the result would be too large to be represented as
    a signed integer, too.

    Cheers,
    Michael
  • Derick Rethans at Feb 22, 2004 at 10:15 pm

    On Sun, 22 Feb 2004 cm@leetspeak.org wrote:

    It's generating an idivl, which gives you an exception if the (signed)
    result is too large (a.k.a. integer overflow).

    Did you notice your compiler warning "this decimal constant is unsigned
    only in ISO C90"? ;) Yes I did
    +2147483648 is: 10000000 00000000 00000000 00000000.
    -2147483648 is too large to be represented by a signed integer (as it
    would be ~(+2147483648) + 1,
    No, -2147483648 is the lower bound and 2147483647 is the upper bound for
    signed integers.

    -2147483648 = 10000000000000000000000000000000
    2147483647 = 01111111111111111111111111111111

    it still doesn't explain the FPE here. What does explain it is that
    -2147483648 / -1 = 2147483648 which is too large.

    Derick
  • George Schlossnagle at Feb 22, 2004 at 10:33 pm

    On Feb 22, 2004, at 5:15 PM, Derick Rethans wrote:
    On Sun, 22 Feb 2004 cm@leetspeak.org wrote:

    It's generating an idivl, which gives you an exception if the (signed)
    result is too large (a.k.a. integer overflow).

    Did you notice your compiler warning "this decimal constant is
    unsigned
    only in ISO C90"? ;) Yes I did
    +2147483648 is: 10000000 00000000 00000000 00000000.
    -2147483648 is too large to be represented by a signed integer (as it
    would be ~(+2147483648) + 1,
    No, -2147483648 is the lower bound and 2147483647 is the upper bound
    for
    signed integers.

    -2147483648 = 10000000000000000000000000000000
    2147483647 = 01111111111111111111111111111111

    it still doesn't explain the FPE here. What does explain it is that
    -2147483648 / -1 = 2147483648 which is too large.
    Doesn't the rval in modulus need to be unsigned?

    Then you are effective doing

    -2147483648 % 2147482647

    which is 2147483648.

    No?
  • Michael Walter at Feb 22, 2004 at 10:49 pm

    George Schlossnagle wrote:
    On Feb 22, 2004, at 5:15 PM, Derick Rethans wrote:
    On Sun, 22 Feb 2004 cm@leetspeak.org wrote:

    It's generating an idivl, which gives you an exception if the (signed)
    result is too large (a.k.a. integer overflow).

    Did you notice your compiler warning "this decimal constant is unsigned
    only in ISO C90"? ;)

    Yes I did
    +2147483648 is: 10000000 00000000 00000000 00000000.
    -2147483648 is too large to be represented by a signed integer (as it
    would be ~(+2147483648) + 1,

    No, -2147483648 is the lower bound and 2147483647 is the upper bound for
    signed integers.

    -2147483648 = 10000000000000000000000000000000
    2147483647 = 01111111111111111111111111111111

    it still doesn't explain the FPE here. What does explain it is that
    -2147483648 / -1 = 2147483648 which is too large.

    Doesn't the rval in modulus need to be unsigned?
    No, it's implementation-defined though if one of the operands is
    negative, IIRC.

    Cheers,
    Michael
  • Sterling Hughes at Feb 22, 2004 at 10:54 pm

    George Schlossnagle wrote:
    On Feb 22, 2004, at 5:15 PM, Derick Rethans wrote:
    On Sun, 22 Feb 2004 cm@leetspeak.org wrote:

    It's generating an idivl, which gives you an exception if the (signed)
    result is too large (a.k.a. integer overflow).

    Did you notice your compiler warning "this decimal constant is unsigned
    only in ISO C90"? ;)

    Yes I did
    +2147483648 is: 10000000 00000000 00000000 00000000.
    -2147483648 is too large to be represented by a signed integer (as it
    would be ~(+2147483648) + 1,

    No, -2147483648 is the lower bound and 2147483647 is the upper bound for
    signed integers.

    -2147483648 = 10000000000000000000000000000000
    2147483647 = 01111111111111111111111111111111

    it still doesn't explain the FPE here. What does explain it is that
    -2147483648 / -1 = 2147483648 which is too large.

    Doesn't the rval in modulus need to be unsigned?
    No, it's implementation-defined though if one of the operands is
    negative, IIRC.
    no, -22 % 7.

    They truncate towards 0.

    -sterling
  • Michael Walter at Feb 22, 2004 at 10:57 pm

    Sterling Hughes wrote:
    George Schlossnagle wrote:
    On Feb 22, 2004, at 5:15 PM, Derick Rethans wrote:

    On Sun, 22 Feb 2004 cm@leetspeak.org wrote:

    It's generating an idivl, which gives you an exception if the (signed)
    result is too large (a.k.a. integer overflow).

    Did you notice your compiler warning "this decimal constant is unsigned
    only in ISO C90"? ;)

    Yes I did

    +2147483648 is: 10000000 00000000 00000000 00000000.
    -2147483648 is too large to be represented by a signed integer (as it
    would be ~(+2147483648) + 1,

    No, -2147483648 is the lower bound and 2147483647 is the upper bound for
    signed integers.

    -2147483648 = 10000000000000000000000000000000
    2147483647 = 01111111111111111111111111111111

    it still doesn't explain the FPE here. What does explain it is that
    -2147483648 / -1 = 2147483648 which is too large.

    Doesn't the rval in modulus need to be unsigned?
    No, it's implementation-defined though if one of the operands is
    negative, IIRC.
    no, -22 % 7.
    Well, I was sort of confused by the
    Microsoft Specific
    In Microsoft C++, the result of a modulus expression is always the
    same as the sign of the first operand.
    END Microsoft Specific
    remark on MSDN.

    Cheers,
    Michael
  • Andi Gutmans at Feb 22, 2004 at 10:57 pm
    At 23:49 22/02/2004 +0100, Michael Walter wrote:
    No, -2147483648 is the lower bound and 2147483647 is the upper bound for
    signed integers.

    -2147483648 = 10000000000000000000000000000000
    2147483647 = 01111111111111111111111111111111

    it still doesn't explain the FPE here. What does explain it is that
    -2147483648 / -1 = 2147483648 which is too large.
    Doesn't the rval in modulus need to be unsigned?
    No, it's implementation-defined though if one of the operands is negative,
    IIRC.
    I checked the standard (not very thoroughly I admit) and it seems to only
    be undefined for 0.
    We can check for this special case or work around it like Derick did (i.e.
    take the abs()) but why should we?
    Can someone check this on a non-intel CPU with a 32bit int?

    Andi
  • Michael Walter at Feb 22, 2004 at 11:03 pm

    Andi Gutmans wrote:
    At 23:49 22/02/2004 +0100, Michael Walter wrote:
    No, -2147483648 is the lower bound and 2147483647 is the upper bound for
    signed integers.

    -2147483648 = 10000000000000000000000000000000
    2147483647 = 01111111111111111111111111111111

    it still doesn't explain the FPE here. What does explain it is that
    -2147483648 / -1 = 2147483648 which is too large.

    Doesn't the rval in modulus need to be unsigned?
    No, it's implementation-defined though if one of the operands is
    negative, IIRC.

    I checked the standard (not very thoroughly I admit) and it seems to
    only be undefined for 0.
    The standard also seems to say that "truncation towards zero" (or
    rather, the resulting equality) is only guaranteed if a/b is
    "representable" (which it isn't in Derrik's special case, is it?).
    Can someone check this on a non-intel CPU with a 32bit int?
    If an Athlon is non-intel enough for you, then there you have the same
    behaviour ;)

    Cheers,
    Michael
  • Edin Kadribasic at Feb 22, 2004 at 11:22 pm

    On Sunday, Feb 22, 2004, at 23:57 Europe/Copenhagen, Andi Gutmans wrote:
    Can someone check this on a non-intel CPU with a 32bit int?
    gcc 3.3 produces the same warning (this decimal constant is unsigned
    only in ISO C90) on PowerPC G4. The code produces no floating point
    exceptions though. c at the end of the execution is -2147483648.

    Edin
  • Andi Gutmans at Feb 22, 2004 at 11:24 pm

    At 00:23 23/02/2004 +0100, Edin Kadribasic wrote:
    On Sunday, Feb 22, 2004, at 23:57 Europe/Copenhagen, Andi Gutmans wrote:
    Can someone check this on a non-intel CPU with a 32bit int?
    gcc 3.3 produces the same warning (this decimal constant is unsigned only
    in ISO C90) on PowerPC G4. The code produces no floating point exceptions
    though. c at the end of the execution is -2147483648.
    G4 is 64bit right?

    Andi
  • Sterling Hughes at Feb 22, 2004 at 11:25 pm

    At 00:23 23/02/2004 +0100, Edin Kadribasic wrote:
    On Sunday, Feb 22, 2004, at 23:57 Europe/Copenhagen, Andi Gutmans wrote:
    Can someone check this on a non-intel CPU with a 32bit int?
    gcc 3.3 produces the same warning (this decimal constant is unsigned only
    in ISO C90) on PowerPC G4. The code produces no floating point exceptions
    though. c at the end of the execution is -2147483648.
    G4 is 64bit right?
    G5 is. G4 is 32 bit afaik.

    -Sterling
    Andi

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Edin Kadribasic at Feb 22, 2004 at 11:31 pm

    On Monday, Feb 23, 2004, at 00:23 Europe/Copenhagen, Sterling Hughes wrote:
    At 00:23 23/02/2004 +0100, Edin Kadribasic wrote:

    On Sunday, Feb 22, 2004, at 23:57 Europe/Copenhagen, Andi Gutmans
    wrote:
    Can someone check this on a non-intel CPU with a 32bit int?
    gcc 3.3 produces the same warning (this decimal constant is unsigned
    only
    in ISO C90) on PowerPC G4. The code produces no floating point
    exceptions
    though. c at the end of the execution is -2147483648.
    G4 is 64bit right?
    G5 is. G4 is 32 bit afaik.
    Yes, sizeof(long) is 4 if its any indication.

    Edin
  • Michael Walter at Feb 22, 2004 at 10:43 pm

    Derick Rethans wrote:
    [embarassing mistake]
    No, -2147483648 is the lower bound and 2147483647 is the upper bound for
    signed integers.
    Yes of course.
    -2147483648 = 10000000000000000000000000000000
    2147483647 = 01111111111111111111111111111111

    it still doesn't explain the FPE here. What does explain it is that
    -2147483648 / -1 = 2147483648 which is too large.
    So it *does* explain the FPE, no?

    Cheers,
    Michael

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupphp-internals @
categoriesphp
postedFeb 22, '04 at 8:49p
activeFeb 22, '04 at 11:31p
posts17
users8
websitephp.net

People

Translate

site design / logo © 2022 Grokbase