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 ? Clément
