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. -- H.J.
