https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83707
Alan Modra <amodra at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2018-03-29
Ever confirmed|0 |1
--- Comment #4 from Alan Modra <amodra at gmail dot com> ---
Here's some analysis.
Yes, with -O, variable v1 is indeed in a register, v31 aka vs63 before the call
to thrower. This should be fine. Variables don't need to be in memory for
exceptions to work..
thrower() sets up a frame
stwu 1,-288(1)
stores the vector reg of interest to the stack
li 0,208
stvx 31,1,0
and accurately describes that save with
.cfi_offset 108, -80
At -O, thrower() indeed uses the non-volatile v20..v31, and doesn't restore the
saved values itself. That's all good. We are relying on the exception
handling mechanism, ie. frame unwinding to restore the value of v31.
With 8.0.1 20180322 the test passes for me at -O -maltivec -m32 -mcpu=power7,
with LD_LIBRARY_PATH set to pick up the newly built libstdc++ and libgcc. So
perhaps the problem has been fixed, or maybe you were somehow picking up a bad
version of the unwinder?
Note that my build was with --build=powerpc64-linux --prefix=/home/amodra/gnu
--with-cpu=power8 --enable-valgrind-annotations --enable-gnu-indirect-functions
--enable-__cxa-exit --enable-secure-plt --disable-nls --enable-languages=all
--enable-lto
I'm also using bleeding edge binutils.
