Hi, all!
As for our last discussion re buffure overflows, I had to take time to think and do homework, after which I feel more sympathetic to what you have said - stack execution protection truly isn't all.
NOW; I was asked from GCC team whether the RotateLeft/RotateRight bug is still present in their middle-end/back-end, and I am unable to tell without trying to recompile implementation attempt in PASCAL with newest backend (3.4.5, as it seem that GPC still does not support 4.0.2 :-(
However, it appears that predef.h is missing from gpc-yyyymmdd/p subtree. On surface, it appears to be replaced by predef.def.
I am not sure if the mechanism of definition of primitives is the same as the previous one in predef.h, so I am asking because you of course know more.
Thank you very much in forward.
Best regards, Mirsad
"Tvrdim da bi se napetost izmedju znanosti i vjere trebala rijesiti njihovom sintezom, a ne odbacivanjem ili podvojenoscu."
Pierre Teilhard de Chardin (1881-1955)
Mirsad Todorovac wrote:
As for our last discussion re buffure overflows, I had to take time to think and do homework, after which I feel more sympathetic to what you have said - stack execution protection truly isn't all.
NOW; I was asked from GCC team whether the RotateLeft/RotateRight bug is still present in their middle-end/back-end, and I am unable to tell without trying to recompile implementation attempt in PASCAL with newest backend (3.4.5, as it seem that GPC still does not support 4.0.2 :-(
No, it doesn't yet. That's kind of a FAQ here ...
However, it appears that predef.h is missing from gpc-yyyymmdd/p subtree. On surface, it appears to be replaced by predef.def.
I am not sure if the mechanism of definition of primitives is the same as the previous one in predef.h, so I am asking because you of course know more.
Yes, it's the same. The file was just renamed because it really isn't a C header file (similar to other files such as tree.def in the backend).
Frank
Thanks, Frank,
On Mon, 20 Feb 2006, Frank Heckenbach wrote:
Mirsad Todorovac wrote:
NOW; I was asked from GCC team whether the RotateLeft/RotateRight bug is still present in their middle-end/back-end, and I am unable to tell without trying to recompile implementation attempt in PASCAL with newest backend (3.4.5, as it seem that GPC still does not support 4.0.2 :-(
No, it doesn't yet. That's kind of a FAQ here ...
Yes, I realize there must be problems here, but I ma certain the Team is more than able to keep up with the task :-)
I am not sure if the mechanism of definition of primitives is the same as the previous one in predef.h, so I am asking because you of course know more.
Yes, it's the same. The file was just renamed because it really isn't a C header file (similar to other files such as tree.def in the backend).
Now, I was digging into it, and the new version keep complaining about the invalid operands to RotateLeft/RotateRight when argument is even a ''Byte''
The predef.def lines look like (inherited from Pred/Succ, and worked before, in 2003 versions):
PREDEF_ROUTINE (RotateLeft, "xv,r|", ER_CONST, GNU_PASCAL) PREDEF_ROUTINE (RotateRight, "xv,r|", ER_CONST, GNU_PASCAL)
In fact, I was going through the source quite a bit before and now, and I still can't seem to catch all the tricks of this "signature" string ...
Essentially, the implementation is simple as LROTATE_EXPR and RROTATE_EXPR are supported by the backend already:
I see that now build_binary_op is depracated and abandoned in favor of build_pascal_binary_op. Is that the problem (also build_binary_op has misteriously lost last (default 0) argument).
Any help with this? Thank you!
Mirsad
P.S: Here is the implementation attempt:
----- case p_RotateLeft: case p_RotateRight: { int left = (r_num == p_RotateLeft); int precision = TYPE_PRECISION (type); tree precision_node = build_int_2 (precision, 0);
if (code == REAL_TYPE) error ("argument 1 of `%s' must be of integer type", r_name); else if (code2 == REAL_TYPE) error ("argument 2 of `%s' must be of integer type", r_name); if (argcount == 1) val2 = integer_one_node; else val2 = build_binary_op (TRUNC_MOD_EXPR, val2, precision_node);
retval = convert (type, build_binary_op (left ? LROTATE_EXPR : RROTATE_EXPR, val, val2)); } break;
And the demo breaks:
mtodorov@domac:~/rotltest$ cat rotl_bb.pas program rotlnnn (output);
var i0, i: Byte; j: Byte;
begin i0 := 1; j := BitSizeof (i0) + 1; i := RotateLeft (i0, j); if i <> RotateLeft (i0, 1) then WriteLn ('failed : i: Byte = 1; j: Byte = ', j, '; RotateLeft(i, j) = ', i) else WriteLn ('OK') end. mtodorov@domac:~/rotltest$ gpc rotl_bb.pas rotl_bb.pas: In main program: rotl_bb.pas:13: error: invalid operands to `RotateLeft' rotl_bb.pas:14: error: invalid operands to `RotateLeft' mtodorov@domac:~/rotltest$
Mirsad Todorovac wrote:
Now, I was digging into it, and the new version keep complaining about the invalid operands to RotateLeft/RotateRight when argument is even a ''Byte''
The predef.def lines look like (inherited from Pred/Succ, and worked before, in 2003 versions):
PREDEF_ROUTINE (RotateLeft, "xv,r|", ER_CONST, GNU_PASCAL) PREDEF_ROUTINE (RotateRight, "xv,r|", ER_CONST, GNU_PASCAL)
In fact, I was going through the source quite a bit before and now, and I still can't seem to catch all the tricks of this "signature" string ...
Searching for the character in '' in predef.c sometimes helps:
[...]
case 'r': case 'e': if (!INT_REAL (code)) errstr = "argument %d to `%s' must be a real or an integer"; break; case 'v': if (!ORDINAL_OR_REAL_TYPE (code) && code != POINTER_TYPE) errstr = "argument %d to `%s' must be of ordinal, real or pointer type"; break;
I don't think you want real types here. (You probably took it from `Succ', but `Succ' for reals is a GPC extension.) You probably don't want pointers either (pointer arithmetics *can* be strange, but rotation, well, no :-).
The `,' means optional parameters follow (for `Succ' that's according to the standards, for rotations we'd have to decide if we want it -- if so, the code in predef.c must handle this case and supply the missing parameters, here probably 1). The part after `|' is the signature of the RTS routine which may be the same as the Pascal-level one (then `|...' is omitted), or different if the compiler does some magic, or missing for completely inlined routines, such as here (then there's nothing after the `|').
BTW, feel free to write this up more formally and completely as a chapter in internals.texi. :-) I'm afraid I don't have the time to do it (but I could proofread your writing if you do) ...
I see that now build_binary_op is depracated and abandoned in favor of build_pascal_binary_op. Is that the problem
Probably not the problem, though you should do the same when you add it.
(also build_binary_op has misteriously lost last (default 0) argument).
Some changes may be mysterious, but this one is documented in the ChangeLog (2005-01-06).
And the demo breaks:
mtodorov@domac:~/rotltest$ cat rotl_bb.pas program rotlnnn (output);
var i0, i: Byte; j: Byte;
begin i0 := 1; j := BitSizeof (i0) + 1; i := RotateLeft (i0, j); if i <> RotateLeft (i0, 1) then WriteLn ('failed : i: Byte = 1; j: Byte = ', j, '; RotateLeft(i, j) = ', i) else WriteLn ('OK') end. mtodorov@domac:~/rotltest$ gpc rotl_bb.pas rotl_bb.pas: In main program: rotl_bb.pas:13: error: invalid operands to `RotateLeft' rotl_bb.pas:14: error: invalid operands to `RotateLeft' mtodorov@domac:~/rotltest$
This message doesn't come from predef.c, but from expressions.c (you find the text in binary_op_error()) which is called from build_binary_op() (`if (!result_type)') -- all the other calls are for specific operands or types, so it must be this one. So you'd have to add some code in build_binary_op() (and build_pascal_binary_op()) to support it.
But, BTW, you remember of discussions back then about principal problems such as well-defined results (here: RotateLeft (i0 + 0, j) would yield a different result, when `+' is evaluted in `Integer', very strange), and my suspicion that it might not be worth the trouble to build it in? (Perhaps a pseudo-procedure with a pseudo-var-parameter would help to avoid the type-size issues. I think we've talked about this, but I don't remember the conclusion. If you don't have the old mails handy, I could probably look it up.)
Frank
-
Frank Heckenbach -
Mirsad Todorovac