GCC 4.3.0 Status Report (2008-02-14)
Mark Mitchell
mark@codesourcery.com
Tue Feb 19 00:40:00 GMT 2008
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
More information about the Gcc
mailing list