Gpc November 2007

gpc@gnu.de

11 participants
17 discussions

ISO 7185 test failures
by Scott Moore 23 Nov '07

23 Nov '07

{****************************************************************************** GPC standard ISO 7185 test failures The following failures were found: =============================================================================== C:\GPC\usr\test>gpc --standard-pascal -Wno-warnings -o fails fails.pas fails.pas:93: error: ISO 7185 Pascal allows only simple constants fails.pas: In main program: fails.pas:112: error: this use of packed array components is an extension of fails.pas:112: error: Borland Pascal, traditional Macintosh Pascal fails.pas:113: error: this use of packed record fields is an extension of Borland fails.pas:113: error: Pascal, traditional Macintosh Pascal =============================================================================== None of these are valid failures, or indeed even have a reasonable explaination in the standard. Also, all of these used to work fine in GPC: GNU Pascal version 2.1 (20020510), based on gcc-2.95.3-6 (mingw special) See the testing details for that compiler: http://www.moorecad.com/standardpascal/compiler.html Now, with "--standard-pascal" off: =============================================================================== C:\GPC\usr\test>gpc -Wno-warnings -o fails fails.pas C:\GPC\usr\test>fails 1 10 100 2147483647 True False =============================================================================== This appears to indicate the default fields for integer is set to 1. This is technically valid, but clearly preverts the intent of the language. The "Pascal users manual and report" shows several examples of the field for integer being clearly set to the maximum size of integer. Ie., for a maximum integer of 11 digits including the sign (for +/-2147483647) the default should be 11 digits for integer. The output of numbers in collumns under the assumption that they would correctly spaced for all integers would fail under the current GPC (see again the several examples in the "report"). I have had the discussion with another implementor, and this treatment of defaults falls under "techically valid (by the ISO 7185 standard), but would break examples of the original Pascal as formulated by Wirth", which I consider a quality issue. There is no explaination for the values of boolean. Since they are treated as the strings "true" or "false", there is no possible default field that would deliver the results shown. If the default were 5 (size of 'false') the result would be: True False For 4 (size of 'true') it would be: True Fals I tried this also with the "--standard-pascal" flag on (by commenting out the error causing statements), and got the same result. Again, this used to pass: GNU Pascal version 2.1 (20020510), based on gcc-2.95.3-6 (mingw special) Here is a -v dump on the GPC used: =============================================================================== C:\GPC\usr\test>gpc -v Reading specs from /ecos-c/gpc/usr/bin/../lib/gcc/i686-pc-cygwin/3.4.4/specs Configured with: ../configure --verbose --prefix=/usr --exec-prefix=/usr --sysco nfdir=/etc --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --inf odir=/usr/share/info --enable-languages=c,pascal --enable-nls --without-included -gettext --enable-version-specific-runtime-libs --without-x --enable-libgcj --di sable-java-awt --with-system-zlib --enable-interpreter --disable-libgcj-debug -- enable-threads=posix --enable-java-gc=boehm --disable-win32-registry --enable-sj lj-exceptions --enable-hash-synchronization --enable-libstdcxx-debug Thread model: posix gpc version 20051116, based on gcc-3.4.4 =============================================================================== ******************************************************************************} program fails(output); const scst = 'this is a string'; type cset = set of char; prec = packed record i: integer; b: boolean; c: char; r: real; stc: cset; end; var i: integer; pavs: packed array [1..10] of cset; parec: prec; begin for i := 1 to 10 do pavs[i] := [chr(i+ord('a'))]; parec.stc := ['b'..'e', 'i']; writeln(1); writeln(10); writeln(100); writeln(maxint); writeln(true); writeln(false) end.

2 4

About Timing Functions and Inline Assembly
by pascaltomath＠yahoo.fr 16 Nov '07

16 Nov '07

Dear Kevan; Of course I do not know what scientific projects you are working on, but I guess that you also, you can probably use for your goals the "Inline Assembly" for Timing. As you know very well, with the Assembly opcode, or, with the Hex code, you can easily get the the timing in nanosecond unit. I use it for profiling my codings [for testing my: -vectorization, -pipelining, -unrolling, -overlapping, -recurrence processes], and, it proves itself very useful. And please, as you are a physicist, would you like not to forget to tell us if; according to the quantum physics laws, we in fact are living truly in a bi-dimensional holographic universe. Sincerely, Kadir T. --------------------------------- Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers Yahoo! Mail

1 0

Re: About The - GetMicroSecondTime on Windows
by Prof A Olowofoyeku (The African Chief) 16 Nov '07

16 Nov '07

Hi I found this code for getttimeofday: http://www.koders.com/c/fid456B26D94CDBADE2A642C5F13B41A31102D20C5E.aspx But the result is the same. Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/

1 0

About The - GetMicroSecondTime on Windows - Post
by pascaltomath＠yahoo.fr 15 Nov '07

15 Nov '07

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

4 4

[Fwd: Re: About The Timing Codes and MinGW Tools]
by Kevan Hashemi 15 Nov '07

15 Nov '07

Dear Kadir, > I am going to write and compile some others, see the facts, and after > putting them in a strict formal manner, I will send them to the MinGW > developers and here. Thank you for doing that. I find that the same Pascal code will compile under Cigwin and run with microseconds displayed correctly. I tried the older Pascal compiler (20060215) in MinGW and obtained the same problem: microseconds is always zero. So I think you're probably right: the problem is with MinGW. Yours, Kevan -- Kevan Hashemi, Electrical Engineer Physics Department, Brandeis University http://alignment.hep.brandeis.edu/

1 0

About The Timing Codes and MinGW Tools
by pascaltomath＠yahoo.fr 14 Nov '07

14 Nov '07

Dear Professor Olowofoyeku; I have compiled some C++ codes quite similar to the timing test program of the NTL Library, and they have given too some erroneous results. I am going to write and compile some others, see the facts, and after putting them in a strict formal manner, I will send them to the MinGW developers and here. Perhaps, perhaps, there may be a missed "link command option" which must be added during the compile time. Whatever, MinGW is a true wonderful collection provided very generously to us. Really thanks a lot to its smart and laborious developers. I use it along with the GNU Tools Suite; being able to get those wonders on Windows platform, open sourced and free, what gift... Sincerely Yours, With my best regards. Kadir T. Yuce --------------------------------- Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers Yahoo! Mail

1 0

GetMicroSecondTime on Windows
by Kevan Hashemi 05 Nov '07

05 Nov '07

Dear GPC Creators, I'm using GPC 20070904 to compile the following on Windows within MinGW: program p; function GetMicroSecondTime:longint; external name '_p_GetMicroSecondTime'; var i,j:integer; x:real; begin for i:=0 to 10 do begin for j:=0 to 100000 do x:=j/2; writeln(GetMicroSecondTime); end; end. On Linux with GPC 20041218, and on MacOS with GPC 20051116, the program produced output like this: 1194023823927008 1194023823934003 1194023823940745 1194023823947257 1194023823955457 1194023823977409 1194023823984707 1194023823990997 1194023823997348 1194023824003602 1194023824023001 But with the GPC 20070904 and MinGW, I get this: 1194023823000000 1194023823000000 1194023823000000 1194023823000000 1194023823000000 1194023823000000 1194023823000000 1194023823000000 1194023823000000 1194023824000000 1194023824000000 It appears that the microsecond part of the time is not working. Yours, Kevan -- Kevan Hashemi, Electrical Engineer Physics Department, Brandeis University http://alignment.hep.brandeis.edu/

2 2

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

Gpc November 2007