On Jul 13, 2012, at 4:21 PM, Joseph S. Myers wrote: > 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.
Anyone that wants to validate my work can trivially do so. They are free to grab any of the OI ports, and turn on scalar OImode, and then test. Because it is trivial to validate it, I have no clue what you mean by impossible. Does that mean that you have no access to an x86_64? I just can't begin to understand what you mean by impossible, can you elaborate? > The question is whether someone could just add their own 256-bit port and > reasonably expect it to work. No, they can not reasonable expect it to work. They are guaranteed that any expectations of goodness are misplaced, I will personally make that guarantee. What they can expect to work, are those things they have tested that work; that's all. The compiler has bugs, that those bugs prevent good code from working. This has always been the case, and will always be the case. I'm a realist, what I can say about the patch is that the compiler will work better with the patch, than without the patch. The patch lies in the direction of goodness, and that it is impossible to get to goodness without either applying the patch, or creating a virtually identical patch. > And when submitting patches, it's the job > of the submitter to make it easy for the reviewer to give them an A I don't see what you all see. For example, you see that it is impossible to validate my work, I only see that it is trivially possible to validate my work. I can't explain the difference in viewpoint. Richard says that the patch introduces wrong-code bugs almost everywhere in the compiler, I only see that it does not. I can't explain the difference. Richard says I expose users to bugs, I see that I do not. I can't explain the difference. I see that you worry that the patch is unsound, I only see that it is not. I can't explain the difference. I see that you want to pend this on libgcc work. I see that there is no benefit to doing that. I can't explain the difference. I see that Richard wants to pend the work on the cont_wide_int work, I see that there is no benefit to doing that. I can't explain the difference. The list is seemingly endless... I don't have a proof the work is sound, and cannot sign up to provide one at this time. I do not have the time at this point to fix all 256-bit bugs in the compiler. I don't have time to add support for all possible future ports of gcc. I don't have time to craft abis for all gcc ports. I don't have time to implement argument passing for all other ports. I don't have time to validate __int256 for you. I don't have time to re-implement __int128 support in the compiler for you. So, are there any other specific actionable things I can do for you to make the patch acceptable?
