Mirsad Todorovac wrote:
OK, here are the results:
Alpha SparcSizeof(Pointer) 8 4 Sizeof(Integer) 4 4 Sizeof(MedInt) 8 4
So the Sparc compiler is 32 bit, and the problem is likely to be 64 bit specific (and I have reason to assume, also dependent on the endianness).
Thanks. I'm putting your programs in the test suite (mirsad[12].pas).
That's great! I thought of making some more thorough verifications of proper working of SETs, yet I wonder how much time is acceptable for a single test to last?
You mean run time in the test suite? Well, as much as is necessary ... I've written some tests that run quite for a while. But, of course, the shorter the better (i.e., the prime number sieve is quite a bit of overhead for a test of sets, but on a range of up to 255, it's short enough to be unnoticeable; but if for some reason you'd do it with a larger range, a simpler test algorithm would be preferable). But if the time is spent testing many different situations where problems might occur, it's certainly worth it.
Anyway - if I could be of more help (even including giving you access to our Alpha machine) -
Indeed, it would be very helpful if you could give me an account and somme disk space. I have a few ideas what could be wrong, and it's probably easier if I can test them on the actual machine, than each time asking you to do it and send me the results ...
It might be related to endianness, and at the moment I'm quite confident that it will be rather easy to fix.
OK. Whould 2GB be enough disk space (I don't think I can provide more at the moment, but you will not have quotas - so help yourself).
That's far more than enough. Usually, GCC/GPC builds, including source, take around 150 MB (very roughly, don't remember exactly). On a 64 bit platform, the objects and executables might be somewhat larger, but certainly far below a GB.
The account you gave me is working for me, and I think I'll test (and hopefully fix) GPC on it next week.
Also, if that may help, I've defined -DEGCS95 while compiling (I think that last time it did not compile without defining no -DEGCS....). Then again, I've used the same -DEGCS95 on Solaris and it works ...
Usually configure will detect the version automatically and write it into gcc-version.h, so one doesn't have to give any of these flags manually. However, there was a bug in it when using non-GNU grep. It was fixed before 20010924, but after 20010315.
OK. Taken for notice. I remember having problems with May verison of GPC and EGCS defines.
Yes. The date is was fixed was 20010713.
Right now I've noticed that GPC doesn't compile well when -DEGCS97 is set on Solaris (with 20010924 version). I had to recompile everything from scratch with -DEGCS97,
With or without? AFAIK, EGCS97 should never be defined -- this port is still unfinished (and probably never will be finished since when Peter works on it again, he'll go directly for 3.0 I suppose).
Frank