On Tue, Apr 2, 2019 at 10:24 AM CHIGOT, CLEMENT <clement.chi...@atos.net> wrote: > > > On Tue, Apr 2, 2019 at 4:05 PM David Edelsohn <dje....@gmail.com> wrote: > > On Tue, Apr 2, 2019 at 10:01 AM CHIGOT, CLEMENT <clement.chi...@atos.net> > > wrote: > > > On Tue, Apr 2, 2019 at 8:01 PM Ian Lance Taylor <i...@golang.org> wrote: > > > > On Mon, Apr 1, 2019 at 7:28 PM David Edelsohn <dje....@gmail.com> wrote: > > > > > On Mon, Apr 1, 2019 at 10:12 PM Ian Lance Taylor <i...@golang.org> > > > > > wrote: > > > > > > On Mon, Apr 1, 2019 at 7:06 PM David Edelsohn <dje....@gmail.com> > > > > > > wrote: > > > > > > > On Mon, Apr 1, 2019 at 9:50 PM Ian Lance Taylor <i...@golang.org> > > > > > > > wrote: > > > > > > > > On Mon, Apr 1, 2019 at 12:43 AM CHIGOT, CLEMENT > > > > > > > > <clement.chi...@atos.net> wrote: > > > > > > > > > > > > > > > > > > Description: > > > > > > > > > * This patch removes -mvsx and -maltivec for go aix/ppc. > > > > > > > > > These options don't seem compatible with Go stack layout. > > > > > > > > > > > > > > > > Can you give some more details on the problem? gccgo should > > > > > > > > just be > > > > > > > > using the regular stack layout, I can't think of any reason why > > > > > > > > these > > > > > > > > options would not be compatible. > > > > > > > > > > > > > > Some Altivec instructions require stricter alignment and 32 bit > > > > > > > AIX > > > > > > > does not impose sufficient alignment in the stack, so GCC Go > > > > > > > silently > > > > > > > references the wrong address. > > > > > > > > > > > > > > GCC Go should be able to align the stack properly on AIX. In the > > > > > > > interim, we need to disable generation of Altivec/VSX. > > > > > > > > > > > > Thanks. That makes it seem like more of a general GCC problem than > > > > > > a > > > > > > gccgo problem, though. Or does GCC arrange to align the stack in > > > > > > the > > > > > > main function? > > > > > > > > > > 32 bit AIX doesn't require stack alignment as strict as Altivec > > > > > assumes. GCC believes that the stack alignment is stricter than it > > > > > is. > > > > > > > > OK, so that seems like something to address in > > > > gcc/config/rs6000/rs6000.c, not in gcc/go/gospec.c. > > > > > > I do agree. However, it seems to work with C programs. At least, I didn't > > > see anything linked in test failures. > > > I didn't have time to investigate in order to know which part of gcc code > > > generation is making Go failing. > > > Therefore, I want to disable it for GCC Go for the moment and fix it > > > properly once I can. > > > If you don't want such a thing, we can keep this patch locally for our > > > RPMs, and submit a better patch > > > later. > > > > Clement, > > > > If this should be disabled this temporarily, it should be disabled in > > target-specific, GCC backend code, not in the common Go frontend code. > > For example, the code that enables processor features mask bits should > > clear the Altivec and VSX bits when used by the Go language with > > AIX32, as opposed to the Go language testing for AIX and Power. > > Ok, I'll do a better patch, once I've understood how the GCC backend works. > I'm still wondering how altivec can work with C programs if you said that > the 32 bit AIX stack isn't as strict as the Altivec wants ?
I'm not certain what Go is doing differently. A good place to change this is in SUBTARGET_OVERRIDE_OPTIONS in gcc/config/rs6000/aix72.h (and aix61.h). A heavyweight method to check the language is to use if (! strcmp (language_string, "GNU Go")) or whatever value is used for the language name. Thanks, David
