Wed 08 Feb 2012 10:21:08 PM UTC, comment #19:
Add record:
John made the following change:
http://hg.savannah.gnu.org/hgweb/octave/rev/06f706e92771
jwe
|
Wed 08 Feb 2012 10:18:38 PM UTC, comment #18:
I add Michael's report on the maintainers list for the MSVC build report as records.
|
Tue 04 Oct 2011 05:24:52 PM UTC, comment #17:
OK, I think I finally got it right this time.
|
Tue 04 Oct 2011 03:45:03 PM UTC, comment #16:
oops2
should be _MINGW32_ not _MINGW_
|
Tue 04 Oct 2011 02:05:27 PM UTC, comment #15:
Oops, I fixed it.
|
Tue 04 Oct 2011 07:46:16 AM UTC, comment #14:
In the changeset changeset 13269:b1882a8217ab
I found
The above should be
|
Mon 03 Oct 2011 02:54:48 AM UTC, comment #13:
I have tried the John's code.
It is also effective on MinGW.
Integrated test scripts:
.../general\profile.m PASS 3/3
|
Sat 01 Oct 2011 05:36:50 AM UTC, comment #12:
it is effective on cygwin.
Tatsuro could you check the same on Mingw ?
octave:1> test profile.m
PASSES 3 out of 3 tests
|
Sat 01 Oct 2011 01:45:55 AM UTC, comment #11:
Could you try a change like this instead:
|
Fri 30 Sep 2011 09:02:34 PM UTC, comment #10:
attached a workaround patch effective for CYGWIN and MINGW
until we find a real FIXME.
No change for the other platforms.
I tried to build a simpler test case, but failed as
the bug disappear.
It must be some corner case of g++ or linker on MS.
--- a/src/profiler.cc Fri Sep 30 14:40:33 2011 -0400
+++ b/src/profiler.cc Fri Sep 30 22:48:02 2011 +0200
@@ -385,7 +385,22 @@
profile_data_accumulator::query_time (void) const
{
octave_time now;
+
+#if defined (_CYGWIN_) || defined (_MINGW32_)
+
+// FIXME force storage and avoid optimization
+// bug only on Windows platform (Cygwin and Mingw)
+ double ora = now.double_value ();
+ char buff[64];
+ snprintf(buff,sizeof(buff), "Ora %e \n", ora);
+ return ora ;
+
+#else
+
return now.double_value ();
+
+#endif
+
}
void
(file #24061)
|
Tue 27 Sep 2011 11:44:24 PM UTC, comment #9:
I have tried an intrusive huck but the huck suppresses the output.
As you told, we will need to do the action for this bug. But I have no idea to make a small test case.
|
Tue 27 Sep 2011 08:33:34 AM UTC, comment #8:
Hi Tatsuro,
I added the fprintf to force the not optimization of
return now.double_value ()
and to check what was happening.
Without the fprintf, the compiler makes no difference between
return now.double_value ();
and
double ora;
ora = now.double_value ();
return ora ;
so both fails.
If you have an idea for a less intrusive operation instead of the fprintf, I will appreciate.
This bug seems a gcc bug on windows platform, so we should
check the gcc bug database to see if it is already known,
or to write a small test case and open a gcc bug.
|
Tue 27 Sep 2011 07:11:41 AM UTC, comment #7:
I have attached the hack by Marco on the MinGW build.
The patch gives additional values representation like
e:\usr\Tatsu\mingwhome\octaves\hg\octave-work\scripts/general\profile.m
Ora 1.317107e+009
Ora 1.317107e+009
<snip>
but test octave did not hang up at test of general/profile.m as Marco has reported.
|
Mon 26 Sep 2011 10:29:07 AM UTC, comment #6:
It seems an optimization bug around the output value of
now.double_value.
The other crazy thing is that under gdb stepping,
the failure doesn't happen.
With the attached path, "test profile.m"
passes all the test.
Idea for an operation less intrusive than fprintf ?
--- profiler.cc_orig 2011-09-26 10:25:58.937500000 +0200
+++ profiler.cc 2011-09-26 11:49:03.921875000 +0200
@@ -385,7 +385,10 @@
profile_data_accumulator::query_time (void) const
{
octave_time now;
- return now.double_value ();
+ double ora;
+ ora = now.double_value ();
+ fprintf(stderr,"Ora %e \n", ora );
+ return ora ;
}
void
-----------------------------------
$ g++ --version
g++ (GCC) 4.5.3
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
(file #24024)
|
Tue 06 Sep 2011 08:29:07 PM UTC, comment #5:
(gdb) p t
$4 = inf
(gdb) p last_time
$5 = 1315210006.311523
|
Tue 06 Sep 2011 06:51:49 PM UTC, comment #4:
I don't see a crash with this example.
Can you look at the assert on line 389 of src/profiler.cc and split check to see which of last_time >= 0 or last_time <= t that is failing? Also, what are the values of last_time and t when the failure occurs?
|
Tue 06 Sep 2011 04:30:10 AM UTC, comment #3:
The last post
should be
|
Tue 06 Sep 2011 04:15:45 AM UTC, comment #2:
ON MinGW the same error seemed to occur.
|
Mon 05 Sep 2011 08:30:52 AM UTC, comment #1:
the t variable seems to overflow on cygwin
78 octave_time::stamp (void)
79 {
80 struct timeval tp;
81
82 gnulib::gettimeofday (&tp, 0);
83
(gdb) next
82 gnulib::gettimeofday (&tp, 0);
(gdb) next
84 ot_unix_time = tp.tv_sec;
(gdb) next
85 ot_usec = tp.tv_usec;
(gdb) p ot_unix_time
$1 = 1315210184
(gdb) p ot_usec
$2 = 0
(gdb) next
86 }
(gdb) p ot_usec
$3 = 877929
(gdb) next
profile_data_accumulator::query_time (this=0x6bbd05c0) at ../../octave/src/profiler.cc:382
382 return now.double_value ();
(gdb) next
383 }
(gdb) next
382 return now.double_value ();
(gdb) next
383 }
(gdb) next
profile_data_accumulator::add_current_time (this=0x6bbd05c0) at ../../octave/src/profiler.cc:389
389 assert (last_time >= 0.0 && last_time <= t);
(gdb) p t
$4 = inf
(gdb) p last_time
$5 = 1315210006.311523
|
Mon 05 Sep 2011 07:38:45 AM UTC, original submission:
cygwin with gcc-4.5.3
$ hg tip
changeset: 13095:32fdd834c09a
tag: tip
user: John W. Eaton <jwe@octave.org>
date: Sun Sep 04 01:43:30 2011 -0400
summary: tests for typeinfo function
runnig "make check"
scripts/general/prepad.m ............................... PASS 9/9
scripts/general/profile.m ..............................assertion "last_time >= 0.0 && last_time <= t" failed: file "../../octave/src/profiler.cc", line 389, function: void profile_data_accumulator::add_current_time()
panic: Aborted -- stopping myself...
make: *** [check] Aborted (core dumped)
|