On Tue, Nov 26, 2013 at 3:00 PM, Kenneth Zadeck <zad...@naturalbridge.com> wrote: > > On 11/26/2013 08:44 AM, Richard Earnshaw wrote: >> >> On 26/11/13 09:18, Eric Botcazou wrote: >>>> >>>> you are correct - this was an incorrect change. I believe that the >>>> patch below would be correct, but it is impossible to test it because (i >>>> believe) that gcc no longer works if the host_bits_per_wide_int is 32. >>>> I could be wrong about this but if i am correct, what do you want me to >>>> do? >>> >>> While you're right that most mainstream architectures now require a >>> 64-bit >>> HWI, not all of them do according to config.gcc, so I don't think that >>> this >>> path is entirely dead yet. I'll carry out the testing once we agree on >>> the >>> final change. >> >> I'm hoping, once this patch series is in that we might be able to >> migrate the ARM port back to supporting a 32-bit HWI. The driving >> factor behind the original switch was supporting 128-bit constants for >> Neon and these patches should resolve that. >> >> R. > > > Richard, > > I had not realized that you were into self abuse like that. you are > going to have a bad time. I tried this as a way to test the wide-int branch > because if we made hwi be 32bits, then it would trigger the long version of > the implementation wide-int routines. What a disaster!!!! richard sandiford > told me not to try and i ignored him. that was a wasted weekend!!! There > are roadblocks everywhere. i certainly do not have a complete list, > because i gave up after hacking a few things back. But very quickly you > find places like real.[ch] which no longer work because the math that the > dfp people hacked into it no longer works if the hwis are 32 bits. it is > misleading because all of the tests are still there, it is just that the > equations return the wrong answers. It is like this, one place after > another. > > As far as your hope that once this patch goes in you would be able to > support 128 bit constants is only partially true. it will/should be the > case, that you always get the correct answer and the code will not ice. > That is the good news. But the bad news is that there is still way to > much code of the form, if var fits in hwi, do some optimization, else do not > do the optimization. Richi did not want me to attack this code yet because > it would have made the patches even bigger. For the rtl level a lot of > this was removed because i did it before he told me not to, but the tree > level still has tons of code like this. So at least for a long time, like > the close of the next release, this is not going to get fixed.
Note that in the long run we want wide-int to use HOST_WIDEST_FAST_INT and not HOST_WIDE_INT internally. I know I asked you to do that but it's of course too late now. Richard. > Kenny > > > >> >
