On Fri, 13 Jul 2012, Mike Stump wrote: > I understand the beauty of putting in the const wide int stuff first... > I don't think it matters much to me... but I might ask why? I think we > have added support for all in-tree gcc ports for all possible testcases. > Do you know of a single testcase that fails on a single port?
We need to be careful about putting in changes that are only relevant for out-of-tree ports, because it's impossible for anyone using FSF GCC to validate whether the code in question works properly. Fixing issues that look like they would appear with a port with 256-bit integer support, and adding associated testcases, helps convince peopel that the code is sound. So does implementing it in a suitably generic way, so that the same code paths are used by narrower types for in-tree ports rather than there being code purely for 256-bit integers that is dead code for FSF GCC. > I believe that libgcc support for all existing in-tree ports of gcc is > already complete. We'd be happy to do any libgcc work necessary to make > any testcase work on any existing in-tree gcc port. If you know of any > work that remains to be done, please provide a testcase, and I can > ensure the work is complete. The question is whether someone could just add their own 256-bit port and reasonably expect it to work. And when submitting patches, it's the job of the submitter to make it easy for the reviewer to give them an A - submit a patch series that makes it transparent to the reviewer that any questions they thought up have already been addressed (because they can see relevant testcases added to the testsuite, for example). > Hum, how about this, if you fix __int128 to do it the way you want, then > I will fix __int256 to copy the style that is set by __int128. I'd > rather have them be exactly the same, so that testing for one will more > likely help the other one. I don't have a good idea of a better way to > do this. Longer term, I'd like __int256 to be universally available, > just like long is and just like long long is. We can't do that yet, I > think doing that is premature. Making a type universally available is dangerous because there are ABI implications - the function-calling ABI for a type should be worked out with the ABI maintainers for each relevant architecture rather than just blindly adding it and hoping that what the back end happens to do is a sensible ABI for all other compilers for that architecture to copy. The ABI for complex numbers on some architectures is an awful mess because of just blindly making them universally available without working out ABIs properly.... > If you can sketch out a better incantation for the 128 and 256 bit > support, I can try my hand at improving it. I just don't know any > better form for it. I'd argue that all powers of twos in use by any > port, should be put into machmode.def. I can rip out all TImode > handling, leaving the int128 handling, the TImode code I think is > redundant with the int128 code. Would you like me to do that? I just > don't want to be on the hook when it doesn't work out for someone. I believe I sketched things in July 2011 - I'd guess sorting this out properly and incrementally is on the order of a ten-patch series (each patch being small and clearly safe for existing targets), not a hundred-patch series. For example, I said: * The c_common_type_for_size code using those nodes is suspicious. Front ends shouldn't care about modes like that. Check standard types, otherwise defer to something generic that loops over available types or modes or builds a type as needed. So in that case I'd do the following: * Check standard types, int, signed char, short, long, long long, as at present. * Check a list of __intN types. The list would be target-dependent. Targets supporting __int128 would define a relevant hook to produce the list containing just __int128. Your new target would define it to contain __int128 and __int256. * Check widest_integer_literal_type_node, as at present. * Check for modes, not through globals hardcoded for each mode as at present but through iterating through integer modes. Maybe getting rid of the globals such as intQI_type_node, replacing them by something sized to cover whatever integer modes on the target can be used for integer types and replacing code using those globals by something iterating over integer modes, would be a good first step. It shouldn't be that hard to move on to making the existence of TImode target-specific (I'd guess there would be a common .def file used by all targets that have TImode). -- Joseph S. Myers jos...@codesourcery.com
