> fixed at this point at tip.
>
> Thanks, Than
>
>
> On Mon, Jul 20, 2020 at 2:33 PM Ian Lance Taylor > wrote:
>
>> [ + thanm, cherryyz ]
>>
>> On Mon, Jul 20, 2020 at 4:24 AM Yuan Ting > > wrote:
>> >
>> > Hi, I try to build hugo
Hi,
I know from README that gollvm does not support race detector. Is there any
technical problem? Is it possible to use ThreadSanitizer in LLVM to
implement a workaround race detector in gollvm?
Thanks.
Ting
--
You received this message because you are subscribed to the Google Groups
"golang
>
> On Saturday, July 20, 2019 at 5:32:03 AM UTC+3 Yuan Ting wrote:
>
>> OK, I will check out the reflect2 package and take a look. Thanks a lot
>> for your direction!
>>
>> Best,
>> Ting
>>
>> On Friday, July 19, 2019 at 10:30:32 PM UTC+8, Ian Lan
gt; do you have any progress here?
>
> Ivan
>
> On Thursday, May 28, 2020 at 6:47:41 AM UTC+3 Yuan Ting wrote:
>
>> Thanks for your correction, overriding CMAKE_C_FLAGS and CMAKE_ASM_FLAGS
>> with "-fcf-protection=none" works for me.
>> I also try to build
Hi, I try to build hugo with fresh gollvm but the linker complains that:
# github.com/gohugoio/hugo
/usr/bin/ld.gold: error: $WORK/b029/_pkg_.a(gccgo_c.o): failed to match
split-stack sequence at section 1 offset 0
/usr/bin/ld.gold: error: $WORK/b029/_pkg_.a(gccgo_c.o): failed to match
split-sta
pening is that by setting CMAKE_C_FLAGS="-fcf-protection=none" but not
> also setting CMAKE_ASM_FLAGS="-fcf-protection=none" you've introduced a
> discrepancy between the C and Assembly compiles in libgo. If you
> set CMAKE_C_FLAGS, you should also set CMAKE_ASM_FLAG
e ld.gold error message really exists on
> both platforms.
>
> 在 2020年5月26日星期二 UTC+8上午10:14:43,Yuan Ting写道:
>>
>> I tried to build gollvm in a docker container (the image is based on
>> ubuntu 20.04, and the host OS is MacOS catalina). I configured llvm by
>>
have a rebuild from a clean start.
>
> Thanks, Than
>
>
> On Tue, May 26, 2020 at 11:00 AM Yuan Ting > wrote:
>
>> OK, as follows
>>
>> ./tools/gollvm/libgo/CMakeFiles/libgo_c_piclib.dir/__/gofrontend/libgo/go/syscall/errno.c.o:
>>
>>file
14
> 10: R_X86_64_PLT32 __errno_location-0x4
>
> Thanks, Than
>
> ?
>
> On Tue, May 26, 2020 at 10:05 AM Yuan Ting > wrote:
>
>> Fine, that is
>>
>> [1/3] /usr/bin/cc -D_DEBUG -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS
>> -D__STDC_
ompile line for errno.c?
>
> Thanks, Than
>
>
>
>
> On Tue, May 26, 2020 at 7:21 AM Yuan Ting >
> wrote:
>
>> Yes, I'm sure I fetched the last version of gollvm,
>> i.e. 0edc44a02852dd0d56cac35163a45634b497d6cd
>>
>> On Tuesday, May 26, 2
com/golang/go/issues/38728.
>
> Can you please check to make sure that your client is sync'd past the CLs
> that fix this issue, e.g. 0edc44a02852dd0d56cac35163a45634b497d6cd.
>
> Thanks, Than
>
>
> On Mon, May 25, 2020 at 10:15 PM Yuan Ting > wrote:
>
>> I tr
I tried to build gollvm in a docker container (the image is based on ubuntu
20.04, and the host OS is MacOS catalina). I configured llvm by
SHELL=/bin/sh cmake -DCMAKE_BUILD_TYPE=Release -DLLVM_TARGETS_TO_BUILD=X86
-DLLVM_ENABLE_ASSERTIONS=On -DLLVM_ENABLE_RTTI=On -DLLVM_USE_LINKER=gold -G
Ninj
How about the main go compiler? Will the code generated by the main go
compiler panic as you analyze?
On Monday, March 2, 2020 at 2:11:47 PM UTC+8, Jan Mercl wrote:
>
> On Mon, Mar 2, 2020 at 6:56 AM burak serdar > wrote:
>
> > At this point, channel receive is still holding a reference to the
I'm not sure if the channel receive is atomic. I thought it would get a
null pointer dereference error in chanrecv at runtime.
On Monday, March 2, 2020 at 1:37:01 PM UTC+8, burak serdar wrote:
>
> On Sun, Mar 1, 2020 at 9:49 PM Yuan Ting >
> wrote:
> >
> > I write
I write a simple program likes below and it triggers a data race alarm with
-race flag. But no matter how I run, this program will not panic. I know it
is legal to receive messages from nil channels, but I don't quite
understand why this program does not panic in the presence of data races.
ch
OK, I will check out the reflect2 package and take a look. Thanks a lot for
your direction!
Best,
Ting
On Friday, July 19, 2019 at 10:30:32 PM UTC+8, Ian Lance Taylor wrote:
>
> On Fri, Jul 19, 2019 at 1:11 AM Yuan Ting >
> wrote:
> >
> > Sorry to have troubled you
ossible to support the same symbol in
gccgo/gollvm style?
Best,
Ting
On Thursday, July 18, 2019 at 10:55:39 PM UTC+8, Ian Lance Taylor wrote:
>
> On Thu, Jul 18, 2019 at 6:50 AM Yuan Ting >
> wrote:
> >
> > Thank you for your fix. I have some curious about the differen
Thank you. The explanation really makes sense. I think I should modify the
source code of etcd, or change to another project that is not so hackful.
On Thursday, July 18, 2019 at 10:55:39 PM UTC+8, Ian Lance Taylor wrote:
>
> On Thu, Jul 18, 2019 at 6:50 AM Yuan Ting >
> wrote:
&g
Hi Than
Thank you for your fix. I have some curious about the difference between
the main Go compiler and gollvm. I read gollvm's readme and know that the
main difference comes from the efficiency of GC. Is the other difference
causes the symbol undefined reference as you mentioned above? Or so
; Cheers, Than
>
> On Tue, Jul 9, 2019 at 8:04 PM Yuan Ting >
> wrote:
>
>> My gollvm version is
>> commit 29005f52b3501c489cb1653506cd479d5a178e98 (HEAD -> master,
>> origin/master, origin/HEAD)
>> Author: Cherry Zhang <...>
>> Date: Sat Ju
github.com/golang/go/issues/32778
>
> which was fixed last week. What vintage is your gollvm?
>
> Thanks, Than
>
>
> On Tue, Jul 9, 2019 at 9:54 AM Yuan Ting >
> wrote:
>
>> In addition, I also failed to build etcd.
>>
>> $ git clone https://github.com
ater this morning; off the top of my head I'm not sure
> what the issue might be.
> Question: are you building with modules enabled?
> Thanks ,Than
>
>
> On Mon, Jul 8, 2019 at 11:05 PM Yuan Ting >
> wrote:
>
>> Hi, I'm working on converting some Go projects to l
e might be.
> Question: are you building with modules enabled?
> Thanks ,Than
>
>
> On Mon, Jul 8, 2019 at 11:05 PM Yuan Ting >
> wrote:
>
>> Hi, I'm working on converting some Go projects to llvm IR for static
>> analysis. When I build kubernetes
Hi, I'm working on converting some Go projects to llvm IR for static
analysis. When I build kubernetes with gollvm, an unexpected error occurred
as :
I0709 10:48:29.158892 16573 deepcopy.go:266] Type
k8s.io/apimachinery/pkg/apis/meta/v1.map_StatusDetails is not copyable
I0709 10:48:29.158899
Oh, my mistake. I can successfully build gollvm now, thank you so much!
On Thursday, May 9, 2019 at 11:07:37 AM UTC+8, Than McIntosh wrote:
>
> There was a recent checkin related to -fdebug-go-optimization in both
> repos-- I think the failure you're seeing is just build skew.
> Try doing a "git
25 matches
Mail list logo