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. Thanks, David
