Re: [PATCH] Don't build 32-bit libatomic with -march=i486 on x86-64

[Uros Bizjak]

On Mon, Apr 25, 2016 at 11:50 AM, Uros Bizjak  wrote:
> On Mon, Apr 25, 2016 at 11:46 AM, Bernd Schmidt  wrote:
>> On 04/20/2016 04:57 PM, H.J. Lu wrote:
>>>
>>> On Wed, Apr 20, 2016 at 7:54 AM, Jakub Jelinek  wrote:
>
> https://gcc.gnu.org/ml/gcc-patches/2016-04/msg01080.html


 This is wrong, see my other comment on the libgomp patch.

>>> See my reply to your reply on the libgomp patch.
>>
>>
>> Since Jakub has said it is wrong, please revert.
>
> I agree.

(sent the message too fast...)

These patches obviously need some more discussion.

Uros.

Re: [PATCH] Don't build 32-bit libatomic with -march=i486 on x86-64

[Uros Bizjak]

On Mon, Apr 25, 2016 at 11:46 AM, Bernd Schmidt  wrote:
> On 04/20/2016 04:57 PM, H.J. Lu wrote:
>>
>> On Wed, Apr 20, 2016 at 7:54 AM, Jakub Jelinek  wrote:

 https://gcc.gnu.org/ml/gcc-patches/2016-04/msg01080.html
>>>
>>>
>>> This is wrong, see my other comment on the libgomp patch.
>>>
>> See my reply to your reply on the libgomp patch.
>
>
> Since Jakub has said it is wrong, please revert.

I agree.

Uros.

Re: [PATCH] Don't build 32-bit libatomic with -march=i486 on x86-64

[Bernd Schmidt]

On 04/20/2016 04:57 PM, H.J. Lu wrote:

On Wed, Apr 20, 2016 at 7:54 AM, Jakub Jelinek  wrote:

https://gcc.gnu.org/ml/gcc-patches/2016-04/msg01080.html


This is wrong, see my other comment on the libgomp patch.


See my reply to your reply on the libgomp patch.


Since Jakub has said it is wrong, please revert.


Bernd

Re: [PATCH] Don't build 32-bit libatomic with -march=i486 on x86-64

[Jakub Jelinek]

On Wed, Apr 20, 2016 at 07:45:44AM -0700, H.J. Lu wrote:
> On Wed, Apr 20, 2016 at 12:02 AM, Uros Bizjak  wrote:
> >>
> >> 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.
> >
> 
> This is the patch I checked in.  I also updated patches for libgomp:
> 
> https://gcc.gnu.org/ml/gcc-patches/2016-04/msg01079.html
> 
> and libitm:
> 
> https://gcc.gnu.org/ml/gcc-patches/2016-04/msg01080.html

This is wrong, see my other comment on the libgomp patch.

>   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..49233a4 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
> + # x86_64 compiler passes -march=x86_64 by default when building
> + # 32bit target libraries.
>   ARCH=x86
>   # ??? Detect when -mcx16 is already enabled.
>   try_ifunc=yes


Jakub

Re: [PATCH] Don't build 32-bit libatomic with -march=i486 on x86-64

[H.J. Lu]

On Wed, Apr 20, 2016 at 7:54 AM, Jakub Jelinek  wrote:
> On Wed, Apr 20, 2016 at 07:45:44AM -0700, H.J. Lu wrote:
>> On Wed, Apr 20, 2016 at 12:02 AM, Uros Bizjak  wrote:
>> >>
>> >> 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.
>> >
>>
>> This is the patch I checked in.  I also updated patches for libgomp:
>>
>> https://gcc.gnu.org/ml/gcc-patches/2016-04/msg01079.html
>>
>> and libitm:
>>
>> https://gcc.gnu.org/ml/gcc-patches/2016-04/msg01080.html
>
> This is wrong, see my other comment on the libgomp patch.
>

See my reply to your reply on the libgomp patch.


-- 
H.J.

Re: [PATCH] Don't build 32-bit libatomic with -march=i486 on x86-64

[H.J. Lu]

On Wed, Apr 20, 2016 at 12:02 AM, Uros Bizjak  wrote:
>>
>> 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.
>

This is the patch I checked in.  I also updated patches for libgomp:

https://gcc.gnu.org/ml/gcc-patches/2016-04/msg01079.html

and libitm:

https://gcc.gnu.org/ml/gcc-patches/2016-04/msg01080.html

Thanks.

-- 
H.J.
From bafad333cdf4125bf245e05d82df824ffb62c9d5 Mon Sep 17 00:00:00 2001
From: "H.J. Lu" 
Date: Wed, 30 Mar 2016 05:51:28 -0700
Subject: [PATCH 1/3] Don't build 32-bit libatomic with -march=i486 on x86-64

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.

	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..49233a4 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
+	# x86_64 compiler passes -march=x86_64 by default when building
+	# 32bit target libraries.
 	ARCH=x86
 	# ??? Detect when -mcx16 is already enabled.
 	try_ifunc=yes
-- 
2.5.5

Re: [PATCH] Don't build 32-bit libatomic with -march=i486 on x86-64

[Uros Bizjak]

On Tue, Apr 19, 2016 at 8:36 PM, H.J. Lu  wrote:
> On Tue, Apr 19, 2016 at 11:30 AM, Uros Bizjak  wrote:
>> On Tue, Apr 19, 2016 at 8:24 PM, H.J. Lu  wrote:
>>> On Tue, Apr 19, 2016 at 11:18 AM, Uros Bizjak  wrote:
 On Tue, Apr 19, 2016 at 8:08 PM, H.J. Lu  wrote:
> On Tue, Apr 19, 2016 at 8:45 AM, Uros Bizjak  wrote:
>> On Tue, Apr 19, 2016 at 5:07 PM, H.J. Lu  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.

Re: [PATCH] Don't build 32-bit libatomic with -march=i486 on x86-64

[H.J. Lu]

On Tue, Apr 19, 2016 at 11:30 AM, Uros Bizjak  wrote:
> On Tue, Apr 19, 2016 at 8:24 PM, H.J. Lu  wrote:
>> On Tue, Apr 19, 2016 at 11:18 AM, Uros Bizjak  wrote:
>>> On Tue, Apr 19, 2016 at 8:08 PM, H.J. Lu  wrote:
 On Tue, Apr 19, 2016 at 8:45 AM, Uros Bizjak  wrote:
> On Tue, Apr 19, 2016 at 5:07 PM, H.J. Lu  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


-- 
H.J.

Re: [PATCH] Don't build 32-bit libatomic with -march=i486 on x86-64

[Uros Bizjak]

On Tue, Apr 19, 2016 at 8:24 PM, H.J. Lu  wrote:
> On Tue, Apr 19, 2016 at 11:18 AM, Uros Bizjak  wrote:
>> On Tue, Apr 19, 2016 at 8:08 PM, H.J. Lu  wrote:
>>> On Tue, Apr 19, 2016 at 8:45 AM, Uros Bizjak  wrote:
 On Tue, Apr 19, 2016 at 5:07 PM, H.J. Lu  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.

Re: [PATCH] Don't build 32-bit libatomic with -march=i486 on x86-64

[H.J. Lu]

On Tue, Apr 19, 2016 at 11:18 AM, Uros Bizjak  wrote:
> On Tue, Apr 19, 2016 at 8:08 PM, H.J. Lu  wrote:
>> On Tue, Apr 19, 2016 at 8:45 AM, Uros Bizjak  wrote:
>>> On Tue, Apr 19, 2016 at 5:07 PM, H.J. Lu  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

-- 
H.J.

Re: [PATCH] Don't build 32-bit libatomic with -march=i486 on x86-64

[Uros Bizjak]

On Tue, Apr 19, 2016 at 8:08 PM, H.J. Lu  wrote:
> On Tue, Apr 19, 2016 at 8:45 AM, Uros Bizjak  wrote:
>> On Tue, Apr 19, 2016 at 5:07 PM, H.J. Lu  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

Uros.

Re: [PATCH] Don't build 32-bit libatomic with -march=i486 on x86-64

[H.J. Lu]

On Tue, Apr 19, 2016 at 8:45 AM, Uros Bizjak  wrote:
> On Tue, Apr 19, 2016 at 5:07 PM, H.J. Lu  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

-- 
H.J.

Re: [PATCH] Don't build 32-bit libatomic with -march=i486 on x86-64

[Uros Bizjak]

On Tue, Apr 19, 2016 at 5:07 PM, H.J. Lu  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

$ /ssd/uros/gcc-build/gcc/cc1 -E -dM -m32 hello.c > aaa

and

$ /ssd/uros/gcc-build/gcc/cc1 -E -dM -m32 -march=i486 hello.c > bbb

is substantial:
--- aaa 2016-04-19 17:44:08.798432467 +0200
+++ bbb 2016-04-19 17:44:16.078351225 +0200
@@ -12,12 +12,15 @@
 #define __ORDER_LITTLE_ENDIAN__ 1234
 #define __SIZE_MAX__ 0xU
 #define __WCHAR_MAX__ 0x7fffL
+#define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_1 1
+#define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_2 1
+#define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4 1
 #define __DBL_DENORM_MIN__ ((double)4.94065645841246544177e-324L)
-#define __GCC_ATOMIC_CHAR_LOCK_FREE 1
+#define __GCC_ATOMIC_CHAR_LOCK_FREE 2
 #define __GCC_IEC_559 2
 #define __FLT_EVAL_METHOD__ 2
 #define __unix__ 1
-#define __GCC_ATOMIC_CHAR32_T_LOCK_FREE 1
+#define __GCC_ATOMIC_CHAR32_T_LOCK_FREE 2
 #define __UINT_FAST64_MAX__ 0xULL
 #define __SIG_ATOMIC_TYPE__ int
 #define __DBL_MIN_10_EXP__ (-307)
@@ -31,7 +34,7 @@
 #define __SHRT_MAX__ 0x7fff
 #define __LDBL_MAX__ 1.18973149535723176502e+4932L
 #define __UINT_LEAST8_MAX__ 0xff
-#define __GCC_ATOMIC_BOOL_LOCK_FREE 1
+#define __GCC_ATOMIC_BOOL_LOCK_FREE 2
 #define __UINTMAX_TYPE__ long long unsigned int
 #define __linux 1
 #define __DEC32_EPSILON__ 1E-6DF
@@ -44,7 +47,7 @@
 #define __WCHAR_MIN__ (-__WCHAR_MAX__ - 1)
 #define __INT64_C(c) c ## LL
 #define __DBL_DIG__ 15
-#define __GCC_ATOMIC_POINTER_LOCK_FREE 1
+#define __GCC_ATOMIC_POINTER_LOCK_FREE 2
 #define __SIZEOF_INT__ 4
 #define __SIZEOF_POINTER__ 4
 #define __USER_LABEL_PREFIX__
@@ -80,6 +83,7 @@
 #define __DEC128_EPSILON__ 1E-33DL
 #define __ATOMIC_HLE_RELEASE 131072
 #define __PTRDIFF_MAX__ 0x7fff
+#define __tune_i486__ 1
 #define __STDC_NO_THREADS__ 1
 #define __ATOMIC_HLE_ACQUIRE 65536
 #define __LONG_LONG_MAX__ 0x7fffLL
@@ -102,7 +106,7 @@
 #define __VERSION__ "7.0.0 20160419 (experimental) [trunk revision 235206]"
 #define __UINT64_C(c) c ## ULL
 #define _STDC_PREDEF_H 1
-#define __GCC_ATOMIC_INT_LOCK_FREE 1
+#define __GCC_ATOMIC_INT_LOCK_FREE 2
 #define __FLOAT_WORD_ORDER__ __ORDER_LITTLE_ENDIAN__
 #define __STDC_IEC_559_COMPLEX__ 1
 #define __INT32_C(c) c
@@ -111,6 +115,7 @@
 #define __DEC128_MIN_EXP__ (-6142)
 #define __code_model_32__ 1
 #define __INT_FAST32_TYPE__ int
+#define __i486__ 1
 #define __UINT_LEAST16_TYPE__ short unsigned int
 #define unix 1
 #define __INT16_MAX__ 0x7fff
@@ -125,7 +130,7 @@
 #define __LDBL_EPSILON__ 1.08420217248550443401e-19L
 #define __UINTMAX_C(c) c ## ULL
 #define __SIG_ATOMIC_MAX__ 0x7fff
-#define __GCC_ATOMIC_WCHAR_T_LOCK_FREE 1
+#define __GCC_ATOMIC_WCHAR_T_LOCK_FREE 2
 #define __SIZEOF_PTRDIFF_T__ 4
 #define __DEC32_SUBNORMAL_MIN__ 0.01E-95DF
 #define __INT_FAST16_MAX__ 0x7fff
@@ -146,7 +151,7 @@
 #define __INT64_MAX__ 0x7fffLL
 #define __UINT_LEAST32_MAX__ 0xU
 #define __SEG_GS 1
-#define __GCC_ATOMIC_LONG_LOCK_FREE 1
+#define __GCC_ATOMIC_LONG_LOCK_FREE 2
 #define __INT_LEAST64_TYPE__ long long int
 #define __INT16_TYPE__ short int
 #define __INT_LEAST8_TYPE__ signed char
@@ -169,12 +174,13 @@
 #define __FLT_DIG__ 6
 #define __UINT_FAST64_TYPE__ long long unsigned int
 #define __INT_MAX__ 0x7fff
+#define __i486 1
 #define __INT64_TYPE__ long long int
 #define __FLT_MAX_EXP__ 128
 #define __DBL_MANT_DIG__ 53
 #define __SIZEOF_FLOAT128__ 16
 #define __INT_LEAST64_MAX__ 0x7fffLL
-#define __GCC_ATOMIC_CHAR16_T_LOCK_FREE 1
+#define __GCC_ATOMIC_CHAR16_T_LOCK_FREE 2
 #define __DEC64_MIN__ 1E-383DD
 #define __WINT_TYPE__ unsigned int
 #define __UINT_LEAST32_TYPE__ unsigned int
@@ -228,7 +234,7 @@
 #define __LDBL_DIG__ 18
 #define 

[PATCH] Don't build 32-bit libatomic with -march=i486 on x86-64

[H.J. Lu]

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