On Fri, May 25, 2012 at 5:27 PM, H.J. Lu <hjl.to...@gmail.com> wrote: > On Fri, May 25, 2012 at 5:16 PM, Sriraman Tallam <tmsri...@google.com> wrote: >> Hi H.J., >> >> On Fri, May 25, 2012 at 5:07 PM, H.J. Lu <hjl.to...@gmail.com> wrote: >>> On Mon, May 14, 2012 at 11:28 AM, Sriraman Tallam <tmsri...@google.com> >>> wrote: >>>> Hi H.J, >>>> >>>> Attaching new patch with 2 test cases, mv2.C checks ISAs only and >>>> mv1.C checks ISAs and arches mixed. Right now, checking only arches is >>>> not needed as they are mutually exclusive, any order should be fine. >>>> >>>> Patch also available for review here: >>>> http://codereview.appspot.com/5752064 >>> >>> Sorry for the delay. It looks OK except for the function order in tescases. >>> I think you should rearrange them so that they are not in the same order >>> as the priority. >> >> I am not sure I understand. The function order is mixed up in the >> declarations, I have explicitly commented about this. I only do the >> checking in order which I must, right? >> >> > > gcc/testsuite/g++.dg/mv2.C has > > int __attribute__ ((target("avx2"))) > foo () > { > return 1; > } > > int __attribute__ ((target("avx"))) > foo () > { > return 2; > } > > int __attribute__ ((target("popcnt"))) > foo () > { > return 3; > } > > int __attribute__ ((target("sse4.2"))) > foo () > { > return 4; > } > > int __attribute__ ((target("sse4.1"))) > foo () > { > return 5; > } > > int __attribute__ ((target("ssse3"))) > foo () > { > return 6; > } > > int __attribute__ ((target("sse3"))) > foo () > { > return 7; > } > > int __attribute__ ((target("sse2"))) > foo () > { > return 8; > } > > int __attribute__ ((target("sse"))) > foo () > { > return 9; > } > > int __attribute__ ((target("mmx"))) > foo () > { > return 10; > } > > It is most in the priority order.
Ah! ok, got it. I kept it that way because it is really the order of the declarations before the call that matter but I will rearrange the definitions too to be clear. > > BTW, I noticed: > > [hjl@gnu-6 pr14170]$ readelf -sW libgcc.a | grep __cpu_model > 20: 0000000000000010 16 OBJECT GLOBAL HIDDEN COM __cpu_model > [hjl@gnu-6 pr14170]$ readelf -sW libgcc_s.so | grep __cpu_model > 82: 0000000000214ff0 16 OBJECT GLOBAL DEFAULT 24 > __cpu_model@@GCC_4.8.0 > 310: 0000000000214ff0 16 OBJECT GLOBAL DEFAULT 24 __cpu_model > [hjl@gnu-6 pr14170]$ > > Why is __cpu_model in both libgcc.a and libgcc_s.o? How do I disallow this in libgcc_s.so? Looks like t-cpuinfo file is wrong but I cannot figure out the fix. Thanks, -Sri. > > > H.J.
