On Tue, Apr 19, 2016 at 8:36 PM, H.J. Lu <hjl.to...@gmail.com> wrote:
> On Tue, Apr 19, 2016 at 11:30 AM, Uros Bizjak <ubiz...@gmail.com> wrote:
>> On Tue, Apr 19, 2016 at 8:24 PM, H.J. Lu <hjl.to...@gmail.com> wrote:
>>> On Tue, Apr 19, 2016 at 11:18 AM, Uros Bizjak <ubiz...@gmail.com> wrote:
>>>> On Tue, Apr 19, 2016 at 8:08 PM, H.J. Lu <hjl.to...@gmail.com> wrote:
>>>>> On Tue, Apr 19, 2016 at 8:45 AM, Uros Bizjak <ubiz...@gmail.com> wrote:
>>>>>> On Tue, Apr 19, 2016 at 5:07 PM, H.J. Lu <hongjiu...@intel.com> wrote:
>>>>>>> Gcc uses the same -march= for both -m32 and -m64 on x86-64 unless
>>>>>>> --with-arch-32= is used. There is no need for -march=i486 to compile
>>>>>>> 32-bit libatomic on x86-64.
>>>>>>>
>>>>>>> Tested on x86-64. OK for trunk?
>>>>>>>
>>>>>>> H.J.
>>>>>>> ---
>>>>>>> PR target/70454
>>>>>>> * configure.tgt (XCFLAGS): Don't add -march=i486 to compile
>>>>>>> 32-bit x86 target library on x86-64.
>>>>>>> ---
>>>>>>> libatomic/configure.tgt | 10 ++--------
>>>>>>> 1 file changed, 2 insertions(+), 8 deletions(-)
>>>>>>>
>>>>>>> diff --git a/libatomic/configure.tgt b/libatomic/configure.tgt
>>>>>>> index c5470d7..bbb93fc 100644
>>>>>>> --- a/libatomic/configure.tgt
>>>>>>> +++ b/libatomic/configure.tgt
>>>>>>> @@ -81,14 +81,8 @@ case "${target_cpu}" in
>>>>>>> try_ifunc=yes
>>>>>>> ;;
>>>>>>> x86_64)
>>>>>>> - case " ${CC} ${CFLAGS} " in
>>>>>>> - *" -m32 "*)
>>>>>>> - XCFLAGS="${XCFLAGS} -march=i486 -mtune=generic"
>>>>>>> - XCFLAGS="${XCFLAGS} -fomit-frame-pointer"
>>>>>>> - ;;
>>>>>>> - *)
>>>>>>> - ;;
>>>>>>> - esac
>>>>>>> + # Since 64-bit arch > i486, we can use the same -march= to build
>>>>>>> + # both 32-bit and 64-bit target libraries.
>>>>>>> ARCH=x86
>>>>>>> # ??? Detect when -mcx16 is already enabled.
>>>>>>> try_ifunc=yes
>>>>>>> --
>>>>>>> 2.5.5
>>>>>>>
>>>>>>
>>>>>> No, this is wrong. My build with default options defaults to i386. So,
>>>>>> the difference between
>>>>>>
>>>>>
>>>>> How was your GCC configured? Did you use
>>>>>
>>>>> --with-arch_32=i386
>>>>
>>>> Nope, just:
>>>>
>>>> ~/gcc-svn/trunk/configure
>>>>
>>>
>>> $ /ssd/uros/gcc-build/gcc/cc1 -E -dM -m32 hello.c > aaa
>>>
>>> I don't think cc1 is supposed to be used directly. Can you use gcc
>>> driver instead, like
>>>
>>> $ /ssd/uros/gcc-build/gcc/xgcc -B/ssd/uros/gcc-build/gcc/ -E -dM -m32
>>> hello.c
>>
>> This works, since the driver passes:
>>
>> COLLECT_GCC_OPTIONS='-B' '/ssd/uros/gcc-build/gcc/' '-E' '-dM' '-m32'
>> '-mtune=generic' '-march=x86-64'
>>
>
> That is why I submitted my patches. Since -m32 passes -march=x86-64
> to cc1 on x86-64, we shouldn't pass -march=i486 to cc1. It is undesirable
> especially when --with-arch= is used. I noticed the issue when 32-bit
> libatomic/libgomp/libitm weren't optimized with -march=haswell when GCC
> was configured with --with-arch=haswell
OK then. IMO, following comment is more informative:
# x86_64 compiler passes -march=x86_64 by default when building 32bit
target libraries.
>>>>>>> + # Since 64-bit arch > i486, we can use the same -march= to build
>>>>>>> + # both 32-bit and 64-bit target libraries.
OK with the above change.
Thanks,
Uros.
