Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <hr> <p><strong>Final Edit</strong>: This is almost certainly a bug in either GCC or glibc. Simply declaring a function that calls fmod somewhere else in the code (even if that function doesn't get called) makes the problem go away.</p> <p>I suggest passing <code>-fno-builtins</code> to the compiler to work around this. Thas seems to fix it for me.</p> <hr> <p>I'm able to reproduce this in GCC 4.5.3 for cygwin. </p> <p>This only happens if the <code>i</code> variable is non-const [<strong>Edit</strong>: Probably because it's encouraging the compiler to use a temporary to store the result of the initial division). My even simpler C program to test:</p> <pre><code>#include &lt;stdio.h&gt; #include &lt;math.h&gt; int main() { int i = 512; printf("%f %f\n", fmod(i/102.4,1.f), fmod(i/102.4,1.f)); printf("%f %f\n", fmod(i/102.4,1.f), fmod(i/102.4,1.f)); } </code></pre> <p>Which outputs:</p> <pre><code>0.000000 1.000000 0.000000 0.000000 </code></pre> <p>I've tried looking through the asm output, but my x87-foo is weak. <em>Can anyone else see what's wrong?</em> I'll keep looking in the meantime:</p> <pre><code> .file "test.cpp" .section .debug_abbrev,"dr" Ldebug_abbrev0: .section .debug_info,"dr" Ldebug_info0: .section .debug_line,"dr" Ldebug_line0: .text Ltext0: .def ___main; .scl 2; .type 32; .endef .section .rdata,"dr" LC3: .ascii "%f %f\12\0" .text .globl _main .def _main; .scl 2; .type 32; .endef _main: LFB7: .file 1 "test.cpp" .loc 1 6 0 pushl %ebp LCFI0: movl %esp, %ebp LCFI1: andl $-16, %esp LCFI2: subl $64, %esp LCFI3: .loc 1 6 0 call ___main LBB2: .loc 1 7 0 movl $512, 60(%esp) .loc 1 8 0 fildl 60(%esp) fldl LC0 fdivrp %st, %st(1) fld1 fld %st(1) L2: fprem fnstsw %ax sahf jp L2 fstp %st(1) fucomi %st(0), %st jp L5 fucomi %st(0), %st je L6 fstp %st(0) jmp L4 L5: fstp %st(0) L4: fld1 fstpl 8(%esp) fstpl (%esp) call _fmod jmp L3 L6: fstp %st(1) L3: fstpl 40(%esp) fildl 60(%esp) fldl LC0 fdivrp %st, %st(1) fld1 fstpl 8(%esp) fstpl (%esp) call _fmod fldl 40(%esp) fstpl 12(%esp) fstpl 4(%esp) movl $LC3, (%esp) call _printf .loc 1 9 0 fildl 60(%esp) fldl LC0 fdivrp %st, %st(1) fld1 fstpl 8(%esp) fstpl (%esp) call _fmod fstpl 32(%esp) fildl 60(%esp) fldl LC0 fdivrp %st, %st(1) fld1 fstpl 8(%esp) fstpl (%esp) call _fmod fldl 32(%esp) fstpl 12(%esp) fstpl 4(%esp) movl $LC3, (%esp) call _printf LBE2: movl $0, %eax .loc 1 10 0 leave LCFI4: ret LFE7: .section .rdata,"dr" .align 8 LC0: .long -1717986918 .long 1079613849 .section .debug_frame,"dr" Lframe0: .long LECIE0-LSCIE0 LSCIE0: .long 0xffffffff .byte 0x1 .ascii "\0" .uleb128 0x1 .sleb128 -4 .byte 0x8 .byte 0xc .uleb128 0x4 .uleb128 0x4 .byte 0x88 .uleb128 0x1 .align 4 LECIE0: LSFDE0: .long LEFDE0-LASFDE0 LASFDE0: .secrel32 Lframe0 .long LFB7 .long LFE7-LFB7 .byte 0x4 .long LCFI0-LFB7 .byte 0xe .uleb128 0x8 .byte 0x85 .uleb128 0x2 .byte 0x4 .long LCFI1-LCFI0 .byte 0xd .uleb128 0x5 .byte 0x4 .long LCFI4-LCFI1 .byte 0xc5 .byte 0xc .uleb128 0x4 .uleb128 0x4 .align 4 LEFDE0: .section .eh_frame,"w" Lframe1: .long LECIE1-LSCIE1 LSCIE1: .long 0x0 .byte 0x1 .ascii "\0" .uleb128 0x1 .sleb128 -4 .byte 0x8 .byte 0xc .uleb128 0x4 .uleb128 0x4 .byte 0x88 .uleb128 0x1 .align 4 LECIE1: LSFDE3: .long LEFDE3-LASFDE3 LASFDE3: .long LASFDE3-Lframe1 .long LFB7 .long LFE7-LFB7 .byte 0x4 .long LCFI0-LFB7 .byte 0xe .uleb128 0x8 .byte 0x85 .uleb128 0x2 .byte 0x4 .long LCFI1-LCFI0 .byte 0xd .uleb128 0x5 .byte 0x4 .long LCFI4-LCFI1 .byte 0xc5 .byte 0xc .uleb128 0x4 .uleb128 0x4 .align 4 LEFDE3: .text Letext0: .section .debug_loc,"dr" Ldebug_loc0: LLST0: .long LFB7-Ltext0 .long LCFI0-Ltext0 .word 0x2 .byte 0x74 .sleb128 4 .long LCFI0-Ltext0 .long LCFI1-Ltext0 .word 0x2 .byte 0x74 .sleb128 8 .long LCFI1-Ltext0 .long LCFI4-Ltext0 .word 0x2 .byte 0x75 .sleb128 8 .long LCFI4-Ltext0 .long LFE7-Ltext0 .word 0x2 .byte 0x74 .sleb128 4 .long 0x0 .long 0x0 .section .debug_info,"dr" .long 0x13a .word 0x2 .secrel32 Ldebug_abbrev0 .byte 0x4 .uleb128 0x1 .ascii "GNU C++ 4.5.3\0" .byte 0x4 .ascii "test.cpp\0" .ascii "/home/martin\0" .long Ltext0 .long Letext0 .secrel32 Ldebug_line0 .uleb128 0x2 .byte 0x4 .byte 0x7 .ascii "unsigned int\0" .uleb128 0x2 .byte 0x1 .byte 0x6 .ascii "char\0" .uleb128 0x2 .byte 0x1 .byte 0x6 .ascii "signed char\0" .uleb128 0x2 .byte 0x1 .byte 0x8 .ascii "unsigned char\0" .uleb128 0x2 .byte 0x2 .byte 0x5 .ascii "short int\0" .uleb128 0x2 .byte 0x2 .byte 0x7 .ascii "short unsigned int\0" .uleb128 0x2 .byte 0x4 .byte 0x5 .ascii "int\0" .uleb128 0x2 .byte 0x8 .byte 0x5 .ascii "long long int\0" .uleb128 0x2 .byte 0x8 .byte 0x7 .ascii "long long unsigned int\0" .uleb128 0x2 .byte 0x4 .byte 0x5 .ascii "long int\0" .uleb128 0x2 .byte 0x4 .byte 0x7 .ascii "long unsigned int\0" .uleb128 0x2 .byte 0x8 .byte 0x4 .ascii "double\0" .uleb128 0x2 .byte 0x4 .byte 0x4 .ascii "float\0" .uleb128 0x2 .byte 0xc .byte 0x4 .ascii "long double\0" .uleb128 0x3 .byte 0x1 .ascii "main\0" .byte 0x1 .byte 0x5 .long 0x98 .long LFB7 .long LFE7 .secrel32 LLST0 .uleb128 0x4 .long LBB2 .long LBE2 .uleb128 0x5 .ascii "i\0" .byte 0x1 .byte 0x7 .long 0x98 .byte 0x2 .byte 0x74 .sleb128 60 .byte 0x0 .byte 0x0 .byte 0x0 .section .debug_abbrev,"dr" .uleb128 0x1 .uleb128 0x11 .byte 0x1 .uleb128 0x25 .uleb128 0x8 .uleb128 0x13 .uleb128 0xb .uleb128 0x3 .uleb128 0x8 .uleb128 0x1b .uleb128 0x8 .uleb128 0x11 .uleb128 0x1 .uleb128 0x12 .uleb128 0x1 .uleb128 0x10 .uleb128 0x6 .byte 0x0 .byte 0x0 .uleb128 0x2 .uleb128 0x24 .byte 0x0 .uleb128 0xb .uleb128 0xb .uleb128 0x3e .uleb128 0xb .uleb128 0x3 .uleb128 0x8 .byte 0x0 .byte 0x0 .uleb128 0x3 .uleb128 0x2e .byte 0x1 .uleb128 0x3f .uleb128 0xc .uleb128 0x3 .uleb128 0x8 .uleb128 0x3a .uleb128 0xb .uleb128 0x3b .uleb128 0xb .uleb128 0x49 .uleb128 0x13 .uleb128 0x11 .uleb128 0x1 .uleb128 0x12 .uleb128 0x1 .uleb128 0x40 .uleb128 0x6 .byte 0x0 .byte 0x0 .uleb128 0x4 .uleb128 0xb .byte 0x1 .uleb128 0x11 .uleb128 0x1 .uleb128 0x12 .uleb128 0x1 .byte 0x0 .byte 0x0 .uleb128 0x5 .uleb128 0x34 .byte 0x0 .uleb128 0x3 .uleb128 0x8 .uleb128 0x3a .uleb128 0xb .uleb128 0x3b .uleb128 0xb .uleb128 0x49 .uleb128 0x13 .uleb128 0x2 .uleb128 0xa .byte 0x0 .byte 0x0 .byte 0x0 .section .debug_pubnames,"dr" .long 0x17 .word 0x2 .secrel32 Ldebug_info0 .long 0x13e .long 0x10d .ascii "main\0" .long 0x0 .section .debug_pubtypes,"dr" .long 0xe .word 0x2 .secrel32 Ldebug_info0 .long 0x13e .long 0x0 .section .debug_aranges,"dr" .long 0x1c .word 0x2 .secrel32 Ldebug_info0 .byte 0x4 .byte 0x0 .word 0x0 .word 0x0 .long Ltext0 .long Letext0-Ltext0 .long 0x0 .long 0x0 .def _fmod; .scl 2; .type 32; .endef .def _printf; .scl 2; .type 32; .endef </code></pre> <p>[<strong>Edit</strong>: Note, it's always the first call to fmod that is returning the strange result (never later one's). The fmod calls are being evaluated right-to-left.</p> <p>[<strong>Edit 2</strong>: Defining a function, <code>double my_fmod(double a, double b) { return fmod(a, b); }</code> and passing the calls through that makes the problem go away. ]</p>
    singulars
    1. This table or related slice is empty.
    1. POfmod returns inconsistent value
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USMartin
    1. USMartin
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POfmod returns inconsistent value
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. CO+1 for SSCCE and assembly output. I can reproduce this with MinGW GCC 4.6.2 (Windows 7). Looking at the assembly code, it seems like GCC tries to replace the first `fmod` with some `fprem` magic and only falls back to `fmod` if `fucomi %st(0), %st` says `st0 != st0` (*?!?*). That means the first result is computed using only FPU (80-bit precision), whereas all further calls to `fmod` get thrown around the stack, where they get reduced to 64-bit precision (in this case the result of `i/102.4` is stored in `st0` as `4.99999999999999972244(0)e+0`, but `fstpl (%esp)` turns it into a `qword 5.0`).
      singulars
      1. PO
      1. USDCoder
    2. CONice work, DCoder.
      singulars
      1. PO
      1. USMartin
    3. COAppears to be fixed by GCC 4.7.0 (Fedora 17). Output is `0.000000 0.000000` in both cases, including at `-O3`.
      singulars
      1. PO
      1. USElectro
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload