[Bug tree-optimization/35468] LHS of assignment can be folded to a constant causing ICE

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2008-03-06 10:35 ---
(later)


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2008-03-05 15:27:56 |2008-03-06 10:35:49
   date||


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

[Bug tree-optimization/35468] LHS of assignment can be folded to a constant causing ICE

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2008-03-06 10:10 ---
Actually, CCP propagates the invariant address in

  D.1547_2 = &"/dev/ptyXX"[8];
  *D.1547_2 ={v} 1;

which we cannot undo easily, so we indeed should fold the stmt to a
trap representation.


-- 


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

[Bug fortran/35423] Implement OpenMP workshare

[jakub at gcc dot gnu dot org]

--- Comment #1 from jakub at gcc dot gnu dot org  2008-03-06 11:20 ---
This is not middle-end thing, all that is needed is change fortran FE to lower
(some forms of ) !$omp workshare constructs into some other standard
worksharing construct than single, particularly into OMP_FOR or perhaps
sometimes OMP_SECTIONS or OMP_SINGLE just for one or a couple of lines rather
than the whole !$omp workshare.
I don't plan to work on this myself, but any of the numerous Fortran FE
maintainers could do this, I can help with advice if needed.
Either code to expand the implicit loops in expressions will need to be
duplicated, or tweaked (e.g. add a flag to them, which would result in OMP_FOR
loops being created rather than normal loops).


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|middle-end  |fortran


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

[Bug target/35466] Different assembly codes on 32bit and 64bit hosts

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2008-03-06 09:43 ---
Indeed.  Maybe we should finally change the default.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID


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

[Bug tree-optimization/35468] LHS of assignment can be folded to a constant causing ICE

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2008-03-06 10:34 ---
Created an attachment (id=15268)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15268&action=view)
patch

Like with this patch.


-- 


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

[Bug fortran/35478] New: internal compiler error: Segmentation fault

[dennis dot wassel at googlemail dot com]

When trying to build some data processing stuff (using an interface for some
median functions in a module), I get an "internal compiler error: Segmentation
fault".
This code snippet should *not* compile anyway (there being no median function
taking two arguments) but I think a compiler segfault is a rather drastic way
of telling me :-)


 Command line:

gfortran -v -save-temps -c main.f90


 Compiler output:

Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /home/dwassel/Installationen/gcc-4.2.3/configure
--prefix=/home/dwassel --program-suffix=-4.2.3 --enable-languages=c,c++,fortran
--with-gmp=/home/dwassel --with-mpfr=/home/dwassel --with-arch=i686
--with-tune=i686
Thread model: posix
gcc version 4.2.3
 /localdata/bin/../libexec/gcc/i686-pc-linux-gnu/4.2.3/f951 main.f90 -quiet
-dumpbase main.f90 -mtune=i686 -march=i686 -auxbase main -version -I
/localdata/bin/../lib/gcc/i686-pc-linux-gnu/4.2.3/finclude -o main.s
GNU F95 version 4.2.3 (i686-pc-linux-gnu)
compiled by GNU C version 4.2.3.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
main.f90:46.9:

  data = median(rawData, work)
1
Error: There is no specific function for the generic 'median' at (1)
main.f90:19: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.

-
 My System:
-
Linux version 2.6.18-6-k7 (Debian 2.6.18.dfsg.1-18etch1) ([EMAIL PROTECTED])
(gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #1 SMP Sun Feb 10
22:16:15 UTC 2008

---
 The original source code (main.f90):
---
MODULE auxiliary

  IMPLICIT NONE

  INTEGER, PARAMETER, PRIVATE :: dp = SELECTED_REAL_KIND(15)

  INTERFACE median
 MODULE PROCEDURE R_valmed, I_valmed, D_valmed
  END INTERFACE

  PUBLIC  :: median
  PRIVATE :: R_valmed, I_valmed, D_valmed

CONTAINS

  RECURSIVE FUNCTION D_valmed (XDONT) RESULT (res_med)
Real (kind=dp), Dimension (:), Intent (In) :: XDONT
Real (kind=dp) :: res_med
res_med = 0.0d0
  END FUNCTION D_valmed

  RECURSIVE FUNCTION R_valmed (XDONT) RESULT (res_med)
Real, Dimension (:), Intent (In) :: XDONT
Real :: res_med
res_med = 0.0
  END FUNCTION R_valmed

  RECURSIVE FUNCTION I_valmed (XDONT) RESULT (res_med)
Integer, Dimension (:), Intent (In)  :: XDONT
Integer :: res_med
res_med = 0
  END FUNCTION I_valmed

END MODULE auxiliary


PROGRAM main

  USE auxiliary

  IMPLICIT NONE

  INTEGER, PARAMETER:: dp = SELECTED_REAL_KIND(15)
  REAL(kind=dp) :: rawData(2), data, work(3)

  data = median(rawData, work)

END PROGRAM main


---
 -save-temp output (main.s):
---
.file   "main.f90"
.text
.globl __auxiliary__i_valmed
.type   __auxiliary__i_valmed, @function
__auxiliary__i_valmed:
pushl   %ebp
movl%esp, %ebp
subl$16, %esp
movl$0, -4(%ebp)
movl-4(%ebp), %eax
leave
ret
.size   __auxiliary__i_valmed, .-__auxiliary__i_valmed
.globl __auxiliary__r_valmed
.type   __auxiliary__r_valmed, @function
__auxiliary__r_valmed:
pushl   %ebp
movl%esp, %ebp
subl$20, %esp
movl$0x, %eax
movl%eax, -4(%ebp)
movl-4(%ebp), %eax
movl%eax, -20(%ebp)
flds-20(%ebp)
leave
ret
.size   __auxiliary__r_valmed, .-__auxiliary__r_valmed
.globl __auxiliary__d_valmed
.type   __auxiliary__d_valmed, @function
__auxiliary__d_valmed:
pushl   %ebp
movl%esp, %ebp
subl$16, %esp
fldz
fstpl   -8(%ebp)
fldl-8(%ebp)
leave
ret
.size   __auxiliary__d_valmed, .-__auxiliary__d_valmed


-- 
   Summary: internal compiler error: Segmentation fault
   Product: gcc
   Version: 4.2.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dennis dot wassel at googlemail dot com
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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

[Bug fortran/35478] internal compiler error: Segmentation fault

[dominiq at lps dot ens dot fr]

--- Comment #1 from dominiq at lps dot ens dot fr  2008-03-06 10:57 ---
Confirmed with 4.2.3, fixed at least in 4.3.0 2008021 and  trunk (4.4.0):

pr35478.f90:46.9:

  data = median(rawData, work)
1
Error: There is no specific function for the generic 'median' at (1)


-- 


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

[Bug fortran/33197] Fortran 2008: math functions

[fxcoudert at gcc dot gnu dot org]

--- Comment #13 from fxcoudert at gcc dot gnu dot org  2008-03-06 12:45 
---
Remaining tasks in this PR: taking care of math functions that now accept
complex args (in particular, A{SIN,COS,TAN}{,H}), taking care of the two
arguments form of ATAN, and deal with the 3 args form of BESSEL_JN and
BESSEL_YN.


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|Fortran 2008: math functions|Fortran 2008: math functions
   |and other small changes |


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

[Bug fortran/33197] Fortran 2008: math functions and other small changes

[fxcoudert at gcc dot gnu dot org]

--- Comment #12 from fxcoudert at gcc dot gnu dot org  2008-03-06 12:41 
---
Subject: Bug 33197

Author: fxcoudert
Date: Thu Mar  6 12:40:28 2008
New Revision: 132970

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132970
Log:
PR fortran/33197
* intrinsic.c (add_functions): Add simplification routines for
ERF, DERF, ERFC and DERFC.
* decl.c (gfc_match_suffix, gfc_match_subroutine): Change GNU
extensions into Fortran 2008 features.
* intrinsic.h (gfc_simplify_erf, gfc_simplify_erfc): New
prototypes.
* simplify.c (gfc_simplify_erf, gfc_simplify_erfc): New functions.

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/decl.c
trunk/gcc/fortran/intrinsic.c
trunk/gcc/fortran/intrinsic.h
trunk/gcc/fortran/simplify.c


-- 


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

[Bug fortran/33197] Fortran 2008: math functions

[fxcoudert at gcc dot gnu dot org]

--- Comment #15 from fxcoudert at gcc dot gnu dot org  2008-03-06 13:15 
---
(In reply to comment #14)
> I think also missing are:
> - Compile-time evaluation of erfc_scaled

Right. A though one.

> - Implementation of NORM2

There are quite a few other new F2008 intrinsics, including other
transformational intrinsics, so I think it's better to focus this PR on math
intrinsics.


-- 


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

[Bug fortran/33197] Fortran 2008: math functions

[burnus at gcc dot gnu dot org]

--- Comment #14 from burnus at gcc dot gnu dot org  2008-03-06 13:10 ---
> Remaining tasks in this PR: [...]
I think also missing are:
- Compile-time evaluation of erfc_scaled
- Implementation of NORM2


-- 


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

[Bug target/35466] Different assembly codes on 32bit and 64bit hosts

[jsm28 at gcc dot gnu dot org]

--- Comment #6 from jsm28 at gcc dot gnu dot org  2008-03-06 13:51 ---
Then we should fix this bug by requiring 64-bit HOST_WIDE_INT for x86 targets
rather than by declaring it will never be fixed.  It can be closed when we've
switched to 64-bit HOST_WIDE_INT (or as a duplicate if we already have a bug
open for the issue).  I don't recall any disagreement to the stated importance
of generating the same code independent of host.

http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01598.html "I do think that
generating the same code, independent of host system, is
a very important property of GCC's design, just like generating the same
code independent of whether or not we're compiling with -g."

http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01789.html "I've always thought
these principles were meant to be sacrosanct"


-- 

jsm28 at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|WONTFIX |


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

[Bug fortran/33197] Fortran 2008: math functions

[burnus at gcc dot gnu dot org]

--- Comment #16 from burnus at gcc dot gnu dot org  2008-03-06 13:50 ---
(In reply to comment #15)
> > - Implementation of NORM2
> There are quite a few other new F2008 intrinsics, including other
> transformational intrinsics, so I think it's better to focus this PR on math
> intrinsics.

I would regard the L2 norm as mathematical
(http://mathworld.wolfram.com/L2-Norm.html)
y = NORM2(x) is for rank one arrays simply:

y = 0
do i=lbound(x,dim=1),ubound(x,dim=1)
   y = y + x(i)**2
enddo
y = sqrt(y).

For a rank-one, size-two array it is the same as hypot(x(1),x(2)). Actually,
using hypot is an optimization one should do for size-2 arrays.


-- 


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

[Bug target/35466] Different assembly codes on 32bit and 64bit hosts

[jsm28 at gcc dot gnu dot org]

--- Comment #4 from jsm28 at gcc dot gnu dot org  2008-03-06 13:32 ---
Different code for the same target on different hosts is a valid bug, not
INVALID.  If a target works with more than one HOST_WIDE_INT setting, the
choice should not affect the code generated; this is separate from the question
of whether x86 targets should allow 32-bit HOST_WIDE_INT.


-- 

jsm28 at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |


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

[Bug c++/35480] New: Relational operators for don't error on different sized tuples

[gryan at akoostix dot com]

According to the 6.1.3.5 [tr.tuple.rel], there is an implicit dependencies on
the sizes of the tuples being compared, and there should be a compilation
failure if the tuples are not the same size.

However I am not seeing compilation errors in this case. The following example
compiles and runs. Below that is the output from compilation with " g++ -v
-save-temps".

#include 
int main()
{
  std::tr1::tuple t1( 1 );
  std::tr1::tuple t2( 1, 2 );
  if ( t1 < t2 ) {}
  if ( t1 == t2 ) {}
}

1$ g++ -v -save-temps tuples.cpp 
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--with-gxx-include-dir=/usr/include/c++/4.1.3 --program-suffix=-4.1
--enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug
--enable-mpfr --enable-checking=release i486-linux-gnu
Thread model: posix
gcc version 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)
 /usr/lib/gcc/i486-linux-gnu/4.1.3/cc1plus -E -quiet -v -D_GNU_SOURCE
tuples.cpp -mtune=generic -fpch-preprocess -o tuples.ii
ignoring nonexistent directory "/usr/local/include/i486-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc/i486-linux-gnu/4.1.3/../../../../i486-linux-gnu/include"
ignoring nonexistent directory "/usr/include/i486-linux-gnu"
#include "..." search starts here:
#include <...> search starts here:
 /usr/include/c++/4.1.3
 /usr/include/c++/4.1.3/i486-linux-gnu
 /usr/include/c++/4.1.3/backward
 /usr/local/include
 /usr/lib/gcc/i486-linux-gnu/4.1.3/include
 /usr/include
End of search list.
 /usr/lib/gcc/i486-linux-gnu/4.1.3/cc1plus -fpreprocessed tuples.ii -quiet
-dumpbase tuples.cpp -mtune=generic -auxbase tuples -version -fstack-protector
-fstack-protector -o tuples.s
GNU C++ version 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)
(i486-linux-gnu)
compiled by GNU C version 4.1.3 20070929 (prerelease) (Ubuntu
4.1.2-16ubuntu2).
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 3cc47be363985179cfafdceddd0e8f5d
 as --traditional-format -V -Qy -o tuples.o tuples.s
GNU assembler version 2.18 (i486-linux-gnu) using BFD version (GNU Binutils for
Ubuntu) 2.18
 /usr/lib/gcc/i486-linux-gnu/4.1.3/collect2 --eh-frame-hdr -m elf_i386
--hash-style=both -dynamic-linker /lib/ld-linux.so.2
/usr/lib/gcc/i486-linux-gnu/4.1.3/../../../../lib/crt1.o
/usr/lib/gcc/i486-linux-gnu/4.1.3/../../../../lib/crti.o
/usr/lib/gcc/i486-linux-gnu/4.1.3/crtbegin.o
-L/usr/lib/gcc/i486-linux-gnu/4.1.3 -L/usr/lib/gcc/i486-linux-gnu/4.1.3
-L/usr/lib/gcc/i486-linux-gnu/4.1.3/../../../../lib -L/lib/../lib
-L/usr/lib/../lib tuples.o -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc
/usr/lib/gcc/i486-linux-gnu/4.1.3/crtend.o
/usr/lib/gcc/i486-linux-gnu/4.1.3/../../../../lib/crtn.o


-- 
   Summary: Relational operators for  don't error on
different sized tuples
   Product: gcc
   Version: 4.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gryan at akoostix dot com


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

[Bug c++/35480] Relational operators for don't error on different sized tuples

[gryan at akoostix dot com]

--- Comment #1 from gryan at akoostix dot com  2008-03-06 14:30 ---
Created an attachment (id=15269)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15269&action=view)
Preprocessed file

Preprocessed file output using the -save-temps flag.


-- 


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

[Bug target/35466] Different assembly codes on 32bit and 64bit hosts

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2008-03-06 13:38 ---
32bit HWI cannot represent 128bit constants.  If you are lucky and it works as
far as creating code you should not be surprised that some constants might
be forced to memory.  The only chance to generate the same code in this context
is to pessimize code generation for 64bit HWI.  We are not going to do that.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||WONTFIX


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

[Bug rtl-optimization/33642] unrecognizable insn for -frtl-abstract-sequences

[loki at gcc dot gnu dot org]

--- Comment #4 from loki at gcc dot gnu dot org  2008-03-06 15:01 ---
Created an attachment (id=15272)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15272&action=view)
Use own COMPUTE_RTX_LENGTH method

The previous patch wasn't a good solution for some targets.

This patch fixes the problem on i486-linux-gnu, arm-eabi, powerpc-elf.
I am still hunting for similar bugs.


-- 

loki at gcc dot gnu dot org changed:

   What|Removed |Added

  Attachment #15262|0   |1
is obsolete||


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

[Bug c/35481] New: GCC is not ported to AIX 5.3 / AIX 6.1

[Laurent dot Vivier at bull dot net]

file gcc/config/rs6000/aix61.h and gcc/config/rs6000/aix53.h are missing.
gcc/config.gcc doesn't manage aix6.1,


-- 
   Summary: GCC is not ported to AIX 5.3 / AIX 6.1
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Laurent dot Vivier at bull dot net
  GCC host triplet: powerpc-ibm-aix6.1.0.0


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

[Bug c++/35483] New: GCC on AIX doesn't support dollar in symbols name.

[Laurent dot Vivier at bull dot net]

When compiling libjava on AIX 6.1, gcc generates to the assembler symbols with
dollar inside.
But IBM "as" is not able to manage dollar in symbol names, so the compilation
fails.


-- 
   Summary: GCC on AIX doesn't support dollar in symbols name.
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Laurent dot Vivier at bull dot net
  GCC host triplet: powerpc-ibm-aix6.1.0.0


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

[Bug c/35481] GCC is not ported to AIX 5.3 / AIX 6.1

[Laurent dot Vivier at bull dot net]

--- Comment #2 from Laurent dot Vivier at bull dot net  2008-03-06 14:59 
---
Created an attachment (id=15271)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15271&action=view)
Add AIX 6.1 detection


-- 


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

[Bug c/35481] GCC is not ported to AIX 5.3 / AIX 6.1

[Laurent dot Vivier at bull dot net]

--- Comment #1 from Laurent dot Vivier at bull dot net  2008-03-06 14:58 
---
Created an attachment (id=15270)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15270&action=view)
Add AIX 5.3 and 6.1 definitions


-- 


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

[Bug libffi/35484] New: libffi doesn't support AIX 64bit

[Laurent dot Vivier at bull dot net]

When compiling libffi on AIX with ppc64 target, libffi fails.
Assembler parts of libffi manage only 32bit AIX.


-- 
   Summary: libffi doesn't support AIX 64bit
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libffi
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Laurent dot Vivier at bull dot net
  GCC host triplet: powerpc-ibm-aix6.1.0.0


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

[Bug java/35485] New: libjava is disabled by default

[Laurent dot Vivier at bull dot net]

GCC allows to compile gcj but libgcj is not generated.


-- 
   Summary: libjava is disabled by default
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Laurent dot Vivier at bull dot net
  GCC host triplet: powerpc-ibm-aix6.1.0.0


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

[Bug java/35485] libjava is disabled by default

[Laurent dot Vivier at bull dot net]

--- Comment #1 from Laurent dot Vivier at bull dot net  2008-03-06 15:28 
---
Created an attachment (id=15275)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15275&action=view)
enable libjava on AIX


-- 


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

[Bug libffi/35484] libffi doesn't support AIX 64bit

[Laurent dot Vivier at bull dot net]

--- Comment #1 from Laurent dot Vivier at bull dot net  2008-03-06 15:24 
---
Created an attachment (id=15274)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15274&action=view)
Add AIX 64bit support


-- 


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

[Bug c++/35483] GCC on AIX doesn't support dollar in symbols name.

[Laurent dot Vivier at bull dot net]

--- Comment #1 from Laurent dot Vivier at bull dot net  2008-03-06 15:14 
---
Created an attachment (id=15273)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15273&action=view)
This patch learns to gcc how to use IBM as with symbols with dollar inside.

This patch removes '$' from symbol names and replace them by "_".
It emits ".rename" pseudo-op to keep the good symbol name in the symbol table.

See
http://publib.boulder.ibm.com/infocenter/systems/index.jsp?topic=/com.ibm.aix.aixassem/doc/alangref/rename.htm


-- 


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

[Bug c++/35159] g++ and gfortran inoperable with no error message

[nightstrike at gmail dot com]

--- Comment #19 from nightstrike at gmail dot com  2008-03-06 16:08 ---
Ok, compiling the aforementioned "Hello, world!" program using "gfortran
--save-temps hello.f90" results in f951.exe maxing out the CPU forever.


-- 


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

[Bug libstdc++/35480] Relational operators for don't error on different sized tuples

[pcarlini at suse dot de]

--- Comment #2 from pcarlini at suse dot de  2008-03-06 16:27 ---
Frankly, I'm not 100% sure we want an error here: I mean, we have a "Requires"
violation in the case at issue, which, in general, in my reading of the
standard, certainly doesn't mean the code must not compile, means something
like "user, anything can happen, you are on your own". Certainly it would be
easy to add in the TR1 version, an __enable_if, but I would be more willing to
do that change to the TR1 version in case eventually the C++0x version will get
a concept enforcing equality of the sizes. Doug, is that in the plan?


-- 

pcarlini at suse dot de changed:

   What|Removed |Added

 CC||doug dot gregor at gmail dot
   ||com, pcarlini at suse dot de
  Component|c++ |libstdc++


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

[Bug libstdc++/35480] Relational operators for don't error on different sized tuples

[gryan at akoostix dot com]

--- Comment #3 from gryan at akoostix dot com  2008-03-06 16:38 ---
I understand your concern here, which is why I wrote that I thought that it was
"implicit".

The standard says "where get(t) == get(u)" is a valid expression" only,
however; 6.1.3.4 says that get(t) is "ill formed if I is out of bounds."

In the original proposal Jarvi writes "An attempt to compare two tuples of
different lengths results in a compile time error." This is co-operated by
Becker in his TR-1 book, where we writes "... can be compared if they have the
same number of elements..." But the standard itself isn't so explicit.

To me, if get(t) fails to compile under the assumption of "ill formed", then
by the definitions of 6.1.3.5, get(t) == get(u) should also fail to
compile. Although it is not explicitly stated in N1836=05-0096.

At least that's my interpretation of "ill-formed." Are all ill-formed
expression compilation errors?

On an aside, it would certainly be useless to have something compile and run
with no side effects (as it does) when the construct is clearly erroneous.


-- 


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

[Bug libstdc++/35480] Relational operators for don't error on different sized tuples

[pcarlini at suse dot de]

--- Comment #4 from pcarlini at suse dot de  2008-03-06 16:53 ---
(In reply to comment #3)
> To me, if get(t) fails to compile under the assumption of "ill formed", 
> then
> by the definitions of 6.1.3.5, get(t) == get(u) should also fail to
> compile. Although it is not explicitly stated in N1836=05-0096.

My exact point was that all the wording about get etc belongs to a **Requires**
clause, which is a *precondition*. In other terms, nothing says that the
implementation actually attempts those operations.

> On an aside, it would certainly be useless to have something compile and run
> with no side effects (as it does) when the construct is clearly erroneous.

Sure. But note that this problem also exists in O(1) other places in the
Standard, in particular with templates (when there are substantive hopes to
finally catch a bit more at compile-time in C++0x) but also without templates.


-- 


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

[Bug c/35481] GCC is not ported to AIX 5.3 / AIX 6.1

[rwild at gcc dot gnu dot org]

--- Comment #4 from rwild at gcc dot gnu dot org  2008-03-06 17:00 ---
but libjava/classpath/configure was forgotten:



-- 

rwild at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||Ralf dot Wildenhues at gmx
   ||dot de


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

[Bug libstdc++/35480] Relational operators for don't error on different sized tuples

[pcarlini at suse dot de]

--- Comment #5 from pcarlini at suse dot de  2008-03-06 17:00 ---
By the way, in the meanwhile I checked N2322 and C++0x will simply enforce
EqualityComparable...

We are presently trying to figure out whether in the meanwhile we want to
explicitly enforce sizeof...(TTypes) == sizeof...(UTypes)


-- 


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

Re: [Bug c/35481] GCC is not ported to AIX 5.3 / AIX 6.1

[Andrew Pinski]

This was done for GCC 4.3.0.

Sent from my iPhone

On Mar 6, 2008, at 6:58, "Laurent dot Vivier at bull dot net" <[EMAIL PROTECTED] 
> wrote:





--- Comment #1 from Laurent dot Vivier at bull dot net   
2008-03-06 14:58 ---

Created an attachment (id=15270)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15270&action=view)
Add AIX 5.3 and 6.1 definitions


--


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

[Bug c/35481] GCC is not ported to AIX 5.3 / AIX 6.1

[pinskia at gmail dot com]

--- Comment #3 from pinskia at gmail dot com  2008-03-06 16:40 ---
Subject: Re:  GCC is not ported to AIX 5.3 / AIX 6.1

This was done for GCC 4.3.0.

Sent from my iPhone

On Mar 6, 2008, at 6:58, "Laurent dot Vivier at bull dot net"
<[EMAIL PROTECTED] 
 > wrote:

>
>
> --- Comment #1 from Laurent dot Vivier at bull dot net   
> 2008-03-06 14:58 ---
> Created an attachment (id=15270)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15270&action=view)
> --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15270&action=view)
> Add AIX 5.3 and 6.1 definitions
>
>
> -- 
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35481
>


-- 


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

[Bug libstdc++/35480] Relational operators for don't error on different sized tuples

[chris at bubblescope dot net]

--- Comment #6 from chris at bubblescope dot net  2008-03-06 17:11 ---
While I agree that this is an issue of implementation detail, I thought there
was code already there to stop this case, except it is broken :(

Looking at the svn copy of tr1/tuple, you can see operator== (and others)
delegate to _tuple_compare, passing the first parameter:

tuple_size<_Tp>::value - tuple_size<_Tp>::value

Which should be:

tuple_size<_Tp>::value - tuple_size<_Up>::value

The template which accepts this is only implemented for this value being 0, so
any other value produces a compile time error.

I broke this (woops) in r91171, back in 2004. The code has continued to be
updated as tuple has changed, and no-one seems to have noticed it made no sense
;)


-- 

chris at bubblescope dot net changed:

   What|Removed |Added

 CC||chris at bubblescope dot net


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

[Bug c/35481] GCC is not ported to AIX 5.3 / AIX 6.1

[pinskia at gcc dot gnu dot org]

--- Comment #6 from pinskia at gcc dot gnu dot org  2008-03-06 17:18 ---
Fixed so closing as such.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.3.0


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

[Bug libstdc++/35480] Relational operators for don't error on different sized tuples

[pcarlini at suse dot de]

--- Comment #7 from pcarlini at suse dot de  2008-03-06 17:18 ---
Cool, if everything can be dealt with right now by simply fixing that, then
let's do it! Really, in these times, I dislike the idea of robustify templates
here and there (without a global neat strategy) with "old-times"
__enable_ifs...


-- 

pcarlini at suse dot de changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-03-06 17:18:45
   date||


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

[Bug target/33963] [4.3/4.4 Regression] Dllimport attribute wrongly accepted on typedefs

[jsm28 at gcc dot gnu dot org]

--- Comment #3 from jsm28 at gcc dot gnu dot org  2008-03-06 17:30 ---
Subject: Bug 33963

Author: jsm28
Date: Thu Mar  6 17:29:36 2008
New Revision: 132978

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132978
Log:
PR target/33963
* tree.c (handle_dll_attribute): Disallow TYPE_DECLs for types
other than structures and unions.

Modified:
branches/gcc-4_3-branch/gcc/ChangeLog
branches/gcc-4_3-branch/gcc/tree.c


-- 


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

[Bug target/33963] [4.3/4.4 Regression] Dllimport attribute wrongly accepted on typedefs

[jsm28 at gcc dot gnu dot org]

--- Comment #4 from jsm28 at gcc dot gnu dot org  2008-03-06 17:31 ---
Fixed in 4.3.1 and 4.4.0.


-- 

jsm28 at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to fail||4.3.0
  Known to work|4.2.0   |4.2.0 4.3.1 4.4.0
 Resolution||FIXED
   Target Milestone|4.3.0   |4.3.1


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

[Bug c/35481] GCC is not ported to AIX 5.3 / AIX 6.1

[rwild at gcc dot gnu dot org]

--- Comment #5 from rwild at gcc dot gnu dot org  2008-03-06 17:03 ---
Never mind, sorry about the noise.


-- 


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

[Bug c++/35323] [4.3 regression] ICE calling functions with fixed-point type parameter

[paolo at gcc dot gnu dot org]

--- Comment #3 from paolo at gcc dot gnu dot org  2008-03-06 17:51 ---
Subject: Bug 35323

Author: paolo
Date: Thu Mar  6 17:50:54 2008
New Revision: 132980

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132980
Log:
/cp
2008-03-06  Paolo Carlini  <[EMAIL PROTECTED]>

PR c++/35323
* name-lookup.c (arg_assoc_type): Handle FIXED_POINT_TYPE.

/testsuite
2008-03-06  Paolo Carlini  <[EMAIL PROTECTED]>

PR c++/35323
* g++.dg/lookup/crash7.C: New.

/cp
2008-03-06  Paolo Carlini  <[EMAIL PROTECTED]>

PR c++/35333
* error.c (dump_expr): Handle CONJ_EXPR.

/testsuite
2008-03-06  Paolo Carlini  <[EMAIL PROTECTED]>

PR c++/35333
* g++.dg/other/error26.C: New.

/cp
2008-03-06  Paolo Carlini  <[EMAIL PROTECTED]>

PR c++/35338
* error.c (dump_type): Handle FIXED_POINT_TYPE.
(dump_expr): Handle FIXED_CST.

/testsuite
2008-03-06  Paolo Carlini  <[EMAIL PROTECTED]>

PR c++/35338
* g++.dg/other/error25.C: New.

Added:
branches/gcc-4_3-branch/gcc/testsuite/g++.dg/lookup/crash7.C
branches/gcc-4_3-branch/gcc/testsuite/g++.dg/other/error25.C
branches/gcc-4_3-branch/gcc/testsuite/g++.dg/other/error26.C
Modified:
branches/gcc-4_3-branch/gcc/cp/ChangeLog
branches/gcc-4_3-branch/gcc/cp/error.c
branches/gcc-4_3-branch/gcc/cp/name-lookup.c
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/35333] [4.1/4.2/4.3 regression] Broken diagnostic for complex builtin

[paolo at gcc dot gnu dot org]

--- Comment #4 from paolo at gcc dot gnu dot org  2008-03-06 17:51 ---
Subject: Bug 35333

Author: paolo
Date: Thu Mar  6 17:50:54 2008
New Revision: 132980

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132980
Log:
/cp
2008-03-06  Paolo Carlini  <[EMAIL PROTECTED]>

PR c++/35323
* name-lookup.c (arg_assoc_type): Handle FIXED_POINT_TYPE.

/testsuite
2008-03-06  Paolo Carlini  <[EMAIL PROTECTED]>

PR c++/35323
* g++.dg/lookup/crash7.C: New.

/cp
2008-03-06  Paolo Carlini  <[EMAIL PROTECTED]>

PR c++/35333
* error.c (dump_expr): Handle CONJ_EXPR.

/testsuite
2008-03-06  Paolo Carlini  <[EMAIL PROTECTED]>

PR c++/35333
* g++.dg/other/error26.C: New.

/cp
2008-03-06  Paolo Carlini  <[EMAIL PROTECTED]>

PR c++/35338
* error.c (dump_type): Handle FIXED_POINT_TYPE.
(dump_expr): Handle FIXED_CST.

/testsuite
2008-03-06  Paolo Carlini  <[EMAIL PROTECTED]>

PR c++/35338
* g++.dg/other/error25.C: New.

Added:
branches/gcc-4_3-branch/gcc/testsuite/g++.dg/lookup/crash7.C
branches/gcc-4_3-branch/gcc/testsuite/g++.dg/other/error25.C
branches/gcc-4_3-branch/gcc/testsuite/g++.dg/other/error26.C
Modified:
branches/gcc-4_3-branch/gcc/cp/ChangeLog
branches/gcc-4_3-branch/gcc/cp/error.c
branches/gcc-4_3-branch/gcc/cp/name-lookup.c
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/35338] [4.3 regression] Broken diagnostics for fixed-point types

[paolo at gcc dot gnu dot org]

--- Comment #4 from paolo at gcc dot gnu dot org  2008-03-06 17:51 ---
Subject: Bug 35338

Author: paolo
Date: Thu Mar  6 17:50:54 2008
New Revision: 132980

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132980
Log:
/cp
2008-03-06  Paolo Carlini  <[EMAIL PROTECTED]>

PR c++/35323
* name-lookup.c (arg_assoc_type): Handle FIXED_POINT_TYPE.

/testsuite
2008-03-06  Paolo Carlini  <[EMAIL PROTECTED]>

PR c++/35323
* g++.dg/lookup/crash7.C: New.

/cp
2008-03-06  Paolo Carlini  <[EMAIL PROTECTED]>

PR c++/35333
* error.c (dump_expr): Handle CONJ_EXPR.

/testsuite
2008-03-06  Paolo Carlini  <[EMAIL PROTECTED]>

PR c++/35333
* g++.dg/other/error26.C: New.

/cp
2008-03-06  Paolo Carlini  <[EMAIL PROTECTED]>

PR c++/35338
* error.c (dump_type): Handle FIXED_POINT_TYPE.
(dump_expr): Handle FIXED_CST.

/testsuite
2008-03-06  Paolo Carlini  <[EMAIL PROTECTED]>

PR c++/35338
* g++.dg/other/error25.C: New.

Added:
branches/gcc-4_3-branch/gcc/testsuite/g++.dg/lookup/crash7.C
branches/gcc-4_3-branch/gcc/testsuite/g++.dg/other/error25.C
branches/gcc-4_3-branch/gcc/testsuite/g++.dg/other/error26.C
Modified:
branches/gcc-4_3-branch/gcc/cp/ChangeLog
branches/gcc-4_3-branch/gcc/cp/error.c
branches/gcc-4_3-branch/gcc/cp/name-lookup.c
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/35338] [4.3 regression] Broken diagnostics for fixed-point types

[pcarlini at suse dot de]

--- Comment #5 from pcarlini at suse dot de  2008-03-06 17:52 ---
Fixed for 4.3.1 too.


-- 

pcarlini at suse dot de changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
   Target Milestone|4.3.0   |4.3.1


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

[Bug c++/35333] [4.1/4.2 regression] Broken diagnostic for complex builtin

[pcarlini at suse dot de]

--- Comment #5 from pcarlini at suse dot de  2008-03-06 17:53 ---
Fixed for 4.3.1 too.


-- 

pcarlini at suse dot de changed:

   What|Removed |Added

 AssignedTo|pcarlini at suse dot de |unassigned at gcc dot gnu
   ||dot org
 Status|ASSIGNED|NEW
Summary|[4.1/4.2/4.3 regression]|[4.1/4.2 regression] Broken
   |Broken diagnostic for   |diagnostic for complex
   |complex builtin |builtin


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

[Bug c++/35323] [4.3 regression] ICE calling functions with fixed-point type parameter

[pcarlini at suse dot de]

--- Comment #4 from pcarlini at suse dot de  2008-03-06 17:53 ---
Fixed for 4.3.1 too.


-- 

pcarlini at suse dot de changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
   Target Milestone|4.3.0   |4.3.1


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

[Bug rtl-optimization/33009] [4.4 Regression] -frtl-abstract-sequences causes an ICE

[belyshev at depni dot sinp dot msu dot ru]

--- Comment #14 from belyshev at depni dot sinp dot msu dot ru  2008-03-06 
17:58 ---
It is now broken on trunk on x86_64-linux with -m32 -fPIC:

pr11832.c: In function 'foo':
pr11832.c:30: error: unrecognizable insn:
(insn 216pr11832.c:30: internal compiler error: Segmentation fault

And in the same way for pr33009.c.

Also fails on ia64: http://gcc.gnu.org/ml/gcc-testresults/2008-03/msg00409.html


-- 

belyshev at depni dot sinp dot msu dot ru changed:

   What|Removed |Added

 CC||belyshev at depni dot sinp
   ||dot msu dot ru
 Status|RESOLVED|REOPENED
  GCC build triplet|i386-linux-gnu  |
   GCC host triplet|i386-linux-gnu  |
 GCC target triplet|i386-linux-gnu  |
   Keywords||ice-on-valid-code
  Known to work||4.3.0
 Resolution|FIXED   |
Summary|-frtl-abstract-sequences|[4.4 Regression] -frtl-
   |causes an infinite loop |abstract-sequences causes an
   ||ICE
   Target Milestone|--- |4.4.0


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

[Bug preprocessor/35458] Dependency generation (-M) does not quote '#' in filenames

[tromey at gcc dot gnu dot org]

--- Comment #4 from tromey at gcc dot gnu dot org  2008-03-06 18:09 ---
Subject: Bug 35458

Author: tromey
Date: Thu Mar  6 18:08:40 2008
New Revision: 132982

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132982
Log:
libcpp
2008-03-06  Markus Milleder  <[EMAIL PROTECTED]>
PR preprocessor/35458
* mkdeps.c (munge): Quote '#' with a '\'.
gcc/testsuite
2008-03-06  Markus Milleder  <[EMAIL PROTECTED]>
PR preprocessor/35458
* gcc.dg/cpp/cmdlne-M-2.c: New file.
* gcc.dg/cpp/cmdlne-M-2#.h: New file.
* gcc.dg/cpp/#cmdlne-M-2.h: New file.

Added:
trunk/gcc/testsuite/gcc.dg/cpp/#cmdlne-M-2.h
trunk/gcc/testsuite/gcc.dg/cpp/cmdlne-M-2#.h
trunk/gcc/testsuite/gcc.dg/cpp/cmdlne-M-2.c
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/libcpp/ChangeLog
trunk/libcpp/mkdeps.c


-- 


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

[Bug preprocessor/35458] Dependency generation (-M) does not quote '#' in filenames

[tromey at gcc dot gnu dot org]

--- Comment #5 from tromey at gcc dot gnu dot org  2008-03-06 18:15 ---
I agree with comment #3.
This is an improvement.
Users concerned with real portability should be avoiding "#" anyhow.


-- 

tromey at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||tromey at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.4.0


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

[Bug rtl-optimization/33642] unrecognizable insn for -frtl-abstract-sequences

[dominiq at lps dot ens dot fr]

--- Comment #5 from dominiq at lps dot ens dot fr  2008-03-06 18:20 ---
Could the patch in comment #4 explain the following regressions?

FAIL: gcc.dg/bf-ms-layout-2.c execution test
FAIL: gcc.dg/bf-ms-layout.c execution test


-- 


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

[Bug fortran/33296] [4.3/4.4 regression] nearest(huge(1.0),1.0) gives an error

[burnus at gcc dot gnu dot org]

--- Comment #10 from burnus at gcc dot gnu dot org  2008-03-06 18:23 ---
> It seems things are now worse:
> next.c:91:  assertion failed: !mpfr_set_exp ((x), (exp + 1))
> f951: internal compiler error: Aborted

Works for me with 4.4.0 and 4.3.0 20080131/rev131976 and 4.3.0 (of today) on
x86_64.


-- 


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

[Bug testsuite/35406] gfortran.dg/ldist-1.f90 and gcc.dg/tree-ssa/ldist-4.c don't work

[belyshev at depni dot sinp dot msu dot ru]

--- Comment #2 from belyshev at depni dot sinp dot msu dot ru  2008-03-06 
18:34 ---
Both are testsuite bugs, apparently.

ldist-1.f90 scans for:
! { dg-final { scan-tree-dump-times "distributed: split to 4 loops" 1 "ldist" }
}

and the dump output is: "Loop 1 distributed: split to 5 loops."


And ldist-4.c is even xfailed in a weird way:
/* We used to distribute also innermost loops, but these could produce
   too much code in the outer loop, degrading performance of scalar
   code.  So this test is XFAILed because the cost model of the stand
   alone distribution pass has evolved.  */
/* { dg-final { scan-tree-dump-times "distributed: split to 2 loops" 0 "ldist"
} } */

and it works now:
FIXME: Loop 1 not distributed: it has more than two basic blocks.
Loop 2 distributed: split to 2 loops.


-- 

belyshev at depni dot sinp dot msu dot ru changed:

   What|Removed |Added

 CC||belyshev at depni dot sinp
   ||dot msu dot ru
   Severity|normal  |trivial
  Component|tree-optimization   |testsuite
   Last reconfirmed|2008-03-04 17:14:36 |2008-03-06 18:34:21
   date||


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

[Bug libstdc++/35480] Relational operators for don't error on different sized tuples

[paolo at gcc dot gnu dot org]

--- Comment #8 from paolo at gcc dot gnu dot org  2008-03-06 18:36 ---
Subject: Bug 35480

Author: paolo
Date: Thu Mar  6 18:35:26 2008
New Revision: 132983

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132983
Log:
2008-03-06  Chris Jefferson  <[EMAIL PROTECTED]>
Paolo Carlini  <[EMAIL PROTECTED]>

PR libstdc++/35480
* include/tr1/tuple (operator==, operator<): Fix.
* include/std/tuple (operator==, operator<): Likewise.
* testsuite/tr1/6_containers/tuple/comparison_operators/35480.cc: New.
* testsuite/20_util/tuple/comparison_operators/35480.cc: Likewise.

Added:
trunk/libstdc++-v3/testsuite/20_util/tuple/comparison_operators/35480.cc
   
trunk/libstdc++-v3/testsuite/tr1/6_containers/tuple/comparison_operators/35480.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/std/tuple
trunk/libstdc++-v3/include/tr1/tuple


-- 


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

[Bug libstdc++/35480] Relational operators for don't error on different sized tuples

[pcarlini at suse dot de]

--- Comment #10 from pcarlini at suse dot de  2008-03-06 18:37 ---
Fixed for 4.4.0 and 4.3.1.


-- 

pcarlini at suse dot de changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.3.1


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

[Bug libstdc++/35480] Relational operators for don't error on different sized tuples

[paolo at gcc dot gnu dot org]

--- Comment #9 from paolo at gcc dot gnu dot org  2008-03-06 18:36 ---
Subject: Bug 35480

Author: paolo
Date: Thu Mar  6 18:35:37 2008
New Revision: 132984

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132984
Log:
2008-03-06  Chris Jefferson  <[EMAIL PROTECTED]>
Paolo Carlini  <[EMAIL PROTECTED]>

PR libstdc++/35480
* include/tr1/tuple (operator==, operator<): Fix.
* include/std/tuple (operator==, operator<): Likewise.
* testsuite/tr1/6_containers/tuple/comparison_operators/35480.cc: New.
* testsuite/20_util/tuple/comparison_operators/35480.cc: Likewise.

Added:
   
branches/gcc-4_3-branch/libstdc++-v3/testsuite/20_util/tuple/comparison_operators/35480.cc
   
branches/gcc-4_3-branch/libstdc++-v3/testsuite/tr1/6_containers/tuple/comparison_operators/35480.cc
Modified:
branches/gcc-4_3-branch/libstdc++-v3/ChangeLog
branches/gcc-4_3-branch/libstdc++-v3/include/std/tuple
branches/gcc-4_3-branch/libstdc++-v3/include/tr1/tuple


-- 


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

[Bug fortran/35474] [4.3/4.4 regression] Reading module file with COMMON and EQUIVALENCE

[burnus at gcc dot gnu dot org]

--- Comment #2 from burnus at gcc dot gnu dot org  2008-03-06 19:03 ---
Paul, do you have an idea?

The ICE happens when reading the .mod for p->u.wsym.sym->name == "i" in
free_pi_tree:
  if (p->fixup != NULL)
gfc_internal_error ("free_pi_tree(): Unresolved fixup");

I got somehow lost in module.c when trying to track 'fixup'. See comment 1 for
your patch which caused the regression. Still, I cannot see anything which is
obviously wrong.

Just for fun, I set p->fixup = NULL in mio_symtree_ref (see your patch), then
one gets the error that COMMON 'c' does not exist.


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pault at gcc dot gnu dot org


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

[Bug rtl-optimization/33642] unrecognizable insn for -frtl-abstract-sequences

[dominiq at lps dot ens dot fr]

--- Comment #6 from dominiq at lps dot ens dot fr  2008-03-06 19:18 ---
With the patch from comment #4 I get onpowerpc-apple-darwin9:

[karma] f90/bug% gfc -c -frtl-abstract-sequences
/opt/gcc/_gcc_clean/gcc/testsuite/gcc.c-torture/compile/pr11832.c
/opt/gcc/_gcc_clean/gcc/testsuite/gcc.c-torture/compile/pr11832.c: In function
'foo':
/opt/gcc/_gcc_clean/gcc/testsuite/gcc.c-torture/compile/pr11832.c:30: error:
insn does not satisfy its constraints:
(jump_insn 322 95 323
/opt/gcc/_gcc_clean/gcc/testsuite/gcc.c-torture/compile/pr11832.c:16 (set (pc)
(reg:SI 3 r3)) 519 {*indirect_jumpsi} (nil))
/opt/gcc/_gcc_clean/gcc/testsuite/gcc.c-torture/compile/pr11832.c:30: internal
compiler error: in final_scan_insn, at final.c:2552
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
[karma] f90/bug% gfc -c -frtl-abstract-sequences
/opt/gcc/_gcc_clean/gcc/testsuite/gcc.c-torture/compile/pr33009.c
/opt/gcc/_gcc_clean/gcc/testsuite/gcc.c-torture/compile/pr33009.c: In function
'foo':
/opt/gcc/_gcc_clean/gcc/testsuite/gcc.c-torture/compile/pr33009.c:36: error:
insn does not satisfy its constraints:
(jump_insn 145 87 146
/opt/gcc/_gcc_clean/gcc/testsuite/gcc.c-torture/compile/pr33009.c:32 (set (pc)
(reg:SI 6 r6)) 519 {*indirect_jumpsi} (nil))
/opt/gcc/_gcc_clean/gcc/testsuite/gcc.c-torture/compile/pr33009.c:36: internal
compiler error: in final_scan_insn, at final.c:2552
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

in both 32 and 64 bit modes.


-- 


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

[Bug libffi/35484] libffi doesn't support AIX 64bit

[green at redhat dot com]

--- Comment #2 from green at redhat dot com  2008-03-06 19:40 ---
Thanks for this patch.  If you haven't already done so, please submit it to
[EMAIL PROTECTED]  Be sure to include proper ChangeLog entries.

Thanks!

AG


-- 


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

[Bug other/35486] New: Can't build gimple-tuples-branch

[mstein at phenix dot rootshell dot be]

Hi!
I get this when building gimple-tuples-branch (rev 132972) on x86_64/debian 4:

echo '[c]' >> tmp-gi.list
echo '/home/mstein/svn/gimple-tuples-branch/gcc/c-lang.c' >> tmp-gi.list
echo '/home/mstein/svn/gimple-tuples-branch/gcc/c-tree.h' >> tmp-gi.list
echo '/home/mstein/svn/gimple-tuples-branch/gcc/c-decl.c' >> tmp-gi.list
echo '/home/mstein/svn/gimple-tuples-branch/gcc/c-common.c' >> tmp-gi.list
echo '/home/mstein/svn/gimple-tuples-branch/gcc/c-common.h' >> tmp-gi.list
echo '/home/mstein/svn/gimple-tuples-branch/gcc/c-pragma.h' >> tmp-gi.list
echo '/home/mstein/svn/gimple-tuples-branch/gcc/c-pragma.c' >> tmp-gi.list
echo '/home/mstein/svn/gimple-tuples-branch/gcc/c-objc-common.c' >> tmp-gi.list
echo '/home/mstein/svn/gimple-tuples-branch/gcc/c-parser.c' >> tmp-gi.list
/bin/sh /home/mstein/svn/gimple-tuples-branch/gcc/../move-if-change tmp-gi.list
gtyp-input.list
echo timestamp > s-gtyp-input
build/gengtype /home/mstein/svn/gimple-tuples-branch/gcc gtyp-input.list
make[3]: *** [s-gtype] Segmentation fault
make[3]: Leaving directory `/home/mstein/obj/gimple-tuples-branch/gcc'
make[2]: *** [all-stage2-gcc] Error 2
make[2]: Leaving directory `/home/mstein/obj/gimple-tuples-branch'
make[1]: *** [stage2-bubble] Error 2
make[1]: Leaving directory `/home/mstein/obj/gimple-tuples-branch'
make: *** [bootstrap] Error 2


-- 
   Summary: Can't build gimple-tuples-branch
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mstein at phenix dot rootshell dot be
  GCC host triplet: x86_64-unknown-linux-gnu


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

[Bug other/35486] Can't build gimple-tuples-branch

[dnovillo at gcc dot gnu dot org]

--- Comment #1 from dnovillo at gcc dot gnu dot org  2008-03-06 20:01 
---

Thanks.  This is known and I'm working on a fix.  In the meantime, you can get
a clean build of the branch if you configure with --disable-bootstrap
--disable-libmudflap --disable-libgomp --enable-languages=c,fortran.


-- 


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

[Bug tree-optimization/35402] Store CCP will not inline static const variable which is default initialized

[pinskia at gcc dot gnu dot org]

--- Comment #5 from pinskia at gcc dot gnu dot org  2008-03-06 21:57 ---
Subject: Bug 35402

Author: pinskia
Date: Thu Mar  6 21:56:04 2008
New Revision: 132991

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132991
Log:
2008-03-06  Andrew Pinski  <[EMAIL PROTECTED]>

PR tree-opt/35402
* tree-ssa-ccp.c (get_symbol_constant_value): Handle
integral and scalar float variables which have a
NULL DECL_INITIAL.

2008-03-06  Andrew Pinski  <[EMAIL PROTECTED]>

PR tree-opt/35402
* gcc.dg/tree-ssa/ssa-store-ccp-1.c: New test.


Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-store-ccp-1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-ccp.c


-- 


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

[Bug tree-optimization/35402] Store CCP will not inline static const variable which is default initialized

[pinskia at gcc dot gnu dot org]

--- Comment #6 from pinskia at gcc dot gnu dot org  2008-03-06 21:59 ---
Fixed.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.4.0


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

[Bug fortran/35418] [4.4 Regression]: Revision 132592 miscompiles 172.mgrid

[hjl dot tools at gmail dot com]

--- Comment #8 from hjl dot tools at gmail dot com  2008-03-06 22:03 ---
This is a known issue with mgrid. The absolute tolerance is too
small. After increasing absolute tolerance from 1.0e-12 to
1.0e-11, the miscomparison is gone.


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX


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

[Bug c++/34964] ICE with broken variable in #pragma omp threadprivate

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2008-03-06 22:09 ---
Subject: Bug 34964

Author: jakub
Date: Thu Mar  6 22:08:55 2008
New Revision: 132992

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132992
Log:
* gimplify.c (goa_lhs_expr_p): Allow different ADDR_EXPR nodes
for the same VAR_DECL.

PR c++/35028
* cp-gimplify.c (cxx_omp_clause_apply_fn): Handle vararg copy ctors.

PR c++/34964
PR c++/35244
* semantics.c (finish_omp_threadprivate): Do nothing for
error_operand_p
vars.  Afterwards ensure v is VAR_DECL.

PR c++/35078
* parser.c (cp_parser_omp_for_loop): If DECL has REFERENCE_TYPE, don't
call cp_finish_decl.
* semantics.c (finish_omp_for): Fail if DECL doesn't have integral type
early.

PR c++/35028
* g++.dg/gomp/pr35028.C: New test.

PR c++/34964
PR c++/35244
* gcc.dg/gomp/pr34964.c: New test.
* g++.dg/gomp/pr34964.C: New test.
* gcc.dg/gomp/pr35244.c: New test.
* g++.dg/gomp/pr35244.C: New test.

PR c++/35078
* g++.dg/gomp/pr35078.C: New test.

* testsuite/libgomp.c/atomic-3.c: New test.

Added:
branches/gcc-4_3-branch/gcc/testsuite/g++.dg/gomp/pr34964.C
  - copied unchanged from r132426,
trunk/gcc/testsuite/g++.dg/gomp/pr34964.C
branches/gcc-4_3-branch/gcc/testsuite/g++.dg/gomp/pr35028.C
  - copied unchanged from r132426,
trunk/gcc/testsuite/g++.dg/gomp/pr35028.C
branches/gcc-4_3-branch/gcc/testsuite/g++.dg/gomp/pr35078.C
  - copied unchanged from r132426,
trunk/gcc/testsuite/g++.dg/gomp/pr35078.C
branches/gcc-4_3-branch/gcc/testsuite/g++.dg/gomp/pr35244.C
  - copied unchanged from r132426,
trunk/gcc/testsuite/g++.dg/gomp/pr35244.C
branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/gomp/pr34964.c
  - copied unchanged from r132426,
trunk/gcc/testsuite/gcc.dg/gomp/pr34964.c
branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/gomp/pr35244.c
  - copied unchanged from r132426,
trunk/gcc/testsuite/gcc.dg/gomp/pr35244.c
branches/gcc-4_3-branch/libgomp/testsuite/libgomp.c/atomic-3.c
  - copied unchanged from r132979,
trunk/libgomp/testsuite/libgomp.c/atomic-3.c
Modified:
branches/gcc-4_3-branch/gcc/ChangeLog
branches/gcc-4_3-branch/gcc/cp/ChangeLog
branches/gcc-4_3-branch/gcc/cp/cp-gimplify.c
branches/gcc-4_3-branch/gcc/cp/parser.c
branches/gcc-4_3-branch/gcc/cp/semantics.c
branches/gcc-4_3-branch/gcc/gimplify.c
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog
branches/gcc-4_3-branch/libgomp/ChangeLog


-- 


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

[Bug c++/35028] ICE with strange ctor and firstprivate

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2008-03-06 22:09 ---
Subject: Bug 35028

Author: jakub
Date: Thu Mar  6 22:08:55 2008
New Revision: 132992

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132992
Log:
* gimplify.c (goa_lhs_expr_p): Allow different ADDR_EXPR nodes
for the same VAR_DECL.

PR c++/35028
* cp-gimplify.c (cxx_omp_clause_apply_fn): Handle vararg copy ctors.

PR c++/34964
PR c++/35244
* semantics.c (finish_omp_threadprivate): Do nothing for
error_operand_p
vars.  Afterwards ensure v is VAR_DECL.

PR c++/35078
* parser.c (cp_parser_omp_for_loop): If DECL has REFERENCE_TYPE, don't
call cp_finish_decl.
* semantics.c (finish_omp_for): Fail if DECL doesn't have integral type
early.

PR c++/35028
* g++.dg/gomp/pr35028.C: New test.

PR c++/34964
PR c++/35244
* gcc.dg/gomp/pr34964.c: New test.
* g++.dg/gomp/pr34964.C: New test.
* gcc.dg/gomp/pr35244.c: New test.
* g++.dg/gomp/pr35244.C: New test.

PR c++/35078
* g++.dg/gomp/pr35078.C: New test.

* testsuite/libgomp.c/atomic-3.c: New test.

Added:
branches/gcc-4_3-branch/gcc/testsuite/g++.dg/gomp/pr34964.C
  - copied unchanged from r132426,
trunk/gcc/testsuite/g++.dg/gomp/pr34964.C
branches/gcc-4_3-branch/gcc/testsuite/g++.dg/gomp/pr35028.C
  - copied unchanged from r132426,
trunk/gcc/testsuite/g++.dg/gomp/pr35028.C
branches/gcc-4_3-branch/gcc/testsuite/g++.dg/gomp/pr35078.C
  - copied unchanged from r132426,
trunk/gcc/testsuite/g++.dg/gomp/pr35078.C
branches/gcc-4_3-branch/gcc/testsuite/g++.dg/gomp/pr35244.C
  - copied unchanged from r132426,
trunk/gcc/testsuite/g++.dg/gomp/pr35244.C
branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/gomp/pr34964.c
  - copied unchanged from r132426,
trunk/gcc/testsuite/gcc.dg/gomp/pr34964.c
branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/gomp/pr35244.c
  - copied unchanged from r132426,
trunk/gcc/testsuite/gcc.dg/gomp/pr35244.c
branches/gcc-4_3-branch/libgomp/testsuite/libgomp.c/atomic-3.c
  - copied unchanged from r132979,
trunk/libgomp/testsuite/libgomp.c/atomic-3.c
Modified:
branches/gcc-4_3-branch/gcc/ChangeLog
branches/gcc-4_3-branch/gcc/cp/ChangeLog
branches/gcc-4_3-branch/gcc/cp/cp-gimplify.c
branches/gcc-4_3-branch/gcc/cp/parser.c
branches/gcc-4_3-branch/gcc/cp/semantics.c
branches/gcc-4_3-branch/gcc/gimplify.c
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog
branches/gcc-4_3-branch/libgomp/ChangeLog


-- 


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

[Bug c++/35078] ICE with reference in parallel for loop

[jakub at gcc dot gnu dot org]

--- Comment #4 from jakub at gcc dot gnu dot org  2008-03-06 22:09 ---
Subject: Bug 35078

Author: jakub
Date: Thu Mar  6 22:08:55 2008
New Revision: 132992

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132992
Log:
* gimplify.c (goa_lhs_expr_p): Allow different ADDR_EXPR nodes
for the same VAR_DECL.

PR c++/35028
* cp-gimplify.c (cxx_omp_clause_apply_fn): Handle vararg copy ctors.

PR c++/34964
PR c++/35244
* semantics.c (finish_omp_threadprivate): Do nothing for
error_operand_p
vars.  Afterwards ensure v is VAR_DECL.

PR c++/35078
* parser.c (cp_parser_omp_for_loop): If DECL has REFERENCE_TYPE, don't
call cp_finish_decl.
* semantics.c (finish_omp_for): Fail if DECL doesn't have integral type
early.

PR c++/35028
* g++.dg/gomp/pr35028.C: New test.

PR c++/34964
PR c++/35244
* gcc.dg/gomp/pr34964.c: New test.
* g++.dg/gomp/pr34964.C: New test.
* gcc.dg/gomp/pr35244.c: New test.
* g++.dg/gomp/pr35244.C: New test.

PR c++/35078
* g++.dg/gomp/pr35078.C: New test.

* testsuite/libgomp.c/atomic-3.c: New test.

Added:
branches/gcc-4_3-branch/gcc/testsuite/g++.dg/gomp/pr34964.C
  - copied unchanged from r132426,
trunk/gcc/testsuite/g++.dg/gomp/pr34964.C
branches/gcc-4_3-branch/gcc/testsuite/g++.dg/gomp/pr35028.C
  - copied unchanged from r132426,
trunk/gcc/testsuite/g++.dg/gomp/pr35028.C
branches/gcc-4_3-branch/gcc/testsuite/g++.dg/gomp/pr35078.C
  - copied unchanged from r132426,
trunk/gcc/testsuite/g++.dg/gomp/pr35078.C
branches/gcc-4_3-branch/gcc/testsuite/g++.dg/gomp/pr35244.C
  - copied unchanged from r132426,
trunk/gcc/testsuite/g++.dg/gomp/pr35244.C
branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/gomp/pr34964.c
  - copied unchanged from r132426,
trunk/gcc/testsuite/gcc.dg/gomp/pr34964.c
branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/gomp/pr35244.c
  - copied unchanged from r132426,
trunk/gcc/testsuite/gcc.dg/gomp/pr35244.c
branches/gcc-4_3-branch/libgomp/testsuite/libgomp.c/atomic-3.c
  - copied unchanged from r132979,
trunk/libgomp/testsuite/libgomp.c/atomic-3.c
Modified:
branches/gcc-4_3-branch/gcc/ChangeLog
branches/gcc-4_3-branch/gcc/cp/ChangeLog
branches/gcc-4_3-branch/gcc/cp/cp-gimplify.c
branches/gcc-4_3-branch/gcc/cp/parser.c
branches/gcc-4_3-branch/gcc/cp/semantics.c
branches/gcc-4_3-branch/gcc/gimplify.c
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog
branches/gcc-4_3-branch/libgomp/ChangeLog


-- 


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

[Bug c++/35244] Broken diagnostic: 'type_decl' not supported by dump_expr

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2008-03-06 22:09 ---
Subject: Bug 35244

Author: jakub
Date: Thu Mar  6 22:08:55 2008
New Revision: 132992

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132992
Log:
* gimplify.c (goa_lhs_expr_p): Allow different ADDR_EXPR nodes
for the same VAR_DECL.

PR c++/35028
* cp-gimplify.c (cxx_omp_clause_apply_fn): Handle vararg copy ctors.

PR c++/34964
PR c++/35244
* semantics.c (finish_omp_threadprivate): Do nothing for
error_operand_p
vars.  Afterwards ensure v is VAR_DECL.

PR c++/35078
* parser.c (cp_parser_omp_for_loop): If DECL has REFERENCE_TYPE, don't
call cp_finish_decl.
* semantics.c (finish_omp_for): Fail if DECL doesn't have integral type
early.

PR c++/35028
* g++.dg/gomp/pr35028.C: New test.

PR c++/34964
PR c++/35244
* gcc.dg/gomp/pr34964.c: New test.
* g++.dg/gomp/pr34964.C: New test.
* gcc.dg/gomp/pr35244.c: New test.
* g++.dg/gomp/pr35244.C: New test.

PR c++/35078
* g++.dg/gomp/pr35078.C: New test.

* testsuite/libgomp.c/atomic-3.c: New test.

Added:
branches/gcc-4_3-branch/gcc/testsuite/g++.dg/gomp/pr34964.C
  - copied unchanged from r132426,
trunk/gcc/testsuite/g++.dg/gomp/pr34964.C
branches/gcc-4_3-branch/gcc/testsuite/g++.dg/gomp/pr35028.C
  - copied unchanged from r132426,
trunk/gcc/testsuite/g++.dg/gomp/pr35028.C
branches/gcc-4_3-branch/gcc/testsuite/g++.dg/gomp/pr35078.C
  - copied unchanged from r132426,
trunk/gcc/testsuite/g++.dg/gomp/pr35078.C
branches/gcc-4_3-branch/gcc/testsuite/g++.dg/gomp/pr35244.C
  - copied unchanged from r132426,
trunk/gcc/testsuite/g++.dg/gomp/pr35244.C
branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/gomp/pr34964.c
  - copied unchanged from r132426,
trunk/gcc/testsuite/gcc.dg/gomp/pr34964.c
branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/gomp/pr35244.c
  - copied unchanged from r132426,
trunk/gcc/testsuite/gcc.dg/gomp/pr35244.c
branches/gcc-4_3-branch/libgomp/testsuite/libgomp.c/atomic-3.c
  - copied unchanged from r132979,
trunk/libgomp/testsuite/libgomp.c/atomic-3.c
Modified:
branches/gcc-4_3-branch/gcc/ChangeLog
branches/gcc-4_3-branch/gcc/cp/ChangeLog
branches/gcc-4_3-branch/gcc/cp/cp-gimplify.c
branches/gcc-4_3-branch/gcc/cp/parser.c
branches/gcc-4_3-branch/gcc/cp/semantics.c
branches/gcc-4_3-branch/gcc/gimplify.c
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog
branches/gcc-4_3-branch/libgomp/ChangeLog


-- 


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

[Bug tree-optimization/35403] ipa-reference.c does not change a default initialized static variable to be readonly

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2008-03-06 22:22 ---
Actually this is already fixed with my patch for PR 35402, the code that sets
module_statics_const is dead code which I will remove.


-- 


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

[Bug c/35488] New: A incorrect result in a simple division, only in 32-bit gcc.

[purnnam1 at naver dot com]

Hi. 

I am testing a floating point division algorithm. I had tested several thousand
division cases. In most case, the result was the same with the calculated
result with FPU.

However, I found an error case for double precision floating-point division.

The case is as follows;
n = 1.600228...;
d = 1.312790...;
q = n/d;

error in q : the last bit of the output is incorrect in 32-bit GCC compiler.

(FPU rc = round to nearst even, the default rounding mode)
(The actual number were written in 64-bit hex-decimal number)


The following tool & envirionments output wrong answer:
- i386-redhat-linux gcc 3.4.6 (Intel P4, (AMD Opteron is also tested))
- windows XP/cygwin/ gcc 3.4.4 (Intel Core2 duo)


The following tool & environments output right answer:
- Solaris10 gcc3.2.3, (Sparc)
- x86_64-redhat-linux gcc 3.4.6  (AMD Opteron)
- Visual C++ 6.0 (Intel Core2 duo)


Only gcc for 32-bit envirionment outputs incorrect result.
I think there may be a problem in FPU rc(rounding control) in GCC for 32-bit
environment.

I don't think it's not the problem of CPU h/w design because other compilers
output the correct result.

Although it's very small error in a floating number calculation, gcc might be
regarded as an unreliable compiler in my field, computer arithmetic.  

I hope this problem will be fixed as soon as possible. 

Regards,
Inwook Kong

 source code   

typedef unsigned long long int UINT64;

int main(void)
{
int i,j;
double n,d,q;

//for test cases
*((UINT64*)&n)=0x3ff99a89160f4c0ell;
*((UINT64*)&d)=0x3ff5012fcd164611ll;

q=n/d;

printf("q=%llx\n",*((UINT64*)&q));
}



-- output --

[output : i386-redhat-linux gcc 3.4.6]
q=3ff380d464d7da48 <-incorrect value

[correct output- Solaris10 gcc3.2.3, x86_64-redhat-linux gcc 3.4.6]
q=3ff380d464d7da47 <- right value in IEEE-754 standard


-- environment --
[Environment]
Reading specs from /usr/lib/gcc/i386-redhat-linux/3.4.6/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--disable-checking --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-java-awt=gtk --host=i386-redhat-linux
Thread model: posix
gcc version 3.4.6 20060404 (Red Hat 3.4.6-9)


[GCC option]
CFLAGS = -c -save-temps 
LFLAGS = -lm


-- 
   Summary: A incorrect result in a simple division, only in 32-bit
gcc.
   Product: gcc
   Version: 3.4.6
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: purnnam1 at naver dot com
 GCC build triplet: gcc version 3.4.6 20060404
  GCC host triplet: i386-redhat-linux
GCC target triplet: Red Hat 3.4.6-9


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

[Bug target/35488] A incorrect result in a simple division, only in 32-bit gcc.

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|major   |normal
  Component|c   |target


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

[Bug target/35488] A incorrect result in a simple division, only in 32-bit gcc.

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2008-03-06 22:44 ---


*** This bug has been marked as a duplicate of 323 ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug rtl-optimization/323] optimized code gives strange floating point results

[pinskia at gcc dot gnu dot org]

--- Comment #105 from pinskia at gcc dot gnu dot org  2008-03-06 22:44 
---
*** Bug 35488 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||purnnam1 at naver dot com


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

[Bug target/35488] A incorrect result in a simple division, only in 32-bit gcc.

[purnnam1 at naver dot com]

--- Comment #2 from purnnam1 at naver dot com  2008-03-06 23:07 ---
It's not simple floating point related error!

I fully understand that the decimal number can't be converted to the exact
floating point number. so, the result may be different from our expectation.

This problem has no relation to a foolish mistake, (0.3+0.6)!=0.9.

In only ONE BASIC arithmetic operation, the output should be same between
compilers if the compilers are compliant to IEEE-754 standard and the inputs
are exactly same. If this bug is not corrected, the GCC 32-bit is NOT compliant
to IEEE-754 standard.


-- 

purnnam1 at naver dot com changed:

   What|Removed |Added

   Severity|normal  |major


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

[Bug target/35488] A incorrect result in a simple division, only in 32-bit gcc.

[purnnam1 at naver dot com]

--- Comment #3 from purnnam1 at naver dot com  2008-03-06 23:09 ---
This problem is not kind of a duplicate of #323.


-- 

purnnam1 at naver dot com changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|DUPLICATE   |


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

[Bug target/35488] A incorrect result in a simple division, only in 32-bit gcc.

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2008-03-06 23:14 ---
The i?86 FPU computes values in 80bit precision by default.  Starting with
GCC 4.3 you can use -mpc64 to reduce its precision to 64bits thereby obtaining
the valid IEEE-754 result.  Or you can use -mfpmath=sse to use sse registers
for doing math (which also have a precision of 64bits).

*** This bug has been marked as a duplicate of 323 ***


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug rtl-optimization/323] optimized code gives strange floating point results

[rguenth at gcc dot gnu dot org]

--- Comment #106 from rguenth at gcc dot gnu dot org  2008-03-06 23:14 
---
*** Bug 35488 has been marked as a duplicate of this bug. ***


-- 


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

[Bug target/35488] A incorrect result in a simple division, only in 32-bit gcc.

[pinskia at gcc dot gnu dot org]

--- Comment #5 from pinskia at gcc dot gnu dot org  2008-03-06 23:15 ---
The division is done and then rounded to 80bits and then rounded again to
64bits.

This is not really a bug.  It is just a misunderstanding on how x87 FPU works.

fldl-24(%ebp)
fldl-32(%ebp)
fdivrp  %st, %st(1)
fstpl   -40(%ebp)

Either use -mfpmath=sse or don't use x86.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Resolution|DUPLICATE   |INVALID


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

[Bug target/35488] A incorrect result in a simple division, only in 32-bit gcc.

[pinskia at gcc dot gnu dot org]

--- Comment #6 from pinskia at gcc dot gnu dot org  2008-03-06 23:18 ---
One more comment about this code, you are violating C/C++ aliasing rules.


-- 


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

[Bug c/35489] New: Inaccurate GCC documentation

[adam at irvine dot com]

I'm not sure whether this is the proper method for reporting errors in
the documentation.  However, I believe there is a serious error in the
GCC documentation that needs to be addressed.

The error is at http://gcc.gnu.org/bugs.html#nonbugs_general.  This
section refers to inherent limitations of floating-point types because
most numbers can be represented only approximately.

The problem is that this "non-bug", which is connected to problem
report #323 and has a hyperlink to it, encompasses many other problem
reports that are not accurately described by this documentation
section.  Some are due to the inherent limitations, but others are
actual bugs in which the compiler is generating incorrect instructions
(such as #12331); others are due to a particular floating-point
processor feature that can be defeated with a flag (but it could be
considered a bug that the compiler is not able to take proper advantage
of this feature); still others could marginally be considered "bugs"
because a compiler could, in theory, generate correct code although
expecting it to do so may not be reasonable.

For honesty's sake, since so many problem reports end up with users
being referred to this section, the documentation should accurately
describe the situation (including the fact that there are known bugs
which may be difficult to fix), rather than giving the false
implication that all such problems are the user's fault for doing
something ignorant.  I believe this to be a serious inaccuracy in the
documentation, and one that I think has been leaving users in an
unhelpful state of confusion.


-- 
   Summary: Inaccurate GCC documentation
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: adam at irvine dot com


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

[Bug c/35489] Inaccurate GCC documentation

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2008-03-06 23:58 ---
> but others are
actual bugs in which the compiler is generating incorrect instructions
(such as #12331);

That is not incorrect instructions.  Just different than what you are
expecting.  All can be defected by the compiler option to turn the fp precision
differently.




*** This bug has been marked as a duplicate of 323 ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug rtl-optimization/323] optimized code gives strange floating point results

[pinskia at gcc dot gnu dot org]

--- Comment #107 from pinskia at gcc dot gnu dot org  2008-03-06 23:58 
---
*** Bug 35489 has been marked as a duplicate of this bug. ***


-- 


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

[Bug target/35488] A incorrect result in a simple division, only in 32-bit gcc.

[purnnam1 at naver dot com]

--- Comment #7 from purnnam1 at naver dot com  2008-03-07 00:05 ---
Although I knew GCC use 80-bit format internally, I thought the result should
be same in 80-bit format.
Due to the very kind explanation about my problem, I can understand that the
result can be changed because the rounding operation occurs two times.

The cause of the problem was 'double rounding'.

Ironically, the 80-bit internal format makes MORE BIG ERROR in 64-bit floating
point calculation. 
For 64-bit output, 64-bit internal format will generate the best result becauce
IEEE-754 intendeds a result to be nearest to the true value with infinite
precision.

If GCC adopts 80-bit internal format, the final result in the 64-bit floating
point will not be the best because of the unavoidable double rounding
operation.
So, I think that it's very good decision to support 64-bit internal foramt in
GCC 4.x version. If a user uses 64-bit floating point numbers, the user will
get the more correct result by this option.

Also, I really appreciate that Andrew Pinski lets me know my alais rule
violation in C/C++. Due to Andrew's kind advice, I knew how much my violation
affects the program performance. It was not just a problem about code
portability issue. Thank you again.

I reallly appreciate you all.


-- 


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

[Bug target/35189] -mno-sse4.2 turns off SSE4a

[hjl at gcc dot gnu dot org]

--- Comment #7 from hjl at gcc dot gnu dot org  2008-03-07 00:08 ---
Subject: Bug 35189

Author: hjl
Date: Fri Mar  7 00:07:36 2008
New Revision: 132994

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132994
Log:
gcc/

2008-03-06  H.J. Lu  <[EMAIL PROTECTED]>

Backport from mainline:
2008-02-18  H.J. Lu  <[EMAIL PROTECTED]>

PR target/35189
* config/i386/i386.c (OPTION_MASK_ISA_MMX_SET): New.
(OPTION_MASK_ISA_3DNOW_SET): Likewise.
(OPTION_MASK_ISA_SSE_SET): Likewise.
(OPTION_MASK_ISA_SSE2_SET): Likewise.
(OPTION_MASK_ISA_SSE3_SET): Likewise.
(OPTION_MASK_ISA_SSSE3_SET): Likewise.
(OPTION_MASK_ISA_SSE4_1_SET): Likewise.
(OPTION_MASK_ISA_SSE4_2_SET): Likewise.
(OPTION_MASK_ISA_SSE4_SET): Likewise.
(OPTION_MASK_ISA_SSE4A_SET): Likewise.
(OPTION_MASK_ISA_SSE5_SET): Likewise.
(OPTION_MASK_ISA_3DNOW_A_UNSET): Likewise.
(OPTION_MASK_ISA_MMX_UNSET): Updated.
(OPTION_MASK_ISA_3DNOW_UNSET): Updated.
(OPTION_MASK_ISA_SSE_UNSET): Likewise.
(OPTION_MASK_ISA_SSE3_UNSET): Likewise.
(OPTION_MASK_ISA_SSSE3_UNSET): Likewise.
(OPTION_MASK_ISA_SSE4_1_UNSET): Likewise.
(OPTION_MASK_ISA_SSE4_2_UNSET): Likewise.
(OPTION_MASK_ISA_SSE4A_UNSET): Likewise.
(OPTION_MASK_ISA_SSE5_UNSET): Likewise.
(OPTION_MASK_ISA_SSE4): Removed.
(ix86_handle_option): Turn on bits in ix86_isa_flags and
ix86_isa_flags_explicit with OPTION_MASK_ISA_XXX_SET for
-mXXX.
(override_options): Don't turn on implied SSE/MMX bits in
ix86_isa_flags.

gcc/testsuite/

2008-03-06  H.J. Lu  <[EMAIL PROTECTED]>

Backport from mainline:
2008-02-18  H.J. Lu  <[EMAIL PROTECTED]>

PR target/35189
* gcc.target/i386/isa-1.c: New.
* gcc.target/i386/isa-2.c: Likewise.
* gcc.target/i386/isa-3.c: Likewise.
* gcc.target/i386/isa-4.c: Likewise.
* gcc.target/i386/isa-5.c: Likewise.
* gcc.target/i386/isa-6.c: Likewise.
* gcc.target/i386/isa-7.c: Likewise.
* gcc.target/i386/isa-8.c: Likewise.
* gcc.target/i386/isa-9.c: Likewise.
* gcc.target/i386/isa-10.c: Likewise.
* gcc.target/i386/isa-11.c: Likewise.
* gcc.target/i386/isa-12.c: Likewise.
* gcc.target/i386/isa-13.c: Likewise.
* gcc.target/i386/isa-14.c: Likewise.

Added:
branches/gcc-4_3-branch/gcc/testsuite/gcc.target/i386/isa-1.c
branches/gcc-4_3-branch/gcc/testsuite/gcc.target/i386/isa-10.c
branches/gcc-4_3-branch/gcc/testsuite/gcc.target/i386/isa-11.c
branches/gcc-4_3-branch/gcc/testsuite/gcc.target/i386/isa-12.c
branches/gcc-4_3-branch/gcc/testsuite/gcc.target/i386/isa-13.c
branches/gcc-4_3-branch/gcc/testsuite/gcc.target/i386/isa-14.c
branches/gcc-4_3-branch/gcc/testsuite/gcc.target/i386/isa-2.c
branches/gcc-4_3-branch/gcc/testsuite/gcc.target/i386/isa-3.c
branches/gcc-4_3-branch/gcc/testsuite/gcc.target/i386/isa-4.c
branches/gcc-4_3-branch/gcc/testsuite/gcc.target/i386/isa-5.c
branches/gcc-4_3-branch/gcc/testsuite/gcc.target/i386/isa-6.c
branches/gcc-4_3-branch/gcc/testsuite/gcc.target/i386/isa-7.c
branches/gcc-4_3-branch/gcc/testsuite/gcc.target/i386/isa-8.c
branches/gcc-4_3-branch/gcc/testsuite/gcc.target/i386/isa-9.c
Modified:
branches/gcc-4_3-branch/gcc/ChangeLog
branches/gcc-4_3-branch/gcc/config/i386/i386.c
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug c/35489] Inaccurate GCC documentation

[adam at irvine dot com]

--- Comment #2 from adam at irvine dot com  2008-03-07 00:08 ---
(In reply to comment #1)
> > but others are
> actual bugs in which the compiler is generating incorrect instructions
> (such as #12331);
> 
> That is not incorrect instructions.  Just different than what you are
> expecting. 

I suppose that if the chip has an instruction that would allow it to store the
correct value without losing any precision, and the compiler instead chooses to
generate an instruction that causes the computation to lose precision, that
could be considered "different than what I am expecting", yes.

Actually, I like that response.  I might try to use it myself next time one of
our customers reports a problem.


-- 


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

[Bug target/35488] A incorrect result in a simple division, only in 32-bit gcc.

[purnnam1 at naver dot com]

--- Comment #8 from purnnam1 at naver dot com  2008-03-07 00:37 ---
Actually the 80-bit internal format will be better in converting a decimal
number into the floating point number. In this point, the 80-bit internal
format may be useful. 


-- 


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

[Bug target/35490] New: Wrong code with altivec register passing and sibcalling

[pinskia at gcc dot gnu dot org]

Take the following piece of code:
#define vector __vector
struct data {
 vector float v;
   };

   extern int bar (int a, struct data b, void *c);

   int foo (struct data *inp_r3, void *inp_r4)
   {
 return bar(10, *inp_r3, ((void *) inp_r4));
   }

Right now we sibcall with -O2 and the lvx instruction gets removed:
_foo:
mfspr r0,256
stw r0,-4(r1)
oris r0,r0,0x2000
mtspr 256,r0
li r3,10
lwz r12,-4(r1)
mtspr 256,r12
b L_bar$stub


-- 
   Summary: Wrong code with altivec register passing and sibcalling
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
GCC target triplet: powerpc64-darwin


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

[Bug target/35491] New: wrong ABI for some struct passing with vector code

[pinskia at gcc dot gnu dot org]

Take the following code:
#define vector __vector
struct data {
 float f;  //0 - 3
 int i;// 4 - 7
 double d; // 8 - 15
 vector float v;  // 16 - 31
   };// __attribute__ ((d64_abi));  //size is 32

   extern int bar (int a, struct data b, void *c);

   int foo (struct data *inp_r3, void *inp_r4)
   {
 return bar(10, *inp_r3, ((void *) inp_r4));
   }

--- CUT ---
We get:
_foo:
mflr r0
std r0,16(r1)
stdu r1,-128(r1)
mfspr r0,256
stw r0,124(r1)
oris r0,r0,0x2000
mtspr 256,r0
li r0,16
lfs f1,0(r3)
lvx v2,r3,r0
mr r10,r4  <--- note r10
lfd f2,8(r3)
lwz r5,4(r3)
li r3,10
bl L_bar$stub
addi r1,r1,128
lwz r12,-4(r1)
mtspr 256,r12
ld r0,16(r1)
mtlr r0
blr

--- CUT ---
With Apple's compiler we get:
_foo:
mfspr r0,256
stw r0,-12(r1)
oris r0,r0,0x2000
mtspr 256,r0
mflr r0
mr r9,r4  <--- NOTE r9
std r0,16(r1)
stdu r1,-128(r1)
li r0,16
nop
lfs f1,0(r3)
lfd f2,8(r3)
lwz r5,4(r3)
lvx v2,r3,r0
li r3,10
bl L_bar$stub
addi r1,r1,128
lwz r12,-12(r1)
mtspr 256,r12
ld r0,16(r1)
mtlr r0
blr


-- 
   Summary: wrong ABI for some struct passing with vector code
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: wrong-code, ABI
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
GCC target triplet: powerpc64-darwin


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

[Bug target/35488] A incorrect result in a simple division, only in 32-bit gcc.

[brian at dessent dot net]

--- Comment #9 from brian at dessent dot net  2008-03-07 01:20 ---
Subject:  A incorrect result in a simple division, only in 
 32-bit gcc.


> Although I knew GCC use 80-bit format internally, I thought the result should
> be same in 80-bit format.

No, it's not that gcc uses 80 bit or 64 bit "internally".  It's that the
i387 does computations for 64 bit double types in 80 bit extended mode
by default.  So it's not gcc that determines this, or that gcc changed
anything and suddenly decided "to support 64-bit internal foramt in GCC
4.x version."  gcc's double precision type has always been and always
will be 64 bits on 32 bit i386.  That has not changed in 4.x.  It's a
matter of how the i387 hardware is configured.  The -mpc64 switch
changes nothing about gcc's internal representation, it simply emits
extra code to set some fp registers to tell the hardware not to use
extended precision.  This is not a change in gcc per se.


-- 


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

[Bug target/35492] New: ICE building kernel sk_stream_wait_connect output_operand: invalid operand for 'p' modifier

[hp at gcc dot gnu dot org]

With trunk r132993 and gcc-4_3-branch r132992, the following testcase yields,
with "-march=v32 -O2":
(const_int -13 [0xfff3])
s2.c: In function 'sk_stream_wait_connect':
s2.c:26: internal compiler error: output_operand: invalid operand for 'p'
modifier

void prepare_to_wait (void *, void *, int);
void finish_wait (void *, void *);
extern signed long schedule_timeout (signed long);
struct sock
{
  unsigned char skc_state;
  void *sk_sleep;
  int sk_err;
};

void
sk_stream_wait_connect (struct sock *sk, long *timeo_p)
{
  int done;
  int wait;
  do
{
  if ((1 << sk->skc_state) & ~12)
return;
  prepare_to_wait (sk->sk_sleep, &wait, 1);
  *(timeo_p) = schedule_timeout (0);
  done = !sk->sk_err;
  finish_wait (sk->sk_sleep, &wait);
}
  while (!done);
}


-- 
   Summary: ICE building kernel sk_stream_wait_connect
output_operand: invalid operand for 'p' modifier
   Product: gcc
   Version: 4.3.1
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hp at gcc dot gnu dot org
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: cris-*-* and crisv32-*-*


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

[Bug ada/35493] New: Assert_Failure uintp.adb:1593

[danglin at gcc dot gnu dot org]

/Users/dave/gnu/gcc/objdir/./prev-gcc/xgcc
-B/Users/dave/gnu/gcc/objdir/./prev-g
cc/ -B/opt/gnu/gcc/gcc-4.4.0/i686-apple-darwin9/bin/ -c -g -O2
-fomit-frame-poin
ter  -gnatpg -gnata -nostdinc -I- -I. -Iada -I../../gcc/gcc/ada
../../gcc/gc
c/ada/ada.ads -o ada/ada.o
+===GNAT BUG DETECTED==+
| 4.4.0 20080307 (experimental) [trunk revision 132999] (i686-apple-darwin9) |
| Assert_Failure uintp.adb:1593|
| No source file position information available|

This occurs in stage3.  Build yesterday was ok.


-- 
   Summary: Assert_Failure uintp.adb:1593
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: danglin at gcc dot gnu dot org
 GCC build triplet: i686-apple-darwin9
  GCC host triplet: i686-apple-darwin9
GCC target triplet: i686-apple-darwin9


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

[Bug middle-end/35492] ICE building kernel sk_stream_wait_connect output_operand: invalid operand for 'p' modifier

[hp at gcc dot gnu dot org]

--- Comment #1 from hp at gcc dot gnu dot org  2008-03-07 03:07 ---
Also with trunk r132670.  The ICE points at the somewhat-hairy last alternative
of the *btst pattern for being at fault for not matching for the insn appearing
in 177r.greg:

(insn:QI 12 11 13 3 s2.c:18 (set (cc0)
(zero_extract:SI (const_int -13 [0xfff3])
(const_int 1 [0x1])
(reg:SI 15 acr [orig:29 .skc_state ] [29]))) 16 {*btst}
(nil))

On closer inspection however, the condition indicates that the operands are
invalid and gcc should have noticed that, when transforming the following valid
insn into the above (from 176r.lreg):
(insn:QI 12 11 13 3 s2.c:18 (set (cc0)
(zero_extract:SI (reg:SI 44)
(const_int 1 [0x1])
(reg:SI 29 [ .skc_state ]))) 16 {*btst}
(expr_list:REG_DEAD (reg:SI 29 [ .skc_state ])
(nil)))

So, something replaces reg 44 and doesn't check the validity of the
replacement.
For 4.3, it might be safer to remove the last alternative of *btst, but for
trunk we should fix the real bug, supposedly in reload. ;)
Changing component to middle-end.


-- 

hp at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |hp at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
  Component|target  |middle-end
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-03-07 03:07:59
   date||


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

[Bug target/35373] [4.4 Regression] bootstraping on powerpc with 128bit long double fails with revision 132578

[bergner at gcc dot gnu dot org]

--- Comment #10 from bergner at gcc dot gnu dot org  2008-03-07 04:15 
---
Created an attachment (id=15276)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15276&action=view)
Updated patch to disallow TFmode and TDmode from reg+reg addressing  

Here is an updated patch that not only fixes the bootstrap issue, but also
fixes a regression of the vect-64.c test case, both of which were being caught
by the new gcc_assert added by Joseph.


-- 

bergner at gcc dot gnu dot org changed:

   What|Removed |Added

  Attachment #15256|0   |1
is obsolete||


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

[Bug target/35189] -mno-sse4.2 turns off SSE4a

[hjl dot tools at gmail dot com]

--- Comment #8 from hjl dot tools at gmail dot com  2008-03-07 04:24 ---
Fixed.


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Known to work|4.4.0   |4.4.0 4.3.1
 Resolution||FIXED


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

[Bug target/35408] Bad XFmode size and alignment for x86

[hjl dot tools at gmail dot com]

--- Comment #1 from hjl dot tools at gmail dot com  2008-03-07 04:26 ---
There is no problem. TARGET_128BIT_LONG_DOUBLE is enabled in 64bit:

/* By default, 64-bit mode uses 128-bit long double.  */
#undef TARGET_SUBTARGET64_DEFAULT
#define TARGET_SUBTARGET64_DEFAULT \
MASK_128BIT_LONG_DOUBLE


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug other/35457] Error building GCC trunk on CELL SPU

[eres at il dot ibm dot com]

--- Comment #2 from eres at il dot ibm dot com  2008-03-07 04:52 ---
(In reply to comment #1)
> What happens if you build from a clean directory?

I get the same error.


-- 


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

[Bug other/35457] Error building GCC trunk on CELL SPU

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2008-03-07 04:58 ---
I don't usually build in combined tree for spu-elf so I never run into this
issue.  I wonder if due to the newer autoconf issue.


-- 


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

[Bug other/35457] Error building GCC trunk on CELL SPU

[eres at il dot ibm dot com]

--- Comment #4 from eres at il dot ibm dot com  2008-03-07 05:15 ---
(In reply to comment #3)
> I don't usually build in combined tree for spu-elf so I never run into this
> issue.  I wonder if due to the newer autoconf issue.

It seems to be related to the following change: 

2008-02-20  Paolo Bonzini  <[EMAIL PROTECTED]>

PR bootstrap/32009
PR bootstrap/32161

* configure.ac (CFLAGS_FOR_TARGET, CXXFLAGS_FOR_TARGET): Compute here.
* configure: Regenerate.

* Makefile.def: Define stage_libcflags for all bootstrap stages.
* Makefile.tpl (BOOT_LIBCFLAGS, STAGE2_LIBCFLAGS, STAGE3_LIBCFLAGS,
STAGE4_LIBCFLAGS): New.
(CFLAGS_FOR_TARGET, CXXFLAGS_FOR_TARGET): Subst from autoconf, without
$(SYSROOT_CFLAGS_FOR_TARGET) and $(DEBUG_PREFIX_CFLAGS_FOR_TARGET).


-- 


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

[Bug tree-optimization/35494] New: [4.4 Regression]: Revision 132991 breaks 483.xalancbmk

[hjl dot tools at gmail dot com]

Revision 132991:

http://gcc.gnu.org/ml/gcc-patches/2008-03/msg00445.html

breaks 483.xalancbmk in SPEC CPU 2006 on Linux/Intel64
with -O2 -ffast-math. I got

  Running 483.xalancbmk ref base o2 default

483.xalancbmk: copy #0 non-zero return code (rc=0, signal=6)



Contents of ref.err

terminate called after throwing an instance of 'xercesc_2_5::DOMException'



That optimization may not be valid for C++ code.


-- 
   Summary: [4.4 Regression]: Revision 132991 breaks 483.xalancbmk
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com


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

[Bug c++/35495] New: Error in compiling 64 bit on AIX 5.1 for C++.

[sarveshpat at gmail dot com]

bash-2.05b# g++ -maix64 a.cpp
/tmp//ccAIh3XS.o(.pr+0x1c):/tmp//ccveogPZ.c: undefined reference to
`.__register_frame_info_table'
/tmp//ccAIh3XS.o(.pr+0x6c):/tmp//ccveogPZ.c: undefined reference to
`.__deregister_frame_info'
collect2: ld returned 1 exit status


gcc compiler i am using 4.0.0.0.

this i have tested with default LD i.e is in /usr/ccs/bin
and also with GNU ld. getting same error.

gcc working fine for 32 and 64 bit.
g++ working for 32 bit only and giving error for 64 bit and have nentioned
above.


-- 
   Summary: Error in compiling 64 bit on AIX 5.1 for C++.
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sarveshpat at gmail dot com


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