* 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: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 ` 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: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).