First, Frank, thanks for the advice on using Initialize to work around my file problem - works a treat.
Now I have bumped into a difference (I have an easy workaround for me real code but I thought people might be interested).
Build and run the program below.
program mgcd_program;
var num : integer ;
begin num := -2147483648 ;
if num = 16#80000000 then writeln( 'equal' ) else writeln( 'not equal' ) end.
When I build with
Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.6/2.8.1/specs gpc version 2.1 (20020510), based on gcc-2.8.1
I get the output "equal".
When I build with
Reading specs from /ClearCase_01/mgcd/gcc-3.2.1_gpc-20021128_install.dir/lib/gcc-lib/sparc-sun- solaris2.6/3.2.1/specs Configured with: /ClearCase_01/mgcd/gcc-3.2.1/configure --prefix=/ClearCase_01/mgcd/gcc-3.2.1 _gpc-20021128_install.dir Thread model: posix gpc version 20021128, based on gcc-3.2.1
I get the output "not equal".
The C program:-
main() { int num = -2147483647 - 1 ;
if ( num == 0x80000000 ) printf( "equal\n" ) ; else printf( "not equal\n" ) ; }
always returns "equal".
Anyway, clearly there is an inconsistency between the GPC versions.
Cheers, Martin G C Davies
Martin G C Davies wrote:
Now I have bumped into a difference (I have an easy workaround for me real code but I thought people might be interested).
Build and run the program below.
program mgcd_program;
var num : integer ;
begin num := -2147483648 ;
if num = 16#80000000 thenwriteln( 'equal' ) else writeln( 'not equal' ) end.
When I build with
gpc version 2.1 (20020510), based on gcc-2.8.1
I get the output "equal".
When I build with
gpc version 20021128, based on gcc-3.2.1
I get the output "not equal".
The C program:-
main() { int num = -2147483647 - 1 ;
if ( num == 0x80000000 )printf( "equal\n" ) ; else printf( "not equal\n" ) ; }
always returns "equal".
Anyway, clearly there is an inconsistency between the GPC versions.
Indeed, but since in Pascal "not equal" is correct, I'm glad it's so. I suppose it's the result of the following bug fix:
@item 20020904: comparisons between signed and unsigned integers sometimes give wrong results (eike2.pas, fjf664.pas)
According to C semantics, I guess "equal" is correct (since it silently ignores overflows, AFAIK). (At least on 32 bit systems. If int is 64 bits, it would probably be "not equal", too.)
Frank
-----Original Message----- From: gpc-owner@gnu.de [mailto:gpc-owner@gnu.de]On Behalf Of Frank Heckenbach Sent: 02 December 2002 20:24 To: gpc@gnu.de Subject: Re: gcc-3.2.1_gpc-20021128 16#80000000
Martin G C Davies wrote:
<snip>
Anyway, clearly there is an inconsistency between the GPC versions.
Indeed, but since in Pascal "not equal" is correct, I'm glad it's so. I suppose it's the result of the following bug fix:
@item 20020904: comparisons between signed and unsigned integers sometimes give wrong results (eike2.pas, fjf664.pas)
Ok. I'm quite happy with that answer.
Also, I can confirm that
"Sparc with gcc-2.95.x: `goto' jumping out of two procedure nesting levels doesn't work (GCC bug; fixed in 3.0.1) 200111170922.KAA09125@goedel.fjf.gnu.de (fjf558[op].pas) (-> `Trap' unit)"
is indeed fixed using gcc-3.2.1_gpc-20021128.
In fact I've built a program (~250,000 lines in ~150 modules) and it has completely passed its regression tests - so congratulations to all involved and many thanks. Once this new version becomes an official release we will be very happy to adopt it.
Cheers, Martin G C Davies
Martin G C Davies wrote:
Also, I can confirm that
"Sparc with gcc-2.95.x: `goto' jumping out of two procedure nesting levels doesn't work (GCC bug; fixed in 3.0.1) 200111170922.KAA09125@goedel.fjf.gnu.de (fjf558[op].pas) (-> `Trap' unit)"
is indeed fixed using gcc-3.2.1_gpc-20021128. x
Thanks for confirming that. This was one of the main reasons for requiring gcc-2.8.1 support. (Unfortunately, a similar problem still exists on Linux/s390, even with gcc-3, but it might have a different cause ...)
In fact I've built a program (~250,000 lines in ~150 modules) and it has completely passed its regression tests
Good to hear so. :-)
Frank
Apparently, there were some problems with the mail transport last night, so not all of my mails came through (or not to all recipients), so I'm resending them. (Sorry if you get some twice; if you didn't get all of them (9 in total), you can find them in the archive at http://gnu-pascal.de/crystal/gpc/en/recent-mails.html).
Martin G C Davies wrote:
Also, I can confirm that
"Sparc with gcc-2.95.x: `goto' jumping out of two procedure nesting levels doesn't work (GCC bug; fixed in 3.0.1) 200111170922.KAA09125@goedel.fjf.gnu.de (fjf558[op].pas) (-> `Trap' unit)"
is indeed fixed using gcc-3.2.1_gpc-20021128. x
Thanks for confirming that. This was one of the main reasons for requiring gcc-2.8.1 support. (Unfortunately, a similar problem still exists on Linux/s390, even with gcc-3, but it might have a different cause ...)
In fact I've built a program (~250,000 lines in ~150 modules) and it has completely passed its regression tests
Good to hear so. :-)
Frank
On 11 Dec 2002 at 17:40, Frank Heckenbach wrote:
Martin G C Davies wrote:
[....]
In fact I've built a program (~250,000 lines in ~150 modules) and it has completely passed its regression tests
Good to hear so. :-)
I can also confirm that the Mingw version works perfectly with a my incubating class library (a rather complex (i.e., several layers of inheritance) application framework vaguely resembling Borland's OWL framework). The whole class library itself (~30k lines, inclusive of non-GPC runtime units that it uses) and a string of demo programs build and run correctly under GPC (based on either gcc-2.9x or gcc- 3.2.1), Freepascal, Delphi (3.0 to 7.0), and Virtual Pascal.
Good work! Best regards, The Chief --------- Prof. Abimbola Olowofoyeku (The African Chief) Web: http://www.bigfoot.com/~african_chief/
-
Frank Heckenbach -
Martin G C Davies -
Prof. A Olowofoyeku (The African Chief)