On Mon, Apr 11, 2005 at 08:59:38PM +0300, Konstantinos Margaritis wrote: > On ?????????????? 10 ???????????????? 2005 23:32, Matthias Klose wrote: > > Konstantinos Margaritis writes: > > > Package: gcc-3.4 > > > Version: 3.4.3-12 > > > Severity: grave > > > > > > Apparently latest packages of gcc-3.4 have disabled -mvrsave=yes > > > for powerpc. This breaks existing software which uses Altivec and > > > it's also wrong. Even worse, it's not documented in the changelog > > > (Debian or normal). The code that is produced is unstable. Please > > > enable it by default. > > > > which Debian version did have the old behaviour? > > Well, gcc 3.3 has -mvrsave=yes by default and also _I think_ the > previous version of gcc i used (3.4.3-6) . It was after the upgrade > to -12 that I noticed some strange behaviour in my programs and it > was just then that I checked and found after a lot of frustration > that it's turned off. I have discussed this with other powerpc > developers (though on irc only, i don't have anything in email, and > not only Debian developers) and they all confirm that this is a wrong > and confusing move. At the very least it should post a warning when > it finds altivec code, that -mvrsave is disabled. I don't deny that > there are a few cases where the developer might want to leave it > disabled, but these are the exceptions not the norm. > > Please, reenable it, or at the very least put a warning and some entry > in the changelog about this. It's truly too dangerous to leave it > like that.
How odd. Matthias, I can reproduce this in 3.3.4-13, but not in 3.4.3-7. Compile this (crappy) testcase with -O2 -maltivec -mabi=altivec, and with -mvrsave=yes/-mvrsave=no: #include <altivec.h> void bar(); vector int ret(); void arg(vector int, ...); int foo() { vector int q = ret(), t = ret(), z, a, b, c, d, e, f, g, h; z = vec_add (q, t); a = vec_add (z, t); b = vec_add (a, t); c = vec_add (b, t); d = vec_add (c, t); e = vec_add (d, t); f = vec_add (e, c); g = vec_add (f, t); h = vec_add (g, z); bar (); z = vec_add (h, vec_add (z, t)); arg (z, a, b, d, h); } Konstantinos, I strongly suspect this was a bug in GCC 3.3. The Linux kernel does not pay attention to vrsave in 32-bit mode: * If the previous thread used altivec in the last quantum * (thus changing altivec regs) then save them. * We used to check the VRSAVE register but not all apps * set it, so we don't rely on it now (and in fact we need * to save & restore VSCR even if VRSAVE == 0). -- paulus So if you insist that GCC needs to fiddle the register, when nothing is looking at it, you'll need some better reason why. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]