RE: 3.4.1 release notes, round two

["Dave Murphy" <wintermute2k4 at ntlworld dot com>]

Hi

Just been looking through some of the powerpc specific bugs

> -----Original Message-----
> From: gcc-owner@gcc.gnu.org [mailto:gcc-owner@gcc.gnu.org]On Behalf Of
> Joe Buck
> Sent: 02 July 2004 18:05
> To: gcc@gcc.gnu.org
> Subject: 3.4.1 release notes, round two
> 
> PowerPC-specific
> 
> 11591 ICE in gcc.dg/altivec-5.c

listed as fixed in bugzilla
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11591

The patch seems to have been applied in the 3.4.1 release candidate

> 12028 powerpc-eabispe produces bad sCOND operation

http://gcc.gnu.org/ml/gcc-patches/2004-04/msg01926.html

> 14478 rs6000 geu/ltu patterns generate incorrect code

listed as fixed in bugzilla
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14478

The patch seems to have been applied in the 3.4.1 release candidate

> 14567 long double and va_arg complex args

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14567

ditto

> 14715 Altivec stack layout may overlap gpr save with stack temps

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14715

ditto

> 14902 (libstdc++) Stream checking functions fail when -pthread 
> option is used.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14902

fixed with IBM assembler patches

> 14924 Compiler ICE on valid code

http://gcc.gnu.org/ml/gcc-patches/2004-05/msg01701.html

> 14960 -maltivec affects vector return with -mabi=no-altivec

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14960

The patch seems to have been applied in the 3.4.1 release candidate

> 15106 vector varargs failure passing from altivec to non-altivec 
> code for -m32

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15106
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15191

ditto

> 16026 ICE in function.c:4804, assign_parms, when -mpowerpc64 & half-word
>       operation

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16026

ditto

> 15191 -maltivec -mabi=no-altivec results in mis-aligned lvx and stvx

see 15106 above

> 15662 Segmentation fault when an exception is thrown - even if 
> try and catch are specified
 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15662

Dave