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.
Kenny
