Re: [go-nuts] About 64bits alignment

2019-01-26 Thread Ian Lance Taylor
On Sat, Jan 26, 2019 at 7:56 AM Marvin Renich wrote: > > * Ian Lance Taylor [190125 18:11]: > > On Fri, Jan 25, 2019 at 2:59 PM wrote: > > > I still can't find anything "authoritative and unambiguous" on this. > > > Therefore apps are going to be released with bugs in them. Can > > > someone

Re: [go-nuts] About 64bits alignment

2019-01-26 Thread Marvin Renich
* Ian Lance Taylor [190125 18:11]: > On Fri, Jan 25, 2019 at 2:59 PM wrote: > > I still can't find anything "authoritative and unambiguous" on this. > > Therefore apps are going to be released with bugs in them. Can > > someone please say specifically when it is _not_ safe to use 64-bit > >

Re: [go-nuts] About 64bits alignment

2019-01-25 Thread Ian Lance Taylor
On Fri, Jan 25, 2019 at 2:59 PM wrote: > > I still can't find anything "authoritative and unambiguous" on this. > Therefore apps are going to be released with bugs in them. Can someone > please say specifically when it is _not_ safe to use 64-bit atomic operations? > > When it is unsafe on a

Re: [go-nuts] About 64bits alignment

2019-01-25 Thread johnmrusk
I still can't find anything "authoritative and unambiguous" on this. Therefore apps are going to be released with bugs in them. Can someone please say specifically when it is _not_ safe to use 64-bit atomic operations? When it is unsafe on a 64-bit OS? When it is unsafe on a 32-bit OS? John

Re: [go-nuts] About 64bits alignment

2018-03-16 Thread T L
On Thursday, March 15, 2018 at 12:54:22 PM UTC-4, Ian Lance Taylor wrote: > > On Thu, Mar 15, 2018 at 8:11 AM, T L > wrote: > > > > On Thursday, March 15, 2018 at 10:57:50 AM UTC-4, Jan Mercl wrote: > >> > >> > >> On Thu, Mar 15, 2018 at 3:29 PM T L

Re: [go-nuts] About 64bits alignment

2018-03-15 Thread Ian Lance Taylor
On Thu, Mar 15, 2018 at 8:11 AM, T L wrote: > > On Thursday, March 15, 2018 at 10:57:50 AM UTC-4, Jan Mercl wrote: >> >> >> On Thu, Mar 15, 2018 at 3:29 PM T L wrote: >> >> > I mean "always makes 64-bit words 64-bit aligned on i386 OSes." >> >> AFAIK,

Re: [go-nuts] About 64bits alignment

2018-03-15 Thread T L
On Thursday, March 15, 2018 at 10:57:50 AM UTC-4, Jan Mercl wrote: > > > On Thu, Mar 15, 2018 at 3:29 PM T L > wrote: > > > I mean "always makes 64-bit words 64-bit aligned on i386 OSes." > > AFAIK, that's not the case, ie. not always. > > -- > > -j > But it looks the

Re: [go-nuts] About 64bits alignment

2018-03-15 Thread Jan Mercl
On Thu, Mar 15, 2018 at 3:29 PM T L wrote: > I mean "always makes 64-bit words 64-bit aligned on i386 OSes." AFAIK, that's not the case, ie. not always. -- -j -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To

Re: [go-nuts] About 64bits alignment

2018-03-15 Thread T L
On Thursday, March 15, 2018 at 10:09:36 AM UTC-4, T L wrote: > > > > On Monday, February 6, 2017 at 7:43:33 AM UTC-5, T L wrote: >> >> >> >> On Monday, February 6, 2017 at 11:16:22 AM UTC, T L wrote: >>> >>> >>> >>> On Monday, February 6, 2017 at 6:43:04 PM UTC+8, T L wrote:

Re: [go-nuts] About 64bits alignment

2018-03-15 Thread T L
On Monday, February 6, 2017 at 7:43:33 AM UTC-5, T L wrote: > > > > On Monday, February 6, 2017 at 11:16:22 AM UTC, T L wrote: >> >> >> >> On Monday, February 6, 2017 at 6:43:04 PM UTC+8, T L wrote: >>> >>> >>> >>> On Monday, February 6, 2017 at 3:14:22 AM UTC+8, Ian Lance Taylor wrote:

Re: [go-nuts] About 64bits alignment

2017-02-06 Thread T L
On Monday, February 6, 2017 at 11:16:22 AM UTC, T L wrote: > > > > On Monday, February 6, 2017 at 6:43:04 PM UTC+8, T L wrote: >> >> >> >> On Monday, February 6, 2017 at 3:14:22 AM UTC+8, Ian Lance Taylor wrote: >>> >>> On Sun, Feb 5, 2017 at 10:52 AM, T L wrote: >>> > Ian,

Re: [go-nuts] About 64bits alignment

2017-02-06 Thread T L
On Monday, February 6, 2017 at 6:43:04 PM UTC+8, T L wrote: > > > > On Monday, February 6, 2017 at 3:14:22 AM UTC+8, Ian Lance Taylor wrote: >> >> On Sun, Feb 5, 2017 at 10:52 AM, T L wrote: >> > Ian, thanks for the answers. >> > >> > But I still not very confirm on many

Re: [go-nuts] About 64bits alignment

2017-02-06 Thread T L
On Monday, February 6, 2017 at 3:14:22 AM UTC+8, Ian Lance Taylor wrote: > > On Sun, Feb 5, 2017 at 10:52 AM, T L > wrote: > > Ian, thanks for the answers. > > > > But I still not very confirm on many points. > > > > Up to now, there are two places mention the

Re: [go-nuts] About 64bits alignment

2017-02-05 Thread T L
On Monday, February 6, 2017 at 12:44:38 PM UTC+8, Ian Lance Taylor wrote: > > On Sun, Feb 5, 2017 at 8:15 PM, T L > wrote: > > > > In fact, I still have another question needs to be clarify: what does > the > > "word" in "The first word in a global variable or in an

Re: [go-nuts] About 64bits alignment

2017-02-05 Thread Ian Lance Taylor
On Sun, Feb 5, 2017 at 8:15 PM, T L wrote: > > In fact, I still have another question needs to be clarify: what does the > "word" in "The first word in a global variable or in an allocated struct or > slice" mean? > A field with the same length with int values? In this case

Re: [go-nuts] About 64bits alignment

2017-02-05 Thread Ian Lance Taylor
On Sun, Feb 5, 2017 at 11:55 AM, T L wrote: > > In short, when structs and slices are used as the non-first fields of other > structs, > then the struct and slice fields may be not 64bit aligned on 32bit OSes. > > But what about arrays? Can the first word in an allocated

Re: [go-nuts] About 64bits alignment

2017-02-05 Thread T L
On Monday, February 6, 2017 at 3:55:35 AM UTC+8, T L wrote: > > > > On Monday, February 6, 2017 at 3:14:22 AM UTC+8, Ian Lance Taylor wrote: >> >> On Sun, Feb 5, 2017 at 10:52 AM, T L wrote: >> > Ian, thanks for the answers. >> > >> > But I still not very confirm on many

Re: [go-nuts] About 64bits alignment

2017-02-05 Thread T L
On Monday, February 6, 2017 at 3:14:22 AM UTC+8, Ian Lance Taylor wrote: > > On Sun, Feb 5, 2017 at 10:52 AM, T L > wrote: > > Ian, thanks for the answers. > > > > But I still not very confirm on many points. > > > > Up to now, there are two places mention the

Re: [go-nuts] About 64bits alignment

2017-02-05 Thread Ian Lance Taylor
On Sun, Feb 5, 2017 at 10:52 AM, T L wrote: > Ian, thanks for the answers. > > But I still not very confirm on many points. > > Up to now, there are two places mention the alignments in Go. > > The first is in the end of Go spec: > > > Size and alignment guarantees > > For

Re: [go-nuts] About 64bits alignment

2017-02-04 Thread Ian Lance Taylor
On Sat, Feb 4, 2017 at 2:38 PM, Axel Wagner wrote: > On Sat, Feb 4, 2017 at 11:13 PM, Ian Lance Taylor wrote: >> >> The spec does not say that unsafe.Alignof(s.B) will return 8. In >> fact, on 32-bit targets, with the gc toolchain, it will return

Re: [go-nuts] About 64bits alignment

2017-02-04 Thread 'Axel Wagner' via golang-nuts
On Sat, Feb 4, 2017 at 11:13 PM, Ian Lance Taylor wrote: > On Sat, Feb 4, 2017 at 7:33 AM, Axel Wagner > wrote: > > > > I believe, that fields do not necessarily need to be properly aligned > > (explaining 599). However, *structs* have a necessary

Re: [go-nuts] About 64bits alignment

2017-02-04 Thread 'Axel Wagner' via golang-nuts
Basically, to most of your disagreements: I'm wildly guessing, trying to make sense of the information I do have :) Just one specific answer: On Sat, Feb 4, 2017 at 11:05 PM, Matt Harden wrote: > > Wait, I don't think you've explained why expvar.Float would be aligned >

Re: [go-nuts] About 64bits alignment

2017-02-04 Thread Ian Lance Taylor
On Sat, Feb 4, 2017 at 7:33 AM, Axel Wagner wrote: > > I believe, that fields do not necessarily need to be properly aligned > (explaining 599). However, *structs* have a necessary alignment, as required > by their fields. So, if you do > type S struct { > A

Re: [go-nuts] About 64bits alignment

2017-02-04 Thread Matt Harden
On Sat, Feb 4, 2017 at 7:34 AM 'Axel Wagner' via golang-nuts < golang-nuts@googlegroups.com> wrote: > I find this an inappropriate answer. Yes, they need care, but it should at > least be possible to figure out how to use them from reading documentation > (carefully). I tend to agree, that

Re: [go-nuts] About 64bits alignment

2017-02-04 Thread 'Axel Wagner' via golang-nuts
I find this an inappropriate answer. Yes, they need care, but it should at least be possible to figure out how to use them from reading documentation (carefully). I tend to agree, that neither the spec nor the documentation of the atomic package is particularly helpful about these questions; at

Re: [go-nuts] About 64bits alignment

2017-02-04 Thread Lars Seipel
On Sat, Feb 04, 2017 at 01:30:49AM -0800, T L wrote: > Get it. This is quite bug prone to write programs on 64bit OSes and the > programs are expected to run on 32bit OSes too. Well, there's a reason the sync/atomic package docs have this statement right at the top: > These functions require

Re: [go-nuts] About 64bits alignment

2017-02-04 Thread T L
On Saturday, February 4, 2017 at 6:32:52 PM UTC+8, Axel Wagner wrote: > > The spec says this: > https://golang.org/ref/spec#Size_and_alignment_guarantees > Now, I can't really read from this whether this applies to fields or not. > If it does, it would seem to me, that, indeed, WaitGroup

Re: [go-nuts] About 64bits alignment

2017-02-04 Thread 'Axel Wagner' via golang-nuts
The spec says this: https://golang.org/ref/spec#Size_and_alignment_guarantees Now, I can't really read from this whether this applies to fields or not. If it does, it would seem to me, that, indeed, WaitGroup wouldn't need to use the trick it does. For the example you name: It isn't particularly

Re: [go-nuts] About 64bits alignment

2017-02-04 Thread T L
On Saturday, February 4, 2017 at 2:18:44 PM UTC+8, Matt Harden wrote: > > https://play.golang.org/p/VWysBwbPCu > > The above program prints 64-bit aligned addresses on the playground, but > that's a 64 bit platform (with 32 bit pointers). On a 32 bit platform x.j > is not guaranteed to be

Re: [go-nuts] About 64bits alignment

2017-02-04 Thread T L
On Saturday, February 4, 2017 at 5:56:30 PM UTC+8, T L wrote: > > > > On Saturday, February 4, 2017 at 5:40:25 PM UTC+8, T L wrote: >> >> >> >> On Friday, February 3, 2017 at 10:44:26 PM UTC+8, Ian Lance Taylor wrote: >>> >>> On Fri, Feb 3, 2017 at 5:38 AM, T L wrote: >>> >

Re: [go-nuts] About 64bits alignment

2017-02-04 Thread T L
On Saturday, February 4, 2017 at 5:40:25 PM UTC+8, T L wrote: > > > > On Friday, February 3, 2017 at 10:44:26 PM UTC+8, Ian Lance Taylor wrote: >> >> On Fri, Feb 3, 2017 at 5:38 AM, T L wrote: >> > Why does WaitGroup.state method check 64-bit alignment at run time? >> > Why

Re: [go-nuts] About 64bits alignment

2017-02-04 Thread T L
On Friday, February 3, 2017 at 10:44:26 PM UTC+8, Ian Lance Taylor wrote: > > On Fri, Feb 3, 2017 at 5:38 AM, T L > wrote: > > Why does WaitGroup.state method check 64-bit alignment at run time? > > Why not make the state field as the first word of WaitGroup struct? > >

Re: [go-nuts] About 64bits alignment

2017-02-04 Thread T L
On Saturday, February 4, 2017 at 2:51:53 PM UTC+8, Axel Wagner wrote: > > On Sat, Feb 4, 2017 at 5:49 AM, T L > wrote: > >> On Saturday, February 4, 2017 at 11:03:11 AM UTC+8, Matt Harden wrote: >>> >>> Never mind; I just realized that a WaitGroup is not necessarily at the

Re: [go-nuts] About 64bits alignment

2017-02-03 Thread 'Axel Wagner' via golang-nuts
On Sat, Feb 4, 2017 at 5:49 AM, T L wrote: > On Saturday, February 4, 2017 at 11:03:11 AM UTC+8, Matt Harden wrote: >> >> Never mind; I just realized that a WaitGroup is not necessarily at the >> start of an allocation or global variable. >> > > Not very get it. > Do you

Re: [go-nuts] About 64bits alignment

2017-02-03 Thread Matt Harden
https://play.golang.org/p/VWysBwbPCu The above program prints 64-bit aligned addresses on the playground, but that's a 64 bit platform (with 32 bit pointers). On a 32 bit platform x.j is not guaranteed to be 64-bit aligned. The same would be true if we substituted a WaitGroup for int64 in that

Re: [go-nuts] About 64bits alignment

2017-02-03 Thread T L
On Saturday, February 4, 2017 at 11:03:11 AM UTC+8, Matt Harden wrote: > > Never mind; I just realized that a WaitGroup is not necessarily at the > start of an allocation or global variable. > Not very get it. Do you mean WaitGroup will be embedded in other types? So we can't use the 64bit

Re: [go-nuts] About 64bits alignment

2017-02-03 Thread Matt Harden
Never mind; I just realized that a WaitGroup is not necessarily at the start of an allocation or global variable. On Fri, Feb 3, 2017 at 7:01 PM Matt Harden wrote: > Doesn't the statement "32-bit compilers to not ensure [64 bit alignment at > the start of an allocation]"

Re: [go-nuts] About 64bits alignment

2017-02-03 Thread Matt Harden
Doesn't the statement "32-bit compilers to not ensure [64 bit alignment at the start of an allocation]" contradict the sync/atomic statement "The first word in a global variable or in an allocated struct or slice can be relied upon to be 64-bit aligned."? On Fri, Feb 3, 2017 at 6:44 AM Ian Lance

Re: [go-nuts] About 64bits alignment

2017-02-03 Thread Ian Lance Taylor
On Fri, Feb 3, 2017 at 5:38 AM, T L wrote: > Why does WaitGroup.state method check 64-bit alignment at run time? > Why not make the state field as the first word of WaitGroup struct? > > // https://golang.org/src/sync/waitgroup.go?s=1857:1892#L20 > > type WaitGroup struct { >

Re: [go-nuts] About 64bits alignment

2017-02-03 Thread T L
Why does WaitGroup.state method check 64-bit alignment at run time? Why not make the state field as the first word of WaitGroup struct? // https://golang.org/src/sync/waitgroup.go?s=1857:1892#L20 type WaitGroup struct { noCopy noCopy // 64-bit value: high 32 bits are counter,

Re: [go-nuts] About 64bits alignment

2017-02-01 Thread T L
On Thursday, February 2, 2017 at 12:11:39 AM UTC+8, Jan Mercl wrote: > > On Wed, Feb 1, 2017 at 5:04 PM T L > wrote: > > > But what does an allocated struct or slice means? A struct or slice > allocated on heap, not stack? > > There's no heap nor stack from the POV of the

Re: [go-nuts] About 64bits alignment

2017-02-01 Thread Jan Mercl
On Wed, Feb 1, 2017 at 5:04 PM T L wrote: > But what does an allocated struct or slice means? A struct or slice allocated on heap, not stack? There's no heap nor stack from the POV of the language spec. Allocated means appropriate amount of storage is now used by the