This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: GCC 4.3.0 Status Report (2008-02-14)
Janis Johnson wrote:
I discussed this on IRC with David Edelsohn and others. I plan to modify
the patch at http://gcc.gnu.org/ml/gcc-patches/2008-02/msg00521.html to
set the default for the AltiVec ABI based on -maltivec; that patch had set
it by default. That patch will continue to re-enable -mabi=no-altivec,
which had been broken since 4.0. I had hoped to get this in before the
4.3 release but it probably won't make it and isn't worth holding up the
release.
OK, that takes the pressure off. I was wading in here because of the
request that we put this in 4.3, and I felt that I couldn't in good
conscience approve that without understanding the details better. If we
can take our time, then that's easier.
without the rest of the AltiVec ABI, so I'll leave that alone. Users who
explicity use "-maltivec -mabi=no-altivec" will get dangerous code.
That seems OK.
However, if I understand correct, some users have probably been
implicitly using those options because they were using "-mcpu=970", or
otherwise specifying an AltiVec CPU. It seems desirable in the abstract
that this code still be binary-compatible with new -mcpu=970 code, if it
was "plain C" code not using AltiVec vectors explicitly. But, I don't
know if that's technically feasible or not.
There are lots of inconsistencies in passing generic vectors as arguments
and return values, and I'll leave those alone until the PowerPC ELF ABI
group decides what to do with them.
It's certainly good to minimize the number of times we introduce ABI
changes, so waiting for a definitive plan makes sense.
Thanks,
--
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713