Mirsad Todorovac wrote:
This test I've tried to tweak to isolate the set on Alpha problem. I hope they might give some help with finding bug (altough I'm aware that there are many other important things to do with GPC).
New tests are in attachment (submitted for approval). I hope that it's not a problem - it may be harder to read on some email clients, but on the other hand it's easier to save them ...
Yes, it is. (If noone else is interested, perhaps it's better to send them to me privately; others will get them with the next GPC version, anyway.)
Results on SOlaris: all OK.
Same on Linux/IA32 and DJGPP.
Results on Alpha: mirsad06: Failed: extra: 31 IN [0..255]-[31..31] miss: 32 NOT IN [0..255]-[0..0] mirsad07: OK mirsad08: Failed: 32 not set but IN [0..255] mirsad09: Failed: 32 not set but IN [0..255] mirsad10: Failed: 31 set but not IN [32..95] mirsad11: Failed: 32 not set but IN [0..32] mirsad12: Failed: 31 set but not IN [32..32]
I was surprized for mirsad07 passed OK, since I've designed it to fail on Alpha (you might say maliciously).
It uses something like ``IF (i IN [start..endr]) THEN'' test which compiled correctly. This leas me to produce assembly, and I was surprized to see that it didn't call _p_set_in fucntion from RTS (p/rts/sets.pas, as Frank said).
Exactly. That's why I'm not surprised that it didn't fail. GPC optimizes test of the form `... in [...]' to a sequence of `=', `>=' and `<=' comparisons and avoids constructing sets at all.
On the other hand, ``FOR i IN [start..endr] DO'' use _p_set_in and do fail.
GPC does not use this optimization for loops yet (but perhaps it's a good idea to do so in the future, though it will become more difficult with constructors containing several ranges ...)
Frank