Re: Why is __i686 undefined for x86_64 -m32 (in mainline)

Re: Why is __i686 undefined for x86_64 -m32 (in mainline)

[H.J. Lu]

On Tue, Mar 16, 2010 at 12:32 PM, Paolo Carlini
<paolo.carlini@oracle.com> wrote:
> Hi,
>
> I'm rather surprised that now, in the "sane default world", only __i386 is
> defined, whereas __i686 is not on x86_64 -m32, I need -march=i686 on the
> command line (together with -m32).
>
> I noticed that while analyzing libstdc++/43394, where I was surprised that
> some preprocessor lines, legacy code actually, in the library code for
> parallel mode do not "notice" that we have now a better default:
>
> #elif defined(__GNUC__) && defined(__i386) &&                   \
>   (defined(__i686) || defined(__pentium4) || defined(__athlon))
>     return __sync_fetch_and_add(__ptr, __addend);
>
> ... indeed, such lines want __i686 in order to safely enable the builtin and
> still find it undefined.
>
> If - as it's probably the case - I'm a bit confused about the meaning of
> those __i?86 macros, what people suggest instead? I suspect my
> __GCC_HAVE_SYNC_COMPARE_AND_SWAP_* could be put to good use, still I'm still
> curious about the exact semantics of the __i?86 macros...
>
> Thanks in advance,
> Paolo.

The question is what processor macros should "-march=x86-64" define. There
is

      {"x86-64", PROCESSOR_K8, CPU_K8,
        PTA_64BIT | PTA_MMX | PTA_SSE | PTA_SSE2 | PTA_NO_SAHF},

For -march=x86-64, __k8 is defined.  However, real K8 supports:

      {"k8", PROCESSOR_K8, CPU_K8,
        PTA_64BIT | PTA_MMX | PTA_3DNOW | PTA_3DNOW_A | PTA_SSE
        | PTA_SSE2 | PTA_NO_SAHF},

It isn't an issue in i386.c since PROCESSOR_K8 isn't used to check
ISAs. But using __k8 to check ISAs is a problem.

-- 
H.J.

Re: Why is __i686 undefined for x86_64 -m32 (in mainline)

[Paolo Carlini]

On 03/16/2010 08:53 PM, H.J. Lu wrote:
> The question is what processor macros should "-march=x86-64" define. There
> is
>
>       {"x86-64", PROCESSOR_K8, CPU_K8,
>         PTA_64BIT | PTA_MMX | PTA_SSE | PTA_SSE2 | PTA_NO_SAHF},
>
> For -march=x86-64, __k8 is defined.  However, real K8 supports:
>
>       {"k8", PROCESSOR_K8, CPU_K8,
>         PTA_64BIT | PTA_MMX | PTA_3DNOW | PTA_3DNOW_A | PTA_SSE
>         | PTA_SSE2 | PTA_NO_SAHF},
>
> It isn't an issue in i386.c since PROCESSOR_K8 isn't used to check
> ISAs. But using __k8 to check ISAs is a problem.
>   
I'm not sure to follow the gory details of your reply, but to me, it
seems *really* strange that *now*, on x86_64, "-m32" is not the same as
"-m32 -march=-i686" as far as __i686 is concerned...

Paolo.

Re: Why is __i686 undefined for x86_64 -m32 (in mainline)

[H.J. Lu]

[-- Attachment #1: Type: text/plain, Size: 1030 bytes --]

On Tue, Mar 16, 2010 at 1:13 PM, Paolo Carlini <paolo.carlini@oracle.com> wrote:
> On 03/16/2010 08:53 PM, H.J. Lu wrote:
>> The question is what processor macros should "-march=x86-64" define. There
>> is
>>
>>       {"x86-64", PROCESSOR_K8, CPU_K8,
>>         PTA_64BIT | PTA_MMX | PTA_SSE | PTA_SSE2 | PTA_NO_SAHF},
>>
>> For -march=x86-64, __k8 is defined.  However, real K8 supports:
>>
>>       {"k8", PROCESSOR_K8, CPU_K8,
>>         PTA_64BIT | PTA_MMX | PTA_3DNOW | PTA_3DNOW_A | PTA_SSE
>>         | PTA_SSE2 | PTA_NO_SAHF},
>>
>> It isn't an issue in i386.c since PROCESSOR_K8 isn't used to check
>> ISAs. But using __k8 to check ISAs is a problem.
>>
> I'm not sure to follow the gory details of your reply, but to me, it
> seems *really* strange that *now*, on x86_64, "-m32" is not the same as
> "-m32 -march=-i686" as far as __i686 is concerned...
>

We never defined __i686 for -m32 by default on x86_64. Here is
a patch to define __i686 for -m32 if the processor supports it.

-- 
H.J.

[-- Attachment #2: gcc-isa-1.patch --]
[-- Type: text/plain, Size: 1959 bytes --]

2010-03-16  H.J. Lu  <hongjiu.lu@intel.com>

	* config/i386/i386-c.c (ix86_target_macros_internal): Define
	__i686/__i686__ for PROCESSOR_K8, PROCESSOR_AMDFAM10,
	PROCESSOR_PENTIUM4, PROCESSOR_NOCONA, PROCESSOR_CORE2 and
	PROCESSOR_ATOM.

diff --git a/gcc/config/i386/i386-c.c b/gcc/config/i386/i386-c.c
index 35eab49..f6dad14 100644
--- a/gcc/config/i386/i386-c.c
+++ b/gcc/config/i386/i386-c.c
@@ -100,26 +100,53 @@ ix86_target_macros_internal (int isa_flag,
 	def_or_undef (parse_in, "__athlon_sse__");
       break;
     case PROCESSOR_K8:
+      if (!TARGET_64BIT)
+	{
+	  def_or_undef (parse_in, "__i686");
+	  def_or_undef (parse_in, "__i686__");
+	}
       def_or_undef (parse_in, "__k8");
       def_or_undef (parse_in, "__k8__");
       break;
     case PROCESSOR_AMDFAM10:
+      if (!TARGET_64BIT)
+	{
+	  def_or_undef (parse_in, "__i686");
+	  def_or_undef (parse_in, "__i686__");
+	}
       def_or_undef (parse_in, "__amdfam10");
       def_or_undef (parse_in, "__amdfam10__");
       break;
     case PROCESSOR_PENTIUM4:
+      def_or_undef (parse_in, "__i686");
+      def_or_undef (parse_in, "__i686__");
       def_or_undef (parse_in, "__pentium4");
       def_or_undef (parse_in, "__pentium4__");
       break;
     case PROCESSOR_NOCONA:
+      if (!TARGET_64BIT)
+	{
+	  def_or_undef (parse_in, "__i686");
+	  def_or_undef (parse_in, "__i686__");
+	}
       def_or_undef (parse_in, "__nocona");
       def_or_undef (parse_in, "__nocona__");
       break;
     case PROCESSOR_CORE2:
+      if (!TARGET_64BIT)
+	{
+	  def_or_undef (parse_in, "__i686");
+	  def_or_undef (parse_in, "__i686__");
+	}
       def_or_undef (parse_in, "__core2");
       def_or_undef (parse_in, "__core2__");
       break;
     case PROCESSOR_ATOM:
+      if (!TARGET_64BIT)
+	{
+	  def_or_undef (parse_in, "__i686");
+	  def_or_undef (parse_in, "__i686__");
+	}
       def_or_undef (parse_in, "__atom");
       def_or_undef (parse_in, "__atom__");
       break;

Re: Why is __i686 undefined for x86_64 -m32 (in mainline)

[Paolo Carlini]

On 03/16/2010 09:40 PM, H.J. Lu wrote:
> We never defined __i686 for -m32 by default on x86_64. Here is
> a patch to define __i686 for -m32 if the processor supports it.
>   
If I understand correctly the logic underlying the recent work in this
area, I think we certainly want your patch, because otherwise we have
kind of an inconsistent situation: the i686 facilites *are* available,
but __i686 is undefined.

Maybe the patch should go to gcc-patches to...

Thanks,
Paolo.

Re: Why is __i686 undefined for x86_64 -m32 (in mainline)

[Jakub Jelinek]

On Tue, Mar 16, 2010 at 09:53:30PM +0100, Paolo Carlini wrote:
> On 03/16/2010 09:40 PM, H.J. Lu wrote:
> > We never defined __i686 for -m32 by default on x86_64. Here is
> > a patch to define __i686 for -m32 if the processor supports it.
> >   
> If I understand correctly the logic underlying the recent work in this
> area, I think we certainly want your patch, because otherwise we have
> kind of an inconsistent situation: the i686 facilites *are* available,
> but __i686 is undefined.
> 
> Maybe the patch should go to gcc-patches to...

I don't think it is a good idea to change the meaning of the macros years
after they have been introduced.
You could add a different macro if you want.
Why should be __i686 special?  i686 does have __i586 features too, should it
define also __i586, __i486?  Should __core2 define __pentium4?  Etc., etc.

	Jakub

Re: Why is __i686 undefined for x86_64 -m32 (in mainline)

[Paolo Carlini]

On 03/16/2010 09:58 PM, Jakub Jelinek wrote:
> I don't think it is a good idea to change the meaning of the macros years
> after they have been introduced.
> You could add a different macro if you want.
> Why should be __i686 special?  i686 does have __i586 features too, should it
> define also __i586, __i486? 
Probably it should, in my opinion.

But maybe I'm missing something about the whole logic of the recent
changes: wasn't about having the default for an i686 target similar, if
not identical, to passing by hand -march=i686? I'm really, really
confused... How is people supposed to figure out with macros that the
new default configuration supports everything -march=i686 supports vs
the previous status when it was identical to -march=i386?!?

Paolo.

Re: Why is __i686 undefined for x86_64 -m32 (in mainline)

[H.J. Lu]

On Tue, Mar 16, 2010 at 2:03 PM, Paolo Carlini <paolo.carlini@oracle.com> wrote:
> On 03/16/2010 09:58 PM, Jakub Jelinek wrote:
>> I don't think it is a good idea to change the meaning of the macros years
>> after they have been introduced.
>> You could add a different macro if you want.
>> Why should be __i686 special?  i686 does have __i586 features too, should it
>> define also __i586, __i486?
> Probably it should, in my opinion.
>
> But maybe I'm missing something about the whole logic of the recent
> changes: wasn't about having the default for an i686 target similar, if
> not identical, to passing by hand -march=i686? I'm really, really
> confused... How is people supposed to figure out with macros that the
> new default configuration supports everything -march=i686 supports vs
> the previous status when it was identical to -march=i386?!?
>
> Paolo.
>

Checking __iX86 is a good idea for ISAs since it's meaning isn't well defined
nor enforced.  For libstdc++ purpose, can you check __SSE2__ in addition to
__i686?


-- 
H.J.

Re: Why is __i686 undefined for x86_64 -m32 (in mainline)

[H.J. Lu]

On Tue, Mar 16, 2010 at 2:06 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Tue, Mar 16, 2010 at 2:03 PM, Paolo Carlini <paolo.carlini@oracle.com> wrote:
>> On 03/16/2010 09:58 PM, Jakub Jelinek wrote:
>>> I don't think it is a good idea to change the meaning of the macros years
>>> after they have been introduced.
>>> You could add a different macro if you want.
>>> Why should be __i686 special?  i686 does have __i586 features too, should it
>>> define also __i586, __i486?
>> Probably it should, in my opinion.
>>
>> But maybe I'm missing something about the whole logic of the recent
>> changes: wasn't about having the default for an i686 target similar, if
>> not identical, to passing by hand -march=i686? I'm really, really
>> confused... How is people supposed to figure out with macros that the
>> new default configuration supports everything -march=i686 supports vs
>> the previous status when it was identical to -march=i386?!?
>>
>> Paolo.
>>
>
> Checking __iX86 is a good idea for ISAs since it's meaning isn't well defined

I mean "isn't a good idea".

> nor enforced.  For libstdc++ purpose, can you check __SSE2__ in addition to
> __i686?
>
>
> --
> H.J.
>



-- 
H.J.

Re: Why is __i686 undefined for x86_64 -m32 (in mainline)

[H.J. Lu]

On Tue, Mar 16, 2010 at 1:58 PM, Jakub Jelinek <jakub@redhat.com> wrote:
> On Tue, Mar 16, 2010 at 09:53:30PM +0100, Paolo Carlini wrote:
>> On 03/16/2010 09:40 PM, H.J. Lu wrote:
>> > We never defined __i686 for -m32 by default on x86_64. Here is
>> > a patch to define __i686 for -m32 if the processor supports it.
>> >
>> If I understand correctly the logic underlying the recent work in this
>> area, I think we certainly want your patch, because otherwise we have
>> kind of an inconsistent situation: the i686 facilites *are* available,
>> but __i686 is undefined.
>>
>> Maybe the patch should go to gcc-patches to...
>
> I don't think it is a good idea to change the meaning of the macros years
> after they have been introduced.
> You could add a different macro if you want.
> Why should be __i686 special?  i686 does have __i586 features too, should it
> define also __i586, __i486?  Should __core2 define __pentium4?  Etc., etc.
>

I don't think we should add those at all. i386.c has

 /* For sane SSE instruction set generation we need fcomi instruction.
     It is safe to enable all CMOVE instructions.  */
  if (TARGET_SSE)
    TARGET_CMOVE = 1;

Why not check __SSE__ or __SSE2__?


-- 
H.J.

Re: Why is __i686 undefined for x86_64 -m32 (in mainline)

[Paolo Carlini]

On 03/16/2010 10:08 PM, H.J. Lu wrote:
> I don't think it is a good idea to change the meaning of the macros years
>> after they have been introduced.
>> You could add a different macro if you want.
>> Why should be __i686 special?  i686 does have __i586 features too, should it
>> define also __i586, __i486?  Should __core2 define __pentium4?  Etc., etc.
>>
>>     
> I don't think we should add those at all.
>   
About i586 & co, I see now that you are right.

To recapitulate my point, it just seemed strange to me, that, before and
after the recent changes, __i386 is defined,  whereas __i686 is defined
only if I pass -march=i686. On the other hand, after the recent changes,
which essentially change the default subtarget to -march=i686, __i686 is
not defined by default.

Paolo.

Re: Why is __i686 undefined for x86_64 -m32 (in mainline)

[H.J. Lu]

On Tue, Mar 16, 2010 at 1:14 PM, Paolo Carlini <paolo.carlini@oracle.com> wrote:
> On 03/16/2010 10:08 PM, H.J. Lu wrote:
>> I don't think it is a good idea to change the meaning of the macros years
>>> after they have been introduced.
>>> You could add a different macro if you want.
>>> Why should be __i686 special?  i686 does have __i586 features too, should it
>>> define also __i586, __i486?  Should __core2 define __pentium4?  Etc., etc.
>>>
>>>
>> I don't think we should add those at all.
>>
> About i586 & co, I see now that you are right.
>
> To recapitulate my point, it just seemed strange to me, that, before and
> after the recent changes, __i386 is defined,  whereas __i686 is defined
> only if I pass -march=i686. On the other hand, after the recent changes,
> which essentially change the default subtarget to -march=i686, __i686 is
> not defined by default.
>

That is not true. The new -m32 default ISA on x86-64 is i686 + MMX + SSE + SSE2.
It is Pentium 4, not i686.  For historical reason, we define __k8
instead of __pentium4.


-- 
H.J.

Re: Why is __i686 undefined for x86_64 -m32 (in mainline)

[Paolo Carlini]

On 03/16/2010 10:20 PM, H.J. Lu wrote:
> That is not true. The new -m32 default ISA on x86-64 is i686 + MMX + SSE + SSE2.
> It is Pentium 4, not i686.  For historical reason, we define __k8
> instead of __pentium4.
>   
Ah, ok, this is what I was missing! We have *more* than i686. Thus I can
check for __k8.

Thanks again,
Paolo.

Re: Why is __i686 undefined for x86_64 -m32 (in mainline)

[H.J. Lu]

On Tue, Mar 16, 2010 at 1:30 PM, Paolo Carlini <paolo.carlini@oracle.com> wrote:
> On 03/16/2010 10:20 PM, H.J. Lu wrote:
>> That is not true. The new -m32 default ISA on x86-64 is i686 + MMX + SSE + SSE2.
>> It is Pentium 4, not i686.  For historical reason, we define __k8
>> instead of __pentium4.
>>
> Ah, ok, this is what I was missing! We have *more* than i686. Thus I can
> check for __k8.
>

Please check __SSE__ since __k8 won't be defined for -march=atom.

-- 
H.J.

Re: Why is __i686 undefined for x86_64 -m32 (in mainline)

[Paolo Carlini]

On 03/16/2010 10:33 PM, H.J. Lu wrote:
> Please check __SSE__ since __k8 won't be defined for -march=atom.
I don't care about Atom.

Paolo.

Re: Why is __i686 undefined for x86_64 -m32 (in mainline)

[H.J. Lu]

On Tue, Mar 16, 2010 at 2:36 PM, Paolo Carlini <paolo.carlini@oracle.com> wrote:
> On 03/16/2010 10:33 PM, H.J. Lu wrote:
>> Please check __SSE__ since __k8 won't be defined for -march=atom.
> I don't care about Atom.
>

Do you care about -march=core2?


-- 
H.J.

Re: Why is __i686 undefined for x86_64 -m32 (in mainline)

[Paolo Carlini]

On 03/16/2010 11:27 PM, H.J. Lu wrote:
> Do you care about -march=core2?
Ok, thanks, let's check __core2 too, but really, I don't want to fiddle
too much with these macros in the 4.5.0 timeframe. This is code for
parallel-mode which really is tailored by and large to modern 64-bit
machines. For further enhancements we have libstdc++/34106.

Paolo.

Re: Why is __i686 undefined for x86_64 -m32 (in mainline)

[H.J. Lu]

On Tue, Mar 16, 2010 at 2:32 PM, Paolo Carlini <paolo.carlini@oracle.com> wrote:
> On 03/16/2010 11:27 PM, H.J. Lu wrote:
>> Do you care about -march=core2?
> Ok, thanks, let's check __core2 too, but really, I don't want to fiddle
> too much with these macros in the 4.5.0 timeframe. This is code for
> parallel-mode which really is tailored by and large to modern 64-bit
> machines. For further enhancements we have libstdc++/34106.
>

As I said, you should check __SSE__ and be done with it. Otherwise you
will need to keep adding more checks for no good reasons.


-- 
H.J.

Re: Why is __i686 undefined for x86_64 -m32 (in mainline)

[Paolo Carlini]

On 03/16/2010 11:36 PM, H.J. Lu wrote:
> As I said, you should check __SSE__ and be done with it. Otherwise you
> will need to keep adding more checks for no good reasons.
>   
As I said, that file we'll be reworked *completely* by its maintainers,m
we have another PR for this, and I don't want __SSE__ which by itself
tells me nothing about atomic operations.

Paolo.

Re: Why is __i686 undefined for x86_64 -m32 (in mainline)

[H.J. Lu]

On Tue, Mar 16, 2010 at 3:39 PM, Paolo Carlini <paolo.carlini@oracle.com> wrote:
> On 03/16/2010 11:36 PM, H.J. Lu wrote:
>> As I said, you should check __SSE__ and be done with it. Otherwise you
>> will need to keep adding more checks for no good reasons.
>>
> As I said, that file we'll be reworked *completely* by its maintainers,m
> we have another PR for this, and I don't want __SSE__ which by itself
> tells me nothing about atomic operations.
>

__SSE__/-msse enables i686 ISA. Does i686 ISA support
atomic operations?

-- 
H.J.

Re: Why is __i686 undefined for x86_64 -m32 (in mainline)

[Paolo Carlini]

On 03/17/2010 12:04 AM, H.J. Lu wrote:
> __SSE__/-msse enables i686 ISA. Does i686 ISA support
> atomic operations?
>   
If you are willing to contribute to these issue, please add your
comments to the audit trail of libstdc++/34106 and figure out with
Johannes a good clean-up for 4.6.0 (including a good amount of comments,
of course)

Thanks,
Paolo.

Why is __i686 undefined for x86_64 -m32 (in mainline)

[Paolo Carlini]

Hi,

I'm rather surprised that now, in the "sane default world", only __i386
is defined, whereas __i686 is not on x86_64 -m32, I need -march=i686 on
the command line (together with -m32).

I noticed that while analyzing libstdc++/43394, where I was surprised
that some preprocessor lines, legacy code actually, in the library code
for parallel mode do not "notice" that we have now a better default:

#elif defined(__GNUC__) && defined(__i386) &&                   \
  (defined(__i686) || defined(__pentium4) || defined(__athlon))
    return __sync_fetch_and_add(__ptr, __addend);

... indeed, such lines want __i686 in order to safely enable the builtin
and still find it undefined.

If - as it's probably the case - I'm a bit confused about the meaning of
those __i?86 macros, what people suggest instead? I suspect my
__GCC_HAVE_SYNC_COMPARE_AND_SWAP_* could be put to good use, still I'm
still curious about the exact semantics of the __i?86 macros...

Thanks in advance,
Paolo.