gmane.comp.compilers.gpc

Re: GPC for MinGW?

Prof A Olowofoyeku (The African Chief — 2013-06-19T19:15:40


Yes, I did, with gcc-4.1.x. IIRC, it was straightforward to build under 
Msys. However, I have stayed with gcc-3.4.x (Mingw special) backends. I 
am sure I had good reasons at the time, but that shouldn't prevent 
anyone else going ahead.

Best regards, The Chief
--------
Prof. Abimbola A. Olowofoyeku (The African Chief) 
web:  http://www.greatchief.plus.com/


_______________________________________________
Gpc mailing list
Gpc< at >gnu.de
https://www.g-n-u.de/mailman/listinfo/gpc

Re: GPC for MinGW?

Waldek Hebisch — 2013-06-19T16:53:24

I did not try, but you should have no extra problem due to MinGW.
My impresion was that in the past The Chief reported successful build 
of Mingw version based on GCC4.  Note:

- currently using gcc newer than 4.3.x requires serious
  developement work
- 4.3.x works only if you use '--disable-mapped-location' argument
- code for 4.2.x and 4.3.x is inly in github:

https://github.com/hebisch/gpc

Code for gcc 4.1.x is in the gpc-20070904.tar.bz2 tarball.

- There are known testsuite failures when using gcc-4.x backends.
  Since 4.x backends got less use than 3.x one can expect
  unknown problems.  Also, 4.x backends optimize much more
  agressively than 3.x.  Consequently, wrong programs which
  worked "by accident" with 3.x are likely to be broken
  by 4.x.

GPC for MinGW?

Robert Hartmann — 2013-06-18T08:24:19

Hi list,

If it is possible to integrate GPC into an actual MinGW-based GCC4 port, 
I like to get some hint.

I would like to build in Msys (Windows XP),
but if it easyer to build under Linux, well then I hope I could do it with
Knoppix-Live-DVD. 

Best regards,
Robert


_______________________________________________
Gpc mailing list
Gpc< at >gnu.de
https://www.g-n-u.de/mailman/listinfo/gpc

Re: variable type cast

Jay Michael — 2013-05-17T00:36:36

     Do you have any idea why this case is rejected?

     The compiler accepted

          type winbool = boolean attribute( size = 32 ) ;
          var i : integer ;
          var wb : winbool ;

          integer(wb) := 1024 ;
          integer(wb) := -1 ;
          integer(wb) := i ;

I thought BOOLEAN was an enumeration type.  I thought an enumeration type was a second cousin to an unsigned integer.  So I thought the only real difference in my case was that I was using 16-bit integers.

     I was prepared for the compiler to accept the code and insist on generating range checks that I don't want.  I'm just puzzled that it wouldn't even accept what looks to me to be just like examples I see posted of "variable type cast".



_______________________________________________
Gpc mailing list
Gpc< at >gnu.de
https://www.g-n-u.de/mailman/listinfo/gpc

Re: variable type cast

Adriaan van Os — 2013-05-15T07:41:04


Not really. A casting at the right of the assignment operator is called a value type cast, a 
casting at the left of the assignment operator is called a variable type cast. The rules for both 
are a bit different, e.g. a value type cast may allow a cast to a different size (e.g. to a 
different size integer), a variable type cast is more strict.

Regards,

Adriaan van Os


_______________________________________________
Gpc mailing list
Gpc< at >gnu.de
https://www.g-n-u.de/mailman/listinfo/gpc

Re: variable type cast

Adriaan van Os — 2013-05-14T08:58:59

A bug in the compiler. GPC is too picky when it comes to typecasts.

Regards,

Adriaan van Os


_______________________________________________
Gpc mailing list
Gpc< at >gnu.de
https://www.g-n-u.de/mailman/listinfo/gpc

Re: variable type cast

Tom Verhoeff — 2013-05-13T19:06:40

I would think that the reason is that to the left of the assignment
operator you need a variable or equivalent, in C jargon also known
as an lvalue (i.e. something that has a persistent memory address).

Note that a variable by itself is both an lvalue and an expression (an
rvalue, though this term is little used), but not every expression is
an lvalue (e.g. v + 1 is not an lvalue; you cannot assign anything to it).

In particular, casting is an operator that yields an rvalue, but not
an lvalue.  Casting needs to done to the right of the assignment operator.

(The previous warnings about casting still stand.)

Tom

Fwd: Re: variable type cast

Maurice Lombardi — 2013-05-13T16:38:02



-------- Message original --------
Sujet: Re: variable type cast
Date : Mon, 13 May 2013 09:11:11 +0200
De : Maurice Lombardi <Maurice.Lombardi< at >ujf-grenoble.fr>
Pour : Jay Michael <jmichael_ll< at >yahoo.com>

Le 13/05/2013 01:12, Jay Michael a écrit :

First notice tht the other way around

    I16 := INT16(W16) ;

works.

Typecasts are C style unportable "extensions" which garble the
"write once, compile everywhere" philosophy behind the strong typing
principles of Pascal.
There is certainly nothing about it in the standards, and I do not know
at which point this "lvalue error" crept in first into C, and then into
Pascal.

Maurice

Re: variable type cast

Prof A Olowofoyeku (The African Chief — 2013-05-13T15:23:45

           
int16 and word16 have different ranges, and that kind of type-casting 
will not circumvent the fact that the compiler should stop you from 
doing things like that unless you specifically instruct it to NOT do 
so.  

"i16 := Word16(w16)" should compile, as should "i16 := w16". 
Preferably, all should be avoided, because, if the value of "w16" is 
higher than the int16 range, the program may simply die with a runtime 
error (at best), or, worse, you end up with an undefined value in 
"i16", which may then lead to unpredictable behaviour in your program.  

Imagine this;
w16 := 45000;
i16 := w16;
This should compile, but the assignment will generate a run-time error. 

If you turn off range checking;
w16 := 45000;
{$R-}
i16 := w16;
{$R+}
then you will not get a runtime error, but what would the value of 
"i16" be after the assignment? Would it be what you are expecting?

Best regards, The Chief
--------
Prof. Abimbola A. Olowofoyeku (The African Chief) 
web:  http://www.greatchief.plus.co

variable type cast

Jay Michael — 2013-05-12T23:12:45

gpc version 20070904, based on gcc-3.4.5 (mingw special)
 
     Given
          type INT16  = INTEGER  attribute( size=16 ) ;
          type WORD16 = Cardinal attribute( size=16 ) ;
          var i16 : INT16 ;
          var w16 : WORD16 ;
why does
          WORD16(I16) := W16 ;
produce "error: invalid lvalue in assignment"?

 
          program jsm5( input, output ) ;
type
  INT16  = INTEGER  attribute( size=16 ) ;
  WORD16 = Cardinal attribute( size=16 ) ;
var
  i16 : INT16 ;
  w16 : WORD16 ;
begin
WORD16(I16) := W16 ; { error: invalid lvalue in assignment }
end.
_______________________________________________
Gpc mailing list
Gpc< at >gnu.de
https://www.g-n-u.de/mailman/listinfo/gpc

Re: for-loops and subrange types

Jonas Maebe — 2013-04-29T07:19:58

On 29 Apr 2013, at 09:07, Jonas Maebe wrote:


Or rather "statement of the for-statement". I thought it was just awkward standardese wording .


Jonas_______________________________________________
Gpc mailing list
Gpc< at >gnu.de
https://www.g-n-u.de/mailman/listinfo/gpc

Re: for-loops and subrange types

Jonas Maebe — 2013-04-29T07:07:23

On 27 Apr 2013, at 20:47, Waldek Hebisch wrote:

[snip]

The poster was obviously heavily invested in getting his code accepted by FPC. Given that GPC is known for its standards compliance and had the same behaviour as FPC, and given the fact that as a non-standards-expert I did not know that for-statement always solely refers to "loop body", I thought the standard was possibly in part self-contradicting or ambiguous (it wouldn't be the first such standard). That's why I asked here rather than just closing the bug report and be done with it, because I knew there are people here who know way more about the Pascal standard than I do.


Jonas
_______________________________________________
Gpc mailing list
Gpc< at >gnu.de
https://www.g-n-u.de/mailman/listinfo/gpc

Re: for-loops and subrange types

Adriaan van Os — 2013-04-29T06:24:36

I second with what Waldek Hebisch and submitter have said and argued in detail.

Regards,

Adriaan van Os


_______________________________________________
Gpc mailing list
Gpc< at >gnu.de
https://www.g-n-u.de/mailman/listinfo/gpc

Re: for-loops and subrange types

Waldek Hebisch — 2013-04-28T18:06:41

Yes, it is a gpc bug.

Re: for-loops and subrange types

Maurice Lombardi — 2013-04-28T17:38:36

Le 27/04/2013 20:47, Waldek Hebisch a écrit :

This is how gpc should work, but not how it actually works with current 
gpc version (20070904 with either 3.4.5 or 4.3.5 gcc backends).
To check a suggestion of Florian Kaempfl on the fpc bug list about 
signed/unsigned underlying type, I changed ttlow to -1 to be sure that 
the underlying "full" type is integer, not cardinal, and put ttop - 2 
for the upper limit of the loop, which is out of bounds for assignment, 
but not for the underlying integer type, giving
------------------------------------------------------------------
program range ( output );

const  ttlow = -1;   tthigh  =  800;

type   ttx = ttlow .. tthigh;

var    ttop : ttx;

procedure p ( low : ttx );
var  high : ttx;
begin
    for high := low to ttop - 2 do
       writeln( high, ' ', low, ' ', ttop, ' ', ttop - 1 );
end;

begin
    ttop := 0;
    p( 1 );
end.
--------------------------------------------------------------------
I obtain the following out of bounds message:

MinGW: C:\Lombardi

Re: for-loops and subrange types

Waldek Hebisch — 2013-04-27T18:47:03

The 'statement of the for-statement' is standarese for loop body,
so the quoted part is quite clear: assignment-compatibility
only applies when body is executed.

BTW: Standard also includes "equivalent" code and before this
code states that the clause I cited takes precedence over
what you would normally expect from assignment-compatibility.

BTW2: In Pascal expressions are normally computed using "full"
types and range restrictions only play role for assignment.
The "equivalent" code will perform assignment to control
variable only when body will be execute.

BTW3: Given that standard usually leaves many thing up to
general rules it is clear that the intent of wording was to
allow examples like the one reported.

BTW4: The reporter wrote this clearly in the comment to the
FPC bug report...

Re: for-loops and subrange types

Maurice Lombardi — 2013-04-27T10:50:40

Le 26/04/2013 21:33, Phil Nelson a écrit :

old versions of *GPC* had not implemented range check. What was the 
*GPC* (not *GCC*) version of that compiler ?

Maurice

Re: for-loops and subrange types

Jonas Maebe — 2013-04-27T06:37:35

On 27 Apr 2013, at 00:03, Contestcen< at >aol.com wrote:


It certainly is valid. The same goes for boolean and enumeration types.


Jonas_______________________________________________
Gpc mailing list
Gpc< at >gnu.de
https://www.g-n-u.de/mailman/listinfo/gpc

Re: for-loops and subrange types

2013-04-26T22:03:32

This compatibility requirement seems to imply that the control variable  
need not be an integer type.  Does this mean that
 
    Var  letter: char;
 
    for  letter := 'A' to 'Z'  do
 
is legitimate, or that the definers of the language expected  that might 
eventually be allowed?  Or does it merely mean that the  magnitudes must match 
the range, so that
 
    Var  num: smallint;
 
    for  num := 20000 to 40000  do
 
is illegal?
 
 
 
In a message dated 4/26/2013 4:28:41 P.M. Eastern Daylight Time,  
jonas.maebe< at >elis.ugent.be writes:

: The  initial-value and the final-value of a sequence-iteration
: of an  iteration-clause of a for-statement shall be of a type
: compatible with  the type of control-variable of the for-statement.
: The initial-value and  the final-value shall be
: assignment-compatible with the type possesed by  the
: control-variable if the statement of the for-statement
: is  executed.
_______________________________________________
Gpc mailing list
Gpc< at >gnu.de
https://www.g-n-u.de/mail

Re: for-loops and subrange types

Waldek Hebisch — 2013-04-26T20:22:58

AFAICS he is right.  ISO-10206 clause 6.9.3.9.2 says:

: The initial-value and the final-value of a sequence-iteration
: of an iteration-clause of a for-statement shall be of a type
: compatible with the type of control-variable of the for-statement.
: The initial-value and the final-value shall be
: assignment-compatible with the type possesed by the
: control-variable if the statement of the for-statement
: is executed.

Compatible type for integer subrange means that any integer
value is OK.  Assignment-compatible means that values must
be in range, but is only required when loop body is
actually executed.

Re: for-loops and subrange types

Jonas Maebe — 2013-04-26T20:28:00

On 26 Apr 2013, at 22:22, Waldek Hebisch wrote:


The for-statement includes the initial-value assignment to the control-variable and the comparison of the control-variable with the final-value. That part of the for-statement is executed any time the control flow of the program reaches the for-loop. That's why I believe that the assignment-compatibility rule applies.


Jonas_______________________________________________
Gpc mailing list
Gpc< at >gnu.de
https://www.g-n-u.de/mailman/listinfo/gpc