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%2BUr55FxA8SCxsjJvY5odcPuS%3DTkSj2X51PK8WRBLLrSwGK-5g%40mail.gmail.com.
