Dear All;
I have tested the Kevan Hashemi's program, on SuSE Linux 10.2 running with AMD Athlon X2 CPU.
GNU Pascal 20070904; compiled with GCC 4.1.2 [the latest snapshot], and, compiled with GCC 3.4.6, with the same option << enable languages C, C++, Pascal>> yield the correct results.
On Win XP platform, with MinGW using GCC 3.4.5, it does not.
I must add that, the testing part of NTL which belongs to the "Timings" does not give correct results on MinGW.
But, on Cygwin with GCC 3.4.4, the testing part runs in a perfect manner.
When you build and use NTL on MinGW without paying attention to the errors of its test program, there is not also any conflict at all thereafter.
With kind regards.
Kadir Yuce
--------------------------------- Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers Yahoo! Mail
On 13 Nov 2007 at 9:05, pascaltomath@yahoo.fr wrote:
Dear All;
I have tested the Kevan Hashemi's program, on SuSE Linux 10.2 running with AMD Athlon X2 CPU.
GNU Pascal 20070904; compiled with GCC 4.1.2 [the latest snapshot], and, compiled with GCC 3.4.6, with the same option << enable languages C, C++, Pascal>> yield the correct results.
On Win XP platform, with MinGW using GCC 3.4.5, it does not.
I must add that, the testing part of NTL which belongs to the "Timings" does not give correct results on MinGW.
But, on Cygwin with GCC 3.4.4, the testing part runs in a perfect manner.
When you build and use NTL on MinGW without paying attention to the errors of its test program, there is not also any conflict at all thereafter.
Perhaps you may wish to compile a similar C program with gcc ? This is to ascertain whether the problem is in the Mingw libraries. If it is, then you need to report it to the Mingw maintainers.
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/
Prof A Olowofoyeku wrote:
On 13 Nov 2007 at 9:05, pascaltomath@yahoo.fr wrote:
Dear All;
I have tested the Kevan Hashemi's program, on SuSE Linux 10.2 running with AMD Athlon X2 CPU.
GNU Pascal 20070904; compiled with GCC 4.1.2 [the latest snapshot], and, compiled with GCC 3.4.6, with the same option << enable languages C, C++, Pascal>> yield the correct results.
On Win XP platform, with MinGW using GCC 3.4.5, it does not.
I must add that, the testing part of NTL which belongs to the "Timings" does not give correct results on MinGW.
But, on Cygwin with GCC 3.4.4, the testing part runs in a perfect manner.
When you build and use NTL on MinGW without paying attention to the errors of its test program, there is not also any conflict at all thereafter.
Perhaps you may wish to compile a similar C program with gcc ? This is to ascertain whether the problem is in the Mingw libraries. If it is, then you need to report it to the Mingw maintainers.
To get GPC runtime tries to use the 'gettimeofday' function if available, otherwise the 'time' function is used. I think that the 'gettimeofday' is not available in MinGW or at least GPC can not detect it. To check if GPC detected 'gettimeofday' one could look at p/rts/rts-config.h file generated during build and check if it contains line:
#define HAVE_GETTIMEOFDAY 1
If not GPC will use 'time' function which has limited resolution: it can not return microsecond part.
One solution is to ask Mingw maintainers to provide 'gettimeofday'. Alternatively, we can look for appropriate native Windows function...
Waldek Hebisch a écrit:
Prof A Olowofoyeku wrote:
To get GPC runtime tries to use the 'gettimeofday' function if available, otherwise the 'time' function is used. I think that the 'gettimeofday' is not available in MinGW or at least GPC can not detect it. To check if GPC detected 'gettimeofday' one could look at p/rts/rts-config.h file generated during build and check if it contains line:
#define HAVE_GETTIMEOFDAY 1
If not GPC will use 'time' function which has limited resolution: it can not return microsecond part.
One solution is to ask Mingw maintainers to provide 'gettimeofday'. Alternatively, we can look for appropriate native Windows function...
HAVE_GETTIMEOFDAY 1 is defined in p/rts/rts-config.h and the function gettimeofday() is declared in <sys/time.h>
But os-hacks.h used to compile gpc with mingw contains: ----------------------------------------------------------------------- /* we undefine HAVE_GETTIMEOFDAY because of Cygwin's date/time bug */ #undef HAVE_GETTIMEOFDAY
/* new time() that uses the WinAPI to call GetLocalTime */ #undef time #define time(_timer) \ ( \ { \ time_t *timer = (_timer); \ SYSTEMTIME tmp; \ time_t tmp2 = 0; \ struct tm gnu; \ memset (&gnu, 0, sizeof (gnu)); \ GetLocalTime (&tmp); \ gnu.tm_isdst = -1; \ gnu.tm_year = tmp.wYear - 1900; \ gnu.tm_mon = tmp.wMonth - 1; \ gnu.tm_mday = tmp.wDay; \ gnu.tm_hour = tmp.wHour; \ gnu.tm_min = tmp.wMinute; \ gnu.tm_sec = tmp.wSecond; \ tmp2 = mktime (&gnu); \ if (timer) *timer = tmp2; \ tmp2; \ } \ ) ----------------------------------------------------------- this function time() apparently does not set microseconds.
Maurice
On 15 Nov 2007 at 11:13, Maurice Lombardi wrote:
[...]
HAVE_GETTIMEOFDAY 1 is defined in p/rts/rts-config.h and the function gettimeofday() is declared in <sys/time.h>
But os-hacks.h used to compile gpc with mingw contains: ----------------------------------------------------------------------- /* we undefine HAVE_GETTIMEOFDAY because of Cygwin's date/time bug */ #undef HAVE_GETTIMEOFDAY
/* new time() that uses the WinAPI to call GetLocalTime */ #undef time #define time(_timer) \ ( \ { \ time_t *timer = (_timer); \ SYSTEMTIME tmp; \ time_t tmp2 = 0; \ struct tm gnu; \ memset (&gnu, 0, sizeof (gnu)); \ GetLocalTime (&tmp); \ gnu.tm_isdst = -1; \ gnu.tm_year = tmp.wYear - 1900; \ gnu.tm_mon = tmp.wMonth - 1; \ gnu.tm_mday = tmp.wDay; \ gnu.tm_hour = tmp.wHour; \ gnu.tm_min = tmp.wMinute; \ gnu.tm_sec = tmp.wSecond; \ tmp2 = mktime (&gnu); \ if (timer) *timer = tmp2; \ tmp2; \ } \ )
this function time() apparently does not set microseconds.
I thought someone might raise this. The result is exactly the same when those bits of os-hacks.h are removed. Remember that gcc does not use os- hacks.h, and the problem has been reported to show up in a C++ test program as well.
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/