Menu
▾
▴
flint-devel
|
From: Michael A. <mab...@go...> - 2009-01-15 23:19:53
|
Hi Bill, at SD 10 we had a chat about using "long" in the FLINT headers and in general. Since we integration with FLINT and Sage is getting tighter and tighter, i.e. #4965 in Sage's trac, I am wondering what the long term plan is here because of the Windows port. In the development version's flint.h you already have something like #define ulong unsigned long #if FLINT_BITS == 32 #define half_ulong uint16_t #define half_long int16_t #define HALF_FLINT_BITS 16 #else #define half_ulong uint32_t #define half_long int32_t #define HALF_FLINT_BITS 32 #endif Would it be possible to also declare appropriate 64 bit types here since we cannot assume that sizeof(long)==8 on 64 bit platforms in general? Obviously the native Windows port won't happen next week, but since FLINT 2.0 is a while out it might be good to think about this now :) The SFU port of Sage also has to deal with sizeof(long)==4 in 64 bit mode AFAIK, so this is a lot more concrete than I want it to be. Cheers, Michael |
|
From: Bill H. <goo...@go...> - 2009-01-15 23:33:24
|
Hi Michael, At present I always assume that a ulong and a GMP limb are the same size. The plan is to replace unsigned long with ulong throughout the code. Then I guess you could simply change ulong in flint.h to whatever you want, though there is no point changing it to something that is not the same size as a limb, otherwise FLINT will certainly break. There's quite a bit of code to go through. But I *think* just doing a search and replace for unsigned long and replacing it with ulong should not break anything. That at least makes FLINT work on a machine where the limb size is not the same as an unsigned long. One just defines a ulong to be something that is the same size as a limb in flint.h. The bigger issue is that I also currently assume that pointer arithmetic can always be done with a ulong and in some cases I even assume that a pointer can be cast to a ulong. That is not so easy to fix at present, though this problem should occur less often throughout the code. These issues will *definitely* be fixed for FLINT 2.0. But beyond that I don't know when I will get them fixed. Another minor issue is that I assume that a double can fit in a ulong on a 64 bit machine. But whether or not the machine is 64 bit is defined in flint.h, so this problem is trivial to fix. I certainly won't have time to do anything about these problem for a few months. I have so much on at the moment it isn't funny. Bill. 2009/1/15 Michael Abshoff <mab...@go...>: > Hi Bill, > > at SD 10 we had a chat about using "long" in the FLINT headers and in > general. Since we integration with FLINT and Sage is getting tighter > and tighter, i.e. #4965 in Sage's trac, I am wondering what the long > term plan is here because of the Windows port. In the development > version's flint.h you already have something like > > #define ulong unsigned long > > #if FLINT_BITS == 32 > #define half_ulong uint16_t > #define half_long int16_t > #define HALF_FLINT_BITS 16 > #else > #define half_ulong uint32_t > #define half_long int32_t > #define HALF_FLINT_BITS 32 > #endif > > Would it be possible to also declare appropriate 64 bit types here > since we cannot assume that sizeof(long)==8 on 64 bit platforms in > general? Obviously the native Windows port won't happen next week, but > since FLINT 2.0 is a while out it might be good to think about this > now :) The SFU port of Sage also has to deal with sizeof(long)==4 in > 64 bit mode AFAIK, so this is a lot more concrete than I want it to > be. > > Cheers, > > Michael > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > flint-devel mailing list > fli...@li... > https://lists.sourceforge.net/lists/listinfo/flint-devel > |
|
From: Bill H. <goo...@go...> - 2009-01-15 23:48:12
|
The plan by the way will be to use intptr_t everywhere in FLINT where integers are needed to hold a pointer. Of course it is easier said than done. Bill. 2009/1/15 Bill Hart <goo...@go...>: > Hi Michael, > > At present I always assume that a ulong and a GMP limb are the same > size. The plan is to replace unsigned long with ulong throughout the > code. Then I guess you could simply change ulong in flint.h to > whatever you want, though there is no point changing it to something > that is not the same size as a limb, otherwise FLINT will certainly > break. > > There's quite a bit of code to go through. But I *think* just doing a > search and replace for unsigned long and replacing it with ulong > should not break anything. That at least makes FLINT work on a machine > where the limb size is not the same as an unsigned long. One just > defines a ulong to be something that is the same size as a limb in > flint.h. > > The bigger issue is that I also currently assume that pointer > arithmetic can always be done with a ulong and in some cases I even > assume that a pointer can be cast to a ulong. That is not so easy to > fix at present, though this problem should occur less often throughout > the code. > > These issues will *definitely* be fixed for FLINT 2.0. But beyond that > I don't know when I will get them fixed. > > Another minor issue is that I assume that a double can fit in a ulong > on a 64 bit machine. But whether or not the machine is 64 bit is > defined in flint.h, so this problem is trivial to fix. > > I certainly won't have time to do anything about these problem for a > few months. I have so much on at the moment it isn't funny. > > Bill. > > 2009/1/15 Michael Abshoff <mab...@go...>: >> Hi Bill, >> >> at SD 10 we had a chat about using "long" in the FLINT headers and in >> general. Since we integration with FLINT and Sage is getting tighter >> and tighter, i.e. #4965 in Sage's trac, I am wondering what the long >> term plan is here because of the Windows port. In the development >> version's flint.h you already have something like >> >> #define ulong unsigned long >> >> #if FLINT_BITS == 32 >> #define half_ulong uint16_t >> #define half_long int16_t >> #define HALF_FLINT_BITS 16 >> #else >> #define half_ulong uint32_t >> #define half_long int32_t >> #define HALF_FLINT_BITS 32 >> #endif >> >> Would it be possible to also declare appropriate 64 bit types here >> since we cannot assume that sizeof(long)==8 on 64 bit platforms in >> general? Obviously the native Windows port won't happen next week, but >> since FLINT 2.0 is a while out it might be good to think about this >> now :) The SFU port of Sage also has to deal with sizeof(long)==4 in >> 64 bit mode AFAIK, so this is a lot more concrete than I want it to >> be. >> >> Cheers, >> >> Michael >> >> ------------------------------------------------------------------------------ >> This SF.net email is sponsored by: >> SourcForge Community >> SourceForge wants to tell your story. >> http://p.sf.net/sfu/sf-spreadtheword >> _______________________________________________ >> flint-devel mailing list >> fli...@li... >> https://lists.sourceforge.net/lists/listinfo/flint-devel >> > |
|
From: Michael A. <mab...@go...> - 2009-01-16 00:02:11
|
On Thu, Jan 15, 2009 at 3:48 PM, Bill Hart <goo...@go...> wrote: Hi Bill, > The plan by the way will be to use intptr_t everywhere in FLINT where > integers are needed to hold a pointer. Of course it is easier said > than done. Sure, but I can help with "menial" tasks like that. The big question is whether any of those changes could be in FLINT 1.1 since it would potentially break API. Given the rather unclear time table for FLINT 2.0 I don't want to depend on that to get a 64 bit SFU version of Sage going. > Bill. > > 2009/1/15 Bill Hart <goo...@go...>: >> Hi Michael, >> >> At present I always assume that a ulong and a GMP limb are the same >> size. The plan is to replace unsigned long with ulong throughout the >> code. Then I guess you could simply change ulong in flint.h to >> whatever you want, though there is no point changing it to something >> that is not the same size as a limb, otherwise FLINT will certainly >> break. >> >> There's quite a bit of code to go through. But I *think* just doing a >> search and replace for unsigned long and replacing it with ulong >> should not break anything. That at least makes FLINT work on a machine >> where the limb size is not the same as an unsigned long. One just >> defines a ulong to be something that is the same size as a limb in >> flint.h. Yes. Note that neither gmp nor eMPIRe compiled on MinGW 64 due to it using long instead of long long as basic 64 bit type. There was a patch on the gmp list many months ago that added a check if sizeof(long)==sizeof(long long) and it it failed used long long. This is something that is done in a similar way for Brian's 64 bit MSVC build, but I am hazy on the details. Once we have eMPIRe build on MinGW 64 we can easily test FLINT in 64 bit mode on Windows without the need to do a port to MSVC which should make things much easier. >> The bigger issue is that I also currently assume that pointer >> arithmetic can always be done with a ulong and in some cases I even >> assume that a pointer can be cast to a ulong. That is not so easy to >> fix at present, though this problem should occur less often throughout >> the code. >> >> These issues will *definitely* be fixed for FLINT 2.0. But beyond that >> I don't know when I will get them fixed. >> >> Another minor issue is that I assume that a double can fit in a ulong >> on a 64 bit machine. But whether or not the machine is 64 bit is >> defined in flint.h, so this problem is trivial to fix. Ok. >> I certainly won't have time to do anything about these problem for a >> few months. I have so much on at the moment it isn't funny. Sure, I am not complaining, I want to help you. Obviously my time table is about as empty as your's, so no promises here :) >> Bill. Cheers, Michael |
|
From: Bill H. <goo...@go...> - 2009-01-16 00:23:10
|
Hi Michael, the timetable for FLINT 2.0 is not so uncertain. It should be out for Christmas this year. But you don't want to wait that ulong. Doing a search and replace of unsigned long for ulong is certainly something you can go ahead and do. It won't break FLINT 1.1 (I don't think). Replacing integers that hold pointers with intptr_t will not break FLINT 1.1 on any of the systems it currently works on, as intptr_t will be a 32 or 64 bit integer on a 32 and 64 bit machine respectively. But it isn't a magic bullet for LLP and SFU machines. FLINT still won't work on those machines without human intervention. It is that job which I need to find the time to complete. Assuming the rest was already done, I guess I could look at it in a little over a month. Would that screw with your timetable too much? Perhaps I would have time to do it at UW in April or May, but that seems to be an appalling waste of time, and William may not approve. I suppose Sage days at UW is one time I might get away with it! Bill. 2009/1/16 Michael Abshoff <mab...@go...>: > On Thu, Jan 15, 2009 at 3:48 PM, Bill Hart <goo...@go...> wrote: > > Hi Bill, > >> The plan by the way will be to use intptr_t everywhere in FLINT where >> integers are needed to hold a pointer. Of course it is easier said >> than done. > > Sure, but I can help with "menial" tasks like that. The big question > is whether any of those changes could be in FLINT 1.1 since it would > potentially break API. Given the rather unclear time table for FLINT > 2.0 I don't want to depend on that to get a 64 bit SFU version of Sage > going. > >> Bill. >> >> 2009/1/15 Bill Hart <goo...@go...>: >>> Hi Michael, >>> >>> At present I always assume that a ulong and a GMP limb are the same >>> size. The plan is to replace unsigned long with ulong throughout the >>> code. Then I guess you could simply change ulong in flint.h to >>> whatever you want, though there is no point changing it to something >>> that is not the same size as a limb, otherwise FLINT will certainly >>> break. >>> >>> There's quite a bit of code to go through. But I *think* just doing a >>> search and replace for unsigned long and replacing it with ulong >>> should not break anything. That at least makes FLINT work on a machine >>> where the limb size is not the same as an unsigned long. One just >>> defines a ulong to be something that is the same size as a limb in >>> flint.h. > > Yes. Note that neither gmp nor eMPIRe compiled on MinGW 64 due to it > using long instead of long long as basic 64 bit type. There was a > patch on the gmp list many months ago that added a check if > sizeof(long)==sizeof(long long) and it it failed used long long. This > is something that is done in a similar way for Brian's 64 bit MSVC > build, but I am hazy on the details. > > Once we have eMPIRe build on MinGW 64 we can easily test FLINT in 64 > bit mode on Windows without the need to do a port to MSVC which should > make things much easier. > >>> The bigger issue is that I also currently assume that pointer >>> arithmetic can always be done with a ulong and in some cases I even >>> assume that a pointer can be cast to a ulong. That is not so easy to >>> fix at present, though this problem should occur less often throughout >>> the code. >>> >>> These issues will *definitely* be fixed for FLINT 2.0. But beyond that >>> I don't know when I will get them fixed. >>> >>> Another minor issue is that I assume that a double can fit in a ulong >>> on a 64 bit machine. But whether or not the machine is 64 bit is >>> defined in flint.h, so this problem is trivial to fix. > > Ok. > >>> I certainly won't have time to do anything about these problem for a >>> few months. I have so much on at the moment it isn't funny. > > Sure, I am not complaining, I want to help you. Obviously my time > table is about as empty as your's, so no promises here :) > >>> Bill. > > Cheers, > > Michael > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > flint-devel mailing list > fli...@li... > https://lists.sourceforge.net/lists/listinfo/flint-devel > |
|
From: Michael A. <mab...@go...> - 2009-01-16 00:53:56
|
On Thu, Jan 15, 2009 at 4:23 PM, Bill Hart <goo...@go...> wrote: > Hi Michael, Hi Bill. > the timetable for FLINT 2.0 is not so uncertain. It should be out for > Christmas this Sure, but this is roughly a year away :) > year. But you don't want to wait that ulong. Nice pun. > Doing a search and replace of unsigned long for ulong is certainly > something you can go ahead and do. It won't break FLINT 1.1 (I don't > think). It won't aside from some C compiler throwing a couple new warnings. But if you are willing to risk it I am game. > Replacing integers that hold pointers with intptr_t will not break > FLINT 1.1 on any of the systems it currently works on, as intptr_t > will be a 32 or 64 bit integer on a 32 and 64 bit machine > respectively. But it isn't a magic bullet for LLP and SFU machines. > FLINT still won't work on those machines without human intervention. > It is that job which I need to find the time to complete. Absolutely, but given its extensive test suite and a little compiler magic I think I can help out finding and fixing those issues by using MinGW 64. > Assuming the rest was already done, I guess I could look at it in a > little over a month. Would that screw with your timetable too much? Well, the timetable for the Windows port has been slipping so bad I hope I won't be pulling a Vista :) But in all seriousness: The Solaris port is nearing completion and hopefully the remaining few issues will be sorted out at SD 12. Then my focus will shift to the Cygwin as well as 32 bit SFU port which I hope I will get done in about two months, i.e. by the end of March. Then the 64 bit SFU port would be next where issues like the ones in FLINT will likely pop up in many other places, too, but I am hoping this won't take the rest of the year to fix. > Perhaps I would have time to do it at UW in April or May, but that > seems to be an appalling waste of time, and William may not approve. I > suppose Sage days at UW is one time I might get away with it! Well, I can assure you that the Windows port is very important for William, but your time at UW is probably better spend mostly on something else. I had originally planned to spend some time at UW in February and March, but things have moved around. Maybe coordinating me being at UW for at least a couple weeks in the time frame you are there and then planning to work on the 64 bit Windows issues for FLINT among other things might be a good idea. I.e. I could imagine me asking a bunch of questions every couple days and then coming back with patches for you to look at so that the impact for your work at UW is rather minimal. We can take this part of the discussion off-list with William since not too many people on flint-devel will care I guess :) > Bill. Cheers, Michael |
|
From: Bill H. <goo...@go...> - 2009-01-16 01:22:55
|
Hi Michael, you are set to go. I've checked you have write access to the flint repo. Thanks for offering to help with this. Bill. 2009/1/16 Michael Abshoff <mab...@go...>: > On Thu, Jan 15, 2009 at 4:23 PM, Bill Hart <goo...@go...> wrote: >> Hi Michael, > > Hi Bill. > >> the timetable for FLINT 2.0 is not so uncertain. It should be out for >> Christmas this > > Sure, but this is roughly a year away :) > >> year. But you don't want to wait that ulong. > > Nice pun. > >> Doing a search and replace of unsigned long for ulong is certainly >> something you can go ahead and do. It won't break FLINT 1.1 (I don't >> think). > > It won't aside from some C compiler throwing a couple new warnings. > But if you are willing to risk it I am game. > >> Replacing integers that hold pointers with intptr_t will not break >> FLINT 1.1 on any of the systems it currently works on, as intptr_t >> will be a 32 or 64 bit integer on a 32 and 64 bit machine >> respectively. But it isn't a magic bullet for LLP and SFU machines. >> FLINT still won't work on those machines without human intervention. >> It is that job which I need to find the time to complete. > > Absolutely, but given its extensive test suite and a little compiler > magic I think I can help out finding and fixing those issues by using > MinGW 64. > >> Assuming the rest was already done, I guess I could look at it in a >> little over a month. Would that screw with your timetable too much? > > Well, the timetable for the Windows port has been slipping so bad I > hope I won't be pulling a Vista :) > > But in all seriousness: The Solaris port is nearing completion and > hopefully the remaining few issues will be sorted out at SD 12. Then > my focus will shift to the Cygwin as well as 32 bit SFU port which I > hope I will get done in about two months, i.e. by the end of March. > Then the 64 bit SFU port would be next where issues like the ones in > FLINT will likely pop up in many other places, too, but I am hoping > this won't take the rest of the year to fix. > >> Perhaps I would have time to do it at UW in April or May, but that >> seems to be an appalling waste of time, and William may not approve. I >> suppose Sage days at UW is one time I might get away with it! > > Well, I can assure you that the Windows port is very important for > William, but your time at UW is probably better spend mostly on > something else. I had originally planned to spend some time at UW in > February and March, but things have moved around. Maybe coordinating > me being at UW for at least a couple weeks in the time frame you are > there and then planning to work on the 64 bit Windows issues for FLINT > among other things might be a good idea. I.e. I could imagine me > asking a bunch of questions every couple days and then coming back > with patches for you to look at so that the impact for your work at UW > is rather minimal. > > We can take this part of the discussion off-list with William since > not too many people on flint-devel will care I guess :) > >> Bill. > > Cheers, > > Michael > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > flint-devel mailing list > fli...@li... > https://lists.sourceforge.net/lists/listinfo/flint-devel > |
|
From: Michael A. <mab...@go...> - 2009-01-16 01:28:11
|
On Thu, Jan 15, 2009 at 5:22 PM, Bill Hart <goo...@go...> wrote: > Hi Michael, Hi Bill, > you are set to go. I've checked you have write access to the flint > repo. Thanks for offering to help with this. Well, I have great planes, but let's hope it actually translates into patches. The first step for me would be to get MinGW 64 bit up and running as well as make eMPIRe build in 64 bit mode. My time until the end of SD12 is basically filled with Solaris work, but after that you need to gently remind me to do some friggin' work :) > Bill. Cheers, Michael |
|
From: Michael A. <mab...@go...> - 2009-01-16 02:27:22
|
On Thu, Jan 15, 2009 at 5:15 PM, Bill Hart <goo...@go...> wrote: Hi Bill, > It's ok to keep the discussion on list, but you are also welcome to > take it offline. I only meant to discuss the details of potentially meeting up at UW to work on this. All the technical discussion should happen on list. > You are welcome to check out FLINT and start modifying files if you > want. One complication is that modifications for the FLINT 1.1 series > need to be made to trunk *and* the flint-1.1 branch. There is no way > to merge the changes to both automatically as the two directories > differ. Note that there are more files in the trunk than the flint-1.1 > branch, but all files that appear in flint-1.1 also appear in trunk. Ok, it seems like I should be working on the development version then and if we get that to work we can always back port the relevant changes. This allows for more flexibility and won't impact the stable branch. > I am the only person committing code at present and I am likely to > spend time only in the files F_zmod_poly.c/h, F_zmod_poly-test.c and > packed_vec.c/h (which only exist in trunk) for the next couple of > days. Otherwise you are welcome to edit the other files as you wish. > When it comes to modifying the files I am currently working on I'll do > a commit so you can work on them. Sure. As mentioned in the other mail my time for the next 10 or so days is booked. > I will enable write access to the flint-svn via your sourceforge > username in a few moments. But can I ask that you tell me which files > you're modifying two or three at a time so I can complain if > necessary. :-) Thanks, will do. > You will also need to replace long with something. I don't know what > to call it. slong will probably have to do, though it is very close to > a rude Australian swear word, Not only Australian :) But I am wondering if using something closer to a C99 unsigned long and signed long type might make the nature of ulong and "slong" more clear. But I think this will cause confusion with the underlying gmp types. I need to think about this more. Either way, signed and unsignled long types should be consistent in naming convention if possible. But in the end I can certainly live with ulong slong > i.e. FLINT should use ulong instead of > unsigned long and slong instead of long throughout. Finding where > pointers are assigned to a ulong will be difficult to find. Looking > for all occurrences of **, fmpz_t and ****alloc*** (e.g. > flint_heap_alloc, malloc, flint_stack_alloc, flint_stack_alloc_small, > flint_stack_alloc_bytes, etc) should get many of them. Ok. There is a new valgrind tool called exp-ptrcheck that catches the use of 32 bit pointers when interacting with 64 bit pointers. It doesn't run on anything but Linux and I can't see a way yet to make long on 64 bit platforms 32 bit without impacting all the other things FLINT uses. There is no LLP Linux box AFAIK, so maybe using purify in Windows might lead some assistance. In the end it might have to be good old fashioned debugging :) > Bill. Cheers, Michael |
|
From: Bill H. <goo...@go...> - 2009-01-16 02:43:11
|
Damn, I was hoping to get to SD12, but I'm going to miss it. Oh well, have fun. Bill. 2009/1/16 Michael Abshoff <mab...@go...>: > On Thu, Jan 15, 2009 at 5:22 PM, Bill Hart <goo...@go...> wrote: >> Hi Michael, > > Hi Bill, > >> you are set to go. I've checked you have write access to the flint >> repo. Thanks for offering to help with this. > > Well, I have great planes, but let's hope it actually translates into > patches. The first step for me would be to get MinGW 64 bit up and > running as well as make eMPIRe build in 64 bit mode. My time until the > end of SD12 is basically filled with Solaris work, but after that you > need to gently remind me to do some friggin' work :) > >> Bill. > > Cheers, > > Michael > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > flint-devel mailing list > fli...@li... > https://lists.sourceforge.net/lists/listinfo/flint-devel > |
|
From: Michael A. <mab...@go...> - 2009-01-16 03:09:49
|
On Thu, Jan 15, 2009 at 5:36 PM, Bill Hart <goo...@go...> wrote: > Damn, I was hoping to get to SD12, but I'm going to miss it. Oh well, have fun. > > Bill. Well, it will be a 72 hour bug squashing marathon, so the best kind of Sage Days :) Cheers, Michael |
|
From: Bill H. <goo...@go...> - 2009-01-16 02:56:59
|
2009/1/16 Michael Abshoff <mab...@go...>: > On Thu, Jan 15, 2009 at 5:15 PM, Bill Hart <goo...@go...> wrote: > > Hi Bill, > >> It's ok to keep the discussion on list, but you are also welcome to >> take it offline. > > I only meant to discuss the details of potentially meeting up at UW to > work on this. All the technical discussion should happen on list. > >> You are welcome to check out FLINT and start modifying files if you >> want. One complication is that modifications for the FLINT 1.1 series >> need to be made to trunk *and* the flint-1.1 branch. There is no way >> to merge the changes to both automatically as the two directories >> differ. Note that there are more files in the trunk than the flint-1.1 >> branch, but all files that appear in flint-1.1 also appear in trunk. > > Ok, it seems like I should be working on the development version then > and if we get that to work we can always back port the relevant > changes. This allows for more flexibility and won't impact the stable > branch. Any changes to trunk without changing flint-1.1 will not appear in Sage until FLINT 2.0 is released. The vast majority of files are identical between the two at this moment in time (which diff can check for you). If you change one version, you may as well change the other). Of the remaining files, most of those appear only in trunk. There are a handful of files which appear in trunk and flint-1.1 which differ, but these are small enough in number to deal with separately at present. > >> I am the only person committing code at present and I am likely to >> spend time only in the files F_zmod_poly.c/h, F_zmod_poly-test.c and >> packed_vec.c/h (which only exist in trunk) for the next couple of >> days. Otherwise you are welcome to edit the other files as you wish. >> When it comes to modifying the files I am currently working on I'll do >> a commit so you can work on them. > > Sure. As mentioned in the other mail my time for the next 10 or so > days is booked. > >> I will enable write access to the flint-svn via your sourceforge >> username in a few moments. But can I ask that you tell me which files >> you're modifying two or three at a time so I can complain if >> necessary. :-) > > Thanks, will do. > >> You will also need to replace long with something. I don't know what >> to call it. slong will probably have to do, though it is very close to >> a rude Australian swear word, > > Not only Australian :) > > But I am wondering if using something closer to a C99 unsigned long > and signed long type might make the nature of ulong and "slong" more > clear. But I think this will cause confusion with the underlying gmp > types. I need to think about this more. Either way, signed and > unsignled long types should be consistent in naming convention if > possible. But in the end I can certainly live with > > ulong > slong I used ulong because it is what David uses in zn_poly. It is convenient because it is short to type. I don't know what he uses for long. Probably he uses long. > >> i.e. FLINT should use ulong instead of >> unsigned long and slong instead of long throughout. Finding where >> pointers are assigned to a ulong will be difficult to find. Looking >> for all occurrences of **, fmpz_t and ****alloc*** (e.g. >> flint_heap_alloc, malloc, flint_stack_alloc, flint_stack_alloc_small, >> flint_stack_alloc_bytes, etc) should get many of them. > > Ok. There is a new valgrind tool called exp-ptrcheck that catches the > use of 32 bit pointers when interacting with 64 bit pointers. It > doesn't run on anything but Linux and I can't see a way yet to make > long on 64 bit platforms 32 bit without impacting all the other things > FLINT uses. There is no LLP Linux box AFAIK, so maybe using purify in > Windows might lead some assistance. In the end it might have to be > good old fashioned debugging :) Yeah I don't have any easy answers here. The problem is, it is not going to be enough to just make sure all the tests pass. The tests are not designed to pick up problems with pointer arithmetic. Presumably the compiler will complain though. If it doesn't, send a strongly worded letter to the compiler writer. I suppose the compiler may not have a problem with using a 32 bit ulong for pointer arithmetic between 64 bit pointers though.This would be a serious bug which would affect FLINT in real world use but would not fail a single test. The only way to fix that would be to check every occurrence of * in FLINT and every occurrence of every type which is typedef'd to some blah * or blah **. If that is the case, you're screwed, and see you in a year or two, I'm off to the Bahamas. I expect the problem will be casts, which no doubt the compiler will be happy with regardless if they are correct. But casts should always be of the form (ulong *), (mp_limb_t *), etc or (ulong), etc, depending which way the cast is. So if you look for all occurrences of (ulong), (mp_limb_t), (F_mpz_t) and *) and **) you should get everything the compiler misses, Bill. |
|
From: Michael A. <mab...@go...> - 2009-01-16 03:12:52
|
On Thu, Jan 15, 2009 at 6:56 PM, Bill Hart <goo...@go...> wrote: > 2009/1/16 Michael Abshoff <mab...@go...>: <SNIP> >> Ok, it seems like I should be working on the development version then >> and if we get that to work we can always back port the relevant >> changes. This allows for more flexibility and won't impact the stable >> branch. > > Any changes to trunk without changing flint-1.1 will not appear in > Sage until FLINT 2.0 is released. Yes, but I see porting patches to FLINT 1.1 once they have worked out in the FLINT 2.0 trunk. > The vast majority of files are identical between the two at this > moment in time (which diff can check for you). If you change one > version, you may as well change the other). Of the remaining files, > most of those appear only in trunk. There are a handful of files which > appear in trunk and flint-1.1 which differ, but these are small enough > in number to deal with separately at present. Ok, good to know. >> But in the end I can certainly live with >> >> ulong >> slong > > I used ulong because it is what David uses in zn_poly. It is > convenient because it is short to type. I don't know what he uses for > long. Probably he uses long. That sounds like it will be another library to revisit. Let's hope he abstracted out all the types, but I haven't looked. >> Ok. There is a new valgrind tool called exp-ptrcheck that catches the >> use of 32 bit pointers when interacting with 64 bit pointers. It >> doesn't run on anything but Linux and I can't see a way yet to make >> long on 64 bit platforms 32 bit without impacting all the other things >> FLINT uses. There is no LLP Linux box AFAIK, so maybe using purify in >> Windows might lead some assistance. In the end it might have to be >> good old fashioned debugging :) > > Yeah I don't have any easy answers here. The problem is, it is not > going to be enough to just make sure all the tests pass. The tests are > not designed to pick up problems with pointer arithmetic. Presumably > the compiler will complain though. If it doesn't, send a strongly > worded letter to the compiler writer. > > I suppose the compiler may not have a problem with using a 32 bit > ulong for pointer arithmetic between 64 bit pointers though.This would > be a serious bug which would affect FLINT in real world use but would > not fail a single test. The only way to fix that would be to check > every occurrence of * in FLINT and every occurrence of every type > which is typedef'd to some blah * or blah **. If that is the case, > you're screwed, and see you in a year or two, I'm off to the Bahamas. Well, this was meant to test is there is still any long pointer lurking around somewhere. The compiler should pick all of them up, but we will see. > I expect the problem will be casts, which no doubt the compiler will > be happy with regardless if they are correct. But casts should always > be of the form (ulong *), (mp_limb_t *), etc or (ulong), etc, > depending which way the cast is. So if you look for all occurrences of > (ulong), (mp_limb_t), (F_mpz_t) and *) and **) you should get > everything the compiler misses, I guess learning about all the gory internals of FLINT can't be a bad thing :) > Bill. Cheers, Michael > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > flint-devel mailing list > fli...@li... > https://lists.sourceforge.net/lists/listinfo/flint-devel > |
Thanks for helping keep SourceForge clean.
X