Right, that would be expected. The easiest thing to do is make sure that you're running cmake in your build area with
-DLLVM_TARGETS_TO_BUILD="all" then you can build "llc" and "clang" , then update your path so that the freshly built llc/clang are picked up first. Once you have that set up, it should take care of the problem running "llc" from capture-fcn-attributes. Than On Wed, Jan 6, 2021 at 3:14 PM Ivan Serdyuk <local.tourist.k...@gmail.com> wrote: > I think a caught an error: > > $ ./capture-fcn-attributes >> llc run failed: llc: error: : error: unable to get target for >> 'aarch64-unknown-linux-gnu', see --version and --triple. >> >> capture-fcn-attributes: err = exit status 1 >> > > . Hence that I didn't compile Aarch64 back-end, for LLVM: > > $ llc --version >> LLVM (http://llvm.org/): >> LLVM version 12.0.0git >> Optimized build. >> Default target: i686-pc-linux-gnu >> Host CPU: yonah >> >> Registered Targets: >> x86 - 32-bit X86: Pentium-Pro and above >> x86-64 - 64-bit X86: EM64T and AMD64 >> > . So this would not run out-of-the-box. > > > > On Wed, Jan 6, 2021 at 8:21 PM Than McIntosh <th...@google.com> wrote: > >> Thanks. The error you're seeing >> >> "unable to determine target CPU features for target i686-pc-linux-gnu" >> >> looks as though it's because i686-pc-linux-gnu isn't listed as a target in >> driver/ArchCpusAttrs.h. >> >> From the root of your repo, try >> >> $ cd tools >> $ go build capture-fcn-attributes.go >> $ ./capture-fcn-attributes -o ../driver/ArchCpusAttrs.h >> >> and then give the gollvm build another try. >> >> Thanks, Than >> >> On Wed, Jan 6, 2021 at 12:53 PM Ivan Serdyuk < >> local.tourist.k...@gmail.com> wrote: >> >>> Here you go: >>> >>> ~/Desktop/workarea/llvm-project/llvm/tools/gollvm$ git diff >>> diff --git a/cmake/modules/AutoGenGo.cmake >>> b/cmake/modules/AutoGenGo.cmake >>> index 3e3ab83..097a2ad 100644 >>> --- a/cmake/modules/AutoGenGo.cmake >>> +++ b/cmake/modules/AutoGenGo.cmake >>> @@ -51,6 +51,17 @@ function(mkversion goos goarch outfile bindir srcroot >>> scriptroot) >>> set(pcquantum "1") >>> set(int64align "8") >>> set(minframesize 0) >>> + elseif( ${goarch} STREQUAL "386") >>> + # Simply picking up one typical setting >>> + # Align with current sets in gofrontend/libgo/goarch.sh >>> + set(archfamily "I386") >>> + set(bigendian "false") >>> + set(cachelinesize "64") >>> + set(physpagesize "4096") >>> + set(pcquantum "1") >>> + set(int64align "4") >>> + set(minframesize 4) >>> + set(ptrsize 4) >>> elseif( ${goarch} STREQUAL "arm64") >>> # Simply picking up one typical setting >>> # Align with current sets in gofrontend/libgo/goarch.sh >>> diff --git a/cmake/modules/GoVars.cmake b/cmake/modules/GoVars.cmake >>> index ec6f6b2..0cea38a 100644 >>> --- a/cmake/modules/GoVars.cmake >>> +++ b/cmake/modules/GoVars.cmake >>> @@ -8,6 +8,9 @@ list(GET lht_components 2 goos) >>> # LLVM's "x86_64" is the same as Go's "amd64". >>> if( ${llarch} STREQUAL "x86_64" ) >>> set(goarch "amd64") >>> +# For i386/i686 >>> +elseif( ${llarch} STREQUAL "i686" ) >>> + set(goarch "386") >>> # LLVM's "aarch64" is the same as Go's "arm64". >>> elseif( ${llarch} STREQUAL "aarch64" ) >>> set(goarch "arm64") >>> @@ -23,6 +26,10 @@ set(allgoos "aix" "android" "darwin" "dragonfly" >>> "freebsd" "irix" "linux" "netbs >>> # Set library suffix based on target triple >>> if( ${llarch} STREQUAL "x86_64" ) >>> set(library_suffix "64") >>> +elseif( ${llarch} STREQUAL "i686" ) >>> +# Driver::installedLibDir honors ./lib only, on Ubuntu 16 >>> +# But we can stick for ./lib32 (along with those in AddGollvm.cmake) >>> + set(library_suffix "32") >>> elseif( ${llarch} STREQUAL "aarch64" ) >>> # Driver::installedLibDir honors ./lib64 only >>> # Future change needed (along with those in AddGollvm.cmake) >>> diff --git a/cmake/modules/LibbacktraceUtils.cmake >>> b/cmake/modules/LibbacktraceUtils.cmake >>> index dc54f18..42287a9 100644 >>> --- a/cmake/modules/LibbacktraceUtils.cmake >>> +++ b/cmake/modules/LibbacktraceUtils.cmake >>> @@ -8,6 +8,9 @@ function(setup_libbacktrace) >>> if( ${goarch} STREQUAL "amd64") >>> set(BACKTRACE_ELF_SIZE 64) >>> set(HAVE_GETIPINFO 1) >>> + elseif( ${goarch} STREQUAL "386") >>> + set(BACKTRACE_ELF_SIZE 32) >>> + set(HAVE_GETIPINFO 1) >>> elseif( ${goarch} STREQUAL "arm64") >>> set(BACKTRACE_ELF_SIZE 64) >>> set(HAVE_GETIPINFO 1) >>> diff --git a/cmake/modules/LibffiUtils.cmake >>> b/cmake/modules/LibffiUtils.cmake >>> index b3fa697..fb34c36 100644 >>> --- a/cmake/modules/LibffiUtils.cmake >>> --- a/cmake/modules/LibffiUtils.cmake >>> +++ b/cmake/modules/LibffiUtils.cmake >>> @@ -9,6 +9,8 @@ function(setup_libffi libffi_srcroot) >>> set(arch_dir "aarch64") >>> elseif(${llarch} STREQUAL "x86_64") >>> set(arch_dir "x86") >>> + elseif(${llarch} STREQUAL "i686") >>> + set(arch_dir "x86") >>> else() >>> message(SEND_ERROR "Arch ${llarch} not yet supported") >>> endif() >>> diff --git a/driver/Driver.cpp b/driver/Driver.cpp >>> index 8debbab..aa83fb1 100644 >>> --- a/driver/Driver.cpp >>> +++ b/driver/Driver.cpp >>> @@ -76,7 +76,7 @@ std::string Driver::installedLibDir() >>> llvm::sys::path::append(ldir, "../lib64"); >>> break; >>> default: >>> - llvm::sys::path::append(ldir, "../lib64"); >>> + llvm::sys::path::append(ldir, "../lib"); >>> break; >>> } >>> : >>> --- a/cmake/modules/LibffiUtils.cmake >>> +++ b/cmake/modules/LibffiUtils.cmake >>> @@ -9,6 +9,8 @@ function(setup_libffi libffi_srcroot) >>> set(arch_dir "aarch64") >>> elseif(${llarch} STREQUAL "x86_64") >>> set(arch_dir "x86") >>> + elseif(${llarch} STREQUAL "i686") >>> + set(arch_dir "x86") >>> else() >>> message(SEND_ERROR "Arch ${llarch} not yet supported") >>> endif() >>> diff --git a/driver/Driver.cpp b/driver/Driver.cpp >>> index 8debbab..aa83fb1 100644 >>> --- a/driver/Driver.cpp >>> +++ b/driver/Driver.cpp >>> @@ -76,7 +76,7 @@ std::string Driver::installedLibDir() >>> llvm::sys::path::append(ldir, "../lib64"); >>> break; >>> default: >>> - llvm::sys::path::append(ldir, "../lib64"); >>> + llvm::sys::path::append(ldir, "../lib"); >>> break; >>> } >>> return std::string(ldir.str()); >>> >>> and >>> >>> $ git log -1 >>> commit 850255c5cd7f9df79a148d537fd395089b7caf29 (HEAD -> master, >>> origin/master, origin/HEAD) >>> Author: Ivan Serdyuk <local.tourist.k...@gmail.com> >>> Date: Fri Dec 4 17:14:00 2020 +0200 >>> >>> gollvm: Updating README.md, to elevate the min. required version of >>> Clang compiler >>> >>> Too many issues with Clang 9 - so let's assume Clang 10+ >>> >>> Change-Id: Icf1a74148878b07fd941e5d525ac7e0c7f6bfdaf >>> Reviewed-on: https://go-review.googlesource.com/c/gollvm/+/275473 >>> Reviewed-by: Than McIntosh <th...@google.com> >>> Trust: Ian Lance Taylor <i...@golang.org> >>> >>> On Wednesday, January 6, 2021 at 5:34:17 PM UTC+2 th...@google.com >>> wrote: >>> >>>> Diff is fine. No need for the entire folder. >>>> Than >>>> >>>> >>>> On Wed, Jan 6, 2021 at 10:18 AM Ivan Serdyuk <local.tou...@gmail.com> >>>> wrote: >>>> >>>>> Than, >>>>> I could perform "git diff" and provide the generated file. >>>>> I could also compress & share the build folder. >>>>> What else would be required? >>>>> >>>>> Ivan >>>>> >>>>> On Wednesday, January 6, 2021 at 5:07:06 PM UTC+2 th...@google.com >>>>> wrote: >>>>> >>>>>> >>>>>> It would be helpful if you could put up a CL that includes all of the >>>>>> changes you're testing -- at this point do you have any modifications to >>>>>> driver/ArchCpusAttrs.h ? >>>>>> >>>>>> Thanks >>>>>> >>>>>> >>>>>> >>>>>> On Wed, Jan 6, 2021 at 10:00 AM Ivan Serdyuk <local.tou...@gmail.com> >>>>>> wrote: >>>>>> >>>>>>> Ping >>>>>>> >>>>>>> On Friday, January 1, 2021 at 5:45:02 AM UTC+2 Ivan Serdyuk wrote: >>>>>>> >>>>>>>> Happy New Year, Than. >>>>>>>> >>>>>>>> So I have rebuilt llvm-goc, after applying >>>>>>>> https://go-review.googlesource.com/c/gollvm/+/270219. >>>>>>>> Here >>>>>>>> <https://drive.google.com/file/d/1qDSKwKORZjH824gVeSXUknVm0rpKZ9j-/view?usp=sharing> >>>>>>>> is my compressed build folder. >>>>>>>> >>>>>>>> I am using >>>>>>>> $ clang --version >>>>>>>> clang version 12.0.0 >>>>>>>> Target: i686-pc-linux-gnu >>>>>>>> Thread model: posix >>>>>>>> on >>>>>>>> $ uname -a >>>>>>>> Linux oceanfish81-A8He 4.15.0-129-generic #132-Ubuntu SMP Thu Dec >>>>>>>> 10 14:07:35 UTC 2020 i686 i686 i686 GNU/Linux >>>>>>>> >>>>>>>> You can obtain a pre-compiler "MinSizeRel" build of LLVM (including >>>>>>>> Clang) here >>>>>>>> <https://drive.google.com/file/d/1c7wredQbaX4p20Ee15WnY3SblbjiQHMD/view?usp=sharing> >>>>>>>> . >>>>>>>> >>>>>>>> I tried to build an avarage libgo package - and here is what I got: >>>>>>>> >>>>>>>> $ ninja libgo_golang.org_x_crypto_chacha20 >>>>>>>> [1/120] Building Go package 'unicode' (non-PIC) >>>>>>>> FAILED: tools/gollvm/libgo/unicode.o >>>>>>>> cd /home/oceanfish81/Desktop/workarea/release/tools/gollvm/libgo && >>>>>>>> /usr/local/bin/cmake -E make_directory ./. && >>>>>>>> /home/oceanfish81/Desktop/workarea/release/./bin/llvm-goc -c -o >>>>>>>> /home/oceanfish81/Desktop/workarea/release/tools/gollvm/libgo/./unicode.o >>>>>>>> -fgo-pkgpath=unicode -I . >>>>>>>> /home/oceanfish81/Desktop/workarea/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/unicode/casetables.go >>>>>>>> /home/oceanfish81/Desktop/workarea/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/unicode/digit.go >>>>>>>> /home/oceanfish81/Desktop/workarea/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/unicode/graphic.go >>>>>>>> /home/oceanfish81/Desktop/workarea/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/unicode/letter.go >>>>>>>> /home/oceanfish81/Desktop/workarea/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/unicode/tables.go >>>>>>>> currently Gollvm is not supported on architecture i686 >>>>>>>> /home/oceanfish81/Desktop/workarea/release/./bin/llvm-goc: *unable >>>>>>>> to determine target CPU features for target i686-pc-linux-gnu* >>>>>>>> [2/120] Building Go package 'internal/unsafeheader' (PIC) >>>>>>>> FAILED: tools/gollvm/libgo/internal/.pic/unsafeheader.o >>>>>>>> cd /home/oceanfish81/Desktop/workarea/release/tools/gollvm/libgo && >>>>>>>> /usr/local/bin/cmake -E make_directory ./internal/.pic && >>>>>>>> /home/oceanfish81/Desktop/workarea/release/./bin/llvm-goc -c -o >>>>>>>> /home/oceanfish81/Desktop/workarea/release/tools/gollvm/libgo/internal/.pic/unsafeheader.o >>>>>>>> -fPIC -fgo-pkgpath=internal/unsafeheader -I . >>>>>>>> /home/oceanfish81/Desktop/workarea/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/internal/unsafeheader/unsafeheader.go >>>>>>>> currently Gollvm is not supported on architecture i686 >>>>>>>> /home/oceanfish81/Desktop/workarea/release/./bin/llvm-goc: *unable >>>>>>>> to determine target CPU features for target i686-pc-linux-gnu* >>>>>>>> ninja: build stopped: subcommand failed. >>>>>>>> >>>>>>>> Ivan >>>>>>>> On Tuesday, December 8, 2020 at 3:30:05 PM UTC+2 th...@google.com >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> Thanks for the note. >>>>>>>>> >>>>>>>>> I am still not completely sure what the problem is. >>>>>>>>> >>>>>>>>> >>>>>>>>> You wrote: >>>>>>>>> >>>>>>>>> | I found >>>>>>>>> | >>>>>>>>> | // triple: i686-pc-linux-gnu >>>>>>>>> | static const CpuAttrs attrs1[] = { >>>>>>>>> | // first entry is default cpu >>>>>>>>> | { "i686", "+cx8,+x87"}, >>>>>>>>> | >>>>>>>>> | and (inside the hashmap) >>>>>>>>> | >>>>>>>>> | { "yonah", "+cx8,+fxsr,+mmx,+sse,+sse2,+sse3,+x87"}, >>>>>>>>> | , which is not what I have supported (for Intel Celeron M440). >>>>>>>>> >>>>>>>>> What makes you say that this is not what you have supported? Are >>>>>>>>> you >>>>>>>>> saying that the cpu clang calls "yonah" doesn't actually have one >>>>>>>>> of these >>>>>>>>> features (ex: sse3)? >>>>>>>>> >>>>>>>>> >>>>>>>>> | Clang reports "unsupported CPU features" on any non-provided >>>>>>>>> one. >>>>>>>>> | So that is one big problem. >>>>>>>>> >>>>>>>>> Not sure what you mean here. Can you please post the complete >>>>>>>>> clang invocation and error message you are getting? >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> | const TripleCpus triples[] = { >>>>>>>>> | { "x86_64-unknown-linux-gnu", &attrs0[0] }, >>>>>>>>> | { "i686-pc-linux-gnu", &attrs1[0] }, >>>>>>>>> | { "aarch64-unknown-linux-gnu", &attrs2[0] }, >>>>>>>>> | { "", nullptr } // sentinel >>>>>>>>> | }; >>>>>>>>> | is not targeting to yonah, while llc is targeting it. >>>>>>>>> | It is always some "default" CPU model and, in fact, your code >>>>>>>>> never provided extraction of the CPU model (from llc). >>>>>>>>> | >>>>>>>>> >>>>>>>>> When llc emits the line >>>>>>>>> >>>>>>>>> Host CPU: yonah >>>>>>>>> >>>>>>>>> this does not mean that clang/llc will automatically target >>>>>>>>> 'yonah' when compiling, it just means that the program has detected >>>>>>>>> the >>>>>>>>> host CPU. >>>>>>>>> >>>>>>>>> Generally speaking if you want clang to produce code targeted >>>>>>>>> specifically to the host CPU, you have to use -march=native or >>>>>>>>> -mtune-native. >>>>>>>>> >>>>>>>>> Thanks, Than >>>>>>>>> >>>>>>>>> On Fri, Dec 4, 2020 at 8:08 PM Ivan Serdyuk < >>>>>>>>> local.tou...@gmail.com> wrote: >>>>>>>>> >>>>>>>>>> Hello. >>>>>>>>>> >>>>>>>>>> This issue is related to >>>>>>>>>> https://go-review.googlesource.com/c/gollvm/+/274574 >>>>>>>>>> . >>>>>>>>>> >>>>>>>>>> I think I have some misunderstanding on how you used to deal with >>>>>>>>>> CPU models, for LLVM. >>>>>>>>>> >>>>>>>>>> First things first - I had success with using >>>>>>>>>> >>>>>>>>>> #include "llvm/ADT/StringRef.h" >>>>>>>>>> #include "llvm/ADT/StringMap.h" >>>>>>>>>> #include "llvm/MC/SubtargetFeature.h" >>>>>>>>>> #include "llvm/Support/Host.h" >>>>>>>>>> >>>>>>>>>> using namespace llvm; >>>>>>>>>> SubtargetFeatures Features1; >>>>>>>>>> >>>>>>>>>> int main (int argc, char **argv) >>>>>>>>>> { >>>>>>>>>> sys::getHostCPUName(); >>>>>>>>>> StringMap HostFeatures; >>>>>>>>>> if (sys::getHostCPUFeatures(HostFeatures)) >>>>>>>>>> for (auto &F : HostFeatures) >>>>>>>>>> Features1.AddFeature(F.first(), F.second); >>>>>>>>>> >>>>>>>>>> printf("test %s", Features1.getString().c_str()); >>>>>>>>>> printf("\nsomething else\n"); >>>>>>>>>> return 0; >>>>>>>>>> } >>>>>>>>>> . It gives me such a set of CPU features: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> +sse2,-tsxldtrk,-cx16,-sahf,-tbm,-avx512ifma,-sha,-gfni,-fma4,-vpclmulqdq,-prfchw,-bmi2,-cldemote,-fsgsbase,-ptwrite,-amx-tile,-avx512bf16,-popcnt,-aes,-avx512bitalg,-movdiri,-xsaves,-avx512er,-xsavec,-avx512vnni,-amx-bf16,-avx512vpopcntdq,-pconfig,-clwb,-avx512f,-clzero,-pku,+mmx,-lwp,-rdpid,-xop,-rdseed,-waitpkg,-movdir64b,-sse4a,-avx512bw,-clflushopt,-xsave,-avx512vbmi2,-64bit,-avx512vl,-serialize,-invpcid,-avx512cd,-avx,-vaes,+cx8,-fma,-rtm,-bmi,-enqcmd,-rdrnd,-mwaitx,-sse4.1,-sse4.2,-avx2,+fxsr,-wbnoinvd,+sse,-lzcnt,-pclmul,-prefetchwt1,-f16c,-ssse3,-sgx,-shstk,+cmov,-avx512vbmi,-amx-int8,-movbe,-avx512vp2intersect,-xsaveopt,-avx512dq,-adx,-avx512pf,+sse3 >>>>>>>>>> >>>>>>>>>> $ llc --version >>>>>>>>>> provides >>>>>>>>>> Default target: i686-pc-linux-gnu >>>>>>>>>> Host CPU: yonah >>>>>>>>>> . >>>>>>>>>> >>>>>>>>>> I tried to update the capture-fcn-attributes.go file, like this: >>>>>>>>>> >>>>>>>>>> var supportedTriples []string = []string{ >>>>>>>>>> "x86_64-unknown-linux-gnu", >>>>>>>>>> "i686-pc-linux-gnu", >>>>>>>>>> "aarch64-unknown-linux-gnu", >>>>>>>>>> } >>>>>>>>>> . >>>>>>>>>> >>>>>>>>>> When I tried the generator >>>>>>>>>> >>>>>>>>>> capture-fcn-attributes -o /tmp/cpu_feature_list >>>>>>>>>> it generated me a broad list. >>>>>>>>>> The header contained >>>>>>>>>> >>>>>>>>>> Ubuntu clang version 11.0.0-++20200721055954+cebd637c886-1exp1 >>>>>>>>>> 20200721161335.13 >>>>>>>>>> . >>>>>>>>>> I found >>>>>>>>>> >>>>>>>>>> // triple: i686-pc-linux-gnu >>>>>>>>>> static const CpuAttrs attrs1[] = { >>>>>>>>>> // first entry is default cpu >>>>>>>>>> { "i686", "+cx8,+x87"}, >>>>>>>>>> >>>>>>>>>> and (inside the hashmap) >>>>>>>>>> >>>>>>>>>> { "yonah", "+cx8,+fxsr,+mmx,+sse,+sse2,+sse3,+x87"}, >>>>>>>>>> , which is not what I have supported (for Intel Celeron M440). >>>>>>>>>> Clang reports "unsupported CPU features" on any non-provided one. >>>>>>>>>> So that is one big problem. >>>>>>>>>> Next problem is that >>>>>>>>>> >>>>>>>>>> const TripleCpus triples[] = { >>>>>>>>>> { "x86_64-unknown-linux-gnu", &attrs0[0] }, >>>>>>>>>> { "i686-pc-linux-gnu", &attrs1[0] }, >>>>>>>>>> { "aarch64-unknown-linux-gnu", &attrs2[0] }, >>>>>>>>>> { "", nullptr } // sentinel >>>>>>>>>> }; >>>>>>>>>> is not targeting to yonah, while llc is targeting it. >>>>>>>>>> It is always some "default" CPU model and, in fact, your code >>>>>>>>>> never provided extraction of the CPU model (from llc). >>>>>>>>>> >>>>>>>>>> To make my observation complete - I am providing what is >>>>>>>>>> generated via >>>>>>>>>> >>>>>>>>>> capture-fcn-attributes -cpu yonah >>>>>>>>>> : >>>>>>>>>> >>>>>>>>>> // triple: x86_64-unknown-linux-gnu >>>>>>>>>> static const CpuAttrs attrs0[] = { >>>>>>>>>> // first entry is default cpu >>>>>>>>>> { "x86-64", "+cx8,+fxsr,+mmx,+sse,+sse2,+x87"}, >>>>>>>>>> { "", "" } // sentinel >>>>>>>>>> }; >>>>>>>>>> >>>>>>>>>> // triple: i686-pc-linux-gnu >>>>>>>>>> static const CpuAttrs attrs1[] = { >>>>>>>>>> // first entry is default cpu >>>>>>>>>> { "i686", "+cx8,+x87"}, >>>>>>>>>> { "yonah", "+cx8,+fxsr,+mmx,+sse,+sse2,+sse3,+x87"}, >>>>>>>>>> { "", "" } // sentinel >>>>>>>>>> }; >>>>>>>>>> >>>>>>>>>> // triple: aarch64-unknown-linux-gnu >>>>>>>>>> static const CpuAttrs attrs2[] = { >>>>>>>>>> // first entry is default cpu >>>>>>>>>> { "generic", "+neon"}, >>>>>>>>>> { "", "" } // sentinel >>>>>>>>>> }; >>>>>>>>>> >>>>>>>>>> const TripleCpus triples[] = { >>>>>>>>>> { "x86_64-unknown-linux-gnu", &attrs0[0] }, >>>>>>>>>> { "i686-pc-linux-gnu", &attrs1[0] }, >>>>>>>>>> { "aarch64-unknown-linux-gnu", &attrs2[0] }, >>>>>>>>>> { "", nullptr } // sentinel >>>>>>>>>> }; >>>>>>>>>> . >>>>>>>>>> >>>>>>>>>> I tried >>>>>>>>>> >>>>>>>>>> capture-fcn-attributes -cpu yonah -triples i686-pc-linux-gnu >>>>>>>>>> and got >>>>>>>>>> >>>>>>>>>> // triple: i686-pc-linux-gnu >>>>>>>>>> static const CpuAttrs attrs0[] = { >>>>>>>>>> // first entry is default cpu >>>>>>>>>> { "i686", "+cx8,+x87"}, >>>>>>>>>> { "yonah", "+cx8,+fxsr,+mmx,+sse,+sse2,+sse3,+x87"}, >>>>>>>>>> { "", "" } // sentinel >>>>>>>>>> }; >>>>>>>>>> >>>>>>>>>> const TripleCpus triples[] = { >>>>>>>>>> { "i686-pc-linux-gnu", &attrs0[0] }, >>>>>>>>>> { "", nullptr } // sentinel >>>>>>>>>> }; >>>>>>>>>> . >>>>>>>>>> >>>>>>>>>> I understand that your strategy worked find on Intel based >>>>>>>>>> system-on-board machines - but didn't try something for AMD (yet). >>>>>>>>>> Nevertheless I have these issues on i686 - so I am proposing to >>>>>>>>>> perform a review. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Ivan >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> You received this message because you are subscribed to the >>>>>>>>>> Google Groups "golang-nuts" group. >>>>>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>>>>> send an email to golang-nuts...@googlegroups.com. >>>>>>>>>> To view this discussion on the web visit >>>>>>>>>> https://groups.google.com/d/msgid/golang-nuts/aac8c576-9763-4bba-96a1-51f545084630n%40googlegroups.com >>>>>>>>>> <https://groups.google.com/d/msgid/golang-nuts/aac8c576-9763-4bba-96a1-51f545084630n%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>>>>>> . >>>>>>>>>> >>>>>>>>> -- >>>>>>> You received this message because you are subscribed to the Google >>>>>>> Groups "golang-nuts" group. >>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>> send an email to golang-nuts...@googlegroups.com. >>>>>>> >>>>>> To view this discussion on the web visit >>>>>>> https://groups.google.com/d/msgid/golang-nuts/cc763125-04fe-4a8d-9940-625c0f25cc50n%40googlegroups.com >>>>>>> <https://groups.google.com/d/msgid/golang-nuts/cc763125-04fe-4a8d-9940-625c0f25cc50n%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>>> . >>>>>>> >>>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "golang-nuts" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to golang-nuts...@googlegroups.com. >>>>> >>>> To view this discussion on the web visit >>>>> https://groups.google.com/d/msgid/golang-nuts/67c15826-5ed2-40ca-b284-6ff471fb6584n%40googlegroups.com >>>>> <https://groups.google.com/d/msgid/golang-nuts/67c15826-5ed2-40ca-b284-6ff471fb6584n%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>> -- >>> You received this message because you are subscribed to the Google >>> Groups "golang-nuts" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to golang-nuts+unsubscr...@googlegroups.com. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/golang-nuts/399b00c6-8a6c-46aa-8397-b7d01cd85e44n%40googlegroups.com >>> <https://groups.google.com/d/msgid/golang-nuts/399b00c6-8a6c-46aa-8397-b7d01cd85e44n%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CA%2BUr55G%2BTssHY2VYysAZwFafKUOBt9tesBH%2BGE-0-sNdKbKOAQ%40mail.gmail.com.
