[BUG] statistics.c broken with 32bit mingw-gcc-3.4.5

[Lubomir I. Ivanov]

(or a possible BUG of sorts, rather).

i'm using 32bit mingw-gcc-3.4.5, which is actually fast and is good to
check compatibility.

but there is a crash every time i do a:
- subsurface ./dives/*.xml
- log -> show early statistics
(without a debugger)

seems related to the test dives from month 12 (december)

2 different debuggers didn't crash it or report an issue apart from
showing at least some corrupt values:
http://i50.tinypic.com/33cln5h.jpg

so the disassembly suggests something else instead:

/* Average dive duration */
add_cell_to_tree(store, get_minutes(stats_interval.total_time.seconds
/ stats_interval.selection_size), 3, row);
  42b76c:	8b 55 0c             	mov    0xc(%ebp),%edx
  42b76f:	8d 45 44             	lea    0x44(%ebp),%eax
  42b772:	89 45 a4             	mov    %eax,-0x5c(%ebp)
  42b775:	89 d0                	mov    %edx,%eax
  42b777:	8b 4d a4             	mov    -0x5c(%ebp),%ecx
  42b77a:	ba 00 00 00 00       	mov    $0x0,%edx
  42b77f:	f7 31                	divl   (%ecx)
  42b781:	89 45 a4             	mov    %eax,-0x5c(%ebp)
  42b784:	8b 45 a4             	mov    -0x5c(%ebp),%eax
  42b787:	89 04 24             	mov    %eax,(%esp)
  42b78a:	e8 bc fd ff ff       	call   42b54b <_get_minutes>
  42b78f:	89 c2                	mov    %eax,%edx
  42b791:	8b 45 54             	mov    0x54(%ebp),%eax
  42b794:	89 44 24 0c          	mov    %eax,0xc(%esp)
  42b798:	c7 44 24 08 03 00 00 	movl   $0x3,0x8(%esp)
  42b79f:	00
  42b7a0:	89 54 24 04          	mov    %edx,0x4(%esp)
  42b7a4:	8b 45 b4             	mov    -0x4c(%ebp),%eax
  42b7a7:	89 04 24             	mov    %eax,(%esp)
  42b7aa:	e8 6c fd ff ff       	call   42b51b <_add_cell_to_tree>

^ extra points for spotting the division by zero caused by
"stats_interval.selection_size"

if you have a 32bit gcc 3.4.5 laying around on linux you can give this
a try and perhaps find a solution faster than me.
also understanding the y.stats is obviously a plus.

i have a bunch of (8 or so) compilers on windows and the bug isn't
reproduceable with anything but c.
so we may have a compiler bug here as well...

lubomir
--