On Tue, Nov 26, 2013 at 3:15 PM, H.J. Lu <hjl.to...@gmail.com> wrote: > On Tue, Nov 26, 2013 at 6:03 AM, <pins...@gmail.com> wrote: >> >> >>> On Nov 26, 2013, at 6:00 AM, "H.J. Lu" <hjl.to...@gmail.com> wrote: >>> >>> On Tue, Nov 26, 2013 at 5:55 AM, Richard Biener >>> <richard.guent...@gmail.com> wrote: >>>> On Tue, Nov 26, 2013 at 2:44 PM, Richard Earnshaw <rearn...@arm.com> 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. >>>> >>>> i?86 would be another candidate (if you don't build a compiler with -m64 >>>> support). >>> >>> Not true for x86 since we have >>> >>> Variable >>> HOST_WIDE_INT ix86_isa_flags = TARGET_64BIT_DEFAULT | >>> TARGET_SUBTARGET_ISA_DEFAULT >>> >>> in i386.opt. We need more than 32 bits for ix86_isa_flags. >> >> Then that should be HOST_WIDEST_INT instead. >> > > Also one function in i386.c generates less optimal > results when HOST_WIDE_INT is 32-bit such that > we were generating different outputs from the same > input on x86 and on x86-64 with -m32.
Well - we knew the code would bitrot once we decided to always default to 64bit HWI ... Richard. > -- > H.J.
