Dear All
I am porting the code developed using pc and cc compilers on solaris 2.6 to solaris 2.8 with gcc and gpc compilers.
I am using the makefile from the older version.In that makefile, linker(ld) is called explicitly.
Right now I am facing the below problems
1) related to real array constant intialization.
TYPE MaxCPlus_RArray = ARRAY[1..MaxCplus] OF REAL; Maxcomp_Array = ARRAY[1..Maxcomp] OF REAL;
CONST wPAF : Maxcomp_Array = [ 0.040, 0.225, 0.100, 0.344, 0.008, 0.098, 0.152, 0.176, 0.193, 0.227, 0.251, 0.197, 0.296, 0.351, 0.394, 0.444, 0.490, 0, 0, 0, 0, 0, 0, 0, 0 ];
it is giving following error
/home/kvsspl/esipas81/flo/joint_lib.inc:125: incompatible types in initialization /home/kvsspl/esipas81/flo/joint_lib.inc:125: initial value is of wrong type /home/kvsspl/esipas81/flo/joint_lib.inc:125: set constructor elements must be of ordinal type /home/kvsspl/esipas81/flo/joint_lib.inc:125: set constructor elements must be of ordinal type /home/kvsspl/esipas81/flo/joint_lib.inc:125: set constructor elements must be of ordinal type /home/kvsspl/esipas81/flo/joint_lib.inc:125: set constructor elements must be of ordinal type
2) Do we have the standard library function in gpc which accomplishes the below functionality of sun library function. open(file, pathname, history, error, buffer)
open associates the permanent file file with a file variable for reading or writing. open does not actually open the file;
3) compiler error: label `9999' used before containing binding contour
what could be the cause for above error
Please help me out
Regards Hari
__________________________________ Yahoo! FareChase: Search multiple travel sites in one click. http://farechase.yahoo.com
vanam srihari kumar wrote:
Dear All
I am porting the code developed using pc and cc compilers on solaris 2.6 to solaris 2.8 with gcc and gpc compilers.
I am using the makefile from the older version.In that makefile, linker(ld) is called explicitly.
Right now I am facing the below problems
- related to real array constant intialization.
TYPE MaxCPlus_RArray = ARRAY[1..MaxCplus] OF REAL; Maxcomp_Array = ARRAY[1..Maxcomp] OF REAL;
CONST wPAF : Maxcomp_Array = [ 0.040, 0.225, 0.100, 0.344, 0.008, 0.098, 0.152, 0.176, 0.193, 0.227, 0.251, 0.197, 0.296, 0.351, 0.394, 0.444, 0.490, 0, 0, 0, 0, 0, 0, 0, 0 ];
it is giving following error
/home/kvsspl/esipas81/flo/joint_lib.inc:125: incompatible types in initialization /home/kvsspl/esipas81/flo/joint_lib.inc:125: initial value is of wrong type /home/kvsspl/esipas81/flo/joint_lib.inc:125: set constructor elements must be of ordinal type /home/kvsspl/esipas81/flo/joint_lib.inc:125: set constructor elements must be of ordinal type /home/kvsspl/esipas81/flo/joint_lib.inc:125: set constructor elements must be of ordinal type /home/kvsspl/esipas81/flo/joint_lib.inc:125: set constructor elements must be of ordinal type
Replace [ ] with ( ).
- Do we have the standard library function in gpc
which accomplishes the below functionality of sun library function. open(file, pathname, history, error, buffer)
open associates the permanent file file with a file variable for reading or writing. open does not actually open the file;
Maybe "Assign" is useful.
- compiler error: label `9999' used before containing
binding contour
what could be the cause for above error
Could this be a bug that has been solved by now http://www.gnu-pascal.de/gpc/Fixed-Bugs.html, item
20050307: problem with string operations and goto (contour0.pas, contourbug.pas, martin1.pas, berend3.pas).
Regards,
Adriaan van Os
Adriaan van Os wrote:
vanam srihari kumar wrote:
Dear All
I am porting the code developed using pc and cc compilers on solaris 2.6 to solaris 2.8 with gcc and gpc compilers.
I am using the makefile from the older version.In that makefile, linker(ld) is called explicitly.
Right now I am facing the below problems
- related to real array constant intialization.
TYPE MaxCPlus_RArray = ARRAY[1..MaxCplus] OF REAL; Maxcomp_Array = ARRAY[1..Maxcomp] OF REAL;
CONST wPAF : Maxcomp_Array = [ 0.040, 0.225, 0.100, 0.344, 0.008, 0.098, 0.152, 0.176, 0.193, 0.227, 0.251, 0.197, 0.296, 0.351, 0.394, 0.444, 0.490, 0, 0, 0, 0, 0, 0, 0, 0 ];
it is giving following error
/home/kvsspl/esipas81/flo/joint_lib.inc:125: incompatible types in initialization /home/kvsspl/esipas81/flo/joint_lib.inc:125: initial value is of wrong type /home/kvsspl/esipas81/flo/joint_lib.inc:125: set constructor elements must be of ordinal type /home/kvsspl/esipas81/flo/joint_lib.inc:125: set constructor elements must be of ordinal type /home/kvsspl/esipas81/flo/joint_lib.inc:125: set constructor elements must be of ordinal type /home/kvsspl/esipas81/flo/joint_lib.inc:125: set constructor elements must be of ordinal type
Replace [ ] with ( ).
Yes. Seems like Sun Pascal has yet another intialization syntax (besides standard [1: 0.040; ...] and BP (0.040, ...)).
The problem with this syntax is that it really looks like set constants ([1, 2, 3]), especially if the array fields are ordinal types. So changing it should also make the code somewhat more readable IMHO.
- Do we have the standard library function in gpc
which accomplishes the below functionality of sun library function. open(file, pathname, history, error, buffer)
open associates the permanent file file with a file variable for reading or writing. open does not actually open the file;
Maybe "Assign" is useful.
Yes. I don't know what the latter 3 parameters do. If they're important, please explain.
- compiler error: label `9999' used before containing
binding contour
what could be the cause for above error
Could this be a bug that has been solved by now http://www.gnu-pascal.de/gpc/Fixed-Bugs.html, item
20050307: problem with string operations and goto (contour0.pas, contourbug.pas, martin1.pas, berend3.pas).
Yes, looks like it. If so, upgrading GPC is probably your best option. If you're afraid of that (because the current releases are labelled alpha), you could try showing us the relevant code (with some context), and we *might* be able to suggest work-arounds ...
Frank
Frank Heckenbach wrote:
Adriaan van Os wrote:
vanam srihari kumar wrote:
Dear All
I am porting the code developed using pc and cc compilers on solaris 2.6 to solaris 2.8 with gcc and gpc compilers.
I am using the makefile from the older version.In that makefile, linker(ld) is called explicitly.
Right now I am facing the below problems
- related to real array constant intialization.
TYPE MaxCPlus_RArray = ARRAY[1..MaxCplus] OF REAL; Maxcomp_Array = ARRAY[1..Maxcomp] OF REAL;
CONST wPAF : Maxcomp_Array = [ 0.040, 0.225,
<snip>
0 ];it is giving following error
/home/kvsspl/esipas81/flo/joint_lib.inc:125: incompatible types in initialization /home/kvsspl/esipas81/flo/joint_lib.inc:125: initial value is of wrong type /home/kvsspl/esipas81/flo/joint_lib.inc:125: set constructor elements must be of ordinal type
<snip>
Replace [ ] with ( ).
Yes. Seems like Sun Pascal has yet another intialization syntax (besides standard [1: 0.040; ...] and BP (0.040, ...)).
The problem with this syntax is that it really looks like set constants ([1, 2, 3]), especially if the array fields are ordinal types. So changing it should also make the code somewhat more readable IMHO.
Current GPC version allows:
CONST Maxcomp = 3; TYPE Maxcomp_Array = ARRAY[1..Maxcomp] OF REAL; CONST wPAF : Maxcomp_Array = [ 0.040; 0.225; 0 ];
(with semicolons as separators). The compiler (and presumably human readers too) use type information to decide the meaning of the list. I think that we can easily add Sun syntax (if we want to).
Waldek Hebisch wrote:
Frank Heckenbach wrote:
Adriaan van Os wrote:
vanam srihari kumar wrote:
TYPE MaxCPlus_RArray = ARRAY[1..MaxCplus] OF REAL; Maxcomp_Array = ARRAY[1..Maxcomp] OF REAL;
CONST wPAF : Maxcomp_Array = [ 0.040, 0.225,
<snip> > > > 0 ]; > > The problem with this syntax is that it really looks like set > constants ([1, 2, 3]), especially if the array fields are ordinal > types. So changing it should also make the code somewhat more > readable IMHO.
Current GPC version allows:
CONST Maxcomp = 3; TYPE Maxcomp_Array = ARRAY[1..Maxcomp] OF REAL; CONST wPAF : Maxcomp_Array = [ 0.040; 0.225; 0 ];
Indeed, that's closer to the original.
(with semicolons as separators). The compiler (and presumably human readers too) use type information to decide the meaning of the list. I think that we can easily add Sun syntax (if we want to).
Are you sure it's so easy? Even if the element type is ordinal, and it occurs deep within another structure (so you can't easily decide while parsing whether it will become a set or an array)?
Frank
Frank Heckenbach wrote:
Waldek Hebisch wrote:
I think that we can easily add Sun syntax (if we want to).
Are you sure it's so easy? Even if the element type is ordinal, and it occurs deep within another structure (so you can't easily decide while parsing whether it will become a set or an array)?
We already had to solve that problem for one element sets. Below is a patch (we probably want to add dialect checks). The question is if we want the feature.
Index: p/expressions.c =================================================================== RCS file: /mn/a8/cvsroot/gpc/p/expressions.c,v retrieving revision 1.5 diff -u -p -r1.5 expressions.c --- p/expressions.c 4 Nov 2005 01:00:21 -0000 1.5 +++ p/expressions.c 11 Nov 2005 03:35:43 -0000 @@ -3565,38 +3565,62 @@ build_routine_call (tree function, tree }
static tree -strip_needless_lists (tree list) +strip_needless_lists1 (tree list) { + if (!list) + return NULL_TREE; while (1) { - tree nl = TREE_VALUE (list); - if (TREE_CHAIN (list) || TREE_PURPOSE (list) || !nl) - return NULL_TREE; - if (TREE_CODE (nl) != TREE_LIST) - return list; - if (!PASCAL_BP_INITIALIZER_LIST (nl)) + tree nl; + if (TREE_CODE (list) != TREE_LIST) + return list; + nl = TREE_VALUE (list); + if (!PASCAL_BP_INITIALIZER_LIST (list) || + TREE_CHAIN (list) || TREE_PURPOSE (list) || !nl) return NULL_TREE; - PASCAL_BP_INITIALIZER_LIST (nl) = 0; list = nl; } }
+static tree +strip_needless_lists (tree list) +{ + tree * pl = &list; + while (*pl) + { + tree nl = strip_needless_lists1 (TREE_VALUE (*pl)); + if (TREE_PURPOSE (*pl) || !nl) + return NULL_TREE; + TREE_VALUE (*pl) = nl; + pl = &TREE_CHAIN (*pl); + } + return list; +} + +static void +preverse (tree list) +{ + while (list) + { + tree tmp = TREE_VALUE (list); + TREE_VALUE (list) = TREE_PURPOSE (list); + TREE_PURPOSE (list) = tmp; + list = TREE_CHAIN (list); + } +} + tree build_iso_set_constructor (tree type, tree list, int one_el) { tree nl = NULL_TREE; if (one_el) { - if ((list = strip_needless_lists (list))) - { - TREE_PURPOSE (list) = TREE_VALUE (list); - TREE_VALUE (list) = NULL_TREE; - } - else + if (!(list = strip_needless_lists (list))) { error ("invalid set constructor"); return error_mark_node; } + preverse (list); } while (list) { Index: p/parse.y =================================================================== RCS file: /mn/a8/cvsroot/gpc/p/parse.y,v retrieving revision 1.3 diff -u -p -r1.3 parse.y --- p/parse.y 28 Oct 2005 20:00:56 -0000 1.3 +++ p/parse.y 11 Nov 2005 03:57:37 -0000 @@ -201,7 +201,7 @@ static void locations (YYLTYPE *, const unsigned_number id_list_limited set_constructor routine_heading bp_field_value array_index_list remote_directive operator_symbol string_constant variant_list rest_of_variant new_pointer_type conformant_array enumerated_type id_list1 err - optional_rename attrib id_list id + optional_rename attrib id_list id component_value_list
%%
@@ -1910,6 +1910,21 @@ structured_constructor_list: { TREE_CHAIN (($$ = $3)) = $1; } | variant_part_value | array_value_completer + | component_value_list + ; + +/* In one element case we choose field_value_list insted */ +component_value_list: + component_value ',' component_value + { + $$ = build_tree_list (NULL_TREE, $3); + TREE_CHAIN ($$) = build_tree_list (NULL_TREE, $1); + } + | component_value_list ',' component_value + { + $$ = build_tree_list (NULL_TREE, $3); + TREE_CHAIN ($$) = $1; + } ;
field_value_list:
-
Adriaan van Os -
Frank Heckenbach -
vanam srihari kumar -
Waldek Hebisch