* Re: Why is __i686 undefined for x86_64 -m32 (in mainline)
[not found] <4B9FDCC1.2080201@oracle.com>
@ 2010-03-16 20:00 ` H.J. Lu
2010-03-16 20:40 ` Paolo Carlini
0 siblings, 1 reply; 21+ messages in thread
From: H.J. Lu @ 2010-03-16 20:00 UTC (permalink / raw)
To: Paolo Carlini; +Cc: gcc
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.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Why is __i686 undefined for x86_64 -m32 (in mainline)
2010-03-16 20:00 ` Why is __i686 undefined for x86_64 -m32 (in mainline) H.J. Lu
@ 2010-03-16 20:40 ` Paolo Carlini
2010-03-16 20:53 ` H.J. Lu
0 siblings, 1 reply; 21+ messages in thread
From: Paolo Carlini @ 2010-03-16 20:40 UTC (permalink / raw)
To: H.J. Lu; +Cc: gcc, Jason Merrill
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.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Why is __i686 undefined for x86_64 -m32 (in mainline)
2010-03-16 20:40 ` Paolo Carlini
@ 2010-03-16 20:53 ` H.J. Lu
2010-03-16 20:58 ` Paolo Carlini
0 siblings, 1 reply; 21+ messages in thread
From: H.J. Lu @ 2010-03-16 20:53 UTC (permalink / raw)
To: Paolo Carlini; +Cc: gcc, Jason Merrill
[-- 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;
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Why is __i686 undefined for x86_64 -m32 (in mainline)
2010-03-16 20:53 ` H.J. Lu
@ 2010-03-16 20:58 ` Paolo Carlini
2010-03-16 21:03 ` Jakub Jelinek
0 siblings, 1 reply; 21+ messages in thread
From: Paolo Carlini @ 2010-03-16 20:58 UTC (permalink / raw)
To: H.J. Lu; +Cc: gcc, Jason Merrill
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.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Why is __i686 undefined for x86_64 -m32 (in mainline)
2010-03-16 20:58 ` Paolo Carlini
@ 2010-03-16 21:03 ` Jakub Jelinek
2010-03-16 21:06 ` Paolo Carlini
2010-03-16 21:15 ` H.J. Lu
0 siblings, 2 replies; 21+ messages in thread
From: Jakub Jelinek @ 2010-03-16 21:03 UTC (permalink / raw)
To: Paolo Carlini; +Cc: H.J. Lu, gcc, Jason Merrill
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
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Why is __i686 undefined for x86_64 -m32 (in mainline)
2010-03-16 21:06 ` Paolo Carlini
@ 2010-03-16 21:06 ` H.J. Lu
2010-03-16 21:08 ` H.J. Lu
0 siblings, 1 reply; 21+ messages in thread
From: H.J. Lu @ 2010-03-16 21:06 UTC (permalink / raw)
To: Paolo Carlini; +Cc: Jakub Jelinek, gcc, Jason Merrill
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.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Why is __i686 undefined for x86_64 -m32 (in mainline)
2010-03-16 21:03 ` Jakub Jelinek
@ 2010-03-16 21:06 ` Paolo Carlini
2010-03-16 21:06 ` H.J. Lu
2010-03-16 21:15 ` H.J. Lu
1 sibling, 1 reply; 21+ messages in thread
From: Paolo Carlini @ 2010-03-16 21:06 UTC (permalink / raw)
To: Jakub Jelinek; +Cc: H.J. Lu, gcc, Jason Merrill
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.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Why is __i686 undefined for x86_64 -m32 (in mainline)
2010-03-16 21:06 ` H.J. Lu
@ 2010-03-16 21:08 ` H.J. Lu
0 siblings, 0 replies; 21+ messages in thread
From: H.J. Lu @ 2010-03-16 21:08 UTC (permalink / raw)
To: Paolo Carlini; +Cc: Jakub Jelinek, gcc, Jason Merrill
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.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Why is __i686 undefined for x86_64 -m32 (in mainline)
2010-03-16 21:03 ` Jakub Jelinek
2010-03-16 21:06 ` Paolo Carlini
@ 2010-03-16 21:15 ` H.J. Lu
2010-03-16 21:21 ` Paolo Carlini
1 sibling, 1 reply; 21+ messages in thread
From: H.J. Lu @ 2010-03-16 21:15 UTC (permalink / raw)
To: Jakub Jelinek; +Cc: Paolo Carlini, gcc, Jason Merrill
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.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Why is __i686 undefined for x86_64 -m32 (in mainline)
2010-03-16 21:15 ` H.J. Lu
@ 2010-03-16 21:21 ` Paolo Carlini
2010-03-16 21:31 ` H.J. Lu
0 siblings, 1 reply; 21+ messages in thread
From: Paolo Carlini @ 2010-03-16 21:21 UTC (permalink / raw)
To: H.J. Lu; +Cc: Jakub Jelinek, gcc, Jason Merrill
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.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Why is __i686 undefined for x86_64 -m32 (in mainline)
2010-03-16 21:21 ` Paolo Carlini
@ 2010-03-16 21:31 ` H.J. Lu
2010-03-16 21:34 ` Paolo Carlini
0 siblings, 1 reply; 21+ messages in thread
From: H.J. Lu @ 2010-03-16 21:31 UTC (permalink / raw)
To: Paolo Carlini; +Cc: Jakub Jelinek, gcc, Jason Merrill
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.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Why is __i686 undefined for x86_64 -m32 (in mainline)
2010-03-16 21:31 ` H.J. Lu
@ 2010-03-16 21:34 ` Paolo Carlini
2010-03-16 21:36 ` H.J. Lu
0 siblings, 1 reply; 21+ messages in thread
From: Paolo Carlini @ 2010-03-16 21:34 UTC (permalink / raw)
To: H.J. Lu; +Cc: Jakub Jelinek, gcc, Jason Merrill
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.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Why is __i686 undefined for x86_64 -m32 (in mainline)
2010-03-16 21:34 ` Paolo Carlini
@ 2010-03-16 21:36 ` H.J. Lu
2010-03-16 22:27 ` Paolo Carlini
0 siblings, 1 reply; 21+ messages in thread
From: H.J. Lu @ 2010-03-16 21:36 UTC (permalink / raw)
To: Paolo Carlini; +Cc: Jakub Jelinek, gcc, Jason Merrill
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.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Why is __i686 undefined for x86_64 -m32 (in mainline)
2010-03-16 21:36 ` H.J. Lu
@ 2010-03-16 22:27 ` Paolo Carlini
2010-03-16 22:32 ` H.J. Lu
0 siblings, 1 reply; 21+ messages in thread
From: Paolo Carlini @ 2010-03-16 22:27 UTC (permalink / raw)
To: H.J. Lu; +Cc: Jakub Jelinek, gcc, Jason Merrill
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.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Why is __i686 undefined for x86_64 -m32 (in mainline)
2010-03-16 22:27 ` Paolo Carlini
@ 2010-03-16 22:32 ` H.J. Lu
2010-03-16 22:36 ` Paolo Carlini
0 siblings, 1 reply; 21+ messages in thread
From: H.J. Lu @ 2010-03-16 22:32 UTC (permalink / raw)
To: Paolo Carlini; +Cc: Jakub Jelinek, gcc, Jason Merrill
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.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Why is __i686 undefined for x86_64 -m32 (in mainline)
2010-03-16 22:32 ` H.J. Lu
@ 2010-03-16 22:36 ` Paolo Carlini
2010-03-16 22:39 ` H.J. Lu
0 siblings, 1 reply; 21+ messages in thread
From: Paolo Carlini @ 2010-03-16 22:36 UTC (permalink / raw)
To: H.J. Lu; +Cc: gcc
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.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Why is __i686 undefined for x86_64 -m32 (in mainline)
2010-03-16 22:36 ` Paolo Carlini
@ 2010-03-16 22:39 ` H.J. Lu
2010-03-16 22:57 ` Paolo Carlini
0 siblings, 1 reply; 21+ messages in thread
From: H.J. Lu @ 2010-03-16 22:39 UTC (permalink / raw)
To: Paolo Carlini; +Cc: gcc
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.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Why is __i686 undefined for x86_64 -m32 (in mainline)
2010-03-16 22:39 ` H.J. Lu
@ 2010-03-16 22:57 ` Paolo Carlini
2010-03-16 23:11 ` H.J. Lu
0 siblings, 1 reply; 21+ messages in thread
From: Paolo Carlini @ 2010-03-16 22:57 UTC (permalink / raw)
To: H.J. Lu; +Cc: gcc
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.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Why is __i686 undefined for x86_64 -m32 (in mainline)
2010-03-16 22:57 ` Paolo Carlini
@ 2010-03-16 23:11 ` H.J. Lu
2010-03-17 3:27 ` Paolo Carlini
0 siblings, 1 reply; 21+ messages in thread
From: H.J. Lu @ 2010-03-16 23:11 UTC (permalink / raw)
To: Paolo Carlini; +Cc: gcc
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.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Why is __i686 undefined for x86_64 -m32 (in mainline)
2010-03-16 23:11 ` H.J. Lu
@ 2010-03-17 3:27 ` Paolo Carlini
0 siblings, 0 replies; 21+ messages in thread
From: Paolo Carlini @ 2010-03-17 3:27 UTC (permalink / raw)
To: H.J. Lu; +Cc: gcc
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.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Why is __i686 undefined for x86_64 -m32 (in mainline)
@ 2010-03-16 19:53 Paolo Carlini
0 siblings, 0 replies; 21+ messages in thread
From: Paolo Carlini @ 2010-03-16 19:53 UTC (permalink / raw)
To: 'gcc@gcc.gnu.org', H.J. Lu
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.
^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2010-03-16 23:11 UTC | newest]
Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <4B9FDCC1.2080201@oracle.com>
2010-03-16 20:00 ` Why is __i686 undefined for x86_64 -m32 (in mainline) H.J. Lu
2010-03-16 20:40 ` Paolo Carlini
2010-03-16 20:53 ` H.J. Lu
2010-03-16 20:58 ` Paolo Carlini
2010-03-16 21:03 ` Jakub Jelinek
2010-03-16 21:06 ` Paolo Carlini
2010-03-16 21:06 ` H.J. Lu
2010-03-16 21:08 ` H.J. Lu
2010-03-16 21:15 ` H.J. Lu
2010-03-16 21:21 ` Paolo Carlini
2010-03-16 21:31 ` H.J. Lu
2010-03-16 21:34 ` Paolo Carlini
2010-03-16 21:36 ` H.J. Lu
2010-03-16 22:27 ` Paolo Carlini
2010-03-16 22:32 ` H.J. Lu
2010-03-16 22:36 ` Paolo Carlini
2010-03-16 22:39 ` H.J. Lu
2010-03-16 22:57 ` Paolo Carlini
2010-03-16 23:11 ` H.J. Lu
2010-03-17 3:27 ` Paolo Carlini
2010-03-16 19:53 Paolo Carlini
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).