Re: GCC 4.3.0 Status Report (2008-02-14)

On Tue, 2008-02-19 at 18:47 +0100, Jakub Jelinek wrote: > On Mon, Feb 18, 2008 at 01:10:57PM -0800, Janis Johnson wrote: > > I changed argument passing and function return of generic vectors to be > > consistent with and without the AltiVec ABI for powerpc-linux and > > powerpc64-linux, but in so

Re: GCC 4.3.0 Status Report (2008-02-14)

On Tue, 2008-02-19 at 01:34 +, Joseph S. Myers wrote: > On Mon, 18 Feb 2008, Janis Johnson wrote: > > > 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.

Re: GCC 4.3.0 Status Report (2008-02-14)

On Mon, Feb 18, 2008 at 01:10:57PM -0800, Janis Johnson wrote: > I changed argument passing and function return of generic vectors to be > consistent with and without the AltiVec ABI for powerpc-linux and > powerpc64-linux, but in so doing inadvertently changed the behavior for > other powerpc tar

Re: GCC 4.3.0 Status Report (2008-02-14)

Daniel Jacobowitz wrote: On Mon, Feb 18, 2008 at 08:16:39PM -0500, David Edelsohn wrote: The Altivec ABI does change the stack alignment. This should not create an incompatibility for old code, but new code may not receive the stack properly aligned without additional dynamic alignment.

Re: GCC 4.3.0 Status Report (2008-02-14)

> Mark Mitchell writes: Mark> So, if we wanted to make this interoperate better, we'd have to Mark> introduce dynamic stack alignment in every externally visible function, Mark> thereby penalizing the average user who isn't trying to support linking Mark> with legacy code. Right?

Re: GCC 4.3.0 Status Report (2008-02-14)

On Mon, 18 Feb 2008, Janis Johnson wrote: > 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. Perhaps you'd care to recommend what the semantics *ought* to be, g

Re: GCC 4.3.0 Status Report (2008-02-14)

David Edelsohn wrote: Mark Mitchell writes: Mark> However, if I understand correct, some users have probably been Mark> implicitly using those options because they were using "-mcpu=970", or Mark> otherwise specifying an AltiVec CPU. It seems desirable in the abstract Mark> that this code s

Re: GCC 4.3.0 Status Report (2008-02-14)

On Mon, Feb 18, 2008 at 08:16:39PM -0500, David Edelsohn wrote: > The Altivec ABI does change the stack alignment. This should not > create an incompatibility for old code, but new code may not receive the > stack properly aligned without additional dynamic alignment. I thought so, too, but

Re: GCC 4.3.0 Status Report (2008-02-14)

> Mark Mitchell writes: Mark> However, if I understand correct, some users have probably been Mark> implicitly using those options because they were using "-mcpu=970", or Mark> otherwise specifying an AltiVec CPU. It seems desirable in the abstract Mark> that this code still be binary-comp

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

Re: GCC 4.3.0 Status Report (2008-02-14)

David Edelsohn wrote: The patch was suppose to enable -mabi=altivec when -maltivec is enabled, not change the default ABI. OK. If I understand correctly, then, this is going to be an ABI break for 32-bit Power GNU/Linux users using an AltiVec CPU (like 970). In particular, if I hav

Re: GCC 4.3.0 Status Report (2008-02-14)

On Mon, 2008-02-18 at 18:58 -0500, David Edelsohn wrote: > I misread Janis's latest patch that I approved. > > The patch was suppose to enable -mabi=altivec when -maltivec is > enabled, not change the default ABI. > > For other OSes, -mabi=altivec is the default, so -maltivec ju

Re: GCC 4.3.0 Status Report (2008-02-14)

I misread Janis's latest patch that I approved. The patch was suppose to enable -mabi=altivec when -maltivec is enabled, not change the default ABI. For other OSes, -mabi=altivec is the default, so -maltivec just works and produces correct code. If a user enables -maltive

Re: GCC 4.3.0 Status Report (2008-02-14)

Daniel Jacobowitz wrote: On Mon, Feb 18, 2008 at 03:25:03PM -0500, Jakub Jelinek wrote: What would break if in non-altivec ABI all Altivec registers are either fixed (-mno-altivec) or call-used (-maltivec)? I still suggest that the correct choice is to use the same set of call-used and call-sa

Re: GCC 4.3.0 Status Report (2008-02-14)

On Mon, 2008-02-18 at 17:21 -0500, David Edelsohn wrote: > > Janis Johnson writes: > > Janis> I have a patch, written since this thread started, that saves and > Janis> restores AltiVec registers based on TARGET_ALTIVEC instead of > Janis> TARGET_ALTIVEC_ABI. It passes gcc.target/powerpc test

Re: GCC 4.3.0 Status Report (2008-02-14)

> Janis Johnson writes: Janis> I have a patch, written since this thread started, that saves and Janis> restores AltiVec registers based on TARGET_ALTIVEC instead of Janis> TARGET_ALTIVEC_ABI. It passes gcc.target/powerpc tests and 176.gcc Janis> with "-O3 -maltivec -mabi=no-altivec". I'll p

Re: GCC 4.3.0 Status Report (2008-02-14)

On Mon, 2008-02-18 at 16:12 -0500, Jakub Jelinek wrote: > On Mon, Feb 18, 2008 at 03:57:10PM -0500, Daniel Jacobowitz wrote: > > On Mon, Feb 18, 2008 at 03:25:03PM -0500, Jakub Jelinek wrote: > > > What would break if in non-altivec ABI all Altivec registers are either > > > fixed (-mno-altivec) or

Re: GCC 4.3.0 Status Report (2008-02-14)

On Mon, Feb 18, 2008 at 03:57:10PM -0500, Daniel Jacobowitz wrote: > On Mon, Feb 18, 2008 at 03:25:03PM -0500, Jakub Jelinek wrote: > > What would break if in non-altivec ABI all Altivec registers are either > > fixed (-mno-altivec) or call-used (-maltivec)? > > I still suggest that the correct ch

Re: GCC 4.3.0 Status Report (2008-02-14)

On Mon, 2008-02-18 at 15:25 -0500, Jakub Jelinek wrote: > On Mon, Feb 18, 2008 at 09:29:22AM -0800, Janis Johnson wrote: > > PR target/34526 doesn't show up as a regression but it is in that > > on powerpc-linux "-O3 -mcpu=970" now includes -ftree-vectorize > > and with the default, non-AltiVec ABI

Re: GCC 4.3.0 Status Report (2008-02-14)

On Mon, Feb 18, 2008 at 03:25:03PM -0500, Jakub Jelinek wrote: > What would break if in non-altivec ABI all Altivec registers are either > fixed (-mno-altivec) or call-used (-maltivec)? I still suggest that the correct choice is to use the same set of call-used and call-saved registers without the

Re: GCC 4.3.0 Status Report (2008-02-14)

Jakub, PPC970 and POWER6 support Altivec and that feature is enabled for those processor by default. Now with inlining, auto-vectorization, and copying via Altivec registers, GCC needs to save and restore the registers correctly for overlapped use enabled implicitly. PPC64 Linux enables

Re: GCC 4.3.0 Status Report (2008-02-14)

On Mon, Feb 18, 2008 at 09:29:22AM -0800, Janis Johnson wrote: > PR target/34526 doesn't show up as a regression but it is in that > on powerpc-linux "-O3 -mcpu=970" now includes -ftree-vectorize > and with the default, non-AltiVec ABI vector registers can be > clobbered by other functions in the s

Re: GCC 4.3.0 Status Report (2008-02-14)

PR target/34526 doesn't show up as a regression but it is in that on powerpc-linux "-O3 -mcpu=970" now includes -ftree-vectorize and with the default, non-AltiVec ABI vector registers can be clobbered by other functions in the same call tree. An example of this is 176.gcc from SPEC CPU2000. The f

Re: GCC 4.3.0 Status Report (2008-02-14)

Joseph S. Myers wrote: On Thu, 14 Feb 2008, Joel Sherrill wrote: Alexandre Pereira Nunes wrote: Also regarding ARM, PR31849 (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31849 ) is a show stopper, at least for some embedded bare metal t

Re: GCC 4.3.0 Status Report (2008-02-14)

"Joseph S. Myers" <[EMAIL PROTECTED]> writes: > On Fri, 15 Feb 2008, Ralf Corsepius wrote: > >> > 2007-09-26 Joseph Myers <[EMAIL PROTECTED]> >> > >> >* config/m68k/m68k.h (DWARF_CIE_DATA_ALIGNMENT): Define. >> > >> > Index: gcc/config/m68k/m68k.h >> > =

Re: GCC 4.3.0 Status Report (2008-02-14)

On Fri, 15 Feb 2008, Ralf Corsepius wrote: > > 2007-09-26 Joseph Myers <[EMAIL PROTECTED]> > > > > * config/m68k/m68k.h (DWARF_CIE_DATA_ALIGNMENT): Define. > > > > Index: gcc/config/m68k/m68k.h > > === > > --- gcc/config/m68k/

Re: GCC 4.3.0 Status Report (2008-02-14)

On 15/02/2008, Ralf Corsepius <[EMAIL PROTECTED]> wrote: > > On Thu, 2008-02-14 at 22:17 +, Joseph S. Myers wrote: > > On Thu, 14 Feb 2008, Joel Sherrill wrote: > > > > The m68k/coldfire is suffering from this regression the > > > RTEMS community really would like to see resolved. > > > >

Re: GCC 4.3.0 Status Report (2008-02-14)

On Thu, 2008-02-14 at 22:17 +, Joseph S. Myers wrote: > On Thu, 14 Feb 2008, Joel Sherrill wrote: > > The m68k/coldfire is suffering from this regression the > > RTEMS community really would like to see resolved. > > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35088 > > Please try this

Re: GCC 4.3.0 Status Report (2008-02-14)

On Thu, 14 Feb 2008, Joel Sherrill wrote: > Alexandre Pereira Nunes wrote: > > Also regarding ARM, PR31849 > > (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31849 > > ) is a show stopper, > > at least for some embedded bare metal targets, i.e. arm-

Re: GCC 4.3.0 Status Report (2008-02-14)

On Thu, Feb 14, 2008 at 10:42 PM, Joel Sherrill <[EMAIL PROTECTED]> wrote: > > Richard Guenther wrote: > > On Thu, Feb 14, 2008 at 7:42 PM, Joel Sherrill > > <[EMAIL PROTECTED]> wrote: > > > >> Alexandre Pereira Nunes wrote: > >> > Also regarding ARM, PR31849 > >> > (http://gcc.gnu.org/bugz

Re: GCC 4.3.0 Status Report (2008-02-14)

Richard Guenther wrote: On Thu, Feb 14, 2008 at 7:42 PM, Joel Sherrill <[EMAIL PROTECTED]> wrote: Alexandre Pereira Nunes wrote: > Also regarding ARM, PR31849 > (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31849 > ) is a show stopper, > a

Re: GCC 4.3.0 Status Report (2008-02-14)

Richard Guenther escreveu: On Thu, Feb 14, 2008 at 7:28 PM, Alexandre Pereira Nunes <[EMAIL PROTECTED]> wrote: Also regarding ARM, PR31849 (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31849 ) is a show stopper, at least for some embedded b

Re: GCC 4.3.0 Status Report (2008-02-14)

On Thu, Feb 14, 2008 at 7:42 PM, Joel Sherrill <[EMAIL PROTECTED]> wrote: > > Alexandre Pereira Nunes wrote: > > Also regarding ARM, PR31849 > > (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31849 > > ) is a show stopper, > > at least for some e

Re: GCC 4.3.0 Status Report (2008-02-14)

On Thu, Feb 14, 2008 at 7:28 PM, Alexandre Pereira Nunes <[EMAIL PROTECTED]> wrote: > Also regarding ARM, PR31849 > (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31849 > ) is a show stopper, > at least for some embedded bare metal targets, i.e. a

Re: GCC 4.3.0 Status Report (2008-02-14)

On Thu, Feb 14, 2008 at 11:55 AM, H.J. Lu <[EMAIL PROTECTED]> wrote: > Gcc 4.3 can't compile the current FSF binutils on Linux/ia32. And this is not a bug in GCC. The binutils sources actually do violate C/C++ aliasing rules. It comes down to taking the address of the field of the union and then

Re: GCC 4.3.0 Status Report (2008-02-14)

Hi, I opened one: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35200 Gcc 4.3 can't compile the current FSF binutils on Linux/ia32. H.J. --- On Thu, Feb 14, 2008 at 3:47 AM, Jakub Jelinek <[EMAIL PROTECTED]> wrote: > Status > == > > We are in Stage 3 and the trunk is open for regression an

Re: GCC 4.3.0 Status Report (2008-02-14)

Alexandre Pereira Nunes wrote: Also regarding ARM, PR31849 (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31849 ) is a show stopper, at least for some embedded bare metal targets, i.e. arm-elf and arm-none-eabi. Until size optimization at least ma

Re: GCC 4.3.0 Status Report (2008-02-14)

Also regarding ARM, PR31849 (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31849 ) is a show stopper, at least for some embedded bare metal targets, i.e. arm-elf and arm-none-eabi. Until size optimization at least matches gcc 4.2, gcc 4.3 will

Re: GCC 4.3.0 Status Report (2008-02-14)

Hi, Any chance of someone with ARM knowledge dealing with this issue before the branch is cut. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35071 Uros Bizjak thinks it is just a typo in an assembly file but no one who has commented on this PR is comfortable saying that. Just a wild guess, coul

Re: GCC 4.3.0 Status Report (2008-02-14)

g++ 4.3 broken on OpenBSD, see: http://gcc.gnu.org/ml/libstdc++/2008-02/msg00034.html Dongsheng 2008/2/14, Jakub Jelinek <[EMAIL PROTECTED]>: > Status > == > > We are in Stage 3 and the trunk is open for regression and documentation > fixes only. We have reached our goal of zero open P1 r