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'

Uros.

Reply via email to