Issue 8654 in go: GOARCH values for powerpc64/powerpc64le inconsistent between gccgo and gc

[g...@googlecode.com]

Status: New
Owner: ----

New issue 8654 by labo...@gmail.com: GOARCH values for
powerpc64/powerpc64le inconsistent between gccgo and gc
https://code.google.com/p/go/issues/detail?id=8654

I built the go tools were built from the dev.power64 branch of the google
code repository with some patches from mi...@golang.org. I built gccgo
from trunk gcc trunk.

I ran my testcase on power8 BE & LE machines.

With gccgo the value for GOARCH on ppc64 and ppc64le machines is 'ppc64'.

With gc I get the GOARCH values 'power64' on the ppc64 machine
and 'power64le' on the ppc64le machine.

> What does 'go version' print?

~/gowork/go/bin/go version
go version devel +be0c14f62257 Mon Aug 18 22:24:15 2014 -0400 linux/power64

~/gowork/go/bin/go version
go version devel +be0c14f62257 Mon Aug 18 22:24:15 2014 -0400
linux/power64le

./gccgo --version
gccgo (GCC) 5.0.0 20140828 (experimental)
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

./gccgo -o test_arch test_arch.go
./test_arch
arch: ppc64

(Same results on both power8 and power8LE machines)

> What steps reproduce the problem?
My testcase:

package main

import (
"fmt"
"runtime"
)

func main() {
fmt.Println("arch: ", runtime.GOARCH)
}

> What should have happened instead?

The GOARCH values for powerpc64 & powerp64le should be consistent between
gccgo and gc. If it isn't then go code which is written to test the GOARCH
value could behave differently with each go compiler.

Since gccgo has been using ppc64 for while now, that seems like the
preferred base name (instead of just power).

A related question is whether the GOARCH value for powerpc64 BE & LE
machines should be the same. I'm stating an opinion on that for now just
that however it is set it should be consistent.


--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

[g...@googlecode.com]

Comment #1 on issue 8654 by labo...@gmail.com: GOARCH values for

powerpc64/powerpc64le inconsistent between gccgo and gc
https://code.google.com/p/go/issues/detail?id=8654

Last sentence should be "I'm not stating an opinion.... "

[g...@googlecode.com]

Updates:
Status: Accepted
Labels: Repo-Main Release-Go1.5

Comment #2 on issue 8654 by i...@golang.org: GOARCH values for

powerpc64/powerpc64le inconsistent between gccgo and gc
https://code.google.com/p/go/issues/detail?id=8654

(No comment was entered for this change.)

[g...@googlecode.com]

Comment #3 on issue 8654 by mi...@golang.org: GOARCH values for

powerpc64/powerpc64le inconsistent between gccgo and gc
https://code.google.com/p/go/issues/detail?id=8654

i still like power64/power64le as that's how ibm calls the
architecture, and we don't always agree with gcc in terms
of goarch.

for example, 386, amd64, amd64p32, arm64.

iant? do you agree? i will send CL to gccgo if you agree.

[g...@googlecode.com]

Comment #4 on issue 8654 by labo...@gmail.com: GOARCH values for

powerpc64/powerpc64le inconsistent between gccgo and gc
https://code.google.com/p/go/issues/detail?id=8654

I was told by Steve Munroe that there is an issue with the use of the name
power64 because Power is an IBM brand name. If you want more details I can
ask him to provide them.

Right now we use both ppc64 and powerpc64, so it would be nice not to add
another variation. Also I don't think the fact that it is inconsistent for
other platforms is a legitimate reason to make it inconsistent for
powerpc64 too. Seems like you'd want all the GOARCH values to be same for
gc and gccgo.

[g...@googlecode.com]

Comment #5 on issue 8654 by mi...@golang.org: GOARCH values for

powerpc64/powerpc64le inconsistent between gccgo and gc
https://code.google.com/p/go/issues/detail?id=8654

yes, i propose both gc and gccgo use power64 and power64le.

we need a way to differentiate big/little endian when generating
the code, so we need two goarches.

we use power64 to refer to precisely the same that ibm refers to,
so why that's not allowed?

[g...@googlecode.com]

Comment #6 on issue 8654 by mi...@golang.org: GOARCH values for

powerpc64/powerpc64le inconsistent between gccgo and gc
https://code.google.com/p/go/issues/detail?id=8654

note: PowerPC is also a trademark of IBM, so i think
the trademark shouldn't affect us.

[g...@googlecode.com]

Comment #7 on issue 8654 by labo...@gmail.com: GOARCH values for

powerpc64/powerpc64le inconsistent between gccgo and gc
https://code.google.com/p/go/issues/detail?id=8654

Last sentence should be "I'm not stating an opinion.... "

[g...@googlecode.com]

Comment #8 on issue 8654 by peter.e....@gmail.com: GOARCH values for

powerpc64/powerpc64le inconsistent between gccgo and gc
https://code.google.com/p/go/issues/detail?id=8654

We use powerpc64 and powerpc64le for gcc target triples. Can we use
those? Otherwise, my second choice would be ppc64 and ppc64le, since those
are also used in some other projects (LLVM?). As far as I am aware, no one
uses power64 and power64le.

[g...@googlecode.com]

Comment #9 on issue 8654 by mi...@golang.org: GOARCH values for

powerpc64/powerpc64le inconsistent between gccgo and gc
https://code.google.com/p/go/issues/detail?id=8654

no one uses amd64p32 either. so there is precedent using Go
specific GOARCHes.

[g...@googlecode.com]

Comment #10 on issue 8654 by sjmunro...@gmail.com: GOARCH values for

powerpc64/powerpc64le inconsistent between gccgo and gc
https://code.google.com/p/go/issues/detail?id=8654

POWER is brand name for series for chip designs (micro architecture)
designed by IBM for servers. It does not apply to Chips produced by
Freescale (e6500) or P.A. Semi (PA6T).

PowerPC was the official name of the Instruction Set Architecture (it is
now PowerISA as of V2.03) and so applies to ISA complaint chips (includes
Freescale and PA Semi)

powerpc[64] and ppc[64] are widely accepted names for the architecture in
the GNU/Linux community. When generating code you want the architecture
name at the top level.

power with a number suffix (ie power7 power8) should only be used to
designate a specific POWER server chip (micro-architecture).

[g...@googlecode.com]

Comment #11 on issue 8654 by peter.e....@gmail.com: GOARCH values for

powerpc64/powerpc64le inconsistent between gccgo and gc
https://code.google.com/p/go/issues/detail?id=8654

> no one uses amd64p32 either. so there is precedent using
> Go specific GOARCHes.

Maybe so, but since GC support for POWER doesn't exist modulo with your new
patches, there's no reason to use values that are different from what other
packages use.

[g...@googlecode.com]

Comment #12 on issue 8654 by mi...@golang.org: GOARCH values for

powerpc64/powerpc64le inconsistent between gccgo and gc
https://code.google.com/p/go/issues/detail?id=8654

gccgo might support x32 before we added amd64p32, but
that doesn't mean we must use x32 in gc.

according to the latest ISA, the ISA itself is called
Power, and as that document also call it "Power Architecture",
i see no reason we can't use power64 and power32 to
designate 64/32-bit GOARCH. Note: there is no need to
use the same architecture name as others (gcc/llvm/binutils)
do because gc is a completely separate toolchain.

we are not talking about the chip here, so i don't think
people will confuse it with IBM's microarchitecture (plus
we are not even close to Power32/Power64 now)

and btw, power64 is not a trademark, but powerpc is.

[g...@googlecode.com]

Comment #13 on issue 8654 by i...@golang.org: GOARCH values for

powerpc64/powerpc64le inconsistent between gccgo and gc
https://code.google.com/p/go/issues/detail?id=8654

Minux, why not use the names that the IBM guys are suggesting? And why not
use the names that other people use? What's the advantage of being
different? Why is power64 better?

[g...@googlecode.com]

Comment #14 on issue 8654 by mi...@golang.org: GOARCH values for

powerpc64/powerpc64le inconsistent between gccgo and gc
https://code.google.com/p/go/issues/detail?id=8654

power64 is consistent with other GOARCHes,
and also the latest ISA document called the
ISA "Power ISA", not ppc ISA or powerpc ISA.

i think the names ppc or powerpc are chosen
because of historical reasons (gcc internally
even use rs6000 for ppc)

now that ibm named their ISA "Power", why not
use the official name?

[g...@googlecode.com]

Comment #15 on issue 8654 by al...@pbrane.org: GOARCH values for

powerpc64/powerpc64le inconsistent between gccgo and gc
https://code.google.com/p/go/issues/detail?id=8654

Good work, Minux. The port must be sufficiently far along that the only
thing to complain about is the name. :) More seriously, why is it important
to use the outdated name that GCC uses? It's the Power architecture, hence
power and power64. Just like arm.

[g...@googlecode.com]

Comment #16 on issue 8654 by a...@mgk.ro: GOARCH values for

powerpc64/powerpc64le inconsistent between gccgo and gc
https://code.google.com/p/go/issues/detail?id=8654

Gcc/binutils names have always been very different from gc names. That's
perfectly fine, and it will always continue to be true because of the
pigeon hole principle. Let's not bikeshed this. Historically, GOARCH has
been Plan 9's $objtype, and $objtype for 9c has been power64 (objtype for
qc has been power). Since the toolchain can now also do little-endian,
power64le seems fine. All these are internally consistent and consistent
with the ISA manual

[g...@googlecode.com]

Comment #17 on issue 8654 by a...@mgk.ro: GOARCH values for

powerpc64/powerpc64le inconsistent between gccgo and gc
https://code.google.com/p/go/issues/detail?id=8654

> I was told by Steve Munroe that there is an issue with the use of
> the name power64 because Power is an IBM brand name. If you want
> more details I can ask him to provide them

I'm pretty sure Windows and Solaris are brand names too.

[g...@googlecode.com]

Comment #18 on issue 8654 by sjmunro...@gmail.com: GOARCH values for

powerpc64/powerpc64le inconsistent between gccgo and gc
https://code.google.com/p/go/issues/detail?id=8654

There is difference between a trademark on a architect and brand name for a
hardware product.

IBM wants you to use the trademarked Architecture name for enabled
software, and it Ok to apply it to the all complaint implementations,
include CHIPs from other companies.

It is NOT OK to apply IBM's Brand Name to chips from other companies.

So you if you don't want to use powerpc then use the new powerISA (TM). But
please don't use power or power64.

[g...@googlecode.com]

Comment #19 on issue 8654 by mi...@golang.org: GOARCH values for

powerpc64/powerpc64le inconsistent between gccgo and gc
https://code.google.com/p/go/issues/detail?id=8654

are you suggesting that we set
GOARCH="powerISA (TM)"
?

perhaps you're talking about something else, for example,
documentation for the port (and in that case, i'm open to
whatever adjustment you want), but we are talking about
$GOARCH and runtime.GOARCH, which is a string/environment
variable to tell the toolchain which compiler and linker
it should use.

as aram pointed out, Plan 9 has been using power64
for some time, see http://plan9.bell-labs.com/sources/plan9/power64/, even
though the official plan 9 distribution
doesn't include the 9c toolchain.

[g...@googlecode.com]

Comment #20 on issue 8654 by sjmunro...@gmail.com: GOARCH values for

powerpc64/powerpc64le inconsistent between gccgo and gc
https://code.google.com/p/go/issues/detail?id=8654

I am suggesting that if you don't like powerpc you can use powerisa because
is the TradeMark for architecture and not the Brand name for the POWER
servers.

I don't think plan9 counts in this discussion. They are messing with IBM's
Brand identity, a bad idea.

GCC and GNU in general are consistent with powerpc.

gcc -E -dD hello.c | grep power
#define __powerpc__ 1
#define __powerpc64__ 1

That is what every one would expect.

[g...@googlecode.com]

Comment #21 on issue 8654 by peter.e....@gmail.com: GOARCH values for

powerpc64/powerpc64le inconsistent between gccgo and gc
https://code.google.com/p/go/issues/detail?id=8654

minux wrote:
> yes, i propose both gc and gccgo use power64 and power64le.

I agree gc and gccgo should use a common GOARCH value, but I don't think
changing the gccgo GOARCH value is a good idea, since there are already
gccgo compilers released and being used in distros (Ubuntu, etc.) that
use the ppc64 value. Since there is no released gc compiler we have to
be compatible with, why not change gc to match gccgo's ppc64 value?

You also mention in another comment that gc and gccgo don't have to
agree on the GOARCH value and although that is true, I believe it is
highly desirable that they do match and since ppc64 gc support has not
been released yet, we can easily make that happen by having gc match
gccgo's ppc64 GOARCH value.

If gc and gccgo don't match, then that just make porting packages that
rely on GOARCH that were developed on one compiler all that much harder
to get working on the other. If we pick a common value, then that is
just one less thing to worry about.

> we need a way to differentiate big/little endian when generating
> the code, so we need two goarches.

I agree that we need to differentiate between ppc64 big-endian versus
little-endian. I thought someone (Ian?) mentioned that we should have
the same GOARCH value for both big-endian and little-endian. If that
is the case, what would be the mechanism to differentiate between the
two? A different macro like GOENDIAN or ??? I'll state I'm not against
a different GOARCH value for little-endian versus big-endian, but can
be persuaded either way.

[g...@googlecode.com]

Comment #22 on issue 8654 by mi...@golang.org: GOARCH values for

powerpc64/powerpc64le inconsistent between gccgo and gc
https://code.google.com/p/go/issues/detail?id=8654

we will need to change gccgo's GOARCH
anyway because it uses ppc64 for both
endians.

I don't like to add another mechanism
to set endian.

similarly, the upcoming 64-bit arm port
will have the same problem. gccgo will
to change to match gc's if we want to
maintain consistent GOARCH.

Also, if we have a mips gc port, then
I'd expect that GOARCH be mips, mips64
and mips64p32 for o32, n64 and n32 abi.
again, gccgo needs to change to match.

[g...@googlecode.com]

Comment #23 on issue 8654 by i...@golang.org: GOARCH values for

powerpc64/powerpc64le inconsistent between gccgo and gc
https://code.google.com/p/go/issues/detail?id=8654

I don't mind changing gccgo's GOARCH value.

I'm still inclined to listen to IBM's suggestions for GOARCH values rather
than Plan 9 suggestions. The fact that we have in the past used unusual
GOARCH names is not a reason to use unusual ones going forward.

The problem with using different GOARCH values based on endianness is that
file names become awkward. You can no longer name a file
syscall_powerpc64.go, because it will only be used on big-endian, not
little-endian. It's quite normal to want to have build tags that are
processor-specific. It's quite unusual, in fact, it never happens, to use
a build tag that is endian-specific. So why do we want to distinguish
endianness in the GOARCH value?

[g...@googlecode.com]

Comment #24 on issue 8654 by mi...@golang.org: GOARCH values for

powerpc64/powerpc64le inconsistent between gccgo and gc
https://code.google.com/p/go/issues/detail?id=8654

we need some way to embed (into cmd/go)
and set the endianness for the build


using GOARCH is the easiest way to do
without another mechanism.

Perhaps we do need another mechanism,
think all three mips GOARCHes.

Currently the 9g port used the convention
that files are named file_power64x.go
and have both GOARCHes are build tags.

[g...@googlecode.com]

Comment #25 on issue 8654 by labo...@gmail.com: GOARCH values for

powerpc64/powerpc64le inconsistent between gccgo and gc
https://code.google.com/p/go/issues/detail?id=8654

Based on the last two comments, are you leaning toward keeping the current
gccgo GOARCH value, using ppc64 for both BE & LE? Meaning no changes
needed for gccgo but gc will change to use ppc64 for both and find another
way to determine endianness?

[g...@googlecode.com]

Comment #26 on issue 8654 by labo...@linux.vnet.ibm.com: GOARCH values for

powerpc64/powerpc64le inconsistent between gccgo and gc
https://code.google.com/p/go/issues/detail?id=8654

Is there any update on this issue with respect to gccgo? The team working
on Docker for Power believe there should be different GOARCH values for
ppc64 and ppc64le and would like to know when there would be a change for
that or if a patch should be submitted to set it.

[g...@googlecode.com]

Comment #27 on issue 8654 by r...@golang.org: GOARCH values for

powerpc64/powerpc64le inconsistent between gccgo and gc
https://code.google.com/p/go/issues/detail?id=8654

Based on the discussion on golang-dev, the GOARCH values will be "ppc64"
and "ppc64le". Both the gc toolchain and gccgo will need to be updated. For
the gc toolchain, this will happen in the 1.5 release (the first with
64-bit Power support).

[g...@googlecode.com]

Comment #28 on issue 8654 by go...@golang.org: GOARCH values for

powerpc64/powerpc64le inconsistent between gccgo and gc

https://code.google.com/p/go/issues/detail?id=8654#c28

CL https://codereview.appspot.com/180600043 mentions this issue.

[g...@googlecode.com]

Updates:
Status: Fixed

Comment #29 on issue 8654 by r...@golang.org: GOARCH values for

powerpc64/powerpc64le inconsistent between gccgo and gc
https://code.google.com/p/go/issues/detail?id=8654

This issue was closed by revision 4d000340a768.