Mail #13499

Back to main page of archive

Previous mail   Next mail   Unformatted/full headers
Overview  10 days   Subject   Date   Thread   Author  

From: Frank Heckenbach
Subject: -m64 on powerpc-apple-darwin8
Date: 2 Apr 2006, 00:34:46

Adriaan van Os wrote:

> OK, I built the 64-bit and fat libgcc and then turned to the testsuite,
> expecting many failures, but there were less than I had thought. This  
> apart from problems with stabs and dwarf-2 debug info, that I ignored  
> for now (not reproducing "can't find atom for N_GSYM stabs ..." in the  
> results below). In fact, I believe that some of the testsuite is wrong  
> in a situation where Integer and Longint are both 64-bit and CInteger  
> is 32-bit, as on powerpc-apple-darwin-8 when using -m64 to create  
> 64-bit binaries.
> 
> Some of the failures (not all) are reproduced below, with my comments.  
> One possible fix of the testsuite is to replace Integer by CInteger  
> where appropriate.

Yes. Have you made a diff already?

> TEST    c_gpc.pas:
> 13c13
> < PascalProgramVariable is now 53021371269137.
> ---
>  > PascalProgramVariable is now 12345.
> failed
> 
> *** c_gpc.pas is wrong (two occurences of Integer should be CInteger)
>
> TEST    gpc_c_p.pas:
> TEST    gpcu_c_u.pas:
>
> *** gpc_c_p.pas is wrong (two occurences of Integer should be CInteger),
> *** gpc_c_u.pas is wrong (one occurence of Integer should be CInteger)

Clearly wrong in the test programs, indeed.

> TEST    chief40.pas:    ./chief40.pas: In main program:
> ./chief40.pas:8: error: constant out of range
> ./chief40.pas:11: error: arithmetical overflow
> ./chief40.pas:11: error: constant overflow in expression
> ./chief40.pas:14: error: arithmetical overflow
> ./chief40.pas:14: error: constant overflow in expression
> failed
> 
> *** compiler is right, testsuite is wrong
> 
> 
> TEST    fjf526a.pas:    ./fjf526a.pas: In main program:
> gpc1: warnings being treated as errors
> ./fjf526a.pas:8: warning: left shift count >= width of type
> failed
> 
> *** compiler is right, testsuite is wrong
> 
> 
> TEST    fjf526b.pas:    ./fjf526b.pas: In main program:
> gpc1: warnings being treated as errors
> ./fjf526b.pas:8: warning: left shift count >= width of type
> failed
> 
> *** compiler is right, testsuite is wrong
> 
>
> 
> TEST    shl.pas:        ./shl.pas: In main program:
> gpc1: warnings being treated as errors
> ./shl.pas:9: warning: left shift count >= width of type
> ./shl.pas:11: warning: right shift count >= width of type
> ./shl.pas:21: warning: left shift count >= width of type
> ./shl.pas:23: warning: right shift count >= width of type
> failed
> 
> *** compiler is right, testsuite is wrong

Yes, these tests rely on there being a type larger than `Integer',
which is currently not guaranteed. Changing to CInteger will
probably help (though not strictly guaranteed either, except perhaps
indirectly via C standards which I don't know, but rather likely for
all backends). FWIW, I still think it's problematic when there's no
larger type than `Integer', as probably quite a few real programs
implicitly rely on it, but until we have 128 bit type support, it
seems there's nothing we can do about it.

> TEST    fjf327.pas:     ./fjf327.pas: In main program:
> ./fjf327.pas:9: error: constant out of range
> failed
> 
> *** compiler is right, testsuite is wrong (I recall the discussion on  
> range checking for constants)

What does the discussion have to do with it? AFAICS, it's the same
issue as before: The test program assumes that the negative of the
maximum value of Cardinal is representable which is true if and only
if Cardinal is smaller than LongestInt. So, yes, the test program is
wrong, as before.

> TEST    chuck6.pas:
> 1c1,4
> < ./a.out: value out of range (error #300 at 28a3)
> ---
>  > -10
>  > 10
>  >          -10          10
>  >          -10          10
> failed
> 
> *** see the recent discussion on subrange expressions ?

I don't think so here. This test program is purely standard Pascal
(obviously, being written by Chuck :-) and correct AFAICS. That GPC
chooses an unsigned 64 bit (here) type for the type called
"unsigned" is GPC's decision. It could have chosen signed as well,
as it goes only up to maxint, and in fact, in ISO Pascal there's
only subranges of (signed) Integer, so all the operations are
correct.

How to fix this is another question. We could make subranges
(formally) signed if they fit into a default signed type of a size
not larger than the unsigned type otherwise chosen, but I fear this
might cause other problems. This is a tricky area (but at least we
could try it) ...

Frank

Previous mail   Next mail   Unformatted/full headers
Overview  10 days   Subject   Date   Thread   Author  

Replies

In reply to

Back to main page of archive

Note: This page contains information that does not originate from the owner of this web site, but from the authors of the mails archived. The owner of this web site is not responsible for the content of such information. Any use of that infomation requires the consent of the respective author.

Where WWW addresses (URLs) in the mails archived are marked as hyperlinks, this is only for the comfort of the reader. The content of the web pages linked to like this does not necessarily reflect the opinion of the owner of this web site or of the authors of the mails archived. The owner of this web site is not responsible for the content of such web pages. Those pages are explicitly not to be considered as part of the content of this page, but merely as references.

This page was created by Crystal 0.999 (Linux 2.4.27/i686).