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